Alternative Route bei Ausfall der DSL-Leitung braucht gefühlt ewig

Hallo,

ich habe hier einen Knoten, der über zwei Sprünge zu einem anderen Knoten mit Uplink mesht.

Wenn ich jetzt das LAN-Kabel ziehe, merkt er relativ schnell, dass die Verbindung weg ist, und routet den Traffic über meinen Nachbarn.

Wenn aber die DSL-Leitung unterbrochen ist, die Verbindung zum lokalen LAN noch da ist, dauert das mehrere Minuten.

Ich dachte, dass Batman-adv alle 5 Sekunden die Routen optimiert? Warum dauert das so lange? Ist das ein Bug, könnte man das nicht beschleunigen?

Grüße
MPW

batman-adv sendet alle 5s OGM Pakete. Bis sich die Route dann tatsächlich ändert, können tatsächlich einige Minuten vergehen. Leider kann man die OGM Interval auch nicht viel kleiner wählen, weil dann die Grundlast ungefähr im gleichen Maße steigt.

Eine Routen Information muss erst um eine bestimmte Zeit „veraltet“ sein damit eine Link „Qualität“ soweit gesunken ist damit ein Routing Deamon eine Route wechselt. Genaueres findest du bestimmt im Netz wenn du nach batman_adv suchst.

Wir überlegen im ffrg schon, das OGM-Interval zu verdoppeln, da wir schon teilweise über(!) 2GB pro Tag(!) an Hintergrund-Traffik (>90 OGM?) liegen.
Würde dann in Konsequenz noch länger dauern.

Wäre es keine Möglichkeit, das OGM-Intervall irgendwie dynamisch zu steuern? Also abhängig von der Historie eines Nodes, also „wie wackelig“ seine Netzverbindungen sind? Also bei jemden, der „an stabilem DSL mit maximal einer Zwangstrennung am Tag und keinem Wifimesh-Nachbarn seit Tagen“ das OGM einfach auf faktisch Null zu reduzieren, weil es sowieso keinen Erkenntnisgewinn geben wird mit an Sicherheit grenzender Wahrscheinlichkeit?

Wie könnte man die „Erkenntnisspanne“ verkürzen. Dass eine DSL-Verbindung weg ist, kann man doch innerhalb von 5 Sekunden feststellen.

Könnte man den Zeitverlust zwischen OGM und der Routenänderung verändern?

Hier geht es ja nicht darum, eine wakelige WLAN-Verbindung gegen eine andere zu setzen, sondern die Verbindung ist dann erstmal weg, wenn jemand ein Kabel getrennt hat oder es eine Anbieterstörung gibt.

/edit: Könnte man nicht den Algorithmus so definieren, dass wenn der Link um mehr als 90% einbricht, er direkt als tot gilt und möglichst ein anderer verwendet werden soll, außer es gibt keinen anderen? Oder ist das zu simpel gedacht?

Problem dürfte bekannt sein, wenn meine Vermutung, was da passiert, richtig ist. In Graphen mit Zyklen (wie wir sie immer zwischen zwei Uplinks haben) nennt sich das Problem in Informatikerkreisen „Count to Infinity“.

Was passiert ist halt, dass die Knoten in die OGMs nicht reinschreiben, über welche Knoten die entsprechenden Routen gehen. Das würde die OGMs halt nochmal quadratisch vergrößern. Selber wird auch immer nur der nächste Hop gespeichert.
Das führt dazu, dass eine Information wie „Knoten A hat gerade seine direkte Verbindung zum Supernode verloren“ gar nicht ausgewertet werden kann, um die Routingtabelle zu aktualisieren.

Was dann passiert ist, dass der Knoten A einfach seine beste Verbindung zum Supernode broadcastet, die über Knoten B geht (mit einer gewissen höheren Latenz), die Tatsache, dass die Verbindung aber über B geht, steht da nicht drin. Knoten B sieht nun einfach, dass die Verbindung von A zum Supernode sich um eine gewisse Latenz verschlechtert hat, und korrigiert seine Routingtabelle. Er würde nun beim nächsten OGM ebenfalls einen schlechteren Wert für Latenz zum Supernode ankündigen. Router A sieht nun wieder, dass sich seine Verbindung zum Supernode über B verschlechtert hat und korrigiert seinen Wert, usw.

Das ganze geht dann so lange, bis sich die Latenz von A bzw. B zum Supernode so weit hochgeschaukelt hat, bis die Verbindung über einen Knoten C im Vergleich besser da steht. Je nachdem wie groß der Kreis ist, und wie klein die Latenz zwischen A und B im Vergleich dazu ist, dauert das immer länger, bis umgeschwenkt wird. (Schlimmster Fall wäre also sowas wie z.B. 5 Hops bis zum nächsten Uplink, und die ersten zwei Knoten sind über Kabel verbunden)
Wenn man ein Protokoll hätte, in dem es keine Timeouts wie bei BATMAN gibt, und in denen Unerreichbarkeit durch einen Latenzwert von Unendlich angegeben wird, würde man dann ewig hochzählen ohne dass man jeweils erkennt, dass das Ziel unerreichbar geworden ist. Daher heißt das „Count to Infinity“.

Man kann viele der Ideen umsetzen. Wenn ihr Lust dazu habt, könntet ihr euch ein batman-adv ein bisschen einarbeiten.

Gerade dieses Problem ist meiner Meinung nach auch bei babel schöner gelöst. Dort tauschen sich Nachbarknoten permanent darüber aus, ob sie sich noch sehen.

1 Like