锐捷S5750V2-L GRE场景下同步数据异常
一、故障现象描述
分部和总部的服务器同步数据异常，分部无法同步数据给总部服务器，分部上传大文件也无法获得总部服务器的响应，以及分部的考勤数据也无法传到总部服务器。
场景拓扑图如下：
拓扑描述：S5750V2-L和总部的核心设备建立GRE隧道来跨公网传输数据，S5750V2-L下的终端需要向总部核心下的服务器同步数据。
二、故障排查分析
-
了解到故障背景是将原思科设备替换为我司S5750V2-L交换机之后出现的问题，怀疑是我司交换机丢包导致，由于GRE报文通过acl计数无法统计到，故分别抓取正常情况和不正常情况的报文对比分析。 正常情况下，终端ping小包能通，终端侧抓包如下，收发包正常。
https://www.imgdata.cn/imgs/2024/12/24/9542215b05b36124.png
正常情况下，上联防火墙抓包如下，收发包正常。
异常情况下，终端ping大包不通，终端侧抓包没有reply。终端发出报文长度1514，但还未超出我司设备默认情况下最大支持的报文长度1522。（扩展说明：我司设备对报文长度设计的额外22字节，包括了Ethernet II 规范的6字节DA+6字节SA+2字节EtherType+4字节CRC，以及802.3ac增加的4字节vlan tag）
异常情况下，上联防火墙抓包如下，防火墙没有收到我司设备发出的icmp request，说明大包丢包位置在我司设备上。
-
进一步分析设备丢弃报文的原因，终端侧发出的icmp request报文是1514字节，加上4字节FCS(即CRC)和4字节vlan tag，长度刚好是1522，所以报文进入交换机接口时不会丢包。但长度超过了隧道口下的ip mtu 1360，从而导致了报文在GRE隧道口产生丢包。如果要让经过GRE封装后的报文能在交换机上正常收发，则需要在默认MTU的基础上扩展28字节，但可能会导致下一跳传输设备无法处理报文。
-
基于客户原设备可正常转发，分析正常tcp有协商机制，会协商发送的报文大小，交换机有icmp不可达功能，正常mtu值过大会发送差错报文和终端协商，但是终端侧抓包未抓到差错报文；
-
检查交换机配置，发现svi口下关闭了icmp不可达功能，从而导致交换机未发送差错报文，重新开启配置后传输恢复正常。
三、故障根因说明
终端所属vlan下关闭了ip unreachables功能，当终端发送的tcp报文长度超过了tunnel隧道口的mtu时，报文就被交换机丢弃了。而当交换机开启了ip unreachables功能，若终端发送的tcp报文的长度超过了tunnel隧道口的mtu，交换机会给终端发送一个icmp差错报文（icmp差错报文里面会携带tunnel隧道口的ip mtu），告诉终端，它发送的数据包的长度过大，终端收到这个差错报文之后 ，后续发送报文的长度会使用icmp差错报文里面的mtu值，故可以正常通过整个网络。
四、故障解决方案
终端所属vlan下开启ip unreachables功能 ，如下 interface VLAN 2
ip unreachables
版权声明：
作者：SE_You
链接：https://www.cnesa.cn/2579.html
来源：CNESA
文章版权归作者所有，未经允许请勿转载。
THE END
0
二维码
打赏
海报
锐捷S5750V2-L GRE场景下同步数据异常
一、故障现象描述
分部和总部的服务器同步数据异常，分部无法同步数据给总部服务器，分部上传大文件也无法获得总部服务器的响应，以及分部的考勤数据也无法传到总部服务器。
场景拓扑图如下：
拓扑描述：S5750V2-L和总部的核心设备建立GRE隧道来跨公网传输数据，S5750V2-L下的终端需要向总部核心下的服务器同步数据。
二、故障排查分析
了解到故障背景是将原思科设备替换为我司S5750V2-L交换机之后出现的问题，怀疑是我司交换机丢包导致，由于GRE报文通过acl计数无法统计到，故分别抓取正常情况和不正常情况的报文对比分析。 正常情况下，终端ping小包能通，终端侧抓包如下，收发包正常。
https://www.imgdata.cn/imgs/2024/12/24/9542215b05b36124.png
正常情况下，上联防火墙抓包如下，收发包正常。
异常情况下，终端ping大包不通，终端侧抓包没有reply。终端发出报文长度1514，但还未超出我司设备默认情况下最大支持的报文长度1522。（扩展说明：我司设备对报文长度设计的额外22字节，包括了Ethernet II 规范的6字节DA+6字节SA+2字节EtherType+4字节CRC，以及802.3ac增加的4字节vlan tag）
异常情况下，上联防火墙抓包如下，防火墙没有收到我司设备发出的icmp request，说明大包丢包位置在我司设备上。
进一步分析设备丢弃报文的原因，终端侧发出的icmp request报文是1514字节，加上4字节FCS(即CRC)和4字节vlan tag，长度刚好是1522，所以报文进入交换机接口时不会丢包。但长度超过了隧道口下的ip mtu 1360，从而导致了报文在GRE隧道口产生丢包。如果要让经过GRE封装后的报文能在交换机上正常收发，则需要在默认MTU的基础上扩展28字节，但可能会导致下一跳传输设备无法处理报文。
基于客户原设备可正常转发，分析正常tcp有协商机制，会协商发送的报文大小，交换机有icmp不可达功能，正常mtu……
共有 0 条评论