From owner-freebsd-virtualization@FreeBSD.ORG Wed Feb 5 21:02:16 2014 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1CD38526; Wed, 5 Feb 2014 21:02:16 +0000 (UTC) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D2CBD1964; Wed, 5 Feb 2014 21:02:15 +0000 (UTC) Received: from smarthost.fisglobal.com ([10.132.206.192]) by ltcfislmsgpa01.fnfis.com (8.14.5/8.14.5) with ESMTP id s15L2Eag019014 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 5 Feb 2014 15:02:14 -0600 Received: from THEMADHATTER (10.242.181.54) by smarthost.fisglobal.com (10.132.206.192) with Microsoft SMTP Server id 14.3.174.1; Wed, 5 Feb 2014 15:02:12 -0600 From: Sender: Devin Teske To: "'Craig Rodrigues'" , "'George Neville-Neil'" References: In-Reply-To: Subject: RE: MAC addresses to use for BHyve VM's running under FreeBSD? Date: Wed, 5 Feb 2014 13:02:06 -0800 Message-ID: <09da01cf22b5$885cecd0$9916c670$@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQKZhVDonEQDk15t88paxz5njic4opkSWrEg Content-Language: en-us X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-02-05_07:2014-02-05,2014-02-05,1970-01-01 signatures=0 Cc: dteske@FreeBSD.org, freebsd-virtualization@freebsd.org X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 21:02:16 -0000 > -----Original Message----- > From: Craig Rodrigues [mailto:rodrigc@FreeBSD.org] > Sent: Tuesday, February 4, 2014 11:03 PM > To: George Neville-Neil > Cc: freebsd-virtualization@freebsd.org > Subject: MAC addresses to use for BHyve VM's running under FreeBSD? > > Hi, > > I am running many BHyve VM's and am using tap interfaces with a single > bridge. I am configuring the IP addresses of these VM's via DHCP. > > I need to have separate MAC addresses for each VM. > > Can anyone recommend a range of MAC addresses to use? > > I seem to recall that at the 2013 FreeBSD Vendor Summit in Sunnyvale, > California, that George mentioned that there might be a Organizational > Unique Identifier (OUI) for the FreeBSD project that we can use for BHyve > VM's. Is that right? > > If not, can people recommend a range of addresses to use? > [Devin Teske] I read a bunch of RFCs on how manufacturers form their MAC addresses. There is a range of values that will indicate "privately administered" MAC to networking equipment. In my testing over 6 years, I've found that these "privately administered" MAC addresses are not only treated well (read: no issues), but in some cases they hold their DHCP leases far longer than those without this special bit set. In my vimage script: http://druidbsd.sourceforge.net/download.shtml#vimage I have the following formula: # # Set the MAC address of the new interface using a sensible # algorithm to prevent conflicts on the network. # # MAC LAYOUT LP:LL:LB:BB:BB:BB # # Where: # P 2, 6, A, or E but usually 2 # NOTE: Indicates "privately administered" MAC # L ng_bridge(4) link number (1-65535) # B Same as bridged interface # So if we think of a MAC address as 6 octets, there are three goals that this formula/layout is addressing: Goal 1: Set the P nibble to a value of 2, 6, A, or E to indicate that the MaC address is one that is "privately administered" Goal 2: Allow up to 65530** unique MAC addresses to be formed from one single bridged interface. ** This number comes from stress-testing the ng_bridge(4) interface. In a lab, we were able to generate 65530 peers, all visible with ifconfig(8) and ngctl(8). Goal 3: Make the child MAC address look as similar to the parent MAC while satisfying goal 1 and goal 2. It is Goal #2 that gives us the layout requirement to have 2 octets (4 nibbles, aka 16 bits) to store a numeric identifier for a unique MAC address. It is goal #3 that gives us the layout requirement to copy (unmodified) bits from the bridge interface into the child MAC address. However, it is Goal #1 (of utmost importance in our needs) to force the second nibble of the first octet (high order; P in the layout) to a certain value. It was my own personal preference to simply split the 4 nibbles for child identifier so I could group the nibbles from the parent MAC. Resulting in the layout: LP:LL:LB:BB:BB Again, where the disjoint LL:LL represents a number 0-65535 for the LINK or CHILD identifier (first peer is 0, second is 1, so-on), P is locked at 2 (but could easily expand to also use 6, A, or E), and B:BB:BB are bits from the bridge's MAC. For code on calculating it all, see the above link -- written in shell script using bit- wise masking. I think it needless to say that we went overboard... a single system could potentially run 262,120 vimages (dup the vimage rc.d 3x and change the privately administered MAC nibble ``P'' from 2 to 6, then A, then E; each gaining up to 65530 new privately administered MAC address space). -- Devin _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.