Cumulus RMP 3.1.1 Release Notes

Follow

Overview

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

Cumulus RMP 3.1.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.1.1

Cumulus RMP 3.1.1 contains bug fixes only.

Installing Version 3.1.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.1.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.1.1

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

Release Note ID Summary Description

RN-465 (CM-11480)
IPv6 next hop global and peer addresses are ignored in favor of the link local address

When receiving a route from an IPv6 eBGP neighbor, Cumulus RMP always installs the link local address instead of the peer address or the global address, even with a route map. This can cause issues in circumstances like when the neighbor router is advertising a virtual IP address as the next hop for a load balancer, whereas the next hop must be the global address, not a link local address.

This issue is fixed in Cumulus RMP 3.1.1 — now the link local address no longer appears in the BGP table entry and the next hop is set to the globally-defined address.


RN-476 (CM-12820)
switchd ignores neighbor table netlink messages

The issue occurs because the kernel neighbor table gets out of sync with the neighbor table in the hardware.

This issue is fixed in Cumulus RMP 3.1.1.


RN-481 (CM-12798)
ifupdown2 error when bridge subinterface has both IPv4 and IPv6 addresses

When an interface has both IPv4 and IPv6 addresses, executing ifreload -a causes errors like the following to be displayed for both subinterfaces:

cumulus@switch:~$ sudo ifreload -a
error: bridge.200: cmd 'ip -force -batch - [addr add 10.50.103.193/26 dev bridge.200
addr add 2a01:75e0:0000:09b1::1/64 dev bridge.200
]' failed: returned 1 (RTNETLINK answers: File exists
Command failed -:1
)
error: bridge.100: cmd 'ip -force -batch - [addr add 10.50.103.129/26 dev bridge.100
addr add 2a01:75e0:0000:09b0::1/64 dev bridge.100
]' failed: returned 1 (RTNETLINK answers: File exists
Command failed -:1
)

This issue is fixed in Cumulus RMP 3.1.1.

Known Issues in Cumulus RMP 3.1.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-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 16 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-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-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-454 (CM-12370)
An interface cannot have both inet and inet6 DHCP configurations

If you configure an interface so it can to obtain both IPv4 and IPv6 IP addresses via DHCP, ifupdown2 will honor only the first configuration and ignore the second.

In the following example configuration, ifupdown2 will only issue an IPv4 DHCP address for swp1, but not the IPv6 address.

auto swp1
iface swp1 inet dhcp
    link-speed 10000
    link-duplex full
    link-autoneg off

auto swp1
iface swp1 inet6 dhcp

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


RN-447 (CM-11280)
"portwd: invalid SFF identifier: 0x0c" messages appear continuously in syslog

The following SFF message appears every 5 seconds in syslog:

cumulus@switch:~$ tail -f /var/log/syslog 
2016-08-06T12:18:56.095606-04:00 cumulus portwd: invalid SFF identifier: 0x0c
2016-08-06T12:19:01.113397-04:00 cumulus portwd: invalid SFF identifier: 0x0c
2016-08-06T12:19:01.121068-04:00 cumulus portwd: invalid SFF identifier: 0x0c
2016-08-06T12:19:01.121698-04:00 cumulus portwd: invalid SFF identifier: 0x0c
2016-08-06T12:19:06.139373-04:00 cumulus portwd: invalid SFF identifier: 0x0c
2016-08-06T12:19:06.147045-04:00 cumulus portwd: invalid SFF identifier: 0x0c
2016-08-06T12:19:06.147677-04:00 cumulus portwd: invalid SFF identifier: 0x0c
2016-08-06T12:19:11.165355-04:00 cumulus portwd: invalid SFF identifier: 0x0c
2016-08-06T12:19:11.173134-04:00 cumulus portwd: invalid SFF identifier: 0x0c
2016-08-06T12:19:11.173747-04:00 cumulus portwd: invalid SFF identifier: 0x0c
2016-08-06T12:19:16.191418-04:00 cumulus portwd: invalid SFF identifier: 0x0c
2016-08-06T12:19:16.199154-04:00 cumulus portwd: invalid SFF identifier: 0x0c
2016-08-06T12:19:16.199805-04:00 cumulus portwd: invalid SFF identifier: 0x0c

This is a known issue that should be fixed in a future version of Cumulus RMP.


RN-449 (CM-11584)
In traditional bridge mode, clagd syncs MAC addresses in the wrong VLAN when the peerlink is tagged and the bond is native

When a traditional mode bridge is configured and the peerlink is tagged but the clagd bonds are native VLANs, clagd appears to try and sync the MAC addresses learned using the VLAN tag from the peerlink.

This causes the MAC address not to be synced correctly on the peer.

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


RN-453 (CM-12564)
Default routes learned via DHCP are moved to the management VRF even if they are not in the management VRF

The mgmt-vrf package has a dhclient exit hook that incorrectly assumes that DHCP is used only with the management interface. If management VRF is enabled, it inserts default routes from the DHCP server into the management table.

Until this issue is resolved, do not use DHCP with the front panel (switch) ports.


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