BRKMPL 3124

Troubleshooting End-to-End MPLS
Vinit Jain - CCIE# 22854

Twitter - @vinugenie
BRKMPL-3124
Coming
this year
BRKMPL-3124 2016 Cisco and/or its affiliates. All rights reserved. Cisco Public 3
Agenda
Fundamentals
Troubleshooting LDP Issues
Troubleshooting MPLS LSP
Troubleshooting MPLS L3 VPNs
Troubleshooting 6VPE
Inter-AS MPLS VPNs
Conclusion
Introduction
Housekeeping
Who am I?
Who are you?
Service Provider
Enterprise
Enterprises using MPLS
Studying for CCIE
Advanced Class
Assume MPLS Operational Experience
Basic configuration
Show commands
Understand basic MPLS concepts
MPLS Fundamentals
MPLS Fundamentals
MPLS Architecture
MPLS has two major components:
1. Control plane: Exchanges Layer 3 routing information and labels
2. Forwarding plane: Forwards packets based on labels
Control plane contains complex mechanisms to exchange routing information,
such as OSPF, EIGRP, IS-IS, and BGP, and to exchange labels, such as TDP,
LDP, BGP, and RSVP.
Forwarding plane forwards packets based on CEF
MPLS Fundamentals
Terminologies
RIB is the Routing Information Base that is analogous to the IP routing table.
FIB aka CEF is Forwarding information base that is derived from the IP routing
table.
LIB is Label Information Base that contains all the label bindings learned via
LDP
LFIB is Label Forwarding Information Base that is derived from FIB entries and
corresponding LIB entries.
FEC ( Forwarding Equivalence Class)
Group of IP packets forwarded in the same manner (e.g. over same forwarding path)
A FEC can represent a: Destination IP prefix, VPN ID, ATM VC, VLAN ID, Traffic
Engineering tunnel, Class of Service.
MPLS Fundamentals
MPLS Architecture Incoming IP
Packet
Control Plane Data Plane

Routing
Routing Routing Forwarding
updates
Protocol Information Information
from peer
Database Base (RIB) Base (FIB)
routers
Outgoing
MPLS/IP
Packet
Label Label Label
Bindings Information Forwarding
via LDP Base (LIB) Information
peering Base (LFIB)
Incoming
MPLS Packet
MPLS Fundamentals
MPLS Label: Label Format
MPLS uses a 32-bit label field that is inserted between Layer 2 and Layer 3
headers
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 COS S TTL
Label = 20 bits
COS/EXP = Class of Service, 3 bits
S = Bottom of Stack, 1 bit
TTL = Time to Live (Loop detection)
MPLS Fundamentals
MPLS: Ethertype
Ethertype 0x0800 refers to IP
Ethertype 0x8847 refers to MPLS
Based on the Ethertype, the packet is handed over to the appropriate
processing engine on the router
MPLS Fundamentals
MPLS Label: The Label Stack
An MPLS packet may have more than one label

Frame Mode can handle a stack of two or more
labels, depending on the platform
Bottom most label has the S-bit set to 1
LSRs label switch packets are based ONLY on
the label at the top of the stack
MPLS Fundamentals
MPLS Label: The Label Stack
The following scenarios may produce more than one label:
MPLS L3 VPNs (two labels: The top label points to the egress router and the
second label identifies the VPN.)
MPLS TE with Fast Reroute (FRR) (two or more labels: The top label is for
the backup tunnel and the second label points to the primary tunnel
destination.)
MPLS VPNs combined with MPLS TE / FRR (three labels)
Carrier Supporting Carrier (CSC) with MPLS TE / FRR (four labels)
MPLS Fundamentals
Label Switch Path (LSP)
IGP domain without a label IGP domain with a label

distribution protocol distribution protocol
LSP follows IGP shortest path LSP diverges from IGP shortest path
LSPs are derived from IGP routing information

LSPs may diverge from IGP shortest path
LSP tunnels (explicit routing) with TE
LSPs are unidirectional
MPLS Fundamentals
Facts Check - Question
Which protocols have signaling and labeling capabilities?
OSPF / IS-IS
RSVP
LDP / TDP
BGP
MPLS LDP Configuration
IOS / IOS XE IOS XR NX-OS
install feature-set mpls

mpls label protocol ldp mpls ldp
feature-set mpls
! router-id x.x.x.x
feature mpls
interface Gig 0/0 interface gi 0/0/0/0
mpls ldp configuration
mpls ip interface gi 0/0/0/1
router-id x.x.x.x
mpls label protocol ldp
!
exit
interface ethernet 2/1
!
mpls ip
mpls ldp router-id
loopback0 force
LDP Neighborship
LDP neighborship is formed on TCP port 646
Discovery Mechanism:
Basic Discovery Multicast UDP hellos for directly connected neighbors
Extended Discovery Targeted Unicast UDP hellos for non-directly connected
neighbors
Parameters
Session Keepalive = 60 sec. & Hold time = 180 Sec.
Discover Hello interval = 5 sec. and Hold Time = 15 sec.
Can be viewed using the command show mpls ldp parameters
LDP Neighborship Negotiation
Verifying LDP Neighborship
PE1#sh mpls ldp neighbor

Peer LDP Ident: 10.13.1.101:0; Local LDP Ident 10.13.1.61:0
TCP connection: 10.13.1.101.11031 - 10.13.1.61.646
State: Oper; Msgs sent/rcvd: 58/60; Downstream
Up time: 00:39:27
LDP discovery sources:
Ethernet0/0, Src IP addr: 10.13.1.5
Ethernet1/0, Src IP addr: 10.13.1.9
Addresses bound to peer LDP Ident:
10.13.1.9 10.13.1.5 10.13.2.5 10.13.1.101
PE1#show tcp brief| i 646

43ABB020 10.13.1.101.11031 10.13.1.61.646 ESTAB
PE1#
Reachability and ACL verification
Ensure reachability between the LDP router IDs
PE1#ping 192.168.11.11 source lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.11.11, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.1
..... Check Routing
Success rate is 0 percent (0/5) Configuration
Verify no ACL in path blocking TCP port 646 and other Multicast traffic for LDP
Hellos.
PE1#telnet 192.168.11.11 646 /source-interface lo0
Trying 192.168.11.11, 646 ... Verify ACLs in the path or
% Destination unreachable; gateway or host down on the routers itself
LDP Router-id
If router-id is not set manually, router checks all operational interfaces on the
router(including loopbacks) and chooses the highest IP address as the LDP
router-id.
LDP_ID should be hardcoded via
mpls ldp router-ID <interface>
The above configuration will not help unless:
<interface> is UP when LDP gets started
Existing LDP_ID (usually an interface) is shut
Following avoids both shortcomings

mpls ldp router-ID <interface> force
Troubleshooting LDP issues
Verifying LDP Connection
show mpls ldp discovery [detail]

Must show xmit/recv on LDP enabled interface
PE1#show mpls ldp discovery

Local LDP Identifier:
192.168.1.1:0 Local LDP_ID Xmited and
Recvd Hellos
Discovery Sources: on that
Interfaces: interface
GigabitEthernet0/1 (ldp): xmit/recv
LDP Id: 192.168.11.11:0
Discovered
Neighbors LDP_ID
Problem with xmit / recv
Lo0=192.168.1.1 Lo0=192.168.11.11
PE1 P1
PE1#show mpls ldp discovery P1#show mpls ldp discovery

Local LDP Identifier: Local LDP Identifier:
192.168.1.1:0 192.168.11.11:0
Discovery Sources: Discovery Sources:
Interfaces: Interfaces:
GigabitEthernet0/1 (ldp): xmit GigabitEthernet0/1 (tdp): xmit
R1#debug mpls ldp transport connections

07:00:06.106: ldp: Scan listening TCBs
07:01:06.106: ldp: Scan listening TCBs Label Protocol
07:02:06.106: ldp: Scan listening TCBs is TDP
PE1(config-if)#mpls label protocol ldp
LDP No Route Problem
Lo0=192.168.1.1 Lo0=192.168.11.11
PE1 P1
PE1#show mpls ldp discovery P1#show mpls ldp discovery

192.168.1.1:0 192.168.11.11:0
Discovery Sources: Discovery Sources:
Interfaces: Interfaces:
Gi0/1 (ldp): xmit/recv Gi0/1 (ldp): xmit/recv
LDP Id: 192.168.11.11:0; no route LDP Id: 192.168.1.1:0
PE1#show ip route 192.168.11.11

% Network not in table
Problem: Default route towards the peering router
Problem due to Summarization
PE1 P1
PE1#show mpls ldp neighbor 192.168.11.11 PE2#sh mpls ldp neighbor 192.168.1.1
PE1#show mpls ldp discovery PE2#show mpls ldp discovery

192.168.1.1:0 192.168.11.11:0
GigabitEthernet0/1 (ldp): xmit/recv GigabitEthernet0/1 (ldp): xmit/recv
LDP Id: 192.168.11.11:0 LDP Id: 192.168.1.1:0
PE1#show ip route 192.168.11.11 PE2#show ip route 192.168.1.1
Routing entry for 192.168.11.11/32 Routing entry for 192.168.1.0/24
Known via "ospf 100", distance 110, metric 2, type Known via "bgp 100", distance 200, metric 0
intra area Tag 1, type internal
Last update from 10.1.111.11 on Gi0/1, 00:04:34 ago Last update from 192.168.1.12 20:10:38 ago
Routing Descriptor Blocks: Routing Descriptor Blocks:
* 10.1.111.11, from 192.168.11.11, 00:04:34 ago, * 192.168.1.12, from 192.168.12.12, 20:10:38
via GigabitEthernet0/1 ago
Route metric is 2, traffic share count is 1 Route metric is 0, traffic share count is 1
AS Hops 5
Troubleshooting LDP Issues Also good to check show
mpls ldp trace discovery
MPLS LDP Trace on IOS XR
RP/0/0/CPU0:PE2#show mpls ldp trace peer last 20
0/0/CPU0 t1 [PEER]:506: VRF(0x60000000): Peer(192.168.11.11:0): Peer FSM: Stepped, pp=0x102d9548, event=0, state
0 -> 1
0/0/CPU0 t1 [PEER]:581: VRF(0x60000000): Peer(192.168.11.11:0): DOWN - reason 'TCP connection closed'
0/0/CPU0 t1 [PEER]:3262: VRF(0x60000000): Release Peer(192.168.11.11:0): rsn 'TCP connection closed' ('Success')
0/0/CPU0 t1 [PEER]:3625: Peer(192.168.11.11:0): Unsupported/Unknown TLV (type 0x506, U/F 1/0) rcvd in INIT msg
0/0/CPU0 t1 [PEER]:506: VRF(0x60000000): Peer(192.168.11.11:0): Peer FSM: Stepped, pp=0x102d9520, event=0, state
0 -> 1
0/0/CPU0 t1 [PEER]:575: VRF(0x60000000): Peer(192.168.11.11:0): DOWN - reason 'Received Notification message

from peer' (more_info 'KeepAlive Timer Expired')
0/0/CPU0 t1 [PEER]:3262: VRF(0x60000000): Release Peer(192.168.11.11:0): rsn 'Received Notification message

from peer' ('KeepAlive Timer Expired')
0/0/CPU0 t1 [PEER]:3625: Peer(192.168.11.11:0): Unsupported/Unknown TLV (type 0x506, U/F 1/0) rcvd in INIT msg
LDP & IGP Sync
When a link comes up, LDP and IGP compete to converge; Labeled traffic drops
if IGP wins.
When LDP session on a link drops, IGP may continue forwarding labeled traffic
to that link and cause traffic dropped.
LDP & IGP Sync Solution
Link up:
If LDP peer is reachable (alternate route exists), defer IGP adjacency on the link.
If LDP peer is not reachable (no alternate route), IGP advertise max-metric to reach
neighbor through the link.
LDP session down:
IGP advertises max-metric to reach neighbor through the link.
LDP & IGP Sync
LDP IGP Sync feature is enabled under IGP (OSPF/ISIS)

- sync-igp-shortcuts for TE tunnel interfaces, sync for all other types.
router (config-isis-if-af) # mpls ldp sync [ level <1-2> ]
router (config-ospf) # mpls ldp sync + (config-ospf-ar), (config-ospf-ar-if)
router (config-ospf) # mpls ldp sync-igp-shortcuts + (config-ospf-ar)
LDP & IGP Sync
LDP IGP Sync delays are configured under LDP
router (config-ldp) # igp sync delay on-session-up <sec>
router (config-ldp) # igp sync delay on-proc-restart <sec>
LDP Session Protection
Problem:
I. When a link flaps (for a short time),
II. LDP hello adjacency over the link flaps
III. LDP session is torn down then re-setup
IV. LDP re-exchanges label bindings when LDP session is setup (i.e. LDP
re-convergence).
Solution:
When LDP session supported by link hello is setup, create a targeted hello to
protect the session.
When link is down, the targeted hello remains through other path and keeps
the LDP session up.
When link restores, re-discover neighbors, re-program forwarding.
LDP Session Protection
router (config-ldp) # session protection [ for <peer-acl> ] [ duration { <sec> | infinite } ]
router (config-ldp) # log session-protection
Reasons for LSP to Break
MP-IBGP VPNv4
LDP + IGP
172.16.11.0/24 10.1.111.0/24 10.1.211.0/24 172.16.22.0/24
CE1 PE1 P1 PE2 CE2

Lo0=172.16.1.1/32 192.168.1.1/32 192.168.11.11/32 192.168.2.2/32 Lo0=172.16.2.2/32
Broken LDP adjacency

MPLS not enabled
Mismatch labels
Software/hardware corruption
Label Information Base (LIB)
LIB stores local and remote bindings
Local Binding:
Prefix in own routing table + local label
One binding
Remote Binding:
Prefix + remote label received from LDP neighbor
Holds LDP router-id
One binding per LDP neighbor
LIB stores all labels from all LDP (BGP) neighbors, even the ones that are not
used for packet forwarding (now)
Looking at the LIB
RTR#show mpls ldp bindings detail
tib entry: 10.1.1.0/30, rev 10
local binding: tag: imp-null
Advertised to:
10.1.2.2:0 10.1.2.6:0 10.1.2.4:0
remote binding: tsr: 10.1.2.2:0, tag: imp-null
remote binding: tsr: 10.1.2.6:0, tag: 12304
remote binding: tsr: 10.1.2.4:0, tag: 12305
Label Forwarding Information Base (LFIB)
The LFIB stores local and remote labels for prefixes that are used to forward
packets
Prefixes that are used = prefixes in routing table (RIB)
Labels are derived from LIB
LDP TDP
prefix, next-hop and in-
label, out-label prefix + next-hop
LIB LFIB RIB
(prefix, LDP Ident, get in- and out-label for (prefix,next-hop, (prefix, next-hop)
label) (prefix, next-hop) in-label, out-label)
Building the LFIB
P1#show ip route 3.3.3.4
Routing entry for 3.3.3.4/32
* 10.1.2.1, from 10.1.2.1, 13:28:32 ago, via Ethernet0/0
P1#show mpls ldp neighbor 10.1.2.1
Peer LDP Ident: 3.3.3.3:0; Local LDP Ident 2.2.2.2:0
P1#show mpls ldp binding 3.3.3.4 255.255.255.255
lib entry: 3.3.3.4/32, rev 18
remote binding: lsr: 3.3.3.3:0, label: imp-null
P1#show mpls forwarding 3.3.3.4
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
20 Pop Label 3.3.3.4/32 0 Et0/0 10.1.2.1
MPLS OAM
Defined in RFC 4379
LSP Ping and Traceroute provide ability to monitor MPLS Label Switched Paths
and quickly isolate MPLS forwarding problems.
Two messages
MPLS Echo Request:
MPLS labeled IPv4 or IPv6 UDP packet
MPLS Echo Reply IPv4 or IPv6 UDP packet
Ping mode: Connectivity check of an LSP

Test if a particular FEC ends at the correct egress LSR
Traceroute mode: Hop by Hop fault localization
Packet follows data path
FEC Types Supported
ping mpls ?
ipv4 Target specified as an IPv4 address
pseudowire Target VC specified as an IPv4 address and VC ID
traffic-eng Target specified as TE tunnel interface
traceroute mpls ?
ipv4 Target specified as an IPv4 address
multipath LSP Multipath Traceroute
pseudowire Target VC specified as an IPv4 address and VC ID
traffic-eng Target specified as TE tunnel interface
LSP Ping (ping mpls . . . )
Simple and efficient mechanism to detect data plane failures in MPLS LSPs
Verify data plane against the control plane
Sending echo request and receiving echo reply
Verify that packets belonging to a FEC exit the LSP on the correct egress LSR
Modelled after the well known IP ping and traceroute
Ping verifies connectivity, traceroute verifies path
LSP Ping/trace leave the LSR with the correct label stack for the LSP to be
tested
Packet Format
Version Number Must Be Zero
Message Type Reply Mode Return Code Return Subcode
Senders Handle
Sequence Number
Timestamp Sent (seconds)
Timestamp Sent (microseconds)
Timestamp Received (seconds)
Timestamp Received (microseconds)
TLV
Packet Format
Version number: 1
Message Type
MPLS Echo Request
MPLS Echo Reply
Reply Mode
1 Do not reply
2 Reply via an IPv4/IPv6 UDP packet
3 Reply via an IPv4/IPv6 UDP packet with Router Alert
4 Reply via application level control channel
Timestamp
Time-of-day in seconds and microseconds
Reply Modes
Reply Mode Do Not Reply
This mode is useful for a keepalive application running at the remote end
Such an application would trigger state changes if it does not receive
a LSP ping packet within a predefined time
An MPLS echo request with do not reply may also be used by the receiving
router to log gaps in the sequence numbers and/or maintain delay/jitter statistics
Reply Modes
Reply Mode Reply via an IPv4 UDP Packet
The Reply via UDP packet implies that an IP V4 UDP packet should be sent in
reply to an MPLS echo request
This will be the most common reply mode for simple LSP pings sent to
periodically poll the integrity of an LSP
This is the default reply mode
Reply Modes
Reply Mode Reply via an IPv4 UDP Packet with Router Alert
In this mode when the destination router replies it appends a label of 1 to the
packet
This forces all the intermediate routers, on the way back, to process switch the
reply
This mode is CPU intensive and should generally be used if the reply fails for
reply with IPv4 UDP packet
This mode is useful when we have inconsistency between IP and MPLS
Return Codes
Value Meaning
0 The Error Code Is Contained in the Error Code TLV
1 Malformed Echo Request Received
2 One Or More of the TLVs Was Not Understood
3 Replying Router Is an Egress for the FEC
4 Replying Router Has No Mapping for the FEC
5 Replying Router Is Not One of the Downstream Routers
Replying Router Is one of the Downstream Routers, and Its Mapping for this FEC on the
6 Received Interface Is the Given Label
MPLS Echo Request
R1#ping mpls ipv4 192.168.2.2/32 verbose

destination 127.0.0.2 repeat 1 exp 7 pad 0xFFFF
Sending 1, 100-byte MPLS Echos to 10.200.254.4/32,
timeout is 2 seconds, send interval is 0 msec:
Codes: '!' - success, 'Q' - request not transmitted,
'.' - timeout, 'U' - unreachable,
'R' - downstream router but not target
! Reply address 10.1.211.2, return code 3
MPLS Ping (Operational Theory)
We use the same label stack as used by the LSP and this makes the echo to be
switched inband of LSP
The IP header destination address field of the echo request is a 127/8 address
An Echo reply, which may or may not be labelled, has the egress interface IP
address as the source; destination IP address/port are copied from the echo-
requests source address/port
Presence of the 127/8 address in the IP header destination address field causes
the packet to be consumed by any routers trying to forward the packet using the
ip header
In this case P1 would not forward the echo-req to PE1 but rather consumes the
packet and sends a reply to PE2 accordingly
MPLS Ping Packet Capture
Operation
MPLS OAM Caveats
For LSP ping we generate an MPLS echo request
The payload includes the LDP/RSVP/L2 Circuit sub-TLV depending on the LSP
we use
Echo request is appropriately labelled and sent out
Ping mode: MPLS TTL = 255
Traceroute mode: TTL = 1, 2 ,3 etc.
MPLS Echo Request always has FEC Stack TLV
The LSP ping sender sets the return code to 0.
The replying router would set it accordingly based on the table shown previously
TTL Field in Labels
Only the TTL field in the label at the top of the stack counts
The outgoing TTL value is only a function of the incoming TTL value
Outgoing TTL is one less than incoming TTL
If outgoing TTL = 0, packet is not forwarded (not even stripped and forwarded
as an IP packet)
When an IP packet is first labelled, the TTL field is copied from the IP header to
the MPLS header (after being decremented by 1)
When the label stack is removed, the outgoing TTL value is copied to the TTL
field in the IP header
Unless MPLS TTL > IP TTL
Operation
Receiving LSR checks that label stack of received packet matches with the
received FECs in FEC Stack
MPLS Echo Reply is sent in response to MPLS Echo Request
Destination IP address is source IP address of Echo Request
IP TTL = 255
Reply Mode: (You do not control if return packet is sent over IP or MPLS)
IPv4
IPv4 with Router Alert (IP Option)
If over MPLS, then Router Alert Label as topmost label is added in the label stack
Hardware forwarding bypassed; packet is sent to RP process level forwarding
Traceroute in MPLS Network
In Prefix Output Out In Prefix Output Out
Label Interface Label Label Interfac Label
e
- 172.16.2.2/32 Y 19 24008 24008 172.16.2.2/32 Y -
16 172.16.1.1/32 X - - 172.16.1.1/32 X 22 16
Y Y
PE1 X P1 X PE2
192.168.1.1/32 192.168.2.2/32
In Prefix Output Out

Label Interface Label
CE1 CE2
22 192.168.1.1/32 X pop
172.16.1.1/32 19 192.168.2.2/32 Y pop 172.16.2.2/32
Traceroute in MPLS Network
Aggregate Outgoing
Label 19, TTL=1 Label, IP Lookup
done in CEF for VRF
Label 24008 Label 24008,
TTL=255
172.16.2.2 172.16.2.2 172.16.2.2
TTL=2 TTL=1 TTL=255, ICMP
UDP port 35678 UDP port 35678 TTL Exceeded
CE1 PE1 P1 PE2 CE2

172.16.1.1/32 192.168.1.1/32 192.168.2.2/32 172.16.2.2/32
Label 22, TTL=254
172.16.1.1 TTL=252 Label 16, TTL=253 Label 16

ICMP TTL Exceeded
172.16.1.1 TTL=254 172.16.1.1 TTL=254
ICMP TTL Exceeded ICMP TTL Exceeded
MPLS Trace
The ICMP messages TTL exceeded are forwarded along the LSP until the end
of the LSP. So, the router does not lookup the source ip address in the global
routing table to return the ICMP message.
Reason : P routers do not have knowledge of VPN prefixes : all traceroutes
initiated from within a VPN would fail
ICMP messages are forwarded with EXP bits = 6
MPLS Trace Hiding
This command prohibits the copying of the TTL from the IP header to the MPLS
shim header and vice versa (TTL is set to 255)
It should be configured on the routers that do the label imposement (LSR edge
routers), which is the PE routers.
Providers like to use it so that the customers see the MPLS network as one hop
when tracerouting
no mpls ip propagate-ttl forwarded
MPLS Trace Hiding
CE1#traceroute 172.16.2.2 source 172.16.1.1 (mpls ip propagate-ttl forwarded)

Tracing the route to 172.16.2.2
1 172.16.11.2 [AS 100] 3 msec 3 msec 3 msec local PE
2 10.1.111.11 [MPLS: Labels 19/24008 Exp 0] 122 msec 25 msec 19 msec P
3 10.1.211.2 [MPLS: Label 24008 Exp 0] 21 msec 16 msec 23 msec remote PE
4 172.16.12.1 [AS 100] 23 msec * 22 msec remote CE
CE1#traceroute 172.16.2.2 source 172.16.1.1 (no mpls ip propagate-ttl forwarded)

Tracing the route to 172.16.2.2
VRF info: (vrf in name/id, vrf out name/id)
1 172.16.11.2 [AS 100] 4 msec 3 msec 3 msec local PE
2 10.1.211.2 [MPLS: Label 24008 Exp 0] 25 msec 25 msec 31 msec remote PE
3 172.16.12.1 [AS 100] 24 msec * 28 msec remote CE
MPLS Trace with no mpls ip propagate-ttl on PE routers
Aggregate Outgoing
Label 19, TTL=1 Label
udp port
Label 24008 Label 24008,
35678?
TTL=255
172.16.2.2 172.16.2.2 172.16.2.2 172.16.2.2
TTL=2 TTL=1 TTL=1 TTL=1
UDP port 35678 UDP port 35678 UDP port 35678 UDP port 35678
CE1 PE1 P1 PE2 CE2

172.16.1.1/32 172.16.2.2/32
Label 22, TTL=255
172.16.1.1 TTL=254, 172.16.1.1
ICMP TTL=255, ICMP
Label 16, TTL=254 Label 16 Port Unreachable
Port Unreachable
172.16.1.1 TTL=254, 172.16.1.1 TTL=254,
ICMP ICMP
Port Unreachable Port Unreachable
MPLS Forwarding Plane
With MPLS, the idea is to de-couple the forwarding from the IP header
The forwarding decision is based on the MPLS header, not the IP header
The above is true once the packet is inside the MPLS network
Forwarding is still based on the IP header at the edge where the packet first
enters the MPLS network
CEF must be configured on all the routers in a MPLS network.
CEF takes care of the crucial recursion and resolution operations
What happens when CEF disabled?
PE1#show mpls forwarding-table

16 No Label 172.16.1.1/32 0 drop
17 No Label 192.168.12.12/32 0 drop
20 No Label 192.168.2.2/32 0 drop
21 No Label 10.1.212.0/24 0 drop
22 No Label 10.1.211.0/24 0 drop
23 No Label 192.168.11.11/32 0 drop
24 No Label 172.16.11.0/24 0 drop
25 No Label 172.16.14.0/24 0 drop
MPLS Forwarding Plane Outgoing Labels
PE1#show mpls forwarding-table 192.168.2.2

Local Outgoing Prefix Bytes Label Outgoing NextHop
20 19 192.168.2.2/32 0 Gi0/1 10.1.111.11
PE1#
Outgoing label also conveys what treatment the packet is going to

get. It could also be:
I. Pop - Pops the topmost label
II. Untagged - Untag the incoming MPLS packet
III. Aggregate - Untag and then do a FIB lookup
Label values 0-15 are reserved.
MPLS Forwarding Plane: Outgoing Labels
PE1#sh mpls forwarding-table
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
16 2002 10.13.1.22/32 0 Et0/0 10.13.1.5
2002 10.13.1.22/32 0 Et1/0 10.13.1.9
18 Pop tag 10.13.1.101/32 0 Et1/0 10.13.1.9
Pop tag 10.13.1.101/32 0 Et0/0 10.13.1.5
19 Pop tag 10.13.2.4/30 0 Et1/0 10.13.1.9
Pop tag 10.13.2.4/30 0 Et0/0 10.13.1.5
20 Untagged 5.5.5.5/32[V] 0 Se2/0 point2point
21 Pop tag 10.13.21.4/30 0 Et1/0 10.13.1.9
Pop tag 10.13.21.4/30 0 Et0/0 10.13.1.5
24 Aggregate 200.1.61.4/30[V] 0
26 Untagged 30.30.30.1/32[V] 0 Se2/0 point2point
PE1#
MPLS Forwarding Plane: Outgoing Labels
Untagged
Convert the incoming MPLS packet to an IP packet and forward it.
Pop
Pop the top label from the label stack present in an incoming MPLS packet
and forward it as an MPLS packet.
If there was only one label in the stack, then forward it as an IP packet. SAME
as imp-null label.
Aggregate
Convert the incoming MPLS packet to an IP packet and then do a FIB lookup
for it to find out the outgoing interface.
MPLS Forwarding Plane - Lookup
Three cases in the MPLS forwarding:
1) Label Imposition - IP to MPLS conversion
2) Label swapping - MPLS to MPLS
3) Label disposition - MPLS to IP conversion
So, depending upon the case, we need to check:

1) FIB - For IP packets that get forwarded as MPLS
2) LFIB - For MPLS packets that get forwarded as MPLS
3) LFIB - For MPLS packets that get forwarded as IP
MPLS Forwarding Plane: Loadsharing
MPLS Loadsharing (due to multiple paths to a prefix) is no different from that of
IP
Hashing-algorithm is still the typical FIB based i.e per-dest loadsharing by
default **
So the show commands are still relevant
Show ip cef exact-route <source> <dest> etc.
But the <dest> must be known in the FIB table, otherwise the command wont
work.
Wont work on P routers for the VPN prefixes.
MPLS Forwarding Plane: MTU Setting
mpls mtu <bytes> can be applied to an interface to change the
MPLS MTU size on the interface
MPLS MTU size is checked by the router
while converting an IP packet into a labeled packet or transmitting a labelled
packet
Label imposition(s) increases the packet size by 4 bytes/label, hence the
outgoing packet size may exceed interface MTU size, hence the need
to tune MTU
mpls mtu <bytes> command has no effect on interface or IP MTU size.
By default, MPLS MTU = interface MTU
MPLS MTU setting doesnt affect MTU handling for IP-to-IP packet switching
MPLS Forwarding Plane: MTU Setting
If the label imposition makes the packet bigger than the

MPLS MTU size of an outgoing interface, then:
- If the DF bit set, then discard the packet and send ICMP reply
back (with code=4)
- If the DF bit is not set, then fragment the IP packet (say, into 2
packets), and then impose the same label(s) on both the packets,
and then transmit MPLS packets
MPLS Forwarding Plane: Show Commands
show mpls forwarding
Shows all LFIB entries (vpn, non-vpn, TE etc.)
show mpls forwarding <prefix>
LFIB lookup based on a prefix
show mpls forwaring label <label>

LFIB lookup based on an incoming label
show mpls forwarding <prefix> detail

Shows detailed info such as L2 encap etc
MPLS Forwarding Plane: Show Commands
R2#show mpls forwarding 10.13.1.11 detail
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
45 51 10.13.1.11/32 0 Fa1/1/1 10.13.7.33
MAC/Encaps=14/18, MRU=1500, Tag Stack{51}
0003FD1C828100044E7548298847 00033000
No output feature configured
Per-packet load-sharing
R2#
14/18 means that the L2 header is of 14 bytes, but

L2+label header is 18 bytes (one label is 4 bytes)
Nodes and their Roles
PE Provider Edge router, connects to P and CE routers
Maintains separate routing table per VRF (RD)
Uses MP-BGP to exchange VRF routing information (RD + RT)
Performs LFIB and FIB lookups, label imposition and disposition
Exchanges IGP and LDP labels with the core
P Provider core router, connects to P and PE routers

Does not need to run BGP with the PEs
Performs LFIB MPLS forwarding, label swap or PHP
Exchanges IGP and LDP labels with other P routers and the PEs
CE Customer edge router, connects to the CE network and the PE

Forwards only IP packets no awareness of the MPLS network is needed
Routes between the CE internal network and the PE router
L3VPN by Parts
The Core:
BGP between PEs
LDP
IGP (mainly to get between PEs)
The Edge:
Any routing protocol between the PE and CE
PE-CE Protocol MP-iBGP PE-CE Protocol
LDP + IGP
CE CE
PE PE
P
VRF Overview
VRF = VPN Routing Forwarding instance
Isolated routing table, kind of like a VM
Easiest to think of each VRF like a different physical box
Interfaces are assigned to a VRF
Everything not in a VRF is in the global (routing table)
In MPLS-VPN each customer has a VRF
VRFs for customers, global for the Provider
vrf mpls
Customer ISP
Network
VRF Overview
Because each RIB is isolated, overlapping address are allowed
VRF-aware features add vrf <name> to commands
Commands without VRF keyword reference the global RIB
e0 e1
ip vrf forwarding red ip vrf forwarding red
ip address 1.1.1.1/24 ip address 2.2.2.2/24
e2
ip address 1.1.1.1/24
VRF Overview
e0 e1
ip vrf forwarding red ip vrf forwarding red
ip address 1.1.1.1/24 ip address 2.2.2.2/24
PE1#show ip route 2.2.2.0 e2

ip address 1.1.1.1/24
% Network not in table
PE1#show ip route vrf red 2.2.2.0

Routing Table: red
Routing entry for 2.2.2.0/24
Known via "connected"
* directly connected, via Ethernet1
MP-BGP (Multi Protocol BGP)
MP-BGP extends BGP to carry more than just IPv4 prefixes
Introduced address family style configuration
Allows for IPv6, MPLS and other information in same BGP session
When session is established the capabilities are negotiated
No new rules, still requires full mesh or RRs

RRs need to support additional capabilities
For MPLS only PEs need to speak BGP or know CE routes
L3VPN Relies on Extended Communities
Extended Communities are arbitrary TLVs attached to BGP prefixes
MP-BGP: Address-Families
Address-family vpnv4, ipv4 unicast vrf introduced
vpnv4 AFI for PE to PE (label information)
ipv4 unicast vrf for PE to CE

Neighbor must be activated for each AFI supported
router bgp 100
neighbor 3.3.3.3 remote-as 100
!
address-family vpnv4
neighbor 3.3.3.3 activate Remote PE
neighbor 3.3.3.3 send-community extended
!
address-family ipv4 unicast vrf red Local CE
neighbor 4.4.4.4 activate
MP-BGP: Advertising CE Routes
BGP maintains a table for each AFI (vpnv4, ipv4, vrf)
CE routes are placed into the vpnv4 BGP table
BGP routes in a vrf AFI are automatically turned into vpnv4 routes
If BGP is not PE-CE protocol routes must be redistributed into ipv4 vrf AFI
All vpnv4 routes get an assigned label

vpnv4 routes are exchanged between vpnv4 peers (PEs)
RTs and RDs: Creating the VRF
VRFs have 3 parts:
1. VRF name (case sensitive)
2. Route Distinguisher (RD)
3. Route Target(s) (RT)
ip vrf red
RD and RT are for MPLS; RD must always rd 100:100
route-target import 200:200
be defined route-target export 201:201
RD must be unique to the VRFs on the
local PE
If there is no MPLS, called VRF-lite
Understanding RDs
Route Distinguisher
Every CE route from all VRFs are placed in a
single VPNv4 table
How are routes from one VRF distinguished
from another VRF? ip vrf red
By prepending the RD to the route to create a rd 1:1
VPNv4 route route-target export 201:201
Only used to make routes unique VPNv4
prefixes
IPv4 Route: 192.168.1.0/24
RD: 100:100
VPNv4 Route: 100:100:192.168.10/24
Understanding the RT
Route Target
RT is a BGP extended community (extra
information on the update)
ip vrf red
route-target export adds the rd 1:1
community to the outbound update route-target import 100:100
route-target import defines which route-target import 200:200
routes to bring into the VRF route-target export 201:201
Multiple imports and exports allowed route-target export 44:313
RT in Action
ip vrf red
rd 1:1
route-target export 201:201
66:66:2.2.2.0/24
RT: 100:100 VRF Red RIB
55:55:1.1.1.0/24 BGP 2.2.2.0/24

RT: 201:201 Update 3.3.3.0/24
44:44:3.3.3.0/24
RT: 100:100
MP-BGP: Advertising CE Routes
ip vrf test
rd 1:1
route-target export 123:456
Route Target
Locally Assigned Label
RD
Prefix
Example Topology
MP-IBGP VPNv4
LDP + IGP
172.16.11.0/24 10.1.14.0/24 10.1.24.0/24 172.16.22.0/24
CE1 IOS PE P1 XR PE CE2

Lo0=172.16.1.1/32 Lo0=1.1.1.1/32 Lo0=4.4.4.4/32 Lo0=2.2.2.2/32 Lo0=172.16.2.2/32
Verify VPNv4 Neighborship
IOS-PE#sh bgp vpnv4 unicast all summary

BGP router identifier 1.1.1.1, local AS number 100
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
4.4.4.4 4 100 22 13 39 0 0 00:04:01 2
172.16.11.2 4 65001 31 38 39 0 0 00:24:28 1
RP/0/0/CPU0:XR-PE#sh bgp vpnv4 unicast summary

BGP router identifier 2.2.2.2, local AS number 100
Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd
4.4.4.4 0 100 100 65 37 0 0 00:35:10 2
RP/0/0/CPU0:XR-PE#show bgp vrf ABC summary
Verify PE to PE LSP
IOS-PE#ping mpls ipv4 2.2.2.2 255.255.255.255
.....
Success rate is 0 percent (0/5)
RP/0/0/CPU0:XR-PE(config)#mpls oam
RP/0/0/CPU0:XR-PE(config-oam)#commit
IOS-PE#ping mpls ipv4 2.2.2.2 255.255.255.255

!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/7 ms
Verify VPN Labels and Prefix
IOS-PE#show bgp vpnv4 unicast vrf ABC 172.16.1.1
BGP routing table entry for 1:1:172.16.1.1/32, version 23
Paths: (1 available, best #1, table ABC)
Advertised to update-groups:
5
Refresh Epoch 1
65001
172.16.11.2 (via vrf ABC) from 172.16.11.2 (172.16.1.1)
Origin IGP, metric 0, localpref 100, valid, external, best
Extended Community: RT:1:1 Local VPN Label
mpls labels in/out 24/nolabel
rx pathid: 0, tx pathid: 0x0
Verifying VPN Label on Remote PE
RP/0/0/CPU0:XR-PE#show bgp vpnv4 unicast vrf ABC 172.16.1.1
BGP routing table entry for 172.16.1.1/32, Route Distinguisher: 2:2
Last Modified: May 30 16:57:21.986 for 00:18:10
65001
1.1.1.1 (metric 3) from 4.4.4.4 (1.1.1.1)
Received Label 24 Remote VPN Label
Origin IGP, metric 0, localpref 100, valid, internal, best, group-best,
import-candidate, imported
Received Path ID 0, Local Path ID 1, version 36
Extended community: RT:1:1
Originator: 1.1.1.1, Cluster list: 4.4.4.4
Source AFI: VPNv4 Unicast, Source VRF: default, Source
Route Distinguisher: 1:1
Verifying Labels (The Easy Way)
IOS-PE#show bgp vpnv4 unicast vrf ABC labels
Network Next Hop In label/Out label
Route Distinguisher: 1:1 (ABC)
172.16.1.1/32 172.16.11.2 24/nolabel
172.16.2.2/32 2.2.2.2 nolabel/24006
172.16.11.0/30 0.0.0.0 16/nolabel(ABC)
172.16.22.0/30 2.2.2.2 nolabel/24005
In Label represents local label and Out Label represents remote label
Verifying CEF (FIB, and LFIB) - IOS
IOS-PE#show ip cef vrf ABC 172.16.2.2 detail
172.16.2.2/32, epoch 0, flags [rib defined all labels]
recursive via 2.2.2.2 label 24006()
nexthop 10.1.14.4 GigabitEthernet0/2 label 17()
IOS-PE#show mpls forwarding-table 2.2.2.2

19 17 2.2.2.2/32 0 Gi0/2 10.1.14.4
IOS-PE#show ip cef 2.2.2.2 detail

2.2.2.2/32, epoch 0
dflt local label info: global/19 [0x0]
1 RR source [no flags]
nexthop 10.1.14.4 GigabitEthernet0/2 label 17()
Verifying CEF (FIB, and LFIB) - IOS
P1#show mpls forwarding-table labels 17
17 Pop Label 2.2.2.2/32 1690 Gi0/2 10.1.24.2
P1#show ip cef 2.2.2.2 detail

Implicit-
2.2.2.2/32, epoch 0
Null
nexthop 10.1.24.2 GigabitEthernet0/2
P1#show ip cef 1.1.1.1 detail

1.1.1.1/32, epoch 0
nexthop 10.1.14.1 GigabitEthernet0/1
Verifying CEF (FIB, and LFIB) IOS XR
RP/0/0/CPU0:XR-PE#show cef vrf ABC 172.16.1.1 detail

. . .
via 1.1.1.1/32, 3 dependencies, recursive [flags 0x6000]
path-idx 0 NHID 0x0 [0xa14fd474 0x0]
recursion-via-/32
next hop VRF - 'default', table - 0xe0000000
next hop 1.1.1.1/32 via 24000/0/21
next hop 10.1.24.4/32 Gi0/0/0/0 labels imposed {16 24}
Load distribution: 0 (refcount 1)
Hash OK Interface Address
0 Y Unknown 24000/0
Local Label IGP Label VPN Label

for PE1 Lo0 from P1 from PE1
Verifying CEF (FIB, and LFIB) IOS XR
RP/0/0/CPU0:XR-PE#show mpls forwarding labels 24000
Mon May 30 18:39:05.368 UTC
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
24000 16 1.1.1.1/32 Gi0/0/0/0 10.1.24.4 540
RP/0/0/CPU0:XR-PE#show cef 1.1.1.1/32

. . .
via 10.1.24.4/32, GigabitEthernet0/0/0/0, 5 dependencies, weight 0, class 0
[flags 0x0]
path-idx 0 NHID 0x0 [0xa0ed91a8 0x0]
next hop 10.1.24.4/32
local adjacency
local label 24000 labels imposed {16}
Verifying Hardware Programming IOS XR
RP/0/0/CPU0:XR-PE#show cef vrf ABC 172.16.1.1 hardware egress location 0/0/CPU0

172.16.1.1/32, version 18, internal 0x5000001 0x0 (ptr 0xa13f20f4) [1], 0x0
(0x0), 0x208 (0xa1495140)
Updated May 30 16:57:22.336
Prefix Len 32, traffic index 0, precedence n/a, priority 3
via 1.1.1.1/32, 3 dependencies, recursive [flags 0x6000]
path-idx 0 NHID 0x0 [0xa14fd474 0x0]
recursion-via-/32
next hop 1.1.1.1/32 via 24000/0/21
. . .
Case Study MPLS Traffic Not Forwarded
Customer reported traffic forwarding issue to the VRFs attached to a newly
configured PE2 router
The PE1 router has the VPN label which is being shared with the remote PE2
router
MP-IBGP VPNv4
LDP + IGP
172.16.11.0/24 10.1.14.0/24 10.1.24.0/24 172.16.22.0/24
CE1 PE1 P1 PE2 CE2

Lo0=172.16.1.1/32 Lo0=1.1.1.1/32 Lo0=4.4.4.4/32 Lo0=2.2.2.2/32 Lo0=172.16.2.2/32
On PE1, the CEF shows the correct forwarding output.
Troubleshooting Approach
The first step in MPLS deployment is to verify if the LSP is complete or not.
Use ping mpls ipv4 <dest-pe-loopback> <subnet_mask> to verify LSP Path
Use traceroute mpls ipv4 <dest-pe-loopback> <subnet_mask> to verify
what is the path and see the point where MPLS packet is getting dropped
The other option is to check the labeling and LFIB information hop by hop or at
least on the node where the MPLS trace is dropped.
Findings
The MPLS PING failed
MPLS Trace dropped on P-1 router
Show mpls forwarding <PE2-loopback> output shows no label as outgoing label
P-1# show mpls forwarding 3.3.3.3
17 No Label 3.3.3.3/32 476193 Et0/0 23.23.23.2
Verified that LDP was enabled between the two routers but there was no
bindings
Resolution
P-1(config)#no mpls ldp advertise-labels
P-1(config)#mpls ldp advertise-labels for LOOPBACK_ACL
The P-1 router had an ACL to limit the allocation of labels for certain prefixes
Sometimes, there are too many prefixes in the core due to which the labels get
exhausted
To prevent such situations, LDP is configured to allocate labels for certain prefixes but
not all.
PE2 loopback address was added in the ACL which fixed the problem
6VPE Troubleshooting
Reference Topology
IPv4 192.168.1.1/32
IPv6 2001:DB8::1/128
AS 100
Service Provider Core
PE1 IPv4 IGP
MPLS
IPv4 192.168.2.2/32
IPv6 2001:DB8::2/128
IPv4 192.168.5.5/32
IPv6 2001:DB8::6/128 IPv6 2001:DB8::7/128
IPv6 2001:DB8::5/128
CE1 RR-P PE5 CE2

PE2
AS 200 IPv4 192.168.4.4/32 AS 300
VRF Configuration
IPv6 enabled VRFs are configured in the same way as IPv4 VRFs
On Cisco IOS, use command vrf definition to configure both IPv4 and IPv6
capable VRFs
vrf definition ABC vrf ABC
rd 1:1 address-family ipv6 unicast
address-family ipv6 unicast import route-target
route-target import 1:1 1:1
route-target export 1:1 2:2
route-target import 2:2 export route-target
address-family ipv4 unicast 1:1
. . . address-family ipv4 unicast
interface Gi0/0 . . .
vrf forwarding ABC interface Gi0/0/0/0
ipv6 address xx:xx:xx::y/64 vrf ABC
ipv6 address xx:xx:xx::y/64
6VPE Configuration Cisco IOS
router bgp 100
bgp router-id 192.168.1.1
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 192.168.4.4 update-source Loopback0
!
address-family vpnv6
neighbor 192.168.4.4 activate
neighbor 192.168.4.4 send-community extended
neighbor 192.168.4.4 next-hop-self
!
address-family ipv6 vrf red
neighbor 2001:DB8:0:16::6 remote-as 200
neighbor 2001:DB8:0:16::6 activate
exit-address-family
6VPE Configuration IOS XR
router bgp 100
bgp router-id 192.168.2.2
address-family vpnv6 unicast
!
neighbor 192.168.4.4
remote-as 100
update-source Loopback0
address-family vpnv6 unicast
next-hop-self
!
vrf red
rd 100:1
address-family ipv6 unicast
!
neighbor 2001:db8:0:26::6
remote-as 200
address-family ipv6 unicast
route-policy pass in
route-policy pass out
Verifying Control Plane
Since both control plane and data plane works in opposite direction, verify the
IPv6 VPN prefix on PE5.
PE5#show ipv6 route vrf red

! Output omitted for brevity
B 2001:DB8::6/128 [200/0]
via 192.168.1.1%default, indirectly connected
B 2001:DB8::7/128 [20/0]
via FE80::7, GigabitEthernet0/2
Verify the VPNv6 prefix in BGP along with the local label
PE5#show bgp vpnv6 unicast vrf red 2001:db8::7/128

BGP routing table entry for [100:5]2001:DB8::7/128, version 38
Paths: (1 available, best #1, table red)
2
Refresh Epoch 1
300
2001:DB8:0:57::7 (FE80::7) (via vrf red) from 2001:DB8:0:57::7
(192.168.7.7)
Origin IGP, metric 0, localpref 100, valid, external, best
Extended Community: RT:100:1
mpls labels in/out 23/nolabel
The remote IOS PE - PE1, receives the VPNv6 prefix as the out label of 23.
PE1#show bgp vpnv6 unicast vrf red 2001:db8::7/128

BGP routing table entry for [100:1]2001:DB8::7/128, version 7
Paths: (1 available, best #1, table red)
1
Refresh Epoch 1
300, imported path from [100:5]2001:DB8::7/128 (global)
::FFFF:192.168.5.5 (metric 3) (via default) from 192.168.4.4 (192.168.4.4)
Origin IGP, metric 0, localpref 100, valid, internal, best
Extended Community: RT:100:1
mpls labels in/out nolabel/23
RP/0/0/CPU0:PE2#show bgp vpnv6 unicast vrf red 2001:db8::7/128
BGP routing table entry for 2001:db8::7/128, Route Distinguisher: 100:1
Last Modified: Feb 4 22:46:29.408 for 1d05h
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
300
192.168.5.5 (metric 3) from 192.168.4.4 (192.168.5.5)
Received Label 23
Origin IGP, metric 0, localpref 100, valid, internal, best, group-best,
import-candidate, imported
Received Path ID 0, Local Path ID 1, version 5
Extended community: RT:100:1
Source VRF: default, Source Route Distinguisher: 100:5
Verifying Data Plane
PE1#show ipv6 cef vrf red 2001:db8::7/128 detail

2001:DB8::7/128, epoch 0, flags [rib defined all labels]
recursive via 192.168.5.5 label 23
nexthop 10.1.14.4 GigabitEthernet0/2 label 19
PE1#show mpls forwarding-table 192.168.5.5

21 19 192.168.5.5/32 0 Gi0/2 10.1.14.4
Verifying Data Plane on IOS XR
RP/0/0/CPU0:PE2#show cef vrf red ipv6 2001:db8::7/128
2001:db8::7/128, version 7, internal 0x5000001 0x0 (ptr 0xa140c5f4) [1],
0x0 (0x0), 0x208 (0xa14db230)
Updated Feb 4 22:46:29.731
Prefix Len 128, traffic index 0, precedence n/a, priority 3
via ::ffff:192.168.5.5, 3 dependencies, recursive [flags 0x6000]
path-idx 0 NHID 0x0 [0xa176b0bc 0x0]
recursion-via-/128
next hop ::ffff:192.168.5.5 via ::ffff:192.168.5.5:0
RP/0/0/CPU0:PE2#show mpls forwarding-table prefix 192.168.5.5/32

24001 19 192.168.5.5/32 0 Gi0/0/0/1 10.1.24.4
Verifying Ingress Hardware Programming IOS XR
PE2#show cef vrf red ipv6 2001:db8::7/128 hardware ingress detail loc0/0/CPU0
0x0 (0x0), 0x208 (0xa14db230)
Updated Feb 4 22:46:29.730
[1 type 1 flags 0x48089 (0xa14f5398) ext 0x0 (0x0)]
LW-LDI[type=0, refc=0, ptr=0x0, sh-ldi=0x0]
gateway array update type-time 1 Feb 4 22:46:29.730
LDI Update time Feb 4 22:46:29.730
recursion-via-/128
Ingress platform showdata is not available.

0 Y Unknown ::ffff:192.168.5.5:0
Verifying Egress Hardware Programming IOS XR
PE2#show cef vrf red ipv6 2001:db8::7/128 hard egr det loc 0/0/CPU0
0x0 (0x0), 0x208 (0xa14db230)
[1 type 1 flags 0x48089 (0xa14f5398) ext 0x0 (0x0)]
LW-LDI[type=0, refc=0, ptr=0x0, sh-ldi=0x0]
gateway array update type-time 1 Feb 4 22:46:29.730
LDI Update time Feb 4 22:46:29.730
recursion-via-/128
Egress platform showdata is not available.

0 Y Unknown ::ffff:192.168.5.5:0
Troubleshooting 6VPE / MPLS
Verifying Counters on Interface
Verify the interface counters for mpls forwarding
If there is forwarding problem, check the counters and ensure they are not
increasing.
Initiate the VPNv6 prefix ping and verify the counters again to see if they
increased
RP/0/0/CPU0:PE2#show interface gigabitethernet0/0/0/1 accounting
GigabitEthernet0/0/0/1
Protocol Pkts In Chars In Pkts Out Chars Out
IPV4_UNICAST 261333 20337753 46929 2305821
IPV6_UNICAST 21017 2062274 20995 1964348
MPLS 10 1180 14426 968553
ARP 84 5040 84 3528
IPV6_ND 13296 1193736 10306 742016
Inter-AS MPLS VPNs
Inter-AS MPLS VPNs
Flavors
Previous section VPNs within Single-AS boundary
Inter-AS MPLS VPN VPNs spanning across multiple AS boundaries
Types:
Option 1 Back to Back VRF
Option 2 Inter-Provider VPNs using ASBR-to-ASBR approach
A. Next-Hop-Self Method
B. Redistribute Connected Method
C. Multi-hop EBGP between ASBRs
Option 3 MP-EBGP between RR and EBGP between ASBR
Inter-AS MPLS VPNs
Option 1 - Back-to-Back VRF Method
VRF- ABC VRF- XYZ

RR-P1 RR-P2
PE1 IPv4 + IGP/BGP PE2

AS100 AS200
PE-ASBR1 PE-ASBR2
Lo0-11.11.11.11/32 Lo0-22.22.22.22/32
CE1 CE2
Inter-AS MPLS VPNs
Option 2a ASBR-to-ASBR with Next-Hop-Self Method
172.16.1.1 v1
RR-P1 RR-P2
MP-eBGP
PE1 PE2
AS100 AS200
PE-ASBR1 PE-ASBR2
Lo0-11.11.11.11/32 Lo0-22.22.22.22/32
neighbor x.x.x.x next-hop-self

CE1 CE2
172.16.1.1 No LDP or IGP required on the link between the two ASBRs. 172.16.2.2
Configure no bgp default route-target filter on ASBRs
Inter-AS MPLS VPNs
Option 2a ASBR-to-ASBR with Next-Hop-Self Method
Both ASBRs allocate VPN labels for prefixes received from the other AS.
When MP-eBGP peering is configured between ASBRs, below configuration is
done to complete LSP
mpls bgp forwarding on Cisco IOS devices
no bgp default route-target filter configured on ASBR not having
VRF configured.
Default behavior deny vpnv4 prefixes that are not imported in any local VRF
On XR retain route-target all
Inter-AS MPLS VPNs
Option 2b ASBR-to-ASBR with Redistribute Connected Method
172.16.1.1 v1
RR-P1 RR-P2
MP-eBGP
PE1 PE2
AS100 AS200
PE-ASBR1 PE-ASBR2
Lo0-11.11.11.11/32 Lo0-22.22.22.22/32
CE1 No LDP or IGP required on the link between the two ASBRs. CE2
172.16.1.1 Configure no bgp default route-target filter on ASBRs 172.16.2.2
Inter-AS MPLS VPNs
Option 2b ASBR-to-ASBR with Redistribute Connected Method
Redistribute the link between ASBR into IGP in local AS
Required on both ASBR routers.
VPN label V1 is advertised from AS100 towards ASBR-PE2 in AS200.
Since the NH changes on ASBR-PE2, ASBR-PE2 swaps that label with V2 and
advertises it towards the core.
Inter-AS MPLS VPNs
Option 2c ASBR-to-ASBR with Multi-Hop EBGP between ASBRs Method
172.16.1.1 v1
RR-P1 RR-P2
PE1 MP-eBGP
PE2
AS100 AS200
PE-ASBR1 PE-ASBR2
Lo0-11.11.11.11/32 Lo0-22.22.22.22/32
CE1 Loopback to loopback peering between ASBRs CE2

172.16.1.1 Configure no bgp default route-target filter on ASBRs 172.16.2.2
Inter-AS MPLS VPNs
Option 2c ASBR-to-ASBR with Multi-Hop EBGP between ASBRs Method
Loopback to loopback MP-EBGP peering between ASBRs.
IGP or static route required between the ASBR link
VPN label V1 is advertised from AS100 towards ASBR-PE2 in AS200.
Since the NH changes on ASBR-PE2, ASBR-PE2 swaps that label with V2 and
advertises it towards the core.
Inter-AS MPLS VPNs
Option 3 Multi-Hop MP-EBGP between RR and EBGP between ASBRs
MP-eBGP
RR-P1 RR-P2
eBGP +
Send-label
PE1 PE2
AS100 AS200
PE-ASBR1 PE-ASBR2
Lo0-11.11.11.11/32 Lo0-22.22.22.22/32
CE1 Neighbor send-label required on eBGP peers on ASBR. CE2

172.16.1.1 172.16.2.2
Inter-AS MPLS VPNs
Option 3 Multi-Hop MP-EBGP between RR and EBGP between ASBRs
RR & ASBR loopbacks are advertised via EBGP on ASBR
The remote ASBR redistributes the received loopbacks into local IGP
MP-EBGP peering configured between RRs on each AS
Configure neighbor next-hop-unchanged
Complete Your Online Session Evaluation
Give us your feedback to be
entered into a Daily Survey
Drawing. A daily winner will
receive a $750 Amazon gift card.
Complete your session surveys
through the Cisco Live mobile
app or from the Session Catalog
on CiscoLive.com/us.
Dont forget: Cisco Live sessions will be available

for viewing on-demand after the event at
CiscoLive.com/Online
Continue Your Education
Demos in the Cisco campus
Walk-in Self-Paced Labs
Table Topics
Meet the Engineer 1:1 meetings
Related sessions
Thank you

BRKMPL 3124

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

BRKMPL 3124

Transféré par

Droits d'auteur :

Formats disponibles

Troubleshooting End-to-End MPLS

Vinit Jain - CCIE# 22854

Control Plane Data Plane

Label COS S TTL

An MPLS packet may have more than one label

The following scenarios may produce more than one label:

IGP domain without a label IGP domain with a label

LSPs are derived from IGP routing information

install feature-set mpls

PE1#sh mpls ldp neighbor

PE1#show tcp brief| i 646

Following avoids both shortcomings

show mpls ldp discovery [detail]

PE1#show mpls ldp discovery

PE1#show mpls ldp discovery P1#show mpls ldp discovery

R1#debug mpls ldp transport connections

PE1(config-if)#mpls label protocol ldp

PE1#show mpls ldp discovery P1#show mpls ldp discovery

PE1#show ip route 192.168.11.11

Problem: Default route towards the peering router

PE1#show mpls ldp discovery PE2#show mpls ldp discovery

0/0/CPU0 t1 [PEER]:581: VRF(0x60000000): Peer(192.168.11.11:0): DOWN - reason 'TCP connection closed'

0/0/CPU0 t1 [PEER]:575: VRF(0x60000000): Peer(192.168.11.11:0): DOWN - reason 'Received Notification message

0/0/CPU0 t1 [PEER]:3262: VRF(0x60000000): Release Peer(192.168.11.11:0): rsn 'Received Notification message

LDP IGP Sync feature is enabled under IGP (OSPF/ISIS)

router (config-isis-if-af) # mpls ldp sync [ level <1-2> ]

router (config-ospf) # mpls ldp sync + (config-ospf-ar), (config-ospf-ar-if)

router (config-ospf) # mpls ldp sync-igp-shortcuts + (config-ospf-ar)

LDP IGP Sync delays are configured under LDP

router (config-ldp) # igp sync delay on-session-up <sec>

router (config-ldp) # igp sync delay on-proc-restart <sec>

router (config-ldp) # session protection [ for <peer-acl> ] [ duration { <sec> | infinite } ]

router (config-ldp) # log session-protection

CE1 PE1 P1 PE2 CE2

Broken LDP adjacency

Ping mode: Connectivity check of an LSP

Message Type Reply Mode Return Code Return Subcode

Timestamp Sent (seconds)

Timestamp Sent (microseconds)

Timestamp Received (seconds)

Timestamp Received (microseconds)

1 Malformed Echo Request Received

2 One Or More of the TLVs Was Not Understood

3 Replying Router Is an Egress for the FEC

4 Replying Router Has No Mapping for the FEC

5 Replying Router Is Not One of the Downstream Routers

R1#ping mpls ipv4 192.168.2.2/32 verbose

In Prefix Output Out

CE1 PE1 P1 PE2 CE2

172.16.1.1 TTL=252 Label 16, TTL=253 Label 16

no mpls ip propagate-ttl forwarded

CE1#traceroute 172.16.2.2 source 172.16.1.1 (mpls ip propagate-ttl forwarded)

CE1#traceroute 172.16.2.2 source 172.16.1.1 (no mpls ip propagate-ttl forwarded)

CE1 PE1 P1 PE2 CE2

PE1#show mpls forwarding-table

PE1#show mpls forwarding-table 192.168.2.2

Outgoing label also conveys what treatment the packet is going to

So, depending upon the case, we need to check:

If the label imposition makes the packet bigger than the

show mpls forwaring label <label>

show mpls forwarding <prefix> detail

14/18 means that the L2 header is of 14 bytes, but

P Provider core router, connects to P and PE routers