On 6/9/2020 1:42 PM, Markus Wernig wrote:
Neither jumbo frames nor multicast will prevent group demotion when the
other side of a crosslink cable goes physically down. Only not having
the sync interface in the carp group will.
True. But I think he was just discussing general best practices,
On 6/9/20 9:25 PM, Paul B. Henson wrote:
> Hmm, I had never considered using jumbo frames.
...
> I guess multicast would work too
Neither jumbo frames nor multicast will prevent group demotion when the
other side of a crosslink cable goes physically down. Only not having
the sync interface in
ake sense to me.
I guess multicast would work too for a direct peer relationship, but it
just seemed more accurate to explicitly configure the two peers.
Some documentation regarding the interaction of pfsync and the carp
group might be helpful, along with a suggestion to remove the carp gr
On 2020-06-08, Markus Wernig wrote:
> On 6/9/20 12:27 AM, Paul B. Henson wrote:
>
>> Yes, I am using a direct link between the two physical firewalls.
> [...]
>> Is this no longer a best practice?
>
> If it's in the documentation, I suppose it still is.
>
> But I have found it problematic,
On 6/9/20 12:27 AM, Paul B. Henson wrote:
> Yes, I am using a direct link between the two physical firewalls.
[...]
> Is this no longer a best practice?
If it's in the documentation, I suppose it still is.
But I have found it problematic, because taking down one firewall, or
even only its sync
On 6/8/2020 6:29 AM, Philipp Buehler wrote:
did you follow some "howto" and set net.inet.carp.preempt=1?
Well, if you consider the official openBSD documentation a "how-to",
then yes :).
In the example in https://www.openbsd.org/faq/pf/carp.html under the
section "Combining CARP and
On 6/7/2020 5:21 PM, Markus Wernig wrote:
I don't see that behaviour on my carp pair. Are you using a cross-link
cable between the two firewalls? (You shouldn't, in my experience.)
Yes, I am using a direct link between the two physical firewalls. It
seems to be the configuration recommended
Am 08.06.2020 00:29 schrieb Paul B. Henson:
However, for only two firewalls, when you're using the syncpeer
directive for the pfsync interface, it seems it would be better not to
default to belonging to the carp group? With only two firewalls, if
one of them has broken synchronization, so does
On 6/8/20 12:29 AM, Paul B. Henson wrote:
> whenever I rebooted the secondary firewall, the
> carp interfaces on the primary would flip to backup and then back to
> master as the secondary one rebooted
I don't see that behaviour on my carp pair. Are you using a cross-link
cable between the two
the other, so is there any
real point in trying to migrate away from the one that's currently master?
I updated my configuration to remove the pfsync interface from the carp
group and now when I reboot there are no issues with the carp interfaces
changing state or connections being dropped. Would
10 matches
Mail list logo