Cumulus RMP 3.0.1 Release Notes

Follow

Overview

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

Cumulus RMP 3.0.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.0.1

Cumulus RMP 3.0.1 includes bug fixes only.

Cumulus RMP 3.0.z is a significant departure from earlier releases. See the user guide for details on new behaviors and functionality.

Deprecated Features

  • cl-img-install
  • Disk image slots
  • /mnt/persist: For information and strategies on how to preserve your network configuration across software upgrades, read the Upgrading Cumulus RMP chapter.
  • cl-brctl. This utility was simply a symlink to brctl, which is what you should use to configure bridges, VLANs and the like.

Installing Version 3.0.1

If you are upgrading from version 3.0.0, 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.0.1 installer 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.0.1

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

Release Note ID Summary Description

RN-366 (CM-8894)
A policer on a traditional bridge is supported and functional; however, once a bridge has a VNI associated, the policer is no longer matched

Policers were not enabled on VXLAN-enabled bridges. This meant that while a policer on a traditional bridge was supported and functional, once a the bridge had a VNI associated, the policer no longer matched. By adding vpn as a match field in the IFP qset, policers are now enabled on VXLAN bridges, correcting the issue.


RN-395 (CM-10230)
Must reboot after installing license for first time after image install

When you install a Cumulus RMP license for the first time after you install a Cumulus RMP image, the license tool says that you must either reboot or run systemctl restart switchd.

Cumulus Networks recommends you reboot the switch after installing the license in order for the switch to function correctly.


RN-436 (CM-11441)
Aborting the ZTP process does not unmount the partition if the process didn't exit properly

If you abort the zero touch provisioning (ZTP) process, and ZTP does not exit properly, the partition remains mounted. If you run the process again again, ZTP looks for an unmounted partition, and cannot find the USB partition again.

This issue has been fixed in Cumulus RMP 3.0.1.

Known Issues in Cumulus RMP 3.0.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-58 (CM-747)
IPv6 route is installed and active in the routing table when the associated interface is down If an IPv6 address is assigned to a "down" interface, the associated route is still installed into the route table.

Also, the type of IPv6 address doesn't matter. Link local, site local, and global all exhibit the same problem.

If the interface is bounced up and down, then the routes are no longer in the route table.

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-132 (CM-2272)
You must run "apt-get update" before running any apt-get commands or after changing sources.list

Before running any apt-get commands or after changing the source.list file in /etc/apt, you need to run apt-get update.


RN-133 (CM-2273)
Interface names in Cumulus RMP cannot exceed 15 characters

Device names, including interface names, in Cumulus RMP cannot exceed 16 characters – including the terminator. Cumulus RMP truncates longer interface names.

To avoid this issue, do not assign long names to your interfaces.

The following example configuration reproduces this issue:

cumulus@switch:/sys/class/net$ grep 'iface br' /etc/network/interfaces 
iface br2-pubmgmt inet static
iface br3-prvmgmt inet manual
iface br400-quarantine inet manual
iface br401-peering-1k5 inet manual
iface br402-peering-9k inet manual
iface br500-pi-exa inet manual
iface br501-akamai-exa inet manual
iface br502-exa-internetfactory inet manual
cumulus@switch:/sys/class/net$ brctl show | grep br
bridge name	bridge id	 STP enabled	interfaces
br2-pubmgmt	 8000.089e01cebe37	no	 bond0.2
br3-prvmgmt	 8000.089e01cebe3a	no	 bond0.3
br400-quarantin	 8000.089e01cebe37	no	 bond0.400
br401-peering-1	 8000.089e01cebe3a	no	 bond0.401 <<<

RN-229 (CM-4433)
When a bond subinterface that is part of a traditional bridge is brought down, it flaps that bridge This issue has been encountered in environments where both VLAN-aware and traditional bridges are in use, where a traditional bridge has a subinterface of a bond that is present as a normal interface in a VLAN-aware bridge.

RN-281 (CM-5118)
Default route not removed on ifup after removing gateway statement from eth0 configuration

If you try to remove the default route from eth0 (either by commenting out or removing the gateway statement in the eth0 configuration), the route remains after running ifup.

To work around this issue, first run ifdown, then ifup on the interface via the console. After this, the route disappears.


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-403 (CM-10968)
default.target is set to graphical.target

The default.target for systemd is mistakenly set to graphical.target in this release, instead of multi-user.target. You may see this message in the journal or syslog at system boot:

systemd[1]: Cannot add dependency job for unit display-manager.service, ignoring: Unit display-manager.service failed to load: No such file or directory.

You should ignore this message, as the correct systemd state is reached, since the multi-user.target is a prerequisite of graphical.target.

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


RN-405 (CM-8720)
ifupdown2: IP address scope is not working; all addresses considered global

ifupdown2 does not honor the configured IP address scope setting in /etc/network/interfaces, and it does not report an error. Consider this example configuration:

auto swp2
iface swp2
    address 35.21.30.5/30
    address 3101:21:20::31/80
    scope link

When you run ifreload -a on this configuration, ifupdown2 considers all IP addresses as global.

cumulus@switch:~$ ip addr show swp2
5: swp2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 74:e6:e2:f5:62:82 brd ff:ff:ff:ff:ff:ff
inet 35.21.30.5/30 scope global swp2
valid_lft forever preferred_lft forever
inet6 3101:21:20::31/80 scope global 
valid_lft forever preferred_lft forever
inet6 fe80::76e6:e2ff:fef5:6282/64 scope link 
valid_lft forever preferred_lft forever

To work around this issue, configure the IP address scope using post-up ip address add <address> dev <interface> scope <scope>. In continuing with the previous example:

auto swp6
iface swp6
    post-up ip address add 71.21.21.20/32 dev swp6 scope site

Now, when you run ifreload -a on this configuration, it has the correct scope:

cumulus@switch:~$ ip addr show swp6
9: swp6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 74:e6:e2:f5:62:86 brd ff:ff:ff:ff:ff:ff
inet 71.21.21.20/32 scope site swp6
valid_lft forever preferred_lft forever
inet6 fe80::76e6:e2ff:fef5:6286/64 scope link 
valid_lft forever preferred_lft forever

RN-407 (CM-11103)
When the sx_sdk service is restarted manually or during a package upgrade, switchd receives "Invalid Handle" errors

When the sx_sdk service is restarted manually, or when the sx_sdk Debian package is upgraded, switchd receives "Invalid Handle" errors:

2016-05-20T20:05:15.144736+00:00 mlx-2700-01 switchd[14396]: hal_mlx.c:4620 [SX_API_INTERNAL     ]: Invalid handle: handle is not valid.
2016-05-20T20:05:15.145099+00:00 mlx-2700-01 switchd[14396]: hal_mlx_port.c:1789 ERR port_pfc_stats_get failed for lid 0x13c00 prio 2: Invalid Handle
2016-05-20T20:05:15.145460+00:00 mlx-2700-01 switchd[14396]: hal_mlx.c:4620 [SX_API_INTERNAL     ]: Invalid handle: handle is not valid.
2016-05-20T20:05:15.145847+00:00 mlx-2700-01 switchd[14396]: hal_mlx_port.c:1789 ERR port_pfc_stats_get failed for lid 0x13c00 prio 3: Invalid Handle

These error messages are being investigated, but in the meantime, you should restart switchd when you restart sx-sdk. This ensures that the services recognize the other has been restarted manually.


RN-414 (CM-11175)
Kernel source not added to Cumulus Networks repository

Kernel source (linux<vers>.orig.tar.xz and linux<vers>.debian.tar.xz) files are not being added properly to the Cumulus Networks repository.

You can retrieve these packages manually with apt-get source <package name>. For example, to retrieve the Cumulus Networks linux-image source package, run:

cumulus@switch:~$ sudo apt-get install linux-source-4.1

The archive file is stored at /usr/src/linux-source-4.1.tar.xz.


RN-426 (CM-5970)
isc-dhcp-relay must be restarted after flapping an interface or if logical interface is down

There are two known issues regarding isc-dhcp-relay:

  • If isc-dhcp-relay is already running and a host-facing interface is flapped (brought down then up using ifupdown2), the DHCP relay will not work for that interface until isc-dhcp-relay is restarted.
  • If a logical interface defined in /etc/default/isc-dhcp-relay is down when isc-dhcp-relay is started or restarted, then isc-dhcp-relay will not start; thus, the DHCP relay will not work for any interfaces.

To work around the issue, apply the following configuration to each interface specified in INTERFACES from /etc/default/isc-dhcp-relay to the corresponding iface in /etc/network/interfaces:

post-up test -e /var/run/boot.done && service isc-dhcp-relay restart

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.

Have more questions? Submit a request

Comments

Powered by Zendesk