> From: Bryan Holloway <[email protected]> > Sent: Friday, January 3, 2020 4:56 PM > > > > On 1/3/20 5:09 PM, [email protected] wrote: > >> From: cisco-nsp <[email protected]> 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 _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
