NetBox als Datenquelle für Netzwerkinfrastruktur

Herald: Ja, herzlich willkommen
zur Halbzeit hier auf dem Kanal von der

FeM, der nächstes BK heißt Votti
(Votteler). Er war mal vor einiger Zeit

bei uns in der FeM aktiv, hat dort bereits
einiges an Netzwerk Infrastruktur

administriert und mittlerweile arbeitet er
bei einem richtigen ISP und zeigt uns

heute, wie er mithilfe von NetBox dort
diverse Teile der Netzwerk Infrastruktur

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 RC3Fem oder auch
unter dem Hashtag rc3Fem. This Talk also

will be translated into the english
language. To receive the english translation

english translation audio stream using
selection tool in the web player. Und nun

viel Spaß mit dem Talk.

Votteler: Hallo und herzlich willkommen zu
meinem Vortrag zum Thema NetBox als

Datenquelle für Netzwerk Infrastruktur.
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
andere Netzwerkedienste. Dabei geht es

explizit nicht um die Generierung von
Geräte config, sondern um die ganzen

Systeme, die man so drumherum hat, wie zum
Beispiel ein Monitoring System. Der ganze

Vortrag ist kurz gehalten und als
Diskussionsanstoß gedacht und ich werde

mich auf Feedback und Umfragen und
Diskussionen im Anschluss freuen. Kurz zu

mir. Mein Name ist Alexander Votteler. Den
meisten hier werde ich bekannt sein als

votti. 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 C3Wok
anzutreffen. Aktuell mache ich eine

Ausbildung bei Relax Networks in Aachen.
Dann zu NetBox. Der Vortrag richtet sich

so ein bisschen an Leute, die sich damit
auskennen, das vielleicht schon selbst im

Einsatz haben, weil es trotzdem einen
kurzen Einstieg daran bieten. Was ist

NetBox? Ist ein Tool zur Dokumentation von
IT-Infrastruktur. Es ist dabei ein iPam,

ein IP Adress Management und ein DKIM, ein
Data Center Infrastruktur 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 wird 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, werde ich jetzt kurz ne Demo

bieten. Man sieht ja so den Login Screen
bevor man eingeloggt ist in NetBox. Da

sieht man schon welche ganzen Objekte wir
hier verwalten können. Ich glaube mich

jetzt einfach mal ein. Wir sehen wie
gesagt Organisatorisches Datacenter

Inventar, Wracks und Geräte, man kann
Kabel modellieren und alle IP-Adressen.

Ich gucke jetzt einfach mal die Geräte an.
Geräte Liste, wir haben den 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 Access Switch an. Haben wir
wieder die ganzen Informationen, die wir

gerade schon gesehen haben. Wir sehen aber
auch zum Beispiel auch, in welcher Höhen

Einheit das verbaut ist. Noch mal den Typ
und das Betriebssystem. Können auf

Interfaces klicken, sehen hier, es gibt
Interfaces, die sind verknüpft mit anderen

Geräten wiederum und haben IP-Adressen.
Können uns jetzt einfach mal die primäre

IP-Adresse des Gerätes angucken und sehen
hier wieder Informationen dazu, welche IP-

Adresse Familie das ist, wem du zugewiesen
ist den Status DNS Name. Das Assignement,

auf welches Gerät das zugewiesen ist und
welches Interface. Wir sehen auch die IP-

Adresse ist Teil eines Prefix, also
unserem Platz können hier wiederum auf das

Präfix Object klicken. Wieder allerhand
Informationen können sehen, welche IP-

Adresse am ist in dem Netzwerk gibt,
könnten es hier auf die freien IP-Adressen

klicken. NetBox würde uns die nächste
freie IP-Adresse

vorschlagen. Sie will hier anlegen können
mit DNS, Name und INAT nformation und

Interface Zugehörigkeiten. Was können wir
allgemein alles so NetBox abbilden, so als

Überblick. Wir haben organisatorisches
Geräte, also Geräte und Gerätetypen und

Komponenten, können aber auch die
Verbindung zwischen den Geräten und

abbilden mit Kabeln und kabellosen Links.
Wir haben IP-Adressen und Präfixen. Wir

konnten so autonomen 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 man vor
einem Host-Umgebung zu befüllen. Und wir

können NetBox zum Beispiel mit eigenen
Skripten auch erweitern und eigene

Funktionalitäten hinzufügen. Das ist alles
im 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 zu, wenn wir das

integrieren wollen mit anderen Diensten.
Das ist zum einen gibt es da eine Rest

API. Also einfach per http 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 Information mit einem Request

holen, die man vielleicht braucht. Und
NetBox bietet auch Webhooks, das heißt

NetBox schickt ein HTTP Request und ein
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
Netzwerk Infrastruktur rede, was meine ich

dann? Ich meine damit unser Monitoring-
Tool, das ist in dem Fall Icinga. Wir

haben auch noch Observium im Einsatz, um
weitere Statistiken einsammeln zu können.

Wir verwenden Rancid, um
Konfigurationsänderungen auf Switchen und

Routern zu verfolgen und wir wollen
PowerDNS einsetzen, um eben DNS 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 ZeroTouchProvisioning zwischen den

Systemen 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 Firmware. Es wird auch kurz
um Puppet gehen, dass unser Configuration

Management Tool für VMS vor allem. Und ich
möchte das Ganze jetzt einmal abbilden

oder anhand eines Ablaufs bei uns im
Unternehmen beschreiben, was mit NetBox

erreicht werden soll. Der Ablauf ist das
Anlegen neuer Geräte zum Beispiel neue

exist switches. Wie lief das bisher
ab? Man musste sich eine IP-Adresse

heraussuchen. Da gibt es in Legacy
Umgebung viele verschiedene Methoden.

Excel-Tabellen und irgendwelche Wikis VoIP
Adressen verwaltet wurden, dann muss man

das Gerät manuell konfigurieren. Eventuell
gibt es irgendwelche Vorlagen als

Textfiles, die 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ückmeldung

warten, ob das Gerät verbaut wurde. Dann
wird das ganze in die Icinga eingerichtet

in dem Monitoring, Observium, Rancid. Und
schlussendlich müssen wir das Ganze noch

dokumentieren. Wie soll das in Zukunft
ablaufen, wenn wir das, wenn wir dann

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 Skript 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 die freie App rausgesucht

wird, dass das Gerät als passenden Typ
angelegt wird und der Standort geknüpft

wird. Unser Zero Touch provisioning zieht
sich die Informationen aus NetBox,

generiert schon da Geräte config 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 bland in NetBox an. Also
geplant. Dann bekommen wir wieder unsere

Rückmeldung. Das Gerät wurde verbaut.
Daraufhin setzen wir NetBox den Status auf

aktiv und unser Icinga . Das Observium
und das rancid sollten dann 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

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 meine ich einen vollständigen
Export unseres Datenbestand des NetBox.

Das kann man sich automatisieren mit zum
Beispiel, Ci/CD-Pipleine. 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 Jammelfall generiert, mit

allen Informationen, die wir in Box haben,
bzw. mit allen Informationen, die wir für

so einen Host brauchen. Und daraufhin wird
automatisch ein Git-Commit angestoßen und

ein Merge-Request erzeugt, indem wir dann
die Änderungen, die wir gemacht haben,

noch mal als normal dargestellt bekommen.
In dem Beispiel hier wurde einfach nur

eine IP-Adresse geändert beziehungsweise
das Subnetz verändert. Dann können wir

sagen, Okay, diese Änderung ist hübsch,
die können wir mergen und haben das dann

direkt als Datenbestand im popit zur
Verfügung. Das funktioniert aber genauso

mit anderen Configuration Management
Tools, zum Beispiel mit Ensemble oder

soled stick. Diese Vorgehensweise hat
natürlich Vor und 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 z.B. in

Change Management Prozess, den wir
eventuell im Unternehmen etabliert haben,

damit abbilden. Nachteil ist, dass es mit
erheblichem Aufwand verbunden. Wenn wir

eine kleine Änderung machen, müssen wir
das im NetBox ändern, dann die Pipeline

anstoßen, dann den Merge 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 Merge

request. Aber im NetBox ist da 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 z. B. an einer IP-Adresse was

ändert, automatisch ein Request an diesen
Webhooks-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 oft entstehen, wenn z.
B. der DNS-Server das nicht

übernimmt oder da ein Fehler passiert beim
beim Webhoock, 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 NetBox machen, hat

er sofort eine Auswirkung auf unser
Produktivsystem und es gibt kein Weg, das

noch mal zu überprüfen. Eine andere
Methode, das Ganze zu machen, die wir

aber, die ich es präferiert habe, ist der
regelmäßige automatische Sync von

verschiedenen Diensten mit den
Datenbestände der NetBox. Da habe ich

jetzt von meinem GitHub ein Skript
hinterlegt, wo wir das mit PowerDNS

machen. Das Ganze hat immer den gleichen
Ablauf. Das sieht so aus: Wir holen uns

alle Einträge, die in dem System
existieren, zum Beispiel in DNS-Server.

Wir holen uns alle Einträge, die wir dazu
in NetBox haben, zum Beispiel alle IP-

Adressen und Host , die wir dazu
haben. Wir machen einen Abgleich: Was ist

im System, was ist eine NetBox? Und
daraufhin legen wir alles, was nicht im

System ist, aber in NetBox neu an. Und
alles was im System ist, aber nicht eine

NetBox wird gelöscht. Das ganze habe ich
per Script gelöst für PowerDNS und die

anderen Sachen sind damit auch noch in
Planung. Für Icinga gibt es eine

Sonderregelung, da gibt es nämlich den
Icinga Direktor. Das ist einfach so ein

Tool, um die Konfiguration von Icinga
direkt per GUI verwalten zu können. Und

dafür gibt es ein Netbooks Modul. Die
Konfiguration dafür ist recht aufwendig.

Deswegen zeige ich da kurz gleich ein paar
Screenshots und wir können aber auch nicht

alles abbilden, was Icinga bietet. NetBox
direkt dafür bietet NetBox aber so hübsche

Sachen wie den config Kontext. Das ist
einfach ein json-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 Isinga sieht es

dann so aus, wenn wir dieses Modul
installiert haben. Wir haben Import

Quellen, also unsere NetBox Objekte, zum
Beispiel Devices und API Adressen und VMS

und können darauf wieder Modifiers
anwenden, die die Daten so umbauen, dass

sie für uns in die Icinga dann passen. Das
ganze wird als Objekte in die Icinga

eingesenkt über eine synch rule für die
Devices oder IP-Adressen oder VMS. Und

dort gibt es dann wieder Properties, die
dann sagen, welches Feld aus NetBox soll

in welches Feld im Icinga wandern und auf
welchen, auf welche. Welche Vorbedingungen

erfüllt sein müssen, damit das Gerät oder
das Objekt in Icinga reingesynct wird. Und

auf die Objekte auf diesem Host zum
Beispiel können wir dann über Applayrules

wieder Services anwenden, zum Beispiel für
PGP Checks, die wir auf bestimmten Geräten

haben wollen. Können wir dann über die
Checks, die wir in dem Fall als Jason im

Konflikt Context angelegt haben, einmal
drüber iterieren mit so einer Apply for

rule und daraufhin einzelne Checks
erzeugen? Der regelmäßige Autosynch, was

hat der für Vor und Nachteile? Ein Vorteil
ist. Wir haben eine zeitnahe Wirkung der

Änderungen, die vergleichbar ist mit
Webhoock. Das heißt, wir lassen diesen

Sync entweder das Script oder und dann
Icinga Sync, alle fünf oder zehn Minuten

laufen und wir haben immer einen
konsistenten Zustand in unserem System.

Das heißt, wir haben, nachdem der Sync
einmal gelaufen ist, keine Abweichung zum

soll stand NetBox und zum zum Stand im produktiv
System. Der Nachteil ist, wir haben nicht

diese rigorose Kontrolle, wie beim
vollständigen Export mit dem Git

Workflow. Und wir haben eben die
aufwendigere Logik, z. B. im Icinga

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 ansonsten noch am
Horizont gibt. Es gibt ein NetBox Fork,

nennt sich Nautobot, der bietet einige
nette Features. Zum Beispiel dieses

Configuration Management 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 Plugin machen. Da gibt es einen

netten Vortrag von der VOB kom aus
Wolfsburg. Bei der DENIC 11 habe ich ja

auch verlinkt, die das quasi über den
eigenen Fork schon gelöst haben und ihren

Business Prozess unter Change Management
über NetBox abbilden. Das war so weit von

mir. Wenn es Fragen gibt, ist gerne eine
kleine Diskussion, da würde ich mich

freuen. Ansonsten meine Website, meine
Mailadresse stehen hier. Vielen Dank für

die Aufmerksamkeit.

Herald: Ja, vielen Dank Votti für diesen
interessanten Talk.

Votteler: Hallo, nix!
Herald: Es gibt jetzt noch eine kleine

Fragerunde. Erst habe ich wegen der Maske.
Dafür haben wir Votti jetzt hier live

zugeschaltet.
Votteler: Hi!

Herald: Ja, bisher haben wir hier nur eine
Frage in unserer Liste. Und zwar kann denn

NetBox die Netzwerk Topologie grafisch
darstellen?

Votteler: Die Topologie an sich nicht. Man
kann. Wenn man physikalische Kupferkabel

Kabel hat, kann man sich die tracen. Man
kann dann gucken. Das Kabel geht von dem

Switch in den Patch Panel weiter in
anderen Switch und man kann auch circles

darstellen. Also wenn man jetzt irgendwo
von einem Anbieter pls Netzwerk an das

Netz oder Dienst hat, dann kann man das
auch darstellen. Aber man kann jetzt nicht

die logische Struktur von einem Netzwerk
in der NetBox Virtualisierung

visualisieren. Genau.
Herald. Vielen Dank. Ansonsten ich möchte

noch mal darauf hinweisen, falls es jetzt
noch Fragen gibt gerne stellen im IRC

unter RC3-FeM, alternativ auch auf Twitter
oder unter Hashtag RPG 3 und dann werden

wir die hier auch noch mal vorlesen und
die werden dann sofort beantwortet.

Votteler: Genau, ja.
Herald: Ansonsten wäre jetzt keine Frage

stellen will. Wir haben ja nachher noch
eine Breack out session geplant. Also wer

noch mit mir reden will und allgemein alle
möglichen Leuten, die sich über NetBox

unterhalten wollen. Wir können uns nachher
im virtuellen FeM Office treffen. In der

RC3 Welt. Danke für den Link.
Herald: Genau hier ist nochmal kurz der

Link eingeblendet. Ansonsten findet ihr
uns auch wie gesagt in der FeM. Assembly

in der RC3 World aber auch über die
Webseite von RC3. So, gut es scheint

ansonsten wird es keine weiteren direkten
Fragen zu geben. Von daher würde ich jetzt

einfach sagen sehen wir uns dann in der
RC3 World.

Votteler. Genau.
Herald: So. Ansonsten für alle, die weiter

einschalten wollen. Um 22 Uhr findet hier
der nächste Tack statt und zwar geht es um

Frison 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 Verkehrs Nachrichten.

Untertitel erstellt von c3subtitles.de
im Jahr 2022. Mach mit und hilf uns!