ARP-Broadcast-Flooding-Netzwerk und hohe CPU-Auslastung

Wenn wir hoffen, dass jemand hier einen Einblick in das Problem bekommt, mit dem wir konfrontiert sind. Derzeit haben wir Cisco TAC, die den Fall untersuchen, aber sie kämpfen, um die Grundursache zu finden.

Obwohl der Titel ARP-Broadcast und eine hohe CPU-Auslastung erwähnt, sind wir uns nicht sicher, ob sie zu diesem Zeitpunkt zusammenhängen oder nicht.

Die ursprüngliche Ausgabe wurde in der INE Online Community veröffentlicht

Wir haben das Netzwerk auf eine einzige Verbindung ohne Redundanzeinrichtung reduziert und betrachten es als Sterntopologie.

Fakten:

• Wir verwenden 3750x-Switches, 4 in einem Stapel. Version 15.0 (1) SE3. Cisco TAC bestätigt, dass für diese bestimmte Version keine Probleme mit hoher CPU- oder ARP-Auslastung bekannt sind.
• Es sind keine Hubs / nicht verwalteten Switches verbunden
• Neu geladener Core Stack
• Wir haben keine Standardroute "Ip route 0.0.0.0 0.0.0.0 f1 / 0". Verwenden von OSPF für das Routing.
• Wir sehen große Broadcast-Pakete von VLAN 1, VLAN 1, die für Desktop-Geräte verwendet werden. Wir verwenden 192.168.0.0/20
• Cisco TAC sagte, sie sehen nichts falsch mit der Verwendung von / 20, sonst hätten wir eine große Broadcast-Domain, sollten aber trotzdem funktionieren.
• WLAN, Verwaltung, Drucker usw. befinden sich alle in einem unterschiedlichen VLAN
• Der Spanning Tree wurde von Cisco TAC- und CCNP / CCIE-qualifizierten Personen verifiziert. Wir schalten alle redundanten Verbindungen ab.
• Die Konfiguration auf dem Core wurde von Cisco TAC überprüft.
• Wir haben das Standard-ARP-Timeout für die meisten Switches.
• Wir implementieren keine Q & Q.
• Es wurden keine neuen Schalter hinzugefügt (zumindest keine, von denen wir wissen)
• Die dynamische Arp-Prüfung kann nicht für Edge-Switches verwendet werden, da es sich um 2950 handelt
• Wir haben show interfaces | verwendet inc line | broadcast, um herauszufinden, woher die große Anzahl von Broadcasts stammt. Sowohl Cisco TAC als auch zwei andere Techniker (CCNP & CCIE) haben jedoch bestätigt, dass dies aufgrund der Netzwerkereignisse (wie bei einer großen Anzahl von Mac-Flaps) ein normales Verhalten ist verursacht die größere Sendung). Wir haben überprüft, ob der STP an den Edge-Switches ordnungsgemäß funktioniert.

Symptome im Netzwerk und Switches:

• Große Anzahl von MAC-Klappen
• Hohe CPU-Auslastung für ARP-Eingabeprozess
• Riesige Anzahl von ARP-Paketen, schnell ansteigend und sichtbar
• Wiresharks zeigt, dass Hunderte von Computern das Netzwerk mit ARP Broadcast überfluten
• Zu Testzwecken haben wir ca. 80 Desktop-Computer mit unterschiedlichem VLAN eingesetzt. Wir haben dies jedoch getestet und keinen sichtbaren Unterschied zur hohen CPU- oder Arp-Eingabe gemacht
• Haben verschiedene AV / Malware / Spyware ausgeführt, aber keine Viren im Netzwerk sichtbar.
• sh mac address-table count, zeigt uns ungefähr 750 verschiedene mac-adressen wie auf vlan 1 erwartet.

#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

• Zeigen Sie die MAC-Adresstabelle auf verschiedenen Switches und dem Core selbst an (auf dem Core, z. B. direkt vom Desktop, meinem Desktop), und sehen Sie, dass die verschiedenen MAC-Hardwareadressen auf der Schnittstelle registriert sind, obwohl diese Schnittstelle über eine verfügt nur ein Computer ist daran angeschlossen:

 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

• plattform tcam auslastung anzeigen

 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

Wir sind jetzt in einer Phase, in der wir eine enorme Menge an Ausfallzeiten benötigen, um jeden Bereich zu isolieren, es sei denn, jemand anderes hat Ideen, um die Ursache oder den Grund für dieses seltsame und bizarre Problem zu identifizieren.

Aktualisieren

Vielen Dank an @MikePennington und @RickyBeam für die ausführliche Antwort. Ich werde versuchen zu antworten, was ich kann.

• Wie bereits erwähnt, ist 192.168.0.0/20 ein ererbtes Durcheinander. Wir haben jedoch die Absicht, dies in Zukunft aufzuteilen, aber leider trat dieses Problem auf, bevor wir dies tun konnten. Ich persönlich stimme auch der Mehrheit zu, wobei die Broadcast-Domain viel zu groß ist.
• Die Verwendung von Arpwatch ist definitiv etwas, das wir ausprobieren können, aber ich vermute, dass mehrere Access-Ports die Mac-Adresse registrieren, obwohl sie nicht zu diesem Port gehört. Die Schlussfolgerung von Arpwatch ist möglicherweise nicht hilfreich.
• Ich bin völlig damit einverstanden, nicht zu 100% sicher zu sein, dass alle redundanten Links und unbekannten Switches im Netzwerk gefunden werden. Dies ist jedoch nach unserem besten Wissen der Fall, bis wir weitere Beweise finden.
• Die Hafensicherheit wurde geprüft. Leider hat das Management aus verschiedenen Gründen beschlossen, diese nicht zu verwenden. Gemeinsamer Grund ist, dass wir ständig Computer bewegen (College-Umgebung).
• Wir haben Spanning-Tree Portfast mit in Verbindung mit Spanning-Tree Bpduguard standardmäßig auf allen Access-Ports (Desktop-Maschinen) verwendet.
• Wir verwenden im Moment keinen nicht verhandelbaren Switchport für den Access-Port, aber es werden keine Vlan-Hopping-Angriffe über mehrere Vlans übertragen.
• Gibt eine Benachrichtigung über die Mac-Adressentabelle aus und prüft, ob wir Muster finden können.

"Da zwischen den Switchports eine große Anzahl von MAC-Klappen angezeigt wird, ist es schwierig zu ermitteln, wo sich die Täter befinden. Angenommen, Sie finden zwei oder drei Mac-Adressen, die viele Arps senden, aber die Quell-Mac-Adressen klappen weiterhin zwischen den Ports."

• Wir begannen damit, wählten eine MAC-Klappe aus und setzten unseren Weg durch den gesamten Core-Switch zur Distribution zum Access-Switch fort. Aber wir stellten erneut fest, dass die Access-Port-Schnittstelle mehrere Mac-Adressen überfüllte, daher auch die Mac-Klappen. Also zurück zu Platz eins.
• Wir haben die Sturmkontrolle in Betracht gezogen, befürchten jedoch, dass einige der legitimen Pakete verworfen werden und weitere Probleme verursachen.
• Prüft die VMHost-Konfiguration dreimal.
• @ytti die unerklärlichen MAC-Adressen stecken hinter vielen Access-Ports eher als eine Einzelperson. Es wurden keine Schleifen auf diesen Schnittstellen gefunden. Die MAC-Adressen existieren auch an anderen Schnittstellen, was eine große Anzahl von MAC-Klappen erklären würde
• @ RickyBeam Ich stimme zu, warum Hosts so viele ARP-Anfragen senden. Dies ist eines der rätselhaften Themen. Rouge Wireless Bridge ist eine interessante Brücke, an die ich noch nicht gedacht habe. Soweit wir wissen, befindet sich Wireless in einem anderen VLAN. Aber Rogue wird offensichtlich bedeuten, dass es sich möglicherweise um ein VLAN1 handelt.
• @ RickyBeam, ich möchte nicht wirklich alles vom Stromnetz trennen, da dies massive Ausfallzeiten zur Folge hat. Dies ist jedoch, wo es nur Überschrift sein kann. Wir haben Linux-Server, aber nicht mehr als 3.
• @ RickyBeam, können Sie erklären, dass der DHCP-Server gerade überprüft wird?

Wir (Cisco TAC, CCIEs, CCNP) sind uns global einig, dass dies keine Switch-Konfiguration ist, sondern dass ein Host / Gerät das Problem verursacht.

Gelöst

Das Problem liegt bei SCCM 2012 SP1, einem Dienst namens ConfigMrg Wake-Up Proxy . Die 'Funktion' ist in SCCM 2012 RTM nicht vorhanden.

Innerhalb von 4 Stunden nach dem Deaktivieren dieser Option innerhalb der Richtlinie wurde ein stetiger Rückgang der CPU-Auslastung festgestellt. Nach Ablauf von 4 Stunden betrug die ARP-Auslastung lediglich 1-2%!

Zusammenfassend lässt sich sagen, dass dieser Dienst MAC-Adress-Spoofing ausführt! Ich kann nicht glauben, wie viel Chaos es angerichtet hat.

Unten finden Sie einen vollständigen Text von Microsoft Technet, da ich der Meinung bin, dass es wichtig ist, zu verstehen, wie dies mit dem veröffentlichten Problem zusammenhängt.

Für alle Interessierten finden Sie nachfolgend die technischen Details.

Configuration Manager unterstützt zwei Wake-on-Local-Area-Network-Technologien (LAN), um Computer im Energiesparmodus zu aktivieren, wenn Sie die erforderliche Software wie Softwareupdates und -anwendungen installieren möchten: herkömmliche Wake-up-Pakete und AMT-Einschaltbefehle.

Ab Configuration Manager SP1 können Sie die herkömmliche Methode für Reaktivierungspakete mithilfe der Einstellungen für den Reaktivierungs-Proxy-Client ergänzen. Der Wake-up-Proxy verwendet ein Peer-to-Peer-Protokoll und ausgewählte Computer, um zu überprüfen, ob andere Computer im Subnetz aktiv sind, und um sie gegebenenfalls zu aktivieren. Wenn die Site für Wake-On-LAN konfiguriert ist und Clients für den Wake-Up-Proxy konfiguriert sind, funktioniert der Prozess wie folgt:

1. Computer, auf denen der Configuration Manager SP1-Client installiert ist und die nicht im Subnetz schlafen, prüfen, ob andere Computer im Subnetz aktiv sind. Dazu senden sie sich alle 5 Sekunden einen TCP / IP-Ping-Befehl.

2. Wenn keine Antwort von anderen Computern eingeht, wird davon ausgegangen, dass diese eingeschlafen sind. Die Computer, die wach sind, werden zu Manager-Computern für das Subnetz.

3. Da es möglich ist, dass ein Computer aus einem anderen Grund als dem Schlaf nicht reagiert (z. B. wenn er ausgeschaltet, aus dem Netzwerk entfernt oder die Proxy-Wake-Up-Client-Einstellung nicht mehr angewendet wird), sind dies die Computer schickte jeden Tag um 14 Uhr Ortszeit ein Weckpaket. Computer, die nicht reagieren, werden nicht mehr als eingeschlafen angesehen und nicht vom Weck-Proxy geweckt.

Zur Unterstützung des Wake-Up-Proxys müssen mindestens drei Computer für jedes Subnetz aktiviert sein. Um dies zu erreichen, werden drei Computer nicht deterministisch als Schutzcomputer für das Subnetz ausgewählt. Dies bedeutet, dass sie trotz einer konfigurierten Energierichtlinie wach bleiben, um nach einer Zeit der Inaktivität in den Ruhezustand oder Ruhezustand zu wechseln. Guardian-Computer berücksichtigen Befehle zum Herunterfahren oder Neustarten, z. B. aufgrund von Wartungsaufgaben. In diesem Fall reaktivieren die verbleibenden Guardian-Computer einen anderen Computer im Subnetz, sodass das Subnetz weiterhin über drei Guardian-Computer verfügt.

Manager-Computer fordern den Netzwerk-Switch auf, den Netzwerkverkehr für die schlafenden Computer auf sich selbst umzuleiten.

Die Umleitung wird erreicht, indem der Manager-Computer einen Ethernet-Frame sendet, der die MAC-Adresse des schlafenden Computers als Quelladresse verwendet. Dadurch verhält sich der Netzwerk-Switch so, als ob der in den Ruhezustand versetzte Computer an denselben Port verschoben wurde, an dem sich der Manager-Computer befindet. Der Manager-Computer sendet auch ARP-Pakete für die schlafenden Computer, um den Eintrag im ARP-Cache aktuell zu halten. Der Manager-Computer antwortet auch auf ARP-Anfragen im Namen des schlafenden Computers und mit der MAC-Adresse des schlafenden Computers.

Während dieses Vorgangs bleibt die IP-zu-MAC-Zuordnung für den schlafenden Computer unverändert. Der Weck-Proxy informiert den Netzwerk-Switch, dass ein anderer Netzwerkadapter den von einem anderen Netzwerkadapter registrierten Port verwendet. Dieses Verhalten wird jedoch als MAC-Klappe bezeichnet und ist für den normalen Netzwerkbetrieb ungewöhnlich. Einige Netzwerküberwachungstools suchen nach diesem Verhalten und können davon ausgehen, dass etwas nicht stimmt. Infolgedessen können diese Überwachungstools Warnungen generieren oder Ports schließen, wenn Sie den Weck-Proxy verwenden. Verwenden Sie keinen Weck-Proxy, wenn Ihre Netzwerküberwachungstools und -dienste keine MAC-Flaps zulassen.

4. Wenn ein Manager-Computer eine neue TCP-Verbindungsanforderung für einen schlafenden Computer sieht und die Anforderung an einen Port gerichtet ist, den der schlafende Computer abgehört hat, bevor er in den Schlafmodus versetzt wurde, sendet der Manager-Computer ein Reaktivierungspaket an den schlafenden Computer beendet die Weiterleitung des Datenverkehrs für diesen Computer.

5. Der schlafende Computer empfängt das Weckpaket und wacht auf. Der sendende Computer versucht automatisch, die Verbindung erneut herzustellen. Diesmal ist der Computer aktiv und kann reagieren.

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

Vielen Dank für alle, die hier gepostet und bei der Fehlerbehebung mitgewirkt haben, sehr geschätzt.

ARP / Broadcast-Sturm

• Wir sehen große Broadcast-Pakete von VLAN 1, VLAN 1, die für Desktop-Geräte verwendet werden. Wir verwenden 192.168.0.0/20 ...
• Wiresharks zeigt, dass Hunderte von Computern das Netzwerk mit ARP Broadcast überfluten ...

Ihr ARP-Eingabeprozess ist hoch, was bedeutet, dass der Switch viel Zeit für die Verarbeitung von ARPs benötigt. Eine sehr häufige Ursache für ARP-Flooding ist eine Schleife zwischen Ihren Switches. Wenn Sie eine Schleife haben, können Sie auch die oben erwähnten Mac-Klappen erhalten. Andere mögliche Ursachen für ARP-Überschwemmungen sind:

• IP-Adressenkonfigurationsfehler
• Ein Layer2-Angriff, z. B. Arp-Spoofing

Beseitigen Sie zuerst die Möglichkeit von Fehlkonfigurationen oder einen oben erwähnten Layer2-Angriff. Am einfachsten geht das mit arpwatch auf einem Linux-Rechner (auch wenn Sie eine Live-CD auf einem Laptop verwenden müssen). Wenn Sie eine Fehlkonfiguration oder einen Layer2-Angriff haben, gibt Ihnen arpwatch im Syslog solche Meldungen, in denen die Mac-Adressen aufgelistet sind, die um dieselbe IP-Adresse kämpfen ...
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)

Wenn Sie "Flip-Flops" sehen, müssen Sie die Quelle der Mac-Adressen ausfindig machen und herausfinden, warum sie um dieselbe IP kämpfen.

• Große Anzahl von MAC-Klappen
• Der Spanning Tree wurde von Cisco TAC- und CCNP / CCIE-qualifizierten Personen verifiziert. Wir schalten alle redundanten Verbindungen ab.

Wenn Sie als jemand sprechen, der dies öfter durchgemacht hat, als ich mich erinnern möchte, gehen Sie nicht davon aus, dass Sie alle redundanten Links gefunden haben. Stellen Sie einfach sicher, dass sich Ihre Switchports jederzeit verhalten.

Da zwischen den Switchports eine große Anzahl von Mac-Flaps angezeigt wird, ist es schwierig zu ermitteln, wo sich die Täter befinden (nehmen wir an, Sie finden zwei oder drei Mac-Adressen, die viele Arps senden, aber die Quell-Mac-Adressen flattern weiterhin zwischen den Ports). Wenn Sie kein festes Limit für Mac-Adressen pro Edge-Port festlegen, ist es sehr schwierig, diese Probleme aufzuspüren, ohne die Kabel manuell abzuziehen (was Sie vermeiden möchten). Switch-Loops verursachen einen unerwarteten Pfad im Netzwerk, und Sie könnten mit Hunderten von Macs fertig werden, die zeitweise von einem Desktop-Switchport gelernt wurden.

Der einfachste Weg, die Mac-Moves zu verlangsamen, ist mit port-security. Konfigurieren Sie auf jedem Zugriffs-Switchport in Vlan 1, der mit einem einzelnen PC verbunden ist (ohne Downstream-Switch), die folgenden Befehle auf Schnittstellenebene auf Ihren Cisco-Switches ...

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

In den meisten Fällen von Mac / ARP-Flooding führt das Anwenden dieser Konfiguration auf alle Edge-Switch-Ports (insbesondere auf alle Ports mit Portfast) wieder zu einem vernünftigen Zustand, da die Konfiguration alle Ports herunterfährt, die drei Mac-Adressen überschreiten, und eine geheime Deaktivierung durchführt geschlungener portfast Port. Drei Macs pro Port sind eine Nummer, die in meiner Desktop-Umgebung gut funktioniert, aber Sie könnten sie auf 10 erhöhen und wahrscheinlich in Ordnung sein. Nachdem Sie dies getan haben, werden alle Layer-2-Loops unterbrochen, schnelle Mac-Flaps hören auf und die Diagnose wird erheblich erleichtert.

Ein paar weitere globale Befehle, die nützlich sind, um Ports zu finden, die mit einem Broadcast-Sturm (Mac-Move) und einer Überschwemmung (Threshold) verbunden sind ...

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

Wenn Sie fertig sind, können Sie optional einen clear mac address-tableSchritt ausführen, um die Heilung von einer möglicherweise vollen CAM-Tabelle zu beschleunigen.

• Zeigen Sie die MAC-Adresstabelle auf verschiedenen Switches und dem Core selbst an (auf dem Core, z. B. direkt vom Desktop, meinem Desktop), und sehen Sie, dass die verschiedenen MAC-Hardwareadressen auf der Schnittstelle registriert sind, obwohl diese Schnittstelle über eine verfügt nur ein Computer an diese angeschlossen ...

Diese ganze Antwort geht davon aus, dass Ihr 3750 keinen Fehler hat, der das Problem verursacht (aber Sie sagten, dass Wireshark PCs anzeigt, die überfluten). Was Sie uns zeigen, ist offensichtlich falsch, wenn nur ein Computer an Gi1 / 1/3 angeschlossen ist, es sei denn, auf diesem PC ist so etwas wie VMWare installiert.

Verschiedene Gedanken

Aufgrund eines Gesprächs, das wir geführt haben, muss ich das Offensichtliche wahrscheinlich nicht erwähnen, aber ich werde es für zukünftige Besucher tun ...

• Es ist normalerweise eine schlechte Idee, Benutzer in Vlan1 einzubinden (ich verstehe, dass Sie möglicherweise ein Chaos geerbt haben).
• Unabhängig davon, was Ihnen TAC sagt, ist 192.168.0.0/20 zu groß, um in einer einzelnen Switch-Domäne ohne das Risiko von Layer2-Angriffen verwaltet zu werden. Je größer Ihre Subnetzmaske ist, desto größer ist die Gefährdung durch solche Layer2-Angriffe, da ARP ein nicht authentifiziertes Protokoll ist und ein Router mindestens ein gültiges ARP aus diesem Subnetz lesen muss.
• Storm-Control auf Layer2-Ports ist normalerweise ebenfalls eine gute Idee. Wenn Sie jedoch die Sturmkontrolle in einer solchen Situation aktivieren, wird der gute Verkehr mit dem schlechten Verkehr beendet. Wenden Sie nach der Wiederherstellung des Netzwerks einige Richtlinien zur Sturmkontrolle auf Ihre Edge-Ports und Uplinks an.

Die eigentliche Frage ist, warum Hosts überhaupt so viele ARPs senden. Solange dies nicht beantwortet wird, wird es den Schaltern weiterhin schwer fallen, mit dem Arp-Sturm umzugehen. Netzmaske stimmt nicht überein? Niedrige Host-Arp-Timer? Ein (oder mehrere) Hosts mit einer "Schnittstellen" -Route? Irgendwo eine kabellose Brücke? "Gratuitous Arp" verrückt geworden? "In-Use" -Prüfung des DHCP-Servers? Es klingt nicht nach einem Problem mit den Schaltern oder Schicht 2; Sie haben Gastgeber, die schlechte Dinge tun.

Mein Debugging-Prozess würde darin bestehen, alles vom Computer zu trennen und zu beobachten, wie die Dinge portweise wieder verbunden werden. (Ich weiß, es ist meilenweit vom Ideal entfernt, aber irgendwann müssen Sie Ihre Verluste reduzieren und versuchen, alle möglichen Quellen physisch zu isolieren.) Dann würde ich darauf hinarbeiten, zu verstehen, warum bestimmte Ports einige viele Arps erzeugen.

(Würden viele dieser Hosts Linux-Systeme sein? Linux hatte ein sehr doofes ARP-Cache-Management-System. Die Tatsache, dass es einen Eintrag in nur wenigen Minuten "erneut verifizieren" wird, ist in meinem Buch kaputt In kleinen Netzwerken ist dies in der Regel weniger problematisch, aber a / 20 ist kein kleines Netzwerk.)

Dies mag mit Ihrem Problem zusammenhängen oder auch nicht, aber ich dachte, es könnte sich lohnen, es zumindest hinauszuwerfen:

Wir haben derzeit eine ganze Reihe von 3750x in einigen unserer Remote-Standorte gestapelt, meistens mit 15.0.2 (SE0 bis 4, es gibt einige FRU-Fehler mit SE0, von denen ich langsam wegmigriere).

Während eines routinemäßigen IOS-Updates von 15.0.2 auf 15.2-1 (neueste SE) haben wir einen ziemlich signifikanten CPU-Anstieg festgestellt, von durchschnittlich 30% auf 60% und höher in Zeiten außerhalb der Spitzenzeiten. Ich habe Konfigurationen und IOS-Änderungsprotokolle überprüft und mit dem TAC von Cisco zusammengearbeitet. Laut TAC scheinen sie an dem Punkt zu sein, an dem sie glauben, dass dies ein IOS 15.2-1-Fehler ist.

Als wir den CPU-Anstieg weiter untersuchten, stellten wir fest, dass sich die ARP-Tabellen vollständig füllten und zu Netzwerkinstabilität führten. Die vorübergehende Krücke dafür war, unsere ARP-Zeitüberschreitungen manuell von Standard (14400) auf 300 in unseren Sprach- und Daten-Vlans zurückzusetzen.

Nachdem wir unsere ARP-Zeitüberschreitungen verringert hatten, waren wir ungefähr eine Woche stabil. Zu diesem Zeitpunkt kehrten wir zu IOS 15.0.2-SE4 zurück und entfernten unsere nicht standardmäßigen ARP-Zeitüberschreitungen. Unsere CPU-Auslastung ist wieder auf ~ 30% gesunken, und es gibt keine Probleme mit der ARP-Tabelle.

Eine ganz einfache, aber vielleicht übersehene; Haben Ihre Clients ein gültiges Standardgateway? Tun Sie nicht viele Proxy-Arps? Sie könnten erwägen, die IP-Proxy-Arp-Funktion auf Ihrem 3750 zu negieren?