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>
index | next in thread | previous in thread | raw e-mail
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.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?99A75196-BE3C-466C-9B0B-CF874C1287B5>