华为S6700交换机CPU占用过高 问题描述:两台 S6700 均全局使能 RSTP，并配置 OSPF 和 VRRP。故障发生时，主设备上出现 OSPF、 VRRP 协议震荡。两台交换机上均出现 CPU 高的日志信息，同时网管上监控 CPU 占用率多次超过 90%，同时还有大量的 ARP 报文超过 CPCAR 后丢弃的日志记录。 通过网管监控的 CPU 利用率情况，如图所示 ：通过网管监控看到的 CPU 利用率告警信息1. 交换机上出现 CPU 占用率过高的日志信息。S6700-1 %%01VOSCPU/4/CPU_USAGE_HIGH(l)[31]:The CPU is overloaded(CpuUsage=96%, Threshold=95%), and the tasks with top three CPU occupancy are: FTS total : 18% SRMT total : 11% SOCK total : 8% S6700-1 %%01VOSCPU/4/CPU_USAGE_HIGH(l)[60]:The CPU is overloaded(CpuUsage=100%, Threshold=95%), and the tasks with top three CPU occupancy are: PPI total : 41% SRMT total : 10% FTS total : 8%2. 交换机上还有大量的 ARP 报文超过 CPCAR 后丢弃的日志记录。S6700-1 %%01DEFD/4/CPCAR_DROP_MPU(l)[56]:Rate of packets to cpu exceeded the CPCAR limit on the MPU. (Protocol=arp-miss, ExceededPacketCount=016956) S6700-1 %%01DEFD/4/CPCAR_DROP_MPU(l)[57]:Rate of packets to cpu exceeded the CPCAR limit on the MPU. (Protocol=arp-reply, ExceededPacketCount=020699) S6700-1 %%01DEFD/4/CPCAR_DROP_MPU(l)[58]:Rate of packets to cpu exceeded the CPCAR limit on the MPU. (Protocol=arp-request, ExceededPacketCount=0574)3. 查看端口 TC（Topology Change）报文收发情况。 所有使能 RSTP 的端口，接收的 TC 报文计数均在增长。<S6700> display stp tc-bpdu statistics -------------------------- STP TC/TCN information -------------------------- MSTID Port TC(Send/Receive) TCN(Send/Receive) 0 GigabitEthernet0/0/1 19319/3271 0/0 0 GigabitEthernet0/0/2 29761/676 0/0 0 GigabitEthernet0/0/3 128/4 0/0 0 GigabitEthernet0/0/4 24615/1016 0/0 0 GigabitEthernet0/0/5 30697/98 0/0 0 GigabitEthernet0/0/6 25447/317 0/0处理过程步骤 1 全局配置 stp tc-protection。配置此命令后可以保证设备频繁收到 TC 报文时，每 2 秒周期内最多只处理 1 次表项刷新。 从而减少 MAC、ARP 表项频繁刷新对设备造成的 CPU 处理任务过多。步骤 2 全局配置 arp topology-change disable 及 mac-address update arp当设备收到 TC 报文后，默认会清除 MAC、老化 ARP。当设备上的 ARP 表项较多时，ARP 的 重新学习会导致网络中的 ARP 报文过多。配置 arp topology-change disable、mac-address update arp 后，在网络拓扑变化时，可以根据 MAC 地址的出接口变化刷新 ARP 表项出接口。可以 减少大量不必要的 ARP 表项刷新。说明：V100R006 版本开始支持 mac-address update arp，V200R001 版本开始支持 arp topology-change disable 命令根因通过查看端口的 TC 报文计数，发现端口收到大量的 TC 报文，且在不断增长。触发 MAC 删除、 ARP 表项刷新，设备处理大量 arp-miss、arp-request 和 arp-reply 报文，导致 CPU 升高，OSPF Hello 报文、VRRP 心跳报文不能及时处理，出现震荡建议与总结在部署 STP 时，建议配置 TC 保护功能，所有连接终端的接口配置成边缘端口，这样可以避免 某些端口的状态变化引起整个 STP 网络震荡而重新收敛 

arp攻击解决方法 当网络时断时续，网页弹出各种出错ping内网关request out时断时续，考虑网络arp病毒；装个arp防火墙，找出攻击源，离线杀其毒，清除网内ARP表，然后路由，绑定arp网关及各主机对应mac，有效解决arp病毒广播，划分vlan或实行主机pppoe拔号上网，主机上相关操作cmd 里@echo offarp -darp -s ip macarp -a路由上(cisco)clear ip arparp ip mac arpa int f0/1dhcp snooping enableip source binding vlan 10 ip mac int f0/1show arp|include 攻击源mac华为、H3C路由器上display arp XXX 待更新  

服务做两台Exchange CAS的集群配置完NLB后发现同网段访问正常跨网段不通 问题描述:微软的NLB（网络负载均衡）服务做两台Exchange CAS（Client Access Server）的集群，配置完NLB后发现同网段访问正常，跨网段都无法访问，甚至在NLB网段的网关上都无法访问。拓扑如下：故障截图：处理过程:1.首先尝试从网关S7700上ping NLB虚地址10.16.68.254，发现不通。同网段都不通，最常见的原因就是没有对应的ARP记录。2.然后在网关上查看10.16.68.254的ARP记录，发现果然没有学习到。3.在同网段某台服务器上通过arp –a查看10.16.68.254的ARP记录，发现是组播MAC 03bf-xxxx-xxxx。一般在设备没有启用组播服务或者IGMP监听的情况下，网关设备是不处理组播ARP对应的报文的。根因根据MAC地址的规范，最高位是1时代表组播地址，0是为单播地址。所以0x03开头的地址为组播地址，网络设备在没有启用组播和IGMP侦听的情况下，网关设备不处理组播ARP对应的报文的。由于缺少二层ARP解析，造成三层无法ping通。解决方案通过在网关上手工静态绑定ARP记录。建议与总结根据MAC地址的规范，0x01,03,05,07开头的都是组播MAC地址，而我们最熟悉的组播MAC地址为01-00-5e开头，由此可能会造成思维定式，认为只有01-00-5e开头才是组播MAC。 有