Bridge interfaces are noisy: IPv6 solicitations and multicast reports

[nopid]

The NetworkPlugin container has multicast and IPv6 configured. When a veth pair is created, it generates auto-configuration messages from the container side. One can regularly see router solicitation and multicast reports.

To reproduce : With enable_ipv6 set to False, vstart a machine and tcpdump on eth0, wait a little bit:

$ kathara vstart --eth 0:A -n charlie

root@charlie:/# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether 62:57:16:4f:b1:81  txqueuelen 1000  (Ethernet)
        RX packets 20  bytes 1576 (1.5 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 8  bytes 1056 (1.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 8  bytes 1056 (1.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

root@charlie:/# sysctl  -a | grep disable_ipv6
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.eth0.disable_ipv6 = 1
net.ipv6.conf.ip6tnl0.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

root@charlie:/# tcpdump -v -i eth0
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
14:54:21.261044 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 16) fe80::c462:40ff:fe28:5c41 > ip6-allrouters: [icmp6 sum ok] ICMP6, router solicitation, length 16
          source link-address option (1), length 8 (1): 92:c8:ca:8b:a7:82
14:54:27.408319 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 16) fe80::90c8:caff:fe8b:a782 > ip6-allrouters: [icmp6 sum ok] ICMP6, router solicitation, length 16
          source link-address option (1), length 8 (1): 92:c8:ca:8b:a7:82
14:54:50.957490 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 16) fe80::c462:40ff:fe28:5c41 > ip6-allrouters: [icmp6 sum ok] ICMP6, router solicitation, length 16
          source link-address option (1), length 8 (1): 92:c8:ca:8b:a7:82
14:55:06.314863 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 16) fe80::90c8:caff:fe8b:a782 > ip6-allrouters: [icmp6 sum ok] ICMP6, router solicitation, length 16
          source link-address option (1), length 8 (1): 92:c8:ca:8b:a7:82
14:55:51.371388 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 16) fe80::c462:40ff:fe28:5c41 > ip6-allrouters: [icmp6 sum ok] ICMP6, router solicitation, length 16
          source link-address option (1), length 8 (1): 92:c8:ca:8b:a7:82
14:56:20.044953 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 16) fe80::90c8:caff:fe8b:a782 > ip6-allrouters: [icmp6 sum ok] ICMP6, router solicitation, length 16
          source link-address option (1), length 8 (1): 92:c8:ca:8b:a7:82
14:57:58.345746 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 16) fe80::c462:40ff:fe28:5c41 > ip6-allrouters: [icmp6 sum ok] ICMP6, router solicitation, length 16
          source link-address option (1), length 8 (1): 92:c8:ca:8b:a7:82

[lorenzo93]

Hi @nopid ,

Sorry for the delayed answer :)

Can you check if you have IPv6 enabled in your machine?

This problem relies in the "Enable IPv6" flag that (in the current version) can be set per-devices. So it is possible that in the same collision domain, some devices are using IPv6 while other devices are not using it.

In order to support the per-device IPv6 flag, we cannot disable IPv6 globally on a collision domain.

[nopid]

Dear @lorenzo93, I am very sorry that you closed this issue as there is indeed an issue with the NetworkPlugin.

Each Kathará hub is emulated by a NetworkPlugin network consisting of a Linux bridge and each connection of a host to the hub is emulated by a pair of veth. One of the veth consistues the interface on the Kathará host and can (depending on the configuration) have IPv6 enabled that is fine. However, the bridge and the other interface of the pair should behave as pure L1/L2 components and should not in any circonstance request for router parameters or try IPv6 SLAAC.

Of course, if the host Linux machine has IPv6 disabled, no problem occur but it would be better for Kathará to behave the same independently of this.

[lorenzo93]

Hi @nopid,

I understand your problem but, as far as my knowledge, there is no way to disable this behaviour. Unfortunatelly the linux bridges does not behave just like L2 bridges but have more functionalities. We have other known problems related to this, for example if you use multicast MAC addresses, the bridge catch the packet and does not forward it to the destinations.

If you have suggestions on how to solve this problems, let me know and we'll re-open this issue :)