Re: [j-nsp] RSVP-TE broken between pre and post 16.1 code?
> From: Nathan Ward > Sent: Friday, August 16, 2019 11:20 AM > > Weird that the refresh timer <1200 triggers it. Do you mean the refresh timer > in the time values object is 1200 - i.e. 1.2s? JunOS default is 30,000 (30s), > 1200 > seems very short, or very long? Certainly it sounds like a bug, but, I’m > curious > why you’d have timers like that.. > The refresh timer is in seconds, The idea was to change the refresh timer from 30s to 1200s among other settings to match with the post 16.1 defaults, so when there's time to upgrade these settings would match for better interop -but in this case it totally backfired. adam ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] RSVP-TE broken between pre and post 16.1 code?
Could it be: Number PR1443811 Title RSVP refresh-timer interoperability between 15.1 and 16.1+ Release Note Path message with long refresh interval (equal to or more than 20 minutes) from a node that does not support Refresh-interval Independent RSVP (RI-RSVP) is dropped by the receiver with RI-RSVP. SeverityMinor Status Open Last Modified 2019-07-26 08:51:18 EDT Resolved In Release junos 18.3R3 x 18.4R3 x 17.4R3 x 19.2R2 x 19.3R1 x 19.1R2 x Product J Series, M Series, T Series, MX-series, EX Series, SRX Series, QFX Series, NFX Series, PTX Series Functional Area software Feature Group Multiprotocol Label Switching (MPLS) Workaround 1. Use default rsvp refresh-time config. No config is needed. 30 seconds in 15.1 and 20 minutes in 16.1+ 2. If you must configure rsvp refresh-time, configure it to be less than 20 minutes. set protocols rsvp refresh-time 1199 Problem Starting with Junos OS Release 16.1, RSVP Traffic Engineering (TE) protocol extensions to support Refresh-interval Independent RSVP (RI-RSVP) defined RFC 8370 for fast reroute (FRR) facility protection were introduced to allow greater scalability of label-switched paths (LSPs) faster convergence times and decrease RSVP signaling message overhead from periodic refreshes. RI-RSVP mode is enabled by default and includes protocol extensions to support RI-RSVP for FRR facility bypass originally specified in RFC 4090. The default refresh time for RSVP messages has increased from 30 seconds to 20 minutes. In mixed environments, where a subset of LSPs traverse nodes that do not include this feature, Junos RSVP-TE running in enhanced FRR mode will automatically turn off the new protocol extensions in its signaling exchanges with nodes that do not support the new extensions. However, path messages with long refresh interval (equal to or more than 20 minutes) from such nodes will be dropped by the receiver with RI-RSVP. It is assumed that non-RI-RSVP nodes should have lower refresh time because it is used for failure detection in non-RI-RSVP environments. With this fix, configuring 'no-enhanced-frr-bypass' on 16.1+ nodes will solve the silent path message drop and will allow 20 minutes and higher refresh times to be used on non-RI-RSVP nodes. Triggers - 'protocols rsvp refresh-time 1200' or higher is used on a non-RI-RSVP node (Junos <16.1). - There is a RI-RSVP (16.1 or later) node after non-RI-RSVP node. Kind regards, Andrey Kostin adamv0...@netconsultings.com писал 2019-08-16 06:01: From: Nathan Ward Sent: Friday, August 16, 2019 8:39 AM > On 1/07/2019, at 9:59 PM, adamv0...@netconsultings.com wrote: > >> From: Michael Hare >> Sent: Friday, June 28, 2019 7:02 PM >> >> Adam- >> >> Have you accounted for this behavioral change? >> >> https://kb.juniper.net/InfoCenter/index?page=content=KB32883= >> print=LIST==currentpaging >> > Thank you, yes please we're aware of that, but even with this the > issue is still present if the refresh timer is not <1200 or CSPF is enabled. I’m confused by this one - what’s the refresh timer and CSPF got to do with it? Not much it's a bug, it appears form the logs that the path message has "something different" in the ERO when CSPF is enabled triggering the bug ... LSPs on 16.1 will do self-ping after they come up before they put traffic on them. The lo0 filter has to permit that, or you’ve got to disable self-ping. LSPs will do self ping when switching onto a new/optimized path, not when the LSP is first brought up -which in this case doesn’t happen. Or am I parsing this weird, and you’re saying this is still an issue even with the self ping disabled (or permitted in filters), under those conditions? Yes that is correct, this problem appears even before the self-ping is engaged (the LSP is not even signalled -the RESV msg is never sent as a response to PATH msg in this case). 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] RSVP-TE broken between pre and post 16.1 code?
> On 16/08/2019, at 10:01 PM, > wrote: > > > >> From: Nathan Ward >> Sent: Friday, August 16, 2019 8:39 AM >> >>> On 1/07/2019, at 9:59 PM, adamv0...@netconsultings.com wrote: >>> From: Michael Hare Sent: Friday, June 28, 2019 7:02 PM Adam- Have you accounted for this behavioral change? >> https://kb.juniper.net/InfoCenter/index?page=content=KB32883= print=LIST==currentpaging >>> Thank you, yes please we're aware of that, but even with this the >>> issue is still present if the refresh timer is not <1200 or CSPF is enabled. >> >> I’m confused by this one - what’s the refresh timer and CSPF got to do with >> it? >> > Not much it's a bug, it appears form the logs that the path message has > "something different" in the ERO when CSPF is enabled triggering the bug ... > >> LSPs on 16.1 will do self-ping after they come up before they put traffic on >> them. The lo0 filter has to permit that, or you’ve got to disable self-ping. >> > LSPs will do self ping when switching onto a new/optimized path, not when the > LSP is first brought up -which in this case doesn’t happen. I am fairly certain they’ll do self ping on new LSPs as well. It’s, in theory, whenever the ingress LSR gets a RESV message - for either a new path, or a whole new LSP it doesn’t matter. >> Or am I parsing this weird, and you’re saying this is still an issue even >> with the >> self ping disabled (or permitted in filters), under those conditions? >> > Yes that is correct, this problem appears even before the self-ping is > engaged (the LSP is not even signalled -the RESV msg is never sent as a > response to PATH msg in this case). Yeah got it, that’s certainly Not Right. Weird that the refresh timer <1200 triggers it. Do you mean the refresh timer in the time values object is 1200 - i.e. 1.2s? JunOS default is 30,000 (30s), 1200 seems very short, or very long? Certainly it sounds like a bug, but, I’m curious why you’d have timers like that.. -- Nathan Ward ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] RSVP-TE broken between pre and post 16.1 code?
> From: Nathan Ward > Sent: Friday, August 16, 2019 8:39 AM > > > On 1/07/2019, at 9:59 PM, adamv0...@netconsultings.com wrote: > > > >> From: Michael Hare > >> Sent: Friday, June 28, 2019 7:02 PM > >> > >> Adam- > >> > >> Have you accounted for this behavioral change? > >> > >> > https://kb.juniper.net/InfoCenter/index?page=content=KB32883= > >> print=LIST==currentpaging > >> > > Thank you, yes please we're aware of that, but even with this the > > issue is still present if the refresh timer is not <1200 or CSPF is enabled. > > I’m confused by this one - what’s the refresh timer and CSPF got to do with > it? > Not much it's a bug, it appears form the logs that the path message has "something different" in the ERO when CSPF is enabled triggering the bug ... > LSPs on 16.1 will do self-ping after they come up before they put traffic on > them. The lo0 filter has to permit that, or you’ve got to disable self-ping. > LSPs will do self ping when switching onto a new/optimized path, not when the LSP is first brought up -which in this case doesn’t happen. > Or am I parsing this weird, and you’re saying this is still an issue even > with the > self ping disabled (or permitted in filters), under those conditions? > Yes that is correct, this problem appears even before the self-ping is engaged (the LSP is not even signalled -the RESV msg is never sent as a response to PATH msg in this case). adam ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] RSVP-TE broken between pre and post 16.1 code?
Looks like the PR about this is now available: PR1443811 «RSVP refresh-timer interoperability between 15.1 and 16.1+». «Path message with long refresh interval (equal to or more than 20 minutes) from a node that does not support Refresh-interval Independent RSVP (RI-RSVP) is dropped by the receiver with RI-RSVP.» > Le 2 juil. 2019 à 07:22, Simon Dixon a écrit : > > I had that issue between QFX5110's and MX's.Some feature at the time > forced me to run 17.4 on the QFX's and they wouldn't establish LSP's with > older MX80's in our fleet that were still running 14.2. > > I had to either downgrade the QFX's to 15.1 or upgrade the MX's to 16.1 or > greater. I ended up grading the MX's as they were overdue anyway. > > Simon. > > > On Fri, 28 Jun 2019 at 22:15, wrote: > >> Hi gents, >> >> Just wondering if anyone experienced RSVP-TE incompatibility issues when >> moving from pre 16.1 code to post 16.1 code. >> Didn't get much out of Juniper folks thus far so I figured I'll ask here as >> well. >> >> The problem we're facing is that in case 17 code is LSP head-end and 15 >> code >> is tail-end works, but in the opposite direction 17/15-to-17 (basically >> cases where 17 is the LSP tail-end) the LSP signalling fails. >> Trace reveals that the 17 gets the PATH message for bunch of LSPs, accepts >> it (yes reduction and acks are used), creates the session, then deletes it >> right away for some reason. >> Our testing suggests there are two workarounds for this: >> You might be aware that in 16.1 among other RSVP-TE changes the default >> refresh-time (governing generation of successive refresh messages >> Path/Resv) >> changed to 1200s -so no what you think making it 1200 on 15 side wont do, >> it >> has to be less (e.q. 1999s). >> If you want to keep refresh time at 1200 or higher then another option >> strangely enough is to disable CSPF on the affected LSPs (didn't know that >> SPF/CSPF changes contents of the PATH msg that in one case 17 code is cool >> with PATH msg in other case not). >> >> Would appreciate any pointers. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] RSVP-TE broken between pre and post 16.1 code?
I had that issue between QFX5110's and MX's.Some feature at the time forced me to run 17.4 on the QFX's and they wouldn't establish LSP's with older MX80's in our fleet that were still running 14.2. I had to either downgrade the QFX's to 15.1 or upgrade the MX's to 16.1 or greater. I ended up grading the MX's as they were overdue anyway. Simon. On Fri, 28 Jun 2019 at 22:15, wrote: > Hi gents, > > Just wondering if anyone experienced RSVP-TE incompatibility issues when > moving from pre 16.1 code to post 16.1 code. > Didn't get much out of Juniper folks thus far so I figured I'll ask here as > well. > > The problem we're facing is that in case 17 code is LSP head-end and 15 > code > is tail-end works, but in the opposite direction 17/15-to-17 (basically > cases where 17 is the LSP tail-end) the LSP signalling fails. > Trace reveals that the 17 gets the PATH message for bunch of LSPs, accepts > it (yes reduction and acks are used), creates the session, then deletes it > right away for some reason. > Our testing suggests there are two workarounds for this: > You might be aware that in 16.1 among other RSVP-TE changes the default > refresh-time (governing generation of successive refresh messages > Path/Resv) > changed to 1200s -so no what you think making it 1200 on 15 side wont do, > it > has to be less (e.q. 1999s). > If you want to keep refresh time at 1200 or higher then another option > strangely enough is to disable CSPF on the affected LSPs (didn't know that > SPF/CSPF changes contents of the PATH msg that in one case 17 code is cool > with PATH msg in other case not). > > Would appreciate any pointers. > > > adam > > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Dicko. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] RSVP-TE broken between pre and post 16.1 code?
We have seen similar issues with single hop LSPs and the stats being wrong unless we explicitly configure the single hop LSPs differently with UHP. Sent from my iCar On Jul 1, 2019, at 5:59 AM, wrote: >> From: Michael Hare >> Sent: Friday, June 28, 2019 7:02 PM >> >> Adam- >> >> Have you accounted for this behavioral change? >> >> https://kb.juniper.net/InfoCenter/index?page=content=KB32883= >> print=LIST==currentpaging >> > Thank you, yes please we're aware of that, but even with this the issue is > still present if the refresh timer is not <1200 or CSPF is enabled. > > 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] RSVP-TE broken between pre and post 16.1 code?
> From: Michael Hare > Sent: Friday, June 28, 2019 7:02 PM > > Adam- > > Have you accounted for this behavioral change? > > https://kb.juniper.net/InfoCenter/index?page=content=KB32883= > print=LIST==currentpaging > Thank you, yes please we're aware of that, but even with this the issue is still present if the refresh timer is not <1200 or CSPF is enabled. adam ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] RSVP-TE broken between pre and post 16.1 code?
Adam- Have you accounted for this behavioral change? https://kb.juniper.net/InfoCenter/index?page=content=KB32883=print=LIST==currentpaging -Michael > -Original Message- > From: juniper-nsp On Behalf Of > adamv0...@netconsultings.com > Sent: Friday, June 28, 2019 9:16 AM > To: juniper-nsp@puck.nether.net > Subject: [j-nsp] RSVP-TE broken between pre and post 16.1 code? > > Hi gents, > > Just wondering if anyone experienced RSVP-TE incompatibility issues when > moving from pre 16.1 code to post 16.1 code. > Didn't get much out of Juniper folks thus far so I figured I'll ask here as > well. > > The problem we're facing is that in case 17 code is LSP head-end and 15 code > is tail-end works, but in the opposite direction 17/15-to-17 (basically > cases where 17 is the LSP tail-end) the LSP signalling fails. > Trace reveals that the 17 gets the PATH message for bunch of LSPs, accepts > it (yes reduction and acks are used), creates the session, then deletes it > right away for some reason. > Our testing suggests there are two workarounds for this: > You might be aware that in 16.1 among other RSVP-TE changes the default > refresh-time (governing generation of successive refresh messages > Path/Resv) > changed to 1200s -so no what you think making it 1200 on 15 side wont do, it > has to be less (e.q. 1999s). > If you want to keep refresh time at 1200 or higher then another option > strangely enough is to disable CSPF on the affected LSPs (didn't know that > SPF/CSPF changes contents of the PATH msg that in one case 17 code is cool > with PATH msg in other case not). > > Would appreciate any pointers. > > > 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] RSVP-TE broken between pre and post 16.1 code?
I have MXs and ACXs all running RSVP, ranging in versions from 13 to 18. I haven't had any issues. What platform are you using? On Fri, Jun 28, 2019 at 7:15 AM wrote: > > Hi gents, > > Just wondering if anyone experienced RSVP-TE incompatibility issues when > moving from pre 16.1 code to post 16.1 code. > Didn't get much out of Juniper folks thus far so I figured I'll ask here as > well. > > The problem we're facing is that in case 17 code is LSP head-end and 15 code > is tail-end works, but in the opposite direction 17/15-to-17 (basically > cases where 17 is the LSP tail-end) the LSP signalling fails. > Trace reveals that the 17 gets the PATH message for bunch of LSPs, accepts > it (yes reduction and acks are used), creates the session, then deletes it > right away for some reason. > Our testing suggests there are two workarounds for this: > You might be aware that in 16.1 among other RSVP-TE changes the default > refresh-time (governing generation of successive refresh messages Path/Resv) > changed to 1200s -so no what you think making it 1200 on 15 side wont do, it > has to be less (e.q. 1999s). > If you want to keep refresh time at 1200 or higher then another option > strangely enough is to disable CSPF on the affected LSPs (didn't know that > SPF/CSPF changes contents of the PATH msg that in one case 17 code is cool > with PATH msg in other case not). > > Would appreciate any pointers. > > > 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
