faucetsdn/faucet

LLDP/CDP integration tests fail in some circumstances

mwutzke opened this issue · 2 comments

mwutzke commented

7 of the integration tests regularly fail with fingerprints like the following:

FAIL: mininet_tests.FaucetUntaggedLLDPBlockedTest.test_untagged (subunit.RemotedTestCase)
mininet_tests.FaucetUntaggedLLDPBlockedTest.test_untagged
----------------------------------------------------------------------
testtools.testresult.real._StringException: Traceback (most recent call last):
  File "/faucet-src/tests/integration/mininet_tests.py", line 2619, in test_untagged
    table_id=self._FLOOD_TABLE)
  File "/faucet-src/clib/mininet_test_base.py", line 2606, in wait_nonzero_packet_count_flow
    self.fail('DPID %s flow %s matching %s table ID %s had zero packet count' % (dpid, flow, match, table_id))
  File "/usr/lib/python3.7/unittest/case.py", line 680, in fail
    raise self.failureException(msg)
AssertionError: DPID 1545883070 flow {'priority': 8236, 'cookie': 14763864845902156901, 'idle_timeout': 0, 'hard_timeout': 0, 'byte_count': 0, 'duration_sec': 39, 'duration_nsec'
: 945000000, 'packet_count': 0, 'length': 72, 'flags': 0, 'actions': [], 'match': {'dl_dst': '01:80:c2:00:00:00/ff:ff:ff:ff:ff:f0'}, 'table_id': 3} matching {'dl_dst': '01:80:c2:
00:00:00/ff:ff:ff:ff:ff:f0'} table ID 3 had zero packet count

The 7 tests that fail are the LLDP / CDP related ones:

  • FaucetGroupStackStringOfDPUntaggedTest
  • FaucetStackStringOfDPUntaggedTest
  • FaucetStringOfDPLACPUntaggedTest
  • FaucetStringOfDPLACPUntaggedTest
  • FaucetStringOfDPUntaggedTest
  • FaucetUntaggedCDPTest
  • FaucetUntaggedLLDPBlockedTest

Environment:

  • Bare metal host: Ubuntu 20.04.2 (up to date patches)
  • Docker-CE: 19.03.8 and 20.10.7
  • Docker Image: faucet/test-base:9.0.1
mwutzke commented

Manually running ladvd in a test-base container shows the following:

root@9fc6286b942b:/faucet-src# ladvd -f -e lo -C -o -v -v -v eth0
child_init: ladvd 1.1.2 running
child_send: fetching all interfaces
netif_fetch: skipping interface lo
netif_fetch: found bridge interface docker0
netif_fetch: adding interface docker0
netif_fetch: found tun/tap interface eth0
netif_fetch: adding interface eth0
netif_fetch: detecting docker0 settings
netif_fetch: detecting eth0 settings
netif_fetch: fetching addresses for all interfaces
parent_signal: child exited with return code 0
parent_signal: quitting

Note that:
a) eth0 is detected as a tun/tap interface
b) no CDP packet building /sending logs are generated like the following (running the same on the bare metal host):

child_send: starting loop with interface eth0
child_send: fetching eth0 media details
child_send: building CDP packet for eth0
child_send: sending CDP packet (249 bytes) on eth0

Looking at ip link output:

root@9fc6286b942b:/faucet-src# ip -d link show dev eth0
17: eth0@if18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
    link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0 promiscuity 0 minmtu 68 maxmtu 65535
    veth addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535

This is reporting the eth0 as veth, which is the trigger in ladvd [1] to treat the interface as TUN/TAP

[1] https://github.com/sspans/ladvd/blob/master/src/netif_linux.c#L126

mwutzke commented

Adding -t to the ladvd invocation, allows sending of LLDP/CDP packets on TUN/TAP interfaces, and appears to resolve the issue for the 7 failing test cases.