Sommario

Introduzione

Prerequisiti

Requisiti

Componenti usati

Insieme Logs

RCM

Passaggio 1. Acquisisci alcuni output del comando

Passaggio 2. Raccolta registri controller e Configuration Manager

SU

Risoluzione dei problemi

Scenario di blocco delle UP nello stato In sospeso

Soluzione alternativa

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.