卧龙注册-官网网络架构，出口---核心---有线/POE接入---有线用户/AP。有线直连接入交换机获取不到IP，初步判断故障在核心（DHCP服务器）与 有线接入之间发生，重点观察此处。 然后确认报故障的时候反馈部分网段正常，vlan6网段无法获取IP。获取不到IP结合现场情况可能是DHCP满了导致无法获取IP，于是远程 到核心上，发现核心刚刚重启，这样DHCP的地址肯定释放掉了，但是故障依旧存在，所以不是DHCP地址池满了的问题。

　　此时开始在核心上show log查看具体报错。发现有较多地址冲突，并且是vlan6网关地址冲突，当时判断该故障是因为地址冲突导致下 联用户无法获取IP无法正常上网。

　　于是开始在核心上查看对应的MAC是怎么连的，用show mac-address-table 5869.6c8f.4ea8查看发现同一个MAC出现在2个不同 的接口，可以判断一定有环路。

　　继续结合核心配置，可以看到聚合口agg4和agg5对应的是9、10、11、12口，再继续通过show lldp nei detail来查看接口下联设 备IP。

　　此时进入下联设备查看，继续show log查看和核心一样的提示192.168.32.1的网关冲突。此时发现接入交换机vlan6居然配着和核心 一样的网关地址。于是将该vlan下的ip删除（vlan6不是设备互联vlan，大胆删除）

　　剩余在其他2台下联交换机中同样发现此问题，删除掉冲突IP后，核心已经不报IP冲突了。 但是故障现象依旧存在，所以判断不止是IP冲突导致该问题。继续观察核心log，告警日志变成了ARP攻击、到达ARP水线阈值。

　　此时第一反应是进CPU查看各个线程是否有异常，结果发现arp-request报文一直在drop，这样的结果就是用户连接网络需要获取 IP，当用户广播DHCP的Discover报文核心作为DHCP服务器将不会响应，因为报文被drop掉了。所以判断故障是ARP到达阈值导致的。

　　产生arp水线是存在用户一直做ARP泛洪攻击，2是网络中存在环路。我们按这个思路去看查看攻击列 表，用show nfpp log buff和sho nfpp arp-guard host命令来查看：

　　可以看到攻击源一直在9、10口中产生。再结合核心可以看到这两个口对应聚合口4下联到SW3。此时重点排查SW3即可。 登录到SW3，通过前面排查思路，造成ARP泛洪可能是有人攻击也可能有环路导致。于是通过lldp协议去看设备的互联情况。

　　可以看到本地27口和本地的29口接在一起了，判断环路。通过拔线测试，确认拔线后网络恢复正常。最后顺着线发现两条线接在一台 小hub上，确认环路，解除环路后便网络正常了。

　　写在最后，我们接入交换机在办公网环境下很有可能出现环路，所以尽量在接入交换机下联口配置防环机制，附上一份锐捷交换机的防 环脚本（核心不需要配，只需要配置在接入交换机上就可以）：

　　2、去核心 sh log看具体报错，发现地址网关地址冲突，查看对应的MAC是怎么链接的，发现回路