Kunden-GAU: Router haengt sich auf und blockiert...

[Koppelfeld]

Hallo,
Großes Problem, keine Lösung, wenig Hinweise:

Nach einer Woche stabilen Betriebs steigt die Last eines 1781A
auf 100% und nichts geht mehr im Netz.

Dummerweise läuft auch die Telephonie darüber.

Der Router hängt sich nach 3 Sekunden weg.

Ein Kunde hatte unlängst das gleiche Szenario, welches er löste, indem er einen ganz bestimmten Win-PC, der ihm suspekt erschien, aus dem Netz entfernte.

Alles lief gut. Direkt nach Einstecken des PC ging der LANCOM reproduzierbar in einen Loop. Mehrfach.
Leider hat der Kunde nichts weiter untersucht, sondern den PC in die Tonne getreten.

Hat jemand eine Ahnung, was passiertbsein könnte?

[Jirka]

Hallo Koppelfeld,

Nach einer Woche stabilen Betriebs steigt die Last eines 1781A
auf 100% und nichts geht mehr im Netz.

fragt sich, was zu dem Zeitpunkt passiert ist... (Syslog?)
Über welche Firmware reden wir eigentlich?
Habe einen vergleichbaren Fall gerade am Wickel gehabt heute, mit 9.10 und 9.20 lief alles gut, mit 9.24(.0099) CPU-Last am Anschlag. Grund war ein Loop in der dem LANCOM nachgelagerten HP-Switch (Port 1 und 6 waren an eine weitere unmanagebare Switch angeschlossen). Mit dem Loop haben die (und der LANCOM) ca. 10 Monate gelebt, es gab mitunter ein paar Probleme, ja, aber im Großen und Ganzen ging alles. Mit der 9.24 war's dann aus. Das Positive daran, der Loop-Fehler wurde entdeckt. Ansonsten frage ich mich, warum die 9.24 da nicht mit klar kommt, oder was da genau passiert ist...

Der Router hängt sich nach 3 Sekunden weg.

Bootlog.

Alles lief gut. Direkt nach Einstecken des PC ging der LANCOM reproduzierbar in einen Loop. Mehrfach.

Bootlog.

Leider hat der Kunde nichts weiter untersucht, sondern den PC in die Tonne getreten.

Schlecht. Ich versuche das immer, aber oft geht's halt nicht, weil der laufende Betrieb ja nun nicht schon wieder gestört werden soll...

Viele Grüße,
Jirka

[Koppelfeld]

Alles lief gut. Direkt nach Einstecken des PC ging der LANCOM reproduzierbar in einen Loop. Mehrfach.

Bootlog.

Der Router war ja nicht abgestürzt.

Als ich dann heute abend dazukam, klappte alles wie vorgesehen.
Aber es gab ganz irre Meldungen von der "DDOS"-Detection, mit
Quell-IPs von z.B. 127.22.6.33, beliebigem Quellport und Zielport 0 gegen die LAN-IP des LANCOM.

Ich habe jetzt das eigentliche Routing auf ein Mini-Serverchen übertragen, mal sehen, was morgen passiert.

[Jirka]

Hallo Koppelfeld,

was meinst Du denn damit, dass der LANCOM reproduzierbar in einen Loop ging? Ich hatte das so verstanden, dass er immer wieder abstürzte und neu startete, aber das war ja nicht so, wie Du schreibst.

Viele Grüße,
Jirka

[Koppelfeld]

Hallo Koppelfeld,
was meinst Du denn damit, dass der LANCOM reproduzierbar in einen Loop ging? Ich hatte das so verstanden, dass er immer wieder abstürzte und neu startete, aber das war ja nicht so, wie Du schreibst.

Hallo Jirka,
Ich hatte zunächst "im Kreis laufende" Pakete im Sinn.
So ein Loop über ein mächtiges LAN setzt viele Komponenten außer Gefecht.
Ich sah dann allerdings 'queue erros' auf den LANCOM.
Nun, der Router hängt aneinem unterirdischen Switch.
Kann es sein, daß die Flow conttrol nicht übereinstimmt?

[backslash]

Hi Koppelfeld

Ich sah dann allerdings 'queue erros' auf den LANCOM.

das spricht dann aber wieder für einen "Teilchenbeschleuniger"... "queue errors" werden gezählt, wenn der Ethernet-Chip ein Paket empfangen hat, es aber keinen Puffer mehr für das Paket gibt - und das passiert nur, wenn das Gerät massiv "zugeballert" wird (oder die Puffer aufgrund eines Bugs verloren gehen)

Gruß
Backslash

[GrandDixence]

queue errors" werden gezählt, wenn der Ethernet-Chip ein Paket empfangen hat, es aber keinen Puffer mehr für das Paket gibt - und das passiert nur, wenn das Gerät massiv "zugeballert" wird (oder die Puffer aufgrund eines Bugs verloren gehen)

Siehe auch:
http://www.lancom-forum.de/aktuelle-lan ... 13660.html

[Koppelfeld]

Guten Abend!

"queue errors" werden gezählt, wenn der Ethernet-Chip ein Paket empfangen hat, es aber keinen Puffer mehr für das Paket gibt - und das passiert nur, wenn das Gerät massiv "zugeballert" wird (oder die Puffer aufgrund eines Bugs verloren gehen)

Dumm nur, daß, wenn diese Situation beim Kunden - beim letzten Mal aus heiterem Himmel nach 5 Tagen störungsfreien Betriebs - urplötzlich auftreten, der Router nicht mehr erreichbar ist.

Wir sehen völlig unsinnige Pakete von nichtexistenten MACs mit Ziel Router-Lan-Interface und Zielport 0 von wechselnden Quell-IPs mit 127(!).x.x.x. Bloß: Wenn der Spuk vorbei ist, ist er vorbei. Dann geht es wieder gut. Und dann haut es wieder 'rein und blockiert 20 Leute in einer kleinen Werbeagentur. Unschön.
Das Problem habe ich erstmal umgangen, indem ich ein Intel-Serverchen mit ein paar Netfilter-Regeln für das betroffene VLAN zum Router gemacht habe. Da kann man dann auch besser nachgucken.

[Jirka]

Hallo Koppelfeld,

Kann es sein, daß die Flow control nicht übereinstimmt?

also auf LANCOM-Seite kann man im Status schauen, ob Flow control ausgehandelt wurde. Auf der anderen Seite sollte das auch gehen, immerhin soll das ja eine Switch sein... So, und dann kannst Du Dir die Frage selber beantworten...

Mit Hilfe von Ethernet Flow Control (dt. Flusssteuerung; standardisiert nach IEEE 802.3x) kann in einem Full-duplex-Ethernet-Link der Gegenseite signalisiert werden, dass eine Sendepause gewünscht ist, d. h. zurzeit keine weiteren Frames zugesandt werden sollen und für welchen Zeitraum diese Pause gewünscht ist. Damit soll verhindert werden, dass Pakete verworfen werden, was aus Sicht des Empfängers passieren würde, wenn der Sender weiter senden würde und die Daten dann weder zwischengespeichert noch weiter transportiert werden könnten.
Bei dem Verfahren handelt es sich um eine Funktionalität, die von der Hardware des jeweiligen Ethernet-Controllers bereitgestellt wird. Wenn der Empfänger-Ethernet-Port davon ausgeht, temporär keine Daten mehr annehmen zu können, schickt er einen Pause-Frame, und die Sender-Hardware auf der anderen Seite wertet diesen automatisch aus – völlig ohne Eingriff des Treibers, der den Ethernet-Controller bedient. Üblicherweise gibt es keine Rückmeldung von der Hardware, dass ein Flow Control-Pause-Frame empfangen wurde. Der Treiber stellt lediglich fest, dass die Pakete, die er der Hardware zum Senden gegeben hat, zeitweilig nicht gesendet werden, was im Endeffekt dazu führt, dass die Pakete sich eine Stufe weiter vorne in einer LCOS-Queue aufstauen und da dann verworfen werden, wenn die Aufnahmekapazität überschritten wird.
Die Konfiguration von Flow Control ist ähnlich wie beim Duplex-Modus: Entweder zwei Ethernet-Ports handeln sie als Teil der Autonegotiation aus, oder sie muss auf beiden Seiten gleich und fix konfiguriert werden.

Wir sehen völlig unsinnige Pakete von nichtexistenten MACs mit Ziel Router-Lan-Interface und Zielport 0 von wechselnden Quell-IPs mit 127(!).x.x.x. Bloß: Wenn der Spuk vorbei ist, ist er vorbei. Dann geht es wieder gut. Und dann haut es wieder 'rein und blockiert 20 Leute in einer kleinen Werbeagentur. Unschön.

Natürlich. Möglicherweise liegt hier aber auch ein Hardware-Defekt vor. An welchem Gerät, kann man durch intensives Troubleshooting rausfinden. Wenn dafür keine Zeit ist, kann man einen Switch auch mal auf Verdacht tauschen - ich meine LANCOMs hast Du ja auch schon durchgetauscht.

Viele Grüße,
Jirka