Mailing List Archive

Try a tunnel (lt) interface.


-------- Original message --------
From: Nathan Ward <juniper-nsp@daork.net>
Date: 2/9/20 6:08 PM (GMT-09:00)
To: Juniper NSP <juniper-nsp@puck.nether.net>
Subject: [j-nsp] Next-table, route leaking, etc.

Hi all,

Something that?s always bugged me about JunOS, is when you import a route from another VRF on JunOS, the attributes follow it - i.e. if it is a discard route, you get a discard route imported.
(Maybe this happens on other platforms, I honestly can?t remember, it?s been a while..)

This is an issue where you have a VRF with say a full table in it, and want to generate a default discard for other VRFs to import if they want internet access. Works great if the VRF importing it is on a different PE, but, if it?s local it simply gets a discard route, so packets get dropped rather than doing a second lookup.

You can solve this, sort of, with a next-table route, but things can get a little messy, so hoping for something more elegant.

I?m trying to figure out if there?s a better way to do this, i.e. to make it as though packets following leaked routes behave as though they are from a different router.

Anyone got any magic tricks I?ve somehow missed?

--
Nathan Ward

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Sure - there’s a number of solutions like that available. LT, next-table routes, etc. LT means more processing than a next-table, but in some ways is a bit less fiddly.

I’m hoping there’s a way to bypass this entirely - making packets following imported routes work the same whether the exporter of the route is local or remote.

> On 10/02/2020, at 4:27 PM, Larry Jones <ljones@bluphisolutions.com> wrote:
>
> Try a tunnel (lt) interface.
>
>
> -------- Original message --------
> From: Nathan Ward <juniper-nsp@daork.net>
> Date: 2/9/20 6:08 PM (GMT-09:00)
> To: Juniper NSP <juniper-nsp@puck.nether.net>
> Subject: [j-nsp] Next-table, route leaking, etc.
>
> Hi all,
>
> Something that’s always bugged me about JunOS, is when you import a route from another VRF on JunOS, the attributes follow it - i.e. if it is a discard route, you get a discard route imported.
> (Maybe this happens on other platforms, I honestly can’t remember, it’s been a while..)
>
> This is an issue where you have a VRF with say a full table in it, and want to generate a default discard for other VRFs to import if they want internet access. Works great if the VRF importing it is on a different PE, but, if it’s local it simply gets a discard route, so packets get dropped rather than doing a second lookup.
>
> You can solve this, sort of, with a next-table route, but things can get a little messy, so hoping for something more elegant.
>
> I’m trying to figure out if there’s a better way to do this, i.e. to make it as though packets following leaked routes behave as though they are from a different router.
>
> Anyone got any magic tricks I’ve somehow missed?
>
> --
> Nathan Ward
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net <mailto:juniper-nsp@puck.nether.net>
> https://puck.nether.net/mailman/listinfo/juniper-nsp <https://puck.nether.net/mailman/listinfo/juniper-nsp>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

To deal with this on MX stuff a way that looked like we did previously on Redback gears (old beast but at least on them this «just works» with double lookup), we use a «third part« VRF. This is a dedicated empty VRF on each router with only a bunch of static next-table routes. It is a no-vrf-advertise VRF (config knob normally used in hub and spoke architectures), so it doesn't export its content toward other PEs , but only locally (auto-export).

Each time we have a discard route in an origin VRF that we need to import in some other VRF (local or not, but let's say local), we create a copy of this route in this special VRF, with a next-hop attribute instead of the discard, and a special community.
This is this route that is finally imported by other various local VRFs using auto-export (so the import policy is the same for all routes for any MPLS VPN, local routes or not).

Additionally:
- all the normal VRFs have a first term in their export policy to prevent the re-export of those special imported routes (based on the special community – this is because no-vrf-advertise imported routes become exportable to other PEs once locally imported in another VRF using auto-export).
- in all our import policies, importing static (but also aggregate, in fact all but bgp), get its preference changed to more than 5 (default static preference – we use 168 but whatever), so once the next-hop route is imported in the VRF that contains the former discard route, no route loop ensues (the next-hop route is Inactive because of Route Preference).

Toward the other PEs, the «true» discard route is exported from its VRF.


In importing VRFs, the imported next-hop route wins over the imported discard route (Inactive reason: Number of gateways).


The goals behind all this stuff were to:
- avoid creating a next-hop route in each VRF that needed the route
- keep the same import/export policy standards for about all the VRFs
- use the same conf whatever the null/discard route is to be imported in local or distant VRFs (no difference like on IOS/SEOS and so on)
- use auto-export, so no need for ribgroups (much closer to what was done on other vendors gears)


> Le 10 févr. 2020 à 04:50, Nathan Ward <juniper-nsp@daork.net> a écrit :
>
> Sure - there’s a number of solutions like that available. LT, next-table routes, etc. LT means more processing than a next-table, but in some ways is a bit less fiddly.
>
> I’m hoping there’s a way to bypass this entirely - making packets following imported routes work the same whether the exporter of the route is local or remote.
>
>> On 10/02/2020, at 4:27 PM, Larry Jones <ljones@bluphisolutions.com <mailto:ljones@bluphisolutions.com>> wrote:
>>
>> Try a tunnel (lt) interface.
>>
>>
>> -------- Original message --------
>> From: Nathan Ward <juniper-nsp@daork.net>
>> Date: 2/9/20 6:08 PM (GMT-09:00)
>> To: Juniper NSP <juniper-nsp@puck.nether.net>
>> Subject: [j-nsp] Next-table, route leaking, etc.
>>
>> Hi all,
>>
>> Something that’s always bugged me about JunOS, is when you import a route from another VRF on JunOS, the attributes follow it - i.e. if it is a discard route, you get a discard route imported.
>> (Maybe this happens on other platforms, I honestly can’t remember, it’s been a while..)
>>
>> This is an issue where you have a VRF with say a full table in it, and want to generate a default discard for other VRFs to import if they want internet access. Works great if the VRF importing it is on a different PE, but, if it’s local it simply gets a discard route, so packets get dropped rather than doing a second lookup.
>>
>> You can solve this, sort of, with a next-table route, but things can get a little messy, so hoping for something more elegant.
>>
>> I’m trying to figure out if there’s a better way to do this, i.e. to make it as though packets following leaked routes behave as though they are from a different router.
>>
>> Anyone got any magic tricks I’ve somehow missed?

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On Mon, 10 Feb 2020 at 05:08, Nathan Ward <juniper-nsp@daork.net> wrote:

Hey Nathan,

> Anyone got any magic tricks I’ve somehow missed?

Olivier had a cute trick for this. This issue happens because it's the
same route, there is no resolve-on-import and this is something JNPR
is open to implement where you'd have some sort of toggle when you
want to resolve routes on import. I've not requested ER myself, as
I've just worked around it, but might be something to talk to our
account team and do an ER so we all get to enjoy this feature in few
years time :)


--
++ytti
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

I realise I wrote by mistake «next-hop» instead of «next-table» about everywhere :)

> Le 10 févr. 2020 à 05:51, Olivier Benghozi <olivier.benghozi@wifirst.fr> a écrit :
>
> To deal with this on MX stuff a way that looked like we did previously on Redback gears (old beast but at least on them this «just works» with double lookup), we use a «third part« VRF. This is a dedicated empty VRF on each router with only a bunch of static next-table routes. It is a no-vrf-advertise VRF (config knob normally used in hub and spoke architectures), so it doesn't export its content toward other PEs , but only locally (auto-export).
>
> Each time we have a discard route in an origin VRF that we need to import in some other VRF (local or not, but let's say local), we create a copy of this route in this special VRF, with a next-hop attribute instead of the discard, and a special community.
> This is this route that is finally imported by other various local VRFs using auto-export (so the import policy is the same for all routes for any MPLS VPN, local routes or not).
>
> Additionally:
> - all the normal VRFs have a first term in their export policy to prevent the re-export of those special imported routes (based on the special community – this is because no-vrf-advertise imported routes become exportable to other PEs once locally imported in another VRF using auto-export).
> - in all our import policies, importing static (but also aggregate, in fact all but bgp), get its preference changed to more than 5 (default static preference – we use 168 but whatever), so once the next-hop route is imported in the VRF that contains the former discard route, no route loop ensues (the next-hop route is Inactive because of Route Preference).
>
> Toward the other PEs, the «true» discard route is exported from its VRF.
>
>
> In importing VRFs, the imported next-hop route wins over the imported discard route (Inactive reason: Number of gateways).
>
>
> The goals behind all this stuff were to:
> - avoid creating a next-hop route in each VRF that needed the route
> - keep the same import/export policy standards for about all the VRFs
> - use the same conf whatever the null/discard route is to be imported in local or distant VRFs (no difference like on IOS/SEOS and so on)
> - use auto-export, so no need for ribgroups (much closer to what was done on other vendors gears)
>
>
>> Le 10 févr. 2020 à 04:50, Nathan Ward <juniper-nsp@daork.net <mailto:juniper-nsp@daork.net>> a écrit :
>>
>> Sure - there’s a number of solutions like that available. LT, next-table routes, etc. LT means more processing than a next-table, but in some ways is a bit less fiddly.
>>
>> I’m hoping there’s a way to bypass this entirely - making packets following imported routes work the same whether the exporter of the route is local or remote.
>>
>>> On 10/02/2020, at 4:27 PM, Larry Jones <ljones@bluphisolutions.com <mailto:ljones@bluphisolutions.com>> wrote:
>>>
>>> Try a tunnel (lt) interface.
>>>
>>>
>>> -------- Original message --------
>>> From: Nathan Ward <juniper-nsp@daork.net <mailto:juniper-nsp@daork.net>>
>>> Date: 2/9/20 6:08 PM (GMT-09:00)
>>> To: Juniper NSP <juniper-nsp@puck.nether.net <mailto:juniper-nsp@puck.nether.net>>
>>> Subject: [j-nsp] Next-table, route leaking, etc.
>>>
>>> Hi all,
>>>
>>> Something that’s always bugged me about JunOS, is when you import a route from another VRF on JunOS, the attributes follow it - i.e. if it is a discard route, you get a discard route imported.
>>> (Maybe this happens on other platforms, I honestly can’t remember, it’s been a while..)
>>>
>>> This is an issue where you have a VRF with say a full table in it, and want to generate a default discard for other VRFs to import if they want internet access. Works great if the VRF importing it is on a different PE, but, if it’s local it simply gets a discard route, so packets get dropped rather than doing a second lookup.
>>>
>>> You can solve this, sort of, with a next-table route, but things can get a little messy, so hoping for something more elegant.
>>>
>>> I’m trying to figure out if there’s a better way to do this, i.e. to make it as though packets following leaked routes behave as though they are from a different router.
>>>
>>> Anyone got any magic tricks I’ve somehow missed?
>

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On Sat, 22 Feb 2020 at 00:26, Jeff Haas <jhaas@juniper.net> wrote:

> The problem and example in the thread were past the ability of my brain to follow this round.
> That said, there's some amount of plumbing that can permit a route that's been imported into a VRF to locally resolve vs. the local VRF tables rather than share the fate of its primary route.
> This plumbing isn't generally exposed at this time. Magic words "independent resolution". Just in case that fits the ER. :-)

Ooh, very good news. Nathan, can you please talk to your account team
about this and get formal ER going? I'm happy to 'me too' my account
team, once you have the ER number. And Jeff's work is made whole lot
easier when he can go 'customers are asking this'.

--
++ytti
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

> On 22/02/2020, at 10:52 PM, Saku Ytti <saku@ytti.fi> wrote:
>
> On Sat, 22 Feb 2020 at 00:26, Jeff Haas <jhaas@juniper.net> wrote:
>
>> The problem and example in the thread were past the ability of my brain to follow this round.
>> That said, there's some amount of plumbing that can permit a route that's been imported into a VRF to locally resolve vs. the local VRF tables rather than share the fate of its primary route.
>> This plumbing isn't generally exposed at this time. Magic words "independent resolution". Just in case that fits the ER. :-)
>
> Ooh, very good news. Nathan, can you please talk to your account team
> about this and get formal ER going? I'm happy to 'me too' my account
> team, once you have the ER number. And Jeff's work is made whole lot
> easier when he can go 'customers are asking this’.

Sounds great - will see what I can get going tomorrow.

--
Nathan Ward

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Faced the same issue and found out that generated route works in my
case. It may be not flexible enough if multiple active next-hops exist
at the same time in the routing-instance, but it's ok for simple
primary-backup scenario.

Kind regards,
Andrey Kostin

>>>> -------- Original message --------
>>>> From: Nathan Ward <juniper-nsp@daork.net
>>>> <mailto:juniper-nsp@daork.net>>
>>>> Date: 2/9/20 6:08 PM (GMT-09:00)
>>>> To: Juniper NSP <juniper-nsp@puck.nether.net
>>>> <mailto:juniper-nsp@puck.nether.net>>
>>>> Subject: [j-nsp] Next-table, route leaking, etc.
>>>>
>>>> Hi all,
>>>>
>>>> Something that’s always bugged me about JunOS, is when you import a
>>>> route from another VRF on JunOS, the attributes follow it - i.e. if
>>>> it is a discard route, you get a discard route imported.
>>>> (Maybe this happens on other platforms, I honestly can’t remember,
>>>> it’s been a while..)
>>>>
>>>> This is an issue where you have a VRF with say a full table in it,
>>>> and want to generate a default discard for other VRFs to import if
>>>> they want internet access. Works great if the VRF importing it is on
>>>> a different PE, but, if it’s local it simply gets a discard route,
>>>> so packets get dropped rather than doing a second lookup.
>>>>
>>>> You can solve this, sort of, with a next-table route, but things can
>>>> get a little messy, so hoping for something more elegant.
>>>>
>>>> I’m trying to figure out if there’s a better way to do this, i.e. to
>>>> make it as though packets following leaked routes behave as though
>>>> they are from a different router.
>>>>
>>>> Anyone got any magic tricks I’ve somehow missed?
>>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

> -----Original Message-----
> From: juniper-nsp <juniper-nsp-bounces@puck.nether.net> On Behalf Of
> Saku Ytti
> Sent: Saturday, February 22, 2020 9:52 AM
> To: Jeff Haas <jhaas@juniper.net>
> Cc: Juniper NSP <juniper-nsp@puck.nether.net>
> Subject: Re: [j-nsp] Next-table, route leaking, etc.
>
> On Sat, 22 Feb 2020 at 00:26, Jeff Haas <jhaas@juniper.net> wrote:
>
> > The problem and example in the thread were past the ability of my brain
to
> follow this round.
> > That said, there's some amount of plumbing that can permit a route
that's
> been imported into a VRF to locally resolve vs. the local VRF tables
rather
> than share the fate of its primary route.
> > This plumbing isn't generally exposed at this time. Magic words
> > "independent resolution". Just in case that fits the ER. :-)
>
> Ooh, very good news. Nathan, can you please talk to your account team
> about this and get formal ER going? I'm happy to 'me too' my account team,
> once you have the ER number. And Jeff's work is made whole lot easier
> when he can go 'customers are asking this'.
>
I'll do plus one as well

adam

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp