Date: Tue, 14 Jun 2011 22:51:18 +0200 From: Damien Fleuriot <ml@my.gd> To: Steve Polyack <korvus@comcast.net> Cc: "freebsd-stable@freebsd.org" <freebsd-stable@freebsd.org> Subject: Re: Networking - CARP interfaces Message-ID: <99A75196-BE3C-466C-9B0B-CF874C1287B5@my.gd> In-Reply-To: <4DF79B72.2090805@comcast.net> References: <4DF72488.6050806@my.gd> <4DF793B5.903@my.gd> <4DF79B72.2090805@comcast.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 14 Jun 2011, at 19:33, Steve Polyack <korvus@comcast.net> wrote: > On 06/14/2011 01:00 PM, Damien Fleuriot wrote: >>=20 >> I can confirm that this scenario causes problems, see below: >>=20 >> ### ON FIREWALL 1 , carp master for carp0, carp1, carp2 >> carp2: flags=3D49<UP,LOOPBACK,RUNNING> metric 0 mtu 1500 >> inet 192.168.224.254 netmask 0xffffff00 >> carp: MASTER vhid 224 advbase 1 advskew 50 >>=20 >>=20 >> ### ON FIREWALL 2 , carp backup for carp0, carp1, carp2 >> carp2: flags=3D49<UP,LOOPBACK,RUNNING> metric 0 mtu 1500 >> inet 192.168.234.254 netmask 0xffffff00 >> carp: BACKUP vhid 234 advbase 1 advskew 100 >>=20 >>=20 >> Now, I add a dummy IP to carp2 on FIREWALL 2, which is supposedly backup:= >>=20 >> ifconfig carp2 inet 192.168.234.207 alias >>=20 >> Result: >>=20 >> ### ON FIREWALL 1, carp master for carp0, carp1, carp2 >> carp2: flags=3D49<UP,LOOPBACK,RUNNING> metric 0 mtu 1500 >> inet 192.168.224.254 netmask 0xffffff00 >> carp: MASTER vhid 224 advbase 1 advskew 50 >>=20 >> ### ON FIREWALL 2, carp backup for carp0, carp1, but no longer carp2 >> carp2: flags=3D49<UP,LOOPBACK,RUNNING> metric 0 mtu 1500 >> inet 192.168.234.254 netmask 0xffffff00 >> inet 192.168.234.207 netmask 0xffffff00 >> carp: MASTER vhid 234 advbase 1 advskew 100 >> =20 >> =20 >> After I remove the extraneous IP, the interface becomes backup again: >>=20 >>=20 >> # This was a long time ago >> carp0: MASTER -> BACKUP (more frequent advertisement received) >> carp0: link state changed to DOWN >> carp2: MASTER -> BACKUP (more frequent advertisement received) >> carp2: link state changed to DOWN >> carp1: MASTER -> BACKUP (more frequent advertisement received) >> carp1: link state changed to DOWN >> carp2: link state changed to DOWN >> # This was when I ran my tests >> carp2: INIT -> MASTER (preempting) >> carp2: link state changed to UP >> carp2: MASTER -> BACKUP (more frequent advertisement received) >> carp2: link state changed to DOWN >=20 > Did you give this enough time to reasonably settle? Sometimes when the in= terfaces initially come up, they will become MASTER for a bit before backing= down. >=20 I think I did but I can do try again tomorrow evening just to make sure. Oh god, if only dmesg entries were timestamped... >> This entails that hosts in a given carp vhid must have the exact same IP >> addresses configured on that interface. >>=20 >> While this is perfectly understandable in a master-backup scenario, this >> is a bit more annoying for us in a master-backup + backup-backup >> scenario with 2 datacenters. >>=20 >> I'll just have to adapt and ensure they have the same IP addresses then. >=20 > I have a suspicion that the important part may be the number of IP address= es on the CARP interface. If CARP sends an advertisement from each IP alias= on a CARP interface, then I think that would explain what you are seeing - a= nd also possibly give you a workaround by adding two more bogus IPs on your p= rimary datacenter firewalls (where IPs W and Z are normally missing). >=20 > - Steve >=20 I'll give it a try, although I think in a scenario where the carp interfaces= have the same number of IPs and these IPs differ, both interfaces will clai= m mastership. Will post results.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?99A75196-BE3C-466C-9B0B-CF874C1287B5>