--- format: markdown ... # Fragen (und ggf. Antworten) zum Thema Routing Fragen als Überschriften, (evtl.) Antworten als Text. OK? ## [B.A.T.M.A.N.](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 ~~~ ### 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: 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: . ## 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](https://github.com/freifunk-gluon/gluon) 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 im Ruhrgebiet;). 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. ### 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 #### AHCP? #### FF-Eigenbaulösung? "Nodes machen selbst DHCP-Server, die Ranges werden über ein [neues Protokoll](https://gist.github.com/tcatm/2dd0e6699f2a153505d0) von den Supernodes ausgegeben." (Mail vom 9.5.2015)