Introduzione
Questo documento descrive i problemi relativi alla mancata corrispondenza degli stati UPF in RCM.
Prerequisiti
Requisiti
Nessun requisito specifico previsto per questo documento.
Componenti usati
Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:
- Redundancy Configuration Manager (RCM)
- Funzione User Plane (UPF/UP)
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.
Insieme Logs
RCM
Passaggio 1. Acquisisci alcuni output del comando
In primo luogo, dovete identificare quale sia il problema e quale sia il suo schema. Per determinare quali apparecchi UP sono stati sottoposti a switchover e individuare la posizione in cui si trova il problema attuale, è essenziale documentare le ragioni di tale switchover.
rcm show-statistics switchover
rcm show-statistics switchover-verbose
rcm show-statistics configmgr --------------- to check how many UPs are registered for config push
rcm show-statistics controller --------------- to check no of UPs and its states registered with controller
Passaggio 2. Raccolta registri controller e Configuration Manager
Una volta identificati i gruppi di continuità tra i quali si è verificato il problema, è possibile raccogliere i log dei controller e i log di configmgr per identificare la causa del passaggio e il problema che si è verificato perché i gruppi di continuità rimanessero bloccati nello stato In sospeso.
Fare riferimento al collegamento RCM Log Collection per la procedura di raccolta dei log.
SU
Le trap SSD, Syslog e SNMP per il timestamp problematico coprono l'intervallo temporale almeno due ore prima dell'inizio del problema.
Risoluzione dei problemi
Scenario di blocco delle UP nello stato In sospeso
- In genere, ogni UP si registra su RCM tramite il controller
- Il controller è responsabile della gestione degli stati UP ricevuti da UP e di quelli assegnati da RCM e della loro compilazione
rcm show-statistics controller
message :
{
"keepalive_version": "f1ab207c5d3120f8a4286b999b9f4cd207034e7c61e204d74e41f48578c476de",
"keepalive_timeout": "20s",
"num_groups": 2,
"groups": [
{
"groupid": 1,
"endpoints_configured": 7,
"standby_configured": 1,
"pause_switchover": false,
"active": 2,
"standby": 0,
"endpoints": [
{
"endpoint": "X.X.X.X", -------- UP IP
"bfd_status": "STATE_UP",
"upf_registered": true,
"upf_connected": true,
"upf_state_received": "UpfMsgState_Active",
"bfd_state": "BFDState_UP",
"upf_state": "UPFState_PendActive",
"route_modifier": 32,
"pool_received": false,
"echo_received": 253,
"management_ip": "X.X.X.X",
"host_id": "SEUD2413",
"ssh_ip": "Y.Y.Y.Y",
"force_nso_registration": false
},
Nelle statistiche del controller, se osservate, ci sono stati diversi che il controller sta mantenendo e ogni stato UP ha un proprio significato.
Stato BFD: indica lo stato BFD tra RCM e UP (non viene definito come stato UF, ma solo stato BFD).
Stato UPF: lo stato corrente dell'UPF in RCM
Stato UPF ricevuto - stato UP inviato da UP a RCM
- Per quanto riguarda il flusso generale, ogni volta che si passa da Active UP a Standby UP, RCM deve essere sottoposto a determinate procedure per facilitare le consegne indicate di seguito:
1. Checkpointmgr scarica da vecchio UP e checkpoint sincronizza con nuovo Active UP
2. Svuotamento configurazione
3. Push di configurazione
4. Gestione degli stati UP
Si consideri l'esempio di una coppia UP-A (Active UP) e UP-B (Standby-UP) e, quando si verifica un passaggio prima di passare allo stato Attivo e Standby, il passaggio allo stato In sospeso.
UP-A (Active UP) — PendStandby — Standby
UP-B (Standby-UP) — PendActive — Active (Attivo)
Come si può vedere prima di diventare attivo/standby, le transazioni procedurali menzionate sono in corso tra RCM e UP per avere un passaggio agevole.
- Ogni volta che si passa da Attivo a Standby e viceversa, RCM deve eseguire un push di configurazione in cui la configurazione Active UP viene inserita nella configurazione UP che diventa Active e la configurazione Standby UP nella configurazione UP che diventa Standby.
Note :: In Standby UP normally RCM push all the UP config which are currently active so that whenever this UP becomes active it removes all the unwanted config
- Non appena viene avviato lo switchover, RCM ha un valore del timer di 15 minuti (varia in base al valore configurato) e, entro questo valore, deve completare lo switchover che si conclude una volta completato il push della configurazione.
- In questo caso, per qualche motivo, se il push della configurazione non viene completato entro il tempo di scadenza del timer e RCM avvia il ricaricamento su UP. Questa operazione continua fino al completamento del push della configurazione.
- Pertanto, quando RCM imposta la configurazione su UP, si attende il segnale di configurazione completa da UP in base al quale RCM è consapevole che il push di configurazione è stato completato e lo considera un passaggio di commutazione riuscito.
Questo è il log che può essere visto dai syslog e dalle trap SNMP al termine del config push.
Syslogs
Nov 13 12:01:09 INVIGJ02GNR1D1UP12CO evlogd: [local-60sec9.041] [cli 30000 debug] [1/0/10935 <cli:1010935> cliparse.c:571] [context: local, contextID: 1] [software internal system syslog] CLI command [user rcmadmin, mode [local]INVIGJ02GNR1D1UP12CO]: rcm-config-push-complete
Nov 13 12:01:09 INVIGJ02GNR1D1UP12CO evlogd: [local-60sec9.041] [cli 30000 debug] [1/0/10935 <cli:1010935> cliparse.c:571] [context: local, contextID: 1] [software internal system syslog] CLI command [user rcmadmin, mode [local]INVIGJ02GNR1D1UP12CO]: rcm-config-push-complete end-of-config
SNMP
Fri Mar 24 09:59:01 2023 Internal trap notification 1425 (RCMTCPConnect) Context Name: rcm
Fri Mar 24 09:59:01 2023 Internal trap notification 1421 (RCMConfigPushCompleteSent) Context Name: rcm
Fri Mar 24 09:59:01 2023 Internal trap notification 1426 (RCMChassisState) RCM Chassis State: (2) Chassis State Standby
Fri Mar 24 09:59:04 2023 Internal trap notification 1276 (BFDSessionUp) vpn n6 OurAddr fc00:10:5:132::10 NeighborAddr fc00:10:5:132::254 Session(6/1090552866), Diagnostic code 0 PhyPortId 0
- Tuttavia, in caso di problemi dovuti al tempo necessario per il completamento del push della configurazione che causa la scadenza del valore del timer, si verificheranno problemi di UP bloccato nello stato Pending.
- Poiché RCM non ha ottenuto lo stato di completamento del push di configurazione, considera lo switchover non completo e mantiene attivo lo stato In sospeso.
- Le diverse ragioni per i problemi di push della configurazione sono spiegate in UP Reload Cause (Cause di ricaricamento UP).
Soluzione alternativa
1. È possibile attivare temporaneamente il segnale di completamento del push di configurazione da UP a RCM con il comando indicato di seguito per riportare l'UP nello stato Attivo/Standby:
rcm-config-push-complete end-of-config
2. La soluzione menzionata è solo temporanea per identificare il problema che richiede tempo per il push della configurazione, come descritto in Cause di ricaricamento del pacchetto UP.
Feedback