Release Notes for Cumulus Linux 1.5.0 RC2 & RC3

Follow

Overview

These release notes support Cumulus Linux 1.5 Release Candidate 2 & Release Candidate 3. These release notes describe supported hardware platforms, currently available features, and known issues. In listing issues, resolved issues from POC images are also listed for completeness.

Licensing

The software will only allow  eth0/l0 to be used in routing/switching. All switch ports (swp1, swp2, etc - ASIC supported ports) - will be shut down. In order to activate these ports, a license needs to be entered.

Without the license, the system will come up and work BUT only via the management port, eth0. 

The license key is either tied to a system or a floating license. This depends on the sales arrangement between Cumulus Networks and "you" as a customer.

The license key is a text file which is provided to you via your sales/customer experience representative. 

Entering/Activating the System with the License

 a) Login into the system as root.

 b) Copy the license file to an appropriate directory on the switch.

 c) Execute the following command: ``cl-license-install license_file.txt``

 d) Reboot the switch.

(Ensure that the appropriate path is set for ``license_file.txt``.)

This will activate the regular switch ports.

Details on this entire procedure are found at the Cumulus Networks support page:

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

Supported Hardware Platforms

Cumulus Linux 1.5 RC1 supports the following hardware platforms:

Configuration

Accton

DNI

48 x 10G + 4 x 40G

ES5652BT1 or BT2

ET-7448BF

48 x 1G + 4 x 10G

 

ET-6448R

Cumulus Networks is currently qualifying other vendors and configurations, such as Quanta (LY2, LB9) and the Accton 48x1G platform. If there is a specific platform that is of interest please, contact Cumulus Networks.

Available memory per system on qualified platforms:

System

MTD Flash

Block Device

dni-7448

128MB

SD 8GB

dni-6448

64MB

8GB front-panel USB

Accton-bt1

8MB

USB 2GB

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

64 is supported on hardware but Cumulus Networks has tested to 16.

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 Linux-specific user space applications which allows the fabric topology to be verified prior to configuring L3 routing protocols.

Security

Feature

Tested

Notes

ACL (data plane and control plane)

in progress

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

yes

 

 

Management Authentication/Authorization

Feature

Notes

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

SSH interactive

 

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-RC2

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 athttps://support.cumulusnetworks.com/entries/24087796-Copying-configurations-across-switches-e-g-bad-switch-to-new-switch- for more information.
CumulusLinux-1.5-RC2   Configuration Management
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-RC2, cumulus_linux_poc   Layer 2 (Control Protocols)
RN-26 STP:Port ID election tie breaker is not predictable unless send port priority is set Documentation note for linux behavior w.r.t STP PortID selection 

STP election:http://en.wikipedia.org/wiki/Spanning_tree_protocol 
~~~~~~~~~~ 
In summary, the sequence of events to determine the best received BPDU (which is the best path to the root) is 
• Lowest root bridge ID - Determines the root bridge 
• Lowest cost to the root bridge - Favors the upstream switch with the least cost to root 
• Lowest sender bridge ID - Serves as a tie breaker if multiple upstream switches have equal cost to root 
• Lowest sender port ID - Serves as a tie breaker if a switch has multiple (non-Etherchannel) links to a single upstream switch, where: 
o Bridge ID = priority (16 bits) + ID [MAC address] (48 bits); the default bridge priority is 32768, and 
o Port ID = priority (4 bits) + ID [Interface number] (12 bits); the default port priority is 128. 
Linux Implementation: 
~~~~~~~~~~~~~~~~~~~~ 
We elect the port ID based on the sequence the port is getting added in the given bridge. As result we may endup getting larger physical port lowest interface number. 
If user does not define the port priority at the sender side then topology predictability is lost. It is mandated for our system that we set appropriated sender port priority. 
consider following operations: 
~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~ 
root@dni-7448-30:~# brctl showstp br1003 
br1003 
bridge id 8000.44383900139f 
designated root 1000.000200000014 
root port 3 path cost 2 
max age 20.00 bridge max age 20.00 
hello time 2.00 bridge hello time 2.00 
forward delay 30.00 bridge forward delay 30.00 
ageing time 200.00 
hello timer 0.00 tcn timer 0.00 
topology change timer 0.00 gc timer 168.63 
flags 


swp1.1003 (2) 
port id 8002 state learning 

swp6.1003 (1) 
port id 8001 state learning 

swp7.1003 (4) 
port id 8004 state learning 

swp8.1003 (3) 
port id 8003 state learning 


then user performed following option 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
root@dni-7448-30:~# ifdown swp8.1003 
Removed VLAN -:swp8.1003:- 
root@dni-7448-30:~# ifdown swp7.1003 
Removed VLAN -:swp7.1003:- 
root@dni-7448-30:~# ifup swp7.1003 
Set name-type for VLAN subsystem. Should be visible in /proc/net/vlan/config 
Added VLAN with VID == 1003 to IF -:swp7:- 
root@dni-7448-30:~# ifup swp8.1003 
Set name-type for VLAN subsystem. Should be visible in /proc/net/vlan/config 
Added VLAN with VID == 1003 to IF -:swp8:- 
root@dni-7448-30:~# 

root@dni-7448-30:~# brctl addif br1003 swp7.1003 
root@dni-7448-30:~# brctl addif br1003 swp8.1003 


root@dni-7448-30:~# brctl showstp br1003 | grep -B 1 'port id' 
swp1.1003 (2) 
port id 8002 state forwarding 
-- 
swp6.1003 (1) 
port id 8001 state blocking 
-- 
swp7.1003 (3) 
port id 8003 state forwarding <<< Please note his id got change 
-- 
swp8.1003 (4) 
port id 8004 state forwarding <<< Please note his id got change 
root@dni-7448-30:~# 

Hence his load balancing is gone for toss. 

Comments: 
~~~~~~~~~~~ 
This behavior is linux specific and differs from the behavior of traditional vendors.
CumulusLinux-1.5-RC2, cumulus_linux_poc   Layer 2 (Control Protocols)
RN-49 Annex E (and hence Annex D) of IEEE802.1AB (lldp) is not supported Cumulus Linux does not support Annex E of IEEE 802.1AB 

Table E.1— IEEE 802.1 Organizationally Specific TLVs (optional) 
IEEE 802.1 subtype TLV name Reference 
01 Port VLAN ID E.2 
02 Port And Protocol VLAN ID E.3 
03 VLAN Name E.4 
04 Protocol Identity E.5 
05 VID Usage Digest E.6 
06 Management VID E.7 
07 Link Aggregation E.8 
08–FF Reserved — 

Hence we don't support Annex D section D.2 "IEEE802.1 Organizationally Specific TLVs" 
Port VLAN ID TLV 
Port and Protocol VLAN ID TLV 
VLAN Name TLV 
Protocol Identity TLV
CumulusLinux-1.5-RC2   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-RC2   Layer 2 (Control Protocols)
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-RC2   Layer 2 (Port 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-RC2   Layer 2 (Port Security)
RN-69 Statistics for ACL rules are reset to zero whenever the ACL rules are installed Installation of ACL rules using cl-acltool, causes a reset of ACL stats for all the rules 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-RC2   Layer 2 (Port Security)
RN-54 Some iptables options are not supported in Cumulus Linux Cumulus Linux doesn't support the following list of options: 
"!" in the "-p" option is not supported
CumulusLinux-1.5-RC2   Layer 2 (Port Security)
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-RC2, cumulus_linux_poc   Layer 2 (Segmentation)
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-RC2   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-RC2, cumulus_linux_poc   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-RC2   Layer 2 (Segmentation)
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-RC2, cumulus_linux_poc   Layer 3 (Forwarding)
RN-68 Errors in the routing table when configuring IPv6 addresses on the loop back interface 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-RC2   Layer 3 (Forwarding)
RN-47 Ip route append not supported 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.
CumulusLinux-1.5-RC2   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-RC2   Layer 3 (Forwarding)
RN-4 if site-local v6 address is present on an interface, all addresses are lost on that interface on a ifconfig down Two scenarios shown below. 
1) Adding a site-local scope address and shut down the interface. The interface v6 address was lost. 
2) Same experiment with global scope addresses show that they are retained. 

3) (not shown- but also breaks) If site-local and global-scope are both present, both are lost, when interface is brought down. 

root@dni-7448-09:/home/cumulus# ifconfig swp36 
swp36 Link encap:Ethernet HWaddr 44:38:39:00:02:a5 
UP BROADCAST MULTICAST MTU:1500 Metric:1 
RX packets:0 errors:0 dropped:0 overruns:0 frame:0 
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 
collisions:0 txqueuelen:500 
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) 

root@dni-7448-09:/home/cumulus# ip addr add fec0::1/128 dev swp36 
root@dni-7448-09:/home/cumulus# ifconfig swp36 
swp36 Link encap:Ethernet HWaddr 44:38:39:00:02:a5 
inet6 addr: fec0::1/128 Scope:Site 
UP BROADCAST MULTICAST MTU:1500 Metric:1 
RX packets:0 errors:0 dropped:0 overruns:0 frame:0 
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 
collisions:0 txqueuelen:500 
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) 

root@dni-7448-09:/home/cumulus# ifconfig swp36 down
root@dni-7448-09:/home/cumulus# ifconfig swp36 
swp36 Link encap:Ethernet HWaddr 44:38:39:00:02:a5 
BROADCAST MULTICAST MTU:1500 Metric:1 
RX packets:0 errors:0 dropped:0 overruns:0 frame:0 
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 
collisions:0 txqueuelen:500 
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) 


Now with global-scope address: 
root@dni-7448-09:/home/cumulus# ip addr add 2002::1/64 dev swp36 
root@dni-7448-09:/home/cumulus# ifconfig swp36 
swp36 Link encap:Ethernet HWaddr 44:38:39:00:02:a5 
inet6 addr: 2002::1/64 Scope:Global 
BROADCAST MULTICAST MTU:1500 Metric:1 
RX packets:0 errors:0 dropped:0 overruns:0 frame:0 
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 
collisions:0 txqueuelen:500 
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) 

root@dni-7448-09:/home/cumulus# ifconfig swp36 down
root@dni-7448-09:/home/cumulus# ifconfig swp36 
swp36 Link encap:Ethernet HWaddr 44:38:39:00:02:a5 
inet6 addr: 2002::1/64 Scope:Global 
BROADCAST MULTICAST MTU:1500 Metric:1 
RX packets:0 errors:0 dropped:0 overruns:0 frame:0 
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 
collisions:0 txqueuelen:500 
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) 

Address is not "lost"\!
CumulusLinux-1.5-RC2, cumulus_linux_poc   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-RC2   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. 

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-RC2   Layer 3 (Forwarding)
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-RC2, cumulus_linux_poc   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-RC2   Layer 3 (Routing)
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. CumulusLinux-1.5-RC2   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-RC2   Layer 3 (Routing)
RN-61 BGP4 Notifications missing for several conditions Quagga's bgpd doesn't properly send out notifications in several cases: 

a) Notifications are not sent to peers if the interface is going down. The peer will detect this via TCP connection time out. 
b) If errors, on any one of the following parameters in an UPDATE message are detected: 

CASE: <MESSAGE-ERROR> = "incorrect length for Path Attributes field" 
CASE: <MESSAGE-ERROR> = "incorrect Attribute Flags" 
CASE: <MESSAGE-ERROR> = "attribute Length which conflicts with the expected length" 
CASE: <MESSAGE-ERROR> = "missing well-known attribute" 
CASE: <MESSAGE-ERROR> = "non-recognized well-known attribute" 
CASE: <MESSAGE-ERROR> = "undefined value for ORIGIN attribute" 
CASE: <MESSAGE-ERROR> = "syntactically incorrect AS_PATH attribute" 
CASE: <MESSAGE-ERROR> = "optional attribute with error" 
CASE: <MESSAGE-ERROR> = "two appearances of the same attribute" 
CASE: <MESSAGE-ERROR> = "invalid NLRI field" 

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-RC2   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-RC2   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-RC2   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 unusable from Cumulus Network's perspective. 

If this issue get resolved by either Cumulus Networks or the community, Cumulus Linux will have the patches in the appropriate Cumulus Linux release. Currently the time frame for this is undetermined.
CumulusLinux-1.5-RC2   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-RC2   Layer 3 (Routing)
RN-52 Parameters like the router ID and DR priority cannot be changed while OSPFv3 is running Router ID and DR priority can only be changed by shutting down OSPFv3, changing the ID, and restarting OSPFv3 

DR priority if also changed may not properly reflect in LSAs that are still aging out.
CumulusLinux-1.5-RC2   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-RC2   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-RC2   Management Interface
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 

Support is being planned for the initial Cumulus Linux release.
CumulusLinux-1.5-RC2, cumulus_linux_poc   Tools
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. CumulusLinux-1.5-RC2   Tools
RN-79 cl-route-check when there are common mac across all interfaces When using a single mac address across all interfaces (in qct style) cl-route-check will record false positives. 

This happens because the nexthop resolution check will try to match the outgoing nexthop to an outgoing interface which it does using the source mac to search through the interface table. 

Since all interfaces have the same src mac, this will lead to failure.
CumulusLinux-1.5-RC2   Tools

Fixed Issues from POC

 

Key Summary Description affectedTag fixedTag Feature Category
RN-35 Enable puppet, chef, etc to parse the # cpu's correctly On the dni-7448 platforms, the physical CPU data isn't reported back correctly in puppet, chef due to incorrect or missing values 

For puppet, chef, etc the following files will be fixed. "physical id" should be in /proc/cpuinfo and correct entries (currently -1 values) under /sys/devices/system/cpu*/topology/physical_package_id
cumulus_linux_poc CumulusLinux-1.5-RC1 Configuration Management
RN-27 bridge path cost gets reset to value based on speed on link change The bridge driver exhibits this behavior currently: 

STP port path cost which was set by a user from replaced by the link-speed based path cost whenever the link goes down and comes back up 

More details found on the following links: 
http://lists.linuxfoundation.org/pipermail/bridge/2007-February/005265.html 

http://osdir.com/ml/linux.network.bridge/2007-08/msg00026.html 

The patch is not yet upstream
cumulus_linux_poc CumulusLinux-1.5-RC1 Layer 2 (Control Protocols)
RN-33 bridge mac aging_time is preset to 5minutes The bridge mac aging_time is preset to 5 minutes and cannot be changed. 

This issue is fixed in a later release
cumulus_linux_poc CumulusLinux-1.5-RC1 Layer 2 (Control Protocols)
RN-5 forwarding will be broken if the bridge mac address is changed manually The kernel bridge driver always makes a bridge device inherit its mac from one of its member ports, but user can also set arbitrary mac for the bridge device with ifconfig or equivalent. In case user does change it, the bridge driver doesn't enter the new mac in the fdb and doesn't make it a 'local' mac. So packets that are supposed to terminate on the bridge device or routed through the bridge device don't actually get delivered up the ip stack.

This is fixed in a later release
cumulus_linux_poc CumulusLinux-1.5-RC1 Layer 2 (Control Protocols)
RN-55 ACL: cpu policer is not policing properly In sending a burst of 1000 packets from mz, which will hit the glean adjacency and forward to the CPU. These packets should hit the IP_ROUTER acl rule and get policed to 1KBps and 1KBytes burst. 

It is verified that 1000 packets all hit the IP_ROUTER rule, and the bcm policer counter shows 999 red packets. However, from internal tests (tcpdump), it shows a large number of packets being sent to the cpu. BCM port counters also show that about half went to cpu and half get dropped.
CumulusLinux-1.5-RC1 CumulusLinux-1.5-RC2 Layer 2 (Port Security)
RN-44 mac entry is not properly removed in libnl cache A dynamic mac entry is stuck in libnl cache after a port is removed from a bridge. This causes switchd to repeatedly try and delete the entry from kernel. 

Note: 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. 

Observed behavior: 

- swp1 and swp2 are members of a bridge, macs learned on each port, total about 10 macs 
- swp1 is removed from the bridge, all it's learned macs are flushed from kernel and hardware. But one mac seems to be caught in the libnl cache. On every sync, switchd thinks it needs to be deleted from kernel 
- Following Message shows up continuously - "bridge: RTM_DELNEIGH swp1 not a bridge port" 
- after a forced resync, the mac is gone 

-> TO RESYNC - 
a) First find switchd PID 
b) assume PID ix X -> type: 'kill -SIGRTMIN X' 

Example: 

Right before the bridge port removal: 
root@dni-7448-26:~# brctl showmacs br0 
port name mac addr is local? ageing timer 
swp2 00:02:00:00:00:08 no 10.66 
swp2 00:02:00:00:00:09 no 3.93 
swp1 44:38:39:00:12:9c yes 0.00 
swp2 44:38:39:00:12:9d yes 0.00 
swp2 90:e2:ba:04:ef:14 no 10.16 


After bridge port removal (that mac is gone from both hw and sw): 
root@dni-7448-26:~# cl-bcmcmd l2 show 
mac=00:02:00:00:00:08 vlan=2000 GPORT=0x2 modid=0 port=2/xe1 
mac=00:02:00:00:00:09 vlan=2000 GPORT=0x2 modid=0 port=2/xe1 Hit 

root@dni-7448-26:~# brctl showmacs br0 
port name mac addr is local? ageing timer 
swp2 00:02:00:00:00:09 no 1.59 
swp2 44:38:39:00:12:9d yes 0.00 
root@dni-7448-26:~# br0: port 2(swp2) entering forwarding state 


THE FOLLOWING SHOWS UP ON THE SCREEN CONTINUOUSLY: 

bridge: RTM_DELNEIGH swp1 not a bridge port 
bridge: RTM_DELNEIGH swp1 not a bridge port 
bridge: RTM_DELNEIGH swp1 not a bridge port 
bridge: RTM_DELNEIGH swp1 not a bridge port
cumulus_linux_poc CumulusLinux-1.5-RC1 Layer 2 (Segmentation)
RN-43 With 400 bridge switchd is always doing add mac sync operation. Problem Definition: 
~~~~~~~~~~~~~~~~~~~ 
Switchd is constantly performing following add action in sync process. Where as bcm l2 info shows differently. 
Snippet from switchD log 
364405562.605760 2013-03-27 17:32:42 sync.c:2596 Bridge Macs Summary : 1366 Added, 0 Deleted, 0 Updated in 388290 usecs 
1364405562.986806 2013-03-27 17:32:42 sync.c:2596 Bridge Macs Summary : 1364 Added, 0 Deleted, 0 Updated in 375102 usecs 
1364405563.859513 2013-03-27 17:32:43 sync.c:2596 Bridge Macs Summary : 1365 Added, 0 Deleted, 0 Updated in 382292 usecs 
BCM l2 info 
root@dni-7448-30:/var/log# cl-bcmcmd l2 info 
mac entries : 1908 / 131072 
bpdu entries : 501 / 512 
root@dni-7448-30:/var/log# 

Step: 
~~~~~~~~ 
1. Configure system for 400 bridges using cfg. 
sudo bin/start -n STP1 -m -w -c l2_stp_cfg l2_stp -H switch:dni-7448-xx 
2. Wait till system comes up. 
3. Please check switchd log and bcm info
cumulus_linux_poc CumulusLinux-1.5-RC1 Layer 2 (Segmentation)
RN-25 Management interface is down if a bridge with no ports is configured through the configuration file. This only affects Cumulus Linux POC. It has been fixed in a later release yet to be released. 

If a bridge is configured with no ports on it. 
The management port eth0, will not be able to get an IP address from DHCP because the interface is down, even if eth0 is configured in the /etc/network file. 

For example: 
The interface configuration file in /etc/network has eth0 configured as "auto" with DHCP on it: 
# The primary network interface 
auto eth0 
iface eth0 inet dhcp 

If you want to get an IP address on eth0, the interface needs to be brought up, and "sudo dhclient eth0" 

If the bridge has one port configured on it, then eth0 will be up and will be able to get an IP address from DHCP.
cumulus_linux_poc CumulusLinux-1.5-RC1 Layer 2 (Segmentation)
RN-42 user vlans are restricted to the range of 1-1999 Currently, user can only configure vlans in the fixed range of 1-1999. cumulus_linux_poc CumulusLinux-1.5-RC1 Layer 2 (Segmentation)
RN-39 Bridges, VLANs, and L3 routed interface limits on Cumulus Linux Currently, Cumulus linux "tested" limits (on Trident+ systems) are: 
200 bridges 
200 L3 interfaces (this includes 64 used for physical ports as well as routed sub-interfaces) 
200 VLANs
cumulus_linux_poc CumulusLinux-1.5-RC1 Layer 2 (Segmentation)
RN-20 software forwarding for IPv6 does not support multi path Currently, the kernel does not support multipath forwarding for IPv6. Issue is being worked for the initial release of cumulus linux. It will allow multipath functions like trace route to properly find/expose the various paths in IPv6. cumulus_linux_poc CumulusLinux-1.5-RC1 Layer 3 (Forwarding)
RN-66 Bond state in-correct on the link partner that is up. Assume the following: 

dut1:bond0:swp1/2=========2 cables==========swp1/2:bond0:dut2 

dut1 and dut2 are interconnected. 
on dut2 - ifconfig bond0 down. 
dut1 determines bond0 is down. 
dut1 does not inform upper layers that bond0 is down. 

example: ospfd on dut1 will still advertise on bond0, and essentially bond0 becomes a "blackhole"
CumulusLinux-1.5-RC1 CumulusLinux-1.5-RC2 Layer 3 (Forwarding)
RN-30 IP packets to a network broadcast address are routed IP packets with the network broadcast address (the network with the host bit all set to 1) is being routed to different interfaces. 

As an example - assume the following networks 11.0.1.0/24 and 11.0.2.0/24 are configured on the device. A host, 11.0.1.5, sends a IP packet with destination address of 11.0.2.255. The hosts on the 11.0.2.0/24 network are receiving these packets. 

Default behavior will be to disable this and a command to enable/disable will be added in the future.
CumulusLinux-1.5-RC1, cumulus_linux_poc CumulusLinux-1.5-RC2 Layer 3 (Forwarding)
RN-50 Packets exceeding the MTU size will be truncated If a packet is greater than the MTU size the packet will just be truncated to the MTU size and dropped. As a result the truncated packets are sent to the CPU but not as MTU failures, hence ICMP messages will not be generated. CumulusLinux-1.5-RC1 CumulusLinux-1.5-RC2 Layer 3 (Forwarding)
RN-8 SeqNum Wrapping Handling not supported in quagga OSPFv3 As specified in the OSPFv2/v3 RFC, when an LSA's sequence number reaches its maximum value, where the next increment would cause the number to wraparound, special handling must be triggered. Quagga OSPFv2 code has this handling, but OSPFv3 does not. This addition is being considered for future release of Quagga and Cumulus Linux cumulus_linux_poc CumulusLinux-1.5-RC1 Layer 3 (Routing)
RN-22 OSPFv3: Current multipath limit is set to 4 OSPFv3 currently has a #define OSPF6_MULTI_PATH_LIMIT that is set to 4. Its been verified in running a Nx2 topology that the maximum ECMP computed by OSPFv3 is 4. For reference, OSPFv2 does not even have such a #define. Enabling greater than 4 is enabled in a future Cumulus Linux version, but not the Cumulus Linux POC version. cumulus_linux_poc CumulusLinux-1.5-RC1 Layer 3 (Routing)
RN-6 Max-metric support needed in ospfv3 (quagga) Quagga's ospf6d doesn't support max-metric command. Without this command, graceful withdrawal from the network due to maintenance and other scheduled downtime may result in more network disruption. cumulus_linux_poc CumulusLinux-1.5-RC1 Layer 3 (Routing)
RN-34 system will not support 8000 /64 static IPv6 routes with ecmp If ECMP is set up for 8000 static /64 IPv6 routes, the system will not support the configuration in that the routes will not be distributed from the kernel to the switch ASIC. 

This issue is fixed in future release.
cumulus_linux_poc CumulusLinux-1.5-RC1 Layer 3 (Routing)
RN-28 In OSPFv3, ABR will not advertise the prefix until the backbone area refreshes the LSA if the non-backbone prefix is aged out. In an ABR if a prefix is learned from both the backbone and non-backbone area the ABR will not advertise the prefix until the backbone area refreshes the LSA if the non-backbone prefix is aged out. cumulus_linux_poc CumulusLinux-1.5-RC1 Layer 3 (Routing)
RN-23 OSPFv3: Support Stub and Totally Stubby Areas OSPFv3 doesn't support stub areas and totally stubby areas. This is fixed in a later version of Cumulus Linux - NOT in the POC release. cumulus_linux_poc CumulusLinux-1.5-RC1 Layer 3 (Routing)
RN-40 OSPFv3 needs support for the command "log-adjacency-changes detail" Currently, OSPFv3 doesn't support the command "log-adjacency-changes detail". OSPFv2 already has support for this. Cumulus will try enable this for OSPFv3 in Quagga. cumulus_linux_poc CumulusLinux-1.5-RC1 Layer 3 (Routing)
RN-57 Redistribute command does not accept a metric in ospf6 In Quagga, specifically ospf4, the following command - 
"redistribute static metric ##" works. 
However in OSPFv3 the metric option is not available, only 
"redistribute static" is allowed. 

In addition the default-metric option is available in OSPFv2 But NOT in OSPFv3. 

An alternative to using metric for OSPFv3 is to use route-map. Example: 
route-map foo permit 1 
set metric 10 
router ospf6 
redistribute static route-map foo
CumulusLinux-1.5-RC1 CumulusLinux-1.5-RC2 Layer 3 (Routing)
RN-51 quagga.conf is not supported If a user decides to put all his configuration in Quagga.conf, instead of individual daemon files, then ospfd and ospf6d fail to start. 

The quagga manual recommends that users write individual daemon configuration files rather than in a single integrated file.
CumulusLinux-1.5-RC1 CumulusLinux-1.5-RC2 Layer 3 (Routing)
RN-2 defunct processes (fan monitor and mgmtacl_check.s) Due to the current version of monit, unwanted zombie processes will remain in cumulus linux. In particular - fan_monitor, and mgmtacl. 

root 30167 616 0 12:24 ? 00:00:00 [fan_monitor.py] <defunct> 
root 30168 616 0 12:24 ? 00:00:00 [mgmtacl_check.s] <defunct> 

From the following: 
http://mmonit.com/monit/documentation/monit.html#program_status_testing

Requoted: 
The asynchronous nature of the program check allows for non-blocking behavior in the current Monit design, but it comes with a side-effect: when the program has finished executing and is waiting for Monit to collect the result, it becomes a so-called "zombie" process. A zombie process does not consume any system resources (only the PID remains in use) and it is under Monit's control; The zombie process is removed from the system as soon as Monit collects the exit status. This means that every "check program" will be associated with either a running process or a temporary zombie. This unwanted zombie side-effect will be removed in a later release of Monit.
cumulus_linux_poc CumulusLinux-1.5-RC1 Monitoring
RN-21 cl-sfputil does not pick up qsfp details on accton switches cl-sfputil does not properly provide QSFP details on accton switches. cumulus_linux_poc CumulusLinux-1.5-RC1 Tools
RN-14 cl-sfputil does not work for dni-7448 ganged ports. If 4 ports are "ganged" as a 40G port, cl-spfutil will only list the sfp details of the first port. cumulus_linux_poc CumulusLinux-1.5-RC1 Tools
RN-3 mgmtacltool needs to be extended to non-Trident chips and IPv6 The cl-mgmtacltool does not yet support IPv6 on any switch on the cumulus linux hardware compatibility list (HCL). 

The tool currently only supports the Trident family of products.
CumulusLinux-1.5-RC1, cumulus_linux_poc CumulusLinux-1.5-RC1 Tools
RN-11 IEEE 802.3 packets with length error are not included in ingress port packet counter When sending a L2 frame into the system, the packet counters in "ifconfig" for the ingress port do not reflect the correct number of packets. However, the byte counters are reporting the correct values. 


Packet being sent: 
sudo mz -v swp1 -c 100  

Output: 
cumulus@dni-7448-05$ sudo ifconfig swp1 
swp1 Link encap:Ethernet HWaddr 44:38:39:00:03:81 
inet6 addr: fe80::4638:39ff:fe00:381/64 Scope:Link 
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 
RX packets:143 errors:0 dropped:24 overruns:0 frame:0 
TX packets:419 errors:0 dropped:0 overruns:0 carrier:0 
collisions:0 txqueuelen:500 
RX bytes:46284 (45.1 KiB) TX bytes:39663 (38.7 KiB) 

cumulus@dni-7448-05$ sudo ifconfig swp1 
swp1 Link encap:Ethernet HWaddr 44:38:39:00:03:81 
inet6 addr: fe80::4638:39ff:fe00:381/64 Scope:Link 
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 
RX packets:155 errors:0 dropped:26 overruns:0 frame:0 
TX packets:467 errors:0 dropped:0 overruns:0 carrier:0 
collisions:0 txqueuelen:500 
RX bytes:54862 (53.5 KiB) TX bytes:43953 (42.9 KiB) 

counters have incremented by 7K, but the packet counts have only increased by 12.
cumulus_linux_poc CumulusLinux-1.5-RC1 Trouble Shooting
RN-37 debuginfo not available on all packages in cumulus linux Unfortunately none of the Cumulus Linux packages have the symbols package included. If debugging and/or symbol packages are needed, please contact Cumulus Support cumulus_linux_poc CumulusLinux-1.5-RC1 Trouble Shooting

 

 

 

 

Have more questions? Submit a request

Comments

Powered by Zendesk