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

    Carp does not maintain state (explain me carp protocol please)

    Scheduled Pinned Locked Moved HA/CARP/VIPs
    3 Posts 1 Posters 3.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.
    • M
      mgiammarco
      last edited by

      Hello,

      I rewrite my previous post which is not easy understandable.

      I have two pfsense box, active and passive with dual wan. So I have three (wan,wan2,lan) carp ip and a dedicated carp/pfsync ethernet interface.

      If I powerdown active pfsense all tcp connections are interrupted so I see that carp does not maintain state.

      With tcp dump I see:

      master ip      224.0.0.18        vrrp  announcement (v2)
      ..
      ..
      ..
      ..

      If I disconnect master cable:

      slave ip        224.0.0.18        vrrp announcement (v2)
      ..
      ..
      ..
      ..

      Is the protocol working right?

      Please tell me how carp protocol should work.

      Thank again in advance!

      Mario

      1 Reply Last reply Reply Quote 0
      • M
        mgiammarco
        last edited by

        I have also tried to do tcpdump as suggested by sticky thread about 3d interface above. It seems that for wan wan2 and lan multicast is working ok.

        It seems also that pfsync is working ok on 4th ethernet:

        080101 IP6 fe80::216:3eff:fe0c:22c7.5353 > ff02::fb.5353: 0[|domain]
        000114 IP 192.168.0.149.5353 > 224.0.0.251.5353: 0 PTR (QM)? 93.0.168.192.in-addr.arpa. (43)
        000079 IP 192.168.16.203 > 224.0.0.240:  pfsync 548
        000312 IP 192.168.16.202 > 224.0.0.240:  pfsync 372
        000026 IP 192.168.16.202 > 192.168.16.203:  pfsync 52
        000030 IP 192.168.16.203 > 224.0.0.240:  pfsync 372
        000021 IP 192.168.16.203 > 192.168.16.202:  pfsync 52
        000010 IP 192.168.16.203 > 224.0.0.240:  pfsync 500
        000315 IP 192.168.16.202 > 224.0.0.240:  pfsync 500
        000114 IP 94.141.10.234.50910 > 224.0.0.251.5353: 0 PTR (QM)? 93.0.168.192.in-addr.arpa. (43)
        000375 IP 94.141.10.234.56996 > 224.0.0.251.5353: 0 PTR (QM)? 93.0.168.192.in-addr.arpa. (43)
        002334 IP 192.168.16.203 > 224.0.0.240:  pfsync 196
        000012 IP 192.168.16.203 > 224.0.0.240:  pfsync 116
        000009 IP 192.168.16.203 > 224.0.0.240:  pfsync 116
        019717 arp who-has 192.168.0.208 tell 192.168.0.171
        003355 IP 192.168.16.203 > 224.0.0.240:  pfsync 260
        002192 IP 192.168.16.203 > 224.0.0.240:  pfsync 548
        030458 arp who-has 192.168.0.103 tell 192.168.0.171
        007404 IP 192.168.0.93 > 224.0.0.18: VRRPv2, Advertisement, vrid 40, prio 0, authtype none, intvl 1s, length 36
        000578 arp who-has 192.168.0.202 tell 192.168.0.171
        000953 IP 192.168.16.203 > 224.0.0.240:  pfsync 548
        006602 IP 192.168.16.203 > 224.0.0.240:  pfsync 196
        000431 arp who-has 192.168.0.159 tell 192.168.0.171
        006742 IP 192.168.16.203 > 224.0.0.240:  pfsync 260
        006523 IP 94.141.10.235 > 224.0.0.18: VRRPv2, Advertisement, vrid 41, prio 0, authtype none, intvl 1s, length 36
        021856 arp who-has 192.168.0.156 tell 192.168.0.132
        002106 IP 192.168.16.203 > 224.0.0.240:  pfsync 548
        000032 IP 192.168.1.203 > 224.0.0.18: VRRPv2, Advertisement, vrid 42, prio 0, authtype none, intvl 1s, length 36
        018754 arp who-has 192.168.0.177 tell 192.168.0.171
        043912 IP 192.168.16.203 > 224.0.0.240:  pfsync 548
        020907 IP 192.168.16.203 > 224.0.0.240:  pfsync 548

        1 Reply Last reply Reply Quote 0
        • M
          mgiammarco
          last edited by

          Ok I have almost solved this problem: it seems that with cisco catalyst 500 default option of igmp snooping enabled it happens that when master becomes available again the multicast packets are sent with some delay causing a problem with stake keeping.

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