I've updated bug 1072 (http://redmine.pfsense.org/issues/1072)
According to packet dump carp vhid=1192.168.252.254 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 0, authtype #128, intvl 1s, length 36, addrs(7): 107.95.16.142,89.11.4.1,28.106.118.248,149.43.12.212,148.195.215.246,252.189.185.117,56.253.61.5
0x0000: 0100 5e00 0012 0000 5e00 0101 0800 4510 0x0010: 0038 d66a 4000 ff70 0000 c0a8 fcfe e000 0x0020: 0012 2101 0007 8001 b7a9 6b5f 108e 590b 0x0030: 0401 1c6a 76f8 952b 0cd4 94c3 d7f6 fcbd 0x0040: b975 38fd 3d05 carp vhid=256192.168.253.254 > 224.0.0.18: VRRPv2, Advertisement, vrid 0, prio 0, authtype simple, intvl 1s, length 36, addrs(7): 137.7.31.146,238.223.10.81,90.241.214.208,59.45.154.124,64.216.227.11,117.38.205.9,26.19.86.208[|vrrp]
0x0000: 0100 5e00 0012 0000 5e00 0100 0800 4510 0x0010: 0038 8271 4000 ff70 0000 c0a8 fdfe e000 0x0020: 0012 2100 0007 0101 5dc9 8907 1f92 eedf 0x0030: 0a51 5af1 d6d0 3b2d 9a7c 40d8 e30b 7526 0x0040: cd09 1a13 56d0seems like there is something wrong with bit shifting for vhidx field (previously it was known as "carp_pad1" field). When interface's vhid<=255 - it's allways 10000000b (0x80) and only when interface's vhid>=255 everything works as expected.
2ALL: Temporary workaround for this situation is to use VHID greater than 255.
On 15.12.2010 1:23, st41ker wrote:
Hello, Is there is any update on the issue? On 11.12.2010 12:30, st41...@st41ker.net wrote:Hello, Understood. The requested changes has been made and the result is the same. Please, clarify, what exactly statistics do you need? Here is complete output of netstat -ss #uptime; netstat -ss 12:28PM up 33 mins, 2 users, load averages: 0.23, 0.23, 0.11 tcp: 14643 packets sent 6316 data packets (2478656 bytes) 433 data packets (375832 bytes) retransmitted 25 data packets unnecessarily retransmitted 7266 ack-only packets (0 delayed) 85 window update packets 552 control packets 12769 packets received 6093 acks (for 2483590 bytes) 255 duplicate acks 6666 packets (2405848 bytes) received in-sequence 1 out-of-order packet (0 bytes) 11 window update packets 193 connection requests 205 connection accepts 4 ignored RSTs in the windows 396 connections established (including accepts) 388 connections closed (including 17 drops) 119 connections updated cached RTT on close 128 connections updated cached RTT variance on close 41 connections updated cached ssthresh on close 2 embryonic connections dropped 5376 segments updated rtt (of 5566 attempts) 638 retransmit timeouts 12 connections dropped by rexmit timeout 2 keepalive timeouts 2 connections dropped by keepalive 1986 correct data packet header predictions 205 syncache entries added 5 retransmitted 3 dropped 205 completed 208 cookies sent 130 SACK options (SACK blocks) received udp: 2200 datagrams received 173 dropped due to no socket 589 broadcast/multicast datagrams undelivered 1438 delivered 11169 datagrams output sctp: Packet drop statistics: Timeouts: ip: 68772 total packets received 125 bad header checksums 56439 packets for this host 6 packets for unknown/unsupported protocol 7670 packets forwarded 150 packets not forwardable 29848 packets sent from this host 1182 output packets discarded due to no route icmp: 1544 calls to icmp_error Output histogram: echo reply: 56 destination unreachable: 148 Input histogram: echo reply: 1900 echo: 56 56 message responses generated ICMP address mask responses are disabled igmp: 509 messages received 506 membership reports received 503 membership reports received with invalid field(s) 15 membership reports sent ipsec: ah: esp: ipcomp: pim: carp: 17235 packets received (IPv4) 17225 discarded for bad vhid 12296 packets sent (IPv4) pfsync: 21776 packets received (IPv4) 21768 packets discarded for bad interface 12898 packets sent (IPv4) arp: 2381 ARP requests sent 61 ARP replies sent 3735 ARP requests received 27 ARP replies received 3762 ARP packets received 2317 total packets dropped due to no ARP entry 26 ARP entrys timed out ip6: 51 total packets received 51 packets sent from this host Input histogram: ICMP6: 51 Mbuf statistics: 0 one mbuf 51 one ext mbuf 0 two or more ext mbuf Source addresses selection rule applied: icmp6: Output histogram: neighbor solicitation: 12 MLDv2 listener report: 37 Histogram of error messages to be generated: ipsec6: rip6: pfkey: 2 requests sent from userland 32 bytes sent from userland histogram by message type: flush: 1 x_spdflush: 1 2 requests sent to userland 32 bytes sent to userland histogram by message type: flush: 1 x_spdflush: 1 According to ip_carp.c this counter (discarded for bad vhid) incremented each time when phys. interface on which carp packet was received does not contains any carp interface assosiated or if VHID of assotiated CARP interfaces does not contains the VHID got in the received packet. IMHO the problem could be in binaries. Anyway I've double checked each VLAN interface on router for CARP packets that could get on the "wrong" one due to switch\pfSense interface misconfiguration and there were no signs of such misconfiguration. Every CARP packet getting right to the destination. Also there is intermittent CARP status changes but not for all interfaces and without any logic. On Fri, 10 Dec 2010 20:58:16 +0100, Ermal Luçi<ermal.l...@gmail.com> wrote:Can you please try this change: diff --git a/etc/rc.filter_synchronize b/etc/rc.filter_synchronize index 0a8316b..7bece74 100755 --- a/etc/rc.filter_synchronize +++ b/etc/rc.filter_synchronize @@ -66,7 +66,7 @@ function backup_vip_config_section() { } if($section['advbase']<> "") { $section_val = intval($section['advbase']); - $section_val=$section_val+1; + $section_val=$section_val; if($section_val> 255) $section_val = 255; $section['advbase'] = $section_val; I would like to see even some statistics of your interfaces. On Fri, Dec 10, 2010 at 7:38 PM,<st41...@st41ker.net> wrote:Hello, It seems like this question should be addressed to the pfSense kernel maintainer(s). I've two firewalls on 2.0-BETA4 with CARP enabled. Until the recent upgrade everything worked almost perfect. Now both routers got all CARP devices in MASTER state. Firewall 1: vip6: flags=49<UP,LOOPBACK,RUNNING> metric 0 mtu 1500 inet 192.168.199.1 netmask 0xffffff00 carp: MASTER vhid 6 advbase 2 advskew 100 vip10: flags=49<UP,LOOPBACK,RUNNING> metric 0 mtu 1500 inet 192.168.0.51 netmask 0xffffff00 carp: MASTER vhid 10 advbase 2 advskew 100 vip12: flags=49<UP,LOOPBACK,RUNNING> metric 0 mtu 1500 inet 192.168.253.252 netmask 0xffffff00 carp: MASTER vhid 12 advbase 2 advskew 100 #netstat -ssp carp carp: 92555 packets received (IPv4) 14 discarded for bad authentication 92222 discarded for bad vhid 39869 packets sent (IPv4) Firewall 2: vip6: flags=49<UP,LOOPBACK,RUNNING> metric 0 mtu 1500 inet 192.168.199.1 netmask 0xffffff00 carp: MASTER vhid 6 advbase 1 advskew 0 vip10: flags=49<UP,LOOPBACK,RUNNING> metric 0 mtu 1500 inet 192.168.0.51 netmask 0xffffff00 carp: MASTER vhid 10 advbase 1 advskew 0 vip12: flags=49<UP,LOOPBACK,RUNNING> metric 0 mtu 1500 inet 192.168.253.252 netmask 0xffffff00 carp: MASTER vhid 12 advbase 1 advskew 0 #netstat -ssp carp carp: 39184 packets received (IPv4) 1 discarded for bad authentication 39074 discarded for bad vhid 93005 packets sent (IPv4) Here is a packet dump: #tcpdump -nvei re0_vlan5 not tcp and not udp tcpdump: listening on re0_vlan5, link-type EN10MB (Ethernet), capture size 96 bytes 20:28:26.227652 00:00:5e:00:01:0a> 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: (tos 0x10, ttl 255, id 13532, offset 0, flags [DF], proto VRRP (112), length 56, bad cksum 0 (->a57a)!) 192.168.0.52> 224.0.0.18: VRRPv2, Advertisement, vrid 10, prio 0, authtype #128, intvl 1s, length 36, addrs(7): 227.234.177.249,120.162.118.75,40.102.130.17,242.232.0.66,58.203.185.41,64.96.187.4,114.121.226.49 20:28:26.723778 00:00:5e:00:01:0a> 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: (tos 0x10, ttl 255, id 13772, offset 0, flags [DF], proto VRRP (112), length 56) 192.168.0.53> 224.0.0.18: VRRPv2, Advertisement, vrid 10, prio 100, authtype #128, intvl 2s, length 36, addrs(7): 227.234.177.249,120.162.117.92,228.194.169.203,197.128.149.181,204.97.168.247,234.48.188.234,14.68.23.250 20:28:27.223192 00:00:5e:00:01:0a> 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: (tos 0x10, ttl 255, id 57411, offset 0, flags [DF], proto VRRP (112), length 56, bad cksum 0 (->fa12)!) 192.168.0.52> 224.0.0.18: VRRPv2, Advertisement, vrid 10, prio 0, authtype #128, intvl 1s, length 36, addrs(7): 227.234.177.249,120.162.118.76,5.159.71.110,98.90.217.70,117.200.253.191,117.207.179.185,132.131.241.197 20:28:28.218741 00:00:5e:00:01:0a> 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: (tos 0x10, ttl 255, id 26425, offset 0, flags [DF], proto VRRP (112), length 56, bad cksum 0 (->731d)!) 192.168.0.52> 224.0.0.18: VRRPv2, Advertisement, vrid 10, prio 0, authtype #128, intvl 1s, length 36, addrs(7): 227.234.177.249,120.162.118.77,156.42.80.119,212.10.43.254,52.127.252.175,13.193.236.116,250.186.146.126 20:28:29.115843 00:00:5e:00:01:0a> 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: (tos 0x10, ttl 255, id 17830, offset 0, flags [DF], proto VRRP (112), length 56) 192.168.0.53> 224.0.0.18: VRRPv2, Advertisement, vrid 10, prio 100, authtype #128, intvl 2s, length 36, addrs(7): 227.234.177.249,120.162.117.93,134.208.204.108,14.90.209.13,71.169.61.99,222.84.234.186,206.168.118.252 20:28:29.214280 00:00:5e:00:01:0a> 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: (tos 0x10, ttl 255, id 20580, offset 0, flags [DF], proto VRRP (112), length 56, bad cksum 0 (->89f2)!) 192.168.0.52> 224.0.0.18: VRRPv2, Advertisement, vrid 10, prio 0, authtype #128, intvl 1s, length 36, addrs(7): 227.234.177.249,120.162.118.78,152.171.173.48,92.93.224.15,236.101.105.252,83.24.68.20,227.104.66.63 Overall picture is the same as it was before the upgrade, except that each machine now ignores the carp packets. Did someone make changes in FreeBSD carp subsystem? -- Thanks, St41ker. --------------------------------------------------------------------- To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org--------------------------------------------------------------------- To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org--------------------------------------------------------------------- To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
--------------------------------------------------------------------- To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
