Documente Academic
Documente Profesional
Documente Cultură
Instructor Guide
Text Part Number: xx-xxxx-xx
Copyright " 2006, Cisco Systems, Inc. All rights reserved. CCIP, the Cisco Powered Network mark, the
Cisco Systems Verified logo, Cisco Unity, Follow Me Browsing, FormShare, Internet Quotient, iQ
Breakthrough, iQ Expertise, iQ FastTrack, the iQ logo, iQ Net Readiness Scorecard, Networking Academy,
ScriptShare, SMARTnet, TransPath, and Voice LAN are trademarks of Cisco Systems, Inc.; Changing the Way We
Work, Live, Play, and Learn, Discover All Thats Possible, The Fastest Way to Increase Your Internet Quotient, and
iQuick Study are service marks of Cisco Systems, Inc.; and Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE,
CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, the Cisco IOS logo, Cisco Press,
Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Empowering the Internet Generation,
Enterprise/Solver, EtherChannel, EtherSwitch, Fast Step, GigaStack, IOS, IP/TV, LightStream, MGX, MICA, the
Networkers logo, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, RateMUX, Registrar, SlideCast,
StrataView Plus, Stratm, SwitchProbe, TeleRouter, and VCO are registered trademarks of Cisco Systems, Inc. and/or
its affiliates in the U.S. and certain other countries.
All other trademarks mentioned in this document or Web site are the property of their respective owners. The use of
the word partner does not imply a partnership relationship between Cisco and any other company. (0203R)
Printed in the USA
Course Overview
Intended Audience
This course is for technical professionals who design, implement, and
operate MPLS and other tunnel technologies in a service provider
network employing routers using Cisco IOS XR Software. The primary
audience for this course is:
Support engineers
Course Level
This course provides an advanced level of information pertaining to
the platforms currently supporting Cisco IOS XR Software.
Prerequisites
For a student to successfully complete this course, they must meet
these minimum recommended prerequisites:
Version 4.0.1
Additional Information
Cisco Systems Technical Publications
You can print technical manuals and release notes directly from the
Internet. Go to
http://www.cisco.com/en/US/products/ps5845/tsd_products_suppor
t_series_home.html.
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
vi
Version 4.0.1
Course Agenda
Day 1
Course and Student Introduction
Module 1 MPLS Technology Introduction
Lab 1 Lab Familiarization and Initial Configuration
Module 2 MPLS Operations, Administration, and Management (OAM)
Module 3 MPLS Label Distribution Protocol (LDP) (Part 1)
Lab 2 MPLS LDP Implementation with OSPF
Day 2
Module 3 MPLS Label Distribution Protocol (LDP) (Part 2)
Lab 2 MPLS LDP Implementation with IS-IS
Module 4 Layer 3 Virtual Private Networks (L3VPN)
Lab 3 L3VPN (Intranet)
Module 4 Layer 3 Virtual Private Networks (L3VPN) (Cont.)
Lab 3 L3VPN (Extranet)
Day 3
Module 5 Inter-AS L3VPNs
Lab 4 Inter-AS L3VPNs
Module 6 MPLS Traffic Engineering (MPLS-TE) (Part 1)
Lab 5 MPLS-TE (Parts 1 and 2)
Day 4
Module 6 MPLS Traffic Engineering (MPLS-TE) (Part 2)
Lab 5 MPLS-TE (Parts 3)
Module 7 L2VPNs and AToM (Part 1)
Lab 6 L2VPNs and AToM (Part 1)
Version 4.0.1
vii
Day 5
Module 7 L2VPNs and AToM (Part 2)
Lab 6 L2VPNs and AToM (Part 2)
Module 7 L2VPNs and AToM (Part 3)
Lab 6 L2VPNs and AToM (Part 3)
Course Summary
viii
Version 4.0.1
Overview
Description
This course is designed to teach service provider customers (and
internal Cisco staff) how to configure and to verify their operation of:
The course will include both lecture and intensive hands-on lab
exercises.
The lab network will consist of multiple cores of P and PE routers
running Cisco IOS XR Software Release 3.9.0 and preconfigured CE
routers running Cisco IOS software.
This course does not cover routing fundamentals, MPLS
fundamentals, or Multicast fundamentals, IPv6, QoS, or Layer 3
VPNs.
Version 4.0.1
ix
Objectives
After completing this course, you will be able to do the following:
Version 4.0.1
Contents
Course Overview ................................................................................................................... v!
Course Agenda ..................................................................................................................... vii!
Version 4.0.1
xi
Version 4.0.1
Version 4.0.1
xiii
xiv
Version 4.0.1
Module 1
MPLS Technology Introduction
Overview
Description
This module provides a brief background of the concepts and architecture
of MPLS and MPLS tunnels and supporting technologies. The module
describes the similarities and differences among Layer 2 VPNs,
Layer 3 VPNs, and Traffic Engineering (TE), and describes Resource
Reservation Protocol.
Objectives
After completing this module, you will be able to:
Version 4.0.1
11
Module 1
What is MPLS?
Multiprotocol Label Switching (MPLS) is a technology for enhanced
delivery of services that resolves many issues with packet forwarding
across the Internet. MPLS integrates forwarding using label swapping
with network layer (OSI Layer 3) routing. This integration enables packet
forwarding through label-switch paths (LSPs). The LSPs can be created in
several ways and by using several protocols. A short general list is on the
opposite page.
MPLS provides mechanisms to transport Layer 2 technologies as outlined
in these IETF RFCs:
12
Version 4.0.1
Module 1
What is MPLS?
!ATM
!Frame Relay
!PPP and HDLC
!POS
!Ethernet
!Sonet/SDH circuit emulation over packet (CEP)
Version 3.9.0a
Version 4.0.1
XMPLST4Module 1/4
13
Module 1
14
Version 4.0.1
Module 1
Layer 3
VPNs
Traffic
Engineering
Layer 2
VPNS
Any
Transport
over MPLS
IP+Optical
GMPLS
MPLS
Network Infrastructure
Version 3.9.0a
Version 4.0.1
XMPLST4Module 1/5
15
Module 1
MPLS Security
MPLS security translates to protection and privacy of traffic across the
network. Protection of data in the customer private network over the
public service provider network represents a small slice of the service
providers overall security.
16
Version 4.0.1
Module 1
MPLS Security
Operation
Implementation
Architecture and
Algorithm
MPLS
Privacy
Version 3.9.0a
Version 4.0.1
XMPLST4Module 1/6
17
Module 1
MPLS Elements
MPLS consists of two planes and some core services such as label
management and packet forwarding.
The control plane enables and disables MPLS on interfaces, allocates and
manages label tables, sets up label rewrites, and interacts with the IGP to
set up label binding and forwarding path creation.
The forwarding plane imposes (pushes) labels onto packets, swaps labels
along the forwarding path, and disposes of (pops) labels.
MPLS uses the idea of binding a label to a forwarding equivalence class
(FEC). A FEC describes packets forwarded behind a certain label. A FEC
can represent IP prefixes, layer 2 frames transported over a pseudowire, or
even SONET frames in Circuit Emulation over Packet Switched networks
(CEoPS). In following modules we discuss the case of IP prefixes.
The control plane creates label bindings and stores them in a label
information base (LIB). Label Distribution Protocol (LDP) is used to
distribute this label prefix binding amongst the Label Switch Routers
(LSRs).
Each LSR constructs a label forwarding information base (LFIB) by
participating in the routing protocol using the information received from
the other router participants. The participation associates a destination
prefix to a locally significant label creating the local binding. MPLS LDP
labels are locally significant because they are replaced at each hop in the
label-switched path (LSP).
An LFIB contains an incoming label, outgoing label, outgoing interface,
and outgoing MAC address. The incoming label indexes the destination
prefix.
18
Version 4.0.1
Module 1
MPLS Elements
Control plane
Exchange of
routing information
IP routing protocols
IP routing table
Exchange of
label bindings
Incoming labeled
packets
Outgoing labeled or
unlabeled packets
Label forwarding
information base
Outgoing labeled or
unlabeled packets
Forwarding plane
2011, Cisco Systems, Inc. All rights reserved.
Version 3.9.0a
Version 4.0.1
XMPLST4Module 1/8
19
Module 1
110
Version 4.0.1
Module 1
Version 3.9.0a
Instructor's Note
Slide animation: Slides starts with network diagram; click 1 Existing protocols(#1),
double arrows between cloud routers, pointer; click 2 LDP(#2), dashed arrows, pointer; click 3
Ingress LSR(#3), packets, pointers; click 4 LSRs forward(#4), packets, pointer; click
5 Edge LSR, packets, pointer
Version 4.0.1
111
Module 1
Version 4.0.1
Module 1
Basic elements
!
!
!
RP
BGP
RSVP
IGP
LDP
!
!
!
(LFD)
!
!
!
LC*
Encap
or
decap
RIB
LSD
FIB
LFD
LFIB
*LC means line card and may be the
CRS-1 MSC and PLIM combination
or XR 12000 Series router line cards
Version 3.9.0a
Version 4.0.1
XMPLST4Module 1/11
113
Module 1
Preventing packets from entering the core and disrupting the network
function, however the routing protocol may still be an open issue
The entry point, or edge, of the provider network is clearly the most
vulnerable point. A key factor to keep in mind is the choice of the routing
protocol selected to connect customer CE to provider PE.
114
Other IGPs, such as RIPv2, EIGRP, or OSPF, may be the choice of the
customer. These have limited security features and should only be
employed by specific customer request
Version 4.0.1
Module 1
Network still
open: routing
protocol
Leaves attack
vectors:
transit traffic,
Denial of Service
(DoS)
limiting access
Avoid insider
attacks
Operate securely
2011, Cisco Systems, Inc. All rights reserved.
Version 3.9.0a
XMPLST4Module 1/13
Instructor's Note
Slide animation: Slide starts with first bullet; click 1 second bullet followed after 1 second by
yellow arrow and text box; click 2 third bullet followed after 1 second by yellow arrow and text
box; click 3 fourth bullet followed after 1 second by yellow arrow and text box; click 4 fifth
bullet followed after 1 second by yellow arrow and text box;
2011 Cisco Systems, Inc.
Version 4.0.1
115
Module 1
116
Version 4.0.1
Module 1
!Peer discovery
!Peer session establishment
Version 3.9.0a
Version 4.0.1
XMPLST4Module 1/15
117
Module 1
Label Distribution
Each LSR creates a local binding or label for each IGP prefix in the local
routing information base (RIB) and stores the labels in the LIB as local.
The router distributes these local labels to each of its LDP neighbors. The
neighbors store these labels in their LIB as remote. Each LSR follows this
procedure for prefixes in its RIB.
An LSR may receive more than one remote label for a single prefix. The
LSR chooses the remote label based on the next hop for the prefix in its
RIB. It creates the LFIB labels using the best path routes.
In this simplistic illustration, the network, 10.1.1.0 with a mask of 24 bits
is attached to the router, R4. R4 assigns a label, 16043, to the prefix and
distributes the label upstream to R3. In turn, R3 enters the label in its
LIB. R3 assigns its own label to the prefix, 16032, and distributes it to R2.
R2 assigns the label, 16021, to the prefix and distributes it to R1.
When a device on a network attached to R1 wants to reach 10.1.1.0/24, R1
adds the label, 16021 to the outgoing packet. When the packet reaches R2,
it reads the label 16021 and swaps it for label 16032 and forwards the
packet to R3. This process continues until the packet reaches its
destination.
118
Version 4.0.1
Module 1
Label Distribution
10.1.1.0/24
R4
R3
Label 16021
Label 16032
Label 16043
10.1.1.0/24
10.1.1.0/24
10.1.1.0/24
Version 3.9.0a
Version 4.0.1
XMPLST4Module 1/16
119
Module 1
120
Version 4.0.1
Module 1
Multicast
Customers connect to a
Hosting
service provider
Intranet
VoIP
Extranet
Version 3.9.0a
Version 4.0.1
XMPLST4Module 1/18
121
Module 1
This is the basic type of L3VPN in which multiple sites are connected
together, and each site has full connectivity to the other. The VPN is
isolated from other VPNs that the service provider supports. Customers
might use the same IP addressing within their networks and their own
VPNs as other service provider customers, but the separation prevents any
issue.
Central Services L3VPN
These types of VPNs are also called extranets. An example is multiple auto
parts stores that have access to a central site parts warehouse. However,
while the multiple sites have access to the central site, they do not have
access to each others networks. In this type of VPN some unique IP
addressing is required for customers to access both the extranet and their
own intranets.
122
Version 4.0.1
Module 1
Seattle
San Diego
Boston
IP
and
MPLS
Atlanta
Single L3VPN
Customer A
Customer B
Customer C
IP
and
MPLS
Customer C
Central site
service
Version 4.0.1
123
Module 1
124
Version 4.0.1
Module 1
CE
L3VPN service
CE
L3VPN service
CE
0.0.0.0255.255.255.255
CE
mbehring
0.0.0.0255.255.255.255
PE-CE interfaces
belong to VPN
Data planes:
VPNv4 address
PE
Control plane:
IPv4 address
PE
Version 4.0.1
XMPLST4Module 1/22
125
Module 1
126
Version 4.0.1
Module 1
Core routers
have individual
VC information
VPN pink
VPN blue
VPN green
2011, Cisco Systems, Inc. All rights reserved.
Version 3.9.0a
Version 4.0.1
XMPLST4Module 1/24
127
Module 1
128
Version 4.0.1
Module 1
Version 3.9.0a
Version 4.0.1
XMPLST4Module 1/25
129
Module 1
Traffic Engineering
What is traffic engineering? Most service providers research the traffic in
their network to understand how their resources are being used. Typically,
they use certain statistical techniques to analyze the data they collect. This
analysis helps them understand how they might be able to manage some
traffic to take advantage of their resources.
After they have analyzed the data, they can
Using MPLS and RSVP, you can establish and maintain LSPs by using
particular resource requirements and available resources (usually
bandwidth) passed on by the IGPs.
130
Version 4.0.1
Module 1
Traffic Engineering
PRINT ONLY!!
What is it?
Version 3.9.0a
XMPLST4Module 1/28
IETF DS-TE
Traffic classes
(RFC 4125)
Version 3.9.0a
Version 4.0.1
XMPLST4Module 1/29
131
Module 1
MPLS-TE Terminology
There are some terms that are important to the understanding of traffic
engineering:
132
Version 4.0.1
Module 1
MPLS Terminology
TE Tunnel
R1
R2
R3
Network X
Headend
Midpoint
Tailend
Version 3.9.0a
Version 4.0.1
XMPLST4Module 1/30
133
Module 1
134
Version 4.0.1
Module 1
Available
bandwidth
for TE
80 Mbps
bp
s
0
10
50
10
30 Mbps
80 Mbps
100 Mbps
100 Mbps
Headend
s
bp
s
bp
M
s
bp
60
80
s
bp
60
Total link
bandwidth
bp
s
100 Mbps
Tailend
Version 3.9.0a
Version 4.0.1
XMPLST4Module 1/31
135
Module 1
136
Version 4.0.1
Module 1
Version 3.9.0a
Version 4.0.1
XMPLST4Module 1/33
137
Module 1
138
Version 4.0.1
Module 1
Version 3.9.0a
Version 4.0.1
XMPLST4Module 1/34
139
Module 1
140
Version 4.0.1
Module 1
Router F
Router A
Router E
Router G
Router C
2011, Cisco Systems, Inc. All rights reserved.
Router D
Version 3.9.0a
Version 4.0.1
XMPLST4Module 1/35
141
Module 1
Summary
MPLS Technology Introduction
In this module, you learned:
142
Version 4.0.1
Module 2
MPLS OAM
Overview
Description
MPLS operations, administration, and maintenance (MPLS OAM) is a set
of tools that helps to diagnose and troubleshoot MPLS network
connectivity. This module takes a look at the need for MPLS OAM, what it
is, and how it is used in the Cisco IOS XR operating system. Relevant
MPLS OAM tasks are distributed throughout various lab exercises in this
course.
Objectives
After completing this module, you will be able to:
Version 4.0.1
MPLS OAM
Module 2
Review
This is a review of some basic definitions relevant to the concepts that are
covered in this module.
Definition Review
These are some basic definitions used in the concepts of MPLS OAM:
Version 4.0.1
Module 2
Review
Definition Review
LSR, LER
PHP
LSR
LSR
LSR, LER
manner, over the same path, and with the same forwarding treatment
Version 3.9.0a
XMPLST4Module #/3
Instructors Note
Just establish a baseline to be sure everyone has the same points of reference and resolve any
student questions.
2011 Cisco Systems, Inc.
Version 4.0.1
MPLS OAM
Module 2
PE to PE LSPs
Version 4.0.1
Module 2
Customer A
Site 2
MPLS CORE
CE
CE
PE-PE LSPs
PWES
PE
PE
PWES
Pseudowires
Customer B
Site 1
TE tunnels
Customer B
Site 2
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/5
MPLS OAM
Module 2
Ping makes use of the Internet Control Message Protocol (ICMP) protocol.
There are two ping message types:
These messages contain an optional data field that is used to store the time
the ICMP echo request message was sent. This allows a system to
determine the message round trip time (RTT).
In the first example on the adjacent page the ping from R1 reaches R4,
which responds with an echo reply. The ping is successful. In the second
example the ping packet is lost due to a failure in the core of the network;
there is no response to the originating router resulting in a timeout error.
Traceroute
Version 4.0.1
Module 2
R1
R2
R3
R4
a. Ping reaches R4
R4 sends ICMP
echo response
ICMPbased
ping
R2 drops packet
R2 sends TTL expired
ICMP message back to R1
R2 decreases TTL by 1
and forwards it to R3
R3 drops packet
sends TTL expired
ICMP back to R1
UDP/ICMPbased
traceroute
IP Dest=R4
TTL=3
R1 now has all the ICMP error messages with the corresponding source
addresses and can display the complete route to the destination
2011, Cisco Systems, Inc. All rights reserved.
Version 3.9.0a
XMPLST4Module #/6
Instructor's Note
Instructors may wish to discuss failure scenarios for the traceroute command.
Version 4.0.1
MPLS OAM
Module 2
Version 4.0.1
Module 2
!Broken path OR
!No MPLS path
!In a single label environment, if the next-hop cannot
or MPLS VPNs
Version 3.9.0a
XMPLST4Module #/7
Instructors Note
One confusing issue is that an ICMP ping might also use an LSP to forward packets. Traditional
ICMP would likely be encapsulated as an MPLS packet if MPLS is enabled on the source router.
This leads to nice discussion on the different failures that can be detected with ICMP and LSP
ping (that is, if packet is untagged it may still make it across network and so on)
Version 4.0.1
MPLS OAM
Module 2
10
Version 4.0.1
Module 2
Assumption
MPLS failures always cause devices to send traps
Reality
Customer is often aware of the fault before the service
provider
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/8
11
MPLS OAM
Module 2
Mismatched labels
Detecting MPLS failures can be difficult without MPLS OAM for these
reasons:
12
Version 4.0.1
Module 2
MPLS
49
50
R4
R2
R1
R3
LSP Broken
Mismatched labels
Software or hardware corruption
Detecting MPLS failures can be difficult
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/9
13
MPLS OAM
Module 2
VPNv4 prefixes
TE tunnels
L2VPNs (pseudowires)
14
Version 4.0.1
Module 2
Requirements:
Applications:
Version 3.9.0a
XMPLST4Module #/11
Instructor's Note
RFC 4379 is updated by RFC 5462.
Version 4.0.1
15
MPLS OAM
Module 2
16
MPLS LSP ping tests LSP connectivity for IPv4 LDP prefixes, TE
FECs, and any transport over MPLS (AToM) FECs
MPLS LSP traceroute traces the LSPs for IPv4 LDP prefixes, TE
FECs, and any transport over MPLS (AToM) FECs
Version 4.0.1
Module 2
DA
SA
Echo
SA=Source Addr
DA=Destination Addr
DA
Echo
49
50
R1
R3
R2
LSP Broken
Critical concepts:
Test packet follows the MPLS data path
Traditional IP ping or trace does not detect many MPLS failures
LSRs provide diagnostic information at the point of failure
2011, Cisco Systems, Inc. All rights reserved.
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/12
17
MPLS OAM
Module 2
18
MPLS TEUse the ping MPLS traffic-eng or traceroute MPLS trafficeng command
Version 4.0.1
Module 2
MPLS OAM
CE
Ingress
PE
Egress
PE
CE
PWE3, TE
or
VPN Label
MPLS LSP
MPLS VPN
MPLS TE
Pseudowires (L2VPN)
2011, Cisco Systems, Inc. All rights reserved.
Version 3.9.0a
XMPLST4Module #/13
Instructors Note
The traceroute pseudowire multisegment command supports testing a PW with a single
segment by specifying a destination address only with PE-ID
2011 Cisco Systems, Inc.
Version 4.0.1
19
MPLS OAM
Module 2
20
Version 4.0.1
Module 2
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/15
21
MPLS OAM
Module 2
22
Version 4.0.1
Module 2
MPLS echo-request
MPLS echo-reply
MPLS LSP ping is based on echo request and echo reply operation
Echo request uses data path LSP for the specified FEC
Echo reply copies the echo request source address and port
Note: MPLS LSP ping and traceroute verify LSP paths in only one
direction
2011, Cisco Systems, Inc. All rights reserved.
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/16
23
MPLS OAM
Module 2
Mismatched labels
The MPLS LSP ping and traceroute are valuable tools for diagnosing a
LSP failure. In this example, the failure between R3A and R2 results in
the LSP being down. As a result of the MPLS path failure, R3A processes
the packet using the IP header. R3A does not forward the echo request, but
responds with an echo reply, thus helping isolate the location of the LSP
path failure.
24
Version 4.0.1
Module 2
MPLS Echo-request
R3A
MPLS Echo-reply
LSP Down
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/17
25
MPLS OAM
Module 2
26
Value of 3 reply using an IPv4 UDP packet with router alert (RA)
Sender handle relevant to, and set by the sender; used to match all
echo replies and requests of a single ping
Version 4.0.1
Module 2
IP or MPLS header
Version number
Must be zero
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/18
27
MPLS OAM
Module 2
28
Return code there are seven (7) return codes from target router
!
Version 4.0.1
Module 2
IP or MPLS header
Version number
Must be zero
Sender's handle
Sequence number
Timestamp sent (NTP seconds)
Timestamp sent (NTP fraction of usecs)
Timestamp received (NTP seconds)
Timestamp received (NTP fraction of usecs)
TLVs
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/19
29
MPLS OAM
Module 2
30
exp: MPLS experimental field value in the MPLS header for echo
replies
Module 2
Version 3.9.0a
XMPLST4Module #/21
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/22
31
MPLS OAM
Module 2
32
Version 4.0.1
Module 2
PE2
PE1
CE
CE
Tunnel
CE
CE
XMPLST4Module #/24
PE
PE
Tunnel label
VC label
VC label
VC label
LSP ping
LSP ping
LSP ping
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/25
33
MPLS OAM
Module 2
34
Version 4.0.1
Module 2
!!!!!
Success rate is 100 percent (5/5),
round-trip min/avg/max = 4/6/9 ms
Codes
2011, Cisco Systems, Inc. All rights reserved.
TLV
Meaning
Version 3.9.0a
No return code
Unsupported TLVs
Success
No FEC mapping.
Reserved
10
FEC mismatch
11
No label entry
12
13
unknown
Transit router
Timeout
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/28
XMPLST4Module #/29
35
MPLS OAM
Module 2
36
Version 4.0.1
Module 2
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/30
37
MPLS OAM
Module 2
38
Version 4.0.1
Module 2
LSP
broken
49
P22
P11
PE66
PE33
49
P22
PE66
P11
PE33
XMPLST4Module #/32
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/33
39
MPLS OAM
Module 2
40
Version 4.0.1
Module 2
P3 does not have a label binding for label 60 and drops the packet
LSP ping fails
2011, Cisco Systems, Inc. All rights reserved.
Version 3.9.0a
XMPLST4Module #/35
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/33
41
MPLS OAM
Module 2
MPLS Traceroute
There are two fundamental types of traceroute. The first kind is a path
trace that provides information about only one path out of all the possible
Equal Cost Multipaths (ECMPs). The second is the multipath trace that
provides information on all possible paths between source and destination.
Both of these options are further explored in this section.
42
Version 4.0.1
Module 2
MPLS Traceroute
Path A
Path B
Path traceGives information about only one path out of all possible
equal cost multipaths (ECMPs)
Path trace from PE1 to PE2 gives information about path A OR path B
Multipath traceReturns all possible paths between source and
destination
Multipath trace from PE1 to PE2 gives information about path A AND path B
2011, Cisco Systems, Inc. All rights reserved.
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/34
43
MPLS OAM
Module 2
MPLS traceroute has a rich set of options just as MPLS ping. Once the
traceroute mpls command is issued there are three parameter choices:
44
Version 4.0.1
Module 2
PE66
P22
P11
PE33
Version 3.9.0a
XMPLST4Module #/39
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/37
45
MPLS OAM
Module 2
46
Version 4.0.1
Module 2
PE66
P22
MTU set to 1000
P11
PE33
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/41
47
MPLS OAM
Module 2
Multipath Trace
The syntax for the traceroute MPLS multipath IPv4 command is shown
on the opposite page.
A multipath trace:
Path failures may affect SLAs and services for some traffic flows, but not
others. The flows affected are linked to the failing paths
48
Version 4.0.1
Module 2
Multipath Trace
:router#
traceroute mpls multipath ipv4 address/mask [destination start-address end-address
address-increment] [exp exp-bits] [flags fec] [force-explicit-null] [hashkey ipv4
bitmap bit-size] [interval min-send-delay] [output interface type interface-path-id
[nexthop nexthop-address] ] [reply {dscp dscp-value | mode{ipv4 | router-alert}]
[retry-count count] [revision version] [source source-address] [timeout timeout]
[ttl value] [verbose]
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/43
49
MPLS OAM
Module 2
50
Version 4.0.1
Module 2
R3
Path 127.0.0.1
R1
R4
R2
R6
Path 127.0.0.2
Path 127.0.0.3
Path 127.0.0.4
R7
R8
R9
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/41
51
MPLS OAM
Module 2
52
Version 4.0.1
Module 2
Choosing a LSP
Varying the value of the IP address 127/8
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/45
53
MPLS OAM
Module 2
54
Version 4.0.1
Module 2
10.3.3.33
PE33
10.1.1.11
PE55
P1
identifies failures
Tells you how to test failed paths
10.5.5.55
P2
PE44
10.2.2.22
10.4.4.44
PE66
10.6.6.66
Version 3.9.0a
XMPLST4Module #/47
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/48
55
MPLS OAM
Module 2
Codes
56
TLV
Meaning
No return code
Unsupported TLVs
Success
No FEC mapping.
Reserved
10
FEC mismatch
11
No label entry
12
13
unknown
Transit router
Timeout
Version 4.0.1
Module 2
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/49
57
MPLS OAM
Module 2
58
Version 4.0.1
Module 2
10.3.3.33
PE33
10.1.1.11
PE55
10.5.5.55
MPLS is disabled on
P22 s PE facing interface
P11
P22
10.4.4.44
PE44
10.2.2.22
PE66
10.6.6.66
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/50
59
MPLS OAM
Module 2
60
Version 4.0.1
Module 2
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/52
61
MPLS OAM
Module 2
62
Version 4.0.1
Module 2
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/53
63
MPLS OAM
Module 2
64
Version 4.0.1
Module 2
10.5.5.55
10.3.3.33
Attachment VC
PE33
10.1.1.11
PE55
P11
VCCV Packet
Attachment VC
P22
PE44
10.2.2.22
PE66
10.6.6.66
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/55
65
MPLS OAM
Module 2
66
Version 4.0.1
Module 2
:router(config-oam)# echo ?
disable-vendor-extension Disable sending vendor extension TLV with
echo request
revision
Echo packet default revision
:router(config-oam)# echo revision ?
1 draft-ietf-mpls-lsp-ping-03 (initial)
2 draft-ietf-mpls-lsp-ping-03 (rev 1)
3 draft-ietf-mpls-lsp-ping-03 (rev 2)
4 draft-ietf-mpls-lsp-ping-09 (initial)
2011, Cisco Systems, Inc. All rights reserved.
Version 3.9.0a
XMPLST4Module #/57
Instructor's Note
In IOS OAM is enabled by default
Version 4.0.1
67
MPLS OAM
Module 2
68
Version 4.0.1
Module 2
Show commands
:router# show mpls oam ?
client
clients registered with LSPV server
counters
LSP verification counters
database
information about active LSP verification databases
interface Specify an interface
trace
Trace data
Clear commands
:router# clear mpls oam ?
counters Counters information
:router# clear mpls oam counters ?
global
Clear global counters
interface Specify an interface
packet
Clear global packet counter
2011, Cisco Systems, Inc. All rights reserved.
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/58
69
MPLS OAM
Module 2
70
Version 4.0.1
Module 2
oam interface ?
GigabitEthernet/IEEE 802.3 interface(s)
Loopback interface(s)
Ethernet/IEEE 802.3 interface(s)
Multilink network interface(s)
Null interface
Packet over SONET/SDH network interface(s)
Serial network interface(s)
VASI Left interface(s)
VASI Right interface(s)
Display all interfaces
MPLS Traffic Engineering Tunnel interface(s)
Additional output omitted
IP
---------------10.6.6.66/32
172.21.116.64/24
192.168.126.6/24
192.168.156.6/24
192.168.116.6/24
Version 3.9.0a
Index
---------0x00000007
0x00000005
0x00000002
0x00000003
0x00000004
XMPLST4Module #/60
Instructor's Note
Index is for internal use and relates to the unique interface descriptor block for engineering
troubleshooting.
Pid is the process ID.
2011, Cisco Systems, Inc. All rights reserved.
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/61
71
MPLS OAM
Module 2
Summary
MPLS OAM
In this module, you learned to:
72
Version 4.0.1
Module 3
MPLS LDP
Overview
Description
This module describes the MPLS Label Distribution Protocol (LDP). It
discusses the basic protocol operation of LDP, such as message exchanges
that occur between neighboring label switching routers (LSRs). The
module provides a description of the major data structures used to hold
label information. It also explains how LSRs discover each other and
maintain state information. The module also contains a series of CLI
examples used to configure LDP, and to examine status and statistical
information.
Objectives
After completing this module, you will be able to:
Version 4.0.1
31
MPLS LDP
Module 3
Components of LFIB
The Label FIB (LFIB) consists of three main components: Next Hop Label
Forwarding Entry (NHLFE), FEC-to-NHLFE (FTN) and Incoming Label
Map (ILM). Each is discussed separately. First we define forwarding
equivalence class (FEC), which is critical to the understanding of the three
components of the LFIB
32
Version 4.0.1
Module 3
Components of LFIB
Version 3.9.0a
Version 4.0.1
XMPLSTModule 2/4
33
MPLS LDP
Module 3
Replace the label at the top of the label stack with a specified new
label
Replace the label at the top of the label stack with a specified new
label, and then push one or more specified new labels onto the label
stack
If the packets next hop is the current LSR (egress LSR or label edge router
(LER)), then the label stack operation MUST pop the stack.
In the sample output from PE66 showing NHLFE information, note that:
MAC/Encaps for the unlabeled path is 14/14; the first number is the
size of the MAC header and the second number is the MAC header plus
the label
MAC/Encaps for the labeled path is 14/18; MAC header and MAC
header with one label (4 bytes)
Instructor's Note
Observe that there are 2 paths to the 192.168.134.0 network from PE66: unlabeled using P22 and labeled using P11.
Traffic arriving with a label of 16072 can be forwarded out G0/4/0/0 unlabeled with 14 bytes of MAC address and
14 bytes of encapsulation. Or out G0/4/0/3 with a label of 16005 with 14 bytes of MAC address and 18 bytes of
encapsulation that include the MPLS label.
34
Version 4.0.1
Module 3
Components of LFIB
s label stack
Version 3.9.0a
XMPLSTModule 2/6
Label
In
---------------- ------192.168.134.0/24 16072
Label
Out
---------Unlabelled
16005
Outgoing
Interface
-----------Gi0/4/0/0
Gi0/4/0/3
Next Hop
--------------192.168.126.2
192.168.116.1
Version 3.9.0a
Version 4.0.1
XMPLSTModule 2/7
35
MPLS LDP
Module 3
FEC-to-NHLFE (FTN)
The FEC-to-NHLFE (FTN) maps each FEC to a set of NHLFEs. It is used
when forwarding packets that arrive unlabeled, but that need to be labeled
before being forwarded.
If the FTN maps a particular label to a set of NHLFEs that contains more
than one element, exactly one element of the set must be chosen before the
packet is forwarded. Having the FTN map a label to a set containing more
than one NHLFE may be useful when, for example, you want to load
balance over equal-cost paths.
The show mpls forwarding command provides output showing inbound
and outbound labels and IP addresses. On the PE routers, observe the
ingress traffic from the CE router is labeled as it passes through an
LDP-enabled core. This is an example of FEC-to-NHLFE.
36
Version 4.0.1
Module 3
Components of LFIB
FEC-to-NHLFE (FTN)
Version 3.9.0a
Version 4.0.1
XMPLSTModule 2/8
37
MPLS LDP
Module 3
38
Version 4.0.1
Module 3
Components of LFIB
Version 3.9.0a
Version 4.0.1
XMPLSTModule 2/9
39
MPLS LDP
Module 3
The table lists the label exchange protocols that assign and advertise label
bindings for various FEC types. The label exchange protocols are LDP,
RSVP and MP-BGP.
Instructor's Note
Constraint Based Routing LDP (CR-LDP), an older and deprecated protocol, used LDP
extensions for traffic engineering
310
Version 4.0.1
Module 3
LDP
IPv4 prefixes
XMPLSTModule 2/12
IPv6 prefixes
L2VPN pseudowires
RSVP
MP-BGP
Version 3.9.0a
Version 4.0.1
XMPLSTModule 2/13
311
MPLS LDP
Module 3
312
Version 4.0.1
Module 3
Network Deployment
Scenario
Use of LDP
MPLS-enabled Core
(incl. L3VPNs)
Exchange of label
bindings for IGP prefixes
between P and PE routers
Exchange of label
bindings for IGP prefixes
supporting ASBR interconnectivity
Version 3.9.0a
XMPLSTModule 2/14
Instructor's Note
Remember that with L2VPNs, a pseudowire is comprised of 2 VCs.
2011 Cisco Systems, Inc.
Version 4.0.1
313
MPLS LDP
Module 3
314
BGP free core with MPLSBGP was needed on all network routers to
prevent black-holes in transit networks, by ensuring that all
destinations are known by all routers in the transit network. This need
was circumvented by the introduction of MPLS. MPLS core routers no
longer need destination prefixes because they do not perform normal IP
lookups; they perform label switching. Therefore, core routers in the
service provider network no longer need to run BGP; only the edge
routers need to do that
Version 4.0.1
Module 3
Version 3.9.0a
Version 4.0.1
XMPLSTModule 2/16
315
MPLS LDP
Module 3
Binding exchange
Forwarding setup
316
Version 4.0.1
Module 3
Version 3.9.0a
Version 4.0.1
XMPLSTModule 2/17
317
MPLS LDP
Module 3
Neighbor Discovery
LDP hellos, which use UDP port 646, are automatically sent on all links
(with LDP enabled) to discover neighbors and identify their originator.
LDP Identifier
LDP Hello packets carry an identifier known as the LDP Identifier used to
uniquely identify each peer. The LDP Identifier consists of a LSR-ID
(typically a router-ID address) and Label Space ID. There are two types of
LDP Identifiers:
The zero Label Space ID represents a pool of labels that are shared
across all the devices interfaces
It is typically used for ATM interfaces that use VPI/VCI for labels
Discovery Hellos
Basic Discovery
318
Version 4.0.1
Module 3
Neighbor Discovery
172.12.0.55:0 (platform-wide)
172.12.0.55:5 (per-interface)
Version 3.9.0a
XMPLSTModule 2/19
Basic/Link:
Instructor's Note
Platform-wide label spaces are used with LAN and synchronous type interfaces, while interface
specific label spaces are used with ATM interfaces. This is known as label-controlled ATM, and is
an MPLS interface in which labels are carried in the VPI or VCI fields of the ATM cells, and in
which VC connections are established under the control of MPLS software.
2011, Cisco Systems, Inc. All rights reserved.
Version 3.9.0a
Version 4.0.1
XMPLSTModule 2/20
319
MPLS LDP
Module 3
320
Version 4.0.1
Module 3
Point-to-point
Ethernet
Version 3.9.0a
Version 4.0.1
XMPLSTModule 2/21
321
MPLS LDP
Module 3
Session establishment
In the figure, R1 receives a Hello message from R2. If an LDP session for
the label space is not currently established, R1 attempts to open a TCP
connection to R2. When opening a TCP connection, an LSR will have one of
two roles: active or passive as described in the table. The LSR compares
the LDP identifiers (IP addresses) of both ends of the TCP connection.
R1s LDP identifier (IP address), is greater
in value than R2s
R1 attempts to open a
connection to R2
Downstream unsolicited
Downstream on-demand
When negotiation succeeds, the LDP connection is up, and the LSRs begin
to use the connection for label distribution.
322
Version 4.0.1
Module 3
Terminology
Neighbor router that has been discovered using LDP hellos
Session LDP sessions are TCP connections established to
discovered neighbors
Peer router that has successfully negotiated session parameters
for label exchange
Version 3.9.0a
XMPLSTModule 2/23
Instructor's Note
Discovery hellos for a link are maintained using UDP port 646 packets every 5 seconds, while
sessions are maintained using TCP port 646 keep-alive packets every 60 seconds.
2011, Cisco Systems, Inc. All rights reserved.
Version 3.9.0a
Version 4.0.1
XMPLSTModule 2/24
323
MPLS LDP
Module 3
Single adjacency
Multiple adjacencies
Note that in both cases there is only one TCP connection between the pair
of LSRs. In other words, where multiple links between an LSR pair involve
the exchange of the same label spaces over all of the links, the relationship
would be many links to one TCP connection.
The example on the adjacent page uses platform-wide label spaces.
324
Version 4.0.1
Module 3
Platform-wide example
2011, Cisco Systems, Inc. All rights reserved.
Version 3.9.0a
Version 4.0.1
XMPLSTModule 2/25
325
MPLS LDP
Module 3
Transport Adjacencies
326
Version 4.0.1
Module 3
Transport Adjacency
Periodic transmission of LDP keep-alive messages
on TCP connection to monitor integrity of TCP
connection
Version 3.9.0a
Version 4.0.1
XMPLSTModule 2/26
327
MPLS LDP
Module 3
Binding Exchange
When the session peering is established, the LDP protocol enters the
binding exchange phase. LDP peers freely exchange two types of bindings:
The label information base (LIB) is a database in LDP that maintains, for
each FEC or prefix:
328
Version 4.0.1
Module 3
Binding Exchange
Version 3.9.0a
Version 4.0.1
XMPLSTModule 2/27
329
MPLS LDP
Module 3
Label Values
Label values 0 through 15 are reserved for MPLS-specific control functions,
and not for general forwarding use. Based on the RFCs, the LSR assigns a
specific function to each label. The reserved labels and their functions are:
3: Implicit null is a label assigned to a FEC by the egress LSR, and sent
to the penultimate hop router. This triggers the penultimate hop router
to pop the top label of a stack for packets destined for the FEC with the
implicit null
4 to 15: reserved
A specific label value range can be assigned to each router. The key benefit
is clarity when examining MPLS forwarding statistics.
330
Version 4.0.1
Module 3
Label Values
! 16 to 1,048,575
Version 3.9.0a
Version 4.0.1
XMPLSTModule 2/28
331
MPLS LDP
Module 3
Forwarding Setup
LDP uses routing information to assign labels and forward traffic, it does
not perform any routing. It uses the routing next-hop information and
determines the remote label from the corresponding LDP peer, setup LSPs
that would forward traffic.
LSP Forwarding Setup
LSP Path
332
The packet arrives at R3. An index lookup of L3 shows that the label is
to be removed, and the IP packet is to be forwarded out the
corresponding interface
Version 4.0.1
Module 3
Forwarding Setup
FEC
10.0.0.0/8
FEC
Local
Label
Out
Label
Nexthop
L1
L2
R2
Local
Label
10.0.0.0/8
L1
IP
LFIB
LFIB
LFIB
L2
Out
Label
Nexthop
L1
R1
L3
R3
L4
R4
R1
R2
IP L3
Local
Label
Out
Label
Nexthop
L2
R2
L3
UL*
Rx
10.0.0.0/8
L3
L2
L2
IP L2
FEC
10.0.0.0
cost =5
R3
IP
L2
L4
cos
t =1
R4 LFIB
FEC
*UL: Unlabeled
2011, Cisco Systems, Inc. All rights reserved.
10.0.0.0/8
Version 3.9.0a
Local
Label
Out
Label
Nexthop
L2
R2
L4
UL*
Ry
XMPLSTModule 2/29
Instructors Note
In this example, the point is to explain how labels are assigned to a FEC. Also, walk through how
an IP packet with MPLS label gets from R1 through to R3. Remember you are looking at label
switching and not a L3VPN.
2011 Cisco Systems, Inc.
Version 4.0.1
333
MPLS LDP
Module 3
2. Session messages
3. Advertisement messages
Add, remove, change, and request LDP bindings (labels and addresses)
4. Notification messages
Provide advisory and signal error information (these use a status code)
334
Version 4.0.1
Module 3
Session messages:
Advertisement messages:
Add, remove, change, and request LDP bindings (label and addresses)
ADDRESS, ADDRESS-WITHDRAW, LABEL-MAPPING, LABEL-WITHDRAW,
LABEL-RELEASE, LABEL-REQUEST, LABEL-ABORT-REQUEST
Notification messages:
Provide advisory and signal error information (these use a status code)
NOTIFICATION
HELLO
Version 3.9.0a
XMPLSTModule 2/31
INITIALIZATION
ADDRESS (MAPPING, WITHDRAW)
LABEL (MAPPING, WITHDRAW, RELEASE, REQUEST, ABORT-REQUEST)
NOTIFICATION
KEEPALIVE
R1
Hello
R5
R3
R4
R6
Targeted session
Targeted hello
R2
Version 3.9.0a
Version 4.0.1
XMPLSTModule 2/32
335
MPLS LDP
Module 3
TCP and UDP use well-known port number 646. Messages use wellknown port number 646 for the source port, as well as the destination
port
The LDP data portion of the packet is encoded as one or more TypeLength-Value (TLV) fields. TLV fields consist of a fixed-size (2-octet)
parameter type identifier, a fixed-size (2-octet) length field, and a
variable-length data value
One or more messages can be sent towards a peer within a LDP PDU
336
Version 4.0.1
Module 3
20
General
format
IP
18
10
TCP
LDP header
octets
LDP message
LDP
header
LDP
message
Currently
1
Excludes length
and version
Type
Address
Address withdraw
Hello
Initialization
KeepAlive
Label mapping
2011, Cisco Systems, Inc. All rights reserved.
octets
LDP identifier
Router ID (IP address)
and Label Space ID
6
Length
Excludes type
and length
ID
octets
Parameters
Sequence
number
Mandatory
and optional
Label request
Label abort request
Label withdraw
Label release
Notification
Version 3.9.0a
Version 4.0.1
XMPLSTModule 2/33
337
MPLS LDP
Module 3
The LDP protocol involves the use of eleven (11) messages. These
messages can be categorized as:
338
Version 4.0.1
Module 3
Description
Message Type
Notification
Hello
Initialization
KeepAlive
Address
Address withdraw
Label mapping
Label request
Label withdraw
Label release
Version 3.9.0a
Version 4.0.1
XMPLSTModule 2/34
339
MPLS LDP
Module 3
340
CR-LDP
LC-ATM
Loop Detection
Version 4.0.1
Module 3
Version 3.9.0a
XMPLSTModule 2/36
Instructors Note
CR-LDPConstraint-based LDP contains extensions for LDP to extend its capabilities; allows
path setup beyond what is available for the routing protocol in traffic engineering. (deprecated; no
longer used)
LC-ATMLabel-controlled ATM is an MPLS interface in which labels are carried in the VPI or
VCI fields of the ATM cells; VC connections are established under the control of MPLS
Loop DetectionLDP relies on IGP loop prevention in the MPLS domain, not the TTL field in
the MPLS label.
Cisco IOS XR supports frame-mode MPLS (not LC-ATM*); routers running MPLS exchange
pure IP packets (PHP) and labeled IP packets with each other in an MPLS domain. Data link
layer connectivity in frame-mode MPLS can use HDLC/PPP, Ethernet, or ATM. In ATM Layer
2 cells are used to transport IP packets that also contain MPLS headers. With ATM links in MPLS
it is possible to have IP point-to-point links (routed PVCs). This is considered frame-mode MPLS
while the Layer 2 protocol is ATM.
2011 Cisco Systems, Inc.
Version 4.0.1
341
MPLS LDP
Module 3
Downstream Unsolicited
In the example topology in the lower figure, the LSRs are configured to use
the downstream unsolicited method of label advertisement.
LSRs B and C advertise their label information for destination P/n to
LSR A as soon as they are ready to do so. This is a result of the IGP route
distribution protocol detecting a route to the destination.
The notation P/n is shorthand for the IP address prefix representing a
network, subnet, supernet, or possibly even a host-specific destination. An
IP address prefix consists of an IP address and bit mask.
In this example, the LSD on LSR A would be populated with a label from
both peer LSRs.
342
Version 4.0.1
Module 3
Downstream Unsolicited
Upstream
LSR
Downstream
LSR
Ru
Rd
Label LX for
destination DY
Downstream Unsolicited:
B and C advertise P/n when ready to
label switch packets for P/n
Label Mapping (P/n, Lb)
Version 3.9.0a
XMPLSTModule 2/38
Prefix Peer
P/n
B
C
Label
Lb
Lc
Version 3.9.0a
Instructor's Note:
XMPLSTModule 2/39
Downstream On-Demand
Upstream
LSR
Downstream
LSR
Ru
Request
Rd
Label LX for
destination DY
Downstream on Demand (upstream controlled), is more complex and is typically used for ATM
networks. In the example, the downstream router Rd sends label-binding information only in
response to a request from its upstream neighbor Ru.
2011 Cisco Systems, Inc.
Version 4.0.1
343
MPLS LDP
Module 3
344
Version 4.0.1
Module 3
k1
Lin
R1
1
Lin
k3
R3
R4
Lin
k2
k4
Lin
R2
Version 3.9.0a
XMPLSTModule 2/40
Instructor's Note
R2 responds to request for R4 even if R4 has not yet responded to R2.
In ordered mode, the label setup is strictly sequenced. R2 now requests and receives a label from
R4 prior to returning a label response message to R1. Ordered mode is typically used for
downstream on-demand label distribution with ATM interfaces
k1
Lin
R1
Lin
k
R3
Lin
k
3
R4
R2
k4
Lin
2
Version 4.0.1
345
MPLS LDP
Module 3
Each LSR stores all received labels in its LIB; including labels not
received from a next-hop LSR
346
Version 4.0.1
Module 3
Version 3.9.0a
XMPLSTModule 2/41
Instructor's Note
Briefly review the difference between the LIB and LFIB.
Version 4.0.1
347
MPLS LDP
Module 3
348
Version 4.0.1
Module 3
LDP Sessions
Topology
k1
Lin
R3
Session
over Link1
Lin
k3
R1
R4
Lin
k2
R2
R3
R1
k4
Lin
Session
over Link2
Session
over Link3
R4
R2
Session
over Link4
Label Spaces
Version 3.9.0a
Version 4.0.1
XMPLSTModule 2/42
349
MPLS LDP
Module 3
Link1 is POS
Link2 is PPP
Link3 is Ethernet
Observe that only one LDP session is established with a neighboring LSR,
because all interfaces are packet-based, and they will use the same
platform-wide label space.
_____________________________ Note _________________________
The label space format used is the type <LSR_id : label_space_id>
where label_space_id is 0 for platform wide label spaces, and a number
greater than zero for interface-specific label spaces.
__________________________________________________________________
350
Version 4.0.1
Module 3
Topology
Multiple links
Sessions
Link1
R1
R1
R2
Link2
R2
Link3
Label spaces
R1:0
Platform-wide
R2:0
Platform-wide
Instructor's Note
In the Mixed Topology figure below, the following relationships occur: Link 1 and 3 share a
platform-wide database; there is a unique session for each ATM link on each LSR; label space is
one per interface on each LSR for ATM interfaces.
Version 3.9.0a
XMPLST4Module 2/43
Mixed Topology
Topology
Link1
R1
ATM Link2
LDP sessions
Session over Link2
R2
R1
R2
Session over
Link1 and Link3
Link3
Label spaces
Interface-specific
(Link 2)
R1:1
R2:1
Interface-specific
(Link 2)
Platform-wide
R1:0
R2:0
Platform-wide
Version 4.0.1
Version 3.9.0a
351
XMPLST4Module 2/44
MPLS LDP
Module 3
352
Version 4.0.1
Module 3
!Label management
!Forwarding
Control plane
Data plane
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/46
353
MPLS LDP
Module 3
354
Version 4.0.1
Module 3
RP or DRP
OSPF
LC-CPU
RIP
ISIS
AIB
RIB
BCDL
BGP
LDP
LSD
Switch fabric
EIGRP
Static
routes
LC-HW
Ifmgr
Queries
BCDL
FIB
process
RSVP
Used by
NetIO
Version 3.9.0a
Version 4.0.1
Hardware
FIB
Software
FIB table
XMPLST4Module 2/47
355
MPLS LDP
Module 3
Enable targeted hellos, if necessary. There are four ways in which LDP
targeted discovery is enabled:
356
Version 4.0.1
Module 3
! Session parameters
" Security
" Timers
! Label management
" Allocation
" Inbound policies
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/49
357
MPLS LDP
Module 3
358
Version 4.0.1
Module 3
router(config)#
mpls ldp
:router(config)# mpls ldp
:router(config-ldp)# ?
backoff
Configure session backoff parameters
default-route
Enable MPLS forwarding for default route
describe
Describe a command without taking real actions
discovery
Configure discovery parameters
downstream-on-demand Downstream on demand label advertisement mode
explicit-null
Configure explicit-null advertisement
graceful-restart
Configure graceful restart feature
holdtime
Configure session holdtime
igp
Configure IGP related parameters
interface
Enable LDP on an interface and enter interface submode
label
Configure label allocation, advertisement, and acceptance
log
Configure logging of LDP events
neighbor
Configure neighbor parameters
nsr
Configure Non-Stop Routing
pwd
Commands used to reach current submode
redistribute
Redistribute information from routing protocols
router-id
Configure router Id
session
Configure session parameters
show
Show contents of configuration
signalling
Configure signalling parameters
2011, Cisco Systems, Inc. All rights reserved.
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/50
359
MPLS LDP
Module 3
Discovery hello timers determine the time interval for sending hello
messages and waiting to hear from a neighbor. The range is 1 to 65535
seconds, and 65535 means an infinite wait.
360
Holdtime interval is the time interval the router waits for a hello
from a discovered LDP neighbor; default is 15 seconds
Holdtime interval is the time interval the router waits for a hello
from a discovered targeted LDP neighbor; default is 15 seconds
Holdtime is the base for maintaining sessions with other LDP peers
when no messages are received. The default time is 180 seconds and
the range is 15 to 65535 seconds.
Version 4.0.1
Module 3
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/51
361
MPLS LDP
Module 3
362
Version 4.0.1
Module 3
Version 3.9.0a
XMPLST4Module 2/51
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/52
363
MPLS LDP
Module 3
Session Authentication
Each session between a router and its peers may be secured. Maintaining
session security is accomplished by establishing passwords between
neighbors. Authentication of peer sessions is discussed in this section.
364
Version 4.0.1
Module 3
Session Authentication
:router(config-ldp)#
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/56
365
MPLS LDP
Module 3
Label Filtering
This section discusses the allocation and filtering of LDP labels. Labels are
allocated locally and advertised to peers. The labels allocated and
advertised may be managed using filters. Likewise, labels received from
peers may also be managed using filters.
Faster convergence
The local label allocation policy controls allocation of local labels and
supersedes outbound label filtering rules. If no label is allocated none is
advertised.
The label allocate for <access-list | host-routes> command permits
control of allocated label prefixes based upon an ACL or host routes only.
366
Version 4.0.1
Module 3
Label Filtering
Saves
:router(config-ldp)#
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/58
367
MPLS LDP
Module 3
368
To disable label advertisement to all peers for all prefixes (if there are
no other conflicting rules) use the label advertise disable command
Version 4.0.1
Module 3
Label Filtering
Feature configuration:
:router(config-ldp)#
label advertise [ disable | for access-list [ to peer-acl ] | interface type interface-id ]
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/59
369
MPLS LDP
Module 3
370
Version 4.0.1
Module 3
Label Filtering
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/60
371
MPLS LDP
Module 3
Session Protection
LDP session protection is a feature to protect existing LDP (link-based)
sessions by means of a parallel source of targeted hellos towards the peer.
Overview
When a link flaps and comes back up, IP may converge before LDP. This
may result in an MPLS traffic loss until LDP converges. If a link flaps, the
LDP session also flaps due to loss of link hellos.
With session protection, an LDP session is kept alive and neighbor label
bindings are maintained when links are down. Upon reestablishment of
primary link adjacencies, LDP convergence is expedited, because it need
not relearn the neighbor label bindings.
The LDP session protection feature results in:
Fast convergence
372
Version 4.0.1
Module 3
Session Protection
Problem:
Targeted
hello
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/62
373
MPLS LDP
Module 3
374
Version 4.0.1
Module 3
Session Protection
:router(config-ldp)#
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/63
375
MPLS LDP
Module 3
The result of the command provides a display of the status of the targeted
hello session and configured information, in addition to other LDP session
parameters.
376
Version 4.0.1
Module 3
Session Protection
Up time: 00:04:23
LDP Discovery Sources:
Targeted Hello (1.1.1.1 -> 3.3.3.3, active)
Addresses bound to this peer:
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/64
377
MPLS LDP
Module 3
LDP communicates this information to the IGP upon link up, or session
down events and IGP acts accordingly, depending on the synchronized
state.
With local LDP restart, (using IGP-sync and graceful restart) a recovered
LDP graceful restart session is used and treated as converged, and is given
an opportunity to connect and re-synchronize.
378
Version 4.0.1
Module 3
Problem:
Solution:
Version 3.9.0a
XMPLST4Module 2/67
Configure in
!Router mode
!Area submode
!Interface submode
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/68
379
MPLS LDP
Module 3
380
Version 4.0.1
Module 3
! Process mode
! Area submode
! Interface submode
:router(config-ospf)#
Version 3.9.0a
XMPLST4Module 2/70
:router(config-ospf)#
:router(config-ospf-ar)#
:router(config-ospf-ar-if)#
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/71
381
MPLS LDP
Module 3
382
Version 4.0.1
Module 3
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/72
383
MPLS LDP
Module 3
384
Version 4.0.1
Module 3
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/73
385
MPLS LDP
Module 3
386
Version 4.0.1
Module 3
:router(config-ldp)#
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/74
387
MPLS LDP
Module 3
Graceful Restart
LDP graceful restart provides a control plane mechanism to ensure high
availability; it allows detection and recovery from failure conditions, while
preserving nonstop forwarding (NSF) services.
Overview
Graceful restart is a way to recover from signaling and control plane
failures, without impacting forwarding. Without LDP graceful restart,
when an established session fails, the corresponding forwarding states are
cleaned immediately from the restarting and peer nodes. In that case, LDP
forwarding has to restart from the beginning, causing a potential loss of
data and connectivity.
The LDP graceful restart capability is negotiated between two peers during
session initialization time, using the fault tolerant session TLV (FT
SESSION TLV). In this TLV, an LSR advertises this information to its
peers:
Reconnect time: maximum time the peer should wait for this LSR to
reconnect after control channel failure before purging its state
Recovery time: maximum time that the peer has on its side to reinstate
or refresh its states with this LSR. This time is used only during
session reestablishment after earlier session failure
Once the graceful restart session parameters are conveyed, and the session
is up and running, graceful restart procedures are activated.
Cisco IOS XR operating system LDP is fully GR capable and supports both
local and peer restarts.
388
Version 4.0.1
Module 3
Graceful Restart
establishment phase
GR operational support modes
forwarding impact
Supports both capable and aware modes for local and peer
Version 3.9.0a
XMPLST4Module 2/76
Instructor's Note
Following a processor switchover, graceful restart and non-stop routing both allow for the
forwarding of data packets to continue along known routes, while the routing protocol
information is being restored (in the case of graceful restart) or refreshed (in the case of non-stop
routing). When GR is used, peer networking devices are informed, using protocol extensions
prior to the event, of the SSO capable routers ability to perform graceful restart. The peer device
must have the ability to understand this messaging. When a switchover occurs, the peer will
continue to forward to the router switching over, as instructed by the GR process for each
particular protocol, even though in most cases, the peering relationship needs to be rebuilt.
Essentially, the peer router gives the switching over router a grace period to re-establish the
neighbor relationship, while continuing to forward to the routes from that peer.
Version 4.0.1
389
MPLS LDP
Module 3
390
Version 4.0.1
Module 3
Graceful Restart
Version 4.0.1
391
MPLS LDP
Module 3
When the LDP control plane recovers, the restarting LSR starts its
forwarding state hold timer, and restores its forwarding state entries. This
action reinstates the forwarding state entries, and marks them as ^not
stale. The restarting LSR reconnects to its peer, indicating in the fault
tolerant session type length value (FT Session TLV), that it either, was or
was not, able to restore its state successfully. If it was able to restore the
state, the bindings are resynchronized.
Peer LSR
The peer LSR stops its neighbor reconnect timer (started at the time of
communication channel failure), when the restarting peer connects. It also
starts a neighbor recovery timer. The peer LSR checks the FT Session
TLV. If the restarting peer was able to restore its state successfully it
reinstates the corresponding forwarding state entries and receives
bindings from the restarting peer. When the recovery timer expires, any
forwarding state that is still marked as stale is deleted.
_____________________________ Note _________________________
If the restarting LSR fails to recover (restart), the restarting LSR
forwarding state and entries will eventually timeout and be deleted.
Neighbor-related forwarding states, or entries, are removed by the peer
LSR upon expiration of the reconnect or recovery timer.
__________________________________________________________________
392
Version 4.0.1
Module 3
Graceful Restart
Peer LSR
stopped
deleted
Version 3.9.0a
XMPLST4Module 2/78
Instructor's Note
Graceful restart also handles failures such as process restart.
Version 4.0.1
393
MPLS LDP
Module 3
This parameter is used to start a timer on the peer LSR (upon a neighbor
restart). This timer is typically referred to as the neighbor liveliness timer,
because it determines the length of time a neighbor waits to reconnect,
before declaring a graceful restart session as down.
Forwarding State Hold time
This timer specifies the length of time that stale LDP forwarding states
and rewrites are maintained in forwarding. When the forwarding state
hold time expires, any previously installed LDP forwarding state or rewrite
that has not been refreshed, is deleted from the forwarding table. The
forwarding state hold time encompasses local control plane restart and
recovery time.
Recovery Timeout
The recovery time sent to the peer LSR after restart. It is the current
remaining value of the forwarding state hold timer.
394
Version 4.0.1
Module 3
Graceful Restart
Reconnect-timeout
! Time restarting router wants neighbor to wait after LDP session
initially fails
Forwarding-state-holdtime
! Time it takes for the restarting router to complete its restart
process
Recovery timeout
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/79
395
MPLS LDP
Module 3
396
Version 4.0.1
Module 3
Graceful Restart
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/80
397
MPLS LDP
Module 3
Overview
LDP nonstop routing (NSR) functionality makes failures, such as route
processor (RP) or distributed route processor (DRP) failover, invisible to
routing peers with minimal or no disruption of convergence performance.
By default, NSR is globally enabled on all LDP sessions except AToM.
A disruption in service may include any of these events: Route processor
(RP) or distributed route processor (DRP) failover, LDP process restart, inservice system upgrade (ISSU), or minimum disruption restart (MDR).
_____________________________ Note _________________________
Unlike graceful restart functionality, LDP NSR does not require
protocol extensions, does not force software upgrades on other routers
in the network, and does not require peer routers to support NSR.
__________________________________________________________________
Graceful restart (GR) has some limitations or drawbacks:
Routing protocol extensions are needed, and interoperability issues can
exist between different equipment vendors
Timers may need to be adjusted to obtain optimal performance
Stale forwarding (headless forwarding) states, where forwarding
continues based on the last set of routing updates, which are not
updated until timers have expired and LDP updates have been
completed
_____________________________ Note _________________________
398
Version 4.0.1
Module 3
NSR solution
" Neighbors and protocol peers unaware of BGP, OSPF, IS-IS and LDP
Version 3.9.0a
XMPLST4Module 2/82
Instructor's Note
Graceful restart and non-stop routing suppress routing changes on peers to SSO-enabled devices
during processor switchover events, reducing network instability and downtime. SSO is necessary
to handle other non-routing protocol-related items needed for the router to operate, following a
switchover. These items include synchronizing the complete router configuration, CEF entries
and other information needed by the standby processor. Following a processor switchover,
graceful restart and non-stop routing both allow for the forwarding of data packets to continue
along known routes while the routing protocol information is being restored (in the case of
graceful restart) or refreshed (in the case of non-stop routing). When non-stop routing is used,
peer-networking devices have no knowledge of any event occurring on the router experiencing
switchover. All information needed to continue the routing protocol peering state is transferred to
the standby processor so it can pick up immediately upon a switchover. Unlike graceful restart,
non-stop routing uses more system resources due to the information transfer taking place to the
standby processor. Standards are not necessary in the case of non-stop routing, as the solution
does not require any additional communication with protocol peers.
Version 4.0.1
399
MPLS LDP
Module 3
SSO Functionality
Stateful Switchover (SSO) is required for both GR (NSF) and NSR across
RP and DRP failover.
Graceful restart and non-stop routing suppress routing changes to SSOenabled peer devices during processor switchover events. This results in
reduced network instability and downtime. With SSO, active and standby
RPs maintain non-routing protocol-related items needed for the router to
operate following a switchover. These items include:
3100
Version 4.0.1
Module 3
SSO Functionality
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/83
3101
MPLS LDP
Module 3
NSR is achieved because the LDP stack runs on both the active and
standby RP. The RPs collaborate with each other and with their respective
TCP stacks. LDP NSR functionality is based on three stages:
Once the new S-LDP becomes available again, the stacks go through the
synchronization and steady-state stages again to provide NSR capability.
3102
Version 4.0.1
Module 3
Without NSR
With NSR
To provide NSR
Version 3.9.0a
XMPLST4Module 2/85
" Re-sends its protocol updates (local label and addresses) to the peers
" Sends any pending updates and responses to peer
" Processes incoming messages and continues from where the previously A-LDP
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/86
3103
MPLS LDP
Module 3
3104
Hello adjacencies
Peer sessions
Peer label bindings
Peer address bindings
Version 4.0.1
Module 3
Active RP
Ifmg
ARM
RIB
r
Address
Route
Interface resolution
mgr
UDP
Discovery
hellos
table
LDP
Standby RP
LSD
Label forward
database
LDP sync
LDP
UDP
TCP sync
TCP
S-LDP standby capability: HOT (NSR configured), WARM (NSR not configured)
S-LDP connects to S-TCP to replicate NSR sessions and to perform I/O
S-LDP interacts with other collaborators (RIB, LSD, ARM, and IfMgr) to build its local state
A-LDP and S-LDP use asynchronous communication to synchronize LDP global and protocol
states
State synchronization is done at initial synchronization, and in steady state
LDP state includes:
Hello adjacencies, peer sessions, peer label bindings, peer address bindings
2011, Cisco Systems, Inc. All rights reserved.
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/87
3105
MPLS LDP
Module 3
NSR Configuration
LDP NSR is enabled globally under LDP. Enabling LDP NSR does not
cause the LDP session to flap; it causes the standby RP (DRP) to
synchronize to the active RP (DRP) by replicating the session to the
standby-LDP process.
The LDP configuration command log nsr supports the logging of LDP NSR
synchronization events.
3106
Version 4.0.1
Module 3
NSR Configuration
nsr
log nsr
:router# show log | incl ldp
mpls_ldp[281]:%ROUTING-LDP-5-NSR_SYNC_START:Initial synch started for
1 peer
mpls_ldp[281]:%ROUTING-LDP-5-NSR_SYNC_PEER:Peer 2.2.2.2:0 initial
synch done
mpls_ldp[281]:%ROUTING-LDP-5-NSR_SYNC_DONE:Initial synch success done
1 peer
2011, Cisco Systems, Inc. All rights reserved.
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/88
3107
MPLS LDP
Module 3
Overview
The pseudowire emulates a point-to-point or point-to-multipoint
link. It provides a single service that is perceived as an unshared link or
circuit. The emulation need only be sufficient for the satisfactory
operation of the service. PWE3 operates "edge to edge" and will not exert
control on the underlying PSN, other than to use any existing QoS or
path control mechanism to provide the required connectivity
between the endpoints of the PW.
LDP is also used to carry L2VPN signaling for Layer2 (PW) FEC. LDP plus
L2VPN and AToM implement the PW signaling protocol described in the
IETF PWE3 control protocol. PW setup and maintenance using LDP is
described in these RFCs:
3108
Version 4.0.1
Module 3
Attachment
circuit
Pseudowire
PSN tunnel
MPLS/IP
network
P routers
CE1
PE1
PE2
CE2
LDP PW session
2011, Cisco Systems, Inc. All rights reserved.
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/90
3109
MPLS LDP
Module 3
3110
Session request: Open and CloseLDP messages are used to set up,
maintain, and tear down sessions with remote PEs for AToM
pseudowires. LDP messages also handle PW label and notification
messages
Version 4.0.1
Module 3
PW label
PWid FEC element
PW interface parameter
PW error status code
PW status negotiation
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/91
3111
MPLS LDP
Module 3
Hybrid LDP sessions between directly connected PEs (IPv4 and PW)
events include:
3112
Version 4.0.1
Module 3
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/92
3113
MPLS LDP
Module 3
3114
Version 4.0.1
Module 3
mpls ldp
The process should be in RUN state. No thread should be in mutex for long time.
View the threads with show process thread jid
For targeted sessions over TE tunnels verify
Tunnel head is in show mpls interfaces
Tunnel tail mpls ldp discovery targeted-hello accept is configured
Does LDP have a reachable LDP id?
Displayed in show mpls ldp discovery and show mpls ldp parameter
If the router ID shows as 0.0.0.0 check the configuration
Is the peer session up? show mpls ldp neighbor brief
Needs both udp and tcp connectivity
Check the up time to gauge stability
Configure mpls ldp log neighbor to monitor flaps
Verify IP connectivity in routing table, with ping
2011, Cisco Systems, Inc. All rights reserved.
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/94
3115
MPLS LDP
Module 3
Additional Considerations
RP or DRP Failover
Even if graceful restart is configured, the LDP session may flap. MPLS
LDP sessions are dependent on the underlying TCP socket between the
peers. When an RP fails over, TCP restart and LDP restart occurs, the
TCP socket is lost resulting in a session flap. With the mpls ldp gracefulrestart command configured, the forwarding state is preserved for a
period of time, while the session is being re-established.
MPLS GR also requires IGP graceful restart to prevent traffic loss. That is,
traffic forwarding will continue while routes are marked stale, and then
restored, as long as communication with the neighboring router is
reestablished within timer limits.
Explicit Router-ID Configuration
Inbound label filtering is used when you have no control over the neighbor
router because it is in a different management domain. Modifying inbound
filters to accept bindings (associated with prefixes) from a neighbor
requires that you reset the MPLS LDP neighbor, because LDP does not
request a resend of bindings previously discarded by an ACL. However,
when altering a filter to reject previously-accepted bindings, it is not
necessary to clear the neighbor connection.
3116
Version 4.0.1
Module 3
Additional Considerations
On RP (DRP) failover
s previously
discarded by an ACL
This action not required to transition from accepting to
rejecting a binding
! Just starts discarding
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/95
3117
MPLS LDP
Module 3
Displays discovery, hello info for both link & targeted: tx, rx,
params, timers, stats Areas: Discovery, Session
Displays LDP NSR global and per-session info: sync, stats, status
Areas: NSR, Session/Discovery
show mpls ldp param Displays LDP global params: confg, in-use
System
Areas: Process,
3118
Version 4.0.1
Areas: Scale
Module 3
Displays discovery, hello info for both link & targeted: tx, rx, params, timers, stats
Areas: Discovery, Session
Displays LDP GR global and per-session info Areas: Session, GR, Forwarding
Displays LDP IGP Sync (global + per-intf) info Areas: IGP-Sync, Routing
Displays LDP peer information: TCP conn, discovery, addresses, stats, timers,
features (GR, NSR, SP) and so on
Areas: Discovery, Session, GR, NSR, Session Protection, Forwarding (nexthop addr)
Displays LDP NSR global and per-session info: sync, stats, status
Areas: NSR, Session and Discovery
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/96
3119
MPLS LDP
Module 3
Summary
MPLS LDP
In this module, you learned to:
3120
Version 4.0.1
Module 4
MPLS Layer 3 Virtual Private Networks
Overview
Description
This module provides information about the operation, configuration,
management, and troubleshooting of Layer 3 Virtual Private Networks for
intranets and extranets.
Objectives
After completing this module, you will be able to:
Version 4.0.1
41
Module 4
MPLS L3VPNs
Because privacy is essential for delivering IP services, you need a very
efficient, scalable, and flexible delivery scheme.
The problem with traditional overlay schemes is that they require you to
create tunnels between endpoints. Not only does this limit connectivity, QoS
options, and bandwidth efficiency, it also requires a new network design for
each customer. Adding new services is also a challenge, since you are selling
connections, not networks.
In contrast, leveraging MPLS allows you to build a VPN-based on networks,
not connections. This makes it easy to add valuable services such as content
hosting, or implement IP multicast for multimedia services. MPLS enables
connectionless IP VPNs with multiple service classes and the same privacy
as Frame Relay.
Not only do VPN-aware networks scale to large VPNs and large numbers of
VPNs, it allows you to provision all customer VPNs over a single network,
eliminating per-customer network design.
42
Version 4.0.1
Module 4
VoIP
networks
Support secure communications
!
!
!
Hosting
Intranet
Multicast
Extranet
!
!
!
!
!
!
Version 4.0.1
43
Module 4
VPN Models
The figures show two different service provider backbones with many
customer sites around the edge.
In the overlay model, VPNs connect customers to each other. Each customer
communicates only with a cloud with a similar alphabetic label (for example,
A to A). The exception is D, which connects to both A and B customer sites.
The connections are similar to emulated leased lines. The customer routers
exchange topology information over emulated lines.
In the peer-to-peer model, the customer router (CE) shares its routing
information with the provider router (PE). The provider network is used
more efficiently to route VPN traffic, based on its own network knowledge.
44
Version 4.0.1
Module 4
VPN Models
Provider
backbone
C
Peer-to-peer model
Provider
backbone
Overlay model
Version 4.0.1
45
Module 4
VPN Topologies
There are several types of VPN topologies that have been developed over
time. Here is a brief description of the three most typical types.
Overlay types
The most common of topology is hub and spoke with a central site connected
to remote sites. Typically, the central site communicates with the remote
sites, and some remote sites may communicate with other remote sites. This
topology is generally used in enterprises with a hierarchical structure, such
as banks, governments, retail outlets, and so on.
Full or partial mesh topologies are used by enterprises with less strict
structures. These topologies are generally determined by traffic flow.
The hybrid topology is typically a blend of hub and spoke with partial mesh.
Peer-to-peer types
These types of topologies may take the form of extranets, where different
companies connect their networks for the purpose of exchanging data, but
with security being of utmost importance.
The central services type is one in which enterprise networks may be
connected for the purpose of sharing some service. Supply chain
management is an example of this type of topology.
Special purpose types
46
Version 4.0.1
Module 4
VPN Topologies
Overlay types:
Peer-to-peer types:
Special purpose:
! VPDN
! Managed network
Version 4.0.1
47
Module 4
The customer routers (CE) should run standard IP routing software and
not be MPLS VPN-aware
The provider core routers (P) must not carry VPN routes to make the
MPLS VPN solution scalable
The provider edge routers (PE) must support MPLS VPN services and
traditional Internet services
P Router
P routers run only a backbone IGP with other P routers and with PE routers,
exchanging core subnet information. BGP deployment on P routers is not
required for MPLS VPN operation.
PE Router
PE routers peer with CE routers using BGP. The PE routers peer with each
other to facilitate exchange of VPN information.
CE Router
The MPLS VPN backbone should look like a standard corporate backbone to
the CE routers. The CE routers run standard IP routing software and
exchange routing updates with the PE routers that appear as normal routers
in the customer network.
Virtual routing and forwarding instance (VRF)
48
Version 4.0.1
Module 4
Routing Requirements
Customer routers (CE routers) run standard IP routing
protocol
Version 4.0.1
49
Module 4
410
Version 4.0.1
Module 4
PE
PE
VPN Backbone IGP
P
P
MP-iBGP Session
PE Routers
Edge routers
Connect to both CE and P routers
!
!
P Routers
In the core of the MPLS cloud
Do not need to run BGP and do not
Instructor's Note
Slide animation: starts with picture, PE and P routers headings and P and PE share ; click 1
PE routers bullet 1; click 2 PE routers bullet 2 and sub-bullets; click 3 PE routers last bullet;
click 4 P router bullets 1; click 5 P routers bullet 2; click 6 P routers bullet 3
2011 Cisco Systems, Inc.
Version 4.0.1
411
Module 4
412
Version 4.0.1
Module 4
CE
VPN blue
PE
VPN green
CE
Default VRF
!
!
Version 4.0.1
eBGP
Static
OSPF
EIGRP
RIPv2
413
Module 4
414
Version 4.0.1
Module 4
CE
VPN blue
PE
VPN green
CE
!
!
!
!
Version 4.0.1
415
Module 4
416
Version 4.0.1
Module 4
PE
PE
MPLS Backbone IGP (OSPF, ISIS)
!
!
PE route propagation
!
!
Version 4.0.1
417
Module 4
418
Version 4.0.1
Module 4
CE
VPN blue
CE
PE
VPN blue
PE
MPLS Backbone IGP (OSPF, ISIS)
VPN green
VPN green
CE
CE
Data flow
Version 4.0.1
419
Module 4
420
Version 4.0.1
Module 4
3 bytes
8 bytes
Label
RD
4 bytes
8 bytes (each)
10.1.1.0
IPv4
prefix
Route targets
MP_REACH_NLRI attributes
Relevant fields in MP-iBGP update message
Label
VPNv4 route
Instructor's Note
The label in this diagram is only 3 bytes long. The label is usually 4 bytes long. The usual label
consists of 20 bits of label, 3 bits for class of service, 1 stack bit, and 8 bits of time-to-live (TTL).
The picture above does not consider the TTL bits.
2011 Cisco Systems, Inc.
Version 4.0.1
421
Module 4
422
Version 4.0.1
Module 4
3 bytes
Label
8 bytes
4 bytes
65001:1
10.1.1.0
RD
IPv4
prefix
8 bytes
Route targets
VPNv4
MP_REACH_NLRI attributes
Version 4.0.1
423
Module 4
424
Version 4.0.1
Module 4
3 bytes
8 bytes
65001:1
Label
RD
4 bytes
8 bytes
10.1.1.0
65001:2
IPv4
prefix
Route targets
VPNv4
MP_REACH_NLRI attributes
Route-target
Version 4.0.1
425
Module 4
426
Version 4.0.1
Module 4
3 bytes
8 bytes
50
65001:1
Label
RD
4 bytes
8 bytes
10.1.1.0
65001:2
IPv4
prefix
Route targets
MP_REACH_NLRI attributes
Label for the VPNv4 prefix
Version 4.0.1
427
Module 4
428
Version 4.0.1
Module 4
MP-iBGP update:
RD:65001:1
Next-hop=PE1
RT=Green, Label=16100
Site 1
10.1.1.0/24
Site 2
CE1
10.1.1.0/24
Next-hop=CE1
CE2
PE1
PE2
MPLS backbone
Version 3.9.0a
XMPLST4Module 4/22
Instructor's Note
Slide animation: Starts with network drawing; Click 1 1st major bullet appears, followed by text
box under site 1, followed by arrow from CE1 to PE1; click 2 1st minor bullet; click 3 2nd
minor bullet; click 4 3rd minor bullet; click 5 4th minor bullet; click 6 2nd major bullet,
followed by text box containing MP-iBGP update, followed by arrow from PE1 to PE2
Version 4.0.1
429
Module 4
430
Version 4.0.1
Module 4
MP-iBGP update:
RD:65001:1
Next-hop=PE1
RT=Green, Label=16100
Site 1
10.1.1.0/24
10.1.1.0/24
Next-hop=PE2
CE1
10.1.1.0/24
Next-hop=CE1
Site 2
CE2
PE1
PE2
MPLS backbone
Version 3.9.0a
XMPLST4Module 4/24
Instructor's Note
Slide animation: Starts with network drawing with text box under Site 1 and MP-iBGP update;
Click 1 1st major bullet; click 2 1st minor bullet; click 3 2nd minor bullet; click 4 3rd minor
bullet; click 5 4th minor bullet, followed by text box next to Site 2, followed by arrow from PE2
to CE2
Version 4.0.1
431
Module 4
432
Version 4.0.1
Module 4
Site 2
Site 1
CE1
10.1.1.0/24
10.1.1.0/24
Next-hop=CE1
CE2
P2
P1
PE1
Default VRF
Dest.
Next-hop
PE2
P1
PE2
Default VRF
Dest.
Next-hop
PE1
P2
Label
16075
Default VRF
PE routers store IGP routes
Associated labels
Associated labels
Version 3.9.0a
Version 4.0.1
XMPLST4Module 4/25
433
Module 4
Adding detail to the forwarding example, PE2 imposes two labels on the
packets received from CE2 that have the 10.1.1.0/24 network as the
destination. The packet sent from CE2 for a device with the address of
10.1.1.1 arrives at PE2. PE2 assigns the inner MP-BGP label of 16100 for
the VPN destination as learned from the MP-BGP update for 10.1.1.0/24 and
allocated by PE1.
PE2 then assigns an LDP label of 16025 that represents the LSP path to the
BGP next hop. The BGP next hop is learned from the IGP that is employed
between the P and PE routers. In this example, router P2, which is the next
hop to reach PE1, assigns label 16025 and the packet is sent to P2. At P2,
the label of 16075 is swapped for the label 16025, and the packet sent on to
P1. P1 is the last router prior to the destination PE1 in this LSP or the
penultimate router. P1 removes the top label; an action called penultimate
hop popping (PHP), and sends the remaining packet with the VPN label to
PE1.
When PE1 receives the packet it performs a label, in this case for label
16100. The inner VPN label tells PE1 the packet is destined for 10.1.1.0 in
VRF green. PE1 places the packet on the interface to CE1.
434
Version 4.0.1
Module 4
Site 2
Site 1
CE1
10.1.1.0/24
16075
16100
10.1.1.1
16025
P1
16100
16100
10.1.1.1
CE2
P2
PE1
10.1.1.1
10.1.1.1
PE2
10.1.1.1
PE2 imposes TWO labels for each packet going to VPN destination
10.1.1.1
! Represents LSP to BGP next hop address; exit point of VPN route
Outer label is popped at P1 and packet with inner label is delivered to PE1
PE1 examines inner label for VPN assignment
Version 3.9.0a
XMPLST4Module 4/27
Instructor's Note
Slide animation: Click 1: textbox 10.1.1.1 from CE2-to-PE2 appears followed by arrow; click 2:
first bullet followed by textbox 10.1.1.1 above PE2; click 3: second bullet followed by 16100 label;
click 4: third bullet followed by 16025 label; click 5: fourth bullet appears; click 6: fifth bullet and
sub-bullet appear
2011 Cisco Systems, Inc.
Version 4.0.1
435
Module 4
Configuration Steps
Configuration of VPNs for customers in Cisco IOS XR includes both provider
edge and the core provider routers.
In the core, you define:
These are configured on the P routers and the PE routers for the interfaces
into the core.
On the PE routers, you configure:
A BGP connection from provider edge to provider edge (PE-to-PE) for the
VPN partnership
The routing protocols used in the core, typically either OSPF or IS-IS
The customer premises equipment must have a configuration for the routing
protocol to the PE.
Keep in mind that within Cisco IOS XR the key to connecting all the parts of
a VPN on a single PE router is the VRF name. While it is locally significant,
it must always be the same name in the same router. It is also case sensitive.
436
Version 4.0.1
Module 4
Configuration Steps
definition
" Define the address family
" Define the routes with the destination IPv4 address
On the CE:
! Case sensitive
Version 4.0.1
437
Module 4
438
Version 4.0.1
Module 4
10.1.1.0/24
CE3
PE3
172.16.130.3
Version 3.9.0a
XMPLST4Module 4/33
Instructor's Note
Animation: click 1 - Bullet 1; click 2 1st sub-bullet, then its sub-bullet; click 3 top CLI display
and arrow; click 4 2nd major bullet and sub-bullet; click 5 lower CLI display and arrow
Version 4.0.1
439
Module 4
440
Version 4.0.1
Module 4
10.1.1.0/24
CE3
172.16.130.33
PE3
172.16.130.3
Core network
!
!
Redistribution
!
!
!
Version 4.0.1
441
Module 4
nn 32-bit number
or
ip-address:nn IPv4 address in 32-bit form and a 16-bit number
Asplain format represents all the possible 4-byte AS numbers by decimal
integer notation. Asdot+ format represents the AS numbers using two
integer values joined with a period (.). Asdot format represents a mix of
asplain and asdot+. Cisco does not support asdot format (although the
documentation indicates it does). Asplain, asdot+, and asdot are defined in
IETF RFC 5396.
442
Version 4.0.1
Module 4
Customer network
Routing update
10.1.1.0/24
CE1
CE2
Routing update
10.1.1.0/24
PE2
PE1
MP-iBGP update
net=10.1.1.0/24
SOO=2:2 RT=2:2
MPLS backbone IGP (OSPF, ISIS)
Instructor's Note
Slide animation: 1st bullet, network drawing, routing updates without SoO all show initially; click
1 2nd bullet appears followed by red X emphasizing the advertisements being blocked on the
outbound side when SoO is employed; click 2 3rd bullet appears followed by CLI command.
Version 4.0.1
443
Module 4
The neighbor definition has the same format as the definitions for all other
BGP neighbors. For an eBGP definition, you include the remote autonomous
system number. Configure the address family using the address-family
ipv4 command. The address family support is configured to include inbound
and outbound route policies that are a requirement of eBGP neighbor
relationships. Without inbound and outbound route policies for an eBGP
neighbor, BGP updates are neither sent nor received.
The CUSTOMER3 inbound route policy looks like this:
route-policy CUSTOMER3
if destination in(10.1.1.0/24 le 32) then
pass
endif
end-policy
444
Version 4.0.1
Module 4
10.1.1.0/24
CE3
172.16.130.33
PE3
172.16.130.3
Version 4.0.1
445
Module 4
Configure a VRF for static routing using the same name as used in the
initial VRF configuration and configure the address family using the
address-family ipv4 command. Include the static IP addresses for the
networks that may be reached using the link to the CE in the address
family.
Redistribution into BGP
For MP-BGP to carry prefixes to other sites, add redistribution for the static
routes from the CE to the BGP configuration, as shown in this example:
router bgp 65001
vrf CE3
address-family ipv4 unicast
redistribute connected
redistribute static
446
Version 4.0.1
Module 4
10.1.1.0/24
CE3
172.16.130.33
PE3
172.16.130.3
Version 4.0.1
447
Module 4
Configure a VRF for RIP using the same name as used in the initial VRF
configuration and configure the address family using the address-family
ipv4 command. In RIPv2 configuration, add the interface type going to the
CE. Lastly, redistribute the BGP routes that are received from the other
VPN sites into RIP VRF so they may be advertised to the CE.
Redistribution into BGP
Add redistribution for RIP prefixes advertised from the CE to the BGP
configuration, as shown here:
router bgp 65001
vrf CE3
address-family ipv4 unicast
redistribute rip
448
Version 4.0.1
Module 4
10.1.1.0/24
CE3
172.16.130.33
PE3
172.16.130.3
Version 4.0.1
449
Module 4
450
Version 4.0.1
Module 4
10.1.1.0/24
CE3
172.16.130.33
PE3
172.16.130.3
Version 3.9.0a
Version 4.0.1
XMPLST4Module 4/40
451
Module 4
To identify the source of routing updates within EIGRP, use the router-id
command. To maintain consistency and linkage for the configuration, the
interface that is used between the PE and the customer router must also be
included in the EIGRP VRF configuration. Use the redistribute bgp
command to include the prefixes received from the other partners in the
VPN.
Redistribution into BGP
452
Version 4.0.1
Module 4
10.1.1.0/24
CE3
172.16.130.33
PE3
172.16.130.3
10.3.3.3
!
!
!
!
!
!
Define the address family; EIGRP supports only IPv4 and IPv6
Define an autonomous system number for the EIGRP process running
within the VRF
Define the router ID
Define the metric
Define the interface used to reach the CE
Redistribute the relevant BGP prefixes
Version 4.0.1
453
Module 4
Configure a VRF for OSPF using the same name as used in the initial VRF
configuration. OSPF requires the router ID be configured within the VRF.
Use the router-id CLI command. For the prefixes from the partners in the
VPN to reach this customer router, redistribute the BGP prefixes into the
OSPF VRF with the redistribute bgp autonomous-system-number
command (the autonomous-system-number is that of the BGP instance
running on this router).
Configure the Area
Within the VRF, you define the area that will be used for the interface to the
CE, and then configure the interface in the area.
Redistribution into BGP
454
Version 4.0.1
Module 4
10.1.1.0/24
CE3
172.16.130.33
PE3
172.16.130.3 10.3.3.3
Version 4.0.1
455
Module 4
You turn on MPLS with the MPLS LDP command discussed in an earlier
module in this course. You configure router ID, hello timers, interfaces,
neighbor security, and any other requirements as defined by your operation.
OSPF Configuration
For your OSPF configuration for the core you include such parameters as
router ID, areas, interfaces to be included, and other parameters as may be
required by your operation.
IS-IS Configuration
For your IS-IS configuration for the core you include such parameters as
level type, NSAP ID, interfaces, address families, and other parameters as
may be required by your operation.
456
Version 4.0.1
Module 4
P
10.1.1.0/24
10.1.1.1
CE3
POS0/3/0/1
10.3.3.3
PE3
GigE0/4/0/1
P
10.2.2.2
Examples of configuration of MPLS LDP and IGP for PE core side operations
Version 4.0.1
457
Module 4
Based on the route reflector update method, the address family VPNv4 is
defined in the neighbor definition. The only neighbors that are defined in
iBGP clients, such as the PEs, are the route reflectors.
Route Reflector
On the route reflector, all neighbors are identified as clients by using the
parameter route-reflector-client command. This command is included in
all the address families that are defined for the particular client. So if you
are creating VPNs, and want the advertisements going to other clients from
the route reflector, you must include the command in the VPNv4 address
family definition as shown in the illustration.
458
Version 4.0.1
Module 4
PE: MP-iBGP
PE3
10.3.3.3
RR
10.1.1.1
PE6
RR: MP-iBGP
PE3
10.3.3.3
RR
10.1.1.1
PE6
Version 4.0.1
459
Module 4
detail
Detailed information
ipv4
IPv4 information
ipv6
IPv6 information
unresolved
Unresolved VRFs
460
detail
Detailed information
multicast
Multicast information
safi-all
unicast
Unicast information
unresolved
Unresolved VRFs
Version 4.0.1
Module 4
RT
import
export
65001:6
65001:3
AFI
SAFI
IPV4
IPV4
Unicast
Unicast
Version 4.0.1
461
Module 4
462
A.B.C.D/length
afi-all
backup
Backup paths
best-local
Best Local
bgp
connected
Connected
eigrp
Enhanced IGRP
ipv4
IPv4 commands
ipv6
IPv6 commands
isis
ISO IS-IS
local
Local
next-hop
Route next-hop
ospf
quarantined
looping routes
resolving-next-hop
Next Hop
rip
standby
static
Static routes
summary
Version 4.0.1
Module 4
Version 4.0.1
463
Module 4
464
Prefix Mask
Interfaces
adjacency
bgp-attribute
detail
drops
exact-route
exceptions
external
flags
interface
ipv4
ipv6
non-recursive
recursive-nexthop
summary
trace
Version 4.0.1
Module 4
Version 4.0.1
465
Module 4
Additional Information
Forwarding information
label
Label information
lsd
table
Local labels
466
application
Owner application
detail
Detailed information
label
private
Private information
summary
Summary
Version 4.0.1
Module 4
State Rewrite
------ ------InUse Yes
InUse
Yes
InUse
Yes
InUse
Yes
InUse
Yes
InUse
No
InUse
No
InUse
No
Version 4.0.1
467
Module 4
468
Version 4.0.1
Module 4
BGP
prefix
table
Version 4.0.1
469
Module 4
470
Version 4.0.1
Module 4
RcvTblVer
4
bRIB/RIB
4
LabelVer
4
Spk
AS MsgRcvd MsgSent
0 65003
107
104
ImportVer
4
TblVer
4
Version 4.0.1
SendTblVer
4
StandbyVer
0
St/PfxRcd
3
471
Module 4
472
advertised
attribute-key
community
convergence
dampened-paths
inconsistent-as
labels
neighbors
nexthops
nsr
BGP nsr
rd
route-policy
summary
vrf
Version 4.0.1
Module 4
RcvTblVer
50
Spk
0
0
0
0
0
bRIB/RIB
50
LabelVer
50
AS MsgRcvd MsgSent
65001
19873
19881
65001
19891
19894
65001
19891
19898
65001
19895
19894
65001
19898
19900
ImportVer
50
TblVer
0
0
50
50
50
Version 4.0.1
SendTblVer
50
StandbyVer
0
473
Module 4
474
Version 4.0.1
Module 4
Version 4.0.1
475
Module 4
476
Version 4.0.1
Module 4
Version 4.0.1
477
Module 4
478
A.B.C.D or X:X::X
detail
Detailed information
missing-eor
nsr
performance-statistics
standby
Version 4.0.1
Module 4
Version 4.0.1
479
Module 4
detail
Detailed information
exact-route
interface
labels
prefix
private
summary
Summarized information
tunnels
Tunnel(s) at head
vrf
480
debug
detail
Detailed information
hardware
location
Specify a location
no-counters
prefix
private
Version 4.0.1
Module 4
Next Hop
Bytes
Switched
--------------- ------------
172.16.30.33
172.16.30.33
172.16.30.33
0
0
0
0
Bytes
Switched
-----------0
0
16015
Unlabelled 10.250.0.0/16[V]
PO0/3/0/0
Updated Jul 7 14:15:21.951
MAC/Encaps: 4/4, MTU: 4470
Label Stack (Top -> Bottom): { Unlabelled }
Packets Switched: 0
172.16.30.33
16016
Unlabelled 30.0.0.0/16[V]
PO0/3/0/0
Updated Jul 7 14:15:21.951
MAC/Encaps: 4/4, MTU: 4470
Label Stack (Top -> Bottom): { Unlabelled }
Packets Switched: 0
172.16.30.33
Version 4.0.1
481
Module 4
482
Version 4.0.1
Module 4
192.168.23.2
192.168.12.1
192.168.16.6
172.16.60.66
Version 4.0.1
483
Module 4
Route distinguisher to provide a unique identity for the VPN prefixes and
to allow for potential overlapping private addresses
The illustration shows the intranets that you created during the last lab and
which we can use as a base for showing how to create extranet VPNs.
_____________________________ Note _________________________
While the illustration on the adjacent page is in black and white, the
configurations (on the presentation slide) are color-coded with PE3 green,
PE4 blue, PE5 red, and PE6 orange to identify the VPNs they use for the
CEs with which they are directly connected.
__________________________________________________________________
Now we want to extend our VPN capability to partners, or other customers
with whom we may do business. Neither the customer nor we want to reveal
all of our networks to each other, but we do want to establish a private
network that benefits us and enhances each others business. It is worth
noting, that in extranet VPNs, the participants must have unique IP
addresses for successful communication. The separation inside the MPLS
L3VPN with the RD, does not remove this end-to-end requirement.
484
Version 4.0.1
Module 4
VRF definition
Route distinguisher
Export route target
Import route target
VPN definition:
RD: 65001:3
RT: Export 65001:3
Import 65001:6
CE3
CE4
VPN definition:
RD: 65001:5
RT: Export 65001:5
Import 65001:4
PE3
P1
PE5
CE5
PE4
P2
PE6
CE6
VPN definition:
RD: 65001:4
RT: Export 65001:4
Import 65001:5
VPN definition:
RD: 65001:6
RT: Export 65001:6
Import 65001:3
Version 4.0.1
485
Module 4
486
Version 4.0.1
Module 4
VPN definition:
RD: 65001:3
RT: export 65001:3
import 65001:6
import 65001:4
CE3
CE4
VPN definition:
RD: 65001:5
RT: export 65001:5
import 65001:4
import 65001:6
PE3
P1
PE5
CE5
PE4
P2
PE6
CE6
VPN definition:
RD: 65001:4
RT: export 65001:4
import 65001:5
import 65001:3
VPN definition:
RD: 65001:6
RT: export 65001:6
import 65001:3
import 65001:5
Version 4.0.1
487
Module 4
488
Version 4.0.1
Module 4
VPN definition:
RD: 65001:3
RT: export 65001:3
import 65001:6
import 65001:43
CE3
PE3
P1
PE5
CE5
PE4
P2
PE6
CE6
Route policy:
Add extcommunity
RT of 65001:34
CE4
VPN definition:
RD: 65001:4
RT: export 65001:4
import 65001:5
import 65001:34
Use route policy to set additional route target for extranet VPN
Apply the policy to the VRF definition for the CE as an export route policy
Version 4.0.1
489
Module 4
490
Version 4.0.1
Module 4
10.1.103.0/24
CE3
PE3
172.16.130.3
Version 4.0.1
491
Module 4
492
Version 4.0.1
Module 4
10.1.103.0/24
CE3
PE3
172.16.130.3
Version 4.0.1
493
Module 4
494
Version 4.0.1
Module 4
RT
import
import
export
65001:6
65001:43
65001:3
AFI
SAFI
IPV4
IPV4
IPV4
Unicast
Unicast
Unicast
Version 4.0.1
495
Module 4
496
Version 4.0.1
Module 4
Note the route for the extranet partner now in the VRF CE3
routing table
Version 4.0.1
497
Module 4
498
Version 4.0.1
Module 4
Version 4.0.1
499
Module 4
Instructor's Note
If there is time during the lab, you may want to explore creating access from the intranet partner
(CE6) to the extranet partner (CE4).
4100
Version 4.0.1
Module 4
i
i
i
i
i
i
i
i
i
i
i
i
i
i
i
Version 4.0.1
4101
Module 4
4102
Version 4.0.1
Module 4
65003
65003
65004
?
65003
65003
65006
?
?
?
i
i
i
i
i
i
0 65004 i
0
0
0
0
0
?
65006 i
?
?
?
Intranet CE
Version 4.0.1
4103
Module 4
4104
Version 4.0.1
Module 4
nolabel
nolabel
nolabel
nolabel
nolabel
nolabel
Version 4.0.1
4105
Module 4
4106
Version 4.0.1
Module 4
Version 4.0.1
5 msec
3 msec
4107
Module 4
Summary
MPLS Layer 3 Virtual Private Networks
In this module, you learned to:
4108
Version 4.0.1
Module 5
MPLS Inter-AS L3VPN
Overview
Description
This module provides information about the operation, configuration,
management, and troubleshooting of Layer 3 Virtual Private Networks
across different autonomous systems (AS).
Objectives
After completing this module, you will be able to:
Version 4.0.1
51
Module 5
100% or full reachability for all Inter-AS VPNs, including control plane
and data plane
No reachability for VPNs that do not share control and data plane
If an SP has VPN sites in an Inter-AS set up, then the SP has full access to
all the VPN sites, including those in other AS.
52
Version 4.0.1
Module 5
Provider 1
RR1
P1
AS 65001
Provider 2
RR2
ASBR1
ASBR2
???
P2
AS 65002
VPN-v4 update::
PE1
PE2
CE1
CE2
Customer A
VPN-12
Customer A
VPN-12
149.27.2.0/24
Version 4.0.1
53
Module 5
In the rest of this module you learn about the operation of each of these
options and how to configure them in Cisco IOS XR software.
54
Version 4.0.1
Module 5
ASBR1 (PE)
Option A - Back-to-back VRFs
P2
P1
AS #1
AS #2
PE1
PE2
CE1
CE2
VPN-A
VPN-A
Version 4.0.1
55
Module 5
56
When creating route targets and route distinguishers you should use
your local AS number
When creating end-to-end VPNs, consider using limits on the PEs for
prefixes that may be installed in routing tables. These limits should
include both the BGP routing table and the individual VRFs
Version 4.0.1
Module 5
Version 4.0.1
57
Module 5
58
Version 4.0.1
Module 5
P1
P11
P22
P2
AS 65002
AS 65001
PE3
PE55
CE3
CE5
VPN-B
VPN-B
10.52.0.0/16
Customer prefix updates
VPNv4 prefix updates
IGP (IPv4) and LDP updates
eBGP updates in VRF
Version 4.0.1
59
Module 5
510
Version 4.0.1
Module 5
VPNv4 update:
RD:65001:15:10.31.13.0/24
NH=PE3
RT=65001:15, Label=(29)!
P1
VPN-B VRF
imports routes
with RT 65001:15!
VPN-B VRF
exports routes
with RT 65002:15!
P11
VPNv4 update:
RD=65002:15:10.31.13.0/24
NH=P11,RT=65002:15
Label=(92)!
P22
P2
AS 65001
PE3
AS 65002
BGP, OSPF, RIPv2
10.31.13.0/24 NH=P1!
CE3
PE55
CE5
VPN-B
VPN-B
10.31.13.0/24!
Version 3.9.0a
XMPLST4Module 5/10
Instructor's Note
Animation sequence: Click 1 box and arrow, CE3-to-PE3; click 2 box and arrow, PE3 P1;
click 3 box and arrow, P1; click 4 box and arrow P1 P11; click 5 box and arrow, P11;
click 6 box and arrow, P11 PE55; click 7 box and arrow, PE55 to CE5
Version 4.0.1
511
Module 5
512
Version 4.0.1
Module 5
30!
29!
P1
10.31.13.1!
P11
92!
10.31.13.1!
P22
P2
29!
10.31.13.1!
10.31.13.1!
AS 65001
AS 65002
PE3
10.31.13.1!
20!
92!
10.31.13.1!
PE55
CE5
CE3
VPN-B
P1 uses label=30 to
reach PE3
(learned using LDP)!
10.31.13.1!
VPN-B
PE55 uses label=20
to reach P11
(learned using LDP)!
10.31.13.0/24!
Version 3.9.0a
Version 4.0.1
XMPLST4Module 5/11
513
Module 5
514
Configure BGP neighbor relationship with the other ASBR and the
route policies that apply
Version 4.0.1
Module 5
P1
P11
P22
P2
AS 65001
PE3
2. Configure
and verify
VPNv4
AS 65002
CE3
PE55
CE5
VPN-B
VPN-B
10.31.13.0/24
Customer prefix updates
VPNv4 prefix updates
IGP (IPv4) and LDP updates
eBGP updates in VRF
Version 4.0.1
515
Module 5
516
Version 4.0.1
Module 5
P1
P11
.1
P2
192.168.1.0
.11
P22
POS0/3/1/2
PE3
Configure import
and export route
targets
AS 65002
AS 65001
CE3
PE55
:router(config)# vrf VPN1-11
:router(config-vrf)# address-family ipv4 unicast
:router(config-vrf-af)# import route-target 65001:35
:router(config-vrf-af)# export route-target 65001:53
CE5
VPN-B
VPN-B
10.31.13.0/24
Version 4.0.1
517
Module 5
For the BGP configuration create the VRF (VPN1-11 in the illustration).
Then define the eBGP neighbor as a part of the VPN. Remember that with
Cisco IOS XR software both an inbound and outbound route-policy is
required for any eBGP neighbor relationship defined.
The route policy defined in this illustration is very simple example:
route-policy PASS-ALL
pass
route-policy end
This route policy allows all prefixes to be advertised to and received from
the defined neighbor.
The number of prefixes received from a neighbor may be limited, if needed,
by using the following command:
518
Version 4.0.1
Module 5
P1
P11
.1 192.168.1.0 .11
P2
P22
POS0/3/1/2
AS 65002
AS 65001
PE3
PE55
Version 4.0.1
519
Module 5
520
Version 4.0.1
Module 5
P1
P2
PE3
P11
192.168.1.0 .11
.1
P22
AS 65002
AS 65001
i
i
i
i
i
i
i
i
?
i
?
?
Version 4.0.1
521
Module 5
522
Version 4.0.1
Module 5
P1
P2
PE3
P11
192.168.1.0 .11
.1
P22
AS 65002
AS 65001
PE55
Path
0
0
0
0
0
0
?
?
?
?
?
?
0
0
0
0
0
0
65001 65003 i
65001 65003 i
?
65001 65003 i
?
?
Version 4.0.1
523
Module 5
524
Version 4.0.1
Module 5
P1
P11
.1 192.168.1.0 .11
P2
AS 65002
AS 65001
PE3
P22
PE55
:pe55# show bgp vpnv4 unicast
CE5 Weight Path
Network CE3
Next Hop
Metric LocPrf
Route Distinguisher: 65002:5 (default for vrf CE5)
*>i10.31.13.0/24
10.1.1.11
100
0 65001
*>i10.31.103.0/24
10.1.1.11
100
0 65001
*>i30.0.0.0/9VPN-B
10.1.1.11
100
0 65001
VPN-B
*> 10.52.0.0/16
0
32768 ?
152.12.4.0/24 0.0.0.0
*> 50.0.0.0/9
0.0.0.0
0
32768 ?
*> 50.128.0.0/9
0.0.0.0
0
32768 ?
Route Distinguisher: 65002:111
*>i10.31.13.0/24
10.1.1.11
100
0 65001
* i
10.1.1.11
100
0 65001
*>i10.31.103.0/24
10.1.1.11
100
0 65001
* i
10.1.1.11
100
0 65001
*>i30.0.0.0/9
10.1.1.11
100
0 65001
* i
10.1.1.11
100
0 65001
65003 i
65003 i
65003 I
65003
65003
65003
65003
65003
65003
i
i
i
i
i
i
Version 4.0.1
525
Module 5
526
Version 4.0.1
Module 5
P2
P22
P1
P11
AS 65001
LDP
PE4
AS 65002
LDP
PE66
CE6
CE4
VPN-B
VPN-B
10.41.14.0/24!
Version 3.9.0a
Version 4.0.1
XMPLST4Module 5/21
527
Module 5
528
Version 4.0.1
Module 5
VPNv4 update:
RD=65001:11:10.41.14.0/24
NH=PE4
RT=65001:11 Label=(40)!
P2
VPNv4 update:
RD=65001:11:10.41.14.0/24
NH=P22
RT=65001:11 Label=(30)!
P22
P11
P1
AS 65001
LDP
PE4
VPNv4 update:
RD:65001:11:10.41.14.0/24,
NH=P2
RT=65001:11, Label=(20)!
AS 65002
LDP
CE6
CE4
VPN-B
PE66
BGP, OSPF, RIPv2
10.41.14.0/24,
NH=PE66!
VPN-B
10.41.14.0/24!
Version 3.9.0a
XMPLST4Module 5/23
Instructor's Note
Animation: click 1 box and arrow, CE4-PE4; click 2 box and arrow, PE4-P2; click 3 box
and arrow, P2-P22; click 4 box and arrow, P22-PE66; click 5 box and arrow, PE66-CE6
Version 4.0.1
529
Module 5
530
Version 4.0.1
Module 5
30!
40!
30!
10.41.14.1!
P2
10.41.14.1!
P22
P11
P1
40!
10.41.14.1!
AS 65001
PE4
LDP
10.41.14.1!
P2 uses MP-BGP
label=40 for VRF and
LDP label=30 to reach
PE4!
AS 65002
20!
10.41.14.1!
20!
30!
10.41.14.1!
LDP
PE66
CE4
CE6
VPN-B
VPN-B
10.41.14.0/24!
10.41.14.1!
Version 3.9.0a
XMPLST4Module 5/25
Instructor's Note
Animation: click 1 address & arrow, CE6-PE66; click 2 labels, address, blue text & arrow,
PE66-P11; click 3 label, address, & arrow, P11-P22; click 4 label, address, & arrow, P22-P2;
click 5 blue text, labels, address, & arrow, P2-P1; click 6 label, address, & arrow, P1-PE4;
click 7 address & arrow, PE4-CE4
Version 4.0.1
531
Module 5
532
Version 4.0.1
Module 5
P22
P2
P1
P11
PE4
neighbor connection
2. Configure
and verify
VPNv4
AS 65002
LDP
PE66
CE6
CE4
VPN-B
VPN-B
10.41.14.0/24!
Version 3.9.0a
Version 4.0.1
XMPLST4Module 5/27
533
Module 5
534
Version 4.0.1
Module 5
P2
P22
.2
P1
192.168.2.0 .22
P11
POS0/3/1/2
PE4
Configure
route targets
AS 65001
LDP
AS 65002
LDP
PE66
:router(config)# router bgp 65001
:router(config-bgp)# address-family vpnv4 unicast
:router(config-bgp-af)# retain route-target all
CE6
CE4
Version 3.9.0a
Version 4.0.1
XMPLST4Module 5/28
535
Module 5
536
Version 4.0.1
Module 5
P22
P2
.2 192.168.1.0 .22
P1
P11
AS 65002
AS 65001
PE4
PE66
CE6
CE4
VPN-B
VPN-B
0
100
0
100
0
100
0
100
RD from AS 65002
0
0
0
0
65004 i
65004 i
65004 i
I
0 65002 ?
0 65002 ?
0 65002 ?
Version 3.9.0a
Version 4.0.1
XMPLST4Module 5/30
537
Module 5
538
Version 4.0.1
Module 5
P2
P22
.2
P1
192.168.2.0 .22
P11
AS 65002
AS 65001
PE4
PE66
CE6
CE4
VPN-B
Version 4.0.1
100
100
100
65004 i
65004 i
65004 i
I
0 ?
0 ?
0 ?
XMPLST4Module 5/31
539
Module 5
540
Version 4.0.1
Module 5
P22
P2
.2 192.168.2.0 .22
P1
P11
AS 65002
AS 65001
PE4
PE66
AS Path
CE6
CE4
65004 i
65004 i
65004 i
i
Version 3.9.0a
Version 4.0.1
XMPLST4Module 5/32
541
Module 5
ASBRs do the job of forwarding the VPN packets between each other, and
forwarding MPLS packets within their own AS.
542
Version 4.0.1
Module 5
Reflect
VPNv4
prefixes
RR1
P1
ASBR1
RR2
P2
ASBR2
AS #1
AS #2
PE1
PE2
CE1
CE2
VPN-B
VPN-B
152.12.4.0/24!
Version 3.9.0a
Version 4.0.1
XMPLST4Module 5/35
543
Module 5
These PE addresses exchanged are either the IGP plus LDP label or the
iBGP IPv4 address plus LDP label. If the IGP and LDP label is used, you
redistribute the IGP routes and labels into BGP and the BGP prefixes into
the IGP.
You attach a route policy to the redistribute command to manage the
addresses being advertised into the other AS. The addresses may be listed
in the route policy. Another option is to create a prefix-list that contains
only the loopback addresses of the PEs with VPN relationships in the other
providers network. Then you write a route policy to limit outbound
advertisements to the PEs and drop others.
Advertising PE addresses to another AS may not be acceptable to some
providers.
With Cisco IOS XR software, an eBGP peering requires a route policy.
Typically you use the same route policy as used when redistributing the
prefixes.
544
Version 4.0.1
Module 5
RR2
RR1
P1
AS #1
PE1
IGP+LDP:
NH=PE1
Label=(40)"
ASBR1
ASBR2
P2
AS #2
PE2
IGP+LDP:
NH=ASBR2
Label=(30)"
CE1
CE2
VPN-B
VPN-B
152.12.4.0/24"
!
!
Version 3.9.0a
XMPLST4Module 5/37
Instructor's Note
Animation: click 1 first text box, blue arrow, red arrow; click 2 second text box, blue arrow,
red arrow; click 3 third text box, blue arrow, red arrow.
Version 4.0.1
545
Module 5
546
Version 4.0.1
Module 5
RR1
ASBR1
P1
ASBR2
AS 65001
RR2
P2
AS 65002
PE2
PE1
BGP, OSPF, RIPv2
152.12.4.0/24, NH=CE1!
CE1
CE2
VPN-B
VPN-B
152.12.4.0/24!
Version 3.9.0a
XMPLST4Module 5/39
Instructor's Note
Animation: click 1 arrow from CE1 to PE1, text box; click 2 arrow from PE1 to RR1, text
box; click 3 arrow from RR1 to RR2, text box; click 4 arrow from RR2 to PE2, text box;
click 5 arrow from PE2 to CE2, text box
2011 Cisco Systems, Inc.
Version 4.0.1
547
Module 5
548
Version 4.0.1
Module 5
RR1
RR2
P2
P1
40!
90!
90!
152.12.4.1!
ASBR1
152.12.4.1!
ASBR2
30!
AS 65001
PE1
152.12.4.1!
90!
152.12.4.1!
20!
90!
152.12.4.1!
VPN-B
152.12.4.1!
PE2
CE2
CE1
90!
50!
AS 65002
152.12.4.1!
VPN-B
152.12.4.0/24!
Version 3.9.0a
XMPLST4Module 5/41
Instructor's Note
Animation: click 1 text box with 152.12.4.1 address, arrow from CE2 to PE2; click 2 text box
with address and MP-BGP (90) and LDP (50) labels, arrow from PE2 to P2; click 3 - text box
with address, MP-BGP and swapped LDP label, arrow from P2 to ASBR2; click 4 - text box with
address and labels, arrow from ASBR2 to ASBR1; click 5 - text box with address and labels, arrow
from ASBR1 to P1, click 6 text box with address and MP-BGP label only, arrow from P1 to
PE1; click 7 text box with address, arrow from PE1 to CE1
2011 Cisco Systems, Inc.
Version 4.0.1
549
Module 5
Using IGP plus labels and redistribution of BGP into the IGP on the
ASBR; this is the least preferred option
550
Configure and verify the eBGP connection between ASBRs. Create RPL
policy to limit advertisements to relevant loopback addresses
Version 4.0.1
Module 5
RR1
2. Configure VPNv4
P1
ASBR1
P2
ASBR2
AS #1
PE1
RR2
AS #2
CE1
VPN-B
PE2
CE2
1. Configure a VRF for
CE and peer with RR
152.12.4.0/24!
VPN-B
Version 3.9.0a
XMPLST4Module 5/44
Instructor's Note
Animation: click 1 first text box and arrows; click 2 second text box; click 3 third text box;
click 4 fourth text box
Version 4.0.1
551
Module 5
Option C: PE Configuration
On the PE a VRF is created for the VPN traffic. The VRF contains the
prefixes advertised by the local CE. When the configuration is completed
the VRF contains the prefixes advertised by the CE from the other AS.
The PE BGP configuration includes the address family VPNv4 unicast for
the VPN traffic. With option C, you configure a neighbor peering with the
route reflector. The configuration includes the IPv4 and VPNv4 unicast
prefixes. In this configuration a neighbor group is used to consolidate the
features.
neighbor-group iBGP
remote-as 65001
update-source loopback0
address-family ipv4 unicast
next-hop self
!
address-family vpnv4 unicast
552
Version 4.0.1
Module 5
Option C: PE Configuration
RR2
RR1
10.1.1.12
10.2.2.12
10.1.1.1
P1
AS 65001
10.1.1.11
ASBR1
10.1.1.2
.1
192.168.1.0
ASBR2
.11
10.2.2.2
10.2.2.1
AS 65002
10.2.2.11
PE1
CE1
VPN-B
152.12.4.0/24!
P2
PE2
CE2
Version 3.9.0a
Version 4.0.1
XMPLST4Module 5/45
553
Module 5
In this illustration, the update source has been set to Loopback0. In the
route reflector multiple loopback addresses may be defined, one for
internal AS use and the other for external AS use. The external loopback
address is typically an address from the SPs private address space. This
prevents the possibility of duplicate addresses. You use a network
statement in the IPv4 address family definition to define the host address
of the being used as the external address.
Exchanging VPNv4 prefixes between route reflectors in SP networks can
be problematic when a particular RR contains millions of prefixes. One
way to limit the potential for too many prefixes flooding the BGP RIB is to
use an RPL to limit them. In the illustration all prefixes are being passed.
The RR peering between the two AS is an eBGP peering. For that reason,
we add the next-hop-unchanged command to the address family
definition of the RR neighbor. Normally, route reflectors would not change
the next hop attribute by definition. However, because of the eBGP
relationship they would. This command prevents that.
next-hop-unchanged [inheritance-disable]
554
Version 4.0.1
Module 5
RR2
RR1
10..1.12
10.1.1.12
10.2.2.12
10.1.1.1
P1
AS 65001
10.1.1.11
ASBR1
10.1.1.2
.1
192.168.1.0
ASBR2
.11
10.2.2.2
10.2.2.1
AS 65002
10.2.2.11
PE1
P2
PE2
CE1
VPN-B
152.12.4.0/24!
Version 3.9.0a
Version 4.0.1
XMPLST4Module 5/46
555
Module 5
556
Version 4.0.1
Module 5
RR2
RR1
10.1.1.12
10.2.2.12
10.1.1.1
P1
AS 65001
10.1.1.11
ASBR1
10.1.11
10.1.1.2
.1
192.168.1.0
ASBR2
.11
10.2.2.2
10.2.2.1
AS 65002
10.2.2.11
PE1
CE1
VPN-B
152.12.4.0/24!
P2
PE2
VPN-B
Version 3.9.0a
Version 4.0.1
XMPLST4Module 5/47
557
Module 5
In our illustration we are distributing the prefixes into the IGP from BGP
and from BGP into the IGP.
The BGP configuration occurs in the address family definition at the router
BGP configuration level:
address-family ipv4 unicast
redistribute ospf lab metric 3333 route-policy OPT-C-RTRS-OUT
allocate-label route-policy OPT-C-RTRS-OUT
Note the use of the route policy to limit the actual prefix advertisements to
those received from certain routers.
The IGP redistribution for OSPF is illustrated here:
router ospf lab
redistribute bgp 65001 route-policy OPT-C-RTRS-IN
The redistribution into the IGP uses a route policy to limit the prefix
advertisements, too. The prefixes in this policy are those received from the
other AS.
558
Version 4.0.1
Module 5
RR2
RR1
10.1.1.12
10.2.2.12
10.1.1.1
P1
AS 65001
10.1.1.11
ASBR1
10.1.1.2
.1
192.168.1.0
ASBR2
.11
10.2.2.2
10.2.2.1
AS 65002
10.2.2.11
PE1
CE1
VPN-B
152.12.4.0/24!
P2
PE2
CE2
:ASBR1(config)# router bgp 65001
:ASBR1(config-bgp)# neighbor 192.168.1.11
:ASBR1(config-bgp-nbr)# remote-as 65002
VPN-B
:ASBR1(config-bgp-nbr)# description ASBR2 in AS 65002
:ASBR1(config-bgp-nbr)# address-family ipv4 unicast
:ASBR1(config-bgp-nbr)# address-family ipv4 labeled-unicast
:ASBR1(config-bgp-nbr-af)# route-policy PASS-ALL in
:ASBR1(config-bgp-nbr-af)# route-policy OPT-C-RTRS-OUT out
!
!
Version 3.9.0a
Version 4.0.1
XMPLST4Module 5/48
559
Module 5
560
Version 4.0.1
Module 5
P22
P2
PE
AS 65001
P1
.1
192.168.1.0
.11
P11
PE
AS 65002
PE55
PE3
CE3
CE5
RcvTblVer
5
bRIB/RIB
5
LabelVer
5
Spk
AS MsgRcvd MsgSent
0 65002
100
101
ImportVer
5
TblVer
5
SendTblVer
5
StandbyVer
5
St/PfxRcd
2
Version 3.9.0a
Version 4.0.1
XMPLST4Module 5/50
561
Module 5
562
Version 4.0.1
Module 5
P22
P2
PE
AS 65001
P1
192.168.1.0
.1
.11
P11
PE
AS 65002
PE55
PE3
CE3
CE5
Version 3.9.0a
Version 4.0.1
XMPLST4Module 5/51
563
Module 5
564
Version 4.0.1
Module 5
P22
P2
PE
AS 65001
P1
.1
192.168.1.0
.11
P11
PE
AS 65002
PE55
PE3
CE3
CE5
Version 3.9.0a
Version 4.0.1
XMPLST4Module 5/52
565
Module 5
566
Version 4.0.1
Module 5
P22
P2
PE
AS 65001
P1
192.168.1.0
.1
.11
P11
PE
AS 65002
PE55
PE3
CE3
CE5
Outgoing
Next Hop
Interface
------------ --------------PO0/3/1/2
192.168.1.11
Bytes
Switched
-----------10534
Version 3.9.0a
Version 4.0.1
XMPLST4Module 5/53
567
Module 5
568
Version 4.0.1
Module 5
P22
P2
PE
AS 65001
P1
.1
192.168.1.0
.11
P11
PE
AS 65002
PE55
PE3
CE3
:P2# show bgp vpnv4 unicast summary
Process
RcvTblVer
bRIB/RIB
Speaker
6
6
Neighbor
10.1.1.1
10.2.2.22
10.3.3.3
10.4.4.4
10.5.5.5
10.6.6.6
Spk
0
0
0
0
0
0
CE5
LabelVer
6
AS MsgRcvd MsgSent
65001
98
94
65002
95
95
65001
95
96
65001
95
94
65001
0
0
65001
95
95
ImportVer
6
TblVer
0
6
6
0
0
0
SendTblVer
6
StandbyVer
6
RR in AS
65002
Version 3.9.0a
Version 4.0.1
XMPLST4Module 5/54
569
Module 5
570
Version 4.0.1
Module 5
P22
P2
PE
AS 65001
P1
.1
192.168.1.0
.11
P11
PE
AS 65002
PE55
PE3
CE3
CE5
:P2# show bgp vpnv4 unicast
Status codes: s suppressed, d damped, h history, * valid, > best
i - internal, r RIB-failure, S stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network
Next Hop
Metric LocPrf Weight Path
Route Distinguisher: 65001:3
*>i10.31.13.0/24
10.3.3.3
0
100
0 65003 i
*>i10.31.103.0/24
10.3.3.3
0
100
0 65003 i
*>i30.0.0.0/9
10.3.3.3
0
100
0 65003 i
Route Distinguisher: 65002:55
*> 10.52.15.0/24
10.5.5.55
0 65002 ?
*> 50.128.0.0/9
10.5.5.55
0 65002 ?
Processed 5 prefixes, 5 paths
Additional output omitted
2011, Cisco Systems, Inc. All rights reserved.
Version 3.9.0a
Version 4.0.1
XMPLST4Module 5/55
571
Module 5
572
Version 4.0.1
Module 5
P22
P2
PE
AS 65001
P1
.1
192.168.1.0
.11
P11
PE
AS 65002
PE55
PE3
CE3
CE5
Version 3.9.0a
Version 4.0.1
XMPLST4Module 5/56
573
Module 5
574
Version 4.0.1
Module 5
P22
P2
PE
AS 65001
P1
.1
192.168.1.0
.11
P11
PE
AS 65002
PE55
PE3
CE3
CE5
RD
65001:3
RT
import
import
import
export
AFI
65001:6
65001:43
65002:55
65001:3
IPV4
IPV4
IPV4
IPV4
SAFI
Unicast
Unicast
Unicast
Unicast
Version 3.9.0a
Version 4.0.1
XMPLST4Module 5/57
575
Module 5
576
Version 4.0.1
Module 5
P22
P2
PE
AS 65001
P1
.1
192.168.1.0
.11
P11
PE
AS 65002
PE55
PE3
CE3
CE5
Version 3.9.0a
Version 4.0.1
XMPLST4Module 5/58
577
Module 5
578
Version 4.0.1
Module 5
P22
P2
PE
AS 65001
P1
.1
192.168.1.0
.11
P11
PE
AS 65002
PE55
PE3
CE3
CE5
Version 3.9.0a
Version 4.0.1
XMPLST4Module 5/59
579
Module 5
580
Version 4.0.1
Module 5
P22
P2
PE
AS 65001
P1
192.168.1.0
.1
.11
P11
PE
AS 65002
PE55
PE3
CE3
CE5
Outgoing
Label
----------16014
Prefix
or ID
-----------------10.5.5.55/32
Outgoing
Next Hop
Interface
------------ --------------PO0/3/0/2
192.168.34.4
Bytes
Switched
-----------0
Version 3.9.0a
Version 4.0.1
XMPLST4Module 5/60
581
Module 5
Summary
MPLS Inter-AS L3VPN
In this module, you learned to:
582
Version 4.0.1
Module 6
MPLS Traffic Engineering
Overview
Description
This module provides information about the operation, configuration, and
management of Multiprotocol Label Switching (MPLS) traffic engineering
(TE) and Fast Reroute (FRR).
Objectives
After completing this module, you will be able to:
Version 4.0.1
61
Module 6
62
Version 4.0.1
Module 6
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/4
63
Module 6
64
Version 4.0.1
Module 6
R3
R8
R4
R5
R2
R1
R6
R7
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/5
65
Module 6
66
Version 4.0.1
Module 6
R3
R8
100 Mbps
traffic to R5
180 Mbps
aggregate
R4
OC3
OC3
OC3
R1
R2
OC3
(155 Mbps)
R5
OC3
OC3
OC3
2-40 Mbps
traffic to R5
R6
OC3
R7
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/6
67
Module 6
68
Version 4.0.1
Module 6
Load share
" Move traffic along path other than IGP shortest path
" Allow critical traffic paths to have preferred paths
" Include or exclude particular links for certain traffic
Handle failures
! Promote efficiency
! Reduce costs
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/7
69
Module 6
610
Placing traffic where you want it build your Cisco MPLS TE tunnels
to utilize the paths and bandwidth in your network in the way that best
works
Version 4.0.1
Module 6
Collecting metrics
!Measuring utilization
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/8
611
Module 6
612
Version 4.0.1
Module 6
R3
R8
100 Mbps
traffic to R5
R4
OC3
R2
OC3
R1
OC3
2-40 Mbps
traffic to R5
OC3
R5
OC3
OC3
80 Mbps traffic
to R1 from R5
R6
OC3
R7
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/9
613
Module 6
614
Version 4.0.1
Module 6
Bandwidth
Path selection
!Dynamically created
" IGP CSPF calculation including available bandwidth
!Explicitly defined
" Manually defined path
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/10
615
Module 6
616
Version 4.0.1
Module 6
MPLS TE is an umbrella
!Path calculation
!RSVP-TE
!Tunnel admission control
MPLS-TE
RSVP-TE
PCALC
Admission
Control
2011, Cisco Systems, Inc. All rights reserved.
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/11
617
Module 6
618
Version 4.0.1
Module 6
TE Tunnel
R1
R2
R3
Network X
Headend
Midpoint
Tailend
! R2 is downstream from R1
! R2 is upstream to R3
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/13
619
Module 6
620
Version 4.0.1
Module 6
MPLS Domain
Headend
IGP
IGP
IGP
RSVP
RSVP
RSVP
Midpoint
Midpoint
Tailend
Control plane
Data plane
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/14
621
Module 6
Link Attributes
All links in the network have attributes, such as bandwidth, type (POS,
Gigabit Ethernet, and so on), and the physical path (satellite links,
undersea cable, land-based fiber optic, and copper are some examples).
Resource class affinity (policy) supports the ability to include, or exclude,
certain links for certain traffic trunks, based on a user-defined policy that
includes:
32 bits
IP Precedence (IPP)
Affinity string and affinity policy may be used to steer traffic over, or keep
traffic off, specific links.
Affinity refers to the attractiveness of a particular link to carrying tunnel
traffic. Affinity in Cisco MPLS TE permits specifying bits, or strings of bits,
to dictate the type of traffic that can traverse the link. Typically, a bit
signifies something, link type, color, or some other value with meaning.
622
Version 4.0.1
Module 6
Link Attributes
!Available bandwidth
!Affinity policy
Resource attributes distributed by a link-state
IGP within the network
!Available bandwidth
" Per link
" Per priority (DS-TE)
!Affinity string
2011, Cisco Systems, Inc. All rights reserved.
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/15
623
Module 6
Tunnel Attributes
Tunnels have various purposes, some more important than others. Traffic
such as voice cannot afford delay and needs to get resources when
required. Email and other data traffic do not have the same need. You
configure the tunnel attributes at the headend router. Each tunnel has
attribute flags set for it, which are used during the reservation process.
The attribute with the highest impact is bandwidth. The amount of
bandwidth a particular tunnel wants dictates the path the tunnel takes
through your network.
Cisco MPLS TE enables you to set the priority for the traffic based on the
requirements and allows tunnels to take precedence over others for set up,
and determines if the tunnel holds its bandwidth when another tunnel
wants to come up.
There are path options available for your tunnels too. The most popular is
explicit or static tunnels, in which you choose the path the tunnel takes.
This type of tunnel takes full knowledge and understanding of your
networks resources and the traffic that uses it. You may also use tunnels
that are dynamically computed paths based on combination of bandwidth
and policies.
You may also set up your tunnels for reoptimization, which is an attempt
to keep your tunnels on the best possible path. Occasionally, the network
resources are rechecked and if they have changed, your tunnels may be
rerouted, or optimized, to the new resources.
624
Version 4.0.1
Module 6
Tunnel Attributes
Bandwidth requirement
Affinity bits
Priority
!Setup priority
!Hold priority
Path options
!Static or explicit
!Dynamic
Reoptimization
2011, Cisco Systems, Inc. All rights reserved.
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/16
625
Module 6
Network topology and its possible physical paths as well as the choice
of pathexplicit or dynamic
Attribute flags set and used during the set up. Links in the network
also have attributes. For a tunnel to use a particular link, it must
match an affinity for the link. Affinity includes constraints on
bandwidth and path restrictions. Using default settings for links and
tunnels simply allows the use of all possible links by the tunnel
626
Version 4.0.1
Module 6
! CSPF
! Constraints
"
"
"
"
Available bandwidth
Affinity
Administrative weight
Explicit path, if defined
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/17
627
Module 6
Bandwidth:
!
Unreserved bandwidth
OSPF and IS-IS, with their Cisco MPLS TE extensions. perform these:
628
Version 4.0.1
Module 6
! Topology
! Link cost
! Bandwidth
! TE metric
! Administrative grouping or affinity
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/19
629
Module 6
IGP Flooding
To create tunnels, routers need valid information to make strategic
decisions about the path the tunnel takes. Routers learn the information
that helps make the decisions, from the IGPs when they flood.
To make path decisions, routers need to know these:
Flooding less significant events less often than significant ones but
more often than regular periodic flooding
IS-IS and OSPF flood the LSP and LSA, respectively, when the link state
changes, up and down, or when the configuration of the interface changes.
Each of the IGPs also floods periodically, every 30 minutes for OSPF and
every 15 minutes for IS-IS. These refresh rates can be changed through
specific IGP configuration.
630
Version 4.0.1
Module 6
IGP Flooding
Main considerations
errors, immediately
" Flood insignificant events less often, but more often
than regular periodic updates
" Periodic information updates using refresh intervals
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/20
631
Module 6
632
Version 4.0.1
Module 6
Type 9 LSA
Type 10 LSA
Type 11 LSA
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/21
633
Module 6
Name
Length
in octets
Meaning
Link type
Point-to-point or multi-access
Link ID
Router ID of neighbor or DR
interface address
Maximum bandwidth
Maximum reservable
bandwidth
Unreserved bandwidth
32
Administrative group
RFC 2370 defines a new option bit, O-bit, to define the ability of the
routers to send or receive opaque LSAs. The option field is present in OSPF
hello and database description packets, and all LSAs.
The LSA option field values are:
O bitIndicates capability of sending and receiving opaque LSAs
DC bitDescribes handling of demand circuits
EA bitDescribes willingness to receive and forward External=AttributeLSAs
N/P bitDescribes handling of type-7 LSAs
MC bitDescribes whether Multicast packets are forwarded
E bitDescribes external routing capability and the way AS-externalLSAs are flooded
634
Version 4.0.1
Module 6
31
LS age
Options
Opaque type
Opaque ID
Advertising router
LS sequence router
LS checksum
Length
Opaque information
DC
EA
N/P
MC
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/22
635
Module 6
The first new TLVs is type 22, the extended IS reachability TLV
containing new data:
!
Sub-type1 octet
Length1 octet
The second new TLV is the Extended IP Reachability TLV is type 135.
This TLV succeeds the IP Reachability TLV types 128 and 130. The
original TLVs had four metrics of which only the default was really
used. And the ability to redistribute routes was limited to up level in
the IS-IS hierarchy. The new TLV 135 extends the metric to 32 bits and
adds a bit to indicate redistribution down in the hierarchy.
The third new TLV IS the TE router ID TLV (type 134), which contains
the 4-octet router ID of the LSP-originating router. This ensures a
single stable address reference for the path.
636
Version 4.0.1
Module 6
Introduces sub-TLVs
Version 3.9.0a
XMPLST4Module 6/23
Instructor's Note
Additional information is contained after the Summary page, as it was too much to include here.
Version 4.0.1
637
Module 6
638
Version 4.0.1
Module 6
10
R4
Mb
ps
30
30
Cost=10
Cost=10
Cost=10
Cost=10
Cost=10
Cost=10
s
bp
R2
R3
R4
R4
R5
R5
10
R1
R1
R2
R3
R3
R4
50 Mbps
R3
Headend
10
R1
50
10
bp
s
50 Mbps
10
R2
10
R5
Tailend
10 Mbps
B/W=30 Mbps
B/W=50 Mbps
B/W=50 Mbps
B/W=30 Mbps
B/W=10 Mbps
B/W=50 Mbps
!Topology
!Link costs
!Available link bandwidths
Version 3.9.0a
10
R4
Mb
ps
30
30
50 Mbps
10
s
bp
M
MPLS traffic
R3
10
Headend
10
50
10
bp
s
50 Mbps
10
R2
R1
XMPLST4Module 6/25
R5
Tailend
10 Mbps
Shortest path
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/26
639
Module 6
640
Version 4.0.1
Module 6
10
R2
R4
Mb
ps
10
30
30
50 Mbps
10
s
bp
MPLS tunnel
B/W req. 20 Mbps
R3
10
10
R1
Headend
50
10
M
bp
s
50 Mbps
R5
Tailend
10 Mbps
MPLS TE considers
! Cost
! Available bandwidth
" Per priority (eight priorities)
! Constraints
" Resource affinity
! Lowest cost
! Highest minimum bandwidth is tie breaker
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/27
641
Module 6
642
Version 4.0.1
Module 6
mpls traffic-eng
: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)#
Version 3.9.0a
XMPLST4Module 6/29
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/30
643
Module 6
When a tunnel is already up, possible reasons for signaling by the headend
include:
644
Version 4.0.1
Module 6
Tunnel is down
available
After preemption
Path verification failure for unprotected tunnels
Tunnel is up
!Periodic reoptimization
!Reoptimization on FRR
!Path verification failure for protected tunnels
!Auto bandwidth-triggered change
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/33
645
Module 6
Tunnel Request
RSVP uses a series of messages to manage the tunnels, such as Path, Resv,
PathTear, ResvTear, ResvErr, and PathErr. These messages contain
objects, or information, that is used by RSVP routers to make decisions
about the tunnels they manage. In this module, you learn about the
messages and their use in this module.
A headend router sends the RSVP reservation request, in the form of a
Path message. The RSVP reservation is identified using:
Sender Address
Endpoint Address
646
Version 4.0.1
Module 6
Tunnel Request
R9
R8
R3
R4
Path
message
20Mbps
30
R2
R1
80
60
R5
70
50
60
40
R6
R7
100
80
80
RSVP path: R1 ! R2 ! R6 ! R7 ! R4 ! R9
Available bandwidth
Version 3.9.0a
XMPLST4Module 6/35
Instructor's Note
Slide animation: Click 1 Path message 20 Mbps appears and blue arrows trace from R1 to
R9
2011 Cisco Systems, Inc.
Version 4.0.1
647
Module 6
648
Version 4.0.1
Module 6
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/36
649
Module 6
Tunnel Reservation
The response to the Path message is an RSVP Resv message sent by the
tailend router to the headend router.
R9 formulates the Resv message with a destination of R1. The objects in
the Resv message include the address of the link between R9 and R4, and
the R1 router ID. There is no RA^% bit set in the Resv message.
This illustration shows a successful tunnel reservation and admission.
Failure scenarios are addressed later in this module.
650
Version 4.0.1
Module 6
Tunnel Reservation
R9
R8
R3
R4
30
10
R2
R1
80
60
27
32
70
50
60
40
49
RESV
message
Pop
R6
R5
R7
100
80
22
49
80
2011, Cisco Systems, Inc. All rights reserved.
XMPLST4Module 6/38
Instructor's Note
Slide animation: Slide starts with available bandwidth shown in red; Click 1 Yellow Resv
message and green POP label appear from right. Yellow arrows appear R9-R4-R7-R6-R2-R1
along with accompanying green labels. Note the available bandwidth numbers are in red. Click 2
The available bandwidth numbers are reduced to account for new reserved bandwidth and color
changes to tan.
2011 Cisco Systems, Inc.
Version 4.0.1
651
Module 6
Path Maintenance
RSVP has a process that it uses to maintain the paths that tunnels take for
as long as the tunnel needs that path.
RSVP is a soft-state protocol. A soft-state mechanism is one that times out
without regular refreshing.
The headend of a path sends periodic Path messages to refresh the path
information. Occasionally midpoint routers may originate new Path
messages.
Path and Resv messages are sent asynchronously by the headend and
tailend, respectively. Each is sent independent of the other. They are sent
within a standard interval of 45 seconds that is varied to account for
possible jitter in the network. The jitter calculation is one half of the
interval, or 22.5 seconds. Thus, a refresh is sent between 22.5 and
67.5 seconds.
652
Version 4.0.1
Module 6
Path Maintenance
XMPLST4Module 6/40
" K = 4
" R = 45 seconds
" Default soft-state timeout is approximately 303 seconds
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/41
653
Module 6
The PathTear message proceeds hop-by-hop until it reaches the end of the
path. In other words, R3 sees the PathTear message, sends a ResvTear
message, and so on.
The refresh mechanism for a Resv message is the same. R1 is expecting to
see Resv messages from R2 after the initial Resv. In turn, each pair of
adjacent routers does the same thing. And if a timer expires before
receiving the Resv message, the same thing happens as in the case of the
Path message.
If the interface between R6 and R7 goes down, several steps take place
depending on the type of tunnel that was created. If the tunnel was created
as an unprotected tunnel, or as a protected tunnel, but with no backup
path, as in this case, these happen:
R6 sends a PathErr message with the Path State Remove (PSR) bit set
toward R1
R6 sends a PathErr message upstream, but the PSR bit is not set.
Tunnel protection and backup paths are discussed later in this module.
654
Version 4.0.1
Module 6
R7
!
!
Version 3.9.0a
XMPLST4Module 6/43
R9
R4
R2
R1
R6
R7
! R6 deletes state
" Sends PathErr message upstream with Path State Remove (PSR) bit
set
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/44
655
Module 6
When a request for bandwidth reaches a midpoint router in the path from
headend to tailend, the amount of available bandwidth already in use by
other tunnels may be more than what the new tunnel can be granted.
However, the midpoint router does not reject the request immediately. The
midpoint router examines the hold priorities of the existing tunnels and
compares them with the setup priority of the new tunnel request. The
midpoint will preempt any lower priority tunnels it needs to satisfy the
bandwidth request of the new tunnel.
If the midpoint is unable to preempt any existing tunnels, admission
failure occurs. This may be caused by a stale view of the Cisco MPLS TE
database at the headend that requested the tunnel. In this instance, the
midpoint sends a PathErr message to headend.
This also causes OSPF to flood a type-10 LSA or IS-IS to flood a type-135
LSP to update the Cisco MPLS TE databases.
Headend Behavior
When the tunnel setup has failed and the midpoint has sent a PathErr
message, the headend follows a procedure to attempt to deal with the
failure. First, the headend uses an exponential backoff algorithm to holddown the path option. The headend does not hold-down the link in the
Cisco MPLS TE database, so that other existing tunnels are not affected.
If an additional path option for the tunnel is configured, the headend
attempts to signal this new path option. This continues until it is
successful or all path options are exhausted. Retries are attempted based
on the backoff timer.
In the event this is a reoptimization attempt to re-signal a tunnel, the
attempt is abandoned until the next expiration of the reoptimization timer.
The headend receives the OSPF or IS-IS link-state updates and makes the
adjustments to the Cisco MPLS TE topology in parallel with the path
retries.
656
Version 4.0.1
Module 6
Midpoint behavior
Version 3.9.0a
Headend behavior
Headend receives admission failure PathErr message
XMPLST4Module 6/46
! Exponential back-off
! While waiting for CSPF
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/47
657
Module 6
Path Teardown
A tunnel may be shut down if it is dynamic and the application no longer
needs the tunnel, or an administrator may shut it down, or it may be shut
down in favor of another tunnel, which has a higher priority.
The headend will send a PathTear message toward the tunnel destination
with the RA option bit set. Every router in the path will need to act on this
PathTear message. They do so by sending a ResvTear message back
toward the headend and their own PathTear message toward the tailend.
When the tailend router receives the PathTear message, it will send its
own ResvTear message back toward the headend.
Path teardown also occurs when an RSVP state times out.
658
Version 4.0.1
Module 6
Path Teardown
PathTear downstream
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/48
659
Module 6
660
Version 4.0.1
Module 6
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/49
661
Module 6
The other parts of the header are useful for managing the packets in the
network and insuring their integrity, or represent items that have not yet
been defined by the IETF.
The most common message types are listed in the lower illustration, along
with their purpose, what triggers them, which router sends the message,
and to whom the message is sent.
662
Version 4.0.1
Module 6
0
Version
(4 bits)
4
Flags
8
Message type
(4 bits)
16
RSVP checksum
(8 bits)
(16 bits)
Send TTL
Reserved
RSVP length
(8 bits)
(8 bits)
(16 bits)
31
! 1 = Path
! 2 = Resv
! 3 = PathErr
! 4 = ResvErr
! 5 = PathTear
! 6 = ResvTear
! 7 = ResvConf
! 10 = ResvTearConf
! 20 = Hello
Version 3.9.0a
RSVP Message
Purpose
Path (RA)
Signal resource
request
Resv
Response to Path,
carry labels
Next hop
PathErr
Error in Path
message
Next Hop
ResvErr
Error in Path
Message
Next Hop
PathTear (RA)
ResvTear
Next Hop
Hello
Keepalive
Every 5 seconds
All neighbors
Router ID of
neighbor
Trigger
XMPLST4Module 6/51
Who Sends It
Version 3.9.0a
Version 4.0.1
To Whom
Tailend
Tail
XMPLST4Module 6/52
663
Module 6
664
Version 4.0.1
Module 6
Some inheritance
!Bandwidth on interfaces
!Authentication on neighbors
rsvp
(config-rsvp)
authentication
interface
(config-rsvp-auth)
2011, Cisco Systems, Inc. All rights reserved.
(config-rsvp-if)
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/53
665
Module 6
666
Version 4.0.1
Module 6
Setting up signaling
Enter the RSVP context
Choose the interface
:router(config)#
rsvp
:router(config-rsvp)#
Version 3.9.0a
XMPLST4Module 6/55
:router(config-rsvp-if)#
:router(config)# rsvp
:router(config-rsvp)# interface POS 0/3/0/7
:router(config-rsvp-if)# signalling refresh interval 60
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/56
667
Module 6
668
Version 4.0.1
Module 6
Physical
link
RSVP
bandwidth
XMPLST4Module 6/58
! Range is 04,294,967,295
! Default is Kbps
Bandwidth pools
:router(config-rsvp-if)#
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/59
669
Module 6
670
Version 4.0.1
Module 6
MAM
Each class type (CT) has a
CT2
maximum bandwidth
constraint
BC2
CT1
BC1
CT0
BC0
Max Reservable Bandwidth (MaxRBW)
RDM
Version 3.9.0a
CT2
XMPLST4Module 6/61
CT2 + CT1
BC2
BC1
BC0=MaxRBW
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/62
671
Module 6
672
Version 4.0.1
Module 6
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/63
673
Module 6
674
Version 4.0.1
Module 6
:router(config)#
mpls traffic-eng
:router(config)# mpls traffic-eng ?
affinity-map
auto-bw
bfd
ds-te
fast-reroute
interface
link-management
lmp
load-share
logging
path-selection
pce
reoptimize
router-id
signalling
timers
topology
<cr>
2011, Cisco Systems, Inc. All rights reserved.
Version 4.0.1
XMPLST4Module 6/65
675
Module 6
When you configure an interface for Cisco MPLS TE, RSVP is turned on for
the interface, even if you have not previously configured it. However, zero
bandwidth is allocated and the Cisco MPLS TE tunnels will not activate
until RSVP bandwidth is configured.
Also, if the IGP in the network is IS-IS Cisco MPLS TE does not work until
the metric style of the interface is changed to wide. The metric-style is
configured in the IS-IS interface configuration.
676
Version 4.0.1
Module 6
:router(config-mpls-te)#
interface
:router(config)# mpls traffic-eng
:router(config-mpls-te)# interface POS 0/3/0/1
:router(config-mpls-te-if)#
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/66
677
Module 6
678
Version 4.0.1
Module 6
:router(config-mpls-te-if)#
admin-weight weight
:router(config-mpls-te-if)# admin-weight 5
Time router should ignore link in topology database for CSPF calculations
! Avoids creating paths including link until IGP confirms or hold-down timer
expires
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/67
679
Module 6
680
Version 4.0.1
Module 6
Flooding System
: enabled
: 1
IGP Areas
---------IGP Area[1]:: OSPF lab area 0
Flooding Protocol
: OSPF
Flooding Status
: flooded
Periodic Flooding
Flooded Links
: 5
IGP System ID
: 0.0.0.1
MPLS TE Router ID
: 10.1.1.1
IGP Neighbors
: 5
OSPF information
XMPLST4Module 6/69
: 1
IGP Areas
---------IGP Area[1]:: IS-IS L2-12 level 2
Flooding Protocol
: IS-IS
Flooding Status
Periodic Flooding
: flooded
: enabled (every 180 seconds)
Flooded Links
: 3
IGP System ID
MPLS TE Router ID
: 0000.0000.0033
: 10.3.3.33
IGP Neighbors
: 3
Version 3.9.0a
Version 4.0.1
IS-IS information
XMPLST4Module 6/70
681
Module 6
682
Version 4.0.1
Module 6
: PSC
Physical BW
: 1000000 kbits/sec
Intrinsic bandwidth
--More--
BCID
: RDM
Max Reservable BW
Version 3.9.0a
Inbound Admission
: reject-huge
Outbound Admission
: allow-if-room
: 1
: 200000 kbits/sec
BC0 (RDM)
: 200000 kbits/sec
BC1 (RDM)
: 0 kbits/sec
: 500000 kbits/sec
BC0 (MAM)
: 500000 kbits/sec
BC1 (MAM)
: 500000 kbits/sec
Attributes
: 0x0
Attribute Names
XMPLST4Module 6/72
Bandwidth reserved
TE and RSVP up
IGP information
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/73
683
Module 6
684
Version 4.0.1
Module 6
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/75
685
Module 6
TE Tunnel Options
As you can see from the illustration, there are several parameters that
may be set for a tunnel interface:
destinationTunnel destination
priorityTunnel priority
686
Version 4.0.1
Module 6
:router(config)#
Create an interface
Assign a locally unique tunnel-id value
!Range is 0-65,535
Provide a description
2011, Cisco Systems, Inc. All rights reserved.
:router(config-if)# ?
address-family
affinity
auto-bw
autoroute
backup-bw
description
destination
fast-reroute
forwarding-adjacency
ipv4
load-interval
load-share
logging
mpls
path-option
path-protection
path-selection
policy-class
priority
record-route
service-policy
shutdown
signalled-bandwidth
signalled-name
2011, Cisco Systems, Inc. All rights reserved.
Version 3.9.0a
XMPLST4Module 6/77
AFI/SAFI configuration
Link attributes for links traversed by tunnel
Enable tunnel auto-bandwidth and enter its submode
Parameters for IGP routing over tunnel
Fast-reroute backup bandwidth requirement
Set description for this interface
Specify tunnel destination
Specify MPLS tunnel can be fast-rerouted
Use the tunnel as forwarding adjacency
IPv4 interface subcommands
Specify interval for load calculation for an interface
Specify tunnel load-sharing metric
Per-interface logging configuration
MPLS interface subcommands
Primary or fallback path setup option
Enable the path protection feature on this tunnel
Path Selection Configuration
Specify classs for policy-based tunnel selection
Tunnel priority
Record the route used by the tunnel
Configure a service policy
shutdown the given interface
Tunnel bandwidth requirement to be signalled
The signaling name to assign to tunnel
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/78
687
Module 6
688
Version 4.0.1
Module 6
:router(config-if)#
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/78
689
Module 6
690
Version 4.0.1
Module 6
[output omitted]
:router# show ip interface brief
Interface
Loopback0
tunnel-te45
IP-Address
10.4.4.4
10.4.4.4
Status
Up
Down
Protocol
Up
Down
POS0/3/0/0
POS0/3/0/1
POS0/3/0/2
unassigned
192.168.24.4
192.168.34.4
Up
Up
Up
Up
Up
Up
POS0/3/0/3
POS0/3/0/4
POS0/3/0/5
POS0/3/0/6
192.168.14.4
unassigned
unassigned
unassigned
Up
Shutdown
Shutdown
Shutdown
Up
Down
Down
Down
POS0/3/0/7
GigabitEthernet0/4/0/0
GigabitEthernet0/4/0/1
GigabitEthernet0/4/0/2
unassigned
unassigned
unassigned
192.168.146.4
Down
Shutdown
Shutdown
Up
Down
Down
Down
Up
GigabitEthernet0/4/0/3
GigabitEthernet0/4/0/4
GigabitEthernet0/4/0/5
GigabitEthernet0/4/0/6
unassigned
unassigned
unassigned
unassigned
Shutdown
Up
Up
Shutdown
Down
Up
Up
Down
GigabitEthernet0/4/0/7
unassigned
Shutdown
Down
Version 3.9.0a
XMPLST4Module 6/80
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/81
691
Module 6
692
Version 4.0.1
Module 6
:router(config-if)#
destination ip-address
:router(config-if)# destination 10.5.5.5
Version 4.0.1
[output omitted]
XMPLST4Module 6/83
XMPLST4Module 6/84
693
Module 6
Instructor's Note
The instructor should discuss an explanation of the pools, how they work and how they
complement each other.
Slide Animation: Click 1 TE tunnels text appears; followed by dark blue tunnels within RSVP
bandwidth and arrow; followed by Unused bandwidth and arrow
694
Version 4.0.1
Module 6
Tunnel Bandwidth
:router(config-if)#
! Unless configured
Bandwidth is in kilobits
! Range is 0-4294967295
! Reserved in global-pool
! Values are 0 or 1
Version 3.9.0a
XMPLST4Module 6/86
- DSCP
Physical
link
RSVP
bandwidth
Version 3.9.0a
Version 4.0.1
Unused b/w
for other
RSVP signaled
traffic: DSCP
XMPLST4Module 6/88
695
Module 6
Tunnel Priorities
You may set tunnel set up priorities with a value in the range of 0 to 7. The
lower the priority of the tunnel the higher (better or more important) the
value of the tunnel. Likewise, a higher priority tunnel presents a less
important tunnel. The tunnel priority configuration uses two parameters,
defined here:
Tunnel Preemption
696
Version 4.0.1
Module 6
Tunnel Priorities
! Setup
" Possible to preempt existing tunnels
! Hold
Setup priority
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/89
697
Module 6
Preemption Steps
Here you see what happens when a tunnel is preempted by another tunnel,
and how the tunnel headend learns about the tunnel preemption.
Headend Behavior
The RSVP PathErr message travels upstream to the headend, reporting
errors in processing the Path message. The message passes through each
node without changing the state of the path until it reaches the originating
router. The headend matches the PathErr information against the latest
Cisco MPLS TE topology from the IGP database, determining available
bandwidth and the destination accessibility. The headend should attempt
to bring up the tunnel using some other path; typically using a different
outgoing interface.
Midpoint Behavior
A midpoint is any router that is not the headend or tailend of the tunnel.
There may be many midpoint routers in the path.
A PathErr message is an advisory message, but uses reliable messaging
(Prec-6) so that it is not lost, and reaches the sender. In the preemption
scenario, the midpoint notifies the headend of the preempted tunnel and
the link that is the source.
The midpoint sends a ResvTear message to the sender. The intent is for
upstream routers to clean up the associated reservations for this tunnel.
The midpoint sends a PathTear message downstream to the receiver to tell
routers along that path to clean up the resources. Because neither the
ResvTear nor the PathTear messages is reliable, the resources may not be
restored until the tunnel reservation is timed out when it is not refreshed.
Instructor's Note
If bandwidth is not available and a configuration such as EoMPLS with preferred TE tunnel is
configured, there is a question whether or not this traffic would flow at all using IP routing.
698
Version 4.0.1
Module 6
Headend behavior
information
Version 3.9.0a
XMPLST4Module 6/91
Midpoint behavior
Midpoint sends PathErr, ResvTear, and PathTear
messages and cleans up LSP
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/92
699
Module 6
6100
Version 4.0.1
Module 6
R1
R2
100 Kbps
200 Kbps
R3
50 Kbps
200 Kbps
50 Kbps
100 Kbps
200 Kbps
100 Kbps
200 Kbps
50 Kbps
200 Kbps
R5
300 Kbps
150Kbps
R4
Version 3.9.0a
XMPLST4Module 6/94
Instructor's Note
Slide animation: Click 1 Solid blue arrow R1-R2-R4 appears; Click 2 Bandwidth on each
link changes from 200 to 50; Click 3 Green arrow R3-R2-R5 appears; Click 4 Bandwidth goes
from 200 to 100; Click 5 Red X appears on link R2-R4; 50kbps R2-R4 disappears; solid blue
arrow disappears; B/W R1-R2 returns to 200kbps; Click 6 Dashed blue arrow R1-R2-R5-R4
appears; Click 7 Green arrow disappears; blue arrow becomes solid; Click 8 B/W R1-R2 goes
200 to 50, R2-R5 goes 100 to 50, R5-R4 goes 300 to 150; Click 9 B/W R2-R3 goes 100 to 200;
Click 10 Dashed green arrow, R3-R4-R5; Click 11 Green arrow becomes solid, B/W R3-R4
goes 200 to 100, R4-R5 stays at 150
2011 Cisco Systems, Inc.
Version 4.0.1
6101
Module 6
6102
Version 4.0.1
Module 6
:router(config-if)#
:router(config-if)# priority 1 1
:router(config-if)#
Tunnel priority
!Range is 07
" Lower the number; higher the priority
!SetupThis tunnel may preempt another
!HoldThis tunnel may be preempted by another
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/95
6103
Module 6
Path Calculation
The path calculation or PCALC is a modified version of the Dijkstra
algorithm used with IS-IS and OSPF. It uses a graphical method of
determining the lowest cost path from a source to a destination. The
shortest path calculation for resolving Cisco MPLS TE paths (LSPs) is the
CSPF calculation.
When the calculation occurs, there is a possibility that more than one path
may meet the minimum requirements. PCALC finds all the paths in the
database with the lowest IGP cost. It looks at the minimum bandwidth
available on each link and selects the highest. PCALC then chooses the
lowest number of hops for the path; actual physical hops, not an IGP cost.
Finally, if there are still multiple available paths, it randomly chooses one.
The PCALC process is illustrated on the next few pages.
6104
Version 4.0.1
Module 6
Path Calculation
Constrained SPF
PCALC (path calculation)
What if there is more than one path that meets the minimum
requirements, such as bandwidth?
PCALC algorithm:
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/96
6105
Module 6
Path CalculationPart 1
In the example on this and the subsequent pages, you see how the PCALC
algorithm works with the help of an example.
You determine the best path from R1 to R2 given the network illustrated.
In each path, the link outbound from R1 has a cost of 10 and 100 Mbps of
bandwidth. On the other side of the network, the inbound links to R2 all
have a cost of 5 and 50 Mbps of bandwidth.
The path you want to create requests 20 Mbps of bandwidth.
Because all of the R1 outbound costs are equal, and all of the R2 inbound
costs are equal, the calculation centers on the middle of the network. As
you can see, the topmost link has a cost of 10, which is not the lowest cost
for a path. Previously, you learned that the first step of PCALC is to find
all the paths with the lowest cost. In this illustration, the four lower paths
each have a cost of 8, which is equal, and the lowest of the five available
paths.
6106
Version 4.0.1
Module 6
Path CalculationPart 1
Path cost of 10
is not the
lowest cost
{10,100M}
}
,5
,10
0M
M}
}
{5, 50M
}
0M
5
,
{5
,10
0
0M
{10
{4,90M}
R2
50M
{8,90M}
,5
{10
{4,90M}
{5,
{10,100M}
0M
{8,80M}
00M
{10,1
R1
{5
0M
{5
{1
0
0,1
{8,90M}
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/97
6107
Module 6
Path CalculationPart 2
Now the most costly path has been removed from the illustration. PCALC
now looks for the path with the highest minimum bandwidth. In this
example, the topmost path has 80 Mbps, whereas the lower three each
have 90 Mbps bandwidth.
So the top path will be eliminated.
6108
Version 4.0.1
Module 6
Path CalculationPart 2
{8,80M}
00M
{10,1
,10
0M
,10
0
M}
}
{5, 50M
}
0M
5
,
{5
{10
{4,90M}
0M
{10
{4,90M}
R2
50M
{8,90M}
,5
{10,100M}
{5,
{5
R1
{8,90M}
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/98
6109
Module 6
Path CalculationPart 3
The next part of the calculation is to pick a path that is the actual lowest
hop count, meaning nodes, not IGP cost. The key reason for this choice is
lower overhead, and it minimizes the links and nodes that might fail and
disrupt the traffic in the tunnel.
So once again the topmost path is eliminated because it has three nodes in
the path, while the other paths have two nodes each.
6110
Version 4.0.1
Module 6
Path CalculationPart 3
R1
R2
,10
0M
M}
,10
0
}
{5, 50M
}
0M
5
,
{5
0M
{10
{4,90M}
{8,90M}
,5
{10
{4,90M}
{5
{10,100M}
{8,90M}
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/99
6111
Module 6
Path CalculationPart 4
Finally, you are left with two possible paths. Each of these paths is equal
in every way. The PCALC algorithm now chooses a path by random.
6112
Version 4.0.1
Module 6
Path CalculationPart 4
R1
R2
{5
{8,90M}
M}
0M
0M
0
,5
,5
,10
,10
0
{5
{10
{10
{8,90M}
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/100
6113
Module 6
Path CalculationResult
In the example, continue the previous pattern, and eliminate the topmost
path, leaving the bottom path as the one on which you set up your LSP.
6114
Version 4.0.1
Module 6
Path CalculationResult
R1
0M
0M
,5
,10
{5
{10
R2
{8,90M}
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/101
6115
Module 6
6116
Version 4.0.1
Module 6
:router(config-if)#
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/102
6117
Module 6
6118
Static routePrefix is entered into the routing table and traffic for
that destination takes this route
Version 4.0.1
Module 6
Autoroute
Static routes
Forwarding adjacency
EoMPLS tunnel selection
Other methods (not covered in this course)
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/103
6119
Module 6
6120
Version 4.0.1
Module 6
In
lbl
Address
prefix
Out
If
Out
lbl
In
lbl
Address
prefix
Out
If
Out
lbl
128.89
128.89
Tunnel path 1
...
...
...
...
...
...
...
...
Entry populated by TE
tunnel setup
R3
R1
R2
1
128.89.25.4
Data
128.89.25.4
128.89.25.4
To
128.89
Data
Data
Version 3.9.0a
Version 4.0.1
R4
XMPLST4Module 6/104
6121
Module 6
Forwarding Adjacency
One of the ways to steer traffic along the paths you want is by using
forwarding adjacency.
TE tunnels are not advertised as part of the IGP, so changing metrics on
tunnels does not have the desired affect of load-balancing traffic or even
sending traffic along a particular path.
Further, having tunnels go from each router in the network to every other
router where you want them, is not a scalable option. So a better solution
is to create the tunnels at some higher level of the network where they may
be better utilized.
Forwarding adjacency lets you use the IGP to advertise tunnels
downstream, so networks outboard of these downstream routers can reach
networks outboard of the tunnel tailend.
In the illustration on the lower part of the opposite page, you see two
points of presence (POP 1 and POP 2) with a core network between them.
All the routers in the illustration are at IS-IS Level-2 and form
adjacencies. All the links in the illustration have the same administrative
weight of 10.
Without any Cisco MPLS TE involved, the traffic from R100 to R200 flows
over the path, R100-R1-R3-R200, because it is the shortest, least cost path.
To attempt to balance the traffic flow across both paths, you might create
two tunnels on the core routers that follow the R1-R3 and R2-R4 paths and
make their administrative weight equal. But R100 still has no way to know
about the tunnels (they are not advertised), so the traffic continues to flow
over the original path.
6122
Version 4.0.1
Module 6
Forwarding Adjacency
!Area 0 or Level-2
!Scales better
Version 3.9.0a
XMPLST4Module 6/106
Physical view
R100
R1
R200
R3
R4
POP 1
Logical view
R3
R1
R2
2011, Cisco Systems, Inc. All rights reserved.
R4
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/107
6123
Module 6
What is needed is a way for R2 to learn about the tunnel paths so that it
may treat them equally and split the traffic over each as needed.
To accomplish that, you configure forwarding adjacency on the tunnels
created at the R1 headend. This permits the IGP to advertise the
availability of the tunnels to both R2 and R3; the tunnel is installed in the
topology database.
The forwarding-adjacency command has a holdtime parameter that is
associated with the forwarding-adjacency LSP. The parameter is optional
and its default value is zero milliseconds and has a range from 0 to
20,000 milliseconds.
There are caveats about the holdtime parameter and the possible delay of
the forwarding-adjacency notification to the IGP:
6124
Version 4.0.1
Module 6
Physical view
R1
R3
R4
POP 2
POP 1
Logical view
R3
R1
R2
2011, Cisco Systems, Inc. All rights reserved.
R4
Version 3.9.0a
XMPLST4Module 6/109
:router(config-if)#
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/110
6125
Module 6
Autoroute Announce
Autoroute announce is the automatic assignment of traffic based on the
IGP used in the network. It uses a modified SPF calculation. The tunnel
configured at the headend router appears the same as any interface.
During the SPF calculation, at the tailend, the next hop is set for the
interface associated with the end of the tunnel. Therefore, any
destinations, whose shortest paths use the tunnel, also use that interface
associated with the tunnel end at the tailend, as the next hop. Note that
the use of the tunnel does not alter the path metric in the routing table.
6126
Version 4.0.1
Module 6
Router B
Router F
Router H
Router E
Router A
Router G
Router C
Router I
Router D
Autoroute is limited
XMPLST4Module 6/112
Router B
Router F
Router H
Router E
Router A
Router G
Router C
Router D
Router I
Router A view
!Tunnel to Router G
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/113
6127
Module 6
6128
Version 4.0.1
Module 6
Node
B
C
D
E
F
G
H
I
Next-hop
B
C
C
B
B
Tunnel 1
Tunnel 1
Tunnel 1
Cost
10
10
20
20
30
30
40
40
Everything behind
Router B
Router F
Router H
Router E
Router A
Router G
Tunnel 1
Router C
Router I
Router D
Version 3.9.0a
Node
B
C
D
E
F
G
H
H
Next-hop
B
C
C
B
B
Tunnel 1
Tunnel 1
B
Cost
10
10
20
20
30
30
40
40
Tunnel 1
40
XMPLST4Module 6/115
Router B
Router F
Router H
Router E
Router A
Router G
Tunnel 1
Router C
2011, Cisco Systems, Inc. All rights reserved.
Router D
Version 3.9.0a
Version 4.0.1
Router I
XMPLST4Module 6/116
6129
Module 6
6130
Version 4.0.1
Module 6
:router(config-if)#
autoroute announce
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/117
6131
Module 6
6132
Version 4.0.1
Module 6
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/118
6133
Module 6
Static Routing
Another way to get traffic into a Cisco MPLS TE tunnel is by using static
routing. You create a static route using the tunnel exactly as you would
any other interface.
In this illustration, the administrative cost of each link between routers is
10. Using the IGP, both R8 and R9 are each reached at a cost of 40, no
matter which path is used.
To route the traffic for R8 and R9 over a specific path you want, you create
a tunnel between R1 and R7, using the desired path for the traffic. The cost
remains the same. R7, however, is not reached using the tunnel, but by
using the IGP, even though R7 is the tunnel endpoint.
You see the result in the routing table display for R1.
The configuration takes place in router static mode when you enter the
router ID representing the networks you want to reach, and point the
destination ID at the tunnel, in this case, Tunnel1. Note that you must
configure this in the address family you want to support. In this example,
you configure for IPv4 unicast traffic.
6134
Version 4.0.1
Module 6
Static Routing
Node
2
3
4
5
6
7
8
9
Next-hop
2
3
3
2
2
2
Tunnel1
Tunnel1
Cost
10
10
20
20
30
30
40
40
R2
-Uses IP routing
-Yet still tunnel tail
R6
R1
R8
R5
Tunnel1
R7
R9
R3
2011, Cisco Systems, Inc. All rights reserved.
R4
Version 3.9.0a
XMPLST4Module 6/120
:router(config-static-af)#
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/121
6135
Module 6
6136
Version 4.0.1
Module 6
[output omitted]
Destination: 10.6.6.6
Status:
Admin:
up Oper: down
Signalling: Down
type dynamic
PE3
P1
PE5
PE4
P2
PE6
CT0
Config Parameters:
Bandwidth:
5 Affinity: 0x0/0xffff
enabled
LockDown: disabled
Forwarding-Adjacency: disabled
Loadshare:
0 equal loadshares
Auto-bw: disabled
Fast Reroute: Disabled, Protection Desired: None
Path Protection: Not Enabled
Displayed 1 (of 1) heads, 0 (of 0) midpoints, 0 (of 0) tails
Displayed 0 up, 1 down, 0 recovering, 0 recovered heads
Version 3.9.0a
XMPLST4Module 6/124
MaxSub (bps)
0 (
0%)
PO0/3/0/2
0 (
0%)
PO0/3/0/3
0 (
0%)
PE3
P1
PE5
PE4
P2
PE6
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/125
6137
Module 6
6138
Version 4.0.1
Module 6
MaxSub (bps)
50M
50M
PO0/3/0/2
50M
50M
PO0/3/0/3
50M
50M
0 (
0%)
0 (
0%)
5M ( 10%)
PE3
P1
PE5
PE4
P2
PE6
[output omitted]
Destination: 10.6.6.6
Status:
Admin:
up Oper:
up
Path:
type dynamic
valid
Signalling: connected
CT0
Config Parameters:
Bandwidth:
5 Affinity: 0x0/0xffff
PE3
P1
PE5
PE4
P2
PE6
Current LSP:
Uptime: 00:02:07
Path info (OSPF lab area 0):
Hop0: 192.168.23.2
Hop1: 192.168.26.6
Hop2: 10.6.6.6
Version 4.0.1
6139
Module 6
The two illustrations represent the headend, tailend, and midpoints of the
tunnel.
6140
Version 4.0.1
Module 6
Proto/ExtTunID
PSBs
RSBs
Reqs
10.6.6.6
Headend
36
10.3.3.3
PE5
P1
PE3
Dynamic tunnel
P2
PE4
PE6
Tailend
Proto/ExtTunID
PSBs
RSBs
Reqs
10.6.6.6
36
10.3.3.3
Version 3.9.0a
PE3
P1
PE5
PE4
P2
PE6
XMPLST4Module 6/130
Midpoint
:P2# show rsvp session dest 10.6.6.6
Type Destination Add DPort
Proto/ExtTunID
PSBs
RSBs
Reqs
10.6.6.6
36
10.3.3.3
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/131
6141
Module 6
6142
Version 4.0.1
Module 6
PE3
PE5
P1
Interface
-------------------- -----------192.168.23.2
PE4
P2
POS0/3/0/3
PE6
Interface Neighbor
Interface Neighbor
Interface
Interface
-------------------- ------------
-------------------- ------------
192.168.23.3
192.168.26.2
POS0/3/0/3
POS0/3/0/7
Interface
-------------------- -----------192.168.26.6
POS0/3/1/1
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/132
6143
Module 6
When you use explicit tunnels, you must decide if the traffic using the
tunnel is important enough to have a backup path. Backup tunnels will be
discussed later in this module.
6144
Version 4.0.1
Module 6
Intra-area tunnel
Strict hop
192.168.13.1
R3
R1
POS
OSPF Area 0
GigE
POS
192.168.112.2
POS
192.168.23.2
R2
Version 3.9.0a
Version 4.0.1
192.168.26.6
R6
XMPLST4Module 6/135
6145
Module 6
Remember to use strict hop in a single area where the headend sees the
entire topology.
Loose Hop
6146
The router ID of the ABR node (as opposed to a link address on the
ABR) must be specified
Version 4.0.1
Module 6
:router(config)#
!
!
!
!
Range is 165,535
Account for path change or expansion
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/136
6147
Module 6
6148
Version 4.0.1
Module 6
Creating Explicit Cisco MPLS TE Tunnel and Setting the Path Option
!IP address
!Priority
!Announce path to IGP
!Bandwidth
!Destination
Version 3.9.0a
XMPLST4Module 6/138
:router(config-if)#
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/139
6149
Module 6
6150
Version 4.0.1
Module 6
Inter-area path
Loose hop
OSPF Area 1
10.1.1.1
10.1.1.2
R1
10.0.0.3
R2
R4
R3
10.0.0.4
OSPF Area 0
GigE
POS
10.0.0.6
10.0.0.5
R5
R6
10.3.3.7
R7
OSPF Area 3
2011, Cisco Systems, Inc. All rights reserved.
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/140
6151
Module 6
6152
Hold-off time
Version 4.0.1
Module 6
Detected
Time
Key pieces
Recovery methods
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/141
6153
Module 6
Protection
Recovery methods are employed with Cisco MPLS TE:
6154
Version 4.0.1
Module 6
Protection
Tunnel protection
! Local protection
! Path protection
Terms
Reminders
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/142
6155
Module 6
6156
Version 4.0.1
Module 6
Protection (Cont.)
R3
NNHOP
back-up
tunnel
R2
R1
Protected
tunnel
R6
PLR
NHOP
backup
tunnel
R5
R4
R9
Version 3.9.0a
R7
Merge
point
R8
Merge
point
XMPLST4Module 6/144
Instructor's Note
Slide animation: Starts with network drawing; Click 1 Red arrow and protected tunnel text;
Click 2 Red X on link R2-to-R6; Click 3 Protected tunnel text and red arrow disappear;
PLR appears with green arrow, NHOP backup tunnel, and Merge point appear; Click 4
Green arrow, PLR, NHOP backup LSP, Merge point disappear; Protected tunnel and
red arrow reappear; Click 5 R6 turns red; Click 6 Protected tunnel text and red arrow
disappear, PLR, beige arrow, NNHOP backup LSP, and Merge point appear
2011 Cisco Systems, Inc.
Version 4.0.1
6157
Module 6
6158
R2 begins sending the traffic on the backup path. It keeps the original
label for R6, label 62, and pushes a label to reach R9, label 92 onto the
packet
At R9, label 92 is swapped for label 79; labels 92 and 79 represent the
path to the loopback address of R6
At R7, the label is popped because that router is the last hop before R6
R6 receives the packet, it sees the inner label of 62 and swaps it for
label 72 and forwards the packet to R7
Version 4.0.1
Module 6
IP packet
Destination: 172.198.81.10
Original packet and labels
Destination: 172.198.81.10
21
62
21
172.198.11.0
R1
72
62
R2
72
R7
R6
R8
172.198.81.0
79
79
92
92
62
R9
62
62
21 Label
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/145
6159
Module 6
6160
Version 4.0.1
Module 6
43
72
43
32
R3
72
R5
R4
32
72
74
R2
R1
172.198.11.0
21
21
IP packet
Destination: 172.198.81.10
2011, Cisco Systems, Inc. All rights reserved.
R7
R6
62
62
72
R8
172.198.81.0
72
Version 4.0.1
XMPLST4Module 6/146
6161
Module 6
Path Protection
Path protection is protection for a tunnel generally used in a few specific
situations, usually a ring type network where it is not practical or too
costly. An example is Japan, which has a mountain range roughly in the
middle that prohibits laying fiber. So the Japanese have laid their cable
around the range in what you could loosely describe as a clock.
Further, because of the amount of configuration required, path protection
is not scalable.
In this illustration, R1 has a tunnel to R5. If the link between R2 and R3
were to stop working, node or link protection would need to set up a
backup tunnel that would go from R1-R8-R7-R6-R5-R4-R3-R4-R5. Similar
backup tunnels would need to be setup to account for all possible link or
node losses. This is not very practical.
However, in the illustration, path protection lets you create a backup
tunnel going from R1-R8-R7-R6-R5 to protect the original tunnel.
6162
Version 4.0.1
Module 6
Path Protection
Backup
tunnel
Protected
tunnel
R1
R8
PLR
R2
R3
R7
R6
R4
R5
Version 3.9.0a
XMPLST4Module 6/148
Instructor's Note
Slide animation: Starts with network drawing; Click 1 Green pipe and Protected LSP text;
Click 2 Red X on link R2-to-R3 and PLR text; Protected LSP text and green pipe
disappear; Click 3 Orange pipe and Backup LSP text appear
2011 Cisco Systems, Inc.
Version 4.0.1
6163
Module 6
Record Route
Route recording is typically turned on in a protected tunnel configuration
for node protection. The RSVP Path message has the Record Route Object
(RRO) and the Resv message records the addresses on the return.
The record-route command is used to keep track of the IP addresses of
each hop in the path. In Cisco IOS XR Software, the record-route
command must be enabled for tunnels protected by multiple backup paths
that merge at the same node.
6164
Version 4.0.1
Module 6
Record Route
:router(config-if)#
record-route
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/149
6165
Module 6
6166
Version 4.0.1
Module 6
PLR
R1
R5
R3
POS 0/3/0/2
Protected
LSP
Version 3.9.0a
XMPLST4Module 6/151
Merge
point
R6
R2
R4
:router(config-mpls-te-if)#
PLR
Backup
tunnel
R1
R5
R3
POS 0/3/0/2
Protected
LSP
R2
R4
2011, Cisco Systems, Inc. All rights reserved.
Version 3.9.0a
Version 4.0.1
R6
Merge
point
XMPLST4Module 6/152
6167
Module 6
6168
Version 4.0.1
Module 6
[output omitted]
R1
R2
Version 3.9.0a
R5
R6
XMPLST4Module 6/154
[output omitted]
Version 3.9.0a
Version 4.0.1
R5
R6
XMPLST4Module 6/155
6169
Module 6
In this illustration, you see the explicit path from a midpoint perspective,
and you see the entire route and record route information.
6170
Version 4.0.1
Module 6
[output omitted]
:R1# show mpls traffic-eng tunnels
LSP Tunnel 10.3.3.33 3126 [2] is signalled, connection is up
Tunnel Name: R3_t3126 Tunnel Role: Mid
InLabel: GigabitEthernet0/2/0/0, 16013
OutLabel: GigabitEthernet0/2/0/4, 16017
Bandwidth Requested:
5000 kbps CT0
Signalling Info:
Src 10.3.3.33 Dst 10.6.6.66, Tun ID 3126, Tun Inst 2, Ext ID 10.3.3.33
Router-IDs: upstream
10.3.3.33
local
10.1.1.11
downstream 10.2.2.22
Path Info:
Incoming:
Explicit Route:
Strict, 192.168.113.1
R3
Strict, 192.168.112.2
Strict, 192.168.126.2
Strict, 192.168.126.6
Strict, 10.6.6.66
Outgoing:
Explicit Route:
R4
Strict, 192.168.112.2
Strict, 192.168.126.2
Strict, 192.168.126.6
Strict, 10.6.6.66
--More- 2011, Cisco Systems, Inc. All rights reserved.
R1
R2
Version 3.9.0a
R5
R6
XMPLST4Module 6/157
[output omitted]
Record Route:
IPv4 192.168.113.3, flags 0x0
Tspec: avg rate=5000 kbits, burst=1000 bytes, peak rate=5000 kbits
Session Attributes: Local Prot: Set, Node Prot: Not Set, BW Prot: Not Set
Resv Info:
Record Route:
IPv4 10.2.2.22, flags 0x20
Label 16017, flags 0x1
IPv4 192.168.112.2, flags 0x0
Label 16017, flags 0x1
IPv4 10.6.6.66, flags 0x20
Label 3, flags 0x1
IPv4 192.168.126.6, flags 0x0
Label 3, flags 0x1
Fspec: avg rate=5000 kbits, burst=1000 bytes, peak rate=5000 kbits
Displayed 2 (of 2) heads, 1 (of 1) midpoints, 0 (of 0) tails
Displayed 2 up, 0 down, 0 recovering, 0 recovered heads
R1
R5
R3
R4
2011, Cisco Systems, Inc. All rights reserved.
Version 3.9.0a
Version 4.0.1
R2
R6
XMPLST4Module 6/158
6171
Module 6
6172
Version 4.0.1
Module 6
Out Intf/
FRR Intf/
Status
Label
Label
---------------- ---------------- ------tt156:Pop
Active
R1
R5
R3
R4
2011, Cisco Systems, Inc. All rights reserved.
Version 3.9.0a
Version 4.0.1
R2
R6
XMPLST4Module 6/159
6173
Module 6
6174
Version 4.0.1
Module 6
[output omitted]
path option 10, type explicit 3126 (Basis for Setup, path weight 30)
Change in required resources detected: reroute pending
Bandwidth:
5000 kbps (CT0) Priority: 4 3 Affinity: 0x0/0xffff
Metric Type: TE (default)
Last PCALC Error [Reopt]: Tue Nov 2 15:48:37 2010
Info: Explicit path has unknown address: 192.168.112.2
Last Signalled Error: Tue Nov 2 15:48:23 2010
Info: [2] PathErr(25,3)-(notify, local repair) at 192.168.113.1
G-PID: 0x0800 (derived from egress interface properties)
Bandwidth Requested: 5000 kbps CT0
Config Parameters:
Bandwidth:
5000 kbps (CT0) Priority: 4 3 Affinity: 0x0/0xffff
R3
Metric Type: TE (default)
AutoRoute: enabled LockDown: disabled
Policy class: not set
Forwarding-Adjacency: disabled
Loadshare:
0 equal loadshares
Auto-bw: disabled
Fast Reroute: Enabled, Protection Desired: Any
R4
Path Protection: Not Enabled
2011, Cisco Systems, Inc. All rights reserved.
Version 3.9.0a
Version 3.9.0a
Version 4.0.1
R6
[output omitted]
R1
R5
R3
R4
2011, Cisco Systems, Inc. All rights reserved.
R2
R5
XMPLST4Module 6/161
History:
Tunnel has been up for: 00:52:19
Current LSP:
Uptime: 00:52:19
Reopt. LSP:
Last Failure:
LSP not signalled, has no S2Ls
Date/Time: Tue Nov 02 15:48:37 UTC 2010 [00:00:09 ago]
Prior LSP:
ID: path option 10 [2]
Removal Trigger: path error
Path info (IS-IS L2-12 level-2):
Hop0: 192.168.113.1
Hop1: 192.168.112.2
Hop2: 192.168.126.2
Hop3: 192.168.126.6
Hop4: 10.6.6.66
Displayed 1 (of 1) heads, 0 (of 0) midpoints, 0 (of 0) tails
Displayed 1 up, 0 down, 0 recovering, 0 recovered heads
R1
R2
R6
XMPLST4Module 6/162
6175
Module 6
6176
Version 4.0.1
Module 6
R7
R1
R3
R5
POS 0/3/07
PLR
Protected
LSP
R4
R6
R2
R8
Version 3.9.0a
Merge
point
XMPLST4Module 6/164
R1
R3
POS 0/3/07
R7
R5
PLR
Protected
LSP
Merge
point
R4
R2
R8
Version 3.9.0a
Version 4.0.1
R6
XMPLST4Module 6/165
6177
Module 6
TE Timers
The fast-reroute timers promotion command lets you manage how
often a router will switch a protected LSP to a new backup tunnel. This is
particularly useful if the new backup tunnel has increased its backup
bandwidth or a backup tunnel with a better path becomes available. Keep
in mind that the lower you set the value, the more impact it will have on
router performance in the event that tunnels are moved to backup paths.
We recommend that the default value be the low value used. Cisco IOS XR
Software uses internal pacing mechanisms to distribute the load when
backup promotion is in use. However, when a large number of protected
LSPs get promoted, delay may be noticeable. Further, if the timer is
configured particularly low, some protected LSPs may never get promoted.
This depends on the actual number of protected LSPs.
The timers loose-path retry-period command lets you configure the
time period between retries the headend router makes after a path error
has occurred.
The link-management timers bandwidth-hold command lets you set
the amount of time that bandwidth is held while the RSVP setup message
(Path) waits to receive a corresponding RSVP reservation (Resv) message.
The link-management timers periodic-flooding command lets you
alter the time interval of the periodic flooding of link-state information.
When some characteristics of the Cisco MPLS TE link-state information
change, they do not trigger any immediate flooding action to make the
change known. An example is a change in the bandwidth that does not
cross a threshold.
6178
Version 4.0.1
Module 6
TE Timers
:router(config-mple-te)#
!
!
!
!
:router(config-mple-te)#
!
!
!
Version 3.9.0a
XMPLST4Module 6/168
:router(config-mple-te)#
link-management timers bandwidth-hold holdtime
:router(config-mpls-te)# link-management timers bandwidth-hold 20
!
!
!
!
:router(config-mple-te)#
link-management timers periodic-flooding value
:router(config-mpls-te)# link-management timers periodic-flooding 360
!
!
!
!
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/169
6179
Module 6
Reoptimization
In this section you learn about reoptimization of tunnels and the concept of
make-before-break.
Reoptimization in General
Reoptimization for Cisco MPLS TE means putting tunnels on the best path
to the destination.
There are four things that may influence tunnel reoptimization:
6180
Version 4.0.1
Module 6
Reoptimization
Reoptimization in General
What is reoptimization?
Manual changes
! Increasing bandwidth
! Adding new links
! Employing the reoptimize command
Events
! Link flapping
Path lockdown
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/171
6181
Module 6
Reoptimization Commands
Here are some reoptimization commands that you may find useful.
Periodic reoptimization
If you do not want a tunnel to change paths for some reason, use the
lockdown command in path option mode to keep the tunnel from being
reoptimized. If you provide any additional paths, they would only be used if
a link underlying the tunnel fails. The tunnel would switch to the newly
available path, but would return to the original path after the failed link
returns to service.
Event Driven Reoptimization
6182
Version 4.0.1
Module 6
Reoptimization
Reoptimization Commands
:router(config-mpls-te-if)#
reoptimize frequency
:router(config-mpls-te)# reoptimize 7200
Regular reoptimization
:router#
Manual reoptimization
Version 3.9.0a
XMPLST4Module 6/173
:router(config-if)#
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/174
6183
Module 6
Make-Before-Break
The concept of make-before-break is nearly as simple as it sounds. The
objective of making a tunnel before breaking the original tunnel is to
change the characteristics of an existing tunnel without impacting the
traffic in the tunnel, and to avoid completely or minimize substantially,
any traffic disruption. The tunnel characteristics that change are adding
bandwidth, removing bandwidth, or discovering a more optimal path.
A second objective is to avoid double counting bandwidth on any common
links that might carry both the original tunnel and the new tunnel. Double
booking bandwidth makes it appear that not enough bandwidth exists on
the link to support the original and the new tunnels. Thus, a newer tunnel
with more bandwidth would potentially be rejected.
6184
Version 4.0.1
Module 6
Reoptimization
Make-Before-Break
Objective
!Bandwidth
!Path
Avoid tearing down tunnel before new tunnel is
available
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/175
6185
Module 6
Make-Before-Break Example
For the purpose of this example, the domain administrator keeps all RSVP
bandwidth to the default 75 percent of intrinsic bandwidth. In the
illustration, you create a tunnel from R2 to R4 that requires 40 Mbps of
bandwidth. The LSP goes from R2 to R3 and to R4, the shortest physical
path. Later you decide to increase the tunnel bandwidth to 80 Mbps. The
LSP takes a new path from R2 to R1 to R5 to R4 to accommodate the
bandwidth increase request. After the tunnel is created, the original tunnel
is torn down.
OSPF cost changes could produce the same result in this particular
example.
6186
Version 4.0.1
Module 6
Reoptimization
Make-Before-Break Example
40 Mbps
R3
R2
60 Mbps
R4
100 Mbps
100 Mbps
100 Mbps
bandwidth reserved
R1
both paths
100 Mbps
R5
80 Mbps
Reservable bandwidth
shown is prior reservation
2011, Cisco Systems, Inc. All rights reserved.
Version 3.9.0a
XMPLST4Module 6/177
Instructor's Note
Slide animation: 1st major bullet appears with slide; Click 1 green arrow and 40 Mbps
appear; Takes path R2-R3-R4 text appears; Click 2 2nd major bullet appears; Click 3 text
Needs to take path R2-R1-R5-R4 appears, orange arrow and 60 Mbps appear; Click 4 3rd
major bullet, sub-bullet, and sub-sub-bullet appear; Click 5 4th major bullet appears, green
tunnel, 40 Mbps disappear
2011 Cisco Systems, Inc.
Version 4.0.1
6187
Module 6
The result of the SE reservation process is that two Path messages with all
the above parameters the same, are considered representative of the same
reservation. For MPLS TE, if two reservations have all the above
parameters, but with a different LSP ID, the LSP requests are different,
but they share the bandwidth. This tells the reservation process to split the
bandwidth until the original LSP tunnel is torn down.
6188
Version 4.0.1
Module 6
Reoptimization
40 Mbps
R3
100 Mbps
R2
60 Mbps
100 Mbps
100 Mbps
80 Mbps
R4
80 Mbps
100 Mbps
R5
80 Mbps
R1
80 Mbps
40Mbps
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/179
6189
Module 6
Automatic Bandwidth
Cisco MPLS TE automatic bandwidth is configured at the headend for each
individual label-switched path. Cisco MPLS TE monitors the bandwidth
usage on the tunnel interfaces and adjusts the bandwidth periodically to
align with the actual traffic in the tunnel.
In each automatic bandwidth configured tunnel, the output rate is sampled
based on configurable parameters and an average is derived. The tunnel
bandwidth is adjusted based on the highest average traffic output rate
during the last interval or measurement. The bandwidth may also be
adjusted based on a maximum or minimum bandwidth value.
The automatic bandwidth application uses several variables to measure
traffic and adjust the bandwidth:
Output traffic rates are collected at regular intervals when the application
period timer expires. The difference between the measured and current
bandwidth is the delta and the tunnel bandwidth is adjusted whenever the
delta exceeds, or is less than, the current bandwidth. When the timer
expires and the bandwidth adjustment, if any, is made, the samples are
cleared and the recording starts again for a new interval.
When the tunnel is reoptimized to take advantage of the new bandwidth, a
new LSP is signaled. If the bandwidth is not available to the LSP, the old
LSP continues without traffic interruption. Any minimum or maximum
bandwidth configurations keep the adjusted bandwidth within the
configured values. If a tunnel is shut down and restarted, all bandwidth
adjustment information is lost and the tunnel is configured with the
original bandwidth. Application intervals are restarted when the tunnel is
reactivated.
6190
Version 4.0.1
Module 6
Automatic Bandwidth
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/181
6191
Module 6
6192
Version 4.0.1
Module 6
:router(config-if-tunte-autobw)#
auto-bw
:router(config-if)# auto-bw
:router(config-if-tunte-autobw)#
:router(config-mple-te)#
XMPLST4Module 6/183
:router(config-if-tunte-autobw)#
application minutes
:router(config-if-tunte-autobw)# application 720
!
!
:router(config-if-tunte-autobw)#
bw-limit min bandwidth { max bandwidth }
:router(config-if-tunte-autobw)# bw-limit min 500 max 1000
Sets the minimum and maximum automatic bandwidth for the tunnel
Default is 0 Kbps; range is 04294967295
If bandwidth limit is changed while automatic bandwidth application is active,
impact occurs at next application
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/184
6193
Module 6
6194
Version 4.0.1
Module 6
:router(config-if-tunte-autobw)#
:router(config-if-tunte-autobw)#
Version 3.9.0a
XMPLST4Module 6/186
:router(config-if-tunte-autobw)#
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/187
6195
Module 6
6196
Version 4.0.1
Module 6
:router#
Version 3.9.0a
XMPLST4Module 6/189
:router#
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/190
6197
Module 6
6198
Version 4.0.1
Module 6
:router#
Version 3.9.0a
XMPLST4Module 6/192
:router#
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/193
6199
Module 6
When analyzing problems, you may find it helpful to clear out existing
information before starting your review of the information. One useful
command is the clear mpls traffic-eng link-management statistics
command, which will clear any existing admission control statistics.
6200
Version 4.0.1
Module 6
:router#
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/194
6201
Module 6
Summary
MPLS Traffic Engineering
In this module, you learned the following:
6202
Version 4.0.1
Module 6
Summary
Length
Name
10
11
32
Unreserved bandwidth
18
TE default metric
250-254
255
Version 4.0.1
6203
Module 6
6204
Version 4.0.1
Module 7
Layer 2 VPNs
Overview
Description
This module provides an overview and configuration examples for the
implementation of MPLS L2VPNs on systems using the Cisco IOS XR
operating system.
Objectives
After completing this module, you will be able to do the following:
Define AToM, its use, and interworking with Cisco IOS XR operating
system software
Version 4.0.1
71
Layer 2 VPNs
Module 7
72
Version 4.0.1
Module 7
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/4
73
Layer 2 VPNs
Module 7
74
Version 4.0.1
Module 7
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/5
75
Layer 2 VPNs
Module 7
76
Version 4.0.1
Module 7
VPWS Point-to-Point
!AToM
" EoMPLS
!L2TPv3
VPLS Point-to-Multipoint
2011, Cisco Systems, Inc. All rights reserved.
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/6
77
Layer 2 VPNs
Module 7
78
Version 4.0.1
Module 7
L2VPN Models
VPLS
VPWS
Point-to-point
Point-to-multipoint
MPLS Core
MPLS Core
IP Core
L2TPv3
AToM
Ethernet
Ethernet
Frame Relay
Frame Relay
Ethernet
Circuit Emulation
Version 3.9.0a
XMPLST4Module #/7
Instructors Note
This course focuses on AToM functionality
L2VPN working group is responsible for defining and specifying a limited number of solutions
for supporting provider provisioned L2VPNs. These solutions include, Virtual Private LAN
Service (VPLS), Virtual Private Wire Service (VPWS), and IPonly L2VPNs.
The pseudowire edge-to-edge emulation (PWE3) working group provides the framework for
edgetoedge wire emulation over a packet based provider network so that a service provider can
offer Layer 2 services such as ATM and FR by tunneling them across the backbone. The
backbone can be either IP or MPLS or L2TP. PWE3 is focused on providing the implementation
details of edgetoedge emulation across a packet network as well as providing interworking
functionality between the different edge services.
Version 4.0.1
79
Layer 2 VPNs
Module 7
710
Version 4.0.1
Module 7
Layer 2 VPNs
Layer 3 VPNs
Advantageous for:
Advantageous for:
Customers who prefer to
outsource their WAN to service
providers
Technologies:
VPWS (AToM, L2TPv3)
VPLS
Technologies:
BGP and MPLS VPNs
MPLS VPN over IP
GRE
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/8
711
Layer 2 VPNs
Module 7
Pseudowire
From the customer perspective a pseudowire (PW) is characterized as an
unshared link or circuit. The pseudowire edge-to-edge emulation (PWE3)
working group within the IETF defines pseudowire technology as an
emulated point-to-point connection over a packet switched network that
allows the interconnection of two nodes with any Layer 2 technology.
Pseudowires may be point-to-point, or point-to-multipoint. Point-to-point
PWs are always considered bidirectional; point-to-multipoint PWs are
always considered unidirectional.
Pseudowires support the following payloads:
712
Version 4.0.1
Module 7
Pseudowire
Payload Type
PW Service
Packet
Cell
Bit stream
Structured bit stream
ATM
Unstructured E1/T1, E3/T3
SONET/SDH
PSN may be
- IP
- IP and MPLS
2011, Cisco Systems, Inc. All rights reserved.
Version 3.9.0a
XMPLST4Module #/9
Instructors Note
Unstructured - bit stream overhead is treated as part of the payload
Structured - payload created requires knowledge of the underlying bit stream; may be transmitted
in entirety or part; can be recreated at egress
2011 Cisco Systems, Inc.
Version 4.0.1
713
Layer 2 VPNs
Module 7
Pseudowire Technology
L2VPNs are built using PW technology. PWs provide a common,
intermediate format to transport multiple types of network services over a
PSN. As depicted in the diagram PW technology provides like-to-like (L2L)
and interworking (IW) transport.
The CRS-1 does not support AToM interworking. The interworking
features supported by the Cisco XR12000 Series Router are discussed later
in this module.
714
Version 4.0.1
Module 7
Pseudowire Technology
Ethernet
Ethernet
ATM
Frame
Relay
Ethernet
ATM
ATM
Like-to-like
Frame
Relay
Version 3.9.0a
Version 4.0.1
Ethernet
Frame
Relay
Interworking
XMPLST4Module #/10
715
Layer 2 VPNs
Module 7
716
Version 4.0.1
Module 7
Emulated service
Pseudowire
Native
service
Native
service
PSN
tunnel
PW1
CE
AC
AC
PW2
PE
AC
PE
CE
AC
CE
CE
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/11
717
Layer 2 VPNs
Module 7
718
Version 4.0.1
Module 7
Provider
edge
Service interworking
Packet switched
network
Bridged
Ethernet
Provider
edge
Pseudowire
FR
ATM
HDLC
PPP
Ethernet
example
Ethernet
2011, Cisco Systems, Inc. All rights reserved.
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/12
719
Layer 2 VPNs
Module 7
720
Version 4.0.1
Module 7
ATM
Frame
Relay
IP
VPN
Frame Relay
Frame Relay
ATM
IP/MPLS
RPR
Internet
Internet
Ethernet
ATM
Ethernet
Many services,
one network,
(pseudowire)
Many services,
many networks
2011, Cisco Systems, Inc. All rights reserved.
IP/MPLS
PPP
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/14
721
Layer 2 VPNs
Module 7
AToM Interworking
In AToM interworking (IW) a pseudowire links two attachment circuits
with different data-link layer protocols. You provision Layer 2 any-to-any
IW circuits using AToM packet-switched networks (PSNs). IW functions
perform the translation and adaptation necessary to interconnect disparate
attachment circuits. It does this by using a native service that resides in
the PE (for IW, this is called a native service processor (NSP)) between the
pseudowire termination and the attachment circuit.
IP interworking provides IP connectivity between sites, regardless of the
Layer 2 connectivity to these sites. This is different from a Layer 3 VPN,
because it is point-to-point in nature, and the service provider does not
maintain any customer routing information.
These are the supported modes of IP interworking in AToM:
722
Version 4.0.1
Module 7
AToM Interworking
!ATM to Ethernet
!Ethernet port to VLAN mode
!ATM AAL5 multiple PVCs multiplexed on a
single LSP
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/15
723
Layer 2 VPNs
Module 7
AToM
The primary task of Any Transport over MPLS (AToM) is establishing
pseudowires between provider edge (PE) routers and carrying Layer 2
packets over these pseudowires.
AToM is an implementation of Virtual Private Wire Service (VPWS) for
MPLS networks. It provides point-to-point transport for Layer 2 traffic,
including Ethernet, ATM, FR, PPP, HDLC and TDM across MPLS packetbased core networks. By adding QoS and MPLS traffic engineering
features to AToM service providers can offer virtual leased line types of
services. One major feature of AToM is that the service provider does not
need to participate in customer routing.
724
Version 4.0.1
Module 7
AToM
AToM
Frame Relay
ATM
Leased line,
Ethernet
Frame Relay
ATM
IP/MPLS Core
Leased line,
Ethernet
Ethernet, ATM, FR, PPP, HDLC and TDM across MPLS packetbased core networks
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/16
725
Layer 2 VPNs
Module 7
726
Version 4.0.1
Module 7
LSP tunnel
Pseudowire
MPLS
CE
Directed LDP
session
PE1
PE2
1. Attachment circuit
configured with peer
address and PW ID!
CE
Attachment
circuit
Version 3.9.0a
XMPLST4Module #/18
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/19
727
Layer 2 VPNs
Module 7
728
Version 4.0.1
Module 7
MPLS Core
18 50
18 90
PE1
18
PE2
40 20
60 20
Site1
Site2
Site2
Tunnel label
VC label
Original packet
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/20
729
Layer 2 VPNs
Module 7
Control Protocols
The control and forwarding protocols for AToM are comprised of the
targeted LDP control session, and the three layers of encapsulation that
make up the emulated circuit.
Control Connection
Targeted LDP sessions are used for VC label negotiation, label withdrawal
and error notification. They are established through LDP extended
discovery between PE routers and use periodic targeted hellos. When used
with pseudowire emulation targeted hellos distribute VC labels.
Forwarding Protocols
Forwarding protocols have three layers of encapsulation.
Tunneling Component
The tunnel label, also referred to as the LSP label, establishes the
connectivity between a pair of PEs. This is a non-targeted LDP session
established through LDP basic discovery between a PE router and its
directly connected P routers, and is used to distribute tunnel labels. The
distribution and management of tunnel labels is a function of the
deployment of the underlying MPLS network. The MPLS LSP is derived
using LDP or RSVP-TE.
De-multiplexing Component
The VC label identifies the individual attachment circuits on the receiving
PE router. VC labels are either statically defined during configuration or
negotiated using the control plane.
Layer 2 Encapsulation and Control Word
During pseudowire establishment, the PE routers exchange label-mapping
messages. Interface parameters must match between peering PE routers.
For example, if the attachment circuit interface MTU of the peered PE
routers does not match, a pseudowire is not established.
The control word is required with Frame Relay and AAL5 Layer 2 protocol
data units (PDU). For other Layer 2 protocol types the control word is
optional. Information in the headers of those Layer 2 PDUs must be
accounted for, such as, Frame Relay BECN, FECN, DE, and C/R.
730
Version 4.0.1
Module 7
Control
connection
Targeted LDP
Used for VC-label negotiation, withdrawal, error
notification
Tunneling
component
Version 3.9.0a
XMPLST4Module #/21
Instructors Note
A pseudowire is comprised of two VCs, one in each direction.
Version 4.0.1
731
Layer 2 VPNs
Module 7
732
Control word (C-bit) The control word is an optional 4-byte field that
is located between the label stack and Layer 2 packet, when present.
The C-bit set says the advertising PE expects the control word to be
present in PW packets.
VC typeA 15-bit field that defines the type of PW; some examples are:
!
0x0001 FR DLCI
0x0005 Ethernet
0x0006 HDLC
0x0007 PPP
Version 4.0.1
Module 7
VC TLV
VC Type
VC info length
Group ID
VC ID
Interface parameters
Version 3.9.0a
XMPLST4Module #/22
Instructors Note
The LDP specification defines Layer 3 FECs based upon the IGP only. PW emulation defines
extensions to LDP.
The VC label is part of the encoding stack that encapsulates the Layer 2 packets traveling over
PWs.; it is a forwarding plane parameter and is the same as the attachment circuit label.
Version 4.0.1
733
Layer 2 VPNs
Module 7
Encapsulation Detail
Following a native Layer 2 header (not shown in the illustration) are the
tunnel label, VC label, control word, and the Layer 2 PDU:
734
Version 4.0.1
Module 7
Encapsulation Detail
0
1
2
3
0 1 2 3 4 5 67 8 9 01 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Tunnel label
EXP
TTL
VC label (VC)
EXP
TTL (set to 2)
VC label
Control word
0000
Flag
FRG
Length
Sequence number
Layer 2 PDU
Three-level encapsulation
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/23
735
Layer 2 VPNs
Module 7
Implementing a L2VPN
On the core facing edge router, or Network Provider Edge (N-PE) router,
configure:
736
Assign a router ID
Version 4.0.1
Module 7
Implementing a L2VPN
p0/3/0/1
p0/3/0/0
CE4
MPLS
P2
N-PE4
p0/3/0/0
p0/3/0/1
CE6
N-PE6
Enable LDP
Define LDP router-id
Define LDP interfaces
p0/3/0/1
p0/3/0/0
CE4
N-PE4
p0/3/0/0
p0/3/0/1
Version 3.9.0a
Instructors Notes
MPLS
P2
N-PE6
CE6XMPLST4Module #/26
:(config)# l2vpn
:(config-l2vpn)# pw-class TEST
:(config-l2vpn-pwc)# encapsulation mpls
:(config-l2vpn)# xconnect group TEST1-GRP
:(config-l2vpn-xc)# p2p PE4-PE6
:(config-l2vpn-xc-p2p)# interface pos0/3/0/0
:(config-l2vpn-xc-p2p)# neighbor 10.6.6.6
pw-id 1010
:(config-l2vpn-xc-p2p-pw)# pw-class TEST
Version 3.9.0a
XMPLST4Module #/27
When you enable sequencing using any of the available options, the sending of sequence
numbers is automatically enabled and the remote provider edge (PE) peer is requested to
send sequence numbers. Out-of-order packets received on the pseudowire are dropped
only if you use the (config-l2vpn-pwc-mpls)#sequencing receive or sequencing
both command.
2011 Cisco Systems, Inc.
Version 4.0.1
737
Layer 2 VPNs
Module 7
738
Version 4.0.1
Module 7
p0/3/0/1
p0/3/0/0
CE4
MPLS
P2
N-PE4
p0/3/0/0
p0/3/0/1
N-PE6
CE6
Segment 1
Segment 2
Group
Name
ST
------------------------
Description
ST
---------------------
Description
ST
-------------------------
PO0/3/0/0
10.6.6.6
test1-grp
pe4-pe6
UP
UP
1010
UP
PW ID
PW name
Attachment circuit
----------------------------------------------------------------------------
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/28
739
Layer 2 VPNs
Module 7
740
The first line shows the xconnect group and the attachment circuits at
both ends of the PW as POS interfaces. The PW link is up and there is
no interworking (same interface type at both ends)
The next two lines show the attachment circuit, the interface type, the
state, the Layer 2 encapsulation type, and MTU size
MPLS
!
Version 4.0.1
Module 7
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/29
741
Layer 2 VPNs
Module 7
EoMPLS
EoMPLS is one of the Any Transport over MPLS (AToM) types. AToM
transports Layer 2 packets over an MPLS backbone using a directed LDP
session between edge routers for setting up and maintaining connections.
EoMPLS encapsulates Ethernet protocol data units (PDUs) in MPLS
packets and forwards the packets across the MPLS network. Each PDU is
transported as one packet. This allows connecting two VLAN networks in
different locations that are geographically separated and have them appear
as a single entity. It permits connecting two Ethernet networks that are
geographically separated, and have the two networks appear as one logical
Ethernet or VLAN domain.
Service providers may use EoMPLS to interconnect enterprise LANs,
regardless of their physical location, in such a way that the WAN services
supporting the network are not apparent to the customer.
742
Version 4.0.1
Module 7
EoMPLS
Subset of AToM
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/31
743
Layer 2 VPNs
Module 7
Types of EoMPLS
Methods for configuring EoMPLS include:
744
Version 4.0.1
Module 7
Types of EoMPLS
Version 3.9.0a
XMPLST4Module #/32
Instructors Note
Default mode of operation is port mode VC type 5. This mode may be configured using the
L2VPN PW-class using the transport-mode <ethernet | vlan> command
Version 4.0.1
745
Layer 2 VPNs
Module 7
Implementing EoMPLS
The PE router configuration includes:
746
Version 4.0.1
Module 7
PE1
PE2
CE1
PE1
PE2
:(config)# l2vpn
:(config-l2vpn)# pw-class TEST
:(config-l2vpn-pwc)# encapsulation mpls
:(config)# l2vpn
:(config-l2vpn)# pw-class TEST
:(config-l2vpn-pwc)# encapsulation mpls
CE2
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/33
747
Layer 2 VPNs
Module 7
748
Version 4.0.1
Module 7
Version 3.9.0a
XMPLST4Module #/34
Instructor's Note
Lab exercise break here to create AToM and EoMPLS L2VPNs
Version 4.0.1
749
Layer 2 VPNs
Module 7
Pseudowire Redundancy
Pseudowire redundancy is the ability to detect a failure in the end-to-end
network and to be able to re-route the Layer 2 service to another endpoint
in the provider network that can continue to provide that service. It
provides protection in these areas:
750
Version 4.0.1
Module 7
Pseudowire Redundancy
Packet switched
network
CE1
PE2a
CE2a
PE1
Primary
pseudowire
Attachment
circuit
PE2b
Attachment
circuits
CE2b
Redundant
pseudowire
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/37
751
Layer 2 VPNs
Module 7
On PE2, configure the primary link for PE1 using all the preceding
parameters, except the backup link.
On PE3, configure the backup link from PE1 using all the preceding
parameters, except the active link.
The primary PW remains up and the backup becomes active only in the
event of a primary failure.
752
Version 4.0.1
Module 7
PE1: 10.1.1.1
CE1
p 0/3/0/0
AC
PE1
Primary PW
Backup PW
PE1
PE2: 12.1.1.1
CE4
PE3: 13.1.1.1
PE2
:(config)# interface pos0/3/0/2 l2transport
:(config)# l2vpn
:(config-l2vpn)# pw-class TEST
:(config-l2vpn-pwc)# encapsulation mpls
:(config-l2vpn)# xconnect group TEST-GROUP
:(config-l2vpn-xc)# p2p CE4-CE1
:(config-l2vpn-xc-p2p)# int pos0/3/0/2
:(config-l2vpn-xc-p2p)# neighbor 10.1.1.1
pw-id 3001
:(config-l2vpn-xc-p2p-pw)# pw-class TEST
PE3
:(config)# interface pos0/3/1/2 l2transport
:(config)# l2vpn
:(config-l2vpn)# pw-class TEST
:(config-l2vpn-pwc)# encapsulation mpls
:(config-l2vpn)# xconnect group TEST-GROUP
:(config-l2vpn-xc)# p2p CE4-CE1
:(config-l2vpn-xc-p2p)# int pps0/3/1/2
:(config-l2vpn-xc-p2p)# neighbor 10.1.1.1
pw-id 3002
:(config-l2vpn-xc-p2p-pw)# pw-class TEST
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/38
753
Layer 2 VPNs
Module 7
Introduction to VPLS
Virtual private LAN service (VPLS) is a Layer 2 service that emulates a
LAN across an IP or MPLS-enabled IP network. It lets standard Ethernet
devices communicate with each other, as if they were connected to a
common LAN segment.
In a VPLS topology, the MPLS WAN acts like a virtual switch that
emulates a conventional Layer 2 bridge. The WAN supports
communication between fully meshed Layer 2 sites, without the challenges
of the spanning tree protocol.
A common VC ID is used between PEs to create part of a virtual switching
instance (VSI). PEs learn and store VPN site MAC addresses, as well as
allocate and exchange labels for them. The full mesh of targeted LDP
sessions exchange VC labels.
Both VPLS and EoMPLS have the same data plane and Layer 2 PDU
handling. However, EoMPLS is for point-to-point connectivity and VPLS
supports multipoint connectivity.
754
Version 4.0.1
Module 7
Introduction to VPLS
CE
VPLS network
PE
CE
MPLS core
Full mesh of
pseudowires
CE
Version 3.9.0a
XMPLST4Module #/40
Instructors Note
RFC 4762 Virtual Private LAN Service over LDP
Version 4.0.1
755
Layer 2 VPNs
Module 7
Virtual Circuit (VC) labelIdentifies the VFI; one or more VCs can
belong to same VFI. Multiple VFIs can exist on the same PE to
separate user traffic like VLANs
Instructors Note
Review the definitions above. The configuration sample is intended to provide a link between the
definitions and the configuration to help students obtain understanding of what they are going to
do in the lab exercise.
The forwarding table capture shows how the bridge domain integrates both the ACs and PWs.
The configuration and show command captures are reviewed in more detail later in this section.
756
Version 4.0.1
Module 7
Bridge module
VFI
Pseudowires
Attachment circuits
Provider core
Customer network
XMPLST4Module #/42
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/43
757
Layer 2 VPNs
Module 7
758
Version 4.0.1
Module 7
Aggregation
Access
PSN
Aggregation
Access
Internet
VLAN 100
termination
MPLS
VLAN
200
VLAN 200
transport
VPWS
IP
Ethernet
VPLS
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/44
759
Layer 2 VPNs
Module 7
760
Version 4.0.1
Module 7
Feature
MPLS core network emulates a
flat LAN segment
Benefits
Overcomes distance limitations of
Ethernet-switched networks
Enables virtual private LAN services
Customers maintain routing and
administrative autonomy
Multipoint plug-and-play
provisioning
Version 3.9.0a
XMPLST4Module #/45
Instructors Note
VPLS is an IETF superset framework for two services defined by the Metro Ethernet Forum.
The services are Transparent LAN Service (TLS), called Ethernet multipoint service (Cisco
Systems, Inc.); and Ethernet Virtual Connection Service, called Ethernet relay multipoint service
(Cisco Systems, Inc.)(IETF).
Version 4.0.1
761
Layer 2 VPNs
Module 7
762
Version 4.0.1
Module 7
CE
AccessPE
Aggregation and
distribution
N-PE
Aggregation and
distribution
MPLS core
N-PE
AccessPE
CE
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/46
763
Layer 2 VPNs
Module 7
VPLS Architectures
The VPLS network uses two basic architectures, known as direct
attachment (flat VPLS) and hierarchical VPLS (H-VPLS).
764
Version 4.0.1
Module 7
!Direct
!Hierarchical
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/47
765
Layer 2 VPNs
Module 7
766
Version 4.0.1
Module 7
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/48
767
Layer 2 VPNs
Module 7
768
The packet is sent into the core with the addition of a PW label and
LSP (IGP) label
At the penultimate hop router, the LSP label is popped and the Layer 2
packet, with the PW label, is sent on to the appropriate N-PE
Version 4.0.1
Module 7
CE1
Aggregation and
distribution
N-PE
Ethernet
(VLAN or port)
Data
SMAC1 DMAC2
802.1q
Customer
Data
SMAC1 DMAC2
Version 3.9.0a
Version 4.0.1
PW
CE2
Ethernet
(VLAN or port)
Data
Aggregation and
distribution
MPLS core
N-PE
LSP
SMAC1 DMAC2
Pseudowire
service provider
core
XMPLST4Module #/49
769
Layer 2 VPNs
Module 7
770
The LDP protocol has been enhanced to work more effectively with
VPLS. A MAC list TLV label withdrawal message has been added to
LDP
Version 4.0.1
Module 7
Version 3.9.0a
XMPLST4Module #/50
Instructors Note
All VLANs on a port use the same MAC address if they are on the same bridge.
Version 4.0.1
771
Layer 2 VPNs
Module 7
772
Version 4.0.1
Module 7
Pseudowire in LSP
Unknown DMAC?
Data
SMAC DMAC?
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/51
773
Layer 2 VPNs
Module 7
774
Version 4.0.1
Module 7
Send me frames
using label 102
MAC1
PE1
CE1
Adj
MAC 2
170
MAC 1
E0/0
Use VC
label 170
PE1
Data
102
DMAC1 SMAC2
SMAC1 DMAC2
MAC2
PE2
Use VC
label 102
E0/0
MAC address
Send me frames
using label 170
Directed LDP
170
Data
CE2
E0/1
MAC address
Adj
MAC 2
E0/1
MAC 1
102
PE2
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/52
775
Layer 2 VPNs
Module 7
Loop Prevention
VPLS uses split horizon to prevent routing loops in the core. This
functionality is automatically implemented between VPLS VCs when they
are created. Therefore neighbors do not advertise any information out a VC
that they learned on that VC.
776
Version 4.0.1
Module 7
Loop Prevention
MPLS
VFI
VFI
VFI
N-PE4
N-PE6
N-PE5
Loop Prevention
Split-Horizon
! Split-horizon is automatically implemented between VPLS VCs
" Result is a blocking action
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/53
777
Layer 2 VPNs
Module 7
4. Define the VPLS VFI linked to the bridge domain (This action
associates PWs with the VFI)
778
Version 4.0.1
Module 7
MPLS
VFI
VFI
N-PE4
VFI
N-PE5
N-PE6
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/54
779
Layer 2 VPNs
Module 7
780
List of ACs by physical port description, state, and the static MAC
addresses defined for the port
List of VFIs by name, with neighbors, PW-IDs, state, and static MAC
address information
Version 4.0.1
Module 7
MPLS
VFI
VFI
N-PE4
VFI
N-PE5
N-PE6
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/55
781
Layer 2 VPNs
Module 7
782
Version 4.0.1
Module 7
MPLS
VFI
VFI
N-PE4
VFI
N-PE5
N-PE6
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/56
783
Layer 2 VPNs
Module 7
H-VPLS
784
Version 4.0.1
Module 7
Flat VPLS
H-VPLS
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/58
785
Layer 2 VPNs
Module 7
Hierarchical VPLS
H-VPLS consists of two distinct levels, hub and spoke:
786
Spoke
!
Q-in-Q (Layer 2)
EoMPLS (Layer 2)
MPLS (Layer 3)
L2TPv3 (Layer 3)
Hub
!
Version 4.0.1
Module 7
Hierarchical VPLS
Hub
! Q-in-Q (L2)
! EoMPLS (L2)
! MPLS (L3)
! L2TPv3 (L3)
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/59
787
Layer 2 VPNs
Module 7
788
Customers keep their own VLANs; service providers do not assign them
Version 4.0.1
Module 7
Company
B
Company
A
VLAN# 20 - 30 overlap
VLAN# 10 30
VLAN# 20 - 40
Service provider
network
Company
A
Company
B
VLAN# 10 - 30
VLAN# 20 - 40
Version 3.9.0a
XMPLST4Module #/61
Data
FCS
(0 - 1500 Bytes) (4 Bytes)
CE 802.1q Tag
(2 Bytes)
Length/Etype Data
FCS
(2 Bytes)
(0 - 1500 Bytes) (4 Bytes)
Q tag
802.1ad Double-Tagged Ethernet frame
DA
(6 Bytes)
SA
(6 Bytes)
Ether Type
8100
SP 802.1q
(2 Bytes)
S-tag
Ether Type
8100
CE 802.1q Tag
(2 Bytes)
Length/Etype
(2 Bytes)
Data
(0 - 1500 Bytes)
FCS
(4 Bytes)
Inner tag
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/62
789
Layer 2 VPNs
Module 7
MPLS PW Access
The N-PEs in the core are fully meshed through PWs. U-PEs in the bottom
tier have one PW that connects to the N-PE, which becomes a hub and
spoke model.
Version 4.0.1
Module 7
CE
CE
CE
(MPLS Core)
U-PE A
N-PE 1
PW
U-PE B
N-PE 2
VPLS
U-PE A
(MPLS Core)
N-PE 1
MPLS
CE
(Q-in-Q)
MPLS
VPLS
STP
(Q-in-Q)
Layer 2
Version 3.9.0a
Version 4.0.1
U-PE B
PW
N-PE 2
XMPLST4Module #/63
791
Layer 2 VPNs
Module 7
792
Version 4.0.1
Module 7
AccessPE
CE1
Aggregation and
distribution
N-PE
Aggregation and
distribution
MPLS core
N-PE
AccessPE
Service
provider
Ethernet
transport
Service
provider
Ethernet
transport
802.1q
access
Q-in-Q
tunnel
Data
VLAN
CE
CE2
SMAC1 DMAC2
Data
802.1q
access
802.1q
customer
VLAN VLAN
CE
SP
3
2011, Cisco Systems, Inc. All rights reserved.
Q-in-Q
tunnel
Data
SMAC1 DMAC2
VLAN
CE
Q-in-Q
service provider edge
SMAC1 DMAC2
Version 3.9.0a
Version 4.0.1
PW
LSP
Pseudowire
service provider core
XMPLST4Module #/64
793
Layer 2 VPNs
Module 7
MPLS Access
CE to U-PE connectivity may be 802.1q or port mode Ethernet. Packets
arriving at the U-PE are directed using EoMPLS to the N-PE router. The
U-PE attachment circuit is mapped to a PW and carried to the N-PE using
the LSP label obtained from LDP in the MPLS access network.
The MPLS core is a full mesh of VPLS PWs. The EoMPLS packet arriving
at the N-PE is mapped into the N-PE bridge domain using the same PW-ID
as the core PWs in the VPLS bridge domain.
On the adjacent page the PW-ID in the core matches the PW-ID used at
the edge, and the LSP label is derived in the core using LDP.
794
Version 4.0.1
Module 7
MPLS Access
AccessPE
CE1
Aggregation and
distribution
N-PE
MPLS core
Aggregation and
distribution
N-PE
MPLS
access
802.1q
access
MPLS
pseudowire
VLAN
CE
Data
VLAN
CE
3
Full mesh PWs + LDP
SMAC1 DMAC2
MPLS
pseudowire
802.1q
access
802.1q
customer
3
2011, Cisco Systems, Inc. All rights reserved.
CE2
MPLS
access
SMAC1 DMAC2
Data
AccessPE
PW
Data
LSP
VLAN
CE
Version 3.9.0a
Version 4.0.1
MPLS PW
SP Edge
SMAC1 DMAC2
PW
Pseudowire
LSP service provider
core
XMPLST4Module #/65
795
Layer 2 VPNs
Module 7
Split-Horizon Rules
By default, split horizon is enabled in a bridge domain. Any packets
arriving on either the attachment circuits or pseudowires are not returned
on the same attachment circuits or pseudowires. In addition, the packets
received on one pseudowire are not replicated on other pseudowires in the
same VFI.
Split-horizon and non-split-horizon rules may be summed up as packets
traveling between:
796
Version 4.0.1
Module 7
Split-Horizon Rules
MPLS
MPLS
AC
N-PE3
AC
VFI
VFI
AC
MPLS
VFI
N-PE4
U-PE4
U-PE3
N-PE1
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/66
797
Layer 2 VPNs
Module 7
U-PE2
N-PE3
798
Create the VFI and add the neighbor statements for the N-PE1 and
N-PE4 routers, with the matching PW-ID (3001) and PW class
Version 4.0.1
Module 7
AC
MPLS G0/5/1/0
U-PE3 10.33.3.3
AC
G0/4/0/0 U-PE2 10.22.2.2
VFI
VFI
N-PE3
10.3.3.3
MPLS
MPLS
VFI
N-PE1 10.1.1.1
N-PE4
10.4.4.4
U-PE4
U-PE3
U-PE2
:(config)# interface Gig0/4/0/0 l2transport
:(config)# l2vpn
:(config-l2vpn)# pw-class TEST
:(config-l2vpn-pwc)# encap mpls
:(config-l2vpn)# xconnect group TEST-GROUP
:(config-l2vpn-xc)# p2p UPE2-NPE3
:(config-l2vpn-xc-p2p)# interface Gig0/4/0/0
:(config-l2vpn-xc-p2p)# neighbor 10.3.3.3 pw-id 3001
:(config-l2vpn-xc-p2p-pw)# pw-class TEST
Version 3.9.0a
AC
MPLS G0/5/1/0
U-PE3 10.33.3.3
AC
G0/4/0/0 U-PE2 10.22.2.2
MPLS
MPLS
VFI
VFI
N-PE3
10.3.3.3
XMPLST4Module #/68
VFI
N-PE1 10.1.1.1
N-PE4
10.4.4.4
U-PE4
N-PE3
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/69
799
Layer 2 VPNs
Module 7
7100
MAC parameters, including aging time, MAC address limit, any action
to be taken if the limit is exceeded, the notification process if the limit
is exceeded, and MAC filter information
ACs configured (G0/5/1/0), showing this AC with one VFI that has four
PWs, and that they are all up
List of ACs within the bridge domain, their status, and any static MAC
addresses defined
List of defined access PWs and their state for an H-VPLS configuration
List of VFIs with their PW-IDs, their state, and any defined static MAC
addresses
Version 4.0.1
Module 7
AC
MPLS G0/5/1/0
U-PE3 10.33.3.3
AC
G0/4/0/0 U-PE2 10.22.2.2
VFI
VFI
N-PE3
10.3.3.3
MPLS
MPLS
VFI
N-PE1 10.1.1.1
N-PE4
10.4.4.4
U-PE4
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/70
7101
Layer 2 VPNs
Module 7
One AC, one VFI with four PWs that are all operational on N-PE3
AC interfaces, with state, type, and full Layer 2 details for the bridge
group
7102
Table that comparing the local and remote ends of the PW for the
neighbor relationship
Version 4.0.1
Module 7
AC
MPLS G0/5/1/0
U-PE3 10.33.3.3
AC
G0/4/0/0 U-PE2 10.22.2.2
VFI
VFI
N-PE3
10.3.3.3
MPLS
MPLS
VFI
N-PE1 10.1.1.1
N-PE4
10.4.4.4
U-PE4
10.3.3.3
N-PE1 10.1.1.1
10.4.4.4
3.9.0a
XMPLST4Module #/72
2011, Cisco Systems, Inc. All rights reserved.
Security:
disabled Split Horizon Group:Version
none
DHCPv4 snooping: disabled
IGMP Snooping profile: none Storm Control: disabled Static MAC addresses:
Statistics: packets: received 84700, sent 25934 bytes: received 7140788, sent 1652893
Storm control drop counters: packets: broadcast 0, multicast 0, unknown unicast 0
List of Access PWs:
List of VFIs:
VFI CLASS-VFI PW: neighbor 10.4.4.4, PW ID 3001, state is up ( established )
PW class TEST, XC ID 0xff000007 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
16005
16012
Group ID
0x0
0x0
Interface
CLASS-VFI
CLASS-VFI
MTU
1500
1500
Control word disabled
disabled
PW type
Ethernet
Ethernet
VCCV CV type 0x2 (LSP ping verification)
0x2 (LSP ping verification)
VCCV CC type 0x6 (router alert label)
0x6 (router alert label)
(TTL expiry)
(TTL expiry)
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/73
7103
Layer 2 VPNs
Module 7
7104
Version 4.0.1
Module 7
AC
MPLS G0/5/1/0
U-PE3 10.33.3.3
AC
G0/4/0/0 U-PE2 10.22.2.2
VFI
VFI
N-PE3
10.3.3.3
MPLS
MPLS
VFI
N-PE1 10.1.1.1
N-PE4
10.4.4.4
U-PE4
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/74
7105
Layer 2 VPNs
Module 7
H-VPLS Redundancy
Pseudowire redundancy allows you to configure your network to detect a
failure and reroute the Layer 2 service to another endpoint that can
continue to provide service. This feature provides the ability to recover
from a failure of either the remote provider edge (PE) router or the link
between the PE and customer edge (CE) routers.
Pseudowire redundancy involves configuring the network with redundant
pseudowires and redundant network elements.
7106
Version 4.0.1
Module 7
H-VPLS Redundancy
U-PE
CE
N-PE21
N-PE11
VFI
VFI
VFI
VFI
N-PE12
N-PE22
VFI
N-PE31
! Active PW fails
! U-PE will switch to the backup PW
Link or node failure in the MPLS cloud triggers TE FRR
! PW will cut-over to different TE tunnel
! U-PE will keep original active PW instead of switchover to
backup PW
Version 3.9.0a
U-PE1
Primary PW
XMPLST4Module #/77
N-PE2
N-PE1 Primary
VFI
VFI
Primary PW
U-PE3
MPLS Core
U-PE2
Primary PW
VFI
VFI
N-PE4
N-PE3 Backup
Primary PW
U-PE4
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/78
7107
Layer 2 VPNs
Module 7
7108
Version 4.0.1
Module 7
H-VPLS Redundancy
" Minimizes traffic black holes by pushing all N-PEs within the core to
flush all MAC associations for the failed peer
Version 3.9.0a
XMPLST4Module #/79
Instructor's Note
A PW failure nay be detected by several different protocols, VCCV, LDP TCP session failure, or
IGP failure
2011 Cisco Systems, Inc.
Version 4.0.1
7109
Layer 2 VPNs
Module 7
7110
Version 4.0.1
Module 7
Traffic from U-PE2 through N-PE2 to N-PE1 for U-PE1 is lost while backup
N-PE3 becomes active and updates N-PE2
Solution:
Expedite MAC address flushing on N-PE2 while backup N-PE3 activates
and then updates N-PE2. U-PE1 sends MAC withdrawal to N-PE3 which
flushes its table and forwards message to N-PE2 to flush its table
U-PE1
N-PE1
N-PE2
U-PE3
2011, Cisco Systems, Inc. All rights reserved.
U-PE2
N-PE3
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/81
7111
Layer 2 VPNs
Module 7
Relearns the association between the MAC address and the interface or
PW over which this message is received
Sends the same message to all other PEs over the corresponding
directed LDP sessions
7112
Version 4.0.1
Module 7
Directed LDP
MPLS
M
withdAC
rawal
MAC wal
dra
t
i
w h
Version 3.9.0a
XMPLST4Module #/82
Instructor's Note
The IETF standard specifies a TLV withdrawal message setting a list of MAC addresses to be
withdrawn or the use of a null list. The null list standard means flush the entire MAC table.
Cisco IOS XR uses the null list in the MAC withdrawal message.
Version 4.0.1
7113
Layer 2 VPNs
Module 7
Instructor's Note
The mac-withdraw command on U-PE1 has been attached to pw-class. On the N-PE bridge
domain, MAC withdraw is the default mode of operation. This command can be disabled for the
bridge domain, using the MAC withdraw disable command. Note the syntax difference when
used in a pw-class versus a bridge domain.
7114
Version 4.0.1
Module 7
U-PE110.11.1.1
N-PE1 Primary
G0/4/0/4
PE2
10.1.1.1
G0/5/0/2 VFI
VFI
MPLS Core
CE
10.2.2.2
CE
MPLS
PW
VFI
G0/4/0/4 U-PE3 10.33.3.3
U-PE1
:# configure
:(config)# l2vpn
:(config-l2vpn)# pw-class REDUNDANCY
:(config-l2vpn-pwc)# encapsulation
N-PE1 Primarympls
U-PE110.11.1.1
PE2
10.1.1.1
:(config-l2vpn-pwc)#
mac-withdraw
:(config-l2vpn)# xconnect
group
A
VFI
G0/5/0/2
VFI
G0/4/0/4
CE
:(config-l2vpn-xc)#
p2p UPE1-NPE
MPLS Core
10.2.2.2
:(config-l2vpn-xc-p2p)# interface Gig0/4/0/4
MPLS
:(config-l2vpn-xc-p2p)#
neighbor 10.1.1.1 pw-id 2
PW
:(config-l2vpn-xc-p2p-pw)# pw-class REDUNDANCY
VFI
:(config-l2vpn-xc-p2p-pw)# backup neighbor 10.3.3.3 pw-id 2
G0/4/0/4
10.3.3.3
:(config-l2vpn-xc-p2p-pw)#
pw-class
REDUNDANCY
U-PE3 10.33.3.3
N-PE3
Backup
CE
Version 3.9.0a
XMPLST4Module #/84
N-PE1
:# configure
:(config)# l2vpn
:(config-l2vpn)# pw-class
CLASS1
N-PE1
Primary
U-PE110.11.1.1 encapsulation
:(config-l2vpn-pwc)#
mpls
PE2
10.1.1.1
:(config-l2vpn)# bridge group CLASS-LAB
G0/5/0/2 VFI
VFI
G0/4/0/4
:(config-l2vpn-bg)#
bridge-domain CLASS-DOMAIN
CE
CE
MPLS
Core
10.2.2.2
:(config-l2vpn-bg-bd)# interface Gig0/5/2/0
MPLS
:(config-l2vpn-bg-bd-ac)# neighbor 10.11.1.1 pw-id 2
PW
:(config-l2vpn-bg-bd)#
vfi CLASS-VFI
VFI neighbor 10.2.2.2 pw-id 2 pw-class CLASS1
:(config-l2vpn-bg-bd-vfi)#
:(config-l2vpn-bg-bd-vfi)#
neighbor
10.3.3.3
pw-id 2 pw-class CLASS1
G0/4/0/4 U-PE3 10.33.3.3
10.3.3.3
N-PE3
Backup
Version 3.9.0a
XMPLST4Module #/86
N-PE1 (continued)
:(config-l2vpn-bg)# bridge-domain CLASS-DOMAIN5
:(config-l2vpn-bg-bd)# interface Gig0/5/2/0
:(config-l2vpn-bg-bd-ac)# neighbor 10.33.3.3 pw-id 5
:(config-l2vpn-bg-bd)# vfi CLASS-VFI
:(config-l2vpn-bg-bd-vfi)# neighbor 10.2.2.2 pw-id 5 pw-class CLASS1
:(config-l2vpn-bg-bd-vfi)# neighbor 10.3.3.3 pw-id 5 pw-class CLASS1
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/87
7115
Layer 2 VPNs
Module 7
VPLS Auto-Discovery
This section covers the automatic discovery of members of a VPLS domain.
7116
Version 4.0.1
Module 7
VPLS Auto-Discovery
VPLS Auto-Discovery
No flexibility
VPLS with auto-discovery
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/89
7117
Layer 2 VPNs
Module 7
BGP with auto-discovery protocol, where the peers use BGP signaling
Instructor's Note
BGP-AD with LDP signaling is currently supported only on the ASR 9000 router series and is to
be supported on all platforms in Rel 4.0.1.
Auto-discovery is a BGP extended community for PW-ID. The configuration commands:
router BGP
l2vpn
address-family
7118
Version 4.0.1
Module 7
VPLS Auto-Discovery
Point-to-multipoint task
Point-to-point task
Distributed
BGP
LDP (manual config)
Auto-discovery
Instructor's Note
BGP-AD with LDP signaling is only supported on ASR 9000 at 3.9.1 and on all platforms at 4.0.1
Version 4.0.1
7119
Layer 2 VPNs
Module 7
7120
Version 4.0.1
Module 7
VPLS Auto-Discovery
VPN-ID
Version 3.9.0a
XMPLST4Module #/94
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/95
7121
Layer 2 VPNs
Module 7
7122
Version 4.0.1
Module 7
VPLS Auto-Discovery
customers
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/96
7123
Layer 2 VPNs
Module 7
MPLS LDP
!
7124
Router BGP
!
IPv4 and L2VPN address families are enabled for the BGP process
L2VPN
!
Version 4.0.1
Module 7
VPLS Auto-Discovery
10.5.5.5
G0/4/0/4
PE4
PE5
G0/4/0/4
CE5
10.4.4.4
CE4
MPLS Core
10.6.6.6 PE6
G0/4/0/4
CE6
G0/4/0/5
G0/4/0/5
Version 3.9.0a
G0/4/0/4
CE5
G0/4/0/4
CE6
XMPLST4Module #/98
:PE4(config)# l2vpn
:PE4(config-l2vpn)# bridge group TEST-BRIDGE
:PE4(config-l2vpn-bg)# bridge-domain TEST-DOMAIN
:PE4(config-l2vpn-bg-bd)# interface GigabitEthernet0/4/0/4
!
:PE4(config-l2vpn-bg-bd)# vfi CLASS
! Auto-discovery independent VFI attributes
:PE4(config-l2vpn-bg-bd-vfi)# vpn-id 1000
! Auto-discovery attributes
:PE4(config-l2vpn-bg-bd-vfi)# autodiscovery bgp
:PE4(config-l2vpn-bg-bd-vfi-ad)# rd auto
:PE4(config-l2vpn-bg-bd-vfi-ad)# route-target import 10:10
:PE4(config-l2vpn-bg-bd-vfi-ad)# route-target export 10:10
! Signaling attributes
:PE4(config-l2vpn-bg-bd-vfi-ad)# signaling-protocol bgp
:PE4(config-l2vpn-bg-bd-vfi-ad)# ve-id 4
2011, Cisco Systems, Inc. All rights reserved.
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/99
7125
Layer 2 VPNs
Module 7
BGP router ID, local AS, scan interval, table state and ID, and table
version
Local edge is the attachment circuit, with the local label displayed
Remote edge displays the remote PE devices and the VPLS labels that
represent them
Instructor's Note
Other useful show commands:
show l2vpn bridge detail
show bgp l2vpn vpls
show mpls label table
7126
Version 4.0.1
Module 7
VPLS Auto-Discovery
10.5.5.5
G0/4/0/4
PE4
CE4
PE5
G0/4/0/4
CE5
10.4.4.4
MPLS Core
10.6.6.6 PE6
G0/4/0/4
CE6
Version 3.9.0a
XMPLST4Module #/100
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/101
7127
Layer 2 VPNs
Module 7
7128
MPLS switching label; local label representing PE4, and remote label
representing PE5
PW type is VPLS
Version 4.0.1
Module 7
VPLS Auto-Discovery
10.5.5.5
G0/4/0/4
PE4
CE4
PE5
G0/4/0/4
CE5
10.4.4.4
MPLS Core
10.6.6.6 PE6
G0/4/0/4
CE6
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/102
7129
Layer 2 VPNs
Module 7
7130
Version 4.0.1
Module 7
VPLS Auto-Discovery
10.5.5.5
G0/4/0/4
PE4
CE4
PE5
G0/4/0/4
CE5
10.4.4.4
MPLS Core
10.6.6.6 PE6
G0/4/0/4
CE6
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/103
7131
Layer 2 VPNs
Module 7
Summary
Layer 2 VPNs
In this module, you learned the following:
7132
Define AToM, its use, and interworking with Cisco IOS XR operating
system software
Version 4.0.1