From owner-freebsd-net@freebsd.org Mon Feb 6 19:53:33 2017 Return-Path: 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 A9D06CD3ED0; Mon, 6 Feb 2017 19:53:33 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3EBDF1DA3; Mon, 6 Feb 2017 19:53:33 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 93F2525D38A4; Mon, 6 Feb 2017 19:53:19 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id A8B4BD1F855; Mon, 6 Feb 2017 19:53:18 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id 1fU8_GgIFP65; Mon, 6 Feb 2017 19:53:16 +0000 (UTC) Received: from [10.111.64.116] (unknown [IPv6:fde9:577b:c1a9:4410:9b2:9b63:1d3b:690d]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id F325BD1F828; Mon, 6 Feb 2017 19:53:14 +0000 (UTC) From: "Bjoern A. Zeeb" To: "Giulio Ferro" Cc: "freebsd-net@freebsd.org" , freebsd-hackers@freebsd.org Subject: Re: Duplicate MAC addresses in VNET epair interaces Date: Mon, 06 Feb 2017 19:53:12 +0000 Message-ID: <8B1A6A6C-4280-4B96-9D60-FC9E7EEE2222@lists.zabbadoz.net> In-Reply-To: <472069af-0f9d-d830-064b-2d984a5774ae@zirakzigil.org> References: <472069af-0f9d-d830-064b-2d984a5774ae@zirakzigil.org> MIME-Version: 1.0 X-Mailer: MailMate (2.0BETAr6076) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 19:53:33 -0000 On 6 Feb 2017, at 18:53, Giulio Ferro wrote: > Hi all, > > > Setup: > > 11.0-STABLE FreeBSD 11.0-STABLE #0 r312338: Tue Jan 17 12:29:38 UTC > 2017 > > > I've set up two freebsd hosts, each of which has a single VNET jail. > > On each host I've created 2 epair interfaces. > > Host A > > - epair0a, epair1a on the host > > - epair0b, epair1b on the jail > > > Host B > > - epair0a, epair10a on the host > > - epair0b, epair10b on the jail > > > What I noticed is that on both hosts, each epair interface has the > same MAC address: > …> > > (same behavior on the epair interfaces on the jail side) > > > As you can see, the mac addresses seems to depend on the order of the > creation of the epair, not on the name or address > > > This is a potentially bad behavior, because if I want to bridge say > epair1a on A with epair10a on B with a VPN or > > a physical connection giving 192.168.1.1 to epair1b and 192.168.1.2 to > epair10b, I won't be able to make them > > talk to each other since they have the same MAC address. > > > My question is: is this a bug or something I'm doing wrong? If there > any workaround I can use? From the man page: Like any other Ethernet interface, an epair needs to have a network address. Each epair will be assigned a locally administered address by default, that is only guaranteed to be unique within one network stack. To change the default addresses one may use the SIOCSIFADDR ioctl(2) or ifconfig(8) utility. I thought someone patched it a few years ago to have a pseudo-random part to make collisions less likely and use the FreeBSD vendor space, but it seems that never happened for epair (or didn’t make it into the tree). ifconfig epair[ab] ether 02:xx:xx:xx:xx is your friend for now. /bz