From owner-freebsd-net@freebsd.org Mon Aug 31 11:56:06 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 DFD773BDF70 for ; Mon, 31 Aug 2020 11:56:06 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.evolve.de (mail.evolve.de [213.239.217.29]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (Client CN "mail.evolve.de", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bg7vT5w2Kz4QBB for ; Mon, 31 Aug 2020 11:56:05 +0000 (UTC) (envelope-from freebsd@grem.de) Received: by mail.evolve.de (OpenSMTPD) with ESMTP id d2b0cc9a; Mon, 31 Aug 2020 11:55:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=grem.de; h=content-type :content-transfer-encoding:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; s=20180501; bh=3kC5SOLJgCDD0r uhOFKLDoeK42Y=; b=PpqEDAC5+MI1r5T9q5TIoPPxQbeuw2fI2sEd6ikeexCzTO 0ciC/eU1r733V1tw59zxoI+xnWrIBB3UceRcU8zGJl+LkmpA4MfHe9aQcuoIdFi6 XWw0LzAVpaCkJPG0ZPnIXcZ7Ue1k/s4qY6K4/vKWbDl5GyApp0w7febiwaCxz/qk 0yq2H35iExP75CUWxTxylBLi3N6NR7sKFiMtwkC0q0xHyBU1heYuqOim4LwAlLny zfQ1mGKcbV2ZCsCOLcycVkocXxRteI6nTnnn4vQF9ttztxn0ws88/kTopJ/spCsp 3I2jXevMmHiwrvu0IcJMJtRQSLViDbZYrINEp1tw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=grem.de; h=content-type :content-transfer-encoding:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; q=dns; s=20180501; b=Ue8OUbIA 6b9Zz5Wn+ctGM1Mg++pF8EmiVOi5NuSb82rVsspYtFHxg+uRM7Dq4y6R6B7fL395 foIOVj5kLZL38p+zT9sYV+i96xyTElQBa+MCN16nrnmCDGpQQ+/6Nuq/AogR2iYN +71qF7XOGgy8Dy6gGiYsbiQ3GIQuG+DR/p/DunD3wFg2Oh9fcqb8A5cArNk+nPUL OZwl+QAennWVjPWfzVs1T5ox2yZqeYYBQH8vpzw0IjY2r5dwIB/KKgbXGkIebyyz FLuKFalbsCjIJzR7EGoUyBFIgC7UMAgRZmrb6F6DXgwECk3GcC2qe5fV4rnMTUMD VpYjmW915+ZXyg== Received: by mail.evolve.de (OpenSMTPD) with ESMTPSA id 39f8f730 (TLSv1.2:ECDHE-RSA-CHACHA20-POLY1305:256:NO); Mon, 31 Aug 2020 11:55:53 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Subject: Re: CARP over VLAN over LAGG From: Michael Gmelin In-Reply-To: <20200831083705.pvrjk4srdohlxklf@x1> Date: Mon, 31 Aug 2020 13:55:52 +0200 Cc: freebsd-net@freebsd.org Message-Id: <8A98D287-4202-493B-8515-4377740B126A@grem.de> References: <20200831083705.pvrjk4srdohlxklf@x1> To: Julien Cigar X-Mailer: iPhone Mail (17G80) X-Rspamd-Queue-Id: 4Bg7vT5w2Kz4QBB X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=grem.de header.s=20180501 header.b=PpqEDAC5; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd@grem.de designates 213.239.217.29 as permitted sender) smtp.mailfrom=freebsd@grem.de X-Spamd-Result: default: False [-2.98 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[grem.de:s=20180501]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:213.239.217.29/32]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grem.de]; NEURAL_HAM_LONG(-1.01)[-1.007]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[grem.de:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.95)[-0.951]; NEURAL_HAM_MEDIUM(-1.02)[-1.018]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:213.239.192.0/18, country:DE]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-net] 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: Mon, 31 Aug 2020 11:56:06 -0000 > On 31. Aug 2020, at 10:37, Julien Cigar wrote: >=20 > =EF=BB=BFOn Fri, Aug 28, 2020 at 04:52:01PM +0200, Julien Cigar wrote: >> Hello, >>=20 >> 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=20 >> demotion counter when I'm unplugging some interfaces involved in the=20 >> lagg/carp setup, for example if I unplug/replug igb0 and igb1 in this=20 >> case: >>=20 >> (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 >>=20 >> then the CARP status stays to BACKUP unless I demote the CARP demotion >> counter manually with: sudo sysctl net.inet.carp.demotion=3D-240: >>=20 >> (dmesg): >> carp: demoted by -240 to 0 (sysctl) >> carp: 11@vlan11: BACKUP -> MASTER (preempting a slower master) >>=20 >> 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.. >>=20 >> What it the best way to handle this? >=20 > 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"? >=20 Sharing your pf.conf from both hosts could be helpful analyzing the issue. -m