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

    CARP VIP dropping packets

    Scheduled Pinned Locked Moved HA/CARP/VIPs
    3 Posts 2 Posters 1.2k 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.
    • M Offline
      mcampbell
      last edited by

      So I've been stuck with a network latency/packet loss problem.  In order to better understand what's going on in my network, I opened up some 7-10 cmd windows, each pinging a different box to determine the what's dropping and when.  I found that my CARP setup is dropping packets on its LAN VIP, but simultaneous pings to the CARP master/slave IPs show virtually no droppage.  I'd found another topic in a similar vein that suggested that perhaps I was using a VHID that was already in use on the network (it's been set to 1), so I tried changing it to 10, but the problem didn't go away.

      I really didn't see any other suggestions on the matter, and I'm out of ideas, so apologies if I missed another related topic, but could someone please help out on this issue?  We're having regular dropouts on our VPN as well as a result, so it's affecting my coworkers' ability to perform work.

      Thanks in advance!

      1 Reply Last reply Reply Quote 0
      • M Offline
        mcampbell
        last edited by

        I meant to note that I get wildly erratic pings when doing a test ping of my LAN's VIP:

        Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Request timed out.
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Request timed out.
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Request timed out.
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Request timed out.
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Request timed out.
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Request timed out.
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Request timed out.
Reply from 10.100.1.1: bytes=32 time=14ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64
Reply from 10.100.1.1: bytes=32 time<1ms TTL=64

        And yet, simultaneous pings of the local IPs of the two nodes in the cluster show no dropped packets.  Please, any help you could provide would be greatly appreciated.

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

          Check the logs. A packet capture will show if something is using CARP/VRRP on the wire and what VHIDs are in use. It seems unlikely that you would see VRRP traffic on the LAN unless you are not in control of the LAN side of your network.

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