From owner-freebsd-net@FreeBSD.ORG Sun Jun 5 16:27:44 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 04A6F16A41C; Sun, 5 Jun 2005 16:27:44 +0000 (GMT) (envelope-from bms@spc.org) Received: from arginine.spc.org (arginine.spc.org [83.167.185.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F23B43D4C; Sun, 5 Jun 2005 16:27:42 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 13D95651F4; Sun, 5 Jun 2005 17:25:42 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 84704-02-3; Sun, 5 Jun 2005 17:25:41 +0100 (BST) Received: from empiric.dek.spc.org (82-35-114-35.cable.ubr07.dals.blueyonder.co.uk [82.35.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id EBC41651EE; Sun, 5 Jun 2005 17:25:39 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id C01DC61E6; Sun, 5 Jun 2005 17:27:34 +0100 (BST) Date: Sun, 5 Jun 2005 17:27:34 +0100 From: Bruce M Simpson To: Julian Elischer Message-ID: <20050605162734.GA773@empiric.icir.org> Mail-Followup-To: Julian Elischer , Andrew Thompson , freebsd-net@freebsd.org References: <20050603020140.GA22870@heff.fud.org.nz> <42A0C4F4.8010009@elischer.org> <20050603211400.GA26676@heff.fud.org.nz> <42A0CE82.5040306@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42A0CE82.5040306@elischer.org> Cc: freebsd-net@freebsd.org, Andrew Thompson Subject: Re: xxconfig for if_bridge 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: Sun, 05 Jun 2005 16:27:44 -0000 Hi, Many of these points were covered in the thread from over a year ago which Andrew helpfully posted the link to. On Fri, Jun 03, 2005 at 02:41:22PM -0700, Julian Elischer wrote: > and I still don't see why it is better to import Yet another bridge > module rather > than adding it to the 2 we already have. > You can do things with ng_bridge that you can't do with if_bridge.. > for example bridge together 3 remote sites connected by ipsec tunnels. Don't get me wrong, I'm not knocking Netgraph -- it is a nice concept, but it needs more work in order to offer our users the same performance as more traditional ifnet layer code. It is also obscure to configure for many of our users. I think the benefits are quite concrete and speak for themselves. 1) Common code with NetBSD and OpenBSD. This should be obvious -- code which has been shown to be good in these other two BSDs will enable us to pick up fixes and improvements from those lines of development. Where Netgraph bridge implementations are concerned, it has to be pointed out: Netgraph is not part of NetBSD or OpenBSD, so further development of ng_bridge(4) does not offer this particular benefit. 2) Working firewall support through the use of the appropriate mbuf tags. Whilst this is something which may be *possible* with Netgraph, I have yet to see working code for it, which is why I'm puzzled by the persistent argument of 'you should do it with Netgraph!' by the Netgraph devotees. 3) New features, particularly spanning tree. Not only have we been behind the other BSDs in terms of feature set, we've also been behind Linux. Spanning Tree is one of the real wins from importing if_bridge(4). 4) It serves as a good example and basis of how to do Layer 2 things at the ifnet layer for future projects. Based on my reading of the code, it's cleaner than bridge(4). if_bridge(4) incorporates spanning tree as above -- this is a concrete starting point for doing things like 802.11s Mesh. The forwarding table for spanning tree has a clear logical separation from the existing ARP code. 5) It does not suffer from the same issues which bridge(4) has had. bridge(4) has had a number of issues. In particular I'm thinking of things such as disabling and reenabling hardware checksumming. 6) Performance is roughly equal and in some cases better than bridge(4). With this in mind, bridge(4) should be deprecated sooner than later -- I would hope that 6-CURRENT gets enough test coverage that this can happen either in time for 6-RELEASE, if not 7. Regards, BMS