Navigation

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

    Lots of vrrp (carp?) packets outbound from WAN

    HA/CARP/VIPs
    4
    11
    7301
    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.
    • J
      jpgator last edited by

      Our isp told me they're seeing a ton of broadcast traffic coming from the pfsense box.  When observing it in wireshark (pic attached) it's tagged as vrrp, but from digging around in old posts I'm guessing it's actually carp?

      We have two firewall boxes which have been running without problems for several years (been on pfsense 1.2.2 for a while).  We have a lot of virtual ips setup as carp (with vhids from 1 through 46).  These virtual ip's are replicated to the backup firewall (along with rules, etc).  All failover and replication has been working without problems.

      Even though the broadcasts don't seem to be doing any damage, I'd really like to know if there's anything I can do to reduce the volume of them outbound on the WAN?

      If you need any more details let me know.

      1 Reply Last reply Reply Quote 0
      • jimp
        jimp Rebel Alliance Developer Netgate last edited by

        No, that is normal traffic and required for CARP to function. Your ISP may be able to block the traffic on their side or at the CPE, but you need that traffic on the WAN (or WAN switch, rather) or CARP can't properly keep track of which hosts are alive and which should be master/backup.

        Even if you could reduce the overall frequency, it would take longer for a failure to be noticed, and thus longer for the failover to the backup unit to happen.

        1 Reply Last reply Reply Quote 0
        • J
          jpgator last edited by

          Ok, thanks.  That's what I figured.

          Out of curiosity, when I look at the wireshark logs the source is usually something like 'IETF-VRRP-virtual-router-VRID_14'.  I assume for this one the vhid was 14?  I ask because I see lots of others where the id appears to be hex (1b, 1d, 0c, etc) and wasn't sure about them?

          Thanks

          1 Reply Last reply Reply Quote 0
          • jimp
            jimp Rebel Alliance Developer Netgate last edited by

            That may be the MAC address, which is algorithmically determined based off the VHID. If that is hex (which is likely) then that isn't 14, it's VHID 20 in decimal.

            1 Reply Last reply Reply Quote 0
            • J
              jpgator last edited by

              Quite possible.  I thought I'd seen some base 10 id's in wireshark as high as 45, but after glancing at it the highest non-hex is 29 which would make sense.

              Thanks for the help.

              1 Reply Last reply Reply Quote 0
              • R
                Ree last edited by

                @jimp:

                No, that is normal traffic and required for CARP to function. Your ISP may be able to block the traffic on their side or at the CPE, but you need that traffic on the WAN (or WAN switch, rather) or CARP can't properly keep track of which hosts are alive and which should be master/backup.

                Is it possible to have CARP keep track of which hosts are alive and which should be master/backup via the LAN connection?

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

                  @Ree:

                  Is it possible to have CARP keep track of which hosts are alive and which should be master/backup via the LAN connection?

                  It's possible if you only want to run a CARP interface on your LAN. If you want the WAN to failover the WAN interfaces must exchange traffic.

                  1 Reply Last reply Reply Quote 0
                  • jimp
                    jimp Rebel Alliance Developer Netgate last edited by

                    @Ree:

                    Is it possible to have CARP keep track of which hosts are alive and which should be master/backup via the LAN connection?

                    As dotdash said, that won't work.

                    CARP puts a heartbeat on the wire where the interface containing the CARP IP is. The heartbeat is how it determines what is down. Each CARP member listens for heartbeats from other CARP hosts as well as sends its own heartbeat. If a CARP host sees no other heartbeats, it knows that something happened to the other box. Meanwhile, the other box might not even realize it has a problem.

                    It's part of the fundamental architecture of CARP.

                    1 Reply Last reply Reply Quote 0
                    • R
                      Ree last edited by

                      Thanks, that makes perfect sense.

                      And I think I already know the answer to this next question, but just to be absolutely sure, is it that it's not a good idea to have the heartbeat sent out over just the LAN (or the OPT1 cross-over), or is it that it's just not possible?

                      The reason I ask is because in our case we only really care about some sort of hardware failure taking down the master (in our setup if the WAN is down on our master, it's almost guaranteed to be down on our backup), so in theory just a simple "Master box is alive" heartbeat needs to be sent over the LAN or OPT1.

                      But if the heartbeat absolutely has to be on the wire where the interface containing the CARP IP is, then I guess we'll just have to leave things as is.

                      1 Reply Last reply Reply Quote 0
                      • jimp
                        jimp Rebel Alliance Developer Netgate last edited by

                        It absolutely has to be that way. It can't send a heartbeat for WAN over any other interface but WAN.

                        In the case you describe, that could be solved by just putting a switch on the WAN side between your firewalls and the CPE. Even if your ISP link is down, the CARP traffic would still happen on the switch and they'd know that there wasn't a hardware failure.

                        1 Reply Last reply Reply Quote 0
                        • R
                          Ree last edited by

                          Great, thanks again for the help.

                          1 Reply Last reply Reply Quote 0
                          • First post
                            Last post

                          Products

                          • Platform Overview
                          • TNSR
                          • pfSense
                          • Appliances

                          Services

                          • Training
                          • Professional Services

                          Support

                          • Subscription Plans
                          • Contact Support
                          • Product Lifecycle
                          • Documentation

                          News

                          • Media Coverage
                          • Press
                          • Events

                          Resources

                          • Blog
                          • FAQ
                          • Find a Partner
                          • Resource Library
                          • Security Information

                          Company

                          • About Us
                          • Careers
                          • Partners
                          • Contact Us
                          • Legal
                          Our Mission

                          We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

                          Subscribe to our Newsletter

                          Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

                          © 2021 Rubicon Communications, LLC | Privacy Policy