IPv6 mit 2 Uplinks
Hallo,
ich habe eine kleine theoretische Frage zur Einführung von IPv6.
Beispiel:
Ich kriege vom ISP das IPv6 Netz "2001:db8:7562:dc00::/56" zugewiesen. Intern benötigen wir noch weitere IP-Netzwerke. Wir verwenden ein "Transfernetz", dass die Internet-Firewall mit zwei weiteren Routern verbindet. Dieses Netzwerk bekommt die Netz-ID "2001:db8:7562:dc00::/64". Die Router erhalten logischerweise eine IP in diesem Segment. Diese beiden Geräte routen weitere Netzwerke mit den ID's "2001:db8:7562:dc01::/64" bis "2001:db8:7562:dc04::/64" - soweit so gut...vom Prinzip her kein Problem.
Was passiert aber, wenn ich einen weiteren Uplink ins Internet habe (In der Skizze rot markiert)?
Wie verhält sich denn dann die Adressvergabe und das Subnetting?
Danke!
ich habe eine kleine theoretische Frage zur Einführung von IPv6.
Beispiel:
Ich kriege vom ISP das IPv6 Netz "2001:db8:7562:dc00::/56" zugewiesen. Intern benötigen wir noch weitere IP-Netzwerke. Wir verwenden ein "Transfernetz", dass die Internet-Firewall mit zwei weiteren Routern verbindet. Dieses Netzwerk bekommt die Netz-ID "2001:db8:7562:dc00::/64". Die Router erhalten logischerweise eine IP in diesem Segment. Diese beiden Geräte routen weitere Netzwerke mit den ID's "2001:db8:7562:dc01::/64" bis "2001:db8:7562:dc04::/64" - soweit so gut...vom Prinzip her kein Problem.
Was passiert aber, wenn ich einen weiteren Uplink ins Internet habe (In der Skizze rot markiert)?
Wie verhält sich denn dann die Adressvergabe und das Subnetting?
Danke!
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 305209
Url: https://administrator.de/forum/ipv6-mit-2-uplinks-305209.html
Ausgedruckt am: 28.04.2025 um 21:04 Uhr
10 Kommentare
Neuester Kommentar
vom ISP das IPv6 Netz "2001:db8:7562:dc00::/56" zugewiesen
Von keinem Provider der Welt wirst du diese v6 Adresse bekommen !https://tools.ietf.org/html/rfc3849
...soweit so gut...vom Prinzip her kein Problem.
Richtig, klassische Standard IP Adressierung 
Was passiert aber, wenn ich einen weiteren Uplink ins Internet habe
Was würde denn bei v4 passieren ?? Das ist doch identisch !Sieh in deine Routing Tabelle...dann weisst du was passiert. Die Frage die sich stellt ist WIE ist dein Routing ??
Das allein bestimmt wie mit dieser 2ten Leitung im Routing verfahren wird. Failover, Load Balancing...alles ist möglich. Je nach deiner Routing Konfiguration zu der du ja leider nicht das Geringste sagst...
Denkbar wäre ja auch ein LAG mit 802.3ad und LACP auf Layer 2... jedenfalls Hop by Hop.
Zitat von @aqui:
https://tools.ietf.org/html/rfc3849
Es war eine Beispieladresse die ich aus einem Heise-Artikel abgepinnt habe...vom ISP das IPv6 Netz "2001:db8:7562:dc00::/56" zugewiesen
Von keinem Provider der Welt wirst du diese v6 Adresse bekommen !https://tools.ietf.org/html/rfc3849
Was würde denn bei v4 passieren ?? Das ist doch identisch !
Sieh in deine Routing Tabelle...dann weisst du was passiert. Die Frage die sich stellt ist WIE ist dein Routing ??
Das allein bestimmt wie mit dieser 2ten Leitung im Routing verfahren wird. Failover, Load Balancing...alles ist möglich. Je nach deiner Routing Konfiguration zu der du ja leider nicht das Geringste sagst...
Denkbar wäre ja auch ein LAG mit 802.3ad und LACP auf Layer 2... jedenfalls Hop by Hop.
Sieh in deine Routing Tabelle...dann weisst du was passiert. Die Frage die sich stellt ist WIE ist dein Routing ??
Das allein bestimmt wie mit dieser 2ten Leitung im Routing verfahren wird. Failover, Load Balancing...alles ist möglich. Je nach deiner Routing Konfiguration zu der du ja leider nicht das Geringste sagst...
Denkbar wäre ja auch ein LAG mit 802.3ad und LACP auf Layer 2... jedenfalls Hop by Hop.
Naja bei v4 siehts momentan bei mir so aus, dass durch Policy-Based-Routing der jeweilige Uplink verwendet wird der zum Traffic passt. Außerdem wird ja auch noch das NAT/PAT drübergebügelt. Dadurch wird auf meine interne Struktur im globalen Routing keine Rücksicht genommen da ja nur die öffentlichen IPs in Erscheinung treten. Bei v6 ist ja alles transparent...
Grundsätzlich wollte ich wissen wie die adressvergabe bei zwei uplinks aussieht. Bekommen die Clients dann einfach 2 globale Adressen?! Wie wird im Client entschieden welche Adresse als Absender genutzt wird?
Moin,
IPv6 ist was das angeht sehr mächtig und auch sehr einfach aufgestellt. Den Begriff den du suchst nennt sich Mutli-Homeing und ist unter anderem hier beschrieben:
https://www.elektronik-kompendium.de/sites/net/2012211.htm
Ansonsten natürlich auch von Cisco die schönere aber auch teurere BGP Lösung und noch ein paar alternativen:
http://www.cisco.com/c/en/us/about/press/internet-protocol-journal/back ...
Na dann viel Spaß ;)
Gruß
Chris
IPv6 ist was das angeht sehr mächtig und auch sehr einfach aufgestellt. Den Begriff den du suchst nennt sich Mutli-Homeing und ist unter anderem hier beschrieben:
https://www.elektronik-kompendium.de/sites/net/2012211.htm
Ansonsten natürlich auch von Cisco die schönere aber auch teurere BGP Lösung und noch ein paar alternativen:
http://www.cisco.com/c/en/us/about/press/internet-protocol-journal/back ...
Na dann viel Spaß ;)
Gruß
Chris
Multi Homing hat mit dem obigen Szenario soviel zu tun wie ein Fisch mit einem Fahrad...sorry, aber ganz andere Baustelle. Hier geht es rein um Wegefindung sprich Routing. Multihoming besagt nur das ein Adapter multiple IP Adressen haben kann.
Zu dem Cisco Punkt muss man jetzt auch nicht mehr viel sagen aus Thema verfehlt....
Aber da wir den alle auch gelesen haben kam die Assoziation sofort.... Also nix abpinnen...selber nachdenken.
Entscheident ist die Routing Tabelle, deiner Edge Router und ob du da statisch dynamisch oder wie auch immer routest.
Letztlich wird es wie bei v4 auf ein Balancing mir Policy Routing rauslaufen wie du es jetzt schon machst.
Alternativ kannst du dich an einen ISP mit BGP-4 oder OSPFv3 anflanschen, dann machst du das Balancing automatisch inkl. Failover.
Es gibt viele Wege nach Rom... Letztlich ist die Welt bei v6 aber so wie bei v4.
Nur die Adressen sehen ein klein wenig anders aus
Zu dem Cisco Punkt muss man jetzt auch nicht mehr viel sagen aus Thema verfehlt....
Es war eine Beispieladresse die ich aus einem Heise-Artikel abgepinnt habe...
Ohne nachzudenken... Aber da wir den alle auch gelesen haben kam die Assoziation sofort.... Also nix abpinnen...selber nachdenken.Naja bei v4 siehts momentan bei mir so aus, dass durch Policy-Based-Routing der jeweilige Uplink verwendet wird der zum Traffic passt.
Siehst du !! Meinst du das das bei v6 anders ist nur weil die IPs ein bischen länger sind ?!Außerdem wird ja auch noch das NAT/PAT drübergebügelt.
Dat jibbet bei v6 ja nun nich mehr...Dadurch wird auf meine interne Struktur im globalen Routing keine Rücksicht genommen da ja nur die öffentlichen IPs in Erscheinung treten.
Das stimmt aber warum sollte es bei v6 anders sein ?? Auf das Routing hat NAT ja nur einen sehr bedingten Einfluss.Entscheident ist die Routing Tabelle, deiner Edge Router und ob du da statisch dynamisch oder wie auch immer routest.
Letztlich wird es wie bei v4 auf ein Balancing mir Policy Routing rauslaufen wie du es jetzt schon machst.
Alternativ kannst du dich an einen ISP mit BGP-4 oder OSPFv3 anflanschen, dann machst du das Balancing automatisch inkl. Failover.
Es gibt viele Wege nach Rom... Letztlich ist die Welt bei v6 aber so wie bei v4.
Nur die Adressen sehen ein klein wenig anders aus
Ich denke so langsam kommts. Allerdings hätte ich da noch eine kleine Teilfrage die ich an einem Beispiel klar machen möchte.
Bleiben wir bei dem Szenario wie ich es oben konstruiert habe. Es gibt eine Edge-Firewall/einen Edge-Router der zwei Uplinks zu zwei verschiedenen ISPs hat. Durch Policy-Based-Routing wird beispielsweise definiert, dass SMTP-Verkehr über Anschluss1 und HTTP über Anschluss2 geroutet werden soll. Ein Client befindet sich z.B. in Netz 3. Zugeteilt sind die Netzwerke des Anschluss1 - also um beim obigen Beispiel zu bleiben die Adressen "2001:db8:7562:dc03::/64" (Auch wenn die Adressen so eigentlich nicht vergeben werden). Anschluss2 wurde eine völlig anderer Präfix zugeteilt - z.B. weils unterschiedliche Anbieter sind.
Der betreffende Client schickt jetzt eine E-Mail per SMTP - auf IP-Ebene wird die Absendeadresse aus dem 2001:db8:7562:dc04::/64-Netzwerk angegeben. Die Firewall routet diese Nachricht über Anschluss1 raus. Die Rückantworten wie z.B. die TCP-Ack's kommen dann anhand der Absendeadresse auch wieder über den Anschluss1 bei dem Client an. Bis jetzt sollte es ja so richtig ablaufen.
Wie ist das denn dann jetzt aber wenn der Client per HTTP surft und die Policy die Kommunikation über Anschluss2 rausballert? Der Client hängt seine 2001:db8:7562:dc04::/64-Adresse auf IP-Ebene an...es wird zur Firewall geroutet...dort greift die Policy und die FW "schießt" den Verkehr über Anschluss2 raus. Da aber die 2001:db8:7562:dc04::/64-Adresse als Absender angegeben ist kommen Antworten (Auch wieder z.B. die TCP-Ack's) gezwungenermaßen an Anschluss1 an - richtig?
Bleiben wir bei dem Szenario wie ich es oben konstruiert habe. Es gibt eine Edge-Firewall/einen Edge-Router der zwei Uplinks zu zwei verschiedenen ISPs hat. Durch Policy-Based-Routing wird beispielsweise definiert, dass SMTP-Verkehr über Anschluss1 und HTTP über Anschluss2 geroutet werden soll. Ein Client befindet sich z.B. in Netz 3. Zugeteilt sind die Netzwerke des Anschluss1 - also um beim obigen Beispiel zu bleiben die Adressen "2001:db8:7562:dc03::/64" (Auch wenn die Adressen so eigentlich nicht vergeben werden). Anschluss2 wurde eine völlig anderer Präfix zugeteilt - z.B. weils unterschiedliche Anbieter sind.
Der betreffende Client schickt jetzt eine E-Mail per SMTP - auf IP-Ebene wird die Absendeadresse aus dem 2001:db8:7562:dc04::/64-Netzwerk angegeben. Die Firewall routet diese Nachricht über Anschluss1 raus. Die Rückantworten wie z.B. die TCP-Ack's kommen dann anhand der Absendeadresse auch wieder über den Anschluss1 bei dem Client an. Bis jetzt sollte es ja so richtig ablaufen.
Wie ist das denn dann jetzt aber wenn der Client per HTTP surft und die Policy die Kommunikation über Anschluss2 rausballert? Der Client hängt seine 2001:db8:7562:dc04::/64-Adresse auf IP-Ebene an...es wird zur Firewall geroutet...dort greift die Policy und die FW "schießt" den Verkehr über Anschluss2 raus. Da aber die 2001:db8:7562:dc04::/64-Adresse als Absender angegeben ist kommen Antworten (Auch wieder z.B. die TCP-Ack's) gezwungenermaßen an Anschluss1 an - richtig?
Zitat von @aqui:
Multi Homing hat mit dem obigen Szenario soviel zu tun wie ein Fisch mit einem Fahrad...sorry, aber ganz andere Baustelle. Hier geht es rein um Wegefindung sprich Routing. Multihoming besagt nur das ein Adapter multiple IP Adressen haben kann.
Multi Homing hat mit dem obigen Szenario soviel zu tun wie ein Fisch mit einem Fahrad...sorry, aber ganz andere Baustelle. Hier geht es rein um Wegefindung sprich Routing. Multihoming besagt nur das ein Adapter multiple IP Adressen haben kann.
Negativ. Multihoming sagt viel mehr, dass du eine IP-Route über mehrere unabhängige Anbindungen führst - so wie es ein Internetprovider mit mehreren Uplinks an verschiedene Carrier tut
Zitat von @Philipp711:
Wie ist das denn dann jetzt aber wenn der Client per HTTP surft und die Policy die Kommunikation über Anschluss2 rausballert? Der Client hängt seine 2001:db8:7562:dc04::/64-Adresse auf IP-Ebene an...es wird zur Firewall geroutet...dort greift die Policy und die FW "schießt" den Verkehr über Anschluss2 raus. Da aber die 2001:db8:7562:dc04::/64-Adresse als Absender angegeben ist kommen Antworten (Auch wieder z.B. die TCP-Ack's) gezwungenermaßen an Anschluss1 an - richtig?
Wie ist das denn dann jetzt aber wenn der Client per HTTP surft und die Policy die Kommunikation über Anschluss2 rausballert? Der Client hängt seine 2001:db8:7562:dc04::/64-Adresse auf IP-Ebene an...es wird zur Firewall geroutet...dort greift die Policy und die FW "schießt" den Verkehr über Anschluss2 raus. Da aber die 2001:db8:7562:dc04::/64-Adresse als Absender angegeben ist kommen Antworten (Auch wieder z.B. die TCP-Ack's) gezwungenermaßen an Anschluss1 an - richtig?
Prinzipiell ja, aber nur wenn euer Provider an Uplink 2 eure Pakete mit IPv6-Adressen von Uplink 1 überhaupt rauslässt, was angesichts der vergleichsweise langen Präfixlänge eher unwahrscheinlich klingt. Also tendenziell eher nicht, da die Pakete überhaupt nicht rauskönnen.
Am einfachsten lässt sich so etwas unter Zuhilfenahme eines PI-Präfix ("Provider Independent") umsetzen. Dabei müssen nur eure beiden Internetprovider mitspielen und das Präfix für euch announcen resp. ihr macht das selbst per BGP.
Dann könnt ihr mit einem großen Präfix (mind. /48) arbeiten und dieses eine Präfix bei euch verwenden. Fällt einer der Links aus oder ihr wollt einfach bestimmte Pakete anders routen könnt ihr das dann problemlos machen, weil euer Präfix ja über beide Provider zur Verfügung steht.
DAS wäre dann by the way das angesprochene Multihoming
Prinzipiell ja, aber nur wenn euer Provider an Uplink 2 eure Pakete mit IPv6-Adressen von Uplink 1 überhaupt rauslässt, was angesichts der vergleichsweise langen Präfixlänge eher unwahrscheinlich klingt. Also tendenziell eher nicht, da die Pakete überhaupt nicht rauskönnen.
Okay das Dachte ich mir...die Provider filtern ja auch im ipv4-Netz aus Sicherheitsgründen die IPs raus die nicht aus ihrem IP-Pool stammen...
Am einfachsten lässt sich so etwas unter Zuhilfenahme eines PI-Präfix ("Provider Independent") umsetzen. Dabei müssen nur eure beiden Internetprovider mitspielen und das Präfix für euch announcen resp. ihr macht das selbst per BGP.
Dann könnt ihr mit einem großen Präfix (mind. /48) arbeiten und dieses eine Präfix bei euch verwenden. Fällt einer der Links aus oder ihr wollt einfach bestimmte Pakete anders routen könnt ihr das dann problemlos machen, weil euer Präfix ja über beide Provider zur Verfügung steht.
DAS wäre dann by the way das angesprochene Multihoming
Dann könnt ihr mit einem großen Präfix (mind. /48) arbeiten und dieses eine Präfix bei euch verwenden. Fällt einer der Links aus oder ihr wollt einfach bestimmte Pakete anders routen könnt ihr das dann problemlos machen, weil euer Präfix ja über beide Provider zur Verfügung steht.
DAS wäre dann by the way das angesprochene Multihoming
Das heißt man benötigt zwingend einen solchen PI-Präfix und die ISPs müssen mitspielen (falls unterschiedliche ISPs vorhanden sind - z.b. Telekom und Kabel Deutschland).
Technisch gesehen haben dann beide Uplinks von den unterschiedlichen ISPs eine v6-IP mit dem gleichen Präfix.
Also sowas wie z.B. Anschluss1 -> 2001:db8:7562::0001/48 (Telekom) und Anschluss2 ->2001:db8:7562::0002/48 (Kabel Deutschland)??
In der Regel bekommst du vom Provider ein Transfernetz aus seinem eigenen Netz, aber das ist ja dem Rest des Netzwerks egal.
Ja, genau so ist das - beide Provider routen dir dann das selbe (dein!) IPv6-Präfix, welches du verwenden kannst und dem es dann egal ist, über welchen Link es herein oder heraus geroutet wird.
Ja, genau so ist das - beide Provider routen dir dann das selbe (dein!) IPv6-Präfix, welches du verwenden kannst und dem es dann egal ist, über welchen Link es herein oder heraus geroutet wird.
Okay hier schon mal vielen Dank für die Antworten...mir ist jetzt einiges klarer - allerdings ist mir wieder ein weitere Frage zum praktischen Ablauf der Adressvergabe eingefallen.
Es gibt in IPv6 verschiedene Adresstypen:
Link-Local-Adresse -> sind nur in der jeweiligen Broadcast-Domain gültig und werden nicht geroutet
Global Unicast -> Adresse die aus dem ISP-Präfix generiert ist und zur Kommunikation mit dem Internet und anderen Subnetzen fungiert
Site Local bzw. Unique Local Unicast -> Pendant zu den privaten IPv4-Adressen. Diese werden nur innerhalb der Unternehmung geroutet
Mir entgeht der Sinn der Site Local/Unique Local Unicas Adressen - wofür brauch man die noch konkret?
Die Global Unicast Adressen geben doch schon alles her was benötigt wird um mit dem Internet und anderen Subnetzen im gleichen Unternehmen zu kommunizieren. Konkret würde mir nur die Verwendung von Unique Local Unicast Adressen zur Adressierung von z.B. Netzwerkkomponenten wie Switches oder Access-Points mit festen IPv6-Adressen einfallen - diese können dann halt nicht mit dem Internet kommunizieren was ja prinzipiell nicht weiter schlimm ist.
Des weiteren war es ja in v4-Zeiten üblich die Server mit festen IP-Adressen auszustatten. Durch die verstärkte Konzentration auf DNS in ipv6 ist das doch nicht mehr Nötig, richtig? Bis auf Router und DNS-Server/Domänencontroller kann man doch der Autokonfiguration vertrauen...
So und wenn wir schon dabei sind geht's auch noch zum Thema VPN. IPv6 bringt im Standard schon IPSec und durch das transparente Routing werden klassische Site-to-Site-VPN's nicht mehr nötig sein, richtig?
Es gibt in IPv6 verschiedene Adresstypen:
Link-Local-Adresse -> sind nur in der jeweiligen Broadcast-Domain gültig und werden nicht geroutet
Global Unicast -> Adresse die aus dem ISP-Präfix generiert ist und zur Kommunikation mit dem Internet und anderen Subnetzen fungiert
Site Local bzw. Unique Local Unicast -> Pendant zu den privaten IPv4-Adressen. Diese werden nur innerhalb der Unternehmung geroutet
Mir entgeht der Sinn der Site Local/Unique Local Unicas Adressen - wofür brauch man die noch konkret?
Die Global Unicast Adressen geben doch schon alles her was benötigt wird um mit dem Internet und anderen Subnetzen im gleichen Unternehmen zu kommunizieren. Konkret würde mir nur die Verwendung von Unique Local Unicast Adressen zur Adressierung von z.B. Netzwerkkomponenten wie Switches oder Access-Points mit festen IPv6-Adressen einfallen - diese können dann halt nicht mit dem Internet kommunizieren was ja prinzipiell nicht weiter schlimm ist.
Des weiteren war es ja in v4-Zeiten üblich die Server mit festen IP-Adressen auszustatten. Durch die verstärkte Konzentration auf DNS in ipv6 ist das doch nicht mehr Nötig, richtig? Bis auf Router und DNS-Server/Domänencontroller kann man doch der Autokonfiguration vertrauen...
So und wenn wir schon dabei sind geht's auch noch zum Thema VPN. IPv6 bringt im Standard schon IPSec und durch das transparente Routing werden klassische Site-to-Site-VPN's nicht mehr nötig sein, richtig?
Negativ. Multihoming sagt viel mehr, dass du eine IP-Route über mehrere unabhängige Anbindungen führst
OK, zugegeben hast du natürlich Recht wenn jedes dieser unterschiedlichen Adressen ein anderes Gateway benutzt. So detailiert wollte ich jetzt nicht darauf eingehen, da das dann doch eher schon die Ausnahme ist.Normal würde man so ein Szenario mit normalem ECMP bei dynmaischen Routing machen oder noch simpler das im layer 2 mit einfachem Link Aggregation abfackeln was am besten ist.
Letzteres hat allerdings den Nachteil das dann beim Provider Router Schluss ist mit L2 LAGs.
