Date: Mon, 10 Jun 2013 12:54:30 +1000 From: Cameron Simpson <cs@zip.com.au> To: "Eugene M. Zheganin" <emz@norma.perm.ru> Cc: freebsd-net@freebsd.org Subject: Re: carp regression in 9.1 ? Message-ID: <20130610025430.GA96587@cskk.homeip.net> In-Reply-To: <5146F61E.3040601@norma.perm.ru> References: <5146F61E.3040601@norma.perm.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On 18Mar2013 17:10, Eugene M. Zheganin <emz@norma.perm.ru> wrote:
| This is of course up to you to decide, but I feel like I should
| encourage you - 10.x isn't that scarry as it seems to be. I also run
| it on a production (though my production may be not as harsh as
| yours) [...]
| At least, after upgrade from 9.1-STABLE to a random -CURRENT I
| didn't notice any degradation, only improvements. I had all of your
| fears right before the upgrade, none of it became real.
I'm looking at putting in a 9.1 FreeBSD as a new firewall soon
and have only just discovered this possible CARP regression.
Can someone inform me on the following questions:
- does simple CARP (one address) work?
- if I do not destroy and recreate CARP interfaces, does it work?
- if I want to try 10.x, is it enough to build a 10.x kernel and
boot that without making changes to userland?
The partner firewall is running FreeBSD 8.1 and will be staying
that way for a while.
Finally, out of interest, does 10.x address a bug I found (but have
not yet written up and reported, alas) to do with how CARP chooses
the physical interface for its packets?
We did some debugging on a longstanding problem we had in January,
and it appears that CARP is choosing the physical interface naively:
just checking if the CARP address is in the network and not consulting
the netmask. It should be doing as the IP routing code does, but
it does not.
We have a /25 with a smaller subnet of it on our exterior link and
another subnet on an internal DMZ; the main LAN runs the wider /25.
All perfectly sane, but CARP's choice of interface for a given
address is subject to hardware order; leaving aside CARP choosing
the wrong iterface outright, the machines are not physically identical
and therefore CARP can pick different physical networks on each
machine, causing neither side to see the peer and both sides to go
MASTER. A cursor read of the carp code later seemed to support what
out testing with tcpdump showed.
Cheers,
--
Cameron Simpson <cs@zip.com.au>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130610025430.GA96587>