Patch release notes 2110c
Vyatta NOS patch release notes 2110c.
Released March 23, 2022
Issues resolved
Issues resolved in 2110c.
Issue number | Priority | Summary |
|---|---|---|
VRVDR-57038 | Blocker | QoS doesn't work with hardware bonding |
VRVDR-56727 | Blocker | NTP does not update system time and displays ntpq: read: Connection refused in cli output |
VRVDR-56700 | Blocker | PTP: The path asymmetry measured during TC13A appears to vary wildly |
VRVDR-57094 | Critical | vyatta-snmp-subagent has a slow memory leak |
VRVDR-57076 | Critical | PTP: enable the GPS source early when first creating the clock |
VRVDR-57047 | Critical | PTP: failure to get the servo status should result in an alarm |
VRVDR-57035 | Critical | High CPU usage was observed on %Cpu0 |
VRVDR-56963 | Critical | IPv6 PTP pkts send from wrong loopback address when IPv4 and IPv6 address present on source-interface loopback |
VRVDR-56919 | Critical | BFD ipv4 sessions instability on 2110a |
VRVDR-56854 | Critical | PTP: The IDT servo tracking the backup GM will sometimes report " DL packet rate (NN.NN) is different from the nominal rate" |
VRVDR-56765 | Critical | NTP does not sync with servers |
VRVDR-56672 | Critical | SNAT SIP ALG misinterprets SDP part of packet payload header causing dataplane crash |
VRVDR-56576 | Critical | Dataplane crash while capturing traffic |
VRVDR-56563 | Critical | Frequent flapping of all BGP peers due BFD failure |
VRVDR-56127 | Critical | PTP: IPv6 session cannot be established successfully to BC |
VRVDR-55504 | Critical | Multicast/PIM/PIM6 logs unusable |
VRVDR-56920 | Major | vci-kdump service failed to start |
VRVDR-56895 | Major | Dataplane fails to start on bootup after upgrade to 2110a when system is using x710 NIC |
VRVDR-56882 | Major | Azure: Dataplane interface is assigned dhcp IP address from the incorrect VNET subnet |
VRVDR-56827 | Major | IPv6 ping command ignores -I for device names causing path-monitor tests to fail |
VRVDR-56779 | Major | Excessive qos-validate.pl calls with large-scale QoS config / 200 VIFs with QoS takes 17 minutes |
VRVDR-56668 | Major | Dataplane retains mcast entries when incoming interface changes |
VRVDR-56565 | Major | NTP is spamming the journal, preventing retention of useful information |
VRVDR-56397 | Major | IP multicast traffic switched by dataplane when BFD configured |
VRVDR-56097 | Major | BFD configured for 3x150ms but convergence > 1 sec (BGP Backhaul) |
VRVDR-56014 | Major | LACP CLI Message — teamdctl_connect failed (Connection timed out) dp0bond0: Cannot get members |
VRVDR-54861 | Major | OSPFv3 warning message on SIAD |
VRVDR-49747 | Major | Ufi diag 'ledtest all' signal handler over-ridden |
VRVDR-56806 | Minor | Command "show dataplane multicast ipv6 interface" — counter is not displaying multicast traffic correctly |
VRVDR-56385 | Minor | Inability to parse/report SFP eeprom data correctly |
VRVDR-56750 | Minor | "vyatta-gnssd: Unable to find configuration state in VCI" appears in journal logs |
VRVDR-56240 | Trivial | vplane-controller snapshot information does not give the database key |
Security vulnerabilities resolved
Security vulnerabilities resolved in 2110c.
Issue number | CVSS score | Advisory | Summary |
|---|---|---|---|
VRVDR-56918 | 5.5 | CVE-2021-46141, CVE-2021-46142: Debian DSA-5063-1: uriparser security update | |
VRVDR-56917 | 7.5 | CVE-2022-22747: Debian DSA-5062-1: nss security update | |
VRVDR-56903 | 9.1 | CVE-2021-45079: Debian DSA-5056-1: strongswan – security update | |
VRVDR-56843 | 7.1 | CVE-2021-43818: Debian DSA-5043-1 : lxml — security update | |
VRVDR-56831 | 5.9 | CVE-2022-22707: Debian DSA-5040-1 : lighttpd — security update |
Updated BSP and diagnostic packages for the S9500-30XS
The following firmware updates from UfiSpace are included within this patch:
|
Firmware |
Version |
|---|---|
|
CPU Broadwell-DE diagnostics |
3.1.12 |
|
BSP |
3.0.16 |
|
Diagnostics package |
3.1.12 |
BFD dataplane CPU affinity
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:
- 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.
- 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 other existing commands dealing with dataplane cpu affinity are as follows:
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.