A workaround preventing the issue has been implemented in BISDN Linux 3.5.2.
The driver for the PCI bus may report an error leading to the controller not receiving any traffic and causing the platform to completely stop working until restarted. This is a sporadic bug and can be verified by running dmesg where the following logs are available to confirm the presence of the error.
[...] pcieport 0000:00:01.0: AER: Uncorrected (Non-Fatal) error received: 0000:01:00.0 [...] linux-kernel-bde 0000:01:00.0: AER: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, (Requester ID) [...] linux-kernel-bde 0000:01:00.0: AER: device [14e4:b967] error status/mask=00004000/00000000 [...] linux-kernel-bde 0000:01:00.0: AER:  CmpltTO (First) [...] pcieport 0000:00:01.0: AER: Device recovery successful
AER: Device recovery successful shown above is misleading, since the Error can only be resolved by fully rebooting the switch itself.
There might be discrepancies in the maximum number of entries in the unicast routing table (30) announced by of-dpa and how many it accepts.
baseboxd is not compatible with Linux namespaces. Moving basebox’s interfaces to a namespace will duplicate them.
The script onie-bisdn-upgrade allows to use static IP configuration instead of DHCP. However, using the current ONIE installer, there is no route set towards the gateway, so images outside the configured network or, when using the “current” option, outside the switch management network (‘enp0s20f0’) can not be pulled and installed automatically.
Depending on the switch and the link partner, we have observed the following behaviors:
Intel X552 10 GbE SFP+ network cards do not support auto-negotiation. This causes the link to take more than 30 seconds to come up when the port is set to autonegotiation.
The 10G ports on AS4610 only support advertising 1G, so the speed will be limited to 1G regardless of the link partner’s ability.
The 25G ports on AG5648 only support advertising up to 10G, so the speed will be limited to 10G regardless of the link partner’s ability.
In all of these cases forcing the port on the switch to the desired speed works as expected.
As documented in the currently open upstream FRR issue #7299, some routes may get dropped or are not correctly received when ports are flapping during EIGRP session establishment. For now, we recommend the workaround of restarting FRR after all ports are up if this behavior is observed.