VRF static route pointing to dynamic next-hop

[massipace]

scenario:

CE1---PE(R1)----P----PE(R2)---CE2

CE1 advertise its own Loopback address x.y.z.w/32 in VRF_AA

if on R2 we configure:

ip route vrf VRF_AA ETH-CE1 x.y.z.w

does MPLS network transport packet to eth of CE1 for packet sourced from R2?

wich label is associated to network eth of CE1?

[a.alekseev]

MP-BGP is used for assigning labels to vpn routes.

sh ip bgp vpnv4 vrf VRF_NAME labels

[massipace]

thanks for your answer

here I have pasted output of sh ip bgp vpn vrf VRF_NAME labels and show ip cef vrf xxx

for example, in this case I configure a static route with next hop received dynamically via MP-BGP

#ip route vrf VPN_XXX 151.99.125.0 255.255.255.0 10.188.127.5

#p vrf VPN_XXX 10.188.127.5

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.188.127.5, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 20/21/24 ms

#sh ip rou vrf VPN_XXX 151.99.125.2

Routing entry for 151.99.125.0/24

Known via "static", distance 1, metric 0

Routing Descriptor Blocks:

* 10.188.127.5

Route metric is 0, traffic share count is 1

#sh ip rou vrf VPN_XXX 10.188.127.5

Routing entry for 10.188.127.5/32

Known via "bgp yyy", distance 200, metric 0

Tag xxx, type internal

Last update from 217.223.17.130 1w6d ago

Routing Descriptor Blocks:

* 217.223.17.130 (Default-IP-Routing-Table), from 217.222.0.50, 1w6d ago

Route metric is 0, traffic share count is 1

AS Hops 2

#sh ip bgp vpn vrf VPN_XXX tags | i 10.188.127.5

10.188.127.5/32 217.223.17.130 notag/6871

#sh ip cef vrf VPN_XXX 151.99.125.0 255.255.255.0 det

151.99.125.0/24, version 127910, per-destination sharing

0 packets, 0 bytes

Flow: AS 0, mask 24

tag information from 10.188.127.5/32, shared

local tag: VPN-route-head

fast tag rewrite with

Recursive rewrite via 217.223.17.130/32, tags imposed {6871}

via 10.188.127.5, 0 dependencies, recursive

next hop 217.222.7.37, FastEthernet5/1/0 via 10.188.127.5/32

valid adjacency

tag rewrite with

Recursive rewrite via 217.223.17.130/32, tags imposed {6871}

Recursive load sharing using 217.223.17.130/32.

it assigns the same label at both routes (one only static and n.h dinamically received via MP-BGP.

it seems PE is able to transport packets destined to 151.99.125.0/24 without any MP-BGP advertisement about this network.

the questions is:

is it correct this behavior?

[rrlewis]

I have a similar issue, but have found that [speculation with some evidence] this forwarding of traffic only works when the next-hop PE is an LDP neighbour. If the next-hop PE is not and LDP neighbour, then there is no entry in the mpls forwarding table for the route (although it appears valid in the vrf bgp routing table and in CEF). I suspect this to be a recursive lookup problem, but am still in early stages..

[rrlewis]

Now I have it replicated in the lab. As I thought, if you have an LDP neighbour then the correct MPLS forwarding entry appears despite the fact that the prefix is not present in MP-BGP, since it's learnt in LDP. If the two devices are not LDP neighbours and are reliant on MP-BGP for their labels then no MPLS forwarding entry exists and (in my case) CEF forwards the packet to the default route entry instead (effectively blackholing it).

The interesting issue for me is that, although that static route has no matching prefix in MP-BGP, the next hop which the static route points to is valid in MP-BGP and has a label with an entry in the MPLS forwarding table. However that extra lookup does not happen (I think basically this comes down to too much recursion).

I think we are back to the original question of whether it would be reasonable to expect that lookup to take place?