- About This Guide
- Overview of GPRS and UMTS
- Overview of the Single IP Cisco GGSN
- Planning to Configure the GGSN
- Configuring GTP Services on the GGSN
- Configuring IPv6 PDP Support on the GGSN
- Configuring GTP Session Redundancy on the GGSN
- Configuring Charging on the GGSN
- Configuring Enhanced Service-Aware Billing on the GGSN
- Configuring Network Access to the GGSN
- Configuring PPP Support on the GGSN
- Configuring QoS on the GGSN
- Configuring Security on the GGSN
- Configuring Dynamic Addressing on the GGSN
- Configuring Load Balancing on the GGSN
- Monitoring Notifications
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, see 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 3-11 for a list of other Cisco IOS software documentation that might be helpful when configuring the GGSN.
This chapter includes the following sections:
•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
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 6-1 and Figure 6-2):
•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 6-1 illustrates a local GTP-SR implementation.
Figure 6-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 6-2 illustrates a geographical GTP-SR implementation.
Figure 6-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
The the following limitations and restrictions apply to GTP-SR:
•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:
–L2 and L3 HSRP are mutually exclusive.
–Migrating from L2 to an L3 HSRP configuration requires a system reload.
–If using Cisco GGSN Release 10.0 or later, OSPF cannot be used on the Cisco SAMI for learning routes to any of the external nodes such as the RADIUS server, SGSN, etc. However, OSPF like routing protocols can be run on the supervisor with static or default routes configured on the Cisco SAMI pointing to the supervisor.
–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
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
•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. 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 command in interface configuration mode 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 command in interface configuration mode; 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:
|
|
|
---|---|---|
Step 1 |
Router(config)# redundancy inter-device |
Configures redundancy and enters interdevice configuration mode. To remove all interdevice configuration, use the no form of the command. |
Step 2 |
Router(config-red-interdevice)# scheme standby standby-group-name |
Defines the redundancy scheme to use. Currently, "standby" is the only supported scheme. •standby-group-name—Must match the standby name specified by the standby name command (see the "Configuring HSRP" section). Also, the standby name should be the same on both GGSNs in a redundant configuration. |
Step 3 |
Router(config-red-interdevice)# exit |
Returns to 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 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:
|
|
---|---|
Router(config)# gprs redundancy |
Enables GTP-SR on the GGSN. |
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 a gateway GPRS support node-call detail record (G-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 Cisco Service and Application Module for IP User Guide.
Configuration Examples
This section provides the following configuration 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
!