On 1-3-2012 18:10, Marios Makassikis wrote:
> Here you go:
> carp:
> 45808 packets received (IPv4)
> 74835 packets received (IPv6)
> 0 packets discarded for bad interface
> 0 packets discarded for wrong TTL
> 0 packets shorter than header
> 0 discarded for bad checksums
> 0 discarded packets with a bad version
> 0 discarded because packet too short
> 0 discarded for bad authentication
> 32062 discarded for unknown vhid
> 0 discarded because of a bad address list
> 1582 packets sent (IPv4)
> 1582 packets sent (IPv6)
> 0 send failed due to mbuf memory error
> 923 transitions to master
>
> The unknown vhid is because there another set of hosts using CARP
> on the same link. The fw1 and fw2 are using the same vhid.
Ok.
>> If I look at the code netinet/ip_carp.c:
>>
>>> error = ip_output(m, NULL, NULL, IP_RAWOUTPUT,
> &sc->sc_imo,
>>> NULL);
>>> if (error) {
>>> if (error == ENOBUFS)
>>> carpstats.carps_onomem++;
>>> else
>>> CARP_LOG(LOG_WARNING, sc,
>>> ("ip_output failed: %d", error));
>>> sc->sc_if.if_oerrors++;
>>> if (sc->sc_sendad_errors < INT_MAX)
>>> sc->sc_sendad_errors++;
>>> if (sc->sc_sendad_errors ==
> CARP_SENDAD_MAX_ERRORS(sc))
>>> carp_group_demote_adj(&sc->sc_if, 1,
>>> "> snderrors");
>>
>>
>> Either the "send failed due to mbuf memory error" counter should be
>> increasing, or an "ip_output failed" error should appear in the log.
>>
>
> As I said before, there's nothing besides state transitions and the snderrors
> I pasted and incorrectly interpreted. From your input, I take it the
> first demotion
> was because I put a 'block all', and as such the CARP packets were
> correctly blocked.
> The value going back to one is most likely due to the fact I reloaded
> PF with a rule
> to let CARP traffic pass. However, that doesn't explain why it isn't
> going back to 0.
Sorry, you need to bump net.inet.carp.log even more to see the
ip_output() error. Can you try net.inet.carp.log=6 ?
It's probably pf blocking the carp packets indeed, but maybe another
error will show up as well.
