Realizar el mantenimiento del hardware en los nodos 5G IMS y UPF de datos

Introducción

Este documento describe el procedimiento para realizar actividades de mantenimiento en los nodos IP Multimedia Subsystem (IMS) y Data User Plane Function (UPF).

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• 5G-UPF
• Administrador de configuración de redundancia (RCM)
• Núcleo de paquete virtual (VPC): instancia única (SI)
• Hipervisor de máquina virtual (KVM) basado en el núcleo

Componentes Utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

• Subscriber Microservices Infrastructure SMI) 2020.02.2.35
• Star OS 21.22

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Antecedentes

¿Qué es UPF?

La interfaz de plano de usuario (UPF) es una de las funciones de red (NF) de la red de núcleo 5G (5GC). Es responsable del routing y reenvío de paquetes, la inspección de paquetes, la gestión de QoS y las sesiones PDU externas para interconectar redes de datos (DN) en la arquitectura 5G.

¿Qué es VPC-SI?

VPC-SI consolida las operaciones del chasis físico Cisco ASR 5500, que ejecuta StarOS en una única máquina virtual (VM) capaz de ejecutarse en servidores comerciales disponibles (COTS). Cada VM VPC-SI funciona como una instancia independiente de StarOS e incorpora las capacidades de gestión y de proceso de sesión de un chasis físico.

¿Qué es el hipervisor KVM?

La máquina virtual basada en el núcleo (KVM) es una tecnología de virtualización de código abierto integrada en Linux. Específicamente, KVM le permite convertir Linux en un hipervisor que permite a una máquina host ejecutar varios entornos virtuales aislados llamados invitados o máquinas virtuales (VM).

¿Qué es ICSR?

La función Interchassis Session Recovery (ICSR) es una función de Cisco con licencia que requiere una licencia independiente. Esta función proporciona la mayor disponibilidad posible para el proceso de llamadas continuo sin interrupciones en los servicios de los suscriptores. ICSR permite al operador configurar gateways con fines de redundancia. En caso de que se produzca un error en el gateway, el ICSR permite que las sesiones se enruten de forma transparente alrededor del error, lo que mantiene la experiencia del usuario. ICSR también conserva la información y el estado de la sesión.

Problema

El mantenimiento del hardware, como la falla de hardware o la actualización de software/firmware, y mucho más, necesita tiempo de inactividad en los servidores. Este procedimiento debe seguirse para que el mantenimiento se realice en los servidores de estructura básica de UPF y para que el switch de los servicios se realice correctamente a fin de evitar tiempos de inactividad no deseados en la aplicación UPF. 

Procedimiento de mantenimiento

Los nodos UPF son VM StarOS alojadas en hipervisor KVM. Un hipervisor KVM aloja 2 instancias de VM. IMS UPF tiene redundancia 1:1, cada instancia activa tiene una instancia en espera. utiliza ICSR junto con el protocolo de redundancia de sesión (SRP) para gestionar la redundancia. SRP se utiliza para intercambiar mensajes hello entre el chasis ICSR. También intercambia la información de estado de la sesión entre el chasis activo/en espera (datos del punto de control). La información completa de la sesión del suscriptor se envía desde el chasis ACTIVE al chasis STANDBY en forma de registro de recuperación de llamada (CRR), a través del enlace SRP.

Inicie sesión en el nodo KVM y enumere las instancias de VM con el comando KVM virsh.

cloud-user@podname-upf-ims-kvmnode-1:~$ sudo virsh list --all
Id Name State
----------------------------------------------------
1 imsupf01 running
4 imsupf10 running

cloud-user@podname-upf-ims-kvmnode-1:~$

Inicie sesión en la instancia de UPF y verifique el estado del chasis.

[local]imsupf10# show srp info
Friday July 22 15:50:24 UTC 2022
Service Redundancy Protocol:
-------------------------------------------------------------------------------
Context: srp 
Local Address: 10.x.x.74
Chassis State: Standby 
Chassis Mode: Backup 
Chassis Priority: 2 
Local Tiebreaker: 02-7E-35-53-F9-F1
Route-Modifier: 9 

Peer Remote Address: 10.x.x.73
Peer State: Active 
Peer Mode: Primary 
Peer Priority: 1 
Peer Tiebreaker: 02-11-59-73-87-35
Peer Route-Modifier: 8 
Last Hello Message received: Fri Jul 22 15:50:21 2022 (3 seconds ago)
Peer Configuration Validation: Complete 
Last Peer Configuration Error: None 
Last Peer Configuration Event: Fri Jul 22 15:50:22 2022 (2 seconds ago)
Last Validate Switchover Status: None 
Connection State: Connected 

[local]imsupf01# show srp info
Friday July 22 15:31:20 UTC 2022
Service Redundancy Protocol:
-------------------------------------------------------------------------------
Context: srp 
Local Address: 10.x.x.66
Chassis State: Active 
Chassis Mode: Backup 
Chassis Priority: 2 
Local Tiebreaker: 02-7C-1A-62-FA-3C
Route-Modifier: 5 

Peer Remote Address: 10.x.x.65
Peer State: Standby 
Peer Mode: Primary 
Peer Priority: 1 
Peer Tiebreaker: 02-87-33-98-6D-08
Peer Route-Modifier: 6 
Last Hello Message received: Fri Jul 22 15:31:20 2022 (1 seconds ago)
Peer Configuration Validation: Complete 
Last Peer Configuration Error: None 
Last Peer Configuration Event: Fri Jul 22 15:20:13 2022 (668 seconds ago)
Last Validate Switchover Status: None 
Connection State: Connected 

Verifique si el número de líneas es el mismo en el par ICSR activo-en espera para IMS UPF.

Active node 
# show configuration | grep -n -E "^end$" 
Thursday July 21 07:30:17 UTC 2022
14960:end

Standby Node
# show configuration | grep -n -E "^end$" 
Thursday July 21 07:31:02 UTC 2022
14959:end

Verifique si el sessmgr SRP se encuentra en estado conectado-activo antes del switchover SRP en UPF activo y asegúrese de que no haya estado activo-pendiente.

[local]imsupf01# show srp checkpoint statistics active 
Thursday July 21 07:38:04 UTC 2022
Number of Sessmgrs: 20
Sessmgrs in Active-Connected state: 20
Sessmgrs in Standby-Connected state: 0
Sessmgrs in Pending-Active state: 0

Verifique si el sessmgr SRP se encuentra en estado conectado-activo antes del switchover SRP en UPF en espera y asegúrese de que no haya estado activo-pendiente

[local]imsupf02# show srp checkpoint statistics active
Thursday July 21 07:40:03 UTC 2022
Number of Sessmgrs: 20
Sessmgrs in Active-Connected state: 0
Sessmgrs in Standby-Connected state: 20
Sessmgrs in Pending-Active state: 0

Si alguno de estos dos se encuentra en estado Activo, primero debe realizar estas tareas antes del switchover:

[upf-ims]# save config /flash/xxx_production.cfg. --> Replace xxx with the desired name of the config
[upf-ims]# srp validate-configuration
[upf-ims]# srp validate-switchover

Antes del cierre de VM, debe asegurarse de que las instancias activas se conmuten a modo de espera para que los suscriptores se conmuten correctamente. Si la instancia ya está en espera, no se necesita ninguna acción. Si la instancia está activa, verifique los valores resaltados y asegúrese de que el modo en espera esté listo para asumir el control.

Verifique los suscriptores actuales en la instancia UPF activa.

[local]imsupf01# show subscribers data-rate summary 
Friday July 22 16:01:37 UTC 2022

Total Subscribers : 175024 
Active : 175024 Dormant : 0

Cambie la instancia activa a standby.

[context-name]<hostname># srp initiate-switchover

Verifique el estado del modo en espera, que ya se habría activado, y las sesiones del suscriptor también se mueven a la nueva instancia activa. Ahora que ambas instancias de VM están en estado de espera, es bueno que se desactiven para el mantenimiento del servidor. Utilice los comandos virsh dados para cerrar las instancias de VM y verificar el estado.

cloud-user@podname-upf-ims-kvmnode-1:~$ sudo virsh shutdown imsupf01
Domain imsupf01 is being shutdown
cloud-user@podname-upf-ims-kvmnode-1:~$ sudo virsh shutdown imsupf10
Domain imsupf10 is being shutdown
cloud-user@podname-upf-ims-kvmnode-1:~$ sudo virsh list --all
Id Name State
----------------------------------------------------
1 imsupf01 shut off
4 imsupf10 shut off

cloud-user@podname-upf-ims-kvmnode-1:~$

Una vez que el servidor se recupera después del mantenimiento, las VM se inician automáticamente. Las instancias de UPF permanecen en espera. verifique con el comando dado.

[local]imsupf10# show srp info
Friday July 22 15:50:24 UTC 2022
Service Redundancy Protocol:
-------------------------------------------------------------------------------
Context: srp 
Local Address: 10.x.x.74
Chassis State: Standby 
Chassis Mode: Backup 
Chassis Priority: 2 
Local Tiebreaker: 02-7E-35-53-F9-F1
Route-Modifier: 9 

Peer Remote Address: 10.x.x.73
Peer State: Active 
Peer Mode: Primary 
Peer Priority: 1 
Peer Tiebreaker: 02-11-59-73-87-35
Peer Route-Modifier: 8 
Last Hello Message received: Fri Jul 22 15:50:21 2022 (3 seconds ago)
Peer Configuration Validation: Complete 
Last Peer Configuration Error: None 
Last Peer Configuration Event: Fri Jul 22 15:50:22 2022 (2 seconds ago)
Last Validate Switchover Status: None 
Connection State: Connected 

El UPF de datos utiliza el RCM que tiene redundancia N:M, donde N es un número de UPF activos y es menor que 10, y M es un número de UPs en espera en el grupo de redundancia. RCM es un nodo propietario de Cisco o una función de red (NF) que proporciona redundancia para las funciones de plano de usuario (UPF) basadas en StarOS. Almacena o duplica toda la información de sesión requerida de todas las UPF activas. En un disparador de switchover, se selecciona un UPF en espera para recibir los datos de sesión apropiados desde la ubicación común. RCM se ejecuta en un clúster K3 en una VM. El Centro de operaciones configura el nodo RCM. 

Los nodos UPF de datos son también los mismos que los nodos UPF de IMS. La única diferencia es la administración de redundancia RCM. 

Verifique el estado de VM en el nodo KVM.

cloud-user@podname-upf-data-kvmnode-1:~$ sudo virsh list --all
Id Name State
----------------------------------------------------
1 dataupf20 running
2 dataupf11 running

cloud-user@podname-upf-data-kvmnode-1:~$

Después de iniciar sesión en la instancia de UPF, verifique el estado de redundancia de RCM. Si la instancia ya está en espera, no se necesita ninguna acción. Si está activo, debe conmutarse correctamente a modo de espera.

[local]dataupf11# show rcm info
Friday July 22 17:23:17 UTC 2022
Redundancy Configuration Module:
-------------------------------------------------------------------------------
Context: rcm 
Bind Address: 10.x.x.75
Chassis State: Active 
Session State: SockActive 
Route-Modifier: 26 
RCM Controller Address: 10.x.x.163
RCM Controller Port: 9200 
RCM Controller Connection State: Connected 
Ready To Connect: Yes 
Management IP Address: 10.x.x.149
Host ID: DATAUPF15
SSH IP Address: 10.x.x.158 (Activated)
SSH IP Installation: Enabled

[local]dataupf11#

Verifique si todos los sessmgr están en estado Active-connected.

local]dataupf11# show rcm checkpoint statistics active
Thursday July 21 07:47:03 UTC 2022
Number of Sessmgrs: 22
Sessmgrs in Active-Connected state: 22
Sessmgrs in Standby-Connected state: 0
Sessmgrs in Pending-Active state: 0

 Identifique el nodo de RCM correspondiente del cuestionario de información del cliente (CIQ) y verifique el estado de RCM. Tenga en cuenta que el switchover de RCM sólo se puede hacer desde el nodo maestro. Asegúrese de iniciar sesión en el RCM principal.

[podname-aio-1/dcrm01] rcm# rcm show-status
message :
{"status":"MASTER"}
[podname-aio-1/dcrm01] rcm# 

Busque los nodos UPF activos y en espera con el comando dado (resultado truncado):

[podname-aio-1/dcrm01] rcm# rcm show-statistics controller 
message :
{
"keepalive_version": "e7386cb81b1fefc3396dfd1d528e0d2a27de80d5de6a78364caf938a0d2149b6",
"keepalive_timeout": "20s",
"num_groups": 2,
"groups": [
{
"groupid": 1,
"endpoints_configured": 7,
"standby_configured": 1,
"pause_switchover": false,
"active": 6,
"standby": 1,
"endpoints": [
{
"endpoint": "10.x.x.75",
"bfd_status": "STATE_UP",
"upf_registered": true,
"upf_connected": true,
"upf_state_received": "UpfMsgState_Active",
"bfd_state": "BFDState_UP",
"upf_state": "UPFState_Active",
"route_modifier": 26,
"pool_received": true,
"echo_received": 142354,
"management_ip": "10.x.x.149",
"host_id": "DATAUPF15",
"ssh_ip": "10.x.x.158",
"force_nso_registration": false

....

....

 {
"endpoint": "10.x.x.77",
"bfd_status": "STATE_UP",
"upf_registered": true,
"upf_connected": true,
"upf_state_received": "UpfMsgState_Standby",
"bfd_state": "BFDState_UP",
"upf_state": "UPFState_Standby",
"route_modifier": 50,
"pool_received": false,
"echo_received": 3673,
"management_ip": "10.x.x.153",
"host_id": "",
"ssh_ip": "10.x.x.186",
"force_nso_registration": false
},

 Inicie sesión en la instancia UPF en espera con la IP de administración y verifique el estado

[local]dataupf13# show rcm info
Friday July 22 17:36:04 UTC 2022
Redundancy Configuration Module:
-------------------------------------------------------------------------------
Context: rcm 
Bind Address: 10.x.x.77
Chassis State: Standby 
Session State: SockStandby 
Route-Modifier: 50 
RCM Controller Address: 10.x.x.163
RCM Controller Port: 9200 
RCM Controller Connection State: Connected 
Ready To Connect: Yes 
Management IP Address: 10.x.x.153
Host ID: 
SSH IP Address: 10.x.x.186 (Activated)
SSH IP Installation: Enabled

[local]dataupf13#

Después de la verificación, conmute el activo al modo en espera. Asegúrese de utilizar la IP de administración.

[podname-aio-1/dcrm01] rcm# rcm switchover-mgmt-ip source 10.x.x.149 destination 10.x.x.153 

Nota: En el caso posterior al switchover si el nuevo sessmgr de Active UP está atascado en el estado SERVER. Involucre al soporte técnico de Cisco. En el caso de instancias problemáticas, sessmgr debe ser eliminado, por lo que se vuelve a conectar con el RCM con el estado de socket CLIENT adecuado y se recupera. Todos los sessmgr deben estar en el estado CLIENT. Verifíquelo con el comando dado (en modo oculto).

# show session subsystem facility sessmgr all debug-info | grep -E "SessMgr|Mode:" 
Thursday July 21 07:56:26 UTC 2022
SessMgr: Instance 5000
Mode: UNKNOWN State: SRP_SESS_STATE_SOCK_ACTIVE
SessMgr Activity Detected: FALSE
SessMgr: Instance 22
Mode: CLIENT State: SRP_SESS_STATE_SOCK_ACTIVE
SessMgr Activity Detected: TRUE
SessMgr: Instance 21
Mode: CLIENT State: SRP_SESS_STATE_SOCK_ACTIVE
SessMgr Activity Detected: TRUE

Verifique que todos los sessmgr estén activos y listos.

# show rcm checkpoint statistics verbose 
Thursday July 21 07:52:29 UTC 2022
smgr state peer recovery pre-alloc chk-point rcvd chk-point sent
inst conn records calls full micro full micro
---- ------- ----- ------- -------- ----- ----- ----- ----
1 Actv Ready 0 0 1731 68120 3107912 409200665
2 Actv Ready 0 0 1794 70019 3060062 408647685
3 Actv Ready 0 0 1753 68793 3078531 406227415
4 Actv Ready 0 0 1744 67585 3080952 410218643
5 Actv Ready 0 0 1749 69155 3096067 404944553
6 Actv Ready 0 0 1741 68805 3067392 407133464
7 Actv Ready 0 0 1744 67963 3084023 406772101
8 Actv Ready 0 0 1748 68702 3009558 408073589
9 Actv Ready 0 0 1736 68169 3030624 405679108
10 Actv Ready 0 0 1707 67386 3071592 406000628
11 Actv Ready 0 0 1738 68086 3052899 407991476
12 Actv Ready 0 0 1720 68500 3102045 408803079
13 Actv Ready 0 0 1772 69683 3082235 406426650
14 Actv Ready 0 0 1727 66900 2873736 392352402
15 Actv Ready 0 0 1739 68465 3032395 409603844
16 Actv Ready 0 0 1756 69221 3063447 411445527
17 Actv Ready 0 0 1755 68708 3051573 406333047
18 Actv Ready 0 0 1698 66328 3066983 407320405
19 Actv Ready 0 0 1736 68030 3037073 408215965
20 Actv Ready 0 0 1733 67873 3069116 405634816
21 Actv Ready 0 0 1763 69259 3074942 409802455
22 Actv Ready 0 0 1748 68228 3051222 406470380

Verifique que los suscriptores se muevan al nuevo modo en espera:

[local]dataupf11# show subscribers data-rate summary 
Friday July 22 17:40:18 UTC 2022

Total Subscribers : 62259 
Active : 62259 Dormant : 0

Cuando ambas instancias están en espera, las VM se pueden apagar desde KVM con comandos virsh.

cloud-user@podname-upf-data-kvmnode-1:~$ sudo virsh shutdown dataupf20
Domain dataupf20 is being shutdown
cloud-user@podname-upf-data-kvmnode-1:~$ sudo virsh shutdown dataupf11
Domain dataupf11 is being shutdown
cloud-user@podname-upf-data-kvmnode-1:~$ sudo virsh list --all
Id Name State
----------------------------------------------------
1 dataupf20 shut off
4 dataupf11 shut off

cloud-user@podname-upf-data-kvmnode-1:~$

Cuando se cierran las VM, se puede cerrar el nodo KVM (servidor físico) para realizar el mantenimiento. Una vez completado, inicie el servidor. Las VM se activan automáticamente. Las instancias de UPF se vuelven independientes. Verifique lo mismo con los comandos dados.

cloud-user@podname-upf-data-kvmnode-1:~$ sudo virsh list --all
Id Name State
----------------------------------------------------
1 dataupf20 running
2 dataupf11 running

cloud-user@podname-upf-data-kvmnode-1:~$

[local]dataupf11# show rcm info
Friday July 22 17:36:04 UTC 2022
Redundancy Configuration Module:
-------------------------------------------------------------------------------
Context: rcm 
Bind Address: 10.x.x.77
Chassis State: Standby 
Session State: SockStandby 
Route-Modifier: 50 
RCM Controller Address: 10.x.x.163
RCM Controller Port: 9200 
RCM Controller Connection State: Connected 
Ready To Connect: Yes 
Management IP Address: 10.x.x.153
Host ID: 
SSH IP Address: 10.x.x.186 (Activated)
SSH IP Installation: Enabled

[local]dataupf13#

En el nodo RCM, el controlador rcm todavía puede mostrar el UPF en espera como "espera pendiente". Esto puede tardar entre 15 y 20 minutos en transformarse a modo de espera. Verifique lo mismo con los comandos dados (resultado truncado):

[podname-aio-1/dcrm01] rcm# rcm show-statistics controller 
message :
{
"keepalive_version": "e7386cb81b1fefc3396dfd1d528e0d2a27de80d5de6a78364caf938a0d2149b6",
"keepalive_timeout": "20s",
"num_groups": 2,
"groups": [
{
"groupid": 1,
"endpoints_configured": 7,
"standby_configured": 1,
"pause_switchover": false,
"active": 6,
"standby": 1,
"endpoints": [
....
....
{
"endpoint": "10.x.x.77",
"bfd_status": "STATE_UP",
"upf_registered": true,
"upf_connected": true,
"upf_state_received": "UpfMsgState_Standby",
"bfd_state": "BFDState_UP",
"upf_state": "UPFState_Standby",
"route_modifier": 50,
"pool_received": false,
"echo_received": 3673,
"management_ip": "10.x.x.153",
"host_id": "",
"ssh_ip": "10.x.x.186",
"force_nso_registration": false
},