Berlin ist gerade dabei auf Distance-Vector mit babel umzusteigen. Aber eher auch gezwungen durch mangel an alternativen.
Irgendwie wäre ich eher an Link-State Algorithmen interessiert. Ich würde am liebsten OLSRv2 benutzen, welches wir aber einfach nicht vernünftig zum laufen bekommen.
Ich hab auch schonmal an OSPF gedacht.
Was ist so eure Meinung?
awlnx
14. April 2021 um 07:26
2
Was ist das Ziel? Was soll gebaut werden? Pauschal kann man das schlecht sagen :).
1 „Gefällt mir“
wusel
14. April 2021 um 11:59
3
libremesh.org nutzt für L3 bmx6 bzw. bmx7. Für Wireless ist IMO Link-Qualität relevanter als die Entfernung; Link-Kapazität kann AFAIK keines der Protokolle automagisch hinzunehmen.
Kurzum: für v4+v6 sehe ich im Wireless-Mesh z. Zt. keine Alternative zu Batman, ab Wired dann OSPF & BGP.
1 „Gefällt mir“
also das Libremesh mit bmx7 routet nach Link-Kapazität. Nachteil ist schon wieder, zumindest mit ath9k funktioniert das, bei ath10k fehlen leider einige rx/tx-Angaben im wlan-teil.
hier ein Beispiel mit zwei wlan- und einem lan-link:
INTERFACES:
dev state linkKey linkKeys type channel rateMax idx localIp rts helloSqn rxBpP txBpP
br-lan UP DH2048M112 RSA896,DH2048M112 ethernet 0 1000M 1 fe80::618:d6ff:fe53:6e37/64 6 54415 308/1.4 383/1.9
wlan0-mesh_13 UP DH2048M112 RSA896,DH2048M112 wireless 153 56000K 2 fe80::618:d6ff:fe52:6e37/64 17 15872 670/2.4 577/2.4
LINKS:
shortId name linkKey linkKeys nbLocalIp dev rts rq tq txRate wTxRate wTxRateEff wTxThr wTxThrEff mcs sgi chw wSnr
5A17D0B5 dieze-klo5ghz DH2048M112 RSA896,DH2048M112 fe80::26a4:3cff:fe6c:eac9 wlan0-mesh_13 4 35 87 2495K 30000K 2495K 15937K 2152K 1 1 40 19
13468A6C kh-setra-5ghz DH2048M112 RSA896,DH2048M112 fe80::618:d6ff:fe5e:d453 wlan0-mesh_13 13 97 100 119M 300M 119M 59437K 41924K 15 1 40 44
98A57BA4 mr-loco-nord DH2048M112 RSA896,DH2048M112 fe80::26a4:3cff:fe45:c7ff br-lan 6 100 100 1000M -1 -1 -1 -1 0 0 20 0
root@mr-loco-sued:~# iw dev wlan0-mesh station dump | grep hrou
expected throughput: 15.563Mbps
expected throughput: 58.43Mbps
3 „Gefällt mir“
Naja ein dezentrales Layer 3 Mesh-Netzwerk mit ca 700 Nodes, wo alle mindestens Dual-Homed angeschlossen sind.
awlnx
14. April 2021 um 16:58
6
Ok, das sind doch schonmal Anforderungen ;). Wir planen gerade auch einen Umbruch von FFMUC:
opened 04:54PM - 06 Apr 21 UTC
This is a draft idea how we could switch FFMUC to a routed approach without losi… ng functionality of B.A.T.M.A.N. for local meshes.
### Problem statement
We want to switch Freifunk Munich to a routed approach towards the gateways, because large layer2 domains pose too many problems. Also we want to get rid of the overhead of VXLAN and B.A.T.M.A.N. towards the gateways.
### Idea
- Use wireguard to connect to the Freifunk Munich gateways
- Inside wireguard use a calculated link-local address which is derived from the public key
- #### v6
- Run radvd on nodes which have an established wireguard tunnel to announce the v6 /64 inside the local network
- the local /64 is assigned via wgkex
- Default route via the wireguard tunnel
- #### v4
- Use a fixed /20 per segment and set the next-hop to the v6 address of the gateway, also NAT on the node itself.
- The node runs DHCP thus it becomes the default gateway for the local network. Also set B.A.T.M.A.N. GW Mode to server.
- We need a transfer network between gateway and node
- #### Meshing
- The node runs B.A.T.M.A.N. for local meshing just the same as on "normal" Gluon
- #### Why not babel?
- We want to stay compatible to old nodes, which can just mesh like before.
- A routing protocol is not needed in this approach, thus we avoid another failure domain.
### What needs to be done?
- Test setup with that approach (two raspberry PIs or smth)
- Changes to gluon (dhcp-server, radvd, nat)
- wgkex needs to get a backend database from which transfer v4 addresses are picked
- wgkex also needs to have an database for v6 /64
### Possible issues
- Kernel of OpenWRT is too old and doesn't support v6 next-hops for v4
- Meshing freaks out
- IP address conflicts while roaming
### Known Issues
- No IPv4 Connectivity between clients which are not in the same local mesh
- Potential IPv4 collisions in spontaneous meshes
### Glossar
- Nodes => Freifunk Router
- Gateway => Supernode
### Discussion
https://chat.ffmuc.net/freifunk/channels/firmware
Comments welcome! 🚀
Was wirklich besser ist muss man halt an Hand der Anforderungen raussuchen, wieviele Routen, wieviele Nodes, Roaming etc?
1 „Gefällt mir“
Naja möglichst rieeeesig.
Vielleicht sollten wir mal anfangen so nen neues Routing Protokoll zu schreiben, was diesen ganzen neue Sachen benutzt, wie Virtuelle Coordinaten, das dann eher Greedy routed und alles.
Hab jetzt auch nochmal bisschen diskutiert mit einem anderen Freifunker, und vll wären auch einfach Reaktive-Protokolle mal ganz interessant zu benutzen.