Hi!
Long story short: if you try to aggregate tap(4) devices into lacp-based
lagg(4), aggregate will fail to negotiate lacp with remote end and will not
be able to pass traffic.
Root cause: lacp code requires underlying interface to be full-duplex
(else it will not participate in lacp negotiation at all[1]) and have
non-zero speed (else it can not be selected as active aggregator[2],
and so if tap is the only lagg member - aggregate will not become active).
Patch can be as trivial as:
--- sys/net/if_tap.c.orig 2017-02-21 21:02:04.460053000 +0300
+++ sys/net/if_tap.c 2017-02-21 21:02:12.580696000 +0300
@@ -617,7 +617,7 @@
dummy = ifmr->ifm_count;
ifmr->ifm_count = 1;
ifmr->ifm_status = IFM_AVALID;
- ifmr->ifm_active = IFM_ETHER;
+ ifmr->ifm_active = IFM_ETHER | IFM_1000_T | IFM_FDX;
if (tp->tap_flags & TAP_OPEN)
ifmr->ifm_status |= IFM_ACTIVE;
ifmr->ifm_current = ifmr->ifm_active;
[1]:
https://svnweb.freebsd.org/base/head/sys/net/ieee8023ad_lacp.c?revision=312678&view=markup#l483
[2]:
https://svnweb.freebsd.org/base/head/sys/net/ieee8023ad_lacp.c?revision=312678&view=markup#l983
_______________________________________________
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
