LOCKED-ASR 5500-EPC-Product-Suite-System-Administration and Configuration-PT1 PDF

ASR 5500 EPC Product Suite System
Administration and Configuration

Part 1
06-13-2013
Version Number 14.0
Americas Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
http://www.cisco.com
Tel: 408 526-4000
800 553-NETS (6387)
Fax: 408 527-0883
Cisco Proprietary and Confidential

Do Not Distribute
THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS,
INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED
WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED
WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.
The following information is for FCC compliance of Class A devices: This equipment has been tested and found to comply with the limits for a Class A digital device, pursuant to part 15
of the FCC rules. These limits are designed to provide reasonable protection against harmful interference when the equipment is operated in a commercial environment. This equipment
generates, uses, and can radiate radio-frequency energy and, if not installed and used in accordance with the instruction manual, may cause harmful interference to radio communications.
Operation of this equipment in a residential area is likely to cause harmful interference, in which case users will be required to correct the interference at their own expense.
The following information is for FCC compliance of Class B devices: This equipment has been tested and found to comply with the limits for a Class B digital device, pursuant to part 15
of the FCC rules. These limits are designed to provide reasonable protection against harmful interference in a residential installation. This equipment generates, uses and can radiate radio
frequency energy and, if not installed and used in accordance with the instructions, may cause harmful interference to radio communications. However, there is no guarantee that
interference will not occur in a particular installation. If the equipment causes interference to radio or television reception, which can be determined by turning the equipment off and on,
users are encouraged to try to correct the interference by using one or more of the following measures:
Reorient or relocate the receiving antenna.
Increase the separation between the equipment and receiver.
Connect the equipment into an outlet on a circuit different from that to which the receiver is connected.
Consult the dealer or an experienced radio/TV technician for help.
Modifications to this product not authorized by Cisco could void the FCC approval and negate your authority to operate the product.
The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCBs public domain version
of the UNIX operating system. All rights reserved. Copyright 1981, Regents of the University of California.
NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED AS IS WITH ALL
FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE
PRACTICE.
IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT
LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS
HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at
www.cisco.com/go/trademarks. [Insert any required attribution of a third party mark.] [Other] Third party trademarks mentioned are the property of their respective owners. The use of
the word partner does not imply a partnership relationship between Cisco and any other company.
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output,
network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is
unintentional and coincidental.
ASR 5500 EPC Product Suite System Administration And Configuration
2013 Cisco Systems, Inc. and/or its affiliated entities. All rights reserved.

Do Not Distribute
Table of Contents
Lesson 1: LTE Overview
1-1
Lesson 2: Cisco ASR 5500 Hardware Architecture
2-1
Lesson 3: Cisco ASR 5500 Software Architecture
3-1
Lesson 4: Initial System Configuration
4-1
Lesson 5: StarOS CLI and Global Configuration Setttings
5-1
Lab 1 - Introduction to the CLI Hardware Overview
5-65
Lesson 6: Cisco ASR 5500 Configuration Terminology

Lab 2 Creating Contexts and Configuring IP Interfaces and Ports
6-1
6-73

Do Not Distribute

Do Not Distribute
LTE Overview
Lesson 1
2010 Cisco and/or its affiliates. All rights reserv ed. Cisco Conf idential

Do Not Distribute
1-1
Module Overview
In 4G the GSM technology is called LTE-SAE (Long Term Evolution)-(System
Architecture Evolution).
LTE which is introduced in 3GPP Release 8, is the next major step in mobile radio
communications-Evolved 3GPP Packet Switched Domain-also known as the
Evolved Packet System (EPS). The Evolved 3GPP Packet Switched Domain
provides IP connectivity using the Evolved Universal Terrestrial Radio Access
Network (E-UTRAN). LTE is comprised of two major elements; The E-UTRAN
(Evolved UMTS Radio Access Network and the Evolved Packet Core (EPC).
In addition to LTE, 3GPP has specified a flat, IP-based network architecture as part
of the system architecture evolution (SAE) effort. The aim and design of the LTESAE and concepts are to efficiently support mass-market usage of any IP-based
service. The architecture is based on, and evolved from, existing GSM-WCDMA
core networks to facilitate simplified operations.
On the opposite page is a basic 4G-network diagram for LTE-SAE which depicts a
non-roaming architecture for 3GPP access.
1-2

Do Not Distribute
Module Overview
Describe the following Network Elements and
Interfaces that are used in the LTE-SAE
Environment:
Evolved UTRAN (ENodeB))
Mobility Management Entity (MME)
Serving Gateway (S-GW)
PDN Gateway (P-GW)

Do Not Distribute
1-3
LTE Components
In 4G the GSM technology is called LTE-SAE (Long Term Evolution)-(System
Architecture Evolution).
LTE which is introduced in 3GPP Release 8, is the next major step in mobile radio
communications-Evolved 3GPP Packet Switched Domain-also known as the
Evolved Packet System (EPS). The Evolved 3GPP Packet Switched Domain
provides IP connectivity using the Evolved Universal Terrestrial Radio Access
Network (E-UTRAN). LTE is comprised of two major elements; The E-UTRAN
(Evolved UMTS Radio Access Network and the Evolved Packet Core (EPC).
In addition to LTE, 3GPP has specified a flat, IP-based network architecture as part
of the system architecture evolution (SAE) effort. The aim and design of the LTESAE and concepts are to efficiently support mass-market usage of any IP-based
service. The architecture is based on, and evolved from, existing GSM-WCDMA
core networks to facilitate simplified operations.
On the opposite page is a basic 4G-network diagram for LTE-SAE which depicts a
non-roaming architecture for 3GPP access.
1-4

Do Not Distribute
LTE Components
UTRAN
SGSN
GERAN
HSS
S3
S6a
S1-MME
MME
PCRF
S11
S10
LTE-Uu
UE
S12
Serving
Gateway
E-UTRAN
Rx+
Gx
S4
S5
PDN
Gateway
SGi
Enterprise
Network
S1 - U

Do Not Distribute
1-5
Functions of the Evolved UTRAN (eNodeB)

The eNodeB supports the LTE air interface and includes functions for radio access
control, user plane ciphering, and Packet Date Convergence Protocol (PDCP).
eNodeB devices are connected to other eNodeB devices via the XT interface which
is not shown on the diagram.
eNodeB functions include:
Functions for Radio Resource Management (RRM), Radio Bearer Control (RBC),
Radio Admission Control (RAC), Connection Mobility Control (RMC), dynamic
allocation of resources to UEs in both uplink (UL) and downlink (DL) scheduling;
IP header compression and encryption of the user data stream;
Selection of a Mobility Management Entity (MME) at UE attachment when no routing
to an MME can be determined from the information provided by the UE;
Routing of User Plane data towards a Serving Gateway (S-GW);
Scheduling and transmission of paging messages originated from the MME;
Scheduling and transmission of broadcast information originated from the MME or
O&M;
Measurement and measurement reporting configuration for mobility and scheduling.
1-6

Do Not Distribute
Functions of the E-UTRAN (eNodeB)

eNodeB the LTE air interface includes:
RRC Radio Resource Control
RAC Radio Admission Control
UTRAN
RBC Radio Bearer Control

RRM Radio Resource Management
SGSN
PDCP Packet Data Convergence Protocol
GERAN
Dynamic Allocation of resources to UE
HSS
Routing user data to the S-GW
S3
S6a
S1-MME
MME
PCRF
S11
S10
LTE-Uu
UE
S12
Serving
Gateway
E-UTRAN
Rx+
Gx
S4
S5
PDN
Gateway
SGi
Enterprise
Network
S1 - U

Do Not Distribute
1-7
Functions of the Mobility Management Entity (MME) and Supported Interfaces

The MME is the key control node for the LTE access network. The MME manages
mobility, UE identities and security parameters. MME functions include:
Non Access Stratum (NAS) signaling;
NAS signaling security
Inter Core Node (CN) signaling for mobility between 3GPP access networks;
(terminating S3)
Idle mode UE reachability including control and execution of paging retransmission);
Tracking Area list management (for UE in idle and active mode);
P-GW and S-GW selection;
MME selection for handover with MME change;
SGSN selection for handovers to 2G or 3G access networks;
Roaming; (terminating S6a towards Home Subscriber Server (HSS);
Authentication;
Bearer management functions including dedicated bearer establishment
Interfaces/Reference Points of the MME
S1-MME
Reference point for the control plane protocol between the EUTRAN and the MME.
S1-U Reference point between the E-UTRAN and the S-GW for the per
user plane tunneling and inter eNodeB path switching during handover.
bearer
S3
Enables bearer and user information exchange for inter 3GPP
access
network mobility in idle or active state. It is based on Gn
reference point as
defined between SGSNs.
S10 Reference point between MMEs for MME relocation and MME to
Information transfer.
S11
1-8
MME
Reference point between MME and S-GW

Do Not Distribute
Functions of the MME and Supported

Interfaces
MME manages mobility, UE identities and security
parameters and includes:
NAS Non Access Stratum signaling
UTRAN
NAS Non Access Stratum signaling security

Idle mode UE reachability
SGSN
Tracking Area List management (UE idle and active)
GERAN
P-GW and S-GW selection
HSS
Authentication
S3
S6a
S1-MME
EPS bearer management
MME
PCRF
S11
S10
LTE-Uu
UE
S12
Serving
Gateway
E-UTRAN
Rx+
Gx
S4
S5
PDN
Gateway
SGi
Enterprise
Network
S1 - U

Do Not Distribute
1-9
Function of the Serving Gateway (S-GW)and Supported Interfaces

The Serving Gateway is the node that terminates the interface towards E-UTRAN.
For each UE associated with the EPS, at a given point in time, there is one single SGW. The S-GW functions include:
The local Mobility Anchor for inter-eNodeB handover;
Mobility anchoring for inter-3GPP mobility; terminating S4 and relaying the traffic
between 2G and 3G system and PDN Gateway (P-GW). This is sometimes referred
to as the 3GPP Anchor function
E-UTRAN idle mode downlink packet buffering and initiation of network triggered
service request procedure;
Lawful Interception;
Packet routing and forwarding;
Transport level packet marking in the uplink and downlink;
Accounting on user and QOS Class Identifier (QCI) granularity for inter-operator
charging;
UL and DL charging per UE, PDN, and QCI
Interfaces/Reference Points of the S-GW
S4
Provides related control and mobility support between GPRS
Core and
the
3GPP Anchor function of the S-GW and is based on Gn
reference point
as defined between SGSN and GGSN. Provides user plane tunneling when direct
tunnel is not established.
S5
Provides user plane tunneling and tunnel management between S- GW and
P-GW. It used for S-GW relocation due to UE mobility and if the S-GW needs to
connect to a non-collated PGW for the required
PDN connectivity.
S8a
Inter-PLMN reference point providing user and control plane between the
Serving GW in the VPLMN and the PDN GW in the HPLMN. It is based on
Gp reference point as defined between SGSN and GGSN. S8a is the inter PLMN
variant of S5.
S12 Reference point between UTRAN and Serving GW for user plane tunneling
when Direct Tunnel is established. It is based on the Iu-/Gn- u reference point using
the GTP-U protocol as defined between SGSN and UTRAN or respectively between
SGSN and GGSN.
1-10

Do Not Distribute
Functions of the S-GW and Supported

Interfaces
S-GW local mobility anchor point for inter eNodeB
handover it includes:
E-UTRAN Idle mode downlink packet buffering
UTRAN
Packet routing and forwarding

Transport level packet marking for UL and DL
SGSN
GERAN
Accounting on user and QoS Class Identifier (QCI)
HSS
UL and DL charging per UE, PDN, and QCI
S3
S6a
S1-MME
MME
PCRF
S11
S10
LTE-Uu
UE
S12
Serving
Gateway
E-UTRAN
Rx+
Gx
S4
S5
PDN
Gateway
SGi
Enterprise
Network
S1 - U

Do Not Distribute
11
1-11
Functions of the Packet Data Network Gateway (P-GW)and Supported

Interfaces
The PDN Gateway is the node that terminates the SGi interface towards the PDN. If
a UE is accessing multiple PDNs, there may be more than one P-GW for that UE.
The P-GW provides connectivity to the user to external Packet Data Networks by
being the point of exit and entry of traffic for the UE. A UE may have simultaneous
connectivity to more than one P-GW for accessing multiple PDNs. The P-GW
functions include:
Mobility anchor for mobility between 3GPP access systems; This is sometime
referred to as the SAE anchor function
Policy enforcement; (gating and rate enforcement)
Per-user based packet filtering; (by e.g. deep packet inspection)
Charging support;
Lawful Interception;
UE IP address allocation;
Packet screening;
Transport level packet marking in the downlink;
Downlink rate enforcement based on Aggregate Maximum Bit Rate (AMBR)
Interfaces/Reference Points of P-GW
SGi It is the reference point between the PDN GW and the packet
data
network.
Packet data network may be an operator external
public or private
packet data network or an intra operator packet
data network, e.g. for
provision of IMS services. This reference
point corresponds to Gi for 3GPP
accesses.
Gx
Provides transfer of (QoS) policy and charging rules from PCRF to Policy
and Charging Enforcement Function (PCEF) in the PDN GW.
The interface is
based on the Gx interface.
Rx+
1-12
The Rx reference point resides between the AF and the PCRF in the
3GPP TS 23.203.

Do Not Distribute
Functions of the P-GW and Supported

interfaces
P-GW is the point of entry and exit for
network traffic of the UE it includes:
UE IP address allocation
UTRAN
Policy enforcement
Charging support
SGSN
Per user based packet filtering (DPI)
GERAN
DL rate enforcement based on AMBR
HSS
Transport level marking in the DL
S3
S6a
S1-MME
MME
PCRF
S11
S10
LTE-Uu
UE
S12
Serving
Gateway
E-UTRAN
Rx+
Gx
S4
S5
PDN
Gateway
SGi
Enterprise
Network
S1 - U

Do Not Distribute
13
1-13
1-14
14

Do Not Distribute
Cisco ASR 5500

Hardware Architecture
Lesson 2

Do Not Distribute
2-1
Module Agenda
In this Lesson we will detail the Hardware of the Aggregation Services Router 5500
(ASR 5500). This Lesson provides an overview of the chassis and its components
including the Switch Fabric.
Chassis Architecture
Management and IO Module Architecture (MIO)
Data Processing Card (DPC)
System Status Card (SSC)
Fabric and Storage Card (FSC)
Hardware Flow
2-2

Do Not Distribute
Module Agenda
Connecting to the LAB
Hardware Flow and Switch Fabric
1_1-3

Do Not Distribute
2-3
Lab Architecture
For the purposes of this training class, we are going to use an ASR 5500 dedicated
to this training class.
Remote access to the ASR 5500 will be accomplished in one of two ways:
Using a VPN router
Using SSH through Ciscos firewall
The addresses you need to know are displayed in the slide. The most popular
terminal emulators are Putty, Hummgingbird, or SecureCRT.
Follow the instructors advice as to which access method you will use.
Once attached the rest of the drawing is what will be configured during the week.
We have a variety of simulators for Diameter as the PCRF, Enode B for the client,
and MME to support the control plane of the call.
There also a variety on ports and interfaces required to move data or control
information, each will be discussed and configured as we continue through this
module.
2-4

Do Not Distribute
Lab Architecture
192.168.x.x
Simulator
MINID
PCRF
192.168.5.10
Simulator
192.168.10.3
LATTICE
eNodeB
Simulator
S1-mme
S6a
192.168.7.100
HSS
MME
local ctx
Internet
ASR5500
198.135.1.173
S11 int.
egtp service
S1-U int.
sgw service
7.1x1
pgw service
SGi int.
2.1x1
apn
5.x
10.1.x.4
S5 int.
3.1x1
destination ctx
Address pool
Gx int.
IMS Auth Service
egtp service
egtp service
S5 int.
S8 int
spgw ctx
1_1-5

Do Not Distribute
2-5
Establishing Remote CLI Access
2-6

Do Not Distribute
Establishing remote CLI access

Classroom ASR 5500 can be accessed using the
following:
Using Firewall access:
IP address: (ask instructor for complete address)
User: admin
Password: starent
Using SSH, start your preferred terminal emulator

program and connect to the ASR 5500.
1_1-7

Do Not Distribute
2-7
Using Putty for Access

In the example we are using Putty as our SSH client. You can use any SSH client
that you would like. The most popular terminal emulators are Putty, Hummgingbird,
or SecureCRT.
2-8

Do Not Distribute
Using Putty for Access
1_1-9

Do Not Distribute
2-9
Module Agenda
In this Lesson we will detail the Hardware of the Aggregation Services Router 5500
(ASR5500). This Lesson provides an overview of the chassis and its components
including the Switch Fabric.
Hardware Flow
2-10

Do Not Distribute
Lesson Agenda
Connecting to the Lab
Hardware Flow and Switch Fabric
1_1-11

Do Not Distribute
2-11
ASR 5500 FRUs

The ASR5500 is a 21 RU (Rack Unit) height chassis and is designed around a
midplane architecture. The ASR5500 relies on the midplane architecture to
communicate and manage function and connectivity of each of the module
components.
There are a total of 20 slots, 10 in the front, and 10 in the rear of the chassis.
Power Filter Units are located on the top and extend from front to back
There are 4 fan trays moving air from the bottom front and out through the top
back. Fan trays a located top and bottom of the front and back of the chassis.
2-12

Do Not Distribute
ASR 5500 FRUs

Front fan tray
Front-toback airflow
Power Filter Units
Rear fan tray
21 RU
Rear fan tray

Air intake
Front
Rear
1_1-13

Do Not Distribute
2-13
ASR 5500 Slot Numbering

On the ASR 5500, the slot numbering starts from the back of the chassis numbering
the ten modules 1-10 from left to right, and continues on the front of the chassis 1120.
This is illustrated on the slide on the opposite page.
2-14

Do Not Distribute
ASR 5500 Slot Numbering

Front fan tray
Front-toback airflow
Power Filter Units
Rear fan tray
11 12 13 14 15 16 17 18 19 20
1 2 3 4 5 6 7 8 9 10
Front fan tray
Slot
Numbers
Air intake
Front
Rear fan tray
Rear
1_1-15

Do Not Distribute
2-15
ASR 5500 Card Types

Management IO Module Architecture (MIO) the MIO cards as you may have
already determined do allow the administrator to manage the configuration and core
functionalities of the ASR 5500
Installed in slots 5 & 6
1:1 Redundancy Model
Data Processing Card (DPC) These card are dedicated resources for data
processing of all data flows.
Installed in slots 1-4 & 7-10
1:N Redundancy Model
System Status Card (SSC) - Provides status monitoring and alarms for the ASR
5500 chassis and continually keep updating the MIOs
Installed in slots 11 and 12
Fabric and Storage Card (FCS) - Provides crossbar switch fabric and persistent
data storage
Installed in slots 13-18
2-16

Do Not Distribute
ASR 5500 Card Types
Slots (19-20) Unused
System
Status Card
slots (11-12)
Data Processing
Card slots (1-4,
7-10)
Fabric
Storage Card
slots (13-18)
Management and
I/O slots (5-6)
11 12 13 14 15 16 17 18 19 20
1 2 3 4 5 6 7 8 9 10
Slot
Numbers
Front
Rear
1_1-17

Do Not Distribute
2-17
Viewing Card Types

A detailed view of the Chassis card types can be see by typing the command show
card table greater card detail can also be seen with these additional subordinate
arguments.
[local]Training-School-9# show card ? <cr>
diag - Displays diagnostic results for a specific card or all cards
hardware - Displays information about installed hardware. Must be followed by
specific card number
info - Displays detailed information for a specific card or all cards
table
2-18
- Displays information about each card in front and RCC slots, or

complete system in tabular output

Do Not Distribute
Viewing Card Types

[local]Training-School-9# show card table
Slot
Card Type
----------- -------------------------------1: DPC
None
2: DPC
None
3: DPC
Data Processing Card
4: DPC
5: MMIO
Management & 20x10Gb I/O Card
6: MMIO
7: DPC
8: DPC
9: DPC
None
10: DPC
None
11: SSC
System Status Card
12: SSC
System Status Card
13: FSC
None
14: FSC
Fabric & 2x200GB Storage Card
15: FSC
16: FSC
17: FSC
18: FSC
None
19: NONE
None
20: NONE
None
[local]Training-School-9#
Oper State
------------Active
Active
Active
Standby
Active
Standby
Active
Active
Active
Active
Active
Active
-
SPOF
---No
No
No
No
No
No
No
No
No
No
-
Attach
------
1_1-19

Do Not Distribute
2-19
Card types
In the next few slides we will discuss card types and associated functionality. There
are four types of cards in the ASR 5500:
Management and IO Module Architecture (MIO); MIOs are installed in
Slots 5 & 6
Data Processing Card (DPC); DPCs are installed in slots1 4 and slots 7
10. Best practice module loading for DPC is 5, 6,8,3,7,4,9,2,10,1. This

will be discussed as we reveal the fabric connection speeds and power
distribution.
System Status Card (SSC); SSC installed in slots 11 & 12.

Fabric and Storage Card (FSC); FSC installed in slots 13 18.
UNUSED SLOTS - Slots 11 & 12 are not supported at this time and may be used for
future development and system enhancement.
2-20

Do Not Distribute
CARD Types
Summary
1_1-21

Do Not Distribute
2-21
Management and IO Module (MIO)

The MIO is incorporating the Management plane and user data plane physical
access functionality together. However the data and management planes are
isolated
The MIO has a single CPU w/ 96GB of RAM
- Data Planeis supported by 4 x 50 Gbs Typhoon NPUs for a total of 200Gbs
The Typhoon chip is familiar to development is used across a number of Cisco
platforms. This development has years of proven performance and multiple
success stories.
- 3 programmable grid Arrays
2 Control
1 Data
- Management Ethernet Ports 2 x 1000Base-T Management Ports
The Daughter cards only come in one offering as of today 100Gbps I/O
each and are factory only installed. There is no field replaceable option for
the daughter card today.
SFP Short reach or Long reach are supported,

20 10GB interfaces are supported
40 10GB interfaces total if you populate both MIO daughter slots
2-22

Do Not Distribute
Management and IO Module (MIO)

Provides chassis management and external I/O functionality
Control Plane: 1 x 6-core 2.0 GHz x86 processor with 96GB DRAM
Data Plane: 4 x 50Gbps Cisco Typhoon NPUs 200Gbps Capacity
3 FPGAs (2 x Control, 1 x Data)
Installed in slots 5 & 6

2 x 1000BASE-T Management Ethernet Ports
Rear
2 Daughter Card Modules (100Gbps I/O Each)
Status
LEDs
Debug Ports
USB
Console Port
Daughter Card 1
Management
Ethernet
Daughter Card 2
1_1-23

Do Not Distribute
2-23
MIO card LEDs and Indicators

Status LEDs
Debug Ports (normally covered by a face plate use only when directed by
development engineering)
Console port (pin out remain to different than the Cisco standard)
USB slot to be used for uploading code or configuration files.
2-24

Do Not Distribute
MIO card LEDs and Indicators
Online
Master
Backed up by
other MIO
All ports
backed up by
other MIO
Online
Master
Not backed up
by other MIO
- or Any port not
backed up by
other MIO
Online
Slave
All ports
standby
Online
Slave
Any port active
All ports
backed up by
other MIO
Online
Slave
Any port active
Any port not
backed up by
other MIO
Online
Switch over in
progress
Booting,
Starting, or
Initializing
1_1-25

Do Not Distribute
2-25
MIO Port LEDs and Indicators

Daughter card Physical ports cannot be configured in the LOCAL context
specifically designed for user data only.
* Daughter cards are installed as part of the Manufacturing process and not a
FRU
Management Ports are used for only off-lineor out of management management
use.
A 32GB Flash is also on board for configuration and operating system images.
2-26

Do Not Distribute
MIO Port LEDs and Indicators
show card table

show port info 5/1
show led 5
1_1-27

Do Not Distribute
2-27
MIO Card Status

These are good show commands that can reveal details of MIO card information
[local]Trng-9# show card
diag - Displays diagnostic results for a specific card or all
cards
hardware - Displays information about installed hardware. Must be
followed by specific card number
info - Displays detailed information for a specific card or all
cards
Table - Displays information about each card in front and RCC
slots, or complete system in tabular output
And
[local]Trng-9# show card info 6

Card 6:
Slot Type
: MMIO
Card Type
: Management & 20x10Gb I/O Card
Daughter Cards
: DC1 DC2 DC3
Operational State
: Standby
Last State Change
: Thursday February 28 18:09:34 EST 2013
Administrative State
: Enabled
Card Lock
: Locked
Halt Issued
: No
Reboot Pending
: No
Upgrade In Progress
: No
Card Usable
: Yes
Single Point of Failure
: n/a
Temperature
: Normal
Voltages
: Good
Card LEDs
Redundant: Green
2-28
: Run/Fail: Green | Active: Off
Card LEDs
: Master:
Off
CPU 0
: Diags/Kernel Running, Tasks Running

Do Not Distribute
MIO Card Status

Card 5:
Slot Type
Card Type
Daughter Cards
Operational State
Last State Change
Card Lock
Halt Issued
Reboot Pending
Upgrade In Progress
Card Usable
Single Point of Failure
Temperature
Voltages
Card LEDs
Card LEDs
CPU 0
show card info 5

:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
MMIO
DC1 DC2 DC3
Active
Friday January 11 17:18:07 EST 2013
Enabled
Locked
No
No
No
Yes
No
Normal
Good
Run/Fail: Green | Active: Green | Redundant: Green
Master:
Green
Diags/Kernel Running, Tasks Running
1_1-29

Do Not Distribute
2-29
MIO Architecture
The slide is a simplified view of the key components of the MIO card.
The BCF Board Control FPGA (Field Programmable Grid Array)is the first
component to receive power and is used in every card on the system and the Fan
trays as well, The BCF is used to monitor Chassis Management and is based on
USB technology and provides for point to point, 1 to 1 connectivity to all card and
fan trays. The BCF sends power commands.
SL Status Link is a serial link which will set the action of whether a card is to be
either Active or Standby, the algorithm is similar to the ASR5000.
CAF Control and Available FPGA The CAF is a common interface to all the
internal components on the card. Statistics information, Control Information,
Hardware Heartbeat. The CAF makes use of the midplane to communicate to other
CAFs.
CAF also provides I/O to the console port and initiates the StarOS download to the
other cards.
IPsec crypto chip currently not used
NPU Network Processing Unit TCAP & Memory each NPU is mapped to the
physical, 5 - I/O port that are on the daughter cards. There are a total of 4 NPU in
the MIO that provide 4 x 5 I/O ports totaling 20 Ports
FAB Fabric Access Processor communicates to the chassis fabric
MDF MIO Data FPGA Data Plane Direct connectivity for traffic that need to be
handled by the CPU from the NPU #3.
Control Plane CPU to NPU #4 Heartbeat, HW stats
2-30

Do Not Distribute
MIO Architecture
To Midplane
(SAS, USB, PCIe)
To Fabric Modules
FAP
USB
FAP
CPU
Typhoon
NPU 2
FAP
SL
FAP
BCF
Typhoon
NPU 4
CAF
Typhoon
NPU 1
Typhoon
NPU 3
MDF
IPsec
USB
USB
FAPs
RS-232
Flash
Daughter Card 1
Daughter Card 2
1_1-31

Do Not Distribute
2-31
MIO Daughter Cards

Port connections on the MIO are actually accomplished though daughter cards that
are mounted on the MIO.
There are always two daughter cards, with each card supporting ten 10Gb ports
providing a total of 100 Gb per daughter card or with 2 daughter cards 200Gb total.
Port Mapping to NPU
NPU 1 - SFP slots 5/10,11,12,13 & 14
NPU 2 SFP slots 5/16,17,18,19 & 20
NPU 3 SFP slots 6/20,21,22 & 23 - Data Plane MDF
NPU 4 SFP slots 6/26,27 ,28 & 29 - Control Plane CPU
2-32

Do Not Distribute
MIO Daughter Cards

Daughter Cards
mounted on MIO
Typhoon
NPU 1
Typhoon
NPU 2
Quad
Quad
10G
10G
PHY
PHY
S
S
F
F
P
P
+
+
S
S
F
F
P
P
+
+
10
11
S
S
F
F
P
P
+
+
Quad
Quad
10G
10G
PHY
PHY
Typhoon
NPU 3
Quad
Quad
10G
10G
PHY
PHY
Typhoon
NPU 4
Quad
Quad
10G
10G
PHY
PHY
Quad
Quad
10G
10G
PHY
PHY
Quad
Quad
10G
10G
PHY
PHY
S
S
F
F
P
P
+
+
S
S
F
F
P
P
+
+
S
S
F
F
P
P
+
+
S
S
F
F
P
P
+
+
S
S
F
F
P
P
+
+
S
S
F
F
P
P
+
+
S
S
F
F
P
P
+
+
S
S
F
F
P
P
+
+
S
S
F
F
P
P
+
+
S
S
F
F
P
P
+
+
S
S
F
F
P
P
+
+
S
S
F
F
P
P
+
+
S
S
F
F
P
P
+
+
S
S
F
F
P
P
+
+
S
S
F
F
P
P
+
+
S
S
F
F
P
P
+
+
S
S
F
F
P
P
+
+
12 13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
1_1-33

Do Not Distribute
2-33
MIO Internal Flash

The ASR 5500 MIO cards has an internal flash drive that allows for administrators to
manage all the critical file and versions of code. These files include configuration
file with a .cfg extension and the binary operating system file with a .bin extention.
Other files include the boot.sys file which is the boot stack file that contains the
default configuration file and operating system to load and run at boot time.
Each MIO card has an identical flash drive that are synchronized for 100%
redundancy.
2-34

Do Not Distribute
MIO Internal Flash

32 GB compact flash stores the following:
Boot stack file (boot.sys)
Stores StarOS images (.bin)
Stores Configuration Files (.cfg)
[local]Training-School-9# dir /flash
-rwxrwxr-x
1 root
root
581 Aug 22 15:58 boot.sys
-rwxrwxr-x
1 root
root
10514 Jul 12 13:31 mip_class.cfg
-rwxrwxr-x
1 root
root
157 Jul 13 16:10 module.sys
drwxrwxr-x
2 root
root
32768 Jan 7 2010 persistdump
-rwxrwxr-x
1 root
root
159106048 Dec 31 2009 production.41873.asr5500.bin
-rwxrwxr-x
1 root
root
8623 Jul 13 16:26 sip_class.cfg
-rwxrwxr-x
1 root
root
7901 Aug 13 15:40 startup-5500.cfg
-rwxrwxr-x
1 root
root
2920 Jan 7 2010 system.cfg
1304480 /flash
Filesystem
1k-blocks
Used Available Use% Mounted on
/var/run/storage/flash/part1 31154688
1304480 29850208
4% /mnt/user/.auto/
onboard/flash
1_1-35

Do Not Distribute
2-35

Provides complex subscriber-aware traffic processing
2 subsystems, each containing:
Data Plane: 1 x 50Gbps Cisco Typhoon NPU
Hardware Security Processor

2-36

Do Not Distribute

Provides complex subscriber-aware traffic processing
2 subsystems, each containing:
Data Plane: 1 x 50Gbps Cisco Typhoon NPU
Hardware Security Processor

1_1-37

Do Not Distribute
2-37
DPC Architecture
The DPC has 2 identical Subsystems on board, each dedicated to handle
subscriber sessions. Similar to the MIO the DPC communicates over the midplane
architecture via the BCF and the CAF.
The following are major components on the DPC:
Board Control FPGA (BCF)
Board power and control, LEDs, environmental monitoring, general card
reset functions, CPU resets and startup
Control and Availability FPGA (CAF)

PCIe, Console, Heartbeat, Interrupt, etc.
DPC Data FPGA

High-speed data transfer to/from CPU
CPU Subsystem
Processing and memory resources for subscribers traffic processing
(sessmgr, vpnmgr, aaamgr, etc.)
NPU Subsystem - Network processing Unit

Policing/shaping, statistics, packet tracing/logging/mirroring, packet
processing
2-38

Do Not Distribute
DPC Architecture
To Fabric Modules
USB to MIOs
Identical to Subsystem 0
Subsystem 1
FAP
BCF
Subsystem 0
CAF
FAP
Typhoon
NPU
Typhoon
NPU
DDF
SPI
SPI
NAND
CPU0
CPU0
CPU1
CPU1
Security
CPU0
CPU0
CPU1
CPU1
IPsec
USB
USB
DDF
Dual
Dual
10G
10G
MAC
MAC
Dual
Dual
10G
10G
MAC
MAC
1_1-39

Do Not Distribute
2-39
DPC LEDs and Indicators

Standard LEDs detail each of the different states that are possible on the PDC cards
2-40

Do Not Distribute
DPC LEDs and Indicators
Online
Active
Backed up by
another DPC
Online
Active
Not backed up
by another
DPC
Online
Standby
Online
During
Migration
[local]Training-School-9# show led 3

Slot 03: Run/Fail: Green
| Active:
Booting,
Starting, or
Initializing
Green
Failed
Offline
| Redundant: Green
1_1-41

Do Not Distribute
2-41

The SSC communicates over the midplane architecture via the BCF. The SSC is
controlled through USB connections from MIOs. The System Status Card provides
Power monitoring for the entire system
Provides status monitoring and alarms for the ASR 5500 chassis
1 x Control FPGA (BCF)
2 Alarm Contacts and Relays
Voltage (Power) monitoring for all 8 48V rails through the midplane
System LEDs (Status and Service)

BCF controls all major functions

reset functions, audile alarm control, system power monitor (PFUs)
2-42

Do Not Distribute

Provides status monitoring and alarms for the ASR
5500 chassis
BCF controls several major functions
Controlled through USB connections from MIOs
1_1-43

Do Not Distribute
2-43
SSC LEDs and Indicators

Standard LEDs detail each of the different states that are possible on the SSC
cards.
2-44

Do Not Distribute
SSC LEDs and Indicators
Normal
Operation
No Service
Loss
Failed
Components
Service Loss
Failed
Components

| Active: Green
Status:
Green
| Service: Off
Service Loss
No failed
components
Offline
| Redundant: Green
1_1-45

Do Not Distribute
2-45

4 FSCs are required 3 provided for capacity and 1 provided for redundancy.
2 SSD Solid-state drives these are not FRUs.
Loaded in slots 13-18 for a maximum of 6 FSCs per chassis.
Each Fabric and Storage Card provides:
1.2 Tbps Crossbar Switching Fabric
75 Gbps each to slots 1-2 and 9-10 and 300 Gbps max
150 Gbps each to slots 3-8 and 900 Gbps max
2 x 2.5 Serial Access SCSI (SAS) Solid-State Drives (SSD)
Recommended best practice loading would be the following 6 slots in this specific
order for even power distribution: 12, 13, 14,16,18,11,15,17.
2-46

Do Not Distribute

Provides crossbar switch fabric and persistent data
storage
Up to 6 Installed in slots 13-18
3 Required Minimum Configuration
4 Required for RAID5 Redundancy
Each Fabric and Storage Card provides:

1.2 Tbps Crossbar Switching Fabric
75 Gbps each in slots 1-2 and 9-10 = 300 Gbps
150 Gbps each in slots 3-8 = 900 Gbps
2 x 2.5 Serial Access SCSI (SAS) Solid-State Drives (SSD)
Each installed FSC adds to the fabric bandwidth

available to each DPC and MIO card 6 x 1.2Tbps = 7.2 Tbps Capacity absolute maximum
1_1-47

Do Not Distribute
2-47
FSC LEDs and Indicators

Standard LEDs
2-48

Do Not Distribute
FSC LEDs and Indicators
Online
Active
Redundant
Fabric
Redundant
Storage
Online
Active
NonRedundant
Fabric
Initializing

| Active:
Off
Failed
Offline
| Redundant: Green
1_1-49

Do Not Distribute
2-49
FSC Architecture
2 - SSDs A&B CDR Storage controlled by the MIOs
2 FE600s 1 & 2 Fabric Element crossbar chips
1 - Board Control FPGA (BCF) Board Control Field Programmable Gate Array
Fabric and storage are separate failure on one component will not effect the other
Board Control FPGA (BCF)
reset functions, Fabric Element CPU Interface
Fabric Element (FE)

600 Gbps crossbar fabric per switch element
Provides 3 physical fabric planes
96 connection points at 6.25 Gbps
Builds a destination routing table based on reachability messages between Fabric

Access Processors or FAPs
2 Fabric Elements per FSC
1.2 Tbps Total Switching Capacity
6 Physical Fabric Planes
192 connection points at 6.25 Gbps
2-50

Do Not Distribute
FSC Architecture
SAS to Slots MIO 5 & 6
192 6.25 Gbps Links to Slots 1 - 10
USB
BCF
SSD A
FE600-1
96x96
96x96 Connection
Connection Points
Points
6.25G
6.25G per
per Connection
Connection
XBAR
XBAR
FE600-2
96x96
96x96 Connection
Connection Points
Points
6.25G
6.25G Per
Per Connection
Connection
XBAR
XBAR
SSD B
1_1-51

Do Not Distribute
2-51
Fabric Overview
The ASR5500 fabric is comprised of several different components.
The Traffic source and endpoints these are the ASR5500 calls the FAP (Fabric
Access Points) There is 192 FAP points per FSC. These connection points targets
are located on each of the MIOs and the DPCs and there is a 1 to 1 relationship
with the FAP and the NPU.
Each FAP has 6 6.25 Gbps connection points 1 6.25 Gbps for each of the 6 Fabric
Planes all in a full mesh architecture
Each DPC has 2 FAPs, because each DPC has 2 NPUs.
Each MIO has 4 FAPs, because each MIO has 4 NPUs.
2-52

Do Not Distribute
Fabric Overview
ASR 5500 fabric is composed of:
Traffic Sources & Endpoints: Fabric Access Processors (FAPs),
located on MIOs and DPCs
Crossbar Switches: Fabric Elements, located on FSCs
Each FSC provides 6 physical fabric planes

A physical fabric plane provides full-mesh connectivity between all
FAPs
FSC
FSC
(13)
FAP
FAP
DPC
FSC
FSC
(14)
FAP
FSC
FSC
(15)
(15)
FSC
FSC
(16)
(16)
FAP
DPC
MIO
MIO
FSC
FSC
(17)
(17)
FSC
(18)
(18)
FAP
FAP
FAP
DPC
FAP
DPC
1_1-53

Do Not Distribute
2-53
Physical Connectivity
The MIO Ports are connected to the NPU/FAP.
The Fabric Access Point Interfaces are connected to Fabric Elements for every FAP
there are 6 connections to the Fabric Element Chips on the FSCs. There are 3 to
FE-1 and 3 to FE-2
As was noted in the previous slide each FAP Fabric Access Processor has 6
connections to the Switch Fabric. So if we have 2 FAPs on a DPC this is a total of
12 connections @6.25 Gbps per connection to the switch fabric or 75 Gbps.
When we look closer at the MIO in has 4 FAPs so it provides 24 connections @6.25
Gbps per connection or 150 Gbps
Recycle is for Heartbeat and future development possibly QoS.
Notice on DPC FAP3 there is not only a connection to the NPU but there is a
Control interface and on FAP4 there is a interface for the MDF. In and out of the
cards to the FE.
2-54

Do Not Distribute
Physical Connectivity
Fabric Access Processors
MIO
NPU
FAP
6 @ 6.25 Gbps
Fabric Interfaces
per FAP
FSC
FSC
Recycle
NPU
DPC
NPU
FAP
FAP
FE
FE 1
1
Recycle
Control
Recycle
NPU
FAP
Control
NPU
FAP
FE
FE 2
2
Recycle
Control
Recycle
NPU
FAP
MDF
192 Links x 6.25 Gbps

per FSC
96 x 6.25 Gbps links per

Fabric Element
Recycle
1_1-55

Do Not Distribute
2-55
Fabric Connectivity and Bandwidth Distribution

The flexibility of the chassis allows you to add bandwidth in 1.2 Tbps bundles per
each Fabric Storage Card (FSC) added.
There are two types of backplane slots to support the switch fabrics 192 connection
points.
DPC 4 Slots 1-2, 9-10 each have 12 X 6.25 Gbps or 75 Gbps X 4 Slots = 300
Gbps
DPC and MIO 6 Slots 3-8 each have 24 X 6.25 Gbps or 150 Gbps X 6 Slots = 900
Gbps
Total = 1.2 Tbps
2-56

Do Not Distribute
Fabric Connectivity & Bandwidth Distribution

FSC
1.2Tbps per FSC
192 Connections x 6.25Gbps
4 DPC x 75 Gbps = 300Gbps
2 MIO & 4 DPC X150Gbps =900Gbps
24x6.25Gbps = 150Gbps
per MIO and DPC hybrid
slot per FSC
1_1-57

Do Not Distribute
2-57
FSC Card Interconnections

In review the ASR 5500 supports rear cards and front cards.
Rear cards are larger and perform chassis management, packet processing and I/O
functions.
Front cards determine the amount of bandwidth for the switching fabric (crossbars),
and indicate the operating and alarm status of the ASR 5500.
The figure on the next page is a simplified block diagram showing the ASR 5500
card architecture in preparation for a hardware flow example.
Status information regarding card health uses the USB transport. All other data
communication uses the FSC. Information isolation is provided by having a variety
of fabric planes discussed in the previous slides.
2-58

Do Not Distribute
FSC Card Interconnections

Switch fabric hardware or Fabric Elements are located on FSC
System throughput capacity increased by adding FSCs
Minimum of three FSCs are required for operation and a forth for
redundancy
Config file and

image storage
External network
Mgmt network
DPC
DPC
DPC
DPC
Rear
MIO
USB
Front
SSC
MIO
DPC
DPC
DPC
DPC
Session
Processing
and I/O
Switch fabric
SSC
FSC
FSC
FSC
FSC
RAID 0
RAID 0
RAID 0
RAID 0
SSD
SSD
SSD
SSD
SSD
SSD
SSD
SSD
RAID 5
CO Alarm Panel
1_1-59

Do Not Distribute
2-59
DPC Ingress Packet Flow

There are several steps moving data from the ingress port to an appropriate CPU
for processing this is the hardware vie of that ingress procees
1. Receive packet from wire
2. Basic validation checks
3. Flow processing
4. Fabric arbitration and queuing
5. Transmit to fabric
6. Receive from fabric
7. Forwarding lookup
8. Transmit to CPU
2-60

Do Not Distribute
MIO-NPU Ingress Packet Flow

FSC
FSC 1
1
5.
FE
Transmit
to fabric
FSC
FSC N
N
FE
FE
FE
6. Receive
from fabric
4. VOQ
arbitration and
queuing
FAP
FAP
FAP
7. Forwarding
lookup
3. Flow
processi ng
M-NPU
D-NPU
8. Transmit
to CPU
M-NPU
2. Basic
validation
checks
CPU
CPU
1. Receive
packet from
wire
S
S
F
F
P
P
+
+
MIO
MIO
CPU
CPU
DDF
DPC
DPC
1_1-61

Do Not Distribute
2-61
DPC Egress Packet Flow

There are several steps moving data from the CPU to the appropriate Egress port
for final framing and transport.
9. Receive packet from CPU
11. Fabric arbitration and queuing
12. Transmit to fabric
13. Receive from fabric
15. Basic validation checks
16. Transmit to wire
2-62

Do Not Distribute
DPC-NPU Egress Packet Flow

FSC
FSC 1
1
FE
5. Receive
from fabric
FSC
FSC N
N
FE
FE
FE
4. Transmit
to fabric
3. VOQ
arbitration
and queuing
FAP
FAP
FAP
2. Forwarding
lookup
6. Forwarding
lookup
M-NPU
D-NPU
1. Receive
packet from
CPU
M-NPU
7. Basic
validation
checks
CPU
CPU
8. Transmit
to wire
S
S
F
F
P
P
+
+
MIO
MIO
CPU
CPU
DDF
DPC
DPC
1_1-63

Do Not Distribute
2-63
Useful Show Commands Traffic & CPU
2-64

Do Not Distribute
Useful Show Commands Traffic & CPU

FSC
FSC
FE
FE
FAP
show npu utilization table
show port datalink counters

show port npu counters
show port utilization table
show port transceiver
CPU
CPU
show cpu table
show cpu info card 5
show cpu errors card
5
M-NPU
S
S
F
F
P
P
+
+
MIO
MIO
1_1-65

Do Not Distribute
2-65
FSC Status and Storage
2-66

Do Not Distribute
FSC Status and Storage

Card 13:
Slot Type
Operational State
Last State Change
show card info 13

:
:
:
:
FSC
Empty
Sunday December 09 19:35:25 EST 2012
Enabled
[local]Training-School-9# dir /hd-raid

0
/hd-raid
Filesystem
1k-blocks
tmpfs
1024
16
1008
2% /mnt
1_1-67

Do Not Distribute
2-67
FSC Persistent Storage

Drive RAID Array across all FSC Persistent Storage SSDs
Each FSC has 2 2.5 SAS SSD Drives that are controlled by 2 eight port HD
controllers on the MIO Cards. They are serial attached SCSI, solid state drives.
Complete Redundancy RAID 0+5 hybrid configuration
Slot 5
1 8-port SAS HBA will control all the top SSD A Drives
2 8-port SAS HBA will control all the bottom SSD B Drives
Slot 6
1 8-port SAS HBA will control all the top SSD A Drives
2 8-port SAS HBA will control all the bottom SSD B Drives
2-68

Do Not Distribute
FSC Persistent Storage

ASR 5500 uses a drive array for short-term CDR storage
Each FSC contains 2-200GB 2.5 SAS SSD drives
Each MIO contains 2 SAS controllers
One controller attaches to the top drive A on every FSC
Other controller attaches to the bottom drive B on every FSC
MIO Slot 5
F
S SSD SSD
A
B
C
MIO Slot 6
8-port
SAS HBA
F
S SSD SSD
A
B
C
8-port
SAS HBA
CPU Subsystem
F
S SSD SSD
A
B
C
F
S SSD SSD
A
B
C
CPU Subsystem
8-port
SAS HBA
F
S SSD SSD
A
B
C
F
S SSD SSD
A
B
C
8-port
SAS HBA
1_1-69

Do Not Distribute
2-69
FSC RAID Configuration

HD-Raid- Completely Redundant RAID 0+5 hybrid configuration
2 X 200GB RAID 0 Implementation per card or 400GB
3 X FSC Card RAID 5 Implementation requires 4th FSC as redundant drive per
chassis, or 3 X 400GB = 1.2 TB
Presented in the CLI as:
Dir /hd-raid
Must have 3 FSCs - for this hybrid to work properly and a forth for redundancy
Additional card do not add to storage capacity
2-70

Do Not Distribute
FSC RAID Configuration

ASR 5500 uses a RAID 0+5 hybrid configuration
Each pair of drives on an FSC is striped into a RAID 0 array
RAID 0 array across 4 FSCs is striped into a RAID 5 array
RAID 5 array presented as /hd-raid
3 FSC required for configuration and a forth for redundancy
Loss of an FSC removes 1 RAID 0 array, with the RAID 5 array providing
redundancy with 4 FSC Cards loaded
Adding a 5th and 6th FSC will only provide an extra spare and does not add
disk capacity
RAID 5
RAID 0
F
S
C
SSD
A
SSD
B
RAID 0
F
S
C
SSD
A
SSD
B
RAID 0
RAID 0
F
S
C
SSD
A
SSD
B
F
S
C
SSD
A
SSD
B
1_1-71

Do Not Distribute
2-71
Useful HD/RAID CLI Commands

ASR 5500 Card/Disk States:
Not Used
Invalid partition or image
Unknown partition or image
Valid image of <UUID>
Faulty
Spare
Rebuilding
In-sync
*Adding a 5th FSC will only provide for a extra spare and does not add extra
capacity.
2-72

Do Not Distribute
Useful HD/RAID CLI Commands

[local]ASR5500# sho hd raid
verbose
- More details displayed
|
- pipeline
<cr>
- newline
[local]ASR5500# show hd raid
HD RAID:
Degraded = Yes when card state not In-sync
State
: Available
Is not shown for at least 4 FSCs
Degraded
: No
UUID
: 9b90e1a8:3508dd4e:9ce0e069:564de798
Size
: 1.2TB
Action
: Idle
Card 13
State
: Spare card
Disk hd13a
State
: In-sync component
Disk hd13b
ASR 5500 Card/Disk States:
State
: In-sync component
Not Used
Card 14
State
: In-sync card
Invalid partition or image
Disk hd14a
Unknown partition or image
State
: In-sync component
Valid image of <UUID>
Disk hd14b
State
: In-sync component
Faulty
...
Additional drive-level info
Spare
Rebuilding
In-sync
1_1-73

Do Not Distribute
2-73
Power Planes
On Boot slots 5 & 6 receive power where the Management (MIO) cards reside. At
the same time all 4 fans trays will power up at 50% rpm. After the MIO cards are
detected and power up the remaining slots will receive power and the fans will
power up to 100%.
Management cards must be detected if not no other slot will receive
power.
Issue could be due to MIOs not being seated properly.
Power is applied to slots 5 & 6 and all of the fan trays first
Only after a successful MIO boot on Slot 5 or 6, is power applied to the remaining
18 slots.
Power Planes
Plane A1/B1 Slots 8-10, 13
Plane A2/B2 Slots 4-5, 11-12, 16-17, Lower Fan Trays
Plane A3/B3 Slots 6-7, 14-15, 19-20, Upper Fan Trays
2-74

Do Not Distribute
Power Planes
Plane A2/B2 Slots 4-5, 11-12,
16-17, Lower Fan Trays
Plane A3/B3 Slots 6-7, 14-15,
19-20, Upper Fan Trays
Power is applied to slots 5 & 6
and all of the fan trays first
Only after a successful MIO
boots is power applied to the
remaining slots
1_1-75

Do Not Distribute
2-75
Obtaining Hardware Inventory

On the ASR 5500 the Licensing Serial number is kept on the Midplane its self. The
License needs to be generated off the Midplane component.
That being said the operator can remove any card from the system and the license
will stay with the chassis and the license keys associated with the chassis are not
affected. The License is not associated to any removable component.
Display the Serial number with: show hardware inventory
MEC (Midplane Equipment Component) - part number - serial number
2-76

Do Not Distribute
Obtaining Hardware Inventory

[local]Training-School-9# show hardware inventory
Slot Type
Part Number Product ID / Version ID
---- ---- ----------------- ----------------------1: None
---2: None
---3:
DPC
73-14233-03 A0
ASR55-DPC-K9 V03
CCK
73-14558-01 A0
--4:
DPC
73-14233-03 A0
ASR55-DPC-K9 V03
CCK
73-14558-01 A0
--5:
MIO
73-14234-03 A0
ASR55-MIO-BASE-K9 V03
XDC
73-14547-01 A0
--XDC
73-14547-01 A0
--CCK
73-14548-01 A0
--MEC
73-14501-01 A0
ASR55-MEC V01
MIDP
73-14232-01 A0
--CHAS
73-14344-01
ASR55-CHS-SYS V01
6:
MIO
73-14234-03 A0
ASR55-MIO-BASE-K9 V03
XDC
73-14547-01 A0
--XDC
73-14547-01 A0
--CCK
73-14548-01 A0
----- ----------=
Serial Num
------------SAD1606018Z
SAD1603026T
SAD160300KM
SAD160202UC
SAD154002AB
SAD152302VA
SAD15400277
SAD15400295
FLM154300D8
TBM15471261
FLM160405P7
SAD160200S9
SAD154902YS
SAD152701SN
SAD153802ZM
CLEI code
---------------------------
1_1-77

Do Not Distribute
2-77
Card Interlock Switch

Every card on the ASR 5500 has an interlock switch.
The top and bottom handles of ASR 5500 circuit cards incorporate hooks that fit
behind the upper and lower rails of the card cage. Lifting the handles outwards
ejects the card from the midplane. Pushing the handles inwards seats the card into
the midplane.
The top handle on every card incorporates an interlock switch that signals the
system that a card is seated in the slot. The blue subhandle must be pushed fully
upward to engage the interlock switch. The subhandle also locks the top handle
against the front of the card. Tightening the captive screw within the top and bottom
handles secures the subhandle and circuit card to the card cage.
2-78

Do Not Distribute
Card Interlock Switch
Captive Screw
Ejector Handle
Ejector Subhandle
(Interlock)
1_1-79

Do Not Distribute
2-79
ASR 5500 Hardware Architecture Summary
2-80

Do Not Distribute
ASR 5500 Hardware Architecture Summary

10-slot midplane chassis design
4 card types: MIO, DPC, FSC, SSC
I/O ports are moved from dedicated line
cards to the management cards
21 RU
Good hardware commands:
show
show
show
show
card table
card info <slot>
hardware card <slot>
led <slot>
1_1-81

Do Not Distribute
2-81
1_1-82
2-82

Do Not Distribute
Cisco ASR 5500

Software Architecture
Lesson 3

Do Not Distribute
3-1
Module Overview
3-2

Do Not Distribute
Module Agenda
The ASR 5500 StarOS software model
Software Distribution Philosophy
StarOS Key Processes
Basic building blocks of the StarOS
Typical software components of a flow
1_1-3

Do Not Distribute
3-3
Software Introduction of the StarOS

From the hardware overview lesson, you learned that the ASR 5500 is a multiprocessor system. With an application card in every possible slot:
The ASR 5500 contains 2 x six-core control processors cores (CPs) or

80 cores on active modules
16 cores on standby modules
64-bit Linux Kernel
Userspace runs in 32-bit mode
Some network processor tasks will run as 64-bit tasks
All of these processors run the same binary image. The system binary is started on
the management modules (MIO) and, as the individual application modules come
up, it is then distributed to the control processors on them.
The system is a model of distributed processing, with each CP running the same
image in synchronization with all the other CPs in the system. Sharing the same
image is a complex task that involves a lot of secondary messaging which is
indirectly related to session processing. Consequently, an architectural overview is
not so straight-forward.
This introduction describes a few pieces of the system, not the whole system. It
focuses on those pieces that most directly relate to session processing in a SGW
environment.
The binary image that the processors share is the StarOS operating system. At the
system console, you will sometimes see references to Boxer. This is an older
name for the StarOS.
3-4

Do Not Distribute
Software Introduction of StarOS

The ASR 5500 platform is a model of distributed
processing using 64 bit Linux (Debian Kernel)
Fully-loaded (all application card slots occupied),
The ASR5500 contains 18 hex-core control processors (CPs)
All of the CPs run the same binary image

Sharing the same image across multiple CPUs is
complex, involving the distribution and synchronization
of multiple software functions
This is an introduction to some basic building blocks of
the StarOS operating system
On initial 5500 release only offline upgrades are
supported. Online patches and upgrades not supported
1_1-5

Do Not Distribute
3-5
Viewing Software Components

The best way to get a glimpse of the software operating system is to use the show
task resource CLI command. As you become more proficient with this command
you may wish to use a variety of the options to limits the volume of output. The
slide on the opposite page shows a partial output.
Some points of interest:
The far-left column of the output is the slot and Control Processor (CPU)
number on which the task is running.
The task name is under the facility column, along with the task instance. A
task is not a process. A task runs within a process. Thus there can be multiple
tasks with the same process instance number.
Shown under the cputime column is the percentage of CPU cycles available
to, and used by, each task. When a task exceeds its allocated cpu-time, an
alarm will be generated.
Memory, in Megabytes, that is available to each task is shown under the

memory column.
File space that is available to, and used by, each task is shown in the files
column.
Under the session column, the number of allocated, and actual, subscriber
sessions related to a task is displayed. Not all tasks have sessions directly
related to them.
The S column is the state of the task which can be either static (S) or
initialized (I).
The status column can contain any number of labels, and is meant to display
the overall health of the task.
Software tasks for the ASR 5500:

npusim Slow path processing for MIO NPU; 4 instances, 1 per NPU
afmgr Fabric Manager; child of sitparent; 1 instance per MIO/DPC CPU
afctrl Fabric Controller; child of sitparent; 1 instance on Active MIO
3-6

Do Not Distribute
Viewing Software Components

Once the system is booted, you can view most of the system software
components with the following CLI command: show task resources
[local]Training-School-9# show task resources | more
task
cputime
memory
files
sessions
cpu facility
inst used allc
used alloc used allc used allc S status
----------------------- --------- ------------- --------- ------------- -----3/0 sitmain
30 0.1% 15%
8.5M 16.0M
13 1000
--- good
3/0 sitparent
30 0.1% 20%
8.0M 14.0M
10 500
--- good
3/0 hatcpu
30 0.1% 10%
8.1M 15.0M
11 500
--- good
3/0 afmgr
30 0.0% 10% 12.4M 20.0M
13 500
--- good
3/0 hwmgr
30 0.1% 15%
8.3M 15.0M
12 500
--- good
3/0 dhmgr
30 0.1% 15%
8.5M 26.0M
16 6000
--- good
3/0 dcardmgr
30 0.2% 60% 40.1M 280.0M
16 500
--- good
3/0 npumgr
30 1.1% 100% 383.6M 2326M
22 1000
--- good
3/0 npusim
31 0.1% 33% 12.5M 60.0M
12 500
--- good
3/0 sft
300 0.1% 50% 11.8M 30.0M
10 500
--- good
3/0 vpnmgr
2 0.1% 100% 19.1M 37.0M
34 2000
--- good
3/0 zebos
2 0.0% 50% 12.3M 25.0M
15 1000
--- good
3/0 gtpumgr
1 0.3% 90% 19.4M 2045M
12 1000
2
0 good
3/0 egtpegmgr
1 0.3% 90% 22.3M 1445M 109 1000
1
0 good
Slot/CP#
Task name
CPU
allocation
memory
allocation
file
allocation
1_1-7

Do Not Distribute
3-7
Important Tasks on the ASR 5500

Task
Description
vpnmgr
One VPN manager is started for each configured context (one

is always present for the local context) and performs the
following functions:
- IP address pool and subscriber IP address management.
- implementing Address Resolution Protocol (ARP).
- installing NPU flows.
sessmgr
A Session Manager performs the following functions:

- Provides a subscriber processing system that supports
multiple session types.
- Multiple Session Managers can run on a single CPU and/or
can be distributed throughout any CPU present in the system.
- A single Session Manager can service sessions from
multiple signaling demux Managers.
- for each session manager task created, an AAA Manager
task is created.
aaamgr
AAA Managers are paired with Session Managers (except the

one running on the MIO and perform the following functions:
- Perform all AAA protocol operations and functions for
subscribers.
- Acts as a AAA client to AAA servers.
- Multiple AAA Managers can run on a single CPU and/or can
be distributed throughout any CPU present in the system.
Created for the SGW ingress providing GTP-cV2 signaling for

the S11 interface to the MME and egress providing S5
Signalling to PGW S5 intertace
egtpimgregtpemgr
Created for the PGW ingress provides S5 Interface signalling
Maintains a list of current Session Manager tasks to aid in
system recovery.
gtpumgr
3-8
Provides GPRS Tunnel Protocol Version 1 or GTP-uV1

Created for the SGW ingress providing a user plane tunnel on
the S1U Interface to the eNodeB
Created for the SGW egress and PGW ingress provides
GPRS-U on S5 Interface
Maintains a list of current Session Manager tasks to aid in
system recovery.

Do Not Distribute
Important Tasks on the ASR 5500

In a SGW/PGW environments, the following tasks are
central to call processing:
vpnmgr
sessmgr
Session Control
aaamgr
gtpumgr
egtpegmgr
SGW
egtpinmgr
gtpumgr
egtpinmgr
PGW
1_1-9

Do Not Distribute
3-9
A Functional View
We have already introduced the context on the ASR 5500 and adopted this on the
ASR5500. The diagram on the opposite page attempts to show how the software
tasks mentioned in the previous slide relate to contexts.
Notice the following:
3-10
There is a vpnmgr instance for each context.
For every PGW, SGW or GGSN service configured, there is an associated

manager.
The session manager, accompanied by the aaamgr, are the processes that
are most involved with each call setup. For that reason, they are positioned
across both contexts or in the same context to reduce session manager
cosumption: they are the workhorses in routing calls from one context to
another.
Later in this module, we will discuss session recovery. A session can be

captured and re-created with information found primarily in the sessmgr,
aaamgr, and vpnmgr.
For PGW and SGW services, this is an overly-simplified, but useful, view of
the software architecture.

Do Not Distribute
A Functional View
To a certain extent, some of the
software tasks just mentioned can
be correlated to call-processing
configurations
For every context, there is a
vpnmgr instance
SGW
SGW Dest
Context
SGW Src
Context
S11
S1-U
egtpmgr
sessmgr
SGW
aaamgr
egtpmgr
S5/S8
gtpumgr
gtpumgr
For every service, there is a

corresponding signaling manger:
vpnmgr
vpnmgr
service sgw
PGW
(S11) egtpmgr
PGW Src
Context
(S1-U) gtpumgr
(S5-S8) gtpumgr, egtpmgr
service pgw
(S5-S8) gtpumgr, egtpmgr
Subscriber sessions are
contained within sessmgr and
aaamgr instances
SGi
Context
egtpmgr
egtpmgr
S5/S8
PGW
SGi
sessmgr
aaamgr
gtpumgr
vpnmgr
vpnmgr
1_1-11

Do Not Distribute
3-11
Controller Tasks and Subsystem Manager Tasks

Another relationship that is useful to know is that which exits between a controller
process and a manager process. Many of the primary subsystems are composed of
tasks called Controllers, and subordinated tasks called Managers.
Controllers are usually found only on the MIO cards and spawn Managers. There is
a parent-child relationship between Controllers and Managers. Controllers serve a
number of purposes. They:
monitor the state of their Managers and allow for communication between
Managers within the same subsystem.
enable inter-subsystem communication since they can communicate with the

controllers of other subsystems.
mask from the user the distributed nature of the software, offloading the need
for detailed resource management.
Manager tasks run on the CPs that are located on the DPC cards.
For instance, the session controller creates multiple instances (pairs) of sessmgrs
and aaamgrs on the DPC cards. This is illustrated in the slide on the opposite page.
Each sessmgr task can accommodate a finite number of calls:
ASR5500 Session Count

24 active session mgrs per CPU or 48 session mgrs per DPC
With DPC card redundancy enabled there is 7 total awith active sessions
The total sessions are therefore 7x48x35200 = 11,827,200 theroretical
connection. Keep in mind call setup and other activities other than call
user plan data consume sessions on each manager
Session managers can be created as the demand on the system (call rate)
increases, or can all be created at system initialization.
Also shown in the slide is the vpn controller/manager relationship. The vpn controller
creates a vpn manager task for each context that is created on the system.
3-12

Do Not Distribute
Controller Tasks and Subsystem Managers

Many of the tasks have a parent-child relationship; referred to as Controllers and
Managers
A Controller task runs on the MIO, and is responsible for creating manager
tasks
Manager tasks run on the control processors (CPs) located on DPC modules
(active)
Session Controller (sessctrl) creates:

Multiple instances of session
managers (sessmgrs) and aaa
managers (aaamgrs)
Signaling managers for every
service that is configured (gtpumgr,
egtpmgr, imsimgr)
VPN Controller (vpnctrl) creates a
vpnmgr for each context; used to
facilitate IP routing across and within
contexts
(standby)
MIO
controllers
MIO
vpnctrl
se ssctrl
Switch Fabric
CP0 x 6
CP0 x 6
aaamgr
se ssmgr
se ssmgr
CP1 x 6
se ssmgr
aaamgr
DPC
CP0 x 6
vpnmgr
aaamgr
CP1 x 6
aaamgr
se ssmgr
DPC
CP1 x 6etpmgr
gtpumgr
PSC
sub-managers
1_1-13

Do Not Distribute
3-13
Other Controller Tasks

For call processing purposes, the session controller (sessctrl) and vpn controller
(vpnctrl) are very important tasks. But there are many other equally important
controllers too.
On the opposite page, the show task resource command is executed with a grep
ctrl command to filter the output of the command. The result is a list of controller
tasks on the system. A brief definition of each is given below:
3-14
drvctrl driver controller
rmctrl resource manager controller
npuctrl network processor unit controller
dcardctgrl encryption daughter card ctrl
cspctrl card/slot/port ctrl
vpnctrl virtual private network ctrl
cssctrl content steering service controller
sessctrl session controller
vmgctrl virtual media gateway controller
ipseccctrl ipsec controller
acsctrl active charging service controller

Do Not Distribute
Other Controller Tasks

Besides the vpnctrl and sessctrl tasks, there
are
other
--- good
controller tasks too:
--- good
[local]Training-School-9# show task resources | grep ctrl

5/0 drvctrl
0 0.0% 15% 11.6M 20.0M
10 500
5/0 hdctrl
0 0.2% 15% 10.6M 15.0M
14 500
5/0 rmctrl
0 0.4% 20% 18.4M 35.0M
23 1000
5/0 npuctrl
0 0.2% 10%
8.8M 20.0M
20 500
5/0 dcardctrl
0 0.1% 10%
8.1M 18.0M
10 500
5/0 afctrl
0 0.1% 10% 12.0M 20.0M
20 500
5/0 cspctrl
0 0.6% 50% 11.7M 22.0M
10 500
5/0 vpnctrl
0 0.1% 15% 12.4M 22.0M
11 1500
5/0 cssctrl
0 0.1% 15%
7.8M 17.0M
11 500
5/0 sessctrl
0 0.1% 90% 17.3M 67.0M
11 2000
5/0 ipsecctrl
0 0.1% 15%
8.7M 60.0M
10 500
5/0 kvctrl
0 0.1% 10% 10.4M 16.0M
10 500
5/0 testctrl
0 0.0% 30%
9.2M 20.0M
11 500
5/0 hwctrl
0 1.0% 10%
8.2M 15.0M
28 500
6/0 drvctrl
1 0.1% 15% 11.3M 20.0M
10 500
6/0 hdctrl
1 0.0% 15% 10.4M 15.0M
10 500
---------------
---------------
good
good
good
good
good
good
good
good
good
good
good
good
good
good
1_1-15

Do Not Distribute
3-15
Session Distribution
In the slide on the opposite page, notice that the show task resource command has
been executed with a grep sessmgr qualifier. The end result is that only the session
managers, across the whole system, are displayed.
Under the sessions column there is a used and allocated sub-column. Since this
output was taken from an ASR 5500, the number of allocated sessions per session
manager task is based on board type in the case of the current DPC there is 32500
per manager.
In the used column, notice that there are between four and nine active sessions on
each session manager. This shows that the system tries to distribute the call load
across all session managers that have been created. The slide on the opposite
page illustrates how session distribution can be observed on the system.
3-16

Do Not Distribute
Session Distribution
Up to 48 session managers (and accompanying aaamgrs) providing can be
created per DPC card
Each Session Manager can provide up to 35200 sessions
The system attempts to evenly distribute calls across existing sessmgrs
This can be viewed on an active system with the show task resources |
grep sessmgr command:
[local]Training-School-9# show task resources | grep sessmgr
task cputime
memory
files
sessions
cpu facility
inst used allc
used alloc used allc used allc S status
----------------------- --------- ------------- --------- -------------4/0 sessmgr
5004 0.1% 50% 117.5M 190.0M
16 500
--- S
good
4/0 sessmgr
2 0.2% 100% 214.3M 2550M
16 500
9 35200 I
good
sessmgr 2550M
4/0 sessmgr
6 0.2%Standby
100% 214.3M
16 500
6 35200 I
good
4/0 sessmgr
10 0.2% 100% 214.3M 2550M
16 500
4 35200 I
good
Sessions
Active Sessions
::::
::::
:::: Max
::::
8/0 sessmgr
5012 0.2% 50% 117.5M 190.0M
14 500
--- S
good
8/0 sessmgr
5013 0.1% 50% 117.5M 190.0M
15 500
--- S
good
Standby Card sessmgr
1_1-17

Do Not Distribute
3-17
Tasks Related to Startup

The active MIO management module is the first to load the StarOS from a flash card
that is on the same board. The init process will start the MIO System Initialization
Task (SIT) controller process. When the SIT controller process starts, it is provided
with a startup profile. This startup profile is a text file that contains a set of rules that
SIT and the resource manager use to determine which CPUs and processes to use
to start various tasks. When SIT starts, it will create a set of static tasks. These
include: msgd, evlogd, HAT, CM, and all the other controller tasks.
After the firmware code has passed preliminary diagnostics on the DPC cards, they
will then start the image download process. They use DHCP to obtain an internal IP
address and then retrieve an image from the active management module.
Each PSC kernel will boot and start the UNIX init process. The DPC applications
will then be started, one of the first of those being the SIT process.
There are a few variations of SIT on the system. Some details are given in the table
below:
Task
Description
sitmain
Initiated at system start-up, the SITMAIN task performs the following

functions:
- Reads and provides startup configuration to other SIT components
- Starts SITREAP
- Maintains CPU state information
- Starts MIOs in either active or standby mode

- Registers tasks with HAT task
sitparent - Notifies CSP task of CPU startup completion
- Brings DPCs up in standby mode
- Initiates tasks on the DPC such as High Availability Task and
CPUResource Manager Task
sitreap
3-18
Shuts down tasks as required

Do Not Distribute
Tasks Related to Startup

Active MIO (management i/o
module) is the first to boot by
loading the binary image found
on the resident flash card
ASR5500
The first task to start is the

System Initialization Task (SIT):
Responsible for startup of the
Linux kernel and StarOS on
each processor of each
module
Starts a set of initial static
tasks at system startup time
(active)
(standby)
MIO
MIO
CP0 x 6
SIT
Switch Fabric
CP0 x 6
CP0 x 6
CP0 x 6
SIT
SIT
SIT
CP1 x 6
CP1 x 6
CP1 x 6
SIT
SIT
SIT
DPC
DPC
DPC
SIT on MIO creates SIT

manager instances on each
DPC
1_1-19

Do Not Distribute
3-19
Tasks Related to Redundancy

There are three tasks that, collectively, provide most of the systems redundancy
functionality. This includes both hardware and software redundancy.
The SCT and RCT tasks are only found on the management module.
That HAT task is found on every module.
A brief description of each is given below:
3-20
High Availability Task (HAT) - Together with the Recovery Control Task
(RCT) subsystem, the HAT subsystem is responsible for maintaining the
operational state of the system. HAT does this by monitoring the various
software and hardware aspects of the system. On finding any unusual
activities, such as the unexpected termination of another task, the HAT
subsystem would trigger an event to the RCT subsystem in order to take
some corrective action.
Recovery Control Task (RCT) - This subsystem is responsible for executing

a recovery action for any failure that occurs in the system. The RCT
subsystem receives signals from the HAT subsystem (and in some cases
from the NPU subsystem) and determines what recovery actions are needed.
The RCT subsystem runs on the active MIO and synchronizes the information
it contains with the RCT subsystem on the standby MIO.
Shared Configuration Task (SCT) - This subsystem provides the system

with a facility to set, retrieve and be notified of system configuration
parameters. This subsystem is mainly responsible for storing configuration
data for the applications that run on the system. The SCT subsystem runs
only on the active MIO and synchronizes the information it contains with the
SCT subsystem on the standby MIO.

Do Not Distribute
Tasks Related to Redundancy

The following tasks work together to
provide software/hardware recovery
and/or failover:
High Availability Task (HAT)
Maintains the operation state of the
system by monitoring the software
and hardware on each board
Recovery Control Task (RCT)
Executes a recovery action for any
failure that occurs in the system
Depends on triggers fed to it by
HAT and CSP
Shared Configuration Task (SCT)
Sets, retrieves and is notified of
system configuration parameter
changes and Stores configuration
data for the applications that run in
the system
ASR 5500
(active)
MIO
SCT
(standby)
MIO
RCT
hatctrl
hatcpu
Switch Fabric
CP0
CP0
CP0
hatcpu
hatcpu
hatcpu
CP1
CP1
CP1
hatcpu
hatcpu
hatcpu
DPC
DPC
DPC
1_1-21

Do Not Distribute
3-21
Putting Hardware and Software Together PGW Packet Flow

The diagram on the opposite page illustrates a simplified version of the interaction
between the hardware and the software on the ASR5500.
If focuses on a simple session in PGW scenario where control plane and data plane
sessions are being set up on the S5 interface. From the SGW a session setup is
signaled to the PGW as well as a need for a user plane on the S5 from the SGW to
the PGW. The PGW is of course building a connection to the PDN over the Sgi
interface
Here is a synopsis:
1. Bearer request is received by NPU from the S5 interface, recognized as an a
control signaling packet format it therefore must be sent to the appropriate

manager service for processing. In this case the egtpimgr. Had it been user
data it would have been sent to a gtpumgr. In all cases prior to invoking
session setup the NPU first checks to see if a flow is already established.
2. The egtpimgr and sessmgr are involved in the gtp exchange to set up a
bearer.
3. The aaamgr is involved in authenticating the user.

4. On successful authentication, a route to the destination context is found. This
results in a flow (data path) being created from the ingress port to the egress
port. This is the gtp-u connection and involves the switch hardware that is
hosted by the FSC module.
5. Subscriber session data follows the switch fabric path to an NPU on the MIO
likely on another port of the MIO.
6. Destination NPU sends data out egress port on daughter card.
3-22

Do Not Distribute
Putting Hardware and Software Together

PGW Packet Flow
FSC
FSC 1
1
FE
Control GTP-C V2
Data GTP-U V1
Data Raw IP Packets
FE
FAP
FAP
FAP
D-NPU
M-NPU
DDF
M-NPU
CPU
CPU
CPU
S
S
F
F
P
P
+
+
S5
S
S
F
F
P
P
+
+
MIO
MIO
egtpinmgr
vpnmgr
DPC
DPC DEMUX
DEMUX
FAP
D-NPU
DDF
aaamgr
CPU
se ssmgr
DPC
DPC
SGi
1_1-23

Do Not Distribute
3-23
Session Recovery
Session recovery is an optional feature that requires a license. Its purpose is to add
another level of fault tolerance such that no subscriber session will be lost if either a
hardware or software failure occurs.
It is supported both on the PGW, GGSN, and the PGW.
There are three important components to maintaining a subscribers data session in
the face of a system hardware or software failure. They are the:
session manager (sessmgr)
aaa manager (aaamgr)
demux function, which is a combination of VPN manager (vpnmgr) and the

signaling manager (gtpcmgr) (DEMUX) These reside on one of the DPC
cards called the Demux Card.
The slide on the opposite page shows how these items are related to each other.
A subscriber session exists in each of these components, and in such a way that if
one component is lost, it can be re-created from the remaining other two
components. These three functions are distributed across the hardware such that a
fault with one task can be recovered by pulling information from another task.
For example, the session state required to recover a Session Manager will be
maintained in its peer AAA Manager. The DEMUXMGR tasks were designed to
perform state recovery by retrieving state information from every Session Manager.
In short any two of the three session processes can rebuild the session.
3-24

Do Not Distribute
Session Recovery
There are three critical functions
needed to maintain a session:
sessmgr
aaamgr
sessmgr
aaamgr
demux managers (vpnmgr

plus signaling manager)
These critical tasks are
distributed across hardware
such that a fault with one task
will always allow its recovery
based on information pulled
from remaining tasks
vpnmgr
gtpcmgr
demux
1_1-25

Do Not Distribute
3-25
Session Recovery Basics

Session recovery is performed by mirroring key software processes within the
system. These mirrored processes remain in an idle state (standby-mode) until they
are needed in the case of a software failure.
The slide on the opposite page illustrates some basic changes that are made to the
system when session recovery is enabled. Most of what is listed below is initiated by
the resource manager that is running on the MIO module:
One active-mode DPC cards will be reserved for running demux tasks. No
session manager or aaa manager tasks are run on this card to avoid having 2
key processes running on the same hardware.
A standby-mode session manager is started on every CP in the system that

is available for Session Processing. In the case of a DPC there a 2 CPs. The
Session Controller maintains these standby-mode tasks in a fully configured
standby state (not processing calls). The standby-mode tasks are used to
recover failed managers on the same CP.
A full complement of standby-mode session managers and aaa managers is

started on the standby-mode PSC. The Session Controller maintains these
tasks in a fully-configured standby state (not processing calls but waiting in
the event of a board failure). These tasks will be used to recover failed
managers when a full DPC fails.
The Redundancy Control Task (RCT) is responsible for initiating and controlling
Session Recovery within the system.
The Session Controller (sessctrl) is responsible for monitoring the Session Recovery
process and performing cleanup if the recovery process fails for any reason.
3-26

Do Not Distribute
Session Recovery Basics

When session recovery is enabled:
sessmgr/aaamgr pairs are split and placed on separate DPC cards
vpnmgr and signaling managers are placed on a third DPC card
On standby DPC, standby sessmgr and aaamgr created with number of
instances equal to the maximum number of instances on any one active
DPC
vp
gr
nm
gr
nm
vp
Peer relationship
r
mg
pc
t
g
gr
sim
im
Active DPC
(demux card)
gr
m
ss ive)
e
s ct
(a
gr
am e)
aa ctiv
(a
gr )
sm by
s
se tand
(s
gr
am y)
aa ndb
a
(st
gr
m
ss ive)
e
s ct
(a
gr
am e)
aa ctiv
(a
gr )
sm by
s
se and
t
(s
gr
am y)
aa ndb
a
(st
Active DPC
Active DPC
gr
m )
ss dby
e
s an
t
(s
gr )
am y
aa ndb
ta
(s
Standby DPC
1_1-27

Do Not Distribute
3-27
Session Recovery: Task Recovery Mode

There are two modes of recovery:
Task recovery mode
Full DPC recover mode
The slide illustrates the first mode, or task recovery mode. In this mode, session
manager failures on a slot are recovered without the need of resources on the
standby DPC card. Recovery is performed by using the standby-mode session
manager that is already on each active DPC card. The standby-mode task is
renamed, made active, and is then populated using information from its associated
aaa manager and demux manager.
The session manager will update the per-call state record saved in the aaa manager
at various times during a call:
Call establishment
Call termination
Interim accounting update
CLI configured triggers
A recovering session manager will reject all new calls until the completion of the
recovery process, to ensure consistency between its database and the signaling
demultiplexer database.
The slide on the opposite page illustrates this task recovery mode.
3-28

Do Not Distribute
Session Recovery:
Task Recovery Mode
When a single session manager instance fails:
the standby sessmgr instance is used to replace it
The now-active sessmgr pulls session state info from peer aaamgr
instance and existing sessions are recovered
gr
nm
vp
Peer relationship
gr
nm
vp
Migration
gtp
gr
cm
g
sim
im
Active DPC
(demux card)
gr
m
ss ive)
e
t
s c
(a
gr
am e)
aa ctiv
(a
gr
m y)
ss db
e
s an
t
(s
gr
am y)
aa ndb
a
(st
gr
m
ss ive)
e
s ct
(a
gr
am e)
aa ctiv
(a
gr
m y)
ss db
e
s an
t
(s
gr
am y)
aa ndb
a
(st
Active DPC
Active DPC
gr
sm by)
s
se and
t
(s
gr
am y)
aa ndb
ta
(s
Standby DPC
1_1-29

Do Not Distribute
3-29
Session Recovery: DPC Full Recovery Mode

Full DPC recovery mode is used when a DPC hardware failure occurs. In this mode,
the standby DPC is made active and the session manager and aaa managers on
that card are all made active.
Each aaa manager and session manager will recover from the its counterpart that is
running on some other active DPC.
Because session recovery requires resources such as memory, CPU cycles and
NPU cycles, some additional hardware may be required to ensure that enough
resources are available to support this feature.
A minimum of four DPCs (three active and one standby) per chassis is required.
3-30

Do Not Distribute
Session Recovery:
DPC Full Recovery Mode
When a DPC card fails, many session, aaa, vpn and signaling managers can
be lost:
aaamgr and sessmgr instances recovered on standby DPC
Session state info pulled from peers on existing DPC cards
gr
nm
vp
Peer relationship
Migration
vp
gr
nm
r
mg
pc
gt
gr
sim
im
Active DPC
(demux card)
gr
sm e)
s
se ctiv
(a
gr
am ve)
a
a cti
(a
gr
sm by)
s
se and
t
(s
gr
am y)
aa ndb
a
(st
Active DPC
gr
m
ss ive)
e
s ct
(a
gr
am ve)
a
a cti
(a
gr )
sm by
s
d
se tan
(s
gr
am y)
aa ndb
a
(st
Active DPC
gr
m )
ss dby
e
s an
t
(s
gr )
am by
a
a nd
ta
(s
Standby DPC

Do Not Distribute
1_1-31
3-31
Session Recovery: DEMUX DPC Full Recovery Mode

Full DPC recovery mode is also used when a Demux DPC hardware failure occurs.
In this mode, the standby DPC is made active and the session manager and aaa
managers are deleted from it. The RCT and SCT tasks on the MIO will re-spawn the
signaling managers and vpn managers. The new vpn managers will retrieve state
info from the existing session managers. The loss of a demux DPC card will not
result in the loss of current session,s but may delay the establishment of any new
sessions until the demux card is fully recovered.
Because session recovery requires resources such as memory, CPU cycles and
NPU cycles, some additional hardware may be required to ensure that enough
resources are available to support this feature.
A minimum of four DPCs (three active and one standby) per chassis is required.
3-32

Do Not Distribute
Session Recovery:
DEMUX DPC Full Recovery Mode
When a DPC that is the demux card fails, only signaling managers will be lost:
aaamgr and sessmgr instances will be deleted from the standby DPC
Demux tasks and vpnmgrs will be re-spawned on the standby DPC
Vpnmgrs are re-created using RCT, SCT and controllers from MIO
gr
nm
vp
Peer relationship
Migration
gr
nm
vp
r
mg
pc
gt
g
sim
im
Active DPC
(demux card)
gr
m
ss ive)
e
s ct
(a
gr
am ve)
a
a cti
(a
gr
sm by)
s
se and
t
(s
gr
am y)
aa ndb
a
(st
gr
m
ss ive)
e
s ct
(a
gr
am ve)
a
a cti
(a
gr )
sm by
s
d
se tan
(s
gr
am y)
aa ndb
a
(st
Active DPC
Active DPC
gr
nm
vp
n
vp
r
mg
r
mg
pc
gt
(from MIO)
gr
sim
m
i
Standby DPC
1_1-33

Do Not Distribute
3-33
Session Recovery Another View

In the slide on the opposite page we are demonstrating the pairing of aaa and
session managers on different cards. Also note the location of the demux manager.
It will always locate to the lowest DPC that is in the chassis. Although not required
typically the standby DPC is in the highest DPC slot in the Chassis.
3-34

Do Not Distribute
Session Recovery Another View

From the CLI, the following command can be used to
view the distribution of critical call-processing tasks for
session recovery purposes:
[local]Training-School-9# show session recovery status verbose
Session Recovery Status:
Overall Status
: Ready For Recovery
Last Status Update
: 3 seconds ago
----sessmgr--- ----aaamgr---cpu state
active standby active standby
---- ------- ------ ------- ------ ----------3/0 Active
0
0
0
0
3/1 Active
0
0
0
0
4/0 Active
24
1
23
1
4/1 Active
24
1
25
1
7/0 Active
24
1
23
1
7/1 Active
24
1
25
1
8/0 Standby 0
24
0
23
8/1 Standby 0
24
0
25
Paired aaamgrs and sessmgrs on
unique processors or cards 24
active 1 standby
Standby PSC contains

demux
active
status
48 aaamgrs
and 48
-----sessmgrs-------------------3
5
0
0
0
0
0
0
Good (Demux)
Good (Demux)
Good
Good
Good
Good
Good
Good
contains a combination
of 8 contexts (vpnmgrs)
and services (gtpu)
1_1-35

Do Not Distribute
3-35
Session Redundancy with Redundant DPC Card

In the case of running redundancy mode with no redundancy card the attempt is
made by the ASR 5500 to run aaamgrs and sessmgrs on unique processors. This
adds to high availability in the event of a CPU failure on any one card. The
recommended configuration is 3 DPC Cards active and a forth in standby.
Note the system is telling you that this is not a supported redundancy configuration.
3-36

Do Not Distribute
Session Recovery without Standby Card

From the CLI, the following command can be used to
view the distribution of critical call-processing tasks for
session recovery purposes:
[local]Training# show session recovery status verbose
Cisco Systems ASR5500
[local]Training-School-9# show session recovery status verbose
Session Recovery Status:
Overall Status
Last Status Update
: SESSMGR/AAAMGR Pair Exists On Same Card!

: 0 seconds ago
----sessmgr--- ----aaamgr---cpu state

active standby active standby
---- ------- ------ ------- ------ ----------3/0 Active
0
0
0
0
3/1 Active
0
0
0
0
8/0 Active
24
1
24
1
8/1 Active
24
1
24
1
9/0 Standby 0
24
0
24
9/1 Standby 0
24
0
24
Paired aaamgrs and sessmgrs on
unique processors or cards 24
active 1 standby
demux
active
-----5
5
0
0
0
0
status
--------------------
Good (Demux)
Good (Demux)
Pair on same card
Pair on same card
Good
Good
Config contains 5
contexts (vpnmgrs)
and 5 unique services
1_1-37

Do Not Distribute
3-37
Cisco Software Licenses

Licenses are software mechanisms used to provide session limit controls and
enable special features within the system. These electronic licenses are stored in
the system's configuration file that is loaded each time the system is powered on or
restarted.
Session use licenses limit the number of concurrent sessions that a system is
capable of supporting per service type. They are typically acquired on an as-needed
basis. This allows carriers to pay only for what they are using and easily increase
capacity as their subscriber base grows.
Licenses are keyed to the serial numbers of the chassis on each chassis. This
makes the license unique for every system.
If a system boots with no license key installed, or an invalid license key is specified
in the configuration file, a set of default limited session use and feature licenses is
installed.
The following CLI command can be used to show the status of the license on the
system: show license info.
3-38

Do Not Distribute
Cisco Software Licenses

Two Major Categories are Licensed:
Features
Enabling call processing services on the system
Sessions
Limits the number of concurrent sessions that the system
is capable of supporting per service type
Licenses
Ships with every system
License key is part of the configuration file
Sessions are purchased in groups of 1,000 or 10,000
sessions
License is keyed to serial number of the chassis midplane on
system
Command used to see installed licenses: show license info
1_1-39

Do Not Distribute
3-39
Sample License
The output shown in the slide is a partial print-out of a license.
Some comments about what you are viewing:
3-40
The # key that begins each line is an indicator that the line is a comment,
and there for informational purposes only.
You can see the chassis serial number and model for the chassis
There is an expiration date supplied. On some licenses, there might not be

any expiration date.
The Key Number is unique for all licenses that have been generated.
The authorized feature, and its part number, are listed. Sometimes features
are sold in bundles.

Do Not Distribute
Sample License
The following slides show excerpts from a license
# ----- CUT HERE ----Key Information (installed key):
Comment
Full License for School 9 ASR5500
Chassis SN
FLM154300D8
Issued
Sunday January 13 12:11:47 EST 2013
Chassis backplane serial

number
Expires
Saturday July 13 13:11:47 EDT 2013
Issued By
Starent Networks
Key Number
57239
Enabled Features:
Feature
Applicable Part Numbers
----------------------------------------
-----------------------------
PDSN:
[ 600-00-7501 / 600-00-7504 ]
+ FA
[ None ]
Portions of the feature list not shown continued on next slide

1_1-41

Do Not Distribute
3-41
Sample License (contd)

The slide on the opposite page is a continuation of a license print-out from the
previous slide.
3-42
Everything you see is informational only (they are all commented lines).
The last part of the feature list, with associated part numbers, is shown at the
top.
Most importantly, the number of sessions allowed per feature are shown.

Do Not Distribute

SAE GW Bundle
UE Time Zone Reporting
Session Limits:
Sessions
-------100000
100000
300000
100000
100000
100000
100000
100000
CARD License Counts:
[ 600-20-0133 / 600-20-0131 ]
[ 600-20-0137 ]
Session Type
----------------------GGSN
L2TP LNS
Session
ECS
PGW
Serving GW base license
Combination 3G/4G Gateway
Direct LTE
SAE GW Bundle
limits per service
continued on next slide
1_1-43

Do Not Distribute
3-43

The slide on the opposite page shows the last portion of a license print-out, which is
a continuation from the previous slide.
The uncommented lines are the most important.
The first uncommented line is the configure command, which places the
system in global configuration mode.
The next nine lines are one CLI command: the license key command. It is
followed by the key that has been generated by Cisco (in quotes).
The last uncommented line is the end CLI command which instructs the
system to jump out of configuration mode.
The actual procedure to use to load this key is given on the next slide.
3-44

Do Not Distribute

In exec mode, paste contents of license file
#
[none]
#
configure
license key "\
VER=1|C1M=SanDiskSDCFJ-4096|C1S=116916I0207E2208|C2M=SanDiskSDCFJ-4096\
|C2S=012118H0607X0912|DOI=1202860133|DOE=1218584933|ISS=1|NUM=24715|CM\
T=Full_License_for_Training_Chassis_I|LSP=200000|LSH=100000|LSG=100000\
|LSL=100000|LSC=10000|LEC=10000|LSA=100000|FIS=Y|FR4=Y|FPP=Y|FTC=Y|FCR\
=Y|FSR=Y|FPM=Y|FID=Y|FI6=Y|FLI=Y|FPF=Y|FFA=Y|FCA=Y|FUT=Y|FSS=Y|FDA=Y|F\
DU=Y|FTP=Y|FDR=Y|BPP=Y|BSC=Y|FRC=Y|FMN=Y|FDC=Y|FGR=Y|FAA=Y|FDQ=Y|FEL=Y\
|FIN=Y|BEP=Y|FRO=Y|FAI=Y|LSW=100000|FCP=Y|FSN=Y|SIG=MC0CFQDbH7/KFgTANr\
TpJekHSccsbVHBwAIUD6GYJe07Mucyhu5GIyDwUIHKGOo
end
#
# ----- CUT HERE -----
1_1-45

Do Not Distribute
3-45
Obtaining Hardware Inventory for License Info

On the ASR 5500 the Licensing Serial number is kept on the Midplane it self. The
License needs to be generated off the Midplane component.
That being said the operator can remove any card from the system and the license
will stay with the chassis and the license keys associated with the chassis are not
affected. The License is not associated to any removable component.
Display the Serial number with: show hardware inventory
MEC (Midplane Equipment Component) - part number - serial number
3-46

Do Not Distribute
Obtaining Hardware Inventory License Info

[local]Training-School-9# show hardware inventory
Slot Type
Part Number Product ID / Version ID
Serial Num
CLEI code
---- ---- ----------------- ----------------------- ----------- ---------1: None
-----Chassis
2: None
---- serial number
-- for license
-3:
DPC
73-14233-03 A0
ASR55-DPC-K9 V03 SAD1606018Z
-CCK
73-14558-01 A0
--- SAD1603026T
-4:
DPC
73-14233-03 A0
ASR55-DPC-K9 V03 SAD160300KM
-CCK
73-14558-01 A0
--- SAD160202UC
-5:
MIO
73-14234-03 A0
ASR55-MIO-BASE-K9 V03 SAD154002AB
-XDC
73-14547-01 A0
--- SAD152302VA
-XDC
73-14547-01 A0
--- SAD15400277
-CCK
73-14548-01 A0
--- SAD15400295
-MEC
73-14501-01 A0
ASR55-MEC V01 FLM154300D8
-MIDP
73-14232-01 A0
--- TBM15471261
-CHAS
73-14344-01
ASR55-CHS-SYS V01 FLM160405P7
-6:
MIO
73-14234-03 A0
ASR55-MIO-BASE-K9 V03 SAD160200S9
-XDC
73-14547-01 A0
--- SAD154902YS
-XDC
73-14547-01 A0
--- SAD152701SN
-CCK
73-14548-01 A0
--- SAD153802ZM
---- ----------=
1_1-47

Do Not Distribute
3-47
Obtaining a License
The diagram on the opposite page shows the general procedure for obtaining a
license.
It begins by obtaining the serial numbers of the chassis backplane. This can be
done with the show hardware inventory CLI command,. You will need the serial
number and model of the chassis.
Then you decide what features you want to enable. In a GSM environment, you
would minimally purchase a license for the basic functionality (PGW and / or SGW
maybe SAEGW and GGSN as well).
For each service you would purchase a session limit license too. This is generally
done in increments of 10k users.
All of this information is then sent to Cisco, and a license will be generated using a
special license generating application.
A license key will be returned to you. This key must be integrated into your
configuration file so that it is read when the system boots.
3-48

Do Not Distribute
Obtaining a License
1) Get serial numbers for chassis using (CLI: show hardare
inventory)
2) Get list optional features that need licensing
3) Get number of user sessions per service
4) Using all of the above, get Cisco to generate a license
5) License key (text file) pasted into the config file on both MIOs
1
Backplane
1
Serial Number
Key Generation Tool

(Cisco Networks)
xGSN Session
Limit
(10,000 incr.)
3
2
Optional
Features
4
Session
License Number
Generated
5
License Key
Text File
(Can be placed into
configuration text file)
In-line Session
Limit
(10,000 incr.)
1_1-49

Do Not Distribute
3-49
Installing a New License

The general procedure to use for installing a license is outlined in the slide on the
opposite page.
The license key CLI command is used to add the license to the system. What is
actually happening is that you are adding a new line to the configuration file that is
read during system startup.
If the license you load does not match the system, you are given a thirty-day grace
period in which to fix the problem. In that time period, there is no limit to the number
of sessions that can be run against any service. After the thirty days has expired, the
system will not process any more new calls.
3-50

Do Not Distribute
Installing a New License
To install a new license, you:

Obtain the license key file from Cisco
Copy the contents between the cut here comments and
save in a buffer
Log into the ASR 5500 as administrator
At the CLI prompt, paste the contents of the saved buffer
Verify that the license is good (show license info)
Synchronize the file system so that the configuration file will
be copied to the flash card on the standby management
module
1_1-51

Do Not Distribute
3-51
Checking the License Status

The following command is used to check the license on a system:
show license info
The last portion of the output is shown on the opposite page. Note the last few lines.
They indicate that the serial numbers on the chassis that the license has not
expired.
3-52

Do Not Distribute
Checking the License Status
Use the show license info command to check

the licensing status of the system:
[local]Training-School-9# show license info

Key Information (installed key):
Comment
Full License for School 9 ASR5500
Chassis SN
FLM154300D8
Issued
Sunday January 13 12:11:47 EST 2013
Expires
Saturday July 13 13:11:47 EDT 2013
Chassis serial numbers
Issued By
Starent Networks
Key Number
57239
match those of license
NOTICE: The above features and limits have been reduced because this
license includes capabilities beyond what the ASR5500 supports.
Status:
Chassis MEC SN
Matches
License Status
Good
Not expired
1_1-53

Do Not Distribute
3-53
1_1-54
3-54

Do Not Distribute
Initial System
Configuration
Lesson 4

Do Not Distribute
4-1
Module Overview
In this module, we will take a look at getting the system booted.
The important stages of a system startup will be reviewed. This will lead to a look at
the file system on the flash cards that are located on the management modules. An
important file for proper system boot is the boot stack file. This will be introduced,
along with the commands used to modify it.
Initial configuration of a new ASR5000 will also be reviewed. There are two choices
for initially getting the ASR5000 started. You can manually configure the
management interfaces and accounts using the CLI, which implies knowledge of the
CLI. Or you can use the Quick Setup Wizard, which does not presume any previous
exposure to the CLI. Both of these options would typically be done via a connection
to the systems console port.
4-2

Do Not Distribute
Module Overview
Understanding the Boot Process and Boot Stack
File System Basics
Initial System Configuration Methods

Do Not Distribute
4-3
Booting the System

As mentioned in the slide on the opposite page, the boot process depicted on the
following slides is begun by either:
4-4
Placing the PFU power switches to the on position, which applies -48VDC to
the chassis.
Issuing the CLI reload or reboot command.
Pulling both management modules out and re-inserting them.

Do Not Distribute
Booting the System

The following three slides outline the boot process on a
ASR5500
The depicted boot procedure can be started a number of
ways:
DC power is applied to the chassis
The CLI reload command is issued

Do Not Distribute
4-5
System Power-on Sequence (1)

The initial boot-up events are depicted in the slide:
4-6
The MIO is the management module for the ASR5500 (System Management
Card).
Only slots 5 and 6 initially receive power. Power to the other slots in the
chassis will be applied by whichever management module becomes the
active one. In the case of the ASR5500 it will default to the lower slot or slot 5
if that slot is populated with a MIO.
Details of the boot stack are discussed later in this module.
The management module that is the second to boot (standby) pulls its image
from memory of the management module that is the first to boot (active). This
guarantees that both modules will be using the same binary image.

Do Not Distribute

Power applied to chassis or
reload CLI command executed
Slots 5 and 6 (MIO) receive power,)
MIOs perform POST

Upon successful POST, MIO in lower of
two slots begins boot process:
- boot stack read
- card placed in Active mode
Once active MIO begins loading StarOS
image, the standby MIO boots from the
StarOS image on active MIO, and is placed in
Standby mode
(next slide)

Do Not Distribute
4-7

Some comments:
4-8
The card slot port manager (cspmgr) on the management module is very
involved in bringing the other application cards online.
After a DPC and SFC card completes its power-on self tests it is brought into
a Ready state. The STAR-OS is then loaded..

Do Not Distribute

(previous slide)
Active MIO triggers power to be applied
to remaining chassis slots, and waits for
a signal indicating card is installed:
Is card Installed?
no
yes
MIO signals DPC and SFC

to begin POST
DPCs placed into Standby state
SFCs placed in Standby state
(next slide)

Do Not Distribute
4-9

The final stages of the boot are depicted in this slide:
4-10
The binary image loaded by the DPC and SFC control processor is the same
binary image that is running on the management card. . It is loaded across
the control (internal Ethernet) bus.
Although the binary image on the DPC and SFC control processor are
identical to that running on the management module, the startup sequence is
different which results in a different set of tasks being initialized.
The final tasks created on a DPC and FSC cards are directly related to the
contents of the configuration file. Based on this file, the controller processes
on the management module will spawn manager tasks as required.

Do Not Distribute
(previous slide)
Each Control Processor (CP) of each
DPC and FSC receives binary image
from active management module
Required software tasks
started on each DPC and
FSC
Power on Sequence Complete

Do Not Distribute
11
4-11
Understanding the Boot Stack

The flash card on the management module can contain multiple binary images and
multiple configuration files. Which combination of image/configuration is actually
loaded is determined by the boot stack file. This is a file on the flash called boot.sys.
If boot.sys is deleted from one flash card, the system will initially look on slot 5 for a
binary image called asr5500.bin or system.bin and a config file called system.cfg.
If none of these are found, it uses the boot.sys on slot 6.
If no boot.sys file is found on either flash card, the boot process hangs indefinitely. A
Cisco customer service representative will then be needed to resolve this issue.
Parameters inside the boot.sys file contain information needed by the system to
locate the operating system image file, including:
Bootmode - This setting is typically configured to normal, and is used to

identify how the system should start.
network interface configuration - These optional boot method settings are

used when the system is configured to obtain its operating system image from
an external network server using one of the management LAN interfaces on
the SPIO card.
terminal-speed configuration - This parameter identifies the data transfer

rate at which a serial interface communicates on the Console port. The
default setting for this parameter is 115200 bps (115.2 Kbps). Other serial
communication parameters may also be included in this area. These settings
can be changed using RS-232 Port Configuration Mode commands.
boot stack information - The boot stack is made up of prioritized file group
entries that designate the operating system image file and the CLI
configuration file to load.
4-12

Do Not Distribute
Understanding the Boot Stack

The boot stack is a file on the flash that is consulted by the operating
system during boot
It provides a prioritized list of images and configuration files that the
system should attempt to load
The name of the boot stack file is boot.sys
[local]Training# dir /flash
drwxrwxr-x
2 root
root
--rwxrwxr-x
1 root
root
-rwxrwxr-x
1 root
root
-rwxrwxr-x
1 root
root
drwxrwxr-x
2 root
root
-rwxrwxr-x
1 root
root
-rwxrwxr-x
1 root
root
32768
6527
592
3920672
32768
3350
5559
Jun
Jul
Aug
Jul
Jul
May
Aug
25
23
7
25
25
28
7
10:42
10:33
20:54
13:57
13:57
14:00
09:54
12.2-builds
asn_base.cfg
boot.sys
crashlog2
crsh2
system.cfg
vpn-startup.cfg
Boot stack file

Do Not Distribute
13
4-13
Viewing the Boot Stack

The contents of the boot stack can be viewed using the show boot CLI command.
The first line in this file displays the configured Ethernet interface that would be used
if the system was to boot from a network server. This is rarely done in the field.
The remaining lines represent a prioritized list of image/conf files that should be
used, with the lowest assigned priority number being the most-preferred.
4-14

Do Not Distribute
Viewing the Boot Stack

Some important points about the boot stack:
Use the show boot command to view the contents of the boot
stack file
Use the show boot init command to see what was actually
loaded during the last boot
Path to and name of binary image
[local]Trng-9# show boot
boot system priority 30 \
image /flash/14-0-builds/production.48814.asr5500.bin \
config /flash/epc-pcrf-startup.cfg
boot system priority 40 \
image /flash/14-0-builds/production.48814.asr5500.bin \
config /flash/startup-5500.cfg
Path to and name of config file

Do Not Distribute
15
4-15
Changing the Boot Stack

You can change the image/config file combination that is used by adding a new
entry (of lower priority) to the boot stack. The slide on the opposite page shows the
configuration commands that are needed in order to add an entry into the boot stack
file.
Adding an entry with a lower priority number will change the systems behavior on
re-boot. Adding an entry with a higher priority number will not change the systems
behavior on re-boot.
Adding an entry with a priority number that is already in use will overwrite the
existing entry.
If the boot image for an entry cannot be found, the system skips to the next entry in
the boot stack.
If the config file for an entry cannot be found, the system will try to find the config file
on the backup flash. If this cannot be done the system will assume this is a new
system and start the Quick Setup Wizard.
4-16

Do Not Distribute
Changing the Boot Stack

Changing the contents of boot.sys is done within the CLI configuration
mode
In configuration mode, you add a new priority number with the
appropriate binary image name and configuration file name:
Adding an entry to boot.sys
[local]ST40_Training# config
[local]ST40_Training(config)# boot sys priority 10
image /flash/14-builds/production.48814.asr5500.bin
config /flash/start_base.cfg
Deleting an entry from boot.sys
[local]ST40_Training# config
[local]ST40_Training(config)# no boot sys priority 10

Do Not Distribute
17
4-17
The System Configuration File

The configuration file that is specified in the boot stack is not complicated. It is a flat
ASCII file which contains multiple lines of CLI commands. When read and executed,
a complete system configuration is done.
Configuration files can be identified by the .cfg extension.
The configuration file can be FTPd to and from the system, and edited using any
text editor. However, care should be taken to not introduce extraneous characters or
words as this might adversely affect the boot process.
All configuration commands that are entered during a CLI session are stored in
memory and later saved to a file on the flash. The slide shows a sample CLI session
and its result when saved into a configuration file.
There is not any database maintained on the system. Instead, the configuration file
is used to completely re-build the system during initialization.
4-18

Do Not Distribute
The System Configuration File

Here are some basic characteristics of the configuration file on the
system:
Contains configuration commands and variables that, when parsed, are
executed as if manually entered through the CLI
Can be created using a standard text editor
Usually ends in .cfg
[local]host_name# config
[local]host_name(config)# context
source
[local]host_name(config)# end
/flash/myconfig.cfg
Placed in a text file

on flash
# this is a comment
config
context source
end

Do Not Distribute
19
4-19
Sample Configuration File

A sample configuration file is shown in this slide. Some points of interest:
4-20
Aside from remarks, the first line in any configuration file should be the
config command.
The active management module will read this file line-by-line, and execute
each command.
The #exit line is an implied exit from the present configuration mode.
The indentations shown are significant. The represent changes in

configuration modes. The various configuration modes available are
discussed later in the course.

Do Not Distribute
Sample Configuration File

config
context local
interface LOCAL1
ip address 192.168.1.150 255.255.255.0
#exit
subscriber default
#exit
administrator test_admin encrypted password
fd01268373c5da85
operator test_operator encrypted password
148661a0bb12cd59
port ethernet 5/1
Indentations are significant: they
no shutdown
indicate config mode changes
bind interface LOCAL1 local
#exit
end

Do Not Distribute
21
4-21
Saving the Configuration

This slide shows the CLI command for saving a configuration.
All configurations are stored to the flash card.
The available variables to the save config command are defined in the following
table:
Keyword/
Variable
Description
-redundant
Optional: This keyword directs the system to save the CLI

configuration file to the local device, defined by the url variable,
and then automatically copy that same file to the like device on the
Standby MIO, if available.
Note: This keyword will only work for like local devices that are
located on both the active and standby MIOs. For example, if you
save the file to the /USB device on the active MIO, that same type
of device (a USB-Card in the standby MIO) must be available.
Otherwise, a failure message is displayed. Note: If saving the file
to an external network (non-local) device, the system disregards
this keyword.
-noconfirm
Optional: Indicates that no confirmation is to be given prior to

saving the configuration information to the specified filename (if
one was specified) or to the currently active configuration file (if
none was specified).
Optional: This keyword causes the CLI configuration file to be

showsecrets saved with all passwords in plain text, rather than their default
encrypted format.
verbose
4-22
Optional: Specifies that every parameter that is being saved to the

new configuration file should be displayed.

Do Not Distribute
Saving the Configuration

Any change made to the system configuration takes effect immediately
However, the running configuration only exists in memory and is not
automatically saved to the flash card on the management module
To save the running configuration to flash, use the save configuration
command:
Displays passwords and
security keys in config file
Saves config to both MIOs
save config /flash/myconfig.cfg -redundant
MIO
Slot
5 CompactFlash
myconfig .cfg
config
system hostname Training
context local
administrator admin password 5c4a38dc2ff61f72
end
MIO Slot
6 CompactFlash
myconfig .cfg
config
system hostname Training
context local
administrator admin password 5c4a38dc2ff61f72
end

Do Not Distribute
23
4-23
System Image File

The system boots using only one binary image. Although multiple software images
can be stored on the flash, only one can be specified per boot stack entry.
This file usually ends in .bin and is usually obtained from the Cisco website (with
appropriate login credentials).
4-24

Do Not Distribute
System Image File

The operating system software image is another important file on the
system
Some basic characteristics:
Identified by a .bin extension
Is between 170Mb and 200Mb in size
Typically obtained from the Cisco website
Binary images on flash
[local]Trng-9# dir /flash/14-0-builds

-rwxrwxr-x
1 root
root
170797568 Jul 23 2012 production.44554.asr5500.bin
-rwxrwxr-x
1 root
root
171747840 Sep 18 2012 production.45221.asr5500.bin
-rwxrwxr-x
1 root
root
175760384 Mar 19 12:36 production.48376.asr5500.bin
-rwxrwxr-x
1 root
root
176269312 Mar 29 08:02 production.48814.asr5500.bin
678400 /flash/14-0-builds
Filesystem
1k-blocks
/var/run/storage/flash/part1 31154688
837440 30317248
3%
/mnt/user/.auto/onboard/flash

Do Not Distribute
25
4-25
Synchronizing File Systems

On a working system, only the flash card on the active management module can be
used. The system does not automatically write to the standby flash card.
But it is important that both flash cards contain the same images, configuration files,
and boot stack files. Making the flash card contents identical is done with the card
synchronization command, as shown in the slide.
Other variables that can be used with the filesystem synchronize command are:
Keyword/Variable
Description
all
Specifies that file systems on all available matching local

devices (be synchronized.
Only file systems on matching local devices will be
synchronized. For example, if the active MIO contains two local
devices (/flash and /USB) and the standby MIO contains only
one local device (/flash), then synchronization would only occur
on the matching local device (i.e. /flash).
checkonly
Displays a list of files that can be synchronized without

executing any synchronization actions.
from
Specifies the source MIO for the synchronization process.
to
Specifies the destination MIO for the synchronization process
-noconfirm
This keyword disables the Are you sure? [Yes | No]

confirmation prompt, asked before executing the command
4-26

Do Not Distribute
Synchronizing File Systems

Saving a configuration to flash actually writes it to the flash card of the
active management module; it is not written to the flash card of the
standby management module
Likewise, copying a new binary image to the system is actually writing it
to the flash card on the active management module, not to the flash
card on the standby management module
To ensure that both flash cards contain the same information, you must
synchronize the filesystem:
filesystem synchronize

Do Not Distribute
27
4-27
Initial Connection
On a new system, a proper IP address will probably not be configured. In order to
change or verify this, you will need to connect your PC to the console port and see
what is actually there.
This slide shows where you will make this connection and what asynchronous
terminal settings you should use.
4-28

Do Not Distribute
Initial Connection
On a new system, the

management IP address will not
be configured or, if configured,
will probably not match your
network requirements
Your first action should be to

connect to the console port and
see what is there
ASR 5500
Rear
Console port settings are:

data rate 115,200 baud
8 data bits
no parity
1 stop bit
no flow control
console port on
active MIO
Management
LAN Interfaces

Do Not Distribute
29
4-29
Initial Configuration Methods

On a new system, it is important to have some basic configuration parameters
available. The most important information is the IP address/mask of one Ethernet
management port and an account name/password that can be used to log into the
switch. Other important worksheet entries are shown in the slide.
From the console, you will be asked to log in using an account username/password
combination. This is part of the configuration file that the system is using. If the
system cannot find a configuration file, it will start up the Quick Setup Wizard which
will prompt you for the basic parameters needed. Details of this are on the following
slides.
If you dont want to use the Quick Setup Wizard, you can log in and execute the
necessary CLI commands manually. But this presumes that you already know the
CLI syntax.
4-30

Do Not Distribute
Initial Configuration Methods
There are two ways to initially configure the system:

Using the Quick Setup Wizard requires no knowledge of
the CLI
Manually entering the proper CLI configuration commands
requires knowledge of the CLI
In either case, it is good to have a Setup Worksheet that

outlines:
Administrator account information
System name
Management network interface information (MIO port, IP
address/mask)
Remote access information

Do Not Distribute
31
4-31
Quick Setup Wizard

The slide shows some sample output at the console port. Notice that there is a
message indicating that the configuration file in the boot stack could not be found.
This will cause the system to switch to the Quick Setup Wizard, the first step of
which is shown in the slide.
4-32

Do Not Distribute
Quick Setup Wizard

If StarOS cannot find the config file specified in the boot.sys, it will start
the Quick Setup Wizard at the console port
The Quick Setup Wizard assumes that the system chassis needs some
initial configuration and queries the user for management-related items
[LOCAL PRINT] 2008-Jul-01+09:19:34.800 [cli 30006 info]

[8/0/1140 <cli:0> cli_boot.c:40] [software internal system
critical-info] Unable to read the specified configuration file
</flash/training_test.cfg>
1. Do you wish to continue with the Quick Setup Wizard[yes/no]:

Start of Quick
Setup Wizard

Do Not Distribute
33
4-33
Manually Starting the Wizard

The Quick Setup Wizard can be started anytime after you log in to the switch with
the setup CLI command.
A sample run of the Wizard is shown on the next slide. By default, all entries that
you make using the Wizard are saved on the flash to a configuration file called
system.cfg.
4-34

Do Not Distribute
Manually Starting the Wizard

The Quick Setup Wizard can be started anytime after
StarOS has booted
After logging in with administrator privilege, use the
setup command:
[local]asr5500# setup
1. Do you wish to continue with the Quick Setup Wizard[yes/no]:
The quick setup wizard automatically saves all

configuration parameters to a file called system.cfg,
on the flash of the active MIO module.

Do Not Distribute
35
4-35
Quick Setup Wizard Details

This is a portion of the run of the Wizard. The following is being configured:
4-36
An account with administrator privilege, and a password
System name
Port on the spio card that will be used for management access
IP address of this management port

Do Not Distribute
Quick Setup Wizard Details

The following is a sample run of the Quick Setup Wizard:
[local]Trng-9# setup
1. Do you wish to continue with the Quick Setup Wizard[yes/no]: yes
2. Enable basic configuration[yes/no]: yes
3. Change chassis key value[yes/no]: no
5. local context administrator username[admin]: admin
6. local context administrator password: starent
7. confirm local context administrator password: starent
8. hostname[asr5500]: asr5500
9. Enable LOCAL interface[yes/no]: yes
10. Enable Which LOCAL Ethernet Port[LOCAL1/LOCAL2]: LOCAL1
11. Enable Which LOCAL Port Media[rj45]: rj45
12. LOCAL Out of band Ip Address: 192.168.1.150
13. LOCAL Out of band subnet mask: 255.255.255.0

Do Not Distribute
37
4-37
Quick Setup Wizard Details (cont)

This slide shows that latter stages of a run of the Wizard. The following is being
configured:
Default route defined
SSH access enabled
SFTP access enabled
Telnet access disabled
FTP access enabled
Additionally, you are given the opportunity to review, or change, any of your settings.
4-38

Do Not Distribute
Quick Setup Wizard Details (cont)

14. Default gateway Ip Address: 192.168.1.1
15. Enable remote access[yes/no]: yes
16. Enable sshd[yes/no]: yes
17. Enable which sshd protocol[v2/v1/both]: both
18. Enable sftp server[yes/no]: yes
19. Enable telnetd[yes/no]: yes
20. Enable ftpd[yes/no]: yes
Do you want to review your selections[no/yes]: yes
Which selection do you wish to
review[1,2,7,8,9,10,11,12,13,14,15,16,17,18,19,20,done]: done

Do Not Distribute
39
4-39
Summary of Initial Configuration

The steps shown in the slide represent a summary of what has been covered in this
module, and also define the tasks you would need to do in order to get a new
system ready for remote management access, and further configuration.
4-40

Do Not Distribute
Summary of Initial Configuration
The following outlines the steps that are generally needed

for first-time configuration of the system:
1. Attach a serial cable to the console port of the system
2. Set the baud rate to: 115,200 baud, 8 data bits, no parity, 1 stop
bit, no flow control
3. Apply power to the system, and observe boot-up process
4. Perform initial configuration by:
Running Quick Setup Wizard
Manually entering proper configuration commands
5. Save configuration to file on flash
6. Synchronize file system

Do Not Distribute
41
4-41
4-42
42

Do Not Distribute
StarOS CLI and Global

Configuration Setttings
Lesson 5

Do Not Distribute
5-1
Module Objectives
5-2

Do Not Distribute
Module Objectives
Upon completing this lesson, you will be able to meet
these objectives:
Describe the architecture of the Command Line Interface
Users Permissions
Config Modes
Access Privilliges
Be able to set up global parameters using the CLI
SNMP
Time/Date .
1_1-3

Do Not Distribute
5-3
Module Agenda
5-4

Do Not Distribute
Module Agenda
Command Line Interface (CLI) Operation
CLI Global Commands
Summary
Lab1: Introduction to the CLI Hardware overview
1_1-5

Do Not Distribute
5-5
CLI Command Modes

There are two basic command modes on the ASR 5500:
5-6
Exec Mode - this is the mode into which you are placed upon successfully
logging in. Since the account used for login has a specific set of privileges
associated with it, you will be logged in with those privileges.
Config Mode - entered by executing the config command. This is a writeonly mode; you cannot execute any show commands while in this mode.
Used to change configuration parameters of any sub-system. In terms of
account privilege levels, you must have either administrator or configadministrator rights to use this command.

Do Not Distribute
CLI Command Modes

Command Modes
Exec (Execute) Mode default mode on login
Config (Configuration) Mode entered by typing config
command, available only to users with administrator or
configuration administrator privilege
[local]Training-School-9(config)#
Configuration sub-modes once you are in configuration
mode, you can drop further into certain subsystems:
[local]Training-School-9(config)# card 4
[local]Training(config-card-4)#
1_1-7

Do Not Distribute
5-7
CLI Command Hierarchy

The slide on the opposite page illustrates an important concept: configuration submodes. When you enter the config command, you are actually entering a global
configuration mode. In this mode, you can set many parameters but, in general, they
are global to the switch and do not pertain to any specific port, interface or service.
From global configuration mode, you can enter sub-modes of configuration. For
instance, if you enter a card command (followed by a slot number) you will be
placed in a configuration mode where you have access to all card-related
information. Likewise, if you enter a port ethernet command (followed by a port
identifier) you will be placed in a configuration mode where you have access to all
port-related information.
Much of the configuration work on the ASR 5500 involves moving from one
configuration mode to another.
5-8

Do Not Distribute
CLI Command Hierarchy

Exec Mode
Enter config mode
ip access-list name
ACL
Configuration
Mode
GGSN servicename
GGSN Service
Configuration
Mode
configure
Global
Configuration
Mode
port ethernet slot/port
Sub-modes available
in config mode
Def ault entry point into

system for all users
Accessible to all
Administrator users
Ethernet Port
Conf iguration
Mode
card number
Card
Conf iguration
Mode
context name
Context
Conf iguration
Mode
SS7 Routing Dom ain
Service
Configuration
Mode
server telnetd
Telnet
Configuration
Mode
1_1-9

Do Not Distribute
5-9
Administrative User Types

From a management perspective, there are two fundamental methods of
administering user accounts on the ASR 5500:
Context-level
ANSI T1.276
A context-level user type is usually (but not exclusively) configured within the local
context. For authentication purposes, this type of user relies on the local AAA
subsystem (aaamgr) for validating usernames and passwords during login.
Passwords for are context-level user are assigned once and are accessible in the
configuration file. This type of user is the most common.
An ANSI T1.276 user type provides support for ANSI T1.276-2003 password
security protection. Account information (passwords, password history, lockout
states, etc.) for this type of user is maintained in non-volatile memory on the
CompactFlash. This information is maintained in a separate file, not in configuration
files used by the system. As such, the configured ANSI T1.276 accounts are not
visible in the system configuration.
5-10

Do Not Distribute
Administrative User Types

Context-level administrative users
Configured at the context-level.
usernames and passwords are validated during login by the systems
AAA subsystem.
True for both administrative user accounts configured locally
through a configuration file or on an external RADIUS server.
Passwords for these user types are assigned once and are
accessible in the configuration file.
Local-users (ANSI T1.276-2003 support)

Account information is maintained in a separate file in non-volatile
memory on the CompactFlash module and in the softwares Shared
Configuration Task (SCT).
Local-user accounts are not visible with the rest of the system
configuration.
1_1-11

Do Not Distribute
5-11
Context-level User Privileges

A context-level management user is assigned certain rights by virtue of the account
they use and the privilege level associated with that account. The ASR 5500
supports four privilege levels:
Security Administrator - has read-write privileges and can execute all CLI
commands including those available to Administrators, Operators, and
Inspectors. This type of user can create new user accounts.
Administrator - has read-write privileges and can execute any command

throughout the CLI except for a few security-related commands that can only
be configured by Security Administrators. Administrators can configure or
modify the system and are able to execute all system commands, including
those available to the Operators and Inspectors.
Operator - has read-only privileges to a larger subset of the Exec Mode

commands. They can execute all commands that are part of the inspector
mode, plus some system monitoring, statistic, and fault management
functions such as resetting a card. Operators do not have the ability to enter
the Config Mode.
Inspector - is limited to a small number of read-only Exec Mode commands.

The bulk of these are show commands giving the inspector the ability to view
a variety of statistics and conditions. The Inspector cannot execute show
configuration commands and does not have the privilege to enter the Config
Mode.
The diagram on the opposite page illustrates the relationship between these four
privilege levels
5-12

Do Not Distribute
Context-Level User Privileges

In addition to the context configured by the Quick Setup
Wizard, additional context-level administrative user types can
be configured
User accounts are created with a pre-assigned privilege level;
there are four possible privilege levels:
Administrator
Config-Administrator
Operator
Inspector
Administrator
Exec Mode
Config Mode
Operator
Inspector
1_1-13

Do Not Distribute
5-13
ANS T1.276 User Type Mapping

When the ANSI T1.276 standard was implemented on the ASR 5500, the privilege
levels defined by the standard were re-mapped. The table on the opposite page
shows this.
The left-most column shows the privilege levels as defined by the standard. The
middle column shows how they map into the operating system of the ASR 5500.
The right-most column shows how they compare with the context-level privileges
just discussed on the previous slide.
5-14

Do Not Distribute
ANSI T1.276 User Type Mapping

User Type as Defined
by T1.276-2003
System Security
Administrator
Application Security
Administrator
System
Administrator
Application
Administrator
Application
User/Operator
not applicable
T1.276 User
Types on ASR 5500
Context-Level User
Types
Security
Administrator
Security
Administrator
Administrator
Administrator
Administrator
Operator
Operator
Inspector
Inspector
Administrator
1_1-15

Do Not Distribute
5-15
CLI Instances
The ASR 5500 can support multiple CLI user sessions. The number of guaranteed
sessions are shown in the slide.
CLI sessions consume memory on the management module. When memory
becomes scarce, the session is no longer assured. In this situation, the user is
prompted when they log in as to whether or not they want to continue. If they do
continue, their session may be unexpectedly dropped because the operating system
has re-claimed some memory.
The users to log on last (over the assured limit) are the first to be dropped.
Limiting number of CLI sessions is done by changing max-session parameter (as
long as you have administrator privilege).
5-16

Do Not Distribute
CLI Instances
Multiple CLI sessions can by hosted by the ASR 5500,
with a minimum number assured:
15 assured sessions on the ASR 5500
CLI session consume memory on the MIO

When memory becomes scarce, and the user attempts
to establish a CLI session, the user will be prompted as
to whether or not they want to continue with the
session
1_1-17

Do Not Distribute
5-17
CLI Command Prompt

The prompt that is presented to a CLI user has significance. The slide shows a
typical prompt and explains its meaning. The prompt is designed to inform the user
exactly where they are located within the CLI, the command mode they are in, and
their user privilege.
The example shown on the opposite page is of a user in global configuration mode.
If the user were to go into a configuration sub-mode, the parenthetical portion
(config) of the prompt would change to reflect this.
5-18

Do Not Distribute
CLI Command Prompt

Context Pointer:
Shows the context
in which the user is
currently working.
Command Mode:
Shows the specific command
mode or sub-mode in which
the user is currently working.
[local] host_name (config) #

System Host Name:
Shows the currently
configured host name.
User Privilege Indicator:

Indicates the user mode.
# indicates administrator / config-administrator privileges
> indicates inspector / operator privileges only
1_1-19

Do Not Distribute
5-19
CLI Command Syntax

There are various command components (or structures) the user should be familiar
with prior to using the CLI. These include:
5-20
Commands: Specific words that precede, or initiate, a specific function.
Keywords: Specific words that follow a command to more clearly dictate the
commands function.
Variables: Values, some alpha, numeric, or alphanumeric, that are usersupplied as part of the command syntax. Sometimes referred to as
arguments, these terms further specify the command function.

Do Not Distribute
CLI Command Syntax

Commands
Base, or root, commands (Example: show)
Keywords
Ancillary commands, added to base commands (Example:
show version)
Variables
Often called arguments, these are the settings for the
command(s) issued (Example: show card info 8)
1_1-21

Do Not Distribute
5-21
CLI Documentation Syntax

When accessing the Cisco user documentation, there are certain conventions used.
Some of these conventions are mentioned on the opposite page. The table below
expands on this:
Command
Syntax
Conventions
Description
{ keyword or
variable }
Required keywords and variables are surrounded by grouped

brackets. Required keywords and variables are those
components that are required to be entered as part of the
command syntax.
[ keyword or
variable ]
Optional keywords or variables, or those that a user may or may

not choose to use, are surrounded by square brackets.
With some commands there may be a group of variables, from

which the user chooses one. These are called alternative
variables and are documented by separating each variable with
a vertical bar (also known as a pipe filter).
Pipe filters can be used in conjunction with required or optional
keywords or variables. For example:
{ nonce | timestamp }
OR
[ count number_of_packets | size number_of_bytes ]
5-22

Do Not Distribute
CLI Documentation Syntax

ping host_ip_address [ count num_packets ] [ pattern packet_pattern ]
[ size octet_count ] [ src { src_host_name | src_host_ip_address } ]
[ | { grep grep_options | more } ]
Commands and keywords are always bold-faced

Variables are always italicized
{ } Grouped brackets indicate that it is required
[ ] Square brackets indicate that it is optional
| Pipe filters separate optional keywords or variables
1_1-23

Do Not Distribute
5-23
CLI Hints
While fully typing each command keyword, argument, and variable is acceptable, it
can be time-consuming and increases the chance of making mistakes. The CLI
therefore supports a number of features designed to assist users in entering
commands quickly and with more accuracy. Other features improve users ability to
view the display and review previously entered commands.
The slide presents some useful hints about how to efficiently use the CLI on the
ASR 5500.
Many CLI commands allow for using the | grep and/or the | more keywords. These
keywords allow you to regulate or control the commands output.
Using the | grep keyword allows you to filter through a commands output for certain
expressions or patterns. Only those portions of the output either containing or
excluding the pattern is displayed. The | grep has the following syntax:
Alternative
Keyword
Description
-i
Specifies the filtering of the commands output for a particular

expression while ignoring case (lower case matches the same as
upper case).
-v
Specifies the filtering of the commands output for everything

excluding a particular expression.
--ignorecase
The long form of the -i option.
--invertmatch
The long form of the -v option.
expression
Specifies the character pattern to find in the commands output.
5-24

Do Not Distribute
CLI Hints
CLI command auto-completion use <tab> key
Regulating output pipe to grep | grep <text>
Command history use up/down arrow keys
CLI help use ?
Exiting config or config sub-modes can be done two ways:
exit moves you up one level
end puts you out of config mode, regardless of level you are
presently in
1_1-25

Do Not Distribute
5-25
Module Agenda
5-26

Do Not Distribute
Module Agenda
StarOS Command Line Interface Introduction
CLI Global Commands
Summary
Lab1: Introduction to the CLI Hardware overview
1_1-27

Do Not Distribute
5-27
Global Parameters
The architecture of the ASR5500 is designed to be very structured around the
concept of a context that will be covered in following modules. This concept isolates
function and provides a method of organization. There are however some functions
that are box wide. In this section we will hit on some of the typical globally available
configuration parameters that are often found in the default context.
5-28

Do Not Distribute
Global Parameters
Configuring Global System Settings
Configuring System Timing
Enabling CLI Timestamping
Enabling CLI Session Options
Configuring Additional Context-level Administrative Users
Configuring System-level Administrative Users
Configuring DPC and Line Card Availability
Configuring LC Port Redundancy
Card Migration & Switchover Commands
Enabling Session Recovery
Configuring System Management Settings

Configuring SNMP
1_1-29

Do Not Distribute
5-29
Configuring System Settings: System Timing

The system is equipped with a system clock that supplies the timestamp for statistic
counters, accounting records, logging, and event notification. After the initial
configuration of the system clock, the system can be configured to communicate
with a Network Time Protocol (NTP) server on the network to ensure that the clock
is always accurate.
In the event of a power outage, the clock will be maintained with an accuracy of +/one minute per month for up to 10 years. This ensures that when power is restored,
the system will be fully ready to process sessions and generate accounting, log, and
event data with accurate timestamps.
The systems time zone must be configured first, and then an NTP server defined.
When configuring the time zone, use on-line help to determine the proper syntax for
specifying the time zone. It is also a good idea to configure the local clock before
connecting to the NTP server so that the time period that must be corrected does
not exceed the tolerances of the NTP server. Two NTP servers are recommended.
NTP server configuration details are shown in the table below:
Keyword/Variable
Description
ip_address
Specifies the IP address of the NTP server in dotted decimal notation

(###.###.###.###).
prefer
Sets a configured NTP server as the preferred server.

Use of this keyword is not recommended. The NTP server will provide better
time synchronization without the prefer option.
version
ntp_version
Specifies the version of NTP that is supported by the NTP server. Versions 1
through 4 are supported. The default version is 4.
minpoll
poll_period
Specifies the minimum polling interval for NTP messages, in seconds, as a

power of 2. poll_period is the power or exponent. For example, if you
specify the number 10, the value is 2^10 and the resultant poll period is 1024
seconds. poll_period must be an integer from 6 through 17. The default is
6.
maxpoll
poll_period
Specifies the maximum polling interval for NTP messages, in seconds, as a

power of 2. poll_period is the power or exponent. For example, if you
specify the number 10, the value is 2^10 and the resultant poll period is 1024
seconds. poll_period must be an integer from 6 through 17. The default is
10.
5-30

Do Not Distribute
Configuring System Settings:

System Timing
Involves setting system clock and timezone
System clock maintains accuracy of +/- one minute per month for up to
10 years in the event of a power outage
NTP usually used to keep the system clock in sync
clock set YYYY:MM:DD:HH:MM:SS
configure
clock timezone ?
clock timezone <timezone>
ntp
enable
server x.x.x.x
end
show clock
IP address of NTP server
show ntp status
1_1-31

Do Not Distribute
5-31
Configuring System Settings: CLI Timestamping

The system is capable of displaying a timestamp (date and time) for every
command that is executed on the CLI.
In order to enable CLI activity logging, you must be logged into an account that has
administrator or config-administrator privileges.
Executing the timestamps command within your CLI session will enable
timestamping for your session only. If you quit your session, timestamps will again
be disabled.
In order to enable timestamps for all users, you must go into configuration mode and
execute the timestamps command. After that, all new CLI users will have
timestamps enabled (existing users will not).
5-32

Do Not Distribute

CLI Timestamping
Displays a timestamp for every executed command
Could be useful for debugging
timestamps
Enables timestamp for

this CLI session
configure
timestamps
Enables timestamp for

all new CLI sessions
configure
no timestamps
Disables timestamp for

all new CLI sessions
1_1-33

Do Not Distribute
5-33
Configuring System Settings: User Accounts

The Quick Setup Wizard, when run, creates a user account with administrator
privilege. It does this for initial management of the ASR 5500. If you want additional
accounts of varying privilege levels, you must create these yourself.
The system supports four user privilege levels:
5-34
Administrator - has read-write privileges and can execute all CLI commands
including those available to Administrators, Operators, and Inspectors. This
type of user can create new user accounts.
Config-Administrator - has read-write privileges and can execute any

command throughout the CLI except for a few security-related commands
that can only be configured by Security Administrators. Administrators can
configure or modify the system and are able to execute all system
commands, including those available to the Operators and Inspectors.
Operator - has read-only privileges to a larger subset of the Exec Mode

commands. They can execute all commands that are part of the inspector
mode, plus some system monitoring, statistic, and fault management
functions. Operators do not have the ability to enter the Config Mode.
Inspector - is limited to a small number of read-only Exec Mode commands.

The bulk of these are show commands giving the inspector the ability to view
a variety of statistics and conditions. The Inspector cannot execute show
configuration commands and does not have the privilege to enter the Config
Mode.

Do Not Distribute
Configuring System Settings: User Accounts

In addition to that configured by the Quick Setup Wizard, additional
context-level administrative users can be configured
User accounts are created with a pre-assigned privilege level
There are four privilege levels:
Administrator may perform any CLI command and create new user
accounts
Config-Administrator may make configuration changes except for
security-related commands such as creating a new user account
Operator can execute commands to view the system; may perform
state-impacting operations but not configuration-impacting operations
(write access to flash); i.e. may reset a card or the system, but not
change which config file is used
Inspector can only execute commands to view the system; no
service-affecting commands are possible, nor is any configuration
change (write access to flash) possible
1_1-35

Do Not Distribute
5-35
Configuring System Settings: Security Admin & Admin Accounts

The slide shows how to create an account with security-admin privilege and an
account with administrator privilege. This type of account should only be created in
the local context, where the management interface was also configured.
The table below shows all variables:
Keyword/Variable
Description
name
Specifies the security administrators name. The name can be between 1 and
32 alpha and/or numeric characters and is case sensitive.
password
Specifies the password for the security administrator. The password can be
between 1 and 63 alpha and/or numeric characters and is case sensitive.
encrypted
password
Specifies the encrypted password for the security administrator. The

encrypted keyword is intended only for use by the system while saving
configuration scripts. The system displays the encrypted keyword in the
configuration file as a flag that the variable following the password keyword is
the encrypted version of the plain text password. Only the encrypted password
is saved as part of the configuration file.
ftp
Specifies that the security administrator is allowed to access the system using
the File Transfer Protocol (FTP). This option is useful for allowing the user to
upload files to the systems CompactFlash.
no-cli
Specifies that the security administrator cannot access the systems command
line interface (CLI) and should be used in conjunction with the ftp keyword to
allow access to the system using only FTP.
timeoutabsolute
Specifies the maximum amount of time that the operator can maintain a
session with the system. The absolute_time is measured in seconds can be
configured to any integer value between 0 and 300000000. The default
absolute_time is 0.
In the event that the absolute timeout value is reached, the operator session
will automatically be terminated.
timeout-idle
Specifies the maximum amount of time that an operator session can remain
idle before being automatically terminated. The idle_time is measured in
seconds and can be configured to any integer value between 0 and
300000000. The default idle_time is 0.
expiry-date
The date and time that this account expires. Enter the date and time in the
format YYYY:MM:DD:HH:mm or YYYY:MM:DD:HH:mm:ss.
Where YYYY is the year, MM is the month, DD is the day of the month, HH is
the hour, mm is minutes, and ss is seconds.
5-36

Do Not Distribute
Configuring System Settings: Security Admin

& Admin Accounts
An account with Security Administrator privileges should only be created in the
local context
The command shown below can only be executed if you are already logged in
using an account that has security admin privilege
Note that ftp variable; if omitted, the user will not be able to log into the ASR
5500 using an FTP client
Shown below is the minimum amount of information that needs to be supplied;
other variables are available (timeouts, expirations, etc)
configure
context local
administrator admin password starent ftp
config-administrator cfgadmin password starent ftp
Privilege level
User account name
This user can login with an FTP client
1_1-37

Do Not Distribute
5-37
Configuring System Settings: Operator/Inspector Accounts

The slide shows how to create an account with operator privilege and an account
with inspector privilege. This type of account should only be created in the local
context, where the management interface was also configured.
Note that ftp access is not available. The table below shows all variables:
Keyword/
Variable
Description
name
Specifies the operators name. The name can be between 1 and 32

alpha and/or numeric characters and is case sensitive.
password
Specifies the password for the operator. The password can be

between 1 and 63 alpha and/or numeric characters and is case
sensitive.
encrypted
password
Specifies the encrypted password for the operator. The encrypted

keyword is intended only for use by the system while saving
configuration scripts. The system displays the encrypted keyword in
the configuration file as a flag that the variable following the
password keyword is the encrypted version of the plain text
password. Only the encrypted password is saved as part of the
configuration file.
expirydate
The date and time that this account expires. Enter the date and
time in the format YYYY:MM:DD:HH:mm or
YYYY:MM:DD:HH:mm:ss.
Where YYYY is the year, MM is the month, DD is the day of the
month, HH is the hour, mm is minutes, and ss is seconds.
timeoutabsolute
Specifies the maximum amount of time that the operator can

maintain a session with the system. The absolute_time is measured
in seconds can be configured to any integer value between 0 and
300000000.
In the event that the absolute timeout value is reached, the operator
session will automatically be terminated.
timeoutidle
Specifies the maximum amount of time that an operator session

can remain idle before being automatically terminated. The
idle_time is measured in seconds and can be configured to any
integer value between 0 and 300000000.
5-38

Do Not Distribute

Operator/Inspector Accounts
An account with Operator or Inspector privileges is a read-only account
Note that the ftp variable is not available for these privilege levels
Shown below is the minimum amount of information that needs to be
supplied; other variables are available (timeouts, expirations, etc)
configure
context local
operator operator1 password starent
inspector inspector1 password starent
Privilege level
User account name
1_1-39

Do Not Distribute
5-39
Configuring System Settings: ANSI T1.276 Accounts

This user account type provides support for ANSI T1.276-2003 password security
protection. Local-user account information (passwords, password history, lockout
states, etc.) is maintained in non-volatile memory on the CompactFlash module and
in the softwares Shared Configuration Task (SCT). This information is maintained in
a separate file, not in configuration files used by the system. The configured localuser accounts are not visible with the rest of the system configuration. The slide
shows the minimal CLI entry needed to create a local-user. More variables are
available:
Keyword/Variable
Description
name
Specifies the name of the user. The name must be from 3 to 16 alpha
and/or numeric characters in length and is case sensitive.
authorization-level
Specifies the privilege to assign to this user and can be one of the
following:
security-administrator
administrator
inspector
operator
[ ecs | noecs ]
Specifies whether or not the user has access to configuration parameters

pertaining to the Enhanced Charging Service.
The default is to allow access to ECS parameters.
[ ftp | noftp ]
Specifies whether or not the user is allowed to access the system via the
File Transfer Protocol (FTP) and/or the Secure File Transfer Protocol
(SFTP).
The default is to allow FTP access.
[ timeout-minabsolute time ]
Specifics the maximum session time for this user. time is measured in
minutes and can be configured to any integer value between 0 and
525600. A value of 0 indicates no limit.
The default value is 0.
[ timeoute-min-idle
time ]
Specifics the maximum idle time for this user. time is measured in
minutes and can be configured to any integer value between 0 and
525600. A value of 0 indicates no limit.
The default value is 0.
[ no-lockout-loginfailure ]
Specifies that this user will never be locked out due to login attempt
failures.
This is disabled by default.
[ no-lockout-passwordaging ]
Specifies that this user will never be locked out due to the age of their
password.
This is disabled by default.
password
Specifies the initial password for this user. password must from 6 to 32
alpha and or numeric characters in length in length and is case sensitive.
5-40

Do Not Distribute
Configuring System Settings: ANSI

T1.276 Accounts
User accounts that support the ANSI T1.276 standard are referred to as
system-level admin users, or local-user admin users
Local-user admin users support the ANSI T1.276 password and
security protection standard:
Account info is stored on compact flash

Higher level of password complexity enforcement
User account name
configure
local-user username staruser authorization-level
security-admin ftp password starent
Privilege level
Account password
1_1-41

Do Not Distribute
5-41
MIO and Port Availability

When the system boots up, all installed DPCs are placed into standby mode. Some
portion of these cards must be activated in order to configure and use them for
session processing. Others may remain in standby mode to serve as redundant
components.
DPC need to be activated in order to provide resources (CPU and memory) for
session processing. If they are not enabled and session redundacy is enabled then
they will act in a standby capacity
The MIO card in slot 5 by default powers on first and if it boots successfully its
bootstack settings and local flash will provide the image of the operating system as
well as the configuration file for the rest of the chassis. It is also placed in an active
state and the MIO in slot 6 is placed in the standby state.
The Ports on the MIO card need to be activated thru configuration, they are not by
default enabled. However the MIO in slot 5 by default is active and slot 6 standby.
The remaining cards are all active, which include the SSCs, and FSCs.
5-42

Do Not Distribute
MIO and Port Availability

Upon boot up, all installed cards except the primary MIO are in
standby mode
The MIO in slot 5 after a successful boot is default to Active
Mode
The MIO in slot 6 is defaulted to Standby Mode
By default the corresponding ports in slot 6 becomes the backup
[local]Training-School-9# show card table
Slot
Card Type
----------- -------------------------------1: DPC
None
2: DPC
None
3: DPC
4: DPC
5: MMIO
6: MMIO
7: DPC
8: DPC
Oper State
------------Active
Active
Active
Standby
Active
Standby
SPOF
---No
No
No
No
-
Attach
------
1_1-43

Do Not Distribute
5-43
Management Port Redundancy Defaults

Port redundancy for MIO provides an added level of redundancy to minimize the
impact of network failures that occur external to the system.
The management ports, 5/1 and 5/2, are dedicated to OAM functions and do not
support vlan tagging. The speed can be configured for 10Mb, 100Mb, or 1Gb.
Administrative services:
CLI sessions via Telnet
CLI sessions via SSH
FTP
SFTP
NTP
SNMP
SYSLOG
5-44

Do Not Distribute
Management Port Redundancy Defaults

Configure
Port: 5/1
Port Type
Role
Description
Redundancy Mode
Framing Mode
Redundant With
Preferred Port
Physical ifIndex
Configured Duplex
Configured Speed
Configured Flow Control
Interface MAC Address
Fixed MAC Address
Link State
Link Duplex
Link Speed
Flow Control
Link Aggregation Group
Logical ifIndex
Operational State
show port info 5/1

:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
1000 Ethernet
Management Port
(None Set)
Port Mode
Unspecified
6/1
Non-Revertive
83951616
Enabled
Auto
Auto
Enabled
64-9E-F3-69-5B-E0
64-9E-F3-69-5B-C0
Up
Full
1000 Mb
Disabled
None
83951617
Up, Active
1_1-45

Do Not Distribute
5-45
Subscriber Port Redundancy Defaults

By default, the system provides for port-level redundancy when a failure occurs. in
this mode, the ports on active and standby MIO (e.g. slot 5 and slot 6) share the
same MAC address (e.g. 5/10 and 6/10 would have the same MAC address), but
since only one of these ports may be active at any one time there are no conflicts.
This eliminates the need to transfer MAC addresses and send gratuitous ARPs in
port failover situations. Instead, for Ethernet ports, three Ethernet broadcast packets
containing the source MAC address are sent so that the external network equipment
can update their ARP cache after the topology change. However, if a removal is
detected, then the system sends out gratuitous ARPs to the network because of the
MAC address change that occurred on the specific port.
With port redundancy enabled, if a failover occurs, only the specific port(s) become
active (for example; if port 5/10 fails, then port 6/10 becomes active, while all other
active ports on the MIO in slot 5 remain in the same active state. In port failover
situations, the show port table commands will show what ports are Active on both
cards and if so that both cards are Active, respectively.
If card-level redundancy is enabled, there is no port-level redundancy. In an MIO
failover situation, the Standby MIO becomes Active and all ports on that card
become Active. Port settings, in the system are automatically copies all the MAC
addresses and configuration parameters used by the failed MIO to its redundant
counterpart.
Port redundancy can be configured in a revertive (where it returns service to the
original port when service is restored) or non-revertive fashion where it holds the
port connection regardlet of the status of the original service port. The default
configuration is non-revertive and port mode.
5-46

Do Not Distribute
Subscriber Port Redundancy Defaults

Configure
[local]Training-School-9# show port info 5/11
Port: 5/11
Port Type
Role
Description
Redundancy Mode
Framing Mode
Redundant With
Preferred Port
Physical ifIndex
Configured Duplex
Configured Speed
Fault Unidirection Mode
Configured Flow Control
Interface MAC Address
SRP Virtual MAC Address
Fixed MAC Address
Link State
Link Duplex
Link Speed
Flow Control
Link Aggregation Group
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
10G Ethernet
Service Port
(None Set)
Port Mode
Unspecified
6/11
Non-Revertive
84606976
Enabled
Auto
Auto
802_3ae clause 46
Enabled
64-9E-F3-69-5B-EA
None
64-9E-F3-69-5B-CA
Up
Full
10 Gb
Enabled
None
1_1-47

Do Not Distribute
5-47
802.3ad Link Aggregation (LAG)

Link aggregation are methods of combining (aggregating) multiple network
connections in parallel to increase throughput beyond what a single connection
could sustain, and to provide redundancy in case one of the links fails.
Methods include port trucking, link bundling, Ethernet/network/NIC
bonding, or NIC teaming.
LACP State:
+
Distributing: Link Up, LACP Up, Active
Agreed: Link Up, LACP Up, Standby
No Peer: LACP Down, Link Up or Down
Timeout: LACP negotiation timeout
Other: Indeterminate state
5-48

Do Not Distribute
802.3ad Link Aggregation (LAG)

802.3ad LAG supported among ports on MIO subscriber ports
LAG configuration is mirrored on the standby ports
No traffic, including LACP, is passed by standby ports.
[local]ASR5500# sho port table
Port Role Type
----- ---- -----------------------5/1 Mgmt 1000 Ethernet
5/2 Mgmt 1000 Ethernet
5/3 Mgmt RS232 Serial Console
5/10 Srvc 10G Ethernet
...
+
...
+ Distributing:
Distributing:
Admin
-------Enabled
Disabled
Enabled
Enabled
Enabled
Enabled
LACP State:
Enabled
Oper
---Up
Down
Down
Up
Up
Link
---Up
Down
Unkn
Up
Up
State
------Active
Standby
Standby
Active
Active
Up
Up
Up
Up
Active
Active
Link
Link Up,
Up, LACP
LACP Up,
Up,
Active
Active
~
~ Agreed:
Agreed: Link
Link Up,
Up, LACP
LACP Up,
Up, Standby
Standby
-- No
No Peer:
Peer: LACP
LACP Down,
Down, Link
Link Up
Up or
or
Down
Down
!! Timeout:
Timeout: LACP
LACP negotiation
negotiation timeout
timeout
** Other:
Other: Indeterminate
Indeterminate state
state
Pair
----6/1
6/2
6/3
6/10
6/11
Redundant
--------L2 Link
L2 Link
L2 Link
LA+ 5/10
LA+ 5/10
5/10 LA~
5/11 LA~
5/10
5/10
Master
Port
1_1-49

Do Not Distribute
5-49
LAG Port State & Interface Binding

LACP Link Aggregation Control Protocol determines which port can pass traffic.
From a show ip interface summary a physical port may look bound to a vlan that is
its redundant pair, with LACP that controls the state of the ports looks are both the
active and standby chooses which port to send traffic. So from the perspective of
the NPU all ports are viewed as candidates to pass traffic.
New Commands on the ASR5500
port switch to
link-aggregation port switch to
Ensuring that LAG related fields are set properly and the ports are bound properly is
an important step in debugging LAG related issues
Useful CLI commands:
[local]ASR5500# show npumgr db lookup pport 5/15 5/0/0 <cr>
Verify lag = { enabled:1 in all physical LAG master/member ports
[local]ASR5500# show npumgr db lookup pport 5/15 vlan 301 5/0/0 <cr>
Verify flags = { enable:1, lag:1, vrf-id, and lag-id match in all LAG virtual (VLAN)
ports
5-50

Do Not Distribute
LAG Port State & Interface Binding

LAG member ports are maintained as active/active pairs, even if
the port is standby and not passing traffic.
Causes interfaces created on the master LAG port to bind to
either the active or standby port.
[local]ASR5500# sho port table
Port Role Type
----- ---- -----------------------5/1 Mgmt 1000 Ethernet
5/2 Mgmt 1000 Ethernet
5/3 Mgmt RS232 Serial Console
...
...
Admin
-------Enabled
Disabled
Enabled
Enabled
Enabled
Oper
---Up
Down
Down
Up
Up
Link
---Up
Down
Unkn
Up
Up
State
------Active
Standby
Standby
Active
Active
Enabled
Enabled
Up
Up
Up
Up
Active
Active
Pair
----6/1
6/2
6/3
6/10
6/11
Redundant
--------L2 Link
L2 Link
L2 Link
LA+ 5/10
LA+ 5/10
5/10 LA~
5/11 LA~
5/10
5/10
1_1-51

Do Not Distribute
5-51
Card Migration and Card Switchover

In the event of DPC critical failure, tasks will be automatically be migrated from the
active card to a standby redundant card that is in standby mode with session
managers and aaa managers waiting to take on the . The switch fabric will simply
remap connection across the fabric to the new CPU or NPU. To ensure an validate
or as part of an update strategy the migrate command can be used to migrate an
active DPC to the standby module.
In the event that an issue arises that is not severe enough for the system to perform
an automatic migration, a manual migration can be invoked. The command to do
this is shown on the slide.
In the event of a critical failure on the MIO in slot five, the system will be switched to
the redundant MIO in slot six. This is a relatively seamless transition because the
two are always synchronized. The formerly active MIO will then enter the standby
mode allowing it to be safely replaced or restored.
In the event that an issue arises that is not severe enough for the system to perform
an automatic switchover, a manual switch over can be invoked. The command to do
this is shown on the slide.
CLI sessions that are active at the time of the manual switchover will be deleted and
the CLI users will have to reconnect (CLI sessions are not mirrored on standby).
All access to the management and customer data plane is throiught the 2 MIO cards
in slots 5 and 6. When ports in slot 5 fail slot 6 ports will automatically be made
active while the MIO card in slot 5 will automatically be placed in standby mode for
that por. In the event that the active card experiences a total failure, the system will
automatically switch traffic to the standby card in slot 6.
5-52

Do Not Distribute
Card Migration & Card Switchover

Software tasks can be moved to alternate cards
Called migration for DPCs only (no loss of service with session recovery)
Called switchover for MIOs (no loss of service)
Network traffic can also be switched

Between individual line card ports
[local]Training-School-9# card migrate from ?
3,4,7,8 (note DPCs Only)
[local]Training-School-9# card migrate from 3 to 8
Are you sure? [Yes|No]: yes
[local]Training-School-9# card switch from <slot> to <slot>

(used for MIOS Only)
[local]Training-School-9# card switch from 5 to 6
1_1-53

Do Not Distribute
5-53
Port Switchover
In the case where you might want to test connectivity of the standby port, you can
use the CLI port switch command.
5-54

Do Not Distribute
Port Switchover
Network traffic can be switched from the active to the standby port:
[local]Training-School-9# port switch to 6/11
[local]Training-School-9# show port info 6/11
Port: 6/11
Port Type
: 10G Ethernet
Role
: Service Port
Link State
: Up
Link Duplex
: Full
Link Speed
: 10 Gb
Flow Control
: Enabled
Link Aggregation Group : None
Untagged:
Logical ifIndex
: 101384193
Operational State
: Up, Active
1_1-55

Do Not Distribute
5-55
Configuring System Settings: Session Recovery

Session recovery is performed by mirroring key software processes (e.g. session
manager and AAA manager) within the system. These mirrored processes remain in
an idle state (in standby-mode), until they may be needed in the case of a software
failure.
These mirrored processes require both memory and processing resources, which
means that additional hardware may be required to enable this feature.
Additionally, other key system-level software tasks, such as VPN manager, are
placed on a physically separate DPC card to ensure that a double software fault
(e.g. session manager and VPN manager fails at same time on same card) cannot
occur.
Session recovery can be enabled on a system that is out-of-service (OoS) and does
not yet have any contexts configured, or on an in-service system that is currently
capable of processing calls. However, if the system is in-service, it must be restarted
before the session recovery feature takes effect. The CLI command to enable
session recovery is shown on the opposite page.
5-56

Do Not Distribute

Session Recovery
Session recovery is a feature that provides recovery of user
sessions in the event of a Session Manager software task
or hardware fault
Session recovery is available for most ASR 5500 services.
If any services are already configured when session
recovery is enabled, system should be re-booted
Session Recovery requires a license
Enable is shown below
configure
require session recovery
1_1-57

Do Not Distribute
5-57
Configuring System Settings: SNMP

The system uses SNMP to send traps or events to the Web Element Manager
server or an alarm server on the network.
If needed, configure the system contact, system location, and community string(s)
for SNMPv1 and SNMPv2c access to the system. A community string is a password
that allows access to system management information bases (MIBs).
By default, the UDP port number 162 is used for traps, but you can change this if
desired.
The SNMP trap server to which you want to send traps is configured as a target.
Keyword/Variable
Description
name
Specifies a descriptive name that can be configured for the

alarm server. name can be between 0 and 31 alpha and/or
numeric characters and is case sensitive.
ip_address
Specifies the IP address of the alarm server in dotted decimal

notation (###.###.###.###).
non-default
Specifies that this destination is only used for SNMP traps

which have been specifically identified.
port
Specifies the UDP port number (number) which will be used

by the system to transmit traps over. number can be
configured to any integer value between 0 and 65535. The
default value is 162.
security-name
string
Specifies the community string (string) that will enable the

exchange of SNMP data between the system and the alarm
server. string can be between 0 and 31 alpha and/or
numeric characters and is case sensitive.
version
Specifies the SNMP version supported by the target server.

The version can be either 1, 2c, or 3.
informs
Specifies that the SNMP target should receive information

notifications.
traps
Specifies that the SNMP target should receive trap

notifications.
5-58

Do Not Distribute
Configuring System Settings: SNMP

SNMP (Simple Network Management Protocol)
Used for delivery of traps to an alarm server
Communication with multiple alarm servers (SNMP targets) is
supported
Versions 1, 2c, or 3 are supported
configure
system contact asr5500 manager
system location Tewksbury
snmp authentication-failure-trap
snmp community public read-write
snmp target <name> <ip-address> port <port> securityname <community> version <version> traps
1_1-59

Do Not Distribute
5-59
Configuring System Settings: Trap Suppression

SNMP traps are used by the system to indicate that certain events have occurred. A
complete listing of the traps supported by the system and their descriptions can be
found in the SNMP MIB Reference.
By default, the system enables the generation of all traps. However, individual traps
can be disabled allowing only traps of a certain type to be generated. These
instructions assume that you are at the prompt for the Global Configuration mode.
You can also specify which traps go to a specific trap server.
5-60

Do Not Distribute
Configuring System Settings: SNMP Trap

Suppression
By default, will send all traps to the designated trap
server(s)
This behavior can be modified by suppressing certain
trap types
You can also send certain traps to specific trap servers
configure
snmp trap suppress ?
snmp trap suppress <trap_name1> <trap_name2>
snmp trap enable <trap_name1> target <target-name>
1_1-61

Do Not Distribute
5-61
Module Summary
5-62

Do Not Distribute
Module Summary
You should now be able to demonstrate :
Running commands on the CLI to accomplish
Configuration
Show commands and debugging
Global Commands for time, date, and NMP
Knowledge of the CLI Architecture
The ability to use commands to:
Migrate Cards
Switch Cards
Switch Ports
1_1-63

Do Not Distribute
5-63
1_1-64
5-64

Do Not Distribute
Lab 1 - Introduction to the CLI Hardware Overview
Description
Complete this lab activity to familiarize yourself with the lab environment and
perform various CLI commands to determine the Cisco ASR 5500 hardware
configuration and operational status.
Activity Objective
In this activity, you will familiarize yourself with CLI syntax. You will also learn how
to use the StarOS CLI commands for monitoring and evaluating the Cisco ASR
55000 LTE gateway node. After completing this activity, you will be able to meet
these objectives:
Connect to the lab network from your PC or laptop via putty
Log into the chassis
Use StarOS CLI Commands to monitor various components of

the Cisco LTE Gateway node.
Evaluate hardware inventory and operational status of the

chassis.

Do Not Distribute
5-65
Visual Objective
The figure below illustrates the network topology for this activity.
putty
Internet
Cisco
Firewall
ASR5500
Task 1: Establish and Verify Lab Connectivity

The purpose of this task is to establish connectivity to the lab remotely. The lab
access procedure used below will be used for all the labs found throughout the
course.
Activity Procedure
Complete these steps:
Step 1
Connect to the lab network by secure shell session via putty:
a) Instructor will provide the IP address of the chassis.

b) Log in using the username admin and password starent or
as provided by your instructor:
_____________________________ Note _________________________
Notify the instructor if you do not have connectivity.
5-66

Do Not Distribute
Activity Verification
You have completed this task when you attain these results:
You can successfully access the chassis in our lab via direct connection.
Your prompt identifies you at exec mode (#) in local context on

the correct host name.
You have determined other users who have logged into the
chassis.
_________________________________________ Note _________________________
Only one person can also log in through the console port.
Task 2: Evaluate the Cisco ASR 5500 LTE Gateway Node hardware
The purpose of this task is to familiarize you with common CLI commands used to
determine the hardware configuration and operational status of the chassis.
Activity Procedure
Complete these steps:
Step 2
Using the tab key to expand and provide command completion observe
other login session via the command:
# show admin
or
# show administrator session id
Step 3
Check the time
# show system uptime

Step 4
Check how long the system has been booted
#show clock
What is the timezone?

Do Not Distribute
5-67
Step 5
Determine what modules have been installed and their operational state.
#show card table
Step 6
How many MIOs are in the chassis?
____________
How many DPCs are in the chassis?
____________
How many Fabric storage cards?
____________
How many solid state disk drives are there?
____________
What total space available?
____________
Confirm card status via led displays
#show led
How can you determine which cards are in standby?

On the MIO cards, what is the difference between active and
master leds?
Slot
5-68
Card Type
Status

Do Not Distribute

Step 7
Check chassis fan tray, power supply and temperature
#show
#show
#show
#show
fan
power
temperature
temperature verbose
What does the temperature difference between upper and lower

fan trays tell you?
What is the status of the Power Supply? Try the verbose option
What is the status of the Fan Tray Fan-Fail?
The verbose option for temperature shows each component on
each module. What is the hottest running component?
NOTE: The Cisco ASR 5500 installed in the lab contain four DC power inputs.
Step 8
To get the most detail of power and temperature per module per
component, pipe the output to more for a paged view.
#show card diag | more
You can view this on a per card basis by including the card
number.
Step 9
Check the alarm status with default settings.

#show alarm all
From the time of the previous alarm, what do you think is the
cause?
Facility alarms are part of the configuration and none have been
set yet.

Do Not Distribute
5-69
Step 10
Check the hardware inventory to record part numbers and serial numbers.
#show hardware inventory
Activity Verification
You have completed this task when you have used the Command Line interface to
monitor and check the status of the various components of the Cisco ASR 5500s
and answered all the questions within the lab.
5-70

Do Not Distribute
Cisco ASR 5500

Configuration
Terminology
Lesson 6

Do Not Distribute
6-1
Module Objectives
This module introduces and defines some important terms that you will need to
know when configuring the switch.
These terms appear extensively in the user documentation. For this reason too, it is
important to have an understanding of how they are being used.
6-2

Do Not Distribute
Module Objectives
Upon completing this module, you will be able to meet
these objectives:
Describe the use, implementation, and configuration of the

following configuration building blocks:
Contexts
Logical Interfaces
Loopbacks
Ports
Services
Be able to set up two common techniques of Interface

availability
Redundant interfaces
Lag groups
1_1-3

Do Not Distribute
6-3
Module Agenda
6-4

Do Not Distribute
Module Agenda
Configuration Building Blocks
Contexts
Interfaces
Ports
Services
Interface I/O High Availablity
Port Redudancy
LAG Group
Configuring Network Connectivity

Lab 2: Build and Test the Contexts and IP Interfaces
Summary
1_1-5

Do Not Distribute
6-5
Contexts
A context is a logical grouping or mapping of configuration parameters. A context
can be thought of as a virtual router with no interfaces in it. Between contexts
(virtual routers) there are not connections. Through configuration, interfaces and
services are added to a context. Then interfaces are associated with physical ports.
The system supports the configuration of multiple contexts. Each is configured and
operates independently from the others. Once a context has been created,
administrative users can then configure services, logical IP interfaces, management
users, etc. for that context. Administrative users would then bind the logical
interfaces to physical ports.
As contexts are routers of sorts, they can be configured to perform various traffic
control, filtering and routing functionalities by associating them to static routing
tables (or actual active router invocations), defining Access Control Lists for a
context (ACLs) etc.
As part of the setup of subscriber data session, connections between contexts are
made by the operating system, based on routing parameters that you configure. A
route on the ASR 5000 is a pre-defined path between contexts. This path enables
the movement of subscriber session data through the box at near wire-speeds.
6-6

Do Not Distribute
Contexts
A context is the basic building block for all calling
services on the ASR 5500
It is a container for other components such as:
Interfaces
Services
IP address pools
and more
A context, by itself, can be visualized as a virtual
router without any connections to the external
network
Context A
Context B
Added via
configuration
Context C
Local Context
There is no inherent connection between contexts

Internally, the StarOS operating system can route
across context boundaries
Default context
(for management)
A new as 5500 has only one context: the local

context (management)
1_1-7

Do Not Distribute
6-7
Types of Contexts
Contexts can be loosely categorized into types. Depending what components you
configure within a context, it can assume a certain type. When you create a context,
you cannot define its type. It takes on a type based on how it is used, on what
interfaces and services it contains.
Contexts on the system are often categorized as follows:
Source context - Also referred to as the ingress context, this context

provides the subscribers point-of-entry in the system. It is also the context in
which services are configured.
Destination context - Also referred to as the egress context, this context is

where a subscriber is typically provided with access to the Internet. For
example, the systems destination context would be configured with the
interfaces facilitating subscriber data traffic to/from the Internet.
AAA context - This context provides authorization, authentication, and

accounting (AAA) functionality for subscriber. The AAA context contains
context-specific AAA policies, the logical interfaces for communicating with
AAA servers, and records for locally configured subscribers.
Management context - Also referred to as the local context, this context is

where a CLI user is located. It is reserved for management purposes and
contains minimal call-processing related information.
It is important to note that source, destination, and AAA functionality can be

configured within the same context or be configured as separate contexts. Where
you place components within contexts is dependent on how you are interoperating
with external networks components.
6-8

Do Not Distribute
Types of Contexts
Contexts are not configured to be of a certain type; they
take on a type because of what services and interfaces
they contain:
Source Context
Supports inbound traffic
Destination Context
Supports outbound traffic to a Packet Data Network
AAA Context
Provides authentication functionality for subscriber
Contains the policies and logical interfaces for communicating
with AAA servers
Management Context
A permanent context named local used for management
purposes
1_1-9

Do Not Distribute
6-9
Logical Interfaces
Logical interfaces are assigned a name and an IP address, and then bound to a
specific port during the configuration process. They can only be configured within a
context.
In the same way that a context can be thought of a virtual router, a logical interface
can be visualized as an interface within that virtual router.
Logical interfaces are also associated with services through bindings. Services are
bound to an IP address that is configured for a particular logical interface.
6-10

Do Not Distribute
Logical Interfaces
A logical interface is an IP address that is defined within a context
It is independent of any physical port
In the same way that a context can be visualized as a virtual router, a logical
interface can be visualized as an interface in that virtual router
Up to 512 logical interfaces can be configured per context
A logical interface can have up to 16 secondary addresses assigned to it
Logical interfaces
within a context
Context 1
Logical interface A
IP address1 (192.168.1.150)
(up to 16 secondary addresse s)
Context 2
Logical interface B
IP address1 (192.168.1.150)
Logical interface C
IP address1 (62.1.2.3)
1_1-11

Do Not Distribute
6-11
Types of Logical Interfaces

When a logical interface is tied to a service, the interface takes on the
characteristics of the functions enabled by the service. For this reason, there are a
number of logical interface types. Note that a logical interface is not configured to be
a certain type, it takes on a type because of the context it is in or the service to
which it is bound.
6-12

Do Not Distribute
Types of Logical Interfaces

Logical Interfaces are not created and assigned a specific
purpose; the type of logical interface is determined by either:
The context in which it is placed
The service with which it is associated
Some types of logical interfaces are:

S1-U Interface
Communications path between the eNodeB and the SGW service
S11 Interface
Communication path between the MME and a S-GW service
S5/S8 Interface
Communication path between a S-GW and P-GW service
SGi Interface
Communication path from the P-GW to the Packet Data Network
1_1-13

Do Not Distribute
6-13
Loopback Interfaces
Loopback interfaces are a type of logical interface. As with any logical interface, you
assign an IP address, and mask, to it.
However, a loopback interface has some special characteristics:
6-14
A loopback address must have a 32-bit mask assigned to it.
A loopback interface is not associated with any one physical port. With proper
routing configuration, the traffic being sourced by the assigned loopback
address is load-balanced across all other logical_interfaces/port pairs in the
same context.
Because a loopback address is not associated with any one physical port,
their configured address is available as long as one port in the context is
functioning. This makes their IP address more resilient to port failure, or more
highly available to the external network.
The loopback interface IP address can be transmitted through routing

protocols, such as OSPF, to allow the IP routing domain to learn of the
loopback interfaces IP address. As such, the loopback interfaces address
can be used as the destination for external network entities.

Do Not Distribute
Loopback Interfaces
A loopback interface is a special type of logical interface:
It has an IP address with a 32-bit (host) mask
Can only be assigned one address
Always up and available
Context A
Traffic sourced by this

interface (address) is
load-shared across all
interface/port
combinations in
context
Logical interface A
(10.1.8.150/32)
Logical interface B
(10.1.8.17/28)
Logical interface C
(10.1.8.33/28)
active LC
active LC
standby LC
standby LC
1_1-15

Do Not Distribute
6-15
PhysicalPorts
The actual layer 1 connection point. These are the MIO interfaces.
6-16

Do Not Distribute
Physical Ports
Physical ports provide the physical network connections
They are located on the MIO card
Identified by slot number and port number
LOCAL1 5/1
Subscriber port on MIO 5/10
multiple logical interfaces can be associated with one physical port

Without VLAN tags - one logical interface per port
With VLAN tags one logical interface per port plus one logical
interface per VLAN
IPaddress1
IPaddress2
IPaddress1 IPaddress2
OR
VLAN1
VLAN2
IPaddress3
IPaddress4
VLAN3
VLANxxx
1_1-17

Do Not Distribute
6-17
Standard LAG Operation

LACP(Lag Aggregation Control Protocol), as defined by the IEEE 802.3ad standard
, is used for dynamically exchanging configuration information among cooperating
systems with the intent to automatically configure and maintain link aggregation
groups. The protocol is able to automatically detect the presence and capabilities of
other aggregation capable devices, i.e. with LACP it is possible to specify which
links in a system can be aggregated through the use of LAG groups.
Some other important highlights of LAG operation:
All ports must be full duplex
All ports must be of the same type (speed).
LAG switchover to a lesser bandwidth (or fewer number of links) is not
allowed. Lag groups need to be balanced
The system generates a gratuitous ARP (GARP) when a switch over
occurs.
LAG algorithm for load sharing traffic is the same as with ECMP. It is
based on a combination of source address, destination address and

session manager id.
6-18

Do Not Distribute
Standard LAG Operation

LACP task (lagmgr) controls all links in the group.
Within the group, each port negotiates LACP with the remote router.
A failure of one port in a group, or an LACP-timeout by the remote router, causes
a queue flush and switch over to the group connected to the other router.
Disruption in traffic is 2-3 seconds
Primary links
5/10
5/11
5/15
DSTx
5/16
LAG group 213

6/10
6/11
6/15
6/16
DSTy
ASR 5500
Secondary
links

Do Not Distribute
1_1-19
6-19
Bindings
A binding creates a relationship between certain elements of the system. More
specifically, a bind command is issued as part of port configuration and service
configuration.
Bindings are used to associate:
6-20
A specific logical interface (configured within a particular context) to a physical

port. Once the interface is bound to the physical port, traffic can flow through
the context just as if it were any physically defined circuit. Static bindings
support any encapsulation method over any interface and port type.
A service to an IP address assigned to a logical interface. This allows the

interface to take on the characteristics of the service.

Do Not Distribute
Bindings
An association between elements within the system
Binding done as part of configuration
Bind a physical port or VLAN to a logical interface
Bind a service to an IP address
saegw context
SGW Service
CLI Bind
Loopback interface SGW-LOOP

(10.208.10.132 /32)
CLI Bind
Interface SAE-GW-VLAN402
(10.208.10.148 /29)
VLAN 402
5/11
5/10
6/10
5/16
5/15
6/11
6/15
LAG Group
6/16
1_1-21

Do Not Distribute
6-21
Services
Services are configured within a context and typically enable some kind of callprocessing functionality. It is code on the system that is dedicated to processing and
formatting certain types of packets.
The service must be licensed before it can be used.
Services are licensed for a certain number of sessions.
A service must be bound to an IP address before it can start.
6-22

Do Not Distribute
Services
A service provides call-processing capability
Could be one of the following:
- PGW service
- SGW service
- SAEGW service
saegw context
SGW Service
Loopback interface SGW-LOOP

(10.208.75.132 /32)
Interface SAE-GW-VLAN402
(10.208.75.148 /29)
VLAN 402
5/11
5/10
6/10
5/16
5/15
6/11
6/15
6/16
1_1-23

Do Not Distribute
6-23
Access Point Name

PDNs are associated with access point names (APNs) configured on the ASR5500.
Each APN consists of a set of parameters that dictate how subscriber authentication
and IP address assignment is to be handled for that APN. You must configure
templates for all of the possible APNs that subscribers will be accessing within the
system. You can configure up to 2048 APNs on the system.
6-24

Do Not Distribute
Access Point Name Terminology - APN

The term APN, as used by Cisco, refers to a set of service parameters that
will be applied to a subscriber bearer when it connects to the PDN served by
this APN.
The Cisco ASR5500 can host up to 2048 APNs
The APN must be globally unique on the chassis
The APN can only be configured in a context
SGi context
APN config
APN config
APN config
APN config
Interface SGI-VLAN502
(10.208.75.148 /29)
VLAN 502
5/11
5/10
6/10
5/16
5/15
6/11
6/15
6/16
1_1-25

Do Not Distribute
6-25
Server Groups
A server group contains a list of servers that are eligible to be used for subscriber
authentication and accounting purposes. Instead of having a single list of servers
per context, this feature provides the ability to configure multiple server groups.
Each server group, consisting of a list of servers.
Server groups are configured within a context.
Different server groups can be assigned to different subscribers, via APN
configuration. This provides flexibility in service creation.
Every context has a default server group that is created automatically. Unless
otherwise specified, configuration parameters apply to this group. Because of this,
by default, every context has the potential to be an access point to an server.
6-26

Do Not Distribute
Server Groups
Server Groups are configured within a context
A Server Group is a template for managing
communication to a set of external servers
Every time a context is created, the following
default server groups are created:
gtpp group default
aaa group default
igmp group default
Additional named server groups can also be

configured within a context
Multiple server groups provide flexibility in
assigning authentication and accounting services
per APN
1_1-27

Do Not Distribute
6-27
APNs and Server Group Relationship

An APN defines service characteristics of a PDN connection. Many of these
characteristics relate to authentication and accounting.
Different APNs can reference different AAA server groups and gtpp server groups.
An APN can only reference one aaa server group, and that aaa server group must
be configured in the same context as the APN. The diagram on the opposite
illustrates this.
An APN can reference multiple gtpp groups, and these groups can be in any
context. While aaa server groups are generally associated with authentication, gtpp
server groups are associated with accounting.
6-28

Do Not Distribute
APNs and Server Group Relationship

gtpp group default
aaa group default
saegw context
SGi context
APN config
aaa group RADIUS-to-MSP

APN config
gtpp group default
aaa group default
gtpp group CGF-1
gtpp group default
gtpp group CGF-2
aaa group default
Support context
1_1-29

Do Not Distribute
6-29
Module Agenda
6-30

Do Not Distribute
Module Agenda
Contexts
Interfaces
Ports
Services
Port Redudancy
LAG Group

Summary
1_1-31

Do Not Distribute
6-31
System Requirements
6-32

Do Not Distribute
System Requirements
The Cisco ASR5500 has a single image that runs on all
DPCs, MIOs, and SFCs Release or later
To operate the ASR5500 as an SGW, the Cisco
ASR500 requires:
One or more of the MIO ports to be available for S11,
S1-U, S5/S8 Signalling
Ports need to be bound to vitual interface name
Virtual interface names are bound to SGW Services
Minimum configuration includesthe following:
3 DPC modules
4 SFC modules
1 MIO Modules
1 Status Module
1_1-33

Do Not Distribute
6-33
ASR 5500 Initial Targeted Applications
6-34

Do Not Distribute
ASR 5500 Initial Targeted Applications

StarOS 14.0 supports the following applications on the ASR 5500:
P-GW
S-GW
SAE-GW
GGSN
ICSR (P-GW Only)
ASR 5500 specific documentation:

Cisco ASR 5500 Installation Guide
Cisco ASR 5500 System Administration Guide
1_1-35

Do Not Distribute
6-35
Configuring Network Connectivity to the ASR 5500
6-36

Do Not Distribute
Configuring Network Connectivity to the

ASR 5500
There are 3 parts to configuring network
connectivity on the ASR5500 and SGW, PGW,
GGSN for the first time:
1. Configure the Context that the network connection
is to be associated
2. Configure the interface name and ip addresses
associated to the name in the correct context
3. Configure each port configure and the VLANs to
be used over that physical interface and associate
the interface name within the vlan and port as
required for connectivity
1_1-37

Do Not Distribute
6-37
Configuring Network Connectivity ASR5500 Lab Detailed Diagram Interface

Configuration
6-38

Do Not Distribute
Configuring Network Connectivity ASR5500

Lab Detailed Diagram Interface Configuration
10.3
192.168.-.- /24
eNodeB
PCRF
5.10
S1-mme
S6a
7.112
MME
HSS
SupportZone ctx
local ctx
Gx int.
5.x
SGi ctx
5.10
SGi int.
7.1x1
10.1x1
2.1x1
saegw ctx
S11 int.
S1-U int.
S5 int.
4.10x
S8 int.
4.1x1
S5 int.
4.1x2
1_1-39

Do Not Distribute
6-39
Configuring ASR5500 Contexts
6-40

Do Not Distribute
Configuring ASR5500 Contexts
1. Configure and verify contexts are built for the

following :
1.
SAEGW
2.
SGi
3.
SupportZone
4.
Validate context creation is correct
1_1-41

Do Not Distribute
6-41
Configuring a Context
6-42

Do Not Distribute
1a
Configuring a Context
Configure context saegw-1, SupportZone-1, SGi-1
[local]Training-School-9# config
[local]Training-School-9(config)# context saegw-1
[saegw-1]Training-School-9(config-ctx)# exit
[local]Training-School-9(config)# context SupportZone-1
[SupportZone-1]Training-School-9(config-ctx)# exit
[local]Training-School-9(config)# context SGi-4
[SGi-4]Training-School-9(config-ctx)# exit
[local]Training-School-9(config)# exit
1_1-43

Do Not Distribute
6-43
Verifying Context Creation
6-44

Do Not Distribute
1b
Verifying Context Creation
Verify the 3 context are created using a show command

[local]Training-School-9# show context
Context Name
ContextID
State
-----------------------local
1
Active
saegw-1
2
Active
SupportZone-1
3
Active
SGi-4
4
Active
created by default
1_1-45

Do Not Distribute
6-45
Configuring SAEGW Context Virtual Interface Names and IP Addressing
6-46

Do Not Distribute
2a
Configuring SAEGW Context Virtual

Interface Names and IP Addressing
Configure Virtual Interfaces that will carry traffic to

eNodeB or MME via S1-U, S11, S5SGW, S5PGW
[local]TS-9# config
[saegw-1]TS-9(config-ctx)# interface 5/11_S1-U
[saegw-1]TS-9(config-if-eth)# ip address 192.168.10.111/24
[saegw-1]TS-9(config-if-eth)# exit
[saegw-1]TS-9(config-ctx)# interface 5/11_S11-mme
[saegw-1]TS-9(config-ctx)# interface 5/11_S8
[saegw-1]TS-9(config-ctx)# exit
[local]TS-9(config)#
1_1-47

Do Not Distribute
6-47
Configuring SAEGW Context Loopback Interface Names and IP Addressing
6-48

Do Not Distribute
2b
Configuring SAEGW Context Loopback

Interface Names and IP Addressing
Configure Virtual Looback Interfaces that will carry traffic

to eNodeB or MME via S1-U, S11, S5SGW, S5PGW
[local]TS-9# config
[saegw-1]TS-9(config-ctx)# interface S5-sgw loopback
[saegw-1]TS-9(config-if-loopback)# ip address 192.168.4.111/32
[saegw-1]TS-9(config-if-loopback)# exit
[saegw-1]TS-9(config-ctx)# interface S5-pgw loopback
[saegw-1]TS-9(config-if-loopback)# ip address 192.168.4.112/32
[saegw-1]TS-9(config-if-loopback)# exit
1_1-49

Do Not Distribute
6-49
Configuring SGi & SupportZone Context Virtual Interface Names and IP
6-50

Do Not Distribute
2c
Configuring SGi & SupportZone Context

Virtual Interface Names and IP
Configure Virtual Interfaces SGi and Gx/Gy that will carry

traffic to APN or PCRF to PCEF
[local]TS-9# config
[local]TS-9(config)# context SGi-1
[SGi-1]TS-9(config-ctx)# interface 5/21-sgi
[SGi-1]TS-9(config-if-eth)# ip address 192.168.2.111/24
[SGi-1]TS-9(config-if-eth)# exit
[SGi-1]TS-9(config-ctx)# exit
[local]TS-9(config)# context SupportZone-1
[SupportZone-1]TS-9(config-ctx)# interface 5/21-pcrf
[SupportZone-1]TS-9(config-if-eth)# ip address 192.168.5.1/24
[SupportZone-1]TS-9(config-if-eth)# end
1_1-51

Do Not Distribute
6-51
Validating IP Interfaces
6-52

Do Not Distribute
2d
Validate all IP interface in the saegw-1 context

[local]TS-9# show context
Context Name
ContextID
State
-----------------------local
1
Active
saegw-1
2
Active
SupportZone-1
3
Active
SGi-1
4
Active
[local]TS-9# context saegw-1
[saegw-1]TS-9# show ip interface summary
Interface Name Address/Mask
Port
Status
==============================
==========================
5/11_S1-U
192.168.10.111/24 Not Bound
DOWN
5/11_S11-mme
192.168.7.111/24 Not Bound
DOWN
5/11_S8
192.168.4.101/24 Not Bound
DOWN
S5-pgw
192.168.4.112/32 Loopback
UP
S5-sgw
192.168.4.111/32 Loopback
UP
Total interface count: 5
1_1-53

Do Not Distribute
6-53
6-54

Do Not Distribute
2e
Validate all IP interface in the SGi and SupportZone-1

Contexts context
[local]TS-9# context SGi-1
[SGi-1]TS-9# show ip interface summary
Port
Status
============================== ===========================
5/21-sgi
192.168.2.111/24
Not Bound
DOWN
[SGi-1]TS-9# context SupportZone-1
[SupportZone-1]TS-9# show ip interface summary
Port
Status
============================== ===========================
5/21-pcrf 192.168.5.1/24
Not Bound
DOWN
1_1-55

Do Not Distribute
6-55
Configuring Ports and Interface Binding

[local]TS-9# config
[local]TS-9(config)# port ethernet 5/11
[local]TS-9(config-port-5/11)# no shut
[local]TS-9(config-port-5/11)# vlan 4
[local]TS-9(config-port-5/11-vlan-4)# no shut
[local]TS-9(config-port-5/11-vlan-4)# bind interface 5/11_S8 saegw-1
[local]TS-9(config-port-5/11-vlan-4)# exit
[local]TS-9# config
[local]TS-9(config-port-5/11-vlan-7)# bind interface 5/11_S11 saegw-1
[local]TS-9# config
[local]TS-9(config-port-5/11-vlan-10)# bind interface 5/11_S1-U saegw-1
[local]TS-9(config-port-5/11-vlan-10# exit
[local]TS-9# config
[local]TS-9(config-port-5/21-vlan-2)# bind interface 5/21-sgi SGi-1
[local]TS-9# config
[local]TS-9(config-port-5/21-vlan-2)# bind interface 5/21-pcrf
SupportZone-1
6-56

Do Not Distribute
Configuring Ports and Interface Binding
3a
Bind the physical port and VLAN to the Virtual Interface

Name and the Context that it is located within:
Intf
Slot# / port
#
Logical Intf Name
Logical Intf Context
10
5/11_S1-U
saegw-x
5/11_S11
saegw-x
S8
5/11_S8
saegw-x
SGi
5/21_Sgi
SGi-x
5/21_pcrf
SupportZone-x
S1-U
S11
Gx
5/11
5/2x
VLan Id
See Notes Page for all interfaces

[local]TS-9# config
[local]TS-9(config-port-5/11-vlan-4)# bind interface
5/11_S8 saegw-1
1_1-57

Do Not Distribute
6-57
Validating Configuration Using Show IP Interfaces Command

SGi-1]TS-9# context saegw-1
[saegw-1]TS-9# show ip interface summary
Port
Status
============================== ==========================
5/11_S1-U
192.168.10.111/24
5/11 vlan 10
UP
5/11_S11-mme
192.168.7.111/24
5/11 vlan 7
UP
5/11_S8
192.168.4.101/24
5/11 vlan 4
UP
S5-pgw
192.168.4.112/32
Loopback
UP
S5-sgw
192.168.4.111/32
Loopback
UP

[local]TS-9# context SGi-1
Interface Name
Address/Mask
Port
Status
============================== =================
5/21-sgi
192.168.2.111/24
5/21 vlan 2
UP
6-58

Do Not Distribute
3b
Validating Configuration Using

Show IP Interfaces
See Notes Page for all interfaces
[saegw-1]TS-9# context SupportZone-1

[SupportZone-1]TS-9# show ip interface summary
Port
Status
============================== ==========================
5/21-pcrf
192.168.5.1/24
5/21 vlan 5
UP
[SupportZone-1]TS-9# context SGi-1
Port
Status
============================== ==========================
5/21-sgi
192.168.2.111/24
5/21 vlan 2
UP
1_1-59

Do Not Distribute
6-59
Validating Configuration Using Show IP Route SAEGW Context
6-60

Do Not Distribute
3c

Show IP Route SAEGW Context
[local]TS-9# context saegw-1

[saegw-1]TS-9# show ip rou
route
route-access-list
[saegw-1]TS-9# show ip route
"*" indicates the Best or Used route.
Destination
Nexthop Protocol
Prec Cost Interface
*192.168.4.0/24
0.0.0.0 connected 0
0
5/11_S8
*192.168.4.111/32 0.0.0.0 connected 0
0
S5-sgw
*192.168.4.112/32 0.0.0.0 connected 0
0
S5-pgw
*192.168.7.0/24
0.0.0.0 connected 0
0
5/11_S11mme
*192.168.10.0/24 0.0.0.0 connected 0
0
5/11_S1-U
Total route count : 5
Unique route count: 5
Connected: 5
1_1-61

Do Not Distribute
6-61
Validating Configuration Using Show IP Route SupportZone-1 SGi-1
6-62

Do Not Distribute
3d

Show IP Route SupportZone-1 SGi-1
[saegw-1]TS-9# context SGi-1

[SGi-1]TS-9# show ip route
Destination
Nexthop Protocol
Prec Cost Interface
*192.168.2.0/24 0.0.0.0 connected 0
0
5/21-sgi
Connected: 1
[SGi-1]TS-9# context SupportZone-1
[SupportZone-1]TS-9# show ip route
Destination
Nexthop Protocol
Prec Cost Interface
*192.168.5.0/24 0.0.0.0
connected 0
0
5/21-pcrf
Connected: 1
1_1-63

Do Not Distribute
6-63
In Order to Save a Configuration
6-64

Do Not Distribute
In Order to Save a Configuration

ASR5500 stores its configuration and operating
system on the flash on the MIO flash device /flash
[local]TS-9# show boot init
Initial (boot time) configuration:
image /flash/14-0-builds/production.45221.asr5500.bin
config /flash/epc-pcrf-startup.cfg
priority 30
To enable remote devices such as an external server

copies enable ftp or sftp per user on the ASR5500
User account name
configure
local-user username staruser authorization-level
security-admin ftp password starent
Privilege level
Account password
1_1-65

Do Not Distribute
6-65
Agenda
6-66

Do Not Distribute
Module Agenda
Contexts
Interfaces
Ports
Services
Port Redudancy
LAG Group

Summary
1_1-67

Do Not Distribute
6-67
6-68

Do Not Distribute
Lab 2 Creating Contexts and

Configuring IP Interfaces and Ports
10.3
eNodeB
PCRF
5.10
S1-mme
7.112
MME
S6a
HSS
SupportZone ctx
local ctx
Gx int.
192.168.-.- /24
7.1x1
10.1x1
5.x
SGi ctx
5.10
SGi int.
2.1x1
saegw ctx
S11 int.
S1-U int.
S5 int.
4.10x
S8 int.
4.1x1
S5 int.
4.1x2
1_1-69

Do Not Distribute
6-69
Module Summary
6-70

Do Not Distribute
Module Summary
Contexts
Interfaces
Ports
Services
MIO Redundancy
Lag Groups
Network Configuration Requirements
1_1-71

Do Not Distribute
6-71
1_1-72
6-72

Do Not Distribute

The local context is complete and will require no changes. You will create 3
additional contexts with IP interfaces in each of them. Some will be loopback
interfaces and other will be bound to VLANs through physical ports. Upon
completion, you will test your results by pinging the neighboring servers.
192.168.-.- /24
10.3
eNodeB
PCRF
5.10
S1-mme
S6a
7.110
MME
HSS
Support ctx
local ctx
Gx int.
5.x
SGi ctx
5.10
SGi int.
7.1x1
10.1x1
saegw ctx
S11 int.
S1-U int.
S5 int.
4.10x
S8 int.
4.1x1
S5 int.
4.1x2

Do Not Distribute
6-73
2.1x1
NOTE: In any configuration command, substitute the italic x with your group
number! Values in <> are to be filled in from the table following the step.
The table below lists the name of the contexts, depending on your team number.
Use this table to create the correct contexts.
Team
1
2
3
4
5
6
7
8
SAE
Context
saegw-1
saegw-2
saegw-3
saegw-4
saegw-5
saegw-6
saegw-7
saegw-8
PCEF
Context
Support-1
Support-2
Support-3
Support-4
Support-5
Support-6
Support-7
Support-8
SGi
Context
SGi-1
SGi-2
SGi-3
SGi-4
SGi-5
SGi-6
SGi-7
SGi-8
__ 1) Verify that you are at the Exec mode prompt and in the local context. Enter
global configuration mode and create the SAE context:
config
context saegw-x
7. Using the table below, create the S1-U interface for your team by entering the
following command:
interface 20/x_S1-U
Team
1
2
3
4
5
6
7
8
6-74
S1-U Interface Name

20/1_S1-U
20/2_S1-U
20/3_S1-U
20/4_S1-U
20/5_S1-U
20/6_S1-U
20/7_S1-U
20/8_S1-U

Do Not Distribute
__ 2) Within the interface configuration sub-mode, configure the correct IP address

and subnet mask. Use the following command and table to add the correct
address for your team only:
ip address 192.168.10.1x1/24
Team
1
2
3
4
5
6
7
8
IP address/mask
192.168.10.111 / 24
192.168.10.121 / 24
192.168.10.131 / 24
192.168.10.141 / 24
192.168.10.151 / 24
192.168.10.161 / 24
192.168.10.171 / 24
192.168.10.181 / 24
__ 3) Exit out of the Interface Configuration sub-mode by entering the following

command:
exit
__ 4) Using the table below, create the S11 interface for your team by entering the
following command:
interface 20/x_S11-mme
Team
1
2
3
4
5
6
7
8
S11-MME Interface Name

20/1_S11-mme
20/2_S11-mme
20/3_S11-mme
20/4_S11-mme
20/5_S11-mme
20/6_S11-mme
20/7_S11-mme
20/8_S11-mme

Do Not Distribute
6-75

ip address <address> <mask>
Team
1
2
3
4
5
6
7
8
IP address/mask
192.168.7.111 / 24
192.168.7.121 / 24
192.168.7.131 / 24
192.168.7.141 / 24
192.168.7.151 / 24
192.168.7.161 / 24
192.168.7.171 / 24
192.168.7.181 / 24

command:
exit
__ 7) Create a loopback interface that will be used by the PGW to communicate to
the SGW:
interface S5-sgw loopback
Team
1
2
3
4
5
6
7
8
6-76
IP address/mask
192.168.4.111 / 32
192.168.4.121 / 32
192.168.4.131 / 32
192.168.4.141 / 32
192.168.4.151 / 32
192.168.4.161 / 32
192.168.4.171 / 32
192.168.4.181 / 32

Do Not Distribute
__ 9) Exit out of the Interface Configuration sub-mode:

exit
__ 10) Create a loopback interface that will be used by the SGW to communicate to
the PGW:
interface S5-pgw loopback
__ 11) Within the interface configuration sub-mode, add an IP address and mask.
Use the following command and the table to add the correct address for your
team only:
Team
1
2
3
4
5
6
7
8
IP Address/mask
192.168.4.112 / 32
192.168.4.122 / 32
192.168.4.132 / 32
192.168.4.142 / 32
192.168.4.152 / 32
192.168.4.162 / 32
192.168.4.172 / 32
192.168.4.182 / 32
command:
exit
__ 13) Using the table below, create the S8/Gn interface that will be used by
external SGWs to communicate with the PGW:
interface 20/x_S8
Team
1
2
3
4
5
6
7
8
S8 Interface Name
5 /11_S8
5 /12_S8
5 /13_S8
5 /14_S8
5 /15_S8
5 /16_S8
5 /17_S8
5 /18_S8

Do Not Distribute
6-77
Team
1
2
3
4
5
6
7
8
IP address/mask
192.168.4.101 / 24
192.168.4.102 / 24
192.168.4.103 / 24
192.168.4.104 / 24
192.168.4.105 / 24
192.168.4.106 / 24
192.168.4.107 / 24
192.168.4.108 / 24
command:
exit
__ 16) Exit out of the Context Configuration sub-mode by entering the following
command again:
exit
__ 17) Enter the context configuration sub-mode for the SGi context of your team.
context SGi-x
__ 18) Create the interface that will be used by the PGW to communicate to the
Public Data Network:
interface 29/x-sgi
ip address 192.168.2.1x1/24
exit
__ 19) Exit out of the context configuration sub-mode by entering the following
command:
exit
6-78

Do Not Distribute
__ 20) Enter the context configuration sub-mode for the PCEF context of your team.
context Support-x
__ 21) Create the Gx interface that will be used by the PCEF to communicate with
the PCRF:
interface 29/x-pcrf
ip address 192.168.5.x/24
__ 22) Exit out of configuration mode by entering the following command:
end
We are now back in exec mode. Lets take a look at what weve accomplished so
far.
__ 23) From the prompt, you can see we are in local context. Show all contexts
created up to this point, You should see your own, the local context, and
contexts so far created by other teams:
show context
__ 24) To exam the interfaces, exec mode must be in the appropriate context.
context saegw-x
__ 25) Look at the state of the interfaces youve created in this context:
show ip interfaces
You should see 5 interfaces. The loopback interfaces are up and you should be
able to ping those addresses. The other three interfaces are down and you will see
the message why. Any attempt to ping those interfaces should fail. We will go back
into configuration mode and complete the interface configuration.

Do Not Distribute
6-79
__ 26) Return to configuration mode:

config
__ 27) Configure the physical ports and vlans that the interfaces will use. This
includes binding the logical interface created in the previous steps to the vlan
tag. Use the table below to identify each interface and context name youve
already configured. Repeat this for each physical port:
port ethernet <slot#/port#>
no shutdown
vlan <vlan id>
no shutdown
bind interface <logical int name> <context>
exit
vlan <vlan id>
no shutdown
bind interface <logical int name> <context>
exit
exit
Intf
S1-U
S11
S8
SGi
Gx
Slot# /
port #
20/x
29/x
VLan Id Logical Intf Name

10
7
4
2
5
20/x_S1-U
20/x_S11-mme
20/x_S8
29/x-sgi
29/x-pcrf
Logical Intf Context

saegw-x
saegw-x
saegw-x
SGi-x
Support-x
__ 28) Exit from configuration mode and return to exec mode to test the interfaces:
end
__ 29) Verify and save your configuration by entering the following commands:
context saegw-x
show ip interface (verify the ip state of each interfaces is up)
sho ip route (verify all interfaces are in routing table)
context SGi-x
show ip interface (verify ip state is up)
context Support-x
show ip interface (verify ip state is up)
show port info 20/x (verify link and vlans are up)
show port info 29/x (verify link and vlans are up)
save configuration /flash/Lab2-team-x redundant
6-80

Do Not Distribute

LOCKED-ASR 5500-EPC-Product-Suite-System-Administration and Configuration-PT1 PDF

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

LOCKED-ASR 5500-EPC-Product-Suite-System-Administration and Configuration-PT1 PDF

Diunggah oleh

Hak Cipta:

Format Tersedia

ASR 5500 EPC Product Suite System

Administration and Configuration

Cisco Proprietary and Confidential

Cisco Proprietary and Confidential

Lesson 2: Cisco ASR 5500 Hardware Architecture

Lesson 3: Cisco ASR 5500 Software Architecture

Lesson 4: Initial System Configuration

Lesson 5: StarOS CLI and Global Configuration Setttings

Lab 1 - Introduction to the CLI Hardware Overview

Lesson 6: Cisco ASR 5500 Configuration Terminology

Cisco Proprietary and Confidential

Cisco Proprietary and Confidential

Lesson 1: LTE Overview

Lesson 1: LTE Overview

Cisco Proprietary and Confidential

Lesson 1: LTE Overview

Cisco Proprietary and Confidential

Lesson 1: LTE Overview

Cisco Proprietary and Confidential

Lesson 1: LTE Overview

Cisco Proprietary and Confidential

Lesson 1: LTE Overview

Cisco Proprietary and Confidential

Lesson 1: LTE Overview

Functions of the Evolved UTRAN (eNodeB)

Cisco Proprietary and Confidential

Lesson 1: LTE Overview

Functions of the E-UTRAN (eNodeB)

RBC Radio Bearer Control

PDCP Packet Data Convergence Protocol

Dynamic Allocation of resources to UE

Routing user data to the S-GW

Cisco Proprietary and Confidential

Lesson 1: LTE Overview

Functions of the Mobility Management Entity (MME) and Supported Interfaces

Reference point between MME and S-GW

Cisco Proprietary and Confidential

Lesson 1: LTE Overview

Functions of the MME and Supported

NAS Non Access Stratum signaling security

Tracking Area List management (UE idle and active)

P-GW and S-GW selection

EPS bearer management

Cisco Proprietary and Confidential

Lesson 1: LTE Overview

Function of the Serving Gateway (S-GW)and Supported Interfaces

Cisco Proprietary and Confidential

Lesson 1: LTE Overview

Functions of the S-GW and Supported

Packet routing and forwarding

Accounting on user and QoS Class Identifier (QCI)

UL and DL charging per UE, PDN, and QCI

Cisco Proprietary and Confidential

Lesson 1: LTE Overview

Functions of the Packet Data Network Gateway (P-GW)and Supported

Cisco Proprietary and Confidential

Lesson 1: LTE Overview

Functions of the P-GW and Supported

Per user based packet filtering (DPI)

DL rate enforcement based on AMBR

Transport level marking in the DL

Cisco Proprietary and Confidential

Lesson 1: LTE Overview