Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

GGSN Overview

The gateway GPRS support node (GGSN) converts the incoming data traffic coming from the mobile users through the Service gateway GPRS support node (SGSN) and forwards it to the relevant network, and vice versa. The GGSN and the SGSN together form the GPRS support nodes (GSN).

Understanding GGSN Redirection

Junos OS supports GPRS tunneling protocol (GTP) traffic and gateway GPRS support node (GGSN) redirection. A GGSN (X) can send create-pdp-context responses in which it can specify different GGSN IP addresses (GGSN Y and GGSN Z) for subsequent GTP-C and GTP-U messages. Consequently, the SGSN sends the subsequent GGSN tunneling protocol, control (GTP-C) and GGSN tunneling protocol, user plane (GTP-U) messages to GGSNs Y and Z, instead of X.

GGSN Pooling Scenarios Overview

The General Packet Radio Service (GPRS) tunneling protocol (GTP) supports different Gateway GPRS Support Node (GGSN) IP addresses during a tunnel creation procedure. There are two GGSN pooling scenarios that support Serving GPRS Support Node (SGSN) roaming.

Understanding GGSN Pooling for Scenario 1

In Figure 1, a packet data protocol (PDP) context request is sent from SGSN A to GGSN B during a GTP tunnel creation procedure. After sending the PDP context request message, GGSN D records the request information and it uses a different destination IP address from the request packet’s destination IP address to send the response message to SGSN A.

In this scenario, two GTP packet messages are sent to Services Processing Unit 1 (SPU1) and SPU2 by the central point, and the messages are processed by SPU1 and SPU2 individually. The session is created on SPU1 and SPU 2 for each GTP packet. SPU1 records the request packet information and SPU2 records the response packet information.

The PDP response message sent from GGSN D to SGSN A is dropped because of a lack of request information. Thus the GTP tunnel is not established.

Figure 1: GGSN Pooling Scenario 1GGSN Pooling Scenario 1
Note:

SPU2 cannot retrieve request information from SPU1.

Install Request Information to Remote SPU

In this scenario, the PDP response packet was dropped because of a lack of request information, and the GTP tunnel was not established. This can be resolved by installing the request information on the correct SPU.

In Figure 2, when creating a tunnel, the response packet's GGSN IP address changes, triggering a new session, and the central point distributes the message to another SPU.

The response packet always sends to the request packet's source address to the SPU. This helps to install the request information to the remote SPU for the next response packet.

Install the request information into the predictable SPU, HASH (req-src-ip) function while processing the request packet. After the expected SPU number (Hash (1.1.1.1) = SPU2) is calculated by the source IP address of the PDP request message, the request information is installed in the remote SPU2 through the Juniper Message Passing Interface (JMPI).

Figure 2: Functionality : GGSN Pooling Scenario 1Functionality : GGSN Pooling Scenario 1

Now the request information is installed on local SPU1 and remote SPU2, so the PDP response message is allowed.

Workarounds for Scenario 1

In scenario 1, the PDP context request message sent from SGSN A reached the Junos OS default application junos-gprs-gtp and the GTP inspection was enabled for PDP context request message. However, the PDP context response message sent from GGSN D cannot reach the Junos OS default application junos-gprs-gtp. Thus the packet will not be inspected by the GTP module.

As a workaround, you need to enable GTP inspection for the PDP context response message by configuring the custom policy and applications. See the following examples:

Understanding GGSN Pooling for Scenario 2

In Figure 3, a packet data protocol (PDP) context request is sent from SGSN A to GGSN B during a GTP tunnel creation procedure. After receiving the PDP context request message, GGSN B sends the PDP context response message to SGSN A. After receiving the PDP context response message, the GTP-C tunnel is created between SGSN C and GGSN D. Then SGSN C sends an update PDP context request message to GGSN D using different source and destination IP addresses from the request packet's IP header.

In scenario 2, the SGSN A creates the first GTP context request and sends it to the SPU by the central point. The session is created for the request packet on SPU1. The response packet sent from GGSN B to SGSN A reaches the session correctly.

The request packet sent from SGSN A indicates that GTP-C is established on control IP 1.1.1.2 and the GTP-U is established on data IP 1.1.1.3. Likewise, the response message sent from GGSN indicates that GTP-C is established on control IP 2.2.2.3 and GTP-U is established on data IP 2.2.2.4.

The GTP-C and GTP-U tunnels are created on local SPU1 after all the endpoints are established. However, the tunnel is not established on SPU 2, so the PDP update request message received from SPU2 is dropped.

Figure 3: GGSN Pooling Scenario 2GGSN Pooling Scenario 2

Install Tunnel Information to Remote SPU

In scenario 2, the update request packet is dropped because of a lack of tunnel information. This can be resolved by installing the tunnel information to the correct SPU after the request and response packets are processed. The SPU that receives the response packet installs the tunnel information on the local or remote SPU.

In Figure 4, after the tunnel is established, the control messages are sent to the control tunnel endpoint. The destination IP address of all the control messages should be the control tunnel's GGSN endpoint IP address. This helps to calculate the remote SPU number in advance for the subsequent control message.

Install the tunnel information into the predictable SPU. After the SPU number is calculated by the control tunnel GGSN endpoint IP, the tunnel information is installed in the remote SPU through JMPI.

Figure 4: Functionality : GGSN Pooling Scenario 2Functionality : GGSN Pooling Scenario 2

Now the tunnel information is installed on remote SPU2, so the PDP update response message is allowed.

Example: Configuring a GGSN Custom Policy

This example shows how to configure a Gateway GPRS Support Node (GGSN) custom policy to support GGSN pooling scenario 1.

Requirements

This example uses the following hardware and software components:

  • SRX5400 device

  • A PC

  • Junos OS Release 12.1X44-D10

Before you begin, you should be familiar with GGSN pooling scenarios. See GGSN Pooling Scenarios Overview.

Overview

In this example, you set security zones from zone ggsn and to zone sgsn. Next you set the GGSN policy name to ggsn-pool-g2s. You set the name of the match source address to ggsn-1 and the match destination address to sgsn-1.

Then you set the port based application to src_2123 and src_3386. You set the action type to permit. Then you set the application services name to gprs-gtp-profile and the GTP profile name to test. Finally, you set the default policy name to deny-all.

Configuration

Configuring a GGSN Custom Policy

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

To configure a GGSN custom policy:

  1. Configure the GGSN custom policy.

  2. Configure the source address.

  3. Configure the destination address.

  4. Configure the policy applications.

  5. Configure the activity type and specify the GTP profile name.

  6. Configure the default policy.

Results

From configuration mode, confirm your configuration by entering the show security policies command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

If you are done configuring the device, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Verifying the Configuration

Purpose

Verify that the GGSN custom policy configuration is correct.

Action

From operational mode, enter the show security command.

Sample Output
command-name

This output shows a summary of policy configuration.

Example: Configuring Custom GGSN Applications

This example shows how to configure custom applications to support GGSN pooling scenario 1.

Requirements

This example uses the following hardware and software components:

  • SRX5400 device

  • A PC

  • Junos OS Release 12.1X44-D10

Before you begin, configure the required GGSN policy. See Example: Configuring a GGSN Custom Policy.

Overview

In this example, you create applications src_2123 and src_3386 to identify source ports 2123 and 3386 for both TCP and UDP.

First you configure a custom application called src_2123.You set the application protocol to gprs-gtp-c. Then you set the networking protocol type to UDP. You set the source port to 2123 and the destination port to 0-0.

Then you configure another custom application called src_3386. You set the application protocol to gprs-gtp-v0. Then you set the networking protocol type to UDP. Finally, you set the source port to 3386 and the destination port to 0-0.

Configuration

Configuring Custom Applications

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

To configure custom policy applications:

  1. Configure the first custom application and application protocol name.

  2. Configure the networking protocol type.

  3. Configure the source port number.

  4. Configure the TCP or UDP destination port number.

  5. Configure the second custom application and application protocol name.

  6. Configure the networking protocol type.

  7. Configure the source port number.

  8. Configure the destination port number.

Results

From configuration mode, confirm your configuration by entering the show applications command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

If you are done configuring the device, enter commit from configuration mode.