希望有人可以对我们面临的问题有所了解。目前，我们有Cisco TAC在调查此案，但他们正在努力寻找根本原因。
尽管标题中提到了ARP广播和较高的CPU使用率，但是我们不确定在此阶段它们是否相关。
原始问题已发布在INE Online社区上
我们将网络简化为单个链路，没有冗余设置，可以将其视为星形拓扑。
事实：
- 我们使用3750x交换机，每堆叠4个。15.0（1）SE3版。对于此特定版本，Cisco TAC确认没有有关高cpu或ARP错误的已知问题。
- 没有连接集线器/不受管理的交换机
- 重新加载核心堆栈
- 我们没有默认路由“ Ip route 0.0.0.0 0.0.0.0 f1 / 0”。使用OSPF进行路由。
- 我们看到来自VLAN 1的大型广播数据包用于台式机设备。我们使用192.168.0.0/20
- 思科TAC表示，使用/ 20不会出现任何问题，否则我们将拥有一个较大的广播域，但仍然可以正常工作。
- Wifi，管理，打印机等都位于不同的VLAN
- 生成树已通过思科TAC和CCNP / CCIE合格人员的验证。我们关闭所有冗余链接。
- 核心上的配置已通过Cisco TAC验证。
- 大多数交换机上都有默认的ARP超时。
- 我们不实施问答。
- 没有添加新的开关（至少我们不知道）
- 由于这些是2950，因此无法在边缘交换机上使用动态arp检查
- 我们使用了show接口| inc广播以找出大量广播来自何处，但是Cisco TAC和2位其他工程师（CCNP和CCIE）都确认这是正常行为，原因是网络上发生了什么（如大量的Mac襟翼导致更大的广播）。我们验证了STP在边缘交换机上是否正常运行。
网络和交换机上的症状：
- 大量MAC襟翼
- ARP输入过程的CPU使用率高
- 大量的ARP数据包，迅速增加并可见
- Wiresharks显示ARP广播淹没了数百台计算机
- 为了进行测试，我们将大约80个台式机放置了不同的VLAN，但是我们对此进行了测试，并且对高CPU或ARP输入没有明显的影响
- 运行了不同的AV /恶意软件/间谍软件，但网络上没有可见的病毒。
- sh mac地址表计数，向我们显示了VLAN 1上预期的大约750个不同的mac地址。
#sh processes cpu sorted | exc 0.00%
CPU utilization for five seconds: 99%/12%; one minute: 99%; five minutes: 99%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
12 111438973 18587995 5995 44.47% 43.88% 43.96% 0 ARP Input
174 59541847 5198737 11453 22.39% 23.47% 23.62% 0 Hulc LED Process
221 7253246 6147816 1179 4.95% 4.25% 4.10% 0 IP Input
86 5459437 1100349 4961 1.59% 1.47% 1.54% 0 RedEarth Tx Mana
85 3448684 1453278 2373 1.27% 1.04% 1.07% 0 RedEarth I2C dri
- 在不同的交换机和内核本身上显示了mac地址表（例如，在内核上，直接由桌面插入，我的桌面插入了内核），即使该接口具有仅与此连接的一台计算机：
Vlan Mac Address Type Ports
---- ----------- -------- -----
1 001c.c06c.d620 DYNAMIC Gi1/1/3
1 001c.c06c.d694 DYNAMIC Gi1/1/3
1 001c.c06c.d6ac DYNAMIC Gi1/1/3
1 001c.c06c.d6e3 DYNAMIC Gi1/1/3
1 001c.c06c.d78c DYNAMIC Gi1/1/3
1 001c.c06c.d7fc DYNAMIC Gi1/1/3
- 显示平台tcam利用率
CAM Utilization for ASIC# 0 Max Used
Masks/Values Masks/values
Unicast mac addresses: 6364/6364 1165/1165
IPv4 IGMP groups + multicast routes: 1120/1120 1/1
IPv4 unicast directly-connected routes: 6144/6144 524/524
IPv4 unicast indirectly-connected routes: 2048/2048 77/77
IPv4 policy based routing aces: 452/452 12/12
IPv4 qos aces: 512/512 21/21
IPv4 security aces: 964/964 45/45
我们现在处于一个阶段，在这个阶段，我们将需要大量的停机时间来一次隔离每个区域，除非其他人有一些想法来确定此怪异而奇怪的问题的根源或根本原因。
更新资料
感谢@MikePennington和@RickyBeam的详细回复。我会尽力回答。
- 如前所述，192.168.0.0 / 20是一个继承的混乱。但是，我们确实打算在将来对此进行拆分，但是很遗憾，此问题在我们无法解决之前就已发生。我个人也同意多数意见，因为广播领域太大了。
- 使用Arpwatch绝对是我们可以尝试的方法，但是我怀疑，因为几个访问端口正在注册mac地址，即使它不属于该端口，arpwatch的结论也可能没有用。
- 我完全同意不能100％确定在网络上找到所有冗余链路和未知交换机，但是根据我们的发现，这是事实，直到我们找到进一步的证据为止。
- 已经研究了端口安全性，不幸的是，出于各种原因，管理层决定不使用此功能。常见原因是我们不断在（大学环境中）移动计算机。
- 默认情况下，我们在所有访问端口（台式机）上将生成树portfast与生成树bpduguard结合使用。
- 目前，我们不在接入端口上使用switchport nonnegotiate，但是我们并没有收到跨多个VLAN反弹的任何VLAN跳跃攻击。
- 暂时给mac-address-table通知，看看是否可以找到任何模式。
“由于在交换端口之间有大量的MAC摆动，因此很难找到违规者所在的位置（假设您发现有两个或三个发送大量arp的mac地址，但是源mac地址却在端口之间不断摆动）。”
- 我们从此开始，选择了任意一个MAC挡板，然后继续通过所有核心交换机，直至分发到访问交换机，但是我们发现，访问端口接口再次占用了多个MAC地址，因此就产生了MAC挡板。回到正题。
- 我们确实考虑过风暴控制，但是我们担心一些合法数据包会被丢弃，从而导致进一步的问题。
- 将三重检查VMHost配置。
- @ytti无法解释的MAC地址位于许多访问端口后面，而不是单个端口后面。在这些接口上尚未找到任何循环。MAC地址也存在于其他接口上，这可以解释大量的MAC摆动
- @RickyBeam我同意为什么主机发送这么多ARP请求；这是令人困惑的问题之一。众所周知，Rouge无线网桥是一个有趣的桥梁，据我所知，无线网络位于不同的VLAN上。但是流氓显然将意味着它很可能在VLAN1上。
- @RickyBeam，我真的不希望断开所有连接，因为这将导致大量的停机时间。但是，这可能只是前进的方向。我们确实有Linux服务器，但不超过3台。
- @RickyBeam，您能解释一下DHCP服务器“使用中”探测吗？
我们（思科TAC，CCIE，CCNP）在全球范围内同意这不是交换机配置，而是主机/设备引起了该问题。
1
我会指出：除非网络中存在环路，否则不应发生mac扑灭。唯一的其他逻辑原因是VM使用相同的MAC。（或某些骨头将多个nic设置为使用同一MAC）
@ColdT，我更新了答案，因为我在原始回复中误读了一些内容。
—
Mike Pennington
您是否在许多端口或仅一个端口后面遇到大量无法解释的MAC地址？端口是否可以循环？MAC地址是留在该端口后面还是也出现在其他端口后面？我们有用于ARP的PCAP吗？大量的MAC振荡肯定根本不正常，这意味着拓扑结构不断变化，或者网络中存在非托管环路。
@ColdT，我想您应该与港口安全管理部门重新接触；我专门为您提供了允许PC在交换机端口之间移动的配置。
—
Mike Pennington
switchport port-security aging time 5并且switchport port-security aging type inactivity意味着你可以端口之间的闲置5分钟后，移动站，或者如果你手动清除端口的安全项。但是，此配置可防止交换机的访问端口之间出现mac摆动，因为端口无法从其他端口任意获取相同的mac地址。
还值得一提的是，除非同一IP地址使用不同的ARP，否则arpwatch不会注册触发器。无论原因为何，您都需要知道何时发生。仅仅Mac洪水不足以使arpwatch感到困惑
—
Mike Pennington