Hello,

> No, that's not from your manual commands.  It says there are send errors
> when sending out the carp packets.

My bad.

>
> Just paste the output instead of interpreting...
>

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.

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


Marios

Reply via email to