RIP v2 und Alterung von Routen

Anmeldungsdatum: 03.08.2005 Beiträge: 13 Wohnort: München

Hallo Zusammen,

folgendes Problem auf einem DSL/I-10 mit LCOS 3.56:

Das Gerät hängt an einem DSL-Anschluß, Zugang zum Provider A, daneben steht ein Linux-Router an einem weiteren DSL-Anschluß, Zugang zum Provider B.

Der Linux Router läuft nicht 24/7, das LANCOM schon, der Linux-Router verwedet Zebra/RIPD um wenn er Online ist die über ihn optimal erreichbaren Routen an das LANCOM (Default-Route im LAN) zu announcen. Das funktioniert auch einwandfrei.

Wird nun der Linux-Router ab und an außer Betrieb genommen, dan behält das LANCOM die über ihn erreichbaren Routen dennoch (nicht nur einen bestimmten Zeitraum lang). Erst wenn man per Webkonfiguration oder LANconfig die Default-Route im LANCOM neu auf Provider A setzt gehen diese IP-Präfixe wieder ordentlich raus.

Müssten per RIP empfangene Routen nicht nach einer gewissen Zeit aus der Routing-Tabelle verschwinden? Kann ich irgendwo einen Aging-Parameter setzen, der das forciert?

Danke,
Giovanni

Moderator Anmeldungsdatum: 08.11.2004 Beiträge: 4571 Wohnort: Aachen

Hi gio79de

Zitat:

Müssten per RIP empfangene Routen nicht nach einer gewissen Zeit aus der Routing-Tabelle verschwinden?

ja sie altern heraus. Nach 3.5 Minuten werden sie intern als nicht erreichbar markiert und verschwinden nach 5.5 Minuten ganz aus der Tabelle.

Zitat:

Kann ich irgendwo einen Aging-Parameter setzen, der das forciert?

nein, dieses Verhalten ist im RFC vorgeschrieben - d.h. wenn du den Linux-Router abschaltest, dann mußt du noch 3.5 Minuten warten, bevor das LANCOM eine andere Route nimmt.

Ggf. kannst du den Linux-Router ja dazu bringen, daß er als "letzte Worte" noch mitteilt, daß alle seine Routen nun "down" sind - dann geht der "Wechsel" schlagartig...

Gruß
Backslash

Anmeldungsdatum: 03.08.2005 Beiträge: 13 Wohnort: München

Hi backslash,

backslash hat folgendes geschrieben:

ja sie altern heraus. Nach 3.5 Minuten werden sie intern als nicht erreichbar markiert und verschwinden nach 5.5 Minuten ganz aus der Tabelle.

Das hätte ich eben auch erwartet, da ich das RfC kenne. Die Alterung (in Form der Inkrementierung der Time und Distance) findet auch statt und wenn die Time 10 und die Distance 16 erreicht bzw. überschritten haben verschwinden sie auch aus der per Telnet einsehbaren RIP-Tabelle, aber die Ziele werden dennoch nicht erreicht.

Konkretes Szenario sieht so aus, dass der Linux-Router alle über die DTAG gut erreichbaren Netze an das LANCOM announcet. Nehme ich alle diese Routen aus dem Announcement des RIP-Daemons heraus, dann stehe ich mit diesem Ergebnis da:

Code:

Routenverfolgung zu www.dtag.de [212.184.6.56] über maximal 30 Abschnitte:

1 2 ms 2 ms 2 ms gw-lambdanet [172.28.141.251]
2 gw-lambdanet [172.28.141.251] meldet: Zielnetz nicht erreichbar.

Ablaufverfolgung beendet.

Was hindert das LANCOM daran wieder seine Default-Route zu nutzen?

Moderator Anmeldungsdatum: 08.11.2004 Beiträge: 4571 Wohnort: Aachen

Hi gio79de,

Zitat:

Was hindert das LANCOM daran wieder seine Default-Route zu nutzen?

Ich habs gerade nochmal nachgeschaut: Das Problem ist, daß die 3.56 die interne Routingtabelle nur dann neu aufbaut, wenn ein RIP-Paket empfangen wurde, nicht jedoch wenn ein Eintrag herausaltert... Der Eintrag bleibt einfach mit "unreachable" vorhanden und das führt zur Ablehnung.

Desweiteren kann die 3.56 nicht damit umgehen, wenn ein Subnetz verschwindet und mit einem größeren Netz aus der statischen Routingtabelle zusammengemerged wird. D.h. damit das ganze überhaupt funktioniert, mußt du zusätzlich die Routen, die der Linux-Router kennt, auch im LANCOM explizit eintragen und auf die Default-Route setzen (natürlich mit einer höheren Metrik als die die der Linux-Router propagiert)
Beachte dabei, daß du bei den Routen auch die Maskierung einschaltest...

Versuche als Workarround den Linux-Router dazu zu bringen, daß er die Routen wirklich nochmal als "unreachable" propagiert - das sollte zu einem sofortigen Umschalten der Routen führen (wenn die Routen auch explizit im LANCOM eingetragen sind)...

Gruß
Backslash

Anmeldungsdatum: 03.08.2005 Beiträge: 13 Wohnort: München

Hi backslash,

ich dachte zwar ich hätte bereits gefragt aber offenbar war das nur einbildung, daher muss ich den alten Thread jetzt nochmal aufwärmen:

backslash hat folgendes geschrieben:

Ich habs gerade nochmal nachgeschaut: Das Problem ist, daß die 3.56 die interne Routingtabelle nur dann neu aufbaut, wenn ein RIP-Paket empfangen wurde, nicht jedoch wenn ein Eintrag herausaltert... Der Eintrag bleibt einfach mit "unreachable" vorhanden und das führt zur Ablehnung.

Besteht eine Chance, dass dies in einer zukünftigen Firmware korrigiert wird oder ist es in der 3.54er evtl. noch korrekt?
Ein Withdraw, also ein zurückziehen der Route gibt es nämlich bei RIP schlichtweg nicht, folglich kann ich den anderen Router nicht dazu bringen sowas zu schicken.

Bye,
Gio

Moderator Anmeldungsdatum: 08.11.2004 Beiträge: 4571 Wohnort: Aachen

Hi gio79de,

Zitat:

Besteht eine Chance, dass dies in einer zukünftigen Firmware korrigiert wird oder ist es in der 3.54er evtl. noch korrekt?

Das wird bei künftigen Firmwaren (> 5.0x) gefixt sein, diese wird es aber für ein DSL/I-10 nicht mehr geben.

Zitat:

Ein Withdraw, also ein zurückziehen der Route gibt es nämlich bei RIP schlichtweg nicht, folglich kann ich den anderen Router nicht dazu bringen sowas zu schicken.

Doch den gibt es sehr wohl. Der Router muß seine Route nur mit einer Distanz von 16 Propagieren - das ist ja auch genau das, was ich als Workarround vorgeschlagen haben.

Die Distanz stellt man übrigends im route-Kommando über die "Metrik" ein. Wenn du nun also beim Heruinterfahren des Linux-Rechners bei allen routen eine Metrik von 16 einträgst und danach das Versenden der Routen über RIP erzwingst (sollte sinnvollerweise beim Ändern der Metrik automatisch passieren, aber ich kenne deinen RIP-Daemon nicht), dann wird es funktionieren.

Ach ja, wenn du den Linux-Router nicht dazu bewegen kannst, eine Distanz von 16 zu propagieren, dann tut es auch 15 - das hat die selbe Wirkung, da das LANCOM beim Empfang der Route die Distanz um 1 erhöht und somit auch den Wert "unreachable" erreicht.

Gruß
Backslash

Anmeldungsdatum: 03.08.2005 Beiträge: 13 Wohnort: München

Hi backslash,

backslash hat folgendes geschrieben:

Das wird bei künftigen Firmwaren (> 5.0x) gefixt sein, diese wird es aber für ein DSL/I-10 nicht mehr geben.

Andersherum: Fürs DSL/I-10 wird es keine Firmwareupdates mehr geben?

backslash hat folgendes geschrieben:

Ach ja, wenn du den Linux-Router nicht dazu bewegen kannst, eine Distanz von 16 zu propagieren, dann tut es auch 15 - das hat die selbe Wirkung, da das LANCOM beim Empfang der Route die Distanz um 1 erhöht und somit auch den Wert "unreachable" erreicht.

"unreachable" wird es ja jetzt bereits, aber die Routing-Tabelle des LANCOMs wird dadurch ja auch nicht neu aufgebaut, selbst wenn manche Ziele "unreachable" werden, und das ist ja der eigentliche Bug. Daran ändert sich auch nichts, wenn ich die Routen mit Metrik 16 propagieren lassen.

Bye,
Gio

Moderator Anmeldungsdatum: 08.11.2004 Beiträge: 4571 Wohnort: Aachen

Hi gio79de

Zitat:

Andersherum: Fürs DSL/I-10 wird es keine Firmwareupdates mehr geben?

genau das (der Firmwareunterstützung ist damals mit Erscheinen der 3.56 abgekündigt worden)

Zitat:

"unreachable" wird es ja jetzt bereits, aber die Routing-Tabelle des LANCOMs wird dadurch ja auch nicht neu aufgebaut, selbst wenn manche Ziele "unreachable" werden, und das ist ja der eigentliche Bug. Daran ändert sich auch nichts, wenn ich die Routen mit Metrik 16 propagieren lassen.

Nein! Die Routing-Tabelle wird neu aufgebaut. Das Problem liegt in dem, was ich in meinem zweiten Posting vom 9. August schrieb:

Zitat:

Desweiteren kann die 3.56 nicht damit umgehen, wenn ein Subnetz verschwindet und mit einem größeren Netz aus der statischen Routingtabelle zusammengemerged wird. D.h. damit das ganze überhaupt funktioniert, mußt du zusätzlich die Routen, die der Linux-Router kennt, auch im LANCOM explizit eintragen und auf die Default-Route setzen (natürlich mit einer höheren Metrik als die die der Linux-Router propagiert)
Beachte dabei, daß du bei den Routen auch die Maskierung einschaltest...

In deinem Fall hat das LANCOM nur die Default-Route und der Linux-Server propagiert ein paar weitere Routen. Das LANCOM nimmt diese zwar an, kann aber nicht damit umgehen wenn sie wieder verschwinden. Damit das funktioniert, mußt du im LANCOM die gleichen Routen eintragen (natürlich verweisen sie LANCOM dann auf die gleiche Gegenstelle, wie die Default-Route)!

Gruß
Backlsash

Anmeldungsdatum: 03.08.2005 Beiträge: 13 Wohnort: München

Hallo backslash,

backslash hat folgendes geschrieben:

In deinem Fall hat das LANCOM nur die Default-Route und der Linux-Server propagiert ein paar weitere Routen. Das LANCOM nimmt diese zwar an, kann aber nicht damit umgehen wenn sie wieder verschwinden. Damit das funktioniert, mußt du im LANCOM die gleichen Routen eintragen (natürlich verweisen sie LANCOM dann auf die gleiche Gegenstelle, wie die Default-Route)!

Eben versucht:
Ein /16 das der Linux-Rechner (Debian mit Quagga/RIPD) propagiert im LANCOM auf das selbe Ziel wie die LANCOMsche Default-Route eingetragen.

Ergebnis:
Ab diesem Zeitpunkt wird das wiederum nur über die Verbindung des LANCOMs geroutet, der Linux propagiert zwar schön aber die Route wird dennoch ignoriert.

Ich gehe davon aus, dass Du nicht meintest, diese Route(n) nur dann einzutragen, wenn der Linux-Rechner nicht läuft, denn das würde das automatische Routing das mit RIP erwünscht ist ja ad absurdum führen.

Moderator Anmeldungsdatum: 08.11.2004 Beiträge: 4571 Wohnort: Aachen

Hi gio79de

Zitat:

Ergebnis:
Ab diesem Zeitpunkt wird das wiederum nur über die Verbindung des LANCOMs geroutet, der Linux propagiert zwar schön aber die Route wird dennoch ignoriert.

Ich gehe davon aus, dass Du nicht meintest, diese Route(n) nur dann einzutragen, wenn der Linux-Rechner nicht läuft, denn das würde das automatische Routing das mit RIP erwünscht ist ja ad absurdum führen.

Oh Sch....
da rennst du in das Poblem, daß das LANCOM "Herr der Leitung" ist und in dem Moment, in dem es selbst die Verbindung hat, die Routen auf der Verbindung intern mit einer Metrik 1 verwaltet. Und da kann das Linux nun erzählen was es will - es kommt nicht mehr zum Zug...

Ich shätze mal, du hast es geschafft, daß noch eine 3.58 Beta extra für dich gebaut wird....

Gruß
Backslash

Moderator Anmeldungsdatum: 08.11.2004 Beiträge: 4571 Wohnort: Aachen

Hi gio79de,

ich habe dir eine Firmware als PN geschickt. Bedenke aber, daß sie nur Beta Status hat und nur das Problem mit der Metrik löst...

Gruß
Backslash

Anmeldungsdatum: 03.08.2005 Beiträge: 13 Wohnort: München

Hi backslash,

backslash hat folgendes geschrieben:

Ich shätze mal, du hast es geschafft, daß noch eine 3.58 Beta extra für dich gebaut wird....

Grandios, danke, und ich hab schon an meiner Intelligenz gezweifelt!

Montag werde ich dem LANCOM die *seufz* 40 Routen reinfummeln und dann berichten.

Bye,
Gio