 Ja, herzlich willkommen zur Halbzeit hier auf dem Kanal von der FEM. Der nächste Speaker heißt Woddy. Er war mal vor einiger Zeit bei uns in der FEM aktiv, hat dort bereits einiges an Netzwerkinfrastruktur administriert und mittlerweile arbeitet er bei einem richtigen ISP und zeigt uns heute, wie er mithilfe von Netbox dort diverse Teile der Netzwerkinfrastruktur automatisiert hat. Dieser Talk wird auch danach eine kleine Fragerunde haben. Dazu könnt ihr Fragen stellen im IRC im Channel RC3-FEM oder alternativ auf Twitter unter dem Hashtag RC3-FEM oder auch im Fediverse unter dem Hashtag RC3-FEM. To all the English speaking listeners, this talk will also be translated into the English language. To receive the English translation please use the English translation audio stream using the language selection tool in the web player. Und nun viel Spaß mit dem Talk. Hallo und herzlich willkommen zu meinem Vortrag zum Thema Netbox als Datenquelle für Netzwerkinfrastruktur. Ich habe mich im letzten Jahr ein bisschen mit Netbox beschäftigt und wie man das benutzen kann um Abläufe im Unternehmen zu automatisieren. Es soll im Vortrag um die Vorgehensweise gehen, die man beachten sollte bei der Integration von Netbox in anderen Netzwerksdienste. Dabei geht das explizit nicht um die Generierung von Gerätekonfig, sondern um die ganzen Systeme, die man so drum herum hat, wie zum Beispiel im Monitoringsystem. Der ganze Vortrag ist kurz gehalten und als Diskussionsanschluss gedacht und ich will mich auf Feedback und Fragen und Diskussionen am Anschluss freuen. Kurz zu mir, mein Name ist Alexander Votterler, den meisten hier werde ich bekannt sein als Forty. Ich bin 25 Jahre alt und habe in Ilmenau studiert und dementsprechend war ich bei der Forschungsgemeinschaft Elektronische Medien aktiv und auf den Kongressen bin ich meistens beim C3Voc anzutreffen. Aktuell mache ich eine Ausbildung bei RelaxedNetworks in Aachen. Dann zur Netbox, der Vortrag riecht es sich ein bisschen an Leute, die sich damit schon auskennen, dass vielleicht schon selbst im Einsatz haben. Ich werde jetzt trotzdem einen kurzen Einstieg darin bieten. Was ist Netbox? Es ist ein Tool zur Dokumentation von IT-Infrastruktur. Es ist dabei ein IP-Adress Management und ein DECIM, ein Data Center Infrastructure Management Tool. Er strebt an, eine Abbildung der echten Welt zu modellieren und will eine Single Source of Truth sein. Das heißt, die Idee ist nicht, sein Produktiv-Netzwerk in Netbox zur Dokumentation einfach zu importieren, sondern man soll das Netzwerk in Netbox beschreiben und daraus dann das echte Netzwerk erzeugen. Das Ganze ist eine Web App, die so einem Keep It Simple Ansatz folgt. Das heißt, es werden wirklich nur die grundlegenden Modelle dargelegt und alles Weitere muss man sich selbst dann abbilden. Und das Ganze ist Open Source unter der Apache Lizenz. Das heißt, jeder kann sich das installieren und verwenden. Ich werde jetzt kurz eine Demo bieten. Man sieht hier so den Log-In Screen, bevor man eingeloggt ist in Netbox. Da sieht man schon, welche ganzen Objekte wir hier verwalten können. Ich logge mich jetzt einfach mal ein. Wir sehen wie gesagt organisatorisches Data Center Inventar wie Racks und Geräte. Man kann Kabel modellieren und IP-Adressen. Ich gucke jetzt einfach mal die Geräte an. Wir haben hier Namen und Status und die Rollen der Geräte, Hersteller, Typen, Standort und eventuell auch IP-Adressen, wenn die verknüpft sind mit den Geräten. Wir gucken uns jetzt einfach mal so ein Access Switch an. Haben wir wieder die ganze Information, die wir gerade schon gesehen haben. Wir sehen aber auch zum Beispiel auch in welcher Höheneinheit das verbaut ist. Noch mal den Typ und das Betriebssystem. Wir können auf Interfaces klicken. Wir sehen hier, es gibt Interfaces, die sind verknüpft mit anderen Geräten wiederum und haben IP-Adressen. Wir können uns jetzt einfach mal die primäre IP-Adresse des Gerätes angucken und sehen hier wieder Informationen dazu, welche IP-Adress-Familie das ist, wie man die zugewiesen ist, den Status und den Essenamen, das Assignment auf welches Gerät das zugewiesen ist und welches Interface. Wir sehen auch, die IP-Adresse ist Teil eines Prefixes, also unserem Subnetz. Wir können hier wiederum auf das Prefix-Objekt klicken, wieder alle Handinformationen. Wir können sehen, welche IP-Adressen es in dem Netzwerk gibt. Wir könnten es hier auf die freien IP-Adressen klicken. Netbox würde uns die nächste freie IP-Adresse vorschlagen, die wir hier eben anlegen können mit DNS-Nahme und Nuttinformationen und Interface-Zugehörigkeiten. Was können wir allgemein alles so in Netbox abbilden, so als Überblick. Wir haben organisatorisches Geräte, also Geräte und Gerätetypen und Komponenten. Wir können aber auch die Verbindung zwischen den Geräten und zum Abbilden mit Kabeln und Kabellosen links. Wir haben IP-Adressen und Prefixes. Wir konnten unsere autonome Systeme verwalten, unsere VLANs zum Beispiel. Virtuelle Maschinen sind auch abgebildet in Netbox, die wir hier mit den Parametern anlegen können, die man so braucht, um einen vor allem Host-Umgebungen zu befüllen. Und wir können Netbox zum Beispiel mit eigenen Skripten auch erweitern und eigene Funktionalitäten hinzufügen. Das ist alles in Python dann. Das ist so grob der Überblick zu Netbox, wie wir die Daten da anlegen und verwalten. Jetzt geht es darum, mit welchen Schnittstellen greifen wir denn auf die Daten hinzu, wenn wir das integrieren wollen mit anderen Diensten. Zum einen gibt es da eine REST-API, also einfach behartet in HP Request kann man sich die einzelnen Objekte lesend und schreibend damit bearbeiten. Das ist über Keys gesteuert, die man sich, die jeder Netbox-Nutzer sich anlegen kann. Es gibt auch eine GraphQL-API, da kann man sich also einfach ein Query schreiben und dann direkt die Informationen mit einem Request holen, die man vielleicht braucht. Und Netbox bietet auch Webhooks. Das heißt, Netbox schickt ein HP Request an einen vorkonfigurierten Server, wenn sich an einem bestimmten Objekt oder Objekttyp etwas ändert. Zum Beispiel kann man damit sein DNS-Server befüllen. Wenn ich von Netzwerkinfrastruktur rede, was meine ich dann? Ich meine damit unser Monitoring-Tool, das ist in dem Fall iSinger. Wir haben auch noch Observe im Einsatz, um weitere Statistiken einsammeln zu können. Wir verwenden Ransit, um Konfigurationsänderungen auf Switchen und Routern zu verfolgen. Und wir wollen Power-DNS einsetzen, um eben den S-Einträge für intern und extern zu verwalten. Dabei geht es um Forward und Reverse-DNS. Außerdem haben wir für bestimmte Switche ein Zero-Touch-Provision-Ling-System im Einsatz. Dabei geht es einfach darum, die Geräte nicht mehr vorkonfigurieren zu müssen, bevor sie verbaut werden, sondern sie werden einfach nur noch angelegt und dann über den, ziehen sie sich beim ersten Boot automatisch die Konfiguration und eine Firmware. Es wird auch kurz um Puppet gehen. Das ist unser Konfigurationsmanagement-Tool für VAMs vor allem. Und ich möchte das Ganze jetzt einmal abbilden oder anhand eines Ablaufs bei uns im Unternehmen beschreiben, was dann mit Netbox erreicht werden soll. Der Ablauf ist das Anlegen neuer Geräte, zum Beispiel neue Access-Switche. Wie lief das bisher ab? Man musste sich eine IP-Adresse heraus suchen. Da gibt es in Legacy-Umgebungen viele verschiedene Methoden, irgendwelche Excel-Tabellen oder irgendwelche Wikis, wo IP-Adressen verwaltet wurden. Dann muss man das Gerät manuell konfigurieren. Eventuell gibt es irgendwelche Vorlagen, als Text-Files, die irgendwo rumliegen. Aber das ist halt auch alles nicht hübsch. Wir müssen die IP-Adresse eventuell manuell ins DNS eintragen. Wir müssen auf eine Rückbildung warten, ob das Gerät verbaut wurde. Dann wird das Ganze in die Singer eingerichtet, in den Monitoring, im Observium, im Ranset und schlussendlich müssen wir das Ganze noch dokumentieren. Wie soll das in Zukunft ablaufen, wenn wir das, wenn wir da Netbox ins Spiel bringen? Die Idee ist es, wir dokumentieren und sind fertig. Wie sieht das in der Realität aus? Gerät wird per Script in Netbox angelegt. Da brauchen wir so die grundlegenden Informationen, wie der Name des Gerätes, der Standort und die Mac-Adresse. Das Script kümmert sich darum, dass freie IP rausgesucht wird, dass das Gerät als passend Typ angelegt wird und der Standort verknüpft wird. Unser ScylulTouch-Provisioning zieht sich die Information aus Netbox, generiert schon der Gerätekonfig und legt das passend an. Und im DNS wird der Name der IP-Adresse oder die IP-Adresse auch schon hinterlegt. Und wir legen das Ganze als Status Planned in Netbox an, also geplant. Damit kommen wir wieder unsere Rückmeldung. Das Gerät wurde verbaut. Daraufhin setzen wir in Netbox den Status auf Active und unser eSinger, das Observium und das Ranset sollten automatisch konfiguriert werden, so dass wir nichts mehr machen müssen manuell. Und wir sind fertig. Wie sieht das Ganze aus? Wie können wir das integrieren? Ich habe jetzt hier drei verschiedene Methoden mal dargelegt, wie wir das machen können. Die erste Methode zur Integration ist ein Export mit nachträglicher manueller Kontrolle und mit Export manuellen vollständigen Export unseres Datenbestandes in Netbox. Das kann man sich automatisieren mit zum Beispiel das CI-CD Pipeline. In unserem Fall haben wir das mit GitLab gemacht. Wie sieht das aus? Wir haben eine GitLab Pipeline, die besteht aus zwei Tasks. Einmal wird ein Jammel Fall generiert mit allen Informationen, die wir in Netbox haben bzw. mit allen Informationen, die wir für so einen Host brauchen. Und daraufhin wird automatisch ein GitCommit angestoßen und ein Merch request erzeugt, indem wir dann die Änderungen, die wir gemacht haben, noch mal als noch mal dargestellt bekommen. In dem Beispiel hier wurde einfach nur eine IP Adresse geändert bzw. das Subnetz verändert. Dann können wir sagen, okay, diese Änderung ist hübsch, die können wir merken und haben das dann direkt als Datenbestand im Puppet zur Verfügung. Das funktioniert aber genauso mit anderen Configurations Management Tools, zum Beispiel mit Ansible oder Solstack. Diese Vorgehensweise hat natürlich Vor-Nachteile. Zum einen haben wir die volle Kontrolle über die Daten, die wir in unserem Produktivsystem haben. Und wir können auch wunderbar irgendwelche Business Prozesse, zum Beispiel ein Change Management Prozess, den wir eventuell im Unternehmen etabliert haben, damit abbilden. Nachteil ist, dass es halt mit erheblichem Aufwand verbunden. Wenn wir eine kleine Änderung machen, müssen wir das im Netbox ändern, dann die Pipeline anstoßen, dann den Merch request kontrollieren bzw. kontrollieren lassen und das Ganze ist nicht vollständig oder nicht in Netbox integriert. Das heißt, wenn wir eine Änderung machen, dann haben wir in der Versionskontrolle Merch request, aber im Netbox ist das schon der Zustand, so wie er ist. Ein anderer Ansatz wäre das Ganze mit den Webhooks zu machen. Ich habe jetzt hier ein Beispiel verlinkt, da hat das jemand verwendet, um DNS Updates anzustoßen und das würde einfach so funktionieren, dass sobald sich an zum Beispiel eine IP Adresse, was ändert, automatisch ein Request an diesen Webhook-Server gesendet wird, der dann wiederum ein DNS Update auf dem DNS-Server anstößt. Der Vorteil hierbei, unsere Änderungen sind sofort wirksam. Der Nachteil, es können über die Zeit Inkonsistenzen entstehen. Wenn jetzt zum Beispiel der DNS-Server, das nicht übernimmt oder da ein Fehler passiert beim Webhook, dann können die Daten unter Umständen verloren gehen und wir haben keine Methode, das zu sehen und auch keinen Weg, das wieder konsistent zu bekommen. Wenn wir einen Fehler in Netbox machen, hat er sofort eine Auswirkung auf unser Produktivsystem und es gibt keinen Weg, das nochmal zu überprüfen. Eine andere Methode, das Ganze zu machen, die wir oder die ich jetzt preferiert habe, ist der regelmäßige automatische Sync von verschiedenen Diensten mit den Datenbeständen in Netbox. Da habe ich jetzt von meinem GitHub ein Skript hinterlegt, wo wir das mit Power-DNS machen. Das Ganze hat immer den gleichen Ablauf, das sieht so aus. Wir holen uns alle Eindräge, die in dem System existieren, zum Beispiel im DNS-Server. Wir holen uns alle Eindräge, die wir dazu in Netbox haben, zum Beispiel alle IP-Adressen und Tost-Namen, die wir dazu haben. Wir machen einen Abgleich, was ist im System, was ist in der Netbox? Daraufhin legen wir alles, was nicht im System ist, aber in Netbox neu an und alles, was im System ist, aber nicht in der Netbox wird gelöscht. Das Ganze haben wir bis Skript gelöst für Power-DNS und die anderen Sachen sind damit auch noch in Planung. Für Isingar gibt es eine Sonderregelung, da gibt es nämlich den Isingar Direktor. Das ist einfach so ein Tool, um die Konfiguration von Isingar direkt per GUI verwalten zu können und dafür gibt es ein Netbox-Modul. Die Konfiguration dafür ist recht aufwändig, deswegen zeige ich da kurz gleich ein paar Screenshots und wir können aber auch nicht alles abbilden, was Isingar bietet in Netbox direkt. Dafür bietet Netbox aber so hübsche Sachen wie den Config-Kontext. Das ist einfach ein Chasen-Feld, was zum Beispiel an Geräten oder IP-Adressen hängen kann und da können wir zusätzliche Informationen zu Checks, die wir haben wollen, in unserem Monitoring abbilden. In Isingar sieht es dann so aus, wenn wir dieses Modul installiert haben. Wir haben Importquellen, also unsere Netbox-Objekte, zum Beispiel Devices und IP-Adressen und VMs und können darauf wieder Modifiers anwenden, die die Daten so umbauen, dass sie für uns in Isingar dann passen. Das Ganze wird als Objekte in Isingar dann reingesüngt über eine Sync Rule für Devices oder IP-Adressen oder VMs und dort gibt es dann wieder Properties, die dann sagen, welches Feld aus Netbox soll in welches Feld in Isingar wandern und welche Vorbedingungen erfüllt sein müssen, damit das Gerät oder das Objekt in Isingar reingesüngt wird. Auf die Objekte, auf diese Hosts zum Beispiel, können wir dann über Apply Rules wieder Services anwenden. Zum Beispiel für BGP Checks, die wir auf bestimmten Geräten haben wollen, können wir dann über die Checks, die wir in dem Fall als Chasen im Config-Kontext angelegt haben, einmal drüber iterieren mit so einer Apply for Rule und daraufhin einzelne Checks erzeugen. Der regelmäßige Autosync, was hat der für Vor- und für Nachteile? Ein Vorteil ist, wir haben eine zeitnahe Wirkung der Änderung, die vergleichbar ist mit dem Webhook, das heißt wir lassen diesen Sync entweder das Script oder uns in Isingar Sync alle 5 oder 10 Minuten laufen und wir haben immer einen konsistenten Zustand in unserem System. Das heißt, nachdem der Sync einmal gelaufen ist, keine Abweichung zum Solstand in Netbox und zum Stand im Produktivsystem. Der Nachteil ist, wir haben nicht diese rigorose Kontrolle wie beim vollständigen Export mit dem Git Workflow und wir haben halt eben die aufwendigere Logik zum Beispiel in Isingar oder in den Skripten. Das waren auch schon die drei Methoden, die ich so vorzustellen habe. Kurzes Fazit, Autosync ist für uns die beste Kompromisslösung. Wir haben sowohl die Geschwindigkeit und die Automatisierung, die wir über den Webhook hätten, also eine ähnliche Geschwindigkeit als auch die Konsistenz, die wir über den Vollständigen Export haben. Den vollen Export verwenden wir in Einzelfällen, wo wir es eben haben wollen, zum Beispiel für unser Puppet, wo wir auch die Business Prozesse modellieren wollen und man könnte sich vorstellen, die Webhooks noch zusätzlich zu verwenden, wenn es eben besonders schnell gehen soll. Noch ein bisschen Ausblick, was es ansonsten noch im Horizont gibt. Es gibt ein Netbox Fork, der nennt sich Nautobot. Der bietet einige nette Features, zum Beispiel dieses Konfigurationsmanagement ist da schon sehr schön abgebildet. Allerdings wird das halt sehr komplex und verfolgt nicht mit diesem keep it simple Ansatz von Netbox. Man könnte diese Prozessabbildung auch mit einem Plug-in machen. Da gibt es einen netten Vortrag von der Wobcom aus Wolfsburg bei der Denok 11. Da habe ich ja auch verlinkt, die das quasi über einen Eigen Fork schon gelöst haben und ihren Business Prozess und den Change Management über Netbox abbilden. Das war es so weit von mir. Wenn es Fragen gibt, jetzt gerne eine kleine Diskussion, da würde ich mich freuen. Ansonsten meine Webseite und meine Mail Adresse stehen hier. Vielen Dank für die Aufmerksamkeit. Ja, vielen Dank Wotti für diesen interessanten Talk. Hallo Nix. Es gibt jetzt noch eine kleine Frage runter. Das habe ich wegen der Maske. Dafür haben wir Wotti jetzt hier live zugeschaltet. Bisher haben wir hier nur eine Frage in unserer Liste und zwar, kann denn Netbox die Netzwerktopolegik grafisch darstellen? Wotti. Die Topologie an sich nicht. Wenn man physikalische Kabel hat, kann man sich die tracen. Also man kann dann gucken, das Kabel geht von dem Switch in ein Patch-Panel weiter in einen anderen Switch und man kann auch Circuits darstellen. Also wenn man jetzt irgendwo von einem Anbieter ein NPS-Netzwerk an den NPS-Netz hat, dann kann man das auch darstellen. Aber man kann jetzt nicht die logische Struktur von einem Netzwerk in Netbox virtualisieren. Okay, vielen Dank. Ansonsten möchte ich noch mal darauf hinweisen, falls es jetzt noch Fragen gibt, gerne stellen im IRC unter RC3-FAM, alternativ auch auf Twitter oder im Fediverse unter Hashtag RC3-FAM. Und dann werden wir die hier auch noch mal vorlesen und die werden dann von Wotti beantwortet. Genau. Ansonsten wer jetzt keine Frage stellen will, wir haben ja nachher noch eine Breakout-Session geplant. Also wer noch mit mir reden will oder allgemein alle möglichen Leuten, die sich über Netbox unterhalten wollen, wir können das nachher im virtuellen FAM-Office treffen in der RC3-Welt. Danke für den Link. Genau. Also hier ist noch mal kurz der Link eingeblendet. Ansonsten findet ihr uns auch, wie gesagt, in der FAM Assembly in der RC3-Württ. Aber auch über die Webseite von RC3. Gut, also scheint ansonsten jetzt keine weiteren direkten Fragen zu geben. Von daher würde ich jetzt einfach sagen, sehen wir uns dann in der RC3-Württ. Genau. Ansonsten für alle, die weiter einschalten wollen, um 22 Uhr findet hier der nächste Talk statt und zwar geht es um Frozen Waves. Hier hat ein Team ein System entworfen, um Gänsehaut in einem Publikum zu messen oder auch direkt zu induzieren. Und natürlich jetzt direkt im Anschluss die Verkehrsnachrichten.