From owner-freebsd-net@freebsd.org  Thu Feb 23 12:43:16 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 by mailman.ysv.freebsd.org (Postfix) with ESMTP id E1FB9CE9DB6
 for <freebsd-net@mailman.ysv.freebsd.org>;
 Thu, 23 Feb 2017 12:43:16 +0000 (UTC)
 (envelope-from snar@snar.spb.ru)
Received: from staff.retn.net (staff.retn.net [IPv6:2a02:2d8:0:20ff:232a::8])
 by mx1.freebsd.org (Postfix) with ESMTP id 9DE89A0B
 for <freebsd-net@freebsd.org>; Thu, 23 Feb 2017 12:43:16 +0000 (UTC)
 (envelope-from snar@snar.spb.ru)
Received: from staff.retn.net (staff.retn.net [IPv6:2a02:2d8:0:20ff:232a::8])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
 bits)) (No client certificate requested)
 (Authenticated sender: snarspb@)
 by staff.retn.net (Postfix) with ESMTPSA id AB48F28C19
 for <freebsd-net@freebsd.org>; Thu, 23 Feb 2017 15:43:03 +0300 (MSK)
Date: Thu, 23 Feb 2017 15:42:58 +0300
From: Alexandre Snarskii <snar@snar.spb.ru>
To: freebsd-net <freebsd-net@freebsd.org>
Subject: tap(4): half-duplex and zero-speed ?
Message-ID: <20170223124258.GA80687@staff.retn.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.6.1 (2016-04-27)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
 <mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
 <mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Feb 2017 12:43:17 -0000


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