Contenido

Introducción

Prerequisites

Requirements

Componentes Utilizados

Antecedentes

¿Qué es UPF?

¿Qué es VPC-SI?

¿Qué es el hipervisor KVM?

¿Qué es ICSR?

Problema

Procedimiento de mantenimiento

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

},