On 2014-10-14, Federico Donati <nix.b...@gmail.com> wrote:
> On 10/14/2014 06:53 PM, Andy wrote:
>
>> Why do you have so many CARP interfaces?
>> Generally it's good practice to have one CARP interface per broadcast
>> domain / VLAN etc, and have all your alias IP addresses defined in that
>> one CARP interface.
>> NB; when adding;
>> inet alias <ipaddress> <mask> Always set the mask for each alias to
>> 255.255.255.255
>> This is apparently correct according to the devs. cite; something I was
>> told a long time ago even though you'll get a spurious error in the logs
>> at fail-over time..
I ignore that advice because I am announcing my carp networks into OSPF,
the bad effects *seem* to be limited to some "arp: attempt to add entry ..
on carpXX" / "arp: attempt .... on vlanXX" flip-flop in the logs.
> Hello Andy,
>
> we use so many carp interfaces because we have separate subnets, so the
> netmask 255.255.255.255 can't fit our requirements.
> In past, we tried to use the subnet netmask (i.e. 255.255.255.240), but
> we didn't feel so confident about this configuration, and the official
> documentation does not elaborate on the topic.
>
>> Does it always start once you get to 19?
>>
>> I seem to remember having to increase the number of BPF devices which
>> high numbers of VLANS etc..
This is only needed if you have programs using those bpf devices
(common users include dhcpd, dhcrelay, LLDP listeners).
"fstat | grep bpf" will show what's in use.
>> for(( i=10; i <= 30; i++ )); do mknod /dev/bpf$i c 23 $i; done
>> for(( i=10; i <= 30; i++ )); do chmod o-r,g-r /dev/bpf$i; done
>
> That's intresting. On a similar machine I have only 10 bpf devices
> (0-9). I will study this tomorrow.
Please, don't recommend people do it this way. The right tool for the
job is MAKEDEV (which also takes into account any possible arch
differences in the device major)
# cd /dev
# sh MAKEDEV bpf{10,11,12,...}
>> This all generally looks ok and seems like you know what you're doing.
>> The usual thing which causes multi master is PF. Also rememer to *not*
>> sync your carp states over pfsync, this works for us;
>> pass out quick proto carp keep state (no-sync) set prio 7
>> pass quick proto carp from { fe80::/10 } to { ff00::/8 } keep state (no-sync)
>> pass quick proto carp from { $all_carpv4_ips } keep state (no-sync)
>> pass quick on { $if_pfsync_dev } proto pfsync keep state (no-sync)
>> block drop quick proto carp
Using no-sync is the right thing to do for carp and pfsync states.
IIRC the prio is set automatically for carp, but forcing it doesn't hurt.
FWIW I haven't hit this ..
$ ifconfig carp|grep -c ^carp
29
The most common cause I've seen for split carp states is a mismatch of
IP addresses between master/secondary, though I would think that a
combination of using "defer" and not using "no-sync" on the carp/pfsync
states could very well cause problems like this.
