[c-nsp] Intra-device routing between VRFs

[adamv0025 at netconsultings.com]

> 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