网络架构，出口---核心---有线/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水线被打满的情况一般有2种可能：1是存在用户一直做ARP泛洪攻击，2是网络中存在环路。我们按这个思路去看查看攻击列表，用show nfpp log buff和sho nfpp arp-guard host命令来查看：
可以看到攻击源一直在9、10口中产生。再结合核心可以看到这两个口对应聚合口4下联到SW3。此时重点排查SW3即可。
登录到SW3，通过前面排查思路，造成ARP泛洪可能是有人攻击也可能有环路导致。于是通过lldp协议去看设备的互联情况。
可以看到本地27口和本地的29口接在一起了，判断环路。通过拔线测试，确认拔线后网络恢复正常。最后顺着线发现两条线接在一台小hub上，确认环路，解除环路后便网络正常了。
写在最后，我们接入交换机在办公网环境下很有可能出现环路，所以尽量在接入交换机下联口配置防环机制，附上一份锐捷交换机的防环脚本（核心不需要配，只需要配置在接入交换机上就可以）：
con
errdisable recovery interval 120 //配置errordiable接口恢复时间
rldp enable //开启RLDP协议，锐捷私有防环协议
int ran gi 0/1 - 24 //进入下联1至24口（按需求选择接口）
rldp port loop-detect shutdown-port//开启rldp防环，发现环路时逻辑上shutdown，120秒后恢复
end
wr
排查手段：
1、怀疑地址池满，重启核心，问题存在
2、去核心 sh log看具体报错，发现地址网关地址冲突，查看对应的MAC是怎么链接的，发现回路
3、通过核心查看哪个交换3有回路
4、登录问题交换机3，删除与核心一样配置的VLAN 6，
5、继续看核心日志，ARP攻击，查看CPU线程，判断环路，用show nfpp log buff和sho nfpp arp-guard host命令来查看
6、跟踪到聚合口4，看核心对应接入3，进入接入3，看lldp协议
