Wenn ich das richtig sehe, passiert folgendes: In dieser Konfiguration senden beide Gateways (also Supernodes) RAs mit sich selbst als Router. Gluon macht nichts spezielles damit (anders als mit DHCP), sodass also potentiell Clients einen anderen Router wählen, als der Knoten für seinen fastd-Tunnel. Es muss also Traffic zwischen den Gateways hin und hergeschafft werden - und da unsere Gateways Traffic-technisch ziemlich gut ausgelastet sind, wäre das eher ungünstig.
Für den ausgehenden Traffic kann ich mir noch eine Lösung vorstellen (Anycast-IPv6 als Router eintragen), aber für den eingehenden Traffic (und das ist ja die Mehrheit) bringt das nichts - Rheinland wird den Traffic bei dem GW abladen, der den Präfix ankündigt.
Daher die Frage: Stimmt das so? Und falls ja, gibt es da irgendeine Lösung, oder wird üblicherweise der Inter-Gateway-Traffic einfach in Kauf genommen?
Es gibt dafür keine befriedigende Lösung.
Der Stein der Weisen ist noch nicht gefunden.
Und wenn man 5 Gateways hat, dann gibt es schon 4/5-„Chance“ auf Quertraffic.
Einzige Lösung: Domains früh teilen und mit nur einem Gateway arbeiten. Und dort im Active/Passive mit seinem Backup aufsetzen. Mit verteilten Rollen mit einer zweiten Domain.
Ja, so sieht es leider bei uns in Münster aus. Wir haben bisher auch noch keinen Weg gefunden das in den Griff zu bekommen, vor allem weil Batman hier schon das Problem ist. Clients wählen halt total zufällig ein v6 Gateway. Da bei uns ~35-40% IPv6 Traffic ist, entsteht da schon ein bisschen Quertraffic.
PS: Der Wiki-Artikel ist ein bisschen veraltet. Mittlerweile rollen wir das via Ansible aus. Wir haben radvd und DHCPv6 weggeworfen und nutzen radv in bird: Zeile 24 bis Zeile 34.
Wenn ich es richtig gesehen habe, gibt es noch einen weiteren Ansatz aus der Heimwerker-Ecke:
Jedes Gateway announced seinen eigenen IPv6-Prefix, die Gateways routen aber nichts weiter.
Die Clients stehen als mit x IPv6-Adressen da und haben gefälligst selbst zu bemerken, welche gerade funktioniert (und welche nicht.)
Das ist dann auch so ziemlich die sinnvollste Möglichkeit, wenn man z.B. IPv6 „nur über Schweden-Tunnel“ bekommt.
Ja, das gibt Probleme bei Wolken mit mehreren Uplinks…
Hm, interessante Idee. Aber so, wie ich es verstanden habe, korreliert das gerade funktionierende am gewählten Gateway nicht mit dem kürzesten Weg, also dem Gateway an dem man per Fastd oder allgemein VPN hängt.
Weil eben Batman das Gateway relativ zufällig wählt. Wenn es da doch einen halbwegs funktionierenden Algorithmus gibt, würde ich um mehr Infos bitten.
Danke für eure Antworten! Wir werden dann wohl mit dem Ausrollen von IPv6 warten, bis wir GWs mit mehr Bandbreite haben - oder bis Batman auch IPv6 „lenken“ kann wie es das bei IPv4 tut.
[quote=„descilla, post:3, topic:10690“]
PS: Der Wiki-Artikel ist ein bisschen veraltet. Mittlerweile rollen wir das via Ansible aus. Wir haben radvd und DHCPv6 weggeworfen und nutzen radv in bird: Zeile 24 bis Zeile 34.
[/quote]DHCPv6 haben wir gar nicht erst eingerichtet . Wenn dadurch Windows-Kisten kein IPv6-DNS bekommen… naja. Sollen sie halt IPv4 nehmen, geht ja auch.
Aber dass bird auch RAs kann, wusste ich nicht. Kommt mir irgendwie ein wenig willkürlich vor, BGP und RAs in einem Daemon zu kombinieren. Wir haben gerade erst von dnsmasq auf unbound+radvd+dhcpd umgestellt, und das klappt alles (und der Load ist auf den GWs messbar zurückgegangen), daher lasse ich das lieber, wie es ist
Ich habe inzwischen ein Gluon-Paket gebastelt, dass gegen den Inter-GW-Traffic bei IPv6 hilft: https://github.com/freifunk-saar/gluon-ffsaar/tree/master/gluon-filter-ra. Was das im Wesentlichen tut: Es baut per ebtables einen Filter, der nur Router Advertisments vom gewählten Gateway durchlässt. Die Rechner kriegen so nur die RAs für das gewählte GW, und beim GW-Wechsel wechseln die Rechner auch ihren Router entsprechend. (Das klappt tatsächlich besser als bei IPv4.)
Dabei mache ich mir zu nutze, dass ich aus der MAC-Adresse, die Batman angibt, durch die Struktur unseres Netzwerks, recht einfach die link-lokale IPv6-Adresse des entsprechenden GWs berechnen kann. Momentan müsste man das Paket also forken, um es woanders einzusetzen. Wenn es da Interesse gibt, bin ich gerne bereit, das zu verallgemeinern – es muss nur jemand eine gute Idee haben, wie man das Mappen von Batman-MAC-Adresse auf link-lokale-Adresse am besten in der site.conf beschreiben kann.
. Wenn dadurch Windows-Kisten kein IPv6-DNS bekommen… naja. Sollen sie halt IPv4 nehmen, geht ja auch.