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: >> >> I can confirm that this scenario causes problems, see below: >> >> ### ON FIREWALL 1 , carp master for carp0, carp1, carp2 >> carp2: flags=49<UP,LOOPBACK,RUNNING> metric 0 mtu 1500 >> inet 192.168.224.254 netmask 0xffffff00 >> carp: MASTER vhid 224 advbase 1 advskew 50 >> >> >> ### ON FIREWALL 2 , carp backup for carp0, carp1, carp2 >> carp2: flags=49<UP,LOOPBACK,RUNNING> metric 0 mtu 1500 >> inet 192.168.234.254 netmask 0xffffff00 >> carp: BACKUP vhid 234 advbase 1 advskew 100 >> >> >> Now, I add a dummy IP to carp2 on FIREWALL 2, which is supposedly backup: >> >> ifconfig carp2 inet 192.168.234.207 alias >> >> Result: >> >> ### ON FIREWALL 1, carp master for carp0, carp1, carp2 >> carp2: flags=49<UP,LOOPBACK,RUNNING> metric 0 mtu 1500 >> inet 192.168.224.254 netmask 0xffffff00 >> carp: MASTER vhid 224 advbase 1 advskew 50 >> >> ### ON FIREWALL 2, carp backup for carp0, carp1, but no longer carp2 >> carp2: flags=49<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 >> >> >> After I remove the extraneous IP, the interface becomes backup again: >> >> >> # 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 > > Did you give this enough time to reasonably settle? Sometimes when the interfaces initially come up, they will become MASTER for a bit before backing down. > 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. >> >> 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. >> >> I'll just have to adapt and ensure they have the same IP addresses then. > > I have a suspicion that the important part may be the number of IP addresses 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 - and also possibly give you a workaround by adding two more bogus IPs on your primary datacenter firewalls (where IPs W and Z are normally missing). > > - Steve > 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 claim 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>