Guest

Cisco IOS Software Releases 12.4 Special and Early Deployments

Cisco Packet Data Serving Node Release 5.1 for Cisco IOS Release 12.4(22)XR1

  • Viewing Options

  • PDF (3.1 MB)
  • Feedback
Cisco Packet Data Serving Node Release 5.1 for Cisco IOS Release 12.4(22)XR1

Table Of Contents

Cisco Packet Data Serving Node Release 5.1 for Cisco IOS Release 12.4(22)XR1

Feature Overview

System Overview

How PDSN Works

PDSN Simple IP

PDSN Mobile IP

Randomized IMSI Handling

PMTU Discovery by Mobile IP Client

PDSN Proxy Mobile IP

PDSN on SAMI

Migration Scenarios

Migration Steps

Features

New Features in This Release

Features From Previous Releases

PDSN Performance Metrics

Packet Data Service Access

Simple IP-based Service Access

Simple IP Routed Access

Simple IP VPDN Access

Proxy Mobile IP Access

Mobile IP-based Service Access

Binding Update Procedures

Simple IPv6 Access

Configuring Simple IPv6

Session Redundancy Infrastructure

Functional Overview

In Process Synchronization Events

Handoff

Restrictions

Internals

AAA - Authentication and Authorization

AAA Server Accounting

AAA Server Accounting

New Features in This Release

Simple IP Client IP Accounting Support

SNMP New MIB Objects for Per PCF

Support for Common NAI

Proxy MIP Changes for Latest IS-835

Network-PMIP-NAI Attribute

PMIP-based Mobility Capability Attribute

PMIP-HA-Info-IPv4-Service Attribute

Simple IPv6 Support

Access-Request Attributes

Base Station Identifier (D4) Attribute

PCF IP Address (D3) Attribute

User Zone (E1) Attribute

NAS Port Attribute

Framed IP Address (B1) Attribute

New PPP Per PCF Counters

LCP Phase Failure Counters

Authentication Phase Failure Counters

IPCP Phase Failure Counters

VPDN Conditional Debugging

GRE CVSE and MN NAI Extension in Revocation Message

Single IP per Blade

Overview of Single IP Feature

Single IP Interface

Single Interface for MIP, Simple IP, VPDN-based calls or A11 Registrations

Single Interface for Configuration

Single Interface for SNMP Management

Single Interface for Troubleshooting and Debugging

Single Interface for AAA

Single Interface for Failover

Operation and Management

Chassis-Wide MIB for Application-Related Parameters

AAA Responsiveness Test Tool and Traps

Show Subscriber

Intra-Chassis Configuration Synchronization

Monitor Subscriber

Show Subscriber Session

Bulk Statistics Collection

Redundancy Support in Cisco PDSN Release 5.0

Performance Requirements

Single IP Support - Reused and New CLI Commands

Distributed Configuration, Show and Debug commands in Single IP PDSN

Clear Commands

Distributed Show and Debug

Features Not Supported

Osler Support

Installing Osler

Show Subscriber Commands

Monitor Subscriber Commands

Show Subscriber Session

Bulk Statistics Collection

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

The Controller Redundancy

Configuring Cluster Controller Support

Cluster Controller Member Configuration

IMSI and PCF Redirection

IMSI-based Redirection

PCF-based Redirection

Features of IMSI and PCF-based Redirection

Limitations of IMSI and PCF-based Redirection

Functions of Controller PDSN

Mobile IP and AAA Attributes for China Telecom

Calling Station ID in MIP RRQ

Correlation ID in MIP RRQ

Proxy Mobile IP Indicator Attribute

Proxy Mobile IP Capability Indicator Attribute

PDSN Service Address

Charging Type

MIB Support

MIBs as source of KPIs

Model for MIBs

Trap Generation for AAA Server Unresponsiveness

Supervisor Support

Data Over Signaling

Flow Trigger Classification for DOS

Flow Marking Based on Classification Criteria for DOS

AT-terminated DOS

AT-generated DOS

SDB Accounting Record sent by 1xRTT PCF

Limitations for DOS

Configuring DOS

Differentiated Services Code Point Marking Support

Flow Trigger Classification for DSCP

Flow Marking Based on Classification Criteria for DSCP

Limitations for DSCP

Configuring DSCP

Nortel Aux A10 Support

Masking Off IMSI Prefix

Changes Related to Single IP Architecture

Functional Flow in SingleIP Architecture

Limitations for Masking Off the IMSI Prefix

Configuring Masking Off the IMSI Prefix

Persistent TFT Support

Conserve Unique IP-ID for FA-HA IP-in-IP Tunnel

GRE CVSE Support in FA-HA Tunnel

Remote Address Accounting

Setting up a Session

About the G5 Attribute

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

Inter-PCF Handoff RRQ

Accepted Inter-PCF Handoff

EVDO Network Initial Aux A10 Connection Request

EVDO Network Accepted Initial Aux A10 Connection

Successful PPP Connection Request

Successful PPP Initial Request

Failed PPP Connection 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

Inter-User Priority

Roamer Identification

Served MDN

Framed Pool

3GPP2 DNS Server IP

Virtual Route Forwarding with Sub-interfaces

Configuring PDSN Session Redundancy

Configuring PDSN Session Redundancy Infrastructure

Configuring HSRP

Protocol Layering and RP Connections

Open RP Interface Connections

PPP Connections

Application Flows

PPPoGRE RP Interface

A11 Session Update

SDB Indicator Marking

Signaling of SDB Indication

Identification of Data Packets For SDB Indication

SDB Indicator Marking for PPP Control Packets

Multiple Service Connections

Session Creation—A11 Registration Request

Configuring Multiple Service Connections

Verifying the Configuration

Data Plane

QoS Signaling

Traffic Flow Templates

Configuring TFTs

Verifying the Configuration

Subscriber QoS Policy

Configuring the Subscriber QoS Profile

Verifying the Configuration

Other QoS Parameters

Flow Remapping

Per-flow Accounting

Configuring Per-Flow Accounting

Verifying Per-Flow Accounting

Handoff Scenarios

Call Admission Control

Configuring Call Admission Control on the PDSN

Examples

Verifying the Configuration

Resource Management

Resource Revocation for Mobile IP

Packet of Disconnect

RADIUS Enhancements

RADIUS Server Load Balancing

Subscriber Authorization Based on Domain

IS-835 Prepaid Support

Prepaid Billing

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

Home Area, Maximum Authorized Aggregate Bandwidth, and Inter-user Priority Attributes Downloaded from AAA Server

Configuring Subscriber Qos Profile to PCF

Configuring Bandwidth Policing

Configuring VSAs in Subscriber QoS Profiles

Verifying the Configuration

Mobile IP Call Processing Per Second Improvements

Always On Feature

PDSN MIB Enhancements

Cisco Proprietary Prepaid Billing

How Prepaid Works in PDSN

Prepaid Simple IP Call Flow

Prepaid Mobile IP Call Flow

3DES Encryption

Mobile IP IPSec

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

1xEV-DO Support

Integrated Foreign Agent

AAA Server Support

Packet Transport for VPDN

Proxy Mobile IP

Multiple Mobile IP Flows

Redundancy and Load Balancing

PDSN Cluster Controller / Member Architecture

PDSN Controller-Member Clustering

Redundancy

Load Sharing

PDSN Cluster Member Selection

Load Balancing

Upgrading the Member PDSN Software from Cisco PDSN Release 1.2 to Release 2.0 and Higher

Scalability

High Availability

Related Features and Technologies

Related Documents

Supported Platforms

Supported Standards, MIBs, and RFCs

Configuration Tasks

System Requirements

Memory Requirements

Hardware Supported

Software Compatibility

Determining the Software Version

Upgrading to a New Software Release

Configuring the PDSN Image

Enabling PDSN Services

Creating the CDMA Ix Interface

Creating a Loopback 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 the Mobile IP FA

Configuring Proxy Mobile IP Attributes Locally

Configuring Mobile IP Security Associations

Configuring PDSN Cluster Controller

Configuring PDSN Cluster Member

Enabling Network Management

Configuring Always On Service

Configuring A11 Session Updates

Configuring SDB Indicator Marking

Configuring SDB Indicator Marking for PPP Control Packets

Configuring PoD on the PDSN

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

Configuration Examples

Cisco PDSN Standalone Configuration

Cisco PDSN Session Redundancy Configuration

Cisco PDSN Redundancy Configuration (Auto Synchronization Enabled)

Cisco PDSN Cluster Configuration

Cisco PDSN Member Configuration

Cisco PDSN Controller Configuration

Cisco PDSN Controller Collocated Member with Redundancy

Cisco PDSN Controller Collocated Member (Redundancy with Auto Synchronization Enabled)

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

Simple IPv6 Configuration Example

PDSN Accounting

Flow-based Accounting

AAA Server Authentication and Authorization Profile

AAA Server Profiles for Various Service Types

Attributes

Authentication and Authorization RADIUS Attributes

Accounting Services RADIUS Attributes

Prepaid RADIUS Attributes

Mandatory AVPs in Connection Setup/Release Messages

Q.931 Cause Codes Used in Call Disconnect Notify Message

Glossary

Product Documentation

Related Documentation


Cisco Packet Data Serving Node Release 5.1 for Cisco IOS Release 12.4(22)XR1


Feature History

This table describes feature support for Cisco Packet Serving Node (PDSN) releases.

Release
Modification

12.4(22)XR1

Release 5.1 of Cisco PDSN. The following new features are introduced:

Simple IP Client IP Accounting Support

SNMP New MIB Objects for Per PCF

Support for Common NAI

Proxy MIP Changes for Latest IS-835

Simple IPv6 Support

Access-Request Attributes

New PPP Per PCF Counters

VPDN Conditional Debugging

GRE CVSE and MN NAI Extension in Revocation Message

12.4(22)XR

Release 5.0 of Cisco PDSN. The following new features are introduced:

Single IP per Blade

Osler Support

Improved Throughput and Transaction Handling

Cluster Controller Support in Single IP Blade

IMSI and PCF Redirection

Mobile IP and AAA Attributes for China Telecom

MIB Support

Trap Generation for AAA Server Unresponsiveness

Supervisor Support

Data Over Signaling

Differentiated Services Code Point Marking Support

Nortel Aux A10 Support

Masking Off IMSI Prefix

Persistent TFT Support

Conserve Unique IP-ID for FA-HA IP-in-IP Tunnel

GRE CVSE Support in FA-HA Tunnel

Remote Address Accounting

Default Service Option Implementation

Configurable 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

12.4(15)XR2

Release 4.1 of Cisco PDSN. The following new features are introduced:

Attribute Support

Served MDN

Framed Pool

3GPP2 DNS Server IP

Virtual Route Forwarding with Sub-interfaces

Conditional Debugging Enhancements

12.4(15)XR

Release 4.0 of Cisco PDSN. The following new features are introduced:

Multiple Service Connections

Data Plane

Subscriber QoS Policy (both downloading per-user profile from the AAA server and configuring a local profile)

QoS Signaling

Traffic Flow Templates

Per-flow Accounting

Call Admission Control

PDSN MIB Enhancements

PDSN on SAMI

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:

Home Area, Maximum Authorized Aggregate Bandwidth, and Inter-user Priority Attributes Downloaded from AAA Server

Subscriber QoS Policy

Bandwidth Policing

12.3(14)YX8

Release 3.0 of Cisco PDSN. The following commands are updated:

cdma pdsn cluster member prohibit administratively

subscriber redundancy rate

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:

Support for Mobile Equipment Indentifier

12.3(14)YX

Release 3.0 of Cisco PDSN. The following new features are introduced:

Packet Data Service Access

Simple IPv6 Access

Session Redundancy Infrastructure

RADIUS Server Load Balancing

PPPoGRE RP Interface

Subscriber Authorization Based on Domain

PDSN MIB Enhancements

Conditional Debugging Enhancements

12.3(11)YF3

Release 2.1 of Cisco PDSN.

Added support for:

Randomized IMSI Handling

The following new command is added:

ip mobile cdma imsi dynamic

12.3(11)YF2

Release 2.1 of Cisco PDSN.

Added support for:

Identification of Data Packets For SDB Indication

SDB Indicator Marking for PPP Control Packets

Support for G17 Attribute in Acct-Stop and Interim Records

The following new commands are added or modified:

cdma pdsn a11 dormant sdb-indication match-qos-group

cdma pdsn compliance

cdma pdsn attribute send g17

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:

cdma pdsn compliance

debug cdma pdsn prepaid

debug cdma pdsn radius disconnect nai

show cdma pdsn statistics prepaid

clear cdma pdsn session

clear cdma pdsn statistics adds radius statistics

cdma pdsn mobile-advertisement-burst

ip mobile foreign-service

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, page 5

Features, page 21

Cluster Controller Member Configuration, page 118

Supported Platforms, page 256

Supported Standards, MIBs, and RFCs, page 256

Configuration Tasks, page 257

System Requirements, page 258

Monitoring and Maintaining the PDSN, page 279

Configuration Examples, page 281

PDSN Accounting, page 327

AAA Server Authentication and Authorization Profile, page 333

Attributes, page 336

Glossary, page 351

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

PDSN Mobile IP

PMTU Discovery by Mobile IP Client

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 A static IP address can be requested by the mobile station, and will be assigned if the address is within the pool of addresses and is available. Also an IP address can be statically specified in the AAA profile of the user using the "Framed-IP-Address" attribute.


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. A PPP peer (mobile station) connects with the local NAS (the PDSN).

2. The NAS begins authentication when the client dials in. The NAS determines that the PPP link should be forwarded to a tunnel server for the client. The location of the tunnel server is provided as part of the authentication by the Remote Authentication Dial-in User Service (RADIUS) server.

3. The tunnel server performs its own authentication of the user and starts the PPP negotiation. It performs authentication for both the tunnel-setup and the client.

The PPP client is forwarded through a Layer 2 Tunneling Protocol (L2TP) tunnel over User Datagram Protocol (UDP).

4. The PPP setup is completed and all frames exchanged between the client and tunnel server are sent through the NAS. The protocols running within PPP are transparent to the NAS.

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. The mobile station registers with its Home Agent (HA) through an FA; in this case, the PDSN.

2. The HA accepts the registration, assigns an IP address to the mobile station, and creates a tunnel to the FA. This results in a PPP link between the mobile station and the FA (or PDSN), and an IP-in-IP or Generic Routing Encapsulation (GRE) tunnel between the FA and the HA.

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 While away from home, the mobile station is associated with a care-of address. This address identifies the mobile station's current, topological point of attachment to the Internet, and is used to route packets to the mobile station. In IS-835-B networks, the foreign agent's address is always used as the Care-of address.


3. The HA advertises that the network is reachable to the mobile station, and tunnels datagrams to the mobile station at its current location.

4. The mobile station sends packets with its home address as the source IP address.

5. Packets destined for the mobile station go through the HA; the HA tunnels them through the PDSN to the mobile station using the care-of address.

6. When the PPP link is handed off to a new PDSN, the link is renegotiated and the MIP registration is renewed.

7. The HA updates its binding table with the new care-of address.


Note For more information about MIP, refer to the Cisco IOS Release 12.2 documentation modules Cisco IOS IP Configuration Guide and Cisco IOS IP Command Reference. RFC 2002 describes the specification in detail. TIA/EIA/IS-835-B also defines how MIP is implemented for PDSN.


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).

If the call lands on the same processor:

A new session does not come up on PDSN, and old session remains.

During the mobile handoff between 1XRTT and EVDO call, handoff does not succeed due to the above behavior of PDSN.

If the call lands on a different processor:

Both the calls come up and the old call is deleted when registration lifetime expires. For new calls, downstream traffic is not processed.

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.

Refer to http://www.cisco.com/warp/public/105/38.shtml#2000XP for disabling PMTUD for Windows 2000 or Windows 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 In PMIP, the MS can have only one IP flow per PPP Session.


The communication process occurs in the following order:

1. The Cisco PDSN (acting as an FA) collects and sends mobile station authentication information to the AAA server.

2. If the mobile station is successfully authenticated to use Cisco PDSN PMIP service, the AAA server returns the registration data and an HA address.

3. The FA uses this information, and other data, to generate a Registration Request (RRQ) on behalf of the mobile station, and sends it to the HA.

4. If the registration is successful, the HA sends a registration reply (RRP) that contains an IP address to the FA.

5. The FA assigns the IP address (received in the RRP) to the mobile station, using IPCP.

6. A tunnel is established between the HA and the FA/PDSN. The tunnel carries traffic to and from the mobile station.

PDSN on SAMI

The SAMI blade supports the feature set of Cisco PDSN Release 5.1, 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.

Table 1 Migration Path for Cisco PDSN 

 
Cisco PDSN Release 3.0 or earlier
Cisco PDSN Release 3.5
Cisco PDSN Release 4.0
Cisco PDSN Release 5.0 and 5.1
Platform

7200 NPE400/NPE-G1 and MWAM platform (5 processor only)

MWAM (5 processor only)

SAMI

SAMI

Chassis/Power Supply, Fan Trays)

7200VXR

6500/7600 chassis

7600 chassis

7600 chassis

SUP2/SUP720

SUP720/RSP720/SUP 32

SUP720

SUP32/SUP IOS SX based

SUP IOS - SRC-based image (for example: c7600s72033-advipservicesk9-mz.122-33.SRC.bin)

SUP IOS - Latest SRC-based image

SUP redundancy

SUP redundancy

SUP redundancy


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 For all these migration plans, both hardware and software configurations have significant changes. This requires prudent operation planning and network redesign. The Migration Steps section describes the possible migration steps to minimize both network reconfiguration and service disruption.


Table 2 lists the most common migration scenarios:

Table 2 Migrations Scenarios for Cisco PDSN Release 5.1

Scenario
Migration From
To
Remarks
Downtime

1

Non-SR

Non- clustering

7600 chassis

Each processor can act as an individual Cisco PDSN

Non-SR

Non- clustering

7600 chassis

One Cisco PDSN per blade (single IP architecture)

Erase existing configuration in all processors.

After upgrading to Cisco PDSN Release 5.0 or 5.1, ensure that the configuration is done only on the PCOP (that is, processor 3).

IP address-pool requirements in Cisco PDSN Release 5.0 and 5.1 (at the blade level) are five times that configured in PDSN Release 4.0 (at the processor level).

Yes

2

Non-SR

Non-clustering

7600 chassis

One blade with each processor acting as an individual Cisco PDSN

SR enabled

Non-clustering

7600 chassis

Two SAMI blades (in the same chassis) with a single Cisco PDSN at the blade level

Auto synchronization enabled

Erase existing configuration in all processors on active and standby blades.

After upgrading to Cisco PDSN Release 5.0 or 5.1, ensure that the configuration is done only on an active blade PCOP (that is, processor 3).

Ensure that the standby SAMI blade is shutdown while configuring the active.

IP address-pool requirements in Cisco PDSN Release 5.0 and 5.1 (at the blade level) are five times that configured in PDSN Release 4.0 (at the processor level).

Yes

3

SR-enabled

Non-clustering

7600 chassis

Two SAMI blades (in the same chassis)

SR-enabled

Non-clustering

7600 chassis

Two SAMI blades (in the same chassis)

Auto synchronization enabled

Erase existing configuration in all processors on active and standby blades.

After upgrading to Cisco PDSN Release 5.0 or 5.1, ensure that the configuration is done only on an active blade PCOP (that is, processor 3).

Ensure that the standby SAMI blade is shutdown while configuring the active.

IP address-pool requirements in Cisco PDSN Release 5.0 and 5.1 (at the blade level) are five times that configured in PDSN Release 4.0 (at the processor level).

Yes

4

Non-SR

Clustering enabled

7600 chassis

One or more processors running a Cisco PDSN member

Non-SR

Clustering enabled

7600 chassis

One Cisco PDSN member per blade

Erase existing configuration in all processors on active and standby blades.

After upgrading to Cisco PDSN Release 5.0 or 5.1, ensure that the configuration is done only on an active blade PCOP (that is, processor 3).

IP address-pool requirements in Cisco PDSN Release 5.0 and 5.1 (at the blade level) are five times that configured in PDSN Release 4.0 (at the processor level).

Yes

5

SR enabled (controller redundancy)

Clustering enabled

7600 chassis

Running controller in one of the processors

Redundant SAMI blades (in the same chassis)

SR enabled

Clustering enabled

7600 chassis

Can run both controller and collocated member

Redundant SAMI blades (in the same chassis)

Auto synchronization enabled

Erase existing configuration in all processors on active and standby blades.

After upgrading to Cisco PDSN Release 5.0 or 5.1, ensure that the configuration is done only on an active blade PCOP (that is, processor 3).

Ensure that the standby SAMI blade is shutdown while configuring the active.

If collocated member is configured, ensure that session redundancy is enabled.

IP address-pool requirements in Cisco PDSN Release 5.0 and 5.1 (at the blade level) are five times that configured in PDSN Release 4.0 (at the processor level).

Yes

6

SR-enabled

Clustering-enabled

7600 Chassis

Redundant SAMI blades (in the dual chassis)

SR-enabled

Clustering-enabled

7600 Chassis

Redundant SAMI blades (in the inter chassis)

Auto synchronization disabled (default)

Erase existing configuration in all processors on active and standby blades.

After upgrading to Cisco PDSN Release 5.0 or 5.1, ensure that the configuration is done only on an active blade PCOP (that is, processor 3).

If configured, Cisco PDSN acts as controller and collocated member.

IP address-pool requirements in Cisco PDSN Release 5.0 and 5.1 (at the blade level) are five times that configured in PDSN Release 4.0 (at the processor level).

Yes


Migration Steps

Migration to Cisco PDSN Release 5.1 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 a minimal impact on an existing mobile subscriber's service connections. Migration to Cisco PDSN Release 5.1 image means changing to the architecture of the single PDSN per blade level. The single IP feature reallocates 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.


NoteAll these migration plans must be performed during a maintenance window.

Auto synchronization feature supports configuration synchronization for intra-chassis setup only. In inter-chassis setup, autosynchronization needs to be disabled.


Table 3 lists the migration tasks that are based on the scenarios that were previously established in Table 2.

Table 3 Migration Steps from Cisco PDSN 4.0 to 5.0 or 5.1 

Scenario
Migration Steps

1

In SAMI cards with Cisco PDSN Release 4.0, erase configuration on all processors and reload Cisco PDSN.

Configure the I/O memory (IOMEM) on all processors as 256 MB and save the configuration to the NVRAM.


Note If you have set the IOMEM size as 64 MB, ensure that you configure the memory lite command. The recommended memory size is, however, 256 MB.


Upgrade to Cisco PDSN Release 5.0 or 5.1 and reconfigure the Cisco PDSN configuration on processor 3.

Provision MS and PCFs to use the newly added Cisco PDSN Release 5.0-based PDSN IP.

Provision the newly added PDSN with the HA to service MIP calls.

To minimize provisioning tasks, Cisco PDSN Release 5.0 and 5.1 reuse the IP address and routing scheme used in one of the Cisco PDSN Release 4.0 processors.

2, 3

Install the new SAMI card on 7600/720 that is to be used in redundant configuration.

In the existing Cisco PDSN Release 4.0, erase the existing configuration on all processors and reload the Cisco PDSN.

Configure the IOMEM size on all processors as 256 MB and save the configuration to the NVRAM.


Note If you have set the IOMEM size as 64 MB, ensure that you configure the memory lite command. The recommended memory size is, however, 256 MB.


Upgrade both the SAMI blades to Cisco PDSN Release 5.0 or 5.1.

Shut down the blade for configuration as standby (unit2).

Enable autosynchronization on the active blade (unit1). Configure the PDSN on active blade on processor 3. Keep unit2 as a standby in a redundant configuration. When configuring redundancy, you must configure Hot Standby Router Protocol (HSRP) main interface before configuring Interprocessor Communication (IPC).

Save the configuration on the active blade.

Bring up unit2 with Cisco PDSN Release 5.0 or 5.1 image. Configurations are autosynchronized from the active blade.

Verify the output of the show redundancy state and show redundancy inter device commands on both active and standby blades to confirm if redundancy is enabled. If the output for one of the blades requires a reload to enable redundancy, reload that blade.

Provision MS and PCFs to use the newly added Cisco PDSN Release 5.0 or 5.1-based PDSN IP.

Use the CDMA-1x IP address on the PDSN as controller or member IP when provisioning.

Provision the newly added PDSN with that of HA to service MIP calls.

To minimize provisioning tasks, Cisco PDSN Release 5.0 and 5.1 reuse the IP address and routing scheme used in one of the Cisco PDSN Release 4.0 processors.

4

In SAMI cards with Cisco PDSN Release 4.0, erase the existing configuration on all processors and reload Cisco PDSN. If the blade includes Cisco PDSN members as part of the cluster, we recommend that you remove the PDSN member part before reloading.

Configure the IOMEM size on all processors as 256 MB and save the configuration to the NVRAM.


Note If you have set the IOMEM size as 64 MB, ensure that you configure the memory lite command. The recommended memory size is, however, 256 MB.


Upgrade to Cisco PDSN Release 5.0 or 5.1 and reconfigure the PDSN on processor 3.

You can configure the Cisco PDSN as both controller and collocated member. Cisco PDSN Release 5.0 and 5.1 interoperate with Cisco PDSN Release 3.0 or 4.0 controller or member.

Provision MS and PCFs to use the newly added Cisco PDSN Release 5.0 or 5.1-based PDSN IP.

Use the CDMA-1x IP address on the PDSN as controller or member IP when provisioning.

Provision newly added PDSN with that of HA to service MIP calls.

To minimize provisioning tasks, Cisco PDSN Release 5.0 and 5.1 reuse the IP address and routing scheme used in one of the Cisco PDSN Release 4.0 processors.

5

Install the new SAMI card on 7600/720 that is to be used in redundant configuration.

In the existing Cisco PDSN Release 4.0, erase the existing configuration on all processors and reload the Cisco PDSN.

Configure the IOMEM size on all processors as 256 MB and save the configuration to the NVRAM.


Note If you have set the IOMEM size as 64 MB, ensure that you configure the memory lite command. The recommended memory size is, however, 256 MB.


Upgrade both the SAMI blades to Cisco PDSN Release 5.0 or 5.1.

Shut down the blade for configuration as standby (unit2).

Enable autosynchronization on the active blade (unit1). Configure the PDSN on active blade on processor 3. Keep unit2 as a standby in a redundant configuration. When configuring redundancy, you must configure Hot Standby Router Protocol (HSRP) main interface before configuring Interprocessor Communication (IPC).

Save the configuration on the active blade.

Bring up unit2 with Cisco PDSN Release 5.0 or 5.1 image. Configurations are autosynchronized from the active blade.

Verify the output of the show redundancy state and show redundancy inter device commands on both active and standby blades to confirm if redundancy is enabled. If the output for one of the blades requires a reload to enable redundancy, reload that blade.

Provision MS and PCFs to use the newly added Cisco PDSN Release 5.0 or 5.1-based PDSN IP.

Use the CDMA-1x IP address on the PDSN as controller or member IP when provisioning.

Provision the newly added PDSN with that of HA to service MIP calls.

You can configure the Cisco PDSN to act as controller and collocated member.

In the case of a collocated member, ensure that you enable session redundancy, so that the standby is synchronized with sessions handled by the collocated member.

For an active controller to synchronize the information with the standby controller, ensure that all remote members connect to the HSRP main interface of the controller.

If the member IP is configured, ensure that it is the same as the CDMA -1x interface IP address.

6

In the existing Cisco PDSN Release 4.0, erase the existing configuration on all processors and reload the Cisco PDSN.

Configure the IOMEM size on all processors to 256 MB and save the configuration to the NVRAM.


Note If you have set the IOMEM size as 64 MB, ensure that you configure the memory lite command. The recommended memory size is, however, 256 MB.


Upgrade both the SAMI blades to Cisco PDSN Release 5.0 or 5.1.

Reconfigure the Cisco PDSN and enable inter-chassis HSRP redundancy as in Cisco PDSN Release 4.0.

Provision MS and PCFs to use the newly added Cisco PDSN Release 5.0 or 5.1-based PDSN IP.

Use the CDMA-1x IP address on the PDSN as controller or member IP when provisioning.

Provision the newly added Cisco PDSN with the HA to service MIP calls.


1. MS = Mobile Station.
2. PCF = Packet Control Function.

Features

This section lists the features introduced in the current release (Cisco PDSN Release 5.1) and the previous releases:

New Features in This Release

Features From Previous Releases

New Features in This Release

This section lists the new features in the Cisco PDSN Release 5.1:

Simple IP Client IP Accounting Support

SNMP New MIB Objects for Per PCF

Support for Common NAI

Proxy MIP Changes for Latest IS-835

Simple IPv6 Support

Access-Request Attributes

New PPP Per PCF Counters

VPDN Conditional Debugging

GRE CVSE and MN NAI Extension in Revocation Message

Features From Previous Releases

This section lists features that were introduced before Cisco PDSN Release 5.1:

Support for Common NAI

Single IP per Blade

Osler Support

Improved Throughput and Transaction Handling

Cluster Controller Support in Single IP Blade

IMSI and PCF Redirection

Mobile IP and AAA Attributes for China Telecom

Trap Generation for AAA Server Unresponsiveness

Supervisor Support

Data Over Signaling

Differentiated Services Code Point Marking Support

Nortel Aux A10 Support

Masking Off IMSI Prefix

Persistent TFT Support

Conserve Unique IP-ID for FA-HA IP-in-IP Tunnel

GRE CVSE Support in FA-HA Tunnel

Remote Address Accounting

Default Service Option Implementation

Configurable 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

Attribute Support

Served MDN

Framed Pool

3GPP2 DNS Server IP

Virtual Route Forwarding with Sub-interfaces

Conditional Debugging Enhancements (for Cisco PDSN Release 4.1)

Multiple Service Connections

Data Plane

Subscriber QoS Policy (both downloading per-user profile from the AAA server and configuring a local profile)

QoS Signaling

Traffic Flow Templates

Per-flow Accounting

Call Admission Control

PDSN MIB Enhancements (for Cisco PDSN Release 4.0)

PDSN on SAMI

Inter-User Priority

Roamer Identification

Bandwidth Policing

Packet Data Service Access

Simple IPv6 Access

Session Redundancy Infrastructure

RADIUS Server Load Balancing

Subscriber Authorization Based on Domain

PDSN MIB Enhancements

PPP Counters in Cisco PDSN Release 3.0

RP Counters in Cisco PDSN Release 3.0

Conditional Debugging Enhancements

Trace Functionality in Cisco PDSN Release 3.0

Randomized IMSI Handling

Protocol Layering and RP Connections

PPPoGRE RP Interface

A11 Session Update

SDB Indicator Marking

Resource Revocation for Mobile IP

Packet of Disconnect

IS-835 Prepaid Support

Prepaid Billing

Mobile IP Call Processing Per Second Improvements

Always On Feature

PDSN MIB Enhancements

Conditional Debugging Enhancements

Cisco Proprietary Prepaid Billing

3DES Encryption

Mobile IP IPSec

Hardware IPSec Acceleration Using IPSec Acceleration Module—Static IPSec

1xEV-DO Support

Integrated Foreign Agent

AAA Server Support

Packet Transport for VPDN

Proxy Mobile IP

Multiple Mobile IP Flows

PDSN Cluster Controller / Member Architecture


Note The PDSN software offers several feature options which are available on different images. Some features are image-specific, and are not available on all images. The PDSN Feature Matrix in Table 4 lists the available image for the PDSN.



Note The Cisco PDSN Release 3.5 is only supported on the Cisco MWAM card on the Cisco 7600 or Cisco 6500 Series Router. The features listed in the PDSN Feature Matrix reflect features that are still supported from previous releases.


Please note that Cisco PDSN Release 4.0 does not support Closed-RP clustering. Additionally, Closed-RP support is removed in the release.

Table 4 PDSN Feature Matrix 

Feature Name
c7svcsami-c6ik9s-mz

Session Redundancy

X

Simple IPv6

X(P)

Resource Revocation Per User

X

Trace Functionality

X

RADIUS server load balancing

X

Selection of RADIUS Server Based On Realm

X

PPPoGRE RP Interface

X(P)

A11 Session Update

X

SDB Indicator Marking

X

Packet of Disconnect

X

Resource Revocation

X

Always On Feature

X

NPE-G1 Platform Support

PDSN MIB Enhancements

X

Conditional Debugging

X

10000 Sessions

25000 Sessions

X

RevA Support

X

Prepaid Billing (IS-835-C)

X(P)

PDSN Controller / Member Clustering

X

1xEV-DO Support

X

ESN in Billing

X

3DES Encryption

X*

PPP Optimization

X

P indicates that this feature is only available with a Premium license.

* Requires appropriate hardware support.



Note If you require higher performance values for PDSN selection, use the c6is-mz images; these images contain the PDSN controller-member cluster feature for PDSN selection.


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:

175,000 user sessions

Maximum call setup rate for SIP and MIP sessions for a standalone PDSN

Throughput on the R-P interface for non-fragmented packets of size 64, 350,512, and 1472 bytes

Throughput on the R-P interface for fragmented packets of size 64,350,512, and 1472 bytes with fragmentation of 25 bytes

Call setup rate for a standalone PDSN for SIP and MIP sessions

Card level throughput is increased to 3 Gbps


NoteThe quoted figures are per image, and each SAMI can support six PDSN images.

For detailed call setup rates, refer to the performance data sheet.


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

Mobile IP-based service access

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:

Support for static IP addresses

Public IP addresses

Private IP addresses (for example, for VPDN service)

Support for dynamic IP addresses

Support for PPP PAP/CHAP authentication

Support for MSID-based service access

Support for packet data accounting per TIA/EIA/IS-835-B

Support for packet filtering

Ingress address filtering

Input access lists

Output access lists

User Network Access Identifier (NAI) is available during the PPP CHAP/PAP authentication 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

Simple IP VPDN Access

Proxy-Mobile IP services

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 L2TP Network Server (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 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:

L2TP with proxy authentication

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.

L2TP with dual authentication

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:

Support for static IP addresses

Public IP addresses

Private IP addresses

Support for dynamic IP addresses

Public IP addresses

Private IP addresses

Multiple MIP user flows over a single PPP connection

Multiple flows for different NAIs using static or dynamic addresses

Multiple flows for the same NAI using different static addresses

Foreign Agent Challenge procedures in RFC 3012

MIP Agent Advertisement Challenge Extension

MN-FA Challenge Extension

MN-AAA Authentication Extension

MIP Extensions specified in RFC 2002

MN-HA Authentication Extension

MN-FA Authentication Extension

FA-HA Authentication Extension

MIP Extensions specified in RFC 3220

Authentication requiring the use of SPI.

Mobile NAI Extension, RFC 2794

Reverse Tunneling, RFC 2344

Multiple tunneling Modes between FA and HA

IP-in-IP Encapsulation, RFC 2003

Generic Route Encapsulation, RFC 2784

Support for PPP PAP/CHAP authentication

Support for MSID based service access

Binding Update message for managing zombie PPP connections

Flow based packet data accounting per TIA/EIA/IS-835-B

Support for Packet Filtering

Ingress address filtering

Input access lists

Output access lists

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:

MIP Registration Request received from the Mobile Node

FA-CHAP response received from the HAAA

MIP Registration Reply received from the HA

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 When multiple flows are established for the same NAI, a different IP address is assigned to each flow. This means that simultaneous binding is not required as this is used for maintaining more than one flow to the same IP address.


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:

Link-local address

Global unicast address

Various multicast addresses used for IPv6 Neighbor Discovery and IPv6 ICMP messages

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. See RFC 3513 for additional IPv6 addressing details and information.


Note For Cisco Packet Data Serving Node (PDSN) Feature for Cisco IOS Release 12.3(14)YX, Simple IPv6 support will be added in a future release.


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 cdma pdsn ipv6 command enables the PDSN IPv6 functionality.

The cdma pdsn ipv6 ra-count number command configures the number of IPv6 Route Advertisements (RA).

The cdma pdsn ipv6 ra-count number ra-interval number command controls the number and interval of RAs sent to the MN when an ipv6cp session comes up:

The cdma pdsn accounting send ipv6-flows command control the number of flows and UDR records used for simultaneous IPv4, IPv6 sessions.

The show cdma pdsn flow mn-ipv6-address command shows CDMA PDSN user information by MN IPv6 address.

The show cdma pdsn flow service simple-ipv6 command displays flow-based information for simple IPv6 sessions.

The debug cdma pdsn ipv6 command displays IPv6 error or event messages.

The following configuration commands are required for IPv6:

Global Configuration Commands

ipv6 unicast-routing—IPv6 is disabled by default.

ipv6 cef—Enables cef switching.

ipv6 local pool PDSN-Ipv6-Pool 2001:420:10::/48 64—Enables a pool of IPv6 prefix addresses that can be sent to the MS as a Routing Advertisement (RA).

Virtual-template Interface Commands

ipv6 enable—Enables IPv6 on this interface.

no ipv6 nd suppress-ra—Disables the suppressing of the Neighbor Discovery Routing Advertisement messages (suppressed on non-ethernet interfaces).

ipv6 nd ra-interval 1000—Sends a ND Routing Advertisement every 1000 seconds.

ipv6 nd ra-lifetime 5000—Sets lifetime for the ND Routing Advertisement is 5000 seconds.

peer default ipv6 pool PDSN-Ipv6-Pool—Sets this pool for RA prefixes.

Other commands

show ipv6—Shows IPv6.

See the Cisco IOS IPv6 Command Reference at the following URL for 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:

Bulk synchronize when standby PDSN comes up

When both active and standby PDSN are up and

Session comes up or goes down

Session is refreshed (includes details about updated auxiliary (aux) connections, IP flows and their mapping) on receiving a reregistration

Flow comes up or goes down (includes single IP or MIP or PMIP )

Session goes from active to dormant and vice versa

PPP renegotiation happens

TFT is received or updated

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:

Users perceive no service interruption.

Users do not experience excessive or incorrect billing.

Users are able to re-initiate data service after failover.

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:

Call Setup

Call teardown

Flow setup

Flow teardown

Dormant-Active transition

Handoff

A11 Reregistrations

Periodic accounting synchronization

PPP renegotiation

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 Currently, VPDN, Closed RP, IPv6, and prepaid services are not supported by the session redundancy implementation.



Note Configuration synchronization between the active and standby units is supported in Cisco PDSN Release 5.0. You need to enable the autosync-all feature with the new set of CLI commands to synchronize the configuration on the active unit to the standby one.


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:

Mobile Terminal initiates session teardown

PPP Idle Timeout expires on PDSN

PDSN initiates a Registration Update

PCF initiates a Registration request with lifetime 0

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:

If the user got a Registration Reply (RRP) for previous deregistration from the active node before the switchover and if the Foreign Agent Challenge (FAC) included in that RRP is not synchronized to the now active node (if not, the flow is deleted from this node), this reregistration will be rejected with an invalid challenge error. The user has to initiate a solicitation to the new active node, receive a new challenge, and then resend a Registration Request (RRQ). This time, the RRQ is treated as a valid reregistration and the lifetime is refreshed. It also gets the same IP address as the previous one even though the user considers this as a new registration (it is a reregistration, in the case of FA's and HA's).

If the user did not get a RRP for its previous deregistration from the active node before the switchover, deregistration is resent to the now-active node. This deregistration is likely to be rejected because of an invalid FAC, which depends on whether the latest FAC is synchronized to the standby before the switchover. Then the user can either send a solicitation to get a new FAC, and then sends deregistration again or simply give up. If the user is not able to get a new FAC, then the user has to initiate a solicitation to the new active node, receive a new challenge, and then resend a Registration Request (RRQ).

Dormant-Active Transition

The transition is synchronized between active and standby, and occurs in the following scenarios:

If the PCF receives a RRP in response to the RRQ, and if the transition state is synchronized to the standby before the switchover, the now-active node will have the right session state and the transition is successful.

If the PCF receives a RRP in response to the RRQ but the transition state is not synchronized to the standby before the switchover, the now-active node will have the wrong session state (the session is marked as dormant while it should be active). However, packets will be switched and counted. The PDSN-related show commands may not show all the right information about the session. The subsequent transition from active to dormant will not cause difficulties as the session remains dormant on the PDSN.

If the PCF did not receive an RRP in response to the RRQ before the switchover and if it tries again with the now-active node, this is handled as the current date.

If the PCF did not receive a RRP in response to the RRQ before the switchover, and if it exceeds the maximum number of retries with the now-active node, the packets will be switched and counted.

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:

If the target PCF received an RRP from the active PDSN, and the handoff state is synchronized to the standby before switchover, the data path between the target PCF and the now-active PDSN is established for the handed-off session and the user would not perceive any service disruption. The old PCF may or may not receive the Registration Update from the previously active node, depending on the exact point of switchover. If it receives the Registration Update and sends out a RRQ (lifetime=0), the call should be treated correctly at the old PCF. In case that the old PCF does not receive the Registration Update, and that the session is handled back to it again, it's not clear how PCF will handle this case (this is similar to that the PCF has an existing call for a user and then receives a new call request from the same user). If the PCF ignores the new request, the correct data path is not present and therefore a user is not able to transfer traffic.

If the target PCF received the RRP from the active PDSN, but the handoff state is NOT synchronized to the standby before switchover, the data path between the target PCF and the now-active PDSN will not be established (the session still points to the old PCF). As a result, the end user will notice service disruption. The user cannot gracefully de-register as PPP packets for call termination (TERMREQ) cannot reach the now-active PDSN, and the RRQ (lifetime=0) from the target PCF arrives on the now-active PDSN but the session does not recognize this as a valid remote tunnel endpoint. As a result, deregistration is ignored. The session will eventually be deleted on expiry of the PPP idle timer or registration lifetime. If the user re-registers again, this will be treated as handoff, because the session's current remote tunnel endpoint (the old PCF) is different from the target PCF. This time, the data path is established and the user will receive service.

If the target PCF did not receive an RRP from the active PDSN before switchover, and if the PCF tries again with the now-active PDSN, the handoff is processed the same as of the current date.

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:

R-P Session Lifetime

PPP Idle Timeout

MIP Registration Lifetime

PPP Absolute Session Timeout

The below timer may be running, depending on configuration

Periodic accounting (not to be confused with the synchronization timer mentioned in the Session Events section).

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:

Limitation for Resource Revocation with SR Setup.

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.

The ip radius source interface command does not support virtual address (HSRP), and hence the IP address configured in Loopback interface to be used as source interface (NAS IP address) for reaching the AAA server in SR setup.

IP local pool recycle delay needs to be configured with a minimum delay of 30 (ip local pool pdsn-pool first_ip last_ip recycle delay 30).

It is also advisable to have minimum of (calls per second * recycle delay) extra IPs than required as a buffer, so that sessions do not drop because of IP depletion.

Internals

The following sections identify information that is synchronized to the standby unit:

Asynchronous High-Level Data Link Control

The control character mapping per used Asynchronous High-Level Data Link Control (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 here.

Flags—Fixed and no synchronization is required.

Lifetime—Synchronized.

Home Address—No synchronization is required.

HA—No synchronization is required. This is the HSRP address of the R-P interface. This is used for proposing a PDSN IP address when clustering is configured. This will be the HSRP address of the proposed PDSN. It is only used prior to session establishment.

Care-of-Address—Synchronized. This is the PCF IP address for the R-P Session.

A10 Source IP address—Synchronized. This is the PCF's A10 IP address.

Identification—Not synchronized, contains timestamp to protect against replay attacks.

Mobile-Home Authentication Extension—Not synchronized, calculated per message.

Registration Update Authentication Extension—Not synchronized, calculated per message.

Session-Specific Extension—Synchronized, covers Key, MN_ID and SR-ID.

C-VOSE—Contains multiple application types, Accounting, MEI and DAI. The accounting information will be synchronized. Details are in the accounting section.

N-VOSE contents—ANID will be synchronized, both as part of the session establishment and when it changes as a result of handoff. Fast handoff is not supported, so PDSN Identifier and Identifiers are not relevant to the session redundancy discussion.

Radio Network Packet Data Inactivity Timer (RNPDIT)—Synchronized.

The source UDP port for the A11 traffic will be synchronized.

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.

Table 5 Standard AVPs Supported for Authentication and Authorization 

Authentication and Authorization AVPs Supported By Cisco IOS Name
Synchronized
Description
Allowed In
Access Request
Access Accept

User-Name

Yes

User name for authentication and authorization.

Yes

No

User-Password

No

Password for authentication.

Yes

No

CHAP-Password

No

CHAP password.

Yes

No

NAS-IP-Address

No

IP address of the PDSN interface used for communicating with RADIUS server. A loopback address could be use for this purpose.

Yes

No

Service-Type

No

Type of service the user is getting. Supported values include:

"Outbound" for MSID-based user access

"Framed" for other type of user access

Yes

Yes

Framed-Protocol

No

Framing protocol user is using. Supported values include:

PPP

Yes

Yes

Framed-IP-Address

Yes

IP address assigned to the user.

Yes

Yes

Session-Time-Out

Yes

Maximum number of seconds of service is to be provided to the user before session terminates.

This attribute value becomes the per-user "absolute time-out."

No

Yes

Idle-Time-out

Yes

Maximum number of consecutive seconds of idle connection allowed to the user before the session terminates.

This attribute value becomes the per-user "idle-time-out".

No

Yes

Calling-Station-ID

Yes

MSID identifier of the mobile user.

Yes

No

CHAP-Challenge (optional)

No

CHAP Challenge.

Yes

No

Tunnel-Type

No

VPN tunneling protocol(s) used. Supported values include:

1 for PPTP (not supported)

3 for L2TP

No

Yes

Tunnel-Medium-Type

No. Not supported

Transport medium type to use for the tunnel.

No

Yes

Tunnel-Client- Endpoint

No. Not supported

Address of the client end of the tunnel. When you specify Tunnel-Client-Endpoint, Tunnel-Server is not supported. Use L2TP

No

Yes

Tunnel-Server- Endpoint

No. Not supported

Address of the server end of the tunnel.

No

Yes

Tunnel-Password

No. Not supported

Password to be used for authenticating remote server.

No

Yes

Tunnel-Assignment-ID

No. Not supported

Indicates to the initiator of the tunnel, identifier of the tunnel to which the session is assigned.

No

Yes

addr-pool

No. Not supported

Name of a local pool from which to obtain address. Used with service=ppp and protocol=ip.

"addr-pool" works in conjunction with local pooling. It specifies the name of a local pool (which must have been pre-configured locally).

Use the ip-local pool command for configuring local pools. For example:

ip address-pool local

ip local pool boo 10.0.0.1 10.0.0.10

ip local pool moo 10.0.0.1 10.0.0.20

No

Yes

Inacl#<n>

Yes

ASCII access list identifier for an input access list to be installed and applied to an interface for the duration of the current connection.

Used with service=ppp and protocol=ip, and service service=ppp and protocol =ipx.

Note Per-user access lists do not currently work with ISDN interfaces.

No

Yes

Inacl

Yes

ASCII identifier for an interface input access list.

Used with service=ppp and protocol=ip.

Contains an IP output access list for SLIP or PPP/IP (for example, intacl=4).

The access list itself must be pre-configured on the router.

No

Yes

outacl#<n>

Yes

ASCII access list identifier for an interface output access list to be installed and applied to an interface for the duration of the current connection.

Used with service=ppp and protocol=ip, and service service=ppp and protocol=ipx.

No

Yes

Outacl

Yes

ASCII identifier for an interface output access list.

Used with service=ppp and protocol=ip, and service service=ppp and protocol=ipx.

Contains an IP output access list for SLIP or PPP/IP (for example, outacl=4).

The access list itself must be pre-configured on the router.

No

Yes

interface-config

Yes

User-specific AAA server interface configuration information with Virtual Profiles.

The information that follows the equal sign (=) can be any Cisco IOS interface configuration command.

No

Yes

SPI

Yes

Carries authentication information needed by the HA for authenticating a mobile user during MIP registration.

Provides the Security Parameter Index (SPI), key, authentication algorithm, authentication mode, and replay protection timestamp range.

The information is in the same syntax as the ip mobile secure host address configuration command. Essentially, it contains the rest of the configuration command that follows that string, verbatim.

No

Yes

IP-Pool-Definition

Yes

Defines a pool of addresses using the format: X a.b.c Z; where X is the pool index number, a.b.c is the pool's starting IP address, and Z is the number of IP addresses in the pool.

For example, 3 10.0.0.1 5 allocates 10.0.0.1 through 10.0.0.5 for dynamic assignment.

No

Yes

Assign-IP-Pool

Yes

Assign an IP address from the identified IP pool.

No

Yes

Framed-Compression

Yes

Indicates a compression protocol used for the link. Supported values include:

0: None

1: VJ-TCP/IP header compression

No

Yes

Link-Compression

Yes

Link compression protocol to be used.

Supported values include:

0: None

1: Stac

2: Stac-LZS

3: MS-Stac

No

Yes


GPP2 Packet Data Service Attributes

Table 6 lists the 3GPP2 Packet Data Service Attributes.

Table 6 3GPP2 Packet Data Service Attributes 

Name
Synchronized
Description
Allowed In
     

Access Request

Access Accept

mobileip-mn- lifetime

Yes

Defines lifetime used in Proxy MIP RRQ.

No

Yes

mobileip-mn- ipaddr

Yes

MN IP address for static address assignment. If this attribute is present, this address is used in Proxy MIP RRQ.

No

Yes

mobileip-mn- flags

Yes

Defines Flags used in Proxy MIP RRQ.

No

Yes

CDMA-Realm

Yes

For MSID based access, "realm" information for construction of user name in the form MSID@realm. User names constructed this way are used for accounting purposes only.

The format of realm information is:

ASCII string specifying realm of user's registered domain.

No

Yes

CDMA-User- Class

Yes

Type of service user is subscribed to.

Supported values are:

1 for SIP

2 for MIP

No

Yes

3GPP2-Reverse- Tunnel- Spec

Yes

Indicates whether reverse tunneling is required or not.

Supported values are:

0 for reverse tunneling not required.

1 for reverse tunneling required.

No

Yes

3GPP2-Home- Agent- Attribute

Yes

Address of the HA

Yes

Yes

3GPP2-IP- Technology

Yes

Indicates type of service user is subscribed to.

Supported values are:

1 for SIP

2 for MIP

No

Yes

3GPP2- Correlation-Id

Yes

Identifies all accounting records generated for a particular user flow.

Yes

Yes

3GPP2-Always-On

Yes

Indicates Always On Service.

Supported values are:

0 for non always on users

1for always on users

No

Yes

3GPP2-Security Level

Yes

Indicates the type of security that the home network mandates on the visited network.

No

Yes

3GPP2- IKE Pre-shared Secret Request

No

Indicates that the PDSN needs a pre-shared secret for Phase 1 IKE negotiation with the HA.

Yes

No

3GPP2-Pre-shared secret

No

A pre-shared secret for IKE.

No

Yes

3GPP2-KeyID

No

Contains the KeyID parameter used during IKE exchange between the PDSN and the HA.

No

Yes

3GPP2-Allowed DiffServ marking

No

Specifies if the user is able to mark packets with AF (A), EF (E). The Max Class (i.e., Max Selector Class), specifies that the user may mark packets with a Class Selector Code Point that is less than or equal to Max Class.

No

Yes

3GPP2-MN-AAA Removal Indication

Yes

When received in a RADIUS access-accept message, the PDSN will not include the MN-AAA.

No

Yes

3GPP2-Foreign- Agent Address

No

The IPv4 address of the PDSN CoA contained in RRQ.

Yes

No

Service Option

Yes

Indicates the type of service being used.

Yes

No

DNS Update Required

No. Not supported

Indicates whether DNS update is required.

No

Yes

RN PDIT

Yes

Radio Network Packet Data Inactivity Timer.

No

Yes

Session Termination Capability

Yes

Indicates the nature of resource revocation supported.

Yes

Yes


AAA Server Accounting

GPP2 Accounting Records Fields

Table 7 GPP2 Accounting Records Fields 

Item
Parameter
Description
Synchronized

A. Mobile Identifiers

A1

MSID

MS ID (for example: IMSI, MIN, IRM)

Yes

A2

ESN

Electronic Serial Number

Yes

A3

MEID

Mobile Equipment Identifier

Yes

B. User Identifiers

B1

Source IP Address

IPv4 address of the MS.

Yes

B2

Network Access Identifier (NAI)

user@domain construct which identifies the user and home network of the MS.

Yes

B3

Framed-IPv6- Prefix

MS IPv6 prefix.

Not supported.

B4

IPv6 Interface ID

MS IPv6 interface identifier.

Not supported.

C. Session Identifiers

C1

Account Session ID

The Account Session ID is a unique accounting ID created by the Serving PDSN that allows start and stop RADIUS records from a single R-P connection or P-P connection to be matched.

Yes

C2

Correlation ID

The Correlation ID is a unique accounting ID created by the Serving PDSN for each packet data session that allows multiple accounting events for each associated R-P connection or P-P connection to be correlated.

Yes

C3

Session Continue

This attribute when set to "true" means it is not the end of a Session and an accounting stop is immediately followed by an Account Start Record. "False" means end of a session.

Yes

C4

Beginning Session

The attribute when set to "true" means new packet data session is established; "false" means continuation of previous packet data session. This attribute is contained in a RADIUS Accounting-Request (Start) record.

No

C5

Service Reference ID

This is the service instance reference ID received from the RN in an A11 Registration-Request message.

Yes

D. Infrastructure Identifiers

D1

HA

The IPv4 address of the HA.

Yes

D2

PDSN

The IPv4 address of the PDSN.

No. Should be configured to be the same on the active and standby.

D3

Address Serving PCF

The IP address of the serving PCF (the PCF in the serving RN).

Yes

D4

BSID

SID + NID + Cell Identifier type 2.

Yes

D5

IPv6 PDSN Address

The IPv6 address of the PDSN.

Not supported

D6

Foreign Agent Address

The IPv4 address of the FA-CoA.

Not supported

D7

Subnet

The subnet information for HRPD.

Yes

E. Zone Identifiers

E1

User zone

Tiered Services user zone.

Yes

F. Session Status

F1

Forward FCH Mux Option

Forward Fundamental Channel multiplex option.

Yes

F2

Reverse FCH Mux Option

Reverse Fundamental Channel multiplex option.

Yes

F5

Service Option

CDMA service option as received from the RN.

Yes

F6

Forward Traffic Type

Forward direction traffic type - either Primary or Secondary.

Yes

F7

Reverse Traffic Type

Reverse direction traffic type - either Primary or Secondary.

Yes

F8

FCH Frame Size

Specifies the FCH frame size.

Yes

F9

Forward FCH RC

The format and structure of the radio channel in the forward Fundamental Channel. A set of forward transmission formats that are characterized by data rates, modulation characterized, and spreading rates.

Yes

F10

Reverse FCH RC

The format and structure of the radio channel in the reverse Fundamental Channel. A set of reverse transmission formats that are characterized by data rates, modulation characterized, and spreading rates.

Yes

F11

IP Technology

Identifies the IP technology to use for this call: SIP or MIP.

Yes

F12

Compulsory Tunnel Indicator

Indicator of invocation of compulsory tunnel established on behalf of MS for providing private network and/or ISP access during a single packet data connection.

Yes

F13

Release Indicator

Specifies reason for sending a stop record.

Yes

F14

DCCH Frame Size

Specifies Dedicated Control Channel (DCCH) frame size.

Yes

F15

Always On

Specifies the status of Always On service.

Yes

F16

Forward PDCH RC

The Radio Configuration of the Forward Packet Data Channel. (This parameter can be used as an indication that the MS is 1xEV DV capable.)

Yes

F17

Forward DCCH Mux Option

Forward Dedicated Control Channel multiplex option.

Yes

F18

Reverse DCCH Mux Option

Reverse Dedicated Control Channel multiplex option

Yes

F19

Forward DCCH RC

The format and structure of the radio channel in the forward Dedicated Control Channel. A set of forward transmission formats that are characterized by data rates, modulation characterized, and spreading rates.

Yes

F20

Reverse DCCH RC

The format and structure of the radio channel in the reverse Dedicated Control Channel. A set of reverse transmission formats that are characterized by data rates, modulation characterized, and spreading rates.

Yes

F22

Reverse PDCH RC

The Radio Configuration of the Reverse Packet Data Channel.

Yes

G. Session Activity

G1

Data Octet Count (Terminating)

The total number of octets in IP packets sent to the user, as received at the PDSN from the IP network (i.e. prior to any compression and/or fragmentation).

Yes

G2

Data Octet Count (Originating)

The total number of octets in IP packets sent by the user.

Yes

G3

Bad PPP frame count

The total number of PPP frames from the MS dropped by the PDSN due to incorrect able errors.

Yes

G4

Event Time

This is an event timestamp which indicates one of the following:

The start of an accounting session if it is part of a RADIUS start message.

The end of an accounting session if it is part of a RADIUS stop message.

An Interim-Update accounting event if it is part of a RADIUS Interim-Update message.

Yes

G5

Remote IPv4 Address Octet Count

Contains the octet count associated with one or more remote IPv4 addresses; used for source or destination accounting.

Yes

G6

Remote IPv6 Address Octet Count

Contains the octet count associated with one or more remote IPv6 addresses; used for source or destination accounting.

Not supported

G8

Active Time

The total active connection time on traffic channel in seconds.

Yes

G9

Number of Active Transitions

The total number of non-active to active transitions by the user.

Not supported

G10

SDB Octet Count (Terminating)

The total number of octets sent to the MS using Short Data Bursts.

Yes

G11

SDB Octet Count (Originating)

The total number of octets sent by the MS using Short Data Bursts.

Yes

G12

Number of SDBs (Terminating)

The total number of Short Data Burst transactions with the MS.

Yes

G13

Number of SDBs (Originating)

The total number of Short Data Burst transactions with the MS.

Yes

G14

Number of HDLC layer octets received

The count of all octets received in the reverse direction by the HDLC layer in the PDSN.

Yes

G15

Inbound MIP Signaling Octet Count

This is the total number of octets in registration requests and solicitations sent by the MS.

Yes

G16

Outbound MIP Signaling Octet Count

This is the total number of octets in registration replies and agent advertisements sent to the MS prior to any compression and/or fragmentation.

Yes

G17

Last User Activity Time

This is a Timestamp (in number of seconds from Jan 1 1970 UTC) of the last known activity of the user.

Yes

I. Quality of Service

I1

IP Quality of Service (QoS)

This attribute is deprecated.

Not supported

I2

Airlink Priority

Identifies Airlink Priority associated with the user. This is the user's priority associated with the packet data service.

Not supported

Y. Airlink Record Specific Parameters

Y1

Airlink Record Type

3GPP2 Airlink Record Type.

No

Y2

R-P Connection ID

Identifier for the R-P Connection. This is the GRE key that uniquely identifies an R-P connection (an A10 connection) between the PCF and the PDSN.

Yes

Y3

Airlink Sequence Number

Sequence number for Airlink records. Indicates the sequence of airlink records for an R-P connection.

Yes

Y4

Mobile Originated / Mobile Terminated Indicator

Used only in SDB airlink records. Indicates whether the SDB is Mobile Originated or Mobile Terminated. (0=Mobile Originated and 1=Mobile Terminated).

Yes

Z. Container

Z1

Container

3GPP2 Accounting Container attribute. This attribute is used to embed 3GPP2 AVPs.

Not supported


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:

MIP Registration Lifetime

MIP Flags indicated in the Registration Request

MN-AAA Removal Indication received from the AAA server

HA IP address

Mobile's IP address

Reverse Tunneling indication

Care of Address from MIP Registration Request

FA-Challenge (used during Mobile Node reregistration)

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 G1 and G2 counters will not synchronize.


Here is a sample accounting debug with vsa:

Sep 13 18:23:10.179: RADIUS:   Cisco AVpair       [34]  16  
Sep 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 features in Cisco PDSN Release 5.1:

Simple IP Client IP Accounting Support

SNMP New MIB Objects for Per PCF

Support for Common NAI

Proxy MIP Changes for Latest IS-835

Simple IPv6 Support

Access-Request Attributes

New PPP Per PCF Counters

VPDN Conditional Debugging

GRE CVSE and MN NAI Extension in Revocation Message

Simple IP Client IP Accounting Support

Cisco PDSN provides support for simple IP customers to connect to the L2TP Network Server (LNS) on their home network for IP address assignment. The Cisco PDSN watches for the IPCP configuration acknowledgement returning from the LNS during PPP negotiation between the MS and the LNS. It then extracts the IP address and uses this address, instead of 0.0.0.0 for all subsequent AAA packets.


Note Simple IP accounting does not support IPv6 addresses that are assigned by the LNS.


A new CLI command, cdma pdsn accounting vpdn address [include renegotiation], is introduced in Cisco PDSN Release 5.1. In earlier releases of Cisco PDSN, the accounting-start (with MN IP using all zeroes) is sent out as soon as an L2TP tunnel is established. When you enable the cdma pdsn accounting vpdn address [include renegotiation] command, the accounting-start is delayed till Cisco PDSN gets a valid IP address for the mobile. If the call goes down before the IP address is negotiated, no accounting message is sent.


Note When you enable the CLI command with an extension (including renegotiation), all the packets for VPDN are snooped, thus impacting the performance of Cisco PDSN. If the LNS does not change the IP address during renegotiation, you can remove the extension of the CLI (including renegotiation). By so doing, after the mobile IP address is received, snooping is stopped.


SNMP New MIB Objects for Per PCF

The Cisco PDSN requires SNMP management support for per-PCF PPP statistics. The MIB object defines the manageable objects. Table 8 and 9 describe the new MIB objects per PCF and the VPDN MIB objects that are introduced in Cisco PDSN Release 5.1, respectively.

Table 8 lists the new MIB objects per PCF in Cisco PDSN Release 5.1.

Table 8 New MIB Objects Per PCF in Cisco PDSN Release 5.1 

Object
Description

ccpCdmaExtCacEnabled

Determines if the Cisco PDSN supports call admission control feature.

ccpCdmaExtPcfSoPppPreLCPPdsnA10Rls

Specifies the total number of A10 connections released per PCF by Cisco PDSN before PPP enters into the LCP negotiation phase.

ccpCdmaExtPcfSoPppPreLCPPcfA10Rls

Specifies the total number of A10 connections released by PCF before the PPP enters into the LCP negotiation phase.

ccpCdmaExtPcfSoPppLcpOptionIssueFailures

Specifies the total number of PPP connection requests terminated per PCF due to the LCP option negotiation failure.

ccpCdmaExtPcfSoPppLcpFailuresMaxRetrans

Specifies the total number of PPP connections requests failed per PCF at the LCP phase after the maximum number of retransmissions.

ccpCdmaExtPcfSoPppLcpFailuresUnknown

Specifies the total number of PPP connection requests failed per PCF at the LCP phase due to unknown reasons.

ccpCdmaExtPcfSoPppLcpPhaseRxTermreqs

Specifies the total number of PPP negotiations terminated per PCF due to PPP receiving term request during the LCP phase.

ccpCdmaExtPcfSoPppLcpPcfA10Rls

Specifies the total number of A10 connections released by PCF during the LCP negotiation phase.

ccpCdmaExtPcfSoPppAuthFailures

Specifies the total number of PPP setup connections that failed per PCF at the authentication phase.

ccpCdmaExtPcfSoPppAuthAAATimeouts

Specifies the total number of PPP authentication failures per PCF, due to AAA timeouts.

ccpCdmaExtPcfSoPppAuthFailuresUnknown

Specifies the total number of PPP connection per PCF requests that failed at authentication phase due to unknown reasons.

ccpCdmaExtPcfSoPppAuthMaxRetransFailure

Specifies the total number of PPP connection per PCF requests, which failed at the authentication phase after the maximum number of retransmissions.

ccpCdmaExtPcfSoPppAuthPhaseRxTermreqs

Specifies the total number of PPP negotiations terminated per PCF due to PPP receiving term request during the authentication phase.

ccpCdmaExtPcfSoPppAuthPcfA10Rls

Specifies the total number of A10 connections that are released by the PCF during the PPP authentication phase.

ccpCdmaExtPcfSoPppIpcpOptionIssueFailures

Specifies the total number of PPP connections terminated per PCF due to the IPCP option negotiation failure, such as IP address negotiation.

ccpCdmaExtPcfSoPppIpcpFailuresMaxRetrans

Specifies the total number of PPP connection requests failed per PCF at the IPCP phase after the maximum number of retransmissions

ccpCdmaExtPcfSoPppIpcpFailuresUnknown

Specifies the total number of PPP connection requests failed per PCF at IPCP phase due to unknown reasons.

ccpCdmaExtPcfSoPppIpcpPhaseRxTermreqs

Specifies the total number of PPP negotiations terminated per PCF due to PPP receiving a term request during the IPCP phase.

ccpCdmaExtPcfSoPppIpcpPcfA10Rls

Specifies the total number of A10 connections released by the PCF during the IPCP negotiation phase.

ccpCdmaExtPcfSoPppIpcpIpResourceFail

Specifies the total number of PPP negotiations terminated per PCF due to address exhaustion in the IP pool.

ccpCdmaExtPcfSoPppRenegTotalReqs

Specifies the total number of PPP connections renegotiated per PCF by either Cisco PDSN or the MN.

ccpCdmaExtPcfSoPppRenegByPdsnReqs

Specifies the total number of PPP connections renegotiation requests initiated per PCF by Cisco PDSN.

ccpCdmaExtPcfSoPppRenegByMobileReqs

Specifies the total number of PPP connections renegotiation requests initiated per PCF by the MN.

ccpCdmaExtPcfSoPppRenegSuccesses

Specifies the total number of PPP renegotiations per PCF that have been successfully brought to active state.

ccpCdmaExtPcfSoPppRenegFailures

Specifies the total number of PPP renegotiations failed per PCF at Cisco PDSN.

ccpCdmaExtPcfSoPppRenegConnectionsAborted

Specifies the total number of PPP renegotiations terminated per PCF prematurely due to reasons such as MN power is being off.

ccpCdmaExtPcfSoPppRenegAddrMismatchReqs

Specifies the total number of PPP connections renegotiated per PCF due to IP address mismatch.

ccpCdmaExtPcfSoPppRenegAccessNwIdChanges

Specifies the total number of PPP connections renegotiated per PCF due to access-network identification (ANID) change during session handoff.

ccpCdmaExtPcfSoPppRenegGreChangeReqs

Specifies the total number of PPP connections renegotiated per PCF due to GRE key change requests received from the MN.

ccpCdmaExtPcfSoPppRenegOtherReasonReqs

Specifies the total number of PPP connections renegotiated per PCF due to reasons other than IP address mismatch.

cCdmaClusterRole

Specifies the role that Cisco PDSN assumes within a controller-member.

Type of cluster:

notApply indicates that Cisco PDSN does not assume any cluster role. Cisco PDSN assumes the cluster role, if the cCdmaClusterType is not a controller-member.

controller indicates that Cisco PDSN is the controller of the cluster.

member indicates that Cisco PDSN is a member of the cluster.

collocated indicates that Cisco PDSN is both controller and a member of the cluster.


Table 9 lists the new VPDN MIB objects in Cisco PDSN Release 5.1.

Table 9 New VPDN MIB Objects in Cisco PDSN Release 5.1 

Object
Description

cvpdnSystemInitialConnReq

Specifies the total number of connection attempts in all the VPDN tunnels of this tunnel.

cvpdnSystemSuccessConnReq

Specifies the total number of successful connection attempts in all the VPDN tunnels of this tunnel.

cvpdnSystemFailedConnReq

Specifies the total number of failed connection attempts in all the VPDN tunnels of this tunnel.


Support for Common NAI

The common NAI feature, introduced in Cisco PDSN Release 5.1, involves a global NAI and calling station identification (CLID) on all interactions with external entities, and the CLID as the local identifier (local NAI) within the entity (Foreign Agent).

With a redundancy setup, this attribute is synchronized to standby mode for each flow in both active and standby modes. This attribute is synchronized to standby mode along with other flow attributes. The following CLI command is used to enable this feature:

router(config)# ip mobile foreign-agent mn-identifier calling-station-id

To remove the configuration, use:

router(config)# no ip mobile foreign-agent mn-identifier calling-station-id 

Configure the following CLI commands also.

To send 3GPP2 CLID NVSE in MIP RRQ:
router(config)# [no] cdma pdsn attribute send a1 mip-rrq

To send CT CLID NVSE in MIP RRQ:
Router(config)# [no] cdma pdsn attribute vendor 20942 send a1 mip rrq

To send CLID VSA in FA-CHAP:
Router(config)# [no] cdma pdsn attribute send a1 fa-chap

Note Ensure that you configure this command only when there are no sessions.


Proxy MIP Changes for Latest IS-835

The proxy MIP changes for the IS-835 feature, introduced in Cisco PDSN Release 5.1, supports the draft version of 3GPP2 X.S0061-0 Version 1.0, entitled Network PMIP Support for PMIPv4.

The following are different PMIP-related attributes that are used at the AAA server level to indicate different functionalities of PMIP:

Network-PMIP-NAI Attribute

PMIP-based Mobility Capability Attribute

PMIP-HA-Info-IPv4-Service Attribute

Network-PMIP-NAI Attribute

The network-PMIP-NAI VSA specifies the NAI to be used by the access gateway (AGW) for network PMIP binding between AGW and HA. The network-PMIP-NAI attribute is included in the RADIUS access-accept message if the AGW supports network PMIP and the AT is authorized for network PMIP-based mobility.


Note The network-PMIP NAI attribute is received from the AAA server only in the access-reply message. Also, this attribute specifies the NAI for mobile node for a PMIP call and is used as the NAI.
Cisco PDSN accepts this attribute only if you enable the PMIP-based mobility capability command cdma pdsn attribute send 3gpp2 pmip-indicator auth-req from the CLI. Otherwise, the call is rejected.


PMIP-based Mobility Capability Attribute

The PMIP-based mobility capability VSA indicates that the AGW supports network PMIP to the AAA server. A new PMIP-based mobility capability CLI command, cdma pdsn attribute send 3gpp2 pmip-indicator auth-req, is introduced in Cisco PDSN Release 5.1.

The PMIP-based mobility capability attribute is included in the RADIUS access-request message sent from the AGW to the HAAA server if the AGW supports network PMIP. Cisco PDSN sends this attribute through RADIUS to the AAA server in the access-request message to indicate to the AAA server that the Cisco PDSN supports PMIP and that PMIP is enabled. The absence of the PMIP-based mobility capability attribute indicates that PMIP is not supported by the Cisco PDSN.

While sending the access-request message, Cisco PDSN checks whether the CLI command, cdma pdsn attribute send 3gpp2 pmip-indicator auth-req, is enabled. If yes and if FA service is enabled, the PMIP-based mobility capability attribute with value 1 (representing PMIP4 support) is sent in the access-request message to the AAA server.


NoteTo ensure that the attribute is forwarded, you must enable the cdma pdsn attribute send 3gpp2 pmip-indicator auth-req CLI command.

If FA service is disabled, then the attribute is not sent even if the CLI command is enabled.


Cisco PDSN supports only sending the PMIP-based mobility capability attribute with value 1 (representing PMIP4 support).

The AAA server supports both PMIPv4 and PMIPv6. The AAA server may sends this attribute with value either 1 (supports PMIPv4), or 2 (supports PMIPv6), 3 (supports both) to Cisco PDSN in access-reply. Because the AAA server supports PMIPv4 and PMIPv6, Cisco PDSN too supports PMIPv4 establishing the call.

In the access-reply message from the AAA server, if the PMIP-based mobility capability attribute is present, Cisco PDSN verifies the value. The value of the attribute must be either 1 (PMIP4 support) or 3 (for both PMIP4 and PMIP6 support). Otherwise, Cisco PDSN rejects the call.

If a customer-specific PMIP indicator is received along with the PMIP-based mobility capability attribute in the access-accept message from the AAA server, priority is given to the PMIP-based mobility capability attribute.

PMIP-HA-Info-IPv4-Service Attribute

The PMIP-HA-Info-IPv4-Service VSA specifies the network PMIP4 HA or PMIP6 local mobility anchor (LMA)-related information that is used for IPv4 services. This VSA is included in the RADIUS access-request message sent from the AGW or the visiting AAA (VAAA) server to the Home AAA (HAAA) server. This VSA is also included in the RADIUS access-accept message that is sent from the HAAA server to the VAAA or the AGW.


Note If Cisco PDSN receives HAAA-assigned and VAAA-assigned HA IP addresses together, priority is given to the HAAA-assigned HA IP address.


This attribute will be received from the AAA server in the access-reply message only.


Note Cisco PDSN accepts this attribute only when you enable the PMIP-based mobility capability CLI command (cdma pdsn attribute send 3gpp2 pmip-indicator auth-req). Otherwise, the call is rejected.


This attribute has the following subtypes:

VAAA-Assigned-HA-IPv4-Service

HAAA-Assigned-HA-IPv4-Service

PMN-HA key

PMN-HA-SPI


Note When a Cisco pair of the security parameter index (SPI) key is received along with this attribute containing the PMN HA key and the SPI, priority is given to the PMN key and the SPI.


VAAA-Assigned-LMA-IPv4-Service

HAAA-Assigned-LMA-IPv4-Service

When this attribute is received from the AAA server, the presence of the subtypes is verified and the subtype values are retrieved.


Note Cisco PDSN does not support subtypes 5 and 6, that is:

VAAA-Assigned-LMA-IPv4-Service

HAAA-Assigned-LMA-IPv4-Service

Also, Cisco PDSN does not support sending this attribute to HAAA or VAAA in access-request.


Simple IPv6 Support

While Cisco PDSN supported IPv6 in releases earlier than Cisco PDSN 5.0, Cisco PDSN Release 5.1 extends IPv6 support for single IP architecture.

Cisco PDSN is the PPP termination point for wireless MS with simple IP access. The MS currently supports IPv4 and has been enhanced to support IPv6. An MS may choose IPv4, IPv6, or both simultaneously to access simple IP services in the network. Cisco PDSN supports simple IPv6 access and existing simple IPv4 access.

Access-Request Attributes

Cisco PDSN configures CLI commands to send the attributes in the AAA server authorization request depending on requirements. In Cisco PDSN Release 5.1, Cisco PDSN optionally sends the other existing attributes in the AAA server access-requests. These options are available for prepaid online access-request also and for framed-IP with value 0.0.0.0.

When Cisco PDSN sends an access-request or fa-chap or online-req to the AAA server, Cisco PDSN checks for the respective CLI commands and updates the attributes accordingly.

For example, if cdma pdsn attribute send d4 {auth-req | fa-chap | online-req} is enabled, the D4 attribute is sent in the access-request message along with the other attributes.

The following attributes are sent in the AAA server access-requests:

Base Station Identifier (D4) Attribute

PCF IP Address (D3) Attribute

User Zone (E1) Attribute

NAS Port Attribute

Framed IP Address (B1) Attribute

Base Station Identifier (D4) Attribute

The base station identifier (BSID) attribute represents the BSID, which is a number formed by combining the SID (4 octets), NID (4 octets) and cell identifier (type 2 of 4 octets).

While sending the access-request, Cisco PDSN checks whether the required CLI command, cdma pdsn attribute send d4 {auth-req | fa-chap | online-req}, is enabled. If the CLI command is not enabled, the attribute is not sent in the authentication-request message to the AAA server. The BSID attribute is added for prepaid online access-request message in much the same manner.

PCF IP Address (D3) Attribute

The PCF IP address attribute represents the IP address of the serving PCF; in other words, the PCF in the serving RAN. While sending the access-request message, Cisco PDSN checks whether the required CLI command, cdma pdsn attribute send d3 {auth-req | fa-chap | online-req}, is enabled. If yes, Cisco PDSN sends the PCF IP address attribute set to the PCF IP address in the authentication-request message to the AAA server. The PCF IP address attribute is added for prepaid online access-request message in much the same manner. If the CLI command is not enabled, the attribute is not sent in the authentication-request message to the AAA server.

User Zone (E1) Attribute

The user zone attribute represents the tiered services user zone. While sending the access-request message, Cisco PDSN checks whether the required CLI command, cdma pdsn attribute send e1 {auth-req | fa-chap | online-req}, is enabled. If yes, Cisco PDSN sends the user zone attribute in an authentication-request message to the AAA server. This attribute is added in much the same manner for prepaid online access-request. If the CLI command is not enabled, the attribute is not sent in the authentication-request message to the AAA server.

NAS Port Attribute

The NAS port attribute represents NAS port identification. While sending the access-request message, Cisco PDSN checks whether the required CLI command is enabled. If yes, Cisco PDSN sends the NAS port attribute set to the NAS port identification in the authentication-request message to the AAA server. For prepaid online access-request messages, this attribute is already sent by default. If the CLI command, cdma pdsn attribute send nas-port include-in-authen-req, is disabled, the attribute is not sent in the authentication-request message to the AAA server.

Framed IP Address (B1) Attribute

The framed IP address attribute represents the IP address of the MS. While sending the access-request message, Cisco PDSN checks whether the required CLI command, cdma pdsn attribute send b1 auth-req, is enabled. If yes, Cisco PDSN sends the framed IP address attribute set to 0.0.0.0 in the authentication-request message to the AAA server. For prepaid online access-requests, this attribute is already sent by default. If the CLI command is disabled, the attribute is not sent in the authentication-request message to the AAA server.


NoteDisable the RADIUS attribute CLI command radius-server attribute 8 include-in-access-req to use the new CLI command cdma pdsn attribute send b1 auth-req.

To send framed ip address (0.0.0.0) in an FA-CHAP request for MIP call, use the CLI command ip mobile foreign-agent send-mn-address.


To configure the CLI command cdma pdsn attribute send b1 auth-req, the CLI command ip mobile foreign-agent send-mn-address must be configured already. Without configuring the ip mobile foreign-agent send-mn-address CLI command, you can not configure cdma pdsn attribute send b1 auth-req.

Similarly, if both the CLI commands, ip mobile foreign-agent send-mn-address and cdma pdsn attribute send b1 auth-req are enabled, then to disable the CLI command ip mobile foreign-agent send-mn-address, first disable the cdma pdsn attribute send b1 auth-req CLI command.

New PPP Per PCF Counters

The Cisco PDSN supports PPP-related failure and success global statistics. From Cisco PDSN Release 5.1, Cisco PDSN also supports PPP failure statistics per PCF.

The following PPP failure statistics are added per PCF:

LCP Phase Failure Counters

Authentication Phase Failure Counters

IPCP Phase Failure Counters

LCP Phase Failure Counters

Table 10 lists the LCP phase failure counters.

Table 10 LCP Phase Failure Counters 

Failure Counter
Description

LCP Timeout(MaxRetry)

Total number of PPP connection requests that failed at the LCP phase after the maximum number of retransmission, since the system was last restarted. When configuring the CLI command cdma pdsn mib ignore mn-failures no-lcp-confreq in Cisco PDSN, the maxretry counter does not increment.

MS Term-Req in LCP Phase (LCP Term Req during LCP nego rcvd)

Total number of LCP term requests received from the MN during LCP negotiation since the system was last restarted.

A11 De-Registration in LCP Phase(A10 release during LCP nego by PCF)

Total number of A10 releases during LCP negotiation by the PCF since the system was last restarted.

LCP Negotiation Fail(Failure Reasons Options)

Total number of PPP failures due to options at the LCP phase.

Other Failures in LCP Phase(Unknown)

Total number of PPP connection requests that failed at the LCP phase due to unknown reasons since the system was last restarted.


Authentication Phase Failure Counters

Table 11 Authentication Phase Failure Counters 

Failure Counter
Description

Username/Password Mis-Match(Auth failure

Total number of authentication failures due to username or password mismatch since the system was last restarted.

AAA Timeout(AAA Timeouts)

Total number of PPP authentication failures due to AAA timeouts.

Timeout in Authentication Phase(Auth timeouts)

Total number of PPP authentication failures due to authentication timeout.

MS Term-Req in Authentication Phase(LCP Term Req during Auth nego rcvd)

Total number of LCP term requests received from the MN during IPCP negotiation since the system was last restarted.

A11 De-Registration in Authentication Phase( A10 release during Auth nego by PCF)

Total number of A10 releases during authentication negotiation by the PCF since the system was last restarted.

Other Failures in Authentication Phase(Unknown):

Total number of PPP connection requests that failed at authentication phase due to unknown reasons since the system was last restarted.


Table 11 lists the authentication phase failure counters.

IPCP Phase Failure Counters

Table 12 IPCP Phase Failure Counters 

Failure Counter
Description

IPCP Timeout(MaxRetry)

Total number of PPP connection requests that failed at the IPCP phase after the maximum number of retransmission attempts since system was last restarted.

MS Term-Req in IPCP Phase(LCP Term Req during IPCP nego rcvd)

Total number of LCP term requests received from the MN during authorization negotiation since the system was last restarted.

A11 De-Registration in IPCP Phase(A10 release during IPCP nego by PCF)

Total number of A10 releases during IPCP negotiation by the PCF since the system was last restarted.

IPCP Negotiation Fail( Failure Reasons Options)

Total number of PPP IPCP failures due to options.

Not enough IP resource for allocation(Not enough IP resource for allocation)

Total number of PPP negotiations terminated per PCF due to inadequate IP resources in the IP pool for allocation. The IP pool is downloaded from the AAA server or locally.

When configuring the local IP pool or the wrong local IP pool in Cisco PDSN, this counter does not increment; however, the global counter is incremented.

In earlier releases, if the remote IP pool is configured on Cisco PDSN, the unknown counter was incremented along with this counter. In Cisco PDSN Release 5.1, however, the unknown counter does not increment along with this counter.

Other Failures in IPCP Phase (Unknown)

Total number of PPP connection requests that failed at the IPCP phase due to unknown reasons, since system was last restarted.


Table 12 lists the IPCP phase failure counters.

VPDN Conditional Debugging

The conditional debugging feature enables you to verify or observe the debugs of a particular session. You can enable conditional debugging depending on the IMSI or the username, by using the following CLI command.

PDSN# debug condition ?
  called       called number
  calling      calling --------------------> for IMSI
  glbp         interface group
  interface    interface
  ip           IP address
  mac-address  MAC address
  match-list   apply the match-list
  standby      interface group
  username     username -------------------> for username
  vcid         VC ID
  voice-port   voice-port number
  xconnect     Xconnect conditional debugging on segment pair

In Cisco PDSN Release 5.1, conditional debugging is enabled for VPDN calls. If you enable IMSI (calling station ID)-based conditional debugs, you must verify if the session IMSI matches the IMSI that was set through the conditional debugging CLI command. If a match exists, VPDN context debug flags are set. If a match does not exist, the debug flags in the VPDN context are not set, avoiding printing of the debugs for other sessions. If IMSI-based debugging is enabled, the IMSI is added in the debug message; similarly for username condition also. If both the username and IMSI-based conditional debugs are enabled for a session, priority is given to the IMSI to display with L2TP and VPDN call event debug messages.

The following command shows the condition as part of L2TP and VPDN call event debugs, which is set through the conditional debug CLI command, when the username or IMSI conditional debugging is enabled for VPDN session.

lac(config)# vpdn debug ?
  show-conditions  Show Conditions (IMSI/Username) with debug messages
lac(config)# vpdn debug show-conditions ?

GRE CVSE and MN NAI Extension in Revocation Message

Cisco PDSN Release 5.1 meets the CDMA standard 3GPP2 X.S0011-003-D. As per the CDMA standard (3GPP2 X.S0011-003-D), Cisco PDSN sends previously negotiated GRE encapsulation and GRE key in the revocation message and MN-NAI extension in all the revocation messages.

The following are the conditions for sending GRE CVSE and MN NAI extension in the revocation message:

If GRE CVSE is negotiated between FA and HA, the GRE CVSE with FA assigned key must be included in the revocation message.

If FA has received the revocation message with GRE CVSE and with HA assigned key, the FA must send the revocation acknowledgement message with GRE CVSE as FA assigned key to HA.

The GRE CVSE must be included before the FA-HA authentication extension, if present in revocation and revocation acknowledgement message.

With the CLI command ip mobile foreign-service revocation exclude-nai disabled, the MN NAI extension must be included in revocation message.

If FA has received the revocation message with the MN NAI extension from HA, then FA must include the MN NAI extension in the revocation acknowledgment message while sending to HA.

The MN NAI extension must be included before the FA-HA authentication extension if present in revocation and revocation acknowledgment message.

Single IP per Blade

This section 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

Single IP Interface

Single Interface for MIP, Simple IP, VPDN-based calls or A11 Registrations

Single Interface for Configuration

Single Interface for SNMP Management

Single Interface for Troubleshooting and Debugging

Single Interface for AAA

Single Interface for Failover

Operation and Management

Chassis-Wide MIB for Application-Related Parameters

Trap Generation for AAA Unresponsiveness

Show Subscriber

Intra-Chassis Configuration Synchronization

Configuration Details

Monitor Subscriber

Show Subscriber Session

Bulk Statistics Collection

Redundancy Support in Cisco PDSN Release 5.0

Performance Requirements

Single IP Support - Reused and New CLI Commands

Distributed Configuration, Show and Debug commands in Single IP PDSN

Features Not Supported

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:

AAA interactions

Network Management interaction through SNMP for MIB retrieval

Configuration, Show, and Debug functionality

Failure detection and failover of a blade

AAA server response time determinations and alarm indications

Additionally, the presentation of a per-chassis model applies to the following targeted functionality:

Show subscribers present across a chassis with various output-filtering capabilities.

Display the session activity for one or more subscribers across a chassis.

Monitor Subscriber (Call Trace) for one or more specific subscribers for the purposes of troubleshooting.

Collation, transfer, and storage of bulk statistics for a chassis.

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

Single Interface for Configuration

Single Interface for SNMP Management

Single Interface for Troubleshooting and Debugging

Single Interface for AAA

Single Interface for Failover

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 Troubleshooting and Debugging

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

AAA Responsiveness Test Tool and Traps

Trap Generation for AAA Unresponsiveness

Show Subscriber

Intra-Chassis Configuration Synchronization

Monitor Subscriber

Show Subscriber Session

Bulk Statistics Collection

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:

Manual verification of AAA server availability using a locally initiated binding with AAA authentication.

Indication of lack of server responsiveness during normal operations based on SNMP traps.

AAA Responsiveness Test Tool

This release does not support the AAA responsiveness test tool.

Trap Generation for AAA Unresponsiveness

See Trap Generation for AAA Server Unresponsiveness section.

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 12 lists the feature's functionality:

Table 13 List of Show Subscriber Functionality 

All

Summary of all users on the chassis

To display the total number of all registered users on the chassis, use the show cdma pdsn session {summary | brief | detail} command on the TCOPs per active service blade. The total from each blade is then summed, and the result is displayed.

A single command can display maximum number of subscribers. We recommend that you configure a value of 1000. If the number of registered subscribers exceeds the value, the output is saved to a file, and the name and location of the file is indicated.

Card

Summary of all users on one specific Card or Slot

To display the total of all registered users on one service blade, use the show cdma pdsn session {summary | brief | detail} command. The command is executed on the control processor of the service blade identified with the desired result being the total line.

Member

Summary of all users on one specific member (CPU)

To display the total of all registered users on a given traffic processor on a service blade, use the show cdma pdsn session {summary | brief | detail} command on the service blade, in addition to the TCOP identified in the command.

Connect

Summary of all users with a connect time greater than, lower than, or equal to a time value (use of AGE)

To display the time since the subscriber first registered, not the time since the last reregistration.

show cdma pdsn session lifetime age {lesser | greater | equals} [hh:mm:ss] {detail | brief | summary}

FA-Chassis

Summary of all visitors on FAs within PDSN

To display the total number of visitors serviced by the FA in the chassis, use the show cdma pdsn session visitor summary command on all the TCOPs in the service blades in the chassis.

FA-Member

Summary of all users on one specific FA within the PDSN

To display the total number of visitors serviced by the FA in the service blade, use the show cdma pdsn session visitor summary command in the requested service blade.

HA-User

Summary of all users registered with a particular HA

To display the total number of visitors registered with a HA, use the show ip mobile visitor ha-addr [ha-ip] command on all TCOPs.

Calltype

Summary of all users for this Call Type (such as RTT, EVDO rev A, and rev 0)

To display the total number of visitors for a specific call type, use the show cdma pdsn session service-option [so] on all TCOPs.

NAI or User

Summary of all users for this NAI (supports wildcards in the NAI). For example, show user summary nai *ptt* finds Push to Talk users on the box. Filter by realm is also supported.

To display the total number of visitors for the NAI, use the show cdma pdsn session user [nai] command on all the TCOPs.

(Existing CLI command but NAI to support regular expression.)

Address Range CLI

Summary of all users within the given address space

To display the total number of visitors for a specific address space, use the show cdma pdsn flow mn-ip-address range [startIP] [endIP] {brief | summary | detail} command on all the TCOPs.


Here is a list of the possible output display formats:

Summary - Total number of sessions, bytes in or out, packets in or out, dropped in, and out by ACL.

Brief - Single line of output per user matching the command filters. The output comprises the assigned IP address, NAI, dormant, and PCF address.

Verbose - Full display as provided by the output of the show cdma pdsn session command.

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 autosynchronization 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 It is not possible to execute configuration commands on the standby PDSN. EXEC commands are permitted.


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. See the 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:

Reliable IPC mechanism currently being used for CP-TP messaging

RF or CF SCTP-based approach for IPC messaging

New SCTP-based approach for IPC messaging

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:

Private configuration

Running configuration

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 There are two types of NVRAM configuration files, the public configuration files and the private configuration files. The private configuration files cannot be displayed on the console. Examples of the uses for private NVRAM configuration files are maintaining persistent SNMP interface indices over a system reboot, saving the lawful intercept username and password, and so on.


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:

Bulk synchronize the startup configuration file.

Perform a line-by-line synchronization of the EXEC command.

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:

No configuration commands are allowed on the standby unit. Only the active is configurable and the active drives the standby.

When configuring the redundancy synchronization feature for the first time, only one of the redundant units is up. Make the necessary configuration and save it before the other unit is up. Doing so avoids configuring on the standby unit even for the first time.

The write memory command is not allowed on the standby unit.

With autosynchronization feature enabled, you only need to run the unit1-unit2 set of CLI commands. You cannot use the local-remote set of commands with autosynchronization feature enabled. You can use the local-remote commands only after disabling the autosynchronization feature.

Configuration Details

Using the autosynchronization 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:

ipc zone default

association no.

protocol sctp

unit1-port port1

unit1-ip ip1

unit2-port port2

unit2-ip ip2

The following new command is introduced under the interface GigabitEthernet0/0.23:

redundancy ip address unit1 ip1 mask1 unit2 ip2 mask2

The 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 y

The 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 

unit1-port portnum , unit2-port portnum 

under the ipc-assoc-protocol-sctp mode.


unit1-ip address1 , unit2-ip address2 

under the ipc-unit1-port and ipc-unit2-port modes respectively.


redundancy ip address unit1 address1 mask1 unit2 address2 mask2 

under the interface and sub-interface modes.


Sequence of configuration steps that must be performed on each of the cards:

 
Command
Purpose

Step 1 

Router# show redundancy states




Execute the following commands on both SAMIs before running any redundancy commands. my state should be active on both the cards.

Note Power down one unit, configuration has to be done only on one unit.

Step 2 

Router(config)# auto-sync all


Enables intra-chassis configuration synchronization.

Step 3 

Router(config)# redundancy unit1 slot 9 unit2 slot 6


Configures global redundancy unit-slot mapping.

Step 4 

Router(config)# redundancy unit1 hostname name1 unit2 hostname name2


Identifies and configures the peer slot name in the same chassis.

Step 5 

Router(config)#interface GigabitEthernet0/0.2
		      encapsulation dot1Q 20
		      redundancy ip address unit1 4.0.0.1 
              255.255.255.0 
              unit2 4.0.0.2 255.255.255.0
		      standby 0 ip 4.0.0.4

       standby 0 name hsrp


Configures an interface for HSRP.

HSRP needs unique IPs for the standby and active units and you need to use the redundancy ip address command.

Note Do not configure the ip address command on this interface.

Step 6 

Router(config)#ipc zone default

Router(config-ipczone)# association 1

Router(config-ipczone-assoc)# no shutdown

Router(config-ipc-protocol-sctp)# protocol sctp

Router(config-ipc-protocol-sctp)# unit2-port 5000

Router(config-ipc-unit2-sctp)# unit2-ip 4.0.0.2

Router(config-ipc-protocol-sctp)# unit1-port 5000

Router(config-ipc-unit1-sctp)# unit1-ip 4.0.0.1


Configures IPC information for the RF interdevice.

Step 7 

Router(config)# redundancy inter-device

Router(config-red-interdevice)# scheme standby hsrp

Associates the HSRP scheme name to the RF interdevice.

When session redundancy is configured for the first time with autosynchronization 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. Determine the PDSN instance in the chassis hosting the session.

2. If a session is present, apply the debug conditional command on that PDSN instance and then apply the specific debug commands requested. If no session is present, establish a pre-trigger condition for debug followed by the requested debug commands on all PDSN instances configured in the chassis.

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 The Session Manager on the PCOP is used to locate the subscriber, if the subscriber already exists. The APIs for lookup of the Session Manager are used to search, if the subscriber has already registered. The lookups are based on IMSI, NAI, or mobile-assigned IP address.


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:

Determine the PDSN instance in the chassis hosting the session

Execute the commands for show ip mobile host {ip-address | nai}, show ip mobile secure host {ip-address | nai}, show {ip mobile violation address | nai string}and show ip mobile host-counters.

Bulk Statistics Collection

This feature is capable at a single point:

Begin the periodic collection of the available PDSN statistics, identifiable by name, from each active service blade in the chassis.

Collect the specified statistics by enabling IOS Bulk Statistics collection at each selected service blade. This mechanism allows the collection of statistics for MIB variables. If the required measure is not part of a MIB, it cannot be collected as part of the bulk statistics collection feature.

Transfer the file to an external TFTP server identified by a URL.

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:

PDSNRegRevocationsSent

PDSNRegRevocationsReceived

PDSNRegRevocationsIgnored

PDSNRegRevocationAcksSent

PDSNRegRevocationAcksReceived

PDSNRegRevocationAcksIgnored

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.

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 Cisco PDSN Release 5.0.

Performance Requirements

The single IP PDSN supports the following performance figures:

175,000 registered subscribers per service blade.

3.0 Gbps throughput with 20 percent upstream, 80 percent downstream, IMIX throughput using measurement techniques applied for validating the six independent processor. This model represents 5/6 of the throughput proven as part of those measurements.

The time required to bulk synchronize an active HA service blade hosting 200,000 subscriber registrations to a reloaded standby PDSN service blade takes no longer than the time taken to bulk synchronize a fully loaded active to standby service blade in the "six independent processor" model.

The call per second (CPS) rate is no slower than for a single processor in the "six independent processor" model. The call per second rate meets or exceeds the rate measured during performance verification (100 CPS).

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

debug sami ipc gtp processor 3-8

debug sami ipc gtp processor

debug sami ipc gtp any

debug sami ipc detail

debug sami ipc

debug sami ipc stats detail

debug sami ipc stats

test sami tp-config {enable | disable} (available on TPs in SingleIP image)

Show Commands

show sami ipcp ipc gtp

show sami ipcp ipc ixp

show sami ipcp ipc processor

Configuration Mode:

default sami ipc crashdump

default sami ipc keepalive

default sami ipc retransmit

default sami ipc retries

sami ipc crashdump

sami ipc keepalive

sami ipc retransmit

sami ipc retries

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:

router ospf

router bgp

router eigrp

router rip

router [any routing protocol]

cdp [related commands]

Any subcommands related to the above in interface configuration

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 14 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.

Table 14 PDSN Commands for Single IP 

Command (Configuration Commands)
Purpose
Used at

cdma pdsn multiple service-flows [maximum number]

Enables the multiple flow support. The maximum number defines the maximum number of auxiliary A10s that can be created between PDSN and PCF. The default number of auxiliary A10s allowed is 7.

TCOP

cdma pdsn multiple service-flows qos subscriber profile

Enables you to configure the local subscriber QoS profile. This profile is used for a MN when subscriber QoS profile is not downloaded from the AAA server.

TCOP

cdma pdsn multiple service-flows qos remark-dscp [value]

Enables you to configure the DSCP remark value to be used for marking when the data packets from the mobile toward the Internet do not have the DSCP within the allowed DSCP value for that mobile.

TCOP

cdma pdsn tft reject include error extension

Includes the error extension in the reject message when a TFT is rejected.

TCOP

cdma pdsn cac maximum bandwidth [number]

cdma pdsn cac maximum cpu-threshold [number]

Enables the call admission control. Use one of these CLIs to control the CAC parameters such as bandwidth and CPU.

CPU (memory) on PCOP Bandwidth on TCOP

cdma pdsn attribute send {f16 | f17 | f18 | f19 | f20 | f22}

Forwards the accounting message.

TCOP


PDSN Commands for Local Subscriber QoS Profile

The cdma pdsn multiple service flows qos subscriber profile command takes you to a submode. Table 15 lists the commands that you can use to configure various parameters in the local subscriber QoS profile.

Table 15 PDSN Commands for Local Subscriber QOS Profile 

Command (Configuration Commands)
Purpose
Used at

Bandwidth [number]

Configures the maximum aggregate bandwidth value.

TCOP

inter-user-priority [value]

Configures inter-user priority parameter.

TCOP

tft-allowed [value]

Configures the allowed number of persistent TFTs parameter.

TCOP

link-flow [value]

Configures the maximum service connection parameter in service option profile.

TCOP

flow-priority [value]

Configures the maximum per-flow priority parameter.

TCOP

flow-profile direction {forward | reverse | bi-direction} flow-id [flow-id]

Configures authorized flow profile IDs for each direction.

TCOP

dscp {allowed-class {AF | EF | O} | max-class [value] | reverse-marking [value]}

Configures the allowed differentiated services markings parameter.

TCOP



Note For any configuration command that is filtered, its sub configuration commands are also filtered.


See the Configuring the PDSN Image section for the below configuration tasks:

Enabling PDSN Services

Creating the CDMA Ix Interface

Creating a Loopback Interface

Creating a Virtual Template Interface and Associating it with the PDSN Application

Enabling R-P Interface Signaling

Configuring User Session Parameters

Enabling HSRP and Configuring Redundancy

Using the Loopback Interface For the PDSN-AAA Server Interface

Configuring Application Tracking to Handle active-active Situation

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 the Mobile IP FA

Configuring Proxy Mobile IP Attributes Locally

Configuring Mobile IP Security Associations

Enabling Network Management

Configuring Always On Service

Configuring A11 Session Updates

Configuring SDB Indicator Marking

Configuring SDB Indicator Marking for PPP Control Packets

Configuring PoD on the PDSN

Configuring Mobile IP Resource Revocation on the PDSN

Configuring PDSN Accounting Events

Configuring CDMA RADIUS Attributes

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 16):

Table 16 Configuring Host Routes

Command
Purpose
Used at

[no] cdma pdsn sm add mobile route

Configures or removes configuration of host route on the PDSN.

TCOP


Clear Commands

Table 17 lists the clear commands:

Table 17 Clear Commands 

Command
Purpose
Used at

Router# clear cdma pdsn session {all | pcf ip-addr | msid octet-stream} {send {all-update | termreq}}

Clears the session.

TCOP

Router# clear cdma pdsn statistics

Clears the RAN-to-PDSN interface (RP) or PPP statistics on the PDSN.

 

 

TCOP

Router# clear ip mobile binding {all [load standby-group-name] | ip-address | nai string ip_address}

Removes mobility bindings.

TCOP

Router# clear ip mobile visitor [ip-address | nai string ip_address]

Clears visitor information.

TCOP

Router#clear vpdn tunnel l2tp ?

Clears VPDN L2TP Tunnel information.

all All L2TP tunnels

hostname Based on the hostnames

id Based on the tunnel ID

ip Based on IP address

TCOP


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 IMSI
show sami sm imsi 12345678910112
 Session Manager User Details
   IMSI: 12345678910112                 Location:7(7000000)

 Call Details
   IP Address: 12.1.1.31              VRF ID:0
   HA IP Address: 0.0.0.0              NAI: user1

pdsn# show sami sm statistics 
Session Manager Statistics
 Request Sent:
  Session: 4                   Control: 0
  Control AAA: 0               Control HA: 0

 Request Received:
  Session Create: 5            Session Delete: 4
  Flow Create: 6               Flow Delete: 5
  Agg resp: 0

 Response Sent:
  Session Create Success: 5   Session Create Failure: 0
  Session Delete Success: 4   Session Delete Failure: 0
  IMSI update: 0              IMSI delete Generated : 0
  Flow Create Success: 6      Flow Create Failure: 0
  Flow Delete Success: 5      Flow Delete Failure: 0

 IXP Update:
  Total: 0                    Success: 0
  Failure: 0

 Failure:
  Message parsing: 0          Internal 1: 0
  Internal 2: 0               PPC not found: 0
  Timer Expiry: 0             Pool Manager: 0
 Flow message parse : 0

PDSN-Act-ftb3-83# sh cdma pdsn  statistics sm
PPC Stats:
 Imsi Create Request to PPC Success 4, Failure 0
 Imsi Delete Request to PPC Success 4, Failure 0
 Imsi Response from PPC Success 4, Failure 0
 CCB Create Request to PPC Success 0, Failure 0
 CCB Delete Request to PPC Success 0, Failure 0
 CCB HA Create Request to PPC Success 4, Failure 0
 CCB HA Delete Request to PPC Success 4, Failure 0
 CCB Response from PPC Success 4, Failure 0
 IXP A10 Add Send Success 4 Failure 0, Received Success 4 Failure 0
 IXP A10 Delete Send Success 4 Failure 0, Received Success 4 Failure 0
 IXP CCB Add Send Success 0 Failure 0, Received Success 0 Failure 0
 IXP CCB Delete Send Success 0 Failure 0, Received Success 0 Failure 0
 IXP CCB HA Add Send Success 4 Failure 0, Received Success 4 Failure 0
 IXP CCB HA Delete Send Success 4 Failure 0, Received Success 4 Failure 0
 IXP Nack terminated session 0 flow 0
 Ack timer expiry Imsi 0, Ccb 0

Tunnel PPC Stats:
 Tunnel Create Request Rcvd 3, Sent Ack 3 Nack 0
 Tunnel Delete Request Rcvd 3, Deleted 3
 Invalid Tunnel Request Type Rcvd 0
PDSN-Act-ftb3-83#
PDSN-Act-ftb3-83#

Table 18 lists the distributed show commands.

Table 18 Distributed Show Commands

Option

Description

CLI Command

Category

Connect

Summary of all users with a connect time greater than, lower than, or equal to a time value (use of AGE).

show cdma pdsn session age {less | greater | equals} time

C

HA-User

Summary of all users registered with a particular HA.

show ip mobile visitor home-agent ha-ip

C

Address space

Summary of all users in this address space.

show cdma pdsn flow mn-ip start ip end ip

C

Calltype

Summary of all users for this Call Type (such as RTT, EVDO rev A, and rev 0).

show cdma pdsn session service-option so

C

NAI or User

Summary of all users for this NAI (supports wildcards in the NAI). For example, show user summary nai *ptt* finds Push to Talk users on the box. Filter by realm is also supported.

show cdma pdsn session user nai

C


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:

show cdma pdsn statistics

show cdma pdsn statistics qos

show cdma pdsn statistics ahdlc

show cdma pdsn statistics tft

show cdma pdsn statistics traffic

show cdma pdsn statistics prepaid

show cdma pdsn statistics radius disconnect

show cdma pdsn statistics ppp

show cdma pdsn statistics rp

show cdma pdsn statistics rp error

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:

show cdma pdsn

show cdma pdsn pcf

show cdma pdsn pcf pcfipaddr

show cdma pdsn pcf brief

show cdma pdsn pcf pcfip psi psivalue

show l2tp counters tunnel

show l2tp counters tunnel authentication

show cdma pdsn statistics rp pcf

show cdma pdsn statistics rp pcf pcfip

show cdma pdsn statistics ppp pcf

show cdma pdsn statistics ppp pcf pcfip

show cdma pdsn statistics sm

show cdma pdsn statistics service-option

show cdma pdsn statistics service-option sovalue pcf pcfip

show cdma pdsn statistics prepaid pcf pcfip

Changes to Clustering show Commands

The changes to clustering show commands are given below:

show cdma pdsn cluster controller member 2.1.1.1
PDSN cluster member 2.1.1.1 (local) state      ready, Group NONE <--- New
 registered with PDSN controller 11.1.1.50
 reported load 1 percent, will be sought in 2 seconds
 
Member 2.1.1.1 statistics:
  Number of sessions 0
  Controller seek rcvd 6122, Member seek reply rcvd 6122
  Member state changed 0 time to ready
  Member state changed 0 time to Admin prohibited
  Session-Up message rcvd 0, Session-Down message received 0
  Member seek not replied in sequence 0

show cdma pdsn cluster controller configuration 
cluster interface GigabitEthernet0/0.341 (collocated)
no R-P signaling proxy
timeout to seek member = 10 seconds 
window 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 hello
this PDSN cluster controller is configured
 
Controller maximum number of load units = 100
 
 
show cdma pdsn cluster member configuration 
cluster interface GigabitEthernet0/0.341
IP address of controller is 11.1.1.50  (collocated) <--- New
no prohibit administratively
timeout to resend status or seek controller = 10 sec or less, randomized
resend a msg for 2 timeouts sequentially if no reply, then inform operator
default:  spi 101, Timestamp +/- 0, key ascii hello
this PDSN cluster member is configured

Changes to Show commands

The changes to show commands are given below:

show cdma pdsn pcf:
pdsn_act# show cdma pdsn pcf
PCF 2.2.2.4 has 1 session, 1 service flow 
Received 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.4
PCF 2.2.2.4 has 1 session, 1 service flow 
Received 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 statistics
Last clearing of "show cdma pdsn statistics" counters never
Last Update received at 00:12:54 UTC Mar 1 2009 <--- New
RP Interface: 
Reg Request rcvd 0, accepted 0, denied 0, discarded 0 
Initial Reg Request rcvd 0, accepted 0, denied 0, discarded 0, AuxRequest 0 
Re-registration requests rcvd 0, accepted 0, denied 0, discarded 0 
Re-registration requests containing Active-Start 0, Active-Stop 0 
Re-registration requests containing new connections 0, missing connections 0, remapping 
flows 0 
Handoff requests rcvd 0, accepted 0, denied 0, discarded 0,AuxRequest 0 
De-registration rcvd 0, accepted 0, denied 0, discarded 0 
De-registration Reg Request with Active-Stop 0 
Registration Request Errors: 
Unspecified 0, Administratively prohibited 0 
Resource unavailable 0, Authentication failed 0 
Identification mismatch 0, Poorly formed requests 0 
Unknown PDSN 0, Reverse tunnel mandatory 0 
Reverse tunnel unavailable 0, Bad CVSE 0 
Max Service Flows 0, Unsupported So 0, Non-Existent A10 0 
Bandwidth Unavailable 0 
Update sent 0, accepted 0, denied 0, not acked 0 
Initial Update sent 0, retransmissions 0 
Acknowledge received 0, discarded 0 
Update reason lifetime expiry 0, PPP termination 0, other 0 
Registration Update Errors: 
Unspecified 0, Identification mismatch 0 
Authentication failed 0, Administratively prohibited 0 
Poorly formed request 0 
Handoff statistics: 
Inter PCF handoff active 0, dormant 0 
Update sent 0, accepted 0, denied 0, not acked 0 
Initial Update sent 0, retransmissions 0 
Acknowledge received 0, discarded 0 
De-registration accepted 0, denied 0 
Handoff Update Errors: 
Unspecified 0, Identification mismatch 0
Authentication failed 0, Administratively prohibited 0 
Poorly formed request 0 
RP Session Update statistics: 
Update sent 0, accepted 0, denied 0, not acked 0 
Initial Update sent 0, retransmissions 0 
Acknowledge received 0, discarded 0 
Sent reasons Always On 0, RN-PDIT 0, Subscriber Qos 0 
RP Session Update Errors: 
Unspecified 0, Identification mismatch 0 
Authentication failed 0, Session parameters not updated 0 
Poorly formed request 0 
Service Option:
Address Stats: 
Simple IP: Static 0, Dynamic 0 
Mobile IP: Static 0, Dynamic 0 
Proxy Mobile IP: Static 0, Dynamic 0 
Simple IP VPDN: Static 0, Dynamic 0
Flow Stats: 
Simple IP: Success 0, Failure 0 
Mobile IP: Success 0, Failure 0 
Proxy Mobile IP: Success 0, Failure 0 
Simple IP VPDN: Success 0, Failure 0 
Unknown Service Failures: 0
PPP: 
Current Connections 0 
Connection requests 0, success 0, failure 0, aborted 0 
Connection enters stage LCP 0, Auth 0, IPCP 0 
Connection success LCP 0, AUTH 0, IPCP 0 
Failure reason LCP 0, authentication 0, IPCP 0, other 0 
Failure reason lower layer disconnect 0 
A10 release before LCP nego by PDSN 0, by PCF 0 
LCP Stage 
Failure Reasons Options 0, MaxRetry 0, Unknown 0 
LCP Term Req during LCP nego sent 0, rcvd 0 
A10 release during LCP nego by PDSN 0, by PCF 0 
Auth Stage 
CHAP attempt 0, success 0, failure 0, timeout 0 
PAP attempt 0, success 0, failure 0, timeout 0 
MSCHAP attempt 0, success 0, failure 0, timeout 0 
EAP attempt 0, success 0, failure 0 
MSID attempt 0, success 0, failure 0 
AAA timeouts 0, Auth timeouts 0, Auth skipped 0 
LCP Term Req during Auth nego sent 0, rcvd 0 
A10 release during Auth nego by PDSN 0, by PCF 0 
IPCP Stage 
Failure Reasons Options 0, MaxRetry 0, Unknown 0 
Options failure reason MN Rejected IP Address 0 
LCP Term Req during IPCP nego sent 0, rcvd 0 
A10 release during IPCP nego by PDSN 0, by PCF 0 
CCP Stage 
Connection negotiated compression 0 
Compression type Microsoft 0, Stac 0, other 0 
Connections negotiated MRRU 0, IPX 0, IP 0 
Connections negotiated VJ-Compression 0, BAP 0
PPP bundles 0 
Connections failed to negotiate compression 0 
Renegotiation total 0, by PDSN 0, by Mobile Node 0 
Renegotiation success 0, failure 0, aborted 0 
Renegotiation reason: address mismatch 0, lower layer handoff 0 
GRE key change 0, other 0 
Release total 0, by PDSN 0, by Mobile Node 0 
Release by ingress address filtering 0 
Release reason: administrative 0, LCP termination 0 
Idle timeout 0, echo missed 0 
L2TP tunnel 0, insufficient resources 0 
Session timeout 0, service unavailable 0 
De-Reg from PCF 0, lifetime expiry 0, other 0 
Echo stats 
Request sent 0, resent 0, max retransmit timeout 0 
Response rcvd 0 
Discarded Packets 
Unknown Protocol Errors 0, Bad Packet Length 0
RSVP: 
IEs Parsed 0 
TFTs Created Success 0, Failure 0 
TFTs Updated Success 0, Failure 0 
TFTs Deleted Success 0, Failure 0 
Other Failure 0 
Unknown 0, Unsupported Ie types 0 
Tft Ipv4 Failure Stats 
Tft Unauthorized 0, Unsuccessful Processing 0 
Tft Treatment Unsupported 0 
Packet Filter Add 0, Replace 0 
Packet Filter Precedence Contention 0, Unavailable 0 
Packet Filter Maximum Limit 0, Non-Existent Tft add 0
QOS: 
Total Profile Download Success 0, Failure 0 
Local Profile selected 0 
Failure Reason DSCP 0, Flow Profile ID 0, 
Service option profile 0, Others 0 
Total Consolidated Profile 0, DSCP Remarked 0 
Total policing installed 0, failure 0, removed 0
slot 0: 
AHDLC Engine Type: CDMA HDLC SW ENGINE 
Engine is ENABLED 
total channels: 375000, available channels: 375000 
Framing input 0 bytes, 0 paks 
Framing output 0 bytes, 0 paks 
Framing errors 0, insufficient memory 0, queue overflow 0 
Invalid size 0 
Deframing input 0 bytes, 0 paks 
Defaming output 0 bytes, 0 paks 
Deframing errors 0, insufficient memory 0, queue overflow 0 
Invalid size 0, CRC errors 0
RADIUS DISCONNECT: 
Disconnect Request rcvd 0, accepted 0 
Disconnect Request Errors: 
Unsupported Attribute 0, Missing Attribute 0
Invalid Request 0, NAS Id Mismatch 0 
Session Cxt Not Found 0, Administratively Prohibited 

Similar 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 <--- New
router# show cdma pdsn statistics ? 
ahdlc AHDLC information 
ppp CDMA PDSN ppp statistics 
prepaid CDMA PDSN prepaid statistics 
qos CDMA PDSN QOS statistics 
raa      CDMA PDSN RAA statistics
radius CDMA PDSN traffic statistics 
rp CDMA PDSN RP statistics 
sm       CDMA PDSN SM statistics
tft CDMA PDSN TFT statistics 
| Output modifiers 
<cr>
router#

show cdma pdsn statistics rp error:

san-pdsn# show cdma pdsn statistics rp error
Last clearing of "show cdma pdsn statistics rp error" counters never
Last Update received at 00:12:54 UTC Mar 1 2009 <--- New 
RP Registration Request Error Reasons: 
Invalid Packet length 0, Protocol 0, Flags 0 
Invalid Connection ID 0, Authentication Key 0, SPI 0, Mismatch SPI 0 
Invalid Mobile ID 0, ID type 0, ID length 0 
Invalid Extension Order 0, VSE type 0, Vendor id 0 
Invalid Application type 0, Sub Application type 0 
Missing extension SSE 0, MHAE 0 
Duplicate Application type 0, GRE Key 0, CVSE 0 
Airlink Retransmission with same sequence number 0 
Airlink Invalid attribute length 0, sequence number 0, record 0 
Airlink Unknown attribute 0, Duplicate attribute 0 
Airlink Initial RRQ No Setup 0, Contains Stop 0, Contains SDB 0 
Airlink Start before Setup 0, Start in De-Registration 0
Airlink GRE Key change no Setup 0, Rereceive Setup with same GRE Key 0 
Airlink Start rcvd during active 0, Stop rcvd during dormant 0 
De-Registration received for unknown session 0 
Re-Registration received during session disconnect 0 
Processing error due to memory failure 0 
RP Registration Update Ack Error Reasons: 
Invalid Packet length 0, Protocol 0 
Invalid Connection ID 0, Authentication Key 0, SPI 0 
Invalid Mobile ID 0, ID type 0, ID length 0 
Invalid Extension Order 0, VSE type 0 
Missing extension SSE 0, RUAE 0 
Received for unknown session 0, discard memory failure 0 
RP Session Update Ack Error Reasons: 
Invalid Packet length 0, Protocol 0 
Invalid Connection ID 0, Authentication Key 0, SPI 0 
Invalid Mobile ID 0, ID type 0, ID length 0 
Invalid Extension Order 0, VSE type 0 
Missing extension SSE 0, RUAE 0 
Received for unknown session 0, discard memory failure 0 
RP Registration Reply Error Reasons: 
Not sent memory allocation failure 0, Internal error 0 
Reply not sent to PCF security not found/parse error 0 
RP Registration Update Error Reasons: 
Not sent memory allocation failure 0, Internal error 0 
RP Session Update Error Reasons: 
Not sent memory allocation failure 0, Internal error 0 
Other Error Reasons: 
Maximum configured/limit number of session reached 0

show cdma pdsn cac:

pdsn_act# show cdma pdsn cac
                       Output in Values          Output in percentage
 Total 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 The show cdma pdsn cac command does not display CPU and memory related details.


Debug Commands in the Single IP Architecture

Table 19 shows the debug commands in the single IP architecture:

Table 19 Debug Commands in the Single IP Architecture

Command
Aggregation Required?
Is the exec command sent to TCOP?

debug cdma pdsn *

No

Yes

debug ppp negotiation

No

Yes

debug aaa id

No

Yes

debug aaa accounting

No

Yes

debug aaa authentication

No

Yes

debug aaa authorization

No

Yes

debug ip mobile

No

Yes

debug aaa pod

No

Yes

debug radius

No

Yes

debug tacacs

No

Yes


Network Management and MIBs

See the Radius disconnect enabled section.

Features Not Supported

Cross chassis configuration synchronization.

Summary of Features Reused from Other Gateways

SAMI or HA 5.0

Osler - User Interface, show commands, bulk statistics

SNMP single interface

Config single interface

IXP lookup for GRE/IP, IP/IP, MIP/UDP tunnels

IXP defragmentation for tunnels

AAA responsiveness traps

Crash information or single interface for failovers

Intra-chassis configuration sync

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:

L2TP

MIP RRQ forwarding

TCOP-TCOP redundancy

IXP - per user table

See the Command Reference for Cisco PDSN Release 5.1 in IOS Release 12.4(22)XR1 for more information about configuration commands for Single IP per Blade in Cisco PDSN Release 5.1.

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

Show Subscriber Commands

Monitor Subscriber Commands

Show Subscriber Session

Bulk Statistics Collection

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 20).

Table 20 Installing Osler

Command
Description

: tclsh disk0:pdsn_Osler-Package.tcl

-pkg install|uninstall

Installs or uninstalls the PDSN Osler package. If uninstall is specified, there is no need to specify the rest of the arguments.

-f file name

The file archive on SUP flash for installing the Osler package.

-maxP number

Maximum number of policies that can be run simultaneously. Minimum must be five and maximum must not exceed nine.

-tftpN IP address

IP address or hostname of the TFTP server to store the statistics, traces and subscriber information.

-statsLD Directory Path

Local directory path on SUP to store the statistics temporarily.

-statRD Directory Path

Directory path on remote TFTP server to store the bulk statistics for Osler.

-statT [Periodicity [min]]

Bulk statistics reporting periodicity in minutes. (Default is 30 minutes). Must be in increments of 15 and in the range of 30 to 1440.

-subRD Directory Path

Directory path on remote TFTP server to store the subscriber data.

-traceLD [Directory Path]

Local directory path on SUP to store the traces temporarily.

-traceRD Directory Path

Directory path on remote TFTP server to store the trace subscriber data.


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/traces

The above example assumes that:

There is a TFTP server running on IP 1.1.1.19 with the directory dirname writable for the TFTP access.

/tftpboot/utharani/stats/globalStats, /tftpboot/dirname/traces and /tftpboot/dirname/Osler_Lib directories are present and writable for all on 1.1.1.19


Tip If the PDSN Osler installation package stops in between, press the Enter key to let installation script to continue further.


To uninstall the PDSN Osler Package, the following is an example:

Single chassis environment:

tclsh disk0:pdsn_Osler-Package.tcl -pkg uninstall 


NoteDual chassis mode is not present in the PDSN Osler package.

The PDSN-Osler installation script assumes that the path specified in all of the statsRD, subRD and traceRD arguments exist and is writable at the TFTP server (as specified with tftpN argument).

All the files contained in the installation package must be copied in the same directory path to that of EEM user policy directory configuration (that is, "event manager directory user policy") on SUP. If there is no configuration related to EEM user policy directory, then all the installation files must be copied to disk0:/pdsn_osler and the EEM user policy configuration is set to disk0:/pdsn_osler.

Before uninstalling the PDSN-Osler package, make sure that the bulk statistic reporting is stopped.


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:

All - Summary of all sessions of users at the chassis level.

Card - Summary of all user sessions on a particular card, slot, or blade.

CPU - Summary of all users on a particular CPU.

Connect - Summary of all users with a connect time greater than, less than, or equal to a time value.

FA - Chassis - Summary of all visitors on FAs within the PDSN.

FA - member - Summary of all users FA-specific-FA within the PDSN.

HA - User - Summary of all users registered with a particular HA.

Address space - Summary of all users in this address space.

Calltype - Summary of all users for this Call Type.

NAI/User - Summary of all users for this NAI.

Three display formats are provided: summary, brief, and verbose.

Summary - A simple total of subscribers matching the display policy including packets in, packets out and bytes in, bytes out.

Brief - 'One-line-of-output-per-subscriber' format for each subscriber matching the display policy.

Verbose - 'Multiple-lines-of-output-per-subscriber' format for each subscriber matching the display policy.

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 We do not recommend that you run this policy. Because of the huge amount of data (500,000 subscribers per blade multiplied by the number of SAMI blades) to the SUP card, the policy takes an extended period of time to process it. The fully-loaded chassis may take one to two hours to display all the subscribers.

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 If the total number of subscribers exceeds 1000 per PCOP, this policy does not display the subscribers on screen. However, you can view the list of subscribers by redirecting output to a file.


The below example is a snippet of the display output:

----------- Slot 1/CPU 5, show cdma pdsn session detail-------------

Mobile Station ID IMSI 09003000001
  PCF IP Address 6.6.6.2, PCF Session ID 1
  A10 connection time 02:25:51,  registration lifetime 65535 sec
  Number of successful A11 reregistrations 0
  Remaining session lifetime INFINITE
  Always-On not enabled for the user

  Current Access network ID 0006-0606-02
  Last airlink record received is Active Start, airlink is active
  GRE protocol type is 0x8881
  GRE sequence number transmit 867, receive 860
  Using interface Virtual-Access2.1, status OPN
  Using AHDLC engine on slot 0, channel ID 10
  Service Option EV-DO Flow Discrimination 0 DSCP Included 0
  Flow Count forward 0 reverse 0
  This session has 1 flow
  This session has 0 service flows
  Session Airlink State Active
  This session has 0 TFTs
  Qos subscriber profile
    Max Aggregate Bandwidth : 1
Inter User Priority : 1000
    Maximum Flow Priority : 120980
    Forward profile-id : 4660
    Forward profile-id : 9097
    Forward profile-id : 14454
    Reverse profile-id : 6295
    Reverse profile-id : 17185
    Bidirectional profile-id : 22136
    Bidirectional profile-id : 26505

  Flow service Simple, NAI osler1
    Mobile Node IP address 4.4.4.1
    Packets in 0, bytes in 0
    Packets out 0, bytes out 0

  Qos per flow : osler1
    Max Aggregate Bandwidth : 1
    Inter User Priority : 1000
    Maximum Flow Priority : 120980
    Number of Persistent Tft : 34567

    Forward profile-id : 4660
    Forward profile-id : 9097
    Forward profile-id : 14454
    Reverse profile-id : 6295
    Reverse profile-id : 17185
    Bidirectional profile-id : 22136 
    Bidirectional profile-id : 26505

Show 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 We do not recommend you to run this policy because it is through huge amount of data (500,000 subscribers per blade multiplied by the number of SAMI blades) to the SUP card, and the policy takes an extended period of time to process it. The fully-loaded chassis may take one to two hours to display all the subscribers.

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 If the total number of subscribers exceeds 1000 per PCOP, this policy does not display the subscribers on screen. However, you can view the list of subscribers by redirecting output to a file.


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 Interface
09003000001     6.6.6.2                   1 00:27:02 OPN      0     1 Virtual-Access2.1
09003000053     6.6.6.5                  51 00:00:32 OPN      0     1 Virtual-Access2.2

Show 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 :121
Total  Number of Paks in :83866
Total  Number of Paks out :87872
Total  Number of bytes in :1341130
Total  Number of bytes out :2601436

Show 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 We do not recommend you to run this policy because it is through huge amount of data (500,000 subscribers per blade multiplied by the number of SAMI blades) to the SUP card, and the policy takes an extended period of time to process it. The fully-loaded chassis may take one to two hours to display all the subscribers.

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 If the total number of subscribers exceeds 1000 per PCOP, this policy does not display the subscribers on screen. However, you can view the list of subscribers by redirecting output to a file.


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 09003000003
  PCF IP Address 6.6.6.5, PCF Session ID 1
  A10 connection time 00:08:36,  registration lifetime 65535 sec
  Number of successful A11 reregistrations 0
  Remaining session lifetime INFINITE
  Always-On not enabled for the user
  Current Access network ID 0006-0606-05
  Last airlink record received is Active Start, airlink is active
  GRE protocol type is 0x8881
  GRE sequence number transmit 14, receive 0
  Using interface Virtual-Access2.1, status OPN
  Using AHDLC engine on slot 0, channel ID 54
  Service Option EV-DO Flow Discrimination 0 DSCP Included 0
  Flow Count forward 0 reverse 0
  This session has 1 flow
  This session has 0 service flows
  Session Airlink State Active
  This session has 0 TFTs
  Qos subscriber profile
    Max Aggregate Bandwidth : 1
    Inter User Priority : 1000
    Maximum Flow Priority : 120980
    Forward profile-id : 4660
    Forward profile-id : 9097
    Forward profile-id : 14454
    Reverse profile-id : 6295
    Reverse profile-id : 17185
    Bidirectional profile-id : 22136
    Bidirectional profile-id : 26505

  Flow service Mobile, NAI scdma_osler3@ark.com
    Mobile Node IP address 9.9.9.2

    HA IP address 5.5.5.2
    Packets in 0, bytes in 0
    Packets out 0, bytes out 0

  Qos per flow : scdma_osler3@ark.com
    Max Aggregate Bandwidth : 1
    Inter User Priority : 1000
    Maximum Flow Priority : 120980
    Number of Persistent Tft : 34567
    Forward profile-id : 4660
    Forward profile-id : 9097
    Forward profile-id : 14454
    Reverse profile-id : 6295
    Reverse profile-id : 17185
    Bidirectional profile-id : 22136
    Bidirectional profile-id : 26505

Show 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 We do not recommend you to run this policy. Because of the huge amount of data (500,000 subscribers per blade multiplied by the number of SAMI blades) to the SUP card, the policy takes an extended period of time to process it. The fully-loaded chassis may take one to two hours to display all the subscribers.

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 If the total number of subscribers exceeds 1000 per PCOP, this policy does not display the subscribers on screen. However, you can view the list of subscribers by redirecting output to a file.


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 Interface
09003000001     6.6.6.2                   1 00:28:39 OPN      0     1 Virtual-Access2.1
09003000053     6.6.6.5                  51 00:02:09 OPN      0     1 Virtual-Access2.2

Show 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]):  1
SHOW SUBSCRIBER SUMMARY <-> (All Subscribers on the Card: 1)
-------------------------------
Total  Number of sessions :121
Total  Number of Paks in :84555
Total  Number of Paks out :88561
Total  Number of bytes in :1352154
Total  Number of bytes out :2620915

Show Subscriber Verbose CPU

This command shows all the subscribers from the specific TCOP on a SAMI card. This command internally uses execute-on [TCOP] show cdma pdsn session detail on the specified {Card, PCOP} and parse the output.


Caution We do not recommend you to run this policy. Because of the huge amount of data (500,000 subscribers per blade multiplied by the number of SAMI blades) to the SUP card, the policy takes an extended period of time to process it. The fully-loaded chassis may take one to two hours to display all the subscribers.

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 location.


Note If the total number of subscribers exceeds 1000 per PCOP, this policy does not display the subscribers on screen. However, you can view the list of subscribers by redirecting output to a file.


The below example is a snippet of the display output:

>> Now enter the ',' separated SAMI Card & CPU ID (e.g. 4,5): 1,5
----------- Slot 1/CPU 5, show cdma pdsn session detail-------------

Mobile Station ID IMSI 09003000051
  PCF IP Address 6.6.6.2, PCF Session ID 51
  A10 connection time 00:08:24,  registration lifetime 65535 sec
  Number of successful A11 reregistrations 0

  Remaining session lifetime INFINITE
  Always-On not enabled for the user
  Current Access network ID 0006-0606-02
  Last airlink record received is Active Start, airlink is active
  GRE protocol type is 0x8881
  GRE sequence number transmit 62, receive 55
  Using interface Virtual-Access2.2, status OPN
  Using AHDLC engine on slot 0, channel ID 53
  Service Option EV-DO Flow Discrimination 0 DSCP Included 0
  Flow Count forward 0 reverse 0
  This session has 1 flow
  This session has 0 service flows
  Session Airlink State Active
  This session has 0 TFTs
  Qos subscriber profile
    Max Aggregate Bandwidth : 1
    Inter User Priority : 1000
    Maximum Flow Priority : 120980
    Forward profile-id : 4660
    Forward profile-id : 9097
    Forward profile-id : 14454
    Reverse profile-id : 6295
    Reverse profile-id : 17185
    Bidirectional profile-id : 22136
    Bidirectional profile-id : 26505

  Flow service Simple, NAI osler1
    Mobile Node IP address 4.4.4.5
Packets in 0, bytes in 0
    Packets out 0, bytes out 0

  Qos per flow : osler1
    Max Aggregate Bandwidth : 1
    Inter User Priority : 1000

    Maximum Flow Priority : 120980
    Number of Persistent Tft : 34567
    Forward profile-id : 4660
    Forward profile-id : 9097
Forward profile-id : 14454
    Reverse profile-id : 6295
    Reverse profile-id : 17185
    Bidirectional profile-id : 22136
    Bidirectional profile-id : 26505

Show Subscriber Brief CPU

This command shows all the subscribers from the specific TCOP on a SAMI card. This command internally uses execute-on [TCOP] show cdma pdsn session brief on the specified {Card, PCOP} and parse the output to present it in short form.


Caution We do not recommend you to run this policy. Because of the huge amount of data (500,000 subscribers per blade multiplied by the number of SAMI blades) to the SUP card, the policy takes an extended period of time to process it. The fully-loaded chassis may take one to two hours to display all the subscribers.

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 location.


Note If the total number of subscribers exceeds 1000 per PCOP, this policy does not display the subscribers on screen. However, you can view the list of subscribers by redirecting output to a file.


The below example is a snippet of the display output:

>> Now enter the ',' separated SAMI Card & CPU ID (e.g. 4,5): 1,5
  >> Large number of records to process. Should I tftp it (y/n): y
Redirected the file PPC3-SLOT1-04_33_58.19_Feb_2009
***********************************************************************
=================== Total OP-REDIRECTED Records Found ==================

Show Subscriber Summary CPU

This command shows the subscribers from the specific TCOP on a SAMI card. This command internally uses execute-on [TCOP] show cdma pdsn session summary on the specified {Card, PCOP} and parse the output.

The below example is a snippet of the display output:

>> Now enter the ',' separated SAMI Card & CPU ID (e.g. 4,5): 1,5
SHOW SUBSCRIBER SUMMARY <-> (All Subscribers on the Slot,CPU: [1,5])
-------------------------------
Total  Number of sessions :121
Total  Number of Paks in :120771
Total  Number of Paks out :124777
Total  Number of bytes in :1931750
Total  Number of bytes out :3648760

Show Subscriber Verbose with Connect

This command shows the subscribers with a lifetime within the specified parameters in hh:mm:ss format.This command internally uses show cdma pdsn session lifetime age {greater | less | equals} [time] detail and parse the output.

Because of the huge amount of data to the SUP card, the policy takes an extended period of time to process the data, if the criterion matches for large number of subscribers.

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 location.


Note If the total number of subscribers exceeds 1000 per PCOP, this policy does not display the subscribers on screen. However, you can view the list of subscribers by redirecting output to a file.


The below example is a snippet of the display output:

>> Now enter the lifetime (hh:mm:ss format): 0:2:29
>> Enter the value type for Life Time Record (e.g: greater|lesser|equals): greater
----------- Slot 1/CPU 5, show cdma pdsn session lifetime age greater 0:2:29 
detail-------------

Mobile Station ID IMSI 09003000051
  PCF IP Address 6.6.6.2, PCF Session ID 51
  A10 connection time 00:04:25,  registration lifetime 65535 sec
  Number of successful A11 reregistrations 0
  Remaining session lifetime INFINITE
  Always-On not enabled for the user
  Current Access network ID 0006-0606-02

  Last airlink record received is Active Start, airlink is active
  GRE protocol type is 0x8881
  GRE sequence number transmit 38, receive 31
  Using interface Virtual-Access2.2, status OPN
  Using AHDLC engine on slot 0, channel ID 55
  Service Option EV-DO Flow Discrimination 0 DSCP Included 0
  Flow Count forward 0 reverse 0
  This session has 1 flow
  This session has 0 service flows
  Session Airlink State Active
  This session has 0 TFTs
  Qos subscriber profile
    Max Aggregate Bandwidth : 1
    Inter User Priority : 1000
    Maximum Flow Priority : 120980
    Forward profile-id : 4660
    Forward profile-id : 9097
    Forward profile-id : 14454
    Reverse profile-id : 6295
    Reverse profile-id : 17185
    Bidirectional profile-id : 22136
    Bidirectional profile-id : 26505

  Flow service Simple, NAI osler1
    Mobile Node IP address 4.4.4.5
    Packets in 0, bytes in 0
    Packets out 0, bytes out 0

  Qos per flow : osler1
    Max Aggregate Bandwidth : 1
    Inter User Priority : 1000
    Maximum Flow Priority : 120980
    Number of Persistent Tft : 34567
    Forward profile-id : 4660

    Forward profile-id : 9097
    Forward profile-id : 14454
    Reverse profile-id : 6295
    Reverse profile-id : 17185
    Bidirectional profile-id : 22136
    Bidirectional profile-id : 26505

Show Subscriber Brief with Connect

This command shows the subscribers with a lifetime within the parameters in the hh:mm:ss format. This command internally uses show cdma pdsn session lifetime age {greater | less | equals} [time] brief and parse the output.

Because of large amount of data to the SUP card, the policy takes an extended period of time to process the data, if the criterion matches for large number of subscribers.

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 location.


Note If the total number of subscribers exceeds 1000 per PCOP, this policy does not display the subscribers on screen. However, you can view the list of subscribers by redirecting output to a file.


The below example is a snippet of the display output:

>> Now enter the lifetime (hh:mm:ss format): 0:2:59
>> Enter the value type for Life Time Record (e.g.: greater|lesser|equals): greater

----------- Slot 1/CPU 5, show cdma pdsn session lifetime age greater 0:2:59 
brief-------------
MSID            PCF IP Address          PSI      Age  St SFlows Flows Interface
09003000051     6.6.6.2                  51 00:05:10 OPN      0     1 Virtual-Access2.2

Show Subscriber Summary with Connect

This command shows the subscribers with a lifetime within the parameters in the hh:mm:ss format. This command internally uses show cdma pdsn session lifetime age {greater | less | equals} [time] summary and parse the output.

The below example is a snippet of the display output:

>> Now enter the lifetime (hh:mm:ss format): 1:23:0 
>> Enter the value type for Life Time Record (e.g: greater|lesser|equals): greater 

SHOW SUBSCRIBER SUMMARY <-> (With specified lifetime: 1:23:0)
-------------------------------
Total Number of sessions with lifetime greater than the given time :120
Total Number of Paks in :121117
Total Number of Paks out :125114
Total Number of bytes in :1937152
Total Number of bytes out :3657995

Show Subscriber Verbose from FA-Chassis

This command shows the total number of visitors serviced by the FA in the chassis. This command internally uses show ip mobile visitor and parse the output.


Caution We do not recommend you to run this policy. Because of the huge amount of data (500,000 subscribers per blade multiplied by the number of SAMI blades) to the SUP card, the policy takes an extended period of time to process it. The fully-loaded chassis may take one to two hours to display all the subscribers.

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 location.


Note If the total number of subscribers exceeds 1000 per PCOP, this policy does not display the subscribers on screen. However, you can view the list of subscribers by redirecting output to a file.


The below example is a snippet of the display output:

----------- Slot 1/CPU 5, show ip mobile visitor-------------

Mobile Visitor List:
Total 1
scdma_osler3@ark.com:
    Home addr 9.9.9.2
    Interface Virtual-Access2.1, MAC addr 0000.0000.0000
    IP src 0.0.0.0, dest 5.5.5.1, UDP src port 434
    HA addr 5.5.5.2, Identification CD1EB19A.10000
    Lifetime 00:10:00 (600) Remaining 00:03:05
    Tunnel0 src 5.5.5.1, dest 5.5.5.2, reverse-allowed
    Routing Options 

Show Subscriber Brief From FA-Chassis

This command shows total number of visitors serviced by the FA in the chassis. This command internally uses show ip mobile visitor brief and parses the output to present in a short form.

If the specific FA has a large number of subscribers in the chassis, the policy may take an extended period of time to display all the subscribers. In such cases, we recommend that you do not run this command often.

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 location.


Note If the total number of subscribers exceeds 1000 per PCOP, this policy does not display the subscribers on screen. However, you can view the list of subscribers by redirecting output to a file.


The below example is a snippet of the display output:

----------- Slot 1/CPU 5, show ip mobile visitor brief-------------
Mobile Visitor List:
Total 1
scdma_osler3@ark.com:
    Home addr 9.9.9.1
    MAC addr 0000.0000.0000
    HA addr 5.5.5.2
    FA addr 5.5.5.1
    Lifetime 00:10:00 (600) Remaining 00:08:03

Show Subscriber Summary from FA-Chassis

This command shows the total number of visitors serviced by the FA in the chassis. This command internally uses show ip mobile visitor summary and parse the output.

The below example is a snippet of the display output:

SHOW SUBSCRIBER SUMMARY <-> (FA-Chasis Visitors)
-------------------------------
FA-Chasis visitors List:
Total 1

Show Subscriber Verbose from FA-Member

This command shows the total number of visitors serviced by FA in the specified service card. This command internally uses show ip mobile visitor [Card] and parse the output.


Caution We do not recommend you to run this policy. Because of the huge amount of data (500,000 subscribers per blade multiplied by the number of SAMI blades) to the SUP card, the policy takes an extended period of time to process it. The fully-loaded chassis may take one to two hours to display all the subscribers.

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 location.


Note If the total number of subscribers exceeds 1000 per PCOP, this policy does not display the subscribers on screen. However, you can view the list of subscribers by redirecting output to a file.


The below example is a snippet of the display output:

>> Now enter the Card number for FA-Member visitors: 1
----------- Slot 1/CPU 5, show ip mobile visitor-------------

Mobile Visitor List:
Total 1
scdma_osler3@ark.com:
    Home addr 9.9.9.2
    Interface Virtual-Access2.3, MAC addr 0000.0000.0000
    IP src 0.0.0.0, dest 5.5.5.1, UDP src port 434
    HA addr 5.5.5.2, Identification CD229382.10000
    Lifetime 00:10:00 (600) Remaining 00:02:39
    Tunnel0 src 5.5.5.1, dest 5.5.5.2, reverse-allowed
    Routing Options 

Show Subscriber Brief from FA-Member

This command shows the total number of visitors serviced by FA in the specified service card. This command internally uses show ip mobile visitor [card] brief and parse the output.

If the specific FA has a large number of subscribers in card, the policy takes an extended period of time to display all the subscribers. In such cases, we recommend that you do not run this command often.

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 location.


Note If the total number of subscribers exceeds 1000 per PCOP, this policy does not display the subscribers on screen. However, you can view the list of subscribers by redirecting output to a file.


The below example is a snippet of the display output:

>> Now enter the Card number for FA-Member visitors: 1
----------- Slot 1/CPU 5, show ip mobile visitor brief-------------
Mobile Visitor List:
Total 1
scdma_osler3@ark.com:
    Home addr 9.9.9.2
    MAC addr 0000.0000.0000
    HA addr 5.5.5.2
    Lifetime 00:10:00 (600) Remaining 00:04:57

Show Subscriber Summary from FA-Member

This command shows the total number of visitors serviced by FA in the specified service card. This command internally uses show ip mobile visitor [card] summary and parse the output.

The below example is a snippet of the display output:

SHOW SUBSCRIBER SUMMARY <-> (FA-Member Visitors: 1)
-------------------------------
FA-Member Visitors List:
Total 1

Show Subscriber Verbose from HA-User

This command shows the total number of users registered with a particular HA. This command internally uses show ip mobile visitor ha-addr [ha-ip] on all the TCOPs and parse the output.


Caution We do not recommend you to run this policy. Because of the huge amount of data (500,000 subscribers per blade multiplied by the number of SAMI blades) to the SUP card, the policy takes an extended period of time to process it. The fully-loaded chassis may take one to two hours to display all the subscribers.

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 location.


Note If the total number of subscribers exceeds 1000 per PCOP, this policy does not display the subscribers on screen. However, you can view the list of subscribers by redirecting output to a file.


The below example is a snippet of the display output:

>> Now enter the HA-User address (HA IP): 5.5.5.2
----------- Slot 1/CPU 5, show ip mobile visitor ha-addr 5.5.5.2-------------
Mobile Visitor List:
Total 1
scdma_osler3@ark.com:
    Home addr 9.9.9.2
    Interface Virtual-Access2.3, MAC addr 0000.0000.0000
    IP src 0.0.0.0, dest 5.5.5.1, UDP src port 434
    HA addr 5.5.5.2, Identification CD228505.10000
    Lifetime 00:10:00 (600) Remaining 00:07:33
    Tunnel0 src 5.5.5.1, dest 5.5.5.2, reverse-allowed
    Routing Options 

Show Subscriber Brief from HA-User

This command shows the total number of users registered with a particular HA. This command internally uses show ip mobile visitor ha-addr [ha-ip] brief and parse the output.

If the specific HA has large number of subscribers in card, the policy takes an extended period of time to display all the subscribers; not recommended to run more often.

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 location.


Note If the total number of subscribers exceeds 1000 per PCOP, this policy does not display the subscribers on screen. However, you can view the list of subscribers by redirecting output to a file.


The below example is a snippet of the display output:

>> Now enter the HA-User address (HA IP): 5.5.5.2
----------- Slot 1/CPU 5, show ip mobile visitor ha-addr 5.5.5.2 brief-------------
Mobile Visitor List:
Total 1
scdma_osler3@ark.com:
    Home addr 9.9.9.2
    MAC addr 0000.0000.0000
    HA addr 5.5.5.2
    Lifetime 00:10:00 (600) Remaining 00:04:07

Show Subscriber Summary from HA-user

This command is implemented to show the total number of users registered with a particular HA. This command internally uses show ip mobile visitor ha-addr [ha-ip] summary and parses the output.

The below example is a snippet of the display output:

>> Now enter the HA-User address (HA IP): 5.5.5.2
SHOW SUBSCRIBER SUMMARY <-> (HA-User IP: 5.5.5.2)
-------------------------------
HA User Subscriber List:
Total 1

Show Subscriber Verbose within Address Space

This command shows all the subscribers within the given address space. This command internally uses show cdma pdsn flow mn-ip-address range [mn-ip] detail and parse the output.


Caution We do not recommend you to run this policy. Because of the huge amount of data (500,000 subscribers per blade multiplied by the number of SAMI blades) to the SUP card, the policy takes an extended period of time to process it. The fully-loaded chassis may take one to two hours to display all the subscribers.

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 location.


Note If the total number of subscribers exceeds 1000 per PCOP, this policy does not display the subscribers on screen. However, you can view the list of subscribers by redirecting output to a file.


The below example is a snippet of the display output:

>> Now enter the ',' separated starting IP address & end IP address(e.g. 
10.114.200.49,10.114.200.180) : 4.4.4.1,4.4.4.10
----------- Slot 1/CPU 5, show cdma pdsn flow mn-ip-address range 4.4.4.1 4.4.4.10 
detail-------------

  Flow service Simple, NAI osler1@cisco.com

    Mobile Node IP address 4.4.4.1
    Packets in 0, bytes in 0
    Packets out 0, bytes out 0

  Qos per flow : osler1@cisco.com
    Max Aggregate Bandwidth : 1
    Inter User Priority : 1000
    Maximum Flow Priority : 120980
    Number of Persistent Tft : 34567
    Forward profile-id : 4660
    Forward profile-id : 9097
    Forward profile-id : 14454
    Reverse profile-id : 6295
    Reverse profile-id : 17185
    Bidirectional profile-id : 22136
    Bidirectional profile-id : 26505

  Flow service Simple, NAI osler1@cisco.com
    Mobile Node IP address 4.4.4.2
    Packets in 1, bytes in 108
    Packets out 1, bytes out 76

  Qos per flow : osler1@cisco.com
    Max Aggregate Bandwidth : 1
    Inter User Priority : 1000
    Maximum Flow Priority : 120980
    Number of Persistent Tft : 34567
    Forward profile-id : 4660
    Forward profile-id : 9097
    Forward profile-id : 14454
    Reverse profile-id : 6295
    Reverse profile-id : 17185
    Bidirectional profile-id : 22136
    Bidirectional profile-id : 26505

Show Subscriber Brief within Address Space

This command shows all the subscribers within the given address space. This command internally uses show cdma pdsn flow mn-ip-address range <mn-ip> brief and parse the output.


Caution We do not recommend you to run this policy. Because of the huge amount of data (500,000 subscribers per blade multiplied by the number of SAMI blades) to the SUP card, the policy takes an extended period of time to process it. The fully-loaded chassis may take one to two hours to display all the subscribers.

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 location.


Note If the total number of subscribers exceeds 1000 per PCOP, this policy does not display the subscribers on screen. However, you can view the list of subscribers by redirecting output to a file.


The below example is a snippet of the display output:

>> Now enter the ',' separated starting IP address & end IP address(e.g. 
10.114.200.49,10.114.200.180) : 4.4.4.1,4.4.4.10
----------- Slot 1/CPU 5, show cdma pdsn flow mn-ip-address range 4.4.4.1 
4.4.4.10-------------
MSID            NAI                            Type         MN IP Address    St
09003000001     osler1@cisco.com                         Simple       4.4.4.2          ACT

Show Subscriber Summary within Address Space

This command shows summary of all the subscribers within the given address space. This command internally uses show cdma pdsn flow mn-ip-address range [mn-ip] summary and parse the output.

The below example is a snippet of the display output:

>> Now enter the ',' separated starting IP address & end IP address (e.g. 
10.114.200.49,10.114.200.180) : 4.4.4.1,4.4.4.10
SHOW SUBSCRIBER SUMMARY <-> (Subscriber in address range: 4.4.4.1 4.4.4.10)
-------------------------------
Number of flows having mn-ip-adress between 4.4.4.1 4.4.4.10 : 8
Total Number of Packs in :0
Total Number of Packs out :0
Total Number of bytes in :0
Total Number of Packs out :0

Show Subscriber Verbose for Calltype

This command shows the total number of users for a particular Calltype. This command internally uses show cdma pdsn session service-option [so] detail and parse the output.


Caution We do not recommend you to run this policy. Because of the huge amount of data (500,000 subscribers per blade multiplied by the number of SAMI blades) to the SUP card, the policy takes an extended period of time to process it. The fully-loaded chassis may take one to two hours to display all the subscribers.

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 location.


Note If the total number of subscribers exceeds 1000 per PCOP, this policy does not display the subscribers on screen. However, you can view the list of subscribers by redirecting output to a file.


The below example is a snippet of the display output:

Select Service type:
1.   EVDO
2.   1xRTT
3.   Quit
Enter the service Type choice from the above menu (1/2/3): 1   
----------- Slot 1/CPU 5, show cdma pdsn session service-option 59 detail-------------

Mobile Station ID IMSI 09003000051
  PCF IP Address 6.6.6.2, PCF Session ID 51
  A10 connection time 00:11:13,  registration lifetime 65535 sec
  Number of successful A11 reregistrations 0
  Remaining session lifetime INFINITE
  Always-On not enabled for the user
  Current Access network ID 0006-0606-02
  Last airlink record received is Active Start, airlink is active
  GRE protocol type is 0x8881
  GRE sequence number transmit 78, receive 71
  Using interface Virtual-Access2.2, status OPN
  Using AHDLC engine on slot 0, channel ID 55
  Service Option EV-DO Flow Discrimination 0 DSCP Included 0
  Flow Count forward 0 reverse 0
  This session has 1 flow
  This session has 0 service flows

  Session Airlink State Active
  This session has 0 TFTs
  Qos subscriber profile
    Max Aggregate Bandwidth : 1
    Inter User Priority : 1000
    Maximum Flow Priority : 120980
    Forward profile-id : 4660
    Forward profile-id : 9097
    Forward profile-id : 14454
    Reverse profile-id : 6295
    Reverse profile-id : 17185
    Bidirectional profile-id : 22136
    Bidirectional profile-id : 26505

  Flow service Simple, NAI osler1
    Mobile Node IP address 4.4.4.5
    Packets in 0, bytes in 0
    Packets out 0, bytes out 0

  Qos per flow : osler1
    Max Aggregate Bandwidth : 1
    Inter User Priority : 1000
    Maximum Flow Priority : 120980
    Number of Persistent Tft : 34567
    Forward profile-id : 4660
    Forward profile-id : 9097
    Forward profile-id : 14454
    Reverse profile-id : 6295
    Reverse profile-id : 17185
    Bidirectional profile-id : 22136
    Bidirectional profile-id : 26505

Show Subscriber Brief for Calltype

This command shows the total number of users for a particular Calltype. This command internally uses show pdsn session service-option [so] brief and parse the output.

If the specific card has large number of subscribers, the policy may take an extended period of time to display all the subscribers; not recommended to run more often.

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 location.


Note This policy does not allow to show subscribers on the screen, if the total number of subscribers are above 1000 per PCOP. However, the file option must still work.


The below example is a snippet of the display output:

Select Service type:
1.   EVDO
2.   1xRTT
3.   Quit
Enter the service Type choice from the above menu (1/2/3):   1

----------- Slot 1/CPU 5, show cdma pdsn session service-option 59 brief-------------
MSID            PCF IP Address          PSI      Age  St SFlows Flows Interface
09003000051     6.6.6.2                  51 00:12:00 OPN      0     1 Virtual-Access2.2
09003000003     6.6.6.5                   1 00:04:33 OPN      0     1 Virtual-Access2.1

Show Subscriber Summary for Calltype

This command shows the total number of users for a particular Calltype. This command internally uses show pdsn session service-option [so] summary and parse the output.

The below example is a snippet of the display output:

Select Service type:
1.   EVDO
2.   1xRTT
3.   Quit
Enter the service Type choice from the above menu (1/2/3): 1  

SHOW SUBSCRIBER SUMMARY <-> With CallType Option 59
-------------------------------
Total Number of sessions with service option 59:121
Total Number of Paks in :124122
Total Number of Paks out :128128
Total Number of bytes in :1985366
Total Number of bytes out :3744118

Show Subscriber Verbose with NAI

This command shows the subscribers with specific string within the NAI. For example, you can view subscribers for the push to talk that will have "ptt" within the NAI. This command internally uses show cdma pdsn session user *ptt* detail' and parse the output. It returns only bindings that match the "ptt" string in the NAI.

Because of the large amount of data to the SUP card, depending on the matching criterion, the policy takes an extended time to process the data.

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 location.


Note This policy does not allow to show subscribers on the screen, if the total number of subscribers are above 1000 per PCOP. However, the file option must still work.


The below example is a snippet of the display output:

>> Now enter the NAI (wild-carded or specific): *_osler*
----------- Slot 1/CPU 5, show cdma pdsn session user *_osler* detail-------------

Mobile Station ID IMSI 09003000053
  PCF IP Address 6.6.6.5, PCF Session ID 51
  A10 connection time 00:01:37,  registration lifetime 65535 sec
  Number of successful A11 reregistrations 0
  Remaining session lifetime INFINITE
  Always-On not enabled for the user
  Current Access network ID 0006-0606-05
  Last airlink record received is Active Start, airlink is active
  GRE protocol type is 0x8881
  GRE sequence number transmit 14, receive 0
  Using interface Virtual-Access2.3, status OPN
  Using AHDLC engine on slot 0, channel ID 11
  Service Option EV-DO Flow Discrimination 0 DSCP Included 0
  Flow Count forward 0 reverse 0
  This session has 1 flow
  This session has 0 service flows
  Session Airlink State Active

  This session has 0 TFTs
  Qos subscriber profile
    Max Aggregate Bandwidth : 1
    Inter User Priority : 1000
    Maximum Flow Priority : 120980
    Forward profile-id : 4660
    Forward profile-id : 9097
    Forward profile-id : 14454
    Reverse profile-id : 6295
    Reverse profile-id : 17185
    Bidirectional profile-id : 22136
    Bidirectional profile-id : 26505

  Flow service Mobile, NAI scdma_osler3@ark.com
    Mobile Node IP address 9.9.9.2
    HA IP address 5.5.5.2
    Packets in 0, bytes in 0
    Packets out 0, bytes out 0

  Qos per flow : scdma_osler3@ark.com
    Max Aggregate Bandwidth : 1
    Inter User Priority : 1000
    Maximum Flow Priority : 120980
    Number of Persistent Tft : 34567
    Forward profile-id : 4660
    Forward profile-id : 9097
    Forward profile-id : 14454
    Reverse profile-id : 6295
    Reverse profile-id : 17185
    Bidirectional profile-id : 22136
    Bidirectional profile-id : 26505

Show Subscriber Brief with NAI

This command shows the subscribers with specific string within the NAI. For example, you can view subscribers for the push to talk that will have "ptt" within the NAI. This command internally uses show cdma pdsn session user *ptt* brief and parse the output. It returns only bindings that match the "ptt" string in the NAI.

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 location.


Note This policy does not allow to show subscribers on the screen, if the total number of subscribers are above 1000 per PCOP. However, the file option must still work.


The below example is a snippet of the display output:

>> Now enter the NAI (wild-carded or specific): osler*

----------- Slot 1/CPU 5, show cdma pdsn session user osler* brief-------------
MSID            PCF IP Address          PSI      Age  St SFlows Flows Interface
09003000051     6.6.6.2                  51 00:01:35 OPN      0     1 Virtual-Access2.2

Show Subscriber Summary With NAI

This command shows the subscribers with specific string within the NAI. For example, you can view subscribers for the push to talk that will have "ptt" within the NAI. This command internally uses show cdma pdsn session user *ptt* summary and parse the output. It returns only bindings that match the "ptt" string in the NAI.

The below example is a snippet of the display output:

>> Now enter the NAI (wild-carded or specific): osler1*
SHOW SUBSCRIBER SUMMARY <-> (Matching NAI: osler1*)
-------------------------------
Total  Number of sessions with user osler1* :121
Total  Number of Paks in :124644
Total  Number of Paks out :128650
Total  Number of bytes in :1993718
Total  Number of bytes out :3759382

Monitor Subscriber Commands

Osler implements trace commands to perform all the tasks for subscriber tracing. The subscriber is identified based on the NAI or IMSI.

To trace the subscriber, the policy invokes multiple CLI commands on the processors running the active or standby PDSN to set conditional debugs, using existing IOS CLIs for that subscriber.

The set of conditional debugs is based on session, accounting, MIP, PMIP, VPDN and TFT, which results in invoking multiple commands on the processors. You do not have to set the debug conditions on all the processors.

The monitor commands must configure each SAMI processor mode command debug condition [username | calling] {NAI | IMSI} to enable the inclusion of your name or NAI in the traces.


Note For VPDN and PDSN, IMSI-based conditional debugging is not supported in Osler version 1.0.


The following command provides an option to start the subscriber tracing based on NAI or IMSI:


Note To start the subscriber tracing, the start subscriber tracing command sets the trace conditions on all active and standby PDSN instances. To avoid trace flooding, the trace condition must be set first on all the PDSN instances and then set PDSN specific traces.


SUP-7600#traces

For NAI-based tracing, the traces command uses the following commands to set the trace conditions:

trace condition

debug condition username [NAI]

For IMSI-based tracing, the traces command uses the following commands to set the trace conditions:

trace condition

debug condition calling [IMSI]

To configure show debug condition, use the command cdma pdsn debug show-conditions in configuration mode. For MIP and PMIP debugs to display debug conditions, use the ip mobile debug include username command in configuration mode.

The application specific traces are configured as below:

application specific traces

Session

debug cdma pdsn a11

debug cdma pdsn session

debug ppp negotiation

debug radius authentication

Accounting

debug radius accounting

debug cdma pdsn accounting

TFT

debug cdma pdsn rsvp

debug cdma pdsn tft

VPDN

debug vpdn l2x-errors

debug vpdn l2x-events

MIP

debug ip mobile

PMIP

debug ip mobile proxy

After debugging on PDSN instances, the traces command creates a trace log file on the local disk of the supervisor card to dump the traces. It also displays the traces on the terminal.

The trace command continuously collects the traces of subscriber, until it receives the trace stop request or the trace command registration time (default is one hour) expires. On receiving the trace stop request, it stops the subscriber tracing and it resets the trace conditions that were set while starting the tracing for the subscriber.

Stop Subscriber Tracing

You can send the trace stop request to a single subscriber at a time to stop tracing. The trace stop request contains information about transferring the trace log file to an external host and you need to confirm this information before PDSN sends the trace stop request to the corresponding trace session.

If the trace stop request needs transferring the trace log file to an external host, the trace command transfers the trace log file to an external host and deletes the trace log file from the local directory of the supervisor card.

If the trace stop request does not need transferring the trace log file to an external host, the traces command retains the trace log file in a local directory of the supervisor card.

Show Subscriber Trace Sessions

You can use the trace command to view information about all the existing trace sessions in the system.

This option shows the number of existing trace sessions and the list of subscribers for which tracing is enabled. To view the information about Osler trace conditions, this option invokes the CLI command show debugging on all PDSN instances.

Clear All Subscriber Trace Sessions

You can also clear all existing trace sessions.

Before clearing the trace sessions, this option displays the information about all the existing trace sessions in the system.

The trace clear session request also contains the information about transferring the trace log file to an external host and you need to confirm this information before PDSN sends the trace clear session request.

After sending the clear trace session request, the policy removes the conditional debug from all active and standby PDSN instances for the specific NAI or assigned IP address.

If only one debug condition exists, the application-specific traces are removed first to avoid trace flooding and then the condition is removed.

If there is no active trace session in system, this option provides the mechanism to reset the Osler trace condition which are left unclear (if any) on PDSN instances.


Note This option provides a mechanism to clear all trace sessions that are active or left uncleared. So this option resets the whole Osler trace facility on the chassis.


Traces Representation

After starting the subscriber tracing, the traces command continuously reads the traces from the system log. While logging the traces in trace log file and displaying the traces on the terminal, the trace command reformats them and categorizes the traces based on timestamps and protocols. Within the protocol, the traces are sub-categorized based on the processing stage of a particular request from the subscriber.

Trace Mode

Osler implements the subscriber tracing for brief and verbose mode, where brief mode includes only meaningful traces and verbose mode includes all subscriber traces. All the brief mode traces are maintained in one separate database file. If you want to get more traces, you can add the tokens in the database file. Pre-defined tokens are default tokens for brief traces. To add a new token, add it in a new line in a particular topic.

Protocol Selection

Osler provides the subscriber tracing on Session, Accounting, TFT, MIP, PMIP and VPDN protocols. You can thus trace the subscribers for specific protocols only.

While starting the tracing, the trace command provides an option to select one or more protocols among Session, Accounting, TFT, MIP, PMIP and VPDN protocols. The trace command enables the trace conditions, logs, and displays the conditions for selected protocols only.

Other Conditions

Because the tracing is a continuous process, it consumes CPU resources. Therefore, to meet the CPU requirements, the trace command performs the following checks:

Returns a warning to you, if the available disk space on the supervisor card is less than 20 percentage. If the available disk space is less than 20 percent, the trace command does not start tracing.

If the trace command finds more than 50 trace log files on the local trace directory of the supervisor card, then it transfers the oldest trace log file to an external host and deletes the file from the local supervisor trace directory before starting the subscriber tracing.

If logging console is enabled at severity level seven on the supervisor card, the trace command does not start the tracing.

If debug all is enabled on the supervisor card, the trace command does not start the tracing.

Before starting the tracing, the traces command must configure an applet to track the logging console command. So whenever supervisor card is configured with logging console command, the applet sends the trace stop request to all existing trace sessions.

Before starting the tracing, the trace command configures an applet to track the debug all command. So whenever debug all is enabled, the applet sends the trace stop request to all existing trace sessions.

Show Subscriber Session

The CLI or script commands are implemented as part of this module to determine which service blade is hosting the subscriber and then executes the set of IOS CLIs on that service blade and collates the results and presents in a single coherent output format.

This module runs the following CLIs on all the active SAMI card and get the session and accounting details from the card which is holding the session.

The CLI command for NAI as the condition is:

pdsn# show cdma pdsn session user NAI detail

pdsn# show cdma pdsn accounting user NAI

The CLI command for IMSI as the condition is:

pdsn# show cdma pdsn session msid IMSI_value detail

pdsn# show cdma pdsn accounting session IMSI_value

The CLI command for Mobile Node (mn) IP address as condition is:

pdsn# show cdma pdsn session mn-ip-address IP-Address detail

pdsn# show cdma pdsn accounting mn-ip-addr IP-Address

The below example is a snippet of the display output for the co mmand showSession:

pdsn-osler# showSession
   Subscriber IP Address/NAI/IMSI: osler1@cisco.com

################### SUBSCRIBER SESSION FOUND ###################

User ID: osler1@cisco.com    [Slot:1 CPU:3]
Session Details:
   Mobile Station ID IMSI 09003000001
   PCF IP Address 6.6.6.2, PCF Session ID 1
   A10 connection time 00:00:12,  registration lifetime 65535 sec
   Number of successful A11 reregistrations 0
   Remaining session lifetime INFINITE
   Always-On not enabled for the user
   Current Access network ID 0006-0606-02
   Last airlink record received is Active Start, airlink is active
   GRE protocol type is 0x8881
   GRE sequence number transmit 14, receive 7
   Using interface Virtual-Access2.1, status OPN
   Using AHDLC engine on slot 0, channel ID 3
   Service Option EV-DO Flow Discrimination 0 DSCP Included 0
   Flow Count forward 0 reverse 0
   This session has 1 flow
   This session has 0 service flows
   Session Airlink State Active
   This session has 0 TFTs
   Qos subscriber profile
   Max Aggregate Bandwidth : 1
   Inter User Priority : 1000
   Maximum Flow Priority : 120980
   Forward profile-id : 4660
   Forward profile-id : 9097
   Forward profile-id : 14454
   Reverse profile-id : 6295
   Reverse profile-id : 17185
   Bidirectional profile-id : 22136
   Bidirectional profile-id : 26505
   Flow service Simple, NAI osler1@cisco.com
   Mobile Node IP address 4.4.4.1
   Packets in 0, bytes in 0
   Packets out 0, bytes out 0
   Qos per flow : osler1@cisco.com
   Max Aggregate Bandwidth : 1
   Inter User Priority : 1000
   Maximum Flow Priority : 120980
   Number of Persistent Tft : 34567
   Forward profile-id : 4660
   Forward profile-id : 9097
   Forward profile-id : 14454
   Reverse profile-id : 6295
   Reverse profile-id : 17185
   Bidirectional profile-id : 22136
   Bidirectional profile-id : 26505

Accounting Details:
   UDR for session
   session ID: 1
   Mobile Station ID IMSI 09003000001
   A - A1:09003000001 A2: A3:
   C - C3:0
   D - D3:6.6.6.2 D4:000000000000
   E - E1:0000
   F - F1:00F1 F2:00F2 F5:003B F6:F6 F7:F7 F8:F8
   F9:F9 F10:FA F14:00 F15:0
   F16:00 F17:00 F18:00
   F19:00 F20:00 F22:00
   G - G3:0 G8:0 G9:1 G10:0 G11:0 G12:0
   G13:0 G14:245 G15:0 G16:270 G17:0
   I - I1:0 I4:0
   Y - Y2:1
   UDR for flow
   Mobile Node IP address 4.4.4.1
   B - B1:4.4.4.1 B2:osler1@cisco.com
   C - C1:000F C2:7 C4:0
   D - D1:0.0.0.0
   F - F11:01 F12:00 F13:00
   G - G1:0 G2:0 G4:1232699771
   G22:0 G23:0 G24:0 G25:0
   Packets- in:0 out:0

Note After running the showSession command, you must enter the NAI, IP address, or IMSI to look for session information for a particular subscriber.


Bulk Statistics Collection

Statistics is collected with the SNMP MIB bulk statistics feature available on the Cisco router. With the help of Osler script, the SNMP MIB object list is configured on the control processor. After enabling the bulk statistics feature, for a specified time interval, the statistics is collected and sent to the configured TFTP server. If TFTP file transfer failed, the statistics is sent to the SUP disk specified in the secondary URL.

Start Bulk Statistics

This command configures SNMP MIB objects on all the control processor. While running this command you must not use the Telnet connection, as the command fails to configure SNMP MIB objects on each PCOP. The command establishes Telnet session to each active PCOP and configures various SNMP options such as transfer parameters, object list, and schema definition. Finally, it enables statistics collection.

To enable periodic reporting of the bulk statistics, you must run startStats command. The below example is a snippet of the display output:

pdsn-osler# startStats 
mwtcp-PDSN_SUP-ftb6#startStats
Address or name of remote host to dump statistics[9.11.44.1]?
Directory path on remote host[raseshad/stats]?
Directory path on local host[disk0:/stats]?
Statistics dumping periodicity (in minutes)[30]?
Add MIP object names for statistics reporting? [y/n]y       <<<<<
Add VPDN object names for statistics reporting? [y/n]y      <<<<<
Collecting Cisco Object Names for Statistics Reporting ....

##############################################################################
Configuring Slot:1, Processor:3...
##############################################################################


Successfully enabled bulk stats reporting for Slot:1, Processor:3

##############################################################################
Configuring Slot:2, Processor:3...
#############################################################################
  
Successfully enabled bulk stats reporting for Slot:2, Processor:3

#############################################################################

Stop Bulk Statistics

This command removes configuration of SNMP MIB objects on all the control processors. While running this command, you must not telnet to any processor, as the command fails to remove configurations of SNMP MIB objects from that processor. The telnet session to each active PCOP disables statistics collection, and removes all the configuration from the control processor.

To disable the periodic reporting of the bulk statistics, you must run the stopStats command. The below example is a snippet of the display output:

pdsn-osler# stopStats 
Stopping periodic bulk statistics collection and dumping...

#############################################################################
Configuring Slot:1, Processor:3...
#############################################################################

Successfully stopped the periodic bulk stats reporting for Slot:1, Processor:3

#############################################################################
Configuring Slot:2, Processor:3...
############################################################################## 

Successfully stopped the periodic bulk stats reporting for Slot:2, Processor:3

##############################################################################

Successfully stopped the periodic reporting of bulk statistics for all active CPs!

Timesaver Before uninstalling Osler from the supervisor module, remember to stop statistics reporting. Otherwise, you have to manually stop statistics reporting from all active PCOPs.


Update Statistics Mapping File

Adds new OIDs to the mapping file, which contains all the OIDs with the Cisco object name, vendor object name, and object ID. To update the mapping file with new OIDs that need to be included in the global statistics, you can run the upStatsMap command.

The following example shows output for the upStatsMap command:

pdsn-osler# upStatsMap
Enter the Cisco Object Name: cCdmaServiceOptionSucesses
Enter the SNMP OID: 1.3.6.1.4.1.9.9.157.1.7.6.2.1.3
Enter the Vendor Object Name: ServiceOptionSucesses
Updating the mapping file disk0:/pdsn_osler/pdsn_Mappings.txt...
Done !!

See the Command Reference for Cisco PDSN Release 5.0 in IOS Release 12.4(22)XR1 for more information about configuration commands for Osler Support in Cisco PDSN Release 5.1.

Improved Throughput and Transaction Handling

This release provides improved throughout, enabling PDSN to deliver 3 Gbps. Improved throughout at 3 Gbps is possible under the following assumptions:

80 percent of the sessions has only one session and represent 1xRTT traffic.

CPS for this traffic is 20.

Average throughout or user is 12.5 kbps.

Average packet size is 1440 bytes.

20 percent of the sessions has an average of 2 flows, or Point-to-Point Protocol (PPP) sessions and represent Rev A traffic.

10 percent of the Rev A traffic has QoS enabled.

CPS for this traffic is 5.

Average throughout or user is 100 kbps.

Average packet size is 384 bytes.

All throughput parameters must be No Drop Rate (NDR), with 1 in 10,000 packet drop allowable.

Cluster Controller Support in Single IP Blade

This release introduces support for cluster controller in single IP blade. The cluster controller improves cluster capacity by reducing the resource utilization on the PDSN cluster member.

The following sections describe:

Clustering Architecture in PDSN

Functions of Cluster Controller

Metrics for Cluster Controller

Metrics Between Member and Controller

Backward Compatibility of Cluster Controller

The Controller Redundancy

Configuring Cluster Controller Support

Clustering Architecture in PDSN

The following flow describes the clustering architecture in PDSN:

One of the PCOPs on the chassis is configured to act as the controller in addition to work as a PDSN member. On this PCOP alone, the functionality of the controller and member co-exists. The single IP is only for the functionality of the member.

For a collocated controller or member, the controller and member shares the same CDMA-Ix 1 IP address.

Any packet destined for controller IP address follows the default case on the IXP and lands at PCOP, unless the session is already hosted on the collocated member. In such a case, IXP directly forwards the A11 RRQ to the appropriate TCOP. The controller shares the IMSI database of the session manager.

The session manager has both the member IP address and the TCOP address, or TCOP address against each of the IMSI it stores. For the IMSI in other members, the session manager stores the member IP address. For the IMSI hosted in the same blade, the session manager has the TCOP address. As records are reused for controller and collocated member, prohibiting the collocated member does not clear the records. But the collocated member is not considered in the load selection.

Session-up or session-down from a collocated member is informed directly to the controller instead of a separate message. So periodic update does not have any effect on the collocated member and controller.

The member queueing is not required as the single IP session manager itself queues the packets when processing.

The collocated member and controller share the same interface. On a standalone controller with collocated member, controller IP is optional. Controller IP is the HSRP address in controller redundancy and is mandatory as in earlier releases.

Other PCOPs in the chassis act only as members.

Functions of Cluster Controller

The call flow of cluster controller starts with receiving the A11 RRQ from PCF. On receiving the A11 RRQ, the controller checks whether a session already exists for IMSI. If no session exists, the controller selects the member based on the load. The load table is maintained by the controller and contains the load of all the registered members.

If the member-selected resides on another blade, the controller adds the IMSI in a temporary queue in the session manager (if the controller-periodic is configured) and rejects the A11.

The PCF then resends the A11 RRQ to the suggested member. When the session comes up on the selected member, the member sends a session-up for the IMSI. The controller, on processing the session-up from the member, makes the IMSI permanent on the session manager. The member, selected based on the load, is the co-existing member and the A11 RRQ is given to the session manager.

During handoff, the new PCF sends the A11 RRQ to the controller and the controller looks up the IMSI.
The session manager returns the IMSI with the hosted Member IP address.

If the IMSI already exists on the member, the controller sends a reject message with the already hosted member IP address. If the session manager returns TCOP address, the controller forwards the A11 RRQ to the session manager, which forwards to the selected TCOP.

Metrics for Cluster Controller

The load-balancing metric used between PCOP and TCOP is on the lines of Dynamic Feedback Protocol (DFP). The TCOPs calculate the TCOPs overall weight and send to PCOP. The PCOP performs load balancing based on the weight.

The same metric is also extended to members and the controller.

The default value for dfp_max_weight is 100 as release 4.0 is based on percentage. So the weight reported is from dfp_max_weight (when no load is present) to zero (when load is maximum).

The CPU and memory utilization are converted to a range between 0 and 16 and included in the weight calculation. When the CPU reaches 100 percentage utilization, the weight reported is zero, so that no further redirection happens to the member for the period of time. The DFP parameters are tuned after performance tests are done.

When the available bandwidth reaches the total configured bandwidth, the weight is sent as zero. The TCOP sends this metric to the PCOP.


Note The maximum CPU value is configurable upto 100 percentage. The default value is 90 percentage. The default value (that is 90 percentage) is not displayed in running configuration when configured.


Metrics Between Member and Controller

The controller is based on percentage (based on Cisco PDSN Release 4.0) and also assumes 0 is lightweight and 100 is maximum weight. To retain the logic, the consolidated weight is inverted and converted to percentage when sent to the controller. So, when the member sends the data, it is loaded in terms of 0 as lightly loaded and 100 as heavily loaded.

The consolidated weight is the weight of the least-loaded TCOP. If the maximum number of sessions or the maximum bandwidth for the blade is reached, the load is reported as 100 (heavily loaded).

The metric used between the controller and member has changed from Cisco PDSN Release 3.0 and release 4.0. To retain the backward compatibility, the new member also uses the load extension. Also, session count and maximum session count are "short" (two bytes) fields. With the member now handling the whole blade, the session count and maximum session count are exceeding their limit. So the extension must be reused but replaced with the newly defined weight.

The attributes in the load extension are:

Session count is the weight.

Maximum session count is the maximum DFP weight on the member (100).

Percentage is the percentage of the weight.

Backward Compatibility of Cluster Controller

The maximum weight (or old maximum session count) in the PDSN_LOAD extension is only two bytes, and the blade capacity is close to 200,000 sessions; the session count extension cannot be used as in previous versions of PDSN.

As the session load CVSE is reused, Cisco PDSN Release 3.0 or release 4.0 controllers still assume it to be the session counts. So, when the member session count is zero, the controllers flush their session records. In Cisco PDSN Release 5.1, the member session count is a weight and weight can be zero in the initial phases of the PDSN member that services sessions. To avoid the earlier controllers from clearing when the reported weight is zero, the new PDSN release 5.0 member sends the weight as one, if the weight computed is zero but has some sessions servicing it.

The following section describes about the various scenarios of controller and member combination:

Case 1: 3.0 Controller and 5.0 Member

As the load is sent in session count CVSE, Cisco PDSN Release 3.0 controller proceeds to work based on the session count. But we recommend the round robin selection.

Case 2: 4.0 Controller and 5.0 Member

As with Cisco PDSN Release 3.0 controller, the session count CVSE is considered and the controller continues to work. But we recommend the round robin selection.

Case 3: 5.0 Controller and 3.0 Member

The member reports the load only in terms of sessions. The load is calculated as a percentage and is used.

Case 4: 5.0 Controller and 4.0 Member

The Cisco PDSN Release 4.0 controller interprets the data and gathers the weight in terms of percentage. This weight must be used for the member.

The Controller Redundancy

The controller redundancy is not affected in the single IP. When standby controller is configured, the whole blade is used for redundancy. With single IP, when a processor in a blade reloads, the whole blade reloads. So with single IP, it is necessary to configure the session redundancy also on the blade. This configuration ensures that all the member functionality on the active blade are synchronized to the standby blade.

Configuring Cluster Controller Support

The below example snippet shows the cluster controller configuration:

pdsn# show cdma pdsn cluster controller configuration 
cluster interface GigabitEthernet0/0.341 (collocated)
no R-P signaling proxy
timeout to seek member = 10 seconds 
window 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 hello
this PDSN cluster controller is configured
 
Controller maximum number of load units = 100

The below example snippet shows the cluster controller-member configuration:

pdsn# show cdma pdsn cluster member configuration 
cluster interface GigabitEthernet0/0.341
IP address of controller is 11.1.1.50  (collocated) 
no prohibit administratively
timeout to resend status or seek controller = 10 sec or less, randomized
resend a msg for 2 timeouts sequentially if no reply, then inform operator
default:  spi 101, Timestamp +/- 0, key ascii hello
this PDSN cluster member is configured

Cluster Controller Member Configuration

The below example snippet shows the cluster controller-member configuration:

cdma pdsn cluster controller interface GigabitEthernet0/0.20
cdma pdsn cluster controller standby PDSN-ssp2-43-RP
cdma pdsn cluster controller timeout 120
cdma pdsn cluster controller member periodic-update
cdma pdsn cluster member controller 20.2.43.254
cdma pdsn cluster member interface GigabitEthernet0/0.20
cdma pdsn cluster member timeout 120
cdma pdsn redundancy

To enable round-robin method for member selection on controller, you need to enable the cdma pdsn cluster controller member selection-policy round-robin command.

The below example snippet shows the cluster member configuration:

cdma pdsn cluster member controller 20.2.43.254 
cdma pdsn cluster member interface GigabitEthernet0/0.20
cdma pdsn cluster member timeout 120 
cdma pdsn cluster member periodic-update 300

Also, the show command output in context with the above configuration:

For controller:

PDSN-controller-member#  show cdma pdsn cluster controller configuration
cluster interface GigabitEthernet0/0.20 (collocated)
no R-P signaling proxy
timeout to seek member = 10 seconds
window to seek member is 2 timeouts in a row if no reply (afterwards the member is 
declared offline)
default:  spi 300, Timestamp +/- 0, key ascii cisco
this PDSN cluster controller is configured

For controller redundancy:

database in-sync or no need to sync
group: PDSN-ssp2-43-RP
Controller maximum number of load units = 100

For collocated member:

PDSN-controller-member# show cdma pdsn cluster member configuration
cluster interface GigabitEthernet0/0.20
IP address of controller is 20.2.43.254  (collocated)
no prohibit administratively
timeout to resend status or seek controller = 120 sec or less, randomized
resend a msg for 2 timeouts sequentially if no reply, then inform operator
default:  spi 300, Timestamp +/- 0, key ascii cisco
this PDSN cluster member is configured

For remote member:

PDSN-cluster-member# show cdma pdsn cluster member configuration
cluster interface GigabitEthernet0/0.20
IP address of controller is 20.2.43.254
no prohibit administratively
timeout to resend status or seek controller = 120 sec or less, randomized
resend a msg for 2 timeouts sequentially if no reply, then inform operator
default:  spi 300, Timestamp +/- 0, key ascii cisco
this PDSN cluster member is configured

IMSI and PCF Redirection

This release supports International Mobile Subscriber Identifier (IMSI) and Packet Control Function (PCF) redirection in both cluster controller and standalone PDSN. This feature enables directing a call to a specific PDSN for troubleshooting. You can also use this feature to send specific line ranges of IMSI to a different set of PDSNs.

The following sections describe:

IMSI-based Redirection

PCF-based Redirection

Features of IMSI and PCF-based Redirection

Functions of Controller PDSN

Limitations of IMSI and PCF-based Redirection

IMSI-based Redirection

You can add IMSI-based redirection feature to the cluster controller, member, or standalone PDSN to redirect A11 Registration Requests (RRQ) from a specific or a range of IMSIs to a configured member or non-member PDSN IP.

PCF-based Redirection

You can add PCF-based redirection feature to the cluster controller, member, or standalone PDSN. Adding PCF-based redirection redirects A11 RRQs from a specific or a range of PCFs to a configured member or non-member PDSN IP.

Features of IMSI and PCF-based Redirection

This section describes the common functionality between IMSI and PCF-based redirection. Both features follow the same functionality in storage and lookup, except that IMSI-based lookup is performed before PCF-based redirection. IMSI-based redirection, therefore, takes precedence over PCF-based redirection.

The workflow of IMSI and PCF-based redirection begins with receiving the A11 RRQ. On receiving the A11 RRQ, PDSN checks whether any session exists for the IMSI. If a session exists, the packet is handed over for normal A11 processing. If no session exists, PDSN looks for a match in the IMSI redirection table that is configured with the IMSI derived from the A11 RRQ. On identifying a match, the A11 RRQ is rejected with the matched PDSN IP filled under unknown HA with code as 0x88H (136 decimal).

If no match is found, PDSN looks for a match in the PCF redirection table configured with the PCF IP address in the A11 RRQ. On identifying a match, the A11 RRQ is rejected with the matched PDSN IP filled under unknown HA with code as 0x88H (136 decimal). If no match is found in the IMSI and PCF redirection table, or if PCF or IMSI redirection is not configured, the A11 RRQ is handled by normal A11 processing.

When removing configuration of the IP address range or IMSI range, it is sufficient to give the start value of the IP or IMSI to delete the entire range. When removing a configuration, PDSN ignores the upper value of the IP or IMSI range, even if you have provided the value.

Limitations of IMSI and PCF-based Redirection

The following are the limitations that impact the functioning of IMSI and PCF-based redirection:

If you have enabled IMSI Mobile Identification Number (MIN) equivalence, PDSN takes only the ten digits of the input during lookup for IMSI redirection. The rest of the digits in the configuration are ignored. However, when you use the show run command, irrespective of the presence of IMSI MIN equivalence, the command displays the exact input; it does not print the ten-digit output that is used internally for lookup.

In PCF redirection configuration, if you provide the second IP address in the PCF range as 0.0.0.0, the second IP address is discarded; only the first IP address is considered. But if you provide the first IP address as 0.0.0.0, the CLI command configuration fails.

In IMSI or PCF redirection configuration, if you try to configure the CLI command without configuring the CDMA-Ix 1 interface or IP address, redirection fails. But if you remove the CDMA-Ix 1 interface after configuring the redirection using the CLI command, redirection from the CLI command remains without throwing up any errors or warnings.

In the IMSI or PCF redirection configuration, if you try to configure the CLI command with member value equal to IP address of the CDMA-Ix 1 interface, the redirection configuration fails. But if you change the IP address of the CDMA-Ix 1 interface after configuring redirection from the CLI command with the value equal to the member IP configured in the redirection CLI command, the redirection from the CLI command remains without throwing up errors or warnings.

Functions of Controller PDSN

The workflow of the controller PDSN starts with receiving the A11 RRQ. On receiving the A11 RRQ, PDSN checks whether a session exists for the IMSI. If a session already exists, the packet is handed over for normal A11 processing. If no session exists, PDSN checks for a match in the IMSI redirection table that is configured with the IMSI derived from the A11 RRQ. If no match is found in the IMSI redirection table, PDSN checks if the PCF address in the A11 RRQ falls within the IP address range configured under different PCF groups. If there is no match with the PCF group, the A11 RRQ is handed over to the controller load balancer to select the member PDSN from all the members available in the cluster.

If a match is identified (either IMSI or PCF), the controller gets a PDSN group. The controller then checks whether the "force" option has been configured. If "force" is configured, the controller sends an A11 Reject with the primary IP configured under PDSN. If "force" is not configured, the controller checks the PDSN whether any least-loaded member is available in the matched PDSN group.

If all the member PDSNs under the group are loaded, then the controller sends a A11 Reject with the reason "Insufficient Resources". If the controller returns a least-loaded member from the PDSN group, then with that least-loaded member a A11 Reject is sent.

Before configuring IMSI and PCF redirection, note the following points:

It is possible to configure the PDSN group without configuring any IP address range and configure the PDSN group as part of IMSI or PCF redirection. If any A11 RRQ matches this redirection, then the controller will send a A11 Reject with the reason "Insufficient Resources". Therefore, we recommend that you specify the IP address range when configuring a PDSN group.


Caution Do not configure the IMSI or PCF redirection in both controller and member, because it leads to double redirection.

When you have configured an IP address range in a PDSN group that is configured for redirection, ensure that you do not remove the IP address range. If a PCF or PDSN group has been configured for redirection and if you delete the same PDSN group, then all the IMSI or PCF redirection configurations associated with this PDSN group are removed from the configuration.

If a PDSN group is configured for redirection with "force" option enabled and the primary address from the group is deleted, then the corresponding "force" option in the redirection configuration is removed. If you configure "force" option in the redirection CLI command without the primary address in the PDSN group, then the redirection CLI command configuration fails.


Note For the "force" option to function, you must have configured the primary address in the PDSN group.


If the primary IP is configured to controller CDMA-Ix 1 address and not configured as a member, then the A11 RRQ is enqueued to the local PDSN through the session manager. If the primary IP is configured to controller CDMA-Ix 1 address and configured as a member, then the A11 RRQ is enqueued to the local member.

If the IP address range configured under PDSN or PCF group matches the range configured in a different group, then the configuration fails with an error message. If the IP address range configured under PDSN or PCF group matches the range configured in the same group, then the old configuration is retained.

When removing the configuration of IP address range in a group, if the given IP address matches the range in a different group, then the configuration is not removed because it is not possible to delete the IP address range of a different group. When removing the configuration of the IP address range or IMSI range, you can give the start value of the IP or IMSI to delete the entire range. When removing a configuration, PDSN ignores the upper value of the IP or IMSI range, even if you have provided the IP or IMSI range.

If you have enabled IMSI MIN equivalence, PDSN takes only the ten digits of the input during lookup for IMSI redirection. The rest of the digits in the configuration are ignored. However, when you use the show run command, irrespective of the presence of IMSI MIN equivalence, the command displays the exact input; it does not print the ten-digit output that is used internally for lookup.

The following is a sample configuration that enables you to configure IMSI redirection for a standalone PDSN from the CLI command:

pdsn# cdma pdsn redirect imsi {Single-bound IMSI | Lower-bound IMSI} [Upper Bound IMSI] 
member [Member IP]

cdma pdsn redirect ?
imsi - IMSI Redirection
pcf - PCF Redirection

cdma pdsn redirect imsi ?
Single or Start IMSI - 15 digit IMSI address

cdma pdsn redirect imsi 123456789012345 ?
Ending IMSI - 15 digit IMSI address

cdma pdsn redirect imsi 123456789012345 123456789012400 ?
member - PDSN member

cdma pdsn redirect imsi 123456789012345 123456789012400 member ?
PDSN IP address - IP address of PDSN where A11 need to be redirected

To remove IMSI redirection for a standalone PDSN from the CLI command:

pdsn# no cdma pdsn redirect imsi {Single-bound IMSI | Lower-bound IMSI}

Note Lower-bound IMSI identifies the lower value in the IMSI range; you do not need to give the higher value in the IMSI range.


To configure PCF redirection CLI command for a standalone PDSN from the CLI command:

pdsn# cdma pdsn redirect pcf {Single or Lower-bound PCF IP_address | Upper-bound PCF 
IP_address} member Member_IP

pdsn# cdma pdsn redirect ?
imsi - MSID Redirection
pcf - PCF Redirection
pdsn# cdma pdsn redirect pcf ?
PCF IP address - Single or Start of the range of PCF IP address

pdsn# cdma pdsn redirect pcf 11.11.11.11 ?
PCF IP address - Last PCF address in the range

pdsn# cdma pdsn redirect pcf 11.11.11.11 11.11.11.200 ?
member - PDSN member

pdsn# cdma pdsn redirect pcf 11.11.11.11 11.11.11.200 member ?
PDSN IP address - IP address of PDSN where A11 need to be redirected

To remove PCF redirection for a standalone PDSN from the CLI command:

pdsn# no cdma pdsn redirect pcf Single or Lower-bound PCF IP address

Note To remove a single PCF IP or a range of PCF IPs configured, you only need to give the lower value of the range.


The following commands introduced in Cisco PDSN Release 5.0 enable you to configure the cluster controller PDSN:

To configure the cluster controller for a PCF group:

pdsn# cdma pdsn cluster controller pcf group number

description group name

pcf ip [end_ip]

pcf ip [end_ip]

To configure the cluster controller for a PDSN group:

pdsn# cdma pdsn cluster controller pdsn group number

description group name

pdsn ip [end_ip]

pdsn ip [end_ip]

primary ip

To configure the cluster controller for IMSI or PCF redirection:

pdsn# cdma pdsn cluster controller redirect

imsi IMSI_range pdsn pdsn_group_number [force]

pcf pcf_group_number pdsn pdsn_group_number [force]

Mobile IP and AAA Attributes for China Telecom

This release introduces support for MIP and AAA attributes required for China Telecom (CT).

The following sections describe:

Calling Station ID in MIP RRQ

Correlation ID in MIP RRQ

Proxy Mobile IP Indicator Attribute

Proxy Mobile IP Capability Indicator Attribute

PDSN Service Address

Charging Type

Calling Station ID in MIP RRQ

The calling station ID as the normal vendor specific extension (NVSE) is the carrier in MIP Registration Request (RRQ) between the FA and HA.

The configuration for the calling station ID:

router(config)# cdma pdsn attribute vendor 20942 send a1 mip_rrq

Correlation ID in MIP RRQ

The correlation ID as NVSE is the carrier in the MIP RRQ between the FA and HA. The correlation ID from PDSN is sent in the MIP RRQ to the HA. This ID is sent in all HA-generated accounting records.

The configuration for the correlation ID:

router(config)# cdma pdsn attribute vendor 20942 send c2 mip_rrq

Proxy Mobile IP Indicator Attribute

The PMIP indicator is a VSA. The PMIP indicator is returned via Remote Authentication Dial-In User Service (RADIUS) to PDSN as an access-accept packet, so that PDSN starts PMIP on behalf of the subscriber.

Proxy Mobile IP Capability Indicator Attribute

The PMIP capability indicator is a VSA. PDSN sends the capability indicator through RADIUS to the AAA server as an access-request packet to indicate to the AAA server that PDSN supports PMIP and it is enabled. If the capability indicator attribute is missing, then PMIP is not supported by PDSN.

The configuration for the PMIP capability indicator:

router(config)# cdma pdsn attribute vendor 20942 send pmip_capability access_request

PDSN Service Address

PDSN service address is a VSA. This service address is sent to AAA by accounting-start message.

The configuration for PDSN service message:

pdsn-stby-ftb4-73(config)# cdma pdsn attribute vendor 20942 send pdsn-src-addr ?

pdsn-stby-ftb4-73(config)# acct_reqs Send pdsn-src-addr attribute in acct-reqs ?

pdsn-stby-ftb4-73(config)# cdma pdsn attribute vendor 20942 send pdsn-src-addr ac ?

pdsn-stby-ftb4-73(config)# cdma pdsn attribute vendor 20942 send pdsn-src-addr acct_reqs

Charging Type

The charging type is a CT VSA that is downloaded in the access-accept message form the AAA server (if charging type is configured in the AAA subscriber profile for a particular user). Cisco PDSN sends this downloaded attribute value to the AAA server by using the accounting-start message.

This charging type is of three types as below:

0x00000001 - Postpaid

0x00000002 - Prepaid

0x00000003 - Postpaid and prepaid

To download the charging type, the following CLI command must be enabled:

pdsn_active(config)# cdma pdsn attribute vendor 20942

To remove the configuration:

pdsn_active(config)# no cdma pdsn attribute vendor 20942

The following example snippet shows the downloaded charging type for each flow:

pdsn_active# show cdma pdsn session
Mobile Station ID MIN 2000000003
  PCF IP Address 10.1.1.1, PCF Session ID 1
  A10 connection time 00:00:05,  registration lifetime 500 sec
  Number of successful A11 re-registrations 0
  Remaining session lifetime 494 sec
  Always-On not enabled for the user
  Current Access network ID 000A-0101-01
  Last airlink record received is Connection Setup, airlink is active
  GRE protocol type is 0x8881
  GRE sequence number transmit 14, receive 22
  Using interface Virtual-Access2.1, status OPN
  Using AHDLC engine on slot 0, channel ID 6
  Service Option EV-DO Flow Discrimination 0 DSCP Included 0
  Flow Count forward 0 reverse 0
  This session has 1 flow
  This session has 0 service flows
  Session Airlink State Setup
  This session has 0 TFTs
  Qos subscriber profile
    Max Aggregate Bandwidth : 200
    Inter User Priority : 1000

  Flow service Mobile, NAI mwts-mip-np-user11@ispxyz.com
    Mobile Node IP address 12.1.1.10
    Home Agent IP address 4.1.1.2
    Packets in 0, bytes in 0
    Packets out 0, bytes out 0
    Charge Type 1 
    Radius disconnect enabled

MIB Support

This release introduces support for several new MIBs, related to single IP and chassis-wide MIBs. Many MIBs are used as a source of Key Performance Indicators (KPIs).

The following sections describe:

MIBs as source of KPIs

Model for MIBs

MIBs as source of KPIs

The MIBs that are used as a source of KPIs are:

RFC 2006 MIB

CISCO-CDMA-PDSN-MIB

CISCO-CDMA-PDSN-EXT-MIB

CISCO-VPDN-MGMT-MIB

CISCO-VPDN-MGMT-EXT-MIB

CISCO-AAA-SERVER-MIB

RFC 2618 RADIUS Authentication Client MIB

IF-MIB

CISCO-IP-LOCAL-POOL-MIB

CISCO-PROCESS-MIB

CISCO-MEMORY-POOL-MIB (Replaced by ENHANCED-MEMPOOL-MIB)

CISCO-ENHANCED-MEMPOOL-MIB

The CISCO-PROCESS-MIB, http://tools.cisco.com/Support/SNMP/do/BrowseMIB.do?local=en&mibName=CISCO-PROCESS-MIB, and the CISCO-MEMORY-POOL-MIB, http://tools.cisco.com/Support/SNMP/do/BrowseMIB.do?local=en&step=2&mibName=CISCO-MEMORY-POOL-MIB are affected by the requirement to provide a single MIB report per-service blade, PDSN-SIP-50.


NoteYou cannot set a value using SNMPSET through SNMP; that is, no write access is allowed for a read-write or read-create object.

TCOP-level traps (MN authentication failure, registration ID mismatch) and load high trap because CPU, I/O, and process memory are not supported in single IP.

There are no SNMP SET for CDMA PDSN MIBs, TCOP-level traps (MN authentication failure, registration ID mismatch) and load high trap because of CPU, I/O, and process memory are not supported in single IP.

There are no SNMP SET and traps for CISCO-VPDN-MGMT MIBs and CISCO-AAA_-SERVERS-MIB.


Both these MIBs contain per-processor content. The information for all six application processors is reported with one SNMP GET, each MIB contains six entries, one per-application processor.

The IF-MIB contains information for interfaces of the traffic plane processors, in addition to the interfaces of the control plane processor.

The CISCO-PROCESS-MIB contains a facility to provide information for one or more CPUs. The CSG2 project developed a solution, which requires usage of the ENTITY-MIB in conjunction with the CISCO-PROCESS-MIB.

The CISCO-MEMORY-POOL-MIB does not support this capability. However, the CSG2 project developed a solution, incorporating the CISCO-ENHANCED-MEMPOOL-MIB, http://tools.cisco.com/Support/SNMP/do/BrowseMIB.do?local=en&step=2&submitClicked=true&mibName=CISCO-ENHANCED-MEMPOOL-MIB#dependencies, which is reused for this release.

Both CISCO-CDMA-PDSN-MIB and CISCO-CDMA-PDSN-EXT-MIB currently support only global statistics and PCF-based statistics. All these attributes are independent of multiple CPUs. So, aggregation of values is done on the PCOP.

Both CISCO-VPDN-MGMT-MIB and CISCO-VPDN-MGMT-EXT-MIB currently support only VPDN information,VPDN tunnel information,VPDN tunnel user information, and failure history per-user. All these attributes are independent of multiple CPUs. Aggregation of values is done on the PCOP.

CISCO-AAA-SERVER-MIB currently supports only distinct statistics for each AAA function, status of servers providing AAA functions, and table for configuring AAA servers. All these attributes are independent of multiple CPUs (except configuration table). Aggregation of values is done on the PCOP.

Model for MIBs

The model followed for each MIBs is described in this section. The TCOPs are provided with a mechanism whereby they periodically PUSH data that is required by the SNMP MIBs to the PCOP. A process on the PCOP periodically receives this data and puts it into appropriate temporary structures indexed by TCOP index.

When an SNMP GET arrives at the PCOP, the PCOP aggregates the data or in the case of individual entries per-TCOP, does not aggregate the data; and fills in the summed value or the non-summed value into the SNMP variables that are relevant to the GET request. The rest of the code fills in the SNMP variables into the response PDU and sends it back to the entity that requested the GET.

Aggregate counters are available on PCOP or each counter is turned into a table, indexed by the TCOP index. PCOP either pulls the data at the time of SNMP GET to fill in the SNMP response PDU or it uses the values in the pushed data in temporary structures to fill in the SNMP variables; and then fill in the SNMP response PDU back to the manager entity. The model for MIBs is either a push model or an on-demand pull model to get the data on the PCOP.

Table 21 describes the different MIBs that are supported in this release:

Table 21 PDSN Supported MIBs 

MIB
Description
Does it need information from TCOP?
If Yes, mechanism

RFC 2006-MIB

Uses the RFC 2006 definitions of managed objects for IP mobility support using SMIv2.

No. There are no traffic counters.

Cisco-CDMA-PDSN-MIB / CISCO-CDMA-PDSN-EXT-MIB

Supports CDMA PDSN feature.

Yes.

PDSN global statistics is aggregated periodically every minute.

Registrations and PCF-based statistics are based on pull mechanism. Data aggregator on PCOP, and data provider on TCOP.

RFC 2618 RADIUS Authentication Client MIB

Uses the definitions defined in RFC 2618.

No. There are no traffic counters.

Reused from HA 5.0.

IF-MIB

Contains information for interfaces of the traffic plane processors in addition to the interfaces of the control plane processor.

Yes.

Data aggregator on PCOP and data provider on TCOP, follows push paradigm.

Resource intensive for virtual-access interface. So these interfaces do not respond to the queries. Other interfaces are as in HA 5.0.

CISCO-IP-LOCAL-POOL-MIB

Defines the configuration and monitoring capabilities relating to local IP pools.

No. There are no traffic counters.

CISCO-ENHANCED-MEMPOOL-MIB

For monitoring the memory pools of all physical entities on a managed system.

Yes.

Data aggregator on PCOP and data provider on TCOP. Follows push paradigm. Each TCOP sends update every second to PCOP.

CISCO-PROCESS-MIB

Describes the statistics of active system processes on processors running IOS, the six processors on the two daughter cards.

Yes.

Data aggregator on PCOP and data provider on TCOP. Follows push paradigm. CPU statistics from TCOP is sent every second; other statistics are sent every minute to PCOP.

CISCO-ENTITY-MIB

The MIB module for representing multiple logical entities supported by a single SNMP agent.

Yes.

Data aggregator on CP and data provider on TP.

CISCO-VPDN-MGMT-MIB/CISCO-VPDN-MGMT-EXT-MIB

Supports the VPDN feature of Cisco IOS. The following entities are managed:

Global VPDN information

VPDN tunnel information

VPDN tunnel user information

Failure history per user

Yes.

Global information, tunnel information, user information, and failure history per-user-based statistics are based on pull mechanism. Data aggregator on PCOP and data provider on TCOP.

CISCO-AAA-SERVER-MIB

Provides configuration and statistics reflecting the state of the AAA server operations within the device.

The AAA server MIB provides the following information:

A table for configuring AAA servers.

Distinct statistics for each AAA function.

Status of servers providing AAA functions.

Yes.

Data aggregator on PCOP and data provider on TCOP. Follows pull paradigm.


Trap Generation for AAA Server Unresponsiveness

This release introduces support for sending an SNMP trap or a notification to NMS server when the AAA server unresponsiveness is noticed by PDSN while authenticating MNs.

For each RADIUS server, you can configure the threshold percentage values; that is, normal or high threshold values. When the round-trip time of RADIUS messages between PDSN and the AAA server exceeds or falls below the threshold values, an SNMP trap or notification is sent to the NMS server indicating the AAA server's responsiveness or unresponsiveness. Similarly, when the number of RADIUS retransmit messages rises above or falls below the threshold values, an SNMP trap or message is sent to the NMS server indicating the AAA server's responsiveness or unresponsiveness. By default, the threshold values for both round-trip time and retransmits are:

Normal—0

High—100

For example, when the round-trip time or the number of retransmits exceeds the high threshold value, an SNMP trap or notification is sent to the NMS server indicating that the AAA server state is BUSY or DOWN. Similarly, when round-trip time or number of retransmits falls below the low threshold value, an SNMP trap or notification is sent to the NMS server indicating that the AAA server state is NORMAL. Round-trip time and retransmits generate separate traps for the threshold values configured on them .

The conditions for notification are:

An AAA server state is notified as BUSY for round-trip time, no further traps or notifications are sent to the NMS server for that particular AAA server until that server state becomes NORMAL for the round-trip time.

After a retransmission BUSY trap is sent, no retransmission BUSY trap is sent to the same server until the server state becomes retransmission NORMAL.

After an AAA server state is informed as NORMAL for round-trip time, no further round-trip time NORMAL traps or notifications are sent to the NMS server unless the server state is identified as BUSY for round-trip time.

After the retransmission NORMAL trap is sent, no retransmission NORMAL trap is sent to the same server until the server state becomes retransmission BUSY.

To enable this feature, perform the following tasks:

 
Command
Purpose

Step 1 

Router(config)# radius-server snmp-trap timeout-threshold normal high

Enables you to generate SNMP traps that denote AAA unresponsiveness.

normal is the normal threshold in percentage (that is, 50 to 75 normal value in percentage), used to generate traps.

high is the high threshold in percentage (that is, 60 to 100 high value in percentage), used to generate traps.

Step 2 

Router(config)# radius-server snmp-trap retrans-threshold normal high

Generates a trap (SNMP notification) when round-trip time or retransmit value exceeds the high threshold value and falls below the normal threshold value. The trap is generated for either round-trip time or retransmit time.

normal is the normal threshold in percentage, used to generate traps.

high is the high threshold in percentage, used to generate traps.

Step 3 

Router(config)# snmp-server enable traps aaa_server
snmp-server host [ip address] version [1 | 2c | 3] 
[community-string] 

Enables you to generate SNMP traps that denote AAA unresponsiveness and the IP address.


Note This feature is supported only on the Cisco SAMI card on the 7600.


The RADIUS-CLIENT-AUTHENTICATION-MIB is implemented per PDSN instance and each of these instances generate a trap.

The RADIUS-CLIENT-AUTHENTICATION-MIB contains entries for timeout on AAA access. A trap is added based on this timeout occurring. It is also possible to set a threshold on round trip delay (defined as a percentage of the maximum response time), and generate a trap when that threshold is exceeded. An additional trap is generated when the round-trip delay falls below a second threshold. This provides a level of delay for trap generation.

Supervisor Support

This release introduces support for SUP32, SUP720, and RSP720 variants.

Supervisor support is provided for: Cisco Catalyst 6500 Supervisor Engine 32 (WS-SUP32-GE-3B and WS-SUP32-10GE-3B), Cisco Catalyst 6500 Supervisor Engine 720 (WS-SUP720-3B and WS-SUP720), and the new Cisco Route Switch Processor 720 (RSP720-3C-GE, RSP720-3CXL-GE, and RSP720-3CXL-10GE)

Data Over Signaling

This release introduces support for Data Over Signaling (DOS), also known as Short Data Burst feature enabling you to send short data bursts to and from mobile station (MS) using the available signaling channel.

IOS uses the Modular QoS CLI (MQC) command set and Common Classification Engine (CCE) APIs to support the flow-based infrastructure for policing. CCE is a general framework that provides classification and feature association functions to IOS applications (for example, QoS and ACL). An IOS flow is defined in CCE as a unique instance of a class and as a whole or subset of source address, source port, destination address, destination port, and protocol.

While only one vaccess per MIP session is available, there are multiple flows and each flow downloads a different policy name. So, vaccess is not a target. To enable flow-based QoS on PDSN, a virtual object is created on PDSN, which acts as an interface and attaches the service policy. This virtual object identifies flow and marking parameters to QoS.

DOS packet is identified based on the policy map configured (flow-based policy) on the router. This policy map must be downloaded from the AAA server during access-accept for each direction, The downloaded policy is installed on the PDSN over that virtual interface for that particular direction.

QoS marks the packet as eligible for DOS marking. PDSN must mark the packets with DOS attribute in the GRE header in downstream or forward direction only based on the classification criteria and only when the session is in dormant state.


Note To enable DOS feature, you need to configure cdma pdsn dos.



Note You can install the policy either as vaccess or flow; both are not supported together. If vaccess-based installation is used, then ensure that you disable CDMA PDSN QoS policy flow-only using the no cdma pdsn QoS policy flow-only command.


The following sections describe:

Flow Trigger Classification for DOS

Flow Marking Based on Classification Criteria for DOS

AT-terminated DOS

AT-generated DOS

SDB Accounting Record sent by 1xRTT PCF

Limitations for DOS

Configuring DOS

Flow Trigger Classification for DOS

When a packet arrives at the PDSN, based on the flow, the service policy associated with the virtual interface is identified and the QoS functions that need to be applied to the data packet are also identified. IOS QoS triggers flow classification because of virtual object , which is unique per flow to indicate that the classification criteria is a PDSN flow.

Flow Marking Based on Classification Criteria for DOS

For PDSN, each packet is classified and marked based on classification criteria. Currently, PDSN supports only set marking; set dos is used to mark the SDB packet based on the classification criteria.


Note DOS marking is done for downstream direction only.


AT-terminated DOS

When a PDSN sends downstream traffic over a dormant session, PDSN adds the SDB or DOS attribute in the GRE header with a flag to indicate that it is SDB traffic. This attribute signals to the PCF that it must handle the traffic appropriately while sending it to the Access Network (AN).

1x SDB/HRPD DoS Indicator

If the packet is tagged by PDSN as being suitable for 1x SDB or High Rate Packet Data (HRPD) DoS transmission, it is identified by an attribute defined as:

Type '000 0001' - Short Data Indication

Length 02H

SDI/DoS 0 - Reserved

1 - packet suitable for 1x SDB or HRPD DoS transmission

AT-generated DOS

In case of AT-generated DOS, PDSN does not perform any special handling of the received packet.

SDB Accounting Record sent by 1xRTT PCF

1xRTT PCF sends an airlink record to indicate to PDSN that an SDB transaction has occurred; this is done by sending an airlink-record Y1 set to four. PDSN increments G11 by the value of G10 and increments G13 by one, when mobile originated (y4) or mobile terminated equals zero. PDSN increments G10 by the value of G10 and increments G12 by one, when mobile originated (y4) or mobile terminated equals one.

Limitations for DOS

Performing DOS is subject to the following limitations:

If you download a new policy in the reregistration case, this new policy is not handled and only the policy downloaded during initial registration is installed. You can install the policy either as vaccess or flow (default). If you install using vaccess, ensure that you disable flow-based policy using the no cdma pdsn qos policy flow-only command.

If you have installed a particular policy-map, you can not make changes in the policy-map, associated class-maps, and action groups.

DOS marking using flow-based policy is not supported for Virtual Private dial-up Network (VPDN) calls.

Configuring DOS

To enable DOS in the PDSN:

cdma pdsn dos

For flow-based DOS classification and marking:

class-map class-pdsn
    Match any 
policy-map policy-pdsn
    Class class-pdsn
        set dos

The following CLI command in Exec mode displays flow-based QoS marking statistics when flow-based classification is enabled for a particular flow. The statistics include details such as the number of DOS-marked packets. The statistics is displayed based on specific NAI.

pdsn_active# show policy-map apn realm user1

MSID            NAI      Type         MN IP Address    St  HA IP
01002647325     user1    Simple       3.1.1.5          ACT 0.0.0.0

Service-policy output: SIP-POLICY

    Class-map: SIP-CLASS (match-all)
      5 packets, 520 bytes
      30 second offered rate 0 bps, drop rate 0 bps
      Match: any
      QoS Set
        dos
          Packets marked 5

    Class-map: class-default (match-any)
      0 packets, 0 bytes
      30 second offered rate 0 bps, drop rate 0 bps
      Match: any

The following CLI command in Exec mode displays flow-based QoS policy installation and download statistics:

pdsn_active-4# show cdm pds stat qos

QoS:
   Total Profile Download Success 10, Failure 0
	Local Profile selected 1
   Failure Reason DSCP 0, Flow Profile ID 0,
   Service option profile 0, Others 0
   Total Consolidated Profile 5, DSCP Remarked 5
   Total policing installed 5, failure 0, removed 3

Flow based QoS:
  Input policy:
    Total policy download success 2, failure 0
    Failure reason policy not configured 0, policy downloaded already 0
    Total policy installed 1, failure 0, removed 1
  Output policy:
    Total policy download success 2, failure 0
    Failure reason policy not configured 0, policy downloaded already 0
    Total policy installed 1, failure 0, removed 1

The following CLI command in Exec mode displays the number of flows using flow-based QoS:

pdsn_active-4# show cdm pds
PDSN software version 5.0, service is enabled

  A11 registration-update timeout 5 sec, retransmissions 5
  A11 session-update timeout 5 sec, retransmissions 3
  Mobile IP registration timeout 10 sec
  A10 maximum lifetime allowed 65534 sec
  GRE sequencing is on
  Maximum PCFs limit not set
  Maximum sessions limit not set (default 35000 maximum)
  SNMP failure history table size 100
  MSID Authentication is disabled
  Ingress address filtering is disabled
  Sending Agent Adv in case of IPCP Address Negotiation  is enabled
  Allow CI_ADD option during IPCP Phase  is disabled
  Aging of idle users disabled
  Radius Disconnect Capability enabled
  Multiple Service flows enabled
  Maximum number of service-flows per MN allowed is 7
  Call Admission Control disabled
  Police Downstream enabled
  Data Over Signaling disabled
  Flow based policy enabled

  Number of pcfs connected 1,
  Number of pcfs 3GPP2-RP 1,
  Number of sessions connected 1,
  Number of sessions 3GPP2-RP 1,
  Number of sessions Active 1, Dormant 0,
  Number of sessions using HDLCoGRE 1, using PPPoGRE 0
  Number of sessions using Auxconnections 0, using Policing 1, using DSCP 1
  Number of service flows 0
  Number of flows using flow based qos 1
  Number of sessions connected to VRF 0,
    Simple IP flows 1, Mobile IP flows 0,
    Proxy Mobile IP flows 0, VPDN flows 0

Differentiated Services Code Point Marking Support

This release introduces support for Differentiated Services Code Point (DSCP) marking, which uses flow-based policy.

IOS uses Modular QoS CLI (MQC) command set and Common Classification Engine (CCE) APIs to support the flow-based infrastructure for policing. CCE is a general framework that provides classification and feature association functions to IOS applications (for example, QoS, ACL, and so on). An IOS flow is defined in CCE as a unique instance of a class and as a whole or subset of source address, source port, destination address, destination port, and protocol.

While only one vaccess per MIP session is available, there are multiple flows and each flow downloads a different policy name. So, vaccess is not a target. To enable flow-based QoS on PDSN, a virtual object is created on PDSN, which acts as an interface and attaches the service policy. This virtual object identifies flow and marking parameters to QoS.

DSCP packet is identified based on the policy map configured (flow-based policy) on the router. This policy map must be downloaded from AAA during access-accept for each direction, The downloaded policy is installed on the PDSN over the virtual interface for that particular direction.

PDSN must mark the packets with DSCP in both upstream or reverse and downstream or forward direction based on the classification criteria.


Note You can install the policy either as vaccess or flow; both are not supported together. If vaccess-based installation is used, ensure that you disable CDMA PDSN QoS policy flow-only using the no cdma pdsn qos policy flow-only command.


The following sections describe:

Flow Trigger Classification for DSCP

Flow Marking Based on Classification Criteria for DSCP

Limitations for DSCP

Configuring DSCP

Flow Trigger Classification for DSCP

When a packet arrives at the PDSN, based on the flow, the service policy associated with the virtual interface is identified and the QoS functions that need to be applied on the data packet are also identified. IOS QoS triggers flow classification because of "apn_qos_info_t", which is unique per flow to indicate that the classification criteria is a PDSN flow.

Flow Marking Based on Classification Criteria for DSCP

For PDSN, each packet is classified and marked based on classification criteria. PDSN supports only set marking, such as set dos, set dscp, and set qos-group. Because qos-group and set dos are mutually exclusive, you must use either qos-group or set dos.


Note If reverse tunnel is enabled , DSCP marking happens only in the inner packet.


Limitations for DSCP

Performing DSCP is subject to the following limitations:

If you download a new policy in the reregistration case, this new policy is not handled and only the policy downloaded during initial registration is installed. You can install the policy either as vaccess or flow (default). If you install using vaccess, ensure that you disable flow-based policy using the no cdma pdsn qos policy flow-only command.

DOS marking using flow-based policy is not supported for VPDN calls.

If you have installed a particular policy map, you cannot make changes in the policy map, associated class maps, and action groups.

Configuring DSCP

For flow-based DSCP classification and marking:

Class-map class-pdsn
    Match any
Policy-map policy-pdsn-out
    Class class-pdsn
        set dscp 1

Policy-map policy-pdsn-in
    Class class-pdsn
        set dscp 1

The following CLI command in Exec mode displays flow-based QoS marking statistics when flow-based classification is enabled for a particular flow. The statistics include details such as the number of DSCP marked packets. The statistics is displayed based on specific NAI.

pdsn_active# show policy-map apn realm user1

MSID            NAI      Type         MN IP Address    St  HA IP
01002647325     user1    Simple       3.1.1.5          ACT 0.0.0.0

  Service-policy input: policy-pdsn-in

    Class-map: class-pdsn (match-all)
      5 packets, 520 bytes
      30 second offered rate 0 bps, drop rate 0 bps
      Match: any
      QoS Set
        dscp 1
          Packets marked 5

    Class-map: class-default (match-any)
      0 packets, 0 bytes
      30 second offered rate 0 bps, drop rate 0 bps
      Match: any

  Service-policy output: policy-pdsn-out

    Class-map: class-pdsn (match-all)
      5 packets, 520 bytes
      30 second offered rate 0 bps, drop rate 0 bps
      Match: any
      QoS Set
        dos
          Packets marked 5

    Class-map: class-default (match-any)
      0 packets, 0 bytes
      30 second offered rate 0 bps, drop rate 0 bps
      Match: any

The following CLI command in execution mode displays flow-based QoS policy installation and download statistics:

pdsn_active-4# show cdm pds stat qos

QOS:
   Total Profile Download Success 10, Failure 0
   Local Profile selected 1
   Failure Reason DSCP 0, Flow Profile ID 0,
   Service option profile 0, Others 0
   Total Consolidated Profile 5, DSCP Remarked 5
   Total policing installed 5, failure 0, removed 3

Flow based QoS:
  Input policy:
    Total policy download success 2, failure 0
    Failure reason policy not configured 0, policy downloaded already 0
    Total policy installed 1, failure 0, removed 1
  Output policy:
    Total policy download success 2, failure 0
    Failure reason policy not configured 0, policy downloaded already 0
    Total policy installed 1, failure 0, removed 1

The following CLI command in execution mode displays the number of flows using flow-based QoS:

pdsn_active-4# show cdm pds
PDSN software version 5.0, service is enabled

  A11 registration-update timeout 5 sec, retransmissions 5
  A11 session-update timeout 5 sec, retransmissions 3
  Mobile IP registration timeout 10 sec
  A10 maximum lifetime allowed 65534 sec
  GRE sequencing is on
  Maximum PCFs limit not set
  Maximum sessions limit not set (default 35000 maximum)
  SNMP failure history table size 100
  MSID Authentication is disabled
  Ingress address filtering is disabled
  Sending Agent Adv in case of IPCP Address Negotiation is enabled
  Allow CI_ADD option during IPCP Phase is disabled
  Aging of idle users disabled
  Radius Disconnect Capability enabled
  Multiple Service flows enabled
  Maximum number of service-flows per MN allowed is 7
  Call Admission Control disabled
  Police Downstream enabled
  Data Over Signaling disabled
  Flow based policy enabled

  Number of pcfs connected 1,
  Number of pcfs 3GPP2-RP 1,
  Number of sessions connected 1,
  Number of sessions 3GPP2-RP 1,
  Number of sessions Active 1, Dormant 0,
  Number of sessions using HDLCoGRE 1, using PPPoGRE 0
  Number of sessions using Auxconnections 0, using Policing 1, using DSCP 1
  Number of service flows 0
  Number of flows using flow based qos 1
  Number of sessions connected to VRF 0,
    Simple IP flows 1, Mobile IP flows 0,
    PMIP flows 0, VPDN flows 0

Nortel Aux A10 Support

This release introduces support for Nortel Aux A10, which enables PDSN to accept the Aux A11 Request with protocol type set to 0x88D2. The Aux A10 connection with protocol type set to 0x88D2 carries a packet with AHDLC encoding. With the new support, PDSN can handle AHDLC encoding and decoding for the packets destined to the Aux A10 with protocol type 0x88D2.

Masking Off IMSI Prefix

This release introduces support for masking off the IMSI prefix. Masking off the IMSI prefix is needed for inter-technology handoff (1xRTT to or from EVDO). In inter-technology handoff, the same PPP session is maintained when the subscriber's IMSI changes from 15 digits to or from 10 digits, or vice versa, with the upper five digits set as all ones or all zeros to or from EVDO that uses the country code in the upper five digits.

This feature masks off the upper five digits and then looks for a matching session on the PDSN. Any handoff from 1xRTT to EVDO or vice versa is treated as the same session.

The following sections describe:

Changes Related to Single IP Architecture

Functional Flow in SingleIP Architecture

Limitations for Masking Off the IMSI Prefix

Configuring Masking Off the IMSI Prefix

Changes Related to Single IP Architecture

With the IMSI MIN equivalence feature, a new flag, "strict", is introduced in the message communicated between TCOP and the IXP. The "strict" flag is set to false on enabling the IMSI MIN equivalence feature, while the default is true. For any incoming IMSI, the IXP tries to match all the digits with any IMSI entry (strict or non-strict). If it does not match, IXP checks the last 10 digits and tries to match with non-strict IMSI entries.

Functional Flow in SingleIP Architecture

The functional flow in a single IP architecture is as follows:

MN begins a call through PCF1, which sends the 10-digit IMSI as part of the A11 RRQ. IXP in SAMI receives the 10-digit IMSI and does a lookup. As the A11 RRQ is new, the lookup fails and the A11 RRQ is sent to PCOP.

PCOP does the IMSI-lookup based on the 10 digits and the lookup fails. PCOP then forwards the A11 RRQ to the TCOP selected by the Load Balancer (LB).

TCOPx processes the A11 RRQ and creates the session. On session creation, it installs the entry in IXP by sending a message with the following data, "PCF1 IP + GRE + 10 digits of IMSI with strict = FALSE".

PCF1 re-registers. After every few minutes, A11 RRQ is sent with the same 10 digits.

When the mobile roams into a different PCF2, which prefixes five zeros or different digits (country code and other data for roaming) are added to the 10-digit IMSI and sent as a 15-digit IMSI in A11 RRQ.

The IXP does a lookup in its 15-digit table and the lookup fails. Again, it does a lookup in the 10-digit table with the least 10 digits of the received 15-digit IMSI and gets a valid entry. The valid entry's strict flag is set to false, so the lookup passes and the IXP forwards the A11 RRQ to the same TCOPx.

TCOPx receives the A11 RRQ. As it receives from a different PCF, it does the handoff. On successful completion of handoff, it updates IXP with the following message "PCF2 IP + GRE + 10 digits IMSI with strict = FALSE"

PCF2 re-registers. After every few minutes, PCF2 sends A11 RRQ with the same 15 digits.

On receiving the A11 RRQ, PDSN masks the first five digits and checks whether a session is already existing for the lower ten digits IMSI.

If a session already exists, and the request received is also from the same PCF, PDSN re-registers the session.

If a session already exists and the request received is from a different PCF, PDSN does a handoff.

If no session exists, PDSN opens the new session with IMSI.

With this feature enabled, PDSN maintains all sessions based on lower ten digits of IMSI. So, we recommend not to configure or remove configuration of this feature when sessions already exist in PDSN.

The show command show cdma pdsn session msid prints the same session output if you give the lower 10 to 15 digits MSID, and the show output contains the latest IMSI received. The same case applies for clear cdma pdsn session msid command.

If you execute the show command show cdma pdsn session msid with upper 10 to 15 digits, the command does not print any session information. The same case applies for clear cdma pdsn session msid command.

Limitations for Masking Off the IMSI Prefix

In a cluster controller architecture, you must enable masking off the IMSI prefix feature in both the controller and member.

You must enable this feature in PDSN without having any sessions; it is not possible to configure or remove configuration of this feature when sessions exist in PDSN.

If you enable this feature, accounting records goes with 10-digit IMSI.

Configure the POD IMSI in the AAA server; PDSN compares with lower 10 digits and finds out whether the session exists or not.

Enable this feature in 5.0 controller and using 3.0 or 4.0 members. In this case, controller records with lower 10 digits and replies the member with 15 digits.

Configuring Masking Off the IMSI Prefix

The following CLI command configures masking off the IMSI prefix in PDSN. We recommend you to configure this CLI command in a new window (with no sessions).

Router(config)# cdma pdsn imsi-min-equivalence

To remove the configuration:

Router(config)# no cdma pdsn imsi-min-equivalence

The following example snippet shows the output with lower 11 digits for show cdma pdsn session msid command:

pdsn-act# show cdma pdsn session msid 45678987655 

Mobile Station ID IMSI 112345678987655
  PCF IP Address 4.0.0.1, PCF Session ID 1
  A10 connection time 00:02:33,  registration lifetime 20000 sec
  Number of successful A11 reregistrations 0
  Remaining session lifetime 19846 sec
  Always-On not enabled for the user
  Current Access network ID 0004-0000-01
  Last airlink record received is Active Start, airlink is active
  GRE protocol type is 0x8881
  GRE sequence number transmit 13, receive 0
  Using interface Virtual-Access3, status OPN
  Using AHDLC engine on slot 0, channel ID 2
  Service Option 1xRTT Flow Discrimination 0 DSCP Included 0
  Flow Count forward 0 reverse 0
  This session has 1 flow
  This session has 0 service flows
  Session Airlink State Active
  This session has 0 TFTs
  Qos subscriber profile

The following example snippet shows the output with lower 10 digits for show cdma pdsn session msid command:

pdsn-act# show cdma pdsn session msid 5678987655 
Mobile Station ID IMSI 112345678987655
  PCF IP Address 4.0.0.1, PCF Session ID 1
  A10 connection time 00:02:48, registration lifetime 20000 sec
  Number of successful A11 reregistrations 0
  Remaining session lifetime 19831 sec
  Always-On not enabled for the user
  Current Access network ID 0004-0000-01
  Last airlink record received is Active Start, airlink is active
  GRE protocol type is 0x8881
  GRE sequence number transmit 13, receive 0
  Using interface Virtual-Access3, status OPN
  Using AHDLC engine on slot 0, channel ID 2
  Service Option 1xRTT Flow Discrimination 0 DSCP Included 0
  Flow Count forward 0 reverse 0
  This session has 1 flow
  This session has 0 service flows
  Session Airlink State Active
  This session has 0 TFTs
  Qos subscriber profile

The following example snippet shows the output for show cdma pdsn accounting command:

pdsn1# show cdma pdsn accounting
 UDR for session
 session ID: 1
 Mobile Station ID IMSI 112345678987655

    A - A1:5678987655 A2: A3:
    C - C3:0
    D - D3:11.1.1.12 D4:000000000000
    E - E1:0000
    F - F1:0000 F2:0000 F5:003B F6:00 F7:00 F8:00
        F9:00 F10:00 F14:00 F15:0
        F16:00 F17:00 F18:00
        F19:00 F20:00 F22:00
    G - G3:0 G8:0 G9:0 G10:0 G11:0 G12:0
        G13:0 G14:176 G15:0 G16:0 G17:0
    I - I1:0 I4:0
    Y - Y2:1

 UDR for flow
    Mobile Node IP address 9.1.1.9
    B - B1:9.1.1.9 B2:g7SIP1@xxx.com
    C - C1:0025 C2:98 C4:0
    D - D1:0.0.0.0
    F - F11:01 F12:00 F13:00
    G - G1:0 G2:0 G4:1243836799
        G22:0 G23:0 G24:0 G25:0
    Packets- in:0 out:0

The following example snippet shows the output for show cdma pdsn accounting detail command:

pdsn1# show cdma pdsn accounting detail
 UDR for session
 session ID: 1
 Mobile Station ID IMSI 112345678987656

   Mobile Station ID (A1) IMSI 5678987656
   ESN (A2)
   MEID (A3)
   Session Continue (C3) ' ' 0
   Serving PCF (D3) 11.1.1.12 Base Station ID (D4) 000000000000
   User Zone (E1) 0000
   Forward Mux Option (F1) 0    Reverse Mux Option (F2) 0
   Service Option (F5) 59   Forward Traffic Type (F6) 0
   Reverse Traffix type (F7) 0    Fundamental Frame size (F8) 0
   Forward Fundamental RC (F9) 0    Reverse Fundamntal RC (F10) 0
   DCCH Frame Format (F14) 0    Always On (F15) 0
   Forward PDCH RC (F16) 0    Forward DCCH Mux (F17) 0
   Reverse DCCH Mux (F18) 0    Forward DCCH RC (F19) 0
   Reverse DCCH RC (F20) 0    Reverse PDCH RC (F22) 0

   Bad PPP Frame Count (G3) 0 Active Time (G8) 0
   Number of Active Transitions (G9) 0
   SDB Octet Count Terminating (G10) 0
   SDB Octet Count Originating (G11) 0
   Number of SDBs Terminating (G12) 0
   Number of SDBs Originating G13 0
   Number of HDLC Layer Bytes Received (G14) 290
   In-Bound Mobile IP Signalling Octet Count (G15) 0
   Out-bound Mobile IP Signalling Octet Count (G16) 0
   Last User Activity Time (G17) 0
   IP Quality of Service (I1) 0
   Airlink Quality of Service (I4) 0
   R-P Session ID (Y2) 1

 UDR for flow
    Mobile Node IP address 9.1.1.1
    IP Address (B1) 9.1.1.1,  Network Access Identifier (B2) g7SIP1@xxx.com
    Account Session ID (C1) 2
    Correlation ID (C2) ' ' 18
    Beginning Session (C4) ' ' 0
    MIP Home Agent  (D1) 0.0.0.0
    IP Technology (F11) 01 Compulsory Tunnel indicator (F12) 00
    Release Indicator (F13) 00
    Data Octet Count Terminating (G1) 0
    Data Octet Count Originating (G2) 0  Event Time G4:1243950581
    Rsvp Signaling Inbound  Count (G22) 0 Outbound Count (G23) 0
    Rsvp Signaling Packets In (G24) 0 Packets Out (G25) 0
    Packets- in:0 out:0

Persistent TFT Support

This release introduces support for installing Traffic Flow Template (TFT), which requires dependency on the AAA server attribute. PDSN rejects Resource reSerVation Protocol (RSVP) messages and fails to install the TFT if it does not receive the 3GPP2 attribute Type 89 (cdma-num-persistent) attribute from the AAA server as part of access-accept. To remove dependency on the AAA server attribute, this release merges the AAA server and local QoS profiles.

The following new command enables you to check the 3rd Generation Partnership Project 2 (3GPP2) attribute Type 89 (cdma-num-persistent) downloaded from the AAA server before installing TFT:

router(config)# cdma pdsn tft persistent-check

Depending on your configuration, PDSN behaves in the following ways:

If the new command is not configured by default, PDSN installs the TFT when it receives an RSVP packet.

If the new command is configured,

And the persistent TFT attribute has been downloaded from the AAA server, PDSN installs the TFT.

And PDSN has not downloaded the cdma-num-persistent attribute from the AAA server, PDSN applies the local QoS profile.

And the AAA server returns a value other than Type 89 (cdma-num-persistent), PDSN does not install the TFT.

And the AAA server does not return any attributes, and if PDSN is not configured with the local subscriber profile, PDSN does not install the TFT.

And the AAA server does not return any attributes, and if PDSN is not enabled to using the tft-allowed command in the local subscriber profile, PDSN does not install the TFT.

If the CLI command is configured, the Cisco PDSN Release 4.0 behavior is retained.

To remove the configuration, use the following command:

router(config)# no cdma pdsn tft persistent-check

Conserve Unique IP-ID for FA-HA IP-in-IP Tunnel

This release enables PDSN to set a valid value to the ID field in the IP header when the packet has the chance of fragmenting, by conserving the unique ID in the IP header. By using this feature, you can avoid repeating the ID number within a short time, preventing the duplication of the packet.

The following new command enables you to configure the threshold for the packet size:

Router(config)# ip mobile tunnel ip-ip conserve-ip-id threshold value

Where value represents the threshold value of the packet and now the ip-id could be:

Any number other than zero if the packet size is above the threshold value.

Zero, if the packet size is less than the threshold value.


The following example snippets show the outputs for the ip mobile tunnel ip-ip conserve-ip-id threshold command:


pdsn_active(config)# ip mobile tunnel ip-ip conserve-ip-id threshold ?
<576-1500> length in bytes

pdsn_active(config)# ip mobile tunnel ip-ip conserve-ip-id threshold 600
pdsn_active(config)# end
pdsn_active#

To remove the configuration:

pdsn_active(config)# no ip mobile tunnel ip-ip conserve-ip-id threshold 600
pdsn_active(config)# end
pdsn_active#

GRE CVSE Support in FA-HA Tunnel

This release enables PDSN and the HA to negotiate a Generic Routing Encapsulation (GRE) key, though in the earlier releases, the packets passing through the GRE-enabled reverse tunnel (FA-to-HA) have the default key value as zero. This negotiation is made possible using GRE critical vendor-specific extension (CVSE) support in the Foreign Agent-Home Agent (FA-HA) tunnel.

Here, the FA and HA can generate their own key or both of them can use the FA-generated key. You can send the GRE key CVSE to the HA by configuring the following commands:

To send the GRE CVSE in all MIP RRQs to all HAs:

Router(config)# cdma pdsn attribute send gre_cvse mip_rrq

To send GRE CVSE on a per-HA basis:

Router(config)# ip mobile foreign-agent extension gre home-agent address range or a single address

The following example snippet shows the output for the show ip mobile visitor command:

pdsn_active# show ip mobile visitor
Mobile Visitor List:
Total 1
mwts-mip-np-user11@ispxyz.com:
    Home addr 12.1.1.10
    Interface Virtual-Access2.1, MAC addr 0000.0000.0000
    IP src 0.0.0.0, dest 4.1.1.1, UDP src port 434
    HA addr 4.1.1.2, Identification CDF2DC2A.10000
    Lifetime 00:01:00 (60) Remaining 00:00:45
    Tunnel0 src 4.1.1.1, dest 4.1.1.2, reverse-allowed
    gre cvse enable 
    FA provided key 1253037210, HA returned key 2926312514
    Routing Options - (G)GRE (T)Reverse Tunneling

The following example snippet shows the output for the show ip mobile proxy registration command:

pdsn_active# show ip mobile proxy registration

Proxy Mobile Node Registrations:

userpmip1@ispxyz.com:
    Registration accepted 06/29/09 06:27:11
    Next Re-registration 00:00:13
    Registration sequence number 1
    Care-of addr 4.1.1.1, HA addr 4.1.1.2, Home addr 12.1.1.12
    gre cvse enable
    FA provided key 1527991487, HA returned key 3076709629
    Flags sbdmG-T-, Identification CDF2DD3F.8CB49CB8
    Lifetime requested 00:01:00 (60), granted 00:01:00, remaining 00:00:43

The following example snippet shows the output for show ip mobile tunnel command:

pdsn_active# show ip mobile tunnel
Mobile Tunnels:
Total mobile ip tunnels 1
Tunnel0:
    src 4.1.1.1, dest 4.1.1.2
    encap GRE/IP, mode reverse-allowed, tunnel-users 1
    Multiple GRE keys supported 
    Input ACL users 0, Output ACL users 0
    IP MTU 1472 bytes
    Path MTU Discovery, mtu: 0, ager: 10 mins, expires: never
    outbound interface Ethernet1/0
    FA created, CEF switching enabled, ICMP unreachable enabled
    5 minute input rate 0 bits/sec, 0 packets/sec
    5 minute output rate 0 bits/sec, 0 packets/sec
    0 packets input, 0 bytes, 0 drops
    0 packets output, 0 bytes

To configure the cdma pdsn attribute send gre_cvse mip_rrq command:

pdsn_active# conf term
dsn_active(config)# cdma pdsn attribute send gre_cvse mip_rrq
pdsn_active(config)# end

To configure the ip mobile foreign-agent extension gre home-agent command:

pdsn_active# conf term
pdsn_active(config)# ip mobile foreign-agent extension gre home-agent 4.1.1.2
pdsn_active(config)# end

To remove the configuration:

pdsn_active# conf term
pdsn_active(config)# no cdma pdsn attribute send gre_cvse mip_rrq

pdsn_active# conf term
pdsn_active(config)# no ip mobile foreign-agent extension gre home-agent 4.1.1.2

Remote Address Accounting

This release enables the PDSN to support remote address-based accounting (RAA). Using RAA, the number of octets exchanged between the Mobile Station (MS) and a remote IP address during a packet-data session can be counted. The PDSN enables this accounting functionality on a per-user basis, as specified in the User Profile received from the Home RADIUS server during authentication procedures. The PDSN supports Remote Address Table Index attributes from the AAA server to enable RAA in a session. The PDSN supports RAA only when the IP address is visible to it. For example, in Virtual Packet Data Networks (VPDNs), there are no IP packets and hence, the PDSN does not support RAA for VPDN calls.

The following sections describe:

Setting up a Session

About the G5 Attribute

Support for 835B-Compliant RAA Table Index Downloaded from RADIUS

Setting up a Session

This section describes the workflow to set up a session. During initial call setup, the PDSN authenticates with the AAA server and downloads the remote table index attribute as part of the access-accept. On downloading the RAA table index during access-accept, the downloaded RAA Table indices are matched against the table index configured on the PDSN. The matched indices are associated with the session; unmatched indices are dropped and not associated with the session. If the force index match is configured, and the downloaded index does not match with the configured RAA table index, the session is dropped.

About the G5 Attribute

The G5 container contains counters for forward octet count, reverse octet count, either the RAA index or the remote-network-and-mask pair , forward octet overflow count, and reverse octet overflow count.


Note Here, the G5 contains either the RAA table index or network or mask combination to be monitored.


A remote address mask is used to indicate a range of addresses for remote address accounting. The PDSN aggregates the octet counts for all the remote IP addresses of that mask and generates one remote IPv4 octet-count attribute.

The G5 attribute is included in the accounting stop and accounting interim. Some features of the attribute are:

Instances of the G5 attribute are removed after sending accounting stop. New instances are created based on a match.

Matching packets are accounted in both session and flow.

If the summarize option is not set, the G5 container contains the network-and-mask pair (that is, the unique host mask used to represent a single IP address). The table index is not present at this point; the index is present only if the summarize option is configured for the table index.

In case of redundancy, the table parameters along with the G5 containers are synchronized to standby. Here, the table parameters are synchronized to standby when configuring in active PDSN. If the G5 container is present, it is synchronized whenever an accounting request is sent.

The octet overflow attribute is present as a part of the accounting request even if the byte count does not overflow.

The following workflow describes updates to the G5 attribute during traffic flow:

1. For downstream traffic, if RAA is enabled for this session and a valid index is associated with the session, the PDSN checks if the source IP address matches the IP addresses of the associated index. For upstream traffic, the PDSN checks if the destination IP address matches the IP addresses of the associated index.

2. On finding a match:

a. If a G5 instance is present, the PDSN accounts the bytes or octet count. If the traffic matches to the existing G5 container, PDSN accounts the bytes used in that container.

b. If summarize is enabled, PDSN accounts the packet in a single G5 instance. You can enable or disable the summarize option using the Remote Table Index AAA server attribute.

c. If a match and corresponding G5 instance are not present (that is, created already), the PDSN creates a G5 instance and accounts it.

Support for 835B-Compliant RAA Table Index Downloaded from RADIUS

To support the IS835B-compliant RAA table index downloaded from the AAA server, use the new cdma pdsn accounting remote address compliance 835b command in global configuration mode:

Note that:

On configuring the CLI command, only the table index that is compliant with 835B is accepted; other forms are rejected and the corresponding sessions go down.

If the CLI command is disabled, table indexes that are compliant with 835C or D and B are accepted; other forms are rejected and the corresponding sessions go down. By default, the command is disabled.

For RAA table indexes compliant with IS835B and IS835C, the remote address octet count is in the IS835C format only.

The IS835B-compliant RAA table index downloaded from RADIUS is supported by default. This command is configured to mandate the downloaded table indices, which are in IS835B format.


Note When RAA is enabled:

IP flow accounting is not enabled.

IPv6 addressing is not supported.

Prepaid exempt is not supported.

RAA table cannot be removed if RAA enabled session exists. However, the contents of the RAA table can be modified; these changes are effective for subsequent sessions and re-registered sessions.

Remote address downloaded from the AAA server during access-accept is not supported. Only the remote table index is supported.


Configuring Remote Address Accounting

The following commands have been introduced for configuring remote address accounting.

To configure the remote address table:

pdsn(config)# cdma pdsn accounting remote address table

pdsn(config-raa)# index number

pdsn(config-raa-table)# description string

pdsn(config-raa-table)# remote address ip-addr ip-addr mask

To remove the remote address that is configured in the table:

pdsn(config)# cdma pdsn accounting remote address table

pdsn(config-raa)# index number

pdsn(config-raa-table)# no remote address ip-addr

To remove the index:

pdsn(config)# cdma pdsn accounting remote address table

pdsn(config-raa)# no index number

To remove the remote address table and to disable remote address accounting feature:

pdsn(config)# no cdma pdsn accounting remote address table


Note Disabling the configuration is not allowed when RAA enabled sessions are present.


To force remote address accounting:

pdsn(config)# cdma pdsn accounting remote address table index match


Note This command is configured to force a check with the RAA indices downloaded against the indices configured in the PDSN. If any of the table indexes downloaded for the session are not configured in the PDSN, the session is not created.


To remove force remote address accounting:

pdsn(config)# no cdma pdsn accounting remote address table index match

The following example snippet shows output for the show run command when remote address accounting is enabled:

cdma pdsn accounting remote address table
index 1 
   description test1
   remote address 1.1.1.1 255.255.255.255
   remote address 2.2.2.0 255.255.255.0 
   remote address 10.10.10.5 255.255.255.255
index 2 
   description test2
   remote address 3.3.3.3 255.255.255.255
   remote address 4.4.4.0 255.255.255.255
cdma pdsn accounting remote address index match

The following command clears all RAA-related statistics:

pdsn# clear cdma pdsn statistics

The following command enables support for the 835B-compliant RAA table index that is downloaded from the AAA server:

pdsn(config)# cdma pdsn accounting remote address compliance 835b

When you use this command, the PDSN accepts only the IS835B-compliant RAA table index downloaded from the AAA server. On disabling this command, the PDSN accepts the RAA table indexes downloaded from the AAA server that are compliant with IS835C or D and B; other forms are rejected. This command is disabled by default.

The following command disables support only for the 835B-compliant RAA table index that is downloaded from the AAA server:

pdsn(config)# no cdma pdsn accounting remote address compliance 835b

The following new commands enable you to debug remote address accounting:

pdsn# debug cdma pdsn accounting raa errors

CDMA PDSN Remote address based accounting errors debugging is on.

pdsn#debug cdma pdsn accounting raa events

CDMA PDSN Remote address based accounting events debugging is on.

See the debug commands in the Cisco Packet Data Serving Node Release 5.0 for Cisco IOS Release 12.4(22)XR1 for more information about debugging remote address accounting in Cisco PDSN Release 5.1.

Default Service Option Implementation

As part of accounting records, the PDSN sends zero to the AAA server in either these instances:

It receives a zero as the value for the F5 Service Option.

or

It did not receive the airlink start.

To set the F5 Service Option value to be a non-zero value in a controlled manner, you can now set the default SO value for accounting using the following new command:

Router(config)# [no] cdma pdsn a11 default-service-option value

The new command enables you to configure a default SO value for accounting.

To remove this setting, use the no form of this command.


Note When the F5 attribute value is not present in the received airlink start record, and if it already has a non-zero value, do not modify the Usage Data Record's (UDR) F5. If the UDR's F5 value is zero, then update F5 with the A10 service option value. If the A10 service option value is not available, update the attribute with the value configured using the new command.


Configurable Per-Flow Accounting Options

Currently, the PDSN supports per-flow based accounting, which means accounting records are sent per flow (IP flow). This release enables the PDSN to support configurable per-flow accounting optionally, which is decided either by configuring the CLI command or downloading the accounting option.

The following sections describe:

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

Configuring Per-Flow Accounting Options

The following commands are used to configure per-flow accounting options in the PDSN.

To configure CDMA PDSN accounting with main flow:

pdsn_act(config)# cdma pdsn accounting [main flow] ?

where, main flow configures main flow optionally for accounting.

To configure CDMA PDSN accounting main flow, including IP flows:

pdsn_act(config)# cdma pdsn accounting [main flow include ipflows]

where, main flow include ipflows includes IP flow data optionally in the accounting main flow.

To remove the configuration of CDMA PDSN accounting:

pdsn_act(config)# no cdma pdsn accounting ?

local-timezone Enable local timezone values for accounting

main flow Accounting on Main Flow

prepaid Prepaid related configurations

remote Configure Remote Accounting

send Accounting option

time-of-day Generate accounting record at specified time

pdsn_act(config)# no cdma pdsn accounting main flow ?

The following are the options for configuring the accounting options:

Option 1 - Configuring Accounting Option Only for Main Flow:

If the accounting option (Cisco VSA generic) is downloaded from the AAA server as 2 or the cdma pdsn accounting main flow command is enabled.

Option 2 - Configuring Accounting Option for Including Ipflows in Main Flow:

If the accounting option (Cisco VSA generic) is downloaded from the AAA server as 3 or the cdma pdsn accounting main flow include ipflows command is enabled, the accounting records are sent for main flow alone and include IPflows details.

Default Option - Per-Flow Accounting:

Per-flow accounting is performed, if option 1 is configured. If the accounting option (Cisco VSA generic) downloaded from the AAA server is other than option 1 or option 2, or if neither cdma pdsn accounting main-flow or cdma pdsn accounting main-flow include ipflows commands are enabled, the default option is configured.

Functional Flow for Configuring Per-Flow Accounting Options

The functional flow for this feature includes three options: Only Main Flow, Include IP flow in Main Flow, and Per-Flow Accounting (default).

Option 1 - Only Main Flow:

Accounting is done only on main flow. No accounting records are sent for IPflows. But upstream and downstream traffic are accounted in the respective IPflows and aux A10, if the TFT matches. However, the accounting records (start or stop or interim) are not sent for IPflows. Counters for G1 or G2, packets in or out for IPflows are not included, when the accounting records (interim and stop) of the main flow are sent.

Option 2 - Include IP Flow in Main Flow:

Accounting is done only on main flow. No accounting records are sent for IPflows. But upstream and downstream traffic are accounted in the respective IPflows and aux A10, if the TFT matches. However, the accounting records (start or stop or interim) are not sent for IPflows. Counters for G1 or G2, packets in or out for IPflows are added to G1 or G2 and packets in or out of main flow, when the accounting records (interim and stop) of main flow are sent.

Default Option - Per Flow Accounting:

Per-flow (IP flow)-based accounting is done. Accounting records are sent for main flow and IPflows.

Session and Flow Setup for Configurable Per-Flow Accounting Options

During initial call setup, the PDSN authenticates with the AAA server and downloads the accounting option as part of access-accept. On downloading the attribute, the PDSN checks whether the downloaded option is valid. If it is a valid option, the option is copied to the session. If it is not valid, the PDSN checks for configured CLI command. If the accounting option is configured, it is copied to the session. If the accounting option is not configured, there is no accounting option.

If airlink records are received for the IPflows, the records are parsed and updated. If the accounting option is valid, the accounting records for the IPflows, however, are not sent. The upstream and downstream traffic are sent over the respective IPflows and aux A10s after checking the TFT.

Before sending the accounting records (interim and stop), the PDSN checks for the accounting option and depending on the accounting option value, you can decide about including the G1 or G2, packets in or packets out to the respective attributes of the main flow. If accounting option is valid, you can reset G1 or G2, packets in or out of IPflows when you flush the IPflows for main flow.

Limitations in Configuring Per-Flow Accounting Options

The following are the limitations in configuring per-flow accounting options:

If the accounting option is downloaded twice, only the first downloaded version is considered.

The downloaded attribute is preferred to the configured value.

The accounting option is session-based and not flow-based.

The accounting option is considered only for single flow. If multiple MIP flows or a SIP, MIP flow are opened, the same accounting option is applied for each flow.

Removing the configurations commands cdma pdsn accounting main flow or cdma pdsn accounting main flow include ipflows, removes the accounting option configuration.

To maintain redundancy, the accounting option is synchronized to standby.

IP Flow Discriminator Support for PCF Backward Compatibility

PDSN adds the 4-byte IP flow discriminator to the GRE header. But some PCFs are based on the standard A.S0008 v3.0, or a lesser value that defines the IP flow discriminator to be 3 bytes without the reserved byte.

This release supports IP flow discriminator for backward compatibility of PCFs using the following new command in global configuration mode:

pdsn# cdma pdsn compliance hrpd ipflow-discriminator

On configuring this command, the IP flow discriminator is defined in the new format of 3 bytes. The A10s carry the IP flow discriminator of 3 bytes without a reserved byte. By default, the command is disabled.

Support for Remark DSCP to Max-class Value

The PDSN remarks the upstream packet with the value of the unauthorized Differentiated Services Code Point (DSCP), either to zero or to the value specified by the global configuration command cdma pdsn multiple service-flows qos remark-dscp remark_value. So all unauthorized packets are remarked only to 0 or to a global value as specified in the command.


Note The DSCP value is greater than the max-class value which is either downloaded from the AAA server or configured locally.


To remark the DSCP value of the unauthorized packet to a DSCP value on per-user basis, this release introduces a new command.

To remark the DSCP value of the packet either to the max-class value downloaded from the AAA server or to be configured locally:

pdsn# cdma pdsn multiple service-flows qos remark-maxclass

From this release, the PDSN remarks the DSCP value in the following three ways:

When the new command cdma pdsn multiple service-flows qos remark-maxclass is not configured and only cdma pdsn multiple service-flows qos remark-dscp remark_value is configured, the PDSN remarks the DSCP value with the remark_value specified in the configured cdma pdsn multiple service-flows qos remark-dscp remark_value command if the incoming packet's DSCP value is greater than max-class value.

When both the commands cdma pdsn multiple service-flows qos remark-max-class and cdma pdsn multiple service-flows qos remark-dscp remark_value are configured, the PDSN remarks the DSCP value with the max-class value, if the incoming packet's DSCP value is greater than the max-class value.

When both the commands cdma pdsn multiple service-flows qos remark-maxclass and cdma pdsn multiple service-flows qos remark-dscp remark_value are not configured, the PDSN remarks the DSCP value to 0x00 if the incoming packet's DSCP value is greater than the max-class value.

Command Support for Fragmentation Size

This release introduces a new command that enables you to set the fragmentation size of the first packet and thereby avoid further fragmentation of the second fragment in the network. With IP fragmentation, the first fragment may not include the Layer-4 header information of the inner packet. Thus, firewalls on the network that performs extensive inspection up to Layer 4, may drop the first fragment.

You can use the following new command in global configuration mode to set the fragmentation size of the first packet with Offset = 0 to set the first fragment size and ensure that the network does not drop the first segment.

pdsn# ip fragment first minimum size ?

where, size represents a number between 8 and 560 in bytes.

The size must include only the payload in multiples of 8 bytes and not any header. Otherwise, the command is rejected with the following error message:

%% First fragment payload size is not in multiples of 8.

New Statistics Counters for China Telecom

This release introduces support for new statistics counters for China Telecom.

Currently, only the PDSN-related statistics in the CLI are supported and Exhaustion of Prepaid Quota is provided by the CLI. This release supports A11 registration update per-PCF counter.

A list of new metrics is made available to China Telecom through SNMP on the PDSN. The following statistics counters are supported:

Prepaid Statistics per PCF level

Inter-PCF Handoff RRQ

Accepted Inter-PCF Handoff

EVDO Network Initial Aux A10 Connection Request

Successful PPP Connection Request

Successful PPP Initial Request

Failed PPP Connection 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

Prepaid Statistics per PCF level

The CLI command in Exec mode show cdma pdsn statistics prepaid is enhanced to per-PCF level. The updated command gives prepaid statistics at the per-PCF level.

The per-PCF level prepaid statistics counter does not have the Total Online Access Response Received and Discarded counters. But, these counters are available at the global-level prepaid statistics; if the session is deleted while processing an online response, you cannot control to increment the per-PCF level of the counters.

The following example snippet shows the output for the show cdma pdsn statistics prepaid pcf command:

pdsn1_act# show cdma  pdsn statistics prepaid pcf 2.2.2.1
  PCF 2.2.2.1, Service Option 59
   Total prepaid flows opened: 0
    Volume-based 0, Duration-based 0
    Simple IP 0, VPDN 0, Proxy Mobile IP 0, Mobile IP 0
   Total online Access Requests sent 0
   Total online Access Response
   Accepted 0, Timeout 0
   Online Access Requests sent with Update Reason:
    Pre-Initialization         0
    Initial Request            0
    Threshold Reached          0
    Quota Reached              0
    Remote Forced Disconnect   0
    Client Service Termination 0
    Main SI Released           0
    SI not eastablished        0
    Tariff Switch Update       0

Inter-PCF Handoff RRQ

Currently, only the PDSN-related statistics in the CLI are supported. This release supports inter-PCF handoff RRQ. A counter for inter-PCF handoff on a per-PCF basis is provided in the PDSN.

Accepted Inter-PCF Handoff

Currently, only the PDSN-related statistics in the CLI are supported. This release supports accepted inter-PCF handoff. A counter for accepted inter-PCF handoff on a per-PCF basis is provided in the PDSN.

EVDO Network Initial Aux A10 Connection Request

Currently, only the PDSN-related statistics in the CLI are supported. This release supports EVDO network initial aux A10 connection request. In this release, the total number of aux A10 connections is requested and a new counter is added under "statistics rp", and the per-PCF level is supported.

EVDO Network Accepted Initial Aux A10 Connection

This release supports EVDO network-accepted initial auxiliary A10 connection. In this release, the total number of aux A10 connections is successfully created and a new counter is added under "statistics rp", and a per-PCF level is supported.

New Aux Connection Requested and Accepted

Two new counters, New Aux Connection Requested and New Aux Connection Accepted are added under the show cdma pdsn statistics rp CLI command in the Exec mode. These counters are also available at the per-PCF level.

Whenever a registration or reregistration request is received by the PDSN to create n number of new aux connections, the New Aux Connection Requested counter is incremented by n. If all the aux connections are successfully created, the New Aux Connection Accepted counter is incremented by n. In case there are problems in creating any of the requested aux connections, the New Aux Connection Accepted is not incremented.

The following example snippet shows the output for the show cdma pdsn statistics rp pcf pcf IP address command:

pdsn1_act# show cdma pdsn statistics rp pcf 2.2.2.1

  PCF 2.2.2.1, Service Option 59
    Reg Request rcvd 2, accepted 2, denied 0, discarded 0
    Initial Reg Request rcvd 1, accepted 1, denied 0,discarded 0, AuxRequest 0
    Re-registration requests rcvd 1, accepted 1, denied 0, discarded 0
    Re-registration requests containing Active-Start 1, Active-Stop 0
    Re-registration requests containing new connections 0, missing connections 0, 	 		 	
remapping flows 0
    New Aux Connection Requested 4, New Aux Connection Accepted 4
    Handoff requests rcvd 0, accepted 0, denied 0, discarded 0, AuxRequest 0.

Successful PPP Connection Request

Currently, the successful PPP connection request counter is not compliant with China Telecom. In this release, this counter is updated and also added to MIB and per-PCF-based counters.

IPCP is updated in the PPP connection request counter, in both negotiations and renegotiations. For VPDN, the PDSN receives an authentication response success message from the AAA server, and updates this counter. The total successful PPP connection request is calculated as below:

Total successful PPP connection request = (Connection success + Renegotiation success).

PPP renegotiation for a VPDN call is transparent to the PDSN. Only the initial PPP connection status is updated for the VPDN call.

Successful PPP Initial Request

Currently, the successful PPP initial request counter is not compliant with China Telecom definition. In this release, this counter is updated and also added to the per-PCF-based counter.

IPCP is updated in the PPP initial request counter in the initial stage. For VPDN case, PDSN receives authentication response success message from AAA, and updates this counter.

PPP Statistics Connection Success Counter

For a VPDN call, as soon as an authentication get success is received, the connection success counter is incremented regardless of the status of the L2TP tunnel.

The following example snippet shows the output for the show cdma pdsn statistics ppp command:

pdsn1_act# show cdma pdsn statistics ppp
Last clearing of "show cdma pdsn statistics ppp" counters never
PPP:
  Current Connections 2
  Connection requests 2, success 2, failure 0, aborted 0

Failed PPP Connection Request

Not having IP resource for allocation is one of the reasons for code failure. Currently, this failure reason is not supported and only the PDSN-related statistics in CLI commands are supported. This release supports this failure reason and a failed PPP connection request is added in MIB and per-PCF-based counter.

New Counter for Not Having IP Resource for Allocation in PPP Statistics

Currently, when the IP pool is exhausted, the unknown count available under the IPCP stage is incremented if the IP pool name is downloaded from the AAA server. The other counters under release are incremented, if the pool name is locally configured. A new counter is introduced, under the show cdma pdsn statistics PPP command, to reflect the number of sessions that failed at the IPCP stage because of the IP pool exhaustion, irrespective of whether the pool name is downloaded from the AAA server or locally configured.

The old counter's behavior related to IP address exhaustion has not been changed. The new counter value does not match with the total number of failures under IPCP stage, because the IP pool exhaustion of a local pool is not considered an IPCP failure.

The following example snippet shows the output for the show cdma pdsn statistics ppp command:

pdsn_act# show cdm pdsn statistics ppp
Last clearing of "show cdma pdsn statistics ppp" counters 00:09:33
Last update received at 02:51:38 UTC Mar 1 2002
PPP:
 Current Connections 2
 Connection requests 11, success 2, failure 9, aborted 0
 Connection enters stage LCP 11, Auth 11, IPCP 11
 Connection success LCP 11, AUTH 11, IPCP 2
 Failure reason LCP 0, authentication 0, IPCP 9, other 0
 Failure reason lower layer disconnect 0
 
 A10 release before LCP nego by PDSN 0, by PCF 0

 IPCP Stage
  Failure Reasons Options 0, MaxRetry 0, Unknown 9
  Options failure reason MN Rejected IP Address 0
  LCP Term Req during IPCP nego sent 9, rcvd 0
  A10 release during IPCP nego by PDSN 0, by PCF 0
  No enough IP resource for allocation 9

PCF Terminate A10 Before LCP Stage

Currently, only the PDSN-related statistics in the CLI are supported. This release supports PCF terminate A10 before the LCP stage counter.

PPP Statistics at Per-PCF Level

The counter that gives the PPP statistics about "PCF Terminate A10 before LCP Stage" and renegotiation details are now made available at the per-PCF level.

The following example snippet shows the output for the show cdma pdsn statistics ppp pcf pcf ip address command:

pdsn1_act# show cdma pdsn statistics ppp pcf 2.2.2.1

  PCF 2.2.2.1, Service Option 59
    Current Connections 1
    Connection requests 1, success 1, failure 0, aborted 0

    A10 release before LCP nego by PDSN 0, by PCF 0

    Renegotiation total 0, by PDSN 0, by Mobile Node 0
    Renegotiation success 0, failure 0, aborted 0
    Renegotiation reason: address mismatch 0, lower layer handoff 0
    GRE key change 0, other 0

Initial Connection Requests for L2TP tunnel

Currently, only the PDSN-related statistics in the CLI are supported. This release supports initial connection requests for L2TP tunnel as a global counter. The Start-Control-Connection-Reply (SCCRQ) counter from XMIT gives the details about the initial connection request for the L2TP tunnel, when you execute the command show l2tp counters tunnel.

Successful Request for L2TP Tunnel

Currently, only the PDSN-related statistics in CLI are supported. This release supports successful request for the L2TP tunnel as a global counter. The Start-Control-Channel-Connected (SCCCN) counter from XMIT gives the details about the successful connection request for the L2TP tunnel, when you execute the show l2tp counters tunnel command.

Failed Request for L2TP Tunnel

Currently, only the PDSN-related statistics in the CLI are supported. This release supports failed request for the L2TP tunnel as a global counter. The SCCRQ - SCCCN counter from XMIT gives the details about the failed request for the L2TP tunnel, when you execute the show l2tp counters tunnel command.

Active and Dormant Session Counters

The active counters, also available at the per-PCF level, and dormant session counters give details about the total number of main connections in dormant state.

The following example snippet shows the output for the show cdma pdsn statistics pcf pcf ip address command:

pdsn1_act# show cdma pdsn pcf 2.2.2.1
PCF 2.2.2.1 has 1 session
  Received 6 pkts (185 bytes), sent 15 pkts (640 bytes)

  PCF Session ID 1, Mobile Station ID IMSI 09884708943
    A10 connection age 01:40:24
    A10 registration lifetime 65535 sec, time since last registration 6024 sec
Number of sessions Active 2, Dormant 0,

Outbound and Inbound Bytes on RP Interface

This release supports outbound and inbound bytes on RP interface (SO=33,SO=59,SO=64,SO=67) are added in the per-PCF-based counter.

Counters for Inbound and Outbound Bytes on RP Interface by Service Option

A new CLI command in Exec mode is introduced to give the total number of inbound and outbound bytes on the RP interface based on service option. This command is also available at the per-PCF level.

The following example snippet shows the output for the show cdma pdsn statistics service-option command:

san-pdsn# show cdma pdsn statistics service-option 33 ?
  pcf  give pcf ip for faster response!!
  |    Output modifiers
  <cr>

san-pdsn# show cdma pdsn statistics service-option 33 pcf ?
  A.B.C.D  PCF IP address

san-pdsn# show cdma pdsn statistics service-option 33 pcf 41.1.1.2
Service Option: 50 PCF: 41.1.1.2
  Bytes in: 0                           Bytes out: 0
  Packs in: 0                           Packs out: 0

san-pdsn# show cdma pdsn stat serv 59
Service Option: 59
  Bytes in: 184                         Bytes out: 506
  Packs in: 30                          Packs out: 1

san-pdsn# show cdma pdsn stat serv 59 pcf 41.1.1.3
Service Option: 59 PCF: 41.1.1.3
  Bytes in: 0                           Bytes out: 0
  Packs in: 0                           Packs out: 0

Features From Previous Releases

This section explains the features that were introduced in releases earlier than Cisco PDSN Release 5.1.

Inter-User Priority

PCF uses the inter-user priority attribute to schedule packets to the MN. PDSN receives this attribute from the AAA server in a RADIUS access-accept message.

Roamer Identification

Roamer Identification is a home area attribute defined by Lucent, and PDSN receives this attribute from the AAA server in a RADIUS access-accept message.

Served MDN

Served MDN is a vendor-specific attribute defined by China Telecom. It is similar to the Class IETF attribute. The Served MDN attribute is received by the PDSN from the AAA server in a RADIUS-access accept message and is included in all the accounting request messages sent to the AAA server for the session or IP flow.

The Served-MDN attribute is a China Telecom VSA that is downloaded from the AAA server as part of RADIUS access-accept message per user.

When you configure the cdma pdsn attribute vendor 20942 command, the PDSN parses the served MDN attribute, and sends the attribute in accounting messages. If parsed successfully, the attribute value is stored as part of the flow structure for the user that has received the RADIUS access-accept message.

If downloaded, this attribute is sent in all accounting request messages (start, stop, and interim-update) of the corresponding flow and its associated IP flows. If the PDSN receives multiple values of this attribute in a single access-accept message, and if they are parsed successfully, the last instance in the list of attributes downloaded is stored in the flow structure.

The PDSN drops the access-accept if it gets an invalid format or incorrect length for the Served-MDN VSA. The corresponding failure counter is then incremented. When a new value of the attribute is received in an access-accept during PPP-renegotiation or MIP reregistration, the latest value downloaded will update the existing value. And when a subsequent access-accept does not download this value, then the existing value is retained.

In case of inter-PCF handoff, this attribute is sent in both the accounting stop and accounting start message. In case of PPP renegotiation, if PDSN receives a new value, then the new value is stored in the flow structure. If a new attribute value is downloaded when the session is dormant and accounting start stop is not enabled, the accounting stop contains the old served MDN attribute value and the accounting start contains the new served MDN attribute value.

If unknown China Telecom attributes are received, these attributes are ignored.

If both IETF class attribute and CT VSA served MDN attribute is downloaded as a part of access-accept, both attributes are sent to the AAA server in accounting messages for the session.

To support the served MDN attribute in accounting, show and debugging, run the following command:

router (config)# cdma pdsn attribute vendor 20492


This new command enables the PDSN to parse the served MDN attribute, and send the attribute in accounting messages.

Framed Pool

The Framed Pool attribute is an IETF attribute downloaded by the PDSN from the AAA server in RADIUS access-accept message. This attribute value is used by the PDSN to match the IP pools configured in the PDSN, and allocates an IP address from the selected pool through PPP IPCP negotiation. The PDSN supports Cisco VSA for downloading the pool names from the AAA server. This feature is required to download the pool name as an IETF VSA.

The PDSN downloads the IETF framed-pool attribute from the AAA server as part of the access-accept message per user flow. If the local pool name matches the pool name downloaded, and if the pool has an IP address available for allocation, an IP address is allocated to the MN and the allocated IP address is sent as part of the IPCP CONFNAK message to the MN.

If the MN requests a static IP address and the IETF pool name is downloaded as well during the access-accept, the static IP address requested by the MN is given preference only when the IP address preferred is within the pool range configured in the PDSN. Otherwise, the IP address is assigned from the downloaded Pool.

If no local pool matches the pool name configured in the PDSN, or if the matched pool name does not have any address to allocate, the PPP IPCP negotiation fails, and the call is terminated. If framed IP pool and Cisco av pair pool name attributes are downloaded, the IP address is allocated from the framed pool. When multiple framed IP pool names are downloaded, the IP address is allocated from the first of the downloaded pools. If the IP addresses in the framed IP pool are exhausted, the session goes down.

The IETF pool name is synchronized to the standby unit by the AAA server subsystem. Parsing and validation of this attribute is performed by the AAA server subsystem.

Other Considerations

SIP calls are supported. For all other calls, IP address assignment will be done by the HA and the pool configuration in VAAA will be ignored by the PDSN.

For PMIP calls, the address allocated by the HA is negotiated with the MN as a part of IPCP even if a IETF pool name attribute value was downloaded.

3GPP2 DNS Server IP

The DNS server IP address attribute is a 3GPP2 VSA downloaded by PDSN from the AAA server in RADIUS access-accept message. These IP addresses downloaded from the AAA server must be sent to the MN if requested during IPCP negotiation.

The PDSN downloads the 3GPP2 DNS IP address VSA with Vendor ID 117 from the AAA server as a part of the access-accept message. Downloaded attributes are parsed for the primary and secondary IP addresses and are stored in the AAA server list for the user session. The values that are sent in sub-type 3 and 4 are not used by the PDSN. This attribute (if requested) is sent to the MN during IPCP negotiation from the AAA server list.

During PPP IPCP negotiation, the MN requests an IP address in the IPCP CONFREQ message by sending the primary DNS IP address as 0.0.0.0 and secondary DNS IP address as 0.0.0.0. If a user is authorized for the DNS IP addresses, addresses downloaded from the AAA server are sent to the MN through the IPCP CONFNAK message.

If invalid attributes are downloaded in the DNS VSA (for example, an invalid length or an invalid subtype), the PDSN drops the access-accept, and the corresponding failure counter is incremented. The PDSN does not check the content of the IP address in the primary and secondary fields and the value is sent to the MN as received.

If a user requests is sent for the DNS IP address, but the PDSN does not download the DNS IP address VSA, an IPCP CONFREJ message is sent rejecting the DNS request sent by the MN. Then the MN sends a new CONFREQ without the primary DNS address or secondary DNS address in its CONFREQ.

The attributes downloaded are sent to the MN for SIP calls when configured in VAAA. Flags downloaded are ignored by the PDSN for SIP and PMIP calls. For MIP calls, DNS is sent by the HA through MIP RRP. No configuration is required in the VAAA.

For PMIP calls, the DNS address downloaded by the HA is given preference. If the DNS IP address is downloaded from the AAA server for PMIP calls, it would not be suggested to the MN even if the MN requests for the DNS server IP address.

If multiple 3GPP2 attributes, or a combination of 3GPP2 attributes, and CISCO VSA DNS attribute are downloaded, the last downloaded attribute value is taken into consideration. In case the 3GPP2 DNS server IP address attribute is downloaded but not negotiated with the MN, it would be displayed on the session.

Virtual Route Forwarding with Sub-interfaces

The Virtual Route Forwarding (VRF) attribute is a Cisco-specific vendor attribute downloaded by the PDSN from the AAA server in a RADIUS access-accept message. The vaccess (sub-interface created per session on the PDSN) is added to the VRF matching the VRF attribute value downloaded from the AAA server. The PDSN downloads the Cisco vendor-specific VRF attribute from the AAA server as a part of the access-accept message. If this VSA is received in user authorization, and if the VRF name returned from RADIUS is configured globally on the PDSN, the PDSN will apply this VRF information for the session.

The current support on IOS creates a full vaccess interface for this user session to support VRF. VRF forces the creation of a full access interface that limits the number of sessions to 8,000 (only 8K software IDBs exist).

The VRF, when configured in PDSN, creates an instance of the routing table. When the VRF is applied to the vaccess created, after the PPP IPCP negotiation, the route inserted is in the VRF routing table and not in the global routing table. The current implementation supports VRF as an LCP-based configuration request.

Basic Functionality

The PDSN downloads the Cisco vendor-specific VRF attribute from the AAA server as a part of access-accept message. For sub-interface support of VRF, the VRF value is downloaded as an IP level attribute.

IP CEF has to be enabled for VRF to work.

If this VSA is received in user authorization, and if the VRF name returned from RADIUS is configured globally on the PDSN, then the PDSN applies this VRF information to the vaccess interface created for this user session.

You must download the "ip unnumbered" attribute with the VRF to apply the VRF attribute in the session.

If the VRF attribute is downloaded as an IP-level attribute, the vaccess created for the session is a sub-interface, and this sub-interface is added to the VRF on the PDSN that matched the VRF attribute value downloaded. If the downloaded VRF name is not configured, the call is dropped.

You must download the "ip unnumbered" attribute with the VRF to create sub-interface support in the VRF routing table. If the access-accept message from the AAA server has both the LCP and IP VRF attributes downloaded, we always create a full vaccess interface. The order of LCP VSA in the user profile does not matter. It will override any VRF-ID VSA specifications.

If the access-accept message from the AAA server has multiple IP VRF attributes downloaded, the session is dropped.

If the VRF attribute is not downloaded in order (VRF ID followed by unnumbered interface), the session will be dropped.

If the VRF attribute is configured in the virtual-template, and if no VRF is downloaded from the AAA server, the VRF attribute configured locally gets updated in the session.

If the VRF attribute is configured in the virtual template and if a different VRF attribute is downloaded from the AAA server, the VRF attribute downloaded from the AAA server is updated in the session.

The errors in the AAA server VRF attribute handling is handled by the AAA server sub-system.

The PDSN supports overlapping IP addresses for the user session with VRF.

In case of PPP renegotiation, when a VRF name is downloaded, the vaccess created for the session is now associated with new VRF.

In case a PPP renegotiation does not download a VRF name, then the vaccess for the session is not associated with the VRF.

In case a VRF attribute is downloaded during MIP and VPDN call, the VRF attribute is not used.

If for a PMIP call, the VRF attribute is downloaded, Virutal Access will be associated with VRF routing table and the reverse traffic will be sent only through the VRF enterprise.

In case of SIP+MIP calls, if the SIP call is established with VRF association, and if a MIP call is requested as the SIP call is associated with a VRF, the MIP call will not be up as the MIP RRQ from MN is sent to the VRF enterprise.

Any traffic received on VRF applied V-Access will always be forwarded to VRF enterprise, and this is an expected IOS behavior.

The PDSN supports only IPv4 addresses as a part of the VRF. IPv6 behavior is undefined.

The data traffic for a vaccess in the forward direction (toward the MN) is received from outside the enterprise, the packet will be dropped by the IOS.

Accounting of packets at the PDSN occurs normally.

MN to MN routing packets in case of associated to the same VRF are sent to the enterprise and routed back to the destination MN. The PDSN does not switch this traffic.

In cases where traffic is destined for the PDSN from the MN, the packets are not routed to the VRF, but are processed at PDSN.

VRF attributes are synchronized to the standby unit only during session creation. Any changes in the VRF during PPP renegotiation are not synchronized to standby.

Other Considerations

VRF information on the PDSN is applied only when the call established is a SIP session.

In cases of Mobile-IP users and Proxy Mobile-IP users, this support is not needed since it can already handle over-lapping IP address.

Overlapping IP addresses in SIP are differentiated by its vaccess and the VRF interface configured. The VRF routing table has a vaccess entry that identifies the corresponding MN.

VRF support on the PDSN ensures there are separate routing tables per enterprise, and users accessing the enterprise/corporate network have a separate routing table. The packets originated from the user cannot be forwarded outside of this routing table ensuring there is no security risk.

Performance

Additional memory is needed to create the VRF routing table.

Scalability

This feature supports a maximum of 175,000 PDSN sessions.

The CPS might be impacted due to additional processing per session.

Configuring PDSN Session Redundancy

The following new commands have been introduced for PDSN Session Redundancy:

Enabling PDSN Session Redundancy

The active PDSN will be able to synchronize the session and flow related data to its standby peer provided the redundancy capability has been enabled. By default this capability is disabled.

The commands syntax is as follows:

[no] cdma pdsn redundancy

When the above CLI command is configured, session redundancy is enabled provided the underlying redundancy infrastructure has been configured. The redundancy functionality for PDSN is disabled when the above command with