客户局点反馈新增业务时,在北京SR88和上海SR88建立GRE隧道,出现内网服务器互访时大包不通,小包正常的现象。
大包不通的问题一般跟设备接口MTU有关,SR88做硬件转发,报文在进行转发时,并不考虑其出接口的MTU值,那么出现该情况按照以往经验一般是因为公网传输设备丢了大包,即报文大小大于传输的接口MTU,传输将该报文进行了丢弃。
根据故障现象,最开始怀疑是转发报文在SR88上进行GRE封装后,其MTU值大于1500,而传输设备(MTU值为1500)不支持再分片,从而丢弃了该报文导致。但与运营商确认,答复其传输设备支持分片,也就是大于1500的报文,传输设备会进行再分片后转发,不会丢弃。
那么既然传输支持分片,为什么服务器内网互访大包还是不通呢?
根据该问题的故障现象,在沿途各个设备的端口上进行流统计数确认丢包的具体位置,最终确认报文丢弃在上海的SR8800的XGE3/0/2入方向,丢弃类型为入方向丢包。
[H3C-hidecmd]_display driver forward counter slot 3
PP: SlotId: 3, ChipNum: 0
……
------------------------------------------------------------------
Value(HEX) Value(DEC)| Address | Description
------------------------------------------------------------------
……
0x0000001E 30 | 0x00700074 | Ingress Drop Counter
0x00000000 0 | 0x01202030 | VOQ0 Head Drop
0x00000000 0 | 0x01202038 | VOQ0 Tail Drop
0x00000000 0 | 0x01202040 | VOQ0 Device Disable Drop
各个设备报文详细的统计计数如下图:
确认了丢包位置,也确认现网丢包原因就是运营商设备对GRE报文进行了再分片导致SR88丢弃了该部分报文。那么为什么SR88会丢弃该部分再分片的报文?
a) 如下图1所示,运营商的设备对于北京S95E转发到上海S95E的报文判断超过其端口MTU后进行了如下图1的IP分片,此时作为隧道标识的GRE头部只携带到了第一个分片中,而且隧道外层IP地址设置了IP分片标志。这样的报文到达SR88设备后,如果想要正常的转发,SR88首先需要将这两个报文重组成分片前的报文,这样才能让第二个分片报文进行正常的GRE终结。但是如果要对报文进行重组,则必须要CPU处理,SR88基于硬件转发,报文不上CPU处理,则对该分片报文进行了丢弃。
b) 如下图2所示,对于硬件转发设备,如SR88,能正常终结的GRE分片报文为每个分片报文必须都携带GRE头,同时外层IP的分片标记必须未置位,避免硬件转发设备对报文进行重组。图2的分片方式一般在隧道起始软转发设备上,如MSR。
综上所述,北京和上海之间的SR88建立GRE隧道的大包不通的问题为运营商设备对GRE报文进行了再分片,而SR88设备不能对这种再分片的报文进行重组,然后再进行GRE隧道终结,导致丢弃了该报文。该类问题一般有如下解决方案:
方案1:减小服务器发出的报文大小;
方案2:在SR88设备和服务器之间接入一台软转发设备,如MSR,对服务器发出的报文进行再次分片,避免运营商设备的再分片;
方案3:协调运营商调整传输设备的MTU值(将其改大),做到对于北京95E转发的报文不进行分片。
具体采用何种方案视现场情况而定,如果客户处SERVER较多,方案1也就不具备可操作性。另外根据实际业务需求,方案2肯定会影响GRE上承载的业务性能,带宽必然会形成瓶颈。
一般推荐方案3,由运营商侧修改其传输的MTU彻底解决这个问题,避免为将来业务扩展留下隐患。
SR88等硬件转发设备对数据报文进行转发时不考虑出接口MTU,不进行分片,开启jumbofream帧后(默认开启),能正常接收大包并进行转发。该转发方式因为报文不用上CPU进行处理,转发性能高。
同时该转发方式也存在一个隐患,特别是在做MPLS、GRE等时,数据报文到SR88设备后再进行相应GRE、MPLS等封装,其数据报文大小很有可能会超过中间传输设备的MTU,公网传输设备如果不支持分片,则会丢弃该部分报文,如果支持分片,则传输设备会对报文进行再分片,到对端硬件转发设备后,因不能对该再分片报文进行重组导致丢弃该部分报文。
SR88在做MPLS、GRE时,经常会遇到该类问题,所以在网络规划时,需要充分考虑到该情况。
✖
案例意见反馈
亲~登录后才可以操作哦!
确定你的邮箱还未认证,请认证邮箱或绑定手机后进行当前操作