MPLS Cisco

1 2001, Cisco Systems, Inc. All rights reserved.
Session Number
Presentation_ID
MPLS Introduction
2 2 2 2001, Cisco Systems, Inc. All rights reserved. Presentation_ID 2
Agenda
Introduction to MPLS
LDP
MPLS VPN
Monitoring MPLS
MPLS Concept
In Core:
Forward using labels
(as opposed to IP
addr)
Label indicates service
class and destination
Label Switch
Router (LSR)
Router
ATM switch +
Tag Switch
Controller
Label Distribution
Protocol (LDP)
Edge Label
Switch
Router
(ATM Switch or
Router)
At Edge:
Classify packets
Label them
MPLS concept
MPLS: Multi Protocol Label Switching
Packet forwarding is done based on Labels.
Labels are assigned when the packet enters into
the network.
Labels are on top of the packet.
MPLS nodes forward packets/cells based on the
label value (not on the IP information).
MPLS concept
MPLS allows:
Packet classification only where the packet
enters the network.
The packet classification is encoded as a label.
In the core, packets are forwarded without
having to re-classify them.
- No further packet analysis
- Label swapping
MPLS Operation
1a. Existing routing protocols (e.g. OSPF, IS-IS)
establish reachability to destination networks.
1b. Label Distribution Protocol (LDP)
establishes label to destination
network mappings.
2. Ingress Edge LSR receives packet,
performs Layer 3 value-added
services, and labels(PUSH) packets.
3. LSR switches packets using
label swapping(SWAP) .
4. Edge LSR at egress
removes(POP) label
and delivers packet.
Label Switch Path (LSP)

LSPs are derived from IGP routing information
LSPs may diverge from IGP shortest path
LSPs are unidirectional
Return traffic takes another LSP

LSP follows IGP shortest path LSP diverges from IGP shortest path
IGP domain with a label
distribution protocol
Encapsulations
Label Header PPP Header Layer 3 Header
PPP Header
(Packet over SONET/SDH)
ATM Cell Header
HEC
Label
DATA CLP PTI VCI GFC VPI
Label Header MAC Header Layer 3 Header
LAN MAC Label Header
Label Header
Header= 4 bytes, Label = 20 bits.
Can be used over Ethernet, 802.3, or PPP links
Contains everything needed at forwarding time
Label = 20 bits EXP = Class of Service, 3 bits
S = Bottom of Stack, 1 bit TTL = Time to Live, 8 bits
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Label EXP S TTL
Loops and TTL
In IP networks TTL is used to prevent packets
to travel indefinitely in the network
MPLS may use same mechanism as IP, but not
on all encapsulations
TTL is present in the label header for PPP and LAN
headers (shim headers)
ATM cell header does not have TTL
Loops and TTL
TTL is decremented prior to enter the non-TTL capable
LSP
If TTL is 0 the packet is discarded at the ingress point
TTL is examined at the LSP exit
LSR-1
LSR-2
LSR-4
LSR-5
LSR-
3
LSR-6
Egress
IP packet
TTL = 6

Label = 25
IP packet
TTL = 6

IP packet
TTL = 10

LSR-6 --> 25
Hops=4
IP packet
TTL = 6

Label = 39
IP packet
TTL = 6

Label = 21
Label Assignment and Distribution
Labels have link-local significance:
Each LSR binds his own label mappings
Each LSR assign labels to his FECs
Labels are assigned and exchanged
between adjacent neighboring LSR
Label Assignment and Distribution
Rtr-C is the downstream neighbor of Rtr-B for destination
171.68.10/24
Rtr-B is the downstream neighbor of Rtr-A for destination
171.68.10/24
LSRs know their downstream neighbors through the IP routing
protocol
Next-hop address is the downstream neighbor
171.68.10/24
Rtr-B Rtr-A Rtr-C
171.68.40/24
Upstream and Downstream LSRs
Unsolicited Downstream Distribution

LSRs distribute labels to the upstream neighbors
171.68.10/24
Rtr-B Rtr-A Rtr-C
171.68.40/24
Next-Hop
In
Lab
-
...
Address
Prefix
171.68.10
...
Out
I/F
1
...
Out
Lab
30
...
In
I/F
0
... Next-Hop
In
Lab
30
...
Address
Prefix
171.68.10
...
Out
I/F
1
...
Out
Lab
40
...
In
I/F
0
...
Next-Hop
In
Lab
40
...
Address
Prefix
171.68.10
...
Out
I/F
1
...
Out
Lab
-
...
In
I/F
0
...
Use label 40 for destination
171.68.10/24
171.68.10/24
IGP derived routes
On-Demand Downstream Distribution

Upstream LSRs request labels to downstream neighbors
Downstream LSRs distribute labels upon request
171.68.10/24
Rtr-B Rtr-A Rtr-C
171.68.40/24
171.68.10/24
171.68.10/24
Request label for
destination 171.68.10/24
Request label for
destination 171.68.10/24
Liberal retention mode
LSR retains labels from all neighbors
Improve convergence time, when next-hop is again available
after IP convergence
Require more memory and label space

Conservative retention mode
LSR retains labels only from next-hops neighbors
LSR discards all labels for FECs without next-hop
Free memory and label space
Label Retention Modes
Independent LSP control
LSR binds a Label to a FEC independently, whether or not the LSR has
received a Label the next-hop for the FEC
The LSR then advertises the Label to its neighbor

Ordered LSP control
LSR only binds and advertise a label for a particular FEC if:
it is the egress LSR for that FEC or
it has already received a label binding from its next-hop
Label Distribution Modes
Router Example: Forwarding Packets
0
171.69
Packets Forwarded
Based on IP Address
Data
Address
Prefix
128.89
171.69
1
1
I/F

Address
Prefix
128.89
171.69
0
1

0
1
I/F
128.89 0
1
128.89.25.4 Data

Address
Prefix
128.89 0

I/F
Data Data 128.89.25.4 128.89.25.4
128.89.25.4
MPLS Example: Routing Information
128.89
1
0
1
0
Routing Updates
(OSPF, EIGRP, )
You Can Reach 128.89 and
171.69 Thru Me
You Can Reach 171.69 Thru
Me
You Can Reach 128.89 Thru
Me
In
Label
Address
Prefix
128.89
171.69
1
1
Out
Iface
Out
Label
In
Label
Address
Prefix
128.89
171.69
0
1
Out
Iface
Out
Label

In
Label
Address
Prefix
128.89 0
Out
Iface
Out
Label

171.69
MPLS Example: Assigning Labels
128.89
1
0
1
0
Label Distribution
Protocol (LDP)
(downstream allocation)
Use Label 4 for 128.89 and
Use Label 5 for 171.69
In
Label
Address
Prefix
128.89
171.69
1
1
Out
Iface
Out
Label
In
Label
Address
Prefix
128.89
171.69
0
1
Out
Iface
Out
Label
In
Label
Address
Prefix
128.89 0
Out
Iface
Out
Label
- 9

9
7
4
5
4
5
-
-
171.69
In
Label
Address
Prefix
128.89
171.69
1
1
Out
Iface
Out
Label

4
5
-
-
MPLS Example: Forwarding Packets
Label Switch Forwards
Based on Label
In
Label
Address
Prefix
128.89
171.69
0
1
Out
Iface
Out
Label

9
7
4
5
In
Label
Address
Prefix
128.89 0
Out
Iface
Out
Label
- 9

Data 128.89.25.4 Data
128.89.25.4 Data
128.89.25.4 Data
128.89
1
0
1
0
128.89.25.4 4
9
Agenda
LDP
MPLS VPN
Monitoring MPLS
MPLS Unicast IP Routing
MPLS introduces a new field that is used for
forwarding decisions.
Although labels are locally significant, they have to
be advertised to directly reachable peers.
One option would be to include this parameter into
existing IP routing protocols.
The other option is to create a new protocol to exchange
labels.
The second option has been used because there are
too many existing IP routing protocols that would
have to be modified to carry labels.
Label Distribution Protocol
Defined in RFC 3036 and 3037
Used to distribute labels in a MPLS network
Forwarding equivalence class
How packets are mapped to LSPs (Label
Switched Paths)
Advertise labels per FEC
Reach destination a.b.c.d with label x
Neighbor discovery
Basic and extended discovery
MPLS Unicast IP Routing Architecture
LSR
Control plane
Data plane
Routing protocol
Label distribution protocol
Label forwarding table
IP routing table
Exchange of
routing information
Exchange of
labels
Incoming
labeled packets
Outgoing
labeled packets
IP forwarding table
Incoming
IP packets
Outgoing
IP packets
MPLS Unicast IP Routing: Example
LSR
Control plane
Data plane
OSPF:
RT:
LIB:
FIB:
LFIB:
OSPF: 10.0.0.0/8
10.0.0.0/8 1.2.3.4
10.0.0.0/8 1.2.3.4
10.0.0.0/8 1.2.3.4
L=5 10.1.1.1
10.1.1.1 10.1.1.1
MPLS Unicast IP Routing: Example
LSR
Control plane
Data plane
OSPF:
RT:
LIB:
FIB:
LFIB:
OSPF: 10.0.0.0/8
10.0.0.0/8 1.2.3.4
10.0.0.0/8 1.2.3.4
10.0.0.0/8 1.2.3.4
10.1.1.1
LDP: 10.0.0.0/8, L=3
L=5 10.1.1.1
10.0.0.0/8 Next-hop L=3, Local L=5
LDP: 10.0.0.0/8, L=5
L=3 10.1.1.1
L=3 10.1.1.1 L=5 L=3
, L=3
Label Allocation in Packet-Mode MPLS
Environment
Label allocation and distribution in packet-mode MPLS
environment follows these steps:
1. IP routing protocols build the IP routing table.
2. Each LSR assigns a label to every destination in the IP
routing table independently.
3. LSRs announce their assigned labels to all other LSRs.
4. Every LSR builds its LIB, LFIB data structures based on
received labels.
Building the IP Routing Table
IP routing protocols are used to build IP routing tables on all
LSRs.
Forwarding tables (FIB) are built based on IP routing tables
with no labeling information.
A B C D
E
Network X
Network Next-hop
X B
Routing table of A
Network Next-hop
X C
Routing table of B
Network Next-hop
X D
Routing table of C
Network Next-hop
X C
Routing table of E Network Next hop Label
X B
FIB on A
Allocating Labels
Every LSR allocates a label for every destination in the IP
routing table.
Labels have local significance.
Label allocations are asynchronous.
A B C D
E
Network X
Network Next-hop
X C
Routing table of B
Router B assigns label 25 to
destination X.
LIB and LFIB Set-up
LIB and LFIB structures have to be initialized on the LSR
allocating the label.
A B C D
E
Network X
Network Next-hop
X C
Routing table of B
Router B assigns label 25 to
destination X.
Label Action Next hop
25 pop C
LFIB on B
Outgoing action is POP as B
has received no label for X
from C.
Network LSR label
X local 25
LIB on B
Local label is stored in LIB.
Label Distribution
The allocated label is advertised to all neighbor LSRs,
regardless of whether the neighbors are upstream or
downstream LSRs for the destination.
A B C D
E
Network X
Network LSR label
X local 25
LIB on B
X = 25 X = 25
Receiving Label Advertisement
Every LSR stores the received label in its LIB.
Edge LSRs that receive the label from their next-hop also store
the label information in the FIB.
A B C D
E
Network X
X = 25 X = 25
Network LSR label
X B 25
LIB on A
Network LSR label
X B 25
LIB on C
Network LSR label
X B 25
LIB on E
Network Next hop Label
X B 25
FIB on A
Interim Packet Propagation
Forwarded IP packets are labeled only on the path segments
where the labels have already been assigned.
A B C
E
IP: X Lab: 25 IP: X
X B 25
FIB on A
IP lookup is performed in
FIB, packet is labeled.
25 pop C
LFIB on B
Label lookup is performed
in LFIB, label is removed.
Further Label Allocation
Every LSR will eventually assign a label for every destination.
A B C D
E
Network X
Router C assigns label
47 to destination X.
X = 47
Network LSR label
X B 25
local 47
LIB on C
47 pop D
LFIB on C
Receiving Label Advertisement
Every LSR stores received information in its LIB.
LSRs that receive their label from their next-hop LSR will also
populate the IP forwarding table (FIB).
A B C D
E
Network X
X = 47
Network LSR label
X B 25
C 47
LIB on E
Network LSR label
X local 25
C 47
LIB on B
X C 47
FIB on B
X C 47
FIB on E
Populating LFIB
Router B has already assigned label to X and created an entry
in LFIB.
Outgoing label is inserted in LFIB after the label is received
from the next-hop LSR.
A B C D
E
Network X
X = 47
Network LSR label
X local 25
C 47
LIB on B
X C 47
FIB on B
25 47 C
LFIB on B
Packet Propagation Across MPLS Network
A B C
E
IP: X Lab: 25 Lab: 47
X B 25
FIB on A
IP lookup is performed in
FIB, packet is labeled.
25 47 C
LFIB on B
in LFIB, label is switched.
47 pop D
LFIB on C
in LFIB, label is removed.
IP: X
Ingress LSR Egress LSR
Steady State Description
After the LSRs have exchanged the labels, LIB, LFIB and FIB
data structures are completely populated.
A B C D
E
Network X
Network Next-hop
X C
Routing table of B
X C 47
FIB on B
Network LSR label
X local 25
C 47
E 75
LIB on B
25 47 C
LFIB on B
Convergence in Packet-mode MPLS
Link Failure Actions
Routing protocol neighbors and
LDP neighbors are lost after a
link failure.
Entries are removed from
various data structures.
A B C D
E
Network X
Network Next-hop
X C
Routing table of B
X C 47
FIB on B
Network LSR label
X local 25
C 47
E 75
LIB on B
25 47 C
LFIB on B

Routing Protocol Convergence
Routing protocols rebuild the IP
routing table and the IP
forwarding table.
A B C D
E
Network X
Network LSR label
X local 25
C 47
E 75
LIB on B
25 47 C
LFIB on B

X E
FIB on B
Network Next-hop
X E
Routing table of B
MPLS Convergence
LFIB and labeling information in
FIB are rebuilt immediately after
the routing protocol convergence,
based on labels stored in LIB.
A B C D
E
Network X
Network LSR label
X local 25
C 47
E 75
LIB on B

Network Next-hop
X E
Routing table of B
25 75 E
LFIB on B
X E 75
FIB on B
MPLS Convergence After a Link Failure
MPLS convergence in packet-mode MPLS
does not impact the overall convergence
time.
MPLS convergence occurs immediately after
the routing protocol convergence, based on
labels already stored in LIB.
Link Recovery Actions
Routing protocol neighbors are
discovered after link recovery.
A B C D
E
Network X
Network LSR label
X local 25
C 47
E 75
LIB on B
Network Next-hop
X E
Routing table of B
25 75 E
LFIB on B
X E 75
FIB on B
IP Routing Convergence After Link
Recovery
IP routing protocols rebuild the IP
routing table.
FIB and LFIB are also rebuilt, but
the label information might be
lacking.
A B C D
E
Network X
Network LSR label
X local 25
C 47
E 75
LIB on B
25 75 E
LFIB on B
X E 75
FIB on B
Network Next-hop
X E
Routing table of B
C
C
pop C
MPLS Convergence After a Link Recovery
Routing protocol convergence optimizes the forwarding
path after a link recovery.
LIB might not contain the label from the new next-hop by
the time the IP convergence is complete.
End-to-end MPLS connectivity might be intermittently
broken after link recovery.
Use MPLS Traffic Engineering for make-before-break
recovery.
LDP Session Establishment
LDP and TDP use a similar process to establish a session:
Hello messages are periodically sent on all interfaces enabled for
MPLS.
If there is another router on that interface it will respond by trying
to establish a session with the source of the hello messages.
UDP is used for hello messages. It is targeted at all routers on
this subnet multicast address (224.0.0.2).
TCP is used to establish the session.
Both TCP and UDP use well-known LDP port number 646 (711
for TDP).
LDP Neighbor Discovery
1.0.0.1
1.0.0.3
MPLS_A
NO_MPLS_C
1.0.0.4
MPLS_D
1.0.0.2
MPLS_B
UDP: Hello
(1.0.0.1:1050 224.0.0.2:646)
UDP: Hello
(1.0.0.4:1033 224.0.0.2:646)
UDP: Hello
(1.0.0.2:1064 224.0.0.2:646)
UDP: Hello
(1.0.0.1:1051 224.0.0.2:646)
UDP: Hello
(1.0.0.4:1034 224.0.0.2:646)
UDP: Hello
(1.0.0.2:1065 224.0.0.2:646)
UDP: Hello
(1.0.0.1:1052 224.0.0.2:646)
UDP: Hello
(1.0.0.4:1035 224.0.0.2:646)
UDP: Hello
(1.0.0.2:1066 224.0.0.2:646)
LDP Session is established from the router with higher IP
address.
LDP Session Negotiation
Peers first exchange initialization messages.
The session is ready to exchange label mappings
after receiving the first keepalive.
1.0.0.1
MPLS_A
1.0.0.2
MPLS_B
Initialization message
Establish TCP session
Initialization message
Keepalive
Keepalive
MPLS Domain
Double Lookup Scenario
Double lookup is not an optimal way of
forwarding labeled packets.
A label can be removed one hop earlier.
10.0.0.0/8
L=19
10.0.0.0/8
L=18
10.0.0.0/8
L=17
LFIB
18 19
FIB
10/8 NH, 19
LFIB
17 18
FIB
10/8 NH, 18
LFIB
35 17
FIB
10/8 NH, 17
LFIB
19 untagged
FIB
10/8 NH
10.1.1.1 17

10.1.1.1 18

10.1.1.1 19

10.1.1.1

Double lookup is needed:
1. LFIB: remove the label.
2. FIB: forward the IP
packet based on IP next-
hop address.
10.0.0.0/8
Penultimate Hop Popping
MPLS Domain
A label is removed on the router before the
last hop within an MPLS domain.
10.0.0.0/8
L=pop
10.0.0.0/8
L=18
10.0.0.0/8
L=17
LFIB
18 pop
FIB
10/8 NH, 19
LFIB
17 18
FIB
10/8 NH, 18
LFIB
35 17
FIB
10/8 NH, 17
LFIB

FIB
10/8 NH
10.1.1.1 17

10.1.1.1 18

10.1.1.1

10.1.1.1

One single lookup.
10.0.0.0/8
Pop or implicit null
label is adveritsed.
Penultimate hop popping optimizes MPLS
performace (one less LFIB lookup).
PHP does not work on ATM (VPI/VCI cannot
be removed).
Pop or implicit null label uses value 3 when
being advertised to a neighbor.
LDP Messages
Discovery messages
Used to discover and maintain the presence of
new peers
Hello packets (UDP) sent to all-routers multicast
address
Once neighbor is discovered, the LDP session is
established over TCP
LDP Messages
Session messages
Establish, maintain and terminate LDP sessions
Advertisement messages
Create, modify, delete label mappings
Notification messages
Error signalling

Agenda
LDP
MPLS VPN
Monitoring MPLS
What Is a VPN?
VPN is a set of sites which are allowed to
communicate with each other.
VPN is defined by a set of administrative policies
Policies determine both connectivity and QoS
among sites.
Policies established by VPN customers.
Policies could be implemented completely by VPN service
providers.
Using BGP/MPLS VPN mechanisms
What Is a VPN? (Cont.)
Flexible inter-site connectivity
Ranging from complete to partial mesh
Sites may be either within the same or in different
organizations
VPN can be either intranet or extranet
Site may be in more than one VPN
VPNs may overlap
Not all sites have to be connected to the same service
provider
VPN can span multiple providers
IP VPN Taxonomy
Client-
Initiated
NAS-
Initiated
IP
Tunnel
Virtual
Circuit
Network-
Based VPNs
Security
Appliance
Router FR ATM
IP VPNs
DIAL DEDICATED
RFC 2547 Virtual
Router
MPLS-VPN Terminology
Provider Network (P-Network)
The backbone under control of a Service Provider
Customer Network (C-Network)
Network under customer control
CE router
Customer Edge router. Part of the C-network and
interfaces to a PE router
Site
Set of (sub)networks part of the C-network and co-
located
A site is connected to the VPN backbone through one
or more PE/CE links
PE router
Provider Edge router. Part of the P-Network and
interfaces to CE routers
P router
Provider (core) router, without knowledge of VPN
Route-Target
64 bits identifying routers that should receive the
route
Route Distinguisher
Attributes of each route used to uniquely identify
prefixes among VPNs (64 bits)
VRF based (not VPN based)
VPN-IPv4 addresses
Address including the 64 bits Route Distinguisher
and the 32 bits IP address

VRF
VPN Routing and Forwarding Instance
Routing table and FIB table
Populated by routing protocol contexts
VPN-Aware network
A provider backbone where MPLS-VPN is
deployed
MPLS VPN Connection Model
A VPN is a collection of sites sharing a
common routing information (routing table)
A site can be part of different VPNs
A VPN has to be seen as a community of
interest (or Closed User Group)
Multiple Routing/Forwarding instances
(VRF) on PE routers
A site belonging to different VPNs may or
MAY NOT be used as a transit point between
VPNs
If two or more VPNs have a common site,
address space must be unique among these
VPNs
Site-1
Site-3
Site-4
Site-2
VPN-A
VPN-C
VPN-B
The VPN backbone is composed by MPLS LSRs
PE routers (edge LSRs)
P routers (core LSRs)
PE routers are faced to CE routers and distribute
VPN information through
MP-BGP to other PE routers
VPN-IPv4 addresses, Extended Community,
Label
P routers do not run BGP and do not have any VPN
knowledge
VPN_A
VPN_A
VPN_B
10.3.0.0
10.1.0.0
11.5.0.0
P P
P P
PE
PE CE
CE
CE
VPN_A
VPN_B
VPN_B
10.1.0.0
10.2.0.0
11.6.0.0
CE
PE
PE
CE
CE
VPN_A
10.2.0.0
CE
iBGP sessions
P routers (LSRs) are in the core of the MPLS cloud
PE routers use MPLS with the core and plain IP with
CE routers
P and PE routers share a common IGP
PE router are MP-iBGP fully meshed
PE and CE routers exchange routing
information through:
EBGP, OSPF , RIPv2, Static routing
CE router run standard routing software
PE
CE
C
E
Site-2
Site-1
EBGP,OSPF, RIPv2,Static
PE routers maintain separate routing tables
The global routing table
With all PE and P routes
Populated by the VPN backbone IGP (ISIS or OSPF)
VRF (VPN Routing and Forwarding)
Routing and Forwarding table associated with one or more directly
connected sites (CEs)
VRF are associated to (sub/virtual/tunnel)interfaces
Interfaces may share the same VRF if the connected sites may share
the same routing information
PE
CE
C
E
Site-2
Site-1
VPN Backbone IGP (OSPF, ISIS)
EBGP,OSPF, RIPv2,Static
The routes the PE receives from CE routers are
installed in the appropriate VRF
The routes the PE receives through the backbone IGP
are installed in the global routing table
By using separate VRFs, addresses need NOT to be
unique among VPNs
PE
CE
C
E
Site-2
Site-1
VPN Backbone IGP EBGP,OSPF, RIPv2,Static
The Global Routing Table is populated by
IGP protocols.
In PE routers it may contain the BGP
Internet routes (standard BGP-4 routes)
BGP-4 (IPv4) routes go into global routing
table
MP-BGP (VPN-IPv4) routes go into VRFs

PE
VPN Backbone IGP
iBGP session
PE
P P
P
P
PE and P routers share a common IGP (ISIS or OSPF)
PEs establish MP-iBGP sessions between them
PEs use MP-BGP to exchange routing information
related to the connected sites and VPNs
VPN-IPv4 addresses, Extended Community, Label
PE-1
VPN Backbone IGP
PE-2
P P
P
P
PE routers receive IPv4 updates (EBGP, RIPv2, Static)
PE routers translate into VPN-IPv4
Assign a SOO and RT based on configuration
Re-write Next-Hop attribute
Assign a label based on VRF and/or interface
Send MP-iBGP update to all PE neighbors
BGP,RIPv2 update
for Net1,Next-
Hop=CE-1
VPN-IPv4 update:
RD:Net1, Next-hop=PE-
1
SOO=Site1, RT=Green,
Label=(intCE1)
CE-1
Site-2
VPN-IPv4 update is translated
into IPv4 address (Net1) put
into VRF green since RT=Green
and advertised to CE-2
Site-1
CE-2
Receiving PEs translate to IPv4
Insert the route into the VRF identified by the
RT attribute (based on PE configuration)
The label associated to the VPN-IPv4 address will be
set on packet forwarded towards the destination
PE-1
VPN Backbone IGP
PE-2
P P
P
P
BGP,OSPF, RIPv2
update for Net1
Next-Hop=CE-1
VPN-IPv4 update:
1
Label=(intCE1)
CE-1
Site-2
VPN-IPv4 update is translated
into IPv4 address (Net1) put
into VRF green since RT=Green
and advertised to CE-2
Site-1
CE-2
Route distribution to sites is driven by the Site of
Origin (SOO) and Route-target attributes
BGP Extended Community attribute
A route is installed in the site VRF corresponding to
the Route-target attribute
Driven by PE configuration
A PE which connects sites belonging to multiple
VPNs will install the route into the site VRF if the
Route-target attribute contains one or more VPNs to
which the site is associated
MP-BGP Update
VPN-IPV4 address
Route Distinguisher
64 bits
Makes the IPv4 route globally unique
RD is configured in the PE for each VRF
RD may or may not be related to a site or a VPN
IPv4 address (32bits)
Extended Community attribute (64 bits)
Site of Origin (SOO): identifies the originating site
Route-target (RT): identifies the set of sites the route has to
be advertised to
MP-BGP Update
Any other standard BGP attribute
Local Preference
MED
Next-hop
AS_PATH
Standard Community
...
A Label identifying:
The outgoing interface
The VRF where a lookup has to be done
The BGP label will be the second label in the
label stack of packets travelling in the core
MP-BGP Update - Extended community
BGP extended community attribute
Structured, to support multiple applications
64 bits for increased range
General form
<16bits type>:<ASN>:<32 bit number>
Registered AS number
<16bits type>:<IP address>:<16 bit number>
Registered IP address
MP-BGP Update - Extended community
The Extended Community is used to:

Identify one or more routers where the route has
been originated (site)
Site of Origin (SOO)
Selects sites which should receive the route
Route-Target
MP-BGP Update
The Label can be assigned only by the router which
address is the Next-Hop attribute
PE routers re-write the Next-Hop with their own
address (loopback interface address)
Next-Hop-Self BGP command towards iBGP
neighbors
Loopback addresses are advertised into the
backbone IGP
PE addresses used as BGP Next-Hop must be
uniquely known in the backbone IGP
No summarisation of loopback addresses in the core
MPLS Forwarding
Packet forwarding
PE and P routers have BGP next-hop
reachability through the backbone IGP
Labels are distributed through LDP (hop-by-hop)
corresponding to BGP Next-Hops
Label Stack is used for packet forwarding
Top label indicates BGP Next-Hop (interior
label)
Second level label indicates outgoing interface
or VRF (exterior label)
MPLS Forwarding
PE2
PE1
CE1
CE2
P1
P2
IGP
Label(PE2)
VPN Label
IP
packet
PE1 receives IP packet
Lookup is done on site VRF
BGP route with Next-Hop and
Label is found
BGP next-hop (PE2) is reachable
through IGP route with
associated label
IGP
Label(PE2)
VPN Label
IP
packet
P routers switch the
packets based on the IGP
label (label on top of the
stack)
VPN Label
IP
packet
Penultimate Hop
Popping
P2 is the penultimate
hop for the BGP next-
hop
P2 remove the top label
This has been
requested through LDP
by PE2
IP
packet
PE2 receives the packets
with the label
corresponding to the
outgoing interface (VRF)
One single lookup
Label is popped and packet
sent to IP neighbor
IP
packet
CE3
T1 T7
T2 T8
T3 T9
T4 T7
T5 TB
T6 TB
T7 T8
Packet Forwarding Example 1
VPN_A
VPN_A
VPN_B
10.3.0.0
10.1.0.0
11.5.0.0
P P
P P
PE
CE
CE
CE
Data
<RD_B,10.1> , iBGP next hop PE1
<RD_A,11.6> , iBGP next hop PE1
<RD_B,10.2> , iBGP NH= PE2 , T2 T8
Ingress PE receives normal IP
Packets from CE router
PE router does IP Longest Match
from VPN_B FIB , find iBGP next
hop PE2 and impose a stack of
labels:
exterior Label T2 + Interior Label
T8
Data T8T2
VPN_A
VPN_B
VPN_B
10.1.0.0
10.2.0.0
11.6.0.0
CE
PE1
PE2
CE
CE
VPN_A
10.2.0.0
CE
Packet Forwarding Example 1 (cont.)
VPN_A
VPN_A
VPN_B
10.3.0.0
10.1.0.0
11.5.0.0
P P
P P
PE
CE
CE
CE
T7
T8
T9
Ta
Tb
Tu
Tw
Tx
Ty
Tz
T8, TA
T2 Data T8
Data
T2 Data
TB
out in /
All Subsequent P routers do switch the packet
Solely on Interior Label
Egress PE router, removes Interior Label
Egress PE uses Exterior Label to select which VPN/CE
to forward the packet to.
Exterior Label is removed and packet routed to CE router
VPN_A
VPN_B
VPN_B
10.1.0.0
10.2.0.0
11.6.0.0
CE
PE1
PE2
CE
CE
VPN_A
10.2.0.0
CE
T2 Data Data
TAT2
Packet Forwarding Example 2
In VPN 12, host 130.130.10.1 sends a packet with
destination 130.130.11.3
Customer sites are attached to Provider
Edge (PE) routers A & B.
130.130.10.1
130.130.11.3
12
12
A
B

VPN-ID
VPN Site
Address
Provider Edge
Router Address
VPN Site
Label
PE
Label
12 130.130.10.0/24 172.68.1.11/32 26 42
12 130.130.11.0/24 172.68.1.2/32 989 101
... ... ... ... ...
2. PE router A selects the
correct VPN forwarding table
based on the links VPN ID (12).
12
1. Packet arrives on VPN 12
link on PE router A.
A
130.130.11.3 Rest of IP packet

VPN-ID
VPN Site
Address
Provider Edge
Router Address
VPN Site
Label
PE
Label
12 130.130.10.0/24 172.68.1.11/32 26 42
12 130.130.11.0/24 172.68.1.2/32 989 101
... ... ... ... ...
12
A
3. PE router A matches
the incoming packets
destination address
with VPN 12s
forwarding table.
989 101
4. PE router A adds two
labels to the packet: one
identifying the destination
PE, and one identifying the
destination VPN site.
A
B
5. Packet is label-switched from PE router A to PE B based on
the top label, using normal MPLS.

The network core knows nothing about VPNs and sites: it
only knows how to get packets from A to B using MPLS.
B
12
6. PE router B identifies the correct
site in VPN 12 from the inner label.
130.130.11.3
7. PE router B removes the labels
and forwards the IP packet to the
correct VPN 12 site.
MPLS VPN mechanisms
VRF and Multiple Routing Instances
VRF: VPN Routing and Forwarding Instance
VRF Routing Protocol Context
VRF Routing Tables
VRF CEF Forwarding Tables
MPLS VPN mechanisms
VRF Routing table contains routes which should be
available to a particular set of sites
Analogous to standard IOS routing table, supports
the same set of mechanisms
Interfaces (sites) are assigned to VRFs
One VRF per interface (sub-interface, tunnel or virtual-
template)
Possible many interfaces per VRF
MPLS VPN mechanisms
Static BGP RIP
Routing
processe
s
Routing
contexts
VRF Routing tables
VRF Forwarding
tables
Routing processes run
within specific routing
contexts
Populate specific VPN
routing table and FIBs
(VRF)
Interfaces are assigned to
VRFs
MPLS VPN mechanisms
Site-1 Site-2 Site-3 Site-4
Logical view
Routing view
VRF
for site-1

Site-1
routes
Site-2
routes
VRF
for site-4

Site-3 routes
Site-4 routes
VRF
for site-2
Site-1
routes
Site-2
routes
Site-3
routes
VRF
for site-3
Site-2 routes
Site-3 routes
Site-4 routes
Site-1
Site-3
Site-4
Site-2
VPN-A
VPN-C
VPN-B
PE PE
P P
Multihop MP-iBGP
MPLS VPN Topologies
VPN_A
VPN_A
VPN_B
10.3.0.0
10.1.0.0
11.5.0.0
P P
P P
PE
PE CE
CE
CE
VPN_A
VPN_B
VPN_B
10.1.0.0
10.2.0.0
11.6.0.0
CE
PE
PE
CE
CE
VPN_A
10.2.0.0
CE
VPN-IPv4 address are propagated together with the associated
label in BGP Multiprotocol extension
Extended Community attribute (route-target) is associated to
each VPN-IPv4 address, to populate the site VRF
iBGP sessions
MPLS VPN Topologies
VPN sites with optimal intra-VPN routing
Each site has full routing knowledge of all
other sites (of same VPN)
Each CE announces his own address space
MP-BGP VPN-IPv4 updates are propagated
between PEs
Routing is optimal in the backbone
Each route has the BGP Next-Hop closest to
the destination
No site is used as central point for connectivity
MPLS VPN Topologies
VPN sites with optimal intra-VPN routing
Site-1
VRF
for site-1
N1,NH=CE
1
N2,NH=PE
2
N3,NH=PE
3
PE1
PE3
PE2
N1
Site-3
N3
N2
VPN-IPv4 updates exchanged between
PEs
RD:N1, NH=PE1,Label=IntCE1, RT=Blue
IntCE
1
IntCE3
N1
NH=CE1
Routing Table on
CE1
N1, Local
N2, PE1
N3, PE1
EBGP/RIP/Static
VRF
for site-3
N1,NH=PE
1
N2,NH=PE
2
N3,NH=CE
3
Routing Table on
CE3
N1, PE3
N2, PE3
N3, Local
N3
NH=CE3
EBGP/RIP/Static
Site-2
IntCE2
Routing Table on
CE2
N1,NH=PE2
N2,Local
N3,NH=PE2
N2,NH=CE2
EBGP/RIP/Static
VRF
for site-2
N1,NH=PE
1
N2,NH=CE
2
N3,NH=PE
3
MPLS VPN Topologies
VPN sites with Hub & Spoke routing
One central site has full routing knowledge of
all other sites (of same VPN)
Hub-Site
Other sites will send traffic to Hub-Site for any
destination
Spoke-Sites
Hub-Site is the central transit point between
Spoke-Sites
Use of central services at Hub-Site
MPLS VPN Topologies
PE2
PE1
PE3
Site-1
N1
N3
VPN-IPv4 updates advertised by PE3
RD:N1, NH=PE3,Label=IntCE3-Spoke,
RT=Spoke
RT=Spoke
RT=Spoke
Site-3
Site-2
N2
IntCE3-Spoke
VRF
(Export
RT=Spoke)
N1,NH=CE3-
Spoke
N2,NH=CE3-
Spoke
N3,NH=CE3-
Spoke
CE1
CE3-Spoke
CE2
CE3-Hub
IntCE3-Hub VRF
(Import RT=Hub)
N1,NH=PE1
N2,NH=PE2
VPN-IPv4 update advertised by PE1
RD:N1, NH=PE1,Label=IntCE1,
RT=Hub
VPN-IPv4 update advertised by PE2
RD:N2, NH=PE2,Label=IntCE2,
RT=Hub
IntCE2 VRF
(Import RT=Spoke)
(Export RT=Hub)
N1,NH=PE3 (imported)
N2,NH=CE2 (exported)
IntCE1 VRF
(Import RT=Spoke)
(Export RT=Hub)
N3,NH=PE3 (imported
BGP/RIPv2
BGP/RIPv2
Routes are imported/exported into VRFs based on RT value
of the VPN-IPv4 updates
PE3 uses 2 (sub)interfaces with two different VRFs
MPLS VPN Topologies
PE2
PE1
PE3
Site-1
N1
N3
Site-3
Site-2
N2
IntCE3-Spoke
VRF
(Export
RT=Spoke)
N1,NH=CE3-
Spoke
N2,NH=CE3-
Spoke
N3,NH=CE3-
Spoke
CE1
CE3-Spoke
CE2
CE3-Hub
IntCE3-Hub VRF
(Import RT=Hub)
N1,NH=PE1
N2,NH=PE2
IntCE2 VRF
(Import RT=Spoke)
(Export RT=Hub)
IntCE1 VRF
(Import RT=Spoke)
(Export RT=Hub)
N3,NH=PE3 (imported
BGP/RIPv2
BGP/RIPv2
Traffic from one spoke to another will travel across the hub site
Hub site may host central services
Security, NAT, centralised Internet access
MPLS VPN Internet Routing

In a VPN, sites may need to have Internet
connectivity
Connectivity to the Internet means:
Being able to reach Internet destinations
Being able to be reachable from any Internet source
The Internet routing table is treated separately
In the VPN backbone the Internet routes are in
the Global routing table of PE routers
Labels are not assigned to external (BGP) routes
MPLS VPN Internet routing
VRF specific default route
A default route is installed into the site
VRF and pointing to a Internet Gateway
The default route is NOT part of any VPN
A single label is used for packets forwarded
according to the default route
The label is the IGP label corresponding to the
IP address of the Internet gateway
Known in the IGP
PE router originates CE routes for the Internet
Customer (site) routes are known in the site VRF
Not in the global table
The PE/CE interface is NOT known in the global table.
However:
A static route for customer routes and pointing to the
PE/CE interface is installed in the global table
This static route is redistributed into BGP-4 global table
and advertised to the Internet Gateway
The Internet gateway knows customer routes and with
the PE address as next-hop
The Internet Gateway specified in the
default route (into the VRF) need NOT to
be directly connected
Different Internet gateways can be used
for different VRFs
Using default route for Internet routing
does NOT allow any other default route for
intra-VPN routing
As in any other routing scheme
PE
PE
Internet
Site-1
PE-IG
Site-2
Network 171.68.0.0/16
Serial0
192.168.1.1
192.168.1.2
ip vrf VPN-A
rd 100:1
route-target both 100:1
!
Interface Serial0
ip address 192.168.10.1 255.255.255.0
ip vrf forwarding VPN-A
!
Router bgp 100
no bgp default ipv4-unicast
network 171.68.0.0 mask 255.255.0.0
neighbor 192.168.1.1 remote 100
neighbor 192.168.1.1 activate
neighbor 192.168.1.1 next-hop-self
neighbor 192.168.1.1 update-source loopback0
!
address-family ipv4 vrf VPN-A
neighbor 192.168.10.2 remote-as 65502
exit-address-family
!
address-family vpnv4
exit-address-family
!
ip route 171.68.0.0 255.255.0.0 Serial0
ip route vrf VPN-A 0.0.0.0 0.0.0.0 192.168.1.1 global
BGP-4
MP-BGP
PE
PE
Internet
Site-1
PE-IG
Site-2
Network 171.68.0.0/16
Serial0
192.168.1.1
192.168.1.2
Site-2 VRF
0.0.0.0/0 192.168.1.1
(global)
Site-1 routes
Site-2 routes
Global Table and LFIB
192.168.1.1/32 Label=3
192.168.1.2/32 Label=5
...
IP packet
D=cisco.co
m
Label = 3
IP packet
D=cisco.co
m
IP packet
D=cisco.co
m
PE routers need not to hold the Internet
table
PE routers will use BGP-4 sessions to
originate customer routes
Packet forwarding is done with a single
label identifying the Internet Gateway IP
address
More labels if Traffic Engineering is used
Separated (sub)interfaces
If CE wishes to receive and announce routes
from/to the Internet
A dedicated BGP session is used over a separate (sub)
interface
The PE imports CE routes into the global routing table
and advertise them to the Internet
The interface is not part of any VPN and does not use
any VRF
Default route or Internet routes are exported to the CE
PE needs to have Internet routing table
The PE uses separate (sub)interfaces with
the CE
One (sub)interface for VPN routing
associated to a VRF
Can be a tunnel interface
One (sub)interface for Internet routing
Associated to the global routing table
PE
PE
Internet
Site-1
PE-IG
Site-2
Network 171.68.0.0/16
Serial0.1
192.168.1.1
192.168.1.2
ip vrf VPN-A
rd 100:1
route-target both 100:1
!
Interface Serial0
no ip address
!
Interface Serial0.1
ip address 192.168.10.1 255.255.255.0
ip vrf forwarding VPN-A
!
Interface Serial0.2
ip address 171.68.10.1 255.255.255.0
!
Router bgp 100
neighbor 192.168.1.1 update-source loopback0
!
address-family ipv4 vrf VPN-A
exit-address-family
!
exit-address-family
BGP-4
MP-BGP
Serial0.2
BGP-4
PE
PE
Internet
Site-1
PE-IG
Site-2
Network 171.68.0.0/16
Serial0.1
192.168.1.1
192.168.1.2
Serial0.2
Serial0.1
Serial0.2
CE routing table
Site-2 routes ---->
Serial0.1
Internet routes --->
Serial0.2
IP packet
D=cisco.co
m
PE Global Table
Internet routes --->
192.168.1.1
192.168.1.1, Label=3
Label = 3
IP packet
D=cisco.co
m
IP packet
D=cisco.co
m
Scaling
Existing BGP techniques can be used to scale
the route distribution: route reflectors
Each edge router needs only the information
for the VPNs it supports
Directly connected VPNs
RRs are used to distribute VPN routing
information

MPLS-VPN
Scaling BGP
VPN_A
VPN_A
VPN_B
10.3.0.0
10.1.0.0
11.5.0.0
P P
P P
PE
PE CE
CE
CE
RR RR
Route Reflectors
VPN_A
VPN_B
VPN_B
10.1.0.0
10.2.0.0
11.6.0.0
CE
PE1
PE2
CE
CE
VPN_A
10.2.0.0
CE
Route Reflectors may be partitioned
Each RR store routes for a set of VPNs
Thus, no BGP router needs to store ALL VPNs
information
PEs will peer to RRs according to the VPNs they
directly connect
MPLS-VPN Scaling
BGP updates filtering
iBGP full mesh between PEs results in flooding all
VPNs routes to all PEs
Scaling problems when large amount of routes. In
addition PEs need only routes for attached VRFs
Therefore each PE will discard any VPN-IPv4 route
that hasnt a route-target configured to be imported
in any of the attached VRFs
This reduces significantly the amount of information
each PE has to store
Volume of BGP table is equivalent of volume of
attached VRFs (nothing more)
MPLS-VPN Scaling
BGP updates filtering
Each VRF has an import and export policy configured
Policies use route-target attribute (extended community)
PE receives MP-iBGP updates for VPN-IPv4 routes
If route-target is equal to any of the import values
configured in the PE, the update is accepted
Otherwise it is silently discarded
PE
MP-iBGP sessions
VRFs for VPNs
yellow
green
VPN-IPv4 update:
X
Label=XYZ
VPN-IPv4 update:
X
SOO=Site1, RT=Red,
Label=XYZ
Import RT=yellow
Import RT=green
MPLS-VPN Scaling
Route Refresh
Policy may change in the PE if VRF modifications are done
New VRFs, removal of VRFs
However, the PE may not have stored routing information
which become useful after a change
PE request a re-transmission of updates to neighbors
Route-Refresh
PE
VPN-IPv4 update:
X
Label=XYZ
VPN-IPv4 update:
X
SOO=Site1, RT=Red,
Label=XYZ
Import RT=yellow
Import RT=green
Import RT=red
1. PE doesnt have red
routes (previously filtered
out)
2. PE issue a Route-
Refresh to all neighbors
in order to ask for re-
transmission
3. Neighbors re-send
updates and red
route-target is now
accepted
MPLS-VPN Scaling
Outbound Route Filters - ORF
PE router will discard update with unused route-target
Optimization requires these updates NOT to be sent
Outbound Route Filter (ORF) allows a router to tell its
neighbors which filter to use prior to propagate BGP
updates
PE
VPN-IPv4 update:
X
Label=XYZ
VPN-IPv4 update:
X
SOO=Site1, RT=Red,
Label=XYZ
Import RT=yellow
Import RT=green
1. PE doesnt need
red routes
2. PE issue a ORF
message to all neighbors
in order not to receive red
routes
3. Neighbors
dynamically configure
the outbound filter and
send updates
accordingly
MPLS VPN - Configuration
VPN knowledge is on PE routers
PE router have to be configured for
VRF and Route Distinguisher
VRF import/export policies (based on Route-target)
Routing protocol used with CEs
MP-BGP between PE routers
BGP for Internet routers
With other PE routers
With CE routers
VRF and Route Distinguisher
RD is configured on PE routers (for each VRF)
VRFs are associated to RDs in each PE
Common (good) practice is to use the same RD for
the same VPN in all PEs
But not mandatory
VRF configuration command
ip vrf <vrf-symbolic-name>
rd <route-distinguisher-value>
route-target import <community>
route-target export <community>
CLI - VRF configuration
VRF
for site-1
(100:1)
Site-1 routes
Site-2 routes
VRF
for site-4
(100:4)
Site-3 routes
Site-4 routes
VRF
for site-2
(100:2)
Site-1 routes
Site-2 routes
Site-3 routes
VRF
for site-3
(100:3)
Site-2 routes
Site-3 routes
Site-4 routes
PE1 PE2
P P
Multihop MP-iBGP
ip vrf site1
rd 100:1
route-target export
100:1
route-target import
100:1
ip vrf site2
rd 100:2
route-target export
100:2
route-target import
100:2
route-target import
100:1
route-target export
100:1
ip vrf site3
rd 100:3
route-target export 100:2
route-target import 100:2
ip vrf site-4
rd 100:4
Site-1
Site-3
Site-4
Site-2
VPN-A
VPN-C
VPN-B
PE/CE routing protocols
PE/CE may use BGP, RIPv2 or Static routes
A routing context is used for each VRF
Routing contexts are defined within the routing
protocol instance
Address-family router sub-command
Router rip
version 2
address-family ipv4 vrf <vrf-symbolic-
name>
any common router sub-command
BGP uses same address-family command
Router BGP <asn>
...
address-family ipv4 vrf <vrf-symbolic-
name>

any common router BGP sub-command

Static routes are configured per VRF
ip route vrf <vrf-symbolic-name>
PE router commands
All show commands are VRF based
Show ip route vrf <vrf-symbolic-name> ...
Show ip protocol vrf <vrf-symbolic-name>
Show ip cef <vrf-symbolic-name>

PING and Telnet commands are VRF based
telnet /vrf <vrf-symbolic-name>
ping vrf <vrf-symbolic-name>

PE1
PE2
P P
Multihop MP-iBGP
Site-1
Site-3
Site-4
Site-2
VPN-A
VPN-C
VPN-B
VRF
for site-1
(100:1)
Site-1
routes
Site-2
routes
VRF
for site-4
(100:4)
Site-3 routes
Site-4 routes
VRF
for site-2
(100:2)
Site-1 routes
Site-2 routes
Site-3 routes
VRF
for site-3
(100:3)
Site-2
routes
Site-3
routes
Site-4
routes
ip vrf site3
rd 100:3
ip vrf site-4
rd 100:4
!
interface Serial4/6
ip vrf forwarding site3
ip address 192.168.73.7
255.255.255.0
encapsulation ppp
!
interface Serial4/7
ip address 192.168.74.7
255.255.255.0
encapsulation ppp
ip vrf site1
rd 100:1
ip vrf site2
rd 100:2
!
interface Serial3/6
ip address 192.168.61.6
255.255.255.0
encapsulation ppp
!
interface Serial3/7
ip address 192.168.62.6
255.255.255.0
encapsulation ppp
PE1
PE2
P P
Multihop MP-iBGP
Site-1
Site-3
Site-4
Site-2
VPN-A
VPN-C
VPN-B
VRF
for site-1
(100:1)
Site-1
routes
Site-2
routes
VRF
for site-4
(100:3)
Site-3 routes
Site-4 routes
VRF
for site-2
(100:2)
Site-1 routes
Site-2 routes
Site-3 routes
VRF
for site-3
(100:2)
Site-2
routes
Site-3
routes
Site-4
routes
router bgp 100
neighbor 6.6.6.6 update-source
Loop0
!
address-family ipv4 vrf site4
neighbor 192.168.74.4 remote-as
65504
exit-address-family
!
65503
exit-address-family
!
exit-address-family
router bgp 100
neighbor 7.7.7.7 update-source
Loop0
!
65502
exit-address-family
!
65501
exit-address-family
!
exit-address-family
Summary
Supports large scale VPN services
Increases value add by the VPN Service Provider
Decreases Service Providers cost of providing VPN
services
Mechanisms are general enough to enable VPN
Service Provider to support a wide range of VPN
customers
See RFC2547
Amount of routing peering
maintained by CE is O(1) - CE peers
only with directly attached PE
independent of the total number
of sites within a VPN
scales to VPNs with large
number of sites (100s - 1000s
sites per VPN)
Point-to-point connections vs
BGP/MPLS VPNs: routing peering
Mesh of point-to-point
connections requires each
(virtual) router to maintain O(n)
peering (where n is the number
of sites)

does not scale to VPNs with
large number of sites (due to
the properties of existing
routing protocols)

Site All other sites
CE PE
Routing peering
Amount of configuration changes
needed to add a new site (new CE)
is O(1):
need to configure only the
directly attached PE
independent of the total number
of sites within a VPN
Point-to-point connections vs BGP/MPLS
VPNs: provisioning
All other sites
CE PE
Config
change
Mesh of point-to-point
connections requires O(n)
configuration changes (where n
is the number of sites) when
adding a new site
New
Site
Config
change
New
Site
Agenda
LDP
MPLS VPN
Monitoring MPLS
show tag-switching tdp parameters
router(config)#
Displays TDP parameters on the local router.
Basic MPLS Monitoring Commands
show tag-switching interface
show mpls interface 12.1(3)T
router(config)#

Displays MPLS status on individual interfaces.
show tag-switching tdp discovery
router(config)#
Displays all discovered TDP neighbors.
show tag-switching tdp parameters
Router#show tag-switching tdp parameters
Protocol version: 1
No tag pool for downstream tag distribution
Session hold time: 180 sec; keep alive interval: 60
sec
Discovery hello: holdtime: 15 sec; interval: 5 sec
Discovery directed hello: holdtime: 180 sec;
interval: 5 sec
show tag-switching interface
Router#show tag-switching interface detail
Interface Serial1/0.1:
IP tagging enabled
TSP Tunnel tagging not enabled
Tagging operational
MTU = 1500
Interface Serial1/0.2:
IP tagging enabled
TSP Tunnel tagging not enabled
Tagging operational
MTU = 1500
show tag-switching tdp discovery
Router#show tag-switching tdp discovery
Local TDP Identifier:
192.168.3.102:0
TDP Discovery Sources:
Interfaces:
Serial1/0.1: xmit/recv
TDP Id: 192.168.3.101:0
Serial1/0.2: xmit/recv
TDP Id: 192.168.3.100:0
show tag-switching tdp neighbor
router(config)#
Displays individual TDP neighbors.
More TDP Monitoring Commands
show tag-switching tdp neighbor detail
router(config)#
Displays more details about TDP neighbors.
show tag-switching tdp bindings
router(config)#
Displays Tag Information Base (TIB).
show tag tdp neighbor
Router#show tag-switching tdp neighbors
Peer TDP Ident: 192.168.3.100:0; Local TDP Ident
192.168.3.102:0
TCP connection: 192.168.3.100.711 - 192.168.3.102.11000
State: Oper; PIEs sent/rcvd: 55/53; ; Downstream
Up time: 00:43:26
TDP discovery sources:
Serial1/0.2
Addresses bound to peer TDP Ident:
192.168.3.10 192.168.3.14 192.168.3.100

show tag tdp neighbor detail
Router#show tag-switching tdp neighbors detail
Peer TDP Ident: 192.168.3.100:0; Local TDP Ident 192.168.3.102:0
TCP connection: 192.168.3.100.711 - 192.168.3.102.11000
State: Oper; PIEs sent/rcvd: 55/54; ; Downstream; Last TIB
rev sent 26
UID: 1; Up time: 00:44:01
TDP discovery sources:
Serial1/0.2; holdtime: 15000 ms, hello interval: 5000 ms
Addresses bound to peer TDP Ident:
192.168.3.10 192.168.3.14 192.168.3.100
Peer holdtime: 180000 ms; KA interval: 60000 ms; Peer state:
estab
show tag tdp bindings
Router#show tag tdp bindings
tib entry: 192.168.3.1/32, rev 9
local binding: tag: 28
remote binding: tsr: 19.16.3.3:0, tag: 28
tib entry: 192.168.3.2/32, rev 8
tib entry: 192.168.3.3/32, rev 7
remote binding: tsr: 19.16.3.3:0, tag: imp-null(1)
tib entry: 192.168.3.10/32, rev 6
local binding: tag: imp-null(1)
show tag-switching forwarding-table
show mpls forwarding-table
router(config)#
Displays contents of Label Forwarding Information
Base.
Monitoring Label Switching
show ip cef detail
router(config)#
Displays label(s) attached to a packet during label
imposition on edge LSR.
Monitoring Label Switching
Monitoring LFIB
Router#show tag-switching forwarding-table ?
A.B.C.D Destination prefix
detail Detailed information
interface Match outgoing interface
next-hop Match next hop neighbor
tags Match tag values
tsp-tunnel TSP Tunnel id
| Output modifiers
<cr>
show tag-switching forwarding-table
Router#show tag-switching forwarding-table detail
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
26 Untagged 192.168.3.3/32 0 Se1/0.3 point2point
MAC/Encaps=0/0, MTU=1504, Tag Stack{}
27 Pop tag 192.168.3.4/32 0 Se0/0.4 point2point
MAC/Encaps=4/4, MTU=1504, Tag Stack{}
20618847
28 29 192.168.3.4/32 0 Se1/0.3 point2point
MAC/Encaps=4/8, MTU=1500, Tag Stack{29}
18718847 0001D000
show ip cef detail
Router#show ip cef 192.168.20.0 detail
192.168.20.0/24, version 23, cached adjacency to Serial1/0.2
0 packets, 0 bytes
tag information set
local tag: 33
fast tag rewrite with Se1/0.2, point2point, tags imposed: {32}
via 192.168.3.10, Serial1/0.2, 0 dependencies
next hop 192.168.3.10, Serial1/0.2
valid cached adjacency
tag rewrite with Se1/0.2, point2point, tags imposed: {32}
debug tag-switching tdp ...
router(config)#
Debugs TDP adjacencies, session establishment,
and label bindings exchange.
Debugging Label Switching and TDP
debug tag-switching tfib ...
debug mpls lfib 12.1(3)T
router(config)#

Debugs Tag Forwarding Information Base events:
label creations, removals, rewrites.
debug tag-switching packets [ interface ]
debug mpls packets [ interface ] 12.1(3)T
router(config)#

Debugs labeled packets switched by the router.
Disables fast or distributed tag switching.
Common Frame-Mode MPLS Symptoms
TDP/LDP session does not start.
Labels are not allocated or distributed.
Packets are not labeled although the labels have
been distributed.
MPLS intermittently breaks after an interface failure.
Large packets are not propagated across the
network.
TDP Session Startup Issues: 1/4
Symptom
TDP neighbors are not discovered.
show tag tdp discovery does not display expected TDP neighbors.
Diagnosis
MPLS is not enabled on adjacent router.
Verification
Verify with show tag interface on the adjacent router.
Symptom
Diagnosis
Label distribution protocol mismatch - TDP on one end,
LDP on the other end.
Verification
Verify with show tag interface detail on both routers.
Symptom
Diagnosis
Packet filter drops TDP/LDP neighbor discovery packets.
Verification
Verify access-list presence with show ip interface.
Verify access-list contents with show access-list.
Symptom
TDP neighbors discovered, TDP session is not established.
show tdp neighbor does not display a neighbor in Oper
state.
Diagnosis
Connectivity between loopback interfaces is broken - TDP
session is usually established between loopback
interfaces of adjacent LSRs.
Verification
Verify connectivity with extended ping command.
Label Allocation Issues
Symptom
Labels are not allocated for local routes.
show tag-switching forwarding-table does not display any labels
Diagnosis
CEF is not enabled.
Verification
Verify with show ip cef.
Label Distribution Issues
Symptom
Labels are allocated, but not distributed.
show tag-switching tdp bindings on adjacent LSR does not display labels
from this LSR
Diagnosis
Problems with conditional label distribution.
Verification
Debug label distribution with debug tag tdp advertisement.
Examine the neighbor TDP router IDP with show tag tdp discovery.
Verify that the neighbor TDP router ID is matched by the access list
specified in tag advertise command.
Packet Labeling
Symptom
Labels are distributed, packets are not labeled.
show interface statistic does not labeled packets being sent
Diagnosis
CEF is not enabled on input interface (potentially due to conflicting
feature being configured).
Verification
Verify with show cef interface.
show cef interface
Router#show cef interface
Serial1/0.1 is up (if_number 15)
Internet address is 192.168.3.5/30
ICMP redirects are always sent
Per packet loadbalancing is disabled
IP unicast RPF check is disabled
Inbound access list is not set
Outbound access list is not set
IP policy routing is disabled
Interface is marked as point to point interface
Hardware idb is Serial1/0
Fast switching type 5, interface type 64
IP CEF switching enabled
IP CEF VPN Fast switching turbo vector
Input fast flags 0x1000, Output fast flags 0x0
ifindex 3(3)
Slot 1 Slot unit 0 VC -1
Transmit limit accumulator 0x0 (0x0)
IP MTU 1500
Intermittent MPLS Failures after
Interface Failure
Symptom
Overall MPLS connectivity in a router intermittently breaks after an
interface failure.
Diagnosis
IP address of a physical interface is used for TDP/LDP identifier.
Configure a loopback interface on the router.
Verification
Verify local TDP identifier with show tag-switching tdp neighbors.
Packet Propagation
Symptom
Large packets are not propagated across the network.
Extended ping with varying packet sizes fails for packet sizes close to 1500
In some cases, MPLS might work, but MPLS/VPN will fail.
Diagnosis
Tag MTU issues or switches with no support for jumbo frames in the
forwarding path.
Verification
Trace the forwarding path; identify all LAN segments in the path.
Verify Tag MTU setting on routers attached to LAN segments.
Check for low-end switches in the transit path.
Summary
After completing this lesson, you will be able to
perform the following tasks:
Describe procedures for monitoring MPLS on IOS
platforms.
List the debugging commands associated with label
switching, LDP and TDP.
Identify common configuration or design errors.
Use the available debugging commands in real-life
troubleshooting scenarios.
Session Number
Presentation_ID
Customer Reference
Ciscos MPLS Is Proven
150+ Deployments Today
Americas EMEA APT/Japan
Session Number
Presentation_ID
Thank you.

MPLS Cisco

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

MPLS Cisco

Enviado por

Direitos autorais:

Formatos disponíveis

1 2001, Cisco Systems, Inc. All rights reserved.

Você também pode gostar