Open Source SDN - Mit SaltStack und Netbox zum automatisierten Netzwerk
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 94 | |
| Author | ||
| License | CC Attribution 4.0 International: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/45642 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FrOSCon 201935 / 94
7
10
12
14
15
16
17
20
22
23
26
27
28
29
30
31
32
33
36
37
38
39
41
44
45
48
52
53
55
56
57
58
60
61
62
64
66
67
74
76
77
78
79
81
83
84
93
00:00
Open sourceOpen sourceXMLUMLComputer animation
00:39
Server (computing)RoutingInternetdienstServer (computing)Focus (optics)LINUXDebian GNU/LINUXHausdorff spaceCircleOverlay-NetzSoftwareService (economics)Digital signalNormal (geometry)CASTComputer animation
02:32
RoutingDebian GNU/LINUXComponent-based software engineeringInformationComputer animation
04:04
InformationKnowledge baseSystems <München>Configuration spaceDiagram
05:09
Router (computing)RollbewegungRouter (computing)Integration by partsComputer animation
05:57
Open sourceCiscoSwitch <Kommunikationstechnik>Wireless LANIP addressOverlay-NetzComputer animation
06:29
EthernetOpen sourceBlock (periodic table)Computer animation
06:58
Configuration spaceBorder Gateway ProtocolComputer animation
07:29
Computer-integrated manufacturingOpen sourceDjango <Informatik>APIInformationPHPBoom barrierServer (computing)Systems <München>IP addressDiagramComputer animation
08:47
Computer-integrated manufacturingOpen sourceDjango <Informatik>DemosceneMach's principleALI <Programm>IP addressValue-added networkPoint of saleServer (computing)Message sequence chartSlide ruleSet (mathematics)Switch <Kommunikationstechnik>Computer hardwareComputer animation
09:49
PositionTypLINUXComputing platformDataflowLagIP addressSwitch <Kommunikationstechnik>Set (mathematics)Computer animation
10:36
LagAliasingCLOU <Programm>ACCESS <Programm>TypWebsiteERNA <Programm>InternetdienstBlock (periodic table)OLEExpandierender GraphApple <Marke>Value-added networkIP addressVirtual LANSet (mathematics)InformationRun-time systemPoint of saleIP addressMainframe computerConfiguration spaceAbbildung <Physik>Systems <München>CodeCluster samplingServer (computing)Cache (computing)Hausdorff spaceComputer animation
15:02
DemosceneConfiguration spaceFields MedalRouter (computing)Slide ruleIP addressComputer animation
15:46
Router (computing)Open sourceRollbewegungOverlay-NetzComputer animation
16:18
Configuration spaceFields MedalString (computer science)ZahlField (computer science)Eigenvalues and eigenvectorsComputer animation
16:57
SSHConfiguration spaceValue-added networkSSLLocal ringAPIWireless LANSSHWEBHIT <Programm>NetbookRSA (algorithm)LADY <Programmiersprache>Set (mathematics)Data structureInternetWebsiteMainframe computerPublic key certificateSeries (mathematics)Liste <Informatik>Overlay-NetzFormatiererRollbewegungBridging (networking)TypOpen sourceSingle-precision floating-point formatACCESS <Programm>Virtual LANSpeciesTexture mappingComputer animation
23:08
IP addressTypPOWER <Computerarchitektur>Menu (computing)Pearson product-moment correlation coefficientWebsiteZahlComa BerenicesLocal ringSSLSSHPoint cloudAPISeries (mathematics)Computer animation
24:40
SAC <Programmiersprache>WebsiteHard disk driveDDR SDRAMLagILE <Programmiersprache>Wireless LANComputer animation
25:37
Peer-to-peerLink (knot theory)LagTypValue-added networkCodeAPIACCESS <Programm>Wireless LANSeries (mathematics)Hausdorff spaceComputer animation
26:28
Link (knot theory)LagTypVirtual LANInternetdienstACCESS <Programm>SineBus (computing)WebsiteStructural equation modelingPeer-to-peerEvolutionarily stable strategyComputer musicAtomic clockWireless LANWebsiteComputer animation
27:06
Virtuelles privates NetzwerkLink (knot theory)Peer-to-peerECCE <Programm>Wireless LANComputer networkComputer animation
27:34
SinePoint of saleWebsiteACCESS <Programm>Bus (computing)Degree (graph theory)POWER <Computerarchitektur>Wireless LANComputer hardwareComputer animation
28:08
CiscoComputer engineeringTypsedInheritance (object-oriented programming)Link (knot theory)SAC <Programmiersprache>InformationsvermittlungsstelleSwitch <Kommunikationstechnik>TypAsset <Informatik>NumberComputer animation
29:16
SSHConfiguration spaceStack (abstract data type)APIHOLVirtual LANComputer fileDirection (geometry)Data structureAlgorithmAPICache (computing)Module (mathematics)StatisticsMainframe computerInformationSlide ruleWireless LANComputer animation
34:03
MAX <Programm>Computer animationLecture/ConferenceMeeting/Interview
35:10
openSUSEXMLComputer animation
Transcript: German(auto-generated)
00:07
Ja, heute mal ein bisschen was, wie man seinen Open Source SDN baut. Vorhin wurde der Begriff geprägt, das Salt Defined Network. Das soll es dann tatsächlich auch werden. Das hier ist relativ oberflächlich, was dann die Technik hinterher angeht.
00:22
Gerade eben gab es hier, also auch für später mal nachguckbar unter den Frostcon-Videos, eine schöne Einführung zu Salt. Das heißt, Salt Technik wird hier jetzt quasi vorausgesetzt, aber viel braucht es auch nicht. Und wir gucken uns eher mal den Netzwerkteil an, respektive den Netbox-Teil hinten raus. Wer ich bin, hat Stefan gerade schon erzählt.
00:42
Das heißt, erst mal, womit beschäftigen wir uns, gleich gibt es ein kleines Problem-Statement. Wie ist das in Salt gebaut gewesen? Historisch, letztes Jahr habe ich dazu hier schon was erzählt, an der gleichen Stelle, wie ich das mit Salt bisher schon gelöst habe, das Problem, das ist also schon fertig. Jetzt geht es nur noch darum, wie man das Ganze mit Netbox zusammenstöpselt, damit man sein Netzwerk eben in der Netbox zusammenklicken kann.
01:02
Worum geht es? Das ist jetzt die Nacht- und Abendbeschäftigung. Der Freifunk-Hochstift ist ein Community-Netzwerk bei mir zu Hause in Paderborn, respektive den Kreisen Paderborn und Höxter. Das ist halt eine von vielen Freifunk-Communities in Deutschland, wo es darum geht, einfach mal ein Richtfunk-Netzwerk über die Stadt zu zimmern,
01:21
wo man sich überall anschließen kann, um in der City mittlerweile auch mit Kooperation mit der Stadt und Förderung von Land und Stadt und allen anderen irgendwie ein schönes Netzwerk aufzubauen, wo sich einfach jeder damit verbinden kann und das digitale Glas Wasser gereicht bekommt, wie unsere Kanzlerin mal gesagt hat. Das heißt, wir haben irgendwie Server-Infrastruktur,
01:42
was ungefähr das ist, was gerade gezeigt wurde im Salt-Vortrag, wie man seine Server managt, Software installieren, Config-Management etc. Das klassische Software- oder Config-Management-Problem. Und wir haben einen Wireless-Backbone mit so kleinen Apuboards, die als Wireless-Backbone-Router unter den Dächern hängen, wo Richtfunkstrecken dranhängen, wo auch ein ganz normales Debian Linux drauf ist,
02:04
was als Router fungiert. Das heißt, da wird dann der Fokus aufs Netzwerk spannender. Ich habe viele VLANs, ich habe viele Interfaces, ich muss mich um Routing kümmern. Ich habe noch Overlay-Netzwerke da drüben, um das Batman Mesh-Protokoll zu transportieren, was dann nachher ein Layer-2-Netz ist, was über ein Layer-3-Netz transportiert werden muss.
02:24
Das ist dann ein bisschen spannend. Aber auch ein gelöstes Problem, ich habe noch irgendwelche Services da drin und auch Anycast und Sachen und Zeug. Das heißt, ich habe irgendwie so eine Netzwerkstruktur. Sieht in der Realität mittlerweile ein bisschen anders aus. Aber Grunde genommen so ein City-Ring.
02:41
An jedem dieser Punkte, der Kreuzungspunkt oder jeder der Bubbles da drin, ist so ein Backbone-Router. Die muss ich alle betreuen und habe in ein paar anderen Stadtteilen und anderen Vororten noch mehr davon. Das sind so 30, 40 Stück, das mache ich nicht zu Fuß. Also Config-Management. Da sind wir dann beim SDN.
03:00
Das gibt es jetzt schon seit ein paar Jahren mit eben diesen ganzen Komponenten. Das heißt, ich habe immer das Salt-Stack, was das alles orchestriert, mir das Pakete installiert, Konfigurationstateien verteilt, Sachen neu startet, wenn die Konfig sich geändert hat etc., pp. Das ist old and busted quasi. Dann Salt ist in Python geschrieben. Es gibt ein paar Python-Module, die Sachen generieren.
03:22
Das ist dann der SDN-Teil, der ist auch schon lange da. Das heißt, aus einem bisschen Konfig wird nachher ganz viel anhand von bestimmten Regeln, damit ich nur die grundlegenden Informationen definieren muss, woraus ich dann ganz viele Sachen ableiten kann. IfUpDown 2 ist im Spiel. Das ist ein schöner Ersatz für das klassische IfUpDown unter Debian.
03:42
Das kommt von den Cumulus-Networknasen. Ist auch in Python geschrieben. Da ist auch viel dran passiert. Alles basiert auf Debian. Ich bin ja schließlich ein Debian-Fanboy, wie wir gehört haben. Das Routing wird durch BERT realisiert. Und OSPF und BGP haben wir auch laufen. Und die Fledermaus da oben stilisiert das Batman, von dem ich sprach, das Mesh-Protokoll.
04:02
Das heißt, der ganze Teil war schon da. Wenn man mal reinzoomen in Salt, sieht das ungefähr so aus. Ich habe Teile der Konfig, die beschäftigen sich damit, die Network-Interfaces zu konfigurieren. Es ist ja ein Linux, also schreiben wir einfach eine Textdatei. Daraus werden die Interfaces dann konfiguriert.
04:22
BERT konfiguriere ich auch über Textdateien. Analog, VPN-Strecken etc. pp. Alle möglichen Linux-Dienste werden klassisch über Textdateien konfiguriert. Das ist der einfache Teil. Dann gibt es einmal das Salt-Pillar. Das ist so die Wissensdatenbank des Salt. Das ist eigentlich eine Jaml-Struktur.
04:41
Da stehen viele Daten drin. Klassisch lege ich da meine Konfigurationen ab oder die Eigenschaften ab von meinen teilnehmenden Systemen oder Nodes, wie er gerade schon gehört. Dann unten die drei blauen Kisten ist der Teil, der selbst gebaut ist. Das ist die Magie. Das linke sind so 2000 Zeilen Python ungefähr.
05:01
Daraus wird aus wenig Informationen die Netzwerk-Konfig generiert. Auch das ist schon da. Das heißt, letztlich habe ich dann im Pillar zum Beispiel so eine Struktur. Das ist jetzt ein Backbone-Router in einem Standort in Paderborn. Der hat eine eigene ID. Da steht eine Location dran. Der hat ein paar Rollen. Soll ein Router werden.
05:21
Soll Batman sprechen und soll ein Backbone-Router sein. Das heißt aus der oberen Rolle wird zum Beispiel abgeleitet, dass da eine Bird-Konfig drauf muss. Ein Router muss ein Bird haben. Dass das Ding OSPF und IBGP sprechen muss, wie das aussehen soll. Und aus der zweiten Rolle wird abgeleitet, dass wir Batman-Interfaces generieren müssen.
05:41
Dieser ganze Logikteil ist gesetzt. Das könnt ihr euch auf GitHub alles angucken. Davon gab es schon Vorträge, wie das ineinander greift. Die Sites sagt, welche Batman-Instanzen da gebaut werden sollen. Das heißt, Sites machen nur Sinn, wenn eine Rolle Batman da dran ist. Klassische Interfaces haben wir.
06:00
Das Ding hat einen Bond, also einen Channel in Cisco sprech. Über die ersten beiden physischen Interfaces wird zusammengebaut. Und da drüber gibt es ein paar WLANs. Zwei Backbone-Router sind immer mit einem WLAN verbunden, damit ich die auf beiden Seiten auf dem Switch wieder auseinanderhalten kann. Dafür brauche ich IP-Adressen. Und vielleicht möchte ich da ein Overlay drüber generieren,
06:22
also zum Beispiel so ein WXLAN-Overlay. Das heißt, die Zeile da unten sorgt dann zum Beispiel dafür, dass hier der dritte Block von oben kommt. Das heißt, die Netzwerk-Konfig ist gar nicht so einfach, weil da schon so ein paar Layer übereinander greifen. Das muss ich nachher irgendwie in Konfig darstellen.
06:41
In dem textuellen Teil haben wir gerade gesehen, wie das geht. Nur wie machen wir das denn in der Netbox? Also noch mal zurück. Wo ist mein Mäuserich? Die untere Zeile hier ist das Einzige, was ich da reinschreibe, was dafür sorgt, dass das nachher generiert wird.
07:01
Der ganze Rest ergibt sich aus allen Daten, die drumrum stehen oder wird berechnet. Dafür gibt es, wie gesagt, das Stück Python. Kann man sich angucken, wo eben all das automatisch passiert. So weit so gut. Das gab es schon letztes Jahr.
07:23
Jetzt ist da was dazugekommen. So ein kleines, unscheinbares blaues Logo. Nennt sich Netbox. Und was wir machen wollen, ist, dass der Saltpillar, also die Informationen, wie unsere Knoten aussehen, wie sie konfiguriert werden sollen, aus der Netbox in das Salt reinwandern.
07:41
Das ist der Teil, mit dem wir uns heute beschäftigen. Was ist denn dieses Netbox, von dem ich die ganze Zeit rede? Das ist ein Stück Open-Source-Software, ist auch in Python geschrieben, basiert auf dem Python Django-Framework. Das kommt von den Damen und Herren von Digital Ocean, die das anscheinend entwickelt haben, um ihr eigenes Data Center und ihre Kundensysteme zu verwalten
08:02
und zu dokumentieren. Das ist also ein DKIM und IPAM auf Deutsch, oder erstmal in Englisch, ein Data Center Information Management und ein IP Address Management. Das heißt, ich beschreibe, was steht denn in meinem Rechenzentrum? Welche Schränke habe ich? Wo hängen welche Systeme in den Schränken drin? Was für Netzwerkanschlüsse sind in den Servern dran?
08:22
Welche Ports habe ich an meinen Switchen, meinen Routern? Wo sind da Kabel dazwischen? Wo habe ich welche IP-Adressen drauf? Welche Subnetze habe ich? Wie greift das alles ineinander? Und das Schicke daran ist, im Vergleich zu vielen älteren Systemen, also Rectables, PHP, IPAM, wie sie alle heißen, das Ding hat eine API,
08:41
und zwar ist die Build-In und Lesen und Schreiben. Das heißt, über eine Rest-API kriege ich die Informationen da raus und ich kann sogar drin rumspielen, wenn ich möchte. Ich kann also irgendwas davor schnallen, was da Daten reinschreibt. Und das gucken wir uns jetzt mal live an. Bevor ich das in Slides gieße,
09:00
zeige ich es euch lieber live. So sieht es aus. Das ist jetzt das Netbox vom Freifunk-Hochstift. Das heißt, ich fange mal bei den organisatorischen Teilen an. Ich habe hier irgendwie Sites, also Standorte, eine ganze Menge. Da muss man sich einmal anlegen, welche Standorte gibt es.
09:21
Das sind die, an denen Freifunk-Hardware steht. Schon mal eine ganze Menge. Wieder zurück. An diesen Standorten habe ich vielleicht Racks. Nehmen wir mal eins, wo ein bisschen was los ist. Da kann ich mir angucken, so sieht mein Schrank aus.
09:41
Da steckt Hardware drin. Zum Beispiel ein Core-Router oder ein Linux-Hobel oder ein Switch. Wenn ich mir jetzt den Core-Router angucke, was nichts anderes ist als ein ganz normaler Dell-Server. Warum ist das Bild weg?
10:01
Wie man hier sieht, der hat IP-Adressen. Der hat eine primäre IP, V4, V6. Der hat Interfaces, einen Channel zum Beispiel, drei physische Interfaces und noch so ein paar virtuelle. Und eine ganze Menge IP-Adressen drauf konfiguriert sind.
10:21
So weit, so offensichtlich. Das heißt, ich kann hier meine Realität abbilden. Und komme damit schon relativ weit. Hier gibt es sogar Kabel hier hinten. Das heißt, das ist jetzt eine Kabelnummer. Das geht hier auf einen Switch. Und hier ist der Gegenport. Das heißt, ich klicke mal hier auf den Switch. Das ist eine Cisco-Mühle. Der hat offensichtlich eine ganze Menge Ports mehr.
10:43
Hier sehe ich, ob die tagged sind oder ob da alle VLANs drauf sind oder ob es ein Access-Port ist, also untagged. Das heißt, all das kann ich hier drin abbilden. Was haben wir noch? Jetzt haben wir schon mal Devices gehabt.
11:02
Kabel haben wir gehabt. Ich kann Virtualisierungskluster abbilden. Das heißt zum Beispiel, wir haben jetzt vier Systeme, auf denen ein KVM läuft. Wenn ich mir davon mal einen nehme, kann ich mir... Wo komme ich denn zu den VMs? Hier nicht.
11:21
Also noch im Aufbau. Sprich, hier ist nicht alles drin dokumentiert. Sehe ich, welche virtuellen Systeme auf welchen Clustern laufen. Unsere Cluster bestehen jeweils nur aus einem Host. Ist trotzdem ein Cluster. Ich lautdenke dieses Systems. Kann hier drin spezifizieren, wie viele Ressourcen meine VMs haben. Aktuell wird das nicht genutzt.
11:41
Das ist nur dokumentatorisch. Über die Informationen könnte ich da alle per API rausziehen. Und könnte sogar Automation dafür bauen, wenn ich hier eine VM klicke, dass die dann irgendwo aufpoppt. Vielleicht sogar automatisch installiert wird. Da ist dann der Fantasie des Betreibers wenig Grenzen gesetzt. Next up, IP-Adressen.
12:02
Hier habe ich meine ganzen Prefixe drin. Das heißt, ich kann verwalten, welche Netze es wo gibt. Hier sehen wir zum Beispiel mal die ganzen Management-Netze, die wir benutzen. Pro Standort gibt es jeweils ein eigenes, welches VLAN das ist, an welchen Standorten die sind. Das heißt, hier dokumentiere ich, welche Netze ich wo habe.
12:22
Und habe ja vorhin gesehen, die IP-Adressen standen sogar auf den Interfaces. Das heißt, wenn ich jetzt mal den Mobile Pop zum Beispiel nehme, so Hardware, die man durch die Gegend tragen kann, gibt es hier bisher nur ein Gerät, was da dokumentiert ist. Und das ist der Backborn-Router für den Standort. Das heißt, hier habe ich eine schöne Plattform, wo ich Racks, Server da drin, Switche, Verkabelungen,
12:46
IPs, Netzwerke, Interfaces, alles dokumentiert karriere, schon mal von Hause aus. Das kostet gar nichts. Das ist einfach nur da. Und wenn ich Hipster bin, ziehe ich mir davon die Docker-Images, schmeiße das in meinen Kubernetes oder in mein normales Docker-System und habe das in zehn Minuten in dem Zustand am Fliegen.
13:05
Soweit dazu fragen. Haben wir ein Mikro.
13:21
Das geht aber auch ohne Docker, oder? Das geht auch ohne Docker. Ich als echt kein Docker-Fanboy würde sagen, mach's mit Docker. Das heißt was. Also das ist halt ein Riesen-Python-Klumpatsch. Und man muss sonst irgendwie sämtliche Abhängigkeiten installieren.
13:43
Das kann ich mit PID machen. Wenn man das mag, ist das sicher auch okay. Das hat bei mir aber nur in 50 Prozent der Fälle geklappt. Das habe ich ein paar Mal ausprobiert und dann einfach Docker genommen. Also das Ding braucht eine Postgres-Datenbank. Dann kommen zwei, drei Container in der Netbox und einer mit einem EngineX für den Webserver-Teil. Und ich glaube noch ein Redis als Cache.
14:01
Es funktioniert als Container relativ charmant und ist damit auch gut updatable. Und Latest and Greatest sollte man nutzen. Ich glaube, wenn man neu anfängt, am besten dann die 2.6er. Der Update-Fahrt dahin war ein bisschen schmerzhaft. Sonst noch Fragen? Warum das cool ist, sieht hoffentlich jeder.
14:23
Also ich habe eine Dokumentation meiner kompletten Umgebung. Und wenn wir jetzt den Schritt weitergehen und uns hier aus die Konfiguration generieren, muss die stimmen. Denn wenn sie nicht stimmt, ist es in der Realität nicht konfiguriert. Oder wenn es jemand manuell konfiguriert und hier nicht einträgt, wird es überschrieben.
14:43
Oder mein Code ist fehlerhaft. Ja, das passiert ja nicht. Also das hebt wirklich die Motivation, die Doku zu pflegen. Ich muss es einfach tun, ansonsten klappt es nicht. Das System ist jetzt einfach mal gegeben.
15:04
So jetzt, wieder zu den Slides. Ok, klassische IPs zu konfigurieren,
15:22
bringt uns das Ding mit, das ist einfach. Das heißt, den Teil, wir erinnern uns an das Jaml vorhin. Ich hatte die Interfaces, ich hatte da meine Interfaces mit IP-Adressen drin. Dafür ist das Teil gebaut, das ist easy. Ich springe dann nochmal zurück dahin, damit wir nochmal sehen, welche Probleme wir gerade alle haben.
15:40
Die ID da oben ist so ein Custom Value irgendwie. Weiß ich noch nicht, wie wir die da reinkriegen. Die Location ist auch relativ einfach. Wir hatten ja die Sites. Das heißt, ich gebe meine Location sowieso an in Netbox, kann ich darüber abbilden. Die Liste an Rollen und an Sites in dem Sprech hier. Sollen wir mal gucken.
16:02
Die Interfaces, also zumindest den unteren Teil, Description und die Prefixe, ist auch einfach. VLAN Raw Device, oben die Bond Slaves und unten das Overlay. Schauen wir mal. Wo will ich hin? Da.
16:20
Also, IPs ist easy. Einfache Werte, Strings, Integer, sonst was, für Devices und virtuelle Maschinen, kann ich als Custom Fields in Netbox anlegen. Das heißt, ich kann mir an Geräte eigene Felder dran schnüren, für triviale Werte. Das heißt, diese ID da als Zahl dran zu tun,
16:42
ist einfach. Kann ich sogar dafür sorgen, dass das Ding unik sein muss. Das heißt, Netbox erlaubt es nicht, dass ich an zwei Geräte die selber ID dran klebe. Schon mal ganz praktisch. Aber was machen wir mit dem ganzen Rest? Ich hatte VLAN Interfaces, muss dann sagen, auf welchem Underlay ist das.
17:03
Also die Liste. SSH Keys haben wir da noch mit drin zum Beispiel. Das heißt, im Salt stecken die SSH Host Keys drin. Also die RSA, DSA, EC, DSR, whatever Keys. ETC, SSH und dann die ganzen Host Keys. Das heißt, wenn ich einen Host neu installiere, behält der seine Keys.
17:20
Und ich kann in meinem ganzen Netz ausrollen, welcher Host welche Keys haben sollte. Und wenn dann irgendwo jemand schlimme Dinge tut, fällt mir das sofort auf. Die muss ich auch irgendwo speichern. Das wäre ganz elegant, wenn ich das auch in die Netbox tue. Dann habe ich nämlich meinen Single Source of Truth. Das ist dann die Netbox. Die WXLAN Overlays. Bridges habe ich noch. In meinem Jammel ist das einfach.
17:41
Dann schreibe ich mir einfach rein, es soll eine Bridge werden, hat die Bridge Ports und vielleicht die VLAN-Config, wenn es eine VLAN-Aware-Bridge ist. Oder Grätunnel. Wir sind ja Freifunker. Das heißt, wir müssen irgendwie von unserer Installation mit Grätunneln zum Freifang Rheinland backbone vielleicht, um unser Internet zu bekommen. Wie machen wir das denn? Gucken wir uns der Reihe nach an. WLAN Interfaces.
18:01
Wenn ich die in der klassischen Notation aufschreibe, physisches Device, Punkt WLAN ID, ist das relativ easy. Ich habe den Namen am Interface dranstehen. Das heißt, das kann ich genauso nachher in der ETC Network Interfaces oder sonst wohin generieren und weiß dann, was das Underlay ist und was die WLAN ID ist. Das gibt das Format schlicht her.
18:21
Mir persönlich gefällt diese Variation nicht unbedingt. Ich mag eigentlich diese WLAN 42 Schreibweise lieber. Man muss sich aber irgendwie an das Interface dran schreiben. Wo läuft es denn drauf? Also Bond 0 in dem Fall zum Beispiel. An Interfaces kann man in der Netbox leider keine Custom-Values
18:42
dran nageln. Aus Gründen, die sich mir nicht erschließen. Die Autoren finden das irgendwie unnötig. Also gab es schon mehrere Issues dazu. Hey, erlaubt doch bitte mal, dass man an Interfaces Custom-Values dran machen kann. Nee. Aber, es gibt einen Trick. Wir hatten ja gesehen, dass man
19:02
bei einem Interface sagen kann, ist Access. Also irgendein Untagged WLAN. Tagged oder Tagged All. Wenn es Tagged ist, kann ich angeben, welche WLANs da drauf liegen. Das kann man dann klicken. Das heißt, meine Lösung dafür ist jetzt, ich nehme mir das Underlaying WLAN und klicke da drauf in der Netbox. Welche Tagged WLANs kommen denn da an?
19:21
Dann kann ich mir das nachher über die API rausziehen und habe einen Mapping von WLAN 42 habe ich als Interface oder WLAN 3018 zum Beispiel habe ich als Interface. Gucke in meiner Liste nach. Okay, das ist getagged auf Bond 0, also weiß ich das. Kann ich dann selber wieder verheiraten, diese zwei Dinge. Das ist noch relativ einfach.
19:43
Dann diese Zeile mit Wo soll ein Overlay drüber gebaut werden? Für welches Site? Da kann man Tags für missbrauchen oder nutzen. Also zum Beispiel hier dieses Batman Connect und das, was dahinter kommt, ist dann der Name der Site. Das ist letztlich auch nur ein Aufkleber, den ich an der Interface dran tue. Das heißt hier
20:02
habe ich eine andere Methode gefunden, um die Tatsache herum zu arbeiten, dass ich keine Custom Values da dran tun kann. Das ist auch noch relativ einfach. Das heißt, die zwei haben wir schon mal. Das machen wir dann mit der Liste der Rollen und Sites und SSH Keys, wo wir ein bisschen mehr Daten hinterher haben.
20:21
Dafür gibt es Config Contexts. Die kann ich mir selber erstellen. Kann ich global anlegen. Und damit habe ich sehr viel Freiheit. Ich kann eine Datenstruktur oder eine, was ist denn das? Jason ist das dann, Jason Struktur angeben pro Config Context, wie so ein Kontext aussehen soll.
20:41
Und kann sagen, an welche Typen von Geräten ich das dran hänge. Das heißt, wir haben was angelegt für Zertifikate zum Beispiel, wobei das wahrscheinlich rausfliegt. Da würde ich dann mittlerweile eher den, was ist das Ding? Von Cloudflare gibt es so eine CA, entweder als Docker Container oder als Go Binary. Würde ich die mittlerweile benutzen. Für
21:01
Interfaces, wenn ich sehr viel hacken muss, für die Liste der Rollen, die Liste der Sites, meine SSH Keys und Wireless waren ein Test. Weiß gerade gar nicht, wofür ich den genutzt habe. Wie sieht das dann aus? Das heißt, ich habe zum Beispiel, wenn ich nichts eingetragen habe, so eine Jason Struktur an meinen Geräten dran. Sei es jetzt eine VM oder sei es ein
21:21
physikalisches Device. Netbox unterscheidet da zwischen diesen zwei Arten von Dingen. Das obere ist dann Dictionary, Rollen und Sites. In Jason Notation wären Listen und meine SSH Keys könnte ich da rein tun und unten die Zertifikate, die irgendwann mal rausfliegen. Das ist nicht schön, aber geht.
21:44
Das sieht dann, wenn man Werte da rein tut, entsprechend so aus. Das heißt, da muss ich dann nur das Ganze als Jason formatieren. Das entweder per API in die Netbox stecken oder mir da rein klicken. Und habe dann die Daten. Für GRE-Tunnel
22:01
gibt es leider auch keine eigenen Interface-Typen. Da bräuchte ich ja auch wieder eine ganze Menge Werte an dem Interface. Was meine Gegenstelle, vielleicht was ist meine lokale IP und vielleicht noch über welches Underlay Device soll das Ding gehen, wenn ich mit VRF so umhantiere.
22:23
Das habe ich schlicht und ergreifend so gelöst. Dafür habe ich mir auch eine eigene Datenstruktur gebaut und spezifiziere die Dinge auch als Config-Kontext, bis mir eine bessere Lösung einfällt. Ist nicht schön, aber funktioniert. Und das kann ich quasi für alles machen, was an Daten noch übrig ist.
22:43
Das ist dann der Prozess, da muss man viel Gehirnschmal reinstecken, wie immer in allen Dingen, die man designt. Die Datenstrukturen kosten die meiste Zeit. Und wenn man daneben greift, holt einen das später immer wieder ein. Das heißt, da sollte man wirklich mal richtig Zeit investieren. Aber da kann man dann viel gewinnen.
23:01
Wie bringe ich das jetzt zusammen? Jetzt habe ich irgendwie diese ganzen Daten in Netbox, können wir uns das gerne nochmal live angucken. Das war jetzt ein Schnelldurchgang. Wie sieht das dann wirklich live aus? Nehmen wir uns zum Beispiel mal so einen Core-Router.
23:26
Dann habe ich hier oben die ganze Reihe an Interfaces, der E-Tunnel. Müssen wir mal gucken, wie weit ich scrollen darf, bevor SSH-Private-Keys kommen. Dann kommen die
23:40
ganzen Rollen, die das Ding hat. Hier meine SSH-Keys und erstaunlicherweise keine SSL-Zertifikate. Sites gibt es hier nicht. Sites machen nur Sinn, wenn das Ding die Rolle Batman hat. Das heißt, das sind einmal die Daten, die ich hier manuell reinpuzzeln muss,
24:02
damit sie über die API wieder Mitte rausfallen und ich sie aus Salt-Sicht wieder abgreifen kann, weil ich sie leider stand heute in Netbox nicht besser darstellen kann. Daran wird aber noch sehr viel entwickelt und vielleicht gibt es ja den Bedarf, dass man GRE-Tunnel zum Beispiel standardmäßig sinnvoll abbilden kann. Vielleicht gibt es auch mal ein Pool-Request,
24:21
wenn ich zu viel Langeweile habe. Wir sind ja nicht die Einzigen, die sowas nutzen. Gerade Gerätunnel werden ja in Data-Centern häufiger benutzt. Soweit ich weiß, machen einige der großen Cloud-Scaler auch irgendwelche Stunts mit MPLS und sonstigen Scherzen. Was hatten wir noch?
24:41
Nehmen wir mal den hier. Da sehen wir, hier steht die ID dran. Das ist eins der Custom-Fields. Und hier steht einerseits planned dran. Das heißt, das Monitoring, Icinga in diesem Fall, hat die Information, hey, dieses Interface muss nicht ab sein.
25:01
Wenn da drauf OSPF nicht an ist, ja mei. Wenn die Gegenstelle nicht antwortet, ja mei, geh mir nicht auf den Geist. Ist auch nur ein Tag. Und, konnektiere bitte über dieses WLAN per WXLAN die Site-PadaBond-City. Ist auch ein Tag.
25:21
Damit sind diese Dinge jetzt hier drin abgebildet. Jetzt gucken wir uns das Bond mal an. Und hier unten sehe ich, welche Tagged-WLANs konfiguriert sind. Was wir jetzt mal editieren wollen,
25:42
ist das Entscheidende, dass der Mode tagged ist. Ich habe eins oder mehr tagged-WLANs auf diesem Interface. Und hier unten kann ich die der Reihe nach konfigurieren. Wenn ich da jetzt einfach eins hinzufügen möchte,
26:01
taucht es in dieser Liste nachher auf. Das kommt von Hause aus mit. Damit kann ich zum Beispiel schon mal ganz normalen Switches konfigurieren. Oder abbilden. Welche WLANs habe ich auf welchem Kundenport vielleicht? Welche darf er haben? Welche soll da sein? Oder auch nicht.
26:25
Die Frage ist, ob man die WLANs global oder pro Interface konfiguriert. Die WLANs sind hier auch angelegt. Das heißt, ich kann sogar WLANs und Prefixes verheiraten. Und ein WLAN kann an einer Site kleben. Wo ist es? Irgendwo müsste hier eine Site stehen.
26:42
Stell das hier nicht dran. Doch, da vorne. Ein WLAN kann an einer Site kleben. Also manche sind site-lokal. Aber die ganzen Transfernetze sind natürlich nicht site-lokal. Das heißt, das muss nicht an einer Site kleben. Ein WLAN kann eine bestimmte oder muss, glaube ich, sogar eine bestimmte Rolle haben.
27:00
Die kann ich auch anlegen. Wo sind sie denn? Da. Netzwerke und WLANs müssen eine Rolle haben. Also, was wird denn da drin transportiert in diesem IP-Netz oder in diesem WLAN? Da habe ich die hier angelegt, die wir im Freifunk-Kontext haben.
27:20
Die üblich verdächtigen. Irgendwelche Cross-Connects. Irgendein Layer-3-Netz, Loopback-Adressen, Management-Netze etc. pp. Und damit gibt es dann halt die ganzen WLANs, die es halt so gibt bei uns. Da gibt es eine Nomenklatur dazu. Welche Nummern was bedeuten
27:41
tatsächlich. Also, welche Bereiche was sind. Was weiß ich. 1000er WLANs sind zum Beispiel kabelgebunden. 2000er WLANs sind Richtfunkgebunden. 3000 ist Management. 100er sind IP-Traffic in Batman und so weiter und so fort. Noch eine Frage?
28:01
War der Frage beantwortet? Wundervoll. Was ich noch vergessen hatte, man muss hier sogar, wenn man Hardware abbilden möchte, sagen, wer hat es gebaut? Und was für Typen haben wir denn? Das sind zum Beispiel so die Switche und Geräte, die wir im Einsatz haben. Also man sieht, es gibt
28:21
doch dahin stehen die Instanzen, aber das ist unvollständig. Das ist immer noch so ein bisschen Entwicklung. Die Zahlen ganz rechts wären jeweils deutlich mehr. Aber damit habe ich wirklich die Realität abgebildet. Bis hin auf Gerätetyp. Was gerade den DKIM-Teil, das Data Center
28:40
Information Management Teil, sehr, sehr wertvoll macht. Ich kann damit sogar eine gewisse Form des Asset Management abbilden. Inklusive Asset Tags, welche Inventarnummer hat das Gerät bei mir, wenn ich das möchte. Ob man das will, ist eine andere Diskussion, aber man kann. Ich kriege auf jeden Fall mit, wo ist es verbaut? Wenn mich meine Buchhaltung fragt, ey, das Gerät mit der Seriennummer oder mit der Inventarnummer,
29:01
wo hast du denn das Entschrank geschraubt? Suche ich hier nach und finde es. Dann haben wir, glaube ich, jetzt alles durchgeklickert.
29:25
Jetzt die alles entscheidende Frage. Jetzt habe ich es in dieser Netbox drin. Jetzt habe ich es dokumentiert. Das ist mein Intent. Heißt ja so schön. Intent Driven Network Configuration. Das soll es werden. Jetzt muss ich irgendwie dem Salt beibringen. Hol dir das da mal raus. Dafür
29:40
habe ich jetzt Nazl-D gebaut. Netbox Abstraction Automation and Caching Layer for Salt Stack. Der Name ist rein zufällig gewählt. Das ist ein Stück Python, das per Request die REST API befragt. Die Daten da rausholt, wie Netbox sie präsentiert. Was relativ verbose
30:02
ist das Format. Da ein bisschen drauf rumschlägt und das in das alte Format, wie es im Pillar stand, umbaut. Weil ich habe ja schon eine Datenstruktur fürs Pillar mal designed. Die hat sich jetzt bewährt. Die habe ich seit Jahren nicht mehr angefasst. Also nehme ich mir die ganzen Daten aus der Netbox, lasse da ein paar Algorithmen drüber laufen und habe es nachher in dem Format, wie ich es brauche
30:21
und fummle mir zum Beispiel die Tagged VLANs zusammen mit meinen VLAN Interfaces. Also welches VLAN Interface muss auf welches Bond und so weiter. Das heißt, das wird alles da in diesem Demon zusammengepoolt. Und damit ich da von Salt wieder dran komme, hat der nach vorne raus. Nochmal eine REST API. Und es gibt ein
30:40
ExtPillar Modul in Salt. Das ist dann nur noch so ein Stück Code, was eine Funktion aufruft und als JSON den ganzen Datenbestand zurückkriegt. Also das, was ich vorher manuell in Jaml Files geschrieben habe, im Salt Pillar, auf dem Salt Master, kriegt das Salt jetzt über die REST API vom Nazl-D
31:01
direkt reingeliefert, wenn er danach fragt. Salt fragt also Nazl, hallo, gib mir mal alle Knoten. Okay, der zieht sich das aus Netbox, schlägt drauf rum und bitteschön. Das fand ich jetzt die geschickte Lösung, weil es einfach ich musste an meinem Salt an den tausenden States und der ganzen Logik nichts ändern.
31:21
Ich habe einfach eine neue Datenquelle. Und das ExtPillar Modul ist so gebaut, wenn es eine Config für einen Host mit einem bestimmten Namen im Pillar selbst gibt, also in der klassischen Salt Config gibt, wird das, was aus Netbox kommt, ignoriert. Dadurch habe ich sogar einen weichen Migrationspart. Wenn ich das Ding im Netbox
31:41
anlege, wie zum Beispiel den Core-Router, das macht erstmal nichts, solange er noch im Salt Pillar drin steht, wird die textuelle Config genommen. Es wird erst dann der Netbox-Eintrag relevant, wenn ich es aus dem Salt rauslösche. Damit kann ich die Geräte weise migrieren und wenn es kaputt war, lege ich die Datei wieder an.
32:01
Gibt es auf GitHub. Das Caching ist aktuell noch gelogen, das ist noch nicht drin, weil ich es bisher nicht brauche, aber ich vermute, dass das relativ schnell noch spannend werden könnte, weil da durchaus einiges an Informationen drinsteckt und jeweils wieder rauskommt. Da wird wahrscheinlich noch ein Redis gegriffen und dann dran geflanscht, dass einmal pro Minute oder alle 5 Minuten, je nachdem, die Daten wirklich aus Netbox
32:22
gepooled werden und ansonsten wird einfach ein Redis gegriffen und bitte schön nimm das. So häufig ändert sich ja nichts und im Zweifel braucht es dann vielleicht einfach einen Trigger, liest die Daten mal wirklich neu aus Netbox ein. Das klingt jetzt vielleicht für den einen oder anderen nach not invented here. Stimmt.
32:40
Gibt es Alternativen? Ja, gibt es. Es gibt von für Salt selbst einen X-Pillar-Modul, wo man was direkt mit einer Netbox reden kann. Das heißt aber, ich habe in Salt die Datenstruktur, wie Netbox sie mir anbietet. Die ist komplett anders. Wenn ich bei Null anfange, mag das vielleicht eine coole Idee sein. Es hätte für mich aber gehießen, ich hätte alle meine Salt-States,
33:03
alle meine Templates, alle meine Logik anpassen müssen. Das war mir zu teuer als Aufwand. Und das Ding konnte vor ein paar Wochen bis Monaten noch nicht das, was es jetzt kann. Denn da ist auch ein bisschen was dran passiert. Freifunk München hat sich das vorhin dargestellte Freifunk Hochschrift Setup
33:21
geklaut und geforkt. Und nutzt jetzt den X-Pillar Ansatz, um direkt mit Netbox zu reden. Das heißt, da ist ein bisschen was an dem Salt Setup passiert. Und da ist auch X-Pillar in Richtung Netbox gewachsen, weil Dinge einfach fehlten. Das heißt, diese beiden Dinge gibt es, die kann man sich angucken und klauen. Und sich
33:42
für das entscheiden, was einem besser gefällt. Ich denke beides. Ich freue mich über Patches, wenn das denn von allgemeiner Relevanz ist. Und ich glaube, das X-Pillar für Netbox freut sich auch über Patches. Da sind auch schon einige reingegangen. Mehr Kontext, die älteren Vorträge dazu und ein bisschen Blogartikel. Gerne zum Nachlesen.
34:01
Die Slides gibt es auch nachher online. Ansonsten dürfte mich gerne noch löchern, warum das eine gute Idee ist und wie man es vielleicht nicht machen sollte. Ich glaube, dein Mikro war nicht
34:24
Vielen Dank, Max. Sind Fragen? Keine Fragen. Vielleicht ein Ausblick,
34:41
was werden wir nächstes Jahr präsentiert bekommen? Ja. Dass das alles total toll läuft und man jetzt Freifunk nur noch in der Netbox klickt und dann passieren automatisch Dinge. Freifunk SS Service? Ich glaube nicht. In Docker?
35:00
Nein. Gut. Wenn keine weiteren Fragen sind, dann sind wir heute sehr früh fertig. Und nochmal vielen Dank an Max.