You must have one VHID per IP if you're running CARP. ifconfig alias IPs are not able to be used in a failover deployment.

@RedRocket:

Yes, my ISP is assigning vhids, i am not sure what the normal practice is here, I do know however that if there is any fuckup with vhids on our network interfering with theirs or other clients, they will simply pull the plug on us.

Doesn't surprise me, it's not a bad idea. They need to be willing to provide enough VHIDs though.

~~I'm ending up with the same problem on a 1.2 STABLE release.

I have:

both machines up-to-date usernames the same passwords the same firewall rules on the SYNC interfaces on * * * *

I also rebooted both machines, but this gives no clue.

HTTPS or HTTP set on both machines doesn't make any difference also.

What could be wrong here ?~~

I have solved this issue. It should have been a subnet that needed to be test on /24… this was also in the second trouble shooting part.

So, I've setup pfsense 1.2 using carp for automatic failover.  This is very nice stuff!  However, the ntpd server does not allow the ntpd server to be started on the LAN carp device.  don't forget, that if you edit your openNTP settings, these changes will be lost.  So…

Try this:

diagnostics->edit and load the following file:
/var/etc/ntpd.conf

and add the following line and save:
listen on 172.16.1.1  ( or whatever your LAN carp ip is )

diagnostics->command:
kill -KILL pgrep -u root ntpd && /usr/local/sbin/ntpd -f /var/etc/ntpd.conf

@juraj_bond:

In Firewall-Virtual IPs-Carp Settings-Synchronize Enabled.

Yea I figured it out… Ive now tried with device polling, disabling syncing the state table, changed the table size with no result.

Still when Im ghosting with multicast I get the same high ping issues and interrupts...

Here is the other thread: http://forum.pfsense.org/index.php/topic,7039.0.html
My static route was-  WAN (secondary subnet/mask) gateway (the WAN CARP address)

Please us the search:
http://forum.pfsense.org/index.php?action=search
keyword: "NAT reflection"

http://forum.pfsense.org/index.php/topic,7001.0.html

The load balancer is for failing between WAN interfaces. I'm assuming you just need to failover from the master to the slave in your CARP setup. Please check out the tutorial here: http://www.pfsense.org/mirror.php?section=tutorials/carp/carp-cluster-new.htm
but basically, you want to have the internal machines use 10.x.x.9 as the gateway and use x.x.x.9 as the outbound translate in AON.

Have you looked at this?
http://www.pfsense.org/mirror.php?section=tutorials/carp/carp-cluster-new.htm

You'll notice that on the secondary node, you only check 'sync enabled' and select the interface.
(Ignore the preemption setting, it's on by default now)

CARP and VRRP live happily together provided you are using unique VHIDs.
As mentioned in another thread, the messages are cosmetic.
If they really bother you, you might try filtering the broadcasts, perhaps with a filter on your switch. Setting the sysctl net.inet.carp.log to 0 might get rid of them also. I'm content to ignore the messages and haven't tried either of these suggestions, so proceed at your own risk.

ok i have found my problem, it is my fault i have not read well the tutorial.
i have created the virtual ip manually on both the master and the slave and i think it was the problem, i must create the vip only on the master and they will be sync automatically on the slave.

I have finally solved the problem. I post here the solution because it is a common error that can happen (I am asking pfsense programmers to modify pfsense behaviour):

in wan (and only in wan, not wan2) there is a setting to "block private networks". It is suggested to check it, but nobody warns that blocking private networks block also vrrp advertisement!!!!!!!!!!!

Now I will investigate on the openvpn not working on udp problem.

Ok, found it. One of the switches didnt forward multicast… Working perfect now.

Perfect. Now I know what 'other VIP' is. It worked for you because your provider did not care about L2 address and just forwarded these addresses to you.
Unfortunately I can not use it.
Anyway it is very interesting… Suppose you are server and you have IP packet arriving at your interface... how L2 decides that this packet is intended to you and deliver it to L3 in ethernet environment? I suppose L2 has to deliver every packet and L3 will decide whether this packet yours or not. Obvious overhead but good opportunities to handle this traffic. Very interesting... I would like to read more how FreeBSD handles this.

Thanks again.

I dont think this is possible.

But the node with the lowest advertising frequency will be master.
So you could per default have the master on lets say 4 and the slave on 5.
<– 4 is master, 5 is slave

If the master goes down the slave takes over.
<-- 5 is master

Now before you connect up the new box you set it to 6.
So you have to set it manually to 4 to take over.
<-- 5 is master, 6 is backup
manually change to
<-- 4 is master, 5 is backup

After more research, I found the issue I am experiencing is a known vmware bug.

http://communities.vmware.com/thread/72678

It will show up correctly in the next version now but it's a cosmetic issue with current versions. The sync will work.

http://cvstrac.pfsense.org/chngview?cn=22514

@brianw:

Sorry I have not replied; been a bit busy. We got the hardware and built a lab. We accomplished all of our goals in the end. The setup is at the clients new building awaiting the servers and clients that will be coming in the coming weeks. We experienced a bit of a heartache in the hardware department at first. We thought we were going to have to go back to the drawing board in the hardware department at first.

We got (2) of the Jetway C7 2.0 boards with the daughter board capability. We got the (3) GB Nic daughter boards for them. The daughter boards did not work well at all. They kept dropping IRQ's and such. Generally just not working out. So we got (2) Dual GB Intel nics for each router. And still the problems with IRQ routing persisted. We finally found some documentation on the PCI riser card and was able to get the Dual GB Intel Nic's to work. We were very happy. :)

My Brother and I will soon be publishing a HowTo for the setup we found. None of the HowTo's worked 100% for us… We had to figure some things out. I also want to post our setup so it can be scrutinized.

Check back,

brianw

I would welcome your howto!

Ok, I think it is safer to buy a fourth card!! Thank for advices!!  ;)