Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 14 Jun 2011 19:00:37 +0200
From:      Damien Fleuriot <ml@my.gd>
To:        "freebsd-stable@freebsd.org" <freebsd-stable@freebsd.org>
Subject:   Re: Networking - CARP interfaces
Message-ID:  <4DF793B5.903@my.gd>
In-Reply-To: <4DF72488.6050806@my.gd>
References:  <4DF72488.6050806@my.gd>

next in thread | previous in thread | raw e-mail | index | archive | help
On 6/14/11 11:06 AM, Damien Fleuriot wrote:
> Hello list,
> 
> 
> 
> Here I am today, setting up CARP interfaces on our backup firewalls, and
> I'm wondering something...
> 
> 
> Let's take the following scenario:
> 
> 
> Datacenter PRIM, firewall PRIM:
> - carp13 has public IPs X and Y and is master (advskew 100)
> 
> Datacenter PRIM, firewall BACK:
> - carp13 has public IPs X and Y and is backup (advskew 150)
> 
> 
> Datacenter BACK, firewall PRIM:
> - carp13 has public IPs X, Y, W and Z (advskew 230, down)
> 
> Datacenter BACK, firewall BACK:
> - carp13 has public IPs X, Y, W and Z (advskew 250, down)
> 
> 
> 
> If I bring up my carp13 interfaces on the backup datacenter, will they
> become master because the carp interfaces on the primary datacenter is
> lacking 2 public IPs ?
> 
> That would be a problem...
> 
> Has anyone faced this situation before ?
> 
> Also, adding IPs W and Z on my primary datacenter is not an option at
> the moment.



Replying to myself,



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



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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DF793B5.903>