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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"