On 06/14/2011 04:51 PM, Damien Fleuriot wrote:
On 14 Jun 2011, at 19:33, Steve Polyack<[email protected]> 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.
Now that I look at the spec, it looks like both the count and the
addresses themselves are provided in VRRP packets. CARP likely does the
same. I can't speak for whether these things are considered along with
the VHID and password, but it's worth a shot. I think you are correct,
though.
http://www.networksorcery.com/enp/protocol/vrrp.htm
- Steve
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[email protected]"
