Das Dokument behandelt den Aufbau und die Automatisierung von Freifunk-Netzen unter Verwendung von Open-Source-Komponenten, einschließlich des b.a.t.m.a.n. Routingprotokolls und der Implementierung von VXLAN für Layer-2 Overlays. Es beleuchtet die Herausforderungen der Skalierung von Mesh-Netzen, die Automatisierung von Gateway-Konfigurationen mit Salt Stack und die Nutzung von VRFs zur effizienten Trennung von Netzwerken. Abschließend werden Erfahrungen und Erkenntnisse aus der praktischen Umsetzung der genannten Technologien geteilt.

1. Salt-Orchestrated Software
Defined (Freifunk) Networks
Service-Provider-Style-Netze aus
Open-Sourcen-Komponenten bauen
Maximilian Wilhelm (@BarbarossaTM)
Freifunk Hochstift (@ffhochstift,
@ffho_noc)

2. 2
Wer bin ich?
● Maximilian Wilhelm
– @BarbarossaTM
– @ffho_noc
● Senior Infrastructure Architect, Uni Paderborn
● Vorstand Freifunk Hochstift e.V.
● Linuxer
● Netzwerker
● OpenSource Hacker

3. 3
Agenda
● Hintergrund
● Fails
● Automatisierung
– Ausfallsichere Services
– Elegantes und sicheres
Routing (VRFs)
● Layer2-Overlay (VXLAN)
● Lessons Learned

4. 4
Background: Freifunk Hochstift
● Gegründet als Freifunk Paderborn (12/2013)
● Schnell stark gewachsen dank viel
Unterstützung
– Bäcker
– Werbegemeinschaft Paderborn
– Land NRW
– Seit 2016 auch Stadt + Kreis Paderborn
● Expandiert zum Freifunk Hochstift (09/2015)
● ~900 Knoten, ≥1.500 Clients

5. 5
Dieses Freifunk
Fokus heute

6. 6
Exkurs: B.A.T.M.A.N. adv.
● Better Approach To Mobile Adhoc Networking
● Routingprotokoll für Mesh-Netze
● Layer2-Overlay über Layer2-Netz
– Enkapsuliert Ethernet-Frames in Ethernet
● Klassischerweise: BATMAN über
– Fastd (L2-VPN)
– Richtfunk
– Ad-Hoc WLAN
– LAN

7. 7
B.A.T.M.A.N. im Freifunk-Netz
● Historisch: eine große L2-Domain
– Skaliert nicht
– ≥100kb/s Grundrauschen (ARP, ND, DHCP, RA, ...)
➔ Mittlerweile 10 kleinere L2-Domains
● Pro L2-Domain
– ein IPv4 + IPv6 Prefix
– Full-Mesh zwischen allen Gateways nötig
● Jedes B.A.T.M.A.N. Gateway ist DHCP-Server
– Pro Gateway ein “Sub-Prefix” als DHCP-Pool

8. 8
Wir waren jung und naiv...

9. 9
Tinc for the win (damals™)

10. 10
Tinc
● “Viele Point-to-point
Tunnel sind kompliziert.”
● “Ein großes Layer2-Netz
ist easy. Da drüber kann
man auch OSPF fahren.”
● “Mit zwei VPN-Servern
haben wir auch gleich
Redundanz.”
● Don't try this at home.
Srsly.

11. 11
Heimnetz-Freifunk-Bridge / BCP38
● Fritz!Box Prefixe im Freifunk-Netz
● Firmennetz im Freifunk-Netz
➔ Prefixfilter für Freifunk-Prefix auf Knoten
entfernt 30% Grundrauschen
https://github.com/FreifunkHochstift/ffho-
packages/tree/master/ffho/ffho-ebtables-net-rules

12. 12
I can haz PoE switch for AF-5X?
Nicht von UBNT. Netonix to the rescue!

13. 13
AirFiber 5X
● Beware of Wetterradar (5,6GHz Band)
● Störungen in anderen Bändern (5,5 vs.
5,8GHz)
● Störungen auf parallel laufenden Kabeln?
● Weniger Durchsatz als PBE-5AC-500
● Montagsmodelle?

14. 14
B.A.T.M.A.N. auf EdgeRoutern
● EdgeRouter sind billig (wir hatten kein Geld)
– Wäre cool, wenn die auch BATMAN sprächen..
➔ https://git.c3pb.de/freifunk-pb/edgerouter
● <Rant>
● Nice try, aber
– Nicht update-safe
– Explodiert auf andere Modellen und Versionen
– Performance eher so mittel, da kein Offloading
und keine ernstzunehmende CPU

15. 15
EdgeRouter überhaupt
● Viel Hass
● OpenVPN mit eigenem config-file
– Geht, aber
– Restart nicht deterministisch möglich
– Nach brute-force-restart kein OSPF mehr
● Quagga.
● “Reboot fixed the issue.”
● Alles doof.
● </Rant>

16. 16
Wireless Backbone (alt)

17. 17
BATMAN Layer2 skaliert nicht
● Ein BATMAN Mesh mit 1k Knoten dreht nicht
● Ergo kleinere “Sites” bauen
– Legacy + 9 neue (City, PB N, O, S, W, …)
– Technically 26 “Regionen”
● Aber:
– Ein Vlan pro Site und RF-Strecke?
– Plus Vlan für IP?

18. 18
Erkenntnisse
● Teuer nicht unbedingt besser
● $Linux-Appliance als BATMAN Hop (APU2)
● BCP38 hilft
● Point-To-Point Links (VPNs) bauen
● #routingrocks
● BATMAN-L2-Kopplung per Vlans anstrengend
● Infrastruktur-Manufaktur skaliert nicht
● Bitte kaufen Sie Automatisierung

19. 19
Recap
✔ Erledigt
✔ Fails
● Next up
– Automatisierung
– Geroutete Infrastruktur
– Ausfallsichere Services
– Elegantes und sicheres Routing
– B.A.T.M.A.N.-Overlays
– Lessons Learned

20. 20
Automatisierungsstufen
● Gateway #1 Handgeklöppelt
● Gateway #2 per setup.sh Basiskonfiguriert
● Gateway #3-6 per setup.sh initial Vollkonfiguriert
● Aber Changes?
– Manuell überall anders
● Skaliert nicht

21. 21
Salt Stack
● Continuous Management gewollt
– Pakete installieren
– Configs anpassen
– Dienste/Units starten
– Netzwerk konfigurieren
– Zertifikate verteilen
– ...
● 1. Ansatz hat ~1 Jahr gehalten
● Mittlerweile fast einmal alles neu gebaut

22. 22
Automatisierung

23. 23
States
● Repräsentiert Status den $etwas haben soll
● YAML-Format
● Sammlung von Definitionen für
– (De)Installierte Pakete
– (De)aktivierte Services
– Dateiinhalte
– User
– …
● Abhängigkeiten modellierbar

24. 24
Pillar
● Strukturierter Key-Value-Store
● YAML-Format
● Erlaubt Filterung wer was lesen darf
● Daten in Templates auslesbar
● Prädestiniert für
– Keys
– Host-spezifische Konfigurationen

25. 25
Pillar Example
bbr­vega.in.ffho.net:
id: 198
sysLocation: Vega
roles:
­ router
­ batman
­ bbr
sites:
­ pad­cty
Quelle für Loopback-IP
Bird-Config generieren
Quelle für Loopback-IP
Batman-Interfaces generieren
Batman-Instanzen

26. 26
Pillar Example contd.
ifaces:
bond0:
bond­slaves: "eth0 eth1 eth2"
vlan1002:
desc: "<­> gw04"
vlan­raw­device: bond0
prefixes:
­ 10.132.253.58/31
­ 2a03:2260:2342:fe1c::1/126
batman_connect_sites: pad­cty
[...] #

27. 27
The SDN part
#SDN
Disclaimer: Schriftart auf besonderen Wunsch von AbraXXL

28. 28
SDN für Linux (Debian)?
● Klassisches ifupdown nur mäßig automatisierbar
● /etc/network/interfaces generieren einfach
● Aber wie neu laden?
– »service networking restart« disruptive
– Kein Tool für “neu laden” vorhanden
– Untrivial zu bauen
● CumulusNetworks Ifupdown2
– Rewrite von ifupdown in Python
– https://github.com/CumulusNetworks/ifupdown2

29. 29
ifupdown2
● Leider keine Featureparität mit ifupdown
● Kann von Hause aus
– Dependency Resolution
– ifreload
– VLAN-Aware-Bridges
– VRFs
– VXLAN
● Kann (noch) nicht:
– ppp

30. 30
Ifupdown2 Patches
● Dank Python leicht erweiterbar
● Upstream kommunikativ
● Kann mittlerweile
– B.A.T.M.A.N. Interfaces
– Tunnel (GRE, SIT, IPIP)
● Offene Pull-Requests für
– Filter für Bridge-Interfaces
– Phys-dev für VXLAN
– Pointopoint-Bugfix

31. 31
Automatisierung mit SaltStack
● Node-Informationen in »pillar«
– Strukturierter Key-Value-Store in YAML-Syntax
● Eigene Python Module für “SDN” und mehr
● Daraus generiert:
– /etc/network/interfaces
– Bird-Config (OSPF, iBGP, eBGP)
– OpenVPN
– DHCPd
https://github.com/FreifunkHochstift/ffho­salt­public

32. 32
Netzwerk-Setup heute
● Alle Systeme per DualStack verbunden
● PTP-Verbindungen
– VLANs
● Zwischen zwei Geräten in einem POP
● über Richtfunkstrecken
APU1 Switch1 RF1 ↔ ↔ ↔
RF2 Switch2 APU2↔ ↔
– OpenVPN Tunnel
● An größeren POPs ein L2-Netz (/28 + /64)
● Dynamisches Routing mit Bird

33. 33
#Routing #OSPF #BGP #Bird
● Dynamisches Routing mit Bird
– OSPF
● Loopback-Reachability
● Propagation von Mgmt-Netzen der POPs
– iBGP mit 3 Core-Routern (RRs)
● Default-Route (kommt per eBGP)
● Announcement von Client-Netzen
● Announcement von (Anycasted) Service-IPs
● Traffic Engineering
https://github.com/FreifunkHochstift/ffho­salt­public/tree/master/bird

34. 34
Recap
✔ Erledigt
✔ Fails
✔ Automatisierung
✔ Geroutete Infrastruktur
● Next up
– Ausfallsichere Services
– Elegantes und sicheres Routing
– B.A.T.M.A.N.-Overlays
– Lessons Learned

35. 35
Exkurs: Anycast
● Idee: Service-Prefix mehrfach announcen
● Client verbindet immer zu nahem Server
– Nähe aus Sicht des Routings!
● Realisierung: anycast-healthchecker + bird
– Service-Prefix nur announcen, wenn Dienst OK
– Obacht: Flow-Based ECMP nutzen (ab Kernel 4.4)
● Fällt ein Server aus, “Umleitung” zum nächsten
https://github.com/unixsurfer/anycast_healthchecker
https://github.com/FreifunkHochstift/ffho­salt­
public/blob/master/bird/ff­policy.conf

36. 36
Exkurs: Traffic Engineering
● Steuerung von Traffic-Flows
– Ingress-Traffic steuern
– Kürzeste Weg zu Batman-Gateway-Prefixen
➔ Ost-West-Traffic vermeiden
● Lösung:
– More-Specific Routen von/zu gewünschtem Ziel
– Mit spezieller BGP-Community gekennzeichnet

37. 37
VRFs
● Virtual Routing and Forwarding
● Unabhängige Routinginstanzen
– Layer3 Separation
– Strikte Trennung von Netzen
– Überlappende Prefixe möglich
● L3-VPNs
– Üblicherweise im Kombination mit MPLS
● “VRF ohne MPLS” → VRF-lite
– Hier: VRF-lite

38. 38
VRFs vs. Policy Routing
● Alt bekannt: Policy-Routing (seit Kernel 2.2)
● Fussschusspotential
– Rules für v4 und v6 vorhanden?
– Rules für alle Interfaces vorhanden?
– Rules für alle Source-Prefixe vorhanden?
– Pipe-Protokoll in Bird
– Management-Katastrophe

39. 39
VRFs vs. Network Namespaces
● Seit Kernel 2.6.24++
● NetNS haben eigene
– Routingtabellen
– Routing Policies
– Netfilter Regeln
● Device Layer separation
● Prozesse müssen in NetNS laufen
● Uncharmant im Freifunk Umfeld
– “Zuviel des Guten”

40. 40
VRFs unter Linux
● Separierung für Layer3 Kommunikation
● VRF-Interface als Master für “echte” Interfaces
– Legt Routing-Table für VRF fest
● Ab Kernel 4.[345] (nehmt >= 4.9)
https://git.kernel.org/cgit/linux/kernel/git/to
rvalds/linux.git/tree/Documentation/networking/
vrf.txt
https://cumulusnetworks.com/blog/vrf­for­linux/
https://de.slideshare.net/CumulusNetworks/opera
tionalizing­vrf­in­the­data­center

41. 41
VRFs unter Linux
ip link add VRF_DEVICE type vrf
table ID
ip link set dev DEVICE
master VRF_DEVICE

42. 42
VRFs mit ifupdown2
auto eth0
iface eth0
address 185.46.137.163/25
address 2a00:13c8:1000:2::163/64
gateway 185.46.137.129
gateway 2a00:13c8:1000:2::1
vrf vrf_external
auto vrf_external
iface vrf_external
vrf­table 1023

43. 43
VRF-Konzept
● Haupt-VRF mit internem Freifunk-Netz
– OSPF + iBGP
– Routen zu allen internen Hosts und Diensten
– Debugging mit Standardtools
● Ggf. “external” VRF für Interfaces mit public IPs
– GRE-Tunnel zu AS201701
– OpenVPN-Verbindungen
– Fastd-Einwahl
– Eigene public facing services

44. 44
Inter-VRF-Kommunikation
● Nur in Ausnahmefällen erforderlich
● Erfordert vEth-Paar
– Quasi virtuelles Netzwerkkabel
● Ein Ende in Haupt-VRF, eins in VRF “external”
● Bird spricht BGP mit sich selbst
– Exportiert aggregierte Prefix(e)
– Importiert Public IP(s)
● Public IP(s)s intern redistributiert

45. 45
Veth unter Linux
ip link add VETH_END1 type veth
peer name VETH_END2
# ip l
[...]
24: VETH_END2@VETH_END1: [...]
25: VETH_END1@VETH_END2: [...]

46. Dienste in VRFs
● SSH, Webserver, … soll public erreichbar sein
● $Anwendung schickt Antwortpakete über
default VRF zurück
– Mäh
➔ There's help:
– net.ipv4.tcp_l3mdev_accept (4.x)
– net.ipv4.udp_l3mdev_accept (>= 4.11)
● Wenn das nicht hilft: Applikation patchen (easy)

47. 47
OpenVPN vs. VRFs
● Viele OpenVPN Tunnel im Einsatz
● OpenVPN muss über VRF “external” reden
● Dafür brauchts einen kleinen Patch
setsockopt (sd, SOL_SOCKET,
SO_BINDTODEVICE, dev, strlen(dev)
+1);
● https://github.com/OpenVPN/openvpn/pull/65
– Hallo Gert *wink* :-)

48. Bind9 vs. VRFs
● Wunschsetup (deprecated historical):
– Public Auth-DNS (VRF external)
– Recursor (main VRF)
● Jaja, nicht hauen.
● udp_l3mdev_accept hilft leider nicht
➔ ip ­[4|6] rule add from $public_ip
table vrf_external
● Nur bedingt schön

49. dnsdist (PowerDNS) vs. VRFs
● 25.05.2017 19:58 in #powerdns gefragt
– 22:48: PR #5344
● 26.05. 13:50 nach repo/Pkg gefragt
– PR noch nicht gemerged → nicht in master
– 13:59 Buildchain angeworfen für PR #5344
– 14:10 APT Repo für Build fertig
● <3
● (Noch keine Zeit zum Testen gehabt)

50. 50
“Fixed”: VRF support für pppd
● An manchen Standorten DSL-Uplink vorhanden
● ppp0 soll in VRF “external”
● Mit post-up scripts geht's leider nicht direkt
– Mit 3 Skripten und at geht's
– RFC1925 (6a) applies
● pppd braucht wohl auch einen Patch :-)
– Komplizierter als gedacht

51. 51
Recap
✔ Erledigt
✔ Fails
✔ Geroutete Infrastruktur
✔ Automatisierung
✔ Ausfallsichere Services
✔ Elegantes und sicheres Routing
● Next up
– B.A.T.M.A.N.-Overlays
– Lessons Learned

52. 52
Recap Freifunk / B.A.T.M.A.N.
● Freifunk basiert auf Batman-Meshes
– Eine oder mehr Layer2-Domains
– Ermöglicht netterweise Roaming
● Das ist in der City total cool
● B.A.T.M.A.N Adv.
– Layer2-in-Layer2 Mesh-Protokoll
– Keine Interface-Kosten, nur Hop-Penalty
– Gateway-Knoten == DHCP-Server
– Jede Instanz braucht eigene Layer2-Verbindung zu
Peers

53. 53
Wireless Backbone (Planung)

54. 54
Wege aus der VLAN-Hölle
● B.A.T.M.A.N. braucht Layer2-Verbindung
● IP-Backbone vorhanden
● Layer2-Overlay wäre praktisch!
– MPLS unter Linux bisher nur tw. Vorhanden
➔ VXLAN

55. 55
VXLAN
● “Ethernet over UDP”
– Oder: “Poor mans approach to MPLS”
● Designed als Layer2-Overlay in Data-Centern
– Multi-tenant Overlay über IP-Fabric
– 24Bit VNI => 16M Instanzen möglich
– Unicast/Multicast Kommunikation
– Endpunkt = VTEP (VXLAN Tunnel End Point)
● RFC7348

56. 56
VXLAN unter Linux
ip link add DEVICE type vxlan id ID
[ dev PHYS_DEV ]
[ { group | remote } IPADDR ]
[ local { IPADDR | any } ]
[ … ]

57. 57
VXLAN mit ifupdown2
auto vx_v1002_padcty
iface vx_v1002_padcty
vxlan­id 655617
vxlan­physdev vlan1002
vxlan­svcnodeip 225.10.2.1
#
hwaddress f2:00:c1:01:10:02
mtu 1560
#

58. 58
IPoBATMANoVXLANoIPoVLANoRF
● Wait, what?
Ethernet (RF / Kabel)
Vlan
IP
VXLAN
B.A.T.M.A.N. Adv.
VXLAN
IP

59. 59
MTU
● »Increasing MTUs for fun and profit«
– Mesh-Netz (BATMAN): 1500
– BATMAN-Underlay (VXLAN): 1560
– VXLAN-Underlay (VLAN): 1610
– On-Wire: 1628
IP-Paket
im-Mesh
BATMAN
(+ NC)
VXLANUDP
4 14 20 8 8 60 14 1500
https://github.com/FreifunkHochstift/ffho­salt­
public/blob/master/_modules/ffho_net.py#L77
IP.1q EthEth

60. 60
Recap
✔ Erledigt
✔ Fails
✔ Geroutete Infrastruktur
✔ Automatisierung
✔ Ausfallsichere Services
✔ Elegantes und sicheres Routing
– B.A.T.M.A.N.-Overlays
● Next up
– Lessons Learned

61. 61
Lessons Learned, Part 2

62. 62
Lessons Learned
● Offload ist ein Thema voller Missverständnisse
– Abschalten! (GS, GRO, GSO, TSO)
– 4KB/s vs. 40MB/s
● BCP38 ausrollen
● Kernel >= 4.9 nehmen
– Mit 4.6 / 4.7 IPv6-Routing in VRF subtil kaputt
– Mit 4.8
● Problem mit Bridges und B.A.T.M.A.N.
● IPv6 und Fragmentation

63. 63
Offloading
● Der Unterschied zwischen 4KB/s und 40MB/s...
for iface in eth0 eth1; do
for feature in sg gro gso tso
rxvlan txvlan; do
ethtool ­­offload ${iface}
${feature} off
done
done

64. 64
Systemd + OpenVPN vs. ifup
● Einige OpenVPN Instanzen konfiguriert
● up /etc/openvpn/ifup
– ifup “$1”
● Dank systemd starten Instanzen parallel
– Einige ifup-Aufrufe parallel
– Nahezu keine IPs mehr konfiguriert
– Mäh
➔ flock –exclusive –wait 30

65. 65
Bird 1.6.1 doom
● Bird 1.6.1 + Pipe-Protokoll = Segfault
● Unattended-upgrades ist 'ne tolle Sache
● Salt state pkg.latest auch
● Freifunk Hochstift war zweimal “aus”.
● Oops.

66. Management-Backdoor
● APU2b leider nicht 100% reboot-safe
● Ein Advisary würde lauten:
»Under rare unspecified conditions the device
may be stuck in an unknown state after a
reboot and may not boot correctly.«
● Dann ist leider das Mgmt-Netz an $POP aus
– Das ist bedauerlich
➔ Mgmt-Vlan über RF-Strecken exportieren

67. The plumbing on the air

68. 68
Backend-Infrastruktur
● Mittlerweile über 60 Systeme
– Debian (Jessie) Linux auf Blech oder in VMs
– An immer mehr POPs im Hochstift
– Server + VMs verteilt in .de
– Angebunden per RiFu-Backbone oder VPNs
● Monitoring per LibreNMS + Icinga2
– Weathermaps + Genöle
– Genöle bald auch per Telegram-Bot
– Viel gut

69. 69
Hardware
● Zoo aus z.T. gesponsorter
Hardware
– Server, Switche, Richtfunk, ..
➔ Versuch der Homogenisierung
– PCengines APU2
– Netonix WISP Switches
– Ubiquiti Networks
● PowerBeam
● LiteBeam
● AC Mesh Pro

70. 70
Ubnt Unifi Controller

71. 71
Premium Ultra Mesh Plus (PUMP)
● Gluon vs. 5GHz AP
– 5GHz AP muss DFS können
– Kein DFS-Support für Linux
– Meh
➔ “Fix” (Trust me, I'm an engineer!)
– Ubnt LBE-5AC-16-120 mit Stock-Firmware
– $5GHz-AC-Client device (z.B LBE-5AC-23)
– Dann Mesh-on-LAN zur $Gluon-Device

72. 72
Abdinghof

73. 73
Aufbau PaderHalle

74. 74
Reismann Gymnasium

75. 75
Freifunkromantik

76. 76
Future wins
● SOL-Adapter für APU
● Mgmt-SSID auf zentral verwalteten APs
– WPA2-Enterprise mit Radius auf $APU
● Get IPv6-PI, announce, renumber, profit
– RIPE AP-WG Proposal 2016-04
– v2.0 upcoming
● Tflow2 + AS-Stats
● Dinge

77. 77
Further Reading
● #routingdays – Learn to build the Internet
– Event: https://routingdays.ffrl.net/
– Videos: https://media.ccc.de/search/?
q=routingdays
– Slides: http://tea.systems/FFRL-RD.pdf
●

78. 78
Fragen? Anmerkungen?
Maximilian Wilhelm
@BarbarossaTM
Freifunk Hochstift
@ffhochstift + @ffho_noc