Introducción
Este documento describe el problema y la solución relacionados con los enlaces de capa de adaptación de usuario (M3UA) de nivel 3 de MTP (parte de transferencia de mensajes) que van a un estado de congestión o estado de inestabilidad, después de una interrupción de red importante o una actualización de software del nodo de servicio (SGSN) del router de servicios de agregación (ASR) de Cisco que atiende GPRS (servicio de radio de paquetes general). Esto sucede normalmente en los escenarios de interoperabilidad en los que el nodo ASR 5000 está conectado a nodos de terceros, como Home Location Register (HLR) o Radio Access Network (RNC).
Problema
El problema subyacente es que la SGSN ASR 5000 recibe un tamaño de ventana de baja publicidad en la capa de protocolo de transmisión de control de transmisión (SCTP) desde el nodo de peer remoto, el nodo de punto de transferencia de señalización (STP), HLR o RNC. El tamaño bajo de la ventana se puede ver en el seguimiento de captura de paquetes, el comando show SCTP o el seguimiento del protocolo de monitoreo en el SGSN. En la captura de paquetes puede ver el tamaño de ventana anunciado en el mensaje SCTP SACK con un valor de cero o cercano a cero. Cuando esto sucede, SGSN provoca una alarma M3UA para informar al nodo de peer que no envíe el paquete desde ese punto final de peer. Esto hace que el link SCTP inestable o entre en un estado congestionado. Dado que SGSN envía un tamaño de ventana normal, continúa recibiendo datos M3UA de nodos de peer, pero esos paquetes podrían caer en la cola de espera si el nodo de peer nunca sale de la congestión.
Secuencia de eventos que llevan a una alarma M3UA en SGSN
- SCTP envía una indicación de inicio del control de flujo a M3UA.
- SCTP envía una indicación de detención del control de flujo a M3UA.
- M3UA establece el indicador activo de congestión para la asociación y comienza a sondear SCTP periódicamente sobre su estado de control de flujo.
- Mientras una asociación se encuentra en control de flujo, M3UA coloca en cola las futuras solicitudes de datos para esa asociación hasta que se alcance QUEUE_SIZE. En ese momento, se descartan los mensajes futuros para la asociación. M3UA propaga la información de congestión de asociación a los pares remotos individuales que forman parte de la asociación.
- M3UA borra el indicador de congestión para la asociación y detiene el sondeo de SCTP.
- M3UA transmite cualquier cosa en su cola de congestión para esa asociación a SCTP.
Trampas SGSN
Tue Feb 11 07:03:12 2014 Internal trap notification 1074
(M3UAPSPCongested) ss7-routing-domain-1 peer-server-1
peer-server-process-1 (point-code-13959424) congested
Tue Feb 11 07:03:12 2014 Internal trap notification 1056
(SS7PCCongested) ss7-routing-domain-1 point-code-13959424 congested
Tue Feb 11 07:03:13 2014 Internal trap notification 1075
(M3UAPSPCongestionCleared) ss7-routing-domain-1 peer-server-1
peer-server-process-1 (point-code-13959424) congestion cleared
Tue Feb 11 07:03:13 2014 Internal trap notification 1057
(SS7PCCongestionCleared) ss7-routing-domain-1 point-code-13959424 congestion cleared
Registro de seguimiento
Peer Server Id : 2 Peer Server Process Id: 1
Association State : ESTABLISHED
Flow Control Flag : TRUE
Peer INIT Tag : 17282
SGSN INIT Tag : 3011555404
Next TSN to Assign to
Outgoing Data Chunk : 324019883
Lowest cumulative TSN acknowledged : 324019882
Cumulative Peer TSN arrived from peer : 2204328608
Last Peer TSN sent in the SACK : 2204328607
Self RWND : 1048576 <- SGSN sends
this window size
Advertised RWND in received SACK : 32 <- peer sends
this window size
Peer RWND(estimated) : 32 <- Estimated window
also goes down which cause SGSN not able to send packets on wire
Retransmission counter : 0
Zero Window Probing Flag : FALSE
Last Tsn received during ZWnd Probing : 0
Bytes outstanding on all
addresses of this association : 0
Congestion Queue Length : 0
Ordered TSN assignment Waiting QLen : 7690
Unordered TSN assignment Waiting QLen : 0
Total number of GAP ACKs Transmitted : 2
Total number of GAP ACKs Received : 2037
Solución
Siempre que se producen inestabilidades o congestión de forma continua en los links, esto indica que el nodo de peer no procesa la solicitud a tiempo debido a las solicitudes abrumadoras que vienen de SGSN, o SGSN podría recibir un número abrumador de solicitudes de la red debido a la congestión de la red o a un problema de red.
Una solución alternativa para salir de esta condición es bloquear y desbloquear los links asociados con esta congestión o inestabilidad. Otra forma es quitar y volver a agregar la instancia del proceso de señalización de pares (PSP) asociada a esta congestión o inestabilidad.
Información Relacionada