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
RIP v2 und Alterung von Routen
Moderator: Lancom-Systems Moderatoren
Hi gio79de
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
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.Müssten per RIP empfangene Routen nicht nach einer gewissen Zeit aus der Routing-Tabelle verschwinden?
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.Kann ich irgendwo einen Aging-Parameter setzen, der das forciert?
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
Hi backslash,
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:
Was hindert das LANCOM daran wieder seine Default-Route zu nutzen?
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.backslash hat 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.
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: Alles auswählen
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.Hi gio79de,
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
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.Was hindert das LANCOM daran wieder seine Default-Route zu nutzen?
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
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:
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
ich dachte zwar ich hätte bereits gefragt aber offenbar war das nur einbildung, daher muss ich den alten Thread jetzt nochmal aufwärmen:
Besteht eine Chance, dass dies in einer zukünftigen Firmware korrigiert wird oder ist es in der 3.54er evtl. noch korrekt?backslash hat 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.
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
Hi gio79de,
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
Das wird bei künftigen Firmwaren (> 5.0x) gefixt sein, diese wird es aber für ein DSL/I-10 nicht mehr geben.Besteht eine Chance, dass dies in einer zukünftigen Firmware korrigiert wird oder ist es in der 3.54er evtl. noch korrekt?
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.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.
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
Hi backslash,
Bye,
Gio
Andersherum: Fürs DSL/I-10 wird es keine Firmwareupdates mehr geben?backslash hat geschrieben:Das wird bei künftigen Firmwaren (> 5.0x) gefixt sein, diese wird es aber für ein DSL/I-10 nicht mehr geben.
"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.backslash hat 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.
Bye,
Gio
Hi gio79de
Gruß
Backlsash
genau das (der Firmwareunterstützung ist damals mit Erscheinen der 3.56 abgekündigt worden)Andersherum: Fürs DSL/I-10 wird es keine Firmwareupdates mehr geben?
Nein! Die Routing-Tabelle wird neu aufgebaut. Das Problem liegt in dem, was ich in meinem zweiten Posting vom 9. August schrieb:"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.
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)!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...
Gruß
Backlsash
Hallo backslash,
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.
Eben versucht:backslash hat 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)!
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.
Hi gio79de
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
Oh Sch....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.
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