Date: Tue, 21 Apr 2009 23:01:02 +0200 From: Sebastiaan van Erk <sebster@sebster.com> To: Stanislav Sedov <stas@FreeBSD.org> Cc: freebsd-cluster@freebsd.org Subject: Re: pf and carp, BACKUP host dropping connection Message-ID: <49EE340E.4090006@sebster.com> In-Reply-To: <20090421123735.f7caf3cc.stas@FreeBSD.org> References: <49EC68B6.9090303@sebster.com> <20090421123735.f7caf3cc.stas@FreeBSD.org>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] Stanislav Sedov wrote: > On Mon, 20 Apr 2009 14:21:10 +0200 > Sebastiaan van Erk <sebster@sebster.com> mentioned: >> I think once I have pfsync the problem will go away due to the >> synchronized state (the backups won't block anymore), but it still seems >> strange to me that all 3 machines will then be actively filtering the >> packets... >> >> Does anybody know what's going on? >> > > I'd suggest to look first why all of them're receiving this traffic. It > looks like something is not right in the network itself. After reading about CARP some more, I think that's the expected behavior: --- http://www.openbsd.org/faq/faq6.html#CARP --- How it works: CARP is a multicast protocol. It groups several physical computers together under one or more virtual addresses. Of these, one system is the master and responds to all packets destined for the group, the other systems act as hot spares. --- http://www.openbsd.org/faq/faq6.html#CARP --- Since I don't have pfsync enabled yet the other two machines don't have the propper state and will drop the connection. Normally this would only pollute the log, but on the internal networks I don't want connections to hang for long periods so I do "block return". This causes pf to respond to the traffic since it doesn't know anything about the machine being a carp backup, and thus the originating host receives a RST and drops the connection. I'm wondering if the combination block return + carp is going to work at all, even with pfsync... I will do some more research on that. Regards, Sebastiaan [-- Attachment #2 --] 0 *H 01 0 + 0 *H Q00lS| 6$1-~j0 *H 0b1 0 UZA1%0#U Thawte Consulting (Pty) Ltd.1,0*U#Thawte Personal Freemail Issuing CA0 080630135157Z 090630135157Z0h10Uvan Erk10U* Sebastiaan10USebastiaan van Erk1"0 *H sebster@sebster.com0"0 *H 0 Va\bEnݚa<M8ʄ^tv>x73bohi2oqS_¶Bm^p* I x"9 pt!j ar#)n)^? 'z<).+Ѐ4ig R'UP*\Ւ ,?.;?f BܯTzM IDվCK*3Yŧ mcaztxʐsq/ 00.0 U 0sebster@sebster.com0 U 0 0 *H KT4W6ӽq] tS` %f1 G:H b zJj$EjE'JV~-VbVnJZ E/`@@04!+T: c پf`$Z=1#|oG[OB RG00lS| 6$1-~j0 *H 0b1 0 UZA1%0#U Thawte Consulting (Pty) Ltd.1,0*U#Thawte Personal Freemail Issuing CA0 080630135157Z 090630135157Z0h10Uvan Erk10U* Sebastiaan10USebastiaan van Erk1"0 *H sebster@sebster.com0"0 *H 0 Va\bEnݚa<M8ʄ^tv>x73bohi2oqS_¶Bm^p* I x"9 pt!j ar#)n)^? 'z<).+Ѐ4ig R'UP*\Ւ ,?.;?f BܯTzM IDվCK*3Yŧ mcaztxʐsq/ 00.0 U 0sebster@sebster.com0 U 0 0 *H KT4W6ӽq] tS` %f1 G:H b zJj$EjE'JV~-VbVnJZ E/`@@04!+T: c پf`$Z=1#|oG[OB RG0?0 0 *H 01 0 UZA10U Western Cape10U Cape Town10U Thawte Consulting1(0&U Certification Services Division1$0"UThawte Personal Freemail CA1+0) *H personal-freemail@thawte.com0 030717000000Z 130716235959Z0b1 0 UZA1%0#U Thawte Consulting (Pty) Ltd.1,0*U#Thawte Personal Freemail Issuing CA00 *H 0 Ħ<UsUNʙZ hup [v :aQP 0cZ,p+Z?qV˯< 6$*+w=+>@dקe*TH<a@ dr` 00U 0 0CU <0:08642http://crl.thawte.com/ThawtePersonalFreemailCA.crl0 U 0)U "0 0 10UPrivateLabel2-1380 *H HP . fgCL!6 -6/ P p<ab:~ t%Pb'qW%ݩ9 Oe_N4[5MwV!x!5$ F]_eO1q0m0v0b1 0 UZA1%0#U Thawte Consulting (Pty) Ltd.1,0*U#Thawte Personal Freemail Issuing CAS| 6$1-~j0 + 0 *H 1 *H 0 *H 1 090421210102Z0# *H 1M)_(S eu0_ *H 1R0P0 `He0 *H 0*H 0 *H @0+0 *H (0 +71x0v0b1 0 UZA1%0#U Thawte Consulting (Pty) Ltd.1,0*U#Thawte Personal Freemail Issuing CAS| 6$1-~j0 *H 1xv0b1 0 UZA1%0#U Thawte Consulting (Pty) Ltd.1,0*U#Thawte Personal Freemail Issuing CAS| 6$1-~j0 *H 35`"7thZEv[U+%; ZX,(HhyBwыݠBmөұAYSm378u}\mj i{mDuZփgz氲p8pVZ C8RU8- ߰]~PpuLcW8ru&nF/Ϲ nm4c]P ܭ6KNfB_wZ2Phelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49EE340E.4090006>