CARP problem - both nodes on backup state
-
Hi,
I've tried to setup CARP for the first time using this tutorial: http://www.howtoforge.com/how-to-configure-a-pfsense-2.0-cluster-using-carp
but both VIPs stay on backup state on both nodes :(
PFSENSE1:
wan_vip1: flags=49 <up,loopback,running>metric 0 mtu 1500
inet 192.168.70.253 netmask 0xffffff00
carp: BACKUP vhid 1 advbase 1 advskew 0
lan_vip2: flags=49 <up,loopback,running>metric 0 mtu 1500
inet 192.168.2.253 netmask 0xffffff00
carp: BACKUP vhid 2 advbase 1 advskew 0PFSENSE2:
wan_vip1: flags=49 <up,loopback,running>metric 0 mtu 1500
inet 192.168.70.253 netmask 0xffffff00
carp: BACKUP vhid 1 advbase 1 advskew 100
lan_vip2: flags=49 <up,loopback,running>metric 0 mtu 1500
inet 192.168.2.253 netmask 0xffffff00
carp: BACKUP vhid 2 advbase 1 advskew 100Logs of both nodes in attachment.
Anyone seen this problem before?
pfsense1_log.txt
pfsense2_log.txt</up,loopback,running></up,loopback,running></up,loopback,running></up,loopback,running> -
A couple possibilities:
1. Some kind of network loop/L2 issue causing them to see the advertisements from their neighbors far more often than they should.
2. Something else on that segment is already doing CARP/VRRP/HSRP with the same VHID.First, try using different VHIDs (something random and/or high) and see if that is enough to clear it up.
Otherwise, look at your switch, and make sure you don't have any bridging or layer 2 loops happening.
-
A couple possibilities:
1. Some kind of network loop/L2 issue causing them to see the advertisements from their neighbors far more often than they should.
2. Something else on that segment is already doing CARP/VRRP/HSRP with the same VHID.First, try using different VHIDs (something random and/or high) and see if that is enough to clear it up.
Otherwise, look at your switch, and make sure you don't have any bridging or layer 2 loops happening.
On the same VLAN i have a redhat cluster suite running, but i changed to a new VLAN, only my two pfsenses have access to it, but it didn't fixed the problem.
Now i disabled promiscous mode on my vmware vswitches and it seems it fixes the problem, but without promiscous mode i can't ping the VIPs from any other machine :(
-
oh, well if you're on vmware/esx, there are a lot more things to worry about.
http://doc.pfsense.org/index.php/CARP_Configuration_Troubleshooting#VMware_ESX.2FESXi_Users
-
oh, well if you're on vmware/esx, there are a lot more things to worry about.
http://doc.pfsense.org/index.php/CARP_Configuration_Troubleshooting#VMware_ESX.2FESXi_Users
Thankx, the solution was activating the Net.ReversePathFwdCheckPromisc option on ESXi.
Just another question:
On my vswitch i have this port groups:
VM Network LAN
VM Network MGMT
VM Network WIFI
VM Network SYNC
VM Network DMZDo i need to have promiscous mode activated for all portgroups that have VIPs or just for the SYNC portgroup (network used for CARP)?
I have VIPs for LAN, MGMT, WIFI, DMZ. -
You need it active on every port group containing the pfSense VMs, not the SYNC port group, but every other one.
Now that doesn't mean you need to do it for the entire vswitch, you can make a port group on the vswitch for just the pfSense nodes and only enable those options there, leaving the rest of the switch at its defaults.
-
You need it active on every port group containing the pfSense VMs, not the SYNC port group, but every other one.
Now that doesn't mean you need to do it for the entire vswitch, you can make a port group on the vswitch for just the pfSense nodes and only enable those options there, leaving the rest of the switch at its defaults.
Isn't there anyway to make it work without promiscuous mode activated?
With promiscuous mode activated all VMs can see the traffic of each other :(
-
No, but that's not pfSense's fault, it's VMware.
You can make a port group just for the ports of the firewall, and make that promiscuous, and then have another different port group for the clients that is not promiscuous.
-
No, but that's not pfSense's fault, it's VMware.
You can make a port group just for the ports of the firewall, and make that promiscuous, and then have another different port group for the clients that is not promiscuous.
Thankx, works great.