netdev - Re: 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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 21 Apr 2016 13:32:16 +0200
From:	Patrick Schaaf <netdev@....de>
To:	Toshiaki Makita <makita.toshiaki@....ntt.co.jp>
Cc:	netdev@...r.kernel.org
Subject: Re: bridge not learning from locally sent gratuitous ARP?

On Thu, Apr 21, 2016 at 12:31 PM, Toshiaki Makita
<makita.toshiaki@....ntt.co.jp> wrote:
> On 2016/04/21 15:37, Patrick Schaaf wrote:
> (I understand the problem happens only if you use macvlan on the bridge device. If wrong, correct me.)

That is my understanding, yes. That macvlan device is created by
keepalived, which I use for VRRP, via its use_vmac + vmac_xmit_base
settings.

> Please use "bridge fdb show" instead of "brctl showmacs". brctl is an
> old tool and has limitation in showing fdb entries.

Learn a new thing every day! Thanks, that's good to know.

> I guess your bridge doesn't have the mac address of the macvlan device
> in its fdb. If you can confirm that by bridge command, then add an entry
> by hand.
>
> # bridge fdb add <addr of macvlan> dev <brport> master
> <brport> can be any device that belongs to the bridge.
> This command (without "temp" option) installs an fdb entry that forwards
> frames to the bridge device.

The "bridge" command operates solely on bridge ports (not on the
bridge itself), as far as I can see. Checking the member interfaces,
indeed I cannot find an entry for the macvlan interface VMAC.

The macvlan interface itself is NOT a brport.

So I add that permanent entry to the underlying ethernet link of that bridge.

Seems to work - I can still ping the virtual IP address behind that
VMAC, so the macvlan interface continues to do what it should - and
running tcpdump on the tap brport to openvpn, I see these test pings
when the fdb entry has not been set, but I no longer see them after
the bridge fdb add.

So, assuming that proives stable, I have a workaround - but one that
needs knowlege of A) the unterlying interface (brport) to fondle, and
B) the macvlan MAC address that needs adding. keepalived couldn't
easily do that "in code" because it does not know what sits under the
bridge.

Naive question: shouldn't that work automatically, i.e. macvlan when
sitting on to of a bridge, doing that internally?

Anyway, thanks for the pointers to the workaround, much appreciated!

best regards
  Patrick