From owner-freebsd-net@freebsd.org Tue Sep 1 08:13:30 2020 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 858E93BCBA4 for ; Tue, 1 Sep 2020 08:13:30 +0000 (UTC) (envelope-from SRS0=LuUt=CK=perdition.city=julien@bebif.be) Received: from orval.bbpf.belspo.be (orval.bbpf.belspo.be [193.191.208.90]) by mx1.freebsd.org (Postfix) with ESMTP id 4Bgfw93VCdz46Lb for ; Tue, 1 Sep 2020 08:13:29 +0000 (UTC) (envelope-from SRS0=LuUt=CK=perdition.city=julien@bebif.be) Received: from x1 (77.109.96.40.adsl.dyn.edpnet.net [77.109.96.40]) by orval.bbpf.belspo.be (Postfix) with ESMTPSA id F279E1D4FC26; Tue, 1 Sep 2020 10:13:25 +0200 (CEST) Date: Tue, 1 Sep 2020 10:13:23 +0200 From: Julien Cigar To: Michael Gmelin Cc: freebsd-net@freebsd.org Subject: Re: CARP over VLAN over LAGG Message-ID: <20200901081323.amsc55h5xnikbycu@x1> Mail-Followup-To: Michael Gmelin , freebsd-net@freebsd.org References: <20200831083705.pvrjk4srdohlxklf@x1> <8A98D287-4202-493B-8515-4377740B126A@grem.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8A98D287-4202-493B-8515-4377740B126A@grem.de> X-Rspamd-Queue-Id: 4Bgfw93VCdz46Lb X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of SRS0=LuUt=CK=perdition.city=julien@bebif.be designates 193.191.208.90 as permitted sender) smtp.mailfrom=SRS0=LuUt=CK=perdition.city=julien@bebif.be X-Spamd-Result: default: False [-1.17 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.01)[-1.014]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-0.98)[-0.984]; MIME_GOOD(-0.10)[text/plain]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_NA(0.00)[perdition.city]; NEURAL_SPAM_SHORT(0.23)[0.232]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FORGED_SENDER(0.30)[julien@perdition.city,SRS0=LuUt=CK=perdition.city=julien@bebif.be]; RCVD_NO_TLS_LAST(0.10)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:2611, ipnet:193.191.192.0/19, country:BE]; FROM_NEQ_ENVFROM(0.00)[julien@perdition.city,SRS0=LuUt=CK=perdition.city=julien@bebif.be]; MAILMAN_DEST(0.00)[freebsd-net]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2020 08:13:30 -0000 On Mon, Aug 31, 2020 at 01:55:52PM +0200, Michael Gmelin wrote: > > > > On 31. Aug 2020, at 10:37, Julien Cigar 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.