On Sun, Jul 13, 2008 at 02:44:40PM -0500, Karl O. Pinc wrote:
> On 07/12/2008 04:12:14 PM, Karl O. Pinc wrote:
>> The one unusual thing about my configuration is that
>> I don't bring up pf with rc.conf.local. Pf is
>> started in rc.local so that it starts after
>> the (secondary, local ,caching) nameserver so that I can
>> use the dns names of my domain in pf.conf.
>
> This is clearly going to cause a problem because
> I also don't allow forwarding until after pf is up,
> so as soon as the carp interfaces become master
> the clients will start receiving icmp unreachable messages
> in response to traffic.
The carp demotion twiddling in RC isn't disabled until after rc.local is
run, so this shouldn't be a problem (but in general it's safe to turn on
forwarding during boot, because the boot-time pf.conf won't pass
forwarded traffic.
> Which brings me back to the question of how the demotion counter
> works, so I can do something to use it to keep the carp interfaces out
> of the master state until pf is up and forwarding on. It seems the
> demotion counter is the tool for that task.
There is some usage information in ifconfig(8), and you can look at
/etc/rc to see how it's being used.
INTERFACE GROUPS
ifconfig -g group-name [[-]carpdemote [number]]
The options are as follows:
-g group-name
Specify the group.
carpdemote [number]
Increase carp(4) demote count for given interface group by
number. If number is omitted, it is increased by 1.
-carpdemote [number]
Decrease carp(4) demote count for given interface group by
number. If number is omitted, it is decreased by 1.
> And, I'll be wanting to keep the carp interfaces out of master until
> pfsync has synchronized,
pfsync manages this itself, you shouldn't have to do anything for this.
> so would appreciate help regarding how to monitor pf's
> synchronization-ness.
There is no simple mechanism for monitoring pf's synchronization-ness;
unless the network is idle the firewalls are rarely perfectly
synchronized.
