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



  • 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



  • 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



  • 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.


Log in to reply