Issues resolved in 2204a.

Security vulnerabilities resolved in 2204a.

Bidirectional Forwarding Detection (BFD) is a protocol used to monitor liveness of forwarding engines in order to enable quicker control plane convergence in the event of failure of a node. The original offload design did not consider the fact that the BFD thread in the dataplane either needs to execute on a dedicated CPU or have some other means of always being scheduled in a timely manner in order to avoid timing out sessions. This has resulted in issues when the CPU load on the main thread can result in erratic scheduling of the BFD thread. This patch adds a new command that can dedicate a CPU for BFD in the dataplane using affinity configuration.

set protocols bfd dataplane cpu-affinity <cpu-id>

cpu-id is in the range 1 to 255. It is customized per platform to reflect the actual number of CPUs available on the platform.

When this command is issued, the BFD thread is moved to or started on the specified CPU. All existing BFD sessions experience a flap during this activity due to the temporary teardown and re-instantiation of the BFD thread.

The CPU specified must conform to the following restrictions:

1. It must not be the CPU used to host the main thread of the dataplane.
   • If no affinity is configured for the dataplane as a whole, the main thread is hosted by CPU 0.
   • If the dataplane CPU affinity is configured using set system default dataplane cpu-affinity, the main thread is hosted on the cpu with the lowest id in the list specified.
2. It must not be a CPU configured for control, forwarding or any other feature.
   • The other existing commands dealing with dataplane cpu affinity are as follows:
     • set system default dataplane control cpu-affinity <cpu-list>
     • set interfaces dataplane <interface> < cpu-affinity | transmit-cpu-affinity | receive-cpu-affinity > <list>
     • set security vpn ipsec dataplane < crypto | crypto-fwd > cpu-affinity <list>
     • set service nat cgnat cpu-affinity event session <cpu>

The above restrictions are validated at the time of committing the configuration and the configuration commit fails if the user specifies an invalid configuration.

If the CPU specified by the user does not exist on the system, the configuration is still accepted in order to handle scenarios of VM re-provisioning. However an error message of severity CRITICAL will be emitted indicating that the configuration was not honored. If this happens, BFD runs in a degraded mode on the same CPU as the main thread.

The GNSS (Global Navigation Satellite System) can be in an unexpected state, or be in a temporary state for too long. Therefore, when such issues are detected, an SNMP GNSS failure trap is sent, with a reason for the failure. When the failure event ends, an SNMP GNSS recovery trap is sent. They are also resent periodically when in a failure condition.

The GnssFailure trap is sent for any of the GNSS failure conditions. The failure reason message indicates the cause for the failure. While in a failure condition the trap is sent every 60 minutes. When leaving the failure condition, the GnssRecovery trap is sent.

The following table describes the possible reasons for GNSS failures. These are in the order that is reported if more than one issue occurs.

This patch adds the following configuration commands:

set service gnss instance [number] tracking-time-limit [seconds]

number is the instance number of the GNSS receiver in the system. Most systems have at most one GNSS receiver with an instance number of 0.

seconds is how long to wait, in seconds, until a GNSS failure trap indicates that it has taken too long to enter the tracking state. This value must be as follows:

• Has a minimum value of 10
• Is a multiple of 10
• Less than the holdover-time-limit configuration variable
• Defaults to a value of 900 (15 minutes)

If the tracking state has not transitioned to tracking by the time specified in this configuration value, then a trap is sent with the reason Too long in entering tracking state.

set service gnss instance [number] holdover-time-limit [seconds]

number is the instance number of the GNSS receiver in the system. Most systems have at most one GNSS receiver with an instance number of 0.

seconds is how long to wait, in seconds, until a GNSS failure trap indicates that the holdover time has been exceeded. This value must be as follows:

• Has a minimum value of 20
• Is a multiple of 10
• More than the tracking-time-limit configuration variable
• Defaults to a value of 7200 (2 hours)

If the tracking state has not transitioned to tracking by the time given in this configuration value, then a trap is sent with the reason Holdover exceeded configured duration.

The show tech-support command now includes output from the following commands:

show dataplane statistics ip

show dataplane statistics icmp