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

Netscout 的KFP分析方法论

作者:易隐者 发布于:2012-10-25 9:46 Thursday 分类:网络分析

        Netscout有一个非常知名的应用性能管理的分析理论—— KFP分析方法论

        所谓“KFP”就是“KPI-Flow-Packets”,我在网上搜集诸多关于Netscout的KFP分析方法的资料,下面是我摘录的一些描述KFP的图表: 

点击查看原图

点击查看原图

点击查看原图

点击查看原图

        这些图表将KFP的工作方式做了直观的展示。再加上一段netscout针对KFP的描述:

"The KPI-to-Flow-to-Packet Approach
NetScout’s products leverage deep packet inspection technology to deliver complete visibility into real-time operational intelligence spanning high-level KPIs (Key Performance Indicators) and early warning all the way down to actual packets, enabling IT organizations to reduce MTTR. The nGenius Solution provides  an from key performance indicators (such as response time or errors) to application flow data (such as utilization, conversations or top talkers) and then to packet-level details – if necessary. This “KPI-to-Flow-to-Packet” approach allows you to delve as only deeply as required to effectively manage and troubleshoot your network and application performance. "

        综合这些相关资料的描述,KFP方法论主要利用Netscout系列产品进行核心业务应用性能分析管理的方法:

K:KPI

       其主要确定各种核心业务应用的关键性能指标(根据不同应用的特点,其KPI的选择有所差异),如HTTP应用的KPI主要有:响应时间、响应成功率;VOIP应用的KPI主要有:丢包率、语音质量等。
Netscout产品统计计算出各个应用在交互过程中的KPI值,并且根据这些KPI值制定相应的告警条件,提前预警业务应用的性能问题,反应业务应用的性能情况。

F:Flow

       在Netscout发出告警之后,用户接下来可以利用Flow进行进一步的分析,包括利用率、会话、最差性能等,发现跟告警相关的具体会话、应用、服务等。

P:Packet

        最终站在数据包交互的角度,分析具体数据报文的细节,定位问题根源。

       KFP方法论的思路固然可以通用,但是具体到实现的效果,估计只有Netscout的产品能够完美的体现出来,毕竟这个是Netscout提出来的。

阅读全文>>

标签: Netscout 丢包 响应时间 预警 交互 应用性能 packet KPI Flow KFP VOIP MTTR

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

一切皆有可能

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

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

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

阅读全文>>

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

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

TCP交互式应用

作者:易隐者 发布于:2012-8-30 21:29 Thursday 分类:网络分析

       TCP交互式应用由于其交互的特性,一般对时延的要求较高,因此一旦有应用数据时便立即向对端发送并要求对端能够及时处理,其交互的报文基本上都是小包(小于MSS),常见的TCP交互式应用主要有telnet、rlogin、互动游戏等,我们先来看一个TCP交互应用的报文分析:

点击查看原图

其具有以下三个明显特点:

1,客户端与服务器端的数据传输是交互式进行的;

2,应用字段长度均较小;

3,带有应用字段的TCP报文PUSH位均置一。

TCP交互式应用的场景(以游戏为例):

       对于实时网络游戏这种交互应用,如果TCP接收方不立即将应用数据提交应用程序处理的话,很可能会导致游戏应用出现卡、客户端与服务器端不同步故障,严重影响游戏应用的正常运行。你想啊,你在玩CS,扮演警察,突然一个悍匪跟你正面冲突,悍匪那边快速操作已经移动位置了,但是悍匪移位这个应用信息却被你的TCP放在接收缓存里,你机器显示器上看到的悍匪还在原来的位置,然后你自然向悍匪原来的位置开枪,结果呢,肯定没伤到悍匪,却被早就移位的悍匪爆头击毙,这时候你会爽吗?肯定骂死这个游戏应用了,呵呵。
        那么交互式应用如何保证应用字段能够被立即处理呢答案就是将带有应用字段的TCP报文(不论应用字段大小)的PUSH位全部置一,虽是小包,但TCP一旦接收到便立即将其交付应用程序处理。

       我在08年做内部《TCPIP详解卷一》培训在讲到第19章《TCP的交互数据流》时,曾今专门捕获了WAR 3的局域网游戏的交互报文,用于讲解TCP交互式应用的特性,现在把这个报文一并放在此供各位参考。

WAR 3的局域网游戏的报文:

点击查看原图

        交互式应用并不是非常常见,因此经常被大家忽略,导致有时在遇到交互应用场景的分析时,将其当作HTTP等常见应用的特性来进行分析,可想而知,如此将走向错误的分析方向,望各位兄弟姐妹引以为鉴。

        这里提到了TCP报文的一个非常重要的标志位——PUSH,我下一篇文章将会针对PUSH位做一个详尽的讨论和分析,望大家关注。

阅读全文>>

标签: 同步 TCP 应用字段 故障 push 交互式应用 交互

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

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