Wir haben diese Woche Mittwoch über das Routing bzw. die Konnektivität unseres Backbones gesprochen.
Ich möchte hier mal kurze eine Idee anbringen, die mir eingefallen ist:
Nur an Standorten mit “Uplink” werden VPN Verbindungen zu unseren Gateways aufgebaut.
Das kann z. B. in Form von virtuellen Maschinen an dem Standort geschehen.
Jede Domäne hat dort dann eine eigene virtuelle Maschine.
Nur der Hypervisor hat direkten Zugriff zum Internetanschluss am Standort.
Alle Komponenten sind über ein untagged management vlan erreichbar (im beispiel vlan 5 genannt).
Desweiteren hat jede Domäne ein eigenes VLAN, was tagged ist (und erst direkt vor den Freifunk Knoten untagged rausfällt).
Die Komponenten an unserem derzeitig einzigen Uplink Standort sind ausreichend.
Am anderen Ende der Richtfunk-Verbindungen braucht man nur die Nanobeam und den Freifunk Router.
Am LAN-Anschluss der Nanobeam fällt dann untagged Meshnetz raus.
Die VLAN Funktionalität der Nanobeam sollte eigentlich dafür ausreichen. Falls dem nicht so ist (oder man an einem Standort mehrere Domänen haben (oder durchreichen) möchte, braucht man halt noch so einen Netgearswitch wie in der BezReg (kosten nicht viel und sind klein).
Routing macht das ganze jetzt nicht wirklich, aber unsere Struktur müsste auch erst hinreichend komplexer werden, bevor man über ernsthaftes Routing nachdenken muss.
Ich hoffe aus dem Bild wird mein Gedanke klar, ich hoffe ich habe keinen gedanklichen Fehler gemacht, falls etwas unklar, einfach fragen:
Das könnte man schon so machen, aber dann würde Freifunk an der Warpzone nie den Link zur Bezirksregierung nutzen, weil der über deren eigene Internetleitung aus Batmansicht besser ist, weil ein Sprung kürzer. (Also es sei denn man zieht in der WZ das Kabel, aber das wollen wir denke ich nicht.)
Ich bin eigentlich davon ausgegangen, dass es die VLANs sowieso gibt, damit wir quermeschen können. Aber ich würde zusätzlich von jedem Punkt einen L2TP-Tunnel über ein Trägernetz mit OSPF zu unseren Gateways ziehen, damit wir dort steuern können, wir der Link verläuft.
Dann kann man nämlich hingehen und die Kosten für den Warpzonelink deutlich erhöhen, weil der langsamer ist.
Dann hätte man für das Mesch an sich die Batmanlogik mit allen ihren Vor- und Nachteilen, wobei das nicht ins Gewicht fällt, weil mal realistisch nicht so viel Querverkehr da ist. Und für die Uplinks können wir mit OSPF steuern, wo die langgehen sollen.
Einziger Nachteil an der dualen Lösung ist, dass das Grundrauschen einer Domäne dann mehrfach durch dieselbe Funkstrecke muss. Aber ich denke, dass wir das verschmerzen können.
Da, wo die Funkbackbonestrecke nur Reserve sein soll, könnte man dann keine L2TP-Verbindung über Funk aufbauen. Dann wird sie nur benutzt, wenn sie gebraucht wird.
Grüße
Matthias
Ergänzung: Kleine Standorte könnte man dann trotzdem rein über Batman anbinden (Stichwort SK17). Das ist glaube ich das, was sich @kgbvax auch wünscht, weil man dann sehr kleine Standorte ohne große Softwarekonfig und Debian bauen kann. Einfach eine Nanobeambrücke, Batman drüber und einen Outdoor+ oder sowas aufhängen.
Ich verstehe noch nicht ganz, wie du durch ospf da auf weniger hops kommen willst. Magst du dein Konzept vllt mal kurz visualisieren? (Draw.io > vorlagen > networking > cisco, kannst aber von mir aus auch mit wölkchen und blumen arbeiten)
Ich glaube was @MPW meint ist, dass wir mit OSPF steuern können welchen Weg der Traffic nimmt. Das geht dann nicht über Anzahl Hops sondern über Penalties die man vergibt. (Soweit ich von @paulinsche das noch richtig im Kopf habe)
Ist halt nicht so flexibel wie Batman, dafür aber manchmal schlauer.
Im malen war ich nie so gut, aber letztendlich dasselbe Konzept wie deines: Pro Domäne gibt es ein VLAN mit dem Meschnetz.
Zusätzlich gibt es ein Trägernetz (IP) über das man L2TP-Tunnel aufbauen kann. Dann hat man neben den Meschlinks zusätzliche Punkt-zu-Punkt-Verbindungen zu den Gateways, die dann aus Batmansicht nur einen Sprung haben und daher bevorzugt werden. Wo der Tunnel lang geht, bestimmen wir dann mit OSPF.
OK, ich habe gerade bemerkt, dass mein Konzept Probleme macht wenn man mehr als einen Uplink im Backbone hat. Das kann man mit Tunneln und OSPF sicherlich lösen (aber vielleicht geht das auch einfacher). Ich verstehe aber immer noch nicht, wie du mit OSPF beeinflussen willst, dass der (ein) Uplink im Backbone gegenüber z. B. dem Warpzone Uplink bevorzugt wird. Das sind doch zwei verschiedene Dinge. Zwar hätte meine Lösung einen Hop mehr als deine aber durch die BATMAN Logik könnte immer noch der WZ Uplink gewählt werden. Außerdem ist es ja durchaus üblich, dass in der WZ (und am Hawerkamp) Knoten meshen. Daher wird es wohl Knoten geben, die zum WZ Uplink weniger hops haben werden als zum Backbone Uplink (außer du flanscht den BB Uplink an die Kiste, die den WZ Uplink macht). Daher kommen wir um eine penalty auf dem WZ Uplink wohl nicht umherum.
Außerdem ist das Verhalten, dass das Backbone als Backup als fungiert an anderen Standorten ja durchaus wünschenswert (oder es gibt gar keinen lokalen Uplink).
Daher bleibt für mich als einziger Vorteil von OSPF (und Tunnel darüber), dass es verhindert, dass ein ungünstiger Uplink innerhalb des Backbones gewählt wird.
Das könnte man durch mehr VLANs verhindert, sodass Traffic nicht direkt zwischen zwei Richtfunkverbindungen gehen kann, sondern immer erst über das Gluon (und somit über einen Hop mehr).
Wir würden damit sämtliche Komplexität an den Standorten mit Uplink konzentrieren, wo wir ja tendenziell eh mehr Hardware stehen haben (müssen).
Anmerkung: Meine Annahmen setzen voraus, dass alle Richtfunkverbindungen point-to-point sind.
In OSPF kann man Kosten einstellen. Die Router über die Warpzone-Anbindung wird dann einfach teurer eingestellt als die Router über die Bezreg und schon geht der L2TP darum.
Das fragte ich mich auch. Ich kann es halt immer noch nicht nachvollziehen. Daher mein Wunsch nach einer Grafik o. Ä., die das etwas filigraner aufschlüsselt.
Man kann intern im Backbone über OSPF beeinflussen wo batman aus oder in dem Backbone gekippt wird.
Also kann man dem sagen solange der link zur Bezreg vorhanden ist nehm den, wenn der wegbricht schmeis alles über die WZ Anbindung raus.
Der WZ ist afaik kein Bestandteil des Backbones und somit auch nicht im OSPF drin. So habe ich es zumindest verstanden. @mpw Nochmal: Bitte skizziere es. Wenn su nicht malen willst, dann beschreibe es als Graphen, den du entsprechend beschrifest. Der letzte Mittwoch hat doch schon gezeigt, dass wir alle aneinander vorbei reden.
Im Backbone stehen also Geräte, die OSPF können? Welche sind das? Was für IP-Netze werden da geroutet, und wie ist das Netz an das Internet angeschlossen?
Ich verstehe folgendes: In der Warpzone stehen zwei FF-Knoten, die über l2tp an den VPN heran geführt werden. Die beiden Knoten sind mit ihrem WAN-interface an einen Router angeschlossen, der zwei OSPF Nachbarn sieht. Einmal durch die Warpzone-Anbindung einmal durch die Bezreg.
Die OSPF-Nachbarschaft über die Warpzone-Anbindung wird über einen GRE-Tunnel gebaut, die Nachbarschaft durch die Bezreg irgendwie.
In der Warpzone könnten auch zwei vorgeschaltete Router stehen (Redundanz), aber dann müsste auf dem Gluon OSPF aktiviert werden, damit der Knoten die bessere Route wählen kann.
Ich finde auch, dass bei einem persönlichen Gespräch mit Tafel weniger aneinander vorbei geredet wird. Daher weniger Text, mehr Zeichnungen Und noch besser ein Treffen.
In die Runde geworfen…können unsere Netzwerkgeräte (Router, Switche,…) auch IPv6 damit die von allen Seiten auch bei Störungen erreichbar sind?
Irgendwie ist nirgendwo erwähnt, dass mal eine VM im Gespräch war. Zumindest meine ich mal mit @MPW drüber gesprochen zu haben bevor ich weg musste. Auf die dann OSPF und ein KVM-Image (Gluon) als MOL-Uplink.
Damit ist dann für die Geräte in der Zone die KVM-Maschine der kürzeste Weg.
Und dann entscheiden wir über Penalties wo es lang geht.
@descilla warum sollten wir von der Zone aus nicht weiter unser Netz spinnen?
P.S. vielleicht mal ich dich noch irgendwas im Paint.
Und noch besser ein Treffen.