Sommario

Introduzione

File di configurazione NX-OS

Problemi potenziali con l'avvio ASCII

Approccio consigliato per ridurre al minimo il downtime

Introduzione

In questo documento vengono descritte le implicazioni dell'utilizzo del comando reload ascii.

File di configurazione NX-OS

Durante l'avvio, NXOS può caricare la configurazione in uno dei due modi seguenti:

- Avvio binario il meccanismo di avvio predefinito. La configurazione precompilata in formato binario viene applicata a ogni processo NXOS. Il file startup-config in testo normale non viene utilizzato ed è disponibile solo come riferimento. In generale, ci si aspetta che questo file rifletta accuratamente la configurazione applicata all'avvio, dato è un mirror del running-config, su cui si basa la configurazione binaria. Questa configurazione binaria è denominata PSS (Persistent Storage Service).

- Avvio ASCII: utilizzata solo in situazioni eccezionali. La configurazione in formato testo normale viene letta dal file di configurazione di avvio. Viene quindi applicato durante l'avvio dello switch esattamente come sarebbe stato se fosse stato immesso tramite la CLI di NX-OS, riga per riga. Dal punto di vista concettuale, è simile all'esecuzione dei comandi write erase e reload, seguita dalla copia di backup della configurazione in running-config.

Problemi potenziali con l'avvio ASCII

In genere, non è consigliabile eseguire questo comando a meno che non sia stato proposto da Cisco TAC.

il comportamento esatto può variare a seconda del modello di switch e della versione software. In generale, i nuovi switch Nexus serie 9000 presentano un numero molto inferiore di problemi relativi all'avvio in modalità ASCII, in quanto sono state applicate internamente soluzioni alternative per ridurre al minimo l'impatto. sugli switch meno recenti, ad esempio Nexus 7000, possono verificarsi altri problemi.

- Tempo di avvio. L'avvio dello switch può richiedere molto più tempo, soprattutto se si tratta di uno switch modulare con una grande quantità di VDC. In alcuni casi, l'avvio può richiedere un'ora o anche più. Questo di per sé può causare problemi.

- Incoerenza nella configurazione durante l'avvio. Poiché la configurazione viene applicata riga per riga a un passo relativamente lento, le parti della configurazione precedenti nel file di configurazione di avvio possono avere effetto molto prima di quelle vicine alla fine. Ad esempio, potrebbe accadere che la configurazione del dominio VPC e del collegamento peer venga applicata molto prima della configurazione dell'interfaccia peer-keepalive. Il timer di ripristino automatico del VPC potrebbe scadere prima della configurazione di peer-keepalive, il VPC non ha mai la possibilità di scoprire che esiste già un peer con ruolo "primario" e il VPC potrebbe essere primario anche sullo switch locale, determinando una situazione di separazione del cervello.

- Configurazione mancante dopo l'avvio. Poiché i comandi vengono applicati riga per riga, è possibile che l'entità configurata non sia ancora pronta, pertanto non è possibile applicarne la configurazione. Ciò viene evitato nella maggior parte dei casi sui nuovi switch Nexus serie 9000, ma è rilevante per quelli più vecchi come Nexus 7000. Esempio: La configurazione delle porte FEX, le porte come Ethernet101/1/1 possono ancora mancare nel sistema nel momento in cui è necessario applicare i relativi comandi. Dopo aver eseguito il comando reload ascii, è necessario eseguire un controllo diff completo della configurazione in esecuzione.

- La configurazione non avrà effetto fino al successivo caricamento. Gli switch Nexus serie 9000 in genere hanno dei modi per evitare questo problema, ma in particolare sugli switch Nexus 7000, la configurazione che richiede un ricaricamento per avere effetto, come ad esempio limit-resource u4route-mem minimum X maximum Y, non ha effetto fino a quando non viene ricaricato successivamente, esattamente come se fosse stato configurato manualmente tramite CLI su uno switch appena pronto.

Approccio consigliato per ridurre al minimo il downtime

Se si ha a che fare con una rete di produzione ridondante in cui è necessario evitare l'impatto dovuto al ricaricamento dello switch, date le potenziali avvertenze menzionate in precedenza, sugli switch Nexus 7000 e, in misura minore, sugli switch Nexus 9000, si consiglia di eseguire il ricaricamento ASCII come descritto.

1. Isolare lo switch dalla rete per assicurarsi che eventuali stati incoerenti durante il processo di applicazione della configurazione non influiscano sulla rete in uso.

2. Pianificare un processo di ricaricamento che richieda molto tempo, in particolare sugli switch modulari con molte schede di linea e VDC.

3. Eseguire il backup delle configurazioni di tutti i controller di dominio virtuali.

4. Eseguire il comando reload ascii . Sebbene lo switch possa diventare accessibile relativamente presto, l'avvio viene completato solo dopo che "%ASCII-CFG-2-CONF_CONTROL: In syslog viene visualizzato il messaggio "System ready" (Predisposizione sistema). Questa operazione può richiedere molto più tempo. Esempi di messaggi da cercare:
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

5. Eseguire un controllo delle differenze per confrontare tutte le configurazioni in esecuzione con i backup eseguiti prima di ricaricare. Se mancano parti della configurazione, aggiungerle manualmente.

6. Per accertarsi che tutti i comandi che richiedono un ricaricamento abbiano effetto, eseguire i comandi copy running-config startup-config e reload per eseguire un normale ricaricamento binario.