[案例分析] 一次典型的案例

本来写了一个pdf想传上来，结果超过最大尺寸了，于是乎一点一滴弄上来。。。
最近碰到一个典型案例，发表出来和大家一起分享，有什么说的不对的地方，希望大家多包涵，宗旨是共同进步，主要和大家分享解决问题的思路。。。
该问题是通过和客户电话沟通解决得！
一天，一个客户打电话说他们部门的内网阶段性掉线，而且频率很高，访问外网非常慢，ping网关，时通时不通，延时较大，部门所有机器都是类似情况！初步判断，有可能是内网异常流量占用，或者广播风暴之类的故障！
简单描述一下网络拓扑，比较简单，只是一个部门网络，路由器——二层交换机——用户。抓包位置，路由器和交换机间串联HUB，科来接HUB！网关地址：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 对dihcpoffer 报文的响应
类型为4：dhcp decline    此为当client发现server 分配给它的IP地址无法使用，如 IP地址发生冲突时，将发出此报文让server禁止使用这次分配的IP地址。
类型为5：dhcp ack       此为server对 dhcprequst 报文的响应，client收到此报文后才真正获得了IP地址和相关配置信息。
类型为6：dhcp nak       此为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 文档。
本来写了一个pdf想传上来，结果超过最大尺寸了