CARP and VRRP

[kue]

Can someone help point me in the correct direction?  My system logs keep filling up with the following…

kernel: carp_input: received len 20 < sizeof(struct carp_header)

I searched the forums and with google looking for a solution.

So far I have checked for
  unique VHIDs
  correct Virtual IP settings between our 2 PFSense boxes (we use CARP to sync everything to the slave)
  un-checked the RFC1918 and Bogon network options from the WAN configuration
  the CARP Sync interface allows all traffic and is connected with a xover cable
  using tcpdump, I see that our ISP uses vrid 0 for the redundant internet gateway (I am waiting on a reply email from our provider)
  I also see our CARP advertisements which all seem good.

Now, from what I have read, VRRP, CARP, and HSRP can exist peacefully as long as nothing shares an ID.

Any suggestions on what I can check next?

THANKS!

[sullrich]

This was a debugging line.  upgrade to a recent snapshot.  Search the forum if you do not know what a snapshot is.

[kue]

Thanks, I will give that a shot!

[kue]

I just upgraded to the snapshot from today (12/10/07) and the message is still in the system log.  Anything else I can check?

Thanks!

[sullrich]

Actually on second glance that is not the debug string I spoke of.  This appears more like carp complaining that the length of the multicast packet does not match what it should (switch issue?).

[dotdash]

FWIW, I'm getting the same error in the logs on a cluster that has a VRRP cluster upstream. The provider looks to be running Juniper gear. They are using a unique vrid. It appears to be cosmetic- I was assuming that CARP was complaining because it was seeing the VRRP multicasts, but they were failing the checks for CARP to accept them (as they are VRRP, not CARP). I thought this might be normal, but I don't have any other CARP setups with VRRP upstream…

[sullrich]

Yes, if someone is running VRRP upstream you need to ensure the VHIDS are not the same as the upstream providers.  You might be interfering with their setup otherwise.

[kue]

Well I verified that my ISP is VRRP ID 0.  I doubled check the IDs I use again just to make sure.

I also checked our switches, a pair of HP Procurve 2510.  IGMP is disabled, so multicast packets are being delivered to each port on the vlan.

I did run tcpdump on both PFSense boxes.  I can see the CARP advertisements being sent out and received and appear to be correct length.  So perhaps this is just a cosmetic error because of the upstream VRRP advertisements?

If it would help I can post the results of my tcpdumps.  Perhaps another set of eyes can catch something I am missing.

Thanks!

[dotdash]

I ran a tcpdump on the wan if with the destination 224.0.0.18 to see the VRRP and CARP multicasts on the segment. You should be able to see what vhid the provider is using, and the length of their packets. In my case, the providers VRRP packets appear to indeed have a length of 20.

[kue]

That is what I see as well.  VRRP frames from upstream with a length of 20.  So is there a way to keep this from filling the system log.  I created a firewall rule that filters out CARP (the same protocol number as VRRP) from the upstream IPs, but it does not seem to have any effect.