Contents

Introdução

Arquivos de configuração do NX-OS

Possíveis problemas com a inicialização ASCII

Abordagem recomendada para minimizar o tempo de inatividade

Introdução

Este documento descreve as implicações do uso do comando reload ascii.

Arquivos de configuração do NX-OS

Durante a inicialização, o NXOS pode carregar a configuração de duas maneiras diferentes:

- Boot binário: o mecanismo de inicialização padrão. A configuração pré-compilada em formato binário é aplicada a todos os processos NXOS. O arquivo de configuração de inicialização de texto sem formatação não é usado e está disponível apenas para referência. Em geral, espera-se que esse arquivo reflita com precisão a configuração aplicada na inicialização, uma vez que é um espelho da configuração em execução, que é a base da configuração binária. Essa configuração binária é chamada de Serviço de Armazenamento Persistente (PSS).

- Inicialização ASCII: usado somente em situações excepcionais. A configuração em formato de texto simples é lida do arquivo startup-config. Em seguida, ele é aplicado durante a inicialização do switch exatamente como teria sido se fosse inserido via CLI do NX-OS, linha por linha. Conceitualmente semelhante a executar os comandos write erase e reload, seguido por copiar um backup da configuração para running-config.

Possíveis problemas com a inicialização ASCII

Geralmente, não é recomendável executar esse comando, a menos que o TAC da Cisco o proponha.

O comportamento exato pode diferir entre diferentes modelos de switch e versões de software. Em geral, os switches Nexus 9000 Series mais recentes mostram muito menos problemas relacionados à inicialização ASCII, pois houve soluções alternativas aplicadas internamente para minimizar o impacto. Switches mais antigos, como o Nexus 7000, podem encontrar mais problemas.

- Hora de inicializar. O switch pode demorar significativamente mais para ser inicializado, especialmente se for um switch modular com uma grande quantidade de VDCs. Em alguns casos, a inicialização pode demorar 1 hora ou até mais. Isso, por si só, pode causar problemas.

- Inconsistência de configuração durante a inicialização. Como a configuração é aplicada linha por linha em um ritmo relativamente lento, as partes da configuração que são anteriores no arquivo de configuração de inicialização podem ter efeito muito antes daquelas mais próximas do final. Por exemplo, pode acontecer que a configuração de domínio e link peer do VPC seja aplicada muito antes da configuração da interface peer-keepalive. O temporizador de recuperação automática do VPC pode expirar antes que o peer-keepalive seja configurado, o VPC nunca tem a chance de descobrir que já existe um peer com a função "primária", e o VPC pode vir como primário no switch local também, levando a uma situação cerebral dividida.

- Configuração ausente após a inicialização. Como os comandos estão sendo aplicados linha por linha, pode acontecer que a entidade que está sendo configurada ainda não esteja pronta, portanto sua configuração não pode ser aplicada. Isso é evitado na maioria dos casos em switches Nexus 9000 Series mais recentes, mas é relevante para os mais antigos, como o Nexus 7000. Exemplo: Configuração de porta FEX, portas como Ethernet101/1/1 ainda podem estar ausentes no sistema quando seus comandos precisarem ser aplicados. Depois de executar o comando reload ascii, é necessária uma verificação completa do diff da configuração atual.

- A configuração não terá efeito até o recarregamento subsequente. Os switches Nexus 9000 Series geralmente têm maneiras de evitar isso, mas nos switches Nexus 7000 em particular, a configuração que requer uma recarga para ter efeito, como limit-resource u4route-mem minimum X maximum Y, não tem efeito até uma recarga normal subsequente, exatamente como se tivesse sido configurada manualmente via CLI em um switch recém-pronto para uso.

Abordagem recomendada para minimizar o tempo de inatividade

Se você estiver lidando com uma rede de produção redundante na qual o impacto devido à recarga do switch precisa ser evitado, dadas as possíveis advertências mencionadas anteriormente, nos switches Nexus 7000 e, em menor extensão, nos switches Nexus 9000, é recomendável executar a recarga ASCII conforme descrito.

1. Isole o switch da rede para garantir que os estados inconsistentes durante o processo de aplicação da configuração não afetem a rede ativa.

2. Planeje que o processo de recarregamento leve muito tempo, especialmente em switches modulares com muitas placas de linha e VDCs.

3. Faça backup das configurações de todos os VDCs.

4. Execute o comando reload ascii. Embora o switch em si possa se tornar acessível relativamente cedo, a inicialização só é concluída depois que o "%ASCII-CFG-2-CONF_CONTROL: System ready" (Sistema pronto) é exibida no syslog. Isso pode demorar muito mais. Exemplos de mensagens a serem procuradas:
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. Execute uma verificação de comparação para comparar todas as configurações em execução com os backups obtidos antes do recarregamento. Se alguma parte da configuração estiver ausente, adicione-a manualmente.

6. Para garantir que todos os comandos que requerem um recarregamento tenham efeito, execute os comandos copy running-config startup-config e reload para executar um recarregamento binário normal.