From: Victor Cappuccio (victor@ccbootcamp.com)
Date: Mon Apr 23 2007 - 16:02:06 ART
http://www.cisco.com/warp/public/105/troubleshoot_mpls_vpn.html
Problem
The connectivity between CE1 and the loopback interface of CE2 has been lost,
as shown in the following example.
CE1#ping 192.168.1.196
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.196, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
However, CE1 has a valid routing entry for this destination, as shown in the
following example.
CE1#show ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
Known via "static", distance 1, metric 0, candidate default path
Redistributing via ospf 100
Routing Descriptor Blocks:
* 10.1.1.2
Route metric is 0, traffic share count is 1
At PE1 (the PE router attached to CE1), you can check MPLS VPN specific
information. The following examples show that a valid route to the destination
is present in the VRF table for this VPN.
PE1#show ip route vrf aqua 192.168.1.196
Routing entry for 192.168.1.192/26
Known via "bgp 1", distance 200, metric 1, type internal
Last update from 10.5.5.5 00:09:52 ago
Routing Descriptor Blocks:
* 10.5.5.5 (Default-IP-Routing-Table), from 10.5.5.5, 00:09:52 ago
Route metric is 1, traffic share count is 1
AS Hops 0, BGP network version 0
PE1#show tag-switching forwarding-table vrf aqua 192.168.1.196 detail
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
None 16 192.168.1.192/26 0 Et2/0/2 10.7.7.7
MAC/Encaps=14/22, MTU=1496, Tag Stack{16 32}
00603E2B02410060835887428847 0001000000020000
No output feature configured
PE1#show ip bgp vpnv4 vrf aqua 192.168.1.192
BGP routing table entry for 100:1:192.168.1.192/26, version 43
Paths: (1 available, best #1, table aqua)
Not advertised to any peer
Local
10.5.5.5 (metric 21) from 10.5.5.5 (10.5.5.5)
Origin incomplete, metric 1, localpref 100, valid, internal, best
Extended Community: RT:1:1
PE1#show tag-switching forwarding-table 10.5.5.5 detail
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
18 16 10.5.5.5/32 0 Et2/0/2 10.7.7.7
MAC/Encaps=14/18, MTU=1500, Tag Stack{16}
00603E2B02410060835887428847 00010000
No output feature configured
Per-packet load-sharing, slots: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
As shown in this example, PE1 does not have a route for the BGP next hop with
the correct mask.
PE1#
PE1#show ip route 10.5.5.5 255.255.255.0
% Subnet not in table
PE1#show ip route 10.5.5.5 255.255.255.255
Routing entry for 10.5.5.5/32
Known via "ospf 1", distance 110, metric 21, type intra area
Last update from 10.7.7.7 on Ethernet2/0/2, 00:38:55 ago
Routing Descriptor Blocks:
* 10.7.7.7, from 10.5.5.5, 00:38:55 ago, via Ethernet2/0/2
Route metric is 21, traffic share count is 1
The IGP routing information used by PE1 to reach this BGP next hop is received
from the P router. As shown in the following example, this router also shows
an incorrect mask for the PE2 loopback and does not have a route for this
prefix with the correct mask.
P#show ip route 10.5.5.5
Routing entry for 10.5.5.5/32
Known via "ospf 1", distance 110, metric 11, type intra area
Last update from 10.8.8.5 on Ethernet2/0, 00:47:48 ago
Routing Descriptor Blocks:
* 10.8.8.5, from 10.5.5.5, 00:47:48 ago, via Ethernet2/0
Route metric is 11, traffic share count is 1
P#show ip route 10.5.5.5 255.255.255.0
% Subnet not in table
Cause of the LSP Failure
The LFIB and tag bindings on the P router show the cause of the LSP failure
between this router and PE2. There is no outgoing label for 10.5.5.5. When the
packet leaves PE1 it carries two labels, the BGP next hop label generated by
the P router (16) and the VPN label generated by PE2 (32). Because this entry
on the P router shows untagged, label-switched packets for this destination,
it will be sent out without any labels. Since the VPN label 32 was lost, it
will never be received by PE2, and PE2 will not have the correct information
to forward the packet to the proper VPN destination.
P#show tag-switching forwarding-table 10.5.5.5 detail
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
16 Untagged 10.5.5.5/32 5339 Et2/0 10.8.8.5
MAC/Encaps=0/0, MTU=1504, Tag Stack{}
No output feature configured
Per-packet load-sharing, slots: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
As shown in the following example, the label binding table of the P router
shows that PE2 (tsr: 10.8.8.5:0) only advertises a binding for 10.5.5.5 with a
/24 mask. A label for the /32 route is advertised by the P router and PE1
(tsr: 10.2.2.2:0), but not PE2. Because the binding advertised by PE2 does not
match the route it also advertises, no label is present in the LFIB of the P
router to forward packets to this destination.
P#show tag-switching tdp bindings detail
tib entry: 10.5.5.0/24, rev 67(no route)
remote binding: tsr: 10.8.8.5:0, tag: imp-null
tib entry: 10.5.5.5/32, rev 62
local binding: tag: 16
Advertised to:
10.2.2.2:0 10.8.8.5:0
remote binding: tsr: 10.2.2.2:0, tag: 18
The reason for the discrepancy between the routing updates and label bindings
advertised by PE2 can be seen in the routing table and tag binding table of
this router. The directly connected loopback shows the correct /24 mask, this
is used by the router in generating the label binding. Because this network
uses Open Shortest Path First (OSPF), the router advertises this interface
with a /32 mask, as shown in the following example.
PE2#show ip route 10.5.5.5
Routing entry for 10.5.5.0/24
Known via "connected", distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via Loopback0
Route metric is 0, traffic share count is 1
PE2#show tag-switching tdp bindings detail
tib entry: 10.5.5.0/24, rev 142
local binding: tag: imp-null
Advertised to:
10.7.7.7:0
tib entry: 10.5.5.5/32, rev 148
remote binding: tsr: 10.7.7.7:0, tag: 16
PE2#show ip ospf interface loopback 0
Loopback0 is up, line protocol is up
Internet Address 10.5.5.5/24, Area 0
Process ID 1, Router ID 10.5.5.5, Network Type LOOPBACK, Cost: 1
Loopback interface is treated as a stub Host
!--- OSPF advertises all interfaces of Network Type LOOPBACK as host
!--- routes (/32).
thanks,
Victor Cappuccio.-
Network Learning Inc - A Cisco Sponsored Organization (SO) YES! We take
Cisco Learning credits!
victor@ccbootcamp.com
http://www.ccbootcamp.com (Cisco Training and Rental Racks)
http://www.ccbootcamp.com/groupstudy.html (groupstudy member discounts!)
Voice: 702-968-5100
FAX: 702-446-8012
-----Original Message-----
From: Iamgoingtobeaccie Iamgoingtobeaccie
[mailto:heyiamgoingtobeaccie@yahoo.co.in]
Sent: Mon 4/23/2007 11:59
To: Victor Cappuccio; ccielab@groupstudy.com
Subject: RE: MPLS [mx][html-rem]
Thanks Victor. You are right..but in this case R1 is not an egress router.Its
a P router which is directly connected to R5(whose loopback is 5.5.5.5 and its
another P router).Since 5.5.5.5 is directly connected to R5,R5 should be
sending a Implicit null tag to R1.But when the network is advertised as /32,R5
is neither sending the implicit tag nor a label to R1.So its untagged in R1's
Lfib.But when R5's loopback is advertised as /24, an implicit tag is sent to
R1 by R5 and hence R1's LFIB has a POP tag for 5.5.5.0/24.
Could not understand why there is a difference.Will work on it in the
morning.. I am almost falling from the chair.
Victor Cappuccio <victor@ccbootcamp.com> wrote: Hi,
This is what I understand about those 2 actions in the LFIB
Untagged means the packet will be forwarded out the given interface as IP
packet (0x0800). The Pop tag mean that the penultimate router labels the
packet with the null label (label 3). Is an Egress LSR know now that it
should not process the packet as a labeled packet, the packet should be
treated as a ip packet.
thanks,
Victor Cappuccio.-
Network Learning Inc - A Cisco Sponsored Organization (SO) YES! We take
Cisco Learning credits!
victor@ccbootcamp.com
http://www.ccbootcamp.com (Cisco Training and Rental Racks)
http://www.ccbootcamp.com/groupstudy.html (groupstudy member discounts!)
Voice: 702-968-5100
FAX: 702-446-8012
-----Original Message-----
From: nobody@groupstudy.com on behalf of Iamgoingtobeaccie Iamgoingtobeaccie
Sent: Mon 4/23/2007 11:22
To: ccielab@groupstudy.com
Subject: MPLS
Group,
Do we have a separate list for CCIE-SP??I did subscribe to
CS,but there is no response to it.
I have a basic MPLS topology with OSPF as the IGP.If I
adverise the loopbacks with their default network type,their /32 network is
not being assigned labels.(Untagged) When I change the network type to
point-to-point,i see pop-tag is attached in the "show mpls forwarding" command
which is expected.
Is there a problem with Implicit null tag for /32 networks here.
R1#sh mpls for
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
43 Untagged 5.5.5.5/32 0 Et0/0 190.1.18.5
R1#sh mpls for
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
41 Pop tag 5.5.5.5//24 0 Et0/0 190.1.18.5
---------------------------------
Check out what you're missing if you're not on Yahoo! Messenger
This archive was generated by hypermail 2.1.4 : Tue May 01 2007 - 08:28:37 ART