Date: Tue, 1 Sep 2020 10:13:23 +0200 From: Julien Cigar <julien@perdition.city> To: Michael Gmelin <freebsd@grem.de> Cc: freebsd-net@freebsd.org Subject: Re: CARP over VLAN over LAGG Message-ID: <20200901081323.amsc55h5xnikbycu@x1> In-Reply-To: <8A98D287-4202-493B-8515-4377740B126A@grem.de> References: <20200831083705.pvrjk4srdohlxklf@x1> <8A98D287-4202-493B-8515-4377740B126A@grem.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Aug 31, 2020 at 01:55:52PM +0200, Michael Gmelin wrote: > > > > On 31. Aug 2020, at 10:37, Julien Cigar <julien@perdition.city> wrote: > > > > On Fri, Aug 28, 2020 at 04:52:01PM +0200, Julien Cigar wrote: > >> Hello, > >> > >> I have a "highly available" router/firewall with the following > >> configuration (1). Those are plugged in two 2930F (with VSF) using LACP. > >> It works well, except that I have some weird issues with the CARP > >> demotion counter when I'm unplugging some interfaces involved in the > >> lagg/carp setup, for example if I unplug/replug igb0 and igb1 in this > >> case: > >> > >> (dmesg): > >> igb0: link state changed to DOWN > >> igb1: link state changed to DOWN > >> carp: demoted by 240 to 240 (send error 50 on vlan11) > >> carp: 11@vlan11: MASTER -> BACKUP (more frequent advertisement received) > >> vlan11: deletion failed: 3 > >> igb1: link state changed to UP > >> igb0: link state changed to UP > >> > >> then the CARP status stays to BACKUP unless I demote the CARP demotion > >> counter manually with: sudo sysctl net.inet.carp.demotion=-240: > >> > >> (dmesg): > >> carp: demoted by -240 to 0 (sysctl) > >> carp: 11@vlan11: BACKUP -> MASTER (preempting a slower master) > >> > >> I guess this is because it takes some time for lagg/lacp to converge and > >> thus carp thinks that there is a problematic condition as it experiences > >> problems with sending announcements.. > >> > >> What it the best way to handle this? > > > > I'm wondering if setting net.inet.carp.senderr_demotion_factor to "0" > > could be a solution? Are there any downsides of setting this to "0" > > instead of "240"? > > > > Sharing your pf.conf from both hosts could be helpful analyzing the issue. Here is my pf.conf (it's the same on both host): https://gist.github.com/silenius/b758851f03c28ef8caaa53cfe381c455 However, I don't think pf is the issue here, the problem is that there is a slight delay when LAGG/LACP converge and thus CARP increase the demotion counter by net.inet.carp.senderr_demotion_factor (240). > > -m > > -- Julien Cigar Belgian Biodiversity Platform (http://www.biodiversity.be) PGP fingerprint: EEF9 F697 4B68 D275 7B11 6A25 B2BB 3710 A204 23C0 No trees were killed in the creation of this message. However, many electrons were terribly inconvenienced.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200901081323.amsc55h5xnikbycu>