From owner-freebsd-net@FreeBSD.ORG Wed Mar 28 00:43:11 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A414F16A400 for ; Wed, 28 Mar 2007 00:43:11 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 68A6B13C45D for ; Wed, 28 Mar 2007 00:43:11 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 6F2D820CB65; Tue, 27 Mar 2007 20:43:11 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 27 Mar 2007 20:43:11 -0400 X-Sasl-enc: /JV+OR/jMZl7X3LZ27UJk6cYXPK6QKzE9x7Rr/Fip4f/ 1175042591 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id BF1A21A101; Tue, 27 Mar 2007 20:43:10 -0400 (EDT) Message-ID: <4609BA1C.3060405@FreeBSD.org> Date: Wed, 28 Mar 2007 01:43:08 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: Andrea Venturoli References: <3DDDCC38D00FA545A6C012475EF2DC0302AF8F55@LQEVS1.gcapmedia.com> <46092E46.4090502@dir.bg> <46098962.3040707@netfence.it> In-Reply-To: <46098962.3040707@netfence.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jordan Gordeev , Ross Draper , freebsd-net@freebsd.org Subject: Re: Vrrp/CARP/ucarp Problems 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: Wed, 28 Mar 2007 00:43:11 -0000 Andrea Venturoli wrote: > Jordan Gordeev wrote: >> The only load balancing that CARP supports, to my knowledge, is ARP >> level load balancing. From carp(4): >> The ARP load balancing has some limitations. First, ARP balancing only >> works on the local network segment. It cannot balance traffic that >> crosses a router, because the router itself will always be >> balanced to >> the same virtual host. > > Forgive me for stepping in, but I had read the above statement over > and over trying to figure what it meant; perhaps it's not so clear... > > If I understood it correctly it's not saying you should not use CARP > on routers. Instead it's meaning that load-balancing won't cross a > third router which is on cascade of the two CARP routers. ... Andrea, you are correct. Jordan is pointing out the main limitation of CARP, which is that it operates only within a broadcast domain. I should point out such a feature is out of scope for VRRP, CARP, IPMP or other Layer 2 IP sharing protocol. However this behaviour is just fine for load balancing a router, in which case one relies on next-hop reachability anyway. The thing to remember with CARP is that it relies on the ability of the interface to go into promiscuous mode to pick up traffic for its virtual MAC addresses. More modern cards may support more than one station address in hardware, which avoids the need for promiscuous mode processing, however we don't currently support this hardware feature. If one wishes to load balance across Layer 3 hops (rather than within the same broadcast domain), what one is asking for is a feature like BGP4 Anycast, IPv6 Anycast, or OSPF-based Anycast which relies on cooperating routers to inject a route into the Layer 3 routing domain for a given 'virtual' IP address. There is a daemon out there which uses the OSPF API in Quagga to flood OSPF domains with virtual host routes for anycasting services using Opaque LSAs but I forget its name. XORP has the potential to do the same but requires some development effort to do so. If one wishes to load balance specific requests for an application layer service, one enters the wonderful world of 'middleware' and competing commercial solutions to the problem. And this is where money comes into play... Regards, BMS