回溯分析帮助解决用户网络环路故障
- 格式:pdf
- 大小:958.35 KB
- 文档页数:11
CSNA网络分析论坛,网络分析技术学习、交流、分享平台
推荐下载:《网络分析案例集2012》、《网络通讯协议图》、《网络故障诊断图》更多资料请登录
环路分析
故障描述
故障背景
一天,一个客户打电话说他们部门的内网阶段性掉线,而且频率很高,访问外网非常慢,ping网关,时通时不通,延时较大,部门所有机器都是类似情况!初步判断,有可能是内网异常流量占用,或者广播风暴之类的故障!还好,客户在使用科来回溯产品,可以保存数据,以便于现在回放“录像”。
简单描述一下网络拓扑,比较简单,只是一个部门网络,汇聚交换机——二层交换机——用户。
抓包位置,汇聚交换机作镜像,镜像端口接科来回溯分析系统。
网关地址:192.168.10.1
选取时间为28s,总流量16.312M,速率也是比较大的(如图)!概要统计
下载数据包分析
端点视图:
广播和组播流量比较大,几乎占了总流量的98%。
先前的判断的方向是对的!而且还有两个无效地址0.0.0.0,169.254.134.187,没有获取到地址,忘了说了,地址都是自动获得的!
看了协议视图,豁然开朗
是dhcp 和netbios在作怪!
结合dhcp 和netbios的联动性(见注释1),初步确定是dhcp在作怪了,正是由于dhcp的缘故,所以出现了169.254.x.x和0.0.0.0这样的地址。
DHCP的工作原理(见注释2),现在我们只说第一次登录的时候。
根据客户端是否第一次登录网络,DHCP 的工作形式会有所不同。
我们只说第一次登录的时候,当DHCP 客户端第一次登录网络的时候,也就是客户发现本机上没有任何IP 数据设定,它会向网络发出一个DHCP discover 封包。
因为客户端还不知道自己属于哪一个网络,所以封包的来源地址会为0.0.0.0 ,而目的地址则为255.255.255.255 ,然后再附上DHCP discover 的信息,向网络进行广播。
在Windows 的预设情形下,DHCP discover 的等待时间预设为1 秒,也就是当客户端将第一个DHCP discover 封包送出去之后,在1 秒之内没有得到响应的话,就会进行第二次DHCP discover 广播。
若一直得不到响应的情况下,客户端一共会有四次DHCP discover 广播(包括第一次在内),除了第一次会等待1 秒之外,其余三次的等待时间分别是9、13、16 秒。
如果都没有得到DHCP 服务器的响应,客户端则会显示错误信息,宣告DHCP discover 的失败。
Windows操作系统预设,客户端如果学不到地址,系统自动会把一个169.254.x.x分配给它。
之后,基于使用者的选择,系统会继续在5分钟之后再重
复一次DHCP discover 的过程。
这是数据包0.0.0.0的解码图,是mac地址为00:0f:b0:72:ba:8c发送的广播包,在进行dhcp discover
这是数据包169.254.134.187的解码图,是mac地址为00:0f:b0:72:ba:8c 发送的组播包
说明是同一个客户端00:0f:b0:72:ba:8c 发出的数据包,可是为什么没有学到地址呢?又为什么会产生如此大的流量呢?
带着这个疑问我们继续分析:首先定位DHCP包,深入分析。
这是00:0f:b0:72:ba:8c 发出的数据包
是dhcp discover 包,向服务器请求地址,大家看,标签53是“dhcp报文类型”的标签,消息类型为1说明dhcp discover包,在向服务器请求地址。
再看192.168.10.1发的包
大家再看标签类型为53的“消息类型”,为2,说明是dhcp server发的dhcp offer包,说明服务器给00:0f:b0:72:ba:8c 分配192.168.10.9的地址了,那为什么会有如此多的数据包呢?
我们接着分析!既然服务器为00:0f:b0:72:ba:8c提供了地址,说明它收到了00:0f:b0:72:ba:8c的discover包,那就说明服务器没有问题以及他们之间的网络通信是好的,难道问题出在00:0f:b0:72:ba:8c上?
让客户先把00:0f:b0:72:ba:8c关了,看看现象。
问题依然存在!看来问题不在它身上!
既然服务器和客户机以及他们之间的链路是畅通的,那问题一定出在中间设备上。
难道是网络中存在环路?看来只能先分析一下数据包再说!
定位到dhcp协议,看dhcp事物id和ip的标识id
dhcp事物id如下:
竟然是同一个事物id,就是说是同一个事件的的数据包,看来真的有可能存在环路了。
为了证明以上观点,再看ip identify id:
接着再看TTL,看是否存在路由环路:
TTL值没有变,说明不是路由环路,那就是交换机的问题了。
随后让客户检查交换机。
结论,没有发现环路,这是怎么回事?
思索中。
难道是交换机出了故障,让换之测试。
郁闷,问题还存在!
就在我边郁闷边思索时,客户在一个犄角旮旯里发现了一个布满灰尘的sohu 交换机串在pc和交换机之间!
我大喜过望,罪魁祸首出来了。
令其去掉该设备,网络正常了。
可是客户仔细查看了该sohu交换机,并没有打环的迹象!
继续思索着。
突然想起某天某月某日某点某分在internet上看到某位高人写到:有时一些soho交换机会无缘无辜对收到的数据包进行无限转发。
又一次无语了。
问题解决了,思路似乎也比较清晰了,希望可以提醒以后遇到这种情况的同志不要忽视类似的小东东。
注释1:dhcp 和netbios的联动性
注释2:dhcp报文类型(选项53)取值的含义:
类型为1:dhcp discover 此为client开始DHCP过程中的第一个请求报文
类型为2:dhcp offer 此为server 对dhcpdiscover 报文的响应
类型为3:dhcp request 此为client 对dhcpoffer 报文的响应
类型为4:dhcp decline 此为当client发现server 分配给它的IP地址无法使用,如IP地址发生冲突时,将发出此报文让server禁止使用这次分配的IP地址。
类型为5:dhcp ack 此为server对dhcprequst 报文的响应,client
收到此报文后才真正获得了IP地址和相关配置信息。
类型为6:dhcp nack 此为server对client的dhcprequst报文的拒绝响应,client 收到此报文后,一般会重新开始DHCP过程。
类型为7:dhcp release 此报文是client主动释放IP地址,当server 收到此报文后就可以收回IP地址分配给其他的client.
类型为8:dhcp inform 此为如果客户通过别的手段获得了网络地址,它可以使用DHCPINFORM请求获得其它配置参数,服务器接收到DHCPINFORM包,并建立一个DHCPACK消息,在其中包括一些合适客户的配置参数,只是不包括分配网络地址,检查现有的绑定,在信息中不填充'yiaddr'字段或租用时间参数。
服务器取得DHCPINFORM包内的'ciaddr'地址,而返回DHCPACK包。
详情请参照DHCP 协议之RFC 文件
CSNA网络分析论坛 11 / 11。