This article explains the behavior of protocol flap/impact while configuring TCP MSS on an interface. Any configuration change of TCP MSS on interfaces is service impacting. This is expected behavior and should be done during a maintenance window to avoid impact.
When TCP MSS configuration on an interface is added, changed, or deleted, the protocol configured on that interface flaps. In the following example, OPSF flap is observed after configuring TCP MSS:
user@R1# set interfaces xe-0/0/0.0 family inet tcp-mss 1300 user@R1# commit commit complete user@R1#
OSPF neighbor flap log after commit:
Apr 7 09:33:22.527050 OSPF neighbor 50.1.1.2 (realm ospf-v2 xe-0/0/0.0 area 0.0.0.0) state changed from Full to Down due to KillNbr (event reason: interface went down) (nbr helped: 0) Apr 7 09:33:22.527192 RPD_OSPF_NBRDOWN: OSPF neighbor 50.1.1.2 (realm ospf-v2 xe-0/0/0.0 area 0.0.0.0) state changed from Full to Down due to KillNbr (event reason: interface went down)
When configuring TCP MSS on an interface, IFF gets reprogrammed. As a result, the OSPF (or any other protocol) will flap because there is no family associated with the interface for a few moments.
Example:
/kernel: iff_handle_ifa_delete: deletion of address on IFL xe-0/0/0 has resulted in the removal of primary source address.
This behavior is consistent with other family parameters such as MTU.
Any configuration change of TCP MSS on interfaces is service impacting. This is expected behavior and should be done during a maintenance window to avoid impact.
2020-08-03: Reviewed for accuracy and no modifications needed