Die Themen Infrastructure Automation / Orchestration, Cloud und Software Defined Networks sind in aller Munde und nahezu jeder Netzwerkhersteller, der etwas auf sich hält,bietet Produkte und stellenweise sogar Lösungen in dieser Buzzwordblase an. Der in den letzten Jahren vollzogene Paradigmenwechsel hin zu mehr (Host/Segment-)Routing und weniger Layer2-Magie – Stickwort >>IP Fabric<< - sowie die Besinnung auf offene Standards (OSPF, ISIS, BGP, MPLS) nicht nur in Data-Center-Netzwerken hat neue Standards (z.B. VXLAN) beschert und Open-Source-basierte "Open Networking"-Plattformen auf dem Markt erscheinen lassen. Auf einmal ist man nicht mehr an das Betriebsystem und die Vorgaben des Hardwarevendors gebunden, sondern kann die Control-Plane einiger Gerate mit verschiedenen Linux-basierten Produkten nahezu vollstandig selbst kontrollieren und orchestrieren. Dank der Linux-Basis und Freude am Open-Source-Gedanken mancher Hersteller sind einige Features in Open-Source-Komponenten (Linux-VRFs, MPLS-Forwarding-Plane im Kernel, etc.) gewandert und stehen somit überall zur Verfügung. Besonders zu erwähnen ist hier das Debian-basierte System von Cumulus Networks, aus deren Feder ifupdown2 sowie VRF-Support in Linux stammen. Eine Sammlung dieser Technologien und Ansätze lassen sich auch in Low-Budget- und/oder Eigenbau-Netzwerken anwenden und können hier erstaunliche und mächtige Optionen eröffnen. Der Vortrag wird am Beispiel der Netzwerk- und Server-Infrastruktur des Freifunk Hochstift darlegen, wie man mit ein bisschen SaltStack, knapp 1000 Zeilen Python und erschwinglicher Hardware eine SDN-basierte Service-Provider Infrastruktur bereitstellen kann, in der Overlay-Netze und Anycast keine Fremdworte sind. Neben einem “Technology-Overview” wird es eine Failosophy und Lessons Learned aus dem echten Leben eines Freifunker geben ;-) Das Zielpublikum des Vortrags umfasst in erster Linie (Linux-)Administratoren und Netzwerker, die bereits Erfahrungen mit der jeweils anderen Welt haben und wissen was Routing ist. Eine positive Einstellung zu Automatisierung ist von Vorteil.

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