(Sorry, bekomme das in die vorige Antwort nicht mehr rein.) Jain, wir haben a virtuelle Links, die über i. d. R. ein physisches Interface gehen, irgendwann ist das halt mit v6 voll, während die anderen Kisten Luft satt haben. V4 kommt zum NATenden Server zurück, v6 i. d. R. über nur einen Link zw. lokaler Community und dem Upstream (lies: FFRL) und damit einem Server. Damit verschenkt man ggf. Inklusivtraffic und muß auf einem Server extra zahlen, obwohl es in der Summe reichte.
Wir haben 2 Gateways die per gretap miteinander verbunden sind. Die Gretaps sind in bat0, genauso wir der fastd Tap Interface verbunden.
Dies führt dazu, das Router Advertisement aus einen Gateway verdoppelt werden und der andere Gateway sich auch meldet.
Die Mode entscheiden sich für eine IPv6 Route entsprechend der zuletzt erhaltenen RA. Statistisch dürfte 60% des IPv6 Traffic über der Gateway/Gateway Tunnel laufen. Der GW/GW Traffic verringert merklich die zur Verfügung stehende Brandbreite.
Radvd antwortet auf RS immer mit ein Multicast RA. Diese RA werden dementsprechend an alle Mode und Clients verteilt.
batman-adv dürfte die passende Instanz sein damit ein wenig mehr Ruhe herrscht.
Wir setzen derzeit v6 so ein, daß nur auf einem unserer 4 (batman-) Gateways radvd einen öffentlichen Prefix (aktuell FFRL, vormals FVFN, vorübergehend HE) bekannt gibt. Initiales Setup hatte radvd identisch auf allen GWs, aber das macht aus Gründen des externen Routings schon wenig Sinn.
Je nach Tarif den man hat ist das aber unproblematisch, da nur der ausgehende Traffic berechnet wird. Bei uns läuft es in etwa so, Hetzner ist rechnet da auch sehr angenehem ab:
Der monatliche Trafficverbrauch berechnet sich nur aus ausgehendem Traffic. Eingehender und interner Traffic werden nicht berechnet.
Führt das nicht zu Problemen, wenn dieses eine Gateway ausfällt? Und warum die ausgehenden Pakete auch noch über das eine Gateway leiten? Die können doch direkt raus in Richtung FFRL-Backbone geschickt werden.
Am überfüllten Interface ändert das aber nichts → intern /64er dem FFRL announcen zu können würde helfen. Bzw. die /64er in /56er Blöcken über verschiedene Server anzukündigen ginge ja jetzt schon.
Dazu müßten wir überall ins Mesh announcen, was ggf. zu Traffic KreisGT (VPN) - Gütersloh (fastd) - Falkenstein (radvd) - FFRL führt. Z. Zt. announcen wir deshalb intern nur in GT, d. h. intern wird v6 immer zum GW in GT geroutet, und die GWs in Falkenstein sind (fastd, batman_adv und radvd) deaktiviert. Nächster Schritt wird wohl sein, beide GWs in GT radvd sprechen zu lassen (Redundanz) und das verlinkte Package auszuprobieren. Dann sollte das fastd/L2TP-GW hoffentlich auch das v6-GW sein. Wir werden sehen und dann hoffentlich Falkenstein reaktivieren können.
Bessere Verteilung inbound wird wohl erst möglich werden durch eigenes AS und Routing sowohl über lokalen Upstream als auch FFRL. Aber bis uns die GBit-Interfaces vollaufen, haben wir zum Glück noch Zeit 
2 „Gefällt mir“
Genau sowas habe ich gesucht!
Wie ich sehe ist die Diskussion langsam aber sicher ins OT abgedriftet.
Ich sehe nicht das Problem: Jedes GW bekommt ein /64 vom großen /48, das der FFRL verteilt. Announced werden muss dabei aber ein /52 oder so, weil kleineres nicht im Internet geroutet wird.
Somit bekommt der Client je nach Gateway eine Adresse aus einem anderen Adressbereich für den Internet-Traffic und der Traffic geht in beide Richtungen über das gewählte GW.
1 „Gefällt mir“
/56 ist das Minimum. Aber läuft das denn zusammen, da verschiedene /56 rumfliegen?
Kriegen nicht einfach alle Geräte zwei IPV6 und der Vorteil ist dahin?
Ja, wenn du mehrere /56 gegenüber dem Backbone announced, kommen auch Pakete an alle diese /56 zu dir.
Genau danach habe ich gefragt: So ist es normalerweise, aber ich hatte die Idee (offensichtlich nicht als erster), man könnte ja die router advertisements filtern, sodass ein gerät immer nur die v6 im Netz seines gewählten (batman-adv-)Gateways bekommt.
2 „Gefällt mir“
So müssen wir es wohl mittelfristig machen.
Was wäre denn dein besserer Vorschlag wenn du meinst es ist eine mittelfristige Lösung? Ich sehe mit der Lösung nur das Problem, dass dazu ein seperates Paket auf dem Router benötigt wird, dessen Qualität ich erst noch angucken muss.
Ich habe mich auch mit Filtrierung vin RA befasst un ein filter gebaut.
Meine Pberlegung war: Alle Geräte erhalten die RA der verschiedene Gateway. Die Preference der Route bleibt für das Hauptgateway unangetastet, für der/die andere Gateways wird die Preference auf low gestellt.
Bei dieser Scenarion wählt der Client automatisch die Routen mit der höchste Preferenz, erhält dafür mehrere Globale IPv6.
Unter Linux funktionniert es. Mit Windoof 10 (in eine VM) scheint es auch zu gehen. Welche Gateway aktuel ist kann aud der batman gateways Datei entnommen werden.
Das ganzes setzt voraus, dass die Gateways unterschiedliche Präfixe verteilen.
Vorteil gegenüber die Lösung von „fffamt“ wäre ein geingeren CPU Aufwand auf die Router.
Auf de GW-Seite beshet allerdings immer noch ein Problem. Bei ein RS wird von radvd immer ein multicast gesendet, diese müsste korrigiert werden.
Ne, ich meinte, dass wir mal damit anfangen müssen, das zu implementieren. Eine bessere Lösung sehe ich derzeit nicht.
Ich glaub, solange das alles statisch ist, wird das gut funktionieren. Interessant ist, was passiert, wenn geroamt wird. Dann muss das quergeroutet werden. Und die Filter dürfen das nicht verhindern. Sie sollten sich also ausschließlich auf die RA-Pakete beziehen.
2 „Gefällt mir“
Die optimale Lösung ist es die Filterung bei batman-adv zu verlagern. Solche Vorschläge gab es schon vor 4 Jahre, daraus wurde nichts.
Das Problem ist aber ziemlich komplex.
Bei uns sind 2 GW vorhanden. Diese sind per Tunnel miteinander verbunden. Die Tunnel Interface haben als Master bat0. Dies führt dazu, dass die Clients RA von beide GW erhalten. Ohne Eingriff auf der Batman Ebene lässt sich dies kaum lösen.
Eine weitere Baustelle ist RADVD. laut meine Tests (mit der Version 2.11) werden RS immer mit multicast RA beantwortet. Wenn ein Client ein RS schickt erhalten alle Client automatisch die Antwort.
Auf Node Ebene sollten die RA auch gefiltert werden, am besten in Batman.
In unsere Netz verteilen die GW das gleiche Präfix. Dies bedeutet, dass der Ausgehende Verkehr über irgend eine der GW zufällig läuft der Eingehenden teilweise über der GW/GW Tunnel laufen muss. Bei unterschiedliche Präfixen würde der Eingangsverkehr immer über der richtige GW laufen, dies setzt aber voraus das die Clients entweder nur die RA des bevorzugten GW erhalten oder RA mit unterschiedliche Route Präferenzen.
Beim Empfang von RA mit unterschiedliche Präferenzen wählt der Client die Route mit der höchste Priorität, die Nachrichten gehen immer der gerade Weg in beider Richtungen.
Bei Roaming würde die ndisc gegebenenfalls zuschlagen und der GW/GW Umweg würde für die bereits bestehenden Verbindungen erfolgen.
1 „Gefällt mir“
Soweit ich das verstehe werden die Pakete auf dem Knoten per ebtables gefiltert, sodass nur eine der RAs zum Client durchkommt.
Am saubersten wäre natürlich trotzdem, das in batman-adv einzubauen, aber von der Funktion her tut sich da nichts.
Meine Clients erhalten von beide GW jeweils ein RA. Der Router dagegen die doppelte Menge.
Da gibt es auch schon eine weile einen PR, das Upstream zu mergen:
https://github.com/freifunk-gluon/gluon/pull/838
Wir haben bei uns etwas selbstgehacktes in Betrieb, das aber ordentlich zu funktionieren scheint - der Traffic zwischen den Gateways scheint ziemlich exakt dem Broadcast-Traffic zu entsprechen.
Die Lösung von ffsaar eliminiert alle router advertisements. Dies bedeutet, dass jeder Node selbst Router advertisement für seine Clients erzeugen muss. Damit werden Router Solicitations vom Router beantwortet. Werden die RS trotzdem nicht an den Gateways weitergeleitet ? RS werden an eine multicast Adresse gesended und als Folge gibt es einer Antwort von alle radvd Server. Das Verfahren setzt auch das Vorhandensein ein dhcpv6 auf die Gateways.
Nein; wenn das passiert, geht irgendwas schief. Die RAs vom vom Batman ausgewählten Gateway sollten durchkommen. So funktioniert das auch hier bei uns im Netz.