Cisco IOS Profiled Release 12.3(7)XI3 Testing for
Service Provider Broadband (DSL) Customers
Version History
Version Number
Date
Notes
1
March 31, 2005
This document was created.
Executive Summary
This document describes the service provider broadband (DSL) testing topology, its test plans, and a
summary of the test results, including relevant DDTS numbers, for the second phase of nEverest testing.
This document contains the following main sections:
•
About Service Provider Broadband (DSL) Testing, page 3
•
Test Results Summary, page 10
•
ATM Layer Feature Testing, page 12
•
QoS Policy Testing, page 24
•
Per-User ACL Feature Testing, page 29
•
Routing Feature Testing, page 31
•
RADIUS and L2TP Feature Testing, page 35
•
Network Management and Access Control Feature Testing, page 43
•
Access Protocols Feature Testing, page 51
•
SSG Feature Testing, page 55
•
Multicast Feature Testing, page 57
•
Performance and Scalability Testing, page 60
•
Reliability Testing, page 63
•
Negative Testing, page 64
•
Provisioning and Manageability Testing, page 71
•
Supplementary Information, page 72
•
Glossary, page 74
Corporate Headquarters:
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
Copyright © 2005 Cisco Systems, Inc. All rights reserved.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
The nEverest program is a quality initiative that focuses on satisfying customer requirements by
coordinating Cisco IOS release system-level and reliability testing under “real world” conditions. The
nEverest testing uses the following five profiles, the designs of which are based solely on customer
requirements:
•
Enterprise Global
•
Enterprise Financial
•
Service Provider/IP backbone
•
Service Provider/Multiprotocol Label Switching (MPLS) backbone
•
Broadband
The primary goal of the nEverest broadband profile project is to “harden” specific releases of the
Cisco IOS software for each of Cisco’s broadband aggregation (BBA) platforms, limited to DSL
aggregation and the Cisco 10000 platform for this test phase. A Cisco IOS software release is considered
hardened once it has been subjected to the testing defined in the Project nEverest Broadband (DSL)
Profile Detailed Test Plan and meets the exit criteria defined for this project.
Broadband addresses the needs of those service provider customers using DSL technologies for BBA.
The BBA testing program was designed to verify the key functionality required to build and sustain the
BBA portion of a network. To achieve this goal, system testing was conducted based on requirements
gathered from customers and Cisco’s internal customer account teams that are engaged in this program.
The following tests were performed:
•
Functional—Compact testing to cover as much functionality as possible. Testing focused on
underlying BBA features and in flushing out as many simple defects as possible.
•
Performance and scalability—Scenarios defined as realistically as possible to evaluate system
capacity.
•
Reliability—Testing of a longer duration performed toward the end of the test cycle using a realistic
configuration to evaluate the stability of the system over time.
•
Negative testing—Operations meant to examine system operation when invalid operations occur
(for example, incorrect command line inputs, invalid data input, and traffic overloads).
•
Availability and redundancy—Testing focused on the system operation under failure conditions such
as link failure and hardware failure.
•
Serviceability—Test operations used to study system operation in the presence of normal network
monitoring and maintenance procedures—Simple Network Management (SNMP) queries,
configuration changes, and software upgrades are examples of such procedures.
This document provides a summary of the system-level and reliability testing completed atop the service
provider broadband (DSL) profile for Cisco IOS Release 12.3(7)XI3.
Note
The software versions listed in this document were tested using the procedures described. All relevant
unresolved defects found during testing are listed in the “Test Results Summary” section on page 10. In
addition to the information contained in this report, we highly recommend that you review the Release
Notes for each release to see the latest list of open defects for specific features not tested or defects found
after publication.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
2
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
About Service Provider Broadband (DSL) Testing
About Service Provider Broadband (DSL) Testing
This section provides an overview of the service provider broadband (DSL) testing environment, and
includes the following information:
•
Service Provider Broadband (DSL) Test Configurations, page 3
•
Service Provider Broadband (DSL) Test Equipment and Tools, page 5
•
Service Provider Broadband (DSL) Test Hardware and Software, page 7
•
Service Provider Broadband (DSL) Test Matrixes, page 7
Service Provider Broadband (DSL) Test Configurations
Three high-level test configurations were identified for the first broadband test:
•
PPP termination aggregation (PTA)
•
L2TP access concentrator/PTA (LAC/PTA)
•
LAC with multihop L2TP network server (LNS)
During testing, variations within these configurations were introduced to test different combinations of
broadband DSL features. However, from a logical point of view, Figure 1, Figure 2, and Figure 3 capture
the test architectures that were used.
Figure 1
LAC/LNS Configuration Using Agilent Tester
DSL router DSLAM
800
6015
DS-3
ATM
OC-12
OC12
ATM
OC-12
OC12
GE
UUT
LAC
10000
GE
Policy
router
POS
OC-12
Agilent
SNMP
ATM core
MSR 8540
Client stack
2xCisco 10000
Client PC
PPPoEoE
FE
LNS
7200
10000
FE
RADIUS
ATM
OC-12
OC12
IP core
POS
POS
OC-12
Agilent
GSR
FE
FE
FE
SNMP RADIUS SSD
DHCP
LNE
7200
121844
Client PC
NTP
UNIX
IPTV
server broadcaster
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
3
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
About Service Provider Broadband (DSL) Testing
Figure 2
PTA Configuration Using Agilent Tester
Client PC
DSL router DSLAM
800
6015
DS-3
ATM
OC-12
OC12
ATM
OC12
OC-12
GE
UUT
LAC
10000
GE
Policy
router
POS
OC-12
Agilent
ATM core
MSR 8540
Client stack
2xCisco 10000
Client PC
PPPoEoE
FE
ATM
OC-12
IP core
POS
POS
OC-12
Agilent
GSR
FE
FE
SNMP RADIUS SSD
DHCP
LNE
7200
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
4
121845
FE
NTP
UNIX
IPTV
server broadcaster
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
About Service Provider Broadband (DSL) Testing
Figure 3
L2TP Multihop Test Bed
Client PC
DSL router DSLAM
800
6015
DS-3
POS
OC-12
Agilent
ATM core
MSR 8540
ATM
OC-12
OC12
ATM
OC-12
OC12
GE
UUT
LAC
10000
GE
Policy
router
UUT
Multihop LNS
10000
LNS
10000
FE
RADIUS
ATM
OC-12
OC12
IP core
Client stack
2xCisco 10000
Client PC
PPPoEoE
POS
FE
SNMP
POS
OC-12
Agilent
GSR
FE
FE
SNMP RADIUS SSD
LNE
7200
DHCP
121843
FE
NTP
UNIX
IPTV
server broadcaster
Service Provider Broadband (DSL) Test Equipment and Tools
The equipment that was used during testing is listed in Table 1. The number of units available and
function of each piece of test equipment are also provided.
Table 1
Number
of Units
List of Service Provider Broadband (DSL) Test Equipment
Item
Interfaces
Version
1
2
3
Function
2
Adtech
ATM/POS OC -3/OC-12 x6, GE x7 4.60
PPPoX4 call and packet
generator
3
Agilent
ATM OC-3 x2, ATM OC-12 x2
Packet generator
5.1
1. Packet over SONET
2. Optical carrier
3. Gigabit Ethernet
4. PPPoA or PPPoE
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
5
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
About Service Provider Broadband (DSL) Testing
Traffic Generation
Traffic generation was achieved using two third-party solutions; one from Agilent Technologies and one
from Spirent Systems called Adtech. The Agilent solution consisted of the Router Tester modular
hardware configuration. Multiple POS/ATM OC-3/OC-12 2 ports modules were used. The Adtech
solution consisted of the AX/4000 mainframe chassis equipped with MAX-IP 1G ENET GBIC 1310
POWERBUNDLE CE and 2 PORT MAX-IP OC-3/OC-12 SM POWERBUNDLE CE modules. Both
solutions provided a GUI for easy creation, control, and status of the thousands of traffic streams needed
to have a realistic BBA test environment. In addition to the GUI, the traffic generation tools also
provided a Tool Control Language (TCL) scripting interface that allowed internal automation tools to
easily create thousands of traffic streams with variations in packet length, IP, User Datagram Protocol
(UDP), and TCP header fields, and load. See Table 6 for a breakdown of traffic profiles used in the tests.
Route Generation
The two solutions from Agilent Technologies and Adtech also provided emulation of various internal
and external routing protocols. They can both emulate a peer-neighbor relationship for the various
routing protocols, and create appropriate traffic streams behind the advertised routes from these
emulated peer neighbors.
The Large Network Emulation (LNE) engine running under Pagent was also used to simulate routes and
test the ability of the network to remain stable, even during times of radical topology changes or route
flapping.
These route generation test tools helped to simulate a realistic IP and VPNv4 routing table and
appropriately sized IGP routing table.
PPPoX Emulation
The emulation of PPPoX sessions was achieved using Cisco 10000 series routers configured as clients
as illustrated in Figure 1, Figure 2, and Figure 3, and the Adtech. Both solutions provided the scalability
required to establish the thousands of PPPoX sessions required to simulate a realistic BBA environment.
The Adtech also facilitated the generation of traffic required on the thousands of sessions.
Automation Tools
Internally developed automation tools were used to configure and monitor various aspects of the BBA
architectures described in the “Service Provider Broadband (DSL) Test Configurations” section. The
configuration tools create and apply large-scale configurations to Cisco routers and create traffic for
traffic generation tools. The monitoring tools poll routers and test tools and continuously monitor the
health of the network.
Monitoring Tools
The monitoring tools used by service providers vary depending upon the size and complexity of the items
monitored, and the available resources that can use these tools. The same concept and limitations applied
to this test plan. The primary tools for monitoring were the use of Cisco IOS show EXEC commands,
along with the collection of SNMP and MIB variables using the HP OpenView application. The use of
automation scripts that polled the devices under test, along with the use of the Solaris 2.x system
message logging (syslog server, also assisted in the first stages of network monitoring and
troubleshooting.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
6
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
About Service Provider Broadband (DSL) Testing
Service Provider Broadband (DSL) Test Hardware and Software
Table 2 lists the Cisco routers, processors, interfaces, and system images that made up the test network.
For each hardware and software combination, the function within the test network is also provided. The
items identified as BBA devices represent the platforms and software that were the focus of this test
project.
Table 2
Test Network Hardware and Software
Number Cisco Routers and Processor
of units Hardware
Configuration
Interfaces
Cisco Software
Image
Function
4
Cisco 10000
Redundant
PRE-2
ATM OC-3, POS
12.3(7)XI3
OC-3, ATM OC-12,
POS OC-12, GE
BBA
4
Cisco 6500
—
FE, GE
Ethernet
core
2
Cisco 8540
—
ATM OC-12, OC-3, 12.1(10)E4
T3
ATM core
6
Cisco 12000
—
POS OC-12, OC-3,
GE, ATM OC-12
12.0(23)S
IP-MPLS/
VPN core
2
Sun workstation
Ultra 60
FE
SunOS 5.8
AR
RADIUS
Server
5
Sun workstation
Sparc 5/10
FE
SunOS 5.8
AR
RADIUS
Server
1
Compaq
Alpha
6 FE
Linux
FreeRADIUS
RADIUS
server
6.3(5)
Service Provider Broadband (DSL) Test Matrixes
As Figure 1, Figure 2, and Figure 3 show, numerous platforms can perform the various functions and
roles such as LAC, LNS, and PTA within the BBA architecture. There are also several access protocols
that can be used on both the service provider and client sides of the architecture. Given the number of
platforms and access protocols available, many combinations could be used in the tests. Table 3 and
Table 4 provide a matrix to the combinations of platforms and protocols that were tested. Table 5 lists
the features that were tested, and Table 5 lists the traffic mixes used.
Each combination used in testing was assigned a unique identifier for reference. To minimize repetition
in the document, the following tables and the identifiers in the matrixes are referenced throughout the
test descriptions.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
7
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
About Service Provider Broadband (DSL) Testing
Platform Configurations (Roles) Matrix
Table 3
Platform Roles Matrix—Roles R 1 Through R 9
Cisco 7200
(NPE-G1)
Cisco 10000
(PRE-2)
No LNS
LNS with load PTA Cisco
balancing
10000 PRE-2
PTA
Cisco 10000
PRE-2
—
—
R1
—
—
LAC
Cisco 10000
PRE-2
R2
R3
—
R7
—
PTA/LAC
Cisco 10000
PRE-2
R4
R5
—
—
—
PTA/PE
Cisco 10000
PRE-2
—
—
R8
—
—
Multihop
Cisco 10000
PRE-2
—
R9
—
—
R6
Access Protocols Combinations Matrix
In Table 4, for each access protocol combination (A1 and A2), an “X” in the column indicates that the
corresponding protocol was included in the combination.
Table 4
Access Protocol Combinations Matrix—A1 and A2
A1
A2
PPPoEoA
X
X
PPPoA
X
X
OC-3
X
—
OC-12
—
X
X
X
PTA/LAC protocols toward subscriber
PTA/LAC interfaces toward subscriber
PTA/LAC interfaces toward service provider
Gigabit Ethernet
Feature Profiles Matrix
Table 5 lists feature combinations (FP 1 through FP8) that were selected and merged into, or that
replaced parts of, a default template that was applied for each test. The “X” indicates that a feature
profile contains the feature listed in the first column. The default template represented settings and
features that customers in a broadband environment typically enable, such as authentication,
authorization, and accounting (AAA) accounting, SNMP, or routing.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
8
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
About Service Provider Broadband (DSL) Testing
A feature can be configured in numerous ways. The default template (listed in the “Default Template”
section on page 72) used the most common way. Separate test cases considered all of the configuration
variations.
Table 5
Feature Profiles Matrix—FP 1 Through FP 8
FP 1
FP 2
FP 3
FP 4
FP 5
FP 6
FP 7
FP 8
Multipoint
X
X
X
X
X
X
—
X
ATM PVC
Range feature
X
—
—
X
X
X
—
—
Autosense of
encapsulation
—
X
X
X
X
—
—
X
ATM PXF
queueing
—
X
X
X
X
—
X
X
VC shaping
—
VBR-nrt1 VBR-nrt VBR-nrt VBR-nrt UBR
VBR-nrt VBR-nrt
X
X
X
X
—
X
X
Hierarchical
shaping
Create
on-demand
—
X
—
X
X
X
—
X
Access control
list (ACL)
—
—
X
—
—
X
X
X
BBA group
—
—
X
—
—
—
—
—
Unicast Reverse —
Path
Forwarding
(URPF)
X
X
X
—
X
—
X
DBS
—
—
—
X
X
—
—
X
QoS
—
—
X
X
X
—
—
X
MPLS-PE
—
—
—
—
X
—
—
—
SSG
—
—
—
—
—
—
X
—
Half-duplex
VRF
—
—
—
—
—
—
—
X
1. Variable bit rate nonreal-time ATM service category
Traffic Profiles Matrix
Table 6 lists the characteristics of the traffic that was used throughout testing. In some test cases, such
as the performance tests, variations to this base traffic model may have been introduced. In those cases,
the modifications to the information captured in Table 6 are specifically called out in the test case
description.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
9
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
Test Results Summary
Table 6
Traffic Profiles Matrix—TP 1 Through TP 3
TP 1
Stream 1
Stream 2
Stream 3
Stream 4
TP 2
TP 3
Upstream
Downstream
Upstream
Downstream
Upstream
Downstream
Packet size
40
40
40
40
40
40
Distribution
7
7
7
7
11
4
Packet size
572
572
572
572
576
576
Distribution
4
4
4
4
1
1
Packet size
1500
1500
1400
1400
1500
1450
Distribution
1
1
1
1
3
3
Packet size
—
—
—
—
—
1500
Distribution
—
—
—
—
—
2
4 kbps
25 kbps
4 kbps
25 kbps
4 kbps
25 kbps
Session traffic rate
Test Results Summary
Table 7 provides a quick link to test results. In electronic versions of this document, click on the test in
the Test Cases column to go to a description of the test. Click on a table number in the Results column
to see a summary of the test results. In paper versions of this document, turn to the page number indicated
in the Test Cases column to see test descriptions and results.
Table 7
Service Provider Broadband (DSL) Test Summary
Test Cases
Results
ATM Layer Feature Testing, page 12
Range PVC Provisioning and Maximum Number of VCs, page 12
See Table 8
Range and Create On-Demand PVC Provisioning and Maximum Number of
VPs and VCs, page 14
See Table 9
Infinite Range PVC and Create On-Demand PVC Provisioning and Maximum See Table 10
Number of VPs and VCs, page 16
ATM VC Shaping Accuracy, page 17
See Table 11
ATM VC Shaping Accuracy and Maximum Active VCs, page 18
See Table 12
ATM VP Shaping Accuracy, page 19
See Table 13
ATM VP Shaping Accuracy and Maximum Active VPs, page 20
See Table 14
ATM VP and VC Shaping on the Same Interface, page 22
See Table 15
Weighting of VC into a VP, page 23
See Table 16
QoS Policy Testing, page 24
QoS Policer, page 24
See Table 17
QoS Maximum Number of Applied Queueing Policy, page 26
See Table 18
QoS Input and Output Policing, page 27
See Table 19
QoS Output Queueing, page 28
See Table 20
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
10
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
Test Results Summary
Table 7
Service Provider Broadband (DSL) Test Summary (Continued)
Test Cases
Results
Per-User ACL Feature Testing, page 29
Per-User ACL Functionality, page 29
See Table 21
Routing Feature Testing, page 31
Subscriber IP Address Assignment (PTA), page 31
See Table 22
Pool Depletion, page 32
See Table 23
AAA Route Download, page 33
See Table 24
Half-Duplex VRF, page 33
See Table 25
RADIUS and L2TP Feature Testing, page 35
RADIUS Authentication, page 35
See Table 26
RADIUS Authorization, page 36
See Table 27
RADIUS Accounting, page 37
See Table 28
L2TP-VPDN Load Sharing Group (LSG), page 39
See Table 29
L2TP Accounting, page 41
See Table 30
L2TP Multihop, page 42
See Table 31
Network Management and Access Control Feature Testing, page 43
SNMP, page 43
See Table 32
AAA TACACS+, page 44
See Table 33
NetFlow, page 46
See Table 34
Syslog, page 47
See Table 35
AAA Session MIB, page 48
See Table 36
PPPoE Session MIB, page 49
See Table 37
Packet of Disconnect, page 50
See Table 38
Access Protocols Feature Testing, page 51
Autosense, page 51
See Table 39
PPP Idle Timeout, page 53
See Table 40
PPPoEoA per-VC or per-MAC Session Limit, page 54
See Table 41
SSG Feature Testing, page 55
SSG Passthrough with Auto Logon, page 55
See Table 42
Multicast Feature Testing, page 57
Multicast over GRE Tunnel, page 58
See Table 43
Multicast over IP, page 59
See Table 44
Performance and Scalability Testing, page 60
See Table 45 and
Table 46
Reliability Testing, page 63
See Table 47
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
11
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
ATM Layer Feature Testing
Table 7
Service Provider Broadband (DSL) Test Summary (Continued)
Test Cases
Results
Negative Testing, page 64
Boot Time, page 64
See Table 48
PRE Failover, page 65
See Table 49
Line Card OIR, page 66
See Table 50
ATM Link Failures, page 67
See Table 51
RADIUS Server Failures, page 68
See Table 52
L2TP Tunnel Failures, page 69
See Table 53
Route Flapping, page 69
See Table 54
Storm of PPPoX Sessions, page 70
See Table 55
Provisioning and Manageability Testing, page 71
See Table 56
ATM Layer Feature Testing
This section describes the ATM layer testing, which tested the main ATM capabilities required for BBA
architectures. The ATM layer testing covered two main ATM areas: virtual path identifier/virtual channel
identifier (VPI/VCI) resource allocation and traffic management.
The ATM layer testing was independent of the LAC, PTA, LAC/PTA, PTA/Provider Edge (PE)
architectures, and of the PPPoA and PPPoEoA access protocols defined in Table 4. The ATM
deployment models are identical for any of the architectures illustrated in Figure 1, Figure 2, and
Figure 3.
Table 7 lists all tests; click a highlighted test name or table number to go to results of that test.
Range PVC Provisioning and Maximum Number of VCs
This test verified the virtual circuit (VC) scaling numbers against the range provisioning command. This
test included checks against the maximum number of VCs per ATM module and per system.
Table 8 lists the platform configurations, access protocol combinations, feature and traffic profiles used,
and test results. The following test procedure was executed for each unique combination listed in the
table.
Test Procedure
The following steps were performed:
Step 1
Brought up the maximum number of active VCs per ATM module on one single port using the lowest
supported VPI value (configured with the range pvc command).
Step 2
Established one PPPoA or one PPPoEoA session on each VC.
Step 3
Ensured that all sessions were up before starting the traffic.
Step 4
Generated upstream and downstream traffic on all active sessions.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
12
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
ATM Layer Feature Testing
Neither the VCs nor the interface were to have been overloaded. The aggregate ATM rate should not have
exceeded 75 percent of the total available bandwidth in the downstream direction (75 percent of
149,760 kbps for OC-3, and 75 percent of 599,040 kbps for OC-12).
Step 5
Verified that no packet was dropped.
Step 6
Repeated Steps 1 through 5 after toggling the Parallel Express Forwarding (PXF) queueing mode (when
applicable).
Step 7
Repeated Steps 1 through 5 using the highest supported VPI and VCI values (configured with the range
pvc command).
Step 8
Repeated Steps 1 through 5 using all available ports on the ATM module (if more than one).
Step 9
Established one PPPoA or one PPPoEoA session on each VC.
Step 10
Ensured that all sessions were up before starting the traffic.
Step 11
Verified that no packet was dropped.
The following negative checks were also performed in a configuration with the maximum number of VCs
provisioned among all available ports on the ATM module (if more than one port):
•
Verified the proper handling of VC shutdown and restoral (configured using the pvc-in-range
command) and that the shutdown did not cause any traffic interruption on the other VCs.
•
Verified the proper handling of VC class and rate changes (configured using the pvc-in-range
command) and that the changes did not cause any traffic interruption on the other VCs. Changes
should be done on active sessions as well.
•
Verified the proper handling of VC range additions and deletions, and that the additions and
deletions did not cause any traffic interruption on the other VCs.
•
Verified the proper handling of subinterface and VC range addition/deletion and that it does not
cause any traffic interruption on the other VCs.
•
Verified the proper handling of an ATM port and any module VC over provisioning configuration
errors using EXEC commands and Trivial File Transfer Protocol (TFTP).
•
Verified the proper handling of a system VC over provisioning configuration errors using EXEC
commands and TFTP.
Expected Results
The ATM modules and system should scale up to the maximum number of supported VCs with one
PPPoA or PPPoEoA session established on all of them. No packet should be dropped when bidirectional
traffic is generated on these sessions when neither the VCs nor the ATM interfaces are overloaded.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
13
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
ATM Layer Feature Testing
Results
Table 8 shows the range permanent virtual circuit (PVC) provisioning and maximum number of VCs test
results. Click a highlighted test identifier in the following table, or see Table 3, Table 4, Table 5, and
Table 6 to interpret the identifiers.
Table 8
Range PVC Provisioning and Maximum Number of VCs Test Configurations and
Results
Platform
Configuration
Access
Protocol
Combinations
Feature
Profile
Traffic
Profiles
Result/Reason
R1
A1
FP 1
TP 1
Passed
R1
A2
FP 1
TP 1
Passed
Range and Create On-Demand PVC Provisioning and Maximum Number of VPs
and VCs
This test verified the virtual path (VP) and VC scaling numbers against the create on-demand and range
provisioning configuration commands. This test included checks against the maximum number of VPs
and VCs per ATM module.
Table 9 lists the platform configurations, access protocol combinations, feature and traffic profiles used,
and test results. The following test procedure was executed for each unique combination listed in the
table.
Test Procedure
The following steps were performed:
Step 1
Brought up the maximum number of VPs and VCs per ATM module on one single port (configured with
the range pvc and create on-demand commands). This configuration implied use of hierarchical traffic
shaping and PXF queueing modes.
Step 2
Established one PPPoA or one PPPoEoA session on each VC.
Step 3
Ensured that all sessions were up before starting the traffic.
Step 4
Generated upstream and downstream traffic on all active sessions.
Neither the VCs nor the interface were to have been overloaded. The aggregate ATM rate was not have
exceeded 75 percent of the total available bandwidth in the downstream direction (75 percent of 149,760
kbps for OC-3, and 75 percent of 599,040 kbps for OC-12).
Step 5
Verified that no packet was dropped.
Step 6
Repeated Steps 1 through 5 using all available ports on the ATM module (if more than one).
Step 7
Verified that VC rate changes could dynamically be modified using the Dynamic Bandwidth Selection
(DBS) feature.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
14
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
ATM Layer Feature Testing
The following negative checks were also performed in a configuration with the maximum number of VCs
provisioned among all available ports on the ATM module (if more than one port):
•
Verified the proper handling of dynamic VC removal and restoral (configured using the create
on-demand idle-timeout command) and that the handling did not cause any traffic interruption on
the other VCs.
•
Verified the proper handling of VC class and rate changes (configured using the pvc-in-range
command) and that the rate changes did not cause any traffic interruption on the other VCs. Changes
should have been done on active sessions as well.
•
Verified the proper handling of DBS enabling and disabling configuration change for a VC and
range of VCs, and that enabling and disabling did not cause any traffic interruption on the other VCs.
•
Verified the proper handling of VC range addition and deletion, and that adds and deletes did not
cause any traffic interruption on the other VCs.
•
Verified the proper handling of VP, subinterface, and PVC range additions and deletions, and that
additions and deletions did not cause any traffic interruption on the other VCs.
•
Verified the proper handling of an ATM port and module VP and VC over provisioning configuration
errors using EXEC commands and TFTP.
Expected Results
The ATM modules should scale up to the maximum number of supported VPs and VCs with one PPPoA
or PPPoEoA session established on all VCs. No packet should be dropped when bidirectional traffic is
generated lon these sessions without overloading the VPs, VCs, or ATM interfaces.
Results
Table 9 shows the range and create on-demand PVC provisioning and maximum number of VPs and VCs
test results. Click a highlighted test identifier in the following table, or see Table 3, Table 4, Table 5, and
Table 6 to interpret the identifiers.
Table 9
Range and Create On-Demand PVC Provisioning and Maximum Number of VPs and
VCs Test Configurations and Results
Platform
Configuration
Access Protocol
Combinations
Feature Profile
Traffic Profiles Result/Reason
R1
A1
FP 2
TP 1
Passed with exception
(CSCed84932, CSCsa45029)
R1
A2
FP 2
TP 1
Passed with exception
(CSCed84932, CSCsa45029)
Passed with Exception Explanations
CSCed84932—The maximum number of ATM PVP connections set to 127 is not checked consistently
across all possible configuration scenarios.
CSCsa45029—The virtual-access interface shows the configured bandwidth of the VC, and not the
actual bandwidth set by DBS.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
15
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
ATM Layer Feature Testing
Infinite Range PVC and Create On-Demand PVC Provisioning and Maximum
Number of VPs and VCs
This test verified VP and VC scaling numbers against the create on-demand and infinite VC range
provisioning methods. This test included checks against the maximum number of VPs and VCs per ATM
module.
Table 10 lists the platform configurations, access protocol combinations, feature and traffic profiles
used, and test results. The following test procedure was executed for each unique combination listed in
the table.
Test Procedure
The following steps were performed:
Step 1
Configured the maximum number of VPs per ATM module across all available ports. The test
configuration implied the use of hierarchical traffic shaping and PXF queueing modes.
Step 2
Brought up the maximum number of active VCs supported by the ATM module using the local
autoprovisioning on an ATM interface using the create on-demand and class-int configuration option.
Step 3
Established one PPPoA or one PPPoEoA session on each VC.
Step 4
Ensured that all sessions were up before starting the traffic.
Step 5
Generated upstream and downstream traffic on all active sessions. Neither the VCs nor the interface were
to have been overloaded. The aggregate ATM rate was not to have exceed 75 percent of the total available
bandwidth in the downstream direction (75 percent of 149,760 kbps for OC-3, and 75 percent of
599,040 kbps for OC-12).
Step 6
Verified that no packet was dropped.
Step 7
Brought up the maximum number of VCs that the system (for example, the Performance Routing
Engine 2 or PRE-2) could support.
Step 8
Established one PPPoA or one PPPoEoA session on each VC.
Step 9
Ensured that all sessions were up before starting the traffic.
Step 10
Generated upstream and downstream traffic on all active sessions. Neither the VCs nor the interfaces
should have been overloaded.
Step 11
Verified that no packet was dropped.
The following negative checks were also performed:
•
Verified the proper handling of the dynamic VC creation operation beyond the port and module
scalability limits and that creating the VC did not cause any traffic interruption on the other VCs.
•
Verified the proper handling of the dynamic VC creation operation beyond the system scalability
limit.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
16
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
ATM Layer Feature Testing
Expected Results
The ATM modules scale up to the maximum number of supported VPs and VCs with one PPPoA or
PPPoEoA session established on all VCs. No packet is dropped when bidirectional traffic is generated
on these sessions without overloading the VPs, VCs, or ATM interfaces.
Results
Table 10 shows the infinite range PVC and create on-demand PVC provisioning and maximum number
of VPs and VCs test results. Click a highlighted test identifier in the following table, or see Table 3,
Table 4, Table 5, and Table 6 to interpret the identifiers.
Table 10
Infinite Range PVC and Create On-Demand PVC Provisioning and Maximum Number
of VPs and VCs Test Configurations and Results
Access
Platform
Protocol
Configuration Combinations
Traffic
Feature Profile Profiles
Result/Reason
R1
A1
FP 4
TP 1
Passed
R1
A2
FP 4
TP 1
Passed
ATM VC Shaping Accuracy
This test verified the accuracy of the ATM VC traffic shaping scheduler.
Table 11 lists the platform configurations, access protocol combinations, feature and traffic profiles
used, and test results. The following test procedure was executed for each unique combination listed in
the table.
Test Procedure
The following steps were performed:
Step 1
Configured ten VCs on one port of the ATM module (the default PXF queueing mode was used). The
service category was set as VBR-nrt with the same peak cell rate (PCR) and sustainable cell rate (SCR)
values. The selected kbps rates for these 10 VCs were 160, 256, 448, 512, 640, 864, 1280, 1780, 2304,
and 2560, respectively. Service category and rate values were set using the VC class or at the PVC level.
Step 2
Configured usage parameter control on the ATM switch to determine whether the traffic being sent by
the router on a VC adhered to the configured rates values. The per-UPC policies should have specified
the “tag the cells” action to take with cells deemed noncompliant.
Step 3
Established one PPPoA or one PPPoEoA session on each VC.
Step 4
Sent traffic through all sessions at just over the shaped rate. Ensured the unit under test could correctly
shape to all configured data rates by using the show atm vc EXEC command on each ATM switch VC,
to display the counters of compliant and noncompliant cells.
Step 5
Repeated Steps 1 through 4 with the unspecified bit rate (UBR) service category and with the PCR values
set equal to the rates given in Step 1.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
17
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
ATM Layer Feature Testing
The following negative checks were also performed:
•
Verified that the VC bandwidth boundaries are enforced to protect well-behaving VCs from being
impacted by an excess of load on other VCs.
•
Verified the proper handling of VC rate change using the DBS feature or using the command-line
interface (CLI). The ATM VC rate scheduling should accommodate the change dynamically without
tearing down the session.
Expected Results
ATM VC scheduling operation should be accurate and conform to at least the PCR and SCR rate settings.
Results
Table 11 shows the ATM VC shaping accuracy test results. Click a highlighted test identifier in the
following table, or see Table 3, Table 4, Table 5, and Table 6 to interpret the identifiers.
Table 11
ATM VC Shaping Accuracy Test Configurations and Results
Platform
Configuration
Access Protocol
Combinations
Feature Profile
Traffic Profiles
Result/Reason
R1
A1
FP 6
TP 1
Passed
R1
A2
FP 6
TP 1
Passed
ATM VC Shaping Accuracy and Maximum Active VCs
This test verified the performance of the ATM scheduler when the scheduler performed a shaping
operation for a large number of VCs (up to the maximum active VCs, when possible).
Table 12 lists the platform configurations, access protocol combinations, feature and traffic profiles
used, and test results. The following test procedure was executed for each unique combination listed in
the table.
Test Procedure
The following steps were performed:
Step 1
Configured the maximum number of VCs supported by the ATM module using all available ports. The
service category was set as VBR-nrt with the same PCR and SCR values. The selected rate for all VCs
was 256 kbps. Service category and rate values were set using either the VC class or at the PVC level.
Step 2
Configured usage parameter control on the ATM switch to determine whether the traffic being sent by
the router on a VC adhered to the configured rates values. The per-UPC policies should have specified
the “tag the cells” action to take with cells deemed noncompliant.
Step 3
Established one PPPoA or one PPPoEoA session on each VC.
Step 4
Sent traffic through the selected number of sessions at just below the shaped rate. The number of sessions
should be determined such that the aggregate ATM rate does not exceed 75 percent of the interface rate
bandwidth (for example, 149,760 * 75 percent / 256 = 439 VCs for an OC-3 interface and 599,040 * 75
percent / 256 = 1755 VCs for an OC-12 interface).
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
18
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
ATM Layer Feature Testing
Step 5
Verified that no packet is dropped by the unit under test. Ensured the unit under test can correctly shape
all VCs by using the show atm vc command on each ATM switch VC to display the counters of
compliant and noncompliant cells. Ensured the unit under test could correctly shape all VCs using the
show atm vc EXEC command on each ATM switch VC, to display the counters of compliant and
noncompliant cells. This test also recorded the aggregate rate.
Step 6
Sent traffic through the selected number of sessions at just over the shaped rate (overloading ratio was
1:2).
Step 7
Ensured the unit under test can correctly shape all overloaded VCs by using the show atm vc EXEC
command on each ATM switch VC to display the counters of compliant and noncompliant cells. This
test also recorded the aggregate rate, which should have been at least equal to the rate recorded in Step 5.
Step 8
Repeated Steps 1 through 7 with the UBR service category PCR value set to 256.
Expected Results
The ATM shaper should remain accurate as the number of VCs increases, up to the maximum number
of active VCs configured on the ATM interface.
Results
Table 12 shows ATM VC shaping accuracy and maximum active VCs test results. Click a highlighted
test identifier in the following table, or see Table 3, Table 4, Table 5, and Table 6 to interpret the
identifiers.
Table 12
ATM VC Shaping Accuracy and Maximum Active VCs Test Configurations and Results
Platform
Configuration
Access Protocol
Combinations
Feature Profile
Traffic Profiles
Result/Reason
R1
A1
FP 6
TP 1
Passed
R1
A2
FP 6
TP 1
Passed
ATM VP Shaping Accuracy
This test verified the accuracy of the ATM VP traffic shaping scheduler when hierarchical traffic shaping
was used.
Table 13 lists the platform configurations, access protocol combinations, feature and traffic profiles
used, and test results. The following test procedure was executed for each unique combination listed in
the table.
Test Procedure
The following steps were performed:
Step 1
Configured five VPs with a PCR value of 4 , 8, 12, 20, and 24 Mbps, respectively, and CDVT values of
220, 214, 208, 196, and 190 microseconds, respectively. The test configuration implied the use of
hierarchical traffic shaping and PXF queueing mode.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
19
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
ATM Layer Feature Testing
Step 2
Configured VCs mapped to VPs. The VPs should have been overbooked by a factor of 10, up to a
maximum of 50.
Step 3
Configured usage parameter control (UPC) on the ATM switch to determine whether the traffic being
sent by the router on a VP adhered to the configured rates values. The per-UPC policies should have
specified the CBR service category and the “tag the cells” action to take with cells deemed
noncompliant. The UPC values configured on the switch should also have been included the CDVT
parameter. Note that the CDVT value is configured in OC-3 cell times on the switch. The UPC CDVT
values on the switch corresponding to those defined in Step 1 should therefore be 80, 78, 76, 72, and 69,
respectively.
Step 4
Established one PPPoA or one PPPoEoA session on each VC.
Step 5
Sent traffic through all sessions to overload the VP rates. Ensured that the unit under test could correctly
shape to all configured VP rates by using the show atm vp EXEC command on each ATM switch VP, to
display the counters of compliant and noncompliant cells.
The following negative checks were also performed:
•
Verified that the VC bandwidth boundaries were enforced within a VP to protect well-behaving VCs
from being impacted by an excess of load on other VCs.
•
Verified the proper handling of VP rate change. VCs within the VP might be impacted (see DDTS
report CSCed40208), but VCs mapped to other VPs should not be affected.
Expected Results
The ATM VP scheduling operation is accurate.
Results
Table 13 shows ATM VP shaping accuracy test results. Click a highlighted test identifier in the following
table, or see Table 3, Table 4, Table 5, and Table 6 to interpret the identifiers.
Table 13
ATM VP Shaping Accuracy Test Configurations and Results
Platform
Configuration
Access Protocol
Combinations
Feature Profile
Traffic Profiles
Result/Reason
R1
A1
FP 2
TP 1
Passed
R1
A2
FP 2
TP 1
Passed
ATM VP Shaping Accuracy and Maximum Active VPs
This test verified the scalability of the ATM scheduler when the scheduler shaped a large number of VPs,
and when hierarchical traffic shaping is used.
Table 14 lists the platform configurations, access protocol combinations, feature and traffic profiles
used, and test results. The following test procedure was executed for each unique combination listed in
the table.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
20
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
ATM Layer Feature Testing
Test Procedure
The following steps were performed:
Step 1
Configured the maximum number of active VPs per ATM module across all available ports. The PCR
and cell delay variation tolerance (CDVT) values were set to 4 Mbps and 220 microseconds for all VPs.
The test configuration implied the use of hierarchical traffic shaping and PXF queueing mode. Note that
the ATM interface should not have been oversubscribed by the sum of the VP bandwidths.
Step 2
Configured VCs mapping to the VPs. The VPs should have been overbooked by a factor of 10, up to a
maximum of 50.
Step 3
Configured usage parameter control (UPC) on the ATM switch to determine whether the traffic being
sent by the router on a VP adhered to the configured rates values. The per-UPC policies should have
specified CBR service category and the “tag the cells” action to take with cells were deemed
noncompliant. The Usage-Parameter-Control (UPC) values configured on the switch should also have
included the CDVT parameter. Note that the CDVT value is configured in OC-3 cell times on the switch.
A CDVT value of 80 corresponds to the 220 microseconds specified in step 1.
Step 4
Established one PPPoA or one PPPoEoA session on each VC.
Step 5
Sent traffic through a selected number of VPs at just below the shaped rate. The number of VPs were
determined such that the aggregate ATM rate did not exceed 75 percent of the interface rate bandwidth
(149,760 * 75 percent / 1000 = 112 VPs for OC-3, and 599,040 * 75 percent / 1000 = 450 VPs for
OC-12).
Step 6
Verified that no packet was dropped by the unit under test. Ensured the unit under test could correctly
shape the VPs by using the show atm vp EXEC command on each ATM switch VP to display the
counters of compliant and noncompliant cells. Also recorded the aggregate rate.
Step 7
Sent traffic through the selected number of VPs at just over the shaped rate (the overloading ratio was
1:2).
Step 8
Ensured the unit under test could correctly shape the overloaded VPs by using the show atm vp EXEC
command on each ATM switch VP to display the counters of compliant and noncompliant cells. Also
recorded the aggregate rate, which should have been at least equal to the one recorded in Step 6.
The following negative check was also performed:
•
Verified the proper handling of removing and adding VPs.
Expected Results
The ATM shaper remains accurate as the number of VPs increases, up to the maximum number of active
VPs configured on the ATM interface.
Results
Table 14 shows the ATM VP shaping accuracy and maximum active VPs test results. Click a highlighted
test identifier in the following table, or see Table 3, Table 4, Table 5, and Table 6 to interpret the
identifiers.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
21
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
ATM Layer Feature Testing
Table 14
ATM VP Shaping Accuracy and Maximum Active VPs Test Configurations and Results
Platform
Configuration
Access Protocol
Combinations
Feature Profile
Traffic Profiles
Result/Reason
R1
A1
FP 2
TP 1
Passed
R1
A2
FP 2
TP 1
Passed
ATM VP and VC Shaping on the Same Interface
This test verified that both VP and VC shaping operations could simultaneously be performed by the
ATM scheduler on the same interface.
Table 15 lists the platform configurations, access protocol combinations, feature and traffic profiles
used, and test results. The following test procedure was executed for each unique combination listed in
the table.
Test Procedure
The following steps were performed:
Step 1
Configured ATM VPs on one port of the ATM module. The PCR and CDVT values were set to 4 Mbps
and 242 microseconds for all VPs. The number of VPs should have been determined so that the sum of
the VP bandwidths was about half of the interface rate (149,760 / 2 / 4000 = 19 VPs for an OC-3 interface
and 599,040 / 2 / 4000 = 75 VPs for an OC-12 interface). The test configuration implied the use of
hierarchical traffic shaping and the PXF queueing mode.
Step 2
Configured VCs mapping to the VPs configured in Step 1. The VPs should be overbooked by a factor of
10 up to 50.
Step 3
Configured ATM VCs on the same ATM port with a different VPI value that those used in Step 2. The
service category is set as VBR-nrt with the same PCR and SCR values. The selected rate for all VCs is
1024 kbps. Service category and rate values can be set by a VC class or at the PVC level. The ATM
interface should not have been overbooked.
Step 4
Configured usage parameter control (UPC) on the ATM switch to determine whether the traffic being
sent by the router on the VPs configured in Step 1 and the VCs configured in Step 3 adhered to the
configured rates values. The per-UPC policies should have specified a CBR service category for the VPs
configured in Step 1, VBR-nrt for the VCs configured in Step 3, and the tagging action to take with cells
deemed noncompliant. The UPC values configured on the switch should alsohave included the CDVT
parameter. Note that the CDVT value is configured in OC3 cell times on the switch. A CDVT value of
88 corresponds to the 242 microseconds specified in Step 1, and a CDVT value of 166 (455
microseconds) was used for the VCs configured in Step 3.
Step 5
Established one PPPoA or one PPPoEoA session on each VC.
Step 6
Sent traffic through VPs defined in Step 1 at just over their shaped rate (overloading ratio was 1:2). Also
sent traffic through VCs defined in Step 3 at just over their shaped rate (overloading ratio was 1:2). The
number of VPs and VCs over which traffic was generated should have been determined such that the
aggregate ATM rate did not exceed 75 percent of the interface rate bandwidth (149,760 * 75 percent /
4000 = 28 VPs for an OC-3 interface, and 599,040 * 75 percent / 4000 = 112 VPs for an OC-12
interface).
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
22
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
ATM Layer Feature Testing
Step 7
Ensured the unit under test could correctly shape to all configured VP rates by using the show atm vp
EXEC command on each ATM switch VP to display the counters of compliant and noncompliant cells.
Performed the same check for the VCs defined in Step 3.
Expected Results
Simultaneous ATM VP and VC shaping on the same interface should be handled as expected.
Results
Table 15 shows the VC rate scheduling and VP shaping without hierarchical shaping test results. Click
a highlighted test identifier in the following table, or see Table 3, Table 4, Table 5, and Table 6 to
interpret the identifiers.
Table 15
ATM VP and VC Shaping on the Same Interface Test Configurations and Results
Platform
Configuration
Access Protocol
Combinations
Feature Profile
Traffic Profiles
Result/Reason
R1
A1
FP 4
TP 1
Passed
R1
A2
FP 4
TP 1
Passed
Weighting of VC into a VP
This test ensured that the VC bandwidth allocation into a VP could be controlled with the VC weighting
feature.
Table 16 lists the platform configurations, access protocol combinations, feature and traffic profiles
used, and test results. The following test procedure was executed for each unique combination listed in
the table.
Test Procedure
The following steps were performed:
Step 1
Configured a 4 Mbps VP on one port of the ATM module. The test configuration implied the use of
hierarchical traffic shaping and PXF queueing mode.
Step 2
Configured VCs with a default weight value mapping to the VPs. The VPs should have been overbooked
by a factor of 10, up to a maximum of 50 (for example, 256 kbps VCs and VP overbooking factor of 10
implies 156 VCs).
Step 3
Established one PPPoA or one PPPoEoA session on each VC.
Step 4
Sent traffic through all sessions such that the aggregate rate was just over the VP shaped rate
(overloading ratio was 1:2).
Step 5
Verified that the VP bandwidth was equally shared among all VCs (for example, 4000 / 156 = 26 kbps).
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
23
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
QoS Policy Testing
Step 6
Changed the weight of one or several VCs and verified that the bandwidth allocated to these VCs was
adjusted accordingly.
The following negative checks were also performed:
•
Verified the proper handling of VC weight change and that the change could be dynamically
adjusted without tearing down the session.
•
Verified that the weight of the VC dynamically adjusted to the bandwidth changes.
Expected Results
The bandwidth allocated to a VC into a VP is controllable with the configurable VC weight.
Results
Table 16 shows the weighting of VC into a VP test results. Click a highlighted test identifier in the
following table, or see Table 3, Table 4, Table 5, and Table 6 to interpret the identifiers.
Table 16
Weighting of VC into a VP Test Configurations and Results
Platform
Configuration
Access Protocol
Combinations
Feature Profile
Traffic Profiles
Result/Reason
R1
A1
FP 4
TP 1
Passed
R1
A2
FP 4
TP 1
Passed
QoS Policy Testing
This section describes the quality of service (QoS) policy tests, which were designed to test the QoS
capabilities used at the PTA aggregation level in any of the relevant BBA architectures described in the
“Service Provider Broadband (DSL) Test Configurations” section on page 3. The configuration used for
the tests described in the following sections included input and output QoS features applied at the VC
or virtual template level.
The QoS policing feature was first tested as an alternative to native ATM VC traffic shaping, to regulate
the amount of traffic forwarded per VC in the downstream direction. For these tests, a QoS service policy
with a single class map and the police action were configured. Tests were then performed with a QoS
configuration used with the Hierarchical Traffic Shaping (HTS) feature. The sum of the constituent VC
rates oversubscribing in this case was compared to the VP bandwidth. An input and output QoS service
policy was applied at the VC level.
The output policing configuration defined four classes (1PQ through 3DQs, including a class default).
All rate values were expressed in percentages rather than in absolute kbps values.
Table 7 lists all tests; click a highlighted test name or table number to go to results of that test.
QoS Policer
This test verified the accuracy and the scalability of the QoS policer when the policer performed output
rate limiting for a large number of users.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
24
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
QoS Policy Testing
Table 17 lists the platform configurations, access protocol combinations, feature and traffic profiles
used, and test results. The following test procedure was executed for each unique combination listed in
the table.
Test Procedure
The following steps were performed:
Step 1
Configured the maximum number of UBR VCs supported by the system (for example, 61.5 kbps for a
PRE-2 and no PXF queueing).
Step 2
Established one PPPoA or one PPPoEoA session on each VC. All sessions should have been brought up
with an output policy inherited from the virtual template. The output policy included a single class map
with the police action as defined in the “QoS Policy Testing” section on page 24. Multiple virtual
template interfaces were used with a different service policy and policer rate applied (for example, 256,
640, and 1280 kbps).
Step 3
Generated upstream and downstream traffic over a selected number of sessions at just below the policer
rate in the downstream direction. The number of sessions should have been determined such that the
aggregate ATM rate did not exceed 75 percent of the interface rate bandwidth.
Step 4
Verified that no packet was dropped by the unit under test.
Step 5
Generated upstream and downstream traffic over the selected number of sessions at just over the policer
rate in the downstream direction (overloading ratio was 1:2).
Step 6
Verified that the unit under test limit expected the amount of traffic forwarded in the downstream
direction by checking the received aggregate IP rate. Steps 3 through 6 were repeated for all configured
police rates and by selecting one rate at a time.
The following negative checks were also performed:
•
Verified the proper handling of VC shutdown and restore, and that these changes did not cause any
traffic interruption on the other VCs.
•
Verified the proper handling of VC class change (the configuration change should have been set to
a different virtual template and policer rate than the VC), and that these changes did not cause any
traffic interruption on the other VCs. Changes also should have been done on active sessions.
•
Verified the proper handling of a QoS service policy removal and addition on a virtual template
interface while sessions cloned from the virtual template were active.
•
Verified the proper handling of a QoS policy map change (the configuration change should have
been set to a different policer rate).
•
Verified the proper handling of Operation, Administration, and Maintenance (OAM) F5 loopback
cells received on VCs configured on the unit under test. The OAM flows should not have any impact
on the active sessions (no traffic interruption).
•
Verified the proper handling of OAM F5 Continuity Check (CC) cells received on VCs configured
on the unit under test. The OAM flows should not have any impact on the active sessions (no traffic
interruption).
•
Verified the proper handling of OAM F5 alarm indication signal (AIS) cells received on VCs
configured on the unit under test. The OAM flows should not have any impact on the active sessions
(no traffic interruption).
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
25
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
QoS Policy Testing
•
Verified the proper handling of OAM F4 AIS cells received on VCs configured on the unit under
test. The OAM flows should not have any impact on the active sessions (no traffic interruption).
•
Verified the proper handling of a shutdown and no shutdown operations on the main ATM interface.
Expected Results
Output rate limiting for a large number of users remained accurate and scalable.
Results
Table 17 shows the QoS policer test results. Click a highlighted test identifier in the following table, or
see Table 3, Table 4, Table 5, and Table 6 to interpret the identifiers.
Table 17
QoS Policer Test Configurations and Results
Platform
Configuration
Access Protocol
Combinations
Feature Profile
Traffic Profiles
Result/Reason
R1
A1
FP 3
TP 1
Passed
QoS Maximum Number of Applied Queueing Policy
This test verified the scalability of the system to handle the maximum number of applied queueing
policy.
Table 18 lists the platform configurations, access protocol combinations, feature and traffic profiles
used, and test results. The following test procedure was executed for each unique combination listed in
the table.
Test Procedure
The following steps were performed:
Step 1
Configured the maximum number of VCs applied queueing policies. The number of required ATM
modules depended upon the maximum number of VCs supported by each. All VCs should have been
configured with a rate of 1 Mbps and had the QoS policy applied. The configuration also required the
use of hierarchical traffic shaping and PXF queueing mode. All VPs should have been configured with
a rate of 10 Mbps and overbooked by a factor of 20.
Step 2
Established one PPPoA or one PPPoEoA session on each VC.
Step 3
Ensured that all sessions were up before starting the traffic.
Step 4
Generated upstream and downstream traffic matching the default class on all active sessions. Neither the
VCs nor the interface should have been overloaded. The aggregate ATM rate should not have exceeded
75 percent of the total available bandwidth in the downstream direction.
Step 5
Verified that no packet was dropped.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
26
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
QoS Policy Testing
The following negative checks were also performed:
•
Verified the proper handling of removing and applying QoS policy on a VC while sessions are
established.
•
Verified the policy reflected any rate change applied on the VC either via CLI or via DBS.
•
Verified the proper handling of shutdown and no shutdown of the main ATM interface.
Expected Results
The system scales up to the maximum number of applied queueing policy.
Results
Table 18 shows the QoS maximum number of applied queueing policy test results. Click a highlighted
test identifier in the following table, or see Table 3, Table 4, Table 5, and Table 6 to interpret the
identifiers.
Table 18
QoS Maximum Number of Applied Queueing Policy Test Configurations and Results
Platform
Configuration
Access Protocol
Combinations
Feature Profile
Traffic Profiles
Result/Reason
R1
A2
FP 5
TP 1
Passed
QoS Input and Output Policing
This test verified the accuracy of the QoS policer used to limit the inbound and outbound real-time and
business class traffic.
Table 19 lists the platform configurations, access protocol combinations, feature and traffic profiles
used, and test results. The following test procedure was executed for each unique combination listed in
the table.
Test Procedure
The following steps were performed:
Step 1
Configured 10 Mbps VPs on all available ports of the ATM module. The test configuration implied the
use of hierarchical traffic shaping and PXF queueing mode.
Step 2
Configured 512 kbps and 1 Mbps VCs mapping to the VPs. The VPs should have been overbooked by a
factor of 10 up to a maximum of 50 (for example, VP overbooking factor of 10, and 1:1 ratio between
the two rates VCs implies 65 VCs of each rate per VP). The VCs should have had all the QoS policy
applied.
Step 3
Established one PPPoA or one PPPoEoA session on each VC.
Step 4
Sent upstream and downstream traffic matching the real-time and business classes above the policer rate.
Neither the VPs nor the VCs should have been overloaded (traffic could be forwarded over a limited
number of VCs, matching one class first and then the other).
Step 5
Ensured that the inbound and outbound traffic matching the two classes was policed as expected.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
27
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
QoS Policy Testing
Step 6
Verified that the policy counters were updated.
The following negative checks were also performed:
•
Verified the proper handling of removing and applying QoS policy on a VC while sessions were
established.
•
Verified the proper handling of removing and adding VCs from/to VPs.
•
Verified the proper handling of shutdown and no shutdown of the main ATM interface.
Expected Results
The QoS policer strictly limits the input and output rate configured for the real-time and business classes.
Furthermore, the associated packets and bytes policy counters are all accurate.
Results
Table 19 shows the QoS input and output policing test results. Click a highlighted test identifier in the
following table, or see Table 3, Table 4, Table 5, and Table 6 to interpret the identifiers.
Table 19
QoS Input and Output Policing Test Configurations and Results
Platform
Configuration
Access Protocol
Combinations
Feature Profile
Traffic Profiles
Result/Reason
R1
A1
FP 5
TP 1
Passed
QoS Output Queueing
This test verified the accuracy of the QoS output queueing mechanism.
Table 20 lists the platform configurations, access protocol combinations, feature and traffic profiles
used, and test results. The following test procedure was executed for each unique combination listed in
the table.
Test Procedure
The following steps were performed:
Step 1
Configured 10 Mbps VPs on all available ports of the ATM module. The test configuration implied the
use of hierarchical traffic shaping and PXF queueing mode.
Step 2
Configured 512 kbps and 1 Mbps VCs mapping to the VPs. The VPs should have been overbooked by a
factor of 10 up to a maximum of 50 (for example, VP overbooking factor of 10, and 1:1 ratio between
the two rates VCs implies 65 VCs of each rate per VP). The VCs should have had all the QoS policy
applied.
Step 3
Established one PPPoA or one PPPoEoA session on each VC.
Step 4
Sent upstream and downstream traffic matching the real-time and business classes above the policer rate.
The VCs should have been overloaded in the downstream direction but not the VPs (traffic can be
forwarded over a limited number of VCs per VP).
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
28
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
Per-User ACL Feature Testing
Step 5
Ensured that the outbound traffic matching the two classes allocated the expected class bandwidth.
Step 6
Verified that the policy map counters were updated.
The following negative check was also performed:
•
Overloaded both VCs and VPs in the downstream direction with traffic matching the real-time and
business classes, and verified that there was no impact on other well-behaving VCs. This test could
be done on only one VP.
Expected Results
QoS output queueing provides bandwidth guarantees.
Results
Table 20 shows the QoS output queueing test results. Click a highlighted test identifier in the following
table, or see Table 3, Table 4, Table 5, and Table 6 to interpret the identifiers.
Table 20
QoS Output Queueing Test Configurations and Results
Platform
Configuration
Access Protocol
Combinations
Feature Profile
Traffic Profiles Result/Reason
R1
A1
FP 5
TP 1
Passed
Per-User ACL Feature Testing
This section describes the per-user access control list (ACL) test. An ACL is an ordered set of statements
that permit or deny packets based on matching criteria of access parameters specified in ACEs and the
information contained in the packet. For broadband, ACLs were applied on a per-session basis and were
downloaded from a RADIUS server using the following attributes:
ACL Attribute 242 - Ascend-Data-Filter (nonstandard keyword needed)
IETF attribute 11 - Filter-ID
Cisco AV pair to download an ACL
"ip:outacl[#number]={standard-access-control-list | extended-access-control-list}"
"ip:inacl[#number]={standard-access-control-list | extended-access-control-list}"
A variable portion of an ACL configuration is the number of ACEs per ACL. Because some platforms,
notably the Cisco 10000 router, handle ACLs differently when there are more than eight ACEs per ACL,
behavior for combined MiniACL (#ACEs <= 8) and TurboACL(#ACEs > 8) was checked.
Per-User ACL Functionality
This test verified ACL functionality during the session establishment phase (applying an ACL), during
the steady state (using an ACL), and after sessions were torn down (ACL removed) while churning was
happening in the background.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
29
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
Per-User ACL Feature Testing
Table 21 lists the platform configurations, access protocol combinations, feature and traffic profiles
used, and test results. The following test procedure was executed for each unique combination listed in
the table.
Test Procedure
The following steps were performed:
Step 1
Configured ACLs locally on the device under test.
Step 2
Configured user profiles on a RADIUS server using a mix of the Ascend-Data-Filter attribute, IETF
attribute 11, and Cisco attribute-value (AV) pairs to download an ACL in a ratio of 1:1:1.
Step 3
Established 6000 sessions (3000 PPPoE and 3000 PPPoA sessions) and sent traffic matching ACLs.
Step 4
Checked counters pertaining to ACLs (matches).
Step 5
Started churning of sessions either by disconnects on client, or by PPP idle timeout or absolute timeout
on the sessions. The sessions were left running for an extended period of time.
Step 6
Checked for memory leaks and CPU utilization.
Step 7
Tore down all sessions.
Step 8
Checked the device under test to verify that all per-user ACLs were removed.
Step 9
Established 6000 sessions (3000 PPPoE and 3000 PPPoA sessions) and sent traffic that matched the
ACLs.
Step 10
Changed profiles for the established users on RADIUS to not use ACLs anymore.
Step 11
Brought down all sessions and then reestablished them. None of the connected users should have had
any ACLs applied.
Expected Results
All sessions have their ACLs applied and working. All per-user ACLs need to be cleaned up after
sessions have been terminated.
Results
Table 21 shows the per-user ACL functionality test results. Click a highlighted test identifier in the
following table, or see Table 3, Table 4, Table 5, and Table 6 to interpret the identifiers.
Table 21
Per-User ACL Functionality Test Configurations and Results
Platform
Configuration
Access Protocol
Combinations
Feature Profile
Traffic Profiles
Result/Reason
R1
A1
FP 5
TP 1
Passed
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
30
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
Routing Feature Testing
Routing Feature Testing
This section describes testing done on the various IP address assignment methods. The following
paragraphs summarize these methods.
When the access protocol is PPPoX, subscribers are usually assigned an address from the BRAS into
which they are connecting. PPPoX users may be tunneled, in which case they receive their address from
the LNS at the end of the tunnel.
Address pools can be local, using a virtual template with a local pool applied, or a RADIUS server can
point to the pool. A RADIUS server can even assign a framed IP address. All the different IP address
assignment methods were tested.
Negative testing was also used to connect more users than the pool could handle, so the address pool was
depleted.
Table 7 lists all tests; click a highlighted test name or table number to go to results of that test.
Subscriber IP Address Assignment (PTA)
This test verified the IP address assignment toward the subscriber in the PTA role.
Table 22 lists the platform configurations, access protocol combinations, feature and traffic profiles
used, and test results. The following test procedure was executed for each unique combination listed in
the table.
Test Procedure
The following steps were performed:
Step 1
Configured four local pools, two for PPPoA users and two for PPPoE users. For each PPPoX type, one
was referenced by a virtual template, the other was called from a RADIUS server. Other PPPoX users
received their address assignments using RADIUS attribute 8 (framed IP address).
For example, with 2400 PPPoA sessions and 2400 PPPoE sessions, there would be:
Step 2
•
800 PPPoX using the local pool from the virtual template
•
800 PPPoX using the local pool from a RADIUS server
•
800 PPPoX using RADIUS attribute 8 (framed IP address)
•
2400 PPPoX sessions tunneled to an LNS
All sessions were brought up and a mix of Internet traffic was sent over each of the sessions.
Expected Results
All sessions are forwarding bidirectional traffic.
Results
Table 22 shows the subscriber IP address assignment (PTA) test results. Click a highlighted test
identifier in the following table, or see Table 3, Table 4, Table 5, and Table 6 to interpret the identifiers.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
31
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
Routing Feature Testing
Table 22
Subscriber IP Address Assignment (PTA) Test Configurations and Results
Platform
Configuration
Access Protocol
Combinations
Feature Profile
Traffic Profiles
Result/Reason
R4
A1
FP 6
TP 1
Passed
Pool Depletion
This test verified the behavior when all IP addresses of a pool were in use. When the role allowed for
higher numbers of sessions, the numbers provided in the following test procedure were increased.
Table 23 lists the platform configurations, access protocol combinations, feature and traffic profiles
used, and test results. The following test procedure was executed for each unique combination listed in
the table.
Test Procedure
The following steps were performed:
Step 1
Configured one local pool under a virtual template with a number of IP addresses insufficient to serve
all PPPoA and PPPoE users.
For example, 2400 PPPoA sessions and 2400 PPPoE sessions were configured. Only 2000 total
addresses were in the pool. 2400 PPPoX sessions used the local pool from a virtual template and 2400
PPPoX sessions were tunneled to an LNS.
Step 2
All sessions were brought up and an Internet mix traffic was sent over each session.
Expected Results
All sessions that received an IP address from the pool are forwarding bidirectional traffic. Those that
cannot obtain an IP address do not affect the established sessions, and do not remain established (LCP
open), but rather IPCP closed because testing forced the session down, because the ppp ipcp address
required command was set.
Results
Table 23 shows the pool depletion test results. Click a highlighted test identifier in the following table,
or see Table 3, Table 4, Table 5, and Table 6 to interpret the identifiers.
Table 23
Pool Depletion Test Configurations and Results
Platform
Configuration
Access Protocol
Combinations
Feature Profile
Traffic Profiles
Result/Reason
R4
A1
FP 6
TP 1
Passed
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
32
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
Routing Feature Testing
AAA Route Download
This test verified downloading routes using a AAA server.
Table 24 lists the platform configurations, access protocol combinations, feature and traffic profiles
used, and test results. The following test procedure was executed for each unique combination listed in
the table.
Test Procedure
The following steps were performed:
Step 1
Configured the PTA so it retrieved a large number of static routes pointing to a null interface from a
RADIUS server. Included the class attribute on the RADIUS server.
Step 2
Verified that all routes were installed.
Expected Results
All static routes are installed without any major impact on the CPU.
Results
Table 24 shows the AAA route download test results. Click a highlighted test identifier in the following
table, or see Table 3, Table 4, Table 5, and Table 6 to interpret the identifiers.
Table 24
AAA Route Download Test Configurations and Results
Platform
Configuration
Access Protocol
Combinations
Feature Profile
Traffic Profiles
Result/Reason
R8
A1
FP 8
TP 1
Passed
Half-Duplex VRF
This test verified the functionality of the Half-Duplex VRF feature. The solution the Half-Duplex VRF
feature provides is a forced path through a service provider network (an MPLS cloud) to the Internet
service provider (ISP). The forced path is without a shortcut for subscribers on the same service provider
edge (PE) to sends traffic back and forth using only the PE path; see Figure 4.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
33
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
Routing Feature Testing
Half-Duplex VRF
VPN port
A
PE
Hub
Spoke1
VPN port
Service PE
loopholes
Home
gateway
MPLS core
VPN port
B
VPN port
RPF traffic
All other traffic
CE
ISP
Hub
PE
Home
gateway
CE
ISP
121841
Figure 4
Specific checks were carried out to ensure that all subscribers’ peer-to-peer traffic was sent to the ISP.
Table 25 lists the platform configurations, access protocol combinations, feature and traffic profiles
used, and test results. The following test procedure was executed for each unique combination listed in
the table.
Test Procedure
The following steps were performed:
Step 1
Configured the PTA/PE with 32,000 users spread out over 20 Half-Duplex VRFs, and applied the users
using the following RADIUS script:
RADIUS av-pair = “lcp:interface-config=ip vrf forwarding <upstream_vrf_name> downstream
<downstream_vrf_name>\nip verify unicast reverse-path <downstream_vrf_name>”
Step 2
Sent traffic up and down the VRFs.
Step 3
Sent a small portion of traffic in a peer-to-peer fashion and checked the path that was followed (should
have gone to the ISP and back).
Expected Results
All sessions carry traffic over the half-duplex VRFs.
Peer-to-peer traffic on the PE router is not possible locally, but is instead forwarded to the ISP.
Results
Table 25 shows the Half-Duplex VFR test results. Click a highlighted test identifier in the following
table, or see Table 3, Table 4, Table 5, and Table 6 to interpret the identifiers.
Table 25
Half-Duplex VFR Test Configurations and Results
Platform
Configuration
Access Protocol
Combinations
Feature Profile
Traffic Profiles
Result/Reason
R8
A1
FP 8
TP 1
Passed
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
34
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
RADIUS and L2TP Feature Testing
RADIUS and L2TP Feature Testing
This section describes the tests to verify the correct functioning of RADIUS features in a BBA network
under traffic load.
The platform configuration and access protocol combinations were selected to use as many different
platforms and interfaces as possible under various conditions, to enhance test coverage. The test
configurations are identified in each test case.
The traffic profiles (see Table 6) were used in all RADIUS test cases.
A Sun workstation was used as a RADIUS server and configured with the Access Registrar version
1.7R6 software. Traffic to the RADIUS server was in-band.
Table 7 lists all tests; click a highlighted test name or table number to go to results of that test.
RADIUS Authentication
This test verified RADIUS authentication, which is the mechanism for identifying users before access
to a network is allowed.
Table 26 lists the platform configurations, access protocol combinations, feature and traffic profiles
used, and test results. The following test procedure was executed for each unique combination listed in
the table.
Test Procedure
The following steps were performed:
Step 1
Authenticated a PPPoX session with CHAP using a RADIUS server by name and in a default list. Also
verified the following attribute in the access request packet:
User-name(1)
CHAP-Password(3)
NAS-IP-Address (4)
NAS-Port (5)
Service-Type (6)
Framed-Protocol (7)
NAS-Port-Type (61)
Connect-Info(77)
Step 2
Authenticated a PPPoX session with Password Authentication Protocol (PAP) using a RADIUS server
by name and in a default list. Also verified the following attribute in the access request packet:
User-name(1)
User-Password(2)
NAS-IP-Address (4)
NAS-Port (5)
Service-Type (6)
Framed-Protocol(7)
NAS-Port-Type (61)
Connect-Info(77)
Step 3
Verified PPPoX authentication with failovers between RADIUS servers.
Step 4
Verified that authentication failed when the username or password was wrong (negative test). Verified
that the RADIUS server replied with the Reply-Message (18) attribute.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
35
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
RADIUS and L2TP Feature Testing
Step 5
Verified that there was no rollover with PPPoX authentication failure (negative test).
Step 6
Verified that the RADIUS server stopped by terminating related components on the RADIUS server (the
access registrar). The existing sessions were not affected.
Step 7
Verified that the RADIUS packets were sent to the server after the configured number of minutes using
the radius-server deadtime command.
If new sessions were still trying to connect when all the RADIUS servers were stopped, an access request
was sent, regardless of what was configured on the timer.
Step 8
When the RADIUS server was restarted, verified that the new sessions were valid and successful.
Expected Results
PPPoX sessions are up and an invalid username is dropped.
Results
Table 26 shows the RADIUS authentication test results. Click a highlighted test identifier in the
following table, or see Table 3, Table 4, Table 5, and Table 6 to interpret the identifiers
Table 26
RADIUS Authentication Test Configurations and Results
Platform
Configuration
Access Protocol
Combinations
Feature Profile
Traffic Profiles
Result/Reason
R1
A1
FP 4
TP 1
Passed
RADIUS Authorization
This test verified RADIUS authorization, which is the method used to describe what permissions users
have once the network has authenticated them.
Table 27 lists the platform configurations, access protocol combinations, feature and traffic profiles
used, and test results. The following test procedure was executed for each unique combination listed in
the table.
Test Procedure
The following step was performed:
•
Verified that an access reply packet was sent by the RADIUS server containing the defined
attributes:
Service-type (6)=2
Framed-Protocol(7)=1
Framed-IP-Address(8)
Framed-IP-Netmask (9)
Framed-routing (10)
Filter-ID (11)
Framed-route (22)
Class(25)
Vendor-Specific (26)
Session-Timeout(27)
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
36
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
RADIUS and L2TP Feature Testing
Idle-Timeout(28)
Ascend-Primary-DNS (135)
Ascend-secondary-DNS (136)
Ascend-DNS-Enable (137)
Ascend-Multicast-client (155)
Ascend-Assign-IP-Pool (218)
Ascend-Data-Filter (242).
Note
The value of attributes Service-type must contain 2 (Framed) and 1 for Framed-Protocol (PPP).
Expected Results
User that is authenticated and authorized with the specified parameters is able to send data through the
router.
Results
Table 27 shows the RADIUS authorization test results. Click a highlighted test identifier in the following
table, or see Table 3, Table 4, Table 5, and Table 6 to interpret the identifiers.
Table 27
RADIUS Authorization Test Configurations and Results
Platform
Configuration
Access Protocol
Combinations
Feature Profile
Traffic Profiles
Result/Reason
R1
A1
FP 4
TP 1
Passed
RADIUS Accounting
This test verified RADIUS accounting, which is used for logging and tracking the activities of users
using a network resource.
Table 28 lists the platform configurations, access protocol combinations, feature and traffic profiles
used, and test results. The following test procedure was executed for each unique combination listed in
the table.
Test Procedure
The following steps were performed:
Step 1
Applied accounting for a PPPoX session using a named and default list using the following commands:
aaa group server radius ACCOUNTING
aaa accounting network default start-stop group ACCOUNTING
aaa accounting delay-start
Step 2
Verified that a PPPoX session generated a start-stop record using the following command:
aaa accounting network default start-stop group ACCOUNTING
Step 3
Verified that a PPPoX session generated a stop-only record using the following command:
aaa accounting network default start-only group ACCOUNTING
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
37
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
RADIUS and L2TP Feature Testing
Step 4
Verified that a PPPoX session generated interim records using the following commands:
aaa accounting update periodic 1
accounting network default start-stop group ACCOUNTING
Step 5
Verified that a stop record was generated on a failure to authenticate using the following command:
aaa accounting send stop-record authentication failure
Step 6
Verified that each record type had a defined field.
a.
Verified that every accounting record had the following fields:
User-name (1)
NAS-IP-Address (4)
NAS-port (5)
Service-Type (6)
Framed-Protocol (7)
Framed-IP-Address (8)
Framed-IP-Netmask (9)
Framed-Routing (10)
Framed-Route (22)
Class (25)
connect-info (26-1)
cisco-nas-port (26-2)
Acct-status-type (40)
Acct-Delay-Time(41)
Acct-Input-Octets (42)
Acct-Output-Octets (43)
Acct-session-id (44)
Acct-Authentic (45)
Acct-Session-Time (46)
Acct-Input-Packets (47)
Acct-output-Packets (48)
Acct-Terminate-cause (49)
Acct-Input-Gigawords(52)
Acct-Output-Gigawords (53)
Event-Timestamp (55)
NAS-Port-Type (61)
Ascend-Pre-Input-Octets (190)
Ascend-Pre-Output-Octets (191)
Ascend-Pre-Input-Packets (192)
Ascend-Pre-Output-Packets (193)
Ascend-Disconnect-cause (195)
Ascend-Connect-Progress (196)
Ascend-Data-Rate (197)
Ascend-PreSession-Time (198)
Ascend-Xmit-Rate (255)
Note
NAS-Port-Type (61) should be virtual. For attributes 52 and 53, see Step 7.
b.
Verified that VPI/VCI information was added in Vendor Cisco (26)-Cisco-nas-port (2). The
VPI/VCI information was added after the slot/port. For example:
VPI=3, VCI=101, NAS port used is ATM 3/0/0. The attribute field should be 3/0/0/3.101
This format was supplied when the radius-server attribute nas-port d command is configured.
Step 7
Verified RADIUS attribute 52 and attribute 53 gigaword support.
Attribute 52 tracks the number of times the Acct-Input-Octets counter has rolled over the 32-bit integer
throughout the course of the provided service.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
38
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
RADIUS and L2TP Feature Testing
Attribute 53 tracks the number of times the Acct-Output-Octets counter has rolled over the 32-bit integer
throughout the delivery of service.
Both attributes can be present only in Accounting-Request records where the Acct-Status-Type is set to
“Stop” or “Interim-Update.”
Step 8
Verified the correct behavior of these attributes; they were used to keep accurate track of and bill for
usage.
Expected Results
Correct accounting packets are sent to the RADIUS server.
Results
Table 28 shows the RADIUS accounting test results. Click a highlighted test identifier in the following
table, or see Table 3, Table 4, Table 5, and Table 6 to interpret the identifiers.
Table 28
RADIUS Accounting Test Configurations and Results
Platform
Configuration
Access Protocol
Combinations
Feature Profile
Traffic Profiles
Result/Reason
R1
A1
FP 4
TP 1
Passed
L2TP-VPDN Load Sharing Group (LSG)
This test verified the ability of a remote user to connect to the network over a Layer 2 Transport Protocol
(L2TP) connection. The LAC could have received multiple Tunnel-Server-Endpoint attributes defined in
one tagged attribute group from a RADIUS server. These attributes were then used for VPDN LNS load
balancing and failover. They were interpreted as equal cost load balancing LNSs. The following example
shows that the LAC has the option to forward the session to three different LNSs:
RADIUS: Received from id 21648/217
RADIUS: authenticator 69 AF C4 86
RADIUS: Session-Timeout
[27]
RADIUS: Tunnel-Client-Auth-I[90]
RADIUS: Tunnel-Client-Auth-I[90]
RADIUS: Tunnel-Client-Auth-I[90]
RADIUS: Tunnel-Medium-Type [65]
RADIUS: Tunnel-Medium-Type [65]
RADIUS: Tunnel-Medium-Type [65]
RADIUS: Class
[25]
RADIUS:
6C 32 74 70
RADIUS: Tunnel-Server-Auth-I[91]
RADIUS: Tunnel-Server-Auth-I[91]
RADIUS: Tunnel-Server-Auth-I[91]
RADIUS: Framed-Protocol
[7]
RADIUS: Service-Type
[6]
RADIUS: Tunnel-Password
[69]
RADIUS: Tunnel-Password
[69]
RADIUS: Tunnel-Password
[69]
RADIUS: Tunnel-Preference
[83]
RADIUS: Tunnel-Preference
[83]
RADIUS: Tunnel-Preference
[83]
172.89.29.233:1645, Access-Accept, len 461
E7 C8 56 30 - C1 E5 E6 03 8A 50 2D AE
6
86400
33 01:"[email protected]"
33 02:"[email protected]"
33 03:"[email protected]"
6
01:IPv4
[1]
6
02:IPv4
[1]
6
03:IPv4
[1]
6
[l2tp]
33 01:"[email protected]"
33 02:"[email protected]"
33 03:"[email protected]"
6
PPP
[1]
6
Framed
[2]
37 *
37 *
37 *
6
01:100
6
02:100
6
03:100
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
39
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
RADIUS and L2TP Feature Testing
RADIUS:
RADIUS:
RADIUS:
RADIUS:
RADIUS:
RADIUS:
RADIUS:
Tunnel-Server-Endpoi[67]
Tunnel-Server-Endpoi[67]
Tunnel-Server-Endpoi[67]
Idle-Timeout
[28]
Tunnel-Type
[64]
Tunnel-Type
[64]
Tunnel-Type
[64]
16
16
16
6
6
6
6
01:"200.19.29.246"
02:"200.19.29.130"
03:"200.19.29.131"
900
01:L2TP
02:L2TP
03:L2TP
[3]
[3]
When PAP authentication was used, passwords were sent in cleartext over the tunnel. Service providers
can opt to use the l2tp hidden command to encrypt this sensitive information. Testing was performed
with the l2tp hidden command enabled at all times.
Table 29 lists the platform configurations, access protocol combinations, feature and traffic profiles
used, and test results. The following test procedure was executed for each unique combination listed in
the table.
Test Procedure
The following steps were performed:
Step 1
Configured the LAC and the RADIUS server so that the LAC had a choice among three LNSs with same
preference to which to forward sessions.
Step 2
Brought up numerous PPPoE sessions at a moderate rate and checked that sessions were evenly spread
over the three LNSs.
Step 3
Configured one of the LNSs to be unreachable. Sessions were to have been load-balanced among the two
remaining LNSs.
Step 4
Configured the second LNS to be unreachable. All new sessions should have been terminated on the only
remaining LNS.
Step 5
Repaired connectivity to the three LNSs and checked that newly added LNSs attracted the new sessions
until all three LNSs carried the same load. At this point, load balancing among all three LNSs should
have taken place again.
Step 6
Because the @ (at) symbol is used to delimit the user and domain names, a / (forward slash) symbol was
used instead. This step of the test verified whether the fully qualified domain name (FQDN) was passed
on to the RADIUS server.
Step 7
Configured the first LNS to be unavailable using the vpdn l2tp tunnel refuse command. The four LNSs
should have sent a stopCCN response general error (2), insufficient resources (4), and the session should
have been forwarded to the second LNS.
Step 8
Performed the same test as in Step 7, but configured the vpdn l2tp tunnel refuse 6 command on the first
LNS.
Step 9
Performed the same test as in Step 7, but configured the vpdn l2tp tunnel refuse 7 command on the first
LNS.
Expected Results
Tunnels are created for each domain name.
Traffic is able to be forwarded to the destination.
Load balancing works as expected.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
40
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
RADIUS and L2TP Feature Testing
Results
Table 30 shows the L2TP-VPDN LSG test results. Click a highlighted test identifier in the following
table, or see Table 3, Table 4, Table 5, and Table 6 to interpret the identifiers.
Table 29
L2TP-VPDN LSG Test Configurations and Results
Platform
Configuration
Access Protocol
Combinations
Feature Profile
Traffic Profiles
Result/Reason
R7
A1
FP 1
TP 1
Passed
L2TP Accounting
This test verified the ability of the router to send correctly requested tunnel accounting records.
Table 30 lists the platform configurations, access protocol combinations, feature and traffic profiles
used, and test results. The following test procedure was executed for each unique combination listed in
the table.
Test Procedure
The following steps were performed:
Step 1
Basic accounting was tested by applying tunnel accounting and verifying that a Tunnel-Start accounting
record was created when a tunnel was established. This test also verified that a Tunnel-Stop record was
created when a tunnel was terminated.
Step 2
Tunnel accounting attributes in the following record types were verified for correctness:
Tunnel-Type (64)
Tunnel-client-endpoint (66) (Should have been a string composed of the LAC IP address.)
Tunnel-server-endpoint (67) (Should have been a string composed of the LNS IP address.)
Acct-Tunnel-Connection (68) (Should have been a string composed of the local and remote IDs.)
Tunnel-Assignment-ID (82)
Tunnel-Client-Auth-ID (90) (Should have specified the name used by the tunnel initiator when
authenticating the tunnel set up with the tunnel terminator.)
Tunnel-Server-Auth-ID (91) (Should have specified the name used by the tunnel terminator when
authenticating the tunnel set up with the tunnel initiator.)
Step 3
Ensured that a tunnel reject record was written when a tunnel establishment failed (performed failure
tunnel establishment negative test).
Step 4
Cleared a few sessions on the LAC using the clear sss session command. Ensured appropriate
accounting records were generated (performed sessions within tunnel cleared negative test).
Expected Results
Tunnels are up and accounting records are sent.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
41
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
RADIUS and L2TP Feature Testing
Results
Table 30 shows the L2TP accounting test results. Click a highlighted test identifier in the following table,
or see Table 3, Table 4, Table 5, and Table 6 to interpret the identifiers.
Table 30
L2TP Accounting Test Configurations and Results
Platform
Configuration
Access Protocol
Combinations
Feature Profile
Traffic Profiles
Result/Reason
R4
A1
FP 1
TP 1
Passed
L2TP Multihop
In this test, multiple PPPoX sessions were collected by the LAC and forwarded on the correct L2TP
tunnel to the L2TP multihop router. Multiple ingress tunnels were mapped to outgoing L2TP tunnels,
which terminated on one or several LNSs. The objective of the test was to verify correct L2TP multihop
behavior.
Table 31 lists the platform configurations, access protocol combinations, feature and traffic profiles
used, and test results. The following test procedure was executed for each unique combination listed in
the table.
Test Procedure
The following steps were performed:
Step 1
Verified that the multihop node can switch L2TP ingress tunnels to L2TP egress tunnels by checking
whether an L2TP tunnel is present on the LAC and L2TP on the final destination LNS. On the multihop
node, verified that all L2TP tunnels were up.
Step 2
Verified that VPDN multihop configured with the vpdn authen-before-forward command enabled
worked, and that the tunnel forwarding was done with the full PPP authenticated username.
On both the final destination LNS and the LAC, the show vpdn command was used to verify that the
L2TP tunnels were up. On the multihop node, the show vpdn command indicated that the L2TP tunnels
were up for VPDN and the show sss session command indicated there was one session active.
The VPDN session was supposed to multihop to its final destination LNS. The show vpdn command
was used on the final destination LNS to verify multihop. Review of Subscriber Service Switch (SSS)
debugs on the multihop node verified that the PPP full username was first authenticated and then
forwarded.
Expected Results
Tunnels are up from the LAC to the destination LNS and that traffic is passing through the tunnel.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
42
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
Network Management and Access Control Feature Testing
Results
Table 31 shows the L2TP multihop test results. Click a highlighted test identifier in the following table,
or see Table 3, Table 4, Table 5, and Table 6 to interpret the identifiers.
Table 31
L2TP Multihop Test Configurations and Results
Platform
Configuration
Access Protocol
Combinations
Feature Profile
Traffic Profiles
Result/Reason
R9
A1
FP 1
TP 1
Passed
Network Management and Access Control Feature Testing
This section describes the tests to verify the correct functioning of selected network management and
router access control features in a broadband aggregation network under traffic load.
To enhance test coverage, the platform configuration and access protocol combinations were selected to
use as many different platforms and interfaces as possible under various conditions (although the correct
behavior of the network management and access control features should not directly depend on the
platforms and interfaces). The various test configurations (defined by the role and access protocol
combinations) to be used for testing were identified in each test case.
A mix of Internet traffic was used in all network management and access control test cases.
A Sun workstation was used for each network management and access control test case and configured
with the following software:
•
HP OpenView for SNMP polling and traps
•
Solaris 2.x syslog server
•
SSH Secure Shell 3.0.1 by SSH Communications Security Corporation
•
Cisco Terminal Access Controller Access Control System Plus (TACACS+) developer’s kit version
F4.0.4
Table 7 lists all tests; click a highlighted test name or table number to go to results of that test.
SNMP
This test verified Simple Network Management Protocol (SNMP) functionality.
Each router in the service provider network was configured as an SNMP agent. The SNMP manager used
to test this feature was HP OpenView. The agent and MIB resided on the router. The SNMP manager
could request or change the values of MIB variables on routers. Routers could also send unsolicited traps
to the SNMP manager. The SNMP traffic was sent in-band in the test bed.
SNMP version (v1, v2c, v3) specific features were not tested.
Table 32 lists the platform configurations, access protocol combinations, feature and traffic profiles
used, and test results. The following test procedure was executed for each unique combination listed in
the table.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
43
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
Network Management and Access Control Feature Testing
Test Procedure
The following steps were performed:
Step 1
Configured each router with the following SNMP commands:
snmp-server
snmp-server
snmp-server
snmp-server
snmp-server
community private RW
community public RO
trap-source Loopback0
enable traps
host 10.52.1.1 public
Step 2
Verified that the SNMP manager could identify all agents on the routers.
Step 3
Verified that the SNMP manager could obtain the MIB information and SNMP traps of each router.
Step 4
Verified that the SNMP manager could set the MIB values on routers.
Expected Results
Each router can connect to the SNMP manager on the network management system.
The SNMP manager can get MIB information and SNMP traps from each router.
The SNMP manager can set MIB variables.
Results
Table 32 shows the SNMP test results. Click a highlighted test identifier in the following table, or see
Table 3, Table 4, Table 5, and Table 6 to interpret the identifiers.
Table 32
SNMP Test Configurations and Results
Platform
Configuration
Access Protocol
Combinations
Feature Profiles
Traffic Profiles
Result/Reason
R4
A2
FP 2
TP 1
Passed
AAA TACACS+
This test verified AAA TACACS+ functionality.
Service provider networks used TACACS+ servers for AAA. Each router was configured to use a
TACACS+ server to authenticate user logins, authorize shell command access, and keep an account of
user activities.
Table 33 lists the platform configurations, access protocol combinations, feature and traffic profiles
used, and test results. The following test procedure was executed for each unique combination listed in
the table.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
44
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
Network Management and Access Control Feature Testing
Test Procedure
The following steps were performed:
Step 1
Added each router to the network configuration section of TACACS+ using the router loopback IP
address, and set the TACACS+ key.
Step 2
Configured users and groups with privileged settings on the TACACS+ server.
Step 3
Enabled AAA on the routers using the aaa new-model command.
Step 4
Configured the TACAS+ server connection and AAA features using the following commands:
aaa authentication login TELNETUSER group tacacs+ local
aaa authentication login NO_AUTH none
aaa authentication enable default group tacacs+ enable
aaa authorization exec TELNETUSER group tacacs+ local
aaa authorization exec NO_AUTH none
aaa authorization commands 1 default group tacacs+ local
aaa authorization commands 15 default group tacacs+ local
aaa accounting exec TELNETUSER start-stop group tacacs+
ip tacacs source-interface Loopback0
tacacs-server host <IP-address> key <key-string>
Step 5
Applied AAA to the corresponding line or interfaces using the following commands:
line con 0
authorization exec NO_AUTH
login authentication NO_AUTH
line vty 0 4
authorization exec TELNETUSER
login authentication TELNETUSER
accounting exec TELNETUSER
Step 6
Used the console and Telnet to log in to each router and executed AAA-related tasks.
Step 7
Verified that users were properly authenticated and authorized at the specified command level. Used the
show tacacs, debug aaa authentication, and debug aaa authorization EXEC commands to
troubleshoot problems. The test team also verified that the user prompts when in user and privileged
EXEC mode were correct.
Step 8
Verified that the password change sequence worked.
Step 9
Verified that user activities were recorded on the TACACS+ server.
Expected Results
Users are properly authenticated and authorized.
Users can change their password.
User activities are recorded on the TACACS+ server.
Results
Table 33 shows the AAA TACACS+ test results. Click a highlighted test identifier in the following table,
or see Table 3, Table 4, Table 5, and Table 6 to interpret the identifiers.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
45
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
Network Management and Access Control Feature Testing
Table 33
AAA TACACS+ Test Configurations and Results
Platform
Configuration
Access Protocol
Combinations
Feature Profiles
Traffic Profiles
Result/Reason
R4
A2
FP 2
TP 1
Passed
NetFlow
This test verified NetFlow switching functionality.
NetFlow switching provides network administrators with access to call detail recording information
from their data networks. Exported NetFlow data can be used for a variety of purposes, including
network management and planning, enterprise accounting and departmental chargebacks, Internet
Service Provider (ISP) billing, data warehousing, and data mining for marketing purposes. NetFlow also
provides a highly efficient mechanism with which to process security access lists without as much of a
performance penalty as is incurred with other available switching methods. NetFlow can also be used to
detect Denial of Service (DoS) attacks and regulate the flow of traffic in a DoS attack through rate
limiting.
Table 34 lists the platform configurations, access protocol combinations, feature and traffic profiles
used, and test results. The following test procedure was executed for each unique combination listed in
the table.
Test Procedure
The following steps were performed:
Step 1
Configured NetFlow on interfaces using the ip route-cache flow command.
Step 2
Configured NetFlow on the virtual template using the ip flow ingress command. (The test team did not
use ip route-cache flow virtual-template command because full virtual access interfaces would have
been created).
Step 3
Verified that NetFlow was configured using the show ip interface command.
Step 4
Sent traffic over the established sessions. If possible, the test team sent a sweep of packet sizes.
Step 5
Verified that NetFlow functioned properly using the show ip cache flow command, or alternatively,
configured a NetFlow collector to store the data for further analysis.
Expected Results
NetFlow is configured on interfaces.
NetFlow functions properly.
Results
Table 34 shows the NetFlow test results. Click a highlighted test identifier in the following table, or see
Table 3, Table 4, Table 5, and Table 6 to interpret the identifiers.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
46
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
Network Management and Access Control Feature Testing
Table 34
NetFlow Test Configuration and Test Results
Platform
Configuration
Access Protocol
Combinations
Feature Profiles
Traffic Profiles
Result/Reason
R4
A1
FP 3
TP 1
Passed
Syslog
This test verified system message logging functionality.
The Cisco IOS system message logging (syslog) process allows the system to report and save important
error and notifications messages, either locally or to a remote logging server. These syslog messages
include messages in a standardized format (often called system error messages) and output from debug
commands. These messages are generated during network operation to assist users and Cisco engineers
with identifying the type and severity of a problem, or to aid users in monitoring router activity. Syslog
messages can be sent to the console, a monitor (tty and Telnet connections), the system buffer, or remote
hosts.
Table 35 lists the platform configurations, access protocol combinations, feature and traffic profiles
used, and test results. The following test procedure was executed for each unique combination listed in
the table.
Test Procedure
The following steps were performed:
Step 1
Configured the following logging commands on each router:
logging trap severity-level
logging host [hostname | IP-address]
Step 2
Configured the syslog server to log router messages. On a Solaris workstation, the /etc/syslog.conf file
was edited as follows:
local7.info/var/log/router-info-log
local7.debug/var/log/router-debug-log
Step 3
Restarted the syslog daemon on the server.
Step 4
Sent syslog messages of different severities; for example, change configuration, unplug an interface
cable, and turn on debugging.
Step 5
Verified that no interface or protocol up and down messages were sent to syslog when a virtual template
was configured as follows:
no logging event link-status
no snmp trap link-status
Step 6
Verified that the syslog messages reached the syslog server and were properly classified by severity
level. Used the show logging command to troubleshoot problems.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
47
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
Network Management and Access Control Feature Testing
Expected Results
The router sends syslog messages of appropriate severity
Syslog messages are properly recorded on the syslog server.
Results
Table 35 shows the syslog test results. Click a highlighted test identifier in the following table, or see
Table 3, Table 4, Table 5, and Table 6 to interpret the identifiers.
Table 35
Syslog Test Configurations and Results
Platform
Configuration
Access Protocol
Combinations
Feature Profiles
Traffic Profiles
Result/Reason
R4
A2
FP 2
TP 1
Passed
AAA Session MIB
Service providers need a means of checking how many users are active on a system and what the highest
number of concurrent users is at any point in time (high watermark figures). This high watermark figure
is used for planning and user license fee procurement. This test tested the AAA Session MIB to verify
that it correctly reported the number of active users.
Table 36 lists the platform configurations, access protocol combinations, feature and traffic profiles
used, and test results. The following test procedure was executed for each unique combination listed in
the table.
Test Procedure
The following steps were performed:
Step 1
Configured the aaa session-mib populate start command.
Step 2
Enabled SNMP; see the “SNMP” section on page 43.
Step 3
Brought up 2000 PPPoA users.
Step 4
Queried the casnActiveTableEntries by polling the OID 1.3.6.1.4.1.9.9.150.1.1.1 of the
CISCO-AAA-SESSION-MIB.
Step 5
Brought up another 400 PPPoA users.
Step 6
Queried the casnActiveTableEntries by polling the OID 1.3.6.1.4.1.9.9.150.1.1.1 of the
CISCO-AAA-SESSION-MIB.
Step 7
Cleared all users.
Step 8
Queried the casnTotalSessions by polling the OID 1.3.6.1.4.1.9.9.150.1.2.1 of the
CISCO-AAA-SESSION-MIB
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
48
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
Network Management and Access Control Feature Testing
Expected Results
The MIB reports the correct number of active users.
High watermark of total active sessions at any point in time shows 2400.
Results
Table 36 shows the AAA session MIB test results. Click a highlighted test identifier in the following
table, or see Table 3, Table 4, Table 5, and Table 6 to interpret the identifiers.
Table 36
AAA Session MIB Test Configurations and Results
Platform
Configuration
Access Protocol
Combinations
Feature Profiles
Traffic Profiles
Result/Reason
R8
A1
FP 8
TP 1
Passed
PPPoE Session MIB
Service providers need a means of checking how many PPPoE sessions are active on a system and what
the highest number of concurrent PPPoE users is at any point in time (high watermark figures). This test
tested the PPPoE session MIB to verify that it correctly reported the number of concurrent PPPoE users.
Table 37 lists the platform configurations, access protocol combinations, feature and traffic profiles
used, and test results. The following test procedure was executed for each unique combination listed in
the table.
Test Procedure
The following steps were performed:
Step 1
Enabled SNMP; see the “SNMP” section on page 43.
Step 2
Brought up 2000 PPPoE users.
Step 3
Queried the cPppoeSystemCurrSessions by polling the OID 1.3.6.1.4.1.9.9.194.1.1.1 of the
CISCO-PPPOE-MIB.
Step 4
Brought up another 400 PPPoA users.
Step 5
Queried the cPppoeSystemCurrSessions by polling the OID 1.3.6.1.4.1.9.9.194.1.1.1 of the
CISCO-PPPOE-MIB.
Step 6
Cleared all users.
Step 7
Queried the cPppoeSystemHighWaterSessions by polling the OID 1.3.6.1.4.1.9.9.194.1.1.2 of the
CISCO-PPPOE-MIB. See the following URL for complete MIB information:
http://ftp.eenet.ee/doc/cisco-snmp/oid/CISCO-PPPOE-MIB.oid
Expected Results
The MIB reports the correct number of active users.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
49
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
Network Management and Access Control Feature Testing
High watermark of total active sessions at any point in time shows 2400.
Results
Table 37 shows the PPPoE session MIB test results. Click a highlighted test identifier in the following
table, or see Table 3, Table 4, Table 5, and Table 6 to interpret the identifiers.
Table 37
PPPoE Session MIB Test Configurations and Results
Platform
Configuration
Access Protocol
Combinations
Feature Profiles
Traffic Profiles
Result/Reason
R4
A2
FP 5
TP 1
Passed
Packet of Disconnect
Service providers should be able to disconnect a user on the fly. A RADIUS server can send a Packet of
Disconnect (PoD) message to force a user to disconnect. This test tested PoD to verify that it correctly
disconnected sessions once the message was received.
Table 38 lists the platform configurations, access protocol combinations, feature and traffic profiles
used, and test results. The following test procedure was executed for each unique combination listed in
the table.
Test Procedure
The following steps were performed:
Step 1
Configured the aaa pod server command on the router.
Step 2
Started an application that could send a PoD packet to the router.
Step 3
Brought up a PPPoE and a PPPoA session.
Step 4
Sent a PoD for both sessions.
Expected Results
Sessions are disconnected after PoD has been received.
Results
Table 38 shows the PoD test results. Click a highlighted test identifier in the following table, or see
Table 3, Table 4, Table 5, and Table 6 to interpret the identifiers.
Table 38
PoD Test Configurations and Results
Platform
Configuration
Access Protocol
Combinations
Feature Profiles
Traffic Profiles
Result/Reason
R1
A1
FP 8
TP 1
Passed
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
50
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
Access Protocols Feature Testing
Access Protocols Feature Testing
This section describes the tests to verify the functionality of client access protocols such as ATM
Adaptation Layer 5 AAL5SNAP, for both PPPoA and PPPoE, and AAL5MUX for PPPoA sessions.
Testing was performed on both fixed and automatic encapsulation on a VC.
A minimum of 1000 sessions were used to test the functionality of a given feature. Traffic was sent to
60 percent of the active sessions. Another 20 percent of the sessions were active but had no traffic sent
over them. The remaining 20 percent of the sessions were in a transition state connecting with an
incorrect password.
Table 7 lists all tests; click a highlighted test name or table number to go to results of that test.
Autosense
This test verified PPP autosense functionality when different PPPoX connections running over different
encapsulations were presented to the router. The testers used a minimum of 1000 sessions to test the
functionality of a given feature. Traffic was sent to 60 percent of the active sessions. Twenty percent of
the sessions were active but had no traffic sent over them. The remaining 20 percent were in a transition
state, for example, connecting with an incorrect password.
Table 39 lists the platform configurations, access protocol combinations, feature and traffic profiles
used, and test results. The following test procedure was executed for each unique combination listed in
the table.
Test Procedure
The following steps were performed:
Step 1
Cisco AUTO PPP over AAL5 (AAL5AUTOPPP) encapsulation was enabled on the unit under test.
Step 2
Configured 500 PPPoA/AAL5SNAP and 500 PPPoE/AAL5SNAP sessions on the client. Waited for
sessions to come up.
Step 3
Switched AAL5SNAP to MUX on the clients. Expected the PPPoE sessions to go down and PPPoA
session to stay up.
Step 4
Changed encapsulation back to AAL5SNAP on the clients. All sessions were expected to be up and
running traffic.
Step 5
Configured a VC on client to send RFC1483 Bridge Protocol Data Units (BPDUs). A VC should have
been autodetected to Subnetwork Access Protocol (SNAP), but there should have been no active session
on it, as indicated in the following sample output:
0xAA-AA-03 LLC = SNAP
0x00-80-C2OUI = 802.1
0x00-07Ethernet FCS is not preserved
0x00-00Padding
0xFF-FF-FF-FF-FF-FF Source MAC (example)
0x00-0C-85-66-60-B4 Dest MAC
(example)
0x80-00IP
Step 6
Changed the VC on the client to AAL5SNAP PPPoE encapsulation. The PPPoE session was expected to
come up.
Step 7
Configured a VC on a client to send RFC1483 BPDUs. The VC should have been autodetected to SNAP,
but there should have been no active session on it.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
51
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
Access Protocols Feature Testing
Step 8
Changed the VC on a client to AAL5SNAP PPPoA encapsulation. A PPPoA session was expected to
come up.
Step 9
Configured a VC on a client to send RFC1483 BPDUs. The VC should have been autodetected to SNAP,
but there should have been no active session on it.
Step 10
Changed a VC on a client to MUX PPPoA encapsulation. A PPPoA session was expected to come up.
Step 11
Repeated Steps 5 through 10, but using RFC1483 routed on a client instead of RFC1483 BPDUs. The
following figure shows the structure of routed IP PDUs.
Payload Format for Routed IP PDUs
LLC
0xAA-AA-03
OUI 0x00-00-00
IP PDU
(up to 2^16 - 9 octets)
121842
EtherType 0x08-00
Step 12
Changed encapsulation types continuously on the client, from RFC1483 BPDU to RFC1483 routed, to
PPPoE/AAL5SNAP, to PPPoA MUX, and to PPPoA/AAL5SNAP. Each encapsulation type was left
active for 2 minutes. The test team checked that the VC was not stuck and that a PPPoA or PPPoE session
could be established once a valid protocol type and encapsulation were activated on client.
Step 13
Verified that traffic was flowing and fragmentation was handled correctly when sessions were active.
Step 14
Checked the AAA server records to verify all information received from the router was in correct format
and order, and that accounting records were accurate.
Step 15
Verified the maximum transmission unit (MTU) size on the virtual access interface.
Step 16
Checked the PPP idle timer operation set by the ppp idle timer command by running the show caller
time EXEC command.
Step 17
Verified that PPP keepalive flowed under severe congestion.
Step 18
Checked %CPU utilizations and PROC MEM, looking for correct allocation and release of resources.
Step 19
Cleared a virtual access interface and verified proper cleanup of all records. Verified that all resources
were released.
Step 20
Switched active and standby processors on Cisco 10000 routers and verified end-to-end packet flow for
all sessions.
Expected Results
No matter what type of PPPoX connection is running over either a MUX or SNAP encapsulated VCs,
the AAL5AUTOPPP software detects it automatically so sessions are established. Encapsulations that
are not recognized do not render a VC unusable.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
52
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
Access Protocols Feature Testing
Results
Table 39 shows the autosense test results. Click a highlighted test identifier in the following table, or see
Table 3, Table 4, Table 5, and Table 6 to interpret the identifiers.
Table 39
Autosense Test Configurations and Results
Platform
Configuration
Access Protocol
Combinations
Feature Profile
Combinations
Traffic Profile
Combination
Result/Reason
R1
A1
FP 2
TP 3
Passed
PPP Idle Timeout
This test verified the functionality of PPP idle timeout for a given session either applied via a RADIUS
server or using a configuration applied to a virtual template. This test was done for sessions terminated
on the broadband remote access server (BRAS), that is, a PTA. This test also applied a timeout on
tunneled sessions so they would also time out.
Table 40 lists the platform configurations, access protocol combinations, feature and traffic profiles
used, and test results. The following test procedure was executed for each unique combination listed in
the table.
Test Procedure
The following steps were performed:
Step 1
Applied the ppp timeout idle 300 command on all virtual access interfaces.
Step 2
Stopped sending traffic for 300 seconds to some of the sessions and verified that these sessions timed
out by using the show caller timeout command.
Step 3
Stopped sending traffic to a session for fewer than 300 seconds and restarted the traffic while checking
the output of show caller timeout command, to verify that the timers were reset to the original
300 seconds when traffic was present.
Step 4
Applied an ACL to define interesting traffic that can trigger the idle timer. The following is an example
configuration that was used in this test case to deny Internet Control Message Protocol (ICMP) traffic
from triggering the idle timer.
interface Virtual-Template1
ip unnumbered Loopback1
ip idle-group 101 in
ip idle-group 101 out
ppp authentication chap
ppp timeout idle 300
!
access-list 101 deny icmp any any
access-list 101 permit ip any any
Testers verified that only interesting traffic triggered the idle timer.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
53
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
Access Protocols Feature Testing
Step 5
Applied the idle timeout configuration using a RADIUS user profile such as the following example:
RADIUS user-profile...
Password = isco
Service-Type = Framed
Framed-Protocol = PPP
Idle-Timeout = 300
Step 6
Repeated Steps 2 and 3.
Step 7
Applied the idle timeout period on the L2TP sessions.
Step 8
Checked whether sessions over a tunnel were cleared when idle.
Step 9
Switched active and standby processors on Cisco 10000 routers and performed Steps 2, 3, and 4 again.
Testers also verified end-to-end packet flow for all sessions.
Expected Results
PTA and LAC drop sessions when there is no traffic to keep sessions up.
Results
Table 40 shows PPP idle timeout test results. Click a highlighted test identifier in the following table, or
see Table 3, Table 4, Table 5, and Table 6 to interpret the identifiers.
Table 40
PPP Idle Timeout Test Configurations and Results
Platform
Configuration
Access Protocol
Combinations
Feature Profile
Combinations
Traffic Profile
Combination
Result/Reason
R4
A1
FP 6
TP 3
Passed
PPPoEoA per-VC or per-MAC Session Limit
This test verified that, when a configured maximum limit was reached, the consecutive sessions failed
due to the maximum limit setting.
Table 41 lists the platform configurations, access protocol combinations, feature and traffic profiles
used, and test results. The following test procedure was executed for each unique combination listed in
the table.
Test Procedure
The following steps were performed:
Step 1
Configured the sessions per-vc limit 1 and sessions per-mac limit 1 commands for BBA and VPDN
groups.
Step 2
Attempted to bring up all sessions with only one session for a given VC.
Step 3
Attempted to bring up a second session for a small number of VCs, and verified that they all failed to
establish because the maximum limit configured was reached.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
54
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
SSG Feature Testing
Step 4
Used the debug pppoe events and debug pppoe packets commands to display the error “max-limit
reached.”
Expected Results
A user cannot bring up more sessions than the session limit.
Results
Table 41 shows the PPPoEoA per-VC or per-MAC session limit test results. Click a highlighted test
identifier in the following table, or see Table 3, Table 4, Table 5, and Table 6 to interpret the identifiers.
Table 41
PPPoEoA per-VC or per-MAC Session Limit Test Configurations and Results
Platform
Configuration
Access Protocol
Combinations
Feature Profile
Combinations
Traffic Profile
Combination
Result/Reason
R4
A1
FP 6
TP 3
Passed
SSG Feature Testing
Service Selection Gateway (SSG) feature testing was done to verify limited SSG functionality by
introducing users with a user profile containing auto login to a pass-through service. The tests enabled
the test team to deploy SSG and create all necessary objects, and to pass traffic over a large number of
sessions, without the need for any client (web browser) interaction.
Table 7 lists all tests; click a highlighted test name or table number to go to results of that test.
SSG Passthrough with Auto Logon
This test verified the creation and deletion of SSG objects (host object, service object, and bindings) for
a large number of users.
Table 42 lists the platform configurations, access protocol combinations, feature and traffic profiles
used, and test results. The following test procedure was executed for each unique combination listed in
the table.
Test Procedure
The following steps were performed:
Step 1
Configured pass-through services on an Access-Request (AR) server by creating a default service profile
and adequate user profiles, as shown in the following examples:
Sample service profile:
//localhost/Radius/UserLists/Default/passthrough0001
Password = servicecisco
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
55
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
SSG Feature Testing
//localhost/Radius/UserLists/Default/passthrough0001/Attributes
cisco-SSG-service-info = "Ipassthrough0001"
cisco-SSG-service-info = R10.40.96.3;255.255.255.255
cisco-SSG-service-info = TP
Service-Type = Outbound
Sample user profile:
Cisco-SSG-Account-Info = Apassthrough0001
Cisco-AVPair = <...>
Framed-MTU = 1500
Framed-Protocol = PPP
Service-Type = Framed
Step 2
Configured SSG on the device under test, as shown in the following example. The example is based on
a default network where Subscriber Edge Services Manager (SESM) and the AR screen are located. The
example assumes service is not active for the SSG host object (this can be verified using the show ssg
host ip-address command), and that this network is the only reachable IP network for the PPPoX session.
The SSG service information string starting with the prefix “R” in the AR service profile allows the SSG
to send traffic to another network apart from the default, as long as the bind command is configured
correctly; see the ssg bind service command in the following example:
aaa group server radius CAR
server-private <IP add CAR> auth-port 1812 acct-port 1813 key cisco
aaa
aaa
aaa
aaa
authentication login vty line
authentication ppp default group CAR
authorization exec vty none
authorization network default group CAR
vpdn enable
ssg enable
ssg local-forwarding
ssg default-network <IP NETWORK> <IP NETWORK MASK>
ssg
ssg
ssg
ssg
service-password servicecisco
radius-helper auth-port 1812 acct-port 1813
radius-helper key cisco
bind service passthrough0001 <egress interface>
interface <egress interface>
ssg direction uplink
radius-server
radius-server
radius-server
radius-server
radius-server
radius-server
radius-server
radius-server
radius-server
attribute 44 include-in-access-req
attribute 55 include-in-acct-req
host 10.30.81.20 auth-port 1812 acct-port 1813 key cisco
retransmit 2
timeout 3
key cisco
authorization permit missing Service-Type
vsa send accounting
vsa send authentication
Step 3
Brought up 5000 users (2500 PPPoE, 2500 PPPoA).
Step 4
Churned 5 percent of the users.
Step 5
Sent traffic over all the active sessions.
Step 6
Verified whether SSG objects were created and removed for the churned sessions.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
56
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
Multicast Feature Testing
Expected Results
All sessions are forwarding bidirectional traffic and host objects are created and deleted appropriately.
Results
Table 42 shows the SSG passthrough with autologon test results. Click a highlighted test identifier in the
following table, or see Table 3, Table 4, Table 5, and Table 6 to interpret the identifiers.
Table 42
SSG Passthrough with Autologon Test Configurations and Results
Platform
Configuration
Access Protocol
Combinations
Feature Profile
Combinations
Traffic Profile
Combination
Result/Reason
R1
A1
FP 7
TP 1
Passed
Multicast Feature Testing
Because multicast is being gradually deployed on broadband platforms, the Internet Group Management
Protocol (IGMP) control plane was tested using IGMP capable clients communicating with a rendezvous
point (RP). The Adtech PPPoX session generator issued a join-leave on a PPPoE session. Once clients
joined a multicast group, the data plane was verified by streaming replicated multicast traffic to the users
of the group. Sometimes access control lists exist on networks and block multicast traffic. To overcome
this, users sometimes use Generic Routing Encapsulation (GRE) tunneling and route multicast over the
tunnel. For this reason, both GRE tunneled multicast and multicast over IP were tested.
The multicast over GRE tunnel and multicast over IP test case configurations were based on the use of
the Protocol Independent Multicast (PIM) sparse-mode protocol requiring an RP, as shown in Figure 5.
The test scenarios were limited to the PTA topology.
Figure 5
Multicast with PIM Sparse-Mode Requiring RP
ADSL users
(PPPoX)
Multicast
replications
Cisco 10000
GBE
Cisco 10000
ATM
DSLAM
Rendezvous
point
Cisco 10000
GRE tunnel
121840
Multicast source
Server Win 2003
Cisco 10000
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
57
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
Multicast Feature Testing
The Adtech IGMP over PPPoEoA emulation provided capability to initiate IGMP join and leave requests
over PPPoEoA sessions. This feature was used in the following two test cases to emulate multicast
receivers. The multicast source was also simulated by the Adtech. A Gigabit Ethernet interface was used
for that purpose and was connected to the RP device. One or several multicast streams were sourced from
this Adtech Gigabit Ethernet interface. The multicast packets generated from this interface and received
by the RP device were then forwarded to the PTA unit under test where the multicast replication was
performed.
Multicast over GRE Tunnel
This test verified the control and data plane of a multicast protocol in a broadband environment, in a
scenario where the multicast traffic was forwarded over a GRE tunnel.
Table 43 lists the platform configurations, access protocol combinations, feature and traffic profiles
used, and test results. The following test procedure was executed for each unique combination listed in
the table. Table 7 lists all tests; click a highlighted test name or table number to go to results of that test.
Test Procedure
The following steps were performed:
Step 1
Configured the maximum number of VCs supported by the system (for example, 61.5 kbps for PRE-2
and no PXF queueing).
Step 2
Established 1280 PPPoE sessions over which IGMP join requests were initiated toward two multicast
groups (640 sessions joining one group and the 640 other sessions joining a second group). Other PPPoA
or PPPoEoA sessions were also brought up to obtain a total of 30,000 to 40,000 users connected. All
sessions should be brought up with an output service policy inherited from the virtual template. The
output policy includes a single class map with the police action to limit the session output rate. Multiple
virtual template interfaces (configured using bba-group commands) were used with a different service
policy and policer rate applied (for example, 256, 640, and 1280 kbps).
Step 3
Generated downstream multicast traffic toward the two multicast groups the 1280 PPPoE sessions had
joined. The downstream load should not have exceed the session rate nor the interface rate when
replicated over the multicast enabled receivers’ sessions.
Step 4
Verified that the relevant (S,G) entries were inserted in the multicast routing table. The incoming
interface for these (S,G) entries should have been the GRE tunnel interface.
Step 5
Verified that all multicast sourced packets were replicated over the 1280 PPPoE sessions. Packets
sourced for each of the two streams should have been replicated over 640 sessions.
Step 6
Established 3000 PPPoE sessions over which IGMP join requests were initiated toward one single
multicast group. Other PPPoA or PPPoEoA sessions were also brought up, to obtain a total of 30,000 to
40,000 users connected as in Step 2.
Step 7
Generated downstream multicast traffic toward the multicast group the 3000 PPPoE sessions had joined.
The downstream load should not have exceeded the session rate nor the interface rate when replicated
over the multicast-enabled receivers’ sessions.
Step 8
Verified that the relevant (S,G) entries were inserted in the multicast routing table. The incoming
interface for these (S,G) entries should be the GRE tunnel interface.
Step 9
Verified that all multicast sourced packets were replicated over the 3000 PPPoE sessions.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
58
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
Multicast Feature Testing
Expected Results
Multicast over GRE configuration allows the support of multicast control and data traffic in a broadband
environment with PPPoX multicast-enabled receivers.
Results
Table 43 shows the multicast over GRE tunnel test results. Click a highlighted test identifier in the
following table, or see Table 3, Table 4, Table 5, and Table 6 to interpret the identifiers.
Table 43
Multicast over GRE Tunnel Test Configurations and Results
Platform
Configuration
Access Protocol
Combinations
Feature Profile
Combinations
Traffic Profile
Combination
Result/Reason
R1
A1
FP 3
TP 1
Passed
Multicast over IP
This test verified the control and data plane of a multicast protocol in a broadband environment, in a
scenario where the multicast traffic is forwarded over IP.
Table 44 lists the platform configurations, access protocol combinations, feature and traffic profiles
used, and test results. The following test procedure was executed for each unique combination listed in
the table.
Test Procedure
The following steps were performed:
Step 1
Configured the maximum number of VCs supported by the system (for example, 61.5 kbps for PRE-2
and no PXF queueing).
Step 2
Established 1280 PPPoE sessions over which IGMP Join Requests were initiated toward two multicast
groups (640 sessions joining one group and the 640 other sessions joining a second group). Other PPPoA
or PPPoEoA sessions were also brought up, to obtain a total of 30,000 to 40,000 users connected. All
sessions should be brought up with an output service-policy inherited from the virtual template. The
output policy included a single class map with the police action to limit the session output rate. Multiple
virtual template interfaces (such as those used in the bba-group commands) were used with a different
service policy and policer rate applied (for example, 256, 640, and 1280 kbps).
Step 3
Generated downstream multicast traffic toward the two multicast groups the 1280 PPPoE sessions had
joined. The downstream load should not have exceed the session rate nor the interface rate when
replicated over the multicast-enabled receivers’ sessions.
Step 4
Verified that the relevant (S,G) entries were inserted in the multicast routing table. The incoming
interface for these (S,G) entries should have been the uplink interfaces to the IP core.
Step 5
Verified that all multicast sourced packets have been replicated over the 1280 PPPoE sessions. Packets
sourced for each of the two streams should be replicated over 640 sessions.
Step 6
Establish 3000 PPPoE sessions over which IGMP join requests will be initiated toward one single
multicast group. Other PPPoA or PPPoEoA sessions were also brought up, to obtain a total of 30,000 to
40,000 users connected as in Step 2.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
59
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
Performance and Scalability Testing
Step 7
Generated downstream multicast traffic toward the multicast group the 3000 PPPoE sessions had joined.
The downstream load should not have exceeded the session rate nor the interface rate when replicated
over the multicast enabled receivers’ sessions.
Step 8
Verified that the relevant (S,G) entries are inserted in the multicast routing table. The incoming interface
for these (S,G) entries should be the uplink interfaces to the IP core.
Step 9
Verified that all multicast sourced packets were replicated over the 3000 PPPoE sessions.
Expected Results
Multicast control and data traffic are supported in a broadband environment with PPPoX
multicast-enabled receivers.
Results
Table 44 shows the multicast over IP test results. Click a highlighted test identifier in the following table,
or see Table 3, Table 4, Table 5, and Table 6 to interpret the identifiers.
Table 44
Multicast over IP Test Configurations and Results
Platform
Configuration
Access Protocol
Combinations
Feature Profile
Combinations
Traffic Profile
Combination
Result/Reason
R1
A1
FP 3
TP 1
Passed
Performance and Scalability Testing
The primary objective of performance testing is to test and verify the identified operational performance
parameters of the solution within end-to-end functional scenarios. This includes an evaluation to see if
a platform used in a specific deployment model (function and protocol), with a customer representative
set of features turned on and with a certain traffic load, can handle a predefined number of sessions.
The performance testing was defined such that each test case represented a different combination of
platforms, access protocols, feature profile, and traffic profile. For each test case, the same test steps are
executed and the same pass/fail criteria are applied as detailed in the “Test Procedure” and “Expected
Results” sections that follow.
Table 46 lists the test cases that were performed. For each test case, references to the role and platform
set, access protocol mix, and feature and traffic profiles defined previously in this document are
provided. In addition to the system stress introduced by the feature sets and traffic models captured in
Table 46, the performance test cases also verified the capacity of the BBA platforms by applying
maximum scaling parameters (for example, session count) differently based on the platforms being
tested. The maximum scaling parameters to be used throughout the performance test cases are found in
Table 45.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
60
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
Performance and Scalability Testing
Table 45
Cisco 10000 Series Router/PRE 2 Scaling Parameters
Call Setup Rate
PPPoX1
# CPS
80
LAC
PPPoA
# sessions
31,500
L2TP/PPPoX
# tunnels
8000
PPPoEoA
# sessions
31,500
PPPoEoA
# sessions/VC
1
L2TP/PPPoX
# tunnels
8000
PPPoA
# sessions
31,500
PPPoEoA
# sessions
31,500
PPPoEoA
# sessions/VC
1
PTA
1. PPPoX is either PPPoA or PPPoE.
Test Procedure
The following steps were executed for all performance test cases:
Step 1
Configured the test bed for the appropriate test case (see Table 46) and associated scaling parameters
(see Table 45).
To simulate a live environment, 3 percent of the PPP sessions were configured to fail authentication (for
example, by using incorrect passwords), to replicate the churn experienced in a live network. All the tests
described in this section have assumed that this environment has been configured. The remaining 97
percent of the sessions specified carried test traffic.
Step 2
Configured the test tools to generate the appropriate traffic and sessions per Table 45 and Table 46.
Step 3
Monitored router statistics during session startup.
Step 4
Waited for all sessions to come up and started traffic through them, as defined in the performance test
case.
Step 5
Monitored router statistics during the data traffic phase to verify CPU load and memory usage at
1-minute intervals.
Step 6
Captured router statistics during the data traffic phase for troubleshooting purposes at 5-minute intervals.
Step 7
Monitored external devices such as a RADIUS server, a syslog server, and an SNMP server for proper
interaction between test beds.
Step 8
Ran the test for 30 minutes.
Step 9
Collected and examined test tool results to verify the packet drops.
Expected Results
The following pass/fail criteria apply to every performance test case:
•
Features under test function as expected with other related features running in the test cases.
•
Traffic from the traffic generator must traverse from source to destination (both upstream and
downstream) and must take the expected path.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
61
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
Performance and Scalability Testing
•
Packet drops are less than 0.01 percent of the total.
•
All subscriber sessions are brought up successfully and are passing traffic. In case of failed sessions,
retries are attempted and all sessions come up.
•
The performance of each BBA component within the system is within specification indicated by the
following results: reasonable CPU usage and sufficient memory available.
•
No system or feature errors occur during testing, such as router crashes, reloads, CPU hogs,
tracebacks, or memory leaks.
Results
Table 46 shows performance test case results. Click a highlighted test identifier in the following table,
or see Table 3, Table 4, Table 5, and Table 6 to interpret the identifiers.
Table 46
Performance Test Cases and Results—PC 1 Through PC 9
Test
Case
Role/
Access
Platform Protocol
Feature
Profile
Traffic
Profile Test Case Description
Result/Reason
PC 1
R1
A2
FP 1
TP 1
Performance test case
baseline PTA profile
Passed
PC 2
R3
A2
FP 1
TP 1
Performance test case
baseline LAC profile
Passed
PC 3
R1
A2
FP 2
TP 1
Performance test case
FP2 profile
Passed
PC 4
R1
A2
FP 3
TP 1
Performance test case
FP3 profile
Passed
PC 5
R3
A2
FP 4
TP 1
Performance test case
FP4 profile
Passed with exception
(CSCeg01523)
PC 6
R1
A2
FP 5
TP 1
Performance test case
FP5 profile
Passed
PC 7
R3
A2
FP 6
TP 1
Performance test case
FP6 profile
Passed
PC 8
R1
A2
FP 7
TP 1
Performance test case
FP7 profile
Passed
PC 9
R8
A2
FP 8
TP 1
Performance test case
FP8 profile
Passed
Passed with Exception Explanation
CSCeg01523—The first PPPoE Active Discovery Initiation (PADI) packet is dropped with auto-vc
enabled when the PADI does not fit in one ATM cell. In this case, the PPPoE client will need to
retransmit. There is no workaround.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
62
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
Reliability Testing
Reliability Testing
This section describes the reliability testing used to verify that each of the representative BBA
deployment models can endure a series of burn-in tests for a period of 48 hours without any downtime.
Memory usage was carefully monitored throughout the entire test to check for leakages.
The reliability test cases are similar to the performance test cases, but ran for 48 hours instead of
30 minutes.
Table 47 lists the subset of performance test cases that were executed for 48 hours as reliability test
cases.
Test Procedure
The following steps were executed for all reliability test cases:
Step 1
Configured the test bed for the appropriate test case (see Table 46) and associated scaling parameters
(see Table 45)
Step 2
To simulate a live environment, configured 3 percent of the PPP sessions to fail authentication (for
example, by using incorrect passwords), to replicate the churn experienced in the live network. All the
tests described in this section had assumed that this environment had been configured. The remaining
97 percent of the sessions specified carried test traffic.
Step 3
Configured the test tools to generate the appropriate traffic and sessions per Table 45 and Table 46.
Step 4
Monitored router statistics during session startup.
Step 5
Waited for all sessions to come up and started traffic through them, as defined in the performance test
case.
Step 6
Monitored router statistics during the data traffic phase to verify CPU load and memory usage at
1-minute intervals.
Step 7
Captured router statistics during the data traffic phase for troubleshooting purposes at a 5-minute
intervals.
Step 8
Monitored external devices such as a RADIUS server, a syslog server, and an SNMP server for proper
interaction between test beds.
Expected Results
The following pass/fail criteria apply to every reliability test case:
•
Features under test function as expected with other related features running in the test cases.
•
Traffic from the traffic generator must traverse from source to destination (both upstream and
downstream) and must take the expected path.
•
Packet drops are less than 0.01 percent of the total.
•
All subscribers sessions are brought up successfully and are passing traffic. In case of failed
sessions, retries are attempted and all sessions come up.
•
The performance of each BBA component within the system is within specification indicated by the
following results: CPU usage at 80 percent, and sufficient memory available.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
63
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
Negative Testing
•
No system or feature errors occur during testing, such as router crashes, reloads, CPU hogs,
tracebacks, or memory leaks.
Results
Table 47 shows the reliability test results. Click a highlighted test identifier in the following table, or see
Table 46 to interpret the performance test case identifiers.
Table 47
Reliability Test Cases and Results—1 Through 3
Reliability Test
Case
Performance Test
Case
Result/Reason
RC 1
PC 3
Passed
RC 2
PC 5
Passed
RC 3
PC 9
Passed
Negative Testing
Negative testing is done to demonstrate a system’s ability to handle and respond appropriately to adverse
conditions. Such situations include interface flaps, hardware failures, and network failures.
Negative testing was performed with all user sessions active and data traffic running.
Disconnect time was long enough for sessions, tunnels, and routes to go down.
The same pass/fail criteria that applied to performance testing applied to negative testing, along with
some additional test case pass/fail criteria that were specified per test case.
Boot Time
This test measured the time it took to boot a full system configuration after power up.
Table 48 lists the platform configurations, access protocol combinations, feature and traffic profiles
used, and test results. The following test procedure was executed for each unique combination listed in
the table.
Test Procedure
The following step was performed:
•
Measured boot time after power up.
Expected Results
Boot time is within a reasonable time, depending on the configuration.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
64
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
Negative Testing
Results
Table 48 shows the multicast over boot time test results. Click a highlighted test identifier in the
following table, or see Table 3, Table 4, Table 5, and Table 6 to interpret the identifiers.
Table 48
Boot Time Test Configurations and Results
Platform
Configuration
Access Protocol
Combinations
Feature Profile
Combinations
Traffic Profile
Combination
Result/Reason
R1
A2
FP 1
TP 1
Passed
R3
A2
FP 4
TP 1
Passed
R8
A2
FP 8
TP 1
Passed
PRE Failover
This test tested the stability and recovery capability of the system after a primary Performance Routing
Engine (PRE) failure and extraction.
Table 49 lists the platform configurations, access protocol combinations, feature and traffic profiles
used, and test results. The following test procedure was executed for each unique combination listed in
the table.
Test Procedure
The following steps were performed:
Step 1
Measured PRE failover time after primary PRE failure and extraction.
Step 2
Measured PRE failover time after a primary PRE reinsertion.
Expected Results
After a primary PRE failure and extraction, a secondary PRE assumes the entire configuration and
forwards all existing traffic. The PRE recovers from secondary to primary after the primary PRE
reinsertion (second failover).
Results
Table 49 shows the PRE failover test results. Click a highlighted test identifier in the following table, or
see Table 3, Table 4, Table 5, and Table 6 to interpret the identifiers.
Table 49
PRE Failover Test Configurations and Results
Platform
Configuration
Access Protocol
Combinations
Feature Profile
Combinations
Traffic Profile
Combination
R1
A2
FP 1
TP 1
Result/Reason
Passed with exception
(CSCee50060)
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
65
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
Negative Testing
Table 49
PRE Failover Test Configurations and Results (Continued)
R3
A2
FP 4
TP 1
Passed
R8
A2
FP 8
TP 1
Passed
Passed with Exception Explanation
CSCee50060—A Cisco 10000 router with PPPoA VCs may under abnormal scenarios (such as a
denial-of-service (DoS) attack involving the sending of PPPoA data packets prior to PPPoA session up)
experience heavy RP CPU usage. A Cisco 10000 router with PPPoA VCs may forward PPPoA data
packets for nonexistent sessions. These symptoms occur only when PPPoA data traffic is sent prior to
the session reaching the PTA forwarded state. A normal PPPoA client will not send traffic before a
session is up. A workaround is to configure reverse path forwarding (RPF) on all ATM subinterfaces
containing PPPoA sessions. The subinterface should have an RPF check in addition to use of RPF check
in the virtual template. Configuring RPF on the subinterface will force all PPPoA data traffic to be
dropped by the PXF prior to the session reaching the PTA forward state.
Further Problem Description: Heavy RP CPU usage in this scenario is identified by large numbers of
packets punted with the glean state. The heavy RP CPU usage scenario is remotely probable only after
failover, because typically the upstream adjacency will be resolved. The heavy RP CPU usage scenario
has been observed in the laboratory, during negative testing.
Line Card OIR
This test verified the stability and recovery capability of the system after the reset, extraction, and
insertion of a line card.
Table 50 lists the platform configurations, access protocol combinations, feature and traffic profiles
used, and test results. The following test procedure was executed for each unique combination listed in
the table.
Test Procedure
The following steps were performed:
Step 1
Tested system recovery after the reset, extraction, and insertion of the ATM line card.
Step 2
Tested system recovery after the reset, extraction, and insertion of the GE line card.
Expected Results
All the services for the line card that have been reset are down; however, this condition must not affect
the other interfaces and service of the box.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
66
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
Negative Testing
Results
Table 50 shows the line card OIR test results. Click a highlighted test identifier in the following table,
or see Table 3, Table 4, Table 5, and Table 6 to interpret the identifiers.
Table 50
Line Card OIR Test Configurations and Results
Platform
Configuration
Access Protocol
Combinations
Feature Profile
Combinations
Traffic Profile
Combination
Result/Reason
R1
A1
FP 2
TP 1
Passed
R1
A2
FP 2
TP 1
Passed
ATM Link Failures
This test verified the router’s ability to handle interface flaps toward the aggregation side of the network.
Table 51 lists the platform configurations, access protocol combinations, feature and traffic profiles
used, and test results. The following test procedure was executed for each unique combination listed in
the table.
Test Procedure
The following steps were performed:
Step 1
The physical connection toward subscribers was disconnected and reconnected.
Step 2
The shutdown and no shutdown commands were used on the ATM interface toward subscribers.
Expected Results
After executing test steps, all sessions come up.
Results
Table 51 shows the ATM link failures test results. Click a highlighted test identifier in the following
table, or see Table 3, Table 4, Table 5, and Table 6 to interpret the identifiers.
Table 51
ATM Link Failures Test Configurations and Results
Platform
Configuration
Access Protocol
Combinations
Feature Profile
Combinations
Traffic Profile
Combination
Result/Reason
R1
A1
FP 2
TP 1
Passed
R1
A2
FP 2
TP 1
Passed
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
67
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
Negative Testing
RADIUS Server Failures
This test tested the stability and recovery capability of the system after a disconnect and reconnect of the
RADIUS server.
Table 52 lists the platform configurations, access protocol combinations, feature and traffic profiles
used, and test results. The following test procedure was executed for each unique combination listed in
the table.
Test Procedure
The following steps were performed:
Step 1
The connection between the LAC and the RADIUS server (tunnel authorization) was disconnected and
reconnected.
Step 2
The connection between the PTA and the RADIUS server (user authentication) was disconnected and
reconnected.
Step 3
The connection between the LAC/PTA and accounting RADIUS server was disconnected and
reconnected.
Expected Results
After executing test cases, all sessions come up.
Results
Table 52 shows the RADIUS server failures test results. Click a highlighted test identifier in the
following table, or see Table 3, Table 4, Table 5, and Table 6 to interpret the identifiers.
Table 52
RADIUS Server Failures Test Configurations and Results
Platform
Configuration
Access Protocol
Combinations
Feature Profile
Combinations
Traffic Profile
Combination
Result/Reason
R3
A2
FP 4
TP 1
Passed
R1
A2
FP 5
TP 1
Passed with
exception
(CSCef63332)
Passed with Exception Explanation
CSCef63332—Cisco IOS should purge long outstanding RADIUS accounting packets when
input/output memory (IOMEM) is low. In a situation where RADIUS accounting servers are either down
or excessively slow, RADIUS accounting packets can accumulate in the Cisco IOS router. There is no
workaround.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
68
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
Negative Testing
L2TP Tunnel Failures
This test tested the stability of the system when all L2TP tunnels were cleared and recovered again.
Table 53 lists the platform configurations, access protocol combinations, feature and traffic profiles
used, and test results. The following test procedure was executed for each unique combination listed in
the table.
Test Procedure
The following step was performed:
•
Connections between the LAC and the LNS were disconnected and reconnected .
Expected Results
After executing the test step, all sessions come up.
Results
Table 53 shows the L2TP tunnel failure test results. Click a highlighted test identifier in the following
table, or see Table 3, Table 4, Table 5, and Table 6 to interpret the identifiers.
Table 53
L2TP Tunnel Failure Test Configurations and Results
Platform
Configuration
Access Protocol
Combinations
Feature Profile
Combinations
Traffic Profile
Combination
Result/Reason
R3
A2
FP 1
TP 1
Passed
Route Flapping
This test verified the router’s ability to handle interface and route flaps toward the core side.
Table 54 lists the platform configurations, access protocol combinations, feature and traffic profiles
used, and test results. The following test procedure was executed for each unique combination listed in
the table.
Test Procedure
The following step was performed:
•
The connection toward the core was disconnected and reconnected.
Expected Results
After executing the test step, all routes come back.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
69
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
Negative Testing
Results
Table 54 shows the route flapping test results. Click a highlighted test identifier in the following table,
or see Table 3, Table 4, Table 5, and Table 6 to interpret the identifiers.
Table 54
Route Flapping Test Configurations and Results
Platform
Configuration
Access Protocol
Combinations
Feature Profile
Combinations
Traffic Profile
Combination
Result/Reason
R1
A2
FP 2
TP 1
Passed
R8
A2
FP 8
TP 1
Passed
Storm of PPPoX Sessions
This test tested the stability of the system when PPPoX sessions were sent to the system at a high rate.
Table 55 lists the platform configurations, access protocol combinations, feature and traffic profiles
used, and test results. The following test procedure was executed for each unique combination listed in
the table.
Test Procedure
The following step was performed:
•
PPPoE sessions were generated at a high rate and sent to the router.
Expected Results
Existing sessions stay up and forward traffic.
Results
Table 55 shows the storm of PPPoX sessions test results. Click a highlighted test identifier in the
following table, or see Table 3, Table 4, Table 5, and Table 6 to interpret the identifiers.
Table 55
Storm of PPPoX Sessions Test Configurations and Results
Platform
Configuration
Access Protocol
Combinations
Feature Profile
Combinations
Traffic Profile
Combination
Result/Reason
R1
A2
FP 2
TP 1
Passed
R3
A2
FP 4
TP 1
Passed
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
70
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
Provisioning and Manageability Testing
Provisioning and Manageability Testing
This test suite simulated daily operations typically done by a system administrator. This test tested the
ability of the system to add, delete, or modify existing configurations, user profiles, and class of traffic
parameters while the system was live with active traffic. In addition, the integrity and stability of the
system must have remained intact while being accessed by multiple Telnet sessions, and by either single
or multiple users performing typical system administrative operations.
Test Procedure
The following steps were performed for the provisioning and manageability test:
Step 1
Added and deleted subscribers, both individually and in bulk (3 percent).
Step 2
Added, deleted, and modified class of traffic parameters.
Step 3
Configured updates from multiple locations with multiple users.
Expected Results
•
Subscribers are added and removed accordingly, both individually as well as in bulk.
•
Class of traffic parameters are modified accordingly.
•
Configuration updates are feasible from multiple locations with multiple users.
•
Traffic from the traffic generator must traverse from source to destination (both upstream and
downstream) and must take the expected path.
•
Packet drops are less than 0.01 percent.
•
All subscriber sessions are brought up successfully and pass traffic. In case of failed sessions, retries
are attempted and all sessions come up.
•
The performance of each BBA component within the system is within specification, as indicated by
reasonable CPU usage and sufficient available memory.
•
No system or feature errors occur during testing, such as router reloads, CPU hogs, tracebacks, and
memory leaks.
Results
Table 56 shows the provisioning and manageability test results. Click a highlighted test identifier in the
following table, or see Table 3, Table 4, Table 5, and Table 6 to interpret the identifiers.
Table 56
Provisioning and Manageability Test Configurations and Results
Platform
Configuration
Access Protocol
Combinations
Feature Profile
Combinations
Traffic Profile
Combination
Result/Reason
R1
A2
FP 2
TP 1
Passed
R3
A2
FP 4
TP 1
Passed
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
71
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
Supplementary Information
Supplementary Information
This section provides the following supplementary information about BBA testing:
•
Default Template
•
Glossary
Default Template
This section contains a listing of the default template used in the BBA testing:
!
vpdn enable
no vpdn logging
vpdn search-order domain
!
ip subnet-zero
no ip gratuitous-arps
ip ftp username nsite
ip ftp password nsite
ip domain list nsite.cisco.com
ip name-server 10.52.128.30
!
no cdp run
!
no logging console
logging rate-limit console 10 except errors
!
no virtual-template snmp
!
no ip gratuitous-arps
!
radius-server retransmit 5
radius-server timeout 15
!
ntp clock-period 17179773
ntp server 10.52.128.30
!
vpdn enable
!
vpdn-group pppoe
accept-dialin
protocol pppoe
virtual-template 2
pppoe limit per-mac 1
pppoe limit per-vc 1
!
interface virtual-template1
description vtemp for PPPoA
no logging event link-status
no peer default ip address
ppp authentication chap
ip unnumbered <interface>
idle-timeout 120
ppp ipcp address required
ppp ipcp address unique
!
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
72
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
Supplementary Information
interface virtual-template2
description vtemp for PPPoE
no logging event link-status
no peer default ip address
ppp authentication chap
ip unnumbered <interface>
mtu 1492
idle timeout 120
ppp ipcp address required
ppp ipcp address unique
!
!
! routing protocol
!
! use OSPF
!
! ACLs for management access into the router
!
access-list 100 permit icmp any any echo
access-list 100 permit tcp 172.31.0.0 0.0.255.255 any eq telnet
access-list 100 permit tcp 10.52.0.0 0.0.255.255 any eq telnet
access-list 100 permit tcp 172.31.0.0 0.0.255.255 any eq 22
access-list 100 permit tcp 10.52.0.0 0.0.255.255 any eq 22
access-list 100 deny
ip any any
!
! limit telnet access using ACLs above
!
line vty 0 4
access-class 100 in
!
! syslog configuration
!
logging 10.52.128.46
logging buffered
logging console debugging
!
! SNMP
!
snmp-server community public RO
snmp-server community private RW
snmp-server host 10.52.128.46 public
snmp-server enable traps
!
! AAA
!
aaa new-model
aaa authentication login TELNETUSER group tacacs+ local
aaa authentication login NO_AUTH none
aaa authorization exec TELNETUSER group tacacs+ local
aaa authorization exec NO_AUTH none
aaa accounting exec TELNETUSER start-stop group tacacs+
tacacs-server host 10.52.128.46 key nEverest
aaa authentication ppp default local group radius
aaa authorization network default local group radius
aaa session-id common
line con 0
authorization exec NO_AUTH
login authentication NO_AUTH
line vty 0 4
authorization exec TELNETUSER
login authentication TELNETUSER
accounting exec TELNETUSER
!
ACCOUNTING for sessions
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
73
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
Glossary
!
aaa group server radius ACCOUNTING
server-private 10.52.133.4 auth-port 1645 acct-port 1646 key ww
aaa accounting network default start-stop group ACCOUNTING
aaa accounting network default start-stop group radius
aaa accounting system default start-stop group radius
aaa session-id common
!
RADIUS server
!
!
radius-server attribute nas-port format d
radius-server attribute 4 nrp
radius-server host 10.52.133.4 auth-port 1645 acct-port 1646 key ww
radius-server retransmit 5
radius-server timeout 25
radius-server deadtime 30
radius-server authorization permit missing Service-Type
radius-server vsa send accounting
radius-server vsa send authentication
!
Glossary
AAL5—ATM Adaptation Layer 5
AIS/RDI—alarm indication signal/remote defect indication
ACL—access control list
API—application programming interface
AR—Access-Request server
ATM—Asynchronous Transmission Mode
BBA—broadband aggregation
BGP—Border Gateway Protocol
BPDU—Bridge Protocol Data Units
CDVT—cell delay variation tolerance
CHAP—Challenge Handshake Authentication Protocol
CLI—command-line interface
CPE—customer premises equipment
DBS—Dynamic Bandwidth Setting
DHCP—Dynamic Host Configuration Protocol
DSL—digital subscriber line
DSLAM—digital subscriber line access multiplexer
FE—Fast Ethernet
GE—Gigabit Ethernet
GRE—Generic Routing Encapsulation
HDVRF—half-duplex virtual routing and forwarding
ICMP—Internet Control Message Protocol
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
74
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
Glossary
IGMP—Internet Group Management Protocol
IPCP—IP Control Protocol
IMIX—Internet mix
ISP—Internet service provider
L2TP—Layer 2 Tunneling Protocol (per RFC 2661)
LAC—L2TP access concentrator
LCP—Link Control Protocol
LDP—Label Distribution Protocol
LNS—L2TP network server
MIB—Management Information Base
MPLS—Multiprotocol Label Switching
OAM—Operation, Administration, and Maintenance
OC—optical carrier
PADI—PPPoE Active Discovery Initiation
PCR—peak cell rate
PIM—Protocol Independent Multicast
PoD—Packet of Disconnect
POS—Packet over SONET
PPP—Point-to-Point Protocol
PPPoA—PPP over AAL5
PPPoE—PPP over Ethernet
PPPoX—PPPoA or PPPoE
PRE—Performance Routing Engine
PTA—PPP termination aggregation
PVC—permanent virtual circuit
PXF—Parallel Express Forwarding
RADIUS—Remote Authentication Dial-In User Service
RP—Route Processor or rendezvous point
SCR—sustainable cell rate
SESM—Subscriber Edge Services Manager
SID—Session ID for L2TP tunnel session
SNAP—Subnetwork Access Protocol
SSG—Service Selection Gateway
SSS—Subscriber Service Switch
TACACS+—Terminal Access Controller Access Control System Plus
TFTP—Trivial File Transfer Protocol
TID—Tunnel ID (for L2TP tunnel)
tty—terminal line
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
75
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
Glossary
UBR—unspecified bit rate
UPC—usage parameter control
URPF—Universal Reverse Path Forwarding
VC—virtual circuit
VCI—virtual circuit identifier
VP—virtual path
VPDN—virtual private dial network
VPI—virtual path identifier
VPN—Virtual Private Network
VRF—VPN routing and forwarding
VSA—Vendor Specific Attribute
CCSP,
CCSP, CCVP,
CCVP, the
the Cisco
Cisco Square
Square Bridge
Bridge logo,
logo, Follow
Follow Me
Me Browsing,
Browsing, and
and StackWise
StackWise are
are trademarks
trademarks of
of Cisco
Cisco Systems,
Systems, Inc.;
Inc.; Changing
Changing the
the Way
Way We
We Work,
Work,
Live,
Live, Play,
Play, and
and Learn,
Learn, and
and iQuick
iQuick Study
Study are
are service
service marks
marks of
of Cisco
Cisco Systems,
Systems, Inc.;
Inc.; and
andAccess
Access Registrar,
Registrar,Aironet,
Aironet,ASIST,
ASIST, BPX,
BPX, Catalyst,
Catalyst, CCDA,
CCDA, CCDP,
CCDP,
CCIE,
CCIE, CCIP,
CCIP, CCNA,
CCNA, CCNP,
CCNP, Cisco,
Cisco, the
the Cisco
Cisco Certified
Certified Internetwork
Internetwork Expert
Expert logo,
logo, Cisco
Cisco IOS,
IOS, Cisco
Cisco Press,
Press, Cisco
Cisco Systems,
Systems, Cisco
Cisco Systems
Systems Capital,
Capital, the
the
Cisco
Cisco Systems
Systems logo,
logo, Cisco
Cisco Unity,
Unity, Empowering
Empowering the
the Internet
Internet Generation,
Generation, Enterprise/Solver,
Enterprise/Solver, EtherChannel,
EtherChannel, EtherFast,
EtherFast, EtherSwitch,
EtherSwitch, Fast
Fast Step,
Step, FormShare,
FormShare,
GigaDrive,
GigaDrive, GigaStack,
GigaStack, HomeLink,
HomeLink, Internet
Internet Quotient,
Quotient, IOS,
IOS, IP/TV,
IP/TV, iQ
iQ Expertise,
Expertise, the
the iQ
iQ logo,
logo, iQ
iQ Net
Net Readiness
Readiness Scorecard,
Scorecard, LightStream,
LightStream, Linksys,
Linksys,
MeetingPlace,
MeetingPlace, MGX,
MGX, the
the Networkers
Networkers logo,
logo, Networking
NetworkingAcademy,
Academy, Network
Network Registrar,
Registrar, Packet,
Packet, PIX,
PIX, Post-Routing,
Post-Routing, Pre-Routing,
Pre-Routing, ProConnect,
ProConnect, RateMUX,
RateMUX,
ScriptShare,
ScriptShare, SlideCast,
SlideCast, SMARTnet,
SMARTnet, StrataView
StrataView Plus,
Plus, TeleRouter,
TeleRouter, The
The Fastest
Fastest Way
Way to
to Increase
IncreaseYour
Your Internet
Internet Quotient,
Quotient, and
and TransPath
TransPath are
are registered
registered
trademarks
trademarks of
of Cisco
Cisco Systems,
Systems, Inc.
Inc. and/or
and/or its
its affiliates
affiliates in
in the
the United
United States
States and
and certain
certain other
other countries.
countries.
All
All other
other trademarks
trademarks mentioned
mentioned in
in this
this document
document or
or Website
Website are
are the
the property
property of
of their
their respective
respective owners.
owners. The
The use
use of
of the
the word
word partner
partner does
does not
not imply
imply aa
partnership
partnership relationship
relationship between
between Cisco
Cisco and
and any
any other
other company.
company. (0502R)
(0502R)
Copyright © 2005 Cisco Systems, Inc. All rights reserved.
Cisco IOS Profiled Release 12.3(7)XI3 Testing for Service Provider Broadband (DSL) Customers
76