From owner-freebsd-current@FreeBSD.ORG Wed Apr 11 21:50:42 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E336B16A400 for ; Wed, 11 Apr 2007 21:50:42 +0000 (UTC) (envelope-from schwabe@uni-paderborn.de) Received: from mail.blinkt.de (mail.blinkt.de [88.198.169.219]) by mx1.freebsd.org (Postfix) with ESMTP id AC53E13C43E for ; Wed, 11 Apr 2007 21:50:42 +0000 (UTC) (envelope-from schwabe@uni-paderborn.de) Received: from dslb-084-061-173-057.pools.arcor-ip.net ([84.61.173.57] helo=taubbook.local) by mail.blinkt.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HbkLX-000C74-Mp; Wed, 11 Apr 2007 23:27:19 +0200 Message-ID: <461D52B6.2080200@uni-paderborn.de> Date: Wed, 11 Apr 2007 23:27:18 +0200 From: Arne Schwabe User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Peter Jeremy , freebsd-current@freebsd.org References: <20070402092830.GB28809@heff.fud.org.nz> <20070411191450.GE815@turion.vk2pj.dyndns.org> In-Reply-To: <20070411191450.GE815@turion.vk2pj.dyndns.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 11 Apr 2007 22:04:23 +0000 Cc: Subject: Re: CFT: new trunk(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2007 21:50:43 -0000 > Trunking is a way of combining multiple physical interfaces to increase > the bandwidth. Trunking multiple VLANs on a single interface doesn't > make sense to me. > Cisco calls this Trunk (multiple vlans over one physical connection (with dot1q)). Combining multiple physical links is called channel. Maybe that is were the confusion comes from. > At least some of the proprietary protocols > are fairly dumb and just round-robin MAC addresses between the > physical links rather than dynamically sharing traffic across the > available links. The former means that if most or all of your traffic > is for a single MAC address, you don't actually gain anything by > having multiple physical links. I have seen things break if you do real round robin, some pxe boot stuff and other embedded tcp/ip stack which are intended for local network use only don't like if packets are out of order, which sometimes hapens with link aggration and somehting that is not ensuring the right order (with stupid hash for example). Arne Arne