Cumulus Linux 2.0.0 Release Notes

Follow

Overview

These release notes support Cumulus Linux 2.0 and 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. To install the license, read the Cumulus Linux quick start guide

Installing Version 2.0.0

Warning: Save Your Configurations Before Installing
This installation is destructive. Any configuration files on the switch will not be saved, so please copy them to a different server before upgrading. After you save your configurations, follow these steps to install Cumulus Linux 2.0: 

To install the software, follow these steps: 

  1. Download Cumulus Linux 2.0.0 - Final Latest Version from the Downloads page of the Cumulus Networks website onto your Web server.
  2. Install Cumulus Linux 2.0.0, following the instructions in the quick start guide.

 

Enabling Quagga

There is no SNMP support for Quagga in this release (see RN 88 below). Due to this circumstance, you must remove all references to smux in each of the following configuration files. You must also remove these references before upgrading Cumulus Linux usingapt-get. If the smux entries are present in the configuration files, the daemons in the 2.0.0 packaged version of Quagga will not start.

  1. cd /etc/quagga
  2. grep smux *
  3. Delete all lines in the config files containing the smux keyword.

The references to smux that must be removed are:

  • In bgpd.conf, remove this line: 
    smux peer 1.3.6.1.4.1.3317.1.2.2 quagga_bgpd
  • In ospf6d.conf, remove this line: 
    smux peer 1.3.6.1.4.1.3317.1.2.6 quagga_ospf6d
  • In ospfd.conf, remove this line: 
    smux peer 1.3.6.1.4.1.3317.1.2.5 quagga_ospfd
  • In zebra.conf, remove this line: 
    smux peer 1.3.6.1.4.1.3317.1.2.1 quagga_zebra

What's New in 2.0.0

You can find a list of all features supported by Cumulus Linux here.

New Platforms from Broadcom Trident II HCL

  • Edge-Core AS4600-54T
  • Penguin Computing Arctica 3200XL

Routing

  • Data center iBGP
  • BGP interface peering
  • BGP next hop tracking
  • BGP update delay
  • BGP table map
  • BGP scalability: Handling 300+ peers
  • BGP scalability: Large TCP socket buffer

VXLAN

  • Using Broadcom Trident II-based switches
  • Integration with VMware NSX

Multicast

  • IGMP snooping
  • MLD snooping

QoS

  • DSCP-based Classification
  • DSCP rewrite

PTM

  • Maintenance release of PTMD

New Cumulus Linux cl-* Commands

  • cl-bgp
  • cl-ospf
  • cl-ospfv6
  • cl-ra
  • cl-rctl

Documentation

You can read the technical documentation here.

Known Issues in Cumulus Linux 2.0.0

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

Release Note ID Summary Description
RN-1 Restarting switchd flaps all switch ports switchd is a user-level process created by Cumulus Networks 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, it closes the tap FDS, hence resulting in all links going down.
RN-4 ifup/ifdown must be used for interfaces with IPv6 addresses defined in /etc/network/interfaces, otherwise the IPv6 interface will go down Two scenarios are shown below; one with ifup/ifdown, the other with ifconfig down.

With ifup/ifdown:
 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@switch$ sudo ifdown swp1
cumulus@switch$ 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@switch$ 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@switch$ 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@switch$

With ifconfig down:
 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@switch$ sudo ifconfig swp1 down
cumulus@switch$ 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@switch$ sudo ifconfig swp1 up ADDRCONF(NETDEV_UP): swp1: link is not ready
cumulus@switch$ 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)
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
RN-32 Adding bridges increases bootup time If the "bridge_maxwait" parameter is not set, the system will take approximately twice as long to bring the system up.

You should set the "bridge_maxwait" to 1.

Example configuration:
 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
RN-48 Agema 48x10GE switch eth0 driver reports eth0 as running even when PHY link is down The Agema 48x10GE eth0 driver reports eth0 as running even when the 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 shows eth0 as running, regardless of the PHY link status.

A fix will be released after Cumulus Linux 1.5.
RN-52 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 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 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 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 an 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.
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.
RN-63 BGP4 recursive route not supported

Quagga's bgpd does not support recursive routing when it's resolving BGP routes. It does work with respect to IGP routes.

For 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 types 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.

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.

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.

Sample configuration:
 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:
 cumulus@switch:$ 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 
 cumulus@switch:$ 

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 
 Runtime status after change: 

cumulus@switch:$ 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 cumulus@switch:$
RN-65 Virtual links in Quagga's OSPFv2 are non-operational Cumulus Networks testing has identified too many issues with virtual link support in Quagga's OSPFv2. The feature is unsupported.
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 */ 
cumulus@switch:$ sudo ip addr add 9000:1000:1000:1000::1/80 dev lo cumulus@switch:$ sudo ip -6 route unreachable 9000:1000:1000:1000::/80 dev lo proto kernel metric 256 error -101
RN-70 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-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 hardware fill up, new kernel routes can cause existing routes to move from being fully allocated to being partially allocated.

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

For example, on systems with Trident+ chips, 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:
 cumulus@switch:~# sudo 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.
RN-88 SNMP Support for Quagga Is NOT Provided in Cumulus Linux Cumulus Linux 2.0 does not provide SNMP support for Quagga.
RN-91 sfputil Outputs Garbled Data for Optical QSFP on a Penguin 48x10GE The following example shows the garbled output from sfputil for a 10GE port:
 cumulus@switch:/sys/class/eeprom_dev/eeprom54/device$ sudo cl-sfputil -p swp52 
 swp52: SFP detected 
 Connector : MT-RJ 
 EncodingCodes : Unknown 
 ExtIdentOfTypeOfTransceiver : Unknown
 Length50um(UnitsOf10m) : 66 
 Length62.5um(UnitsOfm) : 132
 LengthCable(UnitsOfm) : 8 
 LengthOM3(UnitsOf10m) : 16
 LengthSMFkm-UnitsOfKm : 128
 NominalSignallingRate(UnitsOf100Mbd) : 32 
 RateIdentifier : Unknown 
 ReceivedPowerMeasurementType : OMA 
 TransceiverCodes : 
 10GEthernetComplianceCode : 10G Base-SR 
 EthernetComplianceCodes : BASE-PX 
 FibreChannelTechnology : Shortwave laser w/o OFC (SN) 
 FibreChannelTransmissionMedia : Multimode, 50um (M5, M5E)
 SONETComplianceCodes : OC-12, single mode, long reach 
 TypeOfTransceiver : Unknown 
 VendorDataCode(yymmdd) : ??B?1b 
 VendorName : @?B @?B? 
 VendorOUI : @? 
 VendorPN : B @?B @? 
 VendorRev : B? 
 VendorSN : B?M?4hРB?0`
RN-99 cl-img-clear-overlay Is Disabled if Kernel Is Upgraded Using apt-get If you have upgraded the kernel to version 1.5.2 using apt-get update, then cl-img-clear-overlay will be disabled. To ensure Cumulus Linux and all its contained packages are in sync, and to be able to use cl-img-clear-overlay, perform a full install of Cumulus Linux using cl-img-install.
RN-102 VXLAN: Error when Configuring VXLAN Network ID 0 or 16777215 VNI ID 0 and 16777215 are reserved values under Cumulus Linux and should not be used in a VXLAN configuration.

Steps to reproduce:
1. In your configuration script, set the VNI ID to 0 for a VXLAN netdev device.
41: vxLan_1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc 
noqueue master br-1-0 state UNKNOWN mode DEFAULT link/ether da:2c:2a:7e:05:ea brd ff:ff:ff:ff:ff:ff vxlan id 0 local 12.0.0.17 port 32768 61000 ageing 300 ^^ Not ME 42: br-1-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
noqueue state UP mode DEFAULT link/ether 44:38:39:00:44:82 brd ff:ff:ff:ff:ff:ff bridge

2. Form the bridge.
3. Try to add a MAC address.
4. You will see following error:
 In [25]: pp.pprint(list_me) 
 ['1381369733.607298 2013-10-10 01:48:53 hal_bcm.c:1130 CRIT Ticket: 
CM-1573: DROP_PKT_CNT_INGr counter not supported on TRIDENT2', '1381369812.155459 2013-10-10 01:50:12 hal_bcm.c:1130 CRIT Ticket:
CM-1573: DROP_PKT_CNT_INGr counter not supported on TRIDENT2', '1381370042.649162 2013-10-10 01:54:02 hal_bcm.c:1130 CRIT Ticket:
CM-1573: DROP_PKT_CNT_INGr counter not supported on TRIDENT2', '1381370281.875083 2013-10-10 01:58:01 hal_bcm.c:1130 CRIT Ticket:
CM-1573: DROP_PKT_CNT_INGr counter not supported on TRIDENT2', '1381370286.427230 2013-10-10 01:58:06 hal_bcm_vxlan.c:381
CRIT VPN create failed: -8', <<?? '1381370286.978184 2013-10-10 01:58:06 hal_bcm_vxlan.c:381
CRIT VPN create failed: -8', '1381370287.114601 2013-10-10 01:58:07 hal_bcm_vxlan.c:381
CRIT VPN create failed: -8', '1381370287.383625 2013-10-10 01:58:07

Solution:
Do not use VNI ID 0 or 16777215 for VXLANs.
RN-103 In a VRR environment, the server that is bonded to the VRR switches could lose packets destined to the VRR's IP addresses for up to 15 seconds.

In the following configuration:

. r1 
 . / \ 
 . vrr1------vrr2 
 . \ / 
 . host1 

The hosts have bond interfaces where one sub-interface goes to switch, vrr1, and the other goes to the other switch, vrr2. 

If the link between the host and one of the VRR switches goes down, it can take up to 15 seconds of the VRR switches to send out an ARP to clear the ARP cache on the host for the IP address on the bridge interface. This is because the host might not clear the ARP cache since the bond doesn't go down. Only a sub-interface in the bond goes down.

Steps to reproduce:
1. One of the the hosts connected to the VRR switches, ping the real IP addresses of the bridge.
2. On the same host, bring the active interface down with "ip link set <interface> down" and let the backup take over.
3. Ping the real IP addresses of the VRR switch that is connected to the active interface.
RN-111 Default arp_filter is set to 0, which causes the wrong interfaces to be associated From Linux documentation:

arp_filter - 0 (default) The kernel can respond to arp requests with addresses from other interfaces. This may seem wrong but it usually makes sense, because it increases the chance of successful communication. IP addresses are owned by the complete host on Linux, not by particular interfaces. Only for more complex setups like load-balancing, does this behavior cause problems.

To work around this issue, set the arp_filter to 1:
 sysctl -w net.ipv4.conf.default.arp_filter=1 
sysctl -w net.ipv4.conf.all.arp_filter=1
RN-112 Enabling LACP support for non-L3/L4 modes Issue:
The current LACP implementation only supports srcdestip (0x6) mode.

Resolution:
In order to use srcdestmac mode, use the following commands:

First, find the bond name to hardware ID mapping:
cumulus@switch:/var/log# sudo kill -SIGRTMIN+5 `pidof switchd` 
cumulus@switch:/var/log# grep -A 1000 'Bond Info Dump Start' /
/var/log/switchd.log | grep -B 1000 'Bond Info Dump End'
1386720020.205690 2013-12-11 00:00:20 sync.c:740 Bond Info Dump Start
1386720020.205953 2013-12-11 00:00:20 sync.c:736 Kernel: bond0 HAL: 0>>>Mapping
1386720020.205981 2013-12-11 00:00:20 sync.c:743
1386720020.206005 2013-12-11 00:00:20 hal_bcm.c:4110 HAL unit: 0
1386720020.206042 2013-12-11 00:00:20 hal_bcm.c:4106 HAL: 0 ext_vlan 0
int_vlan 2000 egr_pg 1
1386720020.206225 2013-12-11 00:00:20 sync.c:745 Bond Info Dump End

Based on the mapping, run the following command, where psc id is the HAL:x:
cumulus@switch:$ sudo /usr/lib/cumulus/bcmcmd trunk psc id=1 rtag=0x3 

Notes:
1. The HAL ID is a non-persistent ID.
2. If the bond interface goes down or up, you need to do this again.

Verify the commands:
srcdestmac mode 0x3== platform dni-7448-05 
XOR DST+SRC MAC = PASS
FLOOD = PASS
RN-113 High memory utilization on switches when large number of MAC addresses have ageing time set to 20000 Issue:
For example, on a system when 115,000 MAC addresses are added with ageing time set to 20,000 seconds, the memory usage climbs to more than 90% and a cl-support incident is created.

Solution:

Cumulus Networks has tested and verified 32,000 MAC addresses for every supported platform. In addition, each manufacturer provides their own limits in the hardware.

You can determine your switch's MAC address hardware limit using cl-resource-query:

cumulus@switch:~$ sudo cl-resource-query 
Host entries: 2, 0% of maximum value 8192
IPv4 neighbors: 2
IPv6 neighbors: 0
Route entries: 9, 0% of maximum value 8092
IPv4 Routes: 5
IPv6 Routes: 2
Long route entries: 2, 0% of maximum value 2048
ECMP nexthops: 0, 0% of maximum value 16346
MAC entries: 0, 0% of maximum value 32768
RN-114 First 4 packets hitting the ACL FORWARD chain for setting DSCP values don't have the DSCP values set correctly. Issue:
The first 4 packets hitting the ACL for setting the DSCP values aren't getting their DSCP values set. After that, the reset of the packets have the DSCP values set correctly.

For example, assume you installed the following ACLs:
[iptables] 
-t mangle -A FORWARD -s 11.0.3.2 -p tcp -t mangle /
--in-interface swp1s0 -j SETQOS --set-dscp 10
-t mangle -A FORWARD -s 11.0.6.2 -p tcp -t mangle /
--in-interface swp1s0 -j SETQOS --set-dscp 10
-t mangle -A FORWARD -s 11.0.7.2 -p tcp -t mangle /
--in-interface swp1s0 -j SETQOS --set-dscp 10
-t mangle -A FORWARD -s 13.0.0.2 -p tcp -t mangle /
--in-interface swp1s0 -j SETQOS --set-dscp 10
-t mangle -A FORWARD -s 60.0.0.2 -p tcp -t mangle /
--in-interface swp1s1 -j SETQOS --set-dscp 10
-t mangle -A FORWARD -s 12.0.1.2 -p tcp -t mangle /
--in-interface swp1s2 -j SETQOS --set-dscp 10

Try sending 10 packets from host11 using the following command:
 mz swp1 -A 60.0.0.2 -B 12.0.2.3 -b 00:02:00:00:00:1a -t tcp 
"sp=3000,dp=4000" -p 80 -a 00:02:00:00:00:03


The first few packets received by the destination show that the DSCP values aren't set:
[cumulus@switch] out:18:19:10.703214 44:38:39:00:5d:0e > 00:02:00:00:00:07, 
ethertype IPv4 (0x0800), length 134: (tos 0x0, ttl 253, id 0, offset 0,
flags [none], proto TCP (6), length 120)
[cumulus@switch] out: 60.0.0.2.3000 > 12.0.2.3.4000: Flags [none],
cksum 0xc879 (correct), seq 42:122, win 10000, length 80
[cumulus@switch] out:18:19:10.703871 44:38:39:00:5d:0e > 00:02:00:00:00:07,
ethertype IPv4 (0x0800), length 134: (tos 0x0, ttl 253, id 0, offset 0,
flags [none], proto TCP (6), length 120)
[cumulus@switch] out: 60.0.0.2.3000 > 12.0.2.3.4000: Flags [none],
cksum 0xc879 (correct), seq 42:122, win 10000, length 80
[cumulus@switch] out:18:19:10.704178 44:38:39:00:5d:0e > 00:02:00:00:00:07,
ethertype IPv4 (0x0800), length 134: (tos 0x0, ttl 253, id 0, offset 0,
flags [none], proto TCP (6), length 120)
[cumulus@switch] out: 60.0.0.2.3000 > 12.0.2.3.4000: Flags [none],
cksum 0xc879 (correct), seq 42:122, win 10000, length 80
[cumulus@switch] out:18:19:10.704228 44:38:39:00:5d:0e > 00:02:00:00:00:07,
ethertype IPv4 (0x0800), length 134: (tos 0x0, ttl 253, id 0, offset 0,
flags [none], proto TCP (6), length 120)
[cumulus@switch] out: 60.0.0.2.3000 > 12.0.2.3.4000: Flags [none],
cksum 0xc879 (correct), seq 42:122, win 10000, length 80
[cumulus@switch] out:18:19:10.712971 44:38:39:00:5d:0e > 00:02:00:00:00:07,
ethertype IPv4 (0x0800), length 134: (tos 0x28, ttl 253, id 0, offset 0,
flags [none], proto TCP (6), length 120)
[cumulus@switch] out: 60.0.0.2.3000 > 12.0.2.3.4000: Flags [none],
cksum 0xc879 (correct), seq 42:122, win 10000, length 80
[cumulus@switch] out:18:19:10.715845 44:38:39:00:5d:0e > 00:02:00:00:00:07,
ethertype IPv4 (0x0800), length 134: (tos 0x28, ttl 253, id 0, offset 0,
flags [none], proto TCP (6), length 120)
[cumulus@switch] out: 60.0.0.2.3000 > 12.0.2.3.4000: Flags [none],
cksum 0xc879 (correct), seq 42:122, win 10000, length 80
[cumulus@switch] out:18:19:10.723845 44:38:39:00:5d:0e > 00:02:00:00:00:07,
ethertype IPv4 (0x0800), length 134: (tos 0x28, ttl 253, id 0, offset 0,
flags [none], proto TCP (6), length 120)
[cumulus@switch] out: 60.0.0.2.3000 > 12.0.2.3.4000: Flags [none],
cksum 0xc879 (correct), seq 42:122, win 10000, length 80
[cumulus@switch] out:18:19:10.727920 44:38:39:00:5d:0e > 00:02:00:00:00:07,
ethertype IPv4 (0x0800), length 134: (tos 0x28, ttl 253, id 0, offset 0,
flags [none], proto TCP (6), length 120)
[cumulus@switch] out: 60.0.0.2.3000 > 12.0.2.3.4000: Flags [none],
cksum 0xc879 (correct), seq 42:122, win 10000, length 80
[cumulus@switch] out:18:19:10.736504 44:38:39:00:5d:0e > 00:02:00:00:00:07,
ethertype IPv4 (0x0800), length 134: (tos 0x28, ttl 253, id 0, offset 0,
flags [none], proto TCP (6), length 120)
[cumulus@switch] out: 60.0.0.2.3000 > 12.0.2.3.4000: Flags [none],
cksum 0xc879 (correct), seq 42:122, win 10000, length 80
[cumulus@switch] out:18:19:10.739893 44:38:39:00:5d:0e > 00:02:00:00:00:07,
ethertype IPv4 (0x0800), length 134: (tos 0x28, ttl 253, id 0, offset 0,
flags [none], proto TCP (6), length 120)
[cumulus@switch] out: 60.0.0.2.3000 > 12.0.2.3.4000: Flags [none],
cksum 0xc879 (correct), seq 42:122, win 10000, length 80

"fp show" displays the following:
EID 0x0000005d: gid=0x1, 
slice=2, slice_idx=0, part =0 prio=0, flags=0x10202, Installed, Enabled
tcam: color_indep=0,
InPorts
DATA=0x0000000000000000000000000000000000000000000000000000000000000004
MASK=0x000000000000000000000000000000000000000000000000001ffffffffffffe
Stage
StageIngress
IpType
Offset: 222 Width: 4
DATA=0x00000000
MASK=0x0000000e
SrcIp
Offset: 142 Width: 32
DATA=0x3c000002
MASK=0xffffffff
slice=3, slice_idx=0, part =1 prio=0, flags=0x14204, Installed, Enabled
tcam: color_indep=0,
IpProtocol
Offset: 0 Width: 0
Offset1: 217 Width1: 8
DATA=0x00000006
MASK=0x000000ff
action={act=DscpNew, param0=10(0xa), param1=0(0), param2=0(0), param3=0(0)}
policer=
statistics={stat id 93 slice = 2 idx=0 entries=1}{Bytes}{Packets}

"fp stat get" reveals:

sudo /usr/lib/cumulus/bcmcmd fp stat get StatID=93 type=Packets 
The value is: 0x0a
RN-115 decode-syseeprom output should be sent with the cl-support script to Cumulus Support decode-syseeprom summarizes hardware information, which is useful to Cumulus Networks Support when investigating support issues.

Output from decode-syseeprom will be added to the cl-support script in a future release.
RN-116 Bridge driver issues affecting IGMP snooping behavior on STP topology change. Issue:
The Cumulus Linux bridge driver does not adhere to the IETF standard for IGMP snooping during an STP topology change.

Resolution:
On an STP topology change, RFC 4541, section 2.1.1, point 4 (https://tools.ietf.org/html/rfc4541, copied below) suggests what an IGMP snooping switch should do to reduce network convergence; this is not present in the bridge driver.

In addition, the bridge driver does not send a general query on receiving a global leave.

4) An IGMP snooping switch should be aware of link layer topology changes
caused by Spanning Tree operation. When a port is enabled or disabled by
Spanning Tree, a General Query may be sent on all active non-router ports
in order to reduce network convergence time. Non-Querier switches should be
aware of whether the Querier is in IGMPv3 mode. If so, the switch should not
spoof any General Queries unless it is able to send an IGMPv3 Query that
adheres to the most recent information sent by the true Querier. In no case
should a switch introduce a spoofed IGMPv2 Query into an IGMPv3 network, as
this may create excessive network disruption.

If the switch is not the Querier, it should use the 'all-zeros' IP Source Address
in these proxy queries (even though some hosts may elect to not process queries
with a 0.0.0.0 IP Source Address). When such proxy queries are received, they must
not be included in the Querier election process. 
RN-117 ACL: Generic error message displayed after ACL rule installation failure. Issue:
After an ACL rule installation failure, a generic error message is displayed.

Resolution:
In a future release of Cumulus Linux, more specific error messages will be displayed so you can correct errors you may have made in your rule file and reinstall the ACL file, including specific error messages from the BCM layer.

Steps to reproduce:
cumulus@switch:$ sudo 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 ...
error: hw sync failed (sync_acl hardware installation failed)
Installing acl policy... Rolling back ..
failed.
RN-118 Bridge: CDP frames are looped by bridge driver and sent to incorrect port; link local boundary issue. Issue:
Cumulus Linux forwards link local frames, instead of filtering the frame based on the link local MAC address 01:00:0c:cc:cc:cc.

Steps to reproduce:
1. Run the following simulation:
 start -vwm -D /tmp/FILE -c $T_H/data/configs/l2_lldp_cfg.py $T_H/data/specs/l2_lldp.py /
-k $C_H/build-amd64/vci/vci.bzImage -b $C_H/build-amd64/vci/vci.img -H switch:qct-ly6-xx

2. Edit the following line in /etc/default/lldpd:
 DAEMON_ARGS="-x -ccc" 

3. Repeat this on the sw1 side on soft-node as well.
4. Perform tcpdump on bridge member port (swp3s1) and capture CDP packets.
cumulus@switch:$ sudo tcpdump -i swp3s1 -xxev 
01:12:20.431004 44:38:39:00:3f:12 (oui Unknown) > 01:00:0c:cc:cc:cc (oui Unknown),
802.3, length 101: << Note mac address is swp3s0
LLC, dsap SNAP (0xaa) Individual, ssap SNAP (0xaa) Command, ctrl 0x03: oui Cisco
(0x00000c), pid CDP (0x2000): CDPv1, ttl: 120s, checksum: 376 (unverified), length 79
Device-ID (0x01), length: 10 bytes: 'qct-ly6-02'
Address (0x02), length: 13 bytes: IPv4 (1) qct-ly6-02.lab.cumulusnetworks.com
Port-ID (0x03), length: 6 bytes: 'swp3s0' >>>> Which is shown here.????
Capability (0x04), length: 4 bytes: (0x00000019): Router, L2 Switch, L3 capable
Version String (0x05), length: 13 bytes:
Cumulus Linux
Platform (0x06), length: 5 bytes: 'Linux'
0x0000: 0100 0ccc cccc 4438 3900 3f12 0057 aaaa
0x0010: 0300 000c 2000 0178 df6d 0001 000e 7163
0x0020: 742d 6c79 362d 3032 0002 0011 0000 0001
0x0030: 0101 cc00 040a 0001 5700 0300 0a73 7770
0x0040: 3373 3000 0400 0800 0000 1900 0500 1143
0x0050: 756d 756c 7573 204c 696e 7578 0006 0009
0x0060: 4c69 6e75 78
01:12:21.407310 44:38:39:00:3f:13 (oui Unknown) > 01:00:0c:cc:cc:cc (oui Unknown),
802.3, length 101: LLC, dsap SNAP (0xaa) Individual, ssap SNAP (0xaa) Command,
ctrl 0x03: oui Cisco (0x00000c), pid CDP (0x2000): CDPv1, ttl: 120s, checksum: 376
(unverified), length 79
Device-ID (0x01), length: 10 bytes: 'qct-ly6-02'
Address (0x02), length: 13 bytes: IPv4 (1) qct-ly6-02.lab.cumulusnetworks.com
Port-ID (0x03), length: 6 bytes: 'swp3s1'
Capability (0x04), length: 4 bytes: (0x00000019): Router, L2 Switch, L3 capable
Version String (0x05), length: 13 bytes:
Cumulus Linux
Platform (0x06), length: 5 bytes: 'Linux'
0x0000: 0100 0ccc cccc 4438 3900 3f13 0057 aaaa
0x0010: 0300 000c 2000 0178 de6d 0001 000e 7163
0x0020: 742d 6c79 362d 3032 0002 0011 0000 0001
0x0030: 0101 cc00 040a 0001 5700 0300 0a73 7770
0x0040: 3373 3100 0400 0800 0000 1900 0500 1143
0x0050: 756d 756c 7573 204c 696e 7578 0006 0009
0x0060: 4c69 6e75 78
cumulus@switch:~# ip addr show swp3s1
9: swp3s1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br1
state UP qlen 500
link/ether 44:38:39:00:3f:13 brd ff:ff:ff:ff:ff:ff
cumulus@switch:~# ip addr show swp3s0
8: swp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br1
state UP qlen 500
link/ether 44:38:39:00:3f:12 brd ff:ff:ff:ff:ff:ff
RN-119 LLDP frames being reported as software RX drops when received on bridge interfaces. Issue:
RX drops have been reported on interfaces (using cl-netstat) that are not reflected in hardware, when they are actually received LLDP frames.

Steps to reproduce:
#! /bin/bash 
mz eth3.1032 -c 0 -d 100m "01:80:c2:00:00:0e 02:00:00:00:00:01 88:cc 02:07
04:90:e2:ba:21:a9:1c:04:07:03:90:e2:ba:21:a9:1c:06:02:00:78:0a:27:78:6b:76:
6d:31:30:33:34:31:2e:70:33:72:32:2e:6d:61:73:73:65:66:66:65:63:74:2e:64:68:
63:6f:6d:70:75:74:65:2e:6e:65:74:0c:5d:55:62:75:6e:74:75:20:31:32:2e:30:34:
2e:31:20:4c:54:53:0a:20:4c:69:6e:75:78:20:33:2e:32:2e:30:2d:32:39:2d:67:65:
6e:65:72:69:63:20:23:34:36:2d:55:62:75:6e:74:75:20:53:4d:50:20:46:72:69:20:
4a:75:6c:20:32:37:20:31:37:3a:30:33:3a:32:33:20:55:54:43:20:32:30:31:32:20:
78:38:36:5f:36:34:0e:04:00:1c:00:00:10:0c:05:01:0a:41:10:30:02:00:00:00:04:
00:08:04:65:74:68:33:fe:09:00:12:0f:03:01:00:00:00:00:fe:09:00:12:0f:01:00:
80:00:00:21:fe:06:00:12:0f:04:00:00:00:00"
RN-120 ethtool LED blinking does not work with switch ports. Linux uses ethtool -p <interface> 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 Linux.
RN-121 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-122 Spanning tree interoperability issue with common spanning tree. Cumulus Linux currently does not operate correctly with bridges that implement a single instance of STP (common spanning tree) and map all VLANs (bridges) to that single instance.
RN-123 cl-ecmpcalc returns an exception or returns incorrect output When invoking the cl-ecmpcalc utility, it can fail with an exception or returns incorrect output. 

This issue will be fixed in a future release of Cumulus Linux.
RN-124 Under rare conditions, Quagga's bgpd has issues when shutting down in general or when a "no router bgp" command is issued A BGP core file may be present in cl-support.
RN-125 Network LSA with an old router ID isn't flushed out by the originator. Issue:
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.

Resolution:
Cumulus Networks isn't removing this LSA, so it will be naturally aged out.
RN-126 Dell S4810 port mapping starts numbering switch ports at 0 Cumulus Linux uses the same switch port layout for all but one of the switches on the HCL, where the port count starts from 1. The exception is the Dell S4810, which starts the port count from 0; hence the first 40G port is 48. 

On Dell S4810 switches, swp1 corresponds to port 0.
RN-127 In an OSPFv2 unnumbered interface, the "ip ospf area <area ID>" in the interface command section is rejected when a "network" command is present. Issue:
If there is a "network <network number>/<mask> area <area ID>" command present in the Quagga configuration, the "ip ospf area <area ID>" command is rejected with the error "Please remove network command first." This prevents you from configuring other areas on some of the unnumbered interfaces.

Steps to reproduce:
Here is a sample configuration from ospfd.conf that illustrates the problem:
router ospf 
log-adjacency-changes detail
ospf router-id 0.0.0.17
network 14.0.0.0/8 area 0.0.0.0
passive-interface swp4
passive-interface swp5
passive-interface swp6
passive-interface swp7
passive-interface swp8
!
interface swp1
ip ospf area 0.0.0.0
!
interface swp2
ip ospf area 0.0.0.1
!
interface swp3
ip ospf area 0.0.0.1
!
RN-128 Quagga does not start by default in Cumulus Linux 2.0 To start Quagga, modify /etc/quagga/daemons to enable the corresponding daemons.
zebra=yes (* this one is mandatory to get the others up) 
bgpd=yes
ospfd=yes
ospf6d=yes
ripd=no
ripngd=no
isisd=no
babeld=no

Then, restart Quagga.
 cumulus@switch1:~# sudo /etc/init.d/quagga start 
RN-130 Error when using "--out-interface" and the "-p" option in "ebtables" ACL

Consider the following "ebtables" ACL:

[ebtables]
-A FORWARD -p IPv4 —out-interface swp17s0.100 -j DROP

This ACL gets rejected with the following error:

hal_acl_bcm.c:1081 ERR bcm_field_qualify_IpType failed Entry not found

If you change the --out-interface to --in-interface, the ACL is accepted.

RN-132 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 Interface names in Cumulus Linux cannot exceed 15 characters

Device names, including interface names, in Cumulus Linux cannot exceed 16 characters – including the terminator. Cumulus Linux 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 <<<<????
br402-peering-9	 8000.089e01cebe3a	no	 bond0.402
br500-pi-exa	 8000.089e01cebe4f	no	 bond0.500
br501-akamai-ex	 8000.089e01cebe42	no	 bond0.501
br502-exa-inter	 8000.089e01cebe42	no	 bond0.502
cumulus@switch:/sys/class/net$ 
RN-134 Installing Chef under Cumulus Linux

The Cumulus Linux 2.0 repository contains two versions of Chef, the automation tool: 11.6.2 (the current version) and 10.30.4.

To install the latest version, connect to the switch and use apt-get:

cumulus@switch:~# sudo  apt-get install chef

To install 10.30.4, connect to the switch and use apt-get:

cumulus@switch:~# sudo apt-get install chef=10.30.4-0.debian.7.3 
RN-145 Cumulus Networks security advisory

Cumulus Networks is writing to inform you of a security issue with certain Cumulus Linux packages.  

The repo.cumulusnetworks.com was updated with the latest security advisory from https://lists.debian.org/debian-security-announce/.

The following packages have been uploaded to repo.cumulusnetworks.com:
file_5.11-2+deb7u3_amd64.deb
file_5.11-2+deb7u3_powerpc.deb
libmagic1_5.11-2+deb7u3_amd64.deb
libmagic1_5.11-2+deb7u3_powerpc.deb
libssl1.0.0_1.0.1e-2+deb7u5_amd64.deb
libssl1.0.0_1.0.1e-2+deb7u5_powerpc.deb
libssl-dev_1.0.1e-2+deb7u5_amd64.deb
libssl-dev_1.0.1e-2+deb7u5_powerpc.deb
libyaml-0-2_0.1.4-2+deb7u4_amd64.deb
libyaml-0-2_0.1.4-2+deb7u4_powerpc.deb
openssh-client_6.0p1-4+deb7u1_amd64.deb
openssh-client_6.0p1-4+deb7u1_powerpc.deb
openssh-server_6.0p1-4+deb7u1_amd64.deb
openssh-server_6.0p1-4+deb7u1_powerpc.deb
openssl_1.0.1e-2+deb7u5_amd64.deb
openssl_1.0.1e-2+deb7u5_powerpc.deb

The upgrade is available for Cumulus Linux 2.0.x.

For instructions to apply latest security upgrades, please refer to this Help Center.

Regarding previous Debian security upgrades for Cumulus Linux:

  • The Cumulus Linux binary image by default includes all Debian security updates available prior to the build date.
  • The Cumulus Linux image files use the following naming format: <X.Y.Z release>-<md5sum>-<build date>-final.
  • Customers can identify security vulnerabilities by correlating a build date with the dates of Debian security updates posted at www.debian.org/security/.
RN-195

Security Update for apt and bash packages: Shellshock bug fix

For information on updating Cumulus Linux to address this issue, read this article.

RN-270 inotify support

inotify is not supported by the overlayfs root filesystem on PowerPC platforms.

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