7100+ schachmatt

[Koppelfeld]

Hallo !

Heute morgen gegen 05:00 bekam mein 7100+ einen Watchdog-Trigger, hänge ich hinten an.
System fuhr sofort wieder hoch, ABER:
DSL-CH 1 ist "Kabel Deutschland", IP-over-Ethernet mit DHCP. Der endete mit "Protocol".
Eigentlich nicht schlimm, das liegt sicher an dem lausigen KD-Modem, aber eines war schlimmer:
Das zweite DSL-Interface (T-DSL, PPPoE) wollte auch nicht: Im Status sah man zwar "Connection", aber weder wurde die DynDNS-Adresse aktualisiert noch konnte man über dieses Interface 'raus.

Und jetzt das wirklich Merkwürdige: Nach Reset des Kabelmodems verband nicht nur der 1. DSL-Kanal, sondern plötzlich war auch das zweite Interface wieder erreichbar. Auch der DynDNS - Update wurde wieder durchgeführt - alles ohne Restart.

Heißt das, daß die WAN-Verbindungen squentiell aufgebaut werden ? Incl. Stop, wenn eine nicht erreichbar ? Wäre jetzt nicht ganz das Verhalten, welches ich mir wünsche ...



Ach ja, der WDT-Eintrag:

04/15/2015 05:45:22 LCOS-Watchdog
Task name = WC Type=IOS watchdog - job timeout in Volume-Budgets (code is stack ptr)
Code=0x05ace470 Thread=05b3fac8 Task=05b3fac0/05b3fac0 Nest=0x00000000

R00=0x00f81df8 SP =0x05b40bf8 R02=0x01856000 R03=0x01ac8008
R04=0x05ace470 R05=0x016d4eb0 R06=0x000000e5 R07=0x016030f8
R08=0x00000000 R09=0x05acd7a0 R10=0x01ac7fee R11=0x00000025
R12=0x24004044 R13=0x01a6bf48 R14=0x00000000 R15=0x00000000
R16=0x00000000 R17=0x00000000 R18=0x00000000 R19=0x00000000
R20=0x00000000 R21=0x00000000 R22=0x00000000 R23=0x00000000
R24=0x00000000 R25=0x09ecfbe0 R26=0x01a65288 R27=0x016d4b70
R28=0x016d4ee8 R29=0x01ac7fe0 R30=0x05acd900 R31=0x01ac8008

CR =0x22000042 XER =0x20000000 LR =0x00f81e14 CTR =0x012c074c
ESR =0x00000000 DEAR=0x01656c30 HID0=0x80804000 HID1=0x45003080
MCSR=0x00000000 PID0=0x00000002 PID1=0x00000000 PID2=0x00000000
MAS0=0x00000001 MAS1=0x80000100 MAS2=0x01656000 MAS3=0x01656003
MAS4=0x00030100 MAS6=0x00020000 MAS7=0x00000000 MCTR=0x00000000
SPR0=0x00000000 SPR1=0x01aae64c SPR2=0x0000edc8 SPR3=0x00400000
SPR4=0x00000000 SPR5=0x01856000 SPR6=0x05b40ba8 SPR7=0x00000000

MCAR =0x0:00000000
SRR0(PC) =0x0128c348
SRR1(MSR)=0x00029200
possible Error location lcos/ios/common.src/IosJobWatchDog.cpp : 229

[MariusP]

Hi,
Bei WDs immer den Bereich zwischen den ***** posten.
Gruß

[Koppelfeld]

Hi,
Bei WDs immer den Bereich zwischen den ***** posten.

Danke. Mir kam es allerdings gar nicht auf den "WD" an:
Denn nach einem Reset am Gerät und anschließendem Neustart blieb die Situation: Das schrottige Kabelmodem blieb "weggehängt", die Telekom-Verbindung war zwar "CONNECTED", aber weder wurde das mit dem Verbindungsaufbau assoziierte "Action-Script" ausgeführt noch konnte die Verbindung genutzt werden.
Nach Kabelmodem-Reset baute sich die Verbindung zu KD wieder auf und direkt danach stieß der Router auch das Script für den Telekom -Zugang an, der fortan auch benutzbar war.

Sieht mir nach einem Softwarefehler im Router aus (FW 9.04.0184).

[MariusP]

Hi,
Das wusste ich, allerdings habe ich nicht soo viel Ahnung vom VDSL.
Daher wollte ich dir jedenfalls bei dem anderen Thema helfen und die User dieses Forums "schulen", da die WDs ohne Angabe der Firmware und ohne Callstack fast nicht auslesbar sind.
Gruß

[Jirka]

Hallo Koppelfeld,

also da muss ich Marius mal unterstützen... Also wenn Watchdog, dann bitte vollständig, ansonsten kann man da so gut wie gar nichts ablesen. Im ersten Posting hattest Du ja noch nicht mal die Firmware-Version angegeben, mit der das auftritt. Und dann wären zwei Sätze zur Konfiguration auch nicht verkehrt gewesen. Werden die beiden Gegenstellen mit policy-based-Routing verwendet, oder aber mit Loadbalancer oder als Backup? Solche Angaben hätte ich eigentlich von Dir erwartet...
Ein Problem mit der 9.04 und der Erkennung von nicht funktionierenden Leitungen liegt LANCOM meines Wissens vor, ob das Deine Probleme nun auch betrifft, weiß ich aber nicht.

Viele Grüße,
Jirka

[Koppelfeld]

Hallo Koppelfeld,

also da muss ich Marius mal unterstützen... Also wenn Watchdog, dann bitte vollständig, ansonsten kann man da so gut wie gar nichts ablesen. Im ersten Posting hattest Du ja noch nicht mal die Firmware-Version angegeben, mit der das auftritt. Und dann wären zwei Sätze zur Konfiguration auch nicht verkehrt gewesen. Werden die beiden Gegenstellen mit policy-based-Routing verwendet, oder aber mit Loadbalancer oder als Backup? Solche Angaben hätte ich eigentlich von Dir erwartet...

Ja, hackt nur alle auf mir 'rum.
Ich habe es doch verstanden.
Die LANCOM - Geräte wende ich nach dem Grundsatz von Ockham (das ist derjenige, dem Umberto Eco im 'Namen der Rose' mit William von Baskerville ein Denkmal gesetzt hat):
Entia non sunt multiplicanda sine necessitas, später sogar noch verschärft mit ~ preater necessitate, auf gut deutsch:
Man soll nix unnötig kompliziert machen, sonst taugt es nicht.

Einen Router benutze ich als Router, einen Switch als Switch, einen WLAN - Adapter als WLAN - Adapter.

Und bevor ich einen Fehler melde, vereinfache ich das Szenarium so lange, wie der Fehler gerade noch auftritt.
Und natürlich sorge ich, bei einem im Produktiveinsatz befindlichen Core-Router, für das aktuelle, offiziell freigegebene Release.

Ein Problem mit der 9.04 und der Erkennung von nicht funktionierenden Leitungen liegt LANCOM meines Wissens vor, ob das Deine Probleme nun auch betrifft, weiß ich aber nicht.

Ich kann's reproduzieren:
Wenn, beim Systemstart wohlgemerkt, die erste WAN-Verbindung (IP/DHCP über Ethernet) nicht zustandekommt, dann wird die zweite zwar aufgebaut (und auch als etabliert angezeigt), aber sie kann nicht genutzt werden.
Mir fällt gerade auf, daß ich ein Idiot bin: KLAR mußte das DDNS-Script fehlschlagen - hat kein Routing-Tag und wollte dann über den nicht funktionierenden KD-Anschluß 'raus. Ich werde alt.
ABER: Ich habe die Default-Route auf das zweite, verbundene Interface gelenkt - kein Erfolg, nix ging 'rüber. Sehr merkwürdig.