Häufig kommt es vor, dass man Mesh-Verbindungen mit externer Richtfunk-Hardware betreibt. Man tut das, weil für die Richtfunk Hardware kein Gluon verfügbar ist oder weil es aus regulatorischen Gründen nicht erlaubt wäre (DFS). Für Gluon erscheint der Mesh-Link dann wie eine Kabelverbindung.
Manchmal hat man mehrere solche Rifu-Verbindungen hintereinander. Dann ist es verlockend, auf einem Node Mesh on LAN zu aktivieren und die Rifu-Verbindungen mit den LAN Ports zu verbinden. Dieser Artikel soll erklären, warum das oft eine schlechte Idee ist und wie man das Problem entschärfen kann.
Ein Switch ist auf Layer 2 transparent, das heisst man kann nicht erkennen ob ein Paket durch einen Switch geleitet wurde. Das verursacht das Problem, das die physische Topologie des Netzwerks vor BATMAN versteckt wird: BATMAN kann nicht sehen, über wie viele Richtfunk-Strecken ein Paket ging, logisch war das ein Hop, da der Switch das Paket einfach durchleitet.
Im obigen Bild gibt es eine Verbindung von A zu B und von B zu C, das heißt, A kann C nur über B erreichen. Wenn man einen Switch bei B verwendet, also zum Beispiel Mesh-on-LAN aktiviert und beide Mesh-Uplinks in dne LAN-Port steckt, entsteht folgende logische Topologie:
Das heisst, A glaubt nun, C direkt erreichen zu können, da der Switch die Pakete weiterleitet, ohne dass sie von BATMAN verarbeitet werden können. Da nun die Hop Penalty bei B keine Anwendung findet, kann es passieren dass A seinen Uplink über C wählt, wenn die Verbindung dorthin ausreichend wenig Paketverluste hat.
Je nach Szenario gibt es verschiedene Lösungsmöglichkeiten.
Diese Lösung funktioniert nur wenn man maximal zwei Richtfunkstrecken an jedem Node. Sie ist aber die einfachste Lösung.
Man aktiviert dazu Mesh on LAN und Mesh on WAN und steckt eine der beiden Rifu Strecken in den WAN Port und die andere in den LAN Port. Eine dritte Richtfunkstrecke kann man nicht anschließen, ohne wieder in das Problem zu laufen.
Die folgende Konfigurationsänderung ist im Allgemeinen nicht updatefest. Es kann sein, dass deine Konfigurationsänderungen nach einem Update verloren gehen. Es liegt also in deiner eigenen Verantwortung, einen derart veränderten Router auf den neusten Softwarestand zu aktualisieren. Bitte führe diese Schritte nur durch, wenn du die Zeit hast, den Node upzudaten.
Dieser Teil der Anleitung hängt stark vom verwendeten Router Modell ab.
In der Regel haben die meisten Router mit mehr als drei LAN Ports intern einen Switch. Der Router (genauer: die CPU im Router auf der das Linux läuft) ist dann mit einem Port an den Switch angebunden. Das bedeutet, dass Pakete zwischen den Switchports weitergeleitet werden können, ohne dass sie durch die CPU müssen. Somit bekommt BATMAN sie nie zu sehen.
Die Idee ist nun, den Switch so zu konfigurieren, dass jeder Switchport in einem eigenen VLAN ist. Die VLANs werden dann getagged an die CPU weitergeleitet, wo sie dann von BATMAN verarbeitet werden können.
Nützlich bei dieser Konfigurationsänderung ist der Failsafe-Mode von OpenWRT.
Zunächst richtet man die Router ein, im Config Mode Mesh-on-LAN aktiv, Mesh-on-WAN inaktiv.
Leider funktioniert jeder Switch in jedem Router leicht anders. Man kann somit keine allgemeingültige Anleitung geben, wie es funktioniert.
Daher gibt es hier Instruktionen für einige Router Modelle. Danach geht's weiter mit „Switchports als extra BATMAN-Mesh-Interfaces konfigurieren“.
Bei diesem Gerät ist im Treiber die Bedeutung der VLANs 1 und 2 fest vorgegeben, daher sollte man diese VLANs vermeiden.
In /etc/config/network
gibt es folgende Zeilen:
config switch_vlan option device 'switch0' option vlan '1' option ports '1 2 3 4 0'
Damit wird das VLAN 1 auf den Ports 0, 1, 2, 3 und 4 (diese Nummern stimmen nicht mit der Beschriftung am Router überein, sondern sind die internen Bezeichnungen) untagged konfiguriert.
An Port 0 hängt die CPU des Routers.
Diesen Abschnitt ändern wir zu:
config switch_vlan option device 'switch0' option vlan '3' option ports '1 0t'
Damit ist dann VLAN 3 nur noch auf Port 1 untagged und auf 0 tagged. Da das VLAN 3 jetzt nur noch tagged an der CPU ankommt, müssen wir die Konfiguration des Mesh-Interface anpassen, damit die Pakete getagged werden. Dazu suchen wir folgenden Abschnitt in /etc/config/network
:
config interface 'mesh_lan' option igmp_snooping '0' option ifname 'eth0' option index '4' option proto 'gluon_wired' option transitive '1' option macaddr '02:e7:89:47:0c:dc' option disabled '0'
Hier müssen wir eth0
durch eth0.3
ersetzen.
Jetzt müssen wir neue VLAN-Konfigurationen für die verbleibenden Ports erstellen:
config switch_vlan option device 'switch0' option vlan '4' option ports '2 0t' config switch_vlan option device 'switch0' option vlan '5' option ports '3 0t' config switch_vlan option device 'switch0' option vlan '6' option ports '4 0t'
Mit diesen Änderungen müsste das Meshing nur noch auf Switch-Port 1 funktionieren.
Folgende Switchports sind damit diesen Interfaces unter Linux zugeordnet:
Switchport (Beschriftung) | Switchport (intern) | Linux-Interface | neu |
---|---|---|---|
1 | 1 | eth0.3 | nein |
2 | 2 | eth0.4 | ja |
3 | 3 | eth0.5 | ja |
4 | 4 | eth0.6 | ja |
In /etc/config/network
gibt es folgende Zeilen:
config switch_vlan option device 'switch0' option vlan '1' option ports '2 3 4 5 0t'
Damit wird das VLAN 1 auf den Ports 2, 3, 4 und 5 (diese Nummern stimmen nicht mit der Beschriftung am Router überein, sondern sind die internen Bezeichnungen) untagged und auf Port 1 tagged konfiguriert. An Port 0 hängt die CPU des Routers, Port 1 ist der WAN-Port.
Diesen Abschnitt ändern wir zu:
config switch_vlan option device 'switch0' option vlan '1' option ports '2 0t'
Damit ist dann VLAN 1 nur noch auf Port 2 untagged und auf 0 tagged. Jetzt müssen wir neue VLAN-Konfigurationen für die verbleibenden Ports erstellen:
config switch_vlan option device 'switch0' option vlan '3' option ports '3 0t' config switch_vlan option device 'switch0' option vlan '4' option ports '4 0t' config switch_vlan option device 'switch0' option vlan '5' option ports '5 0t'
Mit diesen Änderungen müsste das Meshing nur noch auf Switch-Port 1 funktionieren.
Folgende Switchports sind damit diesen Interfaces unter Linux zugeordnet:
Switchport (Beschriftung) | Switchport (intern) | Linux-Interface | neu |
---|---|---|---|
1 | 2 | eth0.1 | nein |
2 | 3 | eth0.3 | ja |
3 | 4 | eth0.4 | ja |
4 | 5 | eth0.5 | ja |
Die Interface-Namen in den folgenden Beispielen müssen gemäß der Angaben im gerätespezifischen Teil angepasst werden!
Man muss sich für jedes dieser Interfaces MAC-Adressen auswählen. Dazu nimmt man die aktuelle MAC-Adresse des oben nicht mit „neu“ gekennzeichneten Interface (ip a s dev <name>
) und ersetzt das letzte Zeichen durch: 0, 8, 4 oder c, je nachdem was noch nicht in der aktuellen MAC verwendet wird.
Nun kann man in /etc/config/network
neue Mesh-Interfaces definieren:
config interface 'mesh_lan3' option igmp_snooping '0' option ifname 'eth0.3' option index '5' option proto 'gluon_wired' option transitive '1' option macaddr 'HIER MAC 1 einsetzten' option disabled '0' config interface 'mesh_lan4' option igmp_snooping '0' option ifname 'eth0.4' option index '6' option proto 'gluon_wired' option transitive '1' option macaddr 'HIER MAC 2 einsetzten' option disabled '0' config interface 'mesh_lan5' option igmp_snooping '0' option ifname 'eth0.5' option index '7' option proto 'gluon_wired' option transitive '1' option macaddr 'HIER MAC 3 einsetzten' option disabled '0'