Skip to content

Commit 6fa0d79

Browse files
author
Cumulus Docs CI
committed
Auto commit of release note update
[skip ci]
1 parent c421643 commit 6fa0d79

File tree

10 files changed

+10
-686
lines changed

10 files changed

+10
-686
lines changed

‎content/cumulus-linux-37/Whats-New/rn.md‎

Lines changed: 0 additions & 49 deletions
Large diffs are not rendered by default.

‎content/cumulus-linux-37/rn.xml‎

Lines changed: 0 additions & 311 deletions
Large diffs are not rendered by default.

‎content/cumulus-linux-40/Whats-New/rn.md‎

Lines changed: 1 addition & 7 deletions
Large diffs are not rendered by default.

‎content/cumulus-linux-40/rn.xml‎

Lines changed: 9 additions & 45 deletions
Original file line numberDiff line numberDiff line change
@@ -2428,18 +2428,6 @@ You can ignore these errors.</td>
24282428
<td>3.7.13-3.7.14, 4.1.0-4.3.0</td>
24292429
</tr>
24302430
<tr>
2431-
<td>2548050</td>
2432-
<td>In EVPN Active-Active (MLAG) environments, rebooting one member of an MLAG pair should result in the local MAC mobility sequence number reverting to 0. Sometimes a reboot of one MLAG peer results in the local MAC mobility sequence number being set to a non-zero value despite that no more mobility events occur. This issue is cosmetic only, as BGP does not advertise the incorrect sequence number and forwarding entries correctly point to the remote VTEP where the MAC is now located.</td>
2433-
<td>3.7.12-3.7.14.2, 4.0.0-4.3.0</td>
2434-
<td></td>
2435-
</tr>
2436-
<tr>
2437-
<td>2548047</td>
2438-
<td>In an EVPN Active-Active (MLAG) environment, sometimes a local-to-remote MAC mobility event results in the local sequence number appearing higher than the remote sequence number in zebra. This issue is cosmetic only, as BGP does not advertise the incorrect sequence number and forwarding entries correctly point to the remote VTEP where the MAC is now located.</td>
2439-
<td>3.7.12-3.7.14.2, 4.0.0-4.3.0</td>
2440-
<td></td>
2441-
</tr>
2442-
<tr>
24432431
<td>2548024</td>
24442432
<td>On the Dell Z9100 switch, 100G-SR4 modules might not link up reliably in certain ports.
24452433
swp1, 2, 3, 9, 10, 23, 24, 30, 31, and 32 might be affected
@@ -2522,13 +2510,6 @@ To work around this issue, reboot the switch.</td>
25222510
<td></td>
25232511
</tr>
25242512
<tr>
2525-
<td>2547700</td>
2526-
<td>On the Dell S5232F-ON switch, EVPN and dynamic VRF route leaking results in the CPU forwarding traffic to newly-learned type-2 routes.
2527-
To work around this issue, restart FRR.</td>
2528-
<td>3.7.9-3.7.14.2, 4.0.0-4.3.0</td>
2529-
<td></td>
2530-
</tr>
2531-
<tr>
25322513
<td>2547667</td>
25332514
<td>On the Dell S5232F-ON switch, the output of {{ledmgrd}} shows {{amber_blinking}} but {{smonctl}} shows all OK.</td>
25342515
<td>3.7.11-3.7.12, 4.0.0-4.1.1</td>
@@ -3565,12 +3546,6 @@ cumulus@switch:~$ net add bridge mybridge vlan-protocol 802.1ad
35653546
<td></td>
35663547
</tr>
35673548
<tr>
3568-
<td>2542874</td>
3569-
<td>If a packet is policed by ebtables, it does not increment an ACL drop on the ingress interface. Instead, it increments the TDBGC3/6 drop counter to the CPU.</td>
3570-
<td>3.7.6-3.7.14.2, 4.0.0-4.3.0</td>
3571-
<td></td>
3572-
</tr>
3573-
<tr>
35743549
<td>2542872</td>
35753550
<td>After you issue the NCLU {{net del bgp vrf &lt;vrf&gt; autonomous-system &lt;AS&gt;}} command and commit the change, Cumulus Linux does not remove the configuration from the {{/etc/frr/frr.conf}} file or the {{net show config commands}}.
35763551
</td>
@@ -3848,12 +3823,6 @@ To restore connectivity, remove the VLAN ID from the bridge. </td>
38483823
<td></td>
38493824
</tr>
38503825
<tr>
3851-
<td>2538766</td>
3852-
<td>On the Mellanox switch, when you configure a GRE tunnel, the traffic behind the local tunnel endpoint destined through the GRE tunnel is software-forwarded. </td>
3853-
<td>3.7.2-3.7.14.2, 4.0.0-4.3.0</td>
3854-
<td></td>
3855-
</tr>
3856-
<tr>
38573826
<td>2538740</td>
38583827
<td>In an EVPN symmetric routing configuration, when an IP address is frozen, kernel neighbor table information and kernel VRF routing table information about the frozen IP address might be out-of-sync.
38593828
</td>
@@ -3897,13 +3866,6 @@ Note: The advertised link mode gets set incorrectly if you include 1000baseT/Hal
38973866
<td>4.1.0-4.3.0</td>
38983867
</tr>
38993868
<tr>
3900-
<td>2538076</td>
3901-
<td>In an EVPN centralized routing configuration, where the layer 2 network extends beyond VTEPs, (for example, a host with bridges), the gateway MAC address does not get refreshed in the network when ARP suppression is enabled on the gateway.
3902-
To work around this issue, disable ARP suppression on the centralized gateway.</td>
3903-
<td>4.0.0-4.3.0</td>
3904-
<td></td>
3905-
</tr>
3906-
<tr>
39073869
<td>2537699</td>
39083870
<td>There is a limitation on the number of SVI interfaces you can specify as DHCP relay interfaces in the {{/etc/default/isc-dhcp-relay}} file. For example, 1500 SVI interfaces causes the {{dhcrelay}} service to exit without a core file and logs similar to the following are generated for the interfaces:
39093871

@@ -4091,13 +4053,6 @@ To work around this issue, use the {{sudo ifdown &lt;bondname&gt;}} command.</td
40914053
<td>4.1.0-4.3.0</td>
40924054
</tr>
40934055
<tr>
4094-
<td>2531740</td>
4095-
<td>FRR tracks interface speed based on the value it learns from the Linux kernel for that interface. If the interface speed changes, FRR does not update its interface speed cache. This can lead to issues for routing protocols that derive metrics from interface speed as the cost can become out of sync with the interface speed.
4096-
To work around this issue, manually define the routing protocol metric for these interfaces or restart FRR.</td>
4097-
<td>3.7.6-3.7.14.2, 4.0.0-4.3.0</td>
4098-
<td></td>
4099-
</tr>
4100-
<tr>
41014056
<td>2531273</td>
41024057
<td>In certain cases, a peer device sends an ARP request from a source IP address that is not on the connected subnet and the switch creates a STALE neighbor entry. Eventually, the switch attempts to keep the entry fresh and sends ARP requests to the host. If the host responds, the switch has REACHABLE neighbor entries for hosts that are not on the connected subnet.
41034058
To work around this issue, change the value of {{arp_ignore}} to 2. See [Address Resolution Protocol in the Cumulus Linux user guide|https://docs.cumulusnetworks.com/cumulus-linux/Layer-3/Address-Resolution-Protocol-ARP/] for more information.</td>
@@ -4166,6 +4121,15 @@ To work around this issue, reboot the leaf switch or restart {{switchd}}.</td>
41664121
<td>3.7.8</td>
41674122
</tr>
41684123
<tr>
4124+
<td>2547381</td>
4125+
<td>The {{hsflowd}} service sends an undefined header protocol 0 in the sampled flow sample to the collector, which is not recognized by the sFlow tool. You see errors similar to the following:
4126+
4127+
Dec 20 08:43:27 netflow-nms sfcapd[3991]: SFLOW: readFlowSample_header() undefined headerProtocol = 0
4128+
4129+
</td>
4130+
<td>3.7.11-3.7.14</td>
4131+
</tr>
4132+
<tr>
41694133
<td>2545563</td>
41704134
<td>The following Linux kernel security vulnerabilities do not affect Cumulus Linux in supported configurations:
41714135
CVE-2018-12207 CVE-2019-0154 CVE-2019-0155 CVE-2019-11135

0 commit comments

Comments
 (0)