 Ja, ich bin der Max, zu finden auf Twitter unter den Händeln da. Bauer-Uni-Infrastruktur im echten Leben, am Tag über und nachts den ganzen Freifunkkram. Ich bin nebenbei Vorstand vom Freifunkhochstift, weil wir mal ein legal Entity brauchen und mach so Zeug mit Linux, Netzwerken und Open Source, wie man gleich sehen wird. Was erzähle ich heute? Wie baut man kommunistische Frickelnetze? Definitive Guide. Was ist alles schief gegangen und warum solltet ihr das nicht tun? Automatisierung sollten sie kaufen. Es ist sehr gut. Was kann man da von uns quasi frei klauen und selber umsetzen? Optimalerweise mit wenig Anpassung. Wie macht man seine Services ausfallsicher? Wie macht man sein Routing schön? Layer 2 Overlays für Batman und was haben wir alles gelernt? Kurzer Hintergrund. Freifunkhochstift fing an 2013 als Freifunkpadderborn. Das ist quasi auf dem Kongress da gegründet worden. 31, 31 C3, ich weiß nicht genau, welcher das war. Wir sind ziemlich schnell ziemlich stark gewachsen dank ein paar Unterstützern. Zum Beispiel hat eine der Bäckereien im Hochstift, was die Kreise Padderborn und Kreise Höxter sind, also relativ großer Bereich, hat mal eine halbe Million Brötchentüten gedruckt und die haben wir designet. Das heißt, das war quasi freie Werbung für Freifunk in 76, glaube ich, Filialen dieser Bäckereikette. Das hat uns ziemlich gepusht. Die Werbegemeinschaft Padderborn hat festgestellt, die sind ja gar nicht so doof, mit denen kann man reden und Dinge tun. Die Förderung vom Land seit 2015, da haben wir in Summe jetzt 45.000 Euro abgegriffen und umgesetzt. Und die Stadt hat uns letztes Jahr vier Pops in der Stadt aufgebaut, inklusive einem 30 Meter hohen Turm. Das heißt, wir haben gesagt, wo und sie haben da Pinden dran geschraubt und Kabel gelegt und wir schrauben jetzt innen aktives Equipment dran. Das ist ganz cool. Ist einigermaßen groß. Muss ich das irgendwie mir erklären? Nein, okay. Dann gehe ich jetzt davon aus, dass klar ist, was ein Gateway ist und wie so ein Freifunk grundsätzlich funktioniert. Wenn nicht, bitte jetzt schreien. Keine Schreie. Dann muss ich glaube ich auch nicht erklären, hallo, Laptop. Dann muss ich glaube ich auch nicht erklären, was Batman ist und wie das funktioniert. Keine Schreie. Historisch hat man Batman benutzt, weil das einfach so in den fertigen Freifunkfilmen, wer es drin war, das ist eine große Layer 2-Domain, das wisst ihr dann alle. Das skaliert halt mal so überhaupt nicht. Das heißt, wenn man, wenn das größer wird und man 1000 Knoten in einer Layer 2-Domain hat, mit Batman hat man nachher ein paar Hundert Kilo bei Grundrauschen für Arp, Neighbor Discovery, Batman selber und gelöt. Das drückt im Zweifelsfall DSL-Leitungen zu für die Leute, die zu Hause nutzen. Da macht man sich sehr unbeliebt mit und das funktioniert nicht mehr so richtig schön. Wir haben mittlerweile 10 kleinere Batman-Domains gebaut und die jeweils Dual-Stack kriegen, V4, V6. Dazu brauche ich noch ein Full-Mesh zwischen den ganzen Gateways und da kriegen wir alles gleich noch schön erklärt, wie man das macht. Aber, wir haben ja auch mal klein angefangen und dann gibt es da diese Firmen, die meinen, Freifunk ist total geil, da machen wir mal mit und wir deployen mal einen Haufen Knoten, auch bei uns in der Firma, so als Gesternetz. Und diese ganzen lustigen Knoten haben ja diesen schönen Blauen Port als Abling und die vier gelben Ports. Die kann man jetzt so umkonfigurieren, dass man darüber Geräte zum Mesh miteinander kriegt oder man kann das lassen und die trotzdem mit dem Internet verbinden. Dann hat man auf einmal seinen Firmennetz im Freifunk. Kannste so machen, ist dann aber kacke. Da hatten wir zwei, drei Kandidaten, unter anderem auch irgendwelche Fritzboxen oder wirklich komplette Firmennetze, auf die man vom Gateway aus zugreifen konnte, wenn man sich nach IP konfiguriert hat daraus. Das haben wir dann mal durch einen Filter in der Firmenwehr ausgebaut. Einige Communities haben sich das schon geklaut. Wenn ihr das noch nicht habt, dann könnt ihr euch mal raten, das anzugucken. Wir kämpfen noch damit, das App-Stream in Gluern zu kriegen. Ich glaube, die Chancen stehen gar nicht schlecht im Moment. Das bringt ungefähr 30% des Grundrauschens raus. Weil man auf einmal nicht mehr irgendwelche kaputten Geräte hat, die glauben, dass sie in 0 slash 0 sind und einfach mal ab für alles schicken, auch für Google-DNS-Server oder in 169, 254, den V4 Link-Local-Netz und was auch immer. Die Blut sind mit weg. Tink ist toll, dachten wir. Da sind wir wieder bei diesem großen Layer-2-Netz. Die Idee war mal, wir haben ein großes Infrastruktur-Tink, was an zwei hier damals hießen sie noch VPN-Servern, also Core-Routern, aufgehängt ist, wo alles drin hängt. Darüber fahren wir ein bisschen OSPF, damit das alles schön dynamisch ist. Das skaliert leider wie ein Sack Nüsse. Die Idee damals war, viele Point-to-Point-Tunnel bauen, ist ja kompliziert und das macht Arbeit. Wir sind wieder bei dem Stichwort Automatisierung. Ein großes Layer-2-Netz ist viel einfacher. Wenn wir da zwei Server hinstellen, haben wir schon Redonant. Tink will es schon richten. Würde ich nicht ausprobieren, haben wir ein Jahr lang gemacht. Das geht an füchterlich vielen Stellen, füchterlich in die Hose und man hat keine Chance, den Treffig zu steuern dadurch. Und allerspätestens mit einem Richtfunk backbauen möchte man das auch nicht mehr so richtig tun. R-Fiber ist ja geil, da kriegt ein Gigabit drüber. Ist ja mal ein bisschen teuer. Wir nehmen mal die R-Fiber 5X, das Low-Kost-Modell, ich glaube 700 Euro pro Seite, die Schüssel und der aktive Feed hinten dran. Bist du bei 1,5K ungefähr für eine Richtfunkstrecke? Wenn man Landes-Sponsoring hat, kann man sich so was mal leisten. Aber erstens, die Dinger bohlen 24 Volt VH, nennt sich das, das heißt 1,5 Ampere auf über 8 A des Netzwerkkabels. Was schon mal eine Ansage ist. Denkt man sich, kaufen wir doch mal UBNT-Switches. Damals hießen sie noch Edge-Switche, glaube ich. Die werden das wohl power'n können, weil wir würden das Ding gerne remote power-cycle'n können, wenn es sich mal die Karten legt, soll ja vorkommen. Weit gefehlt, die können diese Art von Power'n nicht. Dafür gibt es Netflix, es ist ein amerikanischer Hersteller, kann man auch bei Various Store kaufen, die können das unter anderem, macht viel Freude. Aber dann ist dann noch das Thema mit der R-Fiber 5X. Die sind eigentlich ganz nett, aber wenn man sie im 5,6 Gigahertz-Bereich nimmt, was das Wetterer da ist von Flugzeugen und zufällig zwei Hilfen in der Nähe hat, wo die Flugzeuge dann eindrehen, was wir auf diese R-Fiber zeigen, dann sind die regelmäßig mal zehn Minuten lang offline, weil sie feststellen, da hat ja noch jemand ein Wetterer da an, ich mach' mich jetzt mal aus. In dem Bereich sagt der DFS Scan, was die Dinger machen müssen, du bist dann mal zehn Minuten aus und wartest, bis die Luft wieder frei ist. Das passiert dann relativ häufig und wenn du Pecher nicht vorhersehbar, dann ist halt der Standort einmal offline. Was wir auch hatten, unsere R-Fiber auf 5,5 Gigahertz irgendwo unterwegs, der Mensch, der diesen Pop eigentlich betreibt und selber sehr viel Richtfunk macht, beklagte sich nach einem Tag ungefähr, dass Störungen im 5,8 Gigahertz-Bereich sind. Machen wir die R-Fiber aus, ist Ruhe. Man wundert sich. Oder Störungen auf parallel laufenden Kabeln zu den Schüsseln. Entweder wir haben nur Montagsmodelle von den Dingen angekauft oder die Hardware ist eher nicht so premium. Benutzt die zufällig irgendwer? Okay. Kannst du das bestätigen denn wir haben da bald 10 Stück von über. Ja, nächster Punkt. Wenn man sich die Kosten anguckt, 700 Euro pro Seite ist schon ein Wort und sich dann eine Power Beam anguckt, die ich glaube 180 Tala pro Seite kostet, kriege ich mit der irgendwie 2-3 Mal so viel Durchsatz hin auf einigen Strecken. Ergo, wir kaufen die nicht mehr. Das nächste auch UBNT, die Edge Router, die kleinen. Ich glaube, wir hatten damals die Leid oder den Edge Router ohne irgendwie Namenszusatz und die Idee war, das Ding kann man noch irgendwo versenken, das ist klein, das frisst keinen Strom, das kann PoE für kleine Schüsseln. Aber das wäre doch total geil, wenn man dem beibringt, Batman zu sprechen. Das hat dann mal jemand getan, nachdem man ein NDA unterschrieben hat und dann das SDK von UBNT gekriegt hat zum entwickeln und nach mehreren Flüchen und Wochen gab es dann für diese Version dieses Geräts ein Batman-Modul. Das hat dann auch funktioniert. Aber bei einem Update des Edge Routers muss man relativ viel zaubern, überhaupt wieder draufzukommen und das abzustellen. Und die Performance ist auch eher so mittel, das Ding hat ja keine CPU, die wirklich den Namen CPU verdient. Dafür ist das Ding halt nicht gebaut. Würde man vielleicht auch eher lassen wollen. Also könnte er klauen, würde ich aber auch nicht versuchen. Wo wir bei Edge Routern sind, ich habe vor einer Weile, wir haben noch zwei, drei davon im Einsatz in Layer 3 Setups, die wir in Flüchtlingsunterkünften nutzen. Wir fahren da drüber per OSPF einfach nur IP Dual Stack und ruten da Brieffixe hin, bzw. die Dinger machen dann DRCP und schicken RS ins Netz für Sachen, wo nichts drumherum ist, was meschen kann. Das skaliert einfach besser. Oder wenn man mal 2, 300 Leute auf einem Fleck hat, möchte man vielleicht den ganzen Batman-Overhead mal aus dem Bild nehmen. Da habe ich vor einer Weile einen Core-Router aktualisiert, wo das Ding, oder wo vier der Dinger OpenVPN-Tunnel hin aufgemacht haben. Das heißt, man musste die Config mit Schruder anfassen und OpenVPN durchtreten. Mit Hausmitteln ging das mal gar nicht. Wenn man das per Kill All und Neustart macht, dann fällt einem leider das Quagger um und OSPF kommt auch nicht mehr hoch. Das macht alles auch nicht so richtig viel Spaß. Reboot fixen die Issue. Ist günstig. Ihr merkt schon, welche Richtung das so geht. Damals, als wir noch jung waren, hatten wir mal die Idee, wir haben mehrere Standorte. Die IT-Unternehmen mit Butterborn und Provider, die machen selber sehr viel mit Richtfunk, das heißt, die haben das Dach voll mit Antennen, haben gedacht, 2, 3 mehr von uns stören auch nicht. Da haben wir damals viel Platz gekriegt und haben auch ein Server dastehen und ein Stück Ablink von denen, um ein 100 MB symmetrisch, demnächst hoffentlich ein bisschen mehr. Und haben da ein paar Richtfunkstrecken aufgebaut. Eine in die City, zur Volksbank, die gehört zur Werbegemeinschaft dazu, das heißt, da haben wir auch Dinge auf dem Dach und Accesspoints außen dranhängen, die wir aufgebaut haben. Dann neben KT ist ein Modehaus Klingental, gehört auch zur Werbegemeinschaft. Da haben wir auch was auf dem Dach und auch dranhängen, auch auf deren Kosten, also der Werbegemeinschaft. Das heißt, in der City haben wir jetzt aktuell 3 Präsenzen, mittlerweile noch eine mehr. Und unten ist so eine Einrichtung auf dem Berge, wo auch Dinge auf dem Dach hängen. Das haben wir damals alles aufgebaut. Mit der Idee, na gut, wir brauchen Layer 2, wir haben nur eine Batman-Instanz, also schicken wir da über jeden Link quasi ein Vilan, verbinden damit die Batman-Entsprechenden Geräte an jeder Stelle. Wenn man nur eine Batman-Instanz hat, kann man das noch so bauen. Wenn man nachher 10 Stück hat, die man darüber transportieren möchte, skaliert das alles nicht mehr und man klickt sich ein Wolf. Das wollen wir natürlich nicht. Und ich möchte ja zusätzlich noch neben dem Batman-Transport vielleicht noch mein IP-Netz für Management und für irgendwelche Layer 3-Standorte transportieren. Das heißt, ich bräuchte noch mehr ein Stapel, noch schon größeren Stapel wie Lanz. Da wollen wir eigentlich nicht hin. Was machen wir jetzt gerade? Möglichst kleine Layer 2-Segmente, egal wo, egal ob Kabel oder Funk. Möglichst Point-to-Point-Verbindungen, also zwei aktive Geräte seien es jetzt zwei VMs, zwei Backborn-Router, was kleiner APU-Boards sind, oder ähnliche Dinge, möglichst direkt verbinden. Das üblicherweise dann mit Vilan. An vier Pops, wo ziemlich viel steht, also Virtualisierungshosts und noch ein bisschen anderes Zeug drumherum, da macht das nicht so richtig Sinn, das ist kloppt, wenn man da jedes Gerät miteinander verbindet. Aber ansonsten ist das übliche Setup einmal unten aufgemalt, diese APU-Boards, diese kleinen Kistchen als Backborn-Router. Da gibt es üblicherweise ein Switch, wo die ganzen Antennen dran hängen, Richtung dazwischen. Das ist quasi dann an der Layer 2-Strecke, da drüber fahren wir ein IP-Netz. Der Batman-Teil kommt dann gleich später, wie wir das gerade lösen. Also Zusammenfassung der bisherigen Erkenntnisse. Lieber der Batman-Hop selber bauen wir das mit überall im Internet. Die Provider sollten das auch alle tun, aber das ist ein anderes Thema. Point-to-Point ist toll, Routing ist toll und nur weil es viel Geld kostet, muss es nicht unbedingt besser sein, gerade jetzt auf die Airfibers bezogen. Und dann alles verhandt zu konfigurieren, macht auch nicht so richtig Spaß, das möchte man automatisieren. Das gucken wir uns jetzt mal an. Das erste Gateway war 2013, das wurde dann Hand gekloppelt, nach damals noch einer der wenigen Anleitungen, das zweite Gateway wurde schon mal per Shell Script installiert, also Batman drauf, der CP Server drauf, DNS Server drauf, Bridges bauen, das war alles ziemlich use with extreme prejudice, da durfte auch nichts bei schief gehen. Das dritte habe ich dann aufgesetzt, da bin ich dazu gekommen, dass einmal Fehler resistenter gebaut, aber schön war das auch noch nicht, aber damit konnte man zumindest die nächsten drei Gateway automatisiert aufsetzen, nächsten vier sogar. Aber da muss man ja ab und so was dran anfassen. Das wurde natürlich nicht automatisiert und macht so richtig Spaß auch nicht. Aber dafür gibt es ja so Dinge wie Solstack oder Puppet oder Enzybil oder oder oder. Wir haben uns für SORT entschieden, das hatte eine relativ kleinere Einstiegshürde, damit konnte man ziemlich schnell loslegen, das haben wir vor 2,5 Jahren, glaube ich, angefangen ungefähr, 2,5 Jahre. Damit kann man seine Pakete installieren, Konfigurieren dahinter packen, Dienstestarten oder auch nicht, und so weiter und so fort. Der erste Ansatz war das erste Mal, dass ich was mit SORT gemacht habe. Das hat ein Jahr gehalten, dann habe ich es für Scheiße befunden und neu gemacht. Und mittlerweile haben wir wirklich einmal alles neu gebaut. Das liegt auch auf GitHub, Link kommt noch. Das dürft ihr alle gerne forken. Ein, zwei Leute tun das, glaube ich, schon. Und dann automatisiert man mal vor sich hin und schmeißt das einmal auf alle seine Geräte und optimalerweise läuft dann noch alles. Kurzer Abriss auf ganz hoher Flughöhe, wie arbeitet SORT. Es gibt sogenannte States. Das repräsentiert irgendwas, was man als logischer Einheit betrachtet. Zum Beispiel Konfigurieren in SSH-Server, Konfigurieren in den Respondeder drauf oder Konfigurieren in der ganzen Netzwerke. Das ist alles im Jammelformat geschrieben. Das ist relativ übersichtlich, aber ziemlich gemein. Wenn man Tubs und Spaces mischt, dann fällt es leider komplett um. Darüber kann man sich seine Pakete installieren, Services dazu aktivieren oder wegschmeißen, was auch immer man tun möchte. Dann kann man die Verhalte setzen, automatisiert, entweder statisch oder zum Beispiel mit sogenannten Ginger Templates, wo man sich irgendwo zusammenferkelt, mit irgendeiner Logik zusammenbaut und dann Dinge tut. Useranlegen und so weiter. Zwischen den States kann ich netterweise Abhängigkeiten modellieren. Das heißt, ich kann sagen, konfiguriere mir erstmal ein APT auf einem Webian und dann installiere mir die Pakete und Ähnliches. Dadurch kriegt man das hin, installiert, dem sagt, Hallo, da ist dein Preceed-File für ein Debian-Installer. Dann eiert der da einmal durch. Das dauert dann 10 Minuten oder sonst was, da kann man irgendwie Netflix gucken. Dann installiert man da ein Saltminion drauf, einen aktuellen Kernel, bootet die Kiste einmal, sagt dem Saltminion, Hallo, da ist dein Master, wartet fünf bis zehn Minuten, bootet das Ding und das ist fertig. Das macht dann schon deutlich mehr Spaß. Und dann sind sie vor allem auch alle gleich. Salt hat noch ein Pillar und möchte, dass die nicht überall hinkommen. Diese ganzen States werden auf jeden Minionsynchronisiert. Das heißt, da möchte man seine Passwörter eigentlich nicht reinschreiben. Macht man eine Kiste auf, hat man die Konfig von allen quasi. Dafür gibt es das Pillar, ist auch Jammel. Da kann ich ein bisschen filtern, welcher Minion welche Informationen lesen darf. Das heißt, ich kann zum Beispiel sagen, dass den Private Key für das House-Zertifikat darf nur jeder jeweilige Minion selbst lesen. Dafür ist das Ding gedacht. Sieht dann ungefähr so aus. Das ist der Backborn-Router an dem vorhin schon mal angesprochenen Wegasystems-Standort. Oben gibt es eine eindeutige ID. Daraus generieren wir uns eine IP-Adresse für Loopback. Jeder Router sollte eine eigene Loopback-IP haben. Wo soll das Ding stehen? Welche Rollen hat es? Davon hängen ab, welche Pakete oder welche States da drauf kommen. Das ist zum Beispiel ein Router. Das heißt, der wird eine Bird-Konfiguration generiert bekommen. Der wird Forwarding angemacht, wir generieren automatisiert Batman-Interfaces. Welche fällt aus der Liste der Sides unten raus. Der hat nur eine Side konfiguriert. Aber aus diesen zwei Informationen werden ein Dummy-Interface das Batman-Interface selber konfiguriert. Mit entsprechend automatisierten MAC-Adressen. Die müssen ja alle eindeutig sein. Und das Ding soll ein Backborn-Router sein. Das hat einen Einfluss darauf, wie teuer das Ding ist. Ein Sinne von Batman-Hop-Count. Da muss es noch wissen, welche Interface gibt es. Da muss ich irgendwie sagen, irgendwo muss die Information herkommen. Bitte alle echten Netzwerkkarten zusammenknoten. Und da drauf zum Beispiel ein Transfer-Vilan. Was in diesem Falle zum Gateway geht, glaube ich. Die letzte Zeile kommen wir noch mal darauf zurück. Das ist Magie. Und über diese Magie wird es jetzt gehen. Genau, was hatte ich vorhin schon erzählt. Alle Systeme, die wir haben, sind per IP verbunden. Das heißt, per V6 sind sie auch alle public-available. Deswegen sollte man sich dann auch über Security ein bisschen Gedanken machen. Alles Point-to-Point-Verbindung, entweder über die Richtfunkstrecken oder zwei Geräten innerhalb eines Props. Also zum Beispiel der Backborn-Router oben auf dem Dach, zwei Switcher dazwischen, unten ein virtuelles Gateway. Und was nicht alles in derselben Stelle steht, alles OpenVPN-Tunnel. Was man sich mal angucken könnte, wäre WireGuard oder IPsec. Das soll ganz cool sein, das haben wir noch nicht gesehen. An größeren Props ein Layer2-Netz und alles per Bird miteinander verknotet. Das sieht dann so aus. Alles spricht OSPF miteinander. Darüber sind die Geräte untereinander schon mal erreichbar, wie man das so einem Service-Provider-Netzwerk bauen würde. Plus die Management-Netze. Pro Prop, wo wir sind, gibt es ein eindeutiges Management-Netz, wo dann die Switcher-Richtfunkstrecken noch Zeug alles drinhängt, Access Point zum Beispiel. Darüber gibt es ein IBGP, woüber dann die Default-Route kommt, verteilt wird, die wir von außen kriegen, vom Rheinland Backbone. Die Kleinnetze, die wir darüber verteilen. Und auch Anycasted Services dazu gleich noch mehr. Und ein bisschen Traffic Engineering, wo wir welchen Traffic eine lang schieben wollen. Wie baue ich mir jetzt mein SDN Passwords, die gerade so rumfliegen aufzugreifen? Debian kommt mit einem IfUpDown, was nur so mäßig automatisierbar ist. Die Konfig zu generieren ist relativ einfach. Das ist ja ein Stück Text. Das ist ziemlich klar strukturiert. Das kann ich irgendwie generieren. Das ist keine Herausforderung. Die Herausforderung ist, wie schreibe ich eine neue Konfig hin und mache dann, dass das, was ich neu konfiguriert habe, Realität wird. Es geht mit der Brechstange. Ich könnte sagen, Service-Networking-Restart, natürlich, ich habe ein Service-Impact. Das Ding ist einmal kurz offline. Das ist doof und aus Kamergründen nicht zumutbar. Das selber zu bauen ist nicht ganz so einfach. Weil ich wissen müsste, welche Interface gab es vorher. Die müsste ich dann runterfahren. Und welche muss ich jetzt hochfahren. Bei welchen hat sich welche Eigenschaft geändert? Das ist alles nicht ganz so einfach. Aber das hat netterweise schon mal jemand gemacht. Nämlich die Amis von Cumulus Networks. Die dasselbe Problem haben. Das ist dann eine sogenannten Open-Networking-Plattform. Das ist das Buzzword dazu. Das ist eine Debian-Dirivat. Basiert, glaube ich, auf Debian-Jesse aktuell. Das kann man auf Dell, Melanox und Brokehead-Switche, glaube ich, installieren. Und da gibt es IfUpDown2. Das ist in Python geschrieben. Ist relativ Überdeckungsgleich mit IfUpDown, aber nicht komplett. Von Hause aus kann das Ding schon mal dependency resolution. Das heißt, wenn ich ein Channel habe, so ein Bond über zwei Interfaces da drauf in WLAN und dann vielleicht noch schlimme Dingetour, weiß er in welcher Reihenfolge er die hochfährt. Also erst Physik, dann Bond, dann WLAN. Das hängt von einem normalen IfUpDown davon ab, in welcher Reihenfolge die in der Konfig stehen. Das heißt, das Problem habe ich jetzt nicht mehr. Ich kann die jetzt auch alphabetisch sortieren und finde ich es besser. Es gibt IfReload. Das macht genau das, was ich gerne hätte. LiesConfig, guckt die Realität an. Mach Realität gleich Konfiguration. Es kann auch WLAN Aware Bridges. Das haben die Jungs auch gebaut. Also auch im Linux Kernel selbst. Das gibt es ab 4, 4, glaube ich. Das heißt, eine normale Bridge in Linux weiß jetzt, was ein WLAN ist, wenn ich das aktiviere mit einem Eintrag im SysFS. Das heißt, auf einmal kann ich auf jedem Port filtern, welche Tag WLANs da rein und raus dürfen. Das ist relativ cremig für Hosting-Maschinen. Es kann VRFs. Was das ist, dazu gleich mehr und es kann auch noch WX-Laden. Dazu auch noch gleich mehr. Was es noch nicht kann, das ist ein bisschen bedauerlich, ist PPP-Interface. Mit normalem IfDown kann ich ja sagen Call Provider oder wie das Ding heißt und dann fährt der mir eine PPP-Session hoch. Das gibt es noch nicht. Das müsste mal wer bauen. Aber das ist ja per Preis ein leichter Erreicher, er weiter war. Und die Lühungs vom AppStream sind ziemlich kommunikativ. Wenn man mit denen ein bisschen mailt, geht den das auf den Keks und kann das Ding Batman-Interface konfigurieren. Das ist auch schon im AppStream und mittlerweile kann es auch Gräsit und IPIP-Tunnel konfigurieren. Das ist auch schon im AppStream-Branch. Es sind noch drei Pull-Requests offen für kleinere Bugs und ich glaube, einer wird noch kommen. Wir haben noch ein Thema mit MTUs. Aber das macht eigentlich Spaß, mit denen was zu bauen. Also wenn jemand Bock hat, das PPP zu bauen, machen. Damit kann man schon ganz schick anfangen, sich den Netzwerkteil zu automatisieren. Ich baue mir wie vorhin gezeigt meine Netzwerkkonfig im Pillar zusammen. Es gibt bei uns ein Python-Modul mit roundabout 1000 ish lines of code, was den STN-Teilen abbildet. Das heißt, das liest daraus Dinge ein, zum Beispiel die vorhin gesandten Rollen. Generiert dann Batman-Interface, generiert mit ein paar Stichworten noch zum Beispiel Breakout-Interface für, ich möchte gerne Mesh Online hier breakouten das was im Batman ist, Breakouten um es auf Access Points zu schieben in ein bestimmtes VLAN, das ist relativ vereinfacht. Es baut Konfigurationen für BERT wie soll so eine OSPF-Konfig aussehen mit welchen BGP-Neighbors möchte ich reden. Es baut OpenVPN-Interfaces und so weiter und so fort. All das könnt ihr klauen, das ist fertig. Da unten auf GitHub. Das haben wir schon. Damit haben wir jetzt eine Automatisierung und wir haben eine komplette geroutete Infrastruktur und wir haben jetzt noch eine DLS-Service. Ich glaube mittlerweile fast 70 Systemen, die wir so im Hochstift verteilt haben. Jetzt hätte ich gerne noch das meine Services, zum Beispiel so unwichtige Dinge wie DNS und NTP, primär DNS, dass die immer da sind. Weil ich per DHCP ja allen Handys, Laptops, was auch immer ein DNS-Server rausgebe und wenn der nicht da ist, werden Menschen sehr traurig, weil dann geht nichts mehr. Da gibt es sowas wie Anycast, dass ich selber Service-IP auf mehreren DNS-Servern habe und im Netz Announce und wenn der Dienst da läuft, dann sagt der Hallo hier, ich kann auch Anfragen beantworten und wenn nicht, dann nehme ich das Announcement weg. Das kann man auch relativ einfach bauen mit diesem Anycast Help Checker. Das habe ich gestern tatsächlich zum Fliegen gebracht. Das ist auch kein großes Hexenwerk. Das wird noch in unserem Sold-Ding auf GitHub aufpoppen. Da ist es noch nicht drin, bisher ist das per Hand gekraftet. Das wird irgendwie die, sondern nächste Woche wahrscheinlich kommen. Obacht, wenn man ICMP nutzen möchte, also heißt, wenn ich zum selben Ziel über verschiedene Wege kommen soll, dass der eine da lang, der andere da lang geschickt wird, mindestens Kernel 4.4 nutzen, ansonsten macht er das nicht flow-based, das heißt, eine Verbindung nimmt immer den selben Weg, sondern er macht Ron Robin. Das ist relativ doof, wenn ich eine Verbindung habe, die aus mehreren Paketen besteht, dann fällt die nämlich zwischendrin um. Aber dafür braucht man nun aktuellen Kernel, bis 4.9.18 in Backboard, Entschuldigung, der tut super. Traffic Engineering. Ich möchte, dass mein Traffic möglichst die kürzesten Wege nimmt. Das kann ich zum einen per OSPF steuern, über Kosten, oder ich kann noch ein bisschen zaubern. Dass ich zum Beispiel mein Layer 2 Netz, was ich im Batman habe, virtuell unterteile in die DHCP-Pools, die die Gateways haben. Und dafür sorge, dass der DHCP-Pool, den wir als prefix abbilden, als sub prefix, dass dieser ganze Traffic zu diesem Gateway direkt geroutet wird, weil üblicherweise anzunehmen ist, dass aus Batman-Shortest Pathsicht das wirklich der kürzeste Weg ist. So was haben wir zum Beispiel gebaut, und ich möchte, dass innerhalb des Batman sich wenig Quertreffekt habe. Das kann ich damit ja zumindest für V4 relativ leicht vermeiden. Für V6 bin ich da ziemlich in den Allerwertesten gekniffen, weil ich da keine greifbare Adressierung habe, wenn ich mehrere Gateways im selben Layer 2 Netz habe. Das gibt's auch schon fertig. Hatte vorhin schon kurz was von VRFs erzählt. Eigentlich rede ich hier über VRFs Light. Die Abkürzung steht für Virtual Routing in Forwarding Instance. Damit kann ich mehrere Layer 3 Netze trennen, quasi Schizophrenie in Routern, wenn man so möchte. Das braucht man als Service Provider üblicherweise, wenn man über seinen Backbone verschiedene Kunden transportiert, sprich eine Telekom, die, was weiß ich, Wato-Standorte verbindet oder alle Standorte von, was weiß ich, EDEC. Da gibt's was von Ratiofarben. Zum einen gibt es seit 1999, habe ich bei Recherchen festgestellt, Policy Routing, das ist uralt, das dürfte fast jede Freifahrung Community im Moment nutzen. Damit kann ich sagen, wenn über das Interface was reinkommt, wenn von der Source IP was reinkommt, dann schiebt das doch mal in diese Routing-Tabelle. Routing ist ja normalerweise nur abhängig vom Ziel, aber das möchte ich in diesem Falle nicht nur, sondern ich möchte gucken, wo kommt's denn her. Das hat aber relativ viel Fußschusspotenzial. Erstens, ich muss alle Rules, die ich baue für V4 und V6 bauen. Ich muss für alle Input-Interfaces gucken. Könnte ja sein, dass irgendwer sput, wenn ich das nicht irgendwo wegfiltere. Ich muss alle meine Source Prefixes checken. Ich brauche irgendwie ein Pipe-Protokoll im Bird. Das ist mit meinen ganzen Routen in beide Tabels schiebt, damit ich noch sinnvoll debuggen kann. Ich kann das nicht sinnvoll persistieren. Also es gibt für Policy Routing kein fertigen Persistenzmechanismus, der mir nach dem Reboot die ganzen Rules wiederherstellt. Das muss ich mir selbst zu Fuß bauen. Das aus Management sicht eigentlich eine Katastrophe. Das andere Extrem, was es auch schon länger gibt, seit 2008, 2009 meines Wissens, sind Network Namespaces. Das ist eine sehr harte Trennung. Da kann ich jetzt mehrere Namespaces bauen, die eigene Routing-Tabellen haben, die dann sogar eigenes Policy Routing erlauben, wenn ich möchte und die eigene Netfilterregeln habe und ein Netzwerk-Divis, also WLAN-Bond-Echte-Netzwerk-Karte kann ausschließlich in einem Network Namespace sein. Das ist schon ziemlich krass und das hat noch einen Nachteil. Die Prozesse Fast-D, Web-Server, Bird, was auch immer, müssen in diesem Network Namespace laufen. Das heißt, ich kann sie nicht mehr in beiden Bereichen laufen haben. Das ist so im Freifunk-Umfeld eigentlich zu vieles Guten. Aber, da gibt es seit Kernel 4.3, auch von den Cumulus-Jungs, jetzt das VRF Lights das ist basically ein geileres Policy Routing. Die Idee ist, ich baue mir ein virtuelles Interface, was ein VRF ist. Also es gibt noch einen neuen Interface-Type in diesen Kerneln, IP Link unterstützt das auch und knote meine echten Interface an dieses Interface dran. Also es ist quasi ein Master, wie physikalisches Interface hat als Master den Bond oder eine Bridge oder ähnliches. Und darüber baut mir der Kernel eine Policy Rule, wenn über dieses Master-Interface irgendwas reinkommt, dann gehen wir in diese Routing-Tabelle. Das heißt, ich habe in dem Moment auch nicht mehr das Loophole, dass wenn in dieser Routing-Tabelle was nicht gefunden wird, dann, wobei doch das Loophole habe ich noch, aber das habe ich es kein Problem, das erkläre ich gleich, warum das kein Problem ist. Das haben auch die Jungs gebaut, das kann seit, ich glaube seit 4.5 ist das wirklich brauchbar, ich würde aber 4.9 nehmen. Also das ist in mehreren Schichten gekommen, das ist ein Tag fixes, weil schlimme Dinge und überhaupt. Da würde ich einfach den Aktuellstenkönne nehmen, damit läuft das ziemlich cremig. Hier sind ein paar Links zu Blockartikeln drin, wo man nachlesen kann, was die sich dabei gedacht haben und warum das eine coole Idee ist. Wer das lesen möchte, dem kann ich das nur höchst empfehlen. Sieht in der Realität so aus, ich baue mir wie gerade gesagt dieses Interface vom Typ VRF und setze das dann als Master Device für irgendeine echte Netzwerkkarte. Im Gegensatz zu Policy Routing wandert in dem Moment, wo ich den zweiten Befehl absetze, die Device-Route für das Prefix auf dem echten Interface in die andere Routing-Tabelle die mit dieser Table ID, wo es ist, die in dieser, wandert dann in diese Routing-Table. Das passiert bei normalen Policy Routing ja nicht. Das heißt, hiermit habe ich wirklich eine harte Segmentierung, da kann also nicht mehr viel schiefgehen. Das sieht dann in ETC Network Interfaces so aus, was relativ einfach ist. Ich habe eine Netzwerkkarte. Netterweise kann ich hier alle IPs hintereinander hinschreiben. Ich brauche nicht mehr mehrere Blöcke dafür. Schreibe meine beiden Gateways dahinten und sage, welche VRF ist das. Definiere die unten aus dem Aus. Damit habe ich jetzt meine externe Netzwerkkarte vom Internet getrennt und wenn ich keine Clim-Züge mache, gibt es dazwischen keinen Weg mehr hin und her. Das ist für diese ganzen Gateways ziemlich nett. Das heißt, ich möchte ja FastD-Einwahl haben, dafür brauche ich eine öffentliche IP. Dafür nutzen wir das jetzt und für ein paar Web-Server. Das heißt, das sieht jetzt so aus. Früher hatte man ja in der Hauptrouting-Tabelle das öffentliche Netz und in üblicherweise RoutingTable 42, wenn wir alle vom selben geklaut haben, das Freifunknetz. Genau das haben wir jetzt umgedreht. Das heißt, wenn ich nichts tue, bin ich im internen Freifunknetz und der einzige Exit, den ich habe, sind die drei oder vier Exitpoints Richtung Rheinland-Backbone, die wir betreiben. Das heißt, ich kann genau steuern, wo mein Treffig rausgeht und es passieren keine schlimmen Dinge. Wenn ich lokal rausgehen möchte, muss ich das explizit angeben. Das heißt, in meiner Haupt-VRF fahre ich mein dynamisches Routing, bauen wir mein Netz zusammen und kann da ganz normal das Netz debaggen mit Standard-Tools ohne irgendwelche Climzüge machen zu müssen. Also sprich Ping, Trace-Route, MTR und ähnliches funktioniert wunderbar. Möglicherweise habe ich auf so ein paar Kisten eine externe VRF. Darüber möchte ich natürlich meine Gretunnel zum Backbone abbilden. Darüber möchte ich meine OpenVPN-Verbindung abbilden und meine FastD-Einwahl und vielleicht noch ein paar eigene Services, die öffentlich erreichbar sein müssen. DNS, Web-Server Mail-Server und so Zeug. Das heißt, möglicherweise möchte ich jetzt aber auch, dass sich zwei VRFs unterhalten können. Also mein Internet ist Freifunknetz mit meiner externen, weil ich nicht möchte, dass meine Kommunikation, wenn jemand aus dem Freifunk auf unsere Webseite geht, macht jetzt keinen Sinn, dass ich das einmal durchs Rheinland-Backbone, durchs Internet schleife, dann kommt es wieder zu mir Ich habe gesagt, das ist relativ kompliziert. Also man muss das explizit wollen. Dafür braucht es ein virtuelles Netzwerk-Kabel in diesem Linux. Das nennt sich ein VETH-0-Paar. Das kann ich einfach als Device es anlegen, stecke ein Ende in meinen Haupt-VRF 1 in die externe, pack mir da IPs drauf und im Zweifelsfall spricht der Rechner der WGP mit sich selbst und das Netz wird überall ernaut. Sieht ungefähr so aus. Also ich leg mir so ein Interface-Paar an, sage, wie beide Enden heißen sollen und kann dann diese Interface ganz normal konfigurieren. Und ein davon muss ich dann noch mit Setmaster in die andere VRF stecken. Auf einmal habe ich eine Verbindung zwischen den beiden Dingen und kann sinnvoll per Firewall und per Routen, die ich austausche gucken, was soll von Wohnnachbohr gehen dürfen. Das mache ich für Dienste. Ich habe gerade schon gesagt, SSH soll möglicherweise erreichbar sein, eigener Git-Server zum Beispiel oder eigener Web-Server. Wenn ich da keine Climzüge für tue und meine VRF hat, kriege ich von außen die Anfragepakete an den Dienst, zum Beispiel an SSH. Der weiß es aber nicht besser und schickt sie über meine normale Standard-VRF wieder raus. Das heißt, ich schicke an die offizielle IP, der denkt, okay, muss wieder raus, meine Default-Route geht über das normale Freifunknetz raus, das wird genattet und der Kleint, der die Antwort kriegt, denkt, das ist nicht für mich, das habe ich nicht rausgeschickt. Dafür gibt es aber auch was von Radiofarmen, nämlich unten genannte SUS-CTLs. Für TCP gibt es das schon länger, das ist ziemlich super. Da kann ich sagen, wenn so ein Paket reinkommt, dann schreibt da doch mal dran, über welches Interface das reingekommen ist und sagt, das ist der Applikation. Ziemlich merkt ihr das im Kernel irgendwo und abhängig von diesem Interface wird die Routing-Entscheidung getroffen. Auf einmal kann ich dann auch auf die externe IP SSH oder auf den Web-Server zugreifen oder sonst was tun. Mit DNS ist das nicht ganz so einfach, weil UDP, das gibt jetzt seit Kernel 4.11 und da habe ich noch ein Thema mit. Ansonsten muss man Applikationen patchen, das ist aber auch kein Drama. Wir haben viel OpenVPN im Einsatz. Ich möchte natürlich, dass das über das Internet-Facing-Interface den Tunnel aufbaut, aber das, was im Tunnel passiert, soll bitte im Internet bleiben. Das heißt, ich muss OpenVPN dazu kriegen, seine Kommunikation in das externe Netz zu verschieben. Das war ein relativ kleiner Patch. Ich muss noch ein paar Leute motivieren, dass das mal aufgenommen wird. Da werde ich gerade mit was Anderem erpresst, was ich vorher machen muss. Funktioniert aber in unserem APT-Legen-Pakete, die das können. Ich sprach von DNS. Mit einem Bein kriege ich das nicht hin. Mit dem Standard-Sys-CTL. Was man machen kann, ist da wieder Policy-Routing dazu nehmen. Basically ist das ganze VRF-Thema ja nur Policy-Routing und Steroids. Das heißt, wenn ich mir eine Regel mache, wenn von der externen IP was rausgeschickt wird, dann gehen wir bitte auch in diese Routing-Tabelle. Ich habe noch DNS. Ich hatte mir trotzdem noch DNS-Dist angeguckt, weil ich auf einem Riot-Meeting mich mit einem der Power-DNS-Entwickler unterhalten hatte. Der meinte, die müssten das aber können. Gestern Abend um acht schrieb ich denen, nee, ihr könnt das doch nicht. Dann 2,5 Stunden später oder knapp 3 Stunden später war der Patch da, der macht, dass das geht. Das fand ich schon ziemlich geil. Dann habe ich mir mal gedacht, na komm, ihr baut doch immer Pakete von eurem Gitmaster-Branch. Aber 10 Minuten später hatte ich ein Paket, was dann mit diesem Commit gebaut wurde. Ich habe es leider noch nicht getestet. Fragt mich morgen. Ich bin aber sicher, selbst wenn es nicht geht, 2 Stunden später geht es. Nächster Punkt, PPPD. An manchen Standorten haben wir DSL. Irgendwer kauft dann lokal mal eine DSL-Leitung für Redundanz oder mal als Breakout Richtung Backbone in der City haben wir zum Beispiel die Werbegemeinschaft Respektive 1 der Mitglieder finanziert aktuell, glaube ich, 50 Szene Anschluss, über den wir Großteil des Traffics aus der City ausleiten. Da habe ich dasselbe Problem. Die PPP-Session möchte bitte in der X10 VRF laufen. Das heißt, wenn da irgendetwas reinkommt, ist ja eine offizielle IP. Dann soll das bitte auch da bleiben. Das denkt man sich, na ja gut. So ein PPPD hat ja so eine IP-Upscript. Da kann man ja, wenn die Verbindung steht, Dinge tun und einfach mal sagen, die Kuchen geht leider nicht. Ein bisschen im C-Code rumgestocht hat, dräuft sich Stellen gefunden, wo ich glaubte, dass das hilft, half auch nicht. Aber man kann da was bauen. In dem Post-Upscript setzt man sich einfach ein AT-Kommando auf ein anderes Skript ab, was man sofort startet, das liebt irgendwie 10 Sekunden, ruft noch ein anderes generiertes Skript auf und setzt dann das Master-Interface. Ist nicht schön, aber funktioniert. Wenn jemand Langeweile hat und durch alten C-Code durchsteigen möchte, und der Gefühl 10 Jahre nicht mehr angeguckt wurde, ist das auch noch eine dankbare Aufgabe. So, jetzt haben wir Automatisierung, haben unsere Services ausfallsicher, Dank Anycast und haben unser Routing auch so, dass da eigentlich nichts mehr schief laufen kann. Jetzt haben wir noch dieses Batman-Problem. Das braucht ja, wie schon mal erzählt, Layer 2. Was ja auch in der City ganz cool ist, dass ich überall dieselbe Layer 2-Domainer hab. Wenn ich also mit meinem Handy durch die einkaufen Meile der Stadt flaniere und dann einfach mal von einem Access Point zum anderen hoppe, dann fall ich nicht aus dem Wlan raus, sondern bin die ganze Zeit online. Das ist ja eigentlich ganz charmant. Das unterscheidet Freifahrung zum Beispiel von diesen ganzen Hotspot-Anbietern. Die kriegen das nämlich nicht hin. Das finde ich eigentlich ein ganz cooles Argument. Das Layer 2-Teil habe ich durch Batman ja schon gelöst. Ich muss also nur machen, dass meine ganzen Router auf dem Weg, die alle Batman-Sprechen im selben Layer 2-Net sind, ohne mir dazwischen überall Tausende von Wlan zu klicken. Da wollten wir mal hin. Da sind wir auch relativ weit, das aufzubauen. Also City of Paderborn mit einigen Richtfunkstandorten innerer und äußerer Ring sozusagen. Und das ist aktuell noch alles eines Zeit, aber an einigen dieser Punkte wird es noch Breakouts geben in umliegende Dörfer. Das heißt, da brauche ich mehrere Instanzen drüber. Also hier könnte ich vielleicht noch mit einem Wlan durchkommen, aber ich bräuchte wieder pro Strecke 2 für IP und Batman und so weiter, und das skaliert irgendwie alles nicht. Und so ein Service-Provider macht ja eigentlich auch nichts anderes. Also wenn ich mir so ein Telekom-Netz angucke aus derselben Höhe, dann ist das eigentlich ein großer IP-Backbone und ein bisschen Magie oben drüber, dass man alles mögliche transportieren kann. Telefon mittlerweile auch. Zum Beispiel, dass ich alle Standorte von irgendwelchen Firmen darüber verbinden kann. Das ist ja letztlich nichts anderes, was ich hier auch tun möchte. Also greift man doch diese Idee mal auf. Standardansatz eines Netzwerkers, wäre ich Nebaumäder, was mit MPLS. Das ist mit Linux jetzt noch nicht ganz so einfach. Der Großteil davon ist schon da. Also die Forwarding-Plane müsste jetzt im Kernel komplett da sein. Das heißt, ich kann mir das manuell zusammenzimmern. Aber der ganze Flausch drumherum ist noch nicht da. Es hat noch keiner gebaut. Aber was es gibt, ist wie X-Lan. Das ist quasi, ich packe Ethernet-Frames in UDP-Pakete ein. Auf einmal kann ich es wieder per IP transportieren. Man könnte auch sagen, pure man's approach to MPLS. Die Idee ist nämlich eigentlich dieselbe. Gedacht ist das für Datacenter. Da gibt es ja das aktuelle Buzzword IP Fabric. Das ist ja eigentlich dieselbe Idee. Ich baue mir nur ein IP-Netz, weil damit viele Dinge sehr schön automatisch gehen. Und darüber muss ich leider Layer 2 transportieren, weil die üblichen Serverdienste und Anwendung und Ähnliches erwarten, dass sie in einem großen Netz sind. Das mache ich mir einfach zu Nutze. Wenn ich jetzt dafür sorgen möchte, dass ich eine große Layer 2-Domain habe, muss ich irgendwie Multicast-Routing anstatt kriegen. Aber das will ich eigentlich gar nicht. Das wird ja nur zwei Punkte verbinden. Also Backbone-Router hier, bis hin Richtung Backbone-Router 2. Das ist unter Liehnung auch kein großer Akt. Das Schweizer Netzwerker-Taschenmesser-IP hilft da auch. Das heißt, ich lege mir so ein Ding an, schreibe da eine ID dran, sage vielleicht noch, über welches Interface soll das rausgehen. Soll es eine Point-to-Point-Verbindung zwischen zwei Geräten sein, also Unicast-Verbindung oder soll es Multicast sein? Von von Lächeradresse aus los und Abfahrt. Das sieht mit if-up-down dann so aus. Das heißt, ich schreibe da eine ID dran. Ich sage ihm über welches Interface. Wir haben vorhin schon mal dieses WLAN 1001 gesehen. Es steht dann eine Multicast-Adresse. Das ist einfacher für mich, es zu bauen. Also das sind jetzt zwei Geräte, Backbone-Router und am Dach, Gateway unten, die miteinander mit Menschen sprechen sollen, damit über den Backbone-Router es dann Richtung Richtfunk gehen kann. Multicast ist deswegen einfacher, weil ich auf beiden Seiten einfach die selbe IP generieren kann, aus dem Wissen, was ich habe. Wenn man sich das mal scharf anguckt, dann sieht man fest, dass hier 10.2 aussieht, wie das da oben, die Null fällt nur einfach weg. Das heißt, WLAN-ID in der Mitte durchschneiden, erste Hälfte, zweite Hälfte. Das da hinten ist die Side, das fällt aus dieser Information hier raus. Wenn man sich die MAC-Adresse hier unten anguckt, sieht die genauso aus, 10.002. Und hier die Side, das ist jetzt zufällig nur umgedreht. Das da vorne, 00C1, ist die Loopback-ID oder IP von dem Gerät. Es müsste 193 sein. Wer gut in Matte ist, kann sich ausrechnen, dass das da, das da, das da, in einfach mal zusammen ausgerechnet, mit jeweils mal 256, genau dasselbe ist, wieder um. Das generiert man sich alles einfach. Das kann man auf beiden Seiten genauso generieren, weil Side ist gleich, Underlay Interface ist gleich. Und auf einmal habe ich das fertig. Wer gut aufgepasst hat, sieht, dass hier eine ziemlich große MTU steht. Ich muss natürlich jetzt mein Batman irgendwie einpacken. Das heißt, auf dem Kabel habe ich nachher das da. Ich habe einen ziemlich großen Stapel an Ding. Ich habe oben das IP, was man auf dem Handy im Freifunknetz nutzt. Ich packe das in Batman ein. Das ist ja quasi Gott gegeben. Ich packe das jetzt wieder ein in WX LAN. Das packe man ein in UDP respektive IP, transportiere das noch über ein WLAN und dann übers Kabel. Das heißt, am Ende des Tages bin ich bei 1628, was ich übers Kabel schiebe. Macht aber nichts. Die üblichen Zwitsche können das. Bei TP-Link muss ich es nicht mal konfigurieren, bei Cisco muss ich es einmal konfigurieren und das Ding dann durchbuten. Bei Netonics muss ich es pro Port einmal reinklimpern. Ich glaube, mehr haben wir nicht mehr, ne? Dann habe ich das fertig. Achtung, große Falle. Wenn man das irgendwo vergisst, hat man ein schwarzes Loch. Weil es keine Methode auf Layer 2 gibt, die sagt, hallo, dein Paket ist zu groß. Und mit IfUpDown kann man sich das auch sehr schön pro Interface setzen. Da unten ist der Link zu unserem SDN-Controller sozusagen. Da ist die Magie drin, die dafür sorgt, dass die Interface jeweils die richtige MTU kriegen. Damit haben wir das. Was haben wir dabei noch so alles gelernt? Offloading ist ein Thema voller Missverständnisse. Eigentlich würde man sich erwünschen, dass wenn man jetzt Daten durch die Gegend schiebt, das möglichst viel in Hardware passiert, weil die normale CPU sich nicht damit beschäftigen muss. Also CheckZoom-Offloading für Pakete, die ankommen, verifizieren oder CheckZoom-Bauen, wenn ich Pakete raus schicke, oder, oder, oder. Das macht aber nicht so richtig viel Spaß. Der Unterschied zwischen offloading an und offloading aus ist 4 Kilobyte pro Sekunde mit an und 40 Megabyte pro Sekunde mit aus. Warum ist mir eigentlich auch nicht so ganz klar, aber wenn ich Pakete durch ein Linux-System transportiere, also kommt an und er schickt es weiter, funktioniert offloading in den meisten Fällen eher als harte Bremse. Das ist wohl dafür gebaut in den meisten Implementierungen, dass ein Server Pakete annimmt und nur raus schickt, aber sie nicht durch Route drespektive vorwordet. Filtert. BCP38 wäre das Stichwort. Also an allen Stellen, wo man Nutzer-Traffic annimmt, gucken, ob die richtigen, ob das die richtigen IPs für das Netz sind und alles andere wegschmeißen, also kein Spoofing erlauben. Nehmt aktuelle Kernel. In den vorherigen sind Dinge entweder noch nicht funktional oder kaputt. Kernel 4647 haben irgendwie Schmerzen mit IPv6, Routing und VRFs, das ist irgendwie subtil kaputt. Mir ist nicht ganz klar, warum, ob ein Alten geht. Kernel 48 hat Probleme mit Bridges und Batman. Wenn man da aktueller nimmt, dann weint es deutlich weniger. Und IPv6 und Fragmentation ist da auch so ein Thema. Das heißt, da kann es auch schon mal sein, dass die Box umfällt, wenn da passend fragmentierte IPv6-Pakete reinkommen. Genau. Das möchte man irgendwo unterbringen, um die wichtigen Offloading-Themen auszuschalten. Scattergatherlist, Receive, Offload und so weiter und so fort. Auf einmal wird es dann schnell. SystemD ist auch ein Quell der Freude. Wenn man OpenVPN nutzt und 10, 15 Tunnel parallel hochfährt, macht SystemD das ja in Wortwahl oder wirklich in Parallel. Das heißt, ich habe mir jetzt gedacht, na komm, wir generieren diese ganzen Interfaces und IPs für die Tunnel, auch einfach in Network-Interfaces und fahren die mit if-up hoch. Das triggert leider einen füchterlichen Locking-Buck in if-up-down-2. Wenn ich das Ding 2-, 3-mal parallel starte, habe nachher kein Interface mehr irgendeiner IP. Das heißt, man muss dann ein bisschen Locking-Flausch drum rumlöten und auf einmal geht das dann auch. Burt161, vor knappem Jahr würde ich mal tippen, hatte auch so leider einen kleinen Buck. Da hatten wir noch das alte Setup mit Policy-Routing und zwei Tabellen und ein Pipe-Protokoll im Burt, das die in Sync hält. Wenn man mehr als, ich glaube, 100 Routen ungefähr durch das Pipe-Protokoll schickt, segfoltete das Ding irgendwie ziemlich deterministisch. Damals hatten wir erstens noch unattended Upgrades an, unter anderem für Burt. Das heißt, eines Morgens kommt man um 9 Uhr ins Büro und stellt fest, die Weathermap ist überall grau. Da geht kein einziges Byte mehr durch. Das ist eher doof. Na gut, dann macht man unattended Upgrades aus. Respektive packt Burt in die Blacklist davon. Das heißt, nicht aktualisiert und freut sich das Lebens und hat nach 20 Hosts das Burt wieder down-gegraded und alles läuft wieder. Jetzt kommt man am nächsten Morgen wieder ins Büro und stellt fest, scheiße, die Weathermap ist schon wieder grau. Warum? Im Salt stand drin Package.latest. Das heißt, Salt hat in der Nacht das Burt-Paket nochmal aktualisiert. Das haben wir dann auch ausgemacht. Und damit war dann Freifunk bei uns zweimal aus. Ups. Also man sollte sich überlegen, wo man automatisierte Upgrades dann vielleicht noch macht. Attended Upgrades haben wir immer noch an. Das hat uns seitdem auch nie wieder gebissen, aber Burt habe ich immer noch geblacklisted aus Gründen. APU 2B, also Revision 2B, hat leider auch so ein Thema. Wenn man die rebooted, kann es sein, dass sie beim Reboot hängen bleibt. Sprich, das Ding fährt runter und bleibt dann irgendwo im Bios oder in irgendeiner Initialisierung hängen. Alle Ports gehen auf 100 Ambit und er kommt nicht wieder. Spannenderweise habe ich jetzt festgestellt, da die Remote-Hands nicht gegriffen haben, nach einer Woche kommt er wieder, ziemlich genau. Ist aber auch eher doof. Das Advisory würde wahrscheinlich ungefähr so laut wieder steht. Da kann man sich aber auch so ein bisschen helfen, dass man zumindest noch an die Managementnetze dran kommt. Die Idee ist, dass an jeder Pop ein eigenes Managementnetz hat. Wenn ich dann Router habe, sprich, die APU, dann kann die das auch roten, verteilt das per OSPF. Ich komme also von überall aus dran. Es sei denn die APU ist kaputt. Vielleicht möchte ich aber dann trotzdem an irgendeine Richtfunkschüssel, die an diesem Standort ist, dran kommen. Also exportiere ich mir einfach das Managementnetz über die VLAN-Strecken. Und kann es mir von außen dann nochmal greifen. Hilft, hat uns zweimal den Hintergrund gerettet. Sieht dann ungefähr so aus. Das ist eine Nanobeme, Powerbeam, glaube ich. Das heißt, ich brauche einmal das Management-VLAN, die ich mir bauen muss, die Interface. Packe die normalen Interface in eine normale Bridge. Das heißt, alle VLANs, die man da so durchschiebt, gehen dadurch. Denke auch dran, dieser Bridge eine hohe MTU zu geben. Sonst habe ich den schwarzen Loch gebaut. Aller spätestens wenn Batman kommt. Und baue mir eine zweite Bridge, die das Management-VLAN transportiert. Das wird nämlich sonst rausgefiltert. Das heißt, in dem Moment kann ich jetzt von einem anderen Standort mir das Managementnetz konfigurieren zu Fuß, wenn ich es brauche und habe nochmal eine Backdoor und kann dann Dinge tun. Das hilft. Wo sind wir mittlerweile? Haben über 60 Systeme am Start. Großteils mittlerweile Hardware in der Stadt, aber auch einen ganzen Stapel WMs. DNS-Server, Gateways, Mail-Server, Monitoring, sprich Libre NMS plus Ashinger 2. Das macht sehr viel Freude. Haben Server auch in Deutschland verteilt. Zwei davon stehen netterweise in Paderborn und haben eine Richtfunkanbindung an das ganze Richtfunkbackbone. Das ist ziemlich nett. Das sind auch per Richtfunk miteinander verbunden. Einer steht in Berlin, weil es da eine Option gab, günstig Blech unterzustellen und wo Traffic keine Rolle spielt. Das heißt, der hängt per VPN immer im Netz und das Monitoring Duo, Libre NMS und Ashinger 2 nüllt, wenn was kaputt ist und mal lustige Grafen, wo wie viel Traffic durch die Gegend fließt. Das spricht eine schöne Weathermap, plus halt die normalen Grafen, wie viel wir durch die Gegend schieben. Aktuell sind wir bei 240 MBit üblicherweise jeden Abend. Da wird wahrscheinlich bald noch ein bisschen mehr passieren. Wir bauen noch ein paar Standorte aus. Einer fehlt noch. Korrigiere mich mein Kompagnon. Der 30 Meter hohe Turm fehlt noch. Ein Steiger für den E2 fehlt noch. Und das ähnlich hohe Kreishaus, was ich auch angeboten hat, fehlt auch noch. Dann sind wir relativ nah an dem dran, was ich vorhin als Planungskarte gezeigt habe. Eine Verbindung hat sich als geht nicht erwiesen. Ich hoffe, der Rest funktioniert dann besser. Also bauen wir im Weg und so schlimme Dinge. Was machen wir mittlerweile an Hardware? Wir hatten am Anfang einen ziemlich großen Zoo aus gesponsortem Zeug. Alte Richtfunk-Antennen, die glaube ich zu 10, 20, 30 Stück vom Laster gefallen sind. Weil der alte Provider sie nicht mehr wollte und ersetzt hat. Mittlerweile wollen wir sie auch nicht mehr. Und versuchen das zu homogenisieren oder haben das zu 95 plus Prozent homogenisiert auf nur noch Abhus als Richtfunk oder als Backbone-Router. Alle Switche sind mittlerweile von der Tonics. Das heißt, auch da ist alles gleich. Das funktioniert auch ziemlich super. Die Dinger sind ganz lustig. Die kommen in der Packung. Da ist ein Dienerviertzettel, wo draufsteht. Es tut ihnen leid, dass sie keine Zeit hatten, ein Doku zu bauen. Sie haben lieber Zeit ins Engineering gesteckt. Aber man wird wohl klarkommen. Das stimmt aber auch. Wenn man weiß, was ein WLAN und was ein Lack ist, dann nimmt man das Web-Interface, konfiguriert sich das zusammen und braucht keine Doku. CLI ist aber eher so mittel. Und von UBNT haben wir eine ganze Menge Zeug. Power Beams mittlerweile. Da drehen die hier, sitzt da unter einer 300er. Davon haben wir mittlerweile 10 oder 20 Stück verbaut in der City für kürzere Strecken. Nehmen die 500er für längere Strecken, schieben da üblicherweise so um die 300 Mbit durch, also können da durch. So viel Traffic haben wir noch nicht. Nutzen Light Beams, dazu gleich noch mehr. Und die AC Mesh Pro, die neuen, haben wir jetzt eine Hand voll schon verbaut als Access Points selber. Die fahren wir mit Stockfirmen, weil es einfach besser funktioniert. Und weil 5 Gigahertz damit geht. Das Zeug verwalten wir zentral mit einem Unify. Ich hatte jetzt mit Aufschreien wegen zentralistischer Kackscheiße gerechnet. Das funktioniert aber auch ziemlich gut. Also das Zeug von UBNT dreht in Summe eigentlich ganz gut, wenn man es alles so zusammensteckt, wie Sie das vorstellen. Das heißt, die Access Points, die wir überall haben, hängen im jeweiligen Management Netz, kann man unten nach den IP-Adressen sehen, pro Standort ein eigenes Slash 24. Und haben da auch mittlerweile 2-3 Hand voll, die wir so betreiben und zentral darüber konfigurieren, sprich zentrale SSIDs pro wie eine eigene. Mit welchem WLAN gehört dazu und machen darüber Firmenware Updates und ähnliches. Das funktioniert ganz super, das kann ich eben nur empfehlen. Dann haben wir uns was überlegt, um aus dem 5 Gigahertz Problem rauszukommen, nämlich Pump. Premium Ultra Mesh Plus nennt sich das. Das Problem ist, dass ich auch 5 Gigahertz der DFS zwingend brauche, wenn ich mich an den Standard halten will. Was aber mit einem Linux Access Point so nicht geht. Es ist nicht zertifiziert und oder keiner hat es gebaut. Ich glaube, es ist ein Zertifizierungsproblem. Das heißt, einen normalen 5 Gigahertz Access Point nehmen, sei es jetzt irgendwie so ein kleines Gerät, was ich mir auf dem Tisch stelle oder was, was ich eine Wand schraube, wie so ein Mesh Pro zum Beispiel und dann Gluren drauf tun, fällt aus. Also es gibt keine Firmenware, die das kann, respektive Darf. Jetzt möchte ich aber vielleicht trotzdem 5 Gigahertz nehmen zum Meshen, weil einfach weniger los ist in der Luft und unser Fix dafür ist, man nehme zum Beispiel so ein 120 Grad Sektor von UBNT, schraub den irgendwo an Masten, fahre den mit Stock Firmenware, mache da ein Access Point drauf, einen offenen. Jemand, der lustig ist und sich da dran hängen will, kauft sich einen 5 Gigahertz AC irgendwas, sei es jetzt Nano, Beam, Light Beam, was auch immer, also zum Beispiel das Light Beam Gegenstück, konfiguriert sich den als Stock Client, macht das Ding in Bridge Modus, will und macht Mesh und Lahn an. Aus die Maus. Also ist ein bisschen Hardware-Schlacht, aber löst das Problem legal und funktional. Das haben wir noch nicht getestet, weil wir seit 3, 4 Monaten darauf warten, dass Varia Store uns mal diese ganzen Light Beams liefert, die das Land schon bezahlt hat. Sie sollen jetzt im Gestern. Okay, Sie hätten gestern kommen sollen. Ja, wie sieht das dann so aus? Das ist zum Beispiel eine Standort in der City, die zwei Jungs sind auch immer dabei, mindestens einer. Unten sieht man die APU, oben so ein Switch, schön eingebauten Search Protektoren und Strippen, die aufs Dach gehen. Das ist jetzt irgendwo unter das Dach geschraubt, in dem Gebäude wird bald eher abgerissen wird, ich hoffe erst später. Paderhalle, die Stadthalle in Paderborn, links, vorher, rechts, hinterher. Also wir machen da schon so ein bisschen da auch da wurden die Kabel gezogen vom Gebäudemanagement der Stadt. Das heißt, die haben die Pinne aus Dach geschraubt und uns die Strippen gezogen und das Kabel gekauft. Das heißt, das Einzige, was wir noch machen mussten, ist den Schrank der Antiband dübeln, schön alles auflegen, APU reinsetzen, Switch reinsetzen, konfigurieren, Richtfunkstrecken anmachen und nach Hause gehen. Hat aber trotzdem den ganzen Tag gedauert. Und am selben Abend haben wir dann auch noch eine Schule aufgebaut, bisher nur eine Strecke, mittlerweile auch zu. Wo dann genau das selber aussieht. Also sprich, das ist so das Setup, was wir einfach von der Stange nehmen, wo wir uns letztes Jahr 33.400 Euro vom Land für beantragt haben. Das wollen wir tun, mit der Hardware wollen wir das tun, ungefähr das und das wird's kosten und wir haben alles bis auf 5 Euro ausgegeben. Es gibt den NRW seit 2015 nach einem Landtagsbeschluss den Initial die Piraten eingestielt haben und Rot-Grün das eine geile Idee befand und dann das nochmal neu aufgesetzt hat. 100.000 pro Jahr 2015 und seit 2016 150.000 pro Jahr Budget für Freifunk. Das heißt, man muss einen schicken Antrag schreiben und kriegt dann Kohle. Der natürlich zweckgebunden muss das alles ausgegeben werden. Diesen Skill haben wir mittlerweile so ein bisschen gelebbelt, würde ich glaube ich mal ganz kreis behaupten wollen und haben jetzt ziemlich viel cooles Werkzeug, seitdem macht das echt Spaß aufzubauen. Haben uns einen Stapel Switcher, Router, Panels, Kabel und Gelöt gekauft, das heißt wir gehen da jetzt hin mit einem Autofollzeug, also das links ist wirklich nur der Standort. Das einzige was wir davon wieder mitgenommen haben war der 19 Zoll Schrank und das Innenleben dafür, weil es nicht hingepasst hat und haben mal stattdessen den Schallschrank da aufgebaut. Da sind 4 Antennen jetzt auf dem Dach Search Protektoren und so weiter und so fort. Damit macht das dann Spaß, also das ist jetzt ein Zoll Schrank Enterprise, das ist wenn man so möchte, aber alles mit noch mit der Freifunk Idee und viel dabei gelernt. Und wenn man abends auf dem Dach steht unter die City guckt, dann ist das schon alles sehr romantisch finde ich. Was haben wir noch vor? Die APUS haben ja so ein paar Themen, also wie vorhin gesagt, zum Beispiel die Alten haben das Reboot Problem, die 4C übrigens nicht mehr, zumindest hat es uns bisher nicht gebissen, glaube ich. Da hätten wir gerne noch Serial Online und dann haben wir das mit der Direktor Hack, kann man ja zumindest noch an die serielle Konsole. Da mir das noch nie passiert ist, wenn ich so ein Ding vor mir liegen hatte, weiß ich nicht, ob das die Welt rettet oder ob das einfach nur nettes Feature ist. Ich hoffe, es würde die Welt retten. Die Idee ist auf den ganzen Access Points, die wir zentral im UniFi haben, noch ein Management Netz aufzubauen, also sprich das Management Netz, was an dem Standort E ist, mit einer WPA2 alles tun kann. Dann arbeite ich noch an einem Proposal Respektive V2 dafür fürs RIPE, dass wir auch PI Space kriegen, aktuell ist das für Freifunkern nicht erlaubt, wegen Auslegung der Policy, ich hoffe, das ändert sich bald. Takt hat vorhin einiges erzählt zu T-Flow 2, das hätte ich gerne noch am Start plus ein AS-Statz immer so zu sehen, was geht denn so hier eigentlich, also wer redet mit wem, mit welchen Gegenstellen reden Menschen denn so, ich würde erwarten, dass da so Leute aber fände ich einfach mal spannend und bestimmt fallen uns noch viele Dinge ein. Ich stelle fest, ich bin deutlich schneller als ich eigentlich dachte, dann kämen wir jetzt zu Fragen oder Anmerkungen. Wie testen wir Änderungen am Salt? Wie war das so schön? I didn't always test my code, but when I do I do it in production. Erstens Salt Run mit Test gleich true, das heißt, ich lasse mir erst mal anzeigen, was passiert denn hier, also krieg ich ein diff der und dann tue ich das manuell auf einzelnen Kisten. Und wenn sie also sinnvollerweise eine Kiste, die irgendwie auch mal explodieren darf oder wo ich irgendwie Remote Hands habe oder hinlaufen kann und sie dagegen treten kann. Das sind aber eigentlich keine so großen Änderungen mehr, dass mir das vor die Füße fallen sollte, TM. Es sind halt mal Netzwerkänderungen oder man fährt mal ein Interface runter und dann explodiert das Batman und die Kiste steht, da haben wir gerade wenn wir jetzt zum Beispiel haben Batman fährt in einem WX-Lan, darunter ist ein V-Lan ich mache das V-Lan einfach aus dann kann es durchaus schon mal sein, dass es eine Explosion im Kernel gibt und das Batman meint, nee jetzt nicht mehr, dann hilft nur noch Strom aus Strom an. Aber ansonsten The Handle with Care. Es ist aktuell noch nicht wieder an mit dem ersten Salt hatten wir das schon, dass jede Nacht einmal ein High State ausgerollt wird, also sprich die komplette Konfig einer Kiste neu geschrieben wird, die halt ändern müsste. Das haben wir noch nicht wieder an, weil es noch so ein bisschen in Development ist. Das meiste Zeug ist ziemlich fertig, es funktioniert auch alles. Aber man müsste jetzt der Reihe nach mal diese 60 Systeme durchgehen und gucken sind sie denn alle zu 100% kompatibel? Das ist halt alles nur ein Freifunk, ja das ist alles nur ein Freizeitprojekt, das ist manchmal schon ziemlich deckungsgleich diese zwei Worte. Das heißt, es ist nicht alles 100% State of the Art, aber wir arbeiten dran. Nachher auf Slideshare wahrscheinlich, also irgendwo werden sie verlinkt. Sonst mal fragen? Der Grund für das VXLAN ist, dass die nicht auf den VLAN-Beutel geblieben sind, sondern für die Bohnen. Der Grund für das VXLAN ist, dass sich ja sonst zwischen zwei Backbohnen-Routern auf den Zwitschern, auf den Backbohnen-Routern selber nochmal VLANs klicken müsste. Dann kann ich das Zwitschern nicht noch mitkonfigurieren. Das fällt halt so aus, das mache ich einmal, weil ich das Transfernet zwischen den beiden Routern aufsetze, worüber ich IP spreche und dann kann ich ja beliebig viel Layer 2 darüber wegvirtualisiert quasi transportieren. Und das kann ich halt per Salt automatisieren. Ach, das habe ich vergessen zu zeigen, haha. Da war doch irgendwo dieser Buton auf der Slide. 60, ja wohl, sagt er so flür, aber 27 war da eigentlich das, wo ich hin wollte. Diese Zeile hier unten macht nämlich, dass es das VXLAN Overlay für die Site PathCity gibt. Also das ist diese eine Zeile, die ich in die Konfig schreiben muss, dass dieses VXLAN Interface gebaut wird. Neben PathCity könnte ich da eine Liste hinschreiben, mit denen die ich gerne hätte, oder das Powerboard All und er baut alle Sites, die er kennt. Das heißt, wenn ich da ein All hinschreibe, habe ich nachher 10 VXLAN Interfaces. Die entsprechend in das Batman reingepoult werden, automatisch. Also diese Zeile macht wie XLAN Interface und dass das ein Batman Interface wird für die Batman Instanz. Ich muss keinen Switch anfassen und gar nichts. Das mache ich auf zwei Pillar-Einträgen für die zwei Notes, nämlich die zwei, wo ich das halt verbinden will, aus dem Auto. Und ich trau mich tatsächlich nicht die Switch-Config zu automatisieren bisher. Das habe ich noch nie gemacht und das würde ich gerne entwendern sinnvoll mal testen. Und so viel ändert sich nicht, also das lohnt sich fast nicht. Das ist so die Idee dahinter. Sonst noch Fragen oder Ideen, was man noch treiben könnte? Gegenfrage. Wer hier betreibt selber einen Freifunknetz? Wie macht ihr das? Aktuell alles, was wir jetzt beim Hand-Zusammen-Geschägen haben. Wir haben eine andere Integration, also nicht erfindenlos, wie wir. Wir haben die Hand-Zusammen-Geschägen, was wir jetzt beim Hand-Zusammen-Geschägen mit dabei verschüttet haben. Aber was das dann noch besser hat, hat einander ein bisschen um die Sonne den Tag einmal. Was passt, weil jetzt haben wir noch nicht die Idee in der Mitte gekriegt, müssen wir mal diskutieren, was da von uns interessant ist. Ihr könnt doch einfach klonen. Das meiste davon ist in der Tat relativ generisch, glaube ich. Also es sind ein paar Dinge natürlich Hard-Coded drin. Ich fände es tatsächlich mal spannend, wie schmerzhaft das ist, das auf eine andere Community abzubilden. Wenn nicht gut war, nicht. Da können wir ja nachher vielleicht mal drüber reden. Da gibt es sehr viel Schmerz drin und sehr viel Lerneffekte. Ich glaube, das alles noch mal neu zu bauen lohnt sich fast nicht. Ansonsten, ihr erreicht mich auf Twitter oder ähnlich oder lauft mir hier über den Weg. Gut, danke.