El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
Este documento describe cómo configurar High Availability stateful switchover (SSO) en un RP+RMI, en un Catalyst 9800 WLC.
Cisco recomienda que tenga conocimiento de
La información que contiene este documento se basa en las siguientes versiones de software y hardware.
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
Aunque la configuración de HA SSO solo puede requerir 3 de ellas, aquí se han utilizado 4 direcciones IP de la misma red que la interfaz de administración inalámbrica (WMI) para facilitar el acceso a la GUI del controlador.
La capacidad SSO de alta disponibilidad en el controlador inalámbrico permite que el punto de acceso establezca un túnel CAPWAP con el controlador inalámbrico activo y el controlador inalámbrico activo para compartir una copia simétrica del AP y la base de datos del cliente con el controlador inalámbrico en espera. Cuando se producen los switchovers (es decir, el controlador activo falla y, por lo tanto, el Standby toma la mano), los AP unidos no entran en el estado de detección y los clientes no se desconectan. Solo hay un túnel CAPWAP mantenido a la vez entre los AP y el controlador inalámbrico que está en estado Activo.
Las dos unidades forman una conexión de peer a través de un puerto RP dedicado (o una interfaz virtual para VM) y ambos controladores comparten la misma dirección IP en la interfaz de administración. La interfaz RP se utiliza para sincronizar la configuración masiva e incremental en tiempo de ejecución y garantizar el estado operativo de ambos controladores del par HA. Además, cuando se utiliza RMI + RP, tanto los controladores en espera como los activos tienen una interfaz de administración de redundancia (RMI) a la que se asignan direcciones IP, es decir, que se utiliza para garantizar la accesibilidad del gateway. El estado CAPWAP de los puntos de acceso que están en estado de ejecución también se sincroniza desde el controlador inalámbrico activo al controlador inalámbrico Hot-Standby, que permite que los puntos de acceso se conmuten completamente por estado cuando falla el controlador inalámbrico activo. Los AP no pasan al estado de detección cuando falla el controlador inalámbrico activo, y el controlador inalámbrico en espera toma el control como el controlador inalámbrico activo para servir a la red.
Nota: En naranja se resalta la dirección IP temporal asignada a la interfaz virtual GigabitEthernet 2 del controlador 9800-CL designado como WLC2. Esta dirección IP se define temporalmente como WMI para WLC2 y permite el acceso a la GUI de esta instancia para facilitar la configuración de HA SSO. Una vez configurado HA SSO, esta dirección se libera, ya que sólo se utiliza un único WMI para un par de controladores HA SSO.
En este ejemplo, el stateful switchover (SSO) de alta disponibilidad (HA) se configura entre dos instancias de 9800-CL, que ejecutan la misma versión del software Cisco IOS, que se han configurado con WMI separados y con la GUI accesible en
Además de estas direcciones IP, se han utilizado 2 direcciones adicionales en la misma subred (y VLAN), concretamente 10.48.39.131 y 10.48.39.132. Éstas son las direcciones IP de la interfaz de administración de redundancia (RMI) para el chasis 1 (WLC1) y el chasis 2 (WLC2), respectivamente.
Nota: Una vez que se ha configurado HA entre los dos controladores, 10.48.39.133 se libera y 10.48.39.130 se convierte en el único WMI de mi configuración. Por lo tanto, después de la configuración, sólo se utilizan 3 direcciones IP, la de WMI y la de las RMI.
La configuración de las interfaces para ambos dispositivos antes incluso de iniciar la configuración de HA debe ser similar a las proporcionadas en este ejemplo.
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://
/run-backup_x.cfg Address or name of remote host [
]? Destination filename [run-backup_x.cfg]? !! 19826 bytes copied in 1.585 secs (12509 bytes/sec) WLCx#copy startup-config tftp://
/start-backup_x.cfg Address or name of remote host [
]? Destination filename [start-backup_x.cfg]? !! 20482 bytes copied in 0.084 secs (243833 bytes/sec)
Reemplace el
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 ellos. 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
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: éstos son los RP IP configurados 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]
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
Lo habitual show tech wireless
no 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
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
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 la bootflash:
página 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
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.
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
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.
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.
Revisión | Fecha de publicación | Comentarios |
---|---|---|
4.0 |
25-Feb-2024 |
Se agregó una nota sobre el puerto de servicio |
3.0 |
19-Feb-2024 |
pequeña modificación sobre la configuración de la interfaz 9800-CL |
2.0 |
26-Jun-2023 |
Direccionamiento IP Gig3 fijo |
1.0 |
10-Mar-2023 |
Versión inicial |