Configurar o SSO de alta disponibilidade no Catalyst 9800 | Guia de início rápido
Contents
Introdução
Este documento descreve como configurar o SSO (Stateful Switchover) de alta disponibilidade em um modo RP+RMI, em um Catalyst 9800 WLC.
Pré-requisitos
Requisitos
A Cisco recomenda que você tenha conhecimento de:
- Modelo de configuração Catalyst Wireless 9800
- Conceitos de alta disponibilidade conforme abordado no guia de HA SSO.
Componentes Utilizados
As informações neste documento são baseadas nestas versões de software e hardware:
- Catalyst 9800-CL (v. 17.12.3)
Embora a configuração de HA SSO possa exigir apenas 3 deles, aqui 4 endereços IP da mesma rede que a interface de gerenciamento sem fio (WMI) foram usados para facilitar o acesso à GUI do controlador.
As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Informações de Apoio
O recurso SSO de alta disponibilidade no controlador sem fio permite que o access point estabeleça um túnel CAPWAP com o controlador sem fio ativo e o controlador sem fio ativo para compartilhar uma cópia espelhada do AP e do banco de dados do cliente com o controlador sem fio em standby. Quando ocorrem switchovers (ou seja, o controlador ativo falha e, portanto, o Standby toma a mão), os APs unidos não entram no estado Discovery e os clientes não se desconectam. Há apenas um túnel CAPWAP mantido de cada vez entre os APs e o controlador sem fio que está em um estado Ativo.
As duas unidades formam uma conexão peer por meio de uma porta RP dedicada (ou uma interface virtual para VMs) e ambos os controladores compartilham o mesmo endereço IP na interface de gerenciamento. A interface RP é usada para sincronizar a configuração em massa e incremental em tempo de execução e garantir o status operacional de ambos os controladores do par HA. Além disso, quando RMI + RP é usado, os controladores em standby e ativo têm uma interface de gerenciamento de redundância (RMI) à qual são atribuídos endereços IP, ou seja, usados para garantir a acessibilidade do gateway. O estado CAPWAP dos pontos de acesso que estão no estado Run também é sincronizado do controlador sem fio ativo para o controlador sem fio Hot-Standby, que permite que os pontos de acesso sejam comutados por completo quando o controlador sem fio ativo falhar. Os APs não entram no estado Discovery quando o controlador sem fio ativo falha e o controlador sem fio em standby assume como o controlador sem fio ativo para atender à rede.
Configurar
Diagrama de Rede
Note: Em laranja, é realçado o endereço IP temporário atribuído à interface virtual GigabitEthernet 2 do controlador 9800-CL designado como WLC2. Esse endereço IP é definido temporariamente como WMI para WLC2 e permite acesso à GUI dessa instância para facilitar a configuração de HA SSO. Depois que o SSO HA é configurado, esse endereço é liberado, pois apenas uma única WMI é usada para um par de controladores SSO HA.
Configurações
Neste exemplo, o SSO (stateful switchover) de HA (alta disponibilidade) é configurado entre duas instâncias do 9800-CL, que executam a mesma versão do software Cisco IOS, que foi configurada com WMIs separadas e com GUI acessível em:
- O endereço IP 10.48.39.130 para o primeiro, conhecido como WLC1.
- O endereço IP 10.48.39.133 para o segundo, conhecido como WLC2.
Além desses endereços IP, 2 endereços adicionais na mesma sub-rede (e VLAN) foram usados, ou seja, 10.48.39.131 e 10.48.39.132. Esses são os endereços IP da interface de gerenciamento de redundância (RMI) para o chassi 1 (WLC1) e o chassi 2 (WLC2), respectivamente.
Note: Quando o HA estiver configurado entre as duas controladoras, 10.48.39.133 será liberado e 10.48.39.130 se tornará a única WMI da minha configuração. Portanto, após a configuração, apenas 3 endereços IP estão em uso, o da WMI e o dos RMIs.
A configuração das interfaces para ambos os dispositivos antes mesmo de iniciarem a configuração de HA deve ser semelhante àquelas fornecidas neste exemplo.
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 Vlan39WLC2#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 Vlan39Neste exemplo, a WLC1 é designada como a controladora primária (ou seja, o chassi 1), enquanto a WLC2 é a secundária (ou seja, o chassi 2). Isso significa que o par HA feito dos 2 controladores usa a configuração da WLC1 e que o da WLC2 é perdido após o processo.
Etapa 1. (Opcional) Fazer backup dos arquivos Startup Config e Running Config das controladoras.
Um manuseio incorreto pode ocorrer e resultar em perda de configuração. Para evitar isso, é altamente recomendável fazer backup da configuração de inicialização e de execução de ambos os controladores usados na configuração de HA. Isso pode ser feito facilmente usando a GUI ou a CLI do 9800.
Na GUI:
Na guia Administration > Management > Backup & Restore da GUI 9800 (consulte a captura de tela), você pode baixar a configuração de inicialização e execução usada atualmente pelo controlador.
Neste exemplo, a inicialização (lado esquerdo) e a configuração (lado direito) são baixadas diretamente, através do HTTP, no dispositivo que hospeda o navegador usado para acessar a GUI do WLC. Você pode ajustar facilmente o modo de transferência e o destino do arquivo do qual será feito o backup, com o campo Transfer Mode (Modo de transferência).
Na 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)
Substitua o
pelo IP do servidor TFTP no qual o arquivo de configuração de inicialização/execução é copiado.
Etapa 2. (Opcional) Assegurar a conectividade da rede.
Nas GUIs ou CLIs da WLC, você pode executar testes de conectividade simples, ou seja, fazer ping no gateway de ambos os dispositivos e fazer ping nos dispositivos entre eles mesmos. Isso garante que ambos os controladores tenham a conectividade necessária para configurar o HA.
Na GUI:
A ferramenta Ping e Traceroute da guia Troubleshooting da GUI 9800 pode ser usada para testar a conectividade entre os próprios controladores e entre cada WLC e seu gateway de rede, como mostrado nessas figuras.
Na 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 msEtapa 3. Configurar a redundância com o tipo de emparelhamento RMI + RP.
Com a conectividade entre cada dispositivo garantida, a redundância pode ser configurada entre os controladores. Esta captura de tela mostra como a configuração é feita na guia Redundancy da página Administration > Device da GUI 9800.
aviso: Para este exemplo, a WLC1 foi designada como controladora primária, o que significa que é aquela cuja configuração é replicada para a outra controladora. Certifique-se de aplicar a prioridade/renumeração de chassi apropriada para usar a configuração apropriada com seu par HA e não perder nenhuma parte dele.
Revise os campos configurados e sua finalidade.
- Configuração de redundância: isso deve ser habilitado para usar a redundância entre WLCs.
- Tipo de emparelhamento de redundância: como este guia aborda o HA SSO usando a configuração RMI, o tipo de emparelhamento configurado deve ser RMI + RP, usando a interface de gerenciamento de redundância e a porta de redundância. Também é possível optar por configurar a redundância usando somente a porta de redundância. No entanto, quando RP apenas é escolhido, a acessibilidade do gateway não é verificada, apenas o estado da WLC redundante é verificado.
- IP RMI para o chassi 1/2: esses campos atribuem os endereços IP fornecidos à interface de redundância designada para ambas as instâncias. Neste exemplo, ambos os IPs RMI para os chassis 1 e 2 foram configurados como sendo respectivamente 10.48.39.131 e 10.48.39.132, como descrito antes e mostrado no diagrama de rede.
- Interface HA: ao usar dispositivos virtuais, o mapeamento entre as placas de interface de rede virtual (vNIC) do hipervisor e as interfaces de rede da máquina virtual pode ser configurado de diferentes maneiras. Portanto, a interface usada para redundância é configurável para Cisco Catalyst 9800-CLs. Aqui, o GigabitEthernet 3 foi usado, conforme recomendado pelo guia de implantação do 9800-CL.
Note: Ao usar dispositivos C9800 físicos, as interfaces usadas em HA e RP são as padrão e não são configuráveis. De fato, as WLCs 9800 de hardware têm uma interface de redundância dedicada que é separada das WLCs de rede.
-
Failover do gateway de gerenciamento: conforme detalhado no guia de configuração de HA SSO, esse método de redundância implementa a verificação de gateway padrão, feita pelo envio periódico do ping do Internet Control Message Protocol (ICMP) ao gateway. Os controladores ativo e standby usam o IP RMI como o IP de origem para essas verificações. Essas mensagens são enviadas no intervalo de 1 segundo.
-
Intervalo de falha do gateway: representa o tempo durante o qual uma verificação de gateway deve falhar consecutivamente antes que o gateway seja declarado como não alcançável. Por padrão, ele é configurado como 8 segundos. Como as verificações de gateway são enviadas a cada segundo, isso representa 8 falhas consecutivas para acessar o gateway.
-
IP local/remoto: esse é o IP do RP configurado para os chassis 1 e 2. Esses endereços IP são gerados automaticamente como 169.254.x.x, onde x.x é derivado dos dois últimos octetos da interface de gerenciamento.
-
Temporizador Keep Alive: conforme detalhado no guia de configuração de HA SSO, os chassis ativo e standby enviam mensagens de keep-alive entre si para garantir que ambos ainda estejam disponíveis. O temporizador de manutenção de atividade é a quantidade de tempo que separa o envio de 2 mensagens de manutenção de atividade entre cada chassi. Por padrão, as mensagens de keep-alive são enviadas a cada 100 ms. Geralmente, recomenda-se aumentar esse valor com a 9800-CL para evitar switchovers abusivos sempre que a infraestrutura de VM introduz pequenos atrasos (instantâneos, etc.)
-
Tentativas de Keep Alive: esse campo configura o valor de repetição de keepalive do peer antes de afirmar que o peer está inoperante. Se o temporizador de keep-alive e o valor padrão repetido forem usados, um peer será reivindicado como inativo se as 5 mensagens de keep alive enviadas no intervalo de tempo de 100 ms forem deixadas sem resposta (ou seja, se o link de redundância estiver inativo por 500 ms).
-
Renumeração do chassi: o número do chassi que o dispositivo deve usar (1 ou 2).
-
Na WLC2 (10.48.39.133), o chassi é renumerado para 2. Por padrão, o número do chassi é 1. Os endereços IP das portas RP são derivados da RMI. Se o número do chassi for o mesmo em ambos os controladores, a derivação IP da porta RP local será a mesma e a detecção falhará. Renumerar o chassi para evitar esse cenário chamado Ativo-Ativo.
-
-
Prioridade do chassi ativo: a prioridade usada para definir qual configuração deve ser usada pelo par HA. O dispositivo com a prioridade mais alta é aquele que é replicado para o outro. A configuração do chassi com a prioridade mais baixa é, portanto, perdida.
-
Na WLC1 (10.48.39.130), a prioridade do chassi ativo foi definida como 2. Isso serve para garantir que esse chassi seja escolhido como o ativo (e, portanto, que sua configuração seja usada) no par HA criado.
-
Depois que essas configurações forem feitas, use o botão Apply para aplicar a configuração às controladoras.
Na CLI
Primeiro, configure um endereço IP secundário na interface virtual usada para configurar o RMI em ambos os 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)# endWLC2#configure terminal
WLC2(config)#interface vlan 39
WLC2(config-if)# ip address 10.48.39.132 255.255.255.0 secondary
WLC2(config-if)# endEm seguida, habilite a redundância em ambos os 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
Configurar a prioridade do chassi, como WLC1, torna-se o controlador principal.
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.131Renumerar o chassi para WLC2, que se torna o controlador secundário.
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
Por fim, configure o RMI em ambos os 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)#endWLC2#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)#endNote: Quanto à configuração da GUI, no Catalyst 9800 virtual, a interface usada pelo controlador deve ser selecionada entre as disponíveis. Como recomendado, GigabitEthernet 3 é usado aqui e configurado graças aochassis redundancy ha-interface GigabitEthernet 3comando. Esse comando não faz parte da configuração de execução, no entanto, a interface usada pelo HA pode ser vista nas variáveis de ambiente da instância do ROMMON. Eles podem ser vistos com oshow romvarcomando.
Etapa 4. Recarregue os controladores.
Para que o par HA seja formado e a configuração seja efetiva, ambos os controladores devem ser recarregados ao mesmo tempo, uma vez que a configuração feita na etapa 3 tenha sido salva.
Da GUI:
Pode-se usar a página Recarregar administração de ambas as GUIs para reiniciar os controladores, como descrito nesta captura de tela.
Do CLI:
WLCx#reload
Reload command is being issued on Active unit, this will reload the whole stack
Proceed with reload? [confirm]Note: Se estiver usando um servidor AAA, você precisará adicionar o endereço IP WMI e o endereço IP RMI como clientes AAA em seu servidor AAA. A WLC em standby sempre usa seu IP RMI para autenticar sessões SSH. A WLC ativa usa RMI e WMI para acessar o servidor AAA.
Verificar
Quando os dois controladores do par HA se descobrem e criam o par HA desejado, um controlador (o principal) é capaz de monitorar os dois chassis a partir da GUI ou CLI.
Da GUI:
Para monitorar a configuração de redundância da GUI 9800, navegue até a guia Redundancy na página Monitoring > General > System, conforme ilustrado nesta captura de tela.
Do 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.132WLC#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 = 0x102Troubleshooting
Reflexo de um único ponto de venda
O normalshow tech wirelessnão inclui comandos que permitam compreender os failovers de HA de um par de HA nem seu status atual corretamente. Colete este comando para ter a maioria dos comandos relacionados ao HA em uma única operação:
WLC#show tech wireless redundancycomandos show
Para o status das portas de redundância, esses comandos podem ser usados.
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
Esse comando mostra o número do chassi e o Status da Porta de Redundância, útil como solução de problemas na primeira etapa.
Para verificar os contadores keepalive na porta keepalive, você pode usar esses 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 Outros comandos
É possível fazer uma captura de pacote na porta de redundância do controlador com estes 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.As capturas feitas usando esses comandos são salvas no bootflash: diretório do controlador, sob o nome haIntCaptureLo.pcap.
Você também pode executar um teste de keepalive na porta de redundância com esse 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 msEntre em mais detalhes
Para visualizar a configuração das variáveis ROMMON, que nos mostra como a configuração real está sendo refletida nas variáveis, você pode usar 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 = 193112462Esse comando mostra a prioridade do chassi, detalhes de RMI e RP, intervalo de peer juntamente com detalhes mais úteis.
Você também pode monitorar os processos que executam o HA SSO no WLC, que são dois processos, ou seja, stack_mgr e rif_mgr.
Para fazer isso, colete os rastreamentos sempre ativos em um arquivo de texto usando o comando, o parâmetro de tempo aqui pode ser ajustado para cobrir o intervalo de tempo que você deseja solucionar problemas.
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 Note: É importante observar que a porta de serviço do WLC de standby está desativada e inacessível enquanto o controlador está atuando como standby.
Cenários típicos
Usuário Forçado
Se você observar o histórico de switchover, poderá ver o usuário forçado, que aparece quando um usuário iniciou um switchover entre os controladores, usando oredundancy force-switchovercomando.
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 2023Unidade Ativa Removida
Se você observar o histórico do switchover, poderá ver a unidade ativa removida, o que aponta para uma perda de comunicação na porta de redundância entre os dois 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 2023Isso pode acontecer se o link entre os dois controladores cair, mas também pode acontecer se uma unidade WLC cair repentinamente (falha de energia) ou travar. É interessante monitorar as duas WLCs para ver se elas têm relatórios de sistema que indicam travamentos/reinicializações inesperados.
Ativo GW perdido
Se você observar o histórico de switchover, poderá ver o GW perdido ativo, que aponta para uma perda de comunicação com o gateway na porta 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 2023Isso acontece se o link entre o controlador ativo e seu gateway for desativado.
Outras considerações
HA SSO para Catalyst 9800-CL
Em ambientes virtuais, você precisa aceitar que a latência é introduzida, e a latência não é algo que o HA tolera corretamente. Isso é legítimo, já que o SSO HA tende a detectar rápida e eficientemente qualquer falha no chassi. Para conseguir isso, cada chassi verifica o status do outro usando keepalives em links RP e RMI, bem como pings em direção ao gateway de seus RMIs (e este, o de seus WMI que deve ser o mesmo). Se algum desses for perdido, a pilha reage dependendo dos sintomas conforme detalhado no System and Network Fault Handling do guia HA SSO.
Ao trabalhar com pilhas HA SSO virtuais do Catalyst 9800, é comum observar switchovers devido a keepalive perdido no link RP. Isso pode ocorrer devido à latência introduzida pelo ambiente virtualizado.
Para determinar se a pilha de HA SSO sofre de quedas de keepalive RP, você pode usar os logs do gerenciador 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 Se ambos os chassis estiverem operando, o switchover cria uma detecção ativa dupla que é uma consequência dos descartes no RP.
Em tal situação, ajustar os parâmetros de manutenção de atividade de HA para evitar esses switchovers desnecessários pode ajudar. Dois parâmetros podem ser configurados,
- Temporizador de manutenção de atividade: a quantidade de tempo que separa o envio de duas mensagens de manutenção de atividade entre cada chassi.
- Tentativas de Keep Alive: o número de keepalive que precisa ser perdido para declarar um peer inativo.
Por padrão, o temporizador keep alive é definido como 1ms e as novas tentativas como 5. Isso significa que após 5 ms de keepalive serem perdidos no link RP, ocorre um switchover. Esses valores podem ser muito baixos para implantações virtuais. Se você estiver passando por um switchover recorrente devido à perda de keepalives de RP, tente aumentar esses parâmetros para estabilizar a pilha.
Da GUI:
Para monitorar ou modificar os parâmetros de manutenção de atividade de SSO de HA da GUI 9800, navegue até a guia Redundancy na página Administration > Device, conforme descrito nesta captura de tela.
Do CLI:
WLC#chassis redundancy keep-alive retries <5-10>
WLC#chassis redundancy keep-alive timer <1-10>Junto com a configuração desses parâmetros, outra otimização pode ajudar com tal comportamento na pilha de HA SSO. Para dispositivos físicos, o hardware permite conectar um chassi a outro, normalmente usando um único fio. Em um ambiente virtual, a interconexão da porta RP para cada chassi deve ser feita por um switch virtual (vSwitch), que pode mais uma vez introduzir latência em comparação com conexões físicas. Usar um vSwitch dedicado para criar o link RP é outra otimização que pode evitar a perda de manutenções de atividades de HA devido à latência. Isso também está documentado no Guia de implantação de nuvem do Cisco Catalyst 9800-CL Wireless Controller. Portanto, o melhor é usar um link vSwitch dedicado para RP entre as VMs 9800-CL e garantir que nenhum outro tráfego interfira nele.
Catalyst 9800 HA SSO dentro das implantações da ACI
Quando um switchover ocorre em uma pilha de HA SSO, o chassi recém-ativo usa o mecanismo ARP gratuito (GARP) para atualizar o mapeamento MAC para IP na rede e certificar-se de que ele receba o tráfego dedicado ao controlador. Em particular, o chassi envia GARP para se tornar o novo proprietário do WMI e garante que o tráfego CAPWAP alcance o chassi apropriado.
O chassi que está se tornando ativo na verdade não está enviando um único GARP, mas um burst deles para garantir que qualquer dispositivo na rede atualize seu IP para o mapeamento MAC. Essa rajada pode sobrecarregar o recurso de aprendizagem ARP da ACI e, assim, quando a ACI é usada, é recomendável reduzir essa rajada o máximo possível na configuração do Catalyst 9800.
Do CLI:
WLC# configure terminal
WLC(config)# redun-management garp-retransmit burst 0 interval 0Junto com a limitação do burst GARP iniciado pelo 9800 durante um switchover, também é recomendável desativar o recurso fast switchover nesta plataforma. Quando o fast switchover é configurado, o controlador ativo envia uma notificação explícita ao controlador em standby, informando que ele está sendo desativado. Ao usar isso, o tráfego de intercalação pode existir (APs e clientes sendo descartados) entre as duas WLCs que formam a pilha de HA até que uma delas fique inativa. Assim, desativar esse recurso ajuda a estabilizar sua infraestrutura sem fio enquanto trabalha com implantações da ACI.
Do CLI:
WLC#configure terminal
WLC(config)#no redun-management fast-switchover
Caution: Lembre-se de que quando a comutação rápida é desativada, o controlador em standby depende exclusivamente das falhas de tempo limite de keepalive para detectar quando o controlador ativo foi desativado. Estes devem, portanto, ser configurados com o maior cuidado.
Detalhes sobre as considerações para implantações de HA SSO para o Catalyst 9800 dentro da rede ACI podem ser vistos na seção Informações sobre implantação da rede ACI no controlador do Guia de configuração de software do Cisco Catalyst 9800 Series Wireless Controller.
Referências
Histórico de revisões
| Revisão | Data de publicação | Comentários |
|---|---|---|
7.0 |
13-Dec-2024 |
Texto Alt, Destinos de Link e Formatação Atualizados. |
6.0 |
16-Jul-2024 |
versões atualizadas e adicionou uma observação sobre a interface RMI para AAA |
5.0 |
06-Jun-2024 |
Adicionada uma seção "considerações adicionais" |
4.0 |
25-Feb-2024 |
Adicionada uma observação sobre a porta de serviço |
3.0 |
19-Feb-2024 |
pequena modificação na configuração da interface 9800-CL |
2.0 |
26-Jun-2023 |
Endereçamento IP Gig3 fixo |
1.0 |
10-Mar-2023 |
Versão inicial |
FeedbackContate a Cisco
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)