Configurazione dell'SSO High Availability sui dispositivi Catalyst 9800 | Guida introduttiva

Introduzione

In questo documento viene descritto come configurare lo status switchover (SSO) ad alta disponibilità in modalità RP+RMI su un Catalyst 9800 WLC.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza di:

• Catalyst wireless modello 9800 configuration
• Concetti di alta disponibilità illustrati nella guida HA SSO.

Componenti usati

Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:

• Catalyst 9800-CL (v. 17.12.3).

Mentre la configurazione HA SSO può richiedere solo 3 di essi, qui sono stati utilizzati 4 indirizzi IP della stessa rete dell'interfaccia di gestione wireless (WMI) per facilitare l'accesso all'interfaccia grafica del controller.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Premesse

La funzionalità SSO ad alta disponibilità sul controller wireless consente al punto di accesso di stabilire un tunnel CAPWAP con il controller wireless attivo e il controller wireless attivo di condividere una copia mirror del punto di accesso e del database client con il controller wireless in standby. Quando si verificano gli switchover (ovvero il controller attivo si guasta e quindi lo standby prende la mano), gli AP uniti non passano allo stato Discovery e i client non si disconnettono. Tra i punti di accesso e il controller wireless che si trova nello stato Attivo viene mantenuto un solo tunnel CAPWAP alla volta.

Le due unità formano una connessione peer tramite una porta RP dedicata (o un'interfaccia virtuale per le VM) ed entrambi i controller condividono lo stesso indirizzo IP sull'interfaccia di gestione. L'interfaccia RP viene utilizzata per sincronizzare la configurazione in blocco e incrementale in fase di runtime e garantire lo stato operativo di entrambi i controller della coppia HA. Inoltre, quando si utilizza RMI + RP, sia i controller in standby che i controller attivi dispongono di un'interfaccia di gestione della ridondanza (RMI) a cui sono assegnati indirizzi IP, in particolare per garantire la raggiungibilità del gateway. Anche lo stato CAPWAP dei punti di accesso in stato di esecuzione viene sincronizzato dal controller wireless attivo al controller wireless hot-standby, che consente il passaggio completo dallo stato dei punti di accesso in caso di guasto del controller wireless attivo. Gli access point non passano allo stato Discovery quando il controller wireless attivo non funziona e il controller wireless standby diventa il controller wireless attivo che serve la rete.

Configurazione

Esempio di rete

Configurazioni

Nell'esempio, lo stateful switchover (SSO) ad alta disponibilità è configurato tra due istanze 9800-CL, che eseguono la stessa versione del software Cisco IOS, configurate con WMI separati e con interfaccia utente accessibile all'indirizzo:

• l'indirizzo IP 10.48.39.130 per il primo, indicato come WLC1.
• l'indirizzo IP 10.48.39.133 per il secondo indirizzo, denominato WLC2.

Oltre a questi indirizzi IP, sono stati usati altri due indirizzi nella stessa subnet (e VLAN), ossia 10.48.39.131 e 10.48.39.132. Si tratta degli indirizzi IP RMI (Redundancy Management Interface) rispettivamente per lo chassis 1 (WLC1) e lo chassis 2 (WLC2).

La configurazione delle interfacce per entrambi i dispositivi prima ancora di avviare la configurazione HA deve essere simile a quella fornita in questo esempio.

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

Nell'esempio, il WLC1 è designato come controller primario (ossia chassis 1), mentre il WLC2 è il controller secondario (ossia chassis 2). Ciò significa che la coppia HA costituita dai 2 controller utilizza la configurazione di WLC1 e che quella di WLC2 viene persa dopo il processo.

Passaggio 1. (Facoltativo) Eseguire il backup dei file della configurazione di avvio e della configurazione di esecuzione dei controller.

Una gestione errata può causare la perdita della configurazione. Per evitare questo problema, si consiglia di eseguire il backup della configurazione di avvio e di esecuzione da entrambi i controller utilizzati nella configurazione HA. Questa operazione può essere eseguita facilmente dalla GUI o dalla CLI di 9800.

Dall'interfaccia grafica:

Dalla scheda Amministrazione > Gestione > Backup e ripristino della GUI 9800 (fare riferimento alla schermata), è possibile scaricare la configurazione di avvio e di esecuzione attualmente utilizzata dal controller.

Nell'esempio, sia l'avvio (a sinistra) che la configurazione (a destra) vengono scaricati direttamente, tramite HTTP, sul dispositivo che ospita il browser usato per accedere alla GUI del WLC. Il campo Transfer Mode (Modalità di trasferimento) consente di regolare facilmente la modalità di trasferimento e la destinazione del file di cui eseguire il backup.

Dalla 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) 
        
       
      
    

Sostituire con   l'indirizzo IP del server TFTP verso cui viene copiato il file di configurazione di avvio/esecuzione.

Passaggio 2. (Facoltativo) Verificare la connettività di rete.

Sia dalle GUI WLC che dalle CLI, è possibile eseguire semplici test di connettività, ossia eseguire il ping del gateway da entrambi i dispositivi ed eseguire il ping tra i dispositivi. Ciò garantisce che entrambi i controller dispongano della connettività necessaria per configurare HA.

Dall'interfaccia grafica:

Lo strumento Ping e Traceroute dalla scheda Risoluzione dei problemi della GUI 9800 può essere usato per verificare la connettività tra i controller stessi e tra ciascun WLC e il suo gateway di rete, come mostrato nelle seguenti figure.

Dalla 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

Passaggio 3. Configurare la ridondanza con il tipo di accoppiamento RMI + RP.

Una volta assicurata la connettività tra ciascun dispositivo, è possibile configurare la ridondanza tra i controller. Questa schermata mostra come viene eseguita la configurazione dalla scheda Redundancy (Ridondanza) della pagina Administration > Device (Amministrazione > Dispositivo) dell'interfaccia utente di 9800.

Esaminare i campi configurati e il relativo scopo.

• Configurazione ridondanza: per utilizzare la ridondanza tra WLC, è necessario abilitare questa funzionalità.

• Tipo di accoppiamento ridondanza: poiché questa guida riguarda l'SSO HA mediante la configurazione RMI, il tipo di accoppiamento configurato deve essere RMI + RP, utilizzando sia l'interfaccia di gestione della ridondanza che la porta di ridondanza. È inoltre possibile scegliere di configurare la ridondanza utilizzando solo la porta di ridondanza. Tuttavia, quando si sceglie solo RP, non viene verificata la raggiungibilità del gateway, viene controllato solo lo stato WLC ridondante.

• RMI IP per Chassis 1/2: questi campi assegnano gli indirizzi IP forniti all'interfaccia di ridondanza designata per entrambe le istanze. Nell'esempio, gli IP degli RMI per lo chassis 1 e 2 sono stati configurati rispettivamente come 10.48.39.131 e 10.48.39.132, come descritto in precedenza e mostrato nel diagramma di rete.

• Interfaccia HA: quando si utilizzano appliance virtuali, è possibile configurare in modi diversi la mappatura tra le schede di interfaccia di rete virtuali (vNIC) dell'hypervisor e le interfacce di rete della macchina virtuale. Pertanto, l'interfaccia utilizzata per la ridondanza è configurabile per Cisco Catalyst 9800-CL. In questo caso, è stato utilizzato Gigabit Ethernet 3, come consigliato dalla guida all'implementazione di 9800-CL.
  
  

  Nota: Quando si utilizzano accessori fisici C9800, l'interfaccia utilizzata in HA e RP è quella predefinita e non è configurabile. In effetti, i WLC 9800 dell'hardware dispongono di un'interfaccia di ridondanza dedicata separata da quelle della rete.

• Failover del gateway di gestione: come descritto nella guida alla configurazione di HA SSO, questo metodo di ridondanza implementa il controllo del gateway predefinito, eseguito inviando periodicamente il ping ICMP (Internet Control Message Protocol) al gateway. Sia il controller attivo che quello in standby utilizzano l'indirizzo IP RMI come indirizzo IP di origine per questi controlli. Questi messaggi vengono inviati a un secondo intervallo.

• Intervallo errori gateway: rappresenta l'intervallo di tempo per cui un controllo gateway deve avere esito negativo consecutivamente prima che il gateway venga dichiarato non raggiungibile. Per impostazione predefinita, questa impostazione è configurata come 8 secondi. Poiché le verifiche del gateway vengono inviate ogni secondo, si tratta di 8 errori consecutivi che hanno impedito di raggiungere il gateway.

• IP locale/remoto: IP RP configurato per lo chassis 1 e 2. Questi indirizzi IP vengono generati automaticamente come 169.254.x.x, dove x.x deriva dagli ultimi due ottetti dell'interfaccia di gestione.

• Timer Keep Alive: come descritto nella guida alla configurazione di HA SSO, lo chassis attivo e quello in standby inviano messaggi keep-alive per garantire che entrambi siano ancora disponibili. Il timer keep-alive indica il periodo di tempo che separa l'invio di due messaggi keepalive tra ogni chassis. Per impostazione predefinita, i messaggi keep-alive vengono inviati ogni 100 ms. Si consiglia spesso di aumentare questo valore con 9800-CL per evitare commutazioni abusive ogni volta che l'infrastruttura VM introduce piccoli ritardi (istantanee e così via...)

• Tentativi Keep Alive: questo campo configura il valore retry keepalive del peer prima che il peer dichiari inattivo. Se vengono utilizzati sia il timer keep-alive che il valore predefinito retries, un peer viene reclamato inattivo se i 5 messaggi keep-alive inviati a un intervallo di tempo di 100 ms rimangono senza risposta (ossia se il collegamento di ridondanza è inattivo per 500 ms).

• Rinumerazione chassis: il numero dello chassis che deve essere utilizzato dall'accessorio (1 o 2).

  • Sul WLC2 (10.48.39.133), lo chassis è rinumerato come 2. Per impostazione predefinita, il numero di chassis è 1. Gli indirizzi IP delle porte RP derivano da RMI. Se il numero di chassis è lo stesso su entrambi i controller, la derivazione IP della porta RP locale è la stessa e il rilevamento non riesce. Rinumerare lo chassis per evitare questo scenario denominato attivo-attivo.

• Priorità chassis attiva: la priorità utilizzata per definire quale configurazione deve essere utilizzata dalla coppia HA. L'accessorio con la priorità più alta viene replicato sull'altro. La configurazione dello chassis con la priorità più bassa viene quindi persa.

  • Su WLC1 (10.48.39.130), la priorità dello chassis attivo è stata impostata su 2. In questo modo si è certi che lo chassis venga scelto come quello attivo (e quindi che venga utilizzata la relativa configurazione) nella coppia HA creata.

Una volta effettuate queste configurazioni, utilizzare il pulsante Apply per applicare la configurazione ai controller.

Dalla CLI

In primo luogo, configurare un indirizzo IP secondario nell'interfaccia virtuale utilizzata per configurare l'RMI su entrambi i dispositivi.

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

Quindi, abilitare la ridondanza su entrambi i dispositivi.

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

La configurazione della priorità dello chassis, ad esempio WLC1, diventa il controller 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

Rinumerare lo chassis per WLC2, che diventa il controller secondario.

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 

Infine, configurare RMI su entrambi i dispositivi.

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

Passaggio 4. Ricaricare i controller.

Affinché la coppia HA si formi e la configurazione sia efficace, entrambi i controller devono essere ricaricati contemporaneamente una volta salvata la configurazione effettuata al passaggio 3.

Dalla GUI:

È possibile utilizzare la pagina Amministrazione - Ricarica di entrambe le GUI per riavviare i controller, come illustrato in questa schermata.

 

Dalla CLI:

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

Verifica

Quando entrambi i controller della coppia HA si scoprono e creano la coppia HA desiderata, un controller (quello primario) è in grado di monitorare i due chassis dalla GUI o dalla CLI.

Dalla GUI:

Per monitorare la configurazione della ridondanza dalla GUI 9800, passare alla scheda Ridondanza dalla pagina Monitoraggio > Generale > Sistema, come mostrato in questa schermata.

Dalla 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

Risoluzione dei problemi

One Stop-Shop Reflex

Il solitoshow tech wirelessnon include comandi che consentono di comprendere correttamente i failover HA di una coppia HA né il relativo stato corrente. Raccogli questo comando per avere la maggior parte dei comandi relativi alla disponibilità elevata in una singola operazione:

WLC#show tech wireless redundancy

Comandi show

Per lo stato delle porte di ridondanza, è possibile utilizzare questi comandi.

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

Questo comando mostra il numero dello chassis e lo stato della porta di ridondanza, utile come primo passo per la risoluzione dei problemi.

Per verificare i contatori keepalive sulla porta keepalive, è possibile utilizzare questi comandi.

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                   

Altri comandi

È possibile acquisire un pacchetto sulla porta di ridondanza del controller con questi comandi:

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.

Le acquisizioni effettuate utilizzando questi comandi vengono salvate nella bootflash: parte del controller, con il nome haIntCaptureLo.pcap.

Con questo comando è inoltre possibile eseguire un test keepalive sulla porta di ridondanza.

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

Ulteriori informazioni

Per visualizzare la configurazione delle variabili ROMMON, che mostra in che modo la configurazione effettiva si riflette sulle variabili, è possibile utilizzare questo 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

Questo comando mostra la priorità dello chassis, i dettagli RMI e RP, il timeout del peer e dettagli più utili. 

È inoltre possibile monitorare i processi che eseguono HA SSO sul WLC, ossia stack_mgr e rif_mgr.

A tale scopo, raccogliere le tracce Always On in un file di testo utilizzando il comando, il parametro time qui può essere regolato per coprire l'intervallo di tempo in cui si desidera risolvere il problema. 

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 

Scenari tipici

Utente forzato

Se si controlla la cronologia dello switchover, è possibile vedere che l'utente ha forzato la visualizzazione quando ha avviato uno switchover tra i controller, utilizzando ilredundancy 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 2023

Unità attiva rimossa

Se si controlla la cronologia dello switchover, è possibile vedere l'unità attiva rimossa, il che indica una perdita di comunicazione sulla porta di ridondanza tra i due controller.

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

Questo può accadere se il collegamento tra i due controller si interrompe, ma può anche verificarsi se un'unità WLC si spegne improvvisamente (interruzione dell'alimentazione) o si blocca. È interessante monitorare entrambi i WLC per vedere se hanno report di sistema che indicano arresti anomali/riavvii imprevisti.

GW perso attivo

Se si controlla la cronologia dello switchover, è possibile vedere Active lost GW che indica una perdita di comunicazione con il gateway sulla 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

Questo si verifica se il collegamento tra il controller attivo e il relativo gateway non è attivo.

Ulteriori considerazioni

HA SSO per Catalyst 9800-CL

Negli ambienti virtuali è necessario accettare l'introduzione della latenza, che non è tollerata correttamente da HA. Ciò è legittimo, in quanto HA SSO tende a rilevare in modo rapido ed efficiente qualsiasi guasto allo chassis. Per ottenere questo risultato, ogni chassis controlla lo stato dell'altro utilizzando keepalive sui collegamenti RP e RMI, nonché ping verso il gateway degli RMI (e questo, quello del loro WMI che deve essere lo stesso). In caso di mancato superamento di una di queste condizioni, lo stack reagisce in base ai sintomi, come descritto in Gestione degli errori di sistema e di rete nella guida HA SSO.

Quando si utilizzano stack HA SSO virtuali di Catalyst 9800, è comune osservare gli switchover dovuti alla mancata esecuzione di keepalive sul collegamento RP. Ciò può essere dovuto alla latenza introdotta dall'ambiente virtualizzato.

Per determinare se lo stack HA SSO soffre di perdite keepalive RP, è possibile utilizzare i registri dello stack/rif manager.

! 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 entrambi gli chassis sono in funzione, lo switchover crea un rilevamento dual active che è una conseguenza delle cadute su RP.

In una situazione di questo tipo, modificare i parametri HA keepalive per evitare questi cambi non necessari può essere di aiuto. È possibile configurare due parametri,

1. Keep Alive Timer: l'intervallo di tempo che separa l'invio di due messaggi keepalive tra ogni chassis.
2. Tentativi keep-alive: numero di tentativi keepalive che devono essere omessi per dichiarare un peer inattivo.

Per impostazione predefinita, il timer keep-alive è impostato su 1 ms e i tentativi su 5. Ciò significa che dopo 5 ms di keepalive perduti sul collegamento RP, si verifica un switchover. Questi valori possono essere troppo bassi per le distribuzioni virtuali. Se si verifica un passaggio ricorrente a causa della mancata corrispondenza dei pacchetti keepalive RP, provare ad aumentare questi parametri per stabilizzare lo stack.

Dalla GUI:

Per monitorare o modificare i parametri keepalive HA SSO dalla GUI 9800, passare alla scheda Ridondanza dalla pagina Amministrazione > Dispositivo, come mostrato in questa schermata.

Dalla CLI:

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

Insieme alla configurazione di questi parametri, un'altra ottimizzazione può essere utile per ottenere un comportamento di questo tipo nello stack HA SSO. Per gli accessori fisici, l'hardware consente di collegare uno chassis a un altro utilizzando in genere un singolo filo. In un ambiente virtuale, l'interconnessione della porta RP per ogni chassis deve essere effettuata da uno switch virtuale (vSwitch), che può ancora una volta introdurre la latenza rispetto alle connessioni fisiche. L'utilizzo di uno switch vSwitch dedicato per la creazione del collegamento RP è un'altra ottimizzazione che può impedire la perdita dei pacchetti keepalive HA a causa della latenza. Questa condizione è documentata anche nella guida all'implementazione di Cisco Catalyst 9800-CL Wireless Controller for Cloud. Pertanto, la soluzione migliore consiste nell'utilizzare uno switch vSwitch dedicato per il collegamento RP tra le VM 9800-CL e assicurarsi che non interferisca con il traffico.

Catalyst 9800 HA SSO in implementazioni ACI

Quando si verifica uno switchover in uno stack HA SSO, il nuovo chassis attivo utilizza il meccanismo GRATUITO ARP (GARP) per aggiornare il mapping da MAC a IP nella rete e assicurarsi che riceva il traffico dedicato al controller. In particolare, lo chassis invia GARP per diventare il nuovo proprietario di WMI e assicurarsi che il traffico CAPWAP raggiunga lo chassis appropriato.

Lo chassis che sta diventando attivo in realtà non sta inviando un singolo GARP, ma una loro esplosione per garantire che qualsiasi dispositivo nella rete aggiorni la sua mappatura IP a MAC. Questa frammentazione può sopraffare la funzione di apprendimento ARP di ACI e, pertanto, quando si usa ACI, si consiglia di ridurre il più possibile questa frammentazione dalla configurazione di Catalyst 9800.

Dalla CLI:

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

Oltre a limitare la frammentazione GARP iniziata dalla 9800 durante un passaggio, si consiglia di disabilitare la funzione di commutazione veloce su questa piattaforma. Quando è configurato lo switchover rapido, il controller attivo invia una notifica esplicita al controller in standby per segnalare che sta per essere disattivato. Quando si utilizza questo tipo di switch, può esistere traffico di interfoliazione (AP e client interrotti) tra entrambi i WLC che formano lo stack HA finché uno di essi non si blocca. Pertanto, la disattivazione di questa funzionalità consente di stabilizzare l'infrastruttura wireless mentre si lavora con le distribuzioni ACI.

Dalla CLI:

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

Per ulteriori informazioni sulle considerazioni relative alle implementazioni di HA SSO per Catalyst 9800 all'interno della rete ACI, vedere la sezione Informazioni sulla distribuzione di ACI Network nella sezione Controller della Guida alla configurazione del software Cisco Catalyst serie 9800 Wireless Controller.

Riferimenti

• 17.3 Guida SSO HA
• 17.6 Guida SSO HA