[c-nsp] Intra-device routing between VRFs

[Bryan Holloway]

On 1/3/20 8:07 PM, Bryan Holloway wrote:
> 
> 
> On 1/3/20 7:18 PM, adamv0025 at netconsultings.com wrote:
>>> From: Bryan Holloway <bryan at shout.net>
>>> Sent: Friday, January 3, 2020 4:56 PM
>>>
>>>
>>>
>>> On 1/3/20 5:09 PM, adamv0025 at netconsultings.com wrote:
>>>>> From: cisco-nsp <cisco-nsp-bounces at puck.nether.net> On Behalf Of
>>>>> Bryan
>>>>> Sent: Friday, January 3, 2020 2:37 PM
>>>>>
>>>>> I've been attempting to lab up an ASR9001 running 5.3.4 for a PoC
>>>>> scenario
>>>> of
>>>>> routing between two internal VRFs: "default" and "peering".
>>>>> You can probably guess the use-case.
>>>>>
>>>>> While I've been successful in getting each VRF to talk to the things
>>>>> that particular VRF should talk to, getting the two VRFs to talk
>>>>> amongst themselves has been challenging.
>>>>>
>>>>> Installing specific static routes between the two VRFs works, but it
>>>> doesn't
>>>>> scale.
>>>>>
>>>> I think what you're looking for is:
>>>> vrf PEERING address-family ipv4 unicast import from default-vrf
>>>> route-policy RP_V4_STUFF_FROM_DEFAULT_TO_PEERING_VRF
>>>> [advertise-as-vpn] vrf PEERING address-family ipv4 unicast export to
>>>> default-vrf route-policy
>>> RP_V4_STUFF_FROM_PEERING_TO_DEFAULT_VRF
>>>>
>>>> adam
>>>>
>>>
>>> Yeah -- I have that, and I can see routes in the "default" VRF 
>>> imported from
>>> "peering" with a "(nexthop in vrf Peering)" and a valid nexthop.
>>>
>>> However, in the "peering" VRF, I see routes but the next-hop shows up as
>>> Null0 unless I add a static route. (Probably should've mentioned this 
>>> in the
>>> original post.)
>>>
>>> So yeah -- basically I have a next-hop that works in one direction 
>>> (default ->
>>> peering), but not in the other (peering -> default).
>>
>> Hmm that doesn't seem right,
>> Just checked I'm running 6.2.3 and all I have are those two commands 
>> no additional knobs to enable (and certainly no need for any static 
>> routes) to resolve next-hops -and mind you the VRF doesn't even have a 
>> routes for the next-hops and it shouldn't as these are supposed to be 
>> resolved in global/default routing table.
>> And all routes I import to a VRF have the correct next-hop stating: 
>> (Nexthop in Vrf: "default", Table: "default").
>>
>> But in my case in global/default routing table all the prefixes I 
>> redistribute/import to a VRF are BGP prefixes learned via iBGP in 
>> global/default table.
>> So I'm wondering whether you are trying to redistribute BGP learned 
>> prefixes or whether you are trying to leak IGP prefixes from 
>> global/default table to VRF -in which case that might cause problems 
>> related to next-hop?
>>
>> adam
> 
> Yeah -- all I'm trying to redistribute are BGP-learned prefixes. I'm 
> wondering if this is a bug/issue with 5.3.4 ...
> 

I take it back -- I misspoke.

These prefixes are advertised via BGP, but they are generated locally 
('network' statement), which means their next-hop is 0.0.0.0. I do 
believe that is the underlying issue.

So to answer your question, I think it's yes: I'm trying to leak IGP 
prefixes (or in this case, a static in the "default" VRF) into the 
"peering" VRF.

Is this possible?