简介
本文档介绍如何排除ARP风暴故障，而不带内ARP流量。
背景
ARP风暴是您在数据中心环境中看到的常见拒绝服务(DoS)攻击。
处理ARP数据包的常见交换机逻辑是：
- 具有广播目标媒体访问控制(MAC)的ARP数据包
- 具有单播目的MAC的ARP数据包，属于交换机
如果交换机虚拟接口(SVI)在接收VLAN中处于启用状态，则将通过软件中的ARP过程进行处理。
根据此逻辑，如果有一台或多台恶意主机在Vlan中继续发送ARP请求，其中交换机是该Vlan的网关。ARP请求将在软件中处理，因此交换机会被淹没。在某些较旧的思科交换机型号和版本中，您会看到ARP进程占用CPU的高级，并且系统太忙，无法处理其他控制平面流量。跟踪此类攻击的常见方法是运行带内捕获以识别ARP风暴的源MAC。
在Nexus 7000充当汇聚网关的数据中心中，Nexus 7000系列交换机上的CoPP可以降低这种影响。您仍可以在Nexus 7000上运行带内捕获Ethanalyzer故障排除指南，以识别ARP风暴的源MAC，因为控制平面策略(CoPP)只是一个缓慢但不会导致ARP风暴涌入CPU的强盗。
如果：
- SVI关闭
- 没有过多的ARP数据包被发送到CPU
- 由于ARP进程，没有高CPU
但交换机仍会看到与ARP相关的问题，例如直连主机的ARP不完整。是否可能由ARP风暴引起？
在Nexus 7000上，答案是肯定的。
根本原因
在nexus 7000线卡设计中，为了支持CoPP中的ARP数据包处理，ARP请求将驱动特殊逻辑接口(LIF)，然后在转发引擎(FE)中受CoPP的速率限制。 无论您是否为Vlan提供SVI，都会发生这种情况。
因此，尽管FE做出的最终转发决定是不向带内CPU发送ARP请求（如果VLAN没有SVI），CoPP计数器仍会更新。它导致CoPP饱和，ARP请求过多，并丢弃合法ARP请求/应答。在此场景中，您不会看到任何过多的带内ARP数据包，但仍受到ARP风暴的影响。
我们已针对此CoPP第一天行为提交了增强的Bug CSCub47533。
解决方案
在此场景中，可以有几个选项来确定ARP风暴的源。一个有效的选择是：
N7K# sh policy-map interface control-plane class copp-system-p-class-normal
Control Plane
service-policy input copp-system-p-policy-strict
class-map copp-system-p-class-normal (match-any)
match access-group name copp-system-p-acl-mac-dot1x
match exception ip multicast directly-connected-sources
match exception ipv6 multicast directly-connected-sources
match protocol arp
set cos 1
police cir 680 kbps bc 250 ms
conform action: transmit
violate action: drop
module 3:
conformed 4820928 bytes,
5-min offered rate 0 bytes/sec
peak rate 104 bytes/sec at Thu Aug 25 08:12:12 2016
violated 9730978848 bytes,
5-min violate rate 6983650 bytes/sec
peak rate 7632238 bytes/sec at Thu Aug 25 00:43:33 2016
module 4:
conformed 4379136 bytes,
5-min offered rate 0 bytes/sec
peak rate 38 bytes/sec at Wed Aug 24 07:12:09 2016
violated 0 bytes,
5-min violate rate 0 bytes/sec
peak rate 0 bytes/sec
...
- 第二步使用ELAM程序捕获到模块的所有ARP数据包。你可能需要做几次。但是，如果发生风暴，捕获违反的ARP数据包的机率比估计的ARP数据包要好得多。从ELAM捕获中确定源MAC和Vlan。
反馈