On Dec 16, 2009, at 5:41 PM, Chris Buechler wrote:

> On Wed, Dec 16, 2009 at 7:14 PM, Trevor Benson <[email protected]> 
> wrote:
>> I noticed that when creating a CARP virtual that it requires it to be 
>> attached to an interface with the same network.  However when creating a
>> proxy arp, it does not have this requirement.  Wouldn't it be logical to 
>> allow them to have the same validation check?
> 
> CARP cannot have VIPs off-subnet, proxy ARP can and in some
> circumstances is necessary.

I just jumped onto one of our OpenBSD 4.2 systems that has not been replaced by 
pfSense, and configured "off-subnet" CARP addresses without any issue.  To keep 
from failing over the pair i added it to both interfaces, found master on A 
with a slight skew on B, destroyed the CARP interface on A (as not to preempt 
all interfaces onto B), and then B becomes master without a hitch. Is this a 
limitation of Carp on FreeBSD as we have been using these configurations with 
OpenBSD since v4.2 (well over a year if not approaching 2).  


> 
>> I have quite a few networks using fibre metro ethernet, and Embarq (formerly 
>> sprint) loves to provide transport networks, and public networks.
>> Basically giving you 1.2.3.0/29 for transport (.1 is gateway, .2-.6 usable 
>> for firewalls etc.), then assigns you 6.5.4.0/27 for WAN/Public access
> 
> They should be routing the /27 to a CARP IP on your /29. Then you use
> Other type VIPs for the /27.

This works until failure occurs, and then you have the failover unit missing 
the configuration for the /27 allocation and have to manually configure the 
VIPs on the failover system.  Seems like nothing big until you have 10Mbps of 
VoIP traffic using those proxy ARP VIPs and then all inbound outbound traffic 
fails until you replace the proxy ARP, also having to ensure they are removed 
from the down system before it comes back up and fights over the IPs.


> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> 
> Commercial support available - https://portal.pfsense.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Commercial support available - https://portal.pfsense.org

Reply via email to