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.
200 verteilte Oracle- Server mit Ansible ausrollen
Software Defined Freifunk Backbones
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
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
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
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>
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
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
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/ffhosaltpublic
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/ffhosaltpublic/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/ffhosalt
public/blob/master/bird/ffpolicy.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/vrfforlinux/
https://de.slideshare.net/CumulusNetworks/opera
tionalizingvrfinthedatacenter
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
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
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
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
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
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