Dieses Dokument beschreibt Power On Auto Provisioning (POAP) auf Cisco Nexus 9000-Switches mit Cisco NX-OS.
Cisco empfiehlt, dass Sie über Grundkenntnisse in diesen Themen verfügen:
| Komponente | Plattform/Software | Version/Wert | Zweck |
|---|---|---|---|
| Nexus Switch | N9K-C9336C-FX2 | NX-OS 10.6(2) | POAP-Gerät |
| Bereitstellungsserver | Ubuntu-Server | 24,04,5 LTS | Infrastruktur für externe Bereitstellung |
| DHCP/TFTP-Service | dnsmasq | 2.91 | Stellt DHCP- und TFTP-Dienste bereit |
Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.
Bei dieser Übung wird ein Cisco Nexus 9000-Switch verwendet, der direkt mit einem Ubuntu-Server verbunden ist, der die externe Bereitstellungsinfrastruktur bereitstellt.
Ziel ist es, die Topologie so einfach zu halten, dass der POAP-Workflow ohne zusätzliche Netzwerkgeräte zwischen dem Nexus-Switch und dem Bereitstellungsserver beobachtet werden kann.
Ethernet1/10 auf dem Nexus-Switch ist direkt mit ens224 auf dem Ubuntu-Server verbunden.

Für die Bereitstellung eines neuen Cisco Nexus-Switches ist eine Erstkonfiguration erforderlich, bevor das Gerät Teil des Netzwerks werden kann.
PowerOn Auto Provisioning (POAP) automatisiert diesen Bootstrap-Prozess. Wenn ein unterstützter Nexus-Switch ohne Startkonfiguration startet, kann Cisco NX-OS in den POAP-Modus wechseln, temporäre Netzwerkinformationen über DHCP abrufen, ein Bereitstellungsskript abrufen und dieses Skript verwenden, um das erforderliche Software-Image und die erforderliche Gerätekonfiguration bereitzustellen.
POAP ist in erster Linie mit der Erstbereitstellung (Day-0) verbunden, da der Switch die für die Bereitstellung erforderlichen Ressourcen beschaffen kann, ohne dass die vollständige Konfiguration manuell über die CLI eingegeben werden muss.
Ohne POAP kann die Erstbereitstellung eines Nexus-Switches eine manuelle Interaktion erfordern, um die Netzwerkverbindung zu konfigurieren, Konfigurationsdateien zu übertragen und das erforderliche Cisco NX-OS Software-Image vorzubereiten.
Mit POAP kann der Switch automatisch die Bereitstellungsinfrastruktur erkennen und die für die Bereitstellung erforderlichen Ressourcen abrufen.
Allgemein gilt, dass der POAP beginnt, wenn ein unterstützter Nexus-Switch ohne Startkonfiguration bootet. Der Switch startet den Bereitstellungsprozess und versucht, die Netzwerkinformationen abzurufen, die für den Zugriff auf die Bereitstellungsinfrastruktur erforderlich sind.
Nachdem die Netzwerkverbindung hergestellt wurde, ruft der Switch das POAP-Skript ab und führt es aus. Das Skript bestimmt das Software-Image und die Konfigurationsressourcen, die mit dem Gerät verknüpft sind, und steuert die verbleibenden Bereitstellungsvorgänge.
Der POAP-Prozess wird von Cisco in fünf Hauptphasen definiert:
Im nächsten Abschnitt wird die Rolle der einzelnen Phasen während des Bereitstellungsprozesses beschrieben.
Der POAP wird in Cisco NX-OS als stufenweiser Bootstrapping-Prozess ausgeführt. Jede Phase erfüllt eine bestimmte Funktion, die für die automatische Gerätebereitstellung erforderlich ist.
Ein Verständnis dieser Phasen bildet die Grundlage für den Implementierungs- und Verifizierungs-Workflow, der weiter unten in diesem Dokument beschrieben wird.
Wenn ein Nexus Switch hochgefahren wird, lädt Cisco NX-OS das installierte Software-Image und sucht nach einer Startkonfiguration.
Wenn eine Startkonfiguration vorhanden ist, fährt der Switch mit dem normalen Boot-Vorgang fort. Wenn keine Startkonfiguration gefunden wird, startet der POAP-Modus.
Während des Startvorgangs zeigt NX-OS eine Eingabeaufforderung an, die die Option zum Abbrechen des POAP und zum Fortsetzen des normalen interaktiven Setups bietet. Der POAP-Vorgang wird ohne Benutzereingriff fortgesetzt.
Wenn der POAP fortgesetzt wird, werden die Schnittstellen auf der Vorderseite in ihrer Standardkonfiguration festgelegt, bevor der Erkennungsvorgang beginnt.
| Bedingung | Ergebnis |
|---|---|
| Die Startkonfiguration ist vorhanden. | NX-OS fährt mit dem normalen Boot-Vorgang fort. |
| Die Startkonfiguration ist nicht vorhanden. | Der POAP-Modus wird gestartet. |
| POAP wird manuell abgebrochen. | NX-OS startet die normale interaktive Konfiguration. |
| Der POAP wird fortgesetzt. | Der Vorgang wird mit der USB-Erkennung fortgesetzt. |
Nach dem Start des POAP durchsucht NX-OS zugängliche USB-Geräte, um Ressourcen bereitzustellen.
Wenn ein POAP-Skript auf einem USB-Gerät gefunden wird, startet NX-OS die Skriptausführung. Wenn kein brauchbares Skript gefunden wird, wird der POAP mit der DHCP-Erkennung fortgesetzt.
Die USB-basierte Bereitstellung ist Teil des POAP-Workflows. Die Implementierung in diesem Dokument konzentriert sich jedoch auf die netzwerkbasierte Bereitstellung über DHCP.
Wenn während der USB-Erkennung kein POAP-Skript gefunden wird, startet der Switch die DHCP-Erkennung.
Während dieser Phase sendet der Switch DHCP Discover-Nachrichten über die verfügbaren Schnittstellen an der Vorderseite oder die Management-Schnittstelle, um einen DHCP-Server zu finden, der die für den POAP erforderlichen Informationen bereitstellen kann.
Der Cisco Nexus DHCP-Client verwendet die Seriennummer des Switches in der Client-ID. Diese Informationen können von der Bereitstellungsinfrastruktur verwendet werden, um das Gerät zu identifizieren und die für den Bereitstellungsprozess erforderlichen Bootstrap-Informationen bereitzustellen.
Bei der DHCP-Aushandlung wird der standardmäßige Ermittlungs-, Angebots-, Anforderungs- und Bestätigungsprozess (DORA) verwendet:
| DHCP-Nachricht | Zweck |
|---|---|
| Entdecken | Der Nexus-Switch sucht nach einem verfügbaren DHCP-Server. |
| Angebot | Der DHCP-Server liefert Netzwerk- und POAP-bezogene Informationen. |
| Anfrage | Der Switch fordert das ausgewählte DHCP-Angebot an. |
| Bestätigung | Der DHCP-Server bestätigt die Lease und weist die IP-Adresse zu. |
Für netzwerkbasierte POAPs stellt der DHCP-Austausch die temporären Netzwerkinformationen und Bootstrap-Parameter bereit, die zum Auffinden des POAP-Skripts erforderlich sind.
Die DHCP Discovery-Nachricht fordert folgende Informationen an:
Der Name der Boot-Datei identifiziert das POAP-Skript, das der Switch nach Abschluss der DHCP-Aushandlung abruft.
DHCP stellt nicht die endgültige Cisco Nexus-Konfiguration bereit. Er stellt die Bootstrap-Informationen bereit, die erforderlich sind, um eine temporäre Verbindung herzustellen und das Bereitstellungsskript zu finden.
Für den POAP ist eine DHCP-Leasedauer von mindestens 3600 Sekunden erforderlich.
Der Erhalt eines DHCP-Angebots bedeutet nicht automatisch, dass die DHCP-Erkennung erfolgreich ist. Das Angebot muss die vom POAP erwarteten Anforderungen erfüllen, bevor der Switch den DHCP-Request- und -Acknowledgment-Austausch fortsetzt.
Wenn kein gültiges Angebot eingegangen ist, wird über dieses Angebot keine IP-Adresse zugewiesen.
Ab Cisco NX-OS Version 7.0(3)I7(4) unterstützt POAP die in RFC 3004 definierte DHCP User Class-Option.
Für DHCPv4 verwendet der POAP die Benutzerklassenoption 77 mit dem folgenden Wert: Cisco-POAP
Dieser Wert identifiziert die DHCP-Anfrage als vom POAP-Prozess stammend.
Der Cisco-POAP-Wert kann später bei der Paketerfassung während der Überprüfung festgestellt werden.
Nach Abschluss der DHCP-Aushandlung verwendet der Switch die vom DHCP-Server erhaltenen Bereitstellungsinformationen, um das POAP-Skript zu suchen und abzurufen.
In dem in diesem Dokument verwendeten netzwerkbasierten Standard-Workflow werden der TFTP-Server und die Boot-Datei mit dem Bereitstellungsskript durch die DHCP-Informationen identifiziert. Nachdem die temporäre Netzwerkverbindung hergestellt wurde, lädt Cisco NX-OS das Skript vom Bereitstellungsserver herunter.
Das POAP-Skript enthält die erforderliche Logik zum Bestimmen und Verarbeiten des Software-Images und der Konfigurationsressourcen für das Gerät.
Cisco stellt ein in Python geschriebenes Referenz-POAP-Skript bereit. Das Skript kann an die Bereitstellungsumgebung angepasst werden.
Das Cisco Referenz-POAP-Skript enthält eine MD5-Prüfsumme.
Wenn das Skript geändert wird, muss die eingebettete Prüfsumme neu berechnet werden, bevor das Skript für POAP verwendet wird.
Das Verfahren zur Prüfsummenvorbereitung wird weiter unten im Abschnitt "Informationen zur Dateiintegrität vorbereiten" beschrieben.
Nachdem das POAP-Skript heruntergeladen und validiert wurde, führt Cisco NX-OS das Skript lokal auf dem Switch aus.
Das Referenzskript kann Bereitstellungsaufgaben wie die folgenden ausführen:
Die heruntergeladene Konfiguration wird während der Skriptausführung nicht unbedingt sofort angewendet.
Cisco NX-OS kann die Konfiguration bereitstellen und anwenden, nachdem der Switch mit dem Ziel-Software-Image gestartet wurde. Die Konfiguration wird daher in der Softwareumgebung verarbeitet, für die sie erstellt wurde.
Das POAP-Skript kann ermitteln, ob das Cisco NX-OS-Ziel-Image bereits lokal verfügbar ist.
Wenn das erforderliche Image nicht vorhanden ist, kann es vom Skript aus der Bereitstellungsinfrastruktur abgerufen werden.
Wenn das erforderliche Image bereits verfügbar ist, kann das Skript die vorhandene Datei validieren und das Herunterladen einer weiteren Kopie vermeiden.
In der validierten Implementierung war das Ziel-Image bereits im bootflash: vorhanden. Das Skript validierte das Image, bevor mit den verbleibenden Bereitstellungsvorgängen fortgefahren wurde.
Wenn die Skriptausführung abgeschlossen ist, beginnt der Switch mit der Phase des erneuten Ladens nach der Installation.
In dieser Phase wird der Switch neu gestartet und mit dem Cisco NX-OS Software-Zielabbild gestartet, wenn eine Änderung am Software-Image Teil des Bereitstellungsprozesses ist.
Der Switch übernimmt dann die heruntergeladene Konfiguration oder spielt sie erneut ab. Nachdem die Konfiguration erfolgreich angewendet wurde, kopiert Cisco NX-OS die aktuelle Konfiguration in die Startkonfiguration.
Mit dieser Sequenz wird sichergestellt, dass die bereitgestellte Konfiguration in der Softwareumgebung verarbeitet wird, für die sie vorbereitet wurde.
Die Konfigurationswiedergabe ist der Prozess, bei dem Cisco NX-OS die während des POAP heruntergeladene Konfiguration nach dem Neustart des Switches anwendet.
Die Konfigurationsdatei wird beim ersten Herunterladen nicht unbedingt angewendet. Stattdessen kann die Konfiguration beim POAP während der Skriptausführung bereitgestellt und nach Aktivierung des Cisco NX-OS-Ziel-Images angewendet werden.
Der Prozess lässt sich wie folgt zusammenfassen:
| Phase | Aktion |
|---|---|
| Skriptausführung | Ruft das erforderliche Software-Image und die erforderliche Konfiguration ab. |
| Neuladen nach der Installation | Startet den Switch nach der Bereitstellung neu. |
| Konfigurationswiedergabe | Wendet die heruntergeladene Konfiguration an. |
| Konfigurations-Persistenz | Kopiert die aktuelle Konfiguration in die Startkonfiguration. |
Diese Trennung zwischen Konfigurationsabruf und Konfigurationsanwendung ist ein wichtiger Bestandteil des POAP-Workflows.
Der netzwerkbasierte POAP erfordert eine externe Infrastruktur, um vorübergehend Netzwerkverbindungen bereitzustellen und Zugriff auf die Bereitstellungsressourcen zu erhalten.
Die erforderliche Infrastruktur für den Standard-POAP-Workflow umfasst:
Die über DHCP erhaltenen Netzwerkinformationen werden während der POAP-Bereitstellung verwendet.
In diesem Abschnitt werden die Komponenten beschrieben, die für die Implementierung des netzwerkbasierten PowerOn Auto Provisioning (POAP) auf einem Cisco Nexus 9000-Switch erforderlich sind.
POAP nutzt externe DHCP- und Dateiübertragungsdienste, um vorübergehend Netzwerkverbindungen bereitzustellen und Zugriff auf die Bereitstellungsressourcen zu erhalten. Die Konfiguration von Serverplattformen von Drittanbietern wird in diesem Dokument nicht behandelt.
In den Beispielen in diesem Abschnitt wird die zuvor beschriebene Topologie verwendet, um die POAP-Implementierung zu veranschaulichen.
Für die validierte Implementierung stellt die Bereitstellungsinfrastruktur die temporären Netzwerkinformationen und Dateiübertragungsdienste bereit, die der Nexus-Switch während des POAP benötigt.
Die DHCP-Infrastruktur muss die erforderlichen Informationen bereitstellen, um eine temporäre Verbindung herzustellen und das POAP-Skript ausfindig zu machen. Für den POAP ist eine DHCP-Lease von mindestens 3600 Sekunden erforderlich.
| Informationen | Zweck |
|---|---|
| IP-Adresse | Bietet temporäre Netzwerkverbindungen während des POAP. |
| Subnetzmaske | Definiert das temporäre IP-Subnetz. |
| Default gateway (Standardgateway) | Bietet Verbindungen zu Bereitstellungsressourcen, wenn Routing erforderlich ist. |
| Name oder Adresse des TFTP-Servers | Identifiziert den Server, von dem das POAP-Skript abgerufen wird. |
| Name der Startdatei | Identifiziert das vom Nexus-Switch heruntergeladene POAP-Skript. |
Nachdem ein gültiges DHCP-Angebot ausgewählt wurde, schließt der Nexus-Switch die DHCP-Aushandlung ab und verwendet die zugewiesenen Netzwerkinformationen während des Bereitstellungsprozesses.
Für das validierte Beispiel in diesem Dokument verwendet die Bereitstellungsinfrastruktur die folgenden Werte:
| Parameter | Wert der Übung |
|---|---|
| PoP-Netzwerk | 192.168.100.0/24 |
| Bereitstellungsserver | 192.168.100.1 |
| DHCP-Adressbereich | 192.168.100.100–192.168.100.110 |
| DHCP-Lease | 2 Stunden |
| TFTP-Server | 192.168.100.1 |
| POAP-Skript | PoP.py |
| Nexus-Schnittstelle | Ethernet 1/10 |
Der in diesem Beispiel verwendete Bereitstellungsserver führt Ubuntu aus und stellt die für die Implementierung erforderlichen DHCP- und TFTP-Dienste bereit. Die detaillierte Konfiguration der Server-Software von Drittanbietern wird in diesem Dokument nicht behandelt.
Cisco stellt ein in Python entwickeltes Referenz-POAP-Skript bereit. Ändern Sie die vom Benutzer bearbeitbaren Optionen, um sie an die Bereitstellungsumgebung anzupassen.
Das POAP-Skript fungiert als Orchestrierung der Bereitstellung. Nachdem der Nexus Switch das Skript heruntergeladen und validiert hat, legt das Skript fest, wie der Switch die für die Bereitstellung erforderlichen Ressourcen für Konfiguration und Software-Images abruft und verarbeitet.
Für die validierte Implementierung werden folgende Optionen verwendet:
options = { "username": "root", "password": "password", "hostname": "192.168.100.1", "transfer_protocol": "tftp", "mode": "serial_number", "target_system_image": "nxos64-cs.10.6.2.F.bin", "config_path": "/", "target_image_path": "/", }
Die in diesem Beispiel gezeigten Werte entsprechen der Laborumgebung. Die Produktionswerte hängen von der Bereitstellungsinfrastruktur und den Bereitstellungsanforderungen ab.
| Option | Wert der Übung | Zweck |
|---|---|---|
| hostname | 192.168.100.1 | Identifiziert den Server, von dem die Bereitstellungsdateien abgerufen werden. |
| Übertragungsprotokoll | tftp | Definiert das Dateiübertragungsprotokoll |
| Modus | Seriennummer | Verwendet die Seriennummer des Switches zur Auswahl der gerätespezifischen Konfigurationsdatei. |
| Ziel_System_Image | nxos64-cs.10.6.2.F.bin | Definiert das Cisco NX-OS-Ziel-Image. |
| Konfigurationspfad | / | Definiert den Pfad, der die Gerätekonfiguration enthält. |
| Ziel_Bild_Pfad | / | Definiert den Pfad, der das Ziel-Software-Image enthält. |
Das Referenzskript erfordert den Hostnamen, den Benutzernamen und das Kennwort, wenn Dateien von einem Remote-Server abgerufen werden. Im Beispiel wird TFTP verwendet, das keine Benutzernamen- und Kennwortauthentifizierung bietet. Das Referenzskript überprüft jedoch weiterhin, ob diese Parameter während der Initialisierung vorhanden sind.
Die validierte Implementierung verwendet:
"mode": "serial_number"
Im Modus "serial_number" ruft das Skript die Seriennummer des lokalen Switches ab und verwendet sie, um den entsprechenden Konfigurationsdateinamen zu ermitteln.
Beispiele:
Seriennummer des Switches: FDO262921L3
Konfigurationsdatei: Konf.FDO262921L3
Der Name der Konfigurationsdatei hat folgendes Format: conf.<Seriennummer>
Das gleiche Skript "poap.py" kann daher mehrere Nexus-Switches unterstützen, während jeder Switch seine eigene gerätespezifische Konfiguration abruft.
Auf hoher Ebene führt das validierte Skript diese Sequenz aus:
Identify the switch. ↓ Select conf.
Das POAP-Skript enthält nicht die vollständige Gerätekonfiguration. Sie enthält die Logik und die Parameter, die zum Auffinden, Validieren und Verarbeiten der Bereitstellungsressourcen erforderlich sind.
Die Gerätekonfigurationsdatei enthält die Cisco NX-OS-Konfiguration, die der POAP auf dem Nexus-Zielswitch bereitstellt.
Für den in diesem Beispiel verwendeten Switch wählt serial_number mode die folgende Konfigurationsdatei aus:
Seriennummer: FDO262921L3
Konfigurationsdatei: Konf.FDO262921L3
Die Konfigurationsdatei enthält die Befehle, die zum Einrichten der geplanten Day-0-Konfiguration erforderlich sind.
Für die validierte Implementierung enthält die Konfiguration einen Administrator, einen Hostnamen und eine Loopback-Schnittstelle:
username admin password
Die Konfiguration ist bewusst minimal, um die Verifizierung des Bereitstellungs-Workflows zu vereinfachen.
Nach Abschluss des POAP weisen der Hostname, das Administratorkonto und die Loopback100-Schnittstelle eindeutig darauf hin, dass die gerätespezifische Konfiguration erfolgreich angewendet wurde.
Die bereitgestellte Konfiguration muss den Administratorzugriff umfassen, der nach Abschluss des POAP erforderlich ist.
Vorsicht: Stellen Sie sicher, dass die Gerätekonfiguration einen gültigen Administratorbenutzer und ein gültiges Administratorkennwort enthält. Der POAP-Vorgang kann auch dann erfolgreich abgeschlossen werden, wenn die bereitgestellte Konfiguration keinen gültigen Administratorzugriff bietet.
Während der anfänglichen Validierung im Labor enthielt die Gerätekonfiguration den Hostnamen und die Loopback100-Schnittstelle, jedoch keinen administrativen Benutzer. POAP erfolgreich abgeschlossen; Nach der Bereitstellung war jedoch kein Administratorzugriff mehr möglich.
Der POAP-Abschluss bestätigt, dass der Bereitstellungs-Workflow erfolgreich abgeschlossen wurde. Es wird nicht bestätigt, dass die Day-0-Konfiguration alle Einstellungen enthält, die für den Betrieb und den Zugriff auf den Switch erforderlich sind.
Der Referenz-POAP-Workflow verwendet MD5-Prüfsummen, um die Integrität der Bereitstellungsressourcen vor der Verarbeitung durch den Nexus-Switch zu überprüfen.
POAP vergleicht die erwartete Prüfsumme mit der aus der entsprechenden Datei berechneten Prüfsumme. Übereinstimmende Werte bestätigen, dass die Datei die erwarteten Daten enthält.
Die validierte Implementierung verwendet Integritätsinformationen für folgende Ressourcen:
| Ressource | Integritätsinformationen | Zweck |
|---|---|---|
| POAP-Skript | MD5-Wert eingebettet in poap.py | Validiert das Skript vor der Ausführung. |
| Gerätekonfiguration | konf.FDO262921L3.md5 | Validiert die heruntergeladene Gerätekonfiguration. |
| Cisco NX-OS-Image | nxos64-cs.10.6.2.F.bin.md5 | Validiert das Ziel-Software-Image. |
Die Option disable_md5 im Referenzskript steuert die MD5-Validierung. Der Standardwert ist False.
Das Referenz-POAP-Skript enthält einen MD5-Wert am Anfang der Datei:
#md5sum="
Nachdem der Skriptinhalt geändert wurde, muss die eingebettete Prüfsumme neu berechnet werden, bevor das Skript für POAP verwendet wird.
Für das in dieser Implementierung verwendete Skript wurde die Prüfsumme wie folgt aktualisiert:
f=poap.py cat "$f" | sed '/^#md5sum/d' > "$f.md5" sed -i "s/^#md5sum=.*/#md5sum=\"$(md5sum "$f.md5" | sed 's/ .*//')\"/" "$f" rm -f "$f.md5"
Das daraus resultierende Skript enthielt:
#md5sum="e4dd91fd4296d40abd2f6187152cd86e"
Während des POAP-Vorgangs berechnet Cisco NX-OS die Prüfsumme des heruntergeladenen Skripts und vergleicht sie vor der Skriptausführung mit dem eingebetteten Wert.
Das Referenzskript kann eine separate MD5-Datei verwenden, um die Gerätekonfiguration zu überprüfen.
Für diese Implementierung:
Konfigurationsdatei:
Konf.FDO262921L3
Integritätsdatei:
konf.FDO262921L3.md5
Die Integritätsdatei muss die Prüfsumme enthalten, die der aktuellen Version von conf.FDO262921L3 zugeordnet ist.
Nachdem die Konfiguration heruntergeladen wurde, berechnet das Skript ihre Prüfsumme und vergleicht sie mit dem erwarteten Wert, bevor die Konfiguration verarbeitet wird.
Wenn sich die Gerätekonfiguration ändert, aktualisieren Sie die entsprechenden MD5-Informationen vor dem nächsten POAP-Versuch.
Das Referenzskript kann außerdem das Cisco NX-OS-Ziel-Image validieren.
Für diese Implementierung:
Ziel-Image:
nxos64-cs.10.6.2.F.bin
Integritätsdatei:
nxos64-cs.10.6.2.F.bin.md5
Die Integritätsdatei enthält:
ce50c3f0e387bee578e615a373a4ede0 nxos64-cs.10.6.2.F.bin
In der validierten Implementierung war das Ziel-Image bereits im bootflash: vorhanden. Das POAP-Skript berechnete die MD5-Prüfsumme des vorhandenen Images und verglich sie mit dem vom Bereitstellungsserver erhaltenen Wert.
Da beide Werte übereinstimmen, musste die Bilddatei nicht erneut heruntergeladen werden.
Anmerkung: MD5-Validierung überprüft die Dateiintegrität. Die Bereitstellungsdateien werden nicht verschlüsselt, und die Authentifizierung erfolgt nicht von selbst.
POAP wird beim Systemstart ausgeführt, wenn der Switch keine Startkonfiguration aufweist und der systemweite POAP aktiviert ist.
Bevor der Bereitstellungsprozess startet, überprüfen Sie den POAP-Status:
N9K-POAP-SW1# show system poap System-wide POAP is enabled
Cisco NX-OS ermöglicht die globale Deaktivierung von POAP, wobei das System keinen POAP aufweist. Um POAP erneut zu aktivieren, verwenden Sie system-poap oder löschen Sie das POAP-Deaktivierungsflag mit write erase poap.
Standard-POAP startet, wenn der Switch ohne Startkonfiguration gestartet wird.
Führen Sie in einer kontrollierten Laborumgebung Folgendes aus:
switch# write erase
Warnung: Mit diesem Befehl wird die Startkonfiguration gelöscht.
Do you wish to proceed anyway? (y/n) [n] y
Beim standardmäßigen Schreiblöschvorgang wird die Startkonfiguration aus dem permanenten Speicher entfernt. Die aktuelle Konfiguration oder die Boot-Variablen werden nicht gelöscht.
Vergewissern Sie sich, dass die Startkonfiguration nicht mehr vorhanden ist:
switch# show startup-config No startup configuration
Vorsicht: write erase löscht die gespeicherte Switch-Konfiguration. Verwenden Sie dieses Verfahren nur, wenn die Konfiguration sicher entfernt oder wiederhergestellt werden kann.
Um zu verhindern, dass der Administratorzugriff nach dem POAP verloren geht, stellen Sie sicher, dass die im vorherigen Abschnitt vorbereitete Gerätekonfiguration die erforderlichen Administratorberechtigungen enthält.
Nachdem die Startkonfiguration entfernt wurde, laden Sie den Switch neu.
Wenn Cisco NX-OS Sie auffordert, die aktuelle Konfiguration zu speichern, speichern Sie sie nicht. Beim Speichern der aktuellen Konfiguration wird die Startkonfiguration neu erstellt und die standardmäßige POAP-Auslösebedingung verhindert.
Während des Startvorgangs initialisiert Cisco NX-OS POAP und bietet eine Option zum Abbrechen des Vorgangs:
Abort Power On Auto Provisioning [yes - continue with normal setup, no - continue with Power On Auto Provisioning] (yes/no)[no]:
Um mit POAP fortzufahren, akzeptieren Sie die Standardoption "no".
Nach der Initialisierung des POAP sucht der Switch zunächst nach USB-basierten Bereitstellungsressourcen. Wenn kein verwendbares USB-Bereitstellungsskript gefunden wird, wird der POAP mit der netzwerkbasierten Erkennung fortgeführt.
Bei der validierten Implementierung wurden folgende Meldungen generiert:
2026 Sep 22 18:21:23 switch %$ VDC-1 %$ %POAP-2-POAP_INITED: [FDO262921L3-88:FC:5D:BA:D7:7F] - POAP process initialized 2026 Sep 22 18:21:41 switch %$ VDC-1 %$ %POAP-2-POAP_INFO: [FDO262921L3-88:FC:5D:BA:D7:7F] - USB Initializing Success 2026 Sep 22 18:21:41 switch %$ VDC-1 %$ %POAP-2-POAP_INFO: [FDO262921L3-88:FC:5D:BA:D7:7F] - USB disk not detected
POAP startet dann die IPv4-DHCP-Erkennung:
2026 Sep 22 18:23:54 switch %$ VDC-1 %$ %POAP-2-POAP_INFO: [FDO262921L3-88:FC:5D:BA:D7:7F] - Start DHCP v4 session 2026 Sep 22 18:23:54 switch %$ VDC-1 %$ %POAP-2-POAP_DHCP_DISCOVER_START: [FDO262921L3-88:FC:5D:BA:D7:7F] - POAP DHCP Discover phase started
Nach Empfang einer gültigen DHCP-Antwort zeigt Cisco NX-OS die temporären Netzwerkparameter und den Speicherort des POAP-Skripts an.
Die validierte Umsetzung ergab Folgendes:
2026 Sep 22 18:23:58 switch %$ VDC-1 %$ %POAP-2-POAP_INFO: Recieved DHCP offer from server ip - 192.168.100.1 2026 Sep 22 18:24:02 switch %$ VDC-1 %$ %POAP-2-POAP_INFO: [FDO262921L3-88:FC:5D:BA:D7:7F] - Using DHCP, valid information received over Eth1/10 from 192.168.100.1 2026 Sep 22 18:24:02 switch %$ VDC-1 %$ %POAP-2-POAP_INFO: [FDO262921L3-88:FC:5D:BA:D7:7F] - Assigned IP address: 192.168.100.108 2026 Sep 22 18:24:02 switch %$ VDC-1 %$ %POAP-2-POAP_INFO: [FDO262921L3-88:FC:5D:BA:D7:7F] - Netmask: 255.255.255.0 2026 Sep 22 18:24:02 switch %$ VDC-1 %$ %POAP-2-POAP_INFO: [FDO262921L3-88:FC:5D:BA:D7:7F] - Default Gateway: 192.168.100.1 2026 Sep 22 18:24:02 switch %$ VDC-1 %$ %POAP-2-POAP_INFO: [FDO262921L3-88:FC:5D:BA:D7:7F] - Script Server: 192.168.100.1 2026 Sep 22 18:24:02 switch %$ VDC-1 %$ %POAP-2-POAP_INFO: [FDO262921L3-88:FC:5D:BA:D7:7F] - Script Name: poap.py
Zu diesem Zeitpunkt ist die DHCP-Erkennung abgeschlossen. Der Switch verfügt über eine temporäre Netzwerkverbindung und die zum Auffinden des POAP-Skripts erforderlichen Informationen.
Der Switch ruft das POAP-Skript ab, das bei der DHCP-Erkennung identifiziert wurde:
2026 Sep 22 18:24:14 switch %$ VDC-1 %$ %POAP-2-POAP_INFO: [FDO262921L3-88:FC:5D:BA:D7:7F] - The POAP Script download has started 2026 Sep 22 18:24:14 switch %$ VDC-1 %$ %POAP-2-POAP_INFO: [FDO262921L3-88:FC:5D:BA:D7:7F] - The POAP Script is being downloaded from [copy tftp://192.168.100.1/poap.py bootflash:scripts/script.sh vrf default ] 2026 Sep 22 18:24:15 switch %$ VDC-1 %$ %POAP-2-POAP_SCRIPT_DOWNLOADED: [FDO262921L3-88:FC:5D:BA:D7:7F] - Successfully downloaded POAP script file
Nach Abschluss des Skriptabrufs wird der POAP mit der Skriptvalidierung und -ausführung fortgesetzt. Das Referenzskript steuert dann die Geräteidentifizierung, den Konfigurationsabruf, die Verarbeitung von Software-Images, das Konfigurations-Staging und die übrigen Bereitstellungsvorgänge.
Verwenden Sie die Informationen in diesem Abschnitt, um jede Hauptphase des POAP-Workflows zu überprüfen.
Der POAP kann aus mehreren Perspektiven verifiziert werden. Die Nexus-Konsole und die POAP-Protokolle bieten Informationen über den internen Bereitstellungsprozess, während DHCP-Serverprotokolle und Paketerfassungen zusätzliche Transparenz für die Netzwerkaustausche bieten.
Bei der validierten Implementierung werden diese Quellen verwendet, um den Bereitstellungs-Workflow zu korrelieren:
| Verifizierungsquelle | Bereitgestellte Informationen |
|---|---|
| Nexus-Konsole | POAP-Initialisierung, DHCP-Erkennung, Skriptausführung, Neuladen und Konfigurationswiedergabe |
| Nexus POAP-Protokolle | Detaillierte Informationen zur Initialisierung und Skriptausführung |
| DHCP-Serverprotokolle | DHCP-Aushandlung und Dateiübertragungsaktivität |
| Paketerfassung | DHCP- und TFTP-Austausch |
| Ausführen und Starten der Konfiguration | Endgültiges Bereitstellungsergebnis |
Anmerkung: Die Ausgaben in diesem Abschnitt wurden während kontrollierter POAP-Validierungsversuche erfasst. Später wurde versucht, die endgültige Day-0-Konfiguration mit Administratorzugriff zu validieren. Die ursprünglichen Zeitstempel und Protokollmeldungen werden in den Beispielen beibehalten.
Serverprotokolle und Paketerfassungen von Drittanbietern sind nur als zusätzliche Verifizierungsquellen enthalten. Die Konfiguration von Software von Drittanbietern wird in diesem Dokument nicht behandelt.
Stellen Sie beim Systemstart sicher, dass der POAP erfolgreich initialisiert wurde.
Die Nexus-Konsole zeigt das Initialisierungsereignis an:
2026 Sep 22 18:21:23 switch %$ VDC-1 %$ %POAP-2-POAP_INITED: [FDO262921L3-88:FC:5D:BA:D7:7F] - POAP process initialized
Diese Meldung bestätigt, dass der Switch in den POAP-Workflow eingetreten ist.
POAP sucht dann nach USB-basierten Bereitstellungsressourcen:
2026 Sep 22 18:21:41 switch %$ VDC-1 %$ %POAP-2-POAP_INFO: [FDO262921L3-88:FC:5D:BA:D7:7F] - USB Initializing Success 2026 Sep 22 18:21:41 switch %$ VDC-1 %$ %POAP-2-POAP_INFO: [FDO262921L3-88:FC:5D:BA:D7:7F] - USB disk not detected
In diesem Beispiel ist keine USB-Bereitstellungsressource verfügbar. Der POAP fährt daher mit der netzwerkbasierten Erkennung fort.
Anschließend startet der Switch die DHCP-Erkennung:
2026 Sep 22 18:23:54 switch %$ VDC-1 %$ %POAP-2-POAP_INFO: [FDO262921L3-88:FC:5D:BA:D7:7F] - Start DHCP v4 session 2026 Sep 22 18:23:54 switch %$ VDC-1 %$ %POAP-2-POAP_DHCP_DISCOVER_START: [FDO262921L3-88:FC:5D:BA:D7:7F] - POAP DHCP Discover phase started
Diese Meldungen bestätigen den Übergang von der USB-Erkennung zur netzwerkbasierten DHCP-Erkennung.
POAP speichert Initialisierungs- und Skriptausführungsprotokolle in bootflash:. Diese Dateien bieten zusätzliche Informationen über den Bereitstellungsprozess, nachdem die Konsolenereignisse generiert wurden.
N9K-POAP-SW1# dir bootflash: | include poap 5664 Sep 22 19:52:10 2026 20260922195156_poap_24710_script.log 87366 Sep 22 19:58:48 2026 20260922_194902_poap_24710_init.log N9K-POAP-SW1#
Die Datei _init.log enthält Informationen zur POAP-Initialisierung und -Erkennung.
Die Datei _script.log enthält detaillierte Informationen, die während der Ausführung des POAP-Skripts generiert werden.
Verwenden Sie bei mehreren POAP-Versuchen den Zeitstempel im Dateinamen, um jede Datei mit dem entsprechenden Bereitstellungsversuch zu korrelieren.
Nachdem der POAP in die DHCP-Erkennungsphase eingetreten ist, überprüfen Sie, ob der Nexus-Switch gültige Bootstrap-Netzwerkinformationen empfängt.
Die Nexus-Konsole bestätigt, dass die DHCP-Erkennung gestartet wurde und dass gültige Informationen über Ethernet1/10 empfangen wurden:
2026 Sep 22 18:23:54 switch %$ VDC-1 %$ %POAP-2-POAP_INFO: [FDO262921L3-88:FC:5D:BA:D7:7F] - Start DHCP v4 session 2026 Sep 22 18:23:54 switch %$ VDC-1 %$ %POAP-2-POAP_DHCP_DISCOVER_START: [FDO262921L3-88:FC:5D:BA:D7:7F] - POAP DHCP Discover phase started 2026 Sep 22 18:23:58 switch %$ VDC-1 %$ %POAP-2-POAP_INFO: Recieved DHCP offer from server ip - 192.168.100.1 2026 Sep 22 18:24:02 switch %$ VDC-1 %$ %POAP-2-POAP_INFO: [FDO262921L3-88:FC:5D:BA:D7:7F] - Using DHCP, valid information received over Eth1/10 from 192.168.100.1 2026 Sep 22 18:24:02 switch %$ VDC-1 %$ %POAP-2-POAP_INFO: [FDO262921L3-88:FC:5D:BA:D7:7F] - Assigned IP address: 192.168.100.108 2026 Sep 22 18:24:02 switch %$ VDC-1 %$ %POAP-2-POAP_INFO: [FDO262921L3-88:FC:5D:BA:D7:7F] - Netmask: 255.255.255.0 2026 Sep 22 18:24:02 switch %$ VDC-1 %$ %POAP-2-POAP_INFO: [FDO262921L3-88:FC:5D:BA:D7:7F] - Default Gateway: 192.168.100.1 2026 Sep 22 18:24:02 switch %$ VDC-1 %$ %POAP-2-POAP_INFO: [FDO262921L3-88:FC:5D:BA:D7:7F] - Script Server: 192.168.100.1 2026 Sep 22 18:24:02 switch %$ VDC-1 %$ %POAP-2-POAP_INFO: [FDO262921L3-88:FC:5D:BA:D7:7F] - Script Name: poap.py
Die Ausgabe bestätigt, dass POAP "Ethernet1/10" ausgewählt hat, die temporäre Adresse 192.168.100.108 erhalten hat und das Gateway, den Skriptserver und den Skriptdateinamen erhalten hat, die für die nächste Bereitstellungsphase erforderlich sind.
DHCP-Serverprotokolle bieten eine zusätzliche Ansicht des Bootstrap-Austauschs.
Das validierte Beispiel zeigt Folgendes:
vendor class: Cisco N9K-C9336C-FX2 user class: Cisco-POAP DHCPDISCOVER(ens224) 88:fc:5d:ba:d7:7f DHCPOFFER(ens224) 192.168.100.108 88:fc:5d:ba:d7:7f DHCPREQUEST(ens224) 192.168.100.108 88:fc:5d:ba:d7:7f DHCPACK(ens224) 192.168.100.108 88:fc:5d:ba:d7:7f
Der Server identifizierte außerdem die POAP-Bootstrap-Informationen:
option: 67 bootfile-name poap.py option:150 tftp-server-address 192.168.100.1 option: 3 router 192.168.100.1
Die Protokolle bestätigen den vollständigen Austausch von Erkennung, Angebot, Anforderung und Bestätigung. Die Protokolle enthalten außerdem die Cisco POAP-Benutzerklasse, den Skriptdateinamen, die TFTP-Serveradresse und das Standard-Gateway, die mit der Bereitstellungsanforderung verknüpft sind.
Mithilfe einer Paketerfassung kann der DHCP-Austausch direkt im Netzwerk verifiziert werden.
Für das validierte Beispiel wurde die Erfassung wie folgt überprüft:
sudo tcpdump -nn -vvv -r /tmp/poap-run1.pcap \ 'udp port 67 or udp port 68'
Die Aufnahme zeigte:
DHCP-Message (53), length 1: Discover Vendor-Class (60), length 20: "Cisco N9K-C9336C-FX2" DHCP-Message (53), length 1: Offer DHCP-Message (53), length 1: Request Requested-IP (50), length 4: 192.168.100.108 DHCP-Message (53), length 1: ACK
Die Paketerfassung bestätigt die in den DHCP-Serverprotokollen beobachtete Erkennungs-, Angebots-, Anforderungs- und Bestätigungssequenz.
Überprüfen Sie nach Abschluss der DHCP-Erkennung, ob der Nexus-Switch das POAP-Skript vom Server abruft, der während des DHCP-Austauschs identifiziert wurde.
Die Nexus-Konsole zeigt an, wann der Skriptdownload beginnt:
2026 Sep 22 18:24:14 switch %$ VDC-1 %$ %POAP-2-POAP_INFO: [FDO262921L3-88:FC:5D:BA:D7:7F] - The POAP Script download has started 2026 Sep 22 18:24:14 switch %$ VDC-1 %$ %POAP-2-POAP_INFO: [FDO262921L3-88:FC:5D:BA:D7:7F] - The POAP Script is being downloaded from [copy tftp://192.168.100.1/poap.py bootflash:scripts/script.sh vrf default ] 2026 Sep 22 18:24:15 switch %$ VDC-1 %$ %POAP-2-POAP_SCRIPT_DOWNLOADED: [FDO262921L3-88:FC:5D:BA:D7:7F] - Successfully downloaded POAP script file
Diese Meldungen bestätigen, dass der Switch poap.py vom TFTP-Server abgerufen hat, der über DHCP erkannt wurde.
Eine Paketerfassung bietet eine direkte Bestätigung der während der Skriptausführung generierten TFTP-Anforderungen.
Führen Sie für das validierte Beispiel Folgendes aus:
sudo tcpdump -nn -r /tmp/poap-run1.pcap 'udp dst port 69' reading from file /tmp/poap-run1.pcap, link-type EN10MB (Ethernet), snapshot length 262144 13:38:17.012862 IP 192.168.100.108.58485 > 192.168.100.1.69: TFTP, length 16, RRQ "poap.py" octet 13:38:19.955108 IP 192.168.100.108.58550 > 192.168.100.1.69: TFTP, length 29, RRQ "conf.FDO262921L3.md5" octet 13:38:20.651491 IP 192.168.100.108.58680 > 192.168.100.1.69: TFTP, length 25, RRQ "conf.FDO262921L3" octet 13:38:21.737101 IP 192.168.100.108.58866 > 192.168.100.1.69: TFTP, length 35, RRQ "nxos64-cs.10.6.2.F.bin.md5" octet
Die erste Anfrage bestätigt, dass die temporäre POAP-Adresse 192.168.100.108 den Bereitstellungsserver unter 192.168.100.1 kontaktiert und poap.py angefordert hat. Die nachfolgenden Anfragen zeigen den Fortschritt in Richtung Gerätekonfiguration und Image-Validierung.
Bevor das heruntergeladene Skript ausgeführt wird, validiert Cisco NX-OS die im Skript eingebettete MD5-Prüfsumme.
Das validierte Beispiel ergab Folgendes:
2026 Sep 22 18:24:15 switch %$ VDC-1 %$ %POAP-2-POAP_INFO: [FDO262921L3-88:FC:5D:BA:D7:7F] - Script file size 113107, MD5 checksum e4dd91fd4296d40abd2f6187152cd86e 2026 Sep 22 18:24:15 switch %$ VDC-1 %$ %POAP-2-POAP_INFO: [FDO262921L3-88:FC:5D:BA:D7:7F] - MD5 checksum received from the script file is e4dd91fd4296d40abd2f6187152cd86e 2026 Sep 22 18:24:15 switch %$ VDC-1 %$ %POAP-2-POAP_SCRIPT_STARTED_MD5_VALIDATED: [FDO262921L3-88:FC:5D:BA:D7:7F] - POAP script execution started(MD5 validated)
Die übereinstimmenden Werte bestätigen, dass das heruntergeladene Skript die Integritätsprüfung bestanden hat, bevor die Ausführung begonnen hat.
Zu diesem Zeitpunkt geht die Steuerung von der POAP-Initialisierung an die Bereitstellungslogik im heruntergeladenen Skript über.
Überprüfen Sie nach dem Start des POAP-Skripts, ob das Skript den Nexus-Switch identifiziert und die entsprechende Gerätekonfiguration auswählt.
Im Seriennummernmodus verwendet das Referenzskript die Seriennummer des lokalen Switches, um den Namen der Konfigurationsdatei zu ermitteln.
Im validierten Beispiel wurde Folgendes generiert:
Quellnamen der Konfigurationsdatei basierend auf der Seriennummer festlegen
Seriennummer FDO262921L3
Ausgewählter Konf-Dateiname: Konf.FDO262921L3
Die Ausgabe bestätigt, dass das Skript die lokale Seriennummer identifiziert und conf.FDO262921L3 ausgewählt hat.
Nach der Auswahl des Konfigurationsdateinamens ruft das Skript die entsprechenden MD5-Informationen ab:
2026 Sep 22 18:24:17 switch %$ VDC-1 %$ %USER-1-SYSTEM_MSG: - Logfile name: /bootflash/20260922182417_poap_23243_script.log - script.sh 2026 Sep 22 18:24:17 switch %$ VDC-1 %$ %USER-1-SYSTEM_MSG: - Found 1 POAP script logs - script.sh 2026 Sep 22 18:24:17 switch %$ VDC-1 %$ %USER-1-SYSTEM_MSG: - Setting source cfg filename based-on serial number - script.sh 2026 Sep 22 18:24:17 switch %$ VDC-1 %$ %USER-1-SYSTEM_MSG: - serial number FDO262921L3 - script.sh 2026 Sep 22 18:24:17 switch %$ VDC-1 %$ %USER-1-SYSTEM_MSG: - Selected conf file name : conf.FDO262921L3 - script.sh 2026 Sep 22 18:24:17 switch %$ VDC-1 %$ %USER-1-SYSTEM_MSG: S/N[FDO262921L3]-MAC[88:FC:5D:BA:D7:7F] - Verifying freespace in bootflash - script.sh 2026 Sep 22 18:24:17 switch %$ VDC-1 %$ %USER-1-SYSTEM_MSG: S/N[FDO262921L3]-MAC[88:FC:5D:BA:D7:7F] - Free bootflash space is 106776296.0 KB - script.sh 2026 Sep 22 18:24:17 switch %$ VDC-1 %$ %USER-1-SYSTEM_MSG: S/N[FDO262921L3]-MAC[88:FC:5D:BA:D7:7F] - Single image is set - script.sh 2026 Sep 22 18:24:17 switch %$ VDC-1 %$ %USER-1-SYSTEM_MSG: S/N[FDO262921L3]-MAC[88:FC:5D:BA:D7:7F] - Copying config file - script.sh 2026 Sep 22 18:24:17 switch %$ VDC-1 %$ %USER-1-SYSTEM_MSG: S/N[FDO262921L3]-MAC[88:FC:5D:BA:D7:7F] - Copying MD5 information - script.sh 2026 Sep 22 18:24:17 switch %$ VDC-1 %$ %USER-1-SYSTEM_MSG: S/N[FDO262921L3]-MAC[88:FC:5D:BA:D7:7F] - Starting Copy of MD5. src=/conf.FDO262921L3.md5 dest = /bootflash/conf.FDO262921L3.md5 - script.sh 2026 Sep 22 18:24:17 switch %$ VDC-1 %$ %USER-1-SYSTEM_MSG: S/N[FDO262921L3]-MAC[88:FC:5D:BA:D7:7F] - File transfer_protocol = tftp - script.sh
Die Integritätsdatei wird heruntergeladen und im Bootflash gespeichert: 2026 Sep 22 18:24:17 switch %$ VDC-1 %$ %USER-1-SYSTEM_MSG: S/N[FDO262921L3]-MAC[88:FC:5D:BA:D7:7F] - *** Downloaded file is of size 51 *** - script.sh 2026 Sep 22 18:24:17 switch %$ VDC-1 %$ %USER-1-SYSTEM_MSG: S/N[FDO262921L3]-MAC[88:FC:5D:BA:D7:7F] - Renamed /bootflash/conf.FDO262921L3.md5.tmp to /bootflash/conf.FDO262921L3.md5 - script.sh
Das Skript ruft dann die Gerätekonfiguration ab:
2026 Sep 22 18:24:17 switch %$ VDC-1 %$ %USER-1-SYSTEM_MSG: S/N[FDO262921L3]-MAC[88:FC:5D:BA:D7:7F] - INFO: Starting Copy of Config File to /bootflash/poap_conf.cfg - script.sh 2026 Sep 22 18:24:17 switch %$ VDC-1 %$ %USER-1-SYSTEM_MSG: S/N[FDO262921L3]-MAC[88:FC:5D:BA:D7:7F] - Copying file options source=/conf.FDO262921L3 destination=/bootflash/poap_conf.cfg login_timeout=120 destination_tmp=poap_conf.cfg.tmp - script.sh 2026 Sep 22 18:24:17 switch %$ VDC-1 %$ %USER-1-SYSTEM_MSG: S/N[FDO262921L3]-MAC[88:FC:5D:BA:D7:7F] - Transfering using tftp from /conf.FDO262921L3 to bootflash:/poap_conf.cfg.tmp hostname 192.168.100.1 vrf default - script.sh 2026 Sep 22 18:24:17 switch %$ VDC-1 %$ %USER-1-SYSTEM_MSG: S/N[FDO262921L3]-MAC[88:FC:5D:BA:D7:7F] - Command is : terminal dont-ask ; terminal password
Diese Meldungen bestätigen, dass die gerätespezifische Konfiguration erfolgreich abgerufen und zur Verarbeitung lokal gespeichert wurde.
Die Paketerfassung bietet eine unabhängige Bestätigung der vom Nexus-Switch generierten TFTP-Anforderungen.
Für das validierte Beispiel:
sudo tcpdump -nn -r /tmp/poap-run1.pcap 'udp dst port 69' reading from file /tmp/poap-run1.pcap, link-type EN10MB (Ethernet), snapshot length 262144 13:38:19.955108 IP 192.168.100.108.58550 > 192.168.100.1.69: TFTP, length 29, RRQ "conf.FDO262921L3.md5" octet 13:38:20.651491 IP 192.168.100.108.58680 > 192.168.100.1.69: TFTP, length 25, RRQ "conf.FDO262921L3" octet
Die Sequenz bestätigt, dass der Switch die Konfigurationsintegritätsdatei angefordert hat, bevor er die Gerätekonfiguration abruft.
Im TFTP-Serverprotokoll wurden außerdem beide Übertragungen aufgezeichnet:
Sep 22 14:26:36 calo-ubuntu24-00505692aeaf dnsmasq-tftp[144902]: sent /srv/tftp/conf.FDO262921L3.md5 to 192.168.100.108 Sep 22 14:26:37 calo-ubuntu24-00505692aeaf dnsmasq-tftp[144902]: sent /srv/tftp/conf.FDO262921L3 to 192.168.100.108
Nach dem Herunterladen der Konfiguration berechnet das Skript die MD5-Prüfsumme und vergleicht sie mit dem erwarteten Wert.
Der in diesem Beispiel gezeigte Bereitstellungsversuch führte zu folgenden Ergebnissen:
2026 Sep 22 18:24:18 switch %$ VDC-1 %$ %USER-1-SYSTEM_MSG: S/N[FDO262921L3]-MAC[88:FC:5D:BA:D7:7F] - Verifying MD5 checksum - script.sh 2026 Sep 22 18:24:18 switch %$ VDC-1 %$ %USER-1-SYSTEM_MSG: S/N[FDO262921L3]-MAC[88:FC:5D:BA:D7:7F] - file name is bootflash:poap_conf.cfg - script.sh 2026 Sep 22 18:24:18 switch %$ VDC-1 %$ %USER-1-SYSTEM_MSG: S/N[FDO262921L3]-MAC[88:FC:5D:BA:D7:7F] - INFO: md5sum a1a51058d79de0348c6cd1934e08acb4 (recalculated) - script.sh 2026 Sep 22 18:24:18 switch %$ VDC-1 %$ %USER-1-SYSTEM_MSG: S/N[FDO262921L3]-MAC[88:FC:5D:BA:D7:7F] - Verifying MD5 checksum of /bootflash/poap_conf.cfg (size 120) - script.sh 2026 Sep 22 18:24:18 switch %$ VDC-1 %$ %USER-1-SYSTEM_MSG: S/N[FDO262921L3]-MAC[88:FC:5D:BA:D7:7F] - md5given = a1a51058d79de0348c6cd1934e08acb4 md5calculated = a1a51058d79de0348c6cd1934e08acb4 - script.sh 2026 Sep 22 18:24:18 switch %$ VDC-1 %$ %USER-1-SYSTEM_MSG: S/N[FDO262921L3]-MAC[88:FC:5D:BA:D7:7F] - MD5 match for file = /bootflash/poap_conf.cfg - script.sh
Die übereinstimmenden Werte bestätigen, dass die bei diesem Bereitstellungsversuch heruntergeladene Konfiguration mit den entsprechenden Integritätsinformationen übereinstimmt.
Nach erfolgreicher Integritätsprüfung legt das Skript fest, wie die Konfiguration für das Cisco NX-OS-Ziel-Image vorbereitet werden muss.
In diesem Beispiel:
026 Sep 22 18:24:18 switch %$ VDC-1 %$ %USER-1-SYSTEM_MSG: S/N[FDO262921L3]-MAC[88:FC:5D:BA:D7:7F] - Split Config file - script.sh 2026 Sep 22 18:24:18 switch %$ VDC-1 %$ %USER-1-SYSTEM_MSG: S/N[FDO262921L3]-MAC[88:FC:5D:BA:D7:7F] - Target image supports bootstrap replay. Split config is not required. - script.sh 2026 Sep 22 18:24:18 switch %$ VDC-1 %$ %USER-1-SYSTEM_MSG: S/N[FDO262921L3]-MAC[88:FC:5D:BA:D7:7F] - Skip split config as it isn't needed with nxos64-cs.10.6.2.F.bin - script.sh
Die Ausgabe bestätigt, dass das Ziel-Image die Bootstrap-Wiedergabe unterstützt und dass für diesen Bereitstellungsversuch keine Aufteilung der Konfiguration erforderlich ist.
In dieser Phase wurde die gerätespezifische Konfiguration identifiziert, abgerufen, validiert und für den verbleibenden POAP-Workflow vorbereitet.
Nachdem die Gerätekonfiguration abgerufen und validiert wurde, überprüfen Sie, wie das POAP-Skript das Cisco NX-OS-Zielabbild verarbeitet.
Die validierte Implementierung verwendet: nxos64-cs.10.6.2.F.bin
Das Skript ruft zunächst die entsprechenden MD5-Informationen ab:
2026 Sep 22 18:24:18 switch %$ VDC-1 %$ %USER-1-SYSTEM_MSG: S/N[FDO262921L3]-MAC[88:FC:5D:BA:D7:7F] - Starting Copy of MD5. src=/nxos64-cs.10.6.2.F.bin.md5 dest = /bootflash/nxos64-cs.10.6.2.F.bin.md5 - script.sh 2026 Sep 22 18:24:18 switch %$ VDC-1 %$ %USER-1-SYSTEM_MSG: S/N[FDO262921L3]-MAC[88:FC:5D:BA:D7:7F] - File transfer_protocol = tftp - script.sh
Die MD5-Datei wird dann im Bootflash gespeichert:
2026 Sep 22 18:24:19 switch %$ VDC-1 %$ %USER-1-SYSTEM_MSG: S/N[FDO262921L3]-MAC[88:FC:5D:BA:D7:7F] - *** Downloaded file is of size 57 *** - script.sh 2026 Sep 22 18:24:19 switch %$ VDC-1 %$ %USER-1-SYSTEM_MSG: S/N[FDO262921L3]-MAC[88:FC:5D:BA:D7:7F] - Renamed /bootflash/nxos64-cs.10.6.2.F.bin.md5.tmp to /bootflash/nxos64-cs.10.6.2.F.bin.md5 - script.sh
Das Skript liest die vom Bereitstellungsserver empfangene Prüfsumme:
2026 Sep 22 18:24:19 switch %$ VDC-1 %$ %USER-1-SYSTEM_MSG: S/N[FDO262921L3]-MAC[88:FC:5D:BA:D7:7F] - MD5 for system image from server: ce50c3f0e387bee578e615a373a4ede0 - script.sh
Es berechnet dann die Prüfsumme des bereits im bootflash vorhandenen Bildes:
2026 Sep 22 18:24:19 switch %$ VDC-1 %$ %USER-1-SYSTEM_MSG: S/N[FDO262921L3]-MAC[88:FC:5D:BA:D7:7F] - Verifying MD5 checksum - script.sh 2026 Sep 22 18:24:19 switch %$ VDC-1 %$ %USER-1-SYSTEM_MSG: S/N[FDO262921L3]-MAC[88:FC:5D:BA:D7:7F] - file name is bootflash:nxos64-cs.10.6.2.F.bin - script.sh 2026 Sep 22 18:24:30 switch %$ VDC-1 %$ %USER-1-SYSTEM_MSG: S/N[FDO262921L3]-MAC[88:FC:5D:BA:D7:7F] - INFO: md5sum ce50c3f0e387bee578e615a373a4ede0 (recalculated) - script.sh 2026 Sep 22 18:24:30 switch %$ VDC-1 %$ %USER-1-SYSTEM_MSG: S/N[FDO262921L3]-MAC[88:FC:5D:BA:D7:7F] - Verifying MD5 checksum of /bootflash/nxos64-cs.10.6.2.F.bin (size 2952914432) - script.sh 2026 Sep 22 18:24:30 switch %$ VDC-1 %$ %USER-1-SYSTEM_MSG: S/N[FDO262921L3]-MAC[88:FC:5D:BA:D7:7F] - md5given = ce50c3f0e387bee578e615a373a4ede0 md5calculated = ce50c3f0e387bee578e615a373a4ede0 - script.sh
Das Skript bestätigt, dass das vorhandene Bild mit dem erwarteten Bild übereinstimmt:
2026 Sep 22 18:24:30 switch %$ VDC-1 %$ %USER-1-SYSTEM_MSG: S/N[FDO262921L3]-MAC[88:FC:5D:BA:D7:7F] - MD5 match for file = /bootflash/nxos64-cs.10.6.2.F.bin - script.sh 2026 Sep 22 18:24:30 switch %$ VDC-1 %$ %USER-1-SYSTEM_MSG: S/N[FDO262921L3]-MAC[88:FC:5D:BA:D7:7F] - File /bootflash/nxos64-cs.10.6.2.F.bin already exists and MD5 matches - script.sh
Die übereinstimmenden Werte bestätigen, dass das erforderliche Cisco NX-OS-Image bereits im Bootflash vorhanden war: und die Integritätsprüfung bestanden. Daher musste keine weitere Kopie des Images heruntergeladen werden.
Die Paketerfassung bestätigt außerdem, dass der Nexus die Bildintegritätsdatei angefordert hat:
sudo tcpdump -nn -r /tmp/poap-run1.pcap 'udp dst port 69' reading from file /tmp/poap-run1.pcap, link-type EN10MB (Ethernet), snapshot length 262144 13:38:21.737101 IP 192.168.100.108.58866 > 192.168.100.1.69: TFTP, length 35, RRQ "nxos64-cs.10.6.2.F.bin.md5" octet
Im TFTP-Serverprotokoll wurde die gleiche Übertragung aufgezeichnet:
Sep 22 14:26:38 calo-ubuntu24-00505692aeaf dnsmasq-tftp[144902]: sent /srv/tftp/nxos64-cs.10.6.2.F.bin.md5 to 192.168.100.108
Diese Ausgaben bestätigen den Abruf von nxos64-cs.10.6.2.F.bin.md5 vom Bereitstellungsserver.
Obwohl die Image-Datei nicht heruntergeladen werden musste, wurde das Referenzskript mit dem Cisco NX-OS-Installations-Workflow fortgesetzt.
Im validierten Beispiel wurde Folgendes generiert:
2026 Sep 22 18:24:31 switch %$ VDC-1 %$ %USER-1-SYSTEM_MSG: S/N[FDO262921L3]-MAC[88:FC:5D:BA:D7:7F] - Done copying the second scheduled cfg - script.sh 2026 Sep 22 18:24:31 switch %$ VDC-1 %$ %USER-1-SYSTEM_MSG: S/N[FDO262921L3]-MAC[88:FC:5D:BA:D7:7F] - terminal dont-ask ; install all nxos bootflash:/nxos64-cs.10.6.2.F.bin no-reload non-interruptive - script.sh
Das vorhandene Image hat die Integritätsprüfung bestanden und erfordert keine weitere Dateiübertragung. Das Referenzskript hat jedoch den Softwareinstallationsprozess für das validierte Image weiterhin aufgerufen.
Anmerkung: Ein vorhandenes Image und ein passendes MD5 können einen unnötigen Image-Download verhindern. Dies bedeutet nicht notwendigerweise, dass der verbleibende Softwareinstallations-Workflow übersprungen wird.
Nach Abschluss der Softwareverarbeitung wird der POAP mit den verbleibenden Bereitstellungsvorgängen fortgesetzt und der Switch für das erneute Laden vorbereitet.
Wenn das POAP-Skript erfolgreich abgeschlossen wurde, stellen Sie sicher, dass der Switch das erneute Laden und die Konfigurationswiedergabe vornimmt.
Im validierten Beispiel wurde eine erfolgreiche Skriptausführung und dann ein Neuladen gemeldet:
2026 Sep 22 18:31:08 switch %$ VDC-1 %$ %POAP-2-POAP_SCRIPT_EXEC_SUCCESS: [FDO262921L3-88:FC:5D:BA:D7:7F] - POAP script execution success 2026 Sep 22 18:31:09 switch %$ VDC-1 %$ %POAP-2-POAP_RELOAD_DEVICE: [FDO262921L3-88:FC:5D:BA:D7:7F] - Reload device
Diese Meldungen bestätigen den Abschluss der Skriptausführung und den Übergang zur Nachinstallationsphase.
Nach dem Neustart des Switches erkennt Cisco NX-OS die POAP-Wiedergabedatei:
2026 Sep 22 18:33:49 %$ VDC-1 %$ %DAEMON-2-SYSTEM_MSG: <<%ASCII-CFG-2-CONF_CONTROL>> Poap replay /bootflash/poap_replay01.cfg - ascii_cfg_server[17165]
Die Bootstrap-Wiedergabe wurde gestartet und abgeschlossen:
2026 Sep 22 18:34:26 %$ VDC-1 %$ %ASCII-CFG-2-CONFIG_REPLAY_STATUS: Bootstrap Replay Started. 2026 Sep 22 18:34:27 %$ VDC-1 %$ %ASCII-CFG-2-CONFIG_REPLAY_STATUS: Bootstrap Replay Done.
Diese Ereignisse bestätigen, dass Cisco NX-OS mit der Verarbeitung der während des POAP bereitgestellten Konfiguration begonnen hat.
Nach Abschluss der Bootstrap-Wiedergabe verarbeitet NX-OS die bereitgestellte Konfiguration.
Bei den kontrollierten Validierungsversuchen wurden folgende Meldungen generiert:
2026 Sep 22 18:35:42 switch %$ VDC-1 %$ %ASCII-CFG-2-CONFIG_REPLAY_STATUS: Ascii Replay Started. 2026 Sep 22 18:35:44 N9K-POAP-SW1 %$ VDC-1 %$ %ASCII-CFG-2-CONFIG_REPLAY_STATUS: Ascii Replay Done. 2026 Sep 22 20:03:26 switch %VDC_MGR-5-VDC_HOSTNAME_CHANGE: vdc 1 hostname changed to N9K-POAP-SW1 2026 Sep 22 20:03:27 N9K-POAP-SW1 %ETHPORT-5-IF_UP: Interface loopback100 is up 2026 Sep 22 20:03:28 N9K-POAP-SW1 %ASCII-CFG-2-CONFIG_REPLAY_STATUS: Ascii Replay Done. 2026 Sep 22 20:03:29 N9K-POAP-SW1 %ASCII-CFG-2-CONF_CONTROL: System ready
Die Meldungen zeigen die Wiedergabe der ASCII-Konfiguration an und liefern einen direkten Nachweis, dass die bereitgestellte Konfiguration angewendet wurde.
Der Hostname wurde in N9K-POAP-SW1 geändert, und Loopback100 wurde im Rahmen der bereitgestellten Konfiguration aktiviert.
Nach Abschluss der Konfigurationswiedergabe speichert Cisco NX-OS die resultierende Konfiguration.
2026 Sep 22 19:24:03 N9K-POAP-SW1 %$ VDC-1 %$ %ASCII-CFG-2-CONF_CONTROL: System ready [########################################] 100% Copy complete, now saving to disk (please wait)... Copy complete. Auto provisioning complete
Die Meldung Auto Provisioning Complete (Automatische Bereitstellung abgeschlossen) bestätigt den Abschluss des POAP-Workflows.
Überprüfen Sie zu diesem Zeitpunkt die sich ergebende aktuelle Konfiguration und die Startkonfiguration, um sicherzustellen, dass die beabsichtigte Day-0-Konfiguration aktiv und persistent ist.
Überprüfen Sie nach Abschluss des POAP, ob die beabsichtigte Day-0-Konfiguration aktiv und persistent ist. Bestätigen Sie den bereitgestellten Hostnamen, das Administratorkonto, die Schnittstellenkonfiguration, das Cisco NX-OS-Image und den systemweiten POAP-Status.
N9K-POAP-SW1# show hostname N9K-POAP-SW1 N9K-POAP-SW1# show user-account admin user:admin this user account has no expiry date roles:network-admin N9K-POAP-SW1# show ip interface brief IP Interface Status for VRF "default"(1) Interface IP Address Interface Status Lo100 10.255.255.100 protocol-up/link-up/admin-up N9K-POAP-SW1# show running-config interface loopback100 !Command: show running-config interface loopback100 !Running configuration last done at: Tue Sep 22 20:03:48 2026 !Time: Tue Sep 22 23:17:52 2026 version 10.6(2) Bios:version 05.53 interface loopback100 description POAP-VALIDATION ip address 10.255.255.100/32 N9K-POAP-SW1# show startup-config interface loopback100 !Command: show startup-config interface loopback100 !Time: Tue Sep 22 23:17:57 2026 !Startup config saved at: Tue Sep 22 20:03:48 2026 version 10.6(2) Bios:version 05.53 interface loopback100 description POAP-VALIDATION ip address 10.255.255.100/32 N9K-POAP-SW1# show startup-config | include username username admin password 5
Die Ausgabe bestätigt, dass die gerätespezifische Konfiguration erfolgreich angewendet und in der Startkonfiguration gespeichert wurde.
Er bestätigt außerdem, dass auf dem Switch das erwartete Cisco NX-OS-Image ausgeführt wird und dass der systemweite POAP aktiviert bleibt.
In diesem Dokument werden die wichtigsten POAP-Komponenten und der Workflow beschrieben, darunter DHCP-Erkennung, Skriptabruf und -ausführung, gerätespezifische Konfigurationsauswahl, Validierung der Dateiintegrität, Verarbeitung von Cisco NX-OS-Images und Konfigurationswiedergabe.
Die validierte Implementierung zeigt, wie ein Cisco Nexus 9000-Switch die erforderlichen Bereitstellungsressourcen erhält, eine Day-0-Konfiguration anwendet und die resultierende Konfiguration beibehält.
Der Verifizierungsprozess zeigt auch, wie Konsolenmeldungen, POAP-Protokolle, Serverprotokolle und Paketerfassungen korreliert werden können, um jede Hauptphase des Bereitstellungs-Workflows zu bestätigen.
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
1.0 |
12-Oct-2026
|
Erstveröffentlichung |