Impacto de la serie ASR 5000 del tamaño de ventana baja anunciada de SCTP en el enlace M3UA

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

1. SCTP envía una indicación de inicio del control de flujo a M3UA.
2. SCTP envía una indicación de detención del control de flujo a M3UA.
3. 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.
4. 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.
5. M3UA borra el indicador de congestión para la asociación y detiene el sondeo de SCTP.
6. 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

• Guía de administración de SGSN ASR5000 - Cisco Systems
• Soporte Técnico y Documentación - Cisco Systems