Configuración de SSO de alta disponibilidad en Catalyst 9800 | Guía de inicio rápido

WLC1#show running-config | s interface
interface GigabitEthernet1
 shutdown
 negotiation auto
 no mop enabled
 no mop sysid
interface GigabitEthernet2
 switchport trunk allowed vlan 39
 switchport mode trunk
 negotiation auto
 no mop enabled
 no mop sysid
interface GigabitEthernet3
 negotiation auto
 no mop enabled
 no mop sysid
interface Vlan1
 no ip address
 shutdown
 no mop enabled
 no mop sysid
interface Vlan39
 ip address 10.48.39.130 255.255.255.0
 no mop enabled
 no mop sysid
wireless management interface Vlan39

WLC2#show running-config | s interface
interface GigabitEthernet1
 shutdown
 negotiation auto
 no mop enabled
 no mop sysid
interface GigabitEthernet2
 switchport trunk allowed vlan 39
 switchport mode trunk
 negotiation auto
 no mop enabled
 no mop sysid
interface GigabitEthernet3
 negotiation auto
 no mop enabled
 no mop sysid
interface Vlan1
 no ip address
 shutdown
 no mop enabled
 no mop sysid
interface Vlan39
 ip address 10.48.39.133 255.255.255.0
 no mop enabled
 no mop sysid
wireless management interface Vlan39

En este ejemplo, el WLC1 se designa como el controlador primario (que es el chasis 1) mientras que el WLC2 es el secundario (que es el chasis 2). Esto significa que el par de HA hecho de los 2 controladores utiliza la configuración de WLC1 y que el de WLC2 se pierde después del proceso.

Paso 1. (Opcional) Realice una copia de seguridad de los archivos de configuración de inicio y configuración en ejecución de los controladores.

Se puede producir un manejo incorrecto y la configuración se puede perder. Para evitar esto, se recomienda encarecidamente realizar una copia de seguridad de la configuración de inicio y ejecución desde ambos controladores utilizados en la configuración de HA. Esto se puede realizar fácilmente mediante la GUI del 9800 o la CLI.

Desde la GUI:

Desde la pestaña Administration → Management → Backup & Restore de la GUI del 9800 (consulte la captura de pantalla), se puede descargar la configuración de inicio y ejecución que actualmente utiliza el controlador.

En este ejemplo, tanto el inicio (lado izquierdo) como la configuración (lado derecho) se descargan directamente, a través de HTTP, en el dispositivo que aloja el navegador utilizado para acceder a la GUI del WLC. Uno puede ajustar fácilmente el modo de transferencia y el destino del archivo para hacer una copia de seguridad, con el campo Modo de transferencia.

Desde la CLI:

WLCx#copy running-config tftp://<SERVER-IP>/run-backup_x.cfg            
Address or name of remote host [<SERVER-IP>]? 
Destination filename [run-backup_x.cfg]? 
!!
19826 bytes copied in 1.585 secs (12509 bytes/sec)
WLCx#copy startup-config tftp://<SERVER-IP>/start-backup_x.cfg          
Address or name of remote host [<SERVER-IP>]? 
Destination filename [start-backup_x.cfg]? 
!!
20482 bytes copied in 0.084 secs (243833 bytes/sec)

Reemplace el <SERVER-IP> por la IP del servidor TFTP en la que se copia el archivo de configuración de inicio/ejecución.

Paso 2. (Opcional) Garantizar la conectividad de red.

Tanto desde las GUI de WLC como desde las CLI, se pueden realizar sencillas pruebas de conectividad, es decir, hacer ping en la puerta de enlace desde ambos dispositivos y hacer ping entre los dispositivos. Esto garantiza que ambos controladores tengan la conectividad requerida para configurar HA.

Desde la GUI:

La herramienta Ping and Traceroute de la pestaña Troubleshooting de la GUI del 9800 se puede utilizar para probar la conectividad entre los controladores mismos y entre cada WLC y su gateway de red, como se muestra en estas figuras.

Desde la CLI:

WLCx#ping 10.48.39.133 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.48.39.133, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms WLCx#ping 10.48.39.254 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.48.39.254, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

Paso 3. Configure la redundancia con el tipo de emparejamiento RMI + RP.

Con la conectividad asegurada entre cada dispositivo, se puede configurar la redundancia entre los controladores. Esta captura de pantalla muestra cómo se realiza la configuración desde la pestaña Redundancia de la página Administración→ Dispositivo de la GUI del 9800.

Advertencia: Para este ejemplo, el WLC1 se ha designado como controlador primario, lo que significa que éste es el que cuya configuración se replica al otro controlador. Asegúrese de aplicar la prioridad/renumeración adecuada del chasis para utilizar la configuración adecuada con su par HA y no perder ninguna parte de él.

Vamos a revisar los campos configurados y su finalidad

• Configuración de Redundancia: esto debe estar habilitado para utilizar redundancia entre los WLC.
• Tipo de emparejamiento de redundancia: dado que esta guía cubre HA SSO usando la configuración RMI, el tipo de emparejamiento configurado debe ser RMI + RP, usando tanto la interfaz de administración de redundancia como el puerto de redundancia. También se puede optar por configurar la redundancia usando solamente el puerto de redundancia. Sin embargo, cuando se elige RP solamente, la accesibilidad del gateway no se verifica, solamente el estado WLC redundante es
• IP RMI para chasis 1/2: estos campos asignan las direcciones IP proporcionadas a la interfaz de redundancia designada para ambas instancias. En este ejemplo, las IP RMI para el chasis 1 y 2 se han configurado como 10.48.39.131 y 10.48.39.132 respectivamente, tal como se describió anteriormente y se muestra en el diagrama de red.
• Interfaz HA: cuando se utilizan appliances virtuales, la asignación entre las tarjetas de interfaces de red virtuales (vNIC) del hipervisor y las interfaces de red de la máquina virtual se puede configurar de diferentes formas. Por lo tanto, la interfaz utilizada para la redundancia es configurable para Cisco Catalyst 9800-CLs. Aquí se ha utilizado GigabitEthernet 3, tal y como se recomienda en la guía de implementación de 9800-CL.
  
  

  Nota: al utilizar dispositivos físicos C9800, la interfaz utilizada en HA y RP es la predeterminada y no se puede configurar. De hecho, los WLC del hardware 9800 tienen una interfaz de redundancia dedicada que se separa de sus redes.

• Failover de gateway de administración: como se detalla en la guía de configuración de HA SSO, este método de redundancia implementa la comprobación de gateway predeterminada, que se realiza mediante el envío periódico de ping ICMP (Internet Control Message Protocol, Protocolo de mensajes de control de Internet) al gateway. Tanto los controladores activos como los de reserva utilizan la IP RMI como IP de origen para estas comprobaciones. Estos mensajes se envían en un intervalo de 1 segundo.

• Intervalo de fallo de puerta de enlace: representa la cantidad de tiempo durante el cual debe fallar consecutivamente una comprobación de puerta de enlace antes de que se declare que la puerta de enlace no es accesible. De forma predeterminada, esta opción está configurada como 8 segundos. Dado que las comprobaciones de la puerta de enlace se envían cada segundo, esto representa 8 fallos consecutivos para alcanzar la puerta de enlace.

• IP local/remota: IP de RP configurada para los chasis 1 y 2. Estas direcciones IP se generan automáticamente como 169.254.x.x, donde x.x se deriva de los últimos dos octetos de la interfaz de administración.

• Keep Alive Timer: como se detalla en la guía de configuración de HA SSO, el chasis activo y en espera se envían mensajes de señal de mantenimiento entre sí para asegurarse de que ambos aún estén disponibles. El temporizador de señal de mantenimiento es la cantidad de tiempo que se separa el envío de 2 mensajes de señal de mantenimiento entre cada chasis. De forma predeterminada, los mensajes keepalive se envían cada 100 ms. A menudo se recomienda aumentar este valor con 9800-CL para evitar los switchovers abusivos cada vez que la infraestructura de VM introduce pequeños retrasos (instantáneas, etc.)

• Reintentos de Mantener Activo: este campo configura el valor de reintento de keepalive del par antes de afirmar que el par está inactivo. Si se utilizan el temporizador de mantenimiento activo y el valor predeterminado de reintentos, se reclama un peer down si los 5 mensajes de mantenimiento activo enviados en el intervalo de tiempo de 100 ms quedan sin respuesta (es decir, si el link de redundancia está inactivo durante 500 ms).

• Número de chasis: el número de chasis que debe utilizar el dispositivo (1 o 2).

  • En el WLC2 (10.48.39.133), el chasis se renumera a 2. De forma predeterminada, el número de chasis es 1. Las direcciones IP de los puertos RP se derivan de RMI. Si el número de chasis es el mismo en ambos controladores, la derivación IP del puerto RP local es la misma y la detección falla. Renumérese el chasis para evitar este escenario denominado Activo-Activo.

• Prioridad de chasis activo: la prioridad utilizada para definir qué configuración debe utilizar el par HA. El dispositivo con la prioridad más alta es el que se replica en el otro. Por lo tanto, se pierde la configuración del chasis con la prioridad más baja.

  • En el WLC1 (10.48.39.130), la prioridad del chasis activo se ha configurado en 2. Esto es para asegurarse de que este chasis se elija como el activo (y por lo tanto, que se utilice su configuración) en el par HA creado.

Una vez realizadas estas configuraciones, utilice el botón Apply para aplicar la configuración a los controladores.

Desde la CLI

Primero, configure una dirección IP secundaria en la interfaz virtual utilizada para configurar la RMI en ambos dispositivos.

WLC1#configure terminal WLC1(config)#interface vlan 39 WLC1(config-if)# ip address 10.48.39.131 255.255.255.0 secondary WLC1(config-if)# end

WLC2#configure terminal WLC2(config)#interface vlan 39 WLC2(config-if)# ip address 10.48.39.132 255.255.255.0 secondary WLC2(config-if)# end

A continuación, habilite la redundancia en ambos dispositivos

WLC1#configure terminal WLC1(config)#redundancy WLC1(config-red)#mode sso WLC1(config-red)#end 

WLC2#configure terminal WLC2(config)#redundancy WLC2(config-red)#mode sso WLC2(config-red)#end 

Configure la prioridad del chasis, tal como el WLC1 se convierte en el controlador primario

WLC1#show chassis Chassis/Stack Mac Address : 0001.0202.aabb - Local Mac Address Mac persistency wait time: Indefinite H/W Current Chassis# Role Mac Address Priority Version State IP ------------------------------------------------------------------------------------- *1 Active 0001.0202.aabb 1 V02 Ready 169.254.39.131 WLC1#chassis 1 priority 2 WLC1#show chassis Chassis/Stack Mac Address : 0001.0202.aabb - Local Mac Address Mac persistency wait time: Indefinite H/W Current Chassis# Role Mac Address Priority Version State IP ------------------------------------------------------------------------------------- *1 Active 0001.0202.aabb 2 V02 Ready 169.254.39.131

Renumérese el chasis para el WLC2 que se convierte en el controlador secundario

WLC2#show chassis Chassis/Stack Mac Address : 0001.0202.aabb - Local Mac Address Mac persistency wait time: Indefinite H/W Current Chassis# Role Mac Address Priority Version State IP ------------------------------------------------------------------------------------- *1 Active 0001.0202.aabb 1 V02 Ready 169.254.39.132 WLC2#chassis 1 renumber 2 WLC2#show chassis Chassis/Stack Mac Address : 0001.0202.aabb - Local Mac Address Mac persistency wait time: Indefinite H/W Current Chassis# Role Mac Address Priority Version State IP ------------------------------------------------------------------------------------- *2 Active 0001.0202.aabb 1 V02 Ready 169.254.39.132 

Finalmente, configure RMI en ambos dispositivos

WLC1#chassis redundancy ha-interface GigabitEthernet 3 WLC1#configure terminal WLC1(config)#redun-management interface Vlan39 chassis 1 address 10.48.39.131 chassis 2 address 10.48.39.132 WLC1(config)#end

WLC2#chassis redundancy ha-interface GigabitEthernet 3 WLC2#configure terminal WLC2(config)#redun-management interface Vlan39 chassis 1 address 10.48.39.131 chassis 2 address 10.48.39.132 WLC2(config)#end

Nota: En cuanto a la configuración de la GUI, en el Catalyst 9800 virtual, la interfaz utilizada por el controlador debe seleccionarse entre las disponibles. Como se recomienda, GigabitEthernet 3 se utiliza aquí y se configura gracias al chassis redundancy ha-interface GigabitEthernet 3 comando. Este comando no forma parte de la configuración en ejecución, sin embargo, la interfaz utilizada por HA se puede ver en las variables de entorno ROMMON de instancia. Éstas se pueden ver usando el show romvar comando.

Paso 4. Recargue los controladores.

Para que se forme el par HA y la configuración sea efectiva, ambos controladores deben recargarse al mismo tiempo una vez que se haya guardado la configuración realizada en el paso 3.

Desde la GUI:

Se puede utilizar la página Administration Reload (Recarga de administración) de ambas interfaces gráficas de usuario para reiniciar los controladores, como se muestra en esta captura de pantalla.

Desde CLI:

WLCx#reload Reload command is being issued on Active unit, this will reload the whole stack Proceed with reload? [confirm]

Nota: Si utiliza un servidor AAA, debe agregar la dirección IP de WMI y la dirección IP de RMI como clientes AAA en el servidor AAA. El WLC en espera siempre utiliza su IP RMI para autenticar las sesiones SSH. El WLC activo utiliza RMI y WMI para alcanzar al servidor AAA.

Verificación

Una vez que ambos controladores del par HA se descubren entre sí y crean el par HA deseado, un controlador (el principal) puede supervisar los dos chasis desde la GUI o CLI.


Desde la GUI:

Para supervisar la configuración de redundancia desde la GUI del 9800, navegue hasta la pestaña Redundancia desde la página Monitoring > General > System (Supervisión > General > Sistema), como se muestra en esta captura de pantalla.

Desde CLI:

WLC#show chassis rmi Chassis/Stack Mac Address : 0050.568d.cdf4 - Local Mac Address Mac persistency wait time: Indefinite H/W Current Chassis# Role Mac Address Priority Version State IP RMI-IP -------------------------------------------------------------------------------------------------------- *1 Active 0050.568d.cdf4 2 V02 Ready 169.254.39.131 10.48.39.131 2 Standby 0050.568d.2a93 1 V02 Ready 169.254.39.132 10.48.39.132

WLC#show redundancy Redundant System Information : ------------------------------ Available system uptime = 22 minutes Switchovers system experienced = 0 Standby failures = 0 Last switchover reason = none Hardware Mode = Duplex Configured Redundancy Mode = sso Operating Redundancy Mode = sso Maintenance Mode = Disabled Communications = Up Current Processor Information : ------------------------------- Active Location = slot 1 Current Software state = ACTIVE Uptime in current state = 22 minutes Image Version = Cisco IOS Software [Cupertino], C9800-CL Software (C9800-CL-K9_IOSXE), Version 17.9.2, RELEASE SOFTWARE (fc2) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2022 by Cisco Systems, Inc. Compiled Wed 02-Nov-22 15:12 by mcpre BOOT = bootflash:packages.conf,12; CONFIG_FILE = Configuration register = 0x102 Recovery mode = Not Applicable Fast Switchover = Enabled Initial Garp = Enabled Peer Processor Information : ---------------------------- Standby Location = slot 2 Current Software state = STANDBY HOT Uptime in current state = 20 minutes Image Version = Cisco IOS Software [Cupertino], C9800-CL Software (C9800-CL-K9_IOSXE), Version 17.9.2, RELEASE SOFTWARE (fc2) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2022 by Cisco Systems, Inc. Compiled Wed 02-Nov-22 15:12 by mcpre BOOT = bootflash:packages.conf,12; CONFIG_FILE = Configuration register = 0x102

Troubleshoot

Reflejo de ventanilla única

Lo habitual no show tech wireless  incluye comandos que permitan comprender las fallas HA de un par HA ni su estado actual correctamente. Recopile este comando para tener la mayoría de los comandos relacionados con HA en una sola operación :

WLC#show tech wireless redundancy

Comandos show

Para el estado de los puertos de redundancia, se pueden utilizar estos comandos.

WLC#show chassis detail Chassis/Stack Mac Address : 0050.568d.2a93 - Local Mac Address Mac persistency wait time: Indefinite H/W Current Chassis# Role Mac Address Priority Version State IP ------------------------------------------------------------------------------------- 1 Standby aaaa.aaaa.aaaa 2 V02 Ready 169.254.39.131 *2 Active bbbb.bbbb.bbbb 1 V02 Ready 169.254.39.132 Stack Port Status Neighbors Chassis# Port 1 Port 2 Port 1 Port 2 -------------------------------------------------------- 1 OK OK 2 2 2 OK OK 1 1 WLC#show chassis rmi Chassis/Stack Mac Address : 0050.568d.2a93 - Local Mac Address Mac persistency wait time: Indefinite H/W Current Chassis# Role Mac Address Priority Version State IP RMI-IP -------------------------------------------------------------------------------------------------------- 1 Standby aaaa.aaaa.aaaa 2 V02 Ready 169.254.39.131 10.48.39.131 *2 Active bbbb.bbbb.bbbb 1 V02 Ready 169.254.39.132 10.48.39.132 

Este comando muestra el número de chasis y el estado del puerto redundante, útil como primer paso para solucionar problemas.

Para verificar los contadores de señal de mantenimiento en el puerto de señal de mantenimiento, se pueden utilizar estos comandos.

WLC#show platform software stack-mgr chassis active R0 sdp-counters Stack Discovery Protocol (SDP) Counters --------------------------------------- Message Tx Success Tx Fail Rx Success Rx Fail ------------------------------------------------------------------------------ Discovery 162054 2 28 0 Neighbor 23 3 12 0 Keepalive 189856 1665 187970 0 SEPPUKU 0 0 0 0 Standby Elect Req 2 0 0 0 Standby Elect Ack 0 0 2 0 Standby IOS State 0 0 4 0 Reload Req 0 0 0 0 Reload Ack 0 0 0 0 SESA Mesg 0 0 0 0 RTU Msg 0 0 0 0 Disc Timer Stop 1 0 2 0 --------------------------------------- WLC#show platform software stack-mgr chassis standby R0 sdp-counters Stack Discovery Protocol (SDP) Counters --------------------------------------- Message Tx Success Tx Fail Rx Success Rx Fail ------------------------------------------------------------------------------ Discovery 14 2 19 0 Neighbor 6 2 5 0 Keepalive 175905 0 176196 0 SEPPUKU 0 0 0 0 Standby Elect Req 0 0 1 0 Standby Elect Ack 1 0 0 0 Standby IOS State 2 0 0 0 Reload Req 0 0 0 0 Reload Ack 0 0 0 0 SESA Mesg 0 0 0 0 RTU Msg 0 0 0 0 Disc Timer Stop 1 0 0 0 --------------------------------------- WLC#show platform software stack-mgr chassis standby R0 peer-timeout Peer Chassis Peer-timeout (ms) 50% Mark 75% Mark -------------------------------------------------------------------------- 2 500 0 0 

Otros comandos

Es posible tomar una captura de paquetes en el puerto redundante del controlador con estos comandos

WLC#test wireless redundancy packetdump start Redundancy Port PacketDump Start Packet capture started on RP port. WLC#test wireless redundancy packetdump stop Redundancy Port PacketDump Stop Packet capture stopped on RP port.

Las capturas realizadas con estos comandos se guardan en el bootflash: del controlador, bajo el nombre haIntCaptureLo.pcap.

También se puede ejecutar una prueba de keepalive en el puerto redundante con este comando.

WLC#test wireless redundancy rping Redundancy Port ping PING 169.254.39.131 (169.254.39.131) 56(84) bytes of data. 64 bytes from 169.254.39.131: icmp_seq=1 ttl=64 time=0.316 ms 64 bytes from 169.254.39.131: icmp_seq=2 ttl=64 time=0.324 ms 64 bytes from 169.254.39.131: icmp_seq=3 ttl=64 time=0.407 ms --- 169.254.39.131 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2025ms rtt min/avg/max/mdev = 0.316/0.349/0.407/0.041 ms

Más detalles

Para ver la configuración de Variables ROMMON que nos muestra cómo se refleja la configuración real en las variables, puede utilizar este comando.

WLC#show romvar ROMMON variables: MCP_STARTUP_TRACEFLAGS = 00000000:00000000 SWITCH_NUMBER = 2 CONFIG_FILE = BOOTLDR = STACK_1_1 = 0_0 BOOT = bootflash:packages.conf,12; LICENSE_SUITE = CHASSIS_HA_IFNAME = GigabitEthernet3 CHASSIS_HA_IFMAC = 00:50:56:8D:2A:93 SWITCH_PRIORITY = 1 RMI_INTERFACE_NAME = Vlan39 RMI_CHASSIS_LOCAL_IP = 10.48.39.132 RMI_CHASSIS_REMOTE_IP = 10.48.39.131 CHASSIS_HA_LOCAL_IP = 169.254.39.132 CHASSIS_HA_REMOTE_IP = 169.254.39.131 CHASSIS_HA_LOCAL_MASK = 255.255.255.0 RET_2_RTS = LICENSE_BOOT_LEVEL = ,csr1000v:csr1000v; BSI = 0 RET_2_RCALTS = RANDOM_NUM = 193112462

Este comando muestra la prioridad del chasis, tanto los detalles de RMI como RP, el tiempo de espera del par junto con detalles más útiles. 

También podemos monitorear los procesos que ejecutan HA SSO en el WLC que son dos procesos, a saber, stack_mgr y rif_mgr.

Para hacer esto, recopile los seguimientos siempre activos a un archivo de texto usando el comando, el parámetro de tiempo aquí se puede ajustar para cubrir el marco de tiempo que queremos resolver. 

show logging process stack_mgr start last 30 minutes to-file bootflash:stack_mgr_logs.txt show logging process rif_mgr start last 30 minutes to-file bootflash:rif_mgr_logs.txt 

Nota: Es importante tener en cuenta que el puerto de servicio del WLC en espera está desactivado e inalcanzable mientras el controlador actúa como en espera.

Escenarios típicos

Usuario forzado

Si observa el historial de switchover, puede ver "user forced" (el usuario forzado), que aparece cuando un usuario inició un switchover entre los controladores, usando el redundancy force-switchover comando.

WLC#show redundancy switchover history Index Previous Current Switchover Switchover active active reason time ----- -------- ------- ---------- ---------- 1 1 2 user forced 11:38:23 Central Fri Mar 10 2023

Unidad activa quitada

Si observa el historial de switchover, puede ver "unidad activa eliminada" que apunta a una pérdida de comunicación en el puerto redundante entre los dos controladores.

WLC#show redundancy switchover history Index Previous Current Switchover Switchover active active reason time ----- -------- ------- ---------- ---------- 2 2 1 active unit removed 11:55:36 Central Fri Mar 10 2023

Esto puede suceder si el link entre los dos controladores deja de funcionar, pero también puede suceder si una unidad WLC cae repentinamente (falla de energía) o se bloquea. Es interesante monitorear ambos WLCs para ver si tienen informes del sistema que indican caídas/reinicios inesperados.

GW perdido activo

Si observa el historial de switchover, puede ver "GW perdido activo" que apunta a una pérdida de comunicación con el gateway en el puerto RMI.

WLC#show redundancy switchover history Index Previous Current Switchover Switchover active active reason time ----- -------- ------- ---------- ---------- 3 1 2 Active lost GW 12:00:26 Central Fri Mar 10 2023

Esto sucede si el link entre el controlador activo y su gateway se desactiva.

Otras consideraciones

HA SSO para Catalyst 9800-CL

En entornos virtuales, debe aceptar que la latencia se introduce y que la latencia no es algo que HA tolere correctamente. Esto es legítimo, ya que HA SSO tiende a detectar rápida y eficientemente cualquier falla del chasis. Para lograr esto, cada chasis verifica el estado del otro mediante señales de mantenimiento en los links RP y RMI, así como pings hacia el gateway de sus RMI (y éste, el de su WMI que debe ser el mismo). Si se omite alguno de estos, la pila reacciona en función de los síntomas, como se detalla en "System and Network Fault Handling" (Gestión de fallos del sistema y la red) de la guía HA SSO.

Cuando se trabaja con pilas de HA SSO virtuales de Catalyst 9800, es común observar switchovers debido a keepalive perdido sobre el link RP. Esto puede deberse a la latencia introducida por el entorno virtualizado.

Para determinar si la pila HA SSO sufre de caídas de keepalive RP, puede utilizar los registros del administrador de stack/rif.

! Keepalives are missed 004457: Feb 4 02:15:50.959 Paris: %STACKMGR-6-KA_MISSED: Chassis 1 R0/0: stack_mgr: Keepalive missed for 2 times for Chassis 2 ! Chassis is removed %STACKMGR-6-CHASSIS_REMOVED_KA: Chassis 1 R0/0: stack_mgr: Chassis 2 has been removed from the stack due to keepalive failure. ! RP link is down 004469: Feb 4 02:17:28.707 Paris: %RIF_MGR_FSM-6-RP_LINK_DOWN: Chassis 1 R0/0: rif_mgr: Setting RP link status to DOWN ! Dual active detection 004470: Feb 4 02:17:28.707 Paris: %STACKMGR-1-DUAL_ACTIVE_CFG_MSG: Chassis 1 R0/0: stack_mgr: Dual Active Detection links are not available anymore 

Si ambos chasis están funcionando, el switchover crea una "detección activa dual" que es una consecuencia de las caídas en el RP.

En tal situación, ajustar los parámetros de keepalive de HA para evitar estos switchovers innecesarios, puede ayudar. Se pueden configurar dos parámetros,

• Temporizador de mantenimiento activo: la cantidad de tiempo que separa el envío de 2 mensajes de keepalive entre cada chasis.
• Reintentos de Mantener Activo: el número de keepalive que debe perderse para declarar un par inactivo.

De forma predeterminada, el temporizador de mantenimiento activo se establece en 1ms y los reintentos en 5. Esto significa que después de que se pierdan 5ms de keepalive en el link RP, ocurre un switchover. Estos valores pueden ser demasiado bajos para implementaciones virtuales. Si está experimentando un switchover recurrente debido a que se pierden señales de mantenimiento RP, intente aumentar estos parámetros para estabilizar la pila.

Desde la GUI:

Para supervisar o modificar los parámetros de keepalive de HA SSO desde la GUI de 9800, navegue hasta la pestaña Redundancia desde la página Administration > Device, como se muestra en esta captura de pantalla.

Desde CLI:

WLC#chassis redundancy keep-alive retries <5-10> WLC#chassis redundancy keep-alive timer <1-10>

Junto con la configuración de estos parámetros, otra optimización puede ayudar con este comportamiento en la pila de HA SSO. En el caso de los dispositivos físicos, el hardware permite conectar un chasis a otro normalmente mediante un solo cable. En un entorno virtual, la interconexión del puerto RP para cada chasis debe realizarse mediante un switch virtual (vSwitch), que puede introducir de nuevo la latencia en comparación con las conexiones físicas. El uso de un vSwitch dedicado para crear el enlace RP es otra optimización que puede evitar la pérdida de keepalives de HA debido a la latencia. Esto también se documenta en la Guía de implementación del controlador inalámbrico Cisco Catalyst 9800-CL para la nube. Por lo tanto, lo mejor es utilizar un vSwitch dedicado para el link RP entre las VM 9800-CL y asegurarse de que ningún otro tráfico interfiera con él.

Implementaciones de Catalyst 9800 HA SSO Inside ACI

Cuando se produce un switchover en una pila HA SSO, el chasis recientemente activo utiliza el mecanismo ARP gratuito (GARP) para actualizar la asignación MAC a IP en la red y asegurarse de que recibe el tráfico dedicado al controlador. En particular, el chasis envía GARP para convertirse en el nuevo "propietario" de WMI y asegurarse de que el tráfico CAPWAP llegue al chasis adecuado.

El chasis que se activa en realidad no está enviando un solo GARP, sino una ráfaga de ellos para asegurarse de que cualquier dispositivo en la red actualice su asignación de IP a MAC. Esta ráfaga puede superar la función de aprendizaje ARP de ACI y, por lo tanto, cuando se utiliza ACI, se recomienda reducir esta ráfaga tanto como sea posible de la configuración de Catalyst 9800.

Desde CLI:

WLC# configure terminal WLC(config)# redun-management garp-retransmit burst 0 interval 0

Además de limitar la ráfaga GARP iniciada por el 9800 durante un switchover, también se recomienda inhabilitar la función fast switchover en esta plataforma. Cuando se configura el fast switchover, el controlador activo envía una notificación explícita al controlador en espera, indicando que se está apagando. Mientras se utiliza esto, el tráfico de entrelazado puede existir (AP y clientes que se descartan) entre ambos WLC que forman la pila de HA hasta que uno de ellos deja de funcionar. Por lo tanto, la desactivación de esta función ayuda a estabilizar la infraestructura inalámbrica mientras se trabaja con implementaciones de ACI.

Desde CLI:

WLC#configure terminal WLC(config)#no redun-management fast-switchover

Precaución: Tenga en cuenta que cuando se inhabilita el switchover rápido, el controlador en espera se basa únicamente en las fallas de tiempo de espera de keepalive para detectar cuando el controlador activo se desactivó. Por lo tanto, deben configurarse con sumo cuidado.

Los detalles sobre las consideraciones para las implementaciones de HA SSO para Catalyst 9800 dentro de la red ACI se pueden ver en la sección "Información sobre la implementación de la red ACI en el controlador" de la Guía de configuración del software del controlador inalámbrico Cisco Catalyst serie 9800.

Referencias

• Guía de SSO de 17,3 HA
• Guía de SSO de 17,6 HA