Hallo zusammen,
nachdem mich das Thema einiges an Zeit gekostet hat, möchte ich es hier mal vorstellen. Ich denke doch, dass ich nicht der erste bin, der sich mit Multi-DSL an einer Unterkunft abmüht - leider findet man weder ausreichend Informationen noch best-practice dazu.
Dies ist natürlich nur ein kurzer Abriss, der viele Entwicklungen dazwischen auslässt und nur die wichtigsten „Lessons Learned“ und Meilensteine darstellt; leider wirds tortzdem zu lang.
Zudem versuche ich das ganze möglichst wenig technisch zu schreiben, damit eine tiefe Einarbeitung in Protokoll und OpenWRT nicht nötig ist und man die Konfiguration trotzdem nachvollziehen kann.
Eigentlich war es ein ziemlich überschaubares Setup:
- 2-stöckige Geflüchtetenunterkunft mit ~50 Bewohnern
- Formals Geschäftsgebäude
- Verkabelung vorhanden
Doch nichts ist so einfach wie es aussieht:
- Maximal 16.000er DSL verfügbar
- Zugangsprobleme, da Schlüssel beim Hausmeister (Zugang nur über Auftrag beim Landratsamt)
- Dosen sind teilweise nicht mehr zugänglich (Bodentanks wurden verschlossen etc.)
- Dosen sind falsch im Gebäudeplan eingezeichnet, Plan ist insgesamt nicht mehr aktuell
- Verkabelung unbeschriftet (im „Netzwerkraum“ kommen einfach sämtliche Kabel aus der Wand)
- Sehr hohe Ansprüche der Bewohner
Das größte Problem das wir sahen: Die Bewohner. Also blieb nur richtig oder gar nicht.
Also haben wir erstmal versucht einen entsprechend breiten Anschluss zu bekommen, was schon Mal einiges an Zeit ins Land gehen hat lassen. Alles ohne Erfolg außer der Tatsache, dass wir mehrere Anschlüsse haben können: Also fiel der Entschluss auf zwei 16er-DSL-Anschlüsse, sollte ja kein Problem sein die mit Freifunk sinnvoll aufzuteilen (dazu später mehr).
Also zum Setup:
EG: 1 kleinerer Schlafraum (ca. 5 Personen) in der vorderen Hälfte, außerdem Schulungsraum und Küche, sowie Netzwerkraum; 1 großer Schlafraum (ca. 20 Personen) und Treppenhaus/Eingangsbereich in der hinteren Hälfte
OG: 1 großer Schlafraum (ca. 20 Personen) in der vorderen Hälfte; 1 kleiner Schlafraum (ca. 5 Personen), außerdem Schulungsraum, Küche und Treppenhaus in der hinteren Hälfte
Somit erschienen uns von Fläche und Nutzeraufteilung 4 Access Points am sinnvollsten.
Damit kamen wir dann auf folgende Archtektur:
Je 1 TL-WR1043 v2 als Offloader an den DSL-Anschlüssen, je 1 TL-WR841 v9/10 pro Geschoss und Hälfte.
Beim Aufbau ergaben sich bezüglich Aufteilung und Verkabelung weitere Probleme:
- Eine exakte Aufteilung war nich möglich, da man sich nach den verfügbaren Dosen richten musste. Nicht überall wo Kabel hingingen waren Dosen, nicht alle Dosen waren zugänglich
- Die als Spende erhaltenen Stecker passten nicht auf die Verlegekabel (nochmal Abbruch, einkaufen, neuer Termin mit LRA…)
Als es dann endlich alles Stand blieb die Frage: Wie die DSL-Anschlüsse aufteilen? Segmentieren? Oder mach das Batman?
Die erste Idee: Je zwei APs an jeden Offloader, da ganze trennen und aufgrund der sowieso dauerhaften Auslastung und etwa gleichhohen Nutzerzal sollte das schon passen.
Nach Rücksprache mit einem Experten aus der Community: Meshen zwischen den beiden Segmenten, die APs suchen sich dann je nach Auslastung die bessere Leitung.
Architekturplan Endergebnis:
GW
|
--------------------------
| |
Off1@DSL1 Off2@DSL2
| | | | | |
| | ----------------- | |
AP1 AP2 AP3 AP4
Danach erfolgte noch etwas WLAN Optimierung:
- Abschalten des WLANs an den Offloadern (einer hatte zuvor als Übergangslösung bis zur fertigen Verkabelung gedient)
- Abschalten des Meshings an den APs (bis auf den AP4, der Richtung Nachbarn zeigt)
- Aufteilen der Kanäle der APs auf 1, 5, 9, 13 (wobei 5 als Mesh-Kanal natürlich an dem AP mit aktiven WLAN-Mesh blieb)
Also die Konfiguration:
- der Offloader
- Mesh-VPN auf WAN-Interface
- LAN-Mesh auf LAN-Ports
- WLAN aus
- Autoupdate aus
- der APs
- WAN-Mesh auf WAN-Interface
- Client-Netz auf LAN-Ports
- WLAN-Mesh aus (bis auf einen)
- Aufteilung auf verschiedene Kanäle
Nachdem das alles schön funktionierte kam die erste Ernüchterung: Es ist langsam. Ja, es sind 30 gleichzeitige Nutzer - aber die sind nur auf einer Leitung. Denn alle 4 APs wechseln gleichzeitig zwischen den beiden Offloadern hin- und her, statt primär „ihren“ zu benutzen und nur bei schlechter Leitung/hoher Auslastung auf den anderen zu gehen.
Es schien als würden sich immer alle gleichzeitig für die bessere (freie) Leitung entscheiden, um dann aufgrund der nun folgenden Auslastung sofort wieder auf die andere (jetzt leere und somit bessere) Leitung zu springen.
Nach etwas Googeln fand ich in einem Foren-Beitrag (Gibt es im Mesh ein Loadbalancing? - #18 von adorfer) die entscheidende Aussage zum beobachteten Phänomen:
Die ausgelastete Bandbreite ist Batman völlig egal, es nimmt immer die beste Verbindung - also den DSL-Anschluss, der gerade frei ist.
Nun bleibt die Frage: Was macht man mit der Verbindung zwischen den Routern? Segmente trennen? Oder gibt es eine passende Einstellung? Das hat nochmal gut Zeit gekostet…
Nach dem Testen diverser Optionen (gw_mode, Hop Penalty etc.) die riesige Erkenntnis: Aufgrund des Switches vor dem Offloader (was anderes sind die integrierten Switche der Plastikrouter wie allgemein bekannt ja nicht), sind die beiden Offloader für alle APs absolut identsich, da der Traffic ja nicht über das Batman Interface läuft. Manchmal steht man halt etwas auf der Leitung…
Also gibt es seitens der APs nichts, das man optimieren kann.
Daher musste dafür gesorgt werden, dass es für die APs einen Unterschied macht, welchen Offloader sie nehmen. Also muss der Traffic zwischen den Offloadern an den Offloadern über das bat0 laufen, um dadurch einen weiteren Hop zu erzeugen. Somit ist das Gateway für den AP vom eigenen Offloader aus näher, als vom anderen - zumindest virtuell.
Virtuell trifft es ganz gut, das ergab nämlich folgende Netzwerk-Konfiguration (/etc/config/network) mit einem weiteren VLAN (Kommentare gehören natürlich nicht dazu):
# Switch anpassen: Port 1 (intern Port 4, siehe https://wiki.openwrt.org/_detail/media/tplink/tl-wr1043/tl-wr1043nd-v2_schematics.png?id=toh%3Atp-link%3Atl-wr1043nd) mit Verbindung zum anderen Offloader aus der Config vom VLAN 1 raus, Port 0 (der Router selbst, also unser batman-Interface) mit Tag (t) an den Paketen damit klar ist von wo sie kommen
config switch_vlan
option device 'switch0'
option vlan '1'
option ports '0t 2 3 4'
# Switch anpassen: Neuer Abschnitt fürs neue VLAN dazu (VLAN 3, da VLAN 1 unsere restlichen LAN-Ports sind und VLAN 2 die WAN-Ports); 0 muss als quasi Batman-Port wieder dazu - wieder mit Tag damit auch hier klar ist wo die Pakete herkommen
config switch_vlan
option device 'switch0'
option vlan '3'
option ports '0t 1'
# LAN-Mesh anpassen: Wegen dem zweiten VLAN auf dem gleichen Interface (Port 0 = eth1), hat eth1 jetzt zwei Subinterfaces mit der Nummer des VLANs. Also müssen wir alle Erwähnungen von eth1 durch das richtige Interface ersetzten, sonst funktioniert es nicht mehr. Hier wird ifname auf das Interface der restlichen LAN-Ports gesetzt
config interface 'mesh_lan'
option macaddr '32:b6:c3:bd:72:f2'
option mesh 'bat0'
option proto 'batadv'
option auto '1'
option ifname 'eth1.1'
# Neues Mesh Interface anlegen: Jetzt kommt ein neus virtuelles Interface dazu, damit unser vorher angelegtes VLAN mit seinen Ports auch separat an das bat0 angebunden ist. Die MAC-Adresse und der Name kann beliebig gewählt werden.
config interface 'mesh_offloader'
option macaddr 'af:fe:c3:bd:72:f2'
option mesh 'bat0'
option proto 'batadv'
option auto '1'
option ifname 'eth1.3'
Nach dem Anpassen einfach ein „/etc/init.d/network reload“ ausführen. Aber Vorsicht: Sollte etwas falsch sein ist der Router eventuell nicht mehr erreichbar (was blöd wäre, wenn man z. B. erst den Zuständigen beim Landratsamt erreichen muss um an die Hardware zu kommen).
Mit dieser Konfiguration laufen alle Pakete, die von APs des einen Offloaders zu einem AP des anderen Offloaders, oder zum anderen Offloader, sollen über das Batman Interface statt einfach über den Switch.
Dies bedeutet: Normalerweise nehmen APs den Offloader an dem sie hängen um zum Gateway zu kommen. Sollte diese Verbindung nicht verfügbar sein, verbinden sie sich über den anderen Offloader.
Damit haben wir ein „Loadsharing“ erreicht indem die APs händisch auf die beiden DSL-Anschlüsse aufgeteilt haben, aber es fällt kein AP aus nur weil ein Anschluss nicht verfügbar ist. Zudem ist es hausintern möglich Daten mit voller Geschwindigkeit auszutauschen.
Verbliebene Probleme:
- Die Dose eines APs hat einen Wackelkontakt und sorgt für Verbindungsprobleme (SSID bleibt bei Freifunk, somit großer Unmut bei Ausfall), er wird daher abgebaut → Anschlussaufteilung geht nicht mehr so schön auf
- Die Ansprüche der Gelüchteten sind immer noch viel zu hoch und es ist ihnen trotz problemloser Funktion selbst beim Abspielen von YouTube etc. zu langsam
- Das Netz der genutzten Community ist leider etwas langsam, daher kommen an den Offloadern schon nicht mehr als 10 Mbit/s durch
Was die Finanzierung angeht, so wurde die Hardware aus Spenden beschafft, die Gebühren für die Anschlüsse tragen die Geflüchteten selbst (macht pro Person ~1 €/Monat, das hat jeder mehr als locker übrig).
Ich denke ich muss da morgen nochmal drüber lesen, aber das sollte es soweit gewesen sein. Ich hoffe einigermaßen verständlich und doch für jemanden hilfreich.
Über Anmerkungen würde ich mich freuen 
Eventuell folgen auch noch ein paar Bilder…
An der Stelle noch vielen Dank nach Darmstadt für die Unterstützung, obwohl es nicht euer Projekt war! 
Viele Grüße
DontSwitch
Paar Schlagworte für die Suche:
Loadbalancing, Loadsharing, Lastverteilung, Splitting, Segmentierung, Mesh on LAN, Mesh on WAN