[j-nsp] Avoid transit LSPs

[Luis Balbinot]

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 at 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 at 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 at 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 at 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 at 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 at puck.nether.net on behalf of me at 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 at 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 at 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 at 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 at 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 at puck.nether.net
>> > > https://puck.nether.net/mailman/listinfo/juniper-nsp
>> >
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp