Cumulus RMP 3.2.1 Release Notes

Follow

Overview

These release notes support Cumulus RMP 3.2.1 and describe currently available features and known issues.

Cumulus RMP 3.2.1 supports these features and is available on the Penguin Computing Arctica 4804IP-RMP out-of-band switch.

Stay up to Date 

  • Please sign in and click Follow above so you can receive a notification when we update these release notes.
  • Subscribe to our product bulletin mailing list to receive important announcements and updates about issues that arise in our products.
  • Subscribe to our security announcement mailing list to receive alerts whenever we update our software for security issues.

{{table_of_contents}}

What's New in Cumulus RMP 3.2.1

Cumulus RMP 3.2.1 includes the following improvement:

  • Network Command Line Utility: We've improved the syntax so it's even easier for network operators to configure Cumulus Linux with NCLU.

Installing Version 3.2.1

If you are upgrading from version 3.0.0 or later, use apt-get to update the software.

  1. Run apt-get update.
  2. Run apt-get upgrade.
  3. Reboot the switch.

New Install or Upgrading from Versions Older than 3.0.0

If you are upgrading from a version older than 3.0.0, or installing Cumulus RMP for the first time, download the Cumulus RMP 3.2.1 installer for Broadcom switches from the Cumulus Networks website, then use ONIE to perform a complete install, following the instructions in the user guide.

Note: This method is destructive; any configuration files on the switch will not be saved, so please copy them to a different server before upgrading via ONIE.

Important! After you install, run apt-get update, then apt-get upgrade on your switch to make sure you update Cumulus RMP to include any important or other package updates.

Documentation

You can read the technical documentation here.

Issues Fixed in Cumulus RMP 3.2.1

The following is a list of issues fixed in Cumulus RMP 3.2.1 from earlier versions of Cumulus RMP.

Release Note ID Summary Description

RN-546 (CM-14051)
netd crashes at "snapper list" after running "net show commit history"

This issue has been seen on switches that upgraded from a version of Cumulus RMP earlier than 3.2.1. To work around the issue, install the cumulus-snapshot package on the switch. This activates the NCLU rollback capability.

cumulus@switch:~$ sudo apt-get install cumulus-snapshot

This issue has been fixed in Cumulus RMP 3.2.1.


RN-550 (CM-13674)
The ZTP daemon shuts itself down after 5 minutes of inactivity

The zero touch provisioning (ZTP) daemon ztpd shuts itself down after 5 minutes of inactivity but the service remains enabled for the next reboot.

This can affect deployments where a switch might be powered up in a remote data center for weeks without ever being configured. In such a case, there is no way to automatically initiate the ZTP process.

This issue has been fixed in Cumulus RMP 3.2.1.


RN-551 (CM-14264)
Layer 3 egress rewrite information associated with wrong VLAN, causing uplinks to stop forwarding traffic toward the core

A race condition can occur where forwarding rewrite information may not get programmed correctly, when a port is configured as a bridge port and is then reconfigured as a layer 3 uplink port. In this scenario, the exact same neighbor is falsely being re-learned immediately on the reconfigured port, resulting in layer 3 egress rewrite pointing to the bridge, rather than the intended next hop.

This issue has been fixed in Cumulus RMP 3.2.1.


RN-555 (CM-14069)
apt doesn't validate InRelease signatures correctly; DSA-3711, CVE-2016-1252

Jann Horn of Google Project Zero discovered that APT, the high level package manager, does not properly handle errors when validating signatures on InRelease files. An attacker able to man-in-the-middle HTTP requests to an apt repository that uses InRelease files (clearsigned Release files), can take advantage of this flaw to circumvent the signature of the InRelease file, leading to arbitrary code execution.

This issue has been fixed Debian Jessie version 1.0.9.8.4 and also in Cumulus RMP 3.2.1.


RN-557 (CM-14157)
Security patch for CVE-2016-8655 af_packet.c namespace vulnerability

This is a a fix for security issue CVE-2016-8655.

It is a vulnerability that requires local access, so it's not remotely exploitable.

This issue has been fixed in Cumulus RMP 3.2.1.


RN-558 (CM-14125)
Kernel panic in multicast_v4_queriers_show during ifreload -a

Cumulus RMP wasn't checking for configured VLANs, which resulted in some corruption.

This issue has been fixed in Cumulus RMP 3.2.1.


RN-565 (CM-14289)
dhcpd crash due to memory corruption

A dhcpd crash was caused by memory corruption that led to isc-dhcp restarting multiple times. This was caused by a race condition that led to stale pointer access.

This issue has been fixed in Cumulus RMP 3.2.1.


RN-566 (CM-13816)
netshow interface doesn't display interfaces defined in interfaces.d/

Interfaces defined in files accessed via a source in /etc/network/interfaces are not printed when netshow interface is run.

This issue has been fixed in Cumulus RMP 3.2.1.


RN-569 (CM-13853)
Create /etc/default/isc-dhcp-relay6 by default for IPv6 support of DHCP relay

Users were previously required to create a service in order to enable IPv6 DHCP relay support. An empty /etc/default/isc-dhcp-relay6 file has been added to allow for IPv6 DHCP relay to be enabled without creating a service.

This issue has been fixed in Cumulus RMP 3.2.1.

Known Issues in Cumulus RMP 3.2.1

Issues are categorized for easy review. Some issues are fixed but will be available in a later release.

Release Note ID Summary Description

RN-56 (CM-343)
IPv4/IPv6 forwarding disabled mode not recognized

If either of the following is configured:

net.ipv4.ip_forward == 0 

or:

net.ipv6.conf.all.forwarding == 0 

The hardware still forwards packets if there is a neighbor table entry pointing to the destination.


RN-120 (CM-477)
ethtool LED blinking does not work with switch ports Linux uses ethtool -p to identify the physical port backing an interface, or to identify the switch itself. Usually this identification is by blinking the port LED until ethtool -p is stopped.

This feature does not apply to switch ports (swpX) in Cumulus RMP.

RN-121 (CM-2123)
ptmd: When a physical interface is in a PTM FAIL state, its subinterface still exchanges information Issue:
When ptmd is incorrectly in a failure state and the Zebra interface is enabled, PIF BGP sessions are not establishing the route, but the subinterface on top of it does establish routes.

If the subinterface is configured on the physical interface and the physical interface is incorrectly marked as being in a PTM FAIL state, routes on the physical interface are not processed in Quagga, but the subinterface is working.

Steps to reproduce:
cumulus@switch:$ sudo vtysh -c 'show int swp8' 
Interface swp8 is up, line protocol is up 
PTM status: fail
index 10 metric 1 mtu 1500 
 flags: <UP,BROADCAST,RUNNING,MULTICAST>
 HWaddr: 44:38:39:00:03:88 
 inet 12.0.0.225/30 broadcast 12.0.0.227 
 inet6 2001:cafe:0:38::1/64 
 inet6 fe80::4638:39ff:fe00:388/64 
cumulus@switch:$ ip addr show | grep swp8 
 10: swp8: <BROADCAST,MULTICAST,UP,LOWER_UP> 
  mtu 1500 qdisc pfifo_fast state UP qlen 500 
  inet 12.0.0.225/30 brd 12.0.0.227 scope global swp8 
 104: swp8.2049@swp8: <BROADCAST,MULTICAST,UP,LOWER_UP> 
  mtu 1500 qdisc noqueue state UP 
  inet 12.0.0.229/30 brd 12.0.0.231 scope global swp8.2049 
 105: swp8.2050@swp8: <BROADCAST,MULTICAST,UP,LOWER_UP> 
  mtu 1500 qdisc noqueue state UP 
  inet 12.0.0.233/30 brd 12.0.0.235 scope global swp8.2050 
 106: swp8.2051@swp8: <BROADCAST,MULTICAST,UP,LOWER_UP> 
  mtu 1500 qdisc noqueue state UP 
  inet 12.0.0.237/30 brd 12.0.0.239 scope global swp8.2051 
 107: swp8.2052@swp8: <BROADCAST,MULTICAST,UP,LOWER_UP> 
  mtu 1500 qdisc noqueue state UP 
  inet 12.0.0.241/30 brd 12.0.0.243 scope global swp8.2052 
 108: swp8.2053@swp8: <BROADCAST,MULTICAST,UP,LOWER_UP>
  mtu 1500 qdisc noqueue state UP 
  inet 12.0.0.245/30 brd 12.0.0.247 scope global swp8.2053 
 109: swp8.2054@swp8: <BROADCAST,MULTICAST,UP,LOWER_UP> 
  mtu 1500 qdisc noqueue state UP 
  inet 12.0.0.249/30 brd 12.0.0.251 scope global swp8.2054
 110: swp8.2055@swp8: <BROADCAST,MULTICAST,UP,LOWER_UP>
  mtu 1500 qdisc noqueue state UP 
  inet 12.0.0.253/30 brd 12.0.0.255 scope global swp8.2055
cumulus@switch:$ bgp sessions: 
 12.0.0.226 ,4 ,64057 , 958 , 1036 , 0 , 0 , 0 ,15:55:42, 0, 10472 
 12.0.0.230 ,4 ,64058 , 958 , 1016 , 0 , 0 , 0 ,15:55:46, 187, 10285
 12.0.0.234 ,4 ,64059 , 958 , 1049 , 0 , 0 , 0 ,15:55:40, 187, 10285 
 12.0.0.238 ,4 ,64060 , 958 , 1039 , 0 , 0 , 0 ,15:55:45, 187, 10285 
 12.0.0.242 ,4 ,64061 , 958 , 1014 , 0 , 0 , 0 ,15:55:46, 187, 10285 
 12.0.0.246 ,4 ,64062 , 958 , 1016 , 0 , 0 , 0 ,15:55:46, 187, 10285 
 12.0.0.250 ,4 ,64063 , 958 , 1029 , 0 , 0 , 0 ,15:55:43, 187, 10285 
 12.0.0.254 ,4 ,64064 , 958 , 1036 , 0 , 0 , 0 ,15:55:44, 187, 10285 

RN-398 (CM-10379)
While upgrading Cumulus RMP, a prompt to configure grub-pc appears

While upgrading to the latest version of Cumulus RMP from version 2.5.5 or earlier, a prompt appears, asking you to choose onto which partitions to install the GRUB boot loader. 

... 

  1. /dev/mmcblk0 (3783 MB; ???)       3. /dev/dm-2 (1610 MB; CUMULUS-SYSROOT1)
  2. - /dev/mmcblk0p3 (268 MB; /boot)  4. none of the above

(Enter the items you want to select, separated by spaces.)

GRUB install devices:

...

This prompt should not appear, and the issue will be fixed in a future release.

In the meantime, to work around this issue, choose option 1, /dev/mmcblk0 and continue the upgrade.


RN-550 (CM-13674)
The ZTP daemon shuts itself down after 5 minutes of inactivity

The zero touch provisioning (ZTP) daemon ztpd shuts itself down after 5 minutes of inactivity but the service remains enabled for the next reboot.

This can affect deployments where a switch might be powered up in a remote data center for weeks without ever being configured. In such a case, there is no way to automatically initiate the ZTP process.

This is a known issue that will be fixed in a future release of Cumulus RMP.


RN-570 (CM-14499)
apt-get upgrade overwrites edits to TCAM and buffering profiles in datapath.conf without prompting

If you changed the buffering or TCAM profiles in either of the following files, the changes will be lost when you upgrade the cumulus-tools package:

  • /usr/lib/python2.7/dist-packages/cumulus/__chip_config/bcm/datapath.conf
  • /usr/lib/python2.7/dist-packages/cumulus/__chip_config/mlx/datapath.conf

Since the files are not marked as configuration files, they get overwritten without warning.

If you have changed either or both of these files, make sure to back them up before running apt-get upgrade or otherwise upgrading the cumulus-tools package, then re-apply your changes to the newly installed files after the upgrade.


RN-572 (CM-14844)
Invalid locale settings can prevent apt-get upgrade from completing

In some cases, if your locale information (language and/or character set) are invalid for Linux, you may encounter errors like the following when running apt-get upgrade when the upgrade snapshot is taken:

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
	LANGUAGE = (unset),
	LC_ALL = (unset),
	LC_CTYPE = "UTF-8",
	LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_US.UTF-8").
Creating pre-apt snapshot... Failed to set locale. Fix your system.
ERROR:/usr/lib/cumulus/apt-snapshot-hook: Unable to create pre snapshot
E: Problem executing scripts DPkg::Pre-Invoke '/usr/lib/cumulus/apt-snapshot-hook pre-invoke'
E: Sub-process returned an error code

This is an issue with the snapper application, which takes snapshots of the Cumulus Linux NOS. Cumulus Networks intends to update snapper in the future so this issue will not cause an error. 

To work around this error, set your locale information to valid settings, such as the following:

export LC_CTYPE=en_US.UTF-8

Then run apt-get upgrade again.


RN-576 (CM-14908)
TACACS sends authentication requests out of the default VRF, not the management VRF

If a management VRF if configured, TACACS won't send authentication requests out of the management VRF. Instead, it sends these requests out of the default VRF.

To work around this issue, run the following commands, which restrict inbound SSH to only the management VRF interface and disable inbound SSH via the switch ports. Note that using SSH via the front panel ports is not a workaround.

cumulus@switch:~$ sudo systemctl disable ssh.service
cumulus@switch:~$ sudo systemctl stop ssh.service
cumulus@switch:~$ sudo systemctl enable ssh@mgmt.service
cumulus@switch:~$ sudo systemctl start ssh@mgmt.service
Have more questions? Submit a request

Comments

Powered by Zendesk