Einleitung
In diesem Dokument werden die Auswirkungen der Verwendung des Befehls reload ascii beschrieben.
NX-OS-Konfigurationsdateien
Beim Start kann NXOS die Konfiguration auf zwei verschiedene Arten laden:
- Binärer Start: den Standard-Startmechanismus. Die vorkompilierte Konfiguration im Binärformat wird auf alle NXOS-Prozesse angewendet. Die Startkonfigurationsdatei im Nur-Text-Format wird nicht verwendet und ist nur als Referenz verfügbar. Im Allgemeinen wird von dieser Datei erwartet, dass sie die beim Start angewendete Konfiguration genau widerspiegelt, da es sich um eine Spiegelung der running-config handelt, auf der die binäre Konfiguration basiert. Diese binäre Konfiguration wird als Persistent Storage Service (PSS) bezeichnet.
- ASCII-Boot: nur in Ausnahmesituationen verwendet werden. Die Konfiguration im Nur-Text-Format wird aus der Datei "startup-config" gelesen. Diese wird dann während des Switch-Bootvorgangs genau wie bei der zeilenweisen Eingabe über die NX-OS-CLI angewendet. Das Konzept ist vergleichbar mit dem Ausführen von write erase und reload-Befehlen, gefolgt von einem Backup der Konfiguration in running-config.
Potenzielle Probleme beim ASCII-Start
Die Ausführung dieses Befehls wird nur empfohlen, wenn dies vom Cisco TAC vorgeschlagen wird.
Das genaue Verhalten kann sich zwischen verschiedenen Switch-Modellen und Softwareversionen unterscheiden. Im Allgemeinen weisen neuere Nexus Switches der Serie 9000 eine weitaus geringere Anzahl von Problemen im Zusammenhang mit ASCII-Boot auf, da intern Workarounds angewendet wurden, um die Auswirkungen zu minimieren. Bei älteren Switches wie dem Nexus 7000 können weitere Probleme auftreten.
- Zeit zum Booten. Der Start des Switches kann erheblich länger dauern, insbesondere wenn es sich um einen modularen Switch mit einer großen Anzahl von VDCs handelt. In einigen Fällen kann der Start 1 Stunde oder sogar länger dauern. Dies an sich kann zu Problemen führen.
- Inkonsistente Konfiguration beim Hochfahren. Da die Konfiguration Zeile für Zeile mit relativ langsamer Geschwindigkeit angewendet wird, können die Teile der Konfiguration, die früher in der Startkonfigurationsdatei enthalten sind, viel früher übernommen werden als die Teile, die näher am Ende liegen. So kann es beispielsweise vorkommen, dass die Konfiguration der vPC-Domäne und der vPC-Peer-Verbindung viel früher als die Konfiguration der Peer-Keepalive-Schnittstelle angewendet wird. Der VPC-Timer für die automatische Wiederherstellung könnte ablaufen, bevor Peer-Keepalive konfiguriert ist. VPC hat nie die Chance, herauszufinden, dass es bereits einen Peer mit der Rolle "primär" gibt, und VPC kann auch auf dem lokalen Switch als primär erscheinen, was zu einer geteilten Gehirnsituation führt.
- Konfiguration fehlt nach dem Hochfahren. Da die Befehle zeilenweise angewendet werden, kann es vorkommen, dass die zu konfigurierende Einheit noch nicht bereit ist und daher nicht konfiguriert werden kann. Dies wird in den meisten Fällen bei neueren Nexus Switches der Serie 9000 vermieden, ist jedoch für ältere Switches wie Nexus 7000 relevant. Beispiel: FEX-Portkonfiguration, d. h. Ports wie Ethernet101/1/1 können immer noch fehlen, wenn die entsprechenden Befehle angewendet werden müssen. Nach dem Ausführen des Befehls reload ascii ist eine vollständige Überprüfung der laufenden Konfiguration erforderlich.
- Die Konfiguration wird erst nach dem anschließenden Neuladen wirksam. Switches der Serie Nexus 9000 bieten im Allgemeinen Möglichkeiten, dies zu vermeiden, aber insbesondere auf Nexus 7000-Switches wird eine Konfiguration, die erst nach einem Neuladen wirksam wird, wie limit-resource u4route-mem minimum X maximum Y, erst nach einem anschließenden normalen Neuladen wirksam, genau so, als ob sie manuell über die CLI auf einem neuen Gerät konfiguriert wurde. Switch.
Empfohlener Ansatz zur Minimierung von Ausfallzeiten
Wenn es sich um ein redundantes Produktionsnetzwerk handelt, in dem Auswirkungen durch das Neuladen des Switches aufgrund der zuvor erwähnten potenziellen Probleme auf Nexus 7000-Switches und in geringerem Maße auf Nexus 9000-Switches vermieden werden müssen, wird empfohlen, das ASCII-Neuladen wie beschrieben durchzuführen.
- Trennen Sie den Switch vom Netzwerk, um sicherzustellen, dass sich inkonsistente Status während der Anwendung der Konfiguration nicht auf das Live-Netzwerk auswirken.
- Planen Sie einen langen Neuladeprozess, insbesondere bei modularen Switches mit vielen Linecards und VDCs.
- Sichern der Konfigurationen aller VDCs
- Führen Sie den Befehl reload ascii aus. Während der Zugriff auf den Switch selbst relativ bald möglich ist, ist der Systemstart erst abgeschlossen, wenn "%ASCII-CFG-2-CONF_CONTROL: Die Meldung "System ready" (System bereit) wird im Syslog angezeigt. Dies kann deutlich länger dauern. Beispiele für zu suchende Nachrichten:
switch# show logging log | in ASCII
2025 Aug 20 09:32:07 switch %DAEMON-2-SYSTEM_MSG: <<%ASCII-CFG-2-CONF_CONTROL>> Ascii replay - ascii_cfg_server[14359]
2025 Aug 20 09:32:44 switch %ASCII-CFG-2-CONFIG_REPLAY_STATUS: Bootstrap Replay Started.
2025 Aug 20 09:32:49 switch %ASCII-CFG-2-CONFIG_REPLAY_STATUS: Bootstrap Replay Done.
2025 Aug 20 09:33:50 switch %ASCII-CFG-2-CONFIG_REPLAY_STATUS: Ascii Replay Started.
2025 Aug 20 09:33:56 switch %ASCII-CFG-2-CONFIG_REPLAY_STATUS: Ascii Replay Done.
2025 Aug 20 09:33:56 switch %ASCII-CFG-2-CONF_CONTROL: System ready
- Führen Sie eine Diff-Prüfung durch, um alle laufenden Konfigurationen mit den vor dem Neuladen vorgenommenen Sicherungen zu vergleichen. Wenn Teile der Konfiguration fehlen, fügen Sie sie manuell hinzu.
- Um sicherzustellen, dass alle neu zu ladenden Befehle wirksam werden, führen Sie die Befehle copy running-config startup-config und reload aus, um ein normales binäres Neuladen durchzuführen.
Feedback