Date: Fri, 16 Dec 2011 12:08:17 -0500 From: Ben Kaduk <minimarmot@gmail.com> To: Gleb Smirnoff <glebius@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r228571 - in head: . lib/libc/net sbin/ifconfig share/man/man4 sys/net sys/netinet sys/netinet6 sys/sys Message-ID: <CAK2BMK5RjFwDuYX49FLZerV8ai%2B%2BKu9Qfzpb4D_r2OnikuGg_A@mail.gmail.com> In-Reply-To: <201112161216.pBGCGu8B006328@svn.freebsd.org> References: <201112161216.pBGCGu8B006328@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/16/11, Gleb Smirnoff <glebius@freebsd.org> wrote: > Author: glebius > Date: Fri Dec 16 12:16:56 2011 > New Revision: 228571 > URL: http://svn.freebsd.org/changeset/base/228571 > > Log: > A major overhaul of the CARP implementation. The ip_carp.c was started > from scratch, copying needed functionality from the old implemenation > on demand, with a thorough review of all code. The main change is that > interface layer has been removed from the CARP. Now redundant addresses > are configured exactly on the interfaces, they run on. > > The CARP configuration itself is, as before, configured and read via > SIOCSVH/SIOCGVH ioctls. A new prefix created with SIOCAIFADDR or > SIOCAIFADDR_IN6 may now be configured to a particular virtual host id, > which makes the prefix redundant. > > ifconfig(8) semantics has been changed too: now one doesn't need > to clone carpXX interface, he/she should directly configure a vhid > on a Ethernet interface. > > To supply vhid data from the kernel to an application the getifaddrs(8) > function had been changed to pass ifam_data with each address. [1] > > The new implementation definitely closes all PRs related to carp(4) > being an interface, and may close several others. It also allows > to run a single redundant IP per interface. > > Big thanks to Bjoern Zeeb for his help with inet6 part of patch, for > idea on using ifam_data and for several rounds of reviewing! > > PR: kern/117000, kern/126945, kern/126714, kern/120130, kern/117448 > Reviewed by: bz > Submitted by: bz [1] > > Modified: > head/UPDATING > head/lib/libc/net/getifaddrs.c > head/sbin/ifconfig/af_inet.c > head/sbin/ifconfig/af_inet6.c > head/sbin/ifconfig/ifcarp.c > head/sbin/ifconfig/ifconfig.8 > head/sbin/ifconfig/ifconfig.c > head/sbin/ifconfig/ifconfig.h > head/share/man/man4/carp.4 > head/sys/net/if.c > head/sys/net/if.h > head/sys/net/if_ethersubr.c > head/sys/net/if_types.h > head/sys/net/if_var.h > head/sys/net/rtsock.c > head/sys/netinet/if_ether.c > head/sys/netinet/if_ether.h > head/sys/netinet/in.c > head/sys/netinet/in_var.h > head/sys/netinet/ip_carp.c > head/sys/netinet/ip_carp.h > head/sys/netinet6/in6.c > head/sys/netinet6/in6_ifattach.c > head/sys/netinet6/in6_var.h > head/sys/netinet6/nd6.c > head/sys/netinet6/nd6_nbr.c > head/sys/sys/param.h > > Modified: head/UPDATING > ============================================================================== ============================== > --- head/share/man/man4/carp.4 Fri Dec 16 11:52:33 2011 (r228570) > +++ head/share/man/man4/carp.4 Fri Dec 16 12:16:56 2011 (r228571) > @@ -1,6 +1,7 @@ > .\" $OpenBSD: carp.4,v 1.16 2004/12/07 23:41:35 jmc Exp $ > .\" > .\" Copyright (c) 2003, Ryan McBride. All rights reserved. > +.\" Copyright (c) 2011, Gleb Smirnoff <glebius@FreeBSD.org> > .\" > .\" Redistribution and use in source and binary forms, with or without > .\" modification, are permitted provided that the following conditions > @@ -138,36 +131,36 @@ Value of 0 means that preemption is not > problems are detected. > Every problem increments suppression counter. > .El > -.Sh ARP level load balancing > -The > -.Nm > -has limited abilities for load balancing the incoming connections > -between hosts in Ethernet network. > -For load balancing operation, one needs several CARP interfaces that > -are configured to the same IP address, but to a different VHIDs. > -Once an ARP request is received, the CARP protocol will use a hashing > -function against the source IP address in the ARP request to determine > -which VHID should this request belong to. > -If the corresponding CARP interface is in master state, the ARP request > -will be replied, otherwise it will be ignored. > -See the > -.Sx EXAMPLES > -section for a practical example of load balancing. > -.Pp > -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. > -Second, ARP load balancing can lead to asymmetric routing > -of incoming and outgoing traffic, and thus combining it with > -.Xr pfsync 4 > -is dangerous, because this creates a race condition between > -balanced routers and a host they are serving. > -Imagine an incoming packet creating state on the first router, being > -forwarded to its destination, and destination replying faster > -than the state information is packed and synced with the second router. > -If the reply would be load balanced to second router, it will be > -dropped due to no state. > +.\".Sh ARP level load balancing > +.\"The > +.\".Nm > +.\"has limited abilities for load balancing the incoming connections > +.\"between hosts in Ethernet network. > +.\"For load balancing operation, one needs several CARP interfaces that > +.\"are configured to the same IP address, but to a different vhids. > +.\"Once an ARP request is received, the CARP protocol will use a hashing > +.\"function against the source IP address in the ARP request to determine > +.\"which vhid should this request belong to. > +.\"If the corresponding CARP interface is in master state, the ARP request > +.\"will be replied, otherwise it will be ignored. > +.\"See the > +.\".Sx EXAMPLES > +.\"section for a practical example of load balancing. > +.\".Pp > +.\"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. > +.\"Second, ARP load balancing can lead to asymmetric routing > +.\"of incoming and outgoing traffic, and thus combining it with > +.\".Xr pfsync 4 > +.\"is dangerous, because this creates a race condition between > +.\"balanced routers and a host they are serving. > +.\"Imagine an incoming packet creating state on the first router, being > +.\"forwarded to its destination, and destination replying faster > +.\"than the state information is packed and synced with the second router. > +.\"If the reply would be load balanced to second router, it will be > +.\"dropped due to no state. > .Sh STATE CHANGE NOTIFICATIONS > Sometimes it is useful to get notified about > .Nm Hi Gleb, Perhaps the man page portions that were commented out should just be removed entirely? -Ben Kaduk
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAK2BMK5RjFwDuYX49FLZerV8ai%2B%2BKu9Qfzpb4D_r2OnikuGg_A>