主页 / server / 问题 / 555066
Accepted
Cold T
Asked: 2013-10-27 06:26:18 +0800 CST

ARP广播泛洪网络和高cpu使用率

  • 772

希望这里的人可能对我们面临的问题有所了解。目前，我们有 Cisco 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 超时。
  • 我们不实施问答。
  • 没有添加新的开关（至少我们不知道）
  • 不能在边缘交换机上使用动态 arp 检查，因为这些是 2950
  • 我们使用了显示接口 | inc line|broadcast 以确定大量广播来自何处，但是 Cisco TAC 和其他 2 位工程师（CCNP 和 CCIE）都证实这是由于网络上发生的事情而导致的正常行为（如大量 MAC 抖动）导致更大的广播）。我们验证了 STP 在边缘交换机上正常运行。

网络和交换机上的症状：

  • 大量 MAC 抖动
  • ARP 输入进程的高 CPU 使用率
  • 海量ARP报文，快速增长且可见
  • Wiresharks 显示 100 台计算机正在使用 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
  • Ran show mac address-table on differentswitchs and core本身（在core上，比如直接被桌面插上，我的桌面），我们可以看到接口注册了几个不同的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 上；但流氓显然意味着它很可能在 VLAN1 上。
  • @RickyBeam，我真的不想拔掉所有东西，因为这会导致大量停机。然而，这可能只是它的发展方向。我们确实有 Linux 服务器，但不超过 3 个。
  • @RickyBeam，你能解释一下 DHCP 服务器“使用中”的探测吗？

我们（思科 TAC、CCIE、CCNP）在全球范围内都同意这不是交换机配置，而是主机/设备导致了问题。

cisco

5 个回答

  1. Best Answer

    解决了。

    问题在于 SCCM 2012 SP1，该服务名为：ConfigMrg Wake-Up Proxy。“功能”不存在 SCCM 2012 RTM。

    在策略内关闭此功能后的 4 小时内，我们看到 CPU 使用率稳步下降。到 4 小时结束时，ARP 使用率仅为 1-2%！

    综上所述，该服务进行MAC地址欺骗！无法相信它造成了多大的破坏。

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

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

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

    从 Configuration Manager SP1 开始，您可以通过使用唤醒代理客户端设置来补充传统的唤醒数据包方法。唤醒代理使用点对点协议和选定的计算机来检查子网上的其他计算机是否处于唤醒状态，并在必要时唤醒它们。当站点配置为 Wake On LAN 并且客户端配置为唤醒代理时，过程如下：

    1. 安装了 Configuration Manager SP1 客户端并且在子网上未处于睡眠状态的计算机会检查子网上的其他计算机是否处于唤醒状态。他们通过每 5 秒互相发送一个 TCP/IP ping 命令来做到这一点。

    2. 如果其他计算机没有响应，则假定它们处于睡眠状态。唤醒的计算机成为子网的管理器计算机。

    3. 由于计算机可能由于睡眠以外的其他原因（例如，它已关闭、从网络中删除或不再应用代理唤醒客户端设置）而没有响应，因此计算机是每天当地时间下午 2 点发送一个叫醒包。没有响应的计算机将不再被假定为处于睡眠状态，并且不会被唤醒代理唤醒。

    要支持唤醒代理，每个子网必须至少有三台计算机处于唤醒状态。为了实现这一点，三台计算机被不确定地选择为子网的监护计算机。这意味着它们保持清醒，尽管任何配置的电源策略在一段时间不活动后进入睡眠或休眠状态。Guardian 计算机遵守关闭或重新启动命令，例如，作为维护任务的结果。如果发生这种情况，剩余的监护计算机会唤醒子网上的另一台计算机，以便子网继续拥有三台监护计算机。

    管理器计算机要求网络交换机将睡眠计算机的网络流量重定向到它们自己。

    重定向是通过管理计算机广播以太网帧来实现的，该帧使用休眠计算机的 MAC 地址作为源地址。这使得网络交换机的行为就像睡眠计算机已移动到管理器计算机所在的同一端口一样。管理器计算机还为睡眠计算机发送 ARP 数据包，以使 ARP 缓存中的条目保持新鲜。管理器计算机也会代表休眠计算机响应 ARP 请求，并回复休眠计算机的 MAC 地址。

    在此过程中，睡眠计算机的 IP 到 MAC 映射保持不变。唤醒代理通过通知网络交换机另一个网络适配器正在使用另一个网络适配器注册的端口来工作。但是，这种行为称为 MAC 翻动，对于标准网络操作来说是不常见的。一些网络监控工具会寻找这种行为，并可以假设有问题。因此，这些监控工具可以在您使用唤醒代理时生成警报或关闭端口。如果您的网络监控工具和服务不允许 MAC 抖动，请不要使用唤醒代理。

    1. 当管理器计算机看到对睡眠计算机的新 TCP 连接请求并且该请求是对睡眠计算机在进入睡眠之前侦听的端口时，管理器计算机向睡眠计算机发送唤醒数据包，然后停止为此计算机重定向流量。

    2. 睡眠中的计算机接收到唤醒数据包并唤醒。发送计算机自动重试连接，这一次，计算机处于唤醒状态并可以响应。

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

    感谢所有在这里发帖并协助故障排除过程的人，非常感谢。

    • 12

  2. ARP/广播风暴

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

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

    • IP 地址配置错误
    • 第 2 层攻击，例如arp 欺骗

    首先消除上述错误配置或layer2攻击的可能性。最简单的方法是在 linux 机器上使用arpwatch（即使您必须在笔记本电脑上使用livecd）。如果您有错误配置或第 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-moves 的最简单方法是使用port-security. 在连接到单个 PC（没有下游交换机）的 Vlan 1 中的每个接入交换机端口上，在您的 cisco 交换机上配置以下接口级命令...

    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 表中恢复。

    • Ran show mac address-table on differentswitchs and core本身（在core上，比如直接被桌面插上，我的桌面），我们可以看到接口注册了几个不同的MAC硬件地址，虽然那个接口有只有一台电脑连接到这个...

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

    其他想法

    根据我们的聊天对话，我可能不必提及显而易见的事情，但为了未来的访客，我会...

    • 将任何用户放入 Vlan1 通常是一个坏主意（我知道你可能继承了一个烂摊子）
    • 无论 TAC 告诉您什么，192.168.0.0/20 都太大而无法在单个交换域中进行管理，而没有第 2 层攻击的风险。您的子网掩码越大，您就越容易受到这样的 layer2 攻击，因为 ARP 是未经身份验证的协议，路由器必须至少从该子网读取有效的 ARP。
    • 对 layer2 端口进行风暴控制通常也是一个好主意；然而，在这样的情况下启用风暴控制，它将把好的流量和坏的流量一起带走。网络恢复后，在边缘端口和上行链路上应用一些风暴控制策略。
    • 10

  3. 真正的问题是为什么主机首先会发送如此多的 ARP。在此问题得到答复之前，交换机将继续难以应对 arp 风暴。网络掩码不匹配？低主机arp计时器？一个（或多个）主机具有“接口”路由？某处的胭脂无线网桥？“免费arp”疯了吗？DHCP服务器“使用中”探测？这听起来不像是开关或第 2 层的问题。你有主机做坏事。

    我的调试过程将拔掉所有东西，并在重新连接时密切观察，一次一个端口。（我知道它离理想还有几英里，但在某些时候你必须减少损失并尝试物理隔离任何可能的来源）然后我会努力理解为什么选择端口会生成许多 arp。

    （会不会有很多主机碰巧是 linux 系统？Linux 有一个非常愚蠢的 ARP 缓存管理系统。它会在几分钟内“重新验证”一个条目的事实，在我的书中被打破了. 它在小型网络中往往不是问题，但 /20 不是小型网络。）

    • 2

  4. 这可能与您手头的问题有关，也可能不相关，但是我认为它可能至少值得扔在那里：

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

    在例行 IOS 更新期间，从 15.0.2 升级到 15.2-1（最近的 SE），我们注意到 CPU 显着增加，在非高峰时间从平均约 30% 到 60% 甚至更高。我查看了配置和 IOS 更改日志，并且一直在使用 Cisco 的 TAC。根据 TAC 的说法，他们似乎已经到了认为这是一些 IOS 15.2-1 错误的地步。

    随着我们继续调查 CPU 的增加，我们开始看到大量的 ARP 流量，以至于我们的 ARP 表完全填满并导致网络不稳定。对此的临时支持是手动将我们的语音和数据 vlan 上的 ARP 超时从默认值 (14400) 恢复到 300。

    减少 ARP 超时后，我们稳定了一周左右，此时我们返回到 IOS 15.0.2-SE4，并删除了我们的非默认 ARP 超时。我们的 CPU 利用率回落到 30% 左右，并且我们的 ARP 表问题不存在。

    • 1

  5. 一个失败的简单但可能被忽视的；您的客户是否有有效的默认网关，您的核心不是在做很多代理 arp。你可以考虑取消3750上的ip proxy arp功能吗？

    • 0

相关问题