Troubleshooting End-to-End MPLSd2zmdbbm9feqrf.cloudfront.net/2016/usa/pdf/BRKMPL-3124.pdf ·...

Troubleshooting End-to-End MPLS

Vinit Jain - CCIE# 22854Twitter - @vinugenie

BRKMPL-3124

© 2016 Cisco and/or its affiliates. All rights reserved. Cisco Public

Coming

this year

BRKMPL-3124 3

• Fundamentals

• Troubleshooting LDP Issues

• Troubleshooting MPLS LSP

• Troubleshooting MPLS L3 VPNs

• Troubleshooting 6VPE

• Inter-AS MPLS VPNs

• Conclusion

Agenda


Introduction

• 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

Housekeeping

BRKMPL-3124 5

MPLS Fundamentals


MPLS Fundamentals

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

BRKMPL-3124 7


MPLS Fundamentals

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

Terminologies

BRKMPL-3124 8


MPLS FundamentalsMPLS Architecture

Control Plane Data Plane

Routing

Protocol

Database

Routing

Information

Base (RIB)

Label

Information

Base (LIB)

Label

Bindings

via LDP

peering

Forwarding

Information

Base (FIB)

Label

Forwarding

Information

Base (LFIB)

Routing

updates

from peer

router’s

Incoming IP

Packet

Incoming

MPLS Packet

Outgoing

MPLS/IP

Packet

BRKMPL-3124 9


MPLS Fundamentals

• MPLS uses a 32-bit label field that is inserted between Layer 2 and Layer 3 headers

MPLS Label: Label Format

0 1 2 30 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)

BRKMPL-3124 10


MPLS Fundamentals

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: Ethertype

BRKMPL-3124 11


MPLS FundamentalsMPLS 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

BRKMPL-3124 12


MPLS FundamentalsMPLS 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)

BRKMPL-3124 13


MPLS FundamentalsLabel Switch Path (LSP)

LSPs are derived from IGP routing information

LSPs may diverge from IGP shortest path• LSP tunnels (explicit routing) with TE

LSPs are unidirectional

LSP follows IGP shortest path LSP diverges from IGP shortest path

IGP domain without a label

distribution protocol

IGP domain with a label

distribution protocol

BRKMPL-3124 14


MPLS Fundamentals

• Which protocols have signaling and labeling capabilities?

• OSPF / IS-IS

• RSVP

• LDP / TDP

• BGP

Facts Check - Question

BRKMPL-3124 15

Troubleshooting LDP Issues



IOS / IOS XE

MPLS LDP Configuration

IOS XR

mpls label protocol ldp

!

interface Gig 0/0

mpls ip

mpls label protocol ldp

exit

!

mpls ldp router-id

loopback0 force

mpls ldp

router-id x.x.x.x

interface gi 0/0/0/0

interface gi 0/0/0/1

install feature-set mpls

feature-set mpls

feature mpls

mpls ldp configuration

router-id x.x.x.x

!

interface ethernet 2/1

mpls ip

NX-OS

BRKMPL-3124 17



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

BRKMPL-3124 18


Troubleshooting LDP IssuesLDP Neighborship Negotiation

BRKMPL-3124 19


Troubleshooting LDP IssuesVerifying 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#

BRKMPL-3124 20



• Ensure reachability between the LDP router ID’s

• Verify no ACL in path blocking TCP port 646 and other Multicast traffic for LDP Hello’s.

Reachability and ACL verification

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

.....

Success rate is 0 percent (0/5)

PE1#telnet 192.168.11.11 646 /source-interface lo0

Trying 192.168.11.11, 646 ...

% Destination unreachable; gateway or host down

Check Routing

Configuration

Verify ACLs in the path or

on the routers itself

BRKMPL-3124 21



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

LDP Router-id

BRKMPL-3124 22


Troubleshooting LDP issuesVerifying 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

Discovery Sources:

Interfaces:

GigabitEthernet0/1 (ldp): xmit/recv

LDP Id: 192.168.11.11:0

Local LDP_ID

Discovered

Neighbors’ LDP_ID

Xmited and

Recvd Hellos

on that

interface

BRKMPL-3124 23


Troubleshooting LDP issuesProblem with xmit / recv



192.168.1.1:0

Discovery Sources:

Interfaces:

GigabitEthernet0/1 (ldp): xmit

R1#debug mpls ldp transport connections

07:00:06.106: ldp: Scan listening TCBs



PE1 P1

P1#show mpls ldp discovery


192.168.11.11:0

Discovery Sources:

Interfaces:

GigabitEthernet0/1 (tdp): xmit

Lo0=192.168.1.1 Lo0=192.168.11.11

Label Protocol

is TDP

PE1(config-if)#mpls label protocol ldp

BRKMPL-3124 24


Troubleshooting LDP issues

Problem: Default route towards the peering router

LDP No Route Problem



192.168.1.1:0

Discovery Sources:

Interfaces:

Gi0/1 (ldp): xmit/recv

LDP Id: 192.168.11.11:0; no route

PE1 P1

P1#show mpls ldp discovery


192.168.11.11:0

Discovery Sources:

Interfaces:

Gi0/1 (ldp): xmit/recv

LDP Id: 192.168.1.1:0

Lo0=192.168.1.1 Lo0=192.168.11.11

PE1#show ip route 192.168.11.11

% Network not in table

BRKMPL-3124 25


Troubleshooting LDP issuesProblem due to Summarization

PE1 P1

PE1#show mpls ldp neighbor 192.168.11.11



192.168.1.1:0


LDP Id: 192.168.11.11:0


Routing entry for 192.168.11.11/32

Known via "ospf 100", distance 110, metric 2, type

intra area

Last update from 10.1.111.11 on Gi0/1, 00:04:34 ago

Routing Descriptor Blocks:

* 10.1.111.11, from 192.168.11.11, 00:04:34 ago,

via GigabitEthernet0/1

Route metric is 2, traffic share count is 1

PE2#sh mpls ldp neighbor 192.168.1.1



192.168.11.11:0


LDP Id: 192.168.1.1:0



Known via "bgp 100", distance 200, metric 0

Tag 1, type internal

Last update from 192.168.1.12 20:10:38 ago

Routing Descriptor Blocks:

* 192.168.1.12, from 192.168.12.12, 20:10:38

ago

Route metric is 0, traffic share count is 1

AS Hops 5

BRKMPL-3124 26



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

MPLS LDP Trace on IOS XR

Also good to check “show

mpls ldp trace discovery”

BRKMPL-3124 27



• 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

BRKMPL-3124 28



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

BRKMPL-3124 29


Troubleshooting LDP IssuesLDP & 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)

BRKMPL-3124 30


Troubleshooting LDP IssuesLDP & IGP Sync

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

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

LDP IGP Sync delays are configured under LDP

BRKMPL-3124 31



• 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

BRKMPL-3124 32


Troubleshooting LDP IssuesLDP Session Protection

router (config-ldp) # log session-protection

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

BRKMPL-3124 33

Troubleshooting MPLS LSP



• Broken LDP adjacency

• MPLS not enabled

• Mismatch labels

• Software/hardware corruption

Reasons for LSP to Break

PE1

192.168.1.1/32

PE2

192.168.2.2/32

CE1

Lo0=172.16.1.1/32

CE2

Lo0=172.16.2.2/32

P1

192.168.11.11/32

MP-IBGP – VPNv4

10.1.111.0/24 10.1.211.0/24 172.16.22.0/24172.16.11.0/24

LDP + IGP

BRKMPL-3124 35



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

Label Information Base (LIB)

BRKMPL-3124 36



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

Looking at the LIB

BRKMPL-3124 37



• 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

Label Forwarding Information Base (LFIB)

RIBLIB LFIBprefix + next-hop

prefix, next-hop and in-

label, out-label

get in- and out-label for

(prefix, next-hop)

LDP TDP

(prefix, LDP Ident,

label)(prefix,next-hop,

in-label, out-label)

(prefix, next-hop)

BRKMPL-3124 38


Troubleshooting MPLS LSPBuilding the LFIB

P1#show ip route 3.3.3.4Routing 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.1Peer 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.4Local 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

BRKMPL-3124 39



• 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

MPLS OAM

BRKMPL-3124 40



• 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

FEC Types Supported

BRKMPL-3124 41



• 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

LSP Ping (ping mpls . . . )

BRKMPL-3124 42


Troubleshooting MPLS LSPPacket Format

Version Number Must Be Zero

Message Type Reply Mode Return Code Return Subcode

Sender’s Handle

Sequence Number

Timestamp Sent (seconds)

Timestamp Sent (microseconds)

Timestamp Received (seconds)

Timestamp Received (microseconds)

TLV …

BRKMPL-3124 43



• Version number: 1

• Message Type• MPLS Echo Request

• MPLS Echo Reply

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

Packet Format

BRKMPL-3124 44



• 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

BRKMPL-3124 45



• 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

BRKMPL-3124 46



• 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

Reply Modes

BRKMPL-3124 47


Troubleshooting MPLS LSPReturn 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”

6Replying Router Is one of the “Downstream Routers”, and Its Mapping for this FEC on the Received Interface Is the Given Label

BRKMPL-3124 48


Troubleshooting MPLS LSPMPLS 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

BRKMPL-3124 49



• 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-request’s 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 (Operational Theory)

BRKMPL-3124 50


Troubleshooting MPLS LSPMPLS Ping Packet Capture

BRKMPL-3124 51


Operation

• 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

MPLS OAM Caveats

BRKMPL-3124 52



• 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

TTL Field in Labels

BRKMPL-3124 53



• 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

Operation

BRKMPL-3124 54


Traceroute in MPLS Network

In

Label

Prefix Output

Interface

Out

Label

- 172.16.2.2/32 Y 19 24008

16 172.16.1.1/32 X -

In

Label

Prefix Output

Interface

Out

Label

22 192.168.1.1/32 X pop

19 192.168.2.2/32 Y pop

In

Label

Prefix Output

Interfac

e

Out

Label

24008 172.16.2.2/32 Y -

- 172.16.1.1/32 X 22 16

PE1 P1 PE2

CE1 CE2

Y

X

Y

X

192.168.1.1/32 192.168.2.2/32

172.16.1.1/32 172.16.2.2/32

BRKMPL-3124 55


Troubleshooting MPLS LSPTraceroute in MPLS Network

PE1 P1 PE2CE1 CE2

192.168.1.1/32 192.168.2.2/32 172.16.2.2/32

172.16.2.2

TTL=2

UDP port 35678

172.16.2.2

TTL=1

UDP port 35678

172.16.2.2

TTL=255, ICMP

TTL Exceeded

172.16.1.1 TTL=254

ICMP TTL Exceeded

Label 24008

Label 19, TTL=1

Label 24008,

TTL=255

172.16.1.1 TTL=252

ICMP TTL Exceeded

172.16.1.1 TTL=254

ICMP TTL Exceeded

172.16.1.1/32

Label 16

Label 22, TTL=254

Label 16, TTL=253

Aggregate Outgoing

Label, IP Lookup

done in CEF for VRF

BRKMPL-3124 56



• 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

BRKMPL-3124 57



• 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

MPLS Trace Hiding

no mpls ip propagate-ttl forwarded

BRKMPL-3124 58


Troubleshooting MPLS LSPMPLS Trace Hiding

CE1#traceroute 172.16.2.2 source 172.16.1.1


Tracing the route to 172.16.2.2

1 172.16.11.2 [AS 100] 3 msec 3 msec 3 msec

2 10.1.111.11 [MPLS: Labels 19/24008 Exp 0] 122 msec 25 msec 19 msec

3 10.1.211.2 [MPLS: Label 24008 Exp 0] 21 msec 16 msec 23 msec

4 172.16.12.1 [AS 100] 23 msec * 22 msec

remote PE

Plocal PE

remote CE

(mpls ip propagate-ttl forwarded)

CE1#traceroute 172.16.2.2 source 172.16.1.1


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

2 10.1.211.2 [MPLS: Label 24008 Exp 0] 25 msec 25 msec 31 msec

3 172.16.12.1 [AS 100] 24 msec * 28 msec

remote PElocal PE

remote CE

(no mpls ip propagate-ttl forwarded)

BRKMPL-3124 59


Troubleshooting MPLS LSPMPLS Trace with no mpls ip propagate-ttl on PE routers

PE1 P1 PE2CE1 CE2

172.16.2.2/32

172.16.2.2

TTL=2

UDP port 35678

172.16.2.2

TTL=1

UDP port 35678

172.16.2.2

TTL=1

UDP port 35678

172.16.1.1 TTL=254,

ICMP

Port Unreachable

Label 24008

Label 19, TTL=1

Label 24008,

TTL=255

172.16.1.1 TTL=254,

ICMP

Port Unreachable

172.16.1.1 TTL=254,

ICMP

Port Unreachable

172.16.1.1/32

Label 16

Label 22, TTL=255

Label 16, TTL=254

172.16.2.2

TTL=1

UDP port 35678

172.16.1.1

TTL=255, ICMP

Port Unreachable

udp port

35678?

Aggregate Outgoing

Label

BRKMPL-3124 60



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

MPLS Forwarding Plane

BRKMPL-3124 61


Troubleshooting MPLS LSPWhat happens when CEF disabled?

PE1#show mpls forwarding-table

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

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

BRKMPL-3124 62



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

BRKMPL-3124 63


Troubleshooting MPLS LSPMPLS 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#

BRKMPL-3124 64



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: Outgoing Labels

BRKMPL-3124 65



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

BRKMPL-3124 66



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 won’t work.

• Won’t work on P routers for the VPN prefixes.

MPLS Forwarding Plane: Loadsharing

BRKMPL-3124 67



• “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 doesn’t affect MTU handling for IP-to-IP packet switching

MPLS Forwarding Plane: MTU Setting

BRKMPL-3124 68



• 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: MTU Setting

BRKMPL-3124 69



“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

BRKMPL-3124 70


Troubleshooting MPLS LSPMPLS 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)

BRKMPL-3124 71

Troubleshooting MPLS L3 VPNs



• 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 PE’s

• Performs LFIB MPLS forwarding, label swap or PHP

• Exchanges IGP and LDP labels with other P routers and the PE’s

• 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

Nodes and their Roles

BRKMPL-3124 73



• The Core:

• BGP between PEs

• LDP

• IGP (mainly to get between PEs)

• The Edge:

• Any routing protocol between the PE and CE

L3VPN by Parts

MP-iBGP

LDP + IGP

PE-CE Protocol PE-CE Protocol

PE PECE CE

P

BRKMPL-3124 74


vrf


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

mplsCustomer

NetworkISP

BRKMPL-3124 75



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

VRF Overview

e0ip vrf forwarding redip address 1.1.1.1/24


e2ip address 1.1.1.1/24

BRKMPL-3124 76


Troubleshooting MPLS L3 VPNsVRF Overview



e2ip address 1.1.1.1/24


% Network not in table

PE1#show ip route vrf red 2.2.2.0

Routing Table: red


Known via "connected"

* directly connected, via Ethernet1

BRKMPL-3124 77



• 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 (Multi Protocol BGP)

BRKMPL-3124 78



• 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

MP-BGP: Address-Families

router bgp 100neighbor 3.3.3.3 remote-as 100!address-family vpnv4neighbor 3.3.3.3 activateneighbor 3.3.3.3 send-community extended

!address-family ipv4 unicast vrf redneighbor 4.4.4.4 remote-as 400neighbor 4.4.4.4 activate

Remote PE

Local CE

BRKMPL-3124 79



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)

MP-BGP: Advertising CE Routes

BRKMPL-3124 80



• VRFs have 3 parts:

1. VRF name (case sensitive)

2. Route Distinguisher (RD)

3. Route Target(s) (RT)

• RD and RT are for MPLS; RD must alwaysbe defined

• RD must be unique to the VRFs on the local PE

• If there is no MPLS, called “VRF-lite”

RTs and RDs: Creating the VRF

ip vrf redrd 100:100route-target import 200:200route-target export 201:201

BRKMPL-3124 81



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

• By prepending the RD to the route to create a VPNv4 route

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

ip vrf redrd 1:1route-target import 200:200route-target export 201:201

BRKMPL-3124 82



• Route Target

• RT is a BGP extended community (extra information on the update)

• “route-target export” adds the community to the outbound update

• “route-target import” defines which routes to bring into the VRF

• Multiple imports and exports allowed

Understanding the RT

ip vrf redrd 1:1route-target import 100:100route-target import 200:200

route-target export 201:201route-target export 44:313

BRKMPL-3124 83


Troubleshooting MPLS L3 VPNsRT in Action

ip vrf red

rd 1:1

route-target import 100:100

route-target export 201:201

66:66:2.2.2.0/24

RT: 100:100

55:55:1.1.1.0/24

RT: 201:201

44:44:3.3.3.0/24

RT: 100:100

VRF Red RIB

BGP

Update

2.2.2.0/24

3.3.3.0/24

BRKMPL-3124 84


Troubleshooting MPLS L3 VPNsMP-BGP: Advertising CE Routes

Prefix

Locally Assigned Label

RD

Route Target

ip vrf testrd 1:1route-target export 123:456

BRKMPL-3124 85


Troubleshooting MPLS L3 VPNsExample Topology

IOS PE

Lo0=1.1.1.1/32

XR PE

Lo0=2.2.2.2/32

CE1

Lo0=172.16.1.1/32

CE2

Lo0=172.16.2.2/32

P1

Lo0=4.4.4.4/32

MP-IBGP – VPNv4

10.1.14.0/24 10.1.24.0/24 172.16.22.0/24172.16.11.0/24

LDP + IGP

BRKMPL-3124 86


Troubleshooting MPLS L3 VPNsVerify VPNv4 Neighborship

RP/0/0/CPU0:XR-PE#show bgp vrf ABC summary

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

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

BRKMPL-3124 87



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 PE to PE LSP

BRKMPL-3124 88



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

mpls labels in/out 24/nolabel

rx pathid: 0, tx pathid: 0x0

Verify VPN Labels and Prefix

Local VPN Label

BRKMPL-3124 89



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

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 VPN Label on Remote PE

Remote VPN Label

BRKMPL-3124 90



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

Verifying Labels (The Easy Way)

In Label represents local label and Out Label represents remote label

BRKMPL-3124 91


Troubleshooting MPLS L3 VPNsVerifying 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()

BRKMPL-3124 92


Troubleshooting MPLS L3 VPNsVerifying CEF (FIB, and LFIB) - IOS

P1#show ip cef 2.2.2.2 detail

2.2.2.2/32, epoch 0


nexthop 10.1.24.2 GigabitEthernet0/2

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 1.1.1.1 detail

1.1.1.1/32, epoch 0


nexthop 10.1.14.1 GigabitEthernet0/1

Implicit-

Null

BRKMPL-3124 93


Troubleshooting MPLS L3 VPNsVerifying 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

IGP Label

from P1

VPN Label

from PE1

Local Label

for PE1 Lo0

BRKMPL-3124 94


Troubleshooting MPLS L3 VPNsVerifying CEF (FIB, and LFIB) – IOS XR

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}

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

BRKMPL-3124 95


Troubleshooting MPLS L3 VPNsVerifying 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


. . .

BRKMPL-3124 96



• Customer reported traffic forwarding issue to the VRF’s attached to a newly configured PE2 router

• The PE1 router has the VPN label which is being shared with the remote PE2 router

• On PE1, the CEF shows the correct forwarding output.

Case Study – MPLS Traffic Not Forwarded

PE1

Lo0=1.1.1.1/32

PE2

Lo0=2.2.2.2/32

CE1

Lo0=172.16.1.1/32

CE2

Lo0=172.16.2.2/32

P1

Lo0=4.4.4.4/32

MP-IBGP – VPNv4

10.1.14.0/24 10.1.24.0/24 172.16.22.0/24172.16.11.0/24

LDP + IGP

BRKMPL-3124 97



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

Troubleshooting Approach

BRKMPL-3124 98



• The MPLS PING failed

• MPLS Trace dropped on P-1 router

• Show mpls forwarding <PE2-loopback> output shows no label as outgoing label

• Verified that LDP was enabled between the two routers but there was no bindings

Findings

P-1# show mpls forwarding 3.3.3.3



17 No Label 3.3.3.3/32 476193 Et0/0 23.23.23.2

BRKMPL-3124 99



• 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

Resolution

P-1(config)#no mpls ldp advertise-labels

P-1(config)#mpls ldp advertise-labels for LOOPBACK_ACL

BRKMPL-3124 100

6VPE Troubleshooting


Troubleshooting 6VPEReference Topology

PE1

PE2

CE1 RR-P PE5 CE2

IPv4 – 192.168.1.1/32

IPv6 – 2001:DB8::1/128

IPv4 – 192.168.2.2/32

IPv6 – 2001:DB8::2/128IPv4 – 192.168.5.5/32

IPv6 – 2001:DB8::5/128IPv6 – 2001:DB8::7/128IPv6 – 2001:DB8::6/128

AS 100

AS 200 AS 300IPv4 – 192.168.4.4/32

Service Provider Core

IPv4 – IGP

MPLS

BRKMPL-3124 102


Troubleshooting 6VPE

• IPv6 enabled VRF’s are configured in the same way as IPv4 VRF’s

• On Cisco IOS, use command vrf definition to configure both IPv4 and IPv6 capable VRF’s

VRF Configuration

vrf definition ABC

rd 1:1

address-family ipv6 unicast


route-target export 1:1



. . .

interface Gi0/0

vrf forwarding ABC

ipv6 address xx:xx:xx::y/64

vrf ABC


import route-target

1:1

2:2

export route-target

1:1


. . .

interface Gi0/0/0/0

vrf ABC

ipv6 address xx:xx:xx::y/64

BRKMPL-3124 103


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 remote-as 100

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

BRKMPL-3124 104


6VPE Configuration – IOS XRrouter 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


!

neighbor 2001:db8:0:26::6

remote-as 200


route-policy pass in

route-policy pass out

BRKMPL-3124 105



• Since both control plane and data plane works in opposite direction, verify the IPv6 VPN prefix on PE5.

Verifying Control Plane

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

BRKMPL-3124 106



• 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


mpls labels in/out 23/nolabel


BRKMPL-3124 107



• 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



mpls labels in/out nolabel/23


BRKMPL-3124 108


Troubleshooting 6VPEVerifying Control Plane

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

BRKMPL-3124 109


Troubleshooting 6VPEVerifying 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

BRKMPL-3124 110


Troubleshooting 6VPEVerifying 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

BRKMPL-3124 111


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

BRKMPL-3124 112


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

BRKMPL-3124 113


Troubleshooting 6VPE / MPLS

• 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

Verifying Counters on Interface

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

BRKMPL-3124 114

Inter-AS MPLS VPNs


Inter-AS MPLS VPNs

• 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 approachA. Next-Hop-Self Method

B. Redistribute Connected Method

C. Multi-hop EBGP between ASBRs

• Option 3 – MP-EBGP between RR and EBGP between ASBR

Flavors

BRKMPL-3124 116


Inter-AS MPLS VPNsOption 1 - Back-to-Back VRF Method

AS100 AS200

PE-ASBR1

Lo0-11.11.11.11/32

PE-ASBR2

Lo0-22.22.22.22/32

RR-P1 RR-P2

PE1 PE2

CE1 CE2

VRF- ABC VRF- XYZ

IPv4 + IGP/BGP

BRKMPL-3124 117


Inter-AS MPLS VPNsOption 2a – ASBR-to-ASBR with Next-Hop-Self Method

AS100 AS200

PE-ASBR1

Lo0-11.11.11.11/32

PE-ASBR2

Lo0-22.22.22.22/32

RR-P1 RR-P2

PE1 PE2

CE1 CE2

MP-eBGP

v1172.16.1.1

172.16.1.1 172.16.2.2

neighbor x.x.x.x next-hop-self

• No LDP or IGP required on the link between the two ASBRs.

• Configure no bgp default route-target filter on ASBRs

BRKMPL-3124 118


Inter-AS MPLS VPNs

• 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

Option 2a – ASBR-to-ASBR with Next-Hop-Self Method

BRKMPL-3124 119


Inter-AS MPLS VPNsOption 2b – ASBR-to-ASBR with Redistribute Connected Method

AS100 AS200

PE-ASBR1

Lo0-11.11.11.11/32

PE-ASBR2

Lo0-22.22.22.22/32

RR-P1 RR-P2

PE1 PE2

CE1 CE2• No LDP or IGP required on the link between the two ASBRs.


MP-eBGP

v1172.16.1.1

172.16.1.1 172.16.2.2

BRKMPL-3124 120


Inter-AS MPLS VPNs

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

Option 2b – ASBR-to-ASBR with Redistribute Connected Method

BRKMPL-3124 121


Inter-AS MPLS VPNsOption 2c – ASBR-to-ASBR with Multi-Hop EBGP between ASBRs Method

AS100 AS200

PE-ASBR1

Lo0-11.11.11.11/32

PE-ASBR2

Lo0-22.22.22.22/32

RR-P1 RR-P2

PE1 PE2

CE1 CE2• Loopback to loopback peering between ASBRs


MP-eBGP

v1172.16.1.1

172.16.1.1 172.16.2.2

BRKMPL-3124 122


Inter-AS MPLS VPNs

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

Option 2c – ASBR-to-ASBR with Multi-Hop EBGP between ASBRs Method

BRKMPL-3124 123


Inter-AS MPLS VPNsOption 3 – Multi-Hop MP-EBGP between RR and EBGP between ASBRs

AS100 AS200

PE-ASBR1

Lo0-11.11.11.11/32

PE-ASBR2

Lo0-22.22.22.22/32

RR-P1 RR-P2

PE1 PE2

CE1 CE2• Neighbor send-label required on eBGP peers on ASBR.

MP-eBGP

172.16.1.1 172.16.2.2

eBGP +

Send-label

BRKMPL-3124 124


Inter-AS MPLS VPNs

• RR & ASBR loopbacks are advertised via EBGP on ASBR

• The remote ASBR redistributes the received loopbacks into local IGP

• MP-EBGP peering configured between RR’s on each AS

• Configure neighbor next-hop-unchanged

Option 3 – Multi-Hop MP-EBGP between RR and EBGP between ASBRs

BRKMPL-3124 125


Complete Your Online Session Evaluation

Don’t forget: Cisco Live sessions will be available for viewing on-demand after the event at CiscoLive.com/Online

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

BRKMPL-3124 126

CiscoLive.com/Online

http://ciscolive.com/Online

http://ciscolive.com/Online

http://ciscolive.com/us

http://ciscolive.com/us


Continue Your Education

• Demos in the Cisco campus

• Walk-in Self-Paced Labs

• Table Topics

• Meet the Engineer 1:1 meetings

• Related sessions

BRKMPL-3124 127

Thank you

Troubleshooting End-to-End MPLSd2zmdbbm9feqrf.cloudfront.net/2016/usa/pdf/BRKMPL-3124.pdf ·...

Documents

Transcript of Troubleshooting End-to-End MPLSd2zmdbbm9feqrf.cloudfront.net/2016/usa/pdf/BRKMPL-3124.pdf ·...