Contents

Introduction

Problema

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

Armadilhas SGSN

Registro de rastreamento

Solução

Informações Relacionadas

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