欢迎关注:1，欢迎关注本博客，你可点击右手边的【QQ邮件订阅】订阅本博客！2，本博客推出江湖救急计划，主要为工作中遇到疑难杂症的兄弟提供远程技术支持和分析，如有需要，请在江湖救急计划页面给我留言！

【转】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 锐捷

评论(19) 引用(0) 浏览(39813)

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