• 全部
  • 经验案例
  • 典型配置
  • 技术公告
  • FAQ
  • 漏洞说明
  • 全部
  • 全部
  • 大数据引擎
  • 知了引擎
产品线
搜索
取消
案例类型
发布者
是否解决
是否官方
时间
搜索引擎
匹配模式
高级搜索

高端路由器SR8800 GRE隧道大包不通案例一则

2015-04-29 发表
  • 0关注
  • 0收藏 2366浏览
罗旭 四段
粉丝:0人 关注:0人

客户局点反馈新增业务时,在北京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后进行了如下图1IP分片,此时作为隧道标识的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进行处理,转发性能高。

同时该转发方式也存在一个隐患,特别是在做MPLSGRE等时,数据报文到SR88设备后再进行相应GREMPLS等封装,其数据报文大小很有可能会超过中间传输设备的MTU,公网传输设备如果不支持分片,则会丢弃该部分报文,如果支持分片,则传输设备会对报文进行再分片,到对端硬件转发设备后,因不能对该再分片报文进行重组导致丢弃该部分报文。

SR88在做MPLSGRE时,经常会遇到该类问题,所以在网络规划时,需要充分考虑到该情况。


该案例对您是否有帮助:

您的评价:1

若您有关于案例的建议,请反馈:

作者在2019-06-07对此案例进行了修订
1 个评论
zhiliao_42833 知了小白
粉丝:0人 关注:0人

牛啊

编辑评论

举报

×

侵犯我的权益 >
对根叔知了社区有害的内容 >
辱骂、歧视、挑衅等(不友善)

侵犯我的权益

×

泄露了我的隐私 >
侵犯了我企业的权益 >
抄袭了我的内容 >
诽谤我 >
辱骂、歧视、挑衅等(不友善)
骚扰我

泄露了我的隐私

×

您好,当您发现根叔知了上有泄漏您隐私的内容时,您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到pub.zhiliao@h3c.com 邮箱,我们会尽快处理。
  • 1. 您认为哪些内容泄露了您的隐私?(请在邮件中列出您举报的内容、链接地址,并给出简短的说明)
  • 2. 您是谁?(身份证明材料,可以是身份证或护照等证件)

侵犯了我企业的权益

×

您好,当您发现根叔知了上有关于您企业的造谣与诽谤、商业侵权等内容时,您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到 pub.zhiliao@h3c.com 邮箱,我们会在审核后尽快给您答复。
  • 1. 您举报的内容是什么?(请在邮件中列出您举报的内容和链接地址)
  • 2. 您是谁?(身份证明材料,可以是身份证或护照等证件)
  • 3. 是哪家企业?(营业执照,单位登记证明等证件)
  • 4. 您与该企业的关系是?(您是企业法人或被授权人,需提供企业委托授权书)
我们认为知名企业应该坦然接受公众讨论,对于答案中不准确的部分,我们欢迎您以正式或非正式身份在根叔知了上进行澄清。

抄袭了我的内容

×

原文链接或出处

诽谤我

×

您好,当您发现根叔知了上有诽谤您的内容时,您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到pub.zhiliao@h3c.com 邮箱,我们会尽快处理。
  • 1. 您举报的内容以及侵犯了您什么权益?(请在邮件中列出您举报的内容、链接地址,并给出简短的说明)
  • 2. 您是谁?(身份证明材料,可以是身份证或护照等证件)
我们认为知名企业应该坦然接受公众讨论,对于答案中不准确的部分,我们欢迎您以正式或非正式身份在根叔知了上进行澄清。

对根叔知了社区有害的内容

×

垃圾广告信息
色情、暴力、血腥等违反法律法规的内容
政治敏感
不规范转载 >
辱骂、歧视、挑衅等(不友善)
骚扰我
诱导投票

不规范转载

×

举报说明

提出建议

    +

亲~登录后才可以操作哦!

确定

亲~检测到您登陆的账号未在http://hclhub.h3c.com进行注册

注册后可访问此模块

跳转hclhub

你的邮箱还未认证,请认证邮箱或绑定手机后进行当前操作