Contenido

Introducción

Prerequisites

Requirements

Componentes Utilizados

Antecedentes

¿Qué es SMI?

¿Qué es CEE?

¿Qué son las VM de protocolo?

Problema

Troubleshoot

Solución Aternativa

Verificación

Introducción

Este documento describe cómo implementar una solución alternativa para los problemas de sincronización horaria del protocolo de tiempo de red (NTP) en las máquinas virtuales de protocolo (VM de protocolo) de infraestructura de microservicios de suscriptor de 5G (SMI).

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento de estos temas:

- SMI de Cisco

- Arquitectura de plataforma de implementación nativa en la nube (CNDP) 5G

- Nube - Red Hat OpenStack Platform 13 ("Queens" versión)

- Dockers y Kubernetes

Componentes Utilizados

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

- SMI 2020.01.1-21

- Kubernetes v1.16.2

- Director de Red Hat OpenStack Platform 13

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 SMI?

Cisco SMI es una pila por capas de estándares y tecnologías de nube que permiten utilizar aplicaciones basadas en microservicios desde las unidades empresariales de Cisco Mobility, Cable y Broadband Network Gateway (BNG). Estas aplicaciones tienen funciones de administración de suscriptores similares y requisitos de almacenamiento de datos similares.

Atributos:

- La pila de nube de capa (tecnologías y estándares) proporciona implementaciones de arriba a abajo y se adapta a las infraestructuras de nube actuales.

- Todas las aplicaciones comparten el entorno de ejecución común (CEE) para funciones que no son de aplicación (almacenamiento de datos, implementación, configuración, telemetría, alarma), que proporciona una interacción y experiencia uniformes para todos los puntos de contacto y puntos de integración de los clientes.

- Las aplicaciones y CEE se implementan en contenedores de microservicios y se conectan con una malla de servicio inteligente.

- Una API expuesta para la implementación, configuración y gestión permite la automatización.

¿Qué es CEE?

- CEE es una solución de software desarrollada para supervisar las aplicaciones móviles y de cable que se implementan en SMI. La CEE captura información (métricas clave) de las aplicaciones de forma centralizada para que los ingenieros puedan depurar y solucionar problemas.

- CEE es el conjunto común de herramientas que se instalan para todas las aplicaciones. Incluye un centro de operaciones dedicado, que proporciona la interfaz de línea de comandos (CLI) y API para administrar las herramientas de supervisión. Sólo hay un CEE disponible para cada clúster.

¿Qué son las VM de protocolo?

Las VM de protocolo alojan los microservicios de aplicación de la función de administración de sesiones (SMF) responsables de la traducción del protocolo. Se implementan dos VM de protocolo por instancia de SMF. Una VM de protocolo tiene grupos de dispositivos como GTPc, Lawful Intercept (LI), Radius, Rest, etc.

Problema

Desde un nodo (VM de protocolo) que muestra el problema, puede ver que la red intenta utilizar dos interfaces diferentes para rutear la conectividad al servidor NTP. Sin embargo, sólo una de las redes puede alcanzar la IP.

Cuando ejecuta un ping sin la interfaz durante algún tiempo, puede ver que causa la pérdida de paquetes.

Alerta de ejemplo de CEE:

[pod-name-cnat/global] cee# show alerts active summary

NAME UID SEVERITY STARTS AT SOURCE SUMMARY

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

VoNR_Ded_Bearer_Creat be183f61dd65 major 01-18T16:32:17 System Success percentage of VoNR - PCF Initiated Dedicated Bearer Creation procedure in NR turns less than t...

clock-is-not-in-synch 38a35e9a8bd8 major 01-18T13:11:15 pod-name-cnat-cnat-co Clock not in synch detected on hostname pod-name-cnat-cnat-core-protocol-data1 . Ensure NTP is configu...

clock-is-not-in-synch 4a7e138b8bae major 01-18T13:07:35 pod-name-cnat-cnat-co Clock not in synch detected on hostname pod-name-cnat-cnat-core-protocol-ims2 . Ensure NTP is configur...

clock-is-not-in-synch 5b3e128f0101 major 01-18T12:05:55 pod-name-cnat-cnat-co Clock not in synch detected on hostname pod-name-cnat-cnat-core-protocol-data2 . Ensure NTP is configu...

container-memory-usag f588aa627792 critical 12-28T15:47:30 path-provisioner-v6zx Pod cee-global/path-provisioner-v6zxj/k8s_path-provisioner_path-provisioner-v6zxj_cee-global_f1a1e8fa-...

container-memory-usag 55b2ea84466f critical 12-27T22:27:10 path-provisioner-v6zx Pod cee-global/path-provisioner-v6zxj/ uses high memory 82.69%.

N11_SM_Timeout_SR f6fb82cac197 major 10-31T15:51:16 System This alert is fired when the increase in timeout for N11 messages toward AMF crosses threshold

Radius_Server_RTT 94ac2cff43a3 warning 10-28T05:08:56 System RTT for Radius Server: 216.x.x.x, Port: 1813 in namespace: smf-mvno is more than 5 ms.

Radius_Server_RTT d02b60b3a3a4 warning 10-28T05:05:56 System RTT for Radius Server: 52.x.x.x, Port: 1813 in namespace: smf-mvno is more than 5 ms.

Radius_Server_RTT 9afcee101013 warning 10-28T05:05:36 System RTT for Radius Server: 52.x.x.x, Port: 1813 in namespace: smf-mvno is more than 5 ms.

N11_SM_Timeout_SR 206c4bbccf21 major 10-20T13:26:16 System This alert is fired when the increase in timeout for N11 messages toward AMF crosses threshold

N4_Total_Outbound_Int 4e0f3c1d6300 major 10-20T09:01:23 System This alert is fired when the percentage of N4 outbound responses sent is lesser than threshold %.

N4_Total_Outbound_Int 3e2fed624704 major 10-20T08:21:23 System This alert is fired when the percentage of N4 outbound responses sent is lesser than threshold %.

watchdog 97a7976a4103 minor 05-05T09:10:58 System This is an alert meant to ensure that the entire alerting pipeline is functional. This alert is always...

Troubleshoot

1. Inicie sesión en las VM afectadas y ejecute este comando: ip route | grep -i default

En este ejemplo, puede ver dos rutas predeterminadas, que son incorrectas. (Sólo debe haber una ruta predeterminada.)

ubuntu@pod-name-cnat-cnat-core-protocol-ims2:~$ ip route | grep -i default

default via 172.16.x.x dev ens4 proto dhcp src 172.16.x.x metric 100

default via 172.16.x.x dev ens3 proto dhcp src 172.16.x.x metric 100

2. Compruebe el estado del servicio Cronyd (NTP). Aunque el servicio está activo, verá errores "No se puede sincronizar".

Ejemplo de resultado

root@pod-name-cnat-cnat-core-protocol-data1:/home/ubuntu# systemctl status chronyd.service

chrony.service - chrony, an NTP client/serverLoaded: loaded (/lib/systemd/system/chrony.service; enabled; vendor preset: enabled)

Active: active (running) since Fri 2021-01-08 07:19:19 UTC; 11 months 24 days ago

Docs: man:chronyd(8)

man:chronyc(1)

man:chrony.conf(5)

Main PID: 4300 (chronyd)

Tasks: 1 (limit: 4915)

CGroup: /system.slice/chrony.service

└─4300 /usr/sbin/chronyd

Dec 30 17:06:28 pod-name-cnat-cnat-core-protocol-data1 chronyd[4300]: Selected source 5.196.x.x

Dec 31 06:37:11 pod-name-cnat-cnat-core-protocol-data1 chronyd[4300]: Can't synchronise: no selectable sources

Dec 31 17:15:31 pod-name-cnat-cnat-core-protocol-data1 chronyd[4300]: Selected source 5.196.x.x

Jan 01 06:29:43 pod-name-cnat-cnat-core-protocol-data1 chronyd[4300]: Can't synchronise: no selectable sources

Jan 01 16:50:02 pod-name-cnat-cnat-core-protocol-data1 chronyd[4300]: Selected source 5.196.x.x

Jan 01 19:25:05 pod-name-cnat-cnat-core-protocol-data1 chronyd[4300]: Can't synchronise: no selectable sources

3. Verifique el estado del servicio network-config. (Está inactivo.)

ubuntu@pod-name-cnat-cnat-core-protocol-data1:~$ systemctl status network-config

network-config.service - Job that configures for routes

Loaded: loaded (/etc/systemd/system/network-config.service; enabled; vendor preset: enabled)

Active: inactive (dead) since Fri 2021-01-08 09:29:05 UTC; 1 years 0 months ago

Process: 1185 ExecStart=/etc/cisco/network-config.sh start (code=killed, signal=TERM)

Main PID: 1185 (code=killed, signal=TERM)

Solución Aternativa

Nota: Este procedimiento no causa tiempo de inactividad en la aplicación.

1. Editar el script de servicio network-config (/etc/systemd/system/network-config.service) en el nodo afectado para agregar estas líneas:

root@pod-name-cnat-cnat-core-protocol-data1:/home/ubuntu# vim /etc/systemd/system/network-config.service

Restart=always

RestartSec=10s

StartLimitIntervalSec=300s

StartLimitBurst=30

2. Inicie el servicio network-config:

root@pod-name-cnat-cnat-core-protocol-data1:/home/ubuntu# systemctl start network-config

3. Recargue la configuración con systemctl:

root@pod-name-cnat-cnat-core-protocol-data1:/home/ubuntu# systemctl daemon-reload

4. Reinicie el servicio de cronyd:

root@pod-name-cnat-cnat-core-protocol-data1:/home/ubuntu# systemctl restart chronyd.service

Verificación

Después de completar los pasos de Solución, ejecute este comando para verificar que los problemas se solucionan:

for server in $(awk '/protocol/{print $1}' /etc/hosts); do ssh $server "hostname && timedatectl status && chronyc sources -vn" ; done

Nota: Un valor "System clock sync" de "yes" indica que los problemas están corregidos.

Ejemplo de resultado

ubuntu@pod-name-cnat-cnat-core-master1:~$ for server in $(awk '/protocol/{print $1}' /etc/hosts); do ssh $server "hostname && timedatectl status && chronyc sources -vn" ; done

pod-name-cnat-cnat-core-protocol-data1

Local time: Tue 2021-09-07 10:22:16 UTC

Universal time: Tue 2021-09-07 10:22:16 UTC

RTC time: Tue 2021-09-07 10:22:17

Time zone: Etc/UTC (UTC, +0000)

System clock synchronized: yes

systemd-timesyncd.service active: no

RTC in local TZ: no

210 Number of sources = 1

MS Name/IP address         Stratum Poll Reach LastRx Last sample

===============================================================================

^* svtsnq01.mgmt                 1   6   170   282  -1100us[-1858us] +/-   47ms

pod-name-cnat-cnat-core-protocol-data2

Local time: Tue 2021-09-07 10:22:16 UTC

Universal time: Tue 2021-09-07 10:22:16 UTC

RTC time: Tue 2021-09-07 10:22:17

Time zone: Etc/UTC (UTC, +0000)

System clock synchronized: yes

systemd-timesyncd.service active: no

RTC in local TZ: no

210 Number of sources = 1

MS Name/IP address         Stratum Poll Reach LastRx Last sample

===============================================================================

^* svtsnq01.mgmt                 1   6    74   206   -218us[-1550us] +/-   46ms

pod-name-cnat-cnat-core-protocol-ims1

Local time: Tue 2021-09-07 10:22:17 UTC

Universal time: Tue 2021-09-07 10:22:17 UTC

RTC time: Tue 2021-09-07 10:22:18

Time zone: Etc/UTC (UTC, +0000)

System clock synchronized: yes

systemd-timesyncd.service active: no

RTC in local TZ: no

210 Number of sources = 1

MS Name/IP address         Stratum Poll Reach LastRx Last sample

===============================================================================

^* svtsnq01.mgmt                 1   6    77    24   +796us[+1044us] +/-   47ms

pod-name-cnat-cnat-core-protocol-ims2

Local time: Tue 2021-09-07 10:22:17 UTC

Universal time: Tue 2021-09-07 10:22:17 UTC

RTC time: Tue 2021-09-07 10:22:18

Time zone: Etc/UTC (UTC, +0000)

System clock synchronized: yes

systemd-timesyncd.service active: no

RTC in local TZ: no

210 Number of sources = 1

MS Name/IP address         Stratum Poll Reach LastRx Last sample

===============================================================================

^* svtsnq01.mgmt                 1   6    17    98  +2176us[+2275us] +/-   47ms