Cisco ASR 9000 Aggregation Services Router Series Student Guide v4.0.1

ASR9KE
Cisco ASR 9000

Aggregation Services
Router Series Essentials
Version 4.0.1
Student Guide
Text Part Number: ASR9KE

Copyright ! 2011, 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 " 2011, Cisco Systems, Inc. All rights reserved. CCIP, the Cisco Powered Network mark, the
Cisco Systems Verified logo, Cisco Unity, Follow Me Browsing, FormShare, Internet Quotient, iQ
Breakthrough, iQ Expertise, iQ FastTrack, the iQ logo, iQ Net Readiness Scorecard, Networking Academy,
ScriptShare, SMARTnet, TransPath, and Voice LAN are trademarks of Cisco Systems, Inc.; Changing the Way We
Work, Live, Play, and Learn, Discover All Thats Possible, The Fastest Way to Increase Your Internet Quotient, and
iQuick Study are service marks of Cisco Systems, Inc.; and Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE,
CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, the Cisco IOS logo, Cisco Press,
Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Empowering the Internet Generation,
Enterprise/Solver, EtherChannel, EtherSwitch, Fast Step, GigaStack, IOS, IP/TV, LightStream, MGX, MICA, the
Networkers logo, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, RateMUX, Registrar, SlideCast,
StrataView Plus, Stratm, SwitchProbe, TeleRouter, and VCO are registered trademarks of Cisco Systems, Inc. and/or
its affiliates in the U.S. and certain other countries.
All other trademarks mentioned in this document or Web site are the property of their respective owners. The use of
the word partner does not imply a partnership relationship between Cisco and any other company. (0203R)
Printed in the USA

Cisco ASR 9000 Aggregation Services Router Series
Essentials Course Overview
Intended Audience
This course is for technical professionals who need to know how to
implement the Cisco ASR 9000 series router in their network
environment.
The following are the primary audience for this course:
Support staff
Installation and implementation personnel
Network Operations Center (NOC) personnel
Network engineers
Course Level
This course provides a fundamental level of information pertaining to
the Cisco ASR 9000 Series family of products.
Prerequisites
The following courses are prerequisites:
Basic knowledge of router installation and some experience with
installation tools
Routing protocol configuration experience with Border Gateway
Protocol (BGP), Intermediate System-to-Intermediate System (IS-
IS), and Open Shortest Path First (OSPF)
Knowledge of Layer 2 IEEE switching and related protocols
Strong knowledge of MPLS configuration or multicast
configuration experience
Knowledge of Cisco router security implementation, including
authentication, authorization, and accounting (AAA) and TACACS
Experience troubleshooting Cisco routers in a large network
environment
Additional Information
Cisco Systems Technical Publications
2011 Cisco Systems, Inc. Version 4.0.1 v

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
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 4.0.1 Cisco ASR 9000 Series Essentials

Course Agenda
Day 1
Course and Student Introduction
Module 1 Introduction to the Cisco ASR 9000 Aggregation Series
Module 2 Cisco ASR 9000 Hardware
Module 3 Cisco IOS XR Software Overview
Lab 1 Hardware Discovery and Initial Configuration
Module 4 Cisco IOS XR Software Basics
Module 5 Cisco IOS XR Software Installation
Lab 2 Cisco IOS XR Software Installation
Day 2
Module 6 Cisco IOS XR Operations
Lab 3 Cisco IOS XR Operations
Module 7 IOS XR Security
Lab 4 IOS XR Security
Module 8 IOS XR Routing Protocols
Lab 5 IS-IS Routing Configuration
Lab 6 OSPF Routing Configuration
Lab 7 iBGP Routing Configuration
Module 9 Route Policy Language
Lab 8 Route Policy Language
Day 3
Module 10 Layer 3 Multicast
Lab 9 Layer 3 Multicast
Module 11 MPLS
Lab 10 MPLS
Module 12 Layer 3 VPN
Lab 11 Layer 3 VPN
Module 13 Cisco ASR 9000 Layer 2 Architecture
Day 4
2011 Cisco Systems, Inc. Version 4.0.1 vii

Module 14 Cisco ASR 9000 Point-to-Point Layer 2 Services
Lab 12 Local E-Line
Lab 13 EoMPLS E-Line
Module 15 Cisco ASR 9000 Multipoint Layer 2 Services
Lab 14 Local E-LAN
Lab 15 VPLS E-LAN
Module 16 Cisco ASR 9000 OAM
Lab 16 Cisco ASR 9000 OAM
Day 5
Module 17 Cisco ASR 9000 Layer 2 Multicast
Lab 17 Layer 2 Multicast
Module 18 Cisco ASR 9000 MQC QoS
Course Summary
viii Version 4.0.1 Cisco ASR 9000 Series Essentials

Course Introduction and Objectives
Overview
Description
The course introduces you to the Cisco ASR 9000 Series Aggregation
Services Router. The chassis options, features, and functionality are
described in detail. The modules are both theoretical and practical in
scope. Although some of the modules focus on the technology and
features of the platform, most of the modules deal specifically with the
tasks associated with configuring and deploying the Cisco ASR 9000
Aggregation Services Router. Hands-on lab exercises allow you to
practice and 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 ASR
9000 series router
List and describe the major features and benefits of Cisco IOS XR
operating system
Understand data flow through the Cisco ASR 9000 series router
Configure Cisco ASR 9000, back out of configuration changes, and
restore older versions of configuration
Install Cisco IOS XR operating system, Package Information
Envelopes (PIEs) and Software Maintenance Updates (SMU)
Configure the Cisco IOS XR security features in an owner SDR
Configure routing protocols and Route Policy Language in a
complex multi-AS environment
Configure Multiprotocol Label SwitchTraffic Engineering
(MPLSTE) on a Cisco ASR9000 series router Configure Layer 2
Multicast features
2011 Cisco Systems, Inc. Version 4.0.1 ix

Enable Multicast routing on Cisco ASR9000 series router
Configure Layer 3 VPN services
Configure Ethernet Link Bundles

Configure Local E-Line L2VPN
Configure Ethernet over MPLS E-Line L2VPN
Configure EoMPLS with Pseudowire Backup
Configure Local E-LAN L2VPN
Configure link-based Ethernet-Operations, Administration, and
Maintenance (E-OAM)
Configure Virtual Private LAN service (VPLS) L2VPN
Configure VPLS with BGP-Autodiscovery
Configure service-based Connectivity Fault Management (CFM)
Describe Multiple Spanning Tree-Access Gateway (MST-AG)

Describe basic Quality of Service (QoS) implementation
x Version 4.0.1 Cisco ASR 9000 Series Essentials

Contents
Cisco ASR 9000 Aggregation Services Router Series Essentials Course Overview .......... v!
Course Agenda ..................................................................................................................... vii!
Course Introduction and Objectives ................................................................ ix!

Overview ............................................................................................................................... ix!
Module 1 ........................................................................................................... 11!

Overview ............................................................................................................................ 11!
What is the Cisco ASR 9000? ............................................................................................ 12!
Applications ..................................................................................................................... 112!
Cisco ASR 9000 Supports Carrier Ethernet .................................................................. 118!
Flexible Ethernet Edge ................................................................................................... 124!
Ethernet Service Delivery to Access Devices ................................................................. 126!
Cisco IP NGN Carrier Ethernet Architecture ............................................................... 128!
Consumer, Business, and Mobile Service Deployment ................................................. 130!
Cisco ASR 9000 Essentials Lab Topology ...................................................................... 157!
Documentation References ............................................................................................. 159!
Summary ......................................................................................................................... 161!
Module 2 ........................................................................................................... 21!

Overview ............................................................................................................................ 21!
Cisco ASR 9000 Series Chassis ........................................................................................ 22!
Cisco ASR 9000 Series FRUs and Components ............................................................... 26!
Cisco ASR 9000 Power Subsystems ............................................................................... 210!
Cisco ASR 9000 Series Cooling Subsystem .................................................................... 218!
Cisco ASR 9000 RSP Functions ...................................................................................... 220!
RSP Arbitration ............................................................................................................... 222!
Fabric ArchitectureSingle RSP, 40G LCs .................................................................. 231!
40G and 80G Ethernet LCs ............................................................................................ 244!
Packet Data Flow ............................................................................................................ 264!
Ethernet LC Product Identification ............................................................................... 266!
Summary ......................................................................................................................... 272!
Module 3 ........................................................................................................... 31!

Overview ............................................................................................................................ 31!
2011 Cisco Systems, Inc. Version 4.0.1 xi

Cisco IOS XR Architecture ............................................................................................... 32!
High Availability ............................................................................................................... 34!
Scalability ........................................................................................................................ 330!
Summary ......................................................................................................................... 344!
Module 4 ........................................................................................................... 41!

Overview ............................................................................................................................ 41!
Configuration Operations ................................................................................................. 42!
Initial Configuration ....................................................................................................... 420!
Reviewing the Configuration .......................................................................................... 444!
RP Redundancy ............................................................................................................... 456!
Summary ......................................................................................................................... 458!
Module 5 ........................................................................................................... 51!

Overview ............................................................................................................................ 51!
Cisco IOS XR Software Packaging ................................................................................... 52!
Considerations Prior to Software Installation ............................................................... 520!
Software Installation ...................................................................................................... 532!
Software Installation Review ......................................................................................... 548!
Installation Recovery ...................................................................................................... 554!
Installation Command Review ....................................................................................... 564!
Summary ......................................................................................................................... 566!
Module 6 ........................................................................................................... 61!

Overview ............................................................................................................................ 61!
Operations ......................................................................................................................... 62!
Configuration Operations ................................................................................................. 68!
Configuration Rollback and Recovery ............................................................................ 628!
System Backup ................................................................................................................ 644!
Process Management ...................................................................................................... 648!
Summary ......................................................................................................................... 658!
Module 7 ........................................................................................................... 71!

Overview ............................................................................................................................ 71!
Cisco Security Features .................................................................................................... 72!
Basic Security Overview ................................................................................................... 74!
Key Chain Management ................................................................................................... 76!
Security Package Overview .............................................................................................. 78!
Software Authentication Manager ................................................................................. 712!
Access Security Control Planes ...................................................................................... 716!
xii Version 4.0.1 Cisco ASR 9000 Series Essentials

Prerequisites for Secure Access ...................................................................................... 718!
Secure Access Implementation ....................................................................................... 720!
Secure Access Policy ........................................................................................................ 728!
Task-Based Authorization .............................................................................................. 730!
Security Configuration .................................................................................................... 732!
Management Plane Protection ....................................................................................... 752!
Summary ......................................................................................................................... 758!
Module 8 ........................................................................................................... 81!

Overview ............................................................................................................................ 81!
Intermediate System to Intermediate System (IS-IS) .................................................... 82!
Configuring IS-IS .............................................................................................................. 86!
Examining IS-IS Operation ............................................................................................ 816!
Open Shortest Path First (OSPF) .................................................................................. 822!
Configuring OSPFv2 ....................................................................................................... 826!
Examining OSPF Operation ........................................................................................... 840!
Border Gateway Protocol (BGP) ..................................................................................... 846!
Configuring iBGP ............................................................................................................ 850!
Examining BGP Operation ............................................................................................. 866!
Summary ......................................................................................................................... 872!
Module 9 ........................................................................................................... 91!

Overview ............................................................................................................................ 91!
RPL Overview .................................................................................................................... 92!
RPL Description ................................................................................................................ 98!
Converting Route Maps to RPL Policies ........................................................................ 944!
RPL-Specific CLI Commands ......................................................................................... 960!
Summary ......................................................................................................................... 968!
Module 10 ....................................................................................................... 101!

Overview .......................................................................................................................... 101!
Introduction ..................................................................................................................... 102!
Configuring Multicast Routing ....................................................................................... 108!
Protocol Independent Multicast ................................................................................... 1016!
Examining PIM Operation ........................................................................................... 1038!
Summary ....................................................................................................................... 1044!
Module 11 ....................................................................................................... 111!

Overview .......................................................................................................................... 111!
Multiprotocol Label Switching ....................................................................................... 112!
2011 Cisco Systems, Inc. Version 4.0.1 xiii

Generalized MPLS .......................................................................................................... 114!
MPLS Forwarding Infrastructure .................................................................................. 116!
Label Distribution Protocol........................................................................................... 1122!
Configuring LDP ........................................................................................................... 1128!
Verifying LDP Configuration and Operation .............................................................. 1138!
MPLS Traffic Engineering ............................................................................................ 1152!
Configuring MPLS Traffic Engineering ....................................................................... 1156!
Examining the MPLS-TE Infrastructure..................................................................... 1164!
Creating MPLS-TE Tunnels ......................................................................................... 1174!
Examining MPLS Tunnel Operation ........................................................................... 1188!
Summary ..................................................................................................................... 11100!
Module 12 ....................................................................................................... 121!

Overview .......................................................................................................................... 121!
Layer 3 Virtual Private Networks .................................................................................. 122!
L3VPN Implementation Control Flow ........................................................................ 126!
L3VPN Implementation Data Flow .......................................................................... 1216!
Configuration ................................................................................................................. 1218!
Examining L3VPN Operation ...................................................................................... 1232!
Summary ....................................................................................................................... 1256!
Module 13 ....................................................................................................... 131!

Overview .......................................................................................................................... 131!
Cisco IP NGN Carrier Ethernet Architecture ............................................................... 132!
Cisco ASR 9000 = Flexible Ethernet Edge ................................................................... 1310!
Layer 2 or Layer 3 VPN ................................................................................................ 1320!
Aligning Service Names and Standards ...................................................................... 1324!
What is the Cisco ASR 9000 Layer 2 Infrastructure? ................................................. 1326!
What is an EFP? ............................................................................................................ 1328!
EFP Flexible Frame Matching ..................................................................................... 1342!
Layer 2 and Layer 3 Coexistence ................................................................................. 1358!
Flexible VLAN Tag Manipulations .............................................................................. 1360!
Layer 2 Network Infrastructure ................................................................................... 1374!
Logical View of Data Path ............................................................................................ 1388!
Layer 2 VPN Types ....................................................................................................... 1390!
Summary ..................................................................................................................... 13100!
Module 14 ....................................................................................................... 141!

Overview .......................................................................................................................... 141!
Visual Objective-Cisco ASR 9000 Lab Topology ............................................................ 142!
xiv Version 4.0.1 Cisco ASR 9000 Series Essentials

Point-to-point, AC-AC Crossconnect CLI ....................................................................... 144!
Local Switching ............................................................................................................... 146!
Attachment Circuit Redundancy .................................................................................. 1410!
P2P AC-PW Cross-Connect (EoMPLS) ........................................................................ 1428!
Pseudowire Redundancy ............................................................................................... 1456!
MPLS Path Selection .................................................................................................... 1462!
Summary ....................................................................................................................... 1474!
Module 15 ....................................................................................................... 151!

Overview .......................................................................................................................... 151!
Visual ObjectiveCisco ASR 9000 Lab Topology ......................................................... 152!
E-LAN Service ................................................................................................................. 154!
Virtual Private LAN Service ........................................................................................ 1532!
VPLS Split Horizon Rule .............................................................................................. 1538!
VPLS and MAC Tables ................................................................................................. 1540!
VPLS Configuration Prerequisites ............................................................................... 1558!
VPLS Auto-Discovery .................................................................................................... 1568!
-PE and N-PE Redundancy Options............................................................................. 1580!
Summary ..................................................................................................................... 15100!
Module 16 ....................................................................................................... 161!

Overview .......................................................................................................................... 161!
Visual ObjectiveCisco ASR 9000 Lab Topology ......................................................... 162!
OAM Protocol Positioning ............................................................................................... 164!
Link OAM: E-OAM IEEE 802.3ah ................................................................................. 166!
Connectivity Fault Management (CFM or 802.1ag).................................................... 1624!
MPLS OAM-VCCV ........................................................................................................ 1658!
Summary ....................................................................................................................... 1662!
Module 17 ....................................................................................................... 171!

Overview .......................................................................................................................... 171!
Visual ObjectiveASR 9000 Lab Topology ................................................................... 172!
Multicast Network Devices and Protocols ..................................................................... 174!
Cisco ASR 9000 IGMP Snooping Implementation ...................................................... 1712!
Implementation ............................................................................................................. 1722!
Summary ....................................................................................................................... 1750!
Module 18 ....................................................................................................... 181!

Overview .......................................................................................................................... 181!
Quality of Service Overview ........................................................................................... 182!
2011 Cisco Systems, Inc. Version 4.0.1 xv

Cisco ASR 9000 QoS MQC Model ................................................................................... 188!
Layer 2 VPN Quality of Service Example .................................................................... 1826!
Summary ....................................................................................................................... 1842!
xvi Version 4.0.1 Cisco ASR 9000 Series Essentials

Module 1
Introduction to the Cisco ASR 9000 Series
Aggregation Services Routers
Overview
Description
This module provides an overview of the Cisco ASR 9000 Series
Aggregation Services Routers (Cisco ASR 9000). It includes a system
description, a list of hardware components, and an introduction to network
applications and deployment scenarios.
Objectives
After completing this module, you will be able to:
Describe the Cisco ASR 9000 features and functions
List and describe different chassis types, control cards, and traffic-
carrying cards
Describe Cisco ASR 9000 network applications
Describe Cisco ASR 9000 deployment scenarios
Locate user documentation and support information
2011 Cisco Systems, Inc. Version 4.0.1 11

Introduction to the Cisco ASR 9000 Series Aggregation Services Routers Module 1
What is the Cisco ASR 9000?

System Description
The Cisco ASR 9000 Series Aggregation Services Router is a multilayer
Ethernet switching and aggregation platform intended to perform a
number of roles in the Service Provider (SP) access and aggregation space.
Its highly flexible architecture also allows it to be deployed by Enterprise
organizations or any organization seeking to extend its local area network
(LAN) between sites.
In terms of service support, it aggregates broadband triple play, Metro
Ethernet services and/or mobile broadband traffic from 10/100 Ethernet or
Gigabit Ethernet (GE) access devices. These services can be aggregated
into a 10 Gigabit Ethernet (10GE) Internet Protocol (IP) or MPLS edge or
core.
It uses Ethernet as both a service offering and a transport mechanism. It
operates Multiprotocol Label Switching (MPLS) and acts as a label edge
router (LER). It is optimized for Layer 2 and Layer 3 multicast, and it is
also capable of Layer 3 IPv4 and IPv6 routing.
The Cisco ASR 9000 is designed to meet carrier-class requirements for
redundancy, availability, packaging, power, and other requirements
traditional to the SP market. It can be deployed in enterprise networks
requiring high-availability (HA). The Cisco ASR 9000 is a distributed
forwarding router and it runs Cisco IOS XR Software Release 3.9.1.
12 Version 4.0.1 Cisco ASR 9000 Essentials

Module 1 What is the Cisco ASR 9000?

It is a Carrier-class Ethernet Access and Aggregation

platform with robust Layer 3 capability
Supports 10/100 Ethernet, Gigabit Ethernet (GE), and 10
Gigabit Ethernet (10GE) interfaces
Supports legacy OC-n/STM-n interfaces beginning in IOS
XR Software R3.9.0
Combines interface flexibility, IP intelligence, and MPLS
scalability
Optimized for Multicast performance to support video
networking
2011, Cisco Systems, Inc. All rights reserved. Version 4.0.1 Cisco ASR 9000 EssentialsModule 1/3

Cisco ASR 9000 Highlights

The Cisco ASR 9000 series includes two chassis types:
Ten-slot chassis (the Cisco ASR 9010)
Six-slot chassis (the Cisco ASR 9006).
Each chassis type is available in AC or DC versions, and they share
interchangeable route-switch processor (RSP or RP) and line cards (LCs).
Two slots are reserved for RSP cards, and the remaining slots can be
populated with traffic-carrying LCs.

Ten-slot and six-slot chassis

versions
Route Switch Processors
(RSPs) and Line Cards (LCs)
operate in either chassis
AC or DC Power Supplies
operate in either chassis
Chassis runs Cisco IOS XR
software and provides
carrier-class
high availability (HA)
Six-slot Ten-slot
chassis chassis

RSP
RSP cards contain the switch fabric that interconnects the LC cards. They
also provide chassis management and control. Typically, two RSPs are
deployed per-chassis to support control plane redundancy.

RSP
RSP cards provide a non-blocking

switch fabric and chassis control.
Two RSP cards are deployed per chassis
to support full switch fabric and control
plane redundancy.
Management ports
LEDs and alarm outputs
Building Integrated Timing Supply (BITS)
inputs
RSP

LCsGE and 10GE

LCs connect to other network devices. For example, they can operate as a
network-facing trunk cards or subscriber-facing cards. Each Cisco ASR
9000 platform supports 40 Gb LCs and 80 Gb LCs in the 3.9.1 release.
The 40 Gb LCs include:
40-port GE, line rate

Four-port 10GE, line rate
Eight-port 10GE card (oversubscribed)
Two-port 10 GE + 20-port GE, line rate

The 80 Gb LCs include:
Eight-port 10GE card, line rate
16-port 10GE card (oversubscribed)

LCsGE and 10GE
There are two categories of Ethernet

LCs supported in IOS XR Software
Release 3.9.1:
40 Gigabit Ethernet cards
80 Gigabit Ethernet cards
Multiple GE and 10GE interface
options.
All Ethernet LCs provide the same
basic functionality.
GE and 10 GE
Low, medium, and high scale capacity Ethernet LCs
options per Ethernet LC.

LCsShared Interface Processor

Cisco IOS XR Software Release 3.9.0 adds support on the Cisco ASR 9000
Series Router for the SIP-700, a 20G SPA Interface Processor.
The Cisco I-Flex design combines shared port adapters (SPAs) with SIPs,
leverage an extensible design that enables service prioritization for data
and voice services. Enterprises and service provider customers can take
advantage of improved slot economics resulting from modular port
adapters that are interchangeable across Cisco routing platforms. The I-
Flex design maximizes connectivity options and offers superior service
intelligence through programmable interface processors.
The SIP-700 is integrated with the ASR 9000s synchronization circuitry to
provide standards-based line-interface functions for delivering and
deriving transport-class network timing, enabling support for applications
such as mobile backhaul and TDM migration.
The Cisco ASR 9000 SIP-700 is available in a single version capable of
handling multiple SPA types. It contains four SPA bays. This single
version provides high-scale, powerful H-QoS, high queue density, and
interface flexibility. Software licenses are not required on the Cisco ASR
9000 SIP-700.
In R3.9.1 there is one version of SPA available for the SIP-700:
Channelized OC-12
Two OC-12 interfaces per SPA

One SPA uses two SIP bays

LCs-Shared Interface Processor
LCsShared Interface Processor

Two
A Shared Interface Processor (SIP) LC Channelized
OC-12 SPAs
supports non-Ethernet, Shared Port shown (each
occupies two
adapter (SPA)-based interfaces: bays)
20 Gigabit bandwidth per LC slot

Four SPA bays per LC
Many non-Ethernet SPAs (OC-N/STM-N
and T3/E3) are available
SIP-700 with channelized

OC-12 SPAs

Applications
Flexible Ethernet Edge
The CISCO ASR 9000 is focused on the Metro Ethernet and broadband
transport market space. It aggregates Ethernet from the customer edge
and can transport the Ethernet frames using native Ethernet, IP, or
MPLS. It can also provide Layer 3 service (L3VPNs, Internet access, and
so on). This flexibility allows the Cisco ASR 9000 to perform a variety of
network functions. It can be deployed by service providers and enterprises
alike.
This slide gives one example of a Cisco ASR 9000 deployment, providing
LAN extension and Layer 3 service access between two geographically
dispersed customer sites.

Module 1 Applications
Applications
Applications supported include:

Residential broadband services such as IPTV and video
on demand (VoD)
Layer 2 and Layer 3 VPN business services
Next-generation mobile backhaul transport
Layer 2 or Layer 3 VPNs Customer

network
location B
Customer
network
location A
Cisco IP/MPLS Cisco Layer 3
ASR core ASR services
9000 9000

Old WayConnection Oriented

Historically, if an organization wanted to extend its local LAN between
locations across a geographic distance, it would typically use leased-line,
circuit-based services such as Frame Relay (FR) or Asynchronous Transfer
Mode (ATM). The LAN data is transparently transported between
locations. The term virtual private network (VPN) was coined. The FR or
ATM VCs are virtual connections, because multiple instances share the
same physical infrastructure. The VCs are private, because they are
independent and isolated from one another. Because FR and ATM are
Layer 2 protocols, these arrangements are considered Layer 2 VPNs
(L2VPN).
These leased-line arrangements evolved with the growing speed and
complexity of LAN Ethernet and the Internet, eventually using high-speed
Packet over SONET (POS) transport. SONET is successful due to its
combination of bandwidth scalability (OC-192 is 10 Gbps) and its superior
Layer 1 fault management and protection technologies. Metro Ethernet
standards were originally published for optical networks due to their
robust Layer 1 superiority.
However, leased-line, circuit-based architectures have a limited ability to
scale and provide multiservice delivery. There was a need to go from a
point-to-point network to a network cloud, meaning, any-to-any
connectivity.

Old WayConnection Oriented
Connection-
Connection-oriented,
Layer 2 VPN
VPN A topology VPN A
VPN A
Customer equipment
VPN A
VPN A
Historically, CEs were interconnected by way of a

Frame Relay (FR) or Asynchronous Transfer Mode
(ATM) network of dedicated, leased-line circuits.
Build once, sell once.

New WayIP/MPLS VPN Cloud

Ethernet + IP/MPLS
IP and MPLS connectionless, packet-switched architectures are now the

choice of service providers worldwide. Ethernet, ubiquitous in the LAN
market, has also evolved in both scale (10 Gigabit Ethernet and 100
Gigabit Ethernet are now available) and Layer 1 performance management
(802.3 OAM, 802.1ag, 802.1ad, and so on), making it an ideal transport
mechanism. IP provides Quality of Service (QoS) at the subscriber level
rather than across the entire physical interface or virtual circuit.
Customers looking to extend their Ethernet LAN now have the option of
connecting with Ethernet across the service provider IP or MPLS network.
MPLS can be used to provide point-to-point or multipoint connectivity. 1:1,
1:N, and any-any connection-types are supported.
The market demands any application, and connectivity, on almost any
device, whether accessing information or entertainment delivered through
voice, video, or data. Users need to be in the office when at home, and
connected to home when at work. And of course, it all must be delivered as
one service. All the characteristics of Carrier Ethernet mean that it is
poised to be that one service.

New Way-IP/MPLS VPN Cloud
IP/MPLS
Layer 2 or Layer 3
VPN network
VPN A
VPN A
VPN B VPN A and B
Pseudowires
VPN C VPN A and C
MPLS combines the privacy and QoS of FR or ATM

networks with the flexibility and scalability of IP
Any-any connectivity = Build once, sell many

Cisco ASR 9000 Supports Carrier Ethernet

The Metro Ethernet forum (MEF) is a consortium of networking vendors,
service providers, and standards bodies, and it defines the standards
services deployed over a Carrier Ethernet network.
The Cisco ASR 9000 supports flexible service mapping, which means that
it can interconnect different subscriber service types (or interface construct
types) across different transport circuit types (or service instances),
simultaneously.
It supports different service types on a single interface, and it offers point-
to-point or multipoint transport architectures. This results in the ability to
provide E-Line and E-LAN Carrier Ethernet services as defined by the
Metro Ethernet forum.

Module 1 Cisco ASR 9000 Supports Carrier Ethernet
Cisco ASR 9000 Supports Carrier Ethernet
User network interface User network interface

(UNI) (UNI)
Carrier Ethernet
Network
CE PE PE CE
Ethernet service attributes

Ingress Ingress
Egress Egress
A UNI is the demarcation between the customer edge (CE) and the
provider edge (PE)
Ethernet service is what Service Providers (SP) provides between UNIs
Ethernet Line service (E-Line) point-to-point
Ethernet LAN service (E-LAN) multipoint

What is Carrier Ethernet?

Carrier Ethernet is a set of standardized, end-to-end Ethernet service
definitions, attributes, and parameters established by the MEF. Carrier
Ethernet services can be deployed over native Ethernet, IEEE 802.1ad
Ethernet, Synchronous Optical Network/Synchronous Digital Hierarchy
(SONET/SDH), or MPLS networks.
Carrier Ethernet differs greatly from traditional LAN-based Ethernet. It
has carrier-class features and functions such asQoS, fault management,
and high availability.

What is Carrier Ethernet?
Ethernet is widely deployed in enterprise and campus LANs, making it a

standard that is readily accepted and available
Carrier Ethernet is a network-wide set of SP transport standards defined
by the Metro Ethernet forum (MEF)
The MEF is a consortium of vendors, SPs, and governing bodies
The MEF sets standards for services deployed over a Carrier Ethernet
network
Standardized services
Scalability
Service management
Reliability
Quality of service (QoS)

Carrier Ethernet Reference Model

The CE network breaks down into multiple functional layers, each
characterized by a specific architectural role. Some basic definitions:
UNI to UNI: This is the service provider area of responsibility going
from the user network interface (UNI) through the core to the user
network interface (UNI).
Distributed Provider Edge: Provider edge devices distribute the
function of multiple network elements: U-PE, PE-Agg, and N-PE.
The user-provider edge (U-PE) device is the demarcation point between the
customer and SP network. It is typically located at the customer premise or
outside plant, but is owned and managed by the SP. Major functions
include:
providing multiple UNIs to the customer, defining Ethernet service
functionality of the UNI, ensuring visible bandwidth, enforcing service
admission, and offering traffic multiplexing.
The provider-edge aggregation (PE-AGG) device is an intermediate
optional layer between U-PE and network-PE. (N-PE) devices that
provides a way to scale the number of U-PE devices connected to the N-
PEs. Functions include:
aggregating traffic, multiplexing and congestion management, and
local switching for Ethernet services.
The network provider edge (N-PE) is the demarcation point between the
Layer 2 protocols in the Ethernet access domain and the Layer 3 and
MPLS functionalities performed in the core.
Single Provider Edge: Provider edge devices can perform the function of
a single network element. Typically, a number of customer facing devices
(U-PEs) interface a single aggregation device (PE-AGG or N-PE)
Service Provider Core: The provider (P) router is the backbone or core
network devices consisting of multiple P and N-PE routers connected in a
partial or full mesh configuration and provides for the end-to-end
connectivity.

Carrier Ethernet Reference Model
CE U-PE PE-AGG N-PE P N-PE CE
Core
Distributed PE Single PE
UNI UNI
Service provider responsibility


The Cisco ASR 9000 connects Ethernet circuits (called Attachment Circuits
[ACs]) on its customer-facing or downstream side to Ethernet virtual
circuits (EVCs) on its network or upstream side provided by Ethernet, IP, r
MPLS connections to other edge or core devices.
The Cisco EVC model uses a series of Ethernet flow points (EFPs), bridge-
domains (BDs), and MPLS pseudowires (PWs) to create end-to-end EVCs.
An EVC can be point-to-point or multipoint. The end result can be a Layer
2 or Layer 3 VPN.
The combination of flexible traffic matching and flexible service mapping
creates the flexible Ethernet edge.

Module 1 Flexible Ethernet Edge
Untagged L2 P-to-P native

Single-tagged L2 P-to-P over PW
Double-tagged L2 MP native bridging
802.1q L2 MP VPLS
802.1ad L3 routed
etc
PE
Flexible Ethernet mapping combined with IP or MPLS allows for

the construction of point to point or point to multipoint Layer 2 or
Layer 3 service.

Ethernet Service Delivery to Access Devices

The access layer provides broadband access for residential and business
services based on DSL, Ethernet, and Wireless access nodes.
The Cisco ASR 9000 Series enables flexible options for interfacing with
access networks and devices through a multiplexed-UNI (muxed-UNI). A
muxed-UNI delivers multiple independent services on a single physical
port.
The connectivity models are aligned with standards recommendations from
the Broadband Forum (formerly known as DSL Forum) and the Metro
Ethernet Forum (MEF). Support for multiple standards enables the system
to aggregate a multitude of access technologies such as DSL, cable, ETTX,
Gigabit Passive Optical Network (GPON), WiMax, and Mobile Radio
Access Network (RAN).
A critical feature required to provide all of these options is the support of
scalable and robust hierarchical quality of service (QoS) on a per-service
and per-subscriber instance basis.

Module 1 Ethernet Service Delivery to Access Devices
Ethernet Service Delivery to Broadband Access Devices
Subscriber services are common across

any access medium
DSL Secure broadband
Cable ETTx
Ethernet service
Ethernet to the home (ETTH)
delivery
Mobile wireless
Delivery of multiple services: Ethernet
Cable Access
Metro Ethernet business services
Residential triple play aggregation Cisco
(VPWS, VPLS, IP routing, IP multicast) ASR 9000
PE
Internet, broadcast TV, video on demand DSL
(VoD), Voice over IP (VoIP)
Broadband wireless backhaul Mobile
broadband

Cisco IP NGN Carrier Ethernet Architecture

The Cisco ASR 9000 is an important part of the Cisco IP Next-Generation
Carrier Ethernet Network. This multilayer architecture provides the
building blocks for complete carrier-class multiservice delivery.
The ASR 9000 operates at the edge of the Cisco IP NGN network. The
edge is typically composed of aggregation and distribution nodes deployed
in various physical topologies such as rings or hub-and-spoke
configurations. The aggregation node provides an intermediate aggregation
and multiplexing layer between the access network and the edge network.
The Cisco ASR 9000 can support aggregation and distribution PE functions
for residential broadband and business Carrier Ethernet services.
Residential broadband components include Internet access, broadcast TV,
video on demand, and Voice over IP. Business Ethernet components
include the MEF standard services of E-Line, E-LAN, and Access to
Layer 3 Virtual Private Network (VPN). This is the Cisco Ethernet Virtual
Circuit (EVC) infrastructure model.
The distribution node is the demarcation point between the aggregation
network and the service edge node, providing an Ethernet handoff to the
Broadband Remote Access Server (BRAS) or Broadband Network Gateway
(BNG) and Multiservice Edge (MSE). At the same time, the distribution
node provides aggregation for the aggregation network EoMPLS and H-
VPLS transport services and acts as an intermediate IP or MPLS
forwarding node for the IPTV services.
The Cisco edge networking portfolio, which includes the Cisco ASR 1000
and ASR 9000 Series Routers, Cisco 7600 and 12000 Series Routers, and
Cisco XR 12000 Series Routers, extends the IP Next-Generation Network
(NGN) Carrier Ethernet Design.
The Cisco ASR 9000 series provides architectural and functional
enhancements that translate to distinctive advantages and incremental
value for service providers by increasing the scalability, reliability, and
longevity that can help service providers reduce operating expenses.

Module 1 Cisco IP NGN Carrier Ethernet Architecture
Portal Monitoring Billing Subscriber Identity Address Policy

Mobile Database Mgmt Definition
Content Farm
Policy Control Plane (per subscriber)
Residential
Access Aggregation/Distribution Edge
MSPP
VoD TV VoIP
Cable
STB
U-PE
Business BRAS/BNG Core Network
ETTx Ethernet/ Digital MPLS /IP
Corporate
IP/MPLS Program DPI
Insertion
DSL
Residential Cisco ASR
9000
Content Farm
PE-Agg or
N-PE MSE
PON
STB
VoD TV VoIP

Consumer, Business, and Mobile Service Deployment

This slide demonstrates the delivery various service types and traffic types
by a single network. Simple residential, business, and mobile radio access
network (RAN) backhaul examples are illustrated.
The residential broadcast TV and VoD (and optionally VoIP) services are
delivered through the Cisco ASR 9000, which enforces service-level
agreements (SLAs) on individual services. High speed Internet
connectivity is provided by transporting customer traffic to a BNG/BRAS
device, which provides subscriber awareness and Layer 3 Internet access.
QoS can be implemented on a per-subscriber basis.
Business Layer 2 or Layer 3 VPNs and managed services are transported
across the core or are terminated at the Multiservice Edge. These services
require transport guarantees.
A transport scenario for a RAN backhaul application is also illustrated.

Module 1 Consumer, Business, and Mobile Service Deployment
Consumer, Business, and Mobile Service Deployment
L3
High speed internet
RAN backhaul L2 EoMPLS backhaul
Base Station
Controller
VoD Servers
BRAS
Core
PE-AGG N-PE
MSE
L2 VPN
L3 VPN
Business VPN
Video and voice L2 EoMPLS backhaul HSI
L3/MPLS edge distributed for L3 VPN, L2 VPN, VPLS VoD
efficient multicast and Broadcast TV
resiliency Business VPN
RAN backhaul

CISCO ASR 9000 Release 1 Features (1 of 5)
Cisco IOS XR Software Support
Modular software design: Provides routing-system scalability, high

availability, service isolation, and manageability to meet the mission-
critical requirements of next-generation networks.
Operating system infrastructure protection: Cisco IOS XR software
provides a microkernel architecture that forces all but the most critical
functions, such as memory management and thread distribution, outside of
the kernel, thereby preventing failures in applications, file systems, and
even device drivers from causing widespread service disruption.
Process and thread protection: Each processeven individual process
threadsis executed in its own protected memory space, and
communications between processes are accomplished through well-defined,
secure, and version-controlled application programming interfaces (APIs),
significantly minimizing the effect that any process failure can have on
other processes.
Cisco In-Service Software Upgrade (ISSU): Cisco IOS XR software
modularity sustains system availability during installation of a software
upgrade. ISSUs or hitless software upgrades (HSUs) allow you to upgrade
most Cisco ASR 9000 software features without affecting deployed services.
You can target particular system components for upgrades based on
software packages or composites that group selected features. Cisco
preconfigures and tests these packages and composites to help ensure
system compatibility.
Process restart: You can restart critical control-plane processes both
manually and automatically in response to a process failure versus
restarting the entire operating system. This feature supports the Cisco IOS
XR goal of continuous system availability and allows for quick recovery
from process or protocol failures with minimal disruption to customers or
traffic.
State checkpointing: You can maintain a memory and critical operating
state across process restarts to sustain routing adjacencies and signaling
state during a route-switch-processor (RSP) switchover.


Cisco ASR 9000 Release 1 Features (1 of 5)
Cisco IOS XR software support

Modular software design
Operating system infrastructure protection
Process and thread protection
Cisco In-service Software Upgrade (ISSU)
Process restart
State checkpointing


Flexible Ethernet and Layer 2 VPN
Ethernet virtual connections (EVCs): Ethernet services are supported

using individual EVCs to carry traffic belonging to a specific service type or
end user through the network. You can use EVC-based services in
conjunction with MPLS-based L2VPNs and native IEEE bridging
deployments.
Flexible VLAN classification: VLAN classification into Ethernet flow
points (EFPs) includes single-tagged VLANs, double-tagged VLANs (QinQ
and 802.1ad), contiguous VLAN ranges, and noncontiguous VLAN lists.
IEEE Bridging: The software supports native bridging based on IEEE
802.1Q, IEEE 802.1ad, and QinQ VLAN encapsulation mechanisms on the
Cisco ASR 9000 series.
IEEE 802.1s Multiple Spanning Tree (MST): MST extends the 802.1w
Rapid Spanning Tree Protocol (MSTP) to multiple spanning trees,
providing rapid convergence and load balancing.
MST Access Gateway: This feature provides a resilient, fast-convergence
mechanism for aggregating and connecting to Ethernet-based access rings.
Provider Backbone Bridging (PBB): IEEE 802.1ah
Virtual Private LAN Services (VPLS): VPLS is a class of VPN that
supports the connection of multiple sites in a single, bridged domain over a
managed IP or MPLS network.
Hierarchical VPLS (H-VPLS): H-VPLS provides a level of hierarchy at
the edge of the VPLS network for increased scale. QinQ access and H-
VPLS pseudowire access options are supported.
Virtual Private WAN Services or Ethernet over MPLS (VPWS or
EoMPLS): EoMPLS transports Ethernet frames across an MPLS core
using pseudowires. Individual EFPs or an entire port can be transported
over the MPLS backbone using pseudowires to an egress interface or
subinterface.
Pseudowire redundancy: Pseudowire redundancy supports the
definition of a backup pseudowire to protect a primary pseudowire that
fails.
Multisegment pseudowire stitching: Multisegment pseudowire
stitching is a method for interworking two pseudowires together to form a
cross-connect relationship.
VPLS with BGP-auto discovery: Standards-based method for auto-
discovering VPLS member and auto-creating a pseudowire mesh.

Flexible Ethernet services

Flexible Ethernet virtual connection (EVC) infrastructure
Flexible VLAN classification
IEEE Bridging
IEEE 802.1s Multiple Spanning Tree (MST)
MST Access Gateway
L2VPN services
Virtual Private LAN Services (VPLS)
Hierarchical VPLS (H-VPLS)
Pseudowire redundancy
Multi-segment pseudowire stitching
VPLS with BGP-auto discovery


Multicast, OAM, Layer 3 Routing, MPLS
IPv4 Multicast: IPv4 Multicast supports Internet Group Management Protocol

Versions 2 and 3 (IGMPv2/v3), Protocol Independent Multicast Source Specific
Multicast (SSM) and Sparse Mode (SM), Multicast Source Discovery Protocol
(MSDP), and Anycast Rendezvous Point (RP).
IGMP v2/v3 Snooping: This Layer 2 mechanism efficiently tracks multicast

membership on an L2VPN network. Individual IGMP joins are snooped at the
VLAN level or pseudowire level and then results are summarized into a single
upstream join message. In residential broadband deployments, this feature
enables the network to send only channels that are being watched to the
downstream users.
E-OAM (IEEE 802.3ah): Ethernet link layer OAM is a vital component of EOAM
that provides physical-link OAM to monitor link health and assist in fault
isolation. Along with 802.1ag, Ethernet link layer OAM can be used to assist in
rapid link-failure detection and signaling to remote end nodes of a local failure.
CFM (IEEE 802.1ag): Ethernet Connectivity Fault Management is a subset of

EOAM that provides numerous mechanisms and procedures that allow discovery
and verification of the path through 802.1 bridges and LANs.
MPLS OAM: This protocol supports label-switched-path (LSP) ping, LSP

TraceRoute, and virtual circuit connectivity verification (VCCV).
IPv4 Routing: Cisco IOS XR software supports a wide range of IPv4 services and
routing protocols, including Border Gateway Protocol (BGP), Intermediate System-
to-Intermediate System (IS-IS), Open Shortest Path First (OSPF), static routing,
IPv4 Multicast, Routing Policy Language (RPL), and Hot Standby Router Protocol
(HSRP) and Virtual Router Redundancy Protocol (VRRP) features.
IPv6 Routing: Cisco IOS XR software supports IPv6 services including OSPFv3
and static routing.
MPLS L3VPN: The IP VPN feature for MPLS allows a Cisco IOS Software or
Cisco IOS XR software network to deploy scalable IPv4 Layer 3 VPN backbone
services. An IP VPN is the foundation that companies use for deploying or
administering value-added services, including applications and data hosting
network commerce and telephony services to business customers.

Multicast
IPv4 PIM-SM, PIM-SSM
IGMP v2/v3 snooping
OAM
E-OAM (IEEE 802.3ah)
E-OAM (IEEE 802.1ag), also supported on bundle interfaces
MPLS OAM
Layer 3 routing
IPv4 Routing
IPv6 Routing
MPLS L3VPN


QoS, MPLS-TE, High Availability
QoS: Comprehensive QoS support with up to three million queues, Class-

Based Weighted Fair Queuing (CBWFQ) based on a three-parameter
scheduler, Weighted Random Early Detection (WRED), two-level strict priority
scheduling with priority propagation, and two-rate, three-color (2R3C) Policing
are all supported.
H-QoS: Four-level H-QoS support is provided for EVCs with the following
hierarchy levels: port, group of EFPs, EFP, and class of service. This level of
support allows for per-service and per-end user QoS granularity.
MPLS TE: Cisco IOS XR software supports MPLS protocols, such as Traffic
Engineering/Fast Reroute (TE-FRR), Resource Reservation Protocol (RSVP),
Label Distribution Protocol (LDP), and Targeted Label Distribution Protocol
(T-LDP).
MPLS TE Preferred Path: Preferred tunnel path functions let you map
pseudowires to specific TE tunnels. Attachment circuits are cross-connected to
specific MPLS TE tunnel interfaces instead of remote provider-edge router IP
addresses (reachable using Interior Gateway Protocol [IGP] or Label
Distribution Protocol [LDP]).
MPLS TE FRR: This feature delivers Layer 3 protection switching for
networks currently configured with MPLS LSPs. MPLS TE FRR provides
temporary rerouting around a failed link or node.
Bidirectional Forwarding Detection (BFD): BFD is a detection protocol

that is designed to provide fast-forwarding path failure detection times for all
media types, encapsulations, topologies, and routing protocols. It is supported
for OSPFv2, IS-IS, PIM v4, and BFD-triggered FRR.
Standard IEEE 802.3ad link aggregation bundles: A bundle of multiple
links can be supported to provide added resiliency and the ability to load
balance traffic over multiple member links.
NSF: NSF support for BGP, OSPF, IS-IS, MPLS-TE, LDP, and T-LDP allows
traffic to continue to be forwarded if a failure occurs. This feature requires
neighboring nodes to be NSF-aware.
NSR: NSR maintains OSPFv2 and LDP sessions and state information across
stateful switchover (SSO) functions as well as ISSU support on a provider-
edge device providing MPLS VPN services.

QoS
H-QoS: Four-level H-QoS support is provided for EVCs with the following
hierarchy levels
MPLS TE
MPLS TE
MPLS TE Preferred Path
High availability
MPLS TE FRR
Bidirectional Forwarding Detection (BFD)
Link aggregation bundles
NSF
NSR


Manageability and Security
Cisco IOS XR software manageability: This feature provides industry-

standard management interfaces, including a modular command-line
interface (CLI), Simple Network Management Protocol (SNMP), and native
XML interfaces.
Cisco Active Network Abstraction (ANA): Cisco ANA is a flexible,
vendor-neutral network resource-management solution for a
multitechnology and multiservice network environment. Operating
between the network and the operations-support-system (OSS) layer, Cisco
ANA aggregates virtual network elements (VNEs) into a software-based
virtual network, much as real network elements create the real-world
network. Cisco ANA dynamically discovers network components and tracks
the status of network elements in close to real time.
Cisco IOS XR software security: This software provides comprehensive
network security features, including ACLs; control-plane protection;
routing authentications; authentication, authorization, and accounting
(AAA); TACACS+; IP Security (IPsec); Secure Shell (SSH) Protocol;
SNMPv3; and leading Routing Policy Language (RPL) support.
Layer 2 ACLs: a security feature that filters packets based on MAC
addresses.
Layer 3 ACLs: This feature matches ACLs by IPv4 protocol packet
attributes.
Security: Many critical security features are supported:
Standard 802.1ad Layer 2 Control Protocol (L2CP) and bridge-protocol-
data-unit (BPDU) filtering
MAC limiting per EFP or bridge domain

Unicast, multicast, and broadcast storm control blocking on any
interface or port
Dynamic Host Configuration Protocol (DHCP) Snooping
Control-plane security CISCO ASR 9000 Release 1 Features (5 of 5)

Manageability
Cisco IOS XR Software manageability
Cisco Active Network Abstraction (ANA)
Security
Layer 2 ACLs
Layer 3 ACLs
Many critical security features are supported:
! Standard 802.1ad Layer 2 Control Protocol (L2CP) and bridge-protocol-data-
unit (BPDU) filtering
! MAC limiting per EFP or bridge domain
! Unicast, multicast, and broadcast storm control blocking on any interface or
port
! Dynamic Host Configuration Protocol (DHCP) Snooping
! Control-plane security

CISCO ASR 9000 R3.9.0 Features

SIP-700 SPA with Channelized OC-12 SIP, Eight-port 10GE LC, and
Two-port 10GE + 20-port GE LC
Feature Licensing: Licensing entitlement required for advanced L3 VPN
support per LC, advanced G.709 optics support per LC, or advanced Inline
Video Monitoring support per chassis.
Traffic mirroring: Traffic Mirroring copies traffic from one or more Layer 2
interfaces or sub-interfaces, including Layer 2 link bundle interfaces/sub-
interfaces, and sends the copied traffic to one or more destinations for analysis
by a network analyzer.
SynchE: Provides a PHY-level frequency distribution mechanism through the
GE/10GE ports from external timing references.
BGP Prefix Independent Convergence (PIC): This feature provides the

ability to converge BGP routes using the fast-convergence innovation that is
unique to Cisco IOS XR software.
BFD support for Hot Standby Router Protocol/Virtual Router
Redundancy Protocol (HSRP/VRRP): This support allows HSRP/VRRP
state to be tracked in a many-to-one model using BFD. This provides faster
convergence with lower CPU and memory overhead for improved system scale.
NSR for BGP: BGP NSR makes routing failures invisible to external BGP
peers, with no disruption of forwarding and no impact to Layer 3 convergence.
IP Fast Reroute: Provides subsecond IP fast convergence for both IS-IS and
OSPF routing protocols in a properly designed network topology.
IPv6 IS-IS: Support for IPv6 addresses in the Integrated IS-IS routing
protocol.
Y.1731: The first phase of Y.1731 implementation and supports the collection
of round-trip delay and jitter results using IEEE 802.1ag loopback packets and
ITU Y.1731 Delay Measurements.
Video Monitorng: Video monitoring is a service to monitor application
(mainly video) traffic quality by measuring per-flow statistics on the router.
The feature provides scalable and efficient inline monitoring of flows.
MoFRR: Multicast-only FRR (MoFRR) is a Cisco IOS XR innovation to
improve multicast network convergence times. The basic idea of MoFRR is to
send a secondary join to a different upstream interface. The network then
receives two copies of the multicast video stream over two separate and
redundant paths through the network. When a primary path fails, it can
switch over to the backup path instantly without issuing a new PIM join.

Hardware
A9K-SIP-700 line card
A9K-8T and A9K-2T20GE line cards
Feature Licensing
Layer 2
Traffic mirroring
MPLS-TE Path protection
Synchronous Ethernet
Layer 3
BGP Fast Convergence or Prefix Independent Convergence (PIC)
BFD support for HSRP/VRRP
NSR for BGP
IP Fast Reroute (IP FRR)
IPv6 IS-IS
OAM and Monitoring
Y.1731 Performance Monitoring
Inline Video Monitoring (also known as Media Monitoring)
Multicast
Per-flow Multicast only Fast Reroute (MoFRR)
IGMP Snooping enhancements
QoS
H-QoS over link aggregation groups


16-port 10GE LC
Layer 3 load balancing on LAG: A LAG can be configured to use the

embedded Layer 3 information in calculation of the hash.
MST topology tracking: Provides the ability to track the number of times a
MST topology change occurs. This can be particularly useful in
troubleshooting and identifying unstable Layer 2 networks managed by
MST.
PBB: The IEEE 802.1ah standard provides a means for interconnecting
multiple Provider Bridged Networks in order to build a truly large-scale,
end-to-end Layer 2 Provider Bridged Network. 802.1ah builds on the IEEE
802.1ad standard and eliminates some of its limitations.
VLAN hopping: Allows some packets to be deliberately hopped (leaked)
from one VLAN to another VLAN. This can be used in situations where
different traffic types share a common VLAN but need to follow different
forwarding models after service classification.
L2TP: Layer 2 Protocol Tunneling is particularly useful at the UNI of a Q-
in-Q network, so that customer frames can be carried across the provider's
network even though the provider's devices may be standard 802.1Q
bridges. For a set of protocols industry standard and Cisco proprietary
protocols, identified by name, L2PT allows these protocol frames to either
be dropped, forwarded, forwarded after rewriting the destination MAC
address, or locally peered.
MVRP-lite: Designed for the edge of an MVRP network and operates in
static node role without having to enact attribute registrations in the local
forwarding table.
MPLS-TE Auto BW: MPLS-TE monitors the traffic rate on a tunnel
interface. Periodically, MPLS-TE resizes the bandwidth on the tunnel
interface to align closely with traffic in the tunnel.
mVPN: A standards-based feature that transmits IPv4 multicast traffic
across an MPLS VPN cloud
6PE/VPE: IPv6 over MPLS feature.that allows IPv6 domains to
communicate with each other over an MPLS IPv4 core network
Cisco Netflow: Cisco Netflow is useful for resource accounting, network
planning, and network monitoring operations.

Hardware
16x10GE LC
Layer 2
Layer 3 load balancing over Layer 2 link aggregation group enhancement
MST Access Gateway also supported over link bundles
MST topology tracking
Provider Backbone Bridging (PBB or 802.1ah)
Policy Based Forwarding (PBF or VLAN hopping)
Layer 2 Protocol Tunneling (L2TP) support
802.1ak or Multicast VLAN registration-lite (MVRP-lite)
MPLS-TE auto-bandwidth
BGP-AD with Label Distribution Protocol (LDP) signaling
MPLS L3VPN
Multicast VPN (mVPN)
IPv6 6PE/VPE
OAM and Monitoring
CFM supported over link aggregation bundle interfaces
CFM supported over link aggregation bundle member interfaces
Y.1731 Alarm Indication Signal (AIS) support
Cisco Netflow v9


The major Cisco ASR 9000 features that have been added as part of
the IOS XR R4.0.0 release are listed on the following slide.
____________________________ Note _________________________

Please refer to Release Notes for Cisco ASR 9000 Series Aggregation
Services Routers for Cisco IOS XR Software Release 4.0.0 for more details.
__________________________________________________________________

Cisco ASR 9000 R4.0.0 Features

Hardware
A9K-RSP-8G (RSP with 8 Gig memory)
Four new OC-N/STM-N SPAs for the SIP-700 card
Layer 2
Multi-Chassis Link Aggregation
MPLS-TE Automatic backup tunnels
mVPN
BGP scale and support enhancements
Any Transport over MPLS (AToM) support
Layer 3
Inter-AS Option B for VPNv4/VPNv6
RIPv2
Quality of Service in-service modification


The major Cisco ASR 9000 features that have been added as part of
the IOS XR R4.0.1 release are listed on the following slide.
____________________________ Note _________________________

__________________________________________________________________

Cisco ASR 9000 R4.0.1 Features

Hardware
Five new SIP-700 T3/E3 and OC-3/STM-1 SPAs
Layer 2
CFM on Multi-Chassis Link Aggregation
Dynamic Link Aggregation load balancing enhancements
Any Transport over MPLS (AToM) enhancements
Per-VLAN STP Gateway
Integrated Routing and Bridging (IRB) on Ethernet LCs
Traffic Mirroring enhancements
Enhance L2 Performance monitoring
Layer 3
IP Fast Reroute
ACL-based forwarding

CISCO ASR 9000 SIP-700 Features (starting R3.9.0)

Supported SPAs:
Channelized OC-12 (ChOC-12)
Two ports per SPA, four ports per SIP or slot
Supports 1344 T1s per slot
Ch-OC12 SPA encapsulation support:
High-level Data-link control (HDLC)
Point-to-point Protocol (PPP) encapsulation
Multi-link PPP (ML-PPP)
Up to 2600 ML-PPP bundles per chassis
QOS/uRPF/ACLs supported on both serial and ML-PPP interfaces
Multi-router-automatic protection switching (MR-APS)
Inter-chassis stateful switchover (IC-SSO)
RIP/BGP/OSPF/ISIS/EIGRP/static routing support over serial and ML-
PPP
Full QoS support
Cisco Netflow
Line timing

CISCO ASR 9000 SIP-700 Features (starting R3.9.0)

SIP-700 Features (available starting R3.9.0)
Supported SPAs:
Channelized OC-12 (ChOC-12)
! Two ports per SPA, four ports per SIP or slot
! Supports 1344 T1s per slot
Ch-OC12 SPA encapsulation support:
High-level Data-link control (HDLC)
Point-to-point Protocol (PPP) encapsulation
Multi-link PPP (ML-PPP)
! Up to 2600 ML-PPP bundles per chassis
QOS/uRPF/ACLs supported on both serial and ML-PPP interfaces
Multi-router-automatic protection switching (MR-APS)
Inter-chassis stateful switchover (IC-SSO)
RIP/BGP/OSPF/ISIS/EIGRP/static routing support over serial and ML-PPP
MPLS
Full QoS support
Cisco Netflow
Line timing
SIP-700 with channelized

OC-12 SPAs

SIP-700 R4.0.0 Hardware

Four new SPAs have been added to the SIP-700 portfolio as part of the
IOS XR R4.0.0 release.
____________________________ Note _________________________

__________________________________________________________________


Hardware
1-Port Channelized OC48/STM16 DS3 SPA (SPA-1XCHOC48/DS3)
2-Port OC-48/STM16 SPA (SPA-2XOC48POS/RPR)
8-Port OC12/STM4 SPA (SPA-8XOC12-POS)
1-Port OC192/STM64 POS SPA (SPA-OC192POS-XFP)
Check Release Notes for Cisco ASR 9000 Series Aggregation Services Routers for
Cisco IOS XR Software Release 4.0.0 for SIP-700 feature enhancement details.


Five new SPAs have been added to the SIP-700 portfolio as part of the
IOS XR R4.0.1 release.
____________________________ Note _________________________

__________________________________________________________________

Module 1

Hardware
4-Port Clear Channel T3/E3 SPA (SPA-4XT3E3)
2-Port Clear Channel T3/E3 SPA (SPA-2XT3E3)
1-Port Channelized OC-3/STM-1 SPA (SPA-1XCHSTM1/OC3)
4-Port OC-3/STM-1 POS SPA (SPA-4XOC3)
8-Port OC-3/STM-1 POS SPA (SPA-8XOC3)
Check Release Notes for Cisco ASR 9000 Series Aggregation Services Routers for
Cisco IOS XR Software Release 4.0.1 for SIP-700 feature enhancement details.

Cisco ASR 9000 Essentials Lab Topology

This course includes hands-on lab exercises to be performed on a
Cisco ASR 9000 network. The Cisco ASR 9000s are connected across a
Cisco 12000 core running Cisco IOS software. The Core represents a
typical IP and MPLS core. Layer 2 and Layer 3 services will be built
between Cisco ASR 9000s.
Additional devices are used to simulate customer equipment and to verify
service configuration.
You will be assigned to a particular pod by your instructor.

Module 1 Cisco ASR 9000 Essentials Lab Topology

Ethernet Virtual Connection

UNI UNI
NNI NNI
P P
PE PE
CE CE
GE GE GE GE GE
Cisco Cisco
ASR Cisco Cisco ASR
9000 12000 12000 9000
Cust A Ethernet or MPLS Ethernet or MPLS Cust A

Loc 1 Access and IP or MPLS Core Access and Loc 2
Aggregation Aggregation

Documentation References
Use the URLs listed the on the slide to locate additional information on the
Cisco ASR 9000 Series Aggregation Series Routers.

Module 1 Documentation References
Documentation and References
Cisco ASR 9000 information on Cisco.com:

http://cisco.com/en/US/products/ps9853/index.html
Cisco ASR 9000 User Documentation
http://cisco.com/en/US/products/ps9853/tsd_products_support_series_home.html
Cisco IOS XR Software User Documentation
http://www.cisco.com/en/US/products/ps5845/tsd_products_support_series_home.html

Summary
Introduction to the Cisco ASR 9000 Series Aggregation Services Routers
In this module, you learned to:
Describe the Cisco ASR 9000 features and functions

List and describe different chassis types, control cards, and traffic-
carrying cards
Describe Cisco ASR 9000 network applications

Describe Cisco ASR 9000 deployment scenarios
Locate user documentation and support information

Module 2
Cisco ASR 9000 Series Hardware
Overview
Description
This module describes the Cisco ASR 9000 series chassis hardware
features and functions, including the field-replaceable units (FRUs) and
components.
Objectives
List the features and functions of the Cisco ASR 9000 Series Chassis
List and describe the features and functions of the FRUs and
components that comprise the Cisco ASR 9000 chassis
List and describe the features and functions of the Cisco ASR 9006 and
ASR 9010 chassis:
! Route Switch Processor cards
! Switch fabric
! Line Cards
! Cooling system
! Power system

Cisco ASR 9000 Series Hardware Module 2
Cisco ASR 9000 Series Chassis

Cisco ASR 9006
The Cisco ASR 9006 router is a six-slot chassis, 40-Gbps-per-slot that
delivers 160Gbps capacity in a compact ! - rack form factor.
Chassis Dimensions:
Width: 18.9 inches (48.1cm)

Depth: 28.9 inches (73.5cm)
Height: 17.5 inches (44.5cm)
Weight: 230 lbs (104.33 kg) fully loaded
Slots:
Six-slots each measuring 14.5 inches x 21.5 inches

! 4-slots are for Line Cards (LCs) each measuring 1.775 inches wide
! 2-slots are dedicated for Route Switch Processor (RSP) cards each
containing switch fabric and measuring 1.5 inches wide
! Both RSPs and LCs are interchangeable with 10-slot chassis
Cooling:
Two redundant fan trays:

! Above LC slots and non-interchangeable with 10-slot chassis
! Each fan tray contains six fans
! One rear replaceable air filter
Power:
One power shelf containing three input power modules interchangeable

with the six input power modules of the 10-slot chassis
! Three input power modules provide either AC or DC power
22 Version 4.0.1 Cisco XR 9000 Series Essentials

Module 2 Cisco ASR 9000 Series Chassis
Cisco ASR 9006
Dimensions:
Width: 18.9 in. (48.1cm)
Fits 19 in. rack
Depth: 28.9 in. (73.5cm) Rear air
Fits 800mm ETSI cabinet exhaust
Height: 17.5 in. (44.5cm)
Fits 10 RU or ! rack
Two system
Weight: 230 lbs (104.33 kg)
fan trays
Slots: Side
4x Line Card slots air
pitch 1.775 in.; LC 14.5 in. X 21.5 in. intake
2x RSP slots
pitch 1.5 in.
Three
Cooling:
Cable modular
Two fan trays
Redundant cooling management power
supplies
Power:
AC or DC Power Shelf
Redundant power modules

Cisco ASR 9010

The Cisco ASR 9010 router is a 10-slot chassis, 40-Gbps-per-slot that
delivers 320Gbps capacity in a compact " - rack form factor.
Chassis Dimensions:
Width: 18.9 in. (48.1cm)

Depth: 28.9 in. (73.5 cm)
Height 36.75 in. (93.35 cm)
Weight: 375 lbs (170.5 kg) fully loaded

Slots:
10-slots each measuring 14.5 in. x 21.5 in.

! Eight-slots are for Line Cards (LCs) each measuring 1.775: wide
! 2-slots are dedicated for RSP cards each containing switch fabric
and measuring 1.5 in. wide
! Both RSPs and LCs are interchangeable with 10-slot chassis
Cooling:
Two redundant fan trays:

! Below LC slots and non-interchangeable with 6-slot chassis
! Each fan tray contains 12 fans
! One front replaceable air filter
Power:
Two power shelves containing six input power modules interchangeable

with three input power modules of the six-slot chassis:
! Each power shelf holds three input power modules providing either
AC or DC power

Module 2 Cisco ASR 9000 Series Chassis
Cisco ASR 9010
Dimensions: Rear air

Width: 18.9 in. (48.1cm) exhaust
Fits 19 in. rack
Depth: 28.9 in. (73.5cm)
Fits 800mm ETSI cabinet
Height: 36.8 in. (93.4cm) Integrated
Fit 21 RU or ! rack cable
Weight: 375 Lbs (170.5 kg) management
with cover
Slots:
8x Line Card slots
pitch 1.775 in.; LC 14.5 in. X 21.5 in.
2x RSP slots
pitch 1.5 in.
Cooling: Front air System

Two fan trays intake fan trays
Redundant cooling
Power:
Two AC or DC Power Shelves Six modular
Redundant power modules power supplies

Cisco ASR 9000 Series FRUs and Components

Overview
This section lists the main components of a Line card (LC) chassis. The
following is a list of the field-replaceable units (FRUs):
RSP: System processor for router:
! Switch fabric (internal to RSPs) Path by which data flows from
ingress to egress ports
! Control Plane Gigabit Ethernet Part of system backplane called
the Ethernet Out of band Communication (EoBC) bus, which is
used for communications and control between line cards, RSPs and
subsystems
! CANbus (Controller Area Network bus) Part of system backplane
which is a two wire system used for monitoring inventory, power,
temperature and alarms
Line cards: Physical connections to router
Cooling subsystem: Fan Trays
Power subsystem: AC or DC power modules
Key points:
Data forwarding is fully distributed on the line cards.
The Control plane is split among RSP and LC CPUs (each LC has the same
type of CPU as the RSP).
Layer 2 protocols, BFD, CFM, Netflow run on the LC CPU to support
higher scale.
____________________________ Note _________________________
Throughout this course the Fabric Interface chip on the line cards is
referred to as the Fabric Interface ASIC (FIA), Fabric Interface, and
Fabric I/O interchangeably.
The Switch Fabric chip is referred to as Switch Fabric ASIC or Fabric
interchangeably.
__________________________________________________________________

Module 2 Cisco ASR 9000 Series FRUs and Components
Cisco ASR 9000 Series FRUs and Components
RSP0 Fabric I/O CPU0

C PU
RSP1 Fabric I/O CPU0 Legend
8641D
Punt Path Data Plane

Fabric Fabric
Sys tem 2 Santa Fabric
B ellagio 2
GE System Fabric GE Control Plane
Timing Cruz Switch Timing Switch
Arbiter Arbiter
Backplane
40x1GE Fabric I/O PHY

GE 8x10GE Fabric I/O GE 4x10GE Fabric I/O GE
PHY PHY Power Cooling
Fixed Fixed Fixed System System
LC CPU LC CPU LC CPU
Bridge Bridge Bridge Bridge Bridge Bridge
NPU NPU NPU NPU NPU NPU NPU NPU NPU NPU NPU NPU
10GE XFP
10GE XFP
10GE XFP
10GE XFP
10GE XFP
10GE XFP
10GE XFP
10GE XFP
10GE XFP
10GE XFP
10GE XFP
10GE XFP
10 x 10 x 10 x 10 x
SFP SFP SFP SFP

Cisco ASR 9006

The Cisco ASR 9006 router is a 6-slot chassis in a small ! - rack form
factor.
Two RSP slots
! Active and Standby RSP each contain dual Switch Fabric
Four LC slots
Two fan trays and one filter
One power shelf containing three AC power modules or three DC power
modules:
! Chassis power is based on a distributed power architecture centered
around a -54 VDC power bus on the chassis backplane
! Two power modules provide 1 + 1 minimum redundancy while three
power modules provide 2 + 1 maximum redundancy
Cisco ASR 9010

The Cisco ASR 9010 router is a 10-slot chassis in a small " - rack form
factor.
Two RSP slots

! Active and Standby RSP each contain dual Switch Fabric
Eight LC slots
Two fan trays and one filter

Two power shelves each containing 3 AC Power Modules or 3 DC Power
Modules:
! Chassis power is based on a distributed power architecture centered
around a -54 VDC power bus on the chassis backplane
! One power module in each shelf provides 1 + 1 minimum
redundancy while six power modules provide 5 + 1 maximum
redundancy

Module 2 Cisco ASR 9000 Series FRUs and Components
Cisco ASR 9006 and ASR 9010

Cisco ASR 9000 Power Subsystems

Overview
The Cisco ASR 9000 chassis can be powered by either AC (200240 or 220
240 VAC) or DC (48 or 60 VDC) power. The chassis power subsystem
takes the facility power and converts it to the DC voltage necessary to
power chassis components.
The power subsystem comprises:
Redundant AC or DC power
AC or DC power modules
Single power bus bar
Chassis backplane
Special components on cards or modules, such as DC-to-DC converters
or electromagnetic interference (EMI) filters

Module 2 Cisco ASR 9000 Power Subsystems
Cisco ASR 9000 Power SubsystemsOverview

Power Architecture
The Cisco ASR 9000 chassis power architecture uses a load balancing
power bus to provide:
Redundant power for all components in the chassis
Redundancy for both AC- or DC-powered chassis
Power shelf provides power input to the backplane of the chassis

All power supplies feed the backplane bus (54V) where it is distributed
and load balanced across the RSP, LC, and fan tray load. Each RSP and
LC has its own power regulators.
With this power architecture the Cisco ASR 9000 chassis still operates
normally if one AC or DC power module fails. It takes two failures before
the system is degraded. Talk to a Cisco representative about a power
budget for possible power requirements.
This architecture, which applies to either AC- or DC-powered chassis, is
built around:
One or two power shelves
Three to six power modules
Single bus bar from shelf to backplane

Power Architecture
Power subsystem architecture provides:

Same architecture for AC and DC powered chassis
Redundant AC or DC power
Chassis still operates normally when 1 AC or DC
Power Module fails
Different power requirements depend on
chassis configuration.
Pay-as-you-grow power
Single Power Bus
No Power Load Zones

Cisco ASR 9006 AC and DC power

The AC power modules are the same for the ten-slot as the six-slot system.
The DC power modules differ on the six-slot in that it uses the 1700 W
power module where the ten-slot does not support it.
Description Value
Total AC input power 3400 VA (volt-amperes) per AC power supply
Rated input voltage 200240 VAC nominal (range: 180 to 264 VAC)
220240 VAC (UK)
Rated input line frequency 50/60 Hz nominal (range: 47 to 63 Hz)
Input current rating 15 A maximum at 200 VAC

13 A maximum at 220 to 240 VRMS (UK)
Source AC service requirement 20 A North America, 16 A international, 13 A UK
Description Value
Total DC input power 1700 W DC power supply (1500 W DC output)
Total DC input power 2300 W DC power supply (2100 W DC output)
Rated input voltage 48 VDC nominal North America

60 VDC nominal in the European Community
Input current rating 41 amperes maximum with single input to each

module, with three modules in the system
providing maximum system power of 7360 W of
54 VDC output power.
Source DC service requirement Sufficient to supply the rated input current.

Cisco ASR 9006 and ASR 9010 AC and DC Power
Cisco ASR 9006

The AC power module provides 3400 VA (3kw)
The DC power modules provide 1700 W (1.5kw) 6 Slot Only
The DC power modules provide 2300 W (2.1kw)
Cisco ASR 9010

The AC power module provides 3400 VA (3kw)
The DC power module provides 2300 W (2.1kw)
ASR 9000 AC
Power Connections
ASR 9000 DC
Power Connections

Power Check and Rules

Power Management is automatically enabled on the Cisco ASR 9000
chassis. It has the capability to prevent an LC from being powered on in
the event that there is not enough system power to available to
accommodate the LC.
Power Management uses Power Monitor software feature which allows
user to monitor the power used and how much is available.
Power Management generates alarms if there is not sufficient power.
Failure modes/behaviors:
In the normal case (with the power management software enabled) the
following rules apply: any time a component is added to the system, the
shelfmgr process checks to see if there is enough power available to boot
that component. If there's sufficient power available, the card will boot. If
not, the card stays in the UNPOWERED state.
In order to bring the card up, there must be enough available power (either
by adding power supplies or by removing other components) and THEN the
LC must explicitly be re-booted via the CLI. Simply adding another power
supply will not automatically bring up any UNPOWERED components.
If a power supply fails and this brings the amount of available power below
what the system needs, there are two different issues to consider: 1. If the
software tries to provision for the system (this is the conservative, high-
temperature, high-traffic number) vs 2. how much power the system is
actually drawing at that given instant in time (this can vary with traffic
load and temperature, etc).
If a power supply failure drops the system below what the software needs,
the system tries its best to keep the existing hardware up. Given that
there's a lot of conservatism in the software and in the power numbers,
this means that normally nothing will happen. However, if you are below
the required power level and a card resets for any reason, it will NOT be
brought back up -- because when it does come back up the rules above
about "when a component is added" apply.
For these reasons, using a fully redundant power supply setup is highly
recommended.
AC power supplies operate in pairs: one supply from the pair connected to
source A, and the other connected to source B. In the case of a failure of
one power source, the remaining N/2 power supplies are sufficient to
operate the system.
DC power supplies operate in N+1 mode: each power supply should be
connected to feeds from both source A and source B. Each source must be
able to meet the entire required load of the supply to protect against
failure of the other source.

.Power Check and Rules
Use the Admin command show environment power-supply to

display current power usage information.
Available power is checked when:
An LC is inserted
An LC is powered up via the CLI
An LC is reset via hw-module reload
If the system does not have enough available power to
accommodate the LC, then the LC becomes UNPOWERED.
Installing new power supplies will not automatically power up any
UNPOWERED line cards. The user can force a recheck using:
hw-module reload location <>
RSPs and fan trays have priority.
LCs power up numerically from Slot 0 onward.

Cisco ASR 9000 Series Cooling Subsystem

Overview
The complete chassis cooling subsystem provides the following:
The Cisco ASR 9006 and ASR 9010 have two fan trays
All Cisco ASR 9000 Series routers use inlet and outlet air vents and
bezels with impedance carriers to control air flow and temperature
monitored by temperature sensors to prevent chassis over heating.
Operating software controls the cooling system by monitoring the
temperature sensors and sending alarms that can cause the system to
power down if temperature gets to high.
All Cisco ASR 9000 Series routers use air filters to keep the chassis
components clean and cool, air flow restriction can occur if filter gets
dirty.
The Cisco ASR 9000 Series power modules have cooling fans separate
from the chassis cooling.
Cooling and power systems are monitored by the CAN bus.

Module 2 Cisco ASR 9000 Series Cooling Subsystem
Cisco ASR 9000 Series Cooling Subsystem Overview
The complete line card chassis cooling subsystem

includes:
Fan trays
Temperature sensors distributed on line cards and
modules in the chassis
Operating software to control the cooling system
Air filters
Inlet and outlet air vents and bezels
Impedance carriers for empty chassis slots
Power Supplies with internal cooling fans
Fan Tray Fan Tray

Front Front
Filter
Front Filter
Rear
ASR 9010 ASR 9006

Cisco ASR 9000 RSP Functions

RSP
The Route Switch Processor:

Serves as active (active) and standby (redundant)
Provides console ports for router configuration
Loads Cisco IOS XR operating system to all the line cards during power up
Connects to the Ethernet Out of Band Communication bus (EoBC) to
provide a control path to all cards and modules
Connects to the CAN bus for monitoring inventory, power,
temperature, and alarms
Connects to the Switch Fabric to provide a data path to all line cards
Updates routing tables; synchronizes table on line cards
Designated Shelf Controller
Implements many of the control plane operations for the entire chassis and
performs the following:
Monitors temperature and voltage of other cards and modules in the
entire chassis
During discovery RSPs and line cards are located in the chassis and the
lowest slot RSP becomes the active RSP and the DSC.
Secure Domain Router
Provides Owner Secure Domain Router (SDR) capabilities in a single

chassis:
Owner-SDR is the active RSP and DSC in the system
Non-owner SDR in the Cisco ASR 9000 are not supported

ASR9K-RSP-8G
A Cisco ASR 9000 Series system configuration requiring high multiple

dimensional scale requires an RSP with 8G memory to support the
increased system scale.

Module 2 Cisco ASR 9000 RSP Functions
Cisco ASR 9000 RSP Functions

RSP Functions
Route Switch Processor (RSP)

!Performs control plane an management functions
!Designated shelf controller (DSC)
!Active (Primary)
!Standby (Redundant)
!Secure domain router (SDR)
" Owner-SDR (Default)
" Non-Owner SDR (no support)
Interchangeable across all Cisco ASR 9000 Chassis

An RSP with 8G of memory is available starting R4.0.0
(ASR9K-RSP-8G)
2011 Cisco Systems, Inc. All rights reserved. Version 4.0.1 Cisco ASR 9000 EssentialsModule 2/16

RSP Arbitration
Active and Standby
RSPs in the 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:
REST_ST, FW_RDY_ST, FW_RDY_WAIT_ST, MASTER_ST
First RSP to become ready or the one in the lowest numbered slot in the
chassis is elected Master.
DSC Election
When the RSP is booted, the Active RSP becomes the designated shelf
controller (DSC)

Module 2 RSP Arbitration
RSP Arbitration
RSPs arbitrate to have an active-standby

relationship.
Chassis powers up, RSPs boots
RSPs exchange messages with all other RSPs
Based on testing, each RSP decides if it is ready
to become the active RSP
Arbitration software chooses the active RSP from
the RSPs that have asserted the Ready signal
or based upon lowest line card slot number
DSC election, defaults to Active (owner-SDR).

RSP Front Panel

For redundancy, every LC chassis provides for two RSP cards in dedicated
slots RSP0 and RSP1. The front panel includes:
Two 10/100/1000-Mb Management Ethernet Ports (Eth0, Eth1)
Two asynchronous serial ports, auxiliary and console; both use RJ-45
receptacles:
! Auxiliary port provides a data terminal equipment (DTE) interface
often used to connect a modem, a channel service unit, or other
equipment
! Console port provides data circuit-terminating equipment (DCE)
interface
Two Building Integrated Timing Supply ports (BITS) for connecting to
an external clock source (BITS 0 and BITS 1)
Alarm Out DB9 connector
Compact Flash
Alarm Cutoff and LAMP Test
Eight discrete LEDs
! Power Fail (FAIL)
! Critical Alarm (CRIT)
! Major Alarm (MAJ)
! Minor Alarm (MIN)
! Synchronization (SYNC)
! Internal Hard Disk Drive (HDD)
! External Compact Flash (CF)

! Alarm Cutoff (ACO)
One rows of alphanumeric displays organized with four characters to
indicate the following information:
! Status of the RSP and System error messages

RSP Front Panel
MGMT
ETH 0
MGMT Management
ETH 1
Management Network RJ-45 Ethernet Port 1
Ethernet Port 0 Con
AUX
RJ-45
Console Port BITS 0
BITS0 and BITS1
BITS 1 (building integration
RJ-45 timing supply)
Auxiliary Port ALARM
PID/VID
Compact Flash:
Removable media
ACO
Lamp
Reset
Fail Sync
Critical HDD
Major CF
Minor ACO
LED Status display

RSPHardware Components
The opposite page shows a block diagram of a RSP (RSP).
Route Switch Processor Memory: comprised of the following:
DRAM, bank 1 and 2 (two 2-GB or 4-GB memory cards)
An 8GB memory version of the RSP is also available
Hard Disk, 70-GB SAS HDD
CPU: dual-core power PC processors runs at 1.5 GHz.
Hard Disk Drive: 70-G hard disk drive (HDD) is an SAS (Serial Attached
SCSI) hard disk used for gathering debug information, such as core dumps
and error log data from the RSP or LCs.
Compact Flash: RSP card provides one Compact flash slot that provide
up to 4-GB of flash storage. The Compact flash card is accessible externally
and removable, and allow you to transfer images and configurations to
them.
Switch Fabric: switch fabric is configured as a single stage of switching
with multiple parallel planes. Each fabric plane is a single-stage, non-
blocking, packet-based store-and-forward switch. The fabric is responsible
for getting packets from one LC to another, but it has no packet processing
capabilities. The switch fabric is 1+1 redundant, deployed as two fabric
planes on each of the redundant RSPs. Each RSP is capable of delivering
80 Gbit/s per slot switching capacity to meet the chassis throughput goals,
allowing for full redundancy.

RSPHardware Components
Switch Fabric
Switch Fabric
Controller
Dual-Core
Route Processor
Punt FPGA
70G Harddisk Drive
4 or 8 Gigabit DRAM
Compact Flash
The RSP card physically contains both the management/control plane and
the Switch Fabric. They are logically separated.

RSPBlock Diagram
The CPU, System controller, Timing, backplane Ethernet and the Switch
Fabric modules such as Switch Fabric 0/1, Fabric I/O, and
Scheduler/Arbiter are the main components of the RSP card:
CPU: RSP uses a Dual Core Power PC Processor 1.5 GHz
DRAM: two 2-GB memory cards (or two 4-GB memory cards)
Hard Disk Drive: SAS 70 GB
Compact Flash: 2 GB or 4 GB
Flash: Internal 4 GB
System controller: Provides the interfaces between (CPU, AUX, NVRAM,
Boot flash, and Alarms) on the RSP.
NVRAM: 512 KB
Boot flash: 128 MB
Timing: Building Integrated Timing Supply (BITS) external timing or
internal Strat-3 clock.
Switch Fabric: Takes packets from one of the Fabric I/O under control of
the Scheduler/Arbiter.
Fabric I/O: Communicates with Fabric Scheduler/Arbiter to setup the
transfer of data through the Fabric.
Fabric Scheduler/Arbiter: Provides control setup for data transfer
through the Fabric.
Backplane Ethernet: Ethernet Out of Band Communications (EOBC):
Control Plane communications between cards in the chassis.
Backplane CAN bus: monitors the environment (voltage and
temperature), controls soft start of the 5-V and 3.3-V DC-to-DC converters,
controls the alphanumeric front-panel displays, and also holds information
unique to this particular card such as the serial number, hardware part
number, and revision.

RSPBlock Diagram
BITS / telco
SETS / Strat-3 Clock Time clocking to
Sync 0 / 1
BITS/DTI Control Line Cards
DTI / UTI FPGA and Other
Backplane
RSP
SAS Hard Timing
Disk Drive DRAM
4 GB Fabric I/O to
Switch Fabric Other RSP
External Fabric I/O
Switch
Fabric I/O
Compact Flash Punt Fabric
CPU FPGA 0 Fabric
Internal Dual Core Connection to
Flash 4 GB Processor Switch Line Cards

Fabric
RGMII
Fabric 1
Mgmt Ether 0/1 Scheduler
PHY GMII GMII VOQ Arb Fabric Arb
UART
Console UART
Backplane Ethernet
Aux Ether EOBC to
Switch Line Cards
Front Panel
System EOBC to
PHY
Controller Other RSP
FPGA, CPLD,
drivers, etc.
CAN Backplane
Pwr Cntrl Quack Controller CANbus
Alarms
CANbus
NVRAM Boot Flash Serial to/from
512K 128M Line Card
Consoles

Fabric ArchitectureSingle RSP, 40G LCs

The Cisco ASR 9000 series fabric has three main components:
Fabric interface chip(s) on each line card and each route switch
processor card
Switch fabric chips on the RSPs to pass data between LCs
Fabric scheduler/arbitrator chips on the RSPs which control the
transfer of data from ingress to egress.
The switch fabric is logically separate from the LCs and the RSP. The RSP
must request access to the switch fabric like an LC. The data and
arbitration paths are also separated.
There are two fabric interface chips on the RSP. Each fabric interface chip
provides 40 Gb (in each direction) of throughput. If one RSP is lost, the
shelf can still operate at full capacity, no bandwidth capacity is lost.

Module 2 Fabric ArchitectureSingle RSP, 40G LCs
Fabric ArchitectureSingle RSP, 40G LCs
Fabric I/O Switch Fabric I/O

(40G LC) Fabric 0 (40G LC)
Fabric I/O Fabric I/O

(40G LC) (40G LC)
Switch
Fabric 1

(40G LC) (40G LC)
Data
Scheduler/
Arbiter

(RSP) (RSP)
Arbitration
23G fabric channels

arbitration grant/request signals

Fabric ArchitectureRedundant RSP, 40G LCs

There are two fabric interface chips on each RSP. Each fabric interface
chip provides 80 Gb of throughput to each LC. If one RSP is lost, the shelf
can still operate at full capacity, no bandwidth capacity is lost.
With redundant RSPs, each LC has up to four 23 Gb fabric channels it can
send traffic across. The switch fabric is active/active. Load balancing is
performed on unicast traffic across these four channels.
With redundant RSPs, the arbiters are in an active and standby
relationship. Both the active and standby arbiters receive requests for
switch fabric access from the LCs. Upon switchover of the active RSP, the
standby RSP arbiter has a current copy of switch fabric requests from the
LCs which speeds up switchover.
An RSP switch over, reload or crash including kernel crash have NO
impact on fabric operation. RSP OIR has no traffic impact due to
long/short pin backplane design and instant fabric switch over
On the insertion point of each LC, where copper pins slide into the
backplane interface, a short pin triggers the control signaling for fabric
switchover in hardware.
Longer pins are used for data packets. This affords the system the ability
to continue draining the in-flight packets from the fabric during the short
period of time between when the short pins are pulled and when the longer
pins are eventually pulled.

Fabric ArchitectureRedundant RSPs, 40G LCs
Switch Active Fabric

One Fabric I/0 Fabric 0
chip per 40G LC Switch

Fabric 1
Arbiter
Fabric I/O
Fabric I/O RSP0
Active RP (40G LC)
40G LC 40G LC
Switch
Fabric 0
Switch
Fabric 1
Arbiter Active Fabric

RSP1
Standby RP
23G fabric channels

Switch fabric data is active/active,
Arbiter is active/standby following the RP state

Fabric ArchitectureRedundant RSP, 80G LCs

Each 80G LC has two fabric interface chips which, together, provide twice
the bandwidth to the switch fabric over that of a 40G LC. The diagram on
the following page illustrates the eight, 23G channels that are formed
when combining 80G LCs with redundant RSPs.
All other arbitration and load balancing mechanisms are the same for both
the 40G LCs and the 80G LCs.

Fabric ArchitectureRedundant RSPs, 80G LCs
Switch Active Fabric

Two Fabric I/0 Fabric 0
chips per 80G LC Switch Active RP

Fabric 1
Arbiter
Fabric I/O
Fabric I/O RSP0
(40G LC)
40G LC
Switch
Fabric I/O Fabric 0
80G LC Switch
Fabric 1
Arbiter
RSP1
Standby RP
23G fabric channels

Switch fabric data is active/active,
Arbiter is active/standby following the RP state

Fabric Load Sharing of Unicast Traffic

All fabric data channels run in active mode for extra fabric bandwidth and
instant fabric switchover. Data and arbitration (control) paths are
separated.
Both Arbiters work in parallel both answer all requests, Fabric I/Os
follow the active Arbiter, Fabric I/Os switch to the standby arbiter if
needed providing instant control path switchover. Arbiter switchover is
controlled by low level hardware signaling.
Unicast traffic is sent across first available fabric link to destination which
maximizes efficiency. Each frame (or superframe) contains sequencing
information that is used to resequence packets at the egress LC. Because
of fabric speedup there is very little latency.
All destination Fabric I/O chips have re-sequencing logic. Resequencing
latency is measured in nanoseconds.

Fabric Load Sharing of Unicast Traffic
Switch
Fabric 0
Switch
1 Fabric 1
3
Arbiter
(unicast fabric plane) 4 3 2 1
(LC) 4 (LC)
Switch
Fabric 0
2 Switch
Fabric 1
Arbiter
(unicast fabric plane)
Unicast traffic is sent across first available fabric link to destination which maximize efficiency.
Each frame (or superframe) contains resequencing logic which is used to reorder frames at the
egress LC.
Latency is measured in nanoseconds.

Fabric Load Sharing of Multicast Traffic

Since multicast traffic could involve a very large set of multicast
destinations it precludes resequencing:
Multicast traffic is hashed based on (S, G) info to maintain flow
integrity
Multicast traffic is non-arbitratedsent across a different fabric plane

Fabric Load Sharing of Multicast Traffic
Switch
Fabric 0
A Switch
A Fabric 1
A B
A
B
Fabric I/O (Multicast fabric plane) Fabric I/O C1 B2 A3 B1 A2 A1
(LC) B (LC)
C Flows exit in-order

C Switch
C Fabric 0
C
Switch
Fabric 1
(Multicast fabric plane)
Multicast traffic is hashed based on (S,G) info to maintain flow integrity

Five Step Switch Fabric Arbitration

Virtual output Queuing (VoQ) is used to control the flow of unicast traffic
across the backplane between ingress LCs and egress LCs. A multi-step
request/acknowledge process is implemented between the fabric interface
chips of each LC.
The term VoQ is derived from the fact that the ingress LCs check the
queues of the egress LC (which are not located on the ingress LC and are
therefore deemed virtual).
These are the control steps required to allow data transfer from ingress LC
to egress LC:
Step 1:
Fabric RequestLC requests fabric scheduler arbitration for data
transfer
Step 2:
ArbitrationFabric scheduler checks with destination LC for data
transfer
Step 3:
Fabric GrantFabric scheduler tells requesting LC request
accepted for data transfer by destination LC
Step 4:
Transfer DataRequesting LC sends data to destination LC
Step 5:
AcknowledgeDestination LC tells fabric scheduler transfer
complete available for next arbitration

Five Step Switch Fabric Arbitration
Scheduler
3 Bellagio2
VoQ Arbiter 2
CPU
PuntPath
1 FPGA
Octopus
Fabric I/O
5
Santa
Switch
Fabric
Cruz
0
NPU
NP3c0 4 4 NPU
NP3c0
Bridge Bridge
Fabric Fabric
FPGA Octopus
I/O 4 Santa
Switch
4 Octopus
I/O
FPGA
NP3c1
NPU Fabric NP3c1
NPU
Cruz
1
LC0 LC7
SUP-A !
!
! !
! !
Scheduler
Bellagio2
Scheduler
VoQ Arbiter
NPU
NP3c0
4 4 CPU 4 NP3c0
NPU
Fabric
PuntPath Fabric Bridge
4 Octopus
Bridge Octopus
Octopus FPGA Fabric I/O FPGA
FPGA
I/O I/O
NP3c1
NPU NP3c1
NPU
Santa
Switch
LC4 Fabric LC11
Cruz
0
Punt Path Packets
Santa
Switch Arbitration Credits/Grants
Fabric
Cruz
1 20Gbs Fabric Links
SUP-B

Superframes
It is inefficient to add a switch fabric header to many smaller packets that
are all destined to the same egress NPU. Multiple unicast packets that are
destined for the same egress LC are grouped into superframes totaling less
than 2000 bytes.
Because there could be a very large combination of multicast destinations,
multicast packets are neither put into superframes nor are they arbitrated
through the VOQ mechanism.
Multicast has its own dedicated data path through the switch fabric.

Superframes
Superframing significantly improves total throughput

Applies to multiple unicast frames from/to same destination
Packet 1 No superframing (1)
Packet 3 Packet 2 Packet 1 Min reached (3)
Packet 3 Packet 2 Packet 1 Max reached (2)
Packet 1 Jumbo (1)
Max Max Min Sufficient 0 (Empty)

MTU Superframe for Superframe

40G and 80G Ethernet LCs

Supported LCs:
The LCs can be categorized into Ethernet-based LCs and SIP/SPA-based
LCs.
The Ethernet-based LCs can be further classified into two groups; 40G LCs
and 80G LCs.
There are four types of 40G Ethernet LCs.
40-port GE
20-port GE + two-port 10 GE
4-port 10 GE
8-port 10 GE (oversubscribed)
There are two types of 80G Ethernet LCs:
8-port 10 GE
The 40Gb, eight-port 10GE card is oversubscribed but it can process up to
60Gbps of traffic. In similar fashion, the 80Gb, 16-port 10GE card can
process up to 120Gbps of ingress traffic.
The LCs are available in multiple scale versions.
Standard, CWDM, & DWDM XFPs/SFPs/SFP+ available
IPoDWDM G.709 FEC/EFEC support
GE - SFP Optics (T, S, L, and Z)
TenGE XFP Optics (LR, ZR, and ER)

Module 2 40G and 80G Ethernet LCs
40G and 80G Ethernet LCs
40G Ethernet LCs:

40-port GE
20-port GE + two-port 10 GE
4-port 10 GE
80G Ethernet LCs:
8-port 10 GE
Each LC supports a wide range of
optical (CWDM, DWDM, SFP, XFP)
interfaces. GE and 10 GE Ethernet LCs

Ethernet LCNPU
NPU Forwarding Engine
The NPU forwarding engine has two forwarding paths, one for ingress and
one for egress. The paths allow the user to implement different features.
Packets are sent from the forwarding engine to the bridge chip and out
through the fabric interface. Fabric scheduler transfers data from VoQs
when the Fabric Grant is returned from the accepting or destination LC.

Ethernet LC-NPU
Network Processing Unit
To the Bridge
Ingress Processing
and Fabric
I/O Interface
Optics
Interface
Framers
Optics
Egress Processing
NPU Forwarding Engine
Line Card Control Plane CPU
The LC NPU executes all major forwarding

features.
The LCs provide separate paths for ingress
features and egress features.
! Each NPU has Four Main Associated memories TCAM , Search/Lookup memory , Frame/buffer memory
and statistics memory
TCAM is used for VLAN tag, QoS and ACL classification
Lookup Memory is used for storing FIB tables, Mac address table and Adjacencies
Stats memory is used for all interface statistics, forwarding statistics etc
Frame memory is buffer memory for Queues
! E/B/L line card have different TCAM , Stats and Frame Memory size, which give different scale number
of the QoS queues and L2 sub-interfaces per line card
! Lookup Memory is the same across line cards
To support mix of the line cards without impacting the system wide scale including routing,
multicast, MAC address, L3 interface, MPLS label space scale

40G Ethernet LCBlock Diagram

Optics and Physical Framer
The fixed interface front end hosts user ports. The fixed interfaces adapt
the user traffic flowing between the fixed interfaces and the NP-3
forwarding engine.
Bridge CHIP
The Bridge chip provides the glue that attaches the NPU network
processors to the Fabric Interface. Key Bridge functions include:
Conversion from XAUI serdes interface to Fabric interface

Conversion from 24-byte NP Fabric Header to 32-byte Fabric
interface/C3 header
Replication for multicast from Fabric interface to two NPU
Check and generation of Ethernet packet checksums on packets
crossing both the Fabric interface and the NPU interfaces.
Bridge chip includes a simple rate-shaper for ingress traffic, preventing
on Bridge from causing unfair bandwidth allocation with respect to its
neighboring Bridge.
Bridge chip also contains the logic for distributing precision time from
the backplane to the NPU processors.
Fabric Interface
The sending fabric interface on each LC

The fabric multicast group is controlled by an 11-bit field which is passed
into the fabric chip as the Fabric Port of Exit (FPOE) field. For a chassis
with eight 40 Gb LCs and two RSPs, this FPOE field is simply a bit-map
one bit in the FPOE can be set for each possible multicast destination.
The first replication point is the fabric itself uses the FPOE field to
indicate the set of fabric ports to which the packet should be sent.
The egress fabric interface is responsible for creating two copies of the
packet, one for each Bridge chip. The Bridge chip then further duplicated
the packet, one for each egress network processor on the card.
The final stage of replication is done in the NPU itself uses the MGID
lookup to indicate the optical ports to which the packet should be sent.

NPU 0 xGE Optics

Network PHY The number of
Bridge-
Processor xGE Optics interfaces per
FPGA 0
NPU is based
NPU 1 xGE Optics
Network PHY on the 40G LC
type:
Fabric Interface
Processor xGE Optics
NPU 2
PHY
xGE Optics 10 ports GE
Network
Bridge-
FPGA 1
Processor xGE Optics 1 port 10 GE
Backplane
NPU 3
Network PHY
xGE Optics 2 ports 10 GE
Processor xGE Optics
One Fabric
2 Gbyte
eUSB flash interface
CANbus PCIe
I/O Daughter Card
Controller
Processor
EOBC GigE All Ethernet
LCs have the
Local Busses to Bridge
2 Gbyte 128M
Control
FPGAs FPGAs, Optics, Fabric I/O, and same control
DRAM Flash so on hardware.

40G Ethernet LC Family

Simplified block diagrams of the 40G Ethernet LC family that are
available in the Cisco IOS XR Software release 3.9.1 are illustrated on the
following slide.
The number of physical interfaces per NPU varies with each LC type.
The LC control hardware and the Bridge chips are not shown to same
room.


A9K-4T-E/B/L A9K-2T20G-E/B/L
PHY 3 NPU0 PHY NPU0
PHY 2 NPU1 PHY NPU1

FI/O FI/O
PHY 1 NPU2 NPU2
PHY 0 NPU3 NPU3
A9K-8T/4-E/B/L A9K-40G-E/B/L
PHY 3
PHY 7
NPU0 NPU0
PHY 2
PHY 6
NPU1 NPU1
FI/O FI/O
PHY 1
PHY 5
NPU2 NPU2
PHY 0
PHY 4 NPU3 NPU3
Oversubscribed
Note: Bridge FPGAs and LC control hardware are not shown for simplicity

40G LCNPU to Interface Mapping

This slide illustrates the mapping of NPUs to individual physical
interfaces. There are four NPUs on each of the 40-Gig line cards available
in the first phase of the Cisco ASR 9000 platform. These NPUs are wired
to 1, 2, or 10 physical interfaces, depending upon the LC type.

Fabric
I/O
Bridge Bridge
0 1
NPU 0 NPU 1 NPU 2 NPU 3
40 x 1GE 30-39 20-29 10-19 0-9

8 x 10 GE 3&7 2&6 1&5 0&4
2 x 10 GE + 20 10-19 0-9 1 0
x GE (GE) (GE) (10 GE) (10 GE)
4 x 10 GE 3 2 1 0
LC Interface number


The layout of the 80G LCs is very similar to the layout of the 40G LCs.
The main differences are the number of optics, NPUs, and fabric interface
chips.

Bridge- 0 NPU 0 PHY xGE Optics

The number of
NPU 1 PHY xGE Optics interfaces per
Fabric Interface
Bridge- 1
PHY
NPU is based
NPU 2 xGE Optics
0
on the 80G LC
NPU 3 PHY xGE Optics type:
Bridge- 2 NPU 4 PHY xGE Optics 1 port 10 GE
Fabric Interface
PHY
NPU 5 xGE Optics
2 ports 10 GE
1
Backplane
Bridge- 3
NPU 6 PHY xGE Optics
NPU 7 PHY xGE Optics
2 Gbyte
eUSB flash
CANbus PCIe
I/O Daughter Card
Controller
Processor
EOBC GigE
Two Fabric
2 Gbyte 128M
Control Local Busses to Bridge
FPGAs, Optics, Fabric I/O, and
interfaces
FPGAs
DRAM Flash so on


Simplified block diagrams of the 40G Ethernet LC family that are
available in the Cisco IOS XR Software release 3.9.1 are illustrated on the
following slide.
The number of physical interfaces per NPU varies with each LC type.
The LC control hardware and the Bridge chips are not shown to same
room.


A9K-8T-E/B/L A9K-16T/8-B
PHY
PHY NPU0 PHY NPU0
Fabric PHY Fabric
PHY NPU1 PHY NPU1
I/0 PHY
I/0
PHY NPU2 0 PHY NPU2 0
PHY
PHY NPU3 PHY NPU3
PHY
PHY NPU4 PHY NPU4
PHY NPU5 Fabric PHY
NPU5 Fabric
PHY
I/0 PHY
I/0
PHY NPU6 1 PHY NPU6 1
PHY
PHY NPU7 PHY NPU7
Oversubscribed
Note: Bridge FPGAs and LC control hardware are not shown for simplicity


This slide illustrates the mapping of NPUs to individual physical
interfaces. There are eight NPUs on each of the 80G LCs available in the
3.9.1 software release of the Cisco ASR 9000 platform.
These NPUs are wired to 1 or 2 physical interfaces, depending upon the LC
type.

Fabric Fabric
I/O 0 I/O 1
Bridge Bridge Bridge Bridge

0 1 2 3
NPU 0 NPU 1 NPU 2 NPU 3 NPU 4 NPU 5 NPU 6 NPU 7
16 x
10 2&8 5 & 10 6 & 13 0 & 12 3 & 11 1&9 4 & 14 7 & 15
GE
8x
10 5 3 4 2 0 1 7 6
GE
LC Interface number

Ethernet LC Internal Bandwidth

In terms of raw bandwidth, the ASR 9000 Ethernet LCs and RSPs can
support line-rate traffic flow for all LCs excluding the two oversubscribed
LCs. (the 40G, 8x10GE and the 80G, 16x10GE). The LC NPU and fabric
interface are QoS aware and policing, queuing, and scheduleding are
supported on each of these components.
The NPU-to-bridge interface is a clocked at ~15Gbps. Note that this is
significantly faster than the ~10gbps linerate provided by a single 10GE or
ten 1GE ports, but significantly LESS than the aggregate 20gbps offered
by the 2:1 oversubscribed linecard where two 10GE ports are shared by a
single NPU.
The bridge-to-fabric interface is a DDR memory interface, with a raw
throughput capacity of approximately 32Gbps. Note that this is faster
than the combined (15G * 2) load of two bridge chips. For this reason we
do not expect to see packet drops here.
The fabric interface-to-fabric is a set of serial links capable of carrying
~46Gbps. To be more precise, each octopus has a 23G connection to each
Fabric chip on each RSP. If we fully expand this number we see that there
are two Fabric chips per RSP, and (generally) two RSPs in a system. This
gives us a final fabric interface ->fabric bandwidth number of (23Gbps * 2 *
2 = 92Gbps).


CPU Fabric
PHY NPU0 I/O
PHY NPU1
B0 Fabric Fabric
I/O
PHY NPU2 I/0 0
B1
Arbiter
PHY NPU3
RSP0
PHY NPU4
Fabric
I/O
PHY NPU5 B2
Fabric
PHY NPU6 B3 I/0 1 Fabric
I/O
PHY NPU7 Arbiter

RSP1
30 Gbps and 25M pps 15 Gbps bi- 30 Gbps bi-

(combined ingress and egress) directional directional Each Fabric I/O has one fabric
60 Gbps bi- channel which is 23 Gbps bi-
30 Gbps bi-
directional directional, to each of the Fabric I/Os
directional

Ethernet LC Counters
This slide illustrates various commands that can be used to display packet
counters for different components of the Ethernet LCs.

Ethernet LC Counters
RP/0/RSP1/CPU0:PE1# show controllers fabric ? Arbiter

arbiter Arbitration ASIC show screens.
Fabric
crossbar XBAR ASIC show screens.
fia Show command for fabric interface asic
FIA
RP/0/RSP1/CPU0:PE1# show controllers fabric fia bridge stats location 0/0/cpu0
RP/0/RSP1/CPU0:PE1# show controllers fabric fia stats location 0/0/cpu0
RP/0/RSP1/CPU0:PE1# show controllers np ?

NPU
counters Display contents of global stats counters
crashinfo Display NP Crash info
drvlog Display Driver Logging
fabric-counters XAUI counters dump
interrupts Show NP interrupt data
memory NP Raw Memory Dump
portMap Show port mapping on NP
ports Shows physical ports associated with each np
<snip>

Packet Data Flow

The following slide illustrates the end-to-end data path of the LCs and
RSPs for both data and punt traffic. Punt traffic is traffic that is identified
as locally important control traffic that needs to be processed by either the
LC CPU (for forwarding plane-oriented protocols) or the RSP CPU (for
control plane-oriented protocols).
There are two possible paths for punt traffic. Depending upon the protocol
(some forwarding-plane oriented protocols such as E-OAM and BFD
operate on the LC CPU only) some punt traffic will be destined to the local
LC CPU and it is punted by the NPU. Global punt traffic is punted from
the local LC NPU to the RSP CPU.
The data path is as follows from ingress LC to egress LC (which in this
example is the same LC):
Optics NPU Bridge Fabric I/O Backplane
! Switch Fabric
Backplane - Fabric I/O Bridge NPU - Optics

Module 2 Packet Data Flow
Packet Data Flow

Ethernet LC Product Identification

The table on the following page summarizes the category (40G or 80G),
scale (low, medium, or high queue) and product ID for each of the Ethernet
LCs.
____________________________ Note _________________________
The A9K-16T/8 only has a B option. It doesnt have E or L options as
of the 3.9.1 release.
__________________________________________________________________

Module 2 Ethernet LC Product Identification
Ethernet LC Product Identification
Category Description Product ID (PID)

40-port GE A9K-40GE-L
Four-port 10 GE A9K-4T-L
Two-port 10 GE + 20-port GE A9K-2T20GE-L
Low Queue LCs (-L)
Eight-port 10 GE A9K-8T/4-L
(oversubscribed)
Eight-port 10 GE A9K-8T-L
40-port GE A9K-40GE-B
Four-port 10 GE A9K-4T-B
Two-port 10 GE + 20-port GE A9K-2T20GE-B
Medium Queue LCs (-B) Eight-port 10 GE A9K-8T/4-B
(oversubscribed)
Eight-port 10 GE A9K-8T-B
16-port 10 GE A9K-16T/8-B
40-port GE A9K-40GE-E
Four-port 10 GE A9K-4T-E
Two-port 10 GE + 20-port GE A9K-2T20GE-E
High Queue LCs (-H)
Eight-port 10 GE A9K-8T/4-E
(oversubscribed)
Eight-port 10 GE A9K-8T-E

LC Scale Selection
The following flowchart illustrates the key decision making criteria in
choosing a particular scale size for a given LC type.
Up to three memory options for each line card:
Extended (or high queue)
Base (medium queue)
Low (low queue)*
The different memory options have different QoS queue scale and L2 sub-
interface scale values. Ethernet Flow Points (EFPs) represent endpoints of
Layer 2 services and are discussed in the Layer 2 Architecture module.
All other system wide scale is the same across different type of the line
cards, including FIB, MAC address, Bridge-domain, L3 sub-interface, VRF,
and so on. Support for a matching set of system-wide scale across a mix of
different LC types allows for mixed LCs support within the same chassis.
All line cards have the same basic hardware features.
Contact your Cisco Representative for the latest scale and capacity
information. Use the below specifications only as a guideline:
32K EFPs/ sub-interfaces (non-bundle) per LC
16K on 40G Base LCs
64K EFPs/ sub-interfaces (non-bundle) per chassis
8K bridge-domains per LC and per chassis
8K EFPs per bridge-domain
512K MAC addresses per LC and per chassis
16K static MACs

LC Scale Selection
LC Scale Selection Guidelines
Contact your Cisco Representative for the latest scale and capacity
information. Use the below specifications only as a guideline.
How many EFPs? >16k
High queue LC 32k EFPs

>4k,<=16k
<=4k (-E) 256k queues
>16k 256k policers
How many queues? 150ms buffering
>8
Medium queue LC 16k EFPs

<=8k per
port (-B) 64k queues
>128k
>=8k 128k policers
How many policers? 50ms buffering
<=8k Low queue LC 4k EFPs

>50ms (-L) 8 queues per port
How much buffering? 8k policers
<= 50ms 50ms buffering

LC or Chassis License Requirements

Optionally, premium features such as Layer 3 VPN, Video Monitoring, and
IP over DWDM can be added with software licenses. The following
flowchart can be used to guide the decision making process on whether or
not a license is required.
L3VPN License
Enables Configuration of Interfaces into VRFs

One each for Base/Low-Q (B/L) and Extended (E) Line Cards
Each license scope is per Line Card
Available in 3.7 on honor basis

Enforced in 4.0
G.709 License
Enables configuration of G.709 on 10GE ports

Each license scope is per Line Card
Available and Enforced in 3.9

VidMon License
Enables configuration of Vidmon on any port
Each license scope is per system
Available and Enforced in 3.9

LC or Chassis License Requirements
Plan to deploy virtual Yes Purchase an Advanced IP

routing an forwarding License per LC
(vrf) on a subinterface?
Yes
Plan to enable G.709 Purchase an Advanced Optical
framing on an License per LC
interface?
Yes
Purchase an Advanced
Plan to enable Video
Video License per chassis
monitoring on the
chassis?
No to all of the Dont buy a

above? license

Summary
Cisco ASR 9000 Series Hardware
List the features and functions of the Cisco ASR 9000 Series Chassis
List and describe the features and functions of the FRUs and
components that comprise the Cisco ASR 9000 chassis
List and describe the features and functions of the Cisco ASR 9006 and
ASR 9010 chassis:
! Route Switch Processor cards
! Switch fabric
! Line Cards
! Cooling system
! Power system

Module 3
Cisco IOS XR Software Overview
Overview
Description
This module introduces you to the Cisco IOS XR software architecture,
high availability (HA) and scalability. You will learn about specifically
applicable features that are specific to each platform.
Objectives
Describe the Cisco IOS XR modular software architecture
Describe Cisco IOS XR high availability

Describe Cisco IOS XR scalability

Cisco IOS XR Software Overview Module 3
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 infrastructure for both
single chassis and CRS-1 multishelf hardware configurations. The
infrastructure includes :
XR 12000
CRS-1 ASR 9000
Series
Route
RP. DRP PRP RSP
processors
Line cards MSC, FP LC LC
Service
SP - -
processors
Shelf controller SC - -
Services
Services are composed of one or more processes, which may be running on

the same or different CPUs. Each process has a separate memory-protected
address space. Each process can have multiple threadsall sharing the
same address space.

Module 3 Cisco IOS XR Architecture
Cisco IOS XR Architecture
Routing Protocol
Application
modules modules
modules
(BGP, OSPF) (IP)
Runs on
multiple
CPUs
Distributed infrastructure
Cisco IOS XR kernel

High Availability
High availability in 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
Process restart and recoveryRP failover
Route processor failover
Nonstop forwarding
Minimum Disruption Restart (MDR)
In Service Software Upgrade (ISSU) capability

Module 3 High Availability
High Availability Components
Kernel
Plane separation
Fault tolerance and isolation
Checkpoint support for process restart
Process-level redundancy
Process restart and recoveryRP failover
Route processor and distributed RP failover
Nonstop forwarding
Minimum Disruption Restart (MDR)
In-Service Software Upgrade (ISSU) capability

Kernel
The QNX Neutrino microkernel has these main features:
Multiprocessor
Small memory footprint
Memory protection
Preemptive fast context switch times
Reliabilityindependent component load/control
Portable Operating System Interface (POSIX)
In the Cisco IOS XR architecture, processes run in their own separate
process spaces. Almost every process can be independently started or
stopped. Failures in processes do not directly 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 Applications
PO
S
Distributed processing Microkernel: I Message queues
C Threads X
File system Scheduling
Lightweight messaging
I Debug
S Timers Synchronization
Event management C
O
Plane Separation
Cisco IOS XR software is partitioned into three planes:

ControlDistributes routing tasks and management of the Routing
Information Base (RIB) in participating RPs; different routing
processes can be running on different physical units
DataMaintains the Forwarding Information Base (FIB) changes
across the participating nodes, letting the router perform as a single
forwarding entity
ManagementControls the operation of the router as a single
networking element

Routing and forwarding are separated, creating a clear separation of

control, data, and management planes. On the Cisco CRS-1, routing control
processes can be distributed across multiple route processors (RPs) or
distributed route processors (DRPs). If desired, Multiprotocol Label
Switching (MPLS) processes could run on a separate DRP altogether.
Each plane can easily be extended 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 checkpointed, so
if a process fails, it can be restarted quickly or the redundant process can
take over faster.

BGP
Module 3
RIP BGP
IS-IS RIP
BGP
OSPFIS-IS
RIP
Control Plane
Routing policy
Process mgmt
Control plane
Plane Separation
OSPFIS-IS
PIM
Control Plane
Routing Policy
2011 Cisco Systems, Inc.

OSPF
Control plane
IGMP PIM
Routing Policy
Control plane
RIB IGMP
PIM
L2 driversRIB IGMP
IPC mech.
ACL
L2 Drivers RIB
FIB ACL
L2 Drivers
QoS FIB
ACL
LPTSQoS
System services
FIB
Data plane
Host services
LPTSQoS
Version 4.0.1
Data plane
Host
PFI Services
LPTS
Memory mgmt.
Interfaces
Memory-protected microkernel
PFI
Data plane
Host Services
CLI
InterfacesPFI
SNMPCLI Interfaces
XMLSNMP
Netflow CLI
XMLSNMP
AlarmNetflow
H/W abstraction
Perf. mgmt. XML

AlarmNetflow
Management plane
SSH
Perf. Mgmt.
Alarm
Management plane
SSH
Mi
Perf. Mgmt.
cr
Distributed subsystems/processes
o k
Management plane
SSH
er
ne
l
High Availability
39
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, in which failure of a single module may cause
failure of the whole system.

Fault Tolerance and Isolation
Cisco IOS XR
Management
Control
plane
plane
Data
plane
Layered rather than monolithic architecture
Fault isolation and protection between the

planes based on separation

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.
At 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
Updates of running state

Process
(Process fails)
Checkpoint
shared
New memory
instance store
of Recover state
process
Active RP/DRP

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
Active service-providing process

Active
process Client
Client
Standby
process Standby process
Client
Active process uses a

checkpoint database to Clients use active service-
share running state providing process
with standby

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
Active 2. Standby process

becomes active
process
Client
New active
Client
Standbyprocess
process
Client
4. New active starts sending
updates to standby process
3. New standby
process is started 5. Clients use new active
service-providing process

Process Recovery on 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

Sent to the standby card continuously; Process A is running in the
A
background
Mirrored to the standby card; Process B is not running; this process uses a
B
checkpoint proxy process to receive checkpoint information
No checkpointing of data; process C can start on the standby card without
C
saved state information
D No checkpointing of data; no process running on the standby card.

Process Recovery on RP Failure
Active Route Processor Standby Route Processor
Process A Process A
1 1
Process B Process B
2 Checkpt
1 Checkpt
process
2 process
Process C 3 Process C
Process D 4
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
2011, Cisco Systems, Inc. All rights reserved. Version 4.0.1 Course nameModule 0/17

Route Processor Failover

Failover is provided through the use of paired (active/standby) route
processors. RPs, PRPs, and RSPs are automatically paired by Cisco IOS
XR software during bootup. Cisco CRS-1 DRPs are not automatically
paired. Unlike other route processors, DRPs can be paired or unpaired by
the user through configuration.
A feature or protocol is considered high availability-aware if it, either
partially or completely, maintains undisturbed operation through a route
processor 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.
____________________________ Note _________________________
With route processors, if no standby is available, no checkpointing
takes place.
__________________________________________________________________
All configurations made on the active route processor are automatically
synchronized to the standby route processor

Route Processor Failover

ASR9KE For Print!!
Failed RSP is
reloaded to
Active
Standby
become new RSP
RP/PRP/RSP
standby RSP
On active RSP
failure, standby
Checkpointed RSP becomes
active
Standby
RSP

Nonstop Forwarding
The main objective of Cisco nonstop forwarding (NSF) is to continue
forwarding IP packets following a route processor (RP/PRP/RSP)
switchover. NSF works with the stateful switchover (SSO) behavior to
minimize the time a network is unavailable to its users following a
switchover. Cisco NSF helps to suppress route flaps, reducing network
instability.
Cisco NSF is supported by the Border Gateway Protocol (BGP), Open
Shortest Path First (OSPF), Intermediate System-to-Intermediate System
(IS-IS), and MPLS protocols for routing. 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 Cisco IOS XR forwarding processes to continue
forwarding packets during switchover while the routing protocols rebuild
the Routing Information Base (RIB) tables. After the routing protocols
have converged, the control processes update the Forwarding Information
Base (FIB) table and remove outdated route entries. In turn, the control
processes update the LCs with the new FIB information.

Nonstop Forwarding
ASR9KE For Print!!
Paired Route Processors

Active Standby
Each LC has dedicated RP RP
packet forwarding
hardware
Packet forwarding is not Control
affected by: updates
! ISIS, OSPF, BGP, MPLS, interrupted
Multicast process restart
! Infrastructure process
restarts
! RP failover
But
LC LC Fwding
Ok!

Minimum Disruption Restart

Minimum Disruption Restart (MDR) capability lets software on a
Cisco IOS XR node (RP/DRP/PRP/RSP, SP, or LC CPU) to be restarted
without restarting the cards hardware. For LCs, MDR allows CPU restart,
so traffic loss is minimized or eliminated.
MDR has two purposes:
To minimize or eliminate user traffic outages during ISSU. An
advantage of using MDR on LCs is for nonredundant configurations;
during upgrades that require card reload. MDR is used in conjunction
with an incremental install process to implement ISSU.
To use as a software fault recovery tool in a software recovery
escalation chain. A typical software recovery escalation chain might be:
1. Try a process restart
2. If a process restart does not fix the problem, try MDR
3. If MDR does not rectify the problem, reload the node

Minimum Disruption Restart
What is it?
A critical piece in ISSU
A way to restart or reload software while hardware
continues to function
! Upgrade MDRUsed to upgrade or downgrade
maintenance releases
! Failure MDRUsed to recover from software failures
before reloading
MDR Goal?
Maintenance release upgrades should be
! Hitless
! Cause the minimum hit to forwardingless than control
protocol timeouts

MDR has some limitations. These limitations are those that require
additional processing outside the basic packet processing.
The current limitations include:
No processing of IPv4, IPv6, or Label Switch Path (LSP) ping packets
IPv4 packets with options are dropped

! Exceptions: router alert and IGMP
IPv6 packets requiring fragmentation are dropped
IPv6 packets with optional headers are dropped

IPv6 ICMP and link local destination address packets are dropped
IGMP group join and leave messages are not processed
IPv4 ICMP packets destined to MSCs are dropped

No processing of ICMP packets sent for:
! TTL expiration
! No route (ingress)
! Fragmentation required but DR bit set (egress)

! Incomplete adjacency (egress)
Fast re-route (FRR) failovers are not supported.
Forwarding plane statistics and Netflow data are lost

Minimum Disruption Restart (Cont.)
MDR limitations:
IPv4, IPv6, or LSP ping packets are not processed
IPv4 packets with options, except router alert and IGMP, are dropped
IPv6 packets that require fragmentation are dropped
IPv6 packets with optional headers are dropped
IPv6 ICMP and link local destination address packets are dropped
IGMP group join and leave messages are not processed
IPv4 ICMP packets destined to MSC are dropped
No ICMP packets sent for:
! TTL expiration
! No route (ingress)
! Fragmentation required but DF bit set (egress)
! Incomplete adjacency (egress)
FRR failovers not supported
Forwarding plane statistics and Netflow data are lost

In Service Software Upgrade Capability

In Service Software Upgrade (ISSU) offers a solution, which is highly
scalable and parallel in nature, in which a system, regardless of its size,
can be upgraded (or downgraded) within a maintenance window.
ISSU has some requirements:
Standby route processor (RP/DRP/PRP/RSP) must be present and ready

Minimum Disruption Restart must be available on all cards
Software upgrades and downgrades must be compatible
Specific steps for the implementation process must be followed and
enforced
ISSU is a process running on a Cisco platform that supports stateful
switchover (SSO) and nonstop forwarding (NSF). The process moves a
Cisco router from one version of SSO/NSF-capable Cisco IOS XR image to
another version of a SSO/NSF-capable Cisco IOS XR image with minimized
downtime, degradation of service, or loss of packets.
____________________________ Note _________________________
There may be some packet loss in certain platforms with certain
configurations.
__________________________________________________________________
The process is user initiated and is controlled through a set of CLI
commands issued in a certain specific order. The ISSU process consists of
four steps; the user explicitly initiates each step by invoking a specific CLI
command. Throughout the process, user has the ability to ensure and
verify that there is no degradation of the service. A CLI command is
available to abort the entire process, should the user decide to do so part-
way through the process.

In Service Software Upgrade Capability
Multi-
ISSU MPLS
cast
! Deliver enhancements and bug fixes, while Mgbl Security

keeping other packages unchanged
! Affect only the areas that are changing, not
RPL BGP
all the software
! Enhancement and bug activation does not OSPF ISIS
result in traffic loss
Forwarding
Base
HFR Admin
OS
Line card

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
Some of the scalability features include:
Adjacency management
Multi-stage forwarding
Forwarding Information Base tables
Distributed interface management
Distributed configuration management

Module 3 Scalability
Scalability Features
Adjacency management
Multi-stage forwarding
Forwarding Information Base tables
Distributed interface management
Distributed configuration management

Adjacency Management
An adjacency is a mapping of the next-hops Layer 3 address to the Layer 2
rewrite needed to get the packet to the next-hop. In traditional Cisco IOS
routers, adjacency management is done in the RP.
With Cisco IOS XR software, the adjacency control plane runs in the LC
and not in the RP. Adjacency management is done locally on every card for
interfaces resident on that card. One LC does not know about adjacencies
on other LCs. The RP does not keep any adjacency information; it pulls it
from the LC when you request the information.
On the ingress LC the receive Adjacency Information Base (AIB) contains
the destination address and associated parameters to get the packet to the
egress LC or line card, based on the forwarding information found in the
Forwarding Information Base (FIB) tables.
In the egress LC, the transmit adjacency table contains the Layer 2 rewrite
to be applied on the packet before sending it out.

Adjacency Management
Route Processor
Interface ARP/Map!
manager tables!
Adjacency
Line card information
base!

Multi-stage Forwarding
Cisco CRS-1
Forwarding of packets is done in two stages. When a packet arrives as the

ingress MSC, only enough information to send the packet to the outbound
MSC and physical interface is needed.
When the packet arrives at the egress point, a deeper lookup is performed
to determine the outbound port and the necessary adjacency information.
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, so there is no
requirement to store all adjacency information on all MSCs.
For security implementations, access control lists (ACLs) can be applied on
either (or both if required) the ingress and egress line cards.
Cisco XR 12000 Series
The Cisco XR12000 uses N-stage forwarding which loosely follows the 2-
stage forwarding model but forwarding decisions are made primarily on
the ingress linecard. The ingress linecard does a Layer 3 (IPv4, IPv6, and
MPLS) lookup which yields the egress slot and a ppIndex. The packet is
then forwarded to the egress slot. The egress linecard does a L3 features
lookup and a ppIndex lookup which produces the outgoing interface for
forwarding the packet.
____________________________ Note _________________________
The feature lookup is done only for IPv4 packets. It is not executed for
IPv6 and MPLS packets
__________________________________________________________________
The egress LC does a ppIndex lookup in the forwarding ASIC but its not a
FIB lookup. Instead of a FIB lookup, a ppIndex lookup is done to obtain
forwarding information which produces the outgoing interface for
forwarding the packet, similar to the way a label lookup is done on LFIB.
A ppIndex is nothing but a context advertised by egress line card to all
ingress line cards. The adjacency index in IOS is analogous to ppIndex but
they are not the same. Other features such as MSB, PBR, and L2VPN need
to use a similar mechanism even on a pure 2-Stage platform such as the
CRS-1 and ASR9000.
This mechanism allows forwarding feature parity with other Cisco IOS XR
platforms because the ppIndex mechanism is not visible to platform
independent code.

Mullti-stage Forwarding
ASR9KE Multi-stage Forwarding (Cont.)
Ingress Feature Ordering Egress Feature Ordering
Incoming packet
from wire Interface Packet from Fabric
Forwarding
Classification
Lookup
ACL
Classification L2 Rewrite
QOS ACL Lookup

Classification
QOS Lookup
Fwding lookup
ACL Action
IFIB Lookup *
Packet to Wire
QOS Action
ACL action
L2 Rewrite * - IFIB lookup/actions only applicable

Operation for Punt traffic
QOS Action
Packet to Fabric
IFIB action *

ASR 9000
The Cisco ASR 9000 Router uses Cisco IOS-XR softwares two-stage
forwarding model, in which the ingress card executes ingress features
associated with the interface and subscriber on which the packet arrived,
then does a routing or switching lookup to derive an adjacency that gives
the egress line card1 and port information, and then uses that adjacency to
send the packet to the egress line card. At the egress line card, the
destination address will be looked up again, so that packet processing can
be resumed in order to complete the egress feature set. In addition to
reducing the amount of state that must be sent along with the packet from
ingress to egress, the two-stage lookup helps to localize information; with
the second lookup, information thats only of interest to the egress card can
more effectively be localized to the egress card.
Classify Port/ Routing /

Ingress Feature Packets
VLAN / Switching
Packets Processing to Fabric
Subscriber Lookup
Line Card Ingress Path

Most-granular
Egress Interface or
Egress Routing / Packets
Packets Feature Subscriber ID passed
Hierarchical Switching from
Processing through buffer header
Queuing Lookup Fabric
from ingress to egress
Line Card Egress Path
Line Card
Although destination information can be obtained by the second lookup at

the egress, source information (identification of where the packet came
from) cannot be recovered at the egress by a simple lookup. To
accommodate the need for ingress identification at the egress, a handle
identifying the most-granular input interface is also passed from ingress to
egress through a field in the buffer header.
Ingress and egress each have a specific set of features that must be
executed upon packets passing through the router, and shown on the
bottom of the following page is the order in which those features must be
executed for normal packets.
Additional ordering rules apply to some features (e.g. tunneling), where
some features may need to be executed on the inner and outer headers.
1
Actually, the adjacency points to not just the card, but one of network processors on the egress card.
Multi-stage Forwarding (Cont.)

ASR9KE For Print!!
What is two-stage forwarding?
Forwarding lookup is done twice
Ingress sideExecute features associated with the interface
and subscriber on which the packet arrived, then lookup
derives an adjacency that gives the egress linecard and port
information, then forwards packet to correct egress linecard
Egress sideThe destination address is looked up again,
packet processing can be resumed to complete egress feature
set, then gets correct interface, queue, adjacency information,
and outbound QoS treatment
Why two-stage forwarding?
Scaling
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 with each path having a next-hop interface and a
next-hop IP address.
Route information is derived from the interior gateway protocols (IGPs)
and BGP and passed to the Bulk Content Downloader (BCDL) process. An
internal group services protocol (GSP) moves updates to the line cards. The
updates are passed to the FIB process (on the LCs), which receives input
from the local Adjacency Information Base (AIB) and interface manager
(IFMGR), downloading the combined information to the LC forwarding
ASIC.

Forwarding Information Base
Route Processor LC LC
CPU PSE
AIB Ifmgr
LDP
LSD
RSVP
Switch fabric
GSP FIB
BCDL Hardware
process
FIB
BGP
RIB
OSPF
ISIS
Static
routes

Distributed Interface Management

Cisco IOS XR software uses distributed interface management. The
interface manager processes reside on the route processors and the line
cards. The processes communicate using an interprocess communication
(IPC). Interface drivers are located on each line card.
The route processor maintains summary state information for all
interfaces in the system. This state information is passed on to the standby
route processor, is maintained during switchover, and is updated in the
FIB tables so that packets destined for down interfaces are dropped at
ingress. Stateful switchover (SSO) synchronizes the processes,
applications, interfaces states, and FIBs on the active and standby route
processors.
The interface manager on the line card does not know about interfaces on
other line card; each interface manager is concerned only with the local
interfaces. Line cards manage their interfaces in parallel; the route
processor holds only the overall view.
Interface management processes user configuration (for example, the
shut/no shut and other commands) and statistics collection.

Distributed Interface Management
Route Interface driver

Processor
Interface manager
Interface manager
global database
LC LC
Interface manager Interface manager
Interface driver Interface driver
Interfaces Interfaces

Distributed Configuration Management

In Cisco IOS XR software, configuration management is split between the
route processor and the line cards. The route processor has a summary of
the configuration information, while each line card has its own individual
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 a Cisco 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:
SharedCommon information for the entire system
AdminAdministrative information about the system
LocalLocally relevant information for that node
Each route processor has all three processes. The shared and admin
processes are active only on the active RP. Each process maintains its own
data store. A replicator process copies data from the primary Sysdb to
servers on other route processors.
Each line card has an active local process only, because packet forwarding
uses only local data. Sysdb clients on the line card use only the local server
process; IPC to other processes is minimized.

Distributed Configuration Management
Route
Processor
Configuration manager
LC LC
Configuration manager Configuration manager
L2/L3 L2/L3
applications and applications and
H/W drivers H/W drivers
Hardware Hardware

Summary
Cisco IOS XR Software Overview
Describe the Cisco IOS XR modular software architecture

Describe Cisco IOS XR high availability
Describe scalability

Module 4
Cisco IOS XR Configuration Basics
Overview
Description
This module shows you the basics of Cisco IOS XR software and how to
create an initial configuration.
Objectives
Describe the configuration file system
Describe login access
Describe command modes

Explain CLI prompts
Describe management addressing
Accomplish an initial configuration

Use redundancy commands

Cisco IOS XR Configuration Basics Module 4
Configuration Operations
Two-Stage Configuration
Cisco IOS XR software 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 the configuration is stored, discarded, or
applied.
In the second stage, you commit the target configuration and make it part
of the running configuration.
Cisco IOS XR software also has Extensible Mark-Up Language (XML)
application program interface (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. Enter the CLI configuration mode using either the config command or
the config exclusive command.
The exclusive keyword option prevents other logged-in users from
making configuration changes during the configuration operation. All
configuration 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>.
2. The CLI parser, which runs every time configuration commands are
entered, checks for valid syntax.
3. The configuration command is written to the target configuration.
4. Verify the entered configuration and ensure that it is correct, or that
the 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 4 Configuration Operations
Two-Stage Configuration
Config database
First stage Second stage
Router#> Config t
commit
Config agents
Target
Running config
config
CLI/XML
Running config + Config changes = New running config
Stage 1: Make configuration changes

!Create new target config by entering config
Stage 2: Make changes persistent

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 could affect service.
__________________________________________________________________
The CFS is stored on the boot media on the RP (usually 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.

Configuration File System
New binary
configuration
created; router uses
it to boot up
following reload
IOS XR Running config

plus changes RP disk0:

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
User Access Verification
Username: cisco
Password: lab
:router#
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 installation
! Assigned username and password

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.
EXEC modeLogging in to a router running Cisco IOS XR software
automatically places you in EXEC mode. This mode enables a set of
commands to view the operational state of the router, install software
on a Secure Domain Router (SDR), and examine the state of an
operating system. Privileges also include a set of EXEC mode
commands for connecting to remote devices, changing terminal line
settings on a temporary basis, and performing basic tests.
Configuration modeConfiguration mode is the starting point for
system configuration. Commands entered in this mode affect the
system as a whole, rather than just one protocol or interface.
Configuration mode is also used to enter configuration submodes to
configure specific elements, such as interfaces or protocols.

Cisco IOS XR Command Modes
Login
EXEC mode
Administration modes Configuration modes

Configuration Modes
Configuration mode is the starting point for system configuration and is
also used to enter configuration submodes to configure specific elements,
such as interfaces or protocols.
Configuration submodesFrom the configuration mode, you can
enter other, more specific command modes. These modes are available
based on your assigned access privileges and include protocol-specific,
platform-specific, and feature-specific configuration modes
POS configuration submodePacket over Sonet/SDH (POS)
configuration submode is used to configure such things as cyclical
redundancy check (CRC) and transmit delay
Router configuration submodeRouter configuration submode is
used to select and configure a routing protocol, such as BGP, OSPF, or
IS-IS
! Router submode configurationRouter configuration submodes
are accessed from the router configuration mode.
Username, User Group, Task Group configuration submodes
From these submodes, you configure users, and non-default user and
task groups, to set access privileges.

Configuration Modes
Configuration mode
Interface config submode
Create router pos config submode

configurations
Router config submode
Perform router
operations
Address family config
submode
User and task group config

submode

Administration Modes
Administration mode is currently used to configure secure domain routers
(SDRs) and to install Cisco IOS XR software. In addition, there are a
number of commands that are not available in EXEC mode.
Administration EXECEnter the administration EXEC mode from
EXEC mode. Administration EXEC mode is used primarily to display
system-wide parameters, install software, and manage and monitor
system resources. These operations are available only to users with the
required root-system level access. When non-owner SDRs have been
configured, EXEC mode provides visibility into only the owner SDR.
You can install packages on either a per SDR basis or across the entire
platform, and set the configuration register.
Administration configurationEnter administration configuration
mode from administration EXEC mode. This modes primary
application is to configure non-owner SDRs, control individual card
slots (for example, you can turn power to a slot on and off), and
configure the administration plane over the control Ethernet for multi-
chassis systems. These operations are available only to those users who
have root-system privileges.
SDR configurationEnter SDR configuration to specify a non-
owner SDR to be provisioned and enter non-owner SDR
configuration mode. Here you configure the non-owner SDRs
resources, such as line cards

Administration Modes
Login
EXEC mode Administration EXEC mode
Administration configuration
mode
Per SDR software installations
SDR configuration
Config-register settings submode
Upgrades
Secure Domain Router management

Command Mode Samples

Here are some sample illustrations of the prompt syntax and some
commands used to enter various modes. Note that the prompt changes as
you enter each area of configuration, but the specifics of the protocol or
interface on which you are working are not as clear from the prompt.

Command Mode Samples
EXEC :router#
Global :router# configure

config: :router(config)#
Interface
:router(config)# interface pos 0/2/0/0
submode :router(config-if)#
config:
Protocol and :router(config)# router bgp 140
submode :router(config-bgp)# address-family ipv4
config: :router(config-bgp-af)#
:router# admin
Admin :router#(admin)#
Admin :router(admin)# configure

config :router#(admin-config)#

CLI Prompt Syntax

When logging in to a Cisco IOS XR router, you are accessing the active
route processor (RP) card.
The prompt at which CLI commands are run is shown on the opposite page
and is described as follows:
The first position, or type, indicates the type of card (RP or DRP) to
which you are connected.
The second position, or rack, indicates a shelf number; a single-shelf
system is always 0 and a Multisystem is numbered from 0 to 71.
The next position, or slot, represents the slot in which the active RP is
located; for the Cisco CRS-1 router, the physical slot is either RP0 or
RP1. For a Cisco XR 12000 Series router, the RP could be in any line
card slot. Similarly on a Cisco CRS-1 router, a DRP could be in any line
card slot.
The next position, or module, is the entity on the card that actually
runs the user commands. For the RP, this is CPU0. For a Cisco CRS-1
DRP it could be either CPU0 or CPU1.
The last position is the name assigned to this router, typically defined
during initial configuration with the hostname command.

CLI Prompt Syntax

ASR9KE - CLI Prompt Syntax
Management
Ethernet
Cisco ASR 9000 Series Router Connection MGMT
ETH 0
MGMT
ETH 1
RP/0/RSP0/CPU0:router#
Con
Console AUX
Connection
RP = route processor card
BITS 0
BITS 1
0 = always the same ALARM

PID/VID
RSP0 = either RSP0 or RSP1

CPU0 = always the same
router = router s host name ACO
Lamp
Reset
Fail Sync
Critical HDD
Major CF
Minor ACO

Virtual Routing and Forwarding

Virtual routing and forwarding is a technology employed in IP routing that
allows forwarding of traffic to different customers by segregating the
traffic. With this segregation comes additional security. To implement this
technology, distinct routing tables and FIBs are kept.
Virtual Private Network Routing and Forwarding

The concept of virtual routing and forwarding is employed with the advent
of virtual private networks (VPN), which require the security of segregated
networks for route and data protection.
Cisco uses VPN routing and forwarding as its definition of the acronym,
VRF.
Cisco IOS XR software is delivered with a default VRF definition.

Virtual Routing and Forwarding
Cust A
Provider
Cust B
Network
Cust C
VPN routing and forwarding

Acronym: VRF

Initial Configuration
Considerations
When initially installing a router that runs Cisco IOS XR software, there
are some initial configuration considerations. Important things to include
in the configuration are:
Management IP interfaces on RP cards and IPv4 virtual address
Hostname for easy router recognition and potential inclusion in a
domain name server
Interfaces that the router will serve, such as loopback and network
links
Routing protocols and routes, such as static and default routes
Telnet server for access

Module 4 Initial Configuration
Configuration Considerations
Management interfaces
! RP Ethernet
! Virtual IP address
Hostname
Interfaces
! Loopback
! Network
Routing protocols and routes
! Static
! Default route
Telnet server

Management Interfaces
The out-of-band IP addresses for router management purposes are
assigned to Ethernet ports on RPs. The RPs for Cisco CRS-1 Routers are
always located in RP Slot 0 and Slot 1 in the LCC. Similarly, the RSPs for
Cisco ASR 9000 routers are located in RSP slot 0 and slot 1. The RPs for a
Cisco XR12000 Router can be located in any available line card slot, but
the prompt is always the same.
The Management Ethernet ports on the RPs are commonly connected to
the same subnet and are 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.
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.
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 an RP switchover. The
active and standby RPs can be user configured. The interface on the
standby card is visible and active if configured with an IPv4 address, even
while the card is in standby mode.

Management Interfaces
ASR9KE - Management Ethernet Interfaces
Management
ASR 9006 RSP s in chassis Ethernet
Connection
slots 0 and 1 MGMT
ETH 0
MGMT
ETH 1
ASR 9010 RSP s in chassis Console

Con
AUX
slots 4 and 5 Connection BITS 0
BITS 1
RSP Ethernet ports:

!mgmtEth0/RSP0/CPU0/0 ALARM
PID/VID
!mgmtEth0/RSP1/CPU0/0
Cisco ASR 9000 Series Router

ACO
Lamp
Reset
Fail Sync
ASR9KE - Management Ethernet Interfaces

Critical HDD
Major CF
Minor ACO
(Cont.)
:router# configure
:router(config)# interface MgmtEth0/RSP0/CPU0/0
:router(config-if)# ipv4 address 172.21.116.10/24
:router(config-if)# no shutdown
:router(config-if)#
Interface mode
Set the IP version
!IPv4 or IPv6 address
!Mask
Activate the interface

Configuring IP Virtual Address

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 active Ethernet port, with
which it shares a common IP subnet, on the currently active RP. Because it
survives RP switchover, it functions as an always available management
address without depending on any routing protocol on the Management
Ethernet.
____________________________ Note _________________________
The show ipv4 interface command does not display the IPv4 virtual
address. The address does appear in the Routing Information Base (RIB)
and in the Address Resolution Protocol (ARP) table.
__________________________________________________________________

Configuring IP Virtual Address
:router(config)# ipv4 virtual address 172.21.116.12/24

:router(config)#
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
IPv4 command
! Assign IP address and mask
Only visible in RIB (not an IP interface)

Configuring 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 our lab configuration filenames,
and, in general, 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.

:router(config)# hostname PE1

:router(config)#
Create a hostname

Configuring Loopback Interfaces

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.
____________________________ Note _________________________
The show ipv4 interface command displays loopback addresses. The
loopback address appears in the Routing Information Base (RIB). However,
the loopback address does not appear in the ARP table, because it is not
associated with any physical interface.
__________________________________________________________________

Configuring Loopback Interfaces
:router(config)# interface loopback0

:router(config-if)#
Interface command
Assign IP address
Visible as interface
2011, Cisco Systems, Inc. All rights reserved. Version 4.0.1 Course NameModule 00/27

Network Interface Numbering

All network interfaces use a numbering format that identifies its physical
location within the chassis.
The format is rack/slot/subslot/port:
rackSpecifies the rack number; always 0 in a single-chassis system.

slotSpecifies the slot number in the chassis in which the LC is
inserted.
subslotSpecifies the secondary slot location which is always 0 for
integrated line cards.
portSpecifies the interface number on the line card.

SPA Interfaces
Shared port adapters (SPA) interfaces use the same numbering format but
subslot specifies the secondary slot on the SIP in which the SPA is
installed and port specifies the interface number on the SPA.
A SIP-800 installed in LC slot 4 containing a 4-port OC-3c/STM-1 POS
SPA installed in subslot 3 with a connection in port 2, would be identified
as:
interface pos0/4/3/2
____________________________ Note _________________________
The numbering format discussed here applies to all Cisco IOS XR
supported platforms.
__________________________________________________________________

Network Interface Numbering
An integrated OC-3 POS line card installed in LC

slot 3
Port 6 of that LC would be identified as:
rack slot subslot port

!Subslot number is 0 for integrated LC
A SIP installed in LC slot 4

A 4-port OC-3 POS SPA is installed in SIP
subslot 3
Port 2 of that SPA would be identifed as:
rack slot subslot port

Configuring Network Interfaces

Interfaces connected to other routers are configured from global
configuration mode.
To configure interfaces, you take these steps:
1. Enter interface submode for the specific network interface
2. Set the IP address
3. Activate the interface

Configuring Network Interfaces
:router(config)# interface POS 0/3/0/4

:router(config-if)# no shutdown
:router(config-if)#
Interface command
!Rack/slot/subslot/port
!Assign IP address
!Activate the interface
Configuring Static and Default Routes
A static route may be a requirement for your network. A default route,

which is a static route, may be needed to provide you with Telnet access to
manage the router from a remote location.

The configuration for static routes is a routing protocol configuration. The

address family must be designated as either IPv4 or IPv6, and unicast or
multicast. The route is configured with the destination prefix, prefix mask,
and next hop address. An outgoing interface may be used instead of the
next hop address.

Configuring Static and Default Routes
:router(config)# router static

:router(config-static)# address-family ipv4 unicast
:router(config-static-afi)# 0.0.0.0/0 172.21.116.1
:router(config-static-afi)#
Protocol configuration
Choose address family
! IPv4 or IPv6
! Unicast or multicast
Destination prefix and mask
Next hop address or outgoing interface

Configuring Telnet Access

To provide Telnet access to a Cisco IOS XR router, you create an instance
of a Telnet server. The Telnet server is configured as either IPv4 or IPv6.
By default, the number of telnet lines available in the vty pool is five.
(vty-pool default 0 4). To raise the default pool beyond five, use the vty-
pool command. The telnet ipv4 server max servers command is
used to enable telnet functionality. You can limit the number of Telnet
sessions to the router using the max-servers argument.
You can also configure the router as a Telnet client.
When displaying the running configuration (explained later in this
module), you see the Telnet configuration as part of the default virtual
routing and forwarding implementation.

Configuring Telnet Access
:router(config)# telnet ipv4 server max-servers 5

:router(config)# show config
!
telnet vrf default ipv4 server max-servers 5
Allowing Telnet access

Choose IPv4 or IPv6
Server or client
Limit sessions
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
:router(config)# commit
:router(config)#
Target changes must pass semantics

! Pass; all changes are committed
! Fail; no changes are committed

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. Cancelling continues the existing configuration session and
keeps the current target configuration in memory.
If you want to commit the changes to the running configuration, you must
respond by typing yes.

Exiting and Ending Configuration Mode
Exit configuration mode

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

:router# configure
:router(config)# interface pos 0/5/0/1 pos crc 16
:router(config-if)# end
Uncommitted changes found, commit them before exiting(yes/no/cancel)?
[cancel]:yes
:router#
! Type "no" to exit or end without committing changes

! Type "yes" for changes to take effect
! Enter or "cancel" continues existing session with current config

Aborting Configuration Mode

The abort command finishes the configuration session immediately
without saving any target configuration. If there are uncommitted changes
when aborting configuration mode, they are lost without any warning. The
same result can be accomplished by issuing the clear command followed
by the end command.

RP/0/0/CPU0:router# configure
RP/0/0/CPU0:router(config)# interface pos 0/5/0/1 pos crc 16
RP/0/0/CPU0:router(config-if)# abort
RP/0/0/CPU0:router#
Ends the configuration session immediately

! No warning before deletion of changes

Reviewing the Configuration

Through the use of Cisco IOS XR show commands, you can review the
configuration file and other relevant information.
Displaying the Active Configuration

The running configuration is the active configuration used to operate the
router; that is, the committed configuration that defines the router
operations.
The show running-config command displays the details of the active, or
currently running, configuration.
You can see specific parts of the current configuration by using additional
parameters, such as:
interfaceDisplays the interfaces
router protocolDisplays the routing protocol specified
usernameDisplays the users configured

These and other parameters are available to minimize the amount of
information you display, particularly with a large router configuration.

Module 4 Reviewing the Configuration
Displaying the Active Configuration

ASR9KE - For Print!!
:P1(config)# show running-config

Building configuration...
!! Last configuration change at 01:17:15 est Thu Feb 14 2011 by cisco
!
hostname PE1
clock timezone est -5
telnet vrf default ipv4 server max-servers 5
ipv4 virtual address 172.21.116.12 255.255.255.0
!
interface Loopback0
ipv4 address 10.1.1.1 255.255.255.255
!
interface MgmtEth0/RSP0/CPU0/0
ipv4 address 172.21.116.10 255.255.255.192
!
[... output omitted]
end
Display entire running configuration

:P1# show run router static

router static
address-family ipv4 unicast
0.0.0.0/0 172.21.116.1
!
!
Display by configuration groupings (interfaces,

routing protocols, and other)

Displaying the Target Configuration

The target configuration is the configuration with 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 command while still in configuration mode.
__________________________________________________________________

Displaying the Target Configuration
:P1(config)# show config

interface POS0/3/0/6
ipv4 address 192.168.16.1 255.255.255.0
!
ipv4 address 192.168.15.1 255.255.255.0
!
end
Display uncommitted changes only from

configuration mode

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.

Displaying the Merged Configuration

ASR9KE - Displaying the Merged Configuration
:P1(config)# show config merge

hostname P1
interface MgmtEth0/RSP0/CPU0/0
ipv4 address 172.21.116.10 255.255.0.0
!
ipv4 address 192.168.12.1 255.255.255.0
!
interface GigabitEthernet 0/2/0/1
ipv4 address 192.168.111.1 255.255.255.0 Added
!
ipv4 address 192.168.121.1 255.255.255.0
!
end

Displaying Interfaces
The show interface command presents the statistics for interfaces that
are configured on the router, in slot order and by interface type and
instance number. The brief keyword, as shown in the slide, presents a
summary of one line for each interface configured. The physical interface
display is in the form rack/slot/module/port.
Displaying Individual Interfaces
Individual interfaces can be displayed by including the specific interface

type and number, as shown in the slide. The information about individual
interfaces includes: hardware type, Internet address, maximum
transmission unit (MTU), bandwidth, encapsulation type, and a variety of
statistics.

Displaying Interfaces
:router# show interface brief
Intf Intf LineP Encap MTU BW

Name State State Type (byte) (Kbps)
--------------------------------------------------------------------------
Lo0 up up Loopback 1514 Unknown
Nu0 up up Null 1500 Unknown
Mg0/RSP0/CPU0/0 up up ARPA 1514 100000
Mg0/RSP0/CPU0/1 admin-down admin-down ARPA 1514 10000
Mg0/RSP1/CPU0/0 up up ARPA 1514 100000
Mg0/RSP1/CPU0/1 admin-down admin-down ARPA 1514 10000
Gi0/1/0/0 down down ARPA 1514 1000000
Gi0/1/0/1 down down ARPA 1514 1000000
Gi0/2/0/0 down down ARPA 1514 1000000
Gi0/2/0/1 up up ARPA 1514 1000000
Gi0/2/0/2 up up ARPA 1514 1000000
:router# show interface GigabitEthernet 0/2/0/1

GigabitEthernet0/2/0/1 is up, line protocol is up
Interface state transitions: 1
Hardware is GigabitEthernet, address is 001d.e5eb.84a9 (bia 001d.e5eb.84a9)
Description: Connection to P1
Internet address is 192.168.71.1/24
MTU 1514 bytes, BW 1000000 Kbit
reliability 255/255, txload 0/255, rxload 0/255
Encapsulation 802.1Q Virtual LAN,
Full-duplex, 1000Mb/s, SXFD, link type is force-up
output flow control is off, input flow control is off
loopback not set,
ARP type ARPA, ARP timeout 04:00:00
Last clearing of "show interface" counters 5d20h
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
224912 packets input, 20649349 bytes, 0 total input drops
0 drops for unrecognized upper-level protocol
Received 47089 broadcast packets, 174265 multicast packets
0 runts, 0 giants, 0 throttles, 0 parity
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
403169 packets output, 37509837 bytes, 0 total output drops
Output 47089 broadcast packets, 352998 multicast packets
0 output errors, 0 underruns, 0 applique, 0 resets
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions

Displaying IP Interfaces
The show ipv4 interface command presents a list of all interfaces, their
IPv4 addresses, if configured, and the status of both the interface and the
protocol.
To display specific information about individual interfaces, use a show
interface command that includes the protocol address family (IPv4 or
IPv6) and the specific interface instance. The slide provides an example.

Displaying IP Interfaces
:router# show ipv4 interface brief
Interface IP-Address Status Protocol

Loopback0 10.1.1.1 Up Up
MgmtEth0/RSP1/CPU0/0 172.21.116.11 Up Up
MgmtEth0/RSP1/CPU0/1 unassigned Shutdown Down
MgmtEth0/RSP0/CPU0/0 172.21.116.10 Up Up
MgmtEth0/RSP0/CPU0/1 unassigned Shutdown Down
GigabitEthernet0/1/0/0 unassigned Down Down
GigabitEthernet0/2/0/0 unassigned Shutdown Down
GigabitEthernet0/2/0/1 192.168.111.1 Up Up
GigabitEthernet0/2/0/2 192.168.121.1 Up Up
:router# show ipv4 interface GigabitEthernet 0/2/0/1
GigabitEthernet0/2/0/1 is Up, line protocol is Up

Vrf is default (vrfid 0x60000000)
MTU is 1514 (1500 is available to IP)
Helper address is not set
Multicast reserved groups joined: 224.0.0.2 224.0.0.1 224.0.0. 5
224.0.0.6
Directed broadcast forwarding is disabled
Outgoing access list is not set
Inbound access list is not set
Proxy ARP is disabled
ICMP redirects are never sent
ICMP unreachables are always sent
ICMP mask replies are never sent

Displaying the Routing Table

The show route command displays the routes currently in the Routing
Information Base (RIB) table.

Displaying the Routing Table

ASR9KE - Displaying the Routing Table
:router# show route
C 172.21.116.0/24 is directly connected, 2d19h, MgmtEth0/RSP0/CPU0/0

is directly connected, 2d19h, MgmtEth0/RSP1/CPU0/0
L 172.21.116.10/32 is directly connected, 2d20h, MgmtEth0/RSP0/CPU0/0
L 172.21.116.12/32 [0/0] via 172.21.116.12, 2d19h, MgmtEth0/RSP0/CPU0/0
O 192.168.12.0/24 [110/2] via 192.168.111.11, 2d19h, GigabitEthernet0/2/0/1
[110/2] via 192.168.121.12, 2d19h, GigabitEthernet0/2/0/2
[110/2] via 192.168.121.12, 2d19h, GigabitEthernet0/2/0/2
C 192.168.111.0/24 is directly connected, 2d20h, GigabitEthernet0/2/0/1
L 192.168.111.1/32 is directly connected, 2d20h, GigabitEthernet0/2/0/1
Use show route or show ipv4 route from EXEC mode


RP Redundancy
Displaying Redundancy
The status of RP redundancy of the router is displayed using the show
redundancy command. The display shows which RP is the active RP and
which is the standby RP. The display further shows the status of the
standby RP, along with the most recent reload and boot information.
Should the standby RP need to become the active RP, you can make the
switch by entering the redundancy switchover command and
confirming the switchover.

Displaying Redundancy
ASR9KE For Print!!
router# show redundancy

Redundancy information for node 0/RSP1/CPU0:
==========================================
Node 0/RSP1/CPU0 is in ACTIVE role
Partner node (0/RSP0/CPU0) is in STANDBY role
Standby node in 0/RSP0/CPU0 is ready
Standby node in 0/RSP0/CPU0 is NSR-ready
Reload and boot info

----------------------
A9K-RSP-4G reloaded Mon Dec 6 23:51:52 2010: 2 weeks, 1 day, 22 hours, 52 mi
Active node booted Tue Dec 7 18:43:10 2010: 2 weeks, 1 day, 4 hours, ago
Last switch-over Wed Dec 15 17:30:42 2010: 1 week, 5 hours, 13 minutes ago
Standby node boot Wed Dec 15 17:31:26 2010: 1 week, 5 hours, 12 minutes ago
Standby node last went not ready Wed Dec 22 04:23:39 2010: 18 hours, 20 mi
Standby node last went ready Wed Dec 22 04:23:39 2010: 18 hours, 20 minut
There have been 3 switch-overs since reload
Display the
ASR9KE current redundancy state
RSP Redundancy (Cont.)
router# redundancy switchover

Updating Commit Database. Please wait...[OK]
Proceed with switchover 0/RSP0/CPU0 -> 0/RSP1/CPU0?[confirm]
Initiating switch-over.
Switch over to standby RP (EXEC mode)

Summary
Cisco IOS XR Configuration Basics
Describe the configuration file system

Describe login access
Describe command modes
Explain CLI prompts
Describe management addressing
Accomplish an initial configuration
Use redundancy commands

Module 5
Cisco IOS XR Installation
Overview
Description
This module teaches you to select, prepare, install, activate, and deactivate
Cisco IOS XR software packages.
Objectives
Describe the Cisco IOS XR packaging model
Summarize 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
Articulate the process of optional software installation and removal

Cisco IOS XR Installation Module 5
Cisco IOS XR Software Packaging

Software Packages
Software packages are groups of software components that provide
functionality for the various installed cards. These packages can be
installed, upgraded, or downgraded individually (provided the new
packages are compatible with the currently 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) in Admin EXEC mode. Software configurations are created
by activating or deactivating packages to add or remove functionality,
upgrade to new software, or downgrade to earlier versions. Line cards can
maintain state during the upgrade or downgrade of software, resulting in
less disruption to the system as a whole.
The slide shows the currently available software packages and examples of
where they can be implemented.

Module 5 Cisco IOS XR Software Packaging
Software Packages
RP LC
Multi- Optional
Doc Diags MPLS
cast
Manage- Optional
Security
ability
Routing
Multi-
MPLS
cast Line card
Mandatory
Forwarding
Routing
Base
OS-MBI
Line card
Mandatory
Forwarding
Admin
Base
OS-MBI
Implementation locations

Software Package Types

Cisco IOS XR software comprises modular "packages," that contain the
components to perform a specific set of router functions, such as routing,
security and modular services card or line card support.
The Cisco IOS XR Unicast Routing Core Bundle is a package containing
the following software components:
Operating system (OS) and minimum boot image (MBI)

Base and administration
SNMP agent and alarm correlation
Routing and forwarding (unicast)

Modular services card or line card drivers
Optional packages provide additional features:
ManageabilitySupport for Corba agent, XML parser, HTTP server,
SNMP, and other management tools
MPLSSupport for Multiprotocol Label Switching (MPLS),
Generalized MPLS (GMPLS), Label Distribution Protocol (LDP),
Resource Reservation Protocol (RSVP), and other associated protocols
MulticastSupport for multicast protocols, tools, and infrastructure
SecuritySupport for encryption, decryption, IPSec, SSH, Secure
Sockets Layer (SSL), and PKI
DocumentationManual (man) pages for Cisco IOS XR commands

DiagnosticsUtilities for testing and verifying hardware functionality
while connected to a live network, helping ensure high availability
FPDFirmware for programmable devices on line cards
Carrier Grade NATSupport for Carrier Grade Network address
Translation on a Cisco CRS-1 router
Service IPsecSupport for IPsec and GRE tunnel interfaces a on Cisco
XR 12000 Series router
FirewallSupport for Virtual Firewall (VFW) on a Cisco XR 12000
Series router
Advanced VideoFirmware for the advanced video feature on a Cisco
ASR 9000 Series router
OpticsFirmware for the optics feature on a Cisco ASR 9000 Series
router

Software Package Types
Manageability MPLS, Diags, Doc, Security

Multicast
CORBA, XML, GMPLS, Firmware, IPSec, encryption,
LDP, RSVP PIM, MFIB, IGMP
alarms etc. decryption
Line card
Line card drivers
Unicast Core Routing Bundle

Forwarding
FIB, ARP, QoS, ACL, and so on
Routing
RIB, BGP, ISIS, OSPF, EIGRP, RIP, RPL
Administration
Resource management: rack, fabric, SDR
Base
Interface manager, system database, checkpoint services,
configuration management, other slow-changing components
OS-MBI
Kernel, file system, memory management, and other slow-changing core components

Package Installation Envelope (PIE)

Software packages are available as package installation envelope (PIE)
files (.pie extension). PIEs 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 boot device of the route
processor (RP). During this installation, one or more directories are
automatically created to store the components of the package. The
directory name is generally based on the name of the package.
Cisco CRS-1 Routers
Following are some examples of the PIE files you might use for the
operation of a Cisco CRS-1 router:
hfr-mini-p.pie-x.y.z
hfr-mpls-p.pie-x.y.z
hfr-k9sec-p.pie-x.y.z
hfr-mcast-p.pie-x.y.z
hfrk-mgbl-p.pie-x.y.z
hfr-doc-p.pie-x.y.z
Cisco XR12000 Series Routers
operation of a Cisco XR 12000 Series router:
c12k-mini.pie-x.y.z
c12k-mpls.pie-x.y.z
c12k-k9sec.pie-x.y.z
c12k-mcast.pie-x.y.z
c12k-mgbl.pie-x.y.z
c12k-doc.pie-x.y.z
Cisco ASR 9000 Series Routers
operation of a Cisco ASR 9000 Series router:
asr9k-mini-p,pie-x.y.z
asr9k-mpls.pie-x.y.z
asr9k-k9sec.pie-x.y.z
asr9k-mcast.pie-x.y.z
asr9k-mgbl.pie-x.y.z
asr9k-doc.pie-x.y.z

Package Installation Envelope
Package installation envelope

Documentation Security Manageability (PIE) files
Non-bootable
Upgrade or add features
Multi- Examples:
MPLS Diags
cast ! hfr-mcast-p.pie-x.y.z
! c12k-mcast.pie-x.y.z
! asr9k-mcast.pie-x.y.z
Unicast core routing

BGP, ISIS, OSPF bundle routing
EIGRP, RIP components
RIB, RPL

Software Maintenance Update

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.
SMUs are not an alternative to maintenance releases. They provide quick
resolution of immediate issues. All caveats fixed by SMUs are typically
integrated into subsequent maintenance releases.

Software Maintenance Update
Update specific software

Install just like a feature .pie file
Follow the same command
sequence to install
ISIS ISIS
SMU updated
BGP OSPF
BGP
OSPF OSPF
Mcast Mcast
RIP All other packages RIP
remain the same
EIGRP EIGRP

Composite Software Upgrade

The Routing Core Bundle is an example of a composite file. A composite file
is one that contains multiple software components. This typical software
upgrade is likely to be a composite PIE file, which contains upgrades to
current software.
An example of a software upgrade would be to upgrade the Cisco IOS XR
Unicast Routing Core Bundle to a new release, such as from Release 4.0.1
to Release 4.1.0.
It is the intent of software upgrades to support In-Service Software
Upgrades (ISSU) and Minimum Disruption Restart (MDR). This provides a
level of high availability by allowing service to continue, or be disrupted as
little as possible, while a software upgrade takes place.
__________________________ CAUTION _______________________
Upgrades between major releases, such as from Release 3.6.3 to
Release 4.0.1, can require procedures beyond simply upgrading
the existing packages. Always consult the new release notes for
any special upgrade procedures.
__________________________________________________________________

Composite Software Upgrade
Most likely upgrade

3.5.2 core bundle 3.5.3 core bundle
Routing Routing
Line card Line card
Forwarding Forwarding
Admin Admin
Base Base
OS-MBI OS-MBI
Example: comp-hfr-mini.pie-x.y.z
Example: c12k-mini.pie-x.y.z

Bootable Code
Core bundle packages are delivered to you in two compressed forms ! .vm
and .pie files.
Files with the .vm extension are bootable files that contain bootup code and
mandatory package software, such as the Unicast Core Bundle. Using the
TURBOBOOT procedure, these files may be used to boot the router for the
first time or for emergency recoveries from a corrupt boot disk. This
process also installs a mandatory set of feature packages.

Bootable Code
Bootable entities
!.vm files are bootable core OS
!Shipped with new routers
!Examples:
" hfr-mini-p.vm-x.y.z
Routing " c12k-mini.vm-x.y.z
" asr9k-mini.vm-x.y.z
Line card
Forwarding Initial or emergency

Admin
installation files
Base
OS-MBI

Software Versioning
Base Package Versions
Software package versions are identified by a three-part numeric scheme:

Major releaseContains a collection of features across multiple
packages. A major release is the least-frequent release and typically
includes large-scale changes that require a router reload.
Minor releaseContains feature upgrades for single packages. A
minor release usually occurs at the application level and, although
some individual router processes may restart, a router reload is
typically not required.
Maintenance releaseContains a collection of caveat resolutions 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 Versioning
Release ! major.minor.maintenance
Delivery vehicle File naming
Composite PIE platform-composite_name.pie-major.minor.maintenance
Single package PIE platform-package_type.pie-major.minor.maintenance
Composite SMU comp-platform-composite_name.ddts.pie
Single package SMU platform-package_type-major.minor.maintenance.ddts.pie
IOS XR platform name: Composite PIE examples

! Cisco CRS-1 router ! hfr ! Cisco CRS-1 router: hfr-mini-p.pie-4.0.1
! Cisco XR 12000 Series router ! c12k ! Cisco XR12000 Series router: c12k-mini.pie-4.0.1
! Cisco ASR 9000 Series router ! asr9k ! Cisco ASR 9000 Series router: asr9k-mini.pie-4.0.1
Single package PIE examples
! Cisco CRS-1 Router: hfr-mpls-p.pie-4.0.1
! Cisco XR12000 Series Router: c12k-mpls.pie-4.0.1
! Cisco ASR 9000 Series router: asr9k-mpls.pie-4.0.1
SMU example
! hfr-p-4.0.1.CSCtk66361.pie

Software Storage
Cisco IOS XR software is installed on the RPs boot device, which is
typically flash disk0: in the router. You can download software prior to its
actual installation. The downloaded software may be stored on a different
media device, such as the optional flash disk1: or harddisk:, until it is
ready to be installed.

Software Storage
ASR9KE - Software Storage
ASR 9000 MGMT

RSP ETH 0
MGMT
ETH 1
Con
AUX
BITS 0
BITS 1
ALARM
PID/VID
disk0:
ACO
Lamp
Reset
Fail Sync
HDD
Major CF
Minor ACO

Installing Software Packages

Code fixes (SMUs) and additional package PIE files are typically copied to
a local server or to (optional) disk1: in their compressed format prior to
beginning the IOS XR installation procedure. This file transfer can use any
of the following mechanisms:
Trivial File Transfer Protocol (TFTP)
File Transfer Protocol (FTP)
Remote Copy Protocol (RCP)
SSH File Transfer Protocol (SFTP)
The commands involved in installing a software package on the router are:
1. install addDecompresses the installation file and builds the
directory structure on the boot disk
2. install activateAdds the new software features into memory and
makes them available for configuration
3. install commitMakes the software features persistent over a reload
Each of the preceding commands are discussed in greater detail on the
following pages.

Installing Software Packages
install add ! Decompresses

the installation file and builds install activate ! Adds the
directory structure new software features to
Memory memory and makes them
SDR available for configuration
1
2
Installdb
Server
disk0:
3
install commit ! Makes features

persistent over a reload

Considerations Prior to Software Installation

We recommend the following best practices when preparing to install Cisco
IOS XR software packages.
Some Best Practices

Prior to installing any software you should create a baseline of the routers
current status. After completing the installation, you should determine if
any adverse effect has occurred. Here are some of the best practices for
completing these tasks.
Prior to software installation, you should:
Verify the system clockSoftware installation uses certificates based
on router clock times
Verify the current system statusTwo commands (illustrated in
following pages) verify the software, looking for any anomalies and a
variety of system information such as memory usage, CPU usage, and
processes status. It is important to understand what the messages in
the system verification mean; refer to documentation and Cisco
Technical Support for further information
Verify the current software versionsDetermine the current version to
decide whether change is necessary
Verify the new software compatibilityDue to interdependencies
between some software packages, some version compatibility is
required. Release notes should also be reviewed for further information
After the software installation, you should:
Verify the system statusEnsure that the changes have not adversely
affected the router
Verify the new software versionEnsure that the version of software is
correctly installed
Verify the stability of the new softwareTest the new software

Module 5 Considerations Prior to Software Installation
Some Best Practices
Before installation, verify

! system clock
! system status
! current software versions
! new software compatibility
After installation, verify
! system status
! current software versions
! stability of new software

Verifying the Router Clocks

Two clocks are used to manage time in a Cisco router. A hardware clock,
also called the calendar clock, maintains time continuously, even if the
router is powered down or rebooted. The second clock, the system software
clock, is erased during a power cycle or reboot. Use the show clock
command to verify the system clock.
Setting the System 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 system 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.
Before a software package installation on the router, the system clock
should be set correctly. The clock set command requires the hour,
minutes, and seconds for the time, but the date may be entered in either
North American (month/day) or European (day/month) format.
__________________________ CAUTION _______________________
Failure to properly set the system clock causes CA Certificate
problems. If the router clock is not set to a valid date, that is
one prior to the certificates expiration date, the following
error is displayed:
SAM detects CA certificate (Code Signing Server Certificate
Authority) has expired...
__________________________________________________________________
Setting the Hardware Clock
Use the clock update-calendar command to set the hardware clock from
the system clock.
The clock read-calendar copies the hardware clock settings into the
system clock. Use the show calendar command to verify the calendar
settings.

Verifying the Router Clocks
Verifying system clock

:router# show clock
17:24:23.648 EST Thu Apr 07 2011
Verifying hardware calendar

:router# show calendar
17:24:23 EST Thu Apr 07 2011
System clock should be valid for certificate

!Digital certificate processing
Set system clock

:router# clock set 17:24:23 07 Apr 2011
or
:router# clock set 17:24:23 Apr 07 2011
Update the hardware calendar
:router# clock update-calendar

Verifying System Status

The install verify command matches the consistency of the installed
software against the file from which it originated. It acts as a debugging
tool to determine installation file validity.
The healthcheck keyword verifies only the packages that are active.
Both checks support the following optional keywords to constrain the verify
operation:
sdrVerification is limited to packages on a named secure domain
router
locationVerification is limited to packages on a specific location
(node).

Verifying System Status

ASR9KE - Verifying System Status (for Print)
:router(admin)# install verify
Install operation 531 '(admin) install verify packages' started by user 'cisco'
:router(admin)# install verify
via CLI at 15:26:28 UTC Tue Jul 05 2011.
Install operation 39 '(admin) install verify packages' started by user 'cisco'
via CLI at operation
The install 13:10:21will
UTCcontinue
Thu Marasynchronously.
27 2008.
The install operation will continue asynchronously.
RP/0/RSP0/CPU0:PE2(admin)#Info:
Info: This operation can take This up
operation can take per
to 2 minutes up topackage
2 minutesbeing
per package being verified.
verified.
Please be patient.
Info: Please be patient.
Info: 0/1/CPU0 [LC] [SDR: Owner]
[...
Info: additional output
meta-data: omitted]
[SUCCESS] Verification Successful.
Info:
Info: 0/0/CPU0 [RP] [SDR: Owner][SUCCESS] Verification Successful.
/install/asr9k-fwding-4.0.1:
Info:
Info: /install/c12k-mcast-3.5.2:
/install/asr9k-cpp-4.0.1: [SUCCESS][SUCCESS]
VerificationVerification
Successful. Successful.
Info:
Info: /install/asr9k-scfclient-4.0.1:
/install/c12k-mpls-3.5.2:[SUCCESS]
[SUCCESS]Verification Successful.
Verification Successful.
Info: /install/iosxr-routing-4.0.1: [SUCCESS] Verification Successful.
Info: /install/c12k-rout-3.5.2: [SUCCESS] Verification Successful.
Info: /install/iosxr-infra-4.0.1: [SUCCESS] Verification Successful.
Info:
Info: /install/c12k-lc-3.5.2:
/install/iosxr-fwding-4.0.1: [SUCCESS]
[SUCCESS] Verification
Successful.
Info:
Info: /install/c12k-fwdg-3.5.2:
/install/iosxr-diags-4.0.1: [SUCCESS]
Verification Successful.Successful.
Info:
Info: /install/c12k-admin-3.5.2:[SUCCESS]
/install/asr9k-diags-supp-4.0.1: [SUCCESS] Verification
Successful.
Info:
Info: /install/asr9k-base-4.0.1:
/install/c12k-base-3.5.2:[SUCCESS] Verification
[SUCCESS] Successful. Successful.
Verification
Info:
Info: 0/2/CPU0 [LC] [SDR: Owner]
/install/c12k-os-mbi-3.5.2: [SUCCESS] Verification Successful.
Info: meta-data: [SUCCESS] Verification Successful.
Info:
Info: 0/1/CPU0 [RP] [SDR: Owner][SUCCESS] Verification Successful.
/install/asr9k-fwding-4.0.1:
Info:
Info: /install/c12k-mcast-3.5.2:
/install/asr9k-cpp-4.0.1: [SUCCESS][SUCCESS]
VerificationVerification
Successful. Successful.
Info:
Info: /install/c12k-mpls-3.5.2:[SUCCESS]
/install/asr9k-scfclient-4.0.1: [SUCCESS] Verification
Successful.
Info:
Info: /install/iosxr-routing-4.0.1:
/install/c12k-rout-3.5.2: [SUCCESS] Verification
[SUCCESS] Successful.
Info:
Info: /install/iosxr-infra-4.0.1:
/install/c12k-lc-3.5.2: [SUCCESS] Verification
[SUCCESS] Successful.
Info: /install/iosxr-fwding-4.0.1: [SUCCESS] Verification Successful.
Info:
Info: /install/c12k-fwdg-3.5.2:
/install/iosxr-diags-4.0.1: [SUCCESS]
Verification Successful.Successful.
Info:
Info: /install/c12k-admin-3.5.2:[SUCCESS]
/install/asr9k-diags-supp-4.0.1: [SUCCESS] Verification
Successful.
Info:
Info: /install/c12k-base-3.5.2:
/install/asr9k-base-4.0.1: [SUCCESS]
Verification Successful. Successful.
--More
Info: /install/c12k-os-mbi-3.5.2: [SUCCESS] Verification Successful.
--More--
ASR9KE - Verifying System Status (Cont.)
Info: /install/asr9k-fpd-4.0.1: [SUCCESS] Verification Successful.

Info: /install/asr9k-cpp-4.0.1: [SUCCESS] Verification Successful.
Info: /install/asr9k-scfclient-4.0.1: [SUCCESS] Verification Successful.
Info: /install/asr9k-diags-supp-4.0.1: [SUCCESS] Verification Successful.
Info: /install/asr9k-fwding-4.0.1: [SUCCESS] Verification Successful.
Info: /install/asr9k-base-4.0.1: [SUCCESS] Verification Successful.
Info: /install/iosxr-diags-4.0.1: [SUCCESS] Verification Successful.
Info: /install/iosxr-routing-4.0.1: [SUCCESS] Verification Successful.
Info: /install/iosxr-fwding-4.0.1: [SUCCESS] Verification Successful.
Info: /install/iosxr-infra-4.0.1: [SUCCESS] Verification Successful.
Info: Verification Summary:
Info: 0/0/CPU0: SUCCESSFUL. No anomalies found.
Info: 0/2/CPU0: SUCCESSFUL. No anomalies found.
Info: 0/RSP1/CPU0: SUCCESSFUL. No anomalies found.
Info: 0/RSP0/CPU0: SUCCESSFUL. No anomalies found.
Info: The system needs no repair.
Install operation 531 completed successfully at 15:30:03 UTC Tue Jul 05 2011.
All packages in chassis (default), Secure Domain Router or location

Use the show system verify command to see a variety of information

including the memory and CPU usage, process status, protocol status, and
other status information.
____________________________ Note _________________________
While most of the output should have an indication of OK, some
processes may show other output, such as WARNING. This does not
necessarily indicate a problem.
__________________________________________________________________
To initiate the system verification, you must issue a show system verify
start command first. Other available keywords for the verification process
are:
detailProvides more specific information at the individual card and
processor level, including actual numbers
reportDefault output; same as the show system verify command

Verifying System Status (Cont.)
:router(admin)# show system verify start

Storing initial router status
[... at some time later]
done.
:router(admin)# show system verify

Getting current router status ...
System Verification Report
==========================
- Verifying Memory Usage
- Verified Memory Usage : [OK]
- Verifying CPU Usage
- Verified CPU Usage : [OK]
- Verifying Blocked Processes

- Verified Blocked Processes : [OK]
- Verifying Aborted Processes
- Verified Aborted Processes : [OK]
- Verifying Crashed Processes
- Verified Crashed Processes : [OK]
- Verifying LC Status
- Verified LC Status : [OK] : [OK]

Displaying Current Software

The show install active command displays the active software that is
installed on the router, including all SDRs. Use this command to record
what is currently installed as a comparison tool for post-installation
analysis.

Displaying Current Software

Secure Domain Router: Owner
Node 0/RSP0/CPU0 [RP] [SDR: Owner]

Boot Device: disk0:
Boot Image: /disk0/asr9k-os-mbi-4.0.1/mbiasr9k-rp.vm
Active Packages:
Owner
disk0:asr9k-mini-p-4.0.1 SDR
Boot Device: disk0:
Active Packages:
disk0:asr9k-mini-p-4.0.1
Node 0/1/CPU0 [LC] [SDR: Owner]
Boot Device: mem:
Boot Image: /disk0/asr9k-os-mbi-4.0.1/lc/mbiasr9k-lc.vm
Active Packages:

Boot Device: mem:
Active Packages:

Verifying Software Compatibility

Prior to installing the software, you should verify that the available
software is compatible with the router on which you are working. The
show install pie-info command should be used for this task.
This command provides three levels of information using the following
keywords:
briefshows the expiration date of the file, the size, and the installed
package name; the default
detailshows the package components, the compatible cards, the
expiration date, the file size, and the installed package name
verboseshows the subcomponents as well as the information
available in the detail level
The certificate expiration date is validated when the file is installed on the
boot media with the install add command.

Verifying Software Compatibility

ASR9KE - Verifying Software Compatibility
:router(admin)# sh install pie-info tftp://172.21.116.8/4.0.1/asr9k-mpls-p.pie-4.0.1 detail
Tue Jul 5 15:34:21.011 UTC
Contents of pie file '/tftp://172.21.116.8/4.0.1/asr9k-mpls-p.pie-4.0.1':

Expiry date : Oct 17, 2015 01:51:47 UTC
Uncompressed size : 12959830 Certificate
Compressed size : 5040042 expiration
asr9k-mpls-p-4.0.1
asr9k-mpls-p V4.0.1[Default] Asr9k MPLS Pie bundle
[composite package]
[root package, grouped contents]
Vendor : Cisco Systems
Desc : Asr9k MPLS Pie bundle
Build : Built on Wed Dec 15 09:18:20 UTC 2010
Source : By sjc-lds-524 in /auto/srcarchive4/production/4.0.1/asr9k/workspace for
pie
Card(s): RP, NP24-4x10GE, NP24-40x1GE, NP40-40x1GE, NP40-4x10GE, NP40-8x10GE,
NP40-2_20_COMBO, NP80-8x10GE, NP80-16x10GE, A9K-SIP-700, A9K-SIP-500
Restart information:
Default: Supported
parallel impacted processes restart cards
Size Compressed/Uncompressed: 4921KB/12MB (38%)
Components in package asr9k-mpls-p-4.0.1, package asr9k-mpls-p:
iosxr-mpls-4.0.1
Certificate expiration date validated during install add


Software Installation
The installation of Cisco IOS XR software has several steps. Some of these
steps can be combined. The installation process is discussed on the next
several pages.
Adding Packages to the Router

The install add command is executed in the administration EXEC mode.
The administration EXEC mode installs software on all SDRs (default).
The install add command unpacks PIE files and writes the components
into a new directory structure on the boot 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 _______________________
Configuration commands cannot be entered during the
installation process.
__________________________________________________________________
All install commands can only be issued from the admin EXEC mode; if
you decide to later remove the software, it must also be removed using this
mode.
The Added Packages New Directories

When a new package is added typically three directories are created as
shown on the adjacent page.
Platform dependent directory.
Platform independent directory.
The directory for the bundle itself. This is a shell containing the meta-
data that groups the sub-packages together making them appear as a
single entity to the user.

Module 5 Software Installation
Adding Packages to the Router

:router(admin)# install add tftp://172.21.116.8/4.0.1/asr9k-mpls-p.pie-4.0.1

Install operation 533 '(admin) install add /tftp://172.21.116.8/4.0.1/asr9k-mpls-
p.pie-4.0.1' started by user 'cisco' via CLI
at 15:36:31 UTC Tue Jul 05 2011.
RP/0/RSP0/CPU0:PE2(admin)#Info: The following package is now available to be activated:
Info:
Info: disk0:asr9k-mpls-p-4.0.1
Info:
Info: The package can be activated across the entire router.
Info:
install add command

!From TFTP server
!From local media (diskn:, harddisk:, compactflash:)
ASR9KE - Adding Packages to the Router
(Cont.)
RP/0/RSP0/CPU0:PE2# dir disk0:

Directory of disk0:
6308 drwx 4096 Tue Jul 5 15:36:57 2011 instdb
4435892 drwx 4096 Tue Jul 5 10:36:11 2011 asr9k-scfclient-4.0.1
4435896 drwx 4096 Tue Jul 5 10:36:12 2011 asr9k-diags-supp-4.0.1
4435905 drwx 4096 Tue Jul 5 10:36:46 2011 asr9k-fwding-4.0.1
5368657 drwx 4096 Tue Jul 5 10:37:04 2011 asr9k-base-4.0.1
6022461 drwx 4096 Tue Jul 5 10:37:22 2011 asr9k-os-mbi-4.0.1
6022465 drwx 4096 Tue Jul 5 10:37:24 2011 iosxr-diags-4.0.1
6022481 drwx 4096 Tue Jul 5 10:37:38 2011 iosxr-routing-4.0.1
6457671 drwx 4096 Tue Jul 5 10:39:01 2011 iosxr-fwding-4.0.1 PI directory
7318840 drwx 4096 Tue Jul 5 10:40:36 2011 iosxr-infra-4.0.1
7919555 drwx 4096 Tue Jul 5 10:40:52 2011 asr9k-mini-p-4.0.1 PD directory
7919587 drwx 4096 Tue Jul 5 15:36:56 2011 iosxr-mpls-4.0.1
7919716 drwx 4096 Tue Jul 5 15:36:57 2011 asr9k-mpls-p-4.0.1
After install add
Directory structure created containing package components
! Platform dependent (PD) sub-package is inside the mcast bundle
! Platform independent (PI) sub-package is inside the mcast bundle
! The bundle is a shell containing meta-data that groups the sub-
packages together, so they appear as a single entity to the user

Activating Packages
The add function previously discussed makes the software package
available to be activated on the router.
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.
install activate test Option
To test the affect of the install activate 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.

Activating Packages
ASR9KE - Activating Packages
:router(admin)# install activate disk0:asr9k-mpls-p-4.0.1

Tue Jul 5 15:42:44.486 UTC
Install operation 534 '(admin) install activate disk0:asr9k-mpls-p-4.0.1'
started by user 'cisco' via CLI at 15:42:44 UTC Tue
Jul 05 2011.
Info: Install Method: Parallel Process Restart
RP/0/RSP0/CPU0:PE2(admin)#
RP/0/RSP0/CPU0:PE2#Info: The changes made to software configurations will
not be persistent across system reloads. Use the command '(admin)
Info: install commit' to make changes persistent.
Info: Please verify that the system is consistent following the software
change using the following commands:
Info: show system verify
Info: install verify packages
install activate command


Installing and Activating Packages

You can accomplish the installation (adding and activating) of software,
such as a PIE or SMU, in one step. The package is verified, unpacked, and
the directory is added to the boot device. Then the package is activated,
just as in the separate steps illustrated previously.
In this slide, the Manageability package is installed and activated in one
step.

Installing and Activating Packages

ASR9KE - Installing and Activating Packages
:router(admin)# install add tftp://172.21.116.8/4.0.1/asr9k-mcast-p.pie-4.0.1 activate

Install operation 535 '(admin) install add /tftp://172.21.116.8/4.0.1/asr9k-mcast-p.pie-4.0.1
activate' started by user
'cisco' via CLI at 15:46:33 UTC Tue Jul 05 2011.
Part 1 of 2 (add software): Started
Info: The following package is now available to be activated:
Info:
Info: disk0:asr9k-mcast-p-4.0.1
Info:
Info: The package can be activated across the entire router.
Info:
Part 1 of 2 (add software): Completed successfully
Part 2 of 2 (activate software): Started
Info: The changes made to software configurations will not be persistent across system
reloads. Use the command '(admin)
Info: Please verify that the system is consistent following the software change using the
following commands:
Part 2 of 2 (activate software): Completed successfully
Part 1 of 2 (add software): Completed successfully
Part 2 of 2 (activate software): Completed successfully

Displaying New Active Software

The installation process does not ensure that packages are available
should the router reload. Another step, discussed later, is required.
However, the software packages are available for use and testing.
The show install active command displays the active software set from
all nodes, including all SDRs that may be configured on the router. You
can specify a node with the location keyword and node-id argument, and
the command displays the active software set from that specific node.

Displaying New Active Software

:router(admin)# sh install active

Tue Jul 5 15:52:38.463 UTC

Boot Device: disk0:
Boot Image: /disk0/asr9k-os-mbi-4.0.1/mbiasr9k-rp.vm Owner
Active Packages:
disk0:asr9k-mini-p-4.0.1 SDR
disk0:asr9k-mpls-p-4.0.1
disk0:asr9k-mcast-p-4.0.1

Boot Device: disk0:
Active Packages:

Boot Device: mem:
Active Packages:

Committing New Software

As previously noted, the add and activate functions do not make the
software package available across reloads; another step is required.
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 the install commit command,
the previously committed software set is used.
Although 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.


:router(admin)# install commit

Install operation 14 '(admin) install commit' started by user 'cisco' via CLI
at 14:31:30 UTC Thu Apr 14 2011.
\\ 100% complete: The operation can no longer be aborted (ctrl-c for options)
RP/0/RP0/CPU0:Apr 14 14:31:36.441 : instdir[216]:
%INSTALL-INSTMGR-4-ACTIVE_SOFTWARE_COMMITTED_INFO :
The currently active software is now the same as the committed software.
Install operation 14 completed successfully at 14:31:36 UTC Thu Apr 14 2011.
install commit command

!New software is activated across reloads

Deactivating Packages
It may be desirable for you to take a package out of the activated software
configuration.
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 then 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. Packages and SMUs can be deactivated based on card
location or by SDR.
____________________________ Note _________________________
When executed from the Admin EXEC mode, packages are deactivated
router-wide.
__________________________________________________________________
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 and is very useful
when multiple non-owner SDRs are configured.

Deactivating Packages
:router(admin)# install deactivate disk0:asr9k-mpls-p-4.0.1

Tue Jul 5 15:55:41.254 UTC
Install operation 537 '(admin) install deactivate disk0:asr9k-mpls-p-4.0.1' started by user
'cisco' via CLI at 15:55:41 UTC
Tue Jul 05 2011.
RP/0/RSP0/CPU0:PE2(admin)#Info: The changes made to software configurations will not be
persistent across system reloads. Use the command '(admin)
Info: Please verify that the system is consistent following the software change using
the following commands:
Package features no longer available on any SDR

Package still installed; can be reactivated or removed (after
committing deactivation)
Configuration commands removed from affected SDR

!Notification received at SDR console
Apr 14 18:19:25.851 : insthelper[60]: %MGBL-CONFIG-6-PKG : Some
incompatible configuration was removed from the running configuration
during this software activation/ deactivation operation and saved in file
'20080316034623.cfg'. To address the incompatibility issue with the
removed configuration use the 'load configuration removed
20080316034623.cfg' and 'commit' commands.

Removing Packages
When a new release has been installed, the old release can be removed. So
that the installation database integrity is maintained, deleting the
directories from the boot disk must only be done using the install
commands.
install remove Command
The install remove name command must be executed from the same
mode or location from which the package was added. This command
removes an inactive package from the location in which it was previously
installed. If a package name is not specified, this command removes all
inactive packages. The command completely removes the packages and all
associated configurations from an SDR.
____________________________ Note _________________________
This command must be preceded by the install deactivate and install
commit commands and executed from the same mode or location from
which it was originally installed.
__________________________________________________________________
install remove test Option
Use the test keyword to verify the effects of the package removal operation
and determine whether the operation can be completed.

Removing Packages
ASR9KE - Removing Packages
Remove any inactive packages
:router(admin)# install remove inactive
Install operation 541 '(admin) install remove inactive' started by user
'cisco' via CLI at 16:02:23 UTC Tue
Jul 05 2011.
Info: This operation will remove the following packages:
Info: disk0:iosxr-mpls-4.0.1 One package with two directory
Info: disk0:asr9k-mpls-p-4.0.1 structures being removed
Info: After this install remove the following install rollback points
will no longer be reachable, as the required
Info: packages will not be present:
Info: 534, 535
Proceed with removing these packages? [confirm]
RP/0/RSP0/CPU0:PE2(admin)#Install operation 541 completed successfully at
16:02:30 UTC Tue Jul 05 2011.
install remove command

! Packages removed from all SDRs
Deactivate package(s) first on all SDRs
! install commit required
test keyword option

Software Installation Directories

As previously mentioned, when software packages are installed, part of the
process is to create and populate directories on disk0:. When new software
packages or upgrades to existing software packages are added new
directories are added. This may present a space problem if old software is
not cleaned up. The install remove command is designed to recover the
space when old software packages are no longer needed.
The slides show the directory layout before and after issuing an install
remove command. Although the slides show the directories for the owner
SDR, the directories would be removed from any other SDR disk0:, as well.

Software Installation Directories

Before install remove
:router(admin)# dir disk0:
Directory of disk0:

6457671 drwx 4096 Tue Jul 5 10:39:01 2011 iosxr-fwding-4.0.1
7919555 drwx 4096 Tue Jul 5 10:40:52 2011 asr9k-mini-p-4.0.1
7919587 drwx 4096 Tue Jul 5 15:36:56 2011 iosxr-mpls-4.0.1 MPLS package
7919716 drwx 4096 Tue Jul 5 15:36:57 2011 asr9k-mpls-p-4.0.1
ASR9KE - Software Installation Directories

(Cont.)
After install remove
:router(admin)# dir disk0:
Directory of disk0:

6457671 drwx 4096 Tue Jul 5 10:39:01 2011 iosxr-fwding-4.0.1
7919555 drwx 4096 Tue Jul 5 10:40:52 2011 asr9k-mini-p-4.0.1 MPLS package
removed

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 installation log is limited to fifty (50) entries.
Displaying Installation Log Information

You can determine the available rollback information by using these
commands:
show install logLists what occurred at each install point
show install committedLists all installed and committed software

show install rollback ?Lists only the available installation
transaction points (IDs), committed or noncommitted, to which you can
roll back. Use these installation points to compare what software was
installed
In the slides, you can see a variety of activity that has been recorded,
including separate package adds and activates, along with a single-step
add and activate. In the second slide, you can see the installation activity
that has taken place on specific SDRs.

Module 5 Software Installation Review
Displaying Installation Log Information

ASR9KE - For Print
:router(admin)# show install log 56 1
Install operation 56 started by user 'cisco' via CLI at 18:01 UTC Thu Apr 14 2011
(admin) install add /tftp://172.21.116.8/asr9k-mcast-p-4.0.1
Install operation 56 completed successfully at 18:02:13 UTC Thu Apr 14 2011

(admin) install activate disk0:asr9k-mcast-p-4.0.1

(admin) install deactivate disk0:asr9k-mgbl-p-4.0.1
Log entry examples of

1. Add operation of 1 package
2. Activate operation of 1 package on non-owner SDR
3. Deactivate operation of 1 package

Displaying Installation Log Entries

Using the show install log command, you can see all 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
the show install log commands with the available detail and verbose
keywords. The output includes details on what files have been changed and
what processes were impacted.

ASR9KE
Displaying - Displaying
Installation Log Entries Installation Log Entries
(Cont.)
:router(admin)# show install log 450 verbose
Tue Jul 5 16:08:44.716 UTC
Install operation 450 started by user 'cisco' via CLI at 18:36:20 UTC Tue Mar 15
2011.
(admin) install remove inactive
Install operation 450 completed successfully at 18:36:40 UTC Tue Mar 15 2011.
Install logs:
Install operation 450 '(admin) install remove inactive' started by user
'cisco' via CLI at 18:36:20 UTC Tue Mar 15 2011.
Info: This operation will remove the following packages:
Info: disk0:asr9k-mcast-3.9.1
Info: disk0:asr9k-mpls-3.9.1
Info: After this install remove the following install rollback points
will no longer be reachable, as the required
Info: packages will not be present:
Info: 416, 422, 427, 429, 441, 444
Proceed with removing these packages? [confirm]
User Response: 'y'
Install operation 450 completed successfully at 18:36:40 UTC Tue Mar 15
2011.

Displaying Active Software 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.
By specifying a device or SDR, you can see all the packages installed on
that device or SDR.

Displaying Active Software Details

:router(admin)# show install active detail

Boot Device: disk0:
Active Packages:
.
.
disk0:iosxr-routing-4.0.1 Owner SDR
disk0:iosxr-fwding-4.0.1 RP software Minimum boot image
disk0:iosxr-infra-4.0.1
disk0:asr9k-mcast-supp-4.0.1
disk0:iosxr-mcast-4.0.1

Boot Device: mem:
Active Packages:
disk0:asr9k-cpp-4.0.1
disk0:asr9k-scfclient-4.0.1
.
. Core
disk0:iosxr-diags-4.0.1 bundle Owner SDR
disk0:iosxr-routing-4.0.1 Line card software
disk0:iosxr-fwding-4.0.1
disk0:iosxr-infra-4.0.1
disk0:asr9k-mcast-supp-4.0.1
disk0:iosxr-mcast-4.0.1

Installation Recovery
You can recover from a software installation by using a rollback process
that returns the active software to a previous version.
Displaying Rollback Options

The show install rollback ? command indicates what installation entries
can be rolled back.
____________________________ Note _________________________
Use the show install log <n> command (explained previously) to show
what installation action took place in the specific entry.
__________________________________________________________________

Module 5 Installation Recovery
Displaying Rollback Options
:router(admin)# show install rollback ?

0 ID of the rollback point to show package information for
Determine the available rollback points

Determining Rollback Options

The show install rollback <n> command displays the status of the
installed software set associated with the installation point.
The slides show the status of the software set for installation point 6. You
can determine from the display that the MPLS and multicast packages are
installed on the owner and non-owner SDRs
Compare this information with the display of the earlier rollback point on
the following pages.

Determining Rollback Options

ASR9KE For Print!!
:router(admin)# show install rollback 535
ID: 535, Label:

Timestamp: 15:47:42 UTC Tue Jul 05 2011

Boot Device: disk0:
Rollback Packages:
disk0:asr9k-mcast-p-4.0.1 Mcast installed
[... RSP1 output omitted]
Boot Device: mem:
Rollback Packages:
--More--
Router software status before rollback

Owner SDR

Determining Rollback Options (Cont.)

These slides show the status of the software set for an earlier installation
point. You can determine from the display that the Mcast package is
removed from the owner and non-owner SDRs. This is the status of the
router if we roll back the installation to this point.
Compare this information with the display of the rollback point on the
previous pages.

Determining Rollback Options (Cont.)

ASR9KE For Print!!
:router(admin)# show install rollback 534
ID: 534, Label:

Timestamp: 15:43:14 UTC Tue Jul 05 2011

Boot Device: disk0: Mcast not installed
Rollback Packages:
[... RSP1 output omitted]
Boot Device: mem:
Rollback Packages:
--More--
Router software status if rolled back to install point 534

Owner SDR

Installation Rollback
You can easily roll back software changes with Cisco IOS XR software.
install rollback Command
The install rollback command provides a method of returning to a

previously active installation point. You can return to either the last
committed package or to a noncommitted package.
____________________________ Note _________________________
The install rollback command without the reload option only rolls
back to the last two installation points. To roll back beyond two
installation points requires the reload option. This is disruptive to the
running system.
__________________________________________________________________
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.
The slide shows a test example of rolling back to installation point 38,
which would remove the MPLS package from the owner SDR and non-
owner SDR, PE33. Because this is a test, the actual package is not
removed. However, testing the rollback shows that there is an impact to
the configuration. This should be investigated by looking at the removed
configuration file.

Installation Rollback
:router(admin)# install rollback 38 test

Install operation 67 '(admin) install rollback to 38 test' started by user
'cisco' via CLI at 12:51:32 UTC Fri Apr 15 2011.
Warning: No changes will occur due to 'test' option being specified.
Warning: SDR Owner: No incompatible configuration will be removed due to the
Warning: 'test' option
Warning: SDR SDR1: No incompatible configuration will be removed due to the 'test' option
Info: SDR SDR1: Detected incompatibility between the activated software and
Info: router running configuration.
Info: SDR SDR1: Removing the incompatible configuration from the running configuration
Info: SDR SDR1: Use the "show configuration removed 20110415125159.cfg"
Info: command to view the removed config.
Rollback to the installed software set at that specific install

point
MPLS packages removed
Test the outcome first
Info: SDR Owner: Use the "show configuration removed 20110415125159.cfg"

Info: command to view the removed config.
Info: NOTE: You must address the incompatibility issues with the
Info: removed configuration above and re-apply it to the running
Info: configuration as required. To address these issues enter
Info: configuration mode and use the
Info: "load configuration removed 20110415125159.cfg" and "commit commands.
Warning: SDR Owner: Rolling back any configuration changes made as part of the
Warning: install operation.
Info: SDR Owner: No configuration operations need to be rolled back.
Info: SDR Owner: No configuration operations need to be rolled back.
Warning: SDR SDR1: Rolling back any configuration changes made as part of the
Warning: install operation.
Info: SDR SDR1: No configuration operations need to be rolled back.
Info: The changes made to software configurations will not be persistent
Info: across system reloads. Use the command '(admin) install commit' to
Info: make changes persistent.
Info: Please verify that the system is consistent following the software
Info: change using the following commands:
Install operation 67 completed successfully at 12:52:05 UTC Fri Apr 15 2011.
Changing installed software makes some CLI commands invalid

! Commands are removed from active configuration
! Stored for possible future use at /config/removed_cfg
Reviewing Rollback Impact

CLI commands removed from the running configuration when a software
package is removed are saved in a removed configuration file. You can
review those CLI commands by using the show configuration removed
command from EXEC mode.
In this case, MPLS LDP in addition to its sub-commands are removed
when the MPLS software package is removed. This is shown when the
removed configuration file is displayed.

Reviewing Rollback Impact
:router(admin)# exit
:router# show config removed 20110415125159.cfg
!! IOS XR Configuration 4.0.1
mpls ldp
router-id 10.3.3.3
nsr
graceful-restart
log
graceful-restart
session-protection
nsr
!
!
end
Display the removed configuration commands

!MPLS commands removed
show config removed available in EXEC mode
!Not Admin EXEC mode

Installation Command Review

With secure domain routers, install commands can be executed in a
variety of ways.
Install Command Summary
The slide provides a summary of the install commands that are available,
where they can be executed, and what they do.

Module 5 Installation Command Review
Install Command Summary
Command Summary
install add Adds package to disk0: of all SDRs
install activate Activates packages on selected SDRs, selected locations, or all locations
install deactivate Deactivates packages on selected SDRs, selected locations, or all

locations
install remove Removes inactive packages from all SDRs; package must be inactive
install commit Applies to all locations
install rollback Returns software installation to status of specified installation point
show install act, inact, Executed in Admin EXEC and any SDR; in Admin EXEC shows all SDRs;
commit in specific SDR shows only packages in that SDR
show install pie-info Shows package information from the source location of the package to be
installed
show install log Shows installation log entries; keywords provide detail, if necessary
show install rollback Shows rollback points and specific information about rollback
show system verify Executed on individual SDR only

Summary
Cisco IOS XR Installation
Describe the Cisco IOS XR packaging model

Summarize 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
Articulate the process of optional software installation and removal

Module 6
Cisco IOS XR Operations
Overview
Description
This module introduces you to other operational Cisco IOS XR features,
including making, checking, and verifying changes; rolling back
configurations; and troubleshooting configurations.
Objectives
Explain configuration processes
List and describe other configuration considerations and best practices

Explain the configuration rollback process
Describe log commands
Describe system backup and commands
Demonstrate process commands

Cisco IOS XR Operations Module 6
Operations
Router operations encompass a variety of configurations and best practices
that are locally defined by the customer.
Other Configuration Considerations and Best Practices

Consider additional configuration steps before putting the router into
service.
Interface Preconfiguration and Online Insertion and Removal
Preconfiguration is the process of configuring interfaces prior to installing

them in a system. The interfaces are not verified or actually applied until
the interface is inserted. Likewise, if an interface card is removed for
online insertion and removal (OIR), the configuration for that interface
reverts to preconfigured.
Logs
System messages generated by Cisco IOS XR software can be logged in a

variety of locations, based on the severity level of the messages.
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 can be optionally
enabled. You can:
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

Module 6 Operations
Other Configuration Considerations and Best Practices
Interface preconfiguration and OIR

Logs
Domain name and domain name server
assignment
! Access efficiency
HTTP and XML services
! XML for CORBA management and configuration
access

Preconfiguration
Preconfiguration lets you configure certain interface types 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 line
card (LC), is inserted and the interfaces are created, the precreated
configuration information is verified and, if successful, immediately is
applied to the routers running configuration.
____________________________ Note _________________________
Only physical interfaces can be preconfigured.
Specifying an interface name that already exists and is configured (or
an abbreviated name like e0/3/0/0) is not permitted.
__________________________________________________________________
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 the drivers have been installed, such
as Ethernet or Packet over SONET/SDH (POS).
Online Insertion and Removal
As a part of high availability, line cards and PLIMs can be removed

without impacting the forwarding of data on other cards. When a device is
removed, the configuration for that device is moved to a preconfiguration
status. If the same type of device is re-inserted, the configuration returns
to active status. It is the responsibility of operations to verify that the card
being installed is the same as called for in the configuration.

Module 6 Operations
Preconfiguration
Prior to
installing line
card, its
configuration
can be entered
Configure resources not yet
present
Reduce down time
Improve operational tasks such
as OIR
CLI
Prior to the LC being inserted

Select the interface
Configure the timing (SONET controller)
Configure the framing
Configure the IP address
:router# config
:router(config)# controller preconfigure sonet 0/4/0/0 clock source line
:router(config)# interface preconfigure POS 0/4/1/0
:router(config-if-pre)# ipv4 address 1.1.1.1 255.255.255.0
:router(config-if-pre)# encapsulation ppp

Logging
Cisco IOS XR software provides logging services for monitoring and
troubleshooting the router. The type of logging information and the
destination of the log messages can be configured. For example, you can
direct information messages to the system console and 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.
The slide shows the currently available logging possibilities.
The sample messages show the information that can be used to determine
what action, if necessary, to take; how to correlate message types; and
which messages to send to which collector.
The message breakdown is:
CategoryMessage category code (see Cisco IOS XR System Error
Messages documentation for further information)
GroupMessage group code; hardware device, protocol, or software
module
SeverityMessage severity code; numeric value as follows:
Message Level Description

0 Emergency; system unusable
1 Alert; immediate action required
2 Critical; condition critical
3 Error; error condition
4 Warning; warning condition
5 Notification; normal but significant
6 Informational; informational message
7 Debugging; provided for debug purposes
MnemonicMessage unique identifier
For additional information, refer to Cisco Systems, Inc. documentation.

Module 6 Operations
Logging
Logging (for Print)
:router(config)# logging ?
A.B.C.D or X:X::X IP v4/v6 address of the logging host
WORD Name of the logging host
archive logging to a persistent device(disk/harddisk)
buffered Set buffered logging parameters
console Set console logging
correlator Configure properties of the event correlator
disable Disable console logging
events Configure event monitoring parameters
facility Modify message logging facilities
history Set history logging
hostnameprefix Hostname prefix to add on msgs to servers
localfilesize Set size of the local log file
monitor Set monitor logging
source-interface Specify interface for source address in logging transactions
suppress Configure properties for the event supression
suppress Suppress logging behaviour
trap Set trap logging
LC/0/3/CPU0:Mar 23 08:04:31.644 : ifmgr[151]: %PKT_INFRA-LINEPROTO-

5-UPDOWN : Line protocol on Interface POS0/3/0/7, changed state to
Down
LC/0/3/CPU0:Mar 23 08:04:39.090 : ifmgr[151]: %PKT_INFRA-LINEPROTO-

5-UPDOWN : Line protocol on Interface POS0/3/0/7, changed state to
Up
Sample of messages
%Category-Group-Severity-Mnemonic: Message
text
Severity categories

Configuration Operations
There are commands you can use to manage your configuration sessions.
Locking and Unlocking the Running Configuration

You can control critical changes to the router by using the lock and unlock
feature of 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
CLI
Config
database
Running
config
:routername# configure exclusive

:routername(config)# hostname router
:routername(config)# commit
:router(config)#

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

Clearing Target Configuration Changes
:router# configure
:router(config-if)# pos crc 32
:router(config-if)# show config

ipv4 address 192.168.101.1 255.255.255.0
pos
crc 32
!
end
:router(config)# clear
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 save config command followed by the pathname and
filename.
You may now exit configuration mode without saving your changes, or
clear this configuration and start another one.

Saving a Target Configuration
:router(config)# username user1

:router(config-un)# password user1pw
:router(config-un)# group root-system
:router(config-un)# save config disk0:user1
[OK]
:router(config-un)#
Save the target configuration to a file

! Save on disk0: or disk1:
! Specify pathname and filename

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.
A loaded configuration merges with any commands already entered in the
existing target configuration.

Loading a Target Configuration

end
:router(config)# load disk0:user1

Loading.
57 bytes parsed in 1 sec (56)bytes/sec

username user1
password 7 110C1D
group root-system
!
end
File previously saved
Loaded file becomes the target configuration
! Merges with existing target configuration commands


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.

:router# configure
:router(config-if)# pos crc 32
:router(config-if)# abort
:router#
Ends the configuration session immediately

! No warning before deletion of target changes

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 that a problem has occurred.
The failed configuration commands can be viewed by entering the show
config failed command.
Another type of commit that can be used is called best effort. This type of
commit implements the parts of the configuration that are semantically
correct and does 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

Failed Configuration Commands (for Print)
:router# config
:router(config)# taskgroup bgp
:router(config-tg)# hostname routerxyz
% Failed to commit one or more configuration items during an
Pseudo-atomic operation. All changes made have been reverted.
Please issue 'show configuration failed' from this session to view
the errors
:router(config)# show config failed

!! SEMANTIC ERRORS: This configuration was rejected by the system
!! due to semantic errors. The individual errors with each failed
!! Cofiguration command can be found below.
taskgroup bgp
!!% LOCALD detected the fatal condition Usergroup/Taskgroup
names cannot be taskid names
:router(config)#
Configuration commit entry fails

!View causes of failures
:router# config
:router(config)# taskgroup bgp
:router(config-tg)# hostname routerxyz
:router(config)# commit best-effort
% Failed to commit one or more configuration items.

Please use 'show configuration failed' to view the errors
Partial
:routerxyz(config)# show config failed configuration!
!! CONFIGURATION FAILED DUE TO SEMANTIC ERRORS
taskgroup bgp
!!% Usergroup/Taskgroup names cannot be taskid names
!
:routerxyz(config)#
Configuration commit entry fails

! Part of configuration is implemented
! Some parts fail

Displaying Configuration Changes

You can see configuration changes at different stagesas part of the
running configuration, as a failed configuration, or removed when a
software package is removed. You can see when changes were committed
and what those committed changes actually were. You can manage
configuration sessions, too.
The show config command has these keywords that provide additional
information:
commitShow what was committed in a particular commit

failedCommands that failed in a commit
historyDisplay the history of configuration events (up to 1500)
inconsistencyConfiguration inconsistencies
lockConfiguration lock
persistentShows the persistent configuration
removedParts of the running configuration that were taken out
when a software package was deactivated. Software packages provide
commands to the command-line interface (CLI) parser as part of the
installation. These commands are removed during deactivation, so the
commands are removed from the running configuration, also
rollbackWhen changes are committed to the running configuration
of the router, a point is established to provide a method of recovering
from those changes, should it be required
running-configShows the same information as the command show
running-config; that is, the configuration currently controlling the
resources of the router
sessionsManage and deactivate configuration sessions

Displaying Configuration Changes
:router# show config ?

commit Show commit information
failed Contents of failed configuration
history Display history of configuration events
(up to 1500 events)
inconsistency Configuration inconsistencies
lock Configuration lock
persistent Show persistent configuration
removed Display configuration removed during install
operations
rollback Show rollback information
running-config Current operating configuration
sessions Users with active configuration sessions

Commit Keywords
The commit command offers these optional keywords:
replaceLets you replace an entire running configuration with the
target configuration
commentLets you add a comment that is displayed when looking at
committed change information
labelLets you label a change, when committing it; the label is
displayed when viewing committed change information
confirmedLets you back out a configuration automatically if the
change results in instability, or for any other good reason. A value
between 30 and 300 seconds is required, and a second commit must be
entered to make the change persistent

Other Commit Keywords
Replace
! Replace entire running configuration with target configuration
commit replace
Comment line
! Add text information to the change
! Shows up when looking at rollback details
commit comment comment
Label line
! Assigns a name to the change
! Shows up when looking at the change
commit label label
Confirmed seconds
! Minimum of 30 seconds and a maximum of 300 seconds
! Requires second commit or change is backed out
commit confirmed 30-300

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.
If both keywords are used, label must appear first and comment last,
because all characters following the comment keyword are considered
comments.

Commit Comments and Labels

Commit Comments and Labels (for Print)
:router(config)# hostname P4abc

:router(config)# commit comment rename from P4 label P4abc
:P4abc# show config commit list 1 detail
1) CommitId: 1000000133 Label: NONE

UserId: cisco Line: vty0
Client: CLI Time: 14:07:35 UTC Wed Mar 23 2011
Comment: rename from P4 label P4abc
:P4abc# show config commit list

SNo. Label/ID User Line Client Time Stamp
~~~~ ~~~~~~~~ ~~~~ ~~~~ ~~~~~~ ~~~~~~~~~~
1 1000000133 cisco vty0 CLI 14:07:35 UTC Wed Mar 23 2011
Commit Comments and Labels (Cont.)
:P4abc(config)# hostname P4hjk

:P4abc(config)# commit label renameP4hjk
:P4hjk# show config commit list 1 detail
1) CommitId: 1000000134 Label: renameP4hjk

Client: CLI Time: 14:19:50 UTC Wed Mar 23 2011
Comment: NONE
:router# show config commit list
~~~~ ~~~~~~~~ ~~~~ ~~~~ ~~~~~~ ~~~~~~~~~~
1 renameP4rhj cisco vty0 CLI 14:19:50 UTC Wed Mar 23 2011
:P4hjk(config)# hostname P4
:routerhjk(config)# commit label renameP4 comment rename back to P4
:P4# show config commit list 1 detail
1) CommitId: 1000000135 Label: renameP4

Client: CLI Time: 14:20:48 UTC Wed May 25 2011
Comment: rename back to P4
:P4# show config commit list
~~~~ ~~~~~~~~ ~~~~ ~~~~ ~~~~~~ ~~~~~~~~~~
1 renameP4 cisco vty0 CLI 14:20:48 UTC Wed Mar 23 2011

Configuration Sessions
Configuration sessions can be managed, if necessary. This management
can be helpful if an 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.
When a session is cleared the following message appears on that session:
% Failed to commit .. As an error (Unknown) encountered during
commit operation. Changes may not have been committed:
'CfgMgr' detected the 'fatal' condition 'The Configuration

Namespace is locked by another agent.'

Configuration Sessions
Configuration Sessions (for Print)
:router(config)# do show config sessions

Session Line User Date Lock
00000201-037eb0cf-00000000 vty1 cisco Thu Mar 10 06:06:01 2011
00000201-037f00d4-00000000 vty3 doug Thu Mar 10 06:06:50 2011 *
00000201-037f10d5-00000000 vty2 cisco Thu Mar 10 06:07:10 2011
:router# show config sessions

Session Line User Date Lock
00000201-037f00d4-00000000 vty3 doug Thu Mar 10 06:06:50 2011
00000201-037f10d5-00000000 vty2 cisco Thu Mar 10 06:07:10 2011
Manage configuration sessions

!View other sessions
!Doug session is exclusive
:router# clear config session 00000201-037eb0cf-00000000

session ID '00000201-037eb0cf-00000000' terminated
:router(config)#This configuration session was terminated by user

'cisco' from line 'vty0'
:router#
Manage configuration sessions

! Delete

Configuration Rollback and Recovery

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 any other reason).

Module 6 Configuration Rollback and Recovery
Configuration Checkpoint and Rollback
Config database
Running config
Target config commit
Config log
Each commit generates record CommitID# 100
CommitID# 099
with CommitID or label CommitID# 098
Each CommitID is a rollback point

Commit database stores up to 100 CommitID# 001
rollback points

Displaying 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 the most recent 100. This list is displayed
by using the show config commit list command. The list contains:
SNoSequence number of the change list

Label/IDIdentifier assigned to this change
UserLogged-on user who committed the changes
LineMethod used to connect to the router

ClientTool used to make the changes
Time StampTime and date of the change
The configuration database actually contains a historical record of up to
1000 committed changes made on the router. These records contain the
minimum information described above.

Displaying Stored Configuration Commits
:router# show config commit list

~~~~ ~~~~~~~~ ~~~~ ~~~~ ~~~~~~ ~~~~~~~~~~
1 1000000167 cisco con0_RP1_C CLI 05:40:54 PST Wed Mar 02 2011
2 1000000166 cisco vty0 CLI 10:22:27 PST Mon Feb 28 2011
3 1000000165 cisco vty0 CLI 10:13:15 PST Mon Feb 28 2011
4 1000000164 cisco con0_RP0_C CLI 13:24:39 PST Thu Feb 24 2011
5 doug cisco con0_RP0_C CLI 13:17:51 PST Thu Feb 24 2011
Maximum of 100 actual changes are viewable

History of up to 1000 committed changes

Displaying Committed Changes

The actual committed configuration commands made at each commit point
are available from the list 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.
Two variations of the command 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:
:router# 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

Displaying Committed Changes
:router# show config commit changes doug

username doug
password 7 110D161010 Same
!
end
:router# show config commit changes 1000000163
username doug
password 7 110D161010
!
end
:router# show config commit changes 1000000167
username doug
group root-system
group cisco-support Added
!
end
Display specific committed changes
:router# show config commit changes last 2

username doug
group root-system
group cisco-support Previous change
!
xml agent corba
http server Last change
end
:router# show config commit changes last 3

router static
address-family ipv4 unicast Prior change
0.0.0.0/0 172.21.116.1
!
!
username doug
group root-system
Previous change
group cisco-support
!
xml agent corba Last change
http server
end

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.

Displaying Committed Changes (Cont.)
:router# show config commit changes since doug

router static
address-family ipv4 unicast Change # 166
0.0.0.0/0 172.21.116.1
!
!
username doug
password 7 110D161010 Change # 163/doug
group root-system
group cisco-support Change # 167
!
username jeff
password 7 1213001114 Change # 164
!
xml agent corba
http server Change # 168
end
Display changes since specified CommitID or label

! Ordered for router configuration
! Not in change order

Displaying Rollback Information

The show config rollback changes command displays committed
changes and what the commands would be if you were to roll these changes
back. In most cases, the display would show the reversal of the change
referenced.
The command uses the following keywords:
lastFollowed by a number value

toFollowed by the Label/CommitID
Each of these keywords is inclusive.

Displaying Rollback Information
:router# show config rollback changes last 1

username doug
no group root-system
no group cisco-support
!
end
Building configuration... Previous
no router static changes
username doug
no group root-system would be
no group cisco-support reversed
!
end
config-register 0x0
username doug
!
end
Display rollback changes (inclusive)
:router# show config rollback changes to doug

no router static
no username doug
username doug
no password
!
no username jeff
username jeff
no password
!
end
Display inclusive changes back to a certain commit

change

Rolling Back Configurations

The rollback configuration command rolls back all configuration
changes up to, and including, the specified label or 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 automatically to the running configuration.

Rolling Back Configurations
:router# rollback configuration to 1000000169

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

Inclusive; undoes configurations up to and
including specified commitID or label
Commits automatically
:router# rollback configuration last 3

Loading Rollback Changes.
Loaded Rollback Changes in 1 sec
Committing.
Updating.
Configuration successfully rolled back 3 commits.
Roll back last (n) number of changes

Loading a Specific Configuration

You can load a specific committed configuration. In global configuration
mode, the load command is used to accomplish this task. Loading a
previously committed change allows 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.

Loading a Specific Configuration
:router(config)# load commit changes 1000000169

Loading.

no username user1
username user1
!
end
Enter configuration mode

Load a specific previously committed change
Recommit the change

Saving and Restoring Configuration Files

You can save the running configuration to a file location by using the copy
command.
You can copy a stored configuration file to the running configuration, also.
This operation replaces all or part of the existing running configuration,
depending on the contents of the stored file.
Here is an example:
File to be copied to running configuration:
RP/0/0/CPU0:P4# more disk0:ed
username ed
password 7 110C1D
group cisco-support
end
The running configuration user section prior to the copy:

RP/0/0/CPU0:P4# sho run username
username ed
password 7 110C1D
group root-system
The running configuration user section after the copy (root-system is

replaced by cisco-support):
RP/0/0/CPU0:P4# show run username
username ed
password 7 110C1D
group cisco-support

Saving and Restoring Configuration Files
Saving a running configuration file

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

:router# copy disk0:configtest1 running-config
Parsing.
Committing.............
Updating...
:router#

System Backup
The system backup feature is provided as a method of protecting the router
software using a backup disk. This feature is sometimes referred to as
Golden Disk.
Backup Requirements
Prior to performing the backup process, there are several prerequisites
that must be met:
The specified storage device must be local and installed

Cisco CRS-1 Series Router supported devices
! disk0:
! disk1:
Cisco XR12000 Series Router supported devices
! disk0:
! disk1:
! compactflash:
Cisco ASR9000 Series Router supported devices

! disk0:
! disk1:
____________________________ Note _________________________

The system backup command only backs up system created files and
directories. User created files and directories need to be manually
copied as needed.
__________________________________________________________________

Module 6 System Backup
System Backup
ASR9KE - System Backup
Process to create a backup disk

Prerequisites
!Specified device must be local and installed
!Cisco ASR 9000 Series Router supported devices
" disk0:
" disk1:

Backing up the Router

A system backup disk is created by backing up system files to a local
storage device. The first time a backup is created, the process formats the
selected device. The backups are either secure domain router (SDR)
specific when performed at EXEC mode, or router-wide when performed in
Admin mode.
Prior to creating a backup disk of the Cisco IOS XR software and the
configurations, you should determine which device has been used as the
boot device by looking at the information provided by these commands:
show version
show install active
show install committed

If you have previously performed a system backup, then you should verify
the status of that backup device by issuing show system backup
command.

Module 6 System Backup
Backing up the Router
Verify previous backup status

:router(admin)# show system backup disk1:
System Backup information for node0_RP0_CPU0 on disk1:
=======================================================
Last Backup Successful
Backup started at Mon Feb 21 12:52:00 2011
ended at Mon Feb 21 13:50:00 2011
Verify started at Mon Feb 21 13:60:00 2011
ended at Mon Feb 21 13:62:00 2011
BOOT_DEV_SEQ_CONF=
BOOT_DEV_SEQ_OPER=
Perform the backup

:router(admin)# system backup disk1: asynchronous
Info: node0_RP0_CPU0: cleaning target device
Info: node0_RP0_CPU0: copying admin configuration
Info: node0_RP0_CPU0: copying SDR configuration
Info: node0_RP0_CPU0: copying installed software Format required first time
Info: node0_RP0_CPU0: backup complete.
Info: node0_RP0_CPU0: verifying admin configuration
Info: node0_RP0_CPU0: verifying SDR configuration
Info: node0_RP0_CPU0: verifying installed software

Process Management
Overview
Cisco IOS XR software is a distributed operating system as opposed to a
monolithic type of operating system. As part of the design, many individual
processes 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 of
how many times during a predetermined period of time a process may stop
and restart. You can manage those processes that do not have pre-set
limitations.
You can use show commands and process commands to manage the
processes.
Displaying 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 6 Process Management
Displaying Process Information
:router# show processes ?

<0-4294967295> job id
WORD Name of the executable
aborts Show process aborts
all Show process data for all processes
blocked Show detail for reply/send/mutex blocked processes.
boot Show process boot info
boot-stalled Show process boot-up blocked
cpu Show CPU use per process
distribution Show distribution of processes
dynamic Show process data for dynamically created processes
failover Show process failover info
family Show process family information.
files Show file and channel use per process
location location to display
log Show process log
mandatory Show process data for mandatory processes
memory Show memory use per process
pidin Show processes using QNX pidin command
searchpath Show the search path
signal Show signal use for processes.
startup Show process data for processes created at startup
threadname 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:
RespawnRestart the process, if a problem occurs with it
Respawn countNumber of times this process has restarted

Max. spawns per minuteWhen the maximum number of spawns is
reached, the process does not restart automatically
Last startedWhen the last respawn took place. This could be the
result of an RP switchover or router reboot
Process stateState of the process when display was taken

Displaying Process Information (Cont.)

ASR9KE - Displaying Process Information (Cont.)
:router# show process ospf

Job Id: 1009
PID: 270607
Executable path: /disk0/iosxr-routing-4.0.1/bin/ospf
Instance #: 1
Version ID: 00.00.0000
Respawn: ON
Respawn count: 1
Max. spawns per minute: 12
Last started: Tue Jul 5 10:48:24 2011
Process state: Run
Package state: Normal
Started on config: cfg/gl/ipv4-ospf/proc/lab/ord_z/config
core: MAINMEM
Max. core: 0
Placement: Placeable
startup_path: /pkg/startup/ospf.startup
Ready: 1.852s
Available: 1.858s
Process cpu time: 0.653 user, 0.261 kernel, 0.914 total
JID TID CPU Stack pri state TimeInState HR:MM:SS:MSEC NAME
1009 1 0 124K 10 Receive 0:00:00:0667 0:00:00:0304 ospf
1009 2 0 124K 10 Receive 0:01:19:0308 0:00:00:0297 ospf
1009 3 0 124K 10 Receive 0:00:03:0280 0:00:00:0077 ospf
1009 4 0 124K 10 Receive 0:21:19:0938 0:00:00:0016 ospf

Process Control
You can use several actions to manage processes. Process control is only
available to a user with root-system access and commands are available in
the administration plane.
The use of process commands should be used in consultation with
Cisco Systems, Inc. technical support.

Process Control
:router(admin)# process ?
0-4294967295> job id
WORD Name of the executable
crash crash a process
mandatory set mandatory settings
node set node reboot settings
restart restart a process
shutdown kill/stop a process
start start a process
Several choices for working with processes

Process Restartability
Due to its modular architecture, Cisco IOS XR software processes 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 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 when 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
Restarting of individual process does not affect

other processes
Normal Normal Normal

forwarding, forwarding, forwarding,
OSPF, BGP OSPF OSPF, BGP
Stop BGP Start BGP

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 that there is no other remedy for your particular problem.
The process commands are only available to a user with root-
system access and in the Admin plane.
__________________________________________________________________

Process Stop and Restart

ASR9KE - Process Stop (for Print)
:router(admin)# process shutdown ospf

Job Id: 1009
PID: 270607
Instance #: 1
Respawn: ON
Respawn count: 1
Process state: Killed (last exit due to SIGTERM)
Registered item(s): cfg/gl/ipv4-ospf/proc/.*/ord_z/
core: MAINMEM
Max. core: 0
Ready: 1.852s
Available: 1.858s
ASRKE - Process Restart

:router(admin)# process start ospf

Job Id: 1009
PID: 803088
Instance #: 1
Respawn: ON
Respawn count: 2
Process state: Run (last exit due to SIGTERM)
Started on config: cfg/gl/ipv4-ospf/proc/lab/ord_z/config
core: MAINMEM
Max. core: 0
Ready: 0.704s
Available: 0.716s
Process cpu time: 0.173 user, 0.036 kernel, 0.209 total
JID TID CPU Stack pri state TimeInState HR:MM:SS:MSEC NAME
1009 1 1 116K 10 Receive 0:00:00:0524 0:00:00:0167 ospf
1009 2 1 116K 10 Receive 0:00:01:0408 0:00:00:0024 ospf
1009 3 0 116K 10 Receive 0:00:01:0687 0:00:00:0000 ospf
1009 4 1 116K 10 Receive 0:00:06:0421 0:00:00:0002 ospf

Summary
Cisco IOS XR Operations
Explain configuration processes

List and describe other configuration considerations and best practices
Explain the configuration rollback process
Describe log commands
Describe system backup and commands
Demonstrate process commands

Module 7
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).
Objectives
List Cisco IOS XR security features
Summarize Cisco IOS XR security package features
Describe security database implementation
Describe task-based authorization
Describe predefined task groups and user groups
Describe usergroup and taskgroup configuration
Explain and implement site-defined group and user configuration
Describe user configuration
Explain control plane and management plane protection

Cisco IOS XR Security Module 7
Cisco Security Features

Layered Defense
The Cisco IOS XR software and the platforms that support it have several
layers of security. Each platform has application-specific integrated
circuits (ASICs) that can localize and minimize any affects of attacks on
the router. Next, the operating system and infrastructure is separated (as
discussed earlier) with the kernel and processes working independently.
The kernel provides memory protection for the processes to prevent issues
in one process from affecting others. And processes are restartable,
allowing for them to be shut down, thus preventing any potential conflicts.
Further, as previously discussed, each of the planes (control, management,
and data) is kept separate for additional defense.
Authentication for Protocol Signaling

The MD5 message-digest algorithm and keychain management are
supported for Border Gateway Protocol (BGP), Intermediate System-
Intermediate System (IS-IS), Open Shortest Path First (OSPF), and Label
Distribution Protocol (LDP). Key chain management is part of the
Manageability package.
In addition, the Generalized TTL Security Mechanism (GTSM, latest is
RFC 5082) feature is integrated at the socket layer of BGP.
Default Services
Services, such as Telnet and TFTP, must be explicitly configured; they are
not on by default. Rate and session limiting of incoming CLI connections
using Telnet, SSH, HTTP, and so on, is available.

Module 7 Cisco Security Features
Cisco Security Features
Layered Defense
! ASICs
! OS and infrastructure
" Kernel
" Memory protection
" Restartable processes
! Division of planes
" Control plane security
" Management plane security
" Data plane security
MD5 Authentication for protocol signaling

! BGP, ISIS, OSPF, MPLS LDP
No default services enabled
! All services must be specifically enabled

Basic 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 that includes:
Software Authentication Manager
Authorization, authentication, and accounting
Access control lists

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.
Authorization, Authentication, and Accounting

Cisco IOS XR AAA controls user access to the router by implementing
security through 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 a network traffic profile. This profile can
then be referenced by 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.

Module 7 Basic Security Overview
Basic Security Overview
Cisco IOS XR base package provides

Software Authentication Manager (SAM)
! Ensures software integrity and compatibility with
each installation
Authorization, authentication, and accounting
! Controls user access
! Implements task-based authorization
! Uses user and task groups
! Provides logging and audit trails
Access control lists (ACL)
! Defines traffic profiles
" Contains one or more access control entries (ACEs)

Key Chain Management

Keys are a string of bits used by an encryption algorithm to encrypt or
decrypt data. A key chain is a container that holds encrypted secrets for
multiple applications and secure services.
Items in a key chain are typically referred to as secrets, encrypted and
protected by the keychain, along with associated attributes and access
objects. A keychain item has a class that determines what attributes it has;
for example Internet password items include an IP address attribute. The
password or other secret stored as a keychain item is encrypted and is
inaccessible when the keychain is locked. When the keychain is unlocked,
the secret can be read by the trusted applications listed in the items access
object and by the user using some utility. Currently, attributes are not
typically encrypted.
Key chain management is a common authentication method to configure
shared secrets on all the entities that exchange secrets before establishing
trust between them. Routing protocols and network management
applications often use authentication to enhance security while
communicating with peers.
The key chain by itself has no relevance; therefore, it must be used by an
application that needs to communicate by using the keys with its peers.
The key chain provides a secure mechanism to handle the keys and
rollover based on the lifetime. A key chain is a sequence of keys that are
collectively managed for authenticating the same peer, peer group, or both.
Key chain management groups a sequence of keys together under a key
chain and associates each key in the key chain with a lifetime.
Keychain management is part of the Manageability PIE.

Module 7 Key Chain Management
Key Chain Management
Key chains
! Software that contains cryptographic keys
Key chain management
! Creates and maintains shared secret keys
" Keys used by applications
Part of the Manageability PIE

Security Package Overview

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.

Module 7 Security Package Overview
Security Package Overview
Security package (k9sec) 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

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

Module 7 Security Package Overview
Security Package Overview (Cont.)
Secure Socket Layer (SSL) and Transport Layer

Security (TLS)
! Application-level protocols
! Secures client/server communication
! Requires RSA or DSA key pairs and CA
certificate
Secure Shell
! Replaces for Berkeley rexec and rsh tools
! Version 1 (SSHv1) using RSA keys
! Version 2 (SSHv2) using DSA keys


Software authentication is used to verify that the software being installed
on the router is safe. For authentication to occur, the software must be in
the PIE format. SAM also verifies that software pre-installed on a flash
card has not been tampered with while in transit.
Basic Cisco IOS XR software is shipped with an embedded CA-root public
certificate. PIE files are digitally signed by the Cisco Release Engineering
group, and SAM verifies the digital signature against the embedded root
certificate before allowing that PIE to reside on the router flash. 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 blocks unauthorized executables from running on the router, as well.

Module 7 Software Authentication Manager
Software Authentication
Ensures that software being installed on router is safe
Requires that installed software be in PIE format
! Verifies that software on flash cards is not compromised
Image Validation
Each Cisco CRS-1 is shipped with embedded Cisco CA-root
public certificate
Additional software installed on the Cisco CRS-1 contains:
! Cisco root certificate
! Digital signature signed by authorized Cisco Release Engineering
with Cisco CA-root certificate
Each PIE is validated against the embedded root certificate
SAM blocks unauthorized executables from running on router

SAM: Image Validation

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.
Other possible reasons for rejection of the package are:
Incorrect format of package
Certificate authority check fails
MD5 checksum is incorrect

Module 7 Software Authentication Manager
SAM: Image Validation

ASRKE - SAM: Image Validation
Install add process

!Checks and validates PIE is a valid entity to load on system
!Contents are rejected if
" Format is not correct
" CA check fails
" MD5 checksum is incorrect
Install 205: [ 0%] Install operation 'add /tftp://172.21.116.8/asr9k-rout-p-hacked.pie'

assigned request id: 205
RP/0/RP0/CPU0:Mar 11 06:44:48.793 : instdir[193]: %PKG-3-NOT_PIE_FILE :
File '/tftp://172.21.116.8/asr9k-rout-p-hacked.pie' is not in PIE format.
RP/0/RP0/CPU0:Mar 11 06:44:48.795 : instdir[193]: %PKG-3-CORRUPT_ARG :

Corrupt parameter passed to Package infrastructure : pkg/bin/instdir : (PID=73834) :
-Traceback= fc3169b8 fc316628 fc316420 fc328440 4821b02c 4821b290 4820f74c 4821814c fc15feac
Install 205: [ 0%] Idle timeout on this line will now be resumed for synchronous
install operations

Access Security Control Planes

Cisco IOS XR software operates in two planes: administration (admin) and
secure domain router (SDR). Basic prerequisites, such as a root-system
user and SDR users, along with task and user groups, are required.
Control Planes
The admin plane has complete responsibility (administrative and non-
administrative) for the physical and owner secure domain router, and
certain other administrative responsibility for all other non-owner secure
domain routers.
The admin plane is accessible to only the root-system user. A non-owner
SDR is accessible to the root-system user, root-lr user of a non-owner SDR ,
and individual users for that specific non-owner SDR. Individual users
should not be given access to any SDR that is not directly associated with
them.

Module 7 Access Security Control Planes
Access Security Control Planes
Administration (admin) plane
Secure domain router (SDR) plane
Admin plane applies to entire physical router

! Cisco CRS-1 router
! Cisco XR12000 Series routers
One or more SDRs

Prerequisites for Secure Access

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
Associate the root-system user with a user group that is associated with
a task group that includes the proper task IDs for security commands
Assign additional users to user groups that provide their needed task
access
Use an external security server when many user accounts are shared
among many routers within a network domain (recommended). A
typical configuration would include the use of an external AAA security
server and database, with the local database (SysDB) option as a
backup in case the external server becomes unreachable.

Module 7 Prerequisites for Secure Access
Prerequisites for Secure Access
Root-system user established

! During initial setup dialog of new router
! During initial setup dialog of router upgrade from Cisco IOS
! Should always be one
Root-system user associated with a task group with
proper task IDs
Additional users assigned to user groups providing
needed task access
External security server recommended when user
accounts apply to many routers in a domain
! Typical configuration includes external AAA security server
and database
! A local database is an option as backup

Secure Access Implementation

Authentication, authorization, and accounting (AAA) helps protect router
resources from improper use. In Cisco IOS XR, the access security
information enabled by AAA is stored in a database on a remote AAA
server or locally in SysDB. Accounting records are stored externally.
Authentication
Authentication is the process of identifying a user or an application
requesting access to the router and ensuring the identity through the use
of passwords. Cisco IOS XR does authentication by comparing the
incoming user ID and password with what is stored in a security database.
Authorization
Authorization is the process of granting a user access to router resources.
Cisco IOS XR uses tasks, task groups, and associated user groups to
determine the accessibility of resources for a user.
Accounting
Accounting is the process of tracking user activity and the amount of
resources being consumed. Cisco IOS XR provides a method of 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.
Cisco IOS XR software supports both the TACACS+ and RADIUS methods
of accounting.
Method Lists
Because AAA data may be stored in variety of places, configuration of
method lists may be used to define the order of preference for the source of
the AAA data. More than one method list may be defined and applications
may use different ones. For example, console and auxiliary ports may use
one method list, while another method list may be assigned to vty access. If
no method list is defined, the application uses a default method list. If
there is no default, the local database is always used.

Module 7 Secure Access Implementation
Secure Access Implementation
Accounting
database
SysDB
Authentication
Authorization
Accounting

Local Security Database

AAA data, such as users, user groups, and task groups, is stored locally
within a secure domain router. The data is stored in the in-memory
database, SysDB, and the configuration file. The stored passwords are
encrypted. The local database may also have X.509 certificates for Secure
Socket Layer (SSL) and Transport Layer Security (TLS), if the security
package is installed.
____________________________ Note _________________________
The specific secure domain router database, in which users and groups
are defined, is not visible to other secure domain routers in the same
system.
__________________________________________________________________

Local Security Database
SysDB
Users, user groups, and task groups are stored

in a local database (SysDB)

Remote Security Database

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+ or RADIUS).
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.
User Group Management
User groups created in an external server are not the same as the AAA
user group concept. External TACACS+ or RADIUS group structures are
not recognized by the router. The management of the external server user
groups is independent from the router. Configuration of user groups is
defined by the design of the external server product.
The remote user or group profiles may contain attributes that indicate
router groups to which a user or users may belong. The remote groups may
also define individual tasks.
Task Group Management
Task groups are defined by lists of permitted task IDs for each type of
action (read, write, execute, debug). The task IDs are defined in the router.

Remote Security Database
AAA subsystem IP
CLI network
AAA client AAA TACACSD

HTTP library server
External
AAA
RADIUSD server
XML
agents
TACACSD TACACS daemon

RADIUSD RADIUS client subsystem

SDR Security Database

The root-system user has the highest level of responsibility for the router.
This user provisions secure domain routers and creates root-lr users. When
created, root-lr users have responsibility for the individual SDRs. Root-lr
users, in turn, can create SDR users. Currently, root-system and root-lr
users have fixed permissions (task IDs) and cannot be changed.
Security data is stored in local databases. Each SDR has a local AAA
database, in which users are defined. The owner SDR local AAA database
also contains the admin plane security information.
If a user is defined in an external TACACS+ server, it is possible for that
same user to have access to multiple secure domain routers.

SDR Security Database
ADMIN
Owner SDR1 SDR2

SDR
AAA AAA AAA
Single physical router

Secure Access Policy

Security policy is created by combining tasks (task IDs) into groups,
defining which router configuration and management functions that can be
performed by users.
Creating Secure Access Policy

Task IDs
Task IDs define permission to perform 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.
Task Groups
A task group is defined by a collection of task IDs for each class of action.
Task groups are defined so that multiple rights can be pooled together into
a rights policy.
Implementing Security Access Policy

Task IDs are grouped into task groups to create job tasks. User groups are
created to simulate job descriptions and associated with task groups. Users
are defined and assigned to user groups based on their job description.
User Groups
A user group is a collection of users that share similar authorization rights

on a router or series of SDRs.
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.

Module 7 Secure Access Policy
Secure Access Policy
Task identifiers Task groups
Control, configuration, Cisco predefined task

or execution of groups
operations
Custom-defined task
Read, write, execute, groups
and debug actions
Hierarchically structured
Task classes groups
Task ID examples: Re-use of task groups
! basic-services
! network
! interface
! bgp, isis, ospf, rib
Security policy
Task IDs
Task
Groups
User
Groups
Users

Task-Based Authorization
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.
Users are associated with sets of task IDs that define the breadth of their
authorized access to the router.
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 ID Samples
Task IDs grant permission to perform tasks and are one, all, or some
combination of the following:
RPermits only a read operation
WPermits a change (or write) operation and allows an implicit read
EPermits an access operation, such as ping or Telnet
DPermits a debug operation
Task ID operations with R/W mean that both operations must be applied.
Multiple task ID operations are separated by commas and mean that the
operations should be applied to the respective task. An example is the
copy access-list ipv4 command, which requires read and write for the acl
task, and execute for the filesystem task.
If no operation is specified for a task, then no specific user association to
the task is required.

Module 7 Task-Based Authorization
Task-Based Authorization
Task IDs
Represent router control, configuration, and monitoring
operations
Define permissions
Each operation on router is a task with a unique task ID
! Config is a task
! Reload is a task
! CLI commands and API invocations
Task group contains a list of task IDs
User group associated with task groups
Users are associated with user groups
Only users assigned with the right task IDs can execute those
tasks
Access List Commands Task IDs Operations

clear access-list ipv4 basic-services, acl, bgp R/W, R/W, R/W/E
clear access-list ipv6 basic-services, acl, network R/W, R/W, R/W
copy access-list ipv4 acl, filesystem R/W, E
copy access-list ipv6 acl, filesystem R/W, E
deny (ipv4) acl R/W
deny (ipv6) acl R/W
ipv4 access-group acl, network R/W, R/W
ipv4 access-list acl R/W
permit (ipv4) acl R/W
permit (ipv6) acl R/W
resequence access-list ipv4 acl R/W
resequence access-list ipv4 acl R/W
show access-lists ipv4 acl R
show access-lists ipv6 acl R

Security Configuration
Cisco IOS XR software provides operational tasks to implement security
policy and grant access based on local requirements. Cisco Systems, Inc.
has also created task groups and user groups with permissions and access
that may suit your particular situation.
Site-Defined Groups and Users

Before configuring the security policy, you must give some thought 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 site-defined 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 7 Security Configuration
Site-Defined Groups and Users
Task group (TG) User group (UG)

Name Name User
Task ID associations Inheritance of Name
! Read, write, and so TG permissions Password
on Taskgroup List of user
Inheritance of other associations groups
TG permissions
Suggested order of configuration
taskgroup ospf-admin
task read ospf
task write ospf
usergroup ospf-users
taskgroup ospf-admin
username joesmith
password <password>
group ospf-users

Task Groups
A task group is defined by a collection of task IDs. Task groups contain
task ID lists for each class of action.
Each user group is associated with a set of task groups applicable to the
users in that group. A users task permissions are derived from the task
groups associated with the user groups to which that user belongs.
Task Groups are either:
Predefined Task Groups

Site-Defined Task Groups
Group Inheritance
Task groups have group inheritance properties that support inheritance

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

The following predefined task groups are available for administrators to
use, typically for initial configuration:
root-systemRoot-system administration
root-lrRoot-SDR administration
netadminNetwork administration
sysadminSystem administration
operatorTypical day-to-day operation
serviceadminService administration
Users can configure their own task groups to meet particular needs.
Task groups support inheritance from other task groups.

Task Groups
Collection of tasks (task IDs)

! Predefined or user-defined
! User groups are associated to a task group
Predefined Groups
! root-system Root-system users
! root-lr Root-SDR users
! netadmin Network administrators
! sysadmin System administrators
SDR users
! operator Day-to-day activity users
! serviceadmin Service administrators
Site-defined task groups
! Support inheritance

Creating Site-Defined 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 task group is associated with one or more task IDs
selected from the Cisco IOS XR set of available task IDs.
The first configuration task in setting up the router authorization is to
configure the task group. To access the task group configuration submode,
enter the taskgroup command.
Here are some additional examples of creating taskgroups:
:router(config)#taskgroup ospf-admin
:router(config-tg)#task read ospf
:router(config-tg)#task write ospf
:router(config-tg)#task read rib
:router(config-tg)#task write rib
:router(config)#taskgroup isis-admin
:router(config-tg)#task read isis
:router(config-tg)#task write isis
:router(config-tg)#task read rib
:router(config-tg)#task write rib
:router(config)#taskgroup igpadmin
:router(config-tg)#inherit taskgroup ospf-admin
:router(config-tg)#inherit taskgroup isis-admin

Creating Site-defined Task Groups
Configure task group bgpadmin
:router(config)# taskgroup bgpadmin
Assign task permissions for BGP configurations
:router(config-tg)# task read bgp

:router(config-tg)# task write bgp
Inherit other task group rights (bgpadmin can do IGP configs, too)
:router(config-tg)# inherit taskgroup igpadmin
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. The display shows tasks that are
a direct part of the group itself, and those that are inherited from other
task groups.

Verifying Task Group Configuration
:router# show aaa taskgroup bgpadmin

Task group 'bgpadmin'
Inherits from task group 'igpadmin'
Inherited
Inherits from task group 'isis-admin'
tasks
Inherits from task group 'ospf-admin'
Directly
Task IDs included directly by this group:
assigned
Task: bgp : READ WRITE tasks
Task group 'bgpadmin' has the following combined set

of task IDs (including all inherited groups):
Task: bgp : READ WRITE
Task: isis : READ WRITE Combined
Task: ospf : READ WRITE tasks
Task: rib : READ WRITE

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
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 is configured in the admin plane and has visibility
into any secure domain routers. To support this feature, the default SDR
AAA database is defined for the admin plane.
Authentication of SDR Owner
An SDR owner can log in to only those nodes belonging to the specific
secure domain router associated with that SDR owner. If the user is a
member of the SDR owner group, then the user is authenticated as an SDR
owner. All secure domain routers have their own SDR owner groups.
Authentication of SDR User
The SDR user authentication is similar to the SDR owner authentication.

If the user is not a member of the designated SDR owner group or the root-
system user group, the user is authenticated as an SDR 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
Collection of users with same attributes and

privileges
! Cisco predefined user groups
! Site-defined groups
Authentication
! Compare user ID and password with AAA DB
! Admin plane
" Root-system user
! SDR plane
" Root
" Users

Predefined User Groups and Permissions

Cisco IOS XR software provides the means for a system administrator to
configure groups of users and job characteristics that are common in
groups of users. Groups must be explicitly assigned to users. Users are not
assigned to groups by default. A user can be assigned to more than one
group.
Cisco IOS XR software has a collection of user groups whose attributes are
already defined. The predefined groups are as follows:
root-systemControls and monitors the entire router. This group has
complete access to all router commands
root-lrControls and monitors a specific SDR. This group has
complete access to a secure domain router and read access to some of
the root-system commands
netadminControls and monitors all system and network
parameters. This group can read all router commands except root-
system commands
sysadminControls and monitors all system parameters, but cannot
configure network protocols. This group can read all router commands
except root-system commands
operatorHas use of some basic commands with basic privileges
serviceadminService adminitration tasks, for example, Session
Border Controller.
Administrators can configure their own user groups to meet particular
needs.

Predefined User Groups and Permissions
Administrators may use these groups in initial

configuration:
root-systemRoot-system owner
! For control and monitoring of entire system
" Read and write all commands on router
root-lrSecure domain router owner

! For control and monitoring a specific SDR
" Read and write all commands on the SDR
! Root-system owner tasks are read only
netadminNetwork administrators
! For control and monitoring all system and network
parameters
" Write routing, forwarding, connectivity, VLAN, AAA, and others
! Read all commands except root-system owner commands
sysadminSystem administrators
! For control and monitoring all system parameters
" Write AAA, manageability, logging, and others
" Cannot configure network protocols
! Read all commands except root-system owner commands

operatorGeneral user
! For basic access
" Reads logs, CDP, and run some diagnostics
! Read and write basic operations commands
serviceadminService administrators
! For administration of services, such as Session Border
Controller

Creating Site-Defined 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.
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.

Creating and Verifying Site-defined User Groups
Configure usergroup routeadmin
:router(config)# usergroup routeadmin
Associate taskgroup to a usergroup
:router(config-ug)# taskgroup bgpadmin
Commit the changes
:router# show aaa usergroup routeadmin

User group 'routeadmin'
Inherits from task group 'bgpadmin'
Inherits from task group 'igpadmin' Group
inherits
Inherits from task group 'isis-admin'
Inherits from task group 'ospf-admin'
User group 'routeadmin' has the following combined set

of task IDs (including all inherited groups):
Task: bgp : READ WRITE
Task: isis : READ WRITE Combined
tasks
Task: ospf : READ WRITE
Task: rib : READ WRITE

Users
User attributes form 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; the maximum
length of a password is 253 characters
List of user groups (at least one) of which the user is a member (thereby
enabling attributes such as task IDs)

Users
Each router user has:

! User ID (ASCII string) that provides a unique
identity
! Password of an arbitrary length, stored encrypted
! At least one user group of which the user is a
member
" Enables attributes such as task IDs

Configuring Users
Each user is identified by a username that is unique across the
administrative domain. Each user should be made a member of at least one
user group. Deleting a user group may orphan the users associated with
that group.
The username command provides username and password authentication
for login purposes only. It provides the method of assigning a user to a user
group.
To create users with passwords, follow these steps:
1. Configure a username to add users who can access the system
2. Configure the password for the user defined with the username
command. Passwords have two levels: password and secret
! PasswordLower security
! Unencrypted uses a parameter value of 0; means enter the
password in clear text and is the default
! Encrypted uses a parameter value of 7; means enter the
password in encrypted format
! SecretHigher security
! Unencrypted uses a parameter value of 0; means enter the
password in clear text and is the default
! Encrypted uses a parameter value of 5; means enter the
password in encrypted format
Secret overrides and ignores password, even if password has been
set.
3. Associate the user with one or more groups that will give them 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
Configure a user
:router(config)#username adam
Assign a password
0 means enter unencrypted (default)
7 means enter encrypted
:router(config-un)#password [0 | 7] <password>
:router(config-un)#
Associate the user to a usergroup
:router(config-un)#group routeadmin
Commit the changes

Verifying User Configuration

To display all local users with their respective user groups, use the show
aaa userdb command. When executed from the primary secure domain
router EXEC mode, this command shows users in the admin plane and
SDR plane.
To display information for a specific user and the tasks that the user can
perform, use the show aaa userdb username command. The display
shows the group, or groups, to which the user belongs, as well as the task
IDs to which they have access. This slide shows a root-lr user.

Module 7
Verifying User Configuration
Display all users on owner SDR
:router# show aaa userdb

Username adam User
User group routeadmin
Username cisco (admin plane) Admin plane root
User group root-system
Username student Owner SDR root
User group root-lr
Display users on non-owner SDR

:SDR-router# show aaa userdb
Username cisco
User group root-lr
Display a specific user
:router# show aaa userdb adam

Username: adam
User group routeadmin
Matches
Task: bgp : READ WRITE routeadmin
Task: isis : READ WRITE user group
Task: ospf : READ WRITE and
Task: rib : READ WRITE bgpadmin
task group

Management Plane Protection

Cisco IOS XR Management Plane Protection (MPP) gives you the ability to
restrict the interfaces on which network management packets are allowed
to be received.
The management plane is the logical path of all traffic that is related to the
management of a router. One of the three planes, the management plane
perfoms the management function for a network and coordinates functions
between all the planes (management, control, and data).
MPP operates within the Control Plane Protection (CPP) infrastructure.
The control plane is the collection of processes that provide the high-level
control for most of the Cisco IOS XR software functions. Control Plane
Policing (CoPP) is a Cisco IOS XR control plane mechanism that offers rate
limiting of the control plane traffic. CPP is the framework for all policing
and protection features in the control plane.
What is MPP?
With MPP, interfaces can be designated as management interfaces.
Restricting the management interfaces has some benefits:
Improved performance for data packets on nonmanagement interfaces
Network scalability
Fewer ACLs to restrict traffic are needed
Management packet floods prevented from overcoming the router CPU

By default the management interfaces on the route processors (RPs) are
part of the management network. Management may be turned off on these
interfaces, if necessary. All other interfaces must be configured to accept
management packets.

Module 7 Management Plane Protection
Network management ingress protection

Designate interfaces as management capable
Benefits
! Provides additional security for router
! Fewer ACLs required to restrict access
Defaults
! Management Ethernet (RP) interfaces on
" May be turned off
! All other interfaces off
" Must be turned on

Configuring Management Plane Protection

By default, when a management protocol is enabled, the management
interfaces on the active RP and standby RP are the only interfaces to allow
the management traffic. You must configure other interfaces to use allow
management traffic.
These protocols are supported by the MPP feature:
SSh, v1 and v2
SNMP, all versions
Telnet
TFTP
HTTP and HTTPS
A single, control-plane management-plane command, as illustrated on
the following page, is used to invoke the management protocol on the
inband interfaces in the router.
____________________________ Note _________________________
By configuring only SSH on the POS interface, all other management
protocols are denied on that interface.
__________________________________________________________________

Configuring Management Plane Protection
Configure interface for management packets

! For example, allow SSH
! Other possibilities: HTTP, SNMP, TFTP, Telnet, all
:router# control-plane management-plane inband interface pos 0/3/0/1 allow ssh
Display running configuration
:router# show running-config control-plane

control-plane
management-plane
inband
allow SSH

Displaying Management Plane Protection

The command, show mgmt-plane, is used to review the configured
inband interfaces on the router.

Displaying Management Plane Protection
:router# show mgmt-plane

inband interfaces
interface - POS0/3/0/1
SSH configured -
All peers allowed
Displays all interfaces

! Non-RP management interfaces

Summary
Cisco IOS XR Security
List Cisco IOS XR security features
Summarize Cisco IOS XR security package features
Describe security database implementation
Describe task-based authorization
Describe predefined task and user groups
Describe user and task group configuration
Explain and implement site-defined group and user configuration
Describe user configuration
Explain control plane and management plane protection

Module 8
Routing Protocols
Overview
Description
This module covers the Cisco IOS XR software implementation of the Open
Shortest Path First (OSPF) protocol, the Intermediate System-to-
Intermediate System (IS-IS) protocol, and the Border Gateway Protocol
(BGP). Only configuration of the IPv4 address family is discussed.
Objectives
Describe IS-IS, OSPF, and BGP features in Cisco IOS XR software
Configure basic IS-IS, OSPF, and iBGP functionality

Examine basic IS-IS, OSPF, and BGP operation

Routing Protocols Module 8
Intermediate System to Intermediate System (IS-IS)

Feature Support
Major features of the Cisco IOS XR IS-IS implementation include the
following:
A hierarchical configuration structure is supported that groups all IS-
IS configuration, including IS-IS interface configuration, under the
router configuration mode. This grouping makes the IS-IS
configuration process clearer and more intuitive. The resulting IS-IS
configuration can be viewed using the show running-config router
isis command.
Cisco IOS XR software supports multiple independent IS-IS instances.
Each IS-IS instance can support a single Level 1 or Level 2 area or one
of each. Routes can be redistributed between instances. You can
configure as many IS-IS instances for each secure domain router (SDR)
as your system network resources allow. Each interface within an SDR
can be associated with only one IS-IS instance.
_________________________ Note _________________________
If Multiprotocol Label Switching Traffic Engineering (MPLS-TE) is
configured for use with IS-IS, it can be enabled for one IS-IS
instance only, because MPLS is not multi-instance aware.
_______________________________________________________________
Cisco IOS XR IS-IS software supports multitopology as the default
behavior when more than one address-family (IPv4 and IPv6) is
configured. Single topology must be explicitly configured in the IPv6
address family.
The Cisco IOS XR IS-IS implementation is optimized for IPv4 and IPv6
routing and does not support routing of OSI Connectionless Network
Service (CLNS) traffic.

Module 8 Intermediate System to Intermediate System (IS-IS)
Feature Support
Hierarchical configuration
show running-config router isis
Multiple IS-IS instances
Each instance ! Level 1 area, Level 1 and Level 2 area, or Level 2
area only
MPLS-TE configured for one instance only
Multitopology is the default behavior
Separate IPv4 and IPv6 topologies
Single (combined IPv4 and IPv6) topology can be configured
IS-IS supports only IP routing
No CLNS routing

CLI Configuration Structure

The hierarchical Cisco IOS XR CLI results in grouped configuration
structure. 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 is 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-wide parameters and under the IS-IS
interface configuration for interface-specific parameters.
____________________________ Note _________________________
Although a logical configuration hierarchy exists in the IS-IS
configuration, no support exists for inheritance of IS-IS interface
parameter values in the same way there is for OSPF.
__________________________________________________________________
Some parameters can be associated with IS-IS Level 1 or Level 2 area
operation. In those cases, such as with the hello-interval command, the
level [1|2] form of the command is used. If the level designation is
omitted, the parameter is associated with both levels by default. In other
cases in which a tri-state value occurs for a parameter, that is, the
Intermediate System is-type can be Level 1 or Level 2 or both, Cisco IOS
XR software uses [level-1|level-2 |level-1-2]. This syntax also allows
something other than level-1-2 to be the default.

Module 8 Intermediate System to Intermediate System (IS-IS)
Hierarchical IS-IS configuration; no IS-IS interface

parameter inheritance
router isis
(config-isis)
address-family interface
(config-isis-af) (config-isis-if)
address-family
(config-isis-if-af)
Example configuration session
:router(config)# router isis lab

:router(config-isis)# net 49.0001.0000.0000.0001.00
:router(config-isis)# address-family ipv4 unicast
:router(config-isis-af)# metric-style wide
:router(config-isis-af)# exit
:router(config-isis)# interface Gi0/2/0/1
:router(config-isis-if)# hello-interval 5 level 1
:router(config-isis-if)# address-family ipv4 unicast
:router(config-isis-if-af)# metric 75

Configuring IS-IS
An IS-IS instance is enabled from global configuration mode (prompt:
config). You can specify multiple IS-IS routing instances in each router.
All IS-IS configuration commands are configured under an IS-IS routing
instance.
Step 1router isis Command

Use the router isis command to enable IS-IS routing for the specified
routing instance and place the CLI in router configuration mode (prompt:
config-isis).
____________________________ Note _________________________

The instance name is a case-sensitive alphanumeric string (no spaces
allowed) no longer than 40 characters.
__________________________________________________________________
Step 2net and Other Router Submode Commands

The network entity title (NET) is a required parameter for the IS-IS
instance. Without a NET specified, the IS-IS instance is not operational. To
configure a NET for the IS-IS instance, use the net command in router
configuration mode.
A NET is a network service access point (NSAP) where the last byte is
always zero. In Cisco IOS XR software, an IS-IS NET can be 8 to 20 bytes
in length. The last byte (n-selector) must be zero, which means that the
packet is for the routing software of the system. The six bytes directly
preceding the n-selector are the IS-IS system ID. The system ID must be
unique throughout each area (Level 1) and throughout the backbone
(Level 2). All bytes preceding the system ID are the area ID.
Other parameters specific to the operation of the IS-IS instance, such as
routing level (Level 1, Level 2 only, or Level 1 and 2, the default), link state
packet (LSP) and sequence number packet (SNP) authentication type
(clear text password or MD5), and nonstop forwarding (NSF) can also be
set in the router configuration submode.

Module 8 Configuring IS-IS
router Command and Submode
Step 1Configure IS-IS instance in global configuration mode

(config)#
router isis instance-name
:router(config)# router isis lab

:router(config-isis)#
Step 2Configure the IS-IS network entity title and optionally other
parameters in router submode
(config-isis)#
net nsap
:router(config-isis)# net 49.0001.0000.0000.0001.00
Area System ID Router

Step 3Router address-family Command

To configure IS-IS routing for standard IPv4 and IPv6 unicast prefixes, use
the address-family command in router submode (prompt: config-isis).
This command places the CLI in router address family submode (prompt:
config-isis-af). If not configured, the default address family for the
IS-IS instance is IPv4 unicast.
Step 4Router Address Family Submode

Parameters specific to the routing of IPv4 and IPv6 prefixes for an IS-IS
instance such as disabling adjacency checking, generating a Level 2 default
route, maximum number of parallel paths per prefix, and metric style are
set directly in the router address family configuration submode.
metric-style Command
The metric-style command causes IS-IS to generate and accept either old-
style 6-bit metrics (narrow keyword) or new-style 24-bit metrics (wide
keyword). MPLS-TE use of IS-IS requires the new-style wide metrics.

Router address-family Command and Submode
Step 3Optionally configure address family in router submode

(config-isis)#
address-family {ipv4 | ipv6} {unicast | multicast}
:router(config-isis)# address-family ipv4 unicast

:router(config-isis-af)#
Step 4Optionally configure other parameters, such as metric style

(required for MPLS-TE), in router address family submode
(config-isis-af)#
:router(config-isis-af)# metric-style wide

Step 5interface Command

To associate a specific interface with an IS-IS instance, use the interface
command in router configuration mode (prompt: config-isis). This
command places the CLI in interface configuration submode (prompt:
config-isis-if), from which you can configure interface-specific settings.
Step 6Interface Submode Commands

Parameters specific to the operation of an IS-IS interface are set directly in
the interface submode. Commands to set the circuit type (Level 1, Level 2,
or Level 1 and 2), hello interval, hello multiplier, hello password, passive,
priority, and retransmit interval are supported. Most interface commands
have an optional level keyword to specify behavior for Level 1 or Level 2
operation.
hello-password Command
The hello-password password command defines the IS-IS hello (IIH)

packet authentication type and associated password. With the text
keyword, a clear text password is exchanged between adjacent IS-IS
routers. The hmac-md5 keyword specifies that the password is used as a
key to compute a cryptographic checksum that is exchanged instead.
To more easily manage the rollover of keys and enhance hello
authentication for IS-IS, you can configure a container of keying
information called a keychain. Each keychain entry comprising the
following attributes: generate/accept time, key identification, and key. Use
the keychain keyword and keychain-id to reference the keychain
containing the HMAC-MD5 keying information. The keychain can be
modified at any time to add or delete keying information without
reconfiguring IS-IS usage.
____________________________ Note _________________________
Changes to the system clock can impact the validity of the keys in a
referenced keychain.
__________________________________________________________________

interface Command and Submode
Step 5Configure IS-IS interface in router submode

(config-isis)#
interface type instance
:router(config-isis)# interface Gi0/2/0/1

:router(config-isis-if)#
Step 6Optionally configure IS-IS interface parameters, such as hello

password, in interface submode
(config-isis-if)#
hello-password {text | hmac-md5} [clear | encrypted] password [level {1 | 2}]

hello-password keychain keychain-id [level {1 | 2}]
:router(config-isis-if)# hello-password text cisco

-or-
:router(config-isis-if)# hello-password keychain isis-keys
2011, Cisco Systems, Inc. All rights reserved. Version 3.9.1 Cisco ASR 9000 Series EssentialsModule 08/9

Step 7Interface address-family Command

To configure an IS-IS interface for routing IPv4 and IPv6 unicast prefixes,
use the address-family command in interface submode (prompt: config-
isis-if). This command places the CLI in interface address family
submode (prompt: config-isis-if-af).
____________________________ Note _________________________
An address family must be configured for the interface to operate.
__________________________________________________________________
Step 8Interface Address Family Submode Commands

Parameters specific to the routing of IPv4 or IPv6 prefixes for an IS-IS
interface such as inhibiting IS-IS for the address family, and interface
metric cost are set directly in the interface address family configuration
submode.

Interface address-family Command and Submode
Step 7Configure address family in interface submode

(config-isis-if)#
address-family {ipv4 | ipv6} {unicast | multicast}
:router(config-isis-if)# address-family ipv4 unicast

:router(config-isis-if-af)#
Step 8Optionally configure other parameters in interface address family

submode
(config-isis-if-af)#
Repeat steps 5 through 8 as necessary for each interface in this IS-IS instance

Configuration Example
The topology and configuration on the opposite page are part of the
courses lab environment. In subsequent pages of this module, the PE3
router is used as the target for examining basic IS-IS operation using
various CLI commands.

PE3 P1
.3 192.168.113 .11
10.3.3.3 10.11.11.11
GigE 0/2/0/1
GigE 0/2/0/2
.3
Level 1
Area 49.0001
192.168.123
P2
.12
10.12.12.12
Configuration Example (Cont.)

interface Loopback0
ipv4 address 10.3.3.3 255.255.255.255
!
ipv4 address 192.168.113.3 255.255.255.0
!
ipv4 address 192.168.123.3 255.255.255.0
!
router isis lab PE3
is-type level-1
net 49.0001.0000.0000.0003.00
Configuration
nsf ietf
hello-password text encrypted 02050D480809
!
!
hello-password text encrypted 070C285F4D06
!
!
!

Examining IS-IS Operation

IS-IS Status
The show isis [instance instance-name] command displays general
information about an IS-IS instance and protocol operation. If the instance
name is not specified, it shows information about all IS-IS instances.
For each instance, the first line of output lists the IS-IS instance ID with
following lines identifying the IS-IS system ID, supported levels (level 1,
level 2, or level-1-2), configured area addresses, active area addresses,
status (enabled or not) and type (Cisco or IETF) of nonstop forwarding
(NSF), and the mode in which the last IS-IS process startup occurred.
Next, the status of each configured address family (or just IPv4 unicast if
none are configured) is summarized. For each level (Level 1 or Level 2), the
metric style (narrow or wide) generated and accepted is listed along with
the status of incremental shortest path first (iSPF) computation (enabled
or not). Then redistributed protocols are listed, followed by the
administrative distance applied to the redistributed routes.
Finally the running state (active, passive, or disabled) and configuration
state (active or disabled) of each IS-IS interface is listed.

Module 8 Examining IS-IS Operation
IS-IS Status
Display IS-IS instance

#
show isis [instance instance-name]
:PE3# show isis instance lab
IS-IS Router: lab

System Id: 0000.0000.0003
IS Levels: level-1
Manual area address(es):
49.0001
Routing for area address(es):
49.0001
Non-stop forwarding: IETF NSF Restart enabled
Most recent startup mode: Cold Restart
--More--
IS-IS Status (Cont.)
Topologies supported by IS-IS:

IPv4 Unicast
Level-1
Metric style (generate/accept): Narrow/Narrow
ISPF status: Disabled
No protocols redistributed
Distance: 115
Interfaces supported by IS-IS:
GigabitEthernet 0/2/0/1 is running actively (active in configuration)
GigabitEthernet 0/2/0/2 is running actively (active in configuration)

Interface Operation
The show isis interface command displays the operational status of
interfaces configured with IS-IS. If not qualified with either the instance
name or interface, it shows interfaces for all IS-IS instances.
For each interface, the first line of output indicates the status of the
interface (enabled or disabled), followed by the status of adjacency
formation (enabled or disabled), the status of prefix advertisement
(enabled or disabled), and whether Bidirectional Forwarding Detection
(BFD) is enabled or disabled, along with the minimum generation interval
in milliseconds and the number (multiplier) of times a BFD packet can be
missed before the interface is declared down.
The circuit section starts with the operational IS-IS circuit type (level-1,
level-2, or level-1-2) and the configured circuit type. They are followed by
the media type (LAN or point-to-point) and an internal 8-bit circuit
number. Then, if the circuit type is point-to-point (P2P), there is an
internal 32-bit extended circuit number and how much time remains before
the next point-to-point hello (IIH) will be transmitted out this interface.
The next sections summarize Level 1 or Level 2 operation, or both. First
there is a count of adjacencies. Then, if the circuit type is LAN, there is a
LAN ID, the local and DIS router priorities, and the time (in seconds) in
which the next LAN hello message is sent. Finally, in all cases, there is the
interval at which the link-state packet (LSP) transmission rate (and by
implication the reception rate of other systems) is to be reduced.
The CLNS I/O section starts with the operational protocol state (up or
down) and the maximum transmission unit (MTU) size. Then if the media
type is LAN, there is the subnetwork point of attachment (SNPA) or MAC
address of the neighbor and the status of Level 1 and Level 2 membership
in Layer 2 multicast groups.
The IPv4 topology section starts with the state (enabled or disabled)
followed by the status of adjacency formation (enabled or disabled), the
status of prefix advertisement (enabled or disabled), the Level 1 and Level
2 metrics, and, the state of MPLS LDP (enabled or disabled)
synchronization follows.
The IPv4 address family section starts with the state (enabled or disabled)
followed by the protocol state (up or down), addresses on this interface
used by the neighbor for next-hop forwarding, and prefixes associated with
this interface included in advertised LSPs.
The final information for each interface is the time remaining before the
next LSP is transmitted, the state of LSP transmissions (idle or active),
and the current limit of back-to-back LSPs that can be transmitted in the
stated time interval.

Interface Operation
Interface Operation (For Print)
Display IS-IS interfaces
#
show isis interface [type instance]
:PE3# show isis interface
IS-IS lab Interfaces

GigabitEthernet 0/2/0/3 Enabled
Adjacency Formation: Enabled
Prefix Advertisement: Enabled
BFD: Disabled
BFD Min Interval: 150
BFD Multiplier: 3
Circuit Type: level-1 (Interface circuit type is level-1-2)

Media Type: LAN
Circuit Number: 1
--More--
Interface Operation (Cont.)

Level-1
Adjacency Count: 1
LAN ID: PE3.01
Priority (Local/DIS): 64/64
Next LAN IIH in: 302 ms
LSP Pacing Interval: 33 ms
PSNP Entry Queue Size: 0
(entries omitted)
IPv4 Unicast Topology: Enabled

Adjacency Formation: Running
Prefix Advertisement: Running
Metric (L1/L2): 10/10
MPLS LDP Sync (L1/L2): Disabled/Disabled
IPv4 Address Family: Enabled

Protocol State: Up
Forwarding Address(es): 192.168.113.3
Global Prefix(es): 192.168.113.0/24
LSP transmit timer expires in 0 ms

LSP transmission is idle
Can send up to 7 back-to-back LSPs in the next 0 ms

Neighbor Adjacencies
The show isis neighbor command displays the current status of neighbor
adjacencies. If not qualified with the instance instance-id keyword and
argument, the command shows all neighbors on all IS-IS interfaces for all
IS-IS instances.
Each neighbor is listed by its system ID, followed by the local interface
name, subnetwork point of attachment (MAC address if LAN or *PtoP* if
point-to-point), adjacency state, time remaining (hold time) before
declaring adjacency down, adjacency type (L1, L2, or L12), and whether the
neighbor supports the IETF-style nonstop forwarding.
Adding the detail keyword to the command provides additional
information about each neighbor adjacency, including area addresses, IPv4
or IPv6 addresses of the network connecting the neighbor, whether IPv4 or
IPv6 (or both) topologies are supported to the neighbor, and the length of
time the adjacency has been up.

Display IS-IS neighbors
#
show isis neighbors [detail]
:PE3# show isis neighbors detail
IS-IS lab neighbors:

System Id Interface SNPA State Holdtime Type IETF-NSF
P2 Gi0/2/0/2 0003.6cfe.cd02 Up 25 L1 Capable
Area Address(es): 49.0001
IPv4 Address(es): 192.168.123.12*
Topologies: 'IPv4 Unicast'
Uptime: 00:01:42
with detail keyword
P1 Gi0/2/0/1 0050.2abe.8902 Up 23 L1 Capable
Area Address(es): 49.0001
IPv4 Address(es): 192.168.113.11*
Topologies: 'IPv4 Unicast'
Uptime: 00:01:41 with detail keyword
Total neighbor count: 2

Open Shortest Path First (OSPF)

Feature Support
The Cisco IOS XR implementation of Open Shortest Path First (OSPF)
conforms to the OSPF version 2 (for IPv4) and OSPF version 3 (for IPv6)
specifications which are detailed in the Internet RFC 2328 and RFC 2740
respectively. The following are key features of the Cisco IOS XR OSPF
implementation:
Stub areasStub areas are supported.
Not-so-stubby areas (NSSA)RFC 1587 is supported.
Virtual linksVirtual links are supported.
Demand circuit and flooding reductionRFC 1793 for demand
circuits is supported, as well as the extension for general flooding
reduction.
Nonstop forwarding (NSF)/Graceful restartCisco NSF is supported
for OSPFv2; RFC 3622 Graceful restart is supported for both OSPFv2 and
OSPFv3.
Shortest path first (SPF) and link state advertisement (LSA)
throttlingBoth SPF and LSA throttling are independently supported.
Route redistributionRoutes from other IP route sources (connected,
static, routing protocols) can be redistributed into OSPF.
Authentication Plain text and Message Digest 5 (MD5) authentication
between neighboring routers is supported for OSPFv2 and IPSec-based
MD5 and SHA1 authentication is supported for OSPFv3.
Routing interface parametersConfigurable interface parameters,
such as metric, retransmission interval, transmit delay, router priority,
dead interval, hello interval, and authentication key are supported.
Multiple InstancesCisco IOS XR software supports multiple
independent OSPF instances.
____________________________ Note _________________________
If Multiprotocol Label Switching Traffic Engineering (MPLS-TE) is
configured for use with OSPF, it can be enabled for one OSPF instance
only, because MPLS is not multi-instance aware.
__________________________________________________________________

Module 8 Open Shortest Path First (OSPF)
Feature Support
BGP
Area 2 EIGRP Area 3
IS-IS
RIP NSSA
Static ASBR
Internal
Internal
Virtual ABR
ABR Link
Area 0 Area 4
Backbone Stub
ABR ABR
Internal
Internal
BBone
Passive
Area 1
Standard OSPFv2 (IPv4) and OSPFv3 (IPv6)


Cisco IOS XR configuration of OSPF uses a hierarchical CLI supporting
inheritance of interface parameter values.
Hierarchical CLI
Hierarchical CLI is the grouping of related network component
information at defined hierarchical levels - OSPF router, area, and
interface:
router ospf lab
area 0
The router configuration prompt tells you the level you are on in the
configuration hierarchy. The following router prompt indicates that you
are in OSPF router (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 software, most OSPF interface 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 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.

Module 8 Open Shortest Path First (OSPF)
Hierarchical configuration with OSPF interface parameter

inheritance
router ospf
(config-ospf)
Interface
parameter
inheritance area
(config-ospf-ar)
interface virtual-link
(config-ospf-ar-if) (config-ospf-ar-vl)
OSPF configuration parameters are grouped at levels under the

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

inherited by lower levels
:router(config-ospf)# hello-interval 40
(specified here at router level and inherited by OSPF interfaces)

Configuring OSPFv2
An OSPF instance is enabled from the global configuration mode (prompt:
config). You can configure multiple OSPF routing instances in each SDR.
All OSPF configuration commands are configured under an OSPF routing
instance.
Step 1router ospf Command

Use the router ospf instance-name command to enable OSPFv2 routing
for the named routing instance, and place the CLI in router configuration
mode (prompt: config-ospf). Alternatively, specifying the ospfv3 keyword
enables OSPFv3 routing for the routing instance.
____________________________ Note _________________________
The instance name is a case-sensitive alphanumeric string (no spaces
allowed) no longer than 40 characters.
__________________________________________________________________
Step 2router-id Command

To configure a router ID for the OSPF process, use the router-id command
in router configuration mode. 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.
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 highest IPv4 address assigned to any loopback interface.
4. The primary IPv4 address of an interface configured for this OSPF
instance.
____________________________ 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 any interface state change or address
reconfiguration.
__________________________________________________________________

Module 8 Configuring OSPFv2
Step 1Configure OSPF instance in global configuration mode

(config)#
router ospf instance-name
:router(config)# router ospf lab

:router(config-ospf)#
Step 2Optionally configure the OSPF router id in router submode
(config-ospf)#
router-id {router-id | interface-type interface-instance}
:router(config-ospf)# router-id 10.1.1.1

Step 3area Command

From the router configuration mode (prompt: config-ospf), use the area
area-id command to configure an OSPF area. The CLI enters area
configuration mode (prompt: config-ospf-ar).
____________________________ 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.
__________________________________________________________________
If multiple areas are configured for an OSPF instance, it will function as
an area border router (ABR) without any other specific configuration.
Step 4Area Submode Commands

Parameters specific to the operation of this area, such as stub or not-so-
stubby area (NSSA) type, advertised cost of default route for stub area or
NSSA, and ABR route summarization can be set in the area configuration
submode.

area Command and Submode
Step 3Configure OSPF area in router submode

(config-ospf)#
area area-id
:router(config-ospf)# area 0
:router(config-ospf-ar)#
Step 4Optionally configure area parameters in area submode

(config-ospf-ar)#
If ABR, repeat these steps as necessary for each area in the OSPF instance

Area Types
In Cisco IOS XR software, a normal OSPF area is configured if the area ID
is 0 (the backbone area) or, if the area ID is nonzero, neither the stub nor
nssa commands are used in that area configuration. This type of area
allows external routes to be flooded through the area.
The stub command used in the area configuration submode defines stub
area operation. A stub area does not allow the flooding of external routes
within the area.
____________________________ Note _________________________
All routers with interfaces configured in the area must have the area
configured as a stub area or else adjacencies do not form between
routers within the area.
__________________________________________________________________
The stub no-summary command is used in area configuration submode
on an area border router (ABR) of a stub area, creating what is sometimes
referred to as a totally stubby area. A totally stubby area operates as a
stub area, with the addition that summary routes from other areas are
inhibited at the area border router (ABR). Instead, the ABR floods only a
summary default route into the area.
The nssa command used in area configuration submode defines not-so-
stubby area (NSSA) operation. A not-so-stubby area does not allow the
flooding of external routes originating from other areas, but does allow
external routes to be flooded within the NSSA if they originate from an
autonomous system boundary router (ASBR) within the NSSA.
____________________________ Note _________________________
Similar to stub areas, all routers with interfaces configured in the area
must have the area configured as NSSA.
__________________________________________________________________

Area Types
Normal area (default if not further specified)

(config-ospf-ar)#
Stub area
stub
:router(config-ospf-ar)# stub
Totally stubby area (specified on ABR only)

stub no-summary
:router(config-ospf-ar)# stub no-summary
Not-so-stubby area (NSSA)

nssa
:router(config-ospf-ar)# nssa

Step 5interface Command

Use the interface command from the area configuration mode (prompt:
config-ospf-ar) to associate a specific interface with an OSPF instance
and area. This command places the router in interface configuration mode
(prompt: config-ospf-ar-if), from which you can configure interface-
specific settings.
Step 6Interface Submode Command

Parameters specific to the operation of this OSPF interface, such as cost,
dead interval, hello interval, retransmit interval, and priority can be set
for each interface. They can be set in the router or area configuration
submodes and inherited by the interface or set directly in the interface
configuration submode, thus overriding any settings at a higher level of the
hierarchy.
dead-interval Command
To set the interval after which an adjacency is declared down when no

hello packets are received from a neighbor, use the dead-interval
command. If the dead interval is not set explicitly, it defaults to four times
the hello interval.

Step 5Configure OSPF interface in area submode

(config-ospf-ar)#
interface type instance
:router(config-ospf-ar)# interface GigabitEthernet 0/2/0/3

:router(config-ospf-ar-if)#
Step 6Optionally configure OSPF interface parameters, such as dead

interval, in the interface submode
(config-ospf-ar-if)#
dead-interval seconds
:router(config-ospf-ar-if)# dead-interval 40
Repeat these steps as necessary for each interface in this OSPF area

Network Types
In Cisco IOS XR software, an interface configured for OSPF defaults to a
specific OSPF network type defining adjacency operation with neighbors
on that network. The network command allows you to override the default
OSPF network type.
The broadcast keyword indicates that the attached network supports
data-link broadcast (or multicast) that allows OSPF neighbors to discover
one another without prior knowledge of each others IP addresses. All
Ethernet interfaces (MgmtEth, GigabitEthernet, and TenGigE) default to
OSPF broadcast type.
The non-broadcast keyword indicates that the attached network is full-
mesh, but does not support broadcast [also known as nonbroadcast, multi-
access (NBMA)] such that neighbor addresses must be configured using the
neighbor command. No interfaces default to this network type.
The point-to-point keyword indicates that there are only two routers on
the attached network such that any OSPF packet transmitted out the
interface is sent to the other router. POS interfaces default to OSPF point-
to-point type.
The passive command disables OSPF protocol operation on the interface.
The interface does not send OSPF packets nor does it process any that are
received; no neighbor adjacencies are formed. The attached network is
considered part of the area topology and is identified as a stub network in
the router LSA.

Network Types
network {broadcast | non-broadcast | point-to-point}
Broadcast network (default for Ethernet types)

:router(config-ospf-if)# network broadcast
Nonbroadcast network
:router(config-ospf-if)# network non-broadcast
Point-to-point network (default for POS)

:router(config-ospf-if)# network point-to-point
Passive network
passive [enable | disable]
:router(config-ospf-if)# passive enable

Authentication Types
No authentication of OSPF neighbors is performed unless the
authentication command is used to establish a specific authentication
type. The authentication command can be used in interface configuration
submode for a specific OSPF interface, but could also be used in the area
configuration for all interfaces in that area or in the router configuration to
apply to all interfaces in all areas for that OSPF instance (process).
The authentication null command is normally not necessary (because no
authentication is the default) unless it is being used to override a specific
authentication type established at some higher level of the configuration
hierarchy. For instance, if password authentication was set at the router
level for all interfaces but no authentication was needed on a specific
interface, the authentication null command could be used at the
interface level to override the password authentication setting.
To enable password authentication use the authentication command
with no keyword. The authentication-key command must be used to set
the clear-text password exchanged between neighbors on the interface.
To enable MD5 authentication use the authentication message-digest
command. The message-digest-key command must be used along with
this command to establish keying information for the MD5 operation.
____________________________ Note _________________________
MD5 key-id/key pairs must match between adjacent neighbors for
authentication to succeed. It is not enough for just the keys to match,
because it is the key IDs that are exchanged and not the keys
themselves.
__________________________________________________________________
To more easily manage the rollover of keys and enhance MD5
authentication for OSPF, you can configure a container of keying
information called a keychain. Each keychain entry comprising the
following attributes: generate/accept time, key identification, and key. Use
the keychain keyword and keychain-id to reference the keychain
containing the MD5 keying information. The keychain can be modified at
any time to add or delete keying information without reconfiguring OSPF
usage.
____________________________ Note _________________________
Changes to the system clock can impact the validity of the keys in a
referenced keychain.
__________________________________________________________________

Authentication Types
authentication [message-digest [keychain keychain-id] | null]
Password authentication
authentication-key [clear | encrypted] password
:router(config-ospf-ar-if)# authentication
:router(config-ospf-ar-if)# authentication-key ourpwd
Message digest authentication

message-digest-key key-id md5 [clear | encrypted] key
:router(config-ospf-ar-if)# authentication message-digest

:router(config-ospf-ar-if)# message-digest-key 4 md5 key1
Keychain-based message digest authentication

:router(config-ospf-ar-if)# authentication message-digest
keychain ospf-keychain

The topology and configuration on the opposite page is part of our lab
environment. In subsequent pages of this OSPF section, the PE3 router is
used as the target for examining basic OSPF operation using various CLI
commands.

PE3 P11
.3 192.168.113 .11
10.3.3.3 10.11.11.11
GigE 0/2/0/1
GigE 0/2/0/2
.3
Area 0
192.168.123
P12
.12
10.12.12.12
interface Loopback0
ipv4 address 10.3.3.3 255.255.255.255
!
ipv4 address 192.168.113.3 255.255.255.0
!
ipv4 address 192.168.123.3 255.255.255.0
!
router ospf lab PE3
nsf ietf Configuration
area 0
authentication message-digest
message-digest-key 1 md5 encrypted 01100F175804
interface Loopback0
passive enable
!
!
!
!
!

Examining OSPF Operation

OSPF Status
The show ospf [instance-name] command without other keywords
displays operational information about OSPF instances. If the instance
name is not specified, the command shows information about all OSPF
instances.
For each instance, the first line of output lists the OSPF router ID, with
following lines identifying support for a single type of service (default cost)
route calculation and opaque LSAs [used by MPLS]. Then there are seven
lines containing timer values for SPF calculation and LSA processing,
followed by the configured maximum number of OSPF interfaces. Next
there are counts (Number) for various types of LSAs, number of areas,
and flood list length. Then the output indicates whether or not nonstop
forwarding (NSF) is enabled.
Finally, each configured area is listed along with area-specific information
such as the number of configured OSPF interfaces, the number of times the
SPF calculation has been run on the area topology, various types of LSA
counts, and the flood list length.

Module 8 Examining OSPF Operation
OSPF Status
Display OSPF instance

#
show ospf [instance-name]
:PE3# show ospf lab
Routing Process "ospf lab" with ID 10.3.3.3

NSR (Non-stop routing) is Disabled
Supports only single TOS(TOS0) routes
Supports opaque LSA
Router is not originating router-LSAs with maximum metric
Initial SPF schedule delay 50 msecs
Minimum hold time between two consecutive SPFs 200 msecs
Maximum wait time between two consecutive SPFs 5000 msecs
Initial LSA throttle delay 50 msecs
Minimum hold time for LSA throttle 200 msecs
Maximum wait time for LSA throttle 5000 msecs
Minimum LSA interval 200 msecs. Minimum LSA arrival 100 msecs
LSA refresh interval 1800 seconds
--More--
Flood pacing interval 33 msecs. Retransmission pacing interval

66 msecs
Adjacency stagger enabled; initial (per area): 2, maximum: 64
Number of neighbors forming: 0, 2 full
Maximum number of configured interfaces 255
Number of external LSA 0. Checksum Sum 00000000
Number of opaque AS LSA 0. Checksum Sum 00000000
Number of DCbitless external and opaque AS LSA 0
Number of DoNotAge external and opaque AS LSA 0
Number of areas in this router is 1. 1 normal 0 stub 0 nssa
External flood list length 0
Non-Stop Forwarding enabled
Area BACKBONE(0)
Number of interfaces in this area is 3

Interface Operation
The show ospf interface command displays the operational status of
interfaces configured with OSPF. If not further qualified, it shows all
OSPF interfaces for all OSPF instances.
physical port (up or down) and the status of the datalink protocol running
on that port (up or down). This output is followed by the configured IPv4
address, area, instance (process ID), router ID, network type, cost, and
transmit delay.
Immediately following (at State) is the adjacency state of the interface,
which depends on the network type, protocol state, and current
adjacencies. Then the configured timer values for hello interval, dead
interval, wait, and retransmit interval are listed, followed by the state
(enabled or not) of NSF and how much time remains before the next hello
will be transmitted out this interface.
The next four lines (starting with Index) deal with the state of flood
queues, which is currently not documented for customer use. Following is a
neighbor count and a list of neighbors by router ID. Finally, a count of
neighbors for whom hellos are being suppressed (due to demand circuit) is
shown.

Interface Operation
Display OSPF interfaces

#
show ospf interface [type instance]
:PE1# show ospf interface

[output omitted]
GigabitEthernet0/2/0/1 is up, line protocol is up
Internet Address 192.168.111.1/24, Area 0
Process ID lab, Router ID 10.1.1.1, Network Type BROADCAST, Cost: 1
Transmit Delay is 1 sec, State BDR, Priority 1
Designated Router (ID) 10.11.11.11, Interface address 192.168.111.11
Backup Designated router (ID) 10.1.1.1, Interface address 192.168.111.1
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:05
Index 2/2, flood queue length 0
Next 0(0)/0(0)
Last flood scan length is 2, maximum is 14
Last flood scan time is 0 msec, maximum is 2 msec
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 10.11.11.11 (Designated Router)
Suppress hello for 0 neighbor(s)
Multi-area interface Count is 0

The show ospf neighbor command displays the operational status of
neighbor adjacencies. If not further qualified, it shows all neighbors on all
OSPF interfaces for all OSPF instances.
Each neighbor is listed with its router ID and priority, followed by the
adjacency and neighbor states. Then the time remaining before OSPF
declares the neighbor dead (adjacency down), the neighbors address, and
the local interface associated with this adjacency are displayed. The
following line shows how long this neighbors adjacency has been up.
Adding the detail keyword to the command provides additional
information about each neighbor adjacency, such as area, number of
adjacency state changes, designated router (DR) and backup designated
router (BDR) [only valid on broadcast and nonbroadcast networks], hello
packet options, and retransmission status.

Display OSPF neighbors

#
show ospf neighbor [neighbor-id] [detail]
:PE3# show ospf neighbor
Neighbors for OSPF lab
Neighbor ID Pri State Dead Time Address Inte rface

10.11.11.11 1 FULL/ - 00:00:37 192.168.113.3 gigE 0/2/0/1
Neighbor is up for 00:00:49
Neighbor ID Pri State Dead Time Address Inte rface
10.12.12.12 1 FULL/ - 00:00:38 192.168.123.3 gigE 0/2/0/2
Neighbor is up for 17:25:59
Total neighbor count: 2

Border Gateway Protocol (BGP)

Feature Support
Cisco IOS XR multiprotocol BGP is enhanced to convey prefix information
for IPv4 and IPv6 along with their VPN extensions. The BGP software
peers only with other routers running BGPv4, which is the current de facto
Internet Exterior Gateway Protocol (EGP) standard.
Graceful restart allows BGP peers to avoid changes to their forwarding
paths following a route processor (RP) switchover or BGP instance restart.
Routers capable of graceful restart exchange this capability in their OPEN
messages when establishing a peer session.
Routers capable of outbound route filter (ORF) exchange inbound prefix
lists over a peer session and pre-filter advertised routes against the
contents of the received list. This feature potentially saves bandwidth and
processing, because less routing information may be sent between the
routers.
A neighbor-based, hierarchical command-line interface (CLI) is used to
configure BGP. Grouping of BGP neighbor configuration makes the overall
BGP configuration more intuitive and more easily viewed. All BGP
parameters can be viewed by simply displaying the BGP configuration.
To simplify configuration of multiple neighbors with similar
characteristics, template groups 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, with only a subset of those families for a specific neighbor.
Route policies written in the Routing Policy Language (RPL) are used to
filter and modify BGP routes. External BGP (eBGP) neighbors must have
both inbound and outbound policies configured. If no policies are
configured, no routes are accepted, nor are any routes advertised. This
default behavior is intended to prevent routes from being accepted or
advertised without specific configuration. For internal (iBGP) BGP
neighbors, the default behavior is to advertise and accept all routes, if
there are no policies specifically configured.
BGP update message generation is dynamically calculated by an algorithm
that sorts neighbors into update groups based on common outbound route
policies. No configuration of update groups is required.

Module 8 Border Gateway Protocol (BGP)
Feature Support
BGP (v4 only) with extensions

Multiprotocol
! IPv4 unicast/labeled unicast/multicast/tunnel/mdt, VPNv4 unicast
! IPv6 unicast/labeled unicast/multicast, VPNv6 unicast
Route refresh and graceful restart
Outbound route filter (ORF)
TCP MD5 authentication
Hierarchical neighbor-based configuration CLI
show running-config router bgp
Template groups to reduce configuration size
No default address family
Inbound and outbound route policies required for eBGP
Dynamic update groups based on common outbound route
policies


Cisco IOS XR software implements a hierarchical CLI configuration
structure that groups all BGP configuration commands with 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
configurations from another group of the same type through the use
command.
EXEC mode show commands can display the inherited configuration of
neighbors along with the inherited group names.

Module 8 Border Gateway Protocol (BGP)
Hierarchical BGP configuration with explicit inheritance
router bgp
(config-bgp)
af-group session-group
(config-bgp-afgrp) (config-bgp-sngrp)
address-family neighbor neighbor-group

(config-bgp-af) (config-bgp-nbr) (config-bgp-nbrgrp)
address-family address-family
(config-bgp-nbr-af) (config-bgp-nbrgrp-af)
Example BGP configuration session using template

groups
:router(config)#router bgp 65000
:router(config-bgp)#neighbor 10.2.2.2
:router(config-bgp-nbr)#remote-as 65000
:router(config-bgp-nbr)#use neighbor-group neighbor1
:router(config-bgp-nbr)#address-family ipv4 unicast
:router(config-bgp-nbr-af)#use af-group family4u

Configuring iBGP
BGP is enabled from global configuration mode (prompt: config).
Step 1router Command

Use the router bgp autonomous-system-number command to enable BGP
routing and place the CLI in router configuration mode (prompt: config-
bgp).
____________________________ Note _________________________

Only a single instance of BGP may be configured for each SDR.
__________________________________________________________________
Step 2bgp router-id and Other Submode Commands

To configure a router ID for BGP, use the bgp router-id command in
router configuration mode. Although the BGP router ID is not required to
be a valid IPv4 address, it is specified using the dotted-decimal notation.
For BGP peering sessions to be established, BGP must be assigned a router
ID. The router ID is sent in the BGP OPEN message when a peering
session is established. BGP attempts to obtain a router ID in the following
order of preference:
By means of the bgp router-id command.
By using the highest IPv4 address on a loopback interface if the router
is booted with a saved loopback address configuration.
By using the primary IPv4 address of the first loopback address that
gets configured if there are no IPv4 addresses in the saved
configuration.
If none of these methods for obtaining a router ID succeeds, BGP cannot
establish any peering sessions with neighbors. An error message is entered
in the system log, and the show bgp summary command displays an
invalid router ID of 0.0.0.0.

Module 8 Configuring iBGP
Step 1Configure iBGP instance in global configuration mode

(config)#
router bgp autonomous-system-number
:router(config)# router bgp 65000

:router(config)#
Step 2Optionally configure BGP router ID and other router parameters

in router submode
(config-bgp)#
bgp router-id ipv4-address
:router(config-bgp)# bgp router-id 10.1.1.1

After BGP has obtained a router ID, it continues to use it even if a better
router ID becomes available. This usage avoids the flapping of BGP
sessions, which occurs when changing a BGP router ID. However, if the
router ID currently in use becomes invalid (because its configuration is
changed), BGP selects a new router ID (using the rules described) and all
established peering sessions are reset.
Other parameters specific to the general operation of BGP are set directly
in router configuration submode. Commands exist to customize the
operation of BGP for optional functions such as route reflection,
confederations, graceful restart, and route dampening. With others you can
originate a default route using redistribution, set the Multi Exit
Discriminator (MED) on routes that do not have one, and adjust the
default keepalive and hold timers for neighbor peer sessions.

router Command and Submode (Cont.)
Step 1Configure iBGP instance in global configuration mode

(config)#
router bgp autonomous-system-number
:router(config)# router bgp 65000

:router(config)#
Step 2Optionally configure BGP router ID and other router parameters

in router submode
(config-bgp)#
bgp router-id ipv4-address
:router(config-bgp)# bgp router-id 10.1.1.1

Step 3Router address-family Command

Use the address-family command in router configuration submode to
enable the specified address family and enter router address family
configuration submode. The address families supported for configuration
are:
IPv4 unicast
IPv4 multicast
IPv4 tunnel
IPv4 multicast distribution tree (MDT)
IPv6 unicast
IPv6 multicast
VPNv4 unicast
VPNv6 unicast
An address family must be explicitly configured in router configuration
mode for the address family to be active in BGP.
Step 4Router Address Family Submode Commands

Parameters specific to the routing of IPv4 and IPv6 prefixes for BGP, such
as administrative distance (for external, internal, and local BGP routes),
maximum number of parallel paths per prefix, and local networks
advertised by BGP, are set directly in the router address family
configuration submode.

Router address-family Command and Submode
Step 3Configure router address family in router submode
(config-bgp)#
address-family ipv4 {unicast | multicast | tunnel | mdt}
address-family ipv6 {unicast | multicast}
address-family {vpnv4 | vpnv6} unicast
:router(config-bgp)# address-family ipv4 unicast

:router(config-bgp-af)#
Step 4Optionally configure parameters in router address family submode

(config-bgp-af)#

Step 5neighbor Command

To enter neighbor configuration mode for configuring BGP peer sessions,
use the neighbor ip-address command in BGP router configuration mode.
The IP address specified will be used as the remote end of the TCP
connection supporting the peer session.
Step 6remote-as and Other Neighbor Submode Commands

The neighbor command alone 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.
Alternatively, the neighbor configuration can inherit a remote autonomous
system number from a neighbor group or session group through the use
command. For an iBGP neighbor, the remote autonomous-system-number
is the same as the local AS.
____________________________ Note _________________________
In addition to configuring the neighbors AS number, at least one
common address family must be configured using the address-family
command in both the neighbor and router configuration.
__________________________________________________________________
Other commands specific to the peer session such as update source (local
end of TCP connection supporting the peer session), timer values (keep
alive, hold, and minimum advertisement interval), MD5 password (secret),
text description, and shutdown state can also be set in the neighbor
configuration submode.
description Command
The description text command is used to annotate the neighbor

configuration and has no affect on BGP behavior. We recommend that the
text be used to identify the neighbor in some manner that is operationally
useful.

neighbor Command and Submode
Step 5Configure iBGP neighbor in router submode

(config-bgp)#
neighbor ip-address
:router(config-bgp)# neighbor 10.3.3.3

:router(config-bgp-nbr)#
Step 6Configure neighbor AS (same as local for iBGP) and optionally other
parameters like description in neighbor submode
(config-bgp-nbr)#
remote-as autonomous-system-number
:router(config-bgp-nbr)# remote-as 65000

:router(config-bgp-nbr)# description PE3 router

Step 7Neighbor address-family Command

Use the address-family command in neighbor configuration submode to
activate the specified address family and enter neighbor address family
configuration submode. The supported address families for neighbors are:
IPv4 unicast
IPv4 multicast
IPv4 labeled unicast
IPv4 tunnel
IPv4 multicast distribution tree (MDT)
IPv6 unicast
IPv6 multicast
IPv6 labeled unicast
VPNv4 unicast
VPNv6 unicast
It is not necessary to have an address family configured in router
configuration mode for either an IPv4, IPv6, or VPNv4 neighbor to be
configured. However, to be able to configure an address family under a
neighbor, generally the same address family must be configured in router
configuration mode. The only exception to this is the IPv4 and IPv6 labeled
unicast neighbor address families which cannot be configured as a router
address family. Instead, they require the corresponding IPv4 or IPv6
unicast address families to be configured as a router address family.
Step 8Neighbor Address Family Submode Commands

Parameters specific to the routing of IPv4 and IPv6 prefixes for a specific
neighbor such as the maximum number of received prefixes, setting routes
next hop to local address, and assigning weight attribute to received routes
are set directly in the neighbor address family configuration submode.

Neighbor address-family Command and Submode
Step 7Configure neighbor address family in neighbor submode

(config-bgp-nbr)#
address-family ipv4 {unicast | multicast | labeled-unicast | tunnel | mdt}

address-family ipv6 {unicast | multicast | labeled-unicast}}
address-family {vpnv4 | vpnv6} unicast
:router(config-bgp-nbr)# address-family ipv4 unicast

:router(config-bgp-nbr-af)#
Step 8Optionally configure parameters in neighbor address family submode
(config-bgp-nbr-af)#
Repeat Step 5 through Step 8 for all routers in local AS (iBGP neighbors)

Configuration Template Groups

The af-group, session-group, and neighbor-group configuration
commands are entered under the router configuration submode and
provide dynamic template support for the neighbor configurations in
Cisco IOS XR software. A neighbor inherits the configuration from any
group type by way of the use command. If the group configuration is
modified, all neighbor configurations using that group are dynamically
updated when the group change is committed.
The af-group command groups neighbor family-specific commands within
an IPv4, IPv6, or VPNv4 address family. Neighbors having the same
address family configuration are able to use the address family group for
their address family-specific configuration. By default, the neighbor
inherits the entire configuration from the address family group. However,
commands explicitly configured in the neighbor address family
configuration override conflicting commands from the address family
group.
The session-group command groups address family-independent
commands (those from neighbor configuration submode). Neighbors can
use the session group for their address family-independent configuration.
By default, the neighbor inherits the entire configuration from the session
group. However, commands explicitly configured in the neighbor
configuration override conflicting commands from the session group.
The neighbor-group command allows you to apply the same
configuration to one or more neighbors. Neighbor groups can inherit from
session groups and address family groups to compose the complete
configuration for a neighbor. Neighbor groups can inherit from other
neighbor groups, as well. If a neighbor is configured to use a neighbor
group, the neighbor inherits the entire BGP configuration of the neighbor
group. However, commands explicitly configured in the neighbor or
neighbor address family configuration override conflicting commands from
the neighbor group.

Configuration Template Groups
Dynamic template support for neighbor configuration

Group commands for configuring multiple neighbors
Three configuration group types:
Address family group (af-group)
! All neighbor address family submode commands
Session group (session-group)
! All neighbor submode commands
Neighbor group (neighbor-group)
! All neighbor and neighbor address family submode commands

neighbor-group Command and Submode

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 in neighbor configuration
mode. 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 address family-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 Command and Submode
Optionally configure a neighbor group in router submode

and apply it in a neighbor configuration
(config-bgp)#
neighbor-group neighbor-group-name
:router(config-bgp)# neighbor-group internal

:router(config-bgp-nbrgrp)# remote-as 65000
:router(config-bgp-nbrgrp)# password cisco
:router(config-bgp-nbrgrp)# update-source loopback0
:router(config-bgp-nbrgrp)# address-family ipv4 unicast
:router(config-bgp-nbrgrp-af)# exit
:router(config-bgp-nbrgrp)# exit
:router(config-bgp)# neighbor 10.3.3.3
:router(config-bgp-nbr)# use neighbor-group internal

The topology and configuration on the opposite page is part of the courses
lab environment. In subsequent pages of this module, the PE3 router is
used as the target for examining basic BGP operation using various CLI
commands.
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.

PE3 P11
.3 192.168.113 .11
10.3.3.3 10.11.11.11
gigE 0/2/0/1
gigE 0/2/0/2
.3
AS 65000
192.168.123
P12
.12
10.12.12.12
TCP connection/BGP session
interface Loopback0
ipv4 address 10.3.3.3 255.255.255.255
!
interface gigE 0/2/0/1
ipv4 address 192.168.113.3 255.255.255.0
!
interface gigE 0/2/0/2
ipv4 address 192.168.123.3 255.255.255.0
!
router bgp 65000
! PE3
neighbor-group internal
remote-as 65000 Configuration
password encrypted 121A0C041104
update-source Loopback0
!
!
neighbor 10.11.11.11
use neighbor-group internal
description P11 router
!
neighbor 10.12.12.12
use neighbor-group internal
description P12 router
!
!

Examining BGP Operation

Effective Configuration
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 is 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.

Module 8 Examining BGP Operation
Effective Configuration
Display effective neighbor configuration and inheritance

#
show bgp neighbors [address] [configuration | inheritance]
:PE3# show bgp neighbors 10.1.1.1 configuration

neighbor 10.1.1.1
remote-as 65000 [n:internal]
password encrypted 121A0C041104 [n:internal]
update-source Loopback0 [n:internal]
address-family ipv4 unicast [n:internal]
:PE3# show bgp neighbors 10.1.1.1 inheritance

Session: n:internal
IPv4 Unicast: n:internal
Legend:
[!] inherited from
n:<group> neighbor group
s:<group> session group
a:<group> address family group

BGP and Neighbor Status

The show bgp summary command displays general information about
the BGP process and neighbor sessions.
The first section starts with the BGP router ID and local autonomous
system number followed by the generic scan interval. Next is the main
routing table version, indicating the latest version of the BGP database
injected into the main routing table. Then the current scan interval is
listed followed by the operating mode, which is either STANDALONE or
DISTRIBUTED.
The next section identifies the BGP process, which for standalone mode is
always Speaker, followed by various table versions (RcvTblVer,
bRIB/RIB, SendTblVer, and TblVer). The table versions provide an
indication of whether or not BGP is up to date.
bRIB/RIB < RecvTblVerSome received routes have not yet been
considered for installation in the global routing table.
TblVer < SendTblVerSome received routes have been installed in the
global routing table but have not yet been considered for advertisement
to this neighbor.
The last section contains information about neighbor sessions. Each
configured neighbor is identified by BGP router ID followed by a speaker
ID, which is always 0 (Speaker process) unless Distributed BGP is
configured, and the neighbors autonomous system number. Then there are
counts for BGP messages received (MsgRcvd) and sent (MsgSent), followed
by the version of the BGP table that was last sent to the neighbor. Counts
for received messages waiting to be processed (InQ) and messages waiting
to be sent (OutQ) are listed next. Generally, these are 0 unless the inter-AS
topology is rapidly changing or the neighbor session is just coming up. Next
is the length of time (in days and hours, hours and minutes, or minutes
and seconds) that the BGP session has been in the established state, or the
length of time since the session left the established state. Listed last is the
state of the neighbor session (St) if not established or the number of
prefixes received (PfxRcd) if established.

BGP and Neighbor Status
Display summary of BGP and neighbor status

#
show bgp summary
:PE3# show bgp summary

BGP router identifier 10.3.3.3, local AS number 65000
BGP generic scan interval 60 secs
BGP table state: Active
Table ID: 0xe0000000
BGP main routing table version 1
BGP scan interval 60 secs
BGP is operating in STANDALONE mode.
Process RecvTblVer bRIB/RIB LabelVer ImportVer SendTblVer StandbyVer

Speaker 1 1 1 1 1 1
Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd

10.1.1.1 0 65000 2607 2608 1 0 0 1d19h 0
10.2.2.2 0 65000 2600 2600 1 0 0 1d19h 0
2011, Cisco Systems, Inc. All rights reserved. Version 4.0.1 Cisco IOS XR CommonModule 0/64

Peer Session Operation

The show bgp neighbors ip-address command displays detailed
information about a neighbor session. If a neighbor ip-address is not
specified, information about all neighbors is shown. The output of this
command is highly variable, depending on the configuration of the
neighbor and address families supported on the session. Any configured
optional capabilities such as route reflectors, confederations, and others
add additional lines of output. The example on the facing page represents a
minimal neighbor configuration.
The first section of output details address family-independent status
information starting with the IPv4 address of the neighbor, the
autonomous system of the neighbor (remote AS), the local autonomous
system number, and whether the connection is internal (iBGP) or external
(eBGP). Any description from the neighbor configuration is shown followed
by the neighbors router ID, along with the state of the BGP session and its
duration (days and hours, hours and minutes, or minutes and seconds).
Then capabilities (route refresh, address families) advertised to the
neighbor and received from the neighbor are listed. Next are counts of BGP
messages received from the neighbor and processed, notifications received,
and messages received (in queue) but not yet processed. Then are listed
counts of BGP messages sent to the neighbor, notifications sent, and
messages waiting (in queue)to be sent. Last, the minimum advertisement
interval (in seconds) for this neighbor is listed.
Subsequent sections detail address family-dependent information starting
with the specific address family name, followed by the last version of the
BGP database that was sent to the neighbor and the update group to which
the neighbor belongs. Then, because the route refresh capability is always
supported, the number of route refresh requests sent and received from
this neighbor is listed. Except in the case of iBGP, inbound and outbound
route policies are required; if configured, their names are listed next. Then
the number of prefixes accepted from the neighbor is listed and how many
are selected as bestpaths. They are followed by the number of prefixes
advertised to the neighbor, the number suppressed (eBGP only), the
number advertised as no longer reachable (withdrawn), and the
maximum number of prefixes that may be received from the neighbor. The
address family section ends with the percentage of maximum prefixes at
which a warning message is generated.
The last section of output lists the number of times the router has
established a BGP peering session with the neighbor and the number of
times that a good connection has failed or been taken down (dropped).
The last reset time and reason are listed next and, if a BGP notification
was issued, the notification error code.

Peer Session Operation
Display BGP neighbor session

#
show bgp neighbors [ip-address]
:PE3# show bgp neighbors 10.1.1.1
BGP neighbor is 10.1.1.1, remote AS 65000, local AS 65000, internal link

Description: P1 router
Remote router ID 10.1.1.1
BGP state = Established, up for 1d18h
Last read 00:00:38, hold time is 180, keepalive interval is 60 seconds
Neighbor capabilities:
Route refresh: advertised and received
Address family IPv4 Unicast: advertised and received
Received 2573 messages, 0 notifications, 0 in queue
Sent 2573 messages, 0 notifications, 0 in queue
Minimum time between advertisement runs is 5 seconds
--More--
For Address Family: IPv4 Unicast

BGP neighbor version 1
Update group: 0.1
Route refresh request: received 0, sent 0
0 accepted prefixes, 0 are bestpaths
Prefix advertised 0, suppressed 0, withdrawn 0, maximum limit 524288
Threshold for warning message 75%
Connections established 1; dropped 0

Last reset 1d21h, due to BGP neighbor initialized

Summary
Routing Protocols
Describe IS-IS, OSPF, and BGP features in Cisco IOS XR software

Configure basic IS-IS, OSPF, and iBGP functionality
Examine basic IS-IS, OSPF and BGP operation

Module 9
Routing Policy Language
Overview
Description
This module teaches the basics of the Routing Policy Language (RPL). It
describes RPL architecture and defines syntax. A methodology to convert
route maps to RPL policies is also illustrated.
Objectives
Define RPL sets and policies
Describe hierarchical and parameterized policies

Construct sets and simple hierarchical policies
Convert route maps to RPL policies

Routing Policy Language Module 9
RPL Overview
Background
The Routing Policy Language (RPL) has been designed to provide a single,
straightforward language in which all routing policy needs can be
expressed. 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. In
a large scale service provider environment the router could possibly need
support for thousands of route maps with their implied redundancy.
RPL was developed to support large-scale routing configurations. It greatly
reduces the redundancy that is inherent in previous Cisco IOS routing
policy configuration methodsroute 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 system
resources required to store and process these configurations, and simplify
troubleshooting.

Module 9 RPL Overview
Background
The Routing Policy Language (RPL) was

developed to support large-scale routing
configurations
Using route-maps in a service provider network could lead
to configurations on the order of several 100k to over a
million lines depending on the number of BGP peers.
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 Cisco IOS route map and 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.
Neither looping nor recursion within a hierarchical policy structure is
allowed. That is, a policy block may not apply itself directly or indirectly
through another policy block that it applies.
Another fundamental capability is that common blocks of policy can be
parameterized. This allows for policies that share the same logical
structure but differ in the specific route attribute values that are set or
matched against to be maintained as independent blocks of policy.
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.

Fundamental Capabilities
Modularization
Common blocks of policy
Defined and maintained independently
Apply from other blocks to build complete policies
Looping/recursion is not allowed
Parameterization
Same logical policy structure but different matched or
set route attribute values
Value passed as parameter by applying block
Parameters can be passed through a policy block
As many layers of hierarchy or parameters as needed

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 that other configurations are committed and may be
displayed using the normal configuration show commands.
Policy RepositoryCompiles created or modified policies into a form
that the execution engine can understand. During this process it
verifies 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 engineIs responsible for running policies as
requested by the policy client. It can be thought of as receiving a route
from a policy client and executing the policy against the specific route
data.
Policy clients (the routing protocols)Call the policy execution
engine at the appropriate times to have a given policy applied to a
specific route and then carry 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
Compile policies for execution

Verify policies
Track and manage client/policy use
Policy configuration Policy Repository Execution Engine
CLI
Editor
Syntax check
filter
attach routes
policies
Clients
(protocols)

RPL Description
Basic Building Blocks
The policy language provides two kinds of persistent, namable objects: sets
and policies. Legal names for these objects can be any sequence of the
upper and lowercase alphabetic characters; the numerals 09; and the
punctuation characters period, hyphen, and underbar. A name must begin
with a letter or numeral.
There are five kinds of sets: AS path, community, extended community,
prefix and route distinguisher set.
Definition of sets and policies is bracketed by beginning and ending

command lines in standard CLI syntax.
For example:
route-policy name
[ . . . Policy statements . . . ]
end-policy
or:
prefix-set name
[ . . . Prefix set elements . . . ]
end-set

Module 9 RPL Description
Basic Building Blocks
Route Policy
Language
route-policy name
[policy statements] Route Policies Policy Sets
end-policy
Extended Route
Community
AS Path Sets Community Prefix Sets Distinguisher
Sets
Sets Sets
as-path-set name community-set name prefix-set name
[set elements] [set elements] [set elements]
end-set end-set end-set

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 applied, setting the Multi Exit Discriminator
(MED) attribute to 100 in any BGP route processed by policy two.
Continuing execution of policy two sets the community to 10:100. This is an
example of a hierarchical policy.
____________________________ Note _________________________
You may have as many levels of hierarchy as you want; there is no
arbitrary limit. However, many levels of hierarchy may be difficult to
maintain and understand. Because policy application is dynamic, changes
to one policy affect all those policies that reference it directly or indirectly.
__________________________________________________________________

Hierarchical Policy
A policy that is referenced by another policy with an

apply statement:
route-policy one
set med 100
end-policy
route-policy two
apply one
set community (10:100)
end-policy

Parameterized Policy
In addition to supporting reuse of policy blocks using the apply statement,
you can also define policies that allow for parameterization of some of the
attributes. The trivial example on the facing page contains a
parameterized policy one which takes one parameter, $medval.
Parameters always begin with a dollar sign, followed by 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 logical structure but
use different values in some of their individual statements can be
implemented as a common module.

Parameterized Policy
A hierarchical policy that receives passed values:
route-policy one ($medval)

set med $medval
end-policy
route-policy two
apply one (10)
end-policy
route-policy three
apply one (20)
end-policy

Global Parameters
RPL supports the definition of systemwide global parameters that can be
used inside policy definition. Global parameters are configured as follows:
policy-global
glbpathtype `ebgp'
glbtag `100'
end-global
The global parameter values can be used directly inside a policy definition
similar to the local parameters of parameterized policy. In the following,
the global parameters gbpathtype and glbtag are used by the tagpath
policy.
route-policy tagpath
if path-type is $glbpathtype then
set tag $glbtag
endif
end-policy
When the name of a parameter passed into policy conflicts with a global
parameter name, the local parameter takes precedence effectively masking
off the conflicting global parameter. Global parameters are also prevented
from being deleted if the name is referred to in any policy.

Global Parameters
Parameters can be defined for use in all policies:
policy-global
glbpathtype ebgp
glbtag 100
end-global
route-policy tagpath
if path-type is $glbpathtype then
set tag $glbtag
end-policy

Sets
In an RPL 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.
Named sets are defined at global configuration level and referenced from
conditionals within policy definitions. The named sets are defined using
as-path-set, community-set, extcommunity-set, prefix-set and rd-set
type statements. The set elements are bracketed between the set type
statement and an end-set statement, with set elements separated by
commas:
prefix-set pfset1
10.1.1.0/24,
10.2.2.0/24
end-set
The inline set form is a parenthesized list of comma-separated elements

contained in a conditional:
(10.1.1.0/24, 10.2.2.0/24)
This inline set above matches exactly the same prefixes as the named set
pfset1, 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.
____________________________ Note _________________________
Null (empty) sets such as:
prefix-set backup
# currently no routes are defined
end-set
are allowed but any route matched against it evaluates as FALSE.

__________________________________________________________________

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 five kinds of sets: as-path-set, community-set,
extcommunity-set, prefix-set and rd-set.
There are two forms for set definition: named form and inline
form.
Named set form example:

prefix-set pfset1
10.1.1.0/24,
10.2.2.0/24
end-set
Inline set form example:

(10.1.1.0/24, 10.2.2.0/24)

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 _________________________
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 supported only 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
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 matches only one possible value,
10.0.1.1/32 or the host address 10.0.1.1. The second element matches only
one possible value, 10.0.2.0/24. The third element matches a range of prefix
values, from 10.0.3.0/28 to 10.0.3.255/32. The fourth element matches 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 matches 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
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. 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. To summarize:
minimum length ! maximum length ! 32 (for IPv4)
128 (for IPv6)
In most circumstances, the minimum length will be equal to or greater
than the mask length, however, if both the minimum and maximum
lengths are specified, they may be less than the mask length. In this case,
the specification matches a discontiguous range of prefixes with the exact
mask length. For example 10.0.7.2/32 ge 16 le 24 matches the prefixes
10.0.[0...255].2/32 and 10.0.8.0/26 ge 8 le 16 matches 10.[0...255].8.0/26.

Prefix Set (Cont.)
Legal prefix specifications:

prefix-set LEGAL
10.0.1.1,
10.0.2.0/24,
10.0.3.0/24 ge 28,
10.0.4.0/24 le 28,
10.0.5.0/24 ge 26 le 30,
10.0.6.0/24 eq 28
end-set
Illegal prefix specifications:

prefix-set ILLEGAL
10.1.1.1 ge 16,
10.1.2.1 le 16,
10.1.3.0/24 le 23,
10.1.4.0/24 ge 33,
10.1.5.0/25 ge 29 le 28
end-set

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$')
The two regular expressions in this set match an AS path originating in
either AS 42 or AS 127.

AS Path Set
An as-path-set holds regular expressions for matching

against the BGP AS path attribute.
as-path-set aset1
ios-regex _42$,
ios-regex _127$
end-set

Community Set
A community-set holds community values for matching against the BGP
community attribute. Each 32-bit community value is expressed as two 16-
bit unsigned decimal integers in the range 0 to 65535, separated by a colon.
The inline form of a community-set supports parameterization. Each 16-bit
portion of the community may be parameterized:
$as:34
12:$tag1
$as:$tag1
The language 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.
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:
123:*
*:68
A range of values can be set in either or both halves of the community.

Range specifications are entered as [low-value..high-value]. The following
are valid range specifications:
10:[100..1000]
[10..100]:80
[10..100]:[100..2000]
In addition, the private-as symbolic name may be used to specify the

range from 64512 to 65534.
Regular expressions are specified as the ios-regex keyword followed by a
valid single-quoted regular expression string such as:
ios-regex '_10:[0-9]0_'

Community Set
A community-set holds community values for

operations on the BGP community attribute. A
community is a 32-bit quantity expressed as two
unsigned decimal integers in the range 0 to 65535,
separated by a colon. Wildcards, ranges (..), and
regular expressions are also allowed for matching.
community-set cset1
12:34,
15:*,
internet,
private-as:33,
[200..206]:68,
ios-regex _10:[0-9]0_
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 or else
In its simplest form, an if statement uses a conditional expression to
decide which actions or dispositions should be taken for the given route.
For example:
if as-path in as-path-set-1 then
drop
endif
The previous 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 applied 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
else
endif

Conditional Statements
An if statement uses a conditional expression to decide which

actions or dispositions should be taken for the given route.
if as-path in as-path-set-1 then
drop
endif
The if statement also permits an else or elseif clause, which is

applied if the conditional expression is false and allows
cascading of tests for different values.
if med eq 150 then
elseif med eq 200 then
else
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
endif
The previous policy example sets the value of the local-preference attribute
to 100 on any route that has a community value of 12:34 or 56:78
associated with it. However, any of those routes that also have a MED
value of 8 are dropped.

Nested Conditionals
The statements within an if statement may themselves

be if statements, as shown in the following:
if community matches-any (12:34, 56:78) then

if med eq 8 then
drop
endif
endif

Boolean Conditions
In the previous section, describing conditional if statements, all of the
examples used simple Boolean conditions that evaluated as 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
is true if and only if the value of the MED in the route is 42; otherwise, it is
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 parentheses 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 subconditions more

readable, or they may force the evaluation of a subcondition as a unit. In
the following example, the highest-precedence NOT operator applies only
to the destination test. The AND combines the result of the NOT
expression with the MED test, and the OR combines that result with the
community test.
med eq 10 and not destination in (10.1.3.0/24) or community
matches-any (56:78)
With a set of parentheses to express the precedence, the result is the

following:
(med eq 10 and (not destination in (10.1.3.0/24)) or community
matches-any (56:78)
Parentheses are more likely to be used to force the evaluation differently

than the normal precedence would do:
med eq 10 and (not destination in (10.1.3.0/24) or community
matches-any (56:78))
The following is another example of a complex expression:

(origin is igp or origin is incomplete or not med eq 42) and
next-hop in (10.0.2.2)
The left-hand conjunct is a compound condition enclosed in parentheses.

The compound condition is evaluated to test whether the BGP route origin
is IGP or incomplete, or the MED is not 42. If any of these conditions are
true and the routes next hop is 10.0.2.2, then the entire compound
condition is true; otherwise, the compound condition is false.

Compound Conditions
Boolean operator precedence from highest to lowest

is: negation (not), conjunction (and), and disjunction
(or). Parentheses may be used to force the evaluation
differently than the normal operator precedence.
For example
med eq 10 and not destination in (10.1.3.0/24) or community is (56:78)
is evaluated differently than

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

Drop Condition
All route policies have a default action to drop a route under evaluation
unless it is accepted. In RPL, this is determined when the route is modified
(such as set) or explicitly accepteded (pass or done). If policy execution
reaches a drop or done statement, it is stopped unlike what happens with
the pass command after which execution continues.
Applied (hierarchical) policies implement this drop condition behavior as
though the applied policy were pasted into the point where it is applied. As
an example, consider a policy to allow all routes in the 10 net and set their
local-preference to 200 while dropping all other routes:
route-policy two
if destination in (10.0.0.0/8 ge 8 le 32) then
endif
end-policy
route-policy one
apply two
end-policy
At first it may seem that policy one will drop all routes because it neither
contains an explicit pass statement nor modifies a route attribute.
However, because the applied policy two does set an attribute, the net
result is that policy one passes 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
endif
end-policy

Drop Condition
RPL applies a default drop condition to a policy

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 or done statement
Execution of a drop or done statement stops
policy evaluation unlike the pass statement

Attribute Value Determination

Policy execution does not modify the attributes of a route during
evaluation. 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.
Example:
set med 42
if med eq 42 then
drop
endif
This example drops only routes that originally had the MED set to 42; all
other routes will have their MED set to 42. A route that had an initial
MED of 15 will have its MED set to 42 upon exiting evaluation 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.
No cascading effect from intermediate attribute
modification
Actual route attributes are not modified until
policy processing is complete
Which routes are dropped?
set med 42
if med eq 42 then
drop
endif

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 routing protocols has attributes that can be referenced in RPL
conditionals or operated on. There are also some attributes specific to Cisco
associated with routes internal to Cisco IOS XR software.

Route Attributes and Operations
Attribute/Operation BGP OSPF IS-IS EIGRP RIP

as-path C/A
community C/A
destination C C C C C
ext[ended]community C/A
eigrp-metric A
isis-metric A
local-preference A
med C/A
metric-type A A
ospf-metric A
rip-metric A
route-type C C C
C Conditional A Action
* This table is not a complete list of available attributes

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
Border Gateway Protocol (BGP), there are several places in which policies
can be used; the most common of these is in defining neighbor import and
export policy:
neighbor ip-address
route-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
instance behavior, in this case a BGP neighbor peer session, and a specific
named policy.
A verification step happens each time a policy is attached and whenever a
policy that is already attached is modified. The verification ensures that
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, because BGP routes do not carry IS-IS attributes.

Attach Point
Any location (usually in a protocol entity) that binds

the use of a named policy for a specific purpose:
neighbor 10.3.3.3
route-policy policyA in
route-policy policyB out

Protocol Attach Points

When a policy is attached to a protocol, the protocol checks the policy to
ensure the policy operates using route attributes known to the protocol. If
the policy uses incompatible attributes, then the protocol rejects the
attachment. For example, BGP rejects a policy that tests the value of
OSPF metrics at the neighbor inbound attach point because routes from
a BGP neighbor can not have OSPF attributes.
The situation is made more complex at the redistribute attach point by
the fact that each protocol potentially has access to another protocols
routes through the RIB, which is the common central representation. An
attach point dealing with two different kinds of routes permits a mix of
operations: matching against the RIB or the other protocols attributes and
setting the local protocols attributes.

Protocol Attach Points
Attach Point BGP OSPF IS-IS EIGRP RIP

Default allowed in/out X
Default originate X X X X
Global inbound/outbound X X
Interface inbound/outbound X X
Neighbor inbound/outbound X
Network X
Redistribute X X X X X
Show bgp X
* This table is not a complete list of available attach points

Converting Route Maps to RPL Policies

In Cisco IOS XR software, route maps are deprecated functionality having
been replaced by RPL-based route policies. New route filtering capabilities
will only appear in RPL and, in some future release, route map support
will be removed. So it is prudent to consider converting any existing route
maps into an equivalent set of RPL policies.
In the example following in this section, we will use a straightforward
methodology leading to the translation of a route map to an RPL policy.
Each step beyond the first progressively reduces the amount of
configuration needed to achieve the same policy behavior.
We will use the following methodolgy 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 inline 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
contains 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 9 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 methodology:
1. Do a simple (direct) syntax translation
2. Nest conditionals to reduce repetitive comparisons
3. Use inline sets to remove small named set references
4. Parameterize common policy structures for reuse

Initial 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 be used only 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.

Initial Route Map Configuration
ip prefix-list 101
10 permit 10.48.0.0/16 le 32
20 permit 172.48.0.0/19
30 permit 192.168.3.0/24
ip prefix-list 102
10 permit 172.16.10.0/24
20 permit 192.168.8.0/21
30 permit 192.168.32.0/21
ip community-list 1
10 permit 10:11
ip community-list 2
10 permit 10:12
ip community-list 3
10 permit 10:13
ip community-list 4
10 permit 10:14
route-map sample1 permit 10 route-map sample2 permit 10

match ip address prefix-list 101 match ip address prefix-list 102
match community 1 match community 1
set metric 11 set metric 11
set community 12:34 additive set 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
Convert the prefix and community lists

to their equivalent RPL set notation. prefix-set ps101
10.48.0.0/16 le 32,
ip prefix-list 101 172.48.0.0/19,
10 permit 10.48.0.0/16 le 32 192.168.3.0/24
20 permit 172.48.0.0/19 end-set
30 permit 192.168.3.0/24
prefix-set ps102
ip prefix-list 102 172.16.10.0/24,
10 permit 172.16.10.0/24 192.168.8.0/21,
20 permit 192.168.8.0/21 192.168.32.0/21
30 permit 192.168.32.0/21 end-set
ip community-list 1 community-set cs1

10 permit 10:11 10:11
end-set
10 permit 10:12 10:12
end-set
10 permit 10:13 10:13
end-set
10 permit 10:14 10:14
end-set

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 these route map configurations still
retains any redundant operations.

Direct Translation (Cont.)
route-map sample1 permit 10 Convert the first route map to a RPL route-
match ip address prefix-list 101
match community 1
policy. Use a simple condition (if and else if
set metric 11 in this example) for every match clause in the
set community 12:34 additive route map and an action statement (in this case
route-map sample1 permit 20 set) for every set command in the route map.
match community 2
set metric 12 route-policy policy1
set community 12:34 additive if destination in ps101 and community matches-any cs1 then
set med 11
route-map sample1 permit 30 set community (12:34) additive
match ip address prefix-list 101 elseif destination in ps101 and community matches-any cs2 then
match community 3 set med 12
set metric 13 set community (12:34) additive
set community 12:34 additive elseif destination in ps101 and community matches-any cs3 then
set med 13
set community 12:34 additive elseif destination in ps101
set med 100
match ip address prefix-list 101 endif
set metric 100 end-policy
set community 12:34 additive
route-map sample2 permit 10

Convert the second route map as well, using the
match community 1 same type of if and set statements. Note the
set metric 11 repetitive statements if destination! and set
community.. in both policies.
route-map sample2 permit 20
match community 2
set metric 12 route-policy policy2
set community 12:35 additive if destination in ps102 and community matches-any cs1 then
set med 11
set community 12:35 additive elseif destination in ps102 and community matches-any cs3 then
set med 13
set community 12:35 additive elseif destination in ps102
set med 100
match ip address prefix-list 102 endif
set metric 100 end-policy

Nest Conditionals
Common operations in both the policies can now be coalesced by nesting
the conditionals, testing the destination address only once, and setting the
community only once. The nesting resolves the redundant testing and
setting operations into a single precondition for the rest of the logic.

Nest Conditionals
Replace the redundant if destination in

conditional and set community statements in
the first route policy by just one instance each.
route-policy policy1
if destination in ps101 and community matches-any cs1 then route-policy policy1
set med 11 if destination in ps101 then
set community 12:34 additive set community (12:34) additive
elseif destination in ps101 and community matches-any cs2 then if community matches-any cs1 then
set med 12 set med 11
set community 12:34 additive elseif community matches-any cs2 then
elseif destination in ps101 and community matches-any cs3 then set med 12
set med 13 elseif community matches-any cs3 then
set community 12:34 additive set med 13
elseif destination in ps101 and community matches-any cs4 then elseif community matches-any cs4 then
set community 12:34 additive else
elseif destination in ps101 set med 100
set med 100 endif
set community 12:34 additive endif
endif end-policy
end-policy
Leave the nested if community
conditionals to reduce size and
evaluation processing.
Perform a similar action on the

second route policy reducing
repetitive conditional statements.
if destination in ps102 and community matches-any cs1 then route-policy policy2
set med 11 if destination in ps102 then
set community (12:35) additive set community (12:35) additive
elseif destination in ps102 and community matches-any cs2 then if community matches-any cs1 then
set community (12:35) additive elseif community matches-any cs2 then
elseif destination in ps102 and community matches-any cs3 then set med 12
set med 13 elseif community matches-any cs3 then
set community (12:35) additive set med 13
elseif destination in ps102 and community matches-any cs4 then elseif community matches-any cs4 then
set community (12:35) additive else
elseif destination in ps102 set med 100
set med 100 endif
set community (12:35) additive endif
endif end-policy
end-policy

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
Replace small named community sets

with inline sets, reducing named set
references during policy evaluation.
route-policy policy1 route-policy policy1

if destination in ps101 then if destination in ps101 then
if community matches-any cs1 then if community matches-any (10:11) then
elseif community matches-any cs2 then elseif community matches-any (10:12) then
else else
endif endif
endif endif
end-policy end-policy
Perform same replacement of named

community sets in the second route
policy. Note that the two route policies
are nearly identical.
route-policy policy2 route-policy policy2

if destination in ps102 then if destination in ps102 then
if community matches-any cs1 then if community matches-any (10:11) then
else else
endif endif
endif endif
end-policy end-policy

Parameterize Common Policy Structures

Create a parameterized policy block containing the common policy
structure from both policies and accepting a community parameter. Then
apply the parameterized policy in place of the common policy structure in
each policy, passing their unique community value as the parameter.

Parameterize Common Policy Structures
Parameter $tag replaces

unique community value. Create a parameterized policy block
that contains the common policy
structure to be used by the route
policies.
route-policy common ($tag)
set community (12:$tag) additive
if community matches-any (10:11) then
set med 11
elseif community matches-any (10:12) then
set med 12
set med 13
set med 14
else
set med 100
endif
end-policy
Apply the parameterized policy to

replace the similar policy blocks in
both of the route policies.
if destination in ps101 then
apply common (34)
pass
endif
end-policy
if destination in ps102 then
apply common (35)
pass
endif
end-policy

Final RPL Policy Configuration

The final RPL policy configuration consists of only two prefix sets and
three policies, instead of the six lists and two route maps we started out
with. Often in production environments, 10s (or more) of route map
configurations have this same kind of inherently redundant structure and
the savings in configuration size using optimized RPL policies can be
significantly larger.

Final RPL Policy Configuration
prefix-set ps101 route-policy policy2

10.48.0.0/16 le 32, if destination in ps102 then
172.48.0.0/19, apply common (35)
192.168.3.0/24 pass
end-set endif
end-policy
prefix-set ps102
172.16.10.0/24, route-policy common ($tag)
192.168.8.0/21, set community (12:$tag) additive
192.168.32.0/21 if community matches-any (10:11) then
end-set set med 11
route-policy policy1 set med 12
if destination in ps101 then elseif community matches-any (10:13) then
apply common (34) set med 13
pass elseif community matches-any (10:14) then
endif set med 14
end-policy else
set med 100
endif
end-policy

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 or deleted using the no form but not practically modified.
__________________________ CAUTION _______________________
If you enter route-policy RP1 (where RP1 is an existing policy) in global
configuration mode, you are warned that the original content will be
replaced if you continue configuring the policy.
__________________________________________________________
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, for example, 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 policy-name
. . .
end-policy
Thus, instead of each line being an individual command, each policy or set
can be thought of as a configuration object that can be manipulated as a
unit using the edit command.
After entering the edit command, a copy of the set or policy is copied to a
temporary file and the MicroEmacs,Vim, or Nano editor is launched. After
editing the policy object and quitting the editor, the policy object will be
parsed and checked for syntax errors.
If there are errors, an error message is displayed, followed by a disposition
query:
Continue editing? [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 ends.
If there are no errors, the configuration change is committed and the
editing session ends.

Module 9 RPL-Specific CLI Commands
Editing Policies and Sets
The command-line interface (CLI) provides the means

to initially enter and subsequently delete route policies.
It also provides a unique means to edit the contents of
the policy between the begin-end brackets using either
the MicroEmacs, Vim, or Nano editors.
The name of the object being edited must be included
following the object type in the edit command.
:router# edit ?
as-path-set edit an as-path-set
community-set edit a community-set
extended-community-set edit an extended-community-set
policy-global edit policy-global definitions
prefix-set edit a prefix-set
rd-set edit a rd-set
route-policy edit a route-policy
:router# edit route-policy labtesting

show rpl route-policy Command

To display the configuration of a specific named route policy, use the show
rpl route-policy name command. If the detail keyword is added to the
show rpl route-policy command, the configuration of all policies and sets
that the policy uses are also displayed.

show rpl route-policy Command
Display configuration of an RPL policy
:router# show rpl route-policy my_policy

route-policy my_policy
set community (1276:4, 1276:1000, no-export) additive
end-policy
!
Specifying detail keyword additionally displays configuration of all

policies and named sets used by this policy

Other show rpl Commands

show rpl route-policy name attachpoints
This command lists, by attach point type, all attach points that use the
specified policy.
show rpl route-policy name references [brief]
This command lists all policies that reference (apply) the named policy.
The brief keyword limits the output to just a summary table and not the
detailed information for the named policy.
show rpl route-policy name uses {all | policies | sets} [direct]
This command lists named policies, sets or both used by the specified
policy.
show rpl route-policy states
This command lists the names of route policies categorized by operational

state:
activeIn use in the system and referenced either directly or
indirectly at a policy attach point.
inactiveNot in use at an attach point either directly or indirectly,
but are referenced by at least one other policy in the system.
unusedDefined but not used at an attach point or referenced from
another policy using an apply statement.
show rpl {active | inactive | unused} route-policy
This command lists all named policies that are in the specified operational
state.

Other show rpl Commands
show rpl route-policy name attachpoints
show rpl route-policy name references [brief]
show rpl route-policy name uses {all | policies | sets} [direct]
show rpl route-policy states
show rpl {active | inactive | unused} route-policy

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 to use this command. When the
show bgp route-policy command is entered, BGP routes from the
specified address family are compared against the specified route
policy, and all routes passed by the route policy are displayed.
__________________________________________________________________

show bgp route-policy Command
Display only BGP routes that match an RPL policy
:router# show bgp route-policy sample

Dampening enabled
Status codes: s suppressed, d damped, h history, * valid, > best
i - internal, S stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
* 10.13.0.0/16 192.168.40.24 0 1878 704 701 200 ?
* 10.16.0.0/16 192.168.40.24 0 1878 704 701 i

Summary
Routing Policy Language
Define RPL sets and policies

Describe hierarchical and parameterized policies
Construct sets and simple hierarchical policies
Convert route maps to RPL policies

Module 10
Multicast Routing
Overview
Description
This module covers the Cisco IOS XR software implementation of multicast
routing and associated protocols.
Objectives
Describe and configure Multicast Routing
Describe Internet Group Management Protocol (IGMP) and examine
basic operation
Describe Protocol Independent Multicast sparse mode (PIM-SM),
source specific mode (PIM-SSM), and bidirectional PIM (Bidir-PIM)
Describe and configure static RP, Boot Strap Router (BSR), and Auto-
RP operation
Configure basic PIM-SM functionality and examine operation

Multicast Routing Module 10
Introduction
Multicast routing is a bandwidth-conserving technology that reduces
traffic by simultaneously delivering a single stream of information to
potentially thousands of recipient hosts. It allows a host to send packets to
a subset of all hosts as a group transmission rather than to a single host,
as in unicast transmission, or to all hosts, as in broadcast transmission.
Packets delivered to group members are identified by a single multicast
group address. Multicast packets are delivered with the same reliability
(best-effort) as unicast packets.
The multicast environment consists of senders and receivers. Any host,
regardless of whether or not it is a member of a group, can send to a group.
However, only the members of a group receive the message. A multicast
address is chosen for the receivers in a multicast group. Senders use that
group address as the destination address of a datagram to reach all
members of the group. Membership in a multicast group is dynamic; hosts
can join and leave at any time. A host can be a member of more than one
multicast group at a time. Membership in a group can change constantly. A
group that has members may have no activity.
Routers use Internet Group Management Protocol (IGMP) (IPv4) and
Multicast Listener Discovery (MLD) (IPv6) to learn whether members of a
group are present on their directly attached subnets. Hosts join multicast
groups by sending IGMP or MLD report messages.

Module 10 Introduction
Introduction
Bandwidth Conserving Broadcast Technology

Reduces packet replication
Forwards packets to group address along
distribution tree
Packets delivered as best effort to all hosts in
group
Multicast group membership is dynamic
Relies on IGMP for IPv4 and MLD for IPv6

Implementation
The Cisco IOS XR hierarchically structured CLI groups each multicast
protocol configuration. Basic multicast operation is configured under the
multicast routing configuration submode and interfaces must be explicitly
enabled.
IGMP operation is enabled automatically when an interface is configured
for multicast routing. Cisco IOS XR defaults IGMP to version 3 operation.
Versions 1 and 2 can be configured per interface.
Protocol Independent Multicast (PIM) operation is enabled automatically
when an interface is configured for multicast routing. Cisco IOS XR
software supports PIM sparse mode (SM), source specific multicast (SSM),
and bidirectional (bidir) PIM operation. Dense mode (DM) operation is
supported only for auto-RP behavior that is specific to Cisco.
Multicast Source Discovery Protocol (MSDP) is used to connect multiple
PIM-SM domains, allowing multiple sources for a group to be known to all
rendezvous points.
____________________________ Note _________________________
IPv6 multicast configuration and operation is not covered in this
course.
__________________________________________________________________

Implementation
Hierarchical configuration
Specific router protocol modes
Interfaces must be explicitly enabled for multicast
! IGMP/MLD and PIM enabled simultaneously
IGMP
Defaults to Version 3
! Versions 2 and 1 can be configured
PIM
Supports SM, SSM and Bidir operation
Static RP, Auto-RP, and BSR configurations
MSDP
Connects PIM SM domains by advertising group sources

Command Line Interface Configuration Structure

Cisco IOS XR multicast routing uses a hierarchical configuration structure.
Multicast protocol-specific configuration has been grouped under the
appropriate router-level configuration submode (IGMP, PIM, or MSDP).
Protocol-specific submodes provide mechanisms for enabling, disabling,
and configuring multicast features on a large number of interfaces.
Interface configuration commands entered in the router configuration
submode are inherited on all protocol interfaces, unless specifically
changed at the protocol interface configuration submode.
For example, in the following configuration, you could quickly specify
(under router PIM configuration mode) that all existing and new PIM
interfaces on your router will use the hello interval parameter of 420
seconds. However, Packet-over-SONET/SDH (POS) interface 0/1/0/1
overrides the global interface configuration and uses the hello interval time
of 210 seconds.

Hierarchical multicast configuration with inheritance
multicast-routing router igmp router pim router msdp
interface interface interface peer
Values for certain parameters specified at router

process level are inherited by lower level
:router(config)# router pim
:router(config-pim-ipv4)# hello-interval 420
:router(config-pim-ipv4)# interface POS0/4/0/0
:router(config-pim-ipv4-if)# hello-interval 210

Configuring Multicast Routing

Initial Multicast Configuration
The following steps create an initial configuration:
1. Enter multicast routing configuration mode.
When you issue the multicast-routing command, all default multicast
components (PIM, IGMP, MLD, MFWD, and MRIB) are automatically
started and the CLI prompt changes to config-mcast indicating that
you have entered multicast-routing configuration submode (IPv4 is the
default mode of operation).
2. Enable multicast routing and forwarding on one or all interfaces.
3. (Optional) Enter IGMP or PIM configuration mode to set parameters.
____________________________ Note _________________________
Management Ethernet (MgmtEth) interfaces cannot be enabled for
multicast routing, even if the interface all enable command is
configured.
__________________________________________________________________

Module 10 Configuring Multicast Routing
Initial Multicast Configuration
Enter multicast routing configuration mode
:router(config)# multicast-routing
Enable multicast routing and forwarding on one interface
:router(config-mcast)# interface pos 0/4/0/0 enable
OR all new and existing interfaces
:router(config-mcast)# interface all enable
Optionally enter IGMP or PIM configuration mode to set parameters
:router(config)# router igmp

:router(config-igmp)#
2011, Cisco Systems, Inc. All rights reserved. Version 34.0.1 Course Name Module 0/8
(config-mcast-default-ipv4) that is the default mode of operation is IPv4 if IPv6 is not specifically
selected.

The topology and configuration on the opposite page is part of our lab
environment. In subsequent pages of this module, the PE3 router is used
as the target for examining basic multicast operation using various CLI
show commands.

PE3 P1
.3 192.192.13 .1
10.3.3.3 10.1.1.1
POS 0/4/0/0
POS 0/3/0/1
.3
192.168.23
.2
10.2.2.2
P2
interface Loopback0
ipv4 address 10.3.3.3 255.255.255.255
!
ipv4 address 192.168.23.3 255.255.255.0 PE3
!
Configuration
ipv4 address 192.168.13.3 255.255.255.0
!
multicast-routing address-family ipv4
interface all enable
!

IGMP Interfaces
The show igmp interface command displays the operational status of
interfaces configured with IGMP. If not further qualified, it shows all
IGMP interfaces for all IGMP instances.
physical port (up/down) and the status of the datalink protocol running on
that port (up/down). That is followed by the configured IPv4 address, mask,
IGMP version, and configured timer values:
IGMP query intervalThe frequency at which the Cisco IOS XR

software sends IGMP host-query messages.
IGMP querier timeoutTimeout that is set by non-querier routers.

When this timeout expires, the non-querier routers begin to send
queries.
IGMP max query response timeQuery response time, in seconds,
that is used by administrators to tune the burstiness of IGMP messages
on the network. This is the maximum time within which a response to
the query is received.
Last member query response intervalQuery response time in

seconds since a host replied to a query that was sent by the querier.
IGMP activityTotal number of joins and total number of leaves
received.
IGMP querying routerIndicates the elected querier on the link.
____________________________ Note _________________________
Management Ethernet interfaces are always disabled for IGMP and
are not displayed with the show igmp interface command.
__________________________________________________________________

IGMP Interfaces
:PE3# show igmp interface

POS0/3/0/1 is up, line protocol is up
IGMP is enabled on interface
Current IGMP version is 3
IGMP query interval is 60 seconds
IGMP querier timeout is 125 seconds
IGMP max query response time is 10 seconds
Last member query response interval is 1 seconds
IGMP activity: 3 joins, 0 leaves
IGMP querying router is 192.168.23.2
[output omitted]

IGMP Group Membership

To display the multicast groups that are directly connected to the router
and were learned through IGMP, use the show igmp groups command. If
not further qualified, the show igmp groups command displays (by group
address and interface name) all the multicast memberships that the
directly connected networks have subscribed. The slide shows a partial list.
For each interface, the output indicates:
Group AddressThe IP address of the multicast group
InterfaceThe interface through which the group is reachable
UptimeHow long (in hours, minutes, and seconds) this multicast

group has been known
ExpiresHow long (in hours, minutes, and seconds) until the entry is
removed from the IGMP groups table
Last ReporterThe last host to report being a member of the

multicast group

IGMP Group Membership
:PE3# show igmp group

IGMP Connected Group Membership
Group Address Interface Uptime Expires Las t Reporter
224.0.0.2 Loopback0 00:05:27 never 10. 3.3.3
224.0.0.13 Loopback0 00:05:27 never 10. 3.3.3
224.0.0.22 Loopback0 00:05:27 never 10. 3.3.3
224.0.1.40 Loopback0 00:05:27 never 10. 3.3.3
224.0.0.2 POS0/3/0/1 00:05:27 never 192 .168.23.3
224.0.0.5 POS0/3/0/1 00:05:27 never 192 .168.23.3
224.0.0.6 POS0/3/0/1 00:05:27 never 192 .168.23.3
224.0.0.13 POS0/3/0/1 00:05:27 never 192 .168.23.3
224.0.0.22 POS0/3/0/1 00:05:27 never 192 .168.23.3
224.0.0.2 POS0/4/0/0 00:05:27 never 192 .168.13.3
224.0.0.5 POS0/4/0/0 00:05:27 never 192 .168.13.3
224.0.0.6 POS0/4/0/0 00:05:27 never 192 .168.13.3
224.0.0.13 POS0/4/0/0 00:05:27 never 192 .168.13.3
224.0.0.22 POS0/4/0/0 00:05:27 never 192 .168.13.3

Protocol Independent Multicast

Protocol Independent Multicast (PIM) is a routing architecture and set of
multicast routing protocols that allow multicast routing on IP networks.
PIM is unicast routing protocol-independent. In other words, regardless of
which unicast routing protocols are being used to populate the unicast
routing table, PIM leverages the existing unicast table content to perform
the Reverse Path Forwarding (RPF) check function instead of building and
maintaining its own separate multicast route table.
PIM Sparse Mode
PIM sparse mode (PIM-SM) tries to constrain multicast data distribution

so that a minimal number of routers in the network receive it. A router
assumes that other routers do not want to forward multicast packets for a
group, unless there is an explicit request for the traffic.
When hosts join a multicast group, the directly connected routers send PIM
Join messages toward the rendezvous point (RP). The RP keeps track of
multicast groups. Hosts that send multicast packets are registered with
the RP by that host's first-hop router. The RP then sends Join messages
toward the source. At this point, packets are forwarded on a shared
distribution tree. Alternatively, the receiver's first-hop router may send
Join messages toward the source to build a source-based distribution tree.

Module 10 Protocol Independent Multicast
Protocol Independent Multicast
Multicast routing architecture

Set of multicast routing protocols
Independent of unicast routing protocol but
leverages unicast routing table for RPF check
Sparse mode (SM)
Assumes relatively few receivers widely
distributed
Based on shared distribution tree rooted at
rendezvous point (RP)

PIM Shared Tree and Source Tree

By default, members of a group receive data from senders to the group
across a single distribution tree rooted at the RP. This type of distribution
tree is called a shared tree or rendezvous point tree (RPT). Data from senders is
delivered to the RP for distribution to group members joined to the shared
tree.
If conditions warrant, leaf routers on the shared tree may initiate a switch
to the data distribution tree rooted at the source. This type of distribution
tree is called a shortest path tree (SPT) or source tree.
By default, Cisco IOS XR software switches to a source tree upon receiving

the first data packet from a source. Alternatively, you can force the
forwarding to stay on the shared tree using the spt-threshold infinity
command in router PIM configuration submode. Unlike other
implementations of PIM-SM, there is no traffic-based threshold to initiate
switching to source tree.

PIM Shared Tree and Source Tree
Shared tree rooted at rendezvous point

First-hop router registers source to RP and
sends data
RP distributes data to group members
Source tree rooted at source
Last-hop router can initiate switch
Forms shortest path tree to first-hop router
First-hop router distributes data using SPT
PIM source
RP RP
register message
(*,G)
Multicast (*,G)
data flow (S, G)
* = all sources
G = Mcast group
S = Source
(*,G)
(*,G) Receiver (S, G) Receiver
Reg
(*,G) (*,G)
ister
(*,G) (*,G)
(*,G) (*,G)
(S, G) (S, G)
Receiver Source Receiver Source
Shared tree from RP Source tree

Designated Router
The designated router (DR) is responsible for sending PIM register, join
and prune messages toward a rendezvous point (RP) to inform it about
host group membership on a local network. If there are multiple PIM-SM
routers on a LAN, a designated router must be elected to avoid duplicating
multicast traffic for connected hosts.
Generally the PIM router with the highest IP address becomes the DR for
the LAN, unless you force the DR election by use of the dr-priority
command. Setting the DR priority of the PIM interfaces allows you to
control the election such that the router with the highest priority is elected
as the DR.
The example on the facing page shows a multiaccess network with Router
A (10.0.0.253) and Router B (10.0.0.251) connected. Host A (10.0.0.1) on
the same network has registered its interest in receiving multicast traffic
to Group G using IGMP. Only Router A, having been elected as the PIM
designated router (DR), sends joins to the RP to construct the shared tree
for Group G. If Host A were to begin to source multicast traffic to the
group, the DRs responsibility would then be to send PIM Register
messages to the RP.

Designated Router
Responsible for sending PIM messages to RP

about host group membership
DR is elected on multiaccess networks to avoid
duplicating multicast traffic for connected
hosts
By default, PIM router with the highest IP
address is elected
DR priority can be configured to control election
RP
(*, G) Join
PIM Router A PIM Router B
DR Non-DR
10.0.0.253 10.0.0.251
10.0.0.0/24
10.0.0.1
Host A (Receiver) in Group G

Rendezvous Point
In PIM sparse mode, one or more routers operate as a rendezvous point
(RP). An RP is a single common root placed at a chosen point of a shared
distribution tree. The location of an RP can either be configured statically
in each PIM router, or learned through a dynamic mechanism such as
Bootstrap Router (BSR) or Ciscos Auto-RP. PIM DRs forward data from
directly connected multicast sources to the RP for distribution down the
shared tree. Data is forwarded to the RP in one of two ways:
Encapsulated in register packets and unicast directly to the RP by the
first-hop router operating as the DR
Multicast forwarded per the Reverse Path Forwarding (RPF) algorithm,
if the RP has itself joined the source tree
The RP address is used by first-hop routers to send PIM register messages
on behalf of a host sending a packet to the group. The RP address is also
used by last-hop routers to send PIM join and prune messages to the RP to
inform it about group membership.
A PIM router can be an RP for more than one group. Only one RP address
per group can be used at a time within a PIM domain. The conditions
specified by an optional access list determine for which groups the router is
an RP.

Rendezvous Point
A PIM router can be RP for multiple groups

RPs are either statically defined or dynamically learned
using BSR or Auto-RP
First-hop routers use RP address for PIM register
messages
Data is forwarded to RPs as either:
Packets unicast directly by DR
Packets forwarded by RPF if RP is joined to source tree
Last-hop routers use RP address to send join and
prune messages

Configuring a Static RP
On non-RP routers, the following steps configure the address of a static RP:
1. Enter router PIM configuration mode.
2. Set the address of the rendezvous point.
No specific configuration needs to be done on the RP router.

Configuring Static RP
Enter router PIM configuration mode

Set the static rendezvous point address
:router(config-pim)# rp-address 10.1.1.1

PIM Bootstrap Router

The PIM Bootstrap Router (BSR), part of the IETF PIM Version 2
specification, provides a fault-tolerant, automated RP discovery and
distribution mechanism. PIM uses the BSR to discover and announce RP-
set information for each group prefix to all the routers in a PIM domain.
____________________________ Note _________________________
BSR is supported for IPv4 only.
__________________________________________________________________
To avoid a single point of failure, you can configure several candidate BSRs
in a PIM domain. A BSR is elected among the candidate BSRs
automatically. Candidates use bootstrap messages to discover which BSR
has the highest priority. The candidate with the highest priority sends an
announcement to all PIM routers in the PIM domain that it is the BSR.
Routers that are configured as candidate RPs unicast to the BSR the group
range for which they are responsible. The BSR includes this information in
its bootstrap messages and disseminates it to all PIM routers in the
domain. Based on this information, all routers are able to map multicast
groups to specific RPs. As long as a router is receiving the bootstrap
message, it has a current RP map.

PIM Bootstrap Router
Provides RP discovery and distribution in PIM domain

Fault-tolerant and automated
Multiple BSR candidates possible in PIM domain
Avoids single point of failure
Elected among candidates
! Highest IP address is elected
Announces self to PIM routers
Candidate RPs unicast to the BSR their group range
responsibility
BSR announces RP-set information to PIM routers

Configuring BSR
In order to configure BSR on a PIM router:
1. Enter router PIM configuration mode.
2. Configure one or more routers as a candidate for BSR.
3. Configure one or more routers to advertise itself as a candidate RP to
the BSR.
4. (Optional) To avoid exchanging BSR messages between PIM domains,
turn off messages on an interface that connects to another domain.

Configuring BSR
Configure the router to announce its candidacy as a BSR
:router(config-pim)# bsr candidate-bsr 10.1.1.1
Configure the router to advertise itself as a candidate RP to the BSR
:router(config-pim)# bsr candidate-rp 10.1.1.1
Avoid exchanging BSR messages between domains

:router(config-pim)# interface pos 0/3/0/0
:router(config-pim-ipv4-if)# bsr-border

Auto-RP
Auto-RP is a behavior specific to Cisco routers that automates the

distribution of group-to-RP mappings in a PIM network. This feature has
the following benefits:
Easy to use multiple RPs within a network to serve different group
ranges
Allows load splitting among different RPs and arrangement of RPs
according to the location of group participants
____________________________ Note _________________________
Auto-RP is supported for IPv4 only.
__________________________________________________________________
Multiple RPs can be used to serve different group ranges or serve as hot
backups of each other. PIM routers are configured as candidate RPs so that
they can announce their interest in operating as the RP for certain group
ranges.
Minimally, one router must be designated as an RP-mapping agent that
receives the RP-announcement messages from the candidate RPs and
arbitrates conflicts. The RP-mapping agent sends the consistent group-to-
RP mappings to all remaining routers. Thus, all routers automatically
discover which RP to use for the groups they support.
An optional access lists allow you to limit an RP to only groups you want. If
no access list is configured, RPs are available for all groups. If two RPs are
announcing their availability to be RPs for the same groups, the elected
mapping agent resolves these conflicts using "the highest IP address wins"
rule.

Auto-RP
Automates the distribution of group-to-RP mappings in

a PIM network
Eases defining multiple RPs in network to serve different
group ranges
Allows load splitting and arrangement of RPs according
to location of participants
Candidate RPs announce group ranges to mapping
agents
Elected mapping agent arbitrates group conflicts
Highest RP address wins
Announce group-to-RP mappings to PIM routers

Configuring Auto-RP
In a PIM domain using Auto-RP, at least one router must operate as an RP
candidate and another router must operate as an RP mapping agent. The
RP and mapping agent could be the same router. Usually more that one
router is configured for each to provide redundancy in the Auto-RP
operation.
In order to configure auto-RP operation:
1. Enter router PIM configuration mode and define the address family.
2. Configure the router to announce itself as an RP candidate by sending
messages to the default CISCO-RP-ANNOUNCE multicast group
(224.0.1.39).
3. Configure the router as RP mapping agent on a loopback interface.

Configuring Auto-RP

:router(config)# router pim address-family ipv4
Configure as an RP candidate to send messages to the CISCO-RP-ANNOUNCE

multicast group
:router(config-pim-default-ipv4)# auto-rp candidate-rp loopback0 scope 3
Configure the router as RP mapping agent on specified interface
:router(config-pim-default-ipv4)# auto-rp mapping-agent loopback0 scope 3

PIM Source Specific Multicast

PIM-SSM is the implementation of Source Specific Multicast derived from
PIM-SM. However, unlike PIM-SM, in which all multicast sources are
sent when there is a PIM join, the SSM feature forwards datagram traffic
to receivers from only those multicast sources that the receivers have
explicitly joined, or subscribed.
In PIM-SSM, delivery of datagrams is based on (S, G) channels. Traffic for
one (S, G) channel consists of datagrams with an IP unicast source address
S and the multicast group address G as the IP destination address.
Systems receive this traffic by becoming members of the (S, G) channel.
Further, instead of the use of RP and shared trees, PIM-SSM uses
information found on source addresses for a multicast group. This
information is provided by receivers through the source addresses relayed
to the last-hop routers by IGMPv3 membership reports resulting in source-
specific trees.

PIM Source Specific Multicast
PIM-SSM is a one-to-many model

PIM-SM is an any-source model
Group address identity
Specific Source, multicast Group (S,G)
Group address is also referred to as channel
Requires IGMPv3 source selection
DR has unicast IP address of source
Bypasses the RP connection stage
SPT rooted at actual source
Channel (S, G) built between

source and receiver
Router joins (S, G) source tree
IGMPv3 join include-list (source S)

Bidirectional PIM
In Bidirectional PIM (Bidir-PIM) operation, the PIM-SM packet forwarding
rules are augmented, allowing traffic to be passed up the shared tree
toward the RP. To avoid multicast packet looping, Bidir-PIM introduces a
new mechanism called designated forwarder (DF) election, which
establishes a loop-free SPT rooted at the RP.
The procedure for joining the shared tree of a bidirectional group is almost
identical to that used in PIM SM. A key difference is that, for bidirectional
groups, the role of the DR is assumed by the DF for the RP.

Bidirectional PIM
Variant of PIM-SM that allows bidirectional traffic

Uses shared distribution tree only
! No source tree (SPT)
! Selected for scaling, not optimum routing
No registration process for sources
Designated forwarder replaces DR
! Issues joins and prunes
! Forwards sourced traffic toward RP
All PIM routers on subnet must be Bidir-PIM
capable
RP
(*,G)
Data from source flows up shared
tree (*, G) to RP
Data flows down shared tree to
receivers
No registration process (*,G) Receiver
(*,G)
(*,G) (*,G)
Source/Receiver Source
Bidirectional Shared Trees

Examining PIM Operation

Interface Information
To display information about PIM interfaces, use the show pim interface
command. The significant fields displayed in this command example are:
AddressIP address of the interface
InterfaceInterface type and instance configured to run PIM
PIMState of PIM (off or on) for this interface

Nbr CountNumber of directly connected PIM neighbors
Hello IntvlTime, in seconds, between PIM hello messages, as set by
the PIM interface hello-interval command
DR PriorDesignated router priority, as advertised by the neighbor
in its hello messages
DRIP address of the DR on a multiaccess network

Note that point-to-point networks do not have DRs, so the IP address is
shown as 0.0.0.0. If the interface on this router is the DR, this system
is indicated; otherwise, the IP address of the external neighbor is given.

Module 10 Examining PIM Operation
Interface Information
:PE3# show pim interface
Address Interface PIM Nbr Hello DR DR

Count Intvl Prior
172.21.116.20 MgmtEth0/0/CPU0/0 off 0 30 1 not elected

172.21.116.21 MgmtEth0/1/CPU0/0 off 0 30 1 not elected
10.3.3.3 Loopback0 on 1 30 1 this system
192.168.13.3 POS0/4/0/0 on 2 30 1 this system
192.168.23.3 POS0/3/0/1 on 2 30 1 this system

Neighbor Information
Information is displayed about the PIM neighbors with the show pim
neighbor command.
The significant fields of the sample output are:
Neighbor AddressIP address of the PIM neighbor (an asterisk
indicates a local interface address, not a neighbor address)
InterfaceInterface type and number over which the neighbor is
reachable
UptimeDuration of time the entry has been in the PIM neighbor
table
ExpiresTime remaining time until the entry is removed from the IP
multicast routing table
DR priDesignated router priority sent by the neighbor in its hello
messages
If this neighbor is elected as the designated router (largest IP address)
on the network connected by the interface, it is annotated with (DR)
in the command output.
FlagsIndicates with a B if the neighbor is capable of bidirectional
PIM mode operation

Neighbor Information
:PE3# show pim neighbor
Neighbor Address Interface Uptime Expires DR pri Flags
10.3.3.3* Loopback0 00:00:20 00:01:24 1 (DR) B

192.168.13.1 POS0/4/0/0 00:00:19 00:01:25 1 B
192.168.13.3* POS0/4/0/0 00:00:20 00:01:26 1 (DR) B
192.168.23.2 POS0/3/0/1 00:00:19 00:01:25 1 B
192.168.23.3* POS0/3/0/1 00:00:20 00:01:25 1 (DR) B
* Asterisk indicates a local (not neighbor) interface address

Group Mappings
The show pim group-map command displays the multicast PIM group
mapping table. The groups can be filtered by multicast group address or
domain name (ip-address-name) and can be further detailed with group
information source (info-source).
The group ranges are listed from most specific to least specific, in
descending order. A more specific group range mapping overrides a less
specific one. The significant fields in the output are:
Group RangeMulticast group range that is mapped
ProtoMulticast forwarding mode
ClientHow the client was learned
GroupsNumber of groups from the PIM topology table
RP addressIP address of the rendezvous point
InfoRPF interface used and neighbor address toward the RP

Examining the group range entries on the facing page:
In the first two, the multicast group addresses used by Auto-RP are
specifically denied from the sparse mode group range.
In the third, link-local multicast groups (224.0.0.0 to 224.0.0.255, as
defined by 224.0.0.0/24) are also denied from the sparse mode group range.
In the fourth, the PIM Source Specific Multicast (PIM-SSM) group range is
mapped to 232.0.0.0/8.
The second to the last entry shows that all remaining group addresses are
in sparse mode mapped to RP 10.2.2.2, which was learned using auto-RP.
The RPF information indicates POS 0/3/0/1 as the local interface towards
the RP and 192.168.23.2 as the neighbor interface address in that
direction.
The last entry statically maps all addresses for sparse mode usage. This
mapping covers the entire Class D address space and is instantiated when
PIM is enabled.

Group Mappings
:PE3# show pim group-map
IP PIM Group Mapping Table

(* indicates group mappings being used)
(+ indicates BSR group mappings active in MRIB)
Group Range Proto Client Groups RP address Info
224.0.1.39/32* DM perm 1 0.0.0.0

224.0.1.40/32* DM perm 1 0.0.0.0
224.0.0.0/24* NO perm 0 0.0.0.0
232.0.0.0/8* SSM config 0 0.0.0.0
224.0.0.0/4* SM autorp 0 10.2.2.2 RPF: PO0/3/0/1,192.168.23.2
224.0.0.0/4 SM static 0 0.0.0.0 RPF: Null,0.0.0.0

Summary
Multicast Routing
Describe and configure Multicast Routing

Describe Internet Group Management Protocol (IGMP) and examine
basic operation
Describe Protocol Independent Multicast sparse mode (PIM-SM),
source specific mode (PIM-SSM), and bidirectional PIM (Bidir-PIM)
Describe and configure static RP, Boot Strap Router (BSR), and Auto-
RP operation
Configure basic PIM-SM functionality and examine operation

Module 11
Multiprotocol Label Switching (MPLS)
Overview
Description
This module discusses the implementation and configuration of MPLS in
the Cisco IOS XR operating system software.
Objectives
Describe Cisco IOS XR MPLS implementation
Explain MPLS forwarding infrastructure
Implement MPLS Label Distribution Protocol

Demonstrate MPLS Traffic Engineering dynamic implementation
Articulate an RSVP implementation for MPLS-TE

Multiprotocol Label Switching (MPLS) Module 11
Multiprotocol Label Switching

Multiprotocol Label Switching (MPLS) is an Internet Engineering Task
Force (IETF) standards-based solution, devised to convert Internet and
enterprise IP backbones from best-effort networks into business-class
transport networks.
MPLS uses label switching capabilities to eliminate the need for an IP
route lookup. It creates a virtual circuit (VC) type switching function that
lets IP-based networks provide performance capabilities similar to those
delivered over networks such as Frame Relay or ATM.
MPLS in Cisco IOS XR software comes in two versions.

This version is the standard implementation in Cisco IOS XR software that
has a control plane for packet switching, creates label switch paths (LSPs),
uses Label Distribution Protocol (LDP), and can configure dynamic or
explicit traffic engineering tunnels.
Generalized MPLS
GMPLS extends MPLS to provide the control plane, signaling, and routing
for devices that switch traffic in packet, time, wavelength, or fiber
networks. The common control plane simplifies network operation and
management by automating provisioning from end-to-end. GMPLS
provides the expected level of quality of service (QoS) that is needed in
these networks.

Module 11 Multiprotocol Label Switching
Two versions
MPLS
! Control plane for packet switching
! Label switch paths
! Label distribution protocol
! Traffic engineering
" Dynamic configuration
" Explicit configuration
Generalized MPLS (GMPLS)

! MPLS plus extensions
! Architectures and protocols; control plane for packet
switching, TDM (over Sonet/SDH), optical (DWDM), and
direct fiber (port switching)
! Provisioning for all types of equipment in transmission
path

Generalized MPLS
The Cisco IOS XR software implementation includes control plane support
for packet-switch capable (PSC), lambda-switch capable (LSC), and fiber-
switch capable (FSC) devices.
GMPLS in the Core

The current implementation of GMPLS supports:
Optical, bi-directional label switch paths (LSPs)

Open Shortest Path First (OSPF) as the only interior gateway protocol
(IGP)
Control channel over the out-of-band/out-of-fiber IP network
Numbered and unnumbered traffic engineering links
IPv4 and MPLS traffic over GMPLS tunnels
Label Distribution Protocol (LDP), Border Gateway Protocol (BGP) and
OSPF over GMPLS tunnels
Link Management Protocol

Support for the Link Management Protocol (LMP) includes:
Control channel management as a combination of control channel
establishment and maintenance procedures; includes a parameter
negotiation
Link property correlation
LMP message exchange over the IP control network

Module 11 Generalized MPLS
Generalized MPLS Features
GMPLS core support currently includes:

Bi-directional optical LSP
OSPF is the only supported IGP
Out-of-fiber/out-of-band IP control channel
Numbered/Unnumbered traffic engineering links
IPv4 and MPLS traffic over GMPLS tunnel
LDP, BGP, and OSPF over the GMPLS tunnel
LMP protocol support:
Control channel management and establishment procedures
Link property correlation
LMP message (all) exchange over out-of-fiber/out-of-band IP control
channel

MPLS Forwarding Infrastructure

Cisco IOS XR software uses an MPLS forwarding infrastructure (MFI) on a
label-switch router (LSR) 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
! To form a label-switch path (LSP)
Rewrite setup
Interaction with the IGPs

! Set up label binding
! Set up forwarding paths
The data plane handles:
Imposition, or push, of labels on packets
Disposition, or pop, of labels in packets

Label swapping

Module 11 MPLS Forwarding Infrastructure
MPLS Forwarding Infrastructure
Core set of services

! Label management
! Forwarding
! Performed on label switch routers (LSR)
Control plane
! Enable and disable MPLS on interfaces
! Label table allocation and management
" Create a label switch path (LSP)
! Rewrite setup
! Interaction with the IGPs
" Set up label binding
" Forwarding path creation
Data plane
! Label imposition (push), disposition (pop), swapping

MFI Architecture
The MFI basic elements are:
Label Switching Database (LSD)Resides on both the primary and
standby route processors (RPs)
Label Forwarding Database (LFD)Resides on both the RPs and
the linecards
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
MFI architecture
Basic elements
! Label Switching
Control plane
LDP MPLS-TE
Database (LSD)
! Label Forwarding LSD
Database (LFD)
! MPLS encapsulation and NetIO
decapsulation routines APPL
LFD
FIB
Control plane
! LSD APPL MPLS
! LFD encap/ encap/
Data plane
decap decap
Data plane
! LFD
! MPLS encap and decap HW ASIC
(LFIB)

The LSD:
Allocates or deallocates 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.
The LSD on the active RP distributes the label information to the standby
RP (SRP) and to all line cards that require the information. The line card
stores the forwarding information.

MFI Architecture (Cont.)
Label Switch Database (LSD)

! Allocates and deallocates RP
labels
! Creates a relationship between IGP
FPIs and rewrites TE RSVP LDP
! Maintains a rewrite database
by interacting with the LFD
! Implements an API for MPLS LSD RIB
applications to create, modify,
and delete rewrites
Label Forwarding Database
(LFD) LC
FIB
! Accepts rewrites from the LSD
! Links rewrite to the correct LFD
forwarding tables
! Sets up label tables for MPLS LFIB
decapsulation
RP SRP
LSD LFD LSD LFD
LC LC LC
LFD LFD LFD

Displaying MPLS Forwarding

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.
To obtain an initial understanding of the MPLS forwarding on the router,
use the show mpls forwarding summary command.
Forwarding entries
! Label switchingNumber of label switching (LFIB) forwarding
entries
! IPv4 label impositionNumber of IPv4 label imposition forwarding
entries (installed at ingress LSR)
! MPLS-TE tunnel headNumber of forwarding entries (installed at
ingress LSR) on MPLS-TE tunnel head
! MPLS-TE fast-rerouteNumber of forwarding entries (installed at
point of local repair (PLR)) for MPLS traffic-engineering (TE) fast
reroute
Forwarding updates
! UpdatesNumber of forwarding updates (including BCDL
messages) sent from LSD to LFIB using the internal bulk content
download (BCDL) mechanism
! MessagesNumber of BCDL messages
Labels in use
! ReservedNumber of labels currently needed and being used
! LowestLowest label number in LFIB
! HighestHighest label number in LFIB

Displaying MPLS Forwarding
MPLS show forwarding commands display output

! Globally (SDR-wide)
! By node or location
:router# show mpls forwarding SDR global information
:router# show mpls forwarding location 0/4/CPU0
Specific location
:router# show mpls forwarding ?
debug Include debug information
detail Detailed information
exact-route Display exact path for source/dest addr pair
hardware Read from hardware
interface Match outgoing interface
labels Match label values
location Specify a location
no-counters Skip displaying counters
p2mp p2mp lsps only
prefix Match destination prefix and mask
private Include private information
summary Summarized information
tunnels Tunnel(s) at head
vrf Show entries for a VPN Routing/Forwarding instance
:router# show mpls forwarding summary

Forwarding entries:
Label switching: 28
MPLS TE tunnel head: 1, protected: 0
MPLS TE midpoint: 0, protected: 0
MPLS TE internal: 1, protected: 0
MPLS P2MP TE tunnel head: 0
MPLS P2MP TE tunnel midpoint/tail: 0
Forwarding updates:
messages: 96
p2p updates: 447
Labels in use:
Reserved: 3
Lowest: 0
Highest: 143998
Deleted stale label entries: 0
Pkts dropped: 340

Pkts fragmented: 0
Failed lookups: 340

Local LabelLabel assigned by this router

Outgoing LabelNumeric label assigned by the next hop or
downstream peer, or a value such as:
! UnlabeledNo label for the destination from the next hop, or label
switching is not enabled on the outgoing interface
! Pop LabelNext hop advertised an implicit-null label for the
destination
Prefix or Tunnel IDAddress or tunnel to which packets with this
label are going
Outgoing interfaceInterface through which packets with this label
are sent
Next HopIP address of neighbor that assigned the outgoing label

Bytes SwitchedNumber of bytes switched with this incoming label

Displaying MPLS Forwarding (Cont.)
:router# show mpls forwarding
Local Outgoing Prefix Outgoing Next Hop Bytes T

Label Label or ID Interface Switched O
------ ----------- ----------------- ------------ --------------- ----------- -
16000 Pop 10.11.11.11/32 Gi0/2/0/1 192.168.111.11 0
16001 Pop 10.2.2.2/32 tt12 10.2.2.2 146567881
16002 Pop 192.168.21.0/24 Gi0/2/0/1 192.168.111.11 0
16003 Pop 192.168.12.0/24 Gi0/2/0/1 192.168.111.11 0
16004 Pop 192.168.116.0/24 Gi0/2/0/1 192.168.111.11 0
16005 Pop 192.168.115.0/24 Gi0/2/0/1 192.168.111.11 0
16006 Pop 192.168.114.0/24 Gi0/2/0/1 192.168.111.11 0
16007 73 192.168.123.0/24 Gi0/2/0/1 192.168.111.11 0
16008 Pop 192.168.113.0/24 Gi0/2/0/1 192.168.111.11 0
16009 Unlabelled 192.168.122.0/24 tt12 10.2.2.2 0
16010 Pop 192.168.112.0/24 Gi0/2/0/1 192.168.111.11 0
16011 Pop 10.4.4.4/32 tt14 10.4.4.4 0
16012 Unlabelled 192.168.124.0/24 tt14 10.4.4.4 0
16013 42 10.6.6.6/32 Gi0/2/0/1 192.168.111.11 840121
16014 41 10.5.5.5/32 Gi0/2/0/1 192.168.111.11 898529
16015 Pop PW(10.2.2.2:102) BD=9 point2point 5375440
16016 Aggregate CE1: Per-VRF Aggr[V] \
CE1 2992
:router# show mpls forwarding

------ ----------- ----------------- ------------ --------------- ----------- -
16018 45 192.168.126.0/24 Gi0/2/0/1 192.168.111.11 0
16019 44 192.168.125.0/24 Gi0/2/0/1 192.168.111.11 0
16021 76 10.3.3.3/32 Gi0/2/0/1 192.168.111.11 151823298
16022 Pop PW(10.2.2.2:101) BE100.2 point2point 4184
16024 Pop PW(10.2.2.2:201) Gi0/2/0/24.1 point2point 1188

Additional information about the details of MPLS forwarding paths is

available showing:
MAC/EncapsLength in bytes of Layer 2 header, and length in bytes of
packet encapsulation, including Layer 2 header and label header
MTUMaximum transmission unit (MTU) of labeled packet
Label StackAll the outgoing labels on the forwarded packet

Packets SwitchedNumber of packets switched with this incoming
label

Displaying MPLS Forwarding (Cont.)
:router# show mpls forwarding detail

------ ----------- ----------------- ------------ --------------- ----------- -
16000 Pop 10.11.11.11/32 Gi0/2/0/1 192.168.111.11 0
Updated Apr 1 20:04:26.108
MAC/Encaps: 14/18, MTU: 1500
Label Stack (Top -> Bottom): { Imp-Null }
Packets Switched: 0
16001 Pop 10.2.2.2/32 tt12 10.2.2.2 146859415

Updated Apr 1 20:04:31.296
Label Stack (Top -> Bottom): { 75 Imp-Null }
Packets Switched: 1865400
16002 Pop 192.168.21.0/24 Gi0/2/0/1 192.168.111.11 0

Updated Apr 1 20:04:26.108
Packets Switched: 0
16003 Pop 192.168.12.0/24 Gi0/2/0/1 192.168.111.11 0

Updated Apr 1 20:04:26.108
Packets Switched: 0
Additional information omitted for space

Displaying MPLS Packet Debug Information

For additional help with determining problems, you can use available
debug commands.

Displaying MPLS Packet Debug Information
debug mpls packet {detail} [location node-id]

Displaying MPLS Label Table

To list MPLS label usage, enter the show mpls label table summary
and show mpls label table detail commands.

Displaying MPLS Label Table
RP/0/RSP1/CPU0:PE1# sh mpls label table summary

Application Count
---------------------------- -------
LSD 3
L2VPN 8
BGP-VPNv4:bgp-0 1
TE-Control 1
LDP:Active 19
LDP:Standby 19
---------------------------- -------
TOTAL 32
RP/0/RSP1/CPU0:PE1# sh mpls label table detail

Table Label Owner State Rewrite
----- ------- ---------------------------- ------ -------
0 0 LSD InUse Yes
0 1 LSD InUse Yes
0 2 LSD InUse Yes
0 Commands related to packet forwarding
16000 LDP:Active InUse Yes
LDP:Standby InUse No
(IPv4, 'default':4U, 10.4.4.4/32)
0 16001 LDP:Active InUse Yes
(IPv4, 'default':4U, 10.11.11.11/32)
0 16002 LDP:Active InUse Yes

Label Distribution Protocol

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), 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, MPLS Traffic Engineering (TE)
tunnels, or Fast Reroute (FRR) backup tunnels. LSPs are also created
manually using MPLS-TE or FRRs.
MPLS Label Distribution

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.
The Cisco IOS XR implementation offers two optional, but important and
helpful, features:
Session protection
IGP synchronization

Module 11 Label Distribution Protocol
MPLS 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)
! Created dynamically by LDP
! Created dynamically or manually as
" TE tunnels
" FRR backup tunnels
LDP control plane

! Potential peer discovery
! Peer session establishment
" Using hello discovery
" Targeted hello for non-adjacent neighbors

LDP Session Protection

With MPLS and LDP, there is a typical problem when links between nodes
go down and then return. The IP protocols reconverge faster tha LDP and,
as a result, traffic flow starts faster than LDP and the MPLS traffic
dependent on it. This can cause a loss of MPLS traffic until LDP is able to
reconverge and reestablish traffic patterns.
Cisco IOS XR software presents a solution that allows the LDP session to
be protected by providing a means to establish a parallel source of targeted
discovery or hellos. Standard IP connectivity can keep LDP sessions alive
and maintain neighbor label bindings. This solution can minimize traffic
loss and help reconvergence of MPLS traffic.
Session protection is off by default. It can be activated by entering the
session protection command. The operation of the feature can be limited
through the use of two optional parameters:
session protection [duration (secs) | for (peer ACL)]
! durationthe time, in seconds, that targeted discovery should
continue following the loss of a neighbor; default is unlimited
duration; possible values are 30 2147483 seconds
! forACL containing peers for which session protection is to be
enabled; a permit statement is required in this ACL

LDP Session Protection
Common problemlinks go up and down

! IP routing converges much faster and earlier than LDP
! MPLS traffic can be lost until LDP converges
! With a link flap, LDP flaps also
Solution session protection
! Protect an LDP session by providing parallel source of
targeted discovery or hello
! IP connectivity lets LDP session stay alive and neighbor
label bindings maintained
! Minimize traffic loss and enable faster reconvergence
R2
targeted hello
R1
R3
traffic primary link traffic
link hello
session

LDP IGP Synchronization

Larger, more complex networks can present additional issues for the same
common problem of links going up and down.
Cisco IOS XR software has a different solution for this particular situation.
In this solution, with LDP IGP synchronization, traffic is not routed
towards links the IGP has indicated as down. This is prevented by letting
LDP control an IGP metric for given LDP links. When the link goes down,
it is advertised with a maximum metric until LDP sessions are restored.
IGP synchronization is off by default. It is activated by entering an mpls
ldp sync command in the respective IGP, either IS-IS or OSPF.
To manage the delay for notification to an IGP of the LDP sync state, use
the igp sync delay command within the MPLS configuration. The delay
(5 60 seconds) is the elapsed time prior to declaring the LDP sync state to
be up after session restoration.

LDP IGP Synchronization
Common problemlink flaps

! With a link flap, LDP flaps also
! IP routing converges much faster and earlier than LDP
! MPLS VPN or multilabel traffic can be lost until LDP converges
Solution
! No traffic is routed towards links on which LDP is not yet converged
! Synchronize IGP with LDP
" LDP controls IGP metric for given link, depending on LDP state on
given link
! A link is advertised by IGP with max metric if LDP session is not yet up and
converged (label bindings exchange)
R2
R1 R4
traffic
max-metric
adv.
R3

Configuring LDP
The parameters to get basic MPLS LDP running are explained on the next
several pages.
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.

Module 11 Configuring LDP
Enabling LDP
Enter MPLS LDP mode
:router(config)# mpls ldp

:router(config-ldp)#
Specify interfaces for LDP
:router(config-ldp)# interface gigE 0/2/0/1

:router(config-ldp-if)#

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.
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
advertised by the IGP to a neighboring router.
LDP uses the router ID in the following order:
1. Configured LDP router ID
2. Selected as the primary IPv4 address of the highest numbered
configured IP address
____________________________ Note _________________________
We always recommend that you configure at least one loopback address
and that the router ID be a loopback address.
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
Used as the source of discovery hello's

!Assign a router ID
:router(config)# mpls ldp
:router(config-ldp)# router-id 10.1.1.1

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 is clear, which is the same as selecting the clear
keyword. If encrypted is chosen, the form of the password entered must
be encrypted. Encrypted implements TCP MD5 encryption.
The password is always displayed as encrypted when you view the running
configuration.

LDP Neighbors
Manage delivery of hellos

! LDP level for all neighbor
:router(config-ldp)# discovery hello holdtime 30
:router(config-ldp)# discovery hello interval 10
Use password authentication

! TCP MD5
:router(config-ldp)# neighbor 192.168.111.11 password secret

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
! Label advertised: explicit-null
" Indicates no PHP
! Label replaced: implicit-null (default)
:router(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.
When the GR session parameters are conveyed and the LDP session is up
and running, GR procedures are activated. Each peer advertises the
following information to its peers:
Reconnect timeSpecifies the maximum time the peer LSR should
wait for the restarting LSR to reconnect after a control plane failure;
the parameter is reconnect-timeout. The available range is 60 to 300
seconds; the default is 120 seconds
Recovery timeSpecifies the maximum time the restarting peer will
retain its MPLS forwarding state during the restart. Recovery time
starts when restarting LSR sends LDP initialization message
containing an FT flag; the parameter is forwarding-state-holdtime.
The default value is 180seconds; the range is 60 to 600 seconds
FT flag(Fault Tolerant) Indicates whether a restart could restore the
preserved (local) node state
If the control plane fails, the forwarding plane holds the LDP forwarding
state for twice the forwarding state holdtime. After restarting, the LSR
looks at its forwarding table to insure it has kept its information. If it has,
it starts the forwarding state hold timer, sends an LDP message, and waits
for the peer to send refreshed information. If the timer expires prior to
receiving an update from the peer, the recovering LSR clears the table of
entries.
If the forwarding state were not preserved through a restart, the FT flag
would be set to zero and advertised. Peers reset their information
immediately upon receiving an FT flag with a zero value.

LDP Graceful Restart
Enabling GR preserves NSF service

:router(config-ldp)# graceful-restart
Set timers as appropriate to neighbor relationship

graceful-restart forwarding-state-holdtime seconds
graceful-restart reconnect-timeout seconds
! Hold the local forwarding state while LDP restarts

" Default is 180 seconds; range is 60 to 600 seconds
! Set the remote neighbor reconnect wait time for local LDP
failure
" Default is 120 seconds; range is 60 to 300 seconds

Verifying LDP Configuration and Operation

The following pages illustrate commands used for LDP operation and
review.
Restarting LDP Sessions

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

Module 11 Verifying LDP Configuration and Operation
Restarting LDP Sessions
EXEC level command

Restart all sessions
Restart a specific session
:router#
clear mpls ldp neighbor

clear mpls ldp neighbor ipv4-address

Displaying LDP Parameter Information

Some show commands provide the necessary general LDP parameter
information, such as:
Protocol VersionCurrent LDP version on this router
Router IDCurrent router ID
Null labelStatus of the label at this router; implicit means the label
was stripped off at the previous peer (penultimate hop); explicit means
label will be stripped off at this router before delivery to final network
Session:
! HoldtimeTime session is to be maintained with the LDP peer
without receiving LDP traffic or a keepalive message from the peer
! Keepalive intervalsInterval between consecutive transmissions of
keepalive messages to a peer
! Backoff parametersInitial maximum session backoff time
Discovery:
! Link hellos:
! HoldtimeAmount of time a neighbor wants this router to
wait without receiving a hello message
! IntervalTime between transmission of consecutive hello
messages to neighbors
! Targeted hellos:
! HoldtimeAmount of time a not-directly connected
neighbor wants this router to wait without receiving a hello
message
! IntervalTime between transmission of consecutive hello
messages to neighbors not directly connected
Graceful restart (GR):

! StatusEnabled or disabled
! Reconnect TimeoutAmount of time a neighbor wants this router
to wait after LDP communication failure occurs and while holding
MPLS forwarding state information
! Forwarding State HoldtimeTime this router is willing to hold
MPLS forwarding state information

Displaying LDP Parameter Information
:router# show mpls ldp parameters
LDP Parameters:
Role: Active
Protocol Version: 1
Router ID: 10.1.1.1
Null Label: Implicit
Session:
Hold time: 180 sec
Keepalive interval: 60 sec
Backoff: Initial:15 sec, Maximum:120 sec
Global MD5 password: Disabled
Discovery:
Link Hellos: Holdtime:30 sec, Interval:15 sec
Targeted Hellos: Holdtime:90 sec, Interval:10 sec
Graceful Restart:
Enabled
Reconnect Timeout:120 sec, Forwarding State Holdtime:180 sec

Displaying LDP Discovery Information

LDP discovery information shows interfaces included in the MPLS LDP
implementation, as well as transport addresses for LDP neighbors.
Local LDP IdentifierThe LDP identifier for the local router, displayed
as address:number, where address is the router ID and number is the
label namespace
InterfacesInterfaces involved in LDP discovery, where:

! xmitIndicates that the interface is transmitting discovery hello
packets
! recvIndicates that the interface is receiving discovery hello
packets
LDP IDLDP ID of the peer
Transport AddressAddress associated with this peer
HoldtimeState of the forwarding holdtimer and its current value

Displaying LDP Discovery Information
:router# show mpls ldp discovery
Local LDP Identifier: 10.1.1.1:0

Discovery Sources: Interface for Peer discovered
Interfaces: peer discovery on this I/F
GigabitEthernet0/2/0/1 : xmit/recv
LDP Id: 10.11.11.11:0, Transport address: 10.11.11.11
Hold time: 30 sec (local:30 sec, peer:30 sec)
GigabitEthernet0/2/0/2 : xmit No peer on this I/F
Targeted Hellos:
10.1.1.1 -> 10.3.3.3 (active), xmit/recv
LDP Id: 10.3.3.3:0
Hold time: 90 sec (local:90, peer:90 sec)
10.1.1.1 -> 10.2.2.2 (active), xmit/recv

LDP Id: 10.2.2.2:0
Hold time: 90 sec (local:90, peer:90 sec)

Displaying LDP Neighbor Information

The LDP neighbor display includes peer identifiers, TCP connection
information, GR information, addresses at that peer, and state
information.
Peer LDP IdentifierLDP identifier of the neighbor (peer) for this
session
TCP connectionTCP connection used to support the LDP session,
shown in the following format:
! peer IP address.peer port
! local IP address.local port
Graceful RestartGraceful restart status (Yes or No)
StateState of the LDP session. Generally, this is Oper (operational),
but transient is another possible state
Msgs sent/rcvdNumber of LDP messages sent to and received from
the session peer. The count includes the transmission and receipt of
periodic keepalive messages, which are required for maintenance of the
LDP session
UptimeThe length of time that this session has been up for (in
hh:mm:ss format)
LDP discovery sourcesThe sources of LDP discovery activity that led
to the establishment of this LDP session
Addresses bound to this peerThe known interface addresses of the
LDP session peer. These addresses may appear as next-hop addresses
in the local routing table. They are used to maintain the LFIB

Displaying LDP Neighbor Information
:router# show mpls ldp neighbor Local and remote

TCP socket IDs
Peer LDP Identifier: 10.11.11.11:0
TCP connection: 10.11.11.11:23856 - 10.1.1.1:646
for this peer
Graceful Restart: No
Session Holdtime: 180 sec
State: Oper; Msgs sent/rcvd: 10241/10252
Up time: 6d04h
LDP Discovery Sources: path
GigabitEthernet0/2/0/1 to peer Peer
Addresses bound to this peer: addresses
10.11.11.11 172.21.116.110 192.168.12.11 192.168.21.11
192.168.111.11 192.168.112.11 192.168.113.11 192.168.114.11
192.168.115.11 192.168.116.11
Peer LDP Identifier: 10.2.2.2:0

TCP connection: 10.2.2.2:46086 - 10.1.1.1:646
Graceful Restart: No
Up time: 5d17h
LDP Discovery Sources:
Targeted Hello (10.1.1.1 -> 10.2.2.2, active/passive)
Addresses bound to this peer:
10.2.2.2 172.21.116.20 172.21.116.21 192.168.112.2
192.168.122.2
Additional information omitted for space

LDP Label Information Base

Looking at the Label Information Base (LIB) on the P1 router shows an
example of labels that get installed in the table and subsequently what
happens to the label information learned by P1.
Displaying MPLS Bindings 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/nIP prefix and mask for a particular destination
revRevision number that is used internally to manage label
distribution for this destination
local bindingLocally assigned label for a given prefix

remote bindingsOutgoing labels for this destination learned from
other LSRs. Each item in this list identifies the LSR from which the
outgoing label was learned and reflects the label associated with that
LSR. Each LSR in the transmission path is identified by its LDP
identifier

LDP Bindings Information
Label forwarding
information base:
Net: 172.16.95.0
Local label: 150 172.16.95.0
Remote labels: P1 PE5 CE5
P2 250
PE4 450
PE5 50
CE4 PE4 P2
PE5 allocates label 50 to network 172.16.95.0

PE5 advertises the network with label 50 to P1, P2
P1 allocates label 150 to network 172.16.95.0

P1 advertises the network with label 150 to P2, PE4, PE5
P2 allocates label 250 to network 172.16.95.0

P2 advertises the network with label 250 to P1, PE4, PE5
PE4 allocates label 450 to network 172.16.95.0

PE4 advertises the network with label 450 to P1, P2
:router# show mpls ldp bindings
0.0.0.0/0 , rev 29
local binding: label:IMP-NULL
remote bindings : Assigned
lsr:10.2.2.2:0, label:IMP-NULL
locally
10.1.1.1/32 , rev 2
local binding: label:IMP-NULL Assigned
remote bindings :
lsr:10.11.11.11:0, label:47
remotely;
lsr:10.2.2.2:0, label:16001 learned
lsr:10.3.3.3:0, label:16001
10.2.2.2/32 , rev 69
local binding: label:16001
remote bindings :
lsr:10.11.11.11:0, label:46
lsr:10.3.3.3:0, label:16002
10.3.3.3/32 , rev 87 EXP-NULL
local binding: label:16021 if lsr does not
remote bindings : want PHP
lsr:10.11.11.11:0, label:76
lsr:10.2.2.2:0, label:16019
lsr:10.3.3.3:0, label:IMP-NULL Some entries
omitted for clarity

Displaying LDP Graceful-Restart Information

LDP forwarding and GR information is also available using show
commands. The graceful restart information:
Forwarding State HoldtimerState of the holdtimer, running or not
running
GR neighborsNumber of graceful restartable neighbors
Neighbor IDRouter ID of each neighbor

UpNeighbor up or down
Connect countNumber of times the same neighbor has reconnected
Liveness timersState of the liveness timer (running or not running)
and its expiration time, if running
Recovery timerState of the recovery timer (running or not running)
and its expiration time, if running

Displaying LDP Graceful-Restart Information
:router# show mpls ldp graceful-restart
Forwarding State Hold timer : Not Running

GR Neighbors : 3
Neighbor ID Up Connect Count Liveness Timer Recovery Timer

--------------- -- ------------- ------------------ ------------------
10.2.2.2 Y 1 - -
10.3.3.3 Y 1 - -

Displaying MPLS Interfaces

The command show mpls interfaces displays all the MPLS-enabled
interfaces on the router.
InterfaceList of interfaces on which MPLS is enabled in any form
LDPIndication of support for LDP on the interface
TunnelIndication of support for traffic engineering tunnels
EnabledStatus of MPLS on the interface

Displaying MPLS Interfaces
:router# show mpls interface

Interface LDP Tunnel Enabled
-------------------------- -------- -------- --------
gigE 0/2/0/1 Yes Yes Yes
gigE 0/2/0/2 Yes No Yes
MPLS-enabled interfaces
! LDP enabled
! Traffic engineering tunnel supported
! Protocol status

MPLS Traffic Engineering

Traffic engineering enables an MPLS backbone network to replicate and
expand upon the Layer 2 ATM and Frame Relay network capabilities.
What is it?
Traffic engineering (TE) is the use of statistical techniques to attempt to
control network traffic. Observation of traffic to measure and determine its
characteristics and type is the first step. Using the observed information, a
model is created to predict traffic patterns. Implementing engineering of
traffic in the network means allocating resources, such as bandwidth and
queues, and then queuing traffic by characteristic.
How does it work for MPLS?

MPLS traffic engineering (MPLS-TE) 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.
Types of Traffic Engineering

Cisco IOS XR software implements two types of traffic engineering, MPLS-
TE and Differentiated Services TE (DS-TE).

Module 11 MPLS Traffic Engineering
MPLS Traffic Engineering
What is it?
Use statistical techniques to control network traffic
! Observation
" Measure
" Characterize
! Model
" Predict
! Implement
" Allocate resources
" Queue traffic
How does it work for MPLS?

Establish and maintain LSPs
! Use RSVP
Determine LSP path
! Resource requirements
! Available resources
" Bandwidth
! Resource info passed on by link-state IGP

Differentiated Services Traffic Engineering

Differentiated Services Traffic Engineering (DS-TE) has two modes, pre-
standard DS-TE and the IETF version of DS-TE. It defines eight traffic
classes, four of which are currently used, and two priorities, high and low.
Bandwidth Allocation Modes
DS-TE uses two methods to allocate the available bandwidth. These

allocation methods were required by service providers for MPLS-TE
support of DiffServ-aware traffic. These modes enforce different
constraints on the bandwidth based on traffic class types.
The models used are:
Maximum Allocation Bandwidth Constraints Model, also known as
MAM. This method is defined by IETF RFC 4125.
Russian Dolls Bandwidth Constraints Model, also known as RDM,
defined by IETF RFC 4127. This is the default method used by Cisco
Systems, Inc. in both MPLS-TE and DS-TE.

Module 11 MPLS Traffic Engineering
Differentiated Services Traffic Engineering
Traffic engineering modes

! Pre-standard DS-TE
! IETF DS-TE
Traffic classes
! Eight defined; four used; two priorities
Bandwidth allocation modes

! Service provider requirements for DiffServ-aware
support for MPLS traffic engineering
! Enforce different bandwidth constraints for
different traffic types
! Models
" Maximum Allocation Bandwidth Constraints Model
(RFC 4125)
" "Russian Dolls" Bandwidth Constraints Model
(RFC 4127)

Configuring MPLS Traffic Engineering

The following pages illustrate the basic steps for configuring MPLS traffic
engineering.
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. Turn on RSVP signaling and set the interfaces and bandwidth
3. Enable MPLS-TE interfaces
4. Create TE tunnels

Module 11 Configuring MPLS Traffic Engineering
Traffic Engineering Steps
1. Configure IGP routing protocol relationship

! IS-IS or OSPF
! Set IGP-to-TE configuration
" Router ID (required)
" Area (OSPF) or Level (ISIS)
2. Set RSVP signaling
! Set the interfaces
! Set the bandwidth on the interfaces Head
3. Configure MPLS-TE interfaces
! Enable the interfaces
P1 CE1
! Set other parameters PE1
4. Create TE Tunnels
! Turn on IPv4 for tunnel
! Set destination Tail
! Set bandwidth
! Set priority
CE2 PE2 P2
! Set tunnel advertisements
! Create paths
" Explicit
" Dynamic

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. Here are two examples of setting up IGP routing protocols (OSPF
or IS-IS) so that MPLS traffic engineering can be configured.
____________________________ Note _________________________
IS-IS supports MPLS-TE with the wide metric only.
__________________________________________________________________

Creating an IGP Relationship
IGP routing protocol

MPLS traffic engineering configuration
OSPF example:
:router(config-ospf)# mpls traffic-eng router-id loopback0

:router(config-ospf)# area 0
:router(config-ospf-ar)# mpls traffic-eng
:router(config-ospf-ar)#
IS-IS example:
:router(config-isis-af)# mpls traffic-eng level 1

:router(config-isis-af)# mpls traffic-eng router-id loopback0
:router(config-isis-af)#

Configuring RSVP for Traffic Engineering

To enter the RSVP configuration submode, use the rsvp command in
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 RSVP
configuration submode. This command changes the configuration mode to
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 for Traffic Engineering
Sets up signaling
Enter the RSVP context
Set the interfaces to be used
Set the total bandwidth available per interface for reservation
! Default is 75% of link bandwidth (when no amount is specified)
:router(config)# rsvp
:router(config-rsvp)# interface gigE 0/2/0/1
:router(config-rsvp-if)# bandwidth
% of link b/w
for all other traffic
TE
Physical tunnels
link Unused b/w
for other
RSVP RSVP signaled
bandwidth traffic: DSCP

Enabling MPLS-TE on Interfaces

To enable interfaces to participate in traffic engineering, enter MPLS
traffic engineering submode and add the interfaces.

Enabling MPLS-TE on Interfaces
Enter MPLS traffic engineering mode

Enable MPLS-TE interfaces
:router(config)# mpls traffic-eng

:router(config-mpls-te)# interface gigE 0/2/0/1
:router(config-mpls-te-if)#
gigE 0/2/0/1
P1 PE1 CE1
10.1.1.1
CE2 PE2 P2
10.2.2.2

Examining the MPLS-TE Infrastructure

Traffic engineering tunnels require an infrastructure of IGP, RSVP, and
MPLS-TE interfaces. Examining this information is an important way to
manage and troubleshoot problems.
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_idLocal IGP router ID and protocol type in use for TE
My_BC_Model_TypeThe bandwidth constraint model used currently
Signaling error holddownLink hold-down timer configured to handle
path error events before excluding link from topology
IGP IdAdvertising router identity
MPLS-TE IdTunnel headend ID
LinkMPLS-TE link type

Frag IdGateway protocol link state advertisement fragment ID
Nbr Intf AddressNeighbor interface address for this link
TE metricCost of this link
Physical BWPhysical line rate
Max Reservable BW GlobalMaximum amount of bandwidth, in
kilobits per second, that you can reserve in this link global pool
Max Reservable BW SubMaximum amount of bandwidth, in kilobits
per second, that you can reserve in this link subpool
Total Allocated BWTotal amount of bandwidth (in kbps) allocated at
this priority
Global Pool Reservable BWAmount of available bandwidth
reservable at this priority
Sub Pool Reservable BWAmount of available bandwidth reservable
at this priority

Module 11 Examining the MPLS-TE Infrastructure
Displaying MPLS-TE Topology
:PE1# show mpls traffic-eng topology IGP and other

My_System_id: 10.1.1.1 (OSPF lab area 0) pertinent information
My_BC_Model_Type: RDM
Signalling error holddown: 10 sec Global Link Generation 117
IGP Id: 10.1.1.1, MPLS TE Id: 10.1.1.1 Router Node (OSPF lab area 0)
Link[0]:Broadcast, DR:192.168.111.11, Nbr Node Id:27, gen:112

Frag Id:3, Intf Address:192.168.111.1, Intf Id:0
Nbr Intf Address:0.0.0.0, Nbr Intf Id:0
Default (75%) and
TE Metric:1, IGP Metric:1, Attribute Flags:0x0
Switching Capability:, Encoding: reserved bandwidth
BC Model ID:RDM
Physical BW:1000000 (kbps), Max Reservable BW Global:750000 (kbps)
Max Reservable BW Sub:0 (kbps)
Global Pool Sub Pool
Total Allocated Reservable Reservable
BW (kbps) BW (kbps) BW (kbps)
--------------- ----------- ----------
bw[0]: 2000 748000 0
bw[1]: 0 748000 0
Additional output omitted
IGP Id: 10.2.2.2, MPLS TE Id: 10.2.2.2 Router Node (OSPF lab area 0)
Additional output omitted

Displaying Link Management Interfaces

Looking at link management information is accomplished using the show
mpls traffic-engineering link-management commands.
Links countNumber of links configured for MPLS-TE
Link IDInterface name and IP address
! Local Intf IDLocally assigned index
! Link Status:
! Link label typeLabel type assigned based on LSP (PSC, LSC,
FSC)
! Physical BWLink bandwidth capacity in kilobits per second
! BCIDBandwidth constraint model identifier
! Max Reservable BWMaximum bandwidth reservable on this
link
! BC0/1Bandwidth available for each bandwidth constraint
traffic class
! MPLS-TE Link StateCurrent status of the TE link

! Inbound AdmissionInbound link admission policy
! Outbound AdmissionOutbound link policy
! IGP Neighbor CountNumber of neighbors directly reachable
on this link
! Max Res BW (RDM)Russian Doll model bandwidth maximum
! BC0/1Bandwidth available for each traffic class in RDM
! Max Res BW (MAM)Maximum Allocation model bandwidth
maximum
! BC0/1Bandwidth available for each traffic class in MAM
! Admin WeightLink administrative weight
! NeighborsNeighbors reachable on this link
! Flooding StatusFlooding status for configured area
! IGP AreaIGP area type and level

Displaying Link Management Interfaces
:PE1# show mpls traffic-eng link-management interfaces

System Information::
Links Count : 1 (Maximum Links Supported 100)
Link ID:: GigabitEthernet0/2/0/1 (192.168.111.1)

Local Intf ID: 3
Link Status:
Link Label Type : PSC

Physical BW : 1000000 kbits/sec
BCID : RDM
Max Reservable BW : 750000 kbits/sec (reserved: 0% in, 0% out)
BC0 (Res. Global BW): 750000 kbits/sec (reserved: 0% in, 0% out)
BC1 (Res. Sub BW) : 0 kbits/sec (reserved: 100% in, 100% out)
MPLS TE Link State : MPLS TE on, RSVP on, admin-up
Inbound Admission : reject-huge
Outbound Admission : allow-if-room
IGP Neighbor Count : 1
Max Res BW (RDM) : 750000 kbits/sec
BC0 (RDM) : 750000 kbits/sec
BC1 (RDM) : 0 kbits/sec
Max Res BW (MAM) : 0 kbits/sec
BC0 (MAM) : 0 kbits/sec
BC1 (MAM) : 0 kbits/sec
Attributes : 0x0
Admin Weight : 1 (OSPF), 10 (ISIS)
Neighbors :
ID 192.168.111.11
Flooding Status: (1 area)
IGP Area[1]: OSPF lab area 0, flooded

Displaying IGP-to-MPLS-TE Information

The show <igp> mpls commands display the relationship between MPLS-
TE and the underlying interior gateway protocol. The fields for the OSPF
information are:
OSPF Router with ID (Process ID) The loopback address or router ID
for this OSPF process
Area number and the number of TE links in the area for this router.
The area instance ID is provided
Link connection typePoint-to-point, NBMA, and others
Link IDThe destination address for this TE link
Interface AddressThe primary interface IP address this tunnel is
using
Neighbor AddressThe IP address of the other end of the primary
interface for this tunnel
Admin MetricAdministrative distance metric for this tunnel in the
IGP
Maximum bandwidthBandwidth capacity of this link
Maximum global pool reservable bandwidthMaximum available
reservable bandwidth in the global pool.
Number of PriorityNumber of priorities available for bandwidth
reservation (number of queues).
Global pool unreservedAmount of bandwidth for each priority
currently available.
PrioritiesBandwidth available for each traffic class (GMPLS)

Affinity BitAttribute values (0 or 1) required for links carrying this
tunnel. Valid values are from 0x0 to 0xFFFFFFFF, representing 32
attributes (bits)

Displaying IGP-to-MPLS-TE Information
:PE1# show ospf mpls traffic-eng link
OSPF Router with ID (10.1.1.1) (Process ID lab)
Area 0 has 1 MPLS TE links. Area instance is 12.

Link is associated with fragment 1. Link instance is 12
Link connected to Broadcast network
Link ID : 192.168.111.11
Interface Address : 192.168.111.1
Admin Metric : TE: 1
(all bandwidths in bytes/sec)
Maximum bandwidth : 125000000
Maximum global pool reservable bandwidth : 93750000
Number of Priority : 8
Global pool unreserved BW
Priority 0 : 93500000 Priority 1 : 93500000
Out Interface ID : 3
Affinity Bit : 0

Displaying Interface Information

Using the show mpls interface command, you can determine if LDP and
tunnels are configured and their configuration status.
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 Interface Information
Tunnels can be created on the I/F

MPLS Interfaces
:PE1# show mpls int

Interface LDP Tunnel Enabled
-------------------------- -------- -------- --------
RSVP Interfaces 75% of link bandwidth (gigE = 1000 Mbps)
:PE1# show rsvp int

Interface MaxBW (bps) MaxFlow (bps) Allocated (bps) MaxSu b (bps)
----------- ----------- ------------- -------------------- ------------
gigE 0/2/0/1 750M 750M 2M ( 0%) 0

Displaying RSVP Reservations

The show rsvp reservation command lists all reservations and includes
the following information:
Destination AddDestination address of the device for this reservation
DPortDestination port and tunnel ID
Source AddSource address of the device for this reservation
SPortSource port and LSP identifier
ProIndicates if this tunnel is protected

Input IFInterface on which the RSVP path was received
RateSum of all current bandwidth requests from MPLS-TE
Burst Preset to 1K (not used in MPLS-TE)

Displaying RSVP Reservations
:PE1# show rsvp reservation

Destination Add DPort Source Add SPort Pro Input IF Sty Serv Rate Burst
---------------- ----- ---------------- ----- --- ---------- --- ---- ---- -----
10.1.1.1 21 10.2.2.2 13 0 No SE LOAD 1M 1K
10.2.2.2 12 10.1.1.1 10 0 Gi0/2/0/1 SE LOAD 1M 1K

Creating MPLS-TE Tunnels

MPLS-TE tunnels are virtual interfaces that will be used for specifically
designated traffic.
Creating Tunnels
When the infrastructure to support tunnels is in place, the first step in
MPLS-TE is to create a tunnel, which is an interface and is configured in
interface configuration submode.

Module 11 Creating MPLS-TE Tunnels
Creating MPLS-TE Tunnels
Configure a tunnel using interface mode

! Locally significant identity
:PE1(config)# interface tunnel-te12

:PE1(config-if)#
P1 PE1 CE1
CE2 PE2 P2

Creating an Unnumbered IP Address

You set the origination IP address for an MPLS traffic engineering tunnel
by using the ipv4 unnumbered command in tunnel configuration
submode. We recommend the use of loopback address as the origination
address.

Creating an Unnumbered IP Address
Tunnel state is down until IP address is configured

! Headend IP address
! Loopback address is recommended
:PE1(config-if)# ipv4 unnumbered loopback0
:PE1(config-if)#
P1 PE1 CE1
10.1.1.1
CE2 PE2 P2

Setting a Tunnel Destination

To configure a destination address for an MPLS traffic engineering tunnel,
use the destination command in tunnel configuration submode, with a
reliable (typically the loopback) IP address for the destination.

Setting a Tunnel Destination
Tunnels require destinations

! IP address or hostname
:PE1(config-if)# destination 10.2.2.2

:PE1(config-if)#
P1 PE1 CE1
CE2 PE2 P2
10.2.2.2

Setting the Bandwidth

To set the bandwidth required for an MPLS-TE tunnel, use the signalled-
bandwidth command in tunnel configuration submode. Bandwidth is
specified in kilobits per second (kbps) and is reserved in the interfaces
global bandwidth pool. This is the maximum bandwidth available to this
tunnel.

Setting the Bandwidth
Tunnel bandwidth required end-to-end

! Specified in kilobits per second
! Maximum bandwidth available for this tunnel
! Reserved in interface global pool by default
:PE1(config-if)# signalled-bandwidth 1000
:PE1(config-if)#
10.1.1.1
To here P1 PE1 CE1
From here
CE2 PE2 P2
10.2.2.2

Setting the 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.
Paths are either dynamic, meaning they set up automatically and seek out
the best path based on the underlying IGP, or they are explicit, indicating
you configure the tunnel manually from origination point to destination
point, including all the interim routers.

Setting the Path Option
Provide multiple paths for a tunnel

! Explicit is a static path
! Dynamic uses the IGP's best path
! Lower path number is preferred
:PE1(config-if)# path-option 1 explicit name PATH_12
:PE1(config-if)# path-option 2 dynamic
:PE1(config-if)#
:PE1(config-if)# path-option 1 explicit name PATH_12

:PE1(config-if)# path-option 2 dynamic
:PE1(config)# explicit-path name PATH_12

:PE1(config-expl-path)# index 1 next-address strict ipv4
unicast 192.168.111.11
:PE1(config-expl-path)# index 2 next-address strict ipv4
unicast 192.168.112.2
192.168.111.11
P1 PE1 CE1
192.168.112.2
Alternate
CE2 PE2 P2

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.
The default tunnel priority is 7.

Setting Tunnel Priority
Tunnel priority
! Setup
! Hold
:PE1(config-if)# priority 1 1
:PE1(config-if)#
10.1.1.1
P1 PE1 CE1
CE2 PE2 P2
10.2.2.2

Setting IGP Tunnel Usage

To have the IGP use the tunnel in its shortest path first (SPF) calculations,
use the autoroute announce command when configuring the tunnel.

Setting IGP Tunnel Usage
IGP uses the tunnel in path calculation
:PE1(config-if)# autoroute announce

:PE1(config-if)#
10.1.1.1
P1 PE1 CE1
Used in
IGP here
CE2 PE2 P2
10.2.2.2

Examining MPLS Tunnel Operation

There are a variety of show commands that you can use to analyze the
traffic engineering tunnels.
Displaying MPLS-TE Tunnels

To see a specific tunnel and the related information, enter the show mpls
traffic-eng tunnels name tunnel name command.
The initial information is the signaling summary that provides the status
of signaling protocols including reoptimization, and fast reroute timers.
This is followed by tunnel name you selected and the destination IP
address.
Status information consists of administrative and operational status, path
validity, and signaling status with respect to the destination address. The
configured path option and type are used to determine path weight in
conjunction with the underlying IGP.
The configuration parameters should match the running configuration for
the tunnel being displayed. Some parameters will be assigned default
values if not specifically configured. Consult Cisco Systems, Inc.
documentation for further information.
The History section of the output refers to the most recent information
about the status of the tunnel.
Finally, the display provides the specific path to the destination using
interface addresses at each hop along the way to the destination, which is
the last address shown.

Module 11 Examining MPLS Tunnel Operation
Displaying MPLS-TE Tunnels
:PE1# show mpls traffic-eng tunnels name tunnel-te12

Signalling Summary:
LSP Tunnels Process: running
RSVP Process: running
Forwarding: enabled
Periodic reoptimization: every 3600 seconds, next in 356 seconds
Periodic FRR Promotion: every 300 seconds, next in 120 seconds
Auto-bw enabled tunnels: 0 (disabled)
Name: tunnel-te12 Destination: 10.2.2.2

Status:
Admin: up Oper: up Path: valid Signalling: connected
path option 1, type dynamic (Basis for Setup, path weight 2)

G-PID: 0x0800 (derived from egress interface properties)
Bandwidth Requested: 1000 kbps CT0
Priority
Config Parameters:
Bandwidth: 1000 kbps (CT0) Priority: 0 0 Affinity: 0x0/0xffff
Metric Type: TE (default)
AutoRoute: enabled LockDown: disabled Policy class: not set
Forwarding-Adjacency: disabled
Loadshare: 0 equal loadshares
Auto-bw: disabled
Fast Reroute: Disabled, Protection Desired: None
Path Protection: Not Enabled
History:
Tunnel has been up for: 00:03:06 (since Thu Dec 23 02:35:01 UTC 2010)
Current LSP:
Uptime: 00:03:06 (since Thu Dec 23 02:35:01 UTC 2010)
:PE1# show mpls traffic-eng tunnels brief

Signalling Summary:
Forwarding: enabled
TUNNEL NAME DESTINATION STATUS STATE
tunnel-te12 10.2.2.2 up up
PE2_t21 10.1.1.1 up up
Displayed 1 (of 1) heads, 0 (of 0) midpoints, 1 (of 1) tails
Displayed 1 up, 0 down, 0 recovering, 0 recovered heads
Two tunnels: one locally defined

one defined at PE2 with name t21

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 ProcessStatus of the LSP tunnels process
RSVP ProcessStatus of the RSVP process

ForwardingStatus of forwarding (enabled or disabled)
HeadSummary information about tunnel heads at this device
TailsSummary information about tunnel tails at this device

Periodic reoptimizationTime until the next periodic reoptimization
(in seconds)
Periodic FRR PromotionTime until the next periodic FRR promotion
(in seconds)
Periodic auto-bw collectionTime until the next periodic auto-bw
collection (in seconds)
RouterSummary information for router tunnels
SummarySummary information for FRR

BackupNumber of assigned backup tunnels
InterfacesNumber of MPLS-TE tunnel interfaces
When you use the show mpls traffic-engineering tunnels brief
command at the source and destination of the tunnel, only the heads and
tails of the tunnels are shown. The same display on routers between the
head and tail of the tunnel indicates midpoints.

Displaying MPLS-TE Tunnels (Cont.)
:PE1# show mpls traffic-eng tunnels brief

Signalling Summary:
Forwarding: enabled
TUNNEL NAME DESTINATION STATUS STATE
tunnel-te12 10.2.2.2 up up
PE2_t21 10.1.1.1 up up
Two tunnels: one locally defined

one defined at PE2 with name t21
:PE2# show mpls traffic-eng tunnels

Local tunnel omitted
LSP Tunnel 10.1.1.1 12 [10] is signalled, connection is up
Tunnel Name: PE1_t12 Tunnel Role: Tail Name and role
InLabel: GigabitEthernet0/2/0/1, implicit-null
Signalling Info:
Src 10.1.1.1 Dst 10.2.2.2, Tun ID 12, Tun Inst 10, Ext ID 10.1.1.1
Router-IDs: upstream 10.11.11.11
local 10.2.2.2 Source, destination, tunnel ID
Bandwidth: 1000 kbps (CT0) Priority: 0 0 DSTE-class: 4
Path Info:
Incoming:
Explicit Route:
Strict, 192.168.112.2
Strict, 10.2.2.2
Record Route: Disabled
Tspec: avg rate=1000 kbits, burst=1000 bytes, peak rate=1000 kbits
Session Attributes: Local Prot: Not Set, Node Prot: Not Set, BW Prot: Not Set
Resv Info: None
Record Route: Disabled
Fspec: avg rate=1000 kbits, burst=1000 bytes, peak rate=1000 kbits

Displaying MPLS-TE Tunnel Summary

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 Summary
Summary of TE tunnels
:PE1# show mpls traffic-eng tunnels summary
Signalling Summary:
Forwarding: enabled
Head: 1 interfaces, 1 active signalling attempts, 1 established
0 explicit, 1 dynamic
4 activations, 3 deactivations
0 recovering, 0 recovered
Mids: 0
Tails: 1
Periodic auto-bw collection: disabled
Fast ReRoute Summary:

Head: 0 FRR tunnels, 0 protected, 0 rerouted
Mid: 0 FRR tunnels, 0 protected, 0 rerouted
Summary: 0 protected, 0 link protected, 0 node protected, 0 bw protected
Backup: 0 tunnels, 0 assigned
Interface: 0 protected, 0 rerouted

Displaying Admission Control

Use the show mpls traffic-eng link-management admission-control
command to display the locally admitted tunnels and the parameters
associated with them.
Tunnels CountNumber of admitted tunnels
Tunnels SelectedNumber of tunnels displayed

Bandwidth descriptor legendBW pool type and status displayed with
the tunnel entry. In the sample output above, shown as RG (Locked BW
in global pool)
Tunnel IDTunnel identification
UP_IFUpstream interface used by this tunnel
DOWN_IFDownstream interface used by this tunnel
PrioritySetup and hold priorities for this tunnel
StateTunnel admission status

BandwidthTunnel bandwidth in kilobits per second. If an R follows
the bandwidth number, the bandwidth is reserved. If an H follows the
bandwidth number, the bandwidth is temporarily being held for a Path
message. If a G follows the bandwidth number, the bandwidth is from
the global pool. If an S follows the bandwidth number, the bandwidth is
from the subpool.

Displaying Admission Control
:PE1# show mpls traffic-eng link-management admission-control
System Information::
Tunnels Count : 1
Tunnels Selected : 1
Bandwidth descriptor legend:
B0 = bw from pool 0, B1 = bw from pool 1, R = bw locked, H = bw held
TUNNEL ID UP IF DOWN IF PRI STATE BW (kbits/sec)

------------------------ ---------- ---------- --- ------------- ---------------
10.1.1.1 12_10 - Gi0/2/0/1 0/0 Resv Admitted 1000 RB0

Displaying Link-Management Advertisements

Use the show mpls traffic-eng link-management advertisements
command to review the local link information that MPLS-TE link
management is currently flooding into the topology.
Flooding StatusState of the link management flooding system
Last FloodingNumber of seconds since the last flooding occurred

Last Flooding TriggerDescription of the event causing the last
flooding
Next Periodic Flooding InNumber of seconds until the next link state
advertisement is sent by TE
Diff-Serv TE ModePre-standard or IETF, if DiffServ is being used
Configured AreasNumber of IGP areas in use by TE
IGP AreaName of the first IGP area, followed by relevant
information regarding the IGP-to-TE relationship. Many of these
parameters have been covered previously

Displaying Link-Management Advertisements
:PE1# show mpls traffic-eng link-management advertisements

Flooding Status : ready
Last Flooding : 1388 seconds ago
Last Flooding Trigger : Periodic timer expired
Next Periodic Flooding In : 51 seconds
Diff-Serv TE Mode : Not enabled
Configured Areas : 1
IGP Area[1]:: OSPF lab area 0

Flooding Protocol : OSPF
IGP System ID : 10.1.1.1
MPLS TE Router ID : 10.1.1.1
Flooded Links : 2
Link ID:: 0 (GigabitEthernet0/2/0/1)

Link IP Address : 192.168.111.1
O/G Intf ID : 5
Designated Router : 192.168.111.11
TE Metric : 1
IGP Metric : 1
Physical BW : 1000000 kbits/sec
BCID : RDM
Max Reservable BW : 750000 kbits/sec
Res Global BW : 750000 kbits/sec
Res Sub BW : 0 kbits/sec
Downstream::
Global Pool Sub Pool
----------- ----------- Additional b/w
Reservable BW[0]: 749000 0 kbits/sec information omitted
Reservable BW[1]: 749000 0 kbits/sec

Displaying Statistics
To see the statistical information about link admissions, use the show
mpls traffic-eng link-management statistics command with
appropriate keywords. LSP admission and upstream and downstream link
admission statistics are shown. These are broken into Path and
Reservation (RESV) categories.
Setup RequestsNumber of requests for setup
Setup AdmitsNumber of requests admitted

Setup RejectsNumber of setups rejected
Setup ErrorsNumber of setup errors
Tear RequestsNumber of requests for tunnel teardowns
Tear PreemptsNumber of paths torn down due to preemption by
other tunnel requests
Tear ErrorsNumber of errors in tear requests

Displaying Statistics
:PE1# show mpls traffic-eng link-management statistics
LSP Admission Statistics::
Setup Setup Setup Setup Tear Tear Tear

Requests Admits Rejects Errors Requests Preempts Errors
-------- -------- -------- -------- -------- -------- --------
Path 9 9 0 0 8 0 0
Resv 9 9 0 0 8 0 0
Link Admission Statistics::
Link ID: GigabitEthernet0/2/0/1 (192.168.111.1)

DOWN
----
-------- -------- -------- -------- -------- -------- --------
Path 8 8 0 0 7 0 0
Resv 8 8 0 0 7 0 0
UP
----
-------- -------- -------- -------- -------- -------- --------
Path 0 0 0 0 0 0 0
Resv 0 0 0 0 0 0 0

Summary
Multiprotocol Label Switching (MPLS)
Describe Cisco IOS XR MPLS implementation

Explain MPLS forwarding infrastructure
Implement MPLS Label Distribution Protocol
Demonstrate MPLS Traffic Engineering dynamic implementation
Articulate an RSVP implementation for MPLS-TE

Module 12
Layer 3 Virtual Private Networks
Overview
Description
This module discusses the basic implementation of Layer 3 Virtual Private
Networks in the Cisco IOS XR operating system software.
Objectives
Describe Layer 3 virtual private networks (L3VPNs) and L3VPN
components
Implement a basic L3VPN using Cisco IOS XR software

Examine basic L3VPN operation

Layer 3 Virtual Private Networks Module 12

A Layer 3 virtual private network (L3VPN) is a set of sites connected by
means of an MPLS provider core network. At each customer location, one
or more customer edge (CE) routers attach to one or more provider edge
(PE) routers.
Customer Requirements
A typical customer who would be interested in Layer 3 VPN service might
have the following requirements:
A connection between two distant offices. The slide shows a customer
needing a connection between Boston, MA and Washington, DC.
The connection should be:
! Secure, so that data is not seen by either the service provider or
other customers using the service provider backbone
! Private, so that the customer does not need to change addressing
schemes and its addresses dont interfere with other customer
addresses
! Reliable, so that the customers network remains available no
matter what happens to the service provider network, and customer
data is available
Private addresses must be available so that network renumbering is
not required
A network infrastructure so that the customer does not have to create
and fund their own infrastructure

Module 12 Layer 3 Virtual Private Networks
Customer Requirements
Connection
between Boston
and Washington,
DC locations
Connection to be: P PE
! Secure Boston
! Private Service provider
! Reliable network
To use its own

private network
addresses P PE
Not create its own
networkuse service Washington, DC
provider network

Service Provider Solution

The service provider with L3VPN service provides a solution that:
Minimizes customer configuration
Builds relationships between its own provider edge (PE) devices and
customer edge (CE) devices
Provides a control plane implementation that:

! Uses reliable routing protocols for the core
! Sets up access on the CE side using static, external Border Gateway
Protocol (eBGP), Extended Interior Gateway Routing Protocol
(EIGRP), Open Shortest Path First (OSPF), or Routing Information
Protocol (RIP) routing
! Uses Multiprotocol-BGP (MP-BGP) in the service provider (SP) core
! Uses Multiprotocol Label Switching (MPLS) to provide label
forwarding
Implements a data plane for:
! Reliable packet forwarding
! MPLS label forwarding of packets
____________________________ Note _________________________
The slide shows a static route connection between the CE and PE. This
is not the only method of connection. eBGP, EIGRP, OSPF, or RIP can
be used as well.
__________________________________________________________________

Module 12 Layer 3 Virtual Private Networks
Service Provider Solution
Minimize the customer

configuration on the CE
Build relationships
! CE to PE
! PE to PE P PE CE
Control plane Boston
implementation Service provider Static Route
! IGP routing protocols network: OSPF or Or
IS-IS, BGP, MPLS eBGP
! Use static or eBGP
routing on customer side
! Use BGP on SP side
P PE CE
Data plane implementation
! Packet forwarding Washington, DC
! Use MPLS in provider
network

L3VPN Implementation Control Flow

The actual implementation of the L3VPN control flow uses configuration
elements in multiple areas of Cisco IOS XR software. The correlation
between the elements is essential for the VPN to work properly. Several
terms must be understood to complete the implementation.
Terms to Understand
Terms used in conjunction with creating VPNs in Cisco IOS XR software
are:
Virtual private network (VPN)
! Private data network that uses a shared infrastructure
! Provides security and privacy equal to private leased lines

! Used for either:
! Intranet access for widespread corporate connectivity
! Extranet for customer access
VPN routing and forwarding (VRF)
! IP technology that allows multiple independent instances of routing
and forwarding tables to co-exist
! Defined by Route Targets (RT)
! Networks (prefixes) are installed in the VRF when they match a
route target
! Route installation can be refined by using the BGP attach point
for VRF import and export in route policies to define conditions
! Default VRF
! Global routing table or public RIB; part of basic operating
system
! All routes not appearing in other specifically defined VRFs

Module 12 L3VPN Implementation Control Flow
Terms to Understand
Virtual private network (VPN)

Private data network that uses a shared infrastructure
Provides security and privacy equal to private leased lines
Used for either:
! Intranet for widespread corporate connectivity
! Extranet for customer access
VPN routing and forwarding (VRF)
IP technology that allows multiple independent instances of routing
and forwarding tables to co-exist
Defined by route targets
! Networks are installed in the VRF based on matching a route target
! Install process can be refined by using route policies to define
conditions
Default VRF
! Part of basic operating software
! All routes not appearing in other specifically defined VRFs

Route distinguisher (RD)

! Unique address qualifier used to identify distinct VPN customer
address space from other customer address spaces
! 8-byte field (64 bits)
! Type field (2 bytes)Defines the length of the other two fields
and the semantics of the administrator field
! Administrator field (4 bytes)Typically the autonomous system
number of the provider
! Assigned number field (2 bytes)Assigned by provider
! Defined in RFC 4364

VPNv4 address (VPNv4)
! Route distinguisher prepended to an IPv4 address
! Exchanged between PE routers using Multiprotocol-BGP (MP-BGP)
! MP-BGP provides a label

! Unique RDs allow duplicate private IP addresses to be installed in
different VRFs, keeping VPNs unique

Terms to Understand (Cont.)
Route distinguisher (RD)

Unique address qualifier used to identify distinct VPN customer routes
from other customer routes
8-byte field (64 bits)
! Type field (2 bytes)defines the length of other two fields and the
semantics of the administrator field
! Administrator field (4 bytes) typically the provider autonomous
system number
! Assigned number field (2 bytes)assigned by provider
Defined in RFC 4364
VPNv4 Address
RD prepended to IPv4 address
Exchanged between PE routers using Multiprotocol BGP (MP-BGP)
! MP-BGP assigns a label
Unique RDs allow duplicate private IP addresses to be installed in
different VRFs keeping VPNs unique

Route target (RT)
! BGP extended community attribute

! Identifies routers that may receive sets of prefixes with the
attribute
! RT formed by either of the following:
! as-number:nn
! as-number is 16-bit autonomous system
! nn is 32-bit number
! ip-address:nn
! ip-address is 32-bit number
! nn is 16-bit number
! Prefixes are advertised with an export RT
! RT matched against an import target for inclusion in VRF
Site of Origin (SoO)
! BGP extended community attribute

! Tags routes from CE prior to advertising to other PEs
! Detects routing loops for multihomed customer sites
! Works for situations when as-override is configured

! Provides route origination information for filtering
! Received route from either PE or CE with a SoO value that
matches local SoO
! Route is removed; likely learned from another PE
! Received route from CE with nonmatching SoO
! Route is accepted for redistribution
! Route already appears in RIB with different SoO; new SoO is
ignored
! Received route from CE with no SoO
! Route is accepted and SoO value is added to table as next
hop for the CE, and route is then redistributed

Terms to Understand (Cont.)
Route target (RT)

BGP extended community attribute
! Identifies one or more routers that may receive sets of prefix with
the attribute
Prefixes are advertised by MP-BGP with RT attribute appended
! Export route target
RT matched for prefix inclusion in VRF
! Import route target
Site of Origin (SoO)
BGP extended community attribute
! Tags routes from CE prior to advertising to other PEs
Detects routing loops for multihomed customer sites
! Works for situations when as-override is configured
Provides route origination information
! Can be used for filtering

L3VPN Routing Infrastructure

For the customer sites to share routes and move data through their
network, an integrated infrastructure is needed.
The service provider has its own internal routing protocol, such as
Intermediate System-to-Intermediate System (IS-IS) or OSPF, which it
uses to maintain the core network. The routes are exchanged by PE routers
and provider core (P) routers. The P routers install only the core network
routes in their RIB. The PE routers maintain separate routing information
for the core and the customer routes through the use of VRFs.
As stated previously, when connecting to customer sites, some method of
exchanging routesstatic routing, eBGP, EIGRP, OSPF, or RIPis
needed. Customer routes do not show up in the providers core RIB, but are
installed in the VRF related to the customers appropriate VPN. The
provider routes must not show up in the customers RIB. Thus, the PE
router has the following routing tables:
Default VRF RIB
! Core routes installed by core IGP
! Internet routes installed by BGP
VPN routing and forwarding tables
! Sets of sites with matching routing requirements
! Information from CE routers
! MP-BGP information from other PE routers
Multiprotocol BGP (MP-BGP) exchanges routes between the PEs using the
neighbor definitions, VPNv4 information, and any extended community
information, such as route target or site-of-origin.

L3VPN Routing Infrastructure
VPNv4
route
exchange
Core IGP
P1 PE1 CE1
Boston
Core IGP
Core IGP
routing Routing
protocol
Washington, DC
P2 PE2
CE2
Core IGP
PE and CE routers exchange VPN routes using a routing protocol

P and PE routers exchange core routes using IGP (OSPF, IS-IS)
PE routers exchange VPNv4 labels and routes using MP-BGP

Route Distinguisher Implementation

The primary function of the route distinguisher (RD) is to keep overlapping
IPv4 addresses globally unique. The RD is configured at the PE router as
part of the setup of a VPN site. It is not configured on the customer
equipment and is not visible to the customer. Simple VPN topologies
require one RD per customer. More complex VPN topologies, in which a
customer site belongs to multiple VPNs, require additional RDs.
Route Propagation Steps

The following occurs in route propagation:
1. CE1 sends an IPv4 route update
2. PE1
a. installs the route into the VRF
b. prepends 64-bit RD to the IPv4 routes in the VRF, resulting in
globally unique 96-bit VPNv4 prefix
c. appends the export route target
3. The VPNv4 prefix is propagated using a Multiprotocol BGP (MP-BGP)
session to other PE routers
4. PE2
a. matches the incoming route target with the correct VRF
b. strips the RD from the VPNv4 prefix, resulting in an IPv4 prefix
c. installs the prefix into the appropriate VRF based on the import
route target
5. PE2 advertises the IPv4 prefix update to the CE2

Route Distinguisher and Route Propag
2a. PE installs routes in

VRF 2b. PE prepends RD
onto CE IPv4 addresses 2c. PE appends the RT
to create VPNv4 prefix
1. CE sends
IPv4 update
3. VPNv4 prefix
propagated by P1 PE1 CE1
MP-BGP to
other PE Boston
Service provider
network: OSPF,
MP-BGP
Washington, DC
P2 PE2 CE2
5. IPv4 update
sent to CE
4a. PE matches the RT
with correct VRF 4b. RD removed by PE, 4c. IPv4 address
resulting in original 32-bit installed in VRF RIB
IPv4 address
ation

L3VPN Implementation Data Flow

The implementation of the data flow uses the two labels provided by MP-
BGP and MPLS.
L3VPN Packet Flow

The label stack is used to indicate the disposition of the VPN packet to the
egress PE router. The ingress PE router labels an incoming IP packet with
two labels. The top (outer) label in the stack is the LDP label for the egress
PE router, which guarantees that the packet will traverse the backbone
and arrive at the egress PE router. The second (inner) label in the stack is
assigned by the egress PE router using MP-BGP, and points directly
toward an outgoing IP address, VRF, or CE.
The two-level label stack satisfies all of the following L3VPN forwarding
requirements:
P routers perform label switching on the LDP-assigned label toward the
egress PE router
The egress PE router performs label switching on the second label and
forwards the IP packet toward the CE router
The steps are:
1. The CE forwards a packet toward the PE5 router
2. The ingress PE5 router accepts the packet and assigns a VPN/MP-BGP
label (A) based on the destination VRF
3. The PE5 router then adds the MPLS outer label (B) for the outgoing
path to the egress PE6 router and sends the packet on
4. The P1 router exchanges the outer MPLS label (B to C)
5. The P2 router pops the outer MPLS label (C) and sends the packet;
unless penultimate hop popping (PHP) is turned off
6. The egress PE6 router receives the packet, matches the inner label (A)
to a VRF entry and strips the inner label (A)
7. The egress PE6 router sends the packet to the CE as determined by the
VRF entry

Module 12 L3VPN Implementation Data Flow
L3VPN Packet Flow
Label A IP packet
2
Label A = Destination VRF label 3
Label B,C = MPLS label Label B Label A IP packet 1
IP packet
4 PE1
P1 CE1
Label C Label A IP packet Boston
MPLS
Washington, DC
P2 PE2 CE2
5
Label A IP packet IP packet
Label A IP packet
6 7

Configuration
The configuration of L3VPNs involves several steps within several
configuration modes of Cisco IOS XR software. You must compile several
pieces of information and create documentation to accomplish this task
successfully.
Configuration Requirements
The requirements for a core network to support L3VPNs are:
Routing protocolsan IGP, BGP and MPLS LDP

Forwarding methodMPLS forwarding
What to Configure
On a PE router running Cisco IOS XR software, the following pieces will be
configured:
VPN definitionA specific VRF definition completed in global
configuration mode
PE to CE definitionA specific VRF definition within the routing
protocol used to exchange routes and on the interfaces to the CE
PE to PE definitionA definition within BGP that identifies neighbors
that will participate in the VPN
VPN, BGP, and MPLS relationship definitionA specific entry in the
BGP base definition and the neighbor definition that makes basic BGP
become MP-BGP and interrelates BGP to MPLS

Module 12 Configuration
Configuration
What must be defined in the core?

Routing protocols: IGP, BGP, MPLS LDP
Forwarding method: MPLS
What to configure?
VPN definition
Provider edge (PE) to customer premises (CE)
Connection from provider edge to provider edge
(PE-to-PE)
The relationship between the VPN , BGP, and
MPLS

Configuration Steps
The steps to successfully creating the L3VPN on the PE are:
1. Define the VPN by creating a VRF in global configuration mode
2. Assign the VRF to an interface facing the customer (CE)
3. Create a routing relationship with the CE
! Add the VRF under the protocol definition
! Define the appropriate address family

4. Create the BGP relationships
! Define the VRF, RD, and address family
! Define the MPLS connection (VPNv4)

! Connect the iBGP neighbors
The connecting point for the VPN configuration is the VRF name. The VRF
name must be the same at all levels of the VPN configuration. However,
the VRF name is locally significant, only.
On the CE, the only required definition is:
Define a matching routing relationship with the PE

____________________________ Note _________________________
In our example and the accompanying lab, we will use static routing
between the PE and CE.
__________________________________________________________________
____________________________ Note _________________________
VRF names are case sensitive and must match at all level of the
configuration.
__________________________________________________________________

Configuration Steps
What are the steps?

On the provider edge router (PE):
! Define the VPN by creating a VRF
! Assign the VRF to the interface attached to
customer premises equipment (CE)
! Create the route relationship to the CE
" Add the VRF under appropriate route protocol
definition
" Define the address family
" Define the routes with the destination IPv4 address
! Create the BGP relationships
" Define the VRF, RD, and address family
" Turn on BGP-to-MPLS connection
" Connect the iBGP neighbors for the VPN
On the customer premises router (CE):

! Define the routing relationship to the PE
The VRF names must all be the same for a single
VPN definition
! Case sensitive
! At all levels of the configuration of the VPN

VRF Configuration
To configure a VRF for the definition of the L3VPN, enter the vrf name
command in global configuration mode. The address-family command is
required, and the options are either IPv4 or IPv6 unicast. Route targets are
set up to determine routes to import into the VRF and export to BGP. The
description command is optional and is limited to 1022 characters.
The import and export commands may be used with route policies, also.
Route policies can be in addition to, or in place of, route targets in the VRF
address family. If policies are to be used, they must be defined first.

VRF Configuration
VRF Configuration
:PE1(config)# vrf GROUP_1
:PE1(config-vrf)# description L3VPN for GROUP_1
:PE1(config-vrf)# address-family ipv4 unicast
:PE1(config-vrf-af)# import route-target 65000:2
:PE1(config-vrf-af)# export route-target 65000:2
VRF name
Description is optional
P1 PE1 CE1
Address family defines traffic type
BGP route targets define VRF inclusion
! Route policies may be used
P2 PE2 CE2
Configuration
from PE1

VRF Interface Configuration

The configuration for the customer-facing interface has the important
requirement that the IP address be assigned to the VRF, not the interface
itself. Any IP address assigned to the interface must first be removed and
the VRF configured. Then the IP address can be configured.
On any interface with an existing IP address, an error will occur if you:
Attempt to configure a VRF, but without an IP address

Attempt to configure a VRF with an IP address
The result will be a failed configuration with the following messages:
% Failed to commit one or more configuration items during an
atomic operation, no changes have been made. Please use 'show
configuration failed' to view the errors
:router(config-if)#show config failed
!! CONFIGURATION FAILED DUE TO SEMANTIC ERRORS

interface gigabitEthernet 0/2/0/28
vrf GROUP_1
!!% The interface's numbered and unnumbered IPv4/IPv6 addresses
must be removed prior to changing or deleting the VRF !
The existing IP address must be removed first.

The VRF name must match the globally configured VRF name.

:PE1(config)# interface gigE 0/2/0/28

:PE1(config-if)# vrf GROUP_1
:PE1(config-if)# ipv4 address 172.16.12.2/24
Remove interface IP address first

Create VRF name
P1 PE1 CE1
Re-assign IP address
P2 PE2 CE2
Configuration
from PE1

Static Route Configuration

In this example (and in our lab for this course), we are defining a static
route connection between the PE and CE routers.
You use the router static command to begin the process of configuring
any static routes. In the creation of VPNs, you must configure a VRF
definition for the routing protocol, by entering a vrf name command. As in
all VRF definitions, an address family is defined and currently is limited to
the IPv4 unicast type.
You configure the static address with its mask followed by the destination,
which can be an IP address, a physical interface type, a tunnel, or another
VRF.

:PE1(config)# router static

:PE1(config-static)# vrf Group_1
:PE1(config-static-vrf)# address-family ipv4 unicast
:PE1(config-static-vrf-afi)# 172.16.12.0 /24 gigabitEth 0/2/0/28
Define the VRF

!Name consistency
!Address family P1 PE1 CE1
!Static route
!Next-hop address
P2 PE2 CE2
Configuration
from PE1

BGP Configuration
Your first step in making BGP recognize VPN configuration is to set up a
connection with MPLS. This is done by entering the address-family
vpnv4 unicast command. This effectively provides access to the extended
communities; that is, lets MP-BGP add the necessary VPNv4 and extended
community information to the packets and forward them using MPLS.
Once again, create a VRF using the vrf name command.
Next, define a route distinguisher using either of these options:
as-number:nn or ip-address:nn
Let the system define its own unique route distinguisher by selecting
the auto keyword
The redistribute command lets the routes in the VRF be advertised by
the routing protocol by BGP.
____________________________ Note _________________________
A new address-family is a new capability, which can only be negotiated
during BGP session establishment, adding the VPNv4 address-family
definition to an existing active BGP configuration will cause the BGP
session to that neighbor to terminate.
__________________________________________________________________

BGP Configuration
:PE1(config)# router bgp 65000

:PE1(config-bgp)# address-family vpnv4 unicast
:PE1(config-bgp-af)# exit
:PE1(config-bgp)# vrf GROUP_1

:PE1(config-bgp-vrf)# rd 65000:1
:PE1(config-bgp-vrf)# address-family ipv4 unicast
:PE1(config-bgp-vrf-af)# redistribute connected
:PE1(config-bgp-vrf-af)# redistribute static
:PE1(config-bgp-vrf-af)# exit
P1 PE1 CE1
Turn on the MPLS relationship
! VPNV4 address family
Consistent VRF name
! RD is arbitrary; could be set automatically
! Address family definition for traffic type
! Allow the routes from the CE to be carried to P2 PE2 CE2
other interested PEs
Configuration
from PE1

BGP Configuration
For the VPN information to be exchanged with PEs participating in the
VPN, the MP-BGP connection is established using the address-family
vpnv4 unicast command under the specific participating neighbor
definitions.
____________________________ Note _________________________
A new address-family is a new capability, which can only be negotiated
during BGP session establishment, adding the VPNv4 address-family
definition to an existing active BGP configuration will cause the BGP
session to that neighbor to terminate.
__________________________________________________________________

BGP Configuration (Cont.)
BGP Configuration (Cont.)
:PE1(config-bgp)# neighbor 10.2.2.2

:PE1(config-bgp-nbr)# remote-as 65000
:PE1(config-bgp-nbr)# address-family vpnv4 unicast
Identify neighbor PEs to be used in VPN

!MP-BGP: Address family VPNv4
configured
P1 PE1 CE1
P2 PE2 CE2
Configuration
2011, Cisco Systems, Inc. All rights reserved. Version 4.0.1
from PE1
Cisco ASR 9000 EssentialsModule 12/18

Examining L3VPN Operation

To determine the operation status of L3VPNs, you use commands that
relate to the different areas of VRF configuration.
Displaying Configuration Information

One of the first steps in determining the status of VPNs is to verify the
configuration is correct. Use the show run command, followed by the
specific areas of interest, to see the information.
You want to verify that the VRF name is consistent throughout each part
of the related configuration.
____________________________ Note _________________________
When issuing show command dealing with VRF names, remember the
names are case sensitive.
__________________________________________________________________

Module 12 Examining L3VPN Operation

:PE1# show run vrf
vrf GROUP_1
import route-target
65000:1
!
export route-target Same VRF name
65000:1
Display the configured VRF
P1 PE1 CE1
0/2/0/28
:PE1# show run int gigE 0/2/0/28
interface gigabitEthernet 0/2/0/28
vrf GROUP_1
ipv4 address 172.16.12.2 255.255.255.0
P2 PE2 CE2
Display the configured customer interface
IP address assigned to VRF, not interface Displayed
from PE1

Displaying Configuration Information (Cont.)

This same technique should be used to see how the routing protocols are
configured. Remember that the VRF names must be consistent. If route
policies are used, verify that they are doing what they were intended to do.
The redistribute commands refer to the routes from the CE.

:PE1# show run router static vrf GROUP_1

router static
vrf GROUP_1
10.255.12.0 /24 gigabitEthernet 0/2/0/28
Same VRF name
Display the configured CE static route
:PE1# show run router bgp 65000 vrf GROUP_1
router bgp 65000
vrf GROUP_1
P1 PE1 CE1
rd 65000:1
!
redistribute connected
redistribute static
Display the configured BGP VRF information P2 PE2 CE2
Route distinguisher definition
Address family type Displayed
- Redistribute routes based on CE routes
from PE1

The BGP autonomous definition that will carry the VPN must be defined
for VPNv4 address family traffic.
Finally, be sure that the BGP PE neighbor definitions, for which sessions
are required, have the necessary VPNv4 address family definition, so that
advertisements can be forwarded.


:PE1# show run router bgp 65000
router bgp 65000 AS VPNv4
address-family ipv4 unicast support
! (MP-BGP)
address-family vpnv4 unicast
Display the general BGP configuration

Address family indicates AS support for VPNv4 routes
:PE1# show run router bgp 65000 neighbor 10.2.2.2

router bgp 65000 Establish VPN
neighbor 10.2.2.2 advertisements P1 CE1
PE1
use neighbor-group INTERNAL (MP-BGP)
address-family vpnv4 unicast
Display the configured BGP neighbor definition

P2 PE2 CE2
Address family indicates advertise VPNv4 routes
Displayed
2011, Cisco Systems, Inc. All rights reserved. Version 4.0.1 from PE1

Displaying VRF Information

You can use the show vrf <name> detail command to review and verify
the compilation of related VPN information, such as the route targets set,
the route policies being used, the route distinguisher, and the interfaces.


:PE1# show vrf GROUP_1 detail
VRF GROUP_1; RD 65000:1; VPN ID not set

Description not set
Interfaces:
GigabitEthernet0/2/0/28
Address family IPV4 Unicast
Import VPN route-target communities:
RT:65000:1
Export VPN route-target communities:
RT:65000:1
No import route policy
No export route policy
Compilation of specified VPN information

! RD from BGP configuration
! Interfaces
! Import and export route target communities
! Any route policies being employed

Displaying RIB after VPN

Once the VPN has been created, the prefixes that are to be part of the VPN
should no longer appear in any of the default VRF RIBs. This should be
confirmed by showing routes in both the PE router where the definition is
located and all the P routers.
In the slides on the opposite page, the RIB from PE1 is shown and the
prefixes no longer appear.

Displaying RIB after VPN

Displaying RIB After VPN (for Print)
:PE1# show route
S* 0.0.0.0/0 [1/0] via 172.21.116.1, 3d16h
L 10.1.1.1/32 is directly connected, 3d16h, Loopback0
O 10.2.2.2/32 [110/3] via 10.2.2.2, 3d14h, tunnel-te12 VPN prefixes
O 10.3.3.3/32 [110/3] via 10.3.3.3, 3d14h, tunnel-te13
O 10.4.4.4/32 [110/3] via 192.168.111.11, 3d16h, GigabitEthernet0/2/0/1 not in the
O 10.5.5.5/32 [110/3] via 192.168.111.11, 3d16h, GigabitEthernet0/2/0/1 default
O 10.11.11.11/32 [110/2] via 192.168.111.11, 3d16h, GigabitEthernet0/2/0/1 VRF
L 127.0.0.0/8 [0/0] via 0.0.0.0, 3d02h
C 172.21.116.0/24 is directly connected, 3d16h, MgmtEth0/RSP0/CPU0/0
is directly connected, 3d16h, MgmtEth0/RSP1/CPU0/0
L 172.21.116.12/32 [0/0] via 172.21.116.12, 3d16h, MgmtEth0/RSP0/CPU0/0
Some prefixes
O 192.168.117.0/24 [110/2] via 192.168.111.11, 3d16h, GigabitEthernet0/2/0/1 left out for
L 192.168.121.1/32 is directly connected, 3d16h, GigabitEthernet0/2/0/2 clarity
O 192.168.122.0/24 [110/3] via 10.2.2.2, 3d14h, tunnel-te12
O 192.168.123.0/24 [110/3] via 10.3.3.3, 3d14h, tunnel-te13
Default RIB at the edge (PE1)


Displaying VPN Routes

Next, verify that the routes in the concerned VRF are also correct. They
must be the routes received from the routing exchange between the CE and
the PE and must not have any of the general routes. In this slide, note the
presence of the next hop in the default VRF that is used. You should be
sure that it points to the correct BGP neighbor.
Further you can verify the routes in the VRF based on the routing
protocols. The slides show the static routes and the routes learned from
BGP by using variations of the show route vrf command.


:PE1# show route vrf GROUP_1
Gateway of last resort is not set
S 10.255.12.0/24 is directly connected, 00:17:27, GigabitEthernet0/2/0/28

B 10.255.21.0/24 [200/0] via 10.2.2.2 (nexthop in vrf default), 00:06:18
C 172.16.12.0/24 is directly connected, 00:24:51, GigabitEthernet0/2/0/28
L 172.16.12.2/32 is directly connected, 00:24:51, GigabitEthernet0/2/0/28
VPN routes
!Routes are not in default RIB
Note reference to VRF default next hop
Displaying VPN Routes (Cont.)

:PE1# show run router static vrf GROUP_1
router static
vrf Group_1
10.255.12.0/24 GigabitEthernet0/2/0/28
Static routes in VPN

:PE1# show route vrf all bgp
VRF: GROUP_1

VPN routes learned from BGP


You can display detailed information about specific routes in the VPN. The
slide on the opposite page shows BGP and MPLS information.


:PE1# sh route vrf Group_1 172.16.12.0/24 detail
Routing entry for 172.16.12.0/24

Known via "connected", distance 0, metric 0 (connected)
Installed Jul 22 18:10:48.089 for 00:28:39
Routing Descriptor Blocks
directly connected, via GigabitEthernet0/2/0/28
Route metric is 0
Label: None
Tunnel ID: None
Extended communities count: 0 MP-BGP
Route version is 0x1 (1) VPN
No local label label
IP Precedence: Not Set
QoS Group ID: Not Set
Route Priority: RIB_PRIORITY_CONNECTED (2)
No advertising protos.
Specific information about individual prefixes

!Shows BGP instance
!Shows next hop information
!Shows MP-BGP label information

Displaying BGP Address Family Information

You verify the BGP status by using show bgp commands. The show bgp
vpnv4 unicast summary command shows local configuration information
as well as neighbors participating in this BGP VPN instance.


:PE1# show bgp vpnv4 unicast sum
BGP generic scan interval 60 secs
Table ID: 0x0
BGP is operating in STANDALONE mode.
Process RcvTblVer bRIB/RIB LabelVer ImportVer SendTblVer StandbyVer

Speaker 7 7 7 7 7 7
Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd

10.2.2.2 0 65000 5382 5385 7 0 0 00:12:42 2
BGP VPN address family support information

!Shows local configuration information
!Shows neighbors for this BGP instance

Displaying BGP VPN Information

You can look at specific BGP VPN information by using a form of the show
bgp vrf <name> command.
The first slide shows the basic command output which includes the local
information like route distinguisher, VRF status, and status of the prefixes
in the VRF, including the validity and best path information.
You can also display additional specific information about individual
prefixes as shown in the second slide. This display includes the MPLS label
information as well as the extended community value.

Displaying BGP VPN Information

Displaying BGP VPN Information (for Print)
:PE1# show bgp vrf GROUP_1
BGP VRF GROUP_1, state: Active
BGP Route Distinguisher: 65000:1
VRF ID: 0x60000002

i - internal, r RIB-failure, S stale
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 65000:1 (default for vrf GROUP_1)
*> 10.255.12.0/24 0.0.0.0 0 32768 ?
*>i10.255.21.0/24 10.2.2.2 0 100 0 ?
*> 172.16.12.0/24 0.0.0.0 0 32768 ?
*>i172.16.21.0/24 10.2.2.2 0 100 0 ?
Processed 4 prefixes, 4 paths
Routes in the VRF

Route distinguisher
Displaying BGP VPN Information (Cont.)
:PE1# sh bgp vrf Group_1 172.16.91.0/24

BGP routing table entry for 172.16.12.0/24, Route Distinguisher: 65000:1
Versions:
Process bRIB/RIB SendTblVer
Speaker 3 3
Local Label: 16001
Last Modified: Jul 22 18:18:26.752 for 00:23:02
Paths: (1 available, best #1)
Advertised to PE peers (in unique update groups):
10.2.2.2
Path #1: Received by speaker 0
Advertised to PE peers (in unique update groups):
10.2.2.2
Local
0.0.0.0 from 0.0.0.0 (10.1.1.1)
Origin incomplete, metric 0, localpref 100, weight 32768, valid, redistributed, best, gro
Received Path ID 0, Local Path ID 1, version 3
Extended community: RT:65000:1
Specific VPN route display

!Shows route distinguisher being used
!Shows import route target extended community
!Shows received VRF (inside) label

You can verify the prefixes that are being imported into the VRF by using
the show bgp vrf name imported-routes. The display indicates the best
path and validity of the entries and the neighbor that provided the routes

Display BGP VPN Information (Cont.)

Displaying BGP VPN Information (Cont.)
:PE1# show bgp vrf GROUP_1 imported-routes

BGP VRF GROUP_1, state: Active
BGP Route Distinguisher: 65000:1
VRF ID: 0x60000002

i - internal, r RIB-failure, S stale
Network Neighbor Route Distinguisher Source VRF
*>i10.255.21.0/24 10.2.2.2 65000:1 GROUP_1
*>i172.16.21.0/24 10.2.2.2 65000:1 GROUP_1
Processed 2 prefixes, 2 paths
VPN imported routes display

!Shows the prefixes imported into this VRF
!Shows the status and origin of the imported routes

Testing VPN Connectivity

Using the ping command, you can test the viability of routes through the
VPN.


:PE1# ping vrf GROUP_1 172.16.21.2
Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 172.16.21.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
Ping PE to PE by using VRF name

:CE1# ping 172.16.21.1

Sending 5, 100-byte ICMP Echos to 172.16.21.1, timeout is 2 seconds:
!!!!!
Ping CE to CE

Displaying MPLS Information

From the perspective of PE1, you will see no specific labels for routes at the
other end of the VPN (in PE2). However, from the VRF route table we
know that routes in PE2 are available using the loopback address of PE2,
which is available through the default VRF. Looking at the MPLS
forwarding table, using the show mpls forwarding command, you see
the label information for PE2 loopback address.

:PE5# show mpls forwarding

Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
This is the
16001 Aggregate GROUP_1: Per-VRF Aggr[V] \
GROUP_1 1112 VPN label
16002 Pop 10.11.11.11/32 Gi0/2/0/1 192.168.111.11 0
16003 Pop 192.168.116.0/24 Gi0/2/0/1 192.168.111.11 0
16004 Pop 192.168.115.0/24 Gi0/2/0/1 192.168.111.11 0
16005 Pop 192.168.112.0/24 Gi0/2/0/1 192.168.111.11 0
16006 Pop 192.168.114.0/24 Gi0/2/0/1 192.168.111.11 0
16007 Pop 192.168.12.0/24 Gi0/2/0/1 192.168.111.11 0
16008 Pop 192.168.21.0/24 Gi0/2/0/1 192.168.111.11 0 This is the
16009 Pop 192.168.117.0/24 Gi0/2/0/1 192.168.111.11 0 path to the
16010 Pop 10.2.2.2/32 tt12 10.2.2.2 1914 other end of
16011 43 10.4.4.4/32 Gi0/2/0/1 192.168.111.11 515988 the VPN
16012 76 10.5.5.5/32 Gi0/2/0/1 192.168.111.11 515988
16013 41 10.6.6.6/32 Gi0/2/0/1 192.168.111.11 515988
16014 Unlabelled 192.168.122.0/24 tt12 10.2.2.2 0
16015 45 192.168.124.0/24 Gi0/2/0/1 192.168.111.11 0
16016 77 192.168.125.0/24 Gi0/2/0/1 192.168.111.11 0
16017 42 192.168.126.0/24 Gi0/2/0/1 192.168.111.11 0
16018 Pop 192.168.113.0/24 Gi0/2/0/1 192.168.111.11 0
16019 Pop 10.3.3.3/32 tt13 10.3.3.3 0
16020 Unlabelled 192.168.123.0/24 tt13 10.3.3.3 0

Summary
Describe Layer 3 virtual private networks (L3VPN) and L3VPN
components
Implement a basic L3VPN using Cisco IOS XR software
Examine basic L3VPN operation

Module 13
Cisco ASR 9000 Layer 2 Architecture
Overview
Description
This module provides a detailed description of the Layer 2 service
architecture supported by the Cisco ASR 9000, including an overview of
terminology, service building blocks, and an illustration of Layer 2 service
implementation.
Objectives
Describe Carrier Ethernet concept
Describe the Cisco ASR 9000 Layer 2 service architecture

Describe how Ethernet Flow Points (EFPs), Ethernet Virtual Circuits
(EVCs), bridge-groups, and Multi-protocol label switching (MPLS) are
involved in building Layer 2 services

Cisco ASR 9000 Layer 2 Architecture Module 13

Consumers, businesses, and mobile broadband carriers are driving demand
for data, voice, and video service delivery on a single, consolidated network.
Service Providers (SPs) are responding by deploying Carrier Ethernet.
The Cisco IP Next Generation (IP NGN) is a network model used to define
end-to-end multiplatform Carrier Ethernet solutions as defined by the
Metro Ethernet Forum (MEF). This model can be divided into logical
network layers: Access, Aggregation or Distribution, Edge, and Core. The
Cisco ASR 9000 is designed to play a key role at the edge of the IP NGN
Carrier Ethernet network.
The Access layer is where the customer network ends and the Carrier
Ethernet network begins. The Access device can be a digital subscriber
line access multiplexor (DSLAM), passive optical network (PON) device or
any switch or router with a Fast Ethernet, Gigabit Ethernet, or Ten
Gigabit Ethernet uplink. The Access devices provide broadband access and
aggregation of end-user traffic into a multiplexed Ethernet access link. In
case of a residential customer this could be triple-play (voice, video, and
data) traffic. For a business customer, it could be a Metro Ethernet
service. For a mobile broadband customer, it could be a wireless
multiservice backhaul.
The Aggregation layer is an extension of the edge. It performs efficient
aggregation and transport service between the access and Edge and Core
layers. It supports a number of protocols and topologies. The Cisco ASR
9000 supports point-to-point and multipoint services over an Ethernet, IP,
or IP/MPLS foundation.
The multiservice edge (MSE) devices provide service awareness and
intelligence. The core is the backbone of the network and it provides
meshed connectivity between edge devices as well as access to specific
services such as Internet access, Video-on Demand (VoD), streaming video,
content sources, and voice network access. A deep packet inspection (DPI)
device can perform Layer 3 termination. Service access and policy is
handled by MSE, Broadband Network Gateway (BNG), or Broadband
Remote Access Server (BRAS) devices.
132 Version 4.0.1 Cisco ASR 9000 Series Essentials

Cisco IP Next Generation (IP-NGN) Carrier Ethernet Architecture
Portal Monitoring Billing Subscriber Identity Address Policy

Mobile Database Mgmt Definition
Content Farm
Policy Control Plane (per subscriber)
Residential
Access Aggregation/Distribution Edge
MSPP
VOD TV SIP
Cable
STB
Untagged L2 P-to-P native BRAS/BNG

Business
Single-tagged L2 P-to-P over PW
Core Network
ETTx
Double-tagged L2 MP native bridging MPLS /IP
Corporate
802.1q L2 MP VPLS
802.1ad L3 routed
And so on
Residential
DSL DPI
U-PE Content Farm
N-PE or PE
Agg MSE
PON
STB
VOD TV SIP

Customer and Carrier Ethernet Network Relationship

The customer equipment (CE) device connects to the Carrier Ethernet
network (CEN) at the user-network interface (UNI). A UNI is a physical
Ethernet interface. In Release 1 of the Cisco ASR 9000, Gigabit Ethernet
and Ten Gigabit Ethernet UNI interfaces are supported. The CE can be a
Layer 2 or Layer 3 device, and it may or may not be owned by the Service
Provider (SP).
The UNI is defined by the MEF as the demarcation point between
customer and SP networks.
The CEN may involve a number of platforms and technologies. It provides
the end-to-end service to the CE between UNIs.

Customer and Carrier Ethernet Network Relationship
CE
CE: UNI
Customer equipment
Router or IEEE 802.1 bridge or switch CEN
UNI:
UNI
User-network interface CE
UNI CE
Gigabit Ethernet or 10GE
Demarcation between customer and provider
Carrier Ethernet network:
Provides Metro Ethernet service between CEs
May use various transports/media

Service Architecture Types

The Cisco ASR 9000 provides 1:1, 1:N, or any-to-any connectivity.
Layer 2 VPNs can be provisioned between switches, hosts, or routers and
may allow data link layer connectivity between separate sites.
Communication between sites is based on Layer 2 addressing.
The MEF defines three Ethernet Virtual Circuit/connection (EVC) service
types: E-Line, E-LAN, and E-Tree. These services are based on logical
point-to-point, multipoint, and rooted multipoint network topologies,
respectively.
Within the Cisco CEN, Layer 2 virtual connections are used to provide
point-to-point or multipoint interconnection between customer service
instances. The Cisco ASR 9000 Layer 2 architecture can support all MEF
service and topology types.
Point-to-point E-Line service provides a transparent connection between
customer UNIs (or EFPs). Customer traffic is tunneled between sites.
E-Line can be used to provide a broad range of Ethernet services. Service
criteria can be defined per subscriber.
Multipoint E-LAN and E-Tree service provides a multipoint Ethernet
service between multiple customer UNIs. Customer sites are
interconnected by an Ethernet broadcast domain; MAC learning and
forwarding is performed. The CEN appears like a LAN segment to the
customer devices. E-LAN can be used to provide a broad range of
multipoint Ethernet services. Service criteria can be defined per E-LAN
service.

Service Architecture Types
CE CE
CE
UNI UNI
UNI
Multipoint-to-multipoint Rooted-multipoint
Point-to-point
UNI UNI
CE UNI CE UNI UNI
CE UNI
CE CE
CE
Three logical topology types :

Point-to-point EVC (E-Line)
Multipoint-to-multipoint EVC (E-LAN)
Rooted-multipoint EVC (E-Tree)

Converged Service Deployment

SPs are constantly looking to match their network architecture and ability
to the traffic patterns of their customers. SPs want a single physical port
to be able to deploy a wide variety of services, including Layer 2 and Layer
3 operation on the same physical interface. SPs also want an end-to-end
network that supports multiple service types with many attributes (QoS,
HA, and so on) per service.

Converged Service Deployment
Service providers are looking to simultaneously:

Leverage a single physical port to provide a range of services to
residential, business, and mobile transport customers
Consolidate the physical media using Carrier Ethernet for their
service infrastructure
These requirements include, among other things, the ability to
provide:
Layer 2 VPN, Layer 3 termination, Layer 3 VPN, legacy interface
and wholesale multicast services
Scalability, manageability, security, and reliability.
Support for integrated service delivery over a converged IP and
MPLS network architecture requires flexibility at the network and
node level.

Cisco ASR 9000 = Flexible Ethernet Edge

In its initial release, the Cisco ASR 9000 is focused on the Metro Ethernet
and broadband transport market space. It aggregates Ethernet from the
customer edge and can transport the Ethernet frames using native
Ethernet, IP, or MPLS. It can also provide Layer 3 service (L3VPNs,
Internet access, and so on). This flexibility allows the ASR-9k to perform a
variety of network functions. It can be deployed by SPs and enterprises
alike.

Module 13 Cisco ASR 9000 = Flexible Ethernet Edge
Cisco ASR 9000 = Flexible Ethernet Edge
To meet SP requirements, the Cisco ASR 9000 provides

service multiplexing over a single physical port, a
capability commonly referred to as multiplexed Ethernet
UNI. This involves the following:
Flexible VLAN matching
Flexible VLAN rewrite operations
Flexible service mapping (Layer 2 and Layer 3 on the same
physical port)
Flexible transport options (P2P and MP services on the
same physical port)
The Cisco ASR 9000 can fulfill the role of an access PE
or aggregation PE node.

Flexible Ethernet Mapping + Flexible Transport

Customer-to-service mapping is illustrated here as a connection between
an Ethernet-based data flow on the access (customer) side and a service on
the trunk side.
Flexible Ethernet mapping is the ability to process and classify different
Ethernet frame types, each with different attributes (Ether types, VLAN
tags, CoS bits, and so on). The Cisco ASR 9000 uses the Ethernet flow
point (EFP) concept to provide flexible Ethernet mapping.
Flexible Transport is found on the trunk side. Each Ethernet flow from
the customer or access side is mapped or connected to a service on the
trunk side. These service types can be native Ethernet, IP, or IP/MPLS-
based; and these form the basis for L2VPN.

Flexible Ethernet Mapping + Flexible Transport
mapping
Multiple L2 frame types Multiple L2 services
Flexible PE
Untagged L2 P2P native Ethernet

Single-tagged L2 P2P over PW
Customer Double-tagged L2 MP native Ethernet bridging
Network 802.1q L2 MP VPLS
802.1ad L3 routed
Access side: Trunk side:

Customer Ethernet attachment Local Layer 2 cross-connect
circuit (AC) Local Layer 2 bridging
Terminates on an Ethernet flow EoMPLS/VPWS
point (EFP)
VPLS/H-VPLS
Layer 3 routing

Attachment Circuit Types
Connection to the customer

The Layer 2 circuit, which connects the customer to a provider edge (PE)
router, is referred to as the attachment circuit (AC). ACs can connect to
physical and logical ports. Several AC circuit types are supported.
The AC circuit mapped to an entire physical port operates in port mode.
There are no subinterfaces involved.
The customer could connect to a logical subinterface or Ethernet flow point
(EFP). In this case, the frames ingress to a physical port are classified by
some frame attribute into one of possibly many logical subinterfaces.
A customer can also connect using Ethernet link aggregation (LAG)
bundles. Bundles are logical combinations of physical ports and are
treated as a single port in most cases.
The Cisco ASR 9000 also supports PW ACs. PW ACs are used in
hierarchical virtual private LAN service (H-VPLS) deployments. In this
case, a PW is a spoke circuit that connects into a VPLS mesh.
All of these customer connection types are described throughout this
module.

Attachment Circuit Types
A customer attachment circuit (AC) connects at the UNI on

the customer-facing side.
Supported AC types:
Physical Ethernet interface (port mode)
Subinterfaces (EFPs)
Bundled interfaces
Ethernet PW (H-VPLS)
UNI CEN UNI
CE1 CE2
Attachment Virtual Attachment

circuit 1 circuit circuit 2

Cisco ASR 9000 Carrier Ethernet Network Example
Flexible PE Deployment Example

P devices are devices such as routers and switches in the SP network that
do not directly connect to customer networks. PE devices connect directly
to customer networks via CE devices. A Carrier Ethernet network can
have many layers between the UNI (CE) devices and the core (P) devices.
Additional levels of hierarchy can be introduced into the network to
improve scalability. The functionality of a PE device can be divided into
different categories depending upon how it is actually provisioned and
deployed.
With the ability to support such features as GE and 10GE interfaces and
H-VPLS, the Cisco ASR 9000 can perform the role of a user-provider edge
PE (U-PE), a network-provider edge PE (N-PE), or a PE-aggregation (PE-
Agg) device.

Cisco ASR 9000 Carrier Ethernet Network Example
The Cisco ASR 9000 supports many hierarchical features, such as

H-VPLS, allowing it to be deployed as a U-PE, N-PE, or PE-Agg
device.
CE U-PE
CE U-PE
PE-Agg
Core
CE
U-PE N-PE P
U-PE
CE

PE Roles
Multilayered Provider Edge
The U-PE is typically located at or near the customer handoff and it

performs the role of aggregation device, aggregating traffic from many
Ethernet platforms.
The N-PE is the handoff to the core device. In the Cisco CEN, this could be
an XR 12000, or a CRS-1 for example.
A PE-Agg device might perform PW aggregation for an H-VPLS
deployment.
This terminology is described in draft-ietf-l2vpn-12-framework-05.txt and
RFC 4026.

PE Roles
U-PE is customer facing

Usually an aggregation device
The spoke of hub and spoke
N-PE is network facing
Connects into the IP or MPLS core
Located at the POP
PE-Agg is a nonstandard term to refer to a PE that
aggregates a number of U-PEs.

Layer 2 or Layer 3 VPN

A virtual private network (VPN) is a private communications network
often used to provide a confidential link between organizations over a
public network or the Internet. The VPN traffic is generally carried over
the Internet using standard protocols or over an SP network under a
service level agreement (SLA) between the VPN customer and the SP. The
VPN can be broadly divided into two categories namely L2VPN and
L3VPN.
Layer 3 VPNs require interaction between customer and SP routing
policies and are typically a more expensive solution. Layer 3 VPN provides
better partial-mesh support than Layer 2 VPN.
Layer 2 VPNs are transparent to all upper layer protocols and do not
require any Layer 3 interaction between customer and SP routing. A
Layer 2 VPN is typically less expensive than Layer 3 VPNs.

Module 13 Layer 2 or Layer 3 VPN
Layer 2 or Layer 3 VPN
VPN
Virtual: Multiple services share physical media
Private: Each service is logically independent
Layer 2 VPN
Ethernet point-to-point or multipoint connectivity between
customer LAN sites or service endpoints
Layer 3 VPN
IP connectivity or routing between service endpoints or
gateways

Why Layer 2 VPN?

Layer 2 VPNs from an SP provides only a Layer 2 interface to its customer,
and the customer is responsible for creating and managing the Layer 3
overlays.
The SP provides Layer 2 connectivity, and the customers build their own
VPN, using the provided Layer 2 connectivity as one of the building blocks.
In a L2VPN service, the SP does not need to know about the customers
topology, about the customer's policies, or about the customer's routing.
In essence, the customers build their own network, using data link
resources obtained from the SP.

Module 13 Layer 2 or Layer 3 VPN
Why Layer 2 VPN?
Tunneling services-customers manage own

routing, QoS, and so on; do not expose Layer 3
to SP
Single common infrastructure for IP and legacy
services
Simplify services at reduced cost-operational
efficiency

Aligning Service Names and Standards

This chart compares common names for various Ethernet service types. A
number of names may exist for a given service depending upon which
standards body or vendor is describing the service.
MEF (E-Line, E-LAN) names are now getting wider usage in the industry,
and these service names are used in this course.

Module 13 Aligning Service Names and Standards
Aligning Service Names and Standards
Cisco service
Metro Ethernet Forum IETF (MPLS) IEEE
name
Ethernet private QinQ, .1ad Ethernet wire
E-Line line (EPL) service (EWS)
(point-to- Virtual private
point) wire service
Ethernet virtual .1Q Ethernet relay
(VPWS)
private line service (ERS)
(EVPL)
Transparent QinQ, .1ad Ethernet
LAN service multipoint service
(TLS) Virtual private (EMS)
E-LAN
LAN service
(multipoint) Ethernet virtual .1Q Ethernet relay
(VPLS)
connection multipoint service
service (EVCS) (ERMS)

What is the Cisco ASR 9000 Layer 2 Infrastructure?

The Cisco ASR 9000 Layer 2 Infrastructure combines the elements of
Ethernet flow points (EFPs), xconnects, bridge-domains, and MPLS
pseudowires to provide a highly flexible Carrier Ethernet service
foundation. Its flexibility allows it to support a number of services and
standards.

Module 13 What is the Cisco ASR 9000 Layer 2 Infrastructure?
What is the Cisco ASR 9000 Layer 2 Infrastructure?
A software infrastructure that provides Ethernet,

Layer 2, and Layer 2 VPN service support.
Uses the following concepts:
Ethernet flow point (EFP): Instance of an Ethernet
service on a physical port.
Cross-connect: Point-to-point connection between
EFPs
Bridge domain (BD): Multipoint connection between
EFPs
Supports service convergence over Ethernet and MPLS
Addresses flexible Ethernet edge requirements
Complies with MEF, IEEE, IETF standards

What is an EFP?
EFP = Service Instance
An EFP represents an endpoint of a particular service on a given network

device. An EFP is defined by a set of filters. These filters are applied to all
ingress traffic to classify which frames belong to a particular EFP. An EFP
filter is a set of entries, where each entry looks very much like the start of a
packet (ignoring source/destination MAC address); so, each entry is usually
0, 1 or 2 VLAN tags. A packet that starts with the same tags as an entry in
the filter is said to match the filter, if the start of the packet does not
correspond to any entry in the filter, the packet does not match.

Module 13 What is an EFP?
What is an EFP?
What Is an EFP?
An EFP represents a G0/0/0/1

service instance on a subinterfaces
physical interface Service A
EFP = subinterface G0/0/0/1.1 L2 transport
Multiple EFPs can exist on
a single UNI or uplink port Service B
Can be used to create Service C
VLAN access, trunk, and G0/0/0/1.2 L2
transport G0/0/0/1.3 L2
tunnel ports. transport
EFP Service D
G0/0/0/1.4 l2
EFP transport
EFP
EFP Interface Physical Ethernet interface

Flexible Frame Matching/Service Mapping

EFP VLAN Filters:
Single tagged frame. VLAN tag can be single, list or range or any (1 to
4094).
encapsulation dot1q {any | vlan-id[,vlan-id[- vlan-id]]}
Double tagged frame: First VLAN tag must be unique, second VLAN tag
can be any unique value or a list or range
encapsulation dot1q vlan-id second-dot1q {any | vlan-
id[,vlan-id[- vlain-id]]}
Default tag: match all frames tagged or untagged that are not matched by
other more specific service instances. Similar concept as class-default in
the QoS MQC
encapsulation default
Untagged: match untagged frames
encapsulation untagged\

Flexible Frame Matching/Service Mapping
EFPs enable flexible Outer VLAN Inner VLAN

mapping of frames into tag tag
Layer 2 services.
s-vlan 30
Mapping is based on
c-vlan any
VLAN tagging: s-vlan 20
802.1Q, 802.1ad s-vlan 402- 410
Single-tag or double-tag untagged

s-vlan 300, 400
Unique or multiple values
(ranges or lists) default
s-vlan 50
c-vlan 50
Untagged traffic
Unclassified traffic (default)

EFP Attributes
Service Architecture
The slide on the next page shows the model used to describe an EFP in this
module. Filters are applied on ingress and egress, partly to ensure that
only traffic appropriate to that EFP is allowed to pass, and partly to ensure
that the packets passed to the Tag Operations (manipulations such as
pushing/popping tags) are suitable for the operations to be performed.
Note that, logically, another filter is can be applied on egress. This filter is
the same as the ingress filter, and ensures that traffic leaving via this EFP
conforms to the same criteria as the ingress traffic (with allowances made,
of course, for source/destination MAC addresses being the other way
around). No Egress filtering is the default.
____________________________ Note _________________________
Cisco IOS XR Software Release 3.7.3 introduces EFP Egress Filtering
on the Cisco ASR 9000. The purpose of egress EFP filtering feature is
to implement a way of filtering EFP egress traffic, ensuring that all the
egress traffic on a given EFP complies with the ingress matching
criterion.
By using the ethernet egress-filter command, you can configure
egress EFP filtering in either global or Layer 2 subinterface mode as
follows:
ethernet egress-filter strict configures Egress EFP Filtering
in global configuration mode.
ethernet egress-filter {strict | disabled} configures Egress
EFP Filtering in Layer 2 subinterface mode.
__________________________________________________________________

EFP Attributes
An EFP ID is generated by the software at the time it is created (port/subinterface

number).
Service definitions are bound to the EFP:
Classify ingress frames belonging to particular service based on VLAN tags
Rewrite VLAN tag (optional) before forwarding
Define forwarding actions and behavior
Egress rewrite defines the operation to be performed on frames being transmitted out of
this EFP (always symmetric)
QoS, multicast, OAM, and security features are bound to service instances
Ingress filter Egress filter
EFP
Tag ops
From Filter
physical Towards a
interface xconnect or
Ingress bridge-
Tag ops
domain LC NPU
Filter
Egress
NPU

EFP Layer 2 Transport encap list

Flexible EFP types:
Port Mode (including bundles): Matches all frames received/sent on
a physical Ethernet port. No l2tranport command is used in this
case.
Port Mode EFP (default encapsulation): Matches all frames
ingress on a physical port.
Untagged EFP: Match untagged frames.
Native: (encap dot1q 10, untagged) C-tag preservation option using
an OR expression.
Outer VLAN only : Can be dot1q or dot1ad Ethertype. Exact VLAN
match, list, or range.
QinAny: Single specified outer VLAN and any inner VLAN tag.
QinQ: Single specified outer VLAN and a specified inner VLAN
exact, list or range.

EFP Layer 2 Transport encap list for R3.7.3
Port mode or physical port (including bundles)

Port mode (default EFP)
Untagged EFP
Native
C-tag preservation option only encap dot1q 10, untagged (like native)
encap dot1q native configures no c-tag preservation. Not supported.
Outer VLAN only
Dot1q or dot1ad
Single, list, or list of ranges
Max 9 ranges
For example, encap dot1q 10-20; encap dot1ad 300, 400, 500
QinAny: Single, specified outer VLAN + at least 1 more unspecified inner VLAN
QinQ: Single, specified outer VLAN + 1 more inner VLAN, which can be a list or range
Encap dot1q 10 second-dot1q 20-30
Additional options
exact: No additional VLAN tags beyond those specified in match statement
For example, encap dot1q 10 exact

EFP Implementation
The encapsulation command (along with the match command) sets the
format for packets entering and leaving this EFP. Packets with tags
matching the encapsulation specification are allowed into this EFP, and all
packets that leave will generally match the encapsulation specification.
The encapsulation command takes the following forms, and produces the
corresponding ingress filters. In the absence of any tag manipulation, the
egress filter are the same as the ingress filter (with the exception that
source and destination MAC matching are swapped).

EFP Implementation
Specify an EFP at the subinterface level:

Configure subinterface as l2transport
Specify matching with encapsulation command
Specify any VLAN operations with push, pop, or
translate commands (optional)
Specify QoS treatment with service-policy
commands (optional)
Port parameters such as speed, MTU, duplex,
negotiation set at interface level.

EFP CLI Configuration Structure

IOS-XR uses a structured CLI for EFP and EVC configuration.
The layer2tranport command identifies a subinterface (of a physical port
of bundle-port parent interface) as an EFP.
The encapsulation command is used specify matching criteria.
The rewrite command is used to specify VLAN tag rewrite criteria.
The service-policy input or service-policy-output commands are used
to specify QoS treatment.
The ethernet cfm command is used to set OAM features.
The ethernet services access-group command is used to set Layer 2
security ACLs.

EFP CLI Configuration Structure
Create an EFP at the gigabitEthernet 0/2/0/38.1 l2transport

subinterface level,
specify l2transport
encapsulation
Specify VLAN
matching rewrite ingress tag
Configure VLAN service-policy input, output

rewrite Optional
ethernet cfm
Configure QoS
service-policy
ethernet-services access-group
Configure OAM
Configure security

EFP Creation
From global configuration mode, enter subinterface configuration mode to
begin EFP creation. Specify the subinterface as a l2transport EFP with
the l2transport command.
In subinterface configuration mode, specify the encapsulation type of the
outer tag as dot1ad, dot1q, or untagged, or use a default tag scheme to
accept any unmatched frames.

EFP Creation
:router(config)# interface gigabit ethernet 0/1/0/10.10 l2transport

:router(config-subif)# encapsulation ?
default Packets unmatched by other service instances
dot1ad IEEE 802.1ad VLAN-tagged packets
dot1q IEEE 802.1Q VLAN-tagged packets
untagged Packets with no explicit VLAN tag
Create subinterface and specify l2transport

Specify matching criteria with encapsulation
commands

EFP Flexible Frame Matching

Filter traffic by VLAN Tag
One EFP can match unique VLAN tags, lists of VLAN tags, or ranges of
VLAN tags. It can match untagged frames, single-tagged frames, double-
tagged frames, 802.1q, QinQ, or 802.1ad.
Default frame matching can be used to accept all tagged or untagged
frames that are not matched by other more specific EFPs (much like class-
default in MQC).
Encapsulation classification: 802.1Q (type 0x8100) and 802.1ad (type
0x88a8) can co-exist on the same physical port. Ingress classifier is
Ethertype-aware (802.1Q vlan 10 can be mapped to a different service than
802.1AD vlan 10).

Module 13 EFP Flexible Frame Matching
EFP Flexible Frame Matching
Support for exact Physical Ethernet

interface (GE or 10GE)
match or best match
14 Exact
Support for VLAN VLAN: 14

100
lists, ranges or lists, 101
Range:
100 to 102
and ranges 102
200
Support for default 203

210
List:
200, 203, 210
and untagged frame Outer/Inner:

300 100
classification 300,100
400 1 Match outer 400,

400 2 inner range: 1 to 3
400 3
400 11
Match outer 400,
400 17
inner list: 11,17,34
400 34

Loose Match Classification Rule

If the exact command is not used, a loose match rule is followed.
For example, encap dot1q 10 matches all the frames with outermost
VLAN tag = 10. The frame can have a single tag or double tag as long as its
outer most tag is 10.
For double tag VLAN matching, encap dot1q 10 second-dot1q 50
matches all the frames with outermost two tags = (10, 50).


Unspecified fields are treated as wildcards.

Ex. encapsulation dot1q 10 matches any frame with outer tag equal to 10:
10
10 50
Ex. encapsulation dot1q 10 second-dot1q 50 matches any frame with

outermost tag as 10 and second tag as 50:
10 50
10 50 4

Longest Match Classification Rule

When a mix of different frame types are received on ingress to a physical
interface with multiple EFPs (each with single, double tag and default tag
matching configuration) a longest match rule is used. This is similar to a
routing table lookup.
For example, under the same physical port, you may have the following
three different service instance matching configuration:
int g0/0/0/1.1 l2transport
encapsulation dot1q 10
encapsulation dot1q 10 second-dot1q 100
encapsulation dot1q 10 second-dot1q 128-133
The frames in the slide on the next page are classified according to the
loose and longest match rules as shown.

Longest Match Classification Rule
Frames are mapped to EFP with the longest matching

set of classification fields.
EFP 1
10
VLAN 10
10 200 EFP 2
Interface
S-VLAN 10
10 100 C-VLAN 100
EFP 3
S-VLAN 10
10 130
C-VLAN 128-133

EFPs with Default Encapsulation

The encapsulation default command can be used to match all frames
tagged or untagged that are not matched by other more specific service
instances. This is similar in concept to QoS class-default.
This command can also be used for all-to-one bundling.

EFPs with Default Encapsulation
EFP with default encapsulation matches all frames otherwise unmatched

by any other EFP on the same port:
VLAN 10
VLAN 10
VLAN 20
VLAN 20
VLAN 50
Untagged Default
EFPs Interface
Use a default EFP to match all tagged and untagged traffic on a port (all-
to-one bundling):
VLAN 10
VLAN 20
VLAN 50 Default
Untagged
Interface EFP Interface

Priority Resolution for Multiple Matches

This list shows the priority resolution in the event of a frame that matches
multiple EFPs on a parent interface.

Priority Resolution for Multiple Matches

Priority resolution for multiple matches
QinQ with exact option 300 100 exact
QinQ (no exact option) 300 100
QinAny 300 Any
Single VLAN with exact option 300 exact

Single VLAN with no exact option 300
Untagged Untagged
Encap default No other match
Note: Bundles are treated like another physical port. EFPs on a bundle
are equivalent to EFPs on a physical interface.

Matching Example (double-tagged 802.1q)

EFP Matching CLI
This example shows the CLI options and the steps for configuring Gigabit
Ethernet subinterface 10.10 as a Layer 2 transport EFP that will filter
ingress frames from the parent interface that are double-tagged with an
outer 802.1q tag of 10 and an inner dot1q tag of x.

Matching Example (double-tagged 802.1q)
:router(config)# interface gigabitEthernet 0/2/0/10.10 l2transport

:router(config-subif)# encapsulation dot1q ?
<1-4094> Start of VLAN range
<1-4094> Single VLAN id
any Match any VLAN id
priority-tagged IEEE 802.1ad priority-tagged packets
:router(config-subif)# encapsulation dot1q 10 ?
comma comma
exact Do not allow further inner tags
second-dot1q IEEE 802.1Q VLAN-tagged packets
<cr>
:router(config-subif)# encapsulation dot1q 10 second-dot1q ?
Match outer and inner dot1q tags

Matching Example (802.1ad)

EFP Matching CLI
This example shows the CLI options and steps for configuring gigabit
Ethernet subinterface 0.20 as a l2transport EFP that will filter ingress
frames from the parent interface that are double tagged with an outer
802.1ad tag of 20 and an inner dot1q tag of x.

Matching Example (802.1ad)

:router(config-subif)# encapsulation dot1ad ?
:router(config-subif)# encapsulation dot1ad 10 ?
:router(config-subif)# encapsulation dot1ad 10 dot1q ?
Match outer 802.1ad tag and inner 802.1q tag

EFP Special Rules

Special rules for priority tagged frames and exact frame matching are
listed.

EFP Special Rules
Priority tagged VLAN

This is VLAN 0; it is primarily used for Voice over IP (VoIP)
traffic or other types of traffic that dont use a VLAN, but that
need a COS value
:router(config-subif)# encapsulation dot1q priority-tagged
Exact match
The exact keyword means that there cannot be another tag
following the top tag
:router(config-subif)# encapsulation dot1q 1000 exact

Layer 2 and Layer 3 Coexistence

Layer 2 EFP subinterfaces and Layer 3 subinterfaces can coexist on the
same physical port. In this case, the L3 subinterfaces must adhere to the
following criteria:
Matching can be performed on the physical port, a single VLAN tag, or
double VLAN tags only. They are always assumed to be exact, no
VLAN ranges or lists.
No VLAN re-write options are supported.

Module 13 Layer 2 and Layer 3 Coexistence

Layer 2 services and Layer 3 services can co-exist on the

same physical port.
If physical port is Layer 2 port mode it cannot have any
other Layer 2 or Layer 3 EFPs or subinterfaces on that
port.
If physical port is Layer 3, it can have Layer 2 or Layer 3
EFPs or subinterfaces, or both, on that port.
Layer 3 is always handled according to exact match rules
Non-EFP CLI (ex. encap dot1q vlan 10 ) use for Layer 3
VLANs
Both EFPs and routed subinterfaces support H-QOS.

Flexible VLAN Tag Manipulations

Push, Pop, Translate
After matching a frame, VLAN tag operations are performed on both

ingress and egress. For each possible ingress operation, there is a
corresponding, symmetric, egress operation. Egress packets have a
manipulation applied to them that is logically the reverse of the
manipulation that was applied on ingress. Asymmetric operations are not
supported.
Any mix of 802.1q and 802.1ad push/pop/translate operations is supported.
Push one or more tags: On ingress, one or two tags are added to the start of
the packet. The corresponding egress operation is to remove the same
number of tags.
Pop one or more tags: One or more tags that exist at the start of the packet
are removed. The corresponding egress operation is to push the same
number of tags.
A combination of the above: A number of combined manipulations are
supported. Each of these is equivalent to a pop of one or more tags,
followed immediately by a push of one or more tags. Thus, the comments
that apply to pop also apply here. (On egress, the corresponding egress
operations are performed as described above, but in the reverse order from
ingress).

Module 13 Flexible VLAN Tag Manipulations
Flexible VLAN Tag Manipulations
Add 1 VLAN Tag DA SA 20 DA SA 25 20
Add 2 VLAN Tags DA SA DA SA 25 31
Remove 1 VLAN Tag DA SA 10 20 DA SA 20
Remove 2 VLAN Tags DA SA 10 20 DA SA
1:1 VLAN Translation DA SA 10 DA SA 25
1:2 VLAN Translation DA SA 10 DA SA 25 31
2:1 VLAN Translation DA SA 10 20 DA SA 31
2:2 VLAN Translation DA SA 10 20 DA SA 25 31

VLAN Tag Pop, Push, Translate CLI

Rewrite operations are performed on the ingress EFP. Configuration is
performed in conjunction with VLAN tag matching commands. The
following slide shows the CLI rewrite and translate options.

VLAN Tag Push, Pop, Translate CLI

:router(config-subif)# encapsulation dot1q 10 second-dot1q 100
:router(config-subif)# rewrite ingress tag ?
pop Remove one or more tags
push Push one or more tags
translate Replace tags with other tags
:router(config-subif)# rewrite ingress tag pop ?
1 Remove outer tag only
2 Remove two outermost tags
:router(config-subif)# rewrite ingress tag push ?
dot1ad Push a Dot1ad tag
dot1q Push a Dot1Q tag
:router(config-subif)# rewrite ingress tag translate ?
1-to-1 Replace the outermost tag with another tag
1-to-2 Replace the outermost tag with two tags
2-to-1 Replace the outermost two tags with one tag
2-to-2 Replace the outermost two tags with two other tags

VLAN Tag Rewrite: Push

Add a Tag
After an EFP match, a push operation can be applied to any packet. There
are no restrictions on the filter that comes before a push operation.
A push operation takes as its parameters a list of tags: for each tag, the
following must be specified:
The VLAN id to be pushed
Whether the tag is to be .1Q or .1ad

The effect on the packet is to add the corresponding tag(s) to the front
of the packet.
Rewrite commands are always applied symmetrically, meaning whatever
rewrite operation happens on ingress, the reverse operation is
automatically applied to frames in the egress direction of this particular
EFP.


Push a tag DA SA 20 DA SA 25 20
This allows you to create dot1q tunnels and is

found at the ingress UNI
Can push 1 tag or 2 tags
All rewrite actions are symmetric; the action taken
on ingress is reversed on egress on this local EFP

:router(config-subif)# encapsulation dot1q 20
:router(config-subif)# rewrite ingress tag push dot1q 25

VLAN Tag Rewrite: Pop

Remove a Tag
After an EFP match, a pop operation can be applied to remove the outer
VLAN tag from a frame with one or more VLAN tags. One or two tags can
be popped.

VLAN Tag Rewrite: Pop
Pop a tag DA SA 50 20 DA SA
Useful at the NNI ingress to remove a provider tag

Can pop one tag or two tags
The number of tags you match are the number that
you can pop

:router(config-subif)# rewrite ingress tag pop 2

VLAN Tag Rewrite: Translate

Translate a Tag
After an EFP match, a translate operation can be applied to modify the

VLAN field values.
A push operation takes as its parameters a list of tags: for each tag, the
following must be specified:
The VLAN id to be pushed
Whether the tag is to be .1Q or .1ad

The effect on the packet is to add the corresponding tag or tags to the
front of the packet.

VLAN Tag Rewrite: Translate
DA SA 200 10 DA SA 30
Translate a tag
Options are 1:1, 1:2, 2:1, 2:2
Useful for customer VLAN overlap
:router(config-subif)# rewrite ingress tag 2-to-1 dot1q 30

:router(config-subif)# encapsulation dot1q 30
:router(config-subif)# rewrite ingress tag translate 1-to-2 dot1ad 40
dot1q 50
DA SA 30 DA SA 40 50

Layer 2 Protocol Tunneling via Ethernet Filter

Tunneling is enabled with the Ethernet Filter feature. Default action is to
tunnel all L2 control protocols (including CDP) on L2 interfaces and
terminate/ process on L3 interfaces. 802.3ah and LACP are always
terminated on L2 as well as L3 interfaces.
Note: It is not possible to support Ethernet filtering on the same physical
interface as MSTP.

Layer 2 Protocol Tunneling via Ethernet Filter
Slow protocols like 802.3ah , LACP , 802.1d, and

pause frames have per-segment scope and are
always terminated (dropped or processed) on
arriving interfaces.
Each physical interface can be set into 802.1Q or
802.1ad filtering mode. Layer 2 control protocols are
tunneled or terminated.
Check 802.1ad Standard Table 8-1, 8-2 for defaults.
Main interface
(config)# interface gigabitEthernet 0/2/0/0
(config-if)# ethernet ?
cfm 802.1ag Connectivity Fault Management configuration
filtering Configure ingress Ethernet frame filtering
oam OAM configuration
(config-if)# ethernet filtering ?
dot1ad S-Vlan ingress frame filtering (Table 8-2 of 802.1ad standard)
dot1q C-Vlan ingress frame filtering (Table 8-1 of 802.1ad standard)

Additional EFP Configuration Notes

Rewrite Rules
Rule#1 One rewrite only

One service instance can have none or at most one VLAN tag rewrite
configuration.
If there is no VLAN tag rewrite, it will keep the existing VLAN tag
unchanged. It cannot have more than one VLAN tag rewrite configuration
for a particular service instance.
Rule#2 Rewrite unique VLAN tags only
The translate command can only apply to a unique tag matching service
instance. It does not apply to VLAN range configurations.
Rule#3 symmetric configuration only
Encapsulation rewrite should be always symmetric; meaning whatever
rewrites on ingress direction should have the reverse rewrite on the egress
direction for the same service instance configuration.

Additional EFP Configuration Notes
One rewrite only

Rewrite unique VLAN tags only
Rewrite commands are always symmetric
Other features such as QoS, OAM, and
security can be configured on an EFP and
will be discussed in later modules.

Layer 2 Network Infrastructure

EFPs are interconnected with the Cisco ASR 9000 Cisco IOS XR Layer 2
infrastructure. EFPs can be connected locally (across a single device) or
across two or more devices.
Non-local Layer 2 connections using MPLS (or other Layer 2 technologies)
are often referred to as L2VPNs.
Each device has at least one EFP. Many EFPs are combined to create an
end-end Layer 2 service.

Module 13 Layer 2 Network Infrastructure
Layer 2 Network Infrastructure
L2VPN
CE
CE
EFPs
The Layer 2 infrastructure connects EFPs:

Can connect EFPs locally across a single platform (Layer 2 service)
Can connect EFPs across an MPLS network (L2VPN service)

Cisco ASR 9000 Carrier Ethernet Service Support

Cisco ASR 9000 IOS-XR supports all Ethernet Service Attributes Phase 1
per MEF 10 and MEF 11.
E-Line service is supported by EFP-to-EFP local switching and between
sites with EFP to PW forwarding (EoMPLS/VPWS).
E-LAN service is supported locally with EFPs assigned to a bridge-domain
and between sites with EFP mapping to a VPLS.

Cisco ASR 9000 Carrier Ethernet Service Support
For E-Line services:

EFP-to-EFP local switching
EFP-to-PW forwarding (EoMPLS)
For E-LAN and E-Tree services:
EFP-to-Bridge domain: Layer 2 broadcast domain
spanning set of physical and virtual ports
EFP-to-VPLS/H-VPLS virtual switch instance (VSI):
Bridge domain and Layer 2 virtual forwarding
instance (VFI)

Layer 2 Service Configuration Prerequisites

Before creating local or end-end Layer 2 services, the network interfaces
and devices must be prepared to support the services.

Layer 2 Service Configuration Prerequisites
Ethernet/IGP/MPLS network foundation must

be configured on the platform and across all
neighbor platforms to support the services:
If Layer 2 Ethernet, Ethernet protocols
must be configured
If IPv4 or IPv6, routing protocols must
be configured
If MPLS, routing protocols and MPLS
protocols must be configured

Layer 2 Service CLI Configuration Structure

Enter L2VPN configuration mode:
Specify cross-connect (P2P) or bridge (MP) commands.
If P2P, specify group name and connected EFPs (native Ethernet) or
pseudowire (EoMPLS).
If MP, specify bridge group/bridge-domain and connected EFPs (native
Ethernet), VFIs (VPLS), or pseudowires (H-VPLS).
Optionally, specify pseudowire-class templates.

Layer 2 Service CLI Configuration Structure
Enter l2vpn l2vpn

configuration
mode
P2P MP
Specify cross-
connect or bridge xconnect group bridge group
Specify p2p
bridge-domain
corresponding
parameters interface or neighbor interfaces or VFI
split horizon group
IGMP snooping

Layer 2 Service Creation

Using the structure CLI, in configuration mode enter the L2VPN
command. From here you can create:
Point-to-point cross connects with the xconnect command
Multipoint connections with the bridge commands
PW type profiles using the pw-class command
Create a L2 crossconnect with the xconnect command. The xconnect
command requires a group name and a p2p name.
This is where the service configuration becomes either a local xconnect
(interface command) or an EoMPLS connection (neighbor command) to
another platform.

Layer 2 Service Creation
:router(config)# l2vpn
:router(config-l2vpn)# ?
.
bridge Configure bridge commands
logging Enable cross-connect logging
pw-class Pseudowire class template
pw-status Enable PW status
xconnect Configure cross connect commands
Cross-connect or bridge options
PW-class can also be configured
:router(config-l2vpn)# xconnect group CUSTOMER_A p2p SERVICE_1
:router(config-l2vpn-xc-p2p)# ?
. .
interface Specify the attachment circuit
neighbor Specify the peer to cross connect
Specify a cross-connect group name, p2p name

Specify an interface or neighbor to connect to

L2VPN xconnect Example

This slide illustrates a complete L2VPN xconnect configuration. This
configuration creates a local xconnect between GE subinterfaces on
different LCs.

L2VPN xconnect Example
:router(config)# l2vpn
:router(config-l2vpn)# xconnect group CUSTOMER_A p2p SERVICE_1
:router(config-l2vpn-xc-p2p)# interface gigabitEthernet 0/1/0/0.10
:router(config-l2vpn-xc-p2p)# interface gigabitEthernet 0/2/0/10.20
This example shows a cross-connect with the

name SERVICE_1 connecting two EFPs.

Show commands for Layer 2

Use the commands listed on the slide on the next page to verify and
troubleshoot Layer 2 service configurations.

Show commands for Layer 2
To check physical interface state (for example, up, up), port settings (for example,
MTU, duplex), counters:
show gigabitEthernet 0/2/0/1 or tenGigE 0/4/0/1
show ethernet trunk
To check subinterface state, encapsulation and rewrite settings, counters:
show gigabitEthernet 0/2/01.1
To check for correct cross-connect segment state (AC-AC, AC-PW, or PW-PW):
show l2vpn xconnect
show l2vpn xconnect summary
show l2vpn forwarding
To check EFP details including AC state, VLANs, PW details, and counters:
show l2vpn xconnect detail
show ethernet tags
To check bridge-domain and VFI configurations:
show l2vpn bridge-domain
show running-config l2vpn

Logical View of Data Path

This slide on the next page summarizes the end-end data path from
ingress interface to egress interface.
Upon ingress a frame is matched to a logical EFP.
QoS and ACLs are applied prior to VLAN rewrites.
The frame is then mapped to a service (xconnect or bridge-domain) and
it is bridged to the egress LC(s) through the switch fabric.
Frames are checked on egress for the expected tagging.
Egress rewrites are performed.
Before transmitting the frame out the egress interface, QoS and ACLs
are applied.

Module 13 Logical View of Data Path
Ingress Egress
interface Service mapping interface
(cross-connect, bridge,
and so on)
Tier 1 Tier 2 input Ingress Tier 1 Egress Tier 2
input features VLAN output EFP output
features re-writes matching rewrites features
Ingress QoS, Egress filter
Ingress Ingress Egress 2
interface filter 1 Egress QoS,
ACLs
classify ACLs
Logical interface match, Switch fabric Egress match, symmetric

QoS, ACLs, rewrite rewrite, QoS, ACLs
Note the order of operations when configuring QoS, ACLs in

combination with VLAN rewrites.
For example, if the QoS policy is matching on VLAN, and
VLAN re-write is configured.

Layer 2 VPN Types

This table categorizes the L2VPN types. The table is divided vertically
with P2P on the left and MP on the right. The table is divided horizontally
with local services (one-platform) using native Ethernet on top and multi-
platform services using MPLS on the bottom.
Point-to-point
Local connect is a transparent connection between two EFPs (AC-AC),

which reside on the same box. The EFPs are on the same or different LCs,
and can be on the same or on different physical ports.
EoMPLS is a transparent connection between two EFPs on different
platforms using an MPLS PW. Each platform has an AC-PW connection.
There are two endpoints to the service, no MAC learning is performed.
Multicpoint
Local bridging uses a bridge-domain (BD) to interconnect two or more

EFPs on a single platform.
VPLS bridging uses bridge-domains and a PW mesh to interconnect two or
more EFPs on multiple platforms. MAC learning/forwarding is performed
by the BD. Some Layer 2 protocols are applied per-BD (where MAC
learning is performed). An example is IGMP snooping.

Module 13 Layer 2 VPN Types
Layer 2 VPN Types
Point-to-point Multipoint
1 E-Line E-LAN
3
Local connect Local bridging
Single-
Two EFPs (on same Two or more EFPs (on platform
platform) connected using same platform) connected
using
native Ethernet in a bridge-domain using
Ethernet
native Ethernet
EoMPLS VPLS bridging
EFPs (on different Two or more EFPs (on Multiple-
platforms) connected with different platforms) in a platform
a PW bridge-domain connected using MPLS
by a PW mesh
2 Bridge-domain
4
No MAC learning
Transparent tunnel MAC learning
IGMP snooping
Split-horizon

Putting it All Together 1, 2

The slide on the next page illustrates the point-to-point VPN types
described in the previous slide. The gray boxes represent a single Cisco
ASR 9000 platform. The left side of the slide is customer facing, the right
side is facing the core. Ingress and egress LCs are interconnected by the
switch fabric.
A L2VPN type 1 example is shown as a point-to-point xconnect between
EFPs.
Type 2 is shown as a point-to-point interconnection between an EFP and
an EoMPLS PW.
A Layer 2 termination into a Layer 3 interface (a routed interface) is also
shown as an example of a L2 EFP match mapped to a Layer 3 routing
process.
As described in the previous models, EVCs span this device, connecting
EFPs locally or to another device across the local or core network.

Putting it All Together 1, 2

Putting it All Together
L2
L2 xconnect
xconnect
1 EFPs
Ethernet L2
P2P Ethernet
frames
xconnect MPLS
uplink
EFPs MPLS PW
L2
2 PW
P2P EoMPLS
tunnels
IP
interface
GE or 10GE
ports Ingress LC Switch fabric Egress LC
EVCs

Putting it All Together- 3, 4

This slide illustrates the multipoint VPN types.
Type 3 is shown as a multipoint bridge-domain interconnecting multiple
Ethernet EFPs.
Type 4 is shown as a bridge-domain interconnecting multiple EFPs to an
MPLS PW mesh (VPLS).
As described in the previous models, EVCs span this device, connecting
EFPs locally or to one (or many) other devices across the local or core
network.

Putting
Putting it All3,Together
it All Together- 4
EFPs
Ethernet
frames
L2
MPLS
MP Ethernet
bridge-domain
3 uplink
L2
BD
EFPs
PW
tunnels
MP VPLS
4 L2
MPLS
PWs
BD EoMPLS
VFI
IP
interface
GE or 10 GE
EVCs

Layer 2 Service CLI Command Preview

This slide gives you a preview of some of the CLI commands you will be
using in the rest of the course. An example for each of the Layer 2 service
types is shown.
These commands and their usage will be described in detail in the
following modules of this course.

Layer 2 Service CLI Command Preview

encapsulation dot1q 10-100
l2vpn
xconnect group TEST1 p2p TEST1
int g0/1/0/0.10
Local E-Line 1
int g0/2/0/0.20

encapsulation dot1q 201-1000
l2vpn
EoMPLS E-Line 2
xconnect group TEST2 p2p TEST2
int g0/1/0/0.30
neighbor 2.2.2.2 pw-id 30
3
l2vpn Local E-LAN
bridge group TEST3
bridge-domain TEST3
int g0/1/0/1.10
int g0/1/0/0.20
4
l2vpn VPLS E-LAN
bridge-group TEST4
bridge-domain TEST4
int g0/1/0/0.40
vfi TEST4

Layer 2 System Capabilities

If you enter the show l2vpn capability system command, you can view
the supported Layer 2 service criteria.
____________________________ Note _________________________
This command is only available for tech-support user type
authorization and is shown here for informative purposes.
__________________________________________________________________

Layer 2 System Capabilities
Bundle AC supported: Y
System capability:
Security config supported: Y
VPLS Max MAC addresses: 512000
DHCP snooping supported: Y
VPLS Max bridge-domains: 8192
VPLS Static MAC filter supported: Y
VPLS Max attachment circuits: 64000
VPLS MAC configs on bridge port supported: Y
VPLS Max pseudowires: 32000
VPLS Flooding config on bridge port supported: Y
RSI bit size: 14
Flood unknown unicast disable supported: Y
Per-AC drop counters supported: Y
IGMP snooping supported: Y
VPLS Preferred path allowed: Y
VPLS MAC Aging Default Timer Value: 300
VPLS Preferred path fallback enable allowed: Y
VPLS MAC Aging Min Timer Value: 300
VPLS Preferred path fallback disable allowed: Y
VPLS MAC Aging Max Timer Value: 30000
MAC withdrawal allowed: Y
VPWS Max attachment circuits: 64000
Max attachment circuits per bridge-domain: 16384
VPWS Max pseudowires: 64000
VPLS Max virtual forwarding interfaces: 32000
VPWS Preferred path fallback enable allowed: Y
VPLS Max virtual forwarding interfaces per bridge-domain: 1
VPWS Preferred path fallback disable allowed: Y
VPLS Max pseudowires per bridge-domain: 512
VPLS allowed: Y
VPLS Max pseudowires per virtual forwarding interface: 512
VPLS Default MAC limit: 4000 [DEFAULT]
VPWS PW redundancy supported: Y
Split Horizon Group supported: Y [DEFAULT]
VPLS Access PW supported: Y
VPLS Max MAC addresses per bridge-domain: 512000
VPWS allowed: Y
VPWS Max xconnects: 64000
(additional content not shown)

Summary
Cisco ASR 9000 Layer 2 Architecture
Describe Carrier Ethernet concepts

Describe the Cisco ASR 9000 Layer 2 service architecture
Describe how EFPs, EVCs bridge-groups, and MPLS are involved in
building Layer 2 services

Module 14
Cisco ASR 9000 Point-to-point Layer 2 Services
Overview
Description
This module provides a detailed description of the point-to-point Layer 2
services supported by the Cisco ASR 9000 Series Aggregation Services
Router. This includes an overview of local and Ethernet over Multiprotocol
Label Switching (EoMPLS) Ethernet-Line service and service resiliency
features.
Objectives
Describe and configure local E-line service
Describe and configure link bundles

Describe and configure EoMPLS E-Line service
Describe and configure PW resiliency

Cisco ASR 9000 Point-to-point Layer 2 Services Module 14
Visual Objective-Cisco ASR 9000 Lab Topology

Objective for Hands-on Lab
The Cisco ASR 9000 lab is designed to emulate a portion of the Cisco IP
Next-Generation Network (IP-NGN) Carrier Ethernet network. Cisco ASR
9000 routers deployed as provider-edge (PEs) devices are connected to two
Cisco XR 12000 Series Routers, which form an IP/MPLS core. Two of six
pods are shown in the slide on the next page.
In the labs that accompany this module, you will perform the steps
necessary to create Ethernet flow points (EFPs), cross-connects (xconnect),
and Multiprotocol Label Switching (MPLS) pseudowires (PWs) and combine
them to construct various end-to-end Metro Ethernet services between the
User-to-Network interfaces (UNIs).
Additional equipment will be used to simulate customer device traffic across
the entire service architecture.

Module 14 Visual Objective-Cisco ASR 9000 Lab Topology
Visual Objective-Cisco ASR 9000 Lab Topology

Visual Objective - Cisco ASR 9000
Lab Topology
Layer 2 Service Infrastructure

UNI UNI
NNI NNI
P P
CE PE PE CE
(GE) (GE) (GE) (GE) (GE)
Cisco Cisco
ASR Cisco Cisco ASR
9000 12000 12000 9000
Ethernet or
Cust A Ethernet or MPLS Access Cust A
Loc 1 MPLS Access IP or MPLS Loc 2
Core and
and Aggregation
Aggregation

Point-to-point, AC-AC Crossconnect CLI

An Ethernet Line Service is a point-to-point connection between two
Ethernet UNIs. Two types of Ethernet Line Service (E-Line) are discussed
in this module: local E-Line and Ethernet over MPLS (EoMPLS) E-Line.
Local E-Line involves UNIs located on a single Cisco ASR 9000 Series
Router. They can be located on the same or different LCs.
EoMPLS E-Line connects UNIs between Cisco ASR 9000 Series Routers
across an IP/MPLS core.
The opposite page shows a CLI for a local AC-AC cross-connect.
Configuration can be divided into two steps: EFP configuration and L2VPN
or cross-connect configuration.
The l2transport command is used to create two EFPs on a subinterface.
The EFPs are linked by a cross-connect configured using the l2vpn
command.

Module 14 Point-to-point, AC-AC Crossconnect CLI
P2P AC-AC Cross-Connect CLI
EVC
AC AC
Switch
Ingress LC fabric Egress LC
EFP1 EFP2
int gig0/1/0/0.10 l2transport int gig0/2/0/2.10 l2transport
encapsulation dot1q 10 encapsulation dot1q 10
rewrite ingress tag < > rewrite ingress tag < >
l2vpn
xconnect group CUSTOMER_A p2p SERVICE_1
interface gig0/1/0/0.10
interface gig0/2/0/2.10

Local Switching
To check the configuration the following commands are useful:
show run interface efp-interface

show run l2vpn
show l2vpn xconnect
show l2vpn xconnect detail

show l2vpn xconnect group group-name
show l2vpn xconnect group group-name p2p xconnect-name
show l2vpn forwarding interface efp
show ethernet tags
show ethernet trunk
The following slide shows a l2vpn P2P cross-connect configuration and the
output of the show l2vpn xconnect detail command. The state of the two
AC segments, the subinterface configuration parameters (VLAN tags, MTU
and corresponding counters), are displayed.
The output of the show l2vpn xconnect forwarding command shows the
forwarding plane status for a particular LC or interface.

Module 14 Local Switching
Local Switching
P2P AC-AC Cross-Connect CLI Example
(config)# l2vpn xconnect group CUSTOMER_A p2p SERVICE_1

Xconnect configuration
(config-l2vpn-xconnect-p2p)# interface gigabitEthernet 0/1/0/0.10
(config-l2vpn-xconnect-p2p)# interface gigabitEthernet 0/2/0/2.10
(config-l2vpn-xconnect-p2p)#commit
# sh l2vpn xconnect group CUSTOMER_A detail Show xconnect detail

Group CUSTOMER_A, XC SERVICE_1, state is up
Segment 1 is AC: GigabitEthernet0/1/0/0.10, Xconnect ID: 2, type VLAN
Tags: Outer 10, Inner 0, MTU 1500
State is up
Statistics:
packet totals: receive 0,send 0
byte totals: receive 0,send 0
drops: illegal VLAN 0, illegal length 0
Segment 2 is AC: GigabitEthernet0/2/0/2.10, Xconnect ID: 3, type VLAN
Tags: Outer 10, Inner 0, MTU 1500
State is up
Statistics: Show xconnect forwarding
packet totals: receive 0,send 0
byte totals: receive 0,send 0
per LC
# sh l2vpn forwarding interface gigabitEthernet 0/1/0/0.10 detail location 0/2/cpu0

Local interface: GigabitEthernet0/1/0/0.10, Xconnect id: 2, Status: up
Segment 1
AC, GigabitEthernet0/1/0/0.10, Ethernet VLAN mode, status: Bound
Packet switched: 0, byte switched: 0

AC/PW/XC States
Attachment Circuit (AC) states:
Up (UP)
Down (DN)-Segment is configured, interface has been configured for
l2transport, but local interface is down.
Unresolved (UR)-Segment has not been configured or l2transport has
not been configured on the interface.
Connected (CO)-Service is available, interface has been configured for l2
transport, but interface is not up and AToM is not ready to distribute
labels.
Local Up (LU)-Local AC is up, but remote AC or PW is not ready.
Remote Up (RU)-Remote AC/PW are up, but local AC or PW is not
ready.
Admin down (AD)-Layer 2 interface is administratively down.
Cross-connect and Pseudowire States:

UP All segments are configured and their state is up.
DOWN (DN) At least one of the segments is in the down state.
UNRESOLVED (UR) At least one of the segments is not configured or
its state is unresolved.

Module 14 Local Switching
AC/PW/XC States
AC States Xconnect/PW States

States Note States Note
UP All Segments are
UP All Segments are configured and their state is up configured and their state
is Up
Segment is configured, interface has been configured DN At least one of the
DN for l2transport, but local interface is down segments is in down state
UR At least one of the

UR At least one of the segments is not configured segments is not
configured
Service is available, interface has been configured for
CO l2 transport, but interface is not up and AToM is not
ready to distribute labels
LU AC is up, but remote AC/PW is not ready
RU Remote AC/PW are up, but local AC/PW are not ready
AD At least one of the segments is not configured

Attachment Circuit Redundancy

Redundancy in hardware and software is an important part of delivering
Ethernet services with high availability (HA).
Link bundles and Multiple Spanning Tree (MST) exist as options to prevent
loops and provide load distribution on redundant Layer 2 access circuit
connections.
We discuss MST deployment later in this course.

Module 14 Attachment Circuit Redundancy
Attachment Circuit Redundancy
A single-home PE-CE link can use a link bundle for

increased link availability.
Multiple links as a bundle protects against single link
failures.
Increase bandwidth in unit multiples rather than
orders of magnitude (2 GE links for 2 Gbps instead
of one 10 TenGig interface) Link bundle w ith a 1:1 protection
scheme provides link failure
resiliency
x
Link failure
CE PE

What Is a Link Bundle?

A link bundle is a group of physical interfaces that are bundled together to
act as a single interface (also known as a link aggregation group, [LAG]).
Bundles can be deployed on Layer 2, Layer 3, or MPLS-enabled physical
ports.
Each bundle has a single MAC, a single IP address, and a single
configuration set (such as ACLs or QoS).
Multiple links can span several line cards to form a single interface. Thus,
the failure of a single link does not cause a loss of connectivity. Bundled
interfaces increase bandwidth availability, because traffic is forwarded over
all available members of the bundle. Therefore, traffic can flow on the
available links if one of the links within a bundle fails. Bandwidth can be
added without interrupting packet flow.

What Is a Link Bundle?
Two or more physical ports logically combined to

act as a single port.
Offers increased bandwidth and resiliency over a
single link.
Bundle-Ether 100
gig 0/2/0/3
gig 0/2/0/4
ASR 9000
CE PE
Bundle-Ether 101
gig 0/2/0/20
gig 0/2/0/21

Supported Link Bundle Features

IEEE 802.3adA standards-based technology that employs Link
Aggregation Control Protocol (LACP) to ensure that all the member links in
a bundle are compatible. Links that are incompatible or have failed are
automatically removed from a bundle.
EtherChannelA Cisco proprietary technology that allows the user to
configure links to join a bundle, but has no mechanisms to check whether
the links in a bundle are compatible.
All member links must be of the same speed. The maximum number of link
bundling interfaces per chassis is 128. The maximum number of link
bundle interfaces per line card is 40. The maximum number of members
per bundle is eight. User can configure more than eight members, but the
additional links will be in the de-attached state.
Global MAC addresses stored in the backplane are used as bundle MAC
addresses. Accounting is provided per bundle port.
Bundles are supported on Layer 2, Layer 3, or MPLS uplink ports. Bundle
interfaces support EFPs. QoS is supported on bundle ports. BFD is
supported on bundle ports. 802.3ah link OAM is supported over the
member ports. CFM over the bundle or MST over the bundle is supported
starting with R3.9.0.
A minimum or maximum number of active member links can be configured
on bundle interfaces. A bundle interface and its members can be shut or no
shut independently.

Supported Link Bundle Features
Cisco EtherChannel (default) or 802.3ad LACP

Can be deployed on L2, L3, or MPLS interfaces and across LCs
Global MAC Address stored in the backplane and are used as
Bundle MAC addresses. Bundle is treated as a single Interface by
higher layer protocols.
Many features are applied on the bundle and not on the member
links.
8 members per bundle, 128 bundles per system, 40 per LC
1:1 bundle protection (maximum active link = 1) is supported, N:1
bundle protection is not supported, minimum active link is
supported.
Flow-based load balancing
Interface accounting
Multi-chassis link aggregation groups (MC-LAG) are supported
802.1ag (Connectivity Fault Management) is supported on logical
bundles and member interfaces

Link Bundle Configuration CLI Steps

The following steps provide a general overview of the link bundle
configuration process. Keep in mind that a link must be cleared of all
previous network layer configurations before it can be added to a bundle.
To create a link bundle, two steps are required. First, create a logical
bundle interface using the interface bundle-ether <id> command in
global configuration mode. Second, add physical interfaces to the bundle in
interface configuration mode using the bundle id <id> command and
specify the type of link bundle protocol you would like to deploy.
The default protocol is Cisco Etherchannel and is implemented using the on
command when adding the member interface to the bundle. Optionally, you
can specify LACP and a state with the active or passive command.
If building Layer 2 services, EFPs can then be configured on the logical
bundle interface. Configuration is very similar to EFP creation on a
physical interface.

Link Bundle Functionality

Link Bundle Configuration CLI Steps
Create bundle globally

!
RP/0/RSP0/CPU0:Router(config)# interface bundle-ether 100 !
Interface configuration mode
Add interface members to bundle
!
RP/0/RSP0/CPU0:Router(config)# interface gig0/2/0/3!
RP/0/RSP0/CPU0:Router(config-if)# bundle id 100 mode on|active|
passive!
RP/0/RSP0/CPU0:Router# (config) interface gig0/2/0/4!
RP/0/RSP0/CPU0:Router(config-if)# bundle id 100 mode on|active|
passive!
Create EFPs/subinterfaces on bundle

!
RP/0/RSP0/CPU0:Router(config)# interface bundle-Ether 100.1
l2transport!
RP/0/RSP0/CPU0:Router(config-subif)# encapsulation dot1q 11!
RP/0/RSP0/CPU0:Router(config-subif)# commit!

EtherChannel or LACP configuration

To enable active or passive LACP on the bundle, include the optional mode
active or mode passive keywords in the command string.
To add the link to the bundle without LACP support, include the optional
mode on keyword with the command string.
Only physical interfaces can be added to a bundle. Subinterfaces cannot be
bundled together. Configuration will not be committed.
____________________________ Note _________________________
If you do not specify the mode keyword, the default mode is on (that is,
LACP is not run over the port).
__________________________________________________________________
The optional Link Aggregation Control Protocol (LACP) is defined in the
IEEE 802 standard. LACP communicates between two directly connected
systems (or peers) to verify the compatibility of bundle members. For the
Cisco ASR 9000 Series Router, the peer can be either another router or a
switch. LACP monitors the operational state of link bundles to ensure the
following:
All links terminate on the same two systems.

Both systems consider the links to be part of the same bundle.
All links have the appropriate settings on the peer.
LACP transmits frames containing the local port state and the local view of
the partner systems state. These frames are analyzed to ensure that both
systems are in agreement.
Members with LACP configured are given higher priority and are attached
to the bundle when there is a mix of LACP enabled and disabled links.
LACP in active mode sends and receives control packets, as opposed to
passive mode in which LACP responds only to received control packets.
LACP can be configured in short mode (1 sec) or long mode (30 sec), which
determines the rate at which control packets are exchanged.
If members are configured without LACP, verify link connectivity and
symmetry.

EtherChannel or LACP Configuration
Three available modes. Using LACP is preferred:
Mode on (Cisco EtherChannel, the default)

(config-if)# bundle id 100 mode on interface configuration mode
Mode active (send/receive LACP)

(config-if)# bundle id 100 mode active
Mode passive (receive/respond LACP)

(config-if)# bundle id 100 mode passive

Additional Bundle Commands

You can set additional link bundle parameters. In this example, link
bundle features are configured that set minimum and maximum thresholds
on the number of member links. When one member link in a bundle fails,
traffic is redirected to the remaining operational member links and traffic
flow remains uninterrupted.
The optional bundle minimum-active bandwidth kbps command sets
the minimum amount of bandwidth required before a user can bring up a
bundle.

Additional Bundle Commands
Typically, all member ports are in forwarding state. They are

actively load balancing the traffic.
Optionally, with 1:1 bundle configuration only one of the
member port is in active forwarding state, the rest of ports
(typically one port) is in standby state. When active member
port fails, standby port will become active:
Bundle interface
(config-if)# bundle maximum-active links count configuration mode
Optionally, specify the minimum number of links for the

bundle to become active:
(config-if)# bundle minimum-active { links count | bandwidth bw }

Verify Bundle Configuration

Verify link bundle configuration using the show bundle command. The
state of the bundle port, its virtual MAC address and member interface
information is given.
Bundle member interfaces that are active should be in the distributing
state. If a maximum active link parameter has been set, member
interfaces that are in standby shows up in the collecting state.
In the following example, the member port is in the detached state because
the physical link is down.

Verify Bundle Configuration
RP/0/RSP0/CPU0:PE1# show bundle

State: 0 - Port is Detached. 1 - Port is Waiting.
2 - Port is Attached. 3 - Port is Collecting.
4 - Port is Distributing. If no maximum is specified
p Port is the primary port for this bundle all members should be
distributing.
Bundle-Ether100
Minimum active Maximum active
B/W (Kbps) MAC address Links B/W (Kbps) Links
---------- -------------- ----- ---------- -----
2000000 0024.e5eb.1e8b 1 1 8
Port State Port ID B/W (Kbps) MAC address

------------ ----- -------------- ---------- ---------------
Gi0/2/0/3 4p 0x8000, 0x0001 1000000 001d.e5eb.91c4
Gi0/2/0/4 4 0x8000, 0x0002 1000000 001d.e5eb.91c5
Gi0/1/0/20 0 0x8000, 0x0003 1000000 001d.e5eb.91a4
Link is down
A message is shown if member
is not distributing.

Link Bundle Load Balancing Mechanism

The Cisco ASR 9000 uses a LAG table to provide separation of link bundle
information from adjacencies. The LAG table has eight entries. If there are
an odd number of member interfaces, load balancing will not be evenly
distributed.
The goal of the load balancing mechanism is to pick a particular member
port for each type of traffic flow. Hashing is based on the underlying
traffic type as described in the facing slide. An exclusive OR operation
(XOR) is performed on the least significant bits of the traffic type (for
example a VPWS PW labels) together with the least significant bits of the
router ID. The result identifies one of the eight entries in the LAG table to
use for forwarding.
If a member port fails, the LAG table will be rebuilt.
____________________________ Note _________________________
For more detailed information on link aggregation load balancing for your
particular deployment, talk with your Cisco representative.
__________________________________________________________________

Link Bundle Load Balancing Mechanism
Link Bundle Hashing Algorithm

VPLS and VPWS (PW side) A hashing algorithm is
performed on particular
Per VC load balancing ! VC ID + router ID traffic bits resulting in a
L2 (including VPWS/VPLS to AC) value 0-7 that identifies one
member interface
Per MAC ! source MAC + dst MAC + router ID
Per EFP/sub-interface (optional in R3.9 release) can mix per flow
and per VLAN load balancing on the same bundle port
IPv4 Unicast (ECMP and Link bundle) or IPv4 to MPLS
No or unknown Layer 4 protocol ! IP SA, DA and Router ID
UDP or TCP ! IP SA, DA, Src Port, Dst Port and Router ID
IPv4 Multicast (Link bundle)
Same as IPv4 unicast
MPLS to MPLS or MPLS to IPv4
# of labels <= 4 ! same as IPv4 unicast
# of labels > 4 ! 4th label and Router ID

Bundle-hash CLI Examples

Within the Cisco ASR 9000 CLI there is a tool to calculate which link
bundle member will be chosen based upon the underlying traffic type. This
tool can be used to map traffic flow for your particular deployment.

Bundle-hash CLI Examples
RP/0/RSP0/CPU0:PE1#bundle-hash bundle-e 50
Calculate Bundle-Hash for L2 or L3 or sub-int based: 2/3/4 [3]: 2
Enter traffic type (1.VPWS, 2.VPLS) : [1]: 1
Enter traffic direction (1.AC-to-PW, 2.PW-to-PW, 3.any-to-AC): [1]: 1
Enter PW VC label in decimal (20-bit value) :16001
Link hashed [hash:4] to is TenGigE0/0/0/4 member id 1 ifh 0x4000180
Another? [y]: n
RP/0/RSP0/CPU0:PE1#bundle-hash bundle-e 112

Calculate Bundle-Hash for L2 or L3: 2/3 [3]: 2
Enter traffic type (1.VPWS, 2.VPLS) : [1]: 1
Enter traffic direction (1.AC-to-PW, 2.PW-to-PW, 3.any-to-AC): [1]: 3
Enter source MAC address [xxxx:yyyy:zzzz]:1111:2222:3333
Enter Destination MAC address [xxxx:yyyy:zzzz]:2222:1111:1111
Link hashed [hash_val:0] to is GigabitEthernet0/0/0/1 member id 0 ifh 0xc0

P2P AC-PW Cross-Connect (EoMPLS)

This slide illustrates the components of an EoMPLS service. On the left, an
LC with an EFP is configured. On the right, an interface with MPLS is
enabled and connected to an MPLS PE peer device. The EFP is cross-
connected to an EFP on the neighbor MPLS PE with an MPLS pseudowire.
This is a transparent, point-to-point connection. No MAC learning is
performed on the EFP or the PW. All EFP VLAN operations are supported.
Multi Protocol Label Switching (MPLS) is a set of procedures for
augmenting network layer packets with label stacks, thereby turning
them into labeled packets. It defines the encoding used by a label switching
router to transmit such packets over PPP and LAN links. It is an Ethernet
Tag Switching protocol. This protocol attaches labels to IP and IPv6
protocols in the network layer, after the data link layer headers, but before
the network layer headers. It inserts a four- or eight byte label.
Two Label Switched Routers (LSRs) which use LDP to exchange label
mapping information are known as LDP peers and they have an LDP
session between them. In a single session, each peer is able to learn about
the others label mappings, in other words, the protocol is bidirectional.
References:
draft-rosen-tag-stack-02.txt
draft-ietf-mpls-ldp-07.txt
draft-ietf-mpls-rsvp-lsp-tunnel-05.txt
RFC 4446
RFC 4447
RFC 4448

Module 14 P2P AC-PW Cross-Connect (EoMPLS)
P2P AC-PW Xconnect (EoMPLS)
MPLS
uplink
MPLS PW PW
tunnels
L2
EFP P2P EoMPLS
GE or 10GE
port MPLS
Ingress LC Switch fabric Egress LC network
Point-to-point E-Line service extends between two EFPs (on different

platforms) via an EoMPLS pseudowire (PW).
Frames ingress on the EFP are forwarded onto the PW and vice versa.
No MAC learning by default
VLAN tag operations performed before MPLS encapsulation

What Is a Pseudowire?
Ethernet-over-MPLS (EoMPLS) provides a tunneling mechanism for
Ethernet traffic through an MPLS-enabled Layer 3 core and encapsulates
Ethernet PDUs inside MPLS packets (using label stacking) to forward them
across the MPLS network. The basic idea involves assigning short, fixed-
length labels to packets at the ingress of an MPLS cloud (based on the
concept of forwarding equivalence classes [FEC]). Throughout the interior of
the MPLS domain, the labels attached to packets are used to make
forwarding decisions.
A Label Switch Path (LSP) is the resulting virtual path between Label
Switch Routers (LSRs), in an MPLS network. An LSP is defined by labels
at the LSRs. PEs usually act as LSRs. LSRs use signaling to communicate
label usage and packets are switched based on labels attached to each
packet.
The MPLS architecture does not assume a single label distribution protocol.
LSPs may be signaled with Label Distribution Protocol (LDP) or targeted
LDP (T-LDP) for LSP tunnels and the Resource Reservation Protocol
(RSVP) (for MPLS-Traffic Engineering [MPLS-TE] tunnels) across the
MPLS Packet Switched Network (PSN).
Layer 2 transport services over MPLS are implemented through the use of
two-level label switching between the edge routers. The label used to route
the packet over the MPLS backbone to the destination PE is called the
tunnel label. The label used to determine the egress interface is referred to
as the VC label.
Redundancy options include backup PW and TE preferred path.
When tunneling over MPLS network, Cisco uses the term AToM: Any
Transport over MPLS. When tunneling over IP, L2TPv3 is used (not
supported currently on the Cisco ASR 9000).

What Is a Pseudowire (PW)?
MPLS point-to-point link that provides a single service

LDP and MPLS-TE tunnels are supported
One or more labels may be added to customer data traffic
PW or
Virtual MPLS PSN Tunnel
Circuit (VC)
MPLS
CE Access CE
Customer 1 Customer 1
Access PE PE
L2PDU L2PDU PH L2PDU PH TH L2PDU PH L2PDU
PH Pseudowire header
THTunnel header

EoMPLS Basic Configuration Steps

Before you can create an AC-PW or EoMPLS E-Line services, you must
make sure that the MPLS PIE file is installed and activated.
Configure IGP and MPLS on an uplink or core-facing interface.
Configure a local EFP and xconnect it to the neighbor PE with the other
EFP. Repeat this process for the other EFP.
____________________________ Note _________________________
The neighbor address of a PW must equal the LDP router ID.
The PW type and control word can be set with the PW-class CLI.
The control word cannot be negotiated back to set if it was already reset,
without removing the configuration from both sides of the PWs and
redoing it.
__________________________________________________________________

EoMPLS Basic Configuration Steps
MPLS must be operating to build PWs:

1. Verify that the MPLS PIE is installed, activated
and committed
2. Verify IGP and MPLS configuration
3. Ensure Loopbacks are advertised and reachable
Build EFPs and cross-connect with a PW:
1. Configure EFP (matching, rewrite, and so on)
2. Cross-connect the EFP to an EoMPLS PW
pointing to the neighbor address of the PE with
the far-end EFP
3. Repeat this process on the far-end PE to
complete the bidirectional service

P2P AC-PW Xconnect CLI

This slide includes CLI examples for EoMPLS configuration. On the left,
EFP configuration is entered on an ingress LC interface. This includes
VLAN matching and rewrite operations, and QoS policy.
On the right, an interface is enabled for MPLS. This includes IGP
configuration and LDP configuration.
An EoMPLS cross-connect is used to connect the EFP to a PW (pw-id 100)
that reaches to the neighbor (router ID 2.2.2.2).
This slide shows only half of the required configuration. For a complete,
bidirectional configuration, the EFP on the other side of the point-to-point
EVC must be configured and another PW pointing back to the local EFP
must be created.

MPLS
Ingress LC Switch fabric Egress LC
uplink
MPLS PW
MPLS neighbor
10.2.2.2
PW
tunnels
2. Create EFP
int bundleEthernet100.2 l2transport 1. Enable IGP and MPLS.

rewrite ingress tag < > 3. EoMPLS cross-connect
service-policy input < >
service-policy output < > l2vpn
xconnect group AC2PW_1
p2p PE1_PE2_1_A
interface bundleEthernet100.2
Note: Only one-half of EoMPLS
crossconnect configuration is shown.

MPLS VC Type
The Cisco ASR 9000 supports manual VC type configuration for point-to-
point EoMPLS VCs. However, for VPLS or the bridge-domain spoke or
access PWs, the VC type is always 5, which is not user configurable.
By default, the Cisco ASR 9000 uses VC type 5 for both EoMPLS and VPLS
VC. It can negotiate to be VC type 4 automatically based on the peers VC
type for point-to-point EoMPLS. However, for VPLS or spoke/access PW, it
is always VC type 5.
Most vendors platforms support VC type 5 for VPLS and H-VPLS. If
interoperability is an issue, try popping outer VLAN tags.

MPLS VC Type
Type 5 is the default PW type for EoMPLS and VPLS

EoMPLS is user configurable to Type 4
The Cisco ASR 9000 can negotiate automatically if
peer is Type 4.
Be aware of PW-type mismatch between devices.
Best practice: Always pop outer VLAN tag
regardless of PW Type

Pseudowire VC Type 5
The default VC Type is Type 5 (Ethernet). VC types used on EoMPLS
pseudowires can be configured to Type 4 (Ethernet VLAN) using the pw-
class command.
VLAN tag information from the ingress 802.1q frame is copied to the VC
label. At egress, the VC label data is used to rewrite the egress VLAN tag.
If the EoMPLS VC type is 5, no additional VLAN tag is added to the frame
after the configured rewrite operations.
For EoMPLS cross-connects, ingress VLAN (single or double) tags must be
popped. The VLAN tags after the rewrite tag configuration are treated as
payload for EoMPLS and will be tunneled regardless of VC type.
Summary: The rewrite ingress tag configuration is independent of VC type
for EoMPLS configuration. It is used to decide which VLAN tag is tunneled
as payload. Based on VC type, a random service delimiter VLAN tag maybe
added (for VC type 4), which should be removed and replaced by a peer PE
device based on its UNI configuration.

interface GigabitEthernet0/0/0/4.1 l2transport interface GigabitEthernet0/0/0/5.1 l2transport

rewrite ingress tag pop 1
rewrite ingress tag pop 1
INTF 1
PE2
PE1
INTF 1
MPLS
l2vpn l2vpn
xconnect group CISCO p2p SERVICE_1 xconnect group CISCO p2p SERVICE_1
interface GigabitEthernet0/0/0/4.1 interface GigabitEthernet0/0/0/5.1
neighbor 10.2.2.2 pw-id 22 neighbor 10.1.1.1 pw-id 22
Pop outer Pop outer

VC type 5 tag tag
10 10
Single tag frame
No dummy tag. Only MPLS

tags are shown

VLAN (Type 4) packets are untagged and VLAN-ID can change.
With VC type 4, an additional dummy (random) VLAN tag is added before
PW encapsulation. The peer PE removes the dummy tag and rewrites it
based on its UNI configuration before sending it to CE device.
If the service-delimiter VLAN tag is not popped before mapping into the
PW, it can cause duplicated (double) VLAN tags to be sent to the peer PE. If
the peer PE is not capable of removing these extra tags, they will be passed
as on UNI, and eventually they are dropped at the CE device.


rewrite ingress tag pop 1 rewrite ingress tag pop 1
INTF 1
PE2
PE1
INTF 1
MPLS
l2vpn
l2vpn
xconnect group CISCO p2p SERVICE_1
xconnect group CISCO p2p SERVICE_1
interface GigabitEthernet0/0/0/5.1
pw-class TYPE4
pw-class TYPE4
Pop outer Pop outer
VC type 4 tag tag
10 tag 10
Single-tag frame Dummy- tag frame
Type 4 - dummy
tag added

Pseudowire Type Mismatch

If the ingress VLAN tag is not popped before mapping into the PW, it can
cause a duplicated (double) VLAN tag to be sent to the peer PE. The
original tag is treated as data.
If the peer PE is not capable of removing of this extra tag, it is passed as is
on to the UNI and eventually is dropped at the CE device.
There is no implicit pop with VC type 4 PWs. Popping the outer tag must
be explicitly configured under the EFP

Pseudowire Type Mismatch

rewrite ingress tag pop 1 symmetric
INTF 1
PE2
PE1
INTF 1
MPLS
l2vpn l2vpn
xconnect group CISCO p2p SERVICE_1 xconnect group CISCO p2p SERVICE_1
neighbor 10.2.2.2 pw-id 22 neighbor 10.1.1.1 pw-id 22
pw-class TYPE4 pw-class TYPE4
VC type 4 No pop!
Tag mismatch
10 10 tag 10 10
Single-tag frame
Dummy-tag frame
Un-popped tag(s)
treated as data

Pseudowire Class Configuration in L2VPN Mode

Enter pseudowire class submode to define a pseudowire class template, use
the pw-class command in L2VPN configuration submode. To delete the
pseudowire class, use the no form of this command.
To specify a PW class, enter L2VPN configuration mode. Use the
transport-mode vlan command for Type 4 PWs and the transport-mode
ethernet command for Type 5 PWs.
Apply the pw-class configuration when creating a PW in conjunction with
the neighbor command.

PW Class Configuration in L2VPN Mode
PW Class Configuration in L2VPN Mode
(config)# l2vpn PW type 4

VLAN
pw-class TYPE4
encapsulation mpls
transport-mode vlan
PW type 5
pw-class TYPE5 Ethernet
encapsulation mpls
transport-mode ethernet
xconnect group TEST p2p TESTPW

interface GigabitEthernet0/2/0/36
pw-class TYPE4
Apply in conjunction with
the neighbor command
xconnect group TEST p2p TESTPW2
pw-class TYPE5

Verify LDP and Cross-connect State

The show mpls ldp neighbor detail command gives detailed information
about the LDP session with a particular neighbor.
The show l2vpn xconnect command gives the cross-connect segment state
and description.

Verify LDP and Cross-connect State
# sh mpls ldp neighbor 10.2.2.2 detail Verify MPLS LDP

session with peer
TCP connection: 10.2.2.2:11263 - 10.1.1.1:646
Graceful Restart: Yes (Reconnect Timeout: 120 sec, Recovery: 0 sec)
Up time: 6d08h
LDP Discovery Sources:
Targeted Hello (10.1.1.1 -> 10.2.2.2, active)
Addresses bound to this peer:
10.2.2.2 172.21.116.20 172.21.116.21 192.168.112.2
192.168.122.2
Peer holdtime: 180 sec; KA interval: 60 sec; Peer state: Estab
NSR: Disabled
Clients: AToM
View cross-connect Local AC

status
# sh l2vpn xconnect
Legend: ST = State, UP = Up, DN = Down, AD = Admin Down, UR = Unresolved,
LU = Local Up, RU = Remote Up, CO = Connected
PW
XConnect Segment 1 Segment 2
Group Name ST Description ST Description ST
------------------------ ------------------------- -------------------------
AC2PW_1 PEa_PEb_1_A
UP BE100.2 UP 10.2.2.2 101 UP

Verify Cross-connect Status

The show l2vpn xconnect detail command shows detailed information
about the cross-connects, including VC labels, MTU, PW type, VCCV status,
and packet counters.

Verify Cross-connect Status
# sh l2vpn xconnect detail

Group AC2PW_1, XC PEa_PEb_1_A, state is up; Interworking none
AC: Bundle-Ether100.2, state is up
Type VLAN; Num Ranges: 1
VLAN ranges: [11, 11]
MTU 1504; XC ID 0xfffc0004; interworking none
Statistics:
packets: received 272962, sent 126
bytes: received 18563306, sent 9601
PW: neighbor 10.2.2.2, PW ID 101, state is up ( established ) Local and remote
PW class not set, XC ID 0xfffc0004 PE PW details
Encapsulation MPLS, protocol LDP
PW type Ethernet, control word disabled, interworking none
PW backup disable delay 0 sec
Sequencing not set
MPLS Local Remote

------------ ------------------------------ -----------------------------
Label 143991 16023
Group ID 0xa020060 0x801fe20
Interface Bundle-Ether100.2 Bundle-Ether102.1
MTU 1504 1504
Control word disabled disabled
PW type Ethernet Ethernet
VCCV CV type 0x2 0x2
(LSP ping verification) (LSP ping verification)
VCCV CC type 0x6 0x6
(router alert label) (router alert label)
(TTL expiry) (TTL expiry)
------------ ------------------------------ -----------------------------


Verify Layer 2 Forwarding

The show l2vpn forwarding location command gives the cross-connect
Layer 2 forwarding information base (L2FIB) entries for a particular LC.
In this example, cross-connect information for the LC in slot 0/6 is given.
The segments should be bound. There should not be any unresolved entries
in the forwarding table.

Verify Layer 2 Forwarding
Forwarding plane
details
RP/0/0/CPU0:PE1#sh l2vpn forwarding detail location 0/2/cpu0
Local interface: Bundle-Ether100.2, Xconnect id: 0xfffc0004, Status: up
Segment 1
AC, Bundle-Ether100.2, status: Bound
Statistics:
packets dropped: PLU 0, tail 0
bytes dropped: PLU 0, tail 0
Segment 2
MPLS, Destination address:10.2.2.2: pw-id 101, status: Bound
Pseudowire label: 16023
Statistics:
packets dropped: MTU 0, tail 0
bytes dropped: MTU 0, tail 0

PW MTU Settings
The Ethernet MTU is the size of the largest frame, minus the 4-byte frame
check sequence (FCS) that can be transmitted on the Ethernet network.
Every physical network along the destination of a packet can have a
different MTU.
The Cisco ASR 9000 can adjust the MTU automatically based on the EFP
VLAN tag encapsulation and the VLAN tag manipulation configuration.
The default payload MTU is 1500 bytes which excludes VLAN tags. If
VLAN tag encapsulation is single tag, the MTU will be adjusted to 1504
bytes. MTU is part of the PWE3 T-LDP signaling message. If the MTU on
the two devices does not match, then the PW will not come up. There are
two options to work out the MTU mismatch issue:
Option 1: pop VLAN tag. This is recommended configuration which
applies to most cases
Option 2: Change the per sub-interface MTU size
Although Option 1 is the preferred configuration, in certain cases, VLAN
tag rewrite is not allowed or cannot match on both sides. In those cases
MTU configuration is required.
The Cisco ASR 9000 supports per-sub-interface MTU configuration on the
control plane. This is used for PW signaling purposes only. The ASR 9000
system does not enforce the per sub-interface MTU configuration in the
data plane.

PW MTU Setting
PW MTU Settings
MTU is part of PW end-end Emulation (PWE3) signaling

PW MTU setting must match on peer devices
Different platforms may have different MTU values
If MTU mismatch is occurring, the recommended
practice is to either:
pop VLAN tags; OR
adjust EFP MTU on the Cisco ASR 9000 PE
EFP MTU on the Cisco ASR 9000 is only used for
signaling, it is not enforced in the data plane

Layer 2 MTU Calculation

The Layer 2 MTU of the sub-interface is calculated as follows:
By default, port Layer 2-MTU=1514 bytes. If no Layer 2 MTU is configured
on the sub-interface, then the Layer 2 MTU is derived from the Layer 2
MTU inherited from the main interface:
sub-l2-mtu = parent-l2-mtu + (4 * encaps-tag-count).
For example, if it has a single encapsulation tag configured, the sub-
interface MTU becomes 1514 + 4 =1518
If the sub-interface has an explicit MTU configured, the Layer 2 MTU of the
sub-interface is the minimum of the configured value and the value
calculated from the parent-Layer 2-mtu as described above.
sub-l2-mtu = min (cfg-sub-l2-mtu, (parent-l2-mtu + (4 *
encaps-tag-count)))
For example, if mtu 1514 configured under a Layer 2 sub-interface
explicitly, the sub-interface MTU will be min(1514,1518) = 1514
The Layer 2 payload MTU of the sub-interface or PW MTU is calculated as
follows:
sub-l2-payload-mtu (which is used for the PW signaling) =
sub-l2-mtu (14 + (4 * (pop-tags-count push-tags-count)))
The intention behind the Layer 2 MTU definition is to try and preserve an
IP payload of 1500 bytes under default configuration and hence to increase
the sub-interface Layer 2 MTU to accommodate space for the tags that are
known to be present due to the encapsulation.
Jumbo frame support is automatically enabled for frames that exceed the
standard frame size. The default value is 1514 for standard frames and
1518 for VLAN-tagged frames. These numbers exclude the 4-byte frame
check sequence (FCS).

Layer 2 MTU Calculation
The Layer 2 MTU of a subinterface is the same as the MTU

of the parent interface, by default.
If the subinterface has an explicit MTU configured, then the
subinterface MTU is the smaller of the two values.
For example, if mtu 1514 configured under a Layer 2 sub-
interface explicitly, the sub-interface MTU will be:
min(1514,1518) = 1514.
Subinterface payload MTU (which is used for PW
signaling):
Sub-if MTU (14+(4*(pop tag count-push tag count)))
By default, payload MTU = 1500

Pseudowire Redundancy
If a CE or PE node fails, or an attachment circuit goes down, the PW goes
down and the L2VPN service that uses the PW also goes down.
With PW redundancy, a backup PW is created that can be tied to a different
remote PE box or a different attachment circuit on the same remote PE box,
depending on which component is being protected. When the primary PW
goes down, normally due to PE node failure or attachment circuit failure, it
can quickly switch over to the backup PW.
One-way PW redundancy:
PE node or AC redundancy is only unidirectional (it is one-way PW
redundancy).
Two-way PW redundancy:
Having redundant PEs or ACs on both sides is called two-way PW
redundancy, which is supported currently.
Allows dual-homing of two local PEs to two remote PEs
Four PWs: 1 primary & 3 backup provide redundancy for a dual-homed
device on both sides.
Two-way PW redundancy requires multichassis LAG (MC-LAG) on the
access side (MC-LAG is outside the scope of this course).

Module 14 Pseudowire Redundancy
Pseudowire Redundancy
Backup
PW
PE3
CE1 PE1
(backup
PE)
Primary
PW
1
2 3
PE2 CE2
(primary
Solves L2VPN service failures: PE)
1. P or PE failure due to IGP or MPLS reconvergence

2. PE failure due to HW or SW fault
3. Attachment circuit failure

PW Redundancy Configuration
Use the backup neighbor command to specify a backup PW to the same
neighbor or to a different neighbor.
A backup delay (optional) can be set in pw-class configuration mode.
____________________________ Note _________________________
When configuring PW backup, make sure you create a return-path PW
from the backup PE. This step is not shown in the slide.
__________________________________________________________________
The l2vpn switchover neighbor <ip-address> <pw-id> command
applied to the current active PW can be used to force a manual switchover.

PW Redundancy Configuration
Configure backup neighbor using backup command

PE1(config)# l2vpn
PE1(config-l2vpn)# xconnect group AC2PW_1 p2p PE1_PE2_1_A
PE1(config-l2vpn-xconnect-p2p)# interface bundleEthernet100.2
PE1(config-l2vpn-xconnect-p2p)# neighbor 10.2.2.2 pw-id 101
PE1(config-l2vpn-xconnect-p2p-pw)# backup neighbor 10.3.3.3 pw-id 101
PE1(config-l2vpn-xconnect-p2p-pw)# commit
Optionally configure backup delay under pw-class(default is
0 sec)
PE1(config)# l2vpn
PE1(config-l2vpn)# pw-class PWBACKUP
PE1(config-l2vpn-pw)# backup disable delay 20
PE1(config)# l2vpn
PE1(config-l2vpn)# xconnect group AC2PW_1 p2p PE1_PE2_1_A
PE1(config-l2vpn-xconnect-p2p)# interface bundleEthernet100.2
PE1(config-l2vpn-xconnect-p2p)# neighbor 10.2.2.2 pw-id 101
PE1(config-l2vpn-xconnect-p2p-pw)# pw-class PWBACKUP
PE1(config-l2vpn-xconnect-p2p-pw)# backup neighbor 10.3.3.3 pw-id 101
PE1(config-l2vpn-xconnect-p2p-pw)# commit

PW Redundancy Verification
Use the show l2vpn xconnect command to display cross-connect details
including backup PW configuration.
Traffic is always blocked on one PW for loop prevention, using the active or
inactive state of the pair of PWs being used. The backup PW is held in the
standby state, eliminating any loops between PEs.
In case of failures, status indications from lower-layer protocols (VCCV) and
peer PEs trigger a PW switchover. The backup PW to the redundant PE
becomes active.
The l2vpn switchover xconnect neighbor A.B.C.D pw-id X command
(for example, l2vpn switchover xconnect neighbor 10.5.5.5 pw-id 1) on
the active PW can be used to force a manual switchover between active and
backup PWs.

PW Redundancy Verification
State of Backup
PW will be
DOWN unless
Primary PW
fails
PE1# sh l2vpn xconnect
Legend: ST = State, UP = Up, DN = Down, AD = Admin Down, UR = Unresolved,
LU = Local Up, RU = Remote Up, CO = Connected
XConnect Segment 1 Segment 2

Group Name ST Description ST Description ST
------------------------ ------------------------- -------------------------
AC2PW_1 PE1_PE3_1_A UP BE100.2 UP 10.2.2.2 101 UP
Backup
10.3.3.3 101 DN
Note: Configuration of the return-path of the backup PW from

the backup PE is not shown and must be implemented.

MPLS Path Selection

When a Layer 2 VPN is built on top of the Layer 3 MPLS infrastructure, it
can take full advantage of the advanced Layer 3 routing and MPLS fast-
convergence features.
For example, a L2VPN PW can be built on top of the MPLS TE tunnel by
dynamic or static TE tunnel selection configuration. This means that an
MPLS core link or P-node failure can be addressed by MPLS-TE or Fast
Reroute (FRR). As a result, the L2VPN data path can provide sub-50-
millisecond convergence times.
Preferred tunnel path functions let you map pseudowires to specific TE
tunnels. Attachment circuits are cross-connected to specific MPLS TE
tunnel interfaces instead of remote provider-edge router IP addresses
(reachable using Interior Gateway Protocol [IGP] or Label Distribution
Protocol [LDP]).
If the specified path is unreachable, you can specify that the virtual circuits
(VCs) should use the default path, which is the path that MPLS Label
Distribution Protocol (LDP) uses for signaling. The option of having a
backup LDP path is enabled by default; you must explicitly disable it.
Use the show l2vpn xconnect detail command to show the status
of fallback (that is, enabled or disabled).

Module 14 MPLS Path Selection
MPLS Path Selection
Both LDP and MPLS TE

Tunnel paths between
source and destination
P1
LDP
PE2
PE1
LDP Upon failure of Preferred

LDP LSP
P2 Path, an alternate TE or
TE tunnel 1
LDP path can be used.
TE tunnel 2 This can be combined with
MPLS-TE Fast Reroute
(FRR)
Preferred Path failure

MPLS-TE Preferred Path Options

Fallback disable disallows customer from using the LDP path if the tunnel
is not up. The traffic mapped to this preferred path is dropped.
Support for fallback enable allows the use of an alternate path (either
another TE tunnel or an LDP LSP) in case of tunnel path failure.
The PW flaps and traffic is dropped momentarily (for approximately 10
seconds). When the preferred path comes back up, the PW switches back to
the preferred path, and traffic is momentarily dropped again.
____________________________ Note _________________________
Fallback enable is supported in Release 3.9. MPLS-TE with Fast-Reroute
can be used in conjunction with the MPLS-TE Preferred Path feature as
an option.
__________________________________________________________________

MPLS-TE Preferred Path Options
The preferred path feature allows the user to specify

and MPLS-TE tunnel to be used by an MPLS
crossconnect.
If the MPLS-TE preferred path fails, there are two
Fallback options:
With Fallback With Fallback
Fallback options
enabled (default) disabled
1. LDP (no backup MPLS-TE tunnel
Fallback to LDP Traffic drop
defined)
2. Backup MPLS-TE tunnel with
Fallback to backup
Autoroute Announce and Fast Reroute Traffic drop
TE tunnel
(FRR) enabled
Note: The following examples only show the configuration of the

source PE. The Destination PE must also be configured.

MPLS-TE with Fallback to LDP

The slide on the opposite page shows an example of MPLS-TE tunnel
creation using an explicit-path.
The major steps are:
1. Create an MPLS-TE tunnel interface and specify a dynamic path or a
named explicit-path used to the destination
2. Optionally define and explicit path using strict or loose path
parameters
3. In L2VPN mode, create a PW-class (which is like a template that can
be applied to a PW), and specify the preferred-path of the PW as the
MPLS-TE tunnel created in Step 2
4. The PW class statement is applied to the EoMPLS PW under the
neighbor statement in L2VPN xconnect mode (shown on the next
page)


1. Create an MPLS-TE tunnel (this example uses an explicit-path)
PE1(config)# interface tunnel-te12
PE1(config-if)# ipv4 unnumbered Loopback0
PE1(config-if)# signalled-bandwidth 1000
PE1(config-if)# destination 10.2.2.2
Optional
PE1(config-if)# path-option 1 explicit name PATH_12
explicit-path to
the destination
2. Define an explicit-path (if not using dynamic paths)
PE1(config)# explicit-path name PATH_12
PE1(config-expl-path)# index 2 next-address strict ipv4 unicast 192.168.111.11
Specify an MPLS-TE tunnel as the
preferred path.
3. Create an l2vpn pw-class and preferred-path
PE1(config)# l2vpn Fallback is enabled by default.
PE1(config-l2vpn)# pw-class TEPP
Fallback disabled can be entered
PE1(config-l2vpn-pwc)# encapsulation mpls
here.
PE1(config-l2vpn-pwc-mpls)# preferred-path interface tunnel-te 12

MPLS-TE with Fallback to LDP (Cont.)

MPLS-TE tunnels must be configured before an MPLS-TE preferred path
can be implemented on the tunnels.
Specify MPLS-TE preferred path configuration in pw-class configuration
mode.
Verify the configuration with the show l2vpn xconnect neighbor detail
command.
To view the state of MPLS-TE tunnels with FRR enabled use the show
mpls traffic fast database command.


4. Specify a pw-class to be used by the EoMPLS crossconnect
PE1(config)# l2vpn xconnect group AC2PW_1 p2p PE1_PE2_1_A
PE1(config-l2vpn-xc-p2p)# interface bundleEthernet100.2
PE1(config-l2vpn-xc-p2p)# neighbor 10.2.2.2 pw-id 101
Specify the MPLS-TE pw-class
PE1(config-l2vpn-xc-p2p-pw)# pw-class TEPP
PE1# show l2vpn xconnect detail

Group AC2PW_1, XC PEa_PEb_1_A, state is up; Interworking none
PW-class showing
(output omitted here) MPLS-TE preferred
PW: neighbor 10.2.2.2, PW ID 101, state is up ( established ) path
PW class TEPP, XC ID 0xfffc0004
PW type Ethernet, control word disabled, interworking none Preferred-path with
PW backup disable delay 0 sec fallback enabled
Sequencing not set
Preferred path tunnel TE 12, fallback enabled
In the above example, if the MPLS-TE tunnel Preferred Path goes

down, the crossconnect will fallback to an LDP path

MPLS-TE Fallback with FRR

MPLS-TE Fast Reroute (FRR) can be used to provide fast switchover
between MPLS-TE tunnels.
This summarized example shows two MPLS-TE tunnels being created, the
primary tunnel with a statically created path, and the backup tunnel with a
dynamically created path.
The two tunnels are then configured with FRR establishing a primary and
backup path. MPLS-TE FRR can be used in conjunction or independently of
PW Backup.

MPLS-TE Preferred Path Configuration

MPLS-TE Fallback with FRR
PE1(config)# interface tunnel-te 12 Primary tunnel with an

explicit path assigned
PE1(config-if)# path-option 1 explicit name PATH_12 FRR enabled on the
PE1(config-if)# signalled-bandwidth 1000 primary tunnel
PE1(config-if)# fast-reroute
PE1(config-if)# autoroute announce Autoroute Announce must be enabled
!
PE1(config-if)# interface tunnel-te 120
Backup tunnel with a
dynamic path
PE1(config-if)# signalled-bandwidth 1000
PE1(config-if)# path-option 1 dynamic
!
FRR backup tunnel assigned
PE1(config)# mpls traffic-eng
PE1(config-mpls-te)# interface GigabitEthernet0/2/0/1
PE1(config-mpls-te-if)# backup-path tunnel-te 120
In the above example, if the primary MPLS-TE tunnel goes down,

the crossconnect will fallback to the backup MPLS-TE tunnel
using FRR

EoMPLS and VPWS Troubleshooting

Use the basic checklist on the slide on the opposite page to troubleshoot
EoMPLS or VPWS configurations.

EoMPLS and VPWS Troubleshooting
1. Are the physical interfaces up? (Use show int Gig !)

2. Is the cross-connect up? (Use show l2vpn xc detail). Check that both
segments are up.
3. Is traffic running on the physical interface? (Use show int gig ! on the
physical interface to examine counters).
4. Is traffic being classified to the correct subinterface? (Use show int gig ! on
the subinterface to examine counters).
Note: Physical interface counters are from MAC, subinterface counters
from after classification.
5. Check L2VPN counters: show l2vpn forwarding detail location 0/2/cpu0
6. If PW segment of cross-connect is not up:
Check for consistent configuration on both ends of PW (CW, transport type
4/5, PW ID, MTU!)
Check for MPLS reachability (ping IP/ loopback address of PW neighbor)

Summary
Cisco ASR 9000 Point-to-point Layer 2 Services
Describe and configure local E-line service

Describe and configure link bundles
Describe and configure EoMPLS E-Line service
Describe and configure PW resiliency

Module 15
Cisco ASR 9000 Multipoint Layer 2 Services
Overview
Description
This module provides a detailed description of the Multipoint Layer 2
services supported by the Cisco ASR 9000 Series Aggregation Services
Router. This includes an overview of local and Virtual Private LAN
(VPLS) Ethernet-LAN (E-LAN) services, and service resiliency.
Objectives
Describe how attachment circuits (ACs), Ethernet flow points (EFPs),
bridge-domains (BDs) and multiprotocol label switching (MPLS) are
Describe and configure local E-LAN and VPLS service
Describe and configure VPLS autodiscovery and resiliency features

Cisco ASR 9000 Multipoint Layer 2 Services Module 15
Visual ObjectiveCisco ASR 9000 Lab Topology

In the hands-on lab that accompanies this module, students create local
multipoint and virtual private LAN service (VPLS) E-LAN configurations,
logically connecting three pods. A separate VPLS established with BGP
PW autodiscovery is also configured.
Ethernet OAM (E-OAM) and Connectivity Fault Management (CFM) or
service-based OAM are added to the local multipoint and VPLS services in
later labs.

Module 15 Visual ObjectiveCisco ASR 9000 Lab Topology

Visual Objective ASR-9k Lab Topology
Layer 2 Service Infrastructure

UNI UNI
NNI NNI
P P
CE1 PE1 PE2 CE2
(GE) (GE) (GE) (GE)
VPLS
Cisco mesh Cisco
ASR Cisco ASR
9000 12000 9000
PE3 CE3
Cust A Ethernet or Cisco

Loc 1 MPLS Access IP or MPLS
Core ASR
and 9000
Aggregation

E-LAN Service
E-LAN connects many user-network interfaces (UNIs) together with a
virtual bridge. UNIs can exist locally on a single port, line card (LC), or
platform. UNI connections can also be configured to extend over an MPLS
network to other UNIs on other geographically dispersed provider-edge
(PEs) devices in the network.

Module 15 E-LAN Service
E-LAN Service
E-LAN service provides multipoint connectivity (can

connect two or more UNIs).
UNIs can be local to a single platform or across many
platforms.
UNI 1 UNI 2
CE Carrier Ethernet CE
Network
UNI 4 UNI 3
CE CE
Multipoint-to-multipoint connection

Two Types of E-LAN

Layer 2 native Ethernet multipoint bridging has the following features:
MAC-based forwarding and learning among two or more EFPs
Per-port (local) VLAN significance on EFPs
Split-horizon group configurable to prevent switching between EFPs
in a group
VPLS has the following features:
Ethernet multipoint bridging over a PW mesh
Split horizon support over attachment circuits (configurable) and
PWs (default)

Two Types of E-LAN
MP Ethernet
bridge-domain 3
EFPs
EFPs L2 L2
BD
Split
horizon
group
MPLS
MP VPLS 4 uplink
MPLS PW
L2 PWs tunnels
BD VFI
GE or 10GE
ports Ingress LC Sw itch fabric Egress LC

BD
The bridge-domain (BD) concept is used to differentiate the notion of
VLAN as an encapsulation from VLAN as a broadcast domain. A BD
defines a multiport broadcast domain. Thus, the VLANs within the BD
have local significance per port. VLAN tags can be reused on separate
services.
BD attributes are as follows:
Layer 2 broadcast domain consisting of a set of physical or virtual
ports, or both.
Data frames are switched within a BD based on their destination
MAC address. Multicast, broadcast, and unknown-destination unicast
frames are flooded within the BD. A learned address is aged out.
MAC limits can be configured per BD or per BD port.
Static MAC address support.
Traffic storm control.
Many Layer 2 features are applied per BD such as DHCP snooping
and Internet Group Management Protocol (IGMP) snooping.

BD
A bridge-domain (BD) is the key Bridge-domain

building block of multipoint
bridging.
A BD is a logical multiport switch
MAC learning
with ports that consist of MAC limiting
physical ports, EFPs, bundles, MAC flushing
or PWs. Split-horizon groups
IGMP snooping
All ports on the BD are in an Storm control
Ethernet broadcast domain.
Split horizon groups (SHGs) can
be used to filter communication Physical or virtual ports,
between EFPs. or PWs
Many features are applied at the

BD level.

Split Horizon on Multipoint Bridging

The Cisco IOS XR software supports split horizon groups (SHGs) within
Layer 2 VPLS bridges. An SHG consists of a collection of bridge ports.
Traffic cannot flow between members of a split horizon group. This
restriction applies to all types of traffic; including broadcast, multicast,
unknown unicast, and known unicast. If a packet is received on a bridge
port that is a member of an SHG, that packet will not be sent out on any
other port in the same SHG.
A SHG can be configured and ACs can be assigned. One SHG can be
configured per BD. The ACs under a BD either belong in this group or do
not belong. By default, the group does not have any ACs. You can configure
individual ACs to become members of the group using the split-horizon
group command.
You can configure an entire physical interface or EFPs within an interface
to become members of a SHG.
SHG names or IDs are not used. In the show l2vpn bridge-domain
detail command output, the following convention is used in the split
horizon group field to describe the split horizon status of each port:
Enabled: Port belongs to the SHG
None: Port does not belong to the SHG

Split-Horizon on Multipoint Bridging
Multiple EFPs Bridging among

mapped into one EFPs enabled
global BD for L2
bridging
Split-horizon option BD
used to enable or
disable bridging SHG
between EFPs No bridging among

EFPs in a Split
Split-horizon can be Horizon Group, i.e.
no connectivity at L2
enabled and disabled
per EFP. SHG
EoMPLS PW
BD
SHG VPLS
Enabled on PWs by EoMPLS PW
default.

Local E-LAN Configuration

Begin by creating a BD in global configuration mode. Assign EFPs to the
BD.
Many features are applied per-BD including adding interfaces, setting BD
parameters, and so on.

Local E-LAN Configuration
Configure EFP matching, rewrite, QoS, ACL, etc.

Assign EFPs to bridge-domain
Set SHG parameters as desired
Create BD, assign
interfaces, set BD
parameters
EFPs
EFPs L2 L2
BD
SHG
Create EFPs

BD CLI Configuration Steps

To create a BD to interconnect local EFPs, and so on, follow the same two-
step process found in the creation of point-to-point Layer 2 services.
First, configure the EFPs, bundles, or physical interfaces that will be
member ports of the BD.
Second, enter L2VPN configuration mode, create a bridge group and a BD,
and assign the member interfaces.
In addition, you can configure split-horizon groups, IGMP snooping, and so
on.

BD CLI Configuration Steps
(config)# l2vpn
(config-l2vpn)# bridge group BG_1
(config-l2vpn-bg)# bridge-domain BD_1 EFP not in a SHG
(config-l2vpn-bg-bd)# interface g0/2/0/25.1
(config-l2vpn-bg-bd)# interface bundle-eth100.3 EFPs in an SHG if desired
(config-l2vpn-bg-bd-ac)# split-horizon group
(config-l2vpn-bg-bd)# interface bundle-eth101.2
(config-l2vpn-bg-bd-ac)# split-horizon group
Create l2vpn and create a bridge group

Create a bridge-domain
Specify member interfaces
Specify SHG settings on interfaces (off by default)
Specify additional BD-specific config (VFI, MTU,
IGMP snooping, DHCP snooping, flooding, etc.)

show Commands for L2VPN BD

The following commands are used to troubleshoot BD-based configurations:
group: (Optional) Selects a particular bridge group name.
bd-name (Optional) Selects a particular BD name.
interface: (Optional) Displays only the BD that contains the specified
interface as an AC. Only the matching AC is displayed, and no PWs are
displayed.
neighbor IP addr pw-id-value: (Optional) Displays only the BD that
contains the matching PW. Only the matching PW is displayed, and no
ACs are displayed.
brief: Brief hardware information retrieved from the Network processor
unit (NPU).
____________________________ Note _________________________
Issue the l2vpn forwarding resynchronize mac-address table
location < > command to update the RP software MAC table before
using the show l2vpn forwarding bridge-domain mac-address
commands.
__________________________________________________________________

show Commands for L2VPN BD
sh run l2vpn BD Settings and

Statistics
sh l2vpn bridge-domain [brief] [summary] [detail]
sh l2vpn bridge interface <> detail BD Settings and
Statistics per interface
sh l2vpn forwarding bridge-domain [detail] [hardware ]
[location] SW MAC
Table
sh l2vpn forwarding bridge-domain mac-address location
sh l2vpn forwarding bridge-domain [name] mac-address
[hardware] detail location Show NPU
MAC Table HW MAC
sh controllers np counter np0 loc 0/2/cpu0 Table
clear l2vpn forwarding mac-address bridge-domain <>
Clear BD MAC
Tables

BD show Commands
The following slide shows the output of show l2vpn bridge-domain
commands.

BD show Commands
RP/0/RSP0/CPU0:PE1# show l2vpn bridge-domain summary

Number of groups: 3, bridge-domains: 3, Up: 3, Shutdown: 0 ACs, PWs, state
Default: 3, pbb-edge: 0, pbb-core: 0
Number of ACs: 5 Up: 5, Down: 0
Number of PWs: 4 Up: 4, Down: 0
RP/0/RSP0/CPU0:PE1# show l2vpn bridge-domain

Bridge group: BG_1, bridge-domain: BD_1, id: 1, state: up, ShgId: 0, MSTi: 0
Aging: 300 s, MAC limit: 4000, Action: none, Notification: syslog MAC settings
Filter MAC addresses: 0
ACs: 3 (3 up), VFIs: 0, PWs: 0 (0 up), PBBs: 0 (0 up)
List of ACs:
BE100.3, state: up, Static MAC addresses: 0
BE101.2, state: up, Static MAC addresses: 0 List of ACs
Gi0/2/0/25.1, state: up, Static MAC addresses: 0
List of Access PWs:
List of VFIs:
Aging: 300 s, MAC limit: 4000, Action: none, Notification: syslog
(detail omitted)

The following slide shows the output of the show l2vpn bridge-domain
detail command.

BD show Commands (Cont.)
RP/0/RSP0/CPU0:PE1# show l2vpn bridge-domain detail

MAC learning: enabled
MAC withdraw: enabled BD summary
Flooding:
Broadcast & Multicast: enabled
Unknown unicast: enabled BD-level MAC
MAC aging time: 300 s, Type: inactivity settings
MAC limit: 4000, Action: none, Notification: syslog
MAC limit reached: no
MAC port down flush: enabled MAC table details
Security: disabled
Split Horizon Group: none
DHCPv4 snooping: disabled
IGMP Snooping profile: none
Bridge MTU: 1500
BD-level feature
MIB cvplsConfigIndex: 2
settings
Filter MAC addresses:
Create time: 16/12/2010 22:52:52 (1w5d ago)
No status change since creation
List of ACs: AC details
Type VLAN; Num Ranges: 1
VLAN ranges: [12, 12]
MTU 1504; XC ID 0xfffc0008; interworking none

MAC Learning on Ingress

The Cisco ASR 9000 Series router uses hardware-based MAC learning.
When a frame arrives on a bridge port (port or EFP) and the source MAC
address is unknown to the receiving PE router, the source MAC address is
associated with the PW or attachment circuit. Outbound frames to the
MAC address are forwarded to the appropriate PW or attachment circuit.
A hardware-based MAC table is used for forwarding on the LC network
processor unit (NPU).
A software-based MAC cache is maintained on the LC CPU, which must be
updated by the LC NPUs.
Use the following command to update the LC CPU and the RP MAC cache
before issuing a show MAC command:
l2vpn forwarding resynchronize mac-address-table location

MAC Learning on Ingress
1. New MAC 2. New MAC sent to

An LC NPU learns MAC source stored in local NP other LCs
addresses from frames ingress to a
BD.
New entries are sent to all other
NPUs participating in that BD via NPU CPU NPU
NPU-to-NPU messaging.
MAC entries are maintained in NPU
hardware.
BD BD
CLI show commands poll a software-
based MAC table on the RP which
require on-demand synchronization
with NPU MAC tables.
Ingress LC RP Egress LC
RP MAC cache
must be update
using CLI.

MAC Table Configuration Options

Many options are available to limit the size of the MAC table. You can
configure table size, age-out time, and add static MAC addresses.
MAC limits can be configured at the bridge domain level or at the bridge
port (EFP) level.
If a MAC table limit is reached, notification actions can be taken.
A global MAC limit counter is implemented on the RP.
Simultaneous BD and bridge port learn limits on the same BD are not
supported by the NPU.
Only one counter can be incremented by Learn Machine


Entries in the MAC table are aged out; the aging time is configurable
The MAC table size is configurable on an EFP or bridge-domain level
Configuration command is set per-AC OR per-BD MAC limit
Configuration options perform the following actions when MAC
table limit reached:
Syslog msg (default)
Limit Flood (stop learning)
Limit No-flood (stop learning and disable flooding)
Shut BD/AC
Static MAC addresses
Ability to statically configure MAC addresses
Simulates dynamically learned mac addresses; can be configured
both on AC and PW

MAC Aging, Limiting, Flooding

The slide on the opposite page provides examples of BD-based and AC-
based MAC limiting and other MAC table setting options.

VPLS MAC Limiting
BD-based MAC Limiting

l2vpn
bridge group BG_10 Bridge-domain
bridge-domain BD_10
mac limit
maximum 2000
AC-based MAC Limiting

l2vpn
bridge group BG_10
bridge-domain BD_10 AC
mac limit
maximum 2000
Other configuration options for MAC address under BD and AC

Aging,
mac <aging> | <learning> | <limit> learning, and
Mac limit also has associated actions with it such as SHUT BD, AC limiting
etc. options
The MAC limit includes both static MACs and dynamically learned MACs.
The static MACs are subtracted from the MAC limit passed to NP to be used for dynamic
MACs.
Current MAC limit is configured/default MAC limit minus static MACs not configured
at port level

BD Forwarding show Commands

The slide on the opposite page shows the output of the show l2vpn
forwarding commands.

RP/0/RSP0/CPU0:PE1# show l2vpn forwarding bridge-domain location 0/2/CPU0

Bridge MAC
Bridge-Domain Name ID Ports addr Flooding Learning State
-------------------------------- ------ ----- ------ -------- -------- ---------
BG_1:BD_1 1 3 0 Enabled Enabled UP
RP/0/RSP0/CPU0:PE1# show l2vpn forwarding bridge-domain detail location 0/6/CPU0

Bridge-domain name: BG_1:BD_1, id: 1, state: up
MAC port down flush: enabled
Flooding:
Broadcast & Multicast: enabled
Unknown unicast: enabled
MAC aging time: 300 s, Type: inactivity
MAC limit reached: no
Security: disabled
DHCPv4 snooping: profile not known on this node
IGMP snooping: disabled, flooding: enabled
Bridge MTU: 1500 bytes
Number of bridge ports: 3
Number of MAC addresses: 0
Multi-spanning tree instance: 0
GigabitEthernet0/2/0/25.1, state: oper up

Number of MAC: 0
Statistics:
Storm control drop counters:
packets: broadcast 0, multicast 0, unknown unicast 0
bytes: broadcast 0, multicast 0, unknown unicast 0 (additional ACs not shown)

BD MAC Table show Commands

The slide on the opposite page shows the output of the show l2vpn
forwarding bridge-domain mac-address location < > command.
____________________________ Note _________________________
Issue the l2vpn forwarding resynchronize mac-address table
location < > command to update the LC CPU and RP MAC table
before using the show l2vpn forwarding bridge-domain mac-
address commands.
__________________________________________________________________


RP/0/RSP0/CPU0:PE1# show l2vpn forwarding bridge-domain mac-address location 0/2/cpu0

To Resynchronize MAC table from the Network Processors, use the command...
l2vpn resynchronize forwarding mac-address-table location <r/s/i>
RP/0/RSP0/CPU0:PE1# l2vpn resynchronize forwarding mac-address-table location 0/2/cpu0

#LC/0/2/CPU0:Mar 17 20:52:34.670 : l2fib[191]: %L2-L2FIB-6-MAC_TABLE_RESYNC_COMPLETE : The
resynchronization of the MAC address table is complete
RP/0/RSP0/CPU0:PE1# show l2vpn forwarding bridge-domain mac-address location 0/2/cpu0

MAC Address Type Learned from/Filtered on LC learned Age
--------------------------------------------------------------------------------
0000.0100.0d00 dynamic Gi0/2/0/25.1 0/2/CPU0 0d 0h 2m 16s

0002.0002.0002 static Gi0/2/0/25.10 N/A N/A
This command does not require a Bridge-domain to be specified but a name can be
used within the command syntax in order to filter the output.
If MAC is missing in MAC table then look at MAC table in np struct 18 to verify that MAC is
missing there also or not. Caveat : Same MAC can be learnt on multiple bridges so 2 bytes bridge
id in little-endian format must be added to the search key make it unique for the bridge. To get
bridge id use the following command. show l2vpn bridge bd-name xxx

Virtual Private LAN Service

The VPLS network requires the creation of a BD (Layer 2 broadcast
domain) on each of the PE routers. The VPLS provider edge device holds
all the VPLS forwarding MAC tables and BD information. In addition, it is
responsible for all flooding broadcast frames and multicast replications.
With VPLS, all customer equipment (CE) devices participating in a single
VPLS instance appear to be on the same LAN and, therefore, can
communicate directly with one another in a multipoint topology, without
requiring a full mesh of point-to-point circuits at the CE device. A service
provider can offer VPLS service to multiple customers over the MPLS
network by defining different bridged domains for different customers.
Packets from one bridged domain are never carried over or delivered to
another bridged domain, thus ensuring the privacy of the LAN service.

Module 15 Virtual Private LAN Service
Virtual Private LAN Service
VPLS architecture
PE PE
CE CE
Tunnel LSP
Pseudowire
CE
The MPLS cloud acts like a virtual switch. It supports multipoint

communication between L2 sites.
PEs are linked with a PW mesh using split horizon. There are no spanning
tree protocols (STP) in the core.
PEs learn and store L2VPN site MAC addresses as well as allocate and
exchange labels for them.

Multipoint VPLS Using VSI

The PEs in the VPLS architecture are connected with a full mesh of PWs.
A virtual forwarding instance (VFI) is used to interconnect the mesh of
PWs. A BD is connected to a VFI to create a Virtual Switching Instance
(VSI) that provides Ethernet multipoint bridging over a PW mesh. VPLS
network links the VSIs using the MPLS PWs to create an emulated
Ethernet Switch.
MAC learning is performed per BD.

Two Types of Multipoint Ethernet Service
MPLS
Split horizon
group uplink
MPLS PW
L2 PWs tunnels
BD VFI
MP VPLS
GE or 10GE
MPLS
PW
mesh
BD VFI
EFPs
Virtual switching
instance (VSI)

VSI CLI Configuration Steps

To configure VSI, the BD portion is configured as for EFPs and bundles.
For the PW side, VFI configuration mode is entered under BD
configuration mode. In the L2VFI, a PW mesh is built using neighbor
statements.
The PW mesh can be manually created, or it can be dynamically created
using the BGP PW autodiscovery feature.

VSI CLI Configuration Steps
(config)# l2vpn
(config-l2vpn)# bridge group BG500 VFI config
(config-l2vpn-bg)# bridge-domain BD500 mode
VFI PW mesh to all
(config-l2vpn-bg-bd)# vfi 500
neighbors
(config-l2vpn-bg-bd-vfi)# neighbor 1.1.1.2 pw-id 1
Create l2vpn and bridge-domain

Specify member interfaces
Create a vfi
Specify neighbors

VPLS Split Horizon Rule

All PWs within a VFI are automatically in a SHG. Only one SHG exists
for forwarding PWs per VFI. By default, this group includes all PWs in the
VFI. The PWs are automatically added to the group. No configuration is
necessary or possible.
All PWs in a VFI are placed by default into the same SHG, which
effectively prevents traffic from forwarding to other PWs in the same VFI.
Assume that a packet from CE1 is bound for CE2. If PE1 does not know
MAC address of CE2, it multicasts the packet to PE2 (and all other
connected PEs). PE1 does not broadcast the frame to the AC from which
the frame was received. The other PEs do not forward the multicast frame
to other PWs in the same VFI, effectively eliminating a Layer 2 loop.
____________________________ Note _________________________
SHGs are not supported for access PWs.
__________________________________________________________________

Module 15 VPLS Split Horizon Rule
VPLS Split-Horizon Rule
Broadcast frame
CE1 PE1 PE2 CE2
Broadcast frames
PE3 received on a PW
are not forwarded
to other PWs in
Full Mesh of PW to guarantee frame delivery the same VFI
No STP protocols in the Core

Split-Horizon Forwarding
Packets coming on AC/PW area are not sent back on the
same AC/PW
Packets received on PW are not replicated on other PWs in
the same VFI

VPLS and MAC Tables

A packet from CE1 is bound for CE2. It leaves CE1 with a source MAC
address of M1 and a destination MAC address of M2. If PE1 does not know
where M2 is, it multicasts the packet to PE2 (and all other connected PEs).
When PE2 receives the packet, it has an inner label of 170. PE2 can
conclude that the source MAC address M1 is behind PE1, because it
distributed the label 170 to PE1. It can, therefore, associate MAC address
M1 with VC Label 170.

Module 15 VPLS and MAC Tables
VPLS and MAC Tables
Send me frames Directed LDP Send me frames

using Label 102 using Label 170
MAC1 MAC2
PE1 PE2
CE1 Use VC CE2
Label 102
E0/0 Use VC E0/1
Label 170
MAC Address Adj MAC Address Adj
MAC 2 170 MAC 2 E0/1
102 MAC1 MAC2 Data
MAC 1 E0/0 MAC 1 102
Data MAC1 MAC2 170
Broadcast, multicast, and unknown unicast are

learned via the received label associations
If inbound or outbound LSP is down, the entire PW is
considered down

MAC Address Withdrawal

A local N-PE sends an LDP MAC address withdrawal message to all
corresponding peer PEs if a VPLS topology change takes place or an access
link goes down. This provides faster convergence, minimizes traffic black-
holes, and controls service disruptions by updating related MAC address
changes from the local PE to the egress PE.
The MAC Address Withdrawal feature is one of the key components for
providing H-VPLS N-PE redundancy. MAC Address Withdrawal is needed
regardless of the access circuit type (MPLS or QinQ).
MAC address withdrawal message are sent in response to certain triggers:
AC/BD shut, configuration command to enable MAC address withdrawal.
PEs not supporting LDP MAC address TLV silently ignore it.
MAC Address Withdrawal is described in Section 6.2 of RFC 4762
MAC Address Withdrawal Procedure:
MAC addresses that must be removed are signaled using an LDP
Address Withdraw Message, using an LDP MAC List TLV.
The peer PE removes the AC association on the psuedowire on which
the MAC address withdrawal message is received and flushes the
associated MAC address table.
Newly active (originally, the backup) PE floods the packets until
peers re-learn the MAC addresses.
An empty MAC address withdrawal message with an empty MAC
TLV is sent if the MAC list TLV contains a many MAC addresses
PEs that do not understand MAC address messages can participate
in VPLS. These PEs discard a withdrawal message.
To enable the MAC address withdrawal feature, use the withdrawal
command in l2vpn bridge group BD MAC configuration mode. To verify
that the MAC address withdrawal is enabled, use the show l2vpn bridge-
domain command with the detail keyword.

MAC Address Withdrawal Message
MAC Address
withdrawal
X
X
MAC Address
withdrawal
On by default
Speeds up convergence process upon PE or AC failure
Otherwise PE relies on MAC address aging timer
Upon failure
PE removes locally learned MAC addresses
Send LDP address withdraw (RFC 3036) to remote PEs in VPLS
(using the Directed LDP session)
New MAC List TLV is used to withdraw addresses
PEs not supporting LDP MAC address TLV silently ignore it

VPLS Architecture Types

Direct attachment described in Section 4 of Draft-ietf-l2vpn-vpls-ldp:
Used for small customer implementations with simple provisioning
Full mesh of directed LDP sessions required between participating
PEs
VLAN and port-level support (no QinQ)
Drawbacks:
No hierarchical scalability, scaling issues
Full mesh causes classic - N*(N-1) / 2 concerns
Hierarchical VPLS described in Section 10 of Draft-ietf-l2vpn-vpls-ldp:

Best for larger scale deployment
Reduction in packet replication and signaling overhead
Consists of two levels in a hub-and-spoke topology:

Hub consists of full mesh VPLS PWs in MPLS core
Spokes consist of Layer 2 and Layer 3 tunnels connecting to VPLS
(Hub) PEs
QinQ (Layer 2), MPLS PWs

VPLS Architecture Types
Direct attachment
EFP attachment circuits
Hierarchical or H-VPLS comprising of two access
PW attachment circuits:
Ethernet Edge (EE-H-VPLS): QinQ tunnels
MPLS Edge (ME-H-VPLS): PWE3 PWs (EoMPLS)

Direct Attachment of VPLS (Flat Architecture)

The slide on the following page shows an example of a flat VPLS
architecture. Ethernet (that is, no PW on the access side) ACs are
connected directly to a VPLS PW mesh.

Direct Attachment of VPLS (Flat Architecture)
CE N-PE MPLS Core N-PE CE
MPLS Core
Ethernet Ethernet
(VLAN/Port/EFP) Full Mesh PWs + LDP (VLAN/Port/EFP)
Data MAC1 MAC2 802.1q

Customer Data MAC1 MAC2
Data MAC1 MAC2 VC Label Pseudo Wire

802.1 Ethernet SP Core
MPLS Ethernet

Direct Attachment VPLS Configuration

The following slide shows a configuration example of a flat VPLS
architecture. Ethernet ACs or EFPs have either been configured with the
l2transport encapsulation command set as default, untagged, or as a
single 802.1q tag and are connected directly to a VPLS PW mesh.
A PW mesh is configured in l2vfi mode.
An optional static MAC address is added, and MAC withdrawal is
configured.

Direct Attachment VPLS Configuration
interface gigabitEthernet0/2/0/5.1 l2transport

Ethernet EFP (untagged or default or 802.1q)
l2vpn Bridge-domain with

Bridge-domain
bridge group BG_10 optional static MAC
bridge-domain BD_10
static-mac-address 0003.0003.0003
(Optional) Static MAC
!
address
static-mac-address 0002.0002.0002
!
vfi VFI500
neighbor 10.2.2.2 pw-id 102 VFI with neighbor
neighbor 10.3.3.3 pw-id 102 PW mesh
configured
(Optional) Enabling MAC aging under Bridge Domain
l2vpn
bridge group BG_10
bridge-domain BD_10 Optional MAC aging
mac aging time 200 setting
!

Ethernet Edge H-VPLS (EE-H-VPLS)

The following slide illustrates an H-VPLS network. The hierarchy is
established by using QinQ in the access network. A QinQ AC is mapped
into a VPLS instance.

Ethernet Edge H-VPLS (EE-H-VPLS)
U-PE N-PE N-PE U-PE

CE MTU-s PE-rs MPLS Core PE-rs MTU-s CE
MPLS Core
1 2
802.1q QinQ
3 QinQ 802.1q
Access Tunnel Full Mesh PWs + LDP Tunnel Access
Vlan 802.1q
1 Data MAC1 MAC2 VPLS
CE Customer
Vlan Vlan QinQ
2 Data MAC1 MAC2 SP Edge
CE SP
Vlan Pseudo Wire
QinQ Ethernet 3 Data MAC1 MAC2 VC
CE SP Core

Ethernet Edge H-VPLS Configuration

The following slide shows an example of EE-H-VPLS configuration. The
EFP is a QinQ AC.

Ethernet Edge H-VPLS Configuration
QinQ EFP
interface gigabitEthernet0/1/0/10.500 l2transport
l2vpn QinQAC
Bridge-domain
bridge group BG18
bridge-domain BD180
!
interface GigabitEthernet0/1/0/10.500 VFI with neighbor
PW mesh
! configured
vfi VFI1800
neighbor 18.18.18.15 pw-id 8000

MPLS Edge H-VPLS

The following slide illustrates a second H-VPLS network option. In this
case, the access network runs MPLS and a spoke PW is used to connect
the CE or U-PE devices into the VPLS mesh via the PW AC.

MPLS Edge H-VPLS
U-PE N-PE N-PE U-PE

CE PE-rs PE-rs MPLS Core PE-rs PE-rs CE
MPLS MPLS
Access Access
MPLS Core
1 2
MPLS
802.1q MPLS 3 Pseudo 802.1q
Access Pseudo Wire Full Mesh PWs + LDP Wire Access
1 Vlan 802.1q
Data MAC1 MAC2
CE Customer H-VPLS
2 Vlan MPLS PW
Data MAC1 MAC2 VC1 Label 1
CE SP Edge
3 Vlan Pseudo Wire
Spoke PW Data MAC1 MAC2 VC2
CE SP Core

MPLS Edge H-VPLS Configuration

The following slide shows an example of an MPLS access network
connecting to an MPLS core. In this H-VPLS example, ACs are PWs.

MPLS Edge H-VPLS Configuration
MPLS configuration
(config)# mpls ldp on the interface that
(config-ldp)# interface gigabitEthernet0/5/0/10 connects the spoke
PW
l2vpn Bridge-domain PW AC
bridge group BG_1000
bridge-domain BD_1000
!
!
neighbor 11.11.11.1 pw-id 1111 VFI with neighbor
! PW mesh
vfi VFI1000 configured
neighbor 12.12.12.15 pw-id 5000

VPLS Configuration Prerequisites

Ensure that the MPLS package installation envelope (PIE) file is installed
and activated.
MPLS LDP configuration must be implemented and enabled in the core,
the edge, or both.
Ping neighbor loopback interfaces to verify connectivity.

Module 15 VPLS Configuration Prerequisites
VPLS Configuration Prerequisites
Before you configure VPLS, do the following:

Verify mpls.pie is installed and activated
Configure IP routing in the core.
Enable MPLS in the core.
Configure MPLS LDP on uplink interfaces
Configure a loopback interface. Make sure that
PE routers can access each others loopback
interfaces.

VPLS E-LAN Basic Configuration

Service creation, regardless of type, typically begins with EFP
configuration. When EFPs are configured, they are ready to be added to a
BD.
Add EFPs to a BD (in the case of direct attachment) or PWs if creating an
H-VPLS service, or both.
Create a L2VFI under the BD and add the PW mesh.

VPLS E-LAN Basic Configuration
Configure EFPs
matching, rewrite, QoS, ACL, etc.
Create a L2VPN Bridge-domain
Attach the EFPs to an bridge-domain
Within the bridge-domain, create a VFI with a PW mesh
connecting all neighbors
Optionally:
configure MAC learning/limiting features

VPLS show Commands

The slide on the opposite page provides examples of BD-based and AC-
based MAC limiting.

VPLS show Commands
RP/0/RSP0/CPU0:PE1# show l2vpn bridge-domain

Aging: 300 s, MAC limit: 4000, Action: none, Notification: syslog
ACs, PWs, state
List of ACs:
Gi0/2/0/5.1, state: up, Static MAC addresses: 0
List of Access PWs:
List of VFIs: VFI
VFI 10
Neighbor 10.2.2.2 pw-id 102, state: up, Static MAC addresses: 0
Neighbor 10.3.3.3 pw-id 102, state: up, Static MAC addresses: 0
RP/0/RSP0/CPU0:PE1# show l2vpn bridge-domain detail

MAC withdraw: enabled
Flooding: Detailed BD, AC
Broadcast & Multicast: enabled and VFI settings
Unknown unicast: enabled
MAC aging time: 300 s, Type: inactivity
(continued on next page)

The show l2vpn bridge-domain summary command, the show l2vpn

bridge-domain command, and the show l2vpn bridge-domain detail
command can be used to verify VPLS configuration.

VPLS show Commands (Cont.)
List of VFIs:
VFI 10
PW: neighbor 10.2.2.2, PW ID 102, state is up ( established )
PW class not set, XC ID 0xfffc0006
VFI details
PW type Ethernet, control word disabled, interworking none
PW backup disable delay 0 sec
Sequencing not set
VFI PW details
MPLS Local Remote
------------ ------------------------------ -------------------------
Label 143994 16027
Group ID 0x0 0x7
LDP information
Interface 20 20
MTU 1500 1500
Control word disabled disabled
PW type Ethernet Ethernet
VCCV CV type 0x2 0x2
(LSP ping verification) (LSP ping verification)
VCCV CC type 0x6 0x6
(router alert label) (router alert label)
(TTL expiry) (TTL expiry)
------------ ------------------------------ -------------------------
MIB cpwVcIndex: 5
Create time: 16/12/2010 22:49:48 (1w5d ago)
Last time status changed: 16/12/2010 22:49:54 (1w5d ago)
MAC withdraw message: send 0 receive 0
Static MAC addresses:
Statistics:
IGMP Snooping profile: none
PW: neighbor 10.3.3.3, PW ID 102, state is up ( established ) (additional info omitted)

VPLS Troubleshooting
Follow these guidelines to help troubleshoot and verify your VPLS
configuration:
Traffic is down, but bridge, AC, and PW are up. Why?
Check counters.
Determine which LC or interface is dropping the traffic.
Get counters on interface and subinterface.
Check MPLS forwarding labels.

Check if the labels match.

VPLS Troubleshooting
Why are my ACs in unresolved state?

Check if the AC is configured with l2transport.
Why are my ACs down?
If the AC interface is DOWN, check if the interface is shutdown
or the fiber is connected, bring it in UP state. Check if there is
an MTU mismatch.
Why are my PWs down?
Verify that LDP has core and loopback interface.
Verify LDP targeted session with neighbors.
Check if ping works.
Verify that IGP has core and loopback interface.
Check if PW up message was sent/received.

VPLS Auto-Discovery
BGP for PW auto-discovery: Auto-discovery, by nature, requires the VPN
information to be distributed to all members of a VPN multipoint
mechanism. BGP is well-suited for this purpose..
BGP for signaling: BGP is also used in signaling to exchange label bindings
and for convey MTU and state changes.
References:
VPLS with BGP Auto-discovery and BGP Signaling:
RFC 4761: Virtual Private LAN Service (VPLS) Using BGP for
Auto-Discovery and Signaling
VPWS with BGP Auto-discovery and BGP Signaling:
draft-kompella-l2vpn-l2vpn-02.txt: Layer 2 Virtual Private
Networks Using BGP for Auto-discovery and Signaling

Module 15 VPLS Auto-Discovery
VPLS Auto-Discovery
Problem:
Manual PW mesh creation for each PE.
Manual addition or deletion of new PEs is CLI-intensive
Increased costs and misconfiguration
Solution:
VPLS BGP Auto Discovery finds PEs within the same VPLS domain and
automatically detects when new PEs are added or removed from the
VPLS domain.
! BGP-AD (RFC 4761)
BGP Autodiscovery can also be used with VPWS
! draft-kompella-l2vpn-l2vpn-02.txt

BGP-AD Terminology
The following slide defines terminology important to VPLS and virtual
private wire service (VPWS) BGP-AD configuration.

BGP-AD Terminology
VPN-id
A representation of a BD or xconnect in the discovery database that stores all AD
information pertaining to the VPN (RD, RT, and so on). It must be unique within the
box because it is a key to index into the database. It is not distributed to other PEs
in the network.
RD (Route Distinguisher)
RD is a prefix that is added to the packet originating from the customer end to
distinguish traffic streams from different customers. RD must be unique within a
box, and it will be advertised to other PEs.
RT (Route Target)
Identifier of a VPLS bridge in a BGP network.
Export route target is the RT that is going to be in the network layer reach ability
information (NLRI) advertised to other PEs
Import route target is what the PE compares with the RT in the received NLRI. The
RT in the received NLRI has to match the import RT to decide that they belong to
the same VPLS service.
VFI can have multiple export or import RTs.
Multiple VFIs within a box can have the same RTs.

The following slide defines terminology important to VPLS and VPWS

BGP-AD configuration.

BGP-AD Terminology (continued)
ve-id (VPLS edge)

Must be unique to each PE in a particular VPLS. VFIs in the same VPLS service
cannot share the same ve-id but VFIs in different BDs can have the same ve-id. So it
does not have to be unique within a box.
ve-range
Used to override the minimum size of VE blocks
ce-id
Identifies the customer in VPWS AD configuration
NLRI (Network Layer Reachability Information)
Used to exchange information
AFI/SAFI (Address Family Identifier/Subsequent Address Family Identifier)
Defines the semantics of the NLRI messages

Discovery and Signaling

PE configuration consists only of the identity of the VPLS instance
established on this PE. The identity of other PEs are auto-discovered.
Each VPLS is associated with one or more BGP export Route Targets
(RTs).
A PE announces via BGP that it belongs to VPLS by annotating its NLRIs
with a defined RT and acts on this by accepting NLRIs from other PEs that
have same RT.
If a PE receiving VPLS NLRIs is configured with the VPLS associated with
a particular import RT, it can then import all the NLRIs tagged with the
same RT BGP PW setup (copied from RFC 4761).

Discovery and Signaling
Discovery (point to multipoint task)

Process of finding all the PEs that participate in a given VPLS instance.
Eliminates the need to manually provision a neighbor.
Signaling (set up point-to-point PWs)
Once discovery is done, each pair of PEs exchange demultiplexors, a
process known as signaling.
Signaling is also used to initiate "relearning" and to transmit certain
characteristics of the PE regarding a given VPLS.
Both discovery and signaling functions are accomplished with a single NLRI
UPDATE message.
The PW is provisioned in the same way as a manually configured PW (with
static MPLS labels).

LDP and BGP Configuration for VPLS or VPWS

The following slide shows the initial LDP and BGP configuration required
for VPLS PW auto-discovery.

LDP and BGP Configuration for VPLS or VPWS
PE1
CE3 PE3 CE1
MPLS Core
3.3.3.3 1.1.1.1
LDP config
PE3 PE1 BGP config
mpls ldp mpls ldp
router-id 3.3.3.3 router-id 1.1.1.1
interface GigabitEthernet0/2/0/3 interface GigabitEthernet0/3/0/0
! !
router bgp 100 router bgp 100 AF L2VPN config 1
bgp router-id 3.3.3.3 bgp router-id 1.1.1.1
address-family l2vpn vpls-vpws address-family l2vpn vpls-vpws
neighbor 1.1.1.1 neighbor 3.3.3.3
remote-as 100 remote-as 100
update-source Loopback0 update-source Loopback0
address-family l2vpn vpls-vpws address-family l2vpn vpls-vpws
AF L2VPN config 2

BGP Auto-Discovery and Signaling Configuration for VPLS

This following slide shows the CLI required to implement BGP AD and
signaling on a VPLS configuration.

Module 15
BGP Auto-Discovery and Signaling Configuration for VPLS
PE2 configuration PE2

not shown below CE2
CE3 PE3 PE1 CE1

MPLS Core 1.1.1.1
3.3.3.3 1.1.1.1
PE3 PE1
Autodiscovery
l2vpn l2vpn
attributes
bridge group GR1 bridge group GR1
bridge-domain BD1 bridge-domain BD1
vfi VF1 vfi VF1
vpn-id 100 vpn-id 100 VPN id is locally
autodiscovery bgp autodiscovery bgp significant
rd auto Signaling rd auto
route-target 1.1.1.1:100 attributes route-target 1.1.1.1:100
signaling-protocol bgp signaling-protocol bgp
ve-id 3 ve-id 5
RT must
ve-id must be unique per match peer
PE within same VFI

-PE and N-PE Redundancy Options

Regardless of redundant U-PEs, U-PE links, core devices, and core links,
connectivity loss occurs if there is no redundancy at the edge (the N-PE).
It is desirable to make use of redundant paths to meet scalability demands.
However, Ethernet networks, lacking a TTL field in the Layer 2 header,
are susceptible to broadcast storms if loops are introduced.
Cisco ASR 9000 routers operate as N-PE devices terminating U-PE access
rings and providing connectivity to the aggregation network. Because
these access rings have redundant connections, they are obviously required
to run some variant of STP to maintain loop-free connectivity.
However, loops are a desirable property, because they provide redundant
paths. Spanning Tree Protocol provides a mechanism by which one or more
loop-free spanning trees of links within the network are chosen to carry the
traffic, thus ensuring that all traffic can still flow from any point in the
network to any other and that no loops exist.
As such, STP must be able to load-balance across multiple paths. Basic
STP and RSTP do not allow for multiple spanning-tree instances. Multiple
Spanning Tree (MST, IEEE 802.1s, now merged into 802.1Q) addresses
these concerns by allowing multiple spanning-tree instances to exist within
an Ethernet network. Different VLANs are mapped to different spanning
trees, providing redundancy, load-balancing, and fast convergence.

Module 15 -PE and N-PE Redundancy Options
U-PE and N-PE Redundancy Options
Ethernet or EoMPLS VPLS or H-VPLS PW

ACs mesh
Redundant links,
single N-PE
Redundant links,
redundant N-PE MPLS core
CEs or U-PEs N-PE

Need redundant CEs, and PEs for HA
Redundant CEs, U-PEs, N-PEs and Core routers are essential to

minimize packet drop and provide traffic continuity.
The edge devices run IP/MPLS with a PW mesh.
Layer 2 access devices run a version of MST

AC Redundancy Overview
For native Ethernet networks, the Cisco ASR 9000 router supports the
widely deployed, standards-based Layer 2 redundancy protocol IEEE
802.1s, MST protocol.
For MPLS L2VPN services, to provide redundancy as well as to avoid
Layer 2 forwarding path loops, traditional Layer 2-based redundancy
protocols like MST do not apply. The challenge is that the Layer 2 access
and Layer 3 MPLS aggregation networks are disconnected from the
redundancy-protocol, control-plane point of view. However, from the data-
plane point of view, native Layer 2 access and L2VPN virtual circuit in
aggregation networks are combined to provide Layer 2 service for the end
user. This requires a mechanism to connect the control plane as well as the
data plane between the access and aggregation networks. MST Access
Gateway provides this mechanism.

AC Redundancy Overview
For Native Ethernet:

MST is an extension to STP that provides loop
protection and load balancing while allowing multiple
VLANs to be mapped to a single spanning tree instance.
For VPLS, H-VPLS:
MST Access Gateway allows two Cisco ASR 9000s PEs
to create a per-access ring MST instance using statically
configured BPDUs.

Overview of MST with Native Ethernet ACs

The Cisco ASR 9000 router operates standards-based MST. It does not
interoperate with a network running standard spanning tree protocol (STP
or 802.1D), standard rapid spanning tree protocol (RSTP, now in 802.1Q),
or any network running proprietary spanning tree variations such as
PVST+.
The access network control protocols should be in their own Layer 2
domain for easy provisioning, troubleshooting, migration, and
management.

Overview of MST with Native Ethernet ACs
Blocked for
Instance 2
Ethernet
network with Root (Instance 1)
an MST
domain
configured
Root (Instance 2)
CE U-PE
Blocked for
Instance 1
Different nodes can be the Root for different instances of

MST. On a given port, some instances may be Blocked;
whereas others will be Forwarding.

Access Redundancy with VPLS

Traditional STP does not work for Layer 2 segment because STP only
blocks the link if there is physical Layer 2 loop. The Cisco ASR 9000 uses
the MST Access Gateway feature to solve this problem.
In the slide graphic, Layer 2 access networks run MST, whereas the
aggregation network runs L3 IP/MPLS. Aggregation PEs have fully
meshed VPLS PWs to provide the L2VPN E-LAN services. Because there is
no physical Layer 2 loop in the access network, MST does not block any
link. However, from L2VPN service data forwarding point of view, it
creates a Layer 2 loop due to the PW mesh.
The Cisco ASR 9000s act as a gateway between Layer 2 access and
L3/MPLS aggregation to provide redundant L2 and L3 services to the
access network.
The basic idea of the MST access gateway protocol is to terminate
individual access MST instances locally at the port level. The gateway
router does not need to run the full MST state machine; thus, its more
scalable and simpler to implement. With local port significance, MST
instances from different ports are isolated from each other so that access
networks and their own MSTP instances do not impact each other.
If the primary N-PE router or the path to it fails, MSTP enables the path
to the backup N-PE router.
One of the N-PE routers should be a Root.
Designate a root N-PE by assigning it the lowest priority.
For MSTP, make sure each of the routers participating in the spanning-
tree are in the same region and are the same revision by issuing the
revision, name, and instance commands in MST configuration mode.

Access Redundancy with VPLS
VPLS mesh
Block segment Propagate TCNs creates a
of logical L2 loop logical loop
Isolate access
domain
control
protocols
Ethernet
U-PE
CE
MST access
gateway
Requirements:
Need to block Layer 2 PE-CE segment
Need to propagate TCNs from access to VPLS and vice-versa
Need to isolate access network control protocols

H- VPLS PW Redundancy
If a PW failure occurs, the Access ring reconverges, blocked links will move
to forwarding and U-PE2 sends a VPLS MAC withdrawal messages to all
other PEs.
Upon recovery, the active link will return to blocking, U-PE1 sends
another VPLS MAC withdrawal message.

H-VPLS PW Redundancy
H-VPLS PW Redundancy
Primary PW
U-PE2 N-PE2 N-PE1

H-VPLS
Customer MPLS Access
network
N-PE1 N-PE2
U-PE1
Backup PW
If a PW failure occurs, the Access ring reconverges, the blocked

link moves to forwarding and U-PE2 will send a VPLS MAC
withdrawal messages to all other PEs
Upon recovery, the link will return to blocking, U-PE1 sends

another VPLS MAC withdrawal

MST Access Gateway Operation

Each PE that is configure as part of the MST gateway sends precanned
BPDUs into the access network with every hello timer. The precanned
BPDU indicates a zero cost path to the best STP root bridge. The root
bridge is statically configured as one of the PEs or as a virtual bridge.
From an access network point of view, the STP topology has a Layer 2 loop.
Based on the BPDU it receives from the MST gateway bridges, it blocks
one of access links.
Because the access switch receives equal-cost best BPDUs, to block specific
link, it requires specific STP port costs to be configured on the access
switches. Configure a large STP port cost on the access switch to decide
which link is blocking.
PE root bridge: The primary gateway is configured as a virtual STP root,
giving the best root priority, zero cost, and best-bridge priority. The
backup gateway is configured with zero cost to the root bridge, and has the
second-best bridge priority
Virtual root bridge: Configure the same priority on both PEs to, in effect,
have both gateways appear as the same virtual bridge.

MST Access Gateway Operation
BPDU sent
Equal cost with zero
BPDU cost to root
received,
Layer 2 loop
detected,
block access
link
U-PE
CE
BPDU sent MST access
with zero gateway
cost to root
PEs send pre-set BPDU hellos with zero cost to root. The root is
statically configured.
Access devices see a Layer 2 loop as a result of pre-set BPDUs and
blocks the link.
To block a specific link, Access switches must have port costs set.

MST Access Gateway Configuration

There are two methods to configure an MST Access Gateway on the
Cisco ASR 9000 router. The first method involves creating unique bridge
IDs on each access gateway node. This method is shown on the following
slide.
The second method is to create a virtual root bridge by specifying a zero
cost to the virtual root bridge at each access gateway node. Both gateways
appear to be the same virtual bridge.
Access device configuration is similar in both cases.

MST Access Gateway Configuration
Two approaches to configuring MST:

1. Have the nodes advertise as though they are separate nodes.
Each node would have a different bridge-id, and generally the
instance and priority settings would be used to guarantee
ROOT selection.
2. Have the nodes advertise as though they are different ports
on the same node.
In this case they have identical configuration except for the
port-id.

MST Access Gateway and TCNs

Gateway PE snoops the TCN received from its access link. And this
triggers the VPLS MAC withdrawal. Link down or PW down does not
cause TCN/MAC withdrawal.


Sends VPLS MAC

Equal cost withdrawal to other PEs
BPDU
received, CE2 U-PE2 N-PE1
Layer 2 loop
detected, F1
block
access link
F1 U-PE1 N-PE2
Link failure CE1
Link originally MST access
blocked moves gateway
to forwarding
If failure occurs at F1, F2, or F3 the Access ring reconverges, the blocked link
moves to forwarding and U-PE1 will send VPLS MAC withdrawal messages to all
other PEs
Upon recovery, the blocked link returns to blocking, U-PE1 sends a VPLS MAC
withdrawal

MST Instance Configuration

The following slide illustrates one method of configuring MST Access
Gateway nodes. Each node is a root for unique instances of MST.

MST Instance Configuration
Untagged EFP for BPDUs

0,2
int gig0/0/0/10.1 l2transport int gig0/0/0/20.1 l2transport
encapsulation untagged encapsulation untagged
Instances 0,2 Instance 1

spanning-tree ring-termination RING1 1 spanning-tree ring-termination RING1
CEs
name CISCO MST name CISCO
revision 1 access revision 1
bridge-id 0000.0000.0002
bridge-id 0000.0000.0001
gateway
instance 0 instance 0
root-id 0000.0000.0001
Root for root-id 0000.0000.0001
priority 4096 Instance 0 priority 8192
root-priority 4096 root-priority 4096
! !
instance 1 instance 1
vlan-ids 101,103,105,107 Root for vlan-ids 101,103,105,107
root-id 0000.0000.0002 Instance 1 root-id 0000.0000.0002
priority 8192 priority 4096
! !
instance 2 Root for instance 2
vlan-ids 102,104,106,108 Instance 2 vlan-ids 102,104,106,108
root-id 0000.0000.0001 root-id 0000.0000.0001
priority 4096 priority 8192

MST Access CE Configuration

The slide following slide gives a summarized example of access switch
configuration. Link costs are set to block a particular link when converged.

MST Access CE Configuration
CE1 Instances 0,2 MST region, revision, and

instance-to-vlan mapping must
spanning-tree mode mst match on all CEs and PEs in the
spanning-tree mst configuration MST domain
name CISCO
revision 1
instance 0 0,2
instance 1 vlan 101,103,105,107
instance 2 vlan 102, 104, 106, 108
CE1
interface GigabitEthernet1/1/1
CE2
switchport mode trunk 1
spanning-tree mst 0,2 cost 100000
MST
access
CE2 Instance 1
gateway
spanning-tree mode mst
spanning-tree mst configuration High link cost for MST
name CISCO instances 0 and 2
revision 1
instance 0
instance 1 vlan 101,103,105,107
instance 2 vlan 102, 104, 106, 108
interface GigabitEthernet2/2/2
High link cost
switchport mode trunk
spanning-tree mst 1 cost 100000
for MST
instance 1

Summary
Cisco ASR 9000 Multipoint Layer 2 Services
Describe how attachment circuits (ACs), Ethernet flow points (EFPs),
bridge-domains (BDs) and multiprotocol label switching (MPLS) are
Describe and configure local E-LAN and VPLS service
Describe and configure VPLS autodiscovery and resiliency features

Module 16
Cisco ASR 9000 Operations, Administration
and Maintenance (OAM)
Overview
Description
This module provides a detailed description of the Operations
Administration, and Management (OAM) features.
Objectives
Describe and configure link-based OAM features (Ethernet-OAM or E-
OAM)
Describe and configure service-based OAM features (Connectivity Fault
Management or CFM)
Describe and configure MPLS OAM

Cisco ASR 9000 Operations, Administration and Maintenance (OAM) Module 16

In the hands-on lab that accompanies this module, students will add link-
based OAM to an existing local E-LAN service. Connectivity Fault
Management (CFM) or service-based OAM are added to the VPLS services.

Module 16 Visual ObjectiveCisco ASR 9000 Lab Topology

Visual Objective ASR-9k Lab Topology
CFM
E-OAM
MPLS OAM
P P
CE1 PE1 PE2 CE2
(GE) (GE) (GE) (GE)
VPLS
Cisco mesh Cisco
ASR Cisco ASR
9000 12000 9000
PE3 CE3
UNI Ethernet or
Cust A
IP or MPLS Cisco UNI
Loc 1 MPLS Access ASR
and Core
9000
Aggregation

OAM Protocol Positioning

The Operations, Administration and Maintenance (OAM) protocols are
designed to address the fault indication and performance monitoring
requirements in different segments and layers of a service providers
network. The goal is to reduce operating expenses (avoid a truck roll)
and minimize downtime cost. OAM benchmarks set by time division
multiplexing (TDM) and existing WAN technologies.
IEEE 802.3ah OAM is designed to run on any physical link to monitor the
link integrity. It is often used between customer edge (CE) and provider
edge (PE) devices to verify Ethernet physical connectivity in the First Mile
(EFM).
The 802.1ag Connectivity Fault Management (CFM) manages the end-to-
end connectivity of an Ethernet service with various levels of maintenance
domains.
MPLS OAM is used within the MPLS-enabled portion of the network to
monitor virtual circuit connectivity.

Module 16 OAM Protocol Positioning

E-OAM CFM (802.1ag)
Customer (802.3ah) Core Customer
Business Business
Backbone Backbone
Bridges Bridges
Provider Access
Bridges PWs
MPLS OAM
Residential E-OAM Residential
(802.3ah) IP/MPLS
UNI NNI NNI NNI UNI
E-OAM (802.3ah): Link OAM on any point-to-point 802.3 link

Connectivity fault management (CFM or 802.1ag): End-to-end
service OAM
MPLS OAM: Within MPLS cloud

Link OAM: E-OAM IEEE 802.3ah

Ethernet IEEE 802.3ah defines an OAM sublayer that provides
mechanisms useful for monitoring a link:
Discovery of peer E-OAM capabilities
Critical event detection (link fault, dying gasp or critical event)
Wire-speed data loopback

Remote variable retrieval
Link event reporting
Ethernet OAM can be implemented on any full-duplex point-to-point or

emulated point-to-point Ethernet link. A system-wide implementation is
not required; OAM can be deployed for part of a system; that is, on
particular interfaces. Normal link operation does not require Ethernet
OAM.
OAM frames, called OAM protocol data units (PDUs), use the slow protocol
destination MAC address 0180.c200.0002. They are intercepted by the
MAC sublayer and cannot propagate beyond a single hop within an
Ethernet network. The frame transmission rate is limited to a maximum
of 10 frames per second; therefore, the impact of OAM on normal
operations is negligible. (Standardized: IEEE 802.3ah, clause 57, now in
IEEE 802.3-2005).

Module 16 Link OAM: E-OAM IEEE 802.3ah
Ethernet-OAM; E-OAM or IEEE 802.3ah
Operates on a single point-to-point link between two devices

MAC-layer OAMPDUs use the slow protocol destination MAC address
(0180.c200.002)
Intercepted by MAC sublayer
Cannot propagate beyond a single hop
Customer Service Provider MPLS Core Customer

Eth Access
CE CE
802.3ah OAM
PDUs
E-OAM
(802.3ah)
CPE U-PE N-PE

E-OAM Discovery
Discovery is the first phase of Ethernet OAM and it identifies the devices
in the network and their OAM capabilities. Discovery uses information
OAM PDUs. During the discovery phase, the following information is
advertised within periodic information OAM PDUs:
OAM mode: Conveyed to the remote OAM entity. The mode can be
either active or passive and can be used to determine device
functionality.
OAM configuration: Advertises the capabilities of the local OAM
entity. With this information a peer can determine what functions
are supported and accessible; for example, loopback capability.
OAM PDU configuration: Includes the maximum OAM PDU size for
receipt and delivery. This information along with the rate limiting
of 10 frames per second can be used to limit the bandwidth
allocated to OAM traffic.
Platform identity: Combination of an organization unique identifier
(OUI) and 32-bits of vendor-specific information. OUI allocation,
controlled by the IEEE, is typically the first three bytes of a MAC
address.
Discovery includes an optional phase in which the local station can accept
or reject the configuration of the peer OAM entity. For example, a node
may require that its partner support loopback capability to be accepted
into the management network.

Discovery
First step in Ethernet OAM

Identify peer device and its capabilities
Decide whether to peer and bring up an OAM session
State machine:
1. Send Information OAMPDU in a periodic fashion (once
every second, by default)
2. Discover OAM configuration (for example, active or
passive mode, loopback mode, maximum OAMPDU size
of remote client, and so on)
3. Decide whether OAM clients can be fully operational on
the link
Use information OAMPDUs

E-OAM Link Monitoring

Link monitoring in E-OAM detects and indicates link faults under a
variety of conditions. Link monitoring uses the event notification OAM
PDU and sends events to the remote OAM entity when there are problems
detected on the link. It is enabled by default when E-OAM is configured.
The error events include the following:
Error Symbol Period (error symbols per second): The number of
symbol errors that occurred during a specified period exceeded a
threshold. These errors are coding symbol errors.
Error Frame (error frames per second): The number of frame
errors detected during a specified period exceeded a threshold.
Error Frame Period (error frames per n frames): The number of
frame errors within the last n frames has exceeded a threshold.
Error Frame Seconds Summary (error seconds per m seconds):
The number of error seconds (1-second intervals with at least one
frame error) within the last m seconds has exceeded a threshold.
IEEE 802.3ah OAM does not provide a guaranteed delivery of any OAM
PDU The event notification OAM PDU may be sent multiple times to
reduce the probability of a lost notification. A sequence number is used to
recognize duplicate events.

E-OAM Link Monitoring
On by default when E-OAM is enabled. Uses event notification

OAMPDU to communicate events to peer on configured threshold
being crossed
Monitor link quality over time, and generate events on excessive error
conditions
Four types of event supported:
Errored Symbol Period: Number of symbol errors (coding errors)
that occurred during a specified period
Errored Frame: Number of frame errors detected during a specified
period
Errored Frame Period: Number of frame errors within the last N
frames
Errored Frame Seconds: Number of errored seconds (one second
intervals with at least one frame error) within the last M seconds
Implementation can trigger actions on threshold crossing events

E-OAM Remote Failure Indication

A remote failure indication informs a peer that the receive path is down.
Faults in Ethernet connectivity that are caused by slowly deteriorating
quality are difficult to detect. E- OAM provides a mechanism for an OAM
entity to convey these failure conditions to its peer via specific flags in the
OAM PDU. The following failure conditions can be communicated:
Link Fault: Loss of signal is detected by the receiver; for

instance, a peers laser is malfunctioning. A link fault is sent
once per second in the information OAM PDU. Link fault
applies only when the physical sublayer is capable of
independent transmit and receive operations.
Dying Gasp: Unrecoverable condition has occurred; for
example, a power failure. This type of condition is vendor
specific. A notification about the condition may be sent
immediately and continuously.
Critical Event: Unspecified critical event has occurred. This
type of event is vendor specific. A critical event may be sent
immediately and continuously.

E-OAM Remote Failure Indication
Three types of remote failures:

Link Fault: Hardware detected fault that occurred in the
receive direction of the local equipment
Dying Gasp: Unrecoverable failure (for example, power
failure). The following is considered a dying gasp:
OAM deconfigured
Interface brought down (and differentiate Admin-
Down and Error-Disable)
Critical Event: Implementation-specific recoverable, but
critical, error occurred
Uses bits in header of every OAMPDU
The definition of specific faults is implementation specific.

E-OAM Loopback Mode

An OAM entity can put its remote peer into loopback mode using the
loopback control OAM PDU. Loopback mode helps an administrator ensure
the quality of links during installation or when troubleshooting. In
loopback mode, every frame received is transmitted back on the same port
except for OAM PDUs and pause frames. The periodic exchange of OAM
PDUs must continue during the loopback state to maintain the OAM
session.
The loopback command is acknowledged by responding with an
information OAM PDU with the loopback state indicated in the state field.
This acknowledgement allows an administrator, for example, to estimate if
a network segment can satisfy a service-level agreement.
Acknowledgement makes it possible to test delay, jitter, and throughput.
When an interface is set to the remote loopback mode, the interface no
longer participates in any other Layer 2 or Layer 3 protocols; for example
Spanning Tree Protocol (STP) or Open Shortest Path First (OSPF). The
reason is that when two connected ports are in a loopback session, no
frames other than the OAM PDUs are sent to the CPU for software
processing. The non-OAM PDU frames are either looped back at the MAC
level or discarded at the MAC level.
An interface in loopback mode is in a link-up state.

E-OAM Loopback Mode
Fault localization and link performance testing

Use the ethernet oam loopback enable (disable) <interface>
command (in global configuration mode) to start (or stop) remote
loopback in peer.
All traffic, except OAM PDUs sent from master loopback port, are
looped back by slave port.
OAM OAM
X
MAC MAC
PHY PHY
Master OAM client Slave OAM client

802.3 E-OAM Configuration

E-OAM can be configured in two ways; individual port configuration or by
using E-OAM profiles to configure multiple ports. If using profiles,
configure the profile and attach it to an interface. Updates to the profile
are automatically distributed to ports provisioned with that profile.
Some supported CLI:
mode {active | passive}
link-monitor
frame Frame event configuration
frame-period frame-period event configuration
frame-seconds frame-seconds event configuration
monitoring Monitoring support
symbol-period Symbol-period event configuration
link-monitor monitoring disable
action
capabilities-conflict Action to perform when a capabilities

conflict occurs
critical-event Action to perform when a critical

event occurs
discovery-timeout Action to perform when discovery

timeout occurs
dying-gasp Action to perform when a dying gasp

occurs
high-threshold Action to perform when a high-

threshold is crossed
link-fault Action to perform when a link fault

occurs
remote-loopback
mib retrieval
required remote
link-monitoring Requirement of Link monitoring support
mib-retrieval Requirement of MIB retrieval support
mode Requirement of a specific OAM mode
remote-loopback Requirement of Remote loopback support

E-OAM configuration
802.3 OAM Configuration
Configuring profiles (optional)

ethernet oam profile TEST User-defined threshold setting
link-monitor
frame threshold low 200
action high-threshold error-disable interface
mib-retrieval
Apply profile to interface (or configure directly)

ethernet oam profile TEST
In addition, port-specific
configuration can be added here

E-OAM Show Commands

The show commands listed on the following slide return information about
specific E-OAM configuration.

E-OAM Show Commands
RP/0/RSP0/CPU0:ios# show ethernet oam ?

configuration Show ethernet OAM configuration
discovery Show ethernet OAM discovery information
interfaces Show ethernet OAM interface state
statistics Show ethernet OAM statistics

E-OAM Show Command Discovery

The following slide shows the output of the show ethernet oam
discovery command. This shows what features have been made on the
local and remote E-OAM peers, per interface.
You can use the show ethernet oam discovery interface gig0/20/0/X
remote to show the values from the peers perspective (MIB retrieval must
be enabled on both ends).


RP/0/RSP0/CPU0:asr9k-ce# show ethernet oam discovery
GigabitEthernet0/2/0/0:
Local client Local E-OAM
------------ setting
Administrative configuration:
PDU revision: 6
Mode: Active
Unidirectional support: N
Link monitor support: Y Features
Remote loopback support: N enabled? Y/N
MIB retrieval support: N
Maximum PDU size: 1500
Mis-wiring detection key: 476D
Operational status:
Port status: Operational
Loopback status: None
Interface mis-wired: N Remote E-
OAM
Remote client
setting
Additional
------------- configuration
MAC address: 0024.98e8.20da not shown
Vendor (OUI): 00.00.0C (Cisco)
.
.
.

E-OAM Show Command Configuration

The following slide shows the output of the show ethernet oam
configuration command. This shows what settings have been made on
the local and remote E-OAM peers, per interface.


RP/0/RSP0/CPU0:asr9k-ce# show ethernet oam configuration
GigabitEthernet0/2/0/0:
Link monitoring enabled: Y
Per interface
Remote loopback enabled: N
Mib retrieval enabled: N
Configured mode: Active Features enabled? Y/N
Connection timeout: 5
Symbol period window: 0
Symbol period low threshold: 1
Symbol period high threshold: None
Frame window: 1000
Frame low threshold: 200
Link monitoring threshold
Frame high threshold: None
Frame period window: 1000
settings
Frame period low threshold: 1
Frame period high threshold: None
Frame seconds window: 60000
Frame seconds low threshold: 1
Event actions
Frame seconds high threshold: None
High threshold action: None
Link fault action: Log
Dying gasp action: Log
Critical event action: Log Additional
Discovery timeout action: Log configuration
Capabilities conflict action: Log
not shown
Wiring conflict action: Error-Disable

Connectivity Fault Management (CFM or 802.1ag)

Connectivity Fault Management (CFM) is a service-level, Layer 2 OAM
protocol that provides end-to-end fault detection, isolation, and reporting.
Key CFM terms are:
Maintenance domain (MD): Divides the network along administrative
boundaries
Maintenance association (MA): Monitors end-to-end services under a
domain, composed of MEPs and MIPs
Maintenance association identification (MAID): value that identifies a
particular maintenance domain. This value is carried within the CFM
PDUs.
Maintenance endpoint (MEP): Generates and responds to CFM PDUs
Maintenance intermediate point (MIP): Responds to CFM PDUs

Module 16 Connectivity Fault Management (CFM or 802.1ag)
Connectivity
Connectivity Fault(CFM
Fault Management Management
or 802.1ag)
(CFM or 802.1ag)
CFM provides capability to detect, verify, isolate, and report end-to-end

Ethernet connectivity faults
Provides EVC connectivity management and fault isolation
Uses Domains to contain OAM flows and bound OAM responsibilities
Three types of packets: Continuity Check, Ping, and Traceroute
Customer Service Customer

Provider
Eth MPLS
Access Core
Customer Domain
Provider Domain
Operator Operator Operator

Domain Domain Domain

CFM Maintenance Domain

An end-to-end network can be partitioned into different domains. From
the perspective of the SP, their domain is the part of the network that they
own and control. Outside the SP domain is the operator domain. SPs may
lease network resources from operators, but they have no control of those
networks. The customer domain extends to the endpoints of the network,
and it includes the CE devices.
In its simplest definition, a MD is a part of the network that is controlled
by a single operator. MDs provide a nested decomposition facility that
enables the separation of responsibility for network administration. The
administration of an end-to-end service at the largest scope can be
insulated from the administration of the networks composing that service.
MDs allow CFM to support multiple independent operators, each
supporting service instances from multiple independent customers. MDs
are identified by a globally unique MD name (MD name could be left
NULL).
MDs are also associated with an MD Level (ranging from 0 to 7). The
higher the MD level, the broader the scope of the domain (for example,
Customer Domain Level 7, SP Domain level 5, Operator Domain level 3).
In the innermost (narrowest scope) MD, every physical LAN can serve as
an implied MD (with an MD level of zero (0)). The MD level indicates (and
helps enforce) the nesting relationships among MDs.
Domains maintenance points are the next-higher level loopback points.
The MD level is included in the CFM PDUs sent by the CFM maintenance
points (MP). In that sense, a domain is like an AS.

CE CE
Operator A Operator B
Service Provider
Customer
MD defines operational or administrative boundaries:

Customer, SP, or operator (a single owner per domain)
May nest and touch, but never intersect
Up to eight levels of nesting: MD Level (07)
The higher the level, the broader its reach


In its simplest technical definition, a Maintenance domain (MD) is a set of
MEPs transmitting PDUs with identical MA value.
Maintenance Points at each level are invisible to all higher levels.
Maintenance association identifiers (MAIDs) are carried in CFM PDUs.
Checking the MAID value helps identify inadvertent connection of MEPs
in different services (different MAIDs).

CE Operator A Operator B CE
MA monitors connectivity of a particular service instance under

an MD:
Defined by a set of MEPs at the edge of a domain

CFM Maintenance Endpoint (MEP)

The MEP ID uniquely identifies each MEP among those configured on a
single MA.
MEPs source CFM messages. There are four types of CFM messages:
Continuity check
Loopback
Traceroute
Alarm indication signal (AIS)
The MEP IDs must be unique for each MA.

CFM Maintenance Endpoint (MEP)
MEP MEP
MEP MEP
MEP MEP MEP MEP
MEPs define the boundaries of an MD:

Supports the detection of connectivity failures between any
pair of MEPs in an MA
Associated per MA and identified by a MEPID (18191)
Can initiate and respond to CFM PDUs

Maintenance Intermediate Point

Maintenance Intermediate Points (MIPs) support the discovery of paths
among MEPs and the location of faults along those paths by responding to
received CFM PDUs.
MIPs are passive, they can only respond to CFM messages.

Maintenance Intermediate Point
MEP MIP MIP MEP
MEP MIP MIP MEP
MEP MIP MIP MEP MEP MIP MIP MIP MIP MEP
MIP MIP MIP MIP
MIPs support the discovery of paths among

MEPs and location of faults along those paths by
responding to received CFM PDUs.

Up or Down MEPs
CFM Continuity Check is the main protocol used for end-to-end fault detection
and notification. CFM MEPs are the active components of this protocol, because
they send continuity check messages (CCMs).
Inward-facing MEPs are referred to as UP MEPs in CFM standard. They can
send CCMs even if the port where a CCM is configured is down.
Outward-facing MEPs are referred to as DOWN MEPs in CFM standard. They
cannot send CCMs if the port where a CCM is configured is down.

Up or Down MEPs
UP/Down MEPs
Per link
DOWN MEPs are used for DOWN MEP
services spanning a single link Bridge 1 Bridge 2
can be used with Layer 2 and Bridge Bridge Bridge Bridge
Layer 3 interfaces
Port Port Port Port
UP MEPS are commonly used for Relay Relay
Entity Entity
services across multiple
switches for end-to-end Monitored area
connection with bridge-domain
or cross-connect Layer 2
interfaces UP MEP
Per service
MIPs are auto-created along the

Bridge 1 Bridge 2
path at intermediate nodes, as
defined by auto-create Bridge Bridge Bridge Bridge
configuration
Port Port Port Port
Relay Relay
Entity Entity
Monitored area

CFM Continuity Check Protocol

CFM Continuity Check Message (CCM) is a per-domain, per-VLAN
Multicast heart-beat message protocol.
Transmitted at a configurable periodic interval by MEPs (default is 30
seconds; range is from 10 seconds to 65535 seconds).
Contains a Hold-Time value to indicate to receiver validity of message
(default 2.5 x Transmit Interval, configurable).
Catalogued by MIPs at the same Maintenance Level.
Terminated by remote MEPs at the same Maintenance Level.
Uni-directional and it does not solicit a response.
Carries status of port on which MEP is configured

CFM Continuity Check Protocol
Catalogue and
Catalogue Catalogue Terminate
MEP MIP MIP MEP
1 2 3
Continuity Check Message
X
(CCM)
Used for Fault Detection and Notification

Per-Maintenance Association multicast heartbeat messages originated by MEP
Carries status of port on which MEP is configured
Unidirectional (no response required)
Transmitted at a configurable periodic interval by MEPs
Cataloged by MIPs at the same MD-Level, terminated by remote MEPs in the same MA

CFM Loopback Protocol

CFM Loopback Protocol uses an Ethernet ping to test link integrity. It
uses unicast frames sourced from a MEP and sent to a destination MEP or
MIP. It is specific to a domain. Replies are unicasts.
Loopback messages are generated on-demand via MIB or CLI.
Timestamps are embedded in loopback messages and can be used to
measure round-trip delay and one-way jitter.

CFM Loopback Protocol
S D
MEP MIP MIP MEP
1 1 1. Loopback message (LBM)

2 2 2. Loopback reply (LBR)
Used for fault verificationEthernet ping

MEP can transmit a unicast LBM to a MEP or MIP in the same
MA
Receiving MP responds by transforming the LBM into a unicast
LBR sent back to the originating MEP

CFM Linktrace Protocol

CFM linktrace is very similar in application to IP linktrace. It is useful for
path discovery and link integrity. It is used to discover the path taken to a
target MAC address. It is specific to a maintenance domain and VLAN. It
allows for the discovery of all MIPs belonging to the same MD along the
path to a destination.
The destination can be a MIP or a MEP.
Link trace message (LTM) is used to multicast from a MEP to its
neighboring MIP and from MIP to MIP, to the MP terminating the path.
LTM includes a time-to-live (TTL) to limit propagation within a network.

CFM Linktrace Protocol
6
S 4 D
2
MEP MIP MIP MEP
1 3 5 1, 3, 5
X Linktrace Message (LTM)
Y 2, 4, 6
Linktrace Reply (LTR)
Used for path discovery and fault isolationEthernet traceroute

MEP can transmit a multicast message (LTM) to discover the
MPs and path to a MIP or MEP in the same MA
Each MIP along the path and the terminating MP return a
unicast LTR to the originating MEP

CFM PDU Summary

The following slide summarizes the CFM PDU types and the transmission
methods used.

CFM PDU Summary
Summary of CFM PDUs defined per protocol and type

of frame used
CFM Destination
CFM PDU
Protocol MAC Address
Continuity
Continuity
Check Message Multicast
Check
(CCM)
Loopback
Unicast
Message (LBM)
Loopback
Loopback Reply
Unicast
(LBR)
Linktrace
Multicast
Message (LTM)
Linktrace
Linktrace Reply
Unicast
(LTR)

CFM Configuration-Up MEP

The following slide identifies the steps required to create a CFM Up MEP.
Start by configuring a CFM domain in global configuration mode. Other
parameters and attributes can be set at the global level, such as loopback
message size and CCM interval.
Next, configure CFM on a particular service by entering the cross-connect
or BD group name in CFM domain configuration mode.
Apply the MEP to an interface in EFP or subinterface configuration mode.

CFM Configuration-Up MEP
Configure domain in global configuration mode

Router(config)# ethernet cfm
Router(config-cfm)# domain domain-name level level-number
Configure service in global configuration mode using cross-connect or bridge-

domain
Router(config-cfm-dmn)# service service-name xconnect group group-name p2p xconnect-name
OR
Router(config-cfm-dmn)# service service-name bridge group group-name bridge-domain domain-name
Router(config-cfm-dmn-svc)# mip auto-create all | lower-mep-only
Router(config-cfm-dmn-svc)# continuity-check interval 1s|10s|1m|10m
Configure MEP in interface configuration mode
Router(config)# interface gi0/5/0/1.1 l2transport

Router(config-if)# ethernet cfm mep domain domain-name service service-name mep-id mep-number

CFM Configuration-Down MEP

The following slide identifies the steps required to create a CFM Down
MEP.
Start by configuring a CFM domain in global configuration mode.
Next, configure CFM on a particular service by entering the cross-connect
or BD group name in CFM domain configuration mode. Optionally, specify
a continuity-check interval.
Apply the MEP to an interface in EFP or subinterface configuration mode.

CFM Configuration-Down MEP

CFM Configuration Down MEP
Configure domain in global configuration mode
Router(config)# ethernet cfm
Router(config-cfm)# domain domain-name level level-number
Configure service in global configuration mode

Router(config-cfm-dmn)# service service-name down-meps
Router(config-cfm-dmn-svc)# continuity-check interval 1s|10s|1m|10m|100ms
Configure MEP in parent interface configuration mode

Router(config)# interface gi0/2/0/29
Router(config-if)# ethernet cfm mep domain domain-name service
service-name mep-id mep-number
Subinterface with EFP

Router(config)# interface gi0/2/0/5.1 l2transport
Router(config)# encap dot1q 100 second-dot1q 200
Router(config-if)# ethernet cfm mep domain domain-name service
service-name mep-id mep-number

Optional CFM Configuration

The slide to the right outlines additional CFM configuration options such
as MEP crosscheck, continuity-check logging, and maximum MEP settings.
Crosscheck allows for configuration of a static list of expected remote
MEPs per service. This list is crosschecked against what is learned
dynamically from CCMs. The CFM protocol generates appropriate alarms
when errors are detected.


MEP crosscheck (notification if CCM message not received)
Router(config-cfm-dmn)# mep crosscheck mep-id remote-mep-number
Logging (for changes or errors)

Router(config-cfm-dmn-srv)# log continuity-check mep changes
Router(config-cfm-dmn-srv)# log continuity-check errors
Router(config-cfm-dmn-srv)# log crosscheck errors
Maximum MEPS (per domain)

Router(config-cfm-dmn-srv)# maximum-meps number-max-meps-srv

CFM-show Local Maintenance Points

The show ethernet cfm local maintenance-points command shows all
the CFM maintenance points local to a platform.
The show ethernet cfm local meps command shows all the CFM MEPs
local to a platform.

CFM-show Local Maintenance Points
PE1# show ethernet cfm local maintenance-points

Domain/Level Service Interface Type ID MAC^M
-------------------- ------------------- ----------------- ------ ---- --------
D0M_1/0 SER_1 Gi0/2/0/5.1 Un MEP 1 1b:6a:e5
.
PE1# show ethernet cfm local meps verbose

Near-end MEPs,
Domain DOM_1 (level 3), Service SER_1 MIPs and state
Up MEP on GigabitEthernet0/2/0/5.1 MEP-ID 1
================================================================================
Interface state: Up MAC address: 0024.f71b.6ae5
Peer MEPs: 1 up, 0 with errors, 0 timed out (archived)
CCM generation enabled: Yes (Remote Defect detected: No)

AIS generation enabled: No
Sending AIS: No
Receiving AIS: No
Packet Sent Received

------ ---------- ---------------------------------------------------------
CCM 2748 2746 (out of seq: 0)
LBM 5 0
LBR 0 5 (out of seq: 0, with bad data: 0)
AIS 0 0
LCK - 0

CFM-show Peer MEPs

The show ethernet cfm peer meps command shows that:
State field is explained in the key.
Port field indicates the value of the port status TLV in incoming CCMs.
SeqErr field is the number of CCM out-of-sequence errors.

RDI field indicates the number of CCMs received with the RDI bit set.
Error field indicates the total number of errors seen. The types of error
are expanded upon in the detailed output.
The show ethernet cfm peer meps detail command shows information
about distant CFM endpoint MEPs including state, CCMs, and so on.

CFM-show Peer MEPs
PE1# show ethernet cfm peer meps detail

Domain DOM_2 (level 3), Service SER_2
Up MEP on GigabitEthernet0/2/0/5.1 MEP-ID 1
================================================================================
Peer MEP-ID 2, MAC badb.adbb.6b4a
Far-end MEPs, MIPs
CFM state: Ok, for 00:05:46
and state
Port state: Up
CCMs received: 3461
Out-of-sequence: 0
RDI: 0
Wrong Level: 0
Wrong MAID: 0 number of CCM messages received,
Wrong Interval: 0 errors
Invalid SMAC: 0
Our ID received: 0
Last CCM received 00:00:00 ago:
Level: 3, Version: 0, Interval: 100ms
Sequence number: 10251, MEP-ID: 2
MAID: String: DOM_2, String: SER_2
Chassis ID: Local: PE3; Management address: 'Not specified'
Port status: Up, Interface status: Up

CFM-show CCM
The show ethernet cfm ccm-learning-database command shows the
CFM CCM details including the CFM domain and service, the source MAC
address, and the interface on which it is configured.
The show ethernet cfm int statistics location command displays CFM
statistics for a particular LC.

CFM-show CCM
# show ethernet cfm ccm-learning-database

Location 0/2/CPU0:
Domain/Level Service Source MAC Interface

---------------------- -------------------- -------------- ------------------
D0M_2/3 SER_2 0001.0203.0402 PW : Neighbor 10.2.2.2
PW ID 102
#sh ethernet cfm int statistics Location 0/2/CPU0
Interface Malformed Dropped Last Malformed Reason
----------------- --------- --------- ---------------------
Gi0/2/0/5.1 0 1693783
Gi0/2/0/10.1 1332852 0 LTM Packet malformed -
destination MAC address

CFM-Ping
Use the CFM ping command to ping a CFM maintenance point to check
for connectivity.

CFM-Ping
CFM-Ping
# ping ethernet cfm domain DOM_2 service SER_2 mep-id 2

source mep-id 1 interface gig0/2/0/5.1 data-size 1200 count 35
Sending 35 CFM Loopbacks, timeout is 2 seconds -
Domain DOM_20 (level 3), Service SER_2
Source: MEP ID 1, interface GigabitEthernet0/2/0/5.1
Target: 001b.53ff.8402 (MEP ID 2):
Running (35s) ...
Success rate is 100.0 percent (35/35), round-trip min/avg/max =
1/1/1 ms
Troubleshoot using the following commands:

show ethernet cfm services
Show ethernet cfm local maintenance-points
Show ethernet cfm peer meps

MPLS OAM-VCCV
Virtual Circuit Connection Verification (VCCV) is an L2VPN Operations,
Administration, and Maintenance (OAM) feature that allows network
operators to run IP-based provider edge-to-provider edge (PE-to-PE)
keepalive protocol across a specified pseudowire to ensure that the
pseudowire data path forwarding does not contain any faults. The
disposition PE receives VCCV packets on a control channel, which is
associated with the specified pseudowire. The control channel type and
connectivity verification type, which are used for VCCV, are negotiated
when the pseudowire is established between the PEs for each direction.
MPLS Embedded ManagementLSP Ping/Traceroute and AToM VCCV
can detect when an LSP fails to deliver user traffic.
You can use MPLS LSP Ping to test LSP connectivity for IPv4 Label
Distribution Protocol (LDP) prefixes, traffic engineering (TE)
Forwarding Equivalence Classes (FECs), and AToM FECs.
You can use MPLS LSP Traceroute to trace the LSPs for IPv4 LDP
prefixes and TE tunnel FECs.
AToM VCCV allows you to use MPLS LSP Ping to test the Pseudo-Wire
(PW) section of an AToM virtual circuit (VC).
Internet Control Message ProtocolVCCV pings are used to verify or trace
PE-PE tunnel LSPs, similar to ICMP (IP) ping in the following ways:
Sequence number
Timestamps
Sender identification
Full identification of FEC, based on the application
Variable length for MTU discovery
Support for tunnel or path tracing
Multiple reply modes
Reference: IETF draft-ietf-lsp-ping-01.txt

Module 16 MPLS OAM-VCCV
Virtual Circuit Connection Verification (VCCV)
PSN
PW ping Pseudo Wire

MPLS
CE PE1 PE2 CE
Attachment Attachment
Circuit Circuit
MPLS-TE tunnel
One tunnel can serve many pseudo-wires.
MPLS LSP ping is sufficient to monitor the PSN tunnel (PE-
PE connectivity), but not PWs inside of tunnel.
Trace/Verify packets take same path as data packets

Verify PW Forwarding with VCCV

Enable VCCV by enabling MPLS OAM in global configuration mode.
Use the show l2vpn xconnect detail command to display VCCV
parameters.
The ping pseudowire command can be used to verify MPLS LDP and PW
configuration. Be sure to use the force-control-channel router-alert
label command extension to ensure proper MPLS OAM PW ping
operation.
force-control-channel - (Optional) Specifies the force of the a Virtual
Circuit Connection Verification (VCCV) control channel.
ra-label - (Optional) Specifies the label for the router alert.
If the control-channel option is added, the remote PE is sends the reply

back over the PW; otherwise, the reply is sent using IPV4

Module 16 MPLS OAM-VCCV
Verify PW Forwarding with VCCV

MPLS PW Ping
Router(config)# mpls oam

Router(config)# commit
Router# ping pseudowire 10.2.2.2 102 force-control-channel router-alert label
Sending 5, 100-byte MPLS Echos to 10.2.2.2 VC: 102,

timeout is 2 seconds, send interval is 0 msec:
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'X' - unknown return code, 'x' - return code 0
!!!!!

Summary
Cisco ASR 9000 Operations, Administration and Maintenance (OAM)
Describe and configure link-based OAM features

Describe and configure service-based OAM features
Describe and configure MPLS OAM features

Module 17
ASR 9000 Layer 2 Multicast
Overview
Description
This module defines the Layer 2 multicast features offered by the
Cisco ASR 9000 router. It begins with an overview of multicast concepts
including sources, receivers, and groups for both Layer 2 and Layer 3.
Internet Group Management Protocol (IGMP) snooping implementation.
Control-plane and data-plane architecture are discussed. The final section
gives deployment examples and shows the corresponding CLI commands.
Objectives
Describe the fundamentals of Layer 2 multicast
Describe Cisco ASR 9000 Layer 2 multicast control plane
Describe Cisco ASR 9000 Layer 2 multicast data plane
Configure Layer 2 multicast parameters
Describe Layer 2 multicast deployment considerations

ASR 9000 Layer 2 Multicast Module 17
Visual ObjectiveASR 9000 Lab Topology

Objective for hands-on lab
In the labs that accompany this module, you will perform the steps
necessary to create a multipoint Metro Ethernet service integrated with
multicast protocol awareness at Layer 2.
Multicast operating at Layer 2 will minimize the number of Ethernet
broadcasts in a BD resulting from flooding multicast MAC-addressed
traffic (the default). Ethernet traffic will be generated to simulate
customer traffic flowing across the service architecture.

Module 17 Visual ObjectiveASR 9000 Lab Topology
Visual ObjectiveASR 9000 Lab Topology
Source Receivers
P P
ASR ASR
9000 9000
ASR
9000
Multipoint Layer 2 Connection
Layer 2 and Layer 3 Multicast protocols enabled

Multicast Network Devices and Protocols

Multicast networks involve hosts (sources and receivers), and the routers
and switches that interconnect them. Multicast addresses at Layer 2 and
Layer 3 specify an arbitrary group of hosts that have interest in a
multicast group and want to receive traffic sent to this group. Multicast
protocols such as Protocol Independent Multicast (PIM) and IGMP operate
at Layer 3, providing routing and replication of multicast packets between
sources and receivers that are members of the same multicast group.
Routers enabled with multicast protocols replicate multicast traffic only
where necessary, preventing unnecessary usage of network bandwidth.

Module 17 Multicast Network Devices and Protocols

Routers Switches
G1
(PIM) (IGMP snooping)
G2
(S1,G1)
G1 G2
Sources
G1
G2 Receivers
(IGMP)

Layer 3 Multicast Creates a Layer 2 Broadcast

When processing a packet whose destination MAC address is a multicast
address, by default, a switch forwards a copy of the packet into each of the
remaining network interfaces that are in the forwarding state. This
behavior works well for broadcast packets that are intended to be seen or
processed by all connected nodes.
In the case of multicast packets, however, this approach could lead to less
efficient use of network bandwidth, particularly when the packet is
intended for only a small number of nodes. Packets are flooded into
network segments where no node has any interest in receiving the packet.
In general, significant bandwidth can be wasted by flooding.

Layer 3 Multicast Creates Layer 2 Broadcast
By default, L2 Broadcast
G1
switches treat Source
multicast traffic as
unknown or
Group 1 Data
broadcast and G1
must flood the
frame to every port Default
Router
G1,G2
This will happen
with every Group 2 Data
multicast packet
being sent from the G2
router
Receivers

IGMP Snooping Solution

Layer 2 multicast protocols operate in conjunction with Layer 3 multicast
protocols. At Layer 2, IGMP snooping allows switches to be IP multicast
aware. By snooping router and host query and report messages, the switch
can identify which interfaces are part of a multicast group, avoiding Layer
2 broadcast.
IGMP-enabled hosts send membership reports to routers to join or leave a
particular multicast group. Routers send queries to hosts. Data flows per
group, from source to receivers.
IGMP packets intercepted by an IGMP-aware switch can snoop the
contents of IGMP messages to determine which ports have a multicast
device somewhere in the connected path.
Router ports are learned using IGMP queries, and members are learned
using IGMP reports. A router port (or Mrouter port) is member of all
groups.

IGMP Snooping Solution
With IGMP Join G1 G1

Snooping L3
multicast
me mbership Query G1
Group 1 Data G1
messages are
snooped at L2.
IGMP SN
Multicast Group 2 Data G1,G2
forwarding tables Query G2
are built to deliver
traffic only to ports
with an attached G2
group me mber.
Join G2

IGMP Snooping Example

This following slide provides an example of the deployment of Layer 3 PIM
source-specific multicast (SSM) in tandem with Layer 2 IGMP snooping in
an edge network.
PIM SSM builds a shortest path tree (SPT) or source-based distribution
tree, rooted at the source. PIM SSM distributes (S, G) or both the source
IP and group IP channel for a particular group. PIM SSM-enabled routers
limit multicast replication to ports that are members of a particular (S, G)
channel.
Layer 2 devices operating IGMP snooping snoop the Layer 3 multicast
traffic to determine the location of interested members of a particular
group. Multicast traffic is replicated only to the interfaces that have
attached members of a particular (*, G) or (S, G) group.
Both of these solutions work to minimize multicast traffic bandwidth usage
and to prevent unnecessary broadcast.

IGMP Snooping Example
IGMP
PIM SSM in Snooping in
Layer 2 edge
Layer 3 Core Home
gatewa y
Streaming
Video Home
Channels gatewa y
Super
HeadEnd
IP
Metro
Backbone Aggregation
Network
VoD Servers Home
gatewa y
Video Headend
Home
gatewa y
IGMP Snooping determ ines subscriber requests for a given channel

Only ch annels requested by dow nstream DSLAMs are sent
Results in efficient use of the dow nstream UNI port, saving
bandw idth for other data & voice applications

Cisco ASR 9000 IGMP Snooping Implementation

On the Cisco ASR 9000, IGMP snooping is enabled per BD. BDs are used
for local multipoint bridging and virtual private LAN (VPLS) L2VPN
service deployments. IGMP snooping is enabled by attaching an IGMP
snooping profile to a particular bridge-domain (BD).
All BD port types are supported by IGMP snooping, including physical
interfaces, Ethernet flow point (EFP) interfaces, link aggregation bundles,
or multiprotocol label switching (MPLS) pseudowires (PWs). In the context
of IGMP snooping, all ports are abstracted such that they are treated the
same.
The following slide illustrates the two cases of IGMP snooping deployment
on the Cisco ASR 9000 router. With IGMP snooping enabled, multicast
traffic flowing across a BD flows only between ports that have an attached
multicast group member. IGMP snooping works on EFP, bundle, and PW
interfaces alike.

Module 17 Cisco ASR 9000 IGMP Snooping Implementation
Cisco ASR 9000 IGMP Snooping Implementation
Multipoint Ethernet bridge-domain
Receivers
EFP Bridge-domain
EFPs G1
IGMP snooping
G2
Multicast traffic
Multipoint VPLS
Source Multicast G2
router
IGMP MPLS IGMP
BD
PW or
VFI TE
IGMP snooping
EFPs

Control Plane Architecture

All multicast control packets received on ingress are punted to the active
route switch processor (RSP) card directly, bypassing the CPU on the line
card (LC) (useful for minimum disruption restart [MDR] of an LC).
Multicast control protocols such as IGMP snooping are centralized on the
RSP. The IGMP process communicates Layer 2 multicast state
information to the Layer 2 Forwarding Information Base (L2FIB). The
L2FIB is the central storage location of all multicast routes and outgoing
interface lists (OLISTs) for the entire shelf.
The L2FIB is distributed to all LCs in the shelf. Each LC maintains its
own version of the L2FIB. Some entries are filtered out if not local to the
LC. The L2FIB on the LC programs all hardware components, including
the fabric interface, bridge, and NPU with Layer 2 multicast state. The
LCs are then ready to efficiently replicate multicast traffic on the data
plane.

Control Plane Architecture
IGMP Snooping control centralized on RP:

1. IGMP control plane packets punted from the Layer 2
forwarding plane to the IGMP Snooping application on the RSP
2. The IGMP snooping process creates a L2FIB
3. L2FIB is distributed to LC CPU on all LCs
4. L2FIB is used to program HW structures in NPU, bridge and
switch fabric
LC1
NPU
IGMP B0
Switch Fabric
NPU
Interface
1
Fabric
NPU
B1 IGMP Snooping
NPU 2
3
4 L2FIB RP
L2FIB

Data Plane Forwarding Architecture

Upon ingress, a multicast packet lookup results in a fabric group ID
(FGID) and a multicast group ID (MGID) being translated into an internal
packet header, which is passed along with the packet to the switch fabric.
The switch fabric is the first stage of replication. The FGID is used to
determine to which LCs the packet should be replicated.
The LC CPU programs the fabric interface with a replication table based
on MFIB and L2FIB. This replication table is indexed by the 16-bit MGID.
The result of lookup is a 2-bit value indicating to the bridge chip to which
the packet should be forwarded.
Bridge FPGA replication is similar to fabric interface replication.
Egress NPU replicates the packet to the local output interfaces, which
could be any Layer 2, Layer 3 interface. Replication across bundle
interfaces is discussed later in this module.

Data Plane Forwarding Architecture
Switch fabric Fabric interface

1 2 Bridge FPGA
replication replication 3
replication
replicate to replicate to
LCs replicate to NPUs
bridge chips
LC2
NP3
Fabric Interface
B1
LC1 NP2
Multicast
NP3 2 4 NPU replication
B0
Fabric Interface
Source
NP2 1 NP1
IGMP joins replicate
B0 each copy
NP0
NP1
B1
3 per interface
4
Switch with a
NP0 LC3
Fabric receiver
NP3
Fabric Interface
B1
NP2
NP1
B0
NP0

Uniform Multicast Treatment Across Sources

Regardless of the location of the source or destination of a multicast
packet, all traffic passes through the switch fabric. There is no short path.
For example, with a source and receiver on the same LC, the packet still
passes first passes through the switch fabric.

Uniform Multicast Treatment Across Sources
LC2
NP3
Fabric Interface
2 B1
Multicast LC1 NP2
Source NP3 2
1
B0 IGMP joins
Fabric Interface
NP2 NP1
B0
3
IGMP joins 2 NP0
4
NP1
B13
Switch
NP0 LC3
4 Fabric
NP3
Fabric Interface
B1
NP2
Uniform egress multicast replication
independent of port location for both Layer NP1
B0
2 and Layer 3 multicast traffic NP0

Multicast over Link Bundles

Link bundles as source interface:
When a bundle interface is the source of the multicast traffic, the behavior
is the same as when a non-link bundle is the source of the interface. The
forwarding plane uses the logical link bundle interface (or link bundle
subinterface) as the incoming interface for any packet received on any of
the link bundle member ports.
Link bundles as outgoing interface:
When a link bundle is one of the outgoing interfaces of a multicast stream,
only one copy of the multicast traffic needs to be sent out of that bundle
interface. This implies that traffic should be sent only out of one of the
bundle member ports.
First Stage Hashing
RP MRIB performs a load-balancing hash and selects target egress
line cards.
Hashing is based on (S,G) or G and depends on the multicast
stream. Hash inputs could include a Layer 3 address.
Multicast packet is replicated only to a single egress line card.
Egress Line Card Replication
Member ports could be across multiple NPUs. To have faster
convergence during the member port switchover, multicast packets
are sent to all the NPUs that have member ports for a port-channel
interface, which improves the convergence time significantly.
Second Stage Hashing on the NPU
Each NPU executes an identical load-balancing hashing algorithm
and chooses the same member port. If that member is local to the
NPU, the packet is replicated and forwarded out. Otherwise, the
packet is dropped.

Multicast over Link Bundles
1 First stage hashing - Port-channel

replicate packet across LC2 with 4 member
LCs Physical links across LC
NP3 member and NPU
Fabric Interface
B1 port
LC1 2 NP2
Multicast NP3 2
Source B0
Fabric Interface
NP2 1 NP1 M1
M2
NP0 IGMP joins
NP1 3 M3
B1 4
Switch
NP0 LC3
Fabric
NP3 M4
Fabric Interface
B1
2 3 On Egress Line card - NP2
replicate packet to all NPUs
who have a member port NP1
B0
NP0
4 Second stage hashing on NPU-Each

NPU executes identical hashing, forward
packet out of the interface if its local,
otherwise, it drops the packet

Implementation
On the Cisco IOS XR CLI running on the Cisco ASR 9000 router, IGMP
snooping is enabled per BD, using profiles.
An empty BD profile attached to a BD is the minimum configuration
required to implement IGMP snooping. To disable snooping, simply
remove the profile with the no command.
More specific implementations can be created by attaching separate port-
level profiles.
Guidelines:
An empty profile configures IGMP snooping on the bridge
domain and all ports under the bridge using default
configuration settings.
A bridge domain can have only one IGMP snooping profile
attached to it (at the bridge domain level) at any time. Profiles
can be attached to ports under the bridge, one profile per port.
Port profiles are not in effect if the bridge domain does not have
a profile attached to it.
IGMP snooping must be enabled on the bridge domain for any
port-specific configurations to be in effect.
If a profile attached to a bridge domain contains port-specific
configuration options, the values apply to all of the ports under
the bridge, including all mrouter and host ports, unless another
port-specific profile is attached to a port.
When a profile is attached to a port, IGMP snooping
reconfigures that port, disregarding any port configurations that
may exist in the bridge-level profile.

Module 17 Implementation
Implementation
Hierarchical configuration:
Create a IGMP snooping profile
Attach the profile to a bridge-domain or to ports under a bridge-
domain
Profile usage:
Empty profile attached to a bridge-domain will enable IGMP
snooping on all attached ports. One profile per bridge-domain.
To disable, detach the profile.
Separate profiles can be attached to ports under the bridge-
domain to configure port-level features. One profile per port.
If a profile attached to a bridge-domain contains port-specific
configuration, this will supersede any port profile configuration,
unless a port-specific profile is added later.

BD and Port Profile Application

The following slide illustrates the application of BD and port-level profile
hierarchy.

BD and Port Profile Application
Bridge-domain profile
Port profile
Enables IGMP snooping with
attributes defined in profile to Port profile
bridge domain
Applies IGMP snooping port

attributes to all ports in bridge Host Mrouter
domain that do not have explicit port port
profile attachment. Bridge-domain
profile
Port profile
does not enable IGMP snooping in Bridge domain

bridge domain
Applies IGMP snooping port IGMP snooping

attributes to the target port
Host Host Host
IGMP snooping bridge domain port port port
attributes in this profile are
ignored

Mrouter and Host Ports

From an IGMP snooping perspective, ports on a BD are one of two possible
types. If a port has a reachable multicast router attached, it is considered
an Mrouter port. An Mrouter port can be dynamically discovered by
snooping IGMP queries and PIM hellos, or it can be statically configured as
part of a per-port IGMP profile. Ports with hosts attached are considered
host ports. All ports in a BD are considered host ports unless they are
statically or dynamically assigned as an Mrouter port.
An IGMP snooping switch should forward IGMP membership reports only
to those ports where multicast routers are attached. An IGMP snooping
switch should not forward IGMP membership reports to ports on which
only hosts are attached.

Mrouter and Host Ports
Mrouter port is a port to which a

multicast enabled router is
reached.
Mrouter ports can be statically IGMP PIM
configured or dynamically Query Hello
discovered.
Mrouter Mrouter
IGMP general queries and PIM port port
hellos received on an mrouter
port are forwarded to all ports.
IGMP reports received on a host
port will be snooped and may be
forwarded to all mrouter ports.
Bridge domain
IGMP snooping
Host Host Host
port port port


CLI configuration is hierarchical. First, an IGMP snooping profile(s) must
be created in global configuration mode. In this example, two profiles are
created with one containing Mrouter port configuration.
Next, apply the IGMP snooping profiles to the BD and to the member
ports.
When you detach a profile from a bridge domain or a port, the profile still
exists and is available for use at a later time. Detaching a profile has the
following results:
If you detach a profile from a bridge domain, IGMP snooping is
deactivated in the bridge domain.
If you detach a profile from a port, IGMP snooping configuration values
for the port are instantiated from the bridge domain profile

1. Create an IGMP snooping profiles

2. Attach it to a bridge or port l2vpn
1 Config
2
MP
bridge group
bridge-domain
IGMP snooping IGMP snooping profile
profile
1 Interfaces or VFI
router(config)# igmp snoop profile DEFAULT
router(config)# igmp snoop profile MROUTER

mrouter
router(config)# l2vpn
bridge group BG1
bridge-domain BD1 Identify the Mrouter port
2 igmp snooping profile DEFAULT
interface gigabitethernet0/0/1/1.1
igmp snooping profile MROUTER

Verify IGMP Snooping Profile Configuration

Use the show igmp snooping profile detail include-defaults
command to verify profile configuration including both user-set parameters
and system defaults.


Verify profile configuration, including defaults
:router# show igmp snooping profile detail include-defaults!
!
IGMP Snoop Profile PROFILE1:!
!
System IP Address: 0.0.0.0!
Minimum Version: 2!
Report Suppression: Enabled!
Unsolicited Report Interval: 1000 (milliseconds)!
TCN Query Solicit: Disabled!
TCN Membership Sync: ! Disabled!
TCN Flood! ! Enabled !
TCN Flood Query Count: 2!
Router Alert Check: Disabled!
TTL Check: Enabled!
!
Internal Querier Support: Disabled!
Internal Querier Version: 3!
Internal Querier Timeout: 0 (seconds)!
Internal Querier Interval: 60 (seconds)!
Internal Querier Max Response Time: 10 (seconds)!
Internal Querier TCN Query Interval: 10 (seconds)!
Internal Querier TCN Query Count: 2!
Internal Querier TCN Query MRT: 0!
Internal Querier Robustness: 2!
!
Querier Query Interval: 60 (seconds)!
Querier LMQ Interval: 1000 (milliseconds)!
Querier LMQ Count: 2!
Querier Robustness: 2!
!
Immediate Leave: Disabled!
Explicit Tracking: Disabled!
Static Mrouter: Disabled!
Router Guard: Disabled!
!
Bridge Domain References: 1!
Port References: 0!

IGMP Snooping Attributes-BD and Port

The following slide shows the BD-level and port-level IGMP snooping
attributes that can be set using the CLI.

IGMP Snooping Attributes-BD and Port
Bridge-level attributes Port-level attributes

querier immediate leave
internal querier router guard
system ip address static mrouter
minimum version static group
last member query
report suppression
router alert check
ttl check
tcn
unsolicited report interval

Querier, System IP Address, and Minimum Version

IGMP snooping requires a querier in BD to function:
May be an external querier.
May be an internal querier.
IGMP join packets are discarded until a querier is detected.

Internal querier does not start until a join is received.
The IGMP snooping system IP address is used in the following ways:
Internal querier sends queries from the system IP address. An address
other than the default 0.0.0.0 must be configured.
IGMPv3 sends proxy reports from the system IP address. The default
address 0.0.0.0 is preferred, but it may not be acceptable to some IGMP
routers.
In response to topology change notifications (TCNs) in the BD, IGMP
snooping sends global leaves from the system IP address. The default
address 0.0.0.0 is preferred, but it may not be acceptable to some IGMP
routers.
If the minimum version is set, this command causes IGMP snooping to
filter out all packets for IGMP versions earlier than the minimum-version.
When hosts want to leave a multicast group, they can either ignore the
periodic general IGMP queries (called a silent leave), or they can send a
group-specific leave message.
IGMP snooping can respond to group leaves in the following ways:
Last member query processingThis is the default method for

processing group leaves.
Immediate leaveYou can optionally configure individual ports for
immediate leave.

Querier, System IP Address, and Minimum Version
Proxy reporting
sent with System
Mrouter Mrouter IP address
port port
Bridge domain IGMP

minimum
version set to
IGMP snooping filter out
IGMPv2
Host Host Host
port port port
IGMP IGMPv2
Internal query
messages with
Query X report
sent with
System IP
address

Report Suppression and Proxy Reporting

The IGMP membership reports have to be captured from each host and
suppressed to other hosts to prevent the others from going into idle-
member state; every interested host has to be spoofed into thinking that it
is the only member of the group, so that it actively sends membership
reports. IGMP snooping then forwards one of these membership reports up
to the router (or makes up a fake membership report for itself).
Two techniques employed, depending on the version of the querier in the
BD:
For a v2 querier, IGMP snooping performs report-suppression in which
the first-join and last-leave report for a group are forwarded, and
reports from other hosts are suppressed. This is consistent with the
IGMPv2 host protocol (RFC 2236).
For a v3 querier, IGMP snooping performs proxy reporting, generating
reports only when state changes or in response to queriers queries.
This is consistent with the IGMPv3 protocol (RFC 3376), which
removes support for report-suppression
When a join is received for a new group, IGMP snooping creates group
state and forwards (first) join to all Mrouters.
When the last port leaves a group, the IGMP snooping deletes the group
state and forwards (last) leave to all Mrouters.
Other join and leave reports for the group are suppressed until the next
query is received.
Following receipt of G-Query, IGMP snooping forwards the first refreshing
join received from any host and suppresses the remainder.

Report Suppression and Proxy Reporting
General
Mrouter Query
Join
Port
1 IGMPSN
Report
Suppression
DB
Processing
Port Port Port
1 2 3
Host Host Host

IGMP Snooping Port Profile Attributes

The following slide displays the port-level profile attributes that can be
configured with the CLI.

IGMP Snooping Port Profile Attributes
Immediate Leave
Specifies that state learned on a port can be removed immediately on receipt
of a IGMPv2 leave report or equivalent IGMPv3 membership report. This
feature should only be configured on ports attached to a single host.
Static Group
Configures a static group or (included source-group) on the port.
Mrouter
Statically configures the port to which the profile is attached to be an
mrouter port.
Router Guard
Filters multicast protocol packets originated by routers. Disallows the port
to which the profile is attached from becoming mrouter port.

IGMP Snooping Summary CLI

The show igmp snooping summary command gives an outline of the
IGMP snooping configuration across the entire system.

IGMP Snooping Summary CLI
Router#show igmp snooping summary
Bridge Domains: 4
IGMP Snooping Bridge Domains: 2
Ports: 12
IGMP Snooping Ports: 10
Mrouters: 1
STP Forwarding Ports: 0
IGMP Groups: 2
Member Ports: 3
IGMP Source Groups: 0
Static/Include/Exclude: 0/0/0
Member Ports (Include/Exclude): 0/0

IGMP Snooping Group State

Group state as provided to the forwarding plane and upstream mcast
routers.
Optional CLI keywords exist to filter on BD, port, group, source, and to
provide detail and debug info.


:router# show igmp snooping group
Key: GM=Group Filter Mode, PM=Port Filter Mode

Flags Key: S=Static, D=Dynamic, E=Explicit Tracking
Bridge Domain BG1:BD1
Group Ver GM Source PM Port Exp Flg

----- --- -- ------ -- ---- --- ---
238.1.1.1 V2 - - - Gi0/1/0/0.1 never S
238.1.1.2 V3 IN 10.1.1.1 IN Gi0/1/0/0.1 119 D
238.1.1.2 V3 IN 10.1.1.1 IN Gi0/1/0/0.2 119 D
[output omitted]
Group state as provided to the forwarding plane and upstream mcast

routers
Optional CLI keywords to filter on bd, port, group, source, and to
provide detail and debug info

Verify IGMP Snooping is Active in BD

IGMP snooping is active in a BD if a profile is configured and is attached to
that BD.
Snooping is active in BG1:BD1 and BG1:BD2, because the profile is
applied.
Snooping is inactive in BG1:BD4, because no profile is applied.
Snooping is not active in BG1:BD3:
A non-existent profile can be attached to L2VPN BD

Shows as unconfigured
Creating profile activates IGMP snooping in BD

Verify IGMP Snooping is Active in the BD

Verify IGMP Snooping is Active in BD
:router# show igmp snooping bridge-domain
Bridge Domain Profile Act Ver #Ports #Mrtrs #Grps #SGs

------------- ------- --- --- ------ ------ ----- ----
BG1:BD1 PROFILE1 Y -- 8 1 1 0
BG1:BD2 PROFILE4 Y -- 2 0 1 0
BG1:BD3 PROFILE5 N -- 1 0 0 0
BG1:BD4 N -- 1 0 0 0
:router# show igmp snooping profile
Profile Bridge Domain Port

------- ------------- ----
PROFILE1 1 0
PROFILE2 0 1
PROFILE3 0 1
PROFILE4 1 0
PROFILE5 (unconf) 1 0

Profile Modifications
Modifications to profile are not propagated to referenced BDs or bridge
ports.
Profile must be detached and reattached.
Use the no igmp snooping command to remove a BD profile.
An alternate procedure is to create a new profile incorporating the desired
changes and attach it to the bridges or ports, replacing the existing profile.
This deactivates IGMP snooping and then reactivates it with parameters
from the new profile.

:router(config)# l2vpn bridge group BG1 bridge-domain BD1

:router(config-l2vpn-bg-bd)# no igmp snooping
:router(config-l2vpn-bg-bd)# commit
Make changes to the IGMP Snooping Profile, then reapply

to the Bridge-domain
:router(config-l2vpn-bg-bd)# igmp snooping profile PROFILE1

:router(config-l2vpn-bg-bd)# commit
:router(config-l2vpn-bg-bd)# end
To modify a profile, remove from BD, modify, then reapply to BD

IGMP Snooping Statistics

IGMP snooping statistics can be shown as scoped to the context of BD:
show igmp snooping bridge-domain detail statistics
IGMP snooping statistics can be shown scoped to the context of port.
show igmp snooping port detail statistics


:router# show igmp snooping summary statistics
[topology information omitted]
Traffic Statistics (elapsed time since last cleared 00:00:49):
Received Reinjected Generated
Messages: 1001 500 3
IGMP General Queries: 1 0 0
IGMP Group Specific Queries: 0 0 0
IGMP G&S Specific Queries: 0 0 0
IGMP V2 Reports: 0 0 0
IGMP V3 Reports: 1000 500 3
IGMP V2 Leaves: 0 0 0
IGMP Global Leaves: 0 - 0
PIM Hellos: 0 0 -
Rx Packet Treatment:
Packets Flooded: 500
Packets Forwarded To Members: 0
Packets Forwarded To Mrouters: 0
Packets Consumed: 501
Rx Errors:
V3 Reports DA Not All V3 Routers: 500
V3 Reports Older Version Querier: 1
Tx Errors:
None

Summary
ASR 9000 Layer 2 Multicast
Describe the fundamentals of Layer 2 multicast

Describe Cisco ASR 9000 Layer 2 multicast control plane
Describe Cisco ASR 9000 Layer 2 multicast data plane
Configure Layer 2 multicast parameters
Describe Layer 2 multicast deployment considerations

Module 18
ASR 9000 Quality of Service
Overview
Description
This module describes Cisco ASR 9000s Quality of Service (QoS)
architecture and its software and hardware implementation. It provides
an example of a QoS implementation on E-Line and E-LAN services. A.
brief description of modular QoS CLI (MQC) implementation steps is
given.
Objectives
After completing this module, you will be able to do the following:
Describe the data flow from ingress LC to egress LC across the
backplane and switch fabric
Describe the implementation of modular QoS including classification,
policing, marking, queuing, shaping and scheduling components
Implement QoS on L2VPN services using IOS XR MQC

ASR 9000 Quality of Service Module 18
Quality of Service Overview

QoS refers to the ability of a network to provide better service to selected
network traffic. In particular, QoS features provide better and more
predictable network service by:
Supporting dedicated bandwidth
Improving loss characteristics
Avoiding and managing network congestion

Shaping network traffic
Setting traffic priorities across the network
Depending upon customer traffic requirements, certain end-to-end network
characteristics must be employed to meet Service Level Agreements (SLAs)
How to divvy up a given set of bandwidth between customers is a function
of QoS.
Per user/subscriber level QOS plays a vital role in the edge/aggregation
networks so that service providers can sell oversubscribed services to their
customers.

Module 18 Quality of Service Overview

Service level agreement (SLA)
SLAs are defined between UNIs

Availability of bandwidth
Probability of packet loss
End-to-end delay and jitter
Cisco ASR 9000 QoS is based on Cisco modular QoS CLI (MQC).
QoS components include classification, policing, marking,
queuing, and scheduling.

Cisco ASR 9000 QoS Features

QoS on the Cisco ASR 9000 is implemented in hardware within the LC
NPU and it is very scalable with respect to SLA enforcement. There are 3
million queues and 2 million policers supported per chassis.
Classification and scheduling are supported on ingress and egress. Four
layers of classification granularity are supported
QoS is supported on Layer 2, Layer 3 or MPLS implementations.
The Cisco ASR 9000 architecture provides consistent backpressure across
the system to support flow control. Dedicated, hardware-based traffic
managers (TMs) are used.
Calculation of Queues per Chassis
Four NPUs per LC, each NPU has at least one Traffic Manager
32k queues per Traffic Manager
Two TMs used on egress NPU, 1 TM used on ingress NPU
Four NPU x 32k Queues per NPU x two TMs = 256k Queues on
Egress per LC
Four NPU x 32k Queues per NPU x one TM = 128k Queues on
Ingress per LC
256k +128k = 384k Queues per LC total (ingress + egress)
384k Queues per LC x 10 slots => 3M Queues per chassis


Scalable SLA enforcement

Up to 3 Million queues per system
Up to 2 Million policers per system
Four layer scheduling hierarchy support on
ingress and egress
For example: Port, Subscriber Group, Subscriber, Class
Flexible use cases

L2/Ethernet, L3/IPv4/6, MPLS
Robust implementation
QOS, backpressure available throughout the
system packet path
H-QOS uses dedicated and purpose-built traffic
manager HW

Scalable, Four-Level Hierarchy

This diagram provides an overview of ingress and egress QoS application
at the LC level. Features are available on ingress and egress. Numbers
here are quoted per the extended version of the LC.
Most use cases are going to be related to EVC deployments. Point-to-point
or multipoint Layer 2 subinterface EFPs are the attachment point for QoS
policies and QoS enforcement.
From a marketing perspective, there are four levels in the scheduling
hierarchy. The first level, port-level, is not directly controlled through the
class-map. It is a static setting for the line-rate throughput for a particular
port. The remaining hierarchy is grandparent, parent and child in
implementation. This allows you to apply QoS hierarchy to customer,
service and traffic types. One policy can apply to the traffic type, one
policy can apply to the service type and one policy can apply to an entire
port simultaneously.
The Cisco ASR 9000 has two high-priority queues (P1 and P2, P1 has
priority over P2) which are supported at the system level.
Access Node Control Protocol (ANCP) creates a control plane between a
service-oriented aggregation device and an access node (AN) (for example,
a DSLAM) in order to perform QoS-related, service-related, and subscriber-
related operations. An ANCP Network Access Server (NAS) accepts and
maintains ANCP adjacencies (sessions with an ANCP neighbor), and
sending and receiving ANCP messages.
ANCP allows static mapping between AN ports and VLAN subinterfaces so
that DSL rate updates for a specific subscriber received by the ANCP
server are applied to the QoS configuration corresponding to that
subscriber. DSL train rates received via ANCP are used to alter shaping
rates on subscriber-facing interfaces and subinterfaces. on the Cisco ASR
9000.

Scalable, Four-Level Hierarchy
Port Subscriber Subscriber Class

Level group Level Level Level Up to 384k queues per
linecard (ingress+egress)
EVC1
PQ1 VoIP Bearer + Control
Business Critical
Up to 16k EVCs with H-
BW
QOS per linecard
Customer - egress
BW Internet Best Effort
Up to 256k 2R3C policers,
hierarchical policing
Ingress and egress H-QOS
EVC 2
PQ1 VoIP Bearer + Control
PQ2 Telepresence
with hierarchical shaping
Port BW Internet Best Effort Dual Priority scheduling
with priority propagation
for minimum latency and
EVC1 jitter
VoIP Bearer + Control PQ1
Business Critical BW Customer - ingress Flexible & granular
Internet Best Effort BW classification: Full Layer 2,
Full Layer 3/4 IPv4, IPv6
(even for L2 services)
ANCP driven shapers for
EVC 2
VoIP Bearer + Control PQ1

Telepresence
accurate per subscriber
PQ2
SLA enforcement
Internet Best Effort BW
Class Subscriber Subscriber

Level Level group Level

Cisco ASR 9000 QoS MQC Model

This slide introduces the entire QoS model supported by the Cisco ASR
9000. This model is divided into two parts, actions on ingress and actions
on egress.
Actions on ingress (either ingress from customer or ingress from transport)
include initial classification, policing, and marking. Actions on egress
(either egress to the customer or egress to transport) include a second stage
of classification (post policing and marking) and queuing and scheduling.
Classification Identifies traffic
Policing and marking Provides or limits the bandwidth available to
traffic after it is classified
Classification (on egress) Reclassifies traffic that is policed, or marked,
or both
Queuing Determines what traffic types should receive what size queues
on egress
Scheduling Determines which traffic receives priority in times of
network congestion

Module 18 Cisco ASR 9000 QoS MQC Model
Cisco ASR 9000 QoS MQC Model

QoS MQC Model
Identify each Police or Identify each Enforce

packet flow mark packet packet flow bandwidth
on ingress flow at egress guarantees
Classification Classification
Policing, Policing,
marking, marking,
queuing and queuing and
scheduling scheduling
QoS actions at ingress QoS actions at egress


This slide reviews the order of packet operations from ingress to egress.
Note that ingress QoS shall be applied prior to ingress VLAN rewrites and
egress QoS will be applied after doing the egress VLAN rewrite. This order
of operations therefore takes action on the original classification critieria of
the ingress traffic, not on what the classification criteria is rewritten to by
the system.


Ingress Egress
interface Service mapping interface
(cross-connect, bridge,
and so on)
Tier 1 Tier 2 input Ingress Tier 1 Egress Tier 2 output
input features VLAN output EFP features
features re-writes matching rewrites Egress filter
Ingress QoS, 2
Ingress Ingress Egress Egress QoS,
interface filter 1 ACLs
ACLs
classify
Logical interface match, Switch Fabric Egress match, symmetric

QoS, ACLs, rewrite rewrite, QoS, ACLs
Note the order of operations when configuring QoS, ACLs in

combination with VLAN rewrites
For example, if the QoS policy is matching on VLAN and
VLAN re-write is configured


In terms of raw bandwidth, the ASR 9000 Ethernet LCs and RSPs can
support line-rate traffic flow for all LCs excluding the two oversubscribed
LCs. (the 40G, 8x10GE and the 80G, 16x10GE). The LC NPU and fabric
interface are QoS aware and policing, queuing, and scheduleding are
supported on each of these components.
The NPU-to-bridge interface is a clocked at ~15Gbps. Note that this is
significantly faster than the ~10gbps linerate provided by a single 10GE or
ten 1GE ports, but significantly LESS than the aggregate 20gbps offered
by the 2:1 oversubscribed linecard where two 10GE ports are shared by a
single NPU.
The bridge-to-fabric interface is a DDR memory interface, with a raw
throughput capacity of approximately 32Gbps. Note that this is faster
than the combined (15G * 2) load of two bridge chips. For this reason we
do not expect to see packet drops here.
The fabric interface-to-fabric is a set of serial links capable of carrying
~46Gbps. To be more precise, each octopus has a 23G connection to each
Fabric chip on each RSP. If we fully expand this number we see that there
are two Fabric chips per RSP, and (generally) two RSPs in a system. This
gives us a final fabric interface ->fabric bandwidth number of (23Gbps * 2 *
2 = 92Gbps).


CPU Fabric
PHY NPU0 ASIC
PHY NPU1
B0 Fabric
FI/0 0 ASIC
PHY NPU2
B1
Arbiter
PHY NPU3
RSP0
PHY NPU4
Fabric
ASIC
PHY NPU5 B2
FI/O 1 Fabric
PHY NPU6 B3 ASIC
PHY NPU7
RSP1
30 Gbps and 25M pps 15 Gbps bi- 30 Gbps bi-

(combined ingress and directional directional Each FIA has one fabric channel
which is 23 Gbps bi-directional,
egress) 30 Gbps bi- 60 Gbps bi-
directional to each of the switch fabric
directional
2011, Cisco Systems, Inc. All rights reserved. Version 4.0.1 ASICs Cisco ASR 9000 EssentialsModule 18/18

Set System QoS Policy on Ingress EFP

This slide illustrates how backpressure is used during times of traffic
congestion. On the Cisco ASR 9000, QoS policy is set on the ingress EFP.
This means that traffic ingress to a system should have its QoS attributes
set as it enters. Once a packet stream is classified and or marked on
ingress, the system can respond to these packet markings.
For example, if traffic is marked as High Priority by a QoS policy on
ingress, the ingress NPU and all subsequent FPGAs and Fabric chips will
identify the traffic as High Priority and will place the traffic in a High
Priority queue.
For Unicast traffic, Backpressure can be propagated from the egress NPU
back to the ingress LC Fabric I/O (from right to left on the diagram) which
prevents head-of line blocking. The Bridge FPGA and Fabric interface are
all QoS aware and they each provide two high priority Queues in addition
to the best effort queues.
Multicast has its own high-priority/low-priorityFor Multicast traffic,
Backpressure is propagated from the egress NPU to the egress LC Fabric
I/O.

Set System QoS Policy on Ingress EFP
QoS optimized fabric architecture:

Virtual Output Queueing (VoQ)
Priority aware scheduling & arbitration
Superframing for efficiency
Memory Memory
NPU Bridge Arbiter NPU

Bridge
FPGA 0 FPGA 0
Fabric IO Fabric IO
Fabric
HP(P1& P2) P1 P1 HP(P1& P2)
LP P2 LP
P2
LP LP
Ingress H-QOS Egress H-QOS
Ingress NPU performs QoS classification and/or marking of packet fields with
set command
Egress NPU performs egress classification, queuing and scheduling based on
ingress marking.

Priority Queuing and Consistent Backpressure

This slide illustrates how the system responds to Flow Control Pause
frames. If a Pause frame is received on the egress NPU, backpressure
is cascaded consistently across every chip in the data path. When used
in conjunction with Priority Queuing, consistent backpressure will be
applied while simultaneously providing low-latency queuing (LLQ) to
the high priority traffic.


Consistent QoS Backpressure and Flow Control available

throughout the system packet path
NPU NPU
Bridge Arbiter Bridge

FPGA 0 Fabric FPGA 0
Fabric NPU
I/O I/O
NPU
Bridge Fabric Bridge

FPGA 1 FPGA 1
HP HP HP HP HP
LP LP LP LP LP
Priority propagation ensures consistent, predictable, low-latency queue
performance
High priority and low priority awareness on Bridge and Fabric I/O chips

QoS Techniques and MQC

To provide end-to-end QoS, the following techniques are used:
Packet classification and marking
Congestion management
Congestion avoidance
Not all QoS techniques are appropriate for your network environment.
The Cisco ASR 9000 MQC CLI is used to:
Classify traffic with class-maps
Create traffic policies for particular class-maps
Attach policies to interfaces

QoS Techniques and MQC CLI
1. Create class-
1 Classify Attach a policy
maps class-map 3 tointerface
an (sub)
2. Create policy- specify match interface
maps criteria
3. Apply a policy- 2 Create Policy specify a service-policy
map to
interface or policy-map specify input or
subinterface. output
specify a class
specify actions

QoS CLI Configuration

This slide illustrates basic QoS configuration on a particular service
(specifically on the EFPs of the service endpoints) using the CLI.
First, class-maps and policy-maps are configured in global
configuration mode.
Second, the configured policies are applied to interfaces on either the
ingress or egress direction.

QoS CLI Configuration
EVC
AC AC
3 Switch 3
Ingress LC fabric Egress LC
EFP1 EFP2
int g0/1/0/0.10 int g0/2/0/2.10
service-policy input < > service-policy output < >
Global configuration
# class-map < >
match < >
1
# policy-map < >
class < >
priority-level < >
police < >
2 class < >

bandwidth < >

Supported Classification Criteria

How do you control the mapping of packets to different system queues?
Assign packets to a class on ingress. Packet classification partitions an
aggregate traffic flow and marking identifies traffic flows that require
congestion management or congestion avoidance on a data path. Different
packet markings can later be given different priority treatment.
Identification of a traffic flow can be performed by using several methods
within a single router, such as access control lists (ACLs), protocol match,
IP precedence, IP differentiated service code point (DSCP), MPLS EXP bit,
or Class of Service (CoS).
Marking of a traffic flow is performed by
Setting IP Precedence or DSCP bits in the IP Type of Service (ToS)
byte.
Setting CoS bits in the Layer 2 headers.
Setting EXP bits within the imposed or the topmost Multiprotocol
Label Switching (MPLS) label.
Setting qos-group and discard-class bits.

Marking can be carried out:
UnconditionallyAs part of the class-action.

ConditionallyAs part of a policer-action.
Combination of conditionally and unconditionally.
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 first in, first out (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.

Supported Classification Criteria
Flexible Layer 2 or Layer 3 field classification on Layer 2 interfaces:

Inner/outer cos VLAN IP Packet
CoS DSCP
Inner/Outer vlan
Outer EXP
Dscp/Tos CoS DSCP
VLAN VLAN IP Packet
TTL, TCP flags, source/destination L4 ports CoS CoS DSCP
Protocol
Source/Destination IP
cos-inner
Source/Destination MAC address
cos DSCP
Discard-class MPLS VLAN IP Packet
Exp CoS DSCP
Qos-group
match all
match mac-addr cos-inner
exp DSCP
On Layer 3 interfaces most of the above are supported other than MAC address,
VLAN, etc. (Layer 2 encapsulation, inner/outer COS is supported).

Shared Policy Instances

After the traffic class and traffic policy have been created, Shared Policy
Instance (SPI) can optionally be used to allow allocation of a single set of
QoS resources and share them across a group of subinterfaces, multiple
Ethernet flow points (EFPs), or bundle interfaces.
Using SPI, a single instance of qos policy can be shared across multiple
subinterfaces, allowing for aggregate shaping of the subinterfaces to one
rate. All of the subinterfaces that share the instance of a QoS policy must
belong to the same physical interface. The number of subinterfaces sharing
the QoS policy instance can range from 2 to the maximum number of
subinterfaces on the port.
For bundle interfaces, hardware resources are replicated per bundle
member. All subinterfaces that use a common shared policy instance and
are configured on a Link Aggregation Control Protocol (LAG) bundle must
be load-balanced to the same member link.
When a policy is configured on a bundle EFP, one instance of the policy is
configured on each of the bundle member links. When using SPI across
multiple bundle EFPs of the same bundle, one shared instance of the policy
is configured on each of the bundle member links. By default, the bundle
load balancing algorithm uses hashing to distribute the traffic (that needs
to be sent out of the bundle EFPs) among its bundle members. The traffic
for single or multiple EFPs can get distributed among multiple bundle
members. If multiple EFPs have traffic that needs to be shaped or policed
together usingSPI, the bundle load balancing has to be configured to select
the same bundle member (hash-select) for traffic to all the EFPs that
belong the same shared instance of the policy. This ensures that traffic
going out on all the EFPs with same shared instance of the policy use the
same policer/shaper Instance.
This is normally used when the same subscriber has many EFPs, for
example, one EFP for each service type, and the provider requires shaping
and queuing to be implemented together for all the subscriber EFPs.
Policy Inheritance:
When a policy map is applied on a physical port, the policy is enforced for all Layer 2
and Layer 3 subinterfaces under that physical port.

Shared Policy Instances
Shared Policy Instance
Port
Apply a shared policy among two EFPs on the same port with parent
shape/bandwidth/BRR and child class based queuing.
Same service-policy applied to all member EFPs.
All traffic from all policy instance members are subject to this
common policy instance.
Requires a new key-word to the service-policy comand:
service-policy output/input <name> shared-policy-instance <name>
Are supported over LAG only for L2 Traffic

Layer 2 VPN Quality of Service Example

This section illustrates the application of QoS to EoMPLS and VPLS
services. We are going to analyze an example of QoS applied to the ingress
interfaces of this network. EoMPLS and VPLS EFPs use the same
physical interface.
This example explores a three-level queuing and shaping configuration
with a shared policy instance (SPI) on the UNI port.
Both Layer 2 services on the UNI will have three defined (two high priority
queues and one bandwidth queue) traffic classes and a default class.
Both the EoMPLS and VPLS services belong to the same Layer 2 service
group. The two services will be shaped as a group on ingress.

Module 18 Layer 2 VPN Quality of Service Example
Layer 2 VPN Quality of Service Example
PE1
EFP #1 for EoMPLS
PE2
EFP #2 for VPLS
EoMPLS E-Line
PE1 PE3
VPLS E-LAN
PE2
PE4

L2VPN QoS Example - Hierarchy

Three levels of hierarchy including class-level (child or Level 1), subscriber-
level (parent or Level 2) and subscriber-group level (grandparent or Level
3) are shown as an example. The fourth level, port-level, is implied-as
other subscriber groups would share this link.
Each Layer 2 service has three traffic classes defined. Each service is
considered a subscriber and the two subscribers form a subscriber-group.
Any traffic that does not get classified into one of the three queues listed
above will fall into the default class and will be given best-effort treatment.
Three levels of queuing are implemented using two priority queues and one
bandwidth queue to match the three traffic classes. Each service is shaped
at the subscriber level and both services are together shaped at the
subscriber group level. This is an example of Shared Policy Instance, a
policy map is shared by multiple services.
Use the show policy-map interface gigabitEthernet0/X/X/X command
to display the statistical effects of a policy map when it is applied to an
interface.

L2VPN QoS Example - Hierarchy
Port Subscriber group- Subscriber-level

Level level shaper shaper (200Mbps
(350Mbps per group per subscriber) EFP#1 EoMPLS
Subscriber Subscriber Class Class-level queues
group Level Level Level
EFP#1 - EoMPLS
Cos5 P1 50Mbps
Cos3 P2 50Mbps
Customer - ingress
Cos1 BW 50Mbps
Best Effort EFP#2 VPLS
Port Class-level queues
EFP# 2 - VPLS
Cos5 P1 50Mbps
Cos3 P2 50Mbps
Cos1 BW 50Mbps
Best Effort

L2VPN QoS Example Class Level

The first step is to configure the child-level policy map. Three classes are
created which each match on a different Class of Service (CoS) bit value.
A policy map creates three user-defined queues; two high-priority queues
and one bandwidth queue, in addition to a default traffic queue.
The Priority level 1 queue is policed to 50Mb (shaping is not supported in
order to provide low-latency) and the Priority level 2 queue is shaped to
50Mb (P2 could have either a policer or a shaper). The Bandwidth queue is
assigned 50Mb.
A default class is created to catch all other traffic. The default traffic class
has no user-defined bandwidth so there is no bandwidth guarantee
involved.

L2VPN QoS Example Class-Level
EFP#1 - EoMPLS
Child-level P1 50Mbps Class Map:
queues P2 50Mbps Child-level class-map and
Best Effort 50Mbps policy-map to be shared by
both EoMPLS and VPLS
EFPs
class-map match-any GROUPG-C1 Each class will get 50Mbps

match cos 1 of bandwidth
!
class-map match-any GROUPG-C3
match cos 3
!
class-map match-any GROUPG-C5 Policy Map:
match cos 5
!
Cos 5 will go into P1
! and will use a policer
policy-map CHILD_LEVEL to rate limit
class GROUPG-C5
priority level 1
police rate 50 mbps ! P1 class is policed, P1 class doesnt support shaper to avoid high latency
!
! Cos 3 will go into P2 and can use either a
class GROUPG-C3 policer or a shaper to rate-limit
priority level 2
shape average 50 mbps ! P2 class can have either policer or shaper configuration
!
class GROUPG-C1
bandwidth 50 mbps
Remaining unclassified traffic will fall into
! the best-effort class (class-default) which is
class class-default policed at the parent level.

L2VPN QoS Example Subscriber Level

A Parent-level policy map is applied to each service based upon VLAN
tags. Class maps match on the outer VLAN tag used by each service.
A policy map is created at the subscriber-level that applies to both the
subscriber-level and class-level. A 200Mb shaper is applied to each service
and the VPLS service is given twice the weight as the EoMPLS service in
terms of the bandwidth remaining ratio.
Remaining unclassified traffic will fall into the best-effort class (class-
default) which is policed at the parent level.

L2VPN QoS Example Subscriber-Level
Parent-level
EFP# 2 - VPLS
Cos5 P1 50Mbps Class Map:
policer P2 50Mbps Parent-level class-map and
Cos3
Cos1 BW 50Mbps policy-map applied to
Best Effort child-level classes
Match on VLAN ID
class-map match-all PARENT-VPLS

match vlan 32
! Shape EoMPLS to
class-map match-all PARENT-EoMPLS 200Mbps and assign a
match vlan 22 lower bandwidth
!
!
remaining ratio of 100
policy-map PARENT_LEVEL_SHAPER
class PARENT-EoMPLS
service-policy CHILD_LEVEL Shape VPLS to
shape average 200 mbps 200Mbps and assign a
bandwidth remaining ratio 100 higher bandwidth
!
class PARENT-VPLS
remaining ratio of 200
service-policy CHILD_LEVEL
shape average 200 mbps
bandwidth remaining ratio 200
!
class class-default

L2VPN QoS Example Subscriber-Group Level

A policy map is created at the subscriber-group-level that shapes both
underlying services (EoMPLS and VPLS) to 350Mb total.

L2VPN QoS Example Subscriber-Group Level
Grandparent- Cos5
level policer Cos3
Cos1
Cos5
Parent-level class-
Cos3 map and policy-map
Cos1 applied class-default
policy-map GRANDPARENT_SHAPER
service-policy PARENT_LEVEL_SHAPER
shape average 350 mbps Shape both EoMPLS
bandwidth remaining ratio 200 and VPLS traffic to
!
class class-default 350Mbps total
! Assign a bandwidth
Interface gigabitEthernet 0/2/0 remaining ratio of 200.
(config)

L2VPN QoS Example Application of QoS to the UNI

The service-policy is applied at the UNI to the EoMPLS EFP and to the
VPLS EFP. Note that even though these two EFPs share the same policy-
map name the system will create two individual sets of queues in
hardware.

L2VPN QoS Example Application of QoS to the UNI
Grandparent- Cos5
level policer Cos3
Cos1
Cos5
Apply the final QoS
Cos3 policy statement to
Cos1 two different EFPs.
The result is a shared

policy instance.
policy-map GRANDPARENT_SHAPER
service-policy PARENT_LEVEL_SHAPER
shape average 350 mbps
bandwidth remaining ratio 200
!
class class-default
!
interface gigabitEthernet 0/2/0/15.1 l2transport
service-policy input GRANDPARENT_SHAPER service-policy-instance CUSTOMER_A
interface gigabitEthernet 0/2/0/15.2 l2transport

service-policy input GRANDPARENT_SHAPER service-policy-instance CUSTOMER_A

QoS show Commands

The following slide lists useful QoS show commands that can be used to
verify QoS configuration and implementation.

QoS show Commands
Use the following commands to verify QoS configuration:

show run policy-map
show run class-map
show run policy-map interface
show run interface qos
show policy-map interface

Displaying a Policy Map

Use the show policy-map interface gigabitEthernet0/X/X/X command
to display the statistical effects of a policy map when it is applied to an
interface.
In-Place Policy Modification
The In-Place Policy Modification feature allows you to modify a QoS policy
even when the QoS policy is attached to one or more interfaces. When you
modify the QoS policy attached to one or more interfaces, the QoS policy is
automatically modified on all the interfaces to which the QoS policy is
attached. A modified policy is subject to the same checks that a new policy
is subject to when it is bound to an interface.
If the policy-modification is successful, the modified policy takes effect on
all the interfaces to which the policy is attached. The configuration session
is blocked until the policy modification is complete.
However, if the policy modification fails on any one of the interfaces, an
automatic rollback is initiated to ensure that the pre-modification policy is
in effect on all the interfaces. The configuration session is blocked until the
rollback is complete on all affected interfaces.
Additional QoS reference:
http://www.cisco.com/en/US/docs/routers/asr9000/software/asr9k_r4.0/qos/c
onfiguration/guide/qc40asr9kbook.html

Displaying a Policy Map
router# show policy-map int gigabitEthernet0/2/0/38.7

gigabitEthernet0/2/0/38.7 output: traffic-class
Class routine
Classification statistics (packets/bytes) (rate -)
Matched : 0/0 0
Transmitted : 0/0 0
Total Dropped : 0/0 0
Queueing statistics
Vital (packets) : 0
Queueing statistics
Queue ID : 42
High watermark (packets) : 0
Inst-queue-len (bytes) : 0
Avg-queue-len (bytes) : 0
TailDrop Threshold(bytes) : 59904000
Taildropped(packets/bytes) : 0/0
Class variety
Classification statistics (packets/bytes) (rate -)
Matched : 72/9068 0
Transmitted : 72/9068 0
Total Dropped : 0/0 0
Queueing statistics
Vital (packets) : 0
Queueing statistics
Queue ID : 14
High watermark (packets) : 0
Inst-queue-len (bytes) : 0
Avg-queue-len (bytes) : 0
TailDrop Threshold(bytes) : 2995200
Taildropped(packets/bytes): 0/0
--More--

Summary
ASR 9000 Quality of Service
Describe the data flow from ingress LC to egress LC across the
backplane and switch fabric
Describe the implementation of modular QoS including classification,
policing, marking, queuing, shaping and scheduling components
Implement QoS on L2VPN services using IOS XR MQC

Part Number: ASR9KE

Cisco ASR 9000 Aggregation Services Router Series Student Guide v4.0.1

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Cisco ASR 9000 Aggregation Services Router Series Student Guide v4.0.1

Transféré par

Droits d'auteur :

Formats disponibles

ASR9KE

Cisco ASR 9000

Text Part Number: ASR9KE

Printed in the USA

2011 Cisco Systems, Inc. Version 4.0.1 v

Comprehensive network support is available from Cisco Systems

vi Version 4.0.1 Cisco ASR 9000 Series Essentials

2011 Cisco Systems, Inc. Version 4.0.1 vii

viii Version 4.0.1 Cisco ASR 9000 Series Essentials

2011 Cisco Systems, Inc. Version 4.0.1 ix

Configure Ethernet Link Bundles

Describe Multiple Spanning Tree-Access Gateway (MST-AG)

x Version 4.0.1 Cisco ASR 9000 Series Essentials

Course Introduction and Objectives ................................................................ ix!

Module 1 ........................................................................................................... 11!

Module 2 ........................................................................................................... 21!

Module 3 ........................................................................................................... 31!

2011 Cisco Systems, Inc. Version 4.0.1 xi

Module 4 ........................................................................................................... 41!

Module 5 ........................................................................................................... 51!

Module 6 ........................................................................................................... 61!

Module 7 ........................................................................................................... 71!

xii Version 4.0.1 Cisco ASR 9000 Series Essentials

Module 8 ........................................................................................................... 81!

Module 9 ........................................................................................................... 91!

Module 10 ....................................................................................................... 101!

Module 11 ....................................................................................................... 111!

2011 Cisco Systems, Inc. Version 4.0.1 xiii

Module 12 ....................................................................................................... 121!

Module 13 ....................................................................................................... 131!

Module 14 ....................................................................................................... 141!

xiv Version 4.0.1 Cisco ASR 9000 Series Essentials

Module 15 ....................................................................................................... 151!

Module 16 ....................................................................................................... 161!

Module 17 ....................................................................................................... 171!

Module 18 ....................................................................................................... 181!

2011 Cisco Systems, Inc. Version 4.0.1 xv

xvi Version 4.0.1 Cisco ASR 9000 Series Essentials

Locate user documentation and support information

2011 Cisco Systems, Inc. Version 4.0.1 11

What is the Cisco ASR 9000?

12 Version 4.0.1 Cisco ASR 9000 Essentials

What is the Cisco ASR 9000?

It is a Carrier-class Ethernet Access and Aggregation

2011 Cisco Systems, Inc. Version 4.0.1 13

Cisco ASR 9000 Highlights

14 Version 4.0.1 Cisco ASR 9000 Essentials

Cisco ASR 9000 Highlights

Cisco ASR 9000 Highlights

Ten-slot and six-slot chassis

2011 Cisco Systems, Inc. Version 4.0.1 15

16 Version 4.0.1 Cisco ASR 9000 Essentials

RSP cards provide a non-blocking

2011 Cisco Systems, Inc. Version 4.0.1 17

LCsGE and 10GE

40-port GE, line rate

Two-port 10 GE + 20-port GE, line rate

16-port 10GE card (oversubscribed)

18 Version 4.0.1 Cisco ASR 9000 Essentials

LCsGE and 10GE

There are two categories of Ethernet

2011 Cisco Systems, Inc. Version 4.0.1 19

LCsShared Interface Processor

Two OC-12 interfaces per SPA