From owner-freebsd-virtualization@FreeBSD.ORG Fri Jun 28 17:29:52 2013 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 01D2D8C6 for ; Fri, 28 Jun 2013 17:29:51 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from alto.onthenet.com.au (alto.OntheNet.com.au [203.13.68.12]) by mx1.freebsd.org (Postfix) with ESMTP id BA2BA1A42 for ; Fri, 28 Jun 2013 17:29:51 +0000 (UTC) Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57]) by alto.onthenet.com.au (Postfix) with ESMTPS id 0FCE812269; Sat, 29 Jun 2013 03:29:51 +1000 (EST) Received: from Peter-Grehans-MacBook-Pro.local ([64.245.0.210]) by dommail.onthenet.com.au (MOS 4.2.4-GA) with ESMTP id BMZ71348 (AUTH peterg@ptree32.com.au); Sat, 29 Jun 2013 03:29:50 +1000 Message-ID: <51CDC80C.7070709@freebsd.org> Date: Fri, 28 Jun 2013 10:29:48 -0700 From: Peter Grehan User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: Aryeh Friedman Subject: Re: questions on if_bridge and if_tap References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-virtualization@freebsd.org X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.14 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: Fri, 28 Jun 2013 17:29:52 -0000 > 1. Is there a upper limit on the number of bridges and/or taps and if > so what is it? The if_index field for an interface is 16 bits so I guess there may be an upper bound of 64K. That might start to stretch limits of FreeBSD in other areas. > 2. Does each tap need a corresponding bridge or can they all go > through the same bridge? They can all go through the same bridge if that's what you want (the same broadcoast domain). later, Peter.