From owner-freebsd-pf@FreeBSD.ORG Wed Apr 2 13:18:28 2014 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 63A40574 for ; Wed, 2 Apr 2014 13:18:28 +0000 (UTC) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DCC48EAB for ; Wed, 2 Apr 2014 13:18:27 +0000 (UTC) Received: by mail-lb0-f171.google.com with SMTP id w7so148279lbi.30 for ; Wed, 02 Apr 2014 06:18:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=IlnkqK0rw0UbYlajJ8GBFCzXDY9B+z6xxp/15OxdNJA=; b=E79WZw77KpSjm7TE5Czbev5kBMM59YuJjOLr2EXpqkibKl0temn82fAC/PXagqq13T hfKN4YMHDoe6OpCQVSqfVP10A/ZlL3s9zFC6uOwByvqHRyxRcFmJB3oHvzRyN0syO+gi FcYDYU+0yrYZfD9Gy7eely3sIvPb2sxNIjlrUhJ3+r2r6b2/O/NcK/D7wT3tFO+Tmbdm SyZIN34YJtqzBkQjnHuHOWBWkOURT06laHeQmhln+oTMCGUQJTd+jeBRybWX0GLPkczh 1hxTNp1clUsQFx2SxB7n3mZ9zwidRQePG5nYn7jbqBwpVIpZi0Ga6CgdfsNk0ZVqrJqW YPQA== X-Gm-Message-State: ALoCoQmbIMnsBiun8JYwMjMD6Pmo5vbvpJ67snC7uL9dMQUIWLEpyN1G1rRMz4Hlf4FN3XnffTlA X-Received: by 10.112.198.164 with SMTP id jd4mr18355lbc.92.1396444394380; Wed, 02 Apr 2014 06:13:14 -0700 (PDT) Received: from grey.office.se.prisjakt.nu ([212.16.170.194]) by mx.google.com with ESMTPSA id f9sm1919046laa.8.2014.04.02.06.13.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Apr 2014 06:13:13 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: FreeBSD 10-STABLE and CARP states From: mxb In-Reply-To: Date: Wed, 2 Apr 2014 15:13:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1E20234E-4F81-4BA1-BA57-FADD80F782F4@alumni.chalmers.se> References: <4A818132-757F-4BAD-8137-CDB1F6F0681C@alumni.chalmers.se> To: freebsd-net@freebsd.org X-Mailer: Apple Mail (2.1874) Cc: freebsd-pf@freebsd.org X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 13:18:28 -0000 OK, thanks everyone whom replayed. E.g. NONE. The problem seems to be related to LACP trunking. Disabling LACP and configuring trunk in =91loadbalance=92 mode puts all = in desired state (even after reboot). lagg0: flags=3D8943 = metric 0 mtu 9000 = options=3D8407bb ether 00:25:90:e3:71:f2 inet 172.16.0.234 netmask 0xfffff800 broadcast 172.16.7.255 inet6 fe80::225:90ff:fee3:71f2%lagg0 prefixlen 64 scopeid 0x5 inet 172.16.0.231 netmask 0xfffff800 broadcast 172.16.7.255 vhid = 201 inet 172.16.0.233 netmask 0xfffff800 broadcast 172.16.7.255 vhid = 202 nd6 options=3D29 media: Ethernet autoselect status: active carp: MASTER vhid 201 advbase 1 advskew 1 carp: BACKUP vhid 202 advbase 5 advskew 100 laggproto loadbalance lagghash l2,l3,l4 laggport: ix1 flags=3D4 laggport: ix0 flags=3D4 vlan2: flags=3D8943 = metric 0 mtu 9000 options=3D303 ether 00:25:90:e3:71:f2 inet 10.11.11.201 netmask 0xffffff00 broadcast 10.11.11.255 inet6 fe80::225:90ff:fee3:71f2%vlan2 prefixlen 64 scopeid 0x6 inet 10.11.12.203 netmask 0xffffff00 broadcast 10.11.12.255 vhid = 12 nd6 options=3D29 media: Ethernet autoselect status: active vlan: 2 parent interface: lagg0 carp: BACKUP vhid 12 advbase 1 advskew 100 //mxb =20 On 2 apr 2014, at 09:35, mxb wrote: >=20 > Moving this to freebsd-pf. >=20 > On 31 mar 2014, at 22:21, mxb wrote: >=20 >>=20 >> Manually setting net.inet.carp.demotion brought BOTH VHIDs in desired = state. >> pfsync bulk update seems to not put everything back as it should. >>=20 >> lagg0: flags=3D8943 = metric 0 mtu 9000 >> = options=3D8407bb >> ether 00:25:90:e3:71:f2 >> inet 172.16.0.234 netmask 0xfffff800 broadcast 172.16.7.255 >> inet6 fe80::225:90ff:fee3:71f2%lagg0 prefixlen 64 scopeid 0x5 >> inet 172.16.0.231 netmask 0xfffff800 broadcast 172.16.7.255 vhid = 201 >> inet 172.16.0.233 netmask 0xfffff800 broadcast 172.16.7.255 vhid = 202 >> nd6 options=3D29 >> media: Ethernet autoselect >> status: active >> carp: MASTER vhid 201 advbase 1 advskew 1 >> carp: BACKUP vhid 202 advbase 5 advskew 100 >> laggproto lacp lagghash l2,l3,l4 >> laggport: ix1 flags=3D1c >> laggport: ix0 flags=3D1c >>=20 >>=20 >> On 31 mar 2014, at 20:42, mxb wrote: >>=20 >>>=20 >>> Hi list, >>>=20 >>> hopefully this is the right place to have my question regarding CARP = on 10-STABLE. >>>=20 >>> I have two nodes with following setup(node1): >>>=20 >>> lagg0: flags=3D8943 = metric 0 mtu 9000 >>> = options=3D8407bb >>> ether 00:25:90:e3:71:f2 >>> inet 172.16.0.234 netmask 0xfffff800 broadcast 172.16.7.255 >>> inet6 fe80::225:90ff:fee3:71f2%lagg0 prefixlen 64 scopeid 0x5 >>> inet 172.16.0.231 netmask 0xfffff800 broadcast 172.16.7.255 vhid = 201 >>> inet 172.16.0.233 netmask 0xfffff800 broadcast 172.16.7.255 vhid = 202 >>> nd6 options=3D29 >>> media: Ethernet autoselect >>> status: active >>> carp: BACKUP vhid 201 advbase 1 advskew 1 >>> carp: BACKUP vhid 202 advbase 5 advskew 100 >>> laggproto lacp lagghash l2,l3,l4 >>> laggport: ix1 flags=3D1c >>> laggport: ix0 flags=3D1c >>>=20 >>> net.inet.carp.preempt=3D1 on both nodes. as well as PSYNC as this: >>>=20 >>> pfsync0: flags=3D41 metric 0 mtu 1500 >>> pfsync: syncdev: vlan22 syncpeer: 10.22.22.2 maxupd: 128 defer: = off >>>=20 >>> The problem is (if it is not clear from the ifconfig-output for the = lagg0) the state of VHID 201. >>> Node2 with advskew of 100 is currently MASTER, but it SHOULD NOT as = of setup. >>>=20 >>> Am I hitting a bug or doing something wrong? >>>=20 >>> I also have noted that after the pfsync bulk update the demotion = counter never setts to 0, but stays on 480, >>> thus preventing node1 become a MASTER 201(?). Or is this a normal = behavior? >>>=20 >>> Regards, >>> mxb >>>=20 >>>=20 >>=20 >=20