Cisco CRS

CRSE
Cisco CRS-1 Essentials

Version 2.0b
Instructor Guide
Text Part Number: xx-xxxx-xx
Copyright 2005, Cisco Systems, Inc. All rights reserved.

Cisco Systems has more than 200 offices in the following countries and regions. Addresses, phone numbers, and fax
numbers are listed on the Cisco Web site at www.cisco.com/go/offices.
Argentina Australia Austria Belgium Brazil Bulgaria Canada Chile China PRC Colombia Costa Rica Croatia Czech
Republic Denmark Dubai, UAE Finland France Germany Greece Hong Kong SAR Hungary
India Indonesia Ireland Israel Italy Japan Korea Luxembourg Malaysia Mexico The Netherlands
New Zealand Norway Peru Philippines Poland Portugal Puerto Rico Romania Russia Saudi Arabia
Scotland Singapore Slovakia Slovenia South Africa Spain Sweden Switzerland Taiwan Thailand Turkey Ukraine
United Kingdom United States Venezuela Vietnam Zimbabwe
Copyright 2005, Cisco Systems, Inc. All rights reserved. CCIP, the Cisco Powered Network mark, the
Cisco Systems Verified logo, Cisco Unity, Follow Me Browsing, FormShare, Internet Quotient, iQ
Breakthrough, iQ Expertise, iQ FastTrack, the iQ logo, iQ Net Readiness Scorecard, Networking Academy,
ScriptShare, SMARTnet, TransPath, and Voice LAN are trademarks of Cisco Systems, Inc.; Changing the Way We
Work, Live, Play, and Learn, Discover All Thats Possible, The Fastest Way to Increase Your Internet Quotient, and
iQuick Study are service marks of Cisco Systems, Inc.; and Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE,
CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, the Cisco IOS logo, Cisco Press,
Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Empowering the Internet Generation,
Enterprise/Solver, EtherChannel, EtherSwitch, Fast Step, GigaStack, IOS, IP/TV, LightStream, MGX, MICA, the
Networkers logo, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, RateMUX, Registrar, SlideCast,
StrataView Plus, Stratm, SwitchProbe, TeleRouter, and VCO are registered trademarks of Cisco Systems, Inc.
and/or its affiliates in the U.S. and certain other countries.
All other trademarks mentioned in this document or Web site 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. (0203R)
Printed in the USA
Course Overview
Intended Audience
This course is for technical professionals who need to know how to
implement Cisco CRS-1 in their network environment. The following
are considered the primary audience for this course:
Install Technicians
NOC Engineers
Network and Senior Engineers
Course Level
This course provides a fundamental level of information pertaining to
the Cisco Carrier Routing System family of products.
Prerequisites
The following courses are prerequisites:
Basic knowledge of router installation and some experience with

installation tools
Routing protocols configuration experience with BGP, ISIS and

OSPF or BSCI (Building Scalable Cisco Internetworks course)
Advanced knowledge of BGP multi-homed, multi-as configurations,

or CBCR (Configuring BGP on Cisco Routers course)
Strong knowledge of MPLS configuration or CMPLS course
Multicast configuration experience or Cisco Multicast

Configuration course
Advanced knowledge of Cisco router security implementation

including AAA, Tacacs, or (Cisco Security authentication class)
Experience troubleshooting Cisco routers in a large network

environment, or, CIT (Cisco Internetworking Troubleshooting
course)
Additional Information
Cisco Systems Technical Publications
You can print technical manuals and release notes directly from the
Internet. Go to http://www.cisco.com/univercd/home/home.htm.
Find the Cisco Systems product for which you need documentation.
Then locate the specific category and model or version for your
2005 Cisco Systems, Inc.
Version 2.0
hardware or software product. Using Adobe Acrobat Reader, you can

open the manuals and release notes, search for the sections you need,
and print them on most standard printers. You can download Acrobat
Reader free from the Adobe Systems Web site, www.adobe.com.
Documentation sets and CDs are available through your local Cisco
Systems sales office or account representative.
Cisco Systems Service
Comprehensive network support is available from Cisco Systems

Service & Support solutions. Go to
http://www.cisco.com/public/support_solutions.shtml for a listing of
services.
vi
Version 2.0
Course Agenda
Day 1
Course and Student Introduction
Module 1 Introduction to CRS-1
Module 2 CRS-1 16-Slot Line Card Chassis Hardware
Module 3 CRS-1 8-Slot Line Card Chassis Hardware
Module 4 CRS-1 Line Card Chassis Common Elements
Module 5 Introduction to Cisco CRS-1 Multi-Shelf Architecture
Day 2
Module 6 Cisco IOS XR Overview and Initial Configuration
Lab 1 Hardware Discovery and Initial Configuration
Module 7 - Cisco IOS XR Operations
Lab 2 Cisco IOS XR Operations
Module 8 Cisco IOS XR Installation
Lab 3 IOS XR Software Installation
Day 3
Module 9 IOS XR Security
Lab 4 IOS XR Security
Module 10 Routing Protocols
Lab 5 IS-IS Routing Configuration
Lab 6 OSPF Routing Configuration
Lab 7 iBGP Routing Configuration
Lab 8 IP Multicast Configuration
Day 4
Module 11 Routing Policy Language
Lab 9 Building RPL Route Policies
Module 12 IOS XR MPLS
Lab 10 MPLS
Module 13 Craft Works Interface
Lab 11 Using CWI to Monitor and Configure
Module 14 Data Flow and MQC QoS
Course Summary
Version 2.0
vii
viii
Version 2.0
Course Introduction and Objectives
Overview
Description
This course is designed to train a variety of audiences on the CRS-1
platform. The course is modular in design. Only those modules which
a particular audience needs to perform its tasks needs to be presented,
thus shortening the duration that they need to be away from their job
functions to attend training.
The course introduces the student to the Cisco CRS-1 platforms, its
features and functions. The course then builds up on that information
by strengthening the students understanding of the platform. The
modules are both theoretical and practical in scope. Some of the
modules present both technology and features of certain elements of
the platform in order to build the students understanding of the
benefits of choosing the CRS-1. Most of the modules, however, are
specifically designed with clear, task oriented and specific objectives
built around the job functions of the intended student. Most modules
are re-enforced with review questions and hands-on lab exercises. The
aim of the review questions and lab exercises are to demonstrate the
students ability to use the knowledge and skills gained during this
course to perform measurable tasks.
Objectives
After completing this course, you will be able to do the following:
List and describe the major features and benefits of a Cisco CRS-1
routing system
List and describe the major features and benefits of Cisco IOS XR
operating system
Configure CRS-1 platform, back out of configuration changes,

restore older versions of configuration
Version 2.0
ix
Install Cisco IOS XR operating system, Package Information

Envelopes (PIEs) and Software Maintenance Updates (SMU)
Configure the new IOS XR security features
Configure routing protocols in a complex multi-AS environment

(focus on IOS differences)
Enable Multicast routing on IOS XR platforms (focus on IOS

differences)
Configure MPLS on IOS XR platform
Convert legacy route map configurations using new RPL

language
Use the CWI to configure, view, check configurations and obtain

alarm status of CRS-1 nodes
Understand data flow through the CRS-1 routing system
Troubleshoot basic CRS-1 hardware and software problems
Version 2.0
Contents
Course Overview.....................................................................................................................v
Course Agenda..................................................................................................................... vii
Course Introduction and Objectives ................................................................ ix

Overview ................................................................................................................................ix
Module 1 .......................................................................................................... 11
Overview .............................................................................................................................11
Cisco CRS-1 Carrier Routing Systems..............................................................................12
Market Place Demands ......................................................................................................14
Current PoP Design............................................................................................................16
Getting the CRS-1 into the Network.................................................................................18
Cisco CRS-1 System Configurations ...............................................................................112
Cisco CRS-1 Line Card Chassis.......................................................................................116
Cisco CRS-1 Interfaces.....................................................................................................118
Summary...........................................................................................................................120
Module 2 .......................................................................................................... 21
Overview .............................................................................................................................21
CRS-1 16-Slot Line Card Chassis......................................................................................22
CRS-1 16-Slot Line Card Chassis Components................................................................24
CRS-1 16-Slot Line Card Chassis Slot Numbering ........................................................210
CRS-1 16-Slot Line Card Chassis Power System ...........................................................212
CRS-1 16-Slot Line Card Chassis AC Power Shelves and Rectifiers............................222
CRS-1 16-Slot Line Card Chassis DC Power System ....................................................230
CRS-1 16-Slot Line Card Chassis Alarm Module...........................................................242
CRS-1 16-Slot Chassis Line Card Chassis Cooling System...........................................248
CRS-1 16-Slot Chassis Single Line Card Switch Fabric................................................266
CRS-1 16-Slot Chassis S123 Switch Fabric Card...........................................................268
CRS-1 16-Slot Chassis Route Processor (RP) .................................................................274
Summary...........................................................................................................................288
Version 2.0
xi
Module 3 .......................................................................................................... 31
Overview .............................................................................................................................31
CRS-1 8-Slot Line Card Chassis........................................................................................32
CRS-1 8-Slot Line Card Chassis Components..................................................................34
CRS-1 8-Slot Line Card Chassis Slot Numbering ..........................................................310
CRS-1 8-Slot Line Card Chassis Power System .............................................................312
CRS-1 8-Slot AC Power System.......................................................................................318
CRS-1 8-Slot DC Power System ......................................................................................326
CRS-1 8-Slot Line Card Chassis Cooling System...........................................................332
CRS-1 8-Slot Line Card Chassis Switch Fabric .............................................................344
CRS-1 8-Slot Line Card Chassis Route Processor..........................................................350
Summary...........................................................................................................................362
Module 4 .......................................................................................................... 41
Overview .............................................................................................................................41
Modular Services Card.......................................................................................................42
DRP Architecture - LC Chassis .........................................................................................46
Physical Layer Module (PLIM)..........................................................................................48
Shared Port Adapters (SPAs) and SPA Interface Processor-800 (SIP-800) .................436
SIP Bandwidth Oversubscription....................................................................................444
4-Port OC-3c/STM-1 SPA.................................................................................................449
1-Port OC-192c/STM-64 PoS/RPR XFP SPA ..................................................................453
8-Port Gigabit Ethernet SPA ...........................................................................................457
Summary...........................................................................................................................461
Module 5 .......................................................................................................... 51
Overview .............................................................................................................................51
Switch Fabric Chassis ........................................................................................................52
Switch Fabric Components ................................................................................................56
System Configurations .......................................................................................................58
Switch Fabric Chassis Interconnections .........................................................................512
In-service upgrade from Standalone to Multi-Shelf.......................................................516
CRS-1 Management System Control Plane and Shelf Controller Gigabit Ethernet (SCGE) card ............................................................................................................................518
Summary...........................................................................................................................522
Module 6 .......................................................................................................... 61
Overview .............................................................................................................................61
xii
Version 2.0
Cisco IOS XR Architecture.................................................................................................62

High Availability ................................................................................................................64
Scalability .........................................................................................................................624
Configuration Operations ................................................................................................636
Configuration Basics ........................................................................................................644
Summary...........................................................................................................................668
Module 7 .......................................................................................................... 71
Overview .............................................................................................................................71
Cisco IOS XR Command Modes.........................................................................................72
Configuration Operations ................................................................................................714
Miscellaneous CLI Commands ........................................................................................752
Process Management........................................................................................................762
Summary...........................................................................................................................772
Module 8 .......................................................................................................... 81
Overview .............................................................................................................................81
Cisco IOS XR Software Packaging ....................................................................................82
Package Management ......................................................................................................820
Software Installation Review...........................................................................................836
Summary...........................................................................................................................846
Module 9 .......................................................................................................... 91
Overview .............................................................................................................................91
Cisco IOS XR Security Overview.......................................................................................92
Cisco IOS XR Security Implementation..........................................................................910
Security Configuration .....................................................................................................942
Access Control Lists .........................................................................................................958
Summary...........................................................................................................................970
Module 10 ...................................................................................................... 101

Overview ...........................................................................................................................101
Border Gateway Protocol (BGP) ......................................................................................102
Open Shortest Path First (OSPF) .................................................................................1028
Intermediate System-Intermediate System (IS-IS) .....................................................1048
Multicast Routing ...........................................................................................................1062
Summary.........................................................................................................................1074
Version 2.0
xiii
Module 11 ...................................................................................................... 111

Overview ...........................................................................................................................111
RPL Overview ...................................................................................................................112
RPL Description..............................................................................................................1112
BGP Route Attributes and Operations .........................................................................1148
Converting Route Maps to RPL Policies .......................................................................1178
RPL-Specific CLI Commands ......................................................................................11102
Summary.......................................................................................................................11110
Module 12 ...................................................................................................... 121

Overview ...........................................................................................................................121
MPLS Forwarding Infrastructure ...................................................................................122
Label Distribution Protocol............................................................................................1216
MPLS Traffic Engineering .............................................................................................1234
Summary.........................................................................................................................1268
Module 13 ...................................................................................................... 131

Overview ...........................................................................................................................131
CWI Overview...................................................................................................................132
Desktop Applications......................................................................................................1324
Router Configuration .....................................................................................................1336
Graphical Configuration Applications ..........................................................................1346
Getting Started ...............................................................................................................1366
Summary.........................................................................................................................1378
Module 14 ...................................................................................................... 141

Overview ...........................................................................................................................141
CRS-1 QoS Hardware Components.................................................................................142
Life of a Packet .................................................................................................................144
IngressQ queuing and shaping ......................................................................................1426
EgressQ queuing and shaping .......................................................................................1428
Switch Fabric Cell Structure .........................................................................................1430
Worst Case Fabric Cell Loading ....................................................................................1434
Switch Fabric Architecture ............................................................................................1436
Switch Fabric Features ..................................................................................................1440
Modular QoS Command-Line Interface ........................................................................1444
Summary.........................................................................................................................1460
xiv
Version 2.0
Append A
A1
Troubleshooting
A-1
Appendix B ..................................................................................................... B1
Student Evaluation ........................................................................................ B1
Version 2.0
xv
xvi
Version 2.0
Module 1
Cisco CRS-1 Carrier Routing System
Overview
Description
This module describes the platforms and components that currently
support Cisco IOS XR software. You will learn about the hardware
requirements and specifically applicable features to the platforms.
Objectives
After completing this module, you will be able to do the following:
List the major features of the Cisco CRS-1 routing systems
List and describe the different Cisco CRS-1 platforms
Describe the Market Place demands that drove the development efforts
of the Cisco CRS-1 routing system
Describe the current POP design and Cisco CRS-1 insertion strategy
List and describe four features of core-layer consolidation using the

Cisco CRS-1 routing system
Compare and contrast the Cisco CRS-1 16- and 8-slot line card chassis
List the Cisco CRS-1 interfaces types
Version 2.0
11
Module 1
Cisco CRS-1 Carrier Routing Systems

Overview
The Cisco CRS-1 includes two major elements, line-card chassis and fabric
chassis, combinations of which allow the Cisco CRS-1 to scale from eight
40-Gbps slots to as many 1152 40-Gbps slots in 72 line-card chassis
interconnected using eight fabric chassis, all operating as a single system.
12
Version 2.0b
Module 1
Cisco CRS-1 Carrier Routing Systems
Cisco CRS-1 Carrier Routing Systems - Overview
Next Generation Core

CRS-1
40 Gbps routing
Multishelf scale
Foundation for core
consolidation
Version 2.0b
13
Module 1
Market Place Demands

IP PoP Evolution - Scaling
IP PoP design has always been dependent on a variety of factors:
1. Cost
2. The ability to provide a multitude of speeds and feeds to interface with
different customer equipment
3. The ability to maintain a stable environment using a host of different
vendors products and technologies
4. Software functionality that allowed for features to be provided at the
edge of the providers network (the customer)
Since networks have increasingly become IP based core design has
centered more and more on the high speed router. Thus, router hardware
evolution has centered on increasing backplane capacity, increasing
interface speeds and feeds and incorporating software features in ASIC
design.
The CRS-1 will remove the bottle neck of interconnection technology, with
a multitude of speeds and feeds and with a full set of software features
that are incorporated in the ASIC technology. This puts it in a class by
itself and apart from the other high speed routers now available. What the
CRS-1 provides that has never been previously delivered is the hardware
and software flexibility to simplify PoP design and set the stage to
effectively scale a network into the future.
14
Version 2.0b
Module 1
Market Place Demands
IP PoP Evolution - Scaling
Late 1990
Early 1992
POS
Mid 1995
1998-99
FDDI
X
XSwitch
2004-future
POS
POS
Shared
FDDI Ring
2000-02
Ethernet
ATM
POS
GSR
Cisco
75XX
GSR
DPT
Cisco
75XX
Cisco
75XX
Cisco
75XX
Cisco
75XX
Historically, scaling a PoP is always a problem

Many interconnect technologies have evolved over time but all need to
occupy a revenue generation slot
PoP consolidation leads to converged core, peering, and edge
functions
High Availability is one of the keys to PoP consolidation
Version 2.0b
15
Module 1
Current PoP Design

Interconnect
Current PoP design uses a variety of layers (Core, Distribution and
Aggregation) to transport (DSL, cable, Metro Eth, OCn), route (peering),
and aggregate different speeds and feeds with features at the edge
(policing, VPNs, TLS, VoIP). No one wonder box exists that provides all the
speeds, feeds, features and capacities at all layers. One box might
terminate traffic and provide features needed, while another is capable of
backhauling and can provide resiliency and recovery.
Core routers can move data at very fast rates and have evolved to provide
more and more features in their ASICs thus enabling their migration
towards the customer edge. Their high cost however, have made them
unlikely to be used at the very edge of the network, where other cheaper
boxes often were able to provide similar services at a lower overall price
per interface while only marginally increasing complexity of design.
However, all the different boxes need to be interconnected, leading to a
reduction in the number of ports available for customer traffic with the
number of boxes and links required to operate to support the PoP. The
problem only increases with PoP size which then leads to a scaling problem
often wiping out any initial cost savings. The typical solution of deploying
higher capacity boxes alleviates the scaling problem temporarily but does
nothing to reduce your basic capital and operational cost structure.
16
Version 2.0b
Module 1
Current PoP Design
Current PoP Design Interconnect
OC-12/48->OC-192
Core
Peering
1GE->10GE
1GE/OC-3/12/48DPT
Distribution
DS-3, 1GE
OC-3/12/48
Aggregation
OC-3/12/48DPT
T1/1GE
OC-3/12
Version 2.0b
17
Module 1
Getting the CRS-1 into the Network

Core Layer Insertion
The CRS-1 allows the replacement of multiple platforms in todays PoP and
its primary application following current POP design is a best-in-class next
generation core router. As such we expect customers to first insert a single
chassis system as a replacement for one of their core routers.
As customers become satisfied with the performance and stability of the
CRS-1 platform a gradual and phased introduction of the CRS-1 into the
distribution layer is expected. The slide represents a typical first stage
CRS-1 insertion into a customer network.
18
Version 2.0b
Module 1
Core Layer Insertion
OC-12/48->OC-192
Core
CRS-1
CRS-1
Peering
1GE->10GE
1GE/OC-3/12/48DPT
Distribution
DS-3, 1GE
OC-3/12/48
Aggregation
OC-3/12/48DPT
T1/1GE
OC-3/12
Version 2.0b
19
Module 1
Core Layer Consolidation

After insertion into the core of the network, the next step is to consolidate
equipment used for peering and distribution. This second step is dependent
on features being released and supported in CRS-1 interfaces and new
CRS-1 cards made available with a variety of speeds and feeds.
PoP consolidation is a concept that can lead to a radical reduction in the
number of routers, links, peers, and hops in your network. It leverages a
lower your cost structure by:
1. Replacing the expensive inter-router mesh with a more cost effective
switch fabric-enabling all ports to be used for customer generating
traffic.
2. Reducing the number of elements you need to manage in your network
3. Streamlining your upgrade procedures since upgrading a PoPs
capacity is achieved by simply adding linecards and line card chassis
with no need to interconnect separate routers and modify routing
architectures. (Upgrade here is not referring to SW upgrades but to the
ability to add new speeds and feeds and more equipment into a network
design.)
4. Partitioning the CRS-1 into logical routers (concept discussed later in
course) to assist customers in their migration from a distributed to a
consolidated PoP.
110
Version 2.0b
Module 1
Core Layer Consolidation
STM-64/256
Core
10GE/STM-16/64DPT
STM-256 Ch DS-3
CRS-1
5 Logical Router
partitions
Distribution
Aggregation
STM-4/16 DPT
1G/10GE
GSR120/124xx
CAT6K
Version 2.0b
1GE/10GE
STM-4/16
111
Module 1
Cisco CRS-1 System Configurations

Single Shelf System
The CRS-1 Single Shelf System is a 16-slot, 1.2-terabit router in a single
line-card chassis containing route processors (RPs); modular service cards
(MSCs), physical layer interface modules (PLIMs), and switch fabric. The
system supports up to 16 MSC/PLIM pairs.
A Cisco CRS-1 8-slot chassis is also a single shelf system with up to 8
MSC/PLIM pairs.
Multi-Shelf System
A CRS-1 Multishelf System consists of line card chassis and switch fabric
chassis (SFC) combinations. Possible combinations include:
2 12 Terabit Routerup to 6 line card chassis and one SFC, with support
for up to 96 MSCs
12 23 Terabit Routerup to 18 line card chassis and two SFC, with
support for up to 288 MSCs
23 46 Terabit Routerup to 36 line card chassis and 4 SFC, with support
for up to 576 MSCs
46 92 Terabit Routerup to 72 line card chassis and 8 SFC, with support
for up to 1152 MSCs
112
Version 2.0b
Module 1
CRS-1 System Configurations
Single Shelf System

8 or 16 MSC and PLIM slots
No Fabric chassis required
4 or 8 - Fabric cards in line card chassis
Multishelf System (1.2T TO 92T)
2 to 72 16-slot line card chassis'

1 to 8 fabric chassis
Version 2.0b
113
Module 1
Multi-shelf Systems
Switch-fabric chassis are connected to line-card chassis using parallel
optical fiber cables. This allows data coming into the line-card chassis to be
processed and forwarded across any of the fabric chassis and then out
another port on another line-card chassis.
User data passes over the fiber from chassis to chassis. An out-of-band
Gigabit Ethernet network is used for system control and management, and
all traffic generated for this remains separate from user traffic.
114
Version 2.0b
Module 1
Multi-Shelf Systems
Switch Fabric
Fiber cables are used to
interconnect LC through
SFC
Interchassis management
system control plane
traffic does not pass
through fiber cables
Version 2.0b
115
Module 1
Cisco CRS-1 Line Card Chassis

16-Slot
The Cisco CRS-1 16-Slot line card chassis is the mechanical enclosure,
built around a passive midplane, whose main function is to house 2 Route
Processor (RP) cards, 16 modular services cards (MSCs) and their
associated physical layer interface modules (PLIMs), and 8 switch-fabric
cards. The Cisco CRS-1 line card chassis does not require a separate
mounting rack; it is mounted directly to the facility floor. A fully loaded 16slot line card chassis supports a data throughput rate of 1.2 Tbps.
8-Slot
The Cisco CRS-1 8-slot chassis is a half-height chassis allowing it to be
installed in standard racks. The CRS-1 8-slot chassis supports 8 MSCs, 8
PLIMs, 2 RPs, and 4 fabric cards. MSCs and PLIMs are the same for both
the 16-slot and 8-slot chassis. Like the CRS-1 16-slot line card chassis, the
8-slot chassis contains a passive midplane that interconnects the RPs,
MSCs and PLIMs. The RPs and switch fabric cards in the 8-slot chassis are
a physically different size than the RPs and switch fabric cards in the 16slot chassis. A fully loaded 8-slot line card chassis supports a data
throughput rate of 640 Gbps.
The Cisco CRS-1 8-slot routing system provides the high-speed interfaces
in a smaller platform allowing easier deployment in places where power,
cooling, and other facilities might be hard to provision or too costly.
Software
Both Cisco CRS-1 routing systems use IOS XR software and provide the
same software features.
116
Version 2.0b
Module 1
CRS-1 16-slot
CRS-1 8-slot
Version 2.0b
117
Module 1
Cisco CRS-1 Interfaces

Overview
The following interfaces are available for the Cisco CRS-1 16 and 8-slot
chassis:
PLIMs
16-port OC-48c/STM-16c POS /DPT (Packet over SONET/Dynamic

Packet Transport)
4-port OC-192c/STM-64c POS/DPT
8-port 10 Gigabit Ethernet
SIP & SPAs
118
Shared Port Adapter (SPA) Interface Processor-800 (SIP-800)
8-port Gigabit Ethernet SPA
4-port OC-3c/STM-1c POS SPA
1- port OC-192c/STM-64c POS SPA
Version 2.0b
Module 1
Cisco CRS-1 Interfaces
Cisco CRS-1 Cards
PLIMs

8-port 10 Gigabit Ethernet
SPA Interface Processor-800
8-port Gigabit Ethernet SPA

4-port OC-3c/STM-1c POS SPA
1-Port OC-192c/STM-64c POS SPA
Version 2.0b
119
Module 1
Summary
Cisco IOS XR Hardware and Platform Overview
In this module, you learned the following:
120
The major features of the Cisco CRS-1 routing systems
How to list and describe the different Cisco CRS-1 platforms
The Market Place demands that drove the development efforts of the
Cisco CRS-1 routing system
How to describe the current POP design and Cisco CRS-1 insertion
strategy
How to list and describe four features of core-layer consolidation using

the Cisco CRS-1 routing system
How to compare and contrast the Cisco CRS-1 16- and 8-slot line card
chassis
The Cisco CRS-1 interfaces types
Version 2.0b
Module 2
CRS-1 16-Slot Line Card Chassis Hardware
Overview
Description
This module describes the CRS-1 16-slot line card chassis hardware
features and functions including the Field Replaceable Units (FRUs), and
components that comprise a single line card chassis system.
Objectives
List and describe the hardware features and functions of the CRS-1 16slot line card chassis
List and describe the features and functions of the FRUs and
components that comprise the CRS-1 16-slot Line Card chassis
List and describe the features and functions of the CRS-1 16-slot line
card chassis power system
card chassis alarm modules
card chassis cooling system
card chassis switch fabric
card chassis Route Processor
Version 2.0b
21
Module 2
CRS-1 16-Slot Line Card Chassis

Overview
The Cisco CRS-1 Carrier Routing System is a highly scalable routing
platform designed for efficient service provider point of presence (POP)
evolution as the IP network grows into a multiservice network.
The Cisco CRS-1 routing system consists of a single line card chassis, and
is designated the Cisco CRS-1 Carrier Routing System.
The Cisco CRS-1 routing system line card chassis is a mechanical
enclosure that houses modular services cards (MSCs) and their associated
physical layer interface modules (PLIMs), switch fabric cards, and route
processor (RP) cards. The chassis is bolted to the facility floor and does not
require an external rack. The chassis also contains its own power and
cooling systems.
Mid-plane Design
The Cisco CRS-1 16-slot chassis is a mid-plane design that interconnects
each of the Field Replaceable Modules (FRUs) together.
Front
The front side of the chassis is also referred to as the Physical Layer
Interface Module (PLIM) side. At the top of the chassis are two Power
Shelves, each with three AC rectifiers or three DC PEMs and one Alarm
module. It has two PLIM bays and upper and a lower. The upper bay has
eight PLIM slots, and two Fan Controllers (center). The lower bay has
eight PLIM slots and two Route Processor (RP) slots (center). At the
bottom of the chassis is the air intake grill.
Back
The back side of the chassis is also referred to as the Modular Services
Card (MSC) side. It has two eight slots MSC bays. The upper bay has eight
MSC/DRP slots and four Switch Fabric Card (SFC) slots (center). The
lower bay hold an addition eight MSCs/DRPs and four SFCs. Power
Shelves are at the very top of the chassis. Between the Power Shelves and
the upper MSC/DRP bay is the air exhaust grill.
Dimensions
The physical dimensions of the chassis are:
22
23.6 W x 41* D x 84 H
(60 W x 104.2 D x 213.36H (cm))
Power: ~13.2 KW (AC or DC)
Weight: ~1600 lbs/723kg
Heat Dis.: 41000 BTUs

Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Line Card Chassis Overview
Midplane design with front & rear access
Front
16 PLIM slots
2 RP slots + 2 Fan Controllers
Back
16 MSC Slots
8 Fabric cards
Dimensions:
23.6 W x 41* D x 84 H
(60 W x 104.2 D x 213.36H (cm))
Power: ~13.2 KW (AC or DC)
Weight: ~1600 lbs/723kg
Heat Dis.: 41000 BTUs
Version 2.0b
23
Module 2
CRS-1 16-Slot Line Card Chassis Components

This section lists the main components of a line card chassis. It primarily
identifies the components that are considered field-replaceable units
(FRUs), but where additional detail is useful identifies subassemblies that
are not field-replaceable.
Midplane
The chassis also contains a midplane that connects MSCs to their
associated PLIMs. The midplane design allows an MSC to be removed from
the chassis without having to disconnect the cables that are attached to the
associated PLIM. The midplane distributes power, connects the MSCs to
the switch fabric cards, and provides control plane interconnections. The
midplane is not field-replaceable by the customer.
PLIM Side
The PLIM side of the chassis is considered the front of the chassisthis is
where user data cables attach to the PLIMs and where cool air enters the
chassis. The PLIM side of the Cisco CRS-1 16-Slot Line Card Chassis
contains:
1. Two AC or two DC power shelves and AC rectifiers or DC power entry
modules (PEMs). The power shelves and AC rectifiers or DC PEMs
provide 13.2 kilowatts of redundant power for the chassis.
2. Two alarm modules that provide external alarm system connections.
The modules are located in the AC or DC power shelves.
3. Two fan controller cards that vary the high-speed fans in the fan trays
to adjust the airflow for ambient conditions.
4. Up to 16 PLIMs
5. Two route processor cards (RPs) that perform route processing and
supply the intelligence of the system by functioning as the line card
chassis system controller.
24
Version 2.0b
Module 2
Components PLIM Side
1
2
3
4
5
Version 2.0b
25
Module 2
MSC Side
The MSC side, which is where warm air is exhausted, is considered the
rear of the chassis.
1. Air exhaust outlet
2. Upper fan tray pulls air up through the chassis and exhausts it out the
air exhaust outlet
3. Eight switch fabric cards that provide the three-stage Benes switch
fabric for the system. The switch fabric performs the cross-connect
function of the routing system, connecting every MSC (and its
associated PLIM) with every other MSC (and associated PLIM) in the
system. The switch fabric receives user data from one MSC and PLIM
pair and performs the switching necessary to route the data to the
appropriate egress MSC and PLIM pair.
4. The MSC provides the forwarding engine for Layer 3 routing of user
data, and the PLIM provides the physical interface and connectors for
the user data. One type of MSC exists, but it can be associated with
several different PLIMs, which provide different interface speeds and
technologies.
5. A removable air filter
6. Lower fan tray that draws air into the chassis
7. Lower fan tray that pushes air up through the chassis
26
Version 2.0b
Module 2
MSC Side
1
2
3
4
5
6
Version 2.0b
27
Module 2
Cable-Management
The CRS-1 16-slot line card chassis contains two horizontal cablemanagement brackets that provide cable management capabilities for the
MSCs and PLIMs installed in your line card chassis. The cablemanagement brackets are pre-installed on the front (PLIM) side of the line
card chassis directly above the upper and lower PLIM bays. In a singlechassis system, the following ports are for external cable connections:
CONSOLE or AUX RJ-45 RS-232 serial ports on the route processor

cards for terminal connections
Ethernet ports on the route processor cards for connecting network

management equipment
Physical layer interface modules (PLIMs) for data connections
RJ-45 external clock (EXT CLK 1 and EXT CLK 2) connectors for the
Building Integrated Timing Source (BITS) signaling cables from the fan
controller card
The cable-management bracket is for organizing these interface cables to

keep the front of the chassis clear and to eliminate sharp bends in the
cables.
Cable-management bracket has telescoping feature that allows bracket to
be extended when chassis is upgraded with higher-density cards.
28
Version 2.0b
Module 2
Cable Management
Cable-management bracket has telescoping feature

that allows bracket to be extended when chassis is
upgraded with higher-density cards.
Cablemanagement
Version 2.0b
29
Module 2
CRS-1 16-Slot Line Card Chassis Slot Numbering

PLIM Side
The line card chassis numbers on the PLIM side of the chassis include:
Power shelf 0 (PS0) and associated power module slots A0, A1, A2;
alarm module slot (AM0).
Power shelf 1 (PS1) and associated power module slots B0, B1, B2;
alarm module slot (AM1).
Upper PLIM card cage with eight MSC slots (left to right, 0, 1, 2, 3...4,
5, 6, and 7) and two double-width fan controller card slots, FC0 and
FC1.
Lower PLIM card cage with eight MSC slots (left to right, 8, 9, 10,
11...12, 13, 14, and 15) and two double-width route processor card slots,
RP0 and RP1.
MSC Side
The slot numbers on the MSC side of the chassis include:
Top fan tray (FT0).
Upper MSC-switch fabric cage, eight line card slots (7, 6, 5, 4...3, 2, 1, 0)
and four switch fabric card slots (SM0, SM1, SM2, and SM3).
Lower MSC-switch fabric cage, eight line card slots (15, 14, 13, 12...11,
10, 9, 8) and four switch fabric card slots (SM4, SM5, SM6, and SM7).
Lower fan tray (FT1).
The MSC slot numbers are reversed from the PLIM slot numbers on the
other side of the chassis. Because an MSC mates with its associated PLIM
through the midplane, MSC slot 0 is on the far right side of the chassis
looking at it from the MSC (rear) side; PLIM slot 0 is on the far left side of
the chassis looking at if from the PLIM (front) side. MSC slot 0 and PLIM
slot 0 mate with one another through the midplane, and so do all the other
MSC and PLIM slots (2 through 15).
210
Version 2.0b
Module 2
Version 2.0b
211
Module 2
CRS-1 16-Slot Line Card Chassis Power System

Overview
The line card chassis can be powered by either AC (Wye 3-phase 200240/346-415 VAC or Delta 3-phase 200-240 VAC) or DC (48 or 60 VDC)
power. The chassis power system takes the facility power and converts it to
the DC voltage necessary to power chassis components. The power system,
which is fully redundant, comprises:
212
Redundant AC or DC power shelves
Three AC rectifiers or three DC power entry modules (PEMs) per shelf
Alarm modules
Dual bus bars
Chassis midplane
Special components on cards or modules, such as DC-to-DC converters,

OR-ing diodes or EMI filters
Version 2.0b
Module 2
CRS-1 16-Slot Line Card Chassis Power System - Overview
Power System is fully

redundant and is comprised of:
AC or DC power shelves
3 AC rectifiers or DC PEMs
per shelf
Alarm modules
Dual bus bars
Chassis midplane
Special components on
cards or modules, like DCto-DC converters, or ORing
diodes or EMI filters
Version 2.0b
213
Module 2
Power Architecture
The line card chassis power architecture uses A and B power shelves to
provide:
Redundant power for all components in the chassis (An A and a B side)
2N redundancy for both AC- or DC-powered chassis
Both an A and a B power input to the components in the chassis
The line card chassis still operates normally if:
One AC rectifier or DC PEM fails
One entire power shelf fails, or one bus baran integral part of the
chassisfails
With this power architecture, it takes two failures before the system is
degraded; the failures would have to occur in both the A and B sides of the
power architecture and effect the same load zone for the degradation to
occur.
This architecture, which applies to either AC- or DC-powered line card
chassis, is built around:
Dual power shelves
Dual bus bars
Six load zones
Dual power inputs to cards and modules in the chassis
Different power shelves are used for DC, AC Wye, and AC Delta input
power.
214
Version 2.0b
Module 2
Power Architecture
Power system architecture provides fully redundant AC or DC

power
Line card chassis still operates normally if:

One entire power shelf fails, or one bus bar fails
For system degradation to occur requires two failures:
In both the A and B sides of power architecture that effect the

same load zone
Same architecture used for both AC and DC powered line card
chassis
Three different types of power shelves; DC, AC Wye and AC Delta
Version 2.0b
215
Module 2
Power Distribution
AC or DC power is brought into the chassis through the two power shelves.
The shelves contain the AC rectifier modules or the DC PEMs. The power
architecture is the same for an AC- or a DC-powered chassis. Power is then
distributed in the following way:
The A power (top) shelf then supplies 48 VDC to the A bus bar and the
B power (lower) shelf provides 48 VDC to the B bus bar
The two bus bars distribute power through the midplane to:
16 MSC slots
16 PLIM slots
Eight switch fabric card slots
Two RP slots
Two fan controller card slots
The fan trays receive their operating power from the fan
controller cards
Each of the units that takes its DC power from this power architecture also
has some components that are part of the overall power architecture.
These components are:
OR-ing diodes
Inrush control circuits
EMI filters
These components assist in the dual power source (A and B bus)

architecture and make sure individual units function as online insertion
and removable (OIR or hot-swappable).
Every unit receives power from both the A and B power buses, which
ensures that one entire power shelf could fail and the chassis would still be
fully operational.
216
Version 2.0b
Module 2
Power Distribution
Version 2.0b
217
Module 2
Power Shelf/Load Zones

The line card chassis power architecture distributes power in the chassis
through six load zones. The load zones provide power redundancy and
reliability. The load zone power distribution ensures that each card or
module is powered by one power module in either power shelf. A line card
chassis could lose a single power module or an entire power shelf and the
line card chassis will still have the power to operate. For a load zone to lose
complete power, a power module in each power shelf would have to fail.
Each power module (PEM or AC rectifier) powers two load zones:
218
Power module A0 powers load zones 1 and 2 (Z1 and Z2)
Power module B0 powers load zones 1 and 2 (Z1 and Z2)
The upper fan tray is powered by load zone 2 (A0Z2 and B0Z2)
The lower fan tray is powered by load zone 5 (A2Z5 and B2Z5) through
the fan controller cards
Version 2.0b
Module 2
Power Shelves/Load Zones
A0
A1
Z1 Z2
Z3
A2
Z4
Z5
AM0
Z6
PS0 (Power shelf)

B0
B1
Z1 Z2
Z3
B2
Z4
Z5
AM1
Z6
PS1 (Power shelf)
Version 2.0b
219
Module 2
Line Card Chassis Load Zones

The Line Card Chassis contains six load zones as follows:
220
Load zone 1 (Z1) powers chassis slots 0, 1, 2, and 3
Load zone 2 (Z2) powers chassis slots FC0, RP1 (PLIM side) and SM0,
SM1, SM2 and SM3 (MSC side)
Load zone 5 (Z5) powers chassis slots FC1, RP0 (PLIM side) and SM4,
SM5, SM6 and SM7 (MSC side)
Version 2.0b
Module 2
Line Card Chassis Load Zones
Version 2.0b
221
Module 2
CRS-1 16-Slot Line Card Chassis AC Power Shelves and

Rectifiers
Overview
The Cisco CRS-1 Line Card Chassis has two AC Power Shelves; AC Wye
and an AC Delta that requires basically 220 VAC of input power. Each AC
Power Shelf has three AC Rectifiers. There are two types of AC Power
Shelves:
Wye type AC Wye 3-phase wiring is typically used in Europe and

countries where each phase-to-neutral voltage is approximately 220
VAC
Delta Type AC Delta 3-phase wiring is typically used in the United

States, Japan, and other countries where the phase-to-neutral voltage
is approximately 120 VAC and approximately 208 VAC phase to phase
AC Rectifiers
The AC rectifier is an AC power supply, which converts facility AC power
into the DC power necessary to power the cards and modules in the
chassis. The AC rectifier module takes facility AC power from the AC
power shelf (either the Delta or Wye AC power shelf), rectifies the AC into
DC, provides filtering and control circuit, provides status signaling, and
passes the DC power to either the A or B line card chassis bus bars. Each
AC rectifier module has its own self-contained cooling fan which draws air
through the module.
222
Version 2.0b
Module 2
CRS-1 16-Slot Line Card Chassis AC Power Shelves and Rectifiers
AC Power
Shelf
AC Rectifiers
Version 2.0b
223
Module 2
AC Power Architecture
The 3-phase AC power is brought into the power shelf and distributed to
the three AC rectifiers in the shelf. The AC rectifiers convert the AC power
into the DC power required by the chassis.
_____________________________ Note _________________________
Each phase of the three phase AC power source is used to power two
load zones in the line card chassis.
_________________________________________________________________
The DC power is then routed to bus bars (A and B). The buses distribute
the power through the midplane to the various cards and modules in the
chassis. The top power shelf powers the A bus, and the lower power shelf
powers the B bus. One entire power shelf could fail and the chassis would
still be operational.
_____________________________ Note _________________________
The same AC rectifiers are used in AC Delta power shelves and AC
Wye power shelves.
_________________________________________________________________
224
Version 2.0b
Module 2
AC Power Architecture
Version 2.0b
225
Module 2
AC Rectifier Status Monitoring

The status of each AC rectifier is monitored by a service processor
circuitry, which is located in the power shelf. The service processor
communicates with the system control function. The service processor
circuitry monitors the following AC rectifier fault and alarm conditions:
FaultA signal that summarizes multiple failures in an AC rectifier,

such as failed bias supply, over temperature or current limit. It
includes a warning that the DC output is outside the allowable output
range.
AC Input FailIndicates that the AC input voltage is out of range.
Circuit Breaker TripIndicates that the AC rectifier circuit breaker

has tripped.
Over temperatureIndicates that the AC rectifier has exceeded the

maximum allowable operating temperature.
AC Rectifier PresentIndicates that the AC Rectifier is present and

seated properly in the power shelf.
Voltage and Current Monitor signals (Vmon, Imon)Indicates the

output voltages and currents provided by the AC rectifier are within
range.
Each AC rectifier module contains an ID EEPROM, with AC rectifierspecific information, such as the module part number, serial number,
assembly deviation, special configurations, test history; field-test history,
and field-traceability data that can be accessed by the control software.
226
Version 2.0b
Module 2
AC Rectifier Status Monitoring
The Power Shelf service processor circuitry

monitors the following AC rectifier fault and
alarm conditions:
Fault
AC input fail
Circuit breaker trip
Over temperature
AC rectifier present
Voltage and current monitoring signals
Version 2.0b
227
Module 2
AC Rectifier Status Indicators

The power shelf also provides a visual means of monitoring the condition of
each AC rectifier and provides status signals that indicate the health of the
power supplies.
Each AC rectifier has power and status indicators. Because these
indicators are redundantly powered from the other AC power shelf, they
are operational even when the AC rectifier is not powered from its input
voltage.
228
Version 2.0b
Module 2
Power
OK
Name
Color
PWR OK
Green
The AC rectifier is operating normally with

power
Fault
Yellow
A fault has been detected within the AC

rectifier
AC Input Fail
Yellow
AC input is out of range or is not being

provided to the AC rectifier
Breaker Trip
Yellow
The input circuit breaker is off (in the off

position)
ILIM
Yellow
The AC rectifier is operating in a current

limiting condition
OT
Yellow
The AC rectifier is overheated and it has

been shut down
Fault
AC Input
Fail
CB Trip
ILIM
Function
OT
Version 2.0b
229
Module 2
CRS-1 16-Slot Line Card Chassis DC Power System

Overview
The line card chassis DC power system consumes 13,200 watts maximum
when powering a full chassis. Each DC-powered chassis contains two DC
power shelves for 2N redundancy.
Each DC power shelf houses:
Input power connectors
Its own shelf circuit breaker
Three DC power entry modules (PEMs)
Each PEM is field replaceable
Each PEM has its own circuit breaker
Alarm module
Power distribution connections and wiring
The power shelf is installed in the line card chassis from the front and
plugs into the chassis power interface connector panel.
230
Version 2.0b
Module 2
CRS-1 16-Slot Line Card Chassis DC Power System - Overview
DC power system provides 13,200 watts maximum

Two DC power shelves per chassis provides 2N redundancy
Each DC power shelf houses:
Input power connectors

Its own shelf circuit breaker
Three DC power entry modules (PEMs)
Each PEM is field replaceable
Each PEM has its own circuit breaker
Alarm module
Power distribution connections and wiring
Power shelf installs in chassis from the front and plugs into
chassis power interface connector panel
Version 2.0b
231
Module 2
DC Power Shelf Input Connectors

Each DC power shelf has six input connectors. Each connector consists of
two terminals ( and +). The terminals have a safety cover and there is
strain relief on the power shelf to secure the input power cables.
232
Version 2.0b
Module 2
DC Power Shelf Input Connectors
Grnd
6 Input Connectors
Version 2.0b
233
Module 2
DC Power Shelf Architecture

Each DC power shelf supports three PEMs. Each PEM accepts two 60-A
battery feeds. After some filtering and inrush protection, the PEMs power
the chassis bus bars. One DC power shelf powers the A bus, the other shelf
powers the B bus. The buses distribute the power through the midplane to
the various load zones in the chassis. The load zones distribute power to
the MSCs, PLIMs, switch fabric cards, RPs, fan controllers, and other fieldreplaceable units (cards and modules).
Each card or FRU is powered from both the A and the B power buses. One
entire power shelf could fail and the chassis would still be operational.
The power shelf contains service processor circuitry that provides a means
of monitoring the condition of the each PEM and providing status signals
that indicate the health of the power supplies.
The power for each DC-input power shelf power requires six (6 each) DC
inputs of either nominal 48 VDC or 60 VDC, 60-A service.
234
Version 2.0b
Module 2
DC Power Shelf Architecture
Version 2.0b
235
Module 2
DC PEM
The DC power entry module takes facility DC power from the DC power
shelf, provides some filtering and protection circuitry, and passes the DC
power to either the A or B line card chassis bus bars. Each PEM has two
independent 48 or 60 VDC inputs.
The DC power enters each PEM at the rear of the power shelf through a
connector located on the power shelf midplane. After the power enters the
PEM, internal circuitry provides:
236
Inrush current limiting
EMI filtering
Surge protection
Isolation circuits to process the power before it exits the midplane

connector to the chassis power distribution
Version 2.0b
Module 2
DC PEM
LEDs
Version 2.0b
237
Module 2
DC PEM Status Monitoring

The status of each PEM is monitored by Service Processor circuitry, which
is also located in the power shelf. The service processor communicates with
the system control function. The power shelf service processor circuitry
monitors the following PEM fault and alarm conditions:
FaultSummarizes multiple failures in a PEM, such as failed bias

supply, over temperature or current limit. It includes a warning that
the DC output is outside the allowable output range.
DC Input FailIndicates that the PEM DC input voltage is out of

range.
Circuit Breaker TripIndicates that the PEM circuit breaker has

tripped.
Over temperatureIndicates that the PEM has exceeded the

PEM PresentIndicates that the PEM is present and seated properly

in the power shelf.
Voltage and Current Monitor signals (Vmon, Imon)Indicates the

output voltages and currents provided by the PEM
Each PEM contains an ID EEPROM, with PEM-specific information, such

as the PEM part number, serial number, assembly deviation, special
configurations, test history; field-test history, and field-traceability data
that can be accessed by the control software.
238
Version 2.0b
Module 2
DC PEM Status Monitoring
The Power Shelf service processor circuitry

monitors the following DC PEM fault and alarm
conditions:
Fault
DC input fail
Circuit breaker trip
Over temperature
PEM present
Voltage and current monitoring signals
Version 2.0b
239
Module 2
DC PEM Status Indicators

The power shelf also provides a visual means of monitoring the condition of
each DC PEM and provides status signals that indicate the health of the
PEMs.
Each PEM has power and status indicators. Because these indicators are
redundantly powered from the other DC power shelf, they are operational
even when the PEM is not powered from its input voltage.
240
Version 2.0b
Module 2
Power
OK
Fault
Name
Color
Function
PWR OK
Green
The PEM is operating normally with power
Fault
Yellow
A fault has been detected in the PEM
DC Input
Fail
DC Input Fail
Yellow
DC input is out of range or is not being

provided to the PEM
CB Trip
OT
Yellow
The DC PEM is overheated and it has been

shut down
CB Trip
Yellow
The input circuit breaker is in the off

position
OT
Version 2.0b
241
Module 2
CRS-1 16-Slot Line Card Chassis Alarm Module

Overview
Each AC or DC power shelf contains an alarm module, which monitors the
status of the power shelf and provides an external interface for system
alarms. There is a dedicated alarm module slot on the right side of every
power shelf. The same alarm module is used in all power shelves.
_____________________________ Note _________________________
Only safety extra-low voltage (SELV) circuits can be connected to the
alarm connector. Maximum rating for the alarm circuit is 2 A, 50 VA.
_________________________________________________________________
The Alarm Module is clearly visible, and includes both an alpha numeric
display and 3 LED display. The Alarm module contains a Service Processor
to drive the display and provide control network connectivity.
The Alarm module displays environmental and other hardware alarms and
faults and does not display normal network or software errors. (Example, a
power supply burns out and a minor alarm will be displayed at the alarm
LED display, BUT, if a non-planned feature wipes out the BGP tables this
would not cause ANY alarm to be displayed).
242
Version 2.0b
Module 2
Ext.
Alarm
connector
LED
Indicators
Alpha
Indicators
Version 2.0b
243
Module 2
Alarm Module Functions

The alarm module provides the following:
Alarm outputs, both relay and LEDs:
LEDsThree large LEDs used for signaling the status of the

chassis. The LEDs are designated Major, Minor and Critical: the
supervisory software on the system controller instructs the alarm
module to illuminate these LEDs as required.
AlphaDisplay will show the chassis ID
RelayThe alarm module output function consists of a relay and its

associated driver. As directed by the software on the system
controller (RP or SCFC depending on chassis type) the service
processor module on the alarm module activates the relay.
The alarm relay connector is a standard DA-15S connector
Only safety extra-low voltage (SELV) circuits can be connected to the

connector labeled ALARM on the alarm module faceplate
244
The maximum rating for the alarm circuit is 2A, 50V
PEM or AC Rectifier status monitoring
Alarm monitoring
Version 2.0b
Module 2
Alarm Module Functions
The alarm module performs the following

functions:
Alarm outputs for both LEDs and relay
LEDs
Alpha
Relay
Alarm Relay connector is DA-15S
Only SELV circuits connect to Alarm Module

PEM or AC Rectifier Status Monitoring
Alarm monitoring
Version 2.0b
245
Module 2
Status Monitoring
The alarm module is responsible for monitoring the performance of the AC
rectifiers or DC PEMs plugged into the power shelf that it shares.
The monitored parameters include:
Circuit Breaker Tripped conditions
Power Good
Power Fail
Internal Fault
Over Temp conditions
AC rectifier or PEM presence
Voltage and current output levels
Since it has a backup power connection to the neighboring power shelf, the
alarm module is capable of reporting the status of an unpowered shelf.
246
Version 2.0b
Module 2
Status Monitoring
Alarm module responsible for monitoring AC rectifiers or

DC PEMs plugged into the power shelf it shares
The monitored parameters include:
Circuit Breaker Tripped conditions

Power Good
Power Fail
Internal Fault
Over Temp conditions
AC rectifier or PEM presence
Voltage and current output levels
Has a backup power connection to the neighboring

power shelf
Version 2.0b
247
Module 2
CRS-1 16-Slot Chassis Line Card Chassis Cooling System

Overview
The line card chassis cooling system includes the components and control
system that draw ambient air through the system to dissipate heat and
keep the system operating in a desired temperature range. The complete
line card chassis cooling system includes:
248
Two fan trays
Two fan controller cards
Temperature sensors distributed on cards and modules in the chassis
The operating software that controls the cooling system
An air filter
Inlet and outlet air vents and bezels
Impedance carriers for empty chassis slots
Power module cooling fans
Version 2.0b
Module 2
CRS-1 16-Slot Chassis Line card Chassis cooling System - Overview
The complete line card chassis cooling system

includes:
Two fan trays

Temperature sensors distributed on cards and modules
in the chassis
The operating software that controls the cooling system

An air filter
Inlet and outlet air vents and bezels
Power module cooling fans
Version 2.0b
249
Module 2
Line Card Chassis Airflow

The airflow through the line card chassis is controlled by a push-pull
configuration. Ambient air flows in at the bottom front of the line card
chassis and up through the card cages until it exhausts at the top rear. The
bottom fan tray pulls ambient air in from the bottom front of the chassis;
the top fan tray pushes warm air out the back of the chassis. The AC
Rectifiers or DC PEMs in the power shelves have their own self-contained
cooling fans.
Air Filter
The chassis has a serviceable air filter mounted in a slide-out tray

accessible from the rear of the chassis just above the lower fan tray and
plugs into plugs into the rear (or MSC side) of the chassis.
How often the air filter should be replaced depends on the facility
environment. In a dirty environment, or when you start getting frequent
temperature alarms, you should always check the intake grills for debris,
and then check the air filter to see if it needs replacing.
250
Version 2.0b
Module 2
Version 2.0b
251
Module 2
Fan Control Architecture

The main feature of the line card chassis cooling system is a fully
redundant fan control architecture designed to run with both fan trays in
place. The fan control architecture:
Systematically controls the speed of the fans to optimize cooling,

acoustics, and power consumption for various chassis-heating
conditions
Monitors the cooling system with temperature sensors on modules and

cards
Is redundant from both a power and cooling standpoint
Supports a redundant load-sharing design that contains:
Two fan trays, each containing nine fans
Control software and logic
There are four normal operating fan-speeds, plus one high-speed setting
used when a fan tray has failed.
252
Version 2.0b
Module 2
Fan Control Architecture
The fan control architecture:
Controls fan speed to optimize cooling, acoustics, and power

consumption for various chassis-heating conditions
Monitors the cooling system with temperature sensors on

modules and cards
Is redundant from both a power and cooling standpoint

Supports a redundant load-sharing design that contains:
Two fan trays, each containing nine fans

There are four normal operating fan-speeds, plus one high-speed

setting used when a fan tray has failed.
Version 2.0b
253
Module 2
Line Card Chassis Fan Tray

The line card chassis fan tray operates in either the upper or lower fan
tray slots. Each fan tray is hot-swappable and is a field-replaceable unit
that plugs into the rear (or MSC side) of the chassis.
Each fan tray contains:
254
Nine fansEach multi-speed fan can be speed-controlled by varying

the nominal +24 DC voltage under software control. The fans operate in
the range of 4000 to 6700 RPM. Though each fan is controlled by
separate DC voltages, the control software treats all nine fans as a
group. So, when it is necessary to increase or decrease the airflow, all
nine fans in a tray increase or decrease their rotation speed together.
When two fan trays are operational in a chassis, the speed of the fans
in both trays is adjusted together.
A fan tray boardThe board terminates signals to and from the fans,
filters common mode noise, and houses tracking and indicator parts.
A front-panel status LEDThe LED indicates the following:
GreenThe fan tray is operating normally
YellowThe fan tray has experienced a failure and should be

replaced
OffAn unknown state exists or the LED is faulty
Version 2.0b
Module 2
Line Card Chassis Fan Tray
Status
LED
Statu s
The two fan trays:
Are interchangeable
Plug into the rear of LC chassis
Each line card chassis fan tray contains:
Nine fans
A front-panel status LED
Version 2.0b
255
Module 2
Line Card Chassis Fan Controller Card

There are two line card chassis fan controller (LCFC) cards in every line
card chassis that provide the following functions:
256
Conversion of 48 VDC from the midplane to the DC voltages necessary

to operate the fans.
A Service Processor (SP) module that functions as part of the system

control and communicates with the system controller function on the
RPs.
Inlet temperature and thermal alarms communicated to the fan

controller SP module from the system controller on the RP.
Individual fan tachometer monitoring signals from the fan tray.
A status LED (good/bad) for each fan tray.
Hot-swappable online insertion and removal (OIR) logic.
BITS/SETS RJ-45 external clock (Ext.) connectors and logic for

network/SONET clock synchronization.
Version 2.0b
Module 2
Line Card Chassis Fan Controller Card
BITs/SETs
Ext. Clk 1
BITs/SETs
Ext. Clk 2
Status
LEDs
Version 2.0b
257
Module 2
Fan Controller Card Operation

At initial power up, the control software powers on the fan trays at 4300 to
4500 RPM to provide adequate cooling in case the software hangs during
booting. This ensures there is airflow while each line card chassis powers
up, initializes, and boots the system software.
The fan control software is not initialized until after the system software is
booted, which could take 3 to 5 minutes. After system software is booted
and the fan control software is initiated, fan speeds are adjusted
appropriately.
The fan controller cards and fan trays have a quick-shutdown mode that
kills power when a card or fan tray is disengaged from the chassis
midplane. The quick-shutdown mode minimizes inrush current during a
hot swap or OIR. In normal maintenance conditions, the software
gracefully shut downs the power to the failed part, allowing ample time for
capacitors to discharge.
258
Version 2.0b
Module 2
Fan Controller Card Operation
Fans run at 4300 to 4500 RPM at initial power up

Fan control software takes control of fan speed once
the system is initialized (could take 3 to 5 minutes)
Fan controller cards and fan trays have quickshutdown mode to aide in OIR
Quick-shutdown mode minimizes inrush current

during hot swap or OIR
Version 2.0b
259
Module 2
Cooling System Redundancy

The redundancy design in the cooling subsystem can tolerate:
A single fan tray failure
A single fan failure
A single fan controller board failure
A single fan cable failure
A single power shelf, or a single power module (PEM or AC rectifier) to

fail without impacting routing system or line card chassis availability
The design accounts only for single faults, if a double fault occurs then the
system remains powered on, unless the double fault is both fan trays
failing or the thermal alarms indicate a problem serious enough to power
down the system.
When a single fan controller card fails, the partner fan controller card
provides all power to each fan or fan tray. In this mode the maximum
voltage that can be provided is 24 volts for a line card chassis.
260
Version 2.0b
Module 2
The redundancy design in the cooling

subsystem can tolerate:
A single fan tray failure

A single fan failure
A single fan controller board failure
A single fan cable failure
A single power shelf, or a single power module
(PEM or AC rectifier) to fail without impacting
routing system or line card chassis availability
Version 2.0b
261
Module 2
Thermal Sensors
Thermal sensors placed on each individual board in the system are used to
monitor temperatures throughout the chassis. There are three types of
sensors in the chassis:
Inlet
Exhaust
Hot spot
Any of the three types of the sensors can send a thermal alarm. When a
thermal alarm occurs in the system, the fault condition is passed to the
service processor (SP) of each fan controller board and the control software
takes appropriate action to resolve the fault.
262
Version 2.0b
Module 2
Thermal Sensors
Thermal sensors on each board in system

monitor temperatures throughout chassis
Three types of sensors in the chassis:
Inlet
Exhaust
Hot spot
Any sensor can send a thermal alarm

When thermal alarm occurs fault condition
passed to SP on each fan controller board for
control software to takes appropriate action
Version 2.0b
263
Module 2
Fan Control Redundant Power

The two fan controller cards work together to provide a fully redundant
cooling architecture. Each fan controller card receives 48 VDC from
individual load zones on the midplane. Each load zone gets DC power from
both the A and B power shelves. This ensures that each fan controller card
has nine fans (upper fan tray) powered and controlled from the A bus and
the other nine fans (lower fan tray) powered and controlled from the B
bus. To ensure redundancy, the midplane swaps the load zone power buses
to ensure that, between fan controller cards, the upper fan tray is powered
from the A bus on one fan controller card and from the B bus on the
second fan controller card.
The control software and circuitry vary the DC input voltage to the
individual fans to control their rotation. Two DC-to-DC converters, one on
each fan controller card, control a single fan. This provides redundancy,
and the proper input power to the fan.
264
Version 2.0b
Module 2
Fan Control Redundant Power
Each fan controller card receives 48 VDC from

individual load zones on midplane
Each load zone gets DC power from both the A

and B power shelves.
Upper fan tray powered from A bus on one fan

controller card and from B bus on second fan
controller card
Two DC-to-DC converters, one on each fan

controller card, control a single fan
Version 2.0b
265
Module 2
CRS-1 16-Slot Chassis Single Line Card Switch Fabric

Overview
The single-chassis routing system comprises one16-slot line card chassis
with a self-contained switch fabric. In this configuration, there are eight
S123 switch fabric cards contained in the switch fabric card slots of the line
card chassis.
Shown on the opposite page is a simple block diagram of a Cisco CRS-1
Series single-chassis routing system and its switch fabric. In this system,
there are eight S123 switch fabric cards. Each card consists of all three
stages (S1, S2, and S3) of the three-stage Benes switch fabric, and each
card comprises one entire plane of the eight planes of the total switch
fabric.
There can be up to 16 modular services cards (MSCs) in one line card
chassis. In a single-chassis Cisco CRS-1 Series routing system, each MSC
slot has a bandwidth of 40 Gbps ingress and 40 Gbps egress, so 16 x 80 =
1280 gigabits (or 1.2 terabits) of switching capacity.
Each MSC distributes data cells to each switch fabric plane. Each MSC
also has multiple connections per switch fabric plane.
Like all Cisco CRS-1 Series routing systems, the single-chassis system
switch fabric is a cell switch based on buffered three-stage Benes switch
fabric architecture. Stage 1 (S1 switch element components) distributes
traffic across all S2 switch elements. Stage 2 (S2 switch elements)
performs the switching and provides 2x speedup. Stage 3 (S3 switch
elements) also performs the switching and 2x speedup of the cells.
There are a total of eight fabric planes per line card chassis. Each S123
switch fabric card represents one plane. The S123 switch fabric cards plug
into the rear of the line card chassis.
The S123 switch fabric card is used only in the single-chassis system. The
card is configured during the fabric initialization and configuration
sequence via the Cisco IOS-XR fabric management software.
266
Version 2.0b
Module 2
CRS-1 16-Slot Chassis Single Line Card Switch Fabric
CRS-1 16-Slot Chassis Single Chassis System Switch Fabric
Linecard Chassis
Egress
Ingress
PLIM
MSC
MSC
IP Data
PLIM
IP Data
S1
S2
S3
S1
S2
S3
1 of 8
Switch Fabric Card
Version 2.0b
267
Module 2
CRS-1 16-Slot Chassis S123 Switch Fabric Card

Overview
The S123 switch fabric card (CRS-16-FC/S) is used only in single-chassis
systems. The card does not contain any fiber-optic connectors because it is
not connected to any other switch fabric modules.
The major components of the S123 switch fabric card are the switch
elements that perform the switching functions, a service processor, power
modules, a status LED, and an alphanumeric display.
The S1, S2, and S3 elements perform the switching functions and are
programmed at system startup by IOS XR fabric management software to
perform the various S1, S2, or S3 switching functions.
Each S123 switch fabric card contains two S1, two S2, and four S3
elements.
268
Version 2.0b
Module 2
S123 switch fabric card only used in single-chassis systems

Major components of S123 switch fabric card are:
Switch elements that perform switching functions

Service processor
Power modules
Status LED
Alphanumeric display
S1, S2, and S3 elements perform switching functions and are

programmed at system startup by IOS XR fabric management
software
Each S123 switch fabric card contains two S1, two S2, and four S3
elements.
Version 2.0b
269
Module 2
S123 Functional Blocks

The functional blocks of the S123 switch fabric card are:
1. S1 switch elementReceives data cells from the MSC (or from an RP)
and distributes them to the S2 stage. The S1 switch element is
connected to every S2 switch element on that S123 switch fabric card.
2. S2 switch elementReceives data cells from the S1 stage and performs
switching and fabric speedup. The S2 switch element is connected to
every S3 switch element on that S123 switch fabric card.
3. S3 switch elementReceives data cells from the S2 stage and performs
switching and fabric speedup.
4. Service processorProvides the interface to the Cisco CRS-1 Series
routing system control plane. The service processor performs:
Power up and down of the fabric card
Switch element component initialization and configuration
FGID (Fabric Group ID) update, for multicast function
Maintenance cell configuration
Link up and down control and status
Statistic collection and processing
5. Power modulesTake 48 VDC input power from the midplane and

converts it into the voltages required by the switch fabric cards
components.
6. Alphanumeric displayDisplays S123 switch fabric card messages.
This display is under software control.
7. Status LEDIndicates status of the S123 switch fabric card. Green
indicates module OK.
270
Version 2.0b
Module 2
S123 Functional Blocks
Slots 0-7
Egress
Ingress
from
MSCs
To
MSCs and
RPS
Slots 8-17
(To fabric)
(From
Fabric)
4
Note: Slots 16 & 17 are the active and standby RPs
Version 2.0b
271
Module 2
S123 Physical Overview

The switch fabric (S123) card is used only in single-chassis systems. The
S123 card does not contain any fiber-optic connectors because it is not
connected to any other switch fabric modules.
The S123 switch fabric card front panel contains:
272
A board OK LED
An alphanumeric display
Version 2.0b
Module 2
S123 Physical Overview
Alpha
Status
LED
Version 2.0b
273
Module 2
CRS-1 16-Slot Chassis Route Processor (RP)

Overview
The route processor (RP) card combines system controller (SC)
functionality with route processing capability. The system controller
function implements many of the control plane operations for the Cisco
CRS-1 Series routing system.
Each 16-Slot Line Card Chassis contains two route processor (RP) cards
that:
274
One RP serves as the active master, while the other serves as the
standby unit
RPs are located in dedicated slots on the front side of the chassis in the
center of the lower PLIM card cage
Distribute forwarding tables to the line cards
Provide a control path to each MSC
Provide the system-monitoring functions
Contain the hard disks for system and error logging
Version 2.0b
Module 2
CRS-1 16-Slot Chassis Route Processor (RP) Overview
The RP combines system controller functionality with

route processing capability
Each 16-Slot Line Card Chassis contains two route
processor (RP) cards that:
One RP serves as the active master, while the other
serves as the standby unit
Are located in dedicated slots the front side of the
chassis in the center of the lower PLIM card cage

Distribute forwarding tables to the line cards
Provide a control path to each MSC
Provide the system-monitoring functions
Contain the hard disks for system and error logging
Version 2.0b
275
Module 2
RP Front Panel
Every line card chassis contains two route processor cards in
dedicated|redundant slots on the PLIM side of the chassis.
The RP front panel includes:
An IDE disk slot
A PCMCIA flash disk slot
Two small form-factor pluggable (SFP) modules for external Gigabit

Ethernet (GE) connections
A GE copper port
Two RJ45 serial Console and AUX ports
An alphanumeric LED display
A status OK LED
An Active/Standby LED
Route Processor (RP) Memory Options

The RP can be configured with 2 or 4 GB of memory.
Processor Module (CPU0)

Dual Symmetrical Multiprocessor
276
Version 2.0b
Module 2
CRS-1 16-Slot Chassis RP Front Panel and Memory Options
SMP
CPUs
Memory
Modules
Version 2.0b
277
Module 2
Hard Drive
The RP hard drive is an IDE hard disk used for gathering debug
information, such as core dumps from the RP or MSCs. The IDE hard disk
is typically powered down and activated only when there is a need to store
data. The disk is not vital to a functioning line card chassis and is optional.
_____________________________ Note _________________________
Core dumps are discovered only through intervention with the line card
chassis system software.
_________________________________________________________________
Physically, the RP hard drive is a hot-pluggable PC board and sledmounted drive with a connector interface that gets cleanly seated into a
route processor card. In general, removal and replacement of this drive is
not required.
278
Version 2.0b
Module 2
Hard Drive
RP IDE hard drive:
Used for storing debug info,

such as, core dumps from RP
or MSCs
Typically only active when

needed
Hot-pluggable and sled

mounted
Version 2.0b
279
Module 2
PCMCIA Flash Slots

The RP card provides two ATA type PCMCIA flash slots that provide up to
1 GB of flash storage each. One of the PCMCIA flash subsystems is
accessible externally and removable, and allows you to transfer images and
configurations by plugging in a PCMCIA flash card. The other subsystem
is fixed to the RP and is not removable, and is for permanent storage of
configurations and images and is required for operation of the OS.
280
Version 2.0b
Module 2
PCMCIA Flash Slots
PCMCIA Flash
Each RP provides two ATA type

PCMCIA flash slots to store up to
1 GB storage systems
Disk0: is fixed and used for

permanent storage of
configuration and image files
required for operation of OS
Disk1: is an externally accessible

media slot
Version 2.0b
281
Module 2
Block Diagram
On the oppose page is a simple block diagram of an RP. In this drawing,
the dotted lines indicate distinct RP modules, such as the CPU and
memory controller (MEM CTL), and the To fabric and From fabric
modules.
The main components of the route processor card are:
1. A dual-CPU symmetric multiprocessor (SMP) set for processing. Among
other tasks, the CPU subsystem performs the function of the service
processor (SP) in the MSC and monitors the RPs temperature,
voltages, margining of the power supplies during factory test, and ID
EEPROM.
2. Two small form-factor pluggable (SFP) modules for external Gigabit
Ethernet (GE) connections. These modules connect to two external GE
switches that interconnect all line card and fabric chassis together to
form a control network. The GE switches are not used in a singlechassis CRS-1 routing system.
3. A third Ethernet port for 10/100/1000 Ethernet copper connectivity to
network management systems.
4. Internal Fast Ethernet (FE) midplane connections. Each line MSC in a
chassis connects to both RPs via an internal 100 Mbps FE connection.
The FE connections are traces in the midplane. There are also FE
connections to the fans, blowers, and power supplies. These connections
all form part of the control plane.
5. An IDE hard disk used for gathering debugging information, such as
core dumps from the RP or MSCs. The IDE hard disk does not contain
user data of any kind. The disk is typically powered down and activated
only when there is a need to store data. The IDE hard disk is not vital
to the functioning of the routing system and is user-removable.
6. Two ATA type PCMCIA flash slots for 1 GB of flash storage. One of the
PCMCIA flash subsystems is accessible externally and allows you to
transfer images and configurations by plugging in a PCMCIA flash
card. The other subsystem is fixed to the RP and is for permanent
storage of configurations and images. The RP comes standard with one
PCMCIA 1 GB flash.
282
Version 2.0b
Module 2
Block Diagram
LC FE
links
CTL GE link
FE/GE
switch
CTL GE link
PCI
9
Q
links
To
fabric
From
fabric
CPU
MEM
IF
CTL
CPU
IDE
PCMCIA
2
8
Aux and console
Management GE link
FPGA
Midplane
Card presence detect

RP mastership
PROM presence
10
Version 2.0b
283
Module 2
7. The RP mates with the line card chassis midplane. Through the
midplane, the RP has connections to the routing system switch fabric.
To connect through the switch fabric, the RP has fabric interfaces
(From fabric and To fabric) similar to the one used on the MSC.
8. The From fabric module is part of the receive path of the RP. The
From fabric module queues the data from the switch fabric. It also
reorders and reassembles the cells into packets before queuing them for
slow path processing.
9. The To fabric module is part of the transmit path on the RP. The To
fabric module queues the packets and segments them into cells before
transmitting them to the switch fabric.
10. The Field Programmable Gate Array (FPGA) handles system control
register functions, such as; identifying which PLIMs are installed, RP
mastership signals, card present signals, card reset signals to cards
with service processors. In addition, the FPGA handles the front panel
alphanumeric display, the Active LED and the OK LED.
284
Version 2.0b
Module 2
Block Diagram (Cont.)
LC FE
links
CTL GE link
FE/GE
switch
CTL GE link
PCI
9
Q
links
To
fabric
From
fabric
CPU
MEM
IF
CTL
CPU
IDE
PCMCIA
2
8
Aux and console
Management GE link
FPGA
Midplane

RP mastership
PROM presence
10
Version 2.0b
285
Module 2
Route Processor (RP) Active and Standby Arbitration

The two RPs in a line card chassis operate in an active-standby
relationship. The active-standby arbitration algorithm is performed by
hardware and software. The arbitration algorithm goes through these
steps:
1. At chassis power up, each RP boots its board components and runs selftests.
2. Each RP exchanges messages with the other RP and with the service
processors (SPs) on all other boards on the midplane. Each RP
examines its outgoing Reset lines to verify that they are inactive.
3. Based on the results of these tests, each RP decides whether it is ready
to become shelf (that is, chassis) master that is the active RP. If it is, it
asserts the Ready signal to its on-board arbitration unit. The
arbitration unit propagates the Ready signal to the other RP.
4. The arbitration hardware chooses the active RP from the RPs that has
asserted Ready. The hardware asserts an Active signal to the
chosen RP, along with an interrupt and propagates the Active signal
to the other RP, which also receives an interrupt. In the case of a tie,
the Active will be the RP in the lower numbered slot.
5. Software on each reads its Active signal, and branches accordingly to
Primary or Standby code.
6. In case the active RP is removed, powered down, or voluntarily deasserts its Ready signal, the standby RP immediately receives an
asserted Active signal, along with an interrupt.
286
Version 2.0b
Module 2
The active-standby arbitration algorithm performed by hardware and

software:
1. At chassis power up, each RP boots and runs self-tests.

2. The RPs exchange messages with each other and with SPs on all other
boards. Each RP examines its outgoing Reset lines to verify that they
are inactive.
3. Based on results of these tests, each RP decides whether it is ready to
become the active RP. If it is, it asserts Ready signal to its on-board
arbitration unit that propagates Ready signal to other RP.
4. Arbitration hardware chooses active RP. Hardware asserts Active
signal to chosen RP, along with an interrupt and propagates Active
signal to other RP, which also receives an interrupt. If a tie, Active is RP
in lower numbered slot.

6. If active RP is removed, powered down, or voluntarily de-asserts its
Ready signal, standby RP immediately receives an asserted Active
signal, along with an interrupt.
Version 2.0b
287
Module 2
Summary
288
To list and describe the hardware features and functions of the CRS-1
16-slot line card chassis
To list and describe the features and functions of the FRUs and
To list and describe the features and functions of the CRS-1 16-slot line
card chassis alarm modules
card chassis Switch Fabric
Version 2.0b
Module 3
Overview
Description
This module describes the CRS-1 8-slot line card chassis hardware features
and functions including the Field Replaceable Units (FRUs), and
components that comprise a single line card chassis system.
Objectives
List and describe the hardware features and functions of the CRS-1 8slot line card chassis
List and describe the features and functions of the FRUs and
Version 2.0b
31
Module 3

Overview
The Cisco CRS-1 8-Slot Line Card Chassis is the mechanical enclosure that
contains the system components. The chassis is installed in an external
rack that is bolted to the facility floor, and has locking front doors and
optional rear doors.
Mid-plane Design
The Cisco CRS-1 8-slot chassis is a mid-plane design that is fashioned after
the Cisco CRS-1 16-slot chassis.
Front
The front side of the chassis is also referred to as the Physical Layer
Interface Module (PLIM) side. It has eight PLIM slots and 2 Route
Processor (RP) slots. The lower section of the houses two DC Power Entry
Modules (PEMs) or two AC power rectifiers.
Back
The back side of the chassis is also referred to as the Multi-Services Card
(MSC) side. It has eight MSC slots and 4 Switch Fabric Card (SFC) slots.
The lower section of the houses two Power Distribution Units (PDUs) that
in turn contain either DC PEMs or AC power rectifiers.
Dimensions
The physical dimensions of the chassis are:
17.5 W x 36.6 D x 38.5 H

Or
32
44.5 W x 93 D x 97.8 H cm
Power: 7.5 KW DC or 8.75 KW AC
Weight ~ 600 lbs or 275kg
Heat Disappation: 27,350 BTUs
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Overview
Midplane design:
Front
8 PLIM slots
2 RP slots
Back
8 MSC Slots
4 Fabric cards
Dimensions:
17.5 W x 36.6 D x 38.5 H
(44.5 W x 93 D x 97.8 H cm)
Power: 7.5 KW DC,
8.75 KW AC
Weight: ~ 600 lbs/275kg
Heat Dis.: 27,350 BTU
Rack mountable
Version 2.0b
33
Module 3

This section lists the main components of a line card chassis. It primarily
identifies the components that are considered field-replaceable units
(FRUs), but where additional detail is useful identifies subassemblies that
are not field-replaceable.
Midplane
The chassis also contains a midplane that connects MSCs to their
associated PLIMs. The midplane design allows an MSC to be removed from
the chassis without having to disconnect the cables that are attached to the
associated PLIM. The midplane distributes power, connects the MSCs to
the switch fabric cards, and provides control plane interconnections. The
midplane is not field-replaceable by the customer.
PLIM Side
The PLIM side of the chassis is considered the front of the chassisthis is
where user data cables attach to the PLIMs and where cool air enters the
chassis. The PLIM side of the Cisco CRS-1 8-Slot Line Card Chassis
contains:
1. Cable management system
2. Two route processor (RP) cards. The RP cards provide the intelligence
of the system by functioning as the system controller and by providing
route processing. Only one RP card is active at a time, the other
standby RP card is a backup in case the active RP card fails. The RP
card also monitors system alarms and controls the system fans. LEDS
on the front panel indicate active alarm conditions.
3. PLIMs
4. Air Filter
5. Two AC rectifier modules or two DC power entry modules (PEMs), one
for each power distribution unit (PDU). Each PDU supplies input
power to a rectifier or PEM, which in turn provides processed power to
the chassis.
34
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Components - PLIM Side
Version 2.0b
35
Module 3
MSC Side
The MSC side of the chassis is considered the rear of the chassisthis is
where warm air is exhausted.
The components located on the MSC side of the chassis are:
1. Upper fan tray.
2. Four half-height switch fabric cards (S123). These cards provide the
three-stage Benes switch fabric (S1/S2/S3) for the routing system. The
switch fabric performs the cross-connect function of the routing system,
connecting every MSC (and its associated PLIM) with every other MSC
(and associated PLIM) in the system. The switch fabric receives user
data from one MSC and PLIM pair and performs the switching
necessary to route the data to the appropriate egress MSC and PLIM
pair. The switch fabric is divided into eight planes that evenly
distribute the traffic across the switch fabric. Each switch fabric card
implements two planes of the switch fabric.
3. Up to eight modular services cards (MSCs, also called line cards)
provides the forwarding engine for Layer 3 routing of user data and
connects through the mid-plane to the PLIM that provides the physical
interface and connectors for the user data. There is one type of MSC,
but it can be associated with several different PLIMs, which provide
different interface speeds and technologies.
4. Lower fan tray.
5. The power system consists of two AC or DC power distribution units
(PDUs), and two AC rectifier modules or two DC power entry modules
(PEMs), one for each PDU. Each PDU supplies input power to a
rectifier or PEM, which in turn provides processed power to the chassis.
36
Version 2.0b
CRS-1 Essentials
Module 3
MSC Side
Version 2.0b
37
Module 3
Cable Management
The Cisco CRS-1 8-Slot Line Card Chassis arrives with a pre-installed
horizontal cable-management bracket on the front of the chassis. In a
single-chassis system, the following ports are for external cable
connections:
CONSOLE or AUX RJ-45 RS-232 serial ports on the route processor

cards for terminal connections
Ethernet ports on the route processor cards for connecting network

management equipment
Physical layer interface modules (PLIMs) for data connections
RJ-45 external clock (EXT CLK 1 and EXT CLK 2) connectors for the
Building Integrated Timing Source (BITS) signaling cables from the RP
The cable-management bracket is for organizing these interface cables to

keep the front of the chassis clear and to eliminate sharp bends in the
cables.
The cable-management bracket has a special telescoping feature that
allows the bracket to be extended when the chassis is upgraded with
higher-density cards. This extension feature also helps in installing the
cables in the chassis.
38
Version 2.0b
CRS-1 Essentials
Module 3
Cable Management
Cable-management bracket has telescoping feature

that allows bracket to be extended when chassis is
upgraded with higher-density cards.
Version 2.0b
39
Module 3

PLIM Side
The slot numbers on the PLIM side of the chassis include:
Up to eight PLIM slots (left to right, 0, 1, 2, 3, 4, 5, 6, 7)
Two route processor card slots, RP0 and RP1
MSC Side
The slot numbers on the MSC side of the chassis include:
Eight MSC line card slots numbered from right to left (0, 1, 2, 3, 4, 5, 6,
7)
Four S123 switch fabric card slots (SM 0, SM 1, SM 2, and SM 3)
The MSC (rear) slot numbers are reversed from the PLIM (front) slot
numbers. Therefore the MSC in slot 0 and PLIM in slot 0 mate with one
another through the midplane, and so do all the other MSC and PLIM slots
(0 through 7).
310
Version 2.0b
CRS-1 Essentials
Module 3
Front
Rear
Version 2.0b
311
Module 3

Overview
The Cisco CRS-1 8-Slot Line Card Chassis can be powered by either AC or
DC power. The chassis power system takes the facility power and converts
it to the DC voltage necessary to power system components. Both AC and
DC power systems are fully redundant and contain the following
components:
Two (redundant) AC or DC power distribution units (PDUs) for each

system
One AC rectifier or one DC power entry module (PEM) for each PDU
Different PDUs are used for DC, AC Wye, and AC Delta input power.
312
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Power System Overview
The CRS-1 8-slot can be powered by either AC

or DC power
Power is fully redundant

Has two AC or DC power distribution units
(PDUs)
One AC rectifier or one DC PEM per PDU

Different PDUs are used for DC, AC Wye or AC
Delta input power
Version 2.0b
313
Module 3
Power Architecture
AC and DC power systems use A and B power supplies to provide reliable,
2N redundant power to all chassis components.
AC or DC input power enters the chassis through the two A or B power
supplies and is distributed to the A or B power bus. Both buses distribute
power through the midplane to the MSC, PLIM, switch fabric, and RP card
slots.
The A power supply supplies 48 VDC to the A bus
The B power supply supplies 48 VDC to the B bus
Because chassis components are powered by both A and B power inputs,

the line card chassis can continue to operate normally if:
One input power (A or B) fails
One bus fails
It takes two failures for the system to be degraded. In addition, the failures
must occur in both the A and B sides of the power architecture and affect
the same load zone for the degradation to occur.
Individual chassis components have power-related devices (OR-ing diodes,
inrush control circuits, and EMI filters) that are part of the chassis power
architecture. These power-related devices form part of the dual power
source (A and B bus) architecture, and enable online insertion and removal
(OIR) of the component, also called hot swapping.
314
Version 2.0b
CRS-1 Essentials
Module 3
Power Architecture
Version 2.0b
315
Module 3
Chassis Load Zones

The AC power system distributes power in the chassis through three load
zones, which provide power redundancy and reliability. Each load zone
receives power from both PDUs, which ensures that each zone can operate
in case of PDU failure.
Power Zone Assignments

Zone Number
Front (PLIM Side)
Rear (MSC Side)
Zone 1
Slot 0, 1, 2
Slot 0, 1, 2, Fan 1
Zone 2
Slot 3, 4, RP 0, RP 1
Slot 3, 4, SF 0, 1, 2, 3
Zone 3
Slot 5, 6, 7
Slot 5, 6, 7, Fan 0
316
Version 2.0b
CRS-1 Essentials
Module 3
Chassis Load Zones
Version 2.0b
317
Module 3
CRS-1 8-Slot AC Power System

Overview
The AC power system provides 7.5 kW (Delta or Wye 3-phase) to power the
line card chassis. The AC power system, which provides 2N power
redundancy for the routing system (two independent Delta or Wye 3-phase
power sources required), contains the following components:
__________________________________ CAUTION ______________________________
Use two PDUs of the same type (Delta or Wye) in the Cisco CRS1 8-Slot Line Card Chassis.
_________________________________________________________________________
Two AC PDUsContain the input AC power connectors, EMI filters,

and output connectors mating with AC rectifiers. The PDUs are
available in either AC Delta or AC Wye configurations. Each PDU
supports one AC rectifier that:
318
Convert 200- to 240-VAC input power to 54.5 VDC used by the line
card chassis. Each AC rectifier is field-replaceable.
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot AC Power System - Overview
Provides:
7.5 kW (Delta or Wye 3-phase) of power to

chassis
Two AC PDUstwo independent AC power

sources required
Two AC RectifiersConverts 200- to- 240 VAC to

54.5 VDC
Each rectifier has:
its own circuit breaker

cooling fan
Version 2.0b
319
Module 3
Power Redundancy
The AC power system provides 2N redundancy through the use of two AC
Delta or Wye PDUs that are connected to two independent 3-phase power
sources. Two types of PDUs:
AC Input, Delta 3-phase
3W+PE (3 wire plus protective earthing)
Input voltage3-phase 200-240 VAC (nominal) range 170 to 264

VAC, phase-to-phase
Line frequency50 to 60 Hz, range 47 to 63Hz
Recommended AC service30 A (plugs into L15-30R receptacle)
AC Input, Wye 3-phase
3W+N+PE (3 wire plus neutral plus protective earthing)
Input voltage3-phase 200-240 VAC (nominal)
Range 170 to 264 VAC, phase-to-neutral

Range 295 to 457 VAC, phase-to-phase
Recommended AC service:
20 A North America (plugs into IEC 60309 receptacle)

16 A International
320
Version 2.0b
CRS-1 Essentials
Module 3
Power Redundancy
AC Input, Delta 3-phase
3W+PE (3 wire plus protective earthing)

Input voltage3-phase 200-240 VAC (nominal) range 170 to 264 VAC,
phase-to-phase
Recommended AC service30 A (plugs into L15-30R receptacle)
AC Input, Wye 3-phase
3W+N+PE (3 wire plus neutral plus protective earthing)

Input voltage3-phase 200-240 VAC (nominal)
Range 170 to 264 VAC, phase-to-neutral

Range 295 to 457 VAC, phase-to-phase
20 A North America (plugs into IEC 60309 receptacle)

16 A International
Version 2.0b
321
Module 3
AC PDU & Rectifier

There two type of AC PDU, Delta and Wye. Each PDU will house a single
AC rectifier.
The rectifier takes AC input power from the PDU, rectifies the AC into DC,
provides filtering and control circuitry, provides status signaling, and
passes the regulated and isolated DC power to the chassis midplane. Each
AC rectifier has self-contained cooling fans that draw air through the
module.
The yellow power switch is on the front top left corner of the rectifier. The
switch can be pushed or pulled to turn the power on or off, respectively.
After the power enters the AC rectifier, internal circuits rectify the AC into
DC, filter and regulate it. The conversion from AC to DC is done in two
stages. The first stage is for power factor correction (PFC). The PFC
process converts the AC to regulated primary DC. The PFC maintains the
AC input current to be sinusoidal and in-phase with the AC input. The
result is near unity power factor. The second stage is DC-to-DC conversion.
The DC-to-DC process converts regulated primary side DC power to
isolated 54.5 VDC secondary power.
322
Version 2.0b
CRS-1 Essentials
Module 3
AC PDU & Rectifier
CRS-8-LCC-PDU-ACD
AC Delta PDU
CRS-8-LCC-PDU-ACW
AC WYE PDU
CRS-8-AC-RECT
AC rectifier module
2 required for chassis 1 per PDU
Version 2.0b
323
Module 3

A microprocessor in the AC rectifier monitors the status of each AC
rectifier. The microprocessor communicates with the system controller on
the route processor (RP) card. The microprocessor circuitry monitors the
following AC rectifier fault and alarm conditions:
FaultIndicates a failure in an AC rectifier, such as failed bias supply,

over temperature or current limit. It includes a warning that the DC
output is out of the allowable output range.
AC Input FailIndicates that the AC input voltage is out of range.
Circuit Breaker TripIndicates that the AC rectifier circuit breaker

has tripped.
Over temperatureIndicates that the AC rectifier has exceeded the

AC Rectifier PresentIndicates that the rectifier is present and seated

properly in the power shelf.
Voltage and Current Monitor signals (Vmon, Imon)Indicates how

much output voltages and currents are provided by the AC rectifier.
Each AC rectifier contains an ID EEPROM that stores information used by

control software (for example, part number, serial number, assembly
deviation, special configurations, test history, and field traceability data).
The AC rectifier indicators receive power from both AC rectifiers;
therefore, the indicators are operational even when the AC rectifier is not
powered from its input voltage. The AC power indicators are shown on the
opposite page.
324
Version 2.0b
CRS-1 Essentials
Module 3
Power
OK
Name
Color
PWR OK
Green
The AC rectifier is operating normally with

power
Fault
Yellow
A fault has been detected within the AC

rectifier
AC Input Fail
Yellow
AC input is out of range or is not being

provided to the AC rectifier
Breaker Trip
Yellow
The input circuit breaker is off (in the off

position)
ILIM
Yellow
The AC rectifier is operating in a current

limiting condition
OT
Yellow
The AC rectifier is overheated and it has

been shut down
Fault
AC Input
Fail
CB Trip
ILIM
Function
OT
Version 2.0b
325
Module 3
CRS-1 8-Slot DC Power System

Power Distribution Unit (PDU)
A DC power distribution unit (PDU) contains one DC input terminal block
with 6 poles of two row M6 studs mating with industry standard two-hole
compression lugs on 5/8-inch centers, one ground blade connector and one
output connector mating with DC PEM. One DC PDU requires three
independent nominal -48 VDC or -60 VDC/ 60 A input services.
One DC PDU requires six 45 angle, industry standard, 2-hole compression
lugs with holes on 5/8- inch centers for three pairs (three -48 or -60 VDC
inputs and three returns) of DC input connections.
326
Version 2.0b
CRS-1 Essentials
Module 3
DC Power Distribution Unit (PDU)
Each DC PDU requires three independent

nominal 48 VDC or 60 VDC/60 A input
services.
Version 2.0b
327
Module 3
DC Power Entry Module

The DC power entry module (PEM) processes input power from DC PDU
and passes the power to the system chassis. DC PEMs are fieldreplaceable.
Three -48 or -60 VDC inputs enter the DC PEM at the rear of the PEM
through a connector on DC PDU. The PEM performs inrush current
limiting, EMI filtering, surge protection, and over voltage protection to
process the power before it exits the PEM and is distributed to the chassis
midplane.
Each DC PEM has self-contained cooling fans that draw air through the
module.
The yellow power switch on the front top left corner can be pushed or
pulled to turn the power on or off, respectively.
328
Version 2.0b
CRS-1 Essentials
Module 3
DC Power Entry Module
2 DC PEMs required per chassis, 1 per PDU

Each PEM provides 7500 WATTs of power
Version 2.0b
329
Module 3

A microprocessor in the DC PEM monitors the status of each DC PEM. The
microprocessor communicates with the system controller on the route
processor (RP) card. The microprocessor circuitry monitors the following
DC PEM fault and alarm conditions:
Fault Indicates a failure in a DC PEM, such as failed bias supply, or

over temperature. It includes a warning that the DC output voltage is
outside the allowable output range.
DC Input Fail Indicates that the DC input voltage is out of range.
Circuit Breaker Trip Indicates that the DC PEM circuit breaker has
tripped.
Over temperature Indicates that the DC PEM has exceeded the

DC PEM Present Indicates that the rectifier is present and seated

properly in the system chassis.
Voltage and Current Monitor signals (Vmon, Imon) Indicates how

much output voltage and current are provided by the DC PEM.
Each DC PEM contains an ID EEPROM that stores information used by

control software (for example, part number, serial number, assembly
deviation, special configurations, test history, and field traceability data).
The DC PEM indicators receive power from both DC PEMs; therefore, the
indicators are operational even when the DC PEM is not powered from its
input voltage. The DC power indicators are shown on the opposite page.
330
Version 2.0b
CRS-1 Essentials
Module 3
Power
OK
Fault
Name
Color
Function
PWR OK
Green
The PEM is operating normally with power
Fault
Yellow
A fault has been detected in the PEM
DC Input
Fail
DC Input Fail
Yellow
DC input is out of range or is not being

provided to the PEM
CB Trip
CB Trip
Yellow
The input circuit breaker is in the off

position
OT
Yellow
The DC PEM is overheated and it has been

shut down
OT
Version 2.0b
331
Module 3
CRS-1 8-Slot Line Card Chassis Cooling System

Overview
The line card chassis cooling system dissipates the heat generated by the
routing system and controls the temperature of components in the chassis.
The cooling system has a fully redundant architecture that allows the
routing system to continue operating with a single-fault failure (such as a
single fan or fan tray failure). The architecture also supports a redundant
load-sharing design.
The complete chassis cooling system includes:
Two fan trays (each holds four fans)
Temperature sensors (on cards and modules throughout the chassis)
An air filter, inlet and outlet air vents, and bezels
All four fans in a fan tray operate as a group. So, if it is necessary to

increase or decrease airflow, all fans in the tray increase or decrease their
rotation speed together. When two fan trays are operational in a chassis,
the speed of fans in both trays is adjusted together.
Thermal sensors (inlet, exhaust, and hot-spot) located throughout the line
card chassis are used to monitor temperature readings and identify when
the system is not cooling properly.
Software running on several types of service processor (SP) modules is
used to control the operation of the fans. These SP modules are connected
by internal Ethernet to the system controller on the route processor (RP)
332
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Cooling System - Overview
Cooling system fully redundant allows for single-fault

failure
Complete cooling system includes:
Two fan trays

Temperature sensors
Control S/W and logic
Air Filter, inlet/outlet air vents & bezels
Impedance carriers
4 fans in each tray operate as a group

Thermal sensors located throughout chassis
S/W runs on SP to control fan operations
SP modules connected via internal Ethernet to SC on RP
Version 2.0b
333
Module 3

The airflow through the line card chassis is controlled by a push-pull
configuration. The bottom fan tray pulls in ambient air from the bottom
front of the chassis and the top fan pulls the air up through the card cages
where the warm air is exhausted out the bottom rear of the chassis.
The line card chassis airflow volumes are as follows:
Chassis airflowUp to 900 cubic feet (25,485 liters) per minute
Power system airflowUp to 240 cubic feet (6800 liters) per minute
The chassis has a replaceable air filter mounted in a slide-out tray above
the lower fan tray. The line card chassis air filter, plugs into the rear
(MSC) side of the chassis.
Change the air filter as often as necessary. In a dirty environment, or
when you start getting frequent temperature alarms, check the intake
grilles for debris and check the air filter to see if it needs to be replaced.
Before removing the air filter for replacing, you should have a spare filter
on hand. Then, when you remove the dirty filter, install the spare filter in
the chassis.
334
Version 2.0b
CRS-1 Essentials
Module 3
Line Card Chassis Airflow & Air Filter
Fan Trays
Air Filter
Air Intake
Air Exhaust
PDU
PLIM Side
(Front)
MSC Side
(Rear)
Version 2.0b
335
Module 3
Cooling System Operations

The fan control software and related circuitry varies the DC input voltage
to individual fans to control their speed. This monitoring increases or
decreases the airflow needed to keep the routing system operating in a
desired temperature range. The chassis cooling system uses multiple fan
speeds to optimize cooling, acoustics, and power consumption. There are
four normal operating fan-speeds and one high-speed setting used when a
fan tray has failed.
At initial power up, the routing system control software powers on the fans
to 4300 to 4500 RPM. This provides airflow during system initialization
and software boot, and ensures that there is adequate cooling for the
system in case the software hangs during boot. The fan control software
initializes after the routing system software boots, which can take 3 to 5
minutes. The fan control software then adjusts the fan speeds
appropriately.
During normal operation, the system averages the temperatures reported
by inlet temperature sensors in the lower card cage (or in the upper card
cage if the lower cage is empty). To determine the appropriate fan speed for
the current temperature, the fan control software compares the averaged
inlet temperature to a lookup table that lists the optimal fan speed for each
temperature. The software then sets the fan speed to the appropriate value
for the current temperature. The temperature ranges in the lookup table
overlap to ensure a proper margin to avoid any type of fan speed oscillation
occurring between states.
_____________________________ Note _________________________
When there are no active alarms or failure, the fan control software
checks temperature sensors every 1 to 2 minutes.
_________________________________________________________________
336
Version 2.0b
CRS-1 Essentials
Module 3
Cooling System Operations
Fan control S/W & related circuitry:
Varies input voltage to control individual fan speed

Monitors increases & decreases in airflow to maintain
desired operating temperature
At initial power up fans run at 4300 to 4500 RPM to

ensure adequate cooling in case of S/W hang during boot
up
Fan control S/W initializes after boot up & adjust fan

speeds appropriately
Appropriate fan speed for given temperature determined

by comparing averaged inlet temperature to lookup table
Temperature ranges in lookup table overlap to prevent

fan speed oscillations
Version 2.0b
337
Module 3
Thermal Sensors
Local thermal sensors (on individual cards) monitor temperatures and
generate a thermal alarm when the system is not cooling properly. A
temperature sensor might trip in response to elevated ambient air
temperature, a clogged air filter or other airflow blockage, or a combination
of these causes. A fan failure causes a fault message, but if no thermal
sensors have tripped, the fan control remains unchanged.
When a thermal sensor reports a thermal alarm, the sensor passes the
fault condition to its local service processor (SP), which then notifies the
system controller on the route processor (RP). The system controller passes
the fault condition to the SP. The fan control software then takes
appropriate action to resolve the fault.
When a thermal sensor trips, the fan control software tries to resolve the
problem (for example, by increasing fan speed). The software performs a
series of steps to prevent chassis components from getting anywhere near
reliability-reducing, chip-destroying temperatures. If the fault continues,
the software shuts down the card or module to save components.
338
Version 2.0b
CRS-1 Essentials
Module 3
Thermal Sensors
Local thermal sensors monitor temperatures and

generate alarms when system is not cooling
properly
Alarm condition is passed to local SP which

notifies SC (on RP), SC passes it to SP which
instruct fan controller S/W to resolve problem
Fan controller S/W performs a series of actions

to prevent components from damage
If fault continues, S/W shuts down component or

module
Version 2.0b
339
Module 3

The redundant architecture of the cooling system allows the cooling system
to continue operating even when certain components have failed. The
cooling system can withstand the failure of any one of the following
components and still continue to properly cool the routing system:
a fan tray
DC PEM or AC rectifier
a fan cable (internal to the chassis and not field replaceable)
A double-fault fan failure involves two fan trays, two power modules (DC
PEMs or AC rectifiers), or any combination of two of these units. If a
double-fault failure occurs, the system remains powered on, unless both
fan trays have failed or thermal alarms indicate a problem serious enough
to power down the system. The failure of multiple fans is not considered a
double-fault failure because multiple fans can fail without impacting
system cooling.
___________________________CAUTION _______________________
When a cooling system component fails, it should be replaced as
soon as possible or within 24 hours at most.
_________________________________________________________________
340
Version 2.0b
CRS-1 Essentials
Module 3
Cooling system can withstand failure of any

one of following and still operate normally:
A fan tray
DC PEM or AC Rectifier
A fan cable (internal not FRU)
Double-fault - system remains powered on
unless both fan trays fail or thermal alarms
indicate a serious problem warrants system
power down
Version 2.0b
341
Module 3
Fan Tray
The two fan trays plug into the rear (MSC) side of the chassis. Each fan
tray is hot-swappable and is considered a field-replaceable unit. The
chassis is designed to run with both fan trays in place.
Each fan tray contains:
342
Four fansEach fan uses a nominal +24 VDC as its input power. This
voltage is adjusted to increase or decrease the speed of the fan. The
fans operate in the range of 4000 to 6700 RPM. Two DC-to-DC
converters provide input power to a single fan.
A fan tray boardThe board terminates signals to and from the fans,
filters common-mode noise, and contains tracking and indicator parts.
A front-panel status LEDThe LED indicates the following:
GreenThe fan tray is operating normally.
YellowThe fan tray has experienced a failure and should be

replaced.
OffAn unknown state exists or the LED is faulty.
Version 2.0b
CRS-1 Essentials
Module 3
Fan Tray
Each fan tray:
Has 4 +24 VDC fans

Fan speeds range from 4000 to 6700 RPM
Fan tray board
Front-panel status LED
Version 2.0b
343
Module 3
CRS-1 8-Slot Line Card Chassis Switch Fabric

Architecture
The Cisco CRS-1 8-Slot Line Card Chassis switch fabric uses a three-stage
Benes switch fabric architecture. Stage 1 (S1) distributes traffic. Stage 2
(S2) of the switch fabric implemented in the HS123 fabric card forwards
cells to Stage 3. Stage 3 (S3) performs switching, provides two times speedup of cells (doubling the number of output links to 72), and to reduce
contention for output links and to reduce the possibility of data cells being
delayed during periods of congestion.
On the HS123 fabric card, there are two fabric planes and each plan has 3
ASICs, one for each stage (S1, S2, and S3).
The switch fabric is logically divided into eight fabric planes. There are
four HS123 switch fabric cards (SFCs) in the chassis (numbered 0, 1, 2,
and 3), and each of these cards implements two different planes of the
switch fabric. System bandwidth is distributed equally among all eight
planes of the switch fabric.
344
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Switch Fabric - Architecture
CRS-1 8 slot LC
chassis:
Each fabric plane
comprised of S1, S2
& S3 ASICs
Each plane provides
2x speedup
Each SFC has 2
fabric planes of
fabric
Contains 4 SFC or 8
fabric planes total
System B/W
distributed equally
across all 8 planes
Version 2.0b
345
Module 3
Operation
In the CRS-1 routing system, the switch fabric receives user data from an
ingress MSC/PLIM pair and performs the switching necessary to route the
data to the appropriate egress MSC/PLIM pair.
Ingress data packets are received at a physical interface on a PLIM and
transferred to the associated MSC, where the packets are segmented into
cells for efficient switching by the switch fabric hardware. Each MSC
distributes data cells to each switch fabric plane and has multiple
connections per switch fabric plane.
Each switch fabric plane is independent and not synchronized with one
another. Each cell traverses the switch fabric using a single switch fabric
plane. (Cells are not bit-sliced across the switch fabric.)
The basic path of IP data packets through the Cisco CRS-1 8-Slot switch
fabric is shown in the diagram on the opposite page.
Each HS123 fabric card will actually contain two S1, two S2, and 2 S3 SEA
ASICs, belonging to 2 different fabric planes:
346
Stage 1 (S1)Receives cells from the MSC (or RP card) and distributes
them to Stage 2 (S2) elements in the fabric plane.
Stage 2 (S2)Receives cells from the S1 stage, and switches cells to S3

stage. S2 also performs the first stage of the multicast function.
Stage 3 (S3)Receives cells from the S2 stage, and performs the

switching necessary to route each cell to the appropriate egress MSC,
provides 2X speed-up, and performs a second level of the multicast
function.
Version 2.0b
CRS-1 Essentials
Module 3
Operation
Version 2.0b
347
Module 3
SFC Functional Block Diagram

The major functional blocks of the HS123 switch fabric card are:
348
S1 switch elementReceives data cells from the MSC (or RP) and
distributes them to the S2 stage. The S1 switch element is connected to
its corresponding S2 switch element within the same fabric plane.
S2 switch elementReceives data cells from the S1 stage. The S2

switch element is connected to its corresponding S1 and S3 switch
elements within the same fabric plane. S2 has 36 inputs and 36
outputs.
S3 switch elementReceives data cells from the S2 stage and performs

switching and fabric speed-up. S3 has 36 inputs and 72 outputs.
Service processorProvides the interface to the CRS-1 routing system

control plane. The service processor does the following:
Controls power up and power down of the switch fabric card
Configures the components in the various switch elements
Updates the FGID (Fabric Group ID), for multicast traffic
Maintains cell configuration
Controls link up and link down processing and status
Collects and processes statistics for the HS123 switch fabric card
Power modulesTake 48V DC input power from the midplane and

convert it to the voltages required by the components on the switch
fabric card.
Alphanumeric displayDisplays HS123 switch fabric card messages.
Status LEDIndicates status of the HS123 switch fabric card.
Version 2.0b
CRS-1 Essentials
Module 3
SFC Functional Block Diagram
Version 2.0b
349
Module 3
CRS-1 8-Slot Line Card Chassis Route Processor

Overview
The route processor (RP) card is the system controller for the single-chassis
Cisco CRS-1 8-Slot Carrier Routing System. The CRS-1 8-slot RP is unique
to the 8-slot chassis and contains a single MPC7457 1.2 GHz processor.
The RP performs route processing and distributes forwarding tables to the
MSCs. In a routing system that contains two RP cards, only one RP is
active at a time. The other RP operates in standby mode, ready to assume
control if the active RP fails.
_____________________________ Note _________________________
The Cisco CRS-1 8-slot Carrier Routing System can be purchased with
a single RP, this module discusses the routing system containing two
RPs.
_________________________________________________________________
The RP card provides route processing, alarm, fan and power supply
controller function in the Cisco CRS-1 8-Slot Carrier Routing System. The
RP card controls fans, alarms, and power supplies through the use of an i2c
communication link from the RP card to each fan tray/power supply.
Two RP cards are required per chassis for redundancyone is active, and
the other is standby. An RP card can be inserted in either of the two
dedicated slots in the chassis.
350
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Route Processor - Overview
Not interchangeable with 16 slot RP

Single MPC7457 (1.2Ghz) processor
2 RPs required for redundancy
Route processing functionality
System Controller functionality
Alarm, fan and power supply controller
functionality
Version 2.0b
351
Module 3
RP Components
352
Hard driveAn IDE hard drive is used to gather debugging

information, such as core dumps from the RP or MSCs. It is typically
powered down and activated only when there is a need to store data.
MemoryResides in a SIMM module on the RP card. The RP can be

configured with 2 or 4 GB of memory.
PCMCIA SubsystemsTwo ATA type PCMCIA flash slots provide

support for 1 Gb of flash subsystem storage, each. One of the PCMCIA
flash subsystems is accessible externally and removable, and allows
you to transfer images and configurations by plugging in a PCMCIA
flash card. The other PCMCIA flash subsystem is fixed to the RP, for
permanent storage of configurations and images and is required for OS
operation.
CPUPerforms route processing. The CPU also serves as the MSC

service processor (SP), and monitors the RP temperature, voltages,
power supply margining (during factory test), and ID EEPROM.
SFP modulesTwo small form-factor pluggable (SFP) modules support

external Gigabit Ethernet connections for multi-chassis systems.
RJ45 Ethernet portAn RJ45 10/100/1000 copper Ethernet port is

available for providing connectivity to network management systems.
Fast Ethernet Midplane ConnectorInternal 100 Mbps Fast Ethernet

(FE) midplane connections connect each MSC in the chassis to both RP
cards. These FE connections are traces in the midplane. There are also
FE connections to the fans power supplies. These connections all form
part of the control plane.
Version 2.0b
CRS-1 Essentials
Module 3
RP Components
Hard drive 40 Gig.

Memory 2 or 4 GB
2 PCMCIA slots
CPU
2 SPF Modules
RJ45 Ethernet port
Fast Ethernet
Midplane Connector
Version 2.0b
353
Module 3
RP Front Panel
Every line card chassis contains two route processor cards in
dedicated|redundant slots on the PLIM side of the chassis.
The RP front panel includes:
An IDE disk slot
A PCMCIA flash disk slot
Two small form-factor pluggable (SFP) modules for external Gigabit

Ethernet (GE) connections
A GE copper port
Two RJ45 serial Console and AUX ports
An alphanumeric LED display
A status OK LED
An Active/Standby LED
Route Processor (RP) Memory Options

The RP can be configured with 2 or 4 GB of memory.
Processor Module (CPU0:)

Single MPC7457 1.2 GHz processor
354
Version 2.0b
CRS-1 Essentials
Module 3
RP Front Panel
CPU
Memory
Version 2.0b
355
Module 3
Block Diagram
On the oppose page is a simple block diagram of an RP. In this drawing,
the dotted lines indicate distinct RP modules, such as the CPU and
memory controller (MEM CTL), and the To fabric and From fabric
modules.
The main components of the route processor card are:
1. A single 1.2 GHz CPU processor that performs route processing and
distributes forwarding tables to the MSCs. Among other tasks, the CPU
subsystem performs the function of the service processor (SP) in the
MSC and monitors the RPs temperature, voltages, margining of the
power supplies during factory test, and ID EEPROM. In addition, it
provides alarm, fan and power supply controller function for the line
card chassis.
2. Two small form-factor pluggable (SFP) modules for external Gigabit
Ethernet (GE) connections. These modules connect to two external GE
switches that interconnect all line card and fabric chassis together to
form a control network. The GE switches are not used in a singlechassis CRS-1 routing system.
3. A third Ethernet port for 10/100/1000 Ethernet copper connectivity to
network management systems.
4. Internal Fast Ethernet (FE) midplane connections. Each line MSC in a
chassis connects to both RPs via an internal 100 Mbps FE connection.
The FE connections are traces in the midplane. There are also FE
connections to the fans, blowers, and power supplies. These connections
all form part of the control plane.
5. An IDE hard disk used for gathering debugging information, such as
core dumps from the RP or MSCs. The IDE hard disk does not contain
user data of any kind. The disk is typically powered down and activated
only when there is a need to store data. The IDE hard disk is not vital
to the functioning of the routing system and is user-removable.
6. Two ATA type PCMCIA flash slots for 1 GB of flash storage. One of the
PCMCIA flash subsystems is accessible externally and allows you to
transfer images and configurations by plugging in a PCMCIA flash
card. The other subsystem is fixed to the RP and is for permanent
storage of configurations and images. The RP comes standard with one
PCMCIA 1 GB flash.
356
Version 2.0b
CRS-1 Essentials
Module 3
Block Diagram
LC FE
links
CTL GE link
FE/GE
switch
CTL GE link
PCI
9
Q
links
To
fabric
From
fabric
CPU
MEM
IF
CTL
CPU
IDE
PCMCIA
2
8
Aux and console
Management GE link
FPGA
Midplane

RP mastership
PROM presence
10
Version 2.0b
357
Module 3
7. The RP mates with the line card chassis midplane. Through the
midplane, the RP has connections to the routing system switch fabric.
To connect through the switch fabric, the RP has fabric interfaces
(From fabric and To fabric) similar to the one used on the MSC.
8. The From fabric module is part of the receive path of the RP. The
From fabric module queues the data from the switch fabric. It also
reorders and reassembles the cells into packets before queuing them for
slow path processing.
9. The To fabric module is part of the transmit path on the RP. The To
fabric module queues the packets and segments them into cells before
transmitting them to the switch fabric.
10. The Field Programmable Gate Array (FPGA) handles system control
register functions, such as; identifying which PLIMs are installed, RP
mastership signals, card present signals, card reset signals to cards
with service processors. In addition, the FPGA handles the front panel
alphanumeric display, the Active LED and the OK LED.
358
Version 2.0b
CRS-1 Essentials
Module 3
Block Diagram (Cont.)
LC FE
links
CTL GE link
FE/GE
switch
CTL GE link
PCI
9
Q
links
To
fabric
From
fabric
CPU
MEM
IF
CTL
CPU
IDE
PCMCIA
2
8
Aux and console
Management GE link
FPGA
Midplane

RP mastership
PROM presence
10
Version 2.0b
359
Module 3

The two RPs in a line card chassis operate in an active-standby
relationship. The active-standby arbitration algorithm is performed by
hardware and software. The arbitration algorithm goes through these
steps:
1. At chassis power up, each RP boots its board components and runs selftests.
2. Each RP exchanges messages with the other RP and with the service
processors (SPs) on all other boards on the midplane. Each RP
examines its outgoing Reset lines to verify that they are inactive.
3. Based on the results of these tests, each RP decides whether it is ready
to become shelf (that is, chassis) master that is the active RP. If it is, it
asserts the Ready signal to its on-board arbitration unit. The
arbitration unit propagates the Ready signal to the other RP.
4. The arbitration hardware chooses the active RP from the RPs that has
asserted Ready. The hardware asserts an Active signal to the
chosen RP, along with an interrupt and propagates the Active signal
to the other RP, which also receives an interrupt. In the case of a tie,
the Active will be the RP in the lower numbered slot.
6. In case the active RP is removed, powered down, or voluntarily deasserts its Ready signal, the standby RP immediately receives an
asserted Active signal, along with an interrupt.
360
Version 2.0b
CRS-1 Essentials
Module 3
The active-standby arbitration algorithm performed by hardware and

software:
1. At chassis power up, each RP boots and runs self-tests.

2. The RP exchange messages with each other and with SPs on all other
boards. Each RP examines its outgoing Reset lines to verify that they
are inactive.
3. Based on results of these tests, each RP decides whether it is ready to
become the active RP. If it is, it asserts Ready signal to its on-board
arbitration unit that propagates Ready signal to other RP.
4. Arbitration hardware chooses active RP. Hardware asserts an Active
signal to the chosen RP, along with an interrupt and propagates Active
signal to other RP, which also receives an interrupt. If a tie, Active is
RP in lower numbered slot.

6. If active RP is removed, powered down, or voluntarily de-asserts its
Ready signal, standby RP immediately receives an asserted Active

signal, along with an interrupt.
Version 2.0b
361
Module 3
Summary
362
To list and describe the hardware features and functions of the CRS-1
8-slot line card chassis
To list and describe the features and functions of the FRUs and
Version 2.0b
CRS-1 Essentials
Module 3
Review Questions
1. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
Version 2.0b
363
Module 3

364
Version 2.0b
CRS-1 Essentials
Module 4
CRS-1 Line Card Chassis Common Elements
Overview
Description
This module provides a high-level overview of the hardware elements that
are common to both the CRS-1 16- and 8-slot line card chassis. The
Modular Services Card is presented first, followed by the physical layer
interface cards (PLIMs), and then the SPA Interface Processor (SIP)-800 is
presented. The module ends with a presentation on each of the currently
supported Shared Port Adapters (SPAs).
Objectives
List and describe the features and functions of the CRS-1 MSC
List and describe the features and functions of a Distributed Route

Processor card
List and describe the features and functions of each of the PLIMs
supported by the Cisco CRS-1 routing system
List and describe the features and functions of the SIP-800 jacket card
List and describe the features and functions of each of the SPAs
supported by the Cisco CRS-1 routing system
Version 2.0b
41
Module 4
Modular Services Card

Overview
The modular services card (MSC) is the Layer 3 forwarding engine in the
CRS-1 routing system. Each MSC is paired with a corresponding physical
layer interface module (PLIM) that contains the packet interfaces for the
MSC. An MSC can be paired with different types of PLIMs to provide a
variety of packet interfaces, such as OC-192 POS and OC-48 POS.
Each MSC and associated PLIM implement Layer 1 through Layer 3
functionality of the OSI model that consists of physical layer framers and
optics, MAC framing and access control, and packet lookup and forwarding
capability. The MSCs deliver line-rate performance.
The MSCs support forwarding of IPv4 and IPv6 Unicast and Multicast
traffic while the route processor (RP) is responsible for maintaining global
routing table built from BGP, OSPF, IS-IS or other routing updates, then
distributes routing table information.
MSCs and PLIMs are installed on opposite sides of the line card chassis,
and mate through the line card chassis midplane. Each MSC/PLIM pair is
installed in corresponding chassis slots in the chassis (on opposite sides of
the chassis) shown in the physical view on the opposite page.
The MSC provides Layer 3 services for the user data, and the PLIM
provides Layer 1 and Layer 2 services. An MSC can be paired with
different types of PLIMs to provide a variety of packet interfaces and port
densities (for example, OC-192 and 10-Gigabit Ethernet).
The logical view shows how data enters the ingress PLIM and is forward to
the MSC. The MSC forward the data in the form of switch fabric cells
across the switch fabric to the egress MSC, the MSC reassembles the cells
into a packet and sends the packet out the egress PLIM. All data traffic
must pass through the switch fabric, even data that is received on port zero
of a PLIM and is destine for a distance node reachable through port three
of the same PLIM was travel through the switch fabric.
42
Version 2.0b
CRS-1 Essentials
Module 4
Modular Services Card - Overview
Mid-Plane
Physical
View
PLIMs
MSCs/DRPs
RPs/FCs
SFM
PLIMs
MSCs/DRPs
PLIM MSC
Logical
View
IP
Data
S1
S2
S3
Ingress
MSC
Egress
PLIM
IP
Data
Switch Fabric
Version 2.0b
43
Module 4
MSC Hardware Components

The various components that form the MSC:
CPU The MSC includes a CPU module to handle control plane functions.
The CPU is involved in MSC configuration, management, protocol control,
and exception packet handling. The CPU subsystem includes a single
PowerPC CPU and L3 cache, NVRAM, FLASH Boot PROM, memory
controller, and a single DIMM socket capable of providing up to 2 GBytes
total of DDR SDRAM.
SP The SP controls card power-up, environmental monitoring, and
Ethernet communication with the chassis RP boards.
Power Regulators Standard isolated DC-DC power bricks on the board
convert 48V directly to 5V and 1.8V. The housekeeping voltage 3.3V_SP
comes from a 48V SIP module. Low-voltage non-isolated voltage regulating
modules (VRMs) convert this 5V to 3.3V, 2.5V, 1.5V, 1.25V, and 1.2V for
motherboard and module use.
Packet Switch Engine (PSE) Resides on the MSC and is the primary L3
feature processing ASIC. The PSE applies features such as ACL checking,
uRPF, BGP-PA as well as QOS functions such as policing & WRED to the
traffic stream. There is one PSE in the RX path and another in the TX
path.
IngressQ/EgressQ IngressQ is the RX queuing ASIC, EgressQ is the TX
queuing ASIC and both reside on the MSC. Each of these ASICs
implements features such as P2MDRR, low-latency queuing and shaping
support. In addition, the IngressQ contains fabric queues and the packet to
fabric cell conversion functionality.
FabricQ The MSC contains two of FabricQ ASICs in the transmit path
from the fabric towards the PLIM. The FabricQ reassembles the fabric
cells and converts these back to full packets. Although each ASIC contains
queuing functionality and provide low-latency and precedence-based
queuing, these queues are not directly configurable.
A more detailed discussion of the MSC operations will be covered in a later
module.
44
Version 2.0b
CRS-1 Essentials
Module 4
MSC Hardware Components
Power
Regulators
EgressQ
2*FabricQ
Egress
PSE
SP
CPU
Ingress
PSE
Version 2.0b
IngressQ
45
Module 4
DRP Architecture - LC Chassis

The DRPs can be used where additional route processing power is required
and where you want to partition the routing system into multiple logical
routers. They function just like the Route Processor Card; however, an RP
will remain necessary for operation of the chassis. DRP boards can be
inserted into any MSC slot, with a DRP PLIM inserted so that the two
cards connect through the midplane.
To improve route processor density, there are now two pairs of 933
PowerPC processors on each board. Each DRP board has two auxiliary and
serial ports for login and debugging as well as two of the following:
4G/8GB DDR DRAM via memory controller
64 MB boot flash
2 MB NVRAM for debug, logging data, diagnostic data
PCMCIA slot 1 GB flash card,
20 GB IDE hard drive
DRPs have shared resources SP, IngressQs, and (2) FabricQs.

DRPs do not have separate Control GigE links to connect to the InterChassis management system control plane. DRPs do have two GigE
management ports that serve the same function as the 10/100/GE
management link on the RP.
46
Version 2.0b
CRS-1 Essentials
Module 4
FE Links
M
I
D
P
L
A
N
E
Fabric
Connection
IngressQ
(SPRAYER)CPUCTRL
(SQUID)
SPONGE
FabricQ
(SPONGE)
CPUCTRL
(SQUID)
SP
PCI
IDE
MEM
CTL
CPU
CPU0
IDE
Aux & Console
CPU1
MEM
CTL
Mgmt GE
link
CPU
Aux & Console
Mgmt GE
link
Shared Resource
FLASH
FLASH
Version 2.0b
FLASH
FLASH
47
Module 4
Physical Layer Module (PLIM)

Overview
A physical layer interface module (PLIM) provides the packet interfaces for
the routing system. Optic modules on the PLIM contain ports to which
fiber-optic cables are connected. User data is received and transmitted
through the PLIM ports. In addition, PLIMs perform functions, such as
framing, clock recovery, serialization and de-serialization, channelization
and converted between the optical signals (used in the network) and the
electrical signals (used by Cisco CRS-1 components).
MSCs and PLIMs are installed on opposite sides of the line card chassis,
and mate through the chassis midplane. Each MSC and PLIM pair is
installed in corresponding chassis slots in the chassis (on opposite sides of
the chassis). The chassis midplane enables you to remove and replace an
MSC without disconnecting the user cables on the PLIM.
48
Version 2.0b
CRS-1 Essentials
Module 4
Physical Layer Module (PLIM) - Overview
PLIM provides Layer 1 and Layer 2 services and an
interface for routing system

Optic modules on PLIM contain ports to connect fiberoptic cables
PLIMs perform:
Framing
Clock recovery
Serialization and de-serialization
Channelization
Conversion between optical signals and electrical signals
MSCs and PLIMs installed on opposite sides of line card
chassis and mate through chassis midplane

Chassis midplane enables you to remove and replace an
MSC w/o disconnecting user cables on PLIM
Version 2.0b
49
Module 4
PLIM Physical Characteristics

All POS and POS/DPT PLIMs have the following physical characteristics:
410
Height20.6 in. (52.3 cm)
Depth11.2 in. (28.5 cm)
Width1.8 in. (4.6 cm)
Weight7.8 to 8.6 lb (3.5 to 3.9 kg), see individual PLIM descriptions
Power consumption65 to 150 W, see individual PLIM descriptions
Version 2.0b
CRS-1 Essentials
Module 4
PLIM Physical Characteristics
Height20.6 in. (52.3 cm)

Depth11.2 in. (28.5 cm)
Width1.8 in. (4.65 cm)
Weight7.8 to 8.6 lb. (3.5
to 3.9 kg)
Power Consumption65
to 150 Watts
Version 2.0b
411
Module 4
PLIM Types
Different PLIMs provide a range of optical interfaces, such as very-shortreach (VSR), intermediate-reach (IR), or long-reach (LR). The Cisco CRS-1
supports the following PLIMs for each chassis type.
412
1-port OC-768/STM-256 packet-over-SONET (POS); available in shortreach (SR) optics.
4-port OC-192c/STM-64c POS/DPT; available in long-reach (LR),

intermediate-reach (IR), short-reach (SR), and very-short-reach (VSR)
optics.
OC-48c/STM-16c POS/DPT, configurable with 1 to 16 ports; available in

long-reach (LR) and short-reach (SR) optics. This PLIM supports
pluggable optics.
10-Gigabit Ethernet (GE); available in long-reach (LR) optics. This

PLIM supports pluggable optics, and can be configured with 1 to 8
ports.
Version 2.0b
CRS-1 Essentials
Module 4
PLIM Types
1-port OC-768/STM-256 POS uses SR optics

4-port OC-192c/STM-64c POS/DPT available in
LR, IR, SR, and VSR optics
OC-48c/STM-16c POS/DPT, provisionable with 1

to 16 ports; available in LR and SR optics
Supports pluggable optics
10-GE uses LR optics
Supports pluggable optics

Can be provisioned with 1 to 8 ports
Version 2.0b
413
Module 4
PLIM Functionality
The PLA ASIC is the interface controller for the PLIM.
Ingress
In the ingress direction it takes all the traffic coming from the different
ports on the PLIM and places them into virtual queues. These queues are
serviced according to an egress-initiated backpressure which allows more
traffic to be sent to destination MSCs where the traffic queues are empty.
This allows queues on congested MSCs to empty. The PLA ASIC de-queues
packets and sends them to the PSE ASIC to be Layer3 processed.
Egress
In the egress direction it takes all the traffic from the EgressQ ASIC
buffers it and then transmits it to the appropriate egress port.
The diagram on the opposite page highlights the major actions that take
place when a packet enters the PLIM.
_____________________________ Note _________________________

The same version of the PLA ASIC is used on the OC-192, OC-48
PLIMs, and 8-port 10GE PLIMS. A different version of the PLA ASIC is
used on the OC-768 PLIM and SPA cards.
_________________________________________________________________
414
Version 2.0b
CRS-1 Essentials
Module 4
PLIM Functionality
PLA - L2 ASIC
Some L2 statistics
gathering
Consolidation of port
streams for Rx PSE
Stream separation on Tx
Ingress monitoring Rx
Buffers for congestion
Exact PLA variant and

number of PLAs varies
from PLIM to PLIM
Version 2.0b
M
I
D
P
L
A
N
E
OC192
Framer
OC192
Optics
OC192
Framer
OC192
Optics
OC192
Framer
OC192
Optics
OC192
Framer
OC192
Optics
PLA
PLIM I/F
415
Module 4
PoS and PoS/DPT PLIM Features

Each PoS/DPT PLIM provides:
416
SONET/SDH path, line and section processing
PPP and HDLC encapsulation
Online insertion and removal (OIR)
Local (internal) and loop-timed (network-recovered) clocks; Stratum-3

accuracy
Network management: Cisco IOS XR CLI, SNMP, XML and CWI
Alarm detection (with user configurable thresholds) and performance

monitoring
Payload scrambling
Compliance with network and industry standards
Version 2.0b
CRS-1 Essentials
Module 4
PoS and PoS/DPT PLIM Features
Each PoS/DPT PLIM provides:

SONET/SDH path, line and section processing
PPP and HDLC encapsulation
Online insertion and removal (OIR)
Local (internal) and loop-timed (network-recovered)
clocks; Stratum-3 accuracy

Network management: Cisco IOS XR CLI, SNMP, XML and
CWI
Alarm detection (with user configurable thresholds) and
performance monitoring
Payload scrambling
Compliance with network and industry standards
Version 2.0b
417
Module 4
OC768c PLIM HW Architecture

The 1-port OC-768 PLIM provides a single interface of 40 gigabits per
second (Gbps), which is the OC-768 line rate. The PLIM performs Layer 1
and Layer 2 processing for a single OC-768 data stream by removing and
adding the proper header information as data packets enter and exit the
PLIM. The PLIM passes the MSC a single 40-Gbps data packet stream.
The OC-768 PLIM is a class 1 laser product that operates in POS mode
only; DPT mode is not supported. The PLIM contains:
Optics moduleProvides receive (RX) and transmit (TX) optic

interfaces that comply with ITU Recommendation G.693. The module
provides short-reach (SR) optics with SC fiber-optic interfaces.
FramerProvides processing and termination for SONET/SDH section,

line, and path layers, including alarm processing and automatic
protection switching (APS) support.
Physical interface controllerProvides data packet buffering and Layer

2 processing, including processing for VLANs and back-pressure signals
from the MSC.
Additional componentsInclude power and clocking components,

voltage and temperature sensors, and an identification EEPROM that
stores initial configuration and PLIM hardware information.
The Cisco IOS XR software also provides diagnostic functions for the
PLIM, such as loopback tests, etc.
418
Version 2.0b
CRS-1 Essentials
Module 4
OC768c PLIM HW Architecture
EgressQ
M
i
d
p
l
a
n
e
PLA768
Framer
RX PSE
MSC
1xOC768 PLIM
Version 2.0b
419
Module 4
OC-768c PLIM Faceplate

The 1-port OC-768 PLIM has:
A single port (0) with SC fiber-optic interfaces for TX and RX
Three port LEDs that provide information about the status of the port:
ACTIVEIndicates that the port is logically active; the laser is on
CARRIERIndicates that the receive port (RX) is receiving a

carrier signal. The LED goes out (turns dark) if a loss-of-signal
(LOS) or loss-of-frame (LOF) condition is detected
RX PKTBlinks every time a packet is received
A STATUS LED
Green indicates that the PLIM is properly seated and operating

correctly
Yellow or amber indicates a problem with the PLIM
Off (dark), check that the board is properly seated and that system
power is on
_____________________________ Note _________________________

Power consumption is 65 Watts
_________________________________________________________________
420
Version 2.0b
CRS-1 Essentials
Module 4
OC-768c PLIM Faceplate
A single port (0) with SC fiber-optic interfaces for TX and RX

Three port LEDs that provide information about the status of the port:
ACTIVEIndicates that the port is logically active; the laser is on

CARRIERIndicates that the receive port (RX) is receiving a carrier signal.
The LED goes out (turns dark) if a loss-of-signal (LOS) or loss-of-frame
(LOF) condition is detected
A STATUS LED
Green indicates that the PLIM is properly seated and operating correctly
Off (dark), check that the board is properly seated and that system power
is on
Power consumption is 65 W
Version 2.0b
421
Module 4
4 - Port OC192c PLIM HW Architecture

The 4-port OC-192 PLIM contains four ports that can be software
configured to operate in packet-over-SONET (POS) or Dynamic Packet
Transport (DPT) mode. The PLIM performs Layer 1 and Layer 2
processing for four OC-192 data streams by removing and adding the
proper header information as data packets enter and exit the PLIM. The
PLIM feeds the MSC a single 40-Gbps data packet stream.
The VSR version of the PLIM is a class 1M laser product. All other
versions (LR, IR, and SR) are class 1 laser products.
____________________________________ Note ________________________________
DPT mode is not available at this time.

_________________________________________________________________________________
The 4-port OC-192 PLIM contains:
Optics modulesProvide receive (RX) and transmit (TX) optic

interfaces that comply with GR-253-CORE. The PLIM supports the
following types of optics:
Long-reach (LR) optics with SC fiber-optic interfaces
Intermediate-reach (IR) optics with SC fiber-optic interfaces
Short-reach (SR) optics with SC fiber-optic interfaces
Very-short-reach (VSR) optics with standard MTP (MPO) multifiber optic interfaces
FramersProvide processing and termination for SONET section, line,

and path layers, including alarm processing and automatic protection
switching (APS) support. The framer supports both packet and cell
processing for a multiservice operating mode.

2 processing and multiplexing and demultiplexing on the four OC-192
data streams. Also provides processing for VLANs and back-pressure
signals from the MSC.
DPT or transparent mode componentsProvides the MAC layer

function for the Spatial Reuse Protocol used in DPT mode. When the
PLIM is in POS mode, these components operate in the transparent
mode.
Additional componentsProvide power, clocking, voltage and

temperature sensing, and an identification EEPROM that stores initial
configuration information and details about the PLIM type and
hardware revision.
The Cisco IOS XR software also provides loopback and diagnostic functions
for the PLIM, such as loopback tests, etc.
422
Version 2.0b
CRS-1 Essentials
Module 4
4 - Port OC192c PLIM HW Architecture
M
i
d
p
l
a
n
e
RAC1
Framer 1
RAC2
Framer 2
RAC2
Framer 3
PLA 1
Line card
Framer 0
PLA 0
EgressQ
Rx PSE
RAC0
4xoc192 PLIM
Version 2.0b
423
Module 4
4 - Port OC-192c PLIM Faceplates

424
Four ports (0, 1, 2, and 3) with TX and RX jacks for each port. The VSR
version of the PLIM provides standard MTP (MPO) multi-fiber optic
interfaces. All other PLIMs (LR, IR, and SR) have SC fiber-optic
interfaces.
A STATUS LEDGreen indicates that the PLIM is properly seated

and operating correctly. Yellow or amber indicates a problem with the
PLIM. If the LED is off (dark), check that the board is properly seated
and that system power is on.
Five green LEDs for each port:
ACTIVE/FAILUREIndicates that the port is logically active; the

laser is on.

carrier signal.
RX PKTBlinks every time a packet is received.
WRAPIndicates that the port is in DPT wrapped mode.
PASS THRUIndicates that the port is operating in the POS mode

(DPT pass through).
Two DPT MODE LEDsOne DPT MODE LED is for ports 0 and 1, and
the other is for ports 2 and 3. DPT mode is always configured on pairs
of ports.
Power consumption: 138 Watts
Version 2.0b
CRS-1 Essentials
Module 4
4 - Port OC-192c PLIM Faceplates
Four ports (0, 1, 2, and 3) with TX and RX jacks for each port
VSR version of PLIM provides standard MTP (MPO) multi-fiber optic interfaces
All other versions of PLIMs (LR, IR, and SR) have SC fiber-optic interfaces
A STATUS LEDGreen indicates PLIM properly seated and operating
Yellow or amber indicates a problem with PLIM

Off (dark), check that board is properly seated and that system power is on
Five green LEDs for each port:
ACTIVE/FAILUREIndicates port is logically active; laser is on

CARRIERIndicates receive port (RX) is receiving a carrier signal
WRAPIndicates port is in DPT wrapped mode
PASS THRUIndicates port is operating in POS mode (DPT pass through)
DPT mode is always configured on pairs of ports
Two DPT MODE LEDsOne DPT MODE LED is for ports 0 and 1, and other for ports 2 and 3
Version 2.0b
425
Module 4
16 - Port OC-48c PLIM HW Architecture

The 16-port OC-48 PLIM contains 16 OC-48 interfaces that can be
software configured to operate in packet-over-SONET (POS) or Dynamic
Packet Transport (DPT) mode. The PLIM performs Layer 1 and Layer 2
processing for 16 OC-48 data streams by removing and adding the proper
header information as data packets enter and exit the PLIM. The PLIM
feeds the MSC a single 40 Gbps data packet stream. The PLIM is a class 1
laser product.
____________________________________ Note ________________________________
DPT mode is not available at this time.

_________________________________________________________________________________
The 16-port OC-48 PLIM consists of:
Optics modulesProvide the receive (RX) and transmit (TX) optic

interfaces for each of the 16 ports. The PLIM uses small form-factor
pluggable (SFP) optic modules that can be removed and replaced while
the PLIM is powered up. The SFPs provide short-reach (SR) and longreach (LR2) optics with LC fiber-optic interfaces.
FramersProvides processing and termination for SONET section,

line, and path layers, including alarm processing and APS support and
management. The framer supports both packet and cell processing for a
multiservice operating mode.
DPT or transparent mode componentsProvides the MAC layer

function for the Spatial Reuse Protocol used in DPT mode. When the
PLIM operates in the POS mode, these components operate in the
transparent mode.

2 processing and multiplexing and demultiplexing of the 16 OC-48 data
streams. Also provides processing for VLANs and back-pressure signals
from the MSC.
Additional componentsProvides power, clocking, voltage and

temperature sensing, and an identification EEPROM that stores initial
configuration information and details about the PLIM type and
hardware revision.
The Cisco IOS XR software also provides loopback and diagnostic functions
for the PLIM, such as loopback tests, etc.
426
Version 2.0b
CRS-1 Essentials
Module 4
16 - Port OC-48c PLIM HW Architecture
PLA 0
EgressQ
RAC0
Framer 0
RAC1
Framer 1
RAC2
Framer 2
RAC3
Framer 3
M
i
d
p
l
a
n
e
Rx PSE
PLA 3
Framer 12
RAC13
Framer 13
RAC14
Framer 14
RAC15
Framer 15
16xoc48 PLIM
Line card
RAC12
Version 2.0b
427
Module 4
16 - Port OC-48c PLIM Faceplate

Sixteen slots for SFP optic modules, which provide SR or LR optics with
LC fiber-optic interfaces.
A STATUS LED
correctly
power is on
Eight DPT MODE or POS MODE LEDsOne of these DPT MODE or

POS MODE LEDs is for each pair of ports, 0 and 1, 2 and 3, 4 and 5, 6
and 7, 8 and 9, 10 and 11, 12 and 13, and 14 and 15. DPT mode is
always configured on pairs of ports. The LED is on when a pair of ports
are configured in DPT mode. At this time, the 16-port OC-48 PLIM
operates only in the POS mode.
Five green LEDs for each port. The LEDs, which correspond to the
labels on the lower left of the front panel, have the following meanings
(from left to right):
428
ACTIVE/FAILUREIndicates that the port is logically active; the

laser is on.

carrier signal.
RX PKTBlinks every time a packet is received.
WRAPIndicates that the port is in DPT wrapped mode.
PASS THRUIndicates that the port is operating in the POS mode

(DPT pass through).
Version 2.0b
CRS-1 Essentials
Module 4
16 - Port OC-48c PLIM Faceplate
Sixteen slots for SFP optic modules, which provide SR or LR optics with LC fiber-optic interfaces
A STATUS LED
Green indicates PLIM is properly seated and operating correctly

Yellow or amber indicates a problem with PLIM
Off (dark), check that board is seated and power is on
Eight DPT MODE or POS MODE LEDs
One of these DPT MODE or POS MODE LEDs is for each pair of ports, 0 and 1, 2 and 3, 4 and 5, 6 and 7, 8 and 9, 10 and
11, 12 and 13, and 14 and 15. DPT mode is always configured on pairs of ports
LED is on when a pair of ports are configured in DPT mode
Currently, 16-port OC-48 PLIM operates only in POS mode
ACTIVE/FAILUREIndicates port is logically active; laser is on

CARRIERIndicates receive port (RX) is receiving a carrier signal
WRAPIndicates port is in DPT wrapped mode
PASS THRUIndicates port is operating in POS mode (DPT pass through)
Five green LEDs for each port
Power consumption 136 Watts
Version 2.0b
429
Module 4
10 Port 10GE PLIM HW Architecture

The 8-port 10-Gigabit Ethernet (GE) PLIM provides from one to eight 10GE interfaces. The PLIM supports from one to eight pluggable XENPAK
optic modules that provide the 10-GE interfaces for the card. The PLIM
performs Layer 1 and Layer 2 processing for up to eight 10-GE data
streams by removing and adding the proper header information as data
packets enter and exit the PLIM.
Although the PLIM can terminate up to 80 Gbps of traffic, the MSC
forwards traffic at 40 Gbps. Therefore, the PLIM provides 40 Gbps of
throughput, which it passes to the MSC as two 20-Gbps data packet
streams:
Ports 0 to 3 (the upper set of ports) provide 20 Gbps of throughput.
Ports 4 to 7 (the lower set of ports) provide another 20 Gbps of

throughput.
The 8-port 10-GE PLIM consists of:
430
Optic modulesProvides receive (RX) and transmit (TX) optical

interfaces that comply with IEEE 802.3ae. The PLIM supports from
one to eight pluggable XENPAK optic modules, each providing fullduplex long-reach (LR) optics with SC fiber-optic interfaces. Note that
the PLIM automatically shuts down any optic module that is not a
valid type.
Physical interface controllerProvides data packet buffering, Layer 2

processing, and multiplexing and demultiplexing of the 10-GE data
streams, including processing for VLANs and back-pressure signals
from the MSC.
Additional componentsInclude power and clocking components,

voltage and temperature sensors, and an identification EEPROM that
stores initial configuration and PLIM hardware information.
Version 2.0b
CRS-1 Essentials
Module 4
10 Port 10GE PLIM HW Architecture
PLA 0
EgressQ
M
i
d
p
l
a
n
e
Rx PSE
PLA 1
Line card
PHY0
Optics 0
PHY1
Optics 1
PHY2
Optics 2
PHY3
Optics 3
PHY4
Optics 4
PHY5
Optics 5
PHY6
Optics 6
PHY7
Optics 7
8x10GE PLIM
Version 2.0b
431
Module 4
Oversubscription of 10-GE Ports

If more than 2 optic modules are installed in either set of ports,
oversubscription occurs on all ports in that set. For example, if modules are
installed in ports 0 and 1, each interface has 10 Gbps of throughput.
Adding another module in port 2 causes oversubscription on all of the
interfaces (0, 1, and 2).
___________________________CAUTION _______________________
If your configuration cannot support oversubscription, use the
following guidelines to determine which PLIM slots to install
optic modules in.
_________________________________________________________________
Do not install more than four optic modules in each PLIM.
Install the optic modules in any one of the following sets of PLIM slots:
Slots 0 and 1, and 4 and 5
If your configuration can support oversubscription and you want to install

more than four optic modules in a PLIM, we recommend that you install
additional modules in empty slots, alternating between upper and lower
ports. For example, if you install a fifth optic module in an empty slot in
the upper set of ports (0 to 3), be sure to install the next module in an
empty slot in the lower set of ports (4 to 7), and so on.
432
Version 2.0b
CRS-1 Essentials
Module 4
Oversubscription of 10-GE Ports

oversubscription occurs on all ports in that set

interfaces (0, 1, and 2)
Guidelines for avoiding oversubscription:
Do not install more than four optic modules in each PLIM


If operation supports oversubscription and you want more than four optic
modules in a PLIM:
Install additional modules in empty slots, alternating between upper and

lower ports (recommended)
Example: install a fifth optic module in empty slot in upper set of ports (0
to 3)
Be sure to install next module in empty slot in lower set of ports (4 to 7),
and so on
Version 2.0b
433
Module 4
10 Port 10GE PLIM Faceplate

The 8-port 10-GE PLIM has:
434
Eight slots that accept XENPAK optic modules, which provide LR

optics with SC fiber-optic interfaces.
A STATUS LED

correctly
power is on
A LED for each portIndicates that the port is logically active; the
laser is on
Power consumption110 W (with 8 optic modules)
Version 2.0b
CRS-1 Essentials
Module 4
10 Port 10GE PLIM Faceplate
Eight slots that accept XENPAK optic modules, which provide

LR optics with SC fiber-optic interfaces.
STATUS LED

correctly
power is on
A LED for each portIndicates that the port is logically active;

the laser is on
Power consumption110 W (with 8 optic modules)
Version 2.0b
435
Module 4
Shared Port Adapters (SPAs) and SPA Interface Processor-800

(SIP-800)
Overview
SIPs and SPAs are a carrier card and port adapter architecture to increase
modularity, flexibility, and density across Cisco Systems routers for
network connectivity. This section describes the SIP-800 and SPAs and
provides some guidelines for their use.
SPA Interface Processors (SIPs)

The following list describes some of the general characteristics of a SIP:
436
A SIP is a carrier card that is similar to a physical layer interface

module (PLIM), and inserts into a line card chassis slot like any other
PLIM. Unlike PLIMs, SIPs provide no network connectivity on their
own.
A SIP contains subslots, which are used to house one or more SPAs.
The SPA provides interface ports for network connectivity.
During normal operation the SIP should reside in the router fully
populated either with functional SPAs in all subslots, or with a blank
filler plate inserted in all empty subslots.
SIPs support online insertion and removal (OIR), while SPAs are
inserted in their subslots.
Version 2.0b
CRS-1 Essentials
Module 4
Shared Port Adapters (SPAs) and SPA Interface Processor-800 (SIP-800)
SPA Interface Processors (SIPs)

oversubscription occurs on all ports in that set

interfaces (0, 1, and 2)
Guidelines for avoiding oversubscription:
Do not install more than four optic modules in each PLIM


If operation supports oversubscription and you want more than four optic
modules in a PLIM:
Install additional modules in empty slots, alternating between upper and

lower ports (recommended)
Example: install a fifth optic module in empty slot in upper set of ports (0
to 3)
Be sure to install next module in empty slot in lower set of ports (4 to 7),
and so on
Version 2.0b
437
Module 4
SPA Slot Numbering on the Cisco CRS-1 SIP-800

The Cisco CRS-1 SIP-800 accepts six single-height SPAs. The drawing
shows a Cisco CRS-1 SIP-800 with two 4-Port OC-3c/STM-1 POS SPAs
installed in subslots 0 and 3.
____________________________________ Note ________________________________
Subslots 0, 1, and 2 can provide up to 20 Gbps of capacity, as can

subslots 3, 4, and 5. Take care not to install SPAs that require more than 20
Gbps of capacity in each group of subslots so as not to oversubscribe the card.
_________________________________________________________________________
The drawing on the opposite page illustrates the SPA subslot locations on
the Cisco CRS-1 SIP-800. The subslot labels are located inside the SPA
subslot and are only visible when the SPA is not installed.
438
Version 2.0b
CRS-1 Essentials
Module 4
SPA Slot Numbering on the Cisco CRS-1 SIP-800
Version 2.0b
439
Module 4
Shared Port Adapters

The following list describes some of the general characteristics of a SPA:
A SPA is a modular type of port adapter that inserts into a subslot of a

compatible SIP carrier card to provide network connectivity and
increased interface port density. A SIP can hold one or more SPAs,
depending on the SIP type and the SPA size.
SPAs are available in the following sizes:
Single-height SPAInserts into one SIP subslot.
Double-height SPAInserts into two single, vertically aligned SIP

subslots.
Each SPA provides a certain number of connectors, or ports, that are the
interfaces to one or more networks. These interfaces can be individually
configured using the Cisco IOS XR software command-line interface (CLI).
Either a blank filler plate or a functional SPA should reside in every

subslot of a SIP during normal operation to maintain cooling integrity.
Blank filler plates are available in single-height form only.
SPAs support online insertion and removal (OIR). They can be inserted
or removed independently from the SIP. SIPs also support online
insertion and removal (OIR) with SPAs inserted in their subslots.
As of release 3.2 of IOS XR the following are supported:
440
Cisco CRS-1 SIP-800
4-Port OC-3c/STM-1 POS SPA (SPA-4XOC3-POS)
1-Port OC-192c/STM-64 POS/RPR XFP SPA (SPA-OC192POS-XFP)
8-Port Gigabit Ethernet SPA (SPA-8X1GE)
Version 2.0b
CRS-1 Essentials
Module 4
Shared Port Adapters
SPA Bay 0
SPA Bay 1
SPA Bay 2
SPA Bay 3
SPA Bay 4
SPA Bay 5
SPA Bay 1
SPA Bay 2
SPA Bay 4
SPA Bay 5
Double Height
SPA Bays 1 & 4
Double Height
SPA Bays 2 & 5
Double Height
SPA Bays 0 & 3
Double Height
SPA Bays 0 & 3
As of release 3.2 of IOS XR the following are supported:
Cisco CRS-1 SIP-800

4-Port OC-3c/STM-1 POS SPA (SPA-4XOC3-POS)
1-Port OC-192c/STM-64 POS/RPR XFP SPA (SPA-OC192POS-XFP)
8-Port Gigabit Ethernet SPA (SPA-8X1GE)
Version 2.0b
441
Module 4
SPA Interface Addresses on SIPs

SPAs in the Cisco CRS-1 running Cisco IOS XR Software Release 3.2 use
an addressing format that specifies the physical location of the SIP, SPA,
and interface. The interface address format is rack/slot/subslot/port:
rackSpecifies the rack number, 0 in a single-chassis system.
slotSpecifies the slot number in the Cisco CRS-1 in which the SIP that contains
the SPA is installed:
For the 8-slot line card chassis0 through 7
For the 16-slot line card chassis0 through 15
subslotSpecifies the secondary slot on the SIP where the SPA that you want to
select is installed:
For the Cisco CRS-1 SIP-8000 through 5
portSpecifies the interface number that you want to select on the SPA:
For the 4-Port OC-3c/STM-1 PoS SPA0 through 3
For the 1-Port OC-192c/STM-64 PoS/RPR XFP SPA0 is the only

option.
For the 8-Port Gigabit Ethernet SPA0 through 7
A CRS-1 single line card chassis system containing a SIP-800 installed in

PLIM slot 4 with a 4-Port OC-3c/STM-1 PoS SPA installed in subslot 3,
port 2 of that SPA would be addressed as int pos0/4/3/2.
442
Version 2.0b
CRS-1 Essentials
Module 4
SPA Interface Addresses on SIPs
A CRS-1 single line card chassis

system contains a SIP-800 installed
in PLIM slot 4.
A 4-Port OC-3 PoS SPA installed in
subslot 3.
Port 2 of that SPA would be

addressed as int pos0/4/3/2.
Version 2.0b
443
Module 4
SIP Bandwidth Oversubscription

Overview
Oversubscribing the bandwidth limit recommendations of a router can
result in degraded performance. For this reason, it is important to
determine the amount of bandwidth used by the SPAs on the router and
verify that the total bandwidth used by all SPAs does not exceed the
recommended bandwidth limit of the router. It is also important not to
exceed the 40 Gbps total bandwidth of the SIP-800.
The processing on the Cisco CRS-1 SIP-800 is performed by two PLIM
ASICs, each of which can process up to 20 Gbps of traffic. SPA subslots 0,
1, and 3 are associated with one PLIM ASIC, while SPA subslots 2, 4, and
5 are associated with the second PLIM ASIC. The two PLIM ASICs that
reside on the SIP-800 are shown in the architecture drawing on the
opposite page.
If you are using only Gigabit Ethernet SPAs on the Cisco CRS-1 SIP-800,
then the card can be oversubscribed. The Cisco CRS-1 SIP-800 can pass a
maximum of 40 Gbps of traffic, so if you have six 8-Port Gigabit Ethernet
SPAs operating at almost full capacity, the card will be oversubscribed.
If you are using POS SPAs in the Cisco CRS-1 SIP-800, regardless of
whether there are Gigabit Ethernet SPAs installed or not, no
oversubscription is allowed. For this reason, you can install a maximum of
four 1-Port OC-192c/STM-64 POS/RPR XFP SPAs in the Cisco CRS-1 SIP800. Two of them must be installed in subslots 0, 1, or 3; the other two
must be installed in subslots 2, 4, or 5. If you are using 8-Port Gigabit
Ethernet SPAs and 1-Port OC-192c/STM-64 POS/RPR XFP SPAs, you can
install two of each. If you attempt to install a SPA that will oversubscribe
the card, the SPA will not power up, and you will receive an error message.
The table at the bottom of the next page provides information about the
bandwidth for each port (per-port bandwidth) on a SPA, as well as the
cumulative bandwidth (total bandwidth) for all ports available on the SPA.
444
Version 2.0b
CRS-1 Essentials
Module 4
Bandwidth Oversubscription - Overview
SPA0
PLA 0
EgressQ
M
i
d
p
l
a
n
e
SPA1
SPA2
SPA3
PLA 1
Rx PSE
SPA4
SPA5
MSC
SPA
4-Port OC3c/STM-1 PoS
SPA
1-Port OC192c/STM-64
PoS/RpR XFP
SPA
8-Port Gigabit
Ethernet SPA
SIP-800 Jacket Card
Per-Port
Bandwidth
Number of Ports
Total Bandwidth
155.52 Mbps
622.08 Mbps
10Gbbps
10Gbps
1Gbps
8 Gbps
Version 2.0b
445
Module 4
Modular Optics
Some SPAs implement small form-factor pluggable (SFP) optical
transceivers to provide network connectivity. An SFP module is a fiberoptic transceiver device that mounts flush with the front panel to provide
network connectivity.
Cisco Systems qualifies the SFP modules that can be used with SPAs.
_____________________________ Note _________________________

An SFP check is run every time an SFP module is inserted into a SPA
and only SFP modules that pass this check will be usable.
_________________________________________________________________
The types of optics modules that have been qualified for use with the SPAs
supported on the Cisco CRS-1:
4-Port OC-3c/STM-1 POS SPA
SFP-OC3-MM
SFP-OC3-SR
SFP-OC3-IR1
SFP-OC3-LR1
SFP-OC3-LR2
1-Port OC-192c/STM-64 POS/RPR XFP SPA
446
XFP-10GLR-OC192SR
8-Port Gigabit Ethernet SPA
SFP-GE-S
SFP-GE-L
SFP-GE-Z
Version 2.0b
CRS-1 Essentials
Module 4
Modular Optics
Some SPAs use SFP optical transceivers to provide network connectivity

Each time an SPF is inserted into a SPA an SPF check is run & only SPF
modules that pass will be usable
Types of optics modules that have been qualified for use with SPAs
supported on Cisco CRS-1:
4-Port OC-3c/STM-1 POS SPA

SFP-OC3-MM
SFP-OC3-SR
SFP-OC3-IR1
SFP-OC3-LR1
SFP-OC3-LR2
1-Port OC-192c/STM-64 POS/RPR XFP SPA

XFP-10GLR-OC192SR

SFP-GE-S
SFP-GE-L
SFP-GE-Z
Version 2.0b
447
Module 4
4-Port OC-3c/STM-1 SPA

Overview
The 4-Port OC-3c/STM-1 POS SPA is a single-height SPA that installs into
one SIP subslot. The OC-3c/STM-1 POS SPA with small form-factor
pluggable (SFP) optical transceiver modules provides SONET and SDH
network connectivity with a per-port bandwidth of 155.52 Mbps.
4-Port OC-3c/STM-1 PoS SPA Specifications

The framer processes incoming and outgoing SONET or SDH frames. The
framer operates at OC-3c/STM-1 line rates (155.52 Mbps).
Packet data is transported with a user-configured encapsulation (such as
Point-to-Point Protocol [PPP]) and is mapped into the STS-3c/STM-1
frame.
The 4-Port OC-3c/STM-1 POS SPA interface is compliant with the
following RFCs:
RFC 1619, PPP over SONET/SDH
RFC 1662, PPP in HDLC-like Framing
The 4-Port OC-3c/STM-1 POS SPA also provides support for SNMP v1
agent (RFC 11551157) and RFC 1213:
448
RFC 1155, Structure and Identification of Management Information for TCP/IPbased Internets
RFC 1156, Management Information Base for Network Management of TCP/IPBased Internets
RFC 1157, Simple Network Management Protocol (SNMP)
RFC 1213, Management Information Base (MIB) for Network Management of

TCP/IP-Based Internet MIB II.
Version 2.0b
CRS-1 Essentials
Module 4
4-Port OC-3c/STM-1 POS SPA is a single-height SPA that installs into one SIP subslot
OC-3c PoS SPA with SFP optical transceiver provides 155.52 Mbps per-port bandwidth
Data is encapsulated using PPP or HDLC
SPA interface is compliant with:
SPA also provides support for SNMP v1 agent (RFC 11551157) and RFC 1213
Version 2.0b
449
Module 4
4-Port OC-3c/STM-1 SPA LEDs

The 4-Port OC-3c/STM-1 POS SPA has two LEDs for each port on the SPA,
and one STATUS LED for the SPA.
450
Version 2.0b
CRS-1 Essentials
Module 4
4-Port OC-3c/STM-1 LEDs
LED Label
Color
State
C/A
Off
Off
Port is not enabled
Green
On
Port is enabled and there is a valid SONET signal

without Alarms
Amber
Off
On
Off
Port is enabled and there is at least one alarm

Port is not enabled
Green
On
Port is enabled, loopback is off
Amber
On
Port is enabled, loopback is on
Off
Off
SPA power is off
Green
On
SPA is ready and operational
Amber
On
SPA power is on & good; SPA is being configured
A/L
STATUS
Meaning
Version 2.0b
451
Module 4
1-Port OC-192c/STM-64 PoS/RPR XFP SPA

Overview
The 1-Port OC-192c/STM-64 POS/RPR XFP SPA is a single-height SPA
that is installed in a SIP subslot. The 1-Port OC-192c/STM-64 POS/RPR
XFP SPA provides SONET and SDH network connectivity with a
bandwidth of 9.95 Gbps.
The 1-Port OC-192c/STM-64 POS/RPR XFP SPA uses a 10-Gbps small
form-factor pluggable (XFP) optic receptacle for each port allowing
connection to single-mode optical fiber.
1-Port OC-192c/STM-64 POS/RPR XFP SPA Interface Spcifications

The framer processes incoming and outgoing SONET or SDH frames. The
framer operates at OC-192c/STM-64 line rates (9.95 Gbps).
Packet data is transported with a user-configured encapsulation (such as
Point-to-Point Protocol [PPP]) and is mapped into the STS-192c/STM-64
frame.
The 1-Port OC-192c/STM-64 POS/RPR XFP SPA interface is compliant
with the following RFCs:
RFC 2615, PPP over SONET/SDH.
The 1-Port OC-192c/STM-64 POS/RPR XFP SPA also provides support for
SNMP v1 agent (RFC 11551157) and RFC 1213:
452
RFC 1155, Structure and Identification of Management Information for TCP/IPbased Internets
RFC 1156, Management Information Base for Network Management of TCP/IPBased Internets
RFC 1157, Simple Network Management Protocol (SNMP)
RFC 1213, Management Information Base (MIB) for Network Management of

TCP/IP-Based Internet MIB II.
Version 2.0b
CRS-1 Essentials
Module 4
Framer processes incoming and outgoing SONET or SDH frames at OC-192c/STM-64 line rates
(9.95 Gbps)
Packet data is encapsulated in PPP or HDLC and is mapped into STS-192c/STM-64 frame
1-Port OC-192c/STM-64 POS/RPR XFP SPA interface compliant with:

1-Port OC-192c/STM-64 POS/RPR XFP SPA supports SNMP v1 agent (RFC 11551157) and RFC
1213
Version 2.0b
453
Module 4
1-Port OC-192c/STM-64 PoS/RPR XFP SPA LEDs

The 1-Port OC-192c/STM-64 POS/RPR XFP SPA has six LEDs.
_____________________________ Note _________________________

The WRAP, PASSTHRU, and MATESYNC LEDs apply to the SPA in
RPR/SRP mode only. In Cisco IOS XR Software Release 3.2, RPR/SRP
mode is not supported.
_________________________________________________________________
454
Version 2.0b
CRS-1 Essentials
Module 4
1-Port OC-192c/STM-64 PoS/RPR XFP SPA LEDs
LED Label
Color
State
WRAP
Off
Off
Port is not in wrap mode

Port is in warp mode somewhere on ring
PASSTHRU
MATESYNC
CARRIER
Green
On
Amber
On
Port is in wrap mode locally
Off
Off
Port is not in pass thru mode
Amber
On
Port is in pass thru mode
Off
Off
Mate port is not synchronized
Amber
On
Port is not enabled
Off
Off
Port is not enabled
Green
On
Port is enabled; there is a valid SONET signal w/o alarms
Amber
On
Port is enabled; there is at least one alarm (LOS, LOF, RDI)
Blinking
ACTIVE
STATUS
Meaning
Indicates SRP mode mismatch alarm
Off
Off
Port is not enabled
Green
On
Port is enabled; loopback is off
Amber
On
Port is enabled; loopback is on
Off
Off
SPA power off
Green
On
Amber
On
SPA power is on and good; SPA is being configured
Version 2.0b
455
Module 4

Overview
The 8-Port Gigabit Ethernet SPA is a half-height adapter that provides
eight individual 1 Gbps SPF optical interfaces. Each SPF module has a
receiver port (RX) and a transmit port (TX) that composes one optical
interface. The SPF module is an input/output (I/O) device that plugs into
the Gigabit Ethernet optical slots on the 8-Port Gigabit Ethernet SPA,
linking the port with a 1000BASE-X fiber-optic network.
456
Version 2.0b
CRS-1 Essentials
Module 4
8-Port Gigabit Ethernet SPA half-height adapter provides
eight 1 Gbps SPF optical interfaces

Each SPF module has a receiver port (RX) and a transmit
port (TX)
SPF module plugs into GigE optical slots on SPA and
provides link to a 1000BASE-X fiber-optic network
Version 2.0b
457
Module 4
8-Port Gigabit Ethernet SPA LEDs

The 8-Port Gigabit Ethernet SPA has two types of LEDs. There is an A/L
LED for each individual port and one STATUS LED for the SPA.
458
Version 2.0b
CRS-1 Essentials
Module 4
8-Port Gigabit Ethernet SPA LEDs
LED Label
Color
State
Active/Link
Off
Off
Port is not enabled
Amber
On
Port is enabled and link is down
Green
On
Port is enabled and link is up
Off
Off
SPA power is off
Amber
On
SPA power is on and good, SPA is being configured
Green
On
STATUS
Meaning
Version 2.0b
459
Module 4
Summary
460
The features and functions of the CRS-1 MSC
The features and functions of a Distributed Route Processor (DRP) card
The features and functions of each of the PLIMs supported by the Cisco
CRS-1 routing system
The features and functions of the SIP-800 jacket card
The features and functions of each of the SPAs supported by the Cisco
CRS-1 routing system
Version 2.0b
CRS-1 Essentials
Module 4
Review Questions
Version 2.0b
461
Module 4

462
Version 2.0b
CRS-1 Essentials
Module 5
Introduction to Cisco CRS-1 Multi-Shelf
Architecture
Overview
Description
This module provides a high-level overview of the CRS-1 Multi-Shelf
Architecture.
Objectives
List and describe physical components of the Cisco CRS-1 Fabric

chassis
List and describe the three phases of Multi-Shelf configurations
Describe how the CRS-1 Line Card chassis and Fabric chassis are
interconnected with optical cables
List the basic steps to perform and in service upgrade from a standalone to a Multi-Shelf configuration
Describe the CRS-1 Management System Control Plane and SC-GE

card
Version 2.0b
51
Introduction to Cisco CRS-1 Multi-Shelf Architecture
Module 5
Switch Fabric Chassis

Overview
The switch fabric chassis contains the switch fabric (backplane) cards
(SFCs) that provide fully meshed connections between MSCs in each
interconnected line card chassis. The switch fabric cards are the pathways
for the data coming in on the MSCs. The switch fabric is designed to be in
service upgradeable without traffic interruption.
The Switch Fabric chassis is a mechanical enclosure, built around a
midplane, whose main function is to house the switch fabric cards. The
Switch Fabric Chassis is used in all configurations of the CRS-1, from the
3.84 Tbps CRS-1 to the 92 Tbps CRS-1.
The Switch Fabric Chassis is secured to the floor and has locking front and
rear doors. No external racks are required for the installation of a Switch
Fabric chassis. Special care must be taken to ensure the floor space is
correctly provisioned to ensure weight bearing load specifications.
The front of the Switch Fabric chassis contains:
1. Power Shelves
2. Upper fan tray
3. Upper SFC card cage
4. Lower SFC card cage
5. Chassis air filter
6. Lower fan tray
52
Version 2.0b
Module 5
Switch Fabric Chassis - Front
Version 2.0b
53
Module 5
Switch Fabric Chassis Rear View

The rear of the switch fabric chassis is populated with:
1. Power shelves
2. Upper fan tray area (accessible from front)
3. Upper OIM array
4. Lower OIM array
5. Lower fan tray area
The optical interface modules (OIMs) connect through optical cables to the
line card chassis switch fabric cards. 12 optical interface modules sit in the
upper bay and 12 are in the lower bay.
In addition, the upper and lower fan tray assemblies containing the actual
fans which cool the platform are inserted and removed from the front of the
fabric chassis. Space must also be provisioned during installation in order
to allow for card replacement and proper air circulation.
54
Version 2.0b
Module 5
Switch Fabric Chassis Rear View
Version 2.0b
55
Module 5
Switch Fabric Components

Switch Fabric Cards (SFCs)
Up to 24 S2 Switch Fabric Cards (SFCs) are installed in the front side of
the fabric chassis. 12 SFCs are in the upper half and 12 are in the lower
half of the chassis. The SFCs contain the S2 stage ASICs of the switch
fabric used for data switching.
Optical Interface Modules (OIMs)

OIMs are installed in the rear of the fabric chassis. Each OIM terminates
18 switch-fabric optical link cables and mates with 2 S2 cards through the
switch fabric chassis backplane providing a switch fabric chassis with up to
216 switch-fabric connections. 12 of the single width OIMs are installed in
the upper half and 12 OIMs are installed in the lower half of the chassis.
Shelf Controller Gigabit Ethernet Card (SC-GE)

Two shelf controller Gigabit Ethernet cards are installed in the far right
slots in the upper and lower card cages of the fabric chassis. One SC-GE
card is installed in the upper card cage in the right most slots and one SCGE card is installed in the right most slot of the lower card cage. The SCGE cards are the brains of the chassis. They control the management and
the fans which move the air through the chassis.
Fan Tray Assemblies

Upper and lower fan tray assemblies push and pull cooling air through the
chassis. One is located in the bottom half below the SFCs and the second is
located in the upper half above the SFCs. These are installed in the chassis
from the front. The two trays contain retaining screws which can be locked
down for safety.
Alarm Modules
Two alarm modules provide internal system status display. The alarm
modules are located in the AC or DC power shelves and can be inserted or
replaced during router operation.
AC/DC Power
Two AC or two DC Power shelves with AC rectifiers or DC power entry
modules (PEMs) provide either 8,800 Watts (DC) or 10,000 Watts (AC) of
redundant power.
56
Version 2.0b
Module 5
Switch Fabric Cards (SFCs)

Optical Interface Modules (OIMs)
Fan Tray Assemblies
Alarm Modules
AC/DC Power
Version 2.0b
57
Module 5
System Configurations
Standalone
1.2 Terabit Router is a single chassis router containing the MSCs and all
three-stages of the switching fabric. The switch fabric cards contain all
three stages of the switch fabric and are referred to as S1/S2/S3 fabric
cards. This system supports up to 16 MSCs.
Multi-Shelf
The Cisco CRS-1 multi-Shelf systems are comprised of one or more Switch
Fabric chassis connecting two or more Cisco CRS-1 16-slot line card chassis
together to form a routing system. The phases of multi-shelf systems are:
23 Terabit Router18 line card chassis and two switch fabric chassis. This
system supports up to 288 MSCs.
46 Terabit Router36 line card chassis and 4 switch fabric chassis
supports up to 576 MSCs.
92 Terabit Router72 line card chassis and 8 switch fabric chassis
supports up to 1152 MSCs.
58
Version 2.0b
Module 5
STANDALONE CONFIG (1.2Tbps)

8/16 MSC and PLIM slots
No Fabric chassis required
S1/2/3 Fabric Cards in Line card chassis
MULTI-SHELF CONFIG (1.2T TO 92T)

2 to 72 Line card chassis
1 to 8 fabric chassis
Version 2.0b
59
Module 5
Three Phases of Switch Fabric Chassis Releases

The switch fabric chassis will have three release phases with capacity
doubling from phase-to-phase.
Phase 1
The number of supported switch fabric chassis that can be interconnected
with line card chassis to form 1 CRS-1 functioning router, can be 1 or 2.
In phase 1 2 switch fabric chassis can connect a maximum of 18 line card
chassis. As such the overall capacity of the system is 23 Tbps.
Phase 2
Phase 2 will support up to 4 switch fabric chassis. In phase 2, the
maximum number of supported 36 line card chassis, thus a total capacity
of 46 Tbps.
Phase 3
Phase 3 will support up to 8 switch fabric chassis. In phase 3 there will be
up to 72 line card chassis interconnected through up to 8 switch fabric
chassis thus a total capacity of 92 Tbps.
510
Version 2.0b
Module 5
Three Phases of Switch Fabric Chassis Releases
Phase 1
Interconnects:
1 or 2 Switch Fabric Chassis

1 to 18 Line Card Chassis
Overall capacity of fabric 23 Tbps (1.280Gbps * 18)

Phase 2
Interconnects:
Up to 4 switch fabric chassis

Up to 36 line card chassis
Total capacity of 46 Tbps

Phase 3
Interconnects:
Up to 8 switch fabric chassis

Up to 72 line card chassis
Total capacity of 92 Tbps
Number of
Number of
Fabric Chassis supported
Line Card
chassis
1
up to 6
Maximum
number of
slots
Maximum
capacity
96
7.68 Tbps
up to 18
288
23 Tbps
up to 36
576
46 Tbps
up to 72
1152
92 Tbps
Version 2.0b
511
Module 5
Switch Fabric Chassis Interconnections

Optical cables
Switch fabric chassis are connected to line card chassis through optical
fiber cables. This allows data coming into the line card chassis to be
processed and forwarded across any of the fabric chassis and then out
another port on another MSC interface, all with only one IP hop and
lookup.
User data will pass over the optical cables from chassis to chassis. An out
of band Gigabit Ethernet network is used for system control and
management and all traffic generated for this remains separate from user
traffic.
_____________________________ Note _________________________
To identify the chassis purchased the midplane NVRAM is used to
store tracking number and manufacturing information, as well as MAC
addresses. Software will store the chassis ID value in the midplane
NVRAM and can be displayed for inventory identification.
_________________________________________________________________
512
Version 2.0b
Module 5
Switch Fabric Chassis Interconnections optical cables
Optical cables are used to

interconnect LC through SFC
IP data passing from one LC

to another though the SFC is
considered one IP hop
Inter-chassis Management
System Control Plane traffic
does not pass through
optical cables
Midplane NVRAM is used to

store:
Tracking numbers
Manufacturing information
MAC addresses
Version 2.0b
513
Module 5
Optical Cables
Line card chassis must be connected to fabric chassis in multi chassis
configurations. Cables used for interconnection are Cisco proprietary
cables that can link up to 72 chassis together to form a very high speed
router. The cables bundles are 100 meters in length.
The cables are made up of multiple bundles, ribbons and fibers as follows:
Each bundle is made up of 6 ribbon cables. Each ribbon cable has 12
fibers. Thus, each bundle has 72 fibers.
1 Bundle = 6 ribbon cables * 12 fibers/cable
Each line card chassis has 8 fabric cards. Each fabric card has bundle
connections. Thus, each line card chassis has 24 bundles.
1 line card chassis = 8 SFC * 3 bundles/card = 24 bundles/chassis
Each fabric card chassis has 24 fabric cards SFCs. Each SFC has 9
bundle connections. Thus, a switch fabric card terminates up to 216
bundles.
1 Switch fabric chassis = 24 SFCs * 9 bundles = 216 bundles
Fiber Bundle
12 fibers per cable
6 ribbon cables per bundle
(72 fibers per bundle)
100 meters max length
Connections per Line Card chassis
3 bundle connections per fabric card
8 fabric cards
24 bundles or connections
Connections per Fabric Card Chassis
514
24 fabric cards
Version 2.0b
Module 5
Switch Fabric Chassis Interconnections (Cont.)
Fiber Bundle
12 fibers per cable

6 ribbon cables per bundle
(72 fibers per bundle)
Connections per Line Card chassis:

8 fabric cards
Connections per Fabric Card Chassis
Multiple Bundles
Between LC Chassis
And FC Chassis
9 bundle connections / fabric card

24 fabric cards
Optical Interface Modules
Version 2.0b
Full Utilized Fabric Chassis
515
Module 5
In-service upgrade from Standalone to Multi-Shelf

In a standalone CRS-1 system there are 8 planes of switch fabric, 1 plane
per S123 switch fabric card in the 16-slot chassis and 2 planes of switch
fabric per HS123 switch fabric card in the 8-slot chassis. Only 7 of the 8
switch fabric planes are needed to carry the traffic load of a fully
configured standalone linecard chassis, the 8th switch fabric plane is there
solely for redundancy.
To perform an in-service upgrade from a standalone 16-slot linecard
chassis to a multi-shelf system you need to ensure that the switch fabric
chassis with the appropriate number of S2 switch fabric cards and optical
cables are installed and operational.
General upgrade procedure:
1. Shutdown 1 S123 switch fabric card in the linecard chassis
2. Replace the S123 switch fabric card, from step 1, with an S13 switch
fabric card
3. Connect the optical cable from fabric chassis to S13 switch fabric card
_____________________________ Note _________________________
LED on the rear of the Switch Fabric Chassis fabric module will
illuminate when the cable is properly connected.
_________________________________________________________________
4. Bring up that configuration and verify the system operation
5. Repeat steps 1 through 4 for each fabric plane and linecard chassis you
wish to interconnect into the multi-shelf system
516
Version 2.0b
Module 5
Ensure switch fabric chassis has appropriate number of S2 cards

and optical cables installed and operational
General upgrade procedure:
1. Shutdown 1 S123 switch fiber card in the linecard chassis

2. Replace the S123 switch fiber card, from step 1, with an S13
switch fiber card
3. Connect the optical cable to S13 switch fiber card

4. Bring up that configuration and verify the system operation
5. Repeat steps 1 through 4 for each fabric plane and linecard
chassis you wish to interconnect into the multi-shelf system
Version 2.0b
517
Module 5
CRS-1 Management System Control Plane and Shelf Controller

Gigabit Ethernet (SC-GE) card
CRS-1 Management System Control Plane
There are two of CRS-1 management system control planes:
Inter-chassis
The inter-chassis GE control plane is a system management plane that
allows management information, control signaling, statistics gathering, to
be passed from one chassis to another in a multi-chassis system
configuration. The key elements of the Inter-chassis control plane are:
Cisco 6509 Catalyst switch
RP Route Processor contains 2 Dedicated GE ports on the RP for

connection to the GE management network.
SC-GE Shelf Controller Gigabit Ethernet card. This provides

management functionality for the Fabric Chassis much like the RP
does for the Line Chassis.
Intra-chassis
The intra-chassis (or within one chassis) management plane uses the
100Mbps FE internal bus that allows the RP and the MSC to communicate
within the CRS-1, to pass alarms, statistics and routing information back
and forth. The elements that make up the intra-chassis plane are:
MSC CPU Used to manage the MSC, gather stats, load IOS XR, run
diags
RP Route Processor which runs routing protocols (BGP, OSPF, IS-IS),

Network Mgt, manages the LC chassis. 2 dedicated slots per LC chassis
_____________________________ Note _________________________

Loss of the external Ethernet management does not directly correlate
to a system down state. However, management traffic will stop flowing
and the error condition should be repaired as soon as possible.
_________________________________________________________________
518
Version 2.0b
Module 5
card
CRS-1 Management System Control Plane and Shelf Controller Gigabit Ethernet (SC-GE)
CRS-1 Management System Control Plane
Inter-chassis
GE Network
Line Card chassis

RP
LC
Intra-chassis
FE
RP
LC
Gig Ether
Switch
Line Card chassis

RP
Optional 10 GE
LC
FE
RP
LC
Key Components
RP LC
SC-GE FC
SC-GE
S2
Switch Fabric
chassis
Gig Ether
Switch
FE
Dedicated GigE switches

for inter-chassis control
network
SC-GE
Version 2.0b
S2
519
Module 5

The SC-GE card is the central point of control within the Fabric Chassis.
At least one SC-GE card must be operational at all times for a chassis to
function as part of the system. The SC-GE card functions as the main
system processor for the Fabric Chassis and provides the following
essential functions:
Configuration
Provides out-of-band system console and auxiliary ports
Management
Two GigE ports for router configuration and maintenance.
It monitors and manages power and temperature of system components

such as fabric cards, power supplies, and fans
Maintains access to the file system found on the IDE disk
Redundancy
Redundant SC-GE card can be installed in every chassis, so that loss or

removal of any single SC-GE card does not bring down a chassis.
The SC-GE card instructs individual SPs to power up nodes provides code
images for each card to download, and resets any node that it determines is
unresponsive. The designated Shelf Controller (dSC) is a single control and
arbitration point in the chassis, and determines master and standby DRP
board status when necessary. The SC-GE card hardware provides the
following control plane services:
520
FE connectivity between all nodes in the chassis and the control plane
via Broadcom 5606 switch.
Dual external GE connectivity via Broadcom 5605 switch.
FE connectivity between master/standby SC-GE card pairs, which

provides a path for SC-GE card state synchronization.
PCMCIA slot for flash memory disk to update software images, 1 GB

flash cards planned.
Presences detect circuitry which allows the SC-GE card CPU to read a
vector of currently inserted cards, interrupts CPU on change in
presence vector (OIR event).
Arbitration circuitry which selects a master and standby SC-GE card

according to firmware ready and SC-GE card presence data.
Reset circuitry which allows the SC-GE card to reset any single card in
the chassis. Reset outputs active only on master SC-GE card.
Version 2.0b
Module 5
card
CRS-1 Management System Control Plane and Shelf Controller Gigabit Ethernet (SC-GE)
LC FE
Links
B
A
C
K
P
L
A
N
E
CTL GE link
CTL GE link
FE/GE
Switch
PCI
IDE
CPU
MEM
CTL
Aux & Console

Mgmt GE link
FLASH
Version 2.0b
FLASH
521
Module 5
Summary
522
How to list and describe physical components of the Cisco CRS-1 Fabric
chassis
How to list and describe the three phases of Multi-Shelf configurations
How the CRS-1 Line Card chassis and Fabric chassis are
interconnected with optical cables
How to list the basic steps to perform and in service upgrade from a
stand-alone to a Multi-Shelf configuration
How to describe the CRS-1 Management System Control Plane and SCGE card
Version 2.0b
Module 6
Cisco IOS XR Overview and Initial
Configuration
Overview
Description
This module introduces you to the Cisco IOS XR software architecture, the
High-Availability (HA) features, and the software packaging model. This
module shows you the basics of Cisco IOS XR software and how to create
an initial configuration.
Objectives
After completing this module, you will be able to:
Describe the Cisco IOS XR modular software architecture
Describe Cisco High-Availability architecture
Describe Cisco IOS XR scalability
Describe the configuration file system
Describe login access
Describe command modes
Describe management addressing
Describe an initial configuration
Version 2.0b
61
Cisco IOS XR Overview and Initial Configuration
Module 6
Cisco IOS XR Architecture

Cisco IOS XR software is modular by design, with each layer performing a
separate set of tasks. Layers communicate with each other through the
kernel using standard message-passing application programming interface
(API).
Kernel
Cisco IOS XR software has core system functions, such as process
management, interprocess communication (IPC), memory management,
interrupt, and scheduling. Other system functions become services and run
above the kernel. User or client applications also run above the kernel with
the kernel acting as a sort of traffic director.
Distributed Infrastructure
The kernel is replicated across the router infrastructure. The services and
client applications can be distributed across the router infrastructure for
both standalone and multi-shelf hardware configurations. The
infrastructure includes route processors (RPs), distributed route processors
(DRPs), service processors (SPs), shelf controllers (SCs), modular service
cards (MSCs), and line cards (LCs).
Services
Services are composed of one or more processes which may be running on
the same or different CPUs. Each process has a memory-protected space.
Each process can have multiple threads all accessing the same address
space.
62
Version 2.0b
Module 6
Routing
modules
(BGP, OSPF)
Runs on
multiple
CPUs
Protocol
modules
(IP)
Application
modules
Distributed infrastructure
Cisco IOS XR kernel
Version 2.0b
63
Module 6
High Availability
High availability in the Cisco routing systems is a combination of
hardware redundancy, and the software and operational components that
take advantage of that hardware.
Components
64
Kernel
Plane separation
Fault tolerance and isolation
Checkpoint support for process restart
Process-level redundancy
Route processor and distributed RP failover
Nonstop forwarding
Version 2.0b
Module 6
High Availability
High Availability Components
Kernel
Plane separation
Fault tolerance and isolation
Checkpoint support for process restart
Process-level redundancy
Route processor and Distributed RP failover
Nonstop forwarding
Instructor's Note
Do not spend a lot of time here! This is an intro and the points are detailed on the following
slides.
Version 2.0b
65
Module 6
Kernel
The QNX Neutrino microkernel has these main features:
Multiprocessor
Small memory footprint
Memory protection
Preemptive fast context switch times
Reliabilityindependent component load/control
Portable Operating System Interface (POSIX)
In the Cisco IOS XR architecture, processes run in their own separate

process spaces. Almost every process can be started, stopped, or off-loaded
to another node or processor. Failures in processes do not affect the
operation of other processes.
66
Version 2.0b
Module 6
High Availability
Kernel
Memory-protection, message-passing, pre-emptive

Modular software design
All basic OS and router functionality implemented as
processes
Process model with separate, protected address

spaces
Applications
PO
Microkernel:
Distributed processing
File system
Lightweight messaging
Event management
Threads
C
I
S
S
I
X
Message queues
Scheduling
Debug
Timers
Synchronization
Instructor's Note
POSIX is a set of standard OS interfaces based on UNIX. The need for standardization arose
because enterprises using computers wanted to develop programs that could be moved among
different manufacturer's computer systems without recoding. Unix was selected as the basis for a
standard system interface partly because it was "manufacturer-neutral." However, several major
versions of Unix existed so there was a need to develop a common denominator system.
Informally, each standard in the POSIX set is defined by a decimal following the POSIX.
POSIX.1 is the standard for an application program interface in the C language. POSIX.2 is the
standard shell and utility interface. POSIX.1 and POSIX.2 interfaces are included in a somewhat
larger interface known as the X/Open Programming Guide. POSIX interfaces were developed
under the IEEE.
Version 2.0b
67
Module 6
Plane Separation
Processes can be tailored toward particular applications. Routing and
forwarding are separated, creating a clear separation of control, data, and
management planes. The control processes can be distributed across
multiple route processors (RPs) or distributed route processors (DRPs). If
desired, MPLS processes could run on another DRP altogether.
Cisco IOS XR software is partitioned into three planes:
ControlDistributes routing tasks and management of the Routing

Information Base (RIB) in participating RPs; different routing
processes can be running on different physical units
DataMaintains the Forwarding Information Base (FIB) changes

across the participating nodes letting the router perform as a single
forwarding entity
ManagementControls the operation of the router as a single

networking element
Each plane is easily extensible using the dynamic link library (DLL)
mechanism. Such structure allows for better fault isolation and protection
among the planes. Planes can be distributed among multiple participating
processors (nodes). Distribution provides for process placement and
restartability, giving a high level of service availability so that failures do
not seriously impact router operation. All processes can be check-pointed,
so if a process fails, it can be restarted quickly or the redundant process
can take over faster.
68
Version 2.0b
Control plane
Control Plane
Control plane
Control Plane
IS-IS RIP
BGP
OSPFIS-IS
RIP
Routing policy
OSPFIS-IS
PIM
Routing
Policy
OSPF
IGMP PIM
Routing Policy
RIB IGMP
PIM
RIB IGMP
L2 drivers
ACL
RIB
L2 Drivers
FIB ACL
L2 Drivers
QoS FIB
ACL
LPTSQoS
FIB
Host services
LPTSQoS
PFI Services
Host
LPTS
Interfaces
PFI Services
Host
CLI
Interfaces
PFI
SNMPCLI
Interfaces
XMLSNMP
CLI
Netflow
XMLSNMP
Alarm
Netflow
Perf. mgmt. XML
Alarm
Netflow
SSH
Perf. Mgmt.
Alarm
SSH
Perf. Mgmt.
BGP
RIP BGP
Control plane
Process mgmt

Data plane
Data plane
Data plane
IPC mech.
Memory mgmt.
Version 2.0b
Management plane
SSH
Module 6
High Availability
Plane Separation
Distributed subsystems/processes
Management plane
Management plane
e
rn
ke
o
cr
Mi
H/W abstraction
System services
Memory-protected microkernel
69
Module 6
Fault Tolerance and Isolation

The fault tolerance of Cisco IOS XR software is based on its layered
architecture. The separate layer and module independence within each
layer provides fault isolation.
The planes (data, control, and management), applications, and processes
are separated so that the failure of one module has no influence on the
modules of the other layers. Furthermore, a process failure within one
software plane does not affect other processes or applications within that
plane.
This layered architecture creates a more reliable model than one with a
monolithic architecture, where failure of a single module may cause failure
of the whole system.
610
Version 2.0b
Module 6
High Availability
Fault Tolerance and Isolation
Control
plane
Data
plane
Management
plane
Cisco IOS XR
Layered rather than monolithic architecture
Fault isolation and protection between the

planes
Instructor's Note
This slide is animated. It starts with IOS XR and Layered. Click 1 control plane; click 2 data
plane; click 3 management plane; click 4 arrow and Fault isolation.
Version 2.0b
611
Module 6
Checkpoint Support for Process Restart

Cisco IOS XR software supports individual process restart on the active RP
by using a checkpoint database called shared memory store.
On regular intervals, current running process state information is written
to the database, where it is stored in case a process fails.
If a process does fail, it is restarted and the information contained in the
checkpoint shared memory store is read to create a recovery state.
612
Version 2.0b
Module 6
High Availability
Checkpoint Support for Process Restart
Process
Updates of running state
(Process fails)
New
instance
of
process
Checkpoint
shared
memory
store
Recover state
Active RP/DRP
Instructor's Note
There is a limitation on the number of times a process will restart. The limitation settings are
programmed in and not available to the user. This is to prevent a looping process restart scenario.
Version 2.0b
613
Module 6
Process-Level Redundancy
Process-level redundancy is implemented by a system manager process
creating the standby process. Because the active process created the
standby process, the active process has all the information it needs to
communicate (privately) with the standby process. Symbolic links and
abstract names are used to identify the processes. Clients do not see the
standby process until the active goes away.
If a process fails and it has created a standby process, a system-level
process called QNet Symlink Manager (QSM) and a library called Event
Connection Manager (ECM) are used to reestablish links from the clients
to the processes.
QSM provides:
Distribution of symbolic link information
Abstract name for a process or service
ECM provides:
Common information for connecting processes and services
Detection of broken connections
_____________________________ Note _________________________

Only processes considered essential by development engineers are
designed to support process-level redundancy; this is not a userconfigurable option.
_________________________________________________________________
614
Version 2.0b
Module 6
High Availability
Process-Level Redundancy
Active service-providing process

Active
Client
process
Client
Standby
process
Standby process
Client
Active process uses a
checkpoint database to
share running state
with standby
Clients use active serviceproviding process
Instructor's Note
Instructor emphasis on the note!
The checkpoint database is left out of this picture in the interest of simplicity. The previous page
explains that process.
The process level redundancy discussion continues to the next page.
Version 2.0b
615
Module 6
Clients have to reconnect to the new active process (the original

standby process) when they detect that the active process has failed.
Because the existence of the active process was effectively hiding the
standby process, the standby process becomes uncovered and clients can
connect to it using the symbolic links and abstract names. The new active
process creates a new standby process; the active process has all the
information it needs to provide the new standby process with the updates.
The general steps in process redundancy are:
1. The active process dies
2. The standby process becomes the active process
3. A new standby process starts
4. The new active process begins sending updates to the new standby
process
5. Clients begin using the new active process through the symbolic links
and abstract names
616
Version 2.0b
Module 6
High Availability
Process-Level Redundancy (Cont.)
1. Active process fails

Active
process
2. Standby process
becomes active
Client
New active
Client
Standbyprocess
process
4. New active starts sending

updates to standby process
3. New standby
process is started
Client
5. Clients use new active

service-providing process
Instructor's Note
Animated starts w/ Active process and clients with arrows. Then follows each step 1 click 1
step
Version 2.0b
617
Module 6
Process Restart and RecoveryRP Failure

There are a variety of ways of restarting or recovering a process when the
active RP fails; here are some examples:
618
Process
Checkpoint data status
Sent to the standby card continuously; process A' is

running in the background
Mirrored to the standby card; process B' is not running;

this process uses a checkpoint proxy process to receive
checkpoint information
No checkpointing of data; process C' can start on the

standby card without saved state information
No checkpointing of data; no process running on the

standby card
Version 2.0b
Module 6
High Availability
Process Restart and RecoveryRP Failure
Active card
Standby card
Process A
Process A
1
Process B
Process B
2
Process C
Process D
Checkpt
process
1
2
Checkpt
process
1.
Process A: checkpoint data sent to standby peer continually
2.
Process B: checkpoint data mirrored to standby card
3.
Process C: no checkpointing - process C' started on standby card
4.
Process D: no checkpointing - no process D' started on standby card
Version 2.0b
Process C
619
Module 6
Route Processor and Distributed Route Processor Failover

Failover is provided through the use of paired route processors (RPs) or
distributed route processors (DRPs).
A feature or protocol is considered High Availability-aware if it, either
partially or completely, maintains undisturbed operation through an RP
failover. For some HA-aware protocols and applications, state information
is synchronized (checkpointed) from the active processor to the standby
processor. All Layer 2 and Layer 3 tables and interface states are
maintained during switchover.
All configurations are made on the active RP; they are automatically
synchronized to the standby RP. Moreover, line cards continue forwarding
packets during the switchover.
RPs are automatically paired by Cisco IOS XR software during bootup.
DRPs are automatically paired if they are placed in slots 2 and 3, 4 and 5,
or 6 and 7 during bootup. DRPs, unlike RPs, can be unpaired by the user
through configuration. If no standby RP is available, there is no
checkpointing.
620
Version 2.0b
Module 6
High Availability
Route Processor and Distributed Route Processor Failover
DRP failure
RP failure
Active DRP
Active RP
Checkpointed
Checkpointed
If no standby
DRP exists,
no
checkpointing
Standby DRP
Not
checkpointed
Standby RP
Active DRP
Instructor's Note
For clarification this slide is animated. The If no SDRP line and the accompanying arrow is
the animation based on the mouse click. When either an active RP or DRP, with a properly
configured standby, fails, the standby takes over. In the case of the DRP, a standby may not be
installed, and therefore no checkpointing.
Version 2.0b
621
Module 6
Nonstop Forwarding
The main objective of Cisco nonstop forwarding (NSF) is to continue
forwarding IP packets following a route processor (RP) switchover. NSF
works with the stateful switchover (SSO) feature to minimize the time a
network is unavailable to its users following a switchover. Cisco NSF helps
to suppress route flaps, thus reducing network instability.
Cisco NSF is supported by the BGP, OSPF, IS-IS, and MPLS protocols for
routing and by Cisco Express Forwarding (CEF) for forwarding. The
routing protocols, enhanced with NSF capability and awareness, can detect
a switchover and take the necessary action to continue forwarding network
traffic and recover route information from peer devices.
The IS-IS protocol can be configured to use state information, that has
been synchronized between the active and standby RPs, to recover route
information following a switchover, rather than information received from
peer devices.
Each protocol depends on CEF to continue forwarding packets during
switchover while the routing protocols rebuild the Routing Information
Base (RIB) tables. After the routing protocols have converged, CEF
updates the Forwarding Information Base (FIB) table and removes
outdated route entries. CEF, in turn, updates the MSCs with the new FIB
information.
622
Version 2.0b
Module 6
High Availability
Nonstop Forwarding
Paired RPs or DRPs
Active
RP
Each LC has dedicated

packet forwarding
hardware (SPP)
Packet forwarding is not
Control
updates
interrupted
affected by:
ISIS, OSPF, BGP, MPLS,
Active
RP
Multicast process restart

Infrastructure process
restarts
RP failover
LC
LC
But
Fwding
Ok!
Instructor's Note
Animated slide with 4 clicks: 1 Active RP goes down; 2 control updates arrow appears; 3
standby becomes active; 4 forwarding arrow and words appear
SPP Silicon Packet Processor
This slide can be used to explain how NSF and SSO operates
Version 2.0b
623
Module 6
Scalability
A key feature of Cisco IOS XR is its scalability, providing complete
distributed processing of routing protocols, data forwarding plane,
management plane, and infrastructure services to support carrier-class
router systems such as the Cisco CRS-1 Routing System.
Features
624
Adjacency management
Forwarding Information Base tables
Distributed interface management
Distributed configuration management
Two-stage forwarding
Version 2.0b
Module 6
Scalability
Scalability Features
Adjacency management
Forwarding Information Base tables
Distributed interface management
Distributed configuration management
Two-stage forwarding
Version 2.0b
625
Module 6
Adjacency Management
An adjacency is a mapping of the next-hops Layer 3 address to the Layer 2
rewrite needed to get the packet to the next-hop. In traditional Cisco
routers, adjacency management is done in the RP.
With Cisco IOS XR software, the adjacency control plane runs in the MSC
and not in the RP. Adjacency management is done locally on every card for
interfaces resident on that card. One MSC does not know about adjacencies
on other MSCs. The RP does not keep any adjacency information; it pulls it
from the MSC when you request the information.
The ingress MSC, the receive adjacency table contains the destination
address and associated parameters to get the packet to the egress modular
services card or line card, based on the forwarding information found in the
Forwarding Information Base (FIB) tables.
The egress MSC, the transmit adjacency table contains the layer-2 rewrite
to be applied on the packet before sending it out.
626
Version 2.0b
Module 6
Scalability
Adjacency Management
RP
Interface
manager
Modular
services
card (MSC)
ARP/Map
tables
Adjacency
Information
Base
Instructor's Note
Emphasis: the MSC (CRS-1) and line cards (XR 12000) know only about the locally / directly
attached hosts and peers
Version 2.0b
627
Module 6
Two-Stage Forwarding
What is two-stage forwarding?
Forwarding of packets is done in two stages. When a packet arrives as the

ingress MSC, only enough information is used to send the packet to the
outbound MSC.
When the packet arrives at the egress point, a deeper lookup is performed
to determine the outbound port and the necessary adjacency information.
Why use two-stage forwarding?
The purpose of two-stage forwarding is scaling. Cisco IOS XR software is

available to large-scale systems with large numbers of modular service
cards or line cards, and interfaces. Each MSC must have the forwarding
information limited to speed up the actual packet forwarding. Using this
method allows limiting of Layer 2 adjacency information.
For security implementations, access control lists (ACLs) can be applied on
both the ingress and egress MSCs or line cards.
628
Version 2.0b
Module 6
Scalability
Two-Stage Forwarding
What is two-stage forwarding?
Forwarding lookup is done twice

Ingress side Lookup returns information to forward packet to
correct outbound MSC and physical interface
Egress side Lookup gets correct interface and adjacency

information
Why two-stage forwarding?
Scaling
With the number of cards/interfaces in a CRS-1, the amount of
forwarding information for each MSC must be limited
Entire Layer 2 adjacency information is not required on all

cards
Example: Feature scaling
Input ACLs on ingress cards

Output ACLs on egress cards
Version 2.0b
629
Module 6
Forwarding Information Base

The Forwarding Information Base (FIB) is both a data store, and a process.
The FIB stores routing, or path, information in a format suitable for
forwarding packets. Each path has a next-hop interface and a next-hop
ip address, and points to an adjacency associated with it in the adjacency
information base (AIB). The FIB process manages and populates the
forwarding table in the Packet Switch Engine (PSE).
Each route processed by the Routing Information Base (RIB) has
forwarding information for its paths, which it passes to the FIB. Paths are
inserted into the FIB and set to point to the corresponding next-hop
adjacency.
630
Version 2.0b
Module 6
Scalability
Forwarding Information Base
RP or DRP
MSC-CPU
AIB
OSPF
RIB
ISIS
Switch fabric
BGP
FIB
process
MSC-PSE
Ifmgr
Hardware
FIB
Static
routes
Version 2.0b
631
Module 6
Distributed Interface Management

Cisco IOS XR software uses distributed interface management (DIM). The
interface manager processes reside on the RPs and the line cards. The
processes communicate using an interprocess communication (IPC).
Interface drivers are located on each MSC. The interface manager process
on the MSCs interacts with the interface manager process on the RP.
The RP has summary state information for all interfaces in the system.
This state information is passed on to the standby RP, is maintained
during switchover, and is updated in the FIB tables so that packets
destined for down interfaces are dropped at ingress. The Stateful SwitchOver (SSO) function synchronizes the processes, applications, interfaces
states, and FIBs on the RP and standby RP.
The Interface Manager (IfMgr) on an MSC does not know about interfaces
on other MSCs; each IfMgr is concerned only with the local interfaces. All
MSCs can manage their interfaces in parallel; the RP only holds the
overall view.
Interface management processes user commands; for example, the shut/no
shut and other commands, and statistics collection.
632
Version 2.0b
Module 6
Scalability
Distributed Interface Management
RP
Interface driver
Interface manager
Interface manager
global database
MSC
Interface manager
MSC
Interface manager
Interface driver
Interface driver
Interfaces
Interfaces
Version 2.0b
633
Module 6
Distributed Configuration Management

In Cisco IOS XR software, configuration management is split between the
RP and the MSCs. The RP has a summary of the configuration
information, while each MSC has their individual complete configuration.
The configuration is kept in system database called the Sysdb, which is a
Unix-like namespace. The Sysdb stores configuration and application
operational data. Each node of an IOS XR system has its own data store,
containing the local configuration and operational data.
There are multiple distributed database servers; each holding part of the
total namespace. Access to the Sysdb is handled by three processes:
Shared common information for the entire system
Admin administrative information about the system
Local locally relevant information for that node
Each RP has all three processes. The shared and admin processes are only
active on the primary RP. Each process maintains its own data store. A
replicator process copies data from the primary Sysdb to servers on other
RPs.
Each MSC has an active local process only since packet forwarding uses
only local data. Sysdb clients on the MSC use only the local server process;
IPC to other processes is minimized.
634
Version 2.0b
Module 6
Scalability
Distributed Configuration Management
RP
Configuration manager
MSC
MSC
L2/L3
applications and
H/W drivers
L2/L3
applications and
H/W drivers
Hardware
Hardware
Version 2.0b
635
Module 6
Configuration Operations
Two-Stage Configuration
Cisco IOS XR introduces a two-stage configuration method.
In the first stage, you make, change, add to, or subtract from the running
configuration of the router, creating a target configuration. The running
configuration is not affected. The configuration is entered, the syntax is
checked for correctness, and then stored, discarded, or applied.
In the second stage, you commit the target configuration and make it part
of the running configuration.
Cisco IOS XR also has XML APIs, which compose an interface that can be
used to configure the router. Companies can write applications to obtain
billing, error, traffic, and policing information through the XML interface.
Stage 1: Making Configuration Changes

Here are the steps in stage 1:
1. The CLI configuration mode is entered using one of the following
commands, config or config exclusive.
The exclusive keyword prevents other logged-in users from making
configuration changes during the configuration operation. All
configurations commands entered at this stage have no effect on the
router operation. Commands entered do not take effect upon entry of a
carriage return <CR> as in IOS.
2. The CLI parser (which runs every time configuration commands are
entered) checks all commands for valid syntax.
3. The configuration command is written to the target configuration.
4. The entered configuration can be verified, and ensure that it is correct,
or that configuration can be discarded, before entering the second
stage.
Stage 2: Making Configuration Changes Persistent

When configuration mode is exited the router asks if you want to commit
the configuration changes, that is, make the target configuration the
running configuration.
636
Version 2.0b
Module 6
Two-Stage Configuration
First stage
Second stage
Config database
Router#> Config t
Config agents
CLI/XML
Running config +
commit
Target
config
Config changes
Running config
New running config
Stage 1: Make configuration changes
Create new target config by entering config
Stage 2: Make changes persistent
Instructors Note
This slide is animated in 2 steps.
Click 1 shows all stage 1 elements
Click 2 shows all stage 2 elements
Version 2.0b
637
Module 6
Configuration File System

The configuration file system (CFS) is a set of files and directories used to
store the router configuration state.
___________________________CAUTION _______________________
The files and directories in the CFS are internal to the router and you
should never modify or remove them; doing so may result in the loss of the
configuration and affect service.
_________________________________________________________________
The CFS is stored on the default media on the RP (disk0:), using the
directory structure:
disk0:/config/
An exact copy of the CFS is also maintained on the standby RP. The copy
helps preserve the router configuration state during and after a
redundancy switchover.
Saving Configuration Changes
Every time a configuration change is committed, a new binary file is

created that saves the new router configuration. The router automatically
boots with the last configuration committed. Maintaining the configuration
information in binary format allows for faster bootup times.
___________________________ Warning ________________________
Although possible, changing the configuration bootup method
and using a startup file (ASCII) is not recommended. To do this,
certain ROMMON variables must be set to bypass normal
router operation.
_________________________________________________________________
638
Version 2.0b
Module 6
Configuration File System
New binary
configuration
created; router uses
it to boot up
following reload
IOS XR
Running config
plus changes
Version 2.0b
RP disk0:
639
Module 6
Access and Login

To operate or configure a router running Cisco IOS XR software, you must
first connect with the router using a terminal or PC. Connections are made
either directly through a physical connection (console port) on the active
RP or remotely through a modem or an Ethernet connection.
After a connection is established, enter your assigned username and
password, as shown on the slide.
During the initial startup of a router, the root-system username and
password is set. This root-system user has the authority to create
additional users.
640
Version 2.0b
Module 6
Access and Login
User Access Verification

Username: <username>
Password: <password>
RP/0/RP0/CPU0:P1#
IOS XR router access:
Direct connection to console port

Terminal server connected to the console port
Telnet or SSH (v1 or v2)
Login
Root-system user defined at initial install

Assigned username and password
Version 2.0b
641
Module 6
Command Modes
The CLI for Cisco IOS XR software is divided into different command
modes. Each mode provides access to a subset of commands used to
configure, monitor, and manage the router.
642
EXEC modeLogging in to router running Cisco IOS XR software

automatically places you in EXEC mode. This mode enables a basic set
of commands to view the operational state of the router and examine
the state of an operating system. Minimal privileges also include a
small set of EXEC commands for connecting to remote devices,
changing terminal line settings on a temporary basis, and performing
basic tests.
Configuration modeConfiguration mode is the starting point for

system configuration. Commands entered in this mode affect the
system as a whole, rather than just one protocol or interface.
Configuration mode is also used to enter configuration submodes to
configure specific elements, such as interfaces or protocols.
Version 2.0b
Module 6
Command Modes
Login
EXEC mode
Configuration modes
Version 2.0b
643
Module 6
Configuration Basics
Management IP Interfaces
IP addresses for out-of-band management purposes are assigned to:
Ethernet ports on RPs
The IPv4 virtual address
The Management Ethernet ports (MgmtEth interfaces) on the RPs are

commonly connected to the same subnet and assigned unique addresses in
that address space. Although this is not required for proper operation of
the Management Ethernet, the design and utility of the IPv4 virtual
address assumes this scenario.
644
Version 2.0b
Module 6
Management IP Interfaces
Cisco CRS-1 Management

Ethernet interfaces
MgmtEth0/RP0/CPU0/0
MgmtEth0/RP1/CPU0/0
Management
network
connections
Version 2.0b
645
Module 6
The IPv4 virtual address is primarily used for out-of-band management

over the Management Ethernet. Its IP address is typically assigned in the
same subnet as the Management Ethernet ports on the RPs. The IP virtual
address always maps to the MAC address of the Ethernet port on the
currently active RP. Because it survives RP switchover, it functions as an
always available, out-of-band management address without depending on
any routing protocol on the Management Ethernet.
IP addresses for in-band management purposes are typically assigned to a
loopback interface. A loopback interface provides an always available
address, as long as there is any path through the data network to the
router.
_____________________________ Note _________________________
The show ip interface command displays loopback addresses but not the
IPv4 virtual address. Both addresses appear in the Routing Information
Base RIB. However, the IPv4 virtual address appears in the Address
Resolution Protocol (ARP) table while a loopback address does not, since it
is not associated with any physical interface.
_________________________________________________________________
646
Version 2.0b
Module 6
Management IP Interfaces (Cont.)
IPv4 virtual address
Host address on management

network
Must be on same subnet as
Ethernet management interfaces
Provides sustainable MAC
address in the event of RP

failover
Only for management
Loopback interfaces
Version 2.0b
647
Module 6
Configuring Management Ethernet

To configure the Management Ethernet interface, you must enter interface
configuration mode and identify the location of the Management Ethernet
interface instance.
The Cisco CRS-1 RP cards contains an Ethernet port. You configure
Management Ethernet interfaces for the redundant Cisco CRS-1 RP pair.
Indirectly, you use the Management Ethernet interface to access the RP
card and any other card within the router. The RPs are present in pairs as
active and standby redundant cards in case of switchover. The active and
standby RPs can be user configured. The interface of the standby card is
visible and active if configured with an IPv4 address even while the card is
in standby mode.
648
Version 2.0b
Module 6
Configuring Management Ethernet
RP/0/RP0/CPU0:router#configure
RP/0/RP0/CPU0:router(config)#interface MgmtEth0/RP0/CPU0/0
RP/0/RP0/CPU0:router(config-if)#ipv4 address 12.9.42.105/16
RP/0/RP0/CPU0:router(config-if)#no shut
RP/0/RP0/CPU0:router(config-if)#
Interface mode
Set the IP version
IPv4 or IPv6 address

Mask
Activate the interface
Version 2.0b
649
Module 6
Configuring Loopback Address

IP addresses for in-band management purposes are typically assigned to a
loopback interface. A loopback interface provides an always available
address so long as there is any path through the data network to the
router.
The loopback address is configured as an interface with an assigned IP
address.
650
Version 2.0b
Module 6
Configuring Loopback Address
RP/0/RP0/CPU0:router(config)#interface loopback0 12.9.42.110/16

Interface command
Assign IP address
Visible as interface
Version 2.0b
651
Module 6
Configuring IP Virtual Address

An IP virtual address defines a management address that is persistent
across RP failovers. The IP virtual address must be in the same subnet as
the Management Ethernet addresses. The router will associate the IP
virtual address with the MAC address of the active RP.
_____________________________ Note _________________________
The IP virtual address will appear in the RIB and the configuration
file. It will not show when displaying IP interfaces.
_________________________________________________________________
652
Version 2.0b
Module 6
Configuring IP Virtual Address
RP/0/RP0/CPU0:router(config)#ipv4 virtual address 12.9.42.125/16

RP/0/RP0/CPU0:router(config)#
IPv4 command
Assign IP address
Only visible in RIB
Version 2.0b
653
Module 6
Hostname
The hostname identifies a router on the network. Although devices can be
uniquely identified by their Layer 2 and Layer 3 addresses, such as an IP
address, it is often simpler to remember network devices by a hostname.
This name is used in the CLI prompt, in default configuration filenames,
and to identify the router on the network.
To configure the hostname, enter the hostname command in global
configuration mode, followed by the name of the router.
654
Version 2.0b
Module 6
Hostname
RP/0/RP0/CPU0:router(config)#hostname P1
RP/0/RP0/CPU0:router(config)#
Create a hostname
Version 2.0b
655
Module 6
Configuring Network Interfaces

Interfaces connected to other routers are configured from global
configuration mode.
For POS interfaces, the timing source must be set before turning up the
interface. To do this you configure the SONET controller:
1. Enter controller mode
2. Set the clock source to internal
When the timing has been set on the SONET controller:
1. Enter interface submode for the specific POS interface
2. Set the IP address
3. Activate the interface
656
Version 2.0b
Module 6
Configuring Network Interfaces
RP/0/RP0/CPU0:router(config)#controller sonet 0/4/0/0

RP/0/RP0/CPU0:router(config-sonet)#clock source internal
RP/0/RP0/CPU0:router(config-sonet)#exit
RP/0/RP0/CPU0:router(config)#interface POS 0/4/0/0
RP/0/RP0/CPU0:router(config-if)#ipv4 address 12.9.44.5/24
RP/0/RP0/CPU0:router(config-if)#no shut
Set clock source first

Controller
Interface command
Rack/slot/module/port
Assign IP address
Activate the interface
Version 2.0b
657
Module 6
Committing the Configuration

To commit the configuration changes while keeping the configuration
session active, you must use the commit command. This is an all or
nothing acceptance of the configuration changes to the running
configuration, sometimes called an atomic commit.
During the commit operation, the active configuration is automatically
locked by the router for the duration of the commit process, even if you
have not already locked it.
658
Version 2.0b
Module 6
Committing the Configuration
RP/0/RP0/CPU0:router(config)#commit
RP/0/RP0/CPU0:P1(config)#
Target changes must pass semantics
Pass; all changes are committed

Fail; no changes are committed
Version 2.0b
659
Module 6
Exiting and Ending Configuration Mode

The exit command ends each level (or submode) of the configuration
session. If there are uncommitted changes when exiting configuration
mode, you are prompted to commit them or reject them.
The end command finishes the configuration session immediately. If there
are uncommitted changes when exiting configuration mode, you are
prompted to commit them or reject them.
In each case, cancel is the default response to the question of committing
the changes. If you do want to commit the changes to the running
configuration, you must respond by typing yes.
660
Version 2.0b
Module 6
Exiting and Ending Configuration Mode
Exit configuration mode

RP/0/RP0/CPU0:P1#configure
RP/0/RP0/CPU0:P1(config)#interface pos 0/5/0/1 pos crc 16
RP/0/RP0/CPU0:P1(config-if)#exit
RP/0/RP0/CPU0:P1(config)#exit
Uncommitted changes found, commit them before exiting(yes/no/cancel)?
[cancel]:yes
RP/0/RP0/CPU0:P1#
End configuration mode

RP/0/RP0/CPU0:P1#configure
RP/0/RP0/CPU0:P1(config)#interface pos 0/5/0/1 pos crc 16
RP/0/RP0/CPU0:P1(config-if)#end
Uncommitted changes found, commit them before exiting(yes/no/cancel)?
[cancel]:yes
RP/0/RP)/CPU0:P1#
Press Enter or type "no" to exit or end without committing changes

Type "yes" for changes to take effect
Version 2.0b
661
Module 6
Display the Active Configuration

The running configuration is the active configuration used to operate the
router; that is, the committed configuration that defines the router
operations.
The show running-config command displays the details of the active, or
currently running, configuration.
You can see specific parts of the current configuration by using additional
parameters, such as:
interfacedisplays the interfaces
router protocoldisplays the routing protocol specified
usernamedisplays the users configured
These and other parameters are available to minimize the amount of

information you display, particularly with a large router configuration.
662
Version 2.0b
Module 6
Display the Active Configuration
RP/0/RP0/CPU0:P1(config)#show running-config
Building configuration...
!! Last configuration change at 15:57:39 UTC Wed Jun 16 2004 by cisco
!
hostname P1
Additional messages are not shown
interface MgmtEth0/RP0/CPU0/0
ipv4 address 12.9.42.105 255.255.0.0
!
interface POS0/4/0/0
ipv4 address 142.50.12.5 255.255.255.0
!
ipv4 address 142.50.16.5 255.255.255.0
end
Display entire running configuration

Display by like groups (Interfaces, routing protocols)
Version 2.0b
663
Module 6
Displaying the Target Configuration

The target configuration is all the uncommitted changes made in the
current configuration session.
The show config command, entered while in configuration mode, displays
items configured in the current configuration session. These changes have
been entered, but not yet committed.
_____________________________ Note _________________________
To display configuration changes or the target configuration, you must
enter commands while still in configuration mode.
_________________________________________________________________
664
Version 2.0b
Module 6
Display the Target Configuration
RP/0/RP0/CPU0:P1(config)#show config
ipv4 address 142.50.48.5 255.255.255.0
!
ipv4 address 142.50.36.5 255.255.255.0
pos
crc 16
!
!
end
Version 2.0b
665
Module 6
Displaying the Merged Configuration

The show config merge command displays the merged target
configuration and the running configuration. This command displays what
the running configuration would be after the target configuration is
committed.
666
Version 2.0b
Module 6
Display the Merged Configuration
RP/0/RP0/CPU0:P1(config)#show config merge

hostname P1
interface MgmtEth0/RP0/CPU0/0
ipv4 address 12.9.42.105 255.255.0.0
!
ipv4 address 142.50.12.5 255.255.255.0
!
ipv4 address 142.50.16.5 255.255.255.0
ipv4 address 142.50.48.5 255.255.255.0
!
ipv4 address 142.50.36.5 255.255.255.0
pos
crc 16
!
!
end
Version 2.0b
Added
667
Module 6
Summary
Cisco IOS XR Overview
In this module, you learned to:
668
Describe the Cisco IOS XR modular software architecture
Describe Cisco High-Availability architecture
Describe Cisco IOS XR scalability
Describe the configuration file system
Describe login access
Describe management addressing
Describe an initial configuration
Version 2.0b
Module 6
Review Questions
Version 2.0b
669
Module 6

670
Version 2.0b
Module 7
Cisco IOS XR Operations
Overview
Description
This module introduces you to the Cisco IOS XR configuration features,
including making, checking, and verifying changes; rolling back
configurations; and troubleshooting configurations.
Objectives
Describe the file system and node addressing
Explain configuration processes
Describe other configuration considerations
Explain the configuration rollback process
List storage media
Describe file commands
Describe help commands
Describe process commands
Version 2.0b
71
Module 7
Cisco IOS XR Command Modes

The CLI for Cisco IOS XR software is divided into different command
modes. Each mode provides access to a subset of commands used to
configure, monitor, and manage the router.
Logging in to a router running Cisco IOS XR software automatically places
you in EXEC mode. This mode enables a basic set of commands to view the
operational state of the router and examine the state of an operating
system. Minimal privileges also include a small set of EXEC commands for
connecting to remote devices, changing terminal line settings on a
temporary basis, and performing basic tests.
From EXEC mode you have access to configuration mode for most router
configuration work. You also have access to Admin mode to do software
installation, logical router and multi-chassis work.
72
Version 2.0b
Module 7
Login
EXEC mode
Admin EXEC mode
Configuration modes
Admin configuration mode
Version 2.0b
73
Module 7
Configuration Modes
Configuration modeConfiguration mode is the starting point for

system configuration. Commands entered in this mode affect the
system as a whole, rather than just one protocol or interface.
Configuration mode is also used to enter configuration submodes to
configure specific elements, such as interfaces or protocols.
Configuration submodesFrom the configuration mode, you can

enter other, more-specific command modes. These modes are available
based on your assigned access privileges and include protocol-specific,
platform-specific, and feature-specific configuration modes.
POS configuration submodePOS configuration submode is used to

configure such things as CRC and transmit-delay.
Router configuration submodeRouter configuration submode is

used to select and configure a routing protocol, such as BGP, OSPF or
IS-IS.
74
Router submode configurationRouter configuration submodes

are accessed from the router configuration mode.
Username, User Group, Task Group configuration submodes

From these submodes, you configure users, and non-default user and
task groups to set access privileges.
Version 2.0b
Module 7
Configuration Modes
Configuration mode
Interface config submode
Create router
pos config submode
configurations
Perform router
Router config submode
operations
Address family config

submode
User and Task group config

submode
Version 2.0b
75
Module 7
Administration Modes
Administration mode is currently used to configure multiple logical routers
(LRs) and to install the Cisco IOS XR software.
76
Admin EXECEnter the admin EXEC mode from EXEC mode. The
admin EXEC mode applies primarily to logical routers. When logical
routers have been configured, EXEC mode provides visibility into only
one logical router, so you must enter administration EXEC mode to see
all system parameters. You install packages and update software from
administration EXEC mode, too.
Admin configurationEnter admin configuration (admin config)

mode from admin EXEC mode. This modes primary application is to
configure logical routers and control individual card slots. For example,
you can turn power to a slot on and off. For logical routers, this mode is
used primarily to display system-wide parameters, configure the
administration plane over the control Ethernet, and configure LRs on
multiple-chassis systems.
Logical router configurationTo specify a logical router (LR) to be

provisioned and enter LR configuration mode
Version 2.0b
Module 7
Administration Modes
Admin EXEC mode

Admin configuration mode
Logical router configuration
submode
Software installations
Logical router management
Version 2.0b
77
Module 7
Command Mode Samples

Here are some sample illustrations of the prompt syntax and some
commands used to enter various modes.
78
Version 2.0b
Module 7
Command Mode Samples
EXEC
RP/0/0/CPU0:P4#
Global
config:
RP/0/0/CPU0:P4#configure
RP/0/0/CPU0:P4(config)#
Submode and
Interface
config:
RP/0/0/CPU0:P4(config)#interface pos 0/2/0/0

RP/0/0/CPU0:P4(config-if)#
Protocol and
submode
config:
RP/0/0/CPU0:P4(config)#router bgp 140

RP/0/0/CPU0:P4(config-bgp)#address-family ipv4
RP/0/0/CPU0:P4(config-bgp-af)#
Admin
RP/0/0/CPU0:P4#admin
RP/0/0/CPU0:P4#(admin)#
Instructor's Note
This slide is animated. The instructor needs to click/Enter to see each example except the first.
Version 2.0b
79
Module 7
Cisco CRS-1 Hardware Node Locations

In Cisco IOS XR software, many CLI commands allow you to identify the
location of the node to which actions apply.
The syntax for this location is a node ID, where the node ID is entered as
rack/slot/module. The node ID the processing module that runs the
commands. For instance, on the Cisco CRS-1 routers, this module is the
CPU or service processor (SP) on the card that runs the CLI commands.
The slide shows the node ID definitions for rack/slot/module:
710
rack is always 0 in a Cisco CRS-1 single-shelf system
slot is the number of the physical slot where the card is installed
module is the CPU or SP on the card that runs the commands
Version 2.0b
Module 7
Cisco CRS-1 Hardware Node Locations
Rack number
Slot = Physical
slot of card
Card Type
Module = CPU0 or SP
Rack
Slot
Module
Route processor
071
RP0/RP1
CPU0
Modular services card
071
015
CPU0, SP
Switch fabric module
071
SM0SM7
SP
Alarm card
071
AM0AM1
SP
Fan controller card
071
FC0FC1
SP
Instructor's Note
The MSC actually has both the CPU0 and SP processors. From the EXEC mode you can only see
processes attributed to CPU0 when using the show process location command. You will see the
SP (and only the SP, not CPU0) processes from Admin mode when using the same command.
Version 2.0b
711
Module 7
Command-Line Interface Prompt Syntax: Cisco CRS-1 Routing System

When logging into a Cisco CRS-1, you are accessing the active route
processor (RP) card.
The prompt at which Command-Line Interface (CLI) commands are issued
is shown on the opposite page and is described as follows:
712
The first position, or type, indicates the interface or card you are
connected to
The second position, or rack, indicates the shelf number; a single-shelf

system is always 0, while multishelf systems are numbered from 0 to
71
The next position, or slot, represents the slot in which the primary RP
is located; for the CRS-1, the physical slot is either RP0 or RP1
The next position, or module, is the entity on the card that actually
runs the user commands. For the RP, this is CPU0
The last position is the name assigned to this router, typically defined
during initial configuration with the hostname command
Version 2.0b
Module 7
Command-Line Interface Prompt Syntax: Cisco CRS-1 Routing System
RP/0/RP0/CPU0:router
Direct terminal
connection
RP = Route processor card

0 = Single-rack chassis or 1st
rack in multishelf chassis
RP# = Either RP0 or RP1

CPU0 = Always the same
router = router name
Management
network
connection
Version 2.0b
713
Module 7
Configuration Considerations
Consider additional configuration steps before putting the router into
service.
Domain Name and Domain Name Server
Configure a domain name and domain name server (DNS) for your router
to make contacting other devices on your network more convenient.
Telnet, HTTP, and XML Services
For security, all host services are disabled by default, but you can:
Enable the Telnet server, so you can log in to the router using IPv4 or
IPv6 Telnet clients
Enable the HTTP server, so you can log in to the router using the CWI
Enable the XML agent, which in turn enables XML Common Object
Request Broker Architecture (CORBA) agent services so that you can
manage and configure the router using an XML interface
Router Clock
Generally, if the system is synchronized by a valid outside timing

mechanism, such as a Network Time Protocol (NTP), you do not need to set
the software clock. Use the clock set command for initial configuration or
when a network time source is not available. The clock timezone
command should be entered before the clock is set manually because it
establishes the system time relative to Coordinated Universal Time (UTC).
The system internally keeps time in UTC, so this command is used only for
display and when the time is manually set.
Logging
System messages generated by Cisco IOS XR software can be logged in a

variety of locations, based on the severity level of the messages. For
example, you can direct information messages to the system console and
also log debugging messages in a network server. In addition, you can
define correlation rules that group and summarize related events, generate
complex queries for the list of logged events, and retrieve logging events
through an XML interface.
714
Version 2.0b
Module 7
Configuration Considerations
Domain name and domain name server assignment
Access convenience
Telnet, HTTP, and XML services
Log on to router through either IPv4 or IPv6 Telnet clients
HTTP for Craft Works Interface
XML for CORBA management and configuration access
Router clock
Not necessary if using NTP
Logs
Location to send error messages

Correlate messages based on severity
Version 2.0b
715
Module 7
Locking and Unlocking the Running Configuration

You can control critical changes to the router by using the lock and unlock
feature of the Cisco IOS XR software.
When you place the router in global configuration mode with the
configure command, a new target configuration is automatically created.
More than one user can open a target configuration session at a time,
allowing multiple users to work on separate target configurations.
By default, the running configuration is locked whenever a commit
operation is being performed. This automatic locking ensures that each
commit operation is completed before the next one begins. Other users
receive an error message if they attempt to commit a target configuration
while another commit operation is under way.
Locking the Configuration
Sometimes, locking the router configuration is useful to prevent changes by

other users while you are entering your changes. When you first enter
configuration mode, use the config exclusive command to lock the router.
This lock denies other users the ability to commit changes while your
configuration session is active. Other users can still enter global
configuration mode and populate a target configuration, but they cannot
commit those changes to the running configuration until you exit your
exclusive configuration session.
Unlocking the Configuration
After the configuration session is over, you exit the session. This exit
causes the session to become unlocked. At this point, the router can be
configured by other users.
716
Version 2.0b
Module 7
Locking and Unlocking the Running Configuration
CLI
Config
database
Running
config
RP/0/RP0/CPU0:routername#configure exclusive
RP/0/RP0/CPU0:routername(config)#hostname P4
RP/0/RP0/CPU0:routername(config)#commit
Instructor's Note
Might be used for critical configuration changes.
Exclusive or locking prevents other users from committing changes; it does not prevent them
from entering the config context. Other users can commit changes once you have exited config
exclusive mode.
Other changes being made by other users do not show up in your own configuration because
each session is unique. Changes made by others are not committed to the router when you
commit your own changes.
Version 2.0b
717
Module 7
Preconfiguration
Preconfiguration lets you configure physical interfaces before they are
inserted into the router. Preconfigured interfaces are not verified or
applied until the actual interface with the matching location
(rack/slot/module) is inserted into the router. When the anticipated
MSC/PLIM, or LC, is inserted and the interfaces are created, the
precreated configuration information is verified and, if successful,
immediately applied to the routers running configuration.
The preconfiguration information is created in a different system database
tree, called the preconfiguration directory on the RP.
_____________________________ Note _________________________
Only physical interfaces can be preconfigured.
Do not enter the no shutdown command for new preconfigured
interfaces because the no command removes the existing configuration.
Specifying an interface name that already exists and is configured (or
an abbreviated name like e0/3/0/0) is not permitted.
The option keyword is not validated against the type of the interface
that is getting preconfigured.
_________________________________________________________________
You are expected to provide names during preconfiguration that match the
name of the interface that will be created. If the interface names do not
match, the preconfiguration cannot be applied when the interface is
created. The interface names must begin with the interface type that is
supported by the router and for which drivers have been installed.
718
Version 2.0b
Module 7
Preconfiguration
Prior to
installing line
card, its
configuration
can be entered
Configure resources not yet

present
Reduce down time
Improve operational tasks
CLI
Prior to the LC being inserted
Select the interface

Configure the timing (SONET controller)
Configure the framing
Configure the IP address
RP/0/0/CPU0:P4#config
RP/0/0/CPU0:P4(config)#interface preconfigure POS 0/4/1/0
RP/0/0/CPU0:P4(config-if-pre)#ip address 1.1.1.1 255.255.255.0
RP/0/0/CPU0:P4(config-if-pre)#encapsulation ppp
RP/0/0/CPU0:P4(config)#controller preconfigure sonet 0/4/0/0 clock source line
Version 2.0b
719
Module 7
Clear Target Configuration Changes

The clear command allows you to discard all uncommitted changes made
to a router configuration. This discard eliminates all changes made since
entering configuration mode.
720
Version 2.0b
Module 7
Clear Target Configuration Changes
RP/0/0/CPU0:P4(config)#interface pos 0/5/0/1 pos crc 16
RP/0/0/CPU0:P4(config-if)#ipv4 address 142.50.36.1 255.255.255.0
RP/0/0/CPU0:P4(config-if)#show config
ipv4 address 142.50.36.1 255.255.255.0
pos
crc 16
!
End
RP/0/0/CPU0:P4(config)#clear
RP/0/0/CPU0:P4(config)#show config
end
Version 2.0b
721
Module 7
Saving a Target Configuration

While you are in configuration mode, you may want to save the
configuration you are presently working on without committing it. To do
this, use the show config command, followed by a pipe symbol, followed
by the word, file, followed by the location and file name.
You may now exit configuration mode without saving your changes, or
clear this configuration and start another one.
722
Version 2.0b
Module 7
Saving a Target Configuration Commands
RP/0/0/CPU0:P4(config)#username ed
RP/0/0/CPU0:P4(config-un)#password ed
RP/0/0/CPU0:P4(config-un)#group root-system
RP/0/0/CPU0:P4(config-un)#show config | file disk0:ed
[OK]
RP/0/0/CPU0:P4(config-un)#
Save target configuration commands to specific file
Version 2.0b
723
Module 7
Loading a Target Configuration

If you have previously saved a configuration you were creating, you can
return to that configuration by loading it into configuration mode. You can
make any additions or corrections to the configuration and then implement
it using the normal commit process.
724
Version 2.0b
Module 7
Loading a Target Configuration Commands
end
RP/0/0/CPU0:P4(config)#load disk0:ed
Loading.
57 bytes parsed in 1 sec (56)bytes/sec
username ed
password 7 110C1D
group root-system
!
end
File has been saved as a target configuration

Loaded file becomes the target configuration
Version 2.0b
725
Module 7
Abort Configuration Mode

Like the clear command, the abort command cancels changes you have
made. However, this command discards all uncommitted changes and
returns you directly to EXEC mode. No warning is given before the
configuration changes are cancelled.
726
Version 2.0b
Module 7
Abort Configuration Mode
RP/0/0/CPU0:P4(config)#interface pos 0/5/0/1 pos crc 16
RP/0/0/CPU0:P4(config-if)#abort
RP/0/0/CPU0:P4#
Ends the configuration session immediately
No warning before deletion of changes
Version 2.0b
727
Module 7
Failed Configuration Commands

The default method of committing changes is atomic, which signifies an
all or nothing type of configuration, where a semantic error in one part of a
configuration prevents any of the configuration commands from being
committed.
The configuration commands that fail to pass semantic verification during
the commit process are known as failed configurations. When a
configuration commit fails, the target configuration is left intact and
nothing is promoted to an active configuration. An error message is
generated to indicate a problem has occurred.
The failed configuration commands can be viewed by entering the show
config failed command.
Another type of commit can be used called best effort. This type of
commit will implement the parts of the configuration that are semantically
correct and will not implement the part of the configuration that is
incorrect. An error message is generated in this case also and the failed
part of the configuration can be viewed using the show config failed
command.
728
Version 2.0b
Module 7
Failed Configuration Commands
Configuration commit entry fails
View causes of failures
RP/0/0/CPU0:P4(config)#taskgroup bgp
RP/0/0/CPU0:P4(config-tg)#hostname P4xyz
RP/0/0/CPU0:P4(config)#commit
% Failed to commit one or more configuration items.
Please use 'show configuration failed' to view the errors
RP/0/0/CPU0:P4(config)#show config failed
!! CONFIGURATION FAILED DUE TO SEMANTIC ERRORS
taskgroup bgp
!!% Usergroup/Taskgroup names cannot be taskid names
!
Configuration commit entry fails
View causes of failures
RP/0/0/CPU0:P4(config)#taskgroup bgp
RP/0/0/CPU0:P4(config-tg)#hostname P4xyz
RP/0/0/CPU0:P4(config)#commit best-effort
% Failed to commit one or more configuration items.
Please use 'show configuration failed' to view the errors
RP/0/0/CPU0:P4xyz(config)#show config failed
!! CONFIGURATION FAILED DUE TO SEMANTIC ERRORS
taskgroup bgp
!!% Usergroup/Taskgroup names cannot be taskid names
!
Partial
configuration!
RP/0/0/CPU0:P4xyz(config)#
Version 2.0b
729
Module 7
Configuration Checkpoint and Rollback

Each time a new configuration is committed, Cisco IOS XR software adds a
commit change record (or checkpoint) to the configuration database, logs a
history entry, and generates a configuration-change notification using
syslog.
Each configuration commit point is assigned a unique identifier so that it
can be tracked in the database. Each point is dated and time-stamped and
lists the user who committed it. You can display the configuration changes
that were made at each point.
The history log is an audit trail that allows you to track who made changes
to the router and when. The database is a recovery and convenience
feature; it permits you to go back to a previously working configuration
should a newer configuration present problems (or for any other reason).
730
Version 2.0b
Module 7
Configuration Checkpoint and Rollback
Config database
Running config
Target config
commit
Each commit generates record

with CommitID or label
Each CommitID is a rollback

point
Commit database stores up to 100
Config log
CommitID# 100
CommitID# 099
CommitID# 098
CommitID# 001
rollback points
Version 2.0b
731
Module 7
Display Configuration Changes

Configuration changes can occur at different stages as part of the
running configuration, failed, or removed when a software package is
removed. It is also possible to see when changes were committed and what
those committed changes actually were. We can manage configuration
sessions.
The show config command has these keywords that provide additional
information:
732
commitShow what was committed in a particular commit
failedCommands that failed in a commit
removedParts of the running configuration that were taken out

when a software package was deactivated. Software packages provide
commands to the CLI parser as part of the installation. These
commands would be removed during deactivation, so the commands
would be removed from the running configuration, also
rollbackWhen changes are committed to the running configuration

of the router a point is established to provide a method of recovering
from those changes should it be required
running-configShows the same information as the command show

running-config, that is the configuration currently controlling the
resources of the router
sessionsManage and deactivate configuration sessions
Version 2.0b
Module 7
Display Configuration Changes
RP/0/RP1/CPU0:P4#show config ?
commit
Show commit information
failed
Contents of failed configuration
removed
Display configuration removed during package
(de)activation.
rollback
Show rollback information.
running-config Current operating configuration
sessions
Users with active configuration sessions
Version 2.0b
733
Module 7
Display Stored Configuration Commits

Configuration commits are stored in a configuration database.
The list of the most recent committed configuration changes made can be
viewed. The number is limited to either 100, or those changes made since
the last reboot. This list is displayed by using the show config commit
list command. The list contains:
SNoSequence number of the change list
Label/IDIdentifier assigned to this change
UserLogged on user who committed the changes
LineMethod used to connect to the router
ClientTool used to make the changes
Time StampTime and date of the change
The configuration database actually contains a historical record of up to

1000 committed changes made on the router. These records contain the
minimum information described above.
Instructor's Note
Attempts to display changes prior to last boot, or beyond the 100 in the change database, result in
an error message
734
Version 2.0b
Module 7
Display Stored Configuration Commits
RP/0/RP1/CPU0:P4#show config commit list

SNo. Label/ID
User
Line
Client
~~~~ ~~~~~~~~
~~~~
~~~~
~~~~~~
1
1000000167 cisco
con0_RP1_C CLI
2
1000000166 cisco
vty0
CLI
3
1000000165 cisco
vty0
CLI
4
1000000164 cisco
con0_RP0_C CLI
5
doug
cisco
con0_RP0_C CLI
6
1000000162 cisco
con0_RP0_C CLI
7
1000000161 cisco
con0_RP0_C CLI
Time Stamp
~~~~~~~~~~
05:40:54 PST
10:22:27 PST
10:13:15 PST
13:24:39 PST
13:17:51 PST
12:52:10 PST
12:51:02 PST
Wed
Mon
Mon
Thu
Thu
Thu
Thu
Mar
Feb
Feb
Feb
Feb
Feb
Feb
02
28
28
24
24
24
24
2005
2005
2005
2005
2005
2005
2005
Time Stamp
~~~~~~~~~~
10:22:27 PST
10:13:15 PST
13:24:39 PST
13:17:51 PST
12:52:10 PST
12:51:02 PST
11:06:20 PST
17:17:58 PST
10:11:59 PST
07:26:12 PST
03:27:26 PST
03:27:01 PST
Mon
Mon
Thu
Thu
Thu
Thu
Thu
Tue
Tue
Thu
Thu
Thu
Feb
Feb
Feb
Feb
Feb
Feb
Feb
Feb
Feb
Feb
Feb
Feb
28
28
24
24
24
24
24
15
15
03
03
03
2005
2005
2005
2005
2005
2005
2005
2005
2005
2005
2005
2005
Maximum of 100
Actual changes are viewable
RP/0/RP1/CPU0:P4#show config commit history

SNo. Label/ID
User
Line
Client
~~~~ ~~~~~~~~
~~~~
~~~~
~~~~~~
1
1000000166 cisco
vty0
CLI
2
1000000165 cisco
vty0
CLI
3
1000000164 cisco
con0_RP0_C CLI
4
doug
cisco
con0_RP0_C CLI
5
1000000162 cisco
con0_RP0_C CLI
6
1000000161 cisco
con0_RP0_C CLI
7
1000000160 cisco
con0_RP0_C CLI
8
1000000159 cisco
con0_RP0_C CLI
9
1000000158 cisco
con0_RP0_C CLI
10
1000000157 cisco
0.0.0.0
Rollback
11
1000000156 cisco
con0_RP0_C CLI
12
1000000155 cisco
con0_RP0_C CLI
List of last 1000 committed changes
Version 2.0b
735
Module 7
Display Committed Changes

The actual configuration commands made at each commit point are from
the list that is provided by the show config commit list command
described previously. You can see these changes by using the show config
commit changes command, followed by the Label/ID.
There are two variations of the command that provide information about
multiple changes that have been made. The first variation uses the last n
keyword. All the changes made in the number requested are shown
inclusively.
The list keyword can be extended to include the additional information, as
show here:
RP/0/1/CPU0:P4# show config commit list 2 detail | ?
begin
Begin with the line that matches
exclude
Exclude lines that match
file
Save the configuration
include
Include lines that match
Instructor's Note
Last change is #168; previous change is #167; prior change is #166
736
Version 2.0b
Module 7
Display Committed Changes
Display specific committed changes

RRP/0/0/CPU0:P4#show config commit changes doug
username doug
password 7 110D161010
!
end
RP/0/0/CPU0:P4#show config commit changes 1000000163
username doug
!
end
RP/0/0/CPU0:P4#show config commit changes 1000000167
username doug
group root-system
Added
group cisco-support
!
end
Same
Display last n changes

RP/0/0/CPU0:P4#show config commit changes last 2
username doug
group root-system
Previous change
group cisco-support
!
xml agent corba
Last change
http server
end
RP/0/0/CPU0:P4#show config commit changes last 3

config-register 0x2
Prior change
username doug
group root-system
Previous change
group cisco-support
!
xml agent corba
http server
Last change
end
Version 2.0b
737
Module 7
Another way you might use to see the changes made recently would be to
show the changes since a particular change. You would do this by using the
keyword, since Label/ID. This command is inclusive, also. The changes are
not shown in the order of their order of commitment, but are displayed in
the order they would appear in the running configuration.
738
Version 2.0b
Module 7
Display Committed Changes (Cont.)
Display changes since specified CommitID/Label
Ordered for router configuration

Not in change order
RP/0/0/CPU0:P4#show config commit changes since doug

config-register 0x2
Change # 166
username doug
Change # 163/doug
group root-system
Change # 167
group cisco-support
!
username jeff
Change # 164
password 7 1213001114
!
no redundancy disable
Change # 165
xml agent corba
Change # 168
http server
end
Instructor's Note
Previous page changes were in the same order as the numbers or so it appeared; however this
display is on the same order as the running configuration. Reminder, the running configuration is
actually a binary file that is interpreted when you use the show command
Version 2.0b
739
Module 7
Display Rollback Information

The show config rollback changes command displays committed
changes and what the commands would be if you were to roll these changes
back. In most cases the display would show the reversal of the change
referenced.
The command uses the following keywords:
lastFollowed by a number value
toFollowed by the Label/ID
Each of these keywords is inclusive.
740
Version 2.0b
Module 7
Display Rollback Information
RP/0/RP1/CPU0:P4#show config rollback changes last 1

username doug
no group root-system
no group cisco-support
!
end
config-register 0x0
username doug
!
end
config-register 0x0
username doug
!
end
Previous
changes
would be
reversed
Display rollback changes (inclusive)
RP/0/RP1/CPU0:P4#show config rollback changes to doug

config-register 0x0
no username doug
username doug
no password
!
no username jeff
username jeff
no password
!
end
Display inclusive changes back to a certain commit

change
Version 2.0b
741
Module 7
Roll Back Configurations

The rollback configuration command rolls back all configuration
changes up to, and including, the specified Label/CommitID. This rollback
means that if 10 configuration changes have been made, all are cleared and
the configuration is restored to the configuration present before the
specified Label/ID in the command.
The rollback configuration last n command rolls back configuration
changes made in the last specified number (n) commits, where n is a
number ranging from 0 to the number of saved commits in the commit
database. If n is specified as 0, nothing is rolled back.
These commands are validated by the CLI parser before they are
committed to the running configuration.
742
Version 2.0b
Module 7
Roll Back Configurations
RP/0/0/CPU0:P4#rollback configuration to 1000000169

Loading Rollback Changes.
Loaded Rollback Changes in 1 sec
Committing.
12 items committed in 1 sec (11)items/sec
Updating.
Updated Commit database in 1 sec
Configuration successfully rolled back to '1000000169'.
Roll back to specific commitID

Inclusive; undoes configurations up to and
including specified commitID
RP/0/0/CPU0:P4#rollback configuration last 3

Loading Rollback Changes.
Loaded Rollback Changes in 1 sec
Committing.
Updating.
Configuration successfully rolled back 3 commits.
Roll back last number (n) of changes
Version 2.0b
743
Module 7
Load a Specific Configuration

You can load a specific committed configuration. In the global
configurations mode the load command is used to accomplish this task.
Loading a previously committed change would allow you to commit this
change again. This function might be useful if you roll back multiple
inclusive changes, but want this committed change to remain part of the
running configuration.
744
Version 2.0b
Module 7
Load a Specific Configuration
RP/0/0/CPU0:P4(config)#load commit changes 1000000169

Loading.
no username ken
username ken
!
end
RP/0/0/CPU0:P4(config)#commit
Enter configuration mode

Load a previously committed change
Recommit the change
Version 2.0b
745
Module 7
commit Command Keywords

The commit command offers additional keywords to document the
changes as they occur:
746
replaceLets you replace an entire running configuration with the

target configuration
commentLets you add a comment that is displayed when looking at

committed change information
labelLets you label a change, when committing it; the label is

displayed when viewing committed change information
Version 2.0b
Module 7
commit Command Keywords
Available commit keywords:
Replace
Replace entire running configuration with target
configuration
commit replace
Comment
Add text information to the change

Shows up when looking at rollback details
commit comment <comment>
Label
Assigns a name to the change

Shows up when looking at the change
commit label <label>
Version 2.0b
747
Module 7
commit Comments and Labels

Comments and labels are very helpful when you are trying to keep track of,
and roll back from, configuration changes you have made.
The label is displayed, instead of the auto-generated commit ID, in the
output for the show configuration commit list. The label is limited to
10 characters with no spaces and must begin with an alphabetic character.
The text comment is displayed in the commit entry in the output for the
show configuration commit list detail command. The comment is
limited to 60 characters including spaces. The list detail includes the
comment, the label, and the actual commit ID.
_____________________________ Note _________________________
Comment must be the last keyword in the comment command since
all following characters are considered part of the comment.
_________________________________________________________________
748
Version 2.0b
Module 7
commit Comments and Labels
RP/0/0/CPU0:P4(config)#hostname P4abc
RP/0/0/CPU0:P4(config)#commit comment rename from P4 label P4abc
RP/0/0/CPU0:P4abc#show config commit list 1 detail
1) CommitId: 1000000133
Label: NONE
UserId:
cisco
Line: vty0
Client:
CLI
Time: 14:07:35 UTC Wed May 25 2005
Comment:
rename from P4 label P4abc
RP/0/0/CPU0:P4#show config
SNo. Label/ID
User
~~~~ ~~~~~~~~
~~~~
1
1000000133 cisco
commit list
Line
Client
~~~~
~~~~~~
vty0
CLI
Time Stamp
~~~~~~~~~~
14:07:35 UTC Wed May 25 2005
RP/0/0/CPU0:P4abc(config)#hostname P4hjk
RP/0/0/CPU0:P4abc(config)#commit label renameP4hjk
RP/0/0/CPU0:P4hjk#show config commit list 1 detail
1) CommitId: 1000000134
UserId:
cisco
Client:
CLI
Comment: NONE
RP/0/0/CPU0:P4#show config
SNo. Label/ID
User
~~~~ ~~~~~~~~
~~~~
1
renameP4hj cisco
Label: renameP4hjk
Line: vty0
Time: 14:19:50 UTC Wed May 25 2005
commit list
Line
Client
~~~~
~~~~~~
vty0
CLI
Time Stamp
~~~~~~~~~~
14:19:50 UTC Wed May 25 2005
RP/0/0/CPU0:P4hjk(config)#hostname P4
RP/0/0/CPU0:P4hjk(config)#commit label renameP4 comment rename back to P4
RP/0/0/CPU0:P4#show config commit list 1 detail
1) CommitId: 1000000135
Label: renameP4
UserId:
cisco
Line: vty0
Client:
CLI
Time: 14:20:48 UTC Wed May 25 2005
Comment:
rename back to P4
RP/0/0/CPU0:P4#show config commit list
SNo. Label/ID
User
Line
Client
Time Stamp
~~~~ ~~~~~~~~
~~~~
~~~~
~~~~~~
~~~~~~~~~~
1
renameP4
cisco
vty0
CLI
14:20:48 UTC Wed May 25 2005
Version 2.0b
749
Module 7
Configuration Sessions
Configuration sessions can be managed, if necessary. This management
can be helpful if a exclusive session is left open and prevents another
operator from making changes.
The show configuration sessions command displays the running
configuration sessions. The offending session can be removed by using the
clear configuration session command.
750
Version 2.0b
Module 7
Configuration Sessions
RP/0/0/CPU0:P4(config)#do show config sessions

Session
Line
User
00000201-037eb0cf-00000000 vty1
cisco
00000201-037f00d4-00000000 vty3
doug
00000201-037f10d5-00000000 vty2
cisco
Date
Thu Mar 10 06:06:01 2005
Thu Mar 10 06:06:50 2005
Thu Mar 10 06:07:10 2005
Lock
RP/0/0/CPU0:P4#show config sessions

Session
Line
00000201-037f00d4-00000000 vty3
00000201-037f10d5-00000000 vty2
Date
Thu Mar 10 06:06:50 2005
Thu Mar 10 06:07:10 2005
Lock
User
doug
cisco
Manage configuration sessions
View
RP/0/0/CPU0:P4#clear config session 00000201-037eb0cf-00000000

session ID '00000201-037eb0cf-00000000' terminated
Manage configuration sessions
Delete
Version 2.0b
751
Module 7
Miscellaneous CLI Commands

Storage Media Review
Cisco CRS-1 System
The following storage media is located on the Cisco CRS-1 System:
752
Disk0: - DOS FAT 16 file system; stores installed software packages

and active configurations; /usr is default user directory for storing
saved files; 1-GB
Disk1: - DOS FAT 16 file system; removable; stores installation PIE

files and user files (optional)
Harddisk: - DOS FAT 32 file system; used primarily for process or

kernel dumps
NVRAM: - stores ROMMON variables and cryptographic files
Bootflash: - stores ROMMON software; software packages installed

here for MSCs, MSCs, and service processors (SPs)
Version 2.0b
Module 7
Storage Media Review
Cisco CRS-1 Router
Disk0:
Disk1: (optional)
Harddisk:
NVRAM:
Bootflash:
Version 2.0b
753
Module 7
File Commands
The Cisco IOS XR software has its own file system commands that closely
resemble standard UNIX commands, such as:
cdChange directory
pwdPresent working directory
dirPrint directory (shown on facing page)
These commands let you review files and file access across the multiple
media available in the Cisco routers. You can move between directories as
necessary to manage the router files.
Other commands that are available: copy, delete, mkdir, rmdir, and
more.
754
Version 2.0b
Module 7
File Commands
RP/0/0/CPU0:P4#dir disk0:
Directory of disk0:
2
drwx 16384
3
drwx 16384
4
drwx 16384
32
dr-x 16384
28
drwx 16384
1011
drwx 16384
1013
drwx 16384
5773
drwx 16384
6224
drwx 16384
6777
drwx 16384
7687
drwx 16384
7852
drwx 16384
7853
drwx 16384
7864
dr-x 16384
67168
-rwx 2940
67456
-rwx 126
9545
drwx 16384
Thu
Tue
Tue
Tue
Tue
Wed
Tue
Tue
Tue
Tue
Tue
Wed
Thu
Tue
Wed
Wed
Mon
Mar
Apr
Apr
Apr
Apr
May
Apr
Apr
Apr
Apr
Apr
May
Mar
Apr
Apr
Apr
Apr
31
5
26
26
26
18
26
26
26
26
26
25
31
5
6
6
25
10:47:50
15:53:44
21:02:15
21:01:17
20:55:04
10:20:09
20:57:58
20:58:14
20:58:42
20:59:14
20:59:38
09:38:31
10:59:56
16:00:42
12:35:54
12:35:54
10:57:22
2005
2005
2005
2005
2005
2005
2005
2005
2005
2005
2005
2005
2005
2005
2005
2005
2005
LOST.DIR
shutdown
config
aaa
c12k-os-mbi-3.2.83
instdb
c12k-base-3.2.83
c12k-admin-3.2.83
c12k-fwdg-3.2.83
c12k-lc-3.2.83
c12k-rout-3.2.83
usr
var
fping
sam_certdb
sam_crldb
tftp
1024442368 bytes total (876019712 bytes free)

RP/0/0/CPU0:P4#pwd
disk0:/usr
Many standard UNIX file commands
RP/0/0/CPU0:P4#dir disk0:/config/running/commitdb
Directory of disk0:/config/running/commitdb
920736
920864
920960
921056
921408
921536
921664
-r-x
-r-x
-r-x
-r-x
-r-x
-r-x
-r-x
247
80
77
125
2142
2164
2192
Wed
Wed
Wed
Wed
Wed
Wed
Wed
May
May
May
May
May
May
May
25
25
25
25
25
25
25
15:32:40
14:19:50
14:20:48
14:58:30
14:20:49
14:58:30
15:32:40
2005
2005
2005
2005
2005
2005
2005
1000000137.snd
1000000134.snd
1000000135.snd
1000000136.snd
commitdb_info_1000000135.snf
1024442368 bytes total (876019712 bytes free)
Display directory contents
Version 2.0b
755
Module 7
Save and Restore Configuration Files

You can save the running configuration to a file location by using the copy
command.
You can copy a configuration file to the running configuration, also.
Instructor's Note
The restoration of a configuration replaces all or part of the existing configuration.
RP/0/0/CPU0:P4#more disk0:ed
username ed
password 7 110C1D
group cisco-support
end
RP/0/0/CPU0:P4#sho run username
username ed
password 7 110C1D
group root-system
RP/0/0/CPU0:P4#copy disk0:ed running-config
Parsing.
Committing.
Updating.
RP/0/0/CPU0:P4#show run username
username ed
password 7 110C1D
group cisco-support
756
Version 2.0b
Module 7
Save and Restore Configuration Files
Saving a configuration file

RP/0/0/CPU0:P4#copy run disk0:configtest1
Destination file name (control-c to abort): [/configtest1]?
Building configuration.
300 lines built in 1 second
[OK]
RP/0/0/CPU0:P4#
Restoring a configuration file

RP/0/0/CPU0:P4#copy disk0:configtest1 running-config
Parsing.
Committing.............
Updating...
RP/0/0/CPU0:P4#
Version 2.0b
757
Module 7
Redundancy Commands
The status of RP redundancy of the router is displayed using the show
redundancy command. The display shows you which RP is active and
which is standby. The display further shows the status of the standby RP,
along with the most recent reload and boot information.
Should the currently active RP need to be switched to the standby, you can
do it by entering the redundancy switchover command and confirming
the switchover.
Instructor's Note
It is possible for you to disable redundancy, if necessary. The command is
issued from configuration mode. We do not recommend this action unless
directed by support personnel.
Function is no longer available in version 3.2.
758
Version 2.0b
Module 7
Redundancy Commands
RP/0/0/CPU0:P4#show red
Redundancy information for node 0/0/CPU0:
==========================================
Node 0/0/CPU0 is in ACTIVE role
Partner node (0/1/CPU0) is in STANDBY role
Standby node in 0/1/CPU0 is ready
Reload and boot info
---------------------RP reloaded Mon Mar 7 06:22:03 2005: 3 days, 2 hours, 22 minutes ago
Active node booted Mon Mar 7 06:22:03 2005: 3 days, 2 hours, 22 minutes ago
Standby node boot Tue Mar 8 20:05:57 2005: 1 day, 12 hours, 38 minutes ago
Standby node last went not ready Thu Mar 10 08:10:36 2005: 33 minutes ago
Standby node last went ready Thu Mar 10 08:10:36 2005: 33 minutes ago
There have been 0 switch-overs since reload
Display the current redundancy
RP/0/0/CPU0:P4#redundancy switchover
Updating Commit Database. Please wait...[OK]
Proceed with switchover 0/0/CPU0 -> 0/1/CPU0?[confirm]
Initiating switch-over.
Use to switch over to standby RP (EXEC mode)
Version 2.0b
759
Module 7
Command Shortcuts, History, and Help

Many command shortcuts and abbreviated command forms are available to
you.
The Cisco IOS XR CLI accepts the fewest number of characters necessary
to establish the uniqueness of the command entered. Entering a partial
command followed by the tab key also reveals the complete command, or a
list of commands that are similar to the entered string of characters.
A question mark (?) following any command lists all possible commands,
beginning with the string entered. An entered command followed by a
space and question mark (?) lists all possible following keywords or
commands.
Entering the same command many times can be tedious. Cisco IOS XR
software lets you to use the up arrow key, or CTRL P, to step through
previously entered commands, beginning with the last valid entry. The
down arrow key, or CTRL N, reverses the list of entries.
760
Version 2.0b
Module 7
Command Shortcuts, History, and Help
Abbreviated commands
Fewest characters to keep uniqueness

Tab key completes commands
Offers alternatives
Help
Question mark (?) following a command

Lists possible commands
co? = configure copy
Question mark (?) and space following command

Lists commands and keywords
Command buffer
Up arrow key or CTRL P

Down arrow key or CTRL N
Instructor's Note
There is a man command (man pages) available for online help with commands, features and
keywords. However, it is still a work-in-progress.
Version 2.0b
761
Module 7
Process Management
Cisco IOS XR software is a distributed operating system versus a
monolithic type of operating system. As part of the design, there are many
individual processes that are active during router operation. Occasionally
processes can experience problems. You can manage some of the processes;
only the operating system can access others. This is to protect the integrity
of Cisco IOS XR software.
As part of the resiliency of Cisco IOS XR software, processes may stop and
restart themselves. As a default there is a preprogrammed, pre-set limit as
to how many times during a predetermined period of time a process may
stop and restart. Those processes that do not have pre-set limitations can
be managed by you.
To manage the processes, there are show commands and process
commands.
Display Process Information

The show process command has a number of keywords that can be used
to observe the operation of the router, as well as to provide troubleshooting
information.
762
Version 2.0b
Module 7
Process Management
Display Process Information
RP/0/0/CPU0:P4#show process ?
<0-4294967295> job id
WORD
Name of the executable
aborts
Show process aborts
all
Show process data for all processes
blocked
Show detail for reply/send/mutex blocked processes.
boot
Show process boot info
cpu
Show CPU use per process
distribution
Show distribution of processes
dynamic
Show process data for dynamically created processes
failover
Show process failover info
family
Show process family information.
files
Show file and channel use per process
location
location to display
log
Show process log
mandatory
Show process data for mandatory processes
memory
Show memory use per process
searchpath
Show the search path
signal
Show signal use for processes.
startup
Show process data for processes created at startup
threadname
Show thread names.
Version 2.0b
763
Module 7
To display information about individual processes, use the show process

process name command.
Some of the important information shown in the process display is:
764
RespawnRestart the process, if a problem occurs with it
Respawn countNumber of times this process has restarted
Max. spawns per minuteWhen the maximum spawns is reached the

process will not be restarted automatically
Last startedWhen the last respawn took place. This could be the
result of a RP switchover or router reboot
Process stateState of the process when display was taken
Version 2.0b
Module 7
Process Management
Display Process Information (Cont.)
RP/0/RP0/CPU0:P4#show process ospf

Job Id: 252
PID: 62304466
Executable path: /disk0/hfr-rout-3.2.81/bin/ospf
Instance #: 1
Version ID: 00.00.0000
Respawn: ON
Respawn count: 1
Max. spawns per minute: 12
Last started: Thu Mar 10 08:10:31 2005
Process state: Run
Package state: Normal
Started on config: cfg/gl/ipv4-ospf/proc/lab/ord_a/routerid
core: TEXT SHAREDMEM MAINMEM
Max. core: 0
Placement: ON
startup_path: /pkg/startup/ospf.startup
Ready: 2.440s
Available: 6.444s
Process cpu time: 0.197 user, 0.105 kernel, 0.302 total
JID
TID Stack pri state
HR:MM:SS:MSEC NAME
252
1
40K 10 Receive
0:00:00:0192 ospf
252
2
40K 10 Receive
0:00:00:0001 ospf
252
3
40K 10 Receive
0:00:00:0003 ospf
--More-252
4
40K 10 Condvar
0:00:00:0001 ospf
252
5
40K 10 Receive
0:00:00:0000 ospf
Version 2.0b
765
Module 7
Process Control
There are several choices of action you can use to manage processes. Many
of these should be used only in consultation with Cisco Systems, Inc.
technical support.
766
Version 2.0b
Module 7
Process Management
Process Control
RP/0/0/CPU0:P4#process ?
<0-4294967295> job id
WORD
Name of the executable
blocked
process blocked, capture state
crash
crash a process
mandatory
set mandatory reboot settings
restart
restart a process
shutdown
kill/stop a process
start
start a process
Several choices for working with processes
Version 2.0b
767
Module 7
Process Restartability
Due to its modular architecture, Cisco IOS XR software is easy to upgrade
or repair. Each process can be independently started and shut down for
maintenance or upgrade.
Restartability is based on the following features:
Process independence
Process placement
Distributed processes
Process restart is an inherent part of the process separation built into the
software architecture:
No single process failure brings the router down
Card-level redundancy is used in scenarios when process restart fails
Processes with dynamic state use checkpoint, checkpoint mirroring,

and database mirroring or obtain their state from neighbors
Restarting processes contact other processes to reconcile external

inconsistencies
Typically, restarting one process does not cause or require other

components to restart (The exception is a new software installation.)
Process restart occurs automatically in the event that a switchover occurs

between the active and standby RPs or when particular software packages
are being upgraded. During a system upgrade, a particular package might
be upgraded without stopping router operation. Only the processes that are
part of that package are restarted when activating the newly installed
package.
Non-essential processes can also be restarted manually if a network event
occurs. If troubleshooting indicates that a particular process has stopped,
you can restart that process.
Show process commands display the status of the processes and process
commands control processes.
768
Version 2.0b
Module 7
Process Management
Process Restartability
Restarting of individual process does not affect

other processes
Normal
forwarding,
OSPF
Normal
forwarding,
OSPF, BGP
Stop BGP
Normal
forwarding,
OSPF, BGP
Start BGP
Instructor's Note
This animated slide has 2 clicks: 1 Stop sequence; 2 Restart sequence
Version 2.0b
769
Module 7
Process Stop and Restart

To stop a process, enter the process shutdown command.
To restart the process, enter the process start command.
To recycle a process, enter the process restart command.
___________________________CAUTION _______________________
These commands should be used cautiously and only when you are
certain there is no other remedy for your particular problem.
_________________________________________________________________
770
Version 2.0b
Module 7
Process Management
Process Stop and Restart
RP/0/0/CPU0:P4#process shutdown ospf

RP/0/0/CPU0:P4#show process ospf
Job Id: 252
PID: 62304466
Instance #: 1
Respawn: ON
Respawn count: 1
Process state: Killed (last exit status : 1)
Registered item(s): cfg/gl/ipv4-ospf/proc/
Max. core: 0
Placement: ON
Ready: 2.440s
Available: 6.444s
RP/0/0/CPU0:P4#process start ospf

RP/0/0/CPU0:P4#show process ospf
Job Id: 252
PID: 67231951
Instance #: 1
Respawn: ON
Respawn count: 2
Process state: Run (last exit status : 1)
Started on config: cfg/gl/ipv4-ospf/proc/lab/ord_a/routerid
Max. core: 0
Placement: ON
Ready: 1.858s
Available: 6.444s
Process cpu time: 0.177 user, 0.083 kernel, 0.260 total
JID
TID Stack pri state
HR:MM:SS:MSEC NAME
252
1
40K 10 Receive
0:00:00:0175 ospf
252
2
40K 10 Receive
0:00:00:0001 ospf
252
3
40K 10 Receive
0:00:00:0001 ospf
--More-252
4
40K 10 Condvar
0:00:00:0000 ospf
252
5
40K 10 Receive
0:00:00:0000 ospf
Version 2.0b
771
Module 7
Summary
772
Describe the file system and node addressing
Explain configuration processes
Describe other configuration considerations
Explain the configuration rollback process
List storage media
Describe file commands
Describe help commands
Describe process commands
Version 2.0b
Module 7
Review Questions
Version 2.0b
773
Module 7

774
Version 2.0b
Module 8
Cisco IOS XR Installation
Overview
Description
This module teaches you to select, prepare, install, activate, and deactivate
Cisco IOS XR software packages.
Objectives
Describe the Cisco IOS XR packaging model
Describe the process of downloading new software and patches
Describe the process of installing new software and patches
Implement an upgrade or a downgrade of software packages
Describe the application of Cisco IOS XR patches using specific

software maintenance updates (SMUs)
Version 2.0b
81
Module 8
Cisco IOS XR Software Packaging

Packages
Cisco IOS XR software comprises modular "packages." Each package
contains the components to perform a specific set of router functions, such
as routing, security, modular services card, or line card support.
The Cisco IOS XR Unicast Routing Core Bundle is a composite package
containing the following packages:
Forwarding
Administration
Base
Operating system (OS)
Routing
Modular Services card or line card
Four optional packages provide additional features:
82
Manageability Support for HTTP, XML, SNMP and other

management tools
Multicast Support for multicast protocols
MPLS Support for Multiprotocol Label Switching (MPLS)
Security Support for Secure Sockets Layer (SSL), certificates and

other security tools
Version 2.0b
Module 8
Cisco IOS XR Software Packages
Manageability
MPLS
Multicast
MPLS, UCP
PIM, MFIB, IGMP
Security
Routing
Line card
RIB, BGP, ISIS, OSPF, RPL
Line card drivers
IPSec, encryption,
decryption
ORB, XML,
alarms management
Forwarding
FIB, ARP, QoS, ACL, so on
Administration
Resource management: rack, fabric, LR
Base
Interface manager, system database, checkpoint services,
configuration management, other slow-changing components
OS
Kernel, file system, memory management, and other slow changing core components
Instructor's Note
This slide is animated: Forwarding thru OS appears initially; click 1 will show Routing and Line
card packages, which are separately installed; click 2 Optional packages are added to the slide
There is NO significance to the location of the various boxes representing the packages.
Version 2.0b
83
Module 8
Packages
Software packages are groups of software components that provide bootup
and feature functionality for the various installed cards. These packages
can be installed, upgraded, or downgraded individually (provided the
packages are compatible with the running software), allowing you to
modify specific bootup and feature functionality without impacting other,
unrelated functions. Software packages are installed and managed using
the command-line interface (CLI). Software configurations are created by
activating or deactivating packages to add or remove functionality,
upgrade to new software, or downgrade to earlier versions.
The slide shows the currently available software packages and where they
are implemented.
Software Maintenance Updates (SMUs)
Software maintenance updates (SMUs) are files that contain fixes for
specific defects or sets of defects, and are installed using the same
procedures as PIE files (explained later in this section).
SMUs are not an alternative to maintenance releases. They provide quick
resolution of immediate issues. All bugs fixed by SMUs are integrated into
the maintenance releases.
Upgrades
One of the benefits of the package approach is that features, upgrades, or
software patches can be delivered without rebasing the entire image. The
result is a faster qualification time at a customer location, with faster and
easier delivery of bug fixes and incremental feature introduction. One
component upgrade does not force an upgrade of another component,
resulting in minimum disruption and instability.
Modular services cards can maintain state during upgrade or downgrade of
software resulting in less disruption to the system as a whole.
_____________________________ Note _________________________
The SC on the slide is for the shelf controller, which is a future
enhancement for the Cisco CRS-1 router.
_________________________________________________________________
84
Version 2.0b
Module 8
Modular Packaging and Upgrades
RP
MSC or LC
DRP
Multicast
MPLS
Manageability
Security
MPLS
Multicast
Optl
Manageability
Opt'l
Security
MPLS
Optl
Line card
Multicast
Forwarding
Mand.
Base
Routing
Routing
Line card
Line card
OS-MBI
Mand.
Mand.
SC
Forwarding
Forwarding
Admin
Base
Base
OS-MBI
Admin
Mand.
Base
OS-MBI
OS-MBI
Implementation locations
Version 2.0b
85
Module 8
Package Installation Envelope (PIE)

Package Installation Envelope (PIE) files (.pie extension) are compressed
files used to install the bootup, feature, or upgrade packages of a router.
All PIE files are installed using CLI commands. When a PIE file is
installed, packages contained in the PIE file are extracted and installed
onto the storage device of the route processor (RP). During this
installation, a directory is automatically created to store the components of
the package. By default, the directory name is based on the name of the
package.
Here are some examples of the PIE files you might use for the operation of
a Cisco CRS-1 router:
86
comp-hfr-mini.pie-3.2.1
hfr-mpls-p.pie-3.2.1
hfr-k9sec-p.pie-3.2.1
hfr-mcast-p.pie-3.2.1
hfr-mgbl-p.pie-3.2.1
Version 2.0b
Module 8
Package Installation Envelope (PIE)
MPLS
Multicast
Security
Manageability
RPL
BGP
OSPF
ISIS
Package installation envelope (PIE)
Non-bootable files
Upgrade or add feature
packages
Example: hfr-mcast-p.pie-x.y.z
Routing
package
Instructor's Note
First mouse [Enter] click - Multicast PIE moves forward independently to emphasize PIEs do
not have dependencies.
Manageability t will move forward on the second mouse [Enter] click to indicate other examples
of PIEs.
Version 2.0b
87
Module 8
Software Maintenance Upgrade

A software maintenance update (SMU) is an emergency fix built to be
delivered to you in the least possible time and does not provide new feature
content. Software maintenance updates contain bug fixes and updates for a
single package or for multiple packages.
88
Version 2.0b
Module 8
Software Maintenance Upgrade
Upgrade specific software

Install just like a regular .pie file
ISIS software
ISIS process 1
ISIS process 2
Follow the same command

sequence to install
Upgraded
ISIS process 3
ISIS process 3
ISIS process n
ISIS process 1
ISIS process 2
Upgraded
ISIS process 3
ISIS process ...
ISIS process
ISIS process
ISIS software
All other processes

remain the same
ISIS process ...

ISIS process n
Instructor's Note
Rather than risk having process names change, or new processes introduced, this slide is only to
show the level to which upgrades/changes can be made with the new modular packaging.
Version 2.0b
89
Module 8
Composite Software Upgrade

An example of a software upgrade would be to upgrade the Cisco IOS XR
Unicast Routing Bundle to a new release, such as from release 3.0.0 to
release 3.2.0.
This typical software upgrade is likely to be a composite PIE file, which
contains upgrades to current software.
810
Version 2.0b
Module 8
Composite Software Upgrade
Most likely upgrade

3.0.0 core bundle
3.2.0 core bundle
Routing
Routing
Line card
Line card
Forwarding
Forwarding
Admin
Admin
Base
Base
OS-MBI
OS-MBI
Instructor's Note
Animated click or enter: arrow then 2nd column appear for emphasis
Remind students that PIEs will be new features as well as version upgrades, therefore they are
the most likely software installations they will do.
Version 2.0b
811
Module 8
Bootable Code
Packages are delivered to the user in the form of compressed .vm and PIE
files.
Files with the .vm extension are bootable files that contain bootup code and
mandatory package software, such as the core bundle. These files are used
to boot the router for the first time. This process also installs a mandatory
set of feature packages, or PIE files.
812
Version 2.0b
Module 8
Bootable Code
Bootable entities
Routing
.vm files are bootable core OS

Shipped with new routers
Example: comp-hfr-mini.vm-x.y.z
Line card
Forwarding
Initial or emergency
installation files
Admin
Base
OS-MBI
Instructor's Note
Bootable code versions should only used for emergency recoveries only!
Version 2.0b
813
Module 8
Software Versions
Base Package Versions
Software package versions are identified by a three-part numeric scheme:
Major releaseContains a collection of features across multiple

packages. A major release is the least-frequent release and typically
includes large-scale changes that require a router reload.
Minor releaseContains feature upgrades for single packages. A

minor release usually occurs at the application level and although some
individual router processes may restart, a router reload typically is not
required.
Maintenance releaseContains a collection of bug fixes for a

package. A maintenance release incorporates any intermediate SMUs
for that package.
SMU Versions
SMU versions are based on the software package associated with the SMU
and the Distributed Defect Tracking System (DDTS) number addressed by
the SMU. The version scheme is:
<package name>-<package version>.<primary DDTS>-<SMU version
number>
Composite SMU Versions
Composite SMUs are SMUs that apply to more than one software package.
These files have an additional prefix comp- that identifies them as
composite SMUs. The version scheme is:
comp- <composite number>.<primary DDTS>
814
Version 2.0b
Module 8
Software Versions
Software delivery
type
Cisco CRS-1 Series Routers
Composite PIE
comp-platform-composite_name.piemajor.minor.maintenance
Single package
PIE
platform-package_typep.piemajor.minor.maintenance
Composite SMU
comp-platform-composite_name.ddts.pie
Single package
SMU
platform-package_typemajor.minor.maintenance.ddts.pie
Cisco CRS-1 router platform name: hfr

Composite PIE examples
comp-hfr-mini.pie-3.2.83
Single package PIE examples

hfr-mgbl-p.pie-3.2.83
SMU example
c12k-base-3.2.83.CSCeg00654.pie
Version 2.0b
815
Module 8
Software Storage
Software is typically installed on an internal flash disk in the router. For
both the Cisco CRS-1 router and the Cisco XR 12000 Series Routers this is
disk0:.
You can download software prior to its actual installation. The software is
typically stored on a different media device, such as the optional flash
disk1:, until it is ready to be installed.
816
Version 2.0b
Module 8
Software Storage
CRS-1
Flash
disk1:
Version 2.0b
Flash
disk0:
internal
817
Module 8
Router Clock Setting

Before an OS installation on the router, the clock must be set correctly.
___________________________ Warning ________________________
Failure to set the clock causes CA Certificate problems.
_________________________________________________________________
_____________________________ Note _________________________

If the router clock is not set, the following error is displayed:
SAM detects CA certificate (Code Signing Server Certificate
Authority) has expired...
_________________________________________________________________
818
Version 2.0b
Module 8
Setting the Router Clock
Set software system clock

Router#clock set 17:24:23 30 June 2004
or
Router#clock set 17:24:23 June 30 2004
Update the hardware clock

Router#clock update-calendar
Router clock should be correct
Instructor's Note
Why the emphasis on clock setting? When software installs are implemented a digital signature
check occurs. This check uses the date as part of the check. If the clock is off by determined
value, the add process will fail.
For Cisco internal classes only: using the .vm (executable) install process will circumvent the
check process
Version 2.0b
819
Module 8
Package Management
Adding Packages to the Router
Code fixes (SMUs) and optional or new packages must be transferred to
the router before they can be implemented. There are three ways of getting
software to the router:
Copy the software to the router using:
Trivial File Transfer Protocol (TFTP)
File Transfer Protocol (FTP)
Remote Copy Protocol (RCP)
SSH File Transfer Protocol (SFTP)
Install from flash disk1:
Install the software directly from a TFTP server
You can copy the files to the router by using a flask disk with the needed
files or by copying the files from a server using one of the methods above.
Whichever method of these you choose, we recommend that PIE files be
stored on disk1:.
_____________________________ Note _________________________
Disk1: is not included by default.
_________________________________________________________________
820
Version 2.0b
Module 8
Package Management
Adding Packages to the Router
Disk1:
TFTP, FTP,RCP, SFTP
Add
Commit
Activate
Deactivate
Server
Direct add
Disk0:
Copy to disk1: using
TFTP
FTP
Remote Copy Protocol (RCP)
SSH File Transfer Protocol (SFTP)
Install from disk1:

OR
Install directly using TFTP server
Version 2.0b
821
Module 8
install add Command

The install add command is executed in Admin EXEC mode. This
command unpacks and writes PIE files into a new directory on the target
installation device.
Notice in the output of this operation that the installation is taking place
asynchronously. In this default method, the prompt is returned and the
operator can continue working on the router while the installation is
completed in the background.
___________________________ Caution ________________________
Installation commands cannot be entered and configuration
commands should not be entered during the asynchronous
installation process. Show commands can be used.
_________________________________________________________________
Many of the following install commands can be issued only from Admin
EXEC mode; however the show commands may be issued at the standard
EXEC mode level.
822
Version 2.0b
Module 8
Package Management
install add Command
RP/0/0/CPU0:P4(admin)#install add tftp://172.21.116.8/c12k-mcast.pie-3.2.85.3I to disk0:

Install: The idle timeout on this line will be suspended for synchronous install operations
Install: Starting install operation. Do not insert or remove cards until the operation
completes.
RP/0/0/CPU0:P4(admin)#
Install: Now operating in asynchronous mode. Do not attempt subsequent install operations
until this operation is complete.
Install 3: [ 0%] Install operation 'add /tftp://172.21.116.8/c12k-mcast.pie-3.2.85.3I to
disk0:' assigned request id: 3
Install 3: [ 1%] Downloading PIE file from /tftp://172.21.116.8/c12k-mcast.pie-3.2.85.3I
Install 3: [ 1%]
Transferred 3298994 Bytes
Install 3: [ 1%] Downloaded the package to the router
Install 3: [ 1%] Verifying the package
Install 3: [ 1%] [OK]
Install 3: [ 1%] Verification of the package successful [OK]
Install 3: [ 95%] Going ahead to install the package...
Install 3: [ 95%] Add of '/tftp://172.21.116.8/c12k-mcast.pie-3.2.85.3I' completed.
Install 3: [100%] Add successful.
Install 3: [100%] The following package(s) and/or SMU(s) are now available to be activated:
Install 3: [100%]
disk0:c12k-mcast-3.2.85
Install 3: [100%] Please carefully follow the instructions in the release notes when
activating any software
Install 3: [100%] Idle timeout on this line will now be resumed for synchronous install
operations
Instructor's Note
Follow the documented install procedures. The package verification is by digital signature check.
During an add process, no process restarts occur; process restarts occur during activation only
The code in this example is an internal version and not for customer use
Version 2.0b
823
Module 8
install activate Command

The install activate command activates the new software features in the
package that was unpacked with the install add command. Activating a
package adds it to the software configuration for a card type. By default,
packages are activated for all compatible card types. You can activate or
deactivate a package for all compatible card types, or for a specific location.
_____________________________ Note _________________________
Some messages have been omitted from the slide for readability.
_________________________________________________________________
install activate test Option

To test the affect of the install activate command without actually
running the process, append the test keyword to the end of the command.
This option is used to verify the success of this operation.
824
Version 2.0b
Module 8
Package Management
install activate Command
RP/0/0/CPU0:P4(admin)#install activate disk0:c12k-mcast-3.2.85

Install: The idle timeout on this line will be suspended for synchronous install
operations
Install: Starting install operation. Do not insert or remove cards until the operation completes.
Install 3: [ 0%] Install operation 'activate disk0:c12k-mcast-3.2.85' assigned request id: 3
Install 3: [ 1%] Performing Inter-Package Card/Node/Scope Version Dependency Checks
Install 3: [ 1%] Checking API compatibility in software configurations...
Install 3: [ 10%] Updating software configurations.
Install 3: [ 10%] RP,DRP:
Install 3: [ 10%] Activating c12k-mcast-3.2.85
Install 3: [ 10%] Checking running configuration version compatibility with newly activated software..
Install 3: [ 10%] No incompatibilities found between the activated software and router running
configuration.

RP/0/0/CPU0:Nov 12 14:24:01.249 : instdir[181]: %INSTMGR-6-SOFTWARE_CHANGE_END :
Software change transaction 3 is COMPLETE.
Install 3: [100%] Performing software change
Install 3: [100%] Activation operation successful.
Install 3: [100%] NOTE: The changes made to software configurations will not be
Install 3: [100%] persistent across RP reloads. Use the command 'install commit'
Install 3: [100%] to make changes persistent.
Install 3: [100%] Idle timeout on this line will now be resumed for synchronous
install operations
Instructor's Note
This procedure unpacks, runs compatibility test, shuts down old process, activates new process. If
included, the CLI would be updated. For a mini-pie install, all cards and processes will be
restarted. Use show install inactive to determine the name to use for activation with a minipie
NO config commands during activation!!
Point out the important information relative to the affected processes. Additional messages not
shown show various stages the process enters and completes. There is not room to show them,
but the student should be made aware of what they are.
Version 2.0b
825
Module 8
install commit Command

When a package is activated, it becomes part of the current running
configuration. To make the package activation persistent across reloads,
you must enter the command, install commit. If the system is restarted
before the active software set is saved with install commit, the old active
software set is used.
While commit seems final, there is a process for recovering from software
installations that produce unstable conditions. The rollback process is
discussed later in this module.
826
Version 2.0b
Module 8
Package Management
Install commit Command
RP/0/0/CPU0:P5(admin)#install commit
Install: The idle timeout on this line will be suspended for synchronous
install operations
Install 5: [ 1%] Install operation 'commit' assigned request id: 5
Install 5: [100%] Committing uncommitted changes in software configurations.
Install 5: [100%] Commit operation successful.
Install 5: [100%] Idle timeout on this line will now be resumed for
synchronous operations
New software is activated across reloads
Instructor's Note
The commit is a safety mechanism. This step saves the current state of the software. The software
can be verified that it works correctly by not invoking the commit. If installing the change causes
a system hang or the bug is not fixed, then the package would not be installed after a reboot
Version 2.0b
827
Module 8
install deactivate Command

The install deactivate command turns off the package features for a card
or card type. If an earlier version of the package exists, you can downgrade
the package by activating the earlier package version. The older version of
the package becomes the active package.
___________________________CAUTION _______________________
A feature package cannot be deactivated if other active
packages need it to operate.
_________________________________________________________________
SMUs can be deactivated to remove the updates from the software
configuration.
install deactivate test Option

To test the affect of the install deactivate command without actually
running the process, append the test option to the end of the command.
This option is used to verify the success of this operation.
828
Version 2.0b
Module 8
Package Management
Deactivating Packages
RP/0/0/CPU0:P5(admin)#install deactivate disk0:c12k-rp-mgbl-3.2.85

operations
completes.
Install 8: [ 0%] Install operation 'deactivate disk0:c12k-mgbl-3.2.85' assigned
request id: 8
Install 8: [ 1%] Package 'disk0:c12k-mgbl-3.2.85' is not active and cannot be deactivated.
Install 8: [ 1%] Idle timeout on this line will now be resumed for synchronous
install operations
Package features no longer available

Package still installed
Package can be reactivated
Instructor's Note
This is a general deactivation of a package. For a specific location, the location keyword can be
used: deactivate <package> location 0/1/CPU0.
Point out the important information relative to the affected processes.
Remind students of install commit requirement to make persistent across reloads.
Version 2.0b
829
Module 8
install remove Command

The install remove name command removes an inactive package from the
location in which it was previously installed. The command completely
removes the package and all associated configurations.
_____________________________ Note _________________________
This command must be preceded by install deactivate and install
commit commands.
_________________________________________________________________
830
Version 2.0b
Module 8
Package Management
Package Removal
RP/0/0/CPU0:P5(admin)#install remove disk0:c12k-mgbl-3.2.85

operations
completes.
Install 12: Install operation remove disk0:c12k-mgbl-3.2.85 assigned
request id: 12
Install 12: Scanning existing install information... [OK]
Install 12: Analyzing Request ...
Install 12: [OK]
Install 12: Deleting directory disk0:c12k-mgbl-3.2.85 ...
Install 12: [OK]
Install 12: Remove operation completed.
Install 12: NOTE: The changes made to software configurations will not be
Install 12: persistent across RP reloads. Use the command 'install commit'
Install 12: to make changes persistent.
Install 12: Idle timeout on this line will now be resumed for synchronous
install operations
Deactivate package first

install commit required
Test option
Instructor's Note
What happens if software is deleted the files and directories removed? And the correct steps for
deactivation and removal (install deactivate, commit, remove) are not followed? Software that is
still in use would no longer be available. The router should make multiple attempts to boot and
may appear to be hung; eventually it will give up attempting to boot the primary RP and will boot
the standby RP. The standby should be OK, as the code changes attempted on the primary are
not synchronized with the standby during the deactivation and removal. The standby becomes the
primary and returns the switch to the pre-change state.
Version 2.0b
831
Module 8
Installation Rollback
The install rollback command provides a method of returning to the
previously active installation point. You can return to either the last
committed package or to a noncommitted package. The slide shows an
example of rolling back to a previously committed package.
_____________________________ Note _________________________
The install rollback command without a reload option will only
rollback to the last install point. To roll back to an earlier install point
requires the reload option
_________________________________________________________________
You can determine the available rollback information by using these
commands:
show install logLists what occurred at each install point
show install committedLists all installed and committed software
show install rollback ?Lists only the available install transaction

points (IDs), committed or noncommitted, to which you can roll back.
Use these install points to compare what software was installed
install rollback test Command

To test the affect of the install rollback command without actually
making changes to the system, append the test option to the end of the
command. This option is used to verify the success of this operation.
_____________________________ Note _________________________
The install rollback is intended to be used only when multiple
packages, or a core bundle, are to be removed in a single step
_________________________________________________________________
832
Version 2.0b
Module 8
Package Management
install rollback Command
RP/0/0/CPU0:P5(admin)#install rollback 2
operations
completes.
Install 11: [ 0%] Install operation 'rollback 2' assigned request id: 11
Install 11: [ 10%] Updating software configurations.
Install 11: [ 10%]
RP:
Install 11: [ 10%]
Activating c12k-admin-3.2.83
Install 11: [ 10%]
Activating c12k-base-3.2.83
Rolling back to this version

Install 11: [ 10%]
Install 11: [ 10%]
Install 11: [ 10%]
Activating mprp-rp__boot-3.2.83
Deactivating c12k-admin-3.2.85
Deactivating c12k-base-3.2.85
Rolling back from this version

Install 11: [ 10%]
Install 11: [ 10%]
Deactivating mprp-rp__boot-3.2.85
Change boot image to /disk0/c12k-os-mbi-3.2.83/mbiprp-rp.vm
Committed software
Non-committed software
Install 11: [ 10%] Checking running configuration version compatibility with new
ly activated software ...
Install 11: [ 10%] No incompatibilities found between the activated software and
router running configuration.
Install 11: [ 10%] Node 0/0/CPU0: *** Will be reloaded ***
Note reload
Install 11: [ 55%] Downloading packages to impacted nodes
Install 11: [ 55%] Successfully downloaded packages to impacted nodesRP/0/0/CPU0
:Jun 2 06:12:24.596 : instdir[182]: %INSTALL-INSTMGR-6-SOFTWARE_CHANGE_START :
Software change transaction 11 is BEGINNING...
Install 11: [ 85%] Performing software change
P/0/0/CPU0:Jun 2 06:12:28.632 : instdir[182]: %INSTALL-INSTMGR-6-SOFTWARE_CHANG
E_END : Software change transaction 11 is COMPLETE.
[2KInstall 11: [100%] Reducing timeouts to better synchronize node reloads.
Install 11: [100%] *** This node is reloading, please hold back any commands ***
Install 11: [100%] NOTE: The changes made to software configurations will not be
Install 11: [100%] persistent across RP reloads. Use the command 'install commit
'
Install 11: [100%] to make changes persistent.
Re-boot will occur automatically
Version 2.0b
833
Module 8
SMU Installation and Activation

The Software Maintenance Update (SMU) is built as an emergency fix. The
SMU contains bug fixes and updates for a single package or for multiple
packages.
The Cisco IOS XR software that is delivered on the router and other
hardware platforms can be patched or upgraded online, while the router
continues to forward (using nonstop forwarding) and route packets.
The installation of the SMU follows the same procedures as PIE installs.
The SMU fix is not fully installed until the PIE file is activated on the
router. Depending on the type of fix provided in the PIE file, it may require
a restart of several processes or a reload of the LC or the router.
In this slide, the SMU is installed and activated in one step.
834
Version 2.0b
Module 8
Package Management
SMU Installation and Activation
RP/0/0/CPU0:P5(admin)#install add tftp://223.255.254.254/c12k-mgbl-3.2.83.CSCeg00302.pie

to disk0: activate
operations
Install: Starting install operation. Do not insert or remove cards until the
operation completes.
Install: Now operating in asynchronous mode. Do not attempt subsequent install
operations until this operation is complete.
Install 1: [ 0%] Install operation 'add tftp://223.255.254.254/c12k-mgbl-3.2.83.CSCeg00302.pie
to disk0:' assigned request id: 1
Install 1: [ 1%] Downloaded the package to the router
Install 1: [ 1%] Verifying the package
Refer to the install add command messages

Install
request
Install
Install
Install
Install
Install
install
3: [ 0%] Install operation 'activate disk0:c12k-mgbl-3.2.83.CSCeg00302.pie' assigned

id: 3
3: [100%] Activation operation successful.
3: [100%] NOTE: The changes made to software configurations will not be
3: [100%] persistent across RP reloads. Use the command 'install commit'
3: [100%] to make changes persistent.
3: [100%] Idle timeout on this line will now be resumed for synchronous
operations
Refer to the install activate command messages
Single step for add and activate
Version 2.0b
835
Module 8
Software Installation Review

Cisco IOS XR software provides you with many commands to review and
determine the status of installed software, as well as the installation
process itself. In this context, installation refers to all activities involved in
adding, updating, or removing software. The install log is limited to fifty
(50) entries.
Viewing the Installation Log

The show install log command displays a list, with some detail, of each
installation action (transaction) that took place on the system.
836
Version 2.0b
Module 8
Viewing the Installation Log
RP/0/0/CPU0:P4(admin)#sho install log

Request id 1 by cisco at Tue May 31 10:41:12 2005:
1 pie added to disk0:: /tftp://172.21.116.8/c12k-mcast.pie-3.2.85.3I
1 pie added to disk0:: /tftp://172.21.116.8/c12k-mpls.pie-3.2.85.3I
1 package activated: disk0:c12k-mpls-3.2.85 test - Failed - 'Install Manager
' detected the 'fatal' condition 'Package compatibility check failed, incompatib
ilities detected.'
Request id 4 by cisco at Wed Jun 01 10:20:52 2005:
1 pie added to disk0:: /disk0:c12k-mini.pie-3.2.85.3I
1 package activated: disk0:c12k-mini-3.2.85
More information available via the command 'show install log 5'
Committed loadpath changes
5 entries shown (max log size 50 entries)
Also applicable at the EXEC prompt
Version 2.0b
837
Module 8
Display Installation Entries

Using the show install command you can see all of the information about
any of the installation processes that have occurred. The status of both
successful and failed installations is available. When a package is
successfully activated, the new software may affect many parts of the
router by adding files, programs, dynamic link libraries (DLL), and
stopping and starting processes. You can see all of this activity by using
these commands.
The output from this command includes details on what files have been
changed and what processes were impacted.
838
Version 2.0b
Module 8
Display Installation Entries
RP/0/RP0/CPU0:P1(admin)#show install log 2

Request id 2 by cisco at Tue Apr 05 21:16:16 2005:
1 pie added to disk0:: /tftp://10.0.0.100/hfr-mpls-p.pie-3.2.83.1i
Status Information Logs:
Downloading PIE file from /tftp://10.0.0.100/hfr-mpls-p.pie-3.2.83.1i
Downloaded the package to the router
Verifying the package
[OK]
Verification of the package successful [OK]
Going ahead to install the package...
Add of '/tftp://10.0.0.100/hfr-mpls-p.pie-3.2.83.1i' completed.
Add successful.
The following package(s) and/or SMU(s) are now available to be activated:
disk0:hfr-mpls-3.2.83
Please carefully follow the instructions in the release notes
when activating any software
Example of adding software to router
RP/0/0/CPU0:P5(admin)#show install log 3

Request id 3 by cisco at Wed Mar 02 15:53:52 2005:
1 package activated: disk0:c12k-mgbl-3.2.83
Summary:
Node 0/0/CPU0: 6 c12k-mgbl processes affected (0 updated, 6 added, 0 removed,
0 impacted)
Node 0/1/CPU0: 6 c12k-mgbl processes affected (0 updated, 6 added, 0 removed,
0 impacted)
Status Information Logs:
Installation changes:
Installation changes on node 0/0/CPU0:
Adding executable: perfmgmt_show
Adding and starting process: pm_collector
Adding and starting process: snmppingd
Adding executable: xml_tty_client
Adding and starting process: xmlagent
Adding file: sh_ciscosensormib_ns_cfg__api.configinfo
Adding DLL: libxmlalarmerror.dll
Replacing file: md5_manifest
Installation changes on node 0/1/CPU0:
Installation impact details:
6 New Servers to be started
0 (A: ) pm_collector
server [c12k-mgbl:manageability-perf]
Sample of messages and information
Version 2.0b
839
Module 8
Display Active Software

The show install active command displays the active software set from
all nodes. If you specify a node with the location keyword and node-id
argument, this command displays the active software set from that specific
node.
840
Version 2.0b
Module 8
Display Active Software
RP/0/0/CPU0:P5#show install active

Node 0/0/CPU0 [RP]
Boot Image: /disk0/c12k-os-mbi-3.2.83/mbiprp-rp.vm
Active Packages:
disk0:c12k-mini-3.2.83
Node 0/1/CPU0 [RP]
Active Packages:
Node 0/3/CPU0 [LC(E3-OC3-POS-4)]
Boot Image: /disk0/c12k-os-mbi-3.2.83/gsr/ucode/mbiprp-lc.ucode
Active Packages:
Node 0/4/CPU0 [LC(E3-OC48-POS)]
Active Packages:
Version 2.0b
841
Module 8
Display Active Package Details

You can use the show install active detail command to expand the
composite packages to see the included package names, versions, and
devices on which the packages are installed.
When a specific device is requested, all the composite and other packages
installed on that device are displayed.
842
Version 2.0b
Module 8
Display Active Package Details
RP/0/0/CPU0:P5#show install active detail

Node 0/0/CPU0 [RP]
Active Packages:
disk0:c12k-rout-3.2.83
disk0:c12k-lc-3.2.83
disk0:c12k-fwdg-3.2.83
Core bundle
disk0:c12k-admin-3.2.83
disk0:c12k-base-3.2.83
disk0:c12k-os-mbi-3.2.83
Minimum boot image
Node 0/1/CPU0 [RP]

Active Packages:
disk0:c12k-rout-3.2.83
Node 0/3/CPU0 [LC(E3-OC3-POS-4)]
Active Packages:
Version 2.0b
843
Module 8
Other Display Commands

Other show install commands can be used to display a variety of
information about software installed on the router. These commands have
extended keywords and parameters to locate all the information you might
require.
844
Version 2.0b
Module 8
Other Display Commands
RP/0/0/CPU0:P5#show install ?
active
Show active package information
all
Show information for all locations
committed Show the committed package information
detail
Show information about constituent package
inactive
Show active package information
location
Show information for a specific location
log
Show log file
package
Name of the package
pie-info
Show information in a PIE file
requests
Show current requests
rollback
Show package information for a rollback point
which
Show the origin of a named process, component or package
|
Output Modifiers
<cr>
General and specific information available
Version 2.0b
845
Module 8
Summary
846
Describe the Cisco IOS XR packaging model
Describe the process of downloading new software and patches
Describe the process of installing new software and patches
Implement an upgrade or a downgrade of software packages
Describe the application of Cisco IOS XR patches using specific

software maintenance updates (SMUs)
Version 2.0b
Module 8
Review Questions
Version 2.0b
847
Module 8

848
Version 2.0b
Module 9
Cisco IOS XR Security
Overview
Description
This module teaches you Cisco IOS XR authentication, authorization, and
accounting, along with router security administration and access control
list configuration using the command-line interface (CLI). Neither
Cisco Craft Works Interface (CWI) nor XML security is discussed in this
module.
Objectives
List available router security types
Describe predefined user and task groups
Configure user and task groups
Add and remove users
Describe router authorization, authentication, and accounting
Describe and implement AAA
Describe and implement access control lists
Instructor's Note
This module discusses IOS XR security for the CLI only. Please make the students aware that a
future IOS XR Security course will cover the TACACS+ and Radius implementations along with
CWI and XML security. Also, this course does not cover CA, IKE, IPSec, SFTP or SSL.
Version 1.0c
91
Module 9
Cisco IOS XR Security Overview

The implementation of security is a key piece of network design and
implementation today. Access control is the method used to control access
to the network, servers, and available services. Cisco IOS XR software has
a base security package which includes:
Authorization, authentication, and accounting
Access control lists
Software Authentication Manager
Authorization, Authentication, and Accounting

AAA uses a new administrative model to control user access in the
Cisco IOS XR system. Implementing security requires task-based
authorization that involves configuring user groups and task groups, and
setting up logging and audit trails.
AAA is part of the base package and is available by default.
Access Control List

An access control list (ACL) consists of one or more access control entries
(ACEs) that collectively define the network traffic profile. This profile can
then be referenced by Cisco IOS XR software features, such as traffic
filtering, priority, or custom queuing, and dynamic access control. Each
ACL includes an action element (permit or deny) and a filter element,
based on criteria such as source address, destination address, protocol, and
protocol-specific parameters.
ACLs are a part of the base package and available by default.
92
Version 1.0c
Module 9
IOS XR base security package provides secure

access control with
Authorization, authentication, and accounting
Controls user access

Implements task-based authorization
Uses user and task groups
Logging and audit trails
Access control lists (ACL)
ACL has one or more access control entries

(ACEs)
ACLs define traffic profiles
Version 1.0c
93
Module 9
Software Authentication Manager

Software Authentication Manager (SAM) is a component of the
Cisco IOS XR operating system that ensures that software being installed
on the router is safe and that the software does not run if its integrity has
been compromised.
For SAM to verify software during installation, the software to be installed
must be in a PIE format. PIE files are digitally signed, and SAM verifies
the digital signature before allowing bits from that PIE to reside on the
router. Each time an installed piece of software is accessed, SAM ensures
that the integrity of the software has not been compromised since it was
installed. SAM also verifies that software pre-installed on a flash card has
not been tampered with while in transit.
When the initial image or a software package update is loaded on the
router, SAM verifies the validity of the image by checking the expiration
date of the certificate used to sign the image. If an error message is
displayed indicating that your certificate has expired, check the system
clock and verify that it is accurate. If the system clock is not set correctly,
the system does not function properly.
94
Version 1.0c
Module 9
Cisco IOS XR Security Overview (Cont.)
Software Authentication Manager:
Ensures software being installed on router is

safe
Requires installed software be in PIE format

Ensures software integrity and compatibility with
each installation
Verifies software on flash cards is not

compromised
Version 1.0c
95
Module 9
Optional Cryptographic Security Software

The security protocols and applications described below are optional and
require cryptographic certificate installation.
Certificate Authority
Certificate authority (CA) interoperability supports the IP Security

(IPSec), Secure Socket Layer (SSL), and Secure Shell (SSH) protocols. CA
interoperability permits Cisco IOS XR devices and CAs to communicate so
that your Cisco IOS XR device can obtain and use digital certificates from
the CA. Although IPSec can be implemented in your network without the
use of a CA, using a CA provides manageability and scalability for IPSec.
IP Security (IPSec)
IP Security (IPSec) provides security for the transmission of sensitive

information over unprotected networks, such as the Internet. IPSec acts at
the network layer, protecting and authenticating IP packets between
participating IPSec devices ("peers"), such as Cisco routers.
Internet Key Exchange Security
Internet Key Exchange (IKE) is a key management protocol standard that

is used with the IP Security (IPSec) standard. IPSec is a feature that
provides robust authentication and encryption of IP packets.
IKE is a hybrid protocol that implements the Oakley key exchange and the
Skeme key exchange inside the Internet Security Association and Key
Management Protocol (ISAKMP) framework. (ISAKMP, Oakley, and
Skeme are security protocols implemented by IKE).
IPSec can be configured without IKE, but IKE enhances IPSec by
providing additional features, flexibility, and ease of configuration for the
IPSec standard.
96
Version 1.0c
Module 9
Security package supports
Certificate Authority (CA)
Supports IPSec, SSL, and SSH

Issues digital certificates to authorized devices
IPSec network security
Secures transmission at the network layer

Applies crypto profiles
Tunnel interfaces
Crypto IPSec transport
Internet Key Exchange (IKE) security
Hybrid protocol implements
Oakley key exchange

Skeme key exchange inside (ISAKMP) framework
Enhances IPSec by providing additional features, flexibility,

and configuration ease for IPSec
Version 1.0c
97
Module 9
Secure Socket Layer and Transport Layer Security (SSL)
The Secure Socket Layer (SSL) protocol and Transport Layer Security
(TLS) are application-level protocols that provide for secure communication
between a client and server by allowing mutual authentication, the use of
hash for integrity, and encryption for privacy. SSL and TLS rely upon
certificates, public keys, and private keys.
Secure Shell (SSH)
Secure Shell (SSH) is a protocol and an application that provides a secure

replacement to the Berkeley r-tools. The protocol secures sessions using
standard cryptographic mechanisms, and the application can be used
similarly to the Berkeley rexec and rsh tools.
Two versions of SSH are available: SSH Version 1 (SSHv1) and
SSH Version 2 (SSHv2). SSHv1 uses Rivest, Shamir, and Adelman (RSA)
keys, and SSHv2 uses Digital Signature Algorithm (DSA) keys. Cisco IOS
XR software supports both SSHv1 and SSHv2.
98
Version 1.0c
Module 9
Secure Socket Layer (SSL) and Transport Layer

Security (TLS)
Application-level protocols
Secures client/server communication
Requires RSA or DSA key pairs or CA certificate
Secure Shell
Replaces for Berkeley rexec and rsh tools

Version 1 (SSHv1) using RSA keys
Version 2 (SSHv2) using DSA keys
Version 1.0c
99
Module 9
Cisco IOS XR Security Implementation

Authentication, Authorization, and Accounting
User groups and task groups are configured through the Cisco IOS XR
software command set used for authentication and authorization services.
Authentication commands are used to verify the identity of a user or
principal. Authorization commands are used to verify that an
authenticated user (or principal) is granted permission to perform a
specific task. Accounting commands are used for logging of sessions and to
create an audit trail by recording certain user- or system-generated
actions.
AAA Implementation Planes

Cisco IOS XR software operates in two planes: administration (Admin) and
logical router (LR). The Admin plane has complete responsibility for the
root-system user and certain other administrative responsibility for the
root-lr users.
The root-system user has the highest level of responsibility for the router.
This user provisions logical routers and creates root-lr users. When
created, root-lr users have responsibility for the LR. Root-lr users, in turn,
can create LR users. Currently, root-system and root-lr users have fixed
permissions (task IDs) and cannot be changed by customers.
Resource-Based Access
In Cisco IOS XR software, some resources are made available only to

certain privileged types of users. The Admin plane is accessible to only the
root-system user. An individual LR is accessible to the root-system user
root-lr user, and individual LR users for that specific logical router.
Individual users should not be given access to any LR that is not directly
associated with them.
Each LR has a local AAA database, in which users are defined. However, if
a user is defined in an external TACACS+ server, it is possible for that
same user to have access to multiple logical routers.
910
Version 1.0c
Module 9
AAA Implementation Planes
Logical router (LR) plane
Administration (Admin) plane
ADMIN
LR
AAA
Single physical router
Version 1.0c
911
Module 9
Prerequisites for Security Implementation

For a router security implementation, there are prerequisites, some of
which are configured by default in Cisco IOS XR software.
912
Establish a root-system user using the initial setup dialog; this is

required for either a new router installation or the upgrade of an
existing Cisco IOS router to the Cisco IOS XR software
Root-system user must be in a user group associated with a task group

that includes the proper task IDs for security commands
Additional users are assigned to user groups. The root-system user may
configure a few local users without any additional AAA configuration
An external security server is recommended when many user accounts

are shared among many routers within a network domain. A typical
configuration would include the use of an external AAA security server
and database with the local database option as a backup in case the
external server becomes unreachable.
Version 1.0c
Module 9
Prerequisites for Security Implementation
Root-system user established
During initial setup dialog of new router

During initial setup dialog of router upgrade from IOS
Must always be one
Task groups with proper task IDs

Users must be associated with user groups
Root-system users may configure local users without any

additional AAA configuration
External security server recommended when user

accounts apply to many routers in a domain
Typical configuration would include external AAA security
server and database

A local database is an option as backup
Version 1.0c
913
Module 9
Authorization
Authorization provides the method for access control of user account and
user group support. AAA authorization works by assembling a set of
attributes that describe what the user is authorized to perform.
Task Groups
A task group is defined by a collection of task IDs. Task groups contain

task ID lists for each class of action. Task groups are defined so that
multiple rights can be pooled together into a rights policy.
Task IDs
Task IDs grant permission to perform certain tasks. Task IDs are added to
the task groups to define a security policy. Tasks IDs (rights) are pooled
into a task group that is then assigned to users.
User Groups
A user group is a collection of users that share similar authorization rights

on a router or series of LRs.
Users
A user is the basic authorization unit that is authenticated and authorized

to log in to the router. Users are assigned to user groups for easier
administration.
914
Version 1.0c
Module 9
Authorization
Task groups
Task identifiers
Control, configuration
or execution of
operations
Read, write, execute,
and debug actions
Task classes
Task ID examples:
basic-services
network
interface
bgp, isis, ospf, rib
Cisco predefined task

groups
Custom-defined task
groups
Hierarchically
structured groups
Re-use of task groups
Security policy
Version 1.0c
915
Module 9
Task-Based Authorization
The operational tasks of router control, configuration, and monitoring are
represented by task IDs. A task ID defines the permission to run an
operation. Task ID operations can be one, all, or a combination of:
Readpermits a read operation only
Writepermits a write operation and an implicit read operation
Executepermits an access operation, such as to a copy, ping, or telnet
Debugpermits access to debug commands
Users are associated with sets of task IDs that define the breadth of their
authorized access to the router.
Task IDs
Task-based authorization employs the concept of a task ID as its basic

element.
Every router control, configuration, and monitoring operation is defined by
a particular set of task IDs. Task IDs are common to both the commandline interface (CLI) and the application program interface (API). A given
CLI command or API invocation is associated with at least one or more
task IDs. These associations are hard-coded within the router and may not
be modified. Task IDs grant permission to perform certain tasks; task IDs
do not deny permission to perform tasks.
The system verifies that each CLI command and API invocation conforms
to the task ID permission list for the user. It compares the associated task
IDs for a user with the task IDs associated with the CLI or API invocation;
if the compared task ID sets conform, the user is allowed to run the
operation.
916
Version 1.0c
Module 9
Task-Based Authorization
Task IDs
Represent router control, configuration, and

monitoring operations
Define permissions
CLI commands and API invocations
Associated with at least one (or more) task ID

Hard-coded (associations); cannot be changed
Are one, all, or a combination of: read, write,

execute, or debug
Instructor's Note
The permissions are based on Unix file permissions. An example could be a copy command. This
would require read access to the source file, write access to new target file and execute access to
the copy command. Reviewing the required permissions using the describe command (covered
later in this module) will help you understand the permissions.
Version 1.0c
917
Module 9
Task Groups
A task group is defined by a collection of task IDs. Task groups contain
task ID lists for each class of action.
Each user group is associated with a set of task groups applicable to the
users in that group. A users task permissions are derived from the task
groups associated with the user groups to which that user belongs.
Task Groups can be organized as:
Predefined Task Groups
User-Defined Task Groups
Group Inheritance
Task groups have group inheritance properties that support inheritance

from other task groups. For example, when task group A inherits task
group B, the new set of attributes of task group A is the union of A and B.
Predefined Task Groups

The following predefined task groups are available for administrators to
use, typically for initial configuration:
root-systemRoot-system users
root-lrRoot-logical router users
netadminNetwork administrators
sysadminSystem administrators
operatorDay-to-day activity users
Users can configure their own task groups to meet particular needs.
Task groups support inheritance from other task groups.
918
Version 1.0c
Module 9
Task Groups
Groups
Defined by collection of task IDs
Task groups associated to user groups
Predefined or site-defined task groups
Support inheritance
Pre-defined Groups
root-system Root-system users
root-lr Root-logical router users
netadmin Network administrators
sysadmin System administrators
operator Day-to-day activity users
Version 1.0c
919
Module 9
Authentication
Authentication is accomplished by comparing the user ID and the userprovided password with the information stored in a security database for
the user.
Authentication of Root-System Users
The root-system user (or owner) is configured in the Admin plane and has
visibility into any logical routers. To support this feature, a AAA database
is defined for the Admin plane.
Authentication of LR Owner
An LR owner can log in to only those nodes belonging to the specific logical
router associated with that LR owner. If the user is a member of the LR
owner group, then the user is authenticated as an LR owner. All logical
routers have their own LR owner groups.
Authentication of LR User
The LR user authentication is similar to the LR owner authentication. If

the user is not a member of the designated LR owner group or the rootsystem user group, the user is authenticated as an LR user.
The group, to which an authenticated user belongs, determines the role of
that user. A user can be a member of one or more user groups.
User Groups
A user group defines a collection of users that share a set of attributes,
such as access privileges. Each user may be associated with one or more
user groups. User groups have a list of task groups that define the
authorization for the members of the group. All tasks are permitted by
default for root-system users.
920
Version 1.0c
Module 9
Authentication and User Groups
Authentication
Compare user ID and password with AAA DB

Admin plane
Root-system user
Logical router (LR) plane
LR owner
LR user
User Groups
Collection of user with same attributes and privileges
Cisco predefined user groups

User-defined groups
Version 1.0c
921
Module 9
Predefined User Groups

Cisco IOS XR software provides the means for a system administrator to
configure groups of users and job characteristics that are common in
groups of users. Groups must be explicitly assigned to users. Users are not
assigned to groups by default. A user can be assigned to more than one
group.
Cisco IOS XR software has a collection of user groups whose attributes are
already defined. The predefined groups are as follows:
root-systemControls and monitors the entire router
root-lrControls and monitors a specific LR
sysadminControls and monitors all system parameters, but cannot

configure network protocols
netadminControls and monitors all system and network parameters
operatorHas use of some basic commands with basic privileges
The user group root-system has root-system users as the only members.
The root-system user group has predefined authorization and the complete
responsibility for root-system user-managed resources and certain
responsibilities in logical routers. Authorization is enabled by default for
root-system users in any LR, including the root LR.
Administrators can configure their own user groups to meet particular
needs.
922
Version 1.0c
Module 9
Predefined User Groups
Administrators use these groups in initial configuration:
root-system
For control and monitoring of entire system
root-lr
For control and monitoring a specific LR
sysadmin
For control and monitoring all system parameters

Cannot configure network protocols
netadmin
For control and monitoring all system and network

parameters
operator
For basic access
Version 1.0c
923
Module 9
Predefined User Group Permissions

Cisco IOS XR software provides these user groups with predefined
attributes.
924
root-systemThe root-system user is the entity authorized to own

the entire router chassis. The root-system user acts with the highest
privileges over all router components. The root-system user can
perform all read and write commands on the router.
root-lrThe LR owner can perform all write commands, except the

root-system owner tasks, which are read only.
netadminThe netadmin can perform all read commands except rootsystem owner tasks. The following are examples of write tasks that the
netadmin can perform: routing, forwarding, connectivity, VLAN, AAA,
and so on.
sysadminThe sysadmin can perform all read commands except rootsystem owner tasks. The following are examples of write tasks that the
sysadmin can perform: AAA, manageability, logging, and so on.
operatorThe operator performs the day-to-day activities on the

router. The operator can perform basic read and write router operations
and read logs, Cisco Discovery Protocol (CDP) information, and
diagnostic information.
Version 1.0c
Module 9
Predefined User Group Permissions
root-system
Root-system owner
Read and write all commands available on the router
root-lr
Logical-router owner
Read and write all commands on the LR
Root-system owner tasks are read only
netadmin
Network administrators
Read all commands except root-system owner commands
Write routing, forwarding, connectivity, VLAN, AAA, and so on
sysadmin
System administrators
Read all commands except root-system owner commands
Write AAA, manageability, logging, and so on
operator
General user
Read and write basic operations
Read logs, CDP, and run diagnostics
Version 1.0c
925
Module 9
Users
Cisco IOS XR software attributes forms the basis of router user access.
Each router user is associated with the following:
926
User ID (ASCII string) that identifies the user uniquely across an

administrative domain
Password of an arbitrary length, stored encrypted
List of user groups (at least one) of which the user is a member (thereby
enabling attributes such as task IDs)
Other attributes obtained from the Cisco IOS XR software
Version 1.0c
Module 9
Users
Each router user is associated with a:
User ID (ASCII string) that provides a unique

identity
Password of an arbitrary length, stored encrypted
List of at least one user group of which the user is
a member (thereby enabling attributes such as
task IDs)
Other attributes obtained from the Cisco IOS XR
software
Version 1.0c
927
Module 9
Local AAA and Database

AAA data, such as users, user groups, and task groups, is stored locally
within a logical router. The data is stored in the in-memory database,
SysDB, and the configuration file. The stored passwords must be
encrypted. The local database may also have X.509 certificates for Secure
Socket Layer (SSL) and Transport Layer Security (TLS).
_____________________________ Note _________________________
The specific logical router database, in which users and groups are
defined, is not visible to other logical routers in the same system.
_________________________________________________________________
928
Version 1.0c
Module 9
Local AAA and Database
Authentication, authorization, and accounting (AAA)
Users, user groups, and task groups are stored

in a local database (SysDB)
Version 1.0c
929
Module 9
Remote AAA
Products such as Cisco Secure Access Control Server can be used to
administer the shared or external AAA database. The router communicates
with the remote AAA server using standard IP-based security protocol
(such as TACACS+). The remote security server should support enough
logic to create the different classes of users appropriately. Security data
stored in the server can be used by any client, provided the client knows
the server IP address, port, and key.
Client Configuration
The security server should be configured with the secret key shared with
the router and IP addresses of the clients.
Root-System User Management
Creating, modifying, and deleting root-system users should be done at the

highest privilege of the security server. If the user is configured as a
member of that group, it does not make sense for the user to be a member
of any other user group.
LR Owner Management
A user is termed an LR owner if he or she is made a member of the LR

owner group. If made so, the user cannot be made a member of any other
group, because the permissions of an LR owner are predefined.
LR User Management
LR users can be created and made members of multiple user groups. The
effective task permission set is derived by making a union of all
permissions enabled by all user groups.
User Group Management
User groups have unique names across the domain of the security server.
User groups, however, are qualified with lists of logical routers that can
refer to them.
Task Group Management
Task groups are defined by lists of permitted task IDs for each type of
action (read, write, and so on). The task IDs are defined in the router.
To support configuration of task groups in external software, the task ID
definitions may need to be exported.
930
Version 1.0c
Module 9
Remote AAA
IP
network
AAA subsystem
CLI
HTTP
AAA client
library
AAA
server
TACACSD
RADIUSD
External
AAA
server
XML
agents
TACACSD TACACS daemon

RADIUSD RADIUS client subsystem
Version 1.0c
931
Module 9
Method Lists
AAA data may be stored in a variety of data sources. AAA configuration
uses method lists to define an order of preference for the source of AAA
data. AAA may define more than one method list, and applications (such as
login) can choose one of them. For example, console and AUX ports may
use one method list, and the VTY ports may use another. If a method list is
not specified, the application tries to use a default method list.
Rollover Mechanism
AAA can be configured to use a prioritized list of database options. If the

system is unable to use a database, it automatically rolls over to the next
database on the list. If the authentication, authorization, or accounting
request is rejected by any database, the rollover does not occur and the
request is rejected.
The following methods are available:
Local: Use the locally configured database (not applicable for

accounting and certain types of authorization)
TACACS+: Use a TACACS+ server (such as Cisco Secure)
RADIUS: Use a RADIUS server
Line: Use a line password and user group (applicable only for
authentication)
None: Allow the request (not applicable for authentication)
Server Grouping
Instead of maintaining a single global list of servers, the user can form
server groups for different AAA protocols (such as RADIUS, TACACS+,
and so on) and associate them with AAA applications (PPP, EXEC, and so
on).
932
Version 1.0c
Module 9
Method Lists
Support an order of preference for AAA sources

Prioritize database access options
Local
TACACS+
RADIUS
Line
None
Define multiple method lists
Use one for applications

Use another for console access
Version 1.0c
933
Module 9
Authentication
A method list is a named list that describes the authentication methods to

be used (such as TACACS+) in sequence. The method is one of the
following:
loginSets login authentication
group tacacs+Uses a server group or TACACS+ servers for

authentication
localUses a local username or password database for authentication
lineUses a line password or user group for authentication
Authorization
Method lists for authorization define the ways authorization is performed

and the sequence in which these methods are performed. A method list is a
named list that describes the authorization methods to be used (such as
TACACS+) in sequence. Method lists enable you to designate one or more
security protocols to be used for authorization, thus ensuring a backup
system if the initial method fails.
Cisco IOS XR software supports three types of AAA authorization:
CommandApplies authorization to the EXEC mode commands

issued by a user. Command authorization attempts authorization for
all EXEC mode commands.
EXECApplies authorization to the startup of an EXEC session.
NetworkApplies authorization to network services Internet Key

Exchange (IKE).
Accounting
Currently, Cisco IOS XR software supports only the TACACS method of

accounting. The router reports user activity to the TACACS+ security
server in the form of accounting records. Each accounting record contains
accounting AV pairs and is stored on the security server.
934
Version 1.0c
Module 9
Method Lists (Cont.)
Authentication lists
Set the order of preference for AAA data
login sets login authentication

group tacacs+ use server group or TACACS+
group radius use server name
local use local username and password database
line use line password or user group
Authorization lists
Define ways and sequence of authorization

Command EXEC mode commands
EXEC starting an EXEC session
Network network services IKE
Accounting lists
Supports only TACACS+

Used for monitoring and reporting TACACS+ attribute
value (AV) pairs
Version 1.0c
935
Module 9
Authentication Flow of Control

AAA performs authentication according to the following process:
1. A user requests authentication by providing a username and password.
2. The authentication method list is determined, and the AAA source of
data is consulted.
3. AAA verifies the password and rejects the user, if the password does
not match the database.
936
Version 1.0c
Module 9
Authentication Flow of Control
User requests authentication by providing a

username and password
Authentication verifies the user identity

2
Authentication method list determined

AAA source of data consulted
Authorization verifies the user permissions

3
AAA verifies user password

AAA rejects user if password does not match
database
Version 1.0c
937
Module 9
4. AAA determines the role of the user (root-system user, root-lr user, or
LR user):
If the user has been configured as a member of a root-system user

group, AAA authenticates the user as a root-system user.
If the user has been configured as a member of a root-lr user group,

AAA authenticates the user as a root-lr user.
If the user has not been configured as a member of a root-system

user group or a root-lr user group, AAA authenticates the user as an
LR user.
5. Accounting collects the information about the session and stores it on

the security server.
938
Version 1.0c
Module 9
Security Implementation Flow (Cont.)
Authorization verifies the user permissions

4
AAA determines the role of the user

(root-system user, root-lr owner, or LR user)
Accounting collects and stores access

information
5
AAA information about the user

(identity, start/stop times, commands executed)
Version 1.0c
939
Module 9
Accounting
Accounting provides a method for collecting and sending security server
information used for billing, auditing, and reporting, such as user
identities, start and stop times, executed commands (such as PPP), number
of packets, and number of bytes. Accounting enables you to track the
services users are accessing and the amount of network resources they are
consuming.
Cisco IOS XR software supports the TACACS+ method of accounting. The
router reports user activity to the TACACS+ security server in the form of
accounting records. Each accounting record contains accounting attributevalue (AV) pairs and is stored on the security server in an accounting log.
Use the aaa accounting commands to create named method lists defining
specific accounting methods that can be used on a per-line or per-interface
basis.
Method lists for accounting define the way accounting is performed,
enabling you to designate a particular security protocol to be used on
specific lines or interfaces for particular types of accounting services.
940
Version 1.0c
Module 9
Accounting
Accounting
database
RP/0/0/CPU0:POD5(config)#aaa accounting ?
commands . . . . . . . For EXEC (shell) commands
exec . . . . . . . . . For starting an EXEC (shell)
system . . . . . . . .For System events
RP/0/0/CPU0:POD5(config)#aaa accounting commands ?
word
Named accounting list
default
Default accounting list
RP/0/0/CPU0:POD5(config)#aaa accounting commands cisco ?
start-stop start and stop records
stop-only
stop records only
Version 1.0c
941
Module 9
Security Configuration
Site-Defined Task Groups, User Groups, and Users
Before configuring the security policy, some thought must be given to the
operational tasks that individual users are required to perform. This
planning can provide for all necessary user access, while maintaining
control over router security.
To configure user security policy, follow these steps:
1. Configure task groups and associate task IDs to the group.
Configure a task group and assign rights to it. For example, an OSPF task
group might have only OSPF configuration rights, whereas a BGP task
group might inherit all OSPF rights, in addition to the BGP configuration
rights.
2. Configure user groups.
Configure a user group and give it permissions by associating the group to
a particular task group.
3. Configure users.
Create users and assign them to one or more user groups.
942
Version 1.0c
Module 9
Site-Defined Groups and Users
Configuration flow
Task group (TG)

Name
Task ID associations
Read, write, so on
Inheritance of other
TG permissions
User group (UG)

Name
Inheritance of
TG permissions
Taskgroup
associations
Version 1.0c
User
Name
Password
List of user
groups
943
Module 9
Commands and Task IDs

The describe command provides information about the security level, task
ID, software package, and software release for a CLI command. This
command is useful when establishing user privilege levels.
In the example, access to the taskids, admin and pkg-mgmt is required to
install software.
944
Version 1.0c
Module 9
Commands and Task IDs
Description command provides task ID information

RP/0/0/CPU0:P4#describe admin install commit
The command is defined in instmgr_cmds.parser
Node 0/RP0/CPU0 has file instmgr_cmds.parser for boot package /disk0/hfr-os-mbie
Package:
hfr-base
hfr-base V3.2.0 Base Package
Vendor : Cisco Systems
Desc
: Base Package
Build : Built on Sun Feb 13 19:06:35 PST 2005
Source : By edde-bld1 in /vws/afu/production/3.2.0/hfr/workspace fo8
Component:
installmgr V0.0.0[ci/9]
On the box installation program
File: instmgr_cmds.parser
Required to
install
software
User needs ALL of the following taskids:

admin (READ WRITE EXECUTE)
pkg-mgmt (READ WRITE EXECUTE)
It will take the following actions:

Spawn the process:
instcmd -A install commit
Instructor's Note
At this writing there is some discussion about this command as to availability or replacement. The
command is not documented and is available only to root-system and cisco-support groups.
Emphasize Task IDs; this command is useful when setting up Task groups and User groups; it is
the best way to see the rights needed to set up privileges and access
Version 1.0c
945
Module 9
Creating Task Groups

Task-based authorization employs the concept of a task ID as its basic
element. A task ID defines the permission to execute an operation for a
given user. Each user is associated with a set of permitted Cisco IOS XR
operation tasks, identified by task IDs. Users are granted authority by
being assigned to user groups that are, in turn, associated with task
groups. Each task group is associated with one or more task IDs selected
from the IOS XR set of available task IDs. The first configuration task in
setting up the router authorization is to configure the task group, then the
user group, followed by the individual users.
946
Version 1.0c
Module 9
Creating Task Groups
Configure taskgroup bgpadmin

RP/0/RP0/CPU0:POD5#configure
RP/0/RP0/CPU0:POD5(config)#taskgroup bgpadmin
Inherit other task group rights (bgpadmin can do OSPF configs)

RP/0/RP0/CPU0:POD5(config-tg)#inherit taskgroup ospfadmin
Assign task permissions

RP/0/RP0/CPU0:POD5(config-tg)#task read bgp
RP/0/RP0/CPU0:POD5(config-tg)#task write bgp
Commit the changes

RP/0/RP0/CPU0:POD5(config-tg)#commit
RP/0/RP0/CPU0:POD5(config-tg)#
Version 1.0c
947
Module 9
Verifying Task Group Configuration

To display the details of a group and the tasks that the group can perform,
use the show aaa taskgroup command.
948
Version 1.0c
Module 9
Verifying Task Group Configuration
RP/0/0/CPU0:P5#sho aaa taskgroup igpadmin

Task group 'igpadmin'
Task IDs included directly by this group:
Task:
isis : READ
WRITE
Task:
ospf : READ
WRITE
Task:
rib : READ
WRITE
Task group 'igpadmin' has the following combined set
of task IDs (including all inherited groups):
Task:
isis : READ
WRITE
Task:
ospf : READ
WRITE
Task:
rib : READ
WRITE
Version 1.0c
949
Module 9
Creating User Groups

User groups are configured with the command parameters for a set of
users, such as task groups.
To access the user group configuration submode, enter the usergroup
command. You can remove specific user groups by using the no form of the
usergroup command, and you can remove the user group itself by using
the no form of the command without giving any parameters. Deletion of a
user group that is still referenced in the system results in a warning.
950
Version 1.0c
Module 9
Creating User Groups
Configure usergroup routeadmin

RP/0/RP0/CPU0:POD5(config)#usergroup routeadmin
Assign usergroup to a taskgroup

RP/0/RP0/CPU0:POD5(config-ug)#taskgroup bgpadmin
Commit the changes

RP/0/RP0/CPU0:POD5(config-ug)#commit
RP/0/RP0/CPU0:POD5(config-ug)#
Version 1.0c
951
Module 9
Verifying User Group Configuration

Use the show aaa usergroup command to display details for a single
group and the task groups that the group contains.
952
Version 1.0c
Module 9
Verifying User Group Configuration
RP/0/0/CPU0:POD5#show aaa usergroup

User group 'routeadmin'
contains task group 'bgpadmin'
Version 1.0c
953
Module 9
Configuring Users
Each user is identified by a username that is unique across the
administrative domain. Each user should be made a member of at least one
user group. Deleting a user group may orphan the users associated with
that group.
The username command provides username and password authentication
for login purposes only. It provides the method of assigning a user to a user
group.
To create users with passwords, follow these steps:
1. Configure a username to add users who can access the system.
2. Configure the password for the user defined with the username
command. Passwords have two levels: password and secret.
PasswordLower security
Unencrypted version that uses a parameter value of 0, which is

the default
Hidden version that uses a parameter value of 7
SecretHigher security
Unencrypted version that uses a parameter value of 0, which is

the default
Hidden version that uses a parameter value of 5
Secret overrides and ignores password, even if password has been

set.
3. Configure a group that will give the user the privileges they need
When a sign on process is started on an inbound access line that has
password protection, the process prompts for the password. If the user
enters the correct password, the process presents the normal privileged
prompt. The user can try three times to enter a password before the
process exits and returns the terminal to the idle state.
954
Version 1.0c
Module 9
Configuring Users
Configure a user
RP/0/RP0/CPU0:POD5(config)#username ken
Assign a password
RP/0/RP0/CPU0:POD5(config-un)#password drowssap57
RP/0/RP0/CPU0:POD5(config-un)#
Assign the user to a usergroup

RP/0/RP0/CPU0:POD5(config-un)#group routeadmin
Commit the changes

RP/0/RP0/CPU0:POD5(config-un)#commit
RP/0/RP0/CPU0:POD5(config-un)#
Instructor's Note
The two password choices, password and secret, offer levels of encryption. Password offers 0 or
7; 0 keeps the password in clear text, while 7 encrypts it. For secret, 0 keeps the password in clear
text; 5 encrypts it.
Version 1.0c
955
Module 9
Verifying User Configuration

To display all local users with their respective user groups, use the show
aaa userdb command.
To display information for a specific user and the tasks that the user can
perform, use the show aaa userdb username command.
956
Version 1.0c
Module 9
Verifying User Configuration
Display all users

RP/0/0/CPU0:POD5#show aaa userdb
Username ken
User group routeadmin
Username cisco
User group root-system
Display a specific user

RP/0/0/CPU0:POD5#show aaa userdb ken
Username: ken
User group routeadmin
Task:
bgp : READ
Task:
ospf : READ
WRITE
WRITE
EXECUTE
EXECUTE
Instructor's Note
A question may arise from the information regarding password encryption on the previous page.
Where does one see a clear text password? The show running config command will reveal any
clear text passwords; you will not see them with either of these commands.
Version 1.0c
957
Module 9
Access Control Lists

Overview
Access control lists (ACLs) are lists of conditions that are applied to traffic
traveling across a router interface. ACLs consist of one or more ordered
access control entries (ACEs) that collectively define a network profile.
This profile can be used for traffic filtering, priority or custom queuing, and
dynamic access control.
Each ACL includes an action element (permit or deny) and a filter element
based on criteria such as source address, destination address, protocol, and
protocol-specific parameters.
Prefix lists are used in route maps and route filtering operations and can
be used as an alternative to access lists in many Border Gateway Protocol
(BGP) route filtering commands. A prefix is a portion of an IP address,
starting from the far left bit of the far left octet. By specifying exactly how
many bits of an address belong to a prefix, you can then use prefixes to
aggregate addresses and perform some function on them, such as
redistribution (filter routing updates).
958
Version 1.0c
Module 9
ACL Overview
Access Control List
Lists conditions applied to router traffic

Composed of ACEs that collectively define a
network profile
Each ACL has an action element (permit or deny)

and a filter element
Standard and Extended types of ACL
Version 1.0c
959
Module 9
Access lists perform packet filtering to control which packets move through
the network and where. Such control can help limit network traffic and
restrict the access of users and devices to the network. Access lists have
many uses, and therefore many commands accept a reference to an access
list in their command syntax. Access lists can be used to do the following
Limit network traffic and increase network performance. By restricting

video traffic, for example, ACLs can greatly reduce the network load
and consequently increase network performance.
Provide traffic flow control. ACLs can restrict the delivery of routing
updates. If updates are not required because of network conditions,
bandwidth is preserved.
Provide a basic level of security for network access. ACLs can allow one
host to access a part of the network and prevent another host from
accessing the same area.
Allow an administrator to control what areas a client can access on a

network.
The order in which ACL statements are placed is important. Cisco IOS XR
software tests the packet against each condition statement, in order, from
the top to the bottom of the list. After a match is found, the permit action
or deny action is performed, and no other ACL statements are checked.
960
Version 1.0c
Module 9
ACL Overview (Cont.)
ACL purposes
Filter incoming or outgoing packets

Restrict routing update contents
Control virtual terminal access
Identify or classify traffic for priority queuing, congestion
avoidance or management, and so on
IOS XR ACLs are extended named ACLs
Identify IPv4 or IPv6 type

Define one ACLs for each protocol, and 2 for each
direction, or port (ingress/egress)

Operate in a sequential logical order
Contain an implied deny at the end of all ACLs
Should contain at least 1 permit
Version 1.0c
961
Module 9
Creating ACLs and Applying to an Interface

To create a named extended ACL in Cisco IOS XR, enter the configuration
mode and specify the ACL name; then add ACE statements to the list.
After you create an access list, you must reference the access list to make it
work. Access lists can be applied on either outbound or inbound interfaces.
Set identical restrictions on all the virtual terminal lines, because a user
can attempt to connect to any of them.
For inbound access lists, after receiving a packet, Cisco IOS XR software
checks the source address of the packet against the access list. If the access
list permits the address, the software continues to process the packet. If
the access list rejects the address, the software discards the packet and
returns an ICMP host unreachable message. The ICMP message is
configurable.
For outbound access lists, after receiving and routing a packet to a
controlled interface, the software checks the source address of the packet
against the access list. If the access list permits the address, the software
sends the packet. If the access list rejects the address, the software
discards the packet and returns an ICMP host unreachable message.
When you apply an access list that has not yet been defined to an interface,
the software acts as if the access list has not been applied to the interface
and accepts all packets. Note this behavior if you use undefined access lists
as a means of security in your network.
962
Version 1.0c
Module 9
Creating ACLs and Applying to an Interface
RP/0/RP0/CPU0:POD5#conf
RP/0/RP0/CPU0:POD5(config)#ipv4 access-list cisco
RP/0/RP0/CPU0:POD5(config-ipv4-acl)#30 deny 192.168.34.0 0.0.0.255
RP/0/RP0/CPU0:POD5(config-ipv4-acl)#40 permit 172.168.34.0 0.0.0.255
RP/0/RP0/CPU0:POD5(config-ipv4-acl)#commit
RP/0/RP0/CPU0:POD5(config-ipv4-acl)#exit
RP/0/RP0/CPU0:POD5(config)#interface POS 0/4/0/0
RP/0/RP0/CPU0:POD5(config-if)#ipv4 access-group cisco in
RP/0/RP0/CPU0:POD5(config-if)#commit
Version 1.0c
963
Module 9
Editing ACLs
A value-added feature in Cisco IOS XR software is line addition and
subtraction of individual access control elements in access lists. Individual
ACE statements within an ACL are numbered, making it easy to add or
subtract statements at any time.
Statements are added to the ACL by specifying an additional line number
followed by the new ACE.
Statements are removed from the ACL by specifying the no keyword
followed by the line number.
Instructor's Note
To apply an Extended name ACL:
RP/0/0/CPU0:POD3(config)#interface POS 0/4/0/0 ipv4 access-group ?
WORD access-list name
RP/0/0/CPU0:POD3(config)#interface POS 0/4/0/0 ipv4 access-group cisco ?
in
Filter incoming packets
out Filter outgoing packets
RP/0/0/CPU0:POD3(config)#interface POS 0/4/0/0 ipv4 access-group cisco in
964
Version 1.0c
Module 9
Editing ACLs
Sample ACL
RP/0/RP0/CPU0:POD5#show ipv4 access-list Ethernet_In
ipv4 access-list Ethernet_In
1 deny udp any eq netbios-ns any
2 deny udp any host 255.255.255.255 eq tftp
4 permit any
Add a line
RP/0/0/0:RP-POD1(config-ipv4-acl)#3 deny udp any eq netbios-dgm any
Modified sample ACL

RP/0/RP0/CPU0:POD5#show ipv4 access-list Ethernet_In
3 deny udp any eq netbios-dgm any
4 permit any
Sample ACL
RP/0/RP0/CPU0:POD5#show access-list ipv4 Ethernet_In
3 deny udp any eq netbios-dgm any
4 permit any
Remove a line
RP/0/0/0:RP-POD1(config-ipv4-acl)#no 3
Modified sample ACL

4 permit any
Version 1.0c
965
Module 9
Resequencing ACLs
To add a statement in the middle of an access list, you can renumber the
ACEs in the ACL by using the resequence command.
For example, if statements 1 to 10 have been used and an ACE needs to be
added in the middle of the ACL, use the resequence command to change
the numbers by a factor of 10. Additional statements can then be inserted
in the newly created number space.
966
Version 1.0c
Module 9
Resequencing ACLs
Sample ACL
3 permit any
Resequence the ACL
RP/0/RP0/CPU0:POD5#resequence access-list ipv4 Ethernet_In
Modified sample ACL

30 permit any
Instructor's Note
This is an EXEC level command. This command will create a rollback file with the ACL as the
client.
Version 1.0c
967
Module 9
Copying ACLs
When an ACL has been created, using the copy command, the access list
can be recreated and the statements are renumbered. The new ACL is then
applied to the interfaces.
968
Version 1.0c
Module 9
Copying ACLs
RP/0/RP0/CPU0:POD5#copy access-list ipv4 pod5 pod5copy
Version 1.0c
969
Module 9
Summary
970
List available router security types
Describe predefined user and task groups
Configure user and task groups
Add and remove users
Describe router authorization and accounting
Implement Secure Shell (SSH)
Create and edit access control lists (ACLs)
Version 1.0c
Module 9
Review Questions
Version 1.0c
971
Module 9

972
Version 1.0c
Module 10
Routing Protocols
Overview
Description
This module covers the Cisco IOS XR Release 3.2 implementation of the
Border Gateway Protocol (BGP), the Open Shortest Path First (OSPF)
protocol, the Intermediate System-Intermediate System (IS-IS) protocol,
and Multicast Routing. It also discusses functional and configuration
differences between Cisco IOS and Cisco IOS XR routing protocols.
Objectives
Configure BGP
Configure OSPF
Configure IS-IS
Configure Multicast Routing
Identify functional and configuration differences between Cisco IOS

and Cisco IOS XR routing protocols
Version 2.0a
101
Routing Protocols
Module 10
Border Gateway Protocol (BGP)

Functional Differences
Cisco IOS XR multiprotocol BGP is enhanced to convey routing
information for multiple address families (IPv4 and IPv6, unicast and
multicast prefixes). Unlike Cisco IOS, Cisco IOS XR does not support
BGPv3 by configuration or negotiation. The BGP software peers only with
other routers running BGPv4, which is the current defacto Internet
External Gateway Protocol (EGP) standard.
Graceful restart allows BGP peers to avoid changes to their forwarding
paths following a RP route processor (RP) switchover or BGP instance
restart. Graceful restart-capable routers exchange this capability in their
OPEN messages when establishing a peer session. Graceful restart is also
supported in recent versions of Cisco IOS (12.0S).
Outbound route filter (ORF)-capable routers exchange inbound prefix lists
over a peer session and pre-filter advertised routes against the received
list. This feature potentially saves bandwidth and processing, because less
routing information may be sent between the routers. ORF is also
supported in Cisco IOS release 12.2(4)T.
The hierarchical command-line interface (CLI) configuration is used
throughout Cisco IOS XR and is one of the major changes from Cisco IOS.
Grouping of BGP neighbor configuration makes the BGP configuration
more intuitive and more easily viewed. BGP parameters that would in IOS
have to be displayed by viewing the entire router configuration can be
viewed now by simply displaying the BGP configuration.
To simplify configuration of multiple neighbors with similar
characteristics, template groups were introduced that allow a set of
neighbor-related commands to be defined in a named group that can be
referenced from the neighbor configurations.
BGP address family support must be configured for both the process
instance and neighbor peer session; no address family is defaulted. It is
possible, and often desirable, to have multiple address families configured
for the instance and only a subset of those families for a specific neighbor.
102
Version 2.0a
Module 10
BGPv4 only with extensions

Multiprotocol (IPv4/IPv6 unicast/multicast)
Route refresh and graceful restart
Outbound route filter (ORF)
TCP MD5 authentication
Hierarchical CLI
Neighbor-based configuration
Template groups to reduce configuration size
No default address family
Routing Policy Language (RPL)
Most route map usage replaced
Inbound and outbound policies required for eBGP
Dynamic update groups
Instructor's Note
R3.2 BGP Implementation limits:
1024 neighbors configurable by bgp maximum neighbor command (max 1500)
512K IPv4 unicast prefixes configurable by maximum-prefix command (max 4G)
128K IPv4 multicast prefixes configurable by maximum-prefix command (max 4G)
128K IPv6 unicast prefixes configurable by maximum-prefix command (max 4G)
???? IPv6 multicast prefixes configurable by maximum-prefix command (max 4G)
Version 2.0a
103
Routing Protocols
Module 10
In Cisco IOS software, route maps, community lists, and as-path lists are
used to filter and modify BGP routes. Route policies written with the
Routing Policy Language (RPL) replace most usage of route maps in Cisco
IOS XR.
External BGP (EBGP) neighbors must have inbound and outbound policies
configured. If no policies are configured, no routes will be accepted from a
neighbor, nor will any routes be advertised to it. This default behavior is
intended to prevent routes from being accepted or advertised externally
without specific configuration. All routes are advertised to and accepted
from internal BGP (IBGP) neighbors if there are no policies.
BGP update message generation is dynamically calculated by an algorithm
that sorts neighbors into update groups, based on common outbound
routing policies. No configuration of this feature is required. Cisco IOS
12.0(24)S introduced a similar functionally called Dynamic Update Peergroups.
104
Version 2.0a
Module 10
Functional Differences (Cont.)
BGPv4 only with extensions

Multiprotocol (IPv4/IPv6 unicast/multicast)
Route refresh and graceful restart
Outbound route filter (ORF)
TCP MD5 authentication
Hierarchical CLI
Neighbor-based configuration
Template groups to reduce configuration size
No default address family
Most route map usage replaced
Inbound and outbound policies required for eBGP
Dynamic update groups
Version 2.0a
105
Routing Protocols
Module 10
CLI Differences
Cisco IOS XR implements a hierarchical CLI configuration structure that
groups all BGP configuration and creates new submodes for neighbor and
address family configuration. In addition, address family group, session
group, and neighbor group submodes allow configuration of parameters
that can be inherited by address family and neighbor configurations
through the use command. Similarly, groups can inherit configuration
from another group of the same type through the use command.
New show commands have been added to view the inherited configuration
of neighbors along with the inherited group names.
106
Version 2.0a
Module 10
CLI Differences
Hierarchical BGP configuration with explicit inheritance
router bgp
af-group
address-family
session-group
neighbor
neighbor-group
address-family
address-family
RP/0/RP0/CPU0:router(config)# router bgp 100

RP/0/RP0/CPU0:router(config-bgp)# neighbor 10.222.1.1
RP/0/RP0/CPU0:router(config-bgp-nbr)# remote-as 100
RP/0/RP0/CPU0:router(config-bgp-nbr)# use neighbor-group neighbor1
RP/0/RP0/CPU0:router(config-bgp-nbr)# address-family ipv4 unicast
RP/0/RP0/CPU0:router(config-bgp-nbr-af)# use af-group family4u
Instructor's Note
Presenting This Slide: The dashed arrows represent possible command inheritance with the use
command. That is, a group (af-group, session-group, or neighbor-group) may be used in other
configuration submodes and thus its commands inherited by that configuration.
Version 2.0a
107
Routing Protocols
Module 10
neighbor Command
To enter neighbor configuration mode for configuring BGP peer sessions,
use the neighbor command in BGP router configuration mode. From
neighbor configuration mode, you can enter address-family configuration
for the neighbor by using the address-family command that allows you to
configure routing updates for IPv4 and IPv6 address prefixes.
The neighbor command does not establish a peering session with the
neighbor. To create the neighbor peering session, you must configure a
remote autonomous system number by entering the remote-as command,
or the neighbor can inherit a remote autonomous system number from a
neighbor group or session group through the use command.
108
Version 2.0a
Module 10
neighbor Command
Cisco IOS
router(config-router)# neighbor 10.222.1.1 remote-as 100
router(config-router)# neighbor 10.222.1.1 update-source Loopback0
Cisco IOS XR
RP/0/RP0/CPU0:router(config-bgp-nbr)# update-source Loopback0
Version 2.0a
109
Routing Protocols
Module 10
neighbor-group (peer-group) Command

In Cisco IOS, the neighbor peer-group command groups common
configuration parameters for multiple neighbors and provides the basis for
efficient consolidation of BGP routing updates. In Cisco IOS XR, neighbor
groups replace peer groups for configuration purposes only. Optimal BGP
update message generation is dynamically calculated by an algorithm that
sorts neighbors into update groups, based on outbound routing policies. No
configuration of this feature is required.
The neighbor-group command puts you in neighbor group configuration
mode and allows you to create a neighbor group. A neighbor group helps
you apply the same configuration to one or more neighbors. From neighbor
group configuration mode, you can configure address-family independent
parameters for the neighbor group.
To enter address-family specific configuration for the neighbor group, use
the address-family command when in the neighbor group configuration
mode.
Once a neighbor group is configured, neighbors can be configured to inherit
the configuration through the use command. If a neighbor is configured to
use a neighbor group, the neighbor inherits the entire configuration of the
neighbor group, which includes the address family independent and
specific configurations. However, the inherited configuration can be
overridden if you directly configure specific parameters for the neighbor or
configure and use session groups or address family groups.
1010
Version 2.0a
Module 10
neighbor-group (peer-group) Command
Cisco IOS
router(config-router)# neighbor group_1 peer-group
router(config-router)# neighbor group_1 remote-as 64500
router(config-router)# neighbor group_1 update-source loopback0
router(config-router)# neighbor 10.60.70.10 peer-group group_1
Cisco IOS XR
RP/0/RP0/CPU0:router(config-bgp)# neighbor-group group_1
RP/0/RP0/CPU0:router(config-bgp-nbrgrp)# remote-as 64500
RP/0/RP0/CPU0:router(config-bgp-nbrgrp)# update-source loopback0
RP/0/RP0/CPU0:router(config-bgp-nbrgrp)# exit
RP/0/RP0/CPU0:router(config-bgp-nbr)# use neighbor-group group_1
Instructor's Note
A neighbor group would be most valuable for a IBGP full mesh or route reflector configuration.
In both cases, the router will have many internal peers all typically with the same neighbor
configuration. This is the situation in our Routing lab that follows this module.
Version 2.0a
1011
Routing Protocols
Module 10
address-family Command
To configure various address-family configuration parameters for BGP
peering sessions, use the address-family command in the appropriate
configuration mode - router, neighbor, or neighbor group.
An address family must be explicitly configured in the router configuration
mode for the address family to be active in BGP. Similarly, an address
family must be configured under the neighbor for the BGP session to be
established for that address family. An address family must be configured
in router configuration mode before it can be configured under a neighbor.
Configure the address-family ipv4 or address-family ipv6 command at
the global level to enable configuration of neighbors. When you enter the
address-family command from neighbor configuration mode, you enter
neighbor address-family configuration mode. Use ipv4 for IPv4 neighbors
and ipv6 for IPv6 neighbors.
1012
Version 2.0a
Module 10
address-family Command
router(config-bgp)#
router(config-bgp-nbr)#
address-family {ipv4 | ipv6} {unicast | multicast}
RP/0/RP0/CPU0:router(config-bgp)# address-family ipv4 unicast
RP/0/RP0/CPU0:router(config-bgp-af)# network 10.0.0.0/8
RP/0/RP0/CPU0:router(config-bgp-af)# exit
RP/0/RP0/CPU0:router(config-bgp-nbr)# address-family ipv4 unicast
RP/0/RP0/CPU0:router(config-bgp-nbr-af)# weight 200
Version 2.0a
1013
Routing Protocols
Module 10
Configuration Example
The topology and configuration on the opposite page is similar to part of
the courses lab environment. Because this is a full-mesh iBGP topology, it
would be typical for all the iBGP neighbors to have the same configuration
commands. Notice how use of the neighbor group internal reduces the
configuration of the two BGP neighbors.
1014
Version 2.0a
Module 10
Configuration Example
P3
P1
.3
142.50.12
.1
100.10.20.3
100.10.20.1
POS 0/4/0/0
POS 0/3/0/1
.3
142.50.20
P2
.2
100.10.20.2
interface Loopback0
ipv4 address 100.10.20.3 255.255.255.255
!
ipv4 address 142.50.20.3 255.255.255.0
!
ipv4 address 142.50.12.3 255.255.255.0
!
router bgp 65000
address-family ipv4 unicast
!
neighbor-group internal
remote-as 65000
password encrypted 121A0C041104
update-source Loopback0
!
!
neighbor 100.10.20.1
use neighbor-group internal
description P1 router
!
use neighbor-group internal
description P2 router
!
!
Version 2.0a
1015
Routing Protocols
Module 10
show Commands
With the hierarchical configuration structure supporting explicit
inheritance of address family, session, and neighbor groups, new show
commands exist to view the inherited configuration of neighbors along with
the inherited group names.
To view the effective configuration for a neighbor, you use the show bgp
neighbors <ip-address> configuration command. Names enclosed in
brackets (such as internal) are groups from which the configuration
parameter is inherited. If there is no name in the brackets, the parameter
is set directly in the neighbor configuration and not inherited. You can
view just the inherited group names with the show bgp neighbors <ipaddress> inheritance command.
Address family group, session group, and neighbor group configuration or
inheritance can be viewed in a similar manner using the show bgp
<group-type> <group-name> {configuration | inheritance}
command. Other options for configuring output allow defaulted parameter
values (defaults keyword) or an nvgen-style output (nvgen keyword) to be
viewed.
The overall operational state of BGP is best viewed using the show bgp
summary, show bgp neighbors, and show bgp update-group
commands.
1016
Version 2.0a
Module 10
show Commands
Effective neighbor configuration and inheritance

RP/0/0/CPU0:P3# show bgp neighbors 100.10.20.1 configuration
remote-as 65000
[n:internal]
password encrypted 121A0C041104 [n:internal]
update-source Loopback0
[n:internal]
[n:internal]
RP/0/0/CPU0:P3# show bgp neighbors 100.10.20.1 inheritance
Session:
n:internal
IPv4 Unicast: n:internal
Summary of BGP and neighbor status

RP/0/0/CPU0:P3# show bgp summary
BGP router identifier 100.10.20.3, local AS number 65000
BGP generic scan interval 60 secs
BGP main routing table version 1
BGP scan interval 60 secs
BGP is operating in STANDALONE mode.
Process
Speaker
Neighbor
100.10.20.1
100.10.20.2
RecvTblVer
1
bRIB/RIB
1
SendTblVer
1
Spk
AS MsgRcvd MsgSent
0 65000
2607
2608
0 65000
2600
2600
Version 2.0a
TblVer
1
1
InQ OutQ Up/Down St/PfxRcd

0
0
1d19h
0
0
0
1d19h
0
1017
Routing Protocols
Module 10
Cisco IOS and IOS XR Comparison

Prior to Cisco IOS versions 12.2(8)T and 12.3, routes advertised outside the
AS are summarized into classfull networks by the BGP software. This
legacy behavior is inherited from BGPv3 which had no mechanism to
express prefix length (mask). Thus BGPv3 advertised all routes as either
class A, B or C networks. BGPv4 introduced a prefix length to support
Classless InterDomain Routing (CIDR). Because CIDR and autosummarization potentially conflict, IOS XR drops all support for automatic
summarization.
By default, both Cisco IOS and Cisco IOS XR BGP software allow the
comparison of Multi-Exit Discriminator (MED) attribute values only for
paths from neighbors in the same AS. Both can be configured to compare
MEDs for paths from neighbors in different autonomous systems, although
the commands are slightly different. In Cisco IOS, you use bgp alwayscompare med; in Cisco IOS XR, you use bgp bestpath med always.
By default in both Cisco IOS and Cisco IOS XR, the clients of a route
reflector are not required to be fully meshed, and the routes from a client
are reflected to other clients. However, if the clients are fully meshed,
route reflection is not required. Use the no bgp client-to-client
reflection command to disable client-to-client reflection.
In Cisco IOS, the bgp deterministic-med command ensures the
comparison of the MED variable when choosing routes advertised by
different peers in the same AS because routes from the AS are grouped
together first and then the best entries of each group are compared.
Although not the default in Cisco IOS prior to versions 12.2(8)T and 12.3,
we recommend enabling the bgp deterministic-med command in all new
network rollouts. Cisco IOS XR BGP software always operates in
deterministic mode and cannot be configured otherwise.
1018
Version 2.0a
Module 10
Cisco IOS and IOS XR Comparison
Description
Cisco IOS
Cisco IOS XR
Automatically summarize
subnet routes into classfull
network (A, B, or C) routes
when advertising outside AS.
auto-summary was the

default
Automatic summarization is not

supported
Allow the comparison

of MED for paths from
neighbors in different
autonomous systems.
bgp always-compare-med is
used
bgp bestpath med always is

used
Restore route reflection from a

BGP route reflector to clients.
bgp client-to-client
reflection is the default
bgp client-to-client reflection

is the default
Select the best MED path

among paths advertised from
the neighboring AS.
no bgp deterministic-med
was the default
Version 2.0a
Only deterministic behavior is

supported
1019
Routing Protocols
Module 10
By default, logging the neighbor status changes (up or down) and reset
reason is disabled by default in Cisco IOS but enabled in Cisco IOS XR.
This information can be used for troubleshooting connectivity problems
and measuring network stability.
The default metric command sets the MED value to advertise to peers for
routes that do not already have a metric set (routes that were received
with no MED attribute). Neither Cisco IOS nor Cisco IOS XR set a metric
by default.
Community values are now commonly displayed as two 16-bit values
separated by a colon. Cisco IOS displays them as one 32-bit decimal word
by default unless the ip bgp new format command is used. Cisco IOS XR
always displays communities as two 16-bit words and cannot be configured
otherwise.
Filtering BGP route information in Cisco IOS can be accomplished by a
variety of commands, such as neighbor distribute-list, ip as-path
access-list, neighbor filter-list and route-map. In Cisco IOS XR, RPL
policies can replace or have replaced most of these commands. The prefixlist in command for use with ORF is one exception.
1020
Version 2.0a
Module 10
Cisco IOS and IOS XR Comparison (continued)
Description
Cisco IOS
Cisco IOS XR
Log the neighbor up, down, or

reset reason.
no bgp log-neighborchanges is the default
bgp log neighbor changes is

the default
Set the default MED value to

advertise to peers for routes
without an existing MED
attribute.
no default-metric is the
default
no default-metric is the default
Display the BGP community as

two 16-bit values in aa:nn
format.
no ip bgp new-format is the

default; community is
displayed as 32 bit value
Community is always displayed

in aa:nn format
Filter BGP route information as

specified in an access-list.
Use neighbor {ip-address |

peer-group-name}
distribute-list {access-listnumber | name} {in|out}
Distribute-list is not supported;

use prefix-list {name|number}
in for ORF capability or policy
{name} in|out in general case
Version 2.0a
1021
Routing Protocols
Module 10
By default in Cisco IOS, no community attributes are sent to any neighbor.

In Cisco IOS XR, communities are not sent to an EBGP neighbor by
default. However, communities are always sent to IBGP neighbors.
Standard or extended communities (or both) can be sent to neighbors in
Cisco IOS with the neighbor send-community command. In Cisco IOS
XR, the send-community-ebgp and send-extended-community-ebgp
commands accomplish the same for EBGP neighbors.
Cisco IOS XR supports only BGP version 4, unlike Cisco IOS, which
supports both versions 4 and 3 and dynamically negotiates the common
version between peers by default. Cisco IOS dynamic negotiation can be
disabled with the neighbor version command.
Cisco IOS peer groups, which support both common configuration and
operation, are replaced in Cisco IOS XR with neighbor groups (and address
family groups and session groups) for configuration and update groups for
operation. There are show commands to display all configuration groups,
group inheritance, and update groups.
When an AS provides transit service to other autonomous systems and
non-BGP routers are present in the AS, transit traffic might be dropped if
the intermediate non-BGP routers have not learned routes for that traffic
through an IGP. The BGP synchronization rule states that if an AS
provides transit service to another AS, BGP should not advertise a route
until all routers within the AS have learned about the route through an
IGP. This rule does not apply if all routers in the AS are running BGP.
Prior to Cisco IOS Software version 12.2(8)T and 12.3, synchronization was
enabled by default, but could be disabled with the no synchronization
command. In later releases, synchronization was disabled by default. In
Cisco IOS XR, synchronization is not supported and cannot be configured.
1022
Version 2.0a
Module 10
Cisco IOS and IOS XR Comparison (continued)
Description
Cisco IOS
Cisco IOS XR
Specify that community

attributes should be sent to a
BGP neighbor.
no neighbor {ip-address |
peer-group-name} sendcommunity is the default
no-send-community-ebgp and
no-send-extendedcommunity-ebgp are the
default; always send to IBGP
neighbors
Configure BGP to peer using

only a specific version.
neighbor {ip-address | peergroup-name} version

{value}; dynamic negotiation
is the default
Only BGP version 4 is

supported; no dynamic
negotiation
Display BGP peer-group

information.
Use show ip bgp peergroup {peer-group-name}
Effectively replaced by show

bgp update-group
Enable synchronization between

BGP and your IGP.
synchronization was the

default
Synchronization is not
supported
Version 2.0a
1023
Routing Protocols
Module 10
Distributed BGP (Future)

With a multishelf CRS-1 system capable of scaling to thousands of
interconnections, the possible BGP protocol processing and bestpath
calculation loads for a single BGP process might be overwhelming.
Distributed BGP is a feature that allows you to bring more CPU to bear on
the problem of receiving, computing, and sending BGP routing updates by
distributing the processing among multiple processes.
In distributed BGP mode, BGP processing is separated in to multiple
processes which can be distributed among available RP and DRP
resources. Because interprocess communication adds some overhead, which
may affect BGP performance for small systems, distributed speakers do not
have to be enabled. If no distributed speakers are enabled, BGP operates in
stand-alone mode, similar to the manner in which the Cisco IOS and Cisco
IOS XR release 3.2 BGP operates. If at least one distributed speaker is
enabled, BGP operates in distributed mode.
1024
Version 2.0a
Module 10
Distributed BGP (Future)
Handle 1000s of peers
Primary motivation is scalability

Separate into multiple processes
May impact performance of small systems
Additional IPC may cause degradation

Configurable for standalone mode of operation
Release 3.2 operation is only standalone
Version 2.0a
1025
Routing Protocols
Module 10
Distributed BGP Processes

The BGP processing load logical divides between protocol interaction with
neighbors (peer sessions) and bestpath calculation based on received
routes. The neighbor processing can further be subdivided by grouping
neighbors. Subsequently, the bestpath calculation steps can be split (before
the MED comparison) between processes handling peer sessions and a
common process doing the final comparison of all partially computed
bestpath routes.
BGP Speaker
The BGP speaker communicates with neighbors and is responsible for

inserting routes into the BGP RIB (bRIB). A given speaker has all the
routes learned from its peers and all bestpaths from all speakers. As many
as 15 speakers can be configured.
bRIB
The bRIB is the rendezvous point for the partial bestpaths sent to it by the
various speakers. It makes the ultimate routing decision, installs those
bestpath routes in the global RIB, and distributes them to all speakers.
1026
Version 2.0a
Module 10
Distributed BGP Processes
BGP speakerMultiple instances each handling

subset of peers
Communicates with peers (neighbors)

Considers only paths received from peers
Calculates partial bestpath up to MED comparison
BGP RIB (bRIB)Single process
Receives partial bestpaths from speakers

Computes final bestpaths and installs them in RIB
Sends final bestpaths to speakers
Peers
Speaker
Partial
bestpaths
Final
bestpaths
bRIB
RIB
Final
bestpaths
Peers
Speaker
Partial
bestpaths
Version 2.0a
1027
Routing Protocols
Module 10
Open Shortest Path First (OSPF)

Feature Support
The Cisco IOS XR implementation of Open Shortest Path First (OSPF)
conforms to the OSPF version 2 and OSPF version 3 specifications,
detailed in the Internet RFC 2328 and RFC 2740 respectively. The
following are key features of the Cisco IOS XR OSPF implementation:
HierarchyCLI configuration hierarchy is supported.
InheritanceCLI configuration inheritance is supported.
Stub areasStub areas are supported.
Not-So-Stubby-Areas (NSSA) RFC 1587 is supported.
Virtual linksVirtual links are supported.
OSPF over demand circuitsRFC 1793 is supported.
Non-Stop Forwarding (NSF) NSF is supported for OSPFv2.
Shortest Path First (SPF) throttlingSPF throttling is supported.
Route redistributionRoutes learned by any IP routing protocol can be
redistributed into any other IP routing protocol.
AuthenticationPlain text and Message Digest 5 (MD5) authentication
among neighboring routers within an area is supported for OSPFv2 but not
supported for the OSPFv3 protocol.
Routing interface parametersConfigurable interface parameters,
such as metric, retransmission interval, transmit delay, router priority,
dead interval, hello interval, and authentication key are supported.
1028
Version 2.0a
Module 10
Feature Support
IS-IS
BGP
Static
Area 2
Area 3
NSSA
ASBR
Internal
Internal
ABR
ABR
Virtual
Link
Area 4
Stub
Area 0
Backbone
ABR
ABR
Internal
Internal
BBone
Passive
Area 1
Standard OSPFv2 and OSPFv3
Version 2.0a
1029
Routing Protocols
Module 10
CLI Differences
Cisco IOS XR OSPF configuration differs from that of Cisco IOS by using a
hierarchical CLI with inheritance of parameter values.
Hierarchical CLI
Hierarchical CLI is the grouping of related network component
information at defined hierarchical levels - OSPF router, area and
interface level:
router ospf lab
area 0
interface pos0/4/0/1
The router configuration prompt tells you what level you are at in the
configuration hierarchy. The following router prompt indicates that you
are in OSPF process (ospf), area (ar), and interface (if) configuration
submode:
RP/0/0/CPU0:router(config-ospf-ar-if)#
Hierarchical CLI allows for easier maintenance and troubleshooting of

OSPF configurations. When configuration commands are displayed
together in their hierarchical context, visual inspections are simplified.
Also, hierarchical CLI is intrinsic for CLI inheritance to be supported.
CLI Inheritance
In Cisco IOS XR, some OSPF parameter values can be inherited from a
higher level of the OSPF configuration hierarchy. With CLI inheritance
support, you do not have to explicitly configure a parameter for an area or
interface if it was defined at a higher level unless you want to set a
different value. For example, some parameters, like the hello interval of
interfaces in the same area, can be inherited from the area or router OSPF
process configuration level:
If the hello interval command is configured at the interface configuration
level, use the interface-configured value; else
If the hello interval command is configured at the area configuration
level, use the area-configured value; else
If the hello interval command is configured at the router OSPF process
configuration level, use the OSPF process-configured value; else
Use the default value.
1030
Version 2.0a
Module 10
CLI Differences
Hierarchical OSPF configuration with inheritance
router ospf
area
interface
virtual-link
OSPF configuration parameters are grouped at levels under the

router (process) instance
router ospf lab
area 0 (all OSPF areas for instance configured here)
interface pos0/4/0/1 (all OSPF interfaces in area configured here)
cost 20 (all OSPF parameters for interface configured here)
Values for certain parameters specified in a higher level are

inherited by lower levels
RP/0/RP0/CPU0:router(config-ospf)# hello-interval 40
(specified here at process level and inherited by OSPF interfaces)
Version 2.0a
1031
Routing Protocols
Module 10
Configuration Differences
The key differences in OSPF configuration commands between Cisco IOS
and Cisco IOS XR are:
1032
Areas are explicitly configured. The area command enters area

configuration submode to configure OSPF area parameters and
interfaces.
Area commands no longer have an area prefix. For example, the area
authentication command is now just authentication.
In Cisco IOS, interfaces are configured with the network area

command for a single OSPF area. In Cisco IOS XR, OSPF interfaces are
configured explicitly in an area. The interface command in the area
submode performs this functionality.
The OSPF interface command specifies only the interface type and
number.
Interface parameter configuration commands no longer have an ip ospf

prefix. For example, the ip ospf cost command is now just cost.
Cisco IOS XR OSPF supports Packet over SONET (POS) as a point-topoint network type and Ethernets as broadcast network type.
Alternately, both can be configured as a nonbroadcast (NBMA) network
type with the network non-broadcast command.
Point-to-multipoint, nonbroadcast networks (ATM and Frame Relay)

are not currently supported.
The neighbor command configures OSPF neighbors on NBMA

networks as in Cisco IOS. However, the neighbor command is entered
in the interface submode.
The timers spf command is similar to the Cisco IOS timers throttle
spf command.
Version 2.0a
Module 10
Configuration Differences
Router(config)# interface pos0/0/0

Router(config-if)# ip address 10.1.1.1 255.255.255.252
Router(config-if)# ip ospf cost 20
Router(config-if)# exit
Router(config-if)# ip address 10.1.1.5 255.255.255.252
Router(config-if)# ip ospf cost 40
!
Router(config)# router ospf 1
Router(config-router)# network 10.1.1.0 0.0.0.255 area 0
Cisco IOS
RP/0/RP0/CPU0:router(config)# interface pos0/4/0/0

RP/0/RP0/CPU0:router(config-if)# ip address 10.1.1.1 255.255.255.252
RP/0/RP0/CPU0:router(config-if)# exit
RP/0/RP0/CPU0:router(config-if)# ip address 10.1.1.5 255.255.255.252
!
RP/0/RP0/CPU0:router(config)# router ospf 1
RP/0/RP0/CPU0:router(config-ospf)# area 0
RP/0/RP0/CPU0:router(config-ospf-ar)# cost 20
RP/0/RP0/CPU0:router(config-ospf-ar)# interface pos0/4/0/0
RP/0/RP0/CPU0:router(config-ospf-ar-if)# exit
RP/0/RP0/CPU0:router(config-ospf-ar-if)# cost 40
Cisco IOS XR
Instructor's Note
Through IOS XR R3.1, the same interface (POS, GigE) can be configured in multiple OSPF
instances. This is considered a design deficiency that should be corrected in R3.2.
Version 2.0a
1033
Routing Protocols
Module 10
Differences for OSPFv3

The key differences between the Cisco IOS XR OSPFv3 and Cisco IOS
OSPF for IPv6 are:
Cisco IOS XR uses the term OSPFv3 to indicate OSPF for IPv6 in the
CLI and configuration tasks. Cisco IOS uses the OSPF for IPv6 term
in documents and the ipv6 keyword is appended to commands.
Features not currently supported for OSPFv3:

-
SNMP OSPFv3 MIB

Nonstop Forwarding (NSF)
MPLS Traffic Engineering (MPLS-TE)
MPLS Virtual Private network (VPN)
XML configuration
Graceful shutdown
Incremental SPF
Differences between Cisco IOS XR OSPFv3 and v2

Much of the Cisco IOS XR OSPFv3 feature support and configuration is the
same as for OSPFv2. The key differences are:
1034
OSPFv3 expands on OSPFv2 to provide support for IPv6 routing

prefixes and the larger size of IPv6 addresses.
Manually configured neighbors for an OSPFv3 NBMA interface are

identified by their link local address on the NBMA network.
Unlike OSPFv2, multiple instances of OSPFv3 can be run on a link.
OSPFv3 Link State Advertisements (LSAs) are expressed as prefix

and prefix length instead of address and mask.
The router ID is a 32-bit number with no relationship to an address.
OSPFv3 does not support route maps, but RPL will be supported postFCS.
Version 2.0a
Module 10
Differences for OSPFv3
Cisco IOS configuration

Router(config-if)# ipv6 address 2002:1234::212/64
Router(config-if)# ipv6 ospf 1 area 0
Router(config-if)# ipv6 ospf cost 20
!
Router(config)# ipv6 router ospf 1
Router(config-router)# router-id 1.2.3.4
Cisco IOS XR configuration

RP/0/RP0/CPU0:router(config-if)# ipv6 address 2002:1234::212/64
!
RP/0/RP0/CPU0:router(config)# router ospfv3 1
RP/0/RP0/CPU0:router(config-ospf)# router-id 1.2.3.4
RP/0/RP0/CPU0:router(config-ospf-ar-if)# cost 20
Version 2.0a
1035
Routing Protocols
Module 10
Configuring OSPF
OSPF is enabled from the global configuration mode.
Step 1router ospf Command

Use the router ospf command to enable OSPFv2 routing for the specified
routing instance and place the CLI in router configuration mode.
Alternatively, specifying the ospfv3 keyword enables OSPFv3 routing for
the specified routing instance.
_____________________________ Note _________________________
The instance name is any alphanumeric string no longer than 40
characters without spaces. You can specify multiple OSPF routing
processes in each router. All OSPF configuration commands must be
configured under an OSPF routing process.
_________________________________________________________________
1036
Version 2.0a
Module 10
Configuring OSPFrouter ospf Command
Step 1Configure OSPF instance (process)

router (config) #
router ospf instance-name
RP/0/RP0/CPU0:router(config)# router ospf 1
or
router ospfv3 instance-name
RP/0/RP0/CPU0:router(config)# router ospfv3 1
Version 2.0a
1037
Routing Protocols
Module 10
Step 2router-id Command

To configure a router ID for the OSPF process, use the router-id command
in router configuration mode. To cause the software to use the default
method of determining the router ID, use the no form of this command.
OSPF attempts to obtain a router ID from the following sources, in order of
decreasing preference:
1. The 32-bit numeric value specified by the OSPF router-id command in
router configuration mode.
This value can be any 32-bit value. It is not restricted to the IPv4
addresses assigned to interfaces on this router, and need not be a
routable IPv4 address.
2. The primary IPv4 address of the interface specified by the OSPF
router-id command.
3. The 32-bit numeric value specified by the router-id command in global
configuration mode.
_____________________________ Note _________________________
It is good practice to use the router-id command to explicitly specify a
unique 32-bit numeric value for the router ID. This action ensures that
OSPF can function regardless of the interface address configuration.
_________________________________________________________________
Step 3area Command

To configure an OSPF area, use the area command in router configuration
mode. The router enters area configuration mode.
_____________________________ Note _________________________
The area-id argument can be entered in decimal or dotted decimal
(IPv4 address) notation, such as area 1000 or area 0.0.3.232.
_________________________________________________________________
1038
Version 2.0a
Module 10
Configuring OSPFrouter-id and area Commands
Step 2Optionally configure the OSPF router id

router (config-ospf)#
router-id {ipv4-address | interface-type interface-number}
RP/0/RP0/CPU0:router(config-ospf)# router-id 172.20.10.10
Step 3Configure OSPF area

area area-id
Version 2.0a
1039
Routing Protocols
Module 10
Step 4interface Command

To associate a specific interface with an OSPF instance, use the interface
command. This command places the router in interface configuration mode
(prompt: config-router-ar-if), from which you can configure interfacespecific settings. Commands configured under this mode, such as the cost
command, are automatically bound to that interface. This method of
defining interfaces is one of the main differences in Cisco IOS XR.
1040
Version 2.0a
Module 10
Configuring OSPFinterface Command
Step 4Configure OSPF interface in area submode

router (config-ospf-ar)#
interface interface-type interface-number
RP/0/RP0/CPU0:router(config-ospf-ar)# interface POS 0/4/0/1
Repeat step 4 for each interface in this OSPF area
Instructor's Note
OSPF can be configured on MgmtEth interfaces. If both Mgmt Eth interfaces are configured
with compatible OSPF parameters (hello interval, dead interval, etc.), an adjacency will be formed
between them. This results in both interfaces being represented in the router LSA as links to the
same transient network. Normally an OSPF router rejects received hellos with the same router
ID, however the OSPF specification allows this special case for multiple interfaces on the same
network.
Interestingly however, in the same scenario with IS-IS no adjacency will form.
Version 2.0a
1041
Routing Protocols
Module 10
Step 5Interface-level Command Example

Parameters values specific to the operation of this OSPF interface, such as
cost, dead interval, hello interval, retransmit interval, and priority can be
set in the area interface configuration submode.
dead-interval Command
To set the interval during which not seeing hello packets causes the router
to declare the neighbor down, use the dead-interval command. The dead
interval can be specified at the process, area, or interface level. If the dead
interval is specified at the process level, it is inherited by all areas under
that process and all interfaces in each of the areas. If the dead interval is
not set explicitly, it defaults to 30 seconds.
1042
Version 2.0a
Module 10
Configuring OSPFInterface-level Command Example
Step 5Configure OSPF interface parameters in the interface submode

router (config-ospf-ar-if)#
dead-interval seconds
RP/RO0/0/CPU0:router(config-ospf-ar-if)# dead-interval 40
Version 2.0a
1043
Routing Protocols
Module 10
MD5 Authentication
To enable MD5 authentication for the OSPF process, use the
authentication message-digest command at the router command mode.
This authentication type applies to the operation of all interfaces for the
entire router process unless overridden at a lower hierarchical level, such
as the area or interface. For example, no authentication can be established
on a specific interface if the authenticate null command is used in the
interface submode for that interface.
The message-digest-key command must be used with the
authentication message-digest command to establish keying
information for the MD5 operation. Again, this command can apply to the
OSPF process, area, or interface.
_____________________________ Note _________________________
Your neighbor router must have the same key identifier (key-id).
_________________________________________________________________
1044
Version 2.0a
Module 10
MD5 Authentication
authentication [message-digest | null]
RP/0/RP0/CPU0:router(config-ospf)# authentication message-digest
message-digest-key key-id md5 [encryption-type] key
RP/0/RP0/CPU0:router(config-ospf)# message-digest-key 4 md5 key1
Version 2.0a
1045
Routing Protocols
Module 10
MD5 Configuration Comparison

In Cisco IOS, the area authentication message-digest command is used
only in the router configuration mode and applies to all interfaces in the
area. The ip ospf message-digest-key command is specified only in the
interface configuration.
In the IOS XR configuration on the facing page, the authentication
command is applied at the area configuration for all interfaces in that area,
but could also be used in the router configuration to apply to all interfaces
in all areas for that OSPF instance (process) or at the OSPF interface
configuration submode for only that interface. The message-digest-key
command is applied in the OSPF interface configuration only for
POS0/4/0/0, but could also be used in the area and router configuration
levels.
1046
Version 2.0a
Module 10
MD5 Configuration Comparison
Cisco IOS OSPF
Cisco IOS XR OSPF
interface Loopback1
ip address 10.234.2.6 255.255.255.255
!
interface POS4/0
ip address 10.50.40.1 255.255.255.0
ip ospf message-digest-key 5 md5
ospf-key
!
router ospf 100
log-adjacency-changes detail
nsf
area 0 authentication message-digest
passive-interface Loopback1
network 10.50.40.0 0.0.0.255 area 0
network 10.234.2.6 0.0.0.0 area 0
interface Loopback1
ip address 10.234.2.6 255.255.255.255
!
ip address 10.50.40.1 255.255.255.0
!
router ospf 100
log adjacency changes detail
nsf
area 0
authentication message-digest
interface Loopback1
passive enable
message-digest-key 5 md5 ospf-key
Version 2.0a
1047
Routing Protocols
Module 10
Intermediate System-Intermediate System (IS-IS)

Changes made to IS-IS architecture in Cisco IOS XR include the following:
A new hierarchical configuration structure is supported. Cisco IOS XR

groups all IS-IS configuration in the router configuration mode,
including all interface configuration associated with IS-IS. This
grouping makes the IS-IS configuration process clearer and removes
some of the clutter from the global interface configuration.
Unlike Cisco IOS, Cisco IOS XR supports multiple independent IS-IS

instances. Each IS-IS instance can support a single level 1 or level 2
area or one of each and routes can be redistributed between instances.
You can configure as many IS-IS instances for each logical router (LR)
as your system network resources allow. Each interface within an LR
can be associated with only one IS-IS instance.
__________________________ Note _________________________
If Multi-Protocol Label Switching (MPLS) is configured for use with
IS-IS, it can be enabled for one IS-IS instance only because MPLS is
not multi-instance aware.
______________________________________________________________
Unlike Cisco IOS, Cisco IOS XR supports multitopology as the default

behavior when more than one address-family is configured and single
topology must be explicitly configured. In Cisco IOS, single topology is
the default behavior and multitopology must be explicitly configured.
The multitopology transition mode is not supported.
One consequence of this change is that single-topology configuration is
slightly more complicated. You now must explicitly configure the
address family in some contexts where it could be assumed in Cisco
IOS.
Cisco IOS XR brings other changes by not supporting certain Cisco IOS
functionality and requiring different configuration:
1048
Cisco IOS XR IS-IS supports IP but not OSI Connectionless Network

Service (CLNS) routing.
Passwords on SNP packets are validated by default.
Some commands and keywords have changed to increase the

consistency of the configuration syntax.
Version 2.0a
Module 10
Architecture changes
Hierarchical configuration
Multiple IS-IS instances
Multi-topology as the default behavior
Other changes
IS-IS supports only IP routingno CLNS routing
SNP password validation done by default
Command and keyword consistency changes
Instructor's Note
Although not a hard configuration limit, internal testing of IS-IS was limited to 8 instances.
Version 2.0a
1049
Routing Protocols
Module 10
CLI Differences
The hierarchical Cisco IOS XR CLI results in easier and more logical
configuration. All IS-IS configuration is done and viewed under the IS-IS
routing process, enabling a more deductive flow of commands. IS-IS
interface configuration that was done in Cisco IOS under the global
interface configuration is now accomplished in an interface configuration
submode under the IS-IS router configuration. IPv4 and IPv6 topology
configuration is also accomplished in an address family submode under the
router configuration for instance (process-wide) parameters and under the
IS-IS interface configuration for interface-specific parameters.
_____________________________ Note _________________________
Although a logical hierarchy exists in the IS-IS configuration, no
support exists yet for inheritance of parameter values in the same way
there is for OSPF.
_________________________________________________________________
In general, there are some consistency changes with the CLI syntax in the
IS-IS implementation from Cisco IOS to Cisco IOS XR. Some commands,
keywords, and arguments have changed. Most have the same name, but
may be found in different locations (configuration submodes) due to the
new hierarchical structure.
Some attributes can be associated with IS-IS level 1 or level 2 area
operation. In those cases, such as hello-interval, the level [1|2] form of
the command is used. If the level designation is omitted, the attribute is
associated with both levels by default. In other cases where a tristate value
occurs for an attribute, that is, the Intermediate System is-type can be
level 1 or level 2 or both, Cisco ISO XR uses [level-1|level-2 |level-1-2].
This syntax also allows something other than level-1-2 to be the default.
1050
Version 2.0a
Module 10
CLI Differences
Hierarchical IS-IS configuration but no inheritance
router isis
address-family
interface
address-family
Consistency changes in commands and keywords

RP/0/RP0/CPU0:router(config)# router isis lab
RP/0/RP0/CPU0:router(config-isis)# is-type level-1-2
RP/0/RP0/CPU0:router(config-isis)# address-family ipv4 unicast
RP/0/RP0/CPU0:router(config-isis-af)# distance 100
RP/0/RP0/CPU0:router(config-isis-af)# exit
RP/0/RP0/CPU0:router(config-isis)# interface POS0/4/0/0
RP/0/RP0/CPU0:router(config-isis-if)# hello-interval 5 level 1
RP/0/RP0/CPU0:router(config-isis-if)# address-family ipv4 unicast
RP/0/RP0/CPU0:router(config-isis-if-af)# metric 7
Version 2.0a
1051
Routing Protocols
Module 10
Multiple Instance Example

The router in the middle of the facing page is an inter-area border router
connecting two Level 1 areas to the backbone Level 2 area. Since a single
IS-IS instance can only support one each Level 1 and Level 2 area,
multiple IS-IS instance must be configured to implement this topology. The
IS-IS implementation in Cisco IOS could not support this since multiple
instance of IS-IS could not be configured.
In Cisco IOS XR, the most flexible solution is to configure an IS-IS instance
for each Level 1 area and another instance for the backbone Level 2 area.
If additional Level 1 areas needed to be connected to the backbone through
this router in the future, another instance could be created for each.
1052
Version 2.0a
Module 10
Multiple Instance Example
Level 2 Area 49.0003
1 Level 2 instance
2 Level 1 instances
Version 2.0a
1053
Routing Protocols
Module 10
You can configure as many IS-IS instances as your system network

resources (memory and interfaces) allow. The IS-IS router configuration
syntax requires a unique <instance-id>, permitting you to configure the
parameters for each IS-IS routing instance separately.
To redistribute routes between IS-IS instances, you can use the
redistribute command in address family configuration mode. Because the
Routing Information Base (RIB) defaults routes from each IS-IS instance
to the same administrative cost, you must be careful when redistributing
routes between different IS-IS instances. Since the RIB does not know to
prefer Level 1 routes over Level 2 routes between instances of IS-IS, if you
are running separate Level 1 and Level 2 instances, you should enforce
preferences by configuring different administrative distances.
Instructor's Note
In the configuration on the opposite page, weve set the IS-IS attached bit on all LSPs being
advertised by r1 and r2 into their respective Level 1 areas. The destinations in those Level 1 areas
are being redistributed into r3 for advertisement as internal routes to other routers in the
backbone Level 2 area. r3 will be knowledgeable about Level 2 area topology and any destinations
in other connected Level 1 areas.
1054
Version 2.0a
Module 10
Multiple Instance Example (continued)
RP/0/RP0/CPU0:router# show running router isis

router isis r1
is-type level-1
net 49.0001.0000.0000.0001.00
set-attached-bit
!
!
!
!
!
!
--More--
router isis r2
is-type level-1
net 49.0002.0000.0000.0002.00
set-attached-bit
!
!
!
!
router isis r3
is-type level-2-only
net 49.0003.0000.0000.0003.00
redistribute isis r1 level-2 metric 0 metric-type internal
redistribute isis r2 level-2 metric 0 metric-type internal
distance 116
!
!
!
!
Version 2.0a
1055
Routing Protocols
Module 10
Other Configuration Examples

In the first example, we configure the IS-IS instance lab and set the global
IPv4 address family parameter for the administrative distance that should
be set in the RIB for all routes learned by this instance.
In the second example, we configure the same IS-IS instance and allow
propagation (also known as leaking) of IPv4 routes learned by the level 2
area into the level 1 area. Routes propagated into the level 1 area are
restricted using the L21 distribute (access) list. Again, this example shows
the hierarchical structure of IS-IS configuration.
1056
Version 2.0a
Module 10
Other Configuration Examples
Setting instance-wide address family specific values

RP/0/RP0/CPU0:router(config-isis)# address-family ipv4
RP/0/RP0/CPU0:router(config-isis-af)# distance 10
Propagating (leaking) routes from Level 2 into Level 1

RP/0/RP0/CPU0:router(config)# ipv4 access-list L21 permit ip 10.0.0.0 255.0.0.0
10.1.0.1 0.255.255.255
RP/0/RP0/CPU0:router(config-isis)# is-type level-1-2
RP/0/RP0/CPU0:router(config-isis)# address-family ipv4
RP/0/RP0/CPU0:router(config-isis-af)# propagate level 2 into level 1 distribute-list
L21
Version 2.0a
1057
Routing Protocols
Module 10
Configuration Comparison
In comparing the equivalent Cisco IOS and Cisco IOS XR configurations on
the facing page, the effect that the new hierarchical structure has had on
the location of commands like metric-style and passive should be readily
apparent. Command name changes, such as domain-password and
area-password consolidated to lsp-password with a level keyword, are
also obvious. Notice that the Cisco IOS log-adjacency-changes command
is essentially the same and now is not a single command, but rather a
command log with the required keywords adjacency changes.
1058
Version 2.0a
Module 10
Cisco IOS ISIS-IS:

interface Loopback0
ip address 10.234.1.6 255.255.255.255
ip router isis hfr
!
router isis hfr
passive-interface Loopback0
net 49.1111.1111.0001.0000.0c00.0006.00
metric-style wide
Cisco IOS XR ISIS-IS:

router isis hfr
net 49.1111.1111.0001.0000.0c00.0006.00
metric-style wide
!
interface Loopback0
passive
!
!
Cisco IOS ISIS-IS:

interface POS4/0
ip address 10.50.40.1 255.255.255.0
ip router isis hfr
!
router isis hfr
net 49.1111.1111.0001.0000.0c00.0006.00
domain-password domainpw authenticate snp validate
area-password areapw authenticate snp validate
log-adjacency-changes
nsf ietf
Cisco IOS XR ISIS-IS:

router isis hfr
net 49.1111.1111.0001.0000.0c00.0006.00
nsf ietf
log adjacency changes
lsp-password areapw level 1
lsp-password domainpw level 2
!
!
Version 2.0a
1059
Routing Protocols
Module 10
Debugging
Debugging is done from the EXEC prompt, just as in Cisco IOS. The
primary debugging flags are the main troubleshooting categories for Cisco
IOS. They allow you to select a feature of IS-IS and troubleshoot that
particular subprocess of IS-IS. Every main troubleshooting category has
subcategories where flags can be set to filter more specific events within a
subprocess. The flags contained under the primary options are category
specific, which means, for example, that the detail or interface flag that is
available under one subcategory of debugging might not be available under
another subcategory. This methodology follows the same troubleshooting
process that Cisco IOS does.
Filters can be designed to help narrow the troubleshooting process, either
by combining a sequence of debug commands to obtain information about
several subprocesses running or limiting the information displayed using
specific flags contained in the CLI. For example, you can use debug isis
adjacencies to enable debugging output for adjacency events. The
optional interface <type> < number> keyword identifies debugging
information for a specific interface, and the optional keyword detail
enables detailed debugging output.
Instructor's Note
While testing debug isis adjacencies with IOS XR R2.0, the detail keyword didnt seem to have
any effect on the specifics of the debug output; it appeared to be the same with or without the
keyword.
1060
Version 2.0a
Module 10
Debugging
RP/0/RP0/CPU0:router# debug isis ?

adjacencies
Maintenance of adjacencies including the sending and receiving of
hello packets
configuration Configuration, including interface events
dis-elections Designated IS Elections on LAN interfaces
instance
Filter IS-IS debug by instance
local-updates Generation of local system and pseudo-node LSPs
mpls
MPLS Traffic Engineering Information
packet-errors Format, checksum and authentication errors in received packets
route
Maintenance of IS-IS's local routing table
spf
Route calculations, including incremental SPFs and PRCs
startup
Process initialization (both NSF restarts and cold starts)
update
Synchronization of the LSP DB with neighbors. Includes LSP and SNP
packet processing
RP/0/RP0/CPU0:router# debug isis adjacencies ?

detail
Detail incoming hello handling and outgoing hello generation
interface Filter IS-IS debug by interface
level
Filter IS-IS debug by level
lsp-id
Filter IS-IS debug by LSP ID
restarts
Processing of neighbors' restart requests
summary
Adjacency state changes only
topology
Filter IS-IS debug by topology
<cr>
The following debug shows an interface flap on a point-to-point network

RP/0/RP0/CPU0:POD2# debug isis adjacencies
Aug 2 12:23:04.226 : isis[212]: %ISIS-4-ADJCHANGE : Adjacency to POD3 (POS0/4/0/1) (L1)
Down, Interface state down
Aug 2 12:23:29.510 : isis[212]: %ISIS-4-ADJCHANGE : Adjacency to POD3 (POS0/4/0/1) (L1) Up,
New adjacency
The same debug shows a new adjacency formed on a broadcast network

RP/0/RP0/CPU0:router# debug isis adjacencies
SLOT2:Jan 8 15:14:31.059 :isis[137]: New adjacency (router-gsr5.00), level 2, for
0003.6cff.0680 (MgmtEth0/0/CPU0/0)
SLOT2:Jan 8 15:14:33.071 :isis[137]: Adjacency (router-gsr5.00) state goes to Up
SLOT2:Jan 8 15:14:33.083 :isis[137]: New level 2 DR router-gsr6 on MgmtEth0/0/CPU0/0
SLOT2:Jan 8 15:14:36.747 :isis[137]: New adjacency (router-gsr5.00), level 1, for
0003.6cff.0680 (MgmtEth0/0/CPU0/0)
SLOT2:Jan 8 15:14:44.971 :isis[137]: Adjacency (router-gsr5.00) state goes to Up
SLOT2:Jan 8 15:14:44.983 :isis[137]: New level 1 DR router-gsr6 on MgmtEth0/0/CPU0/0
Version 2.0a
1061
Routing Protocols
Module 10
Multicast Routing
The nonhierarchical multicast configuration in Cisco IOS is replaced in
Cisco IOS XR with a hierarchical-structured CLI that groups each
multicast protocol configuration. Basic multicast operation is configured
under the multicast routing configuration submode and interfaces must be
explicitly enabled.
Internet Group Management Protocol (IGMP) operation is enabled
automatically when an interface is configured for multicast routing. Cisco
IOS XR defaults IGMP to version 3 operation unlike Cisco IOS which
defaults to version 2. Versions 1 and 2 can be configured per interface.
Protocol Independent Multicast (PIM) operation is also enabled
automatically when an interface is configured for multicast routing. Cisco
IOS XR supports sparse mode (SM), source-specific multicast (SSM), and
bidirectional (bidir) PIM operation but not dense mode (DM) configuration.
IOS XR PIM does not support a rate mechanism for switching to the
Shortest Path Tree (SPT). The default behavior switches immediately upon
receiving the initial multicast packet from the Rendezvous Point (RP) for a
SM group. Alternatively, you can force the forwarding to stay on the
shared tree using the spt-threshold infinity command in the router PIM
configuration submode.
Multicast Source Discovery Protocol (MSDP) operation is similar to that in
Cisco IOS except that, in Cisco IOS XR, Source-Active (SA) messages are
sent to peers automatically instead of waiting for an SA request.
For Cisco IOS XR Release 3.2, both IPv4 and IPv6 multicast is supported
on the Cisco CRS-1.
1062
Version 2.0a
Module 10
Multicast Routing
Hierarchical configuration
Specific router protocol modes
Interfaces must be explicitly enabled
IGMP
Defaults to Version 3
PIM
No dense mode configuration
No rate mechanism for switching to Shortest Path Tree
MSDP
Initiates Source Active messages
IPv4 and IPv6 multicast on CRS-1 at Release 3.2
Instructor's Note
PIM dense mode operation is actually supported for Ciscos auto-RP protocol but can not be
configured for user multicast traffic.
In case a student asks, IOS XR IPv6 multicast is not yet supported on the XR 12000 platform.
Version 2.0a
1063
Routing Protocols
Module 10
CLI Differences
Cisco IOS XR multicast routing also uses a hierarchical configuration
architecture. Multicast protocol-specific configuration has been grouped
under the appropriate router process (IGMP, PIM, or MSDP) level
submode. Interface configuration commands entered in the router process
mode are inherited on all protocol interfaces, unless specifically changed at
the protocol interface level configuration submode.
Most configuration parameters have remained the same (with elimination
of the Cisco IOS ip <protocol> prefix in the command). Some new show
and debug commands have been added.
1064
Version 2.0a
Module 10
Multicast Routing
CLI Differences
Hierarchical multicast configuration with inheritance

multicast-routing
router igmp
router pim
router msdp
interface
interface
interface
peer
Values for certain parameters specified at router

process level are inherited by lower level
RP/0/RP0/CPU0:router(config)# router pim
RP/0/RP0/CPU0:router(config-pim-ipv4)# hello-interval 420
RP/0/RP0/CPU0:router(config-pim-ipv4)# interface POS0/4/0/0
RP/0/RP0/CPU0:router(config-pim-ipv4-if)# hello-interval 210
Version 2.0a
1065
Routing Protocols
Module 10
Configuring Multicast
To configure multicast routing in Cisco IOS XR, first use the multicastrouting command in the global router configuration mode. Next, specify
the interfaces that are enabled for multicast, using the interface
<type><number> command to enter the interface configuration submode.
To activate multicast routing on interfaces, you must explicitly enable
them in the interface configuration submode with the enable command.
Alternatively, the interface all enable command entered in the router
configuration mode can activate multicast operation on all interfaces.
To turn off multicast routing on a particular interface, use the disable
command in the interface configuration submode.
In Cisco IOS XR, IGMP and PIM are activated by default on all interfaces
that are enabled for multicast, unless they are explicitly disabled in the
router pim or router igmp interface configuration submode.
_____________________________ Note _________________________
Although you can enable management Ethernet (MgmtEth) interfaces
for multicast routing and configure multicast routing protocols, no
multicast forwarding or protocol operation takes place on those
interfaces. Multicast operation is coded off and cannot be activated.
_________________________________________________________________
1066
Version 2.0a
Module 10
Multicast Routing
Configuring Multicast
RP/0/0/CPU0:router(config)#
Configure IPv4 multicast routing
RP/0/RP0/CPU0:router(config)# multicast-routing
RP/0/0/CPU0:router(config-mcast-ipv4)#
Enable all interfaces to take part in multicast
RP/0/RP0/CPU0:router(config-mcast-ipv4)# interface all enable
RP/0/0/CPU0:router(config-mcast-ipv4)#
Disable a specific interface from taking part in multicast
RP/0/RP0/CPU0:router(config-mcast-ipv4)# interface POS0/4/0/0
RP/0/RP0/CPU0:router(config-mcast-ipv4-if)# disable
Version 2.0a
1067
Routing Protocols
Module 10
PIM Configuration
To configure PIM-specific parameters on your router, use the router pim
command in the global configuration mode. All other PIM commands are
entered in the router PIM (process) submode or the PIM interface submode
below the PIM process. This configuration is necessary only if you want to
change the default operation of PIM, which is automatically enabled on all
active multicast interfaces unless otherwise disabled.
If your router is not an RP and cannot learn necessary RP addresses using
auto-RP operation, which is enabled by default, configure static RP
addresses using the rp-address command in the router PIM submode.
1068
Version 2.0a
Module 10
Multicast Routing
PIM Configuration
RP/0/0/CPU0:router(config)#
Configure PIM-specific behavior
RP/0/RP0/CPU0:router(config)# router pim
RP/0/0/CPU0:router(config-pim-ipv4)#
Make sure loopback is

advertised by IGP
Configure the RP addressuse the loopback address

RP/0/RP0/CPU0:router(config-pim-ipv4)# rp-address 1.1.1.1
Version 2.0a
1069
Routing Protocols
Module 10
If your router is a potential RP, you need to configure it as a candidate RP

(CRP). With autoRP operation, CRPs announce their availability as RPs.
The CRPs send their announcements to the well-known group 224.0.1.39.
The RP mapping agent listens to the announced packets from the CRPs
and then sends RPtogroup mappings in a discovery message to the wellknown group 224.0.1.40. Use the auto-rp candidate-rp and auto-rp
mapping-agent commands, as necessary, to configure auto-RP operation
for your router.
_____________________________ Note _________________________
When choosing an interface to configure as a static Rendezvous Point
(RP) or from which to source Auto-RP Candidate Rendezvous Point
(CRP) announcements, we highly recommend that you use an interface,
such as a loopback, instead of a physical interface. If you choose a
physical interface, you are relying on that interface to be up since the
router stops performing as the RP in the static RP case or stop
advertising itself as the RP for Auto-RP after the physical interface
goes down. A loopback interface, however, is always up, thus ensuring
the RP continues to advertise itself through any available interfaces as
an RP, even if one or more of its physical interfaces should fail. The
loopback interface must have PIM enabled and be advertised through
an Interior Gateway Protocol (IGP).
_________________________________________________________________
Finally, configure any nondefault parameter values for a specific PIM
interface by using the interface <type><number> command to enter the
interface configuration submode. Then, use commands like hello-interval
and dr-priority to set attributes unique to that PIM interface.
After you have completed these basic configuration steps, you should check
to see that PIM is running in your network.
1070
Version 2.0a
Module 10
Multicast Routing
PIM Configuration (continued)
Configure PIM auto-RP candidate RP and mapping agent as necessary
RP/0/RP0/CPU0:router(config-pim-ipv4)# auto-rp candidate-rp
loopback 0 scope 16
RP/0/RP0/CPU0:router(config-pim-ipv4)# auto-rp mapping-agent
loopback 0 scope 16
Configure any PIM interface-specific parameters
RP/0/RP0/CPU0:router(config-pim-ipv4)# interface POS0/4/0/0
RP/0/RP0/CPU0:router(config-pim-ipv4-if)# hello-interval 100
Instructor's Note
Although auto-RP is a non-standard (non-RPF-based) function requiring dense mode PIM
operation to advertise control traffic, it provides an important failover advantage that static RP
assignment does not. With auto-RP, you can configure multiple routers as RP candidates. Should
the elected RP stop operating, one of the other preconfigured routers takes over the RP
functions. This capability is controlled by the auto-RP mapping agent.
Version 2.0a
1071
Routing Protocols
Module 10
A fundamental difference exists in the basic configuration of multicast on
Cisco IOS and Cisco IOS XR. In Cisco IOS, you configure multicast routing
and then configure PIM on an interface, which automatically enables PIM
and IGMP operation. In Cisco IOS XR, you configure multicast routing
and enable an interface, which automatically activates PIM and IGMP
operation. You only have to configure only a PIM interface if you want to
modify its default parameter values.
1072
Version 2.0a
Module 10
Multicast Routing
Cisco IOS XR
Cisco IOS
Enable Multicast:
Enable Multicast:
interface POS4/0
ip multicast-routing
multicast-routing
enable
PIM Configuration:
PIM Configuration:
interface POS4/0
ip pim sparse-mode
!
ip pim rp-address 1.1.1.1
ip pim send-rp-announce loopback0
scope 16
ip pim send-rp-discovery loopback0
scope 16
router pim address-family ipv4

rp-address 1.1.1.1
auto-rp candidate-rp loopback 0
scope 16
auto-rp mapping-agent loopback 0
scope 16
Cisco IOS XR
Cisco IOS
IGMP Configuration:
IGMP Configuration:
interface POS4/0
ip igmp version 3
router igmp
version 3
MSDP Configuration:
MSDP Configuration:
ip msdp peer 10.39.9.6

ip msdp sa-filter in 10.39.9.6 list 111
ip msdp sa-filter out 10.39.9.6 list 111
router msdp
peer 10.39.9.6
sa-filter in list 111
sa-filter out list 111
Version 2.0a
1073
Routing Protocols
Module 10
Summary
Routing Protocols
In this module, you learned:
1074
How to configure BGP
How to configure OSPF
How to configure IS-IS
How to configure Multicast Routing
Functional and configuration differences between Cisco IOS and Cisco

IOS XR routing protocols
Version 2.0a
Module 10
Review Questions
Routing Protocols
Version 2.0a
1075
Routing Protocols
Module 10

1076
Version 2.0a
Module 11
Routing Policy Language
Overview
Description
This module teaches the Routing Policy Language (RPL). It describes RPL
architecture, defines syntax, and demonstrates a methodology to convert
route maps to RPL.
Objectives
Write policies in RPL
Use hierarchical and parameterized policies
Convert route maps to RPL policies
Version 2.0
111
Module 11
RPL Overview
Motivation
Classic Cisco IOS route maps have inherent scaling issues because of their
non-modular structure. Reuse of common policy is not possible because
there is no way to refer from one route map to another. Systems on the
scale of CRS-1 could possible need support for 1000s of route maps with
their implied redundancy.
112
Version 2.0
Module 11
RPL Overview
Motivation
Using route-maps on a CRS-1 scale

could lead to configurations on the order
of several 100k to over a million lines
depending on the number of BGP peers.
Instructor Notes
Rewrote one major ISPs 15K lines of route maps in 1K lines of RPL policy.
Version 2.0
113
Module 11
Route Policy Language (RPL)

The Routing Policy Language (RPL) has been designed to provide a single,
straightforward language in which all routing policy needs can be
expressed. RPL was developed to support large scale routing
configurations. It greatly reduces the redundancy that is inherent in
previous Cisco IOS routing policy configuration methods - route maps and
lists. RPL simplifies large-scale network configuration by reducing the
number of configuration statements required to maintain routing policies
in the network. RPL configurations are modular, more concise, and more
scalable. These improvements streamline routing policy configuration,
reduce systems resources required to store and process these
configurations, and simplify troubleshooting.
114
Version 2.0
Module 11
RPL Overview
Route Policy Language (RPL)
The Routing Policy Language (RPL)

was developed to support large scale
routing configurations.
RPL was designed to reduce some of
the redundancy that is inherent in route
map configuration
Version 2.0
115
Module 11
Fundamental Capabilities
The RPL has several fundamental capabilities that differ from those
present in traditional IOS route-map and acl/prefix-list oriented
configuration.
The first of these capabilities is the ability to build policies in a modular
form. Common blocks of policy can be defined and maintained
independently. These common blocks of policy can then be applied from
other blocks of policy to build complete (hierarchical) policies. This
capability can reduce the amount of configuration information that needs
to be maintained.
In addition, these common blocks of policy can be parameterized. This
allows for policies that share the same structure but differ in the specific
values that are set or matched against to be maintained as independent
blocks of policy.
116
Version 2.0
Module 11
RPL Overview
Fundamental Capabilities
Modularization
Common blocks of policy

Defined and maintained independently
Apply from other blocks to build complete
policies
Parameterization
Same policy structure but different set or

matched values
Value passed as parameter by applying block
Question?
Do we need a more direct comparison between RPL and IOS route map/list mechanisms? More
specifics, like persistent comments?
Version 2.0
117
Module 11
Hierarchy and Parameterization

There is no support for looping or branching constructs within an RPL
policy nor is recursion within a hierarchical policy structure allowed. That
is, a policy block may not apply itself directly or indirectly through another
policy block which it applies.
Hierarchical policy structures may have as many layers as desired with an
arbitrary number of parameters passed block to block. Parameters may
also be passed through a policy block to another block applied from within.
118
Version 2.0
Module 11
RPL Overview
Hierarchy and Parameterization
Looping/recursion is not allowed

As many layers of hierarchy or parameters that
you want
Parameters can be passed through a policy
block
Version 2.0
119
Module 11
Infrastructure
Supporting RPL are four main components involved in configuring and
running policies:
Configuration front-end (CLI)Is the mechanism to enter and modify
policies. RPL configurations are committed to the router in the same way
other configurations are committed and may be displayed using the normal
configuration show commands.
Policy RepositoryCompiles created or modified policies into a form the
execution engine can understand. During this process it vverifies the
policies to be sure they can be executed properly. The Policy Repository
also tracks policy use and notifies the appropriate policy clients when inuse policies are modified.
Policy execution engineIs responsible for running policies as requested
by the policy client. It can be thought of as receiving a route from a policy
client and executing the policy against the specific route data.
Policy clients (the routing protocols)Call the policy execution engine at
the appropriate times to have a given policy applied to a specific route and
then carries out some number of actions. These actions may include
deleting the route from further consideration, passing it along as a
candidate for the best route, or advertising a modified route as
appropriate.
1110
Version 2.0
Module 11
RPL Overview
Infrastructure
Configuration front end
CLI, editor, syntax check

Policy repository
Compiles policies for execution engine

Verifies policies
Tracks and manages client/policy use
Policy execution engine
Processes routes from clients

Policy clients
Routing protocols
Policy configuration
Policy Repository
Execution Engine
Clients
(protocols)
Version 2.0
1111
Module 11
RPL Description
Basic Building Blocks and Functions
The policy language provides two kinds of persistent, namable objects: sets
and policies. Legal names for these objects can be any sequence of the
upper and lowercase alphabetic characters; the numerals 09; the
punctuation characters period, hyphen, and underbar. A name must begin
with a letter or numeral.
There are four kinds of sets: as-path-set, community-set, extcommunityset and prefix-set.
Definition of sets and policies is bracketed by beginning and ending

command lines in standard CLI syntax.
For example:
route-policy test1
[ . . . Policy statements . . . ]
end-policy
or:
prefix-set test2
[ . . . Prefix set statements . . . ]
end-set
1112
Version 2.0
Module 11
RPL Description
Basic Building Blocks and Functions
Route Policy
Language
AS Path Sets
Route Policies
Policy Sets
Community
Sets
Extended
Community
Sets
Version 2.0
Prefix Sets
1113
Module 11
Hierarchical Policy
Policy statements are processed sequentially in the order in which they
appear in the configuration. Policies that hierarchically reference other
policy blocks are processed as if the referenced policy blocks had been
directly substituted inline. Policies may refer to other policies such that
common blocks of policy may be reused. This is accomplished by using the
apply statement.
In the simple example on the facing page, the apply statement in policy
two causes policy one to be executed setting the Multi Exit Discriminator
(MED) attribute to 100 in any BGP route processed by policy two.
Continuing execution of policy one sets the community to 10:100. This is an
example of a hierarchical policy.
_____________________________ Note _________________________
You may have as many levels of hierarchy as desire; there is no arbitrary
limit. However, many levels of hierarchy may be difficult to maintain and
understand. Since policy execution is dynamic, changes to one policy affect
all those policies that reference it directly or indirectly.
_________________________________________________________________
1114
Version 2.0
Module 11
RPL Description
Hierarchical Policy
A policy which is referenced by another policy with an

apply statement:
route-policy one
set med 100
end-policy
route-policy two
apply one
set community (10:100)
end-policy
Version 2.0
1115
Module 11
Parameterized Policy
In addition to supporting reuse of policy blocks via the apply statement,
policies can also be defined which allow for parameterization of some of the
attributes. The trivial example on the facing page contains a
parameterized policy one which takes one parameter $med. Parameters
always begin with a dollar sign and consist otherwise of alphanumeric
characters.
Parameters can be substituted into any attribute that takes a parameter.
In this case we are passing a 16-bit MED value as a parameter. The
parameterized policy can then be used with different parameterizations as
shown. In this manner, policies that share a common structure but use
different values in some of their individual statements can be modularized.
1116
Version 2.0
Module 11
RPL Description
Parameterized Policy
A hierarchical policy that receives passed values:

route-policy one ($med)
set med $med
end-policy
route-policy two
apply one (10)
end-policy
route-policy three
apply one (20)
end-policy
Instructor's Note
For software engineers coding in a procedural language, this is like passing a parameter by value.
The equivalent of passing a parameter by reference is not allowed in the RPL.
Version 2.0
1117
Module 11
Attach Point
Policies do not become useful until they are applied to routes. For that to
happen they need to become known to routing protocols. As an example, in
BGP there are several places where policies can be used, the most common
of these is defining import and export policy:
neighbor <name or address>
policy <name> in|out
These statements are referred to as policy attach points. In other words,

this is the point where an association is formed between a specific protocol
entity, in this case a BGP neighbor, and a specific named policy.
There is a verification step that happens each time a policy is attached and
whenever a policy that is already attached is modified. The verification
ensures the policy is compatible with intended or current use. For example,
a policy that sets the IS-IS level attribute is not allowed to be used as a
BGP import policy since BGP routes dont carry IS-IS attributes.
_____________________________ Note _________________________
Route maps may currently be used instead of RPL-based policies at any
attach point but you cannot use both RPL-based policy and old policy
(including route maps and access control lists) at the same attach point.
_________________________________________________________________
1118
Version 2.0
Module 11
RPL Description
Attach Point
Any location (usually in a protocol entity) that binds

the use of a named policy for a specific purpose:
neighbor 1.2.3.3
policy foo in
policy bar out
Version 2.0
1119
Module 11
BGP Attach Points

Aggregation
The aggregation attach point generates an aggregate route to be advertised

based on the conditional presence of subcomponents of that aggregate.
Aggregation policies can also set any valid BGP attribute on the
aggregated routes. For example, the policy could set a community value or
a MED on the aggregate that is generated. The specified aggregate will be
generated if any routes evaluated by the named policy pass the policy.
Dampening
The dampening attach point controls the default route-dampening

behavior within BGP. Unless overridden by a more specific policy on the
associate peer, all routes in BGP will apply the associated policy to set
their dampening attributes.
Default originate
The default originate attach point allows the default route (0.0.0.0/0) to be
conditionally generated and advertised to a peer, based on the presence of
other routes in the Routing Information Base (RIB). If any routes pass the
policy, the default route is generated and sent to the relevant peer.
Neighbor export/import
The neighbor export attach point is used to select the BGP routes to send
to a given peer or group of peers. The routes are selected by running the
set of possible BGP routes through the associated policy. Any routes that
pass the policy are then sent as updates to the peer or group of peers. The
routes that are sent may have had their BGP attributes altered by the
policy that has been applied.
The neighbor import attach point controls the reception of routes from a
specific peer. All routes that are received by a peer are run through the
attached policy. Any routes that pass the attached policy are considered as
candidates for selection as best path routes.
Network
The network attach point controls the injection of routes from the RIB into
BGP. A route policy attached at this point is able to set any of the valid
BGP attributes on the routes that are being injected.
1120
Version 2.0
Module 11
RPL Description
BGP Attach Points
Aggregation
aggregate-address address/length policy policy-name

Dampening
bgp dampening policy policy-name

Default originate
default-originate policy policy-name

policy policy-name {in | out}

Network
network address/length policy policy-name

Redistribute
redistribute {ospf | isis | bgp} policy policy-name

Show
show bgp route-policy policy-name

Show bgp policy route-policy policy-name
Table
table-policy policy-name
Instructor's Note
Value Added: IGP policy attach points as of IOS XR Release 3.0
OSPF default originate and redistribute
IS-IS redistribute
Version 2.0
1121
Module 11
Redistribute
The redistribute attach point allows routes from other sources to be

advertised by BGP. The redistribute policy can set any of the valid BGP
attributes on the routes that are being redistributed. Also, redistribute
operators can select what route sources are being redistributed and which
routes from those sources.
Show
The show bgp attach point allows the user to display selected BGP routes
that pass the given policy. Any routes that are not dropped by the attached
policy will be displayed in a manner similar to the output of the show bgp
command. There is also a show bgp policy route-policy command which
previews the effects of a BGP neighbor export (outbound) policy by running
all routes in the RIB past the named policy. This command then displays
what each route looked like before and after it was modified.
Table
The table policy attach point allows the user to configure traffic-index
values on routes as they are installed into the global routing table. This
attach point supports the BGP policy accounting feature which uses the
traffic indexes that are set on the BGP routes to track various counters.
This way, you can select different sets of BGP route attributes using the
policy matching operations and then set different traffic indexes for each
class of route you are interested in tracking.
1122
Version 2.0
Module 11
RPL Description
BGP Attach Points (continued)
Aggregation
aggregate-address address/length policy policy-name

Dampening
bgp dampening policy policy-name

Default originate
default-originate policy policy-name

policy policy-name {in | out}

Network
network address/length policy policy-name

Redistribute
redistribute {ospf | isis | bgp} policy policy-name

Show
show bgp route-policy policy-name

Show bgp policy route-policy policy-name
Table
table-policy policy-name
Instructor's Note
Value Added: IGP policy attach points as of IOS XR Release 3.0
OSPF default originate and redistribute
IS-IS redistribute
Version 2.0
1123
Module 11
Sets
In this context, the term set is used in its mathematical sense to mean an
unordered collection of unique elements. The policy language provides sets
as a container for groups of values for matching purposes within
conditional expressions. There are four kinds of sets: as-path-set,
community-set, extcommunity-set and prefix-set.
Named sets are defined at global configuration level and referenced from
conditionals within policy definitions. The set elements are bracketed
between a set type statement and an end-set statement with set elements
separated by comments:
as-path-set aset1
ios-regex _42$,
ios-regex _127$
end-set
The inline set form is a parenthesized list of comma-separated elements

contained in a conditional:
(ios-regx _42$, ios-regx _127$)
This inline set above matches exactly the same AS paths as the named set
aset1, but does not require the extra effort of creating a named set separate
from the policy that uses it. Inline sets are used when the number of
elements is small and the set does not need to be referenced from other
policies.
1124
Version 2.0
Module 11
RPL Description
Sets
The term set used in its mathematical sense means an

unordered collection of unique elements. The policy language
provides sets as a container for groups of values for matching
purposes.
They are used in conditional expressions. The elements of the
set are separated by commas.
There are four kinds of sets: as-path-set, community-set,
extcommunity-set and prefix-set.
There are two forms for set definition: named form and inline
form.
Named set form example:

as-path-set aset1
ios-regx _42$,
ios-regx _127$
end-set
Inline set form example:

(ios-regx _42$, ios-regx _127$)
Version 2.0
1125
Module 11
Prefix Set
A prefix-set holds IPv4/IPv6 prefix match specifications, each of which has
four parts: an address, a mask length, a minimum matching length, and a
maximum matching length. The address is required, but the other three
parts are optional.
The address is a standard dotted-decimal IPv4 address or hexadecimal
IPv6 address. The mask length, if present, follows the address and is
separated from it by a slash. It is a positive decimal integer in the range
from 0 to 32 for IPv4 and from 0 to 128 for IPv6. If a prefix match
specification has no mask length, then the default mask length is 32 (IPv4)
or 128 (IPv6).
The optional minimum matching length follows the address and optional
mask length and is expressed as the keyword ge (mnemonic for greater
than or equal to), followed by a positive decimal integer in the range from 0
to 32 (IPv4) or 0 to 128 (IPv6). Finally, the optional maximum matching
length follows the rest and is expressed by the keyword le (mnemonic for
less than or equal to), followed by yet another positive decimal integer in
the range from 0 to 32 (IPv4) or 0 to 128 (IPv6). A syntactic shortcut for
specifying an exact length for prefixes to match is the eq keyword,
mnemonic for equal to.
The default minimum matching length is the mask length. If a minimum
matching length is specified, then the default maximum matching length is
32 (IPv4) or 128 (IPv6). Otherwise, if neither minimum nor maximum is
specified, the default maximum is the mask length.
_____________________________ Note _________________________
IPv6 addresses and prefixes are supported only for the BGP protocol.
Prefix sets may contain prefix specifications for both IPv4 and IPv6
using dotted-decimal and colon-separated hexadecimal formats,
respectively. However, IPv6 matching on destination, source, and next
hop and setting of IPv6 next hops is only supported at BGP attach
points
_________________________________________________________________
1126
Version 2.0
Module 11
RPL Description
Prefix Set
A prefix-set holds IPv4 and IPv6 prefix match

specifications, each of which has four parts:
address (only required part)
a standard format IPv4 or IPv6 address
mask length
a positive decimal integer in the range from 0 to 32

(IPv4) or 0 to 128 (IPv6)
follows the address and separated from it by a slash
minimum matching length
expressed by the keyword ge (greater than or equal to)
maximum matching length
expressed by the keyword le (less than or equal to)
Version 2.0
1127
Module 11
The prefix-set is a comma-separated list of prefix match specifications:

prefix-set legal-prefix-examples
10.0.1.1,
10.0.2.0/24,
10.0.3.0/24 ge 28,
10.0.4.0/24 le 28,
10.0.5.0/24 ge 26 le 30,
10.0.6.0/24 eq 28
end-set
The first element of the prefix-set will match only one possible value,
10.0.1.1/32 or the host address 10.0.1.1. The second element will match
only one possible value, 10.0.2.0/24. The third element will match a range
of prefix values, from 10.0.3.0/28 to 10.0.3.255/32. The fourth element will
match a range of values, from 10.0.4.0/24 to 10.0.4.240/28. The fifth
element matches prefixes in the range from 10.0.5.0/26 to 10.0.5.252/30.
The sixth element will match any prefix of length 28 in the range from
10.0.6.0/28 through 10.0.6.240/28.
The following prefix-set consists entirely of illegal prefix match
specifications:
prefix-set ILLEGAL-PREFIX-EXAMPLES
10.1.1.1 ge 16,
10.1.2.1 le 16,
10.1.3.0/24 le 23,
10.1.4.0/24 ge 33,
10.1.5.0/25 ge 29 le 28
end-set
Neither minimum-length nor maximum-length is legal without a mask

length. The maximum length must be at least the mask length. For IPv4,
the minimum length must be less than 32, the maximum length of an IPv4
prefix. For IPv6, the minimum length must be 128, the maximum length of
an IPv6 prefix. The maximum length must be equal to or greater than the
minimum length.
1128
Version 2.0
Module 11
RPL Description
Prefix Set (continued)
Legal prefix specifications:

prefix-set legal
10.0.1.1,
10.0.2.0/24,
10.0.3.0/24 ge 28,
10.0.4.0/24 le 28,
10.0.5.0/24 ge 26 le 30
10.0.6.0/24 eq 28
end-set
Illegal prefix specifications:

prefix-set illegal
10.1.1.1 ge 16,
10.1.2.1 le 16,
10.1.3.0/24 le 23,
10.1.4.0/24 ge 33,
10.1.5.0/25 ge 29 le 28
end-set
Version 2.0
1129
Module 11
AS Path Set
This inline form set matches exactly the same AS paths as the named set
shown on the facing page, but does not require the extra effort of creating a
named set separate from the policy that uses it:
(ios-regex '_42$', ios-regex '_127$')
1130
Version 2.0
Module 11
RPL Description
AS Path Set
An as-path-set comprises operations for matching an

AS path attribute. The elements are regular
expressions compatible with the as-regexp keyword in
the Cisco IOS ip as-path access-list command.
as-path-set aset1
ios-regex _42$,
ios-regex _127$
end-set
Version 2.0
1131
Module 11
Community Set
A community-set holds community values for matching against the BGP
community attribute. A community is a 2 * 16-bit quantity. For notational
convenience, each community value is expressed as two unsigned decimal
integers in the range 0 to 65535, separated by a colon.
The following inline set is equivalent to the named set cset1 on the facing
page:
(12:34, 12:56, 12:78)
The inline form of a community-set also supports parameterization. Each

16-bit portion of the community may be parameterized:
($as:34, 12:$tag1, $as:$tag1)
The language also provides symbolic names for the standard well-known
community values: internet is 0:0, no-export is 65535:65281, noadvertise is 65535:65282, and local-as is 65535:65283.
community-set cset2
123:456,
no-advertise
end-set
The language also provides a facility for using wildcards in community

specifications. A wildcard is specified by inserting an asterisk (*) in place
of one of the 16-bit portions of the community specification; this indicates
that any value for that portion of the community will match. Thus, the
following policy matches all communities where the AS part of the
community is 123:
community-set cset3
123:*
end-set
1132
Version 2.0
Module 11
RPL Description
Community Set
A community-set holds community values for matching

against the BGP community attribute. A community is
a 2*16-bit quantity. For notational convenience, each
community value is expressed as two unsigned
decimal integers in the range 0 to 65535, separated by
a colon.
community-set cset1
12:34,
12:78,
internet
end-set
Version 2.0
1133
Module 11
Extended Community Set

An extcommunity-set is analogous to a community set only it contains
extended community values. These values are 64 bits in length providing
an extended range compared to regular community values. There is also a
type field in each value providing a richer structure for encoding
information.
There are two formats supported to define extended community values:
asn:valDefines an Autonomous System (AS) number-based extended

community value where:
asn is a globally-administered 16 bit AS number
val is a locally-administered 32 bit decimal value
ip-addr:valDefines an IP address-based extended community value

where:
ip-addr is a 32 bit IPv4 address entered in dotted decimal notation
val is a locally-administered 16 bit decimal value
There are two Border Gateway Protocol (BGP) extended communities types
currently supported. The Route Target (RT) community identifies one or
more routers that may receive a set of BGP routes carrying this
community. The Site of Origin (SoO) community (also known as Route
Origin community) identifies one or more routers that inject a set of routes
carrying this community into BGP. These named communities are entered
as one of the following:
RT:a.b.c.d:nRoute Target (RT) in IPv4 format

RT:asn:nRT in AS format
SoO:a.b.c.d:nSite of Origin (SoO) in IPv4 format
SoO:asn:nSoO in AS format
Extended community sets also support both named and inline forms. The
following inline set is equivalent to the named set extcomm-set1 on the
facing page:
(RT:1.2.3.4:666, RT:1234:6667, SoO:1.2.3.4:777, SoO:45678:777)
_____________________________ Note _________________________

Parameterization of the extended community type RT (route-target)
and SoO (site of origin) is not currently supported nor is wildcarding (*)
currently supported.
_________________________________________________________________
1134
Version 2.0
Module 11
RPL Description
Extended Community Set
An extcommunity-set is analogous to a community set

only it contains extended community values that are 64
bits long including a type. It supports the named types:
RT - Route Target
SoO: Site of Origin
extcommunity-set extcomm-set1
RT:1.2.3.4:666,
RT:1234:666,
SoO:1.2.3.4:777,
SoO:4567:777
end-set
Version 2.0
1135
Module 11
Conditional Statements
The if-then-else statements provide a set of conditions and actions
- conditions come after the if or elseif
- actions come after the then
In its simplest form, an if statement uses a conditional expression to
decide which action(s) or disposition(s) should be taken for the given route.
For example:
if as-path in as-path-set-1 then
drop
endif
The above example indicates that any routes whose as-path is in the set aspath-set-1 shall be dropped. The contents of the then clause may be an
arbitrary sequence of policy statements:
if (origin is igp) then
set med 42
prepend as-path 73 5
endif
A single policy statement can span multiple lines or be confined to a single

line as clarity requires. The if statement also permits an else clause,
which is executed if the expression is false:
if med eq 200 then
set community (12:34) additive
else
endif
elseif
The RPL also provides a conditional syntax using the elseif keyword to
string together a sequence of tests:
if med eq 150 then
set local-preference 10
elseif med eq 200 then
else
endif
1136
Version 2.0
Module 11
RPL Description
Conditional Statements
An if statement uses a conditional expression to decide which

actions or dispositions should be taken for the given route.
if as-path in as-path-set-1 then
drop
endif
The if statement also permits an else or elseif clause, which is
executed if the expression is false.
if med eq 150 then
elseif med eq 200 then
else
endif
Version 2.0
1137
Module 11
Nested Conditionals
The statements within an if statement may themselves be if statements,
as shown in the following example:
if community matches-any (12:34, 56:78) then
if med eq 8 then
drop
endif
endif
The above policy example will set the value of the local-preference
attribute to 100 on any route which has a community value of 12:34 or
56:78 associated with it. However, if any of these routes with both the
community value of 12:34 or 56:78 has a MED value of 8, then these routes
are dropped.
_____________________________ Note _________________________
Nesting allows you to set up a precondition which cannot easily be done
in a route map. In a route-map, the precondition would have to be
replicated in each route-map clause.
_________________________________________________________________
1138
Version 2.0
Module 11
RPL Description
Nested Conditionals
The statements within an if statement may themselves be if

statements, as shown in the following:
if community matches-every(12:34, 56:78) then
if med eq 8 then
drop
endif
endif
Version 2.0
1139
Module 11
Boolean Conditions
In the previous section describing conditional if statements, all of the
examples used simple Boolean conditions which evaluated to either true or
false. The RPL also provides means to build compound conditions from
simple conditions by means of three Boolean operators: negation (not),
conjunction (and), and disjunction (or). In RPL, negation has the highest
precedence, followed by conjunction, and then by disjunction. Parentheses
may be used to group compound conditions to override precedence or to
improve readability.
The following simple condition:
med eq 42
will be true if and only if the value of the MED in the route is 42, otherwise
it will be false.
A simple condition may also be negated using the not operator:
not next-hop in(10.0.2.2)
Any Boolean condition enclosed in parenthesis is itself a Boolean condition:

(destination in prefix-list-1)
1140
Version 2.0
Module 11
RPL Description
Boolean Conditions
Boolean conditions evaluate as either true or false.

The routing policy language provides means to build compound
conditions from simple conditions by means of Boolean
operators.
There are three Boolean operators : negation (not), conjunction
(and), and disjunction (or).
if med eq 42 and next-hop in (1.1.1.1) then
Version 2.0
1141
Module 11
Compound Conditions
A compound condition is a Boolean condition followed by the and or or
operator, itself followed by a Boolean condition:
med eq 42 and next-hop in (10.0.2.2)
origin is igp or origin is incomplete
An entire compound condition may be enclosed in parentheses:

(med eq 42 and next-hop in (10.0.2.2))
The parentheses may serve to make the grouping of sub-conditions more

readable, or they may force the evaluation of a sub-condition as a unit. In
the example below, the highest-precedence not operator applies only to the
destination test. The and combines the result of the not expression with
the MED test and the or combines that result with the community test.
med eq 10 and not destination in (10.1.3.0/24) or community
matches-any (56:78)
With a set of parentheses to express the precedence, the result is the

following:
(med eq 10 and (not destination in (10.1.3.0/24)) or community
matches-any (56:78)
Parentheses are more likely to be used to force the evaluation differently

than the normal precedence would do:
med eq 10 and (not destination in (10.1.3.0/24) or community
matches-any (56:78))
The following is another example of a complex expression:

(origin is igp or origin is incomplete or not med eq 42) and
next-hop in (10.0.2.2)
The left-hand conjunct is a compound condition enclosed in parentheses.

The compound condition is evaluated to test whether the BGP route origin
is IGP or incomplete, or the MED is not 42. If any of these conditions are
true and the routes next hop is 10.0.2.2 then the entire compound
condition is true. Otherwise the compound condition is false.
1142
Version 2.0
Module 11
RPL Description
Compound Conditions
Boolean operator precedence from highest to lowest is: negation

(not), conjunction (and), and disjunction (or). Parentheses may
be used to force the evaluation differently than the normal
operator precedence.
For example
med eq 10 and not destination in (10.1.3.0/24) or community is (56:78)
is evaluated differently than

med eq 10 and (not destination in (10.1.3.0/24) or community is (56:78))
Version 2.0
1143
Module 11
Default Drop
All route policies have a default action to drop a route under evaluation
unless it is accepted. In IOS route-maps this is determined by a successful
match. In RPL this is determined when the route is modified (set) or
explicitly passed (pass).
Applied (hierarchical) policies implement this as though the applied policy
were pasted into the point where it is applied. As an example, consider a
policy to allow all routes in the 10 net and set their local-preference to 200
while dropping all other routes:
route-policy two
if destination in (10.0.0.0/8 ge 8 le 32) then
endif
end-policy
route-policy one
apply two
end-policy
At first it may seem that policy one will drop all routes because it neither
contains an explicit pass statement nor modifies a route attribute.
However, because the applied policy two does set an attribute, the net
result is that policy one will pass routes with destinations in net 10 and
drop all others. It is the same as if policy one were written:
route-policy one
endif
end-policy
1144
Version 2.0
Module 11
RPL Description
Default Drop
RPL has a default drop condition once a policy

is applied
If the route is not accepted it is dropped
similar behavior to Cisco IOS route maps
Acceptance determined by
modifying any route attribute, or

hitting the pass statement.
Version 2.0
1145
Module 11
Attribute Value Determination

Policy execution does not modify route attributes until all tests have
completed. In other words, comparisons are always performed on original
route data not intermediate results. Intermediate modifications of route
attributes do not have a cascading effect on the evaluation of the policy.
For example:
set med 42
if med eq 42 then
drop
endif
will only drop routes which originally had the MED set to 42; all other
routes will have their MED set to 42. A route which had an initial MED of
15 will have its MED set to 42 but will not be dropped because the
conditional compares the MED value of 15 in the original route not the
modified value.
1146
Version 2.0
Module 11
RPL Description
Attribute Value Determination
All matches are performed on original route

data not intermediate results.
Actual route attributes not modified until policy

execution complete
No cascading effect from intermediate set

statements
Version 2.0
1147
Module 11
BGP Route Attributes and Operations

A primary goal of routing policy is to provide a mechanism for matching
and setting route attributes in a clear, concise and efficient manner. Each
of the BGP attributes has a series of operations that can be used to either
match or modify it. There are also a few attributes that are not standard
BGP attributes but are associated with BGP routes on the Cisco CRS
router which can be manipulated.
1148
Version 2.0
Module 11
BGP Route Attributes
Attribute
BGP
as-path
community
dampening
destination
extended community
local preference
med
next-hop
origin
route-type
Cisco
source
suppress
tag
traffic-index
weight
Instructors Note
This module only covers RPL support for BGP route attributes. RPL also supports attributes
and operations for OSPF and IS-IS but they are not covered in this course.
Version 2.0
1149
Module 11
AS Path
In its simplest form, the AS path is a sequence of autonomous system
numbers traversed by a BGP route. In its more complex form, it is a
sequence of chunks each of which is either a sequence (ordered list) of AS
numbers or a (unordered list) set of AS numbers. RPL provides several
operations on the AS path: matching the AS path of a route against an aspath-set using various operators, prepending an AS number to an AS path
one or more times, and conditional checks based on the length of the AS
path.
An as-path-set comprises operations for matching an AS path attribute.
The only matching operation is a regular expression match, compatible
with the as-regexp provided by Cisco IOS in ip as-path access-list.
The is-local operator takes no arguments and evaluates to true for AS
paths that are empty. This test would be typically used to determine if this
router (or another router within this autonomous system or confederation)
originated the route. Routes that are locally originated within the
autonomous system, or confederation, carry an empty AS path. Per the
BGP specification, when a route is advertised across the autonomous
system boundary or a confederation boundary, the local AS number or
confederation id is appended to the AS path. The AS path of a locally
originated aggregate is also empty unless it has been modified by policy.
The neighbor-is operator tests the autonomous system number or
numbers at the head of the AS path against a sequence of one or more
integral values or parameters. In other words, it tests to see if the
sequence of AS numbers matches the path beginning with the neighboring
AS from which this route was heard.
The passes-through operator takes a single-quoted sequence of integers
or parameters as an argument. It can also take a single integer or
parameter as an argument. It evaluates to true if the supplied integer or
parameter appears anywhere in the AS path or if the supplied sequence of
integers and parameters appears in the same order anywhere in the AS
path. This includes the originates-from or neighbor-is locations in the
AS path.
1150
Version 2.0
Module 11
As Path
as-path -- Match
if
if
if
if
if
if
if
as-path
as-path
as-path
as-path
as-path
as-path
as-path
in as-path-set-1 then
is-local then
length eq 10 then
neighbor-is 10 then
originates-from 100 then
passes-through 10 11 then
unique-length eq 5 then
as-path -- Assignment
prepend as-path 2 3
prepend as-path 666 2
Instructor's Note
The required arguments for prepend as-path are the AS number to prepend to the AS path and
the number of times it should be prepended. The Release 2.0 online help is not clear about this.
It should be cleaned up in a subsequent release.
Version 2.0
1151
Module 11
Community
Communities are 2*16-bit values carried in BGP routes. Each route may
have zero or more communities in an unordered list. To test for the
presence of community values in the list (is-empty), test for any
community values in the list matching some (matches-any) or all
(matches-every) elements of a community-set, delete community values
from the list (delete), add community values to the list (set additive), or
replace the list with a defined set of community values (set) use the
community attribute with the appropriate operator(s).
1152
Version 2.0
Module 11
Community
community -- Match
if community is-empty then
if community matchs-any c1 then
if community matchs-every c2 then
community -- Assignment
set community (10:12)
set community ($as:12) additive
delete community in ($as:12, 10:$tag)
delete community not in keepcomm
delete community all
Instructor's Note
The difference between matches-any and matches-all is that matches-any is true if any
community in the route matches any community listed in the community-set. Whereas, matchesall is true only if each community in the community-set matches at least one community in the
route.
Version 2.0
1153
Module 11
Community Deletion
The command delete community all will remove all communities except
the well-known communities (internet, no-export, no-advertise, or local-as).
You can delete well-known communities but it must be done explicitly.
___________________________CAUTION _______________________
In general, there should be few circumstances where a wellknown community needs to be removed.
_________________________________________________________________
1154
Version 2.0
Module 11
Community Deletion
Community deletion in RPL is slightly different

than in Cisco IOS. Specifically, delete
community all will not delete the well-known
communities. They must be explicitly deleted.
Version 2.0
1155
Module 11
Dampening
To configure BGP route dampening, use the set dampening command.
The BGP protocol supports route dampening via an exponential back-off
algorithm. The algorithm can be controlled by setting the four BGP
dampening values using the set dampening command:
set dampening <1-4 dampening parameters> [others default]
The dampening parameters are halflife, reuse, suppress, and maxsuppress (defined below). They are all optional provided that at least one
parameter is supplied and may appear in the statement in any order. If the
statement defines values for three or fewer of the parameters, then the
statement must end with others default indicating that any parameter
(listed below) not specified in the statement will receive its default value.
halflife
Once the route has been assigned a penalty, the penalty is decreased by
half after the halflife period. The process of reducing the penalty happens
every 5 seconds. The range of the half-life period is 1 to 45 minutes. The
default is 15 minutes.
reuse
If the penalty for a flapping route decreases enough to fall below this value,
the route is unsuppressed. The process of un-suppressing routes occurs at
10-second increments. The range of the reuse value is 1 to 20,000; the
default is 750.
suppress
A route is suppressed when its penalty exceeds this limit. The range is 1 to
20,000; the default is 2000.
max-suppress
Maximum time (in minutes) a route can be suppressed. The range is 1 to

255 (minutes); the default is 4 times the halflife. If the halflife value is
allowed to default, the maximum suppress time defaults to 60 minutes.
1156
Version 2.0
Module 11
Dampening
route-policy foo-damp
if destination in (10.0.0.0/24 ge 28) then
set dampening max-suppress 30 halflife 10 others default
else
set dampening halflife 20 max-suppress 45 reuse 750
suppress 1000
endif
end-policy
Version 2.0
1157
Module 11
Destination
The destination of a route is also known in BGP as its network-layer
reachability information (NLRI). It comprises a prefix value and a mask
length. The policy language provides the ability to test them for a match
against a list of prefix-match specifications.
To match a destination entry in a named prefix-set or inline prefix-set, use
the destination in command in route-policy configuration mode:
destination in <prefix-set name> | <inline prefix-set>
The condition returns true if the destination entry matches any entry in
the prefix-set. An attempt to match a destination using a prefix-set that is
defined but contains no elements returns false.
1158
Version 2.0
Module 11
Destination
destination -- Match
endif
Version 2.0
1159
Module 11
Extended Community
Extended communities are 64-bit values carried in BGP routes. Each route
may have zero or more extended communities in an unordered list. To test
for the presence of community values in the list (is-empty), test for any
community values in the list matching some (matches-any) or all
(matches-every) elements of a community-set, use the extcommunity
attribute with the appropriate operator(s).
Matching of an extended community in the route against a specification in
a named or inline set is intuitive. Because there is no use of wildcards with
extended communities, a community in the route matches a specification in
the set if they encode the same 64-bit number.
1160
Version 2.0
Module 11
Extended Community
extcommunity -- Match
if extcommunity matchs-any ec1 then
If extcommunity matchs-every ec2 then
If extcommunity is-empty then
Version 2.0
1161
Module 11
Local Preference
The local preference attribute is a 32-bit value exchanged between routers
in the same AS as an indication about which path to a certain network is
preferred in exiting the AS. A path with a higher local preference is more
preferred. The default value for local preference is 100 which can be
modified using the bgp default local-preference command in router
BGP configuration mode.
You can define a particular path as more preferable or less preferable than
other paths by setting its local preference attribute value in route-policy
configuration mode:
set local-preference <preference-value>
1162
Version 2.0
Module 11
Local Preference
local-preference -- Assignment
Version 2.0
1163
Module 11
MED
The MED attribute is a 32-bit unsigned integer passed between BGP peers
in different ASes indicating a desire for incoming traffic to a particular
NLRI to be received on a particular route. The MED isn't communicated to
ASes beyond the neighboring AS. It is intended to be used in distributing
incoming traffic where there is more than one connection between a pair of
ASes; setting a higher MED for one route will make the traffic flow over
the other.
To compare the Multi-Exit Discriminator (MED) against an integer value
or a parameterized value, use the med command in route-policy
configuration mode:
med {eq | ge | le} <integer> | <parameter>
The eq operation allows the MED to be compared for equality against

either a static value or a parameterized value. A greater than or equal to
comparison can also be done with the ge operator, and a less than or equal
to comparison can be performed using the le operator.
1164
Version 2.0
Module 11
MED
med -- Match
if (med eq 10) then ...
med -- Assignment
set med 10
Instructor's Note
In RPL, the route attribute metric is NOT overloaded in each protocol. The keyword med is
introduced to refer to the BGP multi-Exit discriminator. The keyword cost is used to refer to the
OSPF cost. The keyword metric refers to the IS-IS metric.
Version 2.0
1165
Module 11
Next-Hop
The next-hop is a dotted-decimal IPv4 address or colon-separated
hexadecimal IPv6 address. To compare the next-hop associated with the
route to data contained in either an inline or named prefix set, use the
next-hop in command in route-policy configuration mode:
next-hop in <prefix-set name> | <inline prefix-set>
The result is true if any value in the prefix-set matches the next-hop of the
route. A comparison which refers to a named prefix-set which has zero
elements in it returns false.
1166
Version 2.0
Module 11
Next-Hop
next-hop -- Match
if next-hop in some-prefix-set then ...
if next-hop in (10.2.23.4, 10.3.14.5) then ...
Version 2.0
1167
Module 11
Origin
The origin of a BGP route is an enumeration; it is either igp, egp or
incomplete. To match a specific origin type, use the origin is command
in route-policy configuration mode:
origin is {igp | egp | incomplete}
To set the origin of a BGP route use the following command:

set origin {igp | egp | incomplete}
1168
Version 2.0
Module 11
Origin
origin -- Match
if origin is igp or origin is incomplete then
origin -- Assignment
set origin incomplete
Version 2.0
1169
Module 11
Source
The source of a BGP route is the IPv4 or IPv6 peering address of the
neighboring router from which you received a BGP route. To test the
source of the route against the elements of either a named or inline prefix
set, use the source in command in route-policy configuration mode:
source in <prefix-set name> | <inline prefix-set>
A comparison which references a prefix-set that has zero elements in it

returns false.
1170
Version 2.0
Module 11
Source
source -- Match
if source matches-any my_prefix_set then ...
Version 2.0
1171
Module 11
Tag
A tag is a 32-bit integer associated with a given route in the RIB. To match
a specific tag value, use the tag command in route-policy configuration
mode:
tag {eq | ge | le} {integer | parameter}
The eq operator matches either a specific tag value or a parameter value.

Its variants, ge and le, match a range of tag values that are either greater
then or equal to or less than or equal to the supplied value or parameter.
Since tag is a comparison operator, it appears in the conditional clauses of
if-then statements.
1172
Version 2.0
Module 11
Tag
tag -- Match
if tag eq 10 then
tag -- Assignment
set tag 20
Version 2.0
1173
Module 11
Traffic-Index
The traffic-index is a special attribute for Ciscos BGP implementation. It
is not a BGP attribute carried with BGP routes but is a value that can be
set to support the BGP accounting feature. It is used as an index into a set
of counters maintained by the forwarding hardware. Traffic indexes can be
used to count traffic being forwarded on these routes in line cards by
enabling the BGP policy accounting counters on the interfaces of interest.
The traffic-index takes a value in the range from 1 to 63 inclusive or the
special keyword ignore. If traffic-index is set to ignore, then BGP policy
accounting is not done.
It is only valid to set the traffic-index in policies that are attached to the
table-policy attach point.
1174
Version 2.0
Module 11
Traffic-Index
traffic-index -- Assignment
set traffic-index 10
set traffic-index $tindex
set traffic-index ignore
Version 2.0
1175
Module 11
Weight
The weight of a route is a Cisco-specific BGP attribute used as the
strongest tie-breaker in the BGP route selection process. Given two BGP
routes with the same NLRI, a route with a higher weight will always be
chosen no matter what the value of other BGP attributes may be. Weight
only has significance on the local router; it is never sent between BGP
peers.
Weight is a number from 0 to 65535. Any path that a Cisco router
originates will have a default weight of 32768; other paths have weight of
0.
Usage
If you have particular neighbors that you want to prefer for most of
your traffic, you can assign a higher weight to all routes learned from
that neighbor.
1176
Version 2.0
Module 11
Weight
weight -- Assignment
set weight 100
Version 2.0
1177
Module 11
Converting Route Maps to RPL Policies

In the following example we will show four different steps leading to a
translation of a route map to an RPL policy, each step progressively
reducing the amount of configuration needed to achieve the same task.
We will use the following methods to reduce the route map configuration.
1. Perform a simple translation of a route map to an RPL policy using
conditional and action statements.
2. Nest conditionals to reduce repetitive comparisons.
Common operations can be coalesced by nesting the conditionals, only
testing the destination address once, and only setting the community
once.
3. Use online sets to remove small named set references.
Since the community comparisons are quite simple, we can replace the
named community-set references with direct inline references, thus
eliminating the need to define four community-sets each of which only
contain one community value.
4. Parameterize to reuse common structures.
Ability to parameterize common structures and create a common
parameterized policy (sample-translation-common) that is reused.
1178
Version 2.0
Module 11
To convert a regular route-map into an RPL policy we will use

the following four steps:
Step 1. Do a simple (direct) syntax translation

Step 2. Nest conditionals to reduce repetitive comparisons
Step 3. Use inline sets to remove small named set references
Step 4. Parameterize to reuse common structures
Version 2.0
1179
Module 11
Route Map Configuration

Most primitives of the policy language translate directly from route map
match and set clauses. The interesting differences come in the way that
the primitives combine to more complex statements. The policy language is
designed to remove the redundancy of expression inherent in route maps.
This example walks you through using several of the features of the
language to modularize the configuration. What you should modularize
and whether you should modularize specific portions are best decided in
the context of how that particular piece of policy will be used.
Is it a special piece that will only be used in one place, or is it a common
structure that can be reused in several places? The answers to these
questions and more may affect how you wish to most effectively structure
policy for your organization.
1180
Version 2.0
Module 11
Route Map Configuration
ip prefix-list 101
10 permit 10.48.0.0/16 le 32
20 permit 172.48.0.0/19
30 permit 192.168.3.0/24
ip prefix-list 102
10 permit 172.16.10.0/24
20 permit 192.168.8.0/21
30 permit 192.168.32.0/21
ip community-list 1
10 permit 10:11
ip community-list 2
10 permit 10:12
ip community-list 3
10 permit 10:13
ip community-list 4
10 permit 10:14
Version 2.0
1181
Module 11
Route Map Configuration (continued)

_____________________________ Note _________________________
You cannot use both RPL and old policy (including route maps and
access control lists) at the same attach point.
_________________________________________________________________
1182
Version 2.0
Module 11
Route Map Configuration (continued)
route-map sample1 permit 10

match ip address prefix-list 101
match community 1
set metric 11
set community 12:34 additive

match community 1
set metric 11

match community 2
set metric 12

match community 2
set metric 12

match community 3
set metric 13

match community 3
set metric 13

match community 4
set metric 14

match community 4
set metric 14

set metric 100

set metric 100
Version 2.0
1183
Module 11
Direct Translation
First take the ip prefix-list command and translate it into the RPL
prefix-set command. Only the network content of the statements, not the
sequence numbers or permit/deny, is retained with commas separating
each network. RPL uses the end-set command to show where the set ends.
The ip community list command similarly changes to the RPL
community-set command. The communities are entered in a similar
fashion under the community-set command but again without any
sequence number or permit/deny.
1184
Version 2.0
Module 11
Direct Translation
prefix-set ps101
10.48.0.0/16 le 32,
172.48.0.0/19,
192.168.3.0/24
end-set
Convert the prefix and community lists to

their equivalent RPL set notation.
prefix-set ps102
172.16.10.0/24,
192.168.8.0/21,
192.168.32.0/21
end-set
community-set cs1
10:11
end-set
community-set cs2
10:12
end-set
community-set cs3
10:13
end-set
community-set cs4
10:14
end-set
Version 2.0
1185
Module 11
Direct Translation (continued)

Next take each route-map and convert it to an equivalent RPL routepolicy. Use a simple condition (if and else if in this example) for every
match-clause in the route map and an action (in this case set) for every set
command in the route map.
The simple direct translation of this route map configuration will still
retain any redundant operations.
1186
Version 2.0
Module 11
Convert the first route map to a RPL

route-policy. Use a simple condition
(if and else if in this example) for
every match clause in the route map and
an action statement (in this case set)
for every set command in the route map.
route-policy policy1
if destination in ps101 and community matches-any cs1 then
set med 11
elseif destination in ps101 and community matches-any cs2 then
set med 12
set med 13
set med 14
elseif destination in ps101
set med 100
endif
end-policy
Version 2.0
1187
Module 11

The same steps used to convert the first route-map are now used to convert
the second route map part of the initial policy.
1188
Version 2.0
Module 11
Convert the second route map as

well using the same type of if and
set statements. Note the repetitive
statements if destination and
set community.. in both policies.
if destination in ps102 and community matches-any cs1 then
set med 11
set med 12
set med 13
set med 14
elseif destination in ps102
set med 100
endif
end-policy
Version 2.0
1189
Module 11
Nest Conditionals
Common operations in the first policy can now be coalesced by nesting the
conditionals, testing the destination address only once, and setting the
community only once.
1190
Version 2.0
Module 11
Nest Conditionals
Replace the redundant if destination

in conditional and set community
statements in the first route policy by
just one instance each.
if destination in ps101 then
if community matches-any cs1 then
set med 11
elseif community matches-any cs2 then
set med 12
set med 13
set med 14
else
set med 100
endif
endif
end-policy
Leave the nested if community

conditionals to reduce size and
evaluation processing.
Version 2.0
1191
Module 11
Nest Conditionals (continued)

The same steps used to reduce the first policy are now used to reduce the
second policy.
1192
Version 2.0
Module 11
Nest Conditionals (continued)
if community matches-any cs1 then
set med 11
set med 12
set med 13
set med 14
else
set med 100
endif
endif
end-policy
Perform a similar action on the

second route policy reducing
repetitive conditional statements.
Version 2.0
1193
Module 11
Use Inline Sets

Because the community comparisons are quite simple, you can replace the
named community set references with direct inline references. This
eliminates the need to define four community sets, each of which contains
only one community value.
1194
Version 2.0
Module 11
Use Inline Sets
if community matches-any (10:11) then
set med 11
elseif community matches-any (10:12) then
set med 12
set med 13
set med 14
else
set med 100
endif
endif
end-policy
Replace small named community sets

with inline sets reducing named set
references during policy evaluation.
Version 2.0
1195
Module 11
Inline Sets (continued)

Performing the same replacements on the second policy leaves only two
prefix sets and two policies.
1196
Version 2.0
Module 11
Inline Sets (continued)
Perform same replacement of named

community sets in the second route
policy. Note that the two route policies
are nearly identical.
set med 11
set med 12
set med 13
set med 14
else
set med 100
endif
endif
end-policy
Version 2.0
1197
Module 11
Parameterize
Create a parameterized policy block containing the common policy
structure from both policies and passing the unique community value in as
a parameter.
1198
Version 2.0
Module 11
Parameterize
Create a parameterized policy block

that contains the common policy
structure to be used by the route
policies.
Parameter $tag replaces

unique community value.
route-policy common ($tag)

set community (12:$tag) additive
set med 11
set med 12
set med 13
set med 14
else
set med 100
endif
end-policy
Version 2.0
1199
Module 11
Parameterize (continued)
Finally, reduce the two policies by applying the parameterized policy in
place of their similar policy structure now contained in the parameterized
policy and passing it their unique community value.
11100
Version 2.0
Module 11
Parameterize (continued)
Apply the parameterized policy to

replace the similar policy blocks in
both of the route policies.
apply common (34)
pass
endif
end-policy
apply common (35)
pass
endif
end-policy
Question?
Do we need the whole new policy as a final slide in this section for comparison?
Version 2.0
11101
Module 11
RPL-Specific CLI Commands

Editing Policies and Sets
Configuration for routing policy is rooted in the Command Line Interface
(CLI). Policies and sets may be entered line by line using the traditional
CLI mechanisms but not practically modified.
___________________________CAUTION _______________________
If you enter route-policy foo in global configuration mode and foo already
exists, the original content is deleted without warning.
___________________________________________________________
The configuration problem that RPL presents is that it uses a statement
and expression syntax, which is at odds with the line-oriented CLI. For
most other configuration constructs, e.g., interfaces, protocols, or route
maps, the CLI forces a one-to-one mapping between statements in the
language and lines of text. The semantics of RPL demand a more flexible
syntax. The CLI encapsulates the policy and set configuration text by
bracketing it in beginning and ending command lines such as:
route-policy <name>
. . .
end-policy
Thus, instead of each line being an individual command, one can think of
each policy or set as a configuration object that can manipulated as a unit
using the edit command.
After entering the edit route-policy command, a copy of the route-policy
is copied to a temporary file and the MicroEmacs editor is launched. After
editing, save the changes by using the save-buffer command, ^X^S
(control-X control-S). To exit the editor, use the quit command, ^X^Q.
Upon quitting the editor, the policy object will be parsed and checked for
syntax errors. If there are no errors, a disposition query is displayed:
Successful parse of edited config.
Commit configuration? (yes or no):
If you answer no, you are asked whether editing should continue:
Continue editing? (yes or no):
If you answer yes, the editor continues on in the text buffer from where
you left off. If you answer no, the running configuration is not changed and
the editing session is ended.
If there is a syntax error in the policy object, you notified of the error and
also prompted to continue editing or not.
11102
Version 2.0
Module 11
Editing Policies and Sets
The Command Line Interface (CLI) provides the means to enter

and delete route policy statements. It also provides a unique
means to edit the contents of the policy between the begin-end
brackets using a microemacs editor.
The name of the object being edited must be included following
the object type in the edit command.
RP/0/0/CPU0:pod1#edit ?
as-path-set
community-set
extended-community-set
prefix-set
route-policy
edit
edit
edit
edit
edit
an as-path-set
a community-set
an extended-community-set
a prefix-set
a route-policy
RP/0/0/CPU0:pod1#edit route-policy labtesting
Version 2.0
11103
Module 11
show rpl policy Command

To display the configuration of a specific named route policy, use the show
rpl policy <name> command in EXEC mode. To use the show rpl policy
command, you must be a member of a user group associated with the
route-policy global task ID.
If the uses all keywords are added to the show rpl policy command, all
policies and sets that policy uses are also displayed.
11104
Version 2.0
Module 11
show rpl policy Command
RP/0/0/CPU0:pod1#show rpl policy example_three uses all

Policies directly and indirectly applied by this policy:
---------------------------------------------------------example_one set-comms
Sets referenced directly and indirectly
---------------------------------------(via applied policies) in this policy:
type prefix-set:
ten-net too-specific
Version 2.0
11105
Module 11
show bgp route-policy Command

To display Border Gateway Protocol (BGP) information about networks
that match an outbound route policy, use the show bgp route-policy
<name> command in EXEC mode. To use the show bgp route-policy
command, the user must be a member of a user group associated with the
BGP global task ID.
_____________________________ Note _________________________
A route-policy must be configured in order to use this command. When
the show bgp route-policy command is entered, routes in the
specified BGP table are compared against the specified route-policy,
and all routes passed by the route-policy are displayed.
_________________________________________________________________
11106
Version 2.0
Module 11
show bgp route-policy Command
RP/0/0/CPU0:pod1#show bgp route-policy sample

BGP router identifier 172.20.1.1, local AS number 1820
BGP main routing table version 729
Dampening enabled
BGP scan interval 60 secs
Status codes: s suppressed, d damped, h history, * valid, > best
i - internal, S stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
* 10.13.0.0/16 192.168.40.24 0 1878 704 701 200 ?
* 10.16.0.0/16 192.168.40.24 0 1878 704 701 i
Version 2.0
11107
Module 11
Other show Commands

show rpl policy <name> detail
This command allows you to examine the configuration of a specific named

route policy. The detail keyword causes all policies and sets which a policy
uses to be displayed along with the policy itself.
show rpl policy <name> attachpoints
This command list by attach point type all attach points that use the
named policy.
show rpl policy <name> references [summary]
This command lists all policies that reference (apply) the named policy.
show rpl policy <name> uses {all | policies | sets} [direct]
This command lists all policies used by a specified name policy.
11108
Version 2.0
Module 11
Other show Commands
show rpl policy <name> detail
show rpl policy <name> attachpoints
show rpl policy <name> references [summary]
show rpl policy <name> uses {all | policies | sets} [direct]
Version 2.0
11109
Module 11
Summary
In this module, you learned:
11110
The definition and basic building blocks of RPL
Attach points are an association between a specific protocol entity and

a named policy
Sets are an unordered collection of route attribute values
Some RPL BGP attributes and operations
Some RPL-specific commands
Version 2.0
Module 11
Review Questions
Version 2.0
11111
Module 11

11112
Version 2.0
Module 12
Multiprotocol Label Switching (MPLS)
Overview
Description
This module discusses the implementation of MPLS in the Cisco IOS XR
operating system software.
Objectives
Describe MPLS forwarding infrastructure
Describe MPLS Label Distribution Protocol implementation
Describe MPLS Traffic Engineering dynamic implementation
Describe MPLS RSVP implementation for MPLS-TE
Version 2.0c
121
Module 12
MPLS Forwarding Infrastructure

Cisco IOS XR software uses an MPLS Forwarding Infrastructure (MFI) to
provide core services for:
Label management
Forwarding
The MFI has data and control planes.

The control plane handles:
Enabling and disabling MPLS on interfaces
Label table allocation and management
Rewrite setup
Interaction with the IGPs
Set up label imposition and disposition
Set up forwarding paths
The data plane handles:
122
Imposition of labels on packets
Disposition of labels in packets
Label swapping
Version 2.0c
Module 12
Core set of services
Label management
Forwarding
Control plane
Enable and disable MPLS on interfaces

Label table allocation and management
Rewrite setup
Interaction with the IGPs
Label imposition and disposition
Forwarding path creation
Data plane
Label imposition, disposition, swapping
Version 2.0c
123
Module 12
MFI Architecture
The MFI has two basic elements:
Label Switching Database (LSD)Resides on both the primary and

standby route processors (RPs)
Label Forwarding Database (LFD)Resides on both the RPs and

modular services cards (MSCs)
The control plane implements both the LSD and the LFD.
The data plane implements a part of the LFD and performs MPLS
encapsulation (encap) and decapsulation (decap).
124
Version 2.0c
Module 12
MFI Architecture
Basic elements
Label Switching
Database (LSD)
Label Forwarding
Database (LFD)
MPLS encapsulation and
decapsulation routines
Control plane
MFI architecture
LFD
MPLS encap and decap
Data plane
Data plane
Version 2.0c
MPLS-TE
LSD
APPL
FIB
Control plane
LSD
LFD
LDP
NetIO
LFD
APPL
encap/
decap
MPLS
encap/
decap
HW ASIC
125
Module 12
The LSD:
Allocates or de-allocates labels
Creates a relationship between the Forwarding Path Identifier (FPI)

and rewrites
Maintains a rewrite database by interacting with the LFD
Implements an application programming interface (API) for

applications to interact with MFI rewrites
Manages interfaces for MPLS
The LFD:
Accepts LSD rewrites
Works with Cisco Express Forwarding (CEF) to keep the output chain
correct during rewrites
Links rewrites to the correct forwarding tables
The resulting label forwarding tables are part of LFD.
126
Version 2.0c
Module 12
MFI Architecture (Cont.)
Label Switch Database (LSD)
Allocates and deallocates

labels
Creates a relationship between
FPIs and rewrites
Maintains a rewrite database
by interacting with the LFD
Implements an API for MPLS
applications to create, modify,
and delete rewrites
Label Forwarding Database

(LFD)
Accepts rewrites from the LSD

Links rewrite to the correct
forwarding tables
Sets up label tables for MPLS
decapsulation
RP
TE
RSVP
LDP
IGP
LSD
RIB
LFD
FIB
MSC or
LC
Version 2.0c
127
Module 12
The LSD on the active RP distributes the label information to the standby
RP (SRP) and to all MSCs or line cards that require the information. The
MSC or line card stores the forwarding information.
128
Version 2.0c
Module 12
MFI Architecture (Cont.)
RP
LSD
LC
LFD
SRP
LFD
LSD
LC
LFD
Version 2.0c
LFD
LC
LFD
129
Module 12
MPLS Forwarding Display Commands

The forwarding commands display information about the operation and
performance of the movement of MPLS-labeled packets. The information
can be seen from both a global and specific-node perspective. These
commands also offer counter-clearing capability to help with
troubleshooting and design.
1210
Local LabelLabel assigned by this router
Outgoing LabelLabel assigned by the next hop or downstream peer,

such as:
UnlabeledNo label for the destination from the next hop, or label
switching is not enabled on the outgoing interface
Pop LabelNext hop advertised an implicit-null label for the

destination
Prefix or Tunnel IDAddress or tunnel to which packets with this

label are going
Outgoing interfaceInterface through which packets with this label

are sent
Next HopIP address of neighbor that assigned the outgoing label
Bytes SwitchedNumber of bytes switched with this incoming label
TOTimeout: Indicates by an * if entry is being timed out in

forwarding
Label switchingNumber of label switching (LFIB) forwarding entries
IPv4 label impositionNumber of IPv4 label imposition forwarding

entries (installed at ingress LSR)
MPLS TE tunnel headNumber of forwarding entries (installed at

ingress LSR) on MPLS TE tunnel head
MPLS TE fast-rerouteNumber of forwarding entries (installed at

PLR) for MPLS traffic-engineering (TE) fast reroute
Forwarding updatesNumber of forwarding updates sent from LSD

(RP/DRP) to LFIB/MPLS (RP/DRP/LC)
Labels in useLocal labels in use (installed in LFIB). These usually

indicate the lowest and highest label in use (allocated by applications).
Furthermore, some reserved labels (range: 0-15), such as explicitnullv4, explicit-nullv6, are installed in the forwarding plane
Version 2.0c
Module 12
MPLS Forwarding Display Commands
MPLS show forwarding commands display output
Globally
By node
RP/0/RP0/CPU0:P1#show mpls forwarding

RP/0/RP0/CPU0:P1#show mpls forwarding location 0/1/CPU0
(Global)
(Node LC 0/1/0)
RP/0/0/CPU0:P5#sho mpls forwarding ?

debug
Include debug information
detail
Detailed information
hardware
Display hardware table information
interface Match outgoing interface
labels
Match label values
location
Specify a location
prefix
Match destination prefix and mask
private
Include private information
summary
Summarized information
tunnels
Tunnel(s) at head
RP/0/0/CPU0:P5#show mpls forwarding

Local Outgoing
Prefix
Label Label
or ID
------ ----------- ----------------16
Unlabelled 100.10.20.1/32
17
18
Pop Label
142.50.20.0/24
19
19
100.10.20.3/32
20
Pop Label
100.10.20.2/32
Outgoing
Interface
-----------tt1
tt1
PO0/3/0/3
tt1
PO0/3/0/3
PO0/3/0/3
Next Hop
--------------100.10.20.1
100.10.20.1
142.50.52.2
100.10.20.1
142.50.52.2
142.50.52.2
Bytes
T
Switched
O
----------- 0
0
0
0
0
0
RP/0/RP0/CPU0:P1#sho mpls forwarding summary

Forwarding entries:
Label switching: 6
IPv4 label imposition: 1
MPLS TE tunnel head: 1
MPLS TE fast-reroute: 0
MPLS TE internal: 0
Forwarding updates:
58 updates, 24 messages
Labels in use:
Reserved: 4
Lowest: 16
Highest: 20
Version 2.0c
1211
Module 12
Additional information about the details of MPLS forwarding paths is

available showing:
1212
MAC/EncapsLength in bytes of Layer 2 header, and length in bytes of

packet encapsulation, including Layer 2 header and label header
MTUMaximum transmission unit (MTU) of labeled packet
Label StackAll the outgoing labels on the forwarded packet
Packets SwitchedNumber of packets switched with this incoming

label
InstalledDate and time label was installed in the label table
OwnerApplication that allocated the label
Version 2.0c
Module 12
MPLS Display Commands (Cont.)
RP/0/0/CPU0:P5#show mpls forwarding detail

Local Outgoing
Prefix
Outgoing
Next Hop
Label Label
or ID
Interface
------ ----------- ----------------- ------------ --------------16
tt1
100.10.20.1
MAC/Encaps: 4/8, MTU: 4470
Label Stack (Top -> Bottom): { 23 }
Packets Switched: 0
Installed: May 3 05:00:59.489 (00:55:17 ago)
Owner: LDP
18
Pop Label
142.50.20.0/24
PO0/3/0/3
142.50.52.2
Label Stack (Top -> Bottom): { Imp-Null }
Packets Switched: 0
Owner: LDP
19
tt1
100.10.20.1
Packets Switched: 0
Owner: LDP
19
100.10.20.3/32
PO0/3/0/3
142.50.52.2
Packets Switched: 0
Owner: LDP
Version 2.0c
Bytes
T
Switched
O
----------- 0
1213
Module 12
Additional information, such as which interfaces are part of the MPLS

configuration, packet counters, and possible reasons for packet drops, is
available. For additional help with determining problems, you can clear
packet counters.
1214
Version 2.0c
Module 12
Display MPLS Forwarding (Cont.)
MPLS-enabled interfaces
RP/0/0/CPU0:P5#sho mpls interface
Interface
LDP
-------------------------- -------POS0/3/0/3
Yes
POS0/4/0/0
Yes
Tunnel
-------Yes
No
Enabled
-------Yes
Yes
Packet forwarding-related commands

RP/0/RP0/CPU0:P1#show mpls packet counters {summary | interface <intf_name>}
[location <node>]
RP/0/RP0/CPU0:P1#clear mpls packet counters { <intf_name> } [ location <node> ]
RP/0/RP0/CPU0:P1#debug mpls packet drop [ location <node> ]
Version 2.0c
1215
Module 12
Label Distribution Protocol

MPLS Label Distribution
Label Distribution Protocol (LDP) provides a standard methodology for hop
by hop, or dynamic label, distribution in an MPLS network by assigning
labels to routes chosen by the underlying Interior Gateway Protocol (IGP)
routing protocol, such as Intermediate System-to-Intermediate System (ISIS) or Open Shortest Path First (OSPF). The resulting labeled paths, called
label switch paths (LSPs), forward labeled traffic across an MPLS
backbone.
LSPs are created dynamically using LDP or manually using MPLS Traffic
Engineering (TE) tunnels, or Fast Reroute backup tunnels.
LDP provides the means for label-switching routers (LSRs) to request,
distribute, and release label prefix-binding information to peer routers in a
network. LDP enables LSRs to discover potential peers and establish LDP
sessions with those peers to exchange label binding information.
The LDP control plane discovers potential peers and establishes sessions
with those peers.
1216
Version 2.0c
Module 12
MPLS label distribution
Paths set up hop by hop or dynamically

Labels assigned to underlying IGP routes
Deployed in a network core
Label Switch Paths (LSP)
LDP created dynamically

LSP TE tunnels manually
FRR backup tunnels
LDP control plane
Potential peer discovery

LDP session establishment
Version 2.0c
1217
Module 12
Enabling LDP
To bring up the MPLS LDP protocol, use the mpls ldp command in global
configuration mode. The MPLS configuration follows a hierarchical
configuration method similar to the rest of the routing protocols.
When LDP is enabled on an interface, the LDP process starts neighbor
discovery by sending link hello messages on the interface, which may
result in eventual session setup with discovered neighbors. The link hello
has an LDP identifier.
If LDP is enabled on traffic engineering tunnel interfaces, targeted
discovery procedures are used instead of link discovery procedures.
1218
Version 2.0c
Module 12
Enabling LDP
Enter MPLS LDP mode

RP/0/RP0/CPU0:P5(config)#mpls ldp
RP/0/RP0/CPU0:P5(config-ldp)#
Specify interfaces for LDP

RP/0/RP0/CPU0:P5(config-ldp)#interface POS 0/3/0/0
RP/0/RP0/CPU0:P5(config-ldp-if)#
Instructor's Note
LDP link hellos are UDP packets sent to the well-known LDP discovery port for all routers on
this subnet group multicast address. Receipt of a LDP link hello identifies a hello adjacency.
Version 2.0c
1219
Module 12
LDP Router ID
The link hello identifier is used to establish a neighbor peer session.
Establishing an LDP session between two neighbors requires a TCP
session connection. MPLS LDP will use the global router ID by default.
LDP uses the globally configured router ID by default. The router-id
command specifies an alternate IP address to use as the LDP router ID. IP
addresses selected as the LDP router ID must be advertisable by the IGP
to a neighboring router.
LDP uses the router ID in the following order:
1. Configured LDP router ID
2. Global router ID (if configured)
_____________________________ Note _________________________
Cisco recommends the router-id be a loopback address.
_________________________________________________________________
The MPLS LDP discovery transport-address command provides an
alternate address for the TCP session. When the interface keyword is
specified, LDP advertises the IP address of the interface in LDP discoveryhello messages sent from the interface. When the ip-address argument is
specified, LDP advertises the specified IP address in LDP discovery-hello
messages sent from the interface.
_____________________________ Note _________________________
When a router has multiple links connecting it to a peer device, the
router must advertise the same transport address in the LDP
discovery-hello messages it sends on all such interfaces.
_________________________________________________________________
1220
Version 2.0c
Module 12
LDP Router ID
Assign a router ID
Used as the source of discovery hello's
RP/0/RP0/CPU0:P5(config)#mpls ldp
RP/0/RP0/CPU0:P5(config-ldp)#router-id loopback0
RP/0/RP0/CPU0:P5(config-ldp)#
Alternate transport addresses
Set a specific address other than the router ID

Address must be advertisable
Enter LDP interface mode
Interface address becomes transport address
Instructor's Note
The transport address would replace the router ID as the routers designated transport address for
the TCP session. The router ID is the default transport address.
Version 2.0c
1221
Module 12
LDP Neighbors
Sessions between neighbors can be managed using some of these
parameters.
Discovery Timers
The LDP discovery hello timer specifies how long to hold a session without
hearing an advertisement from the neighbor. The default value of 15
seconds can be changed with the discovery hello holdtime command.
Likewise, the discovery hello interval command lets you change the
time between neighbor hellos from its default value of 5 seconds.
Security
The password authentication security feature can be enabled for each

neighbor, so that an attempt to establish a session is allowed only when a
password match has been configured. This security option must be
configured so that passwords for both peers match.
There are two keyword options for entering the neighbor password, clear or
encrypted. If neither choice is made, the default for the form of the
password entered will be clear, which is the same as selecting the clear
keyword. During the neighbor password exchange the password will be
transmitted in clear text.
If encrypted is chosen, the form of the password entered must be encrypted
and during the neighbor password exchange the password will be
transmitted using TCP Message Digest 5 (MD5).
The password will always be encrypted when looking at the running
configuration.
1222
Version 2.0c
Module 12
LDP Neighbors
Manage delivery of HELLOs
LDP level for all neighbor
RP/0/RP0/CPU0:P5(config-ldp)#discovery hello holdtime 30

RP/0/RP0/CPU0:P5(config-ldp)#discovery hello interval 25
Use password authentication
TCP MD5
RP/0/RP0/CPU0:P5(config-ldp)#neighbor 192.168.2.44 password secret
Version 2.0c
1223
Module 12
LDP Penultimate Hop

Normally, LDP advertises an implicit null label for directly connected
routes. The label causes the previous hop (penultimate) router to perform
penultimate hop popping (PHP). It may be desirable to prevent the
penultimate router from performing PHP, such as when implementing
end-to-end QoS, and force it to replace the incoming label with the explicit
null label.
To advertise an explicit null in place of the implicit null for directly
connected prefixes, use the explicit-null command.
1224
Version 2.0c
Module 12
LDP Penultimate Hop
LDP PHP implemented by default

QoS extension
Local explicit label advertisement

Default PHP implicit label replacement
RP/0/RP0/CPU0:P5(config-ldp)#explicit-null
Version 2.0c
1225
Module 12
LDP Graceful Restart

MPLS LDP graceful restart (GR) provides a control plane mechanism to
ensure high availability and allows detection and recovery from failure
conditions while preserving nonstop forwarding (NSF) services. GR is a
way to recover from signaling and control-plane failures without impacting
forwarding.
Without LDP GR, when an established session fails, the corresponding
forwarding states are cleaned immediately from the restart and peer
nodes. In this case, LDP forwarding has to restart from the beginning,
causing a potential loss of data and connectivity.
LDP GR is negotiated between two peers during session initialization.
Each peer advertises the following information to its peers:
Reconnect timeSpecifies the maximum time the other peer should

wait for this LSR to reconnect after a control channel failure; the
parameter is reconnect-timeout
Recovery timeSpecifies the maximum time the other peer has to

reinstate or refresh its states with this LSR. This time is used only
during session re-establishment after an earlier session failure
FT flag(Fault Tolerant) Indicates whether a restart could restore the

preserved (local) node state
When the GR session parameters are conveyed and the session is up and
running, GR procedures are activated.
_____________________________ Note _________________________
Currently, the MPLS_LDP process must be restarted for graceful
restart to take affect.
_________________________________________________________________
The value of the forwarding-state-holdtime is used to keep the
forwarding plane state associated with the LDP control plane in case of a
control plane restart or failure. If the control plane fails, then the
forwarding plane keeps the LDP forwarding state for twice the forwarding
state hold time. The value of the forwarding state hold time is also used to
start the local LDP forwarding state hold timer after the LDP control plane
restarts. When the LDP GR sessions are renegotiated with its peers, the
restarting LSR sends the remaining value of this timer as the recovery
time to its peers.
1226
Version 2.0c
Module 12
LDP Graceful Restart
Enabling GR preserves NSF services

RP/0/RP0/CPU0:P5(config-ldp)#graceful-restart
RP/0/RP0/CPU0:P5(config-ldp)#graceful-restart forwarding-state-holdtime
RP/0/RP0/CPU0:P5(config-ldp)#graceful-restart reconnect-timeout
Instructor's Note
When the LDP control plane restarts with GR capability, it starts forwarding-state hold timers
(default: 180 sec, configurable thru GR CLI). After restart, LDP tries to reconnect back with its
neighbors and sends recovery time to its neighbor after the session is reconnected. The value of
the recovery time is set to the remaining time of the fwding-state-hold-timer (If fwding-state
holdtime is to expire in 150 sec, recovery time = 150sec, meaning that neighbor has got 150 secs
to send its fwding state.
The value of the recovery time sent to each peer may be different, depending on the remaining
time for the fwding state holdtime at the time of session negotiation.
Version 2.0c
1227
Module 12
Restarting LDP Sessions

A new EXEC-level CLI command allows you to restart all or specific LDP
sessions. All neighbors can be restarted at once, or a single session can be
restarted by specifying the IP address of the neighbor.
1228
Version 2.0c
Module 12
Restarting LDP Sessions
Restart all sessions

Restart a specific session
RP/0/RP0/CPU0:P1#mpls ldp restart session all
RP/0/RP0/CPU0:P1#mpls ldp restart session A.B.C.D
Version 2.0c
1229
Module 12
Displaying LDP Information

Some show commands provide the necessary general LDP parameter
information, such as:
Protocol VersionLDP version on this router
Router IDCurrent router ID
Session:
Hold timeTime session is to be maintained with the LDP peer

without receiving LDP traffic or keepalive message from the peer
Keepalive intervalsInterval between consecutive transmissions of

keepalive messages to a peer
Backoff parametersInitial maximum session backoff time
Discovery:
1230
Link Hellos:
HoldtimeAmount of time a neighbor wants this router to wait

without receiving a hello message
IntervalTime between transmission of consecutive hello

messages to neighbors
Targeted Hellos
HoldtimeAmount of time a not-directly-connected neighbor

wants this router to wait without receiving a hello message
IntervalTime between transmission of consecutive hello

messages to neighbors not directly connected
Graceful restart (GR):
StatusEnabled or disabled
Reconnect TimeoutAmount of time a neighbor wants this router

to wait after LDP communication failure occurs and while holding
MPLS forwarding state information
Forwarding State HoldtimeTime this router is willing to hold

MPLS forwarding state information
Timeouts:
Binding with no routeTime to wait before deleting invalid route
LDP application recovery (with LSD)Restart recovery time
OOR stateNormal, Major, or Critical

Version 2.0c
Module 12
Displaying LDP Information
View general LDP parameter information

RP/0/0/CPU0:P5#show mpls ldp parameters
LDP Parameters:
Protocol Version: 1
Router ID: 100.10.20.5
Null Label: Implicit
Session:
Hold time: 180 sec
Keepalive interval: 60 sec
Backoff: Initial:15 sec, Maximum:120 sec
Discovery:
Link Hellos:
Holdtime:30 sec, Interval:15 sec
Targeted Hellos: Holdtime:90 sec, Interval:10 sec
Graceful Restart:
Enabled (Configured)
Reconnect Timeout:120 sec, Forwarding State Holdtime:180 sec
Timeouts:
Binding with no-route: 300 sec
LDP application recovery (with LSD): 360 sec
OOR state
Memory: Normal
Version 2.0c
1231
Module 12
LDP discovery information shows interfaces included in the MPLS LDP

implementation, as well as transport addresses for LDP neighbors.
Local LDP IdentifierThe LDP identifier for the local router, displayed
as address:number, where address is the router ID and number is the
label namespace
InterfacesInterfaces involved in LDP discovery, where:
xmitIndicates the interface is transmitting discovery hello

packets
recvIndicates the interface is receiving discovery hello packets
LDP IDLDP ID of the peer
Transport AddressAddress associated with this peer
Hold timeState of the forwarding hold timer and its current value
The LDP neighbor display includes peer identifiers, TCP connection

information, GR information, addresses at that peer, and state
information.
1232
Peer LDP IdentifierLDP identifier of the neighbor (peer) for this

session
Graceful RestartGraceful-restart status (Y or N)
TCP connectionTCP connection used to support the LDP session,

shown in the following format:
peer IP address.peer port
local IP address.local port
StateState of the LDP session. Generally this is Oper (operational),

but transient is another possible state
Msgs sent/rcvdNumber of LDP messages sent to and received from

the session peer. The count includes the transmission and receipt of
periodic keepalive messages, which are required for maintenance of the
LDP session
Up timeThe length of time that this session has been up for (in
hh:mm:ss format)
LDP discovery sourcesThe source(s) of LDP discovery activity that

led to the establishment of this LDP session
Addresses bound to this peerThe known interface addresses of the

LDP session peer. These are addresses that might appear as next hop
addresses in the local routing table. They are used to maintain the
LFIB
Version 2.0c
Module 12
Displaying LDP Information (Cont.)
View LDP discovery information

RP/0/0/CPU0:P5#show mpls ldp discovery
Local LDP Identifier: 100.10.20.5:0
Discovery Sources:
Interfaces:
POS0/3/0/3 : xmit/recv
LDP Id: 100.10.20.2:0, Transport address: 100.10.20.2
Hold time: 30 sec (local:30 sec, peer:30 sec)
POS0/4/0/0 : xmit/recv
LDP Id: 100.10.20.1:0, Transport address: 100.10.20.1
Hold time: 30 sec (local:30 sec, peer:30 sec)
View LDP neighbor information

RP/0/0/CPU0:P5#show mpls ldp neighbor
Peer LDP Identifier: 100.10.20.1:0
TCP connection: 100.10.20.1:646 - 100.10.20.5:63604
Graceful Restart: Yes (Reconnect Timeout: 120 sec, Recovery: 0 sec)
Session Holdtime: 180 sec
State: Oper; Msgs sent/rcvd: 25/25
Up time: 00:11:28
LDP Discovery Sources:
POS0/4/0/0
Addresses bound to this peer:
172.21.116.10
100.10.20.1
172.21.116.11
142.50.44.1
142.50.12.1
Peer LDP Identifier: 100.10.20.2:0
TCP connection: 100.10.20.2:646 - 100.10.20.5:53633
Graceful Restart: Yes (Reconnect Timeout: 120 sec, Recovery: 0 sec)
Session Holdtime: 180 sec
State: Oper; Msgs sent/rcvd: 25/27
Up time: 00:11:24
LDP Discovery Sources:
POS0/3/0/3
Addresses bound to this peer:
172.21.116.15
172.21.116.16
142.50.40.22
142.50.20.2
142.50.24.2
142.50.52.2
100.10.20.2
Version 2.0c
1233
Module 12
The show mpls ldp bindings command provides the label information for
both those assigned locally and for those learned from LDP neighbors:
a.b.c.d/nIP prefix and mask for a particular destination
revRevision number (rev) that is used internally to manage label

distribution for this destination
local bindingLocally assigned label for a given prefix
remote bindingsOutgoing labels for this destination learned from

other LSRs. Each item in this list identifies the LSR from which the
outgoing label was learned and reflects the label associated with that
LSR. Each LSR in the transmission path is identified by its LDP
identifier
(rewrite) Binding has been written into MPLS forwarding and is in

use
(no route) Route is not valid. LDP times it out before the local
binding is deleted
LDP forwarding and GR information is also available using show

commands. The graceful restart information:
1234
Forwarding State Hold timerState of the hold timer, running or not

running
Forwarding EntriesNumber of checkpointed entries, number of

graceful restartable entries, number of non-graceful restartable entries,
number of entries marked as stale, and number of entries without path
up
GR neighborsNumber of graceful restartable neighbors
Neighbor IDRouter ID of each neighbor
UpNeighbor up or down
Connect countNumber of times the same neighbor has re-connected
Liveness timersState of the liveness timer (running or not running)

and its expiration time, if running
Recovery timerState of the recovery timer (running or not running)

and its expiration time, if running
Version 2.0c
Module 12
Displaying LDP Information (Cont.)
View LDP label bindings

RP/0/0/CPU0:P5#show mpls ldp bindings
100.10.20.1/32 , rev 10
local binding: label:16
remote bindings :
lsr:100.10.20.1:0, label:IMP-NULL (rewrite)
lsr:100.10.20.2:0, label:16
100.10.20.2/32 , rev 18
remote bindings :
lsr:100.10.20.1:0, label:19
100.10.20.3/32 , rev 16
remote bindings :
lsr:100.10.20.1:0, label:18 (rewrite)
lsr:100.10.20.2:0, label:19 (rewrite)
100.10.20.5/32 , rev 20
local binding: label:IMP-NULL
remote bindings :
lsr:100.10.20.1:0, label:20
lsr:100.10.20.2:0, label:20
142.50.12.0/24 , rev 12
remote bindings :
lsr:100.10.20.2:0, label:17
Assigned
locally
Learned
View LDP forwarding information

RP/0/0/CPU0:P5#show mpls forwarding
Local Outgoing
Prefix
Label Label
or ID
------ ----------- ----------------16
17
18
Pop Label
142.50.20.0/24
19
19
100.10.20.3/32
20
Pop Label
100.10.20.2/32
Outgoing
Interface
-----------tt1
tt1
PO0/3/0/3
tt1
PO0/3/0/3
PO0/3/0/3
Next Hop
Bytes
T
Switched
O
--------------- ----------- 100.10.20.1
0
100.10.20.1
0
142.50.52.2
0
100.10.20.1
0
142.50.52.2
0
142.50.52.2
0
View LDP GR information

RP/0/0/CPU0:P5#show mpls ldp graceful-restart
Forwarding State Hold timer : Not Running
Forwarding Entries
: 6 Checkpointed (3 GR, 3 non-GR)
0 Stale, 0 without PathUp
GR Neighbors
: 2
Neighbor ID
--------------100.10.20.1
100.10.20.2
Up
-Y
Y
Connect Count
------------3
3
Liveness Timer
------------------
Version 2.0c
Recovery Timer
------------------
1235
Module 12
MPLS Traffic Engineering

Overview
MPLS traffic engineering automatically establishes and maintains label
switched paths (LSPs) across a backbone network by using Resource
Reservation Protocol (RSVP). The path that an LSP uses is determined by
the LSP resource requirements and network resources, such as bandwidth.
Available resources are flooded by means of extensions to a link-statebased Interior Gateway Protocol (IGP).
Traffic engineering tunnels are calculated at the LSP head router based on
a fit between the required and available resources (constraint-based
routing). The IGP automatically routes the traffic to these LSPs.
1236
Version 2.0c
Module 12
Traffic Engineering Overview
How it works
Establishes and maintains LSPs
Uses RSVP
LSP path determined by:
Resource requirements
Available resources
Bandwidth
Resource info passed on by link-state IGP
Version 2.0c
1237
Module 12
Traffic Engineering Steps

To set up MPLS-TE with Cisco IOS XR software, follow these steps:
1. Determine and configure the IGP to be used.
2. Create TE tunnels.
3. Enable MPLS-TE interfaces.
4. Turn on RSVP signaling and set the interfaces and bandwidth.
1238
Version 2.0c
Module 12
Traffic Engineering Steps
1.
Determine and configure the IGP routing protocol relationship
2.
3.
4.
IS-IS
OSPF
Set IGP-to-TE configuration
Router ID (required)
Area (OSPF) or Level (ISIS)
Create TE Tunnels
P1
Turn on IPv4 for tunnel

Set destination
Set bandwidth
Set priority
Set tunnel advertisements
Create paths
Explicit
Dynamic
PE4
P4
P5
PE5
P2
Determine the MPLS-TE interfaces
Enable the interfaces

Set other parameters
Set RSVP signaling
Set the interfaces

Set the bandwidth on the interfaces
Version 2.0c
1239
Module 12
Creating an IGP Relationship

Traffic engineering tunnels are calculated at the LSP head. The IGP routes
the traffic onto these LSPs after MPLS-TE is turned on within the routing
context.
OSPF Setup
Here is an example of setting up OSPF:

RP/0/0/CPU0:POD5(config)#router ospf 1
RP/0/0/CPU0:POD5(config-ospf)#router-id 10.10.10.10
RP/0/0/CPU0:POD5(config-ospf)#area 0
IS-IS Setup
Here is an example of setting up IS-IS:

RP0/0/0/CPU0:POD5(config)#router isis POD5
RP0/0/0/CPU0:POD5(config-isis)#address-family ipv4
RP/0/0/CPU0:POD5(config-isis-af)#metric-style wide level 1
1240
Version 2.0c
Module 12
Creating an IGP Relationship
IGP routing protocol

MPLS traffic engineering configuration
OSPF example:
RP/0/RP0/CPU0:P5(config-ospf)#mpls traffic-eng router-id loopback0
RP/0/RP0/CPU0:P5(config-ospf)#mpls traffic-eng area 0
RP/0/RP0/CPU0:P5(config-ospf)#
IS-IS example:
RP/0/RP0/CPU0:P5(config-isis-af)#mpls traffic-eng level 1
RP/0/RP0/CPU0:P5(config-isis-af)#mpls traffic-eng router-id loopback1
RP/0/RP0/CPU0:P5(config-isis-af)#
Version 2.0c
1241
Module 12
Creating MPLS-TE Tunnels

Creating an MPLS-TE topology is required for traffic engineering tunnel
operations. Physical interfaces used for tunnel traffic must also have IP
addresses.
The first step in MPLS-TE is to create a tunnel, which is an interface and
is configured in interface configuration submode.
1242
Version 2.0c
Module 12
Creating MPLS-TE Tunnels
Configure a tunnel using interface mode
Locally significant identity
RP/0/RP0/CPU0:P5(config)#interface tunnel-te4
RP/0/RP0/CPU0:P5(config-if)#
P1
PE4
P4
P5
PE5
P2
Version 2.0c
1243
Module 12
Creating an Unnumbered IP Address

To configure an origination IP address for an MPLS traffic engineering
tunnel, use the ipv4 unnumbered loopback0 command in tunnel
configuration submode.
1244
Version 2.0c
Module 12
Creating an Unnumbered IP Address
Tunnel state is down until IP address is configured
Head-end IP address
Loopback address is recommended
RP/0/RP0/CPU0:P5(config-if)#ipv4 unnumbered loopback0

100.10.20.5
P1
PE4
P4
P5
PE5
P2
Version 2.0c
1245
Module 12
Creating a Tunnel Destination

To configure a destination address for an MPLS traffic engineering tunnel,
use the keyword destination command in tunnel configuration submode.
1246
Version 2.0c
Module 12
Creating a Tunnel Destination
Tunnels require destinations
IP address or host name
RP/0/RP0/CPU0:P5(config-if)#destination 100.10.20.4
100.10.20.5
P1
PE4
P4
P5
PE5
P2
100.10.20.4
Version 2.0c
1247
Module 12
Setting the Bandwidth

To set the bandwidth required for an MPLS-TE tunnel, use the
bandwidth command in tunnel configuration submode. Bandwidth is
specified in kilobits per second (Kbps) and is reserved in the interfaces
global bandwidth pool. This is the maximum bandwidth available to this
tunnel.
1248
Version 2.0c
Module 12
Setting the Bandwidth
Tunnel bandwidth required end-to-end
Specified in kilobits per second

Reserved in interface global pool by default
RP/0/RP0/CPU0:P5(config-if)#bandwidth 100000
100.10.20.5
P1
To here
P5
PE5
From here
PE4
P4
P2
100.10.20.4
Version 2.0c
1249
Module 12
Setting Priority
There are two priority settings, setup and hold.
Setup priority is used when signaling a label switched path (LSP) for the
tunnel, to determine which existing tunnels can be preempted. Valid
values are from 0 to 7, where a lower number indicates a higher priority.
Therefore, an LSP with a setup priority of 0 can preempt any LSP with a
non-0 priority.
Hold priority is associated with an LSP for the tunnel, to determine if it
should be preempted by other LSPs that are being signaled. Valid values
are from 0 to 7, where a lower number indicates a higher priority. The
lower the priority value, the less likely the tunnel will be preempted.
1250
Version 2.0c
Module 12
Setting Priority
Tunnel priority
Setup
Hold
RP/0/RP0/CPU0:P5(config-if)#priority 1 1
100.10.20.5
P1
PE4
P4
P5
PE5
P2
100.10.20.4
Version 2.0c
1251
Module 12
Using the MPLS Path Option

To configure a path option for an MPLS traffic engineering tunnel, use the
path-option command in tunnel configuration submode.
You can configure several path options for a single tunnel. For example,
several explicit path options and a dynamic option can exist for one tunnel.
Path setup preference is for lower (not higher) numbers, so option 1 in the
example on the slide is preferred.
1252
Version 2.0c
Module 12
Using the MPLS Path Option
Provide multiple paths for a tunnel
Explicit is a static path

Dynamic finds the best path
Lower path number is preferred
RP/0/RP0/CPU0:P5(config-if)#path-option 1 dynamic
RP/0/RP0/CPU0:P5(config-if)#path-option 2 explicit name alternate
100.10.20.5
P1
P5
PE5
Alternate
PE4
P4
P2
100.10.20.4
Version 2.0c
1253
Module 12
Setting IGP Tunnel Usage

For the IGP to use a tunnel in its shortest path first (SPF) calculations, use
the autoroute announce command is used when configuring the tunnel.
1254
Version 2.0c
Module 12
Setting IGP Tunnel Usage
IGP should use the tunnel in path calculation

RP/0/RP0/CPU0:P5(config-if)#autoroute announce
100.10.20.5
P1
P5
PE5
Used in
IGP here
PE4
P4
P2
100.10.20.4
Version 2.0c
1255
Module 12
Enabling MPLS-TE on Interfaces

To enable interfaces to participate in traffic engineering, enter the MPLS
traffic engineering submode and add the interfaces. The RSVP process
becomes active when these commands are committed to the configuration.
1256
Version 2.0c
Module 12
Enabling MPLS-TE on Interfaces
Enter MPLS traffic engineering mode

Enable MPLS-TE interfaces
RSVP enabled (automatically)
RP/0/RP0/CPU0:P5(config)#mpls traffic-eng
RP/0/RP0/CPU0:P5(config-mpls-te)#interface POS 0/4/0/0
RP/0/RP0/CPU0:P5(config-mpls-te-if)#interface pos 0/3/0/3
RP/0/RP0/CPU0:P5(config-mpls-te-if)#
100.10.20.5
POS0/4/0/0
P1
P5
PE5
POS0/3/0/3
PE4
P4
P2
100.10.20.4
Version 2.0c
1257
Module 12
Configuring RSVP
To enter the RSVP configuration submode, use the rsvp command in the
global configuration mode. From this submode, RSVP global and interface
configuration commands can be entered.
This submode allows configuration of global RSVP parameters, such as GR
(signaling) and interface-specific configuration.
To configure RSVP on an interface, use the interface command in the
RSVP configuration submode. This command changes the configuration
mode to the RSVP interface submode, within which you can enter
interface-specific configuration commands; including setting the maximum
bandwidth that will be used. The bandwidth is allocated in kilobits per
second (Kbps). If no bandwidth is configured, a default amount of 75
percent of the total bandwidth of the link is allocated.
1258
Version 2.0c
Module 12
Configuring RSVP
Sets up signaling
Enter the RSVP context
Set the interfaces to be used
Set the total bandwidth available for reservation
Default is 75% of link bandwidth (when no amount is specified)
RP/0/RP0/CPU0:P5(config)#rsvp
RP/0/RP0/CPU0:P5(config-rsvp)#interface POS 0/4/0/0
RP/0/RP0/CPU0:P5(config-rsvp-if)#bandwidth 100000
RP/0/RP0/CPU0:P5(config-rsvp-if)#
RP/0/RP0/CPU0:P5(config-rsvp-if)#interface POS 0/3/0/3
RP/0/RP0/CPU0:P5(config-rsvp-if)#bandwidth
RP/0/RP0/CPU0:P5(config-rsvp-if)#
Physical
link
% of
link b/w
for all
other traffic
TE
tunnels
RSVP
bandwidth
Unused b/w
for other
RSVP signaled
traffic: DSCP
Instructor's Note
Slide is animated. Click 1 RSVP bandwidth appears; click 2 TE tunnels appear; click 3
RSVP bandwidth disappears, unused b/w for other RSVP traffic: DSCP appears; click 4
% of link b/w available for all other traffic appears
Version 2.0c
1259
Module 12
Examining MPLS-TE Operation

Displaying MPLS-TE Topology
To display the current MPLS-TE network topology, use the show mpls
traffic-eng topology command. This command provides valuable
information about the IGP being used and the relationship with MPLS-TE:
1260
My_system_idLocal IGP router ID and protocol in use for TE
Signaling error holddownLink hold-down timer configured to handle

path error events before excluding link from topology
IGP IdAdvertising router identity
MPLS TE IdTunnel head end ID
LinkMPLS TE link type
Frag IdGateway protocol link state advertisement fragment ID
Nbr Intf AddressNeighbor interface address for this link
TE metriccost of this link
Physical BWPhysical line rate
Max Reservable BW GlobalMaximum amount of bandwidth, in

kilobits per second, that you can reserve in this link global pool
Max Reservable BW SubMaximum amount of bandwidth, in kilobits

per second, that you can reserve in this link sub-pool
Total Allocated BWTotal amount of bandwidth (in kbps) allocated at

this priority
Global Pool Reservable BWAmount of available bandwidth

reservable at this priority
Sub Pool Reservable BWAmount of available bandwidth reservable

at this priority
Version 2.0c
Module 12
Displaying MPLS-TE Topology
RP/0/0/CPU0:P5#sho mpls traffic-eng topology

My_System_id: 142.50.52.5 (ospf
area 0)
Signalling error holddown: 10 sec Global Link Generation 2
IGP Id: 142.50.52.5, MPLS TE Id: 100.10.20.5 Router Node
(ospf
area 0)
Link[0]:Point-to-Point, Nbr IGP Id:142.50.20.2, Nbr Node Id:-1, gen:2

Frag Id:0, Intf Address:142.50.52.5, Intf Id:0
Nbr Intf Address:142.50.52.2, Nbr Intf Id:0
TE Metric:1, IGP Metric:1, Attribute Flags:0x0
Switching Capability:, Encoding:
Physical BW:155520 (kbps), Max Reservable BW Global:0 (kbps)
Max Reservable BW Sub:0 (kbps)
Global Pool
Sub Pool
Total Allocated
Reservable
Reservable
BW (kbps)
BW (kbps)
BW (kbps)
---------------------------------bw[0]:
0
0
0
bw[1]:
0
0
0
Additional output omitted

IGP Id: 100.10.20.1, MPLS TE Id: 100.10.20.1 Router Node
(ospf
area 0)
Version 2.0c
1261
Module 12
Displaying MPLS-TE Tunnels

To display tunnel information, enter the show mpls traffic-eng tunnels
command.
Note the destination, status, history, and path information that can be
used to verify operation:
1262
LSP Tunnels ProcessStatus of the LSP tunnels process
RSVP ProcessStatus of the RSVP process
ForwardingStatus of forwarding (enabled or disabled)
HeadSummary information about tunnel heads at this device
TailsSummary information about tunnel tails at this device
Periodic reoptimizationTime until the next periodic reoptimization

(in seconds)
Periodic FRR PromotionTime until the next periodic FRR promotion

(in seconds)
Periodic auto-bw collectionTime until the next periodic auto-bw

collection (in seconds)
RouterSummary information for router tunnels
SummarySummary information for FRR
BackupNumber of assigned backup tunnels
InterfacesNumber of MPLS TE tunnel interfaces
Version 2.0c
Module 12
Displaying MPLS-TE Tunnels
RP/0/0/CPU0:P5#sho mpls traffic-eng

Signalling Summary:
LSP Tunnels Process:
RSVP Process:
Forwarding:
Periodic reoptimization:
Periodic FRR Promotion:
Periodic auto-bw collection:
tunnels
running
running
enabled
every 3600 seconds, next in 3403 seconds
every 300 seconds, next in 245 seconds
disabled
Name: tunnel-te1 Destination: 100.10.20.1

Status:
Admin:
up Oper:
up
Path: valid
Signalling: connected
path option 1, type dynamic
(Basis for Setup, path weight 3)
History:
Tunnel has been up for: 00:01:51
Current LSP:
Uptime: 00:01:51
Path info (ospf
area 0):
Hop0: 142.50.52.2
Hop1: 142.50.20.3
Hop2: 142.50.12.1
Hop3: 100.10.20.1
LSP Tunnel P1_t5
100.10.20.5
is signaled, connection is up
Version 2.0c
1263
Module 12
With the show mpls traffic-engineering tunnels brief command, Cisco

IOS XR software displays only the heads and tails of the tunnels. Note the
message indicating that midpoint information is not available.
1264
Version 2.0c
Module 12
Displaying MPLS-TE Tunnels (Cont.)
RP/0/0/CPU0:P5#sho mpls traffic-eng tunnels brief

Signalling Summary:
LSP Tunnels Process: running
RSVP Process: running
Forwarding: enabled
Periodic reoptimization: every 3600 seconds, next in 3180 seconds
Periodic FRR Promotion: every 300 seconds, next in 22 seconds
Periodic auto-bw collection: disabled
TUNNEL NAME
DESTINATION
STATUS STATE
tunnel-te1
100.10.20.1
up up
P1_t5
100.10.20.5
up up
Displayed 1 (of 1) heads, 1 (of 1) tails
Displayed midpoint: Information not available via this command
Displayed 1 up, 0 down, 0 recovering, 0 recovered heads
Version 2.0c
1265
Module 12
The show mpls traffic-eng tunnels summary command includes the

signaling summary, as well as a summary of any fast reroute tunnels that
may be set up.
1266
Version 2.0c
Module 12
Displaying MPLS-TE Tunnels (Cont.)
Summary of TE tunnels
RP/0/RP0/CPU0:P5#show mpls traffic-eng tunnels summary
Signalling Summary:
LSP Tunnels Process: running
RSVP Process: running
Forwarding: enabled
Head: 2 interfaces, 2 active signalling attempts, 2 established
0 explicit, 2 dynamic
6 activations, 4 deactivations
0 recovering, 0 recovered
Mids: 0
Tails: 0
Periodic reoptimization: every 60000 seconds, next in 22016 seconds
Periodic FRR Promotion: every 300 seconds, next in 146 seconds
Periodic auto-bw collection: every 300 seconds, next in 116 seconds
Fast ReRoute Summary:
Head:
1 frr tunnels, 1 protected, 0 rerouted
Mid:
0 frr tunnels, 0 protected, 0 rerouted
Summary: 1 protected, 1 link protected, 0 node protected, 0 bw protected
Backup:
1 tunnels, 1 assigned
Interface: 1 protected, 0 rerouted
Version 2.0c
1267
Module 12
Displaying RSVP Information

Using the show rsvp interface command, you can see information about
the RSVP interfaces, including maximum bandwidth allowed and the
current allocations. For Differentiated Services implementations, the
amount of subpool bandwidth allocated is shown.
The show rsvp reservation command displays information about the
reservations of bandwidth that have been activated.
1268
Version 2.0c
Module 12
Displaying RSVP Information
Interfaces
RP/0/RP0/CPU0:POD1#show rsvp int
Interface
MaxBW
MaxFlow Allocated
MaxSub
----------- -------- -------- --------------- -------PO0/4/0/1
10M
10M
2M ( 20%)
0
PO0/4/0/3
10M
10M
2M ( 20%)
0
Reservations
RP/0/0/CPU0:P5#show rsvp reservation
Destination Add DPort
Source Add SPort Pro
Input IF Sty Serv Rate Burst
---------------- ----- ---------------- ----- --- ---------- --- ---- ---- ----100.10.20.1
1
100.10.20.5 1635
0 PO0/3/0/3 SE LOAD 10M
1K
100.10.20.5
5
100.10.20.1 1636
0
None SE LOAD 10M
1K
Version 2.0c
1269
Module 12
Summary
1270
Describe MPLS forwarding infrastructure
Describe MPLS Label Distribution Protocol implementation
Describe MPLS Traffic Engineering dynamic implementation
Describe MPLS RSVP implementation for MPLS-TE
Version 2.0c
Module 12
Review Questions
Version 2.0c
1271
Module 12

1272
Version 2.0c
Module 13
Craft Works Interface (CWI)
Overview
Description
This module describes the Craft Works Interface (CWI) software and the
benefits of using it. In this module you learn to use CWI to configure and
manage Cisco IOS XR routers.
Objectives
Start CWI and log in
Describe the basic operation of CWI
Navigate the CWI Desktop
Use CWI Desktop applications
Configure the router using Configuration Editor
Configure the router using the graphical configuration applications
Version 1.0b
131
Module 13
CWI Overview
Platform
CWI is a client-side Java-based application used to configure, manage, and
monitor a Cisco CRS-1 Carrier Routing System or Cisco XR 12000 Router
in your network. CWI was designed to manage large scale routers.
CWI can manage multiple routers in a single session. CWI compliments
and enhances the Cisco IOS XR feature set.
The CLI-based graphical configuration provides flexibility to enable you to
select the best interface for the specific task at hand.
132
Version 1.0b
Module 13
CWI Overview
Platform
Designed from the ground up to manage:
Very large scale products -> Multishelf CRS-1

Multiple router platforms, chassis, and software
versions
Full Cisco IOS XR feature set, including:
Logical Routers (LR)

Flexible interface options
Choice of both physical and logical views

Multiple modes to configure the same component
Version 1.0b
133
Module 13
Management
The CWI includes configuration, fault, and inventory management
features with an emphasis on speed, efficiency, and reduced mistakes. This
is accomplished, such as bulk configuration, export of tabular data, client
side validation and context sensitivity.
CWI provides a consistent look and feel. After becoming familiar with one
application, learning others becomes much simpler.
134
Version 1.0b
Module 13
CWI Overview
Management
Simplify management of a large number of

objects:
Export of tabular data

Client side validation
Context sensitivity
Value-added features (bulk configuration)
Shallow learning curve of User Interface:
Well known GUI look and feel

Consistent view between applications
Version 1.0b
135
Module 13
CWI Launch
CWI uses Hypertext Transfer Protocol (HTTP) for the initial connection
from the desktop client to the router and the loading of the CWI files. The
files are locally cached to speed subsequent CWI launches.
CWI is currently launched from a browser, although stand-alone usage will
be a future enhancement. Even though the browser is used for the initial
loading of the Jar files, the browser can be closed after login.
136
Version 1.0b
Module 13
CWI Overview
CWI Launch
HTTP
JARJAR
HTTP is used for:
CWI
clients
Initial connection
Loading of the CWI
applet and Jar files
Version 1.0b
CRS-1
137
Module 13
Run-Time Transport
CWI can communicate with the router using the following methods:
CLI over Serial Console or Terminal Server
CLI over Telnet and SSH
XML over Telnet and SSH
XML over CORBA and CORBA SSL
The initial requests from the CWI client to the HTTP server on the router
for the Jar files that contain the plug-ins are exchanged over TCP/IP
between HTTP ports. TCP/IP is also used as the underlying protocol for all
XML exchanges; Telnet, SSH and CORBA run over TCP.
The Common Object Request Broker Architecture (CORBA) is a set of
specifications to support platform- and language-independent, objectoriented distributed computing. CORBA is middleware technology, serving
to connect diverse components of a software system. Requests from the
CWI client made in XML format, are transferred over a CORBA bus using
CORBA Naming and Notification Services. The router sends responses and
notifications in XML over the CORBA bus.
Instructor's Note
CORBA was devised as an open standard by an assembly of over 800 corporations in the
computing industry, known collectively as the Object Management Group, to encourage
interoperability between systems regardless of platform or implementation language.
138
Version 1.0b
Module 13
CWI Overview
Run-Time Transport
IOS XR router
CWI client
Launcher
HTTP Jar files
HTTP
server
HTTP Jar files
Telnet/SSH CLI
Serial Console/Terminal Server CLI
CWI
Command
parser
Telnet, SSH
CORBA XML
CORBA
agent
CORBA XML
notifications
CORBA
services
CORBA bus
Version 1.0b
139
Module 13
Security Features
CWI will auto detect the most secure transport for the selected connection
type. User login and command privileges are handled by the normal router
AAA functions.
1310
Version 1.0b
Module 13
CWI Overview
Security Features
HTTP
Linked to AAA authentication
HTTPS
Linked to AAA authentication; encryption; required if using IIOP SSL
IIOP
Authentication to access XML (linked to AAA authentication)
IIOP SSL v2
Authentication to access XML (linked to AAA authentication)

encryption
Telnet
Authentication to access CLI (linked to AAA authentication)
SSH v1/v2
Authentication to access CLI (linked to AAA authentication)

encryption
AAA
Authorization
Authentication (used by HTTP/HTTPS, IIOP SSL, Telnet/SSH, IPsec)
Accounting
Version 1.0b
1311
Module 13
CWI Desktop Window

The CWI Desktop is the window that opens when you log in to CWI. This
window is the main point of access to all CWI applications and tools used
to manage and configure the Cisco IOS XR router.
Window Panes
The CWI Desktop window has two primary panes. The panes allow you to
view the routers with associated objects and use the applications that let
you manage the routers. These panes are:
Inventory TreeDisplays all Cisco IOS XR router objects in a

physical or logical representation
Application paneDisplays all active applications
Toolbar
Above the two primary panes is the Application toolbar, which contains
tool icons that represent commonly used tasks in the application pane.
From left to right, these tools are:
1312
PrintPrints a report based on the active application. When printing

reports, the default web browser opens, displaying the information that
is printed in tabular format, and automatically opens the web browser
Print dialog box.
ExportExports the selected report to a text (comma- or tabseparated) or HTML file.
FindOpens the Find dialog box, allowing you to search the active
window for specific text.
Find NextFinds the next instance of the specific text in the active
window.
CutRemoves the currently selected data or text and moves it to the

Clipboard.
CopyCopies the currently selected data or text and moves it to the

Clipboard.
PastePastes the data or text from the Clipboard into the currently
selected field.
RefreshRefreshes the content in the active window in the

Configuration Applications pane.
Version 1.0b
Module 13
CWI Overview
Desktop Window
Menu bar
Toolbar
Inventory
Tree
Application
pane
Status bar
Instructor's Note
Same slide for following page!!! One slide covers 2 text pages!
Version 1.0b
1313
Module 13
PreferencesOpens the Table Preferences dialog box, allowing you to

select the columns to be displayed in the active application table.
Help ContentsOpens the CWI Online Help for the currently active
application.
Active AlarmsOpens the Alarm Viewer application and displays all

active alarms on the chosen object in the Application Tree.
All AlarmsOpens the Alarm Viewer application and displays all

active, cleared, and non-bistate alarms on the chosen object in the
Application Tree.
Inventory ViewerOpens the Inventory Viewer application and

displays detailed information on the chosen object in the Applications
Tree.
Status Bar
Located at the bottom right of the CWI Desktop window, the status bar
provides information on the status of the CWI Desktop. The left side of the
status bar may contain a progress message when the application is
processing a task. There are three icons on the right side of the status bar:
Secure ConnectionShows the status of the established

communication between the CWI Desktop and the router. If the open
lock icon is displayed, the connection is using a nonencrypted channel
(not secure), and if the closed lock icon is displayed, the connection is
using an encrypted channel (secure).
Alarm DashboardWhen the icon is double-clicked, the Alarm

Dashboard opens to display an alarm count of all active alarms on the
routers you are currently logged in to using CWI.
NE Connectivity StatusShows the connection status between the

CWI Desktop and the router management agent. The icon shows a
green connection line if the CWI Desktop is connected to all
management agents and a red connection line if the CWI Desktop has a
broken connection to any management agent.
_____________________________ Note _________________________

CWI locks when there is no activity in the CWI session for 15 minutes.
To unlock it, you must provide the username and password used when
logging in to the router.
_________________________________________________________________
1314
Version 1.0b
Module 13
CWI Overview
Desktop Window (Cont.)
Menu bar
Toolbar
Inventory
Tree
Application
pane
Status bar
Version 1.0b
1315
Module 13
Desktop Menu
The CWI Desktop menu bar provides a list of options available based on
the chosen object and active application. The CWI Desktop menu bar is
located under the CWI Desktop title bar.
From left to right, the CWI Desktop menu options are:
1316
FileAllows you to log in to multiple routers, log out of a router, lock

the CWI session, print and export CWI application data and text, and
exit CWI.
EditAllows you to cut, copy, and paste CWI application data and
text, search for data and text in a CWI application, and specify CWI
application preferences.
ViewAllows you to show and hide the CWI Desktop toolbar, status
bar, Alarm Dashboard, and display objects in the Inventory Tree in
logical and physical views.
ToolsAllows you to open the CWI applications used to manage the

Cisco IOS XR routers.
WindowAllows you to close CWI applications, cascade and minimize

open CWI applications in the application pane, and choose the active
CWI application.
HelpAllows you to view the online help and the CWI application
version information.
Version 1.0b
Module 13
CWI Overview
Desktop Menu
Version 1.0b
1317
Module 13
Inventory Tree
A Logical Router is a collection of physical inventory contained in racks
that forms a complete router. The Inventory Tree displays a dynamic
expandable and collapsible hierarchy of LR objects in two possible views.
Multiple LRs can be logged in to and displayed in the Inventory Tree.
Physical View
The Physical View displays all objects in a logical router (LR), arranged
according to physical location in racks, providing a physical reference for
objects in a router. The Physical View is useful when performing
operations on a complete rack and for providing a logistical frame of
reference.
Logical View
The Logical View displays all of the LR objects shown under a single LR,
facilitating operations on all objects of an LR. This is the default view of
the Inventory Tree.
1318
Version 1.0b
Module 13
CWI Overview
Inventory Tree
Version 1.0b
1319
Module 13
Tools Menu
The tools menu allows you to invoke a specific desktop application:
1320
Active Alarms and All AlarmsOpens the Alarm Viewer

application, which allows you to dynamically view active or all (active,
cleared, and non-bistate) alarm records.
Inventory ViewerAllows you to retrieve object attribute

information, making it available for viewing or export.
Rack ViewDisplays a dynamic graphical view of the physical

components that make up the router. It allows you to interact and
obtain information on the physical equipment.
Interface ViewerDisplays a table-based view of the interface

configuration.
Configuration DesktopOpens the Configuration Desktop. All

configuration applications are opened from the Configuration Desktop
Version 1.0b
Module 13
CWI Overview
Tools Menu
Version 1.0b
1321
Module 13
Alarm Dashboard
The Alarm Dashboard displays an alarm count, by severity, of all active
alarms on all Cisco IOS XR routers to which you are currently logged in
from CWI. Six alarm severity levels are indicated by colored buttons in the
Dashboard. Each severity button indicates the number of active alarms of
that severity on the Cisco routers. Moving the mouse pointer over a
severity button provides a tool-tip description of the severity, as shown
below:
Alarm Severity
Color
Description
Emergency
Red
System is unusable
Alert
Purple
Critical system condition exists,

requiring immediate action
Critical
Orange
Critical system condition exists
Error
Yellow
Noncritical error occurred
Warning
Blue
Warning occurred
Notification
Green
Changes to system configuration

are noted
You can open the Alarm Viewer application for a specific alarm severity by
double-clicking the severity button on the Alarm Dashboard.
_____________________________ Note _________________________
After double-clicking a severity button, the Alarm Dashboard closes
when the Alarm Viewer application opens.
_________________________________________________________________
The button on the far right of the Dashboard indicates a running count of
all alarm notifications on the Cisco routers since the last reset. Doubleclick the running count button to reset the count to zero (0).
The connection status between CWI and the management agent on the
router is indicated by the NE Connectivity Status icon which looks like a
PC and communications link on the middle right of the Dashboard. The
icon shows a green communication link if the connection is good and a red
link if it is broken.
1322
Version 1.0b
Module 13
CWI Overview
Alarm Dashboard
Emergency (red)
Critical (orange)
Warning (blue)
Running count
Alert (purple)
Error (yellow)
Notification (green)
Double-click on:
Specific severity to display chosen alarms in Alarm Viewer

Running count to zero displayed value
Version 1.0b
1323
Module 13
Desktop Applications
Alarm Viewer
The Alarm Viewer application allows you to dynamically view alarm
records from the alarm management functions of the router. Alarm Viewer
can be started from the following areas in the CWI Desktop.
Inventory Tree
Rack View
CWI Dashboard
CWI Desktop menu
The Alarm Viewer window is the basically the same regardless of whether
it contains all alarms or active alarms. The only difference is that Alarm
Viewer for all alarms contains active, cleared, and non-bistate alarms, and
Alarm Viewer for active alarms contains only active and non-bistate
alarms.
Alarm Table
The Alarm table displays alarms in tabular format. The table displays
alarms against the object selected in the Inventory Tree when Alarm
Viewer is started. The alarms can be filtered using the Filter tool. The
Severity column is color-coded to indicate the severity of alarms.
The Alarm pane displays a single alarm. When an alarm is selected in the
Alarm Viewer table, the Alarm pane displays the alarm details:
1324
TimeStampIs the date and time the alarm was generated on the
router
SeverityIs one of six color-coded levels of severity: Emergency (red),

Alert (purple), Critical (orange), Error (yellow), Warning (blue) or
Notification or Informational (green)
StateIs the state of the alarm: Cleared, None (non-bistate), or Active
Alarm IDIs a cumulative integer assigned to each alarm as it is

generated
SourceIs the source from which the message is emitted in the

format: LR name[rack number, slot number, interface or process ID]
Version 1.0b
Module 13
Alarm Viewer
Toolbar
Alarm table
Alarm pane
Instructor's Note
One slide for these two pages of text!!
Version 1.0b
1325
Module 13
CategoryIs a high-level category, such as communications, QOS,

equipment, or environmental
Correlated IDIs zero (0) if the alarm has not been correlated;
otherwise, it is a numeric ID used to find correlated events in the Event
Correlation log
Event CodeIs the name of the alarm
GroupIs the external event group, such as link or logging
Additional TextIs any other information about the alarm
Toolbar
The Alarm Viewer toolbar contains tool icons that represent common tasks
in the Alarm Viewer window. Click the tool to select the task. When the
pointer is positioned over the tool, a tool-tip appears describing the
function of the tool:
ClearClears the selected active alarms.
PurgeRemoves the selected non-active (cleared and bistate) alarms

from the Alarm table. These alarms are deleted from the table as soon
as the purge is successfully completed.
Correlation RecordsOpens the Correlation Record Viewer from the

Alarm table correlated alarm ID cell.
FilterOpens the Alarm Filter dialog box, which allows you to filter
the records in the Alarm table.
A tool may be enabled or disabled, depending where you are in Alarm

Viewer. A tool appears dimmed (disabled) when it is not available.
1326
Version 1.0b
Module 13
Alarm Viewer (Cont.)
Toolbar
Alarm table
Alarm pane
Version 1.0b
1327
Module 13
Inventory Viewer
The Inventory Viewer application allows you to retrieve object attribute
information, making it available for viewing or export. Inventory Viewer
can be started from the following areas in the CWI Desktop:
Inventory Tree
CWI Desktop menu
CWI toolbar
When no object is selected in the Inventory Tree, the attributes for all
objects are retrieved and displayed in the Inventory table. Multiple objects
can be selected in the Inventory Tree for display in Inventory Viewer. If an
object is selected that does not contain an entity that can be displayed in
Inventory Viewer, an error message is displayed.
The following functions are supported in Inventory Viewer:
Filtering inventory data
Exporting inventory data to a text (comma- or tab-separated) or HTML

file
Printing inventory data
Sorting inventory data
Searching inventory data
Refreshing real-time inventory data
Selecting an entry in the Inventory table displays detailed data as

appropriate:
1328
Node IDIs a drilled-down identification of the object with the

following format: LR.<router name>/Rack.<number>/Slot.<number>
TypeIs the type of object
DescriptionIs a brief description of the object
Vendor TypeIs the vendor type
NameIs the name of the object
Hardware RevisionIs the hardware revision of the object
Software RevisionIs the software revision running on the object
Firmware RevisionIs the firmware revision running on the object
Serial NumberIs the serial number of the object
Manufacturer NameIs the name of the manufacturer
Model NameIs the model name
AliasIs the alias of the object
Asset IDIs the asset ID assigned to the object
FRUSpecifies whether the object is a field-replaceable unit
Version 1.0b
Module 13
Inventory Viewer
Inventory table
Version 1.0b
1329
Module 13
Rack View
The Rack View application displays a graphical representation of the
physical equipment in a Cisco IOS XR router. It allows you to interact with
and obtain information on the physical equipment. Rack View is
dynamically updated, providing an accurate representation of the current
state of a rack.
Rack View can be started from the following areas in the CWI Desktop.
Inventory Tree
CWI Desktop menu
Rack View supports two view modes:
Full ViewIs the default view mode. When Rack View is started, all
corresponding racks are displayed. If there are too many racks to fit in
the Rack View pane, a horizontal scroll bar allows access to the full
view.
Shelf ViewProvides a zoomed-in view of a specific shelf in the Cisco

IOS XR router. This mode provides a complete view of all cards in the
shelf. It is started when you select the Magnify tool and then choose a
rack in the Full View mode.
The Rack View toolbar contains one icon, the Magnify tool, which lets you
open the Shelf View mode for a selected rack. Clicking the tool changes the
pointer to the Magnify tool. When you click on a rack with the Magnify
tool, the Shelf View mode window appears with a larger-scale image of the
selected rack, showing all cards in the shelf. Only one Shelf View mode
window can be open for a rack.
Rack View preferences can be set with the CWI Desktop toolbars
Preferences tool. You can choose to display the front chassis, the back
chassis, or both front and rear chassis.
1330
Version 1.0b
Module 13
Rack View
Version 1.0b
1331
Module 13
Interface Viewer
The Interface Viewer application provides a convenient way to view in a
text-based window the interfaces on selected objects. Interface Viewer can
be started from the following areas in the CWI Desktop:
Inventory Tree
CWI Desktop menu
The following Desktop toolbar functions are supported in Interface

Viewer:
Filtering interface data

Exporting interface data to a text (comma- or tab-separated) or HTML
file
Printing interface data
Sorting interface data
Searching interface data
Refreshing real-time interface data
Selecting an entry in the Interface table displays detailed data:
1332
InterfaceIs the name of the interface
Parent InterfaceIs the name of the parent interface (if any)
Capsulation IDIs the data-link encapsulation active on the

interface
Interface IDIs the ID assigned to the interface
Line StateIs the state of the line
Interface StateIs the state of the interface
MTUIs the size, in bytes, of the largest frame that can be handled by
the interface
Bundle Parent The parent bundle interface, if this interface is part

of a bundle
Version 1.0b
Module 13
Interface Viewer
Interface
table
Version 1.0b
1333
Module 13
Troubleshooter
The Troubleshooter application allows you to run fault-isolation tests on
the communication path between the CWI client and the logical router
(LR) management agent on the router
If a failure is encountered, you can click the Failed button next to the
corresponding test. This action opens a window that describes the reason
for the failure, possible cause, and recommended repair. If CWI is able to
perform an automatic repair, the Repair button is enabled.
The following tests are run:
LR DNS Name TestChecks the Java DNS resolution from the client
(proper DNS name support for the LR). No automatic repair is
provided.
LR and Client Connectivity TestChecks for proper end-to-end

network connectivity between the LR and client. No automatic repair is
provided.
HTTP Server TestChecks whether the HTTP server is running. An

automatic repair is provided in some instances of this test failure.
CORBA Services and XML Agent TestChecks the following:
IP host configuration
CORBA naming service status (running or not running)
XML agent status (running, not running, or jammed)
XML registration with the naming service
An automatic repair is provided in some instances of this test failure.
1334
Notification TestChecks whether the notification service is active

on the router. An automatic repair is provided in some instances of this
test failure.
Version 1.0b
Module 13
Troubleshooter
Version 1.0b
1335
Module 13
Router Configuration
Craft Works Interface (CWI) supports three modes of configuration:
1336
Terminal, Telnet and SSH CLI sessions
Configuration Editor and Replace Configuration Editor
Graphical configuration
Version 1.0b
Module 13
Modes
CLI sessions
Telnet
Terminal
SSH Plus
Editors
Configuration Editor
Replace Configuration Editor
Graphical configuration
Version 1.0b
1337
Module 13
Telnet and SSH Plus

CWI provides Terminal, Telnet and secure shell (SSH) connectivity,
allowing you to manage a Cisco IOS XR router using its CLI without
launching external applications for Terminal, Telnet and SSH. The CWI
applications that provide this connectivity are:
TerminalProvides a terminal emulation protocol-based client integrated
within CWI that allows you to connect to a Cisco IOS XR router, issue CLI
commands, and receive responses without leaving CWI.
SSHv1 PlusProvides the same that Telnet Plus does with the addition
of a secure login session by encrypting the entire session. SSH features
strong cryptographic authentication, strong encryption, and integrity
protection. For Unix users, SSH is a secure replacement for rsh, rlogin,
and rcp. For Windows users, SSH is a replacement for telnet, providing
encryption and better authentication.
SSHv2 PlusProvides the same that SSHv1 Plus does with a higher level
of security.
The Terminal, Telnet and SSH applications can be started from the
following locations in CWI:
Inventory Tree
CWI toolbar
CWI Desktop menu
An LR must be selected in the Inventory Tree for the Telnet or SSH

applications to be available. When the Terminal, Telnet or SSH application
is started, CWI logs in using the user name and password provided during
the CWI login procedure. If that authentication fails, you must manually
enter the user name and password.
1338
Version 1.0b
Module 13
Telnet Plus and SSH Plus
Toolbar
Command
list
Instructor's Note
One slide for 2 test pages!!
Version 1.0b
1339
Module 13
The Terminal, Telnet and SSH Plus application toolbars contain tool icons
that represent common tasks in the Terminal/Telnet/SSH window. When
the pointer is positioned over the tool, a tool-tip appears, describing the
function of the tool. Click the tool to select the task. From left to right,
these tools are:
1340
DisconnectDisconnects the Terminal and Telnet connection and

closes the SSH Plus application.
Launch Text Editor Opens a read-only text editor, displaying the

selected contents of the current Telnet session.
Process Batch Mode CommandsSupports batch mode execution of

CLI commands and logging of the batch operation.
Load Last Command ListLoads a saved list of commands.
Save Last Command ListSaves a list of commands for later use.
Clear Last Command ListClears the command list.
Copy Last CommandCopies the last executed command to the

Clipboard; all commands are not automatically copied to the clipboard.
Command ListDisplays all previously copied Clipboard commands

(up to 50 commands) in a pull-down list. When a command is selected
from the list, the command is pasted into the Terminal/Telnet/SSH
window.
Version 1.0b
Module 13
Telnet and SSH Plus (Cont.)
Toolbar
Command
list
Version 1.0b
1341
Module 13
The Configuration Editor application is available in the Main Menu
Desktop and displays the target configuration (including RPL) in command
line interface (CLI) format. Use this application when you want to edit a
copy of the current configuration or view changes made to the
configuration that have not been committed to the router.
Some special features are:
1342
CLI HelpBy pressing ?, displays a popup list of valid commands and,

by choosing a command from the list, inserts it into the text
Command CompletionBy pressing <Tab> after entering one or

more characters, causes a complete command to appear in text
Cut, Copy and PasteOperates within Configuration Editor and

from external applications like Notepad
Syntax CheckingAllows a selected block of text or the entire

contents of Configuration Editor to be checked for syntax errors
Change TrackingHighlights text in color whenever a command is

deleted (red), modified (blue), not modified (white), or added (green)
Version 1.0b
Module 13
Changed
commands
Added
commands
Deleted
commands
Version 1.0b
1343
Module 13

The Replace Configuration Editor application allows you to replace the
running configuration of a Cisco IOS XR router with the contents of the
Editor window. This editor does not allow modifications to the running
configuration; it deletes the running configuration on the router and
replaces it entirely.
This editor is also in the Configuration Desktop and displays the
configuration in command line interface (CLI) format.
1344
Version 1.0b
Module 13
Version 1.0b
1345
Module 13
Graphical Configuration Applications

Configuration Desktop
The Configuration Desktop window is used to start all graphical
configuration applications and appears when you select Configuration
Desktop from the CWI Desktop menu or toolbar. The graphical
configuration applications let you configure in a faster and more efficient
manner. From the Configuration Desktop window, you can configure the
router using the configuration applications from each of these categories:
AdministrationAAA, Alarm, and User
Applications IEP (IP Explicit Path) and MPLS-TE (Multi-Protocol

Label Switching traffic engineering)
InterfacesCommon, Ethernet, and POS (packet-over-SONET)
ControllersSONET
PolicyAccess Control Lists, Packet Filter, QOS, and Routing Policy
ProtocolsBGP, ISIS, LDP, OSPF, and RSVP
The Configuration Desktop window has three primary panes:
Configuration Applications TreeDisplays all configuration

applications available in the Configuration Desktop.
Configuration ApplicationsContains the active configuration

applications used to configure the router. Multiple applications can be
opened concurrently in the Configuration Applications pane.
Launch ContextDisplays the objects that were selected when the

Configuration Desktop was opened from the CWI Desktop. Only the
objects listed in the Launch Context pane are available for
configuration in the Configuration Desktop.
The Configuration Desktop toolbar contains additional configuration

control tools used to manage the configuration on the Cisco IOS XR router:
1346
Lock/Unlock
Load
Save
View Uncommitted Configuration
Commit
Clear
Rollback
Version 1.0b
Module 13
Configuration Desktop
Toolbar
Configuration
Applications
Tree
Configuration
Applications
Launch
Context
Version 1.0b
1347
Module 13
Graphical Configuration Features

Manageable objects are tabularized to facilitate bulk configuration and
promote fast addition, deletion, and modification:
Configuration cloning uses a selected row to generate multiple new

rows of data with optionally generated key fields
Row Copy and Paste copies the specified attributes of a row to one or
more selected rows
Multi-row editing of an attribute allows editing of an attribute type

across multiple selected rows
Configuration is simplified for large numbers of like objects by partitioning

complex configurations into categorized panels.
The configuration applications provide common user assistance for:
Setting of a selected field or all fields to default values
Undo and redo support
At-a-glance display of required fields and fields set to non-default

values
Attribute value range and default tool-tip
Client-side validation check
Step-through error list
Change of the configuration indicator
Display of changes in CLI format
All data tables provide the following built-in data-browsing features:
1348
Search
Sort
Filter
Column arrangement
Preferences
Drag-and-drop support between the Inventory Tree and applications
Copy and paste of text
Printing and exporting of table data
Manual and automatic refreshing of table data
Version 1.0b
Module 13
Graphical Configuration Features
Version 1.0b
1349
Module 13
Configuration Applications Tree

The Configuration Applications Tree is the primary interface to all CWI
configuration applications. It is used to navigate the configuration
applications and dynamically view the status of the applications. The icon
for each application in the tree indicates the state of the application:
Unchanged configuration (blank page)
Not permitted (red no entry)
Incompatible version (red V)
Uncommitted configuration (paper and pencil)
Disabled (dimmed page)
Right-clicking the configuration applications icon in the Configuration

Applications Tree provides a popup menu, allowing you to view
uncommitted configuration (also known as the target configuration)
settings in a window in CLI format.
Launch Context
The Launch Context pane displays the router objects that were chosen in
the Inventory Tree when the Configuration Desktop was launched from the
CWI Desktop. Only objects listed in the Launch Context pane are available
for configuration.
1350
Version 1.0b
Module 13
Configuration Applications Tree and Launch Context
Configuration
Applications
Tree
Launch
Context
Version 1.0b
1351
Module 13
Configuration Control Toolbar

The configuration control tools are used to manage the configuration on the
Cisco IOS XR router. You can perform the following functions in much the
same way as you would from the CLI:
1352
Lock/UnlockLocks or unlocks the router configuration. If the open

lock icon is displayed, the router is unlocked; if the closed lock icon is
displayed, the router is locked. An unlocked router allows other users to
commit configuration changes to the router. A locked router allows you
to commit your target configuration to the current configuration, but
does not allow other users to commit configuration changes.
LoadOpens the Load dialog box, which allows you to enter the path
and name of a configuration file to load. The file is located on the
router. Loading a configuration overwrites all currently uncommitted
changes and closes all active configuration applications. The loaded
configuration becomes the target configuration.
SaveOpens the Save Uncommitted Configuration dialog box, which

allows you to save an uncommitted configuration to a specified location
on the router.
View Uncommitted ConfigurationDisplays the uncommitted

configuration.
CommitCommits the target configuration to the configuration

currently running on the router. A commit operation is enabled only
after the parameters set in the configuration applications have been
successfully applied. Any errors resulting from a commit operation are
displayed in a read-only text window in CLI format.
ClearStops the current configuration session. The target

configuration is deleted and all active configuration applications are
closed.
RollbackOpens the Rollback dialog box, which contains a list of

available rollback checkpoints saved on the router. A checkpoint is a
previous commit operation. You can choose the checkpoint to which to
roll back the current configuration. The checkpoints provide the user
name, date, and time of the commit operation.
Version 1.0b
Module 13
Configuration Control Toolbar
Lock/Unlock
View
uncommited
configuration
Load Save
Version 1.0b
Commit
Clear
Rollback
1353
Module 13
Common Elements and Activities

Some activities (functionality) are common to the CWI and Configuration
Desktop; others are common across all Configuration Desktop applications.
This commonality exists so that you can more easily perform certain tasks
in whatever application is running. These activities are as follows:
Sorting columnsColumns in an application table are sorted in

ascending or descending order.
Moving columnsCWI application table columns are moved by

dragging the column heading to the desired location. As the column is
dragged horizontally, the surrounding columns dynamically rearrange
themselves around the column that is being moved. The final
arrangement can be saved using the Preferences tool.
Filtering and removing filters for recordsTo filter data, an

application must be open in the CWI Application pane. The application
must also contain a table with data for the Filter Table tool to be
enabled and that data must be displayed. You have the option to
remove record filtering. After record filtering is removed, the table is
automatically updated to display all records.
Finding textAs with the Filter Table tool, an application must be

open in the CWI Application pane, and the application must contain a
table with data for the Find tool to be enabled. You can use the Find
tool to continue searching through the CWI Application table for each
instance of text that matches all search criteria.
Exporting table dataInventory data and alarm data can be

exported to a file in comma-separated values, tab-separated values, or
HTML format.
The Configuration Desktop is designed with common features in all

configuration applications that provide an easy to use and consistent user
interface. The Application window contains all components of the chosen
configuration application. The Application window is used to configure a
specific component of the Cisco IOS XR router.
1354
Version 1.0b
Module 13
Common Elements and Activities
Clone special
Add record
Row Paste
Set defaults
Filter Table
Undo
Common
Common
Configuration
configuration
tools
tools
Clone record
Row copy
Delete record
Redo
Row Paste Special
Print
Find
Cut
Paste
Preferences
Common
application
tools
Export
Version 1.0b
Find next
Copy
Refresh
Help
1355
Module 13
Administration Configuration
The Administration Configuration applications are used to manage user
access, permissions, and alarms. The applications are:
1356
AAAAllows you to configure and set up system security. All triple A

functions can be set up from the AAA application.
Alarm AdministrationAllows you to configure alarm and

correlation rule parameters. Alarm settings can be adjusted to respond
to changes in user activities, network events, or system configurations
that affect network performance or network monitoring requirements.
The appropriate alarm settings depend on the configuration and
requirements of the system.
User AdministrationAllows you to configure groups of users and

the job characteristics that are common in groups of users. All groups
must be explicitly assigned to users. Users are not assigned to groups
by default. A user can be assigned to more than one group. Each user
group defines a collection of users who share a common set of
attributes, such as access privileges.
Version 1.0b
Module 13
Administration Configuration
Version 1.0b
1357
Module 13
Applications Configuration
The Applications Configuration applications allow you to configure and set
up protocol-specific applications. The two applications that can be
configured are:
1358
IEPAllows you to create and configure an IP Explicit Path (IEP). An

IEP is a list of IP addresses, each representing a node or link in the
explicit path.
MPLS-TEAllows you to configure Multi-Protocol Label Switching

traffic engineering (MPLS-TE) on the Cisco IOS XR router. MPLS-TE
automatically establishes and maintains label-switched paths. Traffic
engineering is used both for adjusting bandwidth allocation across the
network when used with RSVP and for providing back-up paths in the
event of a network path failure.
Version 1.0b
Module 13
Applications Configuration
Version 1.0b
1359
Module 13
Interface Configuration
The Interface Configuration applications are used to display, configure,
and manage Ethernet and packet-over-SONET (POS) interfaces. The
applications are:
1360
Common AttributesAllows you to configure interface attributes

that are common across all interfaces, including Ethernet and POS.
Common Attributes prevents the need to enter the same data
numerous times across various interfaces. When an attribute is
configured in the Ethernet or POS application, changes can be
displayed and edited in the Interface Common Attributes Configuration
application.
EthernetAllows you to configure interface attributes that are

specific to Ethernet interfaces. With the exception of the attributes in
the Ethernet tab, when an attribute is configured in the Interface
Ethernet Configuration application, changes can be displayed and
edited in the Common Attributes application.
POSAllows you to configure interface attributes that are specific to

POS interfaces. With the exception of the attributes in the POS tab,
when an attribute is configured in the Interface POS Configuration
application, changes can be displayed and edited in the Common
Attributes application.
Version 1.0b
Module 13
Interface Configuration
Version 1.0b
1361
Module 13
Policy Configuration
The Policy Configuration applications are used to display, configure, and
manage policies used for access control, packet filtering, Quality of Service
(QoS), and routing control. The applications are:
Access Control Lists (ACL)Restricts or polices traffic entering or

leaving a specified interface. ACLs are also used to implement what if
logic on a Cisco router and gives you the only real mechanism for
programming the forwarding of packets in a Cisco router. The ACLs
used for IP in this way enable you to apply great subtlety to the router
configuration.
Packet FilterIs associated with an ACL on a specific interface for

restricting particular types of packets based on fields in the packet
structure. The ACL can be configured for inbound or outbound traffic.
QoSDefines the ability of a network to provide different levels of

service assurances to the various forms of traffic. It enables network
administrators to assign certain traffic priority over other traffic or
actual levels of quality with respect to network bandwidth or end-toend delay.
Routing Policy ManagerAllows you to configure policy-related

information that includes prefix lists, standard and expanded
community lists, and AS-path access lists. In Cisco IOS, routing policies
are primarily defined by route maps in conjunction with these types of
lists. In Cisco IOS-XR, these lists are still supported for some use but
Routing Policy Language (RPL)-based policies are designed to replace
route maps and reduce some of the redundancy that is inherent in
route map configuration.
__________________________ Note _________________________
RPL is not supported by the Routing Policy Manager because, as a
programmatic language, it is not well-suited to be configured by a
graphical application. Use the Configuration Editor or Telnet/SSH
Plus applications to configure RPL-based policies from CWI.
______________________________________________________________
1362
Version 1.0b
Module 13
Policy Configuration
Version 1.0b
1363
Module 13
Protocol Configuration
The Protocol Configuration applications are used to manage, create,
display, and edit protocol data and settings on the Cisco IOS XR router.
Configuration of these protocols is a complex and time-consuming function,
with multiple fields and information that need to be considered and
configured. The applications let you display, edit, and configure:
1364
BGP Border Gateway Protocol (BGP) neighbor, session, and address

family (topology) parameters
ISISIntermediate System-to-Intermediate System (IS-IS) routing

protocol on process, address family (topology), and interface levels
LDPLabel Distribution Protocol (LDP) globally and enable or disable

LDP for each interface or neighbor.
OSPFOpen Shortest Path First (OSPF) processes, areas, and

interfaces.
RSVPResource Reservation Protocol (RSVP) configurations for

available interfaces.
Version 1.0b
Module 13
Protocol Configuration
Version 1.0b
1365
Module 13
Getting Started
CWI Router Configuration
To a Cisco IOS XR router to be managed by CWI over a network
connection, several steps must be followed. In addition to the configuration
steps listed below, make sure, if you are enabling support for CWI to a
new router, that it has a route (default or other) back to the CWI client
PC or workstation.
Step 1 Enter the configuration mode:
RP/0/0/CPU0:router# config
Step 2 Enable the HTTP server on the router:

RP/0/0/CPU0:router(config)# http server
Step 3 Enable the XML agent on the router:

RP/0/0/CPU0:router(config)# xml agent corba
_____________________________ Note _________________________

The optional ssl keyword can to be added to the end of the http server
and xml agent corba commands to enable the Secure HTTP (HTTPS)
server and CORBA agent operation. Before enabling secure operation,
the Certificate Authority (CA) and router certificates must be set up.
During CWI login, the SSL certificates must be accepted.
_________________________________________________________________
Step 4 Commit the target configuration:
RP/0/0/CPU0:router(config)# commit
Step 5 When the router prompts you to commit, respond with yes.
1366
Version 1.0b
Module 13
Getting Started
CWI Router Configuration
Enter router configuration mode

RP/0/0/CPU0:router#config
Enable the HTTP server

RP/0/0/CPU0:router(config)#http server
Enable the XML agent

RP/0/0/CPU0:router(config)#xml agent corba
Commit the target configuration

RP/0/0/CPU0:router(config)#commit
Instructor's Note
Firewall port configuration to support CWI:
HTTP/HTTPS
IIOP/IIOPSSL
Notifications
Telnet/SSH
80/443
10001/10002
49901 to 49950
23/22
Inbound
Inbound
Outbound
Inbound
Version 1.0b
1367
Module 13
Launching CWI
Use the following procedure to start CWI on the client PC or workstation
and login to the CRS-1 router. Some steps are necessary only if SSL is
configured on the routers HTTP server and XML agent.
Step 1 Start a supported web browser.
Step 2 In the Address field located near the top of the web browser
window, enter the DNS name or IP address of the router to be accessed:
http://router-dns-name/
or
http://router-ip-address/
or if SSL is configured for the HTTP server on the router:
https://router-dns-name/
or
http:// router-ip-address/
Step 3 If SSL is configured for the HTTP server, accept the router SSL
certificate. Click Yes to trust and accept the SSL certificate for this router
session only, or click Always to automatically trust and accept the SSL
certificate in this session and all subsequent CWI sessions.
Step 4 If an HTTP authentication dialog box appears (HTTP
authentication is enabled), enter an AAA user name and password.
Step 5 Click the Craft Works Interface link in the web browser.
Step 6 If an HTTP authentication dialog box appears (HTTP
authentication is enabled), enter an AAA username and password.
Step 7 If this is the first time the CWI client has started CWI, the Java
plug-in must be installed and the CWI Cisco security certificate must be
accepted. Click Yes to trust and accept the security certificate for this
router session only, or click Always to automatically trust and accept the
security certificate in this session and all subsequent CWI sessions.
Step 8 If SSL is configured for the XML agent, the router SSL certificate
must be accepted.
If this is the first time you have started CWI or installed a new version of
CWI, the CWI components start downloading. Otherwise, a cached version
of the CWI components is used, reducing the CWI start time.
Step 9 Log in to the Cisco IOS XR router when the CWI Login dialog box
appears.
1368
Version 1.0b
Module 13
Getting Started
Launching CWI
http://<router-dns-name>
or
http://<router-ip-address>
Version 1.0b
1369
Module 13
Loading CWI Components

After the router hostname or address has been entered into the browser
interface and HTTP communication has been established, the CWI
launcher downloads all components in Java archive (Jar) file format, which
is locally cached to speed the subsequent launches of CWI. The window on
the facing page appears while the Jar files are being downloaded from the
router.
1370
Version 1.0b
Module 13
Getting Started
Loading CWI Components
Version 1.0b
1371
Module 13
Checking the Java Runtime Environment

CWI checks for the Java Runtime Environment (JRE) version that runs on
the desktop client from where it is invoked. If the runtime version is lower
than Version 1.4.2, CWI recommends downloading of the environment
from the Sun website and then installs the JRE. Make sure that Java
Version 1.4.2 is used to ensure proper operation.
We recommend following the onscreen messages that appear during the
installation of the JRE. This step is skipped if the desktop client already
has JRE 1.4 or higher.
1372
Version 1.0b
Module 13
Getting Started
Checking the Java Runtime Environment
Version 1.0b
1373
Module 13
Testing Communication
If a problem is encountered during login, you can troubleshoot the problem
using the CWI Troubleshooter.
1374
Version 1.0b
Module 13
Getting Started
Testing Communications
Version 1.0b
1375
Module 13
Logging In
Depending on the authentication security options configured on the router,
you may have had to enter a valid username and password several times.
CWI can communicate with the router using the following methods:
1376
CLI / Serial, Terminal Server
CLI / Telnet, SSHv1, SSHv2
XML / Telnet, SSHv1, SSHv2, CORBA, CORBA SSL
Version 1.0b
Module 13
Getting Started
Logging In
Version 1.0b
1377
Module 13
Summary
Craft Works Interface
1378
Start CWI and log in
Describe the basic operation of CWI
Navigate the CWI Desktop
Use CWI Desktop applications
Configure the router using Configuration Editor
Configure the router using graphical configuration applications
Version 1.0b
Module 13
Review Questions
Craft Works Interface
Version 1.0b
1379
Module 13

1380
Version 1.0b
Module 14
Data Flow and MQC QoS
Overview
Description
This module provides a high-level overview of data flow through the CRS-1
Routing System. The components comprising the MSC are reviewed
followed by a detailed explanation of the data flow through the MSC/PLIM
pair. Switch Fabric Cell structure is described along with worst case cell
loading. Switch Fabric Architecture and Switch Fabric features are
presented, followed by a brief description of using MQC CLI to create Mapclasses, Map-polices and attaching a service policy to an interface.
Objectives
Describe the major features and functions of the MSC
Describe how data flows from ingress interfaces through the switch
fabric and out through the egress interface
Describe the IngressQ ASIC and EgressQ ASIC queuing and shaping
features
Describe the Switch Fabric Cell structure
Describe the major features of the Cisco CRS-1 switch fabric
Use MQC to create class-maps and policy-maps and attach servicepolices to an interface
Version 2.0b
141
Module 14
CRS-1 QoS Hardware Components

Introduction
The Modular Services Card (also known as a linecard) used in the CRS-1
system provides hardware-based QoS packet-processing functionality. In
addition, the Switch Fabric used to transfer data between MSCs is
composed of hardware elements that are QoS-aware. Although QoS
configuration is entered on the Route Processor, the Route Processor is not
involved in the application of the QoS features to the traffic stream
The various components that form the MSC:
Physical Layer Interface Module (PLIM)

This is a physically separated module which provides the optical interfaces
and framing hardware functions. A PLIM will have one or more PLA
ASICs (depending on the PLIM type) which are used to send and receive
Layer 3 packets to and from the MSC. A PLIM is partnered to an MSC in a
1:1 relationship. NOTE the PLIM is not technically part of the MSC but
for an MSC to operate, a PLIM is mandatory. PLIM cards are inserted in
the front of the CRS-1 chassis whereas MSCs are installed in the rear.
Packet Switching Engine (PSE)

The Packet Switching Engine (PSE) resides on the MSC and is the primary
L3 feature processing ASIC. The PSE applies features such as ACL
checking, uRPF, BGP-PA as well as QOS functions such as policing &
WRED to the traffic stream. There is one PSE in the RX path and another
in the TX path.
IngressQ/EgressQ
IngressQ is the RX queuing ASIC, EgressQ is the TX queuing ASIC and
both reside on the MSC. Each of these ASICs implements features such as
P2MDRR, low-latency queuing and shaping support. In addition, the
IngressQ contains fabric queues and the packet to fabric cell conversion
functionality.
FabricQ
The MSC contains two FabricQ ASICs in the transmit path from the fabric
towards the PLIM. The FabricQ reassembles the fabric cells and converts
these back to packets. Although each ASIC contains queuing functionality
and provide low-latency and precedence-based queuing, these queues are
not directly configurable.
142
Version 2.0b
Module 14
EgressQ
2*FabricQ
SP & FIA
Ingress
PSE
Version 2.0b
Power
Regulators
Egress
PSE
Line Card
CPU
IngressQ
143
Module 14
Life of a Packet
Overview
QoS in the CRS-1 is distributed in many locations and is performed end-toend. This means that not only is QoS present in the MSC, but also in the
fabric. As a result, the CRS-1 is able to differentiate traffic types end-toend without dropping packets.
1. A packet that is forwarded by the CRS-1 takes the following path
through the system:
a. The framer on the PLIM receives a frame carrying the IP packet.
The Framer ASCIs perform the appropriate SONET/SDH/Ethernet
deframing/decapsulation and removes the CRC.
144
Version 2.0b
Module 14
Life of a Packet
Life of a Packet Step 1
To Fabric
Ingress Packet Flow

IngressQ
In Q/
Segmenter
CPUCTRL
GW
Fabric
RX PSE
L3 Engine
From
PLIM
CPU
To
PLIM
FabricQ
FabricQ
Reass.
Reass.
TX PSE
L3 Engine
EgressQ
Out Q
M
I
D
P
L
A
N
E
OC192
Framer
& Optics
1
OC192
Framer
& Optics
PLA
OC192
Framer
& Optics
Fabric
OC192
Framer
& Optics
From
Egress Packet Flow Fabric
Version 2.0b
145
Module 14
2. An internal buffer header is added that accompanies the packet

throughout the router. The buffer header carries additional information
that is not available from the packet itself, such as:
a. The ingress physical and logical port
b. Frame type
c. Packet type
d. The interface on which this packet was received
146
Version 2.0b
Module 14
Life of a Packet
To Fabric
Ingress Packet Flow

IngressQ
In Q/
Segmenter
CPUCTRL
GW
Fabric
RX PSE
L3 Engine
From
PLIM
CPU
To
PLIM
FabricQ
FabricQ
Reass.
Reass.
TX PSE
L3 Engine
EgressQ
Out Q
M
I
D
P
L
A
N
E
OC192
Framer
& Optics
2
OC192
Framer
& Optics
PLA
OC192
Framer
& Optics
Fabric
OC192
Framer
& Optics
From
Version 2.0b
147
Module 14
3. The packet, together with the buffer header information from the PLA
is extracted and is passed to the RX PSE.
a. The RX PSE performs the destination lookup and ingress feature
processing such as:
Access-lists
QoS classification
Policing (rate limiting)
WRED per queue
Policy routing
b. The result of the destination lookup will be all the information that
is needed to send the packet to the destination slot and port. The
information includes:
The destination MSC
Which FabricQ ASIC on the destination MSC is to be used
Which queue within the FabricQ (Hi or Low) ASIC the packet is
going to be queued in
Information about QoS queues to use when transmitting across

the switch fabric. This information is stored within a portion of
data known as the Buffer Header Descriptor (BHDR) which is
appended to the front of the packet. The BHDR is applied by the
RX PSE and removed by the TX PSE.
The mapping of ports to queues is reflected from the IngressQ into the
RX PSE where WRED is performed per queue. The RX PSE classifies
the packet and performs rate limiting and WRED prior to sending it
into the IngressQ ASIC.
148
Version 2.0b
Module 14
Life of a Packet
To Fabric
Ingress Packet Flow

Fabric
IngressQ
In Q/
Segmenter
RX PSE
L3 Engine
CPUCTRL
GW
From
PLIM
CPU
To
PLIM
FabricQ
FabricQ
Reass.
Reass.
TX PSE
L3 Engine
EgressQ
Out Q
M
I
D
P
L
A
N
E
OC192
Framer
& Optics
2
OC192
Framer
& Optics
PLA
OC192
Framer
& Optics
Fabric
OC192
Framer
& Optics
From
To Fabric
Ingress Packet Flow

IngressQ
In Q/
Segmenter
CPUCTRL
GW
Fabric
3a
RX PSE
L3 Engine
From
PLIM
CPU
To
PLIM
FabricQ
FabricQ
Reass.
Reass.
TX PSE
L3 Engine
EgressQ
Out Q
M
I
D
P
L
A
N
E
OC192
Framer
& Optics
2
OC192
Framer
& Optics
PLA
OC192
Framer
& Optics
Fabric
OC192
Framer
& Optics
From
Version 2.0b
149
Module 14
4. The packet is passed to the IngressQ ASIC. The IngressQ ASIC

performs shaping and packet-to-packet modified deficit round robin
(P2MDRR) on the packet as well as the segmentation of the packet into
cells for transmission across the switch fabric.
a. The IngressQ ASIC has 2 sets of queues known as shape queues
and fabric queues. There are 8192 shape queues. These queues can
be shaped individually or multiple queues can be allocated into
logical ports. Shaping is only applied if configured. If not configured,
the shape queues operate in a FIFO manner.
b. Once the packet is processed, it is sent to a second set of queues
known as the fabric queues. The fabric queues are organized such
that there is a Hi priority and a Lo priority queue for every possible
destination FabricQ ASIC that could be present in a full-scaled
system. As noted previously, there are two FabricQs per MSC and
route processor. Additionally there is one Hi priority and one Lo
priority multicast queue. Only 1 multicast queue is required since
multicast replication is performed within the switch fabric rather
than on the ingress MSC.
c. Packets leaving the fabric queues are segmented into cells. Each
cell is 136 bytes, of which 120 bytes contain data. The remaining
portion contains cell header information which is used by the
switching fabric. Once packets are segmented, the IngressQ sends
cells in a round-robin fashion across the links to the fabric planes.
d. Depending on the state of the fabric and the egress MSC, the packet
may be dropped in the IngressQ. If congestion is occurring in the
fabric or on the egress MSC interface/sub-interface, back-pressure
can be applied to the IngressQ to slow the flow of packets to the
destination interface and its associated FabricQ ASIC.
1410
Version 2.0b
Module 14
Life of a Packet
IngressQ
PSE
8192 Queues
WRED
1K Ports (Port/VLAN)
HP
LP
MDRR/
Shaper
P1
LP
From
RX
PSE
MDRR/
Shaper
MDRR/
Shaper
Shaping
Min/max BW
4a
Fabric
Cells
IngressQ
In Q/
Segmenter
CPUCTRL
GW
To
fabric
P1023
Configurable
Dynamic
Mapping of
Queues to ports
Max BW
To Fabric
Ingress Packet Flow

Fabric
3a
RX PSE
L3 Engine
From
PLIM
CPU
To
PLIM
FabricQ
FabricQ
Reass.
Reass.
P2
MDRR/
Aggregate
Shaper
TX PSE
L3 Engine
EgressQ
Out Q
M
I
D
P
L
A
N
E
OC192
Framer
& Optics
2
OC192
Framer
& Optics
PLA
OC192
Framer
& Optics
Fabric
OC192
Framer
& Optics
From
Version 2.0b
1411
Module 14
5. Cells are sent into the fabric. The cells arrive at the stage 1 (S1) of the
switch fabric. The S1 simply distributes the incoming cells across the
available S2 stages within the plane. The S1 can avoid an S2 stage for
which it has received an out-of-resources message and select an
alternative S2 path.
1412
Version 2.0b
Module 14
Life of a Packet
4a
Fabric
Cells
IngressQ
In Q/
Segmenter
To Fabric
Ingress Packet Flow
Fabric
Cells
Fabric
3a
CPUCTRL
GW
RX PSE
L3 Engine
From
PLIM
CPU
To
PLIM
FabricQ
FabricQ
Reass.
Reass.
TX PSE
L3 Engine
EgressQ
Out Q
M
I
D
P
L
A
N
E
OC192
Framer
& Optics
2
OC192
Framer
& Optics
PLA
OC192
Framer
& Optics
Fabric
OC192
Framer
& Optics
From
Version 2.0b
1413
Module 14
a. The S2 stage performs a lookup on the cell header to determine

which S3 ASIC within the plane the cell is to be sent to. The S2
stage supports Hi and Lo priority Queues for both Unicast and
Multicast traffic. Queues will only form if the upstream S3 ASICs
were to indicate that they were congested.
b. The S3 stage receives the cell and using the cell header, determines
which FabricQ ASIC the cell is to be sent to. The S3 stage also
supports Hi and Lo priority Queues, for both Unicast and Multicast
traffic.
1414
Version 2.0b
Module 14
Life of a Packet
Life of a Packet Step 5a
136 Bytes cells
MSC
2 Levels of priority
HP Low latency path
LP Best effort traffic
8 of 8
2 of 8
S1
1 of 8
S1
S1
S2
S2
S2
S1
16
MSC
S1
S1
S3
S3
S3
S2
S2
S2
S3
S3
S3
Multicast support
1M multicast
groups
Multi-stage Interconnect 3 Stage Benes

topology - buffered non-blocking switch
H -Unicast
H -Unicast
H -Unicast
H -Unicast
H -Multicast
H -Multicast
H -Multicast
H -Multicast
H -Unicast
H -Unicast
H -Multicast
H -Multicast
S1
RR
S2
S3
S2
H -Unicast
H -Unicast
H -Multicast
H -Multicast
H -Unicast
H -Unicast
H -Unicast
H -Unicast
H -Unicast
HH-Multicast
-Multicast
H -Unicast
H -Multicast
H -Multicast
S1
S2
H -Unicast
H -Multicast
H -Multicast
H -Multicast
S3
S2
H -Unicast
Hi Priority Cells
Lo Priority Cells
RR
H -Unicast
H -Unicast
H -Unicast
H -Unicast
H -Multicast
H -Multicast
H -Multicast
H -Multicast
H -Multicast
Version 2.0b
H -Unicast
H -Unicast
HH-Unicast
-Unicast
H -Multicast
H -Multicast
HH-Multicast
-Multicast
1415
Module 14
6. The cells arrive from the fabric onto one of the two FabricQ ASICs. All
the cells from a single packet are received by the same FabricQ ASIC.
The selection of the FabricQ ASIC is based on the destination port/subinterface towards which the packets are sent. The cells carry cell
sequence numbers to guarantee correct reassembly. Packets also have a
packet sequence number that is used to ensure the correct packet
order. After a packet has been reassembled and is in the right packet
order, it is sent to one of the FabricQ raw queues.
a. Each FabricQ ASIC supports a total of 4096 raw queues. The raw
queues are not user configurable. Four queues are assigned for
every physical or logical interface configured on the egress MSC:
One queue is assigned for high priority traffic
One for low priority
One for internal control traffic
The fourth queue is reserved for later use
b. The packet will be place into the appropriate queue based upon the
information contained in the buffer header assigned to the packet.
The packet is passed to the TX PSE.
1416
Version 2.0b
Module 14
Life of a Packet
4a
Fabric
Cells
IngressQ
In Q/
Segmenter
To Fabric
Ingress Packet Flow
Fabric
Cells
Fabric
3a
CPUCTRL
GW
RX PSE
L3 Engine
From
PLIM
CPU
To
PLIM
FabricQ
FabricQ
Reass.
Reass.
TX PSE
L3 Engine
EgressQ
Out Q
M
I
D
P
L
A
N
E
From
Fabric
2
OC192
Framer
& Optics
PLA
OC192
Framer
& Optics
Fabric
Fabric
Cells
OC192
Framer
& Optics
OC192
Framer
& Optics
Egress Packet Flow
Version 2.0b
1417
Module 14
7. The buffer header descriptor and the packet itself are now processed
by the TX PSE. The TX PSE performs full layer 3 processing including:
a. Destination address lookup (route lookup)
b. Applies the appropriate egress features to the packet such as:
Access-list processing
QoS classification
WRED
c. If the packet is not dropped as a result of the applied functions,

then the appropriate L2 encapsulation rewrite string is applied
before the TX PSE hands the updated packet the EgressQ ASIC.
1418
Version 2.0b
Module 14
Life of a Packet
4a
Fabric
Cells
IngressQ
In Q/
Segmenter
To Fabric
Ingress Packet Flow
Fabric
Cells
Fabric
3a
CPUCTRL
GW
RX PSE
L3 Engine
CPU
From
PLIM
To
PLIM
FabricQ
FabricQ
Reass.
Reass.
TX PSE
L3 Engine
EgressQ
Out Q
M
I
D
P
L
A
N
E
From
Fabric
2
OC192
Framer
& Optics
PLA
OC192
Framer
& Optics
Fabric
Fabric
Cells
OC192
Framer
& Optics
OC192
Framer
& Optics
Egress Packet Flow
Version 2.0b
1419
Module 14
8. The packet is now passed to the EgressQ ASIC which places the packet
in the appropriate queue before shaping and packet-to-packet modified
deficit round robin are applied.
The EgressQ supports a total of 8192 shape queues which are user
configurable. These queues are can be mapped into 2048 groups and in
turn mapped into 768 physical or logical ports.
1420
Version 2.0b
Module 14
Life of a Packet
Fabric
Cells
4a
IngressQ
In Q/
Segmenter
To Fabric
Fabric
Cells
Ingress Packet Flow
Fabric
3a
RX PSE
L3 Engine
CPUCTRL
GW
From
PLIM
CPU
To
PLIM
FabricQ
FabricQ
Reass.
Reass.
TX PSE
L3 Engine
EgressQ
Out Q
M
I
D
P
L
A
N
E
Fabric
Cells
From
Fabric
OC192
Framer
& Optics
PLA
OC192
Framer
& Optics
OC192
Framer
& Optics
Egress Packet Flow
2K Groups
8192 Queues
WRED
Fabric
OC192
Framer
& Optics
HP
LP
768 Ports (Port/VLAN)
(VLAN/Tunnel)
MDRR/
Shaper
G1
LP
from
TX
PSE
P1
MDRR/
Group
MDRR/
Shaper
MDRR/
Shaper
Configurable Dynamic
Mapping of
Queues to groups and ports
Shaping
Min/max BW
G2
MDRR/
Aggregate
Group
To
PLIM
GX
MDRR/ PX
Group
Max BW
9.
Version 2.0b
1421
Module 14
Once the packet has been queued and shaped it is then passed to the
PLA ASIC on the PLIM.
1422
Version 2.0b
Module 14
Life of a Packet
4a
Fabric
Cells
IngressQ
In Q/
Segmenter
To Fabric
Ingress Packet Flow
Fabric
Cells
Fabric
3a
CPUCTRL
GW
RX PSE
L3 Engine
From
PLIM
CPU
To
PLIM
FabricQ
FabricQ
Reass.
Reass.
TX PSE
L3 Engine
EgressQ
Out Q
M
I
D
P
L
A
N
E
From
Fabric
2
OC192
Framer
& Optics
PLA
OC192
Framer
& Optics
9
Fabric
Fabric
Cells
OC192
Framer
& Optics
OC192
Framer
& Optics
Egress Packet Flow
Version 2.0b
1423
Module 14
10. Finally the packet is sent through the egress port, and onto the
physical link.
1424
Version 2.0b
Module 14
Life of a Packet
4a
Fabric
Cells
IngressQ
In Q/
Segmenter
To Fabric
Ingress Packet Flow
Fabric
Cells
Fabric
3a
CPUCTRL
GW
RX PSE
L3 Engine
From
PLIM
CPU
To
PLIM
FabricQ
FabricQ
Reass.
Reass.
TX PSE
L3 Engine
EgressQ
Out Q
M
I
D
P
L
A
N
E
From
Fabric
2
OC192
Framer
& Optics
PLA
OC192
Framer
& Optics
10
9
Fabric
Fabric
Cells
OC192
Framer
& Optics
OC192
Framer
& Optics
Egress Packet Flow
Version 2.0b
1425
Module 14
IngressQ queuing and shaping

Features
1426
The IngressQ has 8192 queues, 8 of which are allocated data to the
MSC CPU queues.
The mapping of ports to queues is reflected back into the RX PSE

where WRED is performed per queue. Hence each packet that is
arriving on the IngressQ has already been congestion controlled.
Queues are allocated dynamically to ports. These ports can represent

physical ports or sub-interfaces.
A maximum of 4000 queues can be mapped to one port.
Only one High priority queue can be configured per port.
Shaping is supported via a standard token bucket mechanism and can

be done on a per port basis
De-queuing is via the P2MDRR algorithm. This is packet-by-packet

MDRR.
Version 2.0b
Module 14
IngressQ queuing and shaping
IngressQ queuing and shaping - Features
IngressQ
PSE
8192 Queues
WRED
HP
LP
1K Ports (Port/VLAN)
MDRR/
Shaper
P1
LP
From
RX
PSE
MDRR/
Shaper
MDRR/
Shaper
Shaping
Min/max BW
P2
To
fabric
P1023
Max BW
Version 2.0b
MDRR/
Aggregate
Shaper
Configurable
Dynamic
Mapping of
Queues to ports
1427
Module 14
EgressQ queuing and shaping

Features
Packets are passed into the EgressQ from the TX PSE
1428
8 of the 8192 queues are reserved for data being passed to the MSC
CPU
The mapping of ports to queues is reflected back into the TX PSE where
WRED is performed per queue
Hence each packet that is arriving has already been congestion

controlled
TX PSE classifies the packet and performs rate limiting and WRED
prior to sending it into the shaping queue.
Shaping is supported on either:
A per queue basis
Per group
Or on a per port basis
Queues are allocated dynamically to ports (and/or groups)
A maximum of 4000 queues can be allocated to a group
A maximum of 4000 queues can be allocated to a port
Only one High priority queue can be configured per group/port
Shaping is supported via a standard token bucket mechanism and can

be done on a per queue basis or a per port basis
Queues are selected for de-queuing via the P2MDRR algorithm
Version 2.0b
Module 14
EgressQ queuing and shaping
EgressQ queuing and shaping -Features
2K Groups
8192 Queues
WRED
HP
LP
768 Ports (Port/VLAN)
(VLAN/Tunnel)
MDRR/
Shaper
G1
LP
from
TX
PSE
P1
MDRR/
Group
MDRR/
Shaper
MDRR/
Shaper
Configurable Dynamic
Mapping of
Queues to groups and ports
Shaping
Min/max BW
G2
MDRR/
Aggregate
Group
To
PLIM
GX
MDRR/ PX
Group
Max BW
Version 2.0b
1429
Module 14
Switch Fabric Cell Structure

Overview
Each cell consists of a 12-byte header, a 120-byte payload and a 4 byte FEC
for a total of 136 bytes per cell. The header contains information necessary
for the processing of packets as well as control and status information for
the fabric and MSCs. The FEC field covers both the header and payload for
bit error correction and error detection. The cell payload is divided into 30byte units consistent with an FCRAM memory read or write unit (data will
be written into FCRAM in 32 byte bursts with 2 bytes of ECC per burst).
Cell Header Elements

Cast - This bit indicates that the cells Destination Address field should be
interpreted as either a multicast or unicast destination address.
Fabric Priority - This bit specifies the priority of unicast and multicast
traffic in the fabric, one indicates high priority
Vital - This bit is ignored by the switch fabric but has meaning to the
reassembly FabricQ (Sponge) ASIC. It is used to mark a packet as a vital
control packet that will not be dropped due to an out of resource condition.
Source Address - This 10-bit field encodes the source address of the cell.
Up 1024 sources are supported.
Packet 1 Sequence Number - The reassembly engine supports up to 8K
outstanding packets per source. This 13 bit field uniquely identifies
packets transmitted from each source to each destination. The packet
sequence numbers are contiguous and monotonically increasing and wrap
after reaching maximum value. For two packet payloads, the packet
sequence number of the second packet is assumed to be Packet Sequence
Number + 1.
Packet 2 Payload Offset/FGID - This 2-bit field specifies the initial
offset of the second packet in a cell. The offset specifies the 30-byte
boundary on which Packet 2 starts. When zero, this field indicates that the
current cell has a single packet payload. When equal to one through three,
this field indicates that the cell has a two packet payload. A value of one
through three also indicates that the Packet Cell Count specifies the total
cell count of the second packet in the payload.
Trailing Offset - This 2-bit field specifies where the unused portion of the
cell starts if any. The offset specifies the 30-byte boundary on which white
space starts. When zero it indicates that the cell has no unused portion.
1430
Version 2.0b
Module 14
Header
FEC
Cell Payload (120 bytes)
Two Packet Payload

Packet 1
Header (12 bytes)
Fields (Data Cells)
Bits
Cast (Mcast/Ucast)
Fabric Priority
Vital
Source Address
10
Packet 1 Sequence Number
13
Packet 2 Payload Offset/FGID
Trailing Offest
Packet Cell Count
Packet 1 Cell Sequence Number
Destination Address (12 bits)/FGID
18
Snoop/CTB
Internal Fabric control bits
32
Packet 2
Packet 1
Packet 2
Packet 2
Packet 1
30
bytes
30
bytes
30
bytes
30
bytes
Single Packet Payload

Packet 1 (120 bytes)
Version 2.0b
1431
Module 14
Packet Cell Count - This field specifies the total number of cells in either
the first or second packet in the cell. When there is only one packet in the
current payload, this field specifies the total cell count for the current
packet. When two packets are in the current payload, this field indicates
the total cell count of Packet 2.
Packet 1 Cell Sequence Number - This field specifies the cell sequence
number for Packet 1 and is used for cell reassembly to reorder cells
arriving across the fabric. The cell sequence number should be contiguous
and monotonically increasing starting with 0 for the first cell in a packet.
(Note: Since the cell payload is 120 bytes, the fabric supports payloads of
up to 15,360 bytes, although the official maximum MTU supported by the
system is 9k bytes). When two packets are in the current payload
(indicated by the Packet 2 Payload Offset being non-zero) the cell sequence
number for packet 2 is zero since it is by definition the first cell in packet 2.
Destination Address (12 bits)/FGID- When the cast bit marks the cell
as a multicast cell, this 18-bit field is concatenated with the 2 bit payload
offset field in the MSC / link portion of the cell header to produce a 20 bit
Fabric Group ID. The FGID is used to determine how the Multicast Data
Cell should be duplicated and forwarded to within the Fabric. When the
cast bit marks the cell as a UC cell, the least significant 12 bits specify a
destination address (the address space has been changed from previous
revisions to a contiguous address space). Note that this field is used for
internal fabric control bits at the last stage of the fabric (between S3 and
FabricQ (Sponge)) since the destination address is not needed there.
Snoop/CTB - When set to one and for unicast traffic, this bit indicates
that the current cell is part of a snooped packet. (Note - the microcode and
software to support a snoop function on CRS-1 will be a future
development). When the cell is a multicast cell, this bit is used to indicate
CTB or Control Traffic Bit. Cells marked with the CTB bit carry software
control plane traffic and are given preference to multicast buffer resources
over regular high and low priority multicast traffic.
Internal Fabric Control Bits - These bits are used internally by the
fabric for various functions and may be redefined as cells traverse from
stage to stage.
1432
Version 2.0b
Module 14
Header
FEC
Switch Fabric Cell Structure (Cont.)
Two Packet Payload

Packet 1
Header (12 bytes)
Fields (Data Cells)
Bits
Cast (Mcast/Ucast)
Fabric Priority
Vital
Source Address
10
Packet 1 Sequence Number
13
Packet 2 Payload Offset/FGID
Trailing Offest
Packet Cell Count
Packet 1 Cell Sequence Number
Destination Address (12 bits)/FGID
18
Snoop/CTB
Internal Fabric control bits
32
Packet 2
Packet 1
Packet 2
Packet 2
Packet 1
30
bytes
30
bytes
30
bytes
30
bytes

Packet 1 (120 bytes)
Version 2.0b
1433
Module 14
Worst Case Fabric Cell Loading

Overview
The payload area of a fabric cell is 120 bytes and is comprised of four 30
byte boundaries. For maximum efficiencies a single cell can contain two 60
byte packets or one 120 byte packet. Increased overhead (waste) happens
when packets do not break on even 30 byte boundaries, causing the
remaining portion of the 30 byte boundary area to be filled with padding.
Example
The worst case scenario is when two 61 byte packets are sent through the
CRS-1 from ingress to egress interface. The packets are broken into cells
and then processed. As illustrated, packet 1 takes up the first two 30 byte
boundary areas and one byte of the third 30 byte boundary area. This
causes the remaining portion of the third boundary area, 29 bytes to be
padded out. Next, the four 30 byte boundary area of the first cell is filled
with the first 30 bytes of packet 2. The remaining 31 bytes of packet 2 then
fill the first 30 byte boundary area of cell 2, and 1 byte of the second 30
byte boundary area of cell 2 remaining 29 bytes of the second 30 byte
boundary area of cell 2 are filled with padding. The action of padding out to
the 30 byte boundary causes added overhead and additional processing
load.
1434
Version 2.0b
Module 14
Worst Case Fabric Cell Loading
Header
FEC
Worst Case Fabric Cell Loading Example
Two Packet Payload
Fabric cells can contain a

maximum of two 60 byte packets
Cell is most efficient when
Pkt 1
PAD Pkt 2
Pkt 2 PAD
Pkt 3
packets break on 30 byte

boundaries
Pkt 5
Pkt 4
Any packet that doesnt break

on 30 byte boundary causes
remainder of 30 bytes to be
padded out to the 30 byte
boundary, causing additional
overhead
30
bytes
30
bytes
30
bytes
30
bytes
Pkt 5 (150 bytes)
Version 2.0b
1435
Module 14
Switch Fabric Architecture

Ingress
The switch fabric is constructed with 8 identical, independent, and
unsynchronized switch planes. Each switch fabric plane is comprised of S1,
S2 and S3 ASICs.
Each switch fabric plane has 2 S1 ASICs. The MSCs in slots 0 through 7
connect to the upper S1 ASIC on each of the switch fabric planes. The 2
RPs in slots RP0 and RP1 and MSCs in slots 8 through 15 connect to the
lower S1 ASIC of each of the switch fabric planes.
Every MSC has 4 - 2.5Gbps serial connections to the S1 ASICs on each of
the 8 switch fabric planes. Therefore each MSC has 32 connections to the
S1 ASICs on the 8 switch fabric planes (4 connection per S1 * 8 switch
fabric planes). Each MSC therefore provides a raw to-fabric bandwidth of
80Gbps (32 connections @.2.5Gbps = 80Gbps). This raw to-fabric
bandwidth is then reduced by:
1. For serial to parallel encoding and error correction 8B10B encoding is
used. As the name implies 8 bits are packed into 10 bits thus a loss of
20% of the bandwidth.
2. Cell header represents about 12% in overhead
3. Segmentation - Whenever the size of a packet is not a multiple of the
cell size, segmentation will result in the last cell containing that packet
to be partially unused (note: the architecture actually allows packing 2
packets in 1 cell aligned on 30 byte boundaries, but the overhead is still
not completely eliminated). The worst case overhead is 28% (61 byte
packets).
4. Error Correction - A 4 byte FEC code is transmitted with each cell. This
is NOT the same as the error control that is done with the encoding
(8B10B is electronic layer one correction) and this error correction is at
the CELL layer (or layer 2 roughly). The FEC code is checked and
regenerated at each stage of the switch fabric (it must be regenerated
because the cell header is modified at each stage of the switch fabric).
The final result of all the combined overhead is an approximate ingress
bandwidth of 50Gbps.
Each RP has 2 - 2.5Gbps connections to the lower S1 ASIC in each of the
switch fabric planes.
1436
Version 2.0b
Module 14
Switch Fabric Architecture - Ingress
Fabric Plane
Upper shelf
Ingress MSC
S1
S2
S3
S1
S2
S3
RP
Lower shelf
Ingress MSC
Ingress speed
32 connections x 2.5Gbps = 80Gbps
80Gbps x 8/10 coding = 64Gbps
Minus cell tax = ~50Gbps
IngressQ
Switch Fabric Card
MSC
Slots
0-7
FabricQ
S1
S2
S3
MSC
MSC
MSC
Slots
8-15
S1
S2
S3
From
Fabric
To
Fabric
Note: RPs in slot
RP0 & RP1
Version 2.0b
1437
Module 14
Egress
On the egress side of the switch fabric planes, there are 4 S3 ASICs per
fabric plane. The S3 ASICs are split across the egress MSC slots in a
similar fashion to the S1 ASICs on the ingress side of the switch fabric
plane. The 2 upper S3 ASICs connects to MSC slots 0 through 7 and the 2
lower S3 ASICs on each switch fabric plane connects to the 2 RPs and the
remaining MSCs in slots 8 through 15.
Each S3 ASIC has 36 egress serial links; therefore the 4 S3 ASICs have a
total of 144 2.5 Gbps egress serial links. Of the 144, 72 are used by the
upper 2 S3 ASICs and the remaining 72 are used by the lower 2 S3 ASICs.
The 2 upper S3 ASICs per switch fabric plane, uses 64 2.5Gbps serial
links to connect to MSC in slots 0 through 7 the remaining 8 serial links
are unused. The lower 2 S3 ASICs use 64 2.5 Gbps serial links to connect
to the MSCs in slots 8 through 15. In addition the lower 2 S3 ASICs have 8
- 2.5Gbps serial links connected to RP0 and RP1 (4 per RP).
The raw from-fabric (egress) bandwidth is 160Gbps (64 * 2.5Gbps =
160Gbps). This is then reduced by:
1. For serial to parallel encoding and error correction 8B10B encoding is
used. As the name implies 8 bits are packed into 10 bits thus a loss of
20% of the bandwidth.
2. Cell header represents about 12% in overhead
The final result of all the combined overhead is an approximate egress
bandwidth of 100Gbps split across the 2 FabricQ ASICs per MSC.
_____________________________ Note _________________________
Egress forwarding capacity is only 40Gbps, so the MSC must
backpressure should it become overloaded.
_________________________________________________________________
1438
Version 2.0b
Module 14
Switch Fabric Architecture Egress
S3
S3
Plane
3
S3
S3
S3
S3
Plane
2
S3
S3
Plane
4
S3
S3
Plane
6
S3
S3
Plane
8
S3
S3
S3
S3
S3
S3
Egress MSC
Plane
1
S3
S3
S3
S3
Plane
5
S3
S3
S3
S3
S3
S3
Plane
7
S3
S3
S3
S3
Egress speed
64 x 2.5Gbps = 160Gbps
160Gbps x 8/10 coding = 128Gbps
Minus cell tax = ~ 100Gbps
Switch Fabric Card
IngressQ
FabricQ
0-7
S1
S2
S3
MSC
MSC
8-15
S1
S2
S3
From
Fabric
To
Fabric
Note: RPs in slot
RP0 & RP1
Version 2.0b
1439
Module 14
Switch Fabric Features

Speedup
Large speedup to overcome head-of-line blocking fabric congestion and to
decouple output queues from input queues. Fabric congestion can lead to
dropped packets at the ingress location and overflowing queues. By
implementing speed-up algorithms at the egress of the switch fabric you
reduce the chance of having congestion across the backplane. Also, since
there are multiple output ports on the egress of a MSC, by having multiple
queues and speed up on the egress from the backplane it allows you to
more efficiently use the fabric backplane and avoid head-of-line blocking.
Priority queuing
There are two levels of priorities that the IngressQ (Sprayer) ASIC assigns
packets to. These priorities are maintained all the way through the fabric
card out to the destination card. These priorities only deal with cell
traversing the switch fabric and have nothing to do with L2/L3 QoS or CoS.
High Priority
Low Priority
Service Enabling
Using the 3 stage Benes topology with buffering, speedup, self routing and
distribution enable non-blocking, but these enhancements do not enable
services. Most switch fabric mechanisms on routers can not differentiate
service types.
As part of the buffering mechanisms in the CRS-1 fabric, unique Hi
priority and Lo priority queues are designated for both unicast and
multicast traffic in each of the stages in the fabric. Hence the overall
fabric provides a layer of granularity for differentiating low latency vs. best
effort traffic.
In addition to the queuing, the fabric is over-provisioned with 2.5x speed
up ensuring that no traffic loss will occur unless the router is heavily
oversubscribed. Hence all low latency (high priority) packets will always be
transmitted through the fabric without being dropped.
1440
Version 2.0b
Module 14
40 Gbps
8 of 8
MSC
2 X Speedup
@ S3
136 Bytes cells
2 of 8
16
S1
S2
MSC
1 of 8
S1
S1
S2
S2
S1
S1
S3
S3
S2
S1
HP Low latency path
S3
S2
S2
S3
S3
S3
Multicast support
1M multicast
groups
1296 x 1296 buffered non-blocking switch

topology
H -Unicast
H -Unicast
H -Unicast
H -Unicast
H -Multicast
H -Multicast
H -Multicast
H -Multicast
H -Unicast
H -Unicast
H -Multicast
H -Multicast
S1
RR
S2
S2
S2
H -Unicast
H -Unicast
H -Multicast
H -Multicast
H -Unicast
H -Unicast
H -Unicast
H -Unicast
H -Unicast
HH-Multicast
-Multicast
H -Unicast
H -Multicast
H -Multicast
S1
S2
H -Unicast
H -Multicast
H -Multicast
H -Multicast
S2
S2
H -Unicast
Hi Priority Cells
Lo Priority Cells
RR
H -Unicast
H -Unicast
H -Unicast
H -Unicast
H -Multicast
H -Multicast
H -Multicast
H -Multicast
H -Multicast
Version 2.0b
H -Unicast
H -Unicast
HH-Unicast
-Unicast
H -Multicast
H -Multicast
HH-Multicast
-Multicast
1441
Module 14
Three stage (3-stage) Benes Topology
LC chassis contains MSCs and S123 of fabric.
Buffers at stages 2 and 3
Cell switched fabric optimized for IP packets
136 byte cells 120 byte payload, 12 byte header and 4 byte FEC
Pack 2 packets / cell
Packets broken into cells and evenly distributed over 8 planes

This prevents all packets going to a specific destination from essentially
take the same possible path
Stage Specific speed-up
2X speedup at S3 by doubling the number of S3 ASICs
8 parallel switch planes
Cost effective 1:N switch fabric redundancy
Simple 23T -> 23T & 46T -> 92T upgrade by upgrading switch cards
(and later MSCs capable of using the switch fabric cards in Phase 3)
Full multicast capability in the fabric
1442
1 Million fabric mcast groups
Mcast cells queued separately from unicast (also have their own high
and low priority queues)
Mcast cells are dropped if fabric is congested
Version 2.0b
Module 14
Switch Fabric Features (Cont.)
40 Gbps
8 of 8
MSC
2 X Speedup
@ S3
136 Bytes cells
2
1
2 of 8
16
S1
S2
S1
S1
S1
S1
MSC
1 of 8
S2
S2
S1
HP Low latency path
S3
S3
S3
S2
S2
S2
S3
S3
S3
Multicast support
1M multicast
groups
1296 x 1296 buffered non-blocking switch

topology
Version 2.0b
1443
Module 14
Modular QoS Command-Line Interface

In Cisco IOS XR software, QoS features are enabled through the Modular
QoS CLI (MQC) feature. The MQC is a CLI structure that allows users to
create traffic polices and attaches these polices to interfaces.
A traffic policy contains a traffic class and one or more QoS features. A
traffic class is used to classify traffic, while the QoS features in the traffic
policy determine how to treat the classified traffic. One of the main goals of
MQC is to provide a platform independent interface for configuring QoS
across Cisco platforms.
1444
Version 2.0b
Module 14
Modular QoS Command Line Interface (MQC)
MQC is used to:

Create traffic policies
Attach policies to interfaces
Provide a platform independent Command Line
Syntax
Version 2.0b
1445
Module 14
Traffic Class
The purpose of a traffic class is to classify traffic on your router. The classmap command is used to define a traffic class.
A traffic class contains three major elements: a name, a series of match
commands, and, if more than one match command exists in the traffic
class, an instruction on how to evaluate these match commands. The traffic
class is named in the class-map command line; for example, if you enter
the class-map premium command while configuring the traffic class in the
Modular QoS CLI (MQC), the traffic class would be named premium.
The match commands are used to specify various criteria for classifying
packets. Packets are checked to determine whether they match the criteria
specified in the match commands; if a packet matches the specified
criteria, that packet is considered a member of the class and is forwarded
according to the QoS specifications set in the traffic policy. Packets that
fail to meet any of the matching criteria are classified as members of the
default traffic class.
The instruction on how to evaluate these match commands needs to be
specified if more than one match criterion exists in the traffic class. The
evaluation instruction is specified with the class-map match-any or match-all
command. If the match-any option is specified as the evaluation instruction,
the traffic being evaluated by the traffic class must match one of the
specified criteria. If the match-all option is specified as the evaluation
instruction, the traffic being evaluated by the traffic class must match all
of the specified criteria.
1446
Version 2.0b
Module 14
Traffic Class
The class-map command is used to define a traffic class

Three elements define a traffic class:
A name
A series of match commands
An instruction on how to evaluate the match command
match commands are used to specify various criteria for classifying
packets
If packet matches criteria it is a member of the class and is forwarded based
on QoS specifications of policy
If no match, packets are members of default traffic class

If more than one match criterion exists in traffic class:
If evaluation instruction is specified as class-map match-any or match-all
command
match-any - Traffic being evaluated by traffic class must match one of

specified criteria (Logical AND)
Match-all - Traffic being evaluated by traffic class must match all specified criteria
(Logical OR)
Version 2.0b
1447
Module 14
Default Traffic Class

Unclassified traffic (traffic that does not meet the match criteria specified
in the traffic classes) is treated as belonging to the default traffic class. If
the user does not configure a default class, packets are still treated as
members of the default class.
However, by default, the default class has no enabled features. Therefore,
packets belonging to a default class with no configured features have no
QoS functionality. These packets are then placed into a FIFO queue and
forwarded at a rate determined by the available underlying link
bandwidth. This FIFO queue is managed by a congestion avoidance
technique called tail drop.
1448
Version 2.0b
Module 14
Default Traffic Class
Consists of all remaining previously unclassified

traffic
Has no enabled features (default value)

Placed in a FIFO queue by default
FIFO queue is managed using tail drop method
in Congestion Avoidance
Version 2.0b
1449
Module 14
Creating a class-map
To create a class-map containing match criterion, use the class-map
global configuration command to specify the class-map name. Optional
match commands can be used in class-map configuration mode, as
needed.
Within the class-map configuration mode you can specify additional
criteria to match against using the match command, these criteria are:
1450
access-group
any
discard-class
dscp
mpls
precedence
protocol
qos-group
Version 2.0b
Module 14
Creating a class-map
RP/0/RP1/CPU0:P1#config
RP/0/RP1/CPU0:P1(config)#class-map routine
RP/0/RP1/CPU0:P1(config-cmap)#match precedence ipv4 routine
RP/0/RP1/CPU0:P1(config-cmap)#exit
RP/0/RP1/CPU0:P1(config)#class-map match-any variety
RP/0/RP1/CPU0:P1(config-cmap)#match precedence ipv4 critical
RP/0/RP1/CPU0:P1(config-cmap)#match access-group blockacl
RP/0/RP1/CPU0:P1(config-cmap)#match mpls experimental topmost 1
RP/0/RP1/CPU0:P1(config-cmap)#exit
RP/0/RP1/CPU0:P1(config-cmap)#match ?
access-group
Access Group
any
Default class
discard-class
Discard behavior identifier
dscp
DSCP match criteria
mpls
Multi Protocol Label Switching specific values
precedence
Precedence match criteria
protocol
An IP Protocol Number
qos-group
Match on qos-group
RP/0/RP1/CPU0:P1(config-cmap)#match
Version 2.0b
1451
Module 14
Traffic Policy
The policy-map command is used to create a traffic policy. The purpose of a
traffic policy is to configure the QoS features that should be associated
with the traffic that has been classified in a user-specified traffic class or
classes. A traffic policy contains three elements: a name, a traffic class
(specified with the class command), and the QoS policies. The name of a
traffic policy is specified in the policy-map CLI (for example, issuing the
policy-map policy1 command would create a traffic policy named policy1).
The traffic class that is used to classify traffic to the specified traffic policy
is defined in policy map configuration mode. After choosing the traffic class
that is used to classify traffic to the traffic policy, the user can enter the
QoS features to apply to the classified traffic. This is done in policy-map
class configuration mode.
The MQC does not necessarily require that users associate only one traffic
class to one traffic policy. When packets match to more than one match
criterion, as many as 16 traffic classes can be associated to a single traffic
policy.
1452
Version 2.0b
Module 14
Traffic Policy
policy-map command is used to create a

traffic policy
Three elements define a traffic policy:
A name specified with policy-map command
A traffic class specified with class command
QoS policy or policies specified in policy-map
class configuration mode
16 traffic classes can be associated to a single

traffic policy
Version 2.0b
1453
Module 14
Creating a policy-map
To configure a policy-map, use the policy-map global configuration
command to specify the traffic policy name.
The class-map is associated with the policy-map when the class
command is used. The class command must be issued after entering
policy-map configuration mode. After entering the class command, you
are automatically in policy-map class configuration mode, which is where
the QoS policies for the traffic policy are defined.
In this example the two previously created two class maps named routine
and variety were associated with the policy-map named traffic-class using
the class command.
Within the policy-map class configuration mode you can specify:
1454
bandwidth
commit
describe
do
exit
no
police
priority
queue-limit
random-detect
service-policy
set
shape
show
Version 2.0b
Module 14
Creating a class-map and policy-map
RP/0/RP1/CPU0:P1(config)#policy-map traffic-class
RP/0/RP1/CPU0:P1(config-pmap)#class routine
RP/0/RP1/CPU0:P1(config-pmap-c)#bandwidth percent 10
RP/0/RP1/CPU0:P1(config-pmap-c)#exit
RP/0/RP1/CPU0:P1(config-pmap)#class variety
RP/0/RP1/CPU0:P1(config-pmap-c)#bandwidth percent 50
RP/0/RP1/CPU0:P1(config-pmap-c)#priority
RP/0/RP1/CPU0:P1(config-pmap-c)#exit
RP/0/RP1/CPU0:P1(config-pmap)#exit
RP/0/RP1/CPU0:P1(config-pmap)#class variety
RP/0/RP1/CPU0:P1(config-pmap-c)#?
bandwidth
bandwidth
commit
Commit the configuration changes to running
describe
Describe a command without taking real actions
do
Run an exec command
exit
Exit from this submode
no
Negate a command or set its defaults
police
Police traffic
priority
assign priority to this class
queue-limit
queue-limit
random-detect
enable random-detect
service-policy Configure QoS Service policy
set
Set QoS values
shape
Shape traffic
show
Show contents of configuration
RP/0/RP1/CPU0:P1(config-pmap-c)#
Version 2.0b
1455
Module 14
Attaching a service-policy to an Interface

After the traffic class and traffic policy are created, the service-policy
interface configuration command is used to attach a service-policy to an
interface, and to specify the direction in which the service-policy should
be applied (either on packets coming into the interface or packets leaving
the interface).
Once the class-map, policy-map and service-policy are committed, the
resulting configuration is shown at the bottom of the opposite page.
1456
Version 2.0b
Module 14
Attaching service-policy to an Interface
RP/0/RP1/CPU0:P1(config)#int pos0/4/0/2
RP/0/RP1/CPU0:P1(config-if)#service-policy output traffic-class
RP/0/RP1/CPU0:P1(config-if)#end
Uncommitted changes found, commit them before
exiting(yes/no/cancel)? [cancel]:y
RP/0/RP1/CPU0:P1#
RP/0/RP1/CPU0:P1(config)#sh run
class-map match-any routine
match precedence ipv4 routine
!
class-map match-any variety
match mpls experimental topmost 1
match precedence ipv4 critical
match access-group ipv4 blockacl
!
policy-map traffic-class
class routine
bandwidth percent 10
!
class variety
priority
!
service-policy output traffic-class
Version 2.0b
1457
Module 14
Displaying a policy-map
You use the show policy-map interface pos0/X/X/X to display the
statistical effects a policy-map has when applied to an interface.
1458
Version 2.0b
Module 14
Displaying a policy-map
RP/0/RP1/CPU0:P1#sh policy-map int pos0/4/0/2

POS0/4/0/2 output: traffic-class
Class routine
Classification statistics
Matched
Transmitted
Total Dropped
Queueing statistics
Vital
(packets)
Queueing statistics
Queue ID
High watermark (packets)
Inst-queue-len (bytes)
Avg-queue-len
(bytes)
TailDrop Threshold(bytes)
Taildropped(packets/bytes)
Class variety
Matched
Transmitted
Total Dropped
Queueing statistics
Vital
(packets)
Queueing statistics
Queue ID
Avg-queue-len
(bytes)
Class default
Matched
Transmitted
Total Dropped
Queueing statistics
Vital
(packets)
Queueing statistics
Queue ID
Avg-queue-len
(bytes)
RP/0/RP1/CPU0:P1#
(packets/bytes)
: 0/0
0
: 0/0
0
: 0/0
0
(rate -)
: 0
:
:
:
:
:
:
42
0
0
0
59904000
0/0
(packets/bytes)
: 72/9068
0
: 72/9068
0
: 0/0
0
(rate -)
: 0
:
:
:
:
:
:
14
0
0
0
2995200
0/0
(packets/bytes)
: 257/358833
0
: 44/3234
0
: 0/0
0
(rate -)
: 0
:
:
:
:
:
:
13
0
0
0
59904000
0/0
Version 2.0b
1459
Module 14
Summary
1460
How to describe the major features and functions of the MSC
How to describe how data flows from ingress interfaces through the
switch fabric and out through the egress interface
How to describe the IngressQ ASIC and EgressQ ASIC queuing and
shaping features
How to describe the Switch Fabric Cell structure
How to describe the major features of the Cisco CRS-1 switch fabric
To use MQC to create class-maps and policy-maps and attach servicepolices to an interface
Version 2.0b
Appendix A
Troubleshooting
Overview
Description
This module discusses CRS-1 modular services card (MSC) and switch
fabric card (SFC) troubleshooting. It also shows how memory and CPU
problems can be identified and resolved.
Objectives
Troubleshoot card-level errors
Check for memory problems and leaks
Look for process-level errors
Troubleshoot ASIC-level problems
Version 2.0
A1
Troubleshooting
Appendix A
Operational-Level Checks
Checking the Card State
When looking at CRS-1 cards, make sure that the card is in the IOS-XR
RUN mode. The RUN mode means that IOS-XR is loaded on the card and
in full operational mode. Several other states exist, like MBI-RUNNING or
IN-RESET, which are intermediate states a card goes through when
booting.
To view the slot locations of the different nodes and the PLIM type that is
mated through the midplane, use the show platform command.
A2
Version 2.0
Appendix A
Checking the Card State
To view the card status and associated PLIMs:

RP/0/RP1/CPU0:mttr-1# show platform
Normal operational
status of CRS-1 cards
that have booted is
IOS-XR RUN.
RP/0/RP1/CPU0:mttr-1#sh platform
Node
Type
PLIM
State
Config State
-------------------------------------------------------------------------------------------------------------------------0/1/SP
MSC(SP)
0/1/CPU0
MSC
N/A
IOS-XR RUN
4OC192-POS/DPT
PWR,NSHUT,MON
IOS-XR RUN
PWR,NSHUT,MON
0/RP1/CPU0 RP(Active)
N/A
IOS-XR RUN
PWR,NSHUT,MON
0/SM0/SP
N/A
IOS-XR RUN
PWR,NSHUT,MON
FC/S(SP)
Version 2.0
A3
Troubleshooting
Appendix A
Resetting a Card
To reset a CRS-1 card, use the hw-module node < r s i > reload
command. This command causes a complete reset of that card. The
software, configuration, drivers, and routing and forwarding tables are
reloaded.
A4
Version 2.0
Appendix A
Resetting a Card
To reset a modular services card (MSC is also referred to

as a node):
RP/0/RP1/CPU0:mttr-1#hw-module node <#> reload
RP/0/RP1/CPU0:mttr-1#hw-module node 0/3/CPU0 reload

RP/0/RP1/CPU0:Nov 24 00:48:54.630 : shelfmgr[292]: %SHELFMGR-3-USER_RESET :
Node 0/3/cpu0 is reset due to user reload request
Version 2.0
A5
Troubleshooting
Appendix A
Identifying Software Issues

To identify a process ID that crashed, use the show context command.
This command shows the location on the disk drive where the core dump
file is located in this example, disk0:/metro_driver.20031114135355.node0_3_1.Z.
This information, along with the core dump file, identifies software issues
encountered during beta testing and reports them to Cisco for decoding
and resolution.
A6
Version 2.0
Appendix A
Identifying Software Issues
Displays the PID

number that caused
the crash
Shows the location

of the core dump file
RP/0/RP1/CPU0:mttr-1# show context all location 0/3/CPU0

Crashed pid = 20519 (pkg/bin/metro_driver)
Crash time: Fri Nov 14, 2003: 13:53:55
Core for process at disk0:/metro_driver.20031114-135355.node0_3_1.Z
Stack Trace
#0 0xfc225248
Used mainly for bug reporting and by beta
..
customers for problem reporting
#9 0x4820268c
Registers info
<text omitted>
R36 24000022 20000004
DLL Info
DLL path Text addr. Text size Data addr. Data size Version
/pkg/lib/libinfra.dll 0xfc10a000 0x00030c98 0xfc109268 0x00000a70
0
Version 2.0
A7
Troubleshooting
Appendix A
Troubleshooting CPU Overload

To determine how many processes are running on a card and which
processes are consuming the most cycles, use the top command.
From the information you obtain with the top command, you can
investigate the reason behind the high CPU usage. In this example, note
that the gsp process is using 38% of the CPU cycles and also note the job
ID (JID) and thread ID (TID) of this process.
The gsp process (a necessary process) allows the sending of data over the
fabric between MSCs and RPs. Because gsp is using the fabric, you see
gsp errors when fabric problems occur. An option exists in gsp that
allows you to send gsp pings over the fabric to test connectivity.
A8
Version 2.0
Appendix A
To view the processes that consumes the most cycle

time:
RP/0/RP1/CPU0:mttr-1# top
Standard top command
displays top processes
RP/0/RP1/CPU0:mttr-1# top
98 processes; 320 threads;
Write down
CPU states: 0.0% idle, 39.2% user, 60.7% kernel
thread ID for
Memory: 1024M total, 202M avail, page size 4K
isolation
JID TID PRI STATE HH:MM:SS

135 15 10 Rply 0:07:15
1 14 10 Run 0:06:49
1
4 10 Rcv 0:07:06
149
1 10 Rdy 0:00:49
CPU COMMAND
38.03% gsp
33.94% procnto-600-smp-cisco-instr
26.83% procnto-600-smp-cisco-instr
0.39% ipv4_fib_mgr
Version 2.0
A9
Troubleshooting
Appendix A
Troubleshooting Memory Issues

Just as you attached to a modular services card (MSC) to isolate process
issues, you must similarly attach to the MSC to troubleshoot memory
issues on a particular node. Remember that on a CRS-1 each card
functions independently and has a separate CPU and memory.
In this example, note that the router has 1 GB of memory available and
that 884 MB of it is in use, leaving only 105 MB of free memory. This
difference indicates that something is taking up a lot of memory, and you
have to isolate the process that is using it.
A10
Version 2.0
Appendix A
To look at the total and available memory:

RP/0/RP1/CPU0:mttr-1# show memory [location] <node>
Show summary
memory information
RP/0/RP1/CPU0:mttr-1# show memory [location] <node>

[1] 114784
Physical Memory: 1024M total
Application Memory : 884M (105 M available)
Image: 11M (bootram: 11M)
Reserved: 128M, IOMem: 0, flashfsys: 0
Total shared window: 0
Version 2.0
A11
Troubleshooting
Appendix A
Viewing Top Memory-Consuming Issues

To look at the memory-allocation information, use the malloc dump A p
208 & command.
In this example, you determine that the tcam_mgr process is taking up
more than 600 MB of memory. Using the process-isolating techniques you
just learned in the process-troubleshooting section, you can determine
what the tcam_mgr is doing. You see that the JID of the tcam_mgr
process is 208. Using this information, you can troubleshoot the process or
try to obtain more information about the memory allocation.
A12
Version 2.0
Appendix A
Viewing Top Memory-Consuming Issues
To view the top memory-consuming processes on the

router:
RP/0/RP1/CPU0:mttr-1# #show processes
RP/0/RP1/CPU0:mttr-1l# #show processes
JID Text
Data Stack Dynamic
208 45056 4096 12288 604951808
53 24576 0
12288 16056320
Job ID of the
process
55 28672 4096 73728 12939264
tcam_mgr for
135 98304 4096 167936 4706304
further
64 8192
4096 40960 1789952
investigation
170 40960 4096 118784 1134592
204 4096
4096 20480 1097728
132 28672 4096 45056 987136
215 65536 4096 40960 966656
216 81920 4096 40960 933888
Version 2.0
Top two memory

consumingprocesses
Process
tcam_mgr
dllmgr
eth_server
gsp
pkgfs
netio
sysdb_svr_local
fqm
wdsysmon
mpls_lfd
A13
Troubleshooting
Appendix A
Troubleshooting the Data Path

Ingress Data Path
Packets arriving at the router follow the ingress data path from the framer
to the pla (Moose) to the pse (Metro) and to the ingressq (Sprayer). The
fabric interface ASIC (FIA) is the generic serial-encapsulation ASIC that
performs encoding and pushes the data onto the fiber channels (FC).
framer -> pla -> pse -> ingressq -> FIA -> FC
Ingress Punt Path

Packets that are not data packets and must be processed by the local card
CPU follow the same path as the data path, but instead of being sent to the
fabric they are punted to the cpuctrl (Squid) field programmable gate
array (FPGA), which serves as a gateway between the different ASICs on
the node and the CPU. The CPU processes the packets and responds as
needed. Samples of packets that must be punted are ICMP, ARP, and
routing protocol packets.
framer -> pla -> pse -> ingressq -> cpuctrl
Egress Data Path

The egress data path refers to the packets that are being pulled from the
fabric and must be sent out the interfaces. From the fabric, the data is
converted by the FIA ASICs and then it is sent to the fabricq (Sponge), pse
(Metro), egressq (Sharq), and finally pla (Moose) ASICs. From the pla
ASIC, it is sent to the PLIM for framing and electrical and/or optical
conversion.
fabric -> FIA -> fabricq -> pse -> egressq -> pla -> framer
Egress Punt Path

The egress punt path again follows the same path as the data path except
that again instead of sending the packet to the pla (Moose) ASIC, the
packet is sent to the cpuctrl (Squid) ASIC for processing.
fabric -> FIA -> fabricq -> pse -> egressq -> cpuctrl
A14
Version 2.0
Appendix A
From
fabric
fabricq 0|1
(SPONGE)
pse 1
(METRO)
Egressq
(SHARQ)
To
line
cpuctrl
(SQUID)
pla
(MOOSE 0|1)
Aka
reindeer/bambi
From
line
To
fabric
ingressq
(SPRAYER)
pse
(METRO) 0
Version 2.0
A15
Troubleshooting
Appendix A
Ingress
Troubleshooting Ingress Interfaces
To see whether any packets have been dropped or there are any input and
output errors, use the show interface command. Usage of this command
is a good first step to take to look for any errors that are occurring on a
particular interface.
In this example, you see 57 input errors and 28 cyclic redundancy check
(CRC) in the input direction, which you can then investigate.
You also see that the pla (Moose) ASIC is the interface controller, which
means all traffic to and from the interface must pass through it. So, a good
next step is to look at the pla (Moose) ASIC and see if there are any errors.
A16
Version 2.0
Appendix A
Ingress
Troubleshooting Ingress Interfaces
To look at the general health of an interface:

RP/0/RP1/CPU0:mttr-1#show interface pos 0/0/1/2
Basic command looks for

input or output drops and
is a good starting point
RP/0/RP1/CPU0:mttr-1#show interface pos 0/0/1/2

POS0/0/1/2 is down, line protocol is down
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation HDLC, crc 32, controller loopback not set, keepalive not set
<text omitted all zero counters>
10 packets input, 1040 bytes, 57 total input drops
0 drops for unrecognized upper-level protocol
Received 0 broadcast packets, 0 multicast packets
0 runts, 0 giants, 0 throttles, 0 parity
57 input errors, 28 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
11 packets output, 1058 bytes, 0 total output drops
Output 0 broadcast packets, 0 multicast packets
<text omitted all zero counters>
Version 2.0
A17
Troubleshooting
Appendix A
Troubleshooting PLA (Moose)

Packets arriving from the framers first go to the PLIM, so you begin to
troubleshoot data-path errors by looking at the PLA ASIC. Because you are
troubleshooting packet input errors, you start with the pla (Moose) ASIC
and work your way to the ingressq (Sprayer) ASIC.
First, you see from the counters that the PLA ASIC is talking to its two
neighbors, the egressq (Sharq) and pse (Metro) ASICs, and sending and
receiving packets from the interfaces on the PLIM (port).
A18
Version 2.0
Appendix A
Ingress
Troubleshooting PLA (Moose)
RP/0/RP1/CPU0:mttr-1#sh controllers plim asic statistics interface pos0/2/0/2 loc

0/2/cpu0
POS0/2/0/2 Rx Statistics
------------------------------------------------------------------------------TotalOctets
: 1904958626719
TotalPkts
: 3882676509
UnicastPkts
: 3882676509
MulticastPkts
:0
BroadcastPkts
:0
64Octets
: 2024
65to127Octets
: 1584114119
128to255Octets : 149750275
256to511Octets : 390598060
512to1023Octets : 1178976903
1024to1518Octets : 579127866
1519to1548Octets : 1
1549to9216Octets : 10763
>9216Octets
:0
BadCRCPkts
:0
BadCodedPkts
:0
Runt
:0
ShortPkts
: 98520
802.1QPkts
:0
Drop
:0
PausePkts
:0
ControlPkts
:0
Jabbers
:0
BadPreamble
:0
Version 2.0
A19
Troubleshooting
Appendix A
In the pla (Moose) troubleshooting output shown on the oppose page, you
see the categories of packet sizes received and sent and the total number of
packet byte counters. These categories are more for statistical information
rather than troubleshooting, but they result from the troubleshooting
process.
A20
Version 2.0
Appendix A
Ingress
Troubleshooting PLA (Moose) (cont.)
POS0/2/0/2 Rx Statistics
------------------------------------------------------------------------------TotalOctets
: 1904958626719
TotalPkts
: 3882676509
UnicastPkts
: 3882676509
MulticastPkts
:0
BroadcastPkts
:0
64Octets
:2
65to127Octets
: 1584114119
128to255Octets : 149750275
256to511Octets : 390598060
512to1023Octets : 1178976903
1024to1518Octets : 579127866
1519to1548Octets : 1
1549to9216Octets : 10763
>9216Octets
:0
BadCRCPkts
:0
BadCodedPkts
:0
Runt
:0
ShortPkts
: 98520
802.1QPkts
:0
Drop
:0
PausePkts
:0
ControlPkts
:0
Jabbers
:0
BadPreamble
:0
POS0/2/0/2 Drop
------------------------------------------------------------------------------RxFiFO Drop
: 49
PAR Tail Drop : 0
TxFIFO Drop
:0
Version 2.0
A21
Troubleshooting
Appendix A
Troubleshooting the General Health of PSE (Metro)

To troubleshoot the general health of the PSE (Metro) ASIC, use the show
controllers pse summary command. Make sure that the state of the
device is up, and check for any excessive cold or warm resets of the device
since power up; one cold reset always occurs for the initial configuration of
the ASIC. And check for excessive error interrupts for this ASIC, which
may warrant a dump of the show ASIC-error metro command output.
A22
Version 2.0
Appendix A
Ingress
Troubleshooting the General Health of PSE (Metro)
RP/0/RP1/CPU0:mttr-1#show controllers pse summary

RP/0/RP1/CPU0:mttr-1# show controllers pse summary instance 0 loc 0/0/cpu0
Node: 0/0/cpu0:
---------------------------------------Look to make sure device
PSE 0, Summary Info:
state is up, indicating that
------------------------------------------------Metro is active
<text omitted>
DeviceState : 0 (UP)
StartupOpts : 00000000 MmappedBase : 0x609b0000
ClsDisMask : 0x1000 NFusedPPEs : 199 (188 hwf, 11 swf)
MPUcodeName : /pkg/gsr/ucode/ingress_mp_v1.mucode
PPEUcodeName: /pkg/gsr/ucode/ingr ess_turbo_pos_v1.mucode
INTR-Status : 00000000 INTR-Enable : 0x7ffffe
NColdResets : 1
NWarmResets : 0
Check for excessive resets,
NResetRetry : 0
which indicate hardware
NIntrtps : 3
NIntrptThrot: 0
problems
Version 2.0
A23
Troubleshooting
Appendix A
Troubleshooting PSE (Metro)

Because you are looking for errors, any counters displaying 0 as the
statistic can be ruled out to indicate an error condition. So expand the use
of the commands you just learned and exclude any output with a value of
zero (0).
Some statistics show packet drops in PSE (Metro). The counts indicating
errors can be identified by the presence of DROP, ERROR,
UNKNOWN, or BAD in the counter name. In this example, you see
many packets have been dropped by PSE 0 due to IPV4 header checksum
errors. Because the entry for this destination in the CEF FIB is marked for
load balancing, the FIB code has an attribute of drop for this particular
entry and has dropped a roughly equal number of packets.
Note that DUMMY_COUNTER always keeps incrementing in an
operational PSE, and indicates the aggregate number of dummy packets
(idles) processed in that PSE.
A24
Version 2.0
Appendix A
Ingress
Troubleshooting PSE (Metro)
To display both PSE (Metro) ASIC traffic

information:
Because you are looking for

errors, you can exclude any
statistics that have zero
counters.
RP/0/RP1/CPU0:mttr-1# show controller pse statistics
RP/0/RP1/CPU0:mttr-1# show cont pse statistics loc 0/0/cpu0 | exclude ": 0"
.
PSE 0, Statistics Info:
CDP : 1442 (informational number of CDP packets received)
DROP_IPV4_CHECKSUM_ERROR : 2534657
DUMMY_COUNTER : 1131918326098 (indicates idle packets sent on a link)
.
PSE 1, Statistics Info: !! (this displays the SECOND PSE asic )
DROP_L3_LOAD_INFO : 2651376
DUMMY_COUNTER : 1131912204019
Dummy counters do not
indicate errors; they

indicate idle cells
Version 2.0
A25
Troubleshooting
Appendix A
Checking for PSE (Squid) Punt Path Errors

How do I debug while the packets punted by PSE are not being received by
the software switching process (netio) on the MSC CPU?
Depending on whether the packets are being punted by the ingress PSE or
egress PSE ASIC, you may want to look at the packet direct memory access
(PDMA) errors for the ingressq (Sprayer) or egressq (Sharq) port,
respectively, with the show controllers cpuctrl ports command. For
example, if the packets punted by the ingress PSE are not being received
by the netio process, you might want to check if you are experiencing any
PDMA error conditions on the ingressq (Sprayer)-to-cpuctrl (Squid) port.
A26
Version 2.0
Appendix A
Ingress
Checking for PSE (Squid) Punt Path Errors
To determine whether packets punted by PSE (not for data path) are dropped:
RP/0/RP1/CPU0:mttr-1# show controllers cpuctrl ports ingressq pdma all
RP/0/33/1# show controllers cpuctrl ports ingressq pdma all active loc 0/0/cpu0| include errors
Rx Pkt errors = 0
Rx NoBuffers = 0
Rx NoBufferLimit = 0
Rx Pkt errors = 0
Rx NoBuffers = 0
Rx Pkt errors = 0
Rx NoBuffers = 0
Rx Pkt errors = 0
Rx NoBuffers = 0
Rx Pkt errors = 0
Rx NoBuffers = 0
Rx Pkt errors = 0
Rx NoBuffers = 0
Rx Pkt errors = 0
Rx NoBuffers = 0
Version 2.0
A27
Troubleshooting
Appendix A
Troubleshooting Ingressq (Sprayer)

To complete the ingress data path troubleshooting, look at the ingressq
ASIC (Sprayer) with the following command to see if you can determine
what counters would indicate errors occurring on the ingressq ASIC.
#show controllers ingressq statistics location 0/0/cpu0
With this command, you can find out whether the ingressq ASIC is
receiving any packets from the PSE (Metro) and cpuctrl (Squid) ASICs,
and how many such packets are being dropped. Note, too, that packets
marked as received from or transmitted to the CPU are being transmitted
to the cpuctrl FPGA, which is the traffic cop for every packet that is sent
to the CPU by the punt path.
Note that the rx pkts (received packets) and tx pkts (transmitted
packets) counters are nearly identical. These two counters identify the
number of packets received from the PSE ASIC and then forwarded to the
fabric. A counter in the example displays 2 as the number of packets
dropped due to length errors. This number is the difference between the
two counters. The cells dropped are equal to the number of packets because
they were probably dropped during cell assembly and reassembly.
Now take a look at the tx cells to fabric counter and note that this
number does not have to be equaland it most likely never willto the
number of packets sent because a cell does not always map directly to a
packet received.
A28
Version 2.0
Appendix A
Ingress
Troubleshooting Ingressq (Sprayer)
RP/0/RP1/CPU0:mttr-1# show controllers ingressq statistics location 0/0/cpu0
Ingressq Rx Statistics.
Packets received
-----------------------------------------------------------------------from Metro
rx pkts
:
1281816 (
645169854 bytes)
rx pkts from cpu
:
487579 (
110400014 bytes)
rx control pkts from cpu
:
487579 (
110400014 bytes)
Packets
sent to
rx data pkts from cpu
:
0 (
0 bytes)
the fabric
Ingressq Tx Statistics.
-----------------------------------------------------------------------tx pkts
:
1281814 (
653384420 bytes)
tx pkts to cpu
:
794227 (
534768680 bytes)
tx control pkts to cpu
:
794217 (
534767520 bytes)
tx data pkts to cpu
:
10 (
1160 bytes)
tx pkts shaped
:
487587 (
118615740 bytes)
tx cells to fabric
:
1290015
Ingressq Drops.
-----------------------------------------------------------------------length error drops
:
2
crc error drops
:
97273
OOR error drops
:
0
Difference between
backpressure discard drops :
0
the two preceding
tail drops
:
0
counters
cell drops
:
2
Version 2.0
A29
Troubleshooting
Appendix A
CRC Error Possibilities

When you encounter CRC errors, you should consider:
The EIO link between the ingressq and PSE ASICs has gone bad.
The EIO link needs to be retrained.
A software bug has caused the ingressq ASIC to enable the EIO link
before waiting for the link to be fully trained.
The implication of an error means that the ingressq ASIC could be losing
packets if the counter keeps increasing at run time. If this loss happens,
look at the state of the EIO link at the ingressq ASIC with the following
command:
show controller ingressq eio link all loc <>
This command tells you if either the link training failed or the link is
getting trained multiple times. You need to consider the health of that
ingressq EIO link when you see CRC errors.
A30
Version 2.0
Appendix A
Ingress
Troubleshooting Ingressq (Sprayer) (cont.)
RP/0/RP1/CPU0:mttr-1# show controllers ingressq statistics location 0/0/cpu0
Ingressq Rx Statistics.
Packets received
-----------------------------------------------------------------------from Metro
rx pkts
:
1281816 (
645169854 bytes)
rx pkts from cpu
:
487579 (
110400014 bytes)
rx control pkts from cpu
:
487579 (
110400014 bytes)
Packets
sent to
rx data pkts from cpu
:
0 (
0 bytes)
the fabric
Ingressq Tx Statistics.
-----------------------------------------------------------------------tx pkts
:
1281814 (
653384420 bytes)
tx pkts to cpu
:
794227 (
534768680 bytes)
tx control pkts to cpu
:
794217 (
534767520 bytes)
tx data pkts to cpu
:
10 (
1160 bytes)
tx pkts shaped
:
487587 (
118615740 bytes)
tx cells to fabric
:
1290015
Ingressq Drops.
-----------------------------------------------------------------------length error drops
:
2
crc error drops
:
97273
OOR error drops
:
0
Difference between
backpressure discard drops :
0
two preceding
tail drops
:
0
counters
cell drops
:
2
Version 2.0
A31
Troubleshooting
Appendix A
Egress
Fabricq (Sponge)
Packets arriving from the fabric first come into the fabricq (Sponge) ASIC.
Two fabricq ASICs exist for each MSC, and buffering is done in the fabricq
because packets are being drawn from the fabric faster than the card can
actually process them.
Note that an input cell counter refers to cells received from the fabric.
Immediately following these cell counters is a counter that shows the total
number of packets reassembled by the fabricq ASIC. Two different sets of
counters also occur, one for each of the fabricq ASICs.
A32
Version 2.0
Appendix A
Egress
Fabricq (Sponge)
To display fabricq (Sponge) ASIC packet statistics:

RP/0/33/1:Alamo# show controllers fabricq packet-stats
RP/0/33/1:Alamo# show controllers fabricq packet-stats location 0/0/cpu0
Fabric Queue Manager Packet Statistics
======================================
Location: 0/2/CPU0
Asic Instance: 0
Fabric Destination Address:
Refers to cells
received from
the fabric
32
Input Cell counters:

+----------------------------------------------------------+
Data cells
: 36263956225 (+ 21319270 )
Control cells
:1097010334
(+ 534872 )
Idle cells
: 6014718920690 (+ 2927581070 )
Reassembled packet counters
+----------------------------------------------------------+
Ucast pkts
: 5045312241
(+ 2966418 )
Mcast pkts
: 1664653428
(+ 979280 )
Cpuctrlcast pkts
: 1388823
(+ 295 )
Version 2.0
A33
Troubleshooting
Appendix A
The packet counters are divided by ASIC level, with the second ASIC
information continuing after fabricq ASIC 0.
A34
Version 2.0
Appendix A
Egress
Fabricq (Sponge) (Cont.)
This counter indicates

whether any packets
pulled were dropped
due to buffer misses
Dropped packets
+----------------------------------------------------------+
Ucast pkts
:
0 (+
0)
Mcast pkts
:
0 (+
0)
Cpuctrlcast pkts
:
0 (+
0)
Vital denied pkts
:
0 (+
0)
NonVital denied pkts :
0 (+
0)
Unicast lost pkts
:
5395 (+
0)
Ucast partial pkts
:
0 (+
0)
PSM OOR Drops
:
0 (+
0)
Location: 0/2/CPU0
Asic Instance: 1
Fabric Destination Address: 33
Input Cell counters:
+----------------------------------------------------------+
Data cells
: 25730549142 (+
15121398 )
Control cells
: 1097010241
(+
534738 )
Idle cells
: 6025247961239 (+ 2933063120 )
Reassembled packet counters
+----------------------------------------------------------+
Ucast pkts
: 3751617451 (+ 2204902 )
Mcast pkts
:
0 (+
0)
Cpuctrlcast pkts
:
0 (+
0)
Dropped packets
+----------------------------------------------------------+
Ucast pkts
:
0 (+
0)
Mcast pkts
:
0 (+
0)
Cpuctrlcast pkts :
0 (+
0)
Vital denied pkts :
0 (+
0)
NonVital denied pkts :
0 (+
0)
Unicast lost pkts :
7831 (+
7831)
Ucast partial pkts :
0 (+
0)
PSM OOR Drops
:
0 (+
0)
Version 2.0
A35
Troubleshooting
Appendix A
Egressq (Sharq)
From the previous commands, you can figure out the state of the egressq
(Sharq) ASIC by looking at the ASIC state. During normal operation, the
state should display normal.
You can look at traffic statistics to see the number of packets (and bytes)
received from the PSE ASIC and sent to the PLA ASIC. Counters also exist
that let you look at packets dropped by the PSE and Squid ASICs.
A36
Version 2.0
Appendix A
Egress
Egressq (Sharq)
RP/0/RP1/CPU0:mttr-1# show controllers egressq statistics location 0/0/cpu0

egressq ASIC version: 1
Packets sent to the
egressq ASIC state: Normal
PLIM ASIC
plimasic link0 output packets: 4294967295
plimasic link0 output bytes: 4257472179491
Packets received
from the cpuctrl
ASIC
cpuctrl input packets: 893151
cpuctrl output bytes: 337999299
Packets received
pse input packets: 4294967295
from the pse ASIC
pse dropped packets: 0
cpuctrl dropped packets: 0
Version 2.0
A37
Troubleshooting
Appendix A
Troubleshooting Switch Fabric Cards

SFC Troubleshooting Overview
This section examines the switch fabric card (SFC). Here you learn to
check and discover whether all SFCs are operational and working properly;
look at packet statistics, which go across the fabric planes; display the uptime percentage and length of time in service for a card; and learn a new
method to ping across the fabric to determine whether packets have a
path-through backplane that is functioning properly.
A38
Version 2.0
Appendix A
SFC Troubleshooting Overview
S1
S1
S1
S1
S1
S1
S1
S1
S1
S1
S1
S1
S1
S1
S1
S3
Sprayer
Port
S1
LINE CARD
S3
S3
S3
S2 S3
S3
S3
S3
S1
S1
S1
S1
S1
S1
S1
FABRIC CARDS
Version 2.0
Port
Sponge
S1
Sprayer
S
2
S3
S3
S3
S3
S3
S3
S3
S3
S3
S3
S3
S3
S3
Sponge
1. Test operational status

2. Check packet statistics
3. Check health statistics
4. Learn how to ping across
fabric to test connectivity
S3
S3
S3
LINE CARD
A39
Troubleshooting
Appendix A
Checking the Switch Fabric Card Health

To see whether all eight switch fabric planes are up and operational on the
box, use the admin show controllers fabric plane all command. Most
important, look for any SFC that has an operational state marked down,
which indicates an error condition that has caused an SFC to fail. In this
example, you see that the operational state is up on all cards.
A40
Version 2.0
Appendix A
Checking the Switch Fabric Card Health
To check SFC status:

RP/0/RP1/CPU0:mttr-1# admin show controllers fabric plane all
RP/0/RP1/CPU0: mttr-1#admin show controllers fabric plane all
Plane Admin Oper
Down Total
Down
Id
State
State
Flags
Bundles Bundles
---------------------------------------------------------------------------0
UP
UP
0
0
1
UP
UP
0
0
2
UP
UP
0
0
3
UP
UP
0
0
4
UP
UP
0
0
5
UP
UP
0
0
6
UP
UP
0
0
7
UP
UP
0
0
Version 2.0
A41
Troubleshooting
Appendix A
Data Path Cell Transmission

Switch fabric cards (SFCs) pass all data path traffic from ingress to egress
ports. Thus traffic passing through the cards should be increasing at very
high rates.
In the example, you see that hundreds of billions of cells have passed
through each of the SFCs with very few errors. The errors are marked in
the last three columns and are indicated as follows:
CE = Correctable Error
UCE = Uncorrectable Error
PE = Parity Error
In the example, you see that a few errors occurred on some of the SFCs. In
normal operation, a very small, non-increasing number of errors does not
indicate a problem. Error counters that are high and increasing steadily
indicate that one of the cards may need replacement.
A42
Version 2.0
Appendix A
Data Path Cell Transmission
To see how many cells have been transmitted across each plane:
RP/0/RP1/CPU0:mttr-1# admin show controller fabric plane all stat
RP/0/RP1/CPU0:mttr-1# admin sh contr fabric plane all stat

In
Out
CE UCE PE
Plane
Cells
Cells
Cells Cells Cells
-----------------------------------------------------------------------------------------0
182100857464
182104887774
0
5
0
1
181926888266
181929025881
0
4
0
2
182153559719
182155676693
0
1
0
3
175491618741
175493740472
0
2
0
4
182582550997
182584668766
1
5
0
5
168887486356
168889599486
1
7
0
6
182993770506
182995889294
0
0
0
7
182059456630
182061580187
0
10
0
Version 2.0
A43
Troubleshooting
Appendix A
Getting Error Details for a Card

If you see an increasing number of errors when you look at all the SFCs in
the system, you can isolate the card that is logging errors by using the
detail flag at the end of the admin show controller fabric plane
command and by specifying the SFC number you want to monitor.
This command lets you look more closely at the errors and data sent and
received for a particular card.
A44
Version 2.0
Appendix A
Getting Error Details for a Card
Detail flag gives more information for each plane:

RP/0/RP1/CPU0:mttr-1# admin sh contr fabric plane 7 stat detail
RP/0/RP1/CPU0:mttr-1# admin sh contr fabric plane 7 stat detail
The fabric plane number is 7
..
Total number of providers for the statistics: 1
Total received data cells: 182821414530
Total received unicast data cells: 182820991976
Total received multicast data cells: 422554
Total transmitted data cells: 182823538527
Total transmitted unicast data cells: 182821003591
Total transmitted multicast data cells: 2534936
Total received correctable errored cells: 0
Total received uncorrectable errored cells: 10
Total received parity error cells: 0
Total unicast lost cells: 0
Total multicast lost cells: 0
Last clearing of "show controller fabric plane" counters never
Version 2.0
A45
Troubleshooting
Appendix A
Displaying SFC-to-MSC Connectivity

To see whether MSCs and RPs are connected and able to send data across
all switch fabric cards (SFCs) in the system, use the admin show cont
fabric connectivity command. A 1 (bit can be set to 1 or 0) should be
set for each of the eight SFCs in the router to indicate that the MSCs can
transmit and receive data across all SFCs.
A46
Version 2.0
Appendix A
Displaying SFC-to-MSC Connectivity
To check SFC connectivity to the MSC:

RP/0/RP1/CPU0:mttr-1# admin show cont fabric connectivity
RP/0/RP1/CPU0:mttr-1#
admin show cont fabric connectivity all detail
Card In Tx Planes Rx Planes Monitored

Total
Percent
R/S/M Use 01234567 01234567 For (s)
Uptime (s) Uptime
------------------------------------------------------------------------------------------------0/0/1 1 11111111 11111111 316247
316247
100.000
0/1/1 1 11111111 11111111 316247
316247
100.000
0/32/1 1 11111111 11111111 316247
316247
100.000
0/33/1 1 11111111 11111111 316247
316247
100.000
Each of 8 planes
should have a 1 bit
set to indicate that the
connectivity is good
Total uptime and

percentage of uptime
since an error was
indicated
Version 2.0
A47
Troubleshooting
Appendix A
Summary
Troubleshooting
A48
Troubleshoot card-level errors
Check for memory problems and leaks
Look for process-level errors
Troubleshoot ASIC-level problems
Version 2.0
Appendix B
Student Evaluation
Version 2.0
B1
Part Number: XX#######-XX-X

Cisco CRS

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Cisco CRS

Caricato da

Copyright:

Formati disponibili

CRSE

Cisco CRS-1 Essentials

Copyright 2005, Cisco Systems, Inc. All rights reserved.

Network and Senior Engineers

Basic knowledge of router installation and some experience with

Routing protocols configuration experience with BGP, ISIS and

Advanced knowledge of BGP multi-homed, multi-as configurations,

Strong knowledge of MPLS configuration or CMPLS course

Multicast configuration experience or Cisco Multicast

Advanced knowledge of Cisco router security implementation

Experience troubleshooting Cisco routers in a large network

2005 Cisco Systems, Inc.

hardware or software product. Using Adobe Acrobat Reader, you can

Comprehensive network support is available from Cisco Systems

Cisco CRS-1 Essentials

2005 Cisco Systems, Inc.

Cisco CRS-1 Essentials

Course Introduction and Objectives

Configure CRS-1 platform, back out of configuration changes,

2005 Cisco Systems, Inc.

Install Cisco IOS XR operating system, Package Information

Configure the new IOS XR security features

Configure routing protocols in a complex multi-AS environment

Enable Multicast routing on IOS XR platforms (focus on IOS

Configure MPLS on IOS XR platform

Convert legacy route map configurations using new RPL

Use the CWI to configure, view, check configurations and obtain

Understand data flow through the CRS-1 routing system

Troubleshoot basic CRS-1 hardware and software problems

Cisco CRS-1 Essentials

Course Introduction and Objectives ................................................................ ix

2005 Cisco Systems, Inc.

Cisco CRS-1 Essentials

Cisco IOS XR Architecture.................................................................................................62

Module 10 ...................................................................................................... 101

2005 Cisco Systems, Inc.

Module 11 ...................................................................................................... 111

Module 12 ...................................................................................................... 121

Module 13 ...................................................................................................... 131

Module 14 ...................................................................................................... 141

Cisco CRS-1 Essentials

2005 Cisco Systems, Inc.

Cisco CRS-1 Essentials

List the major features of the Cisco CRS-1 routing systems

List and describe the different Cisco CRS-1 platforms

List and describe four features of core-layer consolidation using the

List the Cisco CRS-1 interfaces types

2005 Cisco Systems, Inc.

Cisco CRS-1 Carrier Routing System

Cisco CRS-1 Carrier Routing Systems

Cisco CRS-1 Essentials

Cisco CRS-1 Carrier Routing Systems

Cisco CRS-1 Carrier Routing Systems - Overview

Next Generation Core

2005 Cisco Systems, Inc.

Cisco CRS-1 Carrier Routing System

Market Place Demands

Cisco CRS-1 Essentials

Market Place Demands

IP PoP Evolution - Scaling

Historically, scaling a PoP is always a problem

2005 Cisco Systems, Inc.

Cisco CRS-1 Carrier Routing System

Current PoP Design