Date: Wed, 2 Mar 2005 11:10:51 +0300 From: Gleb Smirnoff <glebius@FreeBSD.org> To: Matthew Grooms <mgrooms@seton.org> Cc: freebsd-pf@FreeBSD.org Subject: Re: Fwd: pf + pfsync + carp testing ... Message-ID: <20050302081051.GB87159@cell.sick.ru> In-Reply-To: <4225174C.801@seton.org> References: <200502282232.17646.max@love2party.net> <4223931C.9000607@seton.org> <200502282326.41760.max@love2party.net> <4224B078.9020301@seton.org> <20050301185431.GA81982@cell.sick.ru> <4225174C.801@seton.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 01, 2005 at 07:30:52PM -0600, Matthew Grooms wrote: M> Thanks for the response. I have net.inet.carp.preempt=1 set but M> only one carp interface changes state to master at a time. The second M> host always retains the master for the other two carp interfaces. I am M> able to manually fail over the remaining carp interfaces by changing M> either the carp or parent em[n] interface to down which quickly brings M> the other hosts corresponding interface from backup to master. After a M> firewall holds a master status for all carp devices, I can start to talk M> again through the firewall out to the internet or into the DMZ from my M> test pc. M> M> I have two Dell SMP boxes running dual amd64 compatible intel processors M> with two on board intel ports ( em0 & em1 ) and a quad port intel pro M> 1000 MT ( em2, em3, em4 & em5 ). I am using RELENG_5 amd64 SMP builds on M> both hosts. Here is my config info ... You have that damn em interfaces, which are mot miibus aware. In the patch there is also a small hack in if_em.c to workaround this problem. Can you check please that this part of the patch has successfully applied to your tree and went into your if_em.ko (or kernel)? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050302081051.GB87159>