Cisco CRS
Content
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 That’s 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
v
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
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0
vii
viii
Version 2.0
Cisco CRS-1 Essentials
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 student’s 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
student’s 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
© 2005 Cisco Systems, Inc.
Version 2.0
ix
x
•
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
Cisco CRS-1 Essentials
Contents
Course Overview.....................................................................................................................v
Course Agenda..................................................................................................................... vii
Course Introduction and Objectives ................................................................ ix
Overview ................................................................................................................................ix
Module 1 .......................................................................................................... 1–1
Overview .............................................................................................................................1–1
Cisco CRS-1 Carrier Routing Systems..............................................................................1–2
Market Place Demands ......................................................................................................1–4
Current PoP Design............................................................................................................1–6
Getting the CRS-1 into the Network.................................................................................1–8
Cisco CRS-1 System Configurations ...............................................................................1–12
Cisco CRS-1 Line Card Chassis.......................................................................................1–16
Cisco CRS-1 Interfaces.....................................................................................................1–18
Summary...........................................................................................................................1–20
Module 2 .......................................................................................................... 2–1
Overview .............................................................................................................................2–1
CRS-1 16-Slot Line Card Chassis......................................................................................2–2
CRS-1 16-Slot Line Card Chassis Components................................................................2–4
CRS-1 16-Slot Line Card Chassis Slot Numbering ........................................................2–10
CRS-1 16-Slot Line Card Chassis Power System ...........................................................2–12
CRS-1 16-Slot Line Card Chassis AC Power Shelves and Rectifiers............................2–22
CRS-1 16-Slot Line Card Chassis DC Power System ....................................................2–30
CRS-1 16-Slot Line Card Chassis Alarm Module...........................................................2–42
CRS-1 16-Slot Chassis Line Card Chassis Cooling System...........................................2–48
CRS-1 16-Slot Chassis Single Line Card Switch Fabric................................................2–66
CRS-1 16-Slot Chassis S123 Switch Fabric Card...........................................................2–68
CRS-1 16-Slot Chassis Route Processor (RP) .................................................................2–74
Summary...........................................................................................................................2–88
© 2005 Cisco Systems, Inc.
Version 2.0
xi
Module 3 .......................................................................................................... 3–1
Overview .............................................................................................................................3–1
CRS-1 8-Slot Line Card Chassis........................................................................................3–2
CRS-1 8-Slot Line Card Chassis Components..................................................................3–4
CRS-1 8-Slot Line Card Chassis Slot Numbering ..........................................................3–10
CRS-1 8-Slot Line Card Chassis Power System .............................................................3–12
CRS-1 8-Slot AC Power System.......................................................................................3–18
CRS-1 8-Slot DC Power System ......................................................................................3–26
CRS-1 8-Slot Line Card Chassis Cooling System...........................................................3–32
CRS-1 8-Slot Line Card Chassis Switch Fabric .............................................................3–44
CRS-1 8-Slot Line Card Chassis Route Processor..........................................................3–50
Summary...........................................................................................................................3–62
Module 4 .......................................................................................................... 4–1
Overview .............................................................................................................................4–1
Modular Services Card.......................................................................................................4–2
DRP Architecture - LC Chassis .........................................................................................4–6
Physical Layer Module (PLIM)..........................................................................................4–8
Shared Port Adapters (SPAs) and SPA Interface Processor-800 (SIP-800) .................4–36
SIP Bandwidth Oversubscription....................................................................................4–44
4-Port OC-3c/STM-1 SPA.................................................................................................4–49
1-Port OC-192c/STM-64 PoS/RPR XFP SPA ..................................................................4–53
8-Port Gigabit Ethernet SPA ...........................................................................................4–57
Summary...........................................................................................................................4–61
Module 5 .......................................................................................................... 5–1
Overview .............................................................................................................................5–1
Switch Fabric Chassis ........................................................................................................5–2
Switch Fabric Components ................................................................................................5–6
System Configurations .......................................................................................................5–8
Switch Fabric Chassis Interconnections .........................................................................5–12
In-service upgrade from Standalone to Multi-Shelf.......................................................5–16
CRS-1 Management System Control Plane and Shelf Controller Gigabit Ethernet (SCGE) card ............................................................................................................................5–18
Summary...........................................................................................................................5–22
Module 6 .......................................................................................................... 6–1
Overview .............................................................................................................................6–1
xii
Version 2.0
Cisco CRS-1 Essentials
Cisco IOS XR Architecture.................................................................................................6–2
High Availability ................................................................................................................6–4
Scalability .........................................................................................................................6–24
Configuration Operations ................................................................................................6–36
Configuration Basics ........................................................................................................6–44
Summary...........................................................................................................................6–68
Module 7 .......................................................................................................... 7–1
Overview .............................................................................................................................7–1
Cisco IOS XR Command Modes.........................................................................................7–2
Configuration Operations ................................................................................................7–14
Miscellaneous CLI Commands ........................................................................................7–52
Process Management........................................................................................................7–62
Summary...........................................................................................................................7–72
Module 8 .......................................................................................................... 8–1
Overview .............................................................................................................................8–1
Cisco IOS XR Software Packaging ....................................................................................8–2
Package Management ......................................................................................................8–20
Software Installation Review...........................................................................................8–36
Summary...........................................................................................................................8–46
Module 9 .......................................................................................................... 9–1
Overview .............................................................................................................................9–1
Cisco IOS XR Security Overview.......................................................................................9–2
Cisco IOS XR Security Implementation..........................................................................9–10
Security Configuration .....................................................................................................9–42
Access Control Lists .........................................................................................................9–58
Summary...........................................................................................................................9–70
Module 10 ...................................................................................................... 10–1
Overview ...........................................................................................................................10–1
Border Gateway Protocol (BGP) ......................................................................................10–2
Open Shortest Path First (OSPF) .................................................................................10–28
Intermediate System-Intermediate System (IS-IS) .....................................................10–48
Multicast Routing ...........................................................................................................10–62
Summary.........................................................................................................................10–74
© 2005 Cisco Systems, Inc.
Version 2.0
xiii
Module 11 ...................................................................................................... 11–1
Overview ...........................................................................................................................11–1
RPL Overview ...................................................................................................................11–2
RPL Description..............................................................................................................11–12
BGP Route Attributes and Operations .........................................................................11–48
Converting Route Maps to RPL Policies .......................................................................11–78
RPL-Specific CLI Commands ......................................................................................11–102
Summary.......................................................................................................................11–110
Module 12 ...................................................................................................... 12–1
Overview ...........................................................................................................................12–1
MPLS Forwarding Infrastructure ...................................................................................12–2
Label Distribution Protocol............................................................................................12–16
MPLS Traffic Engineering .............................................................................................12–34
Summary.........................................................................................................................12–68
Module 13 ...................................................................................................... 13–1
Overview ...........................................................................................................................13–1
CWI Overview...................................................................................................................13–2
Desktop Applications......................................................................................................13–24
Router Configuration .....................................................................................................13–36
Graphical Configuration Applications ..........................................................................13–46
Getting Started ...............................................................................................................13–66
Summary.........................................................................................................................13–78
Module 14 ...................................................................................................... 14–1
Overview ...........................................................................................................................14–1
CRS-1 QoS Hardware Components.................................................................................14–2
Life of a Packet .................................................................................................................14–4
IngressQ queuing and shaping ......................................................................................14–26
EgressQ queuing and shaping .......................................................................................14–28
Switch Fabric Cell Structure .........................................................................................14–30
Worst Case Fabric Cell Loading ....................................................................................14–34
Switch Fabric Architecture ............................................................................................14–36
Switch Fabric Features ..................................................................................................14–40
Modular QoS Command-Line Interface ........................................................................14–44
Summary.........................................................................................................................14–60
xiv
Version 2.0
Cisco CRS-1 Essentials
Append A
A–1
Troubleshooting
A-1
Appendix B ..................................................................................................... B–1
Student Evaluation ........................................................................................ B–1
© 2005 Cisco Systems, Inc.
Version 2.0
xv
xvi
Version 2.0
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0
1–1
Cisco CRS-1 Carrier Routing System
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.
1–2
Version 2.0b
Cisco CRS-1 Essentials
Module 1
Cisco CRS-1 Carrier Routing Systems
Cisco CRS-1 Carrier Routing Systems - Overview
Next Generation Core
CRS-1
© 2005 Cisco Systems, Inc.
• 40 Gbps routing
• Multishelf scale
• Foundation for core
consolidation
Version 2.0b
1–3
Cisco CRS-1 Carrier Routing System
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 provider’s 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.
1–4
Version 2.0b
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0b
1–5
Cisco CRS-1 Carrier Routing System
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.
1–6
Version 2.0b
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0b
1–7
Cisco CRS-1 Carrier Routing System
Module 1
Getting the CRS-1 into the Network
Core Layer Insertion
The CRS-1 allows the replacement of multiple platforms in today’s 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.
1–8
Version 2.0b
Cisco CRS-1 Essentials
Module 1
Getting the CRS-1 into the Network
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
© 2005 Cisco Systems, Inc.
Version 2.0b
1–9
Cisco CRS-1 Carrier Routing System
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 PoP’s
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.
1–10
Version 2.0b
Cisco CRS-1 Essentials
Module 1
Getting the CRS-1 into the Network
Core Layer Consolidation
STM-64/256
Core
10GE/STM-16/64DPT
STM-256 Ch DS-3
CRS-1
5 Logical Router
partitions
Distribution
Aggregation
© 2005 Cisco Systems, Inc.
STM-4/16 DPT
1G/10GE
GSR120/124xx
CAT6K
Version 2.0b
1GE/10GE
STM-4/16
1–11
Cisco CRS-1 Carrier Routing System
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 Router—up to 6 line card chassis and one SFC, with support
for up to 96 MSCs
12 – 23 Terabit Router—up to 18 line card chassis and two SFC, with
support for up to 288 MSCs
23 – 46 Terabit Router—up to 36 line card chassis and 4 SFC, with support
for up to 576 MSCs
46 – 92 Terabit Router—up to 72 line card chassis and 8 SFC, with support
for up to 1152 MSCs
1–12
Version 2.0b
Cisco CRS-1 Essentials
Module 1
Cisco CRS-1 System Configurations
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
© 2005 Cisco Systems, Inc.
Version 2.0b
1–13
Cisco CRS-1 Carrier Routing System
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.
1–14
Version 2.0b
Cisco CRS-1 Essentials
Module 1
Cisco CRS-1 System Configurations
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
© 2005 Cisco Systems, Inc.
Version 2.0b
1–15
Cisco CRS-1 Carrier Routing System
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.
1–16
Version 2.0b
Cisco CRS-1 Essentials
Module 1
Cisco CRS-1 Line Card Chassis
Cisco CRS-1 Line Card Chassis
CRS-1 16-slot
CRS-1 8-slot
© 2005 Cisco Systems, Inc.
Version 2.0b
1–17
Cisco CRS-1 Carrier Routing System
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
•
1-port OC-768c/STM-256c POS/DPT
•
8-port 10 Gigabit Ethernet
SIP & SPAs
•
1–18
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
Cisco CRS-1 Essentials
Module 1
Cisco CRS-1 Interfaces
Cisco CRS-1 Cards
• PLIMs
− 16-port OC-48c/STM-16c POS/DPT
− 4-port OC-192c/STM-64c POS/DPT
− 1-port OC-768c/STM-256c POS/DPT
− 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
© 2005 Cisco Systems, Inc.
Version 2.0b
1–19
Cisco CRS-1 Carrier Routing System
Module 1
Summary
Cisco IOS XR Hardware and Platform Overview
In this module, you learned the following:
1–20
•
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
Cisco CRS-1 Essentials
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
After completing this module, you will be able to do the following:
•
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
•
List and describe the features and functions of the CRS-1 16-slot line
card chassis alarm modules
•
List and describe the features and functions of the CRS-1 16-slot line
card chassis cooling system
•
List and describe the features and functions of the CRS-1 16-slot line
card chassis switch fabric
•
List and describe the features and functions of the CRS-1 16-slot line
card chassis Route Processor
© 2005 Cisco Systems, Inc.
Version 2.0b
2–1
CRS-1 16-Slot Line Card Chassis Hardware
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:
2–2
•
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
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
© 2005 Cisco Systems, Inc.
Version 2.0b
2–3
CRS-1 16-Slot Line Card Chassis Hardware
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 chassis—this 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.
2–4
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Line Card Chassis Components
Components – PLIM Side
1
2
3
4
5
© 2005 Cisco Systems, Inc.
Version 2.0b
2–5
CRS-1 16-Slot Line Card Chassis Hardware
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
2–6
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Line Card Chassis Components
MSC Side
1
2
3
4
5
6
© 2005 Cisco Systems, Inc.
Version 2.0b
2–7
CRS-1 16-Slot Line Card Chassis Hardware
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.
2–8
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Line Card Chassis Components
Cable Management
Cable-management bracket has telescoping feature
that allows bracket to be extended when chassis is
upgraded with higher-density cards.
Cablemanagement
© 2005 Cisco Systems, Inc.
Version 2.0b
2–9
CRS-1 16-Slot Line Card Chassis Hardware
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).
2–10
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Line Card Chassis Slot Numbering
CRS-1 16-Slot Line Card Chassis Slot Numbering
© 2005 Cisco Systems, Inc.
Version 2.0b
2–11
CRS-1 16-Slot Line Card Chassis Hardware
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:
2–12
•
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
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Line Card Chassis Power System
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 OR’ing
diodes or EMI filters
© 2005 Cisco Systems, Inc.
Version 2.0b
2–13
CRS-1 16-Slot Line Card Chassis Hardware
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 bar—an integral part of the
chassis—fails
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.
2–14
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Line Card Chassis Power System
Power Architecture
Power system architecture provides fully redundant AC or DC
power
Line card chassis still operates normally if:
• One AC rectifier or DC PEM fails
• 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
© 2005 Cisco Systems, Inc.
Version 2.0b
2–15
CRS-1 16-Slot Line Card Chassis Hardware
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.
2–16
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Line Card Chassis Power System
Power Distribution
© 2005 Cisco Systems, Inc.
Version 2.0b
2–17
CRS-1 16-Slot Line Card Chassis Hardware
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:
2–18
•
Power module A0 powers load zones 1 and 2 (Z1 and Z2)
•
Power module A1 powers load zones 3 and 4 (Z3 and Z4)
•
Power module A2 powers load zones 5 and 6 (Z5 and Z6)
•
Power module B0 powers load zones 1 and 2 (Z1 and Z2)
•
Power module B1 powers load zones 3 and 4 (Z3 and Z4)
•
Power module B2 powers load zones 5 and 6 (Z5 and Z6)
•
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
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Line Card Chassis Power System
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)
© 2005 Cisco Systems, Inc.
Version 2.0b
2–19
CRS-1 16-Slot Line Card Chassis Hardware
Module 2
Line Card Chassis Load Zones
The Line Card Chassis contains six load zones as follows:
2–20
•
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 3 (Z3) powers chassis slots 4, 5, 6, and 7
•
Load zone 4 (Z4) powers chassis slots 8, 9, 10, and 11
•
Load zone 5 (Z5) powers chassis slots FC1, RP0 (PLIM side) and SM4,
SM5, SM6 and SM7 (MSC side)
•
Load zone 6 (Z6) powers chassis slots 12, 13, 14, and 15
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Line Card Chassis Power System
Line Card Chassis Load Zones
© 2005 Cisco Systems, Inc.
Version 2.0b
2–21
CRS-1 16-Slot Line Card Chassis Hardware
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.
2–22
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Line Card Chassis AC Power Shelves and Rectifiers
CRS-1 16-Slot Line Card Chassis AC Power Shelves and Rectifiers
AC Power
Shelf
© 2005 Cisco Systems, Inc.
AC Rectifiers
Version 2.0b
2–23
CRS-1 16-Slot Line Card Chassis Hardware
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.
_________________________________________________________________
2–24
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Line Card Chassis AC Power Shelves and Rectifiers
AC Power Architecture
© 2005 Cisco Systems, Inc.
Version 2.0b
2–25
CRS-1 16-Slot Line Card Chassis Hardware
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:
•
Fault—A 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 Fail—Indicates that the AC input voltage is out of range.
•
Circuit Breaker Trip—Indicates that the AC rectifier circuit breaker
has tripped.
•
Over temperature—Indicates that the AC rectifier has exceeded the
maximum allowable operating temperature.
•
AC Rectifier Present—Indicates 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.
2–26
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Line Card Chassis AC Power Shelves and Rectifiers
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
© 2005 Cisco Systems, Inc.
Version 2.0b
2–27
CRS-1 16-Slot Line Card Chassis Hardware
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.
2–28
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Line Card Chassis AC Power Shelves and Rectifiers
AC Rectifier Status Indicators
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
© 2005 Cisco Systems, Inc.
Version 2.0b
2–29
CRS-1 16-Slot Line Card Chassis Hardware
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.
2–30
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Line Card Chassis DC Power System
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
© 2005 Cisco Systems, Inc.
Version 2.0b
2–31
CRS-1 16-Slot Line Card Chassis Hardware
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.
2–32
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Line Card Chassis DC Power System
DC Power Shelf Input Connectors
Grnd
© 2005 Cisco Systems, Inc.
6 Input Connectors
Version 2.0b
2–33
CRS-1 16-Slot Line Card Chassis Hardware
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.
2–34
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Line Card Chassis DC Power System
DC Power Shelf Architecture
© 2005 Cisco Systems, Inc.
Version 2.0b
2–35
CRS-1 16-Slot Line Card Chassis Hardware
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:
2–36
•
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
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Line Card Chassis DC Power System
DC PEM
LEDs
© 2005 Cisco Systems, Inc.
Version 2.0b
2–37
CRS-1 16-Slot Line Card Chassis Hardware
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:
•
Fault—Summarizes 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 Fail—Indicates that the PEM DC input voltage is out of
range.
•
Circuit Breaker Trip—Indicates that the PEM circuit breaker has
tripped.
•
Over temperature—Indicates that the PEM has exceeded the
maximum allowable operating temperature.
•
PEM Present—Indicates 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.
2–38
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Line Card Chassis DC Power System
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
© 2005 Cisco Systems, Inc.
Version 2.0b
2–39
CRS-1 16-Slot Line Card Chassis Hardware
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.
2–40
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Line Card Chassis DC Power System
DC PEM Status Indicators
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
© 2005 Cisco Systems, Inc.
Version 2.0b
2–41
CRS-1 16-Slot Line Card Chassis Hardware
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).
2–42
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Line Card Chassis Alarm Module
CRS-1 16-Slot Line Card Chassis Alarm Module
Ext.
Alarm
connector
LED
Indicators
Alpha
Indicators
© 2005 Cisco Systems, Inc.
Version 2.0b
2–43
CRS-1 16-Slot Line Card Chassis Hardware
Module 2
Alarm Module Functions
The alarm module provides the following:
•
•
Alarm outputs, both relay and LEDs:
−
LEDs—Three 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.
−
Alpha—Display will show the chassis ID
−
Relay—The 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
−
2–44
The maximum rating for the alarm circuit is 2A, 50V
•
PEM or AC Rectifier status monitoring
•
Alarm monitoring
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Line Card Chassis Alarm Module
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
© 2005 Cisco Systems, Inc.
Version 2.0b
2–45
CRS-1 16-Slot Line Card Chassis Hardware
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.
2–46
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Line Card Chassis Alarm Module
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
© 2005 Cisco Systems, Inc.
Version 2.0b
2–47
CRS-1 16-Slot Line Card Chassis Hardware
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:
2–48
•
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
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Chassis Line Card Chassis Cooling System
CRS-1 16-Slot Chassis Line card Chassis cooling System - Overview
The complete line card chassis cooling system
includes:
• 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
© 2005 Cisco Systems, Inc.
Version 2.0b
2–49
CRS-1 16-Slot Line Card Chassis Hardware
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.
2–50
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Chassis Line Card Chassis Cooling System
Line Card Chassis Airflow
© 2005 Cisco Systems, Inc.
Version 2.0b
2–51
CRS-1 16-Slot Line Card Chassis Hardware
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
−
Two fan controller cards
−
Control software and logic
There are four normal operating fan-speeds, plus one high-speed setting
used when a fan tray has failed.
2–52
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Chassis Line Card Chassis Cooling System
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
− Two fan controller cards
− Control software and logic
There are four normal operating fan-speeds, plus one high-speed
setting used when a fan tray has failed.
© 2005 Cisco Systems, Inc.
Version 2.0b
2–53
CRS-1 16-Slot Line Card Chassis Hardware
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:
2–54
•
Nine fans—Each 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 board—The board terminates signals to and from the fans,
filters common mode noise, and houses tracking and indicator parts.
•
A front-panel status LED—The LED indicates the following:
−
Green—The fan tray is operating normally
−
Yellow—The fan tray has experienced a failure and should be
replaced
−
Off—An unknown state exists or the LED is faulty
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Chassis Line Card Chassis Cooling System
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
© 2005 Cisco Systems, Inc.
Version 2.0b
2–55
CRS-1 16-Slot Line Card Chassis Hardware
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:
2–56
•
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
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Chassis Line Card Chassis Cooling System
Line Card Chassis Fan Controller Card
BITs/SETs
Ext. Clk 1
BITs/SETs
Ext. Clk 2
Status
LEDs
© 2005 Cisco Systems, Inc.
Version 2.0b
2–57
CRS-1 16-Slot Line Card Chassis Hardware
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.
2–58
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Chassis Line Card Chassis Cooling System
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
© 2005 Cisco Systems, Inc.
Version 2.0b
2–59
CRS-1 16-Slot Line Card Chassis Hardware
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.
2–60
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Chassis Line Card Chassis Cooling System
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
© 2005 Cisco Systems, Inc.
Version 2.0b
2–61
CRS-1 16-Slot Line Card Chassis Hardware
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.
2–62
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Chassis Line Card Chassis Cooling System
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
© 2005 Cisco Systems, Inc.
Version 2.0b
2–63
CRS-1 16-Slot Line Card Chassis Hardware
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.
2–64
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Chassis Line Card Chassis Cooling System
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
© 2005 Cisco Systems, Inc.
Version 2.0b
2–65
CRS-1 16-Slot Line Card Chassis Hardware
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.
2–66
Version 2.0b
Cisco CRS-1 Router Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0b
2–67
CRS-1 16-Slot Line Card Chassis Hardware
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.
2–68
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Chassis S123 Switch Fabric Card
CRS-1 16-Slot Chassis S123 Switch Fabric Card
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.
© 2005 Cisco Systems, Inc.
Version 2.0b
2–69
CRS-1 16-Slot Line Card Chassis Hardware
Module 2
S123 Functional Blocks
The functional blocks of the S123 switch fabric card are:
1. S1 switch element—Receives 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 element—Receives 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 element—Receives data cells from the S2 stage and performs
switching and fabric speedup.
4. Service processor—Provides 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 modules—Take –48 VDC input power from the midplane and
converts it into the voltages required by the switch fabric card’s
components.
6. Alphanumeric display—Displays S123 switch fabric card messages.
This display is under software control.
7. Status LED—Indicates status of the S123 switch fabric card. Green
indicates module OK.
2–70
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Chassis S123 Switch Fabric Card
S123 Functional Blocks
3
2
1
Slots 0-7
Egress
Ingress
from
MSCs
To
MSCs and
RPS
Slots 8-17
(To fabric)
(From
Fabric)
4
5
6
7
Note: Slots 16 & 17 are the active and standby RPs
© 2005 Cisco Systems, Inc.
Version 2.0b
2–71
CRS-1 16-Slot Line Card Chassis Hardware
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:
2–72
•
A board “OK” LED
•
An alphanumeric display
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Chassis S123 Switch Fabric Card
S123 Physical Overview
Alpha
Status
LED
© 2005 Cisco Systems, Inc.
Version 2.0b
2–73
CRS-1 16-Slot Line Card Chassis Hardware
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:
2–74
•
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
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Chassis Route Processor (RP)
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
© 2005 Cisco Systems, Inc.
Version 2.0b
2–75
CRS-1 16-Slot Line Card Chassis Hardware
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
2–76
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Chassis Route Processor (RP)
CRS-1 16-Slot Chassis RP Front Panel and Memory Options
SMP
CPUs
Memory
Modules
© 2005 Cisco Systems, Inc.
Version 2.0b
2–77
CRS-1 16-Slot Line Card Chassis Hardware
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.
2–78
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Chassis Route Processor (RP)
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
© 2005 Cisco Systems, Inc.
Version 2.0b
2–79
CRS-1 16-Slot Line Card Chassis Hardware
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.
2–80
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Chassis Route Processor (RP)
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
© 2005 Cisco Systems, Inc.
Version 2.0b
2–81
CRS-1 16-Slot Line Card Chassis Hardware
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 RP’s 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.
2–82
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Chassis Route Processor (RP)
Block Diagram
LC FE
links
CTL GE link
FE/GE
switch
4
CTL GE link
2
PCI
9
7
Q
links
To
fabric
From
fabric
1
CPU
MEM
IF
CTL
5
CPU
IDE
PCMCIA
2
6
8
Aux and console
Management GE link
FPGA
Midplane
© 2005 Cisco Systems, Inc.
3
Card presence detect
RP mastership
PROM presence
10
Version 2.0b
2–83
CRS-1 16-Slot Line Card Chassis Hardware
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.
2–84
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Chassis Route Processor (RP)
Block Diagram (Cont.)
LC FE
links
CTL GE link
FE/GE
switch
4
CTL GE link
2
PCI
9
7
Q
links
To
fabric
From
fabric
1
CPU
MEM
IF
CTL
5
CPU
IDE
PCMCIA
2
6
8
Aux and console
Management GE link
FPGA
Midplane
© 2005 Cisco Systems, Inc.
3
Card presence detect
RP mastership
PROM presence
10
Version 2.0b
2–85
CRS-1 16-Slot Line Card Chassis Hardware
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.
2–86
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Chassis Route Processor (RP)
Route Processor (RP) Active and Standby Arbitration
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.
5. Software on each reads its “Active” signal, and branches accordingly to
“Primary” or “Standby” code.
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.
© 2005 Cisco Systems, Inc.
Version 2.0b
2–87
CRS-1 16-Slot Line Card Chassis Hardware
Module 2
Summary
CRS-1 16-Slot Line Card Chassis Hardware
In this module, you learned the following:
2–88
•
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
components that comprise the CRS-1 16-slot Line Card chassis
•
To list and describe the features and functions of the CRS-1 16-slot line
card chassis power system
•
To list and describe the features and functions of the CRS-1 16-slot line
card chassis alarm modules
•
To list and describe the features and functions of the CRS-1 16-slot line
card chassis cooling system
•
To list and describe the features and functions of the CRS-1 16-slot line
card chassis Switch Fabric
•
To list and describe the features and functions of the CRS-1 16-slot line
card chassis Route Processor
Version 2.0b
Cisco CRS-1 Router Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Hardware
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
After completing this module, you will be able to do the following:
•
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
components that comprise the CRS-1 8-slot Line Card chassis
•
List and describe the features and functions of the CRS-1 8-slot line
card chassis power system
•
List and describe the features and functions of the CRS-1 8-slot line
card chassis Switch Fabric
•
List and describe the features and functions of the CRS-1 8-slot line
card chassis cooling system
•
List and describe the features and functions of the CRS-1 8-slot line
card chassis Route Processor
© 2005 Cisco Systems, Inc.
Version 2.0b
3–1
CRS-1 8-Slot Line Card Chassis Hardware
Module 3
CRS-1 8-Slot Line Card Chassis
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
3–2
•
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
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
© 2005 Cisco Systems, Inc.
Version 2.0b
3–3
CRS-1 8-Slot Line Card Chassis Hardware
Module 3
CRS-1 8-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 chassis—this 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.
3–4
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Components
CRS-1 8-Slot Line Card Chassis Components - PLIM Side
© 2005 Cisco Systems, Inc.
Version 2.0b
3–5
CRS-1 8-Slot Line Card Chassis Hardware
Module 3
MSC Side
The MSC side of the chassis is considered the rear of the chassis—this 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.
3–6
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Components
MSC Side
© 2005 Cisco Systems, Inc.
Version 2.0b
3–7
CRS-1 8-Slot Line Card Chassis Hardware
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.
3–8
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Components
Cable Management
Cable-management bracket has telescoping feature
that allows bracket to be extended when chassis is
upgraded with higher-density cards.
© 2005 Cisco Systems, Inc.
Version 2.0b
3–9
CRS-1 8-Slot Line Card Chassis Hardware
Module 3
CRS-1 8-Slot Line Card Chassis Slot Numbering
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).
3–10
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Slot Numbering
CRS-1 8-Slot Line Card Chassis Slot Numbering
Front
© 2005 Cisco Systems, Inc.
Rear
Version 2.0b
3–11
CRS-1 8-Slot Line Card Chassis Hardware
Module 3
CRS-1 8-Slot Line Card Chassis Power System
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.
3–12
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Power System
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
© 2005 Cisco Systems, Inc.
Version 2.0b
3–13
CRS-1 8-Slot Line Card Chassis Hardware
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 AC rectifier or DC PEM fails
•
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.
3–14
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Power System
Power Architecture
© 2005 Cisco Systems, Inc.
Version 2.0b
3–15
CRS-1 8-Slot Line Card Chassis Hardware
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
3–16
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Power System
Chassis Load Zones
© 2005 Cisco Systems, Inc.
Version 2.0b
3–17
CRS-1 8-Slot Line Card Chassis Hardware
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 PDUs—Contain 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:
−
3–18
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
CRS-1 8-Slot AC Power System - Overview
Provides:
• 7.5 kW (Delta or Wye 3-phase) of power to
chassis
• Two AC PDUs—two independent AC power
sources required
• Two AC Rectifiers—Converts 200- to- 240 VAC to
54.5 VDC
− Each rectifier has:
♦ its own circuit breaker
♦ cooling fan
© 2005 Cisco Systems, Inc.
Version 2.0b
3–19
CRS-1 8-Slot Line Card Chassis Hardware
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 voltage—3-phase 200-240 VAC (nominal) range 170 to 264
VAC, phase-to-phase
−
Line frequency—50 to 60 Hz, range 47 to 63Hz
−
Recommended AC service—30 A (plugs into L15-30R receptacle)
AC Input, Wye 3-phase
−
3W+N+PE (3 wire plus neutral plus protective earthing)
−
Input voltage—3-phase 200-240 VAC (nominal)
♦ Range 170 to 264 VAC, phase-to-neutral
♦ Range 295 to 457 VAC, phase-to-phase
−
Line frequency—50 to 60 Hz, range 47 to 63Hz
−
Recommended AC service:
♦ 20 A North America (plugs into IEC 60309 receptacle)
♦ 16 A International
3–20
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot AC Power System
Power Redundancy
AC Input, Delta 3-phase
• 3W+PE (3 wire plus protective earthing)
• Input voltage—3-phase 200-240 VAC (nominal) range 170 to 264 VAC,
phase-to-phase
• Line frequency—50 to 60 Hz, range 47 to 63Hz
• Recommended AC service—30 A (plugs into L15-30R receptacle)
AC Input, Wye 3-phase
• 3W+N+PE (3 wire plus neutral plus protective earthing)
• Input voltage—3-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
• Line frequency—50 to 60 Hz, range 47 to 63Hz
© 2005 Cisco Systems, Inc.
Version 2.0b
3–21
CRS-1 8-Slot Line Card Chassis Hardware
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.
3–22
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot AC Power System
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
© 2005 Cisco Systems, Inc.
Version 2.0b
3–23
CRS-1 8-Slot Line Card Chassis Hardware
Module 3
AC Rectifier Status Indicators
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:
•
Fault—Indicates 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 Fail—Indicates that the AC input voltage is out of range.
•
Circuit Breaker Trip—Indicates that the AC rectifier circuit breaker
has tripped.
•
Over temperature—Indicates that the AC rectifier has exceeded the
maximum allowable operating temperature.
•
AC Rectifier Present—Indicates 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.
3–24
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot AC Power System
AC Rectifier Status Indicators
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
© 2005 Cisco Systems, Inc.
Version 2.0b
3–25
CRS-1 8-Slot Line Card Chassis Hardware
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.
3–26
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot DC Power System
DC Power Distribution Unit (PDU)
Each DC PDU requires three independent
nominal – 48 VDC or – 60 VDC/60 A input
services.
© 2005 Cisco Systems, Inc.
Version 2.0b
3–27
CRS-1 8-Slot Line Card Chassis Hardware
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.
3–28
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot DC Power System
DC Power Entry Module
2 DC PEMs required per chassis, 1 per PDU
Each PEM provides 7500 WATTs of power
© 2005 Cisco Systems, Inc.
Version 2.0b
3–29
CRS-1 8-Slot Line Card Chassis Hardware
Module 3
DC PEM Status Indicators
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
maximum allowable operating temperature.
•
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.
3–30
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot DC Power System
DC PEM Status Indicators
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
© 2005 Cisco Systems, Inc.
Version 2.0b
3–31
CRS-1 8-Slot Line Card Chassis Hardware
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)
•
Control software and logic
•
An air filter, inlet and outlet air vents, and bezels
•
Impedance carriers for empty chassis slots
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)
3–32
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Cooling System
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
© 2005 Cisco Systems, Inc.
Version 2.0b
3–33
CRS-1 8-Slot Line Card Chassis Hardware
Module 3
Line Card Chassis Airflow
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 airflow—Up to 900 cubic feet (25,485 liters) per minute
•
Power system airflow—Up 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.
3–34
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Cooling System
Line Card Chassis Airflow & Air Filter
Fan Trays
Air Filter
Air Intake
Air Exhaust
PDU
PLIM Side
(Front)
© 2005 Cisco Systems, Inc.
MSC Side
(Rear)
Version 2.0b
3–35
CRS-1 8-Slot Line Card Chassis Hardware
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.
_________________________________________________________________
3–36
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Cooling System
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
© 2005 Cisco Systems, Inc.
Version 2.0b
3–37
CRS-1 8-Slot Line Card Chassis Hardware
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.
3–38
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Cooling System
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
© 2005 Cisco Systems, Inc.
Version 2.0b
3–39
CRS-1 8-Slot Line Card Chassis Hardware
Module 3
Cooling System Redundancy
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.
_________________________________________________________________
3–40
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Cooling System
Cooling System Redundancy
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
© 2005 Cisco Systems, Inc.
Version 2.0b
3–41
CRS-1 8-Slot Line Card Chassis Hardware
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:
3–42
•
Four fans—Each 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 board—The board terminates signals to and from the fans,
filters common-mode noise, and contains tracking and indicator parts.
•
A front-panel status LED—The LED indicates the following:
−
Green—The fan tray is operating normally.
−
Yellow—The fan tray has experienced a failure and should be
replaced.
−
Off—An unknown state exists or the LED is faulty.
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Cooling System
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
© 2005 Cisco Systems, Inc.
Version 2.0b
3–43
CRS-1 8-Slot Line Card Chassis Hardware
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.
3–44
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Switch Fabric
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
© 2005 Cisco Systems, Inc.
Version 2.0b
3–45
CRS-1 8-Slot Line Card Chassis Hardware
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:
3–46
•
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
CRS-1 8-Slot Line Card Chassis Switch Fabric
Operation
© 2005 Cisco Systems, Inc.
Version 2.0b
3–47
CRS-1 8-Slot Line Card Chassis Hardware
Module 3
SFC Functional Block Diagram
The major functional blocks of the HS123 switch fabric card are:
3–48
•
S1 switch element—Receives 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 element—Receives 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 element—Receives data cells from the S2 stage and performs
switching and fabric speed-up. S3 has 36 inputs and 72 outputs.
•
Service processor—Provides 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 modules—Take –48V DC input power from the midplane and
convert it to the voltages required by the components on the switch
fabric card.
•
Alphanumeric display—Displays HS123 switch fabric card messages.
•
Status LED—Indicates status of the HS123 switch fabric card.
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Switch Fabric
SFC Functional Block Diagram
© 2005 Cisco Systems, Inc.
Version 2.0b
3–49
CRS-1 8-Slot Line Card Chassis Hardware
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 redundancy—one is active, and
the other is standby. An RP card can be inserted in either of the two
dedicated slots in the chassis.
3–50
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Route Processor
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
© 2005 Cisco Systems, Inc.
Version 2.0b
3–51
CRS-1 8-Slot Line Card Chassis Hardware
Module 3
RP Components
3–52
•
Hard drive―An 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.
•
Memory―Resides in a SIMM module on the RP card. The RP can be
configured with 2 or 4 GB of memory.
•
PCMCIA Subsystems―Two 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.
•
CPU―Performs 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 modules―Two small form-factor pluggable (SFP) modules support
external Gigabit Ethernet connections for multi-chassis systems.
•
RJ45 Ethernet port―An RJ45 10/100/1000 copper Ethernet port is
available for providing connectivity to network management systems.
•
Fast Ethernet Midplane Connector―Internal 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
CRS-1 8-Slot Line Card Chassis Route Processor
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
© 2005 Cisco Systems, Inc.
Version 2.0b
3–53
CRS-1 8-Slot Line Card Chassis Hardware
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
3–54
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Route Processor
RP Front Panel
CPU
Memory
© 2005 Cisco Systems, Inc.
Version 2.0b
3–55
CRS-1 8-Slot Line Card Chassis Hardware
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 RP’s 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.
3–56
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Route Processor
Block Diagram
LC FE
links
CTL GE link
FE/GE
switch
4
CTL GE link
2
PCI
9
7
Q
links
To
fabric
From
fabric
1
CPU
MEM
IF
CTL
5
CPU
IDE
PCMCIA
2
6
8
Aux and console
Management GE link
FPGA
Midplane
© 2005 Cisco Systems, Inc.
3
Card presence detect
RP mastership
PROM presence
10
Version 2.0b
3–57
CRS-1 8-Slot Line Card Chassis Hardware
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.
3–58
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Route Processor
Block Diagram (Cont.)
LC FE
links
CTL GE link
FE/GE
switch
4
CTL GE link
2
PCI
9
7
Q
links
To
fabric
From
fabric
1
CPU
MEM
IF
CTL
5
CPU
IDE
PCMCIA
2
6
8
Aux and console
Management GE link
FPGA
Midplane
© 2005 Cisco Systems, Inc.
3
Card presence detect
RP mastership
PROM presence
10
Version 2.0b
3–59
CRS-1 8-Slot Line Card Chassis Hardware
Module 3
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.
3–60
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Route Processor
Route Processor (RP) Active and Standby Arbitration
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.
5. Software on each reads its “Active” signal, and branches accordingly to
“Primary” or “Standby” code.
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.
© 2005 Cisco Systems, Inc.
Version 2.0b
3–61
CRS-1 8-Slot Line Card Chassis Hardware
Module 3
Summary
CRS-1 8-Slot Line Card Chassis Hardware
In this module, you learned the following:
3–62
•
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
components that comprise the CRS-1 8-slot Line Card chassis
•
To list and describe the features and functions of the CRS-1 8-slot line
card chassis power system
•
To list and describe the features and functions of the CRS-1 8-slot line
card chassis Switch Fabric
•
To list and describe the features and functions of the CRS-1 8-slot line
card chassis cooling system
•
To list and describe the features and functions of the CRS-1 8-slot line
card chassis Route Processor
Version 2.0b
CRS-1 Essentials
Module 3
Review Questions
CRS-1 8-Slot Line Card Chassis Hardware
1. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
2. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
3. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
4. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
5. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
© 2005 Cisco Systems, Inc.
Version 2.0b
3–63
CRS-1 8-Slot Line Card Chassis Hardware
Module 3
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
3–64
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
After completing this module, you will be able to do the following:
•
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
© 2005 Cisco Systems, Inc.
Version 2.0b
4–1
CRS-1 Line Card Chassis Common Elements
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.
4–2
Version 2.0b
CRS-1 Essentials
Module 4
Modular Services Card
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
© 2005 Cisco Systems, Inc.
Version 2.0b
4–3
CRS-1 Line Card Chassis Common Elements
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.
4–4
Version 2.0b
CRS-1 Essentials
Module 4
Modular Services Card
MSC Hardware Components
Power
Regulators
EgressQ
2*FabricQ
Egress
PSE
SP
CPU
Ingress
PSE
© 2005 Cisco Systems, Inc.
Version 2.0b
IngressQ
4–5
CRS-1 Line Card Chassis Common Elements
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.
4–6
Version 2.0b
CRS-1 Essentials
Module 4
DRP Architecture - LC Chassis
DRP Architecture - LC Chassis
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
© 2005 Cisco Systems, Inc.
Version 2.0b
FLASH
FLASH
4–7
CRS-1 Line Card Chassis Common Elements
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.
4–8
Version 2.0b
CRS-1 Essentials
Module 4
Physical Layer Module (PLIM)
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
© 2005 Cisco Systems, Inc.
Version 2.0b
4–9
CRS-1 Line Card Chassis Common Elements
Module 4
PLIM Physical Characteristics
All POS and POS/DPT PLIMs have the following physical characteristics:
4–10
•
Height—20.6 in. (52.3 cm)
•
Depth—11.2 in. (28.5 cm)
•
Width—1.8 in. (4.6 cm)
•
Weight—7.8 to 8.6 lb (3.5 to 3.9 kg), see individual PLIM descriptions
•
Power consumption—65 to 150 W, see individual PLIM descriptions
Version 2.0b
CRS-1 Essentials
Module 4
Physical Layer Module (PLIM)
PLIM Physical Characteristics
• Height—20.6 in. (52.3 cm)
• Depth—11.2 in. (28.5 cm)
• Width—1.8 in. (4.65 cm)
• Weight—7.8 to 8.6 lb. (3.5
to 3.9 kg)
• Power Consumption—65
to 150 Watts
© 2005 Cisco Systems, Inc.
Version 2.0b
4–11
CRS-1 Line Card Chassis Common Elements
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.
4–12
•
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
Physical Layer Module (PLIM)
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
© 2005 Cisco Systems, Inc.
Version 2.0b
4–13
CRS-1 Line Card Chassis Common Elements
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.
_________________________________________________________________
4–14
Version 2.0b
CRS-1 Essentials
Module 4
Physical Layer Module (PLIM)
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
© 2005 Cisco Systems, Inc.
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
4–15
CRS-1 Line Card Chassis Common Elements
Module 4
PoS and PoS/DPT PLIM Features
Each PoS/DPT PLIM provides:
4–16
•
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
Physical Layer Module (PLIM)
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
© 2005 Cisco Systems, Inc.
Version 2.0b
4–17
CRS-1 Line Card Chassis Common Elements
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 module—Provides 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.
•
Framer—Provides processing and termination for SONET/SDH section,
line, and path layers, including alarm processing and automatic
protection switching (APS) support.
•
Physical interface controller—Provides data packet buffering and Layer
2 processing, including processing for VLANs and back-pressure signals
from the MSC.
•
Additional components—Include 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.
4–18
Version 2.0b
CRS-1 Essentials
Module 4
Physical Layer Module (PLIM)
OC768c PLIM HW Architecture
EgressQ
M
i
d
p
l
a
n
e
PLA768
Framer
RX PSE
MSC
© 2005 Cisco Systems, Inc.
1xOC768 PLIM
Version 2.0b
4–19
CRS-1 Line Card Chassis Common Elements
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:
•
−
ACTIVE—Indicates that the port is logically active; the laser is on
−
CARRIER—Indicates 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 PKT—Blinks 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
_________________________________________________________________
4–20
Version 2.0b
CRS-1 Essentials
Module 4
Physical Layer Module (PLIM)
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:
−
−
−
ACTIVE—Indicates that the port is logically active; the laser is on
CARRIER—Indicates 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 PKT—Blinks 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
• Power consumption is 65 W
© 2005 Cisco Systems, Inc.
Version 2.0b
4–21
CRS-1 Line Card Chassis Common Elements
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 modules—Provide 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
•
Framers—Provide 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.
•
Physical interface controller—Provides data packet buffering and Layer
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 components—Provides 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 components—Provide 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.
4–22
Version 2.0b
CRS-1 Essentials
Module 4
Physical Layer Module (PLIM)
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
© 2005 Cisco Systems, Inc.
Framer 0
PLA 0
EgressQ
Rx PSE
RAC0
4xoc192 PLIM
Version 2.0b
4–23
CRS-1 Line Card Chassis Common Elements
Module 4
4 - Port OC-192c PLIM Faceplates
The 4-port OC-192 PLIM has:
4–24
•
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 LED—Green 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/FAILURE—Indicates that the port is logically active; the
laser is on.
−
CARRIER—Indicates that the receive port (RX) is receiving a
carrier signal.
−
RX PKT—Blinks every time a packet is received.
−
WRAP—Indicates that the port is in DPT wrapped mode.
−
PASS THRU—Indicates that the port is operating in the POS mode
(DPT pass through).
•
Two DPT MODE LEDs—One 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
Physical Layer Module (PLIM)
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 LED—Green 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/FAILURE—Indicates port is logically active; laser is on
CARRIER—Indicates receive port (RX) is receiving a carrier signal
RX PKT—Blinks every time a packet is received
WRAP—Indicates port is in DPT wrapped mode
PASS THRU—Indicates port is operating in POS mode (DPT pass through)
−
DPT mode is always configured on pairs of ports
• Two DPT MODE LEDs—One DPT MODE LED is for ports 0 and 1, and other for ports 2 and 3
• Power consumption: 138 Watts
© 2005 Cisco Systems, Inc.
Version 2.0b
4–25
CRS-1 Line Card Chassis Common Elements
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 modules—Provide 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.
•
Framers—Provides 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 components—Provides 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.
•
Physical interface controller—Provides data packet buffering and Layer
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 components—Provides 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.
4–26
Version 2.0b
CRS-1 Essentials
Module 4
Physical Layer Module (PLIM)
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
© 2005 Cisco Systems, Inc.
RAC12
Version 2.0b
4–27
CRS-1 Line Card Chassis Common Elements
Module 4
16 - Port OC-48c PLIM Faceplate
The 16-port OC-48 PLIM has:
•
Sixteen slots for SFP optic modules, which provide SR or LR optics with
LC fiber-optic interfaces.
•
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
•
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. 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):
•
4–28
−
−
ACTIVE/FAILURE—Indicates that the port is logically active; the
laser is on.
−
CARRIER—Indicates that the receive port (RX) is receiving a
carrier signal.
−
RX PKT—Blinks every time a packet is received.
−
WRAP—Indicates that the port is in DPT wrapped mode.
−
PASS THRU—Indicates that the port is operating in the POS mode
(DPT pass through).
Power consumption: 136 Watts
Version 2.0b
CRS-1 Essentials
Module 4
Physical Layer Module (PLIM)
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/FAILURE—Indicates port is logically active; laser is on
CARRIER—Indicates receive port (RX) is receiving a carrier signal
RX PKT—Blinks every time a packet is received
WRAP—Indicates port is in DPT wrapped mode
PASS THRU—Indicates port is operating in POS mode (DPT pass through)
• Five green LEDs for each port
• Power consumption 136 Watts
© 2005 Cisco Systems, Inc.
Version 2.0b
4–29
CRS-1 Line Card Chassis Common Elements
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:
4–30
•
Optic modules—Provides 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 controller—Provides 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 components—Include 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
Physical Layer Module (PLIM)
10 – Port 10GE PLIM HW Architecture
PLA 0
EgressQ
M
i
d
p
l
a
n
e
Rx PSE
PLA 1
Line card
© 2005 Cisco Systems, Inc.
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
4–31
CRS-1 Line Card Chassis Common Elements
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
−
Slots 0 and 1, and 6 and 7
−
Slots 2 and 3, and 4 and 5
−
Slots 2 and 3, and 6 and 7
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.
4–32
Version 2.0b
CRS-1 Essentials
Module 4
Physical Layer Module (PLIM)
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
• Adding another module in port 2 causes oversubscription on all of the
interfaces (0, 1, and 2)
• Guidelines for avoiding oversubscription:
−
−
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
Slots 0 and 1, and 6 and 7
Slots 2 and 3, and 4 and 5
Slots 2 and 3, and 6 and 7
• 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
© 2005 Cisco Systems, Inc.
Version 2.0b
4–33
CRS-1 Line Card Chassis Common Elements
Module 4
10 – Port 10GE PLIM Faceplate
The 8-port 10-GE PLIM has:
4–34
•
Eight slots that accept XENPAK optic modules, which provide LR
optics with SC fiber-optic interfaces.
•
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
•
A LED for each port—Indicates that the port is logically active; the
laser is on
•
Power consumption—110 W (with 8 optic modules)
Version 2.0b
CRS-1 Essentials
Module 4
Physical Layer Module (PLIM)
10 – Port 10GE PLIM Faceplate
• Eight slots that accept XENPAK optic modules, which provide
LR optics with SC fiber-optic interfaces.
• 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
• A LED for each port—Indicates that the port is logically active;
the laser is on
• Power consumption—110 W (with 8 optic modules)
© 2005 Cisco Systems, Inc.
Version 2.0b
4–35
CRS-1 Line Card Chassis Common Elements
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:
4–36
•
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)
• If more than 2 optic modules are installed in either set of ports,
oversubscription occurs on all ports in that set
• Adding another module in port 2 causes oversubscription on all of the
interfaces (0, 1, and 2)
• Guidelines for avoiding oversubscription:
−
−
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
Slots 0 and 1, and 6 and 7
Slots 2 and 3, and 4 and 5
Slots 2 and 3, and 6 and 7
• 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
© 2005 Cisco Systems, Inc.
Version 2.0b
4–37
CRS-1 Line Card Chassis Common Elements
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.
4–38
Version 2.0b
CRS-1 Essentials
Module 4
Shared Port Adapters (SPAs) and SPA Interface Processor-800 (SIP-800)
SPA Slot Numbering on the Cisco CRS-1 SIP-800
© 2005 Cisco Systems, Inc.
Version 2.0b
4–39
CRS-1 Line Card Chassis Common Elements
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 SPA—Inserts into one SIP subslot.
−
Double-height SPA—Inserts 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:
4–40
•
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 (SPAs) and SPA Interface Processor-800 (SIP-800)
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)
© 2005 Cisco Systems, Inc.
Version 2.0b
4–41
CRS-1 Line Card Chassis Common Elements
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:
•
rack—Specifies the rack number, 0 in a single-chassis system.
•
slot—Specifies the slot number in the Cisco CRS-1 in which the SIP that contains
the SPA is installed:
•
−
For the 8-slot line card chassis—0 through 7
−
For the 16-slot line card chassis—0 through 15
subslot—Specifies the secondary slot on the SIP where the SPA that you want to
select is installed:
−
•
For the Cisco CRS-1 SIP-800—0 through 5
port—Specifies the interface number that you want to select on the SPA:
−
For the 4-Port OC-3c/STM-1 PoS SPA—0 through 3
−
For the 1-Port OC-192c/STM-64 PoS/RPR XFP SPA—0 is the only
option.
−
For the 8-Port Gigabit Ethernet SPA—0 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.
4–42
Version 2.0b
CRS-1 Essentials
Module 4
Shared Port Adapters (SPAs) and SPA Interface Processor-800 (SIP-800)
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.
© 2005 Cisco Systems, Inc.
Version 2.0b
4–43
CRS-1 Line Card Chassis Common Elements
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.
4–44
Version 2.0b
CRS-1 Essentials
Module 4
SIP Bandwidth Oversubscription
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
© 2005 Cisco Systems, Inc.
SIP-800 Jacket Card
Per-Port
Bandwidth
Number of Ports
Total Bandwidth
155.52 Mbps
4
622.08 Mbps
10Gbbps
1
10Gbps
1Gbps
8
8 Gbps
Version 2.0b
4–45
CRS-1 Line Card Chassis Common Elements
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
−
•
4–46
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
SIP Bandwidth Oversubscription
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
8-Port Gigabit Ethernet SPA
♦ SFP-GE-S
♦ SFP-GE-L
♦ SFP-GE-Z
© 2005 Cisco Systems, Inc.
Version 2.0b
4–47
CRS-1 Line Card Chassis Common Elements
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 1155–1157) and RFC 1213:
4–48
•
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 SPA
4-Port OC-3c/STM-1 SPA
•
•
•
•
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:
− RFC 1619, PPP over SONET/SDH
− RFC 1662, PPP in HDLC-like Framing
• SPA also provides support for SNMP v1 agent (RFC 1155–1157) and RFC 1213
© 2005 Cisco Systems, Inc.
Version 2.0b
4–49
CRS-1 Line Card Chassis Common Elements
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.
4–50
Version 2.0b
CRS-1 Essentials
Module 4
4-Port OC-3c/STM-1 SPA
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
© 2005 Cisco Systems, Inc.
Meaning
Version 2.0b
4–51
CRS-1 Line Card Chassis Common Elements
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 Spécifications
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 1619, PPP over SONET/SDH
•
RFC 1662, PPP in HDLC-like Framing
•
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 1155–1157) and RFC 1213:
4–52
•
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
1-Port OC-192c/STM-64 PoS/RPR XFP SPA
1-Port OC-192c/STM-64 PoS/RPR XFP SPA
• 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:
−
−
−
RFC 1619, PPP over SONET/SDH
RFC 1662, PPP in HDLC-like Framing
RFC 2615, PPP over SONET/SDH
• 1-Port OC-192c/STM-64 POS/RPR XFP SPA supports SNMP v1 agent (RFC 1155–1157) and RFC
1213
© 2005 Cisco Systems, Inc.
Version 2.0b
4–53
CRS-1 Line Card Chassis Common Elements
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.
_________________________________________________________________
4–54
Version 2.0b
CRS-1 Essentials
Module 4
1-Port OC-192c/STM-64 PoS/RPR XFP SPA
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
SPA is ready and operational
Amber
On
SPA power is on and good; SPA is being configured
© 2005 Cisco Systems, Inc.
Version 2.0b
4–55
CRS-1 Line Card Chassis Common Elements
Module 4
8-Port Gigabit Ethernet SPA
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.
4–56
Version 2.0b
CRS-1 Essentials
Module 4
8-Port Gigabit Ethernet SPA
8-Port Gigabit Ethernet SPA
• 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
© 2005 Cisco Systems, Inc.
Version 2.0b
4–57
CRS-1 Line Card Chassis Common Elements
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.
4–58
Version 2.0b
CRS-1 Essentials
Module 4
8-Port Gigabit Ethernet SPA
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
SPA is ready and operational
STATUS
© 2005 Cisco Systems, Inc.
Meaning
Version 2.0b
4–59
CRS-1 Line Card Chassis Common Elements
Module 4
Summary
CRS-1 Line Card Chassis Common Elements
In this module, you learned the following:
4–60
•
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
CRS-1 Line Card Chassis Common Elements
1. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
2. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
3. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
4. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
5. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
© 2005 Cisco Systems, Inc.
Version 2.0b
4–61
CRS-1 Line Card Chassis Common Elements
Module 4
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
4–62
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
After completing this module, you will be able to do the following:
•
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
© 2005 Cisco Systems, Inc.
Version 2.0b
5–1
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
5–2
Version 2.0b
Cisco CRS-1 Router Essentials
Module 5
Switch Fabric Chassis
Switch Fabric Chassis - Front
© 2005 Cisco Systems, Inc.
Version 2.0b
5–3
Introduction to Cisco CRS-1 Multi-Shelf Architecture
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.
5–4
Version 2.0b
Cisco CRS-1 Router Essentials
Module 5
Switch Fabric Chassis
Switch Fabric Chassis – Rear View
© 2005 Cisco Systems, Inc.
Version 2.0b
5–5
Introduction to Cisco CRS-1 Multi-Shelf Architecture
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.
5–6
Version 2.0b
Cisco CRS-1 Router Essentials
Module 5
Switch Fabric Components
Switch Fabric Components
• Switch Fabric Cards (SFCs)
• Optical Interface Modules (OIMs)
• Shelf Controller Gigabit Ethernet Card (SC-GE)
• Fan Tray Assemblies
• Alarm Modules
• AC/DC Power
© 2005 Cisco Systems, Inc.
Version 2.0b
5–7
Introduction to Cisco CRS-1 Multi-Shelf Architecture
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 Router—18 line card chassis and two switch fabric chassis. This
system supports up to 288 MSCs.
46 Terabit Router—36 line card chassis and 4 switch fabric chassis
supports up to 576 MSCs.
92 Terabit Router—72 line card chassis and 8 switch fabric chassis
supports up to 1152 MSCs.
5–8
Version 2.0b
Cisco CRS-1 Router Essentials
Module 5
System Configurations
System Configurations
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
© 2005 Cisco Systems, Inc.
Version 2.0b
5–9
Introduction to Cisco CRS-1 Multi-Shelf Architecture
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.
5–10
Version 2.0b
Cisco CRS-1 Router Essentials
Module 5
System Configurations
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
2
up to 18
288
23 Tbps
4
up to 36
576
46 Tbps
8
up to 72
1152
92 Tbps
© 2005 Cisco Systems, Inc.
Version 2.0b
5–11
Introduction to Cisco CRS-1 Multi-Shelf Architecture
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.
_________________________________________________________________
5–12
Version 2.0b
Cisco CRS-1 Router Essentials
Module 5
Switch Fabric Chassis Interconnections
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
© 2005 Cisco Systems, Inc.
Version 2.0b
5–13
Introduction to Cisco CRS-1 Multi-Shelf Architecture
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
5–14
•
9 bundle connections per fabric card
•
24 fabric cards
•
216 bundles or connections
Version 2.0b
Cisco CRS-1 Router Essentials
Module 5
Switch Fabric Chassis Interconnections
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:
• 3 bundle connections per fabric card
• 8 fabric cards
• 24 bundles or connections
Connections per Fabric Card Chassis
Multiple Bundles
Between LC Chassis
And FC Chassis
• 9 bundle connections / fabric card
• 24 fabric cards
• 216 bundles or connections
Optical Interface Modules
© 2005 Cisco Systems, Inc.
Version 2.0b
Full Utilized Fabric Chassis
5–15
Introduction to Cisco CRS-1 Multi-Shelf Architecture
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
5–16
Version 2.0b
Cisco CRS-1 Router Essentials
Module 5
In-service upgrade from Standalone to Multi-Shelf
In-service upgrade from Standalone to Multi-Shelf
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
© 2005 Cisco Systems, Inc.
Version 2.0b
5–17
Introduction to Cisco CRS-1 Multi-Shelf Architecture
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.
_________________________________________________________________
5–18
Version 2.0b
Cisco CRS-1 Router Essentials
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
© 2005 Cisco Systems, Inc.
SC-GE
Version 2.0b
S2
5–19
Introduction to Cisco CRS-1 Multi-Shelf Architecture
Module 5
Shelf Controller Gigabit Ethernet Card (SC-GE)
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:
5–20
•
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
Cisco CRS-1 Router Essentials
Module 5
card
CRS-1 Management System Control Plane and Shelf Controller Gigabit Ethernet (SC-GE)
Shelf Controller Gigabit Ethernet Card (SC-GE)
LC FE
Links
B
A
C
K
P
L
A
N
E
© 2005 Cisco Systems, Inc.
CTL GE link
CTL GE link
FE/GE
Switch
PCI
IDE
CPU
MEM
CTL
Aux & Console
Mgmt GE link
FLASH
Version 2.0b
FLASH
5–21
Introduction to Cisco CRS-1 Multi-Shelf Architecture
Module 5
Summary
Introduction to Cisco CRS-1 Multi-Shelf Architecture
In this module, you learned the following:
5–22
•
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
Cisco CRS-1 Router Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0b
6–1
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.
6–2
Version 2.0b
Cisco CRS-1 Essentials
Module 6
Cisco IOS XR Architecture
Cisco IOS XR Architecture
Routing
modules
(BGP, OSPF)
Runs on
multiple
CPU’s
Protocol
modules
(IP)
Application
modules
Distributed infrastructure
Cisco IOS XR kernel
© 2005 Cisco Systems, Inc.
Version 2.0b
6–3
Cisco IOS XR Overview and Initial Configuration
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
6–4
•
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
Cisco CRS-1 Essentials
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.
© 2005 Cisco Systems, Inc.
Version 2.0b
6–5
Cisco IOS XR Overview and Initial Configuration
Module 6
Kernel
The QNX Neutrino microkernel has these main features:
•
Multiprocessor
•
Small memory footprint
•
Memory protection
•
Preemptive fast context switch times
•
Reliability–independent 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.
6–6
Version 2.0b
Cisco CRS-1 Essentials
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
C
Synchronization
O
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.
© 2005 Cisco Systems, Inc.
Version 2.0b
6–7
Cisco IOS XR Overview and Initial Configuration
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:
•
Control—Distributes routing tasks and management of the Routing
Information Base (RIB) in participating RPs; different routing
processes can be running on different physical units
•
Data—Maintains the Forwarding Information Base (FIB) changes
across the participating nodes letting the router perform as a single
forwarding entity
•
Management—Controls 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.
6–8
Version 2.0b
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
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
l
H/W abstraction
System services
Memory-protected microkernel
6–9
Cisco IOS XR Overview and Initial Configuration
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.
6–10
Version 2.0b
Cisco CRS-1 Essentials
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….
© 2005 Cisco Systems, Inc.
Version 2.0b
6–11
Cisco IOS XR Overview and Initial Configuration
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.
6–12
Version 2.0b
Cisco CRS-1 Essentials
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.
© 2005 Cisco Systems, Inc.
Version 2.0b
6–13
Cisco IOS XR Overview and Initial Configuration
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.
_________________________________________________________________
6–14
Version 2.0b
Cisco CRS-1 Essentials
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.
© 2005 Cisco Systems, Inc.
Version 2.0b
6–15
Cisco IOS XR Overview and Initial Configuration
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
6–16
Version 2.0b
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0b
6–17
Cisco IOS XR Overview and Initial Configuration
Module 6
Process Restart and Recovery—RP Failure
There are a variety of ways of restarting or recovering a process when the
active RP fails; here are some examples:
6–18
Process
Checkpoint data status
A
Sent to the standby card continuously; process A' is
running in the background
B
Mirrored to the standby card; process B' is not running;
this process uses a checkpoint proxy process to receive
checkpoint information
C
No checkpointing of data; process C' can start on the
standby card without saved state information
D
No checkpointing of data; no process running on the
standby card
Version 2.0b
Cisco CRS-1 Essentials
Module 6
High Availability
Process Restart and Recovery—RP Failure
Active card
Standby card
Process A´
Process A
1
1
Process B´
Process B
2
Process C
3
Process D
4
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
© 2005 Cisco Systems, Inc.
Version 2.0b
Process C ´
6–19
Cisco IOS XR Overview and Initial Configuration
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.
6–20
Version 2.0b
Cisco CRS-1 Essentials
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.
© 2005 Cisco Systems, Inc.
Version 2.0b
6–21
Cisco IOS XR Overview and Initial Configuration
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.
6–22
Version 2.0b
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0b
6–23
Cisco IOS XR Overview and Initial Configuration
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
6–24
•
Adjacency management
•
Forwarding Information Base tables
•
Distributed interface management
•
Distributed configuration management
•
Two-stage forwarding
Version 2.0b
Cisco CRS-1 Essentials
Module 6
Scalability
Scalability Features
• Adjacency management
• Forwarding Information Base tables
• Distributed interface management
• Distributed configuration management
• Two-stage forwarding
© 2005 Cisco Systems, Inc.
Version 2.0b
6–25
Cisco IOS XR Overview and Initial Configuration
Module 6
Adjacency Management
An adjacency is a mapping of the next-hop’s 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.
6–26
Version 2.0b
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0b
6–27
Cisco IOS XR Overview and Initial Configuration
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.
6–28
Version 2.0b
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0b
6–29
Cisco IOS XR Overview and Initial Configuration
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.
6–30
Version 2.0b
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0b
6–31
Cisco IOS XR Overview and Initial Configuration
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.
6–32
Version 2.0b
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Interfaces
Version 2.0b
6–33
Cisco IOS XR Overview and Initial Configuration
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.
6–34
Version 2.0b
Cisco CRS-1 Essentials
Module 6
Scalability
Distributed Configuration Management
RP
Configuration manager
MSC
MSC
Configuration manager
Configuration manager
L2/L3
applications and
H/W drivers
L2/L3
applications and
H/W drivers
Hardware
Hardware
© 2005 Cisco Systems, Inc.
Version 2.0b
6–35
Cisco IOS XR Overview and Initial Configuration
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.
6–36
Version 2.0b
Cisco CRS-1 Essentials
Module 6
Configuration Operations
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
Instructor’s Note
This slide is animated in 2 steps.
Click 1 shows all stage 1 elements
Click 2 shows all stage 2 elements
© 2005 Cisco Systems, Inc.
Version 2.0b
6–37
Cisco IOS XR Overview and Initial Configuration
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.
_________________________________________________________________
6–38
Version 2.0b
Cisco CRS-1 Essentials
Module 6
Configuration Operations
Configuration File System
New binary
configuration
created; router uses
it to boot up
following reload
IOS XR
© 2005 Cisco Systems, Inc.
Running config
plus changes
Version 2.0b
RP “disk0:”
6–39
Cisco IOS XR Overview and Initial Configuration
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.
6–40
Version 2.0b
Cisco CRS-1 Essentials
Module 6
Configuration Operations
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
© 2005 Cisco Systems, Inc.
Version 2.0b
6–41
Cisco IOS XR Overview and Initial Configuration
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.
6–42
•
EXEC mode—Logging 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 mode—Configuration 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
Cisco CRS-1 Essentials
Module 6
Configuration Operations
Command Modes
Login
EXEC mode
Configuration modes
© 2005 Cisco Systems, Inc.
Version 2.0b
6–43
Cisco IOS XR Overview and Initial Configuration
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.
6–44
Version 2.0b
Cisco CRS-1 Essentials
Module 6
Configuration Basics
Management IP Interfaces
• Cisco CRS-1 Management
Ethernet interfaces
− MgmtEth0/RP0/CPU0/0
− MgmtEth0/RP1/CPU0/0
Management
network
connections
© 2005 Cisco Systems, Inc.
Version 2.0b
6–45
Cisco IOS XR Overview and Initial Configuration
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.
_________________________________________________________________
6–46
Version 2.0b
Cisco CRS-1 Essentials
Module 6
Configuration Basics
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
© 2005 Cisco Systems, Inc.
Version 2.0b
6–47
Cisco IOS XR Overview and Initial Configuration
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.
6–48
Version 2.0b
Cisco CRS-1 Essentials
Module 6
Configuration Basics
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
© 2005 Cisco Systems, Inc.
Version 2.0b
6–49
Cisco IOS XR Overview and Initial Configuration
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.
6–50
Version 2.0b
Cisco CRS-1 Essentials
Module 6
Configuration Basics
Configuring Loopback Address
RP/0/RP0/CPU0:router(config)#interface loopback0 12.9.42.110/16
RP/0/RP0/CPU0:router(config-if)#
• Interface command
• Assign IP address
• Visible as interface
© 2005 Cisco Systems, Inc.
Version 2.0b
6–51
Cisco IOS XR Overview and Initial Configuration
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.
_________________________________________________________________
6–52
Version 2.0b
Cisco CRS-1 Essentials
Module 6
Configuration Basics
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
© 2005 Cisco Systems, Inc.
Version 2.0b
6–53
Cisco IOS XR Overview and Initial Configuration
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.
6–54
Version 2.0b
Cisco CRS-1 Essentials
Module 6
Configuration Basics
Hostname
RP/0/RP0/CPU0:router(config)#hostname P1
RP/0/RP0/CPU0:router(config)#
• Create a hostname
© 2005 Cisco Systems, Inc.
Version 2.0b
6–55
Cisco IOS XR Overview and Initial Configuration
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
6–56
Version 2.0b
Cisco CRS-1 Essentials
Module 6
Configuration Basics
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
RP/0/RP0/CPU0:router(config-if)#
• Set clock source first
− Controller
• Interface command
− Rack/slot/module/port
− Assign IP address
− Activate the interface
© 2005 Cisco Systems, Inc.
Version 2.0b
6–57
Cisco IOS XR Overview and Initial Configuration
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.
6–58
Version 2.0b
Cisco CRS-1 Essentials
Module 6
Configuration Basics
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
© 2005 Cisco Systems, Inc.
Version 2.0b
6–59
Cisco IOS XR Overview and Initial Configuration
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.
6–60
Version 2.0b
Cisco CRS-1 Essentials
Module 6
Configuration Basics
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
© 2005 Cisco Systems, Inc.
Version 2.0b
6–61
Cisco IOS XR Overview and Initial Configuration
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:
•
interface—displays the interfaces
•
router protocol—displays the routing protocol specified
•
username—displays the users configured
These and other parameters are available to minimize the amount of
information you display, particularly with a large router configuration.
6–62
Version 2.0b
Cisco CRS-1 Essentials
Module 6
Configuration Basics
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
!
interface POS0/4/0/1
ipv4 address 142.50.16.5 255.255.255.0
Additional messages are not shown
end
• Display entire running configuration
• Display by like groups (Interfaces, routing protocols)
© 2005 Cisco Systems, Inc.
Version 2.0b
6–63
Cisco IOS XR Overview and Initial Configuration
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.
_________________________________________________________________
6–64
Version 2.0b
Cisco CRS-1 Essentials
Module 6
Configuration Basics
Display the Target Configuration
RP/0/RP0/CPU0:P1(config)#show config
Building configuration...
interface POS0/4/0/3
ipv4 address 142.50.48.5 255.255.255.0
!
interface POS0/5/0/1
ipv4 address 142.50.36.5 255.255.255.0
pos
crc 16
!
!
end
© 2005 Cisco Systems, Inc.
Version 2.0b
6–65
Cisco IOS XR Overview and Initial Configuration
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.
6–66
Version 2.0b
Cisco CRS-1 Essentials
Module 6
Configuration Basics
Display the Merged Configuration
RP/0/RP0/CPU0:P1(config)#show config merge
Building configuration...
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
!
interface POS0/4/0/1
ipv4 address 142.50.16.5 255.255.255.0
Additional messages are not shown
interface POS0/4/0/3
ipv4 address 142.50.48.5 255.255.255.0
!
interface POS0/5/0/1
ipv4 address 142.50.36.5 255.255.255.0
pos
crc 16
!
!
end
© 2005 Cisco Systems, Inc.
Version 2.0b
Added
6–67
Cisco IOS XR Overview and Initial Configuration
Module 6
Summary
Cisco IOS XR Overview
In this module, you learned to:
6–68
•
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
Cisco CRS-1 Essentials
Module 6
Review Questions
Cisco IOS XR Overview and Initial Configuration
1. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
2. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
3. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
4. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
5. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
© 2005 Cisco Systems, Inc.
Version 2.0b
6–69
Cisco IOS XR Overview and Initial Configuration
Module 6
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
6–70
Version 2.0b
Cisco CRS-1 Essentials
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
After completing this module, you will be able to:
•
Describe command modes
•
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
© 2005 Cisco Systems, Inc.
Version 2.0b
7–1
Cisco IOS XR Operations
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.
7–2
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Cisco IOS XR Command Modes
Cisco IOS XR Command Modes
Login
EXEC mode
Admin EXEC mode
Configuration modes
Admin configuration mode
© 2005 Cisco Systems, Inc.
Version 2.0b
7–3
Cisco IOS XR Operations
Module 7
Configuration Modes
•
Configuration mode—Configuration 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 submodes—From 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 submode—POS configuration submode is used to
configure such things as CRC and transmit-delay.
•
Router configuration submode—Router configuration submode is
used to select and configure a routing protocol, such as BGP, OSPF or
IS-IS.
−
•
7–4
Router submode configuration—Router 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
Cisco CRS-1 Essentials
Module 7
Cisco IOS XR Command Modes
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
© 2005 Cisco Systems, Inc.
Version 2.0b
7–5
Cisco IOS XR Operations
Module 7
Administration Modes
Administration mode is currently used to configure multiple logical routers
(LRs) and to install the Cisco IOS XR software.
7–6
•
Admin EXEC—Enter 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 configuration—Enter admin configuration (admin config)
mode from admin EXEC mode. This mode’s 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 configuration—To specify a logical router (LR) to be
provisioned and enter LR configuration mode
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Cisco IOS XR Command Modes
Administration Modes
Admin EXEC mode
Admin configuration mode
Logical router configuration
submode
• Software installations
• Logical router management
© 2005 Cisco Systems, Inc.
Version 2.0b
7–7
Cisco IOS XR Operations
Module 7
Command Mode Samples
Here are some sample illustrations of the prompt syntax and some
commands used to enter various modes.
7–8
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Cisco IOS XR Command Modes
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.
© 2005 Cisco Systems, Inc.
Version 2.0b
7–9
Cisco IOS XR Operations
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:
7–10
•
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
Cisco CRS-1 Essentials
Module 7
Cisco IOS XR Command Modes
Cisco CRS-1 Hardware Node Locations
Rack number
Slot = Physical
slot of card
Card Type
Module = CPU0 or SP
Rack
Slot
Module
Route processor
0—71
RP0/RP1
CPU0
Modular services card
0—71
0—15
CPU0, SP
Switch fabric module
0—71
SM0—SM7
SP
Alarm card
0—71
AM0—AM1
SP
Fan controller card
0—71
FC0—FC1
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.
© 2005 Cisco Systems, Inc.
Version 2.0b
7–11
Cisco IOS XR Operations
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:
7–12
•
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
Cisco CRS-1 Essentials
Module 7
Cisco IOS XR Command Modes
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
© 2005 Cisco Systems, Inc.
Management
network
connection
Version 2.0b
7–13
Cisco IOS XR Operations
Module 7
Configuration Operations
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.
7–14
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Configuration Operations
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
© 2005 Cisco Systems, Inc.
Version 2.0b
7–15
Cisco IOS XR Operations
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.
7–16
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Configuration Operations
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
RP/0/0/CPU0:P4(config)#
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.
© 2005 Cisco Systems, Inc.
Version 2.0b
7–17
Cisco IOS XR Operations
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 router’s 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.
7–18
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Configuration Operations
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
© 2005 Cisco Systems, Inc.
Version 2.0b
7–19
Cisco IOS XR Operations
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.
7–20
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Configuration Operations
Clear Target Configuration Changes
RP/0/0/CPU0:P4#configure
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
Building configuration...
interface POS0/5/0/1
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
Building configuration...
end
© 2005 Cisco Systems, Inc.
Version 2.0b
7–21
Cisco IOS XR Operations
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.
7–22
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Configuration Operations
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
Building configuration...
[OK]
RP/0/0/CPU0:P4(config-un)#
• Save target configuration commands to specific file
© 2005 Cisco Systems, Inc.
Version 2.0b
7–23
Cisco IOS XR Operations
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.
7–24
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Configuration Operations
Loading a Target Configuration Commands
RP/0/0/CPU0:P4(config)#show config
Building configuration...
end
RP/0/0/CPU0:P4(config)#load disk0:ed
Loading.
57 bytes parsed in 1 sec (56)bytes/sec
RP/0/0/CPU0:P4(config)#show config
Building configuration...
username ed
password 7 110C1D
group root-system
!
end
• File has been saved as a target configuration
• Loaded file becomes the target configuration
© 2005 Cisco Systems, Inc.
Version 2.0b
7–25
Cisco IOS XR Operations
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.
7–26
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Configuration Operations
Abort Configuration Mode
RP/0/0/CPU0:P4#configure
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
© 2005 Cisco Systems, Inc.
Version 2.0b
7–27
Cisco IOS XR Operations
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.
7–28
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Configuration Operations
Failed Configuration Commands
• Configuration commit entry fails
− View causes of failures
RP/0/0/CPU0:P4#config
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
!
RP/0/0/CPU0:P4(config)#
• Configuration commit entry fails
− View causes of failures
RP/0/0/CPU0:P4#config
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)#
© 2005 Cisco Systems, Inc.
Version 2.0b
7–29
Cisco IOS XR Operations
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).
7–30
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Configuration Operations
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
© 2005 Cisco Systems, Inc.
Version 2.0b
7–31
Cisco IOS XR Operations
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:
7–32
•
commit—Show what was committed in a particular commit
•
failed—Commands that failed in a commit
•
removed—Parts 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
•
rollback—When 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-config—Shows the same information as the command show
running-config, that is the configuration currently controlling the
resources of the router
•
sessions—Manage and deactivate configuration sessions
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Configuration Operations
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
© 2005 Cisco Systems, Inc.
Version 2.0b
7–33
Cisco IOS XR Operations
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:
•
SNo—Sequence number of the change list
•
Label/ID—Identifier assigned to this change
•
User—Logged on user who committed the changes
•
Line—Method used to connect to the router
•
Client—Tool used to make the changes
•
Time Stamp—Time 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
7–34
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Configuration Operations
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
© 2005 Cisco Systems, Inc.
Version 2.0b
7–35
Cisco IOS XR Operations
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
7–36
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Configuration Operations
Display Committed Changes
• Display specific committed changes
RRP/0/0/CPU0:P4#show config commit changes doug
Building configuration...
username doug
password 7 110D161010
!
end
RP/0/0/CPU0:P4#show config commit changes 1000000163
Building configuration...
username doug
password 7 110D161010
!
end
RP/0/0/CPU0:P4#show config commit changes 1000000167
Building configuration...
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
Building configuration...
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
Building configuration...
config-register 0x2
Prior change
username doug
group root-system
Previous change
group cisco-support
!
xml agent corba
http server
Last change
end
© 2005 Cisco Systems, Inc.
Version 2.0b
7–37
Cisco IOS XR Operations
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.
7–38
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Configuration Operations
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
Building configuration...
config-register 0x2
Change # 166
username doug
Change # 163/doug
password 7 110D161010
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
© 2005 Cisco Systems, Inc.
Version 2.0b
7–39
Cisco IOS XR Operations
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:
•
last—Followed by a number value
•
to—Followed by the Label/ID
Each of these keywords is inclusive.
7–40
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Configuration Operations
Display Rollback Information
RP/0/RP1/CPU0:P4#show config rollback changes last 1
Building configuration...
username doug
no group root-system
no group cisco-support
!
end
RP/0/RP1/CPU0:P4#show config rollback changes last 2
Building configuration...
config-register 0x0
username doug
no group root-system
no group cisco-support
!
end
RP/0/RP1/CPU0:P4#show config rollback changes last 3
Building configuration...
config-register 0x0
username doug
no group root-system
no group cisco-support
!
no redundancy disable
end
Previous
changes
would be
reversed
• Display rollback changes (inclusive)
RP/0/RP1/CPU0:P4#show config rollback changes to doug
Building configuration...
config-register 0x0
no username doug
username doug
no password
no group root-system
no group cisco-support
!
no username jeff
username jeff
no password
!
no redundancy disable
end
• Display inclusive changes back to a certain commit
change
© 2005 Cisco Systems, Inc.
Version 2.0b
7–41
Cisco IOS XR Operations
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.
7–42
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Configuration Operations
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.
6 items committed in 1 sec (5)items/sec
Updating.
Updated Commit database in 1 sec
Configuration successfully rolled back 3 commits.
• Roll back last number (n) of changes
© 2005 Cisco Systems, Inc.
Version 2.0b
7–43
Cisco IOS XR Operations
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.
7–44
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Configuration Operations
Load a Specific Configuration
RP/0/0/CPU0:P4(config)#load commit changes 1000000169
Building configuration...
Loading.
49 bytes parsed in 1 sec (48)bytes/sec
RP/0/0/CPU0:P4(config)#show config
Building configuration...
no username ken
username ken
!
end
RP/0/0/CPU0:P4(config)#commit
• Enter configuration mode
• Load a previously committed change
• Recommit the change
© 2005 Cisco Systems, Inc.
Version 2.0b
7–45
Cisco IOS XR Operations
Module 7
commit Command Keywords
The commit command offers additional keywords to document the
changes as they occur:
7–46
•
replace—Lets you replace an entire running configuration with the
target configuration
•
comment—Lets you add a comment that is displayed when looking at
committed change information
•
label—Lets you label a change, when committing it; the label is
displayed when viewing committed change information
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Configuration Operations
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>
© 2005 Cisco Systems, Inc.
Version 2.0b
7–47
Cisco IOS XR Operations
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.
_________________________________________________________________
7–48
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Configuration Operations
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
© 2005 Cisco Systems, Inc.
Version 2.0b
7–49
Cisco IOS XR Operations
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.
7–50
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Configuration Operations
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
© 2005 Cisco Systems, Inc.
Version 2.0b
7–51
Cisco IOS XR Operations
Module 7
Miscellaneous CLI Commands
Storage Media Review
Cisco CRS-1 System
The following storage media is located on the Cisco CRS-1 System:
7–52
•
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
Cisco CRS-1 Essentials
Module 7
Miscellaneous CLI Commands
Storage Media Review
• Cisco CRS-1 Router
− Disk0:
− Disk1: (optional)
− Harddisk:
− NVRAM:
− Bootflash:
© 2005 Cisco Systems, Inc.
Version 2.0b
7–53
Cisco IOS XR Operations
Module 7
File Commands
The Cisco IOS XR software has its own file system commands that closely
resemble standard UNIX commands, such as:
•
cd—Change directory
•
pwd—Present working directory
•
dir—Print 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.
7–54
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Miscellaneous CLI Commands
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
commitdb_info_1000000136.snf
commitdb_info_1000000137.snf
1024442368 bytes total (876019712 bytes free)
• Display directory contents
© 2005 Cisco Systems, Inc.
Version 2.0b
7–55
Cisco IOS XR Operations
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
no group root-system
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.
81 bytes parsed in 1 sec (80)bytes/sec
Committing.
5 items committed in 1 sec (4)items/sec
Updating.
Updated Commit database in 1 sec
RP/0/0/CPU0:P4#show run username
username ed
password 7 110C1D
group cisco-support
7–56
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Miscellaneous CLI Commands
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.
5286 bytes parsed in 1 sec (5259)bytes/sec
Committing.............
169 items committed in 13 sec (12)items/sec
Updating...
Updated Commit database in 3 sec
RP/0/0/CPU0:P4#
© 2005 Cisco Systems, Inc.
Version 2.0b
7–57
Cisco IOS XR Operations
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.
7–58
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Miscellaneous CLI Commands
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)
© 2005 Cisco Systems, Inc.
Version 2.0b
7–59
Cisco IOS XR Operations
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.
7–60
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Miscellaneous CLI Commands
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.”
© 2005 Cisco Systems, Inc.
Version 2.0b
7–61
Cisco IOS XR Operations
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.
7–62
Version 2.0b
Cisco CRS-1 Essentials
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.
© 2005 Cisco Systems, Inc.
Version 2.0b
7–63
Cisco IOS XR Operations
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:
7–64
•
Respawn—Restart the process, if a problem occurs with it
•
Respawn count—Number of times this process has restarted
•
Max. spawns per minute—When the maximum spawns is reached the
process will not be restarted automatically
•
Last started—When the last respawn took place. This could be the
result of a RP switchover or router reboot
•
Process state—State of the process when display was taken
Version 2.0b
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0b
7–65
Cisco IOS XR Operations
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.
7–66
Version 2.0b
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0b
7–67
Cisco IOS XR Operations
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.
7–68
Version 2.0b
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0b
7–69
Cisco IOS XR Operations
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.
_________________________________________________________________
7–70
Version 2.0b
Cisco CRS-1 Essentials
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
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: Killed (last exit status : 1)
Package state: Normal
Registered item(s): cfg/gl/ipv4-ospf/proc/
core: TEXT SHAREDMEM MAINMEM
Max. core: 0
Placement: ON
startup_path: /pkg/startup/ospf.startup
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
Executable path: /disk0/hfr-rout-3.2.81/bin/ospf
Instance #: 1
Version ID: 00.00.0000
Respawn: ON
Respawn count: 2
Max. spawns per minute: 12
Last started: Thu Mar 10 11:45:06 2005
Process state: Run (last exit status : 1)
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: 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
© 2005 Cisco Systems, Inc.
Version 2.0b
7–71
Cisco IOS XR Operations
Module 7
Summary
Cisco IOS XR Operations
In this module, you learned to:
7–72
•
Describe command modes
•
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
Cisco CRS-1 Essentials
Module 7
Review Questions
Cisco IOS XR Operations
1. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
2. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
3. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
4. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
5. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
© 2005 Cisco Systems, Inc.
Version 2.0b
7–73
Cisco IOS XR Operations
Module 7
c. <Insert Answer c>
d. <Insert Answer d>
7–74
Version 2.0b
Cisco CRS-1 Essentials
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
After completing this module, you will be able to:
•
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)
© 2005 Cisco Systems, Inc.
Version 2.0b
8–1
Cisco IOS XR Installation
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:
8–2
•
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
Cisco CRS-1 Essentials
Module 8
Cisco IOS XR Software Packaging
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.
© 2005 Cisco Systems, Inc.
Version 2.0b
8–3
Cisco IOS XR Installation
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.
_________________________________________________________________
8–4
Version 2.0b
Cisco CRS-1 Essentials
Module 8
Cisco IOS XR Software Packaging
Modular Packaging and Upgrades
RP
MSC or LC
DRP
Multicast
MPLS
Manageability
Security
MPLS
Multicast
Opt’l
Manageability
Opt'l
Security
MPLS
Opt’l
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
© 2005 Cisco Systems, Inc.
Version 2.0b
8–5
Cisco IOS XR Installation
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:
8–6
•
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
Cisco CRS-1 Essentials
Module 8
Cisco IOS XR Software Packaging
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.
© 2005 Cisco Systems, Inc.
Version 2.0b
8–7
Cisco IOS XR Installation
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.
8–8
Version 2.0b
Cisco CRS-1 Essentials
Module 8
Cisco IOS XR Software Packaging
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.
© 2005 Cisco Systems, Inc.
Version 2.0b
8–9
Cisco IOS XR Installation
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.
8–10
Version 2.0b
Cisco CRS-1 Essentials
Module 8
Cisco IOS XR Software Packaging
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 PIE’s will be new features as well as version upgrades, therefore they are
the most likely software installations they will do.
© 2005 Cisco Systems, Inc.
Version 2.0b
8–11
Cisco IOS XR Installation
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.
8–12
Version 2.0b
Cisco CRS-1 Essentials
Module 8
Cisco IOS XR Software Packaging
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!
© 2005 Cisco Systems, Inc.
Version 2.0b
8–13
Cisco IOS XR Installation
Module 8
Software Versions
Base Package Versions
Software package versions are identified by a three-part numeric scheme:
•
Major release—Contains 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 release—Contains 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 release—Contains 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>
8–14
Version 2.0b
Cisco CRS-1 Essentials
Module 8
Cisco IOS XR Software Packaging
Software Versions
Software delivery
type
Cisco CRS-1 Series Routers
Composite PIE
comp-platform-composite_name.piemajor.minor.maintenance
Single package
PIE
platform-package_type–p.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
© 2005 Cisco Systems, Inc.
Version 2.0b
8–15
Cisco IOS XR Installation
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.
8–16
Version 2.0b
Cisco CRS-1 Essentials
Module 8
Cisco IOS XR Software Packaging
Software Storage
CRS-1
Flash
disk1:
© 2005 Cisco Systems, Inc.
Version 2.0b
Flash
disk0:
internal
8–17
Cisco IOS XR Installation
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...
_________________________________________________________________
8–18
Version 2.0b
Cisco CRS-1 Essentials
Module 8
Cisco IOS XR Software Packaging
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
© 2005 Cisco Systems, Inc.
Version 2.0b
8–19
Cisco IOS XR Installation
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.
_________________________________________________________________
8–20
Version 2.0b
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0b
8–21
Cisco IOS XR Installation
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.
8–22
Version 2.0b
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0b
8–23
Cisco IOS XR Installation
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.
8–24
Version 2.0b
Cisco CRS-1 Essentials
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.
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 '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%] [OK]
Install 3: [ 1%] Checking API compatibility in software configurations...
Install 3: [ 1%] [OK]
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.
Additional messages are not shown
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.
© 2005 Cisco Systems, Inc.
Version 2.0b
8–25
Cisco IOS XR Installation
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.
8–26
Version 2.0b
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0b
8–27
Cisco IOS XR Installation
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.
8–28
Version 2.0b
Cisco CRS-1 Essentials
Module 8
Package Management
Deactivating Packages
RP/0/0/CPU0:P5(admin)#install deactivate disk0:c12k-rp-mgbl-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.
RP/0/0/CPU0:P5(admin)#
Install: Now operating in asynchronous mode. Do not attempt subsequent install operations
until this operation is complete.
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.
© 2005 Cisco Systems, Inc.
Version 2.0b
8–29
Cisco IOS XR Installation
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.
_________________________________________________________________
8–30
Version 2.0b
Cisco CRS-1 Essentials
Module 8
Package Management
Package Removal
RP/0/0/CPU0:P5(admin)#install remove disk0:c12k-mgbl-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.
RP/0/0/CPU0:P5(admin)#
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.
© 2005 Cisco Systems, Inc.
Version 2.0b
8–31
Cisco IOS XR Installation
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 log—Lists what occurred at each install point
•
show install committed—Lists 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
_________________________________________________________________
8–32
Version 2.0b
Cisco CRS-1 Essentials
Module 8
Package Management
install rollback Command
RP/0/0/CPU0:P5(admin)#install rollback 2
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:P5(admin)#
Install: Now operating in asynchronous mode. Do not attempt subsequent install operations
until this operation is complete.
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
Additional messages are not shown
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
Additional messages are not shown
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 ***
Install 11: [ 10%] Node 0/1/CPU0: *** Will be reloaded ***
Note reload
Install 11: [ 10%] Node 0/3/CPU0: *** Will be reloaded ***
Install 11: [ 10%] Node 0/4/CPU0: *** Will be reloaded ***
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
© 2005 Cisco Systems, Inc.
Version 2.0b
8–33
Cisco IOS XR Installation
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.
8–34
Version 2.0b
Cisco CRS-1 Essentials
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
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:P5(admin)#
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
© 2005 Cisco Systems, Inc.
Version 2.0b
8–35
Cisco IOS XR Installation
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.
8–36
Version 2.0b
Cisco CRS-1 Essentials
Module 8
Software Installation Review
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
Request id 2 by cisco at Tue May 31 11:02:51 2005:
1 pie added to disk0:: /tftp://172.21.116.8/c12k-mpls.pie-3.2.85.3I
Request id 3 by cisco at Tue May 31 11:06:31 2005:
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
Request id 5 by cisco at Wed Jun 01 11:02:24 2005:
1 package activated: disk0:c12k-mini-3.2.85
More information available via the command 'show install log 5'
Request id 6 by cisco at Wed Jun 01 11:26:32 2005:
Committed loadpath changes
5 entries shown (max log size 50 entries)
• Also applicable at the EXEC prompt
© 2005 Cisco Systems, Inc.
Version 2.0b
8–37
Cisco IOS XR Installation
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.
8–38
Version 2.0b
Cisco CRS-1 Essentials
Module 8
Software Installation Review
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
© 2005 Cisco Systems, Inc.
Version 2.0b
8–39
Cisco IOS XR Installation
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.
8–40
Version 2.0b
Cisco CRS-1 Essentials
Module 8
Software Installation Review
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]
Boot Image: /disk0/c12k-os-mbi-3.2.83/mbiprp-rp.vm
Active Packages:
disk0:c12k-mini-3.2.83
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:
disk0:c12k-mini-3.2.83
Node 0/4/CPU0 [LC(E3-OC48-POS)]
Boot Image: /disk0/c12k-os-mbi-3.2.83/gsr/ucode/mbiprp-lc.ucode
Active Packages:
disk0:c12k-mini-3.2.83
© 2005 Cisco Systems, Inc.
Version 2.0b
8–41
Cisco IOS XR Installation
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.
8–42
Version 2.0b
Cisco CRS-1 Essentials
Module 8
Software Installation Review
Display Active Package Details
RP/0/0/CPU0:P5#show install active detail
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
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]
Boot Image: /disk0/c12k-os-mbi-3.2.83/mbiprp-rp.vm
Active Packages:
disk0:c12k-mini-3.2.83
disk0:c12k-rout-3.2.83
disk0:c12k-lc-3.2.83
disk0:c12k-fwdg-3.2.83
disk0:c12k-admin-3.2.83
disk0:c12k-base-3.2.83
disk0:c12k-os-mbi-3.2.83
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:
disk0:c12k-mini-3.2.83
disk0:c12k-lc-3.2.83
disk0:c12k-fwdg-3.2.83
disk0:c12k-admin-3.2.83
disk0:c12k-base-3.2.83
disk0:c12k-os-mbi-3.2.83
© 2005 Cisco Systems, Inc.
Version 2.0b
8–43
Cisco IOS XR Installation
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.
8–44
Version 2.0b
Cisco CRS-1 Essentials
Module 8
Software Installation Review
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
© 2005 Cisco Systems, Inc.
Version 2.0b
8–45
Cisco IOS XR Installation
Module 8
Summary
Cisco IOS XR Installation
In this module, you learned to:
8–46
•
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
Cisco CRS-1 Essentials
Module 8
Review Questions
Cisco IOS XR Installation
1. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
2. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
3. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
4. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
5. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
© 2005 Cisco Systems, Inc.
Version 2.0b
8–47
Cisco IOS XR Installation
Module 8
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
8–48
Version 2.0b
Cisco CRS-1 Essentials
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
After completing this module, you will be able to:
•
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.
© 2005 Cisco Systems, Inc.
Version 1.0c
9–1
Cisco IOS XR Security
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.
9–2
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Cisco IOS XR Security Overview
Cisco IOS XR Security Overview
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
© 2005 Cisco Systems, Inc.
Version 1.0c
9–3
Cisco IOS XR Security
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.
9–4
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Cisco IOS XR Security Overview
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
© 2005 Cisco Systems, Inc.
Version 1.0c
9–5
Cisco IOS XR Security
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.
9–6
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Cisco IOS XR Security Overview
Cisco IOS XR Security Overview (Cont.)
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
© 2005 Cisco Systems, Inc.
Version 1.0c
9–7
Cisco IOS XR Security
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.
9–8
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Cisco IOS XR Security Overview
Cisco IOS XR Security Overview (Cont.)
• 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
© 2005 Cisco Systems, Inc.
Version 1.0c
9–9
Cisco IOS XR Security
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.
9–10
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Cisco IOS XR Security Implementation
AAA Implementation Planes
Logical router (LR) plane
Administration (Admin) plane
ADMIN
LR
AAA
Single physical router
© 2005 Cisco Systems, Inc.
Version 1.0c
9–11
Cisco IOS XR Security
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.
9–12
•
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
Cisco CRS-1 Essentials
Module 9
Cisco IOS XR Security Implementation
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
© 2005 Cisco Systems, Inc.
Version 1.0c
9–13
Cisco IOS XR Security
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.
9–14
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Cisco IOS XR Security Implementation
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
© 2005 Cisco Systems, Inc.
Version 1.0c
9–15
Cisco IOS XR Security
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:
•
Read—permits a read operation only
•
Write—permits a write operation and an implicit read operation
•
Execute—permits an access operation, such as to a copy, ping, or telnet
•
Debug—permits 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.
9–16
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Cisco IOS XR Security Implementation
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.
© 2005 Cisco Systems, Inc.
Version 1.0c
9–17
Cisco IOS XR Security
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 user’s 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-system—Root-system users
•
root-lr—Root-logical router users
•
netadmin—Network administrators
•
sysadmin—System administrators
•
operator—Day-to-day activity users
Users can configure their own task groups to meet particular needs.
Task groups support inheritance from other task groups.
9–18
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Cisco IOS XR Security Implementation
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
© 2005 Cisco Systems, Inc.
Version 1.0c
9–19
Cisco IOS XR Security
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.
9–20
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Cisco IOS XR Security Implementation
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
© 2005 Cisco Systems, Inc.
Version 1.0c
9–21
Cisco IOS XR Security
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-system—Controls and monitors the entire router
•
root-lr—Controls and monitors a specific LR
•
sysadmin—Controls and monitors all system parameters, but cannot
configure network protocols
•
netadmin—Controls and monitors all system and network parameters
•
operator—Has 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.
9–22
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Cisco IOS XR Security Implementation
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
© 2005 Cisco Systems, Inc.
Version 1.0c
9–23
Cisco IOS XR Security
Module 9
Predefined User Group Permissions
Cisco IOS XR software provides these user groups with predefined
attributes.
9–24
•
root-system—The 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-lr—The LR owner can perform all write commands, except the
root-system owner tasks, which are read only.
•
netadmin—The 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.
•
sysadmin—The 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.
•
operator—The 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
Cisco CRS-1 Essentials
Module 9
Cisco IOS XR Security Implementation
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
© 2005 Cisco Systems, Inc.
Version 1.0c
9–25
Cisco IOS XR Security
Module 9
Users
Cisco IOS XR software attributes forms the basis of router user access.
Each router user is associated with the following:
9–26
•
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
Cisco CRS-1 Essentials
Module 9
Cisco IOS XR Security Implementation
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
© 2005 Cisco Systems, Inc.
Version 1.0c
9–27
Cisco IOS XR Security
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.
_________________________________________________________________
9–28
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Cisco IOS XR Security Implementation
Local AAA and Database
Authentication, authorization, and accounting (AAA)
• Users, user groups, and task groups are stored
in a local database (SysDB)
© 2005 Cisco Systems, Inc.
Version 1.0c
9–29
Cisco IOS XR Security
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.
9–30
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Cisco IOS XR Security Implementation
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
© 2005 Cisco Systems, Inc.
Version 1.0c
9–31
Cisco IOS XR Security
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).
9–32
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Cisco IOS XR Security Implementation
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
© 2005 Cisco Systems, Inc.
Version 1.0c
9–33
Cisco IOS XR Security
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:
•
login—Sets login authentication
•
group tacacs+—Uses a server group or TACACS+ servers for
authentication
•
local—Uses a local username or password database for authentication
•
line—Uses 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:
•
Command—Applies authorization to the EXEC mode commands
issued by a user. Command authorization attempts authorization for
all EXEC mode commands.
•
EXEC—Applies authorization to the startup of an EXEC session.
•
Network—Applies 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.
9–34
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Cisco IOS XR Security Implementation
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
© 2005 Cisco Systems, Inc.
Version 1.0c
9–35
Cisco IOS XR Security
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.
9–36
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Cisco IOS XR Security Implementation
Authentication Flow of Control
1
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
© 2005 Cisco Systems, Inc.
Version 1.0c
9–37
Cisco IOS XR Security
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.
9–38
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Cisco IOS XR Security Implementation
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)
© 2005 Cisco Systems, Inc.
Version 1.0c
9–39
Cisco IOS XR Security
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.
9–40
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Cisco IOS XR Security Implementation
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
© 2005 Cisco Systems, Inc.
Version 1.0c
9–41
Cisco IOS XR Security
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.
9–42
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Security Configuration
Site-Defined Groups and Users
Configuration flow
Task group (TG)
• Name
• Task ID associations
− Read, write, so on
• Inheritance of other
TG permissions
© 2005 Cisco Systems, Inc.
User group (UG)
• Name
• Inheritance of
TG permissions
• Taskgroup
associations
Version 1.0c
User
• Name
• Password
• List of user
groups
9–43
Cisco IOS XR Security
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.
9–44
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Security Configuration
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
© 2005 Cisco Systems, Inc.
Version 1.0c
9–45
Cisco IOS XR Security
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.
9–46
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Security Configuration
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)#
© 2005 Cisco Systems, Inc.
Version 1.0c
9–47
Cisco IOS XR Security
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.
9–48
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Security Configuration
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
© 2005 Cisco Systems, Inc.
Version 1.0c
9–49
Cisco IOS XR Security
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.
9–50
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Security Configuration
Creating User Groups
Configure “usergroup routeadmin”
RP/0/RP0/CPU0:POD5#configure
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)#
© 2005 Cisco Systems, Inc.
Version 1.0c
9–51
Cisco IOS XR Security
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.
9–52
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Security Configuration
Verifying User Group Configuration
RP/0/0/CPU0:POD5#show aaa usergroup
User group 'routeadmin'
contains task group 'bgpadmin'
© 2005 Cisco Systems, Inc.
Version 1.0c
9–53
Cisco IOS XR Security
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.
−
−
Password—Lower security
−
Unencrypted version that uses a parameter value of 0, which is
the default
−
Hidden version that uses a parameter value of 7
Secret—Higher 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.
9–54
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Security Configuration
Configuring Users
Configure a user
RP/0/RP0/CPU0:POD5#configure
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.
© 2005 Cisco Systems, Inc.
Version 1.0c
9–55
Cisco IOS XR Security
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.
9–56
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Security Configuration
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.
© 2005 Cisco Systems, Inc.
Version 1.0c
9–57
Cisco IOS XR Security
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).
9–58
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Access Control Lists
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
© 2005 Cisco Systems, Inc.
Version 1.0c
9–59
Cisco IOS XR Security
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.
9–60
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Access Control Lists
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
© 2005 Cisco Systems, Inc.
Version 1.0c
9–61
Cisco IOS XR Security
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.
9–62
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Access Control Lists
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
© 2005 Cisco Systems, Inc.
Version 1.0c
9–63
Cisco IOS XR Security
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
9–64
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Access Control Lists
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
ipv4 access-list Ethernet_In
1 deny udp any eq netbios-ns any
2 deny udp any host 255.255.255.255 eq tftp
3 deny udp any eq netbios-dgm any
4 permit any
• Sample ACL
RP/0/RP0/CPU0:POD5#show access-list ipv4 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
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
RP/0/RP0/CPU0:POD5#show access-list ipv4 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
© 2005 Cisco Systems, Inc.
Version 1.0c
9–65
Cisco IOS XR Security
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.
9–66
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Access Control Lists
Resequencing ACLs
• Sample ACL
RP/0/RP0/CPU0:POD5#show access-list ipv4 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
3 permit any
• Resequence the ACL
RP/0/RP0/CPU0:POD5#resequence access-list ipv4 Ethernet_In
• Modified sample ACL
RP/0/RP0/CPU0:POD5#show access-list ipv4 Ethernet_In
ipv4 access-list Ethernet_In
10 deny udp any eq netbios-ns any
20 deny udp any host 255.255.255.255 eq tftp
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.
© 2005 Cisco Systems, Inc.
Version 1.0c
9–67
Cisco IOS XR Security
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.
9–68
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Access Control Lists
Copying ACLs
RP/0/RP0/CPU0:POD5#copy access-list ipv4 pod5 pod5copy
© 2005 Cisco Systems, Inc.
Version 1.0c
9–69
Cisco IOS XR Security
Module 9
Summary
Cisco IOS XR Security
In this module, you learned to:
9–70
•
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
Cisco CRS-1 Essentials
Module 9
Review Questions
Cisco IOS XR Security
1. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
2. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
3. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
4. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
5. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
© 2005 Cisco Systems, Inc.
Version 1.0c
9–71
Cisco IOS XR Security
Module 9
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
9–72
Version 1.0c
Cisco CRS-1 Essentials
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
After completing this module, you will be able to:
•
Configure BGP
•
Configure OSPF
•
Configure IS-IS
•
Configure Multicast Routing
•
Identify functional and configuration differences between Cisco IOS
and Cisco IOS XR routing protocols
© 2005 Cisco Systems, Inc.
Version 2.0a
10–1
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.
10–2
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Border Gateway Protocol (BGP)
Functional Differences
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)
© 2005 Cisco Systems, Inc.
Version 2.0a
10–3
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.
10–4
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Border Gateway Protocol (BGP)
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
Routing Policy Language (RPL)
• Most route map usage replaced
• Inbound and outbound policies required for eBGP
Dynamic update groups
© 2005 Cisco Systems, Inc.
Version 2.0a
10–5
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.
10–6
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Border Gateway Protocol (BGP)
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.
© 2005 Cisco Systems, Inc.
Version 2.0a
10–7
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.
10–8
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Border Gateway Protocol (BGP)
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)# router bgp 65000
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)# update-source Loopback0
© 2005 Cisco Systems, Inc.
Version 2.0a
10–9
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.
10–10
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Border Gateway Protocol (BGP)
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)# neighbor 10.60.70.10
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.
© 2005 Cisco Systems, Inc.
Version 2.0a
10–11
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.
10–12
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Border Gateway Protocol (BGP)
address-family Command
router(config-bgp)#
router(config-bgp-nbr)#
address-family {ipv4 | ipv6} {unicast | multicast}
RP/0/RP0/CPU0:router(config)# router bgp 65000
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)# neighbor 10.1.1.1
RP/0/RP0/CPU0:router(config-bgp-nbr)# remote-as 64500
RP/0/RP0/CPU0:router(config-bgp-nbr)# address-family ipv4 unicast
RP/0/RP0/CPU0:router(config-bgp-nbr-af)# weight 200
© 2005 Cisco Systems, Inc.
Version 2.0a
10–13
Routing Protocols
Module 10
Configuration Example
The topology and configuration on the opposite page is similar to part of
the course’s 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.
10–14
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Border Gateway Protocol (BGP)
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
!
interface POS0/3/0/1
ipv4 address 142.50.20.3 255.255.255.0
!
interface POS0/4/0/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
address-family ipv4 unicast
!
!
neighbor 100.10.20.1
use neighbor-group internal
description P1 router
!
neighbor 100.10.20.2
use neighbor-group internal
description P2 router
!
!
© 2005 Cisco Systems, Inc.
Version 2.0a
10–15
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.
10–16
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Border Gateway Protocol (BGP)
show Commands
Effective neighbor configuration and inheritance
RP/0/0/CPU0:P3# show bgp neighbors 100.10.20.1 configuration
neighbor 100.10.20.1
remote-as 65000
[n:internal]
password encrypted 121A0C041104 [n:internal]
update-source Loopback0
[n:internal]
address-family ipv4 unicast
[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
© 2005 Cisco Systems, Inc.
Version 2.0a
TblVer
1
1
InQ OutQ Up/Down St/PfxRcd
0
0
1d19h
0
0
0
1d19h
0
10–17
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.
10–18
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Border Gateway Protocol (BGP)
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
© 2005 Cisco Systems, Inc.
Version 2.0a
Only deterministic behavior is
supported
10–19
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.
10–20
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Border Gateway Protocol (BGP)
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
© 2005 Cisco Systems, Inc.
Version 2.0a
10–21
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.
10–22
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Border Gateway Protocol (BGP)
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
© 2005 Cisco Systems, Inc.
Version 2.0a
10–23
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.
10–24
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Border Gateway Protocol (BGP)
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”
© 2005 Cisco Systems, Inc.
Version 2.0a
10–25
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.
10–26
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Border Gateway Protocol (BGP)
Distributed BGP Processes
BGP speaker—Multiple 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
© 2005 Cisco Systems, Inc.
Partial
bestpaths
Version 2.0a
10–27
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:
Hierarchy—CLI configuration hierarchy is supported.
Inheritance—CLI configuration inheritance is supported.
Stub areas—Stub areas are supported.
Not-So-Stubby-Areas (NSSA) —RFC 1587 is supported.
Virtual links—Virtual links are supported.
OSPF over demand circuits—RFC 1793 is supported.
Non-Stop Forwarding (NSF) —NSF is supported for OSPFv2.
Shortest Path First (SPF) throttling—SPF throttling is supported.
Route redistribution—Routes learned by any IP routing protocol can be
redistributed into any other IP routing protocol.
Authentication—Plain 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 parameters—Configurable interface parameters,
such as metric, retransmission interval, transmit delay, router priority,
dead interval, hello interval, and authentication key are supported.
10–28
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Open Shortest Path First (OSPF)
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
© 2005 Cisco Systems, Inc.
Version 2.0a
10–29
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.
10–30
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Open Shortest Path First (OSPF)
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)
© 2005 Cisco Systems, Inc.
Version 2.0a
10–31
Routing Protocols
Module 10
Configuration Differences
The key differences in OSPF configuration commands between Cisco IOS
and Cisco IOS XR are:
10–32
•
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
Cisco CRS-1 Essentials
Module 10
Open Shortest Path First (OSPF)
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)# interface pos0/0/1
Router(config-if)# ip address 10.1.1.5 255.255.255.252
Router(config-if)# ip ospf cost 40
Router(config-if)# exit
!
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)# interface pos0/4/0/1
RP/0/RP0/CPU0:router(config-if)# ip address 10.1.1.5 255.255.255.252
RP/0/RP0/CPU0:router(config-if)# exit
!
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)# interface pos0/4/0/1
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.
© 2005 Cisco Systems, Inc.
Version 2.0a
10–33
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:
10–34
•
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
Cisco CRS-1 Essentials
Module 10
Open Shortest Path First (OSPF)
Differences for OSPFv3
Cisco IOS configuration
Router(config)# interface pos0/0/0
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-if)# exit
!
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)# interface pos0/4/0/1
RP/0/RP0/CPU0:router(config-if)# ipv6 address 2002:1234::212/64
RP/0/RP0/CPU0:router(config-if)# exit
!
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)# area 0
RP/0/RP0/CPU0:router(config-ospf-ar)# interface pos0/4/0/1
RP/0/RP0/CPU0:router(config-ospf-ar-if)# cost 20
© 2005 Cisco Systems, Inc.
Version 2.0a
10–35
Routing Protocols
Module 10
Configuring OSPF
OSPF is enabled from the global configuration mode.
Step 1—router 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.
_________________________________________________________________
10–36
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Open Shortest Path First (OSPF)
Configuring OSPF—router ospf Command
Step 1—Configure 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
© 2005 Cisco Systems, Inc.
Version 2.0a
10–37
Routing Protocols
Module 10
Step 2—router-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 3—area 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.
_________________________________________________________________
10–38
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Open Shortest Path First (OSPF)
Configuring OSPF—router-id and area Commands
Step 2—Optionally 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 3—Configure OSPF area
area area-id
RP/0/RP0/CPU0:router(config-ospf)# area 0
© 2005 Cisco Systems, Inc.
Version 2.0a
10–39
Routing Protocols
Module 10
Step 4—interface 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.
10–40
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Open Shortest Path First (OSPF)
Configuring OSPF—interface Command
Step 4—Configure 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.
© 2005 Cisco Systems, Inc.
Version 2.0a
10–41
Routing Protocols
Module 10
Step 5—Interface-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.
10–42
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Open Shortest Path First (OSPF)
Configuring OSPF—Interface-level Command Example
Step 5—Configure 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
© 2005 Cisco Systems, Inc.
Version 2.0a
10–43
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).
_________________________________________________________________
10–44
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Open Shortest Path First (OSPF)
MD5 Authentication
router (config-ospf)#
authentication [message-digest | null]
RP/0/RP0/CPU0:router(config-ospf)# authentication message-digest
router (config-ospf)#
message-digest-key key-id md5 [encryption-type] key
RP/0/RP0/CPU0:router(config-ospf)# message-digest-key 4 md5 key1
© 2005 Cisco Systems, Inc.
Version 2.0a
10–45
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.
10–46
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Open Shortest Path First (OSPF)
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
!
interface POS0/4/0/0
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
interface POS0/4/0/0
message-digest-key 5 md5 ospf-key
© 2005 Cisco Systems, Inc.
Version 2.0a
10–47
Routing Protocols
Module 10
Intermediate System-Intermediate System (IS-IS)
Functional Differences
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:
10–48
•
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
Cisco CRS-1 Essentials
Module 10
Intermediate System-Intermediate System (IS-IS)
Functional Differences
Architecture changes
• Hierarchical configuration
• Multiple IS-IS instances
• Multi-topology as the default behavior
Other changes
• IS-IS supports only IP routing—no 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.
© 2005 Cisco Systems, Inc.
Version 2.0a
10–49
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.
10–50
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Intermediate System-Intermediate System (IS-IS)
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
© 2005 Cisco Systems, Inc.
Version 2.0a
10–51
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.
10–52
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Intermediate System-Intermediate System (IS-IS)
Multiple Instance Example
Level 2 Area 49.0003
Level 1 Area 49.0001
Level 1 Area 49.0002
1 Level 2 instance
2 Level 1 instances
© 2005 Cisco Systems, Inc.
Version 2.0a
10–53
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, we’ve 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.
10–54
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Intermediate System-Intermediate System (IS-IS)
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
address-family ipv4 unicast
set-attached-bit
!
interface POS0/4/0/0
address-family ipv4 unicast
!
!
interface POS0/4/0/1
address-family ipv4 unicast
!
!
!
--More--
router isis r2
is-type level-1
net 49.0002.0000.0000.0002.00
address-family ipv4 unicast
set-attached-bit
!
interface POS0/4/0/2
address-family ipv4 unicast
!
!
!
router isis r3
is-type level-2-only
net 49.0003.0000.0000.0003.00
address-family ipv4 unicast
redistribute isis r1 level-2 metric 0 metric-type internal
redistribute isis r2 level-2 metric 0 metric-type internal
distance 116
!
interface POS0/4/0/3
address-family ipv4 unicast
!
!
!
© 2005 Cisco Systems, Inc.
Version 2.0a
10–55
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.
10–56
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Intermediate System-Intermediate System (IS-IS)
Other Configuration Examples
Setting instance-wide address family specific values
RP/0/RP0/CPU0:router(config)# router isis lab
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)# 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
RP/0/RP0/CPU0:router(config-isis-af)# propagate level 2 into level 1 distribute-list
L21
© 2005 Cisco Systems, Inc.
Version 2.0a
10–57
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.
10–58
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Intermediate System-Intermediate System (IS-IS)
Configuration Comparison
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
address-family ipv4 unicast
metric-style wide
!
interface Loopback0
passive
address-family ipv4 unicast
!
!
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
interface POS0/4/0/0
address-family ipv4 unicast
!
!
© 2005 Cisco Systems, Inc.
Version 2.0a
10–59
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 didn’t seem to have
any effect on the specifics of the debug output; it appeared to be the same with or without the
keyword.
10–60
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Intermediate System-Intermediate System (IS-IS)
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
© 2005 Cisco Systems, Inc.
Version 2.0a
10–61
Routing Protocols
Module 10
Multicast Routing
Functional Differences
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.
10–62
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Multicast Routing
Functional Differences
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 Cisco’s 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.
© 2005 Cisco Systems, Inc.
Version 2.0a
10–63
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.
10–64
Version 2.0a
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0a
10–65
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.
_________________________________________________________________
10–66
Version 2.0a
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0a
10–67
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.
10–68
Version 2.0a
Cisco CRS-1 Essentials
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 address—use the loopback address
RP/0/RP0/CPU0:router(config-pim-ipv4)# rp-address 1.1.1.1
© 2005 Cisco Systems, Inc.
Version 2.0a
10–69
Routing Protocols
Module 10
If your router is a potential RP, you need to configure it as a candidate RP
(CRP). With auto−RP 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 RP−to−group 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.
10–70
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Multicast Routing
PIM Configuration (continued)
RP/0/0/CPU0:router(config-pim-ipv4)#
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
RP/0/0/CPU0:router(config-pim-ipv4)#
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.
© 2005 Cisco Systems, Inc.
Version 2.0a
10–71
Routing Protocols
Module 10
Configuration Comparison
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.
10–72
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Multicast Routing
Configuration Comparison
Cisco IOS XR
Cisco IOS
Enable Multicast:
Enable Multicast:
interface POS4/0
ip multicast-routing
multicast-routing
interface POS0/4/0/0
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
interface POS0/4/0/0
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
© 2005 Cisco Systems, Inc.
Version 2.0a
10–73
Routing Protocols
Module 10
Summary
Routing Protocols
In this module, you learned:
10–74
•
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
Cisco CRS-1 Essentials
Module 10
Review Questions
Routing Protocols
1. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
2. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
3. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
4. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
5. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
© 2005 Cisco Systems, Inc.
Version 2.0a
10–75
Routing Protocols
Module 10
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
10–76
Version 2.0a
Cisco CRS-1 Essentials
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
After completing this module, you will be able to:
•
Write policies in RPL
•
Use hierarchical and parameterized policies
•
Convert route maps to RPL policies
© 2005 Cisco Systems, Inc.
Version 2.0
11–1
Routing Policy Language
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 1000’s of route maps with
their implied redundancy.
11–2
Version 2.0
Cisco CRS-1 Essentials
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 ISP’s 15K lines of route maps in 1K lines of RPL policy.
© 2005 Cisco Systems, Inc.
Version 2.0
11–3
Routing Policy Language
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.
11–4
Version 2.0
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0
11–5
Routing Policy Language
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.
11–6
Version 2.0
Cisco CRS-1 Essentials
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?
© 2005 Cisco Systems, Inc.
Version 2.0
11–7
Routing Policy Language
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.
11–8
Version 2.0
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0
11–9
Routing Policy Language
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 Repository—Compiles 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 engine—Is 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.
11–10
Version 2.0
Cisco CRS-1 Essentials
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)
© 2005 Cisco Systems, Inc.
Version 2.0
11–11
Routing Policy Language
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 0–9; 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
11–12
Version 2.0
Cisco CRS-1 Essentials
Module 11
RPL Description
Basic Building Blocks and Functions
Route Policy
Language
AS Path Sets
© 2005 Cisco Systems, Inc.
Route Policies
Policy Sets
Community
Sets
Extended
Community
Sets
Version 2.0
Prefix Sets
11–13
Routing Policy Language
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.
_________________________________________________________________
11–14
Version 2.0
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0
11–15
Routing Policy Language
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.
11–16
Version 2.0
Cisco CRS-1 Essentials
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.
© 2005 Cisco Systems, Inc.
Version 2.0
11–17
Routing Policy Language
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>
address-family ipv4 unicast
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 don’t 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.
_________________________________________________________________
11–18
Version 2.0
Cisco CRS-1 Essentials
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
address-family ipv4 unicast
policy foo in
policy bar out
© 2005 Cisco Systems, Inc.
Version 2.0
11–19
Routing Policy Language
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.
11–20
Version 2.0
Cisco CRS-1 Essentials
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
Neighbor export/import
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
© 2005 Cisco Systems, Inc.
Version 2.0
11–21
Routing Policy Language
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.
11–22
Version 2.0
Cisco CRS-1 Essentials
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
Neighbor export/import
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
© 2005 Cisco Systems, Inc.
Version 2.0
11–23
Routing Policy Language
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.
11–24
Version 2.0
Cisco CRS-1 Essentials
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$’)
© 2005 Cisco Systems, Inc.
Version 2.0
11–25
Routing Policy Language
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
_________________________________________________________________
11–26
Version 2.0
Cisco CRS-1 Essentials
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)
© 2005 Cisco Systems, Inc.
Version 2.0
11–27
Routing Policy Language
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.
11–28
Version 2.0
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0
11–29
Routing Policy Language
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$')
11–30
Version 2.0
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0
11–31
Routing Policy Language
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
11–32
Version 2.0
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0
11–33
Routing Policy Language
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:val—Defines 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:val—Defines 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:n—Route Target (RT) in IPv4 format
RT:asn:n—RT in AS format
SoO:a.b.c.d:n—Site of Origin (SoO) in IPv4 format
SoO:asn:n—SoO 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.
_________________________________________________________________
11–34
Version 2.0
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0
11–35
Routing Policy Language
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
set community (12:56) additive
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
set local-preference 60
else
set local-preference 0
endif
11–36
Version 2.0
Cisco CRS-1 Essentials
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
set local-preference 10
elseif med eq 200 then
set local-preference 60
else
set local-preference 0
endif
© 2005 Cisco Systems, Inc.
Version 2.0
11–37
Routing Policy Language
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
set local-preference 100
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.
_________________________________________________________________
11–38
Version 2.0
Cisco CRS-1 Essentials
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
set local-preference 100
endif
© 2005 Cisco Systems, Inc.
Version 2.0
11–39
Routing Policy Language
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)
11–40
Version 2.0
Cisco CRS-1 Essentials
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 …
© 2005 Cisco Systems, Inc.
Version 2.0
11–41
Routing Policy Language
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 route’s next hop is 10.0.2.2 then the entire compound
condition is true. Otherwise the compound condition is false.
11–42
Version 2.0
Cisco CRS-1 Essentials
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))
© 2005 Cisco Systems, Inc.
Version 2.0
11–43
Routing Policy Language
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
set local-preference 200
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
if destination in (10.0.0.0/8 ge 8 le 32) then
set local-preference 200
endif
end-policy
11–44
Version 2.0
Cisco CRS-1 Essentials
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.
© 2005 Cisco Systems, Inc.
Version 2.0
11–45
Routing Policy Language
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.
11–46
Version 2.0
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0
11–47
Routing Policy Language
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.
11–48
Version 2.0
Cisco CRS-1 Essentials
Module 11
BGP Route Attributes and Operations
BGP Route Attributes
Attribute
BGP
as-path
X
community
X
dampening
X
destination
X
extended community
X
local preference
X
med
X
next-hop
X
origin
X
route-type
Cisco
X
source
X
suppress
X
tag
X
traffic-index
X
weight
X
Instructor’s 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.
© 2005 Cisco Systems, Inc.
Version 2.0
11–49
Routing Policy Language
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.
11–50
Version 2.0
Cisco CRS-1 Essentials
Module 11
BGP Route Attributes and Operations
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.
© 2005 Cisco Systems, Inc.
Version 2.0
11–51
Routing Policy Language
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).
11–52
Version 2.0
Cisco CRS-1 Essentials
Module 11
BGP Route Attributes and Operations
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.
© 2005 Cisco Systems, Inc.
Version 2.0
11–53
Routing Policy Language
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.
_________________________________________________________________
11–54
Version 2.0
Cisco CRS-1 Essentials
Module 11
BGP Route Attributes and Operations
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.
© 2005 Cisco Systems, Inc.
Version 2.0
11–55
Routing Policy Language
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.
11–56
Version 2.0
Cisco CRS-1 Essentials
Module 11
BGP Route Attributes and Operations
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
© 2005 Cisco Systems, Inc.
Version 2.0
11–57
Routing Policy Language
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.
11–58
Version 2.0
Cisco CRS-1 Essentials
Module 11
BGP Route Attributes and Operations
Destination
destination -- Match
if destination in (10.0.0.0/8 ge 8 le 32) then
set local-preference 200
endif
© 2005 Cisco Systems, Inc.
Version 2.0
11–59
Routing Policy Language
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.
11–60
Version 2.0
Cisco CRS-1 Essentials
Module 11
BGP Route Attributes and Operations
Extended Community
extcommunity -- Match
if extcommunity matchs-any ec1 then …
If extcommunity matchs-every ec2 then …
If extcommunity is-empty then …
© 2005 Cisco Systems, Inc.
Version 2.0
11–61
Routing Policy Language
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>
11–62
Version 2.0
Cisco CRS-1 Essentials
Module 11
BGP Route Attributes and Operations
Local Preference
local-preference -- Assignment
set local-preference 200
© 2005 Cisco Systems, Inc.
Version 2.0
11–63
Routing Policy Language
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.
11–64
Version 2.0
Cisco CRS-1 Essentials
Module 11
BGP Route Attributes and Operations
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.
© 2005 Cisco Systems, Inc.
Version 2.0
11–65
Routing Policy Language
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.
11–66
Version 2.0
Cisco CRS-1 Essentials
Module 11
BGP Route Attributes and Operations
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 ...
© 2005 Cisco Systems, Inc.
Version 2.0
11–67
Routing Policy Language
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}
11–68
Version 2.0
Cisco CRS-1 Essentials
Module 11
BGP Route Attributes and Operations
Origin
origin -- Match
if origin is igp or origin is incomplete then …
origin -- Assignment
set origin incomplete
© 2005 Cisco Systems, Inc.
Version 2.0
11–69
Routing Policy Language
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.
11–70
Version 2.0
Cisco CRS-1 Essentials
Module 11
BGP Route Attributes and Operations
Source
source -- Match
if source matches-any my_prefix_set then ...
© 2005 Cisco Systems, Inc.
Version 2.0
11–71
Routing Policy Language
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.
11–72
Version 2.0
Cisco CRS-1 Essentials
Module 11
BGP Route Attributes and Operations
Tag
tag -- Match
if tag eq 10 then …
tag -- Assignment
set tag 20
© 2005 Cisco Systems, Inc.
Version 2.0
11–73
Routing Policy Language
Module 11
Traffic-Index
The traffic-index is a special attribute for Cisco’s 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.
11–74
Version 2.0
Cisco CRS-1 Essentials
Module 11
BGP Route Attributes and Operations
Traffic-Index
traffic-index -- Assignment
set traffic-index 10
set traffic-index $tindex
set traffic-index ignore
© 2005 Cisco Systems, Inc.
Version 2.0
11–75
Routing Policy Language
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.
11–76
Version 2.0
Cisco CRS-1 Essentials
Module 11
BGP Route Attributes and Operations
Weight
weight -- Assignment
set weight 100
© 2005 Cisco Systems, Inc.
Version 2.0
11–77
Routing Policy Language
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.
11–78
Version 2.0
Cisco CRS-1 Essentials
Module 11
Converting Route Maps to RPL Policies
Converting Route Maps to RPL Policies
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
© 2005 Cisco Systems, Inc.
Version 2.0
11–79
Routing Policy Language
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.
11–80
Version 2.0
Cisco CRS-1 Essentials
Module 11
Converting Route Maps to RPL Policies
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
© 2005 Cisco Systems, Inc.
Version 2.0
11–81
Routing Policy Language
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.
_________________________________________________________________
11–82
Version 2.0
Cisco CRS-1 Essentials
Module 11
Converting Route Maps to RPL Policies
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
route-map sample2 permit 10
match ip address prefix-list 102
match community 1
set metric 11
set community 12:35 additive
route-map sample1 permit 20
match ip address prefix-list 101
match community 2
set metric 12
set community 12:34 additive
route-map sample2 permit 20
match ip address prefix-list 102
match community 2
set metric 12
set community 12:35 additive
route-map sample1 permit 30
match ip address prefix-list 101
match community 3
set metric 13
set community 12:34 additive
route-map sample2 permit 30
match ip address prefix-list 102
match community 3
set metric 13
set community 12:35 additive
route-map sample1 permit 40
match ip address prefix-list 101
match community 4
set metric 14
set community 12:34 additive
route-map sample2 permit 40
match ip address prefix-list 102
match community 4
set metric 14
set community 12:35 additive
route-map sample1 permit 50
match ip address prefix-list 101
set metric 100
set community 12:34 additive
route-map sample2 permit 50
match ip address prefix-list 102
set metric 100
set community 12:35 additive
© 2005 Cisco Systems, Inc.
Version 2.0
11–83
Routing Policy Language
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.
11–84
Version 2.0
Cisco CRS-1 Essentials
Module 11
Converting Route Maps to RPL Policies
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
© 2005 Cisco Systems, Inc.
Version 2.0
11–85
Routing Policy Language
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.
11–86
Version 2.0
Cisco CRS-1 Essentials
Module 11
Converting Route Maps to RPL Policies
Direct Translation (continued)
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
set community 12:34 additive
elseif destination in ps101 and community matches-any cs2 then
set med 12
set community 12:34 additive
elseif destination in ps101 and community matches-any cs3 then
set med 13
set community 12:34 additive
elseif destination in ps101 and community matches-any cs4 then
set med 14
set community 12:34 additive
elseif destination in ps101
set med 100
set community 12:34 additive
endif
end-policy
© 2005 Cisco Systems, Inc.
Version 2.0
11–87
Routing Policy Language
Module 11
Direct Translation (continued)
The same steps used to convert the first route-map are now used to convert
the second route map part of the initial policy.
11–88
Version 2.0
Cisco CRS-1 Essentials
Module 11
Converting Route Maps to RPL Policies
Direct Translation (continued)
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.
route-policy policy2
if destination in ps102 and community matches-any cs1 then
set med 11
set community (12:35) additive
elseif destination in ps102 and community matches-any cs2 then
set med 12
set community (12:35) additive
elseif destination in ps102 and community matches-any cs3 then
set med 13
set community (12:35) additive
elseif destination in ps102 and community matches-any cs4 then
set med 14
set community (12:35) additive
elseif destination in ps102
set med 100
set community (12:35) additive
endif
end-policy
© 2005 Cisco Systems, Inc.
Version 2.0
11–89
Routing Policy Language
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.
11–90
Version 2.0
Cisco CRS-1 Essentials
Module 11
Converting Route Maps to RPL Policies
Nest Conditionals
Replace the redundant “if destination
in” conditional and “set community”
statements in the first route policy by
just one instance each.
route-policy policy1
if destination in ps101 then
set community (12:34) additive
if community matches-any cs1 then
set med 11
elseif community matches-any cs2 then
set med 12
elseif community matches-any cs3 then
set med 13
elseif community matches-any cs4 then
set med 14
else
set med 100
endif
endif
end-policy
© 2005 Cisco Systems, Inc.
Leave the nested ‘if community”
conditionals to reduce size and
evaluation processing.
Version 2.0
11–91
Routing Policy Language
Module 11
Nest Conditionals (continued)
The same steps used to reduce the first policy are now used to reduce the
second policy.
11–92
Version 2.0
Cisco CRS-1 Essentials
Module 11
Converting Route Maps to RPL Policies
Nest Conditionals (continued)
route-policy policy2
if destination in ps102 then
set community (12:35) additive
if community matches-any cs1 then
set med 11
elseif community matches-any cs2 then
set med 12
elseif community matches-any cs3 then
set med 13
elseif community matches-any cs4 then
set med 14
else
set med 100
endif
endif
end-policy
© 2005 Cisco Systems, Inc.
Perform a similar action on the
second route policy reducing
repetitive conditional statements.
Version 2.0
11–93
Routing Policy Language
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.
11–94
Version 2.0
Cisco CRS-1 Essentials
Module 11
Converting Route Maps to RPL Policies
Use Inline Sets
route-policy policy1
if destination in ps101 then
set community (12:34) additive
if community matches-any (10:11) then
set med 11
elseif community matches-any (10:12) then
set med 12
elseif community matches-any (10:13) then
set med 13
elseif community matches-any (10:14) then
set med 14
else
set med 100
endif
endif
end-policy
© 2005 Cisco Systems, Inc.
Replace small named community sets
with inline sets reducing named set
references during policy evaluation.
Version 2.0
11–95
Routing Policy Language
Module 11
Inline Sets (continued)
Performing the same replacements on the second policy leaves only two
prefix sets and two policies.
11–96
Version 2.0
Cisco CRS-1 Essentials
Module 11
Converting Route Maps to RPL Policies
Inline Sets (continued)
Perform same replacement of named
community sets in the second route
policy. Note that the two route policies
are nearly identical.
route-policy policy2
if destination in ps102 then
set community (12:35) additive
if community matches-any (10:11) then
set med 11
elseif community matches-any (10:12) then
set med 12
elseif community matches-any (10:13) then
set med 13
elseif community matches-any (10:14) then
set med 14
else
set med 100
endif
endif
end-policy
© 2005 Cisco Systems, Inc.
Version 2.0
11–97
Routing Policy Language
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.
11–98
Version 2.0
Cisco CRS-1 Essentials
Module 11
Converting Route Maps to RPL Policies
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
if community matches-any (10:11) then
set med 11
elseif community matches-any (10:12) then
set med 12
elseif community matches-any (10:13) then
set med 13
elseif community matches-any (10:14) then
set med 14
else
set med 100
endif
end-policy
© 2005 Cisco Systems, Inc.
Version 2.0
11–99
Routing Policy Language
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.
11–100
Version 2.0
Cisco CRS-1 Essentials
Module 11
Converting Route Maps to RPL Policies
Parameterize (continued)
Apply the parameterized policy to
replace the similar policy blocks in
both of the route policies.
route-policy policy1
if destination in ps101 then
apply common (34)
pass
endif
end-policy
route-policy policy2
if destination in ps102 then
apply common (35)
pass
endif
end-policy
Question?
Do we need the whole new policy as a final slide in this section for comparison?
© 2005 Cisco Systems, Inc.
Version 2.0
11–101
Routing Policy Language
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.
11–102
Version 2.0
Cisco CRS-1 Essentials
Module 11
RPL-Specific CLI Commands
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
© 2005 Cisco Systems, Inc.
Version 2.0
11–103
Routing Policy Language
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.
11–104
Version 2.0
Cisco CRS-1 Essentials
Module 11
RPL-Specific CLI Commands
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
© 2005 Cisco Systems, Inc.
Version 2.0
11–105
Routing Policy Language
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.
_________________________________________________________________
11–106
Version 2.0
Cisco CRS-1 Essentials
Module 11
RPL-Specific CLI Commands
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
© 2005 Cisco Systems, Inc.
Version 2.0
11–107
Routing Policy Language
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.
11–108
Version 2.0
Cisco CRS-1 Essentials
Module 11
RPL-Specific CLI Commands
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]
© 2005 Cisco Systems, Inc.
Version 2.0
11–109
Routing Policy Language
Module 11
Summary
Routing Policy Language
In this module, you learned:
11–110
•
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
Cisco CRS-1 Essentials
Module 11
Review Questions
Routing Policy Language
1. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
2. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
3. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
4. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
5. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
© 2005 Cisco Systems, Inc.
Version 2.0
11–111
Routing Policy Language
Module 11
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
11–112
Version 2.0
Cisco CRS-1 Essentials
Module 12
Multiprotocol Label Switching (MPLS)
Overview
Description
This module discusses the implementation of MPLS in the Cisco IOS XR
operating system software.
Objectives
After completing this module, you will be able to:
•
Describe MPLS forwarding infrastructure
•
Describe MPLS Label Distribution Protocol implementation
•
Describe MPLS Traffic Engineering dynamic implementation
•
Describe MPLS RSVP implementation for MPLS-TE
© 2005 Cisco Systems, Inc.
Version 2.0c
12–1
Multiprotocol Label Switching (MPLS)
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:
12–2
•
Imposition of labels on packets
•
Disposition of labels in packets
•
Label swapping
Version 2.0c
Cisco CRS-1 Essentials
Module 12
MPLS Forwarding Infrastructure
MPLS Forwarding Infrastructure
• 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
© 2005 Cisco Systems, Inc.
Version 2.0c
12–3
Multiprotocol Label Switching (MPLS)
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).
12–4
Version 2.0c
Cisco CRS-1 Essentials
Module 12
MPLS Forwarding Infrastructure
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
© 2005 Cisco Systems, Inc.
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
12–5
Multiprotocol Label Switching (MPLS)
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.
12–6
Version 2.0c
Cisco CRS-1 Essentials
Module 12
MPLS Forwarding Infrastructure
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
© 2005 Cisco Systems, Inc.
RP
TE
RSVP
LDP
IGP
LSD
RIB
LFD
FIB
MSC or
LC
Version 2.0c
12–7
Multiprotocol Label Switching (MPLS)
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.
12–8
Version 2.0c
Cisco CRS-1 Essentials
Module 12
MPLS Forwarding Infrastructure
MFI Architecture (Cont.)
RP
LSD
LC
LFD
© 2005 Cisco Systems, Inc.
SRP
LFD
LSD
LC
LFD
Version 2.0c
LFD
LC
LFD
12–9
Multiprotocol Label Switching (MPLS)
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.
12–10
•
Local Label—Label assigned by this router
•
Outgoing Label—Label assigned by the next hop or downstream peer,
such as:
−
Unlabeled—No label for the destination from the next hop, or label
switching is not enabled on the outgoing interface
−
Pop Label—Next hop advertised an implicit-null label for the
destination
•
Prefix or Tunnel ID—Address or tunnel to which packets with this
label are going
•
Outgoing interface—Interface through which packets with this label
are sent
•
Next Hop—IP address of neighbor that assigned the outgoing label
•
Bytes Switched—Number of bytes switched with this incoming label
•
TO—Timeout: Indicates by an “*” if entry is being timed out in
forwarding
•
Label switching—Number of label switching (LFIB) forwarding entries
•
IPv4 label imposition—Number of IPv4 label imposition forwarding
entries (installed at ingress LSR)
•
MPLS TE tunnel head—Number of forwarding entries (installed at
ingress LSR) on MPLS TE tunnel head
•
MPLS TE fast-reroute—Number of forwarding entries (installed at
PLR) for MPLS traffic-engineering (TE) fast reroute
•
Forwarding updates—Number of forwarding updates sent from LSD
(RP/DRP) to LFIB/MPLS (RP/DRP/LC)
•
Labels in use—Local 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
Cisco CRS-1 Essentials
Module 12
MPLS Forwarding Infrastructure
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
Unlabelled 142.50.12.0/24
18
Pop Label
142.50.20.0/24
19
Unlabelled 100.10.20.3/32
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
© 2005 Cisco Systems, Inc.
Version 2.0c
12–11
Multiprotocol Label Switching (MPLS)
Module 12
Additional information about the details of MPLS forwarding paths is
available showing:
12–12
•
MAC/Encaps—Length in bytes of Layer 2 header, and length in bytes of
packet encapsulation, including Layer 2 header and label header
•
MTU—Maximum transmission unit (MTU) of labeled packet
•
Label Stack—All the outgoing labels on the forwarded packet
•
Packets Switched—Number of packets switched with this incoming
label
•
Installed—Date and time label was installed in the label table
•
Owner—Application that allocated the label
Version 2.0c
Cisco CRS-1 Essentials
Module 12
MPLS Forwarding Infrastructure
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
Unlabelled 100.10.20.1/32
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
MAC/Encaps: 4/8, MTU: 4470
Label Stack (Top -> Bottom): { Imp-Null }
Packets Switched: 0
Installed: May 3 05:01:09.489 (00:55:07 ago)
Owner: LDP
19
Unlabelled 100.10.20.3/32
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
19
100.10.20.3/32
PO0/3/0/3
142.50.52.2
MAC/Encaps: 4/8, MTU: 4470
Label Stack (Top -> Bottom): { 19 }
Packets Switched: 0
Installed: May 3 05:01:09.489 (00:55:07 ago)
Owner: LDP
© 2005 Cisco Systems, Inc.
Version 2.0c
Bytes
T
Switched
O
----------- 0
0
0
0
12–13
Multiprotocol Label Switching (MPLS)
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.
12–14
Version 2.0c
Cisco CRS-1 Essentials
Module 12
MPLS Forwarding Infrastructure
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> ]
© 2005 Cisco Systems, Inc.
Version 2.0c
12–15
Multiprotocol Label Switching (MPLS)
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.
12–16
Version 2.0c
Cisco CRS-1 Essentials
Module 12
Label Distribution Protocol
Label Distribution Protocol
• 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
© 2005 Cisco Systems, Inc.
Version 2.0c
12–17
Multiprotocol Label Switching (MPLS)
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.
12–18
Version 2.0c
Cisco CRS-1 Essentials
Module 12
Label Distribution Protocol
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”.
© 2005 Cisco Systems, Inc.
Version 2.0c
12–19
Multiprotocol Label Switching (MPLS)
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.
_________________________________________________________________
12–20
Version 2.0c
Cisco CRS-1 Essentials
Module 12
Label Distribution Protocol
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 router’s designated transport address for
the TCP session. The router ID is the default transport address.
© 2005 Cisco Systems, Inc.
Version 2.0c
12–21
Multiprotocol Label Switching (MPLS)
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.
12–22
Version 2.0c
Cisco CRS-1 Essentials
Module 12
Label Distribution Protocol
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
© 2005 Cisco Systems, Inc.
Version 2.0c
12–23
Multiprotocol Label Switching (MPLS)
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.
12–24
Version 2.0c
Cisco CRS-1 Essentials
Module 12
Label Distribution Protocol
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
© 2005 Cisco Systems, Inc.
Version 2.0c
12–25
Multiprotocol Label Switching (MPLS)
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 time—Specifies the maximum time the other peer should
wait for this LSR to reconnect after a control channel failure; the
parameter is reconnect-timeout
•
Recovery time—Specifies 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.
12–26
Version 2.0c
Cisco CRS-1 Essentials
Module 12
Label Distribution Protocol
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.
© 2005 Cisco Systems, Inc.
Version 2.0c
12–27
Multiprotocol Label Switching (MPLS)
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.
12–28
Version 2.0c
Cisco CRS-1 Essentials
Module 12
Label Distribution Protocol
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
© 2005 Cisco Systems, Inc.
Version 2.0c
12–29
Multiprotocol Label Switching (MPLS)
Module 12
Displaying LDP Information
Some show commands provide the necessary general LDP parameter
information, such as:
•
Protocol Version—LDP version on this router
•
Router ID—Current router ID
•
Session:
•
−
Hold time—Time session is to be maintained with the LDP peer
without receiving LDP traffic or keepalive message from the peer
−
Keepalive intervals—Interval between consecutive transmissions of
keepalive messages to a peer
−
Backoff parameters—Initial maximum session backoff time
Discovery:
−
−
•
•
•
12–30
Link Hellos:
−
Holdtime—Amount of time a neighbor wants this router to wait
without receiving a hello message
−
Interval—Time between transmission of consecutive hello
messages to neighbors
Targeted Hellos
−
Holdtime—Amount of time a “not-directly-connected” neighbor
wants this router to wait without receiving a hello message
−
Interval—Time between transmission of consecutive hello
messages to neighbors not directly connected
Graceful restart (GR):
−
Status—Enabled or disabled
−
Reconnect Timeout—Amount of time a neighbor wants this router
to wait after LDP communication failure occurs and while holding
MPLS forwarding state information
−
Forwarding State Holdtime—Time this router is willing to hold
MPLS forwarding state information
Timeouts:
−
Binding with no route—Time to wait before deleting invalid route
−
LDP application recovery (with LSD)—Restart recovery time
OOR state—Normal, Major, or Critical
Version 2.0c
Cisco CRS-1 Essentials
Module 12
Label Distribution Protocol
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
© 2005 Cisco Systems, Inc.
Version 2.0c
12–31
Multiprotocol Label Switching (MPLS)
Module 12
LDP discovery information shows interfaces included in the MPLS LDP
implementation, as well as transport addresses for LDP neighbors.
•
Local LDP Identifier—The LDP identifier for the local router, displayed
as address:number, where address is the router ID and number is the
label namespace
•
Interfaces—Interfaces involved in LDP discovery, where:
−
xmit—Indicates the interface is transmitting discovery hello
packets
−
recv—Indicates the interface is receiving discovery hello packets
•
LDP ID—LDP ID of the peer
•
Transport Address—Address associated with this peer
•
Hold time—State 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.
12–32
•
Peer LDP Identifier—LDP identifier of the neighbor (peer) for this
session
•
Graceful Restart—Graceful-restart status (Y or N)
•
TCP connection—TCP connection used to support the LDP session,
shown in the following format:
−
peer IP address.peer port
−
local IP address.local port
•
State—State of the LDP session. Generally this is Oper (operational),
but transient is another possible state
•
Msgs sent/rcvd—Number 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 time—The length of time that this session has been up for (in
hh:mm:ss format)
•
LDP discovery sources—The source(s) of LDP discovery activity that
led to the establishment of this LDP session
•
Addresses bound to this peer—The 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
Cisco CRS-1 Essentials
Module 12
Label Distribution Protocol
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
© 2005 Cisco Systems, Inc.
Version 2.0c
12–33
Multiprotocol Label Switching (MPLS)
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/n—IP prefix and mask for a particular destination
•
rev—Revision number (rev) that is used internally to manage label
distribution for this destination
•
local binding—Locally assigned label for a given prefix
•
remote bindings—Outgoing 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:
12–34
•
Forwarding State Hold timer—State of the hold timer, running or not
running
•
Forwarding Entries—Number 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 neighbors—Number of graceful restartable neighbors
•
Neighbor ID—Router ID of each neighbor
•
Up—Neighbor up or down
•
Connect count—Number of times the same neighbor has re-connected
•
Liveness timers—State of the liveness timer (running or not running)
and its expiration time, if running
•
Recovery timer—State of the recovery timer (running or not running)
and its expiration time, if running
Version 2.0c
Cisco CRS-1 Essentials
Module 12
Label Distribution Protocol
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
local binding: label:20
remote bindings :
lsr:100.10.20.1:0, label:19
lsr:100.10.20.2:0, label:IMP-NULL (rewrite)
100.10.20.3/32 , rev 16
local binding: label:19
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
local binding: label:17
remote bindings :
lsr:100.10.20.1:0, label:IMP-NULL (rewrite)
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
Unlabelled 100.10.20.1/32
17
Unlabelled 142.50.12.0/24
18
Pop Label
142.50.20.0/24
19
Unlabelled 100.10.20.3/32
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
© 2005 Cisco Systems, Inc.
Up
-Y
Y
Connect Count
------------3
3
Liveness Timer
------------------
Version 2.0c
Recovery Timer
------------------
12–35
Multiprotocol Label Switching (MPLS)
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.
12–36
Version 2.0c
Cisco CRS-1 Essentials
Module 12
MPLS Traffic Engineering
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
© 2005 Cisco Systems, Inc.
Version 2.0c
12–37
Multiprotocol Label Switching (MPLS)
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.
12–38
Version 2.0c
Cisco CRS-1 Essentials
Module 12
MPLS Traffic Engineering
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
© 2005 Cisco Systems, Inc.
Version 2.0c
12–39
Multiprotocol Label Switching (MPLS)
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
12–40
Version 2.0c
Cisco CRS-1 Essentials
Module 12
MPLS Traffic Engineering
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)#
© 2005 Cisco Systems, Inc.
Version 2.0c
12–41
Multiprotocol Label Switching (MPLS)
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.
12–42
Version 2.0c
Cisco CRS-1 Essentials
Module 12
MPLS Traffic Engineering
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
© 2005 Cisco Systems, Inc.
P4
P5
PE5
P2
Version 2.0c
12–43
Multiprotocol Label Switching (MPLS)
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.
12–44
Version 2.0c
Cisco CRS-1 Essentials
Module 12
MPLS Traffic Engineering
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
RP/0/RP0/CPU0:P5(config-if)#
100.10.20.5
P1
PE4
© 2005 Cisco Systems, Inc.
P4
P5
PE5
P2
Version 2.0c
12–45
Multiprotocol Label Switching (MPLS)
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.
12–46
Version 2.0c
Cisco CRS-1 Essentials
Module 12
MPLS Traffic Engineering
Creating a Tunnel Destination
• Tunnels require destinations
− IP address or host name
RP/0/RP0/CPU0:P5(config-if)#destination 100.10.20.4
RP/0/RP0/CPU0:P5(config-if)#
100.10.20.5
P1
PE4
P4
P5
PE5
P2
100.10.20.4
© 2005 Cisco Systems, Inc.
Version 2.0c
12–47
Multiprotocol Label Switching (MPLS)
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 interface’s
global bandwidth pool. This is the maximum bandwidth available to this
tunnel.
12–48
Version 2.0c
Cisco CRS-1 Essentials
Module 12
MPLS Traffic Engineering
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
RP/0/RP0/CPU0:P5(config-if)#
100.10.20.5
P1
To here
P5
PE5
From here
PE4
P4
P2
100.10.20.4
© 2005 Cisco Systems, Inc.
Version 2.0c
12–49
Multiprotocol Label Switching (MPLS)
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.
12–50
Version 2.0c
Cisco CRS-1 Essentials
Module 12
MPLS Traffic Engineering
Setting Priority
• Tunnel priority
− Setup
− Hold
RP/0/RP0/CPU0:P5(config-if)#priority 1 1
RP/0/RP0/CPU0:P5(config-if)#
100.10.20.5
P1
PE4
P4
P5
PE5
P2
100.10.20.4
© 2005 Cisco Systems, Inc.
Version 2.0c
12–51
Multiprotocol Label Switching (MPLS)
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.
12–52
Version 2.0c
Cisco CRS-1 Essentials
Module 12
MPLS Traffic Engineering
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
RP/0/RP0/CPU0:P5(config-if)#
100.10.20.5
P1
P5
PE5
Alternate
PE4
P4
P2
100.10.20.4
© 2005 Cisco Systems, Inc.
Version 2.0c
12–53
Multiprotocol Label Switching (MPLS)
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.
12–54
Version 2.0c
Cisco CRS-1 Essentials
Module 12
MPLS Traffic Engineering
Setting IGP Tunnel Usage
• IGP should use the tunnel in path calculation
RP/0/RP0/CPU0:P5(config-if)#autoroute announce
RP/0/RP0/CPU0:P5(config-if)#
100.10.20.5
P1
P5
PE5
Used in
IGP here
PE4
P4
P2
100.10.20.4
© 2005 Cisco Systems, Inc.
Version 2.0c
12–55
Multiprotocol Label Switching (MPLS)
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.
12–56
Version 2.0c
Cisco CRS-1 Essentials
Module 12
MPLS Traffic Engineering
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
© 2005 Cisco Systems, Inc.
Version 2.0c
12–57
Multiprotocol Label Switching (MPLS)
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.
12–58
Version 2.0c
Cisco CRS-1 Essentials
Module 12
MPLS Traffic Engineering
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
© 2005 Cisco Systems, Inc.
Version 2.0c
12–59
Multiprotocol Label Switching (MPLS)
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:
12–60
•
My_system_id—Local IGP router ID and protocol in use for TE
•
Signaling error holddown—Link hold-down timer configured to handle
path error events before excluding link from topology
•
IGP Id—Advertising router identity
•
MPLS TE Id—Tunnel head end ID
•
Link—MPLS TE link type
•
Frag Id—Gateway protocol link state advertisement fragment ID
•
Nbr Intf Address—Neighbor interface address for this link
•
TE metric—cost of this link
•
Physical BW—Physical line rate
•
Max Reservable BW Global—Maximum amount of bandwidth, in
kilobits per second, that you can reserve in this link global pool
•
Max Reservable BW Sub—Maximum amount of bandwidth, in kilobits
per second, that you can reserve in this link sub-pool
•
Total Allocated BW—Total amount of bandwidth (in kbps) allocated at
this priority
•
Global Pool Reservable BW—Amount of available bandwidth
reservable at this priority
•
Sub Pool Reservable BW—Amount of available bandwidth reservable
at this priority
Version 2.0c
Cisco CRS-1 Essentials
Module 12
Examining MPLS-TE Operation
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)
Additional output omitted
© 2005 Cisco Systems, Inc.
Version 2.0c
12–61
Multiprotocol Label Switching (MPLS)
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:
12–62
•
LSP Tunnels Process—Status of the LSP tunnels process
•
RSVP Process—Status of the RSVP process
•
Forwarding—Status of forwarding (enabled or disabled)
•
Head—Summary information about tunnel heads at this device
•
Tails—Summary information about tunnel tails at this device
•
Periodic reoptimization—Time until the next periodic reoptimization
(in seconds)
•
Periodic FRR Promotion—Time until the next periodic FRR promotion
(in seconds)
•
Periodic auto-bw collection—Time until the next periodic auto-bw
collection (in seconds)
•
Router—Summary information for router tunnels
•
Summary—Summary information for FRR
•
Backup—Number of assigned backup tunnels
•
Interfaces—Number of MPLS TE tunnel interfaces
Version 2.0c
Cisco CRS-1 Essentials
Module 12
Examining MPLS-TE Operation
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)
Additional output omitted
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
Additional output omitted
© 2005 Cisco Systems, Inc.
Version 2.0c
12–63
Multiprotocol Label Switching (MPLS)
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.
12–64
Version 2.0c
Cisco CRS-1 Essentials
Module 12
Examining MPLS-TE Operation
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
© 2005 Cisco Systems, Inc.
Version 2.0c
12–65
Multiprotocol Label Switching (MPLS)
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.
12–66
Version 2.0c
Cisco CRS-1 Essentials
Module 12
Examining MPLS-TE Operation
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
© 2005 Cisco Systems, Inc.
Version 2.0c
12–67
Multiprotocol Label Switching (MPLS)
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.
12–68
Version 2.0c
Cisco CRS-1 Essentials
Module 12
Examining MPLS-TE Operation
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
© 2005 Cisco Systems, Inc.
Version 2.0c
12–69
Multiprotocol Label Switching (MPLS)
Module 12
Summary
Multiprotocol Label Switching (MPLS)
In this module, you learned to:
12–70
•
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
Cisco CRS-1 Essentials
Module 12
Review Questions
Multiprotocol Label Switching (MPLS)
1. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
2. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
3. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
4. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
5. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
© 2005 Cisco Systems, Inc.
Version 2.0c
12–71
Multiprotocol Label Switching (MPLS)
Module 12
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
12–72
Version 2.0c
Cisco CRS-1 Essentials
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
After completing this module, you will be able to:
•
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
© 2005 Cisco Systems, Inc.
Version 1.0b
13–1
Craft Works Interface (CWI)
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.
13–2
Version 1.0b
Cisco CRS-1 Essentials
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)
− Routing Policy Language (RPL)
• Flexible interface options
− Choice of both physical and logical views
− Multiple modes to configure the same component
© 2005 Cisco Systems, Inc.
Version 1.0b
13–3
Craft Works Interface (CWI)
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.
13–4
Version 1.0b
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 1.0b
13–5
Craft Works Interface (CWI)
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.
13–6
Version 1.0b
Cisco CRS-1 Essentials
Module 13
CWI Overview
CWI Launch
HTTP
JARJAR
HTTP is used for:
CWI
clients
© 2005 Cisco Systems, Inc.
• Initial connection
• Loading of the CWI
applet and Jar files
Version 1.0b
CRS-1
13–7
Craft Works Interface (CWI)
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.
13–8
Version 1.0b
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 1.0b
13–9
Craft Works Interface (CWI)
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.
13–10
Version 1.0b
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 1.0b
13–11
Craft Works Interface (CWI)
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 Tree—Displays all Cisco IOS XR router objects in a
physical or logical representation
•
Application pane—Displays 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:
13–12
•
Print—Prints 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.
•
Export—Exports the selected report to a text (comma- or tabseparated) or HTML file.
•
Find—Opens the Find dialog box, allowing you to search the active
window for specific text.
•
Find Next—Finds the next instance of the specific text in the active
window.
•
Cut—Removes the currently selected data or text and moves it to the
Clipboard.
•
Copy—Copies the currently selected data or text and moves it to the
Clipboard.
•
Paste—Pastes the data or text from the Clipboard into the currently
selected field.
•
Refresh—Refreshes the content in the active window in the
Configuration Applications pane.
Version 1.0b
Cisco CRS-1 Essentials
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!
© 2005 Cisco Systems, Inc.
Version 1.0b
13–13
Craft Works Interface (CWI)
Module 13
•
Preferences—Opens the Table Preferences dialog box, allowing you to
select the columns to be displayed in the active application table.
•
Help Contents—Opens the CWI Online Help for the currently active
application.
•
Active Alarms—Opens the Alarm Viewer application and displays all
active alarms on the chosen object in the Application Tree.
•
All Alarms—Opens the Alarm Viewer application and displays all
active, cleared, and non-bistate alarms on the chosen object in the
Application Tree.
•
Inventory Viewer—Opens 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 Connection—Shows 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 Dashboard—When 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 Status—Shows 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.
_________________________________________________________________
13–14
Version 1.0b
Cisco CRS-1 Essentials
Module 13
CWI Overview
Desktop Window (Cont.)
Menu bar
Toolbar
Inventory
Tree
Application
pane
Status bar
© 2005 Cisco Systems, Inc.
Version 1.0b
13–15
Craft Works Interface (CWI)
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:
13–16
•
File—Allows 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.
•
Edit—Allows 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.
•
View—Allows 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.
•
Tools—Allows you to open the CWI applications used to manage the
Cisco IOS XR routers.
•
Window—Allows you to close CWI applications, cascade and minimize
open CWI applications in the application pane, and choose the active
CWI application.
•
Help—Allows you to view the online help and the CWI application
version information.
Version 1.0b
Cisco CRS-1 Essentials
Module 13
CWI Overview
Desktop Menu
© 2005 Cisco Systems, Inc.
Version 1.0b
13–17
Craft Works Interface (CWI)
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.
13–18
Version 1.0b
Cisco CRS-1 Essentials
Module 13
CWI Overview
Inventory Tree
© 2005 Cisco Systems, Inc.
Version 1.0b
13–19
Craft Works Interface (CWI)
Module 13
Tools Menu
The tools menu allows you to invoke a specific desktop application:
13–20
•
Active Alarms and All Alarms—Opens the Alarm Viewer
application, which allows you to dynamically view active or all (active,
cleared, and non-bistate) alarm records.
•
Inventory Viewer—Allows you to retrieve object attribute
information, making it available for viewing or export.
•
Rack View—Displays 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 Viewer—Displays a table-based view of the interface
configuration.
•
Configuration Desktop—Opens the Configuration Desktop. All
configuration applications are opened from the Configuration Desktop
Version 1.0b
Cisco CRS-1 Essentials
Module 13
CWI Overview
Tools Menu
© 2005 Cisco Systems, Inc.
Version 1.0b
13–21
Craft Works Interface (CWI)
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.
13–22
Version 1.0b
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 1.0b
13–23
Craft Works Interface (CWI)
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:
13–24
•
TimeStamp—Is the date and time the alarm was generated on the
router
•
Severity—Is one of six color-coded levels of severity: Emergency (red),
Alert (purple), Critical (orange), Error (yellow), Warning (blue) or
Notification or Informational (green)
•
State—Is the state of the alarm: Cleared, None (non-bistate), or Active
•
Alarm ID—Is a cumulative integer assigned to each alarm as it is
generated
•
Source—Is the source from which the message is emitted in the
format: LR name[rack number, slot number, interface or process ID]
Version 1.0b
Cisco CRS-1 Essentials
Module 13
Desktop Applications
Alarm Viewer
Toolbar
Alarm table
Alarm pane
Instructor's Note
One slide for these two pages of text!!
© 2005 Cisco Systems, Inc.
Version 1.0b
13–25
Craft Works Interface (CWI)
Module 13
•
Category—Is a high-level category, such as communications, QOS,
equipment, or environmental
•
Correlated ID—Is 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 Code—Is the name of the alarm
•
Group—Is the external event group, such as link or logging
•
Additional Text—Is 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:
•
Clear—Clears the selected active alarms.
•
Purge—Removes 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 Records—Opens the Correlation Record Viewer from the
Alarm table correlated alarm ID cell.
•
Filter—Opens 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.
13–26
Version 1.0b
Cisco CRS-1 Essentials
Module 13
Desktop Applications
Alarm Viewer (Cont.)
Toolbar
Alarm table
Alarm pane
© 2005 Cisco Systems, Inc.
Version 1.0b
13–27
Craft Works Interface (CWI)
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:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
13–28
Node ID—Is a drilled-down identification of the object with the
following format: LR.<router name>/Rack.<number>/Slot.<number>
Type—Is the type of object
Description—Is a brief description of the object
Vendor Type—Is the vendor type
Name—Is the name of the object
Hardware Revision—Is the hardware revision of the object
Software Revision—Is the software revision running on the object
Firmware Revision—Is the firmware revision running on the object
Serial Number—Is the serial number of the object
Manufacturer Name—Is the name of the manufacturer
Model Name—Is the model name
Alias—Is the alias of the object
Asset ID—Is the asset ID assigned to the object
FRU—Specifies whether the object is a field-replaceable unit
Version 1.0b
Cisco CRS-1 Essentials
Module 13
Desktop Applications
Inventory Viewer
Inventory table
© 2005 Cisco Systems, Inc.
Version 1.0b
13–29
Craft Works Interface (CWI)
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 View—Is 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 View—Provides 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 toolbar’s
Preferences tool. You can choose to display the front chassis, the back
chassis, or both front and rear chassis.
13–30
Version 1.0b
Cisco CRS-1 Essentials
Module 13
Desktop Applications
Rack View
© 2005 Cisco Systems, Inc.
Version 1.0b
13–31
Craft Works Interface (CWI)
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:
13–32
•
Interface—Is the name of the interface
•
Parent Interface—Is the name of the parent interface (if any)
•
Capsulation ID—Is the data-link encapsulation active on the
interface
•
Interface ID—Is the ID assigned to the interface
•
Line State—Is the state of the line
•
Interface State—Is the state of the interface
•
MTU—Is 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
Cisco CRS-1 Essentials
Module 13
Desktop Applications
Interface Viewer
Interface
table
© 2005 Cisco Systems, Inc.
Version 1.0b
13–33
Craft Works Interface (CWI)
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 Test—Checks the Java DNS resolution from the client
(proper DNS name support for the LR). No automatic repair is
provided.
•
LR and Client Connectivity Test—Checks for proper end-to-end
network connectivity between the LR and client. No automatic repair is
provided.
•
HTTP Server Test—Checks whether the HTTP server is running. An
automatic repair is provided in some instances of this test failure.
•
CORBA Services and XML Agent Test—Checks 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.
•
13–34
Notification Test—Checks whether the notification service is active
on the router. An automatic repair is provided in some instances of this
test failure.
Version 1.0b
Cisco CRS-1 Essentials
Module 13
Desktop Applications
Troubleshooter
© 2005 Cisco Systems, Inc.
Version 1.0b
13–35
Craft Works Interface (CWI)
Module 13
Router Configuration
Craft Works Interface (CWI) supports three modes of configuration:
13–36
•
Terminal, Telnet and SSH CLI sessions
•
Configuration Editor and Replace Configuration Editor
•
Graphical configuration
Version 1.0b
Cisco CRS-1 Essentials
Module 13
Router Configuration
Modes
CLI sessions
• Telnet
• Terminal
• SSH Plus
Editors
• Configuration Editor
• Replace Configuration Editor
Graphical configuration
© 2005 Cisco Systems, Inc.
Version 1.0b
13–37
Craft Works Interface (CWI)
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:
Terminal—Provides 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 Plus—Provides 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 Plus—Provides 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.
13–38
Version 1.0b
Cisco CRS-1 Essentials
Module 13
Router Configuration
Telnet Plus and SSH Plus
Toolbar
Command
list
Instructor's Note
One slide for 2 test pages!!
© 2005 Cisco Systems, Inc.
Version 1.0b
13–39
Craft Works Interface (CWI)
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:
13–40
•
Disconnect—Disconnects 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 Commands—Supports batch mode execution of
CLI commands and logging of the batch operation.
•
Load Last Command List—Loads a saved list of commands.
•
Save Last Command List—Saves a list of commands for later use.
•
Clear Last Command List—Clears the command list.
•
Copy Last Command—Copies the last executed command to the
Clipboard; all commands are not automatically copied to the clipboard.
•
Command List—Displays 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
Cisco CRS-1 Essentials
Module 13
Router Configuration
Telnet and SSH Plus (Cont.)
Toolbar
© 2005 Cisco Systems, Inc.
Command
list
Version 1.0b
13–41
Craft Works Interface (CWI)
Module 13
Configuration Editor
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:
13–42
•
CLI Help—By pressing ?, displays a popup list of valid commands and,
by choosing a command from the list, inserts it into the text
•
Command Completion—By pressing <Tab> after entering one or
more characters, causes a complete command to appear in text
•
Cut, Copy and Paste—Operates within Configuration Editor and
from external applications like Notepad
•
Syntax Checking—Allows a selected block of text or the entire
contents of Configuration Editor to be checked for syntax errors
•
Change Tracking—Highlights text in color whenever a command is
deleted (red), modified (blue), not modified (white), or added (green)
Version 1.0b
Cisco CRS-1 Essentials
Module 13
Router Configuration
Configuration Editor
Changed
commands
Added
commands
Deleted
commands
© 2005 Cisco Systems, Inc.
Version 1.0b
13–43
Craft Works Interface (CWI)
Module 13
Replace Configuration Editor
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.
13–44
Version 1.0b
Cisco CRS-1 Essentials
Module 13
Router Configuration
Replace Configuration Editor
© 2005 Cisco Systems, Inc.
Version 1.0b
13–45
Craft Works Interface (CWI)
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:
•
Administration—AAA, Alarm, and User
•
Applications— IEP (IP Explicit Path) and MPLS-TE (Multi-Protocol
Label Switching traffic engineering)
•
Interfaces—Common, Ethernet, and POS (packet-over-SONET)
•
Controllers—SONET
•
Policy—Access Control Lists, Packet Filter, QOS, and Routing Policy
•
Protocols—BGP, ISIS, LDP, OSPF, and RSVP
The Configuration Desktop window has three primary panes:
•
Configuration Applications Tree—Displays all configuration
applications available in the Configuration Desktop.
•
Configuration Applications—Contains the active configuration
applications used to configure the router. Multiple applications can be
opened concurrently in the Configuration Applications pane.
•
Launch Context—Displays 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:
13–46
•
Lock/Unlock
•
Load
•
Save
•
View Uncommitted Configuration
•
Commit
•
Clear
•
Rollback
Version 1.0b
Cisco CRS-1 Essentials
Module 13
Graphical Configuration Applications
Configuration Desktop
Toolbar
Configuration
Applications
Tree
Configuration
Applications
Launch
Context
© 2005 Cisco Systems, Inc.
Version 1.0b
13–47
Craft Works Interface (CWI)
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:
13–48
•
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
Cisco CRS-1 Essentials
Module 13
Graphical Configuration Applications
Graphical Configuration Features
© 2005 Cisco Systems, Inc.
Version 1.0b
13–49
Craft Works Interface (CWI)
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.
13–50
Version 1.0b
Cisco CRS-1 Essentials
Module 13
Graphical Configuration Applications
Configuration Applications Tree and Launch Context
Configuration
Applications
Tree
Launch
Context
© 2005 Cisco Systems, Inc.
Version 1.0b
13–51
Craft Works Interface (CWI)
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:
13–52
•
Lock/Unlock—Locks 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.
•
Load—Opens 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.
•
Save—Opens the Save Uncommitted Configuration dialog box, which
allows you to save an uncommitted configuration to a specified location
on the router.
•
View Uncommitted Configuration—Displays the uncommitted
configuration.
•
Commit—Commits 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.
•
Clear—Stops the current configuration session. The target
configuration is deleted and all active configuration applications are
closed.
•
Rollback—Opens 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
Cisco CRS-1 Essentials
Module 13
Graphical Configuration Applications
Configuration Control Toolbar
Lock/Unlock
View
uncommited
configuration
Load Save
© 2005 Cisco Systems, Inc.
Version 1.0b
Commit
Clear
Rollback
13–53
Craft Works Interface (CWI)
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 columns—Columns in an application table are sorted in
ascending or descending order.
•
Moving columns—CWI 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 records—To 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 text—As 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 data—Inventory 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.
13–54
Version 1.0b
Cisco CRS-1 Essentials
Module 13
Graphical Configuration Applications
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
© 2005 Cisco Systems, Inc.
Version 1.0b
Find next
Copy
Refresh
Help
13–55
Craft Works Interface (CWI)
Module 13
Administration Configuration
The Administration Configuration applications are used to manage user
access, permissions, and alarms. The applications are:
13–56
•
AAA—Allows you to configure and set up system security. All triple “A”
functions can be set up from the AAA application.
•
Alarm Administration—Allows 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 Administration—Allows 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
Cisco CRS-1 Essentials
Module 13
Graphical Configuration Applications
Administration Configuration
© 2005 Cisco Systems, Inc.
Version 1.0b
13–57
Craft Works Interface (CWI)
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:
13–58
•
IEP—Allows 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-TE—Allows 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
Cisco CRS-1 Essentials
Module 13
Graphical Configuration Applications
Applications Configuration
© 2005 Cisco Systems, Inc.
Version 1.0b
13–59
Craft Works Interface (CWI)
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:
13–60
•
Common Attributes—Allows 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.
•
Ethernet—Allows 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.
•
POS—Allows 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
Cisco CRS-1 Essentials
Module 13
Graphical Configuration Applications
Interface Configuration
© 2005 Cisco Systems, Inc.
Version 1.0b
13–61
Craft Works Interface (CWI)
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 Filter—Is 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.
•
QoS—Defines 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 Manager—Allows 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.
______________________________________________________________
13–62
Version 1.0b
Cisco CRS-1 Essentials
Module 13
Graphical Configuration Applications
Policy Configuration
© 2005 Cisco Systems, Inc.
Version 1.0b
13–63
Craft Works Interface (CWI)
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:
13–64
•
BGP— Border Gateway Protocol (BGP) neighbor, session, and address
family (topology) parameters
•
ISIS—Intermediate System-to-Intermediate System (IS-IS) routing
protocol on process, address family (topology), and interface levels
•
LDP—Label Distribution Protocol (LDP) globally and enable or disable
LDP for each interface or neighbor.
•
OSPF—Open Shortest Path First (OSPF) processes, areas, and
interfaces.
•
RSVP—Resource Reservation Protocol (RSVP) configurations for
available interfaces.
Version 1.0b
Cisco CRS-1 Essentials
Module 13
Graphical Configuration Applications
Protocol Configuration
© 2005 Cisco Systems, Inc.
Version 1.0b
13–65
Craft Works Interface (CWI)
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”.
13–66
Version 1.0b
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Inbound
Inbound
Outbound
Inbound
Version 1.0b
13–67
Craft Works Interface (CWI)
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 router’s 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.
13–68
Version 1.0b
Cisco CRS-1 Essentials
Module 13
Getting Started
Launching CWI
http://<router-dns-name>
or
http://<router-ip-address>
© 2005 Cisco Systems, Inc.
Version 1.0b
13–69
Craft Works Interface (CWI)
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.
13–70
Version 1.0b
Cisco CRS-1 Essentials
Module 13
Getting Started
Loading CWI Components
© 2005 Cisco Systems, Inc.
Version 1.0b
13–71
Craft Works Interface (CWI)
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.
13–72
Version 1.0b
Cisco CRS-1 Essentials
Module 13
Getting Started
Checking the Java Runtime Environment
© 2005 Cisco Systems, Inc.
Version 1.0b
13–73
Craft Works Interface (CWI)
Module 13
Testing Communication
If a problem is encountered during login, you can troubleshoot the problem
using the CWI Troubleshooter.
13–74
Version 1.0b
Cisco CRS-1 Essentials
Module 13
Getting Started
Testing Communications
© 2005 Cisco Systems, Inc.
Version 1.0b
13–75
Craft Works Interface (CWI)
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:
13–76
•
CLI / Serial, Terminal Server
•
CLI / Telnet, SSHv1, SSHv2
•
XML / Telnet, SSHv1, SSHv2, CORBA, CORBA SSL
Version 1.0b
Cisco CRS-1 Essentials
Module 13
Getting Started
Logging In
© 2005 Cisco Systems, Inc.
Version 1.0b
13–77
Craft Works Interface (CWI)
Module 13
Summary
Craft Works Interface
In this module, you learned to:
13–78
•
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
Cisco CRS-1 Essentials
Module 13
Review Questions
Craft Works Interface
1. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
2. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
3. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
4. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
5. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
© 2005 Cisco Systems, Inc.
Version 1.0b
13–79
Craft Works Interface (CWI)
Module 13
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
13–80
Version 1.0b
Cisco CRS-1 Essentials
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
After completing this module, you will be able to do the following:
•
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
© 2005 Cisco Systems, Inc.
Version 2.0b
14–1
Data Flow and MQC QoS
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.
14–2
Version 2.0b
Cisco CRS-1 Essentials
Module 14
CRS-1 QoS Hardware Components
CRS-1 QoS Hardware Components
EgressQ
2*FabricQ
SP & FIA
Ingress
PSE
© 2005 Cisco Systems, Inc.
Version 2.0b
Power
Regulators
Egress
PSE
Line Card
CPU
IngressQ
14–3
Data Flow and MQC QoS
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 type’s 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.
14–4
Version 2.0b
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0b
14–5
Data Flow and MQC QoS
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
14–6
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Life of a Packet
Life of a Packet – Step 2
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
2
OC192
Framer
& Optics
PLA
OC192
Framer
& Optics
Fabric
OC192
Framer
& Optics
From
Egress Packet Flow Fabric
© 2005 Cisco Systems, Inc.
Version 2.0b
14–7
Data Flow and MQC QoS
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.
14–8
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Life of a Packet
Life of a Packet – Step 3
To Fabric
Ingress Packet Flow
Fabric
IngressQ
In Q/
Segmenter
RX PSE
L3 Engine
CPUCTRL
GW
From
PLIM
3
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
2
OC192
Framer
& Optics
PLA
OC192
Framer
& Optics
Fabric
OC192
Framer
& Optics
From
Egress Packet Flow Fabric
To Fabric
Ingress Packet Flow
IngressQ
In Q/
Segmenter
CPUCTRL
GW
Fabric
3a
RX PSE
L3 Engine
From
PLIM
3
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
2
OC192
Framer
& Optics
PLA
OC192
Framer
& Optics
Fabric
OC192
Framer
& Optics
From
Egress Packet Flow Fabric
© 2005 Cisco Systems, Inc.
Version 2.0b
14–9
Data Flow and MQC QoS
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.
14–10
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Life of a Packet
Life of a Packet – Step 4
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
4
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
3
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
1
2
OC192
Framer
& Optics
PLA
OC192
Framer
& Optics
Fabric
OC192
Framer
& Optics
From
Egress Packet Flow Fabric
© 2005 Cisco Systems, Inc.
Version 2.0b
14–11
Data Flow and MQC QoS
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.
14–12
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Life of a Packet
Life of a Packet – Step 5
4a
4
Fabric
Cells
IngressQ
In Q/
Segmenter
To Fabric
Ingress Packet Flow
Fabric
Cells
5
Fabric
3a
CPUCTRL
GW
RX PSE
L3 Engine
From
PLIM
3
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
2
OC192
Framer
& Optics
PLA
OC192
Framer
& Optics
Fabric
OC192
Framer
& Optics
From
Egress Packet Flow Fabric
© 2005 Cisco Systems, Inc.
Version 2.0b
14–13
Data Flow and MQC QoS
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.
14–14
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Life of a Packet
Life of a Packet – Step 5a
136 Bytes cells
8
MSC
2 Levels of priority
HP Low latency path
LP Best effort traffic
8 of 8
2
2 of 8
1
S1
1 of 8
S1
S1
S2
S2
S2
S1
16
MSC
2
S1
S1
S3
S3
S3
S2
S2
S2
S3
S3
S3
Multicast support
1M multicast
groups
1
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
© 2005 Cisco Systems, Inc.
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
14–15
Data Flow and MQC QoS
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.
14–16
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Life of a Packet
Life of a Packet – Step 6
4a
4
Fabric
Cells
IngressQ
In Q/
Segmenter
To Fabric
Ingress Packet Flow
Fabric
Cells
5
Fabric
3a
CPUCTRL
GW
RX PSE
L3 Engine
From
PLIM
3
CPU
To
PLIM
FabricQ
FabricQ
Reass.
Reass.
TX PSE
L3 Engine
EgressQ
Out Q
M
I
D
P
L
A
N
E
6
From
Fabric
© 2005 Cisco Systems, Inc.
1
2
OC192
Framer
& Optics
PLA
OC192
Framer
& Optics
Fabric
Fabric
Cells
OC192
Framer
& Optics
OC192
Framer
& Optics
Egress Packet Flow
Version 2.0b
14–17
Data Flow and MQC QoS
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.
14–18
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Life of a Packet
Life of a Packet – Step 7
4a
4
Fabric
Cells
IngressQ
In Q/
Segmenter
To Fabric
Ingress Packet Flow
Fabric
Cells
5
Fabric
3a
CPUCTRL
GW
RX PSE
L3 Engine
CPU
From
PLIM
3
To
PLIM
7
FabricQ
FabricQ
Reass.
Reass.
TX PSE
L3 Engine
EgressQ
Out Q
M
I
D
P
L
A
N
E
6
From
Fabric
© 2005 Cisco Systems, Inc.
1
2
OC192
Framer
& Optics
PLA
OC192
Framer
& Optics
Fabric
Fabric
Cells
OC192
Framer
& Optics
OC192
Framer
& Optics
Egress Packet Flow
Version 2.0b
14–19
Data Flow and MQC QoS
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.
14–20
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Life of a Packet
Life of a Packet – Step 8
Fabric
Cells
4a
IngressQ
In Q/
Segmenter
4
To Fabric
Fabric
Cells
5
Ingress Packet Flow
Fabric
3a
RX PSE
L3 Engine
CPUCTRL
GW
From
PLIM
3
CPU
To
PLIM
8
7
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
1
2
Fabric
6
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.
© 2005 Cisco Systems, Inc.
Version 2.0b
14–21
Data Flow and MQC QoS
Module 14
Once the packet has been queued and shaped it is then passed to the
PLA ASIC on the PLIM.
14–22
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Life of a Packet
Life of a Packet – Step 9
4a
4
Fabric
Cells
IngressQ
In Q/
Segmenter
To Fabric
Ingress Packet Flow
Fabric
Cells
5
Fabric
3a
CPUCTRL
GW
RX PSE
L3 Engine
From
PLIM
3
CPU
To
PLIM
8
7
FabricQ
FabricQ
Reass.
Reass.
TX PSE
L3 Engine
EgressQ
Out Q
M
I
D
P
L
A
N
E
6
From
Fabric
© 2005 Cisco Systems, Inc.
1
2
OC192
Framer
& Optics
PLA
OC192
Framer
& Optics
9
Fabric
Fabric
Cells
OC192
Framer
& Optics
OC192
Framer
& Optics
Egress Packet Flow
Version 2.0b
14–23
Data Flow and MQC QoS
Module 14
10. Finally the packet is sent through the egress port, and onto the
physical link.
14–24
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Life of a Packet
Life of a Packet – Step 10
4a
4
Fabric
Cells
IngressQ
In Q/
Segmenter
To Fabric
Ingress Packet Flow
Fabric
Cells
5
Fabric
3a
CPUCTRL
GW
RX PSE
L3 Engine
From
PLIM
3
CPU
To
PLIM
8
7
FabricQ
FabricQ
Reass.
Reass.
TX PSE
L3 Engine
EgressQ
Out Q
M
I
D
P
L
A
N
E
6
From
Fabric
© 2005 Cisco Systems, Inc.
1
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
14–25
Data Flow and MQC QoS
Module 14
IngressQ queuing and shaping
Features
14–26
•
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
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
P2
To
fabric
P1023
Max BW
Version 2.0b
MDRR/
Aggregate
Shaper
Configurable
Dynamic
Mapping of
Queues to ports
14–27
Data Flow and MQC QoS
Module 14
EgressQ queuing and shaping
Features
•
Packets are passed into the EgressQ from the TX PSE
−
•
•
14–28
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
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Shaping
Min/max BW
G2
MDRR/
Aggregate
Group
To
PLIM
GX
MDRR/ PX
Group
Max BW
Version 2.0b
14–29
Data Flow and MQC QoS
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 cell’s 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.
14–30
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Switch Fabric Cell Structure
Header
FEC
Switch Fabric Cell Structure
Cell Payload (120 bytes)
Two Packet Payload
Packet 1
Header (12 bytes)
Fields (Data Cells)
Bits
Cast (Mcast/Ucast)
1
Fabric Priority
1
Vital
1
Source Address
10
Packet 1 Sequence Number
13
Packet 2 Payload Offset/FGID
2
Trailing Offest
2
Packet Cell Count
7
Packet 1 Cell Sequence Number
7
Destination Address (12 bits)/FGID
18
Snoop/CTB
1
Internal Fabric control bits
32
© 2005 Cisco Systems, Inc.
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
14–31
Data Flow and MQC QoS
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.
14–32
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Switch Fabric Cell Structure
Header
FEC
Switch Fabric Cell Structure (Cont.)
Cell Payload (120 bytes)
Two Packet Payload
Packet 1
Header (12 bytes)
Fields (Data Cells)
Bits
Cast (Mcast/Ucast)
1
Fabric Priority
1
Vital
1
Source Address
10
Packet 1 Sequence Number
13
Packet 2 Payload Offset/FGID
2
Trailing Offest
2
Packet Cell Count
7
Packet 1 Cell Sequence Number
7
Destination Address (12 bits)/FGID
18
Snoop/CTB
1
Internal Fabric control bits
32
© 2005 Cisco Systems, Inc.
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
14–33
Data Flow and MQC QoS
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.
14–34
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Worst Case Fabric Cell Loading
Header
FEC
Worst Case Fabric Cell Loading – Example
Cell Payload (120 bytes)
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 doesn’t 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
Single Packet Payload
Pkt 5 (150 bytes)
© 2005 Cisco Systems, Inc.
Version 2.0b
14–35
Data Flow and MQC QoS
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.
14–36
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Switch Fabric Architecture
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
© 2005 Cisco Systems, Inc.
Version 2.0b
14–37
Data Flow and MQC QoS
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.
_________________________________________________________________
14–38
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Switch Fabric Architecture
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
© 2005 Cisco Systems, Inc.
Version 2.0b
14–39
Data Flow and MQC QoS
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.
14–40
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Switch Fabric Features
Switch Fabric Features
40 Gbps
8 of 8
8
MSC
2 X Speedup
@ S3
136 Bytes cells
2
2 of 8
1
16
S1
S2
MSC
1
1 of 8
S1
S1
S2
S2
S1
S1
S3
S3
S2
S1
2 Levels of priority
HP Low latency path
LP Best effort traffic
2
S3
S2
S2
S3
S3
S3
Multicast support
1M multicast
groups
1296 x 1296 buffered non-blocking switch
Multi-stage Interconnect – 3 Stage Benes
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
© 2005 Cisco Systems, Inc.
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
14–41
Data Flow and MQC QoS
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
14–42
•
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
Cisco CRS-1 Essentials
Module 14
Switch Fabric Features
Switch Fabric Features (Cont.)
40 Gbps
8 of 8
8
MSC
2 X Speedup
@ S3
136 Bytes cells
2
1
2 of 8
16
S1
S2
S1
S1
S1
S1
MSC
1
1 of 8
S2
S2
S1
2 Levels of priority
HP Low latency path
LP Best effort traffic
2
S3
S3
S3
S2
S2
S2
S3
S3
S3
Multicast support
1M multicast
groups
1296 x 1296 buffered non-blocking switch
Multi-stage Interconnect – 3 Stage Benes
topology
© 2005 Cisco Systems, Inc.
Version 2.0b
14–43
Data Flow and MQC QoS
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.
14–44
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Modular QoS Command-Line Interface
Modular QoS Command Line Interface (MQC)
MQC is used to:
• Create traffic policies
• Attach policies to interfaces
• Provide a platform independent Command Line
Syntax
© 2005 Cisco Systems, Inc.
Version 2.0b
14–45
Data Flow and MQC QoS
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.
14–46
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Modular QoS Command-Line Interface
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)
© 2005 Cisco Systems, Inc.
Version 2.0b
14–47
Data Flow and MQC QoS
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.
14–48
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Modular QoS Command-Line Interface
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
© 2005 Cisco Systems, Inc.
Version 2.0b
14–49
Data Flow and MQC QoS
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:
14–50
•
access-group
•
any
•
discard-class
•
dscp
•
mpls
•
precedence
•
protocol
•
qos-group
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Modular QoS Command-Line Interface
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)#
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
© 2005 Cisco Systems, Inc.
Version 2.0b
14–51
Data Flow and MQC QoS
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.
14–52
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Modular QoS Command-Line Interface
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
© 2005 Cisco Systems, Inc.
Version 2.0b
14–53
Data Flow and MQC QoS
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:
14–54
•
bandwidth
•
commit
•
describe
•
do
•
exit
•
no
•
police
•
priority
•
queue-limit
•
random-detect
•
service-policy
•
set
•
shape
•
show
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Modular QoS Command-Line Interface
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)#
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)#
© 2005 Cisco Systems, Inc.
Version 2.0b
14–55
Data Flow and MQC QoS
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.
14–56
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Modular QoS Command-Line Interface
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
Building configuration...
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
!
interface POS0/4/0/2
service-policy output traffic-class
RP/0/RP1/CPU0:P1(config)#
© 2005 Cisco Systems, Inc.
Version 2.0b
14–57
Data Flow and MQC QoS
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.
14–58
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Modular QoS Command-Line Interface
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
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 default
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)
RP/0/RP1/CPU0:P1#
© 2005 Cisco Systems, Inc.
(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
14–59
Data Flow and MQC QoS
Module 14
Summary
Data Flow and MQC QoS
In this module, you learned the following:
14–60
•
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
Cisco CRS-1 Essentials
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
After completing this module, you will be able to:
•
Troubleshoot card-level errors
•
Check for memory problems and leaks
•
Look for process-level errors
•
Troubleshoot ASIC-level problems
© 2005 Cisco Systems, Inc.
Version 2.0
A–1
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.
A–2
Version 2.0
Cisco CRS-1 Essentials
Appendix A
Operational-Level Checks
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)
© 2005 Cisco Systems, Inc.
Version 2.0
A–3
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.
A–4
Version 2.0
Cisco CRS-1 Essentials
Appendix A
Operational-Level Checks
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
© 2005 Cisco Systems, Inc.
Version 2.0
A–5
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.
A–6
Version 2.0
Cisco CRS-1 Essentials
Appendix A
Operational-Level Checks
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
© 2005 Cisco Systems, Inc.
Version 2.0
A–7
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.
A–8
Version 2.0
Cisco CRS-1 Essentials
Appendix A
Troubleshooting CPU Overload
Troubleshooting CPU Overload
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
© 2005 Cisco Systems, Inc.
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
A–9
Troubleshooting
Appendix A
Troubleshooting Memory Issues
Modular Services Card
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.
A–10
Version 2.0
Cisco CRS-1 Essentials
Appendix A
Troubleshooting Memory Issues
Modular Services Card
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
© 2005 Cisco Systems, Inc.
Version 2.0
A–11
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.
A–12
Version 2.0
Cisco CRS-1 Essentials
Appendix A
Troubleshooting Memory Issues
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
© 2005 Cisco Systems, Inc.
Version 2.0
Top two memory
consumingprocesses
Process
tcam_mgr
dllmgr
eth_server
gsp
pkgfs
netio
sysdb_svr_local
fqm
wdsysmon
mpls_lfd
A–13
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
A–14
Version 2.0
Cisco CRS-1 Essentials
Appendix A
Troubleshooting the Data Path
Troubleshooting the Data Path
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)
© 2005 Cisco Systems, Inc.
pse
(METRO) 0
Version 2.0
A–15
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.
A–16
Version 2.0
Cisco CRS-1 Essentials
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>
© 2005 Cisco Systems, Inc.
Version 2.0
A–17
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).
A–18
Version 2.0
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0
A–19
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.
A–20
Version 2.0
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0
A–21
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.
A–22
Version 2.0
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0
A–23
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.
A–24
Version 2.0
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0
A–25
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.
A–26
Version 2.0
Cisco CRS-1 Essentials
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 NoBufferLimit = 0
Rx Pkt errors = 0
Rx NoBuffers = 0
Rx NoBufferLimit = 0
Rx Pkt errors = 0
Rx NoBuffers = 0
Rx NoBufferLimit = 0
Rx Pkt errors = 0
Rx NoBuffers = 0
Rx NoBufferLimit = 0
Rx Pkt errors = 0
Rx NoBuffers = 0
Rx NoBufferLimit = 0
Rx Pkt errors = 0
Rx NoBuffers = 0
Rx NoBufferLimit = 0
© 2005 Cisco Systems, Inc.
Version 2.0
A–27
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 equal—and it most likely never will—to the
number of packets sent because a cell does not always map directly to a
packet received.
A–28
Version 2.0
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0
A–29
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.
A–30
Version 2.0
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0
A–31
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.
A–32
Version 2.0
Cisco CRS-1 Essentials
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 )
© 2005 Cisco Systems, Inc.
Version 2.0
A–33
Troubleshooting
Appendix A
The packet counters are divided by ASIC level, with the second ASIC
information continuing after fabricq ASIC 0.
A–34
Version 2.0
Cisco CRS-1 Essentials
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)
© 2005 Cisco Systems, Inc.
Version 2.0
A–35
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.
A–36
Version 2.0
Cisco CRS-1 Essentials
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
plimasic link1 output packets: 3569577894
plimasic link1 output bytes: 2196621864536
plimasic link2 output packets: 0
Packets received
plimasic link2 output bytes: 0
from the cpuctrl
plimasic link3 output packets: 0
ASIC
plimasic link3 output bytes: 0
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
© 2005 Cisco Systems, Inc.
Version 2.0
A–37
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.
A–38
Version 2.0
Cisco CRS-1 Essentials
Appendix A
Troubleshooting Switch Fabric Cards
SFC Troubleshooting Overview
S1
S1
S1
S1
S1
S1
S1
S1
S1
S1
S1
S1
S1
S1
S1
S3
Sprayer
Port
S1
LINE CARD
© 2005 Cisco Systems, Inc.
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
A–39
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.
A–40
Version 2.0
Cisco CRS-1 Essentials
Appendix A
Troubleshooting Switch Fabric Cards
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
© 2005 Cisco Systems, Inc.
Version 2.0
A–41
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.
A–42
Version 2.0
Cisco CRS-1 Essentials
Appendix A
Troubleshooting Switch Fabric Cards
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
© 2005 Cisco Systems, Inc.
Version 2.0
A–43
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.
A–44
Version 2.0
Cisco CRS-1 Essentials
Appendix A
Troubleshooting Switch Fabric Cards
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
© 2005 Cisco Systems, Inc.
Version 2.0
A–45
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.
A–46
Version 2.0
Cisco CRS-1 Essentials
Appendix A
Troubleshooting Switch Fabric Cards
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
© 2005 Cisco Systems, Inc.
Total uptime and
percentage of uptime
since an error was
indicated
Version 2.0
A–47
Troubleshooting
Appendix A
Summary
Troubleshooting
In this module, you learned to:
A–48
•
Troubleshoot card-level errors
•
Check for memory problems and leaks
•
Look for process-level errors
•
Troubleshoot ASIC-level problems
Version 2.0
Cisco CRS-1 Essentials
Appendix B
Student Evaluation
© 2005 Cisco Systems, Inc.
Version 2.0
B–1
Part Number: XX#######-XX-X
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 That’s 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
v
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
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0
vii
viii
Version 2.0
Cisco CRS-1 Essentials
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 student’s 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
student’s 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
© 2005 Cisco Systems, Inc.
Version 2.0
ix
x
•
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
Cisco CRS-1 Essentials
Contents
Course Overview.....................................................................................................................v
Course Agenda..................................................................................................................... vii
Course Introduction and Objectives ................................................................ ix
Overview ................................................................................................................................ix
Module 1 .......................................................................................................... 1–1
Overview .............................................................................................................................1–1
Cisco CRS-1 Carrier Routing Systems..............................................................................1–2
Market Place Demands ......................................................................................................1–4
Current PoP Design............................................................................................................1–6
Getting the CRS-1 into the Network.................................................................................1–8
Cisco CRS-1 System Configurations ...............................................................................1–12
Cisco CRS-1 Line Card Chassis.......................................................................................1–16
Cisco CRS-1 Interfaces.....................................................................................................1–18
Summary...........................................................................................................................1–20
Module 2 .......................................................................................................... 2–1
Overview .............................................................................................................................2–1
CRS-1 16-Slot Line Card Chassis......................................................................................2–2
CRS-1 16-Slot Line Card Chassis Components................................................................2–4
CRS-1 16-Slot Line Card Chassis Slot Numbering ........................................................2–10
CRS-1 16-Slot Line Card Chassis Power System ...........................................................2–12
CRS-1 16-Slot Line Card Chassis AC Power Shelves and Rectifiers............................2–22
CRS-1 16-Slot Line Card Chassis DC Power System ....................................................2–30
CRS-1 16-Slot Line Card Chassis Alarm Module...........................................................2–42
CRS-1 16-Slot Chassis Line Card Chassis Cooling System...........................................2–48
CRS-1 16-Slot Chassis Single Line Card Switch Fabric................................................2–66
CRS-1 16-Slot Chassis S123 Switch Fabric Card...........................................................2–68
CRS-1 16-Slot Chassis Route Processor (RP) .................................................................2–74
Summary...........................................................................................................................2–88
© 2005 Cisco Systems, Inc.
Version 2.0
xi
Module 3 .......................................................................................................... 3–1
Overview .............................................................................................................................3–1
CRS-1 8-Slot Line Card Chassis........................................................................................3–2
CRS-1 8-Slot Line Card Chassis Components..................................................................3–4
CRS-1 8-Slot Line Card Chassis Slot Numbering ..........................................................3–10
CRS-1 8-Slot Line Card Chassis Power System .............................................................3–12
CRS-1 8-Slot AC Power System.......................................................................................3–18
CRS-1 8-Slot DC Power System ......................................................................................3–26
CRS-1 8-Slot Line Card Chassis Cooling System...........................................................3–32
CRS-1 8-Slot Line Card Chassis Switch Fabric .............................................................3–44
CRS-1 8-Slot Line Card Chassis Route Processor..........................................................3–50
Summary...........................................................................................................................3–62
Module 4 .......................................................................................................... 4–1
Overview .............................................................................................................................4–1
Modular Services Card.......................................................................................................4–2
DRP Architecture - LC Chassis .........................................................................................4–6
Physical Layer Module (PLIM)..........................................................................................4–8
Shared Port Adapters (SPAs) and SPA Interface Processor-800 (SIP-800) .................4–36
SIP Bandwidth Oversubscription....................................................................................4–44
4-Port OC-3c/STM-1 SPA.................................................................................................4–49
1-Port OC-192c/STM-64 PoS/RPR XFP SPA ..................................................................4–53
8-Port Gigabit Ethernet SPA ...........................................................................................4–57
Summary...........................................................................................................................4–61
Module 5 .......................................................................................................... 5–1
Overview .............................................................................................................................5–1
Switch Fabric Chassis ........................................................................................................5–2
Switch Fabric Components ................................................................................................5–6
System Configurations .......................................................................................................5–8
Switch Fabric Chassis Interconnections .........................................................................5–12
In-service upgrade from Standalone to Multi-Shelf.......................................................5–16
CRS-1 Management System Control Plane and Shelf Controller Gigabit Ethernet (SCGE) card ............................................................................................................................5–18
Summary...........................................................................................................................5–22
Module 6 .......................................................................................................... 6–1
Overview .............................................................................................................................6–1
xii
Version 2.0
Cisco CRS-1 Essentials
Cisco IOS XR Architecture.................................................................................................6–2
High Availability ................................................................................................................6–4
Scalability .........................................................................................................................6–24
Configuration Operations ................................................................................................6–36
Configuration Basics ........................................................................................................6–44
Summary...........................................................................................................................6–68
Module 7 .......................................................................................................... 7–1
Overview .............................................................................................................................7–1
Cisco IOS XR Command Modes.........................................................................................7–2
Configuration Operations ................................................................................................7–14
Miscellaneous CLI Commands ........................................................................................7–52
Process Management........................................................................................................7–62
Summary...........................................................................................................................7–72
Module 8 .......................................................................................................... 8–1
Overview .............................................................................................................................8–1
Cisco IOS XR Software Packaging ....................................................................................8–2
Package Management ......................................................................................................8–20
Software Installation Review...........................................................................................8–36
Summary...........................................................................................................................8–46
Module 9 .......................................................................................................... 9–1
Overview .............................................................................................................................9–1
Cisco IOS XR Security Overview.......................................................................................9–2
Cisco IOS XR Security Implementation..........................................................................9–10
Security Configuration .....................................................................................................9–42
Access Control Lists .........................................................................................................9–58
Summary...........................................................................................................................9–70
Module 10 ...................................................................................................... 10–1
Overview ...........................................................................................................................10–1
Border Gateway Protocol (BGP) ......................................................................................10–2
Open Shortest Path First (OSPF) .................................................................................10–28
Intermediate System-Intermediate System (IS-IS) .....................................................10–48
Multicast Routing ...........................................................................................................10–62
Summary.........................................................................................................................10–74
© 2005 Cisco Systems, Inc.
Version 2.0
xiii
Module 11 ...................................................................................................... 11–1
Overview ...........................................................................................................................11–1
RPL Overview ...................................................................................................................11–2
RPL Description..............................................................................................................11–12
BGP Route Attributes and Operations .........................................................................11–48
Converting Route Maps to RPL Policies .......................................................................11–78
RPL-Specific CLI Commands ......................................................................................11–102
Summary.......................................................................................................................11–110
Module 12 ...................................................................................................... 12–1
Overview ...........................................................................................................................12–1
MPLS Forwarding Infrastructure ...................................................................................12–2
Label Distribution Protocol............................................................................................12–16
MPLS Traffic Engineering .............................................................................................12–34
Summary.........................................................................................................................12–68
Module 13 ...................................................................................................... 13–1
Overview ...........................................................................................................................13–1
CWI Overview...................................................................................................................13–2
Desktop Applications......................................................................................................13–24
Router Configuration .....................................................................................................13–36
Graphical Configuration Applications ..........................................................................13–46
Getting Started ...............................................................................................................13–66
Summary.........................................................................................................................13–78
Module 14 ...................................................................................................... 14–1
Overview ...........................................................................................................................14–1
CRS-1 QoS Hardware Components.................................................................................14–2
Life of a Packet .................................................................................................................14–4
IngressQ queuing and shaping ......................................................................................14–26
EgressQ queuing and shaping .......................................................................................14–28
Switch Fabric Cell Structure .........................................................................................14–30
Worst Case Fabric Cell Loading ....................................................................................14–34
Switch Fabric Architecture ............................................................................................14–36
Switch Fabric Features ..................................................................................................14–40
Modular QoS Command-Line Interface ........................................................................14–44
Summary.........................................................................................................................14–60
xiv
Version 2.0
Cisco CRS-1 Essentials
Append A
A–1
Troubleshooting
A-1
Appendix B ..................................................................................................... B–1
Student Evaluation ........................................................................................ B–1
© 2005 Cisco Systems, Inc.
Version 2.0
xv
xvi
Version 2.0
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0
1–1
Cisco CRS-1 Carrier Routing System
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.
1–2
Version 2.0b
Cisco CRS-1 Essentials
Module 1
Cisco CRS-1 Carrier Routing Systems
Cisco CRS-1 Carrier Routing Systems - Overview
Next Generation Core
CRS-1
© 2005 Cisco Systems, Inc.
• 40 Gbps routing
• Multishelf scale
• Foundation for core
consolidation
Version 2.0b
1–3
Cisco CRS-1 Carrier Routing System
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 provider’s 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.
1–4
Version 2.0b
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0b
1–5
Cisco CRS-1 Carrier Routing System
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.
1–6
Version 2.0b
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0b
1–7
Cisco CRS-1 Carrier Routing System
Module 1
Getting the CRS-1 into the Network
Core Layer Insertion
The CRS-1 allows the replacement of multiple platforms in today’s 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.
1–8
Version 2.0b
Cisco CRS-1 Essentials
Module 1
Getting the CRS-1 into the Network
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
© 2005 Cisco Systems, Inc.
Version 2.0b
1–9
Cisco CRS-1 Carrier Routing System
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 PoP’s
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.
1–10
Version 2.0b
Cisco CRS-1 Essentials
Module 1
Getting the CRS-1 into the Network
Core Layer Consolidation
STM-64/256
Core
10GE/STM-16/64DPT
STM-256 Ch DS-3
CRS-1
5 Logical Router
partitions
Distribution
Aggregation
© 2005 Cisco Systems, Inc.
STM-4/16 DPT
1G/10GE
GSR120/124xx
CAT6K
Version 2.0b
1GE/10GE
STM-4/16
1–11
Cisco CRS-1 Carrier Routing System
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 Router—up to 6 line card chassis and one SFC, with support
for up to 96 MSCs
12 – 23 Terabit Router—up to 18 line card chassis and two SFC, with
support for up to 288 MSCs
23 – 46 Terabit Router—up to 36 line card chassis and 4 SFC, with support
for up to 576 MSCs
46 – 92 Terabit Router—up to 72 line card chassis and 8 SFC, with support
for up to 1152 MSCs
1–12
Version 2.0b
Cisco CRS-1 Essentials
Module 1
Cisco CRS-1 System Configurations
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
© 2005 Cisco Systems, Inc.
Version 2.0b
1–13
Cisco CRS-1 Carrier Routing System
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.
1–14
Version 2.0b
Cisco CRS-1 Essentials
Module 1
Cisco CRS-1 System Configurations
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
© 2005 Cisco Systems, Inc.
Version 2.0b
1–15
Cisco CRS-1 Carrier Routing System
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.
1–16
Version 2.0b
Cisco CRS-1 Essentials
Module 1
Cisco CRS-1 Line Card Chassis
Cisco CRS-1 Line Card Chassis
CRS-1 16-slot
CRS-1 8-slot
© 2005 Cisco Systems, Inc.
Version 2.0b
1–17
Cisco CRS-1 Carrier Routing System
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
•
1-port OC-768c/STM-256c POS/DPT
•
8-port 10 Gigabit Ethernet
SIP & SPAs
•
1–18
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
Cisco CRS-1 Essentials
Module 1
Cisco CRS-1 Interfaces
Cisco CRS-1 Cards
• PLIMs
− 16-port OC-48c/STM-16c POS/DPT
− 4-port OC-192c/STM-64c POS/DPT
− 1-port OC-768c/STM-256c POS/DPT
− 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
© 2005 Cisco Systems, Inc.
Version 2.0b
1–19
Cisco CRS-1 Carrier Routing System
Module 1
Summary
Cisco IOS XR Hardware and Platform Overview
In this module, you learned the following:
1–20
•
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
Cisco CRS-1 Essentials
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
After completing this module, you will be able to do the following:
•
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
•
List and describe the features and functions of the CRS-1 16-slot line
card chassis alarm modules
•
List and describe the features and functions of the CRS-1 16-slot line
card chassis cooling system
•
List and describe the features and functions of the CRS-1 16-slot line
card chassis switch fabric
•
List and describe the features and functions of the CRS-1 16-slot line
card chassis Route Processor
© 2005 Cisco Systems, Inc.
Version 2.0b
2–1
CRS-1 16-Slot Line Card Chassis Hardware
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:
2–2
•
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
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
© 2005 Cisco Systems, Inc.
Version 2.0b
2–3
CRS-1 16-Slot Line Card Chassis Hardware
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 chassis—this 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.
2–4
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Line Card Chassis Components
Components – PLIM Side
1
2
3
4
5
© 2005 Cisco Systems, Inc.
Version 2.0b
2–5
CRS-1 16-Slot Line Card Chassis Hardware
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
2–6
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Line Card Chassis Components
MSC Side
1
2
3
4
5
6
© 2005 Cisco Systems, Inc.
Version 2.0b
2–7
CRS-1 16-Slot Line Card Chassis Hardware
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.
2–8
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Line Card Chassis Components
Cable Management
Cable-management bracket has telescoping feature
that allows bracket to be extended when chassis is
upgraded with higher-density cards.
Cablemanagement
© 2005 Cisco Systems, Inc.
Version 2.0b
2–9
CRS-1 16-Slot Line Card Chassis Hardware
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).
2–10
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Line Card Chassis Slot Numbering
CRS-1 16-Slot Line Card Chassis Slot Numbering
© 2005 Cisco Systems, Inc.
Version 2.0b
2–11
CRS-1 16-Slot Line Card Chassis Hardware
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:
2–12
•
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
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Line Card Chassis Power System
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 OR’ing
diodes or EMI filters
© 2005 Cisco Systems, Inc.
Version 2.0b
2–13
CRS-1 16-Slot Line Card Chassis Hardware
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 bar—an integral part of the
chassis—fails
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.
2–14
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Line Card Chassis Power System
Power Architecture
Power system architecture provides fully redundant AC or DC
power
Line card chassis still operates normally if:
• One AC rectifier or DC PEM fails
• 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
© 2005 Cisco Systems, Inc.
Version 2.0b
2–15
CRS-1 16-Slot Line Card Chassis Hardware
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.
2–16
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Line Card Chassis Power System
Power Distribution
© 2005 Cisco Systems, Inc.
Version 2.0b
2–17
CRS-1 16-Slot Line Card Chassis Hardware
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:
2–18
•
Power module A0 powers load zones 1 and 2 (Z1 and Z2)
•
Power module A1 powers load zones 3 and 4 (Z3 and Z4)
•
Power module A2 powers load zones 5 and 6 (Z5 and Z6)
•
Power module B0 powers load zones 1 and 2 (Z1 and Z2)
•
Power module B1 powers load zones 3 and 4 (Z3 and Z4)
•
Power module B2 powers load zones 5 and 6 (Z5 and Z6)
•
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
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Line Card Chassis Power System
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)
© 2005 Cisco Systems, Inc.
Version 2.0b
2–19
CRS-1 16-Slot Line Card Chassis Hardware
Module 2
Line Card Chassis Load Zones
The Line Card Chassis contains six load zones as follows:
2–20
•
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 3 (Z3) powers chassis slots 4, 5, 6, and 7
•
Load zone 4 (Z4) powers chassis slots 8, 9, 10, and 11
•
Load zone 5 (Z5) powers chassis slots FC1, RP0 (PLIM side) and SM4,
SM5, SM6 and SM7 (MSC side)
•
Load zone 6 (Z6) powers chassis slots 12, 13, 14, and 15
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Line Card Chassis Power System
Line Card Chassis Load Zones
© 2005 Cisco Systems, Inc.
Version 2.0b
2–21
CRS-1 16-Slot Line Card Chassis Hardware
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.
2–22
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Line Card Chassis AC Power Shelves and Rectifiers
CRS-1 16-Slot Line Card Chassis AC Power Shelves and Rectifiers
AC Power
Shelf
© 2005 Cisco Systems, Inc.
AC Rectifiers
Version 2.0b
2–23
CRS-1 16-Slot Line Card Chassis Hardware
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.
_________________________________________________________________
2–24
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Line Card Chassis AC Power Shelves and Rectifiers
AC Power Architecture
© 2005 Cisco Systems, Inc.
Version 2.0b
2–25
CRS-1 16-Slot Line Card Chassis Hardware
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:
•
Fault—A 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 Fail—Indicates that the AC input voltage is out of range.
•
Circuit Breaker Trip—Indicates that the AC rectifier circuit breaker
has tripped.
•
Over temperature—Indicates that the AC rectifier has exceeded the
maximum allowable operating temperature.
•
AC Rectifier Present—Indicates 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.
2–26
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Line Card Chassis AC Power Shelves and Rectifiers
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
© 2005 Cisco Systems, Inc.
Version 2.0b
2–27
CRS-1 16-Slot Line Card Chassis Hardware
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.
2–28
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Line Card Chassis AC Power Shelves and Rectifiers
AC Rectifier Status Indicators
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
© 2005 Cisco Systems, Inc.
Version 2.0b
2–29
CRS-1 16-Slot Line Card Chassis Hardware
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.
2–30
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Line Card Chassis DC Power System
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
© 2005 Cisco Systems, Inc.
Version 2.0b
2–31
CRS-1 16-Slot Line Card Chassis Hardware
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.
2–32
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Line Card Chassis DC Power System
DC Power Shelf Input Connectors
Grnd
© 2005 Cisco Systems, Inc.
6 Input Connectors
Version 2.0b
2–33
CRS-1 16-Slot Line Card Chassis Hardware
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.
2–34
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Line Card Chassis DC Power System
DC Power Shelf Architecture
© 2005 Cisco Systems, Inc.
Version 2.0b
2–35
CRS-1 16-Slot Line Card Chassis Hardware
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:
2–36
•
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
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Line Card Chassis DC Power System
DC PEM
LEDs
© 2005 Cisco Systems, Inc.
Version 2.0b
2–37
CRS-1 16-Slot Line Card Chassis Hardware
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:
•
Fault—Summarizes 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 Fail—Indicates that the PEM DC input voltage is out of
range.
•
Circuit Breaker Trip—Indicates that the PEM circuit breaker has
tripped.
•
Over temperature—Indicates that the PEM has exceeded the
maximum allowable operating temperature.
•
PEM Present—Indicates 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.
2–38
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Line Card Chassis DC Power System
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
© 2005 Cisco Systems, Inc.
Version 2.0b
2–39
CRS-1 16-Slot Line Card Chassis Hardware
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.
2–40
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Line Card Chassis DC Power System
DC PEM Status Indicators
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
© 2005 Cisco Systems, Inc.
Version 2.0b
2–41
CRS-1 16-Slot Line Card Chassis Hardware
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).
2–42
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Line Card Chassis Alarm Module
CRS-1 16-Slot Line Card Chassis Alarm Module
Ext.
Alarm
connector
LED
Indicators
Alpha
Indicators
© 2005 Cisco Systems, Inc.
Version 2.0b
2–43
CRS-1 16-Slot Line Card Chassis Hardware
Module 2
Alarm Module Functions
The alarm module provides the following:
•
•
Alarm outputs, both relay and LEDs:
−
LEDs—Three 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.
−
Alpha—Display will show the chassis ID
−
Relay—The 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
−
2–44
The maximum rating for the alarm circuit is 2A, 50V
•
PEM or AC Rectifier status monitoring
•
Alarm monitoring
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Line Card Chassis Alarm Module
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
© 2005 Cisco Systems, Inc.
Version 2.0b
2–45
CRS-1 16-Slot Line Card Chassis Hardware
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.
2–46
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Line Card Chassis Alarm Module
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
© 2005 Cisco Systems, Inc.
Version 2.0b
2–47
CRS-1 16-Slot Line Card Chassis Hardware
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:
2–48
•
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
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Chassis Line Card Chassis Cooling System
CRS-1 16-Slot Chassis Line card Chassis cooling System - Overview
The complete line card chassis cooling system
includes:
• 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
© 2005 Cisco Systems, Inc.
Version 2.0b
2–49
CRS-1 16-Slot Line Card Chassis Hardware
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.
2–50
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Chassis Line Card Chassis Cooling System
Line Card Chassis Airflow
© 2005 Cisco Systems, Inc.
Version 2.0b
2–51
CRS-1 16-Slot Line Card Chassis Hardware
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
−
Two fan controller cards
−
Control software and logic
There are four normal operating fan-speeds, plus one high-speed setting
used when a fan tray has failed.
2–52
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Chassis Line Card Chassis Cooling System
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
− Two fan controller cards
− Control software and logic
There are four normal operating fan-speeds, plus one high-speed
setting used when a fan tray has failed.
© 2005 Cisco Systems, Inc.
Version 2.0b
2–53
CRS-1 16-Slot Line Card Chassis Hardware
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:
2–54
•
Nine fans—Each 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 board—The board terminates signals to and from the fans,
filters common mode noise, and houses tracking and indicator parts.
•
A front-panel status LED—The LED indicates the following:
−
Green—The fan tray is operating normally
−
Yellow—The fan tray has experienced a failure and should be
replaced
−
Off—An unknown state exists or the LED is faulty
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Chassis Line Card Chassis Cooling System
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
© 2005 Cisco Systems, Inc.
Version 2.0b
2–55
CRS-1 16-Slot Line Card Chassis Hardware
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:
2–56
•
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
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Chassis Line Card Chassis Cooling System
Line Card Chassis Fan Controller Card
BITs/SETs
Ext. Clk 1
BITs/SETs
Ext. Clk 2
Status
LEDs
© 2005 Cisco Systems, Inc.
Version 2.0b
2–57
CRS-1 16-Slot Line Card Chassis Hardware
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.
2–58
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Chassis Line Card Chassis Cooling System
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
© 2005 Cisco Systems, Inc.
Version 2.0b
2–59
CRS-1 16-Slot Line Card Chassis Hardware
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.
2–60
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Chassis Line Card Chassis Cooling System
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
© 2005 Cisco Systems, Inc.
Version 2.0b
2–61
CRS-1 16-Slot Line Card Chassis Hardware
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.
2–62
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Chassis Line Card Chassis Cooling System
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
© 2005 Cisco Systems, Inc.
Version 2.0b
2–63
CRS-1 16-Slot Line Card Chassis Hardware
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.
2–64
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Chassis Line Card Chassis Cooling System
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
© 2005 Cisco Systems, Inc.
Version 2.0b
2–65
CRS-1 16-Slot Line Card Chassis Hardware
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.
2–66
Version 2.0b
Cisco CRS-1 Router Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0b
2–67
CRS-1 16-Slot Line Card Chassis Hardware
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.
2–68
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Chassis S123 Switch Fabric Card
CRS-1 16-Slot Chassis S123 Switch Fabric Card
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.
© 2005 Cisco Systems, Inc.
Version 2.0b
2–69
CRS-1 16-Slot Line Card Chassis Hardware
Module 2
S123 Functional Blocks
The functional blocks of the S123 switch fabric card are:
1. S1 switch element—Receives 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 element—Receives 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 element—Receives data cells from the S2 stage and performs
switching and fabric speedup.
4. Service processor—Provides 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 modules—Take –48 VDC input power from the midplane and
converts it into the voltages required by the switch fabric card’s
components.
6. Alphanumeric display—Displays S123 switch fabric card messages.
This display is under software control.
7. Status LED—Indicates status of the S123 switch fabric card. Green
indicates module OK.
2–70
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Chassis S123 Switch Fabric Card
S123 Functional Blocks
3
2
1
Slots 0-7
Egress
Ingress
from
MSCs
To
MSCs and
RPS
Slots 8-17
(To fabric)
(From
Fabric)
4
5
6
7
Note: Slots 16 & 17 are the active and standby RPs
© 2005 Cisco Systems, Inc.
Version 2.0b
2–71
CRS-1 16-Slot Line Card Chassis Hardware
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:
2–72
•
A board “OK” LED
•
An alphanumeric display
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Chassis S123 Switch Fabric Card
S123 Physical Overview
Alpha
Status
LED
© 2005 Cisco Systems, Inc.
Version 2.0b
2–73
CRS-1 16-Slot Line Card Chassis Hardware
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:
2–74
•
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
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Chassis Route Processor (RP)
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
© 2005 Cisco Systems, Inc.
Version 2.0b
2–75
CRS-1 16-Slot Line Card Chassis Hardware
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
2–76
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Chassis Route Processor (RP)
CRS-1 16-Slot Chassis RP Front Panel and Memory Options
SMP
CPUs
Memory
Modules
© 2005 Cisco Systems, Inc.
Version 2.0b
2–77
CRS-1 16-Slot Line Card Chassis Hardware
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.
2–78
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Chassis Route Processor (RP)
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
© 2005 Cisco Systems, Inc.
Version 2.0b
2–79
CRS-1 16-Slot Line Card Chassis Hardware
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.
2–80
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Chassis Route Processor (RP)
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
© 2005 Cisco Systems, Inc.
Version 2.0b
2–81
CRS-1 16-Slot Line Card Chassis Hardware
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 RP’s 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.
2–82
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Chassis Route Processor (RP)
Block Diagram
LC FE
links
CTL GE link
FE/GE
switch
4
CTL GE link
2
PCI
9
7
Q
links
To
fabric
From
fabric
1
CPU
MEM
IF
CTL
5
CPU
IDE
PCMCIA
2
6
8
Aux and console
Management GE link
FPGA
Midplane
© 2005 Cisco Systems, Inc.
3
Card presence detect
RP mastership
PROM presence
10
Version 2.0b
2–83
CRS-1 16-Slot Line Card Chassis Hardware
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.
2–84
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Chassis Route Processor (RP)
Block Diagram (Cont.)
LC FE
links
CTL GE link
FE/GE
switch
4
CTL GE link
2
PCI
9
7
Q
links
To
fabric
From
fabric
1
CPU
MEM
IF
CTL
5
CPU
IDE
PCMCIA
2
6
8
Aux and console
Management GE link
FPGA
Midplane
© 2005 Cisco Systems, Inc.
3
Card presence detect
RP mastership
PROM presence
10
Version 2.0b
2–85
CRS-1 16-Slot Line Card Chassis Hardware
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.
2–86
Version 2.0b
Cisco CRS-1 Router Essentials
Module 2
CRS-1 16-Slot Chassis Route Processor (RP)
Route Processor (RP) Active and Standby Arbitration
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.
5. Software on each reads its “Active” signal, and branches accordingly to
“Primary” or “Standby” code.
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.
© 2005 Cisco Systems, Inc.
Version 2.0b
2–87
CRS-1 16-Slot Line Card Chassis Hardware
Module 2
Summary
CRS-1 16-Slot Line Card Chassis Hardware
In this module, you learned the following:
2–88
•
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
components that comprise the CRS-1 16-slot Line Card chassis
•
To list and describe the features and functions of the CRS-1 16-slot line
card chassis power system
•
To list and describe the features and functions of the CRS-1 16-slot line
card chassis alarm modules
•
To list and describe the features and functions of the CRS-1 16-slot line
card chassis cooling system
•
To list and describe the features and functions of the CRS-1 16-slot line
card chassis Switch Fabric
•
To list and describe the features and functions of the CRS-1 16-slot line
card chassis Route Processor
Version 2.0b
Cisco CRS-1 Router Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Hardware
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
After completing this module, you will be able to do the following:
•
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
components that comprise the CRS-1 8-slot Line Card chassis
•
List and describe the features and functions of the CRS-1 8-slot line
card chassis power system
•
List and describe the features and functions of the CRS-1 8-slot line
card chassis Switch Fabric
•
List and describe the features and functions of the CRS-1 8-slot line
card chassis cooling system
•
List and describe the features and functions of the CRS-1 8-slot line
card chassis Route Processor
© 2005 Cisco Systems, Inc.
Version 2.0b
3–1
CRS-1 8-Slot Line Card Chassis Hardware
Module 3
CRS-1 8-Slot Line Card Chassis
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
3–2
•
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
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
© 2005 Cisco Systems, Inc.
Version 2.0b
3–3
CRS-1 8-Slot Line Card Chassis Hardware
Module 3
CRS-1 8-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 chassis—this 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.
3–4
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Components
CRS-1 8-Slot Line Card Chassis Components - PLIM Side
© 2005 Cisco Systems, Inc.
Version 2.0b
3–5
CRS-1 8-Slot Line Card Chassis Hardware
Module 3
MSC Side
The MSC side of the chassis is considered the rear of the chassis—this 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.
3–6
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Components
MSC Side
© 2005 Cisco Systems, Inc.
Version 2.0b
3–7
CRS-1 8-Slot Line Card Chassis Hardware
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.
3–8
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Components
Cable Management
Cable-management bracket has telescoping feature
that allows bracket to be extended when chassis is
upgraded with higher-density cards.
© 2005 Cisco Systems, Inc.
Version 2.0b
3–9
CRS-1 8-Slot Line Card Chassis Hardware
Module 3
CRS-1 8-Slot Line Card Chassis Slot Numbering
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).
3–10
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Slot Numbering
CRS-1 8-Slot Line Card Chassis Slot Numbering
Front
© 2005 Cisco Systems, Inc.
Rear
Version 2.0b
3–11
CRS-1 8-Slot Line Card Chassis Hardware
Module 3
CRS-1 8-Slot Line Card Chassis Power System
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.
3–12
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Power System
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
© 2005 Cisco Systems, Inc.
Version 2.0b
3–13
CRS-1 8-Slot Line Card Chassis Hardware
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 AC rectifier or DC PEM fails
•
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.
3–14
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Power System
Power Architecture
© 2005 Cisco Systems, Inc.
Version 2.0b
3–15
CRS-1 8-Slot Line Card Chassis Hardware
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
3–16
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Power System
Chassis Load Zones
© 2005 Cisco Systems, Inc.
Version 2.0b
3–17
CRS-1 8-Slot Line Card Chassis Hardware
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 PDUs—Contain 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:
−
3–18
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
CRS-1 8-Slot AC Power System - Overview
Provides:
• 7.5 kW (Delta or Wye 3-phase) of power to
chassis
• Two AC PDUs—two independent AC power
sources required
• Two AC Rectifiers—Converts 200- to- 240 VAC to
54.5 VDC
− Each rectifier has:
♦ its own circuit breaker
♦ cooling fan
© 2005 Cisco Systems, Inc.
Version 2.0b
3–19
CRS-1 8-Slot Line Card Chassis Hardware
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 voltage—3-phase 200-240 VAC (nominal) range 170 to 264
VAC, phase-to-phase
−
Line frequency—50 to 60 Hz, range 47 to 63Hz
−
Recommended AC service—30 A (plugs into L15-30R receptacle)
AC Input, Wye 3-phase
−
3W+N+PE (3 wire plus neutral plus protective earthing)
−
Input voltage—3-phase 200-240 VAC (nominal)
♦ Range 170 to 264 VAC, phase-to-neutral
♦ Range 295 to 457 VAC, phase-to-phase
−
Line frequency—50 to 60 Hz, range 47 to 63Hz
−
Recommended AC service:
♦ 20 A North America (plugs into IEC 60309 receptacle)
♦ 16 A International
3–20
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot AC Power System
Power Redundancy
AC Input, Delta 3-phase
• 3W+PE (3 wire plus protective earthing)
• Input voltage—3-phase 200-240 VAC (nominal) range 170 to 264 VAC,
phase-to-phase
• Line frequency—50 to 60 Hz, range 47 to 63Hz
• Recommended AC service—30 A (plugs into L15-30R receptacle)
AC Input, Wye 3-phase
• 3W+N+PE (3 wire plus neutral plus protective earthing)
• Input voltage—3-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
• Line frequency—50 to 60 Hz, range 47 to 63Hz
© 2005 Cisco Systems, Inc.
Version 2.0b
3–21
CRS-1 8-Slot Line Card Chassis Hardware
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.
3–22
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot AC Power System
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
© 2005 Cisco Systems, Inc.
Version 2.0b
3–23
CRS-1 8-Slot Line Card Chassis Hardware
Module 3
AC Rectifier Status Indicators
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:
•
Fault—Indicates 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 Fail—Indicates that the AC input voltage is out of range.
•
Circuit Breaker Trip—Indicates that the AC rectifier circuit breaker
has tripped.
•
Over temperature—Indicates that the AC rectifier has exceeded the
maximum allowable operating temperature.
•
AC Rectifier Present—Indicates 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.
3–24
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot AC Power System
AC Rectifier Status Indicators
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
© 2005 Cisco Systems, Inc.
Version 2.0b
3–25
CRS-1 8-Slot Line Card Chassis Hardware
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.
3–26
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot DC Power System
DC Power Distribution Unit (PDU)
Each DC PDU requires three independent
nominal – 48 VDC or – 60 VDC/60 A input
services.
© 2005 Cisco Systems, Inc.
Version 2.0b
3–27
CRS-1 8-Slot Line Card Chassis Hardware
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.
3–28
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot DC Power System
DC Power Entry Module
2 DC PEMs required per chassis, 1 per PDU
Each PEM provides 7500 WATTs of power
© 2005 Cisco Systems, Inc.
Version 2.0b
3–29
CRS-1 8-Slot Line Card Chassis Hardware
Module 3
DC PEM Status Indicators
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
maximum allowable operating temperature.
•
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.
3–30
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot DC Power System
DC PEM Status Indicators
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
© 2005 Cisco Systems, Inc.
Version 2.0b
3–31
CRS-1 8-Slot Line Card Chassis Hardware
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)
•
Control software and logic
•
An air filter, inlet and outlet air vents, and bezels
•
Impedance carriers for empty chassis slots
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)
3–32
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Cooling System
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
© 2005 Cisco Systems, Inc.
Version 2.0b
3–33
CRS-1 8-Slot Line Card Chassis Hardware
Module 3
Line Card Chassis Airflow
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 airflow—Up to 900 cubic feet (25,485 liters) per minute
•
Power system airflow—Up 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.
3–34
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Cooling System
Line Card Chassis Airflow & Air Filter
Fan Trays
Air Filter
Air Intake
Air Exhaust
PDU
PLIM Side
(Front)
© 2005 Cisco Systems, Inc.
MSC Side
(Rear)
Version 2.0b
3–35
CRS-1 8-Slot Line Card Chassis Hardware
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.
_________________________________________________________________
3–36
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Cooling System
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
© 2005 Cisco Systems, Inc.
Version 2.0b
3–37
CRS-1 8-Slot Line Card Chassis Hardware
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.
3–38
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Cooling System
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
© 2005 Cisco Systems, Inc.
Version 2.0b
3–39
CRS-1 8-Slot Line Card Chassis Hardware
Module 3
Cooling System Redundancy
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.
_________________________________________________________________
3–40
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Cooling System
Cooling System Redundancy
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
© 2005 Cisco Systems, Inc.
Version 2.0b
3–41
CRS-1 8-Slot Line Card Chassis Hardware
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:
3–42
•
Four fans—Each 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 board—The board terminates signals to and from the fans,
filters common-mode noise, and contains tracking and indicator parts.
•
A front-panel status LED—The LED indicates the following:
−
Green—The fan tray is operating normally.
−
Yellow—The fan tray has experienced a failure and should be
replaced.
−
Off—An unknown state exists or the LED is faulty.
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Cooling System
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
© 2005 Cisco Systems, Inc.
Version 2.0b
3–43
CRS-1 8-Slot Line Card Chassis Hardware
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.
3–44
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Switch Fabric
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
© 2005 Cisco Systems, Inc.
Version 2.0b
3–45
CRS-1 8-Slot Line Card Chassis Hardware
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:
3–46
•
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
CRS-1 8-Slot Line Card Chassis Switch Fabric
Operation
© 2005 Cisco Systems, Inc.
Version 2.0b
3–47
CRS-1 8-Slot Line Card Chassis Hardware
Module 3
SFC Functional Block Diagram
The major functional blocks of the HS123 switch fabric card are:
3–48
•
S1 switch element—Receives 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 element—Receives 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 element—Receives data cells from the S2 stage and performs
switching and fabric speed-up. S3 has 36 inputs and 72 outputs.
•
Service processor—Provides 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 modules—Take –48V DC input power from the midplane and
convert it to the voltages required by the components on the switch
fabric card.
•
Alphanumeric display—Displays HS123 switch fabric card messages.
•
Status LED—Indicates status of the HS123 switch fabric card.
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Switch Fabric
SFC Functional Block Diagram
© 2005 Cisco Systems, Inc.
Version 2.0b
3–49
CRS-1 8-Slot Line Card Chassis Hardware
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 redundancy—one is active, and
the other is standby. An RP card can be inserted in either of the two
dedicated slots in the chassis.
3–50
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Route Processor
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
© 2005 Cisco Systems, Inc.
Version 2.0b
3–51
CRS-1 8-Slot Line Card Chassis Hardware
Module 3
RP Components
3–52
•
Hard drive―An 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.
•
Memory―Resides in a SIMM module on the RP card. The RP can be
configured with 2 or 4 GB of memory.
•
PCMCIA Subsystems―Two 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.
•
CPU―Performs 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 modules―Two small form-factor pluggable (SFP) modules support
external Gigabit Ethernet connections for multi-chassis systems.
•
RJ45 Ethernet port―An RJ45 10/100/1000 copper Ethernet port is
available for providing connectivity to network management systems.
•
Fast Ethernet Midplane Connector―Internal 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
CRS-1 8-Slot Line Card Chassis Route Processor
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
© 2005 Cisco Systems, Inc.
Version 2.0b
3–53
CRS-1 8-Slot Line Card Chassis Hardware
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
3–54
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Route Processor
RP Front Panel
CPU
Memory
© 2005 Cisco Systems, Inc.
Version 2.0b
3–55
CRS-1 8-Slot Line Card Chassis Hardware
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 RP’s 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.
3–56
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Route Processor
Block Diagram
LC FE
links
CTL GE link
FE/GE
switch
4
CTL GE link
2
PCI
9
7
Q
links
To
fabric
From
fabric
1
CPU
MEM
IF
CTL
5
CPU
IDE
PCMCIA
2
6
8
Aux and console
Management GE link
FPGA
Midplane
© 2005 Cisco Systems, Inc.
3
Card presence detect
RP mastership
PROM presence
10
Version 2.0b
3–57
CRS-1 8-Slot Line Card Chassis Hardware
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.
3–58
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Route Processor
Block Diagram (Cont.)
LC FE
links
CTL GE link
FE/GE
switch
4
CTL GE link
2
PCI
9
7
Q
links
To
fabric
From
fabric
1
CPU
MEM
IF
CTL
5
CPU
IDE
PCMCIA
2
6
8
Aux and console
Management GE link
FPGA
Midplane
© 2005 Cisco Systems, Inc.
3
Card presence detect
RP mastership
PROM presence
10
Version 2.0b
3–59
CRS-1 8-Slot Line Card Chassis Hardware
Module 3
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.
3–60
Version 2.0b
CRS-1 Essentials
Module 3
CRS-1 8-Slot Line Card Chassis Route Processor
Route Processor (RP) Active and Standby Arbitration
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.
5. Software on each reads its “Active” signal, and branches accordingly to
“Primary” or “Standby” code.
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.
© 2005 Cisco Systems, Inc.
Version 2.0b
3–61
CRS-1 8-Slot Line Card Chassis Hardware
Module 3
Summary
CRS-1 8-Slot Line Card Chassis Hardware
In this module, you learned the following:
3–62
•
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
components that comprise the CRS-1 8-slot Line Card chassis
•
To list and describe the features and functions of the CRS-1 8-slot line
card chassis power system
•
To list and describe the features and functions of the CRS-1 8-slot line
card chassis Switch Fabric
•
To list and describe the features and functions of the CRS-1 8-slot line
card chassis cooling system
•
To list and describe the features and functions of the CRS-1 8-slot line
card chassis Route Processor
Version 2.0b
CRS-1 Essentials
Module 3
Review Questions
CRS-1 8-Slot Line Card Chassis Hardware
1. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
2. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
3. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
4. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
5. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
© 2005 Cisco Systems, Inc.
Version 2.0b
3–63
CRS-1 8-Slot Line Card Chassis Hardware
Module 3
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
3–64
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
After completing this module, you will be able to do the following:
•
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
© 2005 Cisco Systems, Inc.
Version 2.0b
4–1
CRS-1 Line Card Chassis Common Elements
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.
4–2
Version 2.0b
CRS-1 Essentials
Module 4
Modular Services Card
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
© 2005 Cisco Systems, Inc.
Version 2.0b
4–3
CRS-1 Line Card Chassis Common Elements
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.
4–4
Version 2.0b
CRS-1 Essentials
Module 4
Modular Services Card
MSC Hardware Components
Power
Regulators
EgressQ
2*FabricQ
Egress
PSE
SP
CPU
Ingress
PSE
© 2005 Cisco Systems, Inc.
Version 2.0b
IngressQ
4–5
CRS-1 Line Card Chassis Common Elements
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.
4–6
Version 2.0b
CRS-1 Essentials
Module 4
DRP Architecture - LC Chassis
DRP Architecture - LC Chassis
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
© 2005 Cisco Systems, Inc.
Version 2.0b
FLASH
FLASH
4–7
CRS-1 Line Card Chassis Common Elements
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.
4–8
Version 2.0b
CRS-1 Essentials
Module 4
Physical Layer Module (PLIM)
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
© 2005 Cisco Systems, Inc.
Version 2.0b
4–9
CRS-1 Line Card Chassis Common Elements
Module 4
PLIM Physical Characteristics
All POS and POS/DPT PLIMs have the following physical characteristics:
4–10
•
Height—20.6 in. (52.3 cm)
•
Depth—11.2 in. (28.5 cm)
•
Width—1.8 in. (4.6 cm)
•
Weight—7.8 to 8.6 lb (3.5 to 3.9 kg), see individual PLIM descriptions
•
Power consumption—65 to 150 W, see individual PLIM descriptions
Version 2.0b
CRS-1 Essentials
Module 4
Physical Layer Module (PLIM)
PLIM Physical Characteristics
• Height—20.6 in. (52.3 cm)
• Depth—11.2 in. (28.5 cm)
• Width—1.8 in. (4.65 cm)
• Weight—7.8 to 8.6 lb. (3.5
to 3.9 kg)
• Power Consumption—65
to 150 Watts
© 2005 Cisco Systems, Inc.
Version 2.0b
4–11
CRS-1 Line Card Chassis Common Elements
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.
4–12
•
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
Physical Layer Module (PLIM)
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
© 2005 Cisco Systems, Inc.
Version 2.0b
4–13
CRS-1 Line Card Chassis Common Elements
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.
_________________________________________________________________
4–14
Version 2.0b
CRS-1 Essentials
Module 4
Physical Layer Module (PLIM)
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
© 2005 Cisco Systems, Inc.
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
4–15
CRS-1 Line Card Chassis Common Elements
Module 4
PoS and PoS/DPT PLIM Features
Each PoS/DPT PLIM provides:
4–16
•
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
Physical Layer Module (PLIM)
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
© 2005 Cisco Systems, Inc.
Version 2.0b
4–17
CRS-1 Line Card Chassis Common Elements
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 module—Provides 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.
•
Framer—Provides processing and termination for SONET/SDH section,
line, and path layers, including alarm processing and automatic
protection switching (APS) support.
•
Physical interface controller—Provides data packet buffering and Layer
2 processing, including processing for VLANs and back-pressure signals
from the MSC.
•
Additional components—Include 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.
4–18
Version 2.0b
CRS-1 Essentials
Module 4
Physical Layer Module (PLIM)
OC768c PLIM HW Architecture
EgressQ
M
i
d
p
l
a
n
e
PLA768
Framer
RX PSE
MSC
© 2005 Cisco Systems, Inc.
1xOC768 PLIM
Version 2.0b
4–19
CRS-1 Line Card Chassis Common Elements
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:
•
−
ACTIVE—Indicates that the port is logically active; the laser is on
−
CARRIER—Indicates 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 PKT—Blinks 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
_________________________________________________________________
4–20
Version 2.0b
CRS-1 Essentials
Module 4
Physical Layer Module (PLIM)
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:
−
−
−
ACTIVE—Indicates that the port is logically active; the laser is on
CARRIER—Indicates 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 PKT—Blinks 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
• Power consumption is 65 W
© 2005 Cisco Systems, Inc.
Version 2.0b
4–21
CRS-1 Line Card Chassis Common Elements
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 modules—Provide 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
•
Framers—Provide 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.
•
Physical interface controller—Provides data packet buffering and Layer
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 components—Provides 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 components—Provide 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.
4–22
Version 2.0b
CRS-1 Essentials
Module 4
Physical Layer Module (PLIM)
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
© 2005 Cisco Systems, Inc.
Framer 0
PLA 0
EgressQ
Rx PSE
RAC0
4xoc192 PLIM
Version 2.0b
4–23
CRS-1 Line Card Chassis Common Elements
Module 4
4 - Port OC-192c PLIM Faceplates
The 4-port OC-192 PLIM has:
4–24
•
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 LED—Green 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/FAILURE—Indicates that the port is logically active; the
laser is on.
−
CARRIER—Indicates that the receive port (RX) is receiving a
carrier signal.
−
RX PKT—Blinks every time a packet is received.
−
WRAP—Indicates that the port is in DPT wrapped mode.
−
PASS THRU—Indicates that the port is operating in the POS mode
(DPT pass through).
•
Two DPT MODE LEDs—One 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
Physical Layer Module (PLIM)
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 LED—Green 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/FAILURE—Indicates port is logically active; laser is on
CARRIER—Indicates receive port (RX) is receiving a carrier signal
RX PKT—Blinks every time a packet is received
WRAP—Indicates port is in DPT wrapped mode
PASS THRU—Indicates port is operating in POS mode (DPT pass through)
−
DPT mode is always configured on pairs of ports
• Two DPT MODE LEDs—One DPT MODE LED is for ports 0 and 1, and other for ports 2 and 3
• Power consumption: 138 Watts
© 2005 Cisco Systems, Inc.
Version 2.0b
4–25
CRS-1 Line Card Chassis Common Elements
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 modules—Provide 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.
•
Framers—Provides 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 components—Provides 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.
•
Physical interface controller—Provides data packet buffering and Layer
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 components—Provides 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.
4–26
Version 2.0b
CRS-1 Essentials
Module 4
Physical Layer Module (PLIM)
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
© 2005 Cisco Systems, Inc.
RAC12
Version 2.0b
4–27
CRS-1 Line Card Chassis Common Elements
Module 4
16 - Port OC-48c PLIM Faceplate
The 16-port OC-48 PLIM has:
•
Sixteen slots for SFP optic modules, which provide SR or LR optics with
LC fiber-optic interfaces.
•
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
•
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. 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):
•
4–28
−
−
ACTIVE/FAILURE—Indicates that the port is logically active; the
laser is on.
−
CARRIER—Indicates that the receive port (RX) is receiving a
carrier signal.
−
RX PKT—Blinks every time a packet is received.
−
WRAP—Indicates that the port is in DPT wrapped mode.
−
PASS THRU—Indicates that the port is operating in the POS mode
(DPT pass through).
Power consumption: 136 Watts
Version 2.0b
CRS-1 Essentials
Module 4
Physical Layer Module (PLIM)
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/FAILURE—Indicates port is logically active; laser is on
CARRIER—Indicates receive port (RX) is receiving a carrier signal
RX PKT—Blinks every time a packet is received
WRAP—Indicates port is in DPT wrapped mode
PASS THRU—Indicates port is operating in POS mode (DPT pass through)
• Five green LEDs for each port
• Power consumption 136 Watts
© 2005 Cisco Systems, Inc.
Version 2.0b
4–29
CRS-1 Line Card Chassis Common Elements
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:
4–30
•
Optic modules—Provides 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 controller—Provides 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 components—Include 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
Physical Layer Module (PLIM)
10 – Port 10GE PLIM HW Architecture
PLA 0
EgressQ
M
i
d
p
l
a
n
e
Rx PSE
PLA 1
Line card
© 2005 Cisco Systems, Inc.
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
4–31
CRS-1 Line Card Chassis Common Elements
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
−
Slots 0 and 1, and 6 and 7
−
Slots 2 and 3, and 4 and 5
−
Slots 2 and 3, and 6 and 7
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.
4–32
Version 2.0b
CRS-1 Essentials
Module 4
Physical Layer Module (PLIM)
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
• Adding another module in port 2 causes oversubscription on all of the
interfaces (0, 1, and 2)
• Guidelines for avoiding oversubscription:
−
−
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
Slots 0 and 1, and 6 and 7
Slots 2 and 3, and 4 and 5
Slots 2 and 3, and 6 and 7
• 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
© 2005 Cisco Systems, Inc.
Version 2.0b
4–33
CRS-1 Line Card Chassis Common Elements
Module 4
10 – Port 10GE PLIM Faceplate
The 8-port 10-GE PLIM has:
4–34
•
Eight slots that accept XENPAK optic modules, which provide LR
optics with SC fiber-optic interfaces.
•
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
•
A LED for each port—Indicates that the port is logically active; the
laser is on
•
Power consumption—110 W (with 8 optic modules)
Version 2.0b
CRS-1 Essentials
Module 4
Physical Layer Module (PLIM)
10 – Port 10GE PLIM Faceplate
• Eight slots that accept XENPAK optic modules, which provide
LR optics with SC fiber-optic interfaces.
• 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
• A LED for each port—Indicates that the port is logically active;
the laser is on
• Power consumption—110 W (with 8 optic modules)
© 2005 Cisco Systems, Inc.
Version 2.0b
4–35
CRS-1 Line Card Chassis Common Elements
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:
4–36
•
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)
• If more than 2 optic modules are installed in either set of ports,
oversubscription occurs on all ports in that set
• Adding another module in port 2 causes oversubscription on all of the
interfaces (0, 1, and 2)
• Guidelines for avoiding oversubscription:
−
−
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
Slots 0 and 1, and 6 and 7
Slots 2 and 3, and 4 and 5
Slots 2 and 3, and 6 and 7
• 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
© 2005 Cisco Systems, Inc.
Version 2.0b
4–37
CRS-1 Line Card Chassis Common Elements
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.
4–38
Version 2.0b
CRS-1 Essentials
Module 4
Shared Port Adapters (SPAs) and SPA Interface Processor-800 (SIP-800)
SPA Slot Numbering on the Cisco CRS-1 SIP-800
© 2005 Cisco Systems, Inc.
Version 2.0b
4–39
CRS-1 Line Card Chassis Common Elements
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 SPA—Inserts into one SIP subslot.
−
Double-height SPA—Inserts 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:
4–40
•
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 (SPAs) and SPA Interface Processor-800 (SIP-800)
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)
© 2005 Cisco Systems, Inc.
Version 2.0b
4–41
CRS-1 Line Card Chassis Common Elements
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:
•
rack—Specifies the rack number, 0 in a single-chassis system.
•
slot—Specifies the slot number in the Cisco CRS-1 in which the SIP that contains
the SPA is installed:
•
−
For the 8-slot line card chassis—0 through 7
−
For the 16-slot line card chassis—0 through 15
subslot—Specifies the secondary slot on the SIP where the SPA that you want to
select is installed:
−
•
For the Cisco CRS-1 SIP-800—0 through 5
port—Specifies the interface number that you want to select on the SPA:
−
For the 4-Port OC-3c/STM-1 PoS SPA—0 through 3
−
For the 1-Port OC-192c/STM-64 PoS/RPR XFP SPA—0 is the only
option.
−
For the 8-Port Gigabit Ethernet SPA—0 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.
4–42
Version 2.0b
CRS-1 Essentials
Module 4
Shared Port Adapters (SPAs) and SPA Interface Processor-800 (SIP-800)
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.
© 2005 Cisco Systems, Inc.
Version 2.0b
4–43
CRS-1 Line Card Chassis Common Elements
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.
4–44
Version 2.0b
CRS-1 Essentials
Module 4
SIP Bandwidth Oversubscription
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
© 2005 Cisco Systems, Inc.
SIP-800 Jacket Card
Per-Port
Bandwidth
Number of Ports
Total Bandwidth
155.52 Mbps
4
622.08 Mbps
10Gbbps
1
10Gbps
1Gbps
8
8 Gbps
Version 2.0b
4–45
CRS-1 Line Card Chassis Common Elements
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
−
•
4–46
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
SIP Bandwidth Oversubscription
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
8-Port Gigabit Ethernet SPA
♦ SFP-GE-S
♦ SFP-GE-L
♦ SFP-GE-Z
© 2005 Cisco Systems, Inc.
Version 2.0b
4–47
CRS-1 Line Card Chassis Common Elements
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 1155–1157) and RFC 1213:
4–48
•
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 SPA
4-Port OC-3c/STM-1 SPA
•
•
•
•
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:
− RFC 1619, PPP over SONET/SDH
− RFC 1662, PPP in HDLC-like Framing
• SPA also provides support for SNMP v1 agent (RFC 1155–1157) and RFC 1213
© 2005 Cisco Systems, Inc.
Version 2.0b
4–49
CRS-1 Line Card Chassis Common Elements
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.
4–50
Version 2.0b
CRS-1 Essentials
Module 4
4-Port OC-3c/STM-1 SPA
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
© 2005 Cisco Systems, Inc.
Meaning
Version 2.0b
4–51
CRS-1 Line Card Chassis Common Elements
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 Spécifications
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 1619, PPP over SONET/SDH
•
RFC 1662, PPP in HDLC-like Framing
•
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 1155–1157) and RFC 1213:
4–52
•
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
1-Port OC-192c/STM-64 PoS/RPR XFP SPA
1-Port OC-192c/STM-64 PoS/RPR XFP SPA
• 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:
−
−
−
RFC 1619, PPP over SONET/SDH
RFC 1662, PPP in HDLC-like Framing
RFC 2615, PPP over SONET/SDH
• 1-Port OC-192c/STM-64 POS/RPR XFP SPA supports SNMP v1 agent (RFC 1155–1157) and RFC
1213
© 2005 Cisco Systems, Inc.
Version 2.0b
4–53
CRS-1 Line Card Chassis Common Elements
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.
_________________________________________________________________
4–54
Version 2.0b
CRS-1 Essentials
Module 4
1-Port OC-192c/STM-64 PoS/RPR XFP SPA
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
SPA is ready and operational
Amber
On
SPA power is on and good; SPA is being configured
© 2005 Cisco Systems, Inc.
Version 2.0b
4–55
CRS-1 Line Card Chassis Common Elements
Module 4
8-Port Gigabit Ethernet SPA
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.
4–56
Version 2.0b
CRS-1 Essentials
Module 4
8-Port Gigabit Ethernet SPA
8-Port Gigabit Ethernet SPA
• 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
© 2005 Cisco Systems, Inc.
Version 2.0b
4–57
CRS-1 Line Card Chassis Common Elements
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.
4–58
Version 2.0b
CRS-1 Essentials
Module 4
8-Port Gigabit Ethernet SPA
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
SPA is ready and operational
STATUS
© 2005 Cisco Systems, Inc.
Meaning
Version 2.0b
4–59
CRS-1 Line Card Chassis Common Elements
Module 4
Summary
CRS-1 Line Card Chassis Common Elements
In this module, you learned the following:
4–60
•
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
CRS-1 Line Card Chassis Common Elements
1. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
2. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
3. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
4. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
5. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
© 2005 Cisco Systems, Inc.
Version 2.0b
4–61
CRS-1 Line Card Chassis Common Elements
Module 4
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
4–62
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
After completing this module, you will be able to do the following:
•
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
© 2005 Cisco Systems, Inc.
Version 2.0b
5–1
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
5–2
Version 2.0b
Cisco CRS-1 Router Essentials
Module 5
Switch Fabric Chassis
Switch Fabric Chassis - Front
© 2005 Cisco Systems, Inc.
Version 2.0b
5–3
Introduction to Cisco CRS-1 Multi-Shelf Architecture
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.
5–4
Version 2.0b
Cisco CRS-1 Router Essentials
Module 5
Switch Fabric Chassis
Switch Fabric Chassis – Rear View
© 2005 Cisco Systems, Inc.
Version 2.0b
5–5
Introduction to Cisco CRS-1 Multi-Shelf Architecture
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.
5–6
Version 2.0b
Cisco CRS-1 Router Essentials
Module 5
Switch Fabric Components
Switch Fabric Components
• Switch Fabric Cards (SFCs)
• Optical Interface Modules (OIMs)
• Shelf Controller Gigabit Ethernet Card (SC-GE)
• Fan Tray Assemblies
• Alarm Modules
• AC/DC Power
© 2005 Cisco Systems, Inc.
Version 2.0b
5–7
Introduction to Cisco CRS-1 Multi-Shelf Architecture
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 Router—18 line card chassis and two switch fabric chassis. This
system supports up to 288 MSCs.
46 Terabit Router—36 line card chassis and 4 switch fabric chassis
supports up to 576 MSCs.
92 Terabit Router—72 line card chassis and 8 switch fabric chassis
supports up to 1152 MSCs.
5–8
Version 2.0b
Cisco CRS-1 Router Essentials
Module 5
System Configurations
System Configurations
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
© 2005 Cisco Systems, Inc.
Version 2.0b
5–9
Introduction to Cisco CRS-1 Multi-Shelf Architecture
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.
5–10
Version 2.0b
Cisco CRS-1 Router Essentials
Module 5
System Configurations
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
2
up to 18
288
23 Tbps
4
up to 36
576
46 Tbps
8
up to 72
1152
92 Tbps
© 2005 Cisco Systems, Inc.
Version 2.0b
5–11
Introduction to Cisco CRS-1 Multi-Shelf Architecture
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.
_________________________________________________________________
5–12
Version 2.0b
Cisco CRS-1 Router Essentials
Module 5
Switch Fabric Chassis Interconnections
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
© 2005 Cisco Systems, Inc.
Version 2.0b
5–13
Introduction to Cisco CRS-1 Multi-Shelf Architecture
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
5–14
•
9 bundle connections per fabric card
•
24 fabric cards
•
216 bundles or connections
Version 2.0b
Cisco CRS-1 Router Essentials
Module 5
Switch Fabric Chassis Interconnections
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:
• 3 bundle connections per fabric card
• 8 fabric cards
• 24 bundles or connections
Connections per Fabric Card Chassis
Multiple Bundles
Between LC Chassis
And FC Chassis
• 9 bundle connections / fabric card
• 24 fabric cards
• 216 bundles or connections
Optical Interface Modules
© 2005 Cisco Systems, Inc.
Version 2.0b
Full Utilized Fabric Chassis
5–15
Introduction to Cisco CRS-1 Multi-Shelf Architecture
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
5–16
Version 2.0b
Cisco CRS-1 Router Essentials
Module 5
In-service upgrade from Standalone to Multi-Shelf
In-service upgrade from Standalone to Multi-Shelf
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
© 2005 Cisco Systems, Inc.
Version 2.0b
5–17
Introduction to Cisco CRS-1 Multi-Shelf Architecture
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.
_________________________________________________________________
5–18
Version 2.0b
Cisco CRS-1 Router Essentials
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
© 2005 Cisco Systems, Inc.
SC-GE
Version 2.0b
S2
5–19
Introduction to Cisco CRS-1 Multi-Shelf Architecture
Module 5
Shelf Controller Gigabit Ethernet Card (SC-GE)
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:
5–20
•
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
Cisco CRS-1 Router Essentials
Module 5
card
CRS-1 Management System Control Plane and Shelf Controller Gigabit Ethernet (SC-GE)
Shelf Controller Gigabit Ethernet Card (SC-GE)
LC FE
Links
B
A
C
K
P
L
A
N
E
© 2005 Cisco Systems, Inc.
CTL GE link
CTL GE link
FE/GE
Switch
PCI
IDE
CPU
MEM
CTL
Aux & Console
Mgmt GE link
FLASH
Version 2.0b
FLASH
5–21
Introduction to Cisco CRS-1 Multi-Shelf Architecture
Module 5
Summary
Introduction to Cisco CRS-1 Multi-Shelf Architecture
In this module, you learned the following:
5–22
•
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
Cisco CRS-1 Router Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0b
6–1
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.
6–2
Version 2.0b
Cisco CRS-1 Essentials
Module 6
Cisco IOS XR Architecture
Cisco IOS XR Architecture
Routing
modules
(BGP, OSPF)
Runs on
multiple
CPU’s
Protocol
modules
(IP)
Application
modules
Distributed infrastructure
Cisco IOS XR kernel
© 2005 Cisco Systems, Inc.
Version 2.0b
6–3
Cisco IOS XR Overview and Initial Configuration
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
6–4
•
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
Cisco CRS-1 Essentials
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.
© 2005 Cisco Systems, Inc.
Version 2.0b
6–5
Cisco IOS XR Overview and Initial Configuration
Module 6
Kernel
The QNX Neutrino microkernel has these main features:
•
Multiprocessor
•
Small memory footprint
•
Memory protection
•
Preemptive fast context switch times
•
Reliability–independent 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.
6–6
Version 2.0b
Cisco CRS-1 Essentials
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
C
Synchronization
O
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.
© 2005 Cisco Systems, Inc.
Version 2.0b
6–7
Cisco IOS XR Overview and Initial Configuration
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:
•
Control—Distributes routing tasks and management of the Routing
Information Base (RIB) in participating RPs; different routing
processes can be running on different physical units
•
Data—Maintains the Forwarding Information Base (FIB) changes
across the participating nodes letting the router perform as a single
forwarding entity
•
Management—Controls 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.
6–8
Version 2.0b
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
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
l
H/W abstraction
System services
Memory-protected microkernel
6–9
Cisco IOS XR Overview and Initial Configuration
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.
6–10
Version 2.0b
Cisco CRS-1 Essentials
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….
© 2005 Cisco Systems, Inc.
Version 2.0b
6–11
Cisco IOS XR Overview and Initial Configuration
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.
6–12
Version 2.0b
Cisco CRS-1 Essentials
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.
© 2005 Cisco Systems, Inc.
Version 2.0b
6–13
Cisco IOS XR Overview and Initial Configuration
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.
_________________________________________________________________
6–14
Version 2.0b
Cisco CRS-1 Essentials
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.
© 2005 Cisco Systems, Inc.
Version 2.0b
6–15
Cisco IOS XR Overview and Initial Configuration
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
6–16
Version 2.0b
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0b
6–17
Cisco IOS XR Overview and Initial Configuration
Module 6
Process Restart and Recovery—RP Failure
There are a variety of ways of restarting or recovering a process when the
active RP fails; here are some examples:
6–18
Process
Checkpoint data status
A
Sent to the standby card continuously; process A' is
running in the background
B
Mirrored to the standby card; process B' is not running;
this process uses a checkpoint proxy process to receive
checkpoint information
C
No checkpointing of data; process C' can start on the
standby card without saved state information
D
No checkpointing of data; no process running on the
standby card
Version 2.0b
Cisco CRS-1 Essentials
Module 6
High Availability
Process Restart and Recovery—RP Failure
Active card
Standby card
Process A´
Process A
1
1
Process B´
Process B
2
Process C
3
Process D
4
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
© 2005 Cisco Systems, Inc.
Version 2.0b
Process C ´
6–19
Cisco IOS XR Overview and Initial Configuration
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.
6–20
Version 2.0b
Cisco CRS-1 Essentials
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.
© 2005 Cisco Systems, Inc.
Version 2.0b
6–21
Cisco IOS XR Overview and Initial Configuration
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.
6–22
Version 2.0b
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0b
6–23
Cisco IOS XR Overview and Initial Configuration
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
6–24
•
Adjacency management
•
Forwarding Information Base tables
•
Distributed interface management
•
Distributed configuration management
•
Two-stage forwarding
Version 2.0b
Cisco CRS-1 Essentials
Module 6
Scalability
Scalability Features
• Adjacency management
• Forwarding Information Base tables
• Distributed interface management
• Distributed configuration management
• Two-stage forwarding
© 2005 Cisco Systems, Inc.
Version 2.0b
6–25
Cisco IOS XR Overview and Initial Configuration
Module 6
Adjacency Management
An adjacency is a mapping of the next-hop’s 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.
6–26
Version 2.0b
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0b
6–27
Cisco IOS XR Overview and Initial Configuration
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.
6–28
Version 2.0b
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0b
6–29
Cisco IOS XR Overview and Initial Configuration
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.
6–30
Version 2.0b
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0b
6–31
Cisco IOS XR Overview and Initial Configuration
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.
6–32
Version 2.0b
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Interfaces
Version 2.0b
6–33
Cisco IOS XR Overview and Initial Configuration
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.
6–34
Version 2.0b
Cisco CRS-1 Essentials
Module 6
Scalability
Distributed Configuration Management
RP
Configuration manager
MSC
MSC
Configuration manager
Configuration manager
L2/L3
applications and
H/W drivers
L2/L3
applications and
H/W drivers
Hardware
Hardware
© 2005 Cisco Systems, Inc.
Version 2.0b
6–35
Cisco IOS XR Overview and Initial Configuration
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.
6–36
Version 2.0b
Cisco CRS-1 Essentials
Module 6
Configuration Operations
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
Instructor’s Note
This slide is animated in 2 steps.
Click 1 shows all stage 1 elements
Click 2 shows all stage 2 elements
© 2005 Cisco Systems, Inc.
Version 2.0b
6–37
Cisco IOS XR Overview and Initial Configuration
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.
_________________________________________________________________
6–38
Version 2.0b
Cisco CRS-1 Essentials
Module 6
Configuration Operations
Configuration File System
New binary
configuration
created; router uses
it to boot up
following reload
IOS XR
© 2005 Cisco Systems, Inc.
Running config
plus changes
Version 2.0b
RP “disk0:”
6–39
Cisco IOS XR Overview and Initial Configuration
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.
6–40
Version 2.0b
Cisco CRS-1 Essentials
Module 6
Configuration Operations
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
© 2005 Cisco Systems, Inc.
Version 2.0b
6–41
Cisco IOS XR Overview and Initial Configuration
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.
6–42
•
EXEC mode—Logging 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 mode—Configuration 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
Cisco CRS-1 Essentials
Module 6
Configuration Operations
Command Modes
Login
EXEC mode
Configuration modes
© 2005 Cisco Systems, Inc.
Version 2.0b
6–43
Cisco IOS XR Overview and Initial Configuration
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.
6–44
Version 2.0b
Cisco CRS-1 Essentials
Module 6
Configuration Basics
Management IP Interfaces
• Cisco CRS-1 Management
Ethernet interfaces
− MgmtEth0/RP0/CPU0/0
− MgmtEth0/RP1/CPU0/0
Management
network
connections
© 2005 Cisco Systems, Inc.
Version 2.0b
6–45
Cisco IOS XR Overview and Initial Configuration
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.
_________________________________________________________________
6–46
Version 2.0b
Cisco CRS-1 Essentials
Module 6
Configuration Basics
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
© 2005 Cisco Systems, Inc.
Version 2.0b
6–47
Cisco IOS XR Overview and Initial Configuration
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.
6–48
Version 2.0b
Cisco CRS-1 Essentials
Module 6
Configuration Basics
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
© 2005 Cisco Systems, Inc.
Version 2.0b
6–49
Cisco IOS XR Overview and Initial Configuration
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.
6–50
Version 2.0b
Cisco CRS-1 Essentials
Module 6
Configuration Basics
Configuring Loopback Address
RP/0/RP0/CPU0:router(config)#interface loopback0 12.9.42.110/16
RP/0/RP0/CPU0:router(config-if)#
• Interface command
• Assign IP address
• Visible as interface
© 2005 Cisco Systems, Inc.
Version 2.0b
6–51
Cisco IOS XR Overview and Initial Configuration
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.
_________________________________________________________________
6–52
Version 2.0b
Cisco CRS-1 Essentials
Module 6
Configuration Basics
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
© 2005 Cisco Systems, Inc.
Version 2.0b
6–53
Cisco IOS XR Overview and Initial Configuration
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.
6–54
Version 2.0b
Cisco CRS-1 Essentials
Module 6
Configuration Basics
Hostname
RP/0/RP0/CPU0:router(config)#hostname P1
RP/0/RP0/CPU0:router(config)#
• Create a hostname
© 2005 Cisco Systems, Inc.
Version 2.0b
6–55
Cisco IOS XR Overview and Initial Configuration
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
6–56
Version 2.0b
Cisco CRS-1 Essentials
Module 6
Configuration Basics
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
RP/0/RP0/CPU0:router(config-if)#
• Set clock source first
− Controller
• Interface command
− Rack/slot/module/port
− Assign IP address
− Activate the interface
© 2005 Cisco Systems, Inc.
Version 2.0b
6–57
Cisco IOS XR Overview and Initial Configuration
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.
6–58
Version 2.0b
Cisco CRS-1 Essentials
Module 6
Configuration Basics
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
© 2005 Cisco Systems, Inc.
Version 2.0b
6–59
Cisco IOS XR Overview and Initial Configuration
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.
6–60
Version 2.0b
Cisco CRS-1 Essentials
Module 6
Configuration Basics
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
© 2005 Cisco Systems, Inc.
Version 2.0b
6–61
Cisco IOS XR Overview and Initial Configuration
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:
•
interface—displays the interfaces
•
router protocol—displays the routing protocol specified
•
username—displays the users configured
These and other parameters are available to minimize the amount of
information you display, particularly with a large router configuration.
6–62
Version 2.0b
Cisco CRS-1 Essentials
Module 6
Configuration Basics
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
!
interface POS0/4/0/1
ipv4 address 142.50.16.5 255.255.255.0
Additional messages are not shown
end
• Display entire running configuration
• Display by like groups (Interfaces, routing protocols)
© 2005 Cisco Systems, Inc.
Version 2.0b
6–63
Cisco IOS XR Overview and Initial Configuration
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.
_________________________________________________________________
6–64
Version 2.0b
Cisco CRS-1 Essentials
Module 6
Configuration Basics
Display the Target Configuration
RP/0/RP0/CPU0:P1(config)#show config
Building configuration...
interface POS0/4/0/3
ipv4 address 142.50.48.5 255.255.255.0
!
interface POS0/5/0/1
ipv4 address 142.50.36.5 255.255.255.0
pos
crc 16
!
!
end
© 2005 Cisco Systems, Inc.
Version 2.0b
6–65
Cisco IOS XR Overview and Initial Configuration
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.
6–66
Version 2.0b
Cisco CRS-1 Essentials
Module 6
Configuration Basics
Display the Merged Configuration
RP/0/RP0/CPU0:P1(config)#show config merge
Building configuration...
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
!
interface POS0/4/0/1
ipv4 address 142.50.16.5 255.255.255.0
Additional messages are not shown
interface POS0/4/0/3
ipv4 address 142.50.48.5 255.255.255.0
!
interface POS0/5/0/1
ipv4 address 142.50.36.5 255.255.255.0
pos
crc 16
!
!
end
© 2005 Cisco Systems, Inc.
Version 2.0b
Added
6–67
Cisco IOS XR Overview and Initial Configuration
Module 6
Summary
Cisco IOS XR Overview
In this module, you learned to:
6–68
•
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
Cisco CRS-1 Essentials
Module 6
Review Questions
Cisco IOS XR Overview and Initial Configuration
1. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
2. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
3. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
4. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
5. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
© 2005 Cisco Systems, Inc.
Version 2.0b
6–69
Cisco IOS XR Overview and Initial Configuration
Module 6
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
6–70
Version 2.0b
Cisco CRS-1 Essentials
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
After completing this module, you will be able to:
•
Describe command modes
•
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
© 2005 Cisco Systems, Inc.
Version 2.0b
7–1
Cisco IOS XR Operations
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.
7–2
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Cisco IOS XR Command Modes
Cisco IOS XR Command Modes
Login
EXEC mode
Admin EXEC mode
Configuration modes
Admin configuration mode
© 2005 Cisco Systems, Inc.
Version 2.0b
7–3
Cisco IOS XR Operations
Module 7
Configuration Modes
•
Configuration mode—Configuration 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 submodes—From 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 submode—POS configuration submode is used to
configure such things as CRC and transmit-delay.
•
Router configuration submode—Router configuration submode is
used to select and configure a routing protocol, such as BGP, OSPF or
IS-IS.
−
•
7–4
Router submode configuration—Router 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
Cisco CRS-1 Essentials
Module 7
Cisco IOS XR Command Modes
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
© 2005 Cisco Systems, Inc.
Version 2.0b
7–5
Cisco IOS XR Operations
Module 7
Administration Modes
Administration mode is currently used to configure multiple logical routers
(LRs) and to install the Cisco IOS XR software.
7–6
•
Admin EXEC—Enter 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 configuration—Enter admin configuration (admin config)
mode from admin EXEC mode. This mode’s 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 configuration—To specify a logical router (LR) to be
provisioned and enter LR configuration mode
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Cisco IOS XR Command Modes
Administration Modes
Admin EXEC mode
Admin configuration mode
Logical router configuration
submode
• Software installations
• Logical router management
© 2005 Cisco Systems, Inc.
Version 2.0b
7–7
Cisco IOS XR Operations
Module 7
Command Mode Samples
Here are some sample illustrations of the prompt syntax and some
commands used to enter various modes.
7–8
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Cisco IOS XR Command Modes
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.
© 2005 Cisco Systems, Inc.
Version 2.0b
7–9
Cisco IOS XR Operations
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:
7–10
•
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
Cisco CRS-1 Essentials
Module 7
Cisco IOS XR Command Modes
Cisco CRS-1 Hardware Node Locations
Rack number
Slot = Physical
slot of card
Card Type
Module = CPU0 or SP
Rack
Slot
Module
Route processor
0—71
RP0/RP1
CPU0
Modular services card
0—71
0—15
CPU0, SP
Switch fabric module
0—71
SM0—SM7
SP
Alarm card
0—71
AM0—AM1
SP
Fan controller card
0—71
FC0—FC1
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.
© 2005 Cisco Systems, Inc.
Version 2.0b
7–11
Cisco IOS XR Operations
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:
7–12
•
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
Cisco CRS-1 Essentials
Module 7
Cisco IOS XR Command Modes
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
© 2005 Cisco Systems, Inc.
Management
network
connection
Version 2.0b
7–13
Cisco IOS XR Operations
Module 7
Configuration Operations
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.
7–14
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Configuration Operations
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
© 2005 Cisco Systems, Inc.
Version 2.0b
7–15
Cisco IOS XR Operations
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.
7–16
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Configuration Operations
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
RP/0/0/CPU0:P4(config)#
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.
© 2005 Cisco Systems, Inc.
Version 2.0b
7–17
Cisco IOS XR Operations
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 router’s 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.
7–18
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Configuration Operations
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
© 2005 Cisco Systems, Inc.
Version 2.0b
7–19
Cisco IOS XR Operations
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.
7–20
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Configuration Operations
Clear Target Configuration Changes
RP/0/0/CPU0:P4#configure
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
Building configuration...
interface POS0/5/0/1
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
Building configuration...
end
© 2005 Cisco Systems, Inc.
Version 2.0b
7–21
Cisco IOS XR Operations
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.
7–22
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Configuration Operations
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
Building configuration...
[OK]
RP/0/0/CPU0:P4(config-un)#
• Save target configuration commands to specific file
© 2005 Cisco Systems, Inc.
Version 2.0b
7–23
Cisco IOS XR Operations
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.
7–24
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Configuration Operations
Loading a Target Configuration Commands
RP/0/0/CPU0:P4(config)#show config
Building configuration...
end
RP/0/0/CPU0:P4(config)#load disk0:ed
Loading.
57 bytes parsed in 1 sec (56)bytes/sec
RP/0/0/CPU0:P4(config)#show config
Building configuration...
username ed
password 7 110C1D
group root-system
!
end
• File has been saved as a target configuration
• Loaded file becomes the target configuration
© 2005 Cisco Systems, Inc.
Version 2.0b
7–25
Cisco IOS XR Operations
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.
7–26
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Configuration Operations
Abort Configuration Mode
RP/0/0/CPU0:P4#configure
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
© 2005 Cisco Systems, Inc.
Version 2.0b
7–27
Cisco IOS XR Operations
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.
7–28
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Configuration Operations
Failed Configuration Commands
• Configuration commit entry fails
− View causes of failures
RP/0/0/CPU0:P4#config
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
!
RP/0/0/CPU0:P4(config)#
• Configuration commit entry fails
− View causes of failures
RP/0/0/CPU0:P4#config
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)#
© 2005 Cisco Systems, Inc.
Version 2.0b
7–29
Cisco IOS XR Operations
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).
7–30
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Configuration Operations
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
© 2005 Cisco Systems, Inc.
Version 2.0b
7–31
Cisco IOS XR Operations
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:
7–32
•
commit—Show what was committed in a particular commit
•
failed—Commands that failed in a commit
•
removed—Parts 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
•
rollback—When 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-config—Shows the same information as the command show
running-config, that is the configuration currently controlling the
resources of the router
•
sessions—Manage and deactivate configuration sessions
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Configuration Operations
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
© 2005 Cisco Systems, Inc.
Version 2.0b
7–33
Cisco IOS XR Operations
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:
•
SNo—Sequence number of the change list
•
Label/ID—Identifier assigned to this change
•
User—Logged on user who committed the changes
•
Line—Method used to connect to the router
•
Client—Tool used to make the changes
•
Time Stamp—Time 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
7–34
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Configuration Operations
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
© 2005 Cisco Systems, Inc.
Version 2.0b
7–35
Cisco IOS XR Operations
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
7–36
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Configuration Operations
Display Committed Changes
• Display specific committed changes
RRP/0/0/CPU0:P4#show config commit changes doug
Building configuration...
username doug
password 7 110D161010
!
end
RP/0/0/CPU0:P4#show config commit changes 1000000163
Building configuration...
username doug
password 7 110D161010
!
end
RP/0/0/CPU0:P4#show config commit changes 1000000167
Building configuration...
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
Building configuration...
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
Building configuration...
config-register 0x2
Prior change
username doug
group root-system
Previous change
group cisco-support
!
xml agent corba
http server
Last change
end
© 2005 Cisco Systems, Inc.
Version 2.0b
7–37
Cisco IOS XR Operations
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.
7–38
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Configuration Operations
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
Building configuration...
config-register 0x2
Change # 166
username doug
Change # 163/doug
password 7 110D161010
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
© 2005 Cisco Systems, Inc.
Version 2.0b
7–39
Cisco IOS XR Operations
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:
•
last—Followed by a number value
•
to—Followed by the Label/ID
Each of these keywords is inclusive.
7–40
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Configuration Operations
Display Rollback Information
RP/0/RP1/CPU0:P4#show config rollback changes last 1
Building configuration...
username doug
no group root-system
no group cisco-support
!
end
RP/0/RP1/CPU0:P4#show config rollback changes last 2
Building configuration...
config-register 0x0
username doug
no group root-system
no group cisco-support
!
end
RP/0/RP1/CPU0:P4#show config rollback changes last 3
Building configuration...
config-register 0x0
username doug
no group root-system
no group cisco-support
!
no redundancy disable
end
Previous
changes
would be
reversed
• Display rollback changes (inclusive)
RP/0/RP1/CPU0:P4#show config rollback changes to doug
Building configuration...
config-register 0x0
no username doug
username doug
no password
no group root-system
no group cisco-support
!
no username jeff
username jeff
no password
!
no redundancy disable
end
• Display inclusive changes back to a certain commit
change
© 2005 Cisco Systems, Inc.
Version 2.0b
7–41
Cisco IOS XR Operations
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.
7–42
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Configuration Operations
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.
6 items committed in 1 sec (5)items/sec
Updating.
Updated Commit database in 1 sec
Configuration successfully rolled back 3 commits.
• Roll back last number (n) of changes
© 2005 Cisco Systems, Inc.
Version 2.0b
7–43
Cisco IOS XR Operations
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.
7–44
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Configuration Operations
Load a Specific Configuration
RP/0/0/CPU0:P4(config)#load commit changes 1000000169
Building configuration...
Loading.
49 bytes parsed in 1 sec (48)bytes/sec
RP/0/0/CPU0:P4(config)#show config
Building configuration...
no username ken
username ken
!
end
RP/0/0/CPU0:P4(config)#commit
• Enter configuration mode
• Load a previously committed change
• Recommit the change
© 2005 Cisco Systems, Inc.
Version 2.0b
7–45
Cisco IOS XR Operations
Module 7
commit Command Keywords
The commit command offers additional keywords to document the
changes as they occur:
7–46
•
replace—Lets you replace an entire running configuration with the
target configuration
•
comment—Lets you add a comment that is displayed when looking at
committed change information
•
label—Lets you label a change, when committing it; the label is
displayed when viewing committed change information
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Configuration Operations
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>
© 2005 Cisco Systems, Inc.
Version 2.0b
7–47
Cisco IOS XR Operations
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.
_________________________________________________________________
7–48
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Configuration Operations
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
© 2005 Cisco Systems, Inc.
Version 2.0b
7–49
Cisco IOS XR Operations
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.
7–50
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Configuration Operations
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
© 2005 Cisco Systems, Inc.
Version 2.0b
7–51
Cisco IOS XR Operations
Module 7
Miscellaneous CLI Commands
Storage Media Review
Cisco CRS-1 System
The following storage media is located on the Cisco CRS-1 System:
7–52
•
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
Cisco CRS-1 Essentials
Module 7
Miscellaneous CLI Commands
Storage Media Review
• Cisco CRS-1 Router
− Disk0:
− Disk1: (optional)
− Harddisk:
− NVRAM:
− Bootflash:
© 2005 Cisco Systems, Inc.
Version 2.0b
7–53
Cisco IOS XR Operations
Module 7
File Commands
The Cisco IOS XR software has its own file system commands that closely
resemble standard UNIX commands, such as:
•
cd—Change directory
•
pwd—Present working directory
•
dir—Print 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.
7–54
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Miscellaneous CLI Commands
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
commitdb_info_1000000136.snf
commitdb_info_1000000137.snf
1024442368 bytes total (876019712 bytes free)
• Display directory contents
© 2005 Cisco Systems, Inc.
Version 2.0b
7–55
Cisco IOS XR Operations
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
no group root-system
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.
81 bytes parsed in 1 sec (80)bytes/sec
Committing.
5 items committed in 1 sec (4)items/sec
Updating.
Updated Commit database in 1 sec
RP/0/0/CPU0:P4#show run username
username ed
password 7 110C1D
group cisco-support
7–56
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Miscellaneous CLI Commands
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.
5286 bytes parsed in 1 sec (5259)bytes/sec
Committing.............
169 items committed in 13 sec (12)items/sec
Updating...
Updated Commit database in 3 sec
RP/0/0/CPU0:P4#
© 2005 Cisco Systems, Inc.
Version 2.0b
7–57
Cisco IOS XR Operations
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.
7–58
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Miscellaneous CLI Commands
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)
© 2005 Cisco Systems, Inc.
Version 2.0b
7–59
Cisco IOS XR Operations
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.
7–60
Version 2.0b
Cisco CRS-1 Essentials
Module 7
Miscellaneous CLI Commands
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.”
© 2005 Cisco Systems, Inc.
Version 2.0b
7–61
Cisco IOS XR Operations
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.
7–62
Version 2.0b
Cisco CRS-1 Essentials
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.
© 2005 Cisco Systems, Inc.
Version 2.0b
7–63
Cisco IOS XR Operations
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:
7–64
•
Respawn—Restart the process, if a problem occurs with it
•
Respawn count—Number of times this process has restarted
•
Max. spawns per minute—When the maximum spawns is reached the
process will not be restarted automatically
•
Last started—When the last respawn took place. This could be the
result of a RP switchover or router reboot
•
Process state—State of the process when display was taken
Version 2.0b
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0b
7–65
Cisco IOS XR Operations
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.
7–66
Version 2.0b
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0b
7–67
Cisco IOS XR Operations
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.
7–68
Version 2.0b
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0b
7–69
Cisco IOS XR Operations
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.
_________________________________________________________________
7–70
Version 2.0b
Cisco CRS-1 Essentials
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
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: Killed (last exit status : 1)
Package state: Normal
Registered item(s): cfg/gl/ipv4-ospf/proc/
core: TEXT SHAREDMEM MAINMEM
Max. core: 0
Placement: ON
startup_path: /pkg/startup/ospf.startup
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
Executable path: /disk0/hfr-rout-3.2.81/bin/ospf
Instance #: 1
Version ID: 00.00.0000
Respawn: ON
Respawn count: 2
Max. spawns per minute: 12
Last started: Thu Mar 10 11:45:06 2005
Process state: Run (last exit status : 1)
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: 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
© 2005 Cisco Systems, Inc.
Version 2.0b
7–71
Cisco IOS XR Operations
Module 7
Summary
Cisco IOS XR Operations
In this module, you learned to:
7–72
•
Describe command modes
•
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
Cisco CRS-1 Essentials
Module 7
Review Questions
Cisco IOS XR Operations
1. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
2. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
3. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
4. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
5. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
© 2005 Cisco Systems, Inc.
Version 2.0b
7–73
Cisco IOS XR Operations
Module 7
c. <Insert Answer c>
d. <Insert Answer d>
7–74
Version 2.0b
Cisco CRS-1 Essentials
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
After completing this module, you will be able to:
•
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)
© 2005 Cisco Systems, Inc.
Version 2.0b
8–1
Cisco IOS XR Installation
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:
8–2
•
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
Cisco CRS-1 Essentials
Module 8
Cisco IOS XR Software Packaging
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.
© 2005 Cisco Systems, Inc.
Version 2.0b
8–3
Cisco IOS XR Installation
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.
_________________________________________________________________
8–4
Version 2.0b
Cisco CRS-1 Essentials
Module 8
Cisco IOS XR Software Packaging
Modular Packaging and Upgrades
RP
MSC or LC
DRP
Multicast
MPLS
Manageability
Security
MPLS
Multicast
Opt’l
Manageability
Opt'l
Security
MPLS
Opt’l
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
© 2005 Cisco Systems, Inc.
Version 2.0b
8–5
Cisco IOS XR Installation
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:
8–6
•
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
Cisco CRS-1 Essentials
Module 8
Cisco IOS XR Software Packaging
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.
© 2005 Cisco Systems, Inc.
Version 2.0b
8–7
Cisco IOS XR Installation
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.
8–8
Version 2.0b
Cisco CRS-1 Essentials
Module 8
Cisco IOS XR Software Packaging
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.
© 2005 Cisco Systems, Inc.
Version 2.0b
8–9
Cisco IOS XR Installation
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.
8–10
Version 2.0b
Cisco CRS-1 Essentials
Module 8
Cisco IOS XR Software Packaging
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 PIE’s will be new features as well as version upgrades, therefore they are
the most likely software installations they will do.
© 2005 Cisco Systems, Inc.
Version 2.0b
8–11
Cisco IOS XR Installation
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.
8–12
Version 2.0b
Cisco CRS-1 Essentials
Module 8
Cisco IOS XR Software Packaging
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!
© 2005 Cisco Systems, Inc.
Version 2.0b
8–13
Cisco IOS XR Installation
Module 8
Software Versions
Base Package Versions
Software package versions are identified by a three-part numeric scheme:
•
Major release—Contains 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 release—Contains 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 release—Contains 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>
8–14
Version 2.0b
Cisco CRS-1 Essentials
Module 8
Cisco IOS XR Software Packaging
Software Versions
Software delivery
type
Cisco CRS-1 Series Routers
Composite PIE
comp-platform-composite_name.piemajor.minor.maintenance
Single package
PIE
platform-package_type–p.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
© 2005 Cisco Systems, Inc.
Version 2.0b
8–15
Cisco IOS XR Installation
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.
8–16
Version 2.0b
Cisco CRS-1 Essentials
Module 8
Cisco IOS XR Software Packaging
Software Storage
CRS-1
Flash
disk1:
© 2005 Cisco Systems, Inc.
Version 2.0b
Flash
disk0:
internal
8–17
Cisco IOS XR Installation
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...
_________________________________________________________________
8–18
Version 2.0b
Cisco CRS-1 Essentials
Module 8
Cisco IOS XR Software Packaging
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
© 2005 Cisco Systems, Inc.
Version 2.0b
8–19
Cisco IOS XR Installation
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.
_________________________________________________________________
8–20
Version 2.0b
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0b
8–21
Cisco IOS XR Installation
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.
8–22
Version 2.0b
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0b
8–23
Cisco IOS XR Installation
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.
8–24
Version 2.0b
Cisco CRS-1 Essentials
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.
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 '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%] [OK]
Install 3: [ 1%] Checking API compatibility in software configurations...
Install 3: [ 1%] [OK]
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.
Additional messages are not shown
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.
© 2005 Cisco Systems, Inc.
Version 2.0b
8–25
Cisco IOS XR Installation
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.
8–26
Version 2.0b
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0b
8–27
Cisco IOS XR Installation
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.
8–28
Version 2.0b
Cisco CRS-1 Essentials
Module 8
Package Management
Deactivating Packages
RP/0/0/CPU0:P5(admin)#install deactivate disk0:c12k-rp-mgbl-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.
RP/0/0/CPU0:P5(admin)#
Install: Now operating in asynchronous mode. Do not attempt subsequent install operations
until this operation is complete.
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.
© 2005 Cisco Systems, Inc.
Version 2.0b
8–29
Cisco IOS XR Installation
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.
_________________________________________________________________
8–30
Version 2.0b
Cisco CRS-1 Essentials
Module 8
Package Management
Package Removal
RP/0/0/CPU0:P5(admin)#install remove disk0:c12k-mgbl-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.
RP/0/0/CPU0:P5(admin)#
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.
© 2005 Cisco Systems, Inc.
Version 2.0b
8–31
Cisco IOS XR Installation
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 log—Lists what occurred at each install point
•
show install committed—Lists 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
_________________________________________________________________
8–32
Version 2.0b
Cisco CRS-1 Essentials
Module 8
Package Management
install rollback Command
RP/0/0/CPU0:P5(admin)#install rollback 2
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:P5(admin)#
Install: Now operating in asynchronous mode. Do not attempt subsequent install operations
until this operation is complete.
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
Additional messages are not shown
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
Additional messages are not shown
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 ***
Install 11: [ 10%] Node 0/1/CPU0: *** Will be reloaded ***
Note reload
Install 11: [ 10%] Node 0/3/CPU0: *** Will be reloaded ***
Install 11: [ 10%] Node 0/4/CPU0: *** Will be reloaded ***
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
© 2005 Cisco Systems, Inc.
Version 2.0b
8–33
Cisco IOS XR Installation
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.
8–34
Version 2.0b
Cisco CRS-1 Essentials
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
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:P5(admin)#
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
© 2005 Cisco Systems, Inc.
Version 2.0b
8–35
Cisco IOS XR Installation
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.
8–36
Version 2.0b
Cisco CRS-1 Essentials
Module 8
Software Installation Review
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
Request id 2 by cisco at Tue May 31 11:02:51 2005:
1 pie added to disk0:: /tftp://172.21.116.8/c12k-mpls.pie-3.2.85.3I
Request id 3 by cisco at Tue May 31 11:06:31 2005:
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
Request id 5 by cisco at Wed Jun 01 11:02:24 2005:
1 package activated: disk0:c12k-mini-3.2.85
More information available via the command 'show install log 5'
Request id 6 by cisco at Wed Jun 01 11:26:32 2005:
Committed loadpath changes
5 entries shown (max log size 50 entries)
• Also applicable at the EXEC prompt
© 2005 Cisco Systems, Inc.
Version 2.0b
8–37
Cisco IOS XR Installation
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.
8–38
Version 2.0b
Cisco CRS-1 Essentials
Module 8
Software Installation Review
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
© 2005 Cisco Systems, Inc.
Version 2.0b
8–39
Cisco IOS XR Installation
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.
8–40
Version 2.0b
Cisco CRS-1 Essentials
Module 8
Software Installation Review
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]
Boot Image: /disk0/c12k-os-mbi-3.2.83/mbiprp-rp.vm
Active Packages:
disk0:c12k-mini-3.2.83
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:
disk0:c12k-mini-3.2.83
Node 0/4/CPU0 [LC(E3-OC48-POS)]
Boot Image: /disk0/c12k-os-mbi-3.2.83/gsr/ucode/mbiprp-lc.ucode
Active Packages:
disk0:c12k-mini-3.2.83
© 2005 Cisco Systems, Inc.
Version 2.0b
8–41
Cisco IOS XR Installation
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.
8–42
Version 2.0b
Cisco CRS-1 Essentials
Module 8
Software Installation Review
Display Active Package Details
RP/0/0/CPU0:P5#show install active detail
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
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]
Boot Image: /disk0/c12k-os-mbi-3.2.83/mbiprp-rp.vm
Active Packages:
disk0:c12k-mini-3.2.83
disk0:c12k-rout-3.2.83
disk0:c12k-lc-3.2.83
disk0:c12k-fwdg-3.2.83
disk0:c12k-admin-3.2.83
disk0:c12k-base-3.2.83
disk0:c12k-os-mbi-3.2.83
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:
disk0:c12k-mini-3.2.83
disk0:c12k-lc-3.2.83
disk0:c12k-fwdg-3.2.83
disk0:c12k-admin-3.2.83
disk0:c12k-base-3.2.83
disk0:c12k-os-mbi-3.2.83
© 2005 Cisco Systems, Inc.
Version 2.0b
8–43
Cisco IOS XR Installation
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.
8–44
Version 2.0b
Cisco CRS-1 Essentials
Module 8
Software Installation Review
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
© 2005 Cisco Systems, Inc.
Version 2.0b
8–45
Cisco IOS XR Installation
Module 8
Summary
Cisco IOS XR Installation
In this module, you learned to:
8–46
•
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
Cisco CRS-1 Essentials
Module 8
Review Questions
Cisco IOS XR Installation
1. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
2. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
3. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
4. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
5. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
© 2005 Cisco Systems, Inc.
Version 2.0b
8–47
Cisco IOS XR Installation
Module 8
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
8–48
Version 2.0b
Cisco CRS-1 Essentials
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
After completing this module, you will be able to:
•
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.
© 2005 Cisco Systems, Inc.
Version 1.0c
9–1
Cisco IOS XR Security
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.
9–2
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Cisco IOS XR Security Overview
Cisco IOS XR Security Overview
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
© 2005 Cisco Systems, Inc.
Version 1.0c
9–3
Cisco IOS XR Security
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.
9–4
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Cisco IOS XR Security Overview
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
© 2005 Cisco Systems, Inc.
Version 1.0c
9–5
Cisco IOS XR Security
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.
9–6
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Cisco IOS XR Security Overview
Cisco IOS XR Security Overview (Cont.)
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
© 2005 Cisco Systems, Inc.
Version 1.0c
9–7
Cisco IOS XR Security
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.
9–8
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Cisco IOS XR Security Overview
Cisco IOS XR Security Overview (Cont.)
• 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
© 2005 Cisco Systems, Inc.
Version 1.0c
9–9
Cisco IOS XR Security
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.
9–10
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Cisco IOS XR Security Implementation
AAA Implementation Planes
Logical router (LR) plane
Administration (Admin) plane
ADMIN
LR
AAA
Single physical router
© 2005 Cisco Systems, Inc.
Version 1.0c
9–11
Cisco IOS XR Security
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.
9–12
•
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
Cisco CRS-1 Essentials
Module 9
Cisco IOS XR Security Implementation
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
© 2005 Cisco Systems, Inc.
Version 1.0c
9–13
Cisco IOS XR Security
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.
9–14
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Cisco IOS XR Security Implementation
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
© 2005 Cisco Systems, Inc.
Version 1.0c
9–15
Cisco IOS XR Security
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:
•
Read—permits a read operation only
•
Write—permits a write operation and an implicit read operation
•
Execute—permits an access operation, such as to a copy, ping, or telnet
•
Debug—permits 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.
9–16
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Cisco IOS XR Security Implementation
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.
© 2005 Cisco Systems, Inc.
Version 1.0c
9–17
Cisco IOS XR Security
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 user’s 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-system—Root-system users
•
root-lr—Root-logical router users
•
netadmin—Network administrators
•
sysadmin—System administrators
•
operator—Day-to-day activity users
Users can configure their own task groups to meet particular needs.
Task groups support inheritance from other task groups.
9–18
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Cisco IOS XR Security Implementation
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
© 2005 Cisco Systems, Inc.
Version 1.0c
9–19
Cisco IOS XR Security
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.
9–20
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Cisco IOS XR Security Implementation
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
© 2005 Cisco Systems, Inc.
Version 1.0c
9–21
Cisco IOS XR Security
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-system—Controls and monitors the entire router
•
root-lr—Controls and monitors a specific LR
•
sysadmin—Controls and monitors all system parameters, but cannot
configure network protocols
•
netadmin—Controls and monitors all system and network parameters
•
operator—Has 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.
9–22
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Cisco IOS XR Security Implementation
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
© 2005 Cisco Systems, Inc.
Version 1.0c
9–23
Cisco IOS XR Security
Module 9
Predefined User Group Permissions
Cisco IOS XR software provides these user groups with predefined
attributes.
9–24
•
root-system—The 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-lr—The LR owner can perform all write commands, except the
root-system owner tasks, which are read only.
•
netadmin—The 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.
•
sysadmin—The 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.
•
operator—The 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
Cisco CRS-1 Essentials
Module 9
Cisco IOS XR Security Implementation
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
© 2005 Cisco Systems, Inc.
Version 1.0c
9–25
Cisco IOS XR Security
Module 9
Users
Cisco IOS XR software attributes forms the basis of router user access.
Each router user is associated with the following:
9–26
•
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
Cisco CRS-1 Essentials
Module 9
Cisco IOS XR Security Implementation
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
© 2005 Cisco Systems, Inc.
Version 1.0c
9–27
Cisco IOS XR Security
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.
_________________________________________________________________
9–28
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Cisco IOS XR Security Implementation
Local AAA and Database
Authentication, authorization, and accounting (AAA)
• Users, user groups, and task groups are stored
in a local database (SysDB)
© 2005 Cisco Systems, Inc.
Version 1.0c
9–29
Cisco IOS XR Security
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.
9–30
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Cisco IOS XR Security Implementation
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
© 2005 Cisco Systems, Inc.
Version 1.0c
9–31
Cisco IOS XR Security
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).
9–32
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Cisco IOS XR Security Implementation
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
© 2005 Cisco Systems, Inc.
Version 1.0c
9–33
Cisco IOS XR Security
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:
•
login—Sets login authentication
•
group tacacs+—Uses a server group or TACACS+ servers for
authentication
•
local—Uses a local username or password database for authentication
•
line—Uses 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:
•
Command—Applies authorization to the EXEC mode commands
issued by a user. Command authorization attempts authorization for
all EXEC mode commands.
•
EXEC—Applies authorization to the startup of an EXEC session.
•
Network—Applies 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.
9–34
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Cisco IOS XR Security Implementation
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
© 2005 Cisco Systems, Inc.
Version 1.0c
9–35
Cisco IOS XR Security
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.
9–36
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Cisco IOS XR Security Implementation
Authentication Flow of Control
1
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
© 2005 Cisco Systems, Inc.
Version 1.0c
9–37
Cisco IOS XR Security
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.
9–38
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Cisco IOS XR Security Implementation
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)
© 2005 Cisco Systems, Inc.
Version 1.0c
9–39
Cisco IOS XR Security
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.
9–40
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Cisco IOS XR Security Implementation
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
© 2005 Cisco Systems, Inc.
Version 1.0c
9–41
Cisco IOS XR Security
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.
9–42
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Security Configuration
Site-Defined Groups and Users
Configuration flow
Task group (TG)
• Name
• Task ID associations
− Read, write, so on
• Inheritance of other
TG permissions
© 2005 Cisco Systems, Inc.
User group (UG)
• Name
• Inheritance of
TG permissions
• Taskgroup
associations
Version 1.0c
User
• Name
• Password
• List of user
groups
9–43
Cisco IOS XR Security
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.
9–44
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Security Configuration
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
© 2005 Cisco Systems, Inc.
Version 1.0c
9–45
Cisco IOS XR Security
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.
9–46
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Security Configuration
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)#
© 2005 Cisco Systems, Inc.
Version 1.0c
9–47
Cisco IOS XR Security
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.
9–48
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Security Configuration
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
© 2005 Cisco Systems, Inc.
Version 1.0c
9–49
Cisco IOS XR Security
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.
9–50
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Security Configuration
Creating User Groups
Configure “usergroup routeadmin”
RP/0/RP0/CPU0:POD5#configure
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)#
© 2005 Cisco Systems, Inc.
Version 1.0c
9–51
Cisco IOS XR Security
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.
9–52
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Security Configuration
Verifying User Group Configuration
RP/0/0/CPU0:POD5#show aaa usergroup
User group 'routeadmin'
contains task group 'bgpadmin'
© 2005 Cisco Systems, Inc.
Version 1.0c
9–53
Cisco IOS XR Security
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.
−
−
Password—Lower security
−
Unencrypted version that uses a parameter value of 0, which is
the default
−
Hidden version that uses a parameter value of 7
Secret—Higher 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.
9–54
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Security Configuration
Configuring Users
Configure a user
RP/0/RP0/CPU0:POD5#configure
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.
© 2005 Cisco Systems, Inc.
Version 1.0c
9–55
Cisco IOS XR Security
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.
9–56
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Security Configuration
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.
© 2005 Cisco Systems, Inc.
Version 1.0c
9–57
Cisco IOS XR Security
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).
9–58
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Access Control Lists
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
© 2005 Cisco Systems, Inc.
Version 1.0c
9–59
Cisco IOS XR Security
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.
9–60
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Access Control Lists
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
© 2005 Cisco Systems, Inc.
Version 1.0c
9–61
Cisco IOS XR Security
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.
9–62
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Access Control Lists
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
© 2005 Cisco Systems, Inc.
Version 1.0c
9–63
Cisco IOS XR Security
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
9–64
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Access Control Lists
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
ipv4 access-list Ethernet_In
1 deny udp any eq netbios-ns any
2 deny udp any host 255.255.255.255 eq tftp
3 deny udp any eq netbios-dgm any
4 permit any
• Sample ACL
RP/0/RP0/CPU0:POD5#show access-list ipv4 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
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
RP/0/RP0/CPU0:POD5#show access-list ipv4 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
© 2005 Cisco Systems, Inc.
Version 1.0c
9–65
Cisco IOS XR Security
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.
9–66
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Access Control Lists
Resequencing ACLs
• Sample ACL
RP/0/RP0/CPU0:POD5#show access-list ipv4 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
3 permit any
• Resequence the ACL
RP/0/RP0/CPU0:POD5#resequence access-list ipv4 Ethernet_In
• Modified sample ACL
RP/0/RP0/CPU0:POD5#show access-list ipv4 Ethernet_In
ipv4 access-list Ethernet_In
10 deny udp any eq netbios-ns any
20 deny udp any host 255.255.255.255 eq tftp
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.
© 2005 Cisco Systems, Inc.
Version 1.0c
9–67
Cisco IOS XR Security
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.
9–68
Version 1.0c
Cisco CRS-1 Essentials
Module 9
Access Control Lists
Copying ACLs
RP/0/RP0/CPU0:POD5#copy access-list ipv4 pod5 pod5copy
© 2005 Cisco Systems, Inc.
Version 1.0c
9–69
Cisco IOS XR Security
Module 9
Summary
Cisco IOS XR Security
In this module, you learned to:
9–70
•
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
Cisco CRS-1 Essentials
Module 9
Review Questions
Cisco IOS XR Security
1. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
2. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
3. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
4. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
5. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
© 2005 Cisco Systems, Inc.
Version 1.0c
9–71
Cisco IOS XR Security
Module 9
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
9–72
Version 1.0c
Cisco CRS-1 Essentials
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
After completing this module, you will be able to:
•
Configure BGP
•
Configure OSPF
•
Configure IS-IS
•
Configure Multicast Routing
•
Identify functional and configuration differences between Cisco IOS
and Cisco IOS XR routing protocols
© 2005 Cisco Systems, Inc.
Version 2.0a
10–1
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.
10–2
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Border Gateway Protocol (BGP)
Functional Differences
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)
© 2005 Cisco Systems, Inc.
Version 2.0a
10–3
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.
10–4
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Border Gateway Protocol (BGP)
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
Routing Policy Language (RPL)
• Most route map usage replaced
• Inbound and outbound policies required for eBGP
Dynamic update groups
© 2005 Cisco Systems, Inc.
Version 2.0a
10–5
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.
10–6
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Border Gateway Protocol (BGP)
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.
© 2005 Cisco Systems, Inc.
Version 2.0a
10–7
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.
10–8
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Border Gateway Protocol (BGP)
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)# router bgp 65000
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)# update-source Loopback0
© 2005 Cisco Systems, Inc.
Version 2.0a
10–9
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.
10–10
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Border Gateway Protocol (BGP)
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)# neighbor 10.60.70.10
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.
© 2005 Cisco Systems, Inc.
Version 2.0a
10–11
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.
10–12
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Border Gateway Protocol (BGP)
address-family Command
router(config-bgp)#
router(config-bgp-nbr)#
address-family {ipv4 | ipv6} {unicast | multicast}
RP/0/RP0/CPU0:router(config)# router bgp 65000
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)# neighbor 10.1.1.1
RP/0/RP0/CPU0:router(config-bgp-nbr)# remote-as 64500
RP/0/RP0/CPU0:router(config-bgp-nbr)# address-family ipv4 unicast
RP/0/RP0/CPU0:router(config-bgp-nbr-af)# weight 200
© 2005 Cisco Systems, Inc.
Version 2.0a
10–13
Routing Protocols
Module 10
Configuration Example
The topology and configuration on the opposite page is similar to part of
the course’s 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.
10–14
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Border Gateway Protocol (BGP)
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
!
interface POS0/3/0/1
ipv4 address 142.50.20.3 255.255.255.0
!
interface POS0/4/0/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
address-family ipv4 unicast
!
!
neighbor 100.10.20.1
use neighbor-group internal
description P1 router
!
neighbor 100.10.20.2
use neighbor-group internal
description P2 router
!
!
© 2005 Cisco Systems, Inc.
Version 2.0a
10–15
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.
10–16
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Border Gateway Protocol (BGP)
show Commands
Effective neighbor configuration and inheritance
RP/0/0/CPU0:P3# show bgp neighbors 100.10.20.1 configuration
neighbor 100.10.20.1
remote-as 65000
[n:internal]
password encrypted 121A0C041104 [n:internal]
update-source Loopback0
[n:internal]
address-family ipv4 unicast
[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
© 2005 Cisco Systems, Inc.
Version 2.0a
TblVer
1
1
InQ OutQ Up/Down St/PfxRcd
0
0
1d19h
0
0
0
1d19h
0
10–17
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.
10–18
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Border Gateway Protocol (BGP)
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
© 2005 Cisco Systems, Inc.
Version 2.0a
Only deterministic behavior is
supported
10–19
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.
10–20
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Border Gateway Protocol (BGP)
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
© 2005 Cisco Systems, Inc.
Version 2.0a
10–21
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.
10–22
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Border Gateway Protocol (BGP)
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
© 2005 Cisco Systems, Inc.
Version 2.0a
10–23
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.
10–24
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Border Gateway Protocol (BGP)
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”
© 2005 Cisco Systems, Inc.
Version 2.0a
10–25
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.
10–26
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Border Gateway Protocol (BGP)
Distributed BGP Processes
BGP speaker—Multiple 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
© 2005 Cisco Systems, Inc.
Partial
bestpaths
Version 2.0a
10–27
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:
Hierarchy—CLI configuration hierarchy is supported.
Inheritance—CLI configuration inheritance is supported.
Stub areas—Stub areas are supported.
Not-So-Stubby-Areas (NSSA) —RFC 1587 is supported.
Virtual links—Virtual links are supported.
OSPF over demand circuits—RFC 1793 is supported.
Non-Stop Forwarding (NSF) —NSF is supported for OSPFv2.
Shortest Path First (SPF) throttling—SPF throttling is supported.
Route redistribution—Routes learned by any IP routing protocol can be
redistributed into any other IP routing protocol.
Authentication—Plain 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 parameters—Configurable interface parameters,
such as metric, retransmission interval, transmit delay, router priority,
dead interval, hello interval, and authentication key are supported.
10–28
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Open Shortest Path First (OSPF)
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
© 2005 Cisco Systems, Inc.
Version 2.0a
10–29
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.
10–30
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Open Shortest Path First (OSPF)
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)
© 2005 Cisco Systems, Inc.
Version 2.0a
10–31
Routing Protocols
Module 10
Configuration Differences
The key differences in OSPF configuration commands between Cisco IOS
and Cisco IOS XR are:
10–32
•
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
Cisco CRS-1 Essentials
Module 10
Open Shortest Path First (OSPF)
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)# interface pos0/0/1
Router(config-if)# ip address 10.1.1.5 255.255.255.252
Router(config-if)# ip ospf cost 40
Router(config-if)# exit
!
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)# interface pos0/4/0/1
RP/0/RP0/CPU0:router(config-if)# ip address 10.1.1.5 255.255.255.252
RP/0/RP0/CPU0:router(config-if)# exit
!
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)# interface pos0/4/0/1
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.
© 2005 Cisco Systems, Inc.
Version 2.0a
10–33
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:
10–34
•
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
Cisco CRS-1 Essentials
Module 10
Open Shortest Path First (OSPF)
Differences for OSPFv3
Cisco IOS configuration
Router(config)# interface pos0/0/0
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-if)# exit
!
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)# interface pos0/4/0/1
RP/0/RP0/CPU0:router(config-if)# ipv6 address 2002:1234::212/64
RP/0/RP0/CPU0:router(config-if)# exit
!
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)# area 0
RP/0/RP0/CPU0:router(config-ospf-ar)# interface pos0/4/0/1
RP/0/RP0/CPU0:router(config-ospf-ar-if)# cost 20
© 2005 Cisco Systems, Inc.
Version 2.0a
10–35
Routing Protocols
Module 10
Configuring OSPF
OSPF is enabled from the global configuration mode.
Step 1—router 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.
_________________________________________________________________
10–36
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Open Shortest Path First (OSPF)
Configuring OSPF—router ospf Command
Step 1—Configure 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
© 2005 Cisco Systems, Inc.
Version 2.0a
10–37
Routing Protocols
Module 10
Step 2—router-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 3—area 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.
_________________________________________________________________
10–38
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Open Shortest Path First (OSPF)
Configuring OSPF—router-id and area Commands
Step 2—Optionally 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 3—Configure OSPF area
area area-id
RP/0/RP0/CPU0:router(config-ospf)# area 0
© 2005 Cisco Systems, Inc.
Version 2.0a
10–39
Routing Protocols
Module 10
Step 4—interface 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.
10–40
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Open Shortest Path First (OSPF)
Configuring OSPF—interface Command
Step 4—Configure 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.
© 2005 Cisco Systems, Inc.
Version 2.0a
10–41
Routing Protocols
Module 10
Step 5—Interface-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.
10–42
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Open Shortest Path First (OSPF)
Configuring OSPF—Interface-level Command Example
Step 5—Configure 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
© 2005 Cisco Systems, Inc.
Version 2.0a
10–43
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).
_________________________________________________________________
10–44
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Open Shortest Path First (OSPF)
MD5 Authentication
router (config-ospf)#
authentication [message-digest | null]
RP/0/RP0/CPU0:router(config-ospf)# authentication message-digest
router (config-ospf)#
message-digest-key key-id md5 [encryption-type] key
RP/0/RP0/CPU0:router(config-ospf)# message-digest-key 4 md5 key1
© 2005 Cisco Systems, Inc.
Version 2.0a
10–45
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.
10–46
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Open Shortest Path First (OSPF)
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
!
interface POS0/4/0/0
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
interface POS0/4/0/0
message-digest-key 5 md5 ospf-key
© 2005 Cisco Systems, Inc.
Version 2.0a
10–47
Routing Protocols
Module 10
Intermediate System-Intermediate System (IS-IS)
Functional Differences
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:
10–48
•
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
Cisco CRS-1 Essentials
Module 10
Intermediate System-Intermediate System (IS-IS)
Functional Differences
Architecture changes
• Hierarchical configuration
• Multiple IS-IS instances
• Multi-topology as the default behavior
Other changes
• IS-IS supports only IP routing—no 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.
© 2005 Cisco Systems, Inc.
Version 2.0a
10–49
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.
10–50
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Intermediate System-Intermediate System (IS-IS)
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
© 2005 Cisco Systems, Inc.
Version 2.0a
10–51
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.
10–52
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Intermediate System-Intermediate System (IS-IS)
Multiple Instance Example
Level 2 Area 49.0003
Level 1 Area 49.0001
Level 1 Area 49.0002
1 Level 2 instance
2 Level 1 instances
© 2005 Cisco Systems, Inc.
Version 2.0a
10–53
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, we’ve 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.
10–54
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Intermediate System-Intermediate System (IS-IS)
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
address-family ipv4 unicast
set-attached-bit
!
interface POS0/4/0/0
address-family ipv4 unicast
!
!
interface POS0/4/0/1
address-family ipv4 unicast
!
!
!
--More--
router isis r2
is-type level-1
net 49.0002.0000.0000.0002.00
address-family ipv4 unicast
set-attached-bit
!
interface POS0/4/0/2
address-family ipv4 unicast
!
!
!
router isis r3
is-type level-2-only
net 49.0003.0000.0000.0003.00
address-family ipv4 unicast
redistribute isis r1 level-2 metric 0 metric-type internal
redistribute isis r2 level-2 metric 0 metric-type internal
distance 116
!
interface POS0/4/0/3
address-family ipv4 unicast
!
!
!
© 2005 Cisco Systems, Inc.
Version 2.0a
10–55
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.
10–56
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Intermediate System-Intermediate System (IS-IS)
Other Configuration Examples
Setting instance-wide address family specific values
RP/0/RP0/CPU0:router(config)# router isis lab
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)# 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
RP/0/RP0/CPU0:router(config-isis-af)# propagate level 2 into level 1 distribute-list
L21
© 2005 Cisco Systems, Inc.
Version 2.0a
10–57
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.
10–58
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Intermediate System-Intermediate System (IS-IS)
Configuration Comparison
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
address-family ipv4 unicast
metric-style wide
!
interface Loopback0
passive
address-family ipv4 unicast
!
!
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
interface POS0/4/0/0
address-family ipv4 unicast
!
!
© 2005 Cisco Systems, Inc.
Version 2.0a
10–59
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 didn’t seem to have
any effect on the specifics of the debug output; it appeared to be the same with or without the
keyword.
10–60
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Intermediate System-Intermediate System (IS-IS)
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
© 2005 Cisco Systems, Inc.
Version 2.0a
10–61
Routing Protocols
Module 10
Multicast Routing
Functional Differences
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.
10–62
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Multicast Routing
Functional Differences
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 Cisco’s 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.
© 2005 Cisco Systems, Inc.
Version 2.0a
10–63
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.
10–64
Version 2.0a
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0a
10–65
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.
_________________________________________________________________
10–66
Version 2.0a
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0a
10–67
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.
10–68
Version 2.0a
Cisco CRS-1 Essentials
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 address—use the loopback address
RP/0/RP0/CPU0:router(config-pim-ipv4)# rp-address 1.1.1.1
© 2005 Cisco Systems, Inc.
Version 2.0a
10–69
Routing Protocols
Module 10
If your router is a potential RP, you need to configure it as a candidate RP
(CRP). With auto−RP 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 RP−to−group 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.
10–70
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Multicast Routing
PIM Configuration (continued)
RP/0/0/CPU0:router(config-pim-ipv4)#
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
RP/0/0/CPU0:router(config-pim-ipv4)#
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.
© 2005 Cisco Systems, Inc.
Version 2.0a
10–71
Routing Protocols
Module 10
Configuration Comparison
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.
10–72
Version 2.0a
Cisco CRS-1 Essentials
Module 10
Multicast Routing
Configuration Comparison
Cisco IOS XR
Cisco IOS
Enable Multicast:
Enable Multicast:
interface POS4/0
ip multicast-routing
multicast-routing
interface POS0/4/0/0
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
interface POS0/4/0/0
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
© 2005 Cisco Systems, Inc.
Version 2.0a
10–73
Routing Protocols
Module 10
Summary
Routing Protocols
In this module, you learned:
10–74
•
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
Cisco CRS-1 Essentials
Module 10
Review Questions
Routing Protocols
1. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
2. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
3. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
4. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
5. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
© 2005 Cisco Systems, Inc.
Version 2.0a
10–75
Routing Protocols
Module 10
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
10–76
Version 2.0a
Cisco CRS-1 Essentials
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
After completing this module, you will be able to:
•
Write policies in RPL
•
Use hierarchical and parameterized policies
•
Convert route maps to RPL policies
© 2005 Cisco Systems, Inc.
Version 2.0
11–1
Routing Policy Language
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 1000’s of route maps with
their implied redundancy.
11–2
Version 2.0
Cisco CRS-1 Essentials
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 ISP’s 15K lines of route maps in 1K lines of RPL policy.
© 2005 Cisco Systems, Inc.
Version 2.0
11–3
Routing Policy Language
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.
11–4
Version 2.0
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0
11–5
Routing Policy Language
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.
11–6
Version 2.0
Cisco CRS-1 Essentials
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?
© 2005 Cisco Systems, Inc.
Version 2.0
11–7
Routing Policy Language
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.
11–8
Version 2.0
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0
11–9
Routing Policy Language
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 Repository—Compiles 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 engine—Is 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.
11–10
Version 2.0
Cisco CRS-1 Essentials
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)
© 2005 Cisco Systems, Inc.
Version 2.0
11–11
Routing Policy Language
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 0–9; 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
11–12
Version 2.0
Cisco CRS-1 Essentials
Module 11
RPL Description
Basic Building Blocks and Functions
Route Policy
Language
AS Path Sets
© 2005 Cisco Systems, Inc.
Route Policies
Policy Sets
Community
Sets
Extended
Community
Sets
Version 2.0
Prefix Sets
11–13
Routing Policy Language
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.
_________________________________________________________________
11–14
Version 2.0
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0
11–15
Routing Policy Language
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.
11–16
Version 2.0
Cisco CRS-1 Essentials
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.
© 2005 Cisco Systems, Inc.
Version 2.0
11–17
Routing Policy Language
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>
address-family ipv4 unicast
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 don’t 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.
_________________________________________________________________
11–18
Version 2.0
Cisco CRS-1 Essentials
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
address-family ipv4 unicast
policy foo in
policy bar out
© 2005 Cisco Systems, Inc.
Version 2.0
11–19
Routing Policy Language
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.
11–20
Version 2.0
Cisco CRS-1 Essentials
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
Neighbor export/import
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
© 2005 Cisco Systems, Inc.
Version 2.0
11–21
Routing Policy Language
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.
11–22
Version 2.0
Cisco CRS-1 Essentials
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
Neighbor export/import
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
© 2005 Cisco Systems, Inc.
Version 2.0
11–23
Routing Policy Language
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.
11–24
Version 2.0
Cisco CRS-1 Essentials
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$’)
© 2005 Cisco Systems, Inc.
Version 2.0
11–25
Routing Policy Language
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
_________________________________________________________________
11–26
Version 2.0
Cisco CRS-1 Essentials
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)
© 2005 Cisco Systems, Inc.
Version 2.0
11–27
Routing Policy Language
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.
11–28
Version 2.0
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0
11–29
Routing Policy Language
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$')
11–30
Version 2.0
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0
11–31
Routing Policy Language
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
11–32
Version 2.0
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0
11–33
Routing Policy Language
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:val—Defines 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:val—Defines 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:n—Route Target (RT) in IPv4 format
RT:asn:n—RT in AS format
SoO:a.b.c.d:n—Site of Origin (SoO) in IPv4 format
SoO:asn:n—SoO 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.
_________________________________________________________________
11–34
Version 2.0
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0
11–35
Routing Policy Language
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
set community (12:56) additive
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
set local-preference 60
else
set local-preference 0
endif
11–36
Version 2.0
Cisco CRS-1 Essentials
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
set local-preference 10
elseif med eq 200 then
set local-preference 60
else
set local-preference 0
endif
© 2005 Cisco Systems, Inc.
Version 2.0
11–37
Routing Policy Language
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
set local-preference 100
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.
_________________________________________________________________
11–38
Version 2.0
Cisco CRS-1 Essentials
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
set local-preference 100
endif
© 2005 Cisco Systems, Inc.
Version 2.0
11–39
Routing Policy Language
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)
11–40
Version 2.0
Cisco CRS-1 Essentials
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 …
© 2005 Cisco Systems, Inc.
Version 2.0
11–41
Routing Policy Language
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 route’s next hop is 10.0.2.2 then the entire compound
condition is true. Otherwise the compound condition is false.
11–42
Version 2.0
Cisco CRS-1 Essentials
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))
© 2005 Cisco Systems, Inc.
Version 2.0
11–43
Routing Policy Language
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
set local-preference 200
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
if destination in (10.0.0.0/8 ge 8 le 32) then
set local-preference 200
endif
end-policy
11–44
Version 2.0
Cisco CRS-1 Essentials
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.
© 2005 Cisco Systems, Inc.
Version 2.0
11–45
Routing Policy Language
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.
11–46
Version 2.0
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0
11–47
Routing Policy Language
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.
11–48
Version 2.0
Cisco CRS-1 Essentials
Module 11
BGP Route Attributes and Operations
BGP Route Attributes
Attribute
BGP
as-path
X
community
X
dampening
X
destination
X
extended community
X
local preference
X
med
X
next-hop
X
origin
X
route-type
Cisco
X
source
X
suppress
X
tag
X
traffic-index
X
weight
X
Instructor’s 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.
© 2005 Cisco Systems, Inc.
Version 2.0
11–49
Routing Policy Language
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.
11–50
Version 2.0
Cisco CRS-1 Essentials
Module 11
BGP Route Attributes and Operations
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.
© 2005 Cisco Systems, Inc.
Version 2.0
11–51
Routing Policy Language
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).
11–52
Version 2.0
Cisco CRS-1 Essentials
Module 11
BGP Route Attributes and Operations
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.
© 2005 Cisco Systems, Inc.
Version 2.0
11–53
Routing Policy Language
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.
_________________________________________________________________
11–54
Version 2.0
Cisco CRS-1 Essentials
Module 11
BGP Route Attributes and Operations
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.
© 2005 Cisco Systems, Inc.
Version 2.0
11–55
Routing Policy Language
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.
11–56
Version 2.0
Cisco CRS-1 Essentials
Module 11
BGP Route Attributes and Operations
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
© 2005 Cisco Systems, Inc.
Version 2.0
11–57
Routing Policy Language
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.
11–58
Version 2.0
Cisco CRS-1 Essentials
Module 11
BGP Route Attributes and Operations
Destination
destination -- Match
if destination in (10.0.0.0/8 ge 8 le 32) then
set local-preference 200
endif
© 2005 Cisco Systems, Inc.
Version 2.0
11–59
Routing Policy Language
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.
11–60
Version 2.0
Cisco CRS-1 Essentials
Module 11
BGP Route Attributes and Operations
Extended Community
extcommunity -- Match
if extcommunity matchs-any ec1 then …
If extcommunity matchs-every ec2 then …
If extcommunity is-empty then …
© 2005 Cisco Systems, Inc.
Version 2.0
11–61
Routing Policy Language
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>
11–62
Version 2.0
Cisco CRS-1 Essentials
Module 11
BGP Route Attributes and Operations
Local Preference
local-preference -- Assignment
set local-preference 200
© 2005 Cisco Systems, Inc.
Version 2.0
11–63
Routing Policy Language
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.
11–64
Version 2.0
Cisco CRS-1 Essentials
Module 11
BGP Route Attributes and Operations
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.
© 2005 Cisco Systems, Inc.
Version 2.0
11–65
Routing Policy Language
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.
11–66
Version 2.0
Cisco CRS-1 Essentials
Module 11
BGP Route Attributes and Operations
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 ...
© 2005 Cisco Systems, Inc.
Version 2.0
11–67
Routing Policy Language
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}
11–68
Version 2.0
Cisco CRS-1 Essentials
Module 11
BGP Route Attributes and Operations
Origin
origin -- Match
if origin is igp or origin is incomplete then …
origin -- Assignment
set origin incomplete
© 2005 Cisco Systems, Inc.
Version 2.0
11–69
Routing Policy Language
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.
11–70
Version 2.0
Cisco CRS-1 Essentials
Module 11
BGP Route Attributes and Operations
Source
source -- Match
if source matches-any my_prefix_set then ...
© 2005 Cisco Systems, Inc.
Version 2.0
11–71
Routing Policy Language
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.
11–72
Version 2.0
Cisco CRS-1 Essentials
Module 11
BGP Route Attributes and Operations
Tag
tag -- Match
if tag eq 10 then …
tag -- Assignment
set tag 20
© 2005 Cisco Systems, Inc.
Version 2.0
11–73
Routing Policy Language
Module 11
Traffic-Index
The traffic-index is a special attribute for Cisco’s 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.
11–74
Version 2.0
Cisco CRS-1 Essentials
Module 11
BGP Route Attributes and Operations
Traffic-Index
traffic-index -- Assignment
set traffic-index 10
set traffic-index $tindex
set traffic-index ignore
© 2005 Cisco Systems, Inc.
Version 2.0
11–75
Routing Policy Language
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.
11–76
Version 2.0
Cisco CRS-1 Essentials
Module 11
BGP Route Attributes and Operations
Weight
weight -- Assignment
set weight 100
© 2005 Cisco Systems, Inc.
Version 2.0
11–77
Routing Policy Language
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.
11–78
Version 2.0
Cisco CRS-1 Essentials
Module 11
Converting Route Maps to RPL Policies
Converting Route Maps to RPL Policies
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
© 2005 Cisco Systems, Inc.
Version 2.0
11–79
Routing Policy Language
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.
11–80
Version 2.0
Cisco CRS-1 Essentials
Module 11
Converting Route Maps to RPL Policies
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
© 2005 Cisco Systems, Inc.
Version 2.0
11–81
Routing Policy Language
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.
_________________________________________________________________
11–82
Version 2.0
Cisco CRS-1 Essentials
Module 11
Converting Route Maps to RPL Policies
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
route-map sample2 permit 10
match ip address prefix-list 102
match community 1
set metric 11
set community 12:35 additive
route-map sample1 permit 20
match ip address prefix-list 101
match community 2
set metric 12
set community 12:34 additive
route-map sample2 permit 20
match ip address prefix-list 102
match community 2
set metric 12
set community 12:35 additive
route-map sample1 permit 30
match ip address prefix-list 101
match community 3
set metric 13
set community 12:34 additive
route-map sample2 permit 30
match ip address prefix-list 102
match community 3
set metric 13
set community 12:35 additive
route-map sample1 permit 40
match ip address prefix-list 101
match community 4
set metric 14
set community 12:34 additive
route-map sample2 permit 40
match ip address prefix-list 102
match community 4
set metric 14
set community 12:35 additive
route-map sample1 permit 50
match ip address prefix-list 101
set metric 100
set community 12:34 additive
route-map sample2 permit 50
match ip address prefix-list 102
set metric 100
set community 12:35 additive
© 2005 Cisco Systems, Inc.
Version 2.0
11–83
Routing Policy Language
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.
11–84
Version 2.0
Cisco CRS-1 Essentials
Module 11
Converting Route Maps to RPL Policies
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
© 2005 Cisco Systems, Inc.
Version 2.0
11–85
Routing Policy Language
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.
11–86
Version 2.0
Cisco CRS-1 Essentials
Module 11
Converting Route Maps to RPL Policies
Direct Translation (continued)
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
set community 12:34 additive
elseif destination in ps101 and community matches-any cs2 then
set med 12
set community 12:34 additive
elseif destination in ps101 and community matches-any cs3 then
set med 13
set community 12:34 additive
elseif destination in ps101 and community matches-any cs4 then
set med 14
set community 12:34 additive
elseif destination in ps101
set med 100
set community 12:34 additive
endif
end-policy
© 2005 Cisco Systems, Inc.
Version 2.0
11–87
Routing Policy Language
Module 11
Direct Translation (continued)
The same steps used to convert the first route-map are now used to convert
the second route map part of the initial policy.
11–88
Version 2.0
Cisco CRS-1 Essentials
Module 11
Converting Route Maps to RPL Policies
Direct Translation (continued)
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.
route-policy policy2
if destination in ps102 and community matches-any cs1 then
set med 11
set community (12:35) additive
elseif destination in ps102 and community matches-any cs2 then
set med 12
set community (12:35) additive
elseif destination in ps102 and community matches-any cs3 then
set med 13
set community (12:35) additive
elseif destination in ps102 and community matches-any cs4 then
set med 14
set community (12:35) additive
elseif destination in ps102
set med 100
set community (12:35) additive
endif
end-policy
© 2005 Cisco Systems, Inc.
Version 2.0
11–89
Routing Policy Language
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.
11–90
Version 2.0
Cisco CRS-1 Essentials
Module 11
Converting Route Maps to RPL Policies
Nest Conditionals
Replace the redundant “if destination
in” conditional and “set community”
statements in the first route policy by
just one instance each.
route-policy policy1
if destination in ps101 then
set community (12:34) additive
if community matches-any cs1 then
set med 11
elseif community matches-any cs2 then
set med 12
elseif community matches-any cs3 then
set med 13
elseif community matches-any cs4 then
set med 14
else
set med 100
endif
endif
end-policy
© 2005 Cisco Systems, Inc.
Leave the nested ‘if community”
conditionals to reduce size and
evaluation processing.
Version 2.0
11–91
Routing Policy Language
Module 11
Nest Conditionals (continued)
The same steps used to reduce the first policy are now used to reduce the
second policy.
11–92
Version 2.0
Cisco CRS-1 Essentials
Module 11
Converting Route Maps to RPL Policies
Nest Conditionals (continued)
route-policy policy2
if destination in ps102 then
set community (12:35) additive
if community matches-any cs1 then
set med 11
elseif community matches-any cs2 then
set med 12
elseif community matches-any cs3 then
set med 13
elseif community matches-any cs4 then
set med 14
else
set med 100
endif
endif
end-policy
© 2005 Cisco Systems, Inc.
Perform a similar action on the
second route policy reducing
repetitive conditional statements.
Version 2.0
11–93
Routing Policy Language
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.
11–94
Version 2.0
Cisco CRS-1 Essentials
Module 11
Converting Route Maps to RPL Policies
Use Inline Sets
route-policy policy1
if destination in ps101 then
set community (12:34) additive
if community matches-any (10:11) then
set med 11
elseif community matches-any (10:12) then
set med 12
elseif community matches-any (10:13) then
set med 13
elseif community matches-any (10:14) then
set med 14
else
set med 100
endif
endif
end-policy
© 2005 Cisco Systems, Inc.
Replace small named community sets
with inline sets reducing named set
references during policy evaluation.
Version 2.0
11–95
Routing Policy Language
Module 11
Inline Sets (continued)
Performing the same replacements on the second policy leaves only two
prefix sets and two policies.
11–96
Version 2.0
Cisco CRS-1 Essentials
Module 11
Converting Route Maps to RPL Policies
Inline Sets (continued)
Perform same replacement of named
community sets in the second route
policy. Note that the two route policies
are nearly identical.
route-policy policy2
if destination in ps102 then
set community (12:35) additive
if community matches-any (10:11) then
set med 11
elseif community matches-any (10:12) then
set med 12
elseif community matches-any (10:13) then
set med 13
elseif community matches-any (10:14) then
set med 14
else
set med 100
endif
endif
end-policy
© 2005 Cisco Systems, Inc.
Version 2.0
11–97
Routing Policy Language
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.
11–98
Version 2.0
Cisco CRS-1 Essentials
Module 11
Converting Route Maps to RPL Policies
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
if community matches-any (10:11) then
set med 11
elseif community matches-any (10:12) then
set med 12
elseif community matches-any (10:13) then
set med 13
elseif community matches-any (10:14) then
set med 14
else
set med 100
endif
end-policy
© 2005 Cisco Systems, Inc.
Version 2.0
11–99
Routing Policy Language
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.
11–100
Version 2.0
Cisco CRS-1 Essentials
Module 11
Converting Route Maps to RPL Policies
Parameterize (continued)
Apply the parameterized policy to
replace the similar policy blocks in
both of the route policies.
route-policy policy1
if destination in ps101 then
apply common (34)
pass
endif
end-policy
route-policy policy2
if destination in ps102 then
apply common (35)
pass
endif
end-policy
Question?
Do we need the whole new policy as a final slide in this section for comparison?
© 2005 Cisco Systems, Inc.
Version 2.0
11–101
Routing Policy Language
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.
11–102
Version 2.0
Cisco CRS-1 Essentials
Module 11
RPL-Specific CLI Commands
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
© 2005 Cisco Systems, Inc.
Version 2.0
11–103
Routing Policy Language
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.
11–104
Version 2.0
Cisco CRS-1 Essentials
Module 11
RPL-Specific CLI Commands
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
© 2005 Cisco Systems, Inc.
Version 2.0
11–105
Routing Policy Language
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.
_________________________________________________________________
11–106
Version 2.0
Cisco CRS-1 Essentials
Module 11
RPL-Specific CLI Commands
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
© 2005 Cisco Systems, Inc.
Version 2.0
11–107
Routing Policy Language
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.
11–108
Version 2.0
Cisco CRS-1 Essentials
Module 11
RPL-Specific CLI Commands
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]
© 2005 Cisco Systems, Inc.
Version 2.0
11–109
Routing Policy Language
Module 11
Summary
Routing Policy Language
In this module, you learned:
11–110
•
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
Cisco CRS-1 Essentials
Module 11
Review Questions
Routing Policy Language
1. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
2. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
3. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
4. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
5. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
© 2005 Cisco Systems, Inc.
Version 2.0
11–111
Routing Policy Language
Module 11
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
11–112
Version 2.0
Cisco CRS-1 Essentials
Module 12
Multiprotocol Label Switching (MPLS)
Overview
Description
This module discusses the implementation of MPLS in the Cisco IOS XR
operating system software.
Objectives
After completing this module, you will be able to:
•
Describe MPLS forwarding infrastructure
•
Describe MPLS Label Distribution Protocol implementation
•
Describe MPLS Traffic Engineering dynamic implementation
•
Describe MPLS RSVP implementation for MPLS-TE
© 2005 Cisco Systems, Inc.
Version 2.0c
12–1
Multiprotocol Label Switching (MPLS)
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:
12–2
•
Imposition of labels on packets
•
Disposition of labels in packets
•
Label swapping
Version 2.0c
Cisco CRS-1 Essentials
Module 12
MPLS Forwarding Infrastructure
MPLS Forwarding Infrastructure
• 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
© 2005 Cisco Systems, Inc.
Version 2.0c
12–3
Multiprotocol Label Switching (MPLS)
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).
12–4
Version 2.0c
Cisco CRS-1 Essentials
Module 12
MPLS Forwarding Infrastructure
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
© 2005 Cisco Systems, Inc.
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
12–5
Multiprotocol Label Switching (MPLS)
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.
12–6
Version 2.0c
Cisco CRS-1 Essentials
Module 12
MPLS Forwarding Infrastructure
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
© 2005 Cisco Systems, Inc.
RP
TE
RSVP
LDP
IGP
LSD
RIB
LFD
FIB
MSC or
LC
Version 2.0c
12–7
Multiprotocol Label Switching (MPLS)
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.
12–8
Version 2.0c
Cisco CRS-1 Essentials
Module 12
MPLS Forwarding Infrastructure
MFI Architecture (Cont.)
RP
LSD
LC
LFD
© 2005 Cisco Systems, Inc.
SRP
LFD
LSD
LC
LFD
Version 2.0c
LFD
LC
LFD
12–9
Multiprotocol Label Switching (MPLS)
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.
12–10
•
Local Label—Label assigned by this router
•
Outgoing Label—Label assigned by the next hop or downstream peer,
such as:
−
Unlabeled—No label for the destination from the next hop, or label
switching is not enabled on the outgoing interface
−
Pop Label—Next hop advertised an implicit-null label for the
destination
•
Prefix or Tunnel ID—Address or tunnel to which packets with this
label are going
•
Outgoing interface—Interface through which packets with this label
are sent
•
Next Hop—IP address of neighbor that assigned the outgoing label
•
Bytes Switched—Number of bytes switched with this incoming label
•
TO—Timeout: Indicates by an “*” if entry is being timed out in
forwarding
•
Label switching—Number of label switching (LFIB) forwarding entries
•
IPv4 label imposition—Number of IPv4 label imposition forwarding
entries (installed at ingress LSR)
•
MPLS TE tunnel head—Number of forwarding entries (installed at
ingress LSR) on MPLS TE tunnel head
•
MPLS TE fast-reroute—Number of forwarding entries (installed at
PLR) for MPLS traffic-engineering (TE) fast reroute
•
Forwarding updates—Number of forwarding updates sent from LSD
(RP/DRP) to LFIB/MPLS (RP/DRP/LC)
•
Labels in use—Local 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
Cisco CRS-1 Essentials
Module 12
MPLS Forwarding Infrastructure
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
Unlabelled 142.50.12.0/24
18
Pop Label
142.50.20.0/24
19
Unlabelled 100.10.20.3/32
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
© 2005 Cisco Systems, Inc.
Version 2.0c
12–11
Multiprotocol Label Switching (MPLS)
Module 12
Additional information about the details of MPLS forwarding paths is
available showing:
12–12
•
MAC/Encaps—Length in bytes of Layer 2 header, and length in bytes of
packet encapsulation, including Layer 2 header and label header
•
MTU—Maximum transmission unit (MTU) of labeled packet
•
Label Stack—All the outgoing labels on the forwarded packet
•
Packets Switched—Number of packets switched with this incoming
label
•
Installed—Date and time label was installed in the label table
•
Owner—Application that allocated the label
Version 2.0c
Cisco CRS-1 Essentials
Module 12
MPLS Forwarding Infrastructure
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
Unlabelled 100.10.20.1/32
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
MAC/Encaps: 4/8, MTU: 4470
Label Stack (Top -> Bottom): { Imp-Null }
Packets Switched: 0
Installed: May 3 05:01:09.489 (00:55:07 ago)
Owner: LDP
19
Unlabelled 100.10.20.3/32
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
19
100.10.20.3/32
PO0/3/0/3
142.50.52.2
MAC/Encaps: 4/8, MTU: 4470
Label Stack (Top -> Bottom): { 19 }
Packets Switched: 0
Installed: May 3 05:01:09.489 (00:55:07 ago)
Owner: LDP
© 2005 Cisco Systems, Inc.
Version 2.0c
Bytes
T
Switched
O
----------- 0
0
0
0
12–13
Multiprotocol Label Switching (MPLS)
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.
12–14
Version 2.0c
Cisco CRS-1 Essentials
Module 12
MPLS Forwarding Infrastructure
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> ]
© 2005 Cisco Systems, Inc.
Version 2.0c
12–15
Multiprotocol Label Switching (MPLS)
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.
12–16
Version 2.0c
Cisco CRS-1 Essentials
Module 12
Label Distribution Protocol
Label Distribution Protocol
• 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
© 2005 Cisco Systems, Inc.
Version 2.0c
12–17
Multiprotocol Label Switching (MPLS)
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.
12–18
Version 2.0c
Cisco CRS-1 Essentials
Module 12
Label Distribution Protocol
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”.
© 2005 Cisco Systems, Inc.
Version 2.0c
12–19
Multiprotocol Label Switching (MPLS)
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.
_________________________________________________________________
12–20
Version 2.0c
Cisco CRS-1 Essentials
Module 12
Label Distribution Protocol
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 router’s designated transport address for
the TCP session. The router ID is the default transport address.
© 2005 Cisco Systems, Inc.
Version 2.0c
12–21
Multiprotocol Label Switching (MPLS)
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.
12–22
Version 2.0c
Cisco CRS-1 Essentials
Module 12
Label Distribution Protocol
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
© 2005 Cisco Systems, Inc.
Version 2.0c
12–23
Multiprotocol Label Switching (MPLS)
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.
12–24
Version 2.0c
Cisco CRS-1 Essentials
Module 12
Label Distribution Protocol
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
© 2005 Cisco Systems, Inc.
Version 2.0c
12–25
Multiprotocol Label Switching (MPLS)
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 time—Specifies the maximum time the other peer should
wait for this LSR to reconnect after a control channel failure; the
parameter is reconnect-timeout
•
Recovery time—Specifies 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.
12–26
Version 2.0c
Cisco CRS-1 Essentials
Module 12
Label Distribution Protocol
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.
© 2005 Cisco Systems, Inc.
Version 2.0c
12–27
Multiprotocol Label Switching (MPLS)
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.
12–28
Version 2.0c
Cisco CRS-1 Essentials
Module 12
Label Distribution Protocol
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
© 2005 Cisco Systems, Inc.
Version 2.0c
12–29
Multiprotocol Label Switching (MPLS)
Module 12
Displaying LDP Information
Some show commands provide the necessary general LDP parameter
information, such as:
•
Protocol Version—LDP version on this router
•
Router ID—Current router ID
•
Session:
•
−
Hold time—Time session is to be maintained with the LDP peer
without receiving LDP traffic or keepalive message from the peer
−
Keepalive intervals—Interval between consecutive transmissions of
keepalive messages to a peer
−
Backoff parameters—Initial maximum session backoff time
Discovery:
−
−
•
•
•
12–30
Link Hellos:
−
Holdtime—Amount of time a neighbor wants this router to wait
without receiving a hello message
−
Interval—Time between transmission of consecutive hello
messages to neighbors
Targeted Hellos
−
Holdtime—Amount of time a “not-directly-connected” neighbor
wants this router to wait without receiving a hello message
−
Interval—Time between transmission of consecutive hello
messages to neighbors not directly connected
Graceful restart (GR):
−
Status—Enabled or disabled
−
Reconnect Timeout—Amount of time a neighbor wants this router
to wait after LDP communication failure occurs and while holding
MPLS forwarding state information
−
Forwarding State Holdtime—Time this router is willing to hold
MPLS forwarding state information
Timeouts:
−
Binding with no route—Time to wait before deleting invalid route
−
LDP application recovery (with LSD)—Restart recovery time
OOR state—Normal, Major, or Critical
Version 2.0c
Cisco CRS-1 Essentials
Module 12
Label Distribution Protocol
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
© 2005 Cisco Systems, Inc.
Version 2.0c
12–31
Multiprotocol Label Switching (MPLS)
Module 12
LDP discovery information shows interfaces included in the MPLS LDP
implementation, as well as transport addresses for LDP neighbors.
•
Local LDP Identifier—The LDP identifier for the local router, displayed
as address:number, where address is the router ID and number is the
label namespace
•
Interfaces—Interfaces involved in LDP discovery, where:
−
xmit—Indicates the interface is transmitting discovery hello
packets
−
recv—Indicates the interface is receiving discovery hello packets
•
LDP ID—LDP ID of the peer
•
Transport Address—Address associated with this peer
•
Hold time—State 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.
12–32
•
Peer LDP Identifier—LDP identifier of the neighbor (peer) for this
session
•
Graceful Restart—Graceful-restart status (Y or N)
•
TCP connection—TCP connection used to support the LDP session,
shown in the following format:
−
peer IP address.peer port
−
local IP address.local port
•
State—State of the LDP session. Generally this is Oper (operational),
but transient is another possible state
•
Msgs sent/rcvd—Number 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 time—The length of time that this session has been up for (in
hh:mm:ss format)
•
LDP discovery sources—The source(s) of LDP discovery activity that
led to the establishment of this LDP session
•
Addresses bound to this peer—The 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
Cisco CRS-1 Essentials
Module 12
Label Distribution Protocol
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
© 2005 Cisco Systems, Inc.
Version 2.0c
12–33
Multiprotocol Label Switching (MPLS)
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/n—IP prefix and mask for a particular destination
•
rev—Revision number (rev) that is used internally to manage label
distribution for this destination
•
local binding—Locally assigned label for a given prefix
•
remote bindings—Outgoing 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:
12–34
•
Forwarding State Hold timer—State of the hold timer, running or not
running
•
Forwarding Entries—Number 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 neighbors—Number of graceful restartable neighbors
•
Neighbor ID—Router ID of each neighbor
•
Up—Neighbor up or down
•
Connect count—Number of times the same neighbor has re-connected
•
Liveness timers—State of the liveness timer (running or not running)
and its expiration time, if running
•
Recovery timer—State of the recovery timer (running or not running)
and its expiration time, if running
Version 2.0c
Cisco CRS-1 Essentials
Module 12
Label Distribution Protocol
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
local binding: label:20
remote bindings :
lsr:100.10.20.1:0, label:19
lsr:100.10.20.2:0, label:IMP-NULL (rewrite)
100.10.20.3/32 , rev 16
local binding: label:19
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
local binding: label:17
remote bindings :
lsr:100.10.20.1:0, label:IMP-NULL (rewrite)
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
Unlabelled 100.10.20.1/32
17
Unlabelled 142.50.12.0/24
18
Pop Label
142.50.20.0/24
19
Unlabelled 100.10.20.3/32
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
© 2005 Cisco Systems, Inc.
Up
-Y
Y
Connect Count
------------3
3
Liveness Timer
------------------
Version 2.0c
Recovery Timer
------------------
12–35
Multiprotocol Label Switching (MPLS)
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.
12–36
Version 2.0c
Cisco CRS-1 Essentials
Module 12
MPLS Traffic Engineering
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
© 2005 Cisco Systems, Inc.
Version 2.0c
12–37
Multiprotocol Label Switching (MPLS)
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.
12–38
Version 2.0c
Cisco CRS-1 Essentials
Module 12
MPLS Traffic Engineering
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
© 2005 Cisco Systems, Inc.
Version 2.0c
12–39
Multiprotocol Label Switching (MPLS)
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
12–40
Version 2.0c
Cisco CRS-1 Essentials
Module 12
MPLS Traffic Engineering
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)#
© 2005 Cisco Systems, Inc.
Version 2.0c
12–41
Multiprotocol Label Switching (MPLS)
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.
12–42
Version 2.0c
Cisco CRS-1 Essentials
Module 12
MPLS Traffic Engineering
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
© 2005 Cisco Systems, Inc.
P4
P5
PE5
P2
Version 2.0c
12–43
Multiprotocol Label Switching (MPLS)
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.
12–44
Version 2.0c
Cisco CRS-1 Essentials
Module 12
MPLS Traffic Engineering
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
RP/0/RP0/CPU0:P5(config-if)#
100.10.20.5
P1
PE4
© 2005 Cisco Systems, Inc.
P4
P5
PE5
P2
Version 2.0c
12–45
Multiprotocol Label Switching (MPLS)
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.
12–46
Version 2.0c
Cisco CRS-1 Essentials
Module 12
MPLS Traffic Engineering
Creating a Tunnel Destination
• Tunnels require destinations
− IP address or host name
RP/0/RP0/CPU0:P5(config-if)#destination 100.10.20.4
RP/0/RP0/CPU0:P5(config-if)#
100.10.20.5
P1
PE4
P4
P5
PE5
P2
100.10.20.4
© 2005 Cisco Systems, Inc.
Version 2.0c
12–47
Multiprotocol Label Switching (MPLS)
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 interface’s
global bandwidth pool. This is the maximum bandwidth available to this
tunnel.
12–48
Version 2.0c
Cisco CRS-1 Essentials
Module 12
MPLS Traffic Engineering
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
RP/0/RP0/CPU0:P5(config-if)#
100.10.20.5
P1
To here
P5
PE5
From here
PE4
P4
P2
100.10.20.4
© 2005 Cisco Systems, Inc.
Version 2.0c
12–49
Multiprotocol Label Switching (MPLS)
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.
12–50
Version 2.0c
Cisco CRS-1 Essentials
Module 12
MPLS Traffic Engineering
Setting Priority
• Tunnel priority
− Setup
− Hold
RP/0/RP0/CPU0:P5(config-if)#priority 1 1
RP/0/RP0/CPU0:P5(config-if)#
100.10.20.5
P1
PE4
P4
P5
PE5
P2
100.10.20.4
© 2005 Cisco Systems, Inc.
Version 2.0c
12–51
Multiprotocol Label Switching (MPLS)
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.
12–52
Version 2.0c
Cisco CRS-1 Essentials
Module 12
MPLS Traffic Engineering
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
RP/0/RP0/CPU0:P5(config-if)#
100.10.20.5
P1
P5
PE5
Alternate
PE4
P4
P2
100.10.20.4
© 2005 Cisco Systems, Inc.
Version 2.0c
12–53
Multiprotocol Label Switching (MPLS)
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.
12–54
Version 2.0c
Cisco CRS-1 Essentials
Module 12
MPLS Traffic Engineering
Setting IGP Tunnel Usage
• IGP should use the tunnel in path calculation
RP/0/RP0/CPU0:P5(config-if)#autoroute announce
RP/0/RP0/CPU0:P5(config-if)#
100.10.20.5
P1
P5
PE5
Used in
IGP here
PE4
P4
P2
100.10.20.4
© 2005 Cisco Systems, Inc.
Version 2.0c
12–55
Multiprotocol Label Switching (MPLS)
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.
12–56
Version 2.0c
Cisco CRS-1 Essentials
Module 12
MPLS Traffic Engineering
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
© 2005 Cisco Systems, Inc.
Version 2.0c
12–57
Multiprotocol Label Switching (MPLS)
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.
12–58
Version 2.0c
Cisco CRS-1 Essentials
Module 12
MPLS Traffic Engineering
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
© 2005 Cisco Systems, Inc.
Version 2.0c
12–59
Multiprotocol Label Switching (MPLS)
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:
12–60
•
My_system_id—Local IGP router ID and protocol in use for TE
•
Signaling error holddown—Link hold-down timer configured to handle
path error events before excluding link from topology
•
IGP Id—Advertising router identity
•
MPLS TE Id—Tunnel head end ID
•
Link—MPLS TE link type
•
Frag Id—Gateway protocol link state advertisement fragment ID
•
Nbr Intf Address—Neighbor interface address for this link
•
TE metric—cost of this link
•
Physical BW—Physical line rate
•
Max Reservable BW Global—Maximum amount of bandwidth, in
kilobits per second, that you can reserve in this link global pool
•
Max Reservable BW Sub—Maximum amount of bandwidth, in kilobits
per second, that you can reserve in this link sub-pool
•
Total Allocated BW—Total amount of bandwidth (in kbps) allocated at
this priority
•
Global Pool Reservable BW—Amount of available bandwidth
reservable at this priority
•
Sub Pool Reservable BW—Amount of available bandwidth reservable
at this priority
Version 2.0c
Cisco CRS-1 Essentials
Module 12
Examining MPLS-TE Operation
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)
Additional output omitted
© 2005 Cisco Systems, Inc.
Version 2.0c
12–61
Multiprotocol Label Switching (MPLS)
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:
12–62
•
LSP Tunnels Process—Status of the LSP tunnels process
•
RSVP Process—Status of the RSVP process
•
Forwarding—Status of forwarding (enabled or disabled)
•
Head—Summary information about tunnel heads at this device
•
Tails—Summary information about tunnel tails at this device
•
Periodic reoptimization—Time until the next periodic reoptimization
(in seconds)
•
Periodic FRR Promotion—Time until the next periodic FRR promotion
(in seconds)
•
Periodic auto-bw collection—Time until the next periodic auto-bw
collection (in seconds)
•
Router—Summary information for router tunnels
•
Summary—Summary information for FRR
•
Backup—Number of assigned backup tunnels
•
Interfaces—Number of MPLS TE tunnel interfaces
Version 2.0c
Cisco CRS-1 Essentials
Module 12
Examining MPLS-TE Operation
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)
Additional output omitted
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
Additional output omitted
© 2005 Cisco Systems, Inc.
Version 2.0c
12–63
Multiprotocol Label Switching (MPLS)
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.
12–64
Version 2.0c
Cisco CRS-1 Essentials
Module 12
Examining MPLS-TE Operation
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
© 2005 Cisco Systems, Inc.
Version 2.0c
12–65
Multiprotocol Label Switching (MPLS)
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.
12–66
Version 2.0c
Cisco CRS-1 Essentials
Module 12
Examining MPLS-TE Operation
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
© 2005 Cisco Systems, Inc.
Version 2.0c
12–67
Multiprotocol Label Switching (MPLS)
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.
12–68
Version 2.0c
Cisco CRS-1 Essentials
Module 12
Examining MPLS-TE Operation
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
© 2005 Cisco Systems, Inc.
Version 2.0c
12–69
Multiprotocol Label Switching (MPLS)
Module 12
Summary
Multiprotocol Label Switching (MPLS)
In this module, you learned to:
12–70
•
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
Cisco CRS-1 Essentials
Module 12
Review Questions
Multiprotocol Label Switching (MPLS)
1. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
2. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
3. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
4. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
5. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
© 2005 Cisco Systems, Inc.
Version 2.0c
12–71
Multiprotocol Label Switching (MPLS)
Module 12
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
12–72
Version 2.0c
Cisco CRS-1 Essentials
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
After completing this module, you will be able to:
•
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
© 2005 Cisco Systems, Inc.
Version 1.0b
13–1
Craft Works Interface (CWI)
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.
13–2
Version 1.0b
Cisco CRS-1 Essentials
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)
− Routing Policy Language (RPL)
• Flexible interface options
− Choice of both physical and logical views
− Multiple modes to configure the same component
© 2005 Cisco Systems, Inc.
Version 1.0b
13–3
Craft Works Interface (CWI)
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.
13–4
Version 1.0b
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 1.0b
13–5
Craft Works Interface (CWI)
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.
13–6
Version 1.0b
Cisco CRS-1 Essentials
Module 13
CWI Overview
CWI Launch
HTTP
JARJAR
HTTP is used for:
CWI
clients
© 2005 Cisco Systems, Inc.
• Initial connection
• Loading of the CWI
applet and Jar files
Version 1.0b
CRS-1
13–7
Craft Works Interface (CWI)
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.
13–8
Version 1.0b
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 1.0b
13–9
Craft Works Interface (CWI)
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.
13–10
Version 1.0b
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 1.0b
13–11
Craft Works Interface (CWI)
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 Tree—Displays all Cisco IOS XR router objects in a
physical or logical representation
•
Application pane—Displays 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:
13–12
•
Print—Prints 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.
•
Export—Exports the selected report to a text (comma- or tabseparated) or HTML file.
•
Find—Opens the Find dialog box, allowing you to search the active
window for specific text.
•
Find Next—Finds the next instance of the specific text in the active
window.
•
Cut—Removes the currently selected data or text and moves it to the
Clipboard.
•
Copy—Copies the currently selected data or text and moves it to the
Clipboard.
•
Paste—Pastes the data or text from the Clipboard into the currently
selected field.
•
Refresh—Refreshes the content in the active window in the
Configuration Applications pane.
Version 1.0b
Cisco CRS-1 Essentials
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!
© 2005 Cisco Systems, Inc.
Version 1.0b
13–13
Craft Works Interface (CWI)
Module 13
•
Preferences—Opens the Table Preferences dialog box, allowing you to
select the columns to be displayed in the active application table.
•
Help Contents—Opens the CWI Online Help for the currently active
application.
•
Active Alarms—Opens the Alarm Viewer application and displays all
active alarms on the chosen object in the Application Tree.
•
All Alarms—Opens the Alarm Viewer application and displays all
active, cleared, and non-bistate alarms on the chosen object in the
Application Tree.
•
Inventory Viewer—Opens 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 Connection—Shows 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 Dashboard—When 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 Status—Shows 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.
_________________________________________________________________
13–14
Version 1.0b
Cisco CRS-1 Essentials
Module 13
CWI Overview
Desktop Window (Cont.)
Menu bar
Toolbar
Inventory
Tree
Application
pane
Status bar
© 2005 Cisco Systems, Inc.
Version 1.0b
13–15
Craft Works Interface (CWI)
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:
13–16
•
File—Allows 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.
•
Edit—Allows 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.
•
View—Allows 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.
•
Tools—Allows you to open the CWI applications used to manage the
Cisco IOS XR routers.
•
Window—Allows you to close CWI applications, cascade and minimize
open CWI applications in the application pane, and choose the active
CWI application.
•
Help—Allows you to view the online help and the CWI application
version information.
Version 1.0b
Cisco CRS-1 Essentials
Module 13
CWI Overview
Desktop Menu
© 2005 Cisco Systems, Inc.
Version 1.0b
13–17
Craft Works Interface (CWI)
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.
13–18
Version 1.0b
Cisco CRS-1 Essentials
Module 13
CWI Overview
Inventory Tree
© 2005 Cisco Systems, Inc.
Version 1.0b
13–19
Craft Works Interface (CWI)
Module 13
Tools Menu
The tools menu allows you to invoke a specific desktop application:
13–20
•
Active Alarms and All Alarms—Opens the Alarm Viewer
application, which allows you to dynamically view active or all (active,
cleared, and non-bistate) alarm records.
•
Inventory Viewer—Allows you to retrieve object attribute
information, making it available for viewing or export.
•
Rack View—Displays 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 Viewer—Displays a table-based view of the interface
configuration.
•
Configuration Desktop—Opens the Configuration Desktop. All
configuration applications are opened from the Configuration Desktop
Version 1.0b
Cisco CRS-1 Essentials
Module 13
CWI Overview
Tools Menu
© 2005 Cisco Systems, Inc.
Version 1.0b
13–21
Craft Works Interface (CWI)
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.
13–22
Version 1.0b
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 1.0b
13–23
Craft Works Interface (CWI)
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:
13–24
•
TimeStamp—Is the date and time the alarm was generated on the
router
•
Severity—Is one of six color-coded levels of severity: Emergency (red),
Alert (purple), Critical (orange), Error (yellow), Warning (blue) or
Notification or Informational (green)
•
State—Is the state of the alarm: Cleared, None (non-bistate), or Active
•
Alarm ID—Is a cumulative integer assigned to each alarm as it is
generated
•
Source—Is the source from which the message is emitted in the
format: LR name[rack number, slot number, interface or process ID]
Version 1.0b
Cisco CRS-1 Essentials
Module 13
Desktop Applications
Alarm Viewer
Toolbar
Alarm table
Alarm pane
Instructor's Note
One slide for these two pages of text!!
© 2005 Cisco Systems, Inc.
Version 1.0b
13–25
Craft Works Interface (CWI)
Module 13
•
Category—Is a high-level category, such as communications, QOS,
equipment, or environmental
•
Correlated ID—Is 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 Code—Is the name of the alarm
•
Group—Is the external event group, such as link or logging
•
Additional Text—Is 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:
•
Clear—Clears the selected active alarms.
•
Purge—Removes 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 Records—Opens the Correlation Record Viewer from the
Alarm table correlated alarm ID cell.
•
Filter—Opens 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.
13–26
Version 1.0b
Cisco CRS-1 Essentials
Module 13
Desktop Applications
Alarm Viewer (Cont.)
Toolbar
Alarm table
Alarm pane
© 2005 Cisco Systems, Inc.
Version 1.0b
13–27
Craft Works Interface (CWI)
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:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
13–28
Node ID—Is a drilled-down identification of the object with the
following format: LR.<router name>/Rack.<number>/Slot.<number>
Type—Is the type of object
Description—Is a brief description of the object
Vendor Type—Is the vendor type
Name—Is the name of the object
Hardware Revision—Is the hardware revision of the object
Software Revision—Is the software revision running on the object
Firmware Revision—Is the firmware revision running on the object
Serial Number—Is the serial number of the object
Manufacturer Name—Is the name of the manufacturer
Model Name—Is the model name
Alias—Is the alias of the object
Asset ID—Is the asset ID assigned to the object
FRU—Specifies whether the object is a field-replaceable unit
Version 1.0b
Cisco CRS-1 Essentials
Module 13
Desktop Applications
Inventory Viewer
Inventory table
© 2005 Cisco Systems, Inc.
Version 1.0b
13–29
Craft Works Interface (CWI)
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 View—Is 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 View—Provides 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 toolbar’s
Preferences tool. You can choose to display the front chassis, the back
chassis, or both front and rear chassis.
13–30
Version 1.0b
Cisco CRS-1 Essentials
Module 13
Desktop Applications
Rack View
© 2005 Cisco Systems, Inc.
Version 1.0b
13–31
Craft Works Interface (CWI)
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:
13–32
•
Interface—Is the name of the interface
•
Parent Interface—Is the name of the parent interface (if any)
•
Capsulation ID—Is the data-link encapsulation active on the
interface
•
Interface ID—Is the ID assigned to the interface
•
Line State—Is the state of the line
•
Interface State—Is the state of the interface
•
MTU—Is 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
Cisco CRS-1 Essentials
Module 13
Desktop Applications
Interface Viewer
Interface
table
© 2005 Cisco Systems, Inc.
Version 1.0b
13–33
Craft Works Interface (CWI)
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 Test—Checks the Java DNS resolution from the client
(proper DNS name support for the LR). No automatic repair is
provided.
•
LR and Client Connectivity Test—Checks for proper end-to-end
network connectivity between the LR and client. No automatic repair is
provided.
•
HTTP Server Test—Checks whether the HTTP server is running. An
automatic repair is provided in some instances of this test failure.
•
CORBA Services and XML Agent Test—Checks 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.
•
13–34
Notification Test—Checks whether the notification service is active
on the router. An automatic repair is provided in some instances of this
test failure.
Version 1.0b
Cisco CRS-1 Essentials
Module 13
Desktop Applications
Troubleshooter
© 2005 Cisco Systems, Inc.
Version 1.0b
13–35
Craft Works Interface (CWI)
Module 13
Router Configuration
Craft Works Interface (CWI) supports three modes of configuration:
13–36
•
Terminal, Telnet and SSH CLI sessions
•
Configuration Editor and Replace Configuration Editor
•
Graphical configuration
Version 1.0b
Cisco CRS-1 Essentials
Module 13
Router Configuration
Modes
CLI sessions
• Telnet
• Terminal
• SSH Plus
Editors
• Configuration Editor
• Replace Configuration Editor
Graphical configuration
© 2005 Cisco Systems, Inc.
Version 1.0b
13–37
Craft Works Interface (CWI)
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:
Terminal—Provides 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 Plus—Provides 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 Plus—Provides 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.
13–38
Version 1.0b
Cisco CRS-1 Essentials
Module 13
Router Configuration
Telnet Plus and SSH Plus
Toolbar
Command
list
Instructor's Note
One slide for 2 test pages!!
© 2005 Cisco Systems, Inc.
Version 1.0b
13–39
Craft Works Interface (CWI)
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:
13–40
•
Disconnect—Disconnects 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 Commands—Supports batch mode execution of
CLI commands and logging of the batch operation.
•
Load Last Command List—Loads a saved list of commands.
•
Save Last Command List—Saves a list of commands for later use.
•
Clear Last Command List—Clears the command list.
•
Copy Last Command—Copies the last executed command to the
Clipboard; all commands are not automatically copied to the clipboard.
•
Command List—Displays 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
Cisco CRS-1 Essentials
Module 13
Router Configuration
Telnet and SSH Plus (Cont.)
Toolbar
© 2005 Cisco Systems, Inc.
Command
list
Version 1.0b
13–41
Craft Works Interface (CWI)
Module 13
Configuration Editor
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:
13–42
•
CLI Help—By pressing ?, displays a popup list of valid commands and,
by choosing a command from the list, inserts it into the text
•
Command Completion—By pressing <Tab> after entering one or
more characters, causes a complete command to appear in text
•
Cut, Copy and Paste—Operates within Configuration Editor and
from external applications like Notepad
•
Syntax Checking—Allows a selected block of text or the entire
contents of Configuration Editor to be checked for syntax errors
•
Change Tracking—Highlights text in color whenever a command is
deleted (red), modified (blue), not modified (white), or added (green)
Version 1.0b
Cisco CRS-1 Essentials
Module 13
Router Configuration
Configuration Editor
Changed
commands
Added
commands
Deleted
commands
© 2005 Cisco Systems, Inc.
Version 1.0b
13–43
Craft Works Interface (CWI)
Module 13
Replace Configuration Editor
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.
13–44
Version 1.0b
Cisco CRS-1 Essentials
Module 13
Router Configuration
Replace Configuration Editor
© 2005 Cisco Systems, Inc.
Version 1.0b
13–45
Craft Works Interface (CWI)
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:
•
Administration—AAA, Alarm, and User
•
Applications— IEP (IP Explicit Path) and MPLS-TE (Multi-Protocol
Label Switching traffic engineering)
•
Interfaces—Common, Ethernet, and POS (packet-over-SONET)
•
Controllers—SONET
•
Policy—Access Control Lists, Packet Filter, QOS, and Routing Policy
•
Protocols—BGP, ISIS, LDP, OSPF, and RSVP
The Configuration Desktop window has three primary panes:
•
Configuration Applications Tree—Displays all configuration
applications available in the Configuration Desktop.
•
Configuration Applications—Contains the active configuration
applications used to configure the router. Multiple applications can be
opened concurrently in the Configuration Applications pane.
•
Launch Context—Displays 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:
13–46
•
Lock/Unlock
•
Load
•
Save
•
View Uncommitted Configuration
•
Commit
•
Clear
•
Rollback
Version 1.0b
Cisco CRS-1 Essentials
Module 13
Graphical Configuration Applications
Configuration Desktop
Toolbar
Configuration
Applications
Tree
Configuration
Applications
Launch
Context
© 2005 Cisco Systems, Inc.
Version 1.0b
13–47
Craft Works Interface (CWI)
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:
13–48
•
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
Cisco CRS-1 Essentials
Module 13
Graphical Configuration Applications
Graphical Configuration Features
© 2005 Cisco Systems, Inc.
Version 1.0b
13–49
Craft Works Interface (CWI)
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.
13–50
Version 1.0b
Cisco CRS-1 Essentials
Module 13
Graphical Configuration Applications
Configuration Applications Tree and Launch Context
Configuration
Applications
Tree
Launch
Context
© 2005 Cisco Systems, Inc.
Version 1.0b
13–51
Craft Works Interface (CWI)
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:
13–52
•
Lock/Unlock—Locks 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.
•
Load—Opens 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.
•
Save—Opens the Save Uncommitted Configuration dialog box, which
allows you to save an uncommitted configuration to a specified location
on the router.
•
View Uncommitted Configuration—Displays the uncommitted
configuration.
•
Commit—Commits 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.
•
Clear—Stops the current configuration session. The target
configuration is deleted and all active configuration applications are
closed.
•
Rollback—Opens 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
Cisco CRS-1 Essentials
Module 13
Graphical Configuration Applications
Configuration Control Toolbar
Lock/Unlock
View
uncommited
configuration
Load Save
© 2005 Cisco Systems, Inc.
Version 1.0b
Commit
Clear
Rollback
13–53
Craft Works Interface (CWI)
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 columns—Columns in an application table are sorted in
ascending or descending order.
•
Moving columns—CWI 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 records—To 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 text—As 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 data—Inventory 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.
13–54
Version 1.0b
Cisco CRS-1 Essentials
Module 13
Graphical Configuration Applications
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
Find
Cut
Paste
Preferences
Common
application
tools
Export
© 2005 Cisco Systems, Inc.
Version 1.0b
Find next
Copy
Refresh
Help
13–55
Craft Works Interface (CWI)
Module 13
Administration Configuration
The Administration Configuration applications are used to manage user
access, permissions, and alarms. The applications are:
13–56
•
AAA—Allows you to configure and set up system security. All triple “A”
functions can be set up from the AAA application.
•
Alarm Administration—Allows 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 Administration—Allows 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
Cisco CRS-1 Essentials
Module 13
Graphical Configuration Applications
Administration Configuration
© 2005 Cisco Systems, Inc.
Version 1.0b
13–57
Craft Works Interface (CWI)
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:
13–58
•
IEP—Allows 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-TE—Allows 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
Cisco CRS-1 Essentials
Module 13
Graphical Configuration Applications
Applications Configuration
© 2005 Cisco Systems, Inc.
Version 1.0b
13–59
Craft Works Interface (CWI)
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:
13–60
•
Common Attributes—Allows 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.
•
Ethernet—Allows 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.
•
POS—Allows 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
Cisco CRS-1 Essentials
Module 13
Graphical Configuration Applications
Interface Configuration
© 2005 Cisco Systems, Inc.
Version 1.0b
13–61
Craft Works Interface (CWI)
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 Filter—Is 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.
•
QoS—Defines 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 Manager—Allows 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.
______________________________________________________________
13–62
Version 1.0b
Cisco CRS-1 Essentials
Module 13
Graphical Configuration Applications
Policy Configuration
© 2005 Cisco Systems, Inc.
Version 1.0b
13–63
Craft Works Interface (CWI)
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:
13–64
•
BGP— Border Gateway Protocol (BGP) neighbor, session, and address
family (topology) parameters
•
ISIS—Intermediate System-to-Intermediate System (IS-IS) routing
protocol on process, address family (topology), and interface levels
•
LDP—Label Distribution Protocol (LDP) globally and enable or disable
LDP for each interface or neighbor.
•
OSPF—Open Shortest Path First (OSPF) processes, areas, and
interfaces.
•
RSVP—Resource Reservation Protocol (RSVP) configurations for
available interfaces.
Version 1.0b
Cisco CRS-1 Essentials
Module 13
Graphical Configuration Applications
Protocol Configuration
© 2005 Cisco Systems, Inc.
Version 1.0b
13–65
Craft Works Interface (CWI)
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”.
13–66
Version 1.0b
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Inbound
Inbound
Outbound
Inbound
Version 1.0b
13–67
Craft Works Interface (CWI)
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 router’s 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.
13–68
Version 1.0b
Cisco CRS-1 Essentials
Module 13
Getting Started
Launching CWI
http://<router-dns-name>
or
http://<router-ip-address>
© 2005 Cisco Systems, Inc.
Version 1.0b
13–69
Craft Works Interface (CWI)
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.
13–70
Version 1.0b
Cisco CRS-1 Essentials
Module 13
Getting Started
Loading CWI Components
© 2005 Cisco Systems, Inc.
Version 1.0b
13–71
Craft Works Interface (CWI)
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.
13–72
Version 1.0b
Cisco CRS-1 Essentials
Module 13
Getting Started
Checking the Java Runtime Environment
© 2005 Cisco Systems, Inc.
Version 1.0b
13–73
Craft Works Interface (CWI)
Module 13
Testing Communication
If a problem is encountered during login, you can troubleshoot the problem
using the CWI Troubleshooter.
13–74
Version 1.0b
Cisco CRS-1 Essentials
Module 13
Getting Started
Testing Communications
© 2005 Cisco Systems, Inc.
Version 1.0b
13–75
Craft Works Interface (CWI)
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:
13–76
•
CLI / Serial, Terminal Server
•
CLI / Telnet, SSHv1, SSHv2
•
XML / Telnet, SSHv1, SSHv2, CORBA, CORBA SSL
Version 1.0b
Cisco CRS-1 Essentials
Module 13
Getting Started
Logging In
© 2005 Cisco Systems, Inc.
Version 1.0b
13–77
Craft Works Interface (CWI)
Module 13
Summary
Craft Works Interface
In this module, you learned to:
13–78
•
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
Cisco CRS-1 Essentials
Module 13
Review Questions
Craft Works Interface
1. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
2. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
3. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
4. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
5. <Insert Question>
a. <Insert Answer a>
b. <Insert Answer b>
© 2005 Cisco Systems, Inc.
Version 1.0b
13–79
Craft Works Interface (CWI)
Module 13
c. <Insert Answer c>
d. <Insert Answer d>
e. <Insert Answer e>
13–80
Version 1.0b
Cisco CRS-1 Essentials
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
After completing this module, you will be able to do the following:
•
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
© 2005 Cisco Systems, Inc.
Version 2.0b
14–1
Data Flow and MQC QoS
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.
14–2
Version 2.0b
Cisco CRS-1 Essentials
Module 14
CRS-1 QoS Hardware Components
CRS-1 QoS Hardware Components
EgressQ
2*FabricQ
SP & FIA
Ingress
PSE
© 2005 Cisco Systems, Inc.
Version 2.0b
Power
Regulators
Egress
PSE
Line Card
CPU
IngressQ
14–3
Data Flow and MQC QoS
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 type’s 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.
14–4
Version 2.0b
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0b
14–5
Data Flow and MQC QoS
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
14–6
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Life of a Packet
Life of a Packet – Step 2
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
2
OC192
Framer
& Optics
PLA
OC192
Framer
& Optics
Fabric
OC192
Framer
& Optics
From
Egress Packet Flow Fabric
© 2005 Cisco Systems, Inc.
Version 2.0b
14–7
Data Flow and MQC QoS
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.
14–8
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Life of a Packet
Life of a Packet – Step 3
To Fabric
Ingress Packet Flow
Fabric
IngressQ
In Q/
Segmenter
RX PSE
L3 Engine
CPUCTRL
GW
From
PLIM
3
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
2
OC192
Framer
& Optics
PLA
OC192
Framer
& Optics
Fabric
OC192
Framer
& Optics
From
Egress Packet Flow Fabric
To Fabric
Ingress Packet Flow
IngressQ
In Q/
Segmenter
CPUCTRL
GW
Fabric
3a
RX PSE
L3 Engine
From
PLIM
3
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
2
OC192
Framer
& Optics
PLA
OC192
Framer
& Optics
Fabric
OC192
Framer
& Optics
From
Egress Packet Flow Fabric
© 2005 Cisco Systems, Inc.
Version 2.0b
14–9
Data Flow and MQC QoS
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.
14–10
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Life of a Packet
Life of a Packet – Step 4
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
4
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
3
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
1
2
OC192
Framer
& Optics
PLA
OC192
Framer
& Optics
Fabric
OC192
Framer
& Optics
From
Egress Packet Flow Fabric
© 2005 Cisco Systems, Inc.
Version 2.0b
14–11
Data Flow and MQC QoS
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.
14–12
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Life of a Packet
Life of a Packet – Step 5
4a
4
Fabric
Cells
IngressQ
In Q/
Segmenter
To Fabric
Ingress Packet Flow
Fabric
Cells
5
Fabric
3a
CPUCTRL
GW
RX PSE
L3 Engine
From
PLIM
3
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
2
OC192
Framer
& Optics
PLA
OC192
Framer
& Optics
Fabric
OC192
Framer
& Optics
From
Egress Packet Flow Fabric
© 2005 Cisco Systems, Inc.
Version 2.0b
14–13
Data Flow and MQC QoS
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.
14–14
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Life of a Packet
Life of a Packet – Step 5a
136 Bytes cells
8
MSC
2 Levels of priority
HP Low latency path
LP Best effort traffic
8 of 8
2
2 of 8
1
S1
1 of 8
S1
S1
S2
S2
S2
S1
16
MSC
2
S1
S1
S3
S3
S3
S2
S2
S2
S3
S3
S3
Multicast support
1M multicast
groups
1
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
© 2005 Cisco Systems, Inc.
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
14–15
Data Flow and MQC QoS
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.
14–16
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Life of a Packet
Life of a Packet – Step 6
4a
4
Fabric
Cells
IngressQ
In Q/
Segmenter
To Fabric
Ingress Packet Flow
Fabric
Cells
5
Fabric
3a
CPUCTRL
GW
RX PSE
L3 Engine
From
PLIM
3
CPU
To
PLIM
FabricQ
FabricQ
Reass.
Reass.
TX PSE
L3 Engine
EgressQ
Out Q
M
I
D
P
L
A
N
E
6
From
Fabric
© 2005 Cisco Systems, Inc.
1
2
OC192
Framer
& Optics
PLA
OC192
Framer
& Optics
Fabric
Fabric
Cells
OC192
Framer
& Optics
OC192
Framer
& Optics
Egress Packet Flow
Version 2.0b
14–17
Data Flow and MQC QoS
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.
14–18
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Life of a Packet
Life of a Packet – Step 7
4a
4
Fabric
Cells
IngressQ
In Q/
Segmenter
To Fabric
Ingress Packet Flow
Fabric
Cells
5
Fabric
3a
CPUCTRL
GW
RX PSE
L3 Engine
CPU
From
PLIM
3
To
PLIM
7
FabricQ
FabricQ
Reass.
Reass.
TX PSE
L3 Engine
EgressQ
Out Q
M
I
D
P
L
A
N
E
6
From
Fabric
© 2005 Cisco Systems, Inc.
1
2
OC192
Framer
& Optics
PLA
OC192
Framer
& Optics
Fabric
Fabric
Cells
OC192
Framer
& Optics
OC192
Framer
& Optics
Egress Packet Flow
Version 2.0b
14–19
Data Flow and MQC QoS
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.
14–20
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Life of a Packet
Life of a Packet – Step 8
Fabric
Cells
4a
IngressQ
In Q/
Segmenter
4
To Fabric
Fabric
Cells
5
Ingress Packet Flow
Fabric
3a
RX PSE
L3 Engine
CPUCTRL
GW
From
PLIM
3
CPU
To
PLIM
8
7
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
1
2
Fabric
6
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.
© 2005 Cisco Systems, Inc.
Version 2.0b
14–21
Data Flow and MQC QoS
Module 14
Once the packet has been queued and shaped it is then passed to the
PLA ASIC on the PLIM.
14–22
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Life of a Packet
Life of a Packet – Step 9
4a
4
Fabric
Cells
IngressQ
In Q/
Segmenter
To Fabric
Ingress Packet Flow
Fabric
Cells
5
Fabric
3a
CPUCTRL
GW
RX PSE
L3 Engine
From
PLIM
3
CPU
To
PLIM
8
7
FabricQ
FabricQ
Reass.
Reass.
TX PSE
L3 Engine
EgressQ
Out Q
M
I
D
P
L
A
N
E
6
From
Fabric
© 2005 Cisco Systems, Inc.
1
2
OC192
Framer
& Optics
PLA
OC192
Framer
& Optics
9
Fabric
Fabric
Cells
OC192
Framer
& Optics
OC192
Framer
& Optics
Egress Packet Flow
Version 2.0b
14–23
Data Flow and MQC QoS
Module 14
10. Finally the packet is sent through the egress port, and onto the
physical link.
14–24
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Life of a Packet
Life of a Packet – Step 10
4a
4
Fabric
Cells
IngressQ
In Q/
Segmenter
To Fabric
Ingress Packet Flow
Fabric
Cells
5
Fabric
3a
CPUCTRL
GW
RX PSE
L3 Engine
From
PLIM
3
CPU
To
PLIM
8
7
FabricQ
FabricQ
Reass.
Reass.
TX PSE
L3 Engine
EgressQ
Out Q
M
I
D
P
L
A
N
E
6
From
Fabric
© 2005 Cisco Systems, Inc.
1
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
14–25
Data Flow and MQC QoS
Module 14
IngressQ queuing and shaping
Features
14–26
•
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
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
P2
To
fabric
P1023
Max BW
Version 2.0b
MDRR/
Aggregate
Shaper
Configurable
Dynamic
Mapping of
Queues to ports
14–27
Data Flow and MQC QoS
Module 14
EgressQ queuing and shaping
Features
•
Packets are passed into the EgressQ from the TX PSE
−
•
•
14–28
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
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Shaping
Min/max BW
G2
MDRR/
Aggregate
Group
To
PLIM
GX
MDRR/ PX
Group
Max BW
Version 2.0b
14–29
Data Flow and MQC QoS
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 cell’s 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.
14–30
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Switch Fabric Cell Structure
Header
FEC
Switch Fabric Cell Structure
Cell Payload (120 bytes)
Two Packet Payload
Packet 1
Header (12 bytes)
Fields (Data Cells)
Bits
Cast (Mcast/Ucast)
1
Fabric Priority
1
Vital
1
Source Address
10
Packet 1 Sequence Number
13
Packet 2 Payload Offset/FGID
2
Trailing Offest
2
Packet Cell Count
7
Packet 1 Cell Sequence Number
7
Destination Address (12 bits)/FGID
18
Snoop/CTB
1
Internal Fabric control bits
32
© 2005 Cisco Systems, Inc.
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
14–31
Data Flow and MQC QoS
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.
14–32
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Switch Fabric Cell Structure
Header
FEC
Switch Fabric Cell Structure (Cont.)
Cell Payload (120 bytes)
Two Packet Payload
Packet 1
Header (12 bytes)
Fields (Data Cells)
Bits
Cast (Mcast/Ucast)
1
Fabric Priority
1
Vital
1
Source Address
10
Packet 1 Sequence Number
13
Packet 2 Payload Offset/FGID
2
Trailing Offest
2
Packet Cell Count
7
Packet 1 Cell Sequence Number
7
Destination Address (12 bits)/FGID
18
Snoop/CTB
1
Internal Fabric control bits
32
© 2005 Cisco Systems, Inc.
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
14–33
Data Flow and MQC QoS
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.
14–34
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Worst Case Fabric Cell Loading
Header
FEC
Worst Case Fabric Cell Loading – Example
Cell Payload (120 bytes)
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 doesn’t 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
Single Packet Payload
Pkt 5 (150 bytes)
© 2005 Cisco Systems, Inc.
Version 2.0b
14–35
Data Flow and MQC QoS
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.
14–36
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Switch Fabric Architecture
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
© 2005 Cisco Systems, Inc.
Version 2.0b
14–37
Data Flow and MQC QoS
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.
_________________________________________________________________
14–38
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Switch Fabric Architecture
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
© 2005 Cisco Systems, Inc.
Version 2.0b
14–39
Data Flow and MQC QoS
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.
14–40
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Switch Fabric Features
Switch Fabric Features
40 Gbps
8 of 8
8
MSC
2 X Speedup
@ S3
136 Bytes cells
2
2 of 8
1
16
S1
S2
MSC
1
1 of 8
S1
S1
S2
S2
S1
S1
S3
S3
S2
S1
2 Levels of priority
HP Low latency path
LP Best effort traffic
2
S3
S2
S2
S3
S3
S3
Multicast support
1M multicast
groups
1296 x 1296 buffered non-blocking switch
Multi-stage Interconnect – 3 Stage Benes
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
© 2005 Cisco Systems, Inc.
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
14–41
Data Flow and MQC QoS
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
14–42
•
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
Cisco CRS-1 Essentials
Module 14
Switch Fabric Features
Switch Fabric Features (Cont.)
40 Gbps
8 of 8
8
MSC
2 X Speedup
@ S3
136 Bytes cells
2
1
2 of 8
16
S1
S2
S1
S1
S1
S1
MSC
1
1 of 8
S2
S2
S1
2 Levels of priority
HP Low latency path
LP Best effort traffic
2
S3
S3
S3
S2
S2
S2
S3
S3
S3
Multicast support
1M multicast
groups
1296 x 1296 buffered non-blocking switch
Multi-stage Interconnect – 3 Stage Benes
topology
© 2005 Cisco Systems, Inc.
Version 2.0b
14–43
Data Flow and MQC QoS
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.
14–44
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Modular QoS Command-Line Interface
Modular QoS Command Line Interface (MQC)
MQC is used to:
• Create traffic policies
• Attach policies to interfaces
• Provide a platform independent Command Line
Syntax
© 2005 Cisco Systems, Inc.
Version 2.0b
14–45
Data Flow and MQC QoS
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.
14–46
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Modular QoS Command-Line Interface
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)
© 2005 Cisco Systems, Inc.
Version 2.0b
14–47
Data Flow and MQC QoS
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.
14–48
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Modular QoS Command-Line Interface
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
© 2005 Cisco Systems, Inc.
Version 2.0b
14–49
Data Flow and MQC QoS
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:
14–50
•
access-group
•
any
•
discard-class
•
dscp
•
mpls
•
precedence
•
protocol
•
qos-group
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Modular QoS Command-Line Interface
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)#
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
© 2005 Cisco Systems, Inc.
Version 2.0b
14–51
Data Flow and MQC QoS
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.
14–52
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Modular QoS Command-Line Interface
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
© 2005 Cisco Systems, Inc.
Version 2.0b
14–53
Data Flow and MQC QoS
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:
14–54
•
bandwidth
•
commit
•
describe
•
do
•
exit
•
no
•
police
•
priority
•
queue-limit
•
random-detect
•
service-policy
•
set
•
shape
•
show
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Modular QoS Command-Line Interface
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)#
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)#
© 2005 Cisco Systems, Inc.
Version 2.0b
14–55
Data Flow and MQC QoS
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.
14–56
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Modular QoS Command-Line Interface
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
Building configuration...
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
!
interface POS0/4/0/2
service-policy output traffic-class
RP/0/RP1/CPU0:P1(config)#
© 2005 Cisco Systems, Inc.
Version 2.0b
14–57
Data Flow and MQC QoS
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.
14–58
Version 2.0b
Cisco CRS-1 Essentials
Module 14
Modular QoS Command-Line Interface
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
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 default
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)
RP/0/RP1/CPU0:P1#
© 2005 Cisco Systems, Inc.
(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
14–59
Data Flow and MQC QoS
Module 14
Summary
Data Flow and MQC QoS
In this module, you learned the following:
14–60
•
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
Cisco CRS-1 Essentials
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
After completing this module, you will be able to:
•
Troubleshoot card-level errors
•
Check for memory problems and leaks
•
Look for process-level errors
•
Troubleshoot ASIC-level problems
© 2005 Cisco Systems, Inc.
Version 2.0
A–1
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.
A–2
Version 2.0
Cisco CRS-1 Essentials
Appendix A
Operational-Level Checks
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)
© 2005 Cisco Systems, Inc.
Version 2.0
A–3
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.
A–4
Version 2.0
Cisco CRS-1 Essentials
Appendix A
Operational-Level Checks
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
© 2005 Cisco Systems, Inc.
Version 2.0
A–5
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.
A–6
Version 2.0
Cisco CRS-1 Essentials
Appendix A
Operational-Level Checks
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
© 2005 Cisco Systems, Inc.
Version 2.0
A–7
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.
A–8
Version 2.0
Cisco CRS-1 Essentials
Appendix A
Troubleshooting CPU Overload
Troubleshooting CPU Overload
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
© 2005 Cisco Systems, Inc.
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
A–9
Troubleshooting
Appendix A
Troubleshooting Memory Issues
Modular Services Card
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.
A–10
Version 2.0
Cisco CRS-1 Essentials
Appendix A
Troubleshooting Memory Issues
Modular Services Card
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
© 2005 Cisco Systems, Inc.
Version 2.0
A–11
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.
A–12
Version 2.0
Cisco CRS-1 Essentials
Appendix A
Troubleshooting Memory Issues
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
© 2005 Cisco Systems, Inc.
Version 2.0
Top two memory
consumingprocesses
Process
tcam_mgr
dllmgr
eth_server
gsp
pkgfs
netio
sysdb_svr_local
fqm
wdsysmon
mpls_lfd
A–13
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
A–14
Version 2.0
Cisco CRS-1 Essentials
Appendix A
Troubleshooting the Data Path
Troubleshooting the Data Path
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)
© 2005 Cisco Systems, Inc.
pse
(METRO) 0
Version 2.0
A–15
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.
A–16
Version 2.0
Cisco CRS-1 Essentials
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>
© 2005 Cisco Systems, Inc.
Version 2.0
A–17
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).
A–18
Version 2.0
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0
A–19
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.
A–20
Version 2.0
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0
A–21
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.
A–22
Version 2.0
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0
A–23
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.
A–24
Version 2.0
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0
A–25
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.
A–26
Version 2.0
Cisco CRS-1 Essentials
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 NoBufferLimit = 0
Rx Pkt errors = 0
Rx NoBuffers = 0
Rx NoBufferLimit = 0
Rx Pkt errors = 0
Rx NoBuffers = 0
Rx NoBufferLimit = 0
Rx Pkt errors = 0
Rx NoBuffers = 0
Rx NoBufferLimit = 0
Rx Pkt errors = 0
Rx NoBuffers = 0
Rx NoBufferLimit = 0
Rx Pkt errors = 0
Rx NoBuffers = 0
Rx NoBufferLimit = 0
© 2005 Cisco Systems, Inc.
Version 2.0
A–27
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 equal—and it most likely never will—to the
number of packets sent because a cell does not always map directly to a
packet received.
A–28
Version 2.0
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0
A–29
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.
A–30
Version 2.0
Cisco CRS-1 Essentials
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
© 2005 Cisco Systems, Inc.
Version 2.0
A–31
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.
A–32
Version 2.0
Cisco CRS-1 Essentials
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 )
© 2005 Cisco Systems, Inc.
Version 2.0
A–33
Troubleshooting
Appendix A
The packet counters are divided by ASIC level, with the second ASIC
information continuing after fabricq ASIC 0.
A–34
Version 2.0
Cisco CRS-1 Essentials
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)
© 2005 Cisco Systems, Inc.
Version 2.0
A–35
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.
A–36
Version 2.0
Cisco CRS-1 Essentials
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
plimasic link1 output packets: 3569577894
plimasic link1 output bytes: 2196621864536
plimasic link2 output packets: 0
Packets received
plimasic link2 output bytes: 0
from the cpuctrl
plimasic link3 output packets: 0
ASIC
plimasic link3 output bytes: 0
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
© 2005 Cisco Systems, Inc.
Version 2.0
A–37
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.
A–38
Version 2.0
Cisco CRS-1 Essentials
Appendix A
Troubleshooting Switch Fabric Cards
SFC Troubleshooting Overview
S1
S1
S1
S1
S1
S1
S1
S1
S1
S1
S1
S1
S1
S1
S1
S3
Sprayer
Port
S1
LINE CARD
© 2005 Cisco Systems, Inc.
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
A–39
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.
A–40
Version 2.0
Cisco CRS-1 Essentials
Appendix A
Troubleshooting Switch Fabric Cards
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
© 2005 Cisco Systems, Inc.
Version 2.0
A–41
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.
A–42
Version 2.0
Cisco CRS-1 Essentials
Appendix A
Troubleshooting Switch Fabric Cards
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
© 2005 Cisco Systems, Inc.
Version 2.0
A–43
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.
A–44
Version 2.0
Cisco CRS-1 Essentials
Appendix A
Troubleshooting Switch Fabric Cards
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
© 2005 Cisco Systems, Inc.
Version 2.0
A–45
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.
A–46
Version 2.0
Cisco CRS-1 Essentials
Appendix A
Troubleshooting Switch Fabric Cards
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
© 2005 Cisco Systems, Inc.
Total uptime and
percentage of uptime
since an error was
indicated
Version 2.0
A–47
Troubleshooting
Appendix A
Summary
Troubleshooting
In this module, you learned to:
A–48
•
Troubleshoot card-level errors
•
Check for memory problems and leaks
•
Look for process-level errors
•
Troubleshoot ASIC-level problems
Version 2.0
Cisco CRS-1 Essentials
Appendix B
Student Evaluation
© 2005 Cisco Systems, Inc.
Version 2.0
B–1
Part Number: XX#######-XX-X
