From owner-freebsd-net@freebsd.org Thu Apr 11 05:17:21 2019 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BEB431579D09 for ; Thu, 11 Apr 2019 05:17:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 514747663D for ; Thu, 11 Apr 2019 05:17:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 1247D1579D07; Thu, 11 Apr 2019 05:17:21 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DF4D21579CFF for ; Thu, 11 Apr 2019 05:17:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1F8287662F for ; Thu, 11 Apr 2019 05:17:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 6D2F0C408 for ; Thu, 11 Apr 2019 05:17:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x3B5HGgU054572 for ; Thu, 11 Apr 2019 05:17:16 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x3B5HGF9054571 for net@FreeBSD.org; Thu, 11 Apr 2019 05:17:16 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 221146] [ixgbe] Problem with second laggport Date: Thu, 11 Apr 2019 05:17:11 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: IntelNetworking, regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: johan@stromnet.se X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 05:17:22 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221146 --- Comment #28 from Johan Str=C3=B6m --- Michael, thanks for the quick pointer! Setting net.inet.carp.senderr_demotion_factor=3D0 makes CARP no longer react this w= ay to individual up/down of underlying lagg interfaces. Instead I just get "carp: demoted by 0 to 0 (send error 50 on vlan18)", and no CARP change. As for this "send error 50", I assume 50 is ENETDOWN, so for some reason the lagg driver signals this for a brief moment while changing it's setup. Not = sure how to proceed in hunting down the root cause for that, but this is not rea= lly a super critical setup, mostly doing this for experimenting. For the record, the other end is a HP 1820-24G (J9980A) and the lagg config= is "laggproto lacp laggport ix0 laggport ix1 laggport ix2 laggport ix3" (unrelated carp rambling below:)=20 Regarding why it did not automatically come back when net.inet.carp.preempt= =3D0, it's of course by design.. In carp(4) DESCRIPTION section for this sysctl (= and on when googling it and reading up on it a bit, and studying the carp sourc= e) it's clear that it is actually a way to make it more aggressive in enforci= ng that the node with the lower advskew is always MASTER. With =3D0 it won't g= o in until it stops seeing the current master, regardless of advskew. In the EXAMPLE section of carp(4) the same option is described as a way to = make multiple interfaces change state at the same time, so I had missed the above fact: "When one of the physical interfaces of host A fails, advskew is demot= ed to a configured value on all its carp vhids. Due to the preempt optio= n, host B would start announcing itself, and thus preempt host A on both interfaces instead of just the failed one."=20 One thing about the text above which almost bit me (as in thinking it was n= ot behaving as expected) was this:=20 If I (on the current master with lower advskew) deconfigured a VLAN from the LACP VLAN trunk of current master, the other node no longer sees the masters announcements, and takes over as master. This only happened for that partic= ular VLAN though, and that confused me.. Doesn't the EXAMPLE say that it should affect all all interfaces when preempt=3D1? Yes, for *ifdown* events... In this scenario it just stopped seeing any incoming traffic in that VLAN... so ofcourse it did not demote the other interfaces, which it would have done with the value of net.inet.carp.ifdown_demotion_factor if the interface actually went down.. Sorry for my rambling, but perhaps someone else (or me, when I have forgott= en the details) might stumble upon it in the future and can benefit from it! --=20 You are receiving this mail because: You are the assignee for the bug.=