Das passende VLAN
In einigen Netzwerkumgebungen erfolgt eine strikte VLAN-1-Vermeidung. Dies bedeutet, dass auf Uplinks zwischen Switches der Traffic durch Änderung des Native-VLANs und Beschränkung der übertragenen VLANs nicht über das VLAN 1 läuft. Das genannte Verfahren empfiehlt sich, da bestimmte Traffic-Arten – zum Beispiel Layer-2-Only-Management-Protokolle wie das Cisco Discovery Protocol (CDP) oder die Unidirectional Link Detection (UDLD) – immer über das VLAN 1 laufen und somit nicht von anderem Datenverkehr in diesem VLAN separierbar wären.

Sollte eine solche VLAN-1-Vermeidung im Einsatz sein, können Sie auf dem Upstream-Switch mit dem Kommando pnp startup vlan <X> die VLAN-Definition des DHCP- und PnP-Prozesses durchführen. Zusätzlich findet neben der reinen VLAN-Separierung in einigen Fällen eine zusätzliche Abstraktionsebene des Routings Verwendung. Dies ist häufig in mandantenfähigen Netzen oder bei logisch dedizierten Managementnetzen der Fall und kommt insbesondere bei MPLS-Netzen zum Einsatz. Sollte ein solcher dedizierter Management-VRF eingerichtet sein, könnte in einer Bootstrap-Konfiguration ip http client source-interface <X/Y> zur Festlegung der Quellschnittstelle im Management-VRF erforderlich sein.

Um zu klären, ob die jeweils zu provisionierende Komponente PnP in der eingesetzten Betriebssystemversion unterstützt, werfen Sie einen Blick in die Release Notes der Komponente und des DNA-Centers.

ZTP – Provisionierung ohne proprietären Server
Eine Alternative bietet der Zero-Touch-Provisioning-(ZTP)-Dienst in IOS-XE. ZTP funktioniert ähnlich zu PnP, jedoch ist kein proprietärer Server notwendig. Stattdessen bietet dieser Dienst viele Freiheiten und lässt sich an heterogene Umgebungen mit unterschiedlichen Herstellern und Plattformen anpassen. Auch bei dieser Variante ist ein DHCP-Server erforderlich. Jedoch kommt hierbei die Option 67 für die URL zum Provisierungsskript zum Einsatz. Alternativ können auch andere Transportprotokolle wie etwa TFTP Verwendung finden:

ip dhcp pool ZTP
network 10.0.0.0 255.255.255.0 default-router 10.0.0.1
option 67 http://10.1.1.10/configs/ztp.py

Der grobe Ablauf von ZTP besteht darin, dass ein Switch oder Router ohne Startkonfiguration bootet. Nach dem DHCP Prozess startet eine Python-Guest-Shell. Innerhalb dieser lädt das Gerät das Python-Provisionierungsskript herunter und führt es aus. Ein Beispiel eines solchen Python-Skripts geben wir im Listing-Kasten links. Wir prüfen innerhalb des Skripts die Seriennummer mit der Funktion "cli.executep(ver)" und führen über die Funktion "cli.configurep()" Kommandos im Konfigurationsmodus aus.

Das Skript im Listing-Kasten könnte zum Beispiel auch automatisiert bei Anlegen eines neuen Geräts in einem Netzwerkmanagement- oder Inventarisierungssystem über eine Template-Engine, wie zum Beispiel das Python-Modul Jinja, angepasst werden.

Boot-Loader-Variante iPXE
Im Gegensatz zu den vorgenannten Verfahren setzt iPXE nicht auf einem funktionierenden Betriebssystem, sondern auf einem Bootloader auf. Dieser versetzt ein System nach dem Laden in die Lage, eine Netzwerkquelle für das zu startende Software-Image anzusprechen. Hierbei können, wie auch beim ZTP-Prozess, unterschiedliche Datei-Transferprotokolle wie TFTP, FTP oder HTTP zum Einsatz kommen. Aktuell kann ein iPXE-Boot nur über einen dedizierten Management Port und nach vorheriger Konfiguration (Bootstrap) erfolgen.

Hierfür muss nach dem DHCP-Prozess auf dem PXE-Server ein bootfähiges Image bereitstehen. Eine Aktivierung des iPXE-Prozesses erfolgt mit dem CLI-Kommando boot ipxe timeout <X> für den nächsten Gerätestart mit einem Timeout in konfigurierbaren Sekundenschritten. Nach dem Timeout findet ein Start des auf dem Gerät installierten Betriebssystems statt. Ein Auszug der Konfiguration eines ISC-Servers für iPXE sieht folgendermaßen aus:

host SW1{
     fixed-address 10.0.0.2; hardware ethernet AA:AA:AA:AA:AA:AA ;
if exists user-class and option user-class = 00:00:00:00:01 {
     filename "http://10.1.1.10/pxe.bin;"
     }
}

Altes Verfahren AutoInstall
Bei reinen IOS-Systemen, die noch sehr häufig eingesetzt werden, sieht der Provisionierungsprozess etwas anders aus. Einige wenige bieten zwar PnP-Unterstützung, dies bildet aber die Ausnahme. Viele Systeme laden jedoch bei fehlender Startkonfiguration fix benannte Konfigurationsdateien von einem TFTP-Server gemäß der TFTP-Serverangabe in DHCP-Option 150 herunter. Hierbei handelt es sich um die Dateien "network-confg", "cisconet.cfg", "router-confg" und "ciscortr.cfg", wobei im Normalfall nur die erste Datei "networkconfg" angefragt wird. Der Name des Verfahrens lautet AutoInstall. Es kommt zum Beispiel auch beim Open-Source-Tool FreeZTP zum Einsatz. In unserem Beispiel steht die Datei "network-confg" auf einem TFTP-Server zum Download bereit. Auf diesen TFTP-Server wird durch die DHCP-Option 150 verwiesen. Für jeden Switch/Router besteht eine DHCP-Reservierung gemäß seiner MAC-Adresse. In unserem Fall findet für den Switch SW1 eine DHCP-Reservierung der IP-Adresse 10.0.0.2 statt. Diese Reservierung lässt sich zur Automatisierung dynamisch aus einem Netzwerkmanagementsystem generieren. Beispiel einer "network-config" mit statischer Zuweisung:

ip host sw1 10.0.0.2

end

Konnte der Client nach dem Bootprozess seine Startkonfiguration nicht finden, startet er den AutoInstall- und folglich den DHCP-Prozess. Im DHCP-Prozess erlangt er neben der IP-Adresse, der Subnetzmaske und dem Default-Gateway noch die Option 150 für den TFTP-Server. Er fragt bei diesem TFTP-Server nun die Datei "network-confg" ab. Der Switch überprüft, ob es darin ein Reverse-Mapping seiner per DHCP erhaltenen IPv4-Adresse zu einem Hostnamen gibt. Ist dieses Mapping vorhanden, fragt er wiederum beim gleichen TFTP-Server die Datei "sw1-confg" ab. In dieser Datei können dann die spezifischen Konfigurationsdaten für den Switch stehen. Alternativ zum statischen Host-Mapping in der "network-confg" ist auch ein DNS-Mapping auf einem DNS-Server möglich, der zuvor per DHCP an den Switch verteilt wurde.

Die Konfiguration ließe sich über ein Jinja-Template im Zusammenhang mit Ansible generieren. Wenn es der Server, auf dem auch der TFTP-Server läuft, hergibt, sollte ein Trigger für einen Prozess erfolgen, der es ermöglicht, nachgelagerte Prüfungen wie etwa E-Mail-Benachrichtigungen an Administratoren zu übermitteln. Dies erlaubt es, die Konfiguration des Switches nach der Provisionierung zu überprüfen. Es wäre auch möglich, über den Trigger nach dem Download aller Konfigurationsdateien und einer bestimmten Zeit ein Ansible-Playbook laufen zu lassen, das die Konfiguration überprüft und den Integrator vor Ort über den Status der Provisionierung informiert, ohne dass dieser Kenntnisse oder Zugriff auf der CLI benötigt. Dieser wäre ansonsten auf die Unterstützung von Administratoren mit CLI-Zugriff angewiesen.

Fazit
Welche Art des Zero-Touch-Provisioning die passende für die jeweilige Systemumgebung darstellt, hängt von den eingesetzten Komponenten, dem Budget, dem Wissensstand der Administratoren und dem gewünschten Automatisierungsgrad ab. ZTP-Verfahren vereinfachen und vereinheitlichen Rolloutprozesse auch für aktive Netzwerkkomponenten. Der zeitliche Schwerpunkt des Gesamtprozesses verlagert sich dabei von der Rollout-Phase in die Vorbereitungsphase.

dr/ln/Benjamin Pfister

Im ersten Teil der Workshopserie haben wir am Beispiel von Cisco die möglichen Rollout-Verfahren skizziert und beschrieben, welche Ansätze und Möglichkeiten sich Unternehmen hier bieten. Im zweiten Teil schilderten 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.