MPLS VPN default route question

[Difan Zhao]

Hi,

I have a simple topology like CE1 - PE1 - P - PE2 - CE2. In the customer VPN/VRF, there is only a default route advertised by the CE2 which is learned by PE2 via BGP in that VRF, then imported into VPNv4 AF by PE2 and advertised to PE1.

I can ping address on CE2 and anything behind it from PE1 using the default route

However I can't ping a loopback on the PE2 that is also in the customer VPN/VRF from PE1. If I advertise the loopback in the VPN I will be able to ping it. It looks like that I can't ping it using the default route.

Is this expected behavior?

If so, anyway to allow this ping to work without adversing it?

Thanks,

Difan

[Harold Ritter · Accepted solution]

Hi Difan,

This is normal behavior indeed. The default route is advertised by CE2. Packets from CE1 to PE2 follows the default route to PE1. PE1 performs the label imposition and forwards the packets towards PE2. Since P is the penultimate hop, it removes the top label and forwards the packets to PE2. PE2 does a label lookup and forwards the packets to CE2 withouth even looking at the RIB for the specific VRF.

Regards,

[Difan Zhao]

Thanks Harold.

However I would expect CE2 to receive the packet destined to the PE2 correct? However I did pcap and I did not see packet came in on the CE2. 

Also the traceroute is bit strange as well. Here is what I see when I did a traceroute on PE1:

PE1#traceroute vrf QADeviceConnect 169.254.0.2 source g0/2.18 numeric probe 1 timeout 1
Type escape sequence to abort.
Tracing the route to 169.254.0.2 <- Loopback int on PE2
VRF info: (vrf in name/id, vrf out name/id)
1 *
2 *
3 169.254.0.9 [MPLS: Label 27 Exp 0] 4 msec <- PE2's CE2 facing interface IP
4 *
5 *
6 *
7 *

It looks like it got processed by PE2's CE2 facing interface.. Then it looks like it just blackholed the traffic.. Is it normal?

Thanks,

Difan

[Harold Ritter]

Hi Difan,

In the scenario I was referring to, the packets should definitely reach CE2.

To verify why packets are not getting to CE2, you could do the following:

- "show ip cef vrf <your vrf> 0.0.0.0 0.0.0.0"on PE1

- "show mpls forwarding-table labels <label from output from previous command>" on PE2

The output from the previous command should tell you what takes place on PE2 when packets arrive with the label assign to the default route.

Regards,

[Difan Zhao]

PE1#show ip cef vrf QADeviceConnect 0.0.0.0 0.0.0.0
0.0.0.0/0
nexthop 10.133.252.126 Tunnel21 label 21-(local:42) 27

PE2#show mpls forwarding-table labels 27
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
27 No Label 0.0.0.0/0[V] 95990 Po1.2900 169.254.0.14 <- CE2's PE2-facing interface IP

It looks normal to me. Let me know if you see anything abnormal with the output. I also lied about my topology. There are actually two P routers in the middle. Don't think it would make any difference, would it?

Thanks!

Difan

[Harold Ritter]

Hi Difan,

This output is completely normal, given that the default label allocation is per prefix in IOS. it's indicating that the traffic is sent directly to CE2 after the label lookup.

One quick way to validate this is to enable "deb ip icmp" on CE2, ping CE2 from CE1 and verify that ICMP Host Unreachable messages are sent to CE1. Another way to validate that the behavior I stated is what you are seeing would be to change the default label allocation mode on the egress PE (PE2) from per prefix to per vrf, using the following command:

mpls label mode all-vrfs protocol bgp-vpnv4 per-vrf

Regards,

[Difan Zhao]

You are right! CE2 was not doing the pcap properly... It is not a Cisco device and I made a mistake with the pcap... Now I do see CE2 receiving the traffic and properly forwarding it back to PE2. After all the problem was all on CE2...

Also want to thank you for your command! I did not know that it exist. It seems that it allocates one lable for all prefixes. With it, pings to any addresses on the PE2 in that VRF work. One last question, is this good approach to keep it so it does label allocation per VRF instead of per prefix? It is easier to troubleshoot and it is cleaner with just one lable for everything.. However the link I found says "don't use"... Why is that..?

https://www.cisco.com/c/en/us/td/docs/ios/ios_xe/mpls/configuration/guide/mp_vpn_per_vrf_lbl_xe.html

Thanks!

[Harold Ritter]

Hi Difan,

It is normally recommended to keep the default per prefix label allocation mode unless there is a good reason to use the per vrf label allocation mode. Bear in mind in mind that the per vrf allocation mode will incur an additional lookup (LFIB lookup + RIB lookup) on the ingress PE and that this could lead to lower performance. There are also other scenarios, such as BGP PIC edge, in which the per vrf label allocation mode is not supported.

In your scenario, if you do not want traffic targetted to PE2 to go to CE2, you simply have to configure "redistribute connected" for the VRF on PE2. This is much better than using the per vrf allocation mode.

Regards,

[Difan Zhao]

Thank you sir

[Harold Ritter]

You are very welcome Difan.