O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Este documento descreve as etapas para entender e solucionar problemas de cenários de substituição de dispositivos na ACI.
O material deste documento foi extraído do Solução de problemas da Cisco Application Centric Infrastructure, segunda edição livro, especificamente o Fabric Discovery - Substituição de dispositivos capítulo.
Durante a evolução de uma estrutura da ACI, será necessário substituir vários componentes, incluindo: APICs, switches leaf, switches spine e dispositivos IPN. Os motivos mais comuns para a substituição incluem RMAs e atualizações de hardware. Esses procedimentos são bem documentados nos guias de instalação/atualização da Cisco e o guia mais recente deve ser lido antes da substituição. Esta seção incluirá uma análise mais aprofundada do funcionamento dos procedimentos sob o capô; além de apresentar vários dos cenários mais comuns de solução de problemas.
Note: A partir da versão 5.2(3) do switch ACI, os switches NXOS conectados a um switch de estrutura ACI descoberto podem usar POAP para converter em um switch ACI.
Uma folha do depósito de RMA chegará executando o software NXOS. Consulte a seção abaixo chamada 'Problema: Chega ao modo NXOS para converter corretamente a folha para o modo ACI. Se estiver usando uma folha de uma estrutura diferente ou com uma configuração anterior, certifique-se de usar os comandos 'acidiag touch clean' e 'reload'.
Depois que as etapas acima forem concluídas e o novo switch leaf estiver pronto para registro, remova a leaf a ser substituída da estrutura por meio da opção "Remover do controlador".
A opção 'Remover do controlador' removerá completamente o nó do APIC, liberando a ID do nó, a associação SN e o endereço TEP que foi atribuído pelo APIC. Esses processos são desejados ao substituir um nó de switch. A opção 'Descomissionar' só é usada quando a expectativa é que o mesmo nó reingresse na malha com o mesmo ID de nó e SN.
Quando o switch de folha a ser substituído não é mais visto na página Fabric Membership, a nova folha pode ser conectada à estrutura através das interfaces spine. Quando a folha for descoberta pelo APIC, ela aparecerá no Fabric Inventory e estará pronta para registro. Se o dispositivo a ser substituído ainda não tiver liberado sua ID de nó e um novo switch estiver registrado com a mesma ID de nó, uma falha será lançada referindo-se ao fato de que a ID já está associada a outro nó folha. A falha deve desaparecer após algum tempo. Se o novo nó não aparecer no submenu Fabric Membership (Associação de estrutura), pode haver um problema de cabeamento; isso pode ser verificado visualizando os vizinhos LLDP através do comando 'show lldp neighbors detail' nos switches spine que se conectam ao switch leaf recém-conectado. Para obter mais detalhes sobre o processo Fabric Discovery, consulte o capítulo "Configuração inicial da malha".
Se a infra VLAN for modificada, todos os nós de folha deverão ser reinicializados ao mesmo tempo. Se todos os switches leaf não forem limpos ao mesmo tempo, um switch recarregado e limpo será ativado e receberá a VLAN infra antiga via LLDP de uma folha ainda não limpa, e a folha recarregada e limpa falhará ao se registrar no APIC. Consulte o capítulo "Configuração inicial da estrutura" para obter mais detalhes.
Devido às limitações da plataforma, os pares de VPC não podem ser uma combinação de switches leaf Gen1 e Gen2 ou superiores. No entanto, no momento da escrita, qualquer folha de Gen2 ou superior pode se misturar com qualquer outra folha de Gen2 ou superior.
Como uma folha, dependendo do HW da coluna (como a coluna modular), ela pode chegar no modo NXOS. Use o procedimento "Problema: Chega no modo NXOS" sob os cenários para executar a conversão.
Ao substituir um switch spine, o usuário deve considerar a funcionalidade Refletor de rota BGP. Como prática recomendada, deve haver pelo menos dois switches spine configurados como refletores de rota BGP para uma estrutura de camada 3 da Cisco ACI. Esta configuração está localizada em 'System > System Settings > BGP Route Refletors' em Route Refletor Nodes. Ao substituir ou remover um switch spine, verifique se foram feitas as alterações de configuração apropriadas para manter um refletor de rota ativo e assegure-se de que pelo menos dois refletores de rota ativos após a conclusão das alterações.
Consulte a seção "Políticas de Pod — BGP RR / Date&Time / SNMP" no capítulo "Gerenciamento e serviços centrais" para obter mais informações sobre os Refletores de Rota BGP.
A consideração mais importante ao executar uma substituição do APIC é a integridade do cluster atual do APIC. Antes da substituição, todos os APICs no cluster devem ser relatados como totalmente adequados. Na versão 4.2, uma ferramenta adicional foi introduzida para verificar a integridade do cluster APIC via CLI:
apic1# acidiag cluster
Admin password:
Product-name = APIC-SERVER-L2
Serial-number = FCH2206W0RK
Running...
Checking Core Generation: OK
Checking Wiring and UUID: OK
Checking AD Processes: Running
Checking All Apics in Commission State: OK
Checking All Apics in Active State: OK
Checking Fabric Nodes: OK
Checking Apic Fully-Fit: OK
Checking Shard Convergence: OK
Checking Leadership Degration: Optimal leader for all shards
Ping OOB IPs:
APIC-1: 192.168.4.20 - OK
Ping Infra IPs:
APIC-1: 10.0.0.1 - OK
Checking APIC Versions: Same (4.2(1i))
Checking SSL: OK
Done!
Ao substituir um APIC, observe as variáveis de configuração inicial do APIC a serem substituídas antes de executar uma desativação do APIC.
apic1# cat /data/data_admin/sam_exported.config
Setup for Active and Standby APIC
fabricDomain = POD37
fabricID = 1
systemName =apic1
controllerID = 1
tepPool = 10.0.0.0/16
infraVlan = 3937
GIPo = 225.0.0.0/15
clusterSize = 3
standbyApic = NO
enableIPv4 = Y
enableIPv6 = N
firmwareVersion = 4.2(1i)
ifcIpAddr = 10.0.0.1
apicX = NO
podId = 1
oobIpAddr = 10.48.176.57/24
Prepare o novo APIC com a versão de software correta e insira novamente os valores de configuração inicial mencionados anteriormente. Quando a configuração inicial estiver concluída e o APIC estiver totalmente inicializado, faça a reativação para a estrutura a partir da interface do usuário de um dos outros APICs no cluster.
Em um ambiente com vários pods, pode ser necessário substituir um dos dispositivos que estão sendo usados para a IPN (Inter-Pod Network). Antes da substituição, a rede IPN deve ter a redundância de ponto de encontro bidirecional PIM configurada na forma de RPs fantasmas. Sem RPs fantasmas no lugar, se o nó substituído fosse o RP, haveria uma convergência de PIM e a perda de pacotes seria vista para todo o tráfego BUM enviado através do IPN.
Consulte "Configuração do RP" no capítulo "Descoberta de vários pods" para obter mais informações sobre como configurar o RP fantasma.
Em determinados cenários, a melhor opção para recuperar uma folha/coluna que não se juntará à estrutura é executar uma recarga limpa do dispositivo.
Não é recomendável executar uma recarga limpa em um dispositivo que esteja aguardando sua vez de atualizar. A recarga limpa de qualquer dispositivo pode levar um longo período de tempo.
O comando 'acidiag touch' tem duas opções, clean e setup. A opção clean remove todos os dados da política enquanto mantém a configuração de rede do APIC (como nome da estrutura, endereço IP, login). A opção setup remove os dados de política e a configuração de rede do APIC. A opção de configuração é mais comumente usada ao mover dispositivos entre Pods, pois o ID do Pod deve ser alterado e, normalmente, a rede de gerenciamento também precisará ser atualizada.
APIC
fab1-apic1# acidiag touch clean
This command will wipe out this device, Proceed? [y/N] y
fab1-apic1# acidiag reboot
This command will restart this device, Proceed? [y/N] y
Folha/Coluna
fab1-leaf101# acidiag touch clean
This command will wipe out this device, Proceed? [y/N] y
fab1-leaf101# reload
This command will reload the chassis, Proceed (y/n)? [n]: y
O comando 'acidiag touch clean' funciona colocando um arquivo oculto na folha em /mnt/pss chamado .clean. Quando a folha é inicializada, um script shell é executado para verificar se o arquivo .clean está presente. Caso o arquivo .clean exista em /mnt/pss, a configuração de política é apagada e a configuração é baixada novamente do APIC. Se esse comando for inserido e o nó não for recarregado, o arquivo ainda estará presente e a política ainda será apagada na próxima recarga, não importa quanto tempo tenha decorrido desde que a limpeza por toque foi inserida.
Às vezes, quando um switch é enviado via RMA, ele pode chegar com o software NXOS que ainda não foi configurado por meio do processo Power On Auto Provisioning (POAP). Quando o usuário usar o console para se conectar a esse dispositivo, ele verá alguma forma da seguinte mensagem:
Cancelar o provisionamento automático e continuar com a configuração normal ?(yes/no)
Se o dispositivo já passou por POAP, a maneira mais simples de determinar se uma folha está executando código NXOS autônomo é procurar a linha 'NXOS image file' na saída 'show version'. Se essa saída estiver presente, o leaf estará executando código independente e precisará ser convertido para o modo ACI. A presença do Kickstart e de imagens do sistema pode ser verificada e estará presente apenas em uma folha executando uma imagem da ACI, observando a própria imagem, que será n9000 em independente e aci-n9000 em ACI.
NXOS independente
nxos-n9k# show version
Cisco Nexus Operating System (NX-OS) Software
.
.
.
Software
BIOS: version 07.17
NXOS: version 6.1(2)I3(4)
BIOS compile time: 09/10/2014
NXOS image file is: bootflash:///n9000-dk9.6.1.2.I3.4.bin
NXOS compile time: 3/18/2015 0:00:00 [03/18/2015 07:49:10]
ACI
aci-leaf101# show version
Cisco Nexus Operating System (NX-OS) Software
.
.
.
Software
BIOS: version 07.66
kickstart: version 14.2(1i) [build 14.2(1i)]
system: version 14.2(1i) [build 14.2(1i)]
PE: version 4.2(1i)
BIOS compile time: 06/11/2019
kickstart image file is: /bootflash/aci-n9000-dk9.14.2.1i.bin
kickstart compile time: 09/07/2019 10:25:16 [09/07/2019 10:25:16]
system image file is: /bootflash/auto-s
system compile time: 09/07/2019 10:25:16 [09/07/2019 10:25:16]
Se o switch tiver sido fornecido com código NXOS, ele precisará ser convertido para o modo ACI. O switch deve ser fornecido com o NXOS e a imagem da ACI no flash de inicialização, embora nem sempre seja esse o caso. A imagem da ACI começará com "aci-n9000". Se a imagem da ACI não estiver presente, ela precisará ser carregada manualmente no flash de inicialização. Isso pode ser feito através da conexão USB (acesso local necessário) ou via SCP diretamente do APIC (supondo que ambos os dispositivos estejam conectados por uma rede de gerenciamento). Aqui estão as instruções para copiar a imagem via SCP:
1. nexus-9000(config)# feature scp-server
2. apic1# scp -r /firmware/fwrepos/fwrepo/switch-image-name admin@standalone_switch:switch-image-name
A folha precisará ser configurada para não inicializar a imagem NXOS, salvar a configuração e alterar as instruções de inicialização para ACI.
1. (config)# no boot nxos
2. (config)# copy run start
3. (config)# boot aci bootflash:
4. (config)# reload
As seguintes falhas serão vistas em Faults for the Nexus 9000 ACI switch.
F1582 Detectada incompatibilidade de versão FPGA. Versão atual:0x(z) Versão esperada:0x(y)
Na CLI do APIC, procure todas as instâncias de Fault F1582:
apic1# moquery -c faultInst -f 'fault.Inst.code=="F1582"'
Os switches de modo ACI Cisco Nexus 9000 Series contêm vários dispositivos lógicos programáveis (PLDs) que fornecem funcionalidades de hardware em todos os módulos. A Cisco fornece atualizações de imagem de dispositivo lógico programável eletrônico (EPLD) para aprimorar a funcionalidade do hardware ou para resolver problemas conhecidos. Os PLDs incluem dispositivos lógicos programáveis eletrônicos (EPLDs), matrizes de portas programáveis de campo (FPGAs) e dispositivos lógicos programáveis complexos (CPLDs), mas não incluem ASICs.
O termo EPLD é utilizado para abranger tanto o FPGA como o CPLD.
A vantagem de ter EPLDs para algumas funções de módulo é que quando essas funções precisam ser atualizadas, basta atualizar suas imagens de software em vez de substituir seu hardware.
As atualizações de imagem EPLD para um módulo de I/O interrompem o tráfego que passa pelo módulo porque ele deve ser desligado brevemente durante a atualização. Em um chassi modular, o sistema executa atualizações EPLD em um módulo por vez, portanto, a qualquer momento, a atualização interrompe apenas o tráfego que passa por um módulo.
A Cisco fornece as imagens EPLD mais recentes com cada versão. Normalmente, essas imagens são as mesmas fornecidas em versões anteriores, mas ocasionalmente algumas dessas imagens são atualizadas. Essas atualizações de imagem EPLD não são obrigatórias, a menos que especificado de outra forma. Quando a Cisco disponibiliza uma atualização de imagem EPLD, essas notas de versão anunciam sua disponibilidade e podem ser baixadas do site da Cisco.
Quando novas imagens EPLD estão disponíveis, as atualizações são sempre recomendadas se o ambiente de rede permitir um período de manutenção no qual algum nível de interrupção de tráfego é aceitável. Em geral, as atualizações do EPLD serão necessárias quando uma nova funcionalidade de hardware for adicionada como resultado de uma atualização de software.
Também pode haver várias razões para a necessidade de atualizar o firmware EPLD enquanto já estiver no modo ACI:
Quando a folha ou a lombada for adicionada à estrutura, o EPLD será atualizado automaticamente com qualquer atualização de política (atualização normal iniciada na guia de firmware do APIC) quando uma nova versão do EPLD estiver disponível.
Em versões mais antigas da ACI, era necessário fazer o downgrade e depois atualizar a folha/coluna em questão, mas a partir da versão 11.2(1m), há dois scripts de shell disponíveis para o usuário administrador, o que simplifica muito o processo.
fab1-leaf101# /bin/check-fpga.sh FpGaDoWnGrAdE
fab1-leaf101# /usr/sbin/chassis-power-cycle.sh
O script '/usr/sbin/chassis-power-cycle.sh' reinicializa a energia, em comparação com um 'reload', que é simplesmente uma reinicialização do software. Ao atualizar o EPLD, a energia precisa ser totalmente removida para reprogramar o firmware nas placas de linha. Se '/usr/sbin/chassis-power-cycle.sh' não estiver disponível ou não funcionar, os cabos de alimentação precisarão ser removidos por pelo menos 30 segundos e depois reconectados para restaurar a alimentação.
Revisão | Data de publicação | Comentários |
---|---|---|
1.0 |
08-Aug-2022 |
Versão inicial |