Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Visão geral da GGSN

O nó de suporte para GPRS de gateway (GGSN) converte o tráfego de dados de entrada vindo dos usuários móveis através do nó de suporte gprs de gateway de serviço (SGSN) e o encaminha para a rede relevante, e vice-versa. O GGSN e o SGSN juntos formam os nós de suporte para GPRS (GSN).

Entender o redirecionamento da GGSN

O Junos OS oferece suporte ao tráfego de protocolo de tunelamento GPRS (GTP) e ao redirecionamento do nó de suporte GPRS (GGSN). Um GGSN (X) pode enviar respostas de contexto create-pdp nas quais pode especificar diferentes endereços IP GGSN (GGSN Y e GGSN Z) para mensagens GTP-C e GTP-U subseqüentes. Consequentemente, a SGSN envia as seguintes mensagens de protocolo de tunelamento GGSN, controle (GTP-C) e protocolo de tunelamento GGSN, plano de usuário (GTP-U) para GGSNs Y e Z, em vez de X.

Visão geral dos cenários de agrupamento da GGSN

O protocolo de tunelamento (GTP) general Packet Radio Service (GPRS) oferece suporte a diferentes endereços IP de nó de suporte de GPRS de gateway (GGSN) durante um procedimento de criação de túnel. Existem dois cenários de agrupamento GGSN que oferecem suporte ao roaming de nó de suporte para GPRS (SGSN).

Entender o agrupamento de GGSN para o cenário 1

Na Figura 1, uma solicitação de contexto de protocolo de dados de pacotes (PDP) é enviada da SGSN A para GGSN B durante um procedimento de criação de túnel GTP. Após o envio da mensagem de solicitação de contexto PDP, a GGSN D registra as informações de solicitação e usa um endereço IP de destino diferente do endereço IP de destino do pacote de solicitação para enviar a mensagem de resposta ao SGSN A.

Nesse cenário, duas mensagens de pacote GTP são enviadas para a Unidade de Processamento de Serviços 1 (SPU1) e SPU2 pelo ponto central, e as mensagens são processadas individualmente por SPU1 e SPU2. A sessão é criada em SPU1 e SPU 2 para cada pacote GTP. O SPU1 registra as informações do pacote de solicitação e o SPU2 registra as informações do pacote de resposta.

A mensagem de resposta pdp enviada da GGSN D para SGSN A é retirada devido à falta de informações de solicitação. Assim, o túnel GTP não está estabelecido.

Figura 1: Cenário de agrupamento de GGSN 1 GGSN Pooling Scenario 1
Nota:

O SPU2 não pode recuperar informações de solicitação do SPU1.

Instale informações de solicitação à SPU remota

Nesse cenário, o pacote de resposta a PDP foi descartado por falta de informações de solicitação, e o túnel GTP não foi estabelecido. Isso pode ser resolvido instalando as informações de solicitação sobre a SPU correta.

Na Figura 2, ao criar um túnel, o endereço IP GGSN do pacote de resposta muda, desencadeando uma nova sessão e o ponto central distribui a mensagem para outra SPU.

O pacote de resposta sempre envia para o endereço de origem do pacote de solicitação para a SPU. Isso ajuda a instalar as informações de solicitação na SPU remota para o próximo pacote de resposta.

Instale as informações de solicitação na previsível função SPU, HASH (req-src-ip) enquanto processa o pacote de solicitação. Após o número de SPU esperado (Hash (10.1.1.1) = SPU2) ser calculado pelo endereço IP de origem da mensagem de solicitação de PDP, as informações de solicitação são instaladas no SPU2 remoto por meio da Interface de Passagem de Mensagens (JMPI) da Juniper.

Figura 2: Funcionalidade: Cenário de agrupamento de GGSN 1 Functionality : GGSN Pooling Scenario 1

Agora, as informações de solicitação são instaladas no SPU1 local e no SPU2 remoto, para que a mensagem de resposta do PDP seja permitida.

Soluções alternativas para o Cenário 1

No cenário 1, a mensagem de solicitação de contexto PDP enviada da SGSN A chegou ao aplicativo junos-gprs-gtp padrão Junos OS e a inspeção GTP foi habilitada para mensagem de solicitação de contexto PDP. No entanto, a mensagem de resposta ao contexto PDP enviada pelo GGSN D não pode chegar ao aplicativo junos-gprs-gtppadrão Junos OS. Assim, o pacote não será inspecionado pelo módulo GTP.

Como uma solução alternativa, você precisa habilitar a inspeção de GTP para a mensagem de resposta ao contexto PDP, configurando a política e os aplicativos personalizados. Consulte a configuração de uma política/aplicativo personalizada do GGSN.

Entender o agrupamento de GGSN para o cenário 2

Na Figura 3, uma solicitação de contexto de protocolo de dados de pacotes (PDP) é enviada da SGSN A para GGSN B durante um procedimento de criação de túnel GTP. Após receber a mensagem de solicitação de contexto PDP, a GGSN B envia a mensagem de resposta ao contexto PDP para a SGSN A. Após receber a mensagem de resposta ao contexto PDP, o túnel GTP-C é criado entre SGSN C e GGSN D. Em seguida, a SGSN C envia uma mensagem de solicitação de contexto PDP atualizada para GGSN D usando diferentes endereços IP de origem e destino a partir do cabeçalho IP do pacote de solicitação.

No cenário 2, o SGSN A cria a primeira solicitação de contexto GTP e a envia à SPU pelo ponto central. A sessão é criada para o pacote de solicitação no SPU1. O pacote de resposta enviado de GGSN B para SGSN A chega à sessão corretamente.

O pacote de solicitação enviado pelo SGSN A indica que o GTP-C está estabelecido no CONTROLE IP 10.1.1.2 e o GTP-U está estabelecido nos dados IP 10.1.1.3. Da mesma forma, a mensagem de resposta enviada pelo GGSN indica que o GTP-C está estabelecido no controle do IP 10.2.2.3 e o GTP-U está estabelecido nos dados IP 10.2.2.4.

Os túneis GTP-C e GTP-U são criados no SPU1 local após todos os endpoints serem estabelecidos. No entanto, o túnel não está estabelecido na SPU 2, de modo que a mensagem de solicitação de atualização de PDP recebida da SPU2 é retirada.

Figura 3: Cenário de agrupamento de GGSN 2 GGSN Pooling Scenario 2

Instale informações de túnel na SPU remota

No cenário 2, o pacote de solicitação de atualização é descartado devido à falta de informações de túnel. Isso pode ser resolvido instalando as informações do túnel na SPU correta após o processamento da solicitação e dos pacotes de resposta. A SPU que recebe o pacote de resposta instala as informações do túnel na SPU local ou remota.

Na Figura 4, após a criação do túnel, as mensagens de controle são enviadas para o endpoint do túnel de controle. O endereço IP de destino de todas as mensagens de controle deve ser o endereço IP de endpoint GGSN do túnel de controle. Isso ajuda a calcular o número de SPU remoto com antecedência para a mensagem de controle subseqüente.

Instale as informações do túnel na SPU previsível. Após o número de SPU ser calculado pelo IP de endpoint GGSN do túnel de controle, as informações do túnel são instaladas na SPU remota por meio do JMPI.

Figura 4: Funcionalidade: Cenário de agrupamento de GGSN 2 Functionality : GGSN Pooling Scenario 2

Agora, as informações do túnel são instaladas no SPU2 remoto, para que a mensagem de resposta de atualização do PDP seja permitida.

Exemplo: configurar uma política e aplicativo personalizados do GGSN

Este exemplo mostra como configurar uma política e aplicativo personalizados de nó de suporte para GPRS de gateway (GGSN) para oferecer suporte ao cenário de agrupamento GGSN 1.

Requisitos

Este exemplo usa os seguintes componentes de hardware e software:

  • Dispositivo SRX5400

  • Um PC

  • Versão do Junos OS 12.1X44-D10

Configuração

Configuração de uma política personalizada de GGSN

Visão geral

Este exemplo mostra como configurar políticas de segurança para o tráfego GTP, o que fará o tráfego funcionar caso o agrupamento GTP ocorra. Esse mesmo exemplo também fará o tráfego GTP fluir corretamente quando o recurso de distribuição GTP estiver habilitado, com ou sem inspeção de GTP. O que fazemos aqui é configurar as políticas de segurança em ambas as direções, espelhadas. Em ambas as direções, usamos os mesmos objetos de endereço e os mesmos aplicativos. Além do aplicativo GTP regular junos-gprs-gtp, criamos um aplicativo GTP reverso personalizado, chamado reverso junos-gprs-gtp. Este aplicativo GTP reverso fará com que os pacotes GTP correspondam à política de segurança, mesmo quando apenas a porta UDP de origem for uma porta GTP bem conhecida. Dessa forma, todo o tráfego GTP será compatível com as políticas e tratado corretamente como tráfego GTP.

Configuração rápida da CLI

Para configurar rapidamente este exemplo, copie os seguintes comandos, cole-os em um arquivo de texto, remova quaisquer quebras de linha, altere todos os detalhes necessários para combinar com sua configuração de rede, copiar e colar os comandos na CLI no nível de [edit] hierarquia e, em seguida, entrar no commit modo de configuração.

Caso o recurso GTP Distribution seja usado sem a inspeção do GTP, não crie o perfil GTP e não aplique o perfil gtp de serviços de aplicativo às políticas de segurança.

Procedimento passo a passo

Para configurar uma política personalizada de GGSN:

  1. Configure o endereço de origem.

  2. Configure o endereço de destino.

  3. Configure os aplicativos de política.

  4. Configure o tipo de atividade e especifique o nome do perfil GTP.

    Caso o recurso de distribuição GTP seja usado sem a inspeção do GTP:

  5. Configure o mesmo novamente, com as zonas de segurança confiáveis e invertidas não confiáveis.

Resultados

A partir do modo de configuração, confirme sua configuração entrando no show security policies comando. Se a saída não exibir a configuração pretendida, repita as instruções de configuração neste exemplo para corrigi-la.

Antes de confirmarmos a configuração, precisamos configurar o aplicativo GTP reverso.

Configuração de aplicativo GTP reverso

Ao usar o recurso GTP Distribution , as sessões de fluxo serão definidas como unidirecionais. Essa ação para defini-los como unidirecionais é realizada pelo GTP ALG (mesmo quando não usa o GTP Inspection). Por isso, é necessário que o GTP ALG seja aplicado a todo o tráfego GTP.

O aplicativo predefinido junos-gprs-gtp está configurado com o GTP ALG. No entanto, em alguns casos, o tráfego GTP pode não coincidir com este aplicativo, o que será o caso do tráfego de devolução quando uma porta de origem diferente foi usada do que as portas GTP UDP padrão. Nesse caso, a asa de sessão reversa pode ter uma porta de destino aleatória e a porta GTP padrão como porta de origem. Para garantir que o GTP ALG seja aplicado a esse tráfego GTP reverso neste caso, é necessário adicionar o seguinte aplicativo GTP 'reverso' a todas as políticas de segurança GTP.

Configuração rápida da CLI

Para configurar rapidamente este exemplo, copie os seguintes comandos, cole-os em um arquivo de texto, remova quaisquer quebras de linha, altere todos os detalhes necessários para combinar com sua configuração de rede, copiar e colar os comandos na CLI no nível de [edit] hierarquia e, em seguida, entrar no commit modo de configuração.

Verificação

Confirme que a configuração está funcionando corretamente.

Verificando a configuração

Propósito

Verifique se a configuração de política personalizada do GGSN está correta.

Ação

Comprometa a configuração e a saída. Do modo operacional, entre no show security policies comando.

Saída de amostra
nome de comando

Esta saída mostra um resumo da configuração da política.