网络中MAC漂移障案例 问题描述1、网络异常时S9700 log 上报MAC 地址飘移； 2、网管监控到S9700 CPU 利用率超过阈值； 3、S9700 作为网关，下挂用户ping 不通网关。告警信息 Jul 23 2017 07:14:24+08:00 9700_01 L2IFPPI/4/MFLPVLANALARM:OID 1.3.6.1.4.1.2011.5.25.160.3.7 MAC move detected, VlanId = 853, MacAddress = 0080-87db-a942, Original-Port = GE11/0/44, Flapping port = Eth-Trunk1. Please check the network accessed to flapping port. Jul 23 2017 07:14:28+08:00 9700_01 L2IFPPI/4/MFLPVLANALARM:OID 1.3.6.1.4.1.2011.5.25.160.3.7 MAC move detected, VlanId = 850, MacAddress = 78e7-d1d2-de12, Original-Port = GE12/0/44, Flapping port = Eth-Trunk1. Please check the network accessed to flapping port. Jul 23 2017 07:17:16+08:00 9700_01 �FD/6/CPCAR_DROP_LPU(l)[85839]:Rate of packets to cpu exceeded the CPCAR limit on the LPU in slot 8. (Protocol=vrrp, ExceededPacketCount=011850) Jul 23 2017 07:17:16+08:00 9700_01 �FD/6/CPCAR_DROP_LPU(l)[85840]:Rate of packets to cpu exceeded the CPCAR limit on the LPU in slot 8. (Protocol=dhcp-server, ExceededPacketCount=042) Jul 23 2017 07:17:16+08:00 9700_01 �FD/6/CPCAR_DROP_LPU(l)[85841]:Rate of packets to cpu exceeded the CPCAR limit on the LPU in slot 9. (Protocol=vrrp, ExceededPacketCount=014381)处理过程 1、分析S9700_01 和S9700_02 的日志。 日志显示在发生MAC 漂移前，S9700_01 的端口GE9/0/42 置为forwarding，并且 是从discarding 状态超时15s 变成learning，再经过15s 变成forwarding 状 态。这说明此时对端没有发送STP 报文，可能是对端端口去使能了STP，或者其 他原因导致发包异常。继续分析对端设备AS_23 的信息进行确认。 Jul 23 2017 07:13:10+08:00 S9700_01 %MSTP/6/SET_PORT_DISCARDING(l)[85836]:In MSTP process 0 instance 0, MSTP set port GigabitEthernet9/0/42 state as discarding. --- 9/0/42 端口discarding Jul 23 2017 07:13:25+08:00 S9700_01 %MSTP/6/SET_PORT_LEARNING(l)[85837]:In process 0 instance 0, MSTP set port GigabitEthernet9/0/42 state as learning. ---端口 learning Jul 23 2017 07:13:40+08:00 S9700_01 %MSTP/6/SET_PORT_FORWARDING(l)[85838]:In MSTP process 0instance 0, MSTP set port GigabitEthernet9/0/42 state as forwarding. --- 端口forwarding Jul 23 2017 07:14:24+08:00 S9700_01 L2IFPPI/4/MFLPVLANALARM:OID 1.3.6.1.4.1.2011.5.25.160.3.7 MAC move detected, VlanId = 853, MacAddress = 0080-87db-a942, Original-Port = GE11/0/44, Flapping port = Eth-Trunk1. Please check the network accessed to flapping port. --- 产生mac 漂移2、分析友商AS_23 的日志。 S9700_01 的端口GE9/0/42 对端是友商交换机AS_23 的端口E1/0/47。 根据该设备的日志，在发生MAC 漂移前，一个端口突然变成learning 状态，4s 后端口进入Forwarding 状态，且根桥切换成自己。在网络中存在更高优先级设 备的情况下，根桥切换成自己，通常是因为链路拥塞或单板故障导致收不到报文 或者报文不上送，STP 超时将端口置为Forwarding 状态，但是从learning 到 Forwarding 的时间根据标准是15s。而这里只有4s，且配置中没有修改定时器， 是该设备STP 产生了故障。 %Jul 23 07:14:23 2017 MODULE_L2_MSTP[tMstp]:MSTP set port = 48, mst = 0 to LEARNING! --- 端口learning %Jul 23 07:14:27 2017 MODULE_L2_MSTP[tMstp]:MSTP set port = 48, mst = 0 to FORWARDING! ---4s 后端口forwarding %Jul 23 07:14:28 2017 MODULE_L2_MSTP[tMstp]:Root bridge has been changed. PRS is triggered: INSTANCE=0 --- 根桥发生变化 %Jul 23 07:14:28 2017 MODULE_L2_MSTP[tMstp]:CistRoot = 32768.00:01:7a:f8:00:45, CistRegRoot = 32768.00:01:7a:f8:00:45 --- 以本设备为根桥 AS_23 端口突然进入Forwarding 状态，以自己为根桥向S9700_01 发送报文， S9700_01 的9/0/42 端口收到优先级低于本设备的报文，进入discarding 状态 （见步骤1 的日志），并向AS_23 发送高优先级报文。AS_23 收到报文后会重新 以S9700_01 为根桥（见下面日志），并停止向S9700_01 发送报文，因此后续 S9700_01 的9/0/42 端口不再收到报文，15s 超时进入learning 状态，再经过 15s 超时进入forwarding 状态（见步骤1 的日志）。 %Jul 23 08:57:58 2017 MODULE_L2_MSTP[tMstp]:Root bridge has been changed. PRS is triggered: INSTANCE=0 ---根桥发生变化 %Jul 23 08:57:58 2017 MODULE_L2_MSTP[tMstp]:CistRoot = 0.d8:49:0b:8c:e4:a0, CistRegRoot = 32768.00:01:7a:f8:00:45 ---根桥恢 复成原来的S9700_01 至此，可以证明是AS_23 发生故障，端口forwarding，导致S9700_01 端口状态 震荡1 次，并产生MAC 漂移。2、将AS_23 连接S9700_01 上行口shutdown 后环路破除，网络恢复。 3、4、因组网为VRRP+RSTP，将AS_23 连接S9700_01 上行口shutdown 为临时解 决办法，后客户将AS_23 设备替换，测试正常。 根因 设备上报MAC 地址飘移，同时CPU 利用率高，下挂用户ping 不通网关，一般网 络有环路导致广播风暴，需要及时破除环路。 建议与总结 如果设备同时上报MAC 地址飘移，CPU 利用率高，协议报文CPCAR 丢包，一般为 网络中出现环路。在局域网中环路对网络稳定性影响较大，需要及时破除环路。