一些工作的排错

工作面试需要这几天整理一下之前的一些网络排障，也算是一个总结，后续还会更新，大概情况如下：

一:福州某酒店项目运维过程中无线AP出现无规律性下线。

排查过程：
1：在接收到客户反馈的问题后，我们先去了解了客户的现场拓扑情况，AC与AP是不同网段，AC旁挂与核心交换机旁，DHCP地址池在核心交换机上。
2：通过登录到AC设备，发现有近一半的AP不在线，我们记录了其中一个AP的mac地址，经现场运维人员配合查找到AP的位置。
3：连接AP默认的SSID信号，登录到AP的web界面，发现AP是有获取到ip地址的（192.168.0.34）；由于AC与AP是跨3层通信，我们继续检查了一下option43的地址，发现没有获取到。这样的情况有可能是这个广播域中存在另一个DHCP服务器。
4：在接入AP的交换机上接入一台pc，打开DHCP获取地址，同时通过wireshark抓包，发现有2份request报文发来，证实了我的猜测。
5：AP获取到的地址是192.168.0.X这个网段的，很可能是下面用户私接tp-link等家用路由器导致的。向客户反馈并提出解决方案，在核心交换机以及下联交换机上配置DHCP snooping，信任与dhcp服务器上联接口，解决此问题。

二：上海某私企客户反馈：AP掉线，有时候一个AP掉，有时候一批同时掉，掉线过后大概10分钟左右又会上线，然后过一段时间（不固定）又会掉线，然后再上线。

1：收到客户反馈后，首先登录到客户AC去查看log，发现与客户反馈情况一致，掉线原因没有具体显示。
2：起初我怀疑是物理层或者硬件供电问题，通过与客户沟通，连接AP线缆都是超5类线缆，从poe交换机到AP大概距离都是30-50米，并且通过查看AC的log信息，发现并不是一个交换机下的AP或者某几个AP出现这样的问题。
3：继续检查AC的log信息发现掉线型号为T22D，客户现场是有2款AP型号，另一款T22C并没有出现掉线的情况。
4：连接AP的信号，登录到AP的web界面，检查软件版本不是最新的版本（具体有点忘记是哪个版本了），然后通过与公司研发，测试对接，给出结果这个软件版本存在CPU使用率过高，AP会自动重启。
5:通过与客户沟通了解到，客户现场一个办公室大概会有30人，只有一个AP，由于此AP大概能支撑35人左右的使用，是有可能会导致这个问题。
6:给出解决方案：通过更新最新的软件版本可临时解决此问题，同时建议客户更换新的或者性能更强的AP解决。

三：上海某单位，组播业务异常，现场大屏出现花屏现象。

客户反馈：核心使用2台3956设备堆叠，接入是2952C，每一台接入交换机上都有RX和TX设备。如果RX和TX只通过一台2952C互联，组播业务没问题；如果RX设备连接堆叠的3956，TX设备连接2952C这样的组网，组播业务就会花屏。
1：了解到客户现场组播业务拓扑结构比较简单，组播源和接收者都在同网段。
2：检查交换机上配置发现也都没有问题，同时检查组播转发表项也有生成。
3：通过做流量镜像端口查看组播业务报文发现没有ip层，如下图：

客户接入交换机配置了igmp-snooping形成组播转发表项，防止组播业务流量泛洪，通过镜像抓包查看到组播业务流量已经从互联3956设备的接口发出。
4:在3956设备抓包发现流量并没有发往TX接口，再次去检查配置，发现有一条ip igmp-snooping dlf-drop，这条命令是丢弃组播目的地址查找失败的报文，但是在2952C上也有配置，流量能够发往对应接口。
5：通过收集软件版本对接研发得知：2952C对于组播报文的处理机制是只检查2层组播mac然后根据组播转发表项转发；而3956对于组播报文的处理机制是检查2层组播mac，还会检查3层组播ip，都对应上组播转发表项才会转发，否则就会泛洪或者配置了ip igmp-snooping dlf-drop 就会丢弃。
6:将此问题反馈给产品经理去评估，由于这种组播报文并不常见，所以对接研发出专用版本解决。