希望这里有人能对我们面临的问题有所了解。目前，思科 TAC 正在调查此案，但他们正在努力寻找根本原因。
虽然标题提到了 ARP 广播和高 CPU 使用率，但我们目前不确定它们是否相关或不相关。
最初的问题是发布在INE在线社区
我们已经将网络精简为单个链路，没有冗余设置，可以将其视为星型拓扑。
事实：
- 我们使用 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 的大量广播数据包，VLAN 1 用于桌面设备。我们使用 192.168.0.0/20
- 思科 TAC 表示，他们认为使用 /20 没有任何问题，除了我们会有一个大的广播域但仍应正常运行。
- Wifi、管理、打印机等都在不同的 VLAN 上
- 生成树已由 Cisco TAC 和 CCNP/CCIE 合格人员验证。我们关闭了所有冗余链路。
- 核心上的配置已经过 Cisco TAC 验证。
- 大多数交换机都有默认的 ARP 超时。
- 我们不实施 Q&Q。
- 没有添加新开关（至少我们不知道）
- 无法在边缘交换机上使用动态 arp 检查，因为这些是 2950
- 我们使用 show interface | inc line|broadcast 来查明大量广播来自何处，但 Cisco TAC 和另外 2 名工程师（CCNP 和 CCIE）都确认这是正常现象，因为网络上正在发生这种情况（因为大量 mac 翻动导致广播量较大）。我们验证了 STP 在边缘交换机上正常运行。
网络和交换机上的症状：
- 大量 MAC 襟翼
- ARP 输入进程的 CPU 使用率过高
- 海量ARP报文，增长迅速，且可见
- Wiresharks 显示数百台计算机正在通过 ARP 广播淹没网络
- 为了测试目的，我们将大约 80 台台式机放在不同的 VLAN 中，但我们对此进行了测试，发现高 CPU 或 arp 输入没有明显差异
- 已经运行了不同的 AV/恶意软件/间谍软件，但网络上没有发现病毒。
- sh mac address-table count，向我们展示了 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
- 在不同的交换机和核心本身（在核心上，例如，直接由桌面插入，我的桌面）上运行 show mac address-table ，我们可以看到几个不同的 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% 确定能找到网络上的所有冗余链接和未知交换机，但根据我们的发现，在找到进一步的证据之前，情况就是这样的。
- 端口安全已经过调查，但遗憾的是管理层出于各种原因决定不再使用端口安全。常见的原因是我们经常移动计算机（大学环境）。
- 我们在所有接入端口（台式机）上默认结合使用了 spanning-tree portfast 和 spanning-tree bpduguard。
- 我们目前在接入端口上不使用 switchport nonnegotiate，但我们没有遇到跨多个 Vlan 反弹的任何 Vlan 跳跃攻击。
- 将尝试 mac-address-table 通知，看看是否可以找到任何模式。
“由于交换机端口之间出现大量 MAC 地址翻转，因此很难找到违规者的位置（假设您找到两个或三个发送大量 arp 的 MAC 地址，但源 MAC 地址在端口之间不断翻转）。”
- 我们从这里开始，挑选出任何一个 MAC 地址翻腾，并继续通过所有核心交换机到分发交换机到接入交换机，但我们再次发现，接入端口接口占用了多个 MAC 地址，因此出现 MAC 地址翻腾；所以又回到原点。
- 我们确实考虑过风暴控制，但我们担心一些合法数据包会被丢弃，从而导致进一步的问题。
- 将三次检查 VMHost 配置。
- @ytti 无法解释的 MAC 地址位于许多接入端口后面，而不是单个端口。未在这些接口上发现任何循环。MAC 地址也存在于其他接口上，这可以解释大量的 MAC 翻转
- @RickyBeam 我同意为什么主机要发送这么多 ARP 请求；这是一个令人费解的问题。Rouge 无线网桥是一个有趣的问题，我还没有考虑过，据我们所知，无线网桥位于不同的 VLAN 上；但 Rogue 显然意味着它很可能位于 VLAN1 上。
- @RickyBeam，我并不想拔掉所有电源，因为这会导致大量停机时间。然而，这可能是事情发展的趋势。我们确实有 Linux 服务器，但不超过 3 台。
- @RickyBeam，您能解释一下 DHCP 服务器“正在使用”探测吗？
我们（思科 TAC、CCIE、CCNP）一致认为这不是交换机配置，而是主机/设备导致了问题。
答案1
解决了。
该问题出在 SCCM 2012 SP1 上，该服务名为：ConfigMrg 唤醒代理。此“功能”在 SCCM 2012 RTM 中不存在。
在策略中关闭此功能 4 小时内，我们看到 CPU 使用率稳步下降。4 小时后，ARP 使用率仅为 1-2%！
总之，这项服务确实会进行 MAC 地址欺骗！真不敢相信它造成了多大的破坏。
以下是来自 Microsoft Technet 的全文，我觉得了解这与发布的问题有何关系很重要。
对于任何感兴趣的人，以下是技术细节。
配置管理器支持两种局域网 (LAN) 唤醒技术，当您想要安装所需软件（例如软件更新和应用程序）时，可以使用这两种技术唤醒处于睡眠模式的计算机：传统唤醒数据包和 AMT 开机命令。
从 Configuration Manager SP1 开始，你可以使用唤醒代理客户端设置来补充传统的唤醒数据包方法。唤醒代理使用对等协议和选定的计算机来检查子网上的其他计算机是否处于唤醒状态，并在必要时唤醒它们。当站点配置为 LAN 唤醒并且客户端配置为唤醒代理时，该过程的工作方式如下：
子网上安装了 Configuration Manager SP1 客户端且未处于休眠状态的计算机会检查子网上的其他计算机是否处于唤醒状态。它们通过每 5 秒向彼此发送一次 TCP/IP ping 命令来执行此操作。
如果没有其他计算机的响应，则认为它们处于睡眠状态。处于唤醒状态的计算机将成为子网的管理计算机。
由于计算机可能由于睡眠状态以外的其他原因而未响应（例如，计算机已关闭、从网络移除或代理唤醒客户端设置不再适用），因此计算机每天下午 2 点（当地时间）都会收到唤醒数据包。未响应的计算机将不再被视为睡眠状态，也不会被唤醒代理唤醒。
为了支持唤醒代理，每个子网必须至少有三台计算机处于唤醒状态。为此，需要非确定性地选择三台计算机作为子网的监护计算机。这意味着，尽管配置了电源策略以在一段时间不活动后进入睡眠或休眠状态，它们仍将保持唤醒状态。监护计算机会遵守关机或重启命令，例如，由于维护任务。如果发生这种情况，其余的监护计算机将唤醒子网上的另一台计算机，以便子网继续拥有三台监护计算机。
管理器计算机请求网络交换机将休眠计算机的网络流量重定向到它们自己。
重定向是通过管理器计算机广播使用休眠计算机的 MAC 地址作为源地址的以太网帧来实现的。这使网络交换机的行为就像休眠计算机已移动到管理器计算机所在的同一端口一样。管理器计算机还会为休眠计算机发送 ARP 数据包，以使 ARP 缓存中的条目保持最新。管理器计算机还将代表休眠计算机响应 ARP 请求并使用休眠计算机的 MAC 地址进行回复。
在此过程中，睡眠计算机的 IP 到 MAC 映射保持不变。唤醒代理的工作原理是通知网络交换机，另一个网络适配器正在使用另一个网络适配器注册的端口。但是，这种行为称为 MAC 翻转，对于标准网络操作来说并不常见。一些网络监视工具会查找此行为并假设存在问题。因此，当您使用唤醒代理时，这些监视工具可以生成警报或关闭端口。如果您的网络监视工具和服务不允许 MAC 翻转，请不要使用唤醒代理。
当管理器计算机看到睡眠计算机的新 TCP 连接请求并且该请求发送到睡眠计算机在进入睡眠状态之前正在监听的端口时，管理器计算机会向睡眠计算机发送唤醒数据包，然后停止为此计算机重定向流量。
睡眠中的计算机收到唤醒数据包并被唤醒。发送数据包的计算机会自动重试连接，此时计算机已唤醒并可以响应。
感谢在这里发帖并协助解决问题的每个人，非常感谢。
答案2
ARP/广播风暴
- 我们看到来自 VLAN 1 的大量广播数据包，VLAN 1 用于桌面设备。我们使用 192.168.0.0/20...
- Wiresharks 显示数百台计算机正在通过 ARP 广播充斥网络...
您的 ARP 输入进程很高，这意味着交换机花费大量时间处理 ARP。ARP 泛洪的一个非常常见的原因是交换机之间的循环。如果您有循环，那么您也会得到上面提到的 mac 封包。ARP 泛洪的其他可能原因是：
- IP 地址配置错误
- 第 2 层攻击，例如arp欺骗
首先消除上面提到的配置错误或第 2 层攻击的可能性。最简单的方法是使用阿普观察在 Linux 机器上（即使你必须使用活光盘在笔记本电脑上）。如果您配置错误或遭受第 2 层攻击，arpwatch 会在 syslog 中向您提供类似这样的消息，其中列出了争夺同一 IP 地址的 mac 地址...
Oct 20 10:31:13 tsunami arpwatch: flip flop 192.0.2.53 00:de:ad:85:85:ca (00:de:ad:3:d8:8e)
当你看到“触发器”时，你必须追踪 MAC 地址的来源并弄清楚为什么它们会争夺同一个 IP。
- 大量 MAC 襟翼
- 生成树已由 Cisco TAC 和 CCNP/CCIE 合格人员验证。我们关闭了所有冗余链路。
作为一个经历过很多次这种情况的人，不要以为你找到了所有冗余链接……只要让你的交换机端口始终正常运行即可。
由于交换机端口之间有大量的 mac 地址抖动，因此很难找到问题所在（假设您找到两个或三个发送大量 arp 的 mac 地址，但源 mac 地址在端口之间不断抖动）。如果您没有对每个边缘端口的 mac 地址实施硬性限制，那么如果不手动拔掉电缆（这是您想要避免的），就很难找到这些问题。交换机环路会导致网络中出现意外路径，您可能会间歇性地从通常应该是桌面交换机端口的位置学习到数百个 mac 地址。
减慢 mac 动作的最简单方法是port-security. 在 Vlan 1 中连接到单台 PC（没有下游交换机）的每个接入交换机端口上，在思科交换机上配置以下接口级命令...
switchport mode access
switchport access vlan 1
!! switchport nonegotiate disables some Vlan-hopping attacks via Vlan1 -> another Vlan
switchport nonnegotiate
!! If no IP Phones are connected to your switches, then you could lower this
!! Beware of people with VMWare / hubs under their desk, because
!! "maximum 3" could shutdown their ports if they have more than 3 macs
switchport port-security maximum 3
switchport port-security violation shutdown
switchport port-security aging time 5
switchport port-security aging type inactivity
switchport port-security
spanning-tree portfast
!! Ensure you don't have hidden STP loops because someone secretly cross-connected a
!! couple of desktop ports
spanning-tree bpduguard enable
在大多数 mac/ARP 泛洪情况下，将此配置应用于所有边缘交换机端口（尤其是具有 portfast 的端口）将使您恢复正常状态，因为此配置将关闭超过三个 mac 地址的任何端口，并禁用秘密循环的 portfast 端口。每个端口三个 mac 在我的桌面环境中运行良好，但您可以将其提高到 10，可能也没什么问题。完成此操作后，任何第 2 层循环都会中断，快速 mac 翻滚将停止，诊断将变得更加容易。
另外几个全局命令可用于追踪与广播风暴（mac-move）和洪泛（阈值）相关的端口......
mac-address-table notification mac-move
mac address-table notification threshold limit 90 interval 900
完成后，可选择执行操作clear mac address-table以加速可能已满的 CAM 表的修复。
- 在不同的交换机和核心本身（在核心上，例如，直接由桌面插入，我的桌面）上运行 show mac address-table，我们可以看到几个不同的 MAC 硬件地址被注册到接口，即使该接口只有一台计算机连接到此...
整个回答都假设您的 3750 没有导致问题的 bug（但您确实说过 wireshark 指示了正在泛滥的 PC）。当只有一台计算机连接到 Gi1/1/3 时，您向我们显示的内容显然是错误的，除非该 PC 上有类似 VMWare 的东西。
杂项
根据我们的聊天记录，我可能不需要提及显而易见的事情，但为了未来的访客，我会提及……
- 将任何用户放在 Vlan1 中通常都是一个坏主意（我知道你可能继承了一个烂摊子）
- 无论 TAC 告诉您什么，192.168.0.0/20 都太大了，无法在单个交换域中管理，否则会存在第 2 层攻击的风险。子网掩码越大，您遭受此类第 2 层攻击的风险就越大，因为 ARP 是一种未经身份验证的协议，路由器必须至少从该子网读取有效的 ARP。
- 第 2 层端口上的风暴控制通常也是一个好主意；但是，在这种情况下启用风暴控制会将好流量与坏流量分开。网络恢复后，在边缘端口和上行链路上应用一些风暴控制策略。
答案3
真正的问题是主机为什么首先发送这么多 ARP。在这个问题得到解答之前，交换机将继续难以应对 ARP 风暴。网络掩码不匹配？主机 ARP 计时器低？一个（或多个）主办方有“接口”路由吗？某处有非法无线网桥？“无故 arp”出问题了吗？DHCP 服务器“正在使用”探测？这听起来不像是交换机或第 2 层的问题；您的主机在做坏事。
我的调试过程是拔掉所有东西，然后仔细观察重新连接的过程，一次一个端口。（我知道这远非理想，但在某些时候你必须减少损失并尝试物理隔离任何可能的来源）然后我会努力理解为什么选定的端口会生成这么多 arp。
（这些主机中有很多都是 Linux 系统吗？Linux 有一个非常愚蠢的 ARP 缓存管理系统。它会在几分钟内“重新验证”一个条目，在我看来这是错误的。在小型网络中，这个问题往往不大，但 /20 不是一个小型网络。）
答案4
一个非常简单但可能被忽略的问题；您的客户端是否有有效的默认网关，您的核心是否正在执行大量代理 arp。您可以考虑否定 3750 上的 ip 代理 arp 功能吗？