This article discusses the change in RSVP node-hello behavior from Junos OS release 16.1R1 onward due to which RSVP node-hello packets from PTX devices are seen to use the bypass-lsp even when a direct link to the adjacent router is available.
Note: Due to this, RSVP node-neighborship failure or flaps may be seen if RSVP authentication is not enabled globally on all links.
The customer network device PTX1 sees continuous RSVP node-neighborship flaps with the adjacent router (Cisco1). Packet capture on the Cisco1 router shows that the RSVP node-hello sent by PTX-1 to Cisco1 is being received on Cisco1 on the Cisco1-Cisco2 cross-link that has RSVP authentication enabled.
Bypass-LSP and RSVP node-hello path +------------------------------------------------------------------------------------------+ | | | | | | | +----------+ +------------+ | | | | 10.22.230.52/31 | | | | | PTX-2 | | Cisco2 | | | | +-------------------->+ | | | | |.52 .53| | | | +-----^----+ +-------+----+ | | .229| .33 | | | | | RSVP auth on this link | | | | | | | | 10.81.163.32/31 | | 10.22.226.228/31 | | | | | | | | | | | | .228|et-7/0/0 .32| xe-1/1/0 | | +---------+ +-------v----+ | | | | | | | +-------------------+ | |.108 .109 | Cisco1 | <---------------------+ | PTX-1 <---------------------+ | | | et-7/0/1 xe-1/0/1| | Lo0 +---------+ +------------+ Lo0 10.222.240.32 10.22.229.108/31 10.81.248.127 + + | | | | | | | 1 hop LSP | +---------------------------------+
A lab simulation shows that the node-hello packet is being sent on the bypass LSP.
On PTX-1:
labroot@jtac-ptx5000dc-r2006# run show route 10.81.248.127 Jan 09 22:04:21 inet.0: 17 destinations, 17 routes (16 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 10.81.248.127/32 *[IS-IS/18] 02:12:19, metric 10023310 > to 10.222.229.109 via et-7/0/1.0, label-switched-path MA-MA:TL1RES-LCR21RONKVA-1:LCR to 10.222.226.229 via et-7/0/0.0, label-switched-path Bypass->10.222.229.109 inet.3: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.81.248.127/32 *[RSVP/7/1] 02:12:44, metric 10023310 > to 10.222.229.109 via et-7/0/1.0, label-switched-path MA-MA:TL1RES-LCR21RONKVA-1:LCR to 10.222.226.229 via et-7/0/0.0, label-switched-path Bypass->10.222.229.109 labroot@jtac-ptx5000dc-r2006# show protocols mpls label-switched-path MA-MA:TL1RES-LCR21RONKVA-1:LCR |display inheritance no-comments to 10.81.248.127; ldp-tunneling; priority 3 3; least-fill; link-protection; adaptive; auto-bandwidth { adjust-interval 10800; adjust-threshold 20; minimum-bandwidth 100m; maximum-bandwidth 25g; adjust-threshold-overflow-limit 4; adjust-threshold-underflow-limit 18; } labroot@jtac-ptx5000dc-r2006# show protocols rsvp |display inheritance no-comments keep-multiplier 3; no-enhanced-frr-bypass; interface all { hello-interval 2; subscription 85; link-protection { optimize-timer 1200; } }
On the MX router that is simulating the Cisco2 router, the node-hello is being received on the cross-link:
labroot@jtac-mx480-r2011-re1# run monitor traffic interface xe-1/1/0.0 matching "host 10.222.240.32 and proto 46" no-resolve Jan 09 22:05:20 verbose output suppressed, use <detail> or <extensive> for full protocol decode Address resolution is OFF. Listening on xe-1/1/0.0, capture size 96 bytes 22:05:21.216031 In IP 10. > 10.81.248.127: RSVPv1 Hello Message, length: 32 22:05:30.217398 In IP 10.222.240.32 > 10.81.248.127: RSVPv1 Hello Message, length: 32 22:05:39.215720 In IP 10.222.240.32 > 10.81.248.127: RSVPv1 Hello Message, length: 32 22:05:48.215600 In IP 10.222.240.32 > 10.81.248.127: RSVPv1 Hello Message, length: 32 22:05:57.222703 In IP 10.222.240.32 > 10.81.248.127: RSVPv1 Hello Message, length: 32 22:06:06.214866 In IP 10.222.240.32 > 10.81.248.127: RSVPv1 Hello Message, length: 32
The cause for the RSVP node-neighborship to fail/flap on PTX-1 is that the node-hello that is sent as a labeled packet (that is, on the bypass-LSP between PTX-1 and Cisco1) does not have authentication and it traverses a cross-link between the Cisco1 and Cisco2 routers, which has authentication configured. But the node-hello from Cisco1 to PTX-1 is received on PTX-1 on the direct link interface facing Cisco-1.
Disabling RSVP authentication on the Cisco1-Cisco2 cross-link will fix this flapping issue.
However, the glaring question is why the RSVP node-hello from PTX-1 is traversing the cross-link/bypass-path when the direct link is available. This is explained in the Solution.
RSVP node-id based hello messages are sent over a bypass link if it is available, and are directly injected onto the bypass link without any IP route lookup in the kernel ( dont-route flag is set). This makes the RSVP node-id hello sessions to remain immune to any system-wide churn after any failure event where a large number of route-next-hop adds/deletes/changes are downloaded from the RPD down to the PFE via the kernel.
dont-route
This is done by default from Junos OS release 16.1R1 onward.
However, users can switch off this behavior by using the knob protocols rsvp no-node-hello-on-bypass . If the above knob has been turned on or if there is no bypass, then the node-id hello messages are pushed to the kernel without the dont-route flag so that the kernel decides how to forward the packet.
protocols rsvp no-node-hello-on-bypass