On 2/10/2011 12:57 PM, Evgeny Yurchenko wrote:
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
I want to thank everyone for their help. After getting into contact
with the ISP's senior network engineer, it appears that the issue I'm
experiencing is related to the ISP's network topology and passive
optical fiber infrastructure.
Thanks for everyone's assistance and advice. I learned some new things
about how CARP works in the process.
---------------------------------------------------------------------
To unsubscribe, e-mail: support-unsubscr...@pfsense.com
For additional commands, e-mail: support-h...@pfsense.com
Commercial support available - https://portal.pfsense.org