蚂蚁网-多维人生，三实而立！

IDS异常导致业务访问故障的案例

作者：易隐者 发布于：2013-3-29 16:46 Friday 分类：案例讨论

【说在之前】：

1，这个是以前我在某个商业银行解决的疑难故障，其中IDS设备出现异常，将原先捕获到的原始数据包通过交换机的镜像口回放至交换机，而交换机的镜像端口并未关闭MAC地址学习功能，引起业务服务器交换机MAC表混乱，导致业务服务器的访问出现异常；

2，这是一个非常少见的疑难故障，因此值得大家学习参考；

3，这段时间由于我个人的规划，工作会作出一些变动，杂事较多，有段时间未在博客中更新新的文章，还望各位兄弟见谅，就将这篇老文作为我三月份博客的更新吧。

【案例全文】：

        前段时间晚上，接到某单位朋友电话，说是其一核心业务系统白天出现了故障，很长一段时间没有解决，现在很多厂家工程师都在，让我过去增援一下，明确定位一下故障的原因所在。于是赶紧打的到现场。下面我把故障的情况描述一下：

故障拓扑

        经过简化的网络拓扑如下： 

 故障现象

       核心业务访问异常，业务出现中断现象，使用测试pc直接接入业务服务器交换机，设置为服务器同网段IP，在使用ping测试服务器，不通。

故障分析

       故障时，交换机MAC表出现异常，主要表现为交换机端口镜像的目的口上，出现了防火墙ETH2口的MAC地址和核心服务器的MAC地址，导致核心业务访问出现异常。

分析业务交换机MAC表异常的原因：

       交换机MAC表学习的过程为源地址学习，H3C交换机在做端口镜像时，镜像目的端口默认是可以参与网络数据转发的，那么在交换机端口镜像的目的口上出现了防火墙E2口的MAC和业务服务器的MAC，只能说明该端口上收到了源MAC为防火墙E2口和业务服务器的报文，但是作为与IDS监听口相连的端口镜像目的口，通常情况下是不可能收到任何报文的，因为IDS监听口只是被动监听发过来的报文，而不会主动向网络内发送任何的报文。

这里我们大胆猜想一下：

 故障解决的方式：

       关闭交换机端口镜像目的端口的MAC地址学习功能。这样即使该端口接收到大量的相关报文，其也不会影响交换机正常的MAC地址表项。

阅读全文>>

标签: 端口镜像 疑难故障 MAC表 IDS

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

某公司业务系统经ISA防火墙访问正常而经硬件防火墙访问慢故障分析解决案例

作者：易隐者 发布于：2013-1-25 10:10 Friday 分类：案例讨论

1 故障环境

      这个故障产生的环境较为简单，我们在不影响故障分析的前提下，简化分析网络环境，其故障发生的拓扑结构大致如下所示：

1.1 网络拓扑

1，业务服务器的IP为16.66.252.249/24，网关为16.66.252.254；

2，测试客户端的IP为16.66.180.167/24，网关为16.66.180.1；

3，防火墙与服务器相连的接口地址为16.66.252.254，防火墙与测试客户端相连接口的地址为16.66.180.1；

4，防火墙工作在纯路由模式下；

1.2 业务访问流程

2，测试客户端将数据报文经过硬件防火墙转发至业务服务器端，业务系统根据测试客户端的相关请求，返回业务应用数据报文经硬件防火墙转发给测试客户端；

2 故障现象

       经过与用户的交流和现场的测试，确定故障现象主要表现为以下几点：

1，客户端经过ISA访问业务服务器，测试连接速度非常快；

2，将ISA换成天融信硬件防火墙，硬件防火墙工作在纯路由模式下，测试发现客户端连接业务服务器的大概需要消耗20秒左右的延时；

3，用户反馈，测试过使用cisco的ASA和H3C的硬件防火墙，均有不同程度的较大的连接延时；

3 故障分析

3.1 分析过程

3.1.1 确认是否是硬件防火墙产生的延时

       经过ISA防火墙，业务系统连接测试一切正常，速度很快，但是经过硬件防火墙（TOPSEC/CISCO/H3C）之后，就产生了较大的延时，那么看起来似乎是硬件防火墙产生的延时，我们先从这个角度入手，在测试客户端与业务服务器端同时抓包做对比分析，用于确认是否是硬件防火墙产生的转发延时。

 这个延时不是硬件防火墙产生的，而是业务系统应用产生的。

3.1.2 分析经过ISA防火墙时的业务交互情况

       既然这个延时是业务应用本身产生的，跟硬件防火墙完全无关，那么为什么经过ISA访问的时候，连接测试一切正常呢？

5，应用测试连接成功，客户端主动通过TCP四次握手过程，正常释放TCP连接；

       上述过程清晰的展示了客户端在经过ISA访问服务器时，应用连接建立的时间是非常短的，速度非常快。

3.1.3 分析经过硬件防火墙时的业务交互情况

 NBNS解析成功后，服务器端才向客户端发送应用层连接请求响应数据报文；

 4，通过上图的数据交互情况分析，我们可以得出以下两点结论：

 17秒的延时，就是服务器4次DNS反向解析失败产生的。

3.2 分析结论

       通过上面一系列的分析，我们可以确定，导致该故障产生的核心原因是业务系统程序的处理机制异常导致的。

4 故障解决

       我们知道了经过硬件防火墙访问业务系统变慢的原因是因为业务服务器在接收到客户端的应用请求时，需要针对客户端的IP地址做一个反向名字解析，那么我们可以通过在业务服务器的hosts列表中添加客户端的IP对应的主机名，以此来避开服务器的反向DNS名字解析过程，从而解决了业务系统慢的问题。此方法已经现场测试验证有效。

阅读全文>>

标签: 疑难故障 防火墙 DNS ISA

评论(7) 引用(0) 浏览(10906)

【转】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) 浏览(38769)

HTTP chunked编码异常导致业务下载附件慢故障案例

作者：易隐者 发布于：2012-12-18 9:32 Tuesday 分类：案例讨论

故障现象

       某业务应用系统基于B/S架构开发，其应用页面打开正常，但是该应用在下载附件时，速度非常慢。

故障分析

       在下载附件很慢时，在服务器上捕获客户端与服务器业务交互的报文。其TCP会话交互的情况如下图所示： 

       我们首先分析客户端与服务器三次握手建立连接的情况，查看客户端、服务器协商的MSS值是否正常，我们首先查看客户端SYN报文，其TCP MSS协商为1460，如下图所示： 

       接下来查看服务器SYN/ACK报文，其TCP MSS也为1460，如下图所示： 

       这说明双方协商的MSS值不存在问题，另服务器对客户端的get请求的第一个应用响应报文长度为248B，如下图所示： 

       这也充分说明业务服务器在给客户端发送报文时并不是一直只能发送9字节的报文。那么是什么原因导致业务服务器突然之间只能每次发送9字节的应用层数据呢？

       我们注意到服务器给客户端的第一个HTTP应用响应报文，如下图所示： 

        其Transfer-Enconding是chunked。

        HTTP为什么会使用chunked传输编码？我直接引用《HTTP1.1中CHUNKED编码解析》一文中的描述来说明：“一般HTTP通信时，会使用Content-Length头信息性来通知用户代理（通常意义上是浏览器）服务器发送的文档内容长度，该头信息定义于HTTP1.0协议RFC  1945  10.4章节中。浏览器接收到此头信息后，接受完Content-Length中定义的长度字节后开始解析页面，但如果服务端有部分数据延迟发送吗，则会出现浏览器白屏，造成比较糟糕的用户体验。
        解决方案是在HTTP1.1协议中，RFC  2616中14.41章节中定义的Transfer-Encoding: chunked的头信息，chunked编码定义在3.6.1中，所有HTTP1.1 应用都支持此使用trunked编码动态的提供body内容的长度的方式。进行Chunked编码传输的HTTP数据要在消息头部设置：Transfer-Encoding: chunked表示Content Body将用chunked编码传输内容。根据定义，浏览器不需要等到内容字节全部下载完成,只要接收到一个chunked块就可解析页面.并且可以下载html中定义的页面内容,包括js,css,image等。”

        “Chunked编码一般使用若干个chunk串连而成，最后由一个标明长度为0的chunk标示结束。每个chunk分为头部和正文两部分，头部内容指定下一段正文的字符总数（非零开头的十六进制的数字）和数量单位（一般不写,表示字节）.正文部分就是指定长度的实际内容，两部分之间用回车换行(CRLF)隔开。在最后一个长度为0的chunk中的内容是称为footer的内容，是一些附加的Header信息（通常可以直接忽略）。”

       《HTTP1.1中CHUNKED编码解析》一文中使用了下图作为chunked解码的示意： 

       通过这张示意图，我们可以清晰的了解到，chunked解码主要由2块组成，一块为指定数据块长度，以\r\n回车换行作为结束符，另一块为实际的应用数据，也以\r\n回车换行作为结束符。
       知道了chunked解码的组成，我们再来看看业务服务器给客户端发送的应用层长度仅9字节的报文解码： 

       根据这9个字节的应用字段解码，我们将其十六进制换算为正常的十进制，如下表所示：

        我们根据上图即可解码服务器发往客户端的chunked编码报文，其意义为：
1，指明长度为0001，即为1字节；
2，该报文真正的应用数据仅为1字节的“R”！

       服务器每次仅传输一个字节给客户端！其报文的有效载荷率仅为：   1/63=0.015873015873015873015873015873016！
       如果客户端下载一个1MB大小的附件，服务器端将产生1*1024*1024=1048576个报文，如果客户端每个报文都确认的话，一个下载将产生1048576次交互，即使往返时间RTT值非常小，再乘以1048576的基数之后，也将是个难以接收的数值。
       如此，我们终于明白下载附件慢的原因了。

分析结论

       此为业务服务器HTTP chunked编码传输时，自己指定的数据块长度值太小（为1字节）导致的故障。

参考文档

1，《HTTP1.1中CHUNKED编码解析》
2，RFC 2616《超文本传输协议》

阅读全文>>

标签: 疑难故障 MSS RTT 往返时间 HTTP chunked编码 交互次数

评论(3) 引用(0) 浏览(12042)

可能的URL超长导致丢包案例

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

       上周五，有网友兄弟给我发了一个报文，让我帮忙查看是否存在什么异常问题。我查看其TCP会话交互过程，如下图所示： 

       单从这个报文交互来看，客户端与服务器的TCP连接建立正常，客户端已经向服务器发送过get请求，并得到了服务器的确认，问题出在客户端向服务器发送的第二个get请求：“
http://192.168.0.12/Default_Login.aspxusercode=x6x9&password=81xx9xxx52x04xx20036xxx8313xx055&

MyCurrentCompany=&rdnum=0.5966797953405811”。

       客户端发出这个get请求之后，在37秒的时间内重传了5次，服务器端无应用数据需要主动的发给客户端，因此在这个时间段内我们未见来自于服务器的报文，而如果客户端的发送的这个get请求到达了服务器端，则服务器会根据其请求内容作出应用响应，最起码服务器端会对客户端的TCP报文发送ACK确认。但是这些都没有出现，这能够说明客户端的get请求报文根本未到达服务器端，即客户端的这个get请求报文被中间设备丢弃了，我们查看客户端的发送的第二个get请求报文的解码：

       我们发现这个报文除了其请求的URL长度较长（420字节）外，其他似乎也没什么特别的，因此，个人推测其被中间设备丢弃的原因可能是其URL超出了防火墙/负载均衡/WAF/IPS等设备的限制，或者是URL中包含“uesr”、“password”等敏感字段而被中间设备丢弃了。

阅读全文>>

标签: TCP 负载均衡 解码 ACK确认 防火墙 IPS get URL超长 get请求

评论(3) 引用(0) 浏览(6534)