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 <beec...@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 <l...@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-j...@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 <l...@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 <cba...@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-boun...@puck.nether.net on behalf of m...@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 <l...@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 <adamv0...@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