On 2/10/2011 10:42 AM, Vaughn L. Reid III wrote:
On 2/10/2011 9:32 AM, Vaughn L. Reid III wrote:
On 2/10/2011 2:43 AM, Seth Mos wrote:
Op 10-2-2011 4:18, Vaughn L. Reid III schreef:
1. All the Master and backup status notifications in the web interface
on both PFSense boxes show the correct status
2. I'll do a packet capture tomorrow and see if the carp-heartbeat
shows up
I was unaware that any Carp related traffic passed between any of the
interfaces except the one designated as the synchronization
interface. I
need to double-check the multi-cast configuration on the switch
tomorrow
also ( I think I have multi-cast enabled on the switch, but need to
confirm that).
Yes, some switch support multicast filtering, I know from experience
with HP switches that it works with the setting on. So I know they
have it implemented correctly. This way not all switch ports get the
carp traffic unless they participate in the multicast group. This
cuts down on broadcast a lot.
I recommend the HP switches, they have never given me any grief as
long as I've worked with them. I even have a carp cluster spanning 2
building across the street over a fiber connection. It just works.
If you need a managed switch on a budget I can confirm that the HP
Procurve 1810-8G works well. It's web managed, supports vlans and
basic traffic counters. It is also fanless.
The smallest I have in use on a carp cluster is a Procurcve 2650 in
combination with a 2900-48G. The biggest I have is a 8212zl. Do note
that the software in the 1810 differs a lot from the other managed
switches.
Regards,
Seth
---------------------------------------------------------------------
To unsubscribe, e-mail: support-unsubscr...@pfsense.com
For additional commands, e-mail: support-h...@pfsense.com
Commercial support available - https://portal.pfsense.org
I've run a packet capture and here are the results:
1. Capture shows a bunch of VRRP announcements from the primary
firewall to destination 224.0.0.18. The destination confirms this is
a multicast address I believe. According to Wikipedia, VRRP and
CARP share the same protocol number. So, I believe that these are
CARP announcements.
2. All the VRRP requests had a vrrp.prio value of 0 with a
description of "Priority: 0 (Current Master has stopped participating
in VRRP)
3. Over a 114 second capture, there were no VRRP announcements from
the secondary firewall.
4. There were lots of ARP broadcast requests from the secondary
firewall asking for who has the IP of the default gateway. There
were 0 ARP requests from the primary firewall during the capture period.
5. There were lots of ICMP pings from both the primary and secondary
Pfsense firewalls to the default gateway on this WAN interface. I
assume this is from the Load Balance Fail-Over configuration I have
enabled for the cluster on this interface.
I confirmed that the Master firewall shows itself as Master for all
interfaces. I confirmed that the Secondary firewall shows itself as
Backup for all interfaces.
---------------------------------------------------------------------
To unsubscribe, e-mail: support-unsubscr...@pfsense.com
For additional commands, e-mail: support-h...@pfsense.com
Commercial support available - https://portal.pfsense.org
I performed a second capture of 3 minutes on malfunctioning WAN and
noted identical results for the VRRP/CARP packets. On the second
capture, however, I did see ARP requests from both firewalls asking
for the MAC of the IP of the Default Gateway -- this was different
from my item number 4 in the previous post.
I also performed a 3 minute packet capture from one of the known
working WAN connections on the cluster. The VRRP packets on that
connection showed an origination address of the "Real" IP on
primary/Master firewall and a multi-cast destination, just like the
results from the problem WAN connection. I also noted that the
vrrp.prio value and description was the same on the working WAN as on
the not-working WAN.
Both the working WAN connection packet capture and the non-Working WAN
packet captures show IGMP packets noting the entering and leaving of
multi-cast groups.
---------------------------------------------------------------------
To unsubscribe, e-mail: support-unsubscr...@pfsense.com
For additional commands, e-mail: support-h...@pfsense.com
Commercial support available - https://portal.pfsense.org
One more thing. If I unplug the connection that leads to the ISP's
black box from the switch and leave everything else in place, pings
from the secondary/backup firewall to the CARP start working as expected.
I'm not sure I understand this behavior. With 2 IP addresses on the
same subnet that can communicate with each other on the same VLAN of a
switch, it seems to me that it shouldn't matter what else I plug into
that switch (as long as it has a different IP and as long as it is not
doing some sort of ARP cache spoofing) that pings should still work.
I've asked the ISP twice to confirm that the IP's in question aren't
being used elsewhere, and I've been assured both times that they are
free for our use.
---------------------------------------------------------------------
To unsubscribe, e-mail: support-unsubscr...@pfsense.com
For additional commands, e-mail: support-h...@pfsense.com
Commercial support available - https://portal.pfsense.org