On 1/3/20 7:18 PM, [email protected] wrote:
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
Yeah -- all I'm trying to redistribute are BGP-learned prefixes. I'm
wondering if this is a bug/issue with 5.3.4 ...
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
