【转】VPN Tunnel 口MTU问题解决

作者：易隐者 发布于：2012-12-24 14:00 Monday 分类：案例讨论

【说在之前】：

1，这个帖子是我在锐捷的论坛里看到的，现象很特别，值得研究讨论一番；

2，原帖中仅对故障做了描述，并未给出导致故障产生的根本原因，大家可以自行先考虑考虑，并尝试分析推测一下可能的原因，可在此贴下留言以供探讨；

3，此案例的正确答案应该已由回复中的liuquyong兄弟给出，主要原因在于加解密次数的减少导致了ERP交互性能的提升。关键就在于下面这张来自于思科的加解密流程图：

点击查看原图

【原文连接】：

  http://support.ruijie.com.cn/showtopic-22758.aspx

【原文全文】：

Gre隧道，Tunnel接口的MTU值设置为大于1500的值，有效吗？带着这个问题我讲讲今天遇到的问题：
NPE20（总部，版本RGNOS 9.12）与NBR300（分部,版本RGNOS 9.12）建立Tunnel 0接口的GRE隧道。
2010年初的时候刚开始用Tunnel功能，当时show interface tunnel 0  显示的 Tunnel 的 MTU值 1464，此时分部访问总部的ERP（用友U890，C/S架构，通过Tunnel隧道来访问的）很慢，卡！只要一遇到分部客户端与服务器之间有数据交互的时候，就异常的卡，有时软件直接无响应。
命令行将此Tunnel的MTU值设置为65535，此时访问速度“嗖”的立刻上去，只能用两个字形容：流畅！
前天，我将NPE20和NBR300都升级到最新的9.17 2P1 B4版本，9.17的Web控制界面操控性以及网速都有一定的提升，但这时出现问题，Tunnel的MTU值设置为65535之后，会自动变回1464，企业内的应用再度变卡，就和上述曾经遇到的卡的情况一样。并且无论如何都不像9.12版本那样保持65535。
此问题一直延续到今天。于是迫于无奈，在咨询了锐捷400电话客服之后，由3034号客服帮我将NPE20、NBR300都刷回9.12版本。刷回9.12版本之后的tunnel 0 先是保持1464默认值，这时还是卡，没有任何起色。手动将MTU值设置为65535，分部访问总部的ERP访问速度和响应速度一下子就上去了，非常流畅！
在咨询3034客服之前，我也咨询过几个客服关于MTU值的问题，得到的答案基本上都是类似于“公网传输数据包的MTU 最大只能1500" 、  “你设置为65535实际上没有效果”之类的话。并且让我两端互ping来测试是否丢包，互ping的时候的确是不丢包的，就算互ping的时候的指定ping包的大小也基本不丢包。
但是我想说，这只是理论，而我所遇到的问题是事实，事实胜于雄辩，Tunnel 0 的MTU为1464时与65535时相比，企业分部与总部之间的内部应用访问速度效果提升是：绝对异常明显的！！
所以，在这里我第一想说感谢3034客服帮我恢复到9.12，这个可以保存手动设置的65535MTU值的版本。第二我想恳请锐捷能够在下一个RGNOS版本中将GRE隧道的Tunnel 接口的这个MTU值改为可以保存用户手动配置的值，比如手动设置为65535，而别再自动恢复理论默认的1464之类的值。
因为今天我遇到的问题的确是：相对与MTU1464的默认值，MTU 65535时的隧道内访问速度是：提升绝对异常明显的！所有的事实，3034号客服可以证明！问题虽解决了，但是他也比较纳闷比较难解释。
我其实很纠结，我想用9.17 2P1 B4的新特性，包括上外网的网速也有一定的提升，但是无奈只能用9.12这个老版本。

标签: 丢包 故障 交互 MTU ping tunnel接口 GRE 锐捷


您对本文的评分:
当前平均分: 7.9(8 次打分)

版权所有：《蚂蚁网-多维人生，三实而立！》 => 《【转】VPN Tunnel 口MTU问题解决》
本文地址：http://www.vants.org/?post=207
除非注明，文章均为 《蚂蚁网-多维人生，三实而立！》 原创，欢迎转载！转载请注明本文地址，谢谢。

« 别具匠心的HTTP应用层行为设计 | HTTP chunked编码异常导致业务下载附件慢故障案例»

评论：

LU
2017-08-14 20:42
楼主在么，回过头来现在怎么看这个问题？
回复
易隐者
2017-08-15 07:04
@LU：已在楼下讨论中明确了这个案例的故障原因
回复
LU
2017-08-15 09:30
@易隐者：原始数据包不允许分片，gre tunnel 的mtu过小的话，gre无法分片数据包，需要丢弃，调大gre tunnel的mtu，gre不对数据包进行分片，只进行封装，提交到底层接口进行转发，底层接口会对数据包进行分片，此时分片的是gre封装后的ip包，支持分片。我猜应该是这个原因。
回复
hgh reviews
2013-03-06 14:58
Magnificent website. Lots of useful information here. I抦 sending it to several friends ans also sharing in delicious. And of course, thanks for your sweat!http://www.hghreleaserreview.com
回复
易隐者
2013-02-04 13:16
感谢所有兄弟的积极参与，此案例的根本原因已明确，可供大家参考学习。
回复
liuquyong
2013-02-04 12:57
关于对VPN Tunnel口加密和分片的处理流程，在Cisco的官网上找了一下。发现有对这有方面的文档，原文链接如下：http://www.cisco.com/en/US/docs/interfaces_modules/services_modules/vspa/configuration/guide/ivmvpnb.html Cisco在对VPN Tunnel口处理的流程为：首先在Tunnel口出方向进行加密，然后传输到物理接口，在物理接口进行分片，对方收到以后进行重组与解密。这个案例中，刚开始的时候Tunnel口的MTU设置为1464，进行VNP传输的时候在Tunnel口按1464进行加密，然后传到物理接口，如果大于物理接口的MTU值刚进行分片，然后传给对方，对方进行重组与解密；如果Tunnel口的MTU设置为65535时，从Tunnel口出时按65535进行加密，然后传到物理接口进行分片，再传给对方，对方进行重组与解密。不论Tunnel口的MTU设置为多大，在物理接口的分片次数是一样的，网络快慢主要和Tunnel口的加解密次数有关。
   上文中，将MTU从1464设置为65535以后，在Tunnel口进行只需要进行一次加密，如果是1464则需要进行65535/1464=45次加密，由于进行45次加密会对VPN设备的CPU造成很大影响，所以在案例中表现的就是网速很慢；改成65535以后在Tunnel口只需要加密一次，所以在整个传输过程中网络很快。
回复
易隐者
2013-02-04 13:15
@liuquyong：此应为正确答案，我已将思科的VPN加解密流程图上传至该案例之前的【说在之前】中，该答案与我们之前讨论分析的结果一致，只是苦于没有明确的文档作为佐证，感谢liuquyong辛苦找到思科 VPN加解密流程相关的文档，让我们明确该故障的确是由于Tunnel口MTU=65535时，加解密次数大大减少导致了ERP性能得到提升。
回复
billjdb
2012-12-25 12:27
看完文章后，感觉应该是GRE Tunnel MTU值与设备物理端口MTU值不匹配造成的。
GRE tunnel MTU值为1464，加上GRE封装24个字节的封装，MTU已达1484；如果物理端口MTU值小于1484，则会导致分片，如果DF设置为1，会导致丢包。
至于为何修改Tunnel MTU值为65535后，访问速度得到提升，估计是tunnel mtu超过1500的设置后，会自动调整MTU大小，比方说取整，调整为1285；这样就不会导致分片或丢包了。
以上分析为个人愚见，见笑了。
回复
易隐者
2012-12-25 14:14
@billjdb：仅站在分片的角度，不好解释业务变慢的情况，因为实际环境中，如果是MTU值导致分片问题引起的故障现象一般都是页面打不开（如包含较大图片等），而不是“异常的卡”。
回复
易隐者
2012-12-25 14:16
@billjdb：另外这里我还有个疑问：如果是个大报文，其在经tunnel封装之后，提交给物理端口转发之前，是否会根据tunnel口的MTU值进行分片处理，然后在交由物理端口转发？不知这位兄弟是否清楚？
回复
billjdb
2012-12-26 12:36
@易隐者：我了解的情况，数据包进入GRE隧道会根据MTU值进行分包；如果MTU设置超过1500，会按1500进行分包。
我猜想的故障原因为：服务器与客户端之间协商MTU值应是大于1464值的，针对UDP协议，如果分包，只有第一个包有完整的端口信息，后续分包是没有的。这样导致进入GRE隧道时，进行分包的UDP包会被客户端无法重组，导致应用无响应。当tunnel MTU值设置为65535时，其实是调整了MTU值为1500，这样当UDP报文进入隧道时就不会再分包了。故网络访问比较流畅。
回复
易隐者
2012-12-26 16:54
@billjdb：1，一般而言，分片操作只会发生在转发出接口上，因此，“数据包进入GRE隧道会根据MTU值进行分包”这个说法是否能够确认？
2，“当tunnel MTU值设置为65535时，其实是调整了MTU值为1500，这样当UDP报文进入隧道时就不会再分包了”，如果真的如此，那么是否说明如果故障现场将tunnel MTU值设为1500会解决这个故障呢？
回复
iejtyq
2012-12-26 23:25
@billjdb：提个疑问.
就楼上这位兄弟说针对UDP协议,如果分片,只有第一个包有完整的端口信息,后续分片处理是没有的,导致进入GRE遂道时,进行分片的UDP包会在客户端无法重组.
我记得数据包分片重组是根据IP的标识及分段偏移量进行重组的.跟四层的UDP端口信息有关系?还是我记错了!!
回复
billji
2012-12-28 23:10
@iejtyq：UDP分包切片后，由于端口信息不全，会导致在网络传输过程中被丢弃（例如经过防火墙按状态连接表进行转发），从而导致客户端无法重组。
我的之前描述不太准确，见笑了。
易隐者
2013-02-04 13:10
@billjdb：此案例的正确答案应该已由回复中的liuquyong兄弟给出，主要原因在于加解密次数的减少导致了ERP交互性能的提升。兄弟可参考，另感谢兄弟对此案例的积极参与。
回复
iejtyq
2012-12-25 00:18
呵呵,老王,不知道我有没有说到点上.
回复
iejtyq
2012-12-25 00:16
阅读完文章后,文章所说把接口设置MTU设置超过1500是否有效？我认为是无效的.以太网接口和特性就决定了它的MTU值了.
我会尝试先从MSS着手排查问题.
MSS决定了C/S业务应用系统两端之间能够传输的最大分组.如果业务系统客户端与服务端两端传输的数据包超过最大传输单元，那么会将数据包进行分片传输。文章所说当接口为mtu为1464很慢，卡！只要一遇到分部客户端与服务器之间有数据交互的时候，就异常的卡，有时软件直接无响应。首先，查看慢的原因是什么？是否因为丢包重传导致的访传达室输慢。wireshark抓包软件一抓并知。如果是因为丢包引起，就接着查看业务交互的数据是否允许进行分片（DF位是否置1），如果不允许分片且数据包超过tunnel接口MTU，那么数据包将会被丢弃。
回复
易隐者
2012-12-25 09:27
@iejtyq：非常赞！常规情况下，我们的确如此入手分析，但是有两点：
1，这个案例中提到的是tunnel隧道MTU，而非物理接口MTU，因此，这个可以设置为超出1500的值；
2，案例中很肯定的提到：在修改tunnel MTU值为65535后，业务访问速度立马得到质的提升，这个如何解释呢?
回复
易隐者
2013-02-04 13:10
@iejtyq：此案例的正确答案应该已由回复中的liuquyong兄弟给出，主要原因在于加解密次数的减少导致了ERP交互性能的提升。兄弟可参考，另感谢兄弟对此案例的积极参与。
回复

发表评论：

Powered by 易隐者 基于emlog 皖ICP备12002343号-1