Mailing List Archive: Intra-device routing between VRFs

Intra-device routing between VRFs

Jan 3, 2020, 6:36 AM

Post #1 of 10 (2248 views)

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.

After turning the Google- and Cisco-cranks several times, I get the
impression that yes: it's possible, and no: maybe not.

I'm not necessarily looking for a HOWTO (although I'm not going to
object to one) ... I'm more curious if anyone has made this work and if
I'm barking up the right tree. At least one article I read suggests that
I need later firmware to do what I want.

In essence, I think the final piece is to get an IGP (or iBGP) up and
running between the two VRFs so that when I bring up a new customer in
"default", that things in "peering" can see said customer, and vice versa.

Any input on-line or off- would be greatly appreciated. Thanks!!

- bryan
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: Intra-device routing between VRFs [ In reply to ]

fordlove at gmail

Jan 3, 2020, 7:36 AM

Post #2 of 10 (2248 views)

Permalink

Have you tried adding peering rt rd to the default vrf, and vice versa?

On Fri, Jan 3, 2020, 7:37 AM Bryan Holloway <bryan@shout.net> wrote:

> 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.
>
> After turning the Google- and Cisco-cranks several times, I get the
> impression that yes: it's possible, and no: maybe not.
>
> I'm not necessarily looking for a HOWTO (although I'm not going to
> object to one) ... I'm more curious if anyone has made this work and if
> I'm barking up the right tree. At least one article I read suggests that
> I need later firmware to do what I want.
>
> In essence, I think the final piece is to get an IGP (or iBGP) up and
> running between the two VRFs so that when I bring up a new customer in
> "default", that things in "peering" can see said customer, and vice versa.
>
> Any input on-line or off- would be greatly appreciated. Thanks!!
>
> - bryan
> _______________________________________________
> cisco-nsp mailing list cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: Intra-device routing between VRFs [ In reply to ]

adamv0025 at netconsultings

Jan 3, 2020, 7:54 AM

Post #3 of 10 (2248 views)

Permalink

> From: Scott Miller
> Sent: Friday, January 3, 2020 3:37 PM
>
> Have you tried adding peering rt rd to the default vrf, and vice versa?
>
There's no concept of default vrf in the config -that would be great if
cisco added that to xr7

adam

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: Intra-device routing between VRFs [ In reply to ]

adamv0025 at netconsultings

Jan 3, 2020, 8:09 AM

Post #4 of 10 (2248 views)

Permalink

> From: cisco-nsp <cisco-nsp-bounces@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

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: Intra-device routing between VRFs [ In reply to ]

bryan at shout

Jan 3, 2020, 8:56 AM

Post #5 of 10 (2247 views)

Permalink

On 1/3/20 5:09 PM, adamv0025@netconsultings.com wrote:
>> From: cisco-nsp <cisco-nsp-bounces@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).

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: Intra-device routing between VRFs [ In reply to ]

adamv0025 at netconsultings

Jan 3, 2020, 10:18 AM

Post #6 of 10 (2241 views)

Permalink

> From: Bryan Holloway <bryan@shout.net>
> Sent: Friday, January 3, 2020 4:56 PM
>
>
>
> On 1/3/20 5:09 PM, adamv0025@netconsultings.com wrote:
> >> From: cisco-nsp <cisco-nsp-bounces@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

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: Intra-device routing between VRFs [ In reply to ]

bryan at shout

Jan 3, 2020, 11:07 AM

Post #7 of 10 (2241 views)

Permalink

On 1/3/20 7:18 PM, adamv0025@netconsultings.com wrote:
>> From: Bryan Holloway <bryan@shout.net>
>> Sent: Friday, January 3, 2020 4:56 PM
>>
>>
>>
>> On 1/3/20 5:09 PM, adamv0025@netconsultings.com wrote:
>>>> From: cisco-nsp <cisco-nsp-bounces@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 ...

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: Intra-device routing between VRFs [ In reply to ]

bryan at shout

Jan 3, 2020, 11:26 AM

Post #8 of 10 (2241 views)

Permalink

On 1/3/20 8:07 PM, Bryan Holloway wrote:
>
>
> On 1/3/20 7:18 PM, adamv0025@netconsultings.com wrote:
>>> From: Bryan Holloway <bryan@shout.net>
>>> Sent: Friday, January 3, 2020 4:56 PM
>>>
>>>
>>>
>>> On 1/3/20 5:09 PM, adamv0025@netconsultings.com wrote:
>>>>> From: cisco-nsp <cisco-nsp-bounces@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 ...
>

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 cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: Intra-device routing between VRFs [ In reply to ]

jloiacon at gmail

Jan 3, 2020, 11:36 AM

Post #9 of 10 (2241 views)

Permalink

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?
I recall this frustrating difficulty on the Nexux 7K. In some situations
it would work if I used the destination VLAN ID option instead of the
destination VLAN interface IP address (for some VLAN in the destination VRF)

Joe

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: Intra-device routing between VRFs [ In reply to ]

bryan at shout

Jan 4, 2020, 5:34 AM

Post #10 of 10 (2235 views)

Permalink

If anyone cares, I figured it out.

In short, I was overthinking the problem and came to the anti-climactic
conclusion that you can import/export whatever the hell you want as long
as it's in the RIB. I was under the incorrect assumption that the prefix
being imported/exported had to be in BGP somehow.

After tweaking my route-policies, I'm a happy camper.

Thanks to everyone who responded both on- and off-list.

Cheers!
- bryan

On 1/3/20 8:36 PM, Joe Loiacono wrote:
> 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?
>
> I recall this frustrating difficulty on the Nexux 7K. In some situations
> it would work if I used the destination VLAN ID option instead of the
> destination VLAN interface IP address (for some VLAN in the destination
> VRF)
>
> Joe
>
> _______________________________________________
> cisco-nsp mailing list cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/