ARP广播泛滥networking和高CPU使用率

解决了。

SCCM 2012 SP1是一个名为ConfigMrg Wake-Up Proxy的服务 。 “function”不存在SCCM 2012 RTM。

在政策内closures4小时内，我们看到CPU使用率稳步下降。 到4小时的时候，ARP的使用率只有1-2％！

总之，这个服务做MAC地址欺骗！ 不能相信它造成了多大的破坏。

以下是来自Microsoft Technet的全文，因为我觉得了解这与发布的问题有何联系很重要。

对于任何有兴趣的人，下面是技术细节。

configurationpipe理器支持两种唤醒局域网（LAN）技术，当您要安装所需的软件（如软件更新和应用程序）时，以睡眠模式唤醒计算机：传统唤醒数据包和AMT开机命令。

从configurationpipe理器SP1开始，您可以使用唤醒代理客户端设置来补充传统的唤醒数据包方法。 唤醒代理使用对等协议并select计算机来检查子网上的其他计算机是否清醒，并在必要时将其唤醒。 当站点configuration为LAN唤醒并且客户端configuration为唤醒代理时，该过程如下工作：

1. 安装了Configuration Manager SP1客户端且未在子网上hibernate的计算机将检查子网上的其他计算机是否处于唤醒状态。 他们每5秒发送一次TCP / IP ping命令。

2. 如果没有来自其他电脑的回应，则认为是睡着了。 清醒的计算机成为子网的pipe理员计算机。

3. 由于计算机可能由于睡眠以外的原因（例如closures，从networking中移除，或者不再使用代理唤醒客户端设置）而可能无法响应，因此计算机当地时间每天下午2点发送一个唤醒包。 不响应的电脑将不再被认为是睡着了，不会被唤醒代理唤醒。

要支持唤醒代理，每个子网至less必须有三台计算机保持唤醒状态。 为了达到这个目的，三台计算机被非确定性地select为子网的监护计算机。 这意味着他们保持清醒，尽pipe任何configuration的电源策略hibernate一段时间后hibernate或hibernate。 监护计算机例如由于维护任务而closures关机或重启命令。 如果发生这种情况，其余的监护人计算机会唤醒子网上的另一台计算机，以便该子网继续拥有三台监护计算机。

pipe理员电脑要求networking交换机将睡眠电脑的networkingstream量redirect到自己。

pipe理员计算机广播使用睡眠计算机的MAC地址作为源地址的以太网帧来实现redirect。 这使得networking交换机的行为就好像睡觉的计算机已经移动到pipe理器计算机所在的相同端口一样。 pipe理员计算机还为睡眠的计算机发送ARP数据包，以使条目保持在ARPcaching中。 pipe理员计算机还将代表睡眠的计算机响应ARP请求，并回复睡眠计算机的MAC地址。

在此过程中，睡眠计算机的IP到MAC映射保持不变。 唤醒代理的工作方式是：通知networking交换机一个不同的networking适配器正在使用另一个networking适配器注册的端口。 但是，这种行为被称为MAC襟翼，对于标准的networking操作而言是不寻常的。 有些networking监视工具会查找这种行为，并可能认为出现了问题。 因此，当您使用唤醒代理时，这些监控工具可以生成警报或closures端口。 如果您的networking监视工具和服务不允许MAC襟翼，请不要使用唤醒代理。

4. 当一台pipe理员计算机看到一个新的睡眠计算机的TCP连接请求，并且请求是在hibernate前，睡眠计算机正在侦听的一个端口，pipe理员计算机发送一个唤醒数据包给睡眠的计算机，然后停止redirect这台电脑的stream量。

5. 睡觉的电脑收到唤醒包并醒来。 发送计算机自动重试连接，这次计算机是清醒的，可以响应。

参考： http : //technet.microsoft.com/en-us/library/dd8eb74e-3490-446e-b328-e67f3e85c779#BKMK_PlanToWakeClients

感谢所有在此发布并协助解决问题的人员，非常感谢。

ARP /广播风暴

• 我们看到来自用于桌面设备的VLAN 1，VLAN 1的大型广播数据包。 我们使用192.168.0.0/20 …
• Wiresharks显示，100台计算机正在用ARP广播淹没networking…

您的ARPinput过程很高，这意味着交换机花费大量时间处理ARP。 ARP泛滥的一个常见原因是交换机之间的环路。 如果你有一个循环，那么你也可以得到你上面提到的Mac皮瓣。 ARP泛滥的其他可能原因是：

• IP地址configuration错误
• 二层攻击，如ARP欺骗

首先消除上述错误configuration或二层攻击的可能性。 最简单的方法是在Linux机器上使用arpwatch （即使你必须在笔记本电脑上使用livecd ）。 如果你有configuration错误或者二层攻击，那么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皮瓣
• 生成树已通过思科TAC＆CCNP / CCIE合格人员的validation。 我们closures所有的冗余链接。

作为一个经历过这次比我想回忆的更多时间的人，不要以为你find了所有的冗余链接……只是让你的交换机端口在任何时候都performance出来。

由于您在交换机端口之间收到大量的mac襟翼，因此很难find违规者（假设您find两个或三个发送大量arps的mac地址，但源mac地址在端口之间不断抖动）。 如果您没有对每个边缘端口的MAC地址实施硬性限制，则无需手动拔下电缆（这是您想要避免的），就很难追踪这些问题。 交换机回路会导致networking中出现意想不到的path，并且可能会断断续续地从通常应该是桌面交换机端口的数百个Mac中学习。

减慢mac-moves最简单的方法是使用port-security 。 在连接到单个PC（无下游交换机）的Vlan 1中的每个接入交换机端口上，在您的cisco交换机上configuration以下接口级命令…

 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泛滥情况下，将此configuration应用于所有边缘交换机端口（特别是使用portfast的任何端口）将使您恢复到正常状态，因为configuration将closures任何超过三个mac地址的端口，并且禁用秘密环形portfast端口。 每个端口的三个mac是一个在我的桌面环境中运行良好的数字，但是你可以把它提高到10，可能没问题。 完成此操作后，任何第2层环都会断开，快速的皮瓣将停止，并且使诊断变得更容易。

另外还有一些全局命令可用于跟踪与广播风暴（mac-move）和洪泛（阈值）相关的端口…

 mac-address-table notification mac-move mac address-table notification threshold limit 90 interval 900 

完成之后，可以selectclear mac address-table以便从可能已满的CAM表中加速修复。

• 在不同的交换机和核心上显示MAC地址表（在核心上，例如，通过桌面直接插入，我的桌面），我们可以看到几个不同的MAC硬件地址被注册到接口，即使该接口有只有一台电脑连接到这…

这整个答案假定你的3750没有导致问题的错误（但你确实说wireshark表示PC正在泛滥）。 当Gi1 / 1/3只有一台计算机连接到计算机时，显示的显然是错误的，除非该计算机上有类似VMWare的东西。

其他的想法

基于我们之间的聊天对话，我可能不必提及那些明显的，但我会为了未来的访问者…

• 把任何用户放在Vlan1通常是一个坏主意（我知道你可能inheritance了一个混乱）
• 不pipeTAC告诉你什么，192.168.0.0/20太大而无法在单个交换域中进行pipe理，而没有二层攻击的风险。 你的子网掩码越大，你对第二层攻击的暴露就越大，因为ARP是未经validation的协议，路由器至less必须从该子网读取有效的ARP。
• 层2端口的风暴控制通常也是一个好主意， 但是，在这样的情况下，要搞好风暴控制，交通不好，交通畅通。 networking愈合后，在边缘端口和上行链路上应用一些风暴控制策略。

真正的问题是主机为什么发送这么多的ARP首先。 在这个问题得到解答之前，交换机将继续处理arp风暴。 networking掩码不匹配？ 低主机ARP计时器？ 一个（或多个）有“接口”路线的主机 ？ 一个胭脂无线桥梁的地方？ “无偿ARP”疯了？ DHCP服务器“使用中”探测？ 这听起来不像开关或第2层的问题; 你有东道主做坏事。

我的debugging过程将拔掉所有东西，并密切关注事物重新连接，一次一个端口。 （我知道这与理想距离很远，但是在某些时候你必须减less你的损失，并且尝试物理隔离任何可能的来源）。然后，我会努力理解为什么select端口会产生许多ARP。

（很多这些主机是不是Linux系统？Linux有一个非常愚蠢的ARPcachingpipe理系统，它将在几分钟之内“重新validation”一个条目的事实在我的书中被打破了在小型networking中，这个问题往往不是问题，但是一个/ 20不是一个小networking。）

这可能与您的问题有关，也可能不是，但我认为这可能是至less值得一提的东西：

我们目前在我们的一些远程站点有不less堆叠的3750x，大多数运行15.0.2（SE0到4，有一些SE0的FRU错误，我正在慢慢迁移）。

在例行的IOS更新中，从15.0.2到15.2-1（最近的SE），我们注意到一个非常显着的CPU增加，从非平均时间的平均约30％到60％和更高。 我已经查看过configuration和IOS更改日志，并一直在思科的TAC。 据TAC说，他们似乎是在他们认为这是一些IOS 15.2-1错误的地步。

随着我们继续调查CPU的增加，我们开始看到大量的ARPstream量，直到我们的ARP表完全填满，导致networking不稳定。 这个临时拐杖是在我们的语音和数据VLAN上手动将我们的ARP超时从默认值（14400）恢复到300。

减lessARP超时后，我们稳定了一个星期左右的时间，在这一点上，我们返回到IOS 15.0.2-SE4，并删除了我们的非默认ARP超时。 我们的CPU使用率回落到30％左右，我们的ARP表问题也不存在。

一个简单的，但可能被忽视; 你的客户有一个有效的默认网关，是不是你的核心做了很多代理arps。 你可以考虑取消你的3750的IP代理ARPfunction？