Troubleshooting MPLS HP

MPLS Troubleshooting Guide
Abstract
The main purpose of this guide is to illustrate various issues encountered while troubleshooting MPLS on HP routers. This
troubleshooting guide discusses ways of analyzing a problem and the corrective measures to resolve the issue. This
guide assumes that readers are familiar with the OSI layer and IP routing protocols.
Part number: 5998-4232

© Copyright 2012 Hewlett-Packard Development Company, L.P.
No part of this documentation may be reproduced or transmitted in any form or by any means without
prior written consent of Hewlett-Packard Development Company, L.P.
The information contained herein is subject to change without notice.
HEWLETT-PACKARD COMPANY MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS
MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS FOR A PARTICULAR PURPOSE. Hewlett-Packard shall not be liable for errors contained
herein or for incidental or consequential damages in connection with the furnishing, performance, or use
of this material.
The only warranties for HP products and services are set forth in the express warranty statements
accompanying such products and services. Nothing herein should be construed as constituting an
additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein.
ii
Contents
1 MPLS overview ······················································································································································ 1

2 MPLS and unicast IP routing ································································································································· 2
MPLS LDP peer relationship not established··················································································································· 2
Steps to troubleshoot “MPLS LDP peer not established”······················································································· 2
Problem 1: MPLS not enabled on router ················································································································ 2
Problem 2: LDP not enabled on Router ·················································································································· 4
Problem 3: MPLS not enabled on interface ··········································································································· 7
Problem 4: LDP not enabled on interface ·············································································································· 8
Problem 5: Duplicate MPLS LSR-id ······················································································································· 11
MPLS LDP session not established ································································································································ 13
Steps to troubleshoot “MPLS LDP Peer Session Not Established” ····································································· 13
Problem 1: LSR-ID of the peer is not reachable ·································································································· 13
Problem 2: No route available to reach LDP LSR-id ························································································· 16
Problem 3: LDP authentication enabled on one router and disabled on another ·········································· 20
Broken LSP ······································································································································································ 21
Problem 3: Router not advertising specific FEC in MPLS domain ···································································· 21
Problem 4: Specific FEC being blocked or filtered···························································································· 24
3 MPLS VPN ··························································································································································· 30
Steps to configure MPLS VPN ······································································································································· 30
PE-CE peer relationship establishment ························································································································· 31
Problem1: EBGP Peering: The Peer command incorrectly configured under global BGP····························· 31
Problem 2: OSPF Peering: OSPF process not associated with vpn-instance ·················································· 33
Problem 3: VPN-instance not bounded to interface··························································································· 35
The customer site is not receiving vpn-routes ·············································································································· 36
Problem 1: Customer routes not imported into BGP (PE-CE routing by BGP) ················································· 37
Problem 2: BGP vpnv4 routes not redistributed into customer vrf ···································································· 39
Problem 3: IBGP peers not activated to carry vpn-routes·················································································· 43
Problem 4: Mismatch in the vpn-target configuration························································································ 46
4 MPLS TE ······························································································································································· 51
MPLS TE Tunnel is not getting established ··················································································································· 51
Problem 1: MPLS TE not enabled globally ········································································································· 52
Problem 2: MPLS TE not enabled on interface ··································································································· 54
Problem 3: RSVP-TE not enabled globally ········································································································· 55
Problem 4: RSVP-te not enabled on the interface ······························································································ 58
Problem 5: OSPF not configured to carry TE attributes/OSPF not enabled to generate and receive opaque
LSAs ········································································································································································ 59
Problem 6: Changes to the tunnel interface not committed. ············································································· 62
Traffic not routed through TE tunnel ····························································································································· 63
Problem 1: IP address not assigned to the tunnel interface ·············································································· 63
Problem 2: Tunnel interface not configured to participate in OSPF SPF calculation ····································· 66
Problem 3: OSPF not configured to include the static LSP tunnel in SPF calculation ····································· 69
MPLS TE Traffic not tunneled through the desired path······························································································ 72
Problem 1: Explicit path has lower preference ·································································································· 72
Problem 2: Intermediate router or link down······································································································ 74
Problem 3: Intermediate router not participating in MPLS TE ··········································································· 78
iii
iv
1 MPLS overview
Multiprotocol label switching (MPLS) is a technology that combines the layer 2 switching mechanism
with layer 3 Routing to forward IP packets. In brief, using MPLS, IP packets can be switched to the
destination network rather than being routed.
MPLS works on labels. The IP packet entering an MPLS enabled router is labeled and forwarded to the
next hop. Based on the entry in the LFIB table, this router either swaps the label or pops the label before
forwarding it to the next hop router.
MPLS can be used to forward data as well as voice traffic. Almost all the layer 3 and layer 2 protocols
are compatible with MPLS.
MPLS Troubleshooting Guide is divided into three sections as listed below:
• Unicast IP routing
• MPLS VPN
• MPLS TE
1
2 MPLS and unicast IP routing
MPLS has become popular not only with ISPs, but also with Corporations. Currently corporate networks
are being configured with MPLS due to its capability to carry voice and data traffic in a single network.
The need for two separate networks, one for voice and other for data, changed after the introduction of
MPLS.
This chapter covers many scenarios pertaining to corporate networks as well as ISP networks. To help
reader understanding, the topology used for troubleshooting has been kept small.
This section could again be divided into different categories as listed below:
• MPLS LDP peer relationship not established
• MPLS LDP session not established
• MPLS LSP broken
MPLS LDP peer relationship not established

The LDP (Label distribution protocol) peer relationship could not be established due to various reasons,
some of which are listed below:
• MPLS not enabled globally
• LDP not enabled globally
• MPLS not enabled on interface
• LDP not enabled on interface
• Duplicate LSR-id
Steps to troubleshoot “MPLS LDP peer not established”

1. Check whether MPLS is enabled globally.
2. Check whether LDP protocol is enabled globally.
3. Check whether MPLS is enabled on the interface.
4. Check whether LDP is enabled on the interface.
5. Check whether LSR-ID is distinct on both routers.
Problem 1: MPLS not enabled on router

An example of MPLS not enabled on the router is shown in Figure 1.
2
Figure 1 MPLS not enabled on router
R7
6.2
/24
68.6.0
192.1
R1 6.1 R4
192.168.1.0/24 192.168.2.0/24 192.168.3.0/24
1.1 1.2 3.2
2.1 2.2 3.1
19
4
2.1
0/2
5.1 4.1
68
R2 R3
.5.
.4.
68
0/2
2.1
4
19
5.2 4.2
R6
R5
Problem
LDP peer relationship is not established between R2 and R1
<R1>disp mpls ldp peer
LDP Peer Information in Public network
Total number of peers: 1
-----------------------------------------------------------------------------
Peer-ID Transport-Address Discovery-Source
-----------------------------------------------------------------------------
5.5.5.5:0 5.5.5.5 GigabitEthernet0/0/1
-----------------------------------------------------------------------------
R1 is not showing R2 as its LDP neighbor.
Troubleshooting
1. Check whether MPLS is enabled on interfaces of R1 and R2.
Use the command display mpls interface
Router R1:
[R1]disp mpls interface
Interface Status TE Attr LSP Count CRLSP Count
GE0/0/0 Up Dis 0 0
GE0/0/1 Up Dis 1 0
MPLS is enabled for Gi 0/0/0 interface of R1 connecting R2.

Router R2:
<R2>disp mpls interface
<R2>
The display mpls interface command on R2 gives an empty output, which means that MPLS is
not enabled on this interface.
3
2. Check the MPLS configuration on Router R2.
<R2>disp current-configuration | begin mpls
mpls lsr-id 2.2.2.2
#
From the above output it is clear that only MPLS LSR-id has been configured on R2. MPLS has
not been enabled globally.
Solution
Enable MPLS on Router R2.
[R2]mpls
Info: MPLS starting, please wait...OK.
[R2-mpls]mpls ldp
[R2-mpls-ldp]quit
[R2]int gi 0/0/0
[R2-GigabitEthernet0/0/0]mpls
[R2-GigabitEthernet0/0/0]mpls ldp
[R2-GigabitEthernet0/0/0]int gi 0/0/1
Verification
Check the MPLS LDP peer table on R1.
[R1]disp mpls ldp peer

-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
R1 has established LDP peer relationship with R2 successfully.
Problem 2: LDP not enabled on Router

An example of LDP not enabled on the router is shown in Figure 2.
4
Figure 2 LDP not enabled on router
R7
6.2
/24
68.6.0
192.1
R1 6.1 R4
192.168.1.0/24 192.168.2.0/24 192.168.3.0/24
1.1 1.2 3.2
2.1 2.2 3.1
19
4
2.1
0/2
5.1 4.1
68
R2 R3
.5.
.4.
68
0/2
2.1
4
19
5.2 4.2
R6
R5
Problem
LDP peer relationship is not established between R1 and R2
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
Troubleshooting
1. Check whether MPLS is enabled on the interfaces using the display mpls interface command.
Router R1:
GE0/0/0 Up Dis 0 0
GE0/0/1 Up Dis 1 0
Router R2:
GE0/0/0 Up Dis 0 0
GE0/0/1 Up Dis 0 0
MPLS has been enabled on the interfaces of both R1 and R2.

2. Check whether LDP is enabled on the interfaces using the display mpls ldp interface command.
5
Router R1:
[R1]disp mpls ldp interface
LDP Interface Information in Public Network

-----------------------------------------------------------------------------
IF-Name Status LAM Transport-Address Hello-Sent/Rcv
-----------------------------------------------------------------------------
GE0/0/0 Active DU 1.1.1.1 1542/1498
GE0/0/1 Active DU 1.1.1.1 1685/1632
-----------------------------------------------------------------------------
LAM: Label Advertisement Mode IF-Name: Interface name
Router R2:
[R2]
The display mpls ldp interface command shows an empty output, which means that LDP has not
been enabled on the interfaces.
3. Check the MPLS configuration to verify the MPLS configuration on R2.
Router R2:
[R2]disp current-configuration | begin mpls
mpls lsr-id 2.2.2.2
#
vlan 1
#
mpls
#
The above output shows that LDP is not enabled on R2. As a result, LDP peer relation is not
being established between R1 and R2.
Solution
Enable LDP on R2.
[R2]mpls
[R2-mpls]mpls ldp
[R2-mpls-ldp]quit
[R2]int gi 0/0/0
Verification
Check the MPLS LDP peer relationship between R1 and R2.

-----------------------------------------------------------------------------
6
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
R1 has formed LDP peer relation with R2.
Problem 3: MPLS not enabled on interface

An example of MPLS not enabled on interface is shown in Figure 3.
Figure 3 MPLS not enabled on interface
R7
6.2
/24
68.6.0
192.1
R1 6.1 R4
192.168.1.0/24 192.168.2.0/24 192.168.3.0/24
1.1 1.2 3.2
2.1 2.2 3.1
19
24
2.1
.0/
5.1 4.1
68
R2 R3
8.5
.4.
0/2
6
2.1
4
19
5.2 4.2
R6
R5
Problem
LDP peer relationship not established between R1 and R5

-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
R1 has not established LDP peer relationship with R5
Troubleshooting
1. Check whether LDP is enabled on the interface using the command display mpls ldp interface
Router R5:
<R5>disp mpls ldp interface
7
------------------------------------------------------------------------------
------------------------------------------------------------------------------
GE0/0/0 Active DU 5.5.5.5 2116/1841
------------------------------------------------------------------------------
Router R1:

-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
GE0/0/0 Active DU 1.1.1.1 287/48
-----------------------------------------------------------------------------
R1 shows only one interface with LDP enabled.

2. Check the mpls status on interface gi 0/0/1 of R1
<R1>disp mpls interface gi 0/0/1
<R1>
The above output is empty from which it can be deduced that mpls is not enabled on the interface.
Solution
Enable MPLS on int gi 0/0/1 of R1.
[R1]int gi 0/0/1
Verification
Verify whether the LDP peer relation has established between R1 and R5.

-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
R1 has formed successful LDP peer relation with R5.
Problem 4: LDP not enabled on interface

An example of LDP not enabled on the interface is shown in Figure 4.
8
Figure 4 LDP not enabled on interface
R7
6.2
/24
68.6.0
192.1
R1 6.1 R4
192.168.1.0/24 192.168.2.0/24 192.168.3.0/24
1.1 1.2 3.2
2.1 2.2 3.1
19
4
2.1
0/2
5.1 4.1
68
R2 R3
.5.
.4.
68
0/2
2.1
4
19
5.2 4.2
R6
R5
Problem

-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
R1 has not formed LDP peer relation with R5.
Troubleshooting
1. Check whether LDP is enabled on interfaces using the command display mpls ldp interface.
Router R1:

------------------------------------------------------------------------------
------------------------------------------------------------------------------
GE0/0/0 Active DU 1.1.1.1 35/34
GE0/0/1 Active DU 1.1.1.1 32/0
------------------------------------------------------------------------------
Router R5:
9
<R5>
Router R5 gives an empty output, which means that R5 does not have any LDP enabled interface.
2. Check the mpls status on the interface.
<R5>disp mpls interface
GE0/0/0 Up Dis 0 0
MPLS is enabled for the interface Gi 0/0/0 on R5. Since LDP has not been enabled on this interface,
LDP peer relation is not coming up between R1 and R5.
Solution
Enable ldp on the interface of R5.
[R5]int gi 0/0/0
Verification
Verify the LDP peer table.

------------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------------
10
Problem 5: Duplicate MPLS LSR-id
An example of duplicate MPLS LSR-id is shown in Figure 5.
Figure 5 Duplicate MPLS LSR-id
R7
6.2
/24
68.6.0
192.1
R1 6.1 R4
192.168.1.0/24 192.168.2.0/24 192.168.3.0/24
1.1 1.2 3.2
2.1 2.2 3.1
19
24
2.1
.0/
5.1 4.1
68
R2 R3
8.5
.4
.0/
6
2.1
24
19
5.2 4.2
R6
R5
Problem

------------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------------
R1 has formed LDP peer with R5 and not R2.
Troubleshooting
1. Check the LDP status on the interface using the command display mpls ldp interface.
Router R1:

------------------------------------------------------------------------------
------------------------------------------------------------------------------
GE0/0/0 Active DU 1.1.1.1 320/0
GE0/0/1 Active DU 1.1.1.1 280/279
11
------------------------------------------------------------------------------
Router R2:

------------------------------------------------------------------------------
------------------------------------------------------------------------------
GE0/0/0 Active DU 1.1.1.1 329/0
GE0/0/1 Active DU 1.1.1.1 341/593
------------------------------------------------------------------------------
As shown in the above output, the transport address of R2 is 1.1.1.1, which is wrongly configured.
2. To verify this check the mpls configuration on R2.
mpls lsr-id 1.1.1.1
#
vlan 1
#
mpls
#
mpls ldp
#
The MPLS LSR-ID configured on R2 is incorrect. It duplicates with the LSR-id configured on R1.
Solution
Configure the correct lsr-id.
[R2]undo mpls
Warning: This command will disable MPLS globally. Continue? [Y/N]:y
[R2]mpls lsr-id 2.2.2.2
[R2]mpls
Info: MPLS starting, please wait...OK.
[R2-mpls]mpls ldp
[R2-mpls-ldp]quit
[R2]int gi 0/0/0
Verification
Check the mpls ldp peer status.
12
------------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------------
MPLS LDP session not established

All the LDP enabled routers form an LDP neighbor relationship before proceeding with the label
exchange. A TCP session must establish between the LDP enabled routers. If the Session establishment
fails, then the MPLS LSP is not formed.
The common reasons found in the network that hamper the LDP peer session establishments are listed
below:
• MPLS LSR-id of the peer is not reachable.
• No route available to reach LDP LSR-id.
• LDP authentication enabled on one router and disabled on another.
Steps to troubleshoot “MPLS LDP Peer Session Not Established”

1. Check whether LSR-id of the peer is reachable.
2. Check whether the transport address configured on the interface and LSR-id are same. If not, then
ensure the transport address is reachable to the peer.
3. Check whether LDP MD5 flag is enabled/disabled on the peer.
Problem 1: LSR-ID of the peer is not reachable

An example of LSR-id of the peer not reachable is shown in Figure 6.
13
Figure 6 LSR-id of the peer is not reachable
R7
6.2
/24
68.6.0
192.1
R1 6.1 R4
192.168.1.0/24 192.168.2.0/24 192.168.3.0/24
1.1 1.2 3.2
2.1 2.2 3.1
19
4
2.1
0/2
5.1 4.1
68
R2 R3
.5.
.4.
68
0/2
2.1
4
19
5.2 4.2
R6
R5
Problem
LDP session not established between Routers R1 and R5
[R1]disp mpls ldp session
LDP Session(s) in Public Network

Total number of sessions: 2
------------------------------------------------------------------------------
Peer-ID Status LAM SsnRole FT MD5 KA-Sent/Rcv
------------------------------------------------------------------------------
2.2.2.2:0 Operational DU Passive Off Off 5/5
5.5.5.5:0 Non Existent --- Passive Off Off 0/0
------------------------------------------------------------------------------
LAM : Label Advertisement Mode FT : Fault Tolerance
As shown in the above output, no keepalives has been sent or received. Also, the peer-id status is
non-existent.
Troubleshooting
1. Check the LDP transport address for R5 using the command display mpls ldp peer on R1.

------------------------------------------------------------------------------
------------------------------------------------------------------------------
14
------------------------------------------------------------------------------
The transport address is same as the LSR-id.

Check whether the LSR-id of R5 is reachable. Use the command ping.
[R1]ping 5.5.5.5
PING 5.5.5.5: 56 data bytes, press CTRL_C to break
Request time out
Request time out
Request time out
Request time out
Request time out
--- 5.5.5.5 ping statistics ---

5 packet(s) transmitted
0 packet(s) received
100.00% packet loss
Ping reply is a 100% loss, which means that the reachability to this IP is broken.
2. Check the IP routing table on R1 to verify whether R1 is receiving any route for 5.5.5.5/32
network.
<R1>disp ip routing-table
Routing Tables: Public
Destinations : 12 Routes : 12
Destination/Mask Proto Pre Cost NextHop Interface
1.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0

2.2.2.2/32 OSPF 10 1 192.168.1.2 GE0/0/0
3.3.3.3/32 OSPF 10 2 192.168.1.2 GE0/0/0
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
192.168.1.0/24 Direct 0 0 192.168.1.1 GE0/0/0
192.168.1.1/32 Direct 0 0 127.0.0.1 InLoop0
192.168.2.0/24 OSPF 10 2 192.168.1.2 GE0/0/0
192.168.3.0/24 OSPF 10 3 192.168.1.2 GE0/0/0
192.168.4.0/24 OSPF 10 4 192.168.1.2 GE0/0/0
192.168.5.0/24 Direct 0 0 192.168.5.1 GE0/0/1
192.168.5.1/32 Direct 0 0 127.0.0.1 InLoop0
The IP routing table does not show any entry for 5.5.5.5/32 network. Since there is no route available
for this subnet, the LDP session is showing to be non-existent on R1.
3. Check the OSPF configuration on R5.
[R5]disp current-configuration | begin ospf
ospf 1
area 0.0.0.1
network 192.168.5.0 0.0.0.255
As you can see, Router R5 is not configured to advertise 5.5.5.5/32 network.
15
Solution
Advertise the loopback configured as LSR-id using OSPF.
[R5]ospf 1
[R5-ospf-1]area 1
[R5-ospf-1-area-0.0.0.1]network 5.5.5.5 0.0.0.0
Verification
Check whether LDP session has established between R1 and R5.

------------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------------
Problem 2: No route available to reach LDP LSR-id

MPLS LSR-id participates in the TCP session establishment. LDP assumes the value of globally configured
LSR-id. Hence a separate LDP LSR-id need not be configured. The need for the configuration of LDP LSR-id
arises in MPLS L3VPN configurations. LDP LSr-id has predominance over the MPLS LSR-id. Hence it is
necessary to advertise the loopback ip configured as the LDP LSR-id. If LDP LSR-id is unreachable then
TCP session will not get established between the peers. An example of no route available to reach the
LDP LSR-id is shown in Figure 7.
16
Figure 7 No route available to reach LDP LSR-id
R7
6.2
/24
68.6.0
192.1
R1 6.1 R4
192.168.1.0/24 192.168.2.0/24 192.168.3.0/24
1.1 1.2 3.2
2.1 2.2 3.1
19
4
2.1
0/2
5.1 4.1
68
R2 R3
.5.
.4.
68
0 /2
2.1
4
19
5.2 4.2
R6
R5
Problem
LDP session not established between R1 and R2

------------------------------------------------------------------------------
------------------------------------------------------------------------------
2.2.2.2:0 Initialized --- Active Off Off 0/0
------------------------------------------------------------------------------
The LDP session is shown to be Initialized for peer R2.
Troubleshooting
1. Check the mpls ldp session on R2.

------------------------------------------------------------------------------
------------------------------------------------------------------------------
3.3.3.3:0 Operational DU Passive Off On 7/7
------------------------------------------------------------------------------
17
2. Check the IP routing table of R2.
1.1.1.1/32 OSPF 10 1 192.168.1.1 GE0/0/0

2.2.2.2/32 Direct 0 0 127.0.0.1 InLoop0
3.3.3.3/32 OSPF 10 1 192.168.2.2 GE0/0/1
4.4.4.4/32 OSPF 10 2 192.168.2.2 GE0/0/1
5.5.5.5/32 OSPF 10 2 192.168.1.1 GE0/0/0
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
192.168.1.0/24 Direct 0 0 192.168.1.2 GE0/0/0
192.168.1.2/32 Direct 0 0 127.0.0.1 InLoop0
192.168.2.0/24 Direct 0 0 192.168.2.1 GE0/0/1
192.168.2.1/32 Direct 0 0 127.0.0.1 InLoop0
192.168.3.0/24 OSPF 10 2 192.168.2.2 GE0/0/1
192.168.4.0/24 OSPF 10 3 192.168.2.2 GE0/0/1
192.168.5.0/24 OSPF 10 2 192.168.1.1 GE0/0/0
R2 is receiving the route-entry for 1.1.1.1/32 network. Still the peer session is showing to be
non-existent.
3. Check the transport address for peer 1.1.1.1

------------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------------
The transport address for peer is 10.10.10.10

To verify, check the LDP interface status
<R1>disp mpls ldp interface gi 0/0/0
LDP Interface Information

------------------------------------------------------------------------------
Interface Name : GigabitEthernet0/0/0
LDP ID : 1.1.1.1:0 Transport Address : 10.10.10.10
Entity Status : Active Interface MTU : 1500
18
Configured Hello Timer : 15 Sec
Negotiated Hello Timer : 15 Sec
Configured Keepalive Timer : 45 Sec
Label Advertisement Mode : Downstream Unsolicited
Hello Message Sent/Rcvd : 1600/1647 (Message Count)
------------------------------------------------------------------------------
R2 is not establishing the peer session with R1 because it does not have the route entry for the transport
address 10.10.10.10 in its routing table.
Two possible solutions for such a problem are:
• Remove the transport address configured under the interface for peer R2.
• Advertise the transport address using OSPF.
Solution 1
Remove the transport address configured under the interface using the command undo mpls ldp
transport-address.
[R1]int gi 0/0/0
[R1-GigabitEthernet0/0/0]undo mpls ldp transport-address
Verification
Check the status of LDP session.

------------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------------
Solution 2
Advertise the transport address using OSPF.
[R1]ospf 1
[R1-ospf-1]area 0
Verification
Check the status of LDP session.
<R1>disp mpls ldp session

------------------------------------------------------------------------------
------------------------------------------------------------------------------
2.2.2.2:0 Operational DU Active Off Off 4/4
19
------------------------------------------------------------------------------
Problem 3: LDP authentication enabled on one router and

disabled on another
An example of LDP authentication enabled on one router and disabled on another is shown in Figure 8.
Figure 8 LDP authentication enabled on one router and disabled on another
R7
6.2
/24
68.6.0
192.1
R1 6.1 R4
192.168.1.0/24 192.168.2.0/24 192.168.3.0/24
1.1 1.2 3.2
2.1 2.2 3.1
19
24
2.1
.0/
5.1 4.1
68
R2 R3
8.5
.4.
0/2
6
2.1
4
19
5.2 4.2
R6
R5
Problem
LDP session between Routers R1 and R2 is broken.

------------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------------
Troubleshooting
Check the LDP session status on R2.

------------------------------------------------------------------------------
20
------------------------------------------------------------------------------
1.1.1.1:0 Initialized --- Active Off On 0/0
------------------------------------------------------------------------------
On R1 the MD5 flag is off, whereas on R2 the MD5 flag is ON. Due to this reason MPLS LDP session is
not establishing between R1 and R2.
Solution
Enable MD5 authentication for LDP peer on R1.
[R1]mpls
[R1-mpls]mpls ldp
[R1-mpls-ldp]md5-password cipher 2.2.2.2 abcd
Verification
Verify the LDP session establishment between R1 and R2.

------------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------------
Broken LSP
An LSP is broken when the packets cannot reach the FEC due to some routing issues or FECs are not
advertised by the routers. Broken LSPs may occur due to the following reasons:
1. LDP peer relation not established between routers.
2. MPLS LDP session not established between peers.
3. Router not advertising specific FEC.
4. Specific FEC being blocked or filtered.
This section covers problems 3 and 4. Problems 1 and 2 are covered in earlier sections.
Problem 3: Router not advertising specific FEC in MPLS domain

An example of router not advertising specific FEC in MPLS domain is shown in Figure 9.
21
Figure 9 Router not advertising specific FEC in MPLS domain
R7
6.2
/24
68.6.0
192.1
R1 6.1 R4
192.168.1.0/24 192.168.2.0/24 192.168.3.0/24
1.1 1.2 3.2
2.1 2.2 3.1
19
4
2.1
0/2
5.1 4.1
68
R2 R3
.5.
.4.
68
0/2
2.1
4
19
5.2 4.2
R6
R5
Problem
Router R1 does not have the entry for FEC 192.168.4.0/24 in its LFIB.
<R1>disp mpls lsp
-------------------------------------------------------------------------
LSP Information: LDP LSP
-------------------------------------------------------------------------
FEC In/Out Label In/Out IF Vrf Name
5.5.5.5/32 1024/NULL -/GE0/0/1
1.1.1.1/32 3/NULL -/InLoop0
192.168.5.0/24 3/NULL -/GE0/0/1
6.6.6.6/32 NULL/1024 -/GE0/0/0
4.4.4.4/32 NULL/1025 -/GE0/0/0
3.3.3.3/32 NULL/1026 -/GE0/0/0
2.2.2.2/32 NULL/3 -/GE0/0/0
192.168.3.0/24 NULL/1029 -/GE0/0/0
192.168.2.0/24 NULL/3 -/GE0/0/0
Troubleshooting
1. Check the IP routing table of R1 to verify the network 192.168.4.0 is being advertised by IGP.
1.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0

2.2.2.2/32 OSPF 10 1 192.168.1.2 GE0/0/0
22
3.3.3.3/32 OSPF 10 2 192.168.1.2 GE0/0/0
4.4.4.4/32 OSPF 10 3 192.168.1.2 GE0/0/0
5.5.5.5/32 OSPF 10 1 192.168.5.2 GE0/0/1
6.6.6.6/32 OSPF 10 4 192.168.1.2 GE0/0/0
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
192.168.1.0/24 Direct 0 0 192.168.1.1 GE0/0/0
192.168.1.1/32 Direct 0 0 127.0.0.1 InLoop0
192.168.2.0/24 OSPF 10 2 192.168.1.2 GE0/0/0
192.168.3.0/24 OSPF 10 3 192.168.1.2 GE0/0/0
192.168.4.0/24 OSPF 10 4 192.168.1.2 GE0/0/0
192.168.5.0/24 Direct 0 0 192.168.5.1 GE0/0/1
192.168.5.1/32 Direct 0 0 127.0.0.1 InLoop0
R1 is receiving the route entry for 192.168.4.0/24 network but cannot find an entry in the LFIB table.
2. Check whether Router R4 is having the entry for 192.168.4.0/24 network in its LFIB table.
<R4>disp mpls lsp
-------------------------------------------------------------------------
-------------------------------------------------------------------------
4.4.4.4/32 3/NULL -/InLoop0
5.5.5.5/32 NULL/1024 -/GE0/0/0
2.2.2.2/32 NULL/1025 -/GE0/0/0
1.1.1.1/32 NULL/1026 -/GE0/0/0
3.3.3.3/32 NULL/3 -/GE0/0/0
1.1.1.1/32 1025/1026 -/GE0/0/0
2.2.2.2/32 1026/1025 -/GE0/0/0
3.3.3.3/32 1027/3 -/GE0/0/0
5.5.5.5/32 1028/1024 -/GE0/0/0
6.6.6.6/32 1024/3 -/GE0/0/1
6.6.6.6/32 NULL/3 -/GE0/0/1
192.168.2.0/24 1030/3 -/GE0/0/0
192.168.5.0/24 1031/1027 -/GE0/0/0
192.168.1.0/24 1032/1031 -/GE0/0/0
Even Router R4 does not have the entry for 192.168.4.0 network in its LFIB table.
3. Check whether the command lsp-trigger all is configured under MPLS view.
mpls lsr-id 4.4.4.4
#
vlan 1
#
mpls
#
mpls ldp
23
lsp-trigger all command missing in the configuration of R4.
Solution
Configure the command lsp-trigger all under MPLS view.
[R4]mpls
[R4-mpls]lsp-trigger all
Verification
Check the LFIB table of R1
<R1>disp mpls lsp
-------------------------------------------------------------------------
-------------------------------------------------------------------------
5.5.5.5/32 1024/NULL -/GE0/0/1
1.1.1.1/32 3/NULL -/InLoop0
192.168.5.0/24 3/NULL -/GE0/0/1
6.6.6.6/32 NULL/1024 -/GE0/0/0
4.4.4.4/32 NULL/1025 -/GE0/0/0
3.3.3.3/32 NULL/1026 -/GE0/0/0
2.2.2.2/32 NULL/3 -/GE0/0/0
192.168.3.0/24 NULL/1029 -/GE0/0/0
192.168.2.0/24 NULL/3 -/GE0/0/0
192.168.4.0/24 NULL/1031 -/GE0/0/0
R1 is now receiving the entry for FEC 192.168.4.0/24 in its LFIB table.
Also, check the ping reply to this FEC.
<R1>ping lsp -a 1.1.1.1 ipv4 192.168.4.0 24

LSP Ping FEC: LDP IPV4 PREFIX 192.168.4.0/24 : 100 data bytes, press CTRL_C to
break
Reply from 192.168.3.2: bytes=100 Sequence=1 time = 24 ms
Request time out
--- FEC: LDP IPV4 PREFIX 192.168.4.0/24 ping statistics ---

0.00% packet loss
round-trip min/avg/max = 1/5/24 ms
Problem 4: Specific FEC being blocked or filtered

An example of specific FEC being blocked or filtered is shown in Figure 10.
24
Figure 10 Specific FEC being blocked or filtered
R7
7.2
/24
68.7.0
192.1
R1 7.1 R4
192.168.1.0/24 192.168.2.0/24 192.168.3.0/24
1.1 1.2 3.2
2.1 2.2 3.1
19
2.1
/24 5.1 4.1
68
. 5.0 R2 R3
168
.4.
.
192
0
R5
/24
AREA 0
5.2 4.2
AREA 2
6.1
4
0/2
R6
.6.
68
200.1.1.1/32 AREA 1
2.1
200.1.1.2/32
6.2
19
:
:
:
200.1.1.7/32
R8
In the above scenario, MPLS is enabled on all the routers belonging to area 0, area 1, and area 2.
Router R8 is advertising the routes to 200.1.1.1/32, 200.1.1.2/32…. 200.1.1.7/32 network.
Problem
Router R4 does not have the entry for the FEC 200.1.1.1/32 to 200.1.1.7/32 networks in its LFIB table.
[R4]disp mpls lsp
-------------------------------------------------------------------------
-------------------------------------------------------------------------
1.1.1.1/32 NULL/1025 -/GE0/0/0
2.2.2.2/32 NULL/1026 -/GE0/0/0
3.3.3.3/32 NULL/3 -/GE0/0/0
4.4.4.4/32 3/NULL -/InLoop0
192.168.4.0/24 3/NULL -/GE0/0/1
192.168.1.0/24 NULL/1029 -/GE0/0/0
192.168.2.0/24 NULL/3 -/GE0/0/0
192.168.5.0/24 NULL/1028 -/GE0/0/0
Troubleshooting
1. Check the LFIB table of R8.
[R8]disp mpls lsp
-------------------------------------------------------------------------
-------------------------------------------------------------------------
1.1.1.1/32 NULL/1025 -/GE0/0/0
2.2.2.2/32 NULL/1026 -/GE0/0/0
3.3.3.3/32 NULL/1027 -/GE0/0/0
4.4.4.4/32 NULL/1028 -/GE0/0/0
5.5.5.5/32 NULL/3 -/GE0/0/0
25
192.168.1.0/24 NULL/1029 -/GE0/0/0
192.168.2.0/24 NULL/1030 -/GE0/0/0
192.168.3.0/24 NULL/1031 -/GE0/0/0
192.168.4.0/24 NULL/1032 -/GE0/0/0
8.8.8.8/32 3/NULL -/InLoop0
200.1.1.1/32 3/NULL -/InLoop0
200.1.1.2/32 3/NULL -/InLoop0
200.1.1.3/32 3/NULL -/InLoop0
200.1.1.4/32 3/NULL -/InLoop0
200.1.1.5/32 3/NULL -/InLoop0
200.1.1.6/32 3/NULL -/InLoop0
200.1.1.7/32 3/NULL -/InLoop0
192.168.5.0/24 NULL/3 -/GE0/0/0
R8 has the entry for 200.1.x.x FECs in its LFIB table.

2. Check the LFIB tables of neighboring routers until you come across the router that no longer
advertises the FEC.
In the above scenario, Router R5 also has entry for 200.1.x.x network in its LFIB table.
Router R1 does not have an entry for 200.1.x.x network in its LFIB table.
<R1>disp mpls lsp
-------------------------------------------------------------------------
-------------------------------------------------------------------------
2.2.2.2/32 NULL/3 -/GE0/0/0
1.1.1.1/32 3/NULL -/InLoop0
3.3.3.3/32 NULL/1024 -/GE0/0/0
4.4.4.4/32 NULL/1026 -/GE0/0/0
2.2.2.2/32 1025/3 -/GE0/0/0
3.3.3.3/32 1026/1024 -/GE0/0/0
4.4.4.4/32 1027/1026 -/GE0/0/0
192.168.5.0/24 3/NULL -/GE0/0/1
192.168.1.0/24 3/NULL -/GE0/0/0
192.168.2.0/24 NULL/3 -/GE0/0/0
192.168.2.0/24 1028/3 -/GE0/0/0
192.168.3.0/24 NULL/1029 -/GE0/0/0
192.168.3.0/24 1029/1029 -/GE0/0/0
192.168.4.0/24 NULL/1030 -/GE0/0/0
192.168.4.0/24 1030/1030 -/GE0/0/0
3. Check the ip routing table of R1.
1.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
26
2.2.2.2/32 OSPF 10 1 192.168.1.2 GE0/0/0
3.3.3.3/32 OSPF 10 2 192.168.1.2 GE0/0/0
4.4.4.4/32 OSPF 10 3 192.168.1.2 GE0/0/0
5.5.5.5/32 OSPF 10 1 192.168.5.2 GE0/0/1
8.8.8.8/32 OSPF 10 2 192.168.5.2 GE0/0/1
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
192.168.1.0/24 Direct 0 0 192.168.1.1 GE0/0/0
192.168.1.1/32 Direct 0 0 127.0.0.1 InLoop0
192.168.2.0/24 OSPF 10 2 192.168.1.2 GE0/0/0
192.168.3.0/24 OSPF 10 3 192.168.1.2 GE0/0/0
192.168.4.0/24 OSPF 10 4 192.168.1.2 GE0/0/0
192.168.5.0/24 Direct 0 0 192.168.5.1 GE0/0/1
192.168.5.1/32 Direct 0 0 127.0.0.1 InLoop0
192.168.6.0/24 OSPF 10 2 192.168.5.2 GE0/0/1
200.1.1.1/32 OSPF 10 2 192.168.5.2 GE0/0/1
200.1.1.2/32 OSPF 10 2 192.168.5.2 GE0/0/1
200.1.1.3/32 OSPF 10 2 192.168.5.2 GE0/0/1
200.1.1.4/32 OSPF 10 2 192.168.5.2 GE0/0/1
200.1.1.5/32 OSPF 10 2 192.168.5.2 GE0/0/1
200.1.1.6/32 OSPF 10 2 192.168.5.2 GE0/0/1
200.1.1.7/32 OSPF 10 2 192.168.5.2 GE0/0/1
R1 is receiving the routes to 200.1.x.x network.

4. Check the MPLS configuration on Router R1 and R5.
Router R1:
mpls lsr-id 1.1.1.1
#
vlan 1
#
mpls
lsp-trigger all
#
mpls ldp
accept-label peer 5.5.5.5 ip-prefix block_R5
Router R5:

mpls lsr-id 5.5.5.5
#
vlan 1
#
mpls
lsp-trigger all
27
#
mpls ldp
#
On Router R1, a filter has been configured, which is blocking the FEC 200.1.x.x network.
5. Check the ip-prefix configured on R1.

<R1>disp ip ip-prefix
Prefix-list block_R5
Permitted 0
Denied 10
index: 5 permit 192.168.5.0/24
index: 50 deny 0.0.0.0/0 le 32
This ip-prefix list allows the acceptance of only FEC 192.168.5.0/24. All other FECs are blocked.
Solution
Allow the FEC 200.1.1.1/32….. 200.1.1.7/32
[R1]ip ip-prefix block_R5 index 6 permit 200.1.1.1 32
Now reset mpls ldp on R1.

<R1>reset mpls ldp
Verification
Check the LFIB table of R4
<R4>disp mpls lsp
-------------------------------------------------------------------------
-------------------------------------------------------------------------
1.1.1.1/32 NULL/1025 -/GE0/0/0
2.2.2.2/32 NULL/1026 -/GE0/0/0
3.3.3.3/32 NULL/3 -/GE0/0/0
4.4.4.4/32 3/NULL -/InLoop0
192.168.4.0/24 3/NULL -/GE0/0/1
192.168.1.0/24 NULL/1029 -/GE0/0/0
192.168.2.0/24 NULL/3 -/GE0/0/0
192.168.5.0/24 NULL/1028 -/GE0/0/0
200.1.1.1/32 NULL/1062 -/GE0/0/0
28
200.1.1.2/32 NULL/1063 -/GE0/0/0
200.1.1.3/32 NULL/1064 -/GE0/0/0
200.1.1.4/32 NULL/1065 -/GE0/0/0
200.1.1.5/32 NULL/1066 -/GE0/0/0
200.1.1.6/32 NULL/1067 -/GE0/0/0
200.1.1.7/32 NULL/1068 -/GE0/0/0
Router R4 is now receiving the LFIB entries.
29
3 MPLS VPN
This section covers the possible problems encountered in an MPLS VPN network. The troubleshooting of
MPLS is the same as in Chapter 1. Apart from the problems faced in MPLS configuration, an engineer
may have issues with the VPN configuration using MP-BGP.
For MPLS Troubleshooting, see MPLS troubleshooting.
The advantage of implementing MPLS VPN is that it gives a BGP-free core network. The ISP runs OSPF
in the core network, which ensure the connectivity among all the core routers including the loopback ips
and transport addresses used for MPLS session establishment. PE routers are configured with BGP to
carry the external routes. The routing protocol used between PE and CE routers may differ from customer
to customer. Some customers may peer with the provider network using EBGP while others may prefer
OSPF or RIP.
Before proceeding further, it is recommended that you go through the steps to configure MPLS VPN. An
MPLS VPN network is shown in Figure 11.
Steps to configure MPLS VPN

Figure 11 MPLS VPN network
R6 R8
MPLS BACKBONE
NON-MPLS CUSTOMER PROVIDER NETWORK NON-MPLS CUSTOMER
NETWORK NETWORK
R1 R2 R3 R5
R4 PE
CE EBGP PEER
OSPF
OSPF
PE EBGP PEERCE
IBGP PEER
AS 100
R7
R9
AS 101 AS 102
1. Enable MPLS globally and on all the interfaces participating in MPLS in the provider network.
2. Enable LDP globally and on interfaces participating in MPLS in the provider network.
3. Configure IGP on the MPLS backbone and ensure connectivity among the routers including the
loopback IPs.
4. Configure the VPN-instance on the PE routers and attach a route distinguisher to the VPN-instance.
5. Assign the vpn-instance to interface connecting PE-CE link.
6. Configure BGP peer relationship between the PE routers and activate the Peer under ipv4-family
vpn4.
30
7. For EBGP peering between PE and CE routers, configure the CE routers as the peers under
ipv4-family vpn-instance. Use the interface IP on which the VPN-instance is binded as the peer-ID.
For OSPF peering between PE and CE router, configure a different OSPF process apart from the
provider ospf process running on PE-routers. Use the network command under the newly created
ospf process for enabling ospf on the vpn interface.
8. Import the customer routes into BGP under the ipv4-family vpn-instance. IF OSPF or RIP is being
used as the PE-CE routing protocol, then import RIP and OSPF routes into BGP vpn-instance to
create vpnv4 routes.
9. To connect two customer sites using VPN, configure vpn-target under the ip vpn-instance on both
the site PEs. The VPN-target must be imported and exported to share the private routes between the
sites.
Most of the problems encountered in MPLS VPN fall in the below categories:
• PE-CE peer relationship establishment (depending on the routing protocol used between them).
• Customer site not receiving the VPN-Routes.
PE-CE peer relationship establishment

Problem1: EBGP Peering: The Peer command incorrectly
configured under global BGP
A peer command incorrectly configured under global BGP is shown in Figure 12.
Figure 12 Peer command incorrectly configured under global BGP
R6 R8
MPLS BACKBONE
NETWORK NETWORK
11.1.1.0/24 192.168.4.0/24 192.168.1.0/24 192.168.3.0/24 10.1.1.0/24

R1 R2 192.168.2.0/24
R3 R5
R4 PE
CE EBGP PEER
OSPF
OSPF
PE EBGP PEERCE
11.1.2.0/24
10.1.2.0/24
IBGP PEER
AS 100
R7
R9
AS 101 AS 102
In the above scenario, E-BGP has been configured between the provider and customer routers. MPLS has
been enabled in the provider network. OSPF is being used as the IGP in the provider network. A VPN
has to be established between the two customer sites situated in different locations. An IBGP peer
relation has been established between the PE routers to carry the BGP routes.
Problem
MPLS VPN has been configured between two customer sites. Although the VPN has been configured, it
is not established between both the customer sites. On further investigation it is found that the PE-CE peer
relation has not established between R1 and R4.
31
<R1>disp bgp vpnv4 vpn-instance vpn1 peer
No Peer Exist
Troubleshooting
Check the BGP peer commands configured for R1 and R4.
Router R1:
<R1>disp current-configuration | begin bgp
bgp 100
undo synchronization
peer 192.168.4.2 as-number 101
peer 3.3.3.3 connect-interface LoopBack0
#
ipv4-family vpnv4
peer 3.3.3.3 enable
Router R4:
bgp 101
import-route direct
import-route ospf 1
As seen in the output of R1, the peer command for R4 has been configured under global BGP config,
whereas the peer command had to be included under ipv4-family vpn-instance.
Solution
Configure R4 as a BGP peer under the ipv4-family vpn-instance.
[R1]bgp 100
[R1-bgp]undo peer 192.168.4.2
[R1-bgp]ipv4-family vpn-instance vpn1
[R1-bgp-ipv4-vpn1]peer 192.168.4.2 as-number 101
[R1-bgp-ipv4-vpn1]import-route direct
Verification
Verify the vpn peer table.
[R1]disp bgp vpnv4 vpn-instance vpn1 peer
BGP local router ID : 1.1.1.1

Local AS number : 100
Total number of peers : 1 Peers in established state : 1
Peer AS MsgRcvd MsgSent OutQ PrefRcv Up/Down State
192.168.4.2 101 5 7 0 7 00:02:09 Established
32
Problem 2: OSPF Peering: OSPF process not associated with
vpn-instance
An example of OSPF process not associated with vpn-instance is shown in Figure 13.
Figure 13 OSPF process not associated with vpn-instance
R6 R8
MPLS BACKBONE
NETWORK NETWORK
11.1.1.0/24 192.168.4.0/24 192.168.1.0/24 192.168.3.0/24 10.1.1.0/24

R1 R2 192.168.2.0/24
R3 R5
R4 PE
CE OSPF PEER
OSPF
OSPF
PE OSPF PEERCE
11.1.2.0/24
10.1.2.0/24
IBGP PEER
AS 100
R7
R9
In the above scenario, provider network is running ospf process 1 as an interior gateway protocol. An
IBGP peer relation has been established between R1 and R3 to carry VPNv4 routes. The PE-CE routing
protocol used is OSPF. OSPF process 200 is running between R1 and R4 whereas the OSPF process 111
is running between R3 and R5.
Problem
PE-CE relation between R1 and R4 is not getting established.
[R1]disp ospf 200 peer
OSPF Process 200 with Router ID 1.1.1.1

Neighbor Brief Information
Troubleshooting
1. Check the OSPF configuration on both R1 and R4.
Router R1:
[R1]disp current-configuration | begin ospf
#
ospf 200
import-route bgp
area 0.0.0.0
network 192.168.4.0 0.0.0.255
Router R4:
33
<R4>disp current-configuration | begin ospf
ospf 1
area 0.0.0.0
network 192.168.4.0 0.0.0.255
network 11.1.1.0 0.0.0.255
network 11.1.2.0 0.0.0.255
On router R1, an OSPF process 200 has been configured to carry the customer routes. But this process
is not associated with the vpn-instance created. As a result the ospf peer relationship between PE-CE
routers is not established.
2. Also check the BGP configuration on R1.

bgp 100
#
ipv4-family vpn-instance cust1_site1
import-route direct
import-route ospf 200
#
ipv4-family vpnv4
peer 3.3.3.3 enable
BGP is properly configured on router R1.
Solution
Associate the ospf process 200 with a vpn-instance created.
[R1]undo ospf 200
Warning : Undo OSPF process? [Y/N]:y
[R1]ospf 200 vpn-instance cust1_site1
[R1-ospf-200]area 0
[R1-ospf-200-area-0.0.0.0]quit
[R1-ospf-200]import-route direct
Verification
[R1]disp ospf 200 peer
OSPF Process 200 with Router ID 192.168.4.1

Neighbor Brief Information
Area: 0.0.0.0
Router ID Address Pri Dead-Time Interface State
4.4.4.4 192.168.4.2 1 39 S0/2/1 Full/ -
34
Problem 3: VPN-instance not bounded to interface
An example of vpn-instance not bounded to interface is shown in Figure 14.
Figure 14 VPN-instance not bounded to interface
R6 R8
MPLS BACKBONE
NETWORK NETWORK
11.1.1.0/24 192.168.4.0/24 192.168.1.0/24 192.168.3.0/24 10.1.1.0/24

R1 R2 192.168.2.0/24
R3 R5
R4 PE
CE EBGP PEER
OSPF
OSPF
PE EBGP PEERCE
11.1.2.0/24
10.1.2.0/24
IBGP PEER
AS 100
R7
R9
AS 101 AS 102
Problem
PE-CE peer relation not established between R1 and R4.
[R1-bgp]disp bgp vpnv4 vpn-instance vpn1 peer

192.168.4.2 101 0 0 0 0 00:04:40 Active
Troubleshooting
1. Check the BGP configuration on R1 and R4.
Router R1:
[R1]disp current-configuration | begin bgp
bgp 100
#
ipv4-family vpn-instance vpn1
import-route direct
#
35
ipv4-family vpnv4
peer 3.3.3.3 enable
Router R4:
bgp 101
import-route direct
import-route ospf 1
2. Check the configuration of serial interface connecting PE-CE.

<R1>disp current-configuration | begin interface
#
#
interface Serial0/2/1
link-protocol ppp
ip address 192.168.4.1 255.255.255.0
#
From the output it is clear that vpn-instance vpn1 is not bounded on interface serial 0/2/1.
Solution
Bind the interface with the VPN instance created for customer 1.
[R1]int se 0/2/1
[R1-Serial0/2/1]ip binding vpn-instance vpn1
[R1-Serial0/2/1]ip add 192.168.4.1 24
Verification
Check the bgp vpnv4 peer relation between R1 and R4.
[R1]disp bgp vpnv4 vpn-instance vpn1 peer

192.168.4.2 101 4 6 0 7 00:00:39 Established
The customer site is not receiving vpn-routes

After configuring a vpn, it appears that the customer router at site1 is not receiving the site 2 routes. This
could possibly be due to the following reasons:
1. Customer routes are not imported into BGP. As a result these routes are not carried by the BGP
peer across the network.
2. The BGP routes are not imported into IGP linking the PE-CE router.
36
3. IBGP peers not activated to carry vpnv4 routes.
4. Vpn-target does not match at both sites.
Problem 1: Customer routes not imported into BGP (PE-CE

routing by BGP)
An example of customer routes not imported into BGP is shown in Figure 15.
Figure 15 Customer routes not imported into BGP
R6 R8
MPLS BACKBONE
NETWORK NETWORK
11.1.1.0/24 192.168.4.0/24 192.168.1.0/24 192.168.3.0/24 10.1.1.0/24

R1 R2 192.168.2.0/24
R3 R5
R4 PE
CE EBGP PEER
OSPF
OSPF
PE EBGP PEERCE
11.1.2.0/24
10.1.2.0/24
IBGP PEER
AS 100
R7
R9
AS 101 AS 102
Problem
Router R4 is not receiving the vpn-routes of customer site 2.
4.4.4.4/32 Direct 0 0 127.0.0.1 InLoop0

11.1.1.0/24 Direct 0 0 11.1.1.1 S0/2/1
11.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
11.1.1.2/32 Direct 0 0 11.1.1.2 S0/2/1
11.1.2.0/24 Direct 0 0 11.1.2.1 S0/2/2
11.1.2.1/32 Direct 0 0 127.0.0.1 InLoop0
11.1.2.2/32 Direct 0 0 11.1.2.2 S0/2/2
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
192.168.4.0/24 Direct 0 0 192.168.4.2 S0/2/0
192.168.4.1/32 Direct 0 0 192.168.4.1 S0/2/0
192.168.4.2/32 Direct 0 0 127.0.0.1 InLoop0
37
Troubleshooting
1. Check whether router R3 is receiving the customer site 2 routes.
Router R3:
<R3>disp bgp vpnv4 vpn-instance vpn1 routing-table
Total Number of Routes: 7
BGP Local router ID is 3.3.3.3

Status codes: * - valid, ^ - VPN best, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Network NextHop MED LocPrf PrefVal Path/Ogn
* >i 4.4.4.4/32 1.1.1.1 0 100 0 101?

* >i 11.1.1.0/24 1.1.1.1 0 100 0 101?
* >i 11.1.1.2/32 1.1.1.1 0 100 0 101?
* >i 11.1.2.0/24 1.1.1.1 0 100 0 101?
* >i 11.1.2.2/32 1.1.1.1 0 100 0 101?
* >i 192.168.4.0 1.1.1.1 0 100 0 ?
* >i 192.168.4.2/32 1.1.1.1 0 100 0 ?
The vpn-instance routing table on R3 does not show the route entries for 10.0.0.0 network.
2. Check the BGP configuration on R3 and R5.

Router R3:
bgp 100
#
import-route direct
#
ipv4-family vpnv4
peer 1.1.1.1 enable
Router R5:
bgp 102
import-route ospf 1
38
In the BGP configuration on R5, the import-route direct command is missing from the configuration.
Solution
Configure the command import-route direct on R4 to import all the direct routes into BGP.
[R5]bgp 102
[R5-bgp]import-route direct
Verification
Verify the routing table of R4 to check whether it is receiving the routes of customer site 2.
4.4.4.4/32 Direct 0 0 127.0.0.1 InLoop0

5.5.5.5/32 BGP 255 0 192.168.4.1 S0/2/0
10.1.1.0/24 BGP 255 0 192.168.4.1 S0/2/0
10.1.1.2/32 BGP 255 0 192.168.4.1 S0/2/0
10.1.2.0/24 BGP 255 0 192.168.4.1 S0/2/0
10.1.2.2/32 BGP 255 0 192.168.4.1 S0/2/0
11.1.1.0/24 Direct 0 0 11.1.1.1 S0/2/1
11.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
11.1.1.2/32 Direct 0 0 11.1.1.2 S0/2/1
11.1.2.0/24 Direct 0 0 11.1.2.1 S0/2/2
11.1.2.1/32 Direct 0 0 127.0.0.1 InLoop0
11.1.2.2/32 Direct 0 0 11.1.2.2 S0/2/2
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
192.168.3.0/24 BGP 255 0 192.168.4.1 S0/2/0
192.168.3.2/32 BGP 255 0 192.168.4.1 S0/2/0
192.168.4.0/24 Direct 0 0 192.168.4.2 S0/2/0
192.168.4.1/32 Direct 0 0 192.168.4.1 S0/2/0
192.168.4.2/32 Direct 0 0 127.0.0.1 InLoop0
R4 is now receiving the routes from customer site 2.
Problem 2: BGP vpnv4 routes not redistributed into customer vrf

An example of BGP vpnv4 routes not redistributed into customer vrf is shown in Figure 16.
39
Figure 16 BGP VPNV4 routes not redistributed into customer vrf
Cust_A CE11
Site 1
MPLS BACKBONE
P1 P2
10.1.1.0/24
200.1.1.0/30 Cust_A
CE12
128.1.1.0/30 Site 2
201.1.1.8/30
201.1.1.0/30
PE2 129.1.1.0/30
PE1 11.1.1.0/24
CE21 128.1.1.4/30
Cust_B
200.1.1.8/30 200.1.1.4/30
Site 1
IBGP PEER
10.1.1.0/24
201.1.1.4/30 129.1.1.4/30
201.1.1.12/30
200.1.1.12/30 Cust_B
CE22
128.1.1.8/30 Site 2
P3 P4
OSPF NETWORK
CE31 192.168.1.0/24
Cust_C
Site 1
172.16.1.0/24 PE-CE Routing Protocol
BGP
OSPF
RIP
In the figure above, The Core provider network is running OPSF as its IGP. The Provider Edge routers are
configured with BGP to carry the external routes. An IBGP peer relation has been established between
PE1 and PE2.
The Provider router and the customer routers connect using different routing protocols such as OSPF,
EBGP, and RIP.
Scenario 1: The routing protocol running between the PE1-CE11 and PE2-CE12 is OSPF. The Provider
backbone is configured with OSPF as IGP. An IBGP peer has been established between PE1 and PE2 to
carry the VPN traffic. MPLS has been enabled on the provider devices.
Problem
No VPN routes are exchanged between Customer1 site1 and customer1 site2.
[CE11]disp ip routing-table
10.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0

10.1.2.1/32 Direct 0 0 127.0.0.1 InLoop0
10.1.3.1/32 Direct 0 0 127.0.0.1 InLoop0
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
128.1.1.0/30 Direct 0 0 128.1.1.2 S0/2/0
128.1.1.1/32 Direct 0 0 128.1.1.1 S0/2/0
128.1.1.2/32 Direct 0 0 127.0.0.1 InLoop0
CE11 is not receiving the routes from CE12 via VPN.
40
Troubleshooting
1. Check the routing table for vpn-instance cust1_site1 on PE1.
[PE1]disp bgp vpnv4 vpn-instance cust1_site1 routing-table

*^> 10.1.1.1/32 0.0.0.0 1563 0 ?

*^> 10.1.2.1/32 0.0.0.0 1563 0 ?
*^> 10.1.3.1/32 0.0.0.0 1563 0 ?
* >i 11.1.1.1/32 6.6.6.6 1563 100 0 ?
* >i 11.1.2.1/32 6.6.6.6 1563 100 0 ?
* >i 11.1.3.1/32 6.6.6.6 1563 100 0 ?
* >i 11.1.4.1/32 6.6.6.6 1563 100 0 ?
*^> 128.1.1.0/30 0.0.0.0 0 0 ?
*^> 128.1.1.1/32 0.0.0.0 0 0 ?
*^> 128.1.1.2/32 0.0.0.0 0 0 ?
* >i 129.1.1.0/30 6.6.6.6 0 100 0 ?
* >i 129.1.1.2/32 6.6.6.6 0 100 0 ?
PE1 is receiving the site2 routes.

This means that the problem lies in redistribution of routing table.
2. Check whether the BGP routes are redistributed into OSPF.
[PE1]disp current-configuration | begin bgp
bgp 100
#
import-route direct
import-route ospf 200
#
import-route direct
#
ipv4-family vpnv4
peer 6.6.6.6 enable
#
ospf 1
41
area 0.0.0.0
network 201.1.1.0 0.0.0.255
network 5.5.5.5 0.0.0.0
#
ospf 200 vpn-instance cust1_site1
area 0.0.0.0
network 128.1.1.0 0.0.0.3
#
load xml-configuration
#
load tr069-configuration
#
user-interface con 0
user-interface vty 0 4
#
Return
In this scenario PE1 is configured to import route from OSPF into BGP but redistribution of BGP routes into
OSPF is not configured. Though PE1 receives the customer routes via BGP, since those routes are not
redistributed into OSPF, CE11 is unable to receive the customer vpn routes.
Solution
Redistribute BGP routes into OSPF process 200.
[PE1]ospf 200
[PE1-ospf-200]import-route bgp
Verification
Check whether CE11 is now receiving the routes of site2.
<CE11>disp ip routing-table
10.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0

10.1.2.1/32 Direct 0 0 127.0.0.1 InLoop0
10.1.3.1/32 Direct 0 0 127.0.0.1 InLoop0
11.1.1.1/32 OSPF 10 3125 128.1.1.1 S0/2/0
11.1.2.1/32 OSPF 10 3125 128.1.1.1 S0/2/0
11.1.3.1/32 OSPF 10 3125 128.1.1.1 S0/2/0
11.1.4.1/32 OSPF 10 3125 128.1.1.1 S0/2/0
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
128.1.1.0/30 Direct 0 0 128.1.1.2 S0/2/0
128.1.1.1/32 Direct 0 0 128.1.1.1 S0/2/0
128.1.1.2/32 Direct 0 0 127.0.0.1 InLoop0
129.1.1.0/30 O_ASE 150 1 128.1.1.1 S0/2/0
129.1.1.2/32 O_ASE 150 1 128.1.1.1 S0/2/0
42
CE11 is now receiving all the routes from customer site 2.
Problem 3: IBGP peers not activated to carry vpn-routes

An example of IBGP peers not activated to carry vpn-routes is shown in Figure 17.
Figure 17 IBGP peers not activated to carry VPN-routes
R6 R8
MPLS BACKBONE
NETWORK NETWORK
11.1.1.0/24 192.168.4.0/24 192.168.1.0/24 192.168.3.0/24 10.1.1.0/24

R1 R2 192.168.2.0/24
R3 R5
R4 PE
CE EBGP PEER
OSPF
OSPF
PE EBGP PEERCE
11.1.2.0/24
10.1.2.0/24
IBGP PEER
AS 100
R7
R9
AS 101 AS 102
Problem
Router R4 is not receiving the cust_site2 routes.
[R4]disp ip routing-table
4.4.4.4/32 Direct 0 0 127.0.0.1 InLoop0

11.1.1.0/24 Direct 0 0 11.1.1.1 S0/2/1
11.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
11.1.1.2/32 Direct 0 0 11.1.1.2 S0/2/1
11.1.2.0/24 Direct 0 0 11.1.2.1 S0/2/2
11.1.2.1/32 Direct 0 0 127.0.0.1 InLoop0
11.1.2.2/32 Direct 0 0 11.1.2.2 S0/2/2
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
192.168.4.0/24 Direct 0 0 192.168.4.2 S0/2/0
192.168.4.1/32 Direct 0 0 192.168.4.1 S0/2/0
192.168.4.2/32 Direct 0 0 127.0.0.1 InLoop0
Troubleshooting
1. Check the routing table for the vpn-instance vpn1 on Router R1.
[R1]disp bgp vpnv4 vpn-instance vpn1 routing-table
43

*^> 4.4.4.4/32 192.168.4.2 0 0 101?

*^> 11.1.1.0/24 192.168.4.2 0 0 101?
*^> 11.1.1.2/32 192.168.4.2 0 0 101?
*^> 11.1.2.0/24 192.168.4.2 0 0 101?
*^> 11.1.2.2/32 192.168.4.2 0 0 101?
*^> 192.168.4.0 0.0.0.0 0 0 ?
* 192.168.4.2 0 0 101?
*^> 192.168.4.1/32 0.0.0.0 0 0 ?
* 192.168.4.2 0 0 101?
*^> 192.168.4.2/32 0.0.0.0 0 0 ?
Router R1 is not receiving the 10.0.0.0 network of customer site 2.

2. Check the routing table of R3 for the vpn-instance vpn1.
<R3>disp ip routing-table vpn-instance vpn1
Routing Tables: vpn1
5.5.5.5/32 BGP 255 0 192.168.3.2 S0/2/1

10.1.1.0/24 BGP 255 0 192.168.3.2 S0/2/1
10.1.1.2/32 BGP 255 0 192.168.3.2 S0/2/1
10.1.2.0/24 BGP 255 0 192.168.3.2 S0/2/1
10.1.2.2/32 BGP 255 0 192.168.3.2 S0/2/1
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
192.168.3.0/24 Direct 0 0 192.168.3.1 S0/2/1
192.168.3.1/32 Direct 0 0 127.0.0.1 InLoop0
192.168.3.2/32 Direct 0 0 192.168.3.2 S0/2/1
Router R3 is not receiving the customer site 1 although customer site2 route entries are present in the
routing table of R3.
This means that the customer site 1 and site 2 routes are not being exchanged between Routers R1 and
R3.
3. Check the IBGP peer relation between R1 and R3.
<R1>disp bgp peer
44
3.3.3.3 100 57 59 0 0 00:57:46 Established
4. Check the vpnv4 peer relation between R1 and R3.

Router R1:
<R1>disp bgp vpnv4 all peer
No Peer Exist
Router R3:
<R3>disp bgp vpnv4 all peer

1.1.1.1 100 4 4 0 0 00:01:59 No neg
Even though IBGP peer relation has been established between R1 and R3, a vpnv4 peer relation has not
been established.
5. Check the BGP configuration on R1.
bgp 100
#
import-route direct
From the above output it is clear that the MP-BGP vpnv4 peer has not been enabled.
Solution
Enable peer R3 under ipv4-family vpnv4.
[R1]bgp 100
[R1-bgp]ipv4-family vpnv4
[R1-bgp-af-vpnv4]peer 3.3.3.3 enable
Verification
45
4.4.4.4/32 Direct 0 0 127.0.0.1 InLoop0

5.5.5.5/32 BGP 255 0 192.168.4.1 S0/2/0
10.1.1.0/24 BGP 255 0 192.168.4.1 S0/2/0
10.1.1.2/32 BGP 255 0 192.168.4.1 S0/2/0
10.1.2.0/24 BGP 255 0 192.168.4.1 S0/2/0
10.1.2.2/32 BGP 255 0 192.168.4.1 S0/2/0
11.1.1.0/24 Direct 0 0 11.1.1.1 S0/2/1
11.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
11.1.1.2/32 Direct 0 0 11.1.1.2 S0/2/1
11.1.2.0/24 Direct 0 0 11.1.2.1 S0/2/2
11.1.2.1/32 Direct 0 0 127.0.0.1 InLoop0
11.1.2.2/32 Direct 0 0 11.1.2.2 S0/2/2
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
192.168.3.0/24 BGP 255 0 192.168.4.1 S0/2/0
192.168.3.2/32 BGP 255 0 192.168.4.1 S0/2/0
192.168.4.0/24 Direct 0 0 192.168.4.2 S0/2/0
192.168.4.1/32 Direct 0 0 192.168.4.1 S0/2/0
---- More ----
Router R4 is receiving the customer site2 routes.
Problem 4: Mismatch in the vpn-target configuration

An example of mismatch in the vpn-target configuration is shown in Figure 18.
Figure 18 Mis-match in the vpn-target configuration
R6 R8
MPLS BACKBONE
NETWORK NETWORK
11.1.1.0/24 192.168.4.0/24 192.168.1.0/24 192.168.3.0/24 10.1.1.0/24

R1 R2 192.168.2.0/24
R3 R5
R4 PE
CE EBGP PEER
OSPF
OSPF
PE EBGP PEERCE
11.1.2.0/24
10.1.2.0/24
IBGP PEER
AS 100
R7
R9
AS 101 AS 102
46
Problem
R4 is not receiving the routes of customer site 2.
4.4.4.4/32 Direct 0 0 127.0.0.1 InLoop0

11.1.1.0/24 Direct 0 0 11.1.1.1 S0/2/1
11.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
11.1.1.2/32 Direct 0 0 11.1.1.2 S0/2/1
11.1.2.0/24 Direct 0 0 11.1.2.1 S0/2/2
11.1.2.1/32 Direct 0 0 127.0.0.1 InLoop0
11.1.2.2/32 Direct 0 0 11.1.2.2 S0/2/2
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
192.168.4.0/24 Direct 0 0 192.168.4.2 S0/2/0
192.168.4.1/32 Direct 0 0 192.168.4.1 S0/2/0
192.168.4.2/32 Direct 0 0 127.0.0.1 InLoop0
The routing table of R4 does not show the route-entry for 10.0.0.0 network.
Troubleshooting
1. Check the routing table for vpn-instance vpn1 on Router R1.
[R1]disp ip routing-table vpn-instance vpn1
Routing Tables: vpn1
4.4.4.4/32 BGP 255 0 192.168.4.2 S0/2/1

11.1.1.0/24 BGP 255 0 192.168.4.2 S0/2/1
11.1.1.2/32 BGP 255 0 192.168.4.2 S0/2/1
11.1.2.0/24 BGP 255 0 192.168.4.2 S0/2/1
11.1.2.2/32 BGP 255 0 192.168.4.2 S0/2/1
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
192.168.4.0/24 Direct 0 0 192.168.4.1 S0/2/1
192.168.4.1/32 Direct 0 0 127.0.0.1 InLoop0
192.168.4.2/32 Direct 0 0 192.168.4.2 S0/2/1
Even Router R1 does not have the route entries of site2.
2. Check the vpn routes on R3.

<R3>disp bgp vpnv4 vpn-instance vpn1 routing-table
47

*^> 5.5.5.5/32 192.168.3.2 0 0 102?

*^> 10.1.1.0/24 192.168.3.2 0 0 102?
*^> 10.1.1.2/32 192.168.3.2 0 0 102?
*^> 10.1.2.0/24 192.168.3.2 0 0 102?
*^> 10.1.2.2/32 192.168.3.2 0 0 102?
*^> 192.168.3.0 0.0.0.0 0 0 ?
* 192.168.3.2 0 0 102?
*^> 192.168.3.1/32 0.0.0.0 0 0 ?
* 192.168.3.2 0 0 102?
*^> 192.168.3.2/32 0.0.0.0 0 0 ?
Even router R3 is not receiving the vpn-routes of customer site 1.

3. Check the IBGP peer relation between R1 and R3.
In this scenario, R1 has established a Peer relationship with R3. Still the customer site routes are not
getting exchanged.
4. Check the BGP configuration on both R1 and R3 to verify whether any route-policy is blocking the
route entries.
Router R1:
bgp 100
#
import-route direct
#
ipv4-family vpnv4
peer 3.3.3.3 enable
Router R3:
bgp 100
48
#
import-route direct
#
ipv4-family vpnv4
peer 1.1.1.1 enable
5. Check the VPN-instance configuration on R1 and R3.

Router R1:
<R1>disp ip vpn-instance instance-name vpn1
VPN-Instance Name and ID : vpn1, 1
Create time : 2012/10/08 22:28:05
Up time : 0 days, 09 hours, 36 minutes and 39 seconds
Route Distinguisher : 1:1
Export VPN Targets : 102:1
Import VPN Targets : 102:1
IPv6 Export VPN Targets : 102:1
IPv6 Import VPN Targets : 102:1
Interfaces : Serial0/2/1
Router R3:
[R3]disp ip vpn-instance instance-name vpn1
VPN-Instance Name and ID : vpn1, 1
Create time : 2012/10/08 22:30:16
Up time : 0 days, 09 hours, 31 minutes and 52 seconds
Route Distinguisher : 1:1
Export VPN Targets : 101:1
Import VPN Targets : 101:1
IPv6 Export VPN Targets : 101:1
IPv6 Import VPN Targets : 101:1
Interfaces : Serial0/2/1
The above output shows that the vpn-targets imported and exported for vpn-instance on R1 and R3 differ
from each other. No common vpn-target is available in the vpn-instance, which allows for importing and
exporting the two customer site routes.
Solution
Associate a common vpn-target to the vpn-instances created on R1 and R3 for customer site 1 and site
2.
Router R1:
[R1]ip vpn-instance vpn1
[R1-vpn-instance-vpn1]vpn-target 103:1
49
Router R3:
[R3]ip vpn-instance vpn1
[R3-vpn-instance-vpn1]vpn-target 103:1
Verification
4.4.4.4/32 Direct 0 0 127.0.0.1 InLoop0

5.5.5.5/32 BGP 255 0 192.168.4.1 S0/2/0
10.1.1.0/24 BGP 255 0 192.168.4.1 S0/2/0
10.1.1.2/32 BGP 255 0 192.168.4.1 S0/2/0
10.1.2.0/24 BGP 255 0 192.168.4.1 S0/2/0
10.1.2.2/32 BGP 255 0 192.168.4.1 S0/2/0
11.1.1.0/24 Direct 0 0 11.1.1.1 S0/2/1
11.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
11.1.1.2/32 Direct 0 0 11.1.1.2 S0/2/1
11.1.2.0/24 Direct 0 0 11.1.2.1 S0/2/2
11.1.2.1/32 Direct 0 0 127.0.0.1 InLoop0
11.1.2.2/32 Direct 0 0 11.1.2.2 S0/2/2
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
192.168.3.0/24 BGP 255 0 192.168.4.1 S0/2/0
192.168.3.2/32 BGP 255 0 192.168.4.1 S0/2/0
192.168.4.0/24 Direct 0 0 192.168.4.2 S0/2/0
192.168.4.1/32 Direct 0 0 192.168.4.1 S0/2/0
192.168.4.2/32 Direct 0 0 127.0.0.1 InLoop0
Router R4 is now receiving the site 2 routes.
50
4 MPLS TE
MPLS Traffic Engineering (TE) is a feature that engineers the traffic flows for the optimum utilization of
bandwidth in the core network. In a backbone network, traffic congestion occurs due to over-utilization
of certain links, whereas other links remain under-utilized. Congestion and delay of traffic is a common
occurrence in a backbone network if only the IGP shortest path algorithm is implemented. In order to
prevent such occurrences in a core network and give a satisfactory performance to their clients, ISPs have
selected traffic engineering.
Various problems occur in the configuration of TE on a network. The major problems that occur are listed
below:
• MPLS TE tunnel is not getting established.
• Traffic is not routed through TE tunnel.
• MPLS TE traffic not tunneled through the desired path.
MPLS TE Tunnel is not getting established

TE is brought into effect by creating a tunnel to carry the traffic. Mainly TE is used to avoid network
congestion. TE helps to manage the flow of traffic by re-directing the path of the traffic through the least
used links. As a result, all the links (backup links/ least used links) in the network are functional and there
is less delay and congestion in the network. Load balancing and redundancy can be achieved through
TE.
A tunnel interface is created in the process of configuring TE. This tunnel interface participates in the SPF
calculation. In the IP routing table, the out interface is replaced by the tunnel interface for the tunnel
destination routes.
The few configuration errors that lead to the non-establishment of the tunnel are listed below:
1. MPLS TE not enabled globally.
2. MPLS TE not enabled on the interface participating in TE.
3. RSVP not enabled globally.
4. Interface not enabled to support RSVP.
5. OSPF not configured to carry TE attributes (OSPF not enabled to generate and receive Opaque
LSAs).
6. Changes to the tunnel interface is not committed.
51
Problem 1: MPLS TE not enabled globally
MPLS TE must be enabled globally and on interfaces of all the routers participating in traffic engineering.
If any router is left unconfigured, it may lead to the non-establishment of the tunnel. An example of MPLS
TE not being enabled globally is shown in Figure 19.
Figure 19 MPLS TE not enabled globally
Lo: 1.1.1.1
P1
201.1.1.0/30
201.1.1.4/30
Lo: 4.4.4.4
Lo: 6.6.6.6 PE2 Lo: 7.7.7.7
PE1
128.1.1.0/30 129.1.1.0/30
Lo: 5.5.5.5
A1 A2
200.1.1.8/30
200.1.1.0/30
200.1.1.4/30
P2 P3
Lo: 2.2.2.2
Lo: 3.3.3.3
Problem No mpls te tunnel is getting established between the head-end and tail-end routers.
<A1>disp mpls rsvp-te established

<A1>
Troubleshooting
1. Check whether MPLS is enabled globally on all the routers using the command display
current-configuration configuration mpls.
In this scenario all the routers have mpls enabled globally.
2. Check whether “mpls te” is enabled on all the routers. Use the command display
current-configuration configuration mpls to display the information.
In this scenario, MPLS TE is enabled on all routers except router PE2.
[PE2]disp current-configuration configuration mpls

#
mpls
#
Return
52
Router PE2 is configured with MPLS feature. However, it has not been configured with TE feature in order
to participate in TE. Since PE2 is a critical node in the tunnel between A1 and A2, it must be enabled
with MPLS TE and RSVP.
Solution
Configure MPLS TE globally and on all the interfaces. Also configure the Tunnel signaling protocol as
rsvp-te.
[PE2]mpls
[PE2-mpls]mpls te
Info: MPLS TE starting, please wait...OK.
[PE2-mpls]mpls rsvp-te
[PE2-mpls]mpls te cspf
[PE2-mpls]quit
[PE2]int se 0/2/0
[PE2-Serial0/2/0]mpls te
[PE2-Serial0/2/0]mpls rsvp-te
[PE2-Serial0/2/0]int se 0/2/1
[PE2-Serial0/2/1]int se 0/2/2
Verification
Verify whether Tunnel is UP.
[A1-Tunnel0]disp mpls te tunnel
LSP-Id Destination In/Out-If Name
6.6.6.6:6 7.7.7.7 -/S0/2/0 Tunnel0
You can also verify the same using the command display mpls rsvp-te established.
[A1-Tunnel0]disp mpls rsvp-te established

Interface Serial0/2/0:
Token Bucket Rate: 250000.00 Peak Data Rate: 250000.00
Tunnel Dest: 7.7.7.7 Ingress LSR ID: 6.6.6.6
Local LSP ID: 6 Session Tunnel ID: 1
Next Hop Addr: 128.1.1.2
Upstream Label: NULL Downstream Label: 1031
The tunnel is now established.
53
Problem 2: MPLS TE not enabled on interface
An example of MPLS-TE not enabled on interface is shown in Figure 20.
Figure 20 MPLS TE not enabled on interface
Lo: 1.1.1.1
P1
201.1.1.0/30
201.1.1.4/30
Lo: 4.4.4.4
Lo: 6.6.6.6 PE2 Lo: 7.7.7.7
PE1
128.1.1.0/30 129.1.1.0/30
Lo: 5.5.5.5
A1 A2
200.1.1.8/30
200.1.1.0/30
200.1.1.4/30
P2 P3
Lo: 2.2.2.2
Lo: 3.3.3.3
Problem
No mpls te tunnel is established between the head-end and tail-end routers.
<A1>disp mpls te tunnel
<A1>
Troubleshooting
1. Check whether MPLS is enabled globally and on all the interfaces of routers participating in TE.
In this scenario, all the routers have mpls enabled globally and on interfaces.
2. Check whether MPLS TE is enabled globally and on all the interfaces of routers participating in TE.
Use the command display current-configuration interface to check the configuration of all the
interfaces on routers.
[PE1]disp current-configuration interface

#
link-protocol ppp
ip address 201.1.1.1 255.255.255.252
mpls
mpls te
mpls te max-link-bandwidth 10000
mpls te max-reservable-bandwidth 5000
mpls rsvp-te
#
link-protocol ppp
54
ip address 200.1.1.1 255.255.255.252
mpls
mpls te
mpls rsvp-te
#
link-protocol ppp
ip address 128.1.1.2 255.255.255.252
mpls
#
In the above example, the interface serial 0/2/2 of router PE1 is not configured to participate in TE.
Serial 0/2/2 is the interface connecting to router A1. Since the interface connecting router A1 is not
configured with TE feature, tunnel is not established.
Solution
Enable MPLS TE and rsvp-te on se0/2/2 of router PE1.
[PE1]int se 0/2/2
Verification
Verify the status of tunnel

6.6.6.6:7 7.7.7.7 -/S0/2/0 Tunnel0
The tunnel is now established.
Problem 3: RSVP-TE not enabled globally

An example of RSVP-TE not enabled globally is shown in Figure 21.
55
Figure 21 RSVP-TE not enabled globally
Lo: 1.1.1.1
P1
201.1.1.0/30
201.1.1.4/30
Lo: 4.4.4.4
Lo: 6.6.6.6 PE2 Lo: 7.7.7.7
PE1
128.1.1.0/30 129.1.1.0/30
Lo: 5.5.5.5
A1 A2
200.1.1.8/30
200.1.1.0/30
200.1.1.4/30
P2 P3
Lo: 2.2.2.2
Lo: 3.3.3.3
Problem
No mpls te tunnel is getting established between routers A1 and A2.
[A1-mpls]disp mpls rsvp-te established

[A1-mpls]
Troubleshooting
1. Verify the MPLS configuration on all the routers.
Router A1:
[A1]disp current-configuration configuration mpls
#
mpls
mpls te
mpls te cspf
#
Return
2. Check the configuration of tunnel interface Tunnel0 to verify the signaling protocol used for TE.
[A1]disp mpls te tunnel-interface Tunnel 0
Tunnel Name : Tunnel0

Tunnel Desc : Tunnel0 Interface
Tunnel State Desc : CR-LSP is setting Up
Tunnel Attributes :
LSP ID : 6.6.6.6:8
Session ID : 1
Admin State : UP Oper State : DOWN
Ingress LSR ID : 6.6.6.6 Egress LSR ID: 7.7.7.7
Signaling Prot : RSVP Resv Style : SE
Class Type : CT0 Tunnel BW : 2000 kbps
Reserved BW : 2000 kbps
56
Setup Priority : 7 Hold Priority: 7
Affinity Prop/Mask : 0x0/0x0
Explicit Path Name : Dynamic
Tie-Breaking Policy : None
Metric Type : None
The output of step 2 shows that the signaling protocol used for Tunnel establishment is RSVP-TE, which has
not been enabled globally and on the interfaces of Router A1, as a result of which MPLS TE Tunnel is not
established.
Solution
Enable rsvp-te globally and on interfaces of router A1.
[A1]mpls
[A1-mpls]mpls rsvp-te
[A1-mpls]int se 0/2/0
[A1-Serial0/2/0]mpls rsvp-te
Verification
Verify the status of tunnel.
[A1]disp mpls rsvp-te established
MPLS te tunnel is now established.
57
Problem 4: RSVP-te not enabled on the interface
An example of RSVP-TE not enabled on the interface is shown in Figure 22.
Figure 22 RSVP-TE not enabled on the interface
Lo: 1.1.1.1
P1
201.1.1.0/30
Lo: 4.4.4.4
201.1.1.4/30 Troubleshooting:
Lo: 6.6.6.6 PE2 Lo: 7.7.7.7
PE1
128.1.1.0/30 129.1.1.0/30
Lo: 5.5.5.5
A1 A2
200.1.1.8/30
200.1.1.0/30
200.1.1.4/30
P2 P3
Lo: 2.2.2.2
Lo: 3.3.3.3
Problem

[A1]
Troubleshooting
Follow the steps used in Problem 2 to evaluate the configuration mistake on the routers.
In this scenario, rsvp-te is not enabled on the interface of Router A2, As a result, tunnel is not getting
established.
[A2]disp mpls rsvp-te interface

[A2]
The above command shows an empty output, which means that there is no interface which has rsvp-te
enabled on router A2.
You can also verify the same using the command display current-configuration interface se 0/2/0.
[A2]display current-configuration interface se 0/2/0

#
link-protocol ppp
ip address 129.1.1.1 255.255.255.252
mpls
mpls te
58
#
Return
Solution
Enable rsvp-te on the interface.
[A2]int se 0/2/0
[A2-Serial0/2/0]mpls rsvp-te
Verification
Verify the status of MPLS tunnel.
[A1]disp mpls te tunnel

6.6.6.6:16 7.7.7.7 -/S0/2/0 Tunnel0
You can also check the tunnel established using the command disp mpls rsvp-te established.

Problem 5: OSPF not configured to carry TE attributes/OSPF

not enabled to generate and receive opaque LSAs
OSPF carries the TE attributes in opaque LSA. By default, the opaque LSAs are not generated by OSPF.
This capability to generate and receive opaque LSAs must be enabled on the routers. An example of
OSPF not configured to carry TE attributes is shown in Figure 23.
59
Figure 23 OSPF not configured to carry TE attributes
Lo: 1.1.1.1
P1
201.1.1.0/30
201.1.1.4/30
Lo: 4.4.4.4
Lo: 6.6.6.6 PE2 Lo: 7.7.7.7
PE1
128.1.1.0/30 129.1.1.0/30
Lo: 5.5.5.5
A1 A2
200.1.1.8/30
200.1.1.0/30
200.1.1.4/30
P2 P3
Lo: 2.2.2.2
Lo: 3.3.3.3
Problem

[A1]
Troubleshooting
1. Check the status of tunnel interface using the command display mpls te tunnel-interface Tunnel 0.
[A1]disp mpls te tunnel-interface Tunnel 0
Tunnel Name : Tunnel0

Tunnel Desc : Tunnel0 Interface
Tunnel State Desc : CR-LSP is setting Up
Tunnel Attributes :
LSP ID : 6.6.6.6:2
Session ID : 1
Admin State : UP Oper State : DOWN
Ingress LSR ID : 6.6.6.6 Egress LSR ID: 7.7.7.7
Signaling Prot : RSVP Resv Style : SE
Class Type : CT0 Tunnel BW : 2000 kbps
Reserved BW : 2000 kbps
Setup Priority : 7 Hold Priority: 7
Affinity Prop/Mask : 0x0/0x0
Explicit Path Name : Dynamic
Tie-Breaking Policy : None
Metric Type : None
Loop Detection : Disabled
Record Route : Disabled Record Label : Disabled
FRR Flag : Disabled BackUpBW Flag: Not Supported
BackUpBW Type : - BackUpBW : -
Route Pinning : Disabled
60
Retry Limit : 10 Retry Interval: 2 sec
---- More ----
The status of tunnel interface is showing to be down. You can also verify the status of tunnel interface
using the command display interface tunnel 0.
<A1>disp int Tunnel 0

Tunnel0 current state: DOWN
Line protocol current state: DOWN
Description: Tunnel0 Interface
The Maximum Transmit Unit is 64000
Internet Address is unnumbered, using address of LoopBack0(6.6.6.6/32)
Encapsulation is TUNNEL, service-loopback-group ID not set.
Tunnel source unknown, destination 7.7.7.7
Tunnel bandwidth 200 (kbps)
Tunnel protocol/transport CR_LSP
Tunnel interface is DOWN.
2. Check whether MPLS, MPLS TE, and rsvp are enabled globally and on all the interfaces of routers
participating in the TE.
In the above example, all routers are enabled with MPLS, MPLS Te, and rsvp.
3. Check whether OSPF has been configured to carry the TE attributes.

In the above example, Router PE2 is not configured to carry TE attributes as a result of which tunnel is not
getting established.
<PE2>disp current-configuration configuration ospf

#
ospf 1
area 0.0.0.0
network 129.1.1.0 0.0.0.255
network 201.1.1.0 0.0.0.255
network 200.1.1.0 0.0.0.255
network 5.5.5.5 0.0.0.0
#
Return
Solution
Configure PE2 to carry the tunnel attributes.
[PE2]ospf 1
[PE2-ospf-1]opaque-capability enable
[PE2-ospf-1]area 0
[PE2-ospf-1-area-0.0.0.0]mpls-te enable
61
Verification
Verify the status of tunnel.

6.6.6.6:1 7.7.7.7 -/S0/2/0 Tunnel0
MPLS tunnel is now up.
Problem 6: Changes to the tunnel interface not committed.

To execute the tunnel interface configuration, it is necessary to run the command mpls te commit. This
command executes the configuration done or any changes made to the tunnel interface. In most cases,
engineers tend to reconfigure the bandwidth or other parameters of the tunnel interface and forget to run
this command. As a result, the changes do not reflect in the network, although values have been
changed.
For a newly configured tunnel, if this command is not run, then tunnel is not established. Troubleshooting
of this problem is explained in the below example, see Figure 24.
Figure 24 Changed to tunnel interface not committed
Lo: 1.1.1.1
P1
201.1.1.0/30
201.1.1.4/30
Lo: 4.4.4.4
Lo: 6.6.6.6 PE2 Lo: 7.7.7.7
PE1
128.1.1.0/30 129.1.1.0/30
Lo: 5.5.5.5
A1 A2
200.1.1.8/30
200.1.1.0/30
200.1.1.4/30
P2 P3
Lo: 2.2.2.2
Lo: 3.3.3.3
Problem

[A1]
Troubleshooting
Check the tunnel interface configuration.
[A1-Tunnel0]disp current-configuration int tunnel 0

#
interface Tunnel0
ip address unnumbered interface LoopBack0
62
tunnel-protocol mpls te
destination 7.7.7.7
tunnel bandwidth 2000
mpls
mpls te tunnel-id 1
mpls te path explicit-path p2-p3 preference 1
mpls te path dynamic preference 2
mpls te igp shortcut
mpls te igp metric absolute 200
#
Return
In the above configuration, the mpls te commit command is missing. Unless this command is configured,
the tunnel interface configuration does not take effect. Any changes to the tunnel interface configuration
must be committed for it to be activated.
Solution
Configure the command mpls te commit under tunnel0 interface.
[A1]int tunnel 0
[A1-Tunnel0]mpls te commit
Verification
Verify the status of the tunnel.
[A1-Tunnel0]disp mpls te tunnel
6.6.6.6:1 7.7.7.7 -/S0/2/0 Tunnel0
Tunnel is now established
Traffic not routed through TE tunnel

Most of the time the TE tunnel gets established but still traffic is not routed through the tunnel. In brief,
OSPF does not take the tunnel into consideration while calculating the shortest path using SPF. This
problem may occur in a network due to the following reasons:
1. IP address not assigned to the tunnel interface.
2. Tunnel interface not configured to participate in OSPF SPF calculation.
3. OSPF not configured to include the static LSP tunnel in SPF calculation.
Problem 1: IP address not assigned to the tunnel interface

An example of IP address not assigned to the tunnel interface is shown in Figure 25.
63
Figure 25 IP address not assigned to the tunnel interface
Lo: 1.1.1.1
P1
201.1.1.0/30
201.1.1.4/30
Lo: 4.4.4.4
Lo: 6.6.6.6 PE2 Lo: 7.7.7.7
PE1
128.1.1.0/30 129.1.1.0/30
Lo: 5.5.5.5
A1 A2
200.1.1.8/30
200.1.1.0/30
200.1.1.4/30
P2 P3
Lo: 2.2.2.2
Lo: 3.3.3.3
Problem
Traffic is not routed through the tunnel.
[A1-Tunnel0]disp ip routing-table
1.1.1.1/32 OSPF 10 3124 128.1.1.2 S0/2/0

2.2.2.2/32 OSPF 10 3124 128.1.1.2 S0/2/0
3.3.3.3/32 OSPF 10 4686 128.1.1.2 S0/2/0
4.4.4.4/32 OSPF 10 1562 128.1.1.2 S0/2/0
5.5.5.5/32 OSPF 10 4686 128.1.1.2 S0/2/0
6.6.6.6/32 Direct 0 0 127.0.0.1 InLoop0
7.7.7.7/32 OSPF 10 6248 128.1.1.2 S0/2/0
10.1.1.2/32 OSPF 10 6248 128.1.1.2 S0/2/0
10.1.1.3/32 OSPF 10 6248 128.1.1.2 S0/2/0
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
128.1.1.0/30 Direct 0 0 128.1.1.1 S0/2/0
128.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
128.1.1.2/32 Direct 0 0 128.1.1.2 S0/2/0
129.1.1.0/30 OSPF 10 6248 128.1.1.2 S0/2/0
200.1.1.0/30 OSPF 10 3124 128.1.1.2 S0/2/0
200.1.1.4/30 OSPF 10 4686 128.1.1.2 S0/2/0
200.1.1.8/30 OSPF 10 6248 128.1.1.2 S0/2/0
201.1.1.0/30 OSPF 10 3124 128.1.1.2 S0/2/0
201.1.1.4/30 OSPF 10 4686 128.1.1.2 S0/2/0
The routing table of A1 does not show tunnel interface Tunnel 0 as the out interface for tunnel destination
route.
64
Troubleshooting
1. Check whether tunnel is up.

6.6.6.6:16 7.7.7.7 -/S0/2/0 Tunnel0
The TE tunnel is up and running

2. Check whether the tunnel interface is configured to participate in SPF calculation.
[A1]disp current-configuration interface Tunnel 0
#
interface Tunnel0
destination 7.7.7.7
mpls
mpls te tunnel-id 1
mpls te loop-detection
mpls te record-route
mpls te bandwidth ct0 2000
mpls te commit
#
Return
The above output shows that tunnel interface is properly configured except that no ip address has been
configured for the interface. As a result, OSPF does not consider tunnel to route traffic.
You can also verify the same using the command display ip interface brief.
[A1]disp ip int brief
*down: administratively down
(s): spoofing
Interface Physical Protocol IP Address Description
LoopBack0 up up(s) 6.6.6.6 LoopBack0...
Serial0/2/0 up up 128.1.1.1 Serial0/2...
Tunnel0 up up unassigned Tunnel0 I...
Solution
Assign ip address to the tunnel interface.
[A1]int Tunnel 0
[A1-Tunnel0]ip add unnumbered interface LoopBack 0
[A1-Tunnel0]
Verification
Verify the flow of data.
[A1]disp ip routing-table
65
1.1.1.1/32 OSPF 10 3124 128.1.1.2 S0/2/0

2.2.2.2/32 OSPF 10 3124 128.1.1.2 S0/2/0
3.3.3.3/32 OSPF 10 3125 6.6.6.6 Tun0
4.4.4.4/32 OSPF 10 1562 128.1.1.2 S0/2/0
5.5.5.5/32 OSPF 10 1563 6.6.6.6 Tun0
6.6.6.6/32 Direct 0 0 127.0.0.1 InLoop0
7.7.7.7/32 OSPF 10 1 6.6.6.6 Tun0
10.1.1.2/32 OSPF 10 1 6.6.6.6 Tun0
10.1.1.3/32 OSPF 10 1 6.6.6.6 Tun0
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
128.1.1.0/30 Direct 0 0 128.1.1.1 S0/2/0
128.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
128.1.1.2/32 Direct 0 0 128.1.1.2 S0/2/0
129.1.1.0/30 OSPF 10 1563 6.6.6.6 Tun0
200.1.1.0/30 OSPF 10 3124 128.1.1.2 S0/2/0
200.1.1.4/30 OSPF 10 4686 128.1.1.2 S0/2/0
200.1.1.8/30 OSPF 10 3125 6.6.6.6 Tun0
---- More ----
As shown in the routing table, tunnel interface is now chosen as the out interface in the IP routing table.
Problem 2: Tunnel interface not configured to participate in

OSPF SPF calculation
By default, traffic is not routed through the tunnel established in a network. The tunnel interface must be
configured to participate in the enhanced SPF calculation. Also, the routing protocol must be enabled to
consider the tunnel for the enhanced SPF calculation. If any of the features are not enabled, then the
traffic does not get routed through the tunnel established. An example of a tunnel interface not
configured to participate in SPF calculation is shown in Figure 26.
66
Figure 26 Tunnel interface not configured to participate in SPF calculation
Lo: 1.1.1.1
P1
201.1.1.0/30
201.1.1.4/30
Lo: 4.4.4.4
Lo: 6.6.6.6 PE2 Lo: 7.7.7.7
PE1
128.1.1.0/30 129.1.1.0/30
Lo: 5.5.5.5
A1 A2
200.1.1.8/30
200.1.1.0/30
200.1.1.4/30
P2 P3
Lo: 2.2.2.2
Lo: 3.3.3.3
Problem
<A1>disp ip routing-table
1.1.1.1/32 OSPF 10 3124 128.1.1.2 S0/2/0

2.2.2.2/32 OSPF 10 3124 128.1.1.2 S0/2/0
3.3.3.3/32 OSPF 10 4686 128.1.1.2 S0/2/0
4.4.4.4/32 OSPF 10 1562 128.1.1.2 S0/2/0
5.5.5.5/32 OSPF 10 4686 128.1.1.2 S0/2/0
6.6.6.6/32 Direct 0 0 127.0.0.1 InLoop0
7.7.7.7/32 OSPF 10 6248 128.1.1.2 S0/2/0
10.1.1.2/32 OSPF 10 6248 128.1.1.2 S0/2/0
10.1.1.3/32 OSPF 10 6248 128.1.1.2 S0/2/0
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
128.1.1.0/30 Direct 0 0 128.1.1.1 S0/2/0
128.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
128.1.1.2/32 Direct 0 0 128.1.1.2 S0/2/0
129.1.1.0/30 OSPF 10 6248 128.1.1.2 S0/2/0
200.1.1.0/30 OSPF 10 3124 128.1.1.2 S0/2/0
200.1.1.4/30 OSPF 10 4686 128.1.1.2 S0/2/0
200.1.1.8/30 OSPF 10 6248 128.1.1.2 S0/2/0
---- More ----
The routing table of A1 does not show tunnel interface Tunnel 0 as the out interface for traffic destined
to tunnel.
67
Troubleshooting
1. Verify the status of TE tunnel.

6.6.6.6:16 7.7.7.7 -/S0/2/0 Tunnel0
Tunnel is up and running
<A1>disp current-configuration interface Tunnel 0

#
interface Tunnel0
destination 7.7.7.7
mpls
mpls te tunnel-id 1
mpls te commit
#
Return
The above output shows that the command mpls te igp shortcut is missing from the current configuration.
This means that tunnel is not participating in the enhanced SPF calculation.
Solution
Enable the tunnel interface to take part in the SPF calculation.
[A1]int Tunnel 0
[A1-Tunnel0]mpls te igp shortcut
Verification
Verify the flow of data.
[A1-Tunnel0]disp ip routing-table
1.1.1.1/32 OSPF 10 3124 128.1.1.2 S0/2/0

2.2.2.2/32 OSPF 10 3124 128.1.1.2 S0/2/0
3.3.3.3/32 OSPF 10 3125 6.6.6.6 Tun0
68
4.4.4.4/32 OSPF 10 1562 128.1.1.2 S0/2/0
5.5.5.5/32 OSPF 10 1563 6.6.6.6 Tun0
6.6.6.6/32 Direct 0 0 127.0.0.1 InLoop0
7.7.7.7/32 OSPF 10 1 6.6.6.6 Tun0
10.1.1.2/32 OSPF 10 1 6.6.6.6 Tun0
10.1.1.3/32 OSPF 10 1 6.6.6.6 Tun0
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
128.1.1.0/30 Direct 0 0 128.1.1.1 S0/2/0
128.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
128.1.1.2/32 Direct 0 0 128.1.1.2 S0/2/0
129.1.1.0/30 OSPF 10 1563 6.6.6.6 Tun0
200.1.1.0/30 OSPF 10 3124 128.1.1.2 S0/2/0
200.1.1.4/30 OSPF 10 4686 128.1.1.2 S0/2/0
200.1.1.8/30 OSPF 10 3125 6.6.6.6 Tun0
The traffic is now flowing through the established tunnel.
Problem 3: OSPF not configured to include the static LSP tunnel

in SPF calculation
An example of OSPF not configured to include the static LSP tunnel in SPF calculation is shown in Figure
27.
Figure 27 OSPF not configured to include the static LSP tunnel in SPF calculation
Lo: 1.1.1.1
P1
201.1.1.0/30
201.1.1.4/30
Lo: 4.4.4.4
Lo: 6.6.6.6 PE2 Lo: 7.7.7.7
PE1
128.1.1.0/30 129.1.1.0/30
Lo: 5.5.5.5
A1 A2
200.1.1.8/30
200.1.1.0/30
200.1.1.4/30
P2 P3
Lo: 2.2.2.2
Lo: 3.3.3.3
Problem
<A1>disp ip routing-table
69
1.1.1.1/32 OSPF 10 3124 128.1.1.2 S0/2/0

2.2.2.2/32 OSPF 10 3124 128.1.1.2 S0/2/0
3.3.3.3/32 OSPF 10 4686 128.1.1.2 S0/2/0
4.4.4.4/32 OSPF 10 1562 128.1.1.2 S0/2/0
5.5.5.5/32 OSPF 10 4686 128.1.1.2 S0/2/0
6.6.6.6/32 Direct 0 0 127.0.0.1 InLoop0
7.7.7.7/32 OSPF 10 6248 128.1.1.2 S0/2/0
10.1.1.2/32 OSPF 10 6248 128.1.1.2 S0/2/0
10.1.1.3/32 OSPF 10 6248 128.1.1.2 S0/2/0
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
128.1.1.0/30 Direct 0 0 128.1.1.1 S0/2/0
128.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
128.1.1.2/32 Direct 0 0 128.1.1.2 S0/2/0
129.1.1.0/30 OSPF 10 6248 128.1.1.2 S0/2/0
200.1.1.0/30 OSPF 10 3124 128.1.1.2 S0/2/0
200.1.1.4/30 OSPF 10 4686 128.1.1.2 S0/2/0
200.1.1.8/30 OSPF 10 6248 128.1.1.2 S0/2/0
201.1.1.0/30 OSPF 10 3124 128.1.1.2 S0/2/0
201.1.1.4/30 OSPF 10 4686 128.1.1.2 S0/2/0
The routing table of A1 does not show tunnel interface Tunnel0 as the out interface for traffic destined to
tunnel.
Troubleshooting
1. Check whether tunnel is up.

6.6.6.6:16 7.7.7.7 -/S0/2/0 Tunnel0
The TE tunnel is up and running.
<A1>disp current-configuration int Tunnel 0

#
interface Tunnel0
destination 7.7.7.7
mpls
70
mpls te tunnel-id 1
mpls te tie-breaking random
mpls te reoptimization
mpls te commit
#
Return
Tunnel interface is properly configured.

3. Check the OSPF configuration on A1 to verify whether IGP shortcut is enabled under OSPF view.
<A1>disp current-configuration configuration ospf
#
ospf 1
opaque-capability enable
area 0.0.0.0
network 128.1.1.0 0.0.0.3
network 6.6.6.6 0.0.0.0
mpls-te enable
#
Return
The command enable traffic-adjustment is not configured under OSPF view. This command is essential to
enable the IGP shortcut feature configured on the tunnel interface. Since IGP shortcut is not enabled,
OSPF does not include static LSP tunnel in SPF calculation.
Solution
Configure the command enable traffic-adjustment under ospf view of router A1.
[A1]ospf 1
[A1-ospf-1]enable traffic-adjustment
Verification
Verify the IP routing table.
[A1]disp ip routing-table
1.1.1.1/32 OSPF 10 3124 128.1.1.2 S0/2/0

2.2.2.2/32 OSPF 10 3124 128.1.1.2 S0/2/0
3.3.3.3/32 OSPF 10 3324 6.6.6.6 Tun0
4.4.4.4/32 OSPF 10 1562 128.1.1.2 S0/2/0
5.5.5.5/32 OSPF 10 1762 6.6.6.6 Tun0
6.6.6.6/32 Direct 0 0 127.0.0.1 InLoop0
7.7.7.7/32 OSPF 10 200 6.6.6.6 Tun0
71
10.1.1.2/32 OSPF 10 200 6.6.6.6 Tun0
10.1.1.3/32 OSPF 10 200 6.6.6.6 Tun0
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
128.1.1.0/30 Direct 0 0 128.1.1.1 S0/2/0
128.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
128.1.1.2/32 Direct 0 0 128.1.1.2 S0/2/0
129.1.1.0/30 OSPF 10 1762 6.6.6.6 Tun0
200.1.1.0/30 OSPF 10 3124 128.1.1.2 S0/2/0
200.1.1.4/30 OSPF 10 4686 128.1.1.2 S0/2/0
200.1.1.8/30 OSPF 10 3324 6.6.6.6 Tun0
Traffic is now being routed through the tunnel.
MPLS TE Traffic not tunneled through the desired

path
This problem occurs if the explicit path defined is invalid or the preference for the desired path is lower
than the other path or the router along the explicit path is not reachable.
Problem 1: Explicit path has lower preference

The lower the number, the higher the preference is. If any path is defined with a preference of 1, then it
has the highest priority over other paths. A path with a preference of 2 is chosen when the path
preference 1 is unavailable.
An example of explicit path configured with lower preference is shown in Figure 28.
Figure 28 Explicit path has lower preference
Lo: 1.1.1.1
P1
201.1.1.0/30
201.1.1.4/30
Lo: 4.4.4.4
Lo: 6.6.6.6 PE2 Lo: 7.7.7.7
PE1
128.1.1.0/30 129.1.1.0/30
Lo: 5.5.5.5
A1 A2
200.1.1.8/30
200.1.1.0/30
200.1.1.4/30
P2 P3
Lo: 2.2.2.2
Lo: 3.3.3.3
Problem
Tunnel not established on desired path.
72
[A1]disp mpls te tunnel path
Tunnel Interface Name : Tunnel0
Lsp ID : 6.6.6.6 :2
Hop Information
Hop 0 128.1.1.1
Hop 1 128.1.1.2
Hop 2 4.4.4.4
Hop 3 201.1.1.1
Hop 4 201.1.1.2
Hop 5 1.1.1.1
Hop 6 201.1.1.5
Hop 7 201.1.1.6
Hop 8 5.5.5.5
Hop 9 129.1.1.2
Hop 10 129.1.1.1
Hop 11 7.7.7.7
In this scenario, the desired tunnel path is through p2-p3 router. Instead the path chosen for the tunnel
establishment is through P1.
Troubleshooting
1. Check whether any explicit path has been configured on Router A1.
[A1]disp explicit-path
Path Name : p2-p3 Path Status : Enabled
1 128.1.1.2 Strict Include
The explicit path has been rightly configured.

2. Check whether the tunnel interface has been directed to use this explicit path.
[A1]disp current-configuration interface Tunnel 0

#
interface Tunnel0
destination 7.7.7.7
mpls
mpls te tunnel-id 1
73
mpls te priority 1
mpls te commit
#
Return
In the configuration on Router A1, dynamic path has the top-most priority than the explicit path
configured. As a result, even though tunnel interface has been directed to use explicit-path p2-p3, it does
not choose that path. Instead dynamic path is chosen as it has highest priority.
Solution
Change the preference of explicit-path p2-p3 to 1 and dynamic path to 2.
[A1]int Tunnel 0
[A1-Tunnel0]undo mpls te path dynamic
[A1-Tunnel0]undo mpls te path explicit-path p2-p3
[A1-Tunnel0]mpls te path explicit-path p2-p3 preference 1
[A1-Tunnel0]mpls te path dynamic preference 2
Verification
Check the path selected by the tunnel.
Lsp ID : 6.6.6.6 :3
Hop Information
Hop 0 128.1.1.1
Hop 1 128.1.1.2
Hop 2 4.4.4.4
Hop 3 200.1.1.1
Hop 4 200.1.1.2
Hop 5 2.2.2.2
Hop 6 200.1.1.5
Hop 7 200.1.1.6
Hop 8 3.3.3.3
Hop 9 200.1.1.9
Hop 10 200.1.1.10
Hop 11 5.5.5.5
Hop 12 129.1.1.2
Hop 13 129.1.1.1
Hop 14 7.7.7.7
The tunnel is now established over p2-p3.
Problem 2: Intermediate router or link down

An example of intermediate router or link down is shown in Figure 29.
74
Figure 29 Intermediate router or link down
Lo: 1.1.1.1
P1
201.1.1.0/30
201.1.1.4/30
Lo: 4.4.4.4
Lo: 6.6.6.6 PE2 Lo: 7.7.7.7
PE1
128.1.1.0/30 129.1.1.0/30
Lo: 5.5.5.5
A1 A2
200.1.1.8/30
200.1.1.0/30
200.1.1.4/30
P2 P3
Lo: 2.2.2.2
Lo: 3.3.3.3
Problem
MPLS TE traffic not tunneled through the desired path.
Lsp ID : 6.6.6.6 :5
Hop Information
Hop 0 128.1.1.1
Hop 1 128.1.1.2
Hop 2 4.4.4.4
Hop 3 201.1.1.1
Hop 4 201.1.1.2
Hop 5 1.1.1.1
Hop 6 201.1.1.5
Hop 7 201.1.1.6
Hop 8 5.5.5.5
Hop 9 129.1.1.2
Hop 10 129.1.1.1
Hop 11 7.7.7.7
Tunnel is established over P1 router, whereas desired path is through routers P2 and P3.
Troubleshooting
1. Check the explicit path configured.
Explicit path configured is valid.
75
2. Check the configuration of Tunnel interface to verify whether explicit path is configured to carry
tunneled routes.
[A1]disp current-configuration interface tunnel 0

#
interface Tunnel0
destination 7.7.7.7
mpls
mpls te tunnel-id 1
mpls te timer retry 10
mpls te priority 1
mpls te fast-reroute
mpls te commit
#
return
Here, explicit path has been given the highest preference, yet in our example this path is not getting
selected for the formation of tunnel.
3. Check the connectivity from router A1 to router P2 and P3, which are the intermediate routers lying
along the way of desired tunnel path.
Ping each interface to check the connectivity.
In this example, A1 is receiving successful ping reply from ip 200.1.1.2, which is the link connecting P2
to PE1.
Now check the link connecting P2 and P3.
[A1]ping 200.1.1.5
PING 200.1.1.5: 56 data bytes, press CTRL_C to break
Request time out
Request time out
Request time out
Request time out
Request time out
--- 200.1.1.5 ping statistics ---
76
100.00% packet loss
Router A1 is not receiving successful ping replies from the IP 200.1.1.5, which means that this interface
is down.
Find out the problem that has caused this interface to go down.
Various possible reasons for a link to be down are:
• Bad cable.
• Unplugged cable.
• Interface administratively down.
Find and correct the apparent cause of the problem.

In the above example, the interface se 0/2/0 of P3 router is administratively down, which has caused
this problem.
Solution
Unshut the interface se 0/2/0 on router P3.
[P3]int se 0/2/0
[P3-Serial0/2/0]undo shut
Verification
Verify the tunnel path

Lsp ID : 6.6.6.6 :6
Hop Information
Hop 0 128.1.1.1
Hop 1 128.1.1.2
Hop 2 4.4.4.4
Hop 3 200.1.1.1
Hop 4 200.1.1.2
Hop 5 2.2.2.2
Hop 6 200.1.1.5
Hop 7 200.1.1.6
Hop 8 3.3.3.3
Hop 9 200.1.1.9
Hop 10 200.1.1.10
Hop 11 5.5.5.5
Hop 12 129.1.1.2
Hop 13 129.1.1.1
Hop 14 7.7.7.7
77
Now the tunnel is traversing through P2 and P3.
Problem 3: Intermediate router not participating in MPLS TE

An example of intermediate router not participating in MPLS TE is shown in Figure 30.
Figure 30 Intermediate router not participating in MPLS TE
Lo: 1.1.1.1
P1
201.1.1.0/30
201.1.1.4/30
Lo: 4.4.4.4
Lo: 6.6.6.6 PE2 Lo: 7.7.7.7
PE1
128.1.1.0/30 129.1.1.0/30
Lo: 5.5.5.5
A1 A2
200.1.1.8/30
200.1.1.0/30
200.1.1.4/30
P2 P3
Lo: 2.2.2.2
Lo: 3.3.3.3
Problem
MPLS TE traffic not tunneled through the desired path.
<A1>disp mpls te tunnel path
Lsp ID : 6.6.6.6 :8
Hop Information
Hop 0 128.1.1.1
Hop 1 128.1.1.2
Hop 2 4.4.4.4
Hop 3 201.1.1.1
Hop 4 201.1.1.2
Hop 5 1.1.1.1
Hop 6 201.1.1.5
Hop 7 201.1.1.6
Hop 8 5.5.5.5
Hop 9 129.1.1.2
Hop 10 129.1.1.1
Hop 11 7.7.7.7
MPLS tunnel has been established over router P1 instead of router P2 and P3.
Troubleshooting
1. Check the explicit path configured.
78
Explicit path configured is valid.
2. Check the configuration of tunnel interface to verify whether explicit path is configured to carry
tunneled routes.
[A1]disp current-configuration interface tunnel 0

#
interface Tunnel0
destination 7.7.7.7
mpls
mpls te tunnel-id 1
mpls te timer retry 10
mpls te priority 1
mpls te fast-reroute
mpls te commit
#
return
3. Check the connectivity from router A1 to the intermediate routers P2 and P3.
In this example, router A1 is receiving successful ping replies from both the routers.
4. Check whether MPLS, MPLS TE, and RSVP are enabled on the intermediate routers.
On checking the configuration of router P2 and P3, it is found that interface se 0/2/0 of P2 is not
enabled to support MPLS TE feature. As a result, tunnel was not getting established over the desired
path.
[P2]disp current-configuration interface serial 0/2/0

#
link-protocol ppp
ip address 200.1.1.2 255.255.255.252
mpls
#
79
Solution
Enable MPLS TE on se 0/2/0 of router P2.
[P2]int se 0/2/0
[P2-Serial0/2/0]mpls te
[P2-Serial0/2/0]mpls rsvp-te
Verification
Verify the tunnel path
Lsp ID : 6.6.6.6 :8
Hop Information
Hop 0 128.1.1.1
Hop 1 128.1.1.2
Hop 2 4.4.4.4
Hop 3 200.1.1.1
Hop 4 200.1.1.2
Hop 5 2.2.2.2
Hop 6 200.1.1.5
Hop 7 200.1.1.6
Hop 8 3.3.3.3
Hop 9 200.1.1.9
Hop 10 200.1.1.10
Hop 11 5.5.5.5
Hop 12 129.1.1.2
Hop 13 129.1.1.1
Hop 14 7.7.7.7
Now the tunnel is traversing through P2 and P3.
80

Troubleshooting MPLS HP

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Troubleshooting MPLS HP

Uploaded by

Copyright:

Available Formats

MPLS Troubleshooting Guide

Part number: 5998-4232

MPLS LDP peer relationship not established

Steps to troubleshoot “MPLS LDP peer not established”

Problem 1: MPLS not enabled on router

R1 is not showing R2 as its LDP neighbor.

MPLS is enabled for Gi 0/0/0 interface of R1 connecting R2.

LDP Peer Information in Public network

R1 has established LDP peer relationship with R2 successfully.

Problem 2: LDP not enabled on Router

MPLS has been enabled on the interfaces of both R1 and R2.

LDP Interface Information in Public Network

LDP Peer Information in Public network

R1 has formed LDP peer relation with R2.

Problem 3: MPLS not enabled on interface

LDP Peer Information in Public network

R1 has not established LDP peer relationship with R5

LDP Interface Information in Public Network

LDP Interface Information in Public Network

R1 shows only one interface with LDP enabled.

LDP Peer Information in Public network

R1 has formed successful LDP peer relation with R5.

Problem 4: LDP not enabled on interface

LDP Peer Information in Public network

R1 has not formed LDP peer relation with R5.

LDP Interface Information in Public Network

LDP Peer Information in Public network

LDP Peer Information in Public network

R1 has formed LDP peer with R5 and not R2.

LDP Interface Information in Public Network

LDP Interface Information in Public Network

MPLS LDP session not established

Steps to troubleshoot “MPLS LDP Peer Session Not Established”

Problem 1: LSR-ID of the peer is not reachable

LDP Session(s) in Public Network

LDP Peer Information in Public network

The transport address is same as the LSR-id.

--- 5.5.5.5 ping statistics ---

Destination/Mask Proto Pre Cost NextHop Interface

1.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0

As you can see, Router R5 is not configured to advertise 5.5.5.5/32 network.

LDP Session(s) in Public Network

Problem 2: No route available to reach LDP LSR-id

LDP Session(s) in Public Network

The LDP session is shown to be Initialized for peer R2.

LDP Session(s) in Public Network

Destination/Mask Proto Pre Cost NextHop Interface

1.1.1.1/32 OSPF 10 1 192.168.1.1 GE0/0/0

LDP Peer Information in Public network

The transport address for peer is 10.10.10.10

LDP Interface Information

LDP Session(s) in Public Network

LDP Session(s) in Public Network

Problem 3: LDP authentication enabled on one router and

LDP Session(s) in Public Network

LDP Session(s) in Public Network

LDP Session(s) in Public Network

Problem 3: Router not advertising specific FEC in MPLS domain

Destination/Mask Proto Pre Cost NextHop Interface

1.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0

<R1>ping lsp -a 1.1.1.1 ipv4 192.168.4.0 24

--- FEC: LDP IPV4 PREFIX 192.168.4.0/24 ping statistics ---

Problem 4: Specific FEC being blocked or filtered

R8 has the entry for 200.1.x.x FECs in its LFIB table.