Cumulus VX is a community-supported virtual appliance that enables cloud admins and network engineers to preview and test Cumulus Networks technology at zero cost. You can build sandbox environments to learn open networking concepts, prototype network operations and script & develop applications risk-free. With Cumulus VX, you can get started with open networking at your pace, on your time, and in your environment!
These release notes support Cumulus VX 2.5.3 and describe its features and known issues.
Stay up to date: Click Follow above so you can receive a notification when we update these release notes.
Cumulus VX Features
- Integrates with KVM, VirtualBox and VMware hypervisors
- Runs within GNS3 and Vagrant environments
- VM is a 64-bit operating system based on Cumulus Linux 2.5.3
Downloading Cumulus VX
You can download any of the of the four Cumulus VX images:
- An OVA disk image for use with VirtualBox.
- A VMware-specific OVA disk image.
- A qcow2 disk image for use with KVM.
- A Box image for use with Vagrant.
Keep in mind the following issues when you are running your Cumulus VX virtual machine.
Enabling SNMP in Quagga
There is no SNMP support for Quagga in Cumulus VX (see RN 88 below). Due to this circumstance, you must remove all references to
smux in each of the following configuration files. If the
smux entries are present in the configuration files, the daemons in the 2.5 packaged version of Quagga will not start.
grep smux *
- Delete all lines in the config files containing the smux keyword.
The references to
smux that must be removed are:
bgpd.conf, remove this line:
smux peer 184.108.40.206.4.1.33220.127.116.11 quagga_bgpd
ospf6d.conf, remove this line:
smux peer 18.104.22.168.4.1.3322.214.171.124 quagga_ospf6d
ospfd.conf, remove this line:
smux peer 126.96.36.199.4.1.33188.8.131.52 quagga_ospfd
zebra.conf, remove this line:
smux peer 184.108.40.206.4.1.33220.127.116.11 quagga_zebra
Perl, Python and BDB Modules
Any Perl scripts that use the
DB_File module or Python scripts that use the
bsddb module won't run under Cumulus VX.
You can read the technical documentation here.
If you have any questions or feedback about Cumulus VX, visit the Cumulus VX community for further support.
Known Issues in Cumulus VX
Issues are categorized for easy review. Some issues are fixed but will be available in a later release.
|Release Note ID||Summary||Description|
|RN-4 (FR-53)||ifup/ifdown must be used for interfaces with IPv6 addresses defined in
||Two scenarios are shown below; one with ifup/ifdown, the other with ifconfig down.
swp1 Link encap:Ethernet HWaddr 44:38:39:00:01:81 inet addr:18.104.22.168 Bcast:22.214.171.124 Mask:255.255.255.0 inet6 addr: fe80::4638:39ff:fe00:181/64 Scope:Link inet6 addr: fec0:1000:1000:1000::2/10 Scope:Site UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:4231 errors:0 dropped:0 overruns:0 frame:0 TX packets:4342 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:412115 (402.4 KiB) TX bytes:425688 (415.7 KiB)
With ifconfig down:
sudo ifconfig swp1 swp1 Link encap:Ethernet HWaddr 44:38:39:00:01:81 inet addr:126.96.36.199 Bcast:188.8.131.52 Mask:255.255.255.0 inet6 addr: fe80::4638:39ff:fe00:181/64 Scope:Link inet6 addr: fec0:1000:1000:1000::2/10 Scope:Site UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:98 errors:0 dropped:0 overruns:0 frame:0 TX packets:111 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:13310 (12.9 KiB) TX bytes:12786 (12.4 KiB)
|RN-52 (CM-997, CM-1013)||Parameters like the router ID and DR priority cannot be changed while OSPFv2/v3 is running||Router ID and DR priority can only be changed by shutting down OSPFv2/v3, changing the ID, and restarting the OSPF process.
A change to the DR priority may not properly be reflected in the LSAs that are still aging out.
|RN-56 (CM-343)||IPv4/IPv6 forwarding disabled mode not recognized||
If either of the following is configured:
net.ipv4.ip_forward == 0
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-61 (CM-1004)||BGP4 notifications missing for several conditions||In certain conditions, Quagga
Ideally on any one of these cases,
General functionality of BGP4 is not affected.
|RN-64 (CM-1153)||Configuring route-reflector-client requires specific order||In configuring a route to be a route reflector client, the Quagga configuration must be specified in a specific order; otherwise, the router will not be a route reflector client.
The "neighbor <IPv4/IPV6> route-reflector-client" command must be done after the "neighbor <IPV4/IPV6> Activate" command; otherwise, the route-reflector-client command is ignored.
router bgp 65000 bgp router-id 0.0.0.4 bgp log-neighbor-changes no bgp default ipv4-unicast bgp cluster-id 0.0.0.4 bgp bestpath as-path multipath-relax redistribute connected neighbor 184.108.40.206 remote-as 65000 neighbor 220.127.116.11 route-reflector-client neighbor 18.104.22.168 activate neighbor 22.214.171.124 next-hop-self neighbor 126.96.36.199 remote-as 65000 neighbor 188.8.131.52 activate neighbor 184.108.40.206 next-hop-self neighbor 2001:ded:beef::1 remote-as 65000 neighbor 2001:ded:beef:2::1 remote-as 65000 maximum-paths 4 maximum-paths ibgp 4 ! address-family ipv6 redistribute connected neighbor 2001:ded:beef::1 activate neighbor 2001:ded:beef::1 next-hop-self neighbor 2001:ded:beef:2::1 route-reflector-client neighbor 2001:ded:beef:2::1 activate neighbor 2001:ded:beef:2::1 next-hop-self maximum-paths 4 maximum-paths ibgp 4 exit-address-family
cumulus@switch:$ show ip bgp neighbor 220.127.116.11 BGP neighbor is 18.104.22.168, remote AS 65000, local AS 65000, internal link BGP version 4, remote router ID 0.0.0.6 BGP state = Established, up for 00:23:49 Last read 23:31:36, hold time is 180, keepalive interval is 60 seconds Neighbor capabilities: 4 Byte AS: advertised and received Route refresh: advertised and received(old & new) Address family IPv4 Unicast: advertised and received Message statistics: Inq depth is 0 Outq depth is 0 Sent Rcvd Opens: 2 0 Notifications: 0 0 Updates: 1 1 Keepalives: 25 24 Route Refresh: 0 0 Capability: 0 0 Total: 28 25 Minimum time between advertisement runs is 5 seconds For address family: IPv4 Unicast >>>>>>>>>>>>>>>>>>>>>> ROUTE REFLECTOR CLIENT NOT DISPLAYED NEXT_HOP is always this router Community attribute sent to this neighbor(both) 6 accepted prefixes Connections established 1; dropped 0 Last reset never Local host: 22.214.171.124, Local port: 179 Foreign host: 126.96.36.199, Foreign port: 40290 Nexthop: 188.8.131.52 Nexthop global: 2001:ded:beef::2 Nexthop local: fe80::202:ff:fe00:4 BGP connection: non shared network Read thread: on Write thread: off cumulus@switch:$
Define in following order address-family ipv4 unicast neighbor 184.108.40.206 activate neighbor 220.127.116.11 next-hop-self neighbor 18.104.22.168 route-reflector-client >>> Must be after Activate exit-address-family neighbor 2001:ded:beef:2::1 remote-as 65000 address-family ipv6 unicast redistribute connected maximum-paths 4 maximum-paths ibgp 4 neighbor 2001:ded:beef:2::1 activate neighbor 2001:ded:beef:2::1 next-hop-self neighbor 2001:ded:beef:2::1 route-reflector-client >>> Must be after activate exit-address-family Runtime status after change:
|RN-68 (CM-923)||Blackhole/Unreachable/Prohibit route addition in IPv6 returns corresponding error codes||IPv6 route operations indicate the destination action via returned error codes. In the example shown below where an unreachable route is being added, the return code is:
#define ENETUNREACH 101 /* Network is unreachable */
|RN-70 (CM-1166)||ACL: Bridge traffic that matches a LOG ACTION rule is not logged in syslog||For example, a bridge with switch ports swp1, swp2, swp3 as bridge members is configured. ACL rules to LOG and DROP for icmp traffic are configured.
Ping requests are sent from host1 on swp1 to host3 on swp3, and the following was observed:
* Counters for both LOG and DROP ACL rules are incrementing properly, but the packets are not showing up on /var/log/syslog.
* Packets that are copied to the CPU from hardware for the LOG rule are dropped due to the check in kernel to disable software bridging for hardware bridged packets.
|RN-88 (CM-1200)||SNMP support for Quagga is NOT provided in Cumulus VX||Cumulus VX does not provide SNMP support for Quagga.|
|RN-125 (CM-1576)||Network LSA with an old router ID isn't flushed out by the originator||When the router ID is changed, the router should remove the previous network LSA (link-state advertisement) that it generated based on the IP address on the interface in the Network LSA.
Cumulus Networks doesn't remove this LSA, so it will be naturally aged out.
|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 VX cannot exceed 15 characters||
Device names, including interface names, in Cumulus VX cannot exceed 16 characters – including the terminator. Cumulus VX 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-163 (CM-2499)||VXLAN: ovsdb-server cannot select loopback interface as source IP address, causing TOR registration to the controller to fail||
In a VXLAN using VMware NSX, ovsdb-server cannot select the loopback interface as the source IP address. This causes TOR registration to the controller to fail.
To work around this issue, run:
cl-bgp redistribute add connected
PTM may crash when a large topology file has a syntax error
If there is a syntax error in a large (~ 4000 entries)
|RN-196 (CM-2499)||For a VXLAN in NSX,
As a result, the TOR registration to the controller fails.
To work around this issue, run:
cl-bgp redistribute add connected
|RN-199 (CM-2624)||When a Quagga route-map is modified, the switch could use the partial map before edits are completed||
Cumulus VX triggers a
Cumulus Networks is working to fix this issue.
|RN-210 (CM-3716)||Restarting or clearing BGP can lead to SYN flooding warning, triggering an unnecessary alarm||
When you run
179 dynamic neighbor(s), limit 90 switch07# clear bgp * switch07#TCP: Possible SYN flooding on port 179. / Sending cookies. Check SNMP counters.
The warning also appears in
Sep 18 17:27:40 switch07 kernel: TCP: Possible SYN flooding on port 179. / Sending cookies. Check SNMP counters.
This issue is caused by the maximum number of socket connections that are accepted on a listening socket is reached.
You can safely ignore this warning. Or to silence, it, you can increase the number of socket connections by changing the value for
|RN-217 (CM-4207)||LNV: Network restart removes
Given the following conditions:
When you restart networking (with service networking restart), the anycast IP address gets removed from the loopback interface.
To prevent this issue from occurring, you should specify an anycast IP address for the loopback interface in both
|RN-221 (CM-4501)||BGP graceful restart, including helper mode, not fully supported||If you encounter issues with this, please submit a support request and include the output from
|RN-227 (CM-3388)||BGP dynamic capability is not supported||BGP peer sessions with dynamic capability are not supported under by Cumulus VX at this time.|
One effect is that since
|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.|
This issue should be fixed in a future version of Cumulus VX.
|RN-275 (CM-5794)||BGP import-check fails for IPv6 route if static routes to null0 are used||
The path that Cumulus VX originates should not be invalid since there is a matching route in the RIB. The import check works fine for IPv4 routes.
|RN-276 (CM-5754)||MLAG peer is alive on one switch but is not alive on its peer switch||
One MLAG node can ping its peer switch, but the peer cannot do so. You can see this when you run
cumulus@switch3:~$ sudo clagctl The peer is not alive Our Priority, ID, and Role: 32768 00:e0:ec:25:2f:83 primary Peer Interface and IP: peerlink.4000 22.214.171.124 Backup IP: 126.96.36.199 (active) System MAC: 00:00:00:03:12:01 cumulus@switch4:~$ sudo clagctl The peer is alive Peer Priority, ID, and Role: 32768 00:e0:ec:25:2f:83 primary Our Priority, ID, and Role: 32768 44:38:39:00:1e:82 secondary Peer Interface and IP: peerlink.4000 188.8.131.52 Backup IP: 184.108.40.206 (active) System MAC: 00:00:00:03:12:01
To work around this issue, you can do one of two things:
|RN-278 (CM-6048)||Setting new metric value with BGP redistribute command does not take effect||
If you configure a new metric value using the BGP
cumulus@switch:~$ sudo service quagga restart bgpd
cumulus@switch:~$ sudo service quagga restart
|RN-279 (CM-6012)||STP not supported on bonds in LACP bypass all-active mode||
Cumulus VX does not support STP on bonds in LACP bypass all active mode. To avoid this issue, enable STP BPDU guard for all bonds in LACP bypass all-active mode. For information, read this document.
|RN-281 (CM-5118)||Default route not removed on
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
To work around this issue, first run
|RN-297 (CM-6801)||"Unable to determine platform" error seen in Cumulus VX||
Cumulus VX does not report a platform (as reported by the platform-detect command), so some commands will not execute correctly. This renders dependent packages, such as update-grub, unusable.
cumulus@switch:~$ sudo platform-detect ERROR: Unable to determine platform for ARCH: x86_64 UNKNOWN cumulus@switch:~$ sudo update-grub Generating grub.cfg ... /etc/grub.d/10_cumulus: 27: /etc/cumulus/init/platform.conf: log_failure_msg: not found
|RN-298 (CM-6169)||Cannot start
If you are configuring MLAG, in order to start the
auto peer16.4000 iface peer16.4000 inet static address 220.127.116.11 netmask 255.255.255.0 clagd-enable yes clagd-peer-ip 18.104.22.168 clagd-sys-mac 44:38:39:ff:ff:ff clagd-args --vm