From owner-freebsd-net@FreeBSD.ORG Mon Aug 15 20:42:36 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 470D81065677; Mon, 15 Aug 2011 20:42:36 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id F38DC8FC13; Mon, 15 Aug 2011 20:42:35 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p7FKgPT9060780 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 15 Aug 2011 13:42:34 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4E4984B6.9070105@freebsd.org> Date: Mon, 15 Aug 2011 13:42:30 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Gleb Smirnoff References: <20110810160526.GO43567@FreeBSD.org> <5D7408D3-FAA1-4E22-A136-83DC75D47837@tamu.edu> <20110814084813.GA43567@glebius.int.ru> <67BC462C-0F5D-41E2-B739-CFC9EB417FA6@tamu.edu> <20110815120750.GF43567@glebius.int.ru> In-Reply-To: <20110815120750.GF43567@glebius.int.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: David Duchscher , net@freebsd.org Subject: Re: new CARP implementation 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: Mon, 15 Aug 2011 20:42:36 -0000 On 8/15/11 5:07 AM, Gleb Smirnoff wrote: > Hi David and networkers, > > On Sun, Aug 14, 2011 at 03:56:28PM -0500, David Duchscher wrote: > D> > On Sat, Aug 13, 2011 at 07:32:06PM -0500, David Duchscher wrote: > D> > D> My two cents. > D> > D> > D> > D> We rely on the arp load balance feature. We certainly don't find it useless. Looking at ip load balancing, it would also mean that we would no longer be able to grow bandwidth with additional systems since all boxes must receive all traffic. I only humbling ask that some sort of load balancing feature be included when this goes live. > D> > > D> > Ok, I will make effort to support it. I will inform when patch would > D> > be updated. > D> > D> Thank you. > > On closer look it appeared that restoring ARP balancing as it was, isn't going > to be easy. The essence of ARP balancing is that different vhids possess the > same IP address. Converting that to new scheme would mean that same IP prefixes > exist on one interface, which is impossible in current networking stack. And > making it possible would be a bloody hack. > > So I'd prefer to settle current code a bit, commit it to head, after 9.0 is > forked and released... Test and settle code a bit more... And then work on > ARP and IP balancing. That would probably require bringing in some intermediate > structure along with struct carp_softc, that would group softcs into > balancing groups. That is already done in OpenBSD. Not sure that our balancing > would be compatible with OpenBSD's, however the current is not already, since > OpenBSD changed their hashing function after we merged carp(4) to FreeBSD. > on a very slightly related note: I have had some thoughts about changing the model for interfaces so that we in effect have two completely different components. They would be a stack-endpoint and a media interface. Currently both these are combined into a single entity, and for compatibility I think if a split happenned ifcnfnig would continue to handle them both as before but the mapping between them would only be 'by coincidence'. The way to think of this is if one split the interface at the point of the current 'netgraph injection point'. The aim of doing this would be to allow a top end to be left alone, but switched to a different bottom end transparently for example, or multiplexed (or demultiplexed). these things can be done at the moment via netgraph but it's complicated..