Network-Plug-and-Play – Proprietärer Ansatz mit GUI
Die vom Hersteller präferierte, aber auch kostenintensivste Variante stellt Network-Plug-and-Play dar. Diese setzt eine entsprechende zentrale Provisionierungsplattform auf Basis des Software-defined-Networking-Controllers Cisco-DNA-Center voraus. DNA-Center bietet eine GUI-basierte Konfiguration und einen vom Hersteller gepflegten Prozess für die Provisionierung.

Wir müssen zwischen unterschiedlichen Arten der Provisionierung differenzieren. So besteht die Möglichkeit einer geplanten und einer ungeplanten Provisionierung. Wir gehen in unseren Beispielen von einem klassischen Netz und einem geplanten Rollout aus. Im ersten Schritt erfolgt auf dem DNA-Center das Anlegen von Standorten/Sites und das Hinterlegen der Infrastrukturdienste wie DNS- und NTP-Serverinformationen. Um im späteren Verlauf ein automatisiertes Update des IOS-XE auf die von der jeweiligen Organisation freigegebene Version zu ermöglichen, laden wir die entsprechende Datei in das Repository im DNA-Center hoch und weisen sie dem entsprechenden Modell zu.

Im nächsten Schritt legen wir das Template für Plug-and-Play an. Der zugehörige Editor fußt auf der Java-basierten Template-Engine Apache Velocity. Seit Version 2.1.2 von DNA-Center besteht auch die Möglichkeit, Jinja-Templates einzusetzen. Jinja stellen wir in einem anderen Artikel dieses Sonderhefts vor. Daher konzentrieren wir uns in diesem Artikel auf das PnP mit Velocity. Im Template erfolgt die Parametrisierung einer Vorlage für das Command Line Interface (CLI), also Konfigurationen mit zu ersetzenden gerätespezifischen Variablen, wie zum Beispiel dem Hostnamen.

Diese Variablen sind jeweils mit dem Präfix "$" gekennzeichnet. An dem "V" neben dem Template-Namen erkennen Sie, dass es sich um ein Velocity-Template handelt. Zusätzlich ist eine Validitätsprüfung der Vorlage möglich. Hierbei erfolgt jedoch lediglich ein Check gegen Velocity-Syntax-Fehler oder Konflikte gegen Blacklist-Kommandos, nicht aber gegen Konfigurationsfehler für das spezifische Zielsystem. Es ist im DNA-Center eine Zuweisung des Templates an spezifische Gerätetypen möglich. Dies kann erforderlich sein, da einige CLI-Befehle nur auf bestimmten Gerätetypen mit einer spezifischen Softwareversion zur Verfügung stehen. Des Weiteren besteht die Möglichkeit, ein Template mit Testdaten zu simulieren. Somit können Sie, ohne eine Testkomponente in Betrieb zu nehmen, direkt das Ergebnis des erstellten Templates prüfen und gegebenenfalls korrigieren.

Die Anwendung der CLI-Kommandos in den Templates erfolgt direkt im Konfigurationsmodus der Komponente. Zusätzlich besteht die Möglichkeit, zwischen den Tags "#MODE_ENABLE" und "#MODE_END_ENABLE" Kommandos im privilegierten EXEC-Modus auszuführen, wie wir dies nachfolgend auf Basis einer Speicherung der Konfiguration über write memory darstellen:

#MODE_ENABLE
write memory
#MODE_END_ENABLE

Da das CLI der Komponenten primär auf Benutzerinteraktion anstatt Maschine-Maschine-Schnittstellen ausgelegt ist, kann es auch notwendig sein, interaktive Dialoge handzuhaben. Dies ist ebenfalls möglich im Bereich zwischen "#INTERACTIVE" und "#END_INTERACTIVE". Die Frage im Interaktiven Dialog "<IQ>" kann im Anschluss an die Response "<R>" gestellt werden. Im folgenden Beispiel erfolgt eine Beantwortung der Anfrage zur Generierung eines SSH-Keys mit "yes":

#INTERACTIVE
crypto key generate rsa general-keys modulus 4096 <IQ>yes/no<R> yes
#ENDS_INTERACTIVE

Um Multiline-Kommandos abzusetzen, wie zum Beispiel für verschiedene Banner, betten Sie den Befehl in die beiden Tags "<MLTCMD>" und "</MLTCMD>" ein:

<MLTCMD>
banner exec ^
========================
Topsecret Device
========================
</MLTCMD>

Des Weiteren gibt es diverse zusätzliche Möglichkeiten, wie die Auslagerung wiederkehrender Konfigurationsteile in Makros oder for-Schleifen, die jedoch den Rahmen dieses Artikels sprengen würden.

Im nächsten Schritt kommt ein sogenanntes Network Profile im Design-Bereich des DNA-Centers zur Anwendung. Darin erfolgt eine Verknüpfung des Templates und der Site, also dem Standort, zu einem Network-Profile-Namen. Danach legen wir den zu provisionierenden Router oder Switch an. Für einen größeren Rollout ist es ebenso möglich, einen CSV-Import der zu provisionierenden Komponenten vorzunehmen.

An die Gegebenheiten anpassen
Nachdem ein Import der zu provisionierenden Komponente stattgefunden hat, ist nun das sogenannte "Claiming" möglich. Dabei werden der Komponente ein Standort und ein Template sowie spezifische Variablen zugewiesen. Die Ersetzungen für zentrale Dienste, wie zum Beispiel NTP- oder Syslog-Server, können nicht nur gerätespezifisch, sondern auch über sogenannte "Global Network Settings" erfolgen. Zusätzlich besteht die Möglichkeit der Zuweisung eines vordefinierten Zielbetriebssystems, das wir im ersten Schritt in das Repository hochgeladen haben. Dies kann über ein sogenanntes Golden-Image erfolgen. Dabei handelt es sich um ein global auf eine Geräteart zugewiesenes Image, das für den Einsatzzweck geprüft wurde.

Auch benötigen wir einen DHCP-Server mit konfigurierter Option 43, der auf die IP-Adresse des Plug-and-Play-Servers verweist. Nach dem Anschalten der Komponente und fehlender Startkonfiguration startet das Gerät nach kurzer Zeit den Plug-and-Play-Agenten und versucht per DHCP, IP-Adressinformationen zu erhalten. Wichtig ist, dass keine Eingaben auf der Konsole erfolgen, da hiernach der Plug-and-Play-Prozess nicht mehr auslöst. Bei einem eingehenden DHCP-Discover mit dem Inhalt "ciscopnp" in der Option 60 wird vom DHCP-Server die Option 43 mit den spezifischen Parametern für den PnP-Server zurückgeliefert.

Ein Beispiel der Konfiguration auf einer IOS-XE-Komponente sehen Sie nachfolgend. Alternativ könnte auch eine Zuweisung eines DNS-Servers stattfinden, auf dem wiederum der Plug-and-Play-Server mit dem Hostnamen "pnpserver" und ein NTP-Server namens "pnpntpserver" hinterlegt sind. Der PnP-Agent würde dann versuchen, PnP-Server mit dem Namen "pnpserver" in der lokalen Domäne aufzulösen und zu erreichen:

ip dhcp pool PnP
network 10.0.0.0 255.255.255.0
default-router 10.0.0.1
domain-name intern.example.com
dns-server 10.1.1.20
option 43 ascii "5A1N;B2;K4;I10.1.1.10;J80"

Der Inhalt der DHCP-Option 43 definiert sich wie folgt:

5A1N; = DHCP-Suboption für PnP
B2; = IPv4
K4; = Transport-Protokoll (in diesem Fall HTTP)
Ix.x.x.x = IPv4-Adresse
Jxxxx = Port-Nummer für die Verbindung zum PnP-Server

Mit K5 und J443 könnte auch HTTPS zum Einsatz kommen. Insbesondere bei der Übertragung der Credentials zum Endgerät bietet sich dies an. Vereinfacht gesagt durchläuft ein PnP-fähiger Router oder Switch bei nichtvorhandener Startkonfiguration den DHCP-Prozess und erhält IP-Adressdaten sowie zusätzlich die PnP-Serverinformationen über Option 43. Falls die Option 43 im korrekten Format gesetzt ist, initiiert das Device den Download der gerenderten Konfiguration und gegebenenfalls des zugewiesenen Betriebssystems im PnP-Server.

Sollte, wie zum Beispiel in einem WAN-Deployment, kein DHCP-Server erreichbar sein, stellt dies auch kein Problem dar. Über eine App für mobile Endgeräte und ein spezielles Kabel zur Verbindung mit der seriellen Schnittstelle des Switches/Routers besteht die Möglichkeit, eine sogenannte Bootstrap-Konfiguration durch einen Installateur vor Ort einzuspielen, um eine Konnektivität mit dem PnP-Server herzustellen (etwa mittels PPPoE-Einwahldaten). Bei einigen Modellen ist auch eine Bootstrap-Konfiguration über einen USB-Stick möglich. Dabei prüft die Komponente, ob die Dateien "router-confg", "router.cfg" oder "ciscortr.cfg" vorhanden sind und lädt diese, sofern sie bereitstehen.

Soll diese Bootstrap-Konfiguration ebenfalls von einem zentralen Standort aus er folgen, besteht die Möglichkeit, dies zum Beispiel über AirConsole und einen AirConsole-Enterprise-Server zu erledigen. Bei AirConsole handelt es sich um einen akkubetriebenen Serial-Port-Server. Hierbei kann per WLAN oder Bluetooth eine Kopplung zu einem Smartphone stattfinden. Dessen Internetverbindung dient der TLS-Verbindung zu einem zentralen Terminalserver, in diesem Fall dem AirConsole-Enterprise-Server.

Über den Terminalserver kann der entsprechend geschulte Administrator die Bootstrap-Konfiguration per entfernter Terminal-Session vornehmen. Alternativ besteht die Möglichkeit, vordefinierte Skripte von diesem Server oder aus der zugehörigen App abzuspielen, um die Bootstrap-Konfiguration zu erstellen.

dr/ln/Benjamin Pfister

Im dritten Teil der Workshopserie gehen wir auf weitere Varianten ein, etwa die ZTP-Provisionierung ohne proprietären Server, die Boot-Loader-Variante iPXE oder das alte Verfahren AutoInstall. Im ersten Teil haben wir am Beispiel von Cisco die möglichen Rollout-Verfahren skizziert und beschrieben, welche Ansätze und Möglichkeiten sich Unternehmen hier bieten.