svn commit: r228571 - in head: . lib/libc/net sbin/ifconfig
share/man/man4 sys/net sys/netinet sys/netinet6 sys/sys
Ben Kaduk
minimarmot at gmail.com
Fri Dec 16 17:08:18 UTC 2011
On 12/16/11, Gleb Smirnoff <glebius at 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 at 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
More information about the svn-src-head
mailing list