bisdn / basebox Goto Github PK
View Code? Open in Web Editor NEWA tiny OpenFlow controller for OF-DPA switches.
License: Mozilla Public License 2.0
basebox's People
Contributors
Stargazers
Watchers
basebox's Issues
Untagged packets on port without a PVID should be handled
Expected Behavior
If we recieve an untagged packet on a port where no pvid has been configured, we should expect the switch to drop the packet, and to get a log message.
Actual Behavior
file: src/netlink/nl_bridge.cc
786 // no vid, set vid to pvid
787 vid = br_vlan->pvid;
As you see we simply set the vid pvid, which might be 0 (or something else?)
Steps to Reproduce the Problem
Specifications
- Version: 1.9.20
- Platform: all
- Subsystem: all
baseboxd should properly cleanup behind itself on shutdown
Currently baseboxd just stops when receiving SIGTERM. This is fine when using tap interfaces, but when using knet interfaces this means they won't get cleaned up.
Unfortunately just trapping the SIGTERM doesn't work, as baseboxd will then continue trying to serve the port interfaces, which can cause crashes if a shutdown is in progress.
Likewise if OF-DPA is in shutting down at the same time, in-progress grpc/client_drivshell calls might indefinitely hang, since ofdpa has intentionally no timeouts.
So for being able to properly clean up behind itself, baseboxd should have a "shutdown" mode, where it won't process any netlink or packet-in/outs, and remove all port interfaces.
Once we have that working, we can extend this to even clean up created trunk interfaces and groups/flows.
vlan tagging: change to untagged is not reflected in the ASIC
Expected Behavior
When updating an access ports (port only with PVID) we must be able to configure the untagged parameter on the ASIC.
When checking the grouptables, we expect
groupId = 0x00020002 (L2 Interface, VLAN ID = 2, Port ID = 2): duration: 10, refCount:2
bucketIndex = 0: outputPort = 2 (Physical) *popVlanTag = 1* allowVlanTranslation = 0
Even if the interface was not initially configured with the popVlanTag/untagged.
Actual Behavior
If the interface is initially set without untagged, we cannot change this behaviour without deleting the port from the bridge and reconfiguring it.
Steps to Reproduce the Problem
Error script:
#!/bin/bash
ip link add name swbridge type bridge vlan_filtering 1 vlan_default_pvid 0
ip link set swbridge up
ip link set port2 master swbridge
ip link set port2 up
bridge vlan add vid 2 dev port2 pvid
bridge vlan add vid 2 dev swbridge self
Good script:
#!/bin/bash
ip link add name swbridge type bridge vlan_filtering 1 vlan_default_pvid 0
ip link set swbridge up
ip link set port2 master swbridge
ip link set port2 up
bridge vlan add vid 2 dev port2 pvid untagged
bridge vlan add vid 2 dev swbridge self
## Specifications
- Version: BISDN Linux v3.3.0
- Platform: accton-as4610
baseboxd exception with GLOG_v=5 caused by initial netlink message
Expected Behavior
baseboxd should not crash ...
Actual Behavior
An exception occurs when starting baseboxd with an increased logging verbosity level (GLOG_v >= 4), once the first netlink message is received from the underlying subsystems (kernel => netlink => libnl). The netlink message announces the loopback interface and causes the following exception:
I0604 14:07:31.449709 13 cnetlink.cc:578] handle_read_event: thread=cthread, tid: 139958419461888, num: 1, name: netlink
timers list is EMPTY
, fd=6
I0604 14:07:31.449949 13 cnetlink.cc:626] : cache=0x564db0178170, diff=2 action=5 old_obj=0x564db01a78c0 new_obj=0x7f4a94034d40
I0604 14:07:31.450075 13 nl_obj.cc:77] incremented refcounts nl_obj=0x564db01799b0 (old_obj=0x564db01a78c0 new_obj=0x7f4a94034d40)
I0604 14:07:31.450120 13 nl_obj.cc:13] created nl_obj=0x564db01799b0 (old_obj=0x564db01a78c0 new_obj=0x7f4a94034d40)
I0604 14:07:31.450181 13 cnetlink.cc:582] handle_read_event: #processed=1
I0604 14:07:31.450318 13 nl_l3.cc:116] operator() : found configured loopback (nl_obj=0x564db01abd30) 127.0.0.1/8 inet dev lo scope host <permanent>
label lo
valid-lifetime forever preferred-lifetime forever
created boot-time+1s 680msec last-updated boot-time+1s 680msec
I0604 14:07:31.450544 13 nl_bond.cc:35] get_lag_id: lag_id not found for if=1
--Type <RET> for more, q to quit, c to continue without paging--c
Thread 2 "netlink" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f4a9be01700 (LWP 13)]
0x0000564dae125367 in std::char_traits<char>::length (__s=0x0) at /usr/include/c++/9/bits/char_traits.h:335
335 return __builtin_strlen(__s);
(gdb) bt
#0 0x0000564dae125367 in std::char_traits<char>::length (__s=0x0)
at /usr/include/c++/9/bits/char_traits.h:335
#1 0x0000564dae293e84 in std::basic_string_view<char, std::char_traits<char> >::basic_string_view (this=0x7f4a9be003c0, __str=0x0)
at /usr/include/c++/9/string_view:124
#2 0x0000564dae2a2c15 in basebox::get_link_type (link=0x564db0197a30)
at ../src/netlink/netlink-utils.cc:70
#3 0x0000564dae2df620 in basebox::nl_vlan::get_vid (this=0x564db0174ff0,
link=0x564db0197a30) at ../src/netlink/nl_vlan.cc:322
#4 0x0000564dae2bc61d in basebox::nl_l3::add_l3_addr (this=0x564db0198a70,
a=0x564db01abd30) at ../src/netlink/nl_l3.cc:175
#5 0x0000564dae2bc1fd in basebox::nl_l3::init (this=0x564db0198a70)
at ../src/netlink/nl_l3.cc:125
#6 0x0000564dae2870ce in basebox::cnetlink::init_subsystems (
this=0x564db017a970) at ../src/netlink/cnetlink.cc:204
#7 0x0000564dae288fc2 in basebox::cnetlink::handle_wakeup (
this=0x564db017a970, thread=...) at ../src/netlink/cnetlink.cc:506
#8 0x00007f4a9cfec374 in rofl::cthread::handle_wakeup (this=0x564db017a980)
at /git/rofl-common/src/rofl/common/locking.hpp:47
#9 0x00007f4a9cfed095 in rofl::cthread::run_loop (this=0x564db017a980)
at cthread.cpp:732
#10 0x00007f4a9c815609 in start_thread (arg=<optimized out>)
at pthread_create.c:477
--Type <RET> for more, q to quit, c to continue without paging--c
#11 0x00007f4a9c73a293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Analysis
Refer to line 70 in src/netlink/netlink-utils.cc and to function call rtnl_link_get_family() which is causing the exception due to a NULL pointer in std::char_traits::length().
There is a test for detecting the loopback device lin line 74, so swapping the test and the actual logging may solve the issue.
Steps to Reproduce the Problem
- Start baseboxd with GLOG_v=5.
- Do not connect any switches.
- Wait for the first netlink messages to arrive.
Specifications
- Version: baseboxd 1.9.5
- Platform:
- Subsystem:
baseboxd: properly drop termination mac entry reference when removing l3 addresses from vlan interfaces
Disabling IPv6 does not properly delete flows&groups
Expected Behavior
Disabling IPv6 should remove flows in vlan table and termination_mac table. It also should remove the groups.
Actual Behavior
It only removes flows in termination_mac table.
Steps to Reproduce the Problem
Reboot, see groups and flows before and after:
sysctl net.ipv6.conf.all.disable_ipv6=1 && sysctl net.ipv6.conf.default.disable_ipv6=1
Specifications
- Version: baseboxd version 1.3.2, BISDN Linux 2.1.0
- Platform: AG7648
- Subsystem:
ECMP only supports previously configured/learned next-hops
Expected Behavior
The routes should be configured on the switch, even though the next hops are not learned.
Actual Behavior
Route is not configured on the switch, even after next-hop resolution. Leads to a break in kernel-switch state.
Steps to Reproduce the Problem
Configure the following route, while not having any nexthop.
ip route add $ECMP_ROUTE nexthop via $NEIX weight 1 nexthop via $NEIY weight 2
DHCP packets are not received by port interfaces
Expected Behavior
The dhcp client aquires a lease, and configures the port.
Actual Behavior
When running a dhcp client on a port interface, there dhcp client is unable to acquire a lease.
Steps to Reproduce the Problem
- run e.g. udhcpc -i port1
- connect port1 to a dhcp server.
Analysis
By default Broadcom ASICs do not foward DHCP packets to the switch, so we need to e.g. add a table 60 rule for DHCP(v6) packets to reach the switch.
Question: Using keepalived with option use_vmac
Do we can use keepalived with option use_vmac? Linux kernel has a macvlan feature, but I don't see anything about using macvlan in the documentation, makes me wondering does underlying chipset support vrrp using macvlan interface.
Assigned MACs are not used on data ports
Expected Behavior
There are reserved MAC-addresses (EEPROM) for the switch data ports, and one would expect the network devices to be assigned these MAC-addresses. Running 'ip link show port' show that the port has ben allocated th MAC-address from the Base-Mac burned on the EEPROM.
Actual Behavior
Running ip link show port1 gives the following ouput:
9: port1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 42:34:49:0b:88:9b brd ff:ff:ff:ff:ff:ff
Which is a pseudo-randomly generated MAC
Steps to Reproduce the Problem
Any freshly installed BISDN-Linux version
Specifications
- Version: any
- Platform: any
- Subsystem: not applicable
Forwarding QnQ traffic does not work
Expected Behavior
Configuring baseboxd to support QnQ tagged traffic with the following script: https://gist.github.com/rubensfig/0d629c04f43ac3bef480250994a2d874. Currently the C+S tag combination for stacked VLANs does not work. C+C tag stacked VLANs do not report any issues. The expected behaviour is that traffic would arrive to the outgoing interface with the 0x88a8 outer EtherType, and 0x8100 for the inner EtherType.
Actual Behavior
Feature not natively supported, the traffic is reaching the other interface with 0x8100 outer EtherType, and 0x8100 for the inner EtherType.
Steps to Reproduce the Problem
Run the above linked script on a switch and controller, and start pinging. The traffic will not be arriving at the correct interface (enp5s0f1) with the correct EtherTypes.
Specifications
- Version: 0.18
- Platform: BISDN Linux (switch)
Bridge Ageing Time Configuration
Expected Behavior
change and affect default value (300) of aging time.
Actual Behavior
Changing the aging time has no effect on TBD system. It stuck at its default value 300 seconds.
Steps to Reproduce the Problem
Platform:
TBD, Linux 5.15.90-yocto-standard-onl armv7l GNU/Linux
Procedure:
$ ip -p -d -j link show vbr0 | grep "ageing_time" "ageing_time": 30000,
$ sudo ip link set dev vbr0 type bridge ageing_time 2000
$ ip -p -d -j link show vbr0 | grep "ageing_time"
"ageing_time": 2000,
$ sudo bridge fdb del 00:0b:ab:63:ef:89 dev eth1 master vlan 1
$ sudo bridge -s fdb show br vbr0 dev eth1 state dynamic
$
$ ping 192.168.1.2 -c 2
84 bytes from 192.168.1.2 icmp_seq=1 ttl=64 time=0.524 ms
84 bytes from 192.168.1.2 icmp_seq=2 ttl=64 time=0.648 ms
$ while sleep 1; do sudo bridge -s fdb show br vbr0 dev eth1 state dynamic; done
00:0b:ab:63:ef:89 dev eth1 vlan 1 used 0/0 extern_learn master vbr0
00:0b:ab:63:ef:89 dev eth1 vlan 1 used 1/0 extern_learn master vbr0
00:0b:ab:63:ef:89 dev eth1 vlan 1 used 2/0 extern_learn master vbr0
00:0b:ab:63:ef:89 dev eth1 vlan 1 used 3/1 extern_learn master vbr0
00:0b:ab:63:ef:89 dev eth1 vlan 1 used 4/2 extern_learn master vbr0
00:0b:ab:63:ef:89 dev eth1 vlan 1 used 5/3 extern_learn master vbr0
00:0b:ab:63:ef:89 dev eth1 vlan 1 used 6/4 extern_learn master vbr0
00:0b:ab:63:ef:89 dev eth1 vlan 1 used 7/5 extern_learn master vbr0
00:0b:ab:63:ef:89 dev eth1 vlan 1 used 8/6 extern_learn master vbr0
00:0b:ab:63:ef:89 dev eth1 vlan 1 used 9/7 extern_learn master vbr0
00:0b:ab:63:ef:89 dev eth1 vlan 1 used 10/8 extern_learn master vbr0
00:0b:ab:63:ef:89 dev eth1 vlan 1 used 11/9 extern_learn master vbr0
00:0b:ab:63:ef:89 dev eth1 vlan 1 used 12/10 extern_learn master vbr0
00:0b:ab:63:ef:89 dev eth1 vlan 1 used 14/11 extern_learn master vbr0
00:0b:ab:63:ef:89 dev eth1 vlan 1 used 15/12 extern_learn master vbr0
00:0b:ab:63:ef:89 dev eth1 vlan 1 used 16/14 extern_learn master vbr0
00:0b:ab:63:ef:89 dev eth1 vlan 1 used 17/15 extern_learn master vbr0
00:0b:ab:63:ef:89 dev eth1 vlan 1 used 18/16 extern_learn master vbr0
00:0b:ab:63:ef:89 dev eth1 vlan 1 used 19/17 extern_learn master vbr0
00:0b:ab:63:ef:89 dev eth1 vlan 1 used 20/18 extern_learn master vbr0
00:0b:ab:63:ef:89 dev eth1 vlan 1 used 21/19 extern_learn master vbr0
...
00:0b:ab:63:ef:89 dev eth1 vlan 1 used 69/67 extern_learn master vbr0
00:0b:ab:63:ef:89 dev eth1 vlan 1 used 70/68 extern_learn master vbr0
00:0b:ab:63:ef:89 dev eth1 vlan 1 used 71/69 extern_learn master vbr0
00:0b:ab:63:ef:89 dev eth1 vlan 1 used 72/70 extern_learn master vbr0
00:0b:ab:63:ef:89 dev eth1 vlan 1 used 73/71 extern_learn master vbr0
...
00:0b:ab:63:ef:89 dev eth1 vlan 1 used 297/295 extern_learn master vbr0
00:0b:ab:63:ef:89 dev eth1 vlan 1 used 298/296 extern_learn master vbr0
00:0b:ab:63:ef:89 dev eth1 vlan 1 used 299/297 extern_learn master vbr0
00:0b:ab:63:ef:89 dev eth1 vlan 1 used 300/298 extern_learn master vbr0
00:0b:ab:63:ef:89 dev eth1 vlan 1 used 301/299 extern_learn master vbr0
00:0b:ab:63:ef:89 dev eth1 vlan 1 used 302/300 extern_learn master vbr0
00:0b:ab:63:ef:89 dev eth1 vlan 1 used 303/301 extern_learn master vbr0
Expected Results:
After 20 seconds The entry is cleaned up
Actual Results:
After 300 seconds The entry is cleaned up
And in result of command ‘brctl showstp swbridge’ , show new value of agin time that we set, but not
functionality.
Specifications
- Version: 4.8.3
- Platform: accton as4610
- Subsystem: ofdpa
Adding a FDB entry to a enslaved port crashes basebox
Expected Behavior
A fdb entry should be added when running the bridge fdb add ... command.
Actual Behavior
Basebox crashes:
Nov 02 11:29:40 agema-ag7648 baseboxd[4630]: E1102 11:29:40.611450 4631 nl_vxlan.cc:1352] add_l2_neigh: could not find vxlan port details to add neigh bridge dev port7 lladdr 00:00:00:01:00:01 swbridge <noarp,permanent,self>
Nov 02 11:29:40 agema-ag7648 baseboxd[4630]: , lport=0, tunnel_id=0
Nov 02 11:29:40 agema-ag7648 baseboxd[4630]: I1102 11:29:40.611536 4631 nl_bridge.cc:650] add_neigh_to_fdb: add mac=<caddress_ll 00:00:00:01:00:01 >
Nov 02 11:29:40 agema-ag7648 baseboxd[4630]: to bridge swbridge on port=7 vlan=4294967295, permanent=1
Nov 02 11:29:40 agema-ag7648 baseboxd[4630]: I1102 11:29:40.611588 4631 nl_bridge.cc:653] add_neigh_to_fdb: object: bridge dev port7 lladdr 00:00:00:01:00:01 swbridge <noarp,permanent,self,master>
Nov 02 11:29:40 agema-ag7648 baseboxd[4630]: baseboxd: ../../git/lib/rofl_ofdpa_fm_driver.cpp:2023: rofl::openflow::cofflowmod rofl::openflow::rofl_ofdpa_fm_driver::add_bridging_unicast_vlan(uint8_t, uint32_t, uint16_t, const cmacaddr&, bool, bool): Assertion `vid < 0x1000' failed.
Nov 02 11:29:42 agema-ag7648 systemd[1]: baseboxd.service: Main process exited, code=killed, status=6/ABRT
Nov 02 11:29:42 agema-ag7648 systemd[1]: baseboxd.service: Failed with result 'signal'.
Nov 02 11:29:42 agema-ag7648 systemd[1]: baseboxd.service: Service RestartSec=100ms expired, scheduling restart.
Nov 02 11:29:42 agema-ag7648 systemd[1]: baseboxd.service: Scheduled restart job, restart counter is at 6.
Nov 02 11:29:42 agema-ag7648 systemd[1]: Stopped baseboxd.
Steps to Reproduce the Problem
Example to trigger the crash:
#!/usr/bin/env bash
BRIDGE_NAME=swbridge
BNG_DP_PORT=port7
BNG_VID=100
BNG_DOWNSTREAM_MAC=00:00:00:01:00:01
## Delete and add bridge
ip link del $BRIDGE_NAME
ip link add $BRIDGE_NAME type bridge vlan_filtering 1 vlan_default_pvid 0
## VLANs that are processed by the bridge
bridge vlan add vid $BNG_VID dev $BRIDGE_NAME self
## Add ports to bridge
ip link set $BNG_DP_PORT master $BRIDGE_NAME # BNG data plane
## Add VLANs to ports
bridge vlan add vid $BNG_VID dev $BNG_DP_PORT pvid egress untagged
## Add forwarding entry
bridge fdb add $BNG_DOWNSTREAM_MAC dev $BNG_DP_PORT
Specifications
- Version: Basebox 1.8.3-r0, BISDN Linux 3.5.1
- Platform: agema-ag7648
- Subsystem:
VxLAN tunneled packets are always untagged
Expected Behavior
Packets within a VXLAN keep their VLAN tag when the vxlan interface is set as tagged.
Actual Behavior
Packets are transmitted untagged.
Steps to Reproduce the Problem
Follow the VXLAN example, look at the packets sent by the switch on the vxlan port (port54 in the example).
Specifications
- Version: BISDN Linux 5.0
- Platform: agema-ag7648
- Subsystem: baseboxd
OFDPA fielad for Usage (STG)
Expected Behavior
MSTPD handle loops in scenario.
Actual Behavior
Generated loop in scenario and I got folowing logs:
Apr 28 17:54:45 SW ofdpa[1612]: stg default [<id>] - Show or set the default STG
Apr 28 17:54:45 SW ofdpa[1612]: driverProcessCommand: Platform command "stg stp 2 0 block" failed, rc = -2.
Apr 28 17:54:45 SW ofdpa[1612]:
Apr 28 17:54:45 SW ofdpa[1612]: Usage (STG): Usages:
Apr 28 17:54:45 SW ofdpa[1612]: stg create [<id>] - Create a STG; optionally specify ID
Apr 28 17:54:45 SW ofdpa[1612]: stg destroy <id> - Destroy a STG
Apr 28 17:54:45 SW ofdpa[1612]: stg show [<id>] - List STG(s)
Apr 28 17:54:45 SW ofdpa[1612]: stg add <id> <vlan_id> [...] - Add VLAN(s) to a STG
Apr 28 17:54:45 SW ofdpa[1612]: stg remove <id> <vlan_id> [...] - Remove VLAN(s) from a STG
Apr 28 17:54:45 SW ofdpa[1612]: stg stp - Get span tree state, all ports/STGs
Apr 28 17:54:45 SW ofdpa[1612]: stg stp <id> - Get span tree state of ports in STG
Apr 28 17:54:45 SW ofdpa[1612]: stg stp <id> <pbmp> <state> - Set span tree state of ports in STG
Apr 28 17:54:45 SW ofdpa[1612]: (disable/block/listen/learn/forward)
Apr 28 17:54:45 SW ofdpa[1612]: stg default [<id>] - Show or set the default STG
Apr 28 17:54:45 SW ofdpa[1612]: driverProcessCommand: Platform command "stg stp 2 0 block" failed, rc = -2.
and
Apr 28 18:00:58 Z8 kernel: bcm-iproc-i2c 1803b000.i2c: transaction timed out
Apr 28 18:00:58 Z8 kernel: bcm-iproc-i2c 1803b000.i2c: bus is busy
Apr 28 18:00:58 Z8 kernel: bcm-iproc-i2c 1803b000.i2c: bus is busy
Apr 28 18:00:58 Z8 kernel: bcm-iproc-i2c 1803b000.i2c: bus is busy
Apr 28 18:00:58 Z8 kernel: bcm-iproc-i2c 1803b000.i2c: bus is busy
Apr 28 18:00:59 Z8 kernel: bcm-iproc-i2c 1803b000.i2c: bus is busy
Apr 28 18:00:59 Z8 kernel: bcm-iproc-i2c 1803b000.i2c: bus is busy
Apr 28 18:00:59 Z8 kernel: bcm-iproc-i2c 1803b000.i2c: bus is busy
Apr 28 18:00:59 Z8 kernel: bcm-iproc-i2c 1803b000.i2c: bus is busy
Apr 28 18:00:59 Z8 kernel: bcm-iproc-i2c 1803b000.i2c: bus is busy
Apr 28 18:00:59 Z8 kernel: bcm-iproc-i2c 1803b000.i2c: bus is busy
A
Steps to Reproduce the Problem
sudo ip link add swbridge type bridge vlan_filtering 1 vlan_default_pvid 0 stp_state 1
sudo ip link set swbridge up
scenario:
port1_________port1
SW1 SW2
| port2_________port2 |
| |
| |
| |
| |
port4______SW3_____port3
sudo ip link add swbridge type bridge vlan_filtering 1 vlan_default_pvid 0 stp_state 1
sudo ip link set swbridge up
for i in {1..4}
do
sudo ip link set port${i} master swbridge
sudo bridge vlan add vid 1 dev port${i} pvid untagged
sudo bridge vlan add vid 1 dev swbridge self
sudo ip link set up dev port${i}
done
sudo systemctl start mstpd
sudo mstpctl addbridge swbridge
sudo systemctl restart mstpd
sudo ip link set swbridge type bridge stp_state 0
sudo ip link set swbridge type bridge stp_state 1
sudo systemctl restart mstpd
sudo mstpctl setforcevers swbridge stp
FW _________ FW*
SW1 SW2
| FW _________ BLK|
FW| |BLK
| |
| |
| |
|___(FW*)SW3(FW)_____|
After determining the role(forward and block) to interfaces by MSTPD,Remove the interfaces specified by FW* from the bridge and assign them ip address. and try ping between them.
SW2:
sudo ip link set dev port1 nomaster
sudo ip add add 2.2.2.1/24 dev port1
sudo ip link set up port1
SW3:
sudo ip link set dev port4 nomaster
sudo ip add add 2.2.2.4/24 dev port4
sudo ip link set up port4
ping 2.2.2.1
the simple loop in generated.and if you send among traffic, mstpd will crash and then above logs will appear.
Specifications
- Version: 4.8.3
- Platform: accton as461054T
- Subsystem:ofdpa
Removing a neighbor from an SVI entry does not remove its L3 group table entry
Expected Behavior
The L3 group entry should be removed after deleting the neighbor entry.
Actual Behavior
The group entry remains listed when running client_grouptable_dump. I suspect this is related to how l3_interface_id mapping keys are manipulated when deleting L3 egress entries, similar to #275
Steps to Reproduce the Problem
To configure a switch bridge with a SVI and a neighbor entry:
BRIDGE_NAME=swbridge
BNG_DP_PORT=port50
BNG_VID=100
BNG_PORT_SVI_NAME="$BRIDGE_NAME.$BNG_VID"
BNG_PORT_SVI_MAC=aa:bb:cc:dd:ee:1a
BNG_PORT_SVI_IP="10.1.1.1/24"
BNG_PORT_SVI_NEXTHOP_IP="10.1.1.2"
BNG_IP_POOL_NET="192.51.0.0/16"
BNG_DOWNSTREAM_MAC=00:00:00:01:00:01
## Add bridge
ip link add $BRIDGE_NAME type bridge vlan_filtering 1 vlan_default_pvid 0
## VLANs that are processed by the bridge
bridge vlan add vid $BNG_VID dev $BRIDGE_NAME self
## Add ports to bridge
ip link set $BNG_DP_PORT master $BRIDGE_NAME # BNG data plane
## Add VLANs to ports
# Set PVIDs to BNG and UPLINK ports
bridge vlan add vid $BNG_VID dev $BNG_DP_PORT pvid egress untagged
## Add SVIs
# BNG port
ip link add link $BRIDGE_NAME name $BNG_PORT_SVI_NAME type vlan id $BNG_VID
## Set IP addresses
# BNG port
ip a a $BNG_PORT_SVI_IP dev $BNG_PORT_SVI_NAME
## Ports up
ip link set $BRIDGE_NAME up
ip link set $BNG_PORT_SVI_NAME up
ip link set $BNG_DP_PORT up
# Forwarding entry to BNG_DOWNSTREAM_MAC via the BNG port
bridge fdb add $BNG_DOWNSTREAM_MAC dev $BNG_DP_PORT master vlan $BNG_VID
# Add IP neighbor entry
ip neighbor add $BNG_PORT_SVI_NEXTHOP_IP lladdr $BNG_DOWNSTREAM_MAC dev $BNG_PORT_SVI_NAME
Deleting the entry afterwards:
ip neighbor del $BNG_PORT_SVI_NEXTHOP_IP lladdr $BNG_DOWNSTREAM_MAC dev $BNG_PORT_SVI_NAME
client_grouptable_dump output still shows the group entry:
groupId = 0x20000001 (L3 Unicast, Index = 1): duration: 27, refCount:0
bucketIndex = 0: referenceGroupId = 0x00640032 vlanId = 0x1064 (VLAN 100) srcMac: 92:E5:8B:46:2A:A5 dstMac: 00:00:00:01:00:01
Specifications
- Version: Basebox 1.8.3-r0, BISDN Linux 3.5.1
- Platform: agema-ag7648
- Subsystem:
IPv6 flood correlating with bpdus not being received
Expected Behavior
When a switch has a bridge configured with ports and xSTP is enabled at the bridge, both the Kernel and mstpd must be able to block the correct port, considering correct configuration.
Actual Behavior
With the configuration described above, baseboxd is sometimes failing to receive the required Bridge PDUs to set STP state. This is due to IPv6 MLD packets being flooded, overflowing the OpenFlow channel and impeding baseboxd to receive the relevant traffic. This can be solved by removing the FF02: ACL rule.
Steps to Reproduce the Problem
ip link add name swbridge type bridge vlan_filtering 1 stp_state 1
ip link set port1 master swbridge
ip link set port2 master swbridge
ip link set port1 up
ip link set port2 up
ip link set swbridge up
Specifications
- Version: 1.9.2
- Platform: All
- Subsystem: STP
PVID Egress untagged bug using systemd-networkd
Expected Behavior
Seeing output of "bridge vlan":
swbridge 1 PVID Egress Untagged
15
4090
port1 1 Egress Untagged
15 PVID Egress Untagged
you would expect newVlanId = 0x100f (VLAN 15) set in the switche's flowtable
-- inPort = 1 (Physical) vlanId:mask = 0x0000:0x1fff (VLAN 0) | GoTo = 20 (Termination MAC) newVlanId = 0x100f (VLAN 15) | priority = 3 hard_time = 0 idle_time = 0 cookie = 10
Actual Behavior
in some cases it does not set newVlanId = 0x100f (VLAN 15) but newVlanId = 0x1001 (VLAN 1) instead
-- inPort = 1 (Physical) vlanId:mask = 0x0000:0x1fff (VLAN 0) | GoTo = 20 (Termination MAC) newVlanId = 0x1001 (VLAN 1) | priority = 3 hard_time = 0 idle_time = 0 cookie = 19
Steps to Reproduce the Problem
copy the attached systemd-networkd configuration files to /etc/systemd/network and reboot the switch
network.zip
Specifications
-
Version:
baseboxd version 1.1.1 -
Platform:
ID="bisdn-linux"
NAME="BISDN Linux"
VERSION="19.06 (Marinara)"
VERSION_ID="19.06"
PRETTY_NAME="BISDN Linux 19.06 (Marinara)"
BUILD_ID="20191121222227" -
Subsystem:
BGP routes are not getting cleared in the ASIC tables under stress tests
Expected Behavior
When adding multiple (>1000) routes over BGP, the installed routes should all disappear after the remote peer disconnects.
Before BGP peer is started
172.16.111.1 dev enp0 proto dhcp scope link src 172.16.111.15 metric 10
accton-as4610:/home/basebox# ip r | wc -l
7
accton-as4610:/home/basebox# client_flowtable_dump 30 | head
Table ID 30 (Unicast Routing): Retrieving all entries. Max entries = 32768, Current entries = 7.
After BGP peer is started
accton-as4610:/home/basebox# ip r | wc -l
2048
accton-as4610:/home/basebox# client_flowtable_dump 30 | head
Table ID 30 (Unicast Routing): Retrieving all entries. Max entries = 32768, Current entries = 2048.
After BGP peer is stopped
accton-as4610:/home/basebox# ip r | wc -l
7
accton-as4610:/home/basebox# client_flowtable_dump 30 | head
Table ID 30 (Unicast Routing): Retrieving all entries. Max entries = 32768, Current entries = 7.
Actual Behavior
The routes disappear in the kernel, but are maintained in the ASIC, leading to misconfiguration.
Steps to Reproduce the Problem
Setup BGP on a BISDN Linux and a server. The server announces multiple (>1000) routes, wait for BGP to converge, and stop the daemon after.
Before BGP peer is started
accton-as4610:/home/basebox# client_flowtable_dump 30 | head
Table ID 30 (Unicast Routing): Retrieving all entries. Max entries = 32768, Current entries = 6.
-- etherType = 0x0800 vrf:mask = 0x0000:0x0000 dstIp4 = 10.0.0.0/255.255.255.0 dstIp6 = ::/:: | GoTo = 60 (ACL Policy) outPort = CONTROLLER (Reserved) | priority = 2 hard_time = 0 idle_time = 0 cookie = 16
-- etherType = 0x0800 vrf:mask = 0x0000:0x0000 dstIp4 = 10.0.0.1/255.255.255.255 dstIp6 = ::/:: | GoTo = 60 (ACL Policy) groupId = 0x20000001 | priority = 3 hard_time = 0 idle_time = 0 cookie = 19
accton-as4610:/home/basebox# ip r
10.0.2.0/24 dev port2 proto kernel scope link src 10.0.2.1
After BGP peer is started, and BGP convergence achieved.
accton-as4610:/home/basebox# ip r | wc -l
2048
client_flowtable_dump 30 | head
Table ID 30 (Unicast Routing): Retrieving all entries. Max entries = 32768, Current entries = 2045.
After BGP is stopped,
accton-as4610:/home/basebox# client_flowtable_dump 30 | head
Table ID 30 (Unicast Routing): Retrieving all entries. Max entries = 32768, Current entries = 563.
accton-as4610:/home/basebox# ip r | wc -l
7
This shows that not all routes are correctly learned in the first place, and deletion does not accurately work either.
Specifications
- Version: BISDN Linux v3.7.2
- Platform: accton-as4610
- Subsystem: l3
VxLAN packets are encapsulated with an outer VLAN tag with VID 1 on Trident3
Expected Behavior
There is no outer VLAN tag on VxLAN packets unless explicitly configured.
Actual Behavior
On Trident3, there is an outer VLAN tag on VxLAN packets.
Steps to Reproduce the Problem
Create a VxLAN tunnel, try to send packets over it. When looking at them form the other side, there will be a VLAN tag added to them, while non-VxLAN packets are correctly untagged:
08:07:48.026027 f8:8e:a1:e0:bb:14 > 90:e2:ba:61:16:50, ethertype 802.1Q (0x8100), length 114: vlan 1, p 0, ethertype IPv4, (tos 0x0, ttl 45, id 50, offset 0, flags [none], proto UDP (17), length 96)
192.168.0.2.54443 > 192.168.0.1.4789: VXLAN, flags [I] (0x08), vni 50000
f8:8e:a1:e0:83:49 > 90:e2:ba:61:13:a0, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.0.1 tell 10.0.0.2, length 46
08:07:49.060756 f8:8e:a1:e0:bb:14 > 90:e2:ba:61:16:50, ethertype 802.1Q (0x8100), length 114: vlan 1, p 0, ethertype IPv4, (tos 0x0, ttl 45, id 51, offset 0, flags [none], proto UDP (17), length 96)
192.168.0.2.54443 > 192.168.0.1.4789: VXLAN, flags [I] (0x08), vni 50000
f8:8e:a1:e0:83:49 > 90:e2:ba:61:13:a0, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.0.1 tell 10.0.0.2, length 46
08:07:50.094093 f8:8e:a1:e0:bb:14 > 90:e2:ba:61:16:50, ethertype 802.1Q (0x8100), length 114: vlan 1, p 0, ethertype IPv4, (tos 0x0, ttl 45, id 52, offset 0, flags [none], proto UDP (17), length 96)
192.168.0.2.54443 > 192.168.0.1.4789: VXLAN, flags [I] (0x08), vni 50000
f8:8e:a1:e0:83:49 > 90:e2:ba:61:13:a0, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.0.1 tell 10.0.0.2, length 46
...
08:08:20.585970 90:e2:ba:61:16:50 > f8:8e:a1:e0:bb:14, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.2 tell 192.168.0.1, length 28
08:08:20.586112 f8:8e:a1:e0:bb:14 > 90:e2:ba:61:16:50, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 192.168.0.2 is-at f8:8e:a1:e0:bb:14, length 46
Specifications
- Version: 5.0.0
- Platform: cel-questone-2a, as5835-54x tested, as7726-32x and as4630-54pe likely affected as well
- Subsystem: ofdpa
[forwarding] Route not being installed properly into the flowtable
Expected Behavior
In forwarding scenario, adding static route to the network behing neighboring router should result in adding proper route to the flowtable.
Actual Behavior
The actual route, although installed in kernel, is not added into the flowtable.
Steps to Reproduce the Problem
Topo:
PC1 <--192.168.7.1-----------------192.168.7.2--> ROUTER <--192.168.2.2-------------192.168.2.1 -->/port2/ SWITCH /port4/ <--192.168.4.1----------192.168.4.2--> PC2
The script that should work, but does not:
#!/bin/sh
ifconfig port2 192.168.2.1/24 up
ifconfig port4 192.168.4.1/24 up
echo 1 > /proc/sys/net/ipv4/conf/port2/forwarding
echo 1 > /proc/sys/net/ipv4/conf/port4/forwarding
route add -net 192.168.7.0/24 gw 192.168.2.2
The script that does work:
#!/bin/sh
ifconfig port2 192.168.2.1/24 up
ifconfig port4 192.168.4.1/24 up
echo 1 > /proc/sys/net/ipv4/conf/port2/forwarding
echo 1 > /proc/sys/net/ipv4/conf/port4/forwarding
route add -host 192.168.7.1 gw 192.168.2.2
route del 192.168.7.1
ping -c1 192.168.2.2
ping -c1 192.168.4.2
route add -host 192.168.7.1 gw 192.168.2.2
Specifications
- Platform: ONL/arm/edgecore as4610
Termination MAC entries not being removed after changing SVI MAC address
Expected Behavior
Following a routed vlan bridge setup, I considered the following setup.
Where swbridge.10: 10.0.1.1/24 and MAC address AA:BB:CC:DD:EE:FF.
Flowtable 20 will have the following entry
-- inPort:mask = 0:0x0 etherType = 0x0800 destMac:mask = AABB.CCDD.EEFF:ffff.ffff.ffff vlanId:mask = 0x100a:0x1fff (VLAN 10) | GoTo = 30 (Unicast Routing) outPort = 0 (Physical) | priority = 2 hard_time = 0 idle_time = 0 cookie = 30
-- inPort:mask = 0:0x0 etherType = 0x86dd destMac:mask = AABB.CCDD.EEFF:ffff.ffff.ffff vlanId:mask = 0x100a:0x1fff (VLAN 10) | GoTo = 30 (Unicast Routing) outPort = 0 (Physical) | priority = 2 hard_time = 0 idle_time = 0 cookie = 31
After changing the MAC address to 02:00:00:00:00:01, we see the following entries in the same table
-- inPort:mask = 0:0x0 etherType = 0x0800 destMac:mask = 0200.0000.0001:ffff.ffff.ffff vlanId:mask = 0x100a:0x1fff (VLAN 10) | GoTo = 30 (Unicast Routing) outPort = 0 (Physical) | priority = 2 hard_time = 0 idle_time = 0 cookie = 30
-- inPort:mask = 0:0x0 etherType = 0x86dd destMac:mask = 0200.0000.0001:ffff.ffff.ffff vlanId:mask = 0x100a:0x1fff (VLAN 10) | GoTo = 30 (Unicast Routing) outPort = 0 (Physical) | priority = 2 hard_time = 0 idle_time = 0 cookie = 31
Deleting the IP address should remove the IPv4 entry thus showing
-- inPort:mask = 0:0x0 etherType = 0x86dd destMac:mask = 0200.0000.0001:ffff.ffff.ffff vlanId:mask = 0x100a:0x1fff (VLAN 10) | GoTo = 30 (Unicast Routing) outPort = 0 (Physical) | priority = 2 hard_time = 0 idle_time = 0 cookie = 31
Deleting the Ipv6 link local address should not show any entry wrt to this VLAN
Actual Behavior
The following entries are seen post MAC address change and deletion, meaning the entries are being mantained.
-- inPort:mask = 0:0x0 etherType = 0x0800 destMac:mask = 0200.0000.0001:ffff.ffff.ffff vlanId:mask = 0x100a:0x1fff (VLAN 10) | GoTo = 30 (Unicast Routing) outPort = 0 (Physical) | priority = 2 hard_time = 0 idle_time = 0 cookie = 30
-- inPort:mask = 0:0x0 etherType = 0x86dd destMac:mask = 0200.0000.0001:ffff.ffff.ffff vlanId:mask = 0x100a:0x1fff (VLAN 10) | GoTo = 30 (Unicast Routing) outPort = 0 (Physical) | priority = 2 hard_time = 0 idle_time = 0 cookie = 31
Before and after the deletion on the IP address. This leads me to think that there is a broken interaction between this code path and
Line 1225 in 5805132
Similarly, flushing the IPv6 link local address does not remove the entry on the table.
Steps to Reproduce the Problem
Specifications
- Version:
- Platform:
- Subsystem:
How set autoneg for interfaces
Expected Behavior
be same below result for autoneg value for interfaces
client_drivshell command
Accton:~$ sudo client_drivshell ps
Calling ofdpaBcmCommand rpc with command = "ps ".
Returned from ofdpaBcmCommand rpc with rc = 0.
File logging started to /tmp/.drivshell-output
ena/ speed/ link auto STP lrn inter max loop
port link duplex scan neg? state pause discrd ops face frame back
ge0( 26) up 1G FD SW Yes Forward None FAC SGMII 16356
ge1( 25) up 1G FD SW Yes Forward None FAC SGMII 16356
.
.
.
and ethtool command
Accton:~$ sudo ethtool port1
Settings for port1:
Supported ports: [ ]
Supported link modes: Not reported
Supported pause frame use: No
Supports auto-negotiation: No
Supported FEC modes: Not reported
Advertised link modes: Not reported
Advertised pause frame use: No
Advertised auto-negotiation: No
Advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Auto-negotiation: off
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
MDI-X: Unknown
Link detected: yes
and we got error for set on with ethtool
Accton:~$ sudo ethtool -s port1 autoneg "on"
netlink error: Operation not supported
Actual Behavior
Steps to Reproduce the Problem
Specifications
- Version:4.8.3
- Platform:accton as461054T
- Subsystem:
Routes added through a known next hop are sent to the controller
Expected Behavior
When adding a route with e.g. ip route add X via Y, if gateway Y is known by basebox, the corresponding table 30 entry of that route should be directed to the same group:
Table ID 30 (Unicast Routing): Retrieving all entries. Max entries = 32768, Current entries = 3.
-- etherType = 0x0800 vrf:mask = 0x0000:0x0000 dstIp4 = 10.1.1.0/255.255.255.0 dstIp6 = ::/:: | GoTo = 60 (ACL Policy) outPort = CONTROLLER (Reserved) | priority = 2 hard_time = 0 idle_time = 0 cookie = 10
-- etherType = 0x0800 vrf:mask = 0x0000:0x0000 dstIp4 = 10.1.1.2/255.255.255.255 dstIp6 = ::/:: | GoTo = 60 (ACL Policy) groupId = 0x20000001 | priority = 3 hard_time = 0 idle_time = 0 cookie = 13
-- etherType = 0x0800 vrf:mask = 0x0000:0x0000 dstIp4 = 192.51.0.0/255.255.0.0 dstIp6 = ::/:: | GoTo = 60 (ACL Policy) groupId = 0x20000001 | priority = 2 hard_time = 0 idle_time = 0 cookie = 14
Working example
#!/usr/bin/env bash
BRIDGE_NAME=swbridge
BNG_DP_PORT=port50
BNG_VID=100
BNG_PORT_SVI_NAME="$BRIDGE_NAME.$BNG_VID"
BNG_PORT_SVI_IP="10.1.1.1/24"
BNG_PORT_SVI_NEXTHOP_IP="10.1.1.2"
BNG_IP_POOL_NET="192.51.0.0/16"
BNG_DOWNSTREAM_MAC=00:00:00:01:00:01
## Delete and add bridge
ip link del $BRIDGE_NAME
ip link add $BRIDGE_NAME type bridge vlan_filtering 1 vlan_default_pvid 0
## VLANs that are processed by the bridge
bridge vlan add vid $BNG_VID dev $BRIDGE_NAME self
## Add ports to bridge
ip link set $BNG_DP_PORT master $BRIDGE_NAME # BNG data plane
## Add VLANs to ports
# Set PVIDs to BNG and UPLINK ports
bridge vlan add vid $BNG_VID dev $BNG_DP_PORT pvid egress untagged
## Add SVIs
# BNG port
ip link add link $BRIDGE_NAME name $BNG_PORT_SVI_NAME type vlan id $BNG_VID
## Set IP addresses
# BNG port
ip a a $BNG_PORT_SVI_IP dev $BNG_PORT_SVI_NAME
## Ports up
ip link set $BRIDGE_NAME up
ip link set $BNG_PORT_SVI_NAME up
ip link set $BNG_DP_PORT up
# Forwarding entry to BNG_DOWNSTREAM_MAC via the BNG port
bridge fdb add $BNG_DOWNSTREAM_MAC dev $BNG_DP_PORT master vlan $BNG_VID
# Add IP neighbor entry
ip neighbor add $BNG_PORT_SVI_NEXTHOP_IP lladdr $BNG_DOWNSTREAM_MAC dev $BNG_PORT_SVI_NAME
# Add route
ip route add $BNG_IP_POOL_NET via $BNG_PORT_SVI_NEXTHOP_IP
Actual Behavior
The route is sent to controller instead:
Table ID 30 (Unicast Routing): Retrieving all entries. Max entries = 32768, Current entries = 3.
-- etherType = 0x0800 vrf:mask = 0x0000:0x0000 dstIp4 = 10.1.1.0/255.255.255.0 dstIp6 = ::/:: | GoTo = 60 (ACL Policy) outPort = CONTROLLER (Reserved) | priority = 2 hard_time = 0 idle_time = 0 cookie = 10
-- etherType = 0x0800 vrf:mask = 0x0000:0x0000 dstIp4 = 10.1.1.2/255.255.255.255 dstIp6 = ::/:: | GoTo = 60 (ACL Policy) groupId = 0x20000001 | priority = 3 hard_time = 0 idle_time = 0 cookie = 13
-- etherType = 0x0800 vrf:mask = 0x0000:0x0000 dstIp4 = 192.51.0.0/255.255.0.0 dstIp6 = ::/:: | GoTo = 60 (ACL Policy) outPort = CONTROLLER (Reserved) | priority = 2 hard_time = 0 idle_time = 0 cookie = 14
Steps to Reproduce the Problem
Due to the 192.51.0.0/16 route not being deleted from table 30 when deleting the switch bridge (known issue?), it is recommended that the switch is rebooted between retries.
Non working example 1: When changing the SVI MAC address
#!/usr/bin/env bash
BRIDGE_NAME=swbridge
BNG_DP_PORT=port50
BNG_VID=100
BNG_PORT_SVI_NAME="$BRIDGE_NAME.$BNG_VID"
BNG_PORT_SVI_MAC=aa:bb:cc:dd:ee:1a
BNG_PORT_SVI_IP="10.1.1.1/24"
BNG_PORT_SVI_NEXTHOP_IP="10.1.1.2"
BNG_IP_POOL_NET="192.51.0.0/16"
BNG_DOWNSTREAM_MAC=00:00:00:01:00:01
## Delete and add bridge
ip link del $BRIDGE_NAME
ip link add $BRIDGE_NAME type bridge vlan_filtering 1 vlan_default_pvid 0
## VLANs that are processed by the bridge
bridge vlan add vid $BNG_VID dev $BRIDGE_NAME self
## Add ports to bridge
ip link set $BNG_DP_PORT master $BRIDGE_NAME # BNG data plane
## Add VLANs to ports
# Set PVIDs to BNG and UPLINK ports
bridge vlan add vid $BNG_VID dev $BNG_DP_PORT pvid egress untagged
## Add SVIs
# BNG port
ip link add link $BRIDGE_NAME name $BNG_PORT_SVI_NAME type vlan id $BNG_VID
## Set MAC addresses
# BNG port
ip link set $BNG_PORT_SVI_NAME address $BNG_PORT_SVI_MAC
## Set IP addresses
# BNG port
ip a a $BNG_PORT_SVI_IP dev $BNG_PORT_SVI_NAME
## Ports up
ip link set $BRIDGE_NAME up
ip link set $BNG_PORT_SVI_NAME up
ip link set $BNG_DP_PORT up
# Forwarding entry to BNG_DOWNSTREAM_MAC via the BNG port
bridge fdb add $BNG_DOWNSTREAM_MAC dev $BNG_DP_PORT master vlan $BNG_VID
# Add IP neighbor entry
ip neighbor add $BNG_PORT_SVI_NEXTHOP_IP lladdr $BNG_DOWNSTREAM_MAC dev $BNG_PORT_SVI_NAME
# Add route
ip route add $BNG_IP_POOL_NET via $BNG_PORT_SVI_NEXTHOP_IP
Non working example 2: Adding a second port/vid to the bridge (this one fails sometimes)
#!/usr/bin/env bash
BRIDGE_NAME=swbridge
BNG_DP_PORT=port50
UPLINK_PORT=port52
BNG_VID=100
UPLINK_VID=101
BNG_PORT_SVI_NAME="$BRIDGE_NAME.$BNG_VID"
BNG_PORT_SVI_IP="10.1.1.1/24"
BNG_PORT_SVI_NEXTHOP_IP="10.1.1.2"
BNG_IP_POOL_NET="192.51.0.0/16"
BNG_DOWNSTREAM_MAC=00:00:00:01:00:01
## Delete and add bridge
ip link del $BRIDGE_NAME
ip link add $BRIDGE_NAME type bridge vlan_filtering 1 vlan_default_pvid 0
## VLANs that are processed by the bridge
bridge vlan add vid $BNG_VID dev $BRIDGE_NAME self
bridge vlan add vid $UPLINK_VID dev $BRIDGE_NAME self
## Add ports to bridge
ip link set $BNG_DP_PORT master $BRIDGE_NAME # BNG data plane
ip link set $UPLINK_PORT master $BRIDGE_NAME # UPLINK
## Add VLANs to ports
# Set PVIDs to BNG and UPLINK ports
bridge vlan add vid $BNG_VID dev $BNG_DP_PORT pvid egress untagged
bridge vlan add vid $UPLINK_VID dev $UPLINK_PORT pvid egress untagged
## Add SVIs
# BNG port
ip link add link $BRIDGE_NAME name $BNG_PORT_SVI_NAME type vlan id $BNG_VID
## Set IP addresses
# BNG port
ip a a $BNG_PORT_SVI_IP dev $BNG_PORT_SVI_NAME
## Ports up
ip link set $BRIDGE_NAME up
ip link set $BNG_PORT_SVI_NAME up
ip link set $BNG_DP_PORT up
ip link set $UPLINK_PORT up
# Forwarding entry to BNG_DOWNSTREAM_MAC via the BNG port
bridge fdb add $BNG_DOWNSTREAM_MAC dev $BNG_DP_PORT master vlan $BNG_VID
# Add IP neighbor entry
ip neighbor add $BNG_PORT_SVI_NEXTHOP_IP lladdr $BNG_DOWNSTREAM_MAC dev $BNG_PORT_SVI_NAME
# Add route
ip route add $BNG_IP_POOL_NET via $BNG_PORT_SVI_NEXTHOP_IP
Specifications
- Version: Basebox 1.8.3-r0, BISDN Linux 3.5.1
- Platform: agema-ag7648
- Subsystem:
Flow entries appear even when link and admin state are DOWN
Expected Behavior
- Adding an IP address on an interface that is not cabled should not trigger addition of flow table entries. Only after the port is UP, should there be flows in tables 10, 20 and 30.
- Flow table entries in Tables 20 and 30 should disappear when the port is set down.
- Flow table entries in Table 10 should be removed once an interface is set down.
Actual Behavior
- Adding an IP address on an interface where link or admin state is down triggers the creation of flow table entries in Table 10, 20 and 30.
- Removing the IP address (regardless of state UP or DOWN) correctly removes flows in tables 20 and 30. Table 10 entries are still present.
- Setting an interface from up to down does not delete flow entries for the port in table 10, 20 and 30.
Steps to Reproduce the Problem
Pick a port, say port 2, which has a cable connected. Set interface down on both server side and switch side. (ip link set port2 down). Start with clean switch, reboot if necessary. The command 'client_flowtable_dump' should only show entries in Table 60.
Add an IP to the port on the switch side:
ip a a 10.0.0.1/24 dev port2
Check flow entries in table 10, 20 and 30 with client_flowtable_dump. Flows should not be there.
Remove IP on the switch side:
ip a del 10.0.0.1/24 dev port2
Check flow entries in table 10, 20 and 30 with client_flowtable_dump. Entries from table 20 and 30 are deleted, but table 10 still remains.
Specifications
- Version: baseboxd 1.5.0
- Platform: tested on both agema-ag7648 and accton-as4610
- Subsystem:
DSCP values are dropped on egress
Expected Behavior
Whenever packets marked with a DSCP value arrive to the switch its value should be preserved on egress, if there are no specific forwarding rules that explicitly change this behavior.
Actual Behavior
Packets marked with a DSCP value have their DSCP value set to 0 on egress.
Steps to Reproduce the Problem
Switch configuration
On the switch, configure a bridge with two ports:
ip link add swbridge type bridge vlan_filtering 1 vlan_default_pvid 1
ip link set port7 master swbridge
ip link set port8 master swbridge
ip link set swbridge up
ip link set port7 up
ip link set port8 up
Server
In this example, enp8s0f0np0 is connected to port7 and enp8s0f1np1 to port8 on the switch, respectively.
Terminal 1
Install iperf3, setup 2 namespaces, assign IP addresses. and start iperf3 server on ns0:
apt install iperf3 -y
ip netns add ns0
ip netns add ns1
ip link set enp8s0f0np0 netns ns0
ip netns exec ns0 ip a a 192.51.0.2/24 dev enp8s0f0np0
ip netns exec ns0 ip link set enp8s0f0np0 up
ip link set enp8s0f1np1 netns ns1
ip netns exec ns1 ip a a 192.51.0.1/24 dev enp8s0f1np1
ip netns exec ns1 ip link set enp8s0f1np1 up
ip netns exec ns0 iperf3 -s
Terminal 2
Start traffic capture on ns0:
ip netns exec ns0 tcpdump -venli enp8s0f0np0
Terminal 3
Start traffic capture on ns1:
ip netns exec ns0 tcpdump -venli enp8s0f1np1
Terminal 4
Start iperf3 client on ns1 setting the DSCP value with the --dscp option:
ip netns exec ns1 iperf3 -c 192.51.0.2 -t 1 --dscp 10
Observable results
The terminal capturing traffic on ns0 will show the DSCP value set to 0 on all packets. On ns1, it is possible to observe the configured value on the tos field:
Terminal 2
ethertype IPv4 (0x0800), length 42058: (tos 0x0, ttl 64, id 1207, offset 0, flags [DF], proto TCP (6), length 42044)
192.51.0.1.53068 > 192.51.0.2.5201: Flags [P.], cksum 0x2499 (incorrect -> 0xe92a), seq 1118429446:1118471438, ack 1, win 502, options [nop,nop,TS val 1037566304 ecr 3609952640], length 41992
ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 14871, offset 0, flags [DF], proto TCP (6), length 52)
192.51.0.2.5201 > 192.51.0.1.53068: Flags [.], cksum 0x8090 (incorrect -> 0xfd89), ack 1118471438, win 24557, options [nop,nop,TS val 3609952640 ecr 1037566304], length 0
Terminal 3
ethertype IPv4 (0x0800), length 63778: (tos 0x8, ttl 64, id 22415, offset 0, flags [DF], proto TCP (6), length 63764)
192.51.0.1.53068 > 192.51.0.2.5201: Flags [P.], cksum 0x7971 (incorrect -> 0xbc23), seq 960328118:960391830, ack 1, win 502, options [nop,nop,TS val 1037566171 ecr 3609952507], length 63712
ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 11531, offset 0, flags [DF], proto TCP (6), length 52)
192.51.0.2.5201 > 192.51.0.1.53068: Flags [.], cksum 0x2278 (correct), ack 960391830, win 24557, options [nop,nop,TS val 3609952507 ecr 1037566171], length 0
Specifications
- Version: BISDN Linux 3.7.1
- Platform: accton-as4610 and agema-ag5648
- Subsystem:
Termination MAC cleanup on bonds may sometimes fail
Expected Behavior
Cleaning the Linux state should clear the ASIC tables as well. When configuring an IP address on bonds, changing a MAC address and deleting it, the ASIC tables should be cleaned.
After changing the MAC address, the following state is observed.
10: bond1: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 02:00:00:00:00:01 brd ff:ff:ff:ff:ff:ff
inet 10.0.1.1/24 brd 10.0.3.255 scope global bond1
valid_lft forever preferred_lft forever
...
-- inPort:mask = 131073:0xffffffff etherType = 0x0800 destMac:mask = 0200.0000.0001:ffff.ffff.ffff vlanId:mask = 0x1001:0x1fff (VLAN 1) | GoTo = 30 (Unicast Routing) outPort = 0 (Physical) | priority = 2 hard_time = 0 idle_time = 0
-- inPort:mask = 131073:0xffffffff etherType = 0x86dd destMac:mask = 0200.0000.0001:ffff.ffff.ffff vlanId:mask = 0x1001:0x1fff (VLAN 1) | GoTo = 30 (Unicast Routing) outPort = 0 (Physical) | priority = 2 hard_time = 0 idle_time = 0
...
-- etherType = 0x0800 vrf:mask = 0x0000:0x0000 dstIp4 = 10.0.1.0/255.255.255.0 dstIp6 = ::/:: | GoTo = 60 (ACL Policy) groupId = 0x20000001 | priority = 2 hard_time = 0 idle_time = 0
Deleting the IP address should empty the state in the visible tables above.
Actual Behavior
When configuring IP addresses on bonded interfaces on BISDN Linux, with systemd-networkd, the following log can be visible.
cnetlink.cc:409] add_l3_addresses: adding address=10.0.1.1/24 inet dev bond1 scope global <permanent>
nl_l3.cc:1222] add_l3_termination: added l3 termination for port=131073 vid=1 mac=<caddress_ll 32:e5:10:61:dc:4d >
...
cnetlink.cc:993] route_addr_apply: new addr 10.0.1.1/24 inet dev bond1 scope global <permanent>
nl_l3.cc:1194] add_l3_termination: incremented refcount=2 for key portid=131073 vid=1 mac=<caddress_ll 32:e5:10:61:dc:4d > af=2
This wrongly configures the internal baseboxd refcounts, which can possibly leave some state pending when removing the IP address.
10: bond1: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 02:00:00:00:00:01 brd ff:ff:ff:ff:ff:ff
...
-- inPort:mask = 131073:0xffffffff etherType = 0x0800 destMac:mask = 0200.0000.0001:ffff.ffff.ffff vlanId:mask = 0x1001:0x1fff (VLAN 1) | GoTo = 30 (Unicast Routing) outPort = 0 (Physical) | priority = 2 hard_time = 0 idle_time = 0
-- inPort:mask = 131073:0xffffffff etherType = 0x86dd destMac:mask = 0200.0000.0001:ffff.ffff.ffff vlanId:mask = 0x1001:0x1fff (VLAN 1) | GoTo = 30 (Unicast Routing) outPort = 0 (Physical) | priority = 2 hard_time = 0 idle_time = 0
...
Steps to Reproduce the Problem
It is a racy behaviour only visible in the AS4630. Configure IP addresses on bonds with systemd-networkd.
Specifications
- Version: 4.4.1
- Platform: AS4630
- Subsystem: nl_l3
Incorrect ipv6 Termination MAC entries when enslaving port to bridge
Expected Behavior
Enslaving a port to a bridge, then tagging a vlan on the port should not create any Termination MAC entries.
Table ID 20 (Termination MAC): Retrieving all entries. Max entries = 512, Current entries = 1.
-- inPort:mask = 7:0xffffffff etherType = 0x86dd destMac:mask = aa39.5aea.5990:ffff.ffff.ffff vlanId:mask = 0x1001:0x1fff (VLAN 1)
| GoTo = 30 (Unicast Routing) outPort = 0 (Physical) | priority = 2 hard_time = 0 idle_time = 0 cookie = 14
Actual Behavior
Enslaving a port to a bridge, then tagging a vlan on the port does create a Termination MAC entries.
Steps to Reproduce the Problem
Set server side port UP before starting switch side configuration.
ip link set server_port up
On the Switch run the following commands:
Create vlan_filtering bridge swbridge
/sbin/ip link add name swbridge type bridge vlan_filtering 1
Set bridge swbridge up
/sbin/ip link set swbridge up
Attach port_left to the swbridge"
/sbin/ip link set {{ port_left }} master swbridge
Set port_left attached to swbridge up
/sbin/ip link set {{ port_left }} up
add vid 10 to port_left
/sbin/bridge vlan add vid 10 dev {{ port_left }}
Check termination MAC entries
client_flowtable_dump 20
Gives the output(example given):
Table ID 20 (Termination MAC): Retrieving all entries. Max entries = 512, Current entries = 1.
-- inPort:mask = 7:0xffffffff etherType = 0x86dd destMac:mask = aa39.5aea.5990:ffff.ffff.ffff vlanId:mask = 0x1001:0x1fff (VLAN 1)
| GoTo = 30 (Unicast Routing) outPort = 0 (Physical) | priority = 2 hard_time = 0 idle_time = 0 cookie = 14
Specifications
- Version: 1.9.22
- Platform: agema-ag7648
- Subsystem:
update IPv6 neighbors
Expected Behavior
f407098#diff-e57a8238a1651a954280330119cafefcR471
When updating the neighbour, baseboxd must check if the neighbors state is one of:
- permanent
- noarp
- reachable
- stale
- none
- incomplete
- delay
- probe
- failed
In the case for incomplete neighbors, baseboxd must still install the rule to forward packets to the controller.
See 0a5c7c1#diff-3c368f43e25d51e19a158722ea158133R1547
Actual Behavior
Currently there are no IPv6 neighbor updates being handled in baseboxd.
Steps to Reproduce the Problem
bgp-ipv6 test
Specifications
- Version: baseboxd 1.6.0
baseboxd does not write the flowmods into the switch after deleting/adding swbridge
Expected Behavior
Deleting swbridge that has ports attached will delete corresponding flowmods.
- Before deletion of the swbridge,
TABLE 10:
-- inPort = 7 (Physical) vlanId:mask = 0x0000:0x1fff (VLAN 0) | GoTo = 20 (Termination MAC) newVlanId = 0x1001 (VLAN 1) | priority = 3 hard_time = 0 idle_time = 0 cookie = 111
-- inPort = 7 (Physical) vlanId:mask = 0x1001:0x1fff (VLAN 1) | GoTo = 20 (Termination MAC) | priority = 3 hard_time = 0 idle_time = 0 cookie = 110
-- inPort = 7 (Physical) vlanId:mask = 0x1064:0x1fff (VLAN 100) | GoTo = 20 (Termination MAC) | priority = 3 hard_time = 0 idle_time = 0 cookie = 115
-- inPort = 8 (Physical) vlanId:mask = 0x0000:0x1fff (VLAN 0) | GoTo = 20 (Termination MAC) newVlanId = 0x1001 (VLAN 1) | priority = 3 hard_time = 0 idle_time = 0 cookie = 113
-- inPort = 8 (Physical) vlanId:mask = 0x1001:0x1fff (VLAN 1) | GoTo = 20 (Termination MAC) | priority = 3 hard_time = 0 idle_time = 0 cookie = 112
-- inPort = 8 (Physical) vlanId:mask = 0x1064:0x1fff (VLAN 100) | GoTo = 20 (Termination MAC) | priority = 3 hard_time = 0 idle_time = 0 cookie = 116
TABLE 50:
-- vlanId:mask = 0x1001:0x1fff (VLAN 1) destMac:mask = 0000.0000.0000:0000.0000.0000 | GoTo = 60 (ACL Policy) groupId = 0x40010001 outPort = 0 (Physical) | priority = 2 hard_time = 0 idle_time = 0 cookie = 109
-- vlanId:mask = 0x1064:0x1fff (VLAN 100) destMac:mask = 0000.0000.0000:0000.0000.0000 | GoTo = 60 (ACL Policy) groupId = 0x40640064 outPort = 0 (Physical) | priority = 2 hard_time = 0 idle_time = 0 cookie = 114
- After teardown and re-config of the swbridge,
TABLE 10:
-- inPort = 7 (Physical) vlanId:mask = 0x0000:0x1fff (VLAN 0) | GoTo = 20 (Termination MAC) newVlanId = 0x1001 (VLAN 1) | priority = 3 hard_time = 0 idle_time = 0 cookie = 111
-- inPort = 7 (Physical) vlanId:mask = 0x1001:0x1fff (VLAN 1) | GoTo = 20 (Termination MAC) | priority = 3 hard_time = 0 idle_time = 0 cookie = 110
-- inPort = 7 (Physical) vlanId:mask = 0x1064:0x1fff (VLAN 100) | GoTo = 20 (Termination MAC) | priority = 3 hard_time = 0 idle_time = 0 cookie = 115
-- inPort = 8 (Physical) vlanId:mask = 0x0000:0x1fff (VLAN 0) | GoTo = 20 (Termination MAC) newVlanId = 0x1001 (VLAN 1) | priority = 3 hard_time = 0 idle_time = 0 cookie = 113
-- inPort = 8 (Physical) vlanId:mask = 0x1001:0x1fff (VLAN 1) | GoTo = 20 (Termination MAC) | priority = 3 hard_time = 0 idle_time = 0 cookie = 112
-- inPort = 8 (Physical) vlanId:mask = 0x1064:0x1fff (VLAN 100) | GoTo = 20 (Termination MAC) | priority = 3 hard_time = 0 idle_time = 0 cookie = 116
TABLE 50:
-- vlanId:mask = 0x1001:0x1fff (VLAN 1) destMac:mask = 0000.0000.0000:0000.0000.0000 | GoTo = 60 (ACL Policy) groupId = 0x40010001 outPort = 0 (Physical) | priority = 2 hard_time = 0 idle_time = 0 cookie = 109
-- vlanId:mask = 0x1064:0x1fff (VLAN 100) destMac:mask = 0000.0000.0000:0000.0000.0000 | GoTo = 60 (ACL Policy) groupId = 0x40640064 outPort = 0 (Physical) | priority = 2 hard_time = 0 idle_time = 0 cookie = 114
Actual Behavior
- After teardown and re-config of the swbridge,
TABLE 10:
Does not show VLAN entries corresponding to inPort=7 and 8.
TABLE 50:
Empty.
Steps to Reproduce the Problem
The PR: #237 has a script to allow setting this bug up.
Specifications
- Version: 1.2.1
- Platform: BISDN Linux
- Subsystem: NA
ip neighbors are assumed and made routable regardless of actually having a route
Expected Behavior
Only ip neighbors for which a route exists are being routed (with an appropriate flow).
Actual Behavior
Any reachable ip neighbor is assumed to be routable and flow tables are setup accordingly (and thus routed in hardware), even if there does not exist a route.
Steps to Reproduce the Problem
Consider the following setup
| Server | port1 <-------------> port1 | Switch |
lo 10.0.1.2/24 10.0.1.1/24
10.0.2.1/24
switch:~$ ip route
10.0.1.0/24 dev port1 proto kernel scope link src 10.0.1.1
switch:~$ ip route add 10.0.2.0/24 dev port1
switch:~$ ip route
10.0.1.0/24 dev port1 proto kernel scope link src 10.0.1.1
10.0.2.0/24 dev port1 scope link
switch:~$ ping 10.0.2.1 -I port1
PING 10.0.2.1 (10.0.2.1): 56 data bytes
64 bytes from 10.0.2.1: seq=0 ttl=64 time=1.126 ms
switch:~$ ip neigh show
10.0.2.1 dev port1 lladdr b0:26:28:62:d4:00 REACHABLE
10.0.1.2 dev port1 lladdr b0:26:28:62:d4:00 STALE
switch:~$ client_flowtable_dump 30 | grep 10.
-- etherType = 0x0800 vrf:mask = 0x0000:0x0000 dstIp4 = 10.0.1.0/255.255.255.0 dstIp6 = ::/:: | GoTo = 60 (ACL Policy) outPort = CONTROLLER (Reserved) | priority = 2 hard_time = 0 idle_time = 0 cookie = 11
-- etherType = 0x0800 vrf:mask = 0x0000:0x0000 dstIp4 = 10.0.1.2/255.255.255.255 dstIp6 = ::/:: | GoTo = 60 (ACL Policy) groupId = 0x20000001 | priority = 3 hard_time = 0 idle_time = 0 cookie = 14
-- etherType = 0x0800 vrf:mask = 0x0000:0x0000 dstIp4 = 10.0.2.0/255.255.255.0 dstIp6 = ::/:: | GoTo = 60 (ACL Policy) outPort = CONTROLLER (Reserved) | priority = 2 hard_time = 0 idle_time = 0 cookie = 17
-- etherType = 0x0800 vrf:mask = 0x0000:0x0000 dstIp4 = 10.0.2.1/255.255.255.255 dstIp6 = ::/:: | GoTo = 60 (ACL Policy) groupId = 0x20000001 | priority = 3 hard_time = 0 idle_time = 0 cookie = 16
switch:~$ ip route get 10.0.2.1
10.0.2.1 dev port1 src 10.0.1.1 uid 1000
cache
So far everything's fine.
But if we remove the route, the neighbor stays routed.
switch:~$ ip route del 10.0.2.0/24 dev port1
switch:~$ ip route get 10.0.2.1
RTNETLINK answers: Network is unreachable
switch:~$ client_flowtable_dump 30 | grep 10.0.2.1
-- etherType = 0x0800 vrf:mask = 0x0000:0x0000 dstIp4 = 10.0.2.1/255.255.255.255 dstIp6 = ::/:: | GoTo = 60 (ACL Policy) groupId = 0x20000001 | priority = 3 hard_time = 0 idle_time = 0 cookie = 16
Removing the neighbor removes the forwarding entry:
switch:~$ ip neigh del 10.0.2.1 dev port1
switch:~$ client_flowtable_dump 30 | grep 10.0.2.1
switch:~$
But adding it manually will create a routed entry again, despite it still not being supposed to be routable
switch:~$ ip neigh add 10.0.2.1 lladdr b0:26:28:62:d4:00 dev port1
switch:~$ client_flowtable_dump 30 | grep 10.0.2.1
-- etherType = 0x0800 vrf:mask = 0x0000:0x0000 dstIp4 = 10.0.2.1/255.255.255.255 dstIp6 = ::/:: | GoTo = 60 (ACL Policy) groupId = 0x20000001 | priority = 3 hard_time = 0 idle_time = 0 cookie = 18
switch:~$ ip route get 10.0.2.1
RTNETLINK answers: Network is unreachable
The implication of the groupId being set for that enry is that any traffic with the destination address 10.0.2.1 coming in on a different interface will get routed according to entry, instead of being dropped, and 10.0.2.1 becoming/staying reachable for other connected devices.
To fix this, we would basically need to do the reverse we do for routes and nexthops; only add l3 neighbors as routable / set to forward to an interface if we have a route for them, and wait for a route to be added if not. And the inverse for routes being removed.
Specifications
- Version: master
- Platform: ag5648
- Subsystem: nl_l3
Disabling a port does not properly delete flows&groups
Expected Behavior
Disabling a port (IPv6 enabled) should remove flows in vlan table and termination_mac table. It also should remove the groups.
Actual Behavior
It only removes flows in termination_mac table.
Steps to Reproduce the Problem
Enable a port (ip l set port up), see entries in 10, 20 and group appear. Disable the port and these entries are still there.
Specifications
- Version: baseboxd version 1.4.3, BISDN Linux 3.0.0
- Platform: AG7648
- Subsystem:
I2C on Agema-ag7648 missing devices
Expected Behavior
ofagent looks for devices: /dev/i2c-3 and /dev/i2c-2 but they are not found on the ag7648 running the 19.06 release.
running ofagent by hand (since it crashes and restarts through systemd):
root@agema-ag7648:~# /usr/sbin/ofagent -a=20
initializing
10-22 15:37:58.095739 [ofagent] version 0.0.0.0 [ 267.623270] ofagent[2061]: segfault at 0 ip 00000000004041ed sp 00007ffd70655440 error 4-- Built on Thu in ofagent[403000+19b000]Jun 27 2019 at 0
9:53:08 UTC
OF [ 267.638516] audit: type=1701 audit(1571758678.097:9): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=2061 comm="ofagent" exe="/usr/sbin/ofagent" sig=11
Datapath ID: 0x000000000000DA7A
Initializing the system.
10-22 15:37:58.095739 [socketmanager] Initializing socket manager
10-22 15:37:58.096739 [ofstatemanager] Registered gentable "test" with table id 0
10-22 15:37:58.096739 [socketmanager] Enabling OF socket mgr
10-22 15:37:58.096739 [ofconnectionmanager] Enabling OF connection mgr
10-22 15:37:58.096739 [ofstatemanager] Enabling OF state mgr
10-22 15:37:58.096739 [onlplib] failed to open file /dev/i2c-3 (0x2): No such file or directory
10-22 15:37:58.096739 [onlplib] failed to open file /dev/i2c-3 (0x2): No such file or directory
10-22 15:37:58.096739 [onlplib] failed to open file /dev/i2c-3 (0x2): No such file or directory
10-22 15:37:58.096739 [onlplib] failed to open file /dev/i2c-3 (0x2): No such file or directory
10-22 15:37:58.096739 [onlplib] failed to open file /dev/i2c-3 (0x2): No such file or directory
10-22 15:37:58.096739 [onlplib] failed to open file /dev/i2c-3 (0x2): No such file or directory
10-22 15:37:58.096739 [onlplib] failed to open file /dev/i2c-3 (0x2): No such file or directory
10-22 15:37:58.096739 [onlplib] failed to open file /dev/i2c-3 (0x2): No such file or directory
10-22 15:37:58.096739 [onlplib] failed to open file /dev/i2c-3 (0x2): No such file or directory
10-22 15:37:58.096739 [onlplib] failed to open file /dev/i2c-3 (0x2): No such file or directory
10-22 15:37:58.096739 [onlplib] failed to open file /dev/i2c-3 (0x2): No such file or directory
10-22 15:37:58.096739 [onlplib] failed to open file /dev/i2c-3 (0x2): No such file or directory
10-22 15:37:58.096739 [onlplib] failed to open file /dev/i2c-3 (0x2): No such file or directory
10-22 15:37:58.096739 [onlplib] failed to open file /dev/i2c-3 (0x2): No such file or directory
10-22 15:37:58.096739 [onlplib] failed to open file /dev/i2c-3 (0x2): No such file or directory
10-22 15:37:58.096739 [onlplib] failed to open file /dev/i2c-3 (0x2): No such file or directory
10-22 15:37:58.096739 [onlplib] failed to open file /dev/i2c-3 (0x2): No such file or directory
10-22 15:37:58.096739 [onlplib] failed to open file /dev/i2c-3 (0x2): No such file or directory
10-22 15:37:58.096739 [onlplib] failed to open file /dev/i2c-3 (0x2): No such file or directory
10-22 15:37:58.096739 [onlplib] failed to open file /dev/i2c-3 (0x2): No such file or directory
10-22 15:37:58.096739 [onlplib] failed to open file /dev/i2c-3 (0x2): No such file or directory
10-22 15:37:58.096739 [onlplib] failed to open file /dev/i2c-3 (0x2): No such file or directory
10-22 15:37:58.096739 [onlplib] failed to open file /dev/i2c-2 (0x2): No such file or directory
10-22 15:37:58.096739 [onlplib] failed to open file /dev/i2c-2 (0x2): No such file or directory
10-22 15:37:58.096739 [onlplib] failed to open file /dev/i2c-2 (0x2): No such file or directory
10-22 15:37:58.096739 [x86_64_delta_ag7648] Unable to read the 0 reg
10-22 15:37:58.096739 [onlplib] ONIE data is not in TlvInfo format.
10-22 15:37:58.096739 [onlplib] failed to open file /dev/i2c-2 (0x2): No such file or directory
10-22 15:37:58.096739 [ofagent] got serial number: (null)
Segmentation fault (core dumped)
Actual Behavior
only 2 i2c devices are found:
root@agema-ag7648:~# ls -la /dev/i2c-*
crw------- 1 root root 89, 0 Oct 22 15:36 /dev/i2c-0
crw------- 1 root root 89, 1 Oct 22 15:36 /dev/i2c-1
Steps to Reproduce the Problem
Install 19.06 BISDN on a ag7648 switch.
Specifications
- Version: 19.06
- Platform: Delta Agema
- Subsystem: AG7658
Its also useful to note that if I boot the switch into ODM: DIAG mode, and dump the i2c devices from there I see all the i2c devices.
AG7648-DIAG> show i2c devices
NAME BUS ADDR MUX STATUS
CLOCK_GEN 0 69(d2) OK
DDR_VR 0 2e(5c) OK
DDR_MODULE_0 0 52(a4) OK
DDR_MODULE_1 0 53(a6) N/A
System_CPLD 2 31(62) OK
Master_CPLD 2 32(64) OK
Slave_CPLD 2 33(66) OK
TMP75 2 4d(9a) OK
ID_EEPROM 2 53(a6) OK
TMP75-C 3 4c(98) OK
TMP75-D 3 4d(9a) OK
TMP75-E 3 4e(9c) OK
HotSwap2 3 42(84) OK
HotSwap1 3 40(80) OK
FAN3-EEPROM 3 53(a6) OK
FAN2-EEPROM 3 52(a4) OK
FAN1-EEPROM 3 51(a2) OK
FAN-CTRL1 3 29(52) OK
FAN-CTRL2 3 2a(54) OK
AVS-PWR-RSV 3 2c(58) OK
SFP1 4 50(a0) 1 N/A
SFP2 4 50(a0) 2 N/A
SFP3 4 50(a0) 3 N/A
SFP4 4 50(a0) 4 N/A
SFP5 4 50(a0) 5 N/A
SFP6 4 50(a0) 6 N/A
SFP7 4 50(a0) 7 N/A
SFP8 4 50(a0) 8 N/A
SFP9 4 50(a0) 9 N/A
SFP10 4 50(a0) 10 N/A
SFP11 4 50(a0) 11 N/A
SFP12 4 50(a0) 12 N/A
SFP13 4 50(a0) 13 N/A
SFP14 4 50(a0) 14 N/A
SFP15 4 50(a0) 15 N/A
SFP16 4 50(a0) 16 N/A
SFP17 4 50(a0) 17 N/A
SFP18 4 50(a0) 18 N/A
SFP19 4 50(a0) 19 N/A
SFP20 4 50(a0) 20 N/A
SFP21 4 50(a0) 21 N/A
SFP22 4 50(a0) 22 N/A
SFP23 4 50(a0) 23 N/A
SFP24 4 50(a0) 24 N/A
SFP25 4 50(a0) 25 N/A
SFP26 4 50(a0) 26 N/A
SFP27 4 50(a0) 27 N/A
SFP28 4 50(a0) 28 N/A
SFP29 4 50(a0) 29 N/A
SFP30 4 50(a0) 30 N/A
SFP31 4 50(a0) 31 N/A
SFP32 4 50(a0) 32 N/A
SFP33 4 50(a0) 33 N/A
SFP34 4 50(a0) 34 N/A
SFP35 4 50(a0) 35 N/A
SFP36 4 50(a0) 36 N/A
SFP37 4 50(a0) 37 N/A
SFP38 4 50(a0) 38 N/A
SFP39 4 50(a0) 39 N/A
SFP40 4 50(a0) 40 N/A
SFP41 4 50(a0) 41 N/A
SFP42 4 50(a0) 42 N/A
SFP43 4 50(a0) 43 N/A
SFP44 4 50(a0) 44 N/A
SFP45 4 50(a0) 45 N/A
SFP46 4 50(a0) 46 N/A
SFP47 4 50(a0) 47 N/A
SFP48 4 50(a0) 48 N/A
QSFP49 5 50(a0) 0 N/A
QSFP50 5 50(a0) 1 N/A
QSFP51 5 50(a0) 2 N/A
QSFP52 5 50(a0) 3 N/A
QSFP53 5 50(a0) 4 N/A
QSFP54 5 50(a0) 5 N/A
PSU2-EEPROM 6 51(a2) OK
PSU1-EEPROM 6 50(a0) OK
PSU2-PM 6 59(b2) OK
PSU1-PM 6 58(b0) OK
After more digging I see the diag mode loads a different module (here is a snippet of the diag mode's kernel boot).
i2c /dev entries driver
i801_smbus 0000:00:1f.3: PCI->APIC IRQ transform: INT B -> IRQ 18
i801_smbus 0000:00:1f.3: SMBus using PCI Interrupt
ismt_smbus 0000:00:13.0: PCI->APIC IRQ transform: INT A -> IRQ 16
ismt_smbus 0000:00:13.0: irq 54 for MSI/MSI-X
i2c i2c-1: Added multiplexed i2c bus 2
i2c i2c-1: Added multiplexed i2c bus 3
i2c i2c-1: Added multiplexed i2c bus 4
i2c i2c-1: Added multiplexed i2c bus 5
i2c i2c-1: Added multiplexed i2c bus 6
i2c i2c-1: Added multiplexed i2c bus 7
i2c i2c-1: Added multiplexed i2c bus 8
i2c i2c-1: Added multiplexed i2c bus 9
pca954x 1-0070: registered 8 multiplexed busses for I2C mux pca9547
Note the pca954x driver finding a pac9547, but when we boot into bisdn that driver doesn't seem to be loaded.
Deleting VRF with bonds does not clean up all flowtable entries.
Expected Behavior
Deleting all VRFs should leave no traces of VRFs in flowtable_30
Actual Behavior
Deleting all VRFs should leave no traces of VRFs in flowtable_30, as seen below
accton-as4610:/home/basebox# client_flowtable_dump 30 Table ID 30 (Unicast Routing): Retrieving all entries. Max entries = 32768, Current entries = 4. -- etherType = 0x0800 vrf:mask = 0x0000:0x0000 dstIp4 = 10.0.2.0/255.255.255.0 dstIp6 = ::/:: | GoTo = 60 (ACL Policy) outPort = CONTROLLER (Reserved) | priority = 2 hard_time = 0 idle_time = 0 cookie = 78 -- etherType = 0x0800 vrf:mask = 0x0000:0x0000 dstIp4 = 10.0.3.0/255.255.255.0 dstIp6 = ::/:: | GoTo = 60 (ACL Policy) outPort = CONTROLLER (Reserved) | priority = 2 hard_time = 0 idle_time = 0 cookie = 80 -- etherType = 0x0800 vrf:mask = 0x000a:0xffff dstIp4 = 10.0.1.0/255.255.255.0 dstIp6 = ::/:: | GoTo = 60 (ACL Policy) outPort = CONTROLLER (Reserved) | priority = 2 hard_time = 0 idle_time = 0 cookie = 23 -- etherType = 0x86dd vrf:mask = 0x0000:0x0000 dstIp4 = 0.0.0.0/0.0.0.0 dstIp6 = fe80::/ffc0:: | GoTo = 60 (ACL Policy) outPort = CONTROLLER (Reserved) | priority = 2 hard_time = 0 idle_time = 0 cookie = 83
Steps to Reproduce the Problem
Run the vrf-lacp to setup, then simply remove the only VRF (red) that exists by running
ip l del red
Specifications
- Version: commit ef4443e
- Platform: accton-as4610 (probably all platforms)
- Subsystem:
received VxLAN tunneled packets are copied to controller
Expected Behavior
VXLAN tunneled packets are forwarded in hardware, and the traffic is not visible to the controller.
Actual Behavior
VXLAN tunneled packets are forwarded in hardware(?), but the VXLAN encapsulated packets are copied to Controller (visible in tcpdump on the port with the vxlan interface).
Steps to Reproduce the Problem
Follow the VXLAN example, look at the packets received by the switch on the vxlan port (port54 in the example).
Specifications
- Version: BISDN Linux 5.0
- Platform: agema-ag7648
- Subsystem: baseboxd
carrier state may get out of sync if ports are set up during start up
Expected Behavior
Carrier state of ports matches the actual state.
Actual Behavior
With a low probability, ports interfaces may claim no-carrier despite having one when being set up fast during boot e.g. via systemd-networkd.
Steps to Reproduce the Problem
- Set up ports to be up via systemd-networkd
- ensure other side is up
- reboot until the issue happens (may take a while)
Specifications
- Version: baseboxd 2.0.3 / BISDN Linux 5.0
- Platform: accton-as4610
- Subsystem:
It is currently unclear where the core issue is. Possible sources:
- maybe there is a race in baseboxd where it processes an earlier link down messages after a later link up message (maybe a race between the port table and individual port state messages?)
- maybe the issue is in of-agent, and it sends out notifications in wrong order
- maybe the issue is in OF-DPA, and there is the chance of notifications not being sent out
generic glog configuration options are undocumented
While the https://github.com/bisdn/basebox/blob/main/pkg/systemd/sysconfig.template explains how to get more detailed logging, it does not explain how to reduce the log output by e.g. setting the minimum log level to WARNING.
Since we do document other options, having the documentation there would be good.
Help about enabling QinQ
The documentation about QinQ feature is somehow incomplete to me. I've created the bridge using vlan_protocol 802.1ad but no packets get through it. It seems dropped somehow.
If I change the protocol back to 802.1q we get the packets.
baseboxd exception with GLOG_v=3 in cnetlink.cc on line 1080
Expected Behavior
baseboxd should not crash ...
Actual Behavior
An exception occurs when starting baseboxd with an increased logging verbosity level (GLOG_v = 3 or above), once a netlink message calling method cnetlink::route_link_apply() is received causing the following exception:
--Type <RET> for more, q to quit, c to continue without paging--
Thread 2 "netlink" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff6b28700 (LWP 13)]
0x00005555555ec367 in std::char_traits<char>::length (__s=0x0)
at /usr/include/c++/9/bits/char_traits.h:335
335 return __builtin_strlen(__s);
(gdb) bt
#0 0x00005555555ec367 in std::char_traits<char>::length (__s=0x0)
at /usr/include/c++/9/bits/char_traits.h:335
#1 0x000055555575ae84 in std::basic_string_view<char, std::char_traits<char> >::basic_string_view (this=0x7ffff6b27500, __str=0x0)
at /usr/include/c++/9/string_view:124
#2 0x0000555555754da0 in basebox::cnetlink::link_updated (
this=0x555555943970, old_link=0x7ffff00144c0, new_link=0x7ffff001b9f0)
at ../src/netlink/cnetlink.cc:1083
#3 0x0000555555752ab0 in basebox::cnetlink::route_link_apply (
this=0x555555943970, obj=...) at ../src/netlink/cnetlink.cc:831
#4 0x00005555557500f2 in basebox::cnetlink::handle_wakeup (
this=0x555555943970, thread=...) at ../src/netlink/cnetlink.cc:531
#5 0x00007ffff7d13374 in rofl::cthread::handle_wakeup (this=0x555555943980)
at /git/rofl-common/src/rofl/common/locking.hpp:47
#6 0x00007ffff7d14095 in rofl::cthread::run_loop (this=0x555555943980)
at cthread.cpp:732
#7 0x00007ffff753c609 in start_thread (arg=<optimized out>)
at pthread_create.c:477
#8 0x00007ffff7461293 in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Steps to Reproduce the Problem
- Start baseboxd with GLOG_v=3.
- Connect a switch
- Wait some time for netlink events to occur ...
Anlaysis
- The logging call in cnetlink.cc on line 1080 includes function calls rtnl_link_get_slave_type(old_link) and rtnl_link_get_slave_type(new_link).
- These yield NULL pointers for the triggering netlink message effectively calling std::string_view(NULL) with causes the encountered exception.
Specifications
- Version: baseboxd 1.9.5
- Platform:
- Subsystem:
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.