Académique Documents
Professionnel Documents
Culture Documents
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
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.
Table of Contents
Lesson 1: LTE Overview
1-1
2-1
3-1
4-1
5-1
5-65
6-1
6-73
LTE Overview
Lesson 1
2010 Cisco and/or its affiliates. All rights reserv ed. Cisco Conf idential
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
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)
2010 Cisco and/or its affiliates. All rights reserv ed. Cisco Conf idential
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
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
2010 Cisco and/or its affiliates. All rights reserv ed. Cisco Conf idential
1-5
1-6
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
2010 Cisco and/or its affiliates. All rights reserv ed. Cisco Conf idential
1-7
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
GERAN
HSS
Authentication
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
2010 Cisco and/or its affiliates. All rights reserv ed. Cisco Conf idential
1-9
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
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
2010 Cisco and/or its affiliates. All rights reserv ed. Cisco Conf idential
11
1-11
1-12
The Rx reference point resides between the AF and the PCRF in the
3GPP TS 23.203.
Policy enforcement
Charging support
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
2010 Cisco and/or its affiliates. All rights reserv ed. Cisco Conf idential
13
1-13
2010 Cisco and/or its affiliates. All rights reserv ed. Cisco Conf idential
1-14
14
Lesson 2
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
Module Agenda
Connecting to the LAB
Chassis Architecture
Management and IO Module Architecture (MIO)
Data Processing Card (DPC)
System Status Card (SSC)
Fabric and Storage Card (FSC)
Hardware Flow and Switch Fabric
1_1-3
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:
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
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.
egtp service
egtp service
S5 int.
S8 int
spgw ctx
1_1-5
2-5
2-6
1_1-7
2-7
2-8
1_1-9
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.
Chassis Architecture
Management and IO Module Architecture (MIO)
Data Processing Card (DPC)
System Status Card (SSC)
Fabric and Storage Card (FSC)
Hardware Flow
2-10
Lesson Agenda
Connecting to the Lab
Chassis Architecture
Management and IO Module Architecture (MIO)
Data Processing Card (DPC)
System Status Card (SSC)
Fabric and Storage Card (FSC)
Hardware Flow and Switch Fabric
1_1-11
2-11
2-12
Front-toback airflow
21 RU
Front
Rear
1_1-13
2-13
2-14
Front-toback airflow
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
1_1-15
2-15
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
1:1 Redundancy Model
Fabric and Storage Card (FCS) - Provides crossbar switch fabric and persistent
data storage
Installed in slots 13-18
1:N Redundancy Model
2-16
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
2-17
2-18
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
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
UNUSED SLOTS - Slots 11 & 12 are not supported at this time and may be used for
future development and system enhancement.
2-20
CARD Types
Management and IO Module Architecture (MIO)
Data Processing Card (DPC)
System Status Card (SSC)
Fabric and Storage Card (FSC)
Summary
1_1-21
2-21
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.
2-22
Rear
Status
LEDs
Debug Ports
USB
Console Port
Daughter Card 1
Management
Ethernet
Daughter Card 2
1_1-23
2-23
2-24
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
2-25
2-26
1_1-27
2-27
: MMIO
Card Type
Daughter Cards
Operational State
: Standby
Administrative State
: Enabled
Card Lock
: Locked
Halt Issued
: No
Reboot Pending
: No
Upgrade In Progress
: No
Card Usable
: Yes
: n/a
Temperature
: Normal
Voltages
: Good
Card LEDs
Redundant: Green
2-28
Card LEDs
: Master:
Off
CPU 0
MMIO
Management & 20x10Gb I/O Card
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
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
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
2-31
2-32
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
2-33
2-34
1_1-35
2-35
2-36
1_1-37
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
CPU Subsystem
Processing and memory resources for subscribers traffic processing
processing
2-38
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
2-39
2-40
Online
Active
Backed up by
another DPC
Online
Active
Not backed up
by another
DPC
Online
Standby
Online
During
Migration
Booting,
Starting, or
Initializing
Green
Failed
Offline
| Redundant: Green
1_1-41
2-41
2-42
1_1-43
2-43
2-44
Normal
Operation
No Service
Loss
Failed
Components
Service Loss
Failed
Components
Service Loss
No failed
components
Offline
| Redundant: Green
1_1-45
2-45
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
2-47
2-48
Online
Active
Redundant
Fabric
Redundant
Storage
Online
Active
NonRedundant
Fabric
Initializing
Off
Failed
Offline
| Redundant: Green
1_1-49
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)
Board power and control, LEDs, environmental monitoring, general card
2-50
FSC Architecture
SAS to Slots MIO 5 & 6
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
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
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
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
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
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
Recycle
1_1-55
2-55
2-56
24x6.25Gbps = 150Gbps
per MIO and DPC hybrid
slot per FSC
1_1-57
2-57
2-58
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
2-59
2-60
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
2-61
2-62
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
2-63
2-64
FE
FE
FAP
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
2-65
2-66
FSC
Empty
Sunday December 09 19:35:25 EST 2012
Enabled
1_1-67
2-67
2-68
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
2-69
2-70
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
2-71
*Adding a 5th FSC will only provide for a extra spare and does not add extra
capacity.
2-72
Spare
Rebuilding
In-sync
1_1-73
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.
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
Plane A4/B4 Slots 1-3, 18
2-74
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
Plane A4/B4 Slots 1-3, 18
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
2-75
2-76
Serial Num
------------SAD1606018Z
SAD1603026T
SAD160300KM
SAD160202UC
SAD154002AB
SAD152302VA
SAD15400277
SAD15400295
FLM154300D8
TBM15471261
FLM160405P7
SAD160200S9
SAD154902YS
SAD152701SN
SAD153802ZM
CLEI code
---------------------------
1_1-77
2-77
2-78
Captive Screw
Ejector Handle
Ejector Subhandle
(Interlock)
1_1-79
2-79
2-80
card table
card info <slot>
hardware card <slot>
led <slot>
1_1-81
2-81
1_1-82
2-82
Lesson 3
3-1
Module Overview
3-2
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
3-3
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
3-5
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.
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.
3-6
Slot/CP#
Task name
CPU
allocation
memory
allocation
file
allocation
1_1-7
3-7
Description
vpnmgr
sessmgr
aaamgr
gtpumgr
3-8
Session Control
aaamgr
gtpumgr
egtpegmgr
SGW
egtpinmgr
gtpumgr
egtpinmgr
PGW
1_1-9
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
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.
For PGW and SGW services, this is an overly-simplified, but useful, view of
the software architecture.
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
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
3-11
monitor the state of their Managers and allow for communication between
Managers within the same subsystem.
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:
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
(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
3-13
3-14
---------------
---------------
good
good
good
good
good
good
good
good
good
good
good
good
good
good
1_1-15
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
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
3-17
Description
sitmain
3-18
ASR5500
(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
3-19
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.
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
3-21
2. The egtpimgr and sessmgr are involved in the gtp exchange to set up a
bearer.
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
3-22
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
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:
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
Session Recovery
There are three critical functions
needed to maintain a session:
sessmgr
aaamgr
sessmgr
aaamgr
vpnmgr
gtpcmgr
demux
1_1-25
3-25
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.
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
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
3-27
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
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
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
3-29
3-30
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
1_1-31
3-31
3-32
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
3-33
3-34
Good (Demux)
Good (Demux)
Good
Good
Good
Good
Good
Good
contains a combination
of 8 contexts (vpnmgrs)
and services (gtpu)
1_1-35
3-35
3-36
Overall Status
Last Status Update
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
3-37
3-38
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
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.
Sample License
The following slides show excerpts from a license
# ----- CUT HERE ----Key Information (installed key):
Comment
Chassis SN
FLM154300D8
Issued
Expires
Issued By
Starent Networks
Key Number
57239
Enabled Features:
Feature
----------------------------------------
-----------------------------
PDSN:
[ 600-00-7501 / 600-00-7504 ]
+ FA
[ None ]
3-41
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.
[ 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
1_1-43
3-43
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
1_1-45
3-45
3-46
1_1-47
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
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
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
3-49
3-50
1_1-51
3-51
3-52
1_1-53
3-53
1_1-54
3-54
Initial System
Configuration
Lesson 4
2011 Cisco and/or its affiliates. All rights reserv ed. Cisco Conf idential
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
Module Overview
Understanding the Boot Process and Boot Stack
File System Basics
Initial System Configuration Methods
2011 Cisco and/or its affiliates. All rights reserv ed. Cisco Conf idential
4-3
4-4
Placing the PFU power switches to the on position, which applies -48VDC to
the chassis.
2011 Cisco and/or its affiliates. All rights reserv ed. Cisco Conf idential
4-5
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.
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.
(next slide)
2011 Cisco and/or its affiliates. All rights reserv ed. Cisco Conf idential
4-7
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..
Is card Installed?
no
yes
(next slide)
2011 Cisco and/or its affiliates. All rights reserv ed. Cisco Conf idential
4-9
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.
(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
2011 Cisco and/or its affiliates. All rights reserv ed. Cisco Conf idential
11
4-11
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
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
2011 Cisco and/or its affiliates. All rights reserv ed. Cisco Conf idential
13
4-13
4-14
2011 Cisco and/or its affiliates. All rights reserv ed. Cisco Conf idential
15
4-15
4-16
2011 Cisco and/or its affiliates. All rights reserv ed. Cisco Conf idential
17
4-17
4-18
# this is a comment
config
context source
end
2011 Cisco and/or its affiliates. All rights reserv ed. Cisco Conf idential
19
4-19
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.
2011 Cisco and/or its affiliates. All rights reserv ed. Cisco Conf idential
21
4-21
Description
-redundant
-noconfirm
4-22
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
2011 Cisco and/or its affiliates. All rights reserv ed. Cisco Conf idential
23
4-23
4-24
2011 Cisco and/or its affiliates. All rights reserv ed. Cisco Conf idential
25
4-25
Keyword/Variable
Description
all
checkonly
from
to
-noconfirm
4-26
2011 Cisco and/or its affiliates. All rights reserv ed. Cisco Conf idential
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
Initial Connection
ASR 5500
Rear
console port on
active MIO
Management
LAN Interfaces
2011 Cisco and/or its affiliates. All rights reserv ed. Cisco Conf idential
29
4-29
4-30
2011 Cisco and/or its affiliates. All rights reserv ed. Cisco Conf idential
31
4-31
4-32
2011 Cisco and/or its affiliates. All rights reserv ed. Cisco Conf idential
33
4-33
4-34
2011 Cisco and/or its affiliates. All rights reserv ed. Cisco Conf idential
35
4-35
4-36
System name
Port on the spio card that will be used for management access
37
4-37
Additionally, you are given the opportunity to review, or change, any of your settings.
4-38
2011 Cisco and/or its affiliates. All rights reserv ed. Cisco Conf idential
39
4-39
4-40
2011 Cisco and/or its affiliates. All rights reserv ed. Cisco Conf idential
41
4-41
2011 Cisco and/or its affiliates. All rights reserv ed. Cisco Conf idential
4-42
42
Lesson 5
5-1
Module Objectives
5-2
Module Objectives
Upon completing this lesson, you will be able to meet
these objectives:
Users Permissions
Config Modes
Access Privilliges
SNMP
Time/Date .
1_1-3
5-3
Module Agenda
5-4
Module Agenda
Command Line Interface (CLI) Operation
CLI Global Commands
Summary
Lab1: Introduction to the CLI Hardware overview
1_1-5
5-5
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.
1_1-7
5-7
5-8
ip access-list name
ACL
Configuration
Mode
GGSN servicename
GGSN Service
Configuration
Mode
configure
Global
Configuration
Mode
Sub-modes available
in config mode
Accessible to all
Administrator users
Ethernet Port
Conf iguration
Mode
card number
Card
Conf iguration
Mode
context name
Context
Conf iguration
Mode
Service
Configuration
Mode
server telnetd
Telnet
Configuration
Mode
1_1-9
5-9
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
1_1-11
5-11
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.
The diagram on the opposite page illustrates the relationship between these four
privilege levels
5-12
Administrator
Config-Administrator
Exec Mode
Config Mode
Operator
Inspector
1_1-13
5-13
5-14
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
Config-Administrator
Administrator
Config-Administrator
Operator
Operator
Inspector
Inspector
Administrator
1_1-15
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
CLI Instances
Multiple CLI sessions can by hosted by the ASR 5500,
with a minimum number assured:
15 assured sessions on the ASR 5500
1_1-17
5-17
5-18
Command Mode:
Shows the specific command
mode or sub-mode in which
the user is currently working.
1_1-19
5-19
5-20
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.
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
5-21
Description
{ keyword or
variable }
[ keyword or
variable ]
5-22
1_1-23
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
-v
--ignorecase
--invertmatch
expression
5-24
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
5-25
Module Agenda
5-26
Module Agenda
StarOS Command Line Interface Introduction
CLI Global Commands
Summary
Lab1: Introduction to the CLI Hardware overview
1_1-27
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
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
1_1-29
5-29
Description
ip_address
prefer
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
maxpoll
poll_period
5-30
1_1-31
5-31
5-32
configure
timestamps
configure
no timestamps
1_1-33
5-33
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.
5-35
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
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
configure
context local
administrator admin password starent ftp
config-administrator cfgadmin password starent ftp
Privilege level
1_1-37
5-37
Description
name
password
encrypted
password
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
timeoutidle
5-38
configure
context local
operator operator1 password starent
inspector inspector1 password starent
Privilege level
1_1-39
5-39
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 ]
[ 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
configure
local-user username staruser authorization-level
security-admin ftp password starent
Privilege level
Account password
1_1-41
5-41
5-42
Oper State
------------Active
Active
Active
Standby
Active
Standby
SPOF
---No
No
No
No
-
Attach
------
1_1-43
5-43
5-44
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
5-45
5-46
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
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
5-47
5-48
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
5-49
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
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
5-51
5-52
1_1-53
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
Port Switchover
Network traffic can be switched from the active to the standby port:
[local]Training-School-9# port switch to 6/11
Are you sure? [Yes|No]: yes
[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
5-55
5-56
1_1-57
5-57
Description
name
ip_address
non-default
port
security-name
string
version
informs
traps
5-58
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
5-59
5-60
configure
snmp trap suppress ?
snmp trap suppress <trap_name1> <trap_name2>
snmp trap enable <trap_name1> target <target-name>
1_1-61
5-61
Module Summary
5-62
Module Summary
You should now be able to demonstrate :
Running commands on the CLI to accomplish
Configuration
Migrate Cards
Switch Cards
Switch Ports
1_1-63
5-63
1_1-64
5-64
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:
5-65
Visual Objective
The figure below illustrates the network topology for this activity.
putty
Internet
Cisco
Firewall
ASR5500
Activity Procedure
Complete these steps:
Step 1
5-66
Activity Verification
You have completed this task when you attain these results:
You can successfully access the chassis in our lab via direct connection.
You have determined other users who have logged into the
chassis.
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
#show clock
5-67
Step 5
Determine what modules have been installed and their operational state.
Step 6
____________
____________
____________
____________
____________
#show led
Slot
5-68
Card Type
Status
#show
#show
#show
#show
fan
power
temperature
temperature verbose
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
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.
5-69
Step 10
Check the hardware inventory to record part numbers and serial numbers.
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
Lesson 6
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
Module Objectives
Upon completing this module, you will be able to meet
these objectives:
Contexts
Logical Interfaces
Loopbacks
Ports
Services
Redundant interfaces
Lag groups
1_1-3
6-3
Module Agenda
6-4
Module Agenda
Configuration Building Blocks
Contexts
Interfaces
Ports
Services
Port Redudancy
LAG Group
1_1-5
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
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
Default context
(for management)
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:
6-8
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
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
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
6-11
6-12
1_1-13
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 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.
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
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
6-15
PhysicalPorts
The actual layer 1 connection point. These are the MIO interfaces.
6-16
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
IPaddress1 IPaddress2
OR
VLAN1
VLAN2
IPaddress3
IPaddress4
VLAN3
VLANxxx
1_1-17
6-17
occurs.
LAG algorithm for load sharing traffic is the same as with ECMP. It is
6-18
5/10
5/11
5/15
DSTx
5/16
DSTy
ASR 5500
Secondary
links
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
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
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
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
Services
A service provides call-processing capability
Could be one of the following:
- PGW service
- SGW service
- SAEGW service
saegw context
SGW Service
5/11
5/10
6/10
5/16
5/15
6/11
6/15
6/16
1_1-23
6-23
6-24
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
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
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
1_1-27
6-27
6-28
APN config
Support context
1_1-29
6-29
Module Agenda
6-30
Module Agenda
Configuration Building Blocks
Contexts
Interfaces
Ports
Services
Port Redudancy
LAG Group
1_1-31
6-31
System Requirements
6-32
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
6-33
6-34
1_1-35
6-35
6-36
1_1-37
6-37
6-38
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
6-39
6-40
SAEGW
2.
SGi
3.
SupportZone
4.
1_1-41
6-41
Configuring a Context
6-42
1a
Configuring a Context
[local]Training-School-9# config
[local]Training-School-9(config)# context saegw-1
Are you sure? [Yes|No]: yes
[saegw-1]Training-School-9(config-ctx)# exit
[local]Training-School-9(config)# context SupportZone-1
Are you sure? [Yes|No]: yes
[SupportZone-1]Training-School-9(config-ctx)# exit
[local]Training-School-9(config)# context SGi-4
Are you sure? [Yes|No]: yes
[SGi-4]Training-School-9(config-ctx)# exit
[local]Training-School-9(config)# exit
1_1-43
6-43
6-44
1b
created by default
1_1-45
6-45
6-46
2a
1_1-47
6-47
6-48
2b
1_1-49
6-49
6-50
2c
1_1-51
6-51
Validating IP Interfaces
6-52
2d
Validating IP Interfaces
6-53
Validating IP Interfaces
6-54
2e
Validating IP Interfaces
1_1-55
6-55
[local]TS-9(config-port-5/21)# vlan 5
[local]TS-9(config-port-5/21-vlan-2)# no shut
[local]TS-9(config-port-5/21-vlan-2)# bind interface 5/21-pcrf
SupportZone-1
[local]TS-9(config-port-5/21-vlan-2# exit
6-56
3a
Slot# / port
#
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
6-57
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
Address/Mask
Port
Status
============================== =================
5/21-sgi
192.168.2.111/24
5/21 vlan 2
UP
6-58
3b
1_1-59
6-59
6-60
3c
1_1-61
6-61
6-62
3d
1_1-63
6-63
6-64
configure
local-user username staruser authorization-level
security-admin ftp password starent
Privilege level
Account password
1_1-65
6-65
Agenda
6-66
Module Agenda
Configuration Building Blocks
Contexts
Interfaces
Ports
Services
Port Redudancy
LAG Group
1_1-67
6-67
6-68
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
6-69
Module Summary
6-70
Module Summary
Configuration Building Blocks
Contexts
Interfaces
Ports
Services
MIO Redundancy
Lag Groups
1_1-71
6-71
1_1-72
6-72
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
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
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
6-75
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
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
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
__ 12) Exit out of the Interface Configuration sub-mode by entering the following
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
6-77
__ 14) 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 <address> <mask>
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
__ 15) Exit out of the Interface Configuration sub-mode by entering the following
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
__ 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.
6-79
Slot# /
port #
20/x
29/x
20/x_S1-U
20/x_S11-mme
20/x_S8
29/x-sgi
29/x-pcrf
__ 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