Mpls vpn routing problem!

[v.matiakis]

Hi,

I have 2 mpls vpns. These 2 both receive routes from a route-target. Let's say that there is vpn_A and vpn_B. in show ip route vrf .. command both show a bgp route pointing to a router that has the subnet connected. But in vpn_A the show mpls forwarding-table vrf .. command does not show any labels or a next hop router :

Local Outgoing Prefix Bytes tag Outgoing Next Hop

tag tag or VC or Tunnel Id switched interface

None Recursive 192.168.199.0/24 0 .In vpn_B a label and a next hop router exist. Should i add a static route for the vrf pointing to the next hop?

[v.matiakis]

i get this result from the show ip vrf

show ip cef vrf vpn_A 192.168.199.0 det

192.168.199.0/24, version 26, epoch 0

0 packets, 0 bytes

tag information set, all rewrites owned

local tag: VPN-route-head

fast tag rewrite with

Recursive rewrite via xx.xx.xx.4/32, tags imposed {2981}

via xx.xx.xx.4, 0 dependencies, recursive

next hop xx.xx.xx.190, GigabitEthernet9/10 via xx.xx.xx.4/32 (Default)

valid adjacency

tag rewrite with

Recursive rewrite via xx.xx.xx.4/32, tags imposed {2981}

Recursive load sharing using xx.xx.xx.4/32.

And from another router that the same mpls vpn works just fine i get the following result :

show ip cef vrf vpn_A 192.168.199.0 det

192.168.199.0/24, epoch 18

recursive via xx.xx.xx.4 label 2981

nexthop xx.xx.xx.45 GigabitEthernet4/24 label 18857.

The neighbor P to the first problematic router is a CRS-1

[mheusing]

Hi,

There is nothing problematic here, afaik.

Both routers use the same label - 2981 - the VPN label and this is fine.

As I wrote, you might have more than one path to the destination, which then is indicated by "Recursive load sharing using xx.xx.xx.4/32". show ip cef xx.xx.xx.4/32 should give you the LDP labels used for reaching the outgoing PE, where 192.168.199.0/24 is found.

You can also check the label stack in use by "traceroute vrf VPN_A 192.168.199.y" where y is a reachable host IP.

The first hop should show you the labels your PE is using to reach the destination.

So no worries, everything is fine - assuming you have reachability.

Please rate all posts.

Regards, Martin

[v.matiakis]

The target vrf has a public ip which is routable in the network from a redistributed static route. From the problematic router this ip does not have a tag :

router1#show mpls forwarding-table vrf vpn_A xx.xx.xx.242

Local Outgoing Prefix Bytes tag Outgoing Next Hop

tag tag or VC or Tunnel Id switched interface

None Recursive xx.xx.xx.240/30 0

and the working router :

router2#show mpls forwarding-table vrf vpn_A xx.xx.xx.242

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or VC or Tunnel Id Switched interface

None 593 xx.xx.xx.240/30[V] \

0 Gi4/24 xx.xx.xx.45.

Traceroute fails from the beginning.

[mheusing]

Hi,

Traceroute fails? You mean traceroute from within the VRF to the public destination? Is there no connectivity at all? Or is only traceroute not working? If you have connectivity to the internet, but traceroute fails: That might just mean everything is fine :-)

Let me explain my "wierd" statement.

Traceroute in a MPLS VPN environment is a little tricky.

To send a packet across the MPLS core from a VRF, two labels are needed, top label to send to the BGP next hop, bottom label is VPN label. A P router discarding this packet with labelstack, will create an ICMP "TTL expired in transit" packet. The question is, how to send it back to the originating host. As a P router does not have customer routes any direct delivery of the ICMP packet is impossible. Thus the ICMP packet is sent further on through the same LSP (label switched path) as the original discarded IP packet. This means, that the ICMP reply of a P router will travel to the remote CE, who does an IP lookup and sends it back. You can easily verify this with an access-list denying all ICMP packets in at the remote CE in a lab environment. This will discard the ICMP packets from the core and thus every core/P router will show up as "*" in your traceroute output.

In your case there might be a firewall preventing the "ICMP TTL expired" packetsto get back to the originating PE.

Hope this helps! Please rate all posts.

Regards, Martin

[v.matiakis]

traceroute fails within the vrf :

traceroute vrf vpn_A 192.168.199.11

Type escape sequence to abort.

Tracing the route to 192.168.199.11

1 * * *

2 * * *

3 * * *

4 * * *

5 * * *

6 * * *

7 * * *

8 * * *

9 * * *

10 * * *

11 * * *

12 * * *

13 * * *

14 * * *

15 * * *

16 * * *

17 * * *

18 * * *

19 * * *

20 * * * .

I can trace within tha same vrf. This address is from another vrf from which the routes are imported in the vpn_A routing table!

[mheusing]

Hi,

Are all connected networks announced to the respective VRFs? Could be that either source or destination IPs are not routed. Is there any connectivity across the VRFs or is only traceroute affected? If no connectivity exists, check your VRF routing tables, if all required networks are inserted and if so, troubleshoot the intermediate MPLS network first.

Without further information regarding your configurations and topology it is very difficult to give a more specific answer.

Hope this helps! Please rate all posts.

Regards, Martin

[v.matiakis]

Problem is solved. I had overlapping ip adresses in a forgotten vrf and the BGP selected the old vrf as the best way.. Thanx for all the responses i had the chance to make troubleshooting a little more advanced. It is always nice to know that support is always available from the cisco society!

thanx