欢迎关注: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) 浏览(38723)

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