Hintergrund: derzeit läuft IPv6-Traffic teils suboptimal; Batman selektiver aufgrund der Metriken für IPv4 das beste Gateway und setzt DCHP-Broad- in Unicasts dorthin um. In aller Regel ist das so gewählte Gateway jenes, bei dem der L2TP-Tunnel endet.
Bei IPv6 greift Batman nicht ein. Folge: ggf. muß der IPv6-Traffic erst durch Batman zu einem anderen Gateway laufen, was mindestens Laufzeit, ggf. auch Performance kostet. Das Package gluon-radv-filterd löst dies Problem durch dynamische Filterung der IPv6-Route-Advertisements (jedes Gateway sagt bei uns »hier geht’s raus!«) basierend auf den von Batman getroffenen Entscheidungen.
Fortsetzung der Diskussion von Netzprobleme Unterkunft CMB:
Mit 1.2.0~56 scheint das wie gewünscht zu funktionieren, der Eintrag über ein anderes als das v4-Default-Gateway alterte auf dem Client raus und der neue übernahm in der v6-Routingtabelle.
Wer kann, bitte auf Testsystemen manuell installieren — im Laufe des Wochenendes werde ich das ggf. auch nach experimental schieben.
Weitere geplante Änderungen:
-
Änderung Namensschema
Statt l2tp-ORTXX werden die Gateways in der Firmware als gXXmYY adressiert werden, DNS CNAMEs verweisen dann für g01m01 (Gateway 01 für Mesh 01) auf l2tp-fra01, für g02m66 (Gateway 02 für Mesh 66) auf l2tp-gut01. In der Firmware werden dann nur noch vier Gateways gelistet, da wir /20 (4096 IPs) per Mesh definiert haben und weniger als 1024 IPs/Gateway nicht praktikabel ist bei DHCP. Etwaige Umschichtungen laufen damit dann über’s DNS, statt Gateways »auf Vorrat« in der Firmware zu versenken. -
Neuaufteilung Meshes auf Gateways
Statt kreuz und quer, werden Gateways zukünftig netztopologisch gruppiert. Mesh 01 läuft dann z. B. auf Servern in Düsseldorf, mit IPv4- und IPv6-Adressen, die primär über den Standort laufen. Dies vermeidet weiteres »scenic routing«. Mesh 02 entsprechend über Berlin, Mesh 03 über Hamburg … Fallen Standorte aus, können wir über DNS (s. o.), BGP und Ansible auf andere Standorte ausweichen.