4
Cisco "ARP Input"-Prozess verbraucht alle Ressourcen wg. Netzwerk-Loop
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
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!
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
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!
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 347446
Url: https://administrator.de/contentid/347446
Printed on: April 16, 2024 at 12:04 o'clock
4 Comments
Latest comment
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
@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
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.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.
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.
show spanning-tree [ blockedports | inconsistentports | pathcost method ]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 ...
@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
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.
@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
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.
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
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 ...