cisco crs

CRSE

Cisco CRS-1 Essentials Version 2.0b

Instructor Guide

Text Part Number: xx-xxxx-xx

Copyright © 2005, Cisco Systems, Inc. All rights reserved.

Cisco Systems has more than 200 offices in the following countries and regions. Addresses, phone numbers, and fax numbers are listed on the Cisco Web site at www.cisco.com/go/offices.

Argentina • Australia • Austria • Belgium • Brazil • Bulgaria • Canada • Chile • China PRC • Colombia • Costa Rica Croatia • Czech Republic • Denmark • Dubai, UAE • Finland • France • Germany • Greece • Hong Kong SAR • Hungary

India • Indonesia • Ireland • Israel • Italy • Japan • Korea • Luxembourg • Malaysia • Mexico • The Netherlands New Zealand • Norway • Peru • Philippines • Poland • Portugal • Puerto Rico • Romania • Russia • Saudi Arabia

Scotland • Singapore • Slovakia • Slovenia • South Africa • Spain • Sweden • Switzerland • Taiwan • Thailand • Turkey Ukraine • United Kingdom • United States • Venezuela • Vietnam • Zimbabwe

Copyright © 2005, Cisco Systems, Inc. All rights reserved. CCIP, the Cisco Powered Network mark, the Cisco Systems Verified logo, Cisco Unity, Follow Me Browsing, FormShare, Internet Quotient, iQ

Breakthrough, iQ Expertise, iQ FastTrack, the iQ logo, iQ Net Readiness Scorecard, Networking Academy, ScriptShare, SMARTnet, TransPath, and Voice LAN are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, Discover All 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

http://www.adobe.com/

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

• 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

x 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 (SC-GE) 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• 40 Gbps routing• Multishelf scale• Foundation for core

consolidation

CRS-1

© 2005 Cisco Systems, Inc. Version 2.0b 1–3


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.


Module 1 Market Place Demands

IP PoP Evolution - Scaling

• 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

SharedFDDI Ring

FDDISwitchX X

POS

EthernetATM

POSPOS

POS

GSRGSR

Cisco 75XX

Cisco 75XX

Cisco 75XX

Cisco 75XX

Cisco 75XXDPT

?

Late 1990 Early 1992 Mid 1995 1998-99 2000-02 2004-future



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.


Module 1 Current PoP Design

Current PoP Design – Interconnect

OC-12/48->OC-192

Core

Peering

DS-3, 1GEOC-3/12/48

1GE->10GE

1GE/OC-3/12/48DPTDistribution

T1/1GEOC-3/12

OC-3/12/48DPT

Aggregation



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.


Module 1 Getting the CRS-1 into the Network

Core Layer Insertion

OC-12/48->OC-192

Core

Peering

DS-3, 1GEOC-3/12/48

1GE->10GE

1GE/OC-3/12/48DPTDistribution

T1/1GEOC-3/12

OC-3/12/48DPT

Aggregation

CRS-1 CRS-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.


Module 1 Getting the CRS-1 into the Network

Core Layer Consolidation

STM-64/256

CRS-15 Logical Routerpartitions

GSR120/124xxCAT6K

1GE/10GESTM-4/16

STM-4/16 DPT1G/10GE

10GE/STM-16/64DPTSTM-256 Ch DS-3

Core

Distribution

Aggregation



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


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



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.


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



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 16-slot 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 16-slot 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.


mkumarjo

Highlight

Module 1 Cisco CRS-1 Line Card Chassis

Cisco CRS-1 Line Card Chassis

CRS-1 8-slot

CRS-1 16-slot



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

• 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


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



Summary

Cisco IOS XR Hardware and Platform Overview In this module, you learned the following:

• 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


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.


• List and describe the hardware features and functions of the CRS-1 16-slot 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


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:

• 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

2–2 Version 2.0b Cisco CRS-1 Router Essentials

mkumarjo

Highlight

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/723kgHeat Dis.: 41000 BTUs



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.


Module 2 CRS-1 16-Slot Line Card Chassis Components

Components – PLIM Side

1

2

3

4

5



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


mkumarjo

Highlight

mkumarjo

Highlight


MSC Side

1

2

3

4

56



Cable-Management The CRS-1 16-slot line card chassis contains two horizontal cable-management brackets that provide cable management capabilities for the MSCs and PLIMs installed in your line card chassis. The cable-management brackets are pre-installed on the front (PLIM) side of the line card chassis directly above the upper and lower PLIM bays. 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 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.



Cable Management


Cable-management



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).


Module 2 CRS-1 16-Slot Line Card Chassis Slot Numbering




CRS-1 16-Slot Line Card Chassis Power System

Overview The line card chassis can be powered by either AC (Wye 3-phase 200-240/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:

• 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


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 DC-to-DC converters, or OR’ingdiodes or EMI filters



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.



Power Architecture

Power system architecture provides fully redundant AC or DC powerLine 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 zoneSame architecture used for both AC and DC powered line card chassisThree different types of power shelves; DC, AC Wye and AC Delta



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.



Power Distribution



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:

• Power module A0 powers load zones 1 and 2 (Z1 and Z2)



• Power module B0 powers load zones 1 and 2 (Z1 and Z2)



• The upper fan tray is powered by load zone 2 (A0Z2 and B0Z2)

• The lower fan tray is powered by load zone 5 (A2Z5 and B2Z5) through the fan controller cards



Power Shelves/Load Zones

A0 A1 A2 AM0

B0 B1 B2 AM1

Z1 Z2 Z3 Z4 Z5 Z6

Z1 Z2 Z3 Z4 Z5 Z6

PS0 (Power shelf)

PS1 (Power shelf)



Line Card Chassis Load Zones The Line Card Chassis contains six load zones as follows:

• Load zone 1 (Z1) powers chassis slots 0, 1, 2, and 3

• Load zone 2 (Z2) powers chassis slots FC0, RP1 (PLIM side) and SM0, SM1, SM2 and SM3 (MSC side)



• Load zone 5 (Z5) powers chassis slots FC1, RP0 (PLIM side) and SM4, SM5, SM6 and SM7 (MSC side)




Line Card Chassis Load Zones



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.


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 RectifiersAC Power Shelf



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. _________________________________________________________________



AC Power Architecture



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 rectifier-specific 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.



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



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.



AC Rectifier Status Indicators

The AC rectifier is overheated and it has been shut down

YellowOT

The AC rectifier is operating in a current limiting condition

YellowILIM

The input circuit breaker is off (in the off position)

YellowBreaker Trip

AC input is out of range or is not being provided to the AC rectifier

YellowAC Input Fail

A fault has been detected within the AC rectifier

YellowFault

The AC rectifier is operating normally with power

GreenPWR OK

FunctionColorNamePower OK

Fault

AC Input Fail

CB Trip

ILIM

OT



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.


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 maximumTwo DC power shelves per chassis provides 2N redundancyEach 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



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.



DC Power Shelf Input Connectors

Grnd 6 Input Connectors



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 field-replaceable 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.



DC Power Shelf Architecture



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:

• Inrush current limiting

• EMI filtering

• Surge protection

• Isolation circuits to process the power before it exits the midplane connector to the chassis power distribution



DC PEM

LEDs



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.



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



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.



DC PEM Status Indicators

The input circuit breaker is in the off position

YellowCB Trip

The DC PEM is overheated and it has been shut down

YellowOT

DC input is out of range or is not being provided to the PEM

YellowDC Input Fail

A fault has been detected in the PEMYellowFault

The PEM is operating normally with powerGreenPWR OK


Fault

DC Input Fail

CB Trip

OT



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).


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



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

The maximum rating for the alarm circuit is 2A, 50V

• PEM or AC Rectifier status monitoring

• Alarm monitoring



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



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.



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



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:

• 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


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



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.



Line Card Chassis Airflow



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.



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.



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:

• 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



Line Card Chassis Fan Tray

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

Status

Status LED



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:

• 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.



Line Card Chassis Fan Controller Card

BITs/SETsExt. Clk 1

BITs/SETsExt. Clk 2

Status LEDs



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.



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 quick-shutdown mode to aide in OIR

•Quick-shutdown mode minimizes inrush current during hot swap or OIR



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.



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



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.



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



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.



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



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.


Module 2 CRS-1 16-Slot Chassis Single Line Card Switch Fabric

CRS-1 16-Slot Chassis Single Chassis System Switch Fabric

PLIM PLIMMSCMSC

Ingress Egress

IP Data IP Data

Linecard Chassis

Switch Fabric Card

1 of 8

S1

S1

S2

S2

S3

S3



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.


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 systemsMajor 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 softwareEach S123 switch fabric card contains two S1, two S2, and four S3 elements.



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.



S123 Functional Blocks

1 2 3

4 5 6 7

Slots 0-7

Ingress from MSCs

Slots 8-17

(To fabric)

Egress

To

MSCs and RPS

(From Fabric)

Note: Slots 16 & 17 are the active and standby RPs



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:

• A board “OK” LED

• An alphanumeric display



S123 Physical Overview

Status LED

Alpha



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:

• 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


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 capabilityEach 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



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



CRS-1 16-Slot Chassis RP Front Panel and Memory Options

MemoryModules

SMPCPUs



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 sled-mounted 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.



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



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.



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



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 single-chassis 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.



Block Diagram

FPGA

FE/GEswitch

MEM

CTLCPU

PCMCIA2

IDETo

fabric

From fabric

CPU

IFQ

links

LC FElinks CTL GE link

CTL GE link

Midplane

PCI1

2

3

Aux and console

Management GE link

5

6

7

8

9

4

10

Card presence detectRP mastershipPROM presence



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.



Block Diagram (Cont.)

FPGA

FE/GEswitch

MEM

CTLCPU

PCMCIA2

IDETo

fabric

From fabric

CPU

IFQ

links


CTL GE link

Midplane

PCI1

2

3

Aux and console

Management GE link

5

6

7

8

9

4

10




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 self-tests.

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 de-asserts its “Ready” signal, the standby RP immediately receives an asserted “Active” signal, along with an interrupt.



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.



Summary

CRS-1 16-Slot Line Card Chassis Hardware In this module, you learned the following:

• 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


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.


• List and describe the hardware features and functions of the CRS-1 8-slot 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



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

• 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

3–2 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/275kgHeat Dis.: 27,350 BTURack mountable



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.



CRS-1 8-Slot Line Card Chassis Components - PLIM Side



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.



MSC Side



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.



Cable Management





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).


Module 3 CRS-1 8-Slot Line Card Chassis Slot Numbering


Front Rear



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.



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



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.



Power Architecture



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



Chassis Load Zones



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 CRS-1 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:

− Convert 200- to 240-VAC input power to 54.5 VDC used by the line card chassis. Each AC rectifier is field-replaceable.


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



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



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

• Line frequency—50 to 60 Hz, range 47 to 63Hz− 20 A North America (plugs into IEC 60309 receptacle)− 16 A International



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.



AC PDU & Rectifier

CRS-8-LCC-PDU-ACD AC Delta PDUCRS-8-LCC-PDU-ACW AC WYE PDU

CRS-8-AC-RECT AC rectifier module

2 required for chassis – 1 per PDU



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.



AC Rectifier Status Indicators

The AC rectifier is overheated and it has been shut down

YellowOT

The AC rectifier is operating in a current limiting condition

YellowILIM

The input circuit breaker is off (in the off position)

YellowBreaker Trip

AC input is out of range or is not being provided to the AC rectifier

YellowAC Input Fail

A fault has been detected within the AC rectifier

YellowFault

The AC rectifier is operating normally with power

GreenPWR OK


Fault

AC Input Fail

CB Trip

ILIM

OT



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.


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.



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 field-replaceable.

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.



DC Power Entry Module

2 DC PEMs required per chassis, 1 per PDU

Each PEM provides 7500 WATTs of power



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.



DC PEM Status Indicators

The DC PEM is overheated and it has been shut down

YellowOT

The input circuit breaker is in the off position

YellowCB Trip

DC input is out of range or is not being provided to the PEM

YellowDC Input Fail

A fault has been detected in the PEMYellowFault

The PEM is operating normally with powerGreenPWR OK


Fault

DC Input Fail

CB Trip

OT



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)


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



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.



Line Card Chassis Airflow & Air Filter

Fan Trays

PDUAir Intake Air Exhaust

Air Filter

PLIM Side(Front)

MSC Side(Rear)



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. _________________________________________________________________



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



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.



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



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. _________________________________________________________________



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



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:

• 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.



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



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 speed-up 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.


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



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:

• 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.



Operation



SFC Functional Block Diagram The major functional blocks of the HS123 switch fabric card are:

• 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.



SFC Functional Block Diagram



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.


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



RP Components • 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.



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



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



RP Front Panel

Memory

CPU



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 single-chassis 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.



Block Diagram

FPGA

FE/GEswitch

MEM

CTLCPU

PCMCIA2

IDETo

fabric

From fabric

CPU

IFQ

links


CTL GE link

Midplane

PCI1

2

3

Aux and console

Management GE link

5

6

7

8

9

4

10




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.



Block Diagram (Cont.)

FPGA

FE/GEswitch

MEM

CTLCPU

PCMCIA2

IDETo

fabric

From fabric

CPU

IFQ

links


CTL GE link

Midplane

PCI1

2

3

Aux and console

Management GE link

5

6

7

8

9

4

10




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 self-tests.

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 de-asserts its “Ready” signal, the standby RP immediately receives an asserted “Active” signal, along with an interrupt.



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.



Summary

CRS-1 8-Slot Line Card Chassis Hardware In this module, you learned the following:

• 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


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>






















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).


• 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


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.


Module 4 Modular Services Card

Modular Services Card - Overview

PLIM MSC MSC PLIM

Ingress Egress

S1 S2 S3

Switch Fabric

IPData

IPData

PLIMs

RPs/FCs SFM

MSCs/DRPs

MSCs/DRPsPLIMs

Mid-Plane

PhysicalView

LogicalView



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.


Module 4 Modular Services Card

MSC Hardware Components

CPU

Egress PSE

IngressPSE IngressQ

Power Regulators

SP

2*FabricQ

EgressQ



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 Inter-Chassis 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.


Module 4 DRP Architecture - LC Chassis

DRP Architecture - LC Chassis

FLASHFLASH

SPONGE

MIDPLANE

SPFE Links

CPUMEMCTL

CPUMEMCTL

PCI

Mgmt GE link

Mgmt GE link

IDE

IDE

Aux & Console

Aux & Console

Fabric Connection

IngressQ(SPRAYER)

FabricQ(SPONGE)

CPUCTRL(SQUID)

CPUCTRL(SQUID)

FLASH FLASH

Shared Resource

CPU0

CPU1



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.


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 fiber-optic 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



PLIM Physical Characteristics All POS and POS/DPT PLIMs have the following physical characteristics:

• 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



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



PLIM Types Different PLIMs provide a range of optical interfaces, such as very-short-reach (VSR), intermediate-reach (IR), or long-reach (LR). The Cisco CRS-1 supports the following PLIMs for each chassis type.

• 1-port OC-768/STM-256 packet-over-SONET (POS); available in short-reach (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.



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



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. _________________________________________________________________



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

MIDPLANE

PLAPLIM I/F

OC192Framer

OC192Optics

OC192Optics

OC192Framer

OC192Framer

OC192Optics

OC192Optics

OC192Framer



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



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



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.



OC768c PLIM HW Architecture

EgressQ

RX PSE

PLA768

MSC 1xOC768 PLIM

Framer

Midplane



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 _________________________________________________________________



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



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) multi-fiber 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 - Port OC192c PLIM HW Architecture

Line card 4xoc192 PLIM

EgressQ

Rx PSE

PLA 0

PLA 1

RAC0

RAC1

Framer 0

Framer 1

RAC2

RAC2

Framer 2

Framer 3

Midplane



4 - Port OC-192c PLIM Faceplates The 4-port OC-192 PLIM has:

• 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



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)

• Two DPT MODE LEDs—One DPT MODE LED is for ports 0 and 1, and other for ports 2 and 3− DPT mode is always configured on pairs of ports




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 long-reach (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.



16 - Port OC-48c PLIM HW Architecture

Line card 16xoc48 PLIM

EgressQ

Rx PSE

PLA 0

PLA 3

RAC0

RAC1

Framer 0

Framer 1

RAC14

RAC15

Framer 14

Framer 15

RAC2 Framer 2

RAC3 Framer 3

RAC12 Framer 12

RAC13 Framer 13

Midplane



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

−

−

−

−

−

−

−

−




• 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):

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).




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

• 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)

• Power consumption 136 Watts



10 – Port 10GE PLIM HW Architecture The 8-port 10-Gigabit Ethernet (GE) PLIM provides from one to eight 10-GE 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:

• 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 full-duplex 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.



10 – Port 10GE PLIM HW Architecture

Line card 8x10GE PLIM

EgressQ

Rx PSE

PLA 0

PLA 1

PHY0

PHY1

Optics 0

Optics 1

PHY6

PHY7

Optics 6

Optics 7

PHY2 Optics 2

PHY3 Optics 3

PHY4 Optics 4

PHY5 Optics 5

Midplane



Oversubscription of 10-GE Ports If more than 2 optic modules are installed in either set of ports, oversubscription occurs on all ports in that set. For example, if modules are installed in ports 0 and 1, each interface has 10 Gbps of throughput.

Adding another module in port 2 causes oversubscription on all of the interfaces (0, 1, and 2).

___________________________CAUTION _______________________

If your configuration cannot support oversubscription, use the following guidelines to determine which PLIM slots to install optic modules in. _________________________________________________________________

• Do not install more than four optic modules in each PLIM.

• Install the optic modules in any one of the following sets of PLIM slots:

−

−

−

−

Slots 0 and 1, and 4 and 5




If your configuration can support oversubscription and you want to install more than four optic modules in a PLIM, we recommend that you install additional modules in empty slots, alternating between upper and lower ports. For example, if you install a fifth optic module in an empty slot in the upper set of ports (0 to 3), be sure to install the next module in an empty slot in the lower set of ports (4 to 7), and so on.



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



10 – Port 10GE PLIM Faceplate The 8-port 10-GE PLIM has:

• Eight slots that accept XENPAK optic modules, which provide LR optics with SC fiber-optic interfaces.

• A STATUS LED

−

−

−




• A LED for each port—Indicates that the port is logically active; the laser is on

• Power consumption—110 W (with 8 optic modules)



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)



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:

• 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.


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



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.



SPA Slot Numbering on the Cisco CRS-1 SIP-800



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:

• 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)



Shared Port Adapters

• 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-− 8-Port Gigabit Ethernet SPA (SPA-8X1GE)

XFP)

SPA Bay 3 SPA Bay 4 SPA Bay 5

SPA Bay 0 SPA Bay 1 SPA Bay 2

Double HeightSPA Bays 0 & 3

SPA Bay 4

SPA Bay 1

SPA Bay 5

SPA Bay 2






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.



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.



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 SIP-800. 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.


Module 4 SIP Bandwidth Oversubscription

Bandwidth Oversubscription - Overview

MSC SIP-800 Jacket Card

EgressQ

Rx PSE

PLA 0

PLA 1

SPA0

SPA1

SPA5

SPA2

SPA3

SPA4

Midplane

8 Gbps81Gbps8-Port Gigabit Ethernet SPA

10Gbps110Gbbps1-Port OC-192c/STM-64 PoS/RpR XFP SPA

622.08 Mbps4155.52 Mbps4-Port OC-3c/STM-1 PoS SPA

Total BandwidthNumber of PortsPer-Port Bandwidth

SPA



Modular Optics Some SPAs implement small form-factor pluggable (SFP) optical transceivers to provide network connectivity. An SFP module is a fiber-optic 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

XFP-10GLR-OC192SR

• 8-Port Gigabit Ethernet SPA

SFP-GE-S

SFP-GE-L

SFP-GE-Z


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



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:

• RFC 1155, Structure and Identification of Management Information for TCP/IP-based Internets

• RFC 1156, Management Information Base for Network Management of TCP/IP-Based Internets

• RFC 1157, Simple Network Management Protocol (SNMP)

• RFC 1213, Management Information Base (MIB) for Network Management of TCP/IP-Based Internet MIB II.


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



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.


Module 4 4-Port OC-3c/STM-1 SPA

4-Port OC-3c/STM-1 LEDs

SPA power is offSPA is ready and operationalSPA power is on & good; SPA is being configured

OffOnOn

OffGreenAmber

STATUS

Port is not enabled

Port is enabled, loopback is offPort is enabled, loopback is on

Off

OnOn

Off

GreenAmber

A/L

Port is not enabled Port is enabled and there is a valid SONET signal without AlarmsPort is enabled and there is at least one alarm

OffOn

On

OffGreen

Amber

C/AMeaningStateColorLED Label



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:

• RFC 1155, Structure and Identification of Management Information for TCP/IP-based Internets

• RFC 1156, Management Information Base for Network Management of TCP/IP-Based Internets

• RFC 1157, Simple Network Management Protocol (SNMP)

• RFC 1213, Management Information Base (MIB) for Network Management of TCP/IP-Based Internet MIB II.


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



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. _________________________________________________________________


Module 4 1-Port OC-192c/STM-64 PoS/RPR XFP SPA

1-Port OC-192c/STM-64 PoS/RPR XFP SPA LEDs

SPA power offSPA is ready and operationalSPA power is on and good; SPA is being configured

OffOnOn

OffGreenAmber

STATUS

Port is not enabled

Port is enabled; loopback is offPort is enabled; loopback is on

Off

OnOn

Off

GreenAmber

ACTIVE

Port is not enabledPort is enabled; there is a valid SONET signal w/o alarms

Port is enabled; there is at least one alarm (LOS, LOF, RDI)Indicates SRP mode mismatch alarm

OffOn

OnBlinking

OffGreen

Amber

CARRIER

Mate port is not synchronizedPort is not enabled

OffOn

OffAmber

MATESYNC

Port is not in pass thru mode

Port is in pass thru mode

Off

On

Off

Amber

PASSTHRU

Port is not in wrap modePort is in warp mode somewhere on ring

Port is in wrap mode locally

OffOn

On

OffGreen

Amber

WRAP

MeaningStateColorLED Label



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.


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



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.


Module 4 8-Port Gigabit Ethernet SPA

8-Port Gigabit Ethernet SPA LEDs

SPA power is off

SPA power is on and good, SPA is being configuredSPA is ready and operational

Off

OnOn

Off

AmberGreen

STATUS

Port is not enabledPort is enabled and link is down

Port is enabled and link is up

OffOn

On

OffAmber

Green

Active/LinkMeaningStateColorLED Label



Summary

CRS-1 Line Card Chassis Common Elements In this module, you learned the following:

• 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


Module 4

Review Questions

CRS-1 Line Card Chassis Common Elements 1. <Insert Question>




























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.


• 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 stand-alone to a Multi-Shelf configuration

• Describe the CRS-1 Management System Control Plane and SC-GE card


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


Module 5 Switch Fabric Chassis

Switch Fabric Chassis - Front



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.


Module 5 Switch Fabric Chassis

Switch Fabric Chassis – Rear View



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 SC-GE card is installed in the right most slot of the lower card cage. The SC-GE 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.


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



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.


Module 5 System Configurations

System Configurations

STANDALONE CONFIG (1.2Tbps)8/16 MSC and PLIM slotsNo Fabric chassis required

•S1/2/3 Fabric Cards in Line card chassis

MULTI-SHELF CONFIG (1.2T TO 92T)2 to 72 Line card chassis1 to 8 fabric chassis



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.


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

23 Tbps288up to 182

92 Tbps1152up to 728

46 Tbps576up to 364

7.68 Tbps96up to 61

Maximum capacity

Maximum number of slots

Number of supported Line Card chassis

Number of Fabric Chassis



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. _________________________________________________________________


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



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 • 9 bundle connections per fabric card

• 24 fabric cards



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


Connections per Fabric Card Chassis

• 9 bundle connections / fabric card

• 24 fabric cards


Multiple BundlesBetween LC ChassisAnd FC Chassis

Optical Interface Modules Full Utilized Fabric Chassis



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


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 operationalGeneral upgrade procedure:

1. Shutdown 1 S123 switch fiber card in the linecard chassis2. Replace the S123 switch fiber card, from step 1, with an S13

switch fiber card3. Connect the optical cable to S13 switch fiber card4. Bring up that configuration and verify the system operation5. Repeat steps 1 through 4 for each fabric plane and linecard

chassis you wish to interconnect into the multi-shelf system



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. _________________________________________________________________


Module 5 CRS-1 Management System Control Plane and Shelf Controller Gigabit Ethernet (SC-GE) card

CRS-1 Management System Control Plane

RP

RP LC

LC

FE

RP

RP LC

LC

FE

SC-GE

SC-GE S2

S2

FE

Gig EtherSwitch

Gig EtherSwitch

Inter-chassisGE Network

Optional 10 GE

Dedicated GigE switches for inter-chassis control network

Intra-chassis

Line Card chassis

Key Components• RP – LC• SC-GE – FC

Line Card chassis

Switch Fabricchassis



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:

• 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.


Module 5 CRS-1 Management System Control Plane and Shelf Controller Gigabit Ethernet (SC-GE) card

Shelf Controller Gigabit Ethernet Card (SC-GE)

BACKPLANE

FE/GESwitch

LC FELinks

CPUMEMCTL

CTL GE linkCTL GE link

PCI

Mgmt GE link

IDE

Aux & Console

FLASH FLASH



Summary

Introduction to Cisco CRS-1 Multi-Shelf Architecture In this module, you learned the following:

• 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 SC-GE card


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


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.


Module 6 Cisco IOS XR Architecture

Cisco IOS XR Architecture

Cisco IOS XR kernel

Distributed infrastructure

Routingmodules

(BGP, OSPF)

Protocolmodules

(IP)Application

modules

Runs onmultiple CPU’s



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 • Kernel

• Plane separation

• Fault tolerance and isolation

• Checkpoint support for process restart

• Process-level redundancy

• Route processor and distributed RP failover

• Nonstop forwarding


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.



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.



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

Microkernel:

Threads

Scheduling

Debug

Timers

Message queues

Synchronization

Distributed processing

File system

Lightweight messaging

Event management

CIS

C O

PO SIX

Applications

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.


http://searchwin2000.techtarget.com/sDefinition/0,,sid1_gci211723,00.html

http://searchenterpriselinux.techtarget.com/sDefinition/0,,sid39_gci212978,00.html

http://search390.techtarget.com/sDefinition/0,,sid10_gci213265,00.html


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.



Plane Separation

Microker

nel

Process mgmt IPC mech. Memory mgmt. H/W abstraction

BGP

RIP

IS-IS

OSPF

Rout

ing

Polic

yPI

MIG

MP RIB

L2 D

river

sAC

LFI

BQo

SLP

TSHo

st S

ervic

esPF

IIn

terfa

ces

Data plane

CLI

SNMP

XML

Netfl

owAl

arm

Perf.

Mgm

t.SS

H

Management planeControl plane

Control Plane

BGP

RIP

IS-IS

OSPF

Rout

ing

Polic

yPI

MIG

MP RIB

L2 D

river

sAC

LFI

BQo

SLP

TSHo

st S

ervic

esPF

IIn

terfa

ces

Data plane

CLI

SNMP

XML

Netfl

owAl

arm

Perf.

Mgm

t.SS

H

Management planeControl plane

Control Plane

BGP

RIP

IS-IS

OSPF

Rout

ing

polic

yPI

MIG

MP RIB

L2 d

river

sAC

LFI

BQo

SLP

TSHo

st se

rvice

sPF

IIn

terfa

ces

Data plane

CLI

SNMP

XML

Netfl

owAl

arm

Perf.

mgm

t.SS

H

Management plane

Memory-protected microkernel

Distributed subsystems/processes

System services

Control plane



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.



Fault Tolerance and Isolation

Layered rather than monolithic architecture

Fault isolation and protection between the planes

Cisco IOS XR

Dataplane

Controlplane

Man

agem

ent

plan

e

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….



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.



Checkpoint Support for Process Restart

Process

Checkpoint shared

memory store

Updates of running state

New instance

of process

(Process fails)

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.



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 user-configurable option. _________________________________________________________________



Process-Level Redundancy

Standby

process

Active

process

Active service-providing process

Standby process

Active process uses a checkpoint database to

share running state with standby

Client

Client

Client

Clients use active service-providing 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.



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



Process-Level Redundancy (Cont.)

1. Active process fails

Client

ClientClient

5. Clients use new active service-providing process

4. New active starts sending updates to standby process

Active

process

Standby

process

New active

process

3. New standby process is started

2. Standby process becomes active

Instructor's Note

Animated – starts w/ Active process and clients with arrows. Then follows each step – 1 click – 1 step



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:

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



Process Restart and Recovery—RP Failure

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

Process A

Process B

Process C

Process A

Process B

Process C´

Process D

1

1

1

Active card Standby card

2

2

3

4

Checkptprocess Checkpt

process



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.


mkumarjo

Highlight


Route Processor and Distributed Route Processor Failover

Active RP

Standby RP

Checkpointed

RP failure

If no standby DRP exists,

no checkpointing

Active DRP

Standby DRP

Active DRP

DRP failure

Checkpointed

Notcheckpointed

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.



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.



Nonstop Forwarding

• Paired RPs or DRPs

• Each LC has dedicated packet forwarding hardware (SPP)

• Packet forwarding is not affected by:− ISIS, OSPF, BGP, MPLS,

Multicast process restart− Infrastructure process

restarts− RP failover

LC LC

RP RP

Controlupdatesinterrupted

But…FwdingOk!

Active Active

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



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 • Adjacency management

• Forwarding Information Base tables

• Distributed interface management

• Distributed configuration management

• Two-stage forwarding


Module 6 Scalability

Scalability Features

•Adjacency management

•Forwarding Information Base tables

•Distributed interface management

•Distributed configuration management

•Two-stage forwarding



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.



Adjacency Management

Adjacency Information

Base

Modular services card (MSC)

ARP/Maptables

Interface manager

RP

Instructor's Note

Emphasis: the MSC (CRS-1) and line cards (XR 12000) know only about the locally / directly attached hosts and peers



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.



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

informationWhy 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



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.



Forwarding Information Base

MSC-CPURP or DRP

OSPF

ISIS

Staticroutes

RIB

BGP

HardwareFIB

Switc

h fa

bricMSC-PSE

FIBprocess

AIB Ifmgr



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 Switch-Over (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.



Distributed Interface Management

Interface driver

MSC

RP

Interface manager

Interface driver

MSCInterface manager Interface manager

Interfaces Interfaces

Interface manager global database

Interface driver



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.



Distributed Configuration Management

RP

Configuration manager

L2/L3 applications and

H/W drivers

MSC

Hardware


L2/L3 applications and

H/W drivers

MSC

Hardware




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.


Module 6 Configuration Operations

Two-Stage Configuration

Running config

Config databaseSecond stageFirst stage

commitTargetconfig

Config changes New running config

Config agents

CLI/XML

+

Router#> Config t

=

• Stage 1: Make configuration changes−Create new target config by entering config

• Stage 2: Make changes persistent

Running config

Instructor’s Note

This slide is animated in 2 steps.

Click 1 shows all stage 1 elements

Click 2 shows all stage 2 elements



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. _________________________________________________________________



Configuration File System

RP “disk0:”Running configplus changes

IOS XR

New binary configuration

created; router uses it to boot up

following reload



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.



Access and Login

• 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

User Access Verification

Username: <username>Password: <password>RP/0/RP0/CPU0:P1#



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.

• 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.



Command Modes

Login

Configuration modes

EXEC mode



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.


Module 6 Configuration Basics

Management IP Interfaces

•Cisco CRS-1 Management Ethernet interfaces−MgmtEth0/RP0/CPU0/0−MgmtEth0/RP1/CPU0/0

Managementnetwork

connections



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.

_________________________________________________________________



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



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.



Configuring Management Ethernet

• Interface mode• Set the IP version

− IPv4 or IPv6 address−Mask

•Activate the interface

RP/0/RP0/CPU0:router#configureRP/0/RP0/CPU0:router(config)#interface MgmtEth0/RP0/CPU0/0RP/0/RP0/CPU0:router(config-if)#ipv4 address 12.9.42.105/16RP/0/RP0/CPU0:router(config-if)#no shutRP/0/RP0/CPU0:router(config-if)#



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.



Configuring Loopback Address

• Interface command

•Assign IP address

•Visible as interface

RP/0/RP0/CPU0:router(config)#interface loopback0 12.9.42.110/16RP/0/RP0/CPU0:router(config-if)#



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. _________________________________________________________________



Configuring IP Virtual Address

• IPv4 command

•Assign IP address

•Only visible in RIB

RP/0/RP0/CPU0:router(config)#ipv4 virtual address 12.9.42.125/16RP/0/RP0/CPU0:router(config)#



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.



Hostname

•Create a hostname

RP/0/RP0/CPU0:router(config)#hostname P1RP/0/RP0/CPU0:router(config)#



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



Configuring Network Interfaces

•Set clock source first− Controller

• Interface command− Rack/slot/module/port − Assign IP address− Activate the interface

RP/0/RP0/CPU0:router(config)#controller sonet 0/4/0/0RP/0/RP0/CPU0:router(config-sonet)#clock source internalRP/0/RP0/CPU0:router(config-sonet)#exitRP/0/RP0/CPU0:router(config)#interface POS 0/4/0/0RP/0/RP0/CPU0:router(config-if)#ipv4 address 12.9.44.5/24RP/0/RP0/CPU0:router(config-if)#no shutRP/0/RP0/CPU0:router(config-if)#



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.



Committing the Configuration

•Target changes must pass semantics−Pass; all changes are committed−Fail; no changes are committed

RP/0/RP0/CPU0:router(config)#commitRP/0/RP0/CPU0:P1(config)#



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.



Exiting and Ending Configuration Mode

•Exit configuration mode

•End configuration mode

RP/0/RP0/CPU0:P1#configure RP/0/RP0/CPU0:P1(config)#interface pos 0/5/0/1 pos crc 16RP/0/RP0/CPU0:P1(config-if)#exitRP/0/RP0/CPU0:P1(config)#exitUncommitted changes found, commit them before exiting(yes/no/cancel)?

[cancel]:yesRP/0/RP0/CPU0:P1#

RP/0/RP0/CPU0:P1#configure RP/0/RP0/CPU0:P1(config)#interface pos 0/5/0/1 pos crc 16RP/0/RP0/CPU0:P1(config-if)#endUncommitted changes found, commit them before exiting(yes/no/cancel)?

[cancel]:yesRP/0/RP)/CPU0:P1#

• Press Enter or type "no" to exit or end without committing changes

• Type "yes" for changes to take effect



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.



Display the Active Configuration

• Display entire running configuration• Display by like groups (Interfaces, routing protocols)

RP/0/RP0/CPU0:P1(config)#show running-configBuilding configuration...!! Last configuration change at 15:57:39 UTC Wed Jun 16 2004 by cisco!hostname P1

interface MgmtEth0/RP0/CPU0/0ipv4 address 12.9.42.105 255.255.0.0

!interface POS0/4/0/0ipv4 address 142.50.12.5 255.255.255.0


end

Additional messages are not shown




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. _________________________________________________________________



Display the Target Configuration

RP/0/RP0/CPU0:P1(config)#show configBuilding configuration...interface POS0/4/0/3ipv4 address 142.50.48.5 255.255.255.0

!interface POS0/5/0/1ipv4 address 142.50.36.5 255.255.255.0poscrc 16!

!end



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.



Display the Merged Configuration

RP/0/RP0/CPU0:P1(config)#show config mergeBuilding configuration...hostname P1

interface MgmtEth0/RP0/CPU0/0ipv4 address 12.9.42.105 255.255.0.0



interface POS0/4/0/3ipv4 address 142.50.48.5 255.255.255.0

!interface POS0/5/0/1ipv4 address 142.50.36.5 255.255.255.0poscrc 16

!!end

Added





Summary

Cisco IOS XR Overview In this module, you learned 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 management addressing

• Describe an initial configuration


Module 6

Review Questions

Cisco IOS XR Overview and Initial Configuration 1. <Insert Question>




























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.



• 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


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.


Module 7 Cisco IOS XR Command Modes

Cisco IOS XR Command Modes

Login

Configuration modes

EXEC mode

Admin EXEC mode

Admin configuration mode



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.

− 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.



Configuration Modes

• Create router configurations

• Perform router operations

Configuration mode

Interface config submode

Router config submode

User and Task group config submode

pos config submode

Address family configsubmode



Administration Modes Administration mode is currently used to configure multiple logical routers (LRs) and to install the Cisco IOS XR software.

• 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



Administration Modes

• Software installations

• Logical router management

Admin EXEC mode

Admin configuration mode

Logical router configuration submode



Command Mode Samples Here are some sample illustrations of the prompt syntax and some commands used to enter various modes.



Command Mode Samples

RP/0/0/CPU0:P4#EXEC

Globalconfig:

RP/0/0/CPU0:P4#configure RP/0/0/CPU0:P4(config)#

Submode andInterfaceconfig:

RP/0/0/CPU0:P4(config)#interface pos 0/2/0/0 RP/0/0/CPU0:P4(config-if)#

Protocol andsubmodeconfig:

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)#

RP/0/0/CPU0:P4#adminRP/0/0/CPU0:P4#(admin)#Admin

Instructor's Note

This slide is animated. The instructor needs to click/Enter to see each example except the first.



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:

• 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



Cisco CRS-1 Hardware Node Locations

SPFC0—FC10—71Fan controller card

SPAM0—AM10—71Alarm card

SPSM0—SM70—71Switch fabric module

CPU0, SP0—150—71Modular services card

CPU0RP0/RP10—71Route processor

ModuleSlotRackCard Type

Rack number Slot = Physical slot of card Module = CPU0 or 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.



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:

• 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



Command-Line Interface Prompt Syntax: Cisco CRS-1 Routing System

• 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

RP/0/RP0/CPU0:router Direct terminalconnection

Managementnetwork

connection



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.



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



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.



Locking and Unlocking the Running Configuration

Runningconfig

Configdatabase

CLI

RP/0/RP0/CPU0:routername#configure exclusiveRP/0/RP0/CPU0:routername(config)#hostname P4RP/0/RP0/CPU0:routername(config)#commitRP/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.



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.



Preconfiguration

CLI

Prior to installing line

card, its configuration

can be entered

Configure resources not yet present

Reduce down time

Improve operational tasks

RP/0/0/CPU0:P4#configRP/0/0/CPU0:P4(config)#interface preconfigure POS 0/4/1/0RP/0/0/CPU0:P4(config-if-pre)#ip address 1.1.1.1 255.255.255.0RP/0/0/CPU0:P4(config-if-pre)#encapsulation pppRP/0/0/CPU0:P4(config)#controller preconfigure sonet 0/4/0/0 clock source line

Prior to the LC being inserted• Select the interface

•Configure the timing (SONET controller)

•Configure the framing

•Configure the IP address



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.



Clear Target Configuration Changes

RP/0/0/CPU0:P4#configure RP/0/0/CPU0:P4(config)#interface pos 0/5/0/1 pos crc 16RP/0/0/CPU0:P4(config-if)#ipv4 address 142.50.36.1 255.255.255.0RP/0/0/CPU0:P4(config-if)#show configBuilding configuration...interface POS0/5/0/1ipv4 address 142.50.36.1 255.255.255.0poscrc 16

!End

RP/0/0/CPU0:P4(config)#clearRP/0/0/CPU0:P4(config)#show configBuilding configuration...end



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.



Saving a Target Configuration Commands

• Save target configuration commands to specific file

RP/0/0/CPU0:P4(config)#username edRP/0/0/CPU0:P4(config-un)#password edRP/0/0/CPU0:P4(config-un)#group root-systemRP/0/0/CPU0:P4(config-un)#show config | file disk0:edBuilding configuration...

[OK]RP/0/0/CPU0:P4(config-un)#



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.



Loading a Target Configuration Commands

• File has been saved as a target configuration

• Loaded file becomes the target configuration

RP/0/0/CPU0:P4(config)#show configBuilding configuration...end

RP/0/0/CPU0:P4(config)#load disk0:edLoading.57 bytes parsed in 1 sec (56)bytes/sec

RP/0/0/CPU0:P4(config)#show configBuilding configuration...username edpassword 7 110C1Dgroup root-system!end



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.



Abort Configuration Mode

•Ends the configuration session immediately− No warning before deletion of changes

RP/0/0/CPU0:P4#configure RP/0/0/CPU0:P4(config)#interface pos 0/5/0/1 pos crc 16RP/0/0/CPU0:P4(config-if)#abortRP/0/0/CPU0:P4#



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.



Failed Configuration Commands

•Configuration commit entry fails−View causes of failures

RP/0/0/CPU0:P4#configRP/0/0/CPU0:P4(config)#taskgroup bgpRP/0/0/CPU0:P4(config-tg)#hostname P4xyzRP/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 ERRORStaskgroup 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#configRP/0/0/CPU0:P4(config)#taskgroup bgpRP/0/0/CPU0:P4(config-tg)#hostname P4xyzRP/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 ERRORStaskgroup bgp!!% Usergroup/Taskgroup names cannot be taskid names!

RP/0/0/CPU0:P4xyz(config)#

Partialconfiguration!



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).



Configuration Checkpoint and Rollback

• Each “commit” generates record with CommitID or label

• Each CommitID is a “rollback”point

• Commit database stores up to 100 rollback points

Config logCommitID# 100CommitID# 099CommitID# 098

CommitID# 001

••

Target config commit

Running config

Config database



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:

• 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



Display Configuration Changes

RP/0/RP1/CPU0:P4#show config ?commit Show commit informationfailed Contents of failed configurationremoved Display configuration removed during package

(de)activation.rollback Show rollback information.running-config Current operating configurationsessions Users with active configuration sessions



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



Display Stored Configuration Commits

• Maximum of 100• Actual changes are viewable

RP/0/RP1/CPU0:P4#show config commit listSNo. Label/ID User Line Client Time Stamp~~~~ ~~~~~~~~ ~~~~ ~~~~ ~~~~~~ ~~~~~~~~~~1 1000000167 cisco con0_RP1_C CLI 05:40:54 PST Wed Mar 02 20052 1000000166 cisco vty0 CLI 10:22:27 PST Mon Feb 28 20053 1000000165 cisco vty0 CLI 10:13:15 PST Mon Feb 28 20054 1000000164 cisco con0_RP0_C CLI 13:24:39 PST Thu Feb 24 20055 doug cisco con0_RP0_C CLI 13:17:51 PST Thu Feb 24 20056 1000000162 cisco con0_RP0_C CLI 12:52:10 PST Thu Feb 24 20057 1000000161 cisco con0_RP0_C CLI 12:51:02 PST Thu Feb 24 2005

•List of last 1000 committed changes

RP/0/RP1/CPU0:P4#show config commit historySNo. Label/ID User Line Client Time Stamp~~~~ ~~~~~~~~ ~~~~ ~~~~ ~~~~~~ ~~~~~~~~~~1 1000000166 cisco vty0 CLI 10:22:27 PST Mon Feb 28 20052 1000000165 cisco vty0 CLI 10:13:15 PST Mon Feb 28 20053 1000000164 cisco con0_RP0_C CLI 13:24:39 PST Thu Feb 24 20054 doug cisco con0_RP0_C CLI 13:17:51 PST Thu Feb 24 20055 1000000162 cisco con0_RP0_C CLI 12:52:10 PST Thu Feb 24 20056 1000000161 cisco con0_RP0_C CLI 12:51:02 PST Thu Feb 24 20057 1000000160 cisco con0_RP0_C CLI 11:06:20 PST Thu Feb 24 20058 1000000159 cisco con0_RP0_C CLI 17:17:58 PST Tue Feb 15 20059 1000000158 cisco con0_RP0_C CLI 10:11:59 PST Tue Feb 15 200510 1000000157 cisco 0.0.0.0 Rollback 07:26:12 PST Thu Feb 03 200511 1000000156 cisco con0_RP0_C CLI 03:27:26 PST Thu Feb 03 200512 1000000155 cisco con0_RP0_C CLI 03:27:01 PST Thu Feb 03 2005



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



Display Committed Changes

RRP/0/0/CPU0:P4#show config commit changes dougBuilding configuration...username dougpassword 7 110D161010!endRP/0/0/CPU0:P4#show config commit changes 1000000163Building configuration...username dougpassword 7 110D161010!endRP/0/0/CPU0:P4#show config commit changes 1000000167Building configuration...username douggroup root-systemgroup cisco-support!end

•Display specific committed changes

Same

Added

•Display last n changesRP/0/0/CPU0:P4#show config commit changes last 2Building configuration...username douggroup root-systemgroup cisco-support!xml agent corbahttp serverend

RP/0/0/CPU0:P4#show config commit changes last 3Building configuration...config-register 0x2username douggroup root-systemgroup cisco-support!xml agent corbahttp serverend

Previous change

Last change

Previous change

Last change

Prior change



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.



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 dougBuilding configuration...config-register 0x2username dougpassword 7 110D161010group root-systemgroup cisco-support

!username jeffpassword 7 1213001114

!no redundancy disablexml agent corbahttp serverend

Change # 168

Change # 165

Change # 164

Change # 167

Change # 166Change # 163/doug

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



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.



Display Rollback Information

RP/0/RP1/CPU0:P4#show config rollback changes last 1 Building configuration...username dougno group root-systemno group cisco-support!endRP/0/RP1/CPU0:P4#show config rollback changes last 2Building configuration...config-register 0x0username dougno group root-systemno group cisco-support!endRP/0/RP1/CPU0:P4#show config rollback changes last 3Building configuration...config-register 0x0username dougno group root-systemno group cisco-support!no redundancy disableend

•Display rollback changes (inclusive)

Previouschangeswould bereversed

•Display inclusive changes back to a certain commit change

RP/0/RP1/CPU0:P4#show config rollback changes to dougBuilding configuration...config-register 0x0no username dougusername dougno passwordno group root-systemno group cisco-support!no username jeffusername jeffno password!no redundancy disableend



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.



Roll Back Configurations

•Roll back to specific commitID

• Inclusive; undoes configurations up to and including specified commitID

RP/0/0/CPU0:P4#rollback configuration to 1000000169Loading Rollback Changes.Loaded Rollback Changes in 1 sec Committing.12 items committed in 1 sec (11)items/secUpdating.Updated Commit database in 1 sec Configuration successfully rolled back to '1000000169'.

•Roll back last number (n) of changes

RP/0/0/CPU0:P4#rollback configuration last 3Loading Rollback Changes.Loaded Rollback Changes in 1 sec Committing.6 items committed in 1 sec (5)items/secUpdating.Updated Commit database in 1 sec Configuration successfully rolled back 3 commits.



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.



Load a Specific Configuration

•Enter configuration mode

•Load a previously committed change

•Recommit the change

RP/0/0/CPU0:P4(config)#load commit changes 1000000169Building configuration...Loading.49 bytes parsed in 1 sec (48)bytes/sec

RP/0/0/CPU0:P4(config)#show configBuilding configuration...no username kenusername ken!end

RP/0/0/CPU0:P4(config)#commit



commit Command Keywords The commit command offers additional keywords to document the changes as they occur:

• 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



commit Command Keywords

•Available commit keywords:−Replace

♦ Replace entire running configuration with target configuration

−Comment♦ Add text information to the change♦ Shows up when looking at rollback details

−Label♦ Assigns a name to the change♦ Shows up when looking at the change

commit replace

commit comment <comment>

commit label <label>



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. _________________________________________________________________



commit Comments and Labels

RP/0/0/CPU0:P4(config)#hostname P4abcRP/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: NONEUserId: cisco Line: vty0Client: CLI Time: 14:07:35 UTC Wed May 25 2005Comment: rename from P4 label P4abc

RP/0/0/CPU0:P4#show config commit listSNo. Label/ID User Line Client Time Stamp~~~~ ~~~~~~~~ ~~~~ ~~~~ ~~~~~~ ~~~~~~~~~~1 1000000133 cisco vty0 CLI 14:07:35 UTC Wed May 25 2005

RP/0/0/CPU0:P4abc(config)#hostname P4hjkRP/0/0/CPU0:P4abc(config)#commit label renameP4hjkRP/0/0/CPU0:P4hjk#show config commit list 1 detail

1) CommitId: 1000000134 Label: renameP4hjkUserId: cisco Line: vty0Client: CLI Time: 14:19:50 UTC Wed May 25 2005Comment: NONE

RP/0/0/CPU0:P4#show config commit listSNo. Label/ID User Line Client Time Stamp~~~~ ~~~~~~~~ ~~~~ ~~~~ ~~~~~~ ~~~~~~~~~~1 renameP4hj cisco vty0 CLI 14:19:50 UTC Wed May 25 2005

RP/0/0/CPU0:P4hjk(config)#hostname P4RP/0/0/CPU0:P4hjk(config)#commit label renameP4 comment rename back to P4RP/0/0/CPU0:P4#show config commit list 1 detail

1) CommitId: 1000000135 Label: renameP4UserId: cisco Line: vty0Client: CLI Time: 14:20:48 UTC Wed May 25 2005Comment: rename back to P4

RP/0/0/CPU0:P4#show config commit listSNo. Label/ID User Line Client Time Stamp~~~~ ~~~~~~~~ ~~~~ ~~~~ ~~~~~~ ~~~~~~~~~~1 renameP4 cisco vty0 CLI 14:20:48 UTC Wed May 25 2005



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.



Configuration Sessions

•Manage configuration sessions−View

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

RP/0/0/CPU0:P4#show config sessionsSession Line User Date Lock00000201-037f00d4-00000000 vty3 doug Thu Mar 10 06:06:50 2005 00000201-037f10d5-00000000 vty2 cisco Thu Mar 10 06:07:10 2005

RP/0/0/CPU0:P4#clear config session 00000201-037eb0cf-00000000session ID '00000201-037eb0cf-00000000' terminated

•Manage configuration sessions−Delete



Miscellaneous CLI Commands

Storage Media Review

Cisco CRS-1 System

The following storage media is located on the Cisco CRS-1 System:

• 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)


Module 7 Miscellaneous CLI Commands

Storage Media Review

•Cisco CRS-1 Router−Disk0:−Disk1: (optional)−Harddisk:−NVRAM:−Bootflash:



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.



File Commands

• Many standard UNIX file commands

RP/0/0/CPU0:P4#dir disk0:

Directory of disk0:2 drwx 16384 Thu Mar 31 10:47:50 2005 LOST.DIR3 drwx 16384 Tue Apr 5 15:53:44 2005 shutdown4 drwx 16384 Tue Apr 26 21:02:15 2005 config32 dr-x 16384 Tue Apr 26 21:01:17 2005 aaa28 drwx 16384 Tue Apr 26 20:55:04 2005 c12k-os-mbi-3.2.831011 drwx 16384 Wed May 18 10:20:09 2005 instdb1013 drwx 16384 Tue Apr 26 20:57:58 2005 c12k-base-3.2.835773 drwx 16384 Tue Apr 26 20:58:14 2005 c12k-admin-3.2.836224 drwx 16384 Tue Apr 26 20:58:42 2005 c12k-fwdg-3.2.836777 drwx 16384 Tue Apr 26 20:59:14 2005 c12k-lc-3.2.837687 drwx 16384 Tue Apr 26 20:59:38 2005 c12k-rout-3.2.837852 drwx 16384 Wed May 25 09:38:31 2005 usr7853 drwx 16384 Thu Mar 31 10:59:56 2005 var7864 dr-x 16384 Tue Apr 5 16:00:42 2005 fping67168 -rwx 2940 Wed Apr 6 12:35:54 2005 sam_certdb67456 -rwx 126 Wed Apr 6 12:35:54 2005 sam_crldb9545 drwx 16384 Mon Apr 25 10:57:22 2005 tftp

1024442368 bytes total (876019712 bytes free)

RP/0/0/CPU0:P4#pwddisk0:/usr

•Display directory contents

RP/0/0/CPU0:P4#dir disk0:/config/running/commitdb

Directory of disk0:/config/running/commitdb

920736 -r-x 247 Wed May 25 15:32:40 2005 1000000137.snd920864 -r-x 80 Wed May 25 14:19:50 2005 1000000134.snd920960 -r-x 77 Wed May 25 14:20:48 2005 1000000135.snd921056 -r-x 125 Wed May 25 14:58:30 2005 1000000136.snd921408 -r-x 2142 Wed May 25 14:20:49 2005 commitdb_info_1000000135.snf921536 -r-x 2164 Wed May 25 14:58:30 2005 commitdb_info_1000000136.snf921664 -r-x 2192 Wed May 25 15:32:40 2005 commitdb_info_1000000137.snf

1024442368 bytes total (876019712 bytes free)



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



Save and Restore Configuration Files

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

RP/0/0/CPU0:P4#

RP/0/0/CPU0:P4#copy disk0:configtest1 running-configParsing.5286 bytes parsed in 1 sec (5259)bytes/secCommitting.............169 items committed in 13 sec (12)items/secUpdating...Updated Commit database in 3 sec

RP/0/0/CPU0:P4#

• Restoring a configuration file



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.



Redundancy Commands

•Display the current redundancy

RP/0/0/CPU0:P4#show redRedundancy information for node 0/0/CPU0:==========================================Node 0/0/CPU0 is in ACTIVE rolePartner node (0/1/CPU0) is in STANDBY roleStandby 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 agoActive node booted Mon Mar 7 06:22:03 2005: 3 days, 2 hours, 22 minutes agoStandby node boot Tue Mar 8 20:05:57 2005: 1 day, 12 hours, 38 minutes agoStandby node last went not ready Thu Mar 10 08:10:36 2005: 33 minutes agoStandby node last went ready Thu Mar 10 08:10:36 2005: 33 minutes agoThere have been 0 switch-overs since reload

•Use to switch over to standby RP (EXEC mode)

RP/0/0/CPU0:P4#redundancy switchoverUpdating Commit Database. Please wait...[OK]Proceed with switchover 0/0/CPU0 -> 0/1/CPU0?[confirm]Initiating switch-over.



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.



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.”



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.


Module 7 Process Management

Display Process Information

RP/0/0/CPU0:P4#show process ?<0-4294967295> job idWORD Name of the executableaborts Show process abortsall Show process data for all processesblocked Show detail for reply/send/mutex blocked processes.boot Show process boot infocpu Show CPU use per processdistribution Show distribution of processesdynamic Show process data for dynamically created processesfailover Show process failover infofamily Show process family information.files Show file and channel use per processlocation location to displaylog Show process logmandatory Show process data for mandatory processesmemory Show memory use per processsearchpath Show the search pathsignal Show signal use for processes.startup Show process data for processes created at startupthreadname Show thread names.



To display information about individual processes, use the show process process name command.

Some of the important information shown in the process display is:

• 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



Display Process Information (Cont.)

RP/0/RP0/CPU0:P4#show process ospf Job Id: 252

PID: 62304466Executable path: /disk0/hfr-rout-3.2.81/bin/ospf

Instance #: 1Version ID: 00.00.0000

Respawn: ONRespawn count: 1

Max. spawns per minute: 12Last started: Thu Mar 10 08:10:31 2005

Process state: RunPackage state: Normal

Started on config: cfg/gl/ipv4-ospf/proc/lab/ord_a/routeridcore: TEXT SHAREDMEM MAINMEM

Max. core: 0Placement: ON

startup_path: /pkg/startup/ospf.startupReady: 2.440s

Available: 6.444sProcess cpu time: 0.197 user, 0.105 kernel, 0.302 total

JID TID Stack pri state HR:MM:SS:MSEC NAME252 1 40K 10 Receive 0:00:00:0192 ospf252 2 40K 10 Receive 0:00:00:0001 ospf252 3 40K 10 Receive 0:00:00:0003 ospf--More--252 4 40K 10 Condvar 0:00:00:0001 ospf252 5 40K 10 Receive 0:00:00:0000 ospf



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.



Process Control

RP/0/0/CPU0:P4#process ?<0-4294967295> job idWORD Name of the executableblocked process blocked, capture statecrash crash a processmandatory set mandatory reboot settingsrestart restart a processshutdown kill/stop a processstart start a process

• Several choices for working with processes



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.



Process Restartability

Normal forwarding,OSPF, BGP

Stop BGP Start BGP

Normal forwarding,OSPF, BGP

Restarting of individual process does not affect other processes

Normal forwarding,

OSPF

Instructor's Note

This animated slide has 2 clicks: 1 – Stop sequence; 2 – Restart sequence



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.

_________________________________________________________________



Process Stop and Restart

RP/0/0/CPU0:P4#process shutdown ospf

RP/0/0/CPU0:P4#show process ospfJob Id: 252




Max. spawns per minute: 12Last started: Thu Mar 10 08:10:31 2005Process state: Killed (last exit status : 1)Package state: Normal

Registered item(s): cfg/gl/ipv4-ospf/proc/core: TEXT SHAREDMEM MAINMEM



Available: 6.444s

RP/0/0/CPU0:P4#process start ospf

RP/0/0/CPU0:P4#show process ospfJob Id: 252




Max. spawns per minute: 12Last started: Thu Mar 10 11:45:06 2005Process state: Run (last exit status : 1)Package state: Normal

Started on config: cfg/gl/ipv4-ospf/proc/lab/ord_a/routeridcore: TEXT SHAREDMEM MAINMEM



Available: 6.444sProcess cpu time: 0.177 user, 0.083 kernel, 0.260 total

JID TID Stack pri state HR:MM:SS:MSEC NAME252 1 40K 10 Receive 0:00:00:0175 ospf252 2 40K 10 Receive 0:00:00:0001 ospf252 3 40K 10 Receive 0:00:00:0001 ospf--More--252 4 40K 10 Condvar 0:00:00:0000 ospf252 5 40K 10 Receive 0:00:00:0000 ospf



Summary

Cisco IOS XR Operations In this module, you learned to:


• 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


Module 7

Review Questions

Cisco IOS XR Operations 1. <Insert Question>




























Module 8 Cisco IOS XR Installation

Overview

Description This module teaches you to select, prepare, install, activate, and deactivate Cisco IOS XR software packages.


• 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)


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:

• 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


Module 8 Cisco IOS XR Software Packaging

Cisco IOS XR Software Packages

OSKernel, file system, memory management, and other slow changing core components

BaseInterface manager, system database, checkpoint services,

configuration management, other slow-changing components

AdministrationResource management: rack, fabric, LR

ForwardingFIB, ARP, QoS, ACL, so on

ManageabilityORB, XML,

alarms management

MulticastPIM, MFIB, IGMP

MPLSMPLS, UCP

SecurityIPSec, encryption,

decryption

RoutingRIB, BGP, ISIS, OSPF, RPL

Line cardLine card drivers

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.



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. _________________________________________________________________



Modular Packaging and Upgrades

Mand.

OS-MBI

Admin

Base

SC

Mand.

MPLS Multi-cast

Opt'l

MSC or LC

OS-MBI

Base

Forwarding

Line card

Implementation locations

Mand.

Opt’l

DRP

Routing

MPLS Multi-cast

Manage-ability Security

OS-MBI

Base

Forwarding

Line card

MPLS Multi-cast

Manage-ability Security

Mand.

Opt’l

RP

OS-MBI

Base

Admin

Forwarding

Line card

Routing



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:

• 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



Package Installation Envelope (PIE)

Security

Package installation envelope (PIE)− Non-bootable files− Upgrade or add feature

packages − Example: hfr-mcast-p.pie-x.y.zManageability

OSPF

RPL

MPLS

ISIS

Multi-cast

BGP Routingpackage

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.



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.



Software Maintenance Upgrade

• Upgrade specific software

• Install just like a regular .pie file• Follow the same command

sequence to install

UpgradedISIS process 3

All other processesremain the sameISIS process n

ISIS process …

ISIS process …

ISIS process 3

ISIS process 2

ISIS process 1

ISIS software

ISIS process nISIS process ...

ISIS process ...

ISIS process 2

ISIS process 1

UpgradedISIS process 3

ISIS software

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.



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.



Composite Software Upgrade

•Most likely upgrade

3.0.0 core bundle 3.2.0 core bundle

OS-MBI

Base

Admin

Forwarding

Line card

Routing

OS-MBI

Base

Admin

Forwarding

Line card

Routing

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.



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.



Bootable Code

• Bootable entities− .vm files are bootable core OS− Shipped with new routers− Example: comp-hfr-mini.vm-x.y.z

Initial or emergency installation files

OS-MBI

Base

Admin

Forwarding

Line card

Routing

Instructor's Note

Bootable code versions should only used for emergency recoveries only!



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>



Software Versions

• Cisco CRS-1 router platform name: hfr

• Composite PIE examplescomp-hfr-mini.pie-3.2.83

• Single package PIE exampleshfr-mgbl-p.pie-3.2.83

• SMU examplec12k-base-3.2.83.CSCeg00654.pie

platform-package_type-major.minor.maintenance.ddts.pie

Single package SMU

comp-platform-composite_name.ddts.pieComposite SMU

platform-package_type–p.pie-major.minor.maintenance

Single package PIE

comp-platform-composite_name.pie-major.minor.maintenanceComposite PIE

Cisco CRS-1 Series RoutersSoftware delivery type



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.



Software Storage

CRS-1

Flashdisk1:

Flashdisk0:internal



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...

_________________________________________________________________



Setting the Router Clock

• Router clock should be correct

Router#clock update-calendar

Update the hardware clock

Router#clock set 17:24:23 30 June 2004

Set software system clock

Router#clock set 17:24:23 June 30 2004

or

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



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. _________________________________________________________________


Module 8 Package Management

Adding Packages to the Router

• Copy to disk1: using− TFTP− FTP− Remote Copy Protocol (RCP)− SSH File Transfer Protocol (SFTP)

• Install from disk1:OR

• Install directly using TFTP server

Disk0:

Disk1:

Direct add

TFTP, FTP,RCP, SFTP

Activate

Deactivate

AddCommit

Server



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.



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 operationsInstall: Starting install operation. Do not insert or remove cards until the operationcompletes.RP/0/0/CPU0:P4(admin)#Install: Now operating in asynchronous mode. Do not attempt subsequent install operationsuntil this operation is complete.Install 3: [ 0%] Install operation 'add /tftp://172.21.116.8/c12k-mcast.pie-3.2.85.3I todisk0:' assigned request id: 3Install 3: [ 1%] Downloading PIE file from /tftp://172.21.116.8/c12k-mcast.pie-3.2.85.3IInstall 3: [ 1%] Transferred 3298994 Bytes Install 3: [ 1%] Downloaded the package to the routerInstall 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.85Install 3: [100%] Please carefully follow the instructions in the release notes whenactivating any softwareInstall 3: [100%] Idle timeout on this line will now be resumed for synchronous installoperations

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



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.



install activate Command

RP/0/0/CPU0:P4(admin)#install activate disk0:c12k-mcast-3.2.85Install: The idle timeout on this line will be suspended for synchronous installoperationsInstall: 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 operationsuntil this operation is complete.Install 3: [ 0%] Install operation 'activate disk0:c12k-mcast-3.2.85' assigned request id: 3Install 3: [ 1%] Performing Inter-Package Card/Node/Scope Version Dependency ChecksInstall 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.85Install 3: [ 10%] Checking running configuration version compatibility with newly activated software..Install 3: [ 10%] No incompatibilities found between the activated software and router runningconfiguration.

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 changeInstall 3: [100%] Activation operation successful.Install 3: [100%] NOTE: The changes made to software configurations will not beInstall 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 synchronousinstall 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 “mini-pie”

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.



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.



Install commit Command

•New software is activated across reloads

RP/0/0/CPU0:P5(admin)#install commit Install: The idle timeout on this line will be suspended for synchronousinstall operationsInstall 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 forsynchronous operations

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



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.



Deactivating Packages

• Package features no longer available• Package still installed• Package can be reactivated

RP/0/0/CPU0:P5(admin)#install deactivate disk0:c12k-rp-mgbl-3.2.85Install: The idle timeout on this line will be suspended for synchronous installoperationsInstall: Starting install operation. Do not insert or remove cards until the operationcompletes.RP/0/0/CPU0:P5(admin)#Install: Now operating in asynchronous mode. Do not attempt subsequent install operationsuntil this operation is complete.Install 8: [ 0%] Install operation 'deactivate disk0:c12k-mgbl-3.2.85' assignedrequest id: 8Install 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 synchronousinstall operations

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.



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. _________________________________________________________________



Package Removal

• Deactivate package first• install commit required• Test option

RP/0/0/CPU0:P5(admin)#install remove disk0:c12k-mgbl-3.2.85Install: The idle timeout on this line will be suspended for synchronous installoperationsInstall: Starting install operation. Do not insert or remove cards until the operationcompletes.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 synchronousinstall operations

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.



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 _________________________________________________________________



install rollback Command

RP/0/0/CPU0:P5(admin)#install rollback 2

Install: The idle timeout on this line will be suspended for synchronous installoperationsInstall: Starting install operation. Do not insert or remove cards until the operationcompletes.RP/0/0/CPU0:P5(admin)#Install: Now operating in asynchronous mode. Do not attempt subsequent install operationsuntil this operation is complete.Install 11: [ 0%] Install operation 'rollback 2' assigned request id: 11Install 11: [ 10%] Updating software configurations.Install 11: [ 10%] RP:Install 11: [ 10%] Activating c12k-admin-3.2.83Install 11: [ 10%] Activating c12k-base-3.2.83

Install 11: [ 10%] Activating mprp-rp__boot-3.2.83Install 11: [ 10%] Deactivating c12k-admin-3.2.85Install 11: [ 10%] Deactivating c12k-base-3.2.85

Install 11: [ 10%] Deactivating mprp-rp__boot-3.2.85Install 11: [ 10%] Change boot image to /disk0/c12k-os-mbi-3.2.83/mbiprp-rp.vm

• Committed software• Non-committed software



Rolling back to this version

Rolling back from this version

Install 11: [ 10%] Checking running configuration version compatibility with newly activated software ...Install 11: [ 10%] No incompatibilities found between the activated software androuter running configuration.Install 11: [ 10%] Node 0/0/CPU0: *** Will be reloaded ***Install 11: [ 10%] Node 0/1/CPU0: *** Will be reloaded ***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 nodesInstall 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 changeP/0/0/CPU0:Jun 2 06:12:28.632 : instdir[182]: %INSTALL-INSTMGR-6-SOFTWARE_CHANGE_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

Note reload



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.



SMU Installation and Activation

RP/0/0/CPU0:P5(admin)#install add tftp://223.255.254.254/c12k-mgbl-3.2.83.CSCeg00302.pieto disk0: activateInstall: The idle timeout on this line will be suspended for synchronous installoperationsInstall: Starting install operation. Do not insert or remove cards until theoperation completes.RP/0/0/CPU0:P5(admin)#Install: Now operating in asynchronous mode. Do not attempt subsequent installoperations until this operation is complete.Install 1: [ 0%] Install operation 'add tftp://223.255.254.254/c12k-mgbl-3.2.83.CSCeg00302.pieto disk0:' assigned request id: 1Install 1: [ 1%] Downloaded the package to the routerInstall 1: [ 1%] Verifying the package

Install 3: [ 0%] Install operation 'activate disk0:c12k-mgbl-3.2.83.CSCeg00302.pie' assignedrequest id: 3Install 3: [100%] Activation operation successful.Install 3: [100%] NOTE: The changes made to software configurations will not beInstall 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 synchronousinstall operations

• Single step for add and activate

Refer to the install activate command messages

Refer to the install add command messages



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.


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, incompatibilities 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.85More 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



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.



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.1iDownloaded the package to the routerVerifying 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 activate

disk0:hfr-mpls-3.2.83Please carefully follow the instructions in the release noteswhen activating any software

•Example of adding software to router

d:

RP/0/0/CPU0:P5(admin)#show install log 3Request id 3 by cisco at Wed Mar 02 15:53:52 2005:

1 package activated: disk0:c12k-mgbl-3.2.83Summary:

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_showAdding and starting process: pm_collectorAdding and starting process: snmppingdAdding executable: xml_tty_clientAdding and starting process: xmlagentAdding file: sh_ciscosensormib_ns_cfg__api.configinfoAdding DLL: libxmlalarmerror.dllReplacing 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



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.



Display Active Software

RP/0/0/CPU0:P5#show install activeNode 0/0/CPU0 [RP]

Boot Image: /disk0/c12k-os-mbi-3.2.83/mbiprp-rp.vmActive Packages:

disk0:c12k-mini-3.2.83

Node 0/1/CPU0 [RP]Boot Image: /disk0/c12k-os-mbi-3.2.83/mbiprp-rp.vmActive Packages:


Node 0/3/CPU0 [LC(E3-OC3-POS-4)]Boot Image: /disk0/c12k-os-mbi-3.2.83/gsr/ucode/mbiprp-lc.ucodeActive Packages:


Node 0/4/CPU0 [LC(E3-OC48-POS)]Boot Image: /disk0/c12k-os-mbi-3.2.83/gsr/ucode/mbiprp-lc.ucodeActive Packages:




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.



Display Active Package Details

RP/0/0/CPU0:P5#show install active detailNode 0/0/CPU0 [RP]

Boot Image: /disk0/c12k-os-mbi-3.2.83/mbiprp-rp.vmActive Packages: disk0:c12k-mini-3.2.83disk0:c12k-rout-3.2.83disk0:c12k-lc-3.2.83disk0:c12k-fwdg-3.2.83disk0:c12k-admin-3.2.83disk0:c12k-base-3.2.83disk0:c12k-os-mbi-3.2.83

Node 0/1/CPU0 [RP]Boot Image: /disk0/c12k-os-mbi-3.2.83/mbiprp-rp.vmActive Packages: disk0:c12k-mini-3.2.83disk0:c12k-rout-3.2.83disk0:c12k-lc-3.2.83disk0:c12k-fwdg-3.2.83disk0:c12k-admin-3.2.83disk0:c12k-base-3.2.83disk0: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.ucodeActive Packages: disk0:c12k-mini-3.2.83disk0:c12k-lc-3.2.83disk0:c12k-fwdg-3.2.83disk0:c12k-admin-3.2.83disk0:c12k-base-3.2.83disk0:c12k-os-mbi-3.2.83

Minimum boot imageCore bundle



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.



Other Display Commands

RP/0/0/CPU0:P5#show install ?active Show active package informationall Show information for all locationscommitted Show the committed package informationdetail Show information about constituent packageinactive Show active package informationlocation Show information for a specific locationlog Show log filepackage Name of the packagepie-info Show information in a PIE filerequests Show current requestsrollback Show package information for a rollback pointwhich Show the origin of a named process, component or package| Output Modifiers<cr>

•General and specific information available



Summary

Cisco IOS XR Installation In this module, you learned 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)


Module 8

Review Questions

Cisco IOS XR Installation 1. <Insert Question>




























© 2005 Cisco Systems, Inc. Version 1.0c 9–1

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.


• 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.

Cisco IOS XR Security Module 9

9–2 Version 1.0c Cisco CRS-1 Essentials

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.

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



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.



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



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.




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



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.




•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



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.

Module 9 Cisco IOS XR Security Implementation


AAA Implementation Planes

Administration (Admin) plane

Logical router (LR) plane

ADMIN

LR

AAA

Single physical router



Prerequisites for Security Implementation For a router security implementation, there are prerequisites, some of which are configured by default in Cisco IOS XR software.

• 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.



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



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.



Authorization

• Cisco predefined task groups

• Custom-defined task groups

• Hierarchically structured groups

• Re-use of task groups

Task groups

• 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

Task identifiers

Security policy



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 command-line 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.



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.



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.



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



Authentication Authentication is accomplished by comparing the user ID and the user-provided 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 root-system 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.



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



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.



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



Predefined User Group Permissions Cisco IOS XR software provides these user groups with predefined attributes.

• 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 root-system 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 root-system 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.



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



Users Cisco IOS XR software attributes forms the basis of router user access. Each router user is associated with the following:

• 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



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



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. _________________________________________________________________



Local AAA and Database

•Users, user groups, and task groups are stored in a local database (SysDB)

Authentication, authorization, and accounting (AAA)



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.



Remote AAA

CLI

HTTP

XMLagents

AAA clientlibrary

AAAserver

TACACSD

RADIUSD

ExternalAAAserver

AAA subsystem IPnetwork

TACACSD – TACACS daemonRADIUSD – RADIUS client subsystem



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).



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



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.



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



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.



Authentication Flow of Control

User requests authentication by providing ausername and password

1

•Authentication method list determined•AAA source of data consulted

2

•AAA verifies user password •AAA rejects user if password does not matchdatabase

3

Authentication verifies the user identity

Authorization verifies the user permissions



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.



Security Implementation Flow (Cont.)

AAA determines the role of the user (root-system user, root-lr owner, or LR user)

4

Authorization verifies the user permissions

Accounting collects and stores access information

AAA information about the user(identity, start/stop times, commands executed)

5



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 attribute-value (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.



Accounting

RP/0/0/CPU0:POD5(config)#aaa accounting ?commands . . . . . . . For EXEC (shell) commandsexec . . . . . . . . . For starting an EXEC (shell) system . . . . . . . .For System events

RP/0/0/CPU0:POD5(config)#aaa accounting commands ?word Named accounting listdefault Default accounting list

RP/0/0/CPU0:POD5(config)#aaa accounting commands cisco ?start-stop start and stop recordsstop-only stop records only

Accountingdatabase



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.

Module 9 Security Configuration


Site-Defined Groups and Users

Configuration flow

User• Name• Password• List of user

groups

User group (UG)• Name• Inheritance of

TG permissions • Taskgroup

associations

Task group (TG)• Name• Task ID associations− Read, write, so on

• Inheritance of otherTG permissions



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.



Commands and Task IDs

• Description command provides task ID informationRP/0/0/CPU0:P4#describe admin install commitThe command is defined in instmgr_cmds.parser

Node 0/RP0/CPU0 has file instmgr_cmds.parser for boot package /disk0/hfr-os-mbiePackage:

hfr-basehfr-base V3.2.0 Base PackageVendor : Cisco SystemsDesc : Base PackageBuild : Built on Sun Feb 13 19:06:35 PST 2005Source : 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

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

Required toinstall

software

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



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.



Creating Task Groups

Configure “taskgroup bgpadmin”

Inherit other task group rights (“bgpadmin” can do OSPF configs)

RP/0/RP0/CPU0:POD5#configureRP/0/RP0/CPU0:POD5(config)#taskgroup bgpadmin

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

Assign task permissions

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

RP/0/RP0/CPU0:POD5(config-tg)#commitRP/0/RP0/CPU0:POD5(config-tg)#

Commit the changes



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.



Verifying Task Group Configuration

RP/0/0/CPU0:P5#sho aaa taskgroup igpadminTask 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 setof task IDs (including all inherited groups):

Task: isis : READ WRITE Task: ospf : READ WRITE Task: rib : READ WRITE



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.



Creating User Groups

Configure “usergroup routeadmin”

Assign “usergroup” to a “taskgroup”

RP/0/RP0/CPU0:POD5#configureRP/0/RP0/CPU0:POD5(config)#usergroup routeadmin

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

RP/0/RP0/CPU0:POD5(config-ug)#commitRP/0/RP0/CPU0:POD5(config-ug)#

Commit the changes



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.



Verifying User Group Configuration

RP/0/0/CPU0:POD5#show aaa usergroupUser group 'routeadmin'contains task group 'bgpadmin'



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.



Configuring Users

Assign the user to a usergroup

RP/0/RP0/CPU0:POD5#configureRP/0/RP0/CPU0:POD5(config)#username ken

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

RP/0/RP0/CPU0:POD5(config-un)#commitRP/0/RP0/CPU0:POD5(config-un)#

Commit the changes

Configure a user

RP/0/RP0/CPU0:POD5(config-un)#password drowssap57RP/0/RP0/CPU0:POD5(config-un)#

Assign a password

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.



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.



Verifying User Configuration

Display all users

RP/0/0/CPU0:POD5#show aaa userdbUsername kenUser group routeadmin

Username ciscoUser group root-system

RP/0/0/CPU0:POD5#show aaa userdb kenUsername: ken

User group routeadminTask: bgp : READ WRITE EXECUTETask: ospf : READ WRITE EXECUTE

Display a specific user

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.



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).

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



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.



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



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.



Creating ACLs and Applying to an Interface

RP/0/RP0/CPU0:POD5#confRP/0/RP0/CPU0:POD5(config)#ipv4 access-list ciscoRP/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.255RP/0/RP0/CPU0:POD5(config-ipv4-acl)#commitRP/0/RP0/CPU0:POD5(config-ipv4-acl)#exit

RP/0/RP0/CPU0:POD5(config)#interface POS 0/4/0/0RP/0/RP0/CPU0:POD5(config-if)#ipv4 access-group cisco inRP/0/RP0/CPU0:POD5(config-if)#commit



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



Editing ACLs

• Sample ACL

RP/0/0/0:RP-POD1(config-ipv4-acl)#3 deny udp any eq netbios-dgm any

RP/0/RP0/CPU0:POD5#show ipv4 access-list Ethernet_Inipv4 access-list Ethernet_In

1 deny udp any eq netbios-ns any2 deny udp any host 255.255.255.255 eq tftp4 permit any

•Add a line

RP/0/RP0/CPU0:POD5#show ipv4 access-list Ethernet_Inipv4 access-list Ethernet_In

1 deny udp any eq netbios-ns any2 deny udp any host 255.255.255.255 eq tftp3 deny udp any eq netbios-dgm any 4 permit any

•Modified sample ACL

• Sample ACL

RP/0/0/0:RP-POD1(config-ipv4-acl)#no 3

RP/0/RP0/CPU0:POD5#show access-list ipv4 Ethernet_Inipv4 access-list Ethernet_In



1 deny udp any eq netbios-ns any2 deny udp any host 255.255.255.255 eq tftp3 deny udp any eq netbios-dgm any 4 permit any

•Remove a line

•Modified sample ACL



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.



Resequencing ACLs

• Sample ACL

• Resequence the ACL

• Modified sample ACL



RP/0/RP0/CPU0:POD5#show access-list ipv4 Ethernet_Inipv4 access-list Ethernet_In10 deny udp any eq netbios-ns any20 deny udp any host 255.255.255.255 eq tftp30 permit any

RP/0/RP0/CPU0:POD5#resequence access-list ipv4 Ethernet_In

Instructor's Note

This is an EXEC level command. This command will create a rollback file with the ACL as the client.



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.



Copying ACLs

RP/0/RP0/CPU0:POD5#copy access-list ipv4 pod5 pod5copy



Summary

Cisco IOS XR Security In this module, you learned to:

• 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)

Module 9


Review Questions

Cisco IOS XR Security 1. <Insert Question>



























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.


• 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)



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 Peer-groups.



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



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.



CLI Differences

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

router bgp

neighbor

address-family

address-family neighbor-group

session-groupaf-group

address-family

Hierarchical BGP configuration with explicit inheritance

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.



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.



neighbor Command

router(config-router)# neighbor 10.222.1.1 remote-as 100

router(config-router)# neighbor 10.222.1.1 update-source Loopback0

RP/0/RP0/CPU0:router(config)# router bgp 65000


RP/0/RP0/CPU0:router(config-bgp-nbr)# remote-as 100

RP/0/RP0/CPU0:router(config-bgp-nbr)# update-source Loopback0

Cisco IOS

Cisco IOS XR



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.



neighbor-group (peer-group) Command

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

RP/0/RP0/CPU0:router(config-bgp)# neighbor-group group_1

RP/0/RP0/CPU0:router(config-bgp-nbrgrp)# remote-as 64500

RP/0/RP0/CPU0:router(config-bgp-nbrgrp)# update-source loopback0

RP/0/RP0/CPU0:router(config-bgp-nbrgrp)# exit


RP/0/RP0/CPU0:router(config-bgp-nbr)# use neighbor-group group_1

Cisco IOS

Cisco IOS XR

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.



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.



address-family Command

address-family {ipv4 | ipv6} {unicast | multicast}

router(config-bgp)#

RP/0/RP0/CPU0:router(config)# router bgp 65000RP/0/RP0/CPU0:router(config-bgp)# address-family ipv4 unicastRP/0/RP0/CPU0:router(config-bgp-af)# network 10.0.0.0/8RP/0/RP0/CPU0:router(config-bgp-af)# exitRP/0/RP0/CPU0:router(config-bgp)# neighbor 10.1.1.1RP/0/RP0/CPU0:router(config-bgp-nbr)# remote-as 64500RP/0/RP0/CPU0:router(config-bgp-nbr)# address-family ipv4 unicastRP/0/RP0/CPU0:router(config-bgp-nbr-af)# weight 200

router(config-bgp-nbr)#



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.



Configuration Example

P3142.50.12 .1

.3

.3

.2

142.50.20

100.10.20.3 100.10.20.1

100.10.20.2

POS 0/4/0/0POS 0/3/0/1

P1

P2

interface Loopback0ipv4 address 100.10.20.3 255.255.255.255



!router bgp 65000address-family ipv4 unicast!neighbor-group internalremote-as 65000password encrypted 121A0C041104update-source Loopback0address-family ipv4 unicast!

!neighbor 100.10.20.1use neighbor-group internaldescription P1 router

!neighbor 100.10.20.2use neighbor-group internaldescription P2 router

!!



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 <ip-address> 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.



show Commands

RP/0/0/CPU0:P3# show bgp neighbors 100.10.20.1 configurationneighbor 100.10.20.1remote-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 inheritanceSession: n:internalIPv4 Unicast: n:internal

Effective neighbor configuration and inheritance

RP/0/0/CPU0:P3# show bgp summaryBGP router identifier 100.10.20.3, local AS number 65000BGP generic scan interval 60 secsBGP main routing table version 1BGP scan interval 60 secsBGP is operating in STANDALONE mode.

Process RecvTblVer bRIB/RIB SendTblVerSpeaker 1 1 1

Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd100.10.20.1 0 65000 2607 2608 1 0 0 1d19h 0100.10.20.2 0 65000 2600 2600 1 0 0 1d19h 0

Summary of BGP and neighbor status



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 auto-summarization 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 always-compare 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.



Cisco IOS and IOS XR Comparison

Only deterministic behavior is supported

no bgp deterministic-medwas the default

Select the best MED path among paths advertised from the neighboring AS.

Cisco IOS XRCisco IOSDescription

bgp client-to-client reflectionis the default

bgp client-to-client reflection is the default

Restore route reflection from a BGP route reflector to clients.

bgp bestpath med always is used

bgp always-compare-med is used

Allow the comparison of MED for paths from neighbors in different autonomous systems.

Automatic summarization is not supported

auto-summary was the default

Automatically summarize subnet routes into classfullnetwork (A, B, or C) routes when advertising outside AS.



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 prefix-list in command for use with ORF is one exception.



Cisco IOS and IOS XR Comparison (continued)


Distribute-list is not supported; use prefix-list {name|number} in for ORF capability or policy {name} in|out in general case

Use neighbor {ip-address | peer-group-name} distribute-list {access-list-number | name} {in|out}

Filter BGP route information as specified in an access-list.

Community is always displayed in aa:nn format

no ip bgp new-format is the default; community is displayed as 32 bit value

Display the BGP community as two 16-bit values in aa:nnformat.

no default-metric is the defaultno default-metric is the default

Set the default MED value to advertise to peers for routes without an existing MED attribute.

bgp log neighbor changes is the default

no bgp log-neighbor-changes is the default

Log the neighbor up, down, or reset reason.



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.



Cisco IOS and IOS XR Comparison (continued)


Synchronization is not supported

synchronization was the default

Enable synchronization between BGP and your IGP.

Effectively replaced by show bgp update-group

Use show ip bgp peer-group {peer-group-name}

Display BGP peer-group information.

Only BGP version 4 is supported; no dynamic negotiation

neighbor {ip-address | peer-group-name} version {value}; dynamic negotiation is the default

Configure BGP to peer using only a specific version.

no-send-community-ebgp and no-send-extended-community-ebgp are the default; always send to IBGP neighbors

no neighbor {ip-address | peer-group-name} send-community is the default

Specify that community attributes should be sent to a BGP neighbor.



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.



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”



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.



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

Speaker

Speaker

bRIB RIB

Peers

PeersPartial

bestpaths

Partial bestpaths

Final bestpaths

Final bestpaths



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.


Module 10 Open Shortest Path First (OSPF)

Feature Support

BBone

Internal

Area 4Stub

Area 1

Area 0Backbone

Standard OSPFv2 and OSPFv3

Area 2

Internal

Internal

ABR

ABR ABR

Area 3NSSA

ABRVirtualLink

Passive

Internal

ASBR

IS-ISBGPStatic



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.



CLI Differences

Hierarchical OSPF configuration with inheritance

router ospf

area

interface virtual-link

OSPF configuration parameters are grouped at levels under the router (process) instancerouter 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 levelsRP/0/RP0/CPU0:router(config-ospf)# hello-interval 40

(specified here at process level and inherited by OSPF interfaces)



Configuration Differences The key differences in OSPF configuration commands between Cisco IOS and Cisco IOS XR are:

• 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-to-point 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.



Configuration Differences

RP/0/RP0/CPU0:router(config)# interface pos0/4/0/0RP/0/RP0/CPU0:router(config-if)# ip address 10.1.1.1 255.255.255.252RP/0/RP0/CPU0:router(config-if)# exitRP/0/RP0/CPU0:router(config)# interface pos0/4/0/1RP/0/RP0/CPU0:router(config-if)# ip address 10.1.1.5 255.255.255.252RP/0/RP0/CPU0:router(config-if)# exit!RP/0/RP0/CPU0:router(config)# router ospf 1RP/0/RP0/CPU0:router(config-ospf)# area 0RP/0/RP0/CPU0:router(config-ospf-ar)# cost 20RP/0/RP0/CPU0:router(config-ospf-ar)# interface pos0/4/0/0RP/0/RP0/CPU0:router(config-ospf-ar-if)# exitRP/0/RP0/CPU0:router(config-ospf-ar)# interface pos0/4/0/1RP/0/RP0/CPU0:router(config-ospf-ar-if)# cost 40

Cisco IOS XR

Router(config)# interface pos0/0/0Router(config-if)# ip address 10.1.1.1 255.255.255.252Router(config-if)# ip ospf cost 20Router(config-if)# exitRouter(config)# interface pos0/0/1Router(config-if)# ip address 10.1.1.5 255.255.255.252Router(config-if)# ip ospf cost 40Router(config-if)# exit!Router(config)# router ospf 1Router(config-router)# network 10.1.1.0 0.0.0.255 area 0

Cisco IOS

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.



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:

• 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 post-FCS.



Differences for OSPFv3

Router(config)# interface pos0/0/0Router(config-if)# ipv6 address 2002:1234::212/64Router(config-if)# ipv6 ospf 1 area 0Router(config-if)# ipv6 ospf cost 20Router(config-if)# exit!Router(config)# ipv6 router ospf 1Router(config-router)# router-id 1.2.3.4

Cisco IOS configuration

RP/0/RP0/CPU0:router(config)# interface pos0/4/0/1RP/0/RP0/CPU0:router(config-if)# ipv6 address 2002:1234::212/64RP/0/RP0/CPU0:router(config-if)# exit!RP/0/RP0/CPU0:router(config)# router ospfv3 1RP/0/RP0/CPU0:router(config-ospf)# router-id 1.2.3.4RP/0/RP0/CPU0:router(config-ospf)# area 0RP/0/RP0/CPU0:router(config-ospf-ar)# interface pos0/4/0/1RP/0/RP0/CPU0:router(config-ospf-ar-if)# cost 20

Cisco IOS XR configuration



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. _________________________________________________________________



Configuring OSPF—router ospf Command

RP/0/RP0/CPU0:router(config)# router ospf 1

router ospf instance-name

RP/0/RP0/CPU0:router(config)# router ospfv3 1

router ospfv3 instance-name

or

router (config) #

Step 1—Configure OSPF instance (process)



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. _________________________________________________________________



Configuring OSPF—router-id and area Commands

RP/0/RP0/CPU0:router(config-ospf)# router-id 172.20.10.10

router-id {ipv4-address | interface-type interface-number}

RP/0/RP0/CPU0:router(config-ospf)# area 0

area area-id

router (config-ospf)#

Step 3—Configure OSPF area

Step 2—Optionally configure the OSPF router id



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 interface-specific 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.



Configuring OSPF—interface Command

Repeat step 4 for each interface in this OSPF area

RP/0/RP0/CPU0:router(config-ospf-ar)# interface POS 0/4/0/1

interface interface-type interface-number

Step 4—Configure OSPF interface in area submode

router (config-ospf-ar)#

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.



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.



Configuring OSPF—Interface-level Command Example

RP/RO0/0/CPU0:router(config-ospf-ar-if)# dead-interval 40

dead-interval seconds

router (config-ospf-ar-if)#

Step 5—Configure OSPF interface parameters in the interface submode



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). _________________________________________________________________



MD5 Authentication

RP/0/RP0/CPU0:router(config-ospf)# authentication message-digest

authentication [message-digest | null]


RP/0/RP0/CPU0:router(config-ospf)# message-digest-key 4 md5 key1

message-digest-key key-id md5 [encryption-type] key




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.



MD5 Configuration Comparison

Cisco IOS OSPFCisco IOS OSPF

interface Loopback1ip address 10.234.2.6 255.255.255.255

!interface POS4/0ip address 10.50.40.1 255.255.255.0ip ospf message-digest-key 5 md5ospf-key

!router ospf 100log-adjacency-changes detailnsfarea 0 authentication message-digestpassive-interface Loopback1network 10.50.40.0 0.0.0.255 area 0network 10.234.2.6 0.0.0.0 area 0

Cisco IOS XR OSPFCisco IOS XR OSPF

interface Loopback1ip address 10.234.2.6 255.255.255.255

!interface POS0/4/0/0ip address 10.50.40.1 255.255.255.0

!router ospf 100log adjacency changes detailnsfarea 0authentication message-digestinterface Loopback1

passive enableinterface POS0/4/0/0

message-digest-key 5 md5 ospf-key



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:

• 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.


Module 10 Intermediate System-Intermediate System (IS-IS)


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.



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.



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 labRP/0/RP0/CPU0:router(config-isis)# is-type level-1-2RP/0/RP0/CPU0:router(config-isis)# address-family ipv4 unicastRP/0/RP0/CPU0:router(config-isis-af)# distance 100RP/0/RP0/CPU0:router(config-isis-af)# exitRP/0/RP0/CPU0:router(config-isis)# interface POS0/4/0/0RP/0/RP0/CPU0:router(config-isis-if)# hello-interval 5 level 1RP/0/RP0/CPU0:router(config-isis-if)# address-family ipv4 unicastRP/0/RP0/CPU0:router(config-isis-if-af)# metric 7



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.



Multiple Instance Example

Level 1 Area 49.0002 Level 1 Area 49.0001

Level 2 Area 49.0003

1 Level 2 instance2 Level 1 instances



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.



Multiple Instance Example (continued)

RP/0/RP0/CPU0:router# show running router isisrouter isis r1is-type level-1 net 49.0001.0000.0000.0001.00address-family ipv4 unicastset-attached-bit!interface POS0/4/0/0address-family ipv4 unicast!!interface POS0/4/0/1address-family ipv4 unicast!!

!--More--

router isis r2is-type level-1 net 49.0002.0000.0000.0002.00address-family ipv4 unicastset-attached-bit! interface POS0/4/0/2address-family ipv4 unicast!!

! router isis r3is-type level-2-only net 49.0003.0000.0000.0003.00address-family ipv4 unicastredistribute isis r1 level-2 metric 0 metric-type internalredistribute isis r2 level-2 metric 0 metric-type internaldistance 116! interface POS0/4/0/3address-family ipv4 unicast!!

!



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.



Other Configuration Examples

RP/0/RP0/CPU0:router(config)# router isis labRP/0/RP0/CPU0:router(config-isis)# address-family ipv4RP/0/RP0/CPU0:router(config-isis-af)# distance 10

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.255RP/0/RP0/CPU0:router(config)# router isis labRP/0/RP0/CPU0:router(config-isis)# is-type level-1-2RP/0/RP0/CPU0:router(config-isis)# address-family ipv4RP/0/RP0/CPU0:router(config-isis-af)# propagate level 2 into level 1 distribute-list L21

Setting instance-wide address family specific values

Propagating (leaking) routes from Level 2 into Level 1



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.



Configuration Comparison

Cisco IOS ISCisco IOS IS--IS:IS:interface Loopback0ip address 10.234.1.6 255.255.255.255ip router isis hfr!router isis hfrpassive-interface Loopback0net 49.1111.1111.0001.0000.0c00.0006.00metric-style wide

Cisco IOS XR ISCisco IOS XR IS--IS:IS:router isis hfrnet 49.1111.1111.0001.0000.0c00.0006.00address-family ipv4 unicastmetric-style wide!interface Loopback0passiveaddress-family ipv4 unicast!

!

Cisco IOS ISCisco IOS IS--IS:IS:interface POS4/0ip address 10.50.40.1 255.255.255.0ip router isis hfr!router isis hfrnet 49.1111.1111.0001.0000.0c00.0006.00domain-password domainpw authenticate snp validatearea-password areapw authenticate snp validatelog-adjacency-changesnsf ietf

Cisco IOS XR ISCisco IOS XR IS--IS:IS:router isis hfrnet 49.1111.1111.0001.0000.0c00.0006.00nsf ietflog adjacency changeslsp-password areapw level 1lsp-password domainpw level 2interface POS0/4/0/0address-family ipv4 unicast!

!



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.



Debugging

RP/0/RP0/CPU0:router# debug isis ?adjacencies Maintenance of adjacencies including the sending and receiving of

hello packetsconfiguration Configuration, including interface eventsdis-elections Designated IS Elections on LAN interfacesinstance Filter IS-IS debug by instancelocal-updates Generation of local system and pseudo-node LSPsmpls MPLS Traffic Engineering Informationpacket-errors Format, checksum and authentication errors in received packets route Maintenance of IS-IS's local routing tablespf Route calculations, including incremental SPFs and PRCsstartup 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 generationinterface Filter IS-IS debug by interfacelevel Filter IS-IS debug by levellsp-id Filter IS-IS debug by LSP IDrestarts Processing of neighbors' restart requestssummary Adjacency state changes onlytopology Filter IS-IS debug by topology<cr>

RP/0/RP0/CPU0:POD2# debug isis adjacenciesAug 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 following debug shows an interface flap on a point-to-point network

The same debug shows a new adjacency formed on a broadcast network

RP/0/RP0/CPU0:router# debug isis adjacenciesSLOT2: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 UpSLOT2: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 UpSLOT2:Jan 8 15:14:44.983 :isis[137]: New level 1 DR router-gsr6 on MgmtEth0/0/CPU0/0



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.


Module 10 Multicast Routing


Hierarchical configuration• Specific router protocol modes• Interfaces must be explicitly enabled

IGMP• Defaults to Version 3

PIM• No dense mode configuration• No rate mechanism for switching to Shortest Path Tree

MSDP• Initiates Source Active messages

IPv4 and IPv6 multicast on CRS-1 at Release 3.2

Instructor's Note

PIM dense mode operation is actually supported for 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.



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.



CLI Differences

Values for certain parameters specified at router process level are inherited by lower level

RP/0/RP0/CPU0:router(config)# router pimRP/0/RP0/CPU0:router(config-pim-ipv4)# hello-interval 420RP/0/RP0/CPU0:router(config-pim-ipv4)# interface POS0/4/0/0RP/0/RP0/CPU0:router(config-pim-ipv4-if)# hello-interval 210

multicast-routing

interface

Hierarchical multicast configuration with inheritance

router igmp

interface

router pim

interface

router msdp

peer



Configuring Multicast To configure multicast routing in Cisco IOS XR, first use the multicast-routing 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. _________________________________________________________________



Configuring Multicast

RP/0/RP0/CPU0:router(config)# multicast-routing

Configure IPv4 multicast routing

RP/0/0/CPU0:router(config)#

RP/0/RP0/CPU0:router(config-mcast-ipv4)# interface all enable

Enable all interfaces to take part in multicast

RP/0/0/CPU0:router(config-mcast-ipv4)#

RP/0/RP0/CPU0:router(config-mcast-ipv4)# interface POS0/4/0/0

RP/0/RP0/CPU0:router(config-mcast-ipv4-if)# disable

Disable a specific interface from taking part in multicast

RP/0/0/CPU0:router(config-mcast-ipv4)#



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.



PIM Configuration

RP/0/RP0/CPU0:router(config)# router pim

Configure PIM-specific behavior

RP/0/0/CPU0:router(config)#

RP/0/RP0/CPU0:router(config-pim-ipv4)# rp-address 1.1.1.1

Configure the RP address—use the loopback address

RP/0/0/CPU0:router(config-pim-ipv4)#

Make sure loopback is advertised by IGP



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 well-known 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.



PIM Configuration (continued)

RP/0/RP0/CPU0:router(config-pim-ipv4)# auto-rp candidate-rploopback 0 scope 16

RP/0/RP0/CPU0:router(config-pim-ipv4)# auto-rp mapping-agentloopback 0 scope 16

Configure PIM auto-RP candidate RP and mapping agent as necessary


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

Configure any PIM interface-specific parameters


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.




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.




PIM Configuration:interface POS4/0ip pim sparse-mode

!ip pim rp-address 1.1.1.1ip pim send-rp-announce loopback0scope 16

ip pim send-rp-discovery loopback0scope 16

Enable Multicast:interface POS4/0ip multicast-routing

Cisco IOS

Enable Multicast:multicast-routing

interface POS0/4/0/0enable

PIM Configuration:router pim address-family ipv4

rp-address 1.1.1.1auto-rp candidate-rp loopback 0scope 16

auto-rp mapping-agent loopback 0scope 16

Cisco IOS XR

IGMP Configuration:router igmp

interface POS0/4/0/0version 3

MSDP Configuration:router msdp

peer 10.39.9.6sa-filter in list 111sa-filter out list 111

Cisco IOS XR

IGMP Configuration:interface POS4/0

ip igmp version 3

Cisco IOS

MSDP Configuration:ip msdp peer 10.39.9.6ip msdp sa-filter in 10.39.9.6 list 111ip msdp sa-filter out 10.39.9.6 list 111



Summary

Routing Protocols In this module, you learned:

• 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


Module 10

Review Questions

Routing Protocols 1. <Insert Question>




























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.


• Write policies in RPL

• Use hierarchical and parameterized policies

• Convert route maps to RPL policies


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.



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.



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



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.



Fundamental Capabilities

Modularization•Common blocks of policy•Defined and maintained independently•Apply from other blocks to build complete

policiesParameterization

•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?



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.



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



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 in-use 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.



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 Execution EnginePolicy Repository

Clients (protocols)



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, extcommunity-set 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


Module 11 RPL Description

Basic Building Blocks and Functions

Route Policy Language

Route Policies Policy Sets

ExtendedCommunity

SetsPrefix SetsAS Path Sets Community

Sets



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.

_________________________________________________________________



Hierarchical Policy

A policy which is referenced by another policy with an apply statement:

route-policy oneset med 100

end-policy

route-policy twoapply oneset community (10:100)

end-policy



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.



Parameterized Policy

A hierarchical policy that receives passed values:

route-policy one ($med)set med $med

end-policy

route-policy twoapply one (10)

end-policy

route-policy threeapply 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.



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. _________________________________________________________________



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 unicastpolicy foo inpolicy bar out



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.



BGP Attach Points

Aggregationaggregate-address address/length policy policy-name

Dampeningbgp dampening policy policy-name

Default originatedefault-originate policy policy-name

Neighbor export/importpolicy policy-name {in | out}

Network network address/length policy policy-name

Redistributeredistribute {ospf | isis | bgp} policy policy-name

Showshow bgp route-policy policy-nameShow bgp policy route-policy policy-name

Tabletable-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



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.



BGP Attach Points (continued)

Aggregationaggregate-address address/length policy policy-name

Dampeningbgp dampening policy policy-name

Default originatedefault-originate policy policy-name

Neighbor export/importpolicy policy-name {in | out}

Network network address/length policy policy-name

Redistributeredistribute {ospf | isis | bgp} policy policy-name

Showshow bgp route-policy policy-nameShow bgp policy route-policy policy-name

Tabletable-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



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.



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 aset1ios-regx ‘_42$’,ios-regx ‘_127$’

end-set

Inline set form example:

(ios-regx ‘_42$’, ios-regx ‘_127$’)



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 _________________________________________________________________



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)



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.



Prefix Set (continued)

Legal prefix specifications:prefix-set legal10.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 3010.0.6.0/24 eq 28end-set

prefix-set illegal10.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 28end-set

Illegal prefix specifications:



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$')



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 aset1ios-regex ’_42$’,ios-regex ’_127$’

end-set



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, no-advertise 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



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 cset112:34,12:78,internetend-set



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. _________________________________________________________________



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 TargetSoO: Site of Origin

extcommunity-set extcomm-set1RT:1.2.3.4:666,RT:1234:666,SoO:1.2.3.4:777,SoO:4567:777

end-set



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 as-path-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



Conditional Statements

An if statement uses a conditional expression to decide which actions or dispositions should be taken for the given route.

The if statement also permits an else or elseif clause, which is executed if the expression is false.

if as-path in as-path-set-1 thendrop

endif

if med eq 150 thenset local-preference 10

elseif med eq 200 thenset local-preference 60

elseset local-preference 0

endif



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. _________________________________________________________________



Nested Conditionals

The statements within an if statement may themselves be ifstatements, as shown in the following:

if community matches-every(12:34, 56:78) thenif med eq 8 thendropendifset local-preference 100

endif



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)



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 …



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.



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.

med eq 10 and not destination in (10.1.3.0/24) or community is (56:78)

med eq 10 and (not destination in (10.1.3.0/24) or community is (56:78))

For example

is evaluated differently than



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



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.



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.



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 setstatements



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.


Module 11 BGP Route Attributes and Operations

BGP Route Attributes

XweightXtraffic-indexXtagXsuppress

XsourceXroute-type

XoriginXnext-hopXmedXlocal preferenceXextended communityXdestinationXdampeningXcommunityXas-path

CiscoBGPAttribute

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.



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 as-path-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.



As Path

as-path -- Match

as-path -- Assignment

if as-path in as-path-set-1 then …if as-path is-local then …if as-path length eq 10 then …if as-path neighbor-is ’10’ then …if as-path originates-from ’100’ then …if as-path passes-through ’10 11’ then …if as-path unique-length eq 5 then …

prepend as-path 2 3prepend 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.



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).



Community

community -- Assignment

set community (10:12)set community ($as:12) additivedelete community in ($as:12, 10:$tag)delete community not in keepcommdelete community all

community -- Match

if community is-empty then …if community matchs-any c1 then …if community matchs-every c2 then …

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, matches-all is true only if each community in the community-set matches at least one community in the route.



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 well-known community needs to be removed. _________________________________________________________________



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.



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 max-suppress (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.



Dampening

route-policy foo-dampif destination in (10.0.0.0/24 ge 28) thenset dampening max-suppress 30 halflife 10 others default

elseset dampening halflife 20 max-suppress 45 reuse 750suppress 1000

endifend-policy



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.



Destination

destination -- Match

if destination in (10.0.0.0/8 ge 8 le 32) thenset local-preference 200

endif



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.



Extended Community

extcommunity -- Match

if extcommunity matchs-any ec1 then …If extcommunity matchs-every ec2 then …If extcommunity is-empty then …



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>



Local Preference

local-preference -- Assignment

set local-preference 200



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.



MED

med -- Match

med -- Assignment

if (med eq 10) then ...

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.



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.



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 ...



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}



Origin

origin -- Match

origin -- Assignment

if origin is igp or origin is incomplete then …

set origin incomplete



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.



Source

source -- Match

if source matches-any my_prefix_set then ...



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.



Tag

tag -- Match

tag -- Assignment

if tag eq 10 then …

set tag 20



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.



Traffic-Index

traffic-index -- Assignment

set traffic-index 10set traffic-index $tindexset traffic-index ignore



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.



Weight

weight -- Assignment

set weight 100



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.


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



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.



Route Map Configuration

ip prefix-list 10110 permit 10.48.0.0/16 le 3220 permit 172.48.0.0/1930 permit 192.168.3.0/24

ip prefix-list 10210 permit 172.16.10.0/2420 permit 192.168.8.0/2130 permit 192.168.32.0/21

ip community-list 110 permit 10: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. _________________________________________________________________



Route Map Configuration (continued)

route-map sample1 permit 10match ip address prefix-list 101match community 1set metric 11set community 12:34 additive




route-map sample1 permit 50match ip address prefix-list 101set metric 100set community 12:34 additive





route-map sample2 permit 50match ip address prefix-list 102set metric 100set community 12:35 additive



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.



Direct Translation

prefix-set ps10110.48.0.0/16 le 32,172.48.0.0/19,192.168.3.0/24

end-set

prefix-set ps102172.16.10.0/24,192.168.8.0/21,192.168.32.0/21

end-set

community-set cs110:11

end-setcommunity-set cs2

10:12end-setcommunity-set cs3

10:13end-setcommunity-set cs4

10:14end-set

Convert the prefix and community lists to their equivalent RPL set notation.



Direct Translation (continued) Next take each route-map and convert it to an equivalent 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 (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.



Direct Translation (continued)

route-policy policy1if destination in ps101 and community matches-any cs1 then

set med 11set community 12:34 additive

elseif destination in ps101 and community matches-any cs2 thenset med 12set community 12:34 additive



elseif destination in ps101set med 100set community 12:34 additive

endifend-policy

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.



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.



Direct Translation (continued)

route-policy policy2if destination in ps102 and community matches-any cs1 then

set med 11set community (12:35) additive

elseif destination in ps102 and community matches-any cs2 thenset med 12set community (12:35) additive



elseif destination in ps102set med 100set community (12:35) additive

endifend-policy

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.



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.



Nest Conditionals

route-policy policy1if destination in ps101 then

set community (12:34) additiveif community matches-any cs1 then

set med 11 elseif community matches-any cs2 then

set med 12elseif community matches-any cs3 then


set med 14else

set med 100endif

endifend-policy

Replace the redundant “if destination in” conditional and “set community”statements in the first route policy by just one instance each.

Leave the nested ‘if community”conditionals to reduce size and evaluation processing.



Nest Conditionals (continued) The same steps used to reduce the first policy are now used to reduce the second policy.



Nest Conditionals (continued)


set community (12:35) additiveif community matches-any cs1 then




set med 14else

set med 100endif

endifend-policy

Perform a similar action on the second route policy reducing repetitive conditional statements.



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.



Use Inline Sets


set community (12:34) additiveif community matches-any (10:11) then

set med 11elseif community matches-any (10:12) then



set med 14else

set med 100endif

endifend-policy

Replace small named community sets with inline sets reducing named set references during policy evaluation.



Inline Sets (continued) Performing the same replacements on the second policy leaves only two prefix sets and two policies.



Inline Sets (continued)

route-policy policy2 if destination in ps102 then

set community (12:35) additiveif community matches-any (10:11) then




set med 14else

set med 100endif

endifend-policy

Perform same replacement of named community sets in the second route policy. Note that the two route policies are nearly identical.



Parameterize Create a parameterized policy block containing the common policy structure from both policies and passing the unique community value in as a parameter.



Parameterize

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 14 else

set med 100 endif

end-policy

Create a parameterized policy block that contains the common policy structure to be used by the route policies.



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.



Parameterize (continued)


apply common (34) pass

endifend-policy


apply common (35)pass

endifend-policy

Apply the parameterized policy to replace the similar policy blocks in both of the route policies.

Question?

Do we need the whole new policy as a final slide in this section for comparison?



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.


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 edit an as-path-setcommunity-set edit a community-setextended-community-set edit an extended-community-setprefix-set edit a prefix-setroute-policy edit a route-policy

RP/0/0/CPU0:pod1#edit route-policy labtesting



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.



show rpl policy Command

RP/0/0/CPU0:pod1#show rpl policy example_three uses allPolicies directly and indirectly applied by this policy:----------------------------------------------------------example_one set-commsSets referenced directly and indirectly----------------------------------------(via applied policies) in this policy:type prefix-set:ten-net too-specific



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. _________________________________________________________________



show bgp route-policy Command

RP/0/0/CPU0:pod1#show bgp route-policy sampleBGP router identifier 172.20.1.1, local AS number 1820BGP main routing table version 729Dampening enabledBGP scan interval 60 secsStatus codes: s suppressed, d damped, h history, * valid, > besti - internal, S staleOrigin codes: i - IGP, e - EGP, ? - incompleteNetwork 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



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.



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]



Summary

Routing Policy Language In this module, you learned:

• 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


Module 11

Review Questions

Routing Policy Language 1. <Insert Question>




























Module 12 Multiprotocol Label Switching (MPLS)

Overview

Description This module discusses the implementation of MPLS in the Cisco IOS XR operating system software.


• Describe MPLS forwarding infrastructure

• Describe MPLS Label Distribution Protocol implementation

• Describe MPLS Traffic Engineering dynamic implementation

• Describe MPLS RSVP implementation for MPLS-TE


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:

• Imposition of labels on packets

• Disposition of labels in packets

• Label swapping


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



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).



MFI Architecture

• Basic elements− Label Switching

Database (LSD) − Label Forwarding

Database (LFD)−MPLS encapsulation and

decapsulation routines

• Control plane− LSD− LFD

• Data plane− LFD−MPLS encap and decap

MFI architecture

LDP MPLS-TE

LSD

HW ASIC

LFDAPPLFIB

APPLencap/decap

MPLSencap/decap

NetIOCon

trol

pla

neD

ata

plan

e



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.



MFI Architecture (Cont.)

• Label Switch Database (LSD)− Allocates and deallocates

labels− Creates a relationship between

FPIs and rewrites− Maintains a rewrite database

by interacting with the LFD− Implements an API for MPLS

applications to create, modify, and delete rewrites

• Label Forwarding Database (LFD)− Accepts rewrites from the LSD− Links rewrite to the correct

forwarding tables− Sets up label tables for MPLS

decapsulation

RP

MSC orLC

TE RSVP LDP

LSD

IGP

RIB

LFD FIB



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.



MFI Architecture (Cont.)

RP SRP

LSD

LC

LSD LFD LFD

LFD LFD LFD

LCLC



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.

• 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 explicit-nullv4, explicit-nullv6, are installed in the forwarding plane



MPLS Forwarding Display Commands

RP/0/RP0/CPU0:P1#show mpls forwarding (Global)RP/0/RP0/CPU0:P1#show mpls forwarding location 0/1/CPU0 (Node LC 0/1/0)

RP/0/0/CPU0:P5#sho mpls forwarding ?debug Include debug informationdetail Detailed informationhardware Display hardware table informationinterface Match outgoing interfacelabels Match label valueslocation Specify a locationprefix Match destination prefix and maskprivate Include private informationsummary Summarized informationtunnels Tunnel(s) at head

• MPLS show forwarding commands display output − Globally− By node

RP/0/0/CPU0:P5#show mpls forwardingLocal Outgoing Prefix Outgoing Next Hop Bytes TLabel Label or ID Interface Switched O------ ----------- ----------------- ------------ --------------- ----------- -16 Unlabelled 100.10.20.1/32 tt1 100.10.20.1 0 17 Unlabelled 142.50.12.0/24 tt1 100.10.20.1 0 18 Pop Label 142.50.20.0/24 PO0/3/0/3 142.50.52.2 0 19 Unlabelled 100.10.20.3/32 tt1 100.10.20.1 0

19 100.10.20.3/32 PO0/3/0/3 142.50.52.2 0 20 Pop Label 100.10.20.2/32 PO0/3/0/3 142.50.52.2 0

RP/0/RP0/CPU0:P1#sho mpls forwarding summaryForwarding entries:

Label switching: 6IPv4 label imposition: 1MPLS TE tunnel head: 1MPLS TE fast-reroute: 0MPLS TE internal: 0

Forwarding updates:58 updates, 24 messages

Labels in use:Reserved: 4Lowest: 16Highest: 20



Additional information about the details of MPLS forwarding paths is available showing:

• 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



MPLS Display Commands (Cont.)

RP/0/0/CPU0:P5#show mpls forwarding detailLocal Outgoing Prefix Outgoing Next Hop Bytes TLabel Label or ID Interface Switched O------ ----------- ----------------- ------------ --------------- ----------- -16 Unlabelled 100.10.20.1/32 tt1 100.10.20.1 0

MAC/Encaps: 4/8, MTU: 4470Label Stack (Top -> Bottom): { 23 }Packets Switched: 0Installed: 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 0 MAC/Encaps: 4/8, MTU: 4470Label Stack (Top -> Bottom): { Imp-Null }Packets Switched: 0Installed: May 3 05:01:09.489 (00:55:07 ago)Owner: LDP

19 Unlabelled 100.10.20.3/32 tt1 100.10.20.1 0 MAC/Encaps: 4/8, MTU: 4470Label Stack (Top -> Bottom): { 23 }Packets Switched: 0Installed: 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 0 MAC/Encaps: 4/8, MTU: 4470Label Stack (Top -> Bottom): { 19 }Packets Switched: 0Installed: May 3 05:01:09.489 (00:55:07 ago)Owner: LDP



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.



Display MPLS Forwarding (Cont.)

RP/0/0/CPU0:P5#sho mpls interfaceInterface LDP Tunnel Enabled -------------------------- -------- -------- --------POS0/3/0/3 Yes Yes YesPOS0/4/0/0 Yes No Yes

• MPLS-enabled interfaces

• 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> ]



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 (IS-IS) 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.


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



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.



Enabling LDP

RP/0/RP0/CPU0:P5(config)#mpls ldpRP/0/RP0/CPU0:P5(config-ldp)#

• Enter MPLS LDP mode

RP/0/RP0/CPU0:P5(config-ldp)#interface POS 0/3/0/0 RP/0/RP0/CPU0:P5(config-ldp-if)#

• Specify interfaces for LDP

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”.



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 discovery-hello 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. _________________________________________________________________



LDP Router ID

RP/0/RP0/CPU0:P5(config)#mpls ldpRP/0/RP0/CPU0:P5(config-ldp)#router-id loopback0RP/0/RP0/CPU0:P5(config-ldp)#

•Assign a router ID−Used as the source of discovery hello's

•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.



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.



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

RP/0/RP0/CPU0:P5(config-ldp)#neighbor 192.168.2.44 password secret

•Use password authentication− TCP MD5



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.



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



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.



LDP Graceful Restart

•Enabling GR preserves NSF services

RP/0/RP0/CPU0:P5(config-ldp)#graceful-restartRP/0/RP0/CPU0:P5(config-ldp)#graceful-restart forwarding-state-holdtimeRP/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.



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.



Restarting LDP Sessions

RP/0/RP0/CPU0:P1#mpls ldp restart session all

RP/0/RP0/CPU0:P1#mpls ldp restart session A.B.C.D

•Restart all sessions•Restart a specific session



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:

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



Displaying LDP Information

•View general LDP parameter informationRP/0/0/CPU0:P5#show mpls ldp parameters

LDP Parameters:Protocol Version: 1Router ID: 100.10.20.5Null Label: ImplicitSession:

Hold time: 180 secKeepalive interval: 60 secBackoff: Initial:15 sec, Maximum:120 sec

Discovery:Link Hellos: Holdtime:30 sec, Interval:15 secTargeted 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 secLDP application recovery (with LSD): 360 sec

OOR stateMemory: Normal



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.

• 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



Displaying LDP Information (Cont.)

• View LDP discovery information

RP/0/0/CPU0:P5#show mpls ldp discovery

Local LDP Identifier: 100.10.20.5:0Discovery Sources:

Interfaces:POS0/3/0/3 : xmit/recv

LDP Id: 100.10.20.2:0, Transport address: 100.10.20.2Hold time: 30 sec (local:30 sec, peer:30 sec)

POS0/4/0/0 : xmit/recvLDP Id: 100.10.20.1:0, Transport address: 100.10.20.1

Hold time: 30 sec (local:30 sec, peer:30 sec)

RP/0/0/CPU0:P5#show mpls ldp neighbor

Peer LDP Identifier: 100.10.20.1:0TCP connection: 100.10.20.1:646 - 100.10.20.5:63604Graceful Restart: Yes (Reconnect Timeout: 120 sec, Recovery: 0 sec)Session Holdtime: 180 secState: Oper; Msgs sent/rcvd: 25/25Up time: 00:11:28LDP Discovery Sources:

POS0/4/0/0Addresses 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:0TCP connection: 100.10.20.2:646 - 100.10.20.5:53633Graceful Restart: Yes (Reconnect Timeout: 120 sec, Recovery: 0 sec)Session Holdtime: 180 secState: Oper; Msgs sent/rcvd: 25/27Up time: 00:11:24LDP Discovery Sources:

POS0/3/0/3Addresses 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

• View LDP neighbor information



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:

• 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



Displaying LDP Information (Cont.)

• View LDP label bindings

RP/0/0/CPU0:P5#show mpls ldp bindings100.10.20.1/32 , rev 10

local binding: label:16remote 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:20remote bindings :

lsr:100.10.20.1:0, label:19 lsr:100.10.20.2:0, label:IMP-NULL (rewrite)


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-NULLremote bindings :

lsr:100.10.20.1:0, label:20 lsr:100.10.20.2:0, label:20


lsr:100.10.20.1:0, label:IMP-NULL (rewrite)lsr:100.10.20.2:0, label:17

Assignedlocally

Learned

• View LDP forwarding information

RP/0/0/CPU0:P5#show mpls ldp graceful-restart

Forwarding State Hold timer : Not RunningForwarding Entries : 6 Checkpointed (3 GR, 3 non-GR)

0 Stale, 0 without PathUpGR Neighbors : 2

Neighbor ID Up Connect Count Liveness Timer Recovery Timer --------------- -- ------------- ------------------ ------------------100.10.20.1 Y 3 - -100.10.20.2 Y 3 - -

RP/0/0/CPU0:P5#show mpls forwardingLocal Outgoing Prefix Outgoing Next Hop Bytes TLabel Label or ID Interface Switched O------ ----------- ----------------- ------------ --------------- ----------- -16 Unlabelled 100.10.20.1/32 tt1 100.10.20.1 0 17 Unlabelled 142.50.12.0/24 tt1 100.10.20.1 0 18 Pop Label 142.50.20.0/24 PO0/3/0/3 142.50.52.2 0 19 Unlabelled 100.10.20.3/32 tt1 100.10.20.1 0

19 100.10.20.3/32 PO0/3/0/3 142.50.52.2 0 20 Pop Label 100.10.20.2/32 PO0/3/0/3 142.50.52.2 0

• View LDP GR information



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-state-based 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.


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



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.



Traffic Engineering Steps

1. Determine and configure the IGP routing protocol relationship− IS-IS− OSPF− Set IGP-to-TE configuration

♦ Router ID (required)♦ Area (OSPF) or Level (ISIS)

2. Create TE Tunnels− Turn on IPv4 for tunnel− Set destination− Set bandwidth− Set priority− Set tunnel advertisements− Create paths

♦ Explicit ♦ Dynamic

3. Determine the MPLS-TE interfaces− Enable the interfaces− Set other parameters

4. Set RSVP signaling− Set the interfaces− Set the bandwidth on the interfaces

P1P1

P2P2PE4PE4

PE5PE5

P4P4

P5P5



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



Creating an IGP Relationship

• IGP routing protocol• MPLS traffic engineering configuration• OSPF example:

• IS-IS example:

RP/0/RP0/CPU0:P5(config-isis-af)#mpls traffic-eng level 1RP/0/RP0/CPU0:P5(config-isis-af)#mpls traffic-eng router-id loopback1RP/0/RP0/CPU0:P5(config-isis-af)#

RP/0/RP0/CPU0:P5(config-ospf)#mpls traffic-eng router-id loopback0RP/0/RP0/CPU0:P5(config-ospf)#mpls traffic-eng area 0 RP/0/RP0/CPU0:P5(config-ospf)#



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.



Creating MPLS-TE Tunnels

RP/0/RP0/CPU0:P5(config)#interface tunnel-te4 RP/0/RP0/CPU0:P5(config-if)#

• Configure a tunnel using interface mode− Locally significant identity

P1P1

P2P2PE4PE4

PE5PE5

P4P4

P5P5



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.



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 loopback0RP/0/RP0/CPU0:P5(config-if)#

P1P1

P2P2PE4PE4

PE5PE5

P4P4

P5P5

100.10.20.5



Creating a Tunnel Destination To configure a destination address for an MPLS traffic engineering tunnel, use the keyword destination command in tunnel configuration submode.



Creating a Tunnel Destination

• Tunnels require destinations− IP address or host name

RP/0/RP0/CPU0:P5(config-if)#destination 100.10.20.4RP/0/RP0/CPU0:P5(config-if)#

P1P1

P2P2PE4PE4

PE5PE5

P4P4

P5P5

100.10.20.4

100.10.20.5



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.



Setting the Bandwidth

RP/0/RP0/CPU0:P5(config-if)#bandwidth 100000RP/0/RP0/CPU0:P5(config-if)#

• Tunnel bandwidth required end-to-end− Specified in kilobits per second− Reserved in interface global pool by default

P1P1

P2P2PE4PE4

PE5PE5

P4P4

P5P5

100.10.20.4

100.10.20.5

To here

From here



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.



Setting Priority

RP/0/RP0/CPU0:P5(config-if)#priority 1 1RP/0/RP0/CPU0:P5(config-if)#

• Tunnel priority − Setup − Hold

P1P1

P2P2PE4PE4

PE5PE5

P4P4

P5P5

100.10.20.4

100.10.20.5



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.



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 dynamicRP/0/RP0/CPU0:P5(config-if)#path-option 2 explicit name alternateRP/0/RP0/CPU0:P5(config-if)#

100.10.20.4

P1P1

P2P2PE4PE4

PE5PE5

P4P4

P5P5

100.10.20.5

Alternate



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.



Setting IGP Tunnel Usage

• IGP should use the tunnel in path calculation

RP/0/RP0/CPU0:P5(config-if)#autoroute announceRP/0/RP0/CPU0:P5(config-if)#

P1P1

P2P2PE4PE4

PE5PE5

P4P4

P5P5

100.10.20.4

100.10.20.5

Used inIGP here



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.



Enabling MPLS-TE on Interfaces

RP/0/RP0/CPU0:P5(config)#mpls traffic-eng RP/0/RP0/CPU0:P5(config-mpls-te)#interface POS 0/4/0/0RP/0/RP0/CPU0:P5(config-mpls-te-if)#interface pos 0/3/0/3RP/0/RP0/CPU0:P5(config-mpls-te-if)#

• Enter MPLS traffic engineering mode

• Enable MPLS-TE interfaces−RSVP enabled (automatically)

P1P1

P2P2PE4PE4

PE5PE5

P4P4

P5P5

100.10.20.4

100.10.20.5POS0/4/0/0

POS0/3/0/3



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.



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)#rsvpRP/0/RP0/CPU0:P5(config-rsvp)#interface POS 0/4/0/0 RP/0/RP0/CPU0:P5(config-rsvp-if)#bandwidth 100000RP/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)#bandwidthRP/0/RP0/CPU0:P5(config-rsvp-if)#

Physicallink

RSVPbandwidth

TEtunnels

% of link b/wfor all

other traffic Unused b/wfor other

RSVP signaledtraffic: 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



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:

• 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


Module 12 Examining MPLS-TE Operation

Displaying MPLS-TE Topology

RP/0/0/CPU0:P5#sho mpls traffic-eng topologyMy_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:2Frag Id:0, Intf Address:142.50.52.5, Intf Id:0Nbr Intf Address:142.50.52.2, Nbr Intf Id:0

TE Metric:1, IGP Metric:1, Attribute Flags:0x0Switching Capability:, Encoding:Physical BW:155520 (kbps), Max Reservable BW Global:0 (kbps)Max Reservable BW Sub:0 (kbps)

Global Pool Sub PoolTotal Allocated Reservable ReservableBW (kbps) BW (kbps) BW (kbps)--------------- ----------- ----------

bw[0]: 0 0 0bw[1]: 0 0 0

IGP Id: 100.10.20.1, MPLS TE Id: 100.10.20.1 Router Node (ospf area 0)

Additional output omitted




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:

• 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



Displaying MPLS-TE Tunnels

RP/0/0/CPU0:P5#sho mpls traffic-eng tunnelsSignalling Summary:

LSP Tunnels Process: runningRSVP Process: running

Forwarding: enabledPeriodic reoptimization: every 3600 seconds, next in 3403 secondsPeriodic FRR Promotion: every 300 seconds, next in 245 seconds

Periodic auto-bw collection: disabled

Name: tunnel-te1 Destination: 100.10.20.1Status:Admin: up Oper: up Path: valid Signalling: connectedpath option 1, type dynamic (Basis for Setup, path weight 3)

History:Tunnel has been up for: 00:01:51Current LSP:

Uptime: 00:01:51Path info (ospf area 0):Hop0: 142.50.52.2Hop1: 142.50.20.3Hop2: 142.50.12.1Hop3: 100.10.20.1

LSP Tunnel P1_t5 is signaled, connection is up100.10.20.5





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.



Displaying MPLS-TE Tunnels (Cont.)

RP/0/0/CPU0:P5#sho mpls traffic-eng tunnels briefSignalling Summary:


Forwarding: enabledPeriodic reoptimization: every 3600 seconds, next in 3180 secondsPeriodic FRR Promotion: every 300 seconds, next in 22 seconds

Periodic auto-bw collection: disabledTUNNEL NAME DESTINATION STATUS STATEtunnel-te1 100.10.20.1 up up

P1_t5 100.10.20.5 up upDisplayed 1 (of 1) heads, 1 (of 1) tailsDisplayed midpoint: Information not available via this commandDisplayed 1 up, 0 down, 0 recovering, 0 recovered heads



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.



Displaying MPLS-TE Tunnels (Cont.)

RP/0/RP0/CPU0:P5#show mpls traffic-eng tunnels summarySignalling Summary:


Forwarding: enabledHead: 2 interfaces, 2 active signalling attempts, 2 established

0 explicit, 2 dynamic 6 activations, 4 deactivations0 recovering, 0 recovered

Mids: 0Tails: 0

Periodic reoptimization: every 60000 seconds, next in 22016 secondsPeriodic 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 reroutedMid: 0 frr tunnels, 0 protected, 0 reroutedSummary: 1 protected, 1 link protected, 0 node protected, 0 bw protectedBackup: 1 tunnels, 1 assignedInterface: 1 protected, 0 rerouted

• Summary of TE tunnels



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.



Displaying RSVP Information

RP/0/RP0/CPU0:POD1#show rsvp intInterface MaxBW MaxFlow Allocated MaxSub ----------- -------- -------- --------------- --------PO0/4/0/1 10M 10M 2M ( 20%) 0PO0/4/0/3 10M 10M 2M ( 20%) 0

• Interfaces

RP/0/0/CPU0:P5#show rsvp reservationDestination 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 1K100.10.20.5 5 100.10.20.1 1636 0 None SE LOAD 10M 1K

• Reservations



Summary

Multiprotocol Label Switching (MPLS) In this module, you learned to:

• Describe MPLS forwarding infrastructure

• Describe MPLS Label Distribution Protocol implementation

• Describe MPLS Traffic Engineering dynamic implementation

• Describe MPLS RSVP implementation for MPLS-TE


Module 12

Review Questions

Multiprotocol Label Switching (MPLS) 1. <Insert Question>





























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.


• 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

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.

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



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.



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



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.



CWI Launch

CRS-1

HTTP

CWI clients

JARJAR

HTTP is used for:

• Initial connection• Loading of the CWI

applet and Jar files



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, object-oriented 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.



Run-Time Transport

Launcher

CWI

CWI client

CORBA XML

Telnet/SSH CLI

HTTP Jar files

HTTP Jar files

Telnet, SSH

CORBA bus

CORBA XML notifications

HTTP server

Command parser

CORBA services

CORBA agent

IOS XR router

Serial Console/Terminal Server CLI



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.



Security Features

Authentication to access XML (linked to AAA authentication)IIOP

AuthorizationAuthentication (used by HTTP/HTTPS, IIOP SSL, Telnet/SSH, IPsec)Accounting

AAA

Authentication to access CLI (linked to AAA authentication)encryption

SSH v1/v2

Authentication to access CLI (linked to AAA authentication)Telnet

Authentication to access XML (linked to AAA authentication)encryption

IIOP SSL v2

Linked to AAA authentication; encryption; required if using IIOP SSLHTTPS

Linked to AAA authenticationHTTP



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:

• 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 tab-separated) 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.



Desktop Window

InventoryTree

Applicationpane

Toolbar

Status bar

Menu bar

Instructor's Note

Same slide for following page!!! One slide covers 2 text pages!



• 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. _________________________________________________________________



Desktop Window (Cont.)

InventoryTree

Applicationpane

Toolbar

Status bar

Menu bar



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:

• 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.



Desktop Menu



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.



Inventory Tree



Tools Menu The tools menu allows you to invoke a specific desktop application:

• 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



Tools Menu



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. Double-click 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.



Alarm Dashboard

Emergency (red) Critical (orange) Warning (blue)

Alert (purple) Error (yellow) Notification (green)

Running count

Double-click on:− Specific severity to display chosen alarms in Alarm Viewer− Running count to zero displayed value



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:

• 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]

Module 13 Desktop Applications


Alarm Viewer

Toolbar

Alarm table

Alarm pane

Instructor's Note

One slide for these two pages of text!!



• 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.



Alarm Viewer (Cont.)

Toolbar

Alarm table

Alarm pane



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:

• 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



Inventory Viewer

Inventory table



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.



Rack View



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:

• 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



Interface Viewer

Interfacetable



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.

• Notification Test—Checks whether the notification service is active on the router. An automatic repair is provided in some instances of this test failure.



Troubleshooter



Router Configuration Craft Works Interface (CWI) supports three modes of configuration:

• Terminal, Telnet and SSH CLI sessions

• Configuration Editor and Replace Configuration Editor

• Graphical configuration

Module 13 Router Configuration


Modes

CLI sessions•Telnet•Terminal

•SSH Plus

Editors•Configuration Editor

•Replace Configuration Editor

Graphical configuration



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.



Telnet Plus and SSH Plus

Toolbar Commandlist

Instructor's Note

One slide for 2 test pages!!



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:

• 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.



Telnet and SSH Plus (Cont.)

Toolbar Commandlist



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:

• 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)



Configuration Editor

Changed commands

Deleted commands

Added commands



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.



Replace Configuration Editor



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:

• Lock/Unlock

• Load

• Save

• View Uncommitted Configuration

• Commit

• Clear

• Rollback

Module 13 Graphical Configuration Applications


Configuration Desktop

Toolbar

ConfigurationApplications

Tree


Launch Context



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:

• 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



Graphical Configuration Features



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.



Configuration Applications Tree and Launch Context


Tree

LaunchContext



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:

• 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.



Configuration Control Toolbar

Lock/Unlock

Load Commit Rollback

View uncommitedconfiguration

Clear

Save



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.



Common Elements and Activities

Clone special

Clone recordDelete record

Set defaults

Row copy

Row Paste

Row Paste Special

Undo

Redo

Common Configuration tools

Add recordFilter Table

Print Find

Export Find next

Cut Paste

Copy

Preferences

Refresh Help

Common application

tools

Common configuration

tools



Administration Configuration The Administration Configuration applications are used to manage user access, permissions, and alarms. The applications are:

• 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.



Administration Configuration



Applications Configuration The Applications Configuration applications allow you to configure and set up protocol-specific applications. The two applications that can be configured are:

• 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.



Applications Configuration



Interface Configuration The Interface Configuration applications are used to display, configure, and manage Ethernet and packet-over-SONET (POS) interfaces. The applications are:

• 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.



Interface Configuration



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-to-end 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. ______________________________________________________________



Policy Configuration



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:

• 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.



Protocol Configuration



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”.

Module 13 Getting Started


CWI Router Configuration

RP/0/0/CPU0:router(config)#xml agent corba

RP/0/0/CPU0:router(config)#commit

Enable the XML agent

Commit the target configuration

RP/0/0/CPU0:router#config

RP/0/0/CPU0:router(config)#http server

Enable the HTTP server

Enter router configuration mode

Instructor's Note

Firewall port configuration to support CWI:

HTTP/HTTPS 80/443 Inbound IIOP/IIOPSSL 10001/10002 Inbound Notifications 49901 to 49950 Outbound Telnet/SSH 23/22 Inbound



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.



Launching CWI

http://<router-dns-name>or

http://<router-ip-address>



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.



Loading CWI Components



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.



Checking the Java Runtime Environment



Testing Communication If a problem is encountered during login, you can troubleshoot the problem using the CWI Troubleshooter.



Testing Communications



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:

• CLI / Serial, Terminal Server

• CLI / Telnet, SSHv1, SSHv2

• XML / Telnet, SSHv1, SSHv2, CORBA, CORBA SSL



Logging In



Summary

Craft Works Interface In this module, you learned 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 graphical configuration applications

Module 13


Review Questions

Craft Works Interface 1. <Insert Question>



























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 Map-classes, Map-polices and attaching a service policy to an interface.


• 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 service-polices to an interface


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.


Module 14 CRS-1 QoS Hardware Components

CRS-1 QoS Hardware Components

Line Card CPU

Egress PSE

IngressPSE IngressQ

Power Regulators

SP & FIA

2*FabricQ

EgressQ



Life of a Packet

Overview QoS in the CRS-1 is distributed in many locations and is performed end-to-end. 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-to-end 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.


Module 14 Life of a Packet

Life of a Packet – Step 1

FromFabric

FabricQReass.

MIDPLANE

IngressQIn Q/

Segmenter

RX PSEL3 Engine

CPUCTRLGW CPU

FabricQReass.

TX PSEL3 Engine

EgressQOut Q

OC192Framer

& Optics

ToPLIM

PLA

OC192Framer

& Optics

OC192Framer

& Optics

OC192Framer

& Optics

Egress Packet Flow

1

Fabric

Fabric

FromPLIM

Ingress Packet FlowTo Fabric



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




FromFabric

FabricQReass.

MIDPLANE

IngressQIn Q/

Segmenter

RX PSEL3 Engine

CPUCTRLGW CPU

FabricQReass.

TX PSEL3 Engine

EgressQOut Q

OC192Framer

& Optics

ToPLIM

PLA

OC192Framer

& Optics

OC192Framer

& Optics

OC192Framer

& Optics

Egress Packet Flow

1

Fabric

Fabric

FromPLIM 2




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.




FromFabric

FabricQReass.

MIDPLANE

IngressQIn Q/

Segmenter

RX PSEL3 Engine

CPUCTRLGW CPU

FabricQReass.

TX PSEL3 Engine

EgressQOut Q

OC192Framer

& Optics

ToPLIM

PLA

OC192Framer

& Optics

OC192Framer

& Optics

OC192Framer

& Optics

Egress Packet Flow

1

Fabric

Fabric

3FromPLIM 2


FromFabric

FabricQReass.

MIDPLANE

IngressQIn Q/

Segmenter

RX PSEL3 Engine

CPUCTRLGW CPU

FabricQReass.

TX PSEL3 Engine

EgressQOut Q

OC192Framer

& Optics

ToPLIM

PLA

OC192Framer

& Optics

OC192Framer

& Optics

OC192Framer

& Optics

Egress Packet Flow

1

Fabric

Fabric

3FromPLIM 23a




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.




ConfigurableDynamicMapping ofQueues to ports

To fabric

MDRR/AggregateShaper

ShapingMin/max BW

Max BW

8192 Queues 1K Ports (Port/VLAN)HPLP

LP

MDRR/Shaper P1

MDRR/Shaper

MDRR/Shaper

P2

P1023

WRED

FromRX PSE

PSE IngressQ

FromFabric

FabricQReass.

MIDPLANE

IngressQIn Q/

Segmenter

RX PSEL3 Engine

CPUCTRLGW CPU

FabricQReass.

TX PSEL3 Engine

EgressQOut Q

OC192Framer

& Optics

ToPLIM

PLA

OC192Framer

& Optics

OC192Framer

& Optics

OC192Framer

& Optics

Egress Packet Flow

1

Fabric

Fabric

3FromPLIM 2

4aFabricCells


3a4



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.




FromFabric

FabricQReass.

MIDPLANE

IngressQIn Q/

Segmenter

RX PSEL3 Engine

CPUCTRLGW CPU

FabricQReass.

TX PSEL3 Engine

EgressQOut Q

OC192Framer

& Optics

ToPLIM

PLA

OC192Framer

& Optics

OC192Framer

& Optics

OC192Framer

& Optics

Ingress Packet Flow

Egress Packet Flow

1

Fabric

Fabric

3FromPLIM 2

FabricCells 5

FabricCellsTo Fabric

3a

4a

4



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.



Life of a Packet – Step 5a

S1

S1

S2

S2 S3

S3

S1

S1

S2

S2 S3

S3S1

S1

S2

S2 S3

S3

1 of 8

2 of 8

8 of 8MSC

2

1

8

136 Bytes cells

Multi-stage Interconnect – 3 Stage Benes topology - buffered non-blocking switch

MSC 2

1

16

2 Levels of priorityHP Low latency path LP Best effort traffic

Multicast support1M multicast groups

S1

S1

H -UnicastH -UnicastH -MulticastH -Multicast


S2



S2



S2



S3



S2



S3

Hi Priority CellsLo Priority Cells

RR RR



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/sub-interface 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.




FromFabric

FabricQReass.

MIDPLANE

IngressQIn Q/

Segmenter

RX PSEL3 Engine

CPUCTRLGW CPU

FabricQReass.

TX PSEL3 Engine

EgressQOut Q

OC192Framer

& Optics

ToPLIM

PLA

OC192Framer

& Optics

OC192Framer

& Optics

OC192Framer

& Optics

Ingress Packet Flow

Egress Packet Flow

1

Fabric

Fabric

3FromPLIM 2

FabricCells 5


3a

6FabricCells

4a

4



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.




FabricQReass.

MIDPLANE

IngressQIn Q/

Segmenter

RX PSEL3 Engine

CPUCTRLGW CPU

FabricQReass.

TX PSEL3 Engine

EgressQOut Q

OC192Framer

& Optics

ToPLIM

PLA

OC192Framer

& Optics

OC192Framer

& Optics

OC192Framer

& Optics

Ingress Packet Flow

1

Fabric

Fabric

FromPLIM 2

FabricCells 5


3a

FromFabric Egress Packet Flow6

FabricCells

3

7

4a

4



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.




FabricQReass.

MIDPLANE

IngressQIn Q/

Segmenter

RX PSEL3 Engine

CPUCTRLGW CPU

FabricQReass.

TX PSEL3 Engine

EgressQOut Q

OC192Framer

& Optics

PLA

OC192Framer

& Optics

OC192Framer

& Optics

OC192Framer

& Optics

Ingress Packet Flow

1

Fabric

Fabric

3FromPLIM 2

FabricCells 5


3a


FabricCells

ToPLIM

87

4a

4

2K Groups(VLAN/Tunnel)

To PLIM

Configurable DynamicMapping ofQueues to groups and ports

ShapingMin/max BW

8192 Queues 768 Ports (Port/VLAN)

HPLP

LP P1

PX

WRED

MDRR/Shaper G1

MDRR/Shaper

MDRR/Shaper

G2

GX

MDRR/Group

MDRR/Group

MDRR/AggregateGroup

Max BW

fromTX PSE

9.



Once the packet has been queued and shaped it is then passed to the PLA ASIC on the PLIM.




FabricQReass.

MIDPLANE

IngressQIn Q/

Segmenter

RX PSEL3 Engine

CPUCTRLGW CPU

FabricQReass.

TX PSEL3 Engine

EgressQOut Q

OC192Framer

& Optics

PLA

OC192Framer

& Optics

OC192Framer

& Optics

OC192Framer

& Optics

Ingress Packet Flow

1

Fabric

Fabric

3FromPLIM 2

FabricCells 5


3a


FabricCells

ToPLIM

87 9

4a

4



10. Finally the packet is sent through the egress port, and onto the physical link.




FabricQReass.

MIDPLANE

IngressQIn Q/

Segmenter

RX PSEL3 Engine

CPUCTRLGW CPU

FabricQReass.

TX PSEL3 Engine

EgressQOut Q

OC192Framer

& Optics

PLA

OC192Framer

& Optics

OC192Framer

& Optics

OC192Framer

& Optics

Ingress Packet Flow

1

Fabric

Fabric

3FromPLIM 2

FabricCells 5


3a


FabricCells

8

ToPLIM

7

4a

10

9

4



IngressQ queuing and shaping

Features • 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.


Module 14 IngressQ queuing and shaping

IngressQ queuing and shaping - Features

ConfigurableDynamicMapping ofQueues to ports

To fabric

MDRR/AggregateShaper

ShapingMin/max BW

Max BW

8192 Queues 1K Ports (Port/VLAN)HPLP

LP

MDRR/Shaper P1

MDRR/Shaper

MDRR/Shaper

P2

P1023

WRED

FromRX PSE

PSE IngressQ



EgressQ queuing and shaping

Features • Packets are passed into the EgressQ from the TX PSE

−

−

−

−

−

−

−

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


Module 14 EgressQ queuing and shaping

EgressQ queuing and shaping -Features

2K Groups(VLAN/Tunnel)

To PLIM

Configurable DynamicMapping ofQueues to groups and ports

ShapingMin/max BW

8192 Queues 768 Ports (Port/VLAN)

HPLP

LP P1

PX

WRED

MDRR/Shaper G1

MDRR/Shaper

MDRR/Shaper

G2

GX

MDRR/Group

MDRR/Group

MDRR/AggregateGroup

Max BW

fromTX PSE



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 30-byte 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.


Module 14 Switch Fabric Cell Structure

Switch Fabric Cell Structure

32Internal Fabric control bits

1Snoop/CTB

18Destination Address (12 bits)/FGID

7Packet 1 Cell Sequence Number

7Packet Cell Count

2Trailing Offest

2Packet 2 Payload Offset/FGID

13Packet 1 Sequence Number

10Source Address

1Vital

1Fabric Priority

1Cast (Mcast/Ucast)

BitsFields (Data Cells)

Header (12 bytes) Packet 1 Packet 2

Packet 1 Packet 2

Packet 2

Single Packet Payload

Two Packet Payload

Packet 1 (120 bytes)

Cell Payload (120 bytes) FEC

Header

30 bytes

30 bytes

30 bytes

30 bytes

Packet 1



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.


Module 14 Switch Fabric Cell Structure

Switch Fabric Cell Structure (Cont.)

32Internal Fabric control bits

1Snoop/CTB

18Destination Address (12 bits)/FGID

7Packet 1 Cell Sequence Number

7Packet Cell Count

2Trailing Offest

2Packet 2 Payload Offset/FGID

13Packet 1 Sequence Number

10Source Address

1Vital

1Fabric Priority

1Cast (Mcast/Ucast)

BitsFields (Data Cells)

Header (12 bytes) Packet 1 Packet 2

Packet 1 Packet 2

Packet 2


Two Packet Payload

Packet 1 (120 bytes)


Header

30 bytes

30 bytes

30 bytes

30 bytes

Packet 1



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.


Module 14 Worst Case Fabric Cell Loading

Worst Case Fabric Cell Loading – Example

Pkt 1 Pkt 2

Pkt 3


Two Packet Payload

Pkt 5 (150 bytes)


Header

30 bytes

30 bytes

30 bytes

30 bytes

Pkt 4

• Fabric cells can contain a maximum of two 60 byte packets

• Cell is most efficient when packets break on 30 byte boundaries

• 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

Pkt 2

Pkt 5

PAD

PAD



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.


Module 14 Switch Fabric Architecture

Switch Fabric Architecture - Ingress

S1

S1

S2

S3

S3

Fabric Plane

Upper shelf

Lower shelf

Ingress MSC

Ingress MSC

RP

S2

MSC

MSC Slots0-7

MSC Slots8-15

IngressQFabricQ

MSC

Note: RPs in slot RP0 & RP1

S1

S1 S2

S2 S3

S3

Switch Fabric Card

Ingress speed 32 connections x 2.5Gbps = 80Gbps80Gbps x 8/10 coding = 64GbpsMinus cell tax = ~50Gbps

From Fabric

To Fabric



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. _________________________________________________________________


Module 14 Switch Fabric Architecture

Switch Fabric Architecture – Egress

Plane1

Egre

ss M

SC

Plane2

Plane3

Plane4

Plane5

Plane6

Plane7

Plane8

S3

S3

S3

S3

S3

S3

S3

S3

S3

S3

S3

S3

S3

S3

S3

S3

S3

S3

S3

S3

S3

S3

S3

S3

S3

S3

S3

S3

S3

S3

S3

S3

MSC

0-7

8-15

IngressQFabricQ

MSC

Note: RPs in slot RP0 & RP1

S1

S1 S2

S2 S3

S3

Switch Fabric Card

Egress speed 64 x 2.5Gbps = 160Gbps160Gbps x 8/10 coding = 128GbpsMinus cell tax = ~ 100Gbps

From Fabric

To Fabric



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.


Module 14 Switch Fabric Features

Switch Fabric Features

S1

S1

S2

S2 S3

S3

S1

S1

S2

S2 S3

S3

2 of 8

8 of 8MSC

2

1

8

136 Bytes cells

MSC2

1

16

1296 x 1296 buffered non-blocking switchMulti-stage Interconnect – 3 Stage Benes topology



40 Gbps 2 X Speedup @ S3

S1

S1

S2

S2

1 of 8

S3

S3

S1

S1



S2



S2



S2



S2



S2



S2

Hi Priority CellsLo Priority Cells

RR RR



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 • 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


Module 14 Switch Fabric Features

Switch Fabric Features (Cont.)

S1

S1

S2

S2 S3

S3

S1

S1

S2

S2 S3

S3

2 of 8

8 of 8MSC

2

1

8

136 Bytes cells

MSC2

1

16

1296 x 1296 buffered non-blocking switchMulti-stage Interconnect – 3 Stage Benes topology



40 Gbps 2 X Speedup @ S3

S1

S1

S2

S2

1 of 8

S3

S3



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.


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



Traffic Class The purpose of a traffic class is to classify traffic on your router. The class-map 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.



Traffic Class

The class-map command is used to define a traffic classThree 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)



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.



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



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:

• access-group

• any

• discard-class

• dscp

• mpls

• precedence

• protocol

• qos-group



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



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.



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



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:

• bandwidth

• commit

• describe

• do

• exit

• no

• police

• priority

• queue-limit

• random-detect

• service-policy

• set

• shape

• show



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 varietyRP/0/RP1/CPU0:P1(config-pmap-c)#?bandwidth bandwidthcommit Commit the configuration changes to runningdescribe Describe a command without taking real actionsdo Run an exec commandexit Exit from this submodeno Negate a command or set its defaultspolice Police trafficpriority assign priority to this classqueue-limit queue-limitrandom-detect enable random-detectservice-policy Configure QoS Service policyset Set QoS valuesshape Shape trafficshow Show contents of configuration

RP/0/RP1/CPU0:P1(config-pmap-c)#



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.



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 runBuilding configuration...class-map match-any routinematch precedence ipv4 routine!class-map match-any varietymatch mpls experimental topmost 1match precedence ipv4 criticalmatch access-group ipv4 blockacl!policy-map traffic-classclass routinebandwidth percent 10!class varietypriority!interface POS0/4/0/2service-policy output traffic-classRP/0/RP1/CPU0:P1(config)#



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.



Displaying a policy-map

RP/0/RP1/CPU0:P1#sh policy-map int pos0/4/0/2POS0/4/0/2 output: traffic-class

Class routineClassification statistics (packets/bytes) (rate -)

Matched : 0/0 0Transmitted : 0/0 0Total Dropped : 0/0 0

Queueing statisticsVital (packets) : 0

Queueing statisticsQueue ID : 42High watermark (packets) : 0Inst-queue-len (bytes) : 0Avg-queue-len (bytes) : 0TailDrop Threshold(bytes) : 59904000Taildropped(packets/bytes) : 0/0

Class varietyClassification statistics (packets/bytes) (rate -)




Class defaultClassification statistics (packets/bytes) (rate -)




RP/0/RP1/CPU0:P1#



Summary

Data Flow and MQC QoS In this module, you learned the following:

• 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 service-polices to an interface


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.


• 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

RP/0/RP1/CPU0:mttr-1#sh platform

Node Type PLIM State Config State

--------------------------------------------------------------------------------------------------------------------------

0/1/SP MSC(SP) N/A IOS-XR RUN PWR,NSHUT,MON

0/1/CPU0 MSC 4OC192-POS/DPT IOS-XR RUN PWR,NSHUT,MON

0/RP1/CPU0 RP(Active) N/A IOS-XR RUN PWR,NSHUT,MON

0/SM0/SP FC/S(SP) N/A IOS-XR RUN PWR,NSHUT,MON

Normal operational status of CRS-1 cards that have booted is“IOS-XR RUN”.RP/0/RP1/CPU0:mttr-1# show platform

To view the card status and associated PLIMs:



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.



Resetting a Card

RP/0/RP1/CPU0:mttr-1#hw-module node 0/3/CPU0 reloadRP/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

RP/0/RP1/CPU0:mttr-1#hw-module node <#> reload

To reset a modular services card (MSC is also referred to as a node):



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.20031114-135355.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.



Identifying Software Issues

RP/0/RP1/CPU0:mttr-1# show context all location 0/3/CPU0Crashed pid = 20519 (pkg/bin/metro_driver)Crash time: Fri Nov 14, 2003: 13:53:55Core for process at disk0:/metro_driver.20031114-135355.node0_3_1.Z

Stack Trace#0 0xfc225248…..#9 0x4820268c

Registers info<text omitted>

R36 24000022 20000004DLL Info

DLL path Text addr. Text size Data addr. Data size Version/pkg/lib/libinfra.dll 0xfc10a000 0x00030c98 0xfc109268 0x00000a70 0

Displays the PID number that caused the crash

Used mainly for bug reporting and by beta customers for problem reporting

Shows the location of the core dump file



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.


Appendix A Troubleshooting CPU Overload

Troubleshooting CPU Overload

RP/0/RP1/CPU0:mttr-1# top98 processes; 320 threads;CPU states: 0.0% idle, 39.2% user, 60.7% kernelMemory: 1024M total, 202M avail, page size 4K

JID TID PRI STATE HH:MM:SS CPU COMMAND135 15 10 Rply 0:07:15 38.03% gsp1 14 10 Run 0:06:49 33.94% procnto-600-smp-cisco-instr1 4 10 Rcv 0:07:06 26.83% procnto-600-smp-cisco-instr

149 1 10 Rdy 0:00:49 0.39% ipv4_fib_mgr

RP/0/RP1/CPU0:mttr-1# top

To view the processes that consumes the most cycle time:

Standard top command displays top processes

Write down thread ID for isolation



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.


Appendix A Troubleshooting Memory Issues

Modular Services Card

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

Show summary memory information

RP/0/RP1/CPU0:mttr-1# show memory [location] <node>

To look at the total and available memory:



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.


Appendix A Troubleshooting Memory Issues

Viewing Top Memory-Consuming Issues

RP/0/RP1/CPU0:mttr-1l# #show processes JID Text Data Stack Dynamic Process208 45056 4096 12288 604951808 tcam_mgr53 24576 0 12288 16056320 dllmgr55 28672 4096 73728 12939264 eth_server135 98304 4096 167936 4706304 gsp64 8192 4096 40960 1789952 pkgfs170 40960 4096 118784 1134592 netio204 4096 4096 20480 1097728 sysdb_svr_local132 28672 4096 45056 987136 fqm215 65536 4096 40960 966656 wdsysmon216 81920 4096 40960 933888 mpls_lfd

Top two memory consuming-processes

To view the top memory-consuming processes on the router:

RP/0/RP1/CPU0:mttr-1# #show processes

Job ID of the process “tcam_mgr” for further investigation



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


Appendix A Troubleshooting the Data Path

Troubleshooting the Data Path

pla(MOOSE 0|1)

Aka reindeer/bambi

pse(METRO) 0

ingressq(SPRAYER)

fabricq 0|1(SPONGE)

pse 1(METRO)

Egressq(SHARQ)

cpuctrl(SQUID)

To fabric

From fabric

To line

From line



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.


Appendix A Ingress

Troubleshooting Ingress Interfaces

RP/0/RP1/CPU0:mttr-1#show interface pos 0/0/1/2POS0/0/1/2 is down, line protocol is down reliability 255/255, txload 1/255, rxload 1/255Encapsulation HDLC, crc 32, controller loopback not set, keepalive not set<text omitted all “zero” counters>10 packets input, 1040 bytes, 57 total input drops0 drops for unrecognized upper-level protocol

Received 0 broadcast packets, 0 multicast packets0 runts, 0 giants, 0 throttles, 0 parity57 input errors, 28 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort11 packets output, 1058 bytes, 0 total output drops

Output 0 broadcast packets, 0 multicast packets<text omitted all “zero” counters>

Basic command looks for input or output drops and is a good starting point

To look at the general health of an interface:

RP/0/RP1/CPU0:mttr-1#show interface pos 0/0/1/2



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).


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/cpu0POS0/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



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.


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



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.


Appendix A Ingress

Troubleshooting the General Health of PSE (Metro)

RP/0/RP1/CPU0:mttr-1# show controllers pse summary instance 0 loc 0/0/cpu0Node: 0/0/cpu0:

----------------------------------------PSE 0, Summary Info:-------------------------------------------------<text omitted>DeviceState : 0 (UP)StartupOpts : 00000000 MmappedBase : 0x609b0000ClsDisMask : 0x1000 NFusedPPEs : 199 (188 hwf, 11 swf)MPUcodeName : /pkg/gsr/ucode/ingress_mp_v1.mucodePPEUcodeName: /pkg/gsr/ucode/ingr ess_turbo_pos_v1.mucodeINTR-Status : 00000000 INTR-Enable : 0x7ffffeNColdResets : 1 NWarmResets : 0NResetRetry : 0NIntrtps : 3 NIntrptThrot: 0

Look to make sure device state is up, indicating that Metro is active

Check for excessive resets, which indicate hardware problems

RP/0/RP1/CPU0:mttr-1#show controllers pse summary



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.


Appendix A Ingress

Troubleshooting PSE (Metro)

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 : 2534657DUMMY_COUNTER : 1131918326098 (indicates idle packets sent on a link) ….PSE 1, Statistics Info: !! (this displays the SECOND PSE asic )DROP_L3_LOAD_INFO : 2651376DUMMY_COUNTER : 1131912204019

Because you are looking for errors, you can exclude any statistics that have zero counters.

To display both PSE (Metro) ASIC traffic information:

Dummy counters do not indicate errors; they indicate idle cells

RP/0/RP1/CPU0:mttr-1# show controller pse statistics



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.


Appendix A Ingress

Checking for PSE (Squid) Punt Path Errors

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







RP/0/RP1/CPU0:mttr-1# show controllers cpuctrl ports ingressq pdma all

To determine whether packets punted by PSE (not for data path) are dropped:



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.


Appendix A Ingress

Troubleshooting Ingressq (Sprayer)

RP/0/RP1/CPU0:mttr-1# show controllers ingressq statistics location 0/0/cpu0Ingressq Rx Statistics.------------------------------------------------------------------------rx pkts : 1281816 ( 645169854 bytes)rx pkts from cpu : 487579 ( 110400014 bytes)rx control pkts from cpu : 487579 ( 110400014 bytes)rx data pkts from cpu : 0 ( 0 bytes)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 : 1290015Ingressq Drops.------------------------------------------------------------------------length error drops : 2crc error drops : 97273OOR error drops : 0backpressure discard drops : 0tail drops : 0cell drops : 2

Packets received from Metro

Packets sent to the fabric

Difference between the two preceding counters



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.


Appendix A Ingress

Troubleshooting Ingressq (Sprayer) (cont.)

RP/0/RP1/CPU0:mttr-1# show controllers ingressq statistics location 0/0/cpu0Ingressq Rx Statistics.------------------------------------------------------------------------rx pkts : 1281816 ( 645169854 bytes)rx pkts from cpu : 487579 ( 110400014 bytes)rx control pkts from cpu : 487579 ( 110400014 bytes)rx data pkts from cpu : 0 ( 0 bytes)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 : 1290015Ingressq Drops.------------------------------------------------------------------------length error drops : 2crc error drops : 97273OOR error drops : 0backpressure discard drops : 0tail drops : 0cell drops : 2

Packets receivedfrom Metro

Packets sent to the fabric

Difference between two preceding counters



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.


Appendix A Egress

Fabricq (Sponge)

RP/0/33/1:Alamo# show controllers fabricq packet-stats location 0/0/cpu0

Fabric Queue Manager Packet Statistics======================================

Location: 0/2/CPU0Asic Instance: 0Fabric Destination Address: 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 )

Refers to cells received from the fabric

RP/0/33/1:Alamo# show controllers fabricq packet-statsTo display fabricq (Sponge) ASIC packet statistics:



The packet counters are divided by ASIC level, with the second ASIC information continuing after fabricq ASIC 0.


Appendix A Egress

Fabricq (Sponge) (Cont.)

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 )

This counter indicates whether any packets pulled were dropped due to buffer misses

Location: 0/2/CPU0Asic Instance: 1Fabric Destination Address: 33Input 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 )



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.


Appendix A Egress

Egressq (Sharq)

RP/0/RP1/CPU0:mttr-1# show controllers egressq statistics location 0/0/cpu0egressq ASIC version: 1egressq ASIC state: Normalplimasic link0 output packets: 4294967295plimasic link0 output bytes: 4257472179491plimasic link1 output packets: 3569577894plimasic link1 output bytes: 2196621864536plimasic link2 output packets: 0plimasic link2 output bytes: 0plimasic link3 output packets: 0plimasic link3 output bytes: 0cpuctrl input packets: 893151cpuctrl output bytes: 337999299pse input packets: 4294967295pse dropped packets: 0cpuctrl dropped packets: 0

Packets received from the pse ASIC

Packets sent to the PLIM ASIC

Packets received from the cpuctrl ASIC



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 “up-time” 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.


Appendix A Troubleshooting Switch Fabric Cards

SFC Troubleshooting Overview

Por

t

LINE CARD FABRIC CARDS

Spra

yer

Spon

ge

S1

S3

S1

S3

S1

S3

S1

S3

S1

S3

S1

S3

S1

S3

S1

S3

Port

LINE CARD

Spon

geSp

raye

r

1. Test operational status2. Check packet statistics3. Check “health” statistics4. Learn how to ping across

fabric to test connectivity

S1

S3

S1

S3

S1

S3

S1

S3

S1

S3

S1

S3

S1

S3

S1

S3

S1

S3

S1

S3

S1

S3

S1

S3

S1

S3

S1

S3

S1

S3

S1

S3

S2

S2



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.



Checking the Switch Fabric Card Health

RP/0/RP1/CPU0:mttr-1# admin show controllers fabric plane all

To check SFC status:

RP/0/RP1/CPU0: mttr-1#admin show controllers fabric plane allPlane Admin Oper Down Total DownId State State Flags Bundles Bundles----------------------------------------------------------------------------0 UP UP 0 01 UP UP 0 02 UP UP 0 03 UP UP 0 04 UP UP 0 05 UP UP 0 06 UP UP 0 07 UP UP 0 0



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.



Data Path Cell Transmission

RP/0/RP1/CPU0:mttr-1# admin sh contr fabric plane all statIn Out CE UCE PE

Plane Cells Cells Cells Cells Cells------------------------------------------------------------------------------------------

0 182100857464 182104887774 0 5 01 181926888266 181929025881 0 4 02 182153559719 182155676693 0 1 03 175491618741 175493740472 0 2 04 182582550997 182584668766 1 5 05 168887486356 168889599486 1 7 06 182993770506 182995889294 0 0 07 182059456630 182061580187 0 10 0

To see how many cells have been transmitted across each plane:

RP/0/RP1/CPU0:mttr-1# admin show controller fabric plane all stat



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.



Getting Error Details for a Card

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: 1Total received data cells: 182821414530Total received unicast data cells: 182820991976Total received multicast data cells: 422554Total transmitted data cells: 182823538527Total transmitted unicast data cells: 182821003591Total transmitted multicast data cells: 2534936Total received correctable errored cells: 0Total received uncorrectable errored cells: 10Total received parity error cells: 0Total unicast lost cells: 0Total multicast lost cells: 0Last clearing of "show controller fabric plane" counters never

RP/0/RP1/CPU0:mttr-1# admin sh contr fabric plane 7 stat detail

Detail flag gives more information for each plane:



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.



Displaying SFC-to-MSC 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.0000/1/1 1 11111111 11111111 316247 316247 100.0000/32/1 1 11111111 11111111 316247 316247 100.0000/33/1 1 11111111 11111111 316247 316247 100.000

Each of 8 planes should have a “1” bit set to indicate that the connectivity is good

Total uptime and percentage of uptime since an error was indicated

RP/0/RP1/CPU0:mttr-1# admin show cont fabric connectivity

To check SFC connectivity to the MSC:



Summary

Troubleshooting In this module, you learned to:

• Troubleshoot card-level errors

• Check for memory problems and leaks

• Look for process-level errors

• Troubleshoot ASIC-level problems


Part Number: XX#######-XX-X

cisco crs

Documents