Fragen (und ggf. Antworten) zum Thema Routing

Fragen als Überschriften, (evtl.) Antworten als Text. OK?

B.A.T.M.A.N. - Routing auf layer 2

Wie ist das (quantitative) Verhältnis zwischen normalen broadcasts (zB ARP) und B.A.T.M.A.N. management traffic?

Die folgende B.A.T.M.A.N. Paketzählung legt nahe, dass der Management Traffic alles andere (deutlich) übersteigt:

root@FF-DO-...:~# uptime
 18:59:16 up 28 days,  2:01,  load average: 1.51, 1.96, 2.25
root@FF-DO-...:~# batctl -v
batctl 2013.4.0 [batman-adv: 2013.4.0]
root@FF-DO-...:~# batctl statistics
	tx: 2403518
	tx_bytes: 565704189
	tx_dropped: 44502
	rx: 441821427
	rx_bytes: 37309865542
	forward: 3814047
	forward_bytes: 1308685837
	mgmt_tx: 105098647
	mgmt_tx_bytes: 43865261581
	mgmt_rx: 227260596
	mgmt_rx_bytes: 58887801562
	tt_request_tx: 835434
	tt_request_rx: 874689
	tt_response_tx: 458985
	tt_response_rx: 609431
	tt_roam_adv_tx: 1625
	tt_roam_adv_rx: 2473
	dat_get_tx: 23945
	dat_get_rx: 86964
	dat_put_tx: 4224
	dat_put_rx: 2798
	dat_cached_reply_tx: 98186

Es gibt Vortragsfolien (1.3 MiB) vom September 2013, in denen das “Rauschen” und die Skalierungsprobleme von B.A.T.M.A.N. dargestellt werden (mit bunten Torten!-), incl. der damaligen und geplanten Gegenmaßnahmen. (Gefunden in einem Thread zu Thema “Rauschen” vom Dezember 2014: 150 kbit/s Hintergrund-Traffic!?.)

Um den B.A.T.M.A.N. management traffic zu segmentieren, braucht man verschiedene B.A.T.M.A.N. Instanzen. Richtig?

Man kann nur eine B.A.T.M.A.N. Instanz pro kernel/VM fahren. Richtig?

Falsch:-) “As of 2010.2.0 it is possible to let a single mesh node participate in mutliple mesh clouds at the same time which makes it necessary to assign interfaces to individual mesh clouds and having multiple batX interfaces.”

Siehe: http://www.open-mesh.org/projects/batman-adv/wiki/Tweaking

Daraus folgt: Entkoppelung des Management traffics könnte auch ohne externe bridge (ohne BLA), d.h. innerhalb eines Knotens möglich sein.

Können verschiedene B.A.T.M.A.N. Instanzen eine gemeinsame Broadcastdomäne bilden?

Man kann verschiedene B.A.T.M.A.N. Instanzen über eine (VMWare-)Bridge (ggf. dank BLA;) so koppeln, dass sie eine gemeinsame Broadcastdomäne bilden, aber ihr management traffic getrennt bleibt. Richtig?

Was ist BLA?

Bridge loop avoidance: http://www.open-mesh.org/projects/batman-adv/wiki/Bridge-loop-avoidance.

Routing auf layer 3 statt (ausschließlich) auf layer 2

Wurde eine Lösung mit layer 3 Routing schon diskutiert?

Wenn ja: Warum wurde sie nicht umgesetzt? Wo ist sie dokumentiert?

Wenn nein: Warum wurde sie nicht diskutiert?-)

“Eine neue, in Entwicklung befindliche Gluon-Version baut auf eine geänderte Netzwerkstruktur. Im VPN soll von Layer 2 auf Layer 3 umgestellt werden, so dass die vorhandenen Skalierungsprobleme verschwinden.” (Mail vom 9.5.2015)

“Gluon findet ihr unter https://github.com/freifunk-gluon/gluon, die haben eine Doku und eine Mailingliste, ich glaube das ist der richtige Ort um die Entwicklung zu verfolgen.” (Mail vom 15.5.2015)

Dort heißt es: “To subscribe to the list, send a message to: gluon-subscribe|ät|luebeck.freifunk.net”. Ist jemand auf dieser Mailingliste drauf? Bitte melden!-)

Ist eine Möglichkeit bekannt, Routinginformationen zwischen einem layer 2 Routingprotokoll (B.A.T.M.A.N.) und einem layer 3 Routingdaemon (bird, quagga, babeld) auszutauschen?

Gibt es Erfahrungen, ob B.A.T.M.A.N. mit layer 3 Routingdaemons friedlich koexistieren kann?

Aussführlicher formuliert: Routingdaemons können ein B.A.T.M.A.N. interface einfach als einen layer 2 sehen, über den sie dann layer 3 Routing machen. Aber läuft das “friedlich” ab? D.h. sind die Routingentscheidungen (hinreichend) konsistent zwischen layer 2 und 3?

Fragen zum Roaming

Welche Möglichkeiten gibt es für den Zusammenhang von Roaming und Routing?

Zur Zeit ist Roamingbereich = Broadcastdomäne (= der größte Switch in Dortmund;). Können andere (ggf. kleinere) Roamingbereiche das Routing erleichtern und/oder das Rauschen reduzieren? ZB wenn Roaming nur noch innerhalb eines WLAN meshes möglich ist.

Wenn Gluon auf layer 3 Routing umstellt, kann DHCP nicht mehr wie beim bisherigen broadcast Netz (mit B.A.T.M.A.N.s layer 2 Routing) direkt von zentralen DHCP Servern kommen. Prinzipiell ist Roaming aber auch in jedem Netz mit dynamischem layer 3 Routing möglich, nämlich durch host routes.

Roaming und DHCP - wo befindet sich der zuständige DHCP Server?

Geht das auch dann zentral, wenn der DHCP Server nicht Teil der Broadcastdomäne ist?

DHCP relay, s. zB http://de.wikipedia.org/wiki/DHCP#DHCP_f.C3.BCr_mehrere_Subnetze.

AHCP?

Ad-Hoc Configuration Protocol. Ersetzt router discovery und DHCP in ad-hoc Netzen mit layer 3 Routing (zB OLSR, Babel). S. http://www.pps.univ-paris-diderot.fr/~jch/software/ahcp/.

“Verteiltes DHCP im Mesh”?

Eigenentwicklung (tcatm) für ein distributed DHCP. README https://gist.github.com/tcatm/2dd0e6699f2a153505d0#file-ddhcpd-md, Python Quelltext https://github.com/tcatm/pyddhcpd.

“Nodes machen selbst DHCP-Server, die Ranges werden über ein neues Protokoll von den Supernodes ausgegeben.” (Mail vom 9.5.2015)

“Ich (bzw. auch einige Gluonentwickler und Nutzer) wollen DHCP nicht auf wenige Server zentralisieren sondern die IPs direkt von den Knoten an die Clients vergeben lassen. Dazu ist es nötig, ein IPv4 Subnetz auf die Knoten aufzuteilen, damit es keine Konflikte gibt. pyddhcpd ist der Proof-of-Concept für ein in den letzten zwei Jahren erarbeitetes Konzept. Sobald der gut läuft, wird ein dazu kompatibler Server in C geschrieben, der dann auf den Knoten selber laufen kann. Das Projekt ist völlig unabhängig von Gluon und kann (hoffentlich!) auch in OLSR Netzen sinnvoll eingesetzt werden.” (tcatm auf https://forum.freifunk.net/t/experimenteller-server-fuer-verteiltes-dhcp/5426/67)

Verteiltes DHCP durch Routing?

Es folgt ein (minimalistischer) Vorschlag für verteiltes DHCP. Im Gegensatz zu AHCP und pyddhcpd kommt er ohne zusätzliches Protokoll aus. In Netzen mit dynamischem Routing gibt es einen Mechanismus, der Informationen liefert, die ein verteiltes DHCP braucht. Dieser Mechanismus ist das dynamische Routing selbst. Erhältlich in allen Freifunk-Netzen:-)

In Freifunk-Netzen mit Meshroutern und mobilen WLAN clients werden host routes verwendet, weil angesichts der möglichen Topologieänderungen eines Mesh+mobil-Netzes jedes Gerät als einzelnes seine Erreichbarkeit verändern kann. Das ist anders als bei Kabelnetzen, in denen sich (normalerweise;) nicht ständig die Kabel verlegen und damit die Topologie ändern. Daher werden üblicherweise bei Internet-Technologie ganze Subnetze (die jeweils 2ⁿ host Adressen zusammenfassen) geroutet, um das Routing von topologisch irrelevanten Informationen über einzelne hosts zu entlasten. Die hosts eines Subnetzes unterscheiden sich dabei (von außerhalb ihres Subnetzes betrachtet) nicht hinsichtlich ihrer Erreichbarkeit.

Wenn nun in einem typischen FF-Netz ohnehin host routes zu den clients kursieren, dann kann jeder teilnehmende Router sehen, welche IP-Adressen in diesem FF-Netz aktuell verwendet werden. Diese triviale Feststellung ist bereits die halbe Miete für ein verteiltes DHCP! Denn das Kerngeschäft von DHCP ist die Zuteilung einer ansonsten ungenutzten IP-Adresse an einen neuen client zu dessen exklusiver Nutzung. (Würde eine IP-Adresse an mehr als einer Stelle in einem internet genutzt, wäre sie praktisch nutzlos.) Die andere Hälfte der Miete besteht darin, jede von einem DHCP-Server zugeteilte IP-Adresse im Routing des FF-Netzes bekannt zu machen, um sie damit für alle anderen DHCP-Server im Netz als “nicht mehr zuteilbar” zu markieren.

Der triviale (und daher vmtl. unwiderstehliche) Charme dieser Idee besteht darin, dass man zu ihrer Realisierung nur zwei sowieso vorhandene Zutaten eines FF-Netzes in jedem teilnehmenden Access-Router zusammenkleben muss: Routingdaemon und DHCP-Server.

Wir gehen von einem funktionierenden Routing (von host routes) und funktionierenden DHCP Servern (auf den Access-Routern, insb. WLAN APs) aus. Dann besteht die noch verbleibende Aufgabe einer Implementierung darin, die Gültigkeit der folgenden Entsprechung für die per verteiltem DHCP zuteilbaren IP-Adressen zu gewährleisten:

1 DHCP lease ~ 1 host route

Praktisch bedeutet das:

1. Ein DHCP Server wird so gesteuert, dass er eine IP-Adresse nur dann vergibt, wenn es aktuell keine host route für sie gibt.
2. Sobald ein DHCP Server eine (freie) IP-Adresse an einen neuen client vergibt, setzt er eine lokale host route für diese IP, die vom Routingdaemon verbreitet wird.
3. Bei Ablauf einer DHCP lease (release oder expiry) löscht er die entsprechende host route, was via Routingdaemon zur “Freigabe” der IP-Adresse für die anderen teilnehmenden DHCP Server führt.

Um auch mit Partitionierungen des Netzes umgehen zu können, braucht man noch eine Konfliktbehandlungsmethode wie zB die Folgende:

4. Erhält der Router über das Routingprotokoll eine host route, die bereits lokal für einen lokalen DHCP client gesetzt ist, führt das zum Nicht-Verlängern der lokalen lease und Löschen der lokalen host route. Wenn es eindeutige Router-IDs gibt (und das sollte es:), können diese zum Vergleich konkurrierender host routes verwendet werden: die host route, die vom Router mit der niedrigeren Router-ID announced wird, bleibt. D.h. nur der Router mit der höheren Router-ID löscht lokale lease und host route. Immerhin einer der clients mit der (während der Partitionierung) mehrfach zugeteilten IP-Adresse kann diese Adresse behalten und sie funktioniert dank der Löschungen auf den anderen Routern auch weiterhin.

Verteiltes DHCP mit Roaming?

Für das Roaming von DHCP clients (Wechsel des AP = Router = DHCP Server) kann das (layer 3!) Routing alleine allerdings nicht genug Information bereitstellen - es fehlt vor allem die MAC Adresse des clients. Diese müsste ein DHCP Server, zu dem der client roamt, aber wissen, um dem client gleich eine lease mit dessen aktuell gültiger IP zuteilen zu können. Wenn die verwendete DHCP-Serversoftware Fernsteuerung unterstützt, kann das Roaming von DHCP clients zB so ermöglicht werden:

5. Sobald ein DHCP Server lokal eine lease zuteilt, trägt er diese auch bei anderen DHCP-Servern per Fernsteuerung ein. Entsprechend bei Erlöschen einer lease.

Dabei ist es nicht nötig, dass dieser DHCP-Server alle anderen DHCP-Server des Netzes informiert, sondern nur diejenigen, zu denen ein client tatsächlich innerhalb der lease time roamen kann, also vmtl. ein paar hundert Meter im realweltlichen Umkreis dieses DHCP-Servers.

Eine Fernsteuerung gibt es zB beim ISC dhcpd, der ja auch schon auf den Supernodes des FF-DO genutzt wird. Die zuständige utility nennt sich omshell (om = object management) und baut TCP-Verbindungen zum lokalen oder zu entfernten ISC dhcpd Prozessen auf. Apropos Supernodes: laut hiesiger Supernode-Doku sind die 4 DHCP-Server jeweils eigenständig und haben verschiedene IPv4-Adressbereiche für die clients. Mit einer Implementierung des Konzepts “Verteiltes DHCP mit Roaming” könnten sie alle den gleichen Adressbereich vergeben. Dadurch könnten einzelne Supernodeausfälle und Tunnelwechsel im upstream des clients für diesen transparent sein, d.h. nicht zum Wechsel seiner IP-Adresse führen. Der ISC dhcpd beherrscht einen failover Betrieb, mit dem sich zwei DHCP-Server einen Adressbereich teilen (und redundant operieren) können. Die oben dargestellte Methode funktioniert aber auch für n DHCP-Server, mit n > 2. Von daher könnte sie sogar schon in der eher “zentralistischen” Supernode-Architektur nützlich sein, da dann alle 4 DHCP-Server in einer einfachen Art von failover Betrieb laufen würden. ZZ wäre der “Routing-Partner” der DHCP-Server noch ein B.A.T.M.A.N., dem man die host routes der DHCP clients verklickern bzw. entnehmen müsste. Weil B.A.T.M.A.N. auf layer 2 operiert, taugt er dazu erstmal nicht auf den ersten Blick, doch dafür kennt er die MAC Adressen aller clients;-)