new CARP implementation

[Julian Elischer]

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..