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

Changes by create-pull-request action

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

@@ -18,7 +18,6 @@ pdfhidden: True
 | <a name="4135919"></a> [4135919](#4135919) <a name="4135919"></a> <br /> | You might experience a memory leak in <code>ospfd</code> when processing next hops due to network changes. | 5.9.1-5.10.1 | |
 | <a name="4129344"></a> [4129344](#4129344) <a name="4129344"></a> <br /> | When you create an ACL rule that matches TCP state and more than seven TCP or UDP source or destination ports, the rule does not get framed properly and is rejected by the kernel.<br>To work around this issue, create another rule number when the number of ports you want to match is more than seven. | 5.9.1-5.10.1 | |
 | <a name="4128913"></a> [4128913](#4128913) <a name="4128913"></a> <br /> | In an EVPN configuration,  when you use NVUE to configure a new host bond and an multihoming  ESI at the same time, the Split-Horizon preventive traffic class rule is not programmed in the egress direction. To work around this issue, configure the host bond and apply the configuration, then configure the EVPN multihoming ESI on the host bonds and apply the configuration in a separate step. | 5.9.1-5.10.1 | |
-| <a name="4122543"></a> [4122543](#4122543) <a name="4122543"></a> <br /> | When you use the NVUE <code>nv set bridge domain <bridge-id> stp priority</code> command to  configure the STP priority on two bridges, the STP priority on the second bridge does not apply.<br>To work around this issue, configure an NVUE snippet for the second bridge and apply it to the switch; for example:<br>Create the <code>vlan-aware_bridge_snippet.yaml</code> file and add the following:<br><pre>- set:<br />  system:<br />   config:<br />    snippet:<br />     ifupdown2_eni:<br />      bridge2: \|mstpctl-treeprio 8192</pre><br>Save the file, run the <code>nv config patch vlan-aware_bridge_snippet.yaml</code> command, then the <code>nv config apply</code> command. | 5.9.1-5.10.1 | |
 | <a name="4119696"></a> [4119696](#4119696) <a name="4119696"></a> <br /> | If you run <code>nv set</code> commands after you perform an upgrade but before a reboot, NVUE creates a revision based off the pre-upgrade version. After reboot, the revision contains pre-upgrade data that might cause it to fail during <code>config apply</code>.  To work around this issue, detach the stale revision after upgrade with the <code>nv config detach</code> command. | 5.10.0-5.10.1 | |
 | <a name="4119621"></a> [4119621](#4119621) <a name="4119621"></a> <br /> | When you set the SNMP server listening address to listen on all IPv4 and IPv6 addresses in a VRF with the <code>nv set service snmp-server listening-address all vrf</code> and <code>nv set service snmp-server listening-address all-v6 vrf</code> commands,SNMP requests over IPv6 addresses do not work. | 5.8.0-5.10.1 | |
 | <a name="4102992"></a> [4102992](#4102992) <a name="4102992"></a> <br /> | When you use the NVUE <code>nv set bridge domain <bridge-id> stp priority</code> command to  configure the STP priority on two bridges, the STP priority on the second bridge does not apply.<br>To work around this issue, configure an NVUE snippet for the second bridge and apply it to the switch; for example:<br>Create the <code>vlan-aware_bridge_snippet.yaml</code> file and add the following:<br><pre>- set:<br />  system:<br />   config:<br />    snippet:<br />     ifupdown2_eni:<br />      bridge2: \|mstpctl-treeprio 8192</pre><br>Save the file, run the <code>nv config patch vlan-aware_bridge_snippet.yaml</code> command, then the <code>nv config apply</code> command. | 5.9.1-5.10.1 | |
@@ -117,7 +116,6 @@ pdfhidden: True
 | <a name="4135919"></a> [4135919](#4135919) <a name="4135919"></a> <br /> | You might experience a memory leak in <code>ospfd</code> when processing next hops due to network changes. | 5.9.1-5.10.1 | |
 | <a name="4129344"></a> [4129344](#4129344) <a name="4129344"></a> <br /> | When you create an ACL rule that matches TCP state and more than seven TCP or UDP source or destination ports, the rule does not get framed properly and is rejected by the kernel.<br>To work around this issue, create another rule number when the number of ports you want to match is more than seven. | 5.9.1-5.10.1 | |
 | <a name="4128913"></a> [4128913](#4128913) <a name="4128913"></a> <br /> | In an EVPN configuration,  when you use NVUE to configure a new host bond and an multihoming  ESI at the same time, the Split-Horizon preventive traffic class rule is not programmed in the egress direction. To work around this issue, configure the host bond and apply the configuration, then configure the EVPN multihoming ESI on the host bonds and apply the configuration in a separate step. | 5.9.1-5.10.1 | |
-| <a name="4122543"></a> [4122543](#4122543) <a name="4122543"></a> <br /> | When you use the NVUE <code>nv set bridge domain <bridge-id> stp priority</code> command to  configure the STP priority on two bridges, the STP priority on the second bridge does not apply.<br>To work around this issue, configure an NVUE snippet for the second bridge and apply it to the switch; for example:<br>Create the <code>vlan-aware_bridge_snippet.yaml</code> file and add the following:<br><pre>- set:<br />  system:<br />   config:<br />    snippet:<br />     ifupdown2_eni:<br />      bridge2: \|mstpctl-treeprio 8192</pre><br>Save the file, run the <code>nv config patch vlan-aware_bridge_snippet.yaml</code> command, then the <code>nv config apply</code> command. | 5.9.1-5.10.1 | |
 | <a name="4119696"></a> [4119696](#4119696) <a name="4119696"></a> <br /> | If you run <code>nv set</code> commands after you perform an upgrade but before a reboot, NVUE creates a revision based off the pre-upgrade version. After reboot, the revision contains pre-upgrade data that might cause it to fail during <code>config apply</code>.  To work around this issue, detach the stale revision after upgrade with the <code>nv config detach</code> command. | 5.10.0-5.10.1 | |
 | <a name="4119621"></a> [4119621](#4119621) <a name="4119621"></a> <br /> | When you set the SNMP server listening address to listen on all IPv4 and IPv6 addresses in a VRF with the <code>nv set service snmp-server listening-address all vrf</code> and <code>nv set service snmp-server listening-address all-v6 vrf</code> commands,SNMP requests over IPv6 addresses do not work. | 5.8.0-5.10.1 | |
 | <a name="4102992"></a> [4102992](#4102992) <a name="4102992"></a> <br /> | When you use the NVUE <code>nv set bridge domain <bridge-id> stp priority</code> command to  configure the STP priority on two bridges, the STP priority on the second bridge does not apply.<br>To work around this issue, configure an NVUE snippet for the second bridge and apply it to the switch; for example:<br>Create the <code>vlan-aware_bridge_snippet.yaml</code> file and add the following:<br><pre>- set:<br />  system:<br />   config:<br />    snippet:<br />     ifupdown2_eni:<br />      bridge2: \|mstpctl-treeprio 8192</pre><br>Save the file, run the <code>nv config patch vlan-aware_bridge_snippet.yaml</code> command, then the <code>nv config apply</code> command. | 5.9.1-5.10.1 | |

content/cumulus-linux-510/rn.xml

@@ -31,21 +31,6 @@
 <td></td>
 </tr>
 <tr>
-<td>4122543</td>
-<td>When you use the NVUE {{nv set bridge domain &lt;bridge-id&gt; stp priority}} command to  configure the STP priority on two bridges, the STP priority on the second bridge does not apply.To work around this issue, configure an NVUE snippet for the second bridge and apply it to the switch; for example:
-Create the {{vlan-aware_bridge_snippet.yaml}} file and add the following:
-- set:
-   system:
-    config:
-     snippet:
-      ifupdown2_eni:
-       bridge2: |
-mstpctl-treeprio 8192
-Save the file, run the {{nv config patch vlan-aware_bridge_snippet.yaml}} command, then the {{nv config apply}} command.</td>
-<td>5.9.1-5.10.1</td>
-<td></td>
-</tr>
-<tr>
 <td>4119696</td>
 <td>If you run {{nv set}} commands after you perform an upgrade but before a reboot, NVUE creates a revision based off the pre-upgrade version. After reboot, the revision contains pre-upgrade data that might cause it to fail during {{config apply}}.  To work around this issue, detach the stale revision after upgrade with the {{nv config detach}} command.</td>
 <td>5.10.0-5.10.1</td>
@@ -624,21 +609,6 @@ Fixed: 2.6.0+dfsg.1-1+deb10u1</td>
 <td></td>
 </tr>
 <tr>
-<td>4122543</td>
-<td>When you use the NVUE {{nv set bridge domain &lt;bridge-id&gt; stp priority}} command to  configure the STP priority on two bridges, the STP priority on the second bridge does not apply.To work around this issue, configure an NVUE snippet for the second bridge and apply it to the switch; for example:
-Create the {{vlan-aware_bridge_snippet.yaml}} file and add the following:
-- set:
-   system:
-    config:
-     snippet:
-      ifupdown2_eni:
-       bridge2: |
-mstpctl-treeprio 8192
-Save the file, run the {{nv config patch vlan-aware_bridge_snippet.yaml}} command, then the {{nv config apply}} command.</td>
-<td>5.9.1-5.10.1</td>
-<td></td>
-</tr>
-<tr>
 <td>4119696</td>
 <td>If you run {{nv set}} commands after you perform an upgrade but before a reboot, NVUE creates a revision based off the pre-upgrade version. After reboot, the revision contains pre-upgrade data that might cause it to fail during {{config apply}}.  To work around this issue, detach the stale revision after upgrade with the {{nv config detach}} command.</td>
 <td>5.10.0-5.10.1</td>

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

@@ -17,7 +17,6 @@ pdfhidden: True
 | <a name="4135919"></a> [4135919](#4135919) <a name="4135919"></a> <br /> | You might experience a memory leak in <code>ospfd</code> when processing next hops due to network changes. | 5.9.1-5.10.1 | |
 | <a name="4129344"></a> [4129344](#4129344) <a name="4129344"></a> <br /> | When you create an ACL rule that matches TCP state and more than seven TCP or UDP source or destination ports, the rule does not get framed properly and is rejected by the kernel.<br>To work around this issue, create another rule number when the number of ports you want to match is more than seven. | 5.9.1-5.10.1 | |
 | <a name="4128913"></a> [4128913](#4128913) <a name="4128913"></a> <br /> | In an EVPN configuration,  when you use NVUE to configure a new host bond and an multihoming  ESI at the same time, the Split-Horizon preventive traffic class rule is not programmed in the egress direction. To work around this issue, configure the host bond and apply the configuration, then configure the EVPN multihoming ESI on the host bonds and apply the configuration in a separate step. | 5.9.1-5.10.1 | |
-| <a name="4122543"></a> [4122543](#4122543) <a name="4122543"></a> <br /> | When you use the NVUE <code>nv set bridge domain <bridge-id> stp priority</code> command to  configure the STP priority on two bridges, the STP priority on the second bridge does not apply.<br>To work around this issue, configure an NVUE snippet for the second bridge and apply it to the switch; for example:<br>Create the <code>vlan-aware_bridge_snippet.yaml</code> file and add the following:<br><pre>- set:<br />  system:<br />   config:<br />    snippet:<br />     ifupdown2_eni:<br />      bridge2: \|mstpctl-treeprio 8192</pre><br>Save the file, run the <code>nv config patch vlan-aware_bridge_snippet.yaml</code> command, then the <code>nv config apply</code> command. | 5.9.1-5.10.1 | |
 | <a name="4119621"></a> [4119621](#4119621) <a name="4119621"></a> <br /> | When you set the SNMP server listening address to listen on all IPv4 and IPv6 addresses in a VRF with the <code>nv set service snmp-server listening-address all vrf</code> and <code>nv set service snmp-server listening-address all-v6 vrf</code> commands,SNMP requests over IPv6 addresses do not work. | 5.8.0-5.10.1 | |
 | <a name="4102992"></a> [4102992](#4102992) <a name="4102992"></a> <br /> | When you use the NVUE <code>nv set bridge domain <bridge-id> stp priority</code> command to  configure the STP priority on two bridges, the STP priority on the second bridge does not apply.<br>To work around this issue, configure an NVUE snippet for the second bridge and apply it to the switch; for example:<br>Create the <code>vlan-aware_bridge_snippet.yaml</code> file and add the following:<br><pre>- set:<br />  system:<br />   config:<br />    snippet:<br />     ifupdown2_eni:<br />      bridge2: \|mstpctl-treeprio 8192</pre><br>Save the file, run the <code>nv config patch vlan-aware_bridge_snippet.yaml</code> command, then the <code>nv config apply</code> command. | 5.9.1-5.10.1 | |
 | <a name="4101808"></a> [4101808](#4101808) <a name="4101808"></a> <br /> | When the SNMP service is busy for approximately more than a minute, the applications using <code>net-snmp</code> APIs to support their MIBs (such as FRR) become blocked.  | 5.9.0-5.10.1 | |
@@ -149,7 +148,6 @@ pdfhidden: True
 | <a name="4135919"></a> [4135919](#4135919) <a name="4135919"></a> <br /> | You might experience a memory leak in <code>ospfd</code> when processing next hops due to network changes. | 5.9.1-5.10.1 | |
 | <a name="4129344"></a> [4129344](#4129344) <a name="4129344"></a> <br /> | When you create an ACL rule that matches TCP state and more than seven TCP or UDP source or destination ports, the rule does not get framed properly and is rejected by the kernel.<br>To work around this issue, create another rule number when the number of ports you want to match is more than seven. | 5.9.1-5.10.1 | |
 | <a name="4128913"></a> [4128913](#4128913) <a name="4128913"></a> <br /> | In an EVPN configuration,  when you use NVUE to configure a new host bond and an multihoming  ESI at the same time, the Split-Horizon preventive traffic class rule is not programmed in the egress direction. To work around this issue, configure the host bond and apply the configuration, then configure the EVPN multihoming ESI on the host bonds and apply the configuration in a separate step. | 5.9.1-5.10.1 | |
-| <a name="4122543"></a> [4122543](#4122543) <a name="4122543"></a> <br /> | When you use the NVUE <code>nv set bridge domain <bridge-id> stp priority</code> command to  configure the STP priority on two bridges, the STP priority on the second bridge does not apply.<br>To work around this issue, configure an NVUE snippet for the second bridge and apply it to the switch; for example:<br>Create the <code>vlan-aware_bridge_snippet.yaml</code> file and add the following:<br><pre>- set:<br />  system:<br />   config:<br />    snippet:<br />     ifupdown2_eni:<br />      bridge2: \|mstpctl-treeprio 8192</pre><br>Save the file, run the <code>nv config patch vlan-aware_bridge_snippet.yaml</code> command, then the <code>nv config apply</code> command. | 5.9.1-5.10.1 | |
 | <a name="4119621"></a> [4119621](#4119621) <a name="4119621"></a> <br /> | When you set the SNMP server listening address to listen on all IPv4 and IPv6 addresses in a VRF with the <code>nv set service snmp-server listening-address all vrf</code> and <code>nv set service snmp-server listening-address all-v6 vrf</code> commands,SNMP requests over IPv6 addresses do not work. | 5.8.0-5.10.1 | |
 | <a name="4102992"></a> [4102992](#4102992) <a name="4102992"></a> <br /> | When you use the NVUE <code>nv set bridge domain <bridge-id> stp priority</code> command to  configure the STP priority on two bridges, the STP priority on the second bridge does not apply.<br>To work around this issue, configure an NVUE snippet for the second bridge and apply it to the switch; for example:<br>Create the <code>vlan-aware_bridge_snippet.yaml</code> file and add the following:<br><pre>- set:<br />  system:<br />   config:<br />    snippet:<br />     ifupdown2_eni:<br />      bridge2: \|mstpctl-treeprio 8192</pre><br>Save the file, run the <code>nv config patch vlan-aware_bridge_snippet.yaml</code> command, then the <code>nv config apply</code> command. | 5.9.1-5.10.1 | |
 | <a name="4101808"></a> [4101808](#4101808) <a name="4101808"></a> <br /> | When the SNMP service is busy for approximately more than a minute, the applications using <code>net-snmp</code> APIs to support their MIBs (such as FRR) become blocked.  | 5.9.0-5.10.1 | |

content/cumulus-linux-59/rn.xml

@@ -25,21 +25,6 @@
 <td></td>
 </tr>
 <tr>
-<td>4122543</td>
-<td>When you use the NVUE {{nv set bridge domain &lt;bridge-id&gt; stp priority}} command to  configure the STP priority on two bridges, the STP priority on the second bridge does not apply.To work around this issue, configure an NVUE snippet for the second bridge and apply it to the switch; for example:
-Create the {{vlan-aware_bridge_snippet.yaml}} file and add the following:
-- set:
-   system:
-    config:
-     snippet:
-      ifupdown2_eni:
-       bridge2: |
-mstpctl-treeprio 8192
-Save the file, run the {{nv config patch vlan-aware_bridge_snippet.yaml}} command, then the {{nv config apply}} command.</td>
-<td>5.9.1-5.10.1</td>
-<td></td>
-</tr>
-<tr>
 <td>4119621</td>
 <td>When you set the SNMP server listening address to listen on all IPv4 and IPv6 addresses in a VRF with the {{nv set service snmp-server listening-address all vrf}} and {{nv set service snmp-server listening-address all-v6 vrf}} commands,SNMP requests over IPv6 addresses do not work.</td>
 <td>5.8.0-5.10.1</td>
@@ -792,21 +777,6 @@ This issue occurs because {{poectl}} is called on non-PoE switches. To work arou
 <td></td>
 </tr>
 <tr>
-<td>4122543</td>
-<td>When you use the NVUE {{nv set bridge domain &lt;bridge-id&gt; stp priority}} command to  configure the STP priority on two bridges, the STP priority on the second bridge does not apply.To work around this issue, configure an NVUE snippet for the second bridge and apply it to the switch; for example:
-Create the {{vlan-aware_bridge_snippet.yaml}} file and add the following:
-- set:
-   system:
-    config:
-     snippet:
-      ifupdown2_eni:
-       bridge2: |
-mstpctl-treeprio 8192
-Save the file, run the {{nv config patch vlan-aware_bridge_snippet.yaml}} command, then the {{nv config apply}} command.</td>
-<td>5.9.1-5.10.1</td>
-<td></td>
-</tr>
-<tr>
 <td>4119621</td>
 <td>When you set the SNMP server listening address to listen on all IPv4 and IPv6 addresses in a VRF with the {{nv set service snmp-server listening-address all vrf}} and {{nv set service snmp-server listening-address all-v6 vrf}} commands,SNMP requests over IPv6 addresses do not work.</td>
 <td>5.8.0-5.10.1</td>

content/cumulus-netq-411/Whats-New/rn.md

@@ -15,6 +15,7 @@ pdfhidden: True
 |  Issue ID 	|   Description	|   Affects	|   Fixed |
 |---	        |---	        |---	    |---	                |
 | <a name="4001098"></a> [4001098](#4001098) <a name="4001098"></a> <br /> | When you use NetQ LCM to upgrade a Cumulus Linux switch from version 5.9 to 5.10, and if the upgrade fails, NetQ rolls back to version 5.9 and reverts the <code>cumulus</code> user password to the default password. After rollback, reconfigure the password with the <code>nv set system aaa user cumulus password \<password\></code> command.   | 4.11.0 | |
+| <a name="4000939"></a> [4000939](#4000939) <a name="4000939"></a> <br /> | When you upgrade a NetQ VM with devices in the inventory that have been rotten for 7 or more days, NetQ inventory cards in the UI and table output might show inconsistent results and might not display the rotten devices. To work around this issue, decommission the rotten device and ensure it's running the appropriate NetQ agent version. | 4.11.0 | |
 | <a name="3995266"></a> [3995266](#3995266) <a name="3995266"></a> <br /> | When you use NetQ LCM to upgrade a Cumulus Linux switch with NTP configured using NVUE in a VRF that is not <code>mgmt</code>, the upgrade fails to complete. To work around this issue, first unset the NTP configuration with the <code>nv unset service ntp</code> and <code>nv config apply</code> commands, and reconfigure NTP after the upgrade completes. | 4.11.0 | |
 | <a name="3985598"></a> [3985598](#3985598) <a name="3985598"></a> <br /> | When you configure multiple threshold-crossing events for the same TCA event ID on the same device, NetQ will only display one TCA event for each hostname per TCA event ID, even if both thresholds are crossed or status events are triggered.   | 4.11.0 | |
 | <a name="3981655"></a> [3981655](#3981655) <a name="3981655"></a> <br /> | When you upgrade your NetQ VM, some devices in the NetQ inventory might appear as rotten. To work around this issue, restart NetQ agents on devices or upgrade them to the latest agent version after the NetQ VM upgrade is completed. | 4.11.0 | |