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.