Mailing List Archive

> Luis Balbinot
> Sent: Thursday, January 24, 2019 4:45 PM
>
> Hi.
>
> How could I prevent a device from getting transit RSVP LSPs being
> established through it? I only want it to accept ingress LSPs destined to
that
> box.
>
If this is a permanent thing,
You could create a colouring scheme where all links connected to this node
have to be avoided by all LSPs with the exception of LSPs terminated on this
node (or originated by this node).

If this is a maintenance thing,
There's a command that can be enabled to drain all transit LSPs out the box.
But, all the LSPs would need to be configured with this capability in the
first place.


adam

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

It's a permanent thing.

These boxes are PE routers that are not supposed to handle transit
traffic but during certain network events a few FRR bypass LSPs are
established through them because that's the only remaining path.

Something easier like a "no-eligible-backup" toggle like the one we
have with OSPF LFA would be nice.

Luis

On Thu, Jan 24, 2019 at 2:53 PM <adamv0025@netconsultings.com> wrote:
>
> > Luis Balbinot
> > Sent: Thursday, January 24, 2019 4:45 PM
> >
> > Hi.
> >
> > How could I prevent a device from getting transit RSVP LSPs being
> > established through it? I only want it to accept ingress LSPs destined to
> that
> > box.
> >
> If this is a permanent thing,
> You could create a colouring scheme where all links connected to this node
> have to be avoided by all LSPs with the exception of LSPs terminated on this
> node (or originated by this node).
>
> If this is a maintenance thing,
> There's a command that can be enabled to drain all transit LSPs out the box.
> But, all the LSPs would need to be configured with this capability in the
> first place.
>
>
> adam
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

I'm not aware of any option that will do this.

The three solutions that I can think of are:
Link colouring like Adam suggests
An explicit path that avoids the interfaces you are worried about
Set the RSVP cost for the interfaces really high

Dave

On Thu, 24 Jan 2019 at 17:01, Luis Balbinot <luis@luisbalbinot.com> wrote:

> It's a permanent thing.
>
> These boxes are PE routers that are not supposed to handle transit
> traffic but during certain network events a few FRR bypass LSPs are
> established through them because that's the only remaining path.
>
> Something easier like a "no-eligible-backup" toggle like the one we
> have with OSPF LFA would be nice.
>
> Luis
>
> On Thu, Jan 24, 2019 at 2:53 PM <adamv0025@netconsultings.com> wrote:
> >
> > > Luis Balbinot
> > > Sent: Thursday, January 24, 2019 4:45 PM
> > >
> > > Hi.
> > >
> > > How could I prevent a device from getting transit RSVP LSPs being
> > > established through it? I only want it to accept ingress LSPs destined
> to
> > that
> > > box.
> > >
> > If this is a permanent thing,
> > You could create a colouring scheme where all links connected to this
> node
> > have to be avoided by all LSPs with the exception of LSPs terminated on
> this
> > node (or originated by this node).
> >
> > If this is a maintenance thing,
> > There's a command that can be enabled to drain all transit LSPs out the
> box.
> > But, all the LSPs would need to be configured with this capability in the
> > first place.
> >
> >
> > adam
> >
> _______________________________________________
> 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

Luis-

You could probably set the overload bit.

-Colby

?On 1/24/19, 1:10 PM, "juniper-nsp on behalf of Dave Bell" <juniper-nsp-bounces@puck.nether.net on behalf of me@geordish.org> wrote:

I'm not aware of any option that will do this.

The three solutions that I can think of are:
Link colouring like Adam suggests
An explicit path that avoids the interfaces you are worried about
Set the RSVP cost for the interfaces really high

Dave

On Thu, 24 Jan 2019 at 17:01, Luis Balbinot <luis@luisbalbinot.com> wrote:

> It's a permanent thing.
>
> These boxes are PE routers that are not supposed to handle transit
> traffic but during certain network events a few FRR bypass LSPs are
> established through them because that's the only remaining path.
>
> Something easier like a "no-eligible-backup" toggle like the one we
> have with OSPF LFA would be nice.
>
> Luis
>
> On Thu, Jan 24, 2019 at 2:53 PM <adamv0025@netconsultings.com> wrote:
> >
> > > Luis Balbinot
> > > Sent: Thursday, January 24, 2019 4:45 PM
> > >
> > > Hi.
> > >
> > > How could I prevent a device from getting transit RSVP LSPs being
> > > established through it? I only want it to accept ingress LSPs destined
> to
> > that
> > > box.
> > >
> > If this is a permanent thing,
> > You could create a colouring scheme where all links connected to this
> node
> > have to be avoided by all LSPs with the exception of LSPs terminated on
> this
> > node (or originated by this node).
> >
> > If this is a maintenance thing,
> > There's a command that can be enabled to drain all transit LSPs out the
> box.
> > But, all the LSPs would need to be configured with this capability in the
> > first place.
> >
> >
> > adam
> >
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_juniper-2Dnsp&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3lVLtwWQROCdl4DSF6Gy-pAupMaX1AvOyICNqk7ML5U&m=xjETS_MpBQ5yJFgNOTwIgxvck93EOjA7sbBBzWEr7sE&s=fIjs_f4CA6mUSiUhoRhAYrV4mmOT5lDwryzIvSgr-KU&e=
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_juniper-2Dnsp&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3lVLtwWQROCdl4DSF6Gy-pAupMaX1AvOyICNqk7ML5U&m=xjETS_MpBQ5yJFgNOTwIgxvck93EOjA7sbBBzWEr7sE&s=fIjs_f4CA6mUSiUhoRhAYrV4mmOT5lDwryzIvSgr-KU&e=


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

That’s a good idea. I’m not 100% sure that this will prevent the creation
of bypass LSPs but I’ll give it a try.

Thanks!

Luis

On Thu, 24 Jan 2019 at 18:01 Colby Barth <cbarth@juniper.net> wrote:

> Luis-
>
> You could probably set the overload bit.
>
> -Colby
>
> ?On 1/24/19, 1:10 PM, "juniper-nsp on behalf of Dave Bell" <
> juniper-nsp-bounces@puck.nether.net on behalf of me@geordish.org> wrote:
>
> I'm not aware of any option that will do this.
>
> The three solutions that I can think of are:
> Link colouring like Adam suggests
> An explicit path that avoids the interfaces you are worried about
> Set the RSVP cost for the interfaces really high
>
> Dave
>
> On Thu, 24 Jan 2019 at 17:01, Luis Balbinot <luis@luisbalbinot.com>
> wrote:
>
> > It's a permanent thing.
> >
> > These boxes are PE routers that are not supposed to handle transit
> > traffic but during certain network events a few FRR bypass LSPs are
> > established through them because that's the only remaining path.
> >
> > Something easier like a "no-eligible-backup" toggle like the one we
> > have with OSPF LFA would be nice.
> >
> > Luis
> >
> > On Thu, Jan 24, 2019 at 2:53 PM <adamv0025@netconsultings.com>
> wrote:
> > >
> > > > Luis Balbinot
> > > > Sent: Thursday, January 24, 2019 4:45 PM
> > > >
> > > > Hi.
> > > >
> > > > How could I prevent a device from getting transit RSVP LSPs being
> > > > established through it? I only want it to accept ingress LSPs
> destined
> > to
> > > that
> > > > box.
> > > >
> > > If this is a permanent thing,
> > > You could create a colouring scheme where all links connected to
> this
> > node
> > > have to be avoided by all LSPs with the exception of LSPs
> terminated on
> > this
> > > node (or originated by this node).
> > >
> > > If this is a maintenance thing,
> > > There's a command that can be enabled to drain all transit LSPs
> out the
> > box.
> > > But, all the LSPs would need to be configured with this capability
> in the
> > > first place.
> > >
> > >
> > > adam
> > >
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp@puck.nether.net
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_juniper-2Dnsp&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3lVLtwWQROCdl4DSF6Gy-pAupMaX1AvOyICNqk7ML5U&m=xjETS_MpBQ5yJFgNOTwIgxvck93EOjA7sbBBzWEr7sE&s=fIjs_f4CA6mUSiUhoRhAYrV4mmOT5lDwryzIvSgr-KU&e=
> >
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_juniper-2Dnsp&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3lVLtwWQROCdl4DSF6Gy-pAupMaX1AvOyICNqk7ML5U&m=xjETS_MpBQ5yJFgNOTwIgxvck93EOjA7sbBBzWEr7sE&s=fIjs_f4CA6mUSiUhoRhAYrV4mmOT5lDwryzIvSgr-KU&e=
>
>
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Best option would be the coloring scheme along with explicit excludes in
the config for the LSPs you dont want to go through said device.

On Thu, Jan 24, 2019 at 3:25 PM Luis Balbinot <luis@luisbalbinot.com> wrote:

> That’s a good idea. I’m not 100% sure that this will prevent the creation
> of bypass LSPs but I’ll give it a try.
>
> Thanks!
>
> Luis
>
> On Thu, 24 Jan 2019 at 18:01 Colby Barth <cbarth@juniper.net> wrote:
>
> > Luis-
> >
> > You could probably set the overload bit.
> >
> > -Colby
> >
> > ?On 1/24/19, 1:10 PM, "juniper-nsp on behalf of Dave Bell" <
> > juniper-nsp-bounces@puck.nether.net on behalf of me@geordish.org> wrote:
> >
> > I'm not aware of any option that will do this.
> >
> > The three solutions that I can think of are:
> > Link colouring like Adam suggests
> > An explicit path that avoids the interfaces you are worried about
> > Set the RSVP cost for the interfaces really high
> >
> > Dave
> >
> > On Thu, 24 Jan 2019 at 17:01, Luis Balbinot <luis@luisbalbinot.com>
> > wrote:
> >
> > > It's a permanent thing.
> > >
> > > These boxes are PE routers that are not supposed to handle transit
> > > traffic but during certain network events a few FRR bypass LSPs are
> > > established through them because that's the only remaining path.
> > >
> > > Something easier like a "no-eligible-backup" toggle like the one we
> > > have with OSPF LFA would be nice.
> > >
> > > Luis
> > >
> > > On Thu, Jan 24, 2019 at 2:53 PM <adamv0025@netconsultings.com>
> > wrote:
> > > >
> > > > > Luis Balbinot
> > > > > Sent: Thursday, January 24, 2019 4:45 PM
> > > > >
> > > > > Hi.
> > > > >
> > > > > How could I prevent a device from getting transit RSVP LSPs
> being
> > > > > established through it? I only want it to accept ingress LSPs
> > destined
> > > to
> > > > that
> > > > > box.
> > > > >
> > > > If this is a permanent thing,
> > > > You could create a colouring scheme where all links connected to
> > this
> > > node
> > > > have to be avoided by all LSPs with the exception of LSPs
> > terminated on
> > > this
> > > > node (or originated by this node).
> > > >
> > > > If this is a maintenance thing,
> > > > There's a command that can be enabled to drain all transit LSPs
> > out the
> > > box.
> > > > But, all the LSPs would need to be configured with this
> capability
> > in the
> > > > first place.
> > > >
> > > >
> > > > adam
> > > >
> > > _______________________________________________
> > > juniper-nsp mailing list juniper-nsp@puck.nether.net
> > >
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_juniper-2Dnsp&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3lVLtwWQROCdl4DSF6Gy-pAupMaX1AvOyICNqk7ML5U&m=xjETS_MpBQ5yJFgNOTwIgxvck93EOjA7sbBBzWEr7sE&s=fIjs_f4CA6mUSiUhoRhAYrV4mmOT5lDwryzIvSgr-KU&e=
> > >
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp@puck.nether.net
> >
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_juniper-2Dnsp&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3lVLtwWQROCdl4DSF6Gy-pAupMaX1AvOyICNqk7ML5U&m=xjETS_MpBQ5yJFgNOTwIgxvck93EOjA7sbBBzWEr7sE&s=fIjs_f4CA6mUSiUhoRhAYrV4mmOT5lDwryzIvSgr-KU&e=
> >
> >
> >
> _______________________________________________
> 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 24/Jan/19 22:24, Luis Balbinot wrote:

> That’s a good idea. I’m not 100% sure that this will prevent the creation
> of bypass LSPs but I’ll give it a try.

In theory, that should work, as the node will, effectively, be taken out
of the IS-IS path (and all ensuing support services).

Would be interested to hear how this works out.

Mark.

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

It works. The only drawback is that all metrics on the local routing
table (not only for advertised LSAs) were increased by 65535. That's a
bit annoying but works just fine. The increase is relative to the
actual metric so we'll see values above 65535.

Not sure if I'm moving to this approach or just keep using a very
large metric on those links.

Luis

On Fri, Jan 25, 2019 at 7:02 AM Mark Tinka <mark.tinka@seacom.mu> wrote:
>
>
>
> On 24/Jan/19 22:24, Luis Balbinot wrote:
>
> > That’s a good idea. I’m not 100% sure that this will prevent the creation
> > of bypass LSPs but I’ll give it a try.
>
> In theory, that should work, as the node will, effectively, be taken out
> of the IS-IS path (and all ensuing support services).
>
> Would be interested to hear how this works out.
>
> Mark.
>
> _______________________________________________
> 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 25/Jan/19 14:53, Luis Balbinot wrote:

> It works. The only drawback is that all metrics on the local routing
> table (not only for advertised LSAs) were increased by 65535. That's a
> bit annoying but works just fine. The increase is relative to the
> actual metric so we'll see values above 65535.

Yes, that's what the Overload Bit is supposed to do. It should "steer
away" any and all traffic that is not terminating on the box itself.

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

I’m testing a similar approach (except using the ISIS overload bit) that aims to prevent the path between a pair of LSRs via the links to and through my RRs from being considered as a possible transit path. Seems to work just fine in the lab.

> On Jan 24, 2019, at 3:24 PM, Luis Balbinot <luis@luisbalbinot.com> wrote:
>
> That’s a good idea. I’m not 100% sure that this will prevent the creation
> of bypass LSPs but I’ll give it a try.
>
> Thanks!
>
> Luis
>
> On Thu, 24 Jan 2019 at 18:01 Colby Barth <cbarth@juniper.net> wrote:
>
>> Luis-
>>
>> You could probably set the overload bit.
>>
>> -Colby
>>
>> ?On 1/24/19, 1:10 PM, "juniper-nsp on behalf of Dave Bell" <
>> juniper-nsp-bounces@puck.nether.net on behalf of me@geordish.org> wrote:
>>
>> I'm not aware of any option that will do this.
>>
>> The three solutions that I can think of are:
>> Link colouring like Adam suggests
>> An explicit path that avoids the interfaces you are worried about
>> Set the RSVP cost for the interfaces really high
>>
>> Dave
>>
>> On Thu, 24 Jan 2019 at 17:01, Luis Balbinot <luis@luisbalbinot.com>
>> wrote:
>>
>>> It's a permanent thing.
>>>
>>> These boxes are PE routers that are not supposed to handle transit
>>> traffic but during certain network events a few FRR bypass LSPs are
>>> established through them because that's the only remaining path.
>>>
>>> Something easier like a "no-eligible-backup" toggle like the one we
>>> have with OSPF LFA would be nice.
>>>
>>> Luis
>>>
>>> On Thu, Jan 24, 2019 at 2:53 PM <adamv0025@netconsultings.com>
>> wrote:
>>>>
>>>>> Luis Balbinot
>>>>> Sent: Thursday, January 24, 2019 4:45 PM
>>>>>
>>>>> Hi.
>>>>>
>>>>> How could I prevent a device from getting transit RSVP LSPs being
>>>>> established through it? I only want it to accept ingress LSPs
>> destined
>>> to
>>>> that
>>>>> box.
>>>>>
>>>> If this is a permanent thing,
>>>> You could create a colouring scheme where all links connected to
>> this
>>> node
>>>> have to be avoided by all LSPs with the exception of LSPs
>> terminated on
>>> this
>>>> node (or originated by this node).
>>>>
>>>> If this is a maintenance thing,
>>>> There's a command that can be enabled to drain all transit LSPs
>> out the
>>> box.
>>>> But, all the LSPs would need to be configured with this capability
>> in the
>>>> first place.
>>>>
>>>>
>>>> adam
>>>>
>>> _______________________________________________
>>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_juniper-2Dnsp&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3lVLtwWQROCdl4DSF6Gy-pAupMaX1AvOyICNqk7ML5U&m=xjETS_MpBQ5yJFgNOTwIgxvck93EOjA7sbBBzWEr7sE&s=fIjs_f4CA6mUSiUhoRhAYrV4mmOT5lDwryzIvSgr-KU&e=
>>>
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_juniper-2Dnsp&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3lVLtwWQROCdl4DSF6Gy-pAupMaX1AvOyICNqk7ML5U&m=xjETS_MpBQ5yJFgNOTwIgxvck93EOjA7sbBBzWEr7sE&s=fIjs_f4CA6mUSiUhoRhAYrV4mmOT5lDwryzIvSgr-KU&e=
>>
>>
>>
> _______________________________________________
> 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

Please let me know if you find some other approach.

The overload bit helps but in the absence of another path the RSVP FRR
mechanism will setup a bypass LSP through a node with the overload bit
set. And link coloring does not help, at least in my case.

Luis

On Fri, Jan 25, 2019 at 11:20 AM Jason Lixfeld <jason-jnsp@lixfeld.ca> wrote:
>
> I’m testing a similar approach (except using the ISIS overload bit) that aims to prevent the path between a pair of LSRs via the links to and through my RRs from being considered as a possible transit path. Seems to work just fine in the lab.
>
> > On Jan 24, 2019, at 3:24 PM, Luis Balbinot <luis@luisbalbinot.com> wrote:
> >
> > That’s a good idea. I’m not 100% sure that this will prevent the creation
> > of bypass LSPs but I’ll give it a try.
> >
> > Thanks!
> >
> > Luis
> >
> > On Thu, 24 Jan 2019 at 18:01 Colby Barth <cbarth@juniper.net> wrote:
> >
> >> Luis-
> >>
> >> You could probably set the overload bit.
> >>
> >> -Colby
> >>
> >> ?On 1/24/19, 1:10 PM, "juniper-nsp on behalf of Dave Bell" <
> >> juniper-nsp-bounces@puck.nether.net on behalf of me@geordish.org> wrote:
> >>
> >> I'm not aware of any option that will do this.
> >>
> >> The three solutions that I can think of are:
> >> Link colouring like Adam suggests
> >> An explicit path that avoids the interfaces you are worried about
> >> Set the RSVP cost for the interfaces really high
> >>
> >> Dave
> >>
> >> On Thu, 24 Jan 2019 at 17:01, Luis Balbinot <luis@luisbalbinot.com>
> >> wrote:
> >>
> >>> It's a permanent thing.
> >>>
> >>> These boxes are PE routers that are not supposed to handle transit
> >>> traffic but during certain network events a few FRR bypass LSPs are
> >>> established through them because that's the only remaining path.
> >>>
> >>> Something easier like a "no-eligible-backup" toggle like the one we
> >>> have with OSPF LFA would be nice.
> >>>
> >>> Luis
> >>>
> >>> On Thu, Jan 24, 2019 at 2:53 PM <adamv0025@netconsultings.com>
> >> wrote:
> >>>>
> >>>>> Luis Balbinot
> >>>>> Sent: Thursday, January 24, 2019 4:45 PM
> >>>>>
> >>>>> Hi.
> >>>>>
> >>>>> How could I prevent a device from getting transit RSVP LSPs being
> >>>>> established through it? I only want it to accept ingress LSPs
> >> destined
> >>> to
> >>>> that
> >>>>> box.
> >>>>>
> >>>> If this is a permanent thing,
> >>>> You could create a colouring scheme where all links connected to
> >> this
> >>> node
> >>>> have to be avoided by all LSPs with the exception of LSPs
> >> terminated on
> >>> this
> >>>> node (or originated by this node).
> >>>>
> >>>> If this is a maintenance thing,
> >>>> There's a command that can be enabled to drain all transit LSPs
> >> out the
> >>> box.
> >>>> But, all the LSPs would need to be configured with this capability
> >> in the
> >>>> first place.
> >>>>
> >>>>
> >>>> adam
> >>>>
> >>> _______________________________________________
> >>> juniper-nsp mailing list juniper-nsp@puck.nether.net
> >>>
> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_juniper-2Dnsp&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3lVLtwWQROCdl4DSF6Gy-pAupMaX1AvOyICNqk7ML5U&m=xjETS_MpBQ5yJFgNOTwIgxvck93EOjA7sbBBzWEr7sE&s=fIjs_f4CA6mUSiUhoRhAYrV4mmOT5lDwryzIvSgr-KU&e=
> >>>
> >> _______________________________________________
> >> juniper-nsp mailing list juniper-nsp@puck.nether.net
> >>
> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_juniper-2Dnsp&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3lVLtwWQROCdl4DSF6Gy-pAupMaX1AvOyICNqk7ML5U&m=xjETS_MpBQ5yJFgNOTwIgxvck93EOjA7sbBBzWEr7sE&s=fIjs_f4CA6mUSiUhoRhAYrV4mmOT5lDwryzIvSgr-KU&e=
> >>
> >>
> >>
> > _______________________________________________
> > 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

So I missed your specific comment about being concerned about the bypass
LSPs.

I think (although I haven't tested this in forever) if you enable
no-node-protection under RSVP , that will prevent those interfaces from
being available for any node or link bypass LSP to use.

On Fri, Jan 25, 2019 at 11:51 AM Luis Balbinot <luis@luisbalbinot.com>
wrote:

> Please let me know if you find some other approach.
>
> The overload bit helps but in the absence of another path the RSVP FRR
> mechanism will setup a bypass LSP through a node with the overload bit
> set. And link coloring does not help, at least in my case.
>
> Luis
>
> On Fri, Jan 25, 2019 at 11:20 AM Jason Lixfeld <jason-jnsp@lixfeld.ca>
> wrote:
> >
> > I’m testing a similar approach (except using the ISIS overload bit) that
> aims to prevent the path between a pair of LSRs via the links to and
> through my RRs from being considered as a possible transit path. Seems to
> work just fine in the lab.
> >
> > > On Jan 24, 2019, at 3:24 PM, Luis Balbinot <luis@luisbalbinot.com>
> wrote:
> > >
> > > That’s a good idea. I’m not 100% sure that this will prevent the
> creation
> > > of bypass LSPs but I’ll give it a try.
> > >
> > > Thanks!
> > >
> > > Luis
> > >
> > > On Thu, 24 Jan 2019 at 18:01 Colby Barth <cbarth@juniper.net> wrote:
> > >
> > >> Luis-
> > >>
> > >> You could probably set the overload bit.
> > >>
> > >> -Colby
> > >>
> > >> ?On 1/24/19, 1:10 PM, "juniper-nsp on behalf of Dave Bell" <
> > >> juniper-nsp-bounces@puck.nether.net on behalf of me@geordish.org>
> wrote:
> > >>
> > >> I'm not aware of any option that will do this.
> > >>
> > >> The three solutions that I can think of are:
> > >> Link colouring like Adam suggests
> > >> An explicit path that avoids the interfaces you are worried about
> > >> Set the RSVP cost for the interfaces really high
> > >>
> > >> Dave
> > >>
> > >> On Thu, 24 Jan 2019 at 17:01, Luis Balbinot <luis@luisbalbinot.com
> >
> > >> wrote:
> > >>
> > >>> It's a permanent thing.
> > >>>
> > >>> These boxes are PE routers that are not supposed to handle transit
> > >>> traffic but during certain network events a few FRR bypass LSPs are
> > >>> established through them because that's the only remaining path.
> > >>>
> > >>> Something easier like a "no-eligible-backup" toggle like the one we
> > >>> have with OSPF LFA would be nice.
> > >>>
> > >>> Luis
> > >>>
> > >>> On Thu, Jan 24, 2019 at 2:53 PM <adamv0025@netconsultings.com>
> > >> wrote:
> > >>>>
> > >>>>> Luis Balbinot
> > >>>>> Sent: Thursday, January 24, 2019 4:45 PM
> > >>>>>
> > >>>>> Hi.
> > >>>>>
> > >>>>> How could I prevent a device from getting transit RSVP LSPs being
> > >>>>> established through it? I only want it to accept ingress LSPs
> > >> destined
> > >>> to
> > >>>> that
> > >>>>> box.
> > >>>>>
> > >>>> If this is a permanent thing,
> > >>>> You could create a colouring scheme where all links connected to
> > >> this
> > >>> node
> > >>>> have to be avoided by all LSPs with the exception of LSPs
> > >> terminated on
> > >>> this
> > >>>> node (or originated by this node).
> > >>>>
> > >>>> If this is a maintenance thing,
> > >>>> There's a command that can be enabled to drain all transit LSPs
> > >> out the
> > >>> box.
> > >>>> But, all the LSPs would need to be configured with this capability
> > >> in the
> > >>>> first place.
> > >>>>
> > >>>>
> > >>>> adam
> > >>>>
> > >>> _______________________________________________
> > >>> juniper-nsp mailing list juniper-nsp@puck.nether.net
> > >>>
> > >>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_juniper-2Dnsp&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3lVLtwWQROCdl4DSF6Gy-pAupMaX1AvOyICNqk7ML5U&m=xjETS_MpBQ5yJFgNOTwIgxvck93EOjA7sbBBzWEr7sE&s=fIjs_f4CA6mUSiUhoRhAYrV4mmOT5lDwryzIvSgr-KU&e=
> > >>>
> > >> _______________________________________________
> > >> juniper-nsp mailing list juniper-nsp@puck.nether.net
> > >>
> > >>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_juniper-2Dnsp&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3lVLtwWQROCdl4DSF6Gy-pAupMaX1AvOyICNqk7ML5U&m=xjETS_MpBQ5yJFgNOTwIgxvck93EOjA7sbBBzWEr7sE&s=fIjs_f4CA6mUSiUhoRhAYrV4mmOT5lDwryzIvSgr-KU&e=
> > >>
> > >>
> > >>
> > > _______________________________________________
> > > 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
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

I've tried that before but those settings under RSVP don't seem to
affect FRR LSPs. I tried that at the node I don't want to allow
transit LSPs and at the previous node to that.

Am I missing something? There has to be a way to avoid it. I have
around 5000 tunnels in my production network and I don't want them
accidentally going through an ACX5k box, for instance, in case of a
catastrophic failure.

Luis


Luis

On Fri, Jan 25, 2019 at 4:32 PM Tom Beecher <beecher@beecher.cc> wrote:
>
> So I missed your specific comment about being concerned about the bypass LSPs.
>
> I think (although I haven't tested this in forever) if you enable no-node-protection under RSVP , that will prevent those interfaces from being available for any node or link bypass LSP to use.
>
> On Fri, Jan 25, 2019 at 11:51 AM Luis Balbinot <luis@luisbalbinot.com> wrote:
>>
>> Please let me know if you find some other approach.
>>
>> The overload bit helps but in the absence of another path the RSVP FRR
>> mechanism will setup a bypass LSP through a node with the overload bit
>> set. And link coloring does not help, at least in my case.
>>
>> Luis
>>
>> On Fri, Jan 25, 2019 at 11:20 AM Jason Lixfeld <jason-jnsp@lixfeld.ca> wrote:
>> >
>> > I’m testing a similar approach (except using the ISIS overload bit) that aims to prevent the path between a pair of LSRs via the links to and through my RRs from being considered as a possible transit path. Seems to work just fine in the lab.
>> >
>> > > On Jan 24, 2019, at 3:24 PM, Luis Balbinot <luis@luisbalbinot.com> wrote:
>> > >
>> > > That’s a good idea. I’m not 100% sure that this will prevent the creation
>> > > of bypass LSPs but I’ll give it a try.
>> > >
>> > > Thanks!
>> > >
>> > > Luis
>> > >
>> > > On Thu, 24 Jan 2019 at 18:01 Colby Barth <cbarth@juniper.net> wrote:
>> > >
>> > >> Luis-
>> > >>
>> > >> You could probably set the overload bit.
>> > >>
>> > >> -Colby
>> > >>
>> > >> ?On 1/24/19, 1:10 PM, "juniper-nsp on behalf of Dave Bell" <
>> > >> juniper-nsp-bounces@puck.nether.net on behalf of me@geordish.org> wrote:
>> > >>
>> > >> I'm not aware of any option that will do this.
>> > >>
>> > >> The three solutions that I can think of are:
>> > >> Link colouring like Adam suggests
>> > >> An explicit path that avoids the interfaces you are worried about
>> > >> Set the RSVP cost for the interfaces really high
>> > >>
>> > >> Dave
>> > >>
>> > >> On Thu, 24 Jan 2019 at 17:01, Luis Balbinot <luis@luisbalbinot.com>
>> > >> wrote:
>> > >>
>> > >>> It's a permanent thing.
>> > >>>
>> > >>> These boxes are PE routers that are not supposed to handle transit
>> > >>> traffic but during certain network events a few FRR bypass LSPs are
>> > >>> established through them because that's the only remaining path.
>> > >>>
>> > >>> Something easier like a "no-eligible-backup" toggle like the one we
>> > >>> have with OSPF LFA would be nice.
>> > >>>
>> > >>> Luis
>> > >>>
>> > >>> On Thu, Jan 24, 2019 at 2:53 PM <adamv0025@netconsultings.com>
>> > >> wrote:
>> > >>>>
>> > >>>>> Luis Balbinot
>> > >>>>> Sent: Thursday, January 24, 2019 4:45 PM
>> > >>>>>
>> > >>>>> Hi.
>> > >>>>>
>> > >>>>> How could I prevent a device from getting transit RSVP LSPs being
>> > >>>>> established through it? I only want it to accept ingress LSPs
>> > >> destined
>> > >>> to
>> > >>>> that
>> > >>>>> box.
>> > >>>>>
>> > >>>> If this is a permanent thing,
>> > >>>> You could create a colouring scheme where all links connected to
>> > >> this
>> > >>> node
>> > >>>> have to be avoided by all LSPs with the exception of LSPs
>> > >> terminated on
>> > >>> this
>> > >>>> node (or originated by this node).
>> > >>>>
>> > >>>> If this is a maintenance thing,
>> > >>>> There's a command that can be enabled to drain all transit LSPs
>> > >> out the
>> > >>> box.
>> > >>>> But, all the LSPs would need to be configured with this capability
>> > >> in the
>> > >>>> first place.
>> > >>>>
>> > >>>>
>> > >>>> adam
>> > >>>>
>> > >>> _______________________________________________
>> > >>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> > >>>
>> > >> https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_juniper-2Dnsp&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3lVLtwWQROCdl4DSF6Gy-pAupMaX1AvOyICNqk7ML5U&m=xjETS_MpBQ5yJFgNOTwIgxvck93EOjA7sbBBzWEr7sE&s=fIjs_f4CA6mUSiUhoRhAYrV4mmOT5lDwryzIvSgr-KU&e=
>> > >>>
>> > >> _______________________________________________
>> > >> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> > >>
>> > >> https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_juniper-2Dnsp&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3lVLtwWQROCdl4DSF6Gy-pAupMaX1AvOyICNqk7ML5U&m=xjETS_MpBQ5yJFgNOTwIgxvck93EOjA7sbBBzWEr7sE&s=fIjs_f4CA6mUSiUhoRhAYrV4mmOT5lDwryzIvSgr-KU&e=
>> > >>
>> > >>
>> > >>
>> > > _______________________________________________
>> > > 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
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Hello,

On 25/01/2019 16:50, Luis Balbinot wrote:
> Please let me know if you find some other approach.
>
> The overload bit helps but in the absence of another path the RSVP FRR
> mechanism will setup a bypass LSP through a node with the overload bit
> set. And link coloring does not help, at least in my case.
>
> Luis
This observation of Yours coupled with Your earlier statement about link
metric being 65535 when You configure "overload" speaks of OSPF
"overload" JUNOS feature/knob being used, not ISIS "Overload"/OL bit.

OSPF "overload" feature is drastically different from ISIS "Overload"/OL
: OSPF "overload" is not actually a bit. It is a mock-up of what ISIS
SPF does when it encounters an LSP with true OL bit set.

And this OSPF mock-up is very dissimilar and should not be called
"overload" in 1st place.

Thanks

Alex


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

> Luis Balbinot
> Sent: Friday, January 25, 2019 4:50 PM
>
> And link coloring does not help, at least in my case.
>
Not sure which method are you using for the FRR LSPs but you should be able to specify colouring constrains for the bypass LSPs to exclude specific colours (even though they are dynamically created.

adam

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

> From: Luis Balbinot <luis@luisbalbinot.com>
> Sent: Monday, January 28, 2019 1:39 PM
>
> I have many LSPs from P1 to P4 and all have FRR protection (Juniper FRR, 1:1).
> Even with two distinct paths from P1 to P4 (both with much lower IGP
> metrics) I get some detour LSPs setup on PE1. PE1 is a low-end ACX5k with
> very limited transit capabilities and I definitely don't want any transit traffic
> through it.
>
> I could color the green links and call them "p-pe" for example but I can't just
> exclude all "p-pe" links from the FRR selection. If I setup an LSP from P1 to
> PE1 the CSPF path will be P1->P2->PE1 and I'll need the P1->P2->P3->PE1
> path for protection, but that can't be setup because it has a "p-pe" member
> in the path.
>
> P2->PE1 and P3->PE1 share the same fate as P2->P3, but even with SRLG
> it is not guaranteed that LSPs won't be setup over the PE1 circuits.
>
I think what could be done in this topology is to mark the P2-PE1 and P3-PE1 links with special colour (say green for the sake of this example).
1) Now as for the RSVP-TE signalled LSPs between P routers (e.g. between P1 and P4)
Those would be set up to exclude green colour when signalling their detour LSPs.
[edit protocols mpls label-switched-path LSP_P1_TO_P4]
set fast-reroute exclude GREEN
2) only LSPs to PE1 will have no such constrain configured for their detour LSPS.
And thus will be able to use the P2-PE1 and P3-PE1 links in order to protect the last leg of the path towards PE1

adam


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

Yes it can, but it won't scale. There are lots of PE routers with the same
situation.

I was expecting for a simple configuration knob to avoid detour LSPs but
there seems to be none.

Breaking the OSPF areas could be an option but I don't see anything working
differently if I export the TED via BGP to those routers as the CSFP would
find its way through those routers once again.

Today I don't have any issues because all PE routers are using tunneled
LDP. But since there's no flexibility on how we can control which FEC takes
each tunnel I'm having to extend RSVP all the way to the PEs.

Luis

On Tue, 29 Jan 2019 at 07:03 <adamv0025@netconsultings.com> wrote:

> > From: Luis Balbinot <luis@luisbalbinot.com>
> > Sent: Monday, January 28, 2019 1:39 PM
> >
> > I have many LSPs from P1 to P4 and all have FRR protection (Juniper FRR,
> 1:1).
> > Even with two distinct paths from P1 to P4 (both with much lower IGP
> > metrics) I get some detour LSPs setup on PE1. PE1 is a low-end ACX5k with
> > very limited transit capabilities and I definitely don't want any
> transit traffic
> > through it.
> >
> > I could color the green links and call them "p-pe" for example but I
> can't just
> > exclude all "p-pe" links from the FRR selection. If I setup an LSP from
> P1 to
> > PE1 the CSPF path will be P1->P2->PE1 and I'll need the P1->P2->P3->PE1
> > path for protection, but that can't be setup because it has a "p-pe"
> member
> > in the path.
> >
> > P2->PE1 and P3->PE1 share the same fate as P2->P3, but even with SRLG
> > it is not guaranteed that LSPs won't be setup over the PE1 circuits.
> >
> I think what could be done in this topology is to mark the P2-PE1 and
> P3-PE1 links with special colour (say green for the sake of this example).
> 1) Now as for the RSVP-TE signalled LSPs between P routers (e.g. between
> P1 and P4)
> Those would be set up to exclude green colour when signalling their detour
> LSPs.
> [edit protocols mpls label-switched-path LSP_P1_TO_P4]
> set fast-reroute exclude GREEN
> 2) only LSPs to PE1 will have no such constrain configured for their
> detour LSPS.
> And thus will be able to use the P2-PE1 and P3-PE1 links in order to
> protect the last leg of the path towards PE1
>
> adam
>
>
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp