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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: > > > >> Luis- > >> > >> You could probably set the overload bit. > >> > >> -Colby > >> > >> On 1/24/19, 1:10 PM, "juniper-nsp on behalf of Dave Bell" < > >> [email protected] on behalf of [email protected]> 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 <[email protected]> > >> 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 <[email protected]> > >> 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 [email protected] > >>> > >> 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 [email protected] > >> > >> 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 [email protected] > > https://puck.nether.net/mailman/listinfo/juniper-nsp > _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
