Re: [j-nsp] Avoid transit LSPs
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 wrote: > > From: Luis Balbinot > > 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
Re: [j-nsp] Avoid transit LSPs
> From: Luis Balbinot > 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
Re: [j-nsp] Avoid transit LSPs
> 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
Re: [j-nsp] Avoid transit LSPs
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
Re: [j-nsp] Avoid transit LSPs
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 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 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 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 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 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 >> > >> 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 >> > >> 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=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=3lVLtwWQROCdl4DSF6Gy-pAupMaX1AvOyICNqk7ML5U=xjETS_MpBQ5yJFgNOTwIgxvck93EOjA7sbBBzWEr7sE=fIjs_f4CA6mUSiUhoRhAYrV4mmOT5lDwryzIvSgr-KU= >> > >>> >> > >>___ >> > >>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=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=3lVLtwWQROCdl4DSF6Gy-pAupMaX1AvOyICNqk7ML5U=xjETS_MpBQ5yJFgNOTwIgxvck93EOjA7sbBBzWEr7sE=fIjs_f4CA6mUSiUhoRhAYrV4mmOT5lDwryzIvSgr-KU= >> > >> >> > >> >> > >> >> > > ___ >> > > juniper-nsp mailing list juniper-nsp@puck.nether.net >> > > https://puck.nether.net/mailman/listinfo/juniper-nsp >> > >> ___ >> juniper-nsp mailing list
Re: [j-nsp] Avoid transit LSPs
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 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 > 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 > 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 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 > > > >> 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 > > >> 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=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=3lVLtwWQROCdl4DSF6Gy-pAupMaX1AvOyICNqk7ML5U=xjETS_MpBQ5yJFgNOTwIgxvck93EOjA7sbBBzWEr7sE=fIjs_f4CA6mUSiUhoRhAYrV4mmOT5lDwryzIvSgr-KU= > > >>> > > >>___ > > >>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=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=3lVLtwWQROCdl4DSF6Gy-pAupMaX1AvOyICNqk7ML5U=xjETS_MpBQ5yJFgNOTwIgxvck93EOjA7sbBBzWEr7sE=fIjs_f4CA6mUSiUhoRhAYrV4mmOT5lDwryzIvSgr-KU= > > >> > > >> > > >> > > > ___ > > > 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
Re: [j-nsp] Avoid transit LSPs
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 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 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 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 > >> 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 > >> 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=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=3lVLtwWQROCdl4DSF6Gy-pAupMaX1AvOyICNqk7ML5U=xjETS_MpBQ5yJFgNOTwIgxvck93EOjA7sbBBzWEr7sE=fIjs_f4CA6mUSiUhoRhAYrV4mmOT5lDwryzIvSgr-KU= > >>> > >>___ > >>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=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=3lVLtwWQROCdl4DSF6Gy-pAupMaX1AvOyICNqk7ML5U=xjETS_MpBQ5yJFgNOTwIgxvck93EOjA7sbBBzWEr7sE=fIjs_f4CA6mUSiUhoRhAYrV4mmOT5lDwryzIvSgr-KU= > >> > >> > >> > > ___ > > 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
Re: [j-nsp] Avoid transit LSPs
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 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 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 >> 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 >> 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=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=3lVLtwWQROCdl4DSF6Gy-pAupMaX1AvOyICNqk7ML5U=xjETS_MpBQ5yJFgNOTwIgxvck93EOjA7sbBBzWEr7sE=fIjs_f4CA6mUSiUhoRhAYrV4mmOT5lDwryzIvSgr-KU= >>> >>___ >>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=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=3lVLtwWQROCdl4DSF6Gy-pAupMaX1AvOyICNqk7ML5U=xjETS_MpBQ5yJFgNOTwIgxvck93EOjA7sbBBzWEr7sE=fIjs_f4CA6mUSiUhoRhAYrV4mmOT5lDwryzIvSgr-KU= >> >> >> > ___ > 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
Re: [j-nsp] Avoid transit LSPs
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
Re: [j-nsp] Avoid transit LSPs
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 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
Re: [j-nsp] Avoid transit LSPs
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
Re: [j-nsp] Avoid transit LSPs
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 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 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 > > 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 > > 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=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=3lVLtwWQROCdl4DSF6Gy-pAupMaX1AvOyICNqk7ML5U=xjETS_MpBQ5yJFgNOTwIgxvck93EOjA7sbBBzWEr7sE=fIjs_f4CA6mUSiUhoRhAYrV4mmOT5lDwryzIvSgr-KU= > > > > > ___ > > 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=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=3lVLtwWQROCdl4DSF6Gy-pAupMaX1AvOyICNqk7ML5U=xjETS_MpBQ5yJFgNOTwIgxvck93EOjA7sbBBzWEr7sE=fIjs_f4CA6mUSiUhoRhAYrV4mmOT5lDwryzIvSgr-KU= > > > > > > > ___ > 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
Re: [j-nsp] Avoid transit LSPs
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 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 > 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 > 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=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=3lVLtwWQROCdl4DSF6Gy-pAupMaX1AvOyICNqk7ML5U=xjETS_MpBQ5yJFgNOTwIgxvck93EOjA7sbBBzWEr7sE=fIjs_f4CA6mUSiUhoRhAYrV4mmOT5lDwryzIvSgr-KU= > > > ___ > 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=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=3lVLtwWQROCdl4DSF6Gy-pAupMaX1AvOyICNqk7ML5U=xjETS_MpBQ5yJFgNOTwIgxvck93EOjA7sbBBzWEr7sE=fIjs_f4CA6mUSiUhoRhAYrV4mmOT5lDwryzIvSgr-KU= > > > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Avoid transit LSPs
Luis- You could probably set the overload bit. -Colby On 1/24/19, 1:10 PM, "juniper-nsp on behalf of Dave Bell" 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 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 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=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=3lVLtwWQROCdl4DSF6Gy-pAupMaX1AvOyICNqk7ML5U=xjETS_MpBQ5yJFgNOTwIgxvck93EOjA7sbBBzWEr7sE=fIjs_f4CA6mUSiUhoRhAYrV4mmOT5lDwryzIvSgr-KU= > ___ 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=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=3lVLtwWQROCdl4DSF6Gy-pAupMaX1AvOyICNqk7ML5U=xjETS_MpBQ5yJFgNOTwIgxvck93EOjA7sbBBzWEr7sE=fIjs_f4CA6mUSiUhoRhAYrV4mmOT5lDwryzIvSgr-KU= ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Avoid transit LSPs
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 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 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
Re: [j-nsp] Avoid transit LSPs
> 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
Re: [j-nsp] Avoid transit LSPs
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 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
[j-nsp] Avoid transit LSPs
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. Luis ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
