Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Software Defined Freifunk Backbones

313 Aufrufe

Veröffentlicht am

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.

Veröffentlicht in: Internet
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Software Defined Freifunk Backbones

  1. 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. 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. 3 Agenda ● Hintergrund ● Fails ● Automatisierung – Ausfallsichere Services – Elegantes und sicheres Routing (VRFs) ● Layer2-Overlay (VXLAN) ● Lessons Learned
  4. 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. 5 Dieses Freifunk Fokus heute
  6. 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. 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. 8 Wir waren jung und naiv...
  9. 9. 9 Tinc for the win (damals™)
  10. 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. 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. 12 I can haz PoE switch for AF-5X? Nicht von UBNT. Netonix to the rescue!
  13. 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. 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. 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. 16 Wireless Backbone (alt)
  17. 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. 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. 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. 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. 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. 22 Automatisierung
  23. 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. 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. 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. 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. 27 The SDN part #SDN Disclaimer: Schriftart auf besonderen Wunsch von AbraXXL
  28. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 41 VRFs unter Linux ip link add VRF_DEVICE type vrf             table ID ip link set dev DEVICE             master VRF_DEVICE
  42. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 53 Wireless Backbone (Planung)
  54. 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. 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. 56 VXLAN unter Linux ip link add DEVICE type vxlan id ID [ dev PHYS_DEV ] [ { group | remote } IPADDR ] [ local { IPADDR | any } ] [ … ]
  57. 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. 58 IPoBATMANoVXLANoIPoVLANoRF ● Wait, what? Ethernet (RF / Kabel) Vlan IP VXLAN B.A.T.M.A.N. Adv. VXLAN IP
  59. 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. 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. 61 Lessons Learned, Part 2
  62. 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. 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. 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. 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. 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. 67. The plumbing on the air
  68. 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. 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. 70 Ubnt Unifi Controller
  71. 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. 72 Abdinghof
  73. 73. 73 Aufbau PaderHalle
  74. 74. 74 Reismann Gymnasium
  75. 75. 75 Freifunkromantik
  76. 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. 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. 78 Fragen? Anmerkungen? Maximilian Wilhelm @BarbarossaTM Freifunk Hochstift @ffhochstift + @ffho_noc

×