Neben der Geschwindigkeit bei einer Zero-Touch-Provisionierung muss die Vor-Ort-Installation nicht mehr durch geschultes und entsprechend teures Personal erfolgen. Jedoch wirken die automatisierten Provisionierungsprozesse für viele Konsolen-fokussierte Netzwerkadministratoren noch wie aus einer anderen Welt. Im Gegensatz zu Prozessen bei Servern und Clients besteht die Herausforderung darin, dass die Infrastruktur noch nicht fertig bereitsteht, sondern zunächst teilweise ausgerollt werden soll. Viele Hersteller bieten hierfür aber bereits seit geraumer Zeit vorbereitete Verfahren. Diese bringen jedoch meist nur einen Werkzeugkasten mit und erfordern noch eine Anpassung an die kundenspezifischen Anforderungen. Wir möchten verschiedene Lösungsansätze auf Basis von Komponenten des Herstellers Cisco Systems darstellen. Die Ansätze sind jedoch in vielen Fällen auf die Verfahren anderer Hersteller anpassbar.

Meist exportiert die IT-Abteilung beim Rollout noch die Konfigurationen von Bestandssystemen und passt die Lokations- und System-spezifischen Daten entsprechend an. Sinnvoller wären bereits Templates, etwa auf Basis einer Template-Engine wie das in diesem Sonderheft vorgestellte Jinja2. Dies würde eine verringerte Fehlerhäufigkeit und eine höhere Konsistenz mit sich bringen. Häufig sind auch nicht einmal die Prozesse für die Provisionierung niedergeschrieben und die Administratoren fokussieren sich jeweils nur auf die möglichst fehlerfreie Konfiguration der Komponenten durch Copy-und-Paste auf Basis von bestehenden Konfigurationen. Hingegen verlagert sich beim Zero-Touch-Provisioning die Zeitplanung vom Rollout in die Vorbereitungsphase. Dies vermeidet Lastspitzen bei den Administratoren im Projekt – insbesondere an Rollout-Tagen.

Zwei Rollout-Verfahren
Trotzdem scheuen viele den Aufwand. Natürlich ergibt ein Zero-Touch-Provisioning für ein Netzwerk mit fünf Switchen keinen Sinn. Aber gerade bei Firmen mit diversen Standorten im In- und Ausland zahlt sich die Investition meist schnell aus. Administratoren oder Systemintegratoren müssen nicht mehr quer um den Erdball fliegen, um einen Router zu installieren. Je nach Aufbau des Supportkonzepts der jeweiligen Organisation kommen zwei unterschiedliche Verfahren des Rollouts zum Einsatz. Beim ersten Verfahren erfolgt zur Vorkonfiguration ein Versand der Komponenten an eine zentrale IT-Abteilung, dort erhalten die Geräte ihre initiale Software und Konfiguration. Im Anschluss erfolgt das Verschiffen an die Ziellokation für den Einbau.

Die zweite Variante bedingt Know-how für die Konfiguration am dezentralen Standort. Dies stellt in Anbetracht des aktuellen Fachkräftemangels ein Problem dar. Auch während der Corona-Pandemie konnten einzelne Personen zeitweise nicht in bestimmte Regionen einreisen. Dabei zeigte sich ein zusätzlicher Vorteil automatisierter Provisionierungsprozesse: Diese bieten eine zeitliche Straffung der gesamten Rollout-Phase.

Hierbei ist es nicht mehr notwendig, die Komponenten zur Provisionierung vom Hersteller oder Distributor an einen zentralen Standort der IT-Abteilung zu senden und erst nach manueller Konfiguration weiter an den Standort weiterzureichen, an dem der Einbau erfolgt. Das bietet die Möglichkeit, vor Ort ohne eine Person mit Fachkenntnis zur Konfiguration der Netzwerkkomponente auszukommen. Es reicht ein Mitarbeiter mit den nötigen Zugangsberechtigungen für den Hardware-Einbau und die Verkabelung aus. Neben der Ersteinrichtung lassen sich auch Austauschprozesse über Zero-Touch-Provisioning vereinfachen. Die in diesem Artikel dargestellten Konfigurationsbeispiele sind lediglich zur Erklärung der Verfahren gedacht und stellen keine vollständigen Konfigurationsdateien für den produktiven Einsatz dar.

Ansätze und Möglichkeiten
Zunächst ist vor Auswahl eines passenden Verfahrens für die eigene Organisation oder den Kunden eine genaue Betrachtung der zu parametrisierenden Komponenten notwendig. Zum Beispiel müssen Router, die eine PPPoE-Einwahl benötigen, einen anderen initialen Provisionierungsprozess erfahren als Access-Switche, die über eine Lichtwellenleiter-Anbindung mit einem Core- oder Distributionsswitch verbunden sind. Aber auch der Einsatz von Verschlüsselungsmethoden wie MACsec kann eine Provisionierung erschweren. Zusätzlich besteht die Notwendigkeit einer Gruppierung der Komponenten in Konfigurationsgruppen. Diese bilden die unterschiedlichen Bedürfnisse an Standardkonfigurationen und Standorten ab.

Hierzu ein Beispiel zur Verdeutlichung: Ein Access-Switch in New York benötigt eine andere Konfiguration als ein Distributionsswitch in Frankfurt, weil zum Beispiel andere VLANs, NTP- und RADIUS-Server zum Einsatz kommen. Ein bestehendes Netzwerkmanagementsystem bietet häufig die Möglichkeit, die benötigten Inventardaten zu generieren. Diese verfügen in vielen Fällen auch schon über eine Gruppierung, die als Grundlage dienen kann.

Gerade diese Definition der "Single Source of Truth", also der zentralen Datenquelle mit allen benötigten Daten zur Generierung von Konfiguration, stellt eine der größten Herausforderungen im Gesamtprozess bei allen Automatisierungslösungen im Netzwerk dar. Gegebenenfalls muss auch zunächst ein Aufbau einer solchen Quelle erfolgen, bevor das Projekt beginnen kann.

Die meisten Verfahren bauen für Zero-Touch-Provisioning auf das Dynamic Host Configuration Protocol (DHCP) auf. Über den DHCP-Prozess erfolgt sowohl die Verteilung der IP-Adressinformationen als auch der Erreichbarkeitsinformationen des Provisionierungsservers sowie der entsprechenden Ressource auf diesem Server. Als Verteilpunkt für Konfigurationen und Images kommt meist das UDP-basierte Trivial File Transfer Protocol (TFTP) oder das TCP-basierte Hypertext Transport Protocol (HTTP) zum Einsatz. Die Verfahren unterscheiden sich dann im Management sowie in der Back -end-Logik und der Anbindung an Inventarisierungssysteme.

Die Konfiguration wird dann aus der Datenquelle, die wir bereits genannt haben, und dem Template erzeugt. Hierfür kommen je nach eingesetzter Lösung unterschiedliche Template-Engines, wie zum Beispiel Apache Velocity oder Jinja2, zum Einsatz. Als Datenquelle können zum Beispiel Inventarisierungsdaten von Konfigurationsmanagement-Werkzeugen wie Ansible, gegebenenfalls auch in Kombination mit AWX, wie wir es in einem anderen Artikel dieses Sonderhefts darstellen, oder SQL-Datenbanken zum Einsatz kommen.

Eine zusätzliche Herausforderung stellt noch die Verteilung der in der jeweiligen Organisation getesteten und freigegebenen Betriebssystem-Versionen dar. Die Komponenten sollten sich diese möglichst vor der Konfiguration automatisiert ziehen. Ansonsten könnte es zu Problemen beim Anwenden der Konfigurationen kommen, sollten gegebenenfalls in einer veraltet ausgelieferten Version einzelne Kommandos nicht verfügbar sein oder nur in einem anderen Dialekt zur Verfügung stehen. Zudem soll ein späteres manuelles Update erspart und eine Vermeidung von bereits behobenen Bugs erreicht werden.

Wir wenden in unserem Beispiel Systeme auf Basis von Ciscos Netzwerkbetriebssystem IOS-XE an. Bei diesen gibt es drei unterschiedliche Verfahren zur Provisionierung. Dies beginnt beim bekannten Verfahren Preboot-Execution-Environment (iPXE), das viele bereits aus dem Client-Rollout kennen. Zusätzlich stehen das sogenannte Zero-Touch-Provisioning (ZTP) und das Cisco-proprietäre Network-Plug-and-Play (PnP) zur Verfügung.

dr/ln/Benjamin Pfister

Im zweiten Teil der Workshopserie schildern wir den proprietären Cisco-Ansatz "Network-Plug-and-Play", der über eine GUI erfolgt und bei dem sich die ausgerollten Komponenten an die Gegebenheiten im Netzwerk anpassen lassen.