Changes by create-pull-request action

content/cumulus-linux-37/rn.xml

@@ -1958,8 +1958,8 @@ To work around this issue, change the TCAM profile to {{acl-heavy}} or {{ip-acl-
 <td>3135801</td>
 <td>Zebra rejects MAC IP updates from BGP when the MAC mobility sequence number that BGP sends is lower than the sequence number known to zebra.
 When the MAC mobility sequence that BGP knows legitimately lowers (due to narrow timing conditions during convergence or after rebooting an MLAG pair one VTEP at a time),  zebra rejects these updates and maintains a stale state. If the stale information that zebra uses points to the wrong VTEP address, traffic goes to the wrong VTEP and might drop.</td>
-<td>3.7.12-3.7.15</td>
-<td>3.7.16, 4.3.1-4.4.5</td>
+<td>3.7.12-4.3.0</td>
+<td>4.3.1-4.4.5</td>
 </tr>
 <tr>
 <td>3129819, 3040075</td>
@@ -3955,8 +3955,8 @@ MAC learning looks correct, but traffic does not flow as expected.</td>
 <td>3135801</td>
 <td>Zebra rejects MAC IP updates from BGP when the MAC mobility sequence number that BGP sends is lower than the sequence number known to zebra.
 When the MAC mobility sequence that BGP knows legitimately lowers (due to narrow timing conditions during convergence or after rebooting an MLAG pair one VTEP at a time),  zebra rejects these updates and maintains a stale state. If the stale information that zebra uses points to the wrong VTEP address, traffic goes to the wrong VTEP and might drop.</td>
-<td>3.7.12-3.7.15</td>
-<td>3.7.16, 4.3.1-4.4.5</td>
+<td>3.7.12-4.3.0</td>
+<td>4.3.1-4.4.5</td>
 </tr>
 <tr>
 <td>3073668</td>
@@ -5678,8 +5678,8 @@ MAC learning looks correct, but traffic does not flow as expected.</td>
 <td>3135801</td>
 <td>Zebra rejects MAC IP updates from BGP when the MAC mobility sequence number that BGP sends is lower than the sequence number known to zebra.
 When the MAC mobility sequence that BGP knows legitimately lowers (due to narrow timing conditions during convergence or after rebooting an MLAG pair one VTEP at a time),  zebra rejects these updates and maintains a stale state. If the stale information that zebra uses points to the wrong VTEP address, traffic goes to the wrong VTEP and might drop.</td>
-<td>3.7.12-3.7.15</td>
-<td>3.7.16, 4.3.1-4.4.5</td>
+<td>3.7.12-4.3.0</td>
+<td>4.3.1-4.4.5</td>
 </tr>
 <tr>
 <td>3073668</td>
@@ -7611,8 +7611,8 @@ MAC learning looks correct, but traffic does not flow as expected.</td>
 <td>3135801</td>
 <td>Zebra rejects MAC IP updates from BGP when the MAC mobility sequence number that BGP sends is lower than the sequence number known to zebra.
 When the MAC mobility sequence that BGP knows legitimately lowers (due to narrow timing conditions during convergence or after rebooting an MLAG pair one VTEP at a time),  zebra rejects these updates and maintains a stale state. If the stale information that zebra uses points to the wrong VTEP address, traffic goes to the wrong VTEP and might drop.</td>
-<td>3.7.12-3.7.15</td>
-<td>3.7.16, 4.3.1-4.4.5</td>
+<td>3.7.12-4.3.0</td>
+<td>4.3.1-4.4.5</td>
 </tr>
 <tr>
 <td>3073668</td>
@@ -9723,8 +9723,8 @@ MAC learning looks correct, but traffic does not flow as expected.</td>
 <td>3135801</td>
 <td>Zebra rejects MAC IP updates from BGP when the MAC mobility sequence number that BGP sends is lower than the sequence number known to zebra.
 When the MAC mobility sequence that BGP knows legitimately lowers (due to narrow timing conditions during convergence or after rebooting an MLAG pair one VTEP at a time),  zebra rejects these updates and maintains a stale state. If the stale information that zebra uses points to the wrong VTEP address, traffic goes to the wrong VTEP and might drop.</td>
-<td>3.7.12-3.7.15</td>
-<td>3.7.16, 4.3.1-4.4.5</td>
+<td>3.7.12-4.3.0</td>
+<td>4.3.1-4.4.5</td>
 </tr>
 <tr>
 <td>3073668</td>

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

@@ -1064,14 +1064,14 @@ pdfhidden: True
 | 3390022, 3323138 | When you restore the switch configuration after upgrading  from Cumulus Linux 4.2.x to 4.4.5 and later with ONIE, the configuration lines under the <code>peerlink.4095</code> interface stanza are duplicated. Subsequent <code>ifreloads</code>, or <code>net commit</code> commands fail until you manually remove the duplicated lines from this interface and run <code>ifreload -a</code>. | 4.2.1-4.4.5 | |
 | 3376798 | On Broadcom switches, Cumulus Linux does not create the hardware bridging domain for a traditional bridge with a VXLAN interface during <code>switchd</code> restart. The <code>/var/log/switchd.log</code> file includes the following exception logs shortly after <code>switchd</code> restarts:<pre>switchd&#91;30158&#93;: hal_bcm_l3.c:1617 find_egr_path_if_vxlan_overlay:vxlan overlay : nh PORT: port <#>, vlan <x>.<y> not yet ready</pre>MAC learning looks correct, but traffic does not flow as expected. | 3.7.0-4.3.1 | 4.3.2-4.4.5|
 | 3364996 | Under certain conditions, BGP can allow a combination of EVPN and non-EVPN paths to be put into a multipath group together. This results in erroneous programming of EVPN symmetric next hops and RMACs, which can result in momentary traffic drops. | 4.3.0-4.3.1 | 4.3.2-4.4.5|
+| 3364717 | On the Trident 2+ and Trident 3 switch when using VXLAN layer 2 VPNs and sending tunneled traffic where the inner IP header has a TTL of 1, the egress VTEP incorrectly forwards this traffic through the software path instead of the hardware data plane. This traffic is rate-limited to 100pps by default.  To work around this issue, ensure that the traffic traversing the layer 2 tunnel has an inner IP header TTL value that is more than 1.  If this workaround is not possible, contact Nvidia Support to determine other options. | 4.3.0-4.4.5 | |
+| 3358865 | When you reboot a Broadcom switch with a static default route configured, the route might be installed in hardware without a next hop. This results in forwarded traffic to the CPU and drops. To recover from this issue, remove the default route configuration and reapply it. To prevent this issue, before rebooting the switch, split the default route configuration into two routes as below:<pre>ip route 0.0.0.0/1 10.1.1.1ip route 128.0.0.0/1 10.1.1.1</pre> | 4.3.1-4.4.5 | |
 | 3339249 | The <code>sensors.conf</code> files in Cumulus Linux are out of date. | 4.2.1-4.4.5 | |
-| 3336590 | On the Trident 2+ and Trident 3 switch when using VXLAN layer 2 VPNs and sending tunneled traffic where the inner IP header has a TTL of 1, the egress VTEP incorrectly forwards this traffic through the software path instead of the hardware data plane. This traffic is rate-limited to 100pps by default.  To work around this issue, ensure that the traffic traversing the layer 2 tunnel has an inner IP header TTL value that is more than 1.  If this workaround is not possible, contact Nvidia Support to determine other options. | 4.3.0-4.3.1 | 4.3.2-4.4.5|
 | 3334031 | When you configure or unconfigure a BGP peer and interface towards a host, memory corruption can cause BGP to crash. | 4.3.0-4.3.1 | 4.3.2-4.4.5|
 | 3330705 | When using TACACS+, a TACACS+ server name that returns more than one IP address, such as an IPv6 and IPv4 address, is counted many times against the limit of seven TACACS+ servers, which might cause some of the later listed servers to be ignored as over the limit. To work around this issue, you can set the <code>prefer_ip_version</code> configuration option (the default value is 4) to choose between an IPv4 or IPv6 address if both are present. | 3.7.0-5.3.1 | 5.4.0-5.15.1, 5.16.0-5.16.1, 5.16.6-5.18.0|
 | 3327477 | If you use <code>su</code> to change to a user specified through TACACS+, the user becomes the local tacacs0 thru tacacs15 user instead of the named user to run <code>sudo</code> commands. As a result, the named user password might not match the local tacacs0 thru tacacs15 user password. | 3.7.0-3.7.16, 4.0.0-4.4.5, 5.0.0-5.15.1, 5.16.0-5.16.1, 5.16.6-5.18.0 | |
 | 3319919 | Currently, the default core dump size limit on Cumulus Linux is 256M but the SDK generates core dumps around 800M. To avoid incomplete core files, you can increase the core dump size limit. | 4.2.1-4.3.1, 4.4.0-5.3.1 | 4.3.2, 5.4.0-5.15.1, 5.16.0-5.16.1, 5.16.6-5.18.0|
 | 3288385 | On the EdgeCore AS7326-56X and AS7726-32X switch, the fan speed reports a minimum threshold in the logs. | 4.3.1 | 4.3.2-4.4.5|
-| 3288343 | When you reboot a Broadcom switch with a static default route configured, the route might be installed in hardware without a next hop. This results in forwarded traffic to the CPU and drops. To recover from this issue, remove the default route configuration and reapply it. To prevent this issue, before rebooting the switch, split the default route configuration into two routes as below:<pre>ip route 0.0.0.0/1 10.1.1.1ip route 128.0.0.0/1 10.1.1.1</pre> | 4.3.1 | 4.3.2-4.4.5|
 | 3269538 | The <code>cl-ecmpcalc</code> command prints the following error when the egress interface is a bond or SVI:<pre>ecmpcalc: will query hardwareTraceback (most recent call last):File “/usr/cumulus/bin/cl-ecmpcalc”, line 986, inisTrunkMbr, port = ecmp.getHdPort(hd_cmd)File “/usr/cumulus/bin/cl-ecmpcalc”, line 618, in getHdPortport = int(str4)ValueError: invalid literal for int() with base 10: ‘0t</pre> | 3.7.16-4.3.1 | 4.3.2-4.4.5|
 | 3267353 | In a QinQ configuration, if the VLAN priority is a non-zero value, double-tagged packets are translated to triple-tagged packets.  | 4.3.1 | 4.3.2-4.4.5|
 | 3235956 | With certain triggers on Broadcom switches, such as adding or deleting a VNI or reloading the network, Cumulus Linux might consider the underlay routes as overlay routes. In this case, <code>switchd</code> allocates the overlay next hop, which is incorrect and might affect traffic forwarding. | 4.3.0-4.3.1 | 4.3.2-4.4.5|
@@ -1383,8 +1383,8 @@ pdfhidden: True
 | 3390022, 3323138 | When you restore the switch configuration after upgrading  from Cumulus Linux 4.2.x to 4.4.5 and later with ONIE, the configuration lines under the <code>peerlink.4095</code> interface stanza are duplicated. Subsequent <code>ifreloads</code>, or <code>net commit</code> commands fail until you manually remove the duplicated lines from this interface and run <code>ifreload -a</code>. | 4.2.1-4.4.5 | |
 | 3376798 | On Broadcom switches, Cumulus Linux does not create the hardware bridging domain for a traditional bridge with a VXLAN interface during <code>switchd</code> restart. The <code>/var/log/switchd.log</code> file includes the following exception logs shortly after <code>switchd</code> restarts:<pre>switchd&#91;30158&#93;: hal_bcm_l3.c:1617 find_egr_path_if_vxlan_overlay:vxlan overlay : nh PORT: port <#>, vlan <x>.<y> not yet ready</pre>MAC learning looks correct, but traffic does not flow as expected. | 3.7.0-4.3.1 | 4.3.2-4.4.5|
 | 3364996 | Under certain conditions, BGP can allow a combination of EVPN and non-EVPN paths to be put into a multipath group together. This results in erroneous programming of EVPN symmetric next hops and RMACs, which can result in momentary traffic drops. | 4.3.0-4.3.1 | 4.3.2-4.4.5|
+| 3364717 | On the Trident 2+ and Trident 3 switch when using VXLAN layer 2 VPNs and sending tunneled traffic where the inner IP header has a TTL of 1, the egress VTEP incorrectly forwards this traffic through the software path instead of the hardware data plane. This traffic is rate-limited to 100pps by default.  To work around this issue, ensure that the traffic traversing the layer 2 tunnel has an inner IP header TTL value that is more than 1.  If this workaround is not possible, contact Nvidia Support to determine other options. | 4.3.0-4.4.5 | |
 | 3339249 | The <code>sensors.conf</code> files in Cumulus Linux are out of date. | 4.2.1-4.4.5 | |
-| 3336590 | On the Trident 2+ and Trident 3 switch when using VXLAN layer 2 VPNs and sending tunneled traffic where the inner IP header has a TTL of 1, the egress VTEP incorrectly forwards this traffic through the software path instead of the hardware data plane. This traffic is rate-limited to 100pps by default.  To work around this issue, ensure that the traffic traversing the layer 2 tunnel has an inner IP header TTL value that is more than 1.  If this workaround is not possible, contact Nvidia Support to determine other options. | 4.3.0-4.3.1 | 4.3.2-4.4.5|
 | 3334031 | When you configure or unconfigure a BGP peer and interface towards a host, memory corruption can cause BGP to crash. | 4.3.0-4.3.1 | 4.3.2-4.4.5|
 | 3330705 | When using TACACS+, a TACACS+ server name that returns more than one IP address, such as an IPv6 and IPv4 address, is counted many times against the limit of seven TACACS+ servers, which might cause some of the later listed servers to be ignored as over the limit. To work around this issue, you can set the <code>prefer_ip_version</code> configuration option (the default value is 4) to choose between an IPv4 or IPv6 address if both are present. | 3.7.0-5.3.1 | 5.4.0-5.15.1, 5.16.0-5.16.1, 5.16.6-5.18.0|
 | 3327477 | If you use <code>su</code> to change to a user specified through TACACS+, the user becomes the local tacacs0 thru tacacs15 user instead of the named user to run <code>sudo</code> commands. As a result, the named user password might not match the local tacacs0 thru tacacs15 user password. | 3.7.0-3.7.16, 4.0.0-4.4.5, 5.0.0-5.15.1, 5.16.0-5.16.1, 5.16.6-5.18.0 | |

content/cumulus-linux-43/rn.xml

@@ -7644,18 +7644,28 @@ MAC learning looks correct, but traffic does not flow as expected.</td>
 <td>4.3.2-4.4.5</td>
 </tr>
 <tr>
+<td>3364717</td>
+<td>On the Trident 2+ and Trident 3 switch when using VXLAN layer 2 VPNs and sending tunneled traffic where the inner IP header has a TTL of 1, the egress VTEP incorrectly forwards this traffic through the software path instead of the hardware data plane. This traffic is rate-limited to 100pps by default.  To work around this issue, ensure that the traffic traversing the layer 2 tunnel has an inner IP header TTL value that is more than 1.  If this workaround is not possible, contact Nvidia Support to determine other options.</td>
+<td>4.3.0-4.4.5</td>
+<td></td>
+</tr>
+<tr>
+<td>3358865</td>
+<td>When you reboot a Broadcom switch with a static default route configured, the route might be installed in hardware without a next hop. This results in forwarded traffic to the CPU and drops. To recover from this issue, remove the default route configuration and reapply it. To prevent this issue, before rebooting the switch, split the default route configuration into two routes as below:
+
+ip route 0.0.0.0/1 10.1.1.1
+ip route 128.0.0.0/1 10.1.1.1
+</td>
+<td>4.3.1-4.4.5</td>
+<td></td>
+</tr>
+<tr>
 <td>3339249</td>
 <td>The {{sensors.conf}} files in Cumulus Linux are out of date.</td>
 <td>4.2.1-4.4.5</td>
 <td></td>
 </tr>
 <tr>
-<td>3336590</td>
-<td>On the Trident 2+ and Trident 3 switch when using VXLAN layer 2 VPNs and sending tunneled traffic where the inner IP header has a TTL of 1, the egress VTEP incorrectly forwards this traffic through the software path instead of the hardware data plane. This traffic is rate-limited to 100pps by default.  To work around this issue, ensure that the traffic traversing the layer 2 tunnel has an inner IP header TTL value that is more than 1.  If this workaround is not possible, contact Nvidia Support to determine other options.</td>
-<td>4.3.0-4.3.1</td>
-<td>4.3.2-4.4.5</td>
-</tr>
-<tr>
 <td>3334031</td>
 <td>When you configure or unconfigure a BGP peer and interface towards a host, memory corruption can cause BGP to crash.</td>
 <td>4.3.0-4.3.1</td>
@@ -7686,16 +7696,6 @@ MAC learning looks correct, but traffic does not flow as expected.</td>
 <td>4.3.2-4.4.5</td>
 </tr>
 <tr>
-<td>3288343</td>
-<td>When you reboot a Broadcom switch with a static default route configured, the route might be installed in hardware without a next hop. This results in forwarded traffic to the CPU and drops. To recover from this issue, remove the default route configuration and reapply it. To prevent this issue, before rebooting the switch, split the default route configuration into two routes as below:
-
-ip route 0.0.0.0/1 10.1.1.1
-ip route 128.0.0.0/1 10.1.1.1
-</td>
-<td>4.3.1</td>
-<td>4.3.2-4.4.5</td>
-</tr>
-<tr>
 <td>3269538</td>
 <td>The {{cl-ecmpcalc}} command prints the following error when the egress interface is a bond or SVI:
 
@@ -9853,18 +9853,18 @@ MAC learning looks correct, but traffic does not flow as expected.</td>
 <td>4.3.2-4.4.5</td>
 </tr>
 <tr>
+<td>3364717</td>
+<td>On the Trident 2+ and Trident 3 switch when using VXLAN layer 2 VPNs and sending tunneled traffic where the inner IP header has a TTL of 1, the egress VTEP incorrectly forwards this traffic through the software path instead of the hardware data plane. This traffic is rate-limited to 100pps by default.  To work around this issue, ensure that the traffic traversing the layer 2 tunnel has an inner IP header TTL value that is more than 1.  If this workaround is not possible, contact Nvidia Support to determine other options.</td>
+<td>4.3.0-4.4.5</td>
+<td></td>
+</tr>
+<tr>
 <td>3339249</td>
 <td>The {{sensors.conf}} files in Cumulus Linux are out of date.</td>
 <td>4.2.1-4.4.5</td>
 <td></td>
 </tr>
 <tr>
-<td>3336590</td>
-<td>On the Trident 2+ and Trident 3 switch when using VXLAN layer 2 VPNs and sending tunneled traffic where the inner IP header has a TTL of 1, the egress VTEP incorrectly forwards this traffic through the software path instead of the hardware data plane. This traffic is rate-limited to 100pps by default.  To work around this issue, ensure that the traffic traversing the layer 2 tunnel has an inner IP header TTL value that is more than 1.  If this workaround is not possible, contact Nvidia Support to determine other options.</td>
-<td>4.3.0-4.3.1</td>
-<td>4.3.2-4.4.5</td>
-</tr>
-<tr>
 <td>3334031</td>
 <td>When you configure or unconfigure a BGP peer and interface towards a host, memory corruption can cause BGP to crash.</td>
 <td>4.3.0-4.3.1</td>