Cisco "ARP Input"-Prozess verbraucht alle Ressourcen wg. Netzwerk-Loop

lordgurke
Goto Top
Hallo,

ich habe hier zwei Cisco-Router stehen, auf denen mehrere VLANs verwaltet werden.
An einem dieser Router ist ein Catalyst-Switch (L2-Image) angeschlossen, welcher für MSTP konfiguriert ist.
An ebendiesem ist ein weiterer, unmanaged Switch an einem Access-Port angeschlossen, auf welchem ein Loop produziert wurde.
Warum und weshalb dieser Loop nicht durch den Catalyst erkannt wurde ist eine Sache, die ich noch herausfinden muss - jedenfalls zeigte der Catalyst während dem "Event" an, dass mit STP alles in Ordnung sei und alle Ports dieses VLANs auf Forwarding gesetzt waren. Aber das ist eine andere Windmühle...

Im Verlauf dieses Loop-Events jedenfalls erreichten unter anderem etwa 4.000 ARP-Pakete pro Sekunde den Router, welcher sich ihrer annahm und dem "ARP Input"-Prozess 100% CPU-Zeit schenkte.
Das führte nicht nur zu interessanten Effekten mit währenddessen ablaufenden ARP-Entries anderer VLANs, es führte letztlich auch zu flatternden BGP- und OSPF-Sessions, da diese offenbar nicht genug Rechenzeit bekamen und irgendwelche Sessions immer wieder in Timeout liefen. Und zwar auf beiden Routern (die VLANs sind zwischen den Routern ebenfalls erreichbar).

Jetzt frage ich mich: Gibt es nicht eine Möglichkeit, die ARP-Verarbeitung so zu priorisieren dass wenigstens die BGP-Sessions nicht darunter leiden?
Der Traffic wäre weder für den Switch noch für die Router ein Problem gewesen - nur eben die CPU-Last war es und die hat beide Router ordentlich beeinträchtigt.
Natürlich sollte STP solche Loops erkennen und die Paketwelle stoppen, aber mehr als ein Fangnetz wäre ja durchaus wünschenswert face-wink

Gibt es eventuell auch eine Art Rate-Limit für ARP-Pakete pro VLAN? Das wäre ja die eleganteste Lösung...
Bisher konnte ich nichts dazu in den Dokumentationen finden...


Danke!

Content-Key: 347446

Url: https://administrator.de/contentid/347446

Ausgedruckt am: 13.08.2022 um 11:08 Uhr

Mitglied: brammer
Lösung brammer 27.08.2017 um 20:52:15 Uhr
Goto Top
Hallo,

@LordGurke,

Dein Stichwort sollte "Rate Limiting of ARP Packets" sein.
https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/12-2/31s ...
Das Beispiel solte auch auf einem 2960 gehen... auch wenn der Artikel für einen 4500 Catalyst ist...
Allerdings solltest du den unmanaged Switch gegen einen Cisco tauschen....

Brammer
Mitglied: 134058
134058 27.08.2017 aktualisiert um 21:30:26 Uhr
Goto Top
Zitat von @LordGurke:

An einem dieser Router ist ein Catalyst-Switch (L2-Image) angeschlossen, welcher für MSTP konfiguriert ist.
An ebendiesem ist ein weiterer, unmanaged Switch an einem Access-Port angeschlossen, auf welchem ein Loop produziert wurde.
Warum und weshalb dieser Loop nicht durch den Catalyst erkannt wurde ist eine Sache, die ich noch herausfinden muss - jedenfalls zeigte der Catalyst während dem "Event" an, dass mit STP alles in Ordnung sei und alle Ports dieses VLANs auf Forwarding gesetzt waren.
Nach der zitierten Aussage ist die redundante Verbindung am unmanaged Switch gepatcht.
Die Schleife hätte also der unmanaged Switch per STP erkennen und auflösen müssen. Der Catalyst könnte nur die (einzige)Verbindung zwischen den Geräten trennen, was STP nicht vorsieht.

portfast sollte deaktiviert sein, Priorität (Root, Brückennnummern) sinnvoll gewählt:
https://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-p ...
Mitglied: LordGurke
LordGurke 28.08.2017 um 00:01:58 Uhr
Goto Top
@brammer: Danke, das muss ich mir hier im Laboraufbau mal genauer ansehen. Wenn ich irgendwie vermeiden kann, dass das Interface auf "Err-Disable" wechselt könnte das ziemlich exakt das sein was ich suche.

@134058: Der unmanaged Switch kann vermutlich kein STP. Aber nichtsdestotrotz hätte der Cisco das als "Self-Looped" erkennen und blockieren müssen (dass das funktioniert habe ich bereits selbst gesehen). Es sei denn natürlich, dass der andere Switch die STP-Nachrichten und BPDUs verschluckt und der Cisco so nicht erkennen kann, dass er seine eigenen Pakete über das selbe Interface zurückbekommt.
Ansonsten ist Portfast auf dem Interface deaktiviert - aber das nützt ja auch wenig, wenn jemand an dem seit Wochen angeschlossenen Switch ein Kabel falsch anschließt face-wink

Den unmanaged Switch kann ich nicht austauschen - es ist ja nicht meiner. Das ist der vom Kunden in seinem Server-Rack.
In dieses Rack führt nur ein Kabel von dem Cisco-Accessport.
Mitglied: aqui
aqui 28.08.2017 um 14:08:12 Uhr
Goto Top
Warum und weshalb dieser Loop nicht durch den Catalyst erkannt wurde ist eine Sache, die ich noch herausfinden muss -
Wenn du das mit Spanning Tree machst geht das nur über verschieden Ports und unterschiedliche BPDUs.
Wenn die eigene BPDU z.B. am gleichen Port loopt erkennt das der Switch nicht.
Das ist der Klassiker wie man Netze ohne Loop Protection immer in die Knie zwinget.
Einen kleinen billigen 5 Port Noname Switch anschliessen an dem man zuvor 2 Ports geloopt hat face-wink

Das kannst du nur mit einem Loop Protection Feature schützen. Hast du das auf dem Cisco aktiviert ??
https://www.cisco.com/c/en/us/td/docs/server_nw_virtual/2-10-0_release/c ...