Hallo zusammen,
im Moment ist es ja ziemlich schwierig, IPv6-Traffic unter den Supernodes zu verteilen. Wäre es nicht sinnvoll, die router advertisements genau so wie die DHCP-Anfragen per batman-adv gateway mode zu filtern, sodass die Knoten sich für ein IPv6 gateway entscheiden?
Gibt es eine bessere, umsetzbare Lösung? Habe ich einen Denkfehler?
LG PetaByteBoy
Ich würde erwarten, dass dies nur beim ausgehenden Traffic Abhilfe bringen würde.
Eingehend entscheidet ja die beste Route im ffrl Backbone welche der möglichen Routen genommen wird.
Ich habe mal von @Lars gehört, dass es da einen experimentellen Patch für gibt, um genau dieses zu implementieren.
Aber das Hauptproblem ist meiner Meinung nach nicht, dass es innerhalb der Kollisionsdomäne schlecht läuft, sondern von außen. Die genatteten Pakete kommen immer genau zu ihrem Gateway zurück. Bei V6 kommen alle Pakete zu einem Gateway zurück.
Bei zwei Gateways müssen also schon 50% der Pakete nochmal zum anderen Gateway einen zusätzlichen Sprung nehmen, bei dreien schon zwei Drittel usw.
Das ist das eigentliche Problem. Man müsste irgendwie zwei Sub-Präfixe haben, die man separat an den FFRL schicken könnte.
Grüße
Matthias
Das ist aber nur ein Problem wenn der Traffic zwischen den Supernodes stört.
Solange hier nur Traffic zwischen untereinander gut angebundenen Rechenzentren oder gar interner Traffic entsteht, ist das doch harmlos.
gluon-radv-filterd · master · ffamt / gluon-packages · GitLab ist bekannt? (Zufällig vor kurzem drüber gestolpert.)
Aber ich stimme @MPW zu, primär senden die Netze eher weniger, als sie empfangen, somit ist eher der Rückweg das Problem. Und hier kollidieren dann die Prinzipien des Internetroutings mit dem Freifunk-Aufbau. Kleinere Präfixe (unterhalb des /64 je Mesh) lösen nur das Problem, daß ein Link oder Gateway (bzw. ‚Supernode‘ bzw. Backbonerouter) allen v6-Traffic abbekomt, zu Lasten der FFRL-Infrastruktur. Da v6-Adressen im /64 des Meshs quasi zufällig sind, teilte das nur den Traffic zw. FF-Community und FFRL etwas auf; da der FFRL aber auch nur mit Wasser zwischen den vier Standorten kochen dürfte, ist das wahrscheinlich eher keine Option.
(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 
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.
/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.
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.
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.
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.