From owner-freebsd-net@freebsd.org Sun Mar 11 00:02:01 2018 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 187C0F42C12 for ; Sun, 11 Mar 2018 00:02:01 +0000 (UTC) (envelope-from list1@gjunka.com) Received: from msa1.earth.yoonka.com (yoonka.com [88.98.225.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "msa1.earth.yoonka.com", Issuer "msa1.earth.yoonka.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 974A86CFF9 for ; Sun, 11 Mar 2018 00:02:00 +0000 (UTC) (envelope-from list1@gjunka.com) Received: from crayon2.yoonka.com (crayon2.yoonka.com [10.70.7.20]) (authenticated bits=0) by msa1.earth.yoonka.com (8.15.2/8.15.2) with ESMTPSA id w2B01xVu033453 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sun, 11 Mar 2018 00:01:59 GMT (envelope-from list1@gjunka.com) Subject: Re: Incorrect route interface To: freebsd-net@freebsd.org References: <9dd657bc-ad58-f5cb-327a-572a561f1d6b@gjunka.com> <5AA45F89.7090800@grosbein.net> From: Grzegorz Junka Message-ID: <21e1b380-4d4a-cd26-5694-fac51cc0dfa2@gjunka.com> Date: Sun, 11 Mar 2018 00:01:59 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <5AA45F89.7090800@grosbein.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB-large X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2018 00:02:01 -0000 On 10/03/2018 22:43, Eugene Grosbein wrote: > 11.03.2018 5:01, Grzegorz Junka wrote: > >> In rc.conf I have: >> >> hostname="some.server.com" >> ifconfig_em0="inet 10.20.2.14 netmask 255.255.0.0" >> ifconfig_em1="inet 10.20.2.15 netmask 255.255.0.0" >> ifconfig_igb0="inet 10.20.2.16 netmask 255.255.0.0" > Just do not assign addresses from same network 10.20.0.0/16 to different network interfaces > and you will be fine. Assign them all to right interface: > > ifconfig_em0="inet 10.20.2.14 netmask 255.255.0.0" > ifconfig_em0_alias0="inet 10.20.2.15/32" > ifconfig_igb0_alias0="inet 10.20.2.16/32" > > Do not try to use several physical network cards to connect hosts using just one IP network > as generally each card/interface needs distinct IP network to work flawlessly. > Did you mean: ifconfig_em1_alias0="inet 10.20.2.15/32" I don't quite understand how you can assign an alias to an interface (igb0 in this case) without configuring it with an IP first? According to the documentation an alias is an additional network address, not the only one? From owner-freebsd-net@freebsd.org Sun Mar 11 06:04:44 2018 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 3F471F2F5EB for ; Sun, 11 Mar 2018 06:04:44 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B39BE7A0CA for ; Sun, 11 Mar 2018 06:04:43 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w2B64UYa081363 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 11 Mar 2018 07:04:30 +0100 (CET) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: list1@gjunka.com Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w2B64PDi004025 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 11 Mar 2018 13:04:25 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Incorrect route interface To: Grzegorz Junka , freebsd-net@freebsd.org References: <9dd657bc-ad58-f5cb-327a-572a561f1d6b@gjunka.com> <5AA45F89.7090800@grosbein.net> <21e1b380-4d4a-cd26-5694-fac51cc0dfa2@gjunka.com> From: Eugene Grosbein Message-ID: <5AA4C6E3.2050909@grosbein.net> Date: Sun, 11 Mar 2018 13:04:19 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <21e1b380-4d4a-cd26-5694-fac51cc0dfa2@gjunka.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2018 06:04:44 -0000 11.03.2018 7:01, Grzegorz Junka wrote: >> Just do not assign addresses from same network 10.20.0.0/16 to different network interfaces >> and you will be fine. Assign them all to right interface: >> >> ifconfig_em0="inet 10.20.2.14 netmask 255.255.0.0" >> ifconfig_em0_alias0="inet 10.20.2.15/32" >> ifconfig_igb0_alias0="inet 10.20.2.16/32" Interfaces meant to be all equal, last line should be: ifconfig_em0_alias1="inet 10.20.2.16/32" From owner-freebsd-net@freebsd.org Sun Mar 11 17:46:55 2018 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 4F2A2F40DE4 for ; Sun, 11 Mar 2018 17:46:55 +0000 (UTC) (envelope-from list1@gjunka.com) Received: from msa1.earth.yoonka.com (yoonka.com [88.98.225.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "msa1.earth.yoonka.com", Issuer "msa1.earth.yoonka.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D5EA076096 for ; Sun, 11 Mar 2018 17:46:54 +0000 (UTC) (envelope-from list1@gjunka.com) Received: from crayon2.yoonka.com (crayon2.yoonka.com [10.70.7.20]) (authenticated bits=0) by msa1.earth.yoonka.com (8.15.2/8.15.2) with ESMTPSA id w2BHkqeR051333 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sun, 11 Mar 2018 17:46:52 GMT (envelope-from list1@gjunka.com) Subject: Re: Incorrect route interface To: freebsd-net@freebsd.org References: <9dd657bc-ad58-f5cb-327a-572a561f1d6b@gjunka.com> <5AA45F89.7090800@grosbein.net> <21e1b380-4d4a-cd26-5694-fac51cc0dfa2@gjunka.com> <5AA4C6E3.2050909@grosbein.net> From: Grzegorz Junka Message-ID: <789ff583-7995-75ce-94c8-9e2fe8b17488@gjunka.com> Date: Sun, 11 Mar 2018 17:46:52 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <5AA4C6E3.2050909@grosbein.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB-large X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2018 17:46:55 -0000 On 11/03/2018 06:04, Eugene Grosbein wrote: > 11.03.2018 7:01, Grzegorz Junka wrote: > >>> Just do not assign addresses from same network 10.20.0.0/16 to different network interfaces >>> and you will be fine. Assign them all to right interface: >>> >>> ifconfig_em0="inet 10.20.2.14 netmask 255.255.0.0" >>> ifconfig_em0_alias0="inet 10.20.2.15/32" >>> ifconfig_igb0_alias0="inet 10.20.2.16/32" > Interfaces meant to be all equal, last line should be: > > ifconfig_em0_alias1="inet 10.20.2.16/32" > OK, I see. So this is in case I want many IPs assigned to the same interface. What if I want one IP assigned to multiple interfaces (i.e. so that the additional igb0-3 effectively work as a 4-port switch)? From owner-freebsd-net@freebsd.org Sun Mar 11 20:57:43 2018 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 A92A8F4E49A for ; Sun, 11 Mar 2018 20:57:43 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [89.188.221.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "plan-b.pwste.edu.pl", Issuer "plan-b.pwste.edu.pl" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0D2FE7E791 for ; Sun, 11 Mar 2018 20:57:42 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (zarychtam@localhost [127.0.0.1]) by plan-b.pwste.edu.pl (8.15.2/8.15.2) with ESMTPS id w2BKvWND050859 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 11 Mar 2018 21:57:32 +0100 (CET) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: (from zarychtam@localhost) by plan-b.pwste.edu.pl (8.15.2/8.15.2/Submit) id w2BKvV7c050843; Sun, 11 Mar 2018 21:57:31 +0100 (CET) (envelope-from zarychtam) Date: Sun, 11 Mar 2018 21:57:31 +0100 From: Marek Zarychta To: Grzegorz Junka Cc: freebsd-net@freebsd.org Subject: Re: Incorrect route interface Message-ID: <20180311205731.GA30079@plan-b.pwste.edu.pl> References: <9dd657bc-ad58-f5cb-327a-572a561f1d6b@gjunka.com> <5AA45F89.7090800@grosbein.net> <21e1b380-4d4a-cd26-5694-fac51cc0dfa2@gjunka.com> <5AA4C6E3.2050909@grosbein.net> <789ff583-7995-75ce-94c8-9e2fe8b17488@gjunka.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="WIyZ46R2i8wDzkSu" Content-Disposition: inline In-Reply-To: <789ff583-7995-75ce-94c8-9e2fe8b17488@gjunka.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2018 20:57:43 -0000 --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 11, 2018 at 05:46:52PM +0000, Grzegorz Junka wrote: >=20 > On 11/03/2018 06:04, Eugene Grosbein wrote: > > 11.03.2018 7:01, Grzegorz Junka wrote: > > > >>> Just do not assign addresses from same network 10.20.0.0/16 to differ= ent network interfaces > >>> and you will be fine. Assign them all to right interface: > >>> > >>> ifconfig_em0=3D"inet 10.20.2.14 netmask 255.255.0.0" > >>> ifconfig_em0_alias0=3D"inet 10.20.2.15/32" > >>> ifconfig_igb0_alias0=3D"inet 10.20.2.16/32" > > Interfaces meant to be all equal, last line should be: > > > > ifconfig_em0_alias1=3D"inet 10.20.2.16/32" > > >=20 > OK, I see. So this is in case I want many IPs assigned to the same=20 > interface. What if I want one IP assigned to multiple interfaces (i.e.=20 > so that the additional igb0-3 effectively work as a 4-port switch)? >=20 Please consider bonding all NICs as one bridge(4) interface. Then multiple IPs could be assigned to such interface. --=20 Marek Zarychta --WIyZ46R2i8wDzkSu Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEMOqvKm6wKvS1/ZeCdZ/s//1SjSwFAlqlmDgACgkQdZ/s//1S jSx4mQf/brt3ZhW89bNj+dbbI45aSY2RfqdEvJFuB1SAA0NvKHMwDEJYTVHWNhU3 IZYpwBlCDPSA4z9qoVESRFdFThnQU7uj61zUK9g9QpAsuhwR7sh6GE00ne3J6IYu hK9Gp58N/0Cjf7Ke502mBLXPIwP+t3U2yEx6P/da8ntNOjglDukRUfay129bsOM5 pBOQ0zy4wW5xX4wE0FgNLOcqN1NFDVjRINgCCJyhXHKqac98Hm5VSznPdVZzz3XG 2I6LoZi0AvTe0YtCZEnEXy0YF1mDVibstq5zaCjf4z98xWOj2BzY1smx2GejZE9G U0TSFAwby9GOW9U5ruAvAjZjRfWkXw== =qBf+ -----END PGP SIGNATURE----- --WIyZ46R2i8wDzkSu-- From owner-freebsd-net@freebsd.org Sun Mar 11 21:00:46 2018 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 5C3BDF4E840 for ; Sun, 11 Mar 2018 21:00:46 +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.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CAA197EAFD for ; Sun, 11 Mar 2018 21:00:45 +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 C20BD4B05 for ; Sun, 11 Mar 2018 21:00:44 +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 w2BL0ijp012939 for ; Sun, 11 Mar 2018 21:00:44 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w2BL0ieP012931 for freebsd-net@FreeBSD.org; Sun, 11 Mar 2018 21:00:44 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201803112100.w2BL0ieP012931@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: freebsd-net@FreeBSD.org Subject: Problem reports for freebsd-net@FreeBSD.org that need special attention Date: Sun, 11 Mar 2018 21:00:44 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2018 21:00:46 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- In Progress | 165622 | [ndis][panic][patch] Unregistered use of FPU in k In Progress | 206581 | bxe_ioctl_nvram handler is faulty In Progress | 221146 | [ixgbe] Problem with second laggport New | 204438 | setsockopt() handling of kern.ipc.maxsockbuf limi New | 205592 | TCP processing in IPSec causes kernel panic New | 206053 | kqueue support code of netmap causes panic New | 209682 | [panic] [netinet] arptimer race New | 213410 | [carp] service netif restart causes hang only whe New | 217748 | sys/dev/ixgbe/if_ix.c: PVS-Studio: Assignment to Open | 193452 | Dell PowerEdge 210 II -- Kernel panic bce (broadc Open | 194485 | Userland cannot add IPv6 prefix routes Open | 194515 | Fatal Trap 12 Kernel with vimage Open | 199136 | [if_tap] Added down_on_close sysctl variable to t Open | 202510 | [CARP] advertisements sourced from CARP IP cause Open | 206544 | sendmsg(2) (sendto(2) too?) can fail with EINVAL; Open | 211962 | bxe driver queue soft hangs and flooding tx_soft_ Open | 213814 | AWS/EC2: no egress traffic stats on ixv(4) Open | 222273 | igb(4): Kernel panic (fatal trap 12) due to netwo 18 problems total for which you should take action. From owner-freebsd-net@freebsd.org Sun Mar 11 21:23:06 2018 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 28B2EF50822 for ; Sun, 11 Mar 2018 21:23:06 +0000 (UTC) (envelope-from list1@gjunka.com) Received: from msa1.earth.yoonka.com (yoonka.com [88.98.225.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "msa1.earth.yoonka.com", Issuer "msa1.earth.yoonka.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A78E2803D3 for ; Sun, 11 Mar 2018 21:23:05 +0000 (UTC) (envelope-from list1@gjunka.com) Received: from crayon2.yoonka.com (crayon2.yoonka.com [10.70.7.20]) (authenticated bits=0) by msa1.earth.yoonka.com (8.15.2/8.15.2) with ESMTPSA id w2BLN4UM054282 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sun, 11 Mar 2018 21:23:04 GMT (envelope-from list1@gjunka.com) Subject: Re: Incorrect route interface Cc: freebsd-net@freebsd.org References: <9dd657bc-ad58-f5cb-327a-572a561f1d6b@gjunka.com> <5AA45F89.7090800@grosbein.net> <21e1b380-4d4a-cd26-5694-fac51cc0dfa2@gjunka.com> <5AA4C6E3.2050909@grosbein.net> <789ff583-7995-75ce-94c8-9e2fe8b17488@gjunka.com> <20180311205731.GA30079@plan-b.pwste.edu.pl> From: Grzegorz Junka Message-ID: <0abdf126-64f6-9e98-f109-b843ba333086@gjunka.com> Date: Sun, 11 Mar 2018 21:23:04 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20180311205731.GA30079@plan-b.pwste.edu.pl> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB-large X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2018 21:23:06 -0000 On 11/03/2018 20:57, Marek Zarychta wrote: > On Sun, Mar 11, 2018 at 05:46:52PM +0000, Grzegorz Junka wrote: >> On 11/03/2018 06:04, Eugene Grosbein wrote: >>> 11.03.2018 7:01, Grzegorz Junka wrote: >>> >>>>> Just do not assign addresses from same network 10.20.0.0/16 to different network interfaces >>>>> and you will be fine. Assign them all to right interface: >>>>> >>>>> ifconfig_em0="inet 10.20.2.14 netmask 255.255.0.0" >>>>> ifconfig_em0_alias0="inet 10.20.2.15/32" >>>>> ifconfig_igb0_alias0="inet 10.20.2.16/32" >>> Interfaces meant to be all equal, last line should be: >>> >>> ifconfig_em0_alias1="inet 10.20.2.16/32" >>> >> OK, I see. So this is in case I want many IPs assigned to the same >> interface. What if I want one IP assigned to multiple interfaces (i.e. >> so that the additional igb0-3 effectively work as a 4-port switch)? >> > Please consider bonding all NICs as one bridge(4) interface. Then > multiple IPs could be assigned to such interface. > Many thanks Eugene and Marek for your suggestions. I will now need to decide if I want to fragment the network into subnets or bridge the interfaces. GregJ From owner-freebsd-net@freebsd.org Mon Mar 12 12:16:41 2018 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 17A49F40ABA for ; Mon, 12 Mar 2018 12:16:41 +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.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AA1A97853E for ; Mon, 12 Mar 2018 12:16:40 +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 0A82A14B6C for ; Mon, 12 Mar 2018 12:16:40 +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 w2CCGdYP054080 for ; Mon, 12 Mar 2018 12:16:39 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w2CCGdJ4054079 for freebsd-net@FreeBSD.org; Mon, 12 Mar 2018 12:16:39 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: freebsd-net@FreeBSD.org Subject: [Bug 218517] ppp fails adding route with error Value too large to be stored in data type Date: Mon, 12 Mar 2018 12:16:40 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 11.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: eugen@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: eugen@freebsd.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status 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.25 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, 12 Mar 2018 12:16:41 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218517 Eugene Grosbein changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Open |In Progress --- Comment #31 from Eugene Grosbein --- (In reply to emikulic from comment #9) Note that https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D190932 has already been merged to stable/10 with r329913. Please test and respond. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 12 17:37:02 2018 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 8FAE6F2EEBE for ; Mon, 12 Mar 2018 17:37:02 +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.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2941387B75 for ; Mon, 12 Mar 2018 17:37:02 +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 74FA417787 for ; Mon, 12 Mar 2018 17:37:01 +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 w2CHb1B3056795 for ; Mon, 12 Mar 2018 17:37:01 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w2CHb189056794 for freebsd-net@FreeBSD.org; Mon, 12 Mar 2018 17:37:01 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 218517] ppp fails adding route with error Value too large to be stored in data type Date: Mon, 12 Mar 2018 17:37:01 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 11.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: eugen@freebsd.org X-Bugzilla-Flags: 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.25 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, 12 Mar 2018 17:37:02 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218517 --- Comment #32 from commit-hook@freebsd.org --- A commit references this bug: Author: eugen Date: Mon Mar 12 17:36:37 UTC 2018 New revision: 330804 URL: https://svnweb.freebsd.org/changeset/base/330804 Log: MFC r329105: ppp(8): fix code producing debugging logs ppp(8): fix code producing debugging logs Fix several cases when long buffer is copied to shorter one using snprintf that results in contents truncation and clobbering unsaved errno value and creation of misleading logs. PR: 218517 Approved by: mav (mentor) Changes: _U stable/11/ stable/11/usr.sbin/ppp/defs.h stable/11/usr.sbin/ppp/iface.c stable/11/usr.sbin/ppp/ip.c stable/11/usr.sbin/ppp/ipv6cp.c stable/11/usr.sbin/ppp/ncpaddr.c stable/11/usr.sbin/ppp/route.c --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 12 17:38:06 2018 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 21439F2F140 for ; Mon, 12 Mar 2018 17:38:06 +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.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 987E687D80 for ; Mon, 12 Mar 2018 17:38:05 +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 CB3DC17790 for ; Mon, 12 Mar 2018 17:38:04 +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 w2CHc4Nb058301 for ; Mon, 12 Mar 2018 17:38:04 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w2CHc4Ib058300 for freebsd-net@FreeBSD.org; Mon, 12 Mar 2018 17:38:04 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 218517] ppp fails adding route with error Value too large to be stored in data type Date: Mon, 12 Mar 2018 17:38:04 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 11.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: eugen@freebsd.org X-Bugzilla-Flags: 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.25 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, 12 Mar 2018 17:38:06 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218517 --- Comment #33 from commit-hook@freebsd.org --- A commit references this bug: Author: eugen Date: Mon Mar 12 17:37:39 UTC 2018 New revision: 330805 URL: https://svnweb.freebsd.org/changeset/base/330805 Log: MFC r329105: ppp(8): fix code producing debugging logs ppp(8): fix code producing debugging logs Fix several cases when long buffer is copied to shorter one using snprintf that results in contents truncation and clobbering unsaved errno value and creation of misleading logs. PR: 218517 Approved by: mav (mentor) Changes: _U stable/10/ stable/10/usr.sbin/ppp/defs.h stable/10/usr.sbin/ppp/iface.c stable/10/usr.sbin/ppp/ip.c stable/10/usr.sbin/ppp/ipv6cp.c stable/10/usr.sbin/ppp/ncpaddr.c stable/10/usr.sbin/ppp/route.c --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Mon Mar 12 18:04:31 2018 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 68420F31BFB for ; Mon, 12 Mar 2018 18:04:31 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E553A694DE for ; Mon, 12 Mar 2018 18:04:30 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w2CI4Sa2079783; Mon, 12 Mar 2018 11:04:28 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w2CI4SPD079782; Mon, 12 Mar 2018 11:04:28 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201803121804.w2CI4SPD079782@pdx.rh.CN85.dnsmgr.net> Subject: Re: Incorrect route interface In-Reply-To: <0abdf126-64f6-9e98-f109-b843ba333086@gjunka.com> To: Grzegorz Junka Date: Mon, 12 Mar 2018 11:04:28 -0700 (PDT) CC: freebsd-net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 12 Mar 2018 18:04:31 -0000 > > On 11/03/2018 20:57, Marek Zarychta wrote: > > On Sun, Mar 11, 2018 at 05:46:52PM +0000, Grzegorz Junka wrote: > >> On 11/03/2018 06:04, Eugene Grosbein wrote: > >>> 11.03.2018 7:01, Grzegorz Junka wrote: > >>> > >>>>> Just do not assign addresses from same network 10.20.0.0/16 to different network interfaces > >>>>> and you will be fine. Assign them all to right interface: > >>>>> > >>>>> ifconfig_em0="inet 10.20.2.14 netmask 255.255.0.0" > >>>>> ifconfig_em0_alias0="inet 10.20.2.15/32" > >>>>> ifconfig_igb0_alias0="inet 10.20.2.16/32" > >>> Interfaces meant to be all equal, last line should be: > >>> > >>> ifconfig_em0_alias1="inet 10.20.2.16/32" > >>> > >> OK, I see. So this is in case I want many IPs assigned to the same > >> interface. What if I want one IP assigned to multiple interfaces (i.e. > >> so that the additional igb0-3 effectively work as a 4-port switch)? > >> > > Please consider bonding all NICs as one bridge(4) interface. Then > > multiple IPs could be assigned to such interface. > > > > Many thanks Eugene and Marek for your suggestions. I will now need to > decide if I want to fragment the network into subnets or bridge the > interfaces. > GregJ I believe some of the problem you are experincing is addressed in this differential: https://reviews.freebsd.org/D14547 Your original configuration was(is) valid, just not common, and I have not seen this done in more than a decade, but it seems as if rstone@ also has someone doing this "multiple IP's into same subnet on seperate interfaces". -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-net@freebsd.org Mon Mar 12 19:56:23 2018 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 63567F3F1A5 for ; Mon, 12 Mar 2018 19:56:23 +0000 (UTC) (envelope-from list1@gjunka.com) Received: from msa1.earth.yoonka.com (yoonka.com [88.98.225.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "msa1.earth.yoonka.com", Issuer "msa1.earth.yoonka.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DF8026E101 for ; Mon, 12 Mar 2018 19:56:22 +0000 (UTC) (envelope-from list1@gjunka.com) Received: from crayon2.yoonka.com (crayon2.yoonka.com [10.70.7.20]) (authenticated bits=0) by msa1.earth.yoonka.com (8.15.2/8.15.2) with ESMTPSA id w2CJuEXj076678 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 12 Mar 2018 19:56:15 GMT (envelope-from list1@gjunka.com) Subject: Re: Incorrect route interface To: freebsd-net@freebsd.org References: <201803121804.w2CI4SPD079782@pdx.rh.CN85.dnsmgr.net> From: Grzegorz Junka Message-ID: <24596951-6fe8-b308-344d-636fecabe36b@gjunka.com> Date: Mon, 12 Mar 2018 19:56:14 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <201803121804.w2CI4SPD079782@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB-large X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 12 Mar 2018 19:56:23 -0000 On 12/03/2018 18:04, Rodney W. Grimes wrote: >> On 11/03/2018 20:57, Marek Zarychta wrote: >>> On Sun, Mar 11, 2018 at 05:46:52PM +0000, Grzegorz Junka wrote: >>>> On 11/03/2018 06:04, Eugene Grosbein wrote: >>>>> 11.03.2018 7:01, Grzegorz Junka wrote: >>>>> >>>>>>> Just do not assign addresses from same network 10.20.0.0/16 to different network interfaces >>>>>>> and you will be fine. Assign them all to right interface: >>>>>>> >>>>>>> ifconfig_em0="inet 10.20.2.14 netmask 255.255.0.0" >>>>>>> ifconfig_em0_alias0="inet 10.20.2.15/32" >>>>>>> ifconfig_igb0_alias0="inet 10.20.2.16/32" >>>>> Interfaces meant to be all equal, last line should be: >>>>> >>>>> ifconfig_em0_alias1="inet 10.20.2.16/32" >>>>> >>>> OK, I see. So this is in case I want many IPs assigned to the same >>>> interface. What if I want one IP assigned to multiple interfaces (i.e. >>>> so that the additional igb0-3 effectively work as a 4-port switch)? >>>> >>> Please consider bonding all NICs as one bridge(4) interface. Then >>> multiple IPs could be assigned to such interface. >>> >> Many thanks Eugene and Marek for your suggestions. I will now need to >> decide if I want to fragment the network into subnets or bridge the >> interfaces. >> GregJ > I believe some of the problem you are experincing is addressed > in this differential: > https://reviews.freebsd.org/D14547 > > Your original configuration was(is) valid, just not common, > and I have not seen this done in more than a decade, but it > seems as if rstone@ also has someone doing this "multiple IP's > into same subnet on seperate interfaces". > Thanks for the link. That's interesting. According to this post that configuration shouldn't be valid: https://forums.freenas.org/index.php?threads/multiple-network-interfaces-on-a-single-subnet.20204/ From owner-freebsd-net@freebsd.org Mon Mar 12 20:14:04 2018 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 8F55AF40AF7 for ; Mon, 12 Mar 2018 20:14:04 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1F0DA6ED4E for ; Mon, 12 Mar 2018 20:14:03 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w2CKDwSE080299; Mon, 12 Mar 2018 13:13:59 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w2CKDwSH080298; Mon, 12 Mar 2018 13:13:58 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201803122013.w2CKDwSH080298@pdx.rh.CN85.dnsmgr.net> Subject: Re: Incorrect route interface In-Reply-To: <24596951-6fe8-b308-344d-636fecabe36b@gjunka.com> To: Grzegorz Junka Date: Mon, 12 Mar 2018 13:13:58 -0700 (PDT) CC: freebsd-net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 12 Mar 2018 20:14:04 -0000 > On 12/03/2018 18:04, Rodney W. Grimes wrote: > >> On 11/03/2018 20:57, Marek Zarychta wrote: > >>> On Sun, Mar 11, 2018 at 05:46:52PM +0000, Grzegorz Junka wrote: > >>>> On 11/03/2018 06:04, Eugene Grosbein wrote: > >>>>> 11.03.2018 7:01, Grzegorz Junka wrote: > >>>>> > >>>>>>> Just do not assign addresses from same network 10.20.0.0/16 to different network interfaces > >>>>>>> and you will be fine. Assign them all to right interface: > >>>>>>> > >>>>>>> ifconfig_em0="inet 10.20.2.14 netmask 255.255.0.0" > >>>>>>> ifconfig_em0_alias0="inet 10.20.2.15/32" > >>>>>>> ifconfig_igb0_alias0="inet 10.20.2.16/32" > >>>>> Interfaces meant to be all equal, last line should be: > >>>>> > >>>>> ifconfig_em0_alias1="inet 10.20.2.16/32" > >>>>> > >>>> OK, I see. So this is in case I want many IPs assigned to the same > >>>> interface. What if I want one IP assigned to multiple interfaces (i.e. > >>>> so that the additional igb0-3 effectively work as a 4-port switch)? > >>>> > >>> Please consider bonding all NICs as one bridge(4) interface. Then > >>> multiple IPs could be assigned to such interface. > >>> > >> Many thanks Eugene and Marek for your suggestions. I will now need to > >> decide if I want to fragment the network into subnets or bridge the > >> interfaces. > >> GregJ > > I believe some of the problem you are experincing is addressed > > in this differential: > > https://reviews.freebsd.org/D14547 > > > > Your original configuration was(is) valid, just not common, > > and I have not seen this done in more than a decade, but it > > seems as if rstone@ also has someone doing this "multiple IP's > > into same subnet on seperate interfaces". > > > > Thanks for the link. That's interesting. According to this post that > configuration shouldn't be valid: > > https://forums.freenas.org/index.php?threads/multiple-network-interfaces-on-a-single-subnet.20204/ I'll disagree with the claims it is not valid. I shall however support the claims that it is non-standard, and non-trivial to understand just what it is that occurs in *BSD when you do this. I have seen this "claimed to be invalid" coniguration in use several times over the past 30 years. Where people seem to get this "invalid" from is expecting the traffic to be bound to an IP to go both in and OUT that interface is what is not invalid, but a wrong assertion. Traffic WELL come in that interface, as that is how ethernet macs, arp's an IP work. However it WELL go out the interface that is selected by the routing table. If you can seperate in your mind that this is how IN and OUT interfaces are decided the rest becomes simply mechanical. Simple typical *BSD installs end up with all traffic going out just one of the interfaces, but I can write route rules that change that artifact. And this is where the usage of this odd configuration sometimes comes about. With modern implimentations of *BSD that now have multiple fib's, and things like netgraph, and ipfw one can get very creative in what actually happens. And none of it is invalid, just often miss understood. I can actually casue that traffic bound to a specific IP to go in and out that specific interface. Ipfw's ability to cause a packet to use an alternate fib is how. ipfw add allow ip from ${ip_of_nicX} to any setfib ${fib_for_nicX} -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-net@freebsd.org Mon Mar 12 20:42:22 2018 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 4F2CFF46BFC for ; Mon, 12 Mar 2018 20:42:22 +0000 (UTC) (envelope-from list1@gjunka.com) Received: from msa1.earth.yoonka.com (yoonka.com [88.98.225.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "msa1.earth.yoonka.com", Issuer "msa1.earth.yoonka.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D0D6570D35 for ; Mon, 12 Mar 2018 20:42:21 +0000 (UTC) (envelope-from list1@gjunka.com) Received: from crayon2.yoonka.com (crayon2.yoonka.com [10.70.7.20]) (authenticated bits=0) by msa1.earth.yoonka.com (8.15.2/8.15.2) with ESMTPSA id w2CKgKYT077285 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 12 Mar 2018 20:42:20 GMT (envelope-from list1@gjunka.com) Subject: Re: Incorrect route interface To: freebsd-net@freebsd.org References: <201803122013.w2CKDwSH080298@pdx.rh.CN85.dnsmgr.net> From: Grzegorz Junka Message-ID: Date: Mon, 12 Mar 2018 20:42:20 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <201803122013.w2CKDwSH080298@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB-large X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 12 Mar 2018 20:42:22 -0000 On 12/03/2018 20:13, Rodney W. Grimes wrote: >> On 12/03/2018 18:04, Rodney W. Grimes wrote: >>>> On 11/03/2018 20:57, Marek Zarychta wrote: >>>>> On Sun, Mar 11, 2018 at 05:46:52PM +0000, Grzegorz Junka wrote: >>>>>> On 11/03/2018 06:04, Eugene Grosbein wrote: >>>>>>> 11.03.2018 7:01, Grzegorz Junka wrote: >>>>>>> >>>>>>>>> Just do not assign addresses from same network 10.20.0.0/16 to different network interfaces >>>>>>>>> and you will be fine. Assign them all to right interface: >>>>>>>>> >>>>>>>>> ifconfig_em0="inet 10.20.2.14 netmask 255.255.0.0" >>>>>>>>> ifconfig_em0_alias0="inet 10.20.2.15/32" >>>>>>>>> ifconfig_igb0_alias0="inet 10.20.2.16/32" >>>>>>> Interfaces meant to be all equal, last line should be: >>>>>>> >>>>>>> ifconfig_em0_alias1="inet 10.20.2.16/32" >>>>>>> >>>>>> OK, I see. So this is in case I want many IPs assigned to the same >>>>>> interface. What if I want one IP assigned to multiple interfaces (i.e. >>>>>> so that the additional igb0-3 effectively work as a 4-port switch)? >>>>>> >>>>> Please consider bonding all NICs as one bridge(4) interface. Then >>>>> multiple IPs could be assigned to such interface. >>>>> >>>> Many thanks Eugene and Marek for your suggestions. I will now need to >>>> decide if I want to fragment the network into subnets or bridge the >>>> interfaces. >>>> GregJ >>> I believe some of the problem you are experincing is addressed >>> in this differential: >>> https://reviews.freebsd.org/D14547 >>> >>> Your original configuration was(is) valid, just not common, >>> and I have not seen this done in more than a decade, but it >>> seems as if rstone@ also has someone doing this "multiple IP's >>> into same subnet on seperate interfaces". >>> >> Thanks for the link. That's interesting. According to this post that >> configuration shouldn't be valid: >> >> https://forums.freenas.org/index.php?threads/multiple-network-interfaces-on-a-single-subnet.20204/ > I'll disagree with the claims it is not valid. I shall however support > the claims that it is non-standard, and non-trivial to understand just > what it is that occurs in *BSD when you do this. I have seen this > "claimed to be invalid" coniguration in use several times over the > past 30 years. > > Where people seem to get this "invalid" from is expecting the traffic > to be bound to an IP to go both in and OUT that interface is what is > not invalid, but a wrong assertion. Traffic WELL come in that interface, > as that is how ethernet macs, arp's an IP work. However it WELL go > out the interface that is selected by the routing table. If you > can seperate in your mind that this is how IN and OUT interfaces > are decided the rest becomes simply mechanical. > > Simple typical *BSD installs end up with all traffic going out just > one of the interfaces, but I can write route rules that change that > artifact. And this is where the usage of this odd configuration > sometimes comes about. > > With modern implimentations of *BSD that now have multiple fib's, > and things like netgraph, and ipfw one can get very creative in > what actually happens. And none of it is invalid, just often > miss understood. I can actually casue that traffic bound to > a specific IP to go in and out that specific interface. Ipfw's > ability to cause a packet to use an alternate fib is how. > > ipfw add allow ip from ${ip_of_nicX} to any setfib ${fib_for_nicX} I don't know much about the network stack in FreeBSD but I would assume that I should be able to configure specific traffic (based on the destination subnet, so nothing fancy) to go out of a specific interface. Not only I wasn't able to do that, I was told my approach was wrong. So I think I agree with you. GregJ From owner-freebsd-net@freebsd.org Tue Mar 13 02:22:22 2018 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 111EEAFC6E2 for ; Tue, 13 Mar 2018 02:22:22 +0000 (UTC) (envelope-from chris@chrisbailey.io) Received: from mail-vk0-x244.google.com (mail-vk0-x244.google.com [IPv6:2607:f8b0:400c:c05::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A5DCB81A08 for ; Tue, 13 Mar 2018 02:22:21 +0000 (UTC) (envelope-from chris@chrisbailey.io) Received: by mail-vk0-x244.google.com with SMTP id s1so7568831vke.5 for ; Mon, 12 Mar 2018 19:22:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chrisbailey-io.20150623.gappssmtp.com; s=20150623; h=from:mime-version:date:message-id:subject:to:cc :content-transfer-encoding; bh=o1kEwOHIvw8aI89Gq4EIMz2nPmGg8/QrdbLv30zBSik=; b=d/zdQwh+rYPYE8ap4r5GtXgciPzmHXs07VjZ/laOpM3J0H3AQyLoGkhw7pE0uhkYSJ 6hZNzsHzWoSyBe6ojTyANQ9LcUySNqMMAYt2d2jCS6BlbSxh0ifdjonIgDtQcBfxJ1BF RQ8xXLjl8xZPndaiIiy9ogGWxKMSfUT7LqJkh60wecdznxd6VMS5EsAuFFyj1GZrbij2 pyppvSS3v5wO0OIZDJJq+Kc2GW+cPrxqVLHIlX0W3QAZRLVP69NVK4WL81kwVQ8Au3gz JtojJIR2mtbvlHD/rNZ6ETTcVw4I5+5AZA7XGOL/BEYcEv03uPu1WemQNIhtDYPrzN8Q Fktw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to:cc :content-transfer-encoding; bh=o1kEwOHIvw8aI89Gq4EIMz2nPmGg8/QrdbLv30zBSik=; b=JBQnGbdPfTGoVcnVgUiOiM8xwY2bg8iab4CIMSUh2A4pIEotuJWWMH/wB1p6LBzKAp jfoMIaZkmFXtO7hHozbF3h5UEYw+5secU0t4dKTDxkqCHL/rjQJHSft9t2TEtGyljofW YD0njwxTBInMqfSt96W6DI6sq7rBW7XMK5Id7ogKXYh1BQ8M8XeHOwcH7FaWgJvBpqJv dT3Su8+DOvypzu1SOtZdVw8SwVTdqTD044lpFUUPqSQ0lzHC9tAuwjUqDp4To8T6y+6W TFjqdYpAiK+cSQhwbEWBALH2Qirq/pXquCeLosHagmOplU91KgeiIi/FYRyE7HH1/sG8 Kb/A== X-Gm-Message-State: AElRT7Gb+MAmbPIvnNeXjXi43YT0htwMKok3wCAfxn89CzS/kxJuExdm PLXJnMRyTQl7VtgShWXBwd2UUiCpnmWKNBsGSY6jWQ== X-Google-Smtp-Source: AG47ELuxTmnhACba7Q8xthfTqMP72hIhH8m2w2w9mMgXn+qF3IIZoCi6PRXvBME//L+YT6D5mu46lKi14ELCqbnRjlI= X-Received: by 10.31.27.195 with SMTP id b186mr6492113vkb.14.1520907741133; Mon, 12 Mar 2018 19:22:21 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 12 Mar 2018 22:22:20 -0400 From: Christopher Bailey X-Mailer: Airmail (467) MIME-Version: 1.0 Date: Mon, 12 Mar 2018 22:22:20 -0400 Message-ID: Subject: [GSoC] Dual-stack ping command To: freebsd-hackers@freebsd.org Cc: freebsd-net@freebsd.org, lists@eitanadler.com, gavin@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 13 Mar 2018 02:22:22 -0000 Hello, I=E2=80=99m an undergraduate computer science student at the University of Alaska Fairbanks. I=E2=80=99m interested in unifying ping and ping6 into a single command, because it=E2=80=99s one of the suggested ideas on the wiki= , it=E2=80=99s something that=E2=80=99s mildly irritated me in the past, and = I believe I have the necessary skills to accomplish it. >From looking at the source code to the two existing commands, this project looks pretty straightforward. There could be some complications I=E2=80=99m missing though, so I=E2=80=99d be interested to h= ear from more experienced developers if there are. Also, apologies if I did anything wrong in sending this email. I=E2=80=99ve been following the FreeBSD lists for a while, but this is the first time I=E2=80=99ve sent a message myself, so I=E2=80=99m new to the experien= ce. Thanks, Chris Bailey From owner-freebsd-net@freebsd.org Tue Mar 13 03:40:39 2018 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 8C5E3B7C657; Tue, 13 Mar 2018 03:40:39 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:a:dead:bad:faff]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3F9C485F2D; Tue, 13 Mar 2018 03:40:38 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id w2D3eYFM015437; Tue, 13 Mar 2018 03:40:34 GMT (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id w2D3eXTa015436; Tue, 13 Mar 2018 03:40:33 GMT (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <201803130340.w2D3eXTa015436@donotpassgo.dyslexicfish.net> Date: Tue, 13 Mar 2018 03:40:33 +0000 Organization: Dyslexic Fish To: freebsd-hackers@freebsd.org, chris@chrisbailey.io Cc: lists@eitanadler.com, gavin@freebsd.org, freebsd-net@freebsd.org Subject: Re: [GSoC] Dual-stack ping command References: In-Reply-To: User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [104.207.135.49]); Tue, 13 Mar 2018 03:40:34 +0000 (GMT) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 13 Mar 2018 03:40:39 -0000 Christopher Bailey wrote: > I’m an undergraduate computer science student at the University of > Alaska Fairbanks. I’m interested in unifying ping and ping6 into a > single command, because it’s one of the suggested ideas on the wiki, > it’s something that’s mildly irritated me in the past, and I believe I > have the necessary skills to accomplish it. Hello! That's something that's bugged me too.. I'm going to be cheeky now, and ask if you've thought of doing traceroute/traceroute6 too? :-) Cheers, Jamie From owner-freebsd-net@freebsd.org Tue Mar 13 05:36:33 2018 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 CD487BF11EF for ; Tue, 13 Mar 2018 05:36:33 +0000 (UTC) (envelope-from chris@chrisbailey.io) Received: from mail-vk0-x244.google.com (mail-vk0-x244.google.com [IPv6:2607:f8b0:400c:c05::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5C09D69E59 for ; Tue, 13 Mar 2018 05:36:33 +0000 (UTC) (envelope-from chris@chrisbailey.io) Received: by mail-vk0-x244.google.com with SMTP id s1so7757238vke.5 for ; Mon, 12 Mar 2018 22:36:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chrisbailey-io.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=KSbF8dsVBOUk1Wna7cQ1TEEb3d1kUPglqBCgijqutJY=; b=EYfp9Boie+haUao3b0hBMOfYXE60JcnmnxVf8DBaUg9j9z94L+Sj09+X4ZuzN4zCrI +pM1e8zm5DGK9TbXGld75LYsjRbbmMg0Pt6q8KTsQT3kKYmXpGemurymPDrcPSzUKbtM mcRObFxM6pb2su3nGQP8dkbB0T7l5T/pvwfdgGc62PiT8tWe8f7oyYUjTQ0+WO+YCMDs tIFb1zN+0UoXiNBRmLRIUEB2dIzF6dSmwbn7N2MyI7jd9TNXuni9cazLZ7LmjnhYBYMx /zuFemcVSZem9WJizBcKdKR5Qd47dmawjQoNI3KgcqgMv38y4SoLDL0T/VAM72qNaJdB p4jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=KSbF8dsVBOUk1Wna7cQ1TEEb3d1kUPglqBCgijqutJY=; b=oGjluRXSLD87AmNPJnNf60Ox9jzwWhvaKtF26a4G6/6+05px+2OlwFQZbGh1RUx5bi obWFnsmFzTSDJMGeVkE89kGiWK0EbQCVchvSNEW8FkU0nBCuRZmpRCipiMCFYvHTxX4j uFu5UxC+EZgvgkGqDZ6vbohDS+xz/t1ecPKKPedZeUukiCIVh3W3yC7B158pRCvb8FE1 3OwOS6GEavqw1wqkPH2nhbaOrKGKu/s4BBK2FtOu47ZdcQn13/b3gHax4ObqtoMjb3dI KdmFtuZ1oaOKsjnX2xjhF9cYC+G6mk/BC3D4bPF6KytegTPxavyFw2IlB2KB5TCj/l6W 9COg== X-Gm-Message-State: AElRT7EVfy1WgPai0JRrHdO7/zXhLoME1fXoqUwgngm+YAGXCMsOEekJ sUHiRQU2e+QMPz8qAjmRbDpbNOOXExpYQS/j1zbFMewz X-Google-Smtp-Source: AG47ELvE1pLRHJJTbH0COjGz8JfFBeBq3KAX7eoi49lvkJyFJdwYw/eh162J/rp4M7fi4+QFSgxsxCzgkSGZxWTMzCk= X-Received: by 10.31.138.129 with SMTP id m123mr6790359vkd.13.1520919392758; Mon, 12 Mar 2018 22:36:32 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 13 Mar 2018 01:36:32 -0400 From: Christopher Bailey In-Reply-To: <201803130340.w2D3eXTa015436@donotpassgo.dyslexicfish.net> References: <201803130340.w2D3eXTa015436@donotpassgo.dyslexicfish.net> X-Mailer: Airmail (467) MIME-Version: 1.0 Date: Tue, 13 Mar 2018 01:36:32 -0400 Message-ID: Subject: Re: [GSoC] Dual-stack ping command To: freebsd-hackers@freebsd.org, Jamie Landeg-Jones Cc: freebsd-net@freebsd.org, lists@eitanadler.com, gavin@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 13 Mar 2018 05:36:34 -0000 Jamie Landeg-Jones (jamie@catflap.org) wrote: > That's something that's bugged me too.. I'm going to be cheeky now, and a= sk if you've > thought of doing traceroute/traceroute6 too? Yes, I have. It was listed on the project ideas wiki page as a separate project, but I wouldn=E2=80=99t mind combining the two (or working= on traceroute as a stretch goal). From owner-freebsd-net@freebsd.org Tue Mar 13 08:58:34 2018 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 480EFF2F709 for ; Tue, 13 Mar 2018 08:58:34 +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.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D86B9714C3 for ; Tue, 13 Mar 2018 08:58:33 +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 1050A1F719 for ; Tue, 13 Mar 2018 08:58:33 +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 w2D8wWZn031906 for ; Tue, 13 Mar 2018 08:58:32 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w2D8wWQh031905 for freebsd-net@FreeBSD.org; Tue, 13 Mar 2018 08:58:32 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: freebsd-net@FreeBSD.org Subject: [Bug 7556] [ppp] sl_compress_init() will fail if called anything else than -1 or >MAX_STATE Date: Tue, 13 Mar 2018 08:58:32 +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: 2.2.6-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: eugen@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Overcome By Events X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc bug_status resolution 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.25 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, 13 Mar 2018 08:58:34 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D7556 Eugene Grosbein changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |eugen@freebsd.org Status|In Progress |Closed Resolution|--- |Overcome By Events --- Comment #5 from Eugene Grosbein --- sl(4) was removed from FreeBSD before 8.0-RELEASE. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Tue Mar 13 10:18:05 2018 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 71141F3695F for ; Tue, 13 Mar 2018 10:18:05 +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.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 107F775044 for ; Tue, 13 Mar 2018 10:18:05 +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 3B3BD20241 for ; Tue, 13 Mar 2018 10:18:04 +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 w2DAI428022903 for ; Tue, 13 Mar 2018 10:18:04 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w2DAI4JA022901 for freebsd-net@FreeBSD.org; Tue, 13 Mar 2018 10:18:04 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: freebsd-net@FreeBSD.org Subject: [Bug 7556] [ppp] sl_compress_init() will fail if called anything else than -1 or >MAX_STATE Date: Tue, 13 Mar 2018 10:18:04 +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: 2.2.6-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ak@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status 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.25 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, 13 Mar 2018 10:18:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D7556 Alex Kozlov changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|Overcome By Events |--- Status|Closed |Open --- Comment #6 from Alex Kozlov --- This function is used in ng_vjc(4) and sppp(4). The issue described in this= bug is still exist. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Tue Mar 13 18:29:01 2018 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 48C1CF3FA76 for ; Tue, 13 Mar 2018 18:29:01 +0000 (UTC) (envelope-from justlikeef@gmail.com) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D302A6DA6D for ; Tue, 13 Mar 2018 18:29:00 +0000 (UTC) (envelope-from justlikeef@gmail.com) Received: by mail-it0-x233.google.com with SMTP id z7-v6so874547iti.1 for ; Tue, 13 Mar 2018 11:29:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=4aYn2uVrhNk1s02zl17jq+RX2I9mzXkgthlXy0l6heM=; b=G8Z+AFiGCFnhkVpIWtU9jRK09tqOk0LwY5q21iOZbCcVKrzWelxuMzA3ecbmHM44d1 zD7BQrunXYrRmMTP9VDaOYMfprtBWo+MqAu7831trWDRYCbwqHMT5+uwGEGhcelNRKQj NU9K97au5JmhXywd80bZU4iY11AdWYFjdzl3u9mx69/8Ykjzsk3RPx7YpUAptxzyAcXD 2v36UqB+pvoEBp1eVXBrwuuJjt7I0J8srkXUh49VU2ox9Tv7IsTKOeoCShrit6T2U7Pb oU/Gfb9Dt0Fl0niRwKFxf1XvinO4uwcfETBt2YMSDb0CtCZOdw7CdRZ61IG/IqN2OMeo 6Znw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=4aYn2uVrhNk1s02zl17jq+RX2I9mzXkgthlXy0l6heM=; b=lVvWxIZDejv+YmIqDuz2kiWHVIUv3Hg4z38eejtlWPLCQRZxR3c7v1lmz5rSZ5quXZ dpX/6+KgtDqjgQ7mCwLj7peZ11qJHNZ98lJjpP9dWr6dC+dlgQwLvGWf3NvASNF1lXTl TF2SIJhL6KBO0UaV05sSQDgmsp7RBHY487LekGT7TntgpgJan1HC6UpGOM4Q6vGnfeWl P+fD3tTnlPIVry27zDaOeJKZpSYL712x7o2BL3gHLYIHyVBdJFLu0q2tvNjR+/Qhazui dbTendtA0lr4xbH5wnVudVbsT5YchM7PbpYLOEKlNs8fj9xDOoSZzCQcuqOmTsXPZ+Ga dgMw== X-Gm-Message-State: AElRT7GnkIoltyDEVyA2mq8owIqSs3hy3NnhJMU3nUwO/vOJRVmcxtxL rHzLSxGiZ+7Fqq3lKRA4Xu9HeM4JAZiXm2ZbQ9DKfg== X-Google-Smtp-Source: AG47ELtP0GPaWgG5riSZFZRbUeEHOxKo+yZ2VVayJTcKWkk22u+b7sT4khtsupP0QfuM1nK0Irm67CBRtj1lfLw5qk4= X-Received: by 10.36.81.208 with SMTP id s199mr2224530ita.46.1520965739839; Tue, 13 Mar 2018 11:28:59 -0700 (PDT) MIME-Version: 1.0 From: Rob Hutton Date: Tue, 13 Mar 2018 18:28:49 +0000 Message-ID: Subject: Cisco shows LACP not enabled on 11.1U2, BCM 57810S-t, 2960X IOS 15.2 To: freebsd-net@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 13 Mar 2018 18:29:01 -0000 Trying to get to a LACP Trunk config working on FreeNAS, but I'm not sure if this is an upstream issue. First step is just LACP bundle in edge mode (no vlans) and bundle will not form. The FreeNAS side shows it as being active. The switch is reporting that LACP is not enabled on the individual ports. We have tried multiple versions of IOS from 15.0 to 15.2(6)E1. I have about 10 windows servers with the same NICs on the same switch that are negotiating LACP successfully as well as tagging vlans, so the hardware pieces seem to be OK. I have tried configuring from both the GUI and the CL with the same result. Cisco 2960X switch config: interface Port-channel10 switchport access vlan 1900 switchport mode access ! interface GigabitEthernet1/0/27 switchport access vlan 1900 switchport mode access channel-group 10 mode active ! interface GigabitEthernet1/0/28 switchport access vlan 1900 switchport mode access channel-group 10 mode active logs from switch: Mar 13 17:38:09.626: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/27, changed state to up Mar 13 17:38:09.665: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/28, changed state to up Mar 13 17:38:15.753: %EC-5-L3DONTBNDL2: Gi1/0/28 suspended: LACP currently not enabled on the remote port. Mar 13 17:38:16.005: %EC-5-L3DONTBNDL2: Gi1/0/27 suspended: LACP currently not enabled on the remote port. Switch#sh etherc summ Flags: D - down P - bundled in port-channel I - stand-alone s - suspended H - Hot-standby (LACP only) R - Layer3 S - Layer2 U - in use N - not in use, no aggregation f - failed to allocate aggregator M - not in use, minimum links not met m - not in use, port not aggregated due to minimum links not met u - unsuitable for bundling w - waiting to be aggregated d - default port A - formed by Auto LAG Number of channel-groups in use: 1 Number of aggregators: 1 Group Port-channel Protocol Ports ------+-------------+-----------+----------------------------------------------- 10 Po10(SD) LACP Gi1/0/27(w) Gi1/0/28(w) Switch#sh int gi1/0/27 GigabitEthernet1/0/27 is up, line protocol is down (notconnect) Switch#sh int gi1/0/28 GigabitEthernet1/0/28 is up, line protocol is down (notconnect) FreeNAS ifconfig bxe0: flags=8843 metric 0 mtu 1500 options=527bb ether 00:0e:1e:86:7c:70 hwaddr 00:0e:1e:86:7c:70 nd6 options=9 media: Ethernet autoselect (10Gbase-T ) status: active bxe1: flags=8843 metric 0 mtu 1500 options=527bb ether 00:0e:1e:86:7c:70 hwaddr 00:0e:1e:86:7c:72 nd6 options=9 media: Ethernet autoselect (10Gbase-T ) status: active lagg0: flags=8843 metric 0 mtu 1500 options=527bb ether 00:0e:1e:86:7c:70 nd6 options=9 media: Ethernet autoselect status: active groups: lagg laggproto lacp lagghash l2,l3,l4 laggport: bxe0 flags=0<> laggport: bxe1 flags=0<> Last edited: 12 minutes ago From owner-freebsd-net@freebsd.org Tue Mar 13 23:42:30 2018 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 1A352F2B389 for ; Tue, 13 Mar 2018 23:42:30 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B0A297CCFC for ; Tue, 13 Mar 2018 23:42:29 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by mail-qk0-x22a.google.com with SMTP id f25so1647615qkm.0 for ; Tue, 13 Mar 2018 16:42:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=msWN0izNNAJ2QaizLOn3hqeD7YwYJLBDTpN7rYZ+PFg=; b=CCi01XMFXHje8JN7e0X/YgRKs86ry6UyFPXhbmadC5IyRRlQE817vHSjxayJGfECpN nP/Il8ixbRYyEBFy639xgiyk83QXrWR4SIC4M3O12EgjHMksQhgeXmRNQ7NFKGPFTw7t 3ItxiZAvcvdM5RSe9R0gwOQkeGA0hD0/HL1cBhf34VzVDD33hlN021j2/VfAjNjoXEjp UX2VGRJVL1u9L+ndjr6sLJkI6Bwgu/uVVAsum46Xst/C+oiq7t0MwPqUbg3uRjsUARaj GxZoX7hsE+osorY0DkeVhXH/KTEZXRtPT6NIHtR4Lt00Nnobs+oAupk5YvGfqkiWcN9g D+8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=msWN0izNNAJ2QaizLOn3hqeD7YwYJLBDTpN7rYZ+PFg=; b=PzZRz07eiCF5huFzRFo1xsMr0hvkFEnWu6w1YrRtqBlCiXEKgvmheYWgsCW+s+h5am gq7lCqBwtsa3/xpk4+ZmaZcfokNzk6NZCwG8qlfG85+V+POIpw2cDDAzLOUDPfoB+rDy tmwMjPbKaNDuJIwBH1+BvOCqiHSx9XlEpPz6HxIil4HHP7D9JtDbVLCJt2zXsBnXt36w l5b72SaFOvVVK6JGCmgtjbtZUGUfFrmSvVy3bPXCERraYQslPRW4x5KrZZ7hbAw1S2sd rABqrQcUlMuMpJJEXo41sffy7QKxS8SjdeIfOtl7gY52D9PJKlX1buWubJN79cjBy6X5 zSig== X-Gm-Message-State: AElRT7HX0PMGucmocUmVtmk2OjkYNwFrtg1ZfFktefliOXqCS+Z9CurE YAbqxaFqNd7nbyx6QfTw7O1OEUGhN+rVX+OM+Pk= X-Google-Smtp-Source: AG47ELuPblGElR/yO1kqnIeI2dg2xu9fL2MfH20Dv2zh0VssP9sx4Ke9QVkzHP7AS+IppLUC3rxwaAe2C/+RmTKewBc= X-Received: by 10.55.186.193 with SMTP id k184mr3924686qkf.4.1520984549156; Tue, 13 Mar 2018 16:42:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.32.200 with HTTP; Tue, 13 Mar 2018 16:42:28 -0700 (PDT) In-Reply-To: References: From: Ryan Stone Date: Tue, 13 Mar 2018 19:42:28 -0400 Message-ID: Subject: Re: Cisco shows LACP not enabled on 11.1U2, BCM 57810S-t, 2960X IOS 15.2 To: Rob Hutton Cc: freebsd-net Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 13 Mar 2018 23:42:30 -0000 Unfortunately, this is a known issue with the bxe driver. I was under the impression that QLogic had committed a fix to -head, but I just checked and it hasn't seen any updates from QLogic in over a year, unfortunately. From owner-freebsd-net@freebsd.org Wed Mar 14 01:09:53 2018 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 F367AF32F32 for ; Wed, 14 Mar 2018 01:09:52 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6815C8005A for ; Wed, 14 Mar 2018 01:09:51 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w2E19c4G010050 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Mar 2018 02:09:39 +0100 (CET) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: justlikeef@gmail.com Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w2E19XRV046384 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 14 Mar 2018 08:09:33 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Cisco shows LACP not enabled on 11.1U2, BCM 57810S-t, 2960X IOS 15.2 To: Rob Hutton , freebsd-net@freebsd.org References: From: Eugene Grosbein Message-ID: <5AA87648.5060604@grosbein.net> Date: Wed, 14 Mar 2018 08:09:28 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS * 2.6 LOCAL_FROM From my domains X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 01:09:53 -0000 14.03.2018 1:28, Rob Hutton wrote: > Trying to get to a LACP Trunk config working on FreeNAS, but I'm not sure > if this is an upstream issue. First step is just LACP bundle in edge mode > (no vlans) and bundle will not form. The FreeNAS side shows it as being > active. The switch is reporting that LACP is not enabled on the individual > ports. We have tried multiple versions of IOS from 15.0 to 15.2(6)E1. I > have about 10 windows servers with the same NICs on the same switch that > are negotiating LACP successfully as well as tagging vlans, so the hardware > pieces seem to be OK. I have tried configuring from both the GUI and the > CL with the same result. > > Cisco 2960X > > switch config: > interface Port-channel10 > switchport access vlan 1900 > switchport mode access > ! > interface GigabitEthernet1/0/27 > switchport access vlan 1900 > switchport mode access > channel-group 10 mode active > ! > interface GigabitEthernet1/0/28 > switchport access vlan 1900 > switchport mode access > channel-group 10 mode active > > logs from switch: > Mar 13 17:38:09.626: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/27, > changed state to up > Mar 13 17:38:09.665: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/28, > changed state to up > Mar 13 17:38:15.753: %EC-5-L3DONTBNDL2: Gi1/0/28 suspended: LACP currently > not enabled on the remote port. > Mar 13 17:38:16.005: %EC-5-L3DONTBNDL2: Gi1/0/27 suspended: LACP currently > not enabled on the remote port. > > Switch#sh etherc summ > Flags: D - down P - bundled in port-channel > I - stand-alone s - suspended > H - Hot-standby (LACP only) > R - Layer3 S - Layer2 > U - in use N - not in use, no aggregation > f - failed to allocate aggregator > > M - not in use, minimum links not met > m - not in use, port not aggregated due to minimum links not met > u - unsuitable for bundling > w - waiting to be aggregated > d - default port > > A - formed by Auto LAG > > > Number of channel-groups in use: 1 > Number of aggregators: 1 > > Group Port-channel Protocol Ports > ------+-------------+-----------+----------------------------------------------- > 10 Po10(SD) LACP Gi1/0/27(w) Gi1/0/28(w) > > Switch#sh int gi1/0/27 > GigabitEthernet1/0/27 is up, line protocol is down (notconnect) > > Switch#sh int gi1/0/28 > GigabitEthernet1/0/28 is up, line protocol is down (notconnect) > > > FreeNAS > ifconfig > > bxe0: flags=8843 metric 0 mtu 1500 > options=527bb M,TSO4,TSO6,LRO,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO> > ether 00:0e:1e:86:7c:70 > hwaddr 00:0e:1e:86:7c:70 > nd6 options=9 > media: Ethernet autoselect (10Gbase-T ) > status: active > > bxe1: flags=8843 metric 0 mtu 1500 > options=527bb M,TSO4,TSO6,LRO,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO> > ether 00:0e:1e:86:7c:70 > hwaddr 00:0e:1e:86:7c:72 > nd6 options=9 > media: Ethernet autoselect (10Gbase-T ) > status: active > > lagg0: flags=8843 metric 0 mtu 1500 > options=527bb M,TSO4,TSO6,LRO,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO> > ether 00:0e:1e:86:7c:70 > nd6 options=9 > media: Ethernet autoselect > status: active > groups: lagg > laggproto lacp lagghash l2,l3,l4 > laggport: bxe0 flags=0<> > laggport: bxe1 flags=0<> > > Last edited: 12 minutes ago See also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213606 In short: bxe(4) driver fails to setup hardware so it would receive incoming multicast LACP frames unless switched to promisc. mode. For now, replace the NIC with one from distinct manufacturer (Intel etc.) From owner-freebsd-net@freebsd.org Wed Mar 14 14:52:15 2018 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 1968BF56C57 for ; Wed, 14 Mar 2018 14:52:14 +0000 (UTC) (envelope-from justlikeef@gmail.com) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 571D784471 for ; Wed, 14 Mar 2018 14:52:14 +0000 (UTC) (envelope-from justlikeef@gmail.com) Received: by mail-io0-x22f.google.com with SMTP id u84so4682157iod.9 for ; Wed, 14 Mar 2018 07:52:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Dkg/GCYxnrBoARGlqSLJ4+pj1wJvrQNwLoqQO5Minfw=; b=crUZxI+KjHdgGAzMBWZM5AB3nC2e1V1M3NzlNhdQ4hhFc3e5tIrNe7qsEuStkJ1FjQ O6KaE66O5SHZ4bX/YMwL9lisNyFE1TvlSxuofdTG/3HD5KdQZEtmc09k+aP9Jb+pka8S 4sIaoiyZdH+ZRKOBQdMBlQ7ano3GAKhay5XhLE+zMbWR8J6j6F54HTo15gLpjDZ4zpUv N/j4o4xwqV3XE/6/ovsU/f4tjZ44Jc1YYh22/r49Sohu4u0fj5AruhpAHv+00wd+5Ozx C2mTogpKYZugVkAyHw3b31sqtn2a3/xXY7/bNcHhvtKRXrJZPxReQGt9gpFBBmOx3W5S PFKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Dkg/GCYxnrBoARGlqSLJ4+pj1wJvrQNwLoqQO5Minfw=; b=U4edD/n3ZPUdpsLsyzhBPlFcbNUh9gusIg8WUPN73WIAC0V+lYGVldZkgos668errS rT7uU7I42vY5Nx157/oQ/cvypy9SooZpgnx5JepCWrvK/t2YBB32ZorRGcFS07vFtGbJ OBeDcZnx+a+0en9CqzXzikrKLlL2dkuXwGbh4jQ+nIDp3o7ROFMYJzz3yPoXwNS3FAc5 b/l4f+39g5VmTXSUEVqbJ4CiU0OXygGvRpJHywp9T8+gsZMiC6x0nOj7tvsnL/bR6BXJ 0E1Dt8D9x87RWklD7zUgei6t1bCCDZXFDQDL6gejNATZaiJX1Ul6Hhhrc0Gi6UZdUoso qqKA== X-Gm-Message-State: AElRT7FmudczJe7rtnSWDWTWnHKTOi6rsMrlu2IBLhFIaRUa0VZ8Cktl BMyWPtyDMigykIfCLfbMyrvpLldMJwlQxThPb28= X-Google-Smtp-Source: AG47ELvRdD5kn6ZVptEc+dRI4+6bXPeVM3ACWgAVSosiv5GjvISxBhB8G4+c+znWmKhtHOverjlysC+sjUsG2GY/GbY= X-Received: by 10.107.147.198 with SMTP id v189mr4687289iod.282.1521039133664; Wed, 14 Mar 2018 07:52:13 -0700 (PDT) MIME-Version: 1.0 References: <5AA87648.5060604@grosbein.net> In-Reply-To: <5AA87648.5060604@grosbein.net> From: Rob Hutton Date: Wed, 14 Mar 2018 14:52:03 +0000 Message-ID: Subject: Re: Cisco shows LACP not enabled on 11.1U2, BCM 57810S-t, 2960X IOS 15.2 To: Eugene Grosbein , "rysto32@gmail.com" Cc: freebsd-net@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 14:52:15 -0000 Thanks for your help on this! On Tue, Mar 13, 2018 at 9:09 PM Eugene Grosbein wrote: > 14.03.2018 1:28, Rob Hutton wrote: > > > Trying to get to a LACP Trunk config working on FreeNAS, but I'm not sure > > if this is an upstream issue. First step is just LACP bundle in edge > mode > > (no vlans) and bundle will not form. The FreeNAS side shows it as being > > active. The switch is reporting that LACP is not enabled on the > individual > > ports. We have tried multiple versions of IOS from 15.0 to 15.2(6)E1. I > > have about 10 windows servers with the same NICs on the same switch that > > are negotiating LACP successfully as well as tagging vlans, so the > hardware > > pieces seem to be OK. I have tried configuring from both the GUI and the > > CL with the same result. > > > > Cisco 2960X > > > > switch config: > > interface Port-channel10 > > switchport access vlan 1900 > > switchport mode access > > ! > > interface GigabitEthernet1/0/27 > > switchport access vlan 1900 > > switchport mode access > > channel-group 10 mode active > > ! > > interface GigabitEthernet1/0/28 > > switchport access vlan 1900 > > switchport mode access > > channel-group 10 mode active > > > > logs from switch: > > Mar 13 17:38:09.626: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/27, > > changed state to up > > Mar 13 17:38:09.665: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/28, > > changed state to up > > Mar 13 17:38:15.753: %EC-5-L3DONTBNDL2: Gi1/0/28 suspended: LACP > currently > > not enabled on the remote port. > > Mar 13 17:38:16.005: %EC-5-L3DONTBNDL2: Gi1/0/27 suspended: LACP > currently > > not enabled on the remote port. > > > > Switch#sh etherc summ > > Flags: D - down P - bundled in port-channel > > I - stand-alone s - suspended > > H - Hot-standby (LACP only) > > R - Layer3 S - Layer2 > > U - in use N - not in use, no aggregation > > f - failed to allocate aggregator > > > > M - not in use, minimum links not met > > m - not in use, port not aggregated due to minimum links not met > > u - unsuitable for bundling > > w - waiting to be aggregated > > d - default port > > > > A - formed by Auto LAG > > > > > > Number of channel-groups in use: 1 > > Number of aggregators: 1 > > > > Group Port-channel Protocol Ports > > > ------+-------------+-----------+----------------------------------------------- > > 10 Po10(SD) LACP Gi1/0/27(w) Gi1/0/28(w) > > > > Switch#sh int gi1/0/27 > > GigabitEthernet1/0/27 is up, line protocol is down (notconnect) > > > > Switch#sh int gi1/0/28 > > GigabitEthernet1/0/28 is up, line protocol is down (notconnect) > > > > > > FreeNAS > > ifconfig > > > > bxe0: flags=8843 metric 0 mtu > 1500 > > > options=527bb > M,TSO4,TSO6,LRO,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO> > > ether 00:0e:1e:86:7c:70 > > hwaddr 00:0e:1e:86:7c:70 > > nd6 options=9 > > media: Ethernet autoselect (10Gbase-T ) > > status: active > > > > bxe1: flags=8843 metric 0 mtu > 1500 > > > options=527bb > M,TSO4,TSO6,LRO,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO> > > ether 00:0e:1e:86:7c:70 > > hwaddr 00:0e:1e:86:7c:72 > > nd6 options=9 > > media: Ethernet autoselect (10Gbase-T ) > > status: active > > > > lagg0: flags=8843 metric 0 mtu > 1500 > > > options=527bb > M,TSO4,TSO6,LRO,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO> > > ether 00:0e:1e:86:7c:70 > > nd6 options=9 > > media: Ethernet autoselect > > status: active > > groups: lagg > > laggproto lacp lagghash l2,l3,l4 > > laggport: bxe0 flags=0<> > > laggport: bxe1 flags=0<> > > > > Last edited: 12 minutes ago > > See also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213606 > > In short: bxe(4) driver fails to setup hardware so it would receive > incoming > multicast LACP frames unless switched to promisc. mode. > > For now, replace the NIC with one from distinct manufacturer (Intel etc.) > > From owner-freebsd-net@freebsd.org Wed Mar 14 20:09:16 2018 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 B15A7F41EA4 for ; Wed, 14 Mar 2018 20:09:16 +0000 (UTC) (envelope-from aspam@cox.net) Received: from fed1rmfepi205.cox.net (fed1rmfepi205.cox.net [68.230.241.150]) by mx1.freebsd.org (Postfix) with ESMTP id 2CDE17494D for ; Wed, 14 Mar 2018 20:09:15 +0000 (UTC) (envelope-from aspam@cox.net) Received: from eastrmimpo109.cox.net ([68.230.241.222]) by eastrmfepo203.cox.net (InterMail vM.8.01.05.28 201-2260-151-171-20160122) with ESMTP id <20180314195909.LGIE31819.eastrmfepo203.cox.net@eastrmimpo109.cox.net> for ; Wed, 14 Mar 2018 15:59:09 -0400 Received: from thunder.sweets ([68.100.138.62]) by eastrmimpo109.cox.net with cox id Mvz91x00P1LxgH801vz9zs; Wed, 14 Mar 2018 15:59:09 -0400 X-Authority-Analysis: v=2.2 cv=G8FsK5s5 c=1 sm=1 tr=0 a=3mkzfl4ircflX6G+lDqBYw==:117 a=3mkzfl4ircflX6G+lDqBYw==:17 a=8nJEP1OIZ-IA:10 a=x7bEGLp0ZPQA:10 a=v2DPQv5-lfwA:10 a=e9ASbk4n0QUA:10 a=Kzv8BM1vUIEX2JVxurgA:9 a=wPNLvfGTeEIA:10 X-CM-Score: 0.00 Authentication-Results: cox.net; auth=pass (LOGIN) smtp.auth=jbuehler@cox.net Received: from [10.10.10.15] (thunder.sweets [10.10.10.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thunder.sweets (Postfix) with ESMTP id DD98F119B5 for ; Wed, 14 Mar 2018 15:59:08 -0400 (EDT) Message-ID: <5AA97F0B.8060808@cox.net> Date: Wed, 14 Mar 2018 15:59:07 -0400 From: Joe Buehler User-Agent: Thunderbird 1.5.0.12 (X11/20120201) MIME-Version: 1.0 To: "freebsd-net@freebsd.org" Subject: netmap memory config query Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 20:09:16 -0000 When I increase the ixgbevf rx ring size from 1024 to 4096 I get this: [ 5526.651780] 851.135009 [ 931] netmap_obj_malloc netmap_ring request size 65792 too large [ 5526.652779] 851.136008 [1802] netmap_mem2_rings_create Cannot allocate RX_ring What netmap module parameters do I need to tweak to get past this? I am using LINUX should it matter. Joe Buehler From owner-freebsd-net@freebsd.org Wed Mar 14 20:41:08 2018 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 51DBBF43F76 for ; Wed, 14 Mar 2018 20:41:08 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E25C075B13 for ; Wed, 14 Mar 2018 20:41:07 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mail-qt0-x22a.google.com with SMTP id z14so4982700qti.2 for ; Wed, 14 Mar 2018 13:41:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AwaNRWn3DhtRDkPiXrQ7WVR63b8H39PlK0thPqFFxmM=; b=j2t/SykK7MAwPmlNUd/z0P62bLxLnQO2g1fQBs5hPrvYWKAo3bQszEEQSxGhN1ayJw Ul4783kj31fjKhN6Q8WUhjGw3EfhSbr53GUGA7q8eYAZVnwpO1ITGFSPniknOIYzJ+PL s0cZPDPo9ibHslMUQ4efGlk03HvwLTkankzzbsSV+5Rktl5XWsWAbH/tdnudxsf9TjvX L+ss/6LsryblGY1hTpaxj2TD5E4zfiEu9UnDs8bgHO5vnZ7eCVLSeBEeYxt9OyVbfYxe qU3EBSotsFWO7DHUkaanE9Rv+bj5UJQx8GoF4uKgzLy6qtOEz7k4gVfl7cS02ab3HeLd Wpyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AwaNRWn3DhtRDkPiXrQ7WVR63b8H39PlK0thPqFFxmM=; b=DhNJa+Y2ij1mx+HGuuq7C7lyhn2ov3lkRyr/+WPbfgWurmNUZoPtt5jx8YMMgro9Kp IDJskrTUHs5XtVWhy8OANOpHXCZhnzpUwXYf21hi72SUXZlz/LojcQFKOE/W4B/sJNK5 /zPtv+jR4s44Q8E89CLJxRwgNZFLrBTfWkVzqGEDZ7cWK0XeLW6mKdTZqCmTsdXjNDfN q0XQi3GQdJLkjhTa7tNLQwoLIYaeCd3NEOIcPnRINqhzpCfZeeNn7eYoGqhj5CY1NvA9 pSe+MJehsxv8AUdKP0gzWJIQxPDhOmYjdJ92YnWGj+aaHvP/uC61dbQM1YWPOnFHxyvG Z3qg== X-Gm-Message-State: AElRT7Hta1PagQvCiHiKfG1yMg1kuw+B2LzQTuWtqcEsaOA5MQ8D5O2Z H3f8a8VFP0sCuqG5RqCAouYb+FE5QZapaHb3NqM= X-Google-Smtp-Source: AG47ELtOBilvP1cZYF0ESGBvEBFNw0+dLrNz4owejsVYdZX2ikd512ebHPWZRXO8rnmp212P2I3JKKGBPxdVw0sRrr0= X-Received: by 10.200.41.18 with SMTP id y18mr9459406qty.181.1521060067302; Wed, 14 Mar 2018 13:41:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.195.204 with HTTP; Wed, 14 Mar 2018 13:41:06 -0700 (PDT) In-Reply-To: <5AA97F0B.8060808@cox.net> References: <5AA97F0B.8060808@cox.net> From: Vincenzo Maffione Date: Wed, 14 Mar 2018 21:41:06 +0100 Message-ID: Subject: Re: netmap memory config query To: Joe Buehler Cc: "freebsd-net@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 20:41:08 -0000 Hi, The parameter to increase is "ring_size". FreeBSD or Linux does not matter (except for how you modify the parameter, i.e. sysctl on FreeBSD and sysfs in Linux). Cheers, Vincenzo 2018-03-14 20:59 GMT+01:00 Joe Buehler : > When I increase the ixgbevf rx ring size from 1024 to 4096 I get this: > > [ 5526.651780] 851.135009 [ 931] netmap_obj_malloc netmap_ring > request size 65792 too large > [ 5526.652779] 851.136008 [1802] netmap_mem2_rings_create Cannot allocate > RX_ring > > What netmap module parameters do I need to tweak to get past this? > > I am using LINUX should it matter. > > Joe Buehler > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- Vincenzo Maffione From owner-freebsd-net@freebsd.org Wed Mar 14 21:07:52 2018 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 78B8EF49A84 for ; Wed, 14 Mar 2018 21:07:52 +0000 (UTC) (envelope-from lisa.williams@digitaldatatechno.com) Received: from IND01-MA1-obe.outbound.protection.outlook.com (mail-ma1ind01hn0223.outbound.protection.outlook.com [104.47.100.223]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT TLS CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8663E76F0B for ; Wed, 14 Mar 2018 21:07:51 +0000 (UTC) (envelope-from lisa.williams@digitaldatatechno.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT2140629.onmicrosoft.com; s=selector1-digitaldatatechno-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bNwn+0F9YF+Sk36ikhwsPD7PTYt8o0lBNc/sHAaLK0U=; b=geY8tkmHs/p01I8pgysXKyE6+/kNnCBPGSNhrYmzkjTybpasD5TSmBsV2aXUt3E2cP3SiOjE7BkWt06Huh3FApJjWVwPFV7Tvxg5Pw69Ku8E9xb1a3iquWJZOHSKoyG2AVgW6AVxbeE+dfrfDtc49fg0ca7oz/3UVgReKeQeJH8= Received: from MA1PR01MB0714.INDPRD01.PROD.OUTLOOK.COM (10.174.57.143) by MA1PR01MB0889.INDPRD01.PROD.OUTLOOK.COM (10.174.59.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.588.14; Wed, 14 Mar 2018 21:07:47 +0000 Received: from MA1PR01MB0714.INDPRD01.PROD.OUTLOOK.COM ([fe80::c833:f3a6:9ece:e842]) by MA1PR01MB0714.INDPRD01.PROD.OUTLOOK.COM ([fe80::c833:f3a6:9ece:e842%17]) with mapi id 15.20.0588.013; Wed, 14 Mar 2018 21:07:47 +0000 From: Lisa Williams To: "freebsd-net@freebsd.org" Subject: Re: Cloud Technology and BigData end users DB Thread-Topic: Re: Cloud Technology and BigData end users DB Thread-Index: AdO718ao8G85W3nRQQGxIOJFKyOPPQ== Importance: high X-Priority: 1 Date: Wed, 14 Mar 2018 21:06:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=lisa.williams@digitaldatatechno.com; x-originating-ip: [183.82.22.5] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MA1PR01MB0889; 7:34I6wCtFG1bGtAK7jPcD+4ubkPo3MnwiqSU/tUCo9esSkCHnkHVqpWKkWSdKjFoaKhKlnU2kyOVFNg7gOTUlR9KBHhYp6izDYrZktFhjB/mSTzV1up5nWx6QY60qNaAIVxduFFV8BmuYhu5ZyZ+lF7k90zbYYBVDRo9icE0Bd9WXpK4FSboPQ/d+7yn9cLGxJVHxswqsApq0FQIYIvX8SZOec7tWLilraQeClGFXwPRa9Bgvo5sCgx1EyYoIFp0T x-ms-office365-filtering-correlation-id: 988d10de-6712-4f29-bed7-08d589efa396 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(5600026)(4604075)(3008032)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603328)(7153060)(7193020); SRVR:MA1PR01MB0889; x-ms-traffictypediagnostic: MA1PR01MB0889: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231221)(944501244)(52105095)(93006095)(93001095)(6041310)(2016111802025)(20161123564045)(20161123562045)(20161123560045)(20161123558120)(6072148)(6043046)(201708071742011); SRVR:MA1PR01MB0889; BCL:0; PCL:0; RULEID:; SRVR:MA1PR01MB0889; x-forefront-prvs: 0611A21987 x-forefront-antispam-report: SFV:SPM; SFS:(10009020)(376002)(39380400002)(366004)(346002)(39840400004)(396003)(189003)(199004)(316002)(9406002)(2906002)(2501003)(8676002)(9476002)(106356001)(5640700003)(99286004)(9326002)(25786009)(3280700002)(2351001)(6506007)(26005)(33656002)(97736004)(9686003)(102836004)(5630700001)(6246003)(478600001)(626008)(86362001)(54896002)(6116002)(55016002)(790700001)(7696005)(186003)(6916009)(6436002)(6306002)(66066001)(3660700001)(3846002)(5660300001)(53936002)(7736002)(5250100002)(8936002)(229853002)(74316002)(105586002)(81166006)(2900100001)(81156014)(68736007)(14454004)(81686011)(48640200003); DIR:OUT; SFP:1501; SCL:5; SRVR:MA1PR01MB0889; H:MA1PR01MB0714.INDPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: digitaldatatechno.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: jxAdmXec9FJPfJK/ofXwFQqcGyi8h9EFkjkoyx0fJTOJy39A0KDC8IpQL8RdmV7PINANYXRcRJ3+ebbJSVIVRZKO8AsmBLRXskNEEhtLFLUrZtG8hCuSTiuYNLsJi3rQ3vrX61uJ/C9EZnoTVfGvdut3GqXJMY4AzJHNXkmnLvo0br6flnBAHV0KJqhO/te19hYj4FLJj4R7EUfRTx8ghfvYm7ycuMAGY+FpKhJs259XjlDU0xKHL+IOwEH0w3yQnZHZjikiYkb7HKBOdVZm54fkPnWhm4Ldaxg0WjwanGT9W/pejiSMgzK0rf8sKew4EhlgNnC6JRIX/qrIgfwOUvKybjh2itCxcoqoTJq9kLeWvPMAyuFvDPkh3P7KE93zdhwwciDvX+Z7cjm17I680FvnxcszGktbuEuLr4Y7h/07kVMElAvaaZAhvJ2kcZ1a7G3ILCozuFj5RzQHl/69mo29SLErfa5DK8prsJXDJO7eGAEj+6FpTLQb1UblAmeS spamdiagnosticoutput: 1:22 MIME-Version: 1.0 X-OriginatorOrg: digitaldatatechno.com X-MS-Exchange-CrossTenant-Network-Message-Id: 988d10de-6712-4f29-bed7-08d589efa396 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2018 21:06:50.2407 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 16374125-200f-4766-a98f-7e476a02eea1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MA1PR01MB0889 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 21:07:52 -0000 Hi, Would you be interested in acquiring list of Cloud Technology and BigData e= nd users list. We have: 10million IT contacts 7million Marketing contacts 5Million Engineering Contacts And many more titles from all the industries. Information for each contact: Name, title, Email, Phone number, Company Nam= e, Company URL, Company physical address, SIC Code, Industry, Company Size = (Revenue and Employee). Please provide: Target Technology, Target Job Titles, Target Geography and = Target Industry and I will get back to you with the counts and cost for the= same. Please revert if you have any question, I am happy to help you. Regards, Lisa Williams Marketing Executive From owner-freebsd-net@freebsd.org Thu Mar 15 20:05:55 2018 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 AAAB8F4EEFC for ; Thu, 15 Mar 2018 20:05:55 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by mx1.freebsd.org (Postfix) with ESMTP id 32C56759BA for ; Thu, 15 Mar 2018 20:05:53 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id 39086E6047 for ; Thu, 15 Mar 2018 21:05:52 +0100 (CET) Date: Thu, 15 Mar 2018 21:05:52 +0100 (CET) Message-Id: <20180315.210552.74686746.sthaug@nethelp.no> To: freebsd-net@FreeBSD.org Subject: Does FreeBSD do proactive ARP refresh? From: sthaug@nethelp.no X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 15 Mar 2018 20:05:55 -0000 I have a reproducible problem on 11.1-STABLE where, during a longterm iperf3 session, some packets are lost every time ARP is refreshed (every net.link.ether.inet.max_age seconds). Checking with tcpdump, I can indeed see that the packet loss is happening as the hosts are doing ARP request/reply. How to reproduce the problem: - pkg install iperf3-3.5 - Decrease ARP aging timer to 120 (net.link.ether.inet.max_age=120) - Run receiver as "iperf3 -s -i10" - Run sender as "iperf3 -c -u -b4m -l100 -i10 -t3600" - Observe packet loss of a few packets every 120 seconds on the receiver I've tried this on several different hosts, with different Ethernet cards. Same result. Also, reducing net.link.ether.inet.max_age isn't *needed* for the problem to occur - it simply makes the problem visible faster. The loss interval is clearly correlated with the net.link.ether.inet.max_age value. Extract of typical iperf3 output on the receiver end showing loss: [ 5] 1810.00-1820.00 sec 4.77 MBytes 4.00 Mbits/sec 0.036 ms 0/50000 (0%) [ 5] 1820.00-1830.00 sec 4.77 MBytes 4.00 Mbits/sec 0.007 ms 0/50000 (0%) [ 5] 1830.00-1840.00 sec 4.77 MBytes 4.00 Mbits/sec 0.006 ms 4/50000 (0.008%) [ 5] 1840.00-1850.00 sec 4.77 MBytes 4.00 Mbits/sec 0.029 ms 0/49997 (0%) [ 5] 1850.00-1860.00 sec 4.77 MBytes 4.00 Mbits/sec 0.007 ms 0/49998 (0%) [ 5] 1860.00-1870.00 sec 4.77 MBytes 4.00 Mbits/sec 0.006 ms 0/50000 (0%) [ 5] 1870.00-1880.00 sec 4.77 MBytes 4.00 Mbits/sec 0.030 ms 0/50000 (0%) [ 5] 1880.00-1890.00 sec 4.77 MBytes 4.00 Mbits/sec 0.007 ms 0/50000 (0%) [ 5] 1890.00-1900.00 sec 4.77 MBytes 4.00 Mbits/sec 0.007 ms 0/50000 (0%) [ 5] 1900.00-1910.00 sec 4.77 MBytes 4.00 Mbits/sec 0.006 ms 0/49999 (0%) [ 5] 1910.00-1920.00 sec 4.77 MBytes 4.00 Mbits/sec 0.006 ms 0/49996 (0%) [ 5] 1920.00-1930.00 sec 4.77 MBytes 4.00 Mbits/sec 0.007 ms 0/50000 (0%) [ 5] 1930.00-1940.00 sec 4.77 MBytes 4.00 Mbits/sec 0.013 ms 0/50000 (0%) [ 5] 1940.00-1950.00 sec 4.77 MBytes 4.00 Mbits/sec 0.007 ms 0/50000 (0%) [ 5] 1950.00-1960.00 sec 4.77 MBytes 4.00 Mbits/sec 0.006 ms 4/50000 (0.008%) [ 5] 1960.00-1970.00 sec 4.77 MBytes 4.00 Mbits/sec 0.007 ms 0/49999 (0%) [ 5] 1970.00-1980.00 sec 4.77 MBytes 4.00 Mbits/sec 0.007 ms 0/49996 (0%) I've tried to read some of the code in /sys/netinet/if_ether.c, and I get impression that FreeBSD is supposed to (proactively) refresh an ARP entry *before* it expires - specifically the arptimer() routine which has the comment * Expiration time is approaching. * Let's try to refresh entry if it is still * in use. However, I'm uncertain of whether my reading here is correct. Can somebody tell me if FreeBSD is supposed to proactively refresh an ARP entry? My idea here is that as long as you have a valid ARP entry, it should be possible to refresh the ARP entry *and* continue sending traffic (with no packet drops) - i.e. the goal is to completely avoid the drops I'm currently seeing on every ARP refresh. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-net@freebsd.org Fri Mar 16 09:38:25 2018 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 12E90F5F554 for ; Fri, 16 Mar 2018 09:38:25 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from forward101o.mail.yandex.net (forward101o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::601]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8586C75688 for ; Fri, 16 Mar 2018 09:38:23 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from mxback3o.mail.yandex.net (mxback3o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::1d]) by forward101o.mail.yandex.net (Yandex) with ESMTP id 085521345590; Fri, 16 Mar 2018 12:38:21 +0300 (MSK) Received: from localhost (localhost [::1]) by mxback3o.mail.yandex.net (nwsmtp/Yandex) with ESMTP id F2tUv9j5wY-cIbuLvdX; Fri, 16 Mar 2018 12:38:19 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfw.ru; s=mail; t=1521193099; bh=dQPpcvZPMGTZI2L935SoLHzxtCRy9UDcabwN35IZjv8=; h=From:To:In-Reply-To:References:Subject:Message-Id:Date; b=R9/NqJpocq1iSlcK0bCABBzEpdMYtbIX7xIQb8cFEPtO5faFqADvgUsvHrpb8qaYJ h8T0TQfPNyK3QGhLWOz5mfqBBoqumjWhzbpW9VDxZtpc8euqlL/A75vhB8L1pmhOm7 rwid9fEq4xpBW7kw9Ycr1ZSCTuL1IA10XV5EJlEQ= Authentication-Results: mxback3o.mail.yandex.net; dkim=pass header.i=@ipfw.ru Received: by web19g.yandex.ru with HTTP; Fri, 16 Mar 2018 12:38:18 +0300 From: Alexander V. Chernikov To: "sthaug@nethelp.no" , "freebsd-net@FreeBSD.org" In-Reply-To: <20180315.210552.74686746.sthaug@nethelp.no> References: <20180315.210552.74686746.sthaug@nethelp.no> Subject: Re: Does FreeBSD do proactive ARP refresh? MIME-Version: 1.0 Message-Id: <8530131521193098@web19g.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Fri, 16 Mar 2018 12:38:18 +0300 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2018 09:38:25 -0000 15.03.2018, 23:08, "sthaug@nethelp.no" : > I have a reproducible problem on 11.1-STABLE where, during a longterm > iperf3 session, some packets are lost every time ARP is refreshed (every > net.link.ether.inet.max_age seconds). Checking with tcpdump, I can > indeed see that the packet loss is happening as the hosts are doing > ARP request/reply. I'll take a look. Indeed, the intended behaviour is to proactively refresh the record. Is the situation the same with forwarding and locally-originated traffic? With local TCP socket inpcb route caching might come into play. > > How to reproduce the problem: > > - pkg install iperf3-3.5 > - Decrease ARP aging timer to 120 (net.link.ether.inet.max_age=120) > - Run receiver as "iperf3 -s -i10" > - Run sender as "iperf3 -c -u -b4m -l100 -i10 -t3600" > - Observe packet loss of a few packets every 120 seconds on the > receiver > > I've tried this on several different hosts, with different Ethernet cards. > Same result. Also, reducing net.link.ether.inet.max_age isn't *needed* for > the problem to occur - it simply makes the problem visible faster. The > loss interval is clearly correlated with the net.link.ether.inet.max_age > value. > > Extract of typical iperf3 output on the receiver end showing loss: > > [ 5] 1810.00-1820.00 sec 4.77 MBytes 4.00 Mbits/sec 0.036 ms 0/50000 (0%) > [ 5] 1820.00-1830.00 sec 4.77 MBytes 4.00 Mbits/sec 0.007 ms 0/50000 (0%) > [ 5] 1830.00-1840.00 sec 4.77 MBytes 4.00 Mbits/sec 0.006 ms 4/50000 (0.008%) > [ 5] 1840.00-1850.00 sec 4.77 MBytes 4.00 Mbits/sec 0.029 ms 0/49997 (0%) > [ 5] 1850.00-1860.00 sec 4.77 MBytes 4.00 Mbits/sec 0.007 ms 0/49998 (0%) > [ 5] 1860.00-1870.00 sec 4.77 MBytes 4.00 Mbits/sec 0.006 ms 0/50000 (0%) > [ 5] 1870.00-1880.00 sec 4.77 MBytes 4.00 Mbits/sec 0.030 ms 0/50000 (0%) > [ 5] 1880.00-1890.00 sec 4.77 MBytes 4.00 Mbits/sec 0.007 ms 0/50000 (0%) > [ 5] 1890.00-1900.00 sec 4.77 MBytes 4.00 Mbits/sec 0.007 ms 0/50000 (0%) > [ 5] 1900.00-1910.00 sec 4.77 MBytes 4.00 Mbits/sec 0.006 ms 0/49999 (0%) > [ 5] 1910.00-1920.00 sec 4.77 MBytes 4.00 Mbits/sec 0.006 ms 0/49996 (0%) > [ 5] 1920.00-1930.00 sec 4.77 MBytes 4.00 Mbits/sec 0.007 ms 0/50000 (0%) > [ 5] 1930.00-1940.00 sec 4.77 MBytes 4.00 Mbits/sec 0.013 ms 0/50000 (0%) > [ 5] 1940.00-1950.00 sec 4.77 MBytes 4.00 Mbits/sec 0.007 ms 0/50000 (0%) > [ 5] 1950.00-1960.00 sec 4.77 MBytes 4.00 Mbits/sec 0.006 ms 4/50000 (0.008%) > [ 5] 1960.00-1970.00 sec 4.77 MBytes 4.00 Mbits/sec 0.007 ms 0/49999 (0%) > [ 5] 1970.00-1980.00 sec 4.77 MBytes 4.00 Mbits/sec 0.007 ms 0/49996 (0%) > > I've tried to read some of the code in /sys/netinet/if_ether.c, and I > get impression that FreeBSD is supposed to (proactively) refresh an ARP > entry *before* it expires - specifically the arptimer() routine which > has the comment > >                  * Expiration time is approaching. >                  * Let's try to refresh entry if it is still >                  * in use. > > However, I'm uncertain of whether my reading here is correct. Can > somebody tell me if FreeBSD is supposed to proactively refresh an ARP > entry? > > My idea here is that as long as you have a valid ARP entry, it should > be possible to refresh the ARP entry *and* continue sending traffic > (with no packet drops) - i.e. the goal is to completely avoid the > drops I'm currently seeing on every ARP refresh. > > Steinar Haug, Nethelp consulting, sthaug@nethelp.no > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@freebsd.org Fri Mar 16 09:56:10 2018 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 F03B2F607EC for ; Fri, 16 Mar 2018 09:56:09 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward103p.mail.yandex.net (forward103p.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 753CF76378 for ; Fri, 16 Mar 2018 09:56:09 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from mxback10o.mail.yandex.net (mxback10o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::24]) by forward103p.mail.yandex.net (Yandex) with ESMTP id B345E2180DAE; Fri, 16 Mar 2018 12:55:04 +0300 (MSK) Received: from smtp1p.mail.yandex.net (smtp1p.mail.yandex.net [2a02:6b8:0:1472:2741:0:8b6:6]) by mxback10o.mail.yandex.net (nwsmtp/Yandex) with ESMTP id AGwXg5X8Lv-t49aKWjF; Fri, 16 Mar 2018 12:55:04 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1521194104; bh=9gM2dbtcaSIvcTbPzrYLdRXHdDoYqLmSZtGuT2FrQE4=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=T7DayfynrYV8TNc7DA3b3lp/ntDj7g4sHrlFz8tCK5ufhJ92whAsya8U+hpVY6YKX gqtujlW5JQJuVwTAMXMNfXI8I60vUqLFvPCS4j5kRdcSqaoaqFlPnJVbxt3a7Uz4MM tYgON+b5B74AzMhdmDcjGHWSFQht25IU+FC60TS8= Received: by smtp1p.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id k3tBKixUSB-t34ehJED; Fri, 16 Mar 2018 12:55:03 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1521194103; bh=9gM2dbtcaSIvcTbPzrYLdRXHdDoYqLmSZtGuT2FrQE4=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=sxBbTyqh5zgVMLQIfMG3veAkMoYRFXy6cAcDIYcBQ2FWCMjM9SvBa8/WpoWZKc5XV P/VgCYJi9lhy9LmVmP/cs3bsH0EC6PTQJm99Kwd5HgvI0gSo3JM0Ud+iYbJ97b2y8Q 2XaJp5JB0z0MiBhXMWEDsgGDTOhI3WQQem4GjeZI= Authentication-Results: smtp1p.mail.yandex.net; dkim=pass header.i=@yandex.ru Subject: Re: Does FreeBSD do proactive ARP refresh? To: sthaug@nethelp.no, freebsd-net@FreeBSD.org References: <20180315.210552.74686746.sthaug@nethelp.no> From: "Andrey V. Elsukov" Openpgp: id=E6591E1B41DA1516F0C9BC0001C5EA0410C8A17A Message-ID: <1fba4f44-9308-19b8-973a-645869ff95ee@yandex.ru> Date: Fri, 16 Mar 2018 12:53:46 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180315.210552.74686746.sthaug@nethelp.no> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ThzTrVEqB0T5UJuMTfiOQrRT0OgQBp1GP" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2018 09:56:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ThzTrVEqB0T5UJuMTfiOQrRT0OgQBp1GP Content-Type: multipart/mixed; boundary="e0tiiI74MhjWTSdRZYggp3ZKHmPHYEnHX"; protected-headers="v1" From: "Andrey V. Elsukov" To: sthaug@nethelp.no, freebsd-net@FreeBSD.org Message-ID: <1fba4f44-9308-19b8-973a-645869ff95ee@yandex.ru> Subject: Re: Does FreeBSD do proactive ARP refresh? References: <20180315.210552.74686746.sthaug@nethelp.no> In-Reply-To: <20180315.210552.74686746.sthaug@nethelp.no> --e0tiiI74MhjWTSdRZYggp3ZKHmPHYEnHX Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 15.03.2018 23:05, sthaug@nethelp.no wrote: > My idea here is that as long as you have a valid ARP entry, it should > be possible to refresh the ARP entry *and* continue sending traffic > (with no packet drops) - i.e. the goal is to completely avoid the > drops I'm currently seeing on every ARP refresh. >=20 Can you show your config and stats after the test? # sysctl net.link.ether # netstat -sp arp # netstat -sp ip # netstat -sp udp --=20 WBR, Andrey V. Elsukov --e0tiiI74MhjWTSdRZYggp3ZKHmPHYEnHX-- --ThzTrVEqB0T5UJuMTfiOQrRT0OgQBp1GP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEzBAEBCAAdFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAlqrlCoACgkQAcXqBBDI oXqnKAgAkXm7MqMKjgrSdGKeOstnPZz4ew6F9z6pQyLME9ezSHCP945/oxEoV+yK QC0I7Sl2kLAAD8xFtiPgGhz6lDtqRIQCavBS6DEA6xrzTNkafzF6nNm8mPhvrNHl n/KaSmlPnF0AKCbbmNkisnMpy2PSDflJ8dVh1ovkjawiYOZ/NkpXnwC4IISlBQ5q xIx2Lp+GqsCc1jtqTqzpnRGROTt/FrAPRbAxuY8fY82Ih0ggZlTaCHT7s+k6JhZh +93mY7AhRUhDUjha36t1jCmpd0TJLaRCoo2GKuL0ByzkZC4NM4ZZ2NhL4UkH6I7J 4u1wkmCzeqRVLSYDfQBCFeMuLAlXiw== =Xr05 -----END PGP SIGNATURE----- --ThzTrVEqB0T5UJuMTfiOQrRT0OgQBp1GP-- From owner-freebsd-net@freebsd.org Fri Mar 16 10:01:03 2018 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 12B9FF60E80 for ; Fri, 16 Mar 2018 10:01:03 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9A9987686C for ; Fri, 16 Mar 2018 10:01:02 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id 63CA3E6047; Fri, 16 Mar 2018 11:00:54 +0100 (CET) Date: Fri, 16 Mar 2018 11:00:54 +0100 (CET) Message-Id: <20180316.110054.74682026.sthaug@nethelp.no> To: melifaro@ipfw.ru Cc: freebsd-net@freebsd.org Subject: Re: Does FreeBSD do proactive ARP refresh? From: sthaug@nethelp.no In-Reply-To: <8530131521193098@web19g.yandex.ru> References: <20180315.210552.74686746.sthaug@nethelp.no> <8530131521193098@web19g.yandex.ru> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2018 10:01:03 -0000 > > I have a reproducible problem on 11.1-STABLE where, during a longterm > > iperf3 session, some packets are lost every time ARP is refreshed (every > > net.link.ether.inet.max_age seconds). Checking with tcpdump, I can > > indeed see that the packet loss is happening as the hosts are doing > > ARP request/reply. > I'll take a look. Indeed, the intended behaviour is to proactively refresh the record. > Is the situation the same with forwarding and locally-originated traffic? > With local TCP socket inpcb route caching might come into play. My testing is with locally-originated UDP traffic (iperf3 -u). Haven't tested what happens if the box is forwarding the traffic - however, I believe TCP socket inpcb route caching should not be relevant for the UDP traffic? (But there is also a TCP transaction between the iperf3 sender and the iperf3 receiver at the *start* of the iperf3 session.) In any case, I will also test what happens if the box is forwarding the traffic. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-net@freebsd.org Fri Mar 16 10:58:21 2018 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 9E29ECDA for ; Fri, 16 Mar 2018 10:58:21 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with ESMTP id 176B978878 for ; Fri, 16 Mar 2018 10:58:20 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id A70B0E6047; Fri, 16 Mar 2018 11:58:18 +0100 (CET) Date: Fri, 16 Mar 2018 11:58:18 +0100 (CET) Message-Id: <20180316.115818.41694679.sthaug@nethelp.no> To: "Andrey V. Elsukov" Cc: freebsd-net@FreeBSD.org Subject: Re: Does FreeBSD do proactive ARP refresh?,Re: Does FreeBSD do proactive ARP refresh? From: sthaug@nethelp.no In-Reply-To: <1fba4f44-9308-19b8-973a-645869ff95ee@yandex.ru> References: <20180315.210552.74686746.sthaug@nethelp.no> <20180315.210552.74686746.sthaug@nethelp.no> <1fba4f44-9308-19b8-973a-645869ff95ee@yandex.ru> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2018 10:58:21 -0000 > Can you show your config and stats after the test? > # sysctl net.link.ether > # netstat -sp arp > # netstat -sp ip > # netstat -sp udp OK, below is the output from these commands, run on the iperf3 sender, from before and after one test run. I ran the test for 370 seconds, and had 3 periods of packet loss, spaced 120 seconds apart. Steinar Haug, Nethelp consulting, sthaug@nethelp.no ---------------------------------------------------------------------- # Before sthaug@pondus% sysctl net.link.ether net.link.ether.inet.allow_multicast: 0 net.link.ether.inet.log_arp_permanent_modify: 1 net.link.ether.inet.log_arp_movements: 1 net.link.ether.inet.log_arp_wrong_iface: 1 net.link.ether.inet.garp_rexmit_count: 0 net.link.ether.inet.max_log_per_second: 1 net.link.ether.inet.maxhold: 1 net.link.ether.inet.wait: 20 net.link.ether.inet.proxyall: 0 net.link.ether.inet.maxtries: 5 net.link.ether.inet.max_age: 120 net.link.ether.ipfw: 0 sthaug@pondus% netstat -sp arp arp: 67 ARP requests sent 812 ARP replies sent 54274 ARP requests received 63 ARP replies received 54337 ARP packets received 339 total packets dropped due to no ARP entry 63 ARP entrys timed out 0 Duplicate IPs seen sthaug@pondus% netstat -sp ip ip: 52434 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size < data length 0 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 packets reassembled ok 51339 packets for this host 0 packets for unknown/unsupported protocol 33 packets forwarded (18 packets fast forwarded) 1 packet not forwardable 0 packets received for unknown multicast group 0 redirects sent 109204414 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 23551 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 tunneling packets that can't find gif 0 datagrams with bad address in header sthaug@pondus% netstat -sp udp udp: 2750 datagrams received 0 with incomplete header 0 with bad data length field 0 with bad checksum 440 with no checksum 2138 dropped due to no socket 0 broadcast/multicast datagrams undelivered 0 dropped due to full socket buffers 0 not for hashed pcb 612 delivered 109160018 datagrams output 0 times multicast source filter matched # After sthaug@pondus% sysctl net.link.ether net.link.ether.inet.allow_multicast: 0 net.link.ether.inet.log_arp_permanent_modify: 1 net.link.ether.inet.log_arp_movements: 1 net.link.ether.inet.log_arp_wrong_iface: 1 net.link.ether.inet.garp_rexmit_count: 0 net.link.ether.inet.max_log_per_second: 1 net.link.ether.inet.maxhold: 1 net.link.ether.inet.wait: 20 net.link.ether.inet.proxyall: 0 net.link.ether.inet.maxtries: 5 net.link.ether.inet.max_age: 120 net.link.ether.ipfw: 0 sthaug@pondus% netstat -sp arp arp: 70 ARP requests sent 813 ARP replies sent 54297 ARP requests received 66 ARP replies received 54363 ARP packets received 351 total packets dropped due to no ARP entry 66 ARP entrys timed out 0 Duplicate IPs seen sthaug@pondus% netstat -sp ip ip: 52527 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size < data length 0 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 packets reassembled ok 51432 packets for this host 0 packets for unknown/unsupported protocol 33 packets forwarded (18 packets fast forwarded) 1 packet not forwardable 0 packets received for unknown multicast group 0 redirects sent 111059559 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 23551 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 tunneling packets that can't find gif 0 datagrams with bad address in header sthaug@pondus% netstat -sp udp udp: 2751 datagrams received 0 with incomplete header 0 with bad data length field 0 with bad checksum 440 with no checksum 2138 dropped due to no socket 0 broadcast/multicast datagrams undelivered 0 dropped due to full socket buffers 0 not for hashed pcb 613 delivered 111015060 datagrams output 0 times multicast source filter matched From owner-freebsd-net@freebsd.org Fri Mar 16 11:27:22 2018 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 EAA0CF3759C for ; Fri, 16 Mar 2018 11:27:21 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with ESMTP id 7AD6A79D2A for ; Fri, 16 Mar 2018 11:27:21 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id 2D5B0E6047; Fri, 16 Mar 2018 12:27:20 +0100 (CET) Date: Fri, 16 Mar 2018 12:27:20 +0100 (CET) Message-Id: <20180316.122720.71152047.sthaug@nethelp.no> To: Alexander V. Chernikov Cc: freebsd-net@freebsd.org Subject: Re: Does FreeBSD do proactive ARP refresh? From: sthaug@nethelp.no In-Reply-To: <20180316.110054.74682026.sthaug@nethelp.no> References: <20180315.210552.74686746.sthaug@nethelp.no> <8530131521193098@web19g.yandex.ru> <20180316.110054.74682026.sthaug@nethelp.no> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2018 11:27:22 -0000 > > > I have a reproducible problem on 11.1-STABLE where, during a longterm > > > iperf3 session, some packets are lost every time ARP is refreshed (every > > > net.link.ether.inet.max_age seconds). Checking with tcpdump, I can > > > indeed see that the packet loss is happening as the hosts are doing > > > ARP request/reply. > > I'll take a look. Indeed, the intended behaviour is to proactively refresh the record. > > Is the situation the same with forwarding and locally-originated traffic? > > With local TCP socket inpcb route caching might come into play. > > My testing is with locally-originated UDP traffic (iperf3 -u). Haven't > tested what happens if the box is forwarding the traffic - however, I > believe TCP socket inpcb route caching should not be relevant for the > UDP traffic? (But there is also a TCP transaction between the iperf3 > sender and the iperf3 receiver at the *start* of the iperf3 session.) > > In any case, I will also test what happens if the box is forwarding > the traffic. And thank you for that suggestion! The packet loss during ARP refresh (of the destination address connected to the output interface) does *not* happen when the box is forwarding! It only happens with locally generated traffic. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-net@freebsd.org Fri Mar 16 11:47:50 2018 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 57920F41DB7 for ; Fri, 16 Mar 2018 11:47:50 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by mx1.freebsd.org (Postfix) with ESMTP id DD1BF7A87E for ; Fri, 16 Mar 2018 11:47:49 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id 0BC2BE6047; Fri, 16 Mar 2018 12:47:49 +0100 (CET) Date: Fri, 16 Mar 2018 12:47:48 +0100 (CET) Message-Id: <20180316.124748.104098359.sthaug@nethelp.no> To: Alexander V. Chernikov Cc: freebsd-net@freebsd.org Subject: Re: Does FreeBSD do proactive ARP refresh? From: sthaug@nethelp.no In-Reply-To: <20180316.122720.71152047.sthaug@nethelp.no> References: <8530131521193098@web19g.yandex.ru> <20180316.110054.74682026.sthaug@nethelp.no> <20180316.122720.71152047.sthaug@nethelp.no> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2018 11:47:50 -0000 > > > > I have a reproducible problem on 11.1-STABLE where, during a longterm > > > > iperf3 session, some packets are lost every time ARP is refreshed (every > > > > net.link.ether.inet.max_age seconds). Checking with tcpdump, I can > > > > indeed see that the packet loss is happening as the hosts are doing > > > > ARP request/reply. > > > I'll take a look. Indeed, the intended behaviour is to proactively refresh the record. > > > Is the situation the same with forwarding and locally-originated traffic? > > > With local TCP socket inpcb route caching might come into play. > > > > My testing is with locally-originated UDP traffic (iperf3 -u). Haven't > > tested what happens if the box is forwarding the traffic - however, I > > believe TCP socket inpcb route caching should not be relevant for the > > UDP traffic? (But there is also a TCP transaction between the iperf3 > > sender and the iperf3 receiver at the *start* of the iperf3 session.) > > > > In any case, I will also test what happens if the box is forwarding > > the traffic. > > And thank you for that suggestion! The packet loss during ARP refresh > (of the destination address connected to the output interface) does > *not* happen when the box is forwarding! It only happens with locally > generated traffic. Checking once per second with "arp -n " I can see the following behavior with net.link.ether.inet.max_age=120: - Locally generated traffic: The ARP entry is refreshed after net.link.ether.inet.max_age seconds - which presumably means it actually expires first. And there is some packet loss. - Transit traffic (the box is forwarding): The ARP entry is refreshed 5 seconds *before* net.link.ether.inet.max_age has passed, and there is no packet loss. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-net@freebsd.org Fri Mar 16 12:47:19 2018 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 D6D0AF4C067 for ; Fri, 16 Mar 2018 12:47:18 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward102p.mail.yandex.net (forward102p.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 591017CC78 for ; Fri, 16 Mar 2018 12:47:18 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from mxback4o.mail.yandex.net (mxback4o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::1e]) by forward102p.mail.yandex.net (Yandex) with ESMTP id 2E0D24306E2E; Fri, 16 Mar 2018 15:46:09 +0300 (MSK) Received: from smtp4o.mail.yandex.net (smtp4o.mail.yandex.net [2a02:6b8:0:1a2d::28]) by mxback4o.mail.yandex.net (nwsmtp/Yandex) with ESMTP id hcY6cJUElj-k8Ga0JL9; Fri, 16 Mar 2018 15:46:09 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1521204369; bh=uFK+AUVedCO5QnH8k3P7LpOzQkq//RttyW1w0iDW77Q=; h=Subject:To:Cc:References:From:Message-ID:Date:In-Reply-To; b=otD7cmXeFJgdEUFbR0tqnCm74Yfckd7aE7wgKtq5o6DU/EdeIE3IatnKrwWI1XVdb ImtGR+4u8B4gu5LgHzydQyJo2/ijBTtVVdaC4081Q0q5zPw2xHDXYbehmIa+NHYHgl S7tN1TmDJ5IGv3jSaRDCsVVSwxvLAcHxkT2HZxfY= Received: by smtp4o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id Pavw99EYXc-k7Ra49k6; Fri, 16 Mar 2018 15:46:08 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1521204368; bh=uFK+AUVedCO5QnH8k3P7LpOzQkq//RttyW1w0iDW77Q=; h=Subject:To:Cc:References:From:Message-ID:Date:In-Reply-To; b=np4yD3zx/Im5KmB6SgDvoQcHz/gAtuE6i/extC64ut1z7K6oRY18heiP7zG0q4m53 Rb9n60fj9JGqH68qs88Y9lTsah9wxMn4Xe4yOGD0SpKsyVBTA+Eth4SL2ctGp3T5hE YTnOCFlleQQ5CMPU2ajPfC9/5/WUA+fOUIUMTOi0= Authentication-Results: smtp4o.mail.yandex.net; dkim=pass header.i=@yandex.ru Subject: Re: Does FreeBSD do proactive ARP refresh? To: sthaug@nethelp.no, "Alexander V. Chernikov" Cc: freebsd-net@freebsd.org References: <8530131521193098@web19g.yandex.ru> <20180316.110054.74682026.sthaug@nethelp.no> <20180316.122720.71152047.sthaug@nethelp.no> <20180316.124748.104098359.sthaug@nethelp.no> From: "Andrey V. Elsukov" Openpgp: id=E6591E1B41DA1516F0C9BC0001C5EA0410C8A17A Message-ID: <21eca372-6fc0-6c86-4ca8-a398bfa37d92@yandex.ru> Date: Fri, 16 Mar 2018 15:44:49 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180316.124748.104098359.sthaug@nethelp.no> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3ZUx1sX8ShmEqqE7Fpvpn6TYQFyAFT7A6" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2018 12:47:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3ZUx1sX8ShmEqqE7Fpvpn6TYQFyAFT7A6 Content-Type: multipart/mixed; boundary="mrt3brP2owfeyIyP8LR7RrorVMGhNXcmM"; protected-headers="v1" From: "Andrey V. Elsukov" To: sthaug@nethelp.no, "Alexander V. Chernikov" Cc: freebsd-net@freebsd.org Message-ID: <21eca372-6fc0-6c86-4ca8-a398bfa37d92@yandex.ru> Subject: Re: Does FreeBSD do proactive ARP refresh? References: <8530131521193098@web19g.yandex.ru> <20180316.110054.74682026.sthaug@nethelp.no> <20180316.122720.71152047.sthaug@nethelp.no> <20180316.124748.104098359.sthaug@nethelp.no> In-Reply-To: <20180316.124748.104098359.sthaug@nethelp.no> --mrt3brP2owfeyIyP8LR7RrorVMGhNXcmM Content-Type: multipart/mixed; boundary="------------FB3221505C4F71A7F48BA677" Content-Language: en-US This is a multi-part message in MIME format. --------------FB3221505C4F71A7F48BA677 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 16.03.2018 14:47, sthaug@nethelp.no wrote: >> And thank you for that suggestion! The packet loss during ARP refresh >> (of the destination address connected to the output interface) does >> *not* happen when the box is forwarding! It only happens with locally >> generated traffic. >=20 > Checking once per second with "arp -n " I can see the > following behavior with net.link.ether.inet.max_age=3D120: >=20 > - Locally generated traffic: The ARP entry is refreshed after > net.link.ether.inet.max_age seconds - which presumably means it > actually expires first. And there is some packet loss. >=20 > - Transit traffic (the box is forwarding): The ARP entry is refreshed > 5 seconds *before* net.link.ether.inet.max_age has passed, and there > is no packet loss. Can you test this patch? I did not tested it, but I think it should fix this issue. --=20 WBR, Andrey V. Elsukov --------------FB3221505C4F71A7F48BA677 Content-Type: text/x-patch; name="ethersubr.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="ethersubr.diff" Index: sys/net/if_ethersubr.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/net/if_ethersubr.c (revision 330791) +++ sys/net/if_ethersubr.c (working copy) @@ -317,6 +317,17 @@ ether_output(struct ifnet *ifp, struct mbuf *m, phdr =3D lle->r_linkdata; hlen =3D lle->r_hdrlen; pflags =3D lle->r_flags; + /* + * XXX: Check if we have feedback request + * from arptimer()/nd6_llinfo_timer(). + */ + if ((pflags & RLLE_VALID) && + lle->r_skip_req !=3D 0) { + LLE_REQ_LOCK(lle); + /* Notify that entry was used */ + lle->r_skip_req =3D 0; + LLE_REQ_UNLOCK(lle); + } } } } --------------FB3221505C4F71A7F48BA677-- --mrt3brP2owfeyIyP8LR7RrorVMGhNXcmM-- --3ZUx1sX8ShmEqqE7Fpvpn6TYQFyAFT7A6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEzBAEBCAAdFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAlqrvEEACgkQAcXqBBDI oXo7tgf9EMttcnWuuQgjd9VieQBdI9Bw3VQfmzXNB+3nu28jTm5r/OGgoCWQ3OzE bYlOuP4CVXFraSlFE0eR+/krd/qpYHMnI14eTl05VZpJctEHVG4tBEfiEsXfdv8G h4RHbMXliA+sYen9dLD1kWTMF2P7yGpAlKyrpl4b07IFAEvkJM7VI6LnLKRV/EFk BI7BZWpWRecfN5fZlZFrFUTJlu7ClzM3M16D056x20fFI8gLvBvrCTM+eTiUZk7z Nw913kR7QDoydFqd9gDATIAaq/UTCe/8EtEVg/5MEp3lOmTnQxiK1zXnI74Sr1k5 NgicksaL3qepWHPoj/ERM0vy71OhpA== =NT4S -----END PGP SIGNATURE----- --3ZUx1sX8ShmEqqE7Fpvpn6TYQFyAFT7A6-- From owner-freebsd-net@freebsd.org Fri Mar 16 13:47:38 2018 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 EBCE6F50842 for ; Fri, 16 Mar 2018 13:47:37 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by mx1.freebsd.org (Postfix) with ESMTP id 604F67F594 for ; Fri, 16 Mar 2018 13:47:36 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id 93349E6047; Fri, 16 Mar 2018 14:47:34 +0100 (CET) Date: Fri, 16 Mar 2018 14:47:34 +0100 (CET) Message-Id: <20180316.144734.78772139.sthaug@nethelp.no> To: "Andrey V. Elsukov" Cc: melifaro@ipfw.ru, freebsd-net@freebsd.org Subject: Re: Does FreeBSD do proactive ARP refresh?,Re: Does FreeBSD do proactive ARP refresh? From: sthaug@nethelp.no In-Reply-To: <21eca372-6fc0-6c86-4ca8-a398bfa37d92@yandex.ru> References: <20180316.122720.71152047.sthaug@nethelp.no> <20180316.124748.104098359.sthaug@nethelp.no> <21eca372-6fc0-6c86-4ca8-a398bfa37d92@yandex.ru> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2018 13:47:38 -0000 > >> And thank you for that suggestion! The packet loss during ARP refresh > >> (of the destination address connected to the output interface) does > >> *not* happen when the box is forwarding! It only happens with locally > >> generated traffic. > > > > Checking once per second with "arp -n " I can see the > > following behavior with net.link.ether.inet.max_age=120: > > > > - Locally generated traffic: The ARP entry is refreshed after > > net.link.ether.inet.max_age seconds - which presumably means it > > actually expires first. And there is some packet loss. > > > > - Transit traffic (the box is forwarding): The ARP entry is refreshed > > 5 seconds *before* net.link.ether.inet.max_age has passed, and there > > is no packet loss. > > Can you test this patch? I did not tested it, but I think it should fix > this issue. Looks like this is a patch against HEAD. I don't have any boxes running HEAD, but I can get one installed and test the patch this weekend (unless you want to produce a patch against 11.1-STABLE). I tried the patch manually applied on 11.1-STABLE, but got lots of errors during kernel compilation (see the end of this message). Steinar Haug, Nethelp consulting, sthaug@nethelp.no ---------------------------------------------------------------------- cc -c -O2 -pipe -fno-strict-aliasing -g -nostdinc -I. -I../../.. -I../../../contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.if_ethersubr.o -MTif_ethersubr.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -Wno-error-address-of-packed-member -mno-aes -mno-avx -std=iso9899:1999 -Werror ../../../net/if_ethersubr.c ../../../net/if_ethersubr.c:288:18: error: unused variable 't' [-Werror,-Wunused-variable] struct pf_mtag *t; ^ ../../../net/if_ethersubr.c:286:7: error: unused variable 'linkhdr' [-Werror,-Wunused-variable] char linkhdr[ETHER_HDR_LEN], *phdr; ^ ../../../net/if_ethersubr.c:285:6: error: unused variable 'error' [-Werror,-Wunused-variable] int error = 0; ^ ../../../net/if_ethersubr.c:289:6: error: unused variable 'loop_copy' [-Werror,-Wunused-variable] int loop_copy = 1; ^ ../../../net/if_ethersubr.c:287:23: error: unused variable 'eh' [-Werror,-Wunused-variable] struct ether_header *eh; ^ ../../../net/if_ethersubr.c:293:18: error: unused variable 'rt0' [-Werror,-Wunused-variable] struct rtentry *rt0 = NULL; ^ ../../../net/if_ethersubr.c:335:4: error: control reaches end of non-void function [-Werror,-Wreturn-type] } ^ ../../../net/if_ethersubr.c:336:3: error: extraneous closing brace ('}') } ^ ../../../net/if_ethersubr.c:337:3: error: type specifier missing, defaults to 'int' [-Werror,-Wimplicit-int] rt0 = ro->ro_rt; ^ ../../../net/if_ethersubr.c:337:9: error: use of undeclared identifier 'ro' rt0 = ro->ro_rt; ^ ../../../net/if_ethersubr.c:338:2: error: extraneous closing brace ('}') } ^ ../../../net/if_ethersubr.c:341:2: error: type specifier missing, defaults to 'int' [-Werror,-Wimplicit-int] error = mac_ifnet_check_transmit(ifp, m); ^ ../../../net/if_ethersubr.c:341:35: error: use of undeclared identifier 'ifp' error = mac_ifnet_check_transmit(ifp, m); ^ ../../../net/if_ethersubr.c:341:40: error: use of undeclared identifier 'm' error = mac_ifnet_check_transmit(ifp, m); ^ ../../../net/if_ethersubr.c:342:2: error: expected identifier or '(' if (error) ^ ../../../net/if_ethersubr.c:343:3: error: expected identifier or '(' senderr(error); ^ ../../../net/if_ethersubr.c:123:49: note: expanded from macro 'senderr' #define senderr(e) do { error = (e); goto bad;} while (0) ^ ../../../net/if_ethersubr.c:347:2: error: expected identifier or '(' if (ifp->if_flags & IFF_MONITOR) ^ ../../../net/if_ethersubr.c:348:3: error: expected identifier or '(' senderr(ENETDOWN); ^ ../../../net/if_ethersubr.c:123:49: note: expanded from macro 'senderr' #define senderr(e) do { error = (e); goto bad;} while (0) ^ ../../../net/if_ethersubr.c:349:2: error: expected identifier or '(' if (!((ifp->if_flags & IFF_UP) && ^ fatal error: too many errors emitted, stopping now [-ferror-limit=] 20 errors generated. *** Error code 1 Stop. make: stopped in /usr/src/sys/amd64/compile/DNS_VIMAGE From owner-freebsd-net@freebsd.org Fri Mar 16 14:49:00 2018 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 0AFACF547D9 for ; Fri, 16 Mar 2018 14:49:00 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward106o.mail.yandex.net (forward106o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::609]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7F58B81DFE for ; Fri, 16 Mar 2018 14:48:58 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from mxback11j.mail.yandex.net (mxback11j.mail.yandex.net [IPv6:2a02:6b8:0:1619::84]) by forward106o.mail.yandex.net (Yandex) with ESMTP id CC086784089; Fri, 16 Mar 2018 17:48:43 +0300 (MSK) Received: from smtp4p.mail.yandex.net (smtp4p.mail.yandex.net [2a02:6b8:0:1402::15:6]) by mxback11j.mail.yandex.net (nwsmtp/Yandex) with ESMTP id HgBVXoP4yI-mhHqn9uN; Fri, 16 Mar 2018 17:48:43 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1521211723; bh=Uylom3SOAdVyY5eXNz826m39OLXnSkLrMQndNY/6tgc=; h=Subject:To:Cc:References:From:Message-ID:Date:In-Reply-To; b=Il+GnvuuuTCdUfdCKMaQg2boWrM422pM60yUmpcTzg2PqikKHH4V5fNTFQJcK+Xgc nakeQnm0hugYMZoPxDbLKNaW+grTho5BZTRncglRgOZ9p2nxRV1fl6CM9ohd+zwjcz l3eGimwGnBTyW9SFHy8voUYIp4hXzNqk6Jg9N6bA= Received: by smtp4p.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id d5hshxe5wl-mgSa8eoW; Fri, 16 Mar 2018 17:48:42 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1521211722; bh=Uylom3SOAdVyY5eXNz826m39OLXnSkLrMQndNY/6tgc=; h=Subject:To:Cc:References:From:Message-ID:Date:In-Reply-To; b=RAVj+5DZ9rY9/GKybZJxTw4mlxiUea5fB01CZRXH3JuPOcWhpA4LMFuxjWo3d7rdS DplVTv2OhW21z2OSFjwG2D/Cxc/RMlserFoRq9EJ9PgYoEMOV/Dm9JilJYo56NLOiH /pLz+AOe1e4b54ZJ0W8YZoRnQNPiziFn/2cLCZEc= Authentication-Results: smtp4p.mail.yandex.net; dkim=pass header.i=@yandex.ru Subject: Re: Does FreeBSD do proactive ARP refresh?,Re: Does FreeBSD do proactive ARP refresh? To: sthaug@nethelp.no Cc: freebsd-net@freebsd.org, melifaro@ipfw.ru References: <20180316.122720.71152047.sthaug@nethelp.no> <20180316.124748.104098359.sthaug@nethelp.no> <21eca372-6fc0-6c86-4ca8-a398bfa37d92@yandex.ru> <20180316.144734.78772139.sthaug@nethelp.no> From: "Andrey V. Elsukov" Openpgp: id=E6591E1B41DA1516F0C9BC0001C5EA0410C8A17A Message-ID: <2b01893d-e2d0-b5a0-cfc4-1550f4d0c1da@yandex.ru> Date: Fri, 16 Mar 2018 17:47:28 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180316.144734.78772139.sthaug@nethelp.no> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="eUVqF4WGzAsLGS7IChhUPLQIlU1JFsPTJ" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2018 14:49:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --eUVqF4WGzAsLGS7IChhUPLQIlU1JFsPTJ Content-Type: multipart/mixed; boundary="7aznOmSKlcKOyNHAiCBQ5LiViBDq1I9YV"; protected-headers="v1" From: "Andrey V. Elsukov" To: sthaug@nethelp.no Cc: freebsd-net@freebsd.org, melifaro@ipfw.ru Message-ID: <2b01893d-e2d0-b5a0-cfc4-1550f4d0c1da@yandex.ru> Subject: Re: Does FreeBSD do proactive ARP refresh?,Re: Does FreeBSD do proactive ARP refresh? References: <20180316.122720.71152047.sthaug@nethelp.no> <20180316.124748.104098359.sthaug@nethelp.no> <21eca372-6fc0-6c86-4ca8-a398bfa37d92@yandex.ru> <20180316.144734.78772139.sthaug@nethelp.no> In-Reply-To: <20180316.144734.78772139.sthaug@nethelp.no> --7aznOmSKlcKOyNHAiCBQ5LiViBDq1I9YV Content-Type: multipart/mixed; boundary="------------6E23A3D56A03045BA3AFD375" Content-Language: en-US This is a multi-part message in MIME format. --------------6E23A3D56A03045BA3AFD375 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 16.03.2018 16:47, sthaug@nethelp.no wrote: >> Can you test this patch? I did not tested it, but I think it should fi= x >> this issue. >=20 > Looks like this is a patch against HEAD. I don't have any boxes > running HEAD, but I can get one installed and test the patch this > weekend (unless you want to produce a patch against 11.1-STABLE). >=20 > I tried the patch manually applied on 11.1-STABLE, but got lots of > errors during kernel compilation (see the end of this message). I made the patch for stable/11, but I need some time to build kernel-toolchain, since compiler from head/ doesn't want to build stable/11 kernel :) --=20 WBR, Andrey V. Elsukov --------------6E23A3D56A03045BA3AFD375 Content-Type: text/x-patch; name="ethersubr11.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="ethersubr11.diff" Index: stable/11/sys/net/if_ethersubr.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- stable/11/sys/net/if_ethersubr.c (revision 331055) +++ stable/11/sys/net/if_ethersubr.c (working copy) @@ -292,7 +292,6 @@ ether_output(struct ifnet *ifp, struct mbuf *m, int hlen; /* link layer header length */ uint32_t pflags; struct llentry *lle =3D NULL; - struct rtentry *rt0 =3D NULL; int addref =3D 0; =20 phdr =3D NULL; @@ -320,9 +319,20 @@ ether_output(struct ifnet *ifp, struct mbuf *m, phdr =3D lle->r_linkdata; hlen =3D lle->r_hdrlen; pflags =3D lle->r_flags; + /* + * XXX: Check if we have feedback request + * from arptimer()/nd6_llinfo_timer(). + */ + if ((pflags & RLLE_VALID) && + lle->r_skip_req !=3D 0) { + LLE_REQ_LOCK(lle); + /* Notify that entry was used */ + lle->r_skip_req =3D 0; + lle->lle_hittime =3D time_uptime; + LLE_REQ_UNLOCK(lle); + } } } - rt0 =3D ro->ro_rt; } =20 #ifdef MAC --------------6E23A3D56A03045BA3AFD375-- --7aznOmSKlcKOyNHAiCBQ5LiViBDq1I9YV-- --eUVqF4WGzAsLGS7IChhUPLQIlU1JFsPTJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEzBAEBCAAdFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAlqr2QAACgkQAcXqBBDI oXoRqAf/TqHNTheZDRgF1mtB3kPD70qjkpPteCf8BAIunPKwlRl/CqdT/ohizcye psI9gHcUbMCf0VppVHM8wiQDd+6axeAy5iBX5Dw3hzLcorp3duUHCCtHVS2cVjpJ /+M/CeGofKKLEcy+7PCvQUaeBXTOmdYqtqO6pfKCO/Ta64aAzAkwKQr+BS4MpDjE mtFRvDlb760cXlWqbHyj+purQFrYM5+ggQuy/o4jaI1L/4Rm52fEBL6cSPt9cios TQObPw/1rIEW8C25zavaOR331OK00Ok6JreGNQ0dohk7vYyDV0GrrSBWnarg2AAF AyDIRW2MDaj97X3K06NowTL/t+FhIg== =Q3fN -----END PGP SIGNATURE----- --eUVqF4WGzAsLGS7IChhUPLQIlU1JFsPTJ-- From owner-freebsd-net@freebsd.org Fri Mar 16 22:49:18 2018 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 02CF4F54021 for ; Fri, 16 Mar 2018 22:49:18 +0000 (UTC) (envelope-from aspam@cox.net) Received: from fed1rmfepi208.cox.net (fed1rmfepi208.cox.net [68.230.241.153]) by mx1.freebsd.org (Postfix) with ESMTP id 57DDB78D5F for ; Fri, 16 Mar 2018 22:49:16 +0000 (UTC) (envelope-from aspam@cox.net) Received: from eastrmimpo209.cox.net ([68.230.241.224]) by eastrmfepo103.cox.net (InterMail vM.8.01.05.28 201-2260-151-171-20160122) with ESMTP id <20180316224832.BIYD22712.eastrmfepo103.cox.net@eastrmimpo209.cox.net> for ; Fri, 16 Mar 2018 18:48:32 -0400 Received: from thunder.sweets ([68.100.138.62]) by eastrmimpo209.cox.net with cox id NmoX1x0121LxgH801moYre; Fri, 16 Mar 2018 18:48:32 -0400 X-Authority-Analysis: v=2.2 cv=LrHi8jVc c=1 sm=1 tr=0 a=3mkzfl4ircflX6G+lDqBYw==:117 a=3mkzfl4ircflX6G+lDqBYw==:17 a=8nJEP1OIZ-IA:10 a=x7bEGLp0ZPQA:10 a=v2DPQv5-lfwA:10 a=e9ASbk4n0QUA:10 a=mw34aWhVYinFip9fX-kA:9 a=wPNLvfGTeEIA:10 X-CM-Score: 0.00 Authentication-Results: cox.net; auth=pass (LOGIN) smtp.auth=jbuehler@cox.net Received: from [10.10.10.15] (thunder.sweets [10.10.10.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thunder.sweets (Postfix) with ESMTP id 97F861178C for ; Fri, 16 Mar 2018 18:48:31 -0400 (EDT) Message-ID: <5AAC49BE.3030508@cox.net> Date: Fri, 16 Mar 2018 18:48:30 -0400 From: Joe Buehler User-Agent: Thunderbird 1.5.0.12 (X11/20120201) MIME-Version: 1.0 To: "freebsd-net@freebsd.org" Subject: netmap ixgbevf mtu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2018 22:49:18 -0000 I am having difficulties with netmap over top of ixgbevf when attempting to use a large MTU (say 9000 bytes). Does the ixgbevf driver use 2048 byte buffers for RX regardless of the MTU or netmap buffer size? I can send large frames just fine but inbound frames are passed via netmap as 2048 bytes max. It is possible that netmap is passing frames in multiple pieces I suppose, I haven't checked that yet -- my code is looking at the frame headers only at the moment so would toss trailing pieces. Joe Buehler From owner-freebsd-net@freebsd.org Fri Mar 16 22:52:15 2018 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 0E1D2F543AD for ; Fri, 16 Mar 2018 22:52:15 +0000 (UTC) (envelope-from aspam@cox.net) Received: from eastrmfepo202.cox.net (eastrmfepo202.cox.net [68.230.241.217]) by mx1.freebsd.org (Postfix) with ESMTP id 9FAFB7908C for ; Fri, 16 Mar 2018 22:52:14 +0000 (UTC) (envelope-from aspam@cox.net) Received: from eastrmimpo305.cox.net ([68.230.241.237]) by eastrmfepo202.cox.net (InterMail vM.8.01.05.28 201-2260-151-171-20160122) with ESMTP id <20180316225208.CNXD7322.eastrmfepo202.cox.net@eastrmimpo305.cox.net> for ; Fri, 16 Mar 2018 18:52:08 -0400 Received: from thunder.sweets ([68.100.138.62]) by eastrmimpo305.cox.net with cox id Nms71x00y1LxgH801ms826; Fri, 16 Mar 2018 18:52:08 -0400 X-Authority-Analysis: v=2.2 cv=f7U4PK6M c=1 sm=1 tr=0 a=3mkzfl4ircflX6G+lDqBYw==:117 a=3mkzfl4ircflX6G+lDqBYw==:17 a=9cW_t1CCXrUA:10 a=8nJEP1OIZ-IA:10 a=x7bEGLp0ZPQA:10 a=v2DPQv5-lfwA:10 a=7-O5ulbGV6muH2ddRrgA:9 a=wPNLvfGTeEIA:10 X-CM-Score: 0.00 Authentication-Results: cox.net; auth=pass (LOGIN) smtp.auth=jbuehler@cox.net Received: from [10.10.10.15] (thunder.sweets [10.10.10.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thunder.sweets (Postfix) with ESMTP id 8C47F1178C for ; Fri, 16 Mar 2018 18:52:07 -0400 (EDT) Message-ID: <5AAC4A96.1040107@cox.net> Date: Fri, 16 Mar 2018 18:52:06 -0400 From: Joe Buehler User-Agent: Thunderbird 1.5.0.12 (X11/20120201) MIME-Version: 1.0 CC: "freebsd-net@freebsd.org" Subject: Re: netmap ixgbevf mtu References: <5AAC49BE.3030508@cox.net> In-Reply-To: <5AAC49BE.3030508@cox.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2018 22:52:15 -0000 Sorry, I should have added, this is LINUX if it matters. Joe Buehler wrote: > I am having difficulties with netmap over top of ixgbevf when attempting to use a large MTU (say 9000 bytes). > > Does the ixgbevf driver use 2048 byte buffers for RX regardless of the MTU or netmap buffer size? > > I can send large frames just fine but inbound frames are passed via netmap as 2048 bytes max. It is possible that netmap is passing frames in multiple pieces I suppose, I haven't checked that yet -- my code is looking at the frame headers only at the moment so would toss trailing pieces. > > Joe Buehler > > From owner-freebsd-net@freebsd.org Sat Mar 17 07:19:54 2018 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 EFE2BF4C912 for ; Sat, 17 Mar 2018 07:19:53 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 95FEB6BC29 for ; Sat, 17 Mar 2018 07:19:53 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mail-qk0-x22d.google.com with SMTP id s188so13456224qkb.2 for ; Sat, 17 Mar 2018 00:19:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DK0mwP2w4Rh6sd2r6n35sHBgAHTR620ssauFunbWB8M=; b=rOFhRgJ/LpOXgsKpU0Yi19zutQnQWQUrhnMS7H1prcuX7Fz8HIAobVeh2Pc3doG/Yc Uf4aKuYKJkhPhtJ8hEFufjPbF0gbuoeAQ1E0lHHe2a0eC9YIicPJL3f9dJy+2ywFxxmN dLoE/5NQgVS/ybkpVIXl+r3V21ObyYSVcz/6hvYKc4NooHriqbnK2W2+evmHzi5QhE2q lSoUBVqGmUBmalnuCcVx6w/D6feu0tBE4bC/CWqvzWJGR+OlLBwqo0nKoXlX7ZFh6dw1 A/SD1PN2CRAPR3EieDgttzsiyYapyQOszDhuu/DeX9+ffXX8L0Ma8hQ3NgyXMVXTbrpa Xw6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DK0mwP2w4Rh6sd2r6n35sHBgAHTR620ssauFunbWB8M=; b=X69fxqEfCmiW13mMp1FZO0fCBQR6pQrWblHRK38MS8n7XtRM0qtBw2riAzmrjWYpGA Mqd4rvHWx7fM/BE2PQQtk4zOqUemgeE0zIUnOBuMividGtZwUkUF/rhWMEP/6kemIb6k pw+Pi6wcdyQT3rV/0565t6VEw39begFHm5xwaUYAWhgoWidmqBqTWDN3cZzAQ3vmApP5 5I63B5sFQnE1QnhrgXs34ieXZOhNE1A3/NiWP4sju7ck9uMvikFKl7oGdpfL8sgC7Ch4 7t30ZpgaSo2dhgM9ARpRkK+jZVpEBszTjwUGXbxPDh0h3NkN+mGbqa2J4S9mIv1YRw1y 0njQ== X-Gm-Message-State: AElRT7GmPV4FLjR7kPt6vtJ3X8WlLvJOxn3IL6Yhr5rahKQeA1ZTb/lK KiPFTy5Mat0Z08Gt2PdEfcMFuBUV2h9afLsERxA= X-Google-Smtp-Source: AG47ELtEujH7I2zGK1OtB9vuwCQ3nNsFAEATZbEFp5HroS0hq7kgWr9VgeKD1T6vUbBB+Y6zg2r64cSmZJGHCE1Xpzk= X-Received: by 10.55.77.67 with SMTP id a64mr6986952qkb.249.1521271192468; Sat, 17 Mar 2018 00:19:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.195.204 with HTTP; Sat, 17 Mar 2018 00:19:52 -0700 (PDT) In-Reply-To: <5AAC4A96.1040107@cox.net> References: <5AAC49BE.3030508@cox.net> <5AAC4A96.1040107@cox.net> From: Vincenzo Maffione Date: Sat, 17 Mar 2018 08:19:52 +0100 Message-ID: Subject: Re: netmap ixgbevf mtu To: Joe Buehler Cc: "freebsd-net@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2018 07:19:54 -0000 First, please make sure to use the latest netmap from github. Yes, drivers in general use 2K or 4K RX buffers regardless of the MTU or netmap buffer size. To receive a frame larger than the RX buffer size you need multiple netmap slots (as multiple descriptors are used by the hardware), looking at the NS_MOREFRAG flag. See the example code in utils/functional.c::rx_one(). Also TX may have per-slot limitations (e.g. due to the size of the NIC TX fifo), but this is usually > 9K, so using a single descriptor per packet should always be ok. However, you can also use multiple slots on the TX side (see utils/functional.c::tx_one()). You need to set the buf_size parameter to the RX buffer size. Currently we miss a mechanism for netmap to get the actual RX buffer size from the NIC driver, so we assume 4K. We need to check that buf_size is >= RX buffer size. This mechanism will be added soon. Cheers, Vincenzo 2018-03-16 23:52 GMT+01:00 Joe Buehler : > Sorry, I should have added, this is LINUX if it matters. > > Joe Buehler wrote: > > I am having difficulties with netmap over top of ixgbevf when attempting > to use a large MTU (say 9000 bytes). > > > > Does the ixgbevf driver use 2048 byte buffers for RX regardless of the > MTU or netmap buffer size? > > > > I can send large frames just fine but inbound frames are passed via > netmap as 2048 bytes max. It is possible that netmap is passing frames in > multiple pieces I suppose, I haven't checked that yet -- my code is looking > at the frame headers only at the moment so would toss trailing pieces. > > > > Joe Buehler > > > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- Vincenzo Maffione From owner-freebsd-net@freebsd.org Sat Mar 17 17:13:01 2018 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 34F19F597A0 for ; Sat, 17 Mar 2018 17:13:01 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from forward103p.mail.yandex.net (forward103p.mail.yandex.net [77.88.28.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 99EB184DBE for ; Sat, 17 Mar 2018 17:12:59 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from mxback4o.mail.yandex.net (mxback4o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::1e]) by forward103p.mail.yandex.net (Yandex) with ESMTP id AF3B52182DD0; Sat, 17 Mar 2018 20:12:51 +0300 (MSK) Received: from localhost (localhost [::1]) by mxback4o.mail.yandex.net (nwsmtp/Yandex) with ESMTP id jHLcZ2kOga-CopGYb4q; Sat, 17 Mar 2018 20:12:50 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfw.ru; s=mail; t=1521306770; bh=C0wry0MOpZohP9KiRaEb5O87D/oZv6191YJZiv6xrS8=; h=From:To:Cc:In-Reply-To:References:Subject:Message-Id:Date; b=WNtSGyepgI2WQ8FqKTvVIoQV/NCUVSdPIMCP+0nWEHiOWs0MjYNznLGzwMPicZQi0 Sf/ZFBjxpNgnIaSX30fJIZyJ3k/g3CUeGKXRFqWlc6U0CGB0Hn8ESo5IzAIIxSU+gI BletVNrtOfsD2mNZqmNKzP+j/GsjuUD1CS6u/CJM= Authentication-Results: mxback4o.mail.yandex.net; dkim=pass header.i=@ipfw.ru Received: by web10o.yandex.ru with HTTP; Sat, 17 Mar 2018 20:12:50 +0300 From: Alexander V. Chernikov To: "sthaug@nethelp.no" Cc: "freebsd-net@freebsd.org" In-Reply-To: <20180316.124748.104098359.sthaug@nethelp.no> References: <8530131521193098@web19g.yandex.ru> <20180316.110054.74682026.sthaug@nethelp.no> <20180316.122720.71152047.sthaug@nethelp.no> <20180316.124748.104098359.sthaug@nethelp.no> Subject: Re: Does FreeBSD do proactive ARP refresh? MIME-Version: 1.0 Message-Id: <14964521521306770@web10o.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Sat, 17 Mar 2018 20:12:50 +0300 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2018 17:13:01 -0000 16.03.2018, 14:50, "sthaug@nethelp.no" : .. >>  And thank you for that suggestion! The packet loss during ARP refresh >>  (of the destination address connected to the output interface) does >>  *not* happen when the box is forwarding! It only happens with locally >>  generated traffic. Should be fixed by r331098. From owner-freebsd-net@freebsd.org Sat Mar 17 18:20:13 2018 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 D1E7AF5E3D3 for ; Sat, 17 Mar 2018 18:20:13 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 43D506809E for ; Sat, 17 Mar 2018 18:20:12 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w2HIK9qH003585; Sat, 17 Mar 2018 11:20:09 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w2HIK98r003584; Sat, 17 Mar 2018 11:20:09 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201803171820.w2HIK98r003584@pdx.rh.CN85.dnsmgr.net> Subject: Re: Does FreeBSD do proactive ARP refresh? In-Reply-To: <14964521521306770@web10o.yandex.ru> To: "Alexander V. Chernikov" Date: Sat, 17 Mar 2018 11:20:09 -0700 (PDT) CC: "sthaug@nethelp.no" , "freebsd-net@freebsd.org" X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2018 18:20:14 -0000 > 16.03.2018, 14:50, "sthaug@nethelp.no" : > .. > >> ?And thank you for that suggestion! The packet loss during ARP refresh > >> ?(of the destination address connected to the output interface) does > >> ?*not* happen when the box is forwarding! It only happens with locally > >> ?generated traffic. > Should be fixed by r331098. Thanks for the quick fix, do we know about when this breakage started? -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-net@freebsd.org Sat Mar 17 18:36:23 2018 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 78EB1F5F54A for ; Sat, 17 Mar 2018 18:36:23 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from forward103j.mail.yandex.net (forward103j.mail.yandex.net [5.45.198.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EFE8768C54 for ; Sat, 17 Mar 2018 18:36:22 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from mxback5g.mail.yandex.net (mxback5g.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:166]) by forward103j.mail.yandex.net (Yandex) with ESMTP id 18A4734C4BC3; Sat, 17 Mar 2018 21:36:20 +0300 (MSK) Received: from localhost (localhost [::1]) by mxback5g.mail.yandex.net (nwsmtp/Yandex) with ESMTP id x8TOdA5zhg-aIfGZbZL; Sat, 17 Mar 2018 21:36:19 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfw.ru; s=mail; t=1521311779; bh=e9eDRLuH0m5nKKSAISv6jHqv1E6LV5Pr4SxKCi67Cck=; h=From:To:Cc:In-Reply-To:References:Subject:Message-Id:Date; b=Clh65O9C5X87POGKejSfe+o3ghmp5uIXVqcdxtL6WOMgiCfIOEEi1UPOq+5N+jej3 UAW3//rNjujr9FOCkrTLC6AtTdNrHVts8pQU6/kjgwr0UTKJHIYm4F8gGu7jG11Mt4 kZtjEXpJcn72JAPjrZrnTCPi7R2q9SVfujGgEyWQ= Authentication-Results: mxback5g.mail.yandex.net; dkim=pass header.i=@ipfw.ru Received: by web56g.yandex.ru with HTTP; Sat, 17 Mar 2018 21:36:18 +0300 From: Alexander V. Chernikov To: Rodney W. Grimes Cc: "freebsd-net@freebsd.org" , "sthaug@nethelp.no" In-Reply-To: <201803171820.w2HIK98r003584@pdx.rh.CN85.dnsmgr.net> References: <14964521521306770@web10o.yandex.ru> <201803171820.w2HIK98r003584@pdx.rh.CN85.dnsmgr.net> Subject: Re: Does FreeBSD do proactive ARP refresh? MIME-Version: 1.0 Message-Id: <7275711521311778@web56g.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Sat, 17 Mar 2018 21:36:18 +0300 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2018 18:36:23 -0000 17.03.2018, 21:23, "Rodney W. Grimes" : >>  16.03.2018, 14:50, "sthaug@nethelp.no" : >>  .. >>  >> ?And thank you for that suggestion! The packet loss during ARP refresh >>  >> ?(of the destination address connected to the output interface) does >>  >> ?*not* happen when the box is forwarding! It only happens with locally >>  >> ?generated traffic. >>  Should be fixed by r331098. > > Thanks for the quick fix, do we know about when this breakage started? I guess it's something like r297225. > > -- > Rod Grimes rgrimes@freebsd.org > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"