Configuring GGSN GTP Session Redundancy
This chapter describes how to configure GTP session redundancy (GTP-SR) between two GGSNs.
Note The Cisco GGSN supports GTP Session Redundancy for IPv4 PDP contexts only.
For a complete description of the GGSN commands in this chapter, refer to the Cisco GGSN Command Reference for the Cisco GGSN release you are using.
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 for a list of the other Cisco IOS software documentation that might be helpful while configuring the GGSN.
This chapter includes the following sections:
•GTP Session Redundancy 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 Session Redundancy Overview
Cisco GGSN Release 5.1 and later supports Active/Standby, 1-to-1 inter-device GTP session redundancy (GTP-SR). GTP-SR enables two GGSNs located on separate Cisco Service and Application Module for IP (SAMI) installed in separate Cisco 7600 series router chassis to appear as one network entity and ensures that continuous service is provided to mobile subscribers in the event one of the GGSNs fails.
The Cisco IOS GGSN software uses the Cisco IOS Hot Standby Routing Protocol (HSRP), the Cisco IOS Check-point Facility (CF) and Redundancy Framework (CF), and Stream Control Transmission Protocol (SCTP) to provide inter-device redundancy and high availability.
In a GTP-SR implementation, the Active GGSN establishes and terminates PDP sessions and sends 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. As soon as the Standby GGSN detects that the Active GGSN has failed, it becomes active and assumes the responsibilities of the Active GGSN.
Figure 5-1 illustrates a GTP-SR implementation.
Figure 5-1 GTP-SR Configuration
Note Before GTP-SR can be enabled on the redundant GGSNs, a GTP-SR inter-device infrastructure must be configured. For information on configuring the GTP-SR inter-device infrastructure, see the "Configuring the GTP Session Redundancy Inter-Device Infrastructure" section
Prerequisites
Proper GTP-SR operation requires the following:
•Two Cisco 7600 series router in which a Cisco Supervisor Engine 720 (Sup720), with a Multilayer Switch Feature Card (Cisco Product ID: SUP720-MSFC3-BXL), running Cisco IOS Release 12.2(33)SRB1 or later is installed.
•Two Cisco SAMIs in each of the Cisco 7600 series routers. The SAMI processors must be running the same Cisco IOS GGSN software release, Cisco IOS Release 12.4(15)XQ or later.
•HSRP Version 2.
•The Active and Standby GGSNs have the same configuration, 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.
Each of the configurations must be completed in the same order on both of the units of the GTP-SR configuration.
•When loading or upgrading a new Cisco GGSN image, both GGSNs must be loaded (virtually) together.
•On the SGSN, the values configured for the number GTP N3 requests and T3 retransmissions are larger than the switchover timer. This enables requests sent during a switchover to be serviced by the newly Active GGSN rather than dropped.
•RADIUS has been forced to use the IP address of a specified interface for all outgoing RADIUS packets using the ip radius source-interface global configuration command.
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. In the case of a switchover, these PDP contexts require re-establishment on the Standby GGSN once it becomes active.
–PPP type PDP
–PPP Regeneration / L2TP access
–Network Initiated
•Timers—Except for the session timer, GGSN timers are not synchronized to the Standby GGSN. When a switchover occurs, the timers on the newly Active GGSN are restarted with an increment to prevent many of them from expiring simultaneously.
When a PDP context is recreated on the Standby GGSN, the session timer is restarted with the elapsed time subtracted from the initial session timer value. Once the session expires on the Standby GGSN, the PDP context is deleted.
•Counters—When a change from a Standby to an Active GGSN occurs, all counters are set back to zero. However, this statement is incorrect.
Note that if a switchover occurs, status counters, such as "cgprsAccPtSuccMsActivatedPdps," and some statistics counters will have a non-zero value that is the value of the counter at the time the switchover occurred. All other counters will be 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 and Standby GGSNs.
•Charging—All pertinent information to establish charging on the Standby GGSN for a PDP context is synchronized, however, the user data related charging information for a PDP context is not. 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 relationship is formed between two GGSNs, modifying the configuration of a GGSN might cause the GGSN to reload before the changes can be saved. To ensure that this does not occur, disable GTP-SR before modifying the configuration of a GGSN. For information on disabling GTP-SR, see "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 confirm the state of a GGSN, issue the show gprs redundancy command.
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 Inter-Device Infrastructure
•Configuring GTP-SR on the GGSN
•Configuring Charging-Related Synchronization Parameters
Configuring the GTP Session Redundancy Inter-Device Infrastructure
The GGSN GTP-SR feature uses the Cisco IOS Check-point Facility (CF) to send stateful data over Stream Control Transmission Protocol (SCTP) to a redundant GGSN. Additionally, in conjunction with Cisco IOS HSRP, the GGSN uses the Cisco IOS Redundancy Facility (RF) to monitor and report transitions on Active and Standby GGSNs.
To configure the GTP-SR inter-device infrastructure before enabling GTP-SR on the redundant GGSNs, complete the tasks in the following sections
•Configuring HSRP
•Enabling Inter-Device Redundancy
•Configuring the Inter-Device Communication Transport
Configuring HSRP
The Hot Standby Router Protocol (HSRP) provides high network availability because it routes IP traffic from hosts on networks without relying on the availability of any single router. HSRP is used in a group of routers for selecting an Active router and a Standby router. HSRP monitors both the inside and outside interfaces so that if any interface goes down, the whole device is deemed to be down and the Standby device becomes active and takes over the responsibilities of an Active device.
Restrictions and Recommendations
When configuring HSRP, note that 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 HRSP interface on the GGSN, with its own separate VLAN, can be configured as a follow group using the standby interface configuration command with the follow keyword option specified with the same group number as the primary group.
The follow group feature enables all interfaces configured with an HRSP follow group to share the HSRP parameters of the primary group. This facilitate HRSP group setup and maintenance in environments that contain a large number of GGSN interfaces and HRSP groups. The primary group and associated follow groups share the same group track states together and have the same priority.
Typically, HRSP groups are needed on the following interfaces. One group is configured as the primary group and the rest as follow groups. Each interface must be configured on different VLANs.
–Gn interface—primary group
–Ga interface—follow group
–DHCP (can be shared with the Gi interface)—follow group
–Gi APN (per VRF)—follow group
•The same HSRP group cannot be used on another Active/Standby GGSN pair mapped to the same physical VLAN.
•When HRSP is configured on an interface, a preemption delay can be configured using the standby preempt interface configuration command. However, in a GTP-SR environment, we recommend that you do not configure a preemption delay unless absolutely necessary. This prevents any unnecessary switchovers. If a preemption delay must be configure, ensure that a sufficient delay is specified so that bulk synchronization can complete before preemption takes affect.
•When the standby use-bia command is not used to allow bridge and gateways to learn the virtual MAC address, for optimization purposes, configure the standby mac-refresh command to a value greater than the default (hello messages are sent every 10 seconds) under the main interface (gig0/0). Once configured, all HSRP groups (primary and follow) will send Hello messages only if the node is in Active mode.
•Use the same group number for each GGSN follow group as is defined for the primary group. Using the same group number for the primary and follow groups facilitates HRSP group setup and maintenance in an environment that contains a large number of GGSN interfaces and HRSP groups.
Note A GGSN will reload if additional HSRP configurations are added after the initial HSRP setup has been configured.
For complete information on configuring Cisco IOS HSRP, see "Configuring the Hot Standby Router Protocol" section of the Cisco IOS IP Configuration Guide, Release 12.3.
Enabling HSRP and Configuring an HSRP Primary Group
To enable HSRP on an interface and configure the primary group, use the following commands in interface configuration mode:
|
|
|
Step 1 |
Router(config-if)# standby version 2 |
Changes the HSRP version to HSRP Version 2. |
Step 2 |
Router(config-if)# standby [group-number] ip [ip-address [secondary]] |
Enables the HSRP on the interface. |
Step 3 |
Router(config-if)# standby [group-number] priority priority |
Set the Hot Standby priority used in choosing the active router. The priority value range is from 1 to 255, where 1 denotes the lowest priority and 255 denotes the highest priority. Specify that, if the local router has priority over the current active router, the local router should attempt to take its place as the active router. |
Step 4 |
Router(config-if)# standby [group-number] name name |
Specifies the name of the standby group. |
Step 5 |
Router(config-if)# standby use-bia [scope interface] |
(Optional) Configures HSRP to use the burned-in address of an interface as its virtual MAC address instead of the preassigned MAC address. |
Configuring HSRP Follow Groups
Once HSRP has been enabled and the primary group configured on a GGSN interface, additional GGSN interfaces can be configured to share the HSRP parameters of the primary group by configuring it as a HRSP follow group on the interface using the standby interface configuration command with the follow keyword option specified with the same group number 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 follow groups because they inherit them from the primary group.
To configure an interface to follow a primary group, use the following command in interface configuration mode:
|
|
|
Step 1 |
Router(config-if)# standby group-number follow group-name |
Specifies the number of the follow group and the name of the primary group to follow and share status. Note The group number specified must be the same as the primary group number. |
Step 1 |
Router(config-if)# standby group-number ip virtual-ip-address |
Specifies the group number and virtual IP address of the follow group. Note The group number specified must be the same as the primary group number. |
Enabling Inter-Device Redundancy
The HRSP primary group is associated with Cisco IOS Redundancy Facility (RF) to enable session redundancy between two GGSNs.
To enable inter-device redundancy, use the following commands beginning in global configuration mode.
|
|
|
Step 1 |
Router(config)# redundancy inter-device |
Configures redundancy and enters inter-device configuration mode. To remove all inter-device configuration, use the no form of the command. |
Step 2 |
Router(config-red-interdevice)# scheme standby standby-group-name |
Defines the redundancy scheme that is to be used. Currently, "standby" is the only supported scheme. •standby-group-name—Must match the standby name specified in the standby name interface configuration command (see the "Configuring HSRP" section). Also, the standby name should be the same on both GGSNs. |
Step 3 |
Router(config-red-interdevice)# exit |
Returns to global configuration mode. |
Configuring the Inter-Device Communication Transport
Inter-device redundancy requires a transport for communication between the redundant GGSNs. This transport is configured using Interprocess Communication (IPC) commands.
To configure the inter-device communication transport between the two GGSNs, use the following commands beginning in global configuration mode:
|
|
|
Step 1 |
Router(config)# ipc zone default |
Configures the Inter-device Communication Protocol (IPC) and enters IPC zone configuration mode. Use this command to initiate the communication link between the Active device and the Standby device. |
Step 2 |
Router(config-ipczone)# association 1 |
Configures an association between two devices and enters IPC association configuration mode. In IPC association configuration mode, you configure the details of the association, such as the transport protocol, local port and local IP addresses, and the remote port and remote IP addresses. Valid association IDs range from 1 to 255. There is no default value. |
Step 3 |
Router(config-ipczone)# no shutdown |
Restarts a disabled association and its associated transport protocol. Note Shutdown of the association is required for any changes to the transport protocol parameters. |
Step 4 |
Router(config-ipczone-assoc)# protocol sctp |
Configures Stream Control Transmission Protocol (SCTP) as the transport protocol for this association and enables SCTP protocol configuration mode. |
Step 5 |
Router(config-ipc-protocol-sctp)# local-port local_port_num |
Defines the local SCTP port number to use to communicate with the redundant peer and enables IPC Transport-SCTP local configuration mode. Valid port numbers range from 1 to 65535. There is no default value. Note The local port number should be the same as the remote port number on the peer router. |
Step 6 |
Router(config-ipc-local-sctp)# local ip ip_addr |
Defines the local IP address that is used to communicate with the redundant peer. The local IP address must match the remote IP address on the peer router. |
Step 7 |
Router(config-ipc-local-sctp)# keepalive [period [retries]] |
Enables keepalive packets and specifies the number of times that the Cisco IOS software tries to send keepalive packets with a response before bringing down the interface or tunnel protocol for a specific interface. Valid value for period is an integer value in seconds great than 0. The default is 10. Valid value for retries is an integer value greater than one and less than 355. The default is the previously used value or 5 if there was no value previously specified. |
Step 8 |
Router(config-ipc-local-sctp)# retransmit-timeout interval |
Configures the message retransmission time. Valid range is 300 to 60000 milliseconds. The default is minimum 300/maximum 600. |
Step 9 |
Router(config-ipc-local-sctp)# path-retransmit number |
Configures the maximum number of keep-alive retries before the corresponding destination address is marked inactive. Valid range is 2 to 10. The default is 4. |
Step 10 |
Router(config-ipc-local-sctp)# assoc-retransmit number |
Defines the maximum number of retransmissions over all destination addresses before an association is declared failed. Valid range is 2 to 20. The default is 4. |
Step 11 |
Router(config-ipc-local-sctp)# max-inbound-streams max-streams |
Configures the maximum number of inbound streams allowed for the local port. Valid range is 2 to 25. The default is 17 streams. |
Step 12 |
Router(config-ipc-local-sctp)# init-timeout msec |
Configures the maximum interval for the init packet retransmission time-out value. Valid range is 1000 to 60000 milliseconds. The default is 1000 milliseconds. |
Step 13 |
Router(config-ipc-local-sctp)# exit |
Exits IPC transport - SCTP local configuration mode. |
Step 14 |
Router(config-ipc-protocol-sctp)# remote-port port_nun |
Defines the remote SCTP port that is used to communicate with the redundant peer and enables IPC Transport-SCTP remote configuration mode. Valid port numbers range from 1 to 65535. There is no default. Note The remote port number should be the same as the local port number on the peer device. |
Step 15 |
Router(config-ipc-remote-sctp)# remote-ip ip_addr |
Defines the remote IP address of the redundant peer that is used to communicate with the local device. All remote IP addresses must refer to the same device. |
To remove an association, use the no form of the command.
Configuring GTP-SR on the GGSN
To enable GTP-SR on a GGSN, use the following command in global configuration mode on both GGSNs of a redundant pair:
|
|
Router(config)# gprs redundancy |
Enables GTP-SR on a GGSN. |
Disabling GTP Session Redundancy
To disable GTP-SR (at both the application level and inter-device infrastructure level), complete the following tasks in the following example in the order in which they are listed. Ensure the GGSN is in Standby mode when you start these tasks.
1. Verify 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 inter-device configuration mode.
Router(config)# redundancy inter-device
Router(config-red-interdevice)# no scheme standby HSRP-Gn
3. Save configuration changes to memory.
Router(config)# write memory
4. Reload the router.
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 HRSP configuration associated with an interface, use the no forms of the relevant HSRP commands. Remove the HRSP group configuration for the follow 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)# 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
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 to the Standby GGSN. This data includes:
–Charging Identity (CID) associated with a PDP context
–Local sequence number
–Record sequence number
–GTP' sequence number
Charging Identity (CID) and Local Record Sequence Number
When an established PDP context is synchronized, the CID assigned to the PDP context's CDR is also synchronized to 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, it 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 Active GGSN's CID timer expires and it writes the global CID counter value to memory, the CID value and local record sequence (if configured) are synchronized to the Standby GGSN, which writes the information to its 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 to the Standby GGSN. When the unit becomes active, it will use 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 record sequence number is used by the charging gateway to detect duplicate CDRs associated with a PDP context.
To minimize the amount of data being synchronized to 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 is checked. If the difference is the value configured for the window size (using the gprs redundancy charging sync-window cdr rec-seqnum global configuration command), the current record sequence number is synchronized to 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 used to determine when the CDR record sequence number needs to be synchronized to the Standby GGSN, use the following command in global configuration mode:
|
|
Router# gprs redundancy charging sync-window cdr rec-seqnum size |
Configures the window size used to determine when the CDR record sequence number needs to be synchronized. Valid range is 1 to 20. The default is 10. |
GTP' Sequence Number
The GTP' sequence number is used by the charging gateway 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 GTP packet is acknowledged by the charging gateway, it removes the packet from memory. If it is not acknowledged, it is retransmitted. The charging gateway cannot acknowledged GTP packets if the sequence number repeats.
To minimize the amount of data being synchronized to 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 is checked and if the difference is the value configured for the window size (using the gprs redundancy charging sync-window gtpp seqnum global configuration command), the GTP prime sequence number is synchronized to 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 used to determine when the GTP' sequence number needs to be synchronized to the Standby GGSN, use the following command in global configuration mode:
|
|
Router# gprs redundancy charging sync-window gtpp seqnum size |
Configures the window size used to determine when the GTP' sequence number needs to be synchronized. Valid range is 5 to 65535. The default is 10000. Note Since a GGSN can transmit 128 GTP packets without any acknowledgement, we recommend that you configure the window size to be greater than 128. |
Monitoring and Maintaining GTP-SR
The following privilege EXEC show commands can be used to monitor the different aspects of the GTP-SR configuration on the GGSN.
|
|
Router# show gprs redundancy |
Displays statistics related to GTP-SR. |
Router# show redundancy [clients | counters | events | history | states | switchovers] |
Displays current or historical status and related information on planned or logged handovers. |
Router# show standby |
Displays HSRP information. |
Upgrading GGSN Images in a GTP-SR Environment
To upgrade to an new GGSN image on the SAMI, the following tasks must be completed.
1. Identify all application entities (GGSN images) on the SAMI using the show version processor command.
2. Remove all GGSNs belonging to the SAMI from the GTP SLB list on the supervisor, using the Cisco IOS SLB no inservice command. This prevent a GGSN from receiving new create PDP context requests, but it continues to service existing PDP contexts.
3. Wait until all PDP contexts are cleared, or if desired, manually clear established PDP contexts 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 examples of the of the following examples:
•Primary Supervisor Configuration Example
•Primary GGSN Configuration Example
•Secondary GGSN Configuration Example
Note The following configurations examples are just samples of configurations. Actual configurations vary based on network design.
Primary Supervisor Configuration Example
The following configuration example shows part of a sample configuration on the Primary Supervisor with some of the commands that you use to configure GTP-SR 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
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
svclc multiple-vlan-interfaces
svclc module 7 vlan-group 71,73
svclc vlan-group 71 71 svclc vlan-group 73 95,100,101
ip slb probe PING-PROBE ping
ip slb serverfarm GGSN-SR-FARM
faildetect numconns 1 numclients 1
faildetect numconns 1 numclients 1
faildetect numconns 1 numclients 1
faildetect numconns 1 numclients 1
faildetect numconns 1 numclients 1
ip slb vserver VIRTUAL-GGSN-V0
virtual 10.20.30.91 udp 3386 service gtp
ip slb vserver VIRTUAL-GGSN-V1
virtual 10.20.30.91 udp 2123 service gtp
mpls ldp logging neighbor-changes
spanning-tree extend system-id
interface GigabitEthernet2/1
description "VLAN for Inter-dev SCTP"
switchport access vlan 498
interface FastEthernet3/25
description "VLAN for Gn"
switchport access vlan 410
interface FastEthernet3/26
description "VLAN for Gi"
switchport access vlan 420
description "Virtual LAN for Gn interface for all GGSNs on an SAMI"
ip address 10.20.21.1 255.255.255.0
description "One Gi Vlan all GGSN images of mwmam"
ip address 10.20.51.1 255.255.255.0
description "VLAN for Inter-dev_SCTP"
ip address 10.70.71.1 255.255.255.0
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 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
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
transport input lat pad mop telnet rlogin udptn nasi
Primary GGSN Configuration Example
The following configuration example shows part of a sample GGSN configuration on the Primary GGSN with some of the commands that you use to configure GTP-SR highlighted in bold text:
Act_GGSN#show running-config
Building configuration...
Current configuration : 2942 bytes
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
retransmit-timeout 300 10000
description VT address of processor3:GGSN"
ip address 10.20.30.12 255.255.255.255
description "Loopback of GTP-SLB for dispatch mode"
ip address 10.20.30.91 255.255.255.255
interface GigabitEthernet0/0
interface GigabitEthernet0/0.3
description "VLAN for Gn interface of UMTS"
ip address 10.20.21.52 255.255.255.0
interface GigabitEthernet0/0.31
description "VLAN for Gi interface of UMTS"
ip vrf forwarding internet
ip address 10.30.21.52 255.255.255.0
interface GigabitEthernet0/0.71
description "VLAN for inter-dev_SCTP"
ip address 10.70.71.5 255.255.255.0
interface Virtual-Template1
gprs access-point-list gprs
ip local pool APN1 110.1.0.1 110.1.10.255
gprs access-point-list gprs
ip-address-pool local APN1
gprs gtp path-echo-interval 0
Secondary GGSN Configuration Example
The following configuration example shows part of a sample GGSN configuration on the Standby GGSN with some of the commands that you use to configure GTP-SR highlighted in bold text:
Stby_GGSN#show running config
Building configuration...
Current configuration : 2823 bytes
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
retransmit-timeout 300 10000
description VT address of processor3:GGSN"
ip address 10.20.30.12 255.255.255.255
description "Loopback of GTP-SLB for dispatch mode"
ip address 10.20.30.91 255.255.255.255
interface GigabitEthernet0/0
interface GigabitEthernet0/0.3
description "VLAN for Gn interface of UMTS"
ip address 10.20.21.62 255.255.255.0
interface GigabitEthernet0/0.31
description "VLAN for Gi interface of UMTS"
ip vrf forwarding internet
ip address 10.30.21.62 255.255.255.0
interface GigabitEthernet0/0.71
description "VLAN for inter-dev_SCTP"
ip address 10.70.71.9 255.255.255.0
interface Virtual-Template1
gprs access-point-list gprs
ip local pool APN1 110.1.0.1 110.1.10.255
gprs access-point-list gprs
ip-address-pool local APN1