Cisco GGSN Release 9.2 Configuration Guide, Cisco IOS Release 12.4(22)YE3

Configuring GGSN GTP Session Redundancy

This chapter describes how to configure GPRS Tunneling Protocol session redundancy (GTP-SR) between two Cisco Gateway GPRS Support Nodes (GGSNs).

Note The Cisco GGSN supports GTP-SR for IPv4 Packet Data Protocol (PDP) contexts only.

For complete descriptions of the GGSN commands in this chapter, refer to the Cisco GGSN Command Reference.

To locate documentation of other commands that appear in this chapter, use the command reference master index or search online. See the "Related Documents" section on page 2-11 for a list of other Cisco IOS software documentation that might be helpful when configuring the GGSN.

This chapter includes the following sections:

•GTP-SR Overview

•Enabling GTP Session Redundancy

•Disabling GTP Session Redundancy

•Configuring Charging-Related Synchronization Parameters

•Monitoring and Maintaining GTP-SR

•Upgrading GGSN Images in a GTP-SR Environment

•Configuration Examples

GTP-SR Overview

The GTP-SR supported by the Cisco GGSN enables two GGSNs configured on separate Cisco Service and Application Module for IP (SAMI) modules to appear as one network entity. If one of the GGSNs in a redundant configuration fails, GTP-SR ensures that continuous service is provided to mobile subscribers.

In a GTP-SR configuration, the active GGSN establishes and terminates PDP sessions, and sends the required stateful data to the standby GGSN. To stay current on the states of active PDP sessions, the standby GGSN receives the stateful data sent by the active GGSN. When the standby GGSN detects that the active GGSN has failed, it becomes active, and assumes the responsibilities of the active GGSN.

The Cisco GGSN software uses the Cisco IOS Hot Standby Routing Protocol (HSRP), the Cisco IOS Check-point Facility (CF) and Redundancy Framework (RF), and the Stream Control Transmission Protocol (SCTP) to support Layer 2 (L2) local GTP-SR and Layer 3 (L3) geographical GTP-SR (remote redundancy) implementations.

Note Before GTP-SR can be enabled on redundant GGSNs, a GTP-SR interdevice infrastructure must be configured between the GGSNs. For information on configuring the GTP-SR interdevice infrastructure, see the "Configuring the GTP Session Redundancy Interdevice Infrastructure" section.

In the GTP-SR configuration examples (Figure 5-1 and Figure 5-2), note the following:

•The components of GTP-SR are active and standby operation modes, stateful session synchronization, and switchover event detection and recovery.

•Active and standby operation

–The GGSN is active or standby based on configuration.

–For geographical redundancy implementations, the active GGSN receives packets based on route advertisement via a routing protocol. For local redundancy implementations, the active GGSN receives packets based on MAC address insertion.

–The active GGSN processes control messages and tunnels subscriber data traffic.

–The standby GGSN maintains session states and forwarding entries to minimize data loss.

•Stateful session sychronization

–Session persistence is maintained for switchover

–1-to-1 stateful session synchronization is supported

–The active GGSN downloads all sessions to standby GGSN

–For maximum network bandwidth efficiency, only the changed states and bundling events are delivered in messages.

–Reliable transport is used for sychnronization

Figure 5-1 illustrates a local GTP-SR implementation.

Figure 5-1 Local GTP-SR Implementation

Local GTP-SR Notes

•L2 HSRP provides local GTP-SR support.

•Active GGSN and standby GGSN are located in the same local site (on the same LAN).

•Active and standby GGSNs are configured to participate in the same local HSRP group.

•HSRP transport is L2-based multicasting.

Figure 5-2 illustrates a geographical GTP-SR implementation.

Figure 5-2 Geographical GTP-SR Implementation

Geographical GTP-SR Notes

•L3 HSRP provides geographical GTP-SR support.

•Active GGSN and standby GGSN are located in geographically separate locations that are connected over a WAN.

•Active and standby GGSNs are configured to participate in the same geographical HSRP group.

•HSRP transport is IP unicast routing. This requires that the unicasting IP addresses be routable between the two locations.

•L2 and L3 HSRP are mutually exclusive, therefore, when L3 HSRP is enabled, L2 HSRP is automatically disabled.

•Only an active GGSN should advertises routes using the Open Shortest Path First (OSPF) as the Interior Gateway Protocol (IGP), therefore, GGSN interfaces must be configured not to form OSPF adjacency when functioning as a standby GGSN.

Prerequisites

GTP-SR on the Cisco GGSN requires the following:

•Two Cisco 7600 series routers in which a Cisco Supervisor Engine 720 (Sup720) and RSP, with a Multilayer Switch Feature Card (Cisco Product ID: SUP720-MSFC3-BXL) is installed.

For local redundancy, the Sup720 must be running Cisco IOS Release 12.2(33)SRB1 or later. For geograhpical redundancy, the Sup720 must be running Cisco IOS Release 12.2(33)SRC or later.

•Two Cisco SAMIs in each of the Cisco 7600 series routers. The Cisco SAMI processors must be running the same Cisco GGSN release; Cisco IOS Release 12.4(15)XQ or later for local redundancy, or Cisco IOS Release 12.4(22)YE1 for geographical redundancy.

•HSRP Version 2.

•Except for certain protocol-related configurations that need to be distinct, such as the IP addresses of the HSRP-enabled interfaces and the remote IP addresses in the SCTP configuration, the active GGSN and the standby GGSNs must have the same configuration. Each configuration must be completed in the same order on both GGSNs in the GTP-SR configuration.

•When loading or upgrading a new Cisco GGSN image, both GGSNs must be loaded (virtually) together.

•On the serving GPRS support node (SGSN), the values configured for the number of GTP N3 requests and T3 retransmissions must be larger than the value or the switchover timer. This configuration enables requests sent during a switchover to be serviced by the newly active GGSN rather than dropped.

•Using the ip radius source-interface command in global configuration mode, RADIUS must be configured to use the IP address of a specified interface for all outgoing RADIUS packets.

Limitations and Restrictions

Before configuring GTP-SR, note the following limitations and restrictions:

•PDP Contexts —Redundancy is not supported for the following types of PDP contexts. With a switchover, these PDP contexts require reestablishment on the newly active GGSN.

–IPv6 PDPs

–PPP type PDPs

–PPP regeneration / L2TP access PDPs

–Network initiated PDPs

•Timers—Except for the session timer, GGSN timers are not synchronized with the standby GGSN. When a switchover occurs, the timers on the newly active GGSN are incrementally restarted. Incrementally restarting the timers prevents them from expiring simultaneously.

When a PDP context is re-created on the standby GGSN, the session timer is restarted with the elapsed time subtracted from the value of the initial session timer. Once the session expires on the standby GGSN, the PDP context is deleted.

•Counters—If a switchover occurs, status counters such as "cgprsAccPtSuccMsActivatedPdps," and some statistics counters have a non-zero value that is the value of the counter when the switchover occurred. All other counters are reset to zero.

If a GGSN reload occurs, all counters are set back to zero.

•Sequence numbers related to GTP signaling and data are not synchronized between the active GGSN and the standby GGSN.

•Charging—All pertinent information for establishing charging on the standby GGSN for a PDP context is synchronized; however, the user data related charging information for a PDP context is not sychronized. Therefore, all CDRs in the previously active GGSN that were not sent to the charging gateway are lost when a switchover occurs.

•Once a GTP-SR configuration is established between two GGSNs, modifying the configuration of one of the GGSNs might cause the GGSN to reload before the changes can be saved. To ensure that configuration changes are not lost, disable GTP-SR before modifying the configuration of a GGSN. For information on disabling GTP-SR, see the "Disabling GTP Session Redundancy" section.

•In a GTP session redundancy (GTP-SR) environment, do not use the clear gprs gtp pdp-context command on the standby GGSN. If you issue this command on the standby GGSN, you are prompted to confirm before the command is processed. To determine if the redundancy state of a GGSN is active or standby, use the show gprs redundancy command.

•When configuring geographical redundancy, note the following:

–L2 and L3 HSRP are mutually exclusive.

–Migrating from L2 to an L3 HSRP configuration requires a system reload.

–When using L3 HSRP, the Cisco Content Services Gateway - 2nd Generation does not switch over when the Cisco GGSN switches over, therefore, the user might be overcharged.

–Cisco IOS Release 12.2(33)SRC has a per-chassis limitation of 1000 Border Gateway Protocol (BGP) peers or 1000 OSPF neighbors, therefore, per GGSN on a Cisco SAMI PPC, 160 BGP peers or 160 OSPF neighbors.

–The source interfaces (RADIUS, charging, Diameter, etc.) must be configured with the same IP address on both the active and standby GGSNs, and be distributed through the OSPF routing protocol .

Enabling GTP Session Redundancy

To configure GTP-SR, complete the tasks, in the order in which they are presented, in the following sections:

•Configuring the GTP Session Redundancy Interdevice Infrastructure

•Configuring Passive Route Suppression on an Interface

•Enabling GTP-SR on the GGSN

Configuring the GTP Session Redundancy Interdevice Infrastructure

The GTP-SR feature uses the Cisco IOS CF to send stateful data over SCTP to a redundantly configured GGSN. In addition, the Cisco GGSN uses the Cisco IOS RF in conjunction with Cisco IOS HSRP to monitor and report transitions on active GGSNs and standby GGSNs.

To configure the GTP-SR interdevice infrastructure before enabling GTP-SR on redundant GGSNs, complete the tasks in the following sections

•Configuring HSRP

•Enabling Interdevice Redundancy

•Configuring the Interdevice Communication Transport

Configuring HSRP

The HSRP is a protocol typically used for redundancy. The HSRP provides high network availability because it routes IP traffic from hosts on networks without relying on the availability of any single router.

In a group of routers, the HSRP is used for selecting an active router and a standby router. The HSRP monitors both the inside and outside interfaces so that if any interface goes down, the whole device is deemed to be down. When a device is deemed to be down, the standby device becomes active and takes over the responsibilities of an active device.

Specifically, the HSRP provides the following:

•Dynamic active and standby role selection

•Heartbeat for failure detection

•Method to receive packets only on the active GGSN

To support Layer 3 geographical redundancy, the HSRP has enhanced these three functions as follows:

•Role selection is based on IP unicast routing instead of link-local multicast

•Heartbeat is also an IP unicast message between peers instead of link-local multicast, and triggers active GGSN to advertise routes

•Routes for GGSN IP address and subscriber networks are advertised (by active GGSN) instead of listening to a virtual MAC address for directing traffic to the active GGSN.

Note In HSRP, the virtual IP address and MAC address are used for receiving packets. These addresses are unnecessary when routing is used for L3 geographical redundancy. Therefore, when implementing L3 geographical redundancy, the virtual IP address in the HSRP group is set to zero.

Restrictions and Recommendations

When configuring HSRP, the following recommendation and restrictions apply:

•At minimum, HSRP must be enabled and an HSRP primary group defined on one interface per GGSN instance. Each additional HSRP interface on the GGSN with its own separate VLAN can be configured as a client group.

The client group feature enables all interfaces configured as a client group to share the HSRP parameters of the primary group. This facilitates HSRP group setup and maintenance in environments that contain numerous GGSN interfaces and HSRP groups. The primary group and associated client groups share the same group track states and have the same priority.

Typically, HSRP groups are needed on the following interfaces. One group is configured as the primary group and the rest as client groups. Each interface must be configured on a different VLAN.

–Gn interface—primary group

–Ga interface—client group

–DHCP (can be shared with the Gi interface)—client group

–Gi APN (per VRF)—client group

–RADIUS—client group

–Diameter—client group

–Quota Server—client group

To configure additional interfaces as a HSRP client group, use the standby interface configuration command and specify the follow keyword option with the same group number as the primary group.

•Use the same group number that is used for the primary group for each client group. Using the same group number for the primary group and client groups facilitates HSRP group setup and maintenance in an environment that contains numerous GGSN interfaces and HSRP groups.

•The same HSRP group cannot be used on another active/standby GGSN pair mapped to the same physical VLAN.

•When HSRP is configured on an interface, a preemption delay can be configured using the standby preempt interface configuration command; however, in a GTP-SR configuration, we recommend not configuring a preemption delay unless absolutely necessary. Not configuring a preemption delay prevents any unnecessary switchovers. If a preemption delay must be configured, ensure that a sufficient delay is specified so that bulk synchronization can complete before preemption takes effect.

•When implementing local redundancy, when the standby use-bia command is not used to allow bridges and gateways to learn the virtual MAC address, for optimization purposes, configure the standby mac-refresh command to a value greater than the default. By default, hello messages are sent every 3 seconds under the main interface (gig 0/0). Once configured, all HSRP groups (primary and follow) will send hello messages only if the node is in active mode.

Note A GGSN reloads if additional HSRP configurations are added after the initial HSRP setup is configured.

For complete information on configuring Cisco IOS HSRP, see the "Configuring the Hot Standby Router Protocol" section of the Cisco IOS IP Configuration Guide, Release 12.3.

Enabling L2 HSRP and Configuring a Local HSRP Primary Group on an Interface

L2 HSRP is the default HSRP. L2 HSRP supports local redundancy (redundancy between two Cisco GGSNs on the same LAN).

To enable L2 HSRP on an interface and configure the primary group, use the following commands in interface configuration mode:

The following is an example of a L2 HSRP configuration:

interface GigabitEthernet0/0.7

 encapsulation dot1Q 21

 ip address 172.2.2.1 255.255.0.0

 standby 1 ip 172.2.2.10

 standby 1 name local

Enabling L3 HSRP and Configuring a Geographical HSRP Primary Group on an Interface

L3 HSRP supports geographical redundancy. Geographical redundancy is redundancy between two Cisco GGSNs located in geographically separate locations, connected by a WAN.

In a geographical redundancy implementation, only the active device needs to send routing updates. Therefore, when configuring an L3 HSRP group, you must also configure the interfaces to not send routing updates when the GGSN is the standby GGSN. For information on enabling passive route suppression see "Configuring Passive Route Suppression on an Interface" section.

To enable L3HSRP on an interface and configure the primary group, use the following commands in interface configuration mode:

The following is an example of an L3 HSRP configuration:

Primary GGSN

interface GigabitEthernet0/0.7

 encapsulation dot1Q 21

 ip address 10.0.0.3 255.255.0.0

 standby 1 ip none

 standby 1 name geo

 standby 1 unicast destination 172.0.0.1

Standby GGSN

interface GigabitEthernet0/0.8

 encapsulation dot1Q 21

 ip address 172.0.0.1 255.255.0.0

 standby 1 ip none

 standby 1 name geo

 standby 1 unicast destination 10.0.0.3

Configuring HSRP Client Groups

Once HSRP is enabled and the primary group is configured on a GGSN interface, additional GGSN interfaces can be configured to share the HSRP parameters of the primary group by configuring those interfaces as HSRP client groups.

To configure a GGSN interface as an client group, use the standby command and specify the follow keyword option using the same group number and name as the primary group.

Interfaces that share a group track states together and have the same priority.

Note HSRP group parameters such as priority, name, tracking, and timers are configured under the primary group only. Do not configure these parameters under client groups because the groups inherit them from the primary group.

To configure an interface to follow a primary group, use the following commands in interface configuration mode:

Enabling Interdevice Redundancy

The HSRP primary group is associated with Cisco IOS RF to enable session redundancy between two GGSNs.

To enable interdevice redundancy, use the following commands, beginning in global configuration mode:

Configuring the Interdevice Communication Transport

Interdevice redundancy requires a transport for communication between the redundant GGSNs. This transport is configured using Interprocess Communication (IPC) commands.

To configure the interdevice communication transport between the two GGSNs, use the following commands, beginning in global configuration mode:

To remove an association, use the no form of the command.

Configuring Passive Route Suppression on an Interface

In a geographical redundancy implementation, only the active GGSN advertises routes. Therefore, interfaces must be configured to stop redistributing routes when the GGSN become a standby GGSN.

To configure passive route suppression on an interface, use the following command while in router configuration mode:

In the following example, two GigabitEthernet interfaces are configured to suppress routing updates when the GGSN is the standby GGSN:

router ospf 100

 router-id 30.30.30.30

 no log-adjacency-changes

 redistribute static subnets

 passive-interface GigabitEthernet0/0.100 on-standby

 network 10.0.0.0 0.0.0.255 area 0

 network 1.1.1.10.0.0.0 area 0

!

router ospf 200 vrf Gi-VRF

 no log-adjacency-changes

 redistribute static route-map xxx

 passive-interface GigabitEthernet0/0.200 on-standby

 network 11.0.0.0 0.0.0.255 area 1

Enabling GTP-SR on the GGSN

To enable GTP-SR, use the following command in global configuration mode on each of the redundant GGSNs:

Disabling GTP Session Redundancy

To disable GTP-SR (at both the GGSN application level and the interdevice infrastructure level), complete the following tasks in the order in which they are listed. Ensure that the GGSN is in standby mode when you start these tasks.

1. Verify that the GGSN is in standby mode and disable the GGSN application-level redundancy.

Router(config)# show gprs redundancy

...

Router(config)# no gprs redundancy

The GGSN becomes a standalone active GGSN.

2. Remove the standby scheme configured under interdevice configuration mode.

Router(config)# redundancy inter-device

Router(config-red-interdevice)# no scheme standby HSRP-Gn

3. Save the configuration changes to memory.

Router(config)# write memory

4. Reload the router.

Router# reload

Once the GGSN comes back up, additional configuration changes can be made and saved without the GGSN reloading.

5. Disable SCTP by disabling the association between the two devices and deconfiguring SCTP.

Router(config)# ip zone default

Router(config-ipczone)# association 1

Router(config-ipczone-assoc)# shutdown

...

Router(config-ipczone-assoc)# no protocol sctp

6. To remove the HSRP configuration associated with an interface, use the no forms of the relevant HSRP commands. Remove the HSRP group configuration for the client groups first.

Router(config)# interface GigabitEthernet0/0.56001

Router(config-if)# no standby 52 ip 172.90.1.52

Router(config-if)# no standby 52 follow HSRP-Gn

Router(config-if)# no standby version 2

Router(config-if)# exit

Router(config)# interface GigabitEthernet0/0.401

Router(config-if)# no standby 52 ip 192.1268.1.52

Router(config-if)# no standby 52 name HSRP-Gn

Router(config-if)# no standby version 2

Router(config-if)# exit

7. Save configuration changes to memory:

Router(config)# write memory

Configuring Charging-Related Synchronization Parameters

Charging-related data necessary to establish charging for a PDP context is synchronized with the standby GGSN. This data includes:

–Charging Identity (CID) associated with a PDP context

–Local sequence number

–Record sequence number

–GTP' sequence number

–Per service local sequence number

Note For geographical redundancy, you must configure the charging source interface with the same IP address on boththe active and standby GGSNs, and the address should be distributed via the OSPF routing protocol.

Charging Identity (CID) and Local Record Sequence Number

When an established PDP context is synchronized, the CID assigned to the PDP context's call detail record (CDR) is also synchronized with the standby GGSN. When the standby GGSN receives the synchronized data for the PDP context, if the CID value provided is greater than the current value of the global CID counter, the standby GGSN writes the value to the global CID counter. If a switchover occurs, the newly active GGSN starts from the latest CID value that was written, plus a window/offset for all new PDP contexts created on the newly active GGSN.

When the CID timer of the active GGSN expires, and the active GGSN writes the global CID counter value to memory, the CID value and local record sequence (if configured) are synchronized with the standby GGSN, and the standby GGSN writes the information to memory. If the local sequence number is also configured, when the write timer associated with the local sequence number expires, both the CID and the local sequence number are synchronized with the standby GGSN. When the standby GGSN becomes active, it uses the local record sequence number, plus the latest CID value written to memory, plus a window/offset for subsequent PDP contexts created on the newly active GGSN.

Record Sequence Number

The charging gateway uses the record sequence number to detect duplicate CDRs associated with a PDP context.

To minimize the amount of data being synchronized with the standby GGSN, the record sequence number is not synchronized each time a CDR is closed. Instead, a window threshold for the record sequence number is synchronized each time a CDR closes.

The current value of the record sequence number and the record number last synchronized for a PDP context are checked. If the difference in their values is the value configured for the window size, the current record sequence number is synchronized with the standby GGSN. When a standby GGSN becomes the active GGSN, it starts from the last value synchronized plus the window size.

To configure the window size that determines when the CDR record sequence number is synchronized with the standby GGSN, use the following command in global configuration mode:

GTP' Sequence Number

The charging gateway uses the GTP' sequence number to prevent the duplication of packets. The GGSN sends encoded CDRs associated with a PDP context in a GTP packet to the charging gateway. If the charging gateway acknowledges the GTP packet, it removes the packet from memory. If it is not acknowledged, it is retransmitted. The charging gateway cannot acknowledge GTP packets if the sequence number repeats.

To minimize the amount of data being synchronized with the standby GGSN, the GTP' sequence number is not synchronized each time a CDR is closed. Instead, a window threshold for the GTP' sequence number is synchronized each time a CDR message is sent. The current value of the GTP' sequence number and the GTPP sequence number last synchronized for a PDP context are checked. If the difference in their values is the value configured for the window size, the GTP prime sequence number is synchronized with the standby GGSN. When a standby GGSN becomes the active GGSN, it starts from the last value synchronized plus the window size.

To configure the window size that determines when the GTP' sequence number is synchronized with the standby GGSN, use the following command in global configuration mode:

Per Service Local Sequence Number

The charging gateway uses the per service local sequence number to detect duplicate service containers associated with a PDP context.

To minimize the amount of data being synchronized to the standby GGSN, the per service local sequence number is not synchronized each time an eG-CDR is closed. Instead, the current value of the local sequence number and the local sequence number last synchronized for a PDP context is checked, and if the difference is more than the configured window size, the current local sequence number is synchronized with the standby GGSN. When a standby GGSN becomes the active GGSN, it starts from the last value synchronized, plus the window size.

To configure the window size that determines when the per service local sequence number is synchronized with the standby GGSN, use the following command in global configuration mode:

Monitoring and Maintaining GTP-SR

The following privileged EXEC show commands can be used to monitor the different elements of the GTP-SR configuration.

Upgrading GGSN Images in a GTP-SR Environment

To upgrade to a new Cisco GGSN image on the Cisco SAMI, complete the following tasks:

1. Identify all application entities (GGSN images) on the SAMI by using the show version command on the LCP (PPC0) console.

2. Using the Cisco IOS SLB no inservice command, remove all GGSNs on the Cisco SAMI processors from the GTP server load balancing (SLB) list on the supervisor. This prevents a GGSN from receiving new Create PDP Context requests, but allows it to continue servicing existing PDP contexts.

3. Wait until all PDP contexts are cleared or manually clear PDP contexts by using the clear gprs gtp pdp-context command.

4. Load the new images onto the SAMI, and reset the SAMI as described in the Cisco Service and Application Module for IP User Guide.

5. Once the images have been reloaded, return the GGSNs to the GTP SLB list by using the Cisco IOS SLB inservice command on the supervisor.

For complete information on upgrading application images on the Cisco SAMI, see the Cisco Service and Application Module for IP User Guide.

Configuration Examples

This section provides the following configuration examples:

•Local GTP-SR Examples

•Geographical GTP-SR Examples

Note The following configurations examples are just samples of configurations. Actual configurations vary based on network design.

Local GTP-SR Examples

This section contains the following configuration examples from a local GTP-SR implementation:

•Primary Supervisor Configuration Example

•Primary GGSN Configuration Example

•Secondary GGSN Configuration Example

Primary Supervisor Configuration Example

The following example shows part of a sample configuration on the Primary Supervisor. Some commands that you use to configure GTP-SR are highlighted in bold text.

sup-primary# show running-config 

Building configuration...

Current configuration : 7144 bytes

!

! Last configuration change at 12:28:26 UTC Tue Oct 21 2003

! NVRAM config last updated at 13:32:08 UTC Thu Oct 16 2003

!

version 12.2

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname sup-primary

!

...

!

svclc multiple-vlan-interfaces  
svclc module 7 vlan-group 71,73  
svclc vlan-group 71 71 svclc vlan-group 73 95,100,101

ip subnet-zero

!

no ip domain-lookup

!

interface GigabitEthernet2/1

 description "VLAN for Inter-dev SCTP"

 no ip address

 switchport

 switchport access vlan 498

 switchport mode access

 no cdp enable

!

...

!

interface FastEthernet3/25

 description "VLAN for Gn"

 no ip address

 duplex full

 switchport

 switchport access vlan 410

 switchport mode access

 no cdp enable

!

interface FastEthernet3/26

 description "VLAN for Gi"

 no ip address

 duplex full

 switchport

 switchport access vlan 420

 switchport mode access

!

...

!

interface Vlan1

 no ip address

 shutdown

!

interface Vlan410

 description "Virtual LAN for Gn interface for all GGSNs on an SAMI"

 ip address 10.20.21.1 255.255.255.0

 no ip redirects

!

interface Vlan420

 description "One Gi Vlan all GGSN images of mwmam"

 ip address 10.20.51.1 255.255.255.0

 no ip redirects

!

interface Vlan498

 description "VLAN for Inter-dev_SCTP"

 ip address 10.70.71.1 255.255.255.0

!

router ospf 1

 router-id 10.20.1.2

 log-adjacency-changes

 summary-address 10.20.30.0 255.255.255.0

 redistribute static subnets route-map GGSN-routes

 network 10.20.1.0 0.0.0.255 area 1

!

ip classless

ip route 0.0.0.0 0.0.0.0 128.107.234.100

ip route 1.8.0.0 255.255.0.0 1.8.0.1

ip route 1.12.0.0 255.255.0.0 1.12.0.1

ip route 10.2.5.0 255.255.255.0 10.2.15.1

ip route 10.20.30.11 255.255.255.255 10.20.21.81

ip route 10.20.30.12 255.255.255.255 10.20.21.82

ip route 10.20.30.13 255.255.255.255 10.20.21.83

ip route 10.20.30.14 255.255.255.255 10.20.21.84

ip route 10.20.30.15 255.255.255.255 10.20.21.85

ip route 110.1.0.0 255.255.0.0 10.20.51.91

ip route 120.1.0.0 255.255.0.0 10.20.51.92

ip route 128.107.241.185 255.255.255.255 128.107.234.161

ip route 130.1.0.0 255.255.0.0 10.20.51.93

ip route 140.1.0.0 255.255.0.0 10.20.51.94

ip route 150.1.0.0 255.255.0.0 10.20.51.95

ip route 172.19.23.55 255.255.255.255 172.19.24.1

ip route 223.0.0.0 255.0.0.0 1.8.0.1

ip route 223.0.0.0 255.0.0.0 1.12.0.1

no ip http server

no ip http secure-server

ip pim bidir-enable

!

!

access-list 1 permit 10.20.30.0 0.0.0.255

access-list 101 permit ip 128.107.234.160 0.0.0.31 any

access-list 102 permit ip any 128.107.234.160 0.0.0.31

arp 127.0.0.22 0000.2200.0000 ARPA

!

route-map GGSN-routes permit 10

 match ip address 1

!

!         

line con 0

 exec-timeout 0 0

 logging synchronous

line vty 0 4

 exec-timeout 0 0

 password abc

 logging synchronous

 transport input lat pad mop telnet rlogin udptn nasi

line vty 5 15

 exec-timeout 0 0

 password abc

 logging synchronous

!

ntp master

end

sup-primary#

Primary GGSN Configuration Example

Active_GGSN# show running-config 

Building configuration...

Current configuration : 2942 bytes

!

version 12.3

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

service gprs ggsn

no service dhcp

!

hostname Act_GGSN

!

...

!

redundancy inter-device

 scheme standby Gn

!

ipc zone default

 association 1

  no shutdown

  protocol sctp

   local-port 5000

    local-ip 10.70.71.5

    keepalive 3000

    retransmit-timeout 300 10000

    path-retransmit 10

    assoc-retransmit 20

   remote-port 5000

    remote-ip 10.70.71.9

!

no aaa new-model

ip subnet-zero

!

!

no ip cef

no ip domain lookup

!

!

interface Loopback1

 description VT address of processor3:GGSN"

 ip address 10.20.30.12 255.255.255.255

!

interface Loopback2

 description "Loopback of GTP-SLB for dispatch mode"

 ip address 10.20.30.91 255.255.255.255

!

interface GigabitEthernet0/0

 no ip address

 standby use-bia

!

interface GigabitEthernet0/0.3

 description "VLAN for Gn interface of UMTS"

 encapsulation dot1Q 410

 ip address 10.20.21.52 255.255.255.0

 no ip mroute-cache

 no keepalive

 no cdp enable

 standby version 2 

 standby 7 ip 10.20.21.82

 standby 7 priority 190

 standby 7 name Gn

!

interface GigabitEthernet0/0.31

 description "VLAN for Gi interface of UMTS"

 encapsulation dot1Q 420

 ip vrf forwarding internet

 ip address 10.30.21.52 255.255.255.0

 standby 7 follow Gn

 standby 7 ip 10.30.21.82

!

interface GigabitEthernet0/0.71

 description "VLAN for inter-dev_SCTP"

 encapsulation dot1Q 498

 ip address 10.70.71.5 255.255.255.0

!

interface Virtual-Template1

 ip unnumbered Loopback1

 no ip redirects

 encapsulation gtp

 gprs access-point-list gprs

!

ip local pool APN1 110.1.0.1 110.1.10.255

ip classless

no ip http server

!

gprs access-point-list gprs

  access-point 1

   access-point-name apn1

   ip-address-pool local APN1

!

gprs gtp path-echo-interval 0

!

gprs charging disable

gprs redundancy

!

!

...

!

!

end

Active_GGSN-3#

Secondary GGSN Configuration Example

Standby_GGSN# show running config

Building configuration...

Current configuration : 2823 bytes

!

version 12.3

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Stby_GGSN

!

service gprs ggsn

!

...

!

redundancy inter-device

 scheme standby Gn

!

ipc zone default

 association 1

  no shutdown

  protocol sctp

   local-port 5000

    local-ip 10.70.71.9

    keepalive 3000

    retransmit-timeout 300 10000

    path-retransmit 10

    assoc-retransmit 20

   remote-port 5000

    remote-ip 10.70.71.5

!

no aaa new-model

ip subnet-zero

!

!

no ip cef

!!

interface Loopback1

 description VT address of processor3:GGSN"

 ip address 10.20.30.12 255.255.255.255

!

interface Loopback2

 description "Loopback of GTP-SLB for dispatch mode"

 ip address 10.20.30.91 255.255.255.255

!         

interface GigabitEthernet0/0

 no ip address

 standby use-bia

!

interface GigabitEthernet0/0.3

 description "VLAN for Gn interface of UMTS"

 encapsulation dot1Q 410

 ip address 10.20.21.62 255.255.255.0

 no ip mroute-cache

 no keepalive

 no cdp enable

 standby version 2 

 standby 7 ip 10.20.21.82

 standby 7 priority 160

 standby 7 name Gn

!

interface GigabitEthernet0/0.31

 description "VLAN for Gi interface of UMTS"

 encapsulation dot1Q 420

 ip vrf forwarding internet

 ip address 10.30.21.62 255.255.255.0

 standby 7 follow Gn

 standby 7 ip 10.30.21.82

!

interface GigabitEthernet0/0.71

 description "VLAN for inter-dev_SCTP"

 encapsulation dot1Q 498

 ip address 10.70.71.9 255.255.255.0

!

interface Virtual-Template1

 ip unnumbered Loopback1

 no ip redirects

 encapsulation gtp

 gprs access-point-list gprs

!

ip local pool APN1 110.1.0.1 110.1.10.255

ip classless

no ip http server

!

!

gprs access-point-list gprs

  access-point 1

   access-point-name apn1

   ip-address-pool local APN1

   !

  !       

!

!

gprs charging disable

gprs redundancy

!

!

...

!

!         

end

Stby_GGSN-3#

Geographical GTP-SR Examples

This section contains the following configuration examples from a geographical GTP-SR implementation:

•GGSN Interface Configuration Examples

•Secondary GGSN Interface Configuration Example

•Supervisor Routing Configuration Examples

•GGSN Routing Configuration Examples

GGSN Interface Configuration Examples

Primary GGSN Interface Configuration Example

! 

interface Loopback1 

 description GGSN Loopback i/f 

 ip address 1.1.1.1 255.255.255.255 

! 

interface GigabitEthernet0/0.100 

 description Gn VLAN 

 encapsulation dot1Q 100 

 ip address 10.0.0.1 255.255.255.0 

 standby 1 ip none 

 standby 1 name geo 

 standby 1 unicast destination 20.0.0.2 

! 

interface GigabitEthernet0/0.200 

 description Gi VLAN 

 encapsulation dot1Q 200 

 ip vrf forwarding Gi-VRF 

 ip address 11.0.0.1 255.255.255.0 

 standby 1 ip none 

 standby 1 follow geo 

! 

interface Virtual-Template1 

 ip unnumbered Loopback1 

 encapsulation gtp 

 gprs access-point-list APLIST 

! 

Secondary GGSN Interface Configuration Example

! 

interface Loopback1 

 description GGSN Loopback i/f 

 ip address 2.2.2.2 255.255.255.255 

! 

interface GigabitEthernet0/0.300 

 description Gn VLAN 

 encapsulation dot1Q 300 

 ip address 20.0.0.2 255.255.255.0 

 standby 1 ip none 

 standby 1 name geo 

 standby 1 unicast destination 10.0.0.1 

! 

interface GigabitEthernet0/0.400 

 description Gi VLAN 

 encapsulation dot1Q 400 

 ip vrf forwarding Gi-VRF 

 ip address 21.0.0.2 255.255.255.0 

 standby 1 ip none 

 standby 1 follow geo 

! 

interface Virtual-Template1 

 ip unnumbered Loopback1 

 encapsulation gtp 

gprs access-point-list APLIST 

! 

Supervisor Routing Configuration Examples

Primary Supervisor Configuration Example

ip vrf Gi-VRF 

rd 200:1 

! 

interface Vlan200 

description Gi-VRF 

ip vrf forwarding Gi-VRF 

ip address 11.0.0.10 255.255.255.0 

end 

! 

router ospf 200 vrf Gi-VRF 

log-adjacency-changes 

network 11.0.0.0 0.0.0.255 area 1 

Secondary Supervisor Routing Configuration Example

ip vrf Gi-VRF 

rd 200:1 

! 

interface Vlan400 

description Gi-VRF 

ip vrf forwarding Gi-VRF 

ip address 21.0.0.20 255.255.255.0 

end 

! 

router ospf 400 vrf Gi-VRF 

log-adjacency-changes 

network 21.0.0.0 0.0.0.255 area 3 

! 

GGSN Routing Configuration Examples

Primary GGSN Routing Configuration Example

router ospf 10 

router-id 30.30.30.30 

no log-adjacency-changes 

redistribute static subnets 

passive-interface GigabitEthernet0/0.10 on-standby 

network 10.0.0.0 0.0.0.255 area 0 

network 1.1.1.1 0.0.0.0 area 0 

! 

router ospf 20 vrf Gi-VRF 

no log-adjacency-changes 

redistribute static route-map xxx 

passive-interface GigabitEthernet0/0.20 on-standby 

network 11.0.0.0 0.0.0.255 area 1 

! 

Secondary GGSN Routing Configuration Example

router ospf 30 

router-id 40.40.40.40 

no log-adjacency-changes 

redistribute static subnets 

passive-interface GigabitEthernet0/0.30 on-standby 

network 20.0.0.0 0.0.0.255 area 2 

network 2.2.2.2 0.0.0.0 area 2 

! 

router ospf 40 vrf Gi-VRF 

no log-adjacency-changes 

redistribute static route-map xxx 

passive-interface GigabitEthernet0/0.40 on-standby 

network 21.0.0.0 0.0.0.255 area 3 

!