Guida rapida alla configurazione di HA SSO su Catalyst 9800
Sommario
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à come descritti nella guida all'SSO di alta disponibilità (HA, High Availability).
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
Nota: In arancione è evidenziato l'indirizzo IP temporaneo assegnato all'interfaccia virtuale Gigabit Ethernet 2 del controller 9800-CL designato come WLC2. Questo indirizzo IP è temporaneamente definito come WMI per WLC2 e consente l'accesso alla GUI dell'istanza per semplificare la configurazione HA SSO. Una volta configurato HA SSO, questo indirizzo viene liberato poiché per una coppia di controller HA SSO viene utilizzato un solo WMI.
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 utilizzati altri due indirizzi nella stessa subnet (e VLAN), ossia 10.48.39.131 e 10.48.39.132. Si tratta degli indirizzi IP dell'interfaccia di gestione della ridondanza (RMI) rispettivamente per lo chassis 1 (WLC1) e lo chassis 2 (WLC2).
Nota: Una volta configurato HA tra i due controller, viene liberata la versione 10.48.39.133 e 10.48.39.130 diventa l'unico WMI della configurazione. Pertanto, dopo la configurazione, sono in uso solo 3 indirizzi IP, uno dei due WMI e uno degli RMI.
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 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 Vlan39Nell'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://<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)Sostituire con
Passaggio 2. (Facoltativo) Verificare la connettività di rete.
Dalle GUI o dalle CLI del WLC, è 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 msPassaggio 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.
Avviso: Nell'esempio, il WLC1 è stato designato come controller primario, ossia quello la cui configurazione è stata replicata sull'altro controller. Accertarsi di applicare la corretta priorità/rinumerazione dello chassis per utilizzare la configurazione corretta con la coppia HA e di non perdere alcuna parte di essa.
Esaminare i campi configurati e il relativo scopo:
-
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)# 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)# endQuindi, 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.131Rinumerare 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)#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)#endNota: Per quanto riguarda la configurazione GUI, su Virtual Catalyst 9800, è necessario selezionare l'interfaccia utilizzata dal controller tra quelle disponibili. Come consigliato, Gigabit Ethernet 3 viene utilizzato qui e configurato tramite il comando chassis redundancy ha-interface GigabitEthernet 3. Questo comando non fa parte della configurazione in esecuzione, tuttavia l'interfaccia utilizzata da HA può essere visualizzata nelle variabili di ambiente ROMMON di istanza. Per visualizzarle, usare il show romvarcomando.
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]Nota: Se si utilizza un server AAA, è necessario aggiungere sia l'indirizzo IP WMI che l'indirizzo IP RMI come client AAA sul server AAA. Il WLC in standby usa sempre il proprio IP RMI per autenticare le sessioni SSH. Il WLC attivo utilizza sia RMI che WMI per raggiungere il server AAA.
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.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 = 0x102Risoluzione dei problemi
One Stop-Shop Reflex
Il solito show tech wireless non include comandi che consentono di comprendere correttamente i failover HA di una coppia HA né il relativo stato corrente. Raccogliere questo comando per avere la maggior parte dei comandi relativi alla disponibilità elevata in una singola operazione:
WLC#show tech wireless redundancyComandi 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 nel bootflash: nome 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 msUlteriori 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 = 193112462Questo 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 Nota: È importante notare che la porta di servizio del WLC di standby è disattivata e non raggiungibile mentre il controller funziona in modalità standby.
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 il comando redundancy force-switchover.
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 2023Unità 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 2023Questo 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 2023Questo si verifica se il collegamento tra il controller attivo e il relativo gateway non è attivo.
Ulteriori considerazioni
Abilitazione dell'accesso da console per Standby 9800
Accedere alla CLI del WLC attivo ed eseguire questo comando per abilitare l'accesso alla console allo switch 9800 in standby. In caso contrario, l'accesso alla console è bloccato sul WLC di standby:
WLC#conf t
Enter configuration commands, one per line. End with CNTL/Z.
WLC(config)#redundancy
WLC(config-red)#main-cpu
WLC(config-r-mc)#standby console enable
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,
- Keep Alive Timer: l'intervallo di tempo che separa l'invio di due messaggi keepalive tra ogni chassis.
- 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 0Oltre 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
Attenzione: Tenere presente che quando l'opzione di commutazione veloce è disabilitata, il controller in standby si basa esclusivamente sugli errori di timeout keepalive per rilevare quando il controller attivo si è spento. Per questo motivo è necessario procedere con la massima cura alla configurazione.
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
Cronologia delle revisioni
| Revisione | Data di pubblicazione | Commenti |
|---|---|---|
9.0 |
12-May-2026
|
Intestazioni fisse, grammatica, iniziali maiuscole e minuscole, titolo fisso |
8.0 |
27-Dec-2024
|
Aggiunta di una nota sull'accesso alla console WLC in standby |
7.0 |
13-Dec-2024
|
Testo alternativo, destinazioni collegamento e formattazione aggiornati. |
6.0 |
16-Jul-2024
|
versioni aggiornate e aggiunta di una nota sull'interfaccia RMI per AAA |
5.0 |
06-Jun-2024
|
È stata aggiunta una sezione "ulteriori considerazioni" |
4.0 |
25-Feb-2024
|
Aggiunta di una nota sulla porta del servizio |
3.0 |
19-Feb-2024
|
piccola modifica alla configurazione dell'interfaccia 9800-CL |
2.0 |
26-Jun-2023
|
Indirizzamento IP Gig3 fisso |
1.0 |
10-Mar-2023
|
Versione iniziale |
Feedback