ASR 5000 Series Impacto do SCTP de baixo tamanho de janela anunciado no link M3UA

Introduction

Este documento descreve o problema e a solução relacionados aos links de Camada de Adaptação de Usuário (M3UA - Message Transfer Part) de Nível 3 MTP (Message Transfer Part) que vão para um estado congestionado ou estado flap, após uma interrupção de rede principal ou atualização de software do Cisco Aggregation Services Router (ASR - ASR) Serving GPRS (General Packet Radio Service) Service Node (SGSN - General Packet Radio Service). Isso normalmente acontece em cenários de interoperabilidade em que o nó ASR 5000 está conectado a nós de terceiros, como Home Location Register (HLR) ou Radio Access Network (RNC).

Problema

O problema subjacente é que o ASR 5000 SGSN recebe um tamanho de janela pouco anunciado na camada do Protocolo de Transmissão de Controle de Fluxo (SCTP - Stream Control Transmission Protocol) do nó de peer remoto, nó do Ponto de Transferência de Sinalização (STP - Signaling Transfer Point), HLR ou RNC. O tamanho baixo da janela pode ser visto no rastreamento de captura de pacote, no comando show SCTP ou no monitoramento de rastreamento de protocolo no SGSN. Na captura de pacote, você pode ver o tamanho da janela anunciado na mensagem SCTP SACK com um valor zero ou próximo a zero. Quando isso acontece, o SGSN levanta um alarme M3UA para informar ao nó do peer que não deve enviar o pacote desse ponto de extremidade do peer. Isso faz com que o link SCTP oscile ou entre em um estado congestionado. Como o SGSN envia um tamanho de janela normal, ele continua a receber dados M3UA de nós de peer, mas esses pacotes podem ser descartados na fila de espera se o nó de peer nunca sair do congestionamento.

Sequência de eventos que levam a um alarme M3UA no SGSN

1. O SCTP envia uma indicação de início de controle de fluxo para M3UA.
2. O SCTP envia uma indicação de parada de controle de fluxo ao M3UA.
3. O M3UA define o sinalizador de congestionamento ativo para a associação e começa a pesquisar o SCTP periodicamente sobre seu status de controle de fluxo.
4. Enquanto uma associação está no controle de fluxo, o M3UA enfileira futuras solicitações de dados para essa associação até que QUEUE_SIZE seja alcançado. Nesse momento, as mensagens futuras da associação são descartadas. O M3UA propaga as informações de congestionamento de associação para os peers remotos individuais que fazem parte da associação.
5. O M3UA limpa o sinalizador de congestionamento para a associação e interrompe o polling do SCTP.
6. O M3UA transmite qualquer coisa em sua fila de congestionamento para essa associação ao SCTP.

Armadilhas 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 rastreamento

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

Solução

Sempre que oscilações ou congestionamento ocorrem continuamente nos links, essa é uma indicação de que o nó de peer não processa a solicitação em tempo devido a solicitações sobrecarregadas provenientes da SGSN, ou SGSN podem receber um número esmagador de solicitações da rede devido a um congestionamento da rede ou a um problema de rede.

Uma solução alternativa para sair dessa condição é bloquear e desbloquear os links associados a esse congestionamento ou oscilação. Outra maneira é remover e, em seguida, readicionar a instância do PSP (Peer Signaling Process) associada a esse congestionamento ou oscilação.

Informações Relacionadas

• Guia de administração do ASR5000 SGSN - Cisco Systems
• Suporte Técnico e Documentação - Cisco Systems