欢迎关注: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)

应用层保活行为

作者:易隐者 发布于:2012-12-17 10:53 Monday 分类:网络分析

        我之前专门针对TCP保活撰写了一篇较为详细的说明文章——《TCP保活(TCP keepalive)》,在传输层主要通过TCP的保活功能来实现连接的保持,当时我也提到应用层的保活功能,但是应用层的保活功能在实际工作中较为少见,因为如果TCP能够提供保活功能的话,应用层一般就可以利用TCP的保活功能来实现连接的保活,但是毕竟应用层跟传输层是有区别的,一方面并不是所有的应用层会话都需要实现保活功能,另一方面TCP是针对传输层的,一旦开启TCP保活功能,将对所有基于TCP的应用产生影响,这些影响可能会是负面的,如我博客里的案例:《由TCP保活引起的业务访问故障案例》,这也是运维管理者不愿意看到的,因此,有些应用自行设计自己的应用层保活行为。

       近期在用户的工作环境中,看到了如下图所示的应用层交互行为: 

点击查看原图

       大家可以清晰的看到,这个交互过程具有以下行为特征:
1, 客户端每间隔固定时间(30秒)发出同样的请求;
2, 每次交互的报文都是一致的(客户端的请求、服务器的响应、报文长度等);

       个人认为这些行为特征足以证明该交互过程是应用层设置的应用连接保活探测行为。

阅读全文>>

标签: TCP 明文 故障 运维管理 保活 行为特征 TCP保活 应用保活

评论(0) 引用(0) 浏览(5901)

Juniper IVE设备抓包方法

作者:易隐者 发布于:2012-10-19 10:31 Friday 分类:参考资料

        Juniper IVE VPN设备具有自带的抓包功能,在管理员登录上管理平台之后,在IVE设备管理界面的“Maintenance > Troubleshooting  > Tools > TCP Dump”中可以看到相关的抓包设置选项,如下图所示: 

点击查看原图

       这里的抓包设置选项都很简单,大家一看基本上都能明白,需要说明的是,这里的“Filter”设置选项,可以使用tcpdump的过滤语句对所需要捕获的报文进行过滤。

       在点击“Start Sniffing”开启“TCP Dump” 抓包,在等待故障出现之后,可再次通过“Maintenance > Troubleshooting > Tools > TCP Dump”界面,点击“Stop Sniffing”,停止抓包,如下图所示: 

点击查看原图

      在停止抓包之后,IVE会将捕获的数据报文保存为一个抓包文件,显示在“Dump file”界面下,如下图所示:

点击查看原图

       IVE保存的数据包文件提供三种格式文件的下载,分别为:Raw、SSL Dump、Human Readable(一般我们下载默认的“Raw”格式,因为Raw格式可以使用wireshark直接打开分析),我们点击“Get”,下载RAW格式的文件即可。

阅读全文>>

标签: TCP wireshark tcpdump 故障 抓包 Juniper IVE troubleshooting

评论(0) 引用(0) 浏览(12051)

iPhone与Multicast DNS

作者:易隐者 发布于:2012-9-21 20:58 Friday 分类:案例讨论

        前两天看到CSNA论坛上有一个求助帖,原帖连接为:http://www.csna.cn/network-analyst-49133-1-1.html,故障现象大致为:网络经常出现断网情况,抓包发现断网时有大量的DNS包,楼主认为是IPHONE或IPAD在连接公司无线网络时出现的数据包。

       我下载了其数据包文件,并选其中的一个数据包文件进行了大致的分析:
1, 在数据包视图中查看其发包频率,如下图: 

点击查看原图

在1秒的时间内 发送了15542个IPv6的多播报文,这种发包频率,足以影响相关无线路由、交换机等设备的处理性能,而接收方对多播报文的处理流程决定了过多的多播报文对网络和主机的影响,大家可参考本人个人博客中《基于UDP组播实施分片攻击的可能性》一文。

2,我们查看其详细解码: 

点击查看原图

IPV6封装UDP 5353端口的DNS请求行为,经网络搜索相关信息,确认为Multicast DNS(组播DNS)报文;

       经查阅相关资料,苹果系列产品在本地局域网内缺少DNS服务器的环境下,使用Multicast DNS,实现名字和IP地址的解析,每个主机都知道自己的名字,并且会自动响应来自多播报文中针对该名字的请求。 使用Multicast DNS的设备大致工作过程如下:

1,在“.local.”子域下,挑选所需的名字;
2,使用Multicast DNS进行名字查询,看是否有主机已经使用了这个名字;
3,如果收到来自与其他主机的名字解析响应,则在“.local.”子域下重新选择一个名字,直至确认本地局域网内无其他设备使用该名字为止。

       大家可参考苹果支持主页中关于“Multicast DNS”的相关页面:http://support.apple.com/kb/TA20999?viewlocale=en_US

       这些都明确说明这个报文是iPhone发出的Multicast DNS报文,但是异常之处在于设备发包的频率太快了,而楼主反馈说,“不是每次连接都出现这个问题,只是偶尔会出现”,这也从侧面说明这个异常行为应该是属于iPhone本身跟“Multicast DNS”有关的进程异常导致的,可能是iPhone的BUG亦未可知。

       我在搜索相关信息的时候,竟然找到了一篇跟MAC OS相关的DNS异常问题的帖子,应该属于相关内容了,感兴趣的可以自行查看下面连接:http://blog.sina.com.cn/s/blog_539a3a320100q5dq.html

阅读全文>>

标签: 交换机 分片 解码 故障 UDP 多播 DNS iPhone Multicast DNS 多播DNS 组播DNS IPv6

评论(0) 引用(0) 浏览(14780)

一切皆有可能

作者:易隐者 发布于:2012-9-18 17:11 Tuesday 分类:网络分析

       由于故障现场环境的复杂性、设备的多样性、系统本身的不稳定性以及网络运行情况的不确定性,一个故障的产生,可能存在各种各样的原因,有些甚至超乎我们平日的想象。而我们在遇到疑难故障时,经常会主观的认为设备是不会出问题的、运营商是不可能出问题的、业务程序是不存在问题的……但是,事实上,这些都有可能是导致故障产生的根源所在。我们在分析、定位、解决故障的过程中,一定要在严密推理的情况下大胆假设,站在网络交互的本质层面小心求证。

       我们要明白,在网络的世界里,一切皆有可能发生!

阅读全文>>

标签: 疑难故障 故障 稳定 交互 业务

评论(0) 引用(0) 浏览(7385)

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