• This forum has a zero tolerance policy regarding spam. If you register here to publish advertising, your user account will be deleted without further questions.

kleines AS umziehen

greystone

Active Member
Hallo zusammen,

ich stehe gerade vor der Aufgabe ein kleines AS mit möglichst geringer Downtime umzuziehen. Alles auf einmal(server,router) umziehen würde auch gehen.

Bei mir kam mir zunächst die Idee das mittels VPN und NAT weiterzuleiten und die Antworten wieder zurück. Ein anderer warf mal eine "Bridge" in den Raum(wahrscheinlich auch mittels VPN(tap?) oder GRE als Interface dazwischen).

Die Frage an Euch ist: Wie würdet Ihr einen entspannten schrittweisen Umzug machen?

Grüße,
g.
 
Nur, um sicher zu sein, dass wir unter dem Begriff "AS" (Autonomes System) das exakt gleiche verstehen:
Du hast eine eigene AS-Nummer, eigene IP-Adressen und mindestens eine BGP-Session zu einem Carrier?

Die Begriffe "AS" und "NAT" lassen sich nämlich in keinem mir bekannten Kontext sinnvoll miteinander verbinden...
 
@Lord Gurke:

Da hast Du mich korrekt verstanden.

Mit NAT(DNAT+SNAT) meine ich, dass ich einzelne IP-Adressen über einen Tunnel in eine neue Umgebung route und den gleichen Weg auch wieder zurück, so dass ich z. B. nach und nach IP-Teilbereiche in die neue Umgebung routen kann, bis ich schließlich die Router und die IP-Routen am neuen Standort announce.
 
Disclaimer:Ich bin auf netzwerktechnischer Ebene weniger affin, es kann also durchaus bessere/effizientere Lösungen geben oder Probleme mit meinem Vorschlag.

Spontan würde ich das über einen Site-to-Site GRE Tunnel lösen wo dein primärer (also AS-announcing) Standort über Tabelle den Traffic für den sekundaren Standort weiterleitet. Brauchst dazu auf beiden Seiten entsprechendes GRE/VPN-Equipment oder -software, sparst dir aber dafür die Umkonfiguration auf interne/temporäre IP's.
Sobald der sekundare Standort die Mehrheit des Datenverkehr hat kannst du dann bereits den GRE-TUnnel "umdrehen"; das Announcen am dann neuen Primärstandort beginnen und den Datenverkehr an den alten Standort weiterleiten bis alle Geräte umgezogen sind.
 
Ich habe gelesen, dass es bei GRE-Tunneln Probleme gibt mit großen Paketen(also nahe der 1500 Grenze), da im Paket ja noch der GRE-Header drin ist, der die max. Paketgrösse dann reduziert. Das kann man dadurch lösen, dass man die Pakete fragmentiert, d. h. auf mehrere aufsplittet. Dazu muss allerdings das DF-Flag(Dont Fragment) aus den Paketen entfernt werden, was ich recht kompliziert finde und wo ich nicht weiß ob das überhaupt problemlos funktioniert. Irgendwas kompilieren, was dann manuell das DF-Flag aus den Paketen in Echtzeit rausnimmt.

Deswegen habe ich jetzt ein OpenVPN mit Layer-2 Bridge gebastelt, mit dieser Beispielanleitung:

https://ep.advantech-bb.cz/support/faq/detail/how-to-create-openvpn-tap-interface-bridge-mode
Testsetup geht bisher.
 
Irgendwas kompilieren, was dann manuell das DF-Flag aus den Paketen in Echtzeit rausnimmt.
Oder einen Paketfilter einsetzen, der soetwas kann, beispielsweise bei FreeBSDs PF mittels:
Code:
scrub on $ext_if all no-df ...

Etwas Ähnliches sollte es unter Linux eigentlich auch geben...
 
Wenn dein Provider die BGP Session über Multi-Hop erlaubt kannst du auch die "alte Session" am neuen Standort hochfahren und langsam schwenken wenn du siehst, dass über den neuen Uplink der Großteil des Traffic geht. Dann kannst du dir das ganze Tunnelsetup sparen.
Oder du nutzt den Tunnel um die alte BGP-IP tmp. zum neuen Standort zu ziehen.
 
Wenn dein Provider die BGP Session über Multi-Hop erlaubt kannst du auch die "alte Session" am neuen Standort hochfahren und langsam schwenken wenn du siehst, dass über den neuen Uplink der Großteil des Traffic geht. Dann kannst du dir das ganze Tunnelsetup sparen.

Und wie kommt der Traffic vom alten Standort ohne Tunnel zum neuen Standort?
BGP-Multihop alleine ist kein magisches Wundermittel, was Traffic von A nach B schafft. Mit BGP-Multihop stellst du lediglich eine TTL > 1 für die BGP-Session, mehr passiert aber nicht.

Um den Tunnel kommst du nicht herum. Aber jenachdem, was für Dienst du umziehst, kann sich (z.B. für HTTP) auch ein Reverse-Proxy lohnen.
Die Frage des Tunnels ist dann lediglich, ob du GRE benutzen willst (20 Bytes Overhead bei IPv4, kann innerhalb des Tunnel IPv4 und IPv6 transportieren) oder ob du eine Mischung aus IP-in-IP und IP6IP benutzt (da kann die MTU ein kleines bisschen höher sein).
Der Einfachheit halber würde ich aber zu GRE tendieren, weil du darin - wenn es beide Seiten zulassen - nötigenfalls auch L2-Traffic über mehrere Hops hinweg transportieren kannst und du damit eventuell dein Routingsetup vereinfachen kannst.
 
Back
Top