Configurazione di High Availability SSO su Catalyst 9800 | Guida introduttiva
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 dei
- Catalyst wireless modello 9800.
- 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:
- C9800-CL v17.9.2
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.
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.
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 viene 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 di questa istanza per semplificare la configurazione di 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, l'SSO (Stateful Switchover) 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 in
- 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).
Nota: dopo aver configurato HA tra i due controller, 10.48.39.133 viene liberato 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 & Restore della GUI 9800 (fare riferimento allo screenshot), è 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. È possibile regolare facilmente la modalità di trasferimento e la destinazione del file di cui eseguire il backup, utilizzando il campo Transfer Mode (Modalità di trasferimento).
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à, ovvero eseguire il ping del gateway da entrambi i dispositivi ed eseguire il ping dei dispositivi tra di loro. 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. In questa schermata viene mostrato come eseguire la configurazione dalla scheda Redundancy (Ridondanza) della pagina Administration→ Device (Amministrazione) della GUI del 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
- Configurazione della ridondanza: deve essere abilitata per utilizzare la ridondanza tra WLC.
- Tipo di accoppiamento ridondanza: poiché questa guida riguarda l'SSO HA utilizzando 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, la raggiungibilità del gateway non viene verificata, 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, la mappatura tra le schede di interfaccia di rete virtuali (vNIC) dell'hypervisor e le interfacce di rete della macchina virtuale può essere configurata in modi diversi. 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 di intervallo.
-
Intervallo errori gateway: indica per quanto tempo un controllo gateway deve avere esito negativo consecutivo 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: si tratta dell'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 HA SSO, gli chassis attivo e 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 di ripetizione keepalive del peer prima che asserisca che il peer è 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 di chassis che l'accessorio deve utilizzare (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 la configurazione che 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, lo chassis viene scelto come chassis attivo (e quindi viene utilizzata la relativa configurazione) nella coppia HA creata.
-
Una volta effettuate queste configurazioni, utilizzare il pulsante Apply (Applica) 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
Configurare la priorità dello chassis, ad esempio WLC1, che 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.131Rinumera 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: come per la configurazione GUI, su Virtual Catalyst 9800, l'interfaccia usata dal controller deve essere selezionata tra quelle disponibili. Come consigliato, Gigabit Ethernet 3 viene utilizzato qui e configurato tramite il chassis redundancy ha-interface GigabitEthernet 3 comando. 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 visualizzarli, usare il show romvar comando.
Passaggio 4. Riavviare 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 di 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. Raccogli 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 usare 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 è possibile anche 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.
Possiamo anche monitorare i processi che eseguono HA SSO sul WLC che sono due processi, 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 modificato per coprire l'intervallo di tempo che si desidera risolvere.
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 in standby è disattivata e non raggiungibile mentre il controller funziona in standby.
Scenari tipici
Utente forzato
Se si controlla la cronologia dello switchover, è possibile vedere "user forced" (forzato dall'utente), che appare quando un utente ha avviato uno switchover tra i controller, utilizzando il 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 2023Unità attiva rimossa
Se si controlla la cronologia dello switchover, è possibile vedere "l'unità attiva rimossa" 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, si può 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.
Riferimenti
Cronologia delle revisioni
| Revisione | Data di pubblicazione | Commenti |
|---|---|---|
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