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
