Not all Prefixes in VRF Tables are Reachable?

[Greg Focaccio]

Hello,

During my studies with an MPLS VPN [MP-BGP] lab I found something unexpected.  I wonder if I am mistaken in my comprehension or if this normal:

Not all prefixes in a VRF Table are pingable/reachable ?

Seems that in the standard routing tables, if a prefix is there, then it is pingable/reachable.

I've attached a sketch to help illustrate the lab I have set up and what I found.

Below is output from ABR2 in the lab showing inability to ping 154.0.0.154, even though it is in the VRF IT table.  After "mpls ip" is configured on the "*" interface of Core2 the LDP Adjacency between Core2 and ABR2 comes up and ABR2 can ping everything in the VRF IT table, including 154.0.0.154

Just seems like this is a "Gotcha" for one just coming into the world of MPLS VPN.  Just because a Prefix is in the VRF Table does not mean it is reachable?

Thanks for any input.

[Muhammad Thanveer]

Have you kept the network address of the interfaces(atttached one and the loopback if any) which are in vrf in to address family ipv4 vrf IT

Or simply you can do is redistribute connected.

check with the below outputs

sh ip route vrf IT in all the switches (check whether connected interface network address are coming or not?)

sh bgp vpnv4 uni all summ (Check whether all the intended prefixes are coming or not?)

check whether your route-targets are properly exported and imported or not?

Regards
Thanveer
"Everybody is genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is a stupid."

[blau grana · Accepted solution]

Hello Greg,

Behavior which you have experienced is completly normal in MPLS environment. There is big difference between forwarding IP packets and MPLS frames.

If you disable "mpls ip" on some interface along your LSP, LSP is broken and traffic is lost. MPLS VPN packets have two labels:

- IGP label - according this label, packet is forwarded from ingress PE to egress PE

- VPN label - based on this label, egress PE can put packet to particular VRF

VPN label is known only to ingress and egress PE, if LSP is broken, IGP label is stripped off in the middle of the LSP and packet is forwarded based on VPN label. But as I said, intermediate routers do not know what to do with this packet, because label is unknow to them so packet is discarded.

I hope this cleared some things for you.

To further studies I would recommend this book:

http://www.ciscopress.com/store/mpls-fundamentals-9781587051975

Best Regards

Please rate all helpful posts and close solved questions

[Muhammad Thanveer]

Good explanation Blau Grana,

Regards
Thanveer
"Everybody is genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is a stupid."

[Greg Focaccio]

Awesome explaination.  That is what I was thinking, but wanted to get validation.

So now, how does one best trouble-shoot a reachability issue? 

Does one have to go all along the LSP checking that LDP Adjacencies are up?

[Muhammad Thanveer · Accepted solution]

Hello Greg,

The way I troubleshoot is,

I will first check the ldp adjacency with in the mpls network.

When the matter comes to vpnv4 routes I will check the prefixes by show bgp vpnv4 uni all summ at PE.

It again depends upon the PE to CE protocol and its redistribution.

then I will check for the sh ip router vrf (vrf name) at PE. I must be able to see all the routes including the one which are connected.

If I recieve all the routes at PE and then I am unable see them at CE then I check the vrf definition for wrongly imported rt.

and the network command at PE in bgp ipv4 address family mask should be exactly matched.

Blau if you have better trouble shooting tips, please share it.

Regards
Thanveer
"Everybody is genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is a stupid."

[blau grana · Accepted solution]

Hello Greg,

Best way to troubleshoot is step-by-step checking LSP path, verifying LFIB and CEF if routers has correct labels. You can not have in intermediate routers outgoing label mark as untagged -> all labels will be stripped and packet will be forwarded based on IP.

If you do have allowed TTL propagation in your MPLS network (by default it is allowed) you can start troubleshooting by tracerouting between ingress and egress PEs loopbacks which are used as next-hop for VPN traffic. You can see in output hops along LSP and also assigned labels.

http://blog.ipexpert.com/2009/11/25/mpls-ip-ttl-propagation/

Do not forget that LSP is unidirectional, so you have to check LSP in both directions!!!

Best Regards

Please rate all helpful posts and close solved questions

[Greg Focaccio]

Thanks blau grana,

Great suggestions.  It seems like with a complex network having to check every LDP adjacency along the entire LSP would not be feasible.

I've started a new discussion here: https://supportforums.cisco.com/thread/2212675 to see if LDP-IGP synchronization can provide dynamic fault tolerance in the MPLS VPN network scenario under consideration.

[Giuseppe Larosa]

Hello Greg,

nice to see you again in the forums

MPLS has a distinct signalling plane (routing protocols, LDP and RSVP-TE) and forwarding plane, like it is in ATM for example.

The fact that routes are visilble in VRF routing table just means that MP BGP sessions are up and running and the correct route targets are exported and imported in the various PE nodes, but it does not provide any guarantee about the forwarding plane status.

Hope to help

Giuseppe

[Muhammad Thanveer]

Good info Giuseppe Larosa,

Thanks for sharing.

Regards
Thanveer
"Everybody is genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is a stupid."