[c-nsp] Intra-device routing between VRFs

[Bryan Holloway]

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 ...