Table Of Contents
Cisco Packet Data Serving Node Release 5.0 for Cisco IOS Release 12.4(22)XR
PMTU Discovery by Mobile IP Client
Features From Previous Releases
Simple IP-based Service Access
Mobile IP-based Service Access
Session Redundancy Infrastructure
In Process Synchronization Events
AAA - Authentication and Authorization
Single Interface for MIP, Simple IP, VPDN-based calls or A11 Registrations
Single Interface for Configuration
Single Interface for SNMP Management
Single Interface for Trouble Shooting and Debug
Chassis-Wide MIB for Application-Related Parameters
AAA Responsiveness Test Tool and Traps
Intra-Chassis Configuration Synchronization
Redundancy Support in Cisco PDSN Release 5.0
Single IP Support - Reused and New CLI Commands
Distributed Configuration, Show and Debug commands in Single IP PDSN
Improved Throughput and Transaction Handling
Cluster Controller Support in Single IP Blade
Clustering Architecture in PDSN
Functions of Cluster Controller
Metrics for Cluster Controller
Metrics Between Member and Controller
Backward Compatibility of Cluster Controller
Configuring Cluster Controller Support
Cluster Controller Member Configuration
Features of IMSI and PCF-based Redirection
Limitations of IMSI and PCF-based Redirection
Mobile IP and AAA Attributes for China Telecom
Proxy Mobile IP Indicator Attribute
Proxy Mobile IP Capability Indicator Attribute
Trap Generation for AAA Server Unresponsiveness
Flow Trigger Classification for DOS
Flow Marking Based on Classification Criteria for DOS
SDB Accounting Record sent by 1xRTT PCF
Differentiated Services Code Point Marking Support
Flow Trigger Classification for DSCP
Flow Marking Based on Classification Criteria for DSCP
Changes Related to Single IP Architecture
Functional Flow in SingleIP Architecture
Limitations for Masking Off the IMSI Prefix
Configuring Masking Off the IMSI Prefix
Conserve Unique IP-ID for FA-HA IP-in-IP Tunnel
GRE CVSE Support in FA-HA Tunnel
Support for 835B-Compliant RAA Table Index Downloaded from RADIUS
Configuring Remote Address Accounting
Default Service Option Implementation
Configurable Per-Flow Accounting Options
Configuring Per-Flow Accounting Options
Functional Flow for Configuring Per-Flow Accounting Options
Session and Flow Setup for Configurable Per-Flow Accounting Options
Limitations in Configuring Per-Flow Accounting Options
IP Flow Discriminator Support for PCF Backward Compatibility
Support for Remark DSCP to Max-class Value
Command Support for Fragmentation Size
New Statistics Counters for China Telecom
Prepaid Statistics per PCF level
EVDO Network Initial Aux A10 Connection Request
EVDO Network Accepted Initial Aux A10 Connection
Successful PPP Connection Request
Successful PPP Initial Request
PCF Terminate A10 Before LCP Stage
Initial Connection Requests for L2TP tunnel
Successful Request for L2TP Tunnel
Failed Request for L2TP Tunnel
Outbound and Inbound Bytes on RP Interface
Features From Previous Releases
Virtual Route Forwarding with Sub-interfaces
Configuring PDSN Session Redundancy
Configuring PDSN Session Redundancy Infrastructure
Protocol Layering and RP Connections
Identification of Data Packets For SDB Indication
SDB Indicator Marking for PPP Control Packets
Session Creation—A11 Registration Request
Configuring Multiple Service Connections
Configuring the Subscriber QoS Profile
Configuring Per-Flow Accounting
Configuring Call Admission Control on the PDSN
Resource Revocation for Mobile IP
Subscriber Authorization Based on Domain
Volume-based Prepaid Data Service Flow
Duration-based Prepaid Data Service Flow
Volume-based Prepaid Data Service with Tariff Switching
Support for G17 Attribute in Acct-Stop and Interim Records
Configuring Subscriber Qos Profile to PCF
Configuring Bandwidth Policing
Configuring VSAs in Subscriber QoS Profiles
Mobile IP Call Processing Per Second Improvements
Cisco Proprietary Prepaid Billing
Hardware IPSec Acceleration Using IPSec Acceleration Module—Static IPSec
Conditional Debugging Enhancements
Enhancements in Releases Earlier Than Cisco PDSN 3.0
Electronic Serial Number in Billing
Support for Mobile Equipment Indentifier
PDSN Cluster Controller / Member Architecture
PDSN Controller-Member Clustering
Upgrading the Member PDSN Software from Cisco PDSN Release 1.2 to Release 2.0 and Higher
Related Features and Technologies
Supported Standards, MIBs, and RFCs
Determining the Software Version
Upgrading to a New Software Release
Creating the CDMA Ix Interface
Creating a Virtual Template Interface and Associating it with the PDSN Application
Enabling R-P Interface Signaling
Configuring User Session Parameters
Configuring PDSN Session Redundancy Infrastructure
Configuring AAA Server in the PDSN Environment
Configuring RADIUS in the PDSN Environment
Configuring Prepaid in the PDSN Environment
Enabling VPDN in a PDSN Environment
Configuring Proxy Mobile IP Attributes Locally
Configuring Mobile IP Security Associations
Configuring PDSN Cluster Controller
Configuring PDSN Cluster Member
Configuring A11 Session Updates
Configuring SDB Indicator Marking
Configuring SDB Indicator Marking for PPP Control Packets
Configuring Mobile IP Resource Revocation on the PDSN
Configuring Short Data Burst Flagging
Configuring PDSN Accounting Events
Configuring CDMA RADIUS Attributes
Monitoring and Maintaining the PDSN
PDSN Default Cluster Configuration
Cisco PDSN Configuration for Simple IP
Cisco PDSN Configuration for Simple IP with VPDN
Cisco PDSN Configuration for Mobile IP
Combined Configuration for Cisco PDSN
Session Redundancy Configuration Examples
Simple IPv6 Configuration Example
AAA Server Authentication and Authorization Profile
AAA Server Profiles for Various Service Types
Authentication and Authorization RADIUS Attributes
Accounting Services RADIUS Attributes
Mandatory AVPs in Connection Setup/Release Messages
Q.931 Cause Codes Used in Call Disconnect Notify Message
Cisco Packet Data Serving Node Release 5.0 for Cisco IOS Release 12.4(22)XR
Feature History
This table describes feature support for Cisco Packet Serving Node (PDSN) releases.
12.4(22)XR
Release 5.0 of Cisco PDSN. The following new features are introduced:
•
Improved Throughput and Transaction Handling
•
•
•
•
•
12.4(22)XR
(contd...)
•
•
•
•
•
12.4(15)XR2
Release 4.1 of Cisco PDSN. The following new features are introduced:
•
•
12.4(15)XR
Release 4.0 of Cisco PDSN. The following new features are introduced:
•
Closed-RP support is removed from release 4.0.
PPPoGRE RP Interface support is removed from release 4.0.
12.4(15)XN
Release 3.5 of Cisco PDSN. The following new features are introduced:
12.3(14)YX8
Release 3.0 of Cisco PDSN. The following commands are updated:
•
•
Deleted sections on ODAP and PDSN Selection Peer-to-Peer clustering.
12.3(14)YX1
Release 3.0 of Cisco PDSN. The following new feature is introduced:
12.3(14)YX
Release 3.0 of Cisco PDSN. The following new features are introduced:
•
•
12.3(11)YF3
Release 2.1 of Cisco PDSN.
Added support for:
The following new command is added:
•
12.3(11)YF2
Release 2.1 of Cisco PDSN.
Added support for:
•
•
•
The following new commands are added or modified:
•
•
•
12.3(11)YF1
Release 2.1 of Cisco PDSN.
A restriction for Registration Revocation is removed.
The following new commands are added or modified:
•
•
•
•
•
•
•
•
12.3(11)YF
Release 2.1 of Cisco PDSN. Four new features are added, including the Closed-RP Interface.
12.3(8)XW
Release 2.0 of Cisco PDSN. Five new features are added, including the Always On.
12.3(4)T
Cisco PDSN (a Cisco IOS software) feature is integrated into Cisco IOS Release 12.3(4)T.
12.2(8)ZB8
One new CLI command is added.
12.2(8)ZB7
Six CLI commands are added or modified.
12.2(8)ZB6
Two CLI commands are added or modified.
12.2(8)ZB5
Four new CLI commands are added.
12.2(8)ZB1
Cisco PDSN feature is introduced on the Cisco 7600 Series Router.
12.2(8)ZB
Cisco PDSN feature is introduced on the Cisco Catalyst 6500 Switch.
12.2(8)BY
Cisco PDSN feature is introduced on the Cisco 7200 Series Router.
This document describes the Cisco Packet Data Serving Node (PDSN) software for use on the Cisco Service and Application Module for IP (SAMI) card that resides on the Cisco 7600 Series Router. It includes information on the features and functions of the product, supported platforms, related documents, and configuration tasks.
This document includes the following sections:
•
•
•
•
•
•
•
•
•
Feature Overview
A PDSN provides access to the Internet, intranets, and Wireless Application Protocol (WAP) servers for mobile stations using a Code Division Multiple Access 2000 (CDMA 2000) Radio Access Network (RAN). The PDSN is a Cisco IOS software feature that runs on SAMI cards on the Cisco 7600 Series Router, where PDSN acts as an access gateway for Simple IP (SIP) and Mobile IP (MIP) stations. The PDSN provides foreign agent (FA) support and packet transport for virtual private networking (VPN). It also acts as an Authentication, Authorization, and Accounting (AAA) client.
The PDSN supports all relevant 3rd Generation Partnership Project 2 (3GPP2) standards, including those that define the overall structure of a CDMA 2000 network, and the interfaces between radio components and the PDSN.
System Overview
CDMA is one of the standards for Mobile Station communication. A typical CDMA 2000 network includes terminal equipment, mobile termination, base transceiver stations (BTSs), base station controllers (BSCs or Packet Control Functions (PCFs)), PDSNs, and other CDMA network and data network entities. The PDSN is the interface between a BSC or PCF and a network router.
Figure 1 illustrates the relationship of the components of a typical CDMA 2000 network, including a PDSN. In this illustration, a roaming mobile station user receives data services from a visited access provider network, rather than from the mobile station user's subscribed access provider network.
Figure 1 The CDMA Network
As the illustration shows, the mobile station, which must support either SIP or MIP, connects to a radio tower and BTS. The BTS connects to a BSC, which contains a component called the Packet Control Function (PCF). The PCF communicates with the PDSN through an A10/A11 interface. The A10 interface is for user data and the A11 interface is for control messages. This interface is also known as the RAN-to-PDSN (R-P) interface.
Figure 2 illustrates the communication between the RAN and the PDSN.
Figure 2 RAN-to-PDSN Connection: the R-P Interface
The IP networking between the PDSN and external data networks is through the PDSN-to-intranet or Internet (Pi) interface. For the Cisco PDSN Release 2.0 and higher, you can use either an FE or GE interface as the Pi interface.
For "back office" connectivity, such as connections to a AAA server, or to a RADIUS server, the interface is media independent. Any of the interfaces supported on the Cisco 7206 can be used to connect to these types of services; however, Cisco recommends that you use either an FE or GE interface.
How PDSN Works
When a mobile station makes a data service call, it establishes a Point-to-Point Protocol (PPP) link with the PDSN. The PDSN authenticates the mobile station by communicating with the AAA server. The AAA server verifies that the user is a valid subscriber, determines available services, and tracks usage for billing.
The method used to assign an IP address and the nature of the connection depends on service type and network configuration. SIP operation and MIP operation are referred to as service types. The service type available to a user is determined by the mobile station, and by the type of service that the service provider offers. In the context of PDSN, a mobile station is the end user in both SIP and MIP operation.
Once the mobile station is authenticated, it requests an IP address. SIP stations communicate the request using the Internet Protocol Control Protocol (IPCP). MIP stations communicate the request using MIP registrations.
The following sections describe the IP addressing and communication levels for each respective topic:
•
PDSN Simple IP
With SIP, a service provider's Cisco PDSN assigns a dynamic or static IP address to the mobile station during the PPP link setup. The mobile station retains this IP address as long as it is served by a radio network that has connectivity to the address-assigning PDSN.
Therefore, as long as the mobile station remains within an area of RANs that is served by the same PDSN, the MS can move or roam inside the coverage area and maintain the same PPP links. If the mobile station moves outside the coverage area of the given PDSN, the mobile station is assigned a new IP address, and any application-level connections are terminated.
Note
Figure 3 illustrates the placement of the PDSN in a Simple IP scenario.
Figure 3 CDMA Network - Simple IP Scenario
PDSN Simple IP with VPDN Scenario
A Virtual Private Data Network (VPDN) allows a private network dial-in service to span to a remote access server called Network Access Server (NAS).
Figure 4 illustrates a VPDN connection in the PDSN environment with SIP. In this scenario, the PDSN acts as the NAS.
Figure 4 CDMA Network —Simple IP with VPDN Scenario
A VPDN connection is established in the following order:
1.
2.
3.
The PPP client is forwarded through a Layer 2 Tunneling Protocol (L2TP) tunnel over User Datagram Protocol (UDP).
4.
PDSN Mobile IP
With MIP, the mobile station can roam beyond the coverage area of a given PDSN and still maintain the same IP address and application-level connections.
Figure 5 shows the placement of the PDSN in a MIP scenario.
Figure 5 CDMA Network —Mobile IP Scenario
The communication process occurs in the following order:
1.
2.
As part of the registration process, the HA creates a binding table entry to associate the mobile station's home address with its Care-of address.
Note
3.
4.
5.
6.
7.
Note
Randomized IMSI Handling
The PDSN cannot recognize 1xRTT to EVDO as a handoff due to a change of IMSI. The result is that the "cdma-reason-ind" in the account stop message will not reflect the same.
By default, the PDSN keeps the first call session if the Mobile does a static home address. In this release, the PDSN supports deleting the first call session for dynamic home address cases (for example, 1x-RTT to EVDO handoff where the IMSI changes during the handoff).
•
–
–
•
–
A new CLI command is introduced in this release that allows you to delete the old session. When you issue the ip mobile cdma imsi dynamic command, the PDSN releases the old session and allows the new session to come up.
The limitation with this CLI command is that the error message "PLATFORM-3-SAMI_IPC_IXP_FAIL: Msgcode 26: Bad Param Error received from IXP" may displayed during high stress scenarios.
PMTU Discovery by Mobile IP Client
FTP upload and ping from the end node may fail when PMTU Discovery (done by setting the DF bit) is done by a MobileIP client (an end node) for packet sizes of about 1480. Due to failure of PMTUD algorithm, the IP sender will never learn the smaller path MTU, but will continue unsuccessfully to retransmit the too-large packet, until the retransmissions time out.
Please refer to /en/US/tech/tk870/tk877/tk880/technologies_tech_note09186a008011a218.shtml#2000XP for disabling PMTUD for Windows 2000/XP platforms.
PDSN Proxy Mobile IP
Currently, there is a lack of commercially available MIP client software. Conversely, PPP, which is widely used to connect to an Internet Service Provider (ISP), is ubiquitous in IP devices. As an alternative to MIP, you can use Cisco Proxy Mobile IP (PMIP) feature. This capability of the PDSN, which is integrated with PPP, enables a MIP FA to provide mobility to authenticated PPP users.
Note
The communication process occurs in the following order:
1.
2.
3.
4.
5.
6.
PDSN on SAMI
The SAMI blade supports the feature set of Cisco PDSN Release 5.0, and a Cisco 7600 chassis supports a maximum of six application modules. Each application module has six PPCs, each with two Gigabytes of RAM, and uses one instance of a Cisco IOS software application image. Each PPC can function as a PDSN.
Additionally, instances of the cluster controller functionality will be configured as required. One active and standby controller can support three single IP PDSN members. Each PDSN image supports 1,75,000 user sessions.
Migration Scenarios
Table 1 lists currently available PDSN releases and the migration path to the SAMI platform.
Based on Table 2, there are many possible migration scenarios. In this section, we focus on those scenarios closest to current customer deployments. The actual migration path has to be determined per-customer end-to-end deployment. Additionally, migration should be engineered, and we recommend that you perform the migration in a maintenance window in your deployment.
Customers may take this opportunity to redesign their network, for example, redesigning IP addresses scheme and configuring the routing protocols, network connectivity between PDSN and HA, application connectivity between PDSN and AAA servers, routing on the new SAMI PDSN or HA, and so on.
Note
Table 2 lists the most common migration scenarios:
Migration Steps
Migration to Cisco PDSN Release 5.0 is more than replacing Multi-processor WAN Application Module (MWAM) cards with SAMI modules. Your migration must be well planned and conducted in a way that has minimal impact on an existing mobile subscriber's service connections. Migration to Cisco PDSN Release 5.0 image means, changing to the architecture of single PDSN per blade level. The single IP feature reapportions functionality on a SAMI service blade from the 4.0 model of six independent IOS processors. Each IOS processor executes both control and traffic plane functions, to a model where one IOS processor is designated as a Control Plane (PCOP) processor and the other five designated as Traffic Plane (TCOP) processors.
Note
•
Table 3 lists the migration tasks that are based on the scenarios that were previously established in Table 2.
Features
This section lists the features introduced in the current release (Cisco PDSN Release 5.0) and the previous releases.
For a detailed list, see the following:
•
New Features in This Release
This section lists the features of the Cisco PDSN Release 5.0:
•
•
•
•
•
•
•
•
•
•
•
•
•
Features From Previous Releases
This section lists features that were introduced before Cisco PDSN Release 5.0:
•
•
•
•
•
•
•
–
–
•
–
•
•
•
•
•
•
•
Note
Note
Please note that Cisco PDSN Release 4.0 does not support Closed-RP clustering. Additionally, Closed-RP support is removed in the release.
Note
PDSN Performance Metrics
Cisco PDSN Release 4.x and later releases deliver performance improvements such as significant improvement in 1XRTT call setup rates, compared to Release 3.0 and Release 3.5.
Performance Metrics on the Cisco 7600 S eries Router are as follows: The quoted figures are per image, and each SAMI can support six PDSN images.
•
•
•
•
•
•
Note
Packet Data Service Access
The PDSN supports two types of service accesses. The type of service access for a mobile session is determined by the capabilities of the mobile station:
•
•
Simple IP-based Service Access
The PDSN facilitates a mobile user to access the internet and corporate intranet by using SIP-based service access. SIP mode of access, however, limits user mobility to the coverage area of the serving PDSN. Inter-PDSN handoff causes renegotiation of PPP between the mobile station and the new PDSN. The old IP address assigned at the previous PDSN cannot usually be assigned to the mobile user from the new PDSN, and results in reset and restart of user applications.
Some of the salient features for SIP-based service access are:
•
•
•
•
•
•
•
•
•
•
•
User NAI is available during the PPP CHAP/PAP authenticating phase. Domain name information in the NAI determines the domain responsible for user authentication. Based on the type of packet routing model, SIP-based service access can be categorized as follows:
•
•
•
Simple IP Routed Access
After receiving username and password during PPP LCP negotiations, the PDSN forwards authentication information to the local AAA server through an access-request message. This, in turn, may be proxied to the AAA server in the user's home domain, via broker AAA servers, if necessary. On successful authentication, the user is authorized services based on its service profile. User Class/CDMA_IPTECH information, along with other authorization parameters are returned to the PDSN using an access-accept message from the home AAA server. On successful negotiation of an IP address, SIP-based services are made available to the mobile user.
SIP routed access method is applicable for users that are not configured for VPDN or PMIP services. With PPP terminated at the PDSN, uplink user traffic is routed toward the IP network from the PDSN. The address assigned to the mobile user would be from within the PDSN routable domain. Private addresses may also be used if a NAT is configured. User mobility is limited to the PDSN coverage area. Inter-PCF handoffs do not disrupt service. Inter-PDSN handoffs, however, result in PPP renegotiation at the new PDSN, another IP address being assigned at the new PDSN, and reset and restart of user applications.
Simple IP VPDN Access
After receiving username and password during PPP LCP negotiations, the PDSN forwards authentication information to the local AAA server via an access-request message. This, in turn, may be proxied to the AAA server in the user's home domain, via broker AAA servers, if necessary. On successful authentication, the user is authorized services based on user's service profile. If the user is configured for VPDN based access services, User Class information, along with other authorization parameters including tunneling options and tunneling parameters, are returned to the PDSN through an access-accept message from the home AAA server. The following type of VPDN services is supported at the PDSN:
L2TP - Layer 2 Tunneling Protocol
For L2TP type layer2 tunneling, the PDSN establishes an L2TP tunnel with the tunneling endpoints specified by the tunneling parameters. The L2TP tunnel would be established between the Link Control Protocol (LAC) at the PDSN and LNS at the NAS in user's home domain. The PPP connection would be between the mobile station and the LNS in the home network. Despite the PPP connection termination at the L2TP Network Server (LNS), the PDSN monitors the PPP session for inactivity. Status of the PPP connection is also linked with the state of the underlying A10 connection. PPP connection is deleted when the underlying A10 connection is deleted. IPSec encryption methods can also be enabled over the L2TP tunnels for enhanced security.
On successful negotiation of an IP address between the mobile and the LNS, IP-based services are made available to the mobile.
The LNS may be configured to authenticate the mobile user based on the challenge and challenge response information from the PDSN. Additionally, the LNS may also be configured to challenge the user again after the layer2 tunnel has been established. The following authentication options are supported for L2TP:
•
The LAC (PDSN) challenges the mobile user and forwards authentication-related information to the LNS as part of tunnel-setup parameters. The LNS may be configured to authenticate the user either locally or through the home AAA server, based on the authentication-related information from the LAC (PDSN). On successful authentication, the mobile and the LNS proceed with the IPCP phase and negotiate an IP address for the user session.
•
The LAC (PDSN) challenges the mobile and forwards authentication-related information to the LNS as part of tunnel-setup parameters. The LNS may be configured to authenticate the user either locally or through the home AAA server, based on the authentication-related information from the LAC (PDSN). On successful authentication, the LNS challenges the mobile again. After successful authentication, the LNS and the mobile proceed with IPCP phase and negotiate the IP address for the user session.
Proxy Mobile IP Access
After receiving username and password during PPP LCP negotiations, the PDSN forwards authentication information to the local AAA server via an access-request message. This, in turn, may be proxied to the AAA server in the user's home domain, using broker AAA servers, if necessary. On successful authentication, the user is authorized services based on its service profile. User Class information, along with other authorization parameters, are returned to the PDSN via an access reply from the home AAA server.
If the user is configured for PMIP-based access, authorization parameters from the home AAA server include the HA address, and the security parameter (SPI) to be used for computing the MN-HA Authentication extension for the mobile station. The HA is allocated from the list of HAs configured at the home AAA server. Round robin or hashing algorithms based on user NAI can be used for allocating a HA at the AAA server. Other authorization attributes returned from the AAA server include MN-AAA authenticating extension as defined in RFC 3012. Based on this information, the PDSN performs PMIP procedures on behalf of the mobile user by sending a MIP Registration Request message to the allocated HA. On successful authentication of the mobile with the AAA server and registration at the HA, the HA assigns a home address for this mobile user This address is returned to the mobile during IPCP IP address negotiation phase.
On successful negotiation of an IP address, PMIP-based services are made available to the mobile user. To the mobile, these services are no different from SIP services with tunneling being done through the HA. This feature, however, extends the coverage area of the call beyond the coverage area of the serving PDSN. If, as a result of a handoff event, another PDSN is allocated to the call, the target PDSN performs MIP registration with the HA, thereby ensuring that the same home address is allocated to the mobile.
Mobile IP-based Service Access
The PDSN allows a mobile station with MIP client function to access the Internet and corporate intranet using MIP-based service access. With this mode of service access, user mobility is extended beyond the coverage area of currently serving PDSN. Resulting from a handoff, if another PDSN is allocated to the call, the target PDSN performs MIP registration with the HA, thereby ensuring that the same home address is allocated to the mobile.
Some of the salient features for MIP services access are:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
A MIP capable mobile client may be configured to skip PAP/CHAP based authentication during the PPP LCP phase. Once the PPP is established, the PDSN sends a burst of MIP Agent Advertisement messages that include the MIP Agent Advertisement Challenge extension specified in RFC 3012. The number and timing of the burst is configurable. The mobile user responds with a MIP Registration Request message that includes the mobile user's NAI and MN-FA Challenge extension in response to the challenge in the Agent Advertisement message. If the mobile user does not respond to the initial burst, advertisements can be solicited.
The Foreign Agent function at the PDSN can be configured to authenticate the mobile user by forwarding an access-request message to the local AAA server. The local AAA server would proxy the message to the home AAA server, through broker AAA servers, if necessary. On successful authentication, the home AAA server may assign a HA to the call and return its address in the access reply message. Other authorization parameters in the access-reply message include the SPI and IPSec shared key to be used between the FA and the HA. The PDSN or FA and HA establish a secure IPSec tunnel, if required, and the PDSN/FA forwards the Registration Request message to the HA. The Registration Request message includes the NAI and MN-FA-Challenge Extension also. It may also include MN-AAA Authentication extension.
The HA can be configured to authenticate the mobile again with the home AAA server. On successful authentication and registration, the HA responds with a Registration Reply message to the PDSN or FA that is forwarded to the mobile station. The Registration Reply message contains the home address also (static or dynamically assigned) for the user session.
Potential home addresses are available to the PDSN from the following:
•
•
•
The mobile may be configured to perform PPP PAP/CHAP authentication in addition to performing Foreign Agent Challenge based authentication specified in RFC 3012. In this case the PDSN would support one SIP flow, in addition to one or more MIP flows.
For MIP services, the HA would typically be located within an ISP network or within a corporate domain. However, many of the ISPs and/or corporate entities may not be ready to provision HAs by the time service providers begin rollout of third-generation packet data services. Access service providers could mitigate this situation by provisioning HAs within their own domain, and then forward packets to ISPs or corporate domains via VPDN services.
Binding Update Procedures
When a mobile first registers for packet data services, a PPP session and associated MIP flows are established at the PDSN. In the event of an inter-PDSN handoff, another PPP session is established at the target PDSN, and the mobile registers with the HA through the new PDSN/FA. The Visitor list binding and the PPP session at the previous PDSN are, however, not released until the PPP inactivity timer expires.
Idle/unused PPP sessions at a PDSN consume valuable resources. The PDSN and HA support MIP Resource Revocation as defined in IS83C and Cisco Proprietary Binding Update and Binding Acknowledge messages for releasing such idle PPP sessions as soon as possible. MIP Resource Revocation is described in Section 16 in greater detail
If Cisco Proprietary binding update feature is used, in the event of an inter-PDSN handoff and MIP registration, the HA updates mobility binding information for the mobile with the Care-of-Address (COA) of the new PDSN/FA. If simultaneous bindings are not enabled, the HA sends a notification in the form of a Binding Update message to the previous PDSN/FA. The previous PDSN/FA acknowledges with Binding Acknowledge, if required, and deletes visitor list entry for the MIP session. The previous PDSN/FA initiates the release of the PPP session when there are no active flows for that mobile station.
The sending of the binding update message is configurable at the HA.
Note
Simple IPv6 Access
The PDSN SIP service has been enhanced to allow both simple IPv4 and simple IPv6 access. These protocols can be used one at a time, or at the same time. The ipcp and the ipv6cp are equivalent for each protocol.
An IPv6 access uses the same PPP LCP authentication and authorization procedures, as well as the AAA server access. When an RP connection is established, the MS sends a PPP Link Control Protocol (LCP) Configuration-Request for a new PPP session to the PDSN. The PPP authentication (CHAP/PAP/none) is one of the parameters negotiated during the LCP phase. After the LCP parameters are negotiated between the MS and the PDSN, an LCP Configure-Acknowledge message is exchanged. Once LCP is up, the PPP authentication is started.
The authentication phase uses CHAP, PAP, or none, depending on the configuration and LCP negotiation. After authentication, the NCPs, ipcp or ipv6cp or both, can be started. A simultaneous IPv4 and IPv6 access from an MS shares the common LCP authentication and authorization as well as the AAA server correlation-ID parameter.
The ipv6cp protocol negotiates a valid non-zero 64-bit IPv6 interface identifier for the MS and the PDSN. The PDSN has only one interface-identifier associated with the PPP connection, so it will be unique. Once ipv6cp has been successfully negotiated, the PDSN and MS both generate unique link-local addresses for the IPv6 interface. The link-local addresses are generated by pre-pending the link-local prefix, FE80:/64, to the 64-bit interface-identifier negotiated during the ipv6cp phase (for example, FE80::205:9AFF:FEFA:D806). This gives a 128-bit link-local address.
The PDSN immediately sends an initial unsolicited Router Advertisement (RA) message on the PPP link to the MS. The link-local address of the PDSN is used as the source address and the destination address will be FF02::1, the "all nodes on the local link" IPv6 address. The PDSN includes a globally unique /64 prefix in the RA message sent to the MS. The prefix may be obtained from a local prefix pool or from the AAA server. The MS will construct a global IPv6 unicast address by prepending the prefix received in the RA to the lower 64-bit interface identifier. You should carefully configure the PDSNs so that the /64 prefix is globally unique for each MS.
After a successful ipv6cp negotiation phase and configuration of the link-local address, the MS transmits a Router Solicitation (RS) message if an RA message has not been received from the PDSN within some specified period of time. The RA is necessary for the MS to construct its 128-bit global unicast address.
In contrast to IPv4, an IPv6 MS will have multiple IPv6 addresses, including:
•
•
•
An IPv6 address is 128-bits for both source and destination addresses. The /64 designation means that 64-bits are used for the prefix (upper 64-bits). This is similar to an IPv4 netmask. A /128 address would mean that the entire address is used. Refer to RFC 3513 for additional IPv6 addressing details and information.
Note
Configuring Simple IPv6
The following commands are used to configure simple IPv6 on the PDSN, and are listed in the Cisco IOS IPv6 Command Reference guide:
•
•
•
•
•
•
•
The following configuration commands are required for IPv6:
Global Configuration Commands
•
•
•
Virtual-template Interface Commands
•
•
•
•
•
Other commands
•
Refer to the Cisco IOS IPv6 Command Reference at the following URL for more detailed information about these configuration commands:
http://www.cisco.com/en/US/products/sw/iosswrel/ps5187/products_command_reference_book09186a00801d661a.html
Session Redundancy Infrastructure
In Cisco PDSN Release 5.0, a redundant PDSN is updated with the session details at the following two different times:
•
•
–
–
–
–
–
–
The new parameters introduced in this feature are synchronized to stand by for both scenarios.
Functional Overview
PDSN session redundancy is focused on preserving user flows on failover. Support for the continuity of billing records, internal counters, and MIB variables is secondary. The following conditions need to exist for failover to be successful on the PDSN:
•
•
•
The PDSN Session Redundancy feature provides user session failover capability to minimize the impact of a PDSN failure on the mobile user experience. The PDSN uses a 1:1 redundancy model, with a standby present for every active PDSN. The active PDSN sends state information to the standby PDSN for synchronization on an as-needed basis. When a PDSN failure occurs, the standby PDSN has the necessary state information to provide service to all existing sessions. It then takes over as the active PDSN and services user sessions, thus providing session redundancy. When the previously active PDSN comes back online, it assumes the role of standby for the now active PDSN, and receives state information for all existing sessions from the newly active PDSN.
Under normal operating conditions, the active and standby PDSN pairs are two separate PDSN images that have identical configurations. They share one or more HSRP interfaces, which are used by all external entities to communicate with them. The active PDSN synchronizes session data to the standby PDSN based on events described below.
Session Events
When a new user session needs to be established, the PCF first sets up an A10 connection to the active PDSN using the HSRP address known to the PCF. The MN then sets up a PPP connection with the active PDSN using the A10 tunnel. Once the call is in a stable state (the PPP session is successful), the active PDSN then synchronizes relevant state information to the standby PDSN. The standby then duplicates the actions of the active PDSN with regards to the A10 connection and the PPP session, and awaits further updates from the active. When any of the other events as listed below occurs, the active PDSN sends state information to the standby.
In order to minimize the loss of accounting data in the event of a failover, a periodic accounting update, with configurable frequency will run on the active PDSN. Every periodic update for a session will trigger a synchronization sent to the standby PDSN, which will update its accounting data. Only counters and attributes that undergo a change on the active PDSN are synchronized to the standby periodically. Information since the last accounting synchronization point will be lost. Also, in order to ensure that the latest information is correctly conveyed to the billing system, the standby unit will never send out any accounting records to the AAA server. The records are always sent from the active unit.
Session events that lead to a synchronization are:
•
•
•
•
•
•
•
•
•
Active PDSN Failure
In the event that the standby PDSN detects that the active PDSN has failed (using HSRP), it then takes over as the active PDSN. Since all external entities, including PCFs, AAA servers, and HAs are configured to communicate with the PDSN pair only using the HSRP addresses, once the standby PDSN takes over those addresses, they are unable to detect a failure. All stable calls also have their state synchronized to the standby; therefore the standby is able to start forwarding user traffic once it takes over as active. On the standby all timers (such as A11 lifetime, PPP timers, and MIP lifetime) are started at the time it takes over as active. Accounting data is also synchronized to the extent that the periodic accounting synchronization timer has been configured on the PDSNs.
Standby PDSN Start-up
When a PDSN comes up when there is an existing active, it takes over the standby role. When the active PDSN learns that a standby PDSN is available, it goes through a process of transferring state data for all existing user sessions to the standby, called a Bulk synchronization. After this process is complete, the standby PDSN is then ready to take over as active in the event of a failure.
Handling Active-Active Scenario
If there is a link failure or a failure in an intermediate node, HSRP packets sent will not reach the peer and the standby node would assume that the active has reloaded and transitioned to active state. This leads to a situation of Active-Active PDSN nodes. The requirement is that, in case one of the PDSNs continues to receive traffic while the other is isolated from the network, it is ensured that the node which received traffic should remain active once the link is restored.
To achieve this, an application tracking object is introduced and HSRP priority is altered based on whether PDSN is processing traffic after the HSRP peer is lost. The PDSN will lower its HSPR priority once it detects that the peer PDSN is lost. Afterward, when the PDSN processes traffic (either control or data packets), it raises its priority back to the configured value. This helps to choose the active node after the link is restored between the PDSNs. So the node which received traffic in Active-Active situation remains to be active after link restoration.
Other Considerations
A Redundancy Framework (RF) MIB is available in order to monitor the active and standby status of the two PDSNs. Other MIB variables and internal counters are not synchronized between the active and standby. They start from the values following IOS-Load or Reload on the backup image. The backup image is treated as a new box.
The PDSN redundant pair is treated as a single member by the cluster controller, and is transparent to the PDSN clustering mechanism. The cluster controller is oblivious to a failover from an active PDSN to its redundant standby.
Similarly, a PDSN redundant pair appears as a single PDSN to all external entities, such as the PCF, the HA, and the AAA server.
IPSec security associations for FA-HA connectivity are maintained across failover.
Note
Note
In Process Synchronization Events
The following subsections explain the expected behavior of the PDSN in session redundancy for various synchronization events in process.
Call Setup
The state of "sessions-in-progress" is not preserved during failover. Mechanisms such as R-P connection retry from the PCF will ensure that sessions will be established as required.
It is possible that a failover can occur when the PCF has established an R-P session for a user flow, but user flow establishment is not completed. In this case, failover will result in the R-P session not being present on the standby. The PCF will timeout the R-P session on the next R-P session lifetime refresh. If the user attempts to establish a new session during this time, a new session will be created.
Call Teardown
There are four scenarios for session termination and include:
•
•
•
•
For each of these cases, session teardown is a multi-step process. For example, a failover can occur when a Registration Update message has been sent from the PDSN and the acknowledgement has not been received. In this case, the standby PDSN will already have been told to delete the session. The active PDSN will not wait for an update acknowledgement from the PCF.
If a failover occurs after sending the Registration Update to the PCF but before the standby has been told to delete the session, or the request to delete the session is lost, the session will remain established on the standby.
Another case is that the PPP context has been deleted as a result of mobile-initiated termination, and then failover occurs prior to the R-P session being terminated.
Similarly, expiry of the PPP Idle timer on the PDSN could also result in deleting the PPP context followed by failover prior to R-P session termination.
In these cases, either the MIP Registration Lifetime or the PPP Idle Timeout will expire, and the session is terminated.
Flow Setup
Flows that are in the process of being established are not preserved. You will see this as failure to establish the flow, and you will have to re-establish the flow.
Flow Teardown
This section applies when a session has two or more flows. Currently, only a MIP call supports this case. For a single IP call, only one flow is allowed.
Although a MIP flow is preserved after switchover, it is possible that registration lifetime expiration will lead to deleting the flow. If the same user registers again before the lifetime expires, it will be considered as a reregistration because this is an existing visitor. However, the reregistration may or may not succeed, depending on the following conditions:
•
•
Dormant-Active Transition
The transition is synchronized between active and standby, and occurs in the following scenarios:
•
•
•
•
Handoff
Inter-PCF Handoff (Dormant or Active) - Same PDSN
The most significant problem with handoff is to re-establish the data path between the target PCF and the now-active PDSN for the preserved session, irrespective of whether this is an active or dormant handoff. Again, there is a window between handoff actually being completed and the state being synchronized within which a failover can occur.
These are the following scenarios:
•
•
•
Inter-PCF Handoff (Dormant or Active) - Different PDSN
This kind of handoff is indicated to the PDSN by receipt of an A11 Registration Request containing the PANID and CANID. It also includes the Mobility Event Indicator and Accounting Data (R-P Session Setup Air-link Record). From the perspective of High Availability, this looks like a new session establishment on the newly active PDSN and a 'regular' session termination on the old PDSN.
A11 Reregistrations
A11 Reregistration RRQ is received by the active unit. The registration life timer does not start on the standby, but it keeps track of the life timer value so that it can restart the life timer once it becomes active. If the lifetime in the reregistration RRQ is different from the previous RRQ, the new lifetime is synchronized to the standby. For example, if a previous RRQ carries a lifetime of 300 seconds and now a new RRQ has the value changed to 500 seconds, the new value is synchronized to the standby. Other significant parameters included in the reregistration RRQ are also synchronized to the standby.
Now, in the above example, if the failover occurs before synchronizing the new lifetime to the standby, the standby will start the lifetime for 300 seconds.
PPP Renegotiation
On PPP renegotiation, the PDSN deletes all the flows on the RP session and sends accounting STOP for each flow. After PPP is up again, the PDSN creates new flow(s) for the session. Therefore, when PPP renegotiation happens on the active, the active unit will send a PPP renegotiation notification to the standby which will then delete all the flows from the RP session on the standby. After PPP is up again and a new flow is created on the active, the active unit sends each flow's data to the standby. If the failover occurs during PPP renegotiation, the renegotiation will fail, and the session may be torn down on the newly active unit.
Other Considerations
Timers
The following timers are normally running when a session is established:
•
•
•
•
The below timer may be running, depending on configuration
•
These timers are restarted on the standby when failover occurs, and the elapsed time is not synchronized to the standby. The effect will be to extend the timers beyond their original values by a time equal to the time that has already expired. This ensures that the user will not perceive a session failure on failover.
Restrictions
The following restrictions exist for the PDSN Session Redundancy Feature:
•
Setting the revocation timestamp to "msec" (ip mobile foreign-service revocation timeout 5 retransmit 4 timestamp msec) for PMIP flows with Session Redundancy is not permitted.
The "msec" option puts the uptime in the timestamp field, and the uptime of the standby router is expected to be lower after switchover when the standby PDSN takes over as active (and when the PMIP flow was closed). Therefore, revocation on HA will be ignored because the identifier value in the revocation message is less than what is expected by HA.
•
•
•
Internals
The following sections identify information that is synchronized to the standby unit:
AHDLC
The control character mapping per used AHDLC channel is preserved. As the default is normally used, only those that are different are synchronized. The AHDLC channel number is not synchronized; an available channel will be selected independently on the standby.
GRE - RP Interface
The GRE Key is synchronized. The flags are synchronized as the sequence flag can be set on a per user basis.
RP Signaling
The contents of the A11 messaging will be treated as described below.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
PPP
All LCP options are synchronized. For IPCP, only the IP address and IPHC parameters are synchronized. DNS server IP address negotiated during IPCP negotiation is not synchronized to the standby unit. All per user attributes downloaded from the AAA server during authentication or authorization are synchronized to the standby unit.
Compression - Header and Payload
There is no synchronization of compression context for either header or payload compression. Fail-over to a standby PDSN results in the compression context being re-established.
Header compression - First packet for a session after switchover is dropped, and peer retries the packet after acknowledge timeout.
Payload compression - There is no compression history present after switchover on the standby. A CCP reset is automatically generated when decode fails. No special treatment is needed.
IP Address Assignment
When an IP address is dynamically assigned from a pool configured on the PDSN, it is necessary that the standby associates the same address with the session. The IP address will be synchronized as part of PPP state. If the IP address is received from the AAA server or a static IP address is used that does not come from a local pool, this address will also be associated with the session on the standby. Similarly, the address pool will be synchronized.
AAA - Authentication and Authorization
Table 5 lists the relevant authentication and authorization parameters. This is required on the standby to allow accurate recreation of the AAA state.
GPP2 Packet Data Service Attributes
Table 6 lists the 3GPP2 Packet Data Service Attributes.
AAA Server Accounting
GPP2 Accounting Records Fields
Table 7 identifies the GPP2 accounting records fields.
RADIUS Server Group Support
The IP address of the AAA server chosen will not be synchronized.
Mobile IP Signaling
For MIP service, the parameters to be synchronized, per MIP flow, include the following:
•
•
•
•
•
•
•
•
Mobile IP Tunneled Traffic
This traffic is carried in either GRE tunnels or IP-in-IP tunnels. The only information that needs to be synchronized is the tunnel endpoint of the peer.
Locally Configured IPSec
For the PDSN on the Catalyst 76xx series, IPSec tunnels are terminated on the VPN Acceleration Module. The role of the PDSN is to retrieve parameters from the AAA server and, based on these parameters, 'trigger' IPSec tunnel establishment. Synchronization of these parameters is sufficient to preserve IPSec tunnels in the event of PDSN failover for intra-chassis configurations. PDSN failover is not coupled with VPN Acceleration Module/SUP failover. Inter chassis configurations and intra-chassis SUP failover does not currently support stateful IPSec.
FA-HA IPSec
FA-HA IPSec tunnels will be preserved when PDSN on 7600 failover occurs for intra-chassis configurations. They will not be preserved for inter chassis configurations.
AAA Server Accounting
Periodic Accounting Synchronization
Accounting information is optionally synchronized between the active and standby images. This synchronization occurs at the configured periodic accounting interval. The counters that are synchronized are g1 and g2, along with the packet counts. Sending an Interim Accounting record will trigger synchronization of the byte and packet counts. Setting the operator-defined periodic accounting interval determines the accuracy of the user-billing record as impacted by PDSN failover. It is possible that undercharging could occur; however, overcharging is not possible.
Accounting with VSA Approach
After a switchover takes place, the first interim or stop accounting record (as appropriate) includes a Vendor Specific Attribute (VSA) (cdma-rfswact) indicating that a switchover has occurred. The inclusion of this VSA is controllable by issuing the cdma pdsn redundancy accounting send vsa swact command.
Note
Here is a sample accounting debug with vsa:
Sep 13 18:23:10.179: RADIUS: Cisco AVpair [34] 16Sep 13 18:23:10.179: RADIUS: 63 64 6D 61 2D 72 66 73 77 61 63 74 3D 31 [cdma-rfswact=1]System Accounting
In a session redundancy setup, an accounting ON will be sent by the active unit only when the whole setup is brought up (accounting ON will not be sent by the newly active unit after a failover). The standby unit does not send any system accounting events under any scenarios. The events, however, are sent in a standalone mode.
A sys-off is sent if reload is issued on the active unit.
New Features in This Release
This section explains new and modified features of Cisco PDSN Release 5.0.
Single IP per Blade
This chapter discusses concepts related to single IP Infrastructure and Manageability requirements for the Service Provider PDSN gateway application. This application is resident on the SAMI service blade of the Cisco 7600 Series Router and is part of the Mobile Internet product family. This section also provides details about how to configure this feature.
This section includes the following sub sections:
•
–
–
–
–
–
–
–
–
•
•
•
Overview of Single IP Feature
The current Mobile Internet gateway-on-SAMI solutions, (WiMax ASNGW, GGSN, and PDSN except HA) all offer a multiple-routers-on-a-stick model with the attendant manageability and operational issues. The system design for PDSN single IP allows you to manage the gateway-on-SAMI on a per-blade basis. This results in a "factor-of-6 decrease" in operational complexity compared to the previous presentation of six individual processors per blade.
Here is an additional targeted subset of functionality that is presented in a per-chassis model. The presentation of a per-blade model applies to the following areas:
•
•
•
•
•
Additionally, the presentation of a per-chassis model applies to the following targeted functionality:
•
•
•
•
Single IP Interface
The following features fall under the umbrella of a single IP per blade:
•
•
•
•
•
Single Interface for MIP, Simple IP, VPDN-based calls or A11 Registrations
The service blade presents one IP address for the A11 registration request. This IP address is common across all processors in the blade. The IP address for vaccess interface is also common across all processors in the blade. Thus, the blade presents one IP address for the single IP calls. Similarly, the service blade presents a distinct IP address (PDSN IP address) for each of its service including Simple IPv6. These addresses are configured as done for Cisco PDSN Release 4.0, but only on one of the processors of the blade. The IP address configuration is present on both control plane and traffic plane processors.
The service blade implements a packet distribution function in IXP ucode, which ensures that user traffic packets are dispatched to the correct traffic plane processor. Packets identified as control plane traffic (such as A11 packets, packet of disconnect POD packets, MIP registration revocation packets, and so on) are sent to the control plane processor. The rest of the control plane packets (PPP Negotiation, AAA authentication, accounting, MIP, and so on) are dispatched to the correct traffic plane processor. Packets that do not match a specific identification are sent to the control plane processor for treatment.
Single Interface for Configuration
The service blade provides a single point of configuration for blade functionality. This means that you can establish a session to the service blade, the same as performed in Cisco PDSN Release 4.0. The session is established to the control processor on the service blade. From that single session to the service blade, you can configure PDSN features each command required for a feature. That configuration is then propagated to all processors that require the same configuration without you performing any additional configuration.
The default treatment for any IOS configuration command is that the configuration takes effect on all IOS processors on the service blade. It is possible to define a set of commands that only executes on the processor hosting the configuration session. Some examples of filtered configuration commands are those relating to OSPF, SNMP, HSRP, BGP, Eigrp, CDP, and sub-commands in the interface configuration mode relating to any of the above.
Single Interface for SNMP Management
The service blade provides a distinct configurable IP address that is the target address for SNMP operations. This IP address is hosted on the control plane processor. All MIBs on a service blade related to PDSN functionality are accessible through this IP address. Information required from processors other than the control plane processor is either pushed or pulled depending on the MIB target.
There are two MIBs related to processor resource usage and memory usage that present information on a per-processor basis. There is a single Processor Resource MIB result returned with six individual entries, one per processor. Similarly, this also occurs for memory usage.
Single Interface for Trouble Shooting and Debug
The service blade provides a single point of entry (session into the control plane processor) to execute show and debug commands. By default, show commands are executed on the control plane processor only. Each command that requires execution on one or more traffic plane processors is individually instrumented.
For debug commands the HA model for single IP is followed for the PDSN as well. For commands that require additional information from the traffic plane processor and are qualified per user (either NAI or IP address), the traffic plane processor hosting that user is identified and the command executed on that specific processor.
The results from the various processors are combined into a single presentation before a response to the command is provided.
Conditional debug commands use a similar approach. The model proposed by Osler for HA is followed in the PDSN as well.
Single Interface for AAA
The service blade presents a single IP address for AAA interactions. This IP address may be one address for both RADIUS-based interactions, or separate IP address configurations for each protocol.
RADIUS-based authentication and authorization is executed from the traffic plane processor.
The service blade packet distribution function directs RADIUS traffic to a specific processor based on the destination UDP port.
Single Interface for Failover
The current SAMI failure mode is for a per-processor failure whenever possible. For the single IP model, a failure detected on the blade results in a blade-level failover, even if a processor-level failover is sufficient. This feature is similar to the HA single IP.
Operation and Management
This section discusses features that fall under the umbrella of Operation and Management and describes:
•
•
•
•
Chassis-Wide MIB for Application-Related Parameters
This feature provides a single MIB within which all application-related parameters are reported across the chassis. For PDSN, this functionality is provided on a per-PDSN instance basis.
For all PDSN instances on a single service blade, this information is available through an SNMP Get to a single IP address. The information is available in the CISCO-PDSN-MIB. CISCO-CDMA-PDSN-EXT-MIB and in the CISCO-IP-LOCAL-POOL-MIB. The SNMP manager is responsible for executing the necessary number of SNMP GET operations to retrieve a MIB per PDSN instance. This release of the single IP PDSN feature supports one PDSN instance per service blade, thereby reducing the number of Get operations from 12 per service blade to 2.
AAA Responsiveness Test Tool and Traps
There are two aspects to this function:
•
•
AAA Responsiveness Test Tool
This release does not support the AAA responsiveness test tool.
Trap Generation for AAA Unresponsiveness
Refer the Trap Generation for AAA Server Unresponsiveness.
Show Subscriber
This feature provides—from a single point in the chassis—summary listings of subscribers hosted by the PDSN instances in the chassis. This release supports a single PDSN instance per service blade, so the sequence of steps necessary is limited to requesting the desired information using IOS CLI commands for one, or all, service blades.
Table 8 lists the feature's functionality:
Here is a list of the possible output display formats:
•
•
•
This functionality is not supported through SNMP.
Intra-Chassis Configuration Synchronization
This feature provides that any configuration command executed on the active blade must automatically be synchronized on the partner standby blade by enabling auto synchronization feature. This applies to all commands, except the configuration commands on the active or standby partnering model, PDSN redundancy, and the configuration commands for configuring HSRP, standby command, as a failure detection mode for redundancy.
This feature is disabled by default and can be enabled by the auto-sync all command in configuration mode. The "write memory" needs to be performed before the standby is up.
Note
How an active or standby PDSN is determined is based on the Radio Frequency (RF) infrastructure that is used for Stateful SwitchOver (SSO) support, as well as for Session Redundancy support for various Mobile Severely Errored Frames (mSEF) gateways.
Initialization
The SSO configuration synchronization happens automatically during bootup without any pre-required configurations. The same synchronization cannot be applied to the PDSN as IP connectivity between the redundant units is required before RF negotiation. Therefore, different yet related configurations are necessary for the active and standby blades.
Additionally, the SSO configuration synchronization feature does not support any unique configuration on each of the redundant units. On the PDSN, HSRP and RF Interdev protocols are required, both of which require certain unique configurations on the redundant units.
The existing commands that require unique configurations for each unit are modified to accommodate configurations for the peer unit. A new command identifies the peer slots. These commands are parsed and the RF negotiation state RF_PROG_STANDBY_CONFIG is used to trigger configuration synchronization automatically. Refer Configuration Details section for the new commands.
RF Client
As in the case of SSO configuration synchronization, the PDSN configuration synchronization is also an RF client. The configuration synchronization feature registers a callback with RF for the progression and status events. The RF notifies each of these registered clients in order with the progression and status of events, thus allowing the PDSN to know when to synchronize the configuration files.
Configuration Files and Synchronization
The configuration synchronization feature comprises the startup configuration and the running configuration processes.
The startup configuration is stored in the NVRAM as a text file. This file is synchronized whenever you perform operations such as write memory, copy running startup, and so on. If the file is opened for a write operation, synchronization starts after the file is closed.
A running configuration synchronization is dynamically generated by certain operations, so any time a synchronization is performed, the running configuration must be generated.
In the SSO implementation, before the synchronization process begins, the primary is locked. A bulk synchronization of the startup configuration and the running configuration is performed, followed up by a parser mode synchronization.
After both the processes are in synchronization and the primary is unlocked, the line-by-line synchronization begins.
All the synchronizing processes require a transport mechanism to communicate between the redundant units.
The PDSN configuration synchronization feature may use one the following transport mechanisms:
•
•
•
The first is the fastest solution from an implementation perspective but it does not scale well for an inter-chassis solution. In this release, PDSN supports the second option, RF or CF SCTP.
Bulk Synchronization
RF Interdev communication needs to be established between the two units prior to initiating the bulk synchronization. Each unit parses its startup configuration and this will cause the unit to become active or go into standby. The active unit will then bulk synchronize its running and private configuration files to the standby if there has been running or private configuration modifications on it after bootup.
After the bulk synchronization, the standby will reload itself and come up with the altered configurations. During this standby reload phase, no configurations are allowed on the active unit.
The configurations that are synchronized during initialization include:
•
•
The startup configuration is not synchronized because the startup config files in the SUP are always in synchronization.
If a private configuration is changed after bootup, the active unit copies its private configuration file into a buffer and transports the file using RF Interdev SCTP to the standby.
If running configurations change after bootup, the active unit copies its running configuration file to a buffer and transports the file using RF Interdev SCTP to the standby. Following these steps, the active sends a message to the standby to start parsing the received buffers.
The standby unit saves the received buffer contents locally, and reloads itself to apply the modified configuration to itself.
Note
Line-by-Line Synchronization
When both active and standby units are up and running, the CLI command entered from the active unit is executed first, the command is then propagated to the standby and executed, and the results are returned back to the active unit.
The Parser Return Code (PRC) scheme is used in the SSO implementation to have all the parser action routine for each CLI command set the return code. This return code is a combination of the class of the error code, component ID, sync-bit, sub-code, and so on.
Parser Mode Synchronization maintains the same parser mode between the active and standby units before a command is sent to slave for synchronization.
In the SSO implementation, the synchronization is done through RPC, which blocks the current process until the active RP receives return code message from the standby RP. Thus, the commands are executed in order for both units.
If a command fails on the standby unit, then the result is conveyed back to the active. On the active, a stub registry for the policy maker is invoked that leaves the decision on what to do with the returned result to the calling or upper layer.
The single IP PDSN configuration synchronization feature uses the SSO line-by-line synchronization implementation as is.
Startup Configuration Synchronization
In the SSO implementation, the startup configuration is synchronized during bootup when the RF state is ready to perform bulk synchronization. You must lock the router before initiating the startup configuration synchronization.
When a write memory or copy file1 startup-config is executed, there are two ways to handle the scenario:
•
•
For the single IP PDSN, bulk synchronization of the startup configuration file is used because it allows the active unit to save configuration changes to the standby location.
Running Configuration Synchronization
With a running configuration synchronization, the redundancy units carry the same state of information.
Initially, after the secondary unit establishes RF Interdev communication, the running configuration file is bulk synchronized. The bulk synchronization induces a self-reload of the standby unit if the running configuration has changed on the active unit prior to its bootup. After the reload, the standby comes up with the running config of the active unit.
After this the line-by-line synchronization occurs between the two units. As you configure each command, the same command is passed on to the secondary side after executing the same on the primary.
The bulk synchronization of the running configuration is done using the RF Interdev SCTP for the single IP PDSN feature.
Limitations
The following are the limitations when configuring the intra-chassis:
•
•
•
•
Configuration Details
Using the auto synchronization feature, the configurations are synchronized, and the CLIs on both the units must be identical. This feature is disabled by default. The following commands are currently unique to each redundant unit and have been modified:
•
•
•
•
•
•
•
The following new command is introduced under the interface GigabitEthernet0/0.23:
redundancy ip address unit1 ip1 mask1 unit2 ip2 mask2The redundancy ip address command is a per-interface command. The HSRP protocol uses this IP address configured for its negotiation, and not the one configured using the regular ip address command. You do not require the ip address configuration for a sub-interface that is dedicated for HSRP negotiation with the peer.
redundancy unit1 slot x unit2 slot yThe redundancy slot command is a global configuration and is used for identifying the peer slot.
To configure intra-chassis configuration synchronization, perform the following tasks:
redundancy unit1 slot x unit2 slot yunit1-port portnum , unit2-port portnumunder the ipc-assoc-protocol-sctp mode.
unit1-ip address1 , unit2-ip address2under the ipc-unit1-port and ipc-unit2-port modes respectively.
redundancy ip address unit1 address1 mask1 unit2 address2 mask2under the interface and sub-interface modes.
Sequence of configuration steps that must be performed on each of the cards:
When session redundancy is configured for the first time with auto synchronization feature enabled, you must configure only one unit and the other unit must be powered down.
After the configuration is done, ensure that you run the write memory on unit1, then power up unit2.
Monitor Subscriber
This feature allows you from a single point in the chassis to establish conditional debugs based on the NAI or the assigned IP address. This is possible without knowing which PDSN instance in the chassis hosts the subscriber session or is selected to host the subscriber session for cases when the session is not yet established. This feature make use of the Osler tool that allows centralized execution of IOS commands with the ability to receive responses and present those responses in a clear and concise format.
There are two output formats, brief, where the debug output is succinctly presented, and verbose which is the complete debug output.
You must log in to the Supervisor of the 7600, and then execute the command debug condition "qualifier" protocols.
You need to implement the below two-stage process:
1.
2.
It is possible to specify the protocol subsystems for which conditional debugging applies. The choices are Session, Accounting, TFT, VPDN, MIP, PMIP, All and so on.
There is a limit of ten simultaneous pre-triggers.
Note
Show Subscriber Session
You log in to the Supervisor of the 7600 and then execute the show subscriber session command where the subscriber is identified by IMSI, NAI or IP address.
You need to implement the below two-stage process:
•
•
Bulk Statistics Collection
This feature is capable at a single point:
•
•
•
You can set the statistics collection period to increment by 15 minutes, the minimum collection period being 30 minutes. The maximum collection period is 24 hours.
The file content contains summary statistics for each blade except that relating to CPU usage and memory occupation available on a per-CPU basis collected per blade. The per-blade file has an entry for each application CPU on that blade.
The file format is a sequence of "variable_name value" pairs separated by commas.
In Cisco PDSN Release 5.0, the variable name is the OID of the variable as this is the level of support available from the IOS Bulk Statistics Collection CLI command.
There is a predefined set of statistics that is collected, including the variables available in the MIBs that are supported by the PDSN application. The OID assigned to the statistic corresponds directly to the OID in the related MIB.
The following variables of interest are not present in a MIB. These are not supported as part of the Bulk Statistics Collection feature:
•
•
•
•
•
•
The time-period over which collection is made is indicated in the file in the format yy:mm:dd:hh:mm:ss yy:mm:dd:hh:mm:ss. The first date is the start; the second date the end.
If you want to alter the set of subsystems for which statistics collection is enabled, you must first cancel the ongoing statistics collection and begin a new collection. Any information that you collect during the cancelled session is saved.
In the event that the external server is unavailable, the file is saved in local non-volatile memory. The last transferred file is saved locally until the next file is successfully transferred. On successful transfer of the new file, the currently saved file is replaced with the new one.
No new IOS commands are used to support the bulk statistics feature in the single IP PDSN Release 5.0.
Redundancy Support in Cisco PDSN Release 5.0
Redundancy support for Cisco PDSN Release 5.0 features is identical to that supported in Release 4.0 of the PDSN.
The session redundancy is extended to support the single IP architecture. Only one processor (that is PCOP) per SAMI is involved in redundancy management. All the other processors (such as TCOPs) follow the PCOP's state. Configuration synchronization from active to standby is supported in the Cisco PDSN Release 5.0
Performance Requirements
The single IP PDSN supports the following performance figures:
•
•
•
•
Single IP Support - Reused and New CLI Commands
The following CLI commands are provided to allow IPC to communicate with IXP, and to allow GTP and IPC over GTP modules to provide reliable, acknowledged and unacknowledged communication capabilities between the SAMI PPCs:
EXEC Mode
•
•
•
•
•
•
•
•
Show Commands
•
•
•
Configuration Mode:
•
•
•
•
•
•
•
•
The sami ipc crashdump command in configuration mode is as follows:
pdsn-Stdby-ftb3-73(config)# sami ipc crashdump ?
never Do not crash in response to an IPC failure.
tolerance Specifies permitted duration of IPC link failure.
Distributed Configuration, Show and Debug commands in Single IP PDSN
The following sections describe the distributed configuration, show and debug commands in single IP PDSN.
Distributed Configuration
The Distributed CLI agent distributes the configuration information from the PCOP to each of the TCOPs using the IPC protocol.
By default, the CLI agent allows all the commands, but filter the ones that may trigger some functionality on the TCOP that is not needed.
Non-CDMA (the Rest of IOS) Configuration Commands
A set of non-cdma CLI commands are blocked or filtered on the PCOP.
The list of commands that are filtered on the PCOP are:
•
•
•
•
•
•
•
The routing protocols are not sent to TCOPs. We do not recommend configuring the routing protocols on SAMI, it is preferable to set up static routing configurations between SAMI and SUP.
While allocating the IP address pools on the SAMI, we recommend you to configure their respective static routing entries on the SUP.
IP Local Pool Command Change
This command is reused from the GGSN Centralized Pools implementation.
CDMA-related Configuration Commands
For the single IP model, an EXEC banner appears when logging in to a TCOP and warns you to be aware that "normal" maintenance activities should be run from PCOP.
The Table 9 lists the commands that PDSN single IP supports, and indicates whether they are filtered at the PCOP or also sent to the TCOPs.
If the command is sent to the TCOPs, then it is executed at each of the TCOPs.
PDSN Commands for Local Subscriber QoS Profile
The cdma pdsn multiple service flows qos subscriber profile command takes you to a submode. Table 10 lists the commands that you can use to configure various parameters in the local subscriber QoS profile.
Note
Refer Configuring the PDSN Image section for the below configuration tasks:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Configuring Host Routes
Host routes are added in general on the TCOPs for the mobile. In case of SingleIP, any ARP request for the MIP address lands on the PCOP. To enable PCOP to respond to ARP requests, enable this CLI command. This CLI command installs the host route for the mobile on the PCOP when the flow comes up, and deletes the host route whenever the flow goes down.
This CLI command is required only when the host routes are not added at the Supervisor for MIP. By default, this CLI command is not configured (Table 11):
Table 11 Configuring Host Routes
[no] cdma pdsn sm add mobile route
Configures or removes configuration of host route on the PDSN.
TCOP
Clear Commands
Table 12 lists the clear commands:
Distributed Show and Debug
By default, all the debug commands are executed in the TCOPs, and the trace is displayed from the PCOP. The PCOP does not perform any aggregation for distributed debug.
Distributed Show - The rule to be followed for distributed show command is that, only for the commands mentioned in the Existing show Commands, aggregation is done at the PCOP for the data collected from the TCOPs. By default, the show commands are not executed at all TCOPs.
Distributed Debug - The rule to be followed for distributed debug commands is that, by default, all the debug commands are executed in the TCOPs, and the trace is displayed from the PCOP. The PCOP does not perform any aggregation for distributed debug.
New Show Commands in The Single IP Architecture
The following example snippets show the new show commands in the single IP architecture:
pdsn# show sami sm imsi IMSIshow sami sm imsi 12345678910112Session Manager User DetailsIMSI: 12345678910112 Location:7(7000000)Call DetailsIP Address: 12.1.1.31 VRF ID:0HA IP Address: 0.0.0.0 NAI: user1pdsn# show sami sm statisticsSession Manager StatisticsRequest Sent:Session: 4 Control: 0Control AAA: 0 Control HA: 0Request Received:Session Create: 5 Session Delete: 4Flow Create: 6 Flow Delete: 5Agg resp: 0Response Sent:Session Create Success: 5 Session Create Failure: 0Session Delete Success: 4 Session Delete Failure: 0IMSI update: 0 IMSI delete Generated : 0Flow Create Success: 6 Flow Create Failure: 0Flow Delete Success: 5 Flow Delete Failure: 0IXP Update:Total: 0 Success: 0Failure: 0Failure:Message parsing: 0 Internal 1: 0Internal 2: 0 PPC not found: 0Timer Expiry: 0 Pool Manager: 0Flow message parse : 0PDSN-Act-ftb3-83# sh cdma pdsn statistics smPPC Stats:Imsi Create Request to PPC Success 4, Failure 0Imsi Delete Request to PPC Success 4, Failure 0Imsi Response from PPC Success 4, Failure 0CCB Create Request to PPC Success 0, Failure 0CCB Delete Request to PPC Success 0, Failure 0CCB HA Create Request to PPC Success 4, Failure 0CCB HA Delete Request to PPC Success 4, Failure 0CCB Response from PPC Success 4, Failure 0IXP A10 Add Send Success 4 Failure 0, Received Success 4 Failure 0IXP A10 Delete Send Success 4 Failure 0, Received Success 4 Failure 0IXP CCB Add Send Success 0 Failure 0, Received Success 0 Failure 0IXP CCB Delete Send Success 0 Failure 0, Received Success 0 Failure 0IXP CCB HA Add Send Success 4 Failure 0, Received Success 4 Failure 0IXP CCB HA Delete Send Success 4 Failure 0, Received Success 4 Failure 0IXP Nack terminated session 0 flow 0Ack timer expiry Imsi 0, Ccb 0Tunnel PPC Stats:Tunnel Create Request Rcvd 3, Sent Ack 3 Nack 0Tunnel Delete Request Rcvd 3, Deleted 3Invalid Tunnel Request Type Rcvd 0PDSN-Act-ftb3-83#PDSN-Act-ftb3-83#Table 13 lists the distributed show commands.
Existing show Commands
The show commands can be categorized into Data Aggregator (DA)/Data Provider (DP) model or remote console and logging (RCAL) model. Commands under the RCAL model are executed directly on the TCOP from either the SUP or the PCOP without any aggregation using execute-on command. All non-cdma related commands can be executed only through this method.
Commands under DA/DP category are executed on the PCOP and either show the values present in the PCOP itself or show the aggregated output received from all TCOPs.
These commands are further classified as push commands and pull commands.
Push commands - The push commands do aggregation from all the TCOPs periodically and get displayed on the PCOP on demand (that means, on executing the corresponding CLI command).
The list of existing push-based show commands are:
•
•
•
•
•
•
•
•
•
•
Pull commands - The pull commands do aggregation only on executing the commands under this category. On executing the CLI command, the data or statistics are fetched from the TCOPs at that instant and displayed.
The list of existing pull-based show commands are:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Changes to Clustering show Commands
The changes to clustering show commands are given below:
show cdma pdsn cluster controller member 2.1.1.1PDSN cluster member 2.1.1.1 (local) state ready, Group NONE <--- Newregistered with PDSN controller 11.1.1.50reported load 1 percent, will be sought in 2 secondsMember 2.1.1.1 statistics:Number of sessions 0Controller seek rcvd 6122, Member seek reply rcvd 6122Member state changed 0 time to readyMember state changed 0 time to Admin prohibitedSession-Up message rcvd 0, Session-Down message received 0Member seek not replied in sequence 0show cdma pdsn cluster controller configurationcluster interface GigabitEthernet0/0.341 (collocated)no R-P signaling proxytimeout to seek member = 10 secondswindow to seek member is 2 timeouts in a row if no reply (afterwards the member is declared offline)default: spi 101, Timestamp +/- 0, key ascii hellothis PDSN cluster controller is configuredController maximum number of load units = 100show cdma pdsn cluster member configurationcluster interface GigabitEthernet0/0.341IP address of controller is 11.1.1.50 (collocated) <--- Newno prohibit administrativelytimeout to resend status or seek controller = 10 sec or less, randomizedresend a msg for 2 timeouts sequentially if no reply, then inform operatordefault: spi 101, Timestamp +/- 0, key ascii hellothis PDSN cluster member is configuredChanges to Show commands
The changes to show commands are given below:
show cdma pdsn pcf:pdsn_act# show cdma pdsn pcfPCF 2.2.2.4 has 1 session, 1 service flowReceived 382 pkts (9750 bytes), sent 391 pkts (10585 bytes)pdsn_act#Displays only the tunnel information. Sessions associated with that tunnel will not be displayed.show cdma pdsn pcf <pcf-ip-addr>:pdsn_act# show cdma pdsn pcf 2.2.2.4PCF 2.2.2.4 has 1 session, 1 service flowReceived 382 pkts (9750 bytes), sent 391 pkts (10585 bytes)pdsn_act#Displays only the tunnel information. Sessions associated with that tunnel will not be displayed.show cdma pdsn statistics:san-pdsn# show cdma pdsn statisticsLast clearing of "show cdma pdsn statistics" counters neverLast Update received at 00:12:54 UTC Mar 1 2009 <--- NewRP Interface:Reg Request rcvd 0, accepted 0, denied 0, discarded 0Initial Reg Request rcvd 0, accepted 0, denied 0, discarded 0, AuxRequest 0Re-registration requests rcvd 0, accepted 0, denied 0, discarded 0Re-registration requests containing Active-Start 0, Active-Stop 0Re-registration requests containing new connections 0, missing connections 0, remapping flows 0Handoff requests rcvd 0, accepted 0, denied 0, discarded 0,AuxRequest 0De-registration rcvd 0, accepted 0, denied 0, discarded 0De-registration Reg Request with Active-Stop 0Registration Request Errors:Unspecified 0, Administratively prohibited 0Resource unavailable 0, Authentication failed 0Identification mismatch 0, Poorly formed requests 0Unknown PDSN 0, Reverse tunnel mandatory 0Reverse tunnel unavailable 0, Bad CVSE 0Max Service Flows 0, Unsupported So 0, Non-Existent A10 0Bandwidth Unavailable 0Update sent 0, accepted 0, denied 0, not acked 0Initial Update sent 0, retransmissions 0Acknowledge received 0, discarded 0Update reason lifetime expiry 0, PPP termination 0, other 0Registration Update Errors:Unspecified 0, Identification mismatch 0Authentication failed 0, Administratively prohibited 0Poorly formed request 0Handoff statistics:Inter PCF handoff active 0, dormant 0Update sent 0, accepted 0, denied 0, not acked 0Initial Update sent 0, retransmissions 0Acknowledge received 0, discarded 0De-registration accepted 0, denied 0Handoff Update Errors:Unspecified 0, Identification mismatch 0Authentication failed 0, Administratively prohibited 0Poorly formed request 0RP Session Update statistics:Update sent 0, accepted 0, denied 0, not acked 0Initial Update sent 0, retransmissions 0Acknowledge received 0, discarded 0Sent reasons Always On 0, RN-PDIT 0, Subscriber Qos 0RP Session Update Errors:Unspecified 0, Identification mismatch 0Authentication failed 0, Session parameters not updated 0Poorly formed request 0Service Option:Address Stats:Simple IP: Static 0, Dynamic 0Mobile IP: Static 0, Dynamic 0Proxy Mobile IP: Static 0, Dynamic 0Simple IP VPDN: Static 0, Dynamic 0Flow Stats:Simple IP: Success 0, Failure 0Mobile IP: Success 0, Failure 0Proxy Mobile IP: Success 0, Failure 0Simple IP VPDN: Success 0, Failure 0Unknown Service Failures: 0PPP:Current Connections 0Connection requests 0, success 0, failure 0, aborted 0Connection enters stage LCP 0, Auth 0, IPCP 0Connection success LCP 0, AUTH 0, IPCP 0Failure reason LCP 0, authentication 0, IPCP 0, other 0Failure reason lower layer disconnect 0A10 release before LCP nego by PDSN 0, by PCF 0LCP StageFailure Reasons Options 0, MaxRetry 0, Unknown 0LCP Term Req during LCP nego sent 0, rcvd 0A10 release during LCP nego by PDSN 0, by PCF 0Auth StageCHAP attempt 0, success 0, failure 0, timeout 0PAP attempt 0, success 0, failure 0, timeout 0MSCHAP attempt 0, success 0, failure 0, timeout 0EAP attempt 0, success 0, failure 0MSID attempt 0, success 0, failure 0AAA timeouts 0, Auth timeouts 0, Auth skipped 0LCP Term Req during Auth nego sent 0, rcvd 0A10 release during Auth nego by PDSN 0, by PCF 0IPCP StageFailure Reasons Options 0, MaxRetry 0, Unknown 0Options failure reason MN Rejected IP Address 0LCP Term Req during IPCP nego sent 0, rcvd 0A10 release during IPCP nego by PDSN 0, by PCF 0CCP StageConnection negotiated compression 0Compression type Microsoft 0, Stac 0, other 0Connections negotiated MRRU 0, IPX 0, IP 0Connections negotiated VJ-Compression 0, BAP 0PPP bundles 0Connections failed to negotiate compression 0Renegotiation total 0, by PDSN 0, by Mobile Node 0Renegotiation success 0, failure 0, aborted 0Renegotiation reason: address mismatch 0, lower layer handoff 0GRE key change 0, other 0Release total 0, by PDSN 0, by Mobile Node 0Release by ingress address filtering 0Release reason: administrative 0, LCP termination 0Idle timeout 0, echo missed 0L2TP tunnel 0, insufficient resources 0Session timeout 0, service unavailable 0De-Reg from PCF 0, lifetime expiry 0, other 0Echo statsRequest sent 0, resent 0, max retransmit timeout 0Response rcvd 0Discarded PacketsUnknown Protocol Errors 0, Bad Packet Length 0RSVP:IEs Parsed 0TFTs Created Success 0, Failure 0TFTs Updated Success 0, Failure 0TFTs Deleted Success 0, Failure 0Other Failure 0Unknown 0, Unsupported Ie types 0Tft Ipv4 Failure StatsTft Unauthorized 0, Unsuccessful Processing 0Tft Treatment Unsupported 0Packet Filter Add 0, Replace 0Packet Filter Precedence Contention 0, Unavailable 0Packet Filter Maximum Limit 0, Non-Existent Tft add 0QOS:Total Profile Download Success 0, Failure 0Local Profile selected 0Failure Reason DSCP 0, Flow Profile ID 0,Service option profile 0, Others 0Total Consolidated Profile 0, DSCP Remarked 0Total policing installed 0, failure 0, removed 0slot 0:AHDLC Engine Type: CDMA HDLC SW ENGINEEngine is ENABLEDtotal channels: 375000, available channels: 375000Framing input 0 bytes, 0 paksFraming output 0 bytes, 0 paksFraming errors 0, insufficient memory 0, queue overflow 0Invalid size 0Deframing input 0 bytes, 0 paksDefaming output 0 bytes, 0 paksDeframing errors 0, insufficient memory 0, queue overflow 0Invalid size 0, CRC errors 0RADIUS DISCONNECT:Disconnect Request rcvd 0, accepted 0Disconnect Request Errors:Unsupported Attribute 0, Missing Attribute 0Invalid Request 0, NAS Id Mismatch 0Session Cxt Not Found 0, Administratively ProhibitedSimilar to show cdma pdsn statistics, if we execute any of the individual statistics except for sm, the following line appears at the start:
Last Update received at 00:12:54 UTC Mar 1 2009 <--- Newrouter# show cdma pdsn statistics ?ahdlc AHDLC informationppp CDMA PDSN ppp statisticsprepaid CDMA PDSN prepaid statisticsqos CDMA PDSN QOS statisticsraa CDMA PDSN RAA statisticsradius CDMA PDSN traffic statisticsrp CDMA PDSN RP statisticssm CDMA PDSN SM statisticstft CDMA PDSN TFT statistics| Output modifiers<cr>router#show cdma pdsn statistics rp error:san-pdsn# show cdma pdsn statistics rp errorLast clearing of "show cdma pdsn statistics rp error" counters neverLast Update received at 00:12:54 UTC Mar 1 2009 <--- NewRP Registration Request Error Reasons:Invalid Packet length 0, Protocol 0, Flags 0Invalid Connection ID 0, Authentication Key 0, SPI 0, Mismatch SPI 0Invalid Mobile ID 0, ID type 0, ID length 0Invalid Extension Order 0, VSE type 0, Vendor id 0Invalid Application type 0, Sub Application type 0Missing extension SSE 0, MHAE 0Duplicate Application type 0, GRE Key 0, CVSE 0Airlink Retransmission with same sequence number 0Airlink Invalid attribute length 0, sequence number 0, record 0Airlink Unknown attribute 0, Duplicate attribute 0Airlink Initial RRQ No Setup 0, Contains Stop 0, Contains SDB 0Airlink Start before Setup 0, Start in De-Registration 0Airlink GRE Key change no Setup 0, Rereceive Setup with same GRE Key 0Airlink Start rcvd during active 0, Stop rcvd during dormant 0De-Registration received for unknown session 0Re-Registration received during session disconnect 0Processing error due to memory failure 0RP Registration Update Ack Error Reasons:Invalid Packet length 0, Protocol 0Invalid Connection ID 0, Authentication Key 0, SPI 0Invalid Mobile ID 0, ID type 0, ID length 0Invalid Extension Order 0, VSE type 0Missing extension SSE 0, RUAE 0Received for unknown session 0, discard memory failure 0RP Session Update Ack Error Reasons:Invalid Packet length 0, Protocol 0Invalid Connection ID 0, Authentication Key 0, SPI 0Invalid Mobile ID 0, ID type 0, ID length 0Invalid Extension Order 0, VSE type 0Missing extension SSE 0, RUAE 0Received for unknown session 0, discard memory failure 0RP Registration Reply Error Reasons:Not sent memory allocation failure 0, Internal error 0Reply not sent to PCF security not found/parse error 0RP Registration Update Error Reasons:Not sent memory allocation failure 0, Internal error 0RP Session Update Error Reasons:Not sent memory allocation failure 0, Internal error 0Other Error Reasons:Maximum configured/limit number of session reached 0show cdma pdsn cac:pdsn_act# show cdma pdsn cacOutput in Values Output in percentageTotal configured bandwidth 2000000 b 100%Allocated bandwidth 100 b 0%Available bandwidth 1999900 b 100%Sessions allocated 1 0%Max sessions allowed 175000 100%PDSN_ACT#
Note
Debug Commands in the Single IP Architecture
Table 14 shows the debug commands in the single IP architecture:
Network Management and MIBs
See the Radius disconnect enabled section.
Features Not Supported
Cross chassis configuration synchronization.
Summary of Features Reused from Other Gateways
•
•
•
•
•
•
•
•
•
Summary of Features Reuseable in Other Gateways
The following features that are included in the single IP subsystem as part of PDSN single IP are reused by other gateways:
•
•
•
•
Refer the Command Reference for Cisco PDSN Release 5.0 in IOS Release 12.4(22)XR for more information about configuration commands for Single IP per Blade in Cisco PDSN Release 5.0.
Osler Support
The Operator Interface for Multiple Service blades for the single IP PDSN product is used to provide a single OAM viewpoint for a defined set of functionality. This support means that you can see the whole chassis as a black box without worrying about the multiple service blades having multiple processors, active or standby configuration, and so on.
The implementation reduces dependence on customer OAM deployments and provides real-time diagnostics to allow quick or proactive problem resolution. It also helps in ongoing verification of dimensioning parameters; namely, network predictability, repair or recovery based on problem identification.
This section describes:
Installing Osler
The PDSN Osler Package is a TCL executable file (pdsn_Osler-Package.tcl) along with an archival file (pdsn_osler.tar). You need to download the executable file and archival file to the flash of the supervisor from where you choose to use PDSN Osler Policies.
As the PDSN Osler Package is bundled as part of the SAMI image, first you need to copy both the files (that is, pdsn_Osler-Package.tcl and pdsn_osler.tar) from the respective SAMI LCP (Processor 0) to disk0: of SUP.
Installation Commands for Osler
You need to issue the following commands on SUP prompt:
pdsn-osler# copy sami# slot_number-fs:image/scripts/pdsn_Osler-Package.tcl disk0:
pdsn-osler# copy sami# slot_number-fs:image/scripts/ pdsn_osler.tar disk0:
Once both the files have been copied to the disk0: of SUP, to see the options available within the package on the SUP execute the command tclsh disk0:pdsn_Osler-Package.tcl --help. The command output is as shown below (Table 15).
Sample Installation of Osler
To install the PDSN Osler Package, the following is an example:
Single chassis environment:
tclsh disk0:pdsn_Osler-Package.tcl -pkg install -f disk0:pdsn_osler.tar -maxP 9 -tftpN 1.1.1.19 -statLD disk0:stats -statRD dirname/stats/globalStats -statT 30 -subRD nishigup/Osler_Lib -traceLD disk0:/traces -traceRD dirname/tracesThe above example assumes that:
•
•
Tip
To uninstall the PDSN Osler Package, the following is an example:
Single chassis environment:
tclsh disk0:pdsn_Osler-Package.tcl -pkg uninstall
Note
•
•
•
Show Subscriber Commands
The CLI commands are invoked on the processors running the active PDSN instances to query the subscriber, matching one or more of various conditions. The conditions are:
•
•
•
•
•
•
•
•
•
•
Three display formats are provided: summary, brief, and verbose.
•
•
•
The Osler CLI collects the output of the commands from the processors, collates the results and presents, as if one command is executed. You must provide the option to collect the data in a file or to display the data on the screen for the verbose and brief options.
Show Subscriber Verbose All
This command shows all the subscribers on the chassis. This command internally use show cdma pdsn session detail and parse the output.
Caution
The policy runs the summary command first and checks for the users per PCOP. If the number of the subscribers exceeds the recommended numbers for the terminal display, you need to select the file option. If you have not selected the file option, the PCOP is ignored.
You can use the IOS CLI command show cdma pdsn session detail for this purpose. tftp://tftp-ip/user/[dir]/PPC3-SLOTNumber-subs-[date-time].txt is used collect all the data into a file on the TFTP server.
Note
The below example is a snippet of the display output:
----------- Slot 1/CPU 5, show cdma pdsn session detail-------------Mobile Station ID IMSI 09003000001PCF IP Address 6.6.6.2, PCF Session ID 1A10 connection time 02:25:51, registration lifetime 65535 secNumber of successful A11 reregistrations 0Remaining session lifetime INFINITEAlways-On not enabled for the userCurrent Access network ID 0006-0606-02Last airlink record received is Active Start, airlink is activeGRE protocol type is 0x8881GRE sequence number transmit 867, receive 860Using interface Virtual-Access2.1, status OPNUsing AHDLC engine on slot 0, channel ID 10Service Option EV-DO Flow Discrimination 0 DSCP Included 0Flow Count forward 0 reverse 0This session has 1 flowThis session has 0 service flowsSession Airlink State ActiveThis session has 0 TFTsQos subscriber profileMax Aggregate Bandwidth : 1Inter User Priority : 1000Maximum Flow Priority : 120980Forward profile-id : 4660Forward profile-id : 9097Forward profile-id : 14454Reverse profile-id : 6295Reverse profile-id : 17185Bidirectional profile-id : 22136Bidirectional profile-id : 26505Flow service Simple, NAI osler1Mobile Node IP address 4.4.4.1Packets in 0, bytes in 0Packets out 0, bytes out 0Qos per flow : osler1Max Aggregate Bandwidth : 1Inter User Priority : 1000Maximum Flow Priority : 120980Number of Persistent Tft : 34567Forward profile-id : 4660Forward profile-id : 9097Forward profile-id : 14454Reverse profile-id : 6295Reverse profile-id : 17185Bidirectional profile-id : 22136Bidirectional profile-id : 26505Show Subscriber Brief All
This command is implemented to show all the subscribers in the chassis. This command internally uses show cdma pdsn session brief and parses the output.
Caution
The policy runs the summary command first and checks for the users per PCOP. If the number of the subscribers exceeds the recommended numbers for the terminal display, you need to select the file option. If you have not selected the file option, the PCOP is ignored.
You can use the IOS CLI command show cdma pdsn session detail for this purpose. tftp://tftp-ip/user/[dir]/PPC3-SLOTNumber-subs-[date-time].txt is used collect all the data into a file on the TFTP server.
Note
The below example is a snippet of the display output:
----------- Slot 1/CPU 5, show cdma pdsn session brief-------------MSID PCF IP Address PSI Age St SFlows Flows Interface09003000001 6.6.6.2 1 00:27:02 OPN 0 1 Virtual-Access2.109003000053 6.6.6.5 51 00:00:32 OPN 0 1 Virtual-Access2.2Show Subscriber Summary All
This command is implemented to show summary of all the subscribers in the chassis. This command internally uses show cdma pdsn session summary and parse the output.
The below example is a snippet of the display output:
SHOW SUBSCRIBER SUMMARY-------------------------------Total Number of sessions :121Total Number of Paks in :83866Total Number of Paks out :87872Total Number of bytes in :1341130Total Number of bytes out :2601436Show Subscriber Verbose Card
This command shows all the subscribers on a specific SAMI card. This command internally uses show cdma pdsn session detail on the specified card and then parse the output.
Caution
The policy runs the summary command first and checks for the users per PCOP. If the number of the subscribers exceeds the recommended numbers for the terminal display, you need to select the file option. If you have not selected the file option, the PCOP is ignored.
You can use the IOS CLI command show cdma pdsn session detail for this purpose. tftp://tftp-ip/user/[dir]/PPC3-SLOTNumber-subs-[date-time].txt is used collect all the data into a file on the TFTP server.
Note
The below example is a snippet of the display output:
>> Now enter the SAMI Card ID ([1-13]): 1----------- Slot 1/CPU 5, show cdma pdsn session detail-------------Mobile Station ID IMSI 09003000003PCF IP Address 6.6.6.5, PCF Session ID 1A10 connection time 00:08:36, registration lifetime 65535 secNumber of successful A11 reregistrations 0Remaining session lifetime INFINITEAlways-On not enabled for the userCurrent Access network ID 0006-0606-05Last airlink record received is Active Start, airlink is activeGRE protocol type is 0x8881GRE sequence number transmit 14, receive 0Using interface Virtual-Access2.1, status OPNUsing AHDLC engine on slot 0, channel ID 54Service Option EV-DO Flow Discrimination 0 DSCP Included 0Flow Count forward 0 reverse 0This session has 1 flowThis session has 0 service flowsSession Airlink State ActiveThis session has 0 TFTsQos subscriber profileMax Aggregate Bandwidth : 1Inter User Priority : 1000Maximum Flow Priority : 120980Forward profile-id : 4660Forward profile-id : 9097Forward profile-id : 14454Reverse profile-id : 6295Reverse profile-id : 17185Bidirectional profile-id : 22136Bidirectional profile-id : 26505Flow service Mobile, NAI scdma_osler3@ark.comMobile Node IP address 9.9.9.2HA IP address 5.5.5.2Packets in 0, bytes in 0Packets out 0, bytes out 0Qos per flow : scdma_osler3@ark.comMax Aggregate Bandwidth : 1Inter User Priority : 1000Maximum Flow Priority : 120980Number of Persistent Tft : 34567Forward profile-id : 4660Forward profile-id : 9097Forward profile-id : 14454Reverse profile-id : 6295Reverse profile-id : 17185Bidirectional profile-id : 22136Bidirectional profile-id : 26505Show Subscriber Brief Card
This command shows all the subscribers on a specific card. This command internally uses show cdma pdsn session brief on the specified card and then parse the output.
Caution
The policy runs the summary command first and checks for the users per PCOP. If the number of the subscribers exceeds the recommended numbers for the terminal display, you need to select the file option. If you have not selected the file option, the PCOP is ignored.
You can use the IOS CLI command show cdma pdsn session detail for this purpose. tftp://tftp-ip/user/[dir]/PPC3-SLOTNumber-subs-[date-time].txt is used collect all the data into a file on the TFTP server.
Note
The below example is a snippet of the display output:
>> Now enter the SAMI Card ID ([1-13]): 1----------- Slot 1/CPU 5, show cdma pdsn session brief-------------MSID PCF IP Address PSI Age St SFlows Flows Interface09003000001 6.6.6.2 1 00:28:39 OPN 0 1 Virtual-Access2.109003000053 6.6.6.5 51 00:02:09 OPN 0 1 Virtual-Access2.2Show Subscriber Summary Card
This command shows summary of all the subscribers on a specific card. This command internally uses show cdma pdsn session summary on the specified card and parse the output.
The below example is a snippet of the display output:
>> Now enter the SAMI Card ID ([1-13]): 1SHOW SUBSCRIBER SUMMARY <-> (All Subscribers on the Card: 1)-------------------------------Total Number of sessions :121Total Number of Paks in :84555Total Number of Paks out :88561Total Number of bytes in :1352154
Guest
