From owner-freebsd-cluster@FreeBSD.ORG Mon Apr 20 12:21:14 2009 Return-Path: Delivered-To: freebsd-cluster@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EF0010656FC for ; Mon, 20 Apr 2009 12:21:14 +0000 (UTC) (envelope-from sebster@sebster.com) Received: from mail.sebster.com (mail.sebster.com [193.46.80.82]) by mx1.freebsd.org (Postfix) with SMTP id D02728FC20 for ; Mon, 20 Apr 2009 12:21:13 +0000 (UTC) (envelope-from sebster@sebster.com) Received: (qmail 85050 invoked from network); 20 Apr 2009 12:21:11 -0000 Received: from unknown (HELO ?10.0.1.6?) (sebster@85.147.225.232) by 10.0.98.3 with SMTP; 20 Apr 2009 12:21:11 -0000 Message-ID: <49EC68B6.9090303@sebster.com> Date: Mon, 20 Apr 2009 14:21:10 +0200 From: Sebastiaan van Erk User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: freebsd-cluster@freebsd.org Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070809010008080803090806" Subject: pf and carp, BACKUP host dropping connection X-BeenThere: freebsd-cluster@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Clustering FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 12:21:15 -0000 This is a cryptographically signed message in MIME format. --------------ms070809010008080803090806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I have 3 hosts set up with 1 virtual IP using carp. I don't yet have pfsync (which I'm planning to do next). However, there is a strange behavior that I cannot understand. The 3 machines are all gateways between two networks and have 2 VIP ips which are used for routing (actually they have 4 networks and 4 VIPs, but only 2 are relevant in this case). When I ssh from one network to the other however, connections are sometimes blocked by pf. However, they're dropped on the machine which is NOT currently master! That is, I have machines: 1) carp1: flags=49 metric 0 mtu 1500 inet 10.0.80.74 netmask 0xffffff00 carp: MASTER vhid 2 advbase 1 advskew 0 carp3: flags=49 metric 0 mtu 1500 inet 10.0.82.74 netmask 0xffffff00 carp: MASTER vhid 4 advbase 1 advskew 0 2) carp0: flags=49 metric 0 mtu 1500 inet 212.61.136.74 netmask 0xfffffff0 carp: BACKUP vhid 1 advbase 1 advskew 50 carp2: flags=49 metric 0 mtu 1500 inet 10.0.81.74 netmask 0xffffff00 carp: BACKUP vhid 3 advbase 1 advskew 50 3) carp1: flags=49 metric 0 mtu 1500 inet 10.0.80.74 netmask 0xffffff00 carp: BACKUP vhid 2 advbase 1 advskew 100 carp3: flags=49 metric 0 mtu 1500 inet 10.0.82.74 netmask 0xffffff00 carp: BACKUP vhid 4 advbase 1 advskew 100 Then from the 10.0.80 network I do a ssh to the 10.0.82 network. The router for the 10.0.82 network is 10.0.82.74 and the router for the 10.0.80 network is 10.0.80.74 (the VIPs): > ssh 10.0.82.5 sebster@10.0.82.5's password: > Read from remote host 10.0.82.5: Connection reset by peer Connection to 10.0.82.5 closed. And then I get on the backup gateways pf log: machine 2: # tcpdump -nttteli pflog0 not src or dst port 6155 and not src or dst host 224.0.0.18 and not src or dst port 68 tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 96 bytes 000000 rule 11/0(match): block in on em1: 10.0.80.3.58876 > 10.0.82.5.22: [|tcp] 001161 rule 11/0(match): block in on em1: 10.0.80.3.58876 > 10.0.82.5.22: [|tcp] 000018 rule 11/0(match): block in on em1: 10.0.80.3.58876 > 10.0.82.5.22: tcp 20 [bad hdr length 0 - too short, < 20] machine 3: # tcpdump -nttteli pflog0 not src or dst port 6155 and not src or dst host 224.0.0.18 and not src or dst port 68 tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 96 bytes 000000 rule 11/0(match): block in on em1: 10.0.80.3.58876 > 10.0.82.5.22: [|tcp] 001113 rule 11/0(match): block in on em1: 10.0.80.3.58876 > 10.0.82.5.22: [|tcp] 000019 rule 11/0(match): block in on em1: 10.0.80.3.58876 > 10.0.82.5.22: tcp 20 [bad hdr length 0 - too short, < 20] I'm wondering why these backup hosts are blocking these packets, even though the master is still up, and why they are causing the connection to fail. (The pf on all 3 hosts do a "block return log on devif all" where devif is the interface with the real 10.0.80.x ip; however, why is it returning a RST packet when it's backup?). 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? Regards, Sebastiaan --------------ms070809010008080803090806 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUTCC AwMwggJsoAMCAQICEFN8DarMNuuKJDEtfs0UaqUwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDYzMDEzNTE1N1oX DTA5MDYzMDEzNTE1N1owaDEQMA4GA1UEBBMHdmFuIEVyazETMBEGA1UEKhMKU2ViYXN0aWFh bjEbMBkGA1UEAxMSU2ViYXN0aWFhbiB2YW4gRXJrMSIwIAYJKoZIhvcNAQkBFhNzZWJzdGVy QHNlYnN0ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsJDDAeYHVmH/ GVxi+bhFx27dmg++9BdhPJfk8k041sqEqq7oXnR2GT54quY3Ac7A1BuOM2JvoICraGmjud4y b3EanRnqGIK6iH+VAhhTlV/Owrb2Qm1e13DLxwLp1SocSQl4IrEbF9Y5H3ASdIrE0iFqkpju nPiiHeNhz3LaI5ipjiluKYoH+F6gPx8njHoaDxPePCkSLg4r0IA0afLM74LVZxCRBZEfyRZS J6VVUJefKlz91dWSzR/3xSw/rO4u9Ds/Zh7VBUKy3K+YFryHxRpUek0gSepE1b70Q39L9Sqd M/NZqMvFpwrqgW2Zh2Nh8nqRge90maR4ypBzz3GzLwIDAQABozAwLjAeBgNVHREEFzAVgRNz ZWJzdGVyQHNlYnN0ZXIuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAS1Sk NMgDVzb0ktO9tPPacV0KdKhTYOHcICVmuDEe2sFHOkjLAI1iAKp640pqJEVqvRnfRcCFJ9hK koPjjVZ+ui2rVmJWBG6FSloLRS/YYED4tUAw6DQhK61UOpjkpQxjCdm+5bHG/2ZgJAda1j0x uiN822+xFkcaW/5PQgxSRxcwggMDMIICbKADAgECAhBTfA2qzDbriiQxLX7NFGqlMA0GCSqG SIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QTAeFw0wODA2MzAxMzUxNTdaFw0wOTA2MzAxMzUxNTdaMGgxEDAOBgNVBAQTB3ZhbiBFcmsx EzARBgNVBCoTClNlYmFzdGlhYW4xGzAZBgNVBAMTElNlYmFzdGlhYW4gdmFuIEVyazEiMCAG CSqGSIb3DQEJARYTc2Vic3RlckBzZWJzdGVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALCQwwHmB1Zh/xlcYvm4Rcdu3ZoPvvQXYTyX5PJNONbKhKqu6F50dhk+eKrm NwHOwNQbjjNib6CAq2hpo7neMm9xGp0Z6hiCuoh/lQIYU5VfzsK29kJtXtdwy8cC6dUqHEkJ eCKxGxfWOR9wEnSKxNIhapKY7pz4oh3jYc9y2iOYqY4pbimKB/heoD8fJ4x6Gg8T3jwpEi4O K9CANGnyzO+C1WcQkQWRH8kWUielVVCXnypc/dXVks0f98UsP6zuLvQ7P2Ye1QVCstyvmBa8 h8UaVHpNIEnqRNW+9EN/S/UqnTPzWajLxacK6oFtmYdjYfJ6kYHvdJmkeMqQc89xsy8CAwEA AaMwMC4wHgYDVR0RBBcwFYETc2Vic3RlckBzZWJzdGVyLmNvbTAMBgNVHRMBAf8EAjAAMA0G CSqGSIb3DQEBBQUAA4GBAEtUpDTIA1c29JLTvbTz2nFdCnSoU2Dh3CAlZrgxHtrBRzpIywCN YgCqeuNKaiRFar0Z30XAhSfYSpKD441Wfrotq1ZiVgRuhUpaC0Uv2GBA+LVAMOg0ISutVDqY 5KUMYwnZvuWxxv9mYCQHWtY9MbojfNtvsRZHGlv+T0IMUkcXMIIDPzCCAqigAwIBAgIBDTAN BgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTES MBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UE CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTX p6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYB Af8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBl cnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYD VQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2as Zw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT HUb/XV9lTzGCA3EwggNtAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBJc3N1aW5nIENBAhBTfA2qzDbriiQxLX7NFGqlMAkGBSsOAwIaBQCgggHQMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDQyMDEyMjExMFowIwYJKoZI hvcNAQkEMRYEFJv4JEtSVOnaQ4i6vb4qRNlB4zVtMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEFN8DarMNuuKJDEtfs0UaqUwgYcGCyqG SIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECEFN8DarMNuuKJDEtfs0UaqUwDQYJKoZIhvcNAQEBBQAEggEAJwuSZW57hUN9CWiA OfN4uBm46h8TgYV7eDS8zIeyv/rpo2mF+fvtiypOSjseFf/Dxnnilp0Ycfm3YfSaubc9av5P j+OwrDwmj+1wqhVp0WH5pzshNPiESgGFIiEx8dk36Eub0N6Xxa96VBepb86//J+lS3RJ5lma Z9bu4oJgS63IfiIZQNzfIqJ2iHdrsooE4t59r2U/MT1BcrgSaxbxSdj6cSejotobM8vAxdwX nIkilS0KOxd0K/ftXrp7Bl/+xyShhuZs2/dyiBvfaWlRZsSwgQErIwtdN+TmdDx1bBzDrnku DuEY0aE7VJLDAcS3SdpgJlGkkZs1S8Pw/n5/OgAAAAAAAA== --------------ms070809010008080803090806-- From owner-freebsd-cluster@FreeBSD.ORG Tue Apr 21 08:37:36 2009 Return-Path: Delivered-To: freebsd-cluster@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D7E4106566C for ; Tue, 21 Apr 2009 08:37:36 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from mx0.deglitch.com (backbone.deglitch.com [IPv6:2001:16d8:fffb:4::abba]) by mx1.freebsd.org (Postfix) with ESMTP id C39E58FC18 for ; Tue, 21 Apr 2009 08:37:35 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from DSPAM-Daemon (localhost [127.0.0.1]) by mx0.deglitch.com (Postfix) with SMTP id C17268FC2B for ; Tue, 21 Apr 2009 12:37:33 +0400 (MSD) Received: from orion.SpringDaemons.com (unknown [77.232.3.143]) by mx0.deglitch.com (Postfix) with ESMTPA id 244EE8FC18; Tue, 21 Apr 2009 12:37:32 +0400 (MSD) Received: from orion (localhost [127.0.0.1]) by orion.SpringDaemons.com (Postfix) with SMTP id 3F17439832; Tue, 21 Apr 2009 12:37:35 +0400 (MSD) Date: Tue, 21 Apr 2009 12:37:35 +0400 From: Stanislav Sedov To: Sebastiaan van Erk Message-Id: <20090421123735.f7caf3cc.stas@FreeBSD.org> In-Reply-To: <49EC68B6.9090303@sebster.com> References: <49EC68B6.9090303@sebster.com> Organization: The FreeBSD Project X-XMPP: ssedov@jabber.ru X-Voice: +7 916 849 20 23 X-PGP-Fingerprint: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-DSPAM-Result: Innocent X-DSPAM-Processed: Tue Apr 21 12:37:33 2009 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 49ed85cd967001477745436 Cc: freebsd-cluster@freebsd.org Subject: Re: pf and carp, BACKUP host dropping connection X-BeenThere: freebsd-cluster@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Clustering FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 08:37:36 -0000 On Mon, 20 Apr 2009 14:21:10 +0200 Sebastiaan van Erk mentioned: > Hi, > > I have 3 hosts set up with 1 virtual IP using carp. I don't yet have > pfsync (which I'm planning to do next). However, there is a strange > behavior that I cannot understand. > > The 3 machines are all gateways between two networks and have 2 VIP ips > which are used for routing (actually they have 4 networks and 4 VIPs, > but only 2 are relevant in this case). When I ssh from one network to > the other however, connections are sometimes blocked by pf. However, > they're dropped on the machine which is NOT currently master! > > That is, I have machines: > > 1) > carp1: flags=49 metric 0 mtu 1500 > inet 10.0.80.74 netmask 0xffffff00 > carp: MASTER vhid 2 advbase 1 advskew 0 > carp3: flags=49 metric 0 mtu 1500 > inet 10.0.82.74 netmask 0xffffff00 > carp: MASTER vhid 4 advbase 1 advskew 0 > > 2) > carp0: flags=49 metric 0 mtu 1500 > inet 212.61.136.74 netmask 0xfffffff0 > carp: BACKUP vhid 1 advbase 1 advskew 50 > carp2: flags=49 metric 0 mtu 1500 > inet 10.0.81.74 netmask 0xffffff00 > carp: BACKUP vhid 3 advbase 1 advskew 50 > > 3) > carp1: flags=49 metric 0 mtu 1500 > inet 10.0.80.74 netmask 0xffffff00 > carp: BACKUP vhid 2 advbase 1 advskew 100 > carp3: flags=49 metric 0 mtu 1500 > inet 10.0.82.74 netmask 0xffffff00 > carp: BACKUP vhid 4 advbase 1 advskew 100 > > > Then from the 10.0.80 network I do a ssh to the 10.0.82 network. The > router for the 10.0.82 network is 10.0.82.74 and the router for the > 10.0.80 network is 10.0.80.74 (the VIPs): > > > ssh 10.0.82.5 > sebster@10.0.82.5's password: > > Read from remote host 10.0.82.5: Connection reset by peer > Connection to 10.0.82.5 closed. > > And then I get on the backup gateways pf log: > > machine 2: > # tcpdump -nttteli pflog0 not src or dst port 6155 and not src or dst > host 224.0.0.18 and not src or dst port 68 > tcpdump: WARNING: pflog0: no IPv4 address assigned > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size > 96 bytes > 000000 rule 11/0(match): block in on em1: 10.0.80.3.58876 > > 10.0.82.5.22: [|tcp] > 001161 rule 11/0(match): block in on em1: 10.0.80.3.58876 > > 10.0.82.5.22: [|tcp] > 000018 rule 11/0(match): block in on em1: 10.0.80.3.58876 > > 10.0.82.5.22: tcp 20 [bad hdr length 0 - too short, < 20] > > machine 3: > # tcpdump -nttteli pflog0 not src or dst port 6155 and not src or dst > host 224.0.0.18 and not src or dst port 68 > tcpdump: WARNING: pflog0: no IPv4 address assigned > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size > 96 bytes > 000000 rule 11/0(match): block in on em1: 10.0.80.3.58876 > > 10.0.82.5.22: [|tcp] > 001113 rule 11/0(match): block in on em1: 10.0.80.3.58876 > > 10.0.82.5.22: [|tcp] > 000019 rule 11/0(match): block in on em1: 10.0.80.3.58876 > > 10.0.82.5.22: tcp 20 [bad hdr length 0 - too short, < 20] > > I'm wondering why these backup hosts are blocking these packets, even > though the master is still up, and why they are causing the connection > to fail. (The pf on all 3 hosts do a "block return log on devif all" > where devif is the interface with the real 10.0.80.x ip; however, why is > it returning a RST packet when it's backup?). > > 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. -- Stanislav Sedov ST4096-RIPE !DSPAM:49ed85cd967001477745436! From owner-freebsd-cluster@FreeBSD.ORG Tue Apr 21 21:01:05 2009 Return-Path: Delivered-To: freebsd-cluster@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5C3A10656D1 for ; Tue, 21 Apr 2009 21:01:05 +0000 (UTC) (envelope-from sebster@sebster.com) Received: from mail.sebster.com (mail.sebster.com [193.46.80.82]) by mx1.freebsd.org (Postfix) with SMTP id 24F658FC12 for ; Tue, 21 Apr 2009 21:01:04 +0000 (UTC) (envelope-from sebster@sebster.com) Received: (qmail 46394 invoked from network); 21 Apr 2009 21:01:03 -0000 Received: from unknown (HELO ?10.0.1.6?) (sebster@85.147.225.232) by 10.0.98.3 with SMTP; 21 Apr 2009 21:01:03 -0000 Message-ID: <49EE340E.4090006@sebster.com> Date: Tue, 21 Apr 2009 23:01:02 +0200 From: Sebastiaan van Erk User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Stanislav Sedov References: <49EC68B6.9090303@sebster.com> <20090421123735.f7caf3cc.stas@FreeBSD.org> In-Reply-To: <20090421123735.f7caf3cc.stas@FreeBSD.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000605040908090005030406" Cc: freebsd-cluster@freebsd.org Subject: Re: pf and carp, BACKUP host dropping connection X-BeenThere: freebsd-cluster@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Clustering FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 21:01:06 -0000 This is a cryptographically signed message in MIME format. --------------ms000605040908090005030406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Stanislav Sedov wrote: > On Mon, 20 Apr 2009 14:21:10 +0200 > Sebastiaan van Erk 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 --------------ms000605040908090005030406 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUTCC AwMwggJsoAMCAQICEFN8DarMNuuKJDEtfs0UaqUwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDYzMDEzNTE1N1oX DTA5MDYzMDEzNTE1N1owaDEQMA4GA1UEBBMHdmFuIEVyazETMBEGA1UEKhMKU2ViYXN0aWFh bjEbMBkGA1UEAxMSU2ViYXN0aWFhbiB2YW4gRXJrMSIwIAYJKoZIhvcNAQkBFhNzZWJzdGVy QHNlYnN0ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsJDDAeYHVmH/ GVxi+bhFx27dmg++9BdhPJfk8k041sqEqq7oXnR2GT54quY3Ac7A1BuOM2JvoICraGmjud4y b3EanRnqGIK6iH+VAhhTlV/Owrb2Qm1e13DLxwLp1SocSQl4IrEbF9Y5H3ASdIrE0iFqkpju nPiiHeNhz3LaI5ipjiluKYoH+F6gPx8njHoaDxPePCkSLg4r0IA0afLM74LVZxCRBZEfyRZS J6VVUJefKlz91dWSzR/3xSw/rO4u9Ds/Zh7VBUKy3K+YFryHxRpUek0gSepE1b70Q39L9Sqd M/NZqMvFpwrqgW2Zh2Nh8nqRge90maR4ypBzz3GzLwIDAQABozAwLjAeBgNVHREEFzAVgRNz ZWJzdGVyQHNlYnN0ZXIuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAS1Sk NMgDVzb0ktO9tPPacV0KdKhTYOHcICVmuDEe2sFHOkjLAI1iAKp640pqJEVqvRnfRcCFJ9hK koPjjVZ+ui2rVmJWBG6FSloLRS/YYED4tUAw6DQhK61UOpjkpQxjCdm+5bHG/2ZgJAda1j0x uiN822+xFkcaW/5PQgxSRxcwggMDMIICbKADAgECAhBTfA2qzDbriiQxLX7NFGqlMA0GCSqG SIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QTAeFw0wODA2MzAxMzUxNTdaFw0wOTA2MzAxMzUxNTdaMGgxEDAOBgNVBAQTB3ZhbiBFcmsx EzARBgNVBCoTClNlYmFzdGlhYW4xGzAZBgNVBAMTElNlYmFzdGlhYW4gdmFuIEVyazEiMCAG CSqGSIb3DQEJARYTc2Vic3RlckBzZWJzdGVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALCQwwHmB1Zh/xlcYvm4Rcdu3ZoPvvQXYTyX5PJNONbKhKqu6F50dhk+eKrm NwHOwNQbjjNib6CAq2hpo7neMm9xGp0Z6hiCuoh/lQIYU5VfzsK29kJtXtdwy8cC6dUqHEkJ eCKxGxfWOR9wEnSKxNIhapKY7pz4oh3jYc9y2iOYqY4pbimKB/heoD8fJ4x6Gg8T3jwpEi4O K9CANGnyzO+C1WcQkQWRH8kWUielVVCXnypc/dXVks0f98UsP6zuLvQ7P2Ye1QVCstyvmBa8 h8UaVHpNIEnqRNW+9EN/S/UqnTPzWajLxacK6oFtmYdjYfJ6kYHvdJmkeMqQc89xsy8CAwEA AaMwMC4wHgYDVR0RBBcwFYETc2Vic3RlckBzZWJzdGVyLmNvbTAMBgNVHRMBAf8EAjAAMA0G CSqGSIb3DQEBBQUAA4GBAEtUpDTIA1c29JLTvbTz2nFdCnSoU2Dh3CAlZrgxHtrBRzpIywCN YgCqeuNKaiRFar0Z30XAhSfYSpKD441Wfrotq1ZiVgRuhUpaC0Uv2GBA+LVAMOg0ISutVDqY 5KUMYwnZvuWxxv9mYCQHWtY9MbojfNtvsRZHGlv+T0IMUkcXMIIDPzCCAqigAwIBAgIBDTAN BgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTES MBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UE CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTX p6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYB Af8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBl cnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYD VQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2as Zw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT HUb/XV9lTzGCA3EwggNtAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBJc3N1aW5nIENBAhBTfA2qzDbriiQxLX7NFGqlMAkGBSsOAwIaBQCgggHQMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDQyMTIxMDEwMlowIwYJKoZI hvcNAQkEMRYEFOlN6CkO/xrBXyjDU6XAmx/DZXXYMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEFN8DarMNuuKJDEtfs0UaqUwgYcGCyqG SIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECEFN8DarMNuuKJDEtfs0UaqUwDQYJKoZIhvcNAQEBBQAEggEAMwQ1YJmvi/UijTd0 hWhamMMQRXb1W9n0Vf/9+/MrEhK5JZ87IFpYLLL8gKXrKAaNp0hoeUIQBr3ud4rRixfdoLcE FRTH6KtC3m2RmJPY06mFkPegoNTSsbdBWfBT78ttCDPf8uyAN6HtOM3OdX2Y/pTf4+1c4m1q gh1pvHv4AqWRbRWYFulEo8d1ucxa6taDZ6Z6pZfmsLJwpt84cBVWjLO9ulqAlQpDAv73OFLG G1XUOBgtCguJ37BdDn7PUKuocPR1hMNMY1c42nKs8XUmbka9L80Crs+5Db1ubTTc6mPA4V2V UNEAGtytNktOZrm91MZChl93WugSMoGmUKSuzAAAAAAAAA== --------------ms000605040908090005030406--