MPLS vpn's

Hi all,

I am having a really hard time getting my head around MPLS vpns. Unfortunally theres not too much about it in the exam certification guide, what have you all used to figure it all out? links/books etc.

Also, I have managed to get two PE routers to exchange routes into their respective VRF's (vrf0001), but for some reason i cant ping from one customer from one end to the other.

(PE1) <--> (PE2):

VRF0001 on PE1:

Gateway of last resort is not set

1.0.0.0/24 is subnetted, 1 subnets
C 1.1.1.0 is directly connected, Loopback0
7.0.0.0/24 is subnetted, 1 subnets
C 7.7.7.0 is directly connected, FastEthernet1/0
10.0.0.0/24 is subnetted, 1 subnets
B 10.10.10.0 [200/0] via 192.168.24.4, 00:20:04
R1#

VRF0001 on PE2:

1.0.0.0/24 is subnetted, 1 subnets
B 1.1.1.0 [200/0] via 192.168.12.1, 00:20:23
7.0.0.0/24 is subnetted, 1 subnets
B 7.7.7.0 [200/0] via 192.168.12.1, 00:17:53
10.0.0.0/24 is subnetted, 1 subnets
C 10.10.10.0 is directly connected, Loopback0

I have even setup up a "client" to R1 (the 7.7.7.0/24 link), and tried pinging, but still no dice.

Any ideas?

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

cowood2676

This is exactly why I despise VRF. I think of it as seperate vlans by default you cannot ping from one vlan interface to another. Once you put the network into the VRF you have isolated it, It is not global anymore it belongs to vrf. Turn VRF off and you will be able to ping just fine. Cisco says that vrf selection is unidirectional.

MPLS VPN - VRF Selection based on Source IP Address [Layer 3 VPNs] - Cisco Systems

networker050184

Not enough information provided to help. I could guess, but some configs and a diagram would be beneficial.

Sepiraph

You are using 'ping vrf WORD address' right?

kryolla

Sepiraph wrote: »

You are using 'ping vrf WORD address' right?

That is only on the provider network but the customer only has 1 routing table thus you can use the normal ping.

VRF is just logically isolating the routing tables from each other in the provider network but as far as exchanging routes or leaking between VRF I dont know much about that.

ISCW lab portfolio has a good example of MPLS VPN and verifying step by step. This is my only exposure to MPLS

kpjungle

kryolla wrote: »

That is only on the provider network but the customer only has 1 routing table thus you can use the normal ping.

VRF is just logically isolating the routing tables from each other in the provider network but as far as exchanging routes or leaking between VRF I dont know much about that.

ISCW lab portfolio has a good example of MPLS VPN and verifying step by step. This is my only exposure to MPLS

Okay, so i figured out what was wrong.

Basically i was doing a peering using the each routers interface as the source address:

(R1) <-> (R2) <-> (R3)

The peering works fine, the route shows up in the vrf routing table, and yes im using the VRF ping version. Doing some packet captures, here is what happens:

R1 and R3 has a bgp peering. The routes are flowing fine. But the label switching is where things get messed up.
Since MPLS vpns works by having two labels, the outmost label should be used to identify the egress LSR, in this case R3. The inner most label should be used by the egress router, to make a lookup from the local vrf, and to what interface to route the packet further.

Now with PHP, you strip the outer tag already at R1, because the subnet in question for R3, is being advertised by R2. This leaves only the inner most label which R2 will try to match by looking in its LFIB. nothing exist there because R2 is not part of the vpn between R1 and R3:

*Mar 1 00:22:03.891: tagsw_switch_packet: Pkt drop -- rewrite null, incg label 21 hwinput Se0/0

The fix: use loopbacks. by using loopbacks..
When you use the loopbacks, and have those in the MPLS "cloud", the decision to pop the outermost label occurs at R2, which by then know just to forward it out the direct link, because R3 told it to PHP it.

So all in all, loopbacks are required.. Somewhat of a warning should give you some clue into it:

%BGP-4-VPNV4NH_IF: Nexthop 192.168.12.1 may not be reachable from neigbor 192.168.24.4 - not a loopback

Hope this can be of some help to someone else

cisco_trooper

Oooohhh. I see a shiny new project to work on.