Release Notes for Cumulus Linux 1.5.0-Final

Follow

Overview

These release notes support Cumulus Linux 1.5.0 Final. These release notes describe currently available features and known issues.

Licensing

Cumulus Linux is licensed on a per instance basis. Each network system is fully operational, enabling any capability to be utilized on the switch with the exception of forwarding on switch panel ports. Only eth0, and console ports are activated on an un-licensed instance of Cumulus Linux. Enabling front panel ports requires a license.

You should have received a license key from Cumulus Networks or an authorized reseller. There are two ways to instal this file onto the system:

  • Copy and paste the license key into the cl-license command:
    root@switch: cl-license -i
    <paste file>

    Note: This command used to be known as cl-license-install.

  • Copying it from a local server:

    First ensure a text file with the license is created on an accessible server from the switch. On the switch, use the following command to transfer the file directly on the switch. Then you can install the license file.
    root@switch: scp user@my_server:/home/user/my_license_file.txt . 

Once the license is installed successfully, the system must be rebooted.

root@switch: reboot

Once rebooted, all front panel ports will be active. The front panel ports are identified as switch ports, and show up as swp1, swp2, etc.

Viewing these ports, and utilizing these ports is the same as any other Linux NIC. Hence commands such as

ip link show -> will show all active ports on the switch

ip addr add 10.0.1.200/24 dev swp6 -> will add an address to switch port 6.

https://cumulusnetworks.zendesk.com/entries/24125536-Installing-a-License

Documentation

You can read the technical documentation here.

Features Supported

Networking L2/L3 Features

Feature Notes
LLDP/CDP (both rx/tx) patched lldpd
Rapid STP supported via mstpd
Link Aggregation support provided via the linux bonding driver
Bridging supported via brctl command in linux
STP supported via brctl
v4/v6 DHCP relay via isc-dhcp-relay
v6 Neighbor Discovery  
VLAN 802.1q trunk  
ECMP  
OSPFv2 part of Quagga
OSPFv3 part of Quagga
v4/v6 Static Routes part of Quagga
BGP v4/v6 part of Quagga
Prescriptive Topology Manager Cumulus specific user space applications which allows the fabric topology to be verified prior to configuring L3 routing protocols

Security

Feature Notes
ACL (data plane and control plane) Support provided via the netfilter framework, iptables, ebtables, and ip6tables with a wrapper command called cl-acltool - for setting iptables and ebtable commands in kernel and in HW
BPDU Guard  

 

Management Authentication/Authorization

Feature Notes
SSH  
NTP  
PTP  

 

Data Path Specific

Feature Notes
Jumbo MTU  
Egress scheduling Deficit Weighted Round Robin (DWRR) + strict priority, which provides strict priority for some priorities and dwrr for the rest
Traffic classes/queuing Classification provided via ACLs, and for 802.1p currently - DSCP based classification provided in later release.

Management Interface/Trouble Shooting/Monitoring

Feature Notes
bash based wrapper for Quagga's vtysh available in /usr/bin as cl-ospf and cl-ospfv6
Scripting: Bash, Perl, Python, ruby debian packages in img.
Ping & traceroute  
syslog, rsyslog  
logrotate  
auditd  
SCP  
SNMP v2 (via Net-SNMP) untested
monit Monit tested & preconfigured in the image

 

Known Issues in Cumulus Linux 1.5.0-Final

Issues are categorized for easy review. Some issues are fixed but will be available in a later release. Future fixed issues are noted in the "fixed release"  column with the branch name the fix will be available in.

If the "fixed release" is "mainline", this means the fix is in Cumulus Linux's internal mainline branch, but not yet allocated to a customer branch/release.

Key Summary Description affectedTag fixedTag Feature Category
RN-78 Ensure configurations are backedup in /mtn/persist prior to upgrades Cumulus Linux provides a way to ensure your configurations are persistent across upgrades. All files needs to be copied into /mnt/persist in order to ensure they are persistent across upgrades. 

Check out article at https://cumulusnetworks.zendesk.com/entries/24914812-Copying-configurations-across-switches for more information.
CumulusLinux-1.5.0-Final   Configuration Management
RN-1 restarting switchd flaps all switchports switchd is a user level process created by cumulus to provide an abstraction of the physical ports and the functionality provided by the switching ASIC sdk. Switchd maps physical ports on the switching ASIC to logical ports (tap ports) in the kernel and ensures that CPU bound packets are properly exposed on the proper logical objects to user level processes. 

These exposed tap ports in the kernel are considered "running" if their file descriptors are open. If switchd exists, its closes the tap fds, hence resulting in all links going down.
CumulusLinux-1.5.0-Final   Hardware Abstraction Layer
RN-32 Adding bridges will increase boot up time If the "bridge_maxwait" parameter is not set, the system will take approximately 2x forwarding delay to bring the system up. 

Its best to set the "bridge_maxwait" to 1. 

e.g. CFG 
auto br1004 
iface br1004 inet static 
address 14.0.0.37 
netmask 255.255.0.0 
bridge_ports regex (swp[1|6|7|8].1004) 
bridge_stp on 
bridge_bridgeprio 32768 
bridge_maxwait 1 
bridge_ageing 200 
bridge_fd 30 
down ip addr flush dev br1004
CumulusLinux-1.5.0-Final   Layer 2 (Control Protocols)
RN-72 LLDP Refresh time should not be set below a specific amount otherwise entries will be deleted before the timer expires lldp settings for hold and interval should be: 

root@dni-7448-31:~# cat /etc/lldpd.conf 
configure lldp tx-interval 1 
configure lldp tx-hold 4 
root@dni-7448-31:~# 

If these are set to below 1 and 4 respectively, entries will be deleted before the timer expires. 

root@sw1:~# lldpcli show neighbors hidden details -f keyvalue | grep via=LLDP 
lldp.swp4.via=LLDP <<< Entries are removed 


Following are the expected entries. 

root@sw1:~# lldpcli show neighbors hidden details -f keyvalue | grep via=LLDP 
lldp.swp1.via=LLDP 
lldp.swp2.via=LLDP 
lldp.swp3.via=LLDP 
lldp.swp4.via=LLDP 
lldp.swp5.via=LLDP 
lldp.swp6.via=LLDP 
lldp.swp7.via=LLDP 

If you want the neighbor to retain your port you should always have txTTL > txInterval.
CumulusLinux-1.5.0-Final   Layer 2 (Control Protocols)
RN-71 SPAN: cannot match an output L3 sub-interface Mirroring packets from one switch port to another works

-A FORWARD --out-interface swp1 -j SPAN --dport swp5 

As does mirroring in-bound packets on a VLAN to a switch port 

-A FORWARD --in-interface swp1.100 -j SPAN --dport swp5 

However mirroring out-bound packets from a VLAN to a switch port does not work 

-A FORWARD --out-interface swp1.100 -j SPAN --dport swp5 

Summary: 
matching output L3 main interface works fine. 
matching input L3 sub-interface works fine. 
matching output L3 sub-interface does not work.
CumulusLinux-1.5.0-Final   Layer 2 (Segmentation)
RN-80 Old link local IPv6 and MAC address are still used after the MAC address for a bridge changes Old MAC addresses for a bridge using the associated link local IPv6 address are used in the L2 and L3 headers in a Router Advertisement after the port is removed from the bridge. 

How this is seen: 
1. configure a bridge, br0, with swp1-4 in it. 
2. remove swp1 from br0 with the command "brctl delif br0 swp1" 
3. run a TCPDump session on swp2. 

The TCPDump session reviles that the old MAC address, swp1's MAC address, and link local address are still being advertised. Here is a packet from my capture: 
19:41:15.041412 44:38:39:00:01:81 > 33:33:00:00:00:01, ethertype IPv6 (0x86dd), length 78: (hlim 255, next-header ICMPv6 (58) payload length: 24) fe80::4638:39ff:fe00:181 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 24 
hop limit 64, Flags [none], pref medium, router lifetime 15s, reachable time 0s, retrans time 0s 
source link-address option (1), length 8 (1): 44:38:39:00:01:82 
0x0000: 4438 3900 0182 

MAC 44:38:39:00:01:81 was the old MAC address for bridge br0 that was associated with swp1. 
fe80::4638:39ff:fe00:181 is the link local address for swp1.
CumulusLinux-1.5.0-Final   Layer 2 (Segmentation)
RN-12 The switch's forwarding of VLAN Tagged packets is different from Linux In Cumulus Linux, if tagged packets are sent to a untagged port, they are dropped. This is similar to general switch functionality from most vendors. However in Linux, if a tagged packet is sent to a untagged port, it will be forwarded. CumulusLinux-1.5.0-Final   Layer 2 (Segmentation)
RN-68 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 */ 


sudo ip addr add 9000:1000:1000:1000::1/80 dev lo 
cumulus@dni-7448-13$ sudo ip -6 route 
unreachable 9000:1000:1000:1000::/80 dev lo proto kernel metric 256 error -101
CumulusLinux-1.5.0-Final   Layer 3 (Forwarding)
RN-58 IPv6 route is installed and active in the routing table when the associated interface is down If a IPv6 address is assigned to an "down" interface the associated route is still installed into the route table. 

Also, it didn't matter what type of IPv6 address: Link Local, Site Local, or Global, they all exhibit the same problem. 

If the interface is bounced up and down, then the routes are no longer in the route table.
CumulusLinux-1.5.0-Final   Layer 3 (Forwarding)
RN-47 IP route append not supported causing no support for unnumbered interfaces if the ip route append is used, routes will be appended into the kernel's ip table, but these routes will not show up in the ASIC. 

ip route add 

ip route delete 

Are supported. 

As a subsequent issue, this also means no support for un-numbered interfaces. 

In essence, multiple routes in kernel for an interface will not show up in the ASIC. Only the last route. 

This affects unnumbered interfaces. 

{noformat} 

root@dni-7448-29:~# ifconfig swp7.1007 
swp7.1007 Link encap:Ethernet HWaddr 44:38:39:00:27:a5 
inet addr:11.0.2.115 Bcast:11.0.2.127 Mask:255.255.255.240 
inet6 addr: fe80::4638:39ff:fe00:27a5/64 Scope:Link 
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 
RX packets:0 errors:0 dropped:0 overruns:0 frame:0 
TX packets:1 errors:0 dropped:0 overruns:0 carrier:0 
collisions:0 txqueuelen:0 
RX bytes:0 (0.0 B) TX bytes:90 (90.0 B) 

root@dni-7448-29:~# ifconfig swp8.1007 
swp8.1007 Link encap:Ethernet HWaddr 44:38:39:00:27:a6 
inet addr:11.0.2.115 Bcast:11.0.2.127 Mask:255.255.255.240 
inet6 addr: fe80::4638:39ff:fe00:27a6/64 Scope:Link 
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 
RX packets:0 errors:0 dropped:0 overruns:0 frame:0 
TX packets:1 errors:0 dropped:0 overruns:0 carrier:0 
collisions:0 txqueuelen:0 
RX bytes:0 (0.0 B) TX bytes:90 (90.0 B) 

root@dni-7448-29:~# ip route show table all | grep \.115 
11.0.2.112/28 dev swp7.1007 proto kernel scope link src 11.0.2.115 
11.0.2.112/28 dev swp8.1007 proto kernel scope link src 11.0.2.115 

{noformat}
CumulusLinux-1.5.0-Final   Layer 3 (Forwarding)
RN-31 IP packets with illegal source addresses are forwarded IP packets will the illegal source addresses of 127.0.0.1, 255.255.255.255, and the subnet broadcast are now forwarded as if the source addresses were legal. RFC1812 states that packets with these source addresses should not be forwarded. CumulusLinux-1.5.0-Final   Layer 3 (Forwarding)
RN-77 New routes/ECMPs can evict existing/installed Cumulus Linux syncs routes between the kernel and the switching silicon. If the required resource pools in HW fill up, new kernel routes can cause existing routes to move from being fully allocated to beng partially allocated. 

In order to avoid this, routes in the HW should be monitored and kept below the ASIC limits. 

For example, on systems with Trident+, the limits are as follows: 
routes: 16384 <<<< if all routes are ipv4 
long mask routes 256 <<<< i.e., routes with a mask longer than the route mask limit 
route mask limit 64 
host_routes: 8192 
ecmp_nhs: 4044 
ecmp_nhs_per_route: 52 

That translates to about 77 routes with ecmp nhs, if every route has the maximum ecmp nhs. 

Monitoring this in Cumulus Linux is performed via the cl-resource-query command 

root@dni-7448-17:~# cl-resource-query 
hosts : 3 
all routes : 29 
IP4 routes : 17 
IP6 routes : 12 
nexthops : 3 
ecmp_groups : 0 
ecmp_nexthops : 0 
mac entries : 0 / 131072 
bpdu entries : 500 / 512 

The resource to monitor is the ecmp_nexthops. If this count is close to 4044, new ECMPs may evict existing routes.
CumulusLinux-1.5.0-Final   Layer 3 (Forwarding)
RN-56 ipv4/ipv6 forwarding disabled mode not recognized If: 
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.
CumulusLinux-1.5.0-Final   Layer 3 (Forwarding)
RN-74 BGP: TTL Security hops requires ACL per peer to drop expired TTL BGP packers When configuring TTL security, rules must be put in to drop packets with exceeded TTL on BGL peers. This ensures that when the peers are taken down, the packets are properly discarded. 

As an example of a rule to put in iptables: 

root@dni-7448-11:~# cat /etc/cumulus/acl/policy.d/bgp.rules 
INGRESS_INTF = swp+ 

[iptables] 

-A INPUT --in-interface $INGRESS_INTF -p tcp --dport bgp --src 11.0.0.6 -m ttl --ttl-eq 253 -j POLICE --set-mode pkt --set-rate 2000 --set-burst 1000 --set-class 7
CumulusLinux-1.5.0-Final   Layer 3 (Routing)
RN-63 BGP4 Recursive Route not supported Quagga's bpgd does not support recursive routing when its resolving BGP routes. It does work with respect to IGP routes. 

As an example: 
A BGP route of the form 
R1 -> N1 
where the best match for N1 is also a BGP route: 
N1/24 -> N2 
(and N2 gets resolved through IGP or directly connected) - 
will not get resolved. 

Quagga's Zebra specifically does not allow for such type of routes. The Zebra route path resolution algorithm needs to be fixed. 


Although, Cumulus Linux's version of Quagga - 0.99.21 has errors in recursive routing, the community is actively trying to fix it and patches are being tested in 0.99.22
CumulusLinux-1.5.0-Final   Layer 3 (Routing)
RN-41 Route Summarization acts differently in OSPFv3 vs. OSPFv2 In OSPFv2, regardless of the order of the routes, the longer prefix is always chosen: 
area 0.0.0.0 range 11.0.0.0/16 
area 0.0.0.0 range 11.0.0.0/8 

In this case, 11.0.0.0/16 is always used regardless of the input order. 

In OSPFv3, this is not always the case. Different results occur depending on the order routes are entered.

In the following case we get the longest match: 
area 0.0.0.0 range 2000:1000::/32 
area 0.0.0.0 range 2000::/16 

However, if we do it in the reverse order of: 
area 0.0.0.0 range 2000::/16 
area 0.0.0.0 range 2000:1000::/32 

We get both summarizations.
CumulusLinux-1.5.0-Final   Layer 3 (Routing)
RN-59 BGP should set the correct next-hop based on address-family of NLRIs being advertised. Currently BGP will utilize the IPv4 next hop address for both IPv4 and IPv6 NLRIs 

In essence, for each set of NLRIs, the next hop address should be picked up based on the peering specifics - i.e. if interface peering, pick the v4 or v6 next-hop of the interface; if loopback peering (or update-source), pick the v4 or v6 next-hop of the loopback. 

This should also work if an outbound route map is configured with the statement "set ip next-hop peer-address".
CumulusLinux-1.5.0-Final   Layer 3 (Routing)
RN-61 BGP4 Notifications missing for several conditions In certain conditions, Quagga BGPd silently closes the peering without sending a notification. For example, if BGP receives a message with invalid message type, or invalid message length. 

Ideally on any one of these cases, bgpd should send out a NOTIFICATION message to the peer. 

General functionality of BGP4 is NOT AFFECTED.
CumulusLinux-1.5.0-Final   Layer 3 (Routing)
RN-53 In OSPFv3, a new Router LSA may not be generated if he neighbor advertises a Router LSA with a different Interface ID. If the neighboring router has the interface ID change in the Hello message, Cumulus Linux (Quagga) will not generate a update LSA. CumulusLinux-1.5.0-Final   Layer 3 (Routing)
RN-62 Attributes of a BGP aggregate route may not be RFC-compliant When BGP is configured with an aggregate route and there are more specific routes of that aggregate, the BGP speaker needs to analyze the attributes of those specific routes while forming the attributes of the aggregate route. The corresponding rules are defined in RFC 4271, Sect. 9.2.2.2. 

In certain cases, the user may observe non-compliant attribute formation for the aggregate route: for example, incorrect MED and ORIGIN attributes.
CumulusLinux-1.5.0-Final   Layer 3 (Routing)
RN-64 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. 

"neighbor <IPv4/IPV6> route-reflector-client" command MUST BE AFTER the "neighbor <IPV4/IPV6> Activate" command, otherwise the route-reflector-client command is ignored. 

SAMPLE CONFIG: 

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 14.0.0.1 remote-as 65000 
neighbor 14.0.0.1 route-reflector-client 
neighbor 14.0.0.1 activate 
neighbor 14.0.0.1 next-hop-self 
neighbor 14.0.0.9 remote-as 65000 
neighbor 14.0.0.9 activate 
neighbor 14.0.0.9 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 

AT RUNTIME: 

sp1# show ip bgp neighbor 14.0.0.1 
BGP neighbor is 14.0.0.1, 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: 14.0.0.2, Local port: 179 
Foreign host: 14.0.0.1, Foreign port: 40290 
Nexthop: 14.0.0.2 
Nexthop global: 2001:ded:beef::2 
Nexthop local: fe80::202:ff:fe00:4 
BGP connection: non shared network 
Read thread: on Write thread: off 

sp1# 


WORKAROUND: 
~~~~~~~~~~~ 

Define in following order 
address-family ipv4 unicast 
neighbor 14.0.0.9 activate 
neighbor 14.0.0.9 next-hop-self 
neighbor 14.0.0.9 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 

Run time status after change: 
sp1# show ip bgp neighbors 14.0.0.9 
BGP neighbor is 14.0.0.9, remote AS 65000, local AS 65000, internal link 
BGP version 4, remote router ID 0.0.0.7 
BGP state = Established, up for 00:13:59 
Last read 22:35:13, 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: 1 1 
Notifications: 0 0 
Updates: 2 1 
Keepalives: 15 14 
Route Refresh: 0 0 
Capability: 0 0 
Total: 18 16 
Minimum time between advertisement runs is 5 seconds 

For address family: IPv4 Unicast 
Route-Reflector Client >>>>>>>>>> PLEASE NOTE ME 
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: 14.0.0.10, Local port: 38813 
Foreign host: 14.0.0.9, Foreign port: 179 
Nexthop: 14.0.0.10 
Nexthop global: 2001:ded:beef:2::2 
Nexthop local: fe80::202:ff:fe00:6 
BGP connection: non shared network 
Read thread: on Write thread: off 

sp1#
CumulusLinux-1.5.0-Final   Layer 3 (Routing)
RN-65 Virtual Links in Quagga's OSPFv2 is non-operational Virtual Link support in Quagga's OSPFv2 has too many issues when run in Cumulus Network's testing. The feature is unsupported. CumulusLinux-1.5.0-Final   Layer 3 (Routing)
RN-52 Parameters like the router ID and DR priority cannot be changed while OSPFv2/3 is running Router ID and DR priority can only be changed by shutting down OSPFv2/3, changing the ID, and restarting the OSPF process. 

DR priority if also changed may not properly reflect in LSAs that are still aging out.
CumulusLinux-1.5.0-Final   Layer 3 (Routing)
RN-48 Agema 48x10GE switch eth0 driver reports eth0 RUNNING even when phy link is down The Agema 48x10GE eth0 driver reports eth0 RUNNING even when phy link is down. 

This can be really misleading in trying to diagnose a link-down situation on eth0. ethtool eth0 shows the correct phy link status, but ifconfig show eth0 RUNNING, regardless of phy link status. 

Fix will be post Cumulus Linux 1.5
CumulusLinux-1.5.0-Final   Management Interface
RN-60 Interface bring up errors occur during network restart If the /etc/network/interfaces file uses vlan_raw_device command as part of a vlan interface definition, errors during network bring up (service network restart) or reboot, will be seen. These errors should be ignored. (more below) 

For instance, if the /etc/network/interfaces file has: 

auto swp1.1001 
iface swp1.1001 inet static 
address 11.0.1.81 
netmask 255.255.255.240 
vlan_raw_device swp1 
up vconfig set_egress_map swp1.1001 0 1 
down ip addr flush dev swp1.1001 


Then while network restart occurs (or reboot) - the following error is seen: 
------------------------------ 
Set name-type for VLAN subsystem. Should be visible in /proc/net/vlan/config 
ERROR: trying to add VLAN #1001 to IF -:swp1:- error: File exists <<IGNORE THIS ERROR 
Set egress mapping on device -:swp1.1001:- Should be visible in /proc/net/vlan/swp1.1001 

Essentially, iface swp1.1001 inet static brings the interface up, and vlan_raw_device also tries to bring it up (via vconfig), even though its already up. Hence the error. 

This error also occurs if the interface is a bonding interface.
CumulusLinux-1.5.0-Final   Management Interface
RN-4 ifup/ifdown should be used for interfaces with v6 addresses defined in /etc/network/interfaces, otherwise the v6 interface will go down Two scenarios shown below. one with ifup/ifdown, the other with ifconfig down 

With ifup/ifdown 

{noformat} 

swp1 Link encap:Ethernet HWaddr 44:38:39:00:01:81 
inet addr:11.0.0.2 Bcast:11.0.0.255 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) 

cumulus@dni-7448-13$ sudo ifdown swp1 
cumulus@dni-7448-13$ sudo ifconfig swp1 
swp1 Link encap:Ethernet HWaddr 44:38:39:00:01:81 
BROADCAST MULTICAST MTU:1500 Metric:1 
RX packets:4248 errors:0 dropped:0 overruns:0 frame:0
TX packets:4356 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500 
RX bytes:413990 (404.2 KiB) TX bytes:427074 (417.0 KiB) 

cumulus@dni-7448-13$ sudo ifconfig swp1 
swp1 Link encap:Ethernet HWaddr 44:38:39:00:01:81 
BROADCAST MULTICAST MTU:1500 Metric:1 
RX packets:4248 errors:0 dropped:0 overruns:0 frame:0
TX packets:4356 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500 
RX bytes:413990 (404.2 KiB) TX bytes:427074 (417.0 KiB) 

cumulus@dni-7448-13$ sudo ifup swp1 
ADDRCONF(NETDEV_UP): swp1: link is not ready 
cumulus@dni-7448-13$ sudo ifconfig swp1ADDRCONF(NETDEV_CHANGE): swp1: link becomes ready 

swp1 Link encap:Ethernet HWaddr 44:38:39:00:01:81 
inet addr:11.0.0.2 Bcast:11.0.0.255 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:4250 errors:0 dropped:0 overruns:0 frame:0
TX packets:4362 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500 
RX bytes:414178 (404.4 KiB) TX bytes:427610 (417.5 KiB) 

cumulus@dni-7448-13$ 

{noformat} 


ifconfig down example - 

{noformat} 

sudo ifconfig swp1 
swp1 Link encap:Ethernet HWaddr 44:38:39:00:01:81 
inet addr:11.0.0.2 Bcast:11.0.0.255 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) 

cumulus@dni-7448-13$ sudo ifconfig swp1 down 
cumulus@dni-7448-13$ sudo ifconfig swp1 
swp1 Link encap:Ethernet HWaddr 44:38:39:00:01:81 
inet addr:11.0.0.2 Bcast:11.0.0.255 Mask:255.255.255.0 
BROADCAST MULTICAST MTU:1500 Metric:1 
RX packets:126 errors:0 dropped:0 overruns:0 frame:0 
TX packets:138 errors:0 dropped:0 overruns:0 carrier:0 
collisions:0 txqueuelen:500 
RX bytes:16998 (16.5 KiB) TX bytes:15998 (15.6 KiB) 

cumulus@dni-7448-13$ sudo ifconfig swp1 up 
ADDRCONF(NETDEV_UP): swp1: link is not ready 
cumulus@dni-7448-13$ sudo ifconfig swp1ADDRCONF(NETDEV_CHANGE): swp1: link becomes ready 

swp1 Link encap:Ethernet HWaddr 44:38:39:00:01:81 
inet addr:11.0.0.2 Bcast:11.0.0.255 Mask:255.255.255.0 
inet6 addr: fe80::4638:39ff:fe00:181/64 Scope:Link 
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 
RX packets:130 errors:0 dropped:0 overruns:0 frame:0 
TX packets:149 errors:0 dropped:0 overruns:0 carrier:0 
collisions:0 txqueuelen:500 
RX bytes:17474 (17.0 KiB) TX bytes:17154 (16.7 KiB) 

{noformat}
CumulusLinux-1.5.0-Final   Management Interface
RN-82 Byte count for ebtables will be off by 4 for untagged packets When a L2 packet matches a rule in ebtables, the byte counter will be off by 4 bytes when an untagged packet was used to cause the match. This is due to the fact that we append a VLAN Tag onto a packet once the packet enters the device. If the packet is VLAN Tagged coming into the device, then the packet count will be correct. CumulusLinux-1.5.0-Final   Security
RN-70 ACL: Bridge traffic which matches a LOG ACTION rule is not logged in syslog Example: 
A bridge with a 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 which are copied to CPU from HW for the LOG rule are dropped due to the check in kernel to disable SW bridging for HW bridged packets.
CumulusLinux-1.5.0-Final   Security
RN-69 Statistics for ACL rules are reset to zero whenever the ACL rules are installed The installation of ACL rules in hardware (using cl-acltool) is done atomically using a ping pong buffer scheme. Thus old counters are lost anytime a rule is changed (added or deleted). Thus, ACL stats for all the rules get zeroed out, irrespective of whether the rules file installation succeeds or fails. 

{noformat} 

root@switch:~# iptables -L -v 
Chain INPUT (policy ACCEPT 291 packets, 20717 bytes) 
pkts bytes target prot opt in out source destination 
300 134K DROP udp -- swp+ any 11.0.0.1 11.0.0.10 udp spt:800 dpt:1000 
0 0 SETCLASS ospf -- swp+ any anywhere anywhere SETCLASS class:3 
1 102 POLICE icmp -- swp+ any anywhere anywhere POLICE class:2 rate:1 burst:4 
0 0 SETCLASS udp -- swp+ any anywhere anywhere udp dpt:bootps SETCLASS class:2 
0 0 SETCLASS udp -- swp+ any anywhere anywhere udp dpt:bootpc SETCLASS class:2 
2 892 POLICE all -- swp+ any anywhere anywhere ADDRTYPE match dst-type IPROUTER POLICE class:2 rate:1 burst:4 

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) 
pkts bytes target prot opt in out source destination 

Chain OUTPUT (policy ACCEPT 242 packets, 37343 bytes) 
pkts bytes target prot opt in out source destination 



root@switch:~# cl-acltool -i -p 00control_plane.rules 
Using user provided rule file 00control_plane.rules 
Reading rule file 00control_plane.rules ... 
Processing rules in file 00control_plane.rules ... 
Installing acl policy... done. 



root@switch:~# iptables -L -v 
Chain INPUT (policy ACCEPT 8 packets, 560 bytes) 
pkts bytes target prot opt in out source destination 
0 0 DROP udp -- swp+ any 11.0.0.1 11.0.0.10 udp spt:800 dpt:1000 
0 0 SETCLASS ospf -- swp+ any anywhere anywhere SETCLASS class:3 
0 0 POLICE icmp -- swp+ any anywhere anywhere POLICE class:2 rate:1 burst:4 
0 0 SETCLASS udp -- swp+ any anywhere anywhere udp dpt:bootps SETCLASS class:2 
0 0 SETCLASS udp -- swp+ any anywhere anywhere udp dpt:bootpc SETCLASS class:2 
0 0 POLICE all -- swp+ any anywhere anywhere ADDRTYPE match dst-type IPROUTER POLICE class:2 rate:1 burst:4 

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) 
pkts bytes target prot opt in out source destination 

Chain OUTPUT (policy ACCEPT 5 packets, 612 bytes) 
pkts bytes target prot opt in out source destination 
root@switch:~# 

{noformat}
CumulusLinux-1.5.0-Final   Security
RN-54 "!" in the "-p" option is not supported for iptables Cumulus Linux doesn't support the following list of options: 
"!" in the "-p" option is not supported
CumulusLinux-1.5.0-Final   Security
RN-81 HW enforcement for bridging packets which are matching both ebtables and iptables/ip6tables rules have different behavior from Linux kernel enforcement Issue 1: 
Behavior for Bridging Packets which are matching both ebtables as well as iptables rules is different from netfilter enforcement for packets matching these tables in Linux kernel. 
Ebtables are always enforced before iptables for bridging packets where as iptables are enforced in case of HW . 

Issue 2: 
Behavior for Bridging Packets which are matching both ebtables as well as ip6tables rule is different from netfilter enforcement for packets matching these tables in Linux kernel. 
Ebtables are always enforced before ip6tables for bridging packets in Linux kernel where as the actions in both these tables (ebtables/ip6tables) for the packet will be tried to be enforced.
CumulusLinux-1.5.0-Final   Security
RN-76 cl-route-check will fail when checking routes against bridges with IP addresses and bonding interfaces If you assign an IP address to a bridge interface, cl-route-check will say that the route for this address wasn't found in the hw tables. Similarly any routes against a bonding interface will fail cl-route-check. 

In addition, cl-route-check is unreliable in the operating mode where multiple front panel ports share a mac address
CumulusLinux-1.5.0-Final   Tools
RN-10 cl-phy-update doesn't support aggregated ports Ports can be aggregated into a larger interface in Cumulus Linux. Unfortunately support for aggregated ports is not yet supported when running cl-phy-update. 

If there are any ganged ports during a SW upgrade it is recommended to ungang these ports
CumulusLinux-1.5.0-Final   Tools
 
RN-313 High memory utilization by snmpd following MIB walks

When performing an MIB walk on Cumulus Linux running the standard NET-SNMP 5.4.3 package, memory is consumed and not returned. Over time, this can lead to sub-optimal performance and ultimately can cause the system to hang and require a reboot.

Monitor snmpd memory utilization using ps aux and system memory utilization with free or cat /proc/meminfo. If required, restart snmpd using service snmpd restart.


RN-372 (CM-9360)
Security Update for CVE-2015-7547: glibc getaddrinfo Stack-based Buffer Overflow Vulnerability For details on this issue and how to upgrade, read this article.
Have more questions? Submit a request

Comments

Powered by Zendesk