Congestión STP, IMSIMGR sobre estado y el link SCTP se inestabiliza en SGSN debido a HLR MAP_RESET
Contenido
Introducción
Este documento describe un problema que se ha encontrado en el nodo de soporte del servicio general de radio de paquetes (GPRS) (SGSN) del router de servicios agregados (ASR) de la serie Cisco 5000. También se describen algunas posibles soluciones para este problema.
Antecedentes
Esta cadena específica de eventos en ASR SGSN se describe en este documento:
- 21 de noviembre, 6:25 am: El registro de ubicación de inicio (HLR) envió un MAP_RESET.
- 21 de noviembre, 8:13 am: Se produce una alarma de congestión para el punto de transferencia de señal 2 (STP-2).
- 21 de noviembre, 8:23 am: Se genera una alarma de congestión para STP-1 y STP-2.
- 21 de noviembre, 8:48 am: El administrador de identidad del suscriptor móvil internacional (IMSIMGR) pasa al estado de advertencia.
- 21 de noviembre, 10:07 a.m: Los links se restablecen desde STP-2 hacia el SGSN.
- 21 de noviembre, 10:15 am: Se observa una mejora en las estadísticas de actualización de ubicación (LU) de SGSN.
- 21 de noviembre, 10:00 â 10:30 AM: Las estadísticas empiezan a mejorar a las 10:00 am.
- 21 nov, 11:15 am : Se observa una disminución en las estadísticas de LU de SGSN.
- 21 nov, 11:41 am: El equipo STP informa que el código de enlace de señalización (SLC)-1 de STP-2 no recibe tráfico, el SLC se reinicia y el tráfico vuelve a la normalidad.
- 21 de noviembre, 11:42 am: Se genera una alarma de congestión en SGSN para SLC-1 del STP.
- 21 nov, 12:00 PM: Después de restablecer el SLC-3, las estadísticas de LU de GPRS mejoran.
Problema
Cuando la HLR recibe el mensaje MAP_RESET, establece un indicador para una actualización de ubicación de GPRS (GLU). Cuando el equipo de usuario (UE) envía sus primeros paquetes de enlace ascendente, el SGSN envía un mensaje GLU a la HLR.
At 7 AM SGSN , Nov 21st 2014 had
******** show subscriber summary *******
Total Subscribers: 2386266
Active: 2386266
sgsn-pdp-type-ipv4: 942114
Como se muestra en el resultado del ejemplo, hay 950 000 contextos de protocolo de datos de paquetes (PDP) presentes en el SGSN y los UE intentan examinarlos a medida que avanza el día.
Cuando se reciben los primeros paquetes de link ascendente, el SGSN activa un mensaje GLU. Debido a que hay cientos de miles de UE, el STP no puede manejar la cantidad de tráfico que se genera y pasa a un estado de congestión permanente.
Los mensajes se ponen en cola en el SGSN, y ocurre un tiempo de espera máximo de retransmisión. Dado que todos los mensajes GLU no pasan de la SGSN a la HLR, la SGSN se ve obligada a desconectar a los suscriptores móviles y a solicitar que vuelvan a conectarse. Todos los suscriptores desconectados entonces intentan conectarse, lo que causa un repentino aumento en el número de solicitudes de adjuntos entrantes. Dado que se aplica la protección contra sobrecarga de red, la mayoría de los intentos de adhesión se rechazan debido a la congestión y los suscriptores móviles se ven obligados a realizar un nuevo intento.
A medida que se desarrolla esta cadena de eventos, produce efectos en cascada. Muchos mensajes Send Authentication Information (SAI), mensajes GLU y mensajes MAP-IMEI_CHECK se atascan en la cola SGSN o se descartan. Por esta razón, todos los links STP-1 y STP-2 alcanzan un estado de congestión. Cada STP tiene cuatro links de señalización, pero en este escenario, los primeros tres links de STP-2 no se recuperan durante mucho tiempo.
Estas son las alarmas de congestión, en las que puede ver que todos los links STP se mueven al estado de congestión en STP-2:
Fri Nov 21 08:13:14 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-1 (point-code-782)
congested congLevel-1
Fri Nov 21 08:13:14 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-2 (point-code-782)
congested congLevel-1
Fri Nov 21 08:13:14 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-3 (point-code-782)
congested congLevel-1
Fri Nov 21 08:13:29 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
congested congLevel-1
Fri Nov 21 08:18:48 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
congested congLevel-1
Fri Nov 21 08:20:00 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
congested congLevel-1
Fri Nov 21 08:22:52 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
congested congLevel-1
Fri Nov 21 08:22:55 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
congested congLevel-1
Fri Nov 21 08:23:22 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
congested congLevel-1
Fri Nov 21 08:26:33 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
congested congLevel-1
Fri Nov 21 08:28:06 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
congested congLevel-1
Fri Nov 21 08:28:45 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
congested congLevel-1
Fri Nov 21 09:27:27 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
congested congLevel-1
Como se muestra, sólo se borró el proceso de servidor par (PSP) 4 y el resto se encuentra todavía en estado de congestión:
Fri Nov 21 08:18:47 2014 Internal trap notification 1075 (M3UAPSPCongestionCleared)
ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
congestion cleared congLevel-0
Solución
Esta sección describe cómo resolver el problema que se describe en la sección anterior.
El link STP recibe demasiado tráfico
Como se describe en la sección anterior, un link particular en el STP recibe una gran cantidad de tráfico. Puede ver que los primeros tres links en STP-2 se mueven al estado de congestión y nunca se recuperan, por lo que sólo hay un link disponible y la alarma de congestión se borra en SLC-3 (o peer-server-2-peer-server-process-4).
De acuerdo con el mecanismo de carga compartida de SGSN, debe enviar los paquetes de capa de adaptación de usuario (M3UA) de nivel 3 de transferencia de mensajes (MTP) por igual en los cuatro enlaces. Sin embargo, desde las trampas del protocolo simple de mensajes de red (SNMP), los tres primeros enlaces STP-2 están permanentemente congestionados, lo que significa que todo el tráfico se enruta al enlace SLC-3 (el único enlace STP disponible para enrutar el tráfico). Esto explica por qué la distribución del tráfico se distorsiona entre los links STP-2.
En situaciones de congestión, uno o más links alternan entre estados congestionados y no congestionados, por lo que sólo los links disponibles comparten el tráfico. Por esta razón, hay más utilización en uno de los links. Esto requiere un reinicio del link para recuperar los links.
El siguiente resultado muestra las estadísticas del nivel M3UA y las estadísticas de desconexión. Las estadísticas importantes a considerar son la instancia PSP STP-2 4, donde se puede ver tráfico anormal:
Time #1:ss7rd-m3ua-psp-data-tx #2:ss7rd-m3ua-psp-error-tx #3:ss7rd-m3ua-psp-data-rx
21-11-14 7:30 37409 0 37942
21-11-14 8:00 43677 0 43866
21-11-14 8:30 190414 0 71844
21-11-14 9:00 547418 0 104135
21-11-14 9:30 536019 0 102477
21-11-14 10:00 376797 0 132227
21-11-14 10:30 100394 0 97302
21-11-14 11:00 119652 0 114809
21-11-14 11:30 107073 0 95354
Estos son los datos STP:
DATE TIME LSN LOC SLC LINK TX % RX %
11/21/2014 9:00 sgsncisco 5216 3 A IPVL 11.26 62.07
11/21/2014 9:00 sgsncisco 5213 0 A1 IPVL 11.29 4.86
11/21/2014 9:00 sgsncisco 5214 1 A1 IPVL 11.27 4.85
11/21/2014 9:00 sgsncisco 5215 2 A IPVL 11.23 4.7
Esta salida muestra los desprendimientos por segundo en el momento del problema:
Time #13:2G-ms-init-detach #14:2G-nw-init-detach
21-11-14 6:30 136465 7400
21-11-14 7:00 149241 9557
21-11-14 7:30 165788 12630
21-11-14 8:00 179311 16963
21-11-14 8:30 125564 44759
21-11-14 9:00 112461 95299
21-11-14 9:30 240341 112461
21-11-14 10:00 288014 116298
21-11-14 10:30 203261 123300
21-11-14 11:00 67788 122945
Esta salida muestra los adjuntos por segundo, según WEM:
Time #3:2G-total-attach-req-all Request/Second
21-11-14 8:00 738279 205.078
21-11-14 9:00 14053511 3903.753
21-11-14 10:00 24395071 6776.409
21-11-14 11:00 24663454 6850.959
21-11-14 12:00 17360687 4822.413
IMSIMGR en estado de advertencia
La IMSIMGR debe procesar cada nueva solicitud de IMSI/Packet Temporal Mobile Subscriber Identity (P-TMSI) attach y Routing Area Update (RAU) de llamada.
Con una observación conservadora, el sistema recibe un valor máximo de 6850 solicitudes de adhesión de 2 G por segundo y alrededor de 5313 solicitudes de adhesión de 3 G por segundo. El valor máximo que puede establecer para la protección contra sobrecarga de red es de 5000 solicitudes de adhesión por segundo. Para mantener el IMSIMGR en estado operativo, el sistema no puede manejar un número tan grande de llamadas de los UE.
Este problema comienza después de las 8 AM, cuando el tamaño de la cola alcanza 1500 solicitudes de adhesión por segundo:
network-overload-protection sgsn-new-connections-per-second 500 action
reject-with-cause congestion queue-size 1500 wait-time 5
Dado que hay aproximadamente 12 000 solicitudes de adhesión por segundo, el IMSIMGR procesa y rechaza casi 9000 llamadas. Esto hace que el procesamiento de CPU IMSIMGR alcance un estado alto.
Si el SGSN recibe más del número configurado de solicitudes de adhesión en un segundo, las solicitudes se almacenan en la memoria intermedia en la cola de rastreo y sólo se descartan cuando el búfer se desborda debido a una alta tasa de adhesión entrante. Los mensajes de la cola se procesan de acuerdo con un proceso Primero en entrar, Primero en salir (primero en salir, primero en salir, primero en salir, primero en salir) hasta que se agota el tiempo de espera configurado cuando la vida útil del mensaje en cola supera el tiempo de espera configurado.
Cuando elige las opciones reject o drop en función de sus preferencias, Cisco recomienda que utilice un código de causa reject para indicar la congestión en la red, lo que le permite comprender las condiciones de la red antes de intentar un procedimiento de link ascendente.
Falla HLR
De acuerdo con la Especificación técnica (TS) 23.060 del proyecto de asociación de tercera generación (3GPP), esta sección describe el comportamiento de SGSN durante un reinicio de HLR. Siempre que el SGSN reciba un reinicio del MAP, se espera que envíe una solicitud UL hacia el HLR para sus suscriptores.
Cuando se reinicia una HLR, envía un mensaje de reinicio a cada SGSN al que se registran una o más de sus estaciones móviles (MS). Esto hace que SGSN marque los contextos de gestión móvil relevantes como inválidos si existe una asociación entre SGSN y el centro de switching móvil (MSC)/registro de ubicación visitante (VLR). Después de recibir la primera trama de control de link lógico (LLC) válida (para el modo A/Gb) o después de recibir el primer paquete de protocolo de túnel GPRS (GPT-U) válido o un mensaje de señalización de enlace ascendente (para el modo Iu) desde una estación móvil marcada, el SGSN realiza una UL al HLR como en los procedimientos de actualización de solicitud de adhesión o de área de enrutamiento entre SGSN (RA). Además, si se establece el indicador de alerta no GPRS (NGAF), se sigue el procedimiento de la cláusula Alerta no GPRS. El SGSN podría retrasar el procedimiento UL y el procedimiento hacia el MSC/VLR para una configuración máxima del operador, dependiendo del uso de recursos en ese momento para evitar una carga alta de señalización.
Recomendaciones
Cisco recomienda que complete estos pasos para resolver este problema:
- Aumente el número de nuevas conexiones por segundo. Esto se puede calcular en función del promedio de solicitudes de adhesión.
- Aumente las transacciones por segundo (TPS) en el enlace STP a un valor ideal.
- Cambie el valor SCTP-RTO-MAX de 600 (600*100 = 60.000) a 5 (5*100 ms). Por ejemplo, para dos STP con 4000 TPS, puede soportar hasta 1000 solicitudes de conexión por segundo desde el SGSN.
Lo ideal es que cada STP tenga cuatro enlaces para que 125 solicitudes de conexión puedan procesarse por link STP. Esto se distribuye equitativamente a través de todos los links STP. Sin embargo, si uno de los links deja de funcionar, se ven muchos intentos de reconexión, la cola se llena y se producen descartes de paquetes. Si más links se desactivan, el tráfico se distribuye de manera desigual.
Flujo de tráfico
El tráfico UE no sigue un modo lineal. Suele ocurrir en ráfaga y con muchos intentos de reconexión. El SGSN envía tráfico en paquetes al STP. En ese momento, las cantidades de tráfico exceden el TPS configurado en el STP. Esto hace que algunos links en el STP comiencen a anunciar el tamaño bajo de la ventana si ya procesan más llamadas, y el SGSN comienza a poner en cola los fragmentos de datos SCTP que están en cola. A continuación, espera a que caduque el temporizador RTO MAX.
Si el STP envía periódicamente un buen tamaño de ventana anunciado, debería poder enviar más fragmentos de datos SCTP si el valor SCTP_RTO_MAX se reduce a cinco segundos o menos. La cola se borra más rápido y no se activa una alarma de congestión M3UA. Además, no debe ver el indicador de control de flujo interno desencadenado por el SCTP para controlar el flujo de paquetes.
El SGSN sólo envía paquetes en la cantidad que el STP puede aceptar, que se basa en el tamaño de la ventana anunciada. Si aumenta el link TPS por STP, ayuda a evitar la congestión STP y reduce el temporizador SCTP_RTO_MAX.
Desencadenadores de M3UA con alarma congestionada en SGSN
Si el tamaño de ventana anunciado en el mensaje de confirmación selectiva (SACK) del protocolo de transmisión de control de flujo (SCTP) está cerca de cero (o cero), el SGSN genera una alarma M3UA para indicar que no se deben enviar mensajes para ese punto final de peer. Esto hace que el link inestable o pase a un estado congestionado. Dado que el SGSN envía un tamaño de ventana más alto, usted continúa recibiendo datos M3UA de los nodos de peer, y esos paquetes podrían ser descartados en la cola de espera si el código de punto de peer nunca sale del estado congestionado.
Aquí tiene un ejemplo:
- El SCTP envía una indicación de inicio del control de flujo al M3UA.
- M3UA establece el indicador de congestión activa para la asociación y comienza a sondear periódicamente el SCTP sobre su estado de control de flujo.
- Mientras una asociación se encuentra en control de flujo, pone en cola las futuras solicitudes de datos de esa asociación hasta que la QUEUE_SIZE alcance los 8000. En ese momento, se descartan los mensajes futuros para la asociación.
- Si el STP envía un tamaño adecuado de ventana anunciada, el M3UA intenta vaciar los mensajes que están en cola hasta alcanzar 5,000. El temporizador RTO también juega un papel en esto.
Los mensajes SCTP se ponen en cola solamente para aquellas asociaciones donde el indicador de control de flujo se convierte en True, y el SGSN luego se procesa de acuerdo con la respuesta STP:
*Peer Server Id : 2 Peer Server Process Id: 2
Association State : ESTABLISHED
Flow Control Flag : TRUE
Peer INIT Tag : 20229
SGSN INIT Tag : 3315914061
Next TSN to Assign to
Outgoing Data Chunk : 3418060778
Lowest cumulative TSN acknowledged : 3418060634
Cumulative Peer TSN arrived from peer : 103253660
Last Peer TSN sent in the SACK : 103253658
Self RWND : 1048576
Advertised RWND in received SACK : 8
Peer RWND(estimated) : 8
Retransmission counter : 0
Zero Window Probing Flag : FALSE
Last Tsn received during ZWnd Probing : 0
Bytes outstanding on all
addresses of this association : 19480
Congestion Queue Length : 143
Ordered TSN assignment Waiting QLen : 8050
Unordered TSN assignment Waiting QLen : 0
Total number of GAP ACKs Transmitted : 279
Total number of GAP ACKs Received : 58787
Path No. : 1
Current CWND : 11840
SSThresh : 11840
Partial Bytes Acked : 0
Bytes Outstanding for this Path : 19480
Current RTO for this Path(in ms) : 60000
Como se muestra, la razón detrás de la congestión es que el número total de fragmentos salientes excede el límite de 5,000 (8050+143=8193) y llega al temporizador máximo de 60 segundos de RTO, lo que da lugar a solicitudes de datos SCTP descartadas. Además, hay un temporizador RTO más alto.
Historial de revisiones
| Revisión | Fecha de publicación | Comentarios |
|---|---|---|
1.0 |
16-Apr-2015 |
Versión inicial |
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)