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

Changes by create-pull-request action

Author: mergify[bot]

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

@@ -15,10 +15,13 @@ pdfhidden: True
 |  Issue ID 	|   Description	|   Affects	|   Fixed |
 |---	        |---	        |---	    |---	                |
 | <a name="4850551"></a> [4850551](#4850551) <a name="4850551"></a> <br /> | The switch installs suboptimal routes in the routing table and advertises them out. | 5.9.2-5.15.1 | |
+| <a name="4805286"></a> [4805286](#4805286) <a name="4805286"></a> <br /> | During port‑mapping configuration, an edge case might lead to an invalid configuration state, causing the system to eventually become stuck. | 5.11.3-5.15.1 | |
 | <a name="4797691"></a> [4797691](#4797691) <a name="4797691"></a> <br /> | The message that the switch displays when you generate a cl-support file or as a post login banner contains an invalid Cumulus Support email address, which is no longer the formal channel for reporting support issues. | 5.0.0-5.15.1 | |
 | <a name="4789097"></a> [4789097](#4789097) <a name="4789097"></a> <br /> | The switch deletes a static blackhole route even when the blackhole type specified in the delete command does not match the configured type. | 5.9.4-5.15.1 | |
 | <a name="4771875"></a> [4771875](#4771875) <a name="4771875"></a> <br /> | When you poll optical module data with <code>ethtool -m</code>, <code>switchd</code> might crash due to a firmware timeout that triggers a fatal health-check failure. | 5.11.1-5.15.1 | |
 | <a name="4771521"></a> [4771521](#4771521) <a name="4771521"></a> <br /> | 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. | 5.9.2-5.15.1 | |
+| <a name="4729839"></a> [4729839](#4729839) <a name="4729839"></a> <br /> | In an MLAG configuration, when you reboot the primary MLAG switch with PVRST spanning tree mode configured on both MLAG switches, PVRST mode briefly changes to RSTP, then back to PVRST when the primary switch comes back up. | 5.11.3-5.15.1 | |
+| <a name="4722680"></a> [4722680](#4722680) <a name="4722680"></a> <br /> | If you install RADIUS client packages when rolling back a two partition upgrade, the <code>/var/lib/nvue</code>, <code>/var/lib/ntpsec</code>, and <code>/var/lib/snmp</code> directories might have incorrect ownership after rollback and the <code>nvued</code> service might fail to start up. To work around this issue, run the following commands:<br><pre>sudo chown -R nvue /var/lib/nvue<br>sudo chown -R ntpsec /var/lib/ntpsec<br>sudo chown -R Debian-snmp /var/lib/snmp<br>sudo reboot</pre> | 5.11.4-5.15.1 | |
 | <a name="4722539"></a> [4722539](#4722539) <a name="4722539"></a> <br /> | Optimized image upgrade with warm boot mode is supported in Cumulus Linux 5.13 and later. When you try to run the <code>nv action boot-next</code> command during optimized image upgrade in Cumulus Linux 5.12 and earlier to any target release while the system is in warm boot mode, the <code>boot-next</code> operation fails with the following error:<br><pre>cumulus&#64;switch:~$ nv action boot-next system image other<br>Error: Action failed with the following issue:>br><br /> Failed to set boot-next due to Unknown error</pre><br>To work around this issue, verify system boot mode with the <code>nv show system reboot</code> command before you perform optimized image upgrade and switch to cold boot mode if necessary with the <code>nv set system reboot mode cold</code> command. You can then proceed with the optimized image upgrade <code>boot-next</code> operation. | 5.11.4-5.15.1 | |
 | <a name="4721298"></a> [4721298](#4721298) <a name="4721298"></a> <br /> | When node or VM migration occurs between the MLAG pair and the EVPN-MH pair, the MLAG MAC database becomes out of sync with kernel FDB. The migrated MAC addresses remain as local in MLAG MAC database whereas in the kernel, all MAC addresses are updated correctly as remote with the layer 2 next hop ID. To work around this issue, flap the MLAG bond interface to clear the MLAG local database. | 5.11.0-5.15.1 | |
 | <a name="4714845"></a> [4714845](#4714845) <a name="4714845"></a> <br /> | The switch installs suboptimal routes in the routing table and advertises them out. | 5.9.2-5.15.1 | |
@@ -173,10 +176,12 @@ pdfhidden: True
 |  Issue ID 	|   Description	|   Affects	|   Fixed |
 |---	        |---	        |---	    |---	                |
 | <a name="4850551"></a> [4850551](#4850551) <a name="4850551"></a> <br /> | The switch installs suboptimal routes in the routing table and advertises them out. | 5.9.2-5.15.1 | |
+| <a name="4805286"></a> [4805286](#4805286) <a name="4805286"></a> <br /> | During port‑mapping configuration, an edge case might lead to an invalid configuration state, causing the system to eventually become stuck. | 5.11.3-5.15.1 | |
 | <a name="4797691"></a> [4797691](#4797691) <a name="4797691"></a> <br /> | The message that the switch displays when you generate a cl-support file or as a post login banner contains an invalid Cumulus Support email address, which is no longer the formal channel for reporting support issues. | 5.0.0-5.15.1 | |
 | <a name="4789097"></a> [4789097](#4789097) <a name="4789097"></a> <br /> | The switch deletes a static blackhole route even when the blackhole type specified in the delete command does not match the configured type. | 5.9.4-5.15.1 | |
 | <a name="4771875"></a> [4771875](#4771875) <a name="4771875"></a> <br /> | When you poll optical module data with <code>ethtool -m</code>, <code>switchd</code> might crash due to a firmware timeout that triggers a fatal health-check failure. | 5.11.1-5.15.1 | |
 | <a name="4771521"></a> [4771521](#4771521) <a name="4771521"></a> <br /> | 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. | 5.9.2-5.15.1 | |
+| <a name="4729839"></a> [4729839](#4729839) <a name="4729839"></a> <br /> | In an MLAG configuration, when you reboot the primary MLAG switch with PVRST spanning tree mode configured on both MLAG switches, PVRST mode briefly changes to RSTP, then back to PVRST when the primary switch comes back up. | 5.11.3-5.15.1 | |
 | <a name="4721298"></a> [4721298](#4721298) <a name="4721298"></a> <br /> | When node or VM migration occurs between the MLAG pair and the EVPN-MH pair, the MLAG MAC database becomes out of sync with kernel FDB. The migrated MAC addresses remain as local in MLAG MAC database whereas in the kernel, all MAC addresses are updated correctly as remote with the layer 2 next hop ID. To work around this issue, flap the MLAG bond interface to clear the MLAG local database. | 5.11.0-5.15.1 | |
 | <a name="4714845"></a> [4714845](#4714845) <a name="4714845"></a> <br /> | The switch installs suboptimal routes in the routing table and advertises them out. | 5.9.2-5.15.1 | |
 | <a name="4683602"></a> [4683602](#4683602) <a name="4683602"></a> <br /> | When you poll optical module data with <code>ethtool -m</code>, <code>switchd</code> might crash due to a firmware timeout that triggers a fatal health-check failure. | 5.11.1-5.15.1 | |

content/cumulus-linux-511/rn.xml

@@ -13,6 +13,12 @@
 <td></td>
 </tr>
 <tr>
+<td>4805286</td>
+<td>During port‑mapping configuration, an edge case might lead to an invalid configuration state, causing the system to eventually become stuck.</td>
+<td>5.11.3-5.15.1</td>
+<td></td>
+</tr>
+<tr>
 <td>4797691</td>
 <td>The message that the switch displays when you generate a cl-support file or as a post login banner contains an invalid Cumulus Support email address, which is no longer the formal channel for reporting support issues.</td>
 <td>5.0.0-5.15.1</td>
@@ -37,6 +43,22 @@
 <td></td>
 </tr>
 <tr>
+<td>4729839</td>
+<td>In an MLAG configuration, when you reboot the primary MLAG switch with PVRST spanning tree mode configured on both MLAG switches, PVRST mode briefly changes to RSTP, then back to PVRST when the primary switch comes back up.</td>
+<td>5.11.3-5.15.1</td>
+<td></td>
+</tr>
+<tr>
+<td>4722680</td>
+<td>If you install RADIUS client packages when rolling back a two partition upgrade, the {{/var/lib/nvue}}, {{/var/lib/ntpsec}}, and {{/var/lib/snmp}} directories might have incorrect ownership after rollback and the {{nvued}} service might fail to start up. To work around this issue, run the following commands:
+sudo chown -R nvue /var/lib/nvue
+sudo chown -R ntpsec /var/lib/ntpsec
+sudo chown -R Debian-snmp /var/lib/snmp
+sudo reboot</td>
+<td>5.11.4-5.15.1</td>
+<td></td>
+</tr>
+<tr>
 <td>4722539</td>
 <td>Optimized image upgrade with warm boot mode is supported in Cumulus Linux 5.13 and later. When you try to run the {{nv action boot-next}} command during optimized image upgrade in Cumulus Linux 5.12 and earlier to any target release while the system is in warm boot mode, the {{boot-next}} operation fails with the following error:
 cumulus@switch:~$ nv action boot-next system image other
@@ -983,6 +1005,12 @@ NOTICE  CORE_ASYNC: Error at pre send callback status [Resource is in use]</td>
 <td></td>
 </tr>
 <tr>
+<td>4805286</td>
+<td>During port‑mapping configuration, an edge case might lead to an invalid configuration state, causing the system to eventually become stuck.</td>
+<td>5.11.3-5.15.1</td>
+<td></td>
+</tr>
+<tr>
 <td>4797691</td>
 <td>The message that the switch displays when you generate a cl-support file or as a post login banner contains an invalid Cumulus Support email address, which is no longer the formal channel for reporting support issues.</td>
 <td>5.0.0-5.15.1</td>
@@ -1007,6 +1035,12 @@ NOTICE  CORE_ASYNC: Error at pre send callback status [Resource is in use]</td>
 <td></td>
 </tr>
 <tr>
+<td>4729839</td>
+<td>In an MLAG configuration, when you reboot the primary MLAG switch with PVRST spanning tree mode configured on both MLAG switches, PVRST mode briefly changes to RSTP, then back to PVRST when the primary switch comes back up.</td>
+<td>5.11.3-5.15.1</td>
+<td></td>
+</tr>
+<tr>
 <td>4721298</td>
 <td>When node or VM migration occurs between the MLAG pair and the EVPN-MH pair, the MLAG MAC database becomes out of sync with kernel FDB. The migrated MAC addresses remain as local in MLAG MAC database whereas in the kernel, all MAC addresses are updated correctly as remote with the layer 2 next hop ID. To work around this issue, flap the MLAG bond interface to clear the MLAG local database.</td>
 <td>5.11.0-5.15.1</td>