Thor Lancelot Simon a écrit :
On Thu, Dec 15, 2016 at 11:21:08AM +0100, BERTRAND Jo??l wrote:For me, ingoing packets revceived by tap0 and tap1 are sent to agr0, but not outgoing packets.So packets you send out agr0 (and see in the agr0 tcpdump output) do not appear in the output for either tap0 or tap1? I just want to be sure.
Right.
Did you have the tap0 and tap1 interfaces in the "up" state *BEFORE* attaching them to the agr? I ask because this sounds like the internal state machine in agr has not moved to the "distributing" state where it sends packets out each attached interface -- like there is a LACP or other failure, and I bet attaching the underlying interfaces while they are not "up" is a good way to get stuck like that.
Both tap0 and tap1 were up before adding these interfaces to agr.
I also wonder whether openvpn is transmitting the LACP PDUs across the link. Do you see them on the far end when you tcpdump the underlying tap interfaces?
OpenVPN sends ethernet traffic (in this configuration). I use L2-OpenVPN links for a long time without any trouble (even with NetBSD), thus I'm pretty sure that issue doesn't come from VPN itself. In my test configuration, I use a round robin agr0 (link0+link1) and I've only seen ARP frames. If I create a bond0 mode 4 (802.3ad) on linux server, NetBSD receives LACP PDU (but doesn't answer).
All in all this is a pretty awful way to get ECMP. Even if you get it going, are you sure it's worth the trouble?
I have to aggregate two L2-OpenVPN links between a server and another one. I have done this kind of aggregation without any trouble when both sides run Linux. In this case, foreign server run NetBSD. I have no choice.
Best regards, JKB