Configurar SSO de alta disponibilidade no Catalyst 9800 | Guia de início 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

Neste 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 dos controladores.

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 Administração → gerenciamento → backup e restauração da GUI 9800 (consulte a captura de tela), é possível fazer o download da 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. É possível 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://<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)

Substitua o <SERVER-IP> pelo IP do servidor TFTP no qual o arquivo de configuração de inicialização/execução é copiado.

Etapa 2. (Opcional) Garanta a conectividade da rede.

Nas GUIs ou CLIs da WLC, é possível executar testes de conectividade simples, ou seja, fazer ping no gateway de ambos os dispositivos e fazer ping nos dispositivos entre eles. 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 ms

Etapa 3. Configure 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: neste 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.

Vamos analisar os campos configurados e sua finalidade

• Configuração de redundância: deve ser habilitada para usar redundância entre WLCs.
• Tipo de emparelhamento de redundância: como este guia aborda o SSO HA 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 é escolhido apenas, a acessibilidade do gateway não é verificada, apenas o estado da WLC redundante é
• 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.
  
  

  Observação: 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, este método de redundância implementa a verificação do gateway padrão, feita pelo envio periódico do ping do Internet Control Message Protocol (ICMP) ao gateway. As controladoras ativa e standby usam o IP RMI como o IP de origem para essas verificações. Essas mensagens são enviadas em um intervalo de 1 segundo.

• Intervalo de falha do gateway: representa o tempo durante o qual uma verificação de gateway deve falhar consecutivamente antes de o gateway ser 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: esses são os IPs RP configurados para os chassis 1 e 2. Esses endereços IP são gerados automaticamente como 169.254.x.x, em que x.x é derivado dos dois últimos octetos da interface de gerenciamento.

• Temporizador de manutenção de atividade: conforme detalhado no guia de configuração de HA SSO, os chassis ativo e em espera enviam mensagens de manutenção de atividade 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: este campo configura o valor de repetição de keepalive do peer antes de declarar que o peer está inativo. 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 ativa do chassi: 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)# 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

Em 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.131

Renumerar 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)#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

Observação: 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 ao chassis redundancy ha-interface GigabitEthernet 3 comando. 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 o show romvar comando.

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 GUI 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]

Observação: 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 (Redundância) na página Monitoring > General > System (Monitoramento > Geral > Sistema), conforme mostrado 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.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

Troubleshooting

Reflexo de um único ponto de venda

O comum show tech wireless  nã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 redundancy

comandos 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, é possível 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 esses 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 na bootflash: do controlador, sob o nome haIntCaptureLo.pcap.

Também é possível 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 ms

Entre 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 = 193112462

Esse comando mostra a prioridade do chassi, detalhes de RMI e RP, intervalo de peer juntamente com detalhes mais úteis. 

Também podemos monitorar os processos que executam 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 queremos 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 

Observação: é importante observar que a porta de serviço do WLC em standby está desativada e inacessível enquanto o controlador está atuando como em standby.

Cenários típicos

Usuário Forçado

Se você observar o histórico de switchover, poderá ver "user forced", que aparece quando um usuário iniciou um switchover entre os controladores, usando o 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

Unidade Ativa Removida

Se você observar o histórico do switchover, poderá ver "unidade ativa removida", 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 2023

Isso 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 do switchover, poderá ver "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 2023

Isso 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 de acordo com os 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 das quedas 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 Keep Alive: o período de tempo que separa o envio de duas mensagens de keepalive 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 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 (Redundância) 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.

Implantações do Catalyst 9800 HA SSO Inside 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 certificar-se de 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 0

Junto 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

Cuidado: lembre-se de que quando a alternância rápida é desativada, o controlador em espera 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.

Os 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 a implantação da rede ACI no controlador" do Guia de Configuração de Software do Cisco Catalyst 9800 Series Wireless Controller.

Referências

• 17.3 Guia de HA SSO
• 17.6 Guia de HA SSO