Merge pull request #3180 from CumulusNetworks/create-pull-request/patch

Changes by create-pull-request action

Author: mergify[bot]

content/cumulus-linux-510/Whats-New/rn.md

@@ -26,13 +26,13 @@
 </tr>
 <tr>
 <td>4871161</td>
-<td>If you use NVUE commands to change the BGP autonomous system number (ASN) for existing VRFs without deleting the associated EVPN VNI, FRR reload fails and shows an error during {{nv config apply}}. Be sure to delete the layer 3 VNI before changing the BGP ASN.</td>
+<td>If you use NVUE commands to change the BGP autonomous system number (ASN) for existing VRFs without deleting the associated EVPN VNI, FRR reload fails and shows an error during {{nv config apply}}. Be sure to delete the layer 3 VNI before changing the BGP ASN or restart FRR after the AS change. </td>
 <td>5.9.1-5.16.1</td>
 <td></td>
 </tr>
 <tr>
 <td>4840299</td>
-<td>If you use NVUE commands to change the BGP autonomous system number (ASN) for existing VRFs without deleting the associated EVPN VNI, FRR reload fails and shows an error during {{nv config apply}}. Be sure to delete the layer 3 VNI before changing the BGP ASN.</td>
+<td>If you use NVUE commands to change the BGP autonomous system number (ASN) for existing VRFs without deleting the associated EVPN VNI, FRR reload fails and shows an error during {{nv config apply}}. Be sure to delete the layer 3 VNI before changing the BGP ASN or restart FRR after the AS change. </td>
 <td>5.9.1-5.16.1</td>
 <td></td>
 </tr>
@@ -992,29 +992,17 @@ cumulus@switch:~$ sudo ethtool -s swp1 speed 100000 autoneg off lanes 2
 </tr>
 <tr>
 <td>4871161</td>
-<td>If you use NVUE commands to change the BGP autonomous system number (ASN) for existing VRFs without deleting the associated EVPN VNI, FRR reload fails and shows an error during {{nv config apply}}. Be sure to delete the layer 3 VNI before changing the BGP ASN.</td>
+<td>If you use NVUE commands to change the BGP autonomous system number (ASN) for existing VRFs without deleting the associated EVPN VNI, FRR reload fails and shows an error during {{nv config apply}}. Be sure to delete the layer 3 VNI before changing the BGP ASN or restart FRR after the AS change. </td>
 <td>5.9.1-5.16.1</td>
 <td></td>
 </tr>
 <tr>
 <td>4840299</td>
-<td>If you use NVUE commands to change the BGP autonomous system number (ASN) for existing VRFs without deleting the associated EVPN VNI, FRR reload fails and shows an error during {{nv config apply}}. Be sure to delete the layer 3 VNI before changing the BGP ASN.</td>
+<td>If you use NVUE commands to change the BGP autonomous system number (ASN) for existing VRFs without deleting the associated EVPN VNI, FRR reload fails and shows an error during {{nv config apply}}. Be sure to delete the layer 3 VNI before changing the BGP ASN or restart FRR after the AS change. </td>
 <td>5.9.1-5.16.1</td>
 <td></td>
 </tr>
 <tr>
-<td>4789097</td>
-<td>The switch deletes a static blackhole route even when the blackhole type specified in the delete command does not match the configured type.</td>
-<td>5.9.4-5.15.1</td>
-<td>5.16.0-5.16.1</td>
-</tr>
-<tr>
-<td>4771521</td>
-<td>Layer 3 multicast traffic does not forward when OMF (Optimized Multicast Flooding) and PIM is enabled. To work around this issue, flap the router port.</td>
-<td>5.9.2-5.15.1</td>
-<td>5.16.0-5.16.1</td>
-</tr>
-<tr>
 <td>4647646</td>
 <td>If you configure policy-based routing (PBR) rules for more than 32 interfaces, only the rules assigned to the first 32 interfaces are installed in the kernel. </td>
 <td>4.4.2-5.14.0</td>
@@ -1039,12 +1027,6 @@ cumulus@switch:~$ sudo ethtool -s swp1 speed 100000 autoneg off lanes 2
 <td>5.15.0-5.16.1</td>
 </tr>
 <tr>
-<td>4582679</td>
-<td>If a node has Suppress Route Advertisement enabled and routes are re-learned; for example, when a peer sends the route again due to route policy changes, or you enable or disable graceful shutdown, not all routes are offloaded, which might cause discrepancies in traffic. </td>
-<td>5.9.4-5.16.1</td>
-<td></td>
-</tr>
-<tr>
 <td>4535804</td>
 <td>If you use a bridge name other than {{br_default}}, PTP neighbors fail to establish because the PTP packets are sourced from an unexpected IP address.To work around this issue, configure the {{base-interface}} for the VLAN interface with the {{nv set interface &lt;VLAN-id&gt; base-interface &lt;interface-id&gt;}} command.</td>
 <td>5.10.0-5.16.1</td>
@@ -1103,47 +1085,34 @@ To work around this issue, power cycle the switch.</td>
 <td>5.14.0-5.16.1</td>
 </tr>
 <tr>
-<td>4281099</td>
+<td>4220147</td>
 <td>When you bring STP down, then up on the primary MLAG peer, the STP state machine restarts and the peerlink operational edge resets. As a result, the secondary MLAG peer ends up in an STP discarding state. To work around this issue, restart the {{clagd}} service.</td>
-<td>5.8.0-5.11.5</td>
-<td>5.12.0-5.16.1</td>
+<td>5.8.0-5.11.0</td>
+<td>5.11.1-5.16.1, 5.12.0-5.16.1</td>
 </tr>
 <tr>
-<td>4260012</td>
-<td>If all of the neighbors returned in the {{nv show vrf &lt;vrf&gt; router bgp neighbor}} command output have no {{address-family}} configuration, you see an internal error when the nested table in the  output is being rendered.</td>
-<td>5.10.0-5.11.5</td>
-<td>5.12.0-5.16.1</td>
-</tr>
-<tr>
-<td>4259980</td>
-<td>After you reboot the switch, the ifplugd.service fails to start monitoring the interface.</td>
-<td>5.8.0-5.9.3, 5.10.0-5.11.5</td>
-<td>5.9.4, 5.12.0-5.16.1</td>
+<td>4178578</td>
+<td>An unexpected thermal reboot occurs due to an incorrect firmware status in the i2c driver.</td>
+<td>5.10.0-5.11.0</td>
+<td>5.11.1-5.16.1</td>
 </tr>
 <tr>
-<td>4223451</td>
-<td>When you change the VRR MAC address, {{switchd}} crashes. This occurs because deleting an old VRR MAC address triggers a neighbor update that changes the ECMP container resolution, which results in route entry updates.
-This happens in async mode, where the end notification expected after an end of operation is missing.</td>
-<td>5.9.2-5.11.5</td>
-<td>5.12.0-5.16.1</td>
+<td>4175695</td>
+<td>If all of the neighbors returned in the {{nv show vrf &lt;vrf&gt; router bgp neighbor}} command output have no {{address-family}} configuration, you see an internal error when the nested table in the  output is being rendered.</td>
+<td>5.10.0-5.11.0</td>
+<td>5.11.1-5.16.1, 5.12.0-5.16.1</td>
 </tr>
 <tr>
-<td>4200961</td>
+<td>4170628</td>
 <td>If you use a bridge name other than {{br_default}}, PTP neighbors fail to establish because the PTP packets are sourced from an unexpected IP address.To work around this issue, configure the {{base-interface}} for the VLAN interface with the {{nv set interface &lt;VLAN-id&gt; base-interface &lt;interface-id&gt;}} command.</td>
-<td>5.10.0-5.11.5</td>
-<td>5.12.0-5.16.1</td>
-</tr>
-<tr>
-<td>4195240</td>
-<td>Cumulus Linux installs and runs the {{atftpd}} program by default but cannot access it because a {{/tftpboot}} directory is missing.</td>
-<td>5.9.2-5.11.5</td>
-<td>5.12.0-5.16.1</td>
+<td>5.10.0-5.11.0</td>
+<td>5.11.1-5.16.1, 5.12.0-5.16.1</td>
 </tr>
 <tr>
-<td>4178578</td>
-<td>An unexpected thermal reboot occurs due to an incorrect firmware status in the i2c driver.</td>
-<td>5.10.0-5.11.0</td>
-<td>5.11.1-5.16.1</td>
+<td>4151336</td>
+<td>After you reboot the switch, the ifplugd.service fails to start monitoring the interface.</td>
+<td>5.8.0-5.9.3, 5.10.0-5.11.0</td>
+<td>5.9.4, 5.11.1-5.16.1, 5.12.0-5.16.1</td>
 </tr>
 <tr>
 <td>4144021</td>
@@ -1281,12 +1250,6 @@ Save the file, run the {{nv config patch vlan-aware_bridge_snippet.yaml}} comman
 <td>5.10.1-5.16.1</td>
 </tr>
 <tr>
-<td>4062271</td>
-<td>ASIC monitoring histogram collection might not work because of a crash in the {{asic-monitor}} service. To work around this issue, see the &lt;a href="https://docs.nvidia.com/networking-ethernet-software/cumulus-linux-510/Whats-New/#release-considerations"&gt;Release Considerations section of the What’s New&lt;/a&gt;.</td>
-<td>5.10.0-5.10.1</td>
-<td>5.11.0-5.16.1</td>
-</tr>
-<tr>
 <td>4062001</td>
 <td>With VM migration from one VTEP to another, traffic loss might occur during a MAC move as locally learned MAC addresses are frequently refreshed in the kernel. </td>
 <td>5.8.0-5.10.1</td>
@@ -1299,12 +1262,6 @@ Save the file, run the {{nv config patch vlan-aware_bridge_snippet.yaml}} comman
 <td>5.11.0-5.16.1</td>
 </tr>
 <tr>
-<td>4052578</td>
-<td>When you perform a binary upgrade from Cumulus Linux 5.8 or earlier to 5.9.0 or later with a pre-staged {{startup.yaml}} file, the cumulus user password is reset to the default password because there is no default {{startup.yaml}} file present in 5.8.0 or earlier. To work around this issue, generate the {{startup.yaml}} file from the existing NVUE configuration. </td>
-<td>5.9.2-5.11.5</td>
-<td>5.12.0-5.16.1</td>
-</tr>
-<tr>
 <td>4050835</td>
 <td>The NVUE Service fails to start after an upgrade from Cumulus Linux 5.9 to Cumulus Linux 5.10 because of a corrupted database.</td>
 <td>5.10.0-5.10.1</td>
@@ -1321,12 +1278,6 @@ interface_stats: [ERROR] interface_stats_collector.py:_parse_conf_file:201 — C
 <td>5.11.0-5.16.1</td>
 </tr>
 <tr>
-<td>4049213</td>
-<td>When there are routes that point to a single next hop, an ECMP entry is created in the SDK. After the single next hop from the route is removed, the ECMP entry might stay in the SDK until the time the next hop is present in the kernel.</td>
-<td>5.9.2-5.16.1</td>
-<td></td>
-</tr>
-<tr>
 <td>4048583</td>
 <td>If there are failures in MSTPD or a port is not updated in the database, the NVUE {{nv show bridge domain &lt;bridge-id&gt; stp}} command might not work and might produce errors even when STP has data for other working ports or VLANs. This is a display issue only and does not impact functionality.</td>
 <td>5.10.0-5.12.1</td>
@@ -1349,12 +1300,6 @@ To work around this issue, power-cycle the switch.</td>
 <td></td>
 </tr>
 <tr>
-<td>4043575</td>
-<td>If a ZTP script includes a directive to reboot, the reboot might stop the running ZTP process before it is able to disable itself from running again. As a result, the ZTP process starts again when the system comes back up. To work around this issue, run {{shutdown -r +1}} to schedule a reboot after one minute so that the ZTP process can successfully complete disabling the {{ztp.service}} systemd service.</td>
-<td>5.10.0-5.10.1</td>
-<td>5.9.2, 5.11.0-5.16.1</td>
-</tr>
-<tr>
 <td>4042657</td>
 <td>The SDK times out with a FW FATAL health event, which requires a reboot of the system to recover. 
 </td>
@@ -1392,6 +1337,12 @@ To work around this issue, power-cycle the switch.</td>
 <td>5.11.0-5.16.1</td>
 </tr>
 <tr>
+<td>4037224</td>
+<td>ASIC monitoring histogram collection might not work because of a crash in the {{asic-monitor}} service. To work around this issue, see the &lt;a href="https://docs.nvidia.com/networking-ethernet-software/cumulus-linux-510/Whats-New/#release-considerations"&gt;Release Considerations section of the What’s New&lt;/a&gt;.</td>
+<td>5.10.0</td>
+<td>5.10.1-5.16.1, 5.11.0-5.16.1</td>
+</tr>
+<tr>
 <td>4030380</td>
 <td>When you roll back interface configuration to the default setting with the {{nv unset interface}} command, NVUE removes the complete entry for the interface from the {{/etc/network/interface}} file, and puts the interface in admin down. As a result, you cannot configure FEC on the interface at the lower layers.</td>
 <td>5.10.0-5.16.1</td>
@@ -1422,6 +1373,12 @@ To work around this issue, power-cycle the switch.</td>
 <td>5.13.0-5.16.1</td>
 </tr>
 <tr>
+<td>4016216</td>
+<td>If a ZTP script includes a directive to reboot, the reboot might stop the running ZTP process before it is able to disable itself from running again. As a result, the ZTP process starts again when the system comes back up. To work around this issue, run {{shutdown -r +1}} to schedule a reboot after one minute so that the ZTP process can successfully complete disabling the {{ztp.service}} systemd service.</td>
+<td>5.10.0</td>
+<td>5.9.2, 5.10.1-5.16.1, 5.11.0-5.16.1</td>
+</tr>
+<tr>
 <td>4005422</td>
 <td>When you upgrade Cumulus Linux 5.9.1 to Cumulus Linux 5.10 or later with package upgrade, the NTP service stops. To restart the NTP service, enable, then restart the service in the VRF in which it was running with the {{systemctl enable ntpsec@&lt;vrf&gt;}} and {{systemctl restart ntpsec@&lt;vrf&gt;}} commands.</td>
 <td>5.10.0-5.16.1</td>