On 1/3/20 8:07 PM, Bryan Holloway wrote:
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 ...
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?
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
