ARP廣播泛洪網路和高cpu使用率
希望這裡的人可能對我們面臨的問題有所了解。目前，我們有 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）在全球範圍內都同意這不是交換機配置，而是主機/設備導致了問題。
解決了。
問題在於 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 並且客戶端配置為喚醒代理時，過程如下：
- 安裝了 Configuration Manager SP1 客戶端並且在子網上未處於睡眠狀態的電腦會檢查子網上的其他電腦是否處於喚醒狀態。他們通過每 5 秒互相發送一個 TCP/IP ping 命令來做到這一點。
- 如果其他電腦沒有響應，則假定它們處於睡眠狀態。喚醒的電腦成為子網的管理器電腦。
- 由於電腦可能由於睡眠以外的其他原因（例如，它已關閉、從網路中刪除或不再應用代理喚醒客戶端設置）而沒有響應，因此電腦是每天當地時間下午 2 點發送一個叫醒包。沒有響應的電腦將不再被假定為處於睡眠狀態，並且不會被喚醒代理喚醒。
要支持喚醒代理，每個子網必須至少有三台電腦處於喚醒狀態。為了實現這一點，三台電腦被不確定地選擇為子網的監護電腦。這意味著它們保持清醒，儘管任何配置的電源策略在一段時間不活動後進入睡眠或休眠狀態。Guardian 電腦遵守關閉或重新啟動命令，例如，作為維護任務的結果。如果發生這種情況，剩餘的監護電腦會喚醒子網上的另一台電腦，以便子網繼續擁有三台監護電腦。
管理器電腦要求網路交換機將睡眠電腦的網路流量重定向到它們自己。
重定向是通過管理電腦廣播乙太網幀來實現的，該幀使用休眠電腦的 MAC 地址作為源地址。這使得網路交換機的行為就像睡眠電腦已移動到管理器電腦所在的同一埠一樣。管理器電腦還為睡眠電腦發送 ARP 數據包，以使 ARP 記憶體中的條目保持新鮮。管理器電腦也會代表休眠電腦響應 ARP 請求，並回复休眠電腦的 MAC 地址。
在此過程中，睡眠電腦的 IP 到 MAC 映射保持不變。喚醒代理通過通知網路交換機另一個網路適配器正在使用另一個網路適配器註冊的埠來工作。但是，這種行為稱為 MAC 翻動，對於標準網路操作來說是不常見的。一些網路監控工具會尋找這種行為，並可以假設有問題。因此，這些監控工具可以在您使用喚醒代理時生成警報或關閉埠。如果您的網路監控工具和服務不允許 MAC 抖動，請不要使用喚醒代理。
- 當管理器電腦看到對睡眠電腦的新 TCP 連接請求，並且該請求是針對睡眠電腦在進入睡眠之前正在偵聽的埠時，管理器電腦向睡眠電腦發送喚醒數據包，然後停止為此電腦重定向流量。
- 睡眠中的電腦接收到喚醒數據包並喚醒。發送電腦自動重試連接，這一次，電腦處於喚醒狀態並可以響應。
感謝所有在這裡發帖並協助故障排除過程的人，非常感謝。