DS-Lite (Dual-Stack-Lite) und Backup

[Jirka]

Hallo,

ich hatte vor ein paar Tagen einen Kunden mit einem Problem mit einem DS-Lite-Anschluss (Dual-Stack-Lite-Anschluss) und dem klassischen Backup. Irgendwie kam ich da auch ins Schlingern.

Router war ein 1803VA-4G, aber das ist eher nebensächlich. Es handelte sich um einen (V)DSL-Anschluss von 1&1 mit DS-Lite und einem Mobilfunk-Backup mit O2 (Carrier-grade NAT, allerdings mit mit 100-er IP-Adresskreis, sondern mit 10-er). Alles war mit Assistenten eingerichtet, das Backup funktionierte aber nicht und der Router hatte im Backup-Fall eine CPU-Last von 90 %.

Beim DS-Lite ist es ja so: Man hat Dual-Stack, aber eben in verkrüppelter Lite-Form. Das bedeutet, es gibt eine ordentliche IPv6-Verbindung z. B. Namens INTERNET, in der IPv6-Routing-Tabelle steht also INTERNET als Default-Route. Für IPv4 wird unter Konfiguration -> IPv6 -> Tunnel -> DS-Lite-Tunnel ein Tunnel definiert Namens INTERNET-DSLITE. Dieser Tunnel INTERNET-DSLITE ist dann die Default-Route in der IPv4-Routing-Tabelle. Folglich gibt es im laufenden Betrieb die Gegenstelle INTERNET, die nur IPv6 kann, und für IPv4 den Tunnel INTERNET-DSLITE.

Das Ganze soll jetzt mit dem klassischen Backup über die Backup-Tabelle kombiniert werden. (Konfiguration -> Kommunikation -> Backup -> Backup-Tabelle) Dort befand sich der Eintrag Gegenstelle INTERNET und als Backup die Gegenstelle INET_WWAN.

Wenn nun aber der Backup-Fall eintritt, dann wird zwar die IPv6-Verbindung INTERNET mit der IPv4-Verbindung INET_WWAN ersetzt, aber am Ende funktioniert gar nichts. Denn das IPv4-Routing läuft immer noch über den DS-Lite-Tunnel (INTERNET-DSLITE), der über die IPv4-Mobilfunk-Verbindung (INET_WWAN) nicht aufgebaut werden kann, was vermutlich die 90 % CPU-Last erzeugt. Und das IPv6-Routing funktioniert auch nicht, da INET_WWAN ja kein IPv6 kann.

Wäre es jetzt richtig gewesen einen zweiten Eintrag in der Backup-Tabelle anzulegen, also INTERNET-DSLITE -> INET_WWAN? Wohl kaum, denn aus Erfahrung weiß man, dass immer nur Hauptverbindung oder Backupverbindung aufgebaut sein kann. Sind aber zwei Einträge in der Backup-Tabelle mit der gleichen Backup-Verbindung, könnte es knallen. Also eher nicht.
Aber wäre dann nur ein Eintrag richtig gewesen in der Form INTERNET-DSLITE -> INET_WWAN? Also der Eintrag INTERNET -> INET_WWAN dann raus? Hmm. Aber irgendwie denkt man, dass INTERNET ja die eigentliche Verbindung ist und wird an der Stelle unsicher, ob der LANCOM aus dem Ausfall von INTERNET auch immer gleich den Ausfall von INTERNET-DSLITE schließt.

Ich habe dann letztlich aus Unsicherheit den Weg über die administrative Distanz als Backup gewählt und alles funktioniert einwandfrei. Trotzdem stelle ich mir die Frage, wie es über die Backup-Tabelle richtig zu konfigurieren gewesen wäre. Und ob die Backup-Tabelle intern aus einem Eintrag zwei Einträge für IPv4 und IPv6 macht, die Backup-Tabelle also IPv4 und IPv6 unterscheidet. Letztlich könnte es ja sein, dass eine Internet-Verbindung eine Störung nur in IPv4 oder nur in IPv6 aufweist.
Und wie ist es dann eigentlich mit der IPv6-Default-Route? Die Mobilfunkverbindung kann ja kein IPv6. (Gibt es inzwischen eigentlich (handelsübliche) Mobilfunkverbindungen/-verträge, die standardmäßig IPv6 können?) Merken die Clients im lokalen LAN selber, dass IPv6 nicht geht und gehen dann über IPv4? Gibt es also in diesem Szenario für die IPv6-Default-Route gar kein Backup? Das würde ja wiederum dafür sprechen, dass die Variante mit nur einem Backup-Tabellen-Eintrag richtig gewesen sein könnte.

Hat die administrative Distanz ggf. auch Nachteile als Backup-Variante? (Traffic dürfte ja auf der Mobilfunkverbindung wegen der privaten IPv4-Adresse nicht anfallen.) Oder nur Vorteile? (z. B. schnelleres Backup/Leitungen sind Always-on)

Vielen Dank und viele Grüße
Jirka

[Dr.Einstein]

Und wie ist es dann eigentlich mit der IPv6-Default-Route? Die Mobilfunkverbindung kann ja kein IPv6. Merken die Clients im lokalen LAN selber, dass IPv6 nicht geht und gehen dann über IPv4? Gibt es also in diesem Szenario für die IPv6-Default-Route gar kein Backup? Das würde ja wiederum dafür sprechen, dass die Variante mit nur einem Backup-Tabellen-Eintrag richtig gewesen sein könnte.

Man kann Business Router an sich so einstellen, dass sie ein verlorenes Präfix aktiv mit einer Lifetime von 0 zurückziehen, d.h. die Clients wissen dann sofort bescheid und löschen ihre Einträge. Selbst wenn die Einträge aber nicht zurückgezogen werden, merken die Dual-Stack-Clients innerhalb von 1, max. 2 Sekunden, dass v6 down ist. Zumal die meisten Clients bei Dual-Stack schon DNS Anfragen parallel schicken, A und AAAA Record, damit der Wechsel noch schneller erfolgt.

(Gibt es inzwischen eigentlich (handelsübliche) Mobilfunkverbindungen/-verträge, die standardmäßig IPv6 können?)

Seit mehreren Jahren hat jeder T-Mobile D Kunde IPv6 Dualstack Lite (kein v4 Tunnel über v6!) auf allen Verträgen. Moderne Androids und iPhones nutzen diesen APN auch als Default. Vodafone und O2 haben scheinbar kein Interesse. Fall aber nicht wie ich darauf rein und erwarte, dass dann die v6-Adresse aus dem Internet erreichbar ist. Eine T-Mobile-Firewall verhindert dies. Ist ein ext. Zugriff gewünscht, gibt es eine Zubuchoption. Dann wird aber Dualstack Lite mit v4 Tunnel über v6 erzwungen.

Hat die administrative Distanz ggf. auch Nachteile als Backup-Variante? (Traffic dürfte ja auf der Mobilfunkverbindung wegen der privaten IPv4-Adresse nicht anfallen.) Oder nur Vorteile? (z. B. schnelleres Backup/Leitungen sind Always-on)

Admin. Distanzen trennen anders als das Lancom Backup-Konstrukt nicht aktiv die WAN-Verbindungen. Somit bleiben aktive Sessions so lange über die "Backup"-Verbindung aktiv, bis sie austimen oder bis die WAN-Verbindung aktiv getrennt wird. Vor- und Nachteil zugleich.

[Frühstücksdirektor]

Doch, das geht schon mit der Backup-Tabelle.
Das geht ab der aktuellen 10.80 + zusätzliche Handgriffe: https://knowledgebase.lancom-systems.de ... genstellen

Das DS-Lite ist halt ein "Tunnel" und nicht ganz vergleichbar mit den anderen Gegenstellen. Ist aber auch nicht so wichtig…

Der Wizard macht den Schritt aktuell (noch) nicht.

[backslash]

Hi Jirka,

wenn du wirklich nur IPv4 nutzt und das IPv6 im WAN nur als Transportnetz für da DS-Lite dient, dann richtest du das Backup nur für die DS-Lite Gegenstelle ein.

wenn du auch IPv6 nutzen willst, dann muss die IPv6 Backup-Verbindung auch DS-Lite unterstützen - oder du arbeitest mit administrativen Distanzen. DS-Lite und 464XLAT sind halt Krücken um Dual-Stack auf einem IPv6-only Anschluß zu ermöglichen.

Gruß Backslash

[Jirka]

Hallo zusammen,

erst mal vielen Dank für den umfangreichen und informativen Input. Ich bin noch am verstehen, gelesen habe ich alles.

Der Link von Dir, Frühstücksdirektor, klingt erst mal total interessant. Auf den zweiten Blick verstehe ich aber gar nichts mehr:
Zunächst mal geht es da um das Problem (oder habe ich es falsch verstanden?), dass die DS-Lite-Verbindung das Backup ist. Bei mir ist es aber die Hauptverbindung. Die Hauptverbindung ist bei mir (im IPv4) INTERNET-DSLITE und Backup ist Mobilfunk/WWAN. Also genau umgekehrt. Ist das nicht ein Unterschied und mein Fall hat mit diesem Knowledgebase-Artikel gar nichts zu tun?
Und selbst wenn ich mir den Knowledgebase-Artikel unter dem Gesichtspunkt anschaue, dass Haupt- und Backup-Verbindung dort andersrum sind, dann verstehe ich trotzdem noch nicht, wieso dann überhaupt noch ein Backup-Tabelleneintrag benötigt wird, mit der administrativen Distanz ist doch schon alles eingerichtet...

Also da fehlt mir irgendwie am Freitagnachmittag das Verständnis, ich glaube die Woche war zu anstrengend...

Vielen Dank und viele Grüße
Jirka

[Frühstücksdirektor]

Hallo Jirka,

Oh, Sorry, Du hast Recht. Da war ich wohl zu schnell (bei mir war auch Freitag Nachmittag...) . Der Artikel bezieht sich auf den Fall, wo das DS-Lite eine Backup-Verbindung ist.
Anders herum habe ich persönlich noch nicht konfiguriert. Das schaue ich mir aber mal an.

Viele Grüße,
Frühstücksdirektor

[Dr.Einstein]

Ich muss nochmal bei dem Thema nachfragen, da auch keine finale Antwort kam.

Folgendes Szenario mal durchgesponnen.

xDSL Telekom natives Dual Stack ipv4/ipv6, Name "DSL-WAN"
WWAN natives IPv6 mit 464XLAT, Name WWAN Gegenstelle "MOBILE-WAN", XLAT-Gegenstelle "MOBILE-XLAT"

Fall 1) Backuptabelle im Fall von xDSL auf WWAN
Fall 2) Backuptabelle im Fall von WWAN auf xDSL

Das Szenario ist doch nicht lösbar mit der Backuptabelle, wenn IPv4 und IPv6 parallel im Einsatz sind.

Fall 1 Routing Tabelle v4 wäre DSL-WAN, Routing Tabelle v6 ebenfalls DSL-WAN. Backuptabelle passt nicht mehr, da nur ein Peer angegeben werden kann, entweder MOBILE-WAN oder MOBILE-XLAT. MOBILE-XLAT würde für v4-Tabelle passen, MOBILE-WAN jedoch für v6-Tabelle.

Fall 2 Routing Tabelle v4 wäre MOBILE-XLAT, Routing Tabelle v6 MOBILE-WAN. Backuptabelle könnte passen, da zwei Einträge erstellt werden, von MOBILE-WAN bzw. MOBILE-XLAT auf DSL-WAN

Sehe ich das falsch oder wäre es sinnvoll, dass Lancom eine v4 und eine v6 backup-Tabelle implementiert? Den verlinkten Knowledgebase-Artikel verstehe ich in diesem Zusammenhang auch nicht.

[backslash]

Hi Dr.Einstein

Sehe ich das falsch oder wäre es sinnvoll, dass Lancom eine v4 und eine v6 backup-Tabelle implementiert?

nun ja, lohnt sich der Aufwand?

Das Szenario sollte doch mit administrativen Distanzen lösbar sein:

Backup für die IPv6-Verbindung und administrative Distanzen in der IPv4-Routing-Tabelle. Das sollte funktionierten, da XLAT und DSL-lite fest mit ihrer IPv6-Verbindung verknüpft sind, d.h.

• wenn die IPv6-Verbidnung down geht, geht auch das verknüpfte XLAT oder DSL-lite down.
• wenn die IPv6-Backup-Verbindung up geht, geht auch das verknüpfte XLAT oder DSL-lite up.

Es scheitert nur, wenn IPv6 zwar funktioniert, das damit verknüpfte XLAT oder DSL-lite aber nicht...
Das wäre dann wirklich nur über eine Lösung in der Aktionstabelle lösbar...

Gruß
Backslash

[Dr.Einstein]

Hey Backslash,

also wenn ich nichts falsch gemacht habe, funktioniert dein Ansatz nicht.

Die Backuptabelle sorgt dafür, dass über v4 die Primärgegenstelle xDSL durch eine nicht funktionierende WWAN-Verbindung "virtuell" / im Hintergrund ersetzt wird. Die administrative Distanz Gegenstelle mit XLAT wird nicht aktiv. Der Router bleibt auf "Protokollverhandlung" für die gesamte WWAN-Verbindung stecken, auch kein IPv6 oder IPv6 kommt hoch, XLAT nicht. Das Backup dreht sich also im Kreis wie es normalerweise üblich im LCOS ist, wenn die Backupgegenstelle in der Routing-Tabelle auftaucht, was hier allerdings nur über Ecken der Fall ist.

Werfe ich dagegen die Backup-Tabelle raus und ändere IPv4 auf XLAT, IPv6 auf WWAN, klappt alles sofort.

Administrative Distanzen für Backup wollte ich vermeiden da ich hier massive Eingriffe brauche, zumal viele meiner Kundenkarten Tagesflatrates haben, weshalb Always On negativ wäre. Zumal ich dann zusätzlich mittels Aktionstabellen dafür sorgen muss, dass aktive Verbindungen wie VPN bei einem Rückfall auf die Primärleitung getrennt und neu aufgebaut werden.

[backslash]

Hi Dr.Einstein,

dann wirst du wohl um eine komplett auf der Aktionstabelle beruhende Lösung nicht herumkommen...


- wenn die DSL-Gegenstelle abbaut, die IPv4-Defaultroute umschreiben auf die DS-Lite oder XLAT-Gegenstelle und die IPv6-Defaultroute auf die WWAN-Gegenstelle
- wenn die DSL-Gegenstelle wieder aufbaut, die Routen zurückschreiben.

Damit die DSL-Gegenstelle automatisch neu aufgebaut wird, brauchst du dann noch eine IPv4-Default-Route mit einem sonst ungenutzten Routing-Tag, die auf die DSL-Gegenstelle zeigt (diese Router darfst du natürlich nicht umschreiben)
ggf. kannst du noch mit Sperrzeiten in der Aktionstabelle dafür sorgen daß die Routen nicht sofort umgeschrieben werden, wenn die Leitung nur mal ein bischen "wackelt"

Gruß
Backslash

[Dr.Einstein]

Kurze Rückmeldung: In einem Minimalaufbau hat das Thema jetzt doch funktioniert. Also Backuptabelle + ein Eintrag für v4 XLAT mittels adm. Distanz. Muss also etwas mit komplexeren Szenarien zutun haben, wo viele Routing Tags, ARFs, VPNs usw zum Einsatz kommen. Vllt. beißt sich da noch etwas im LCOS. Ggf. später mehr, falls ich noch was rausfinde.