From owner-freebsd-net@FreeBSD.ORG Wed Apr 18 00:39:49 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95D9B1065674 for ; Wed, 18 Apr 2012 00:39:49 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by mx1.freebsd.org (Postfix) with ESMTP id 5A2B08FC17 for ; Wed, 18 Apr 2012 00:39:49 +0000 (UTC) Received: from labgw2.phaedrus.sandvine.com (192.168.222.22) by WTL-EXCH-1.sandvine.com (192.168.196.31) with Microsoft SMTP Server id 14.1.339.1; Tue, 17 Apr 2012 20:39:42 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 10332) id 486BD33C02; Tue, 17 Apr 2012 20:39:40 -0400 (EDT) Date: Tue, 17 Apr 2012 20:39:40 -0400 From: Ed Maste To: Message-ID: <20120418003939.GA32603@sandvine.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: lagg(4) MAC address selection proposal X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 00:39:49 -0000 When a new lagg(4) interface is created the link layer address from the first port in the group is assigned to the lagg and to all other lagg port members. This means the address assigned to the lagg is different if specified as, for example, "laggport em0 laggport em1" vs "laggport em1 laggport em0". The code in lagg_port_create(), in if_lagg.c that chooses the first l2 address: 575 if (SLIST_EMPTY(&sc->sc_ports)) { 576 sc->sc_primary = lp; 577 lagg_lladdr(sc, IF_LLADDR(ifp)); 578 } else { 579 /* Update link layer address for this port */ 580 lagg_port_lladdr(lp, IF_LLADDR(sc->sc_ifp)); 581 } For the current modes lagg supports this probably doesn't matter much, but we have some improvements in the pipeline for which this behaviour is undesirable. (The first of which is an interface for choosing a different master; this allows a failover lagg to be set to transmit on a new port, without changing link states. With the current behaviour this causes all ports in the lagg to then change their l2 address.) In looking into potential solutions I found that the bridgestp code in bridge(4) searches the list of associated MAC addresses and uses the lowest one when it needs to select one from a group. I'd like to propose using the same logic for lagg's MAC address selection. Can anyone foresee an issue with this change? (I'm not aware of any lagg use cases that rely on the current behaviour.) -Ed