Resolución de problemas de ACI Fabric Discovery - Sustitución de dispositivos

Introducción

En este documento se describen los pasos para comprender y solucionar problemas de los escenarios de sustitución de dispositivos en ACI.

Antecedentes

El material de este documento se ha extraído de la Solución de problemas de Cisco Application Centric Infrastructure, segunda edición , en concreto el Fabric Discovery, Sustitución de dispositivos capítulo.

Overview

Durante la evolución de un fabric de ACI, será necesario sustituir varios componentes, entre ellos: APIC, switches de hoja, switches de columna y dispositivos IPN. Las razones más comunes para la sustitución incluyen las RMA y las actualizaciones de hardware. Estos procedimientos están bien documentados en las guías de instalación/actualización de Cisco y la guía más reciente debe leerse antes de la sustitución. Esta sección incluirá un análisis más profundo de cómo funcionan los procedimientos bajo el capó; así como recorrer varios de los escenarios de resolución de problemas más comunes.

Procedimientos y verificación

Nota: A partir de la versión 5.2(3) del switch ACI, los switches NXOS conectados a un switch de fabric ACI detectado pueden utilizar POAP para convertirse en un switch ACI.

Reemplazo de hardware

Hoja

Llegará una hoja del almacén de RMA con el software NXOS. Consulte la siguiente sección denominada "Problema: Llega al modo NXOS' para convertir correctamente la hoja al modo ACI. Si utiliza una hoja de otro fabric o con una configuración anterior, asegúrese de utilizar los comandos 'acidiag touch clean' y 'reload'.

Una vez que se hayan completado los pasos anteriores y el nuevo switch de hoja esté listo para el registro, elimine la hoja que desea reemplazar del fabric mediante la opción "Quitar del controlador".

La opción "Quitar del controlador" eliminará completamente el nodo del APIC, liberando el ID de nodo, la asociación SN y la dirección TEP que asignó el APIC. Estos procesos se desean cuando se reemplaza un nodo de switch. La opción 'Retirar' solo se utiliza cuando se espera que el mismo nodo se vuelva a unir al fabric con el mismo ID de nodo y SN.

Cuando el switch de hoja que se reemplazará ya no se ve en la página Fabric Membership, la nueva hoja se puede conectar al fabric a través de las interfaces de columna. Una vez que el APIC descubre la hoja, esta aparecerá en el inventario de fabric y estará lista para registrarse. Si el dispositivo que se reemplazará aún no ha liberado su ID de nodo y se registra un nuevo switch con el mismo ID de nodo, se producirá un error que hace referencia al hecho de que el ID ya está asociado a otro nodo de hoja. La falla debería aclararse después de algún tiempo. Si el nuevo nodo no aparece en el submenú Fabric Membership (Pertenencia a fabric), podría haber un problema de cableado; esto se puede verificar al ver los vecinos LLDP a través del comando 'show lldp neighbors detail' en los switches de columna que se conectan al switch de hoja recién conectado. Para obtener más información sobre el proceso de detección de fabric, consulte el capítulo "Configuración inicial de fabric".

Si se modifica la VLAN infra, todos los nodos de hoja deben reiniciarse limpiamente al mismo tiempo. Si no se limpian todos los switches de hoja al mismo tiempo, un switch recargado limpio se conectará y recibirá la VLAN infra antigua a través de LLDP de una hoja sin limpiar aún, y la hoja recargada limpia no podrá registrarse con el APIC. Consulte el capítulo "Configuración inicial del fabric" para obtener más información.

Debido a las limitaciones de la plataforma, los pares VPC no pueden ser una mezcla de switches de hoja Gen1 y Gen2 o superiores. Sin embargo, en el momento de escribir este artículo, cualquier hoja Gen2 o superior puede mezclarse con cualquier otra hoja Gen2 o superior.

Columna

Como una hoja, dependiendo del hardware de la columna (como la columna modular) podría llegar en modo NXOS. Utilice el procedimiento "Problema: Llega al modo NXOS" en los escenarios para realizar la conversión.

Al reemplazar un switch de columna, el usuario debe considerar la funcionalidad BGP Route Reflector. Como práctica recomendada, debe haber al menos dos switches de columna configurados como reflectores de ruta BGP para un fabric de Cisco ACI de capa 3. Esta configuración se encuentra en 'Sistema > Configuración del sistema > Reflectores de ruta BGP' en Nodos reflectores de ruta. Cuando reemplace o quite un switch de columna, asegúrese de que se realicen los cambios de configuración apropiados para mantener un Route Reflector activo y asegúrese de que haya al menos dos Route Reflectors activos después de que se completen los cambios.

Consulte la sección "Políticas de Pod: BGP RR / Date&Time / SNMP" en el capítulo "Gestión y servicios de núcleo" para obtener más información sobre los reflectores de ruta BGP.

APIC

La consideración más importante a la hora de realizar una sustitución de APIC es el estado del clúster APIC existente. Antes de la sustitución, todos los APIC del clúster deben aparecer como Totalmente ajustados. En 4.2, se introdujo una herramienta adicional para verificar el estado del clúster APIC mediante 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!

Cuando reemplace un APIC, asegúrese de anotar las variables de configuración inicial del APIC que desea reemplazar, antes de realizar una retirada del servicio del 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 el nuevo APIC con la versión de software correcta y vuelva a introducir los valores de configuración iniciales indicados anteriormente. Una vez finalizada la configuración inicial y arrancado el APIC por completo, vuelva a enviarlo al fabric desde la interfaz de usuario de uno de los otros APIC del clúster.

Sustitución de dispositivo IPN

En un entorno Multi-Pod, puede ser necesario sustituir uno de los dispositivos que se utilizan para el IPN (red Inter-Pod). Antes de la sustitución, la red IPN debe tener PIM Bidirectional Rendezvous Point Redundancy configurado en forma de Phantom RPs. Sin los RP fantasma instalados, si el nodo reemplazado fuera el RP, habría una convergencia PIM y se vería la pérdida de paquetes para todo el tráfico BUM enviado a través del IPN.

Consulte "Configuración RP" en el capítulo "Detección de Multi-Pod" para obtener más información sobre cómo configurar Phantom RP.

Recarga limpia de APIC/hoja/columna

En ciertos escenarios, la mejor opción para recuperar una hoja/columna que no se unirá a la estructura es realizar una recarga limpia del dispositivo.

No se recomienda realizar una recarga limpia en un dispositivo que está esperando su turno para actualizar. La recarga limpia de cualquier dispositivo puede tardar un período de tiempo prolongado.

El comando 'acidiag touch' tiene dos opciones: limpiar y configurar. La opción clean elimina todos los datos de la política mientras conserva la configuración de red APIC (como el nombre del fabric, la dirección IP o el inicio de sesión). La opción setup quita los datos de la política y la configuración de red APIC. La opción de configuración se suele utilizar cuando se mueven dispositivos entre grupos de dispositivos, ya que se debe cambiar la ID de grupo de dispositivos y, normalmente, la red de gestión también tendrá que actualizarse.

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

Hoja/Columna

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

El comando 'acidiag touch clean' funciona colocando un archivo oculto en la hoja en /mnt/pss llamado .clean. Cuando se arranca la hoja, se ejecuta una secuencia de comandos de shell que comprueba si el archivo .clean está presente. En el caso de que el archivo .clean exista en /mnt/pss, la configuración de la política se borra y la configuración se vuelve a descargar del APIC. Si se ingresa este comando y el nodo no se recarga, el archivo seguirá presente y la política se borrará en la próxima recarga, sin importar cuánto tiempo haya transcurrido desde que se ingresó la limpieza táctil.

Escenarios de resolución de problemas

Problema: Llega en modo NXOS

Verificación

A veces, cuando se envía un switch mediante RMA, puede llegar con el software NXOS que aún no se ha configurado mediante el proceso de aprovisionamiento automático de encendido (POAP). Cuando el usuario se consuele en este dispositivo, verá algún tipo de mensaje como el siguiente:

Anular el aprovisionamiento automático y continuar con la configuración normal ?(sí/no)

Si el dispositivo ya ha pasado por POAP, la forma más sencilla de determinar si una hoja está ejecutando código NXOS independiente es buscar la línea 'archivo de imagen NXOS' en la salida 'show version'. Si dicho resultado está presente, la hoja está ejecutando código independiente y deberá convertirse al modo ACI. Se puede verificar la presencia de Kickstart y de las imágenes del sistema y solo estará presente en una hoja que ejecute una imagen ACI, observando la propia imagen, que será n9000 en modo independiente y aci-n9000 en ACI.

NXOS independiente

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]

Solución

Si el switch se envió con código NXOS, deberá convertirse al modo ACI. El switch debe enviarse con la imagen de NXOS y ACI en la memoria de inicialización, aunque no siempre es así. La imagen de ACI comenzará con 'aci-n9000'. Si la imagen de ACI no está presente, deberá cargarse manualmente en la memoria flash de inicialización. Esto se puede realizar mediante la conexión USB (se necesita acceso local) o mediante SCP desde el APIC directamente (suponiendo que ambos dispositivos estén conectados a través de una red de gestión). Estas son las instrucciones para copiar la imagen a través de SCP:

1. nexus-9000(config)# feature scp-server
2. apic1# scp -r /firmware/fwrepos/fwrepo/switch-image-name admin@standalone_switch:switch-image-name

La hoja deberá configurarse para no arrancar la imagen de NXOS, guardar la configuración y cambiar las sentencias de arranque a ACI.

1. (config)# no boot nxos
2. (config)# copy run start
3. (config)# boot aci bootflash:
     
     
4. (config)# reload

Problema: EPLD/FPGA de columna/hoja incorrecto, F1582

Verificación

Los siguientes fallos se verán en los fallos del switch Nexus 9000 ACI.

Se detectó una discordancia de versión F1582 FPGA. Versión en ejecución:0x(z) Versión esperada:0x(y)

En la CLI de APIC, busque todas las instancias de Fault F1582:

apic1# moquery -c faultInst -f 'fault.Inst.code=="F1582"'

Notas de EPLD

Los switches de modo ACI Nexus de Cisco serie 9000 contienen varios dispositivos lógicos programables (PLD) que proporcionan funciones de hardware en todos los módulos. Cisco proporciona actualizaciones de imagen de dispositivos lógicos programables electrónicos (EPLD) para mejorar la funcionalidad del hardware o resolver problemas conocidos. Los PLD incluyen dispositivos lógicos programables electrónicos (EPLD), matrices de puertas programables in situ (FPGA) y dispositivos lógicos programables complejos (CPLD), pero no incluyen ASIC.

El término EPLD se utiliza para abarcar tanto FPGA como CPLD.

La ventaja de tener EPLD para algunas funciones de módulo es que cuando esas funciones necesitan ser actualizadas, simplemente actualizan sus imágenes de software en lugar de reemplazar su hardware.

Las actualizaciones de imagen EPLD para un módulo de E/S interrumpen el tráfico que atraviesa el módulo porque el módulo debe apagarse brevemente durante la actualización. En un chasis modular, el sistema realiza actualizaciones de EPLD en un módulo a la vez, de modo que en cualquier momento la actualización interrumpe solo el tráfico que pasa por un módulo.

Cisco proporciona las imágenes EPLD más recientes en cada versión. Normalmente, estas imágenes son las mismas que las proporcionadas en versiones anteriores, pero ocasionalmente algunas de estas imágenes se actualizan. Estas actualizaciones de imagen EPLD no son obligatorias a menos que se especifique lo contrario. Cuando Cisco pone a disposición una actualización de imagen EPLD, estas notas de la versión anuncian su disponibilidad y se pueden descargar desde el sitio web de Cisco.

Cuando hay nuevas imágenes EPLD disponibles, siempre se recomiendan las actualizaciones si el entorno de red permite un período de mantenimiento en el que sea aceptable cierto nivel de interrupción del tráfico. En general, se necesitarán actualizaciones de EPLD cuando se añada nueva funcionalidad de hardware como resultado de una actualización de software.

También puede haber varias razones para la necesidad de actualizar el firmware de EPLD mientras se encuentra en el modo ACI:

1. Las versiones de EPLD necesitaban una actualización antes de la conversión de Cisco NX-OS al modo de arranque ACI y NO se actualizaron los FPGA/EPLD.
2. La columna/hoja se actualizó manualmente (en lugar de una actualización de políticas desde el APIC), que no incluye una actualización de EPLD.

Una vez que se agrega la hoja o la columna al fabric, el EPLD se actualizará automáticamente con cualquier actualización de política (actualización normal iniciada desde la ficha de firmware APIC) en la que esté disponible una nueva versión de EPLD.

Solución

En las versiones anteriores de ACI, era necesario realizar un downgrade y, a continuación, actualizar la hoja/columna en cuestión, pero a partir de la versión 11.2(1m), hay dos scripts de shell disponibles para el usuario administrador que simplifican en gran medida el proceso.

fab1-leaf101# /bin/check-fpga.sh FpGaDoWnGrAdE
fab1-leaf101# /usr/sbin/chassis-power-cycle.sh

El script '/usr/sbin/chassis-power-cycle.sh' restablece la energía, en comparación con una 'recarga' que es simplemente un reinicio de software. Al actualizar EPLD, la alimentación debe ser removida completamente para reprogramar el firmware en las tarjetas de línea. Si '/usr/sbin/chassis-power-cycle.sh' no está disponible o no funciona, los cables de alimentación deben quitarse durante al menos 30 segundos y volver a conectarse para restaurar la alimentación.