Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    CARP and VRRP

    Scheduled Pinned Locked Moved HA/CARP/VIPs
    10 Posts 3 Posters 5.8k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • K
      kue
      last edited by

      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!

      1 Reply Last reply Reply Quote 0
      • S
        sullrich
        last edited by

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

        1 Reply Last reply Reply Quote 0
        • K
          kue
          last edited by

          Thanks, I will give that a shot!

          1 Reply Last reply Reply Quote 0
          • K
            kue
            last edited by

            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!

            1 Reply Last reply Reply Quote 0
            • S
              sullrich
              last edited by

              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?).

              1 Reply Last reply Reply Quote 0
              • dotdashD
                dotdash
                last edited by

                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…

                1 Reply Last reply Reply Quote 0
                • S
                  sullrich
                  last edited by

                  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.

                  1 Reply Last reply Reply Quote 0
                  • K
                    kue
                    last edited by

                    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!

                    1 Reply Last reply Reply Quote 0
                    • dotdashD
                      dotdash
                      last edited by

                      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.

                      1 Reply Last reply Reply Quote 0
                      • K
                        kue
                        last edited by

                        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.

                        1 Reply Last reply Reply Quote 0
                        • First post
                          Last post
                        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.