长沙哪个足浴美女:到底是不是交换机打环？-一次典型的案例

最近碰到一个典型案例，发表出来和大家一起分享，有什么说的不对的地方，希望大家多包涵，宗旨是共同进步，主要和大家分享解决问题的思路。。。    该问题是通过和客户电话沟通解决得！
    一天，一个客户打电话说他们部门的内网阶段性掉线，而且频率很高，访问外网非常慢，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数据设定，它会向网络发出一个 DHCPdiscover封包。因为客户端还不知道自己属于哪一个网络，所以封包的来源地址会为 0.0.0.0，而目的地址则为255.255.255.255，然后再附上DHCPdiscover的信息，向网络进行广播。在Windows的预设情形下，DHCPdiscover的等待时间预设为 1秒，也就是当客户端将第一个 DHCPdiscover封包送出去之后，在 1秒之内没有得到响应的话，就会进行第二次DHCPdiscover广播。若一直得不到响应的情况下，客户端一共会有四次DHCPdiscover广播(包括第一次在内)，除了第一次会等待 1秒之外，其余三次的等待时间分别是9、13、16秒。如果都没有得到DHCP服务器的响应，客户端则会显示错误信息，宣告 DHCPdiscover的失败。
    Windows操作系统预设，客户端如果学不到地址，系统自动会把一个169.254.x.x分配给它。之后，基于使用者的选择，系统会继续在 5 分钟之后再重复一次 DHCPdiscover 的过程。
    这是数据包 0.0.0.0 的解码图，是 mac 地址为 00:0f:b0:72:ba:8c 发送的广播包，在进行 dhcpdiscover

    这是数据包169.254.134.187的解码图，是mac地址为00:0f:b0:72:ba:8c发送的组播包

    说明是同一个客户端00:0f:b0:72:ba:8c发出的数据包，可是为什么没有学到地址呢？又为什么会产生如此大的流量呢？
    带着这个疑问我们继续分析：首先定位DHCP包，深入分析。。。
    这是 00:0f:b0:72:ba:8c 发出的数据包

    是dhcpdiscover包，向服务器请求地址，大家看，标签53是“dhcp报文类型”的标签，消息类型为1说明dhcpdiscover包，在向服务器请求地址。
    在看192.168.10.1发的包

    大家再看标签类型为53的“消息类型”，为2，说明是dhcpserver发的dhcpoffer包，说明服务器给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，就是说是同一个事件的数据包，看来真的有可能存在环路
    为了证明以上观点，再看ipidentifyid：

    接着再看TTL，看是否存在路由环路

    TTL值没有变，说明不是路由环路，那就是交换机的问题了。。。
    让客户检查交换机中。。。。
    结论，没有发现环路，无语。。。
    思索中。。。
    难道是交换机出了故障，让换之测试。。。
    郁闷，问题还存在！
    就在我边郁闷边思索时，客户在一个犄角旮旯里发现了一个布满灰尘的sohu交换机串在pc和交换机之间！
    我大喜过望，罪魁祸首出来了。。。令其去之！网络正常了。
    可是客户仔细查看了该sohu交换机，并没有打环的迹象！
    继续思索着。。。
    突然想起某天某月某日某点某分在internet上看到某位高人写到：有时一些soho交换机会无缘无辜对收到的数据包进行无限转发。。。又一次无语了。。。
    问题解决了，思路似乎也比较清晰了，希望可以提醒以后遇到这种情况的同志不要忽视类似的小东东。。。
    注释 1 ： dhcp 和 netbios 的联动性

    注释2：dhcp报文类型（选项53）取值的含义：
    类型为1：dhcpdiscover 此为client开始DHCP过程中的第一个请求报文
    类型为2：dhcpoffer 此为server对dhcpdiscover报文的响应
    类型为3：dhcprequest 此为client对dihcpoffer报文的响应
    类型为4：dhcpdecline 此为当client发现server分配给它的IP地址无法使用，如IP地址发生冲突时，
    将发出此报文让 server 禁止使用这次分配的 IP 地址。
    类型为5：dhcpack 此为server对 dhcprequst报文的响应，client收到此报文后才真正获得了IP地
    址和相关配置信息。
    类型为6：dhcpnak 此为server对client的dhcprequst报文的拒绝响应，client收到此报文后，一般
    会重新开始DHCP过程。
    类型为 7 ： dhcprelease 此报文是 client 主动释放 IP 地址，当 server 收到此报文后就可以收回 IP 地址
    分配给其他的client.
    类型为 8 ： dhcpinform 此为如果客户通过别的手段获得了网络地址，它可以使用 DHCPINFORM 请求获
    得其它配置参数，服务器接收到 DHCPINFORM 包，并建立一个 DHCPACK 消息，在其中包括一些合适客
    户的配置参数，只是不包括分配网络地址，检查现有的绑定，在信息中不填充'yiaddr'字段或租用时间参数。
    服务器取得 DHCPINFORM 包内的 'ciaddr' 地址，而返回 DHCPACK 包。
    详情请参照DHCP协议之 RFC文件

ps：讲的不错，结合案例，与大家分享