-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ian FREISLICH wrote: > Xin LI wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Ian FREISLICH wrote: >> [...] >>> I have noticed that if there are multiple IP addresses on the carp >>> interface and these are configured in a different order on each >>> host, the you can expect messages like the following: >>> >>> Jun 9 23:56:29 firewall2 kernel: carp15: incorrect hash >>> Jun 9 23:56:30 firewall2 kernel: carp15: incorrect hash >>> Jun 9 23:56:31 firewall2 kernel: carp15: incorrect hash >>> Jun 9 23:56:32 firewall2 kernel: carp15: incorrect hash >>> >>> And both hosts will claim MASTER status. >> This reminded me... I've set net.inet.carp.log=2 now but except some >> bad CARP packets on the outside (12.xxx.xxx.112/28) network due to VRRP >> router, I didn't saw any complain about incorrect hash. Are you using >> "pass" parameter when setting up CARP? > > Yes, I use pass. There are many untrusted hosts on my network. > > Taking another look at the manual page, I think that the behaviour > you're seeing is expected. Try setting advbase to the same on all > vhids on both hosts. Use advskew to set a preference for one of > your servers. Use advbase to determine how quickly a failure will > be detected. > > To use carp, the administrator needs to configure at minimum > a common virtual host ID (VHID) and virtual host IP address > on each machine which is to take part in the virtual group. > Additional parameters can also be set on a per-interface basis: > advbase and advskew, which are used to control how frequently > the host sends advertisements when it is the master for a > virtual host, and pass which is used to authenticate carp > advertisements. Um... In order to narrow this down I have removed advbase setting from both servers (now they use the default number, 1) but seems no luck. I have further checked netstat -s, it seems that only the CARP packets with bad length (which are really VRRP packets) are being counted into the "received" packets, and were all discarded (of course). I've manually put these interfaces down and will check back to see if there is some clue in our code in the afternoon. Jul 16 12:22:58 gate2 kernel: carp0: INIT -> BACKUP Jul 16 12:22:58 gate2 kernel: carp1: INIT -> BACKUP Jul 16 12:22:58 gate2 kernel: carp0: link state changed to DOWN Jul 16 12:22:58 gate2 kernel: carp1: link state changed to DOWN Jul 16 12:22:58 gate2 kernel: carp2: INIT -> BACKUP Jul 16 12:22:58 gate2 kernel: carp3: INIT -> BACKUP Jul 16 12:22:58 gate2 kernel: carp2: 2 link states coalesced Jul 16 12:22:58 gate2 kernel: carp2: link state changed to DOWN Jul 16 12:22:58 gate2 kernel: carp3: 2 link states coalesced Jul 16 12:22:58 gate2 kernel: carp3: link state changed to DOWN Jul 16 12:22:58 gate2 kernel: carp2: link state changed to DOWN Jul 16 12:22:58 gate2 kernel: carp3: link state changed to DOWN Jul 16 12:22:58 gate2 kernel: carp_input: received len 20 < sizeof(struct carp_header) on em0 Jul 16 12:23:01 gate2 kernel: carp1: link state changed to UP Jul 16 12:23:01 gate2 kernel: carp0: link state changed to UP Jul 16 12:23:01 gate2 kernel: carp2: INIT -> BACKUP Jul 16 12:23:01 gate2 kernel: carp3: INIT -> BACKUP Jul 16 12:23:01 gate2 kernel: carp2: link state changed to DOWN Jul 16 12:23:01 gate2 kernel: carp3: link state changed to DOWN Jul 16 12:23:01 gate2 kernel: carp_input: received len 20 < sizeof(struct carp_header) on em0 Jul 16 12:23:04 gate2 kernel: carp3: link state changed to UP Jul 16 12:23:04 gate2 kernel: carp2: link state changed to UP Jul 16 12:23:05 gate2 kernel: carp_input: received len 20 < sizeof(struct carp_header) on em0 Jul 16 12:23:09 gate2 kernel: carp_input: received len 20 < sizeof(struct carp_header) on em0 ===== Jul 16 12:22:55 gate1 kernel: carp2: INIT -> BACKUP Jul 16 12:22:55 gate1 kernel: carp3: INIT -> BACKUP Jul 16 12:22:55 gate1 kernel: carp2: link state changed to DOWN Jul 16 12:22:55 gate1 kernel: carp3: link state changed to DOWN Jul 16 12:22:56 gate1 kernel: carp_input: received len 20 < sizeof(struct carp_header) on em0 Jul 16 12:22:58 gate1 kernel: carp2: link state changed to UP Jul 16 12:22:58 gate1 kernel: carp3: link state changed to UP Jul 16 12:22:59 gate1 kernel: carp_input: received len 20 < sizeof(struct carp_header) on em0 Jul 16 12:23:01 gate1 kernel: carp_input: received len 20 < sizeof(struct carp_header) on em0 Jul 16 12:23:20 gate1 kernel: carp_input: received len 20 < sizeof(struct carp_header) on em0 Jul 16 12:23:21 gate1 kernel: carp_input: received len 20 < sizeof(struct carp_header) on em0 Jul 16 12:23:24 gate1 kernel: carp_input: received len 20 < sizeof(struct carp_header) on em0 Jul 16 12:23:25 gate1 kernel: carp_input: received len 20 < sizeof(struct carp_header) on em0 Jul 16 12:23:41 gate1 kernel: carp_input: received len 20 < sizeof(struct carp_header) on em0 Jul 16 12:24:01 gate1 kernel: carp_input: received len 20 < sizeof(struct carp_header) on em0 Jul 16 12:24:21 gate1 kernel: carp_input: received len 20 < sizeof(struct carp_header) on em0 Jul 16 12:24:32 gate1 kernel: carp_input: received len 20 < sizeof(struct carp_header) on em0 - -- Xin LI <delphij_at_delphij.net> http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkpfgA8ACgkQi+vbBBjt66AFhgCgsQ+4NyMliW4EpnqU/nmIlLTu R5kAn0EGS+SFNB6XoijjGI8omTub8YLi =IdlA -----END PGP SIGNATURE-----Received on Thu Jul 16 2009 - 17:33:06 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:52 UTC