netdev - bridge not learning from locally sent gratuitous ARP?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 21 Apr 2016 08:37:32 +0200
From:	Patrick Schaaf <netdev@....de>
To:	netdev@...r.kernel.org
Subject: bridge not learning from locally sent gratuitous ARP?

Dear netdev,

I've got a peculiar issue, and hope for clarification / workarounds here.

Scenario:
- a bridge interface br0, over some ethernet base
- a macvlan interface br0-vrrp on top, set up by keepalived, with VRRP VMAC
- keepalived regularly sending gratuitous ARP with that VRRP VMAC
- (new) an additional tap interface in br0, for an openvpn link

In principle, everything is working fine. The base keepalived setup
has been in operation for a long time, running directly over a VLAN
interface. The conversion to a bridge interface is also working
without any issues by itself. The additional tap to openvpn, and the
VPN setup it realizes, is also working fine, in principle...

Issue:
- openvpn runs at 100% CPU ....
- because it it sent all packets destined to the VRRP VMAC
- because that VMAC is not in the br0 learned MAC address table (brctl showmacs)
- thus the (production webserver outbound...) traffic is flooded to
all br0 ports

Diagnosis I did so far:
- with tcpdump, verified that I can see the gratuitous ARPs on both the macvlan
  and bridge interface.
- verified that "brctl showmacs" does not contain the VRRP VMAC
- identical setup for a different VLAN with almost no traffic to the
VMAC, has openvpn running without the huge CPU consumption
- straced the openvpn daemon with the issue, seeing the packet rate
expected as tap reads / sends to the remote site

Kernel:
3.14.48 (vanilla)
keepalived 1.2.13 (with repeated gratuitous ARP support patched in)

Can anybody shed a light on how to cope with this issue?

best regards
  Patrick