MultiWAN und IPv6-Probleme
Moin Kollegen,
Mal eine kleine Diskussionrunde zum Freitag:
Mehrere Internet-Anschlüsse zu haben war ja schon immer von Vorteil, insbesondere wegen Lastverteilung und Redundanz. "Normalerweise" funktioniert das auch sowohl mit IPv4 und auch mit IPv6 ohne Probleme, indem man sich providerunabhängige IP-Netze geben läßt, ein eigenes AS aufspannt und mit passenden Protokollen ins Internet herausposaunt, wie und wo man zu erreichen ist.
Leider hat nicht jeder Zeit und Lust und vor allem Geld, das in diesem Maßstab zu machen. Bei IPv4 hat sich das Problem in den 90er Jahren in Luft aufgelöst, als man anfing in LANs RFC-1918-Adressen zu verwenden und an den Netzwerkgrenzen per NAT auf öffentliche Adressen maskiert hat. Bei ipv4 war es da unproblematisch, die ausgehenden verbindungen über eine beliebige Leitung für die Dauer der Verbindung zu routen, weil die Rückpakete automatisch auf die richtige Leitung zurückgeroutet wurden. Damit ist MultiWAN mit IPv4 unproblematisch, im Gegensatz zu den 90ern, wenn man ohne NAT arbeitete.
Nachdem ipv6 immer weiter auf dem Vormarsch ist und heutzutage eigentlich unverzichtbar, taucht das alte Problem mit MultiWAN wieder auf. Bei v6 wollte man mit der NATtterei ekigentlich schuß machen. Es stellt sich aber immer mehr heraus, daß es nicht immer ohne geht.
Viele (Geschäfts-) Kunden haben heutzutage mehrere Internetanschlüsse, sei es wegen Redundanz oder zur Bandbreitenerhöhung (oder gar aus historischen Gründen, weil aus zwei Telefonanschlüssen irgendwann zwei DSL-Anschlüsse wurden). das läßt sich ja heutzutage auch recht einfach "abfackeln", indem man da einen MultiWAN-Router hinstellt, der dann für Lastverteilung und Failover sorgt. Funktioniert mit ipv4 super. Mit ipv6, solange es kaum verbreitet war, filen die Probleme kaum auf. Doch inzwischen mahct sich verstärkt bemerkbar, daß manche von den Problemen sich bemerkbar machen.
Was ist nun das Problem? Bei KMUs mach sich selten jemand die Mühe, sich ein eigens AS und eigenen IPV6-Adressraum zu besorgen, zumindest in meinem Kundenkreis. Das bedeutet aber, daß man für IPv6-Adresseierung zur kommunikation mit der Außenwelt entweder NAT an den Internet-Gateways machen muß, was ja verpönt und eigeltich unerwünscht ist, odr mit den Präfixen arbeiten muß, die man von den jeweiligen Providern zugeteilt bekommt. Ist erstmal kein Problem, da es ja im Standard vorgesehen ist, daß die Hosts auch mehrere IPv6-Adressen haben.
Jetzt hat aber der MultiWAN-Router das Problem, wenn er Loadbalancing machen soll. Er kann die Verbindungen nicht willkürlich auf die weniger ausgelastete leitungen legen, weil der interne Host entscheidet, mit welcher Absenderadresse er die Verbindung aufbaut. Hingegen sieht der Host natürlich i.d.R. nicht, welche Leitung gerade am Limit ist und wo noch Kapazitäten frei sind. Das ist, solange die Leitungen nicht ausgereizt werden oder stark unterschiedliche Kapazitäten haben unproblematisch. Problematisch wird es erst, wenn viele Hosts die "falsche" v6-Adresse wählen und alle über dieselbe Leitung wollen oder den Präfix einer "langsamen" Leitung wählen.
Besonders extrem ist mir das bei einem Kunden aufgefallen, der vorher eine ADSL-leitung (16Mbps) und eine VDSL-leitung (50Mbps) hatte und jetzt eine Glasfaser-Leitung (300mbps) dazubekommen hat. Viele Verbindungen schienen immer noch bei 50 oder gar 16 Mbps "festzustecken". Die genauere Recherche ergab, daß das vor allem bei v6-Verbindungen auftrat. Dazu kommt, daß der Glasfaseranbieter anscheinend nur ein prefix (/64) zuteilt. und sich das die Fritte vor dem MultiWAN-Router (be.ip plus) greift und daher für die be.ip kein v6-netz abfällt. Selbst wenn ich die be.ip direkt an das Glasfaser hänge ist das imemr noch ein Problem, weil die nachfolgenden Netze dann natürlich auch kein öffentliches v6-prefix abbekommen.
Nun hadere ich mit mir, auf welche Weise ich den gordischen Knoten durchschlagen soll:
Nachdem ihr Euch durch diese Textwüste gelesen habt, kommen wir endlich zu dem Thema, zu dem ich eine freitagsdiskussion eröffnen will:
Wie geht ihr mit der o.g. Problematik um Lösung des ipv6-Dilemmas mit providerprefixes am Multiwan-Anschluß . Was sind eure Erfahrungen, auf welche Probleme seid Ihr gestoßen und ist euch das bisher überhaupt aufgefallen?
Ich selber wanke noch zwischen den Optionen ipv6 nur auf einer Leitung zuzulassen oder NPT unter austausch des Routers einzusetzen. Was meint Ihr dazuß Oder habt ihr gar ganz andere Lösungsansätze (außer sich providerunabhängige v6-dressen zu holen und ein eigenes AS aufsetzen natürlich ).
Ich hoffe auf eine rege Beteilung und neue Erkenntnisse.
grüße,
lks
PS: Tapp- und Stilfuhler versuche ich wie üblich im Laufe der Diskussion zu beseitigen. Bis dahin sollen sie zu eurer Erheiterung dienen.
Mal eine kleine Diskussionrunde zum Freitag:
Mehrere Internet-Anschlüsse zu haben war ja schon immer von Vorteil, insbesondere wegen Lastverteilung und Redundanz. "Normalerweise" funktioniert das auch sowohl mit IPv4 und auch mit IPv6 ohne Probleme, indem man sich providerunabhängige IP-Netze geben läßt, ein eigenes AS aufspannt und mit passenden Protokollen ins Internet herausposaunt, wie und wo man zu erreichen ist.
Leider hat nicht jeder Zeit und Lust und vor allem Geld, das in diesem Maßstab zu machen. Bei IPv4 hat sich das Problem in den 90er Jahren in Luft aufgelöst, als man anfing in LANs RFC-1918-Adressen zu verwenden und an den Netzwerkgrenzen per NAT auf öffentliche Adressen maskiert hat. Bei ipv4 war es da unproblematisch, die ausgehenden verbindungen über eine beliebige Leitung für die Dauer der Verbindung zu routen, weil die Rückpakete automatisch auf die richtige Leitung zurückgeroutet wurden. Damit ist MultiWAN mit IPv4 unproblematisch, im Gegensatz zu den 90ern, wenn man ohne NAT arbeitete.
Nachdem ipv6 immer weiter auf dem Vormarsch ist und heutzutage eigentlich unverzichtbar, taucht das alte Problem mit MultiWAN wieder auf. Bei v6 wollte man mit der NATtterei ekigentlich schuß machen. Es stellt sich aber immer mehr heraus, daß es nicht immer ohne geht.
Viele (Geschäfts-) Kunden haben heutzutage mehrere Internetanschlüsse, sei es wegen Redundanz oder zur Bandbreitenerhöhung (oder gar aus historischen Gründen, weil aus zwei Telefonanschlüssen irgendwann zwei DSL-Anschlüsse wurden). das läßt sich ja heutzutage auch recht einfach "abfackeln", indem man da einen MultiWAN-Router hinstellt, der dann für Lastverteilung und Failover sorgt. Funktioniert mit ipv4 super. Mit ipv6, solange es kaum verbreitet war, filen die Probleme kaum auf. Doch inzwischen mahct sich verstärkt bemerkbar, daß manche von den Problemen sich bemerkbar machen.
Was ist nun das Problem? Bei KMUs mach sich selten jemand die Mühe, sich ein eigens AS und eigenen IPV6-Adressraum zu besorgen, zumindest in meinem Kundenkreis. Das bedeutet aber, daß man für IPv6-Adresseierung zur kommunikation mit der Außenwelt entweder NAT an den Internet-Gateways machen muß, was ja verpönt und eigeltich unerwünscht ist, odr mit den Präfixen arbeiten muß, die man von den jeweiligen Providern zugeteilt bekommt. Ist erstmal kein Problem, da es ja im Standard vorgesehen ist, daß die Hosts auch mehrere IPv6-Adressen haben.
Jetzt hat aber der MultiWAN-Router das Problem, wenn er Loadbalancing machen soll. Er kann die Verbindungen nicht willkürlich auf die weniger ausgelastete leitungen legen, weil der interne Host entscheidet, mit welcher Absenderadresse er die Verbindung aufbaut. Hingegen sieht der Host natürlich i.d.R. nicht, welche Leitung gerade am Limit ist und wo noch Kapazitäten frei sind. Das ist, solange die Leitungen nicht ausgereizt werden oder stark unterschiedliche Kapazitäten haben unproblematisch. Problematisch wird es erst, wenn viele Hosts die "falsche" v6-Adresse wählen und alle über dieselbe Leitung wollen oder den Präfix einer "langsamen" Leitung wählen.
Besonders extrem ist mir das bei einem Kunden aufgefallen, der vorher eine ADSL-leitung (16Mbps) und eine VDSL-leitung (50Mbps) hatte und jetzt eine Glasfaser-Leitung (300mbps) dazubekommen hat. Viele Verbindungen schienen immer noch bei 50 oder gar 16 Mbps "festzustecken". Die genauere Recherche ergab, daß das vor allem bei v6-Verbindungen auftrat. Dazu kommt, daß der Glasfaseranbieter anscheinend nur ein prefix (/64) zuteilt. und sich das die Fritte vor dem MultiWAN-Router (be.ip plus) greift und daher für die be.ip kein v6-netz abfällt. Selbst wenn ich die be.ip direkt an das Glasfaser hänge ist das imemr noch ein Problem, weil die nachfolgenden Netze dann natürlich auch kein öffentliches v6-prefix abbekommen.
Nun hadere ich mit mir, auf welche Weise ich den gordischen Knoten durchschlagen soll:
- ipv6 abschalten ist natürlich keine Option heutzutage.
- nur das Prefix des schnellsten Anbieters durchlassen? Das ist im Falle eines Failovers natürlich problematisch, da dann im Fehlerfall auch die v6-Konnektivität weg ist. Außerdem funktioniert dann keine Lastverteilung mehr.
- Netze auftrennen, daß z.B. Gäste die 16er-leitung dediziert bekommen. und die beiden anderen netze für weitere zwei subnetzte dediziert aufgeteilt werden? Ist imho ein Rückschritt und auch keine Option.
- NPTv6 nach RFC6296 verwnden? Habe ich persönlich keine Erfahrung damit, aber nicht jeder Router kann das (be.ip plus z.b. nicht)udn bringt oft auch andere Probleme mit sich, wenn man berichten im Internet gleiben darf. Cisco schreibt z.B., daß Multicast, Firewall, High Speed Logging (HSL) und syslog "not supported" ist.
Nachdem ihr Euch durch diese Textwüste gelesen habt, kommen wir endlich zu dem Thema, zu dem ich eine freitagsdiskussion eröffnen will:
Wie geht ihr mit der o.g. Problematik um Lösung des ipv6-Dilemmas mit providerprefixes am Multiwan-Anschluß . Was sind eure Erfahrungen, auf welche Probleme seid Ihr gestoßen und ist euch das bisher überhaupt aufgefallen?
Ich selber wanke noch zwischen den Optionen ipv6 nur auf einer Leitung zuzulassen oder NPT unter austausch des Routers einzusetzen. Was meint Ihr dazuß Oder habt ihr gar ganz andere Lösungsansätze (außer sich providerunabhängige v6-dressen zu holen und ein eigenes AS aufsetzen natürlich ).
Ich hoffe auf eine rege Beteilung und neue Erkenntnisse.
grüße,
lks
PS: Tapp- und Stilfuhler versuche ich wie üblich im Laufe der Diskussion zu beseitigen. Bis dahin sollen sie zu eurer Erheiterung dienen.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 7772139654
Url: https://administrator.de/contentid/7772139654
Ausgedruckt am: 25.11.2024 um 17:11 Uhr
6 Kommentare
Neuester Kommentar
Zitat von @LordGurke:
Du kannst bei RA festlegen, welches Präfix mit welcher Priorität verteilt wird. Dann könntest du das "schnelle" Präfix bevorzugen und alle Clients würden darüber ins Netz verbinden. Fällt das Präfix weg, weil die Leitung down geht, bleibt ja nur noch das andere übrig.
Du kannst bei RA festlegen, welches Präfix mit welcher Priorität verteilt wird. Dann könntest du das "schnelle" Präfix bevorzugen und alle Clients würden darüber ins Netz verbinden. Fällt das Präfix weg, weil die Leitung down geht, bleibt ja nur noch das andere übrig.
Genau so nutze ich das auch.
Bei dem Kunden wo Dir das besonders aufgefallen ist, wäre es wahrscheinlich am einfachsten, sich vom Provider ein größeres Präfix - mindestens /60 zuteilen zu lassen. Die langsameren Verbindungen mit IPv6 werden bevorzugt genutzt, da ja fast alle Betriebssysteme bzw. Browser per default IPv6 präferieren.
NPTv6 habe ich bisher nicht eingesetzt.
Am schönsten finde ich bisher wenn alle Clients sich ein oder mehrere GUAs aus jedem Präfix für das jeweilige Subnetz nehmen.
Irgendwelche Verrenkungen mit NAT und ULAs wären mir ein zu hoher Preis für das Loadbalancing.
Etwas zu dem Thema (was ich mir jetzt auch gleich mal durchlesen werde )
https://datatracker.ietf.org/doc/rfc8678/
Viele Grüße