On 11-02-10 11:07 AM, Vaughn L. Reid III wrote:
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.
You can easily check. Plug the cable from your ISP into your laptop, ping all your IPs in question and look at arp
table, if you see anything then these IPs are in use.
Your set up seems to be correct so it is either ISP or switch.
Evgeny
---------------------------------------------------------------------
To unsubscribe, e-mail: support-unsubscr...@pfsense.com
For additional commands, e-mail: support-h...@pfsense.com
Commercial support available - https://portal.pfsense.org
