Please Help!! - Ping to and from MPLS/VPN

[mheick]

I am having strange ping results and cannot understand why. My gut feeling is that this stems from a lack of understanding of the technology.

First, I have leaked a Vrf subnet into the global vrf so that I can have reachability to some devices in the vrf and the devices themselves can have reachability to services outside of the cloud.

I know this design is going to seem a little convoluted so bear with me. I have built a model of my providers network whereby the connected routes between the CE and PE are public addresses, the internal routes are private addresses in the 10.0.0.0/8 network. I am running BGP between the PE and CE, and then redistributing static routesinto OSPF for the actual MPLS network routing.

Then of the backbone (Area 0) of the OSPF network, I have a connection to what I will call my Services network where resources such as DNS/DHCP, Internet, and Call Manager reside.(See diagram).

What happens is that on the PE that is directly connected to the CE, I cannot ping the network contained in the CE unless I actually specify an interface other than the address of the directly connected interface.

If I go to the P router I can ping just fine. Even if I go to the Services network I am successful so I know that I have been somewhat successful in leaking the subnet located in the VPN vrf.

On the flip side, When I am in the CE, I cannot ping to the Services network, or any network that is in the 10.0.0.0/8 space, so I am almost certain there is a routing principle that I am missing here.

Sorry for the long post, but I am trying to include the pertinent information that I hope will lead to some assistance.

[lejoe.thomas · Accepted solution]

Hi Marc,

What happens is that on the PE that is directly connected to the CE, I cannot ping the network contained in the CE unless I actually specify an interface other than the address of the directly connected interface.

I think to ping from source address of the interface that belongs to a particular vrf, you need to use

ping vrf vpn-mtb

On the flip side, When I am in the CE, I cannot ping to the Services network, or any network that is in the 10.0.0.0/8 space, so I am almost certain there is a routing principle that I am missing here.

When you ping the services network from CE router, the source address belongs 68.139.201.28/30 subnet. You need to add route to this subnet on the 3750 Metro

eg:

ip route 68.139.201.0 255.255.255.0 68.0.1.2

However if you use the source address of the loopback 0 interface on the CE, you'll see the pings are successful.

Likewise if you need to ping from the CE using source address of Fa2/1 (68.1.0.5), you need to add a static route on PE so that it is redistributed into ospf and advertised to P1 as well.

One final thing I noticed is the interface address of GigabitEthernet1/1/1 on 3750 ( Uplink to Balti00R11 Gi1/1/1) is same as the interface address of FastEthernet0/0 on the PE, i.e 68.1.1.6/30. Because of this if you try and ping the services network from PE, the replies will never be received.

HTH

Lejoe

[mheick]

Lejoe,

You were correct in discovering that the route was missing from the 3750 metro point back to the connected route between the PE and CE. I added this and I am not able to ping the services network from the CE router. Thanks very much for this. I am glad it was a simple resolution.

As far as the duplicate address on the 3750 Metro and the PE, the interface on the 3750 was left over from a previous design and is inactive. Thanks for catching as I would need to clean it up regardless.

You were also correct in saying that if I source the ping from within the vrf, then I am able to ping. However, I thought that I took care of this by leaking the route to the global config. Here is the global ruoting table on the PE router.

S 68.139.201.28/30 is directly connected, FastEthernet1/0

C 68.1.1.4/30 is directly connected, FastEthernet0/0

O IA 68.2.1.4/30 [110/12] via 68.1.1.5, 23:30:42, FastEthernet0/0

O IA 68.1.2.4/30 [110/2] via 68.1.1.5, 23:30:42, FastEthernet0/0

O IA 68.1.0.1/32 [110/2] via 68.1.1.5, 23:30:42, FastEthernet0/0

C 68.1.1.1/32 is directly connected, Loopback0

O IA 68.0.1.0/30 [110/2] via 68.1.1.5, 23:30:42, FastEthernet0/0

O IA 68.2.1.1/32 [110/13] via 68.1.1.5, 23:30:42, FastEthernet0/0

O IA 68.0.2.0/30 [110/3] via 68.1.1.5, 23:30:42, FastEthernet0/0

O IA 68.2.0.1/32 [110/3] via 68.1.1.5, 23:30:42, FastEthernet0/0

O IA 68.255.1.0/30 [110/2] via 68.1.1.5, 23:30:42, FastEthernet0/0

10.0.0.0/16 is subnetted, 1 subnets

S 10.152.0.0 [1/0] via 68.139.201.30, FastEthernet1/0

O*E2 0.0.0.0/0 [110/1] via 68.1.1.5, 23:30:42, FastEthernet0/0

If you take a look at the configs, I have placed the directly connected route into the global table by using a static route on the PE router:

ip route 68.139.201.28 255.255.255.252 FastEthernet1/0

I would like to understand why I cannot ping the directly connected route from the PE, especially when it is in the routing table. Would you know why this is?

[lejoe.thomas]

Hi Marc,

The static route

ip route 68.139.201.28 255.255.255.252 FastEthernet1/0

leaks routes in the VRF to global routing table. This allows devices to reach the routes inside the VRF through the global routing table. From the PE, as long as you ping these leaked routes using source address other than interface which belongs to specified VRF, pings will be successful.

However to successfully ping addresses in the VRF using interface that is part of the VRF as source address, the ping vrf command needs to be used, otherwise pings are never successful. The pings (without vrf) using the address of the interface that is part of the VRF uses the global routing and does get replies from the CE but is never successful. An icmp debug should reveal that.

I guess this makes sense because VRFs were created to separate routes into different routing tables. I dont have the exact reason as to why this case is not possible but it does seem to be logical.

HTH

Lejoe

[mheick]

Lejoe,

I agree with yuo about the icmp debug. I saw this last night when I was trying to figure out what was wrong.

At this point, with your assistance, I have my issue resolved.

Many thanks again and look forward to hopefully helping you out in the future.

Mark