Frage ARP Broadcast Flooding Network und hohe CPU-Auslastung


Ich hoffe, dass jemand hier Einblick in das Thema hat, dem wir gegenüberstehen. Zur Zeit haben wir Cisco TAC, der sich den Fall ansieht, aber sie kämpfen darum, die Ursache zu finden.

Obwohl der Titel ARP-Broadcast und hohe CPU-Auslastung erwähnt, sind wir unsicher, ob sie in diesem Stadium verwandt oder nicht verwandt sind.

Das ursprüngliche Problem wurde behoben geposted in der INE Online Community

Wir haben das Netzwerk auf eine einzige Verbindung reduziert, keine Redundanzkonfiguration, sondern eine Sterntopologie.

Fakten:

  • Wir verwenden 3750x Switches, 4 in einem Stack. Version 15.0 (1) SE3. Cisco TAC bestätigt keine bekannten Probleme für hohe CPU- oder ARP-Fehler für diese spezielle Version.
  • Keine Hubs / Unmanaged Switches angeschlossen
  • Reloaded Core-Stapel
  • Wir haben keine Standardroute "Ip route 0.0.0.0 0.0.0.0 f1 / 0". OSPF für das Routing verwenden
  • 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, dass sie mit der Verwendung von / 20 nichts falsch finden, anderenfalls hätten wir eine große Broadcast-Domäne, sollten aber weiterhin funktionieren.
  • Wifi, Management, Drucker usw. befinden sich alle in einem anderen VLAN
  • Spanning Tree wurde von Cisco TAC und CCNP / CCIE qualifizierten Personen verifiziert. Wir beenden alle redundanten Verbindungen.
  • Konfiguration auf dem Kern wurde Cisco TAC verifiziert.
  • Wir haben das Standard-ARP-Timeout für die Mehrzahl der Switches.
  • Wir implementieren Q & Q nicht
  • Es wurden keine neuen Switches hinzugefügt (zumindest keine, die wir kennen)
  • Dynamische Arp-Inspektion an Edge-Switches kann nicht 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 kommt, jedoch sowohl Cisco TAC als auch 2 andere Ingenieure (CCNP & CCIE) bestätigten, dass dies normales Verhalten ist, was im Netzwerk passiert (wie bei einer großen Anzahl von Mac-Klappen) verursacht die größere Sendung). Wir haben überprüft, dass das STP an den Edge-Switches korrekt funktioniert.

Symptome im Netzwerk und bei den Switches:

  • Große Anzahl von MAC-Klappen
  • Hohe CPU-Auslastung für den ARP-Eingabeprozess
  • Sehr große Anzahl von ARP-Paketen, die schnell ansteigen und sichtbar werden
  • Wiresharks zeigt, dass Hunderte von Computern das Netzwerk mit ARP Broadcast überschwemmen
  • Zu Testzwecken haben wir ca. 80 Desktop-Rechner mit unterschiedlichen VLANs ausgestattet, jedoch haben wir dies getestet und keinen sichtbaren Unterschied zu High-CPU- oder ARP-Input gemacht
  • Haben verschiedene AV / Malware / Spyware ausgeführt, aber keine Viren im Netzwerk sichtbar.
  • sh mac address-table count, zeigt uns ca. 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
  • Ran Show MAC Adress-Tabelle auf verschiedenen Switches und Kern selbst (auf dem Kern, zum Beispiel, von Desktop direkt, meinen Desktop gesteckt), und wir können die verschiedenen MAC-Hardware-Adresse registriert werden, die auf der Schnittstelle registriert, obwohl diese Schnittstelle hat nur ein Computer an diesem 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 Nutzung 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 befinden uns jetzt in einem Stadium, in dem wir große Ausfallzeiten benötigen, um jeden Bereich auf einmal zu isolieren, es sei denn, jemand anders hat einige Ideen, um die Quelle oder die Ursache dieses seltsamen und bizarren Problems zu identifizieren.


Aktualisieren

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

  • Wie bereits erwähnt, ist 192.168.0.0/20 ein vererbtes Chaos. Wir beabsichtigen jedoch, dies in Zukunft aufzuteilen, aber unglücklicherweise ist dieses Problem aufgetreten, bevor wir dies tun konnten. Ich stimme auch persönlich 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, da mehrere Access-Ports die MAC-Adresse registrieren, obwohl sie nicht zu diesem Port gehören, ist die Schlussfolgerung von arpwatch möglicherweise nicht nützlich.
  • Ich bin vollkommen damit einverstanden, dass ich nicht 100% ig sicher bin, alle redundanten Links und unbekannten Switches im Netzwerk zu finden, aber wie wir am besten feststellen, ist dies der Fall, bis wir weitere Beweise finden.
  • Port Security wurde untersucht, leider hat das Management entschieden, dies aus verschiedenen Gründen nicht zu verwenden. Allgemeiner Grund ist, dass wir ständig Computer umherbewegen (College-Umgebung).
  • Wir haben Spanning-Tree PortFast in Verbindung mit Spanning-Tree bpduguard standardmäßig auf allen Access-Ports (Desktop-Maschinen) verwendet.
  • Wir verwenden im Moment keinen Switchport, der nicht auf dem Zugriffsport verhandelt, aber wir bekommen keinen Vlan-Hoppingangriff, der über Multiple-Vlans springt.
  • Wir werden die Benachrichtigung über die Mac-Adress-Tabelle geben und sehen, ob wir irgendwelche Muster finden können.

"Da Sie eine große Anzahl von MAC-Klappen zwischen den Switchports bekommen,   es ist schwer zu finden, wo die Täter sind (Angenommen, Sie finden zwei oder   drei Mac-Adressen, die viele Arps senden, aber die Quelle Mac   Adressen flattern zwischen den Ports). "

  • Wir begannen damit, wählten irgendwelche MAC-Klappen aus und setzten unseren Weg durch alle Core-Switches fort, um Zugriff auf den Switch zu bekommen, aber was wir fanden, war wieder einmal, die Access-Port-Schnittstelle hatte mehrere Mac-Adressen und damit Mac-Flaps; also zurück auf Platz eins.
  • Sturmkontrolle ist etwas, das wir in Betracht gezogen haben, aber wir befürchten, dass einige der legitimen Pakete fallengelassen werden, was zu weiteren Problemen führt.
  • Prüft die VMHost-Konfiguration dreifach.
  • @ytti die unerklärlichen MAC-Adressen sind hinter vielen Access-Ports eher als ein Individuum. Habe auf diesen Schnittstellen keine Schleifen 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; Das ist eines der rätselhaften Probleme. Rouge Wireless Bridge ist eine interessante, an die ich nicht gedacht habe, soweit wir wissen, ist Wireless auf verschiedenen VLANs; aber Gauner wird offensichtlich bedeuten, dass es gut auf VLAN1 sein könnte.
  • @ RickyBeam, ich möchte nicht wirklich alles trennen, da dies zu einer enormen Ausfallzeit führen wird. Dies ist jedoch der Punkt, an dem es gerade geht. Wir haben Linux-Server, aber nicht mehr als 3.
  • @RickyBeam, können Sie DHCP-Server "In-Use" -Sondieren erklären?

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


18
2017-10-26 14:26


Ursprung


Ich würde bemerken: Wenn es keine Schleifen im Netzwerk gibt, sollten Mac-Klappen nicht passieren. Der einzige andere logische Grund wären VMs, die denselben MAC verwenden. (oder einige Boneinhead hat mehrere Nics gesetzt, um den gleichen MAC zu verwenden)
@ColdT, ich habe meine Antwort aktualisiert, da ich ein paar Dinge in meiner ursprünglichen Antwort falsch gelesen habe. - Mike Pennington
Haben Sie eine große Anzahl unerklärlicher MAC-Adressen hinter vielen Ports oder nur einem Port? Kann der Port geloopt werden? Bleiben die MAC-Adressen hinter diesem Port oder erscheinen sie auch hinter anderen Ports? Haben wir PCAP für das ARP? Eine große Anzahl von MAC-Klappen ist sicherlich nicht normal, es impliziert, dass sich die Topologie ständig ändert oder dass Sie eine nicht verwaltete Schleife im Netzwerk haben.
@ColdT, ich denke, Sie sollten sich erneut mit dem Management über Port-Sicherheit befassen; Ich gab Ihnen speziell Konfigurationen, die es PCs ermöglichen, zwischen den Switchports zu wechseln. switchport port-security aging time 5 und switchport port-security aging type inactivity bedeutet, dass Sie Stationen nach 5 Minuten Inaktivität zwischen Ports verschieben können oder wenn Sie den Port-Sicherheitseintrag manuell löschen. Diese Konfiguration verhindert jedoch Mac-Klappen zwischen den Zugriffsports des Switches, da die Ports nicht die gleiche MAC-Adresse von einem anderen Port beziehen können. - Mike Pennington
Erwähnenswert ist auch, dass Arpwatch keinen Flip-Flop registriert, es sei denn, es gibt unterschiedliche ARPs für dieselbe IP-Adresse. Unabhängig vom Grund müssen Sie wissen, wann das passiert. Mere Mac Floods sind nicht genug, um Arpwatch zu verwirren - Mike Pennington


Antworten:


Gelöst.

Das Problem ist mit SCCM 2012 SP1, einem Service namens: ConfigMrg-Wake-Up-Proxy. Das 'Feature' existiert nicht SCCM 2012 RTM.

Innerhalb von 4 Stunden nach der Deaktivierung der Richtlinie sahen wir einen stetigen Rückgang der CPU-Auslastung. Zu der Zeit 4 Stunden war ARP Nutzung nur 1-2%!

Zusammenfassend führt dieser Dienst Spoofing von MAC-Adressen durch! Ich kann nicht glauben, wie viel Chaos das verursacht hat.

Im Folgenden finden Sie einen vollständigen Text von Microsoft Technet, da es wichtig zu verstehen ist, wie sich dies auf das Problem bezieht.

Für alle, die interessiert sind, sind unten die technischen Details.

Configuration Manager unterstützt zwei lokale Netzwerke (LAN)   Technologien, um Computer im Schlafmodus zu aktivieren, wenn Sie möchten   Installieren Sie die erforderliche Software, z. B. Software-Updates und Anwendungen:   traditionelle Wake-Up-Pakete und AMT-Einschaltbefehle.

Ab Configuration Manager SP1 können Sie die   traditionelle Wake-Up-Paket-Methode, indem der Wake-Up-Proxy-Client verwendet wird   die Einstellungen. Wake-up-Proxy verwendet ein Peer-to-Peer-Protokoll und gewählt   Computer, um zu überprüfen, ob andere Computer im Subnetz wach sind,   und wecken sie wenn nötig. Wenn die Site für Wake On konfiguriert ist   LAN und Clients sind für den Wake-up-Proxy konfiguriert, der Prozess funktioniert wie   folgt:

  1. Computer, auf denen der Configuration Manager SP1-Client installiert ist und die im Subnetz nicht schlafen, überprüfen, ob andere Computer eingeschaltet sind   das Subnetz ist wach. Sie tun dies, indem sie sich gegenseitig einen TCP / IP-Ping senden   Befehl alle 5 Sekunden.

  2. Wenn von anderen Computern keine Antwort erfolgt, wird davon ausgegangen, dass sie schlafen. Die Computer, die wach sind, werden Managercomputer für   das Subnetz.

  3. Da es möglich ist, dass ein Computer aus einem anderen Grund nicht reagiert, als er schläft (z. B. ist er ausgeschaltet,   aus dem Netzwerk entfernt, oder die Proxy-Wake-up-Client-Einstellung ist nein   länger angewendet), werden den Computern jeden Tag ein Weckpaket geschickt   2 P.M. Ortszeit. Computer, die nicht antworten, werden nicht mehr sein   angenommen, dass er schläft und nicht durch Weckruf geweckt wird.

Um Wake-up-Proxy zu unterstützen, müssen mindestens drei Computer aktiviert sein   jedes Subnetz. Um dies zu erreichen, sind drei Computer   nicht-deterministisch als Wächtercomputer für das Subnetz ausgewählt werden.   Das bedeutet, dass sie trotz konfigurierter Strompolitik wach bleiben   nach einer Zeit der Inaktivität zu schlafen oder zu überwintern. Guardian Computer   Abhold oder Neustart Befehle zum Beispiel als Folge von   Wartungsaufgaben. Wenn das passiert, die restlichen Wächter-Computer   wecken Sie einen anderen Computer im Subnetz, damit das Subnetz weitermacht   Habe drei Wächtercomputer.

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

Die Umleitung wird erreicht, indem der Manager einen Computer ausstrahlt   Ethernet-Frame, der die MAC-Adresse des Schlafcomputers als   Quelladresse Dies bewirkt, dass sich der Netzwerkschalter so verhält, als ob der   Der schlafende Computer ist zum selben Port wie der Managercomputer gewechselt   ist eingeschaltet. Der Managercomputer sendet auch ARP-Pakete für das Schlafen   Computer, um den Eintrag im ARP-Cache frisch zu halten. Der Geschäftsführer   Der Computer antwortet auch auf ARP-Anfragen im Namen des Sleeping   Computer und antworten Sie mit der MAC-Adresse des schlafenden Computers.

Während dieses Vorgangs bleibt das IP-zu-MAC-Mapping für den schlafenden Computer gleich. Der Wake-up-Proxy funktioniert, indem er den Netzwerk-Switch informiert   dass ein anderer Netzwerkadapter den Port verwendet, der registriert wurde   von einem anderen Netzwerkadapter. Dieses Verhalten wird jedoch als MAC bezeichnet   Klappe und ist ungewöhnlich für den normalen Netzwerkbetrieb. Irgendein Netzwerk   Überwachungstools suchen dieses Verhalten und können davon ausgehen   ist falsch. Folglich können diese Überwachungstools Warnungen generieren oder   Schließen Sie die Ports, wenn Sie den Wake-up-Proxy verwenden. Verwenden Sie keinen Weck-Proxy   wenn Ihre Tools und Dienste zur Netzwerküberwachung keine MAC-Klappen zulassen.

  1. Wenn ein Manager-Computer eine neue TCP-Verbindungsanforderung für einen schlafenden Computer sieht und die Anfrage an einen Port gerichtet ist, wird der Schlafmodus ausgeführt   Computer hörte zu, bevor es zu schlafen ging, der Manager   Computer sendet ein Weckpaket an den schlafenden Computer und dann   stoppt die Umleitung von Datenverkehr für diesen Computer.

  2. Der schlafende Computer empfängt das Weckpaket und wacht auf. Der sendende Computer wiederholt automatisch die Verbindung und diesmal   Der Computer ist wach und kann antworten.

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

Danke für alle, die hier gepostet und bei der Fehlersuche geholfen haben, sehr geschätzt.


12
2017-11-14 14:04





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 überschwemmen   ...

Ihr ARP-Eingabeprozess ist hoch, was bedeutet, dass der Switch viel Zeit für die Verarbeitung von ARPs aufwendet. 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:

  • Fehlkonfigurationen der IP-Adresse
  • Ein Layer2-Angriff, wie z Arp Spoofing

Beseitigen Sie zuerst die Möglichkeit von Fehlkonfigurationen oder einem Layer2-Angriff, die oben erwähnt wurden. Der einfachste Weg dies zu tun ist mit Arpuhr auf einem Linux - Rechner (auch wenn Sie einen livecd auf einem Laptop). Wenn du eine Fehlkonfiguration oder einen Layer2-Angriff hast, dann gibt dir arpwatch solche Nachrichten in syslog, die die Mac-Adressen auflisten, die über die gleiche 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 aufspüren und herausfinden, warum sie sich über die gleiche IP-Adresse streiten.

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

Wenn Sie als jemand sprechen, der das öfter durchgemacht hat, als ich gerne zurückrufen würde, gehen Sie nicht davon aus, dass Sie alle überflüssigen Links gefunden haben ... machen Sie Ihre Switchports immer so, dass sie sich ständig verhalten.

Da Sie eine große Anzahl von Mac-Klappen zwischen Switchports bekommen, ist es schwer zu finden, wo die Täter sind (Angenommen, Sie finden zwei oder drei Mac-Adressen, die viele Arps senden, aber die Quell-Mac-Adressen flattern zwischen den Ports). Wenn Sie nicht eine harte Grenze für Mac-Adressen pro Edge-Port erzwingen, ist es sehr schwierig, diese Probleme zu verfolgen, ohne manuell Kabel zu entfernen (was Sie vermeiden wollen). Switch-Loops verursachen einen unerwarteten Pfad im Netzwerk, und Sie könnten mit Hunderten von Macs enden, die intermittierend von einem normalen 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 der 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 mac / ARP-Flooding-Fällen bringt das Anwenden dieser Konfiguration auf alle Edge-Switch-Ports (insbesondere auf Ports mit Portfast) einen normalen Zustand zurück, da die Konfiguration jeden Port, der drei Mac-Adressen überschreitet, außer Betrieb setzt und ein Secret deaktiviert geschleifter 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, sind alle Layer 2 Schleifen gebrochen, schnelle Mac Klappen werden aufhören, und es macht die Diagnose viel einfacher.

Noch ein paar globale Kommandos, die nützlich sind, um Ports ausfindig zu machen, die mit einem Broadcast-Sturm (mac-move) und Flooding (Schwellwert) verbunden sind ...

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

Wenn Sie fertig sind, tun Sie dies optional clear mac address-table um die Heilung von einer möglicherweise vollen CAM-Tabelle zu beschleunigen.

  • Ran Show MAC Adress-Tabelle auf verschiedenen Switches und Kern selbst (auf dem Kern, zum Beispiel, von Desktop direkt, meinen Desktop gesteckt), und wir können die verschiedenen MAC-Hardware-Adresse registriert werden, die auf der Schnittstelle registriert, obwohl diese Schnittstelle hat nur ein Computer an diesem ...

Diese ganze Antwort geht davon aus, dass Ihre 3750 keinen Bug hat, der das Problem verursacht (aber Sie haben gesagt, dass wireshark PCs anzeigte, die überschwemmen). Was Sie uns zeigen, ist offensichtlich falsch, wenn nur ein Computer an Gi1 / 1/3 angeschlossen ist, es sei denn, der PC hat etwas wie VMWare darauf.

Andere Gedanken

Basierend auf einer Chat-Konversation, die wir hatten, muss ich das Offensichtliche wahrscheinlich nicht erwähnen, aber ich werde für zukünftige Besucher ...

  • Es ist normalerweise eine schlechte Idee, irgendwelche Benutzer in Vlan1 zu setzen (ich verstehe, dass Sie eine Unordnung geerbt haben).
  • Unabhängig davon, was Ihnen TAC sagt, ist 192.168.0.0/20 zu groß, um in einer einzigen Switched-Domäne ohne die Gefahr von Layer2-Angriffen zu verwalten. Je größer Ihre Subnetzmaske ist, desto größer ist die Offenlegung, die Sie für Layer2-Angriffe haben, da ARP ein nicht authentifiziertes Protokoll ist und ein Router mindestens einen gültigen ARP aus diesem Subnetz lesen muss.
  • Storm-control auf Layer2-Ports ist in der Regel eine gute Idee; In einer Situation wie dieser ermöglicht sie jedoch eine gute Kontrolle über den Verkehr mit dem schlechten Verkehr. Nachdem das Netzwerk geheilt ist, wenden Sie an Ihren Edge-Ports und Uplinks einige Storm-Control-Richtlinien an.

10
2017-10-26 15:41



Eigentlich ist seine tcam nicht ausgereizt. Die erste Spalte ist die maximale, die zweite die aktuelle Verwendung. Sie können den Teil "Masken gegen Werte" ignorieren. Von hier klingt es wie ein "einfacher" Arpsturm, aber ohne Kenntnis seiner Topologie und des tatsächlichen Verkehrs kann ich nicht erraten, warum.
Fairer Punkt Ricky, danke für die Hervorhebung - Mike Pennington


Die eigentliche Frage ist, warum Hosts so viele ARPs an erster Stelle senden. Bis dies beantwortet ist, wird es den Schaltern weiterhin schwerfallen, sich mit dem ARP-Sturm zu befassen. Netzmasken-Mismatch? Niedrige Host-ARP-Timer? Ein oder mehr) Gastgeber eine "Schnittstellen" -Route haben? Eine rouge drahtlose Brücke irgendwo? "Gratuit Arp" verrückt geworden? DHCP-Server "In-Use" Sondieren? Es klingt nicht wie ein Problem mit den Schaltern oder Schicht 2; Sie haben Gastgeber, die schlechte Dinge tun.

Mein Debugging-Prozess würde alles trennen und genau beobachten, wie die Dinge, Port für Port wieder angehängt werden. (Ich weiß, es ist meilenweit vom Ideal entfernt, aber irgendwann müssen Sie Ihre Verluste reduzieren und versuchen, mögliche Quellen physisch zu isolieren). Dann würde ich darauf hinarbeiten, zu verstehen, warum ausgewählte Ports einige viele ARPs erzeugen.

(Wäre eine Menge dieser Hosts Linux-Systeme? Linux hat ein sehr dummes ARP-Cache-Management-System. Die Tatsache, dass es einen Eintrag in wenigen Minuten "verifiziert", ist in meinem Buch gebrochen In kleinen Netzwerken ist das weniger ein Problem, aber a / 20 ist kein kleines Netzwerk.


2
2017-10-26 19:29





Dies mag mit deinem Problem zusammenhängen oder auch nicht, aber ich dachte mir, dass es etwas wert ist, zumindest dort hinauszuwerfen:

Wir haben derzeit ziemlich viele gestapelte 3750x in einigen unserer Remote-Sites, meist mit 15.0.2 (SE0 bis 4, es gibt einige FRU Bugs mit SE0, von denen ich langsam weg migriere).

Während eines routinemäßigen IOS-Updates, das von 15.0.2 auf 15.2-1 (neueste SE) ging, bemerkten wir einen ziemlich bedeutenden CPU-Anstieg von durchschnittlich etwa 30% auf 60% und mehr außerhalb der Spitzenzeiten. Ich habe Konfigurationen und IOS-Änderungsprotokolle überprüft und mit der TAC von Cisco gearbeitet. Laut TAC scheinen sie an dem Punkt zu sein, an dem sie glauben, dass dies ein IOS 15.2-1 Bug ist.

Als wir den CPU-Anstieg weiter untersuchten, begannen wir massive Mengen an ARP-Verkehr zu sehen, bis unsere ARP-Tabellen vollständig gefüllt waren und Netzwerkinstabilität verursacht wurde. Die zeitweilige Krücke dafür war, unsere ARP-Timeouts von Standard (14400) auf 300 auf unseren Sprach- und Daten-VLANs manuell zu sichern.

Nachdem wir unsere ARP-Timeouts reduziert hatten, waren wir ungefähr ein paar Wochen stabil. Zu diesem Zeitpunkt kehrten wir zu IOS 15.0.2-SE4 zurück und entfernten unsere nicht standardmäßigen ARP-Timeouts. Unsere CPU-Auslastung ist wieder auf ~ 30% gesunken und unsere ARP-Tabellenprobleme sind nicht existent.


1
2017-10-29 13:29



interessante Geschichte ... danke für das Teilen, obwohl es vielleicht helfen könnte, ein Bugid hinzuzufügen, so dass es einfacher ist zu erkennen, ob das OP offen gelegt ist. Zu Ihrer Information: Es ist oft eine gute Idee, Ihr ARP-Zeitlimit niedriger als Ihren CAM-Timer zu halten. - Mike Pennington
Vielen Dank für den Kommentar, aber angesichts des ursprünglichen Problems verwenden wir derzeit eine niedrigere IOS-Version über den Stack und war ziemlich stabil für einige Zeit. @MikePennington Standardmäßig ist das ARP-Timeout auf 4 Stunden und das CAM-Timeout auf 5 Minuten eingestellt. Ist das nicht der Fall? - Cold T
@ColdT, deshalb habe ich das erwähnt. Für einige HSRP-Fälle Ciscos CAM / ARP-Timer brechen standardmäßig ab. Wenn es keinen zwingenden Grund gibt, setze ich meine arp timeout 240 auf allen SVI / L3-Schnittstellen, die einem Switch gegenüberstehen. - Mike Pennington


Eine einfache, aber vielleicht übersehene; Verfügen Ihre Clients über ein gültiges Standard-Gateway, werden nicht viele Proxy-Arps ausgeführt? Sie könnten überlegen, die IP-Proxy-ARP-Funktion auf Ihrem 3750 zu negieren?


0
2017-10-28 21:58