Loops im Netzwerk finden und eliminieren
Entstehung von Loops
Loops entstehen, wenn man innerhalb eines Layer2 Netzes eine Schleife herstellt. Dies kann zum Beispiel passieren, wenn man zwei Freifunk Router mit einem Kabel an den Client Ports (beim 841 also die gelben Ports) miteinander verbindet.
Auswirkungen
Loops führen zu einer starken Einschränkung der Stabilität und Performanz des gesamten Netzwerkes.
Zusätzlich dazu kann man auf den Gateways folgende Zeile im dmesg beobachten:
ff-lev: received packet on mesh-lev with own address as source address (addr:02:ca:fe:76:03:01, vlan:0)
Die MAC-Addresse in Klammern sollte hierbei die MAC Addresse des Gateways sein.
Auf dem betroffenen Knoten kann man folgende (oder ähnliche) dmesg Zeile beobachten:
br-client: received packet on eth0 with own address as source address
Wie kann man nun aber identifizieren welcher Knoten im Netzwerk für den Loop verantwortlich ist?
Vorgehen
1. Verbindung mit dem betroffenen Netzwerk herstellen
Eine Verbindung, zum beispiel per WLAN, herstellen um eine Innensicht des Netzwekes zu erhalten.
Grundsätzlich ließe sich hier auch vom Gateway aus auf das Interface schauen.
2. Verwendung von Wireshark zur Identifikation, dass ein Loop besteht und welche MAC Adresse involviert ist.
Am einfachsten erkennbar wird ein Loop durch ARP Pakete mit der Mitteilung duplicate use of 10.76.1.3 detected!.
Die IP sollte entsprechend die IP eures Gateways sein.
Wireshark zeigt ebenfalls in den Details des Paketes an, welche MAC Addresse ebenfalls diese IP beansprucht. In diesem Fall ist dies die 16:6e:0e:76:03:01
3. Herausfinden über welchen Verbindungsweg der loopende Knoten am Gateway anliegt
Hierzu verwenden wir die batctl Tools.
Mithilfe von batctl tr können wir schauen welchen weg die Pakete zu der gefundenen MAC Addresse nehmen:
[felix@gw3 ~]$ sudo batctl -m mesh-lev tr 16:6e:0e:76:03:01
traceroute to 16:6e:0e:76:03:01 (ce:3b:36:ab:d2:5b), 50 hops max, 20 byte packets
1: 02:ca:fe:76:01:00 0.636 ms 0.497 ms 0.649 ms
2: ce:3b:36:ab:d2:5b 65.976 ms 95.890 ms 80.734 ms
Wie wir hier sehen können fühlt sich der Knoten mit der MAC Addresse ce:3b:36:ab:d2:5b ultimativ verantwortlich für alle Pakete, die an 16:6e:0e:76:03:01 gerichtet sind. Die Höhe des Pings sagt uns auch, dass der loopende Knoten vermutlich per VPN angebunden ist.
Jedoch sehen wir auch, dass ein weiterer Hop zwischen dem loopenden Knoten und unserem Gateway liegt. In diesem Fall ist das ein weiteres Gateway (gw1), über das der loopende Knoten tatsächlich angebunden ist. Zur weiteren Fehleranalyse müssen wir daher auf das gw1 zugreifen. Sollte im Traceroute nur ein Hop angezeigt werden bedeutet das, dass der loopende Knoten direkt mit dem Gateway verbunden ist auf dem wir gerade arbeiten.
4. Herausfinden an welchem Bridgeport der Router anliegt
Mit der MAC Addresse des loopenden Knotens im Gepäck schauen wir auf gw1 nach dem Bridgeport an dem die betreffende MAC anliegt:
[felix@gw1 ~]$ sudo brctl showmacs tun-lev | grep ce:3b:36:ab:d2:5b
8 ce:3b:36:ab:d2:5b no 0.05
tun-lev ist hierbei die Bridge, in dem alle Tunneldigger L2TP Interfaces zusammengefasst sind.
Die erste Zahl in der Zeile benennt den Bridgeport (hier: Port 8).
5. Herausfinden welches L2TP Interface der Bridgeport ist
Mit der Nummer des Bridgeports alleine können wir nicht viel anfangen, wir müssen also herausfinden wie das L2TP Interface heißt, das sich hinter diesem Bridgeport verbirgt.
Hierbei hilft uns der Kernel und dmesg:
[felix@gw1 ~]$ dmesg | grep "port 8" | tail -n1
[11144.591846] tun-lev: port 8(l2tp162-162) entered forwarding state
6. Herausfinden welcher Knoten hinter dem L2TP Interface hängt
Hierzu kann das Syslog von Tunneldigger befragt werden:
[felix@gw1 ~]$ sudo journalctl -u tunneldigger-broker@leverkusen --since "10:00" | grep -E "Creating tunnel.+with id 162" | tail -n1
Jul 03 11:55:31 gw1.fflev.de python2[1314]: [INFO/tunneldigger.broker] Creating tunnel x.x.x.x:53001 (0019995fffff) with id 162.
Der problematische Knoten ist also 0019995fffff.
Über die Karte oder eine nodes.json lässt sich anhand der Knoten ID auch herausfinden welcher Knoten das ist und eventuell auch wo er steht und wie der Besitzer zu erreichen ist.
Beispiel-Link für Meshviewer: https://map.fflev.de/#/de/map/0019995fffff
6. Den Knoten per Tunneldigger Blackliste aussperren
Wie im L2TP/Tunneldigger Serverdoku-Thread beschrieben kann eine Blackliste im Up-Hook Skript des Tunneldiggers den entsprechenden Knoten anhand seiner ID aussperren um somit erst mal Ruhe im Netz zu haben.
Ggf. ist es notwendig mehr als einen Knoten auszusperren.
) an den Clientports miteinander per Patchkabel verbinden. Also beispielsweise einen 841er mit einem Patchkabel an einem gelben Port mit einem gelben Port eines anderen 841 verbinden.