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
