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.

Severity        Minor
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

[email protected] писал 2019-08-16 06:01:
From: Nathan Ward <[email protected]>
Sent: Friday, August 16, 2019 8:39 AM

> On 1/07/2019, at 9:59 PM, [email protected] wrote:
>
>> From: Michael Hare <[email protected]>
>> Sent: Friday, June 28, 2019 7:02 PM
>>
>> Adam-
>>
>> Have you accounted for this behavioral change?
>>
>>
https://kb.juniper.net/InfoCenter/index?page=content&id=KB32883&pmv=
>> print&actp=LIST&searchid=&type=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 [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp

_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp

Reply via email to