Software Defined Freifunk Backbones

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

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

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

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

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
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

9
Tinc for the win (damals™)

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
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
I can haz PoE switch for AF-5X?
Nicht von UBNT. Netonix to the rescue!

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
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
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>

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
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
Recap
✔ Erledigt
✔ Fails
● Next up
– Automatisierung
– Geroutete Infrastruktur
– Elegantes und sicheres Routing
– B.A.T.M.A.N.-Overlays
– Lessons Learned

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
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

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
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
Pillar Example
bbrvega.in.ffho.net:
  id: 198
  sysLocation: Vega
  roles:
     router
     batman
     bbr
  sites:
     padcty
Quelle für Loopback-IP
Bird-Config generieren
Quelle für Loopback-IP
Batman-Interfaces generieren
Batman-Instanzen

26
Pillar Example contd.
ifaces:
    bond0:
      bondslaves: "eth0 eth1 eth2"
    vlan1002:
      desc: "<> gw04"
      vlanrawdevice: bond0
      prefixes:
         10.132.253.58/31
         2a03:2260:2342:fe1c::1/126
      batman_connect_sites: padcty
[...] #

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

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
ifupdown2
● Leider keine Featureparität mit ifupdown
● Kann von Hause aus
– Dependency Resolution
– ifreload
– VLAN-Aware-Bridges
– VRFs
– VXLAN
● Kann (noch) nicht:
– ppp

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
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/ffhosaltpublic

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
#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/ffhosaltpublic/tree/master/bird

34
Recap
✔ Erledigt
✔ Fails
✔ Automatisierung
✔ Geroutete Infrastruktur
● Next up
– Elegantes und sicheres Routing
– Lessons Learned

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/ffhosalt
public/blob/master/bird/ffpolicy.conf

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
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
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
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
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/vrfforlinux/
https://de.slideshare.net/CumulusNetworks/opera
tionalizingvrfinthedatacenter

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

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
       vrftable 1023

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
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
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:  [...]

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
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* :-)

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

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
“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
Recap
✔ Erledigt
✔ Fails
✔ Automatisierung
✔ Ausfallsichere Services
✔ Elegantes und sicheres Routing
● Next up
– Lessons Learned

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
Wireless Backbone (Planung)

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
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
VXLAN unter Linux
ip link add DEVICE type vxlan id ID
[ dev PHYS_DEV ]
[ { group | remote } IPADDR ]
[ local { IPADDR | any } ]
[ … ]

57
VXLAN mit ifupdown2
auto vx_v1002_padcty
iface vx_v1002_padcty
        vxlanid        655617
        vxlanphysdev   vlan1002
        vxlansvcnodeip 225.10.2.1
        #
        hwaddress f2:00:c1:01:10:02
        mtu 1560
#

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

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/ffhosalt
public/blob/master/_modules/ffho_net.py#L77
IP.1q EthEth

60
Recap
✔ Erledigt
✔ Fails
✔ Automatisierung
✔ Ausfallsichere Services
✔ Elegantes und sicheres Routing
● Next up
– Lessons Learned

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
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
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
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.

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

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
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

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

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
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
Fragen? Anmerkungen?
Maximilian Wilhelm
@BarbarossaTM
Freifunk Hochstift
@ffhochstift + @ffho_noc

Software Defined Freifunk Backbones

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Software Defined Freifunk Backbones

Similar to Software Defined Freifunk Backbones (20)

More from Maximilan Wilhelm

More from Maximilan Wilhelm (18)

Software Defined Freifunk Backbones