From owner-freebsd-net@freebsd.org Sun Aug 25 04:56:44 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3B57FD527C for ; Sun, 25 Aug 2019 04:56:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 46GNCJ0wr4z4XJW for ; Sun, 25 Aug 2019 04:56:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 1DE57D527B; Sun, 25 Aug 2019 04:56:44 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1DA27D527A for ; Sun, 25 Aug 2019 04:56:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46GNCJ02mWz4XJS for ; Sun, 25 Aug 2019 04:56:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id D874B18631 for ; Sun, 25 Aug 2019 04:56:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x7P4uheT087540 for ; Sun, 25 Aug 2019 04:56:43 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x7P4uh7p087539 for net@FreeBSD.org; Sun, 25 Aug 2019 04:56:43 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: net@FreeBSD.org Subject: [Bug 238796] ipfilter: failure to detect the same rules when arguments ordered differently Date: Sun, 25 Aug 2019 04:56:42 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: patch 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: cy@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? mfc-stable12? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2019 04:56:44 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238796 --- Comment #41 from commit-hook@freebsd.org --- A commit references this bug: Author: cy Date: Sun Aug 25 04:56:35 UTC 2019 New revision: 351470 URL: https://svnweb.freebsd.org/changeset/base/351470 Log: MFC r350880: r272552 applied the patch from ipfilter upstream fil.c r1.129 to fix broken ipfilter rule matches (upstream bug #554). The upstream patch was incomplete, it resolved all but one rule compare issue. The issue fixed here is when "{to, reply-to, dup-to} interface" are used in conjuncion with "on interface". The match was only made if the on keyword was specified in the same order in each case referencing the same rule. This commit fixes this. The reason for this is that interface name strings and comment keyword comments are stored in a a variable length field starting at fr_names in the frentry struct. These strings are placed into this variable length in the order they are encountered by ipf_y.y and indexed through index pointers in fr_ifnames, fr_comment or one of the frdest struct fd_name fields. (Three frdest structs are within frentry.) Order matters and this patch takes this into account. While in here it was discovered that though ipfilter is designed to pport multiple interface specifiations per rule (up to four), this undocumented (the man page makes no mention of it) feature does not work. A todo is to fix the multiple interfaces feature at a later date. To understand the design decision as to why only four were intended, it is suspected that the decision was made because Sun workstations and PCs rarely if ever exceeded four NICs at the time, this is not true in 2019. PR: 238796 Reported by: WHR Changes: _U stable/11/ stable/11/sys/contrib/ipfilter/netinet/fil.c stable/11/sys/contrib/ipfilter/netinet/ip_fil.h _U stable/12/ stable/12/sys/contrib/ipfilter/netinet/fil.c stable/12/sys/contrib/ipfilter/netinet/ip_fil.h --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Sun Aug 25 04:59:37 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 39E35D5454 for ; Sun, 25 Aug 2019 04:59:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 46GNGd0pwVz4XQh for ; Sun, 25 Aug 2019 04:59:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 1A282D5453; Sun, 25 Aug 2019 04:59:37 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 19ECCD5452 for ; Sun, 25 Aug 2019 04:59:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46GNGc737Pz4XQf for ; Sun, 25 Aug 2019 04:59:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id CF9E918632 for ; Sun, 25 Aug 2019 04:59:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x7P4xaEc093244 for ; Sun, 25 Aug 2019 04:59:36 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x7P4xaCD093243 for net@FreeBSD.org; Sun, 25 Aug 2019 04:59:36 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 238796] ipfilter: failure to detect the same rules when arguments ordered differently Date: Sun, 25 Aug 2019 04:59:36 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: cy@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: cy@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? mfc-stable12? 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.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2019 04:59:37 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238796 Cy Schubert changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|In Progress |Closed --- Comment #42 from Cy Schubert --- Fixed. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Sun Aug 25 07:22:12 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C02FDD7FE1 for ; Sun, 25 Aug 2019 07:22:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 46GRR84lYhz4f6f for ; Sun, 25 Aug 2019 07:22:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id A3038D7FE0; Sun, 25 Aug 2019 07:22:12 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A2CADD7FDF for ; Sun, 25 Aug 2019 07:22:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46GRR83t3Zz4f6d for ; Sun, 25 Aug 2019 07:22:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 66DE61A12E for ; Sun, 25 Aug 2019 07:22:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x7P7MCnQ014364 for ; Sun, 25 Aug 2019 07:22:12 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x7P7MCu4014345 for net@FreeBSD.org; Sun, 25 Aug 2019 07:22:12 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 240023] netmap lb pointer out of bounds on ixgbe Date: Sun, 25 Aug 2019 07:22:12 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.3-RELEASE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: vmaffione@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2019 07:22:12 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D240023 Vincenzo Maffione changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |vmaffione@FreeBSD.org --- Comment #3 from Vincenzo Maffione --- This looks like related to this issue https://github.com/luigirizzo/netmap/issues/600 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sun Aug 25 07:39:04 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C664CD8466 for ; Sun, 25 Aug 2019 07:39:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 46GRpc4vwKz4fgX for ; Sun, 25 Aug 2019 07:39:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id A88CDD8465; Sun, 25 Aug 2019 07:39:04 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A84F4D8464 for ; Sun, 25 Aug 2019 07:39:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46GRpc40ysz4fgW for ; Sun, 25 Aug 2019 07:39:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 6B8411A330 for ; Sun, 25 Aug 2019 07:39:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x7P7d4tV097081 for ; Sun, 25 Aug 2019 07:39:04 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x7P7d42n097080 for net@FreeBSD.org; Sun, 25 Aug 2019 07:39: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: net@FreeBSD.org Subject: [Bug 240023] netmap lb pointer out of bounds on ixgbe Date: Sun, 25 Aug 2019 07:39: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: 11.3-RELEASE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: vmaffione@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@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.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2019 07:39:04 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D240023 --- Comment #4 from Vincenzo Maffione --- If 11.2-p9 works, it would help to see what changed in ixgbe and ixl between 11.2-p9 and 11.3. Are you able to generate a diff or provide pointers to the exact two source trees you are using? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sun Aug 25 20:40:43 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 778AFC2D35 for ; Sun, 25 Aug 2019 20:40:43 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward105o.mail.yandex.net (forward105o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::608]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46Gn8T33tRz4RY7 for ; Sun, 25 Aug 2019 20:40:41 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from mxback3g.mail.yandex.net (mxback3g.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:164]) by forward105o.mail.yandex.net (Yandex) with ESMTP id 378064200C20; Sun, 25 Aug 2019 23:40:37 +0300 (MSK) Received: from smtp4j.mail.yandex.net (smtp4j.mail.yandex.net [2a02:6b8:0:1619::15:6]) by mxback3g.mail.yandex.net (nwsmtp/Yandex) with ESMTP id 0MWQeQ52et-ebAm2DPF; Sun, 25 Aug 2019 23:40:37 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1566765637; bh=p6MyJwxykuz4Kv6GTiXg/MNvPHMjMtEo0auiCkNiNBU=; h=In-Reply-To:From:Date:References:To:Subject:Message-ID; b=u/VZ1uaiw1BP/4KgoTw4PpA973JM46GSWgq7Vil3AyGVEezRdLZXDJr83PazC8X7U HIgUFfEo7TRy714BmRF0ZGGt3yEqnZKzXCHMSkqP5M7XMKE8uTFR0lcVBO8pnqEbni uYLZ5Vmp9yeO9TPn38ur/jNbGu2J/OFhfhBwoyuM= Received: by smtp4j.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id RhxOwIGNTM-eaQCHAvc; Sun, 25 Aug 2019 23:40:36 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) Subject: Re: finding optimal ipfw strategy To: Eugene Grosbein , Victor Gamov , freebsd-net@freebsd.org References: <4ff39c8f-341c-5d72-1b26-6558c57bff8d@grosbein.net> From: "Andrey V. Elsukov" Openpgp: id=E6591E1B41DA1516F0C9BC0001C5EA0410C8A17A Autocrypt: addr=bu7cher@yandex.ru; prefer-encrypt=mutual; keydata= mQENBEwBF1kBCADB9sXFhBEUy8qQ4X63Y8eBatYMHGEFWN9ypS5lI3RE6qQW2EYbxNk7qUC5 21YIIS1mMFVBEfvR7J9uc7yaYgFCEb6Sce1RSO4ULN2mRKGHP3/Sl0ijZEjWHV91hY1YTHEF ZW/0GYinDf56sYpDDehaBF5wkWIo1+QK5nmj3vl0DIDCMNd7QEiWpyLVwECgLX2eOAXByT8B bCqVhJGcG6iFP7/B9Ll6uX5gb8thM9LM+ibwErDBVDGiOgvfxqidab7fdkh893IBCXa82H9N CNwnEtcgzh+BSKK5BgvPohFMgRwjti37TSxwLu63QejRGbZWSz3OK3jMOoF63tCgn7FvABEB AAG0JUFuZHJleSBWLiBFbHN1a292IDxidTdjaGVyQHlhbmRleC5ydT6JATgEEwECACIFAkwB F1kCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEAHF6gQQyKF6qmYIAI6ekfm1VA4T vqankI1ISE6ku4jV7UlpIQlEbE7/8n3Zd6teJ+pGOQhN5qk8QE7utdPdbktAzi+x7LIJVzUw 4TywZLXGrkP7VKYkfg6oyCGyzITghefQeJtr2TN4hYCkzPWpylkue8MtmqfZv/6royqwTbN+ +E09FQNvTgRUYJYTeQ1qOsxNRycwvw3dr2rOfuxShbzaHBB1pBIjGrMg8fC5pd65ACH5zuFV A0CoTNGMDrEZSfBkTW604UUHFFXeCoC3dwDZRKOWJ3GmMXns65Ai5YkA63BSHEE1Qle3VBhd cG1w0CB5FBV3pB27UVnf0jEbysrDqW4qN7XMRFSWNAy5AQ0ETAEXWQEIAJ2p6l9LBoqdH/0J PEFDY2t2gTvAuzz+8zs3R03dFuHcNbOwjvWCG0aOmVpAzkRa8egn5JB4sZaFUtKPYJEQ1Iu+ LUBwgvtXf4vWpzC67zs2dDuiW4LamH5p6xkTD61aHR7mCB3bg2TUjrDWn2Jt44cvoYxj3dz4 S49U1rc9ZPgD5axCNv45j72tggWlZvpefThP7xT1OlNTUqye2gAwQravXpZkl5JG4eOqJVIU X316iE3qso0iXRUtO7OseBf0PiVmk+wCahdreHOeOxK5jMhYkPKVn7z1sZiB7W2H2TojbmcK HZC22sz7Z/H36Lhg1+/RCnGzdEcjGc8oFHXHCxUAEQEAAYkBHwQYAQIACQUCTAEXWQIbDAAK CRABxeoEEMihegkYCAC3ivGYNe2taNm/4Nx5GPdzuaAJGKWksV+w9mo7dQvU+NmI2az5w8vw 98OmX7G0OV9snxMW+6cyNqBrVFTu33VVNzz9pnqNCHxGvj5dL5ltP160JV2zw2bUwJBYsgYQ WfyJJIM7l3gv5ZS3DGqaGIm9gOK1ANxfrR5PgPzvI9VxDhlr2juEVMZYAqPLEJe+SSxbwLoz BcFCNdDAyXcaAzXsx/E02YWm1hIWNRxanAe7Vlg7OL+gvLpdtrYCMg28PNqKNyrQ87LQ49O9 50IIZDOtNFeR0FGucjcLPdS9PiEqCoH7/waJxWp6ydJ+g4OYRBYNM0EmMgy1N85JJrV1mi5i Message-ID: <270233d9-fcdb-fee9-2557-c2d1ec7bf9e6@yandex.ru> Date: Sun, 25 Aug 2019 23:37:34 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <4ff39c8f-341c-5d72-1b26-6558c57bff8d@grosbein.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jKgCVaeKqqox6f9YS6bpsYK19q6peySg8" X-Rspamd-Queue-Id: 46Gn8T33tRz4RY7 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yandex.ru header.s=mail header.b=u/VZ1uai; dmarc=pass (policy=none) header.from=yandex.ru; spf=pass (mx1.freebsd.org: domain of bu7cher@yandex.ru designates 2a02:6b8:0:1a2d::608 as permitted sender) smtp.mailfrom=bu7cher@yandex.ru X-Spamd-Result: default: False [-6.19 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yandex.ru]; R_SPF_ALLOW(-0.20)[+ip6:2a02:6b8:0:1000::/52]; HAS_ATTACHMENT(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[yandex.ru:+]; DMARC_POLICY_ALLOW(-0.50)[yandex.ru,none]; NEURAL_HAM_SHORT(-0.99)[-0.994,0]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[8.0.6.0.0.0.0.0.0.0.0.0.0.0.0.0.d.2.a.1.0.0.0.0.8.b.6.0.2.0.a.2.list.dnswl.org : 127.0.5.1]; ASN(0.00)[asn:13238, ipnet:2a02:6b8::/32, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yandex.ru.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[yandex.ru:s=mail]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; IP_SCORE(0.00)[ip: (-9.76), ipnet: 2a02:6b8::/32(-4.63), asn: 13238(-3.72), country: RU(0.01)]; FREEMAIL_ENVFROM(0.00)[yandex.ru]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2019 20:40:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jKgCVaeKqqox6f9YS6bpsYK19q6peySg8 Content-Type: multipart/mixed; boundary="KAmcFqsaWyFSILrcG213ymcDo3vK5awES"; protected-headers="v1" From: "Andrey V. Elsukov" To: Eugene Grosbein , Victor Gamov , freebsd-net@freebsd.org Message-ID: <270233d9-fcdb-fee9-2557-c2d1ec7bf9e6@yandex.ru> Subject: Re: finding optimal ipfw strategy References: <4ff39c8f-341c-5d72-1b26-6558c57bff8d@grosbein.net> In-Reply-To: <4ff39c8f-341c-5d72-1b26-6558c57bff8d@grosbein.net> --KAmcFqsaWyFSILrcG213ymcDo3vK5awES Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 24.08.2019 22:34, Eugene Grosbein wrote: > If you are concerned of performance, general rule applies: less checks,= better performance. >=20 > First, use 'out xmit' instead of 'out via'. They are semantically equal= and this is micro-optimization > but it still saves extra check unneeded when combined with "out" keywor= d. >=20 > Also, you should use old table numbers instead of new symbolic table na= mes > when you have many rules checking for interface names and much traffic > because checks for numbered tables are slightly more efficient. > You may use symbolic names still at source level: There isn't any old tables, all tables have symbolic names. Even when you are creating "table(1)", its name is converted into symbolic name. --=20 WBR, Andrey V. Elsukov --KAmcFqsaWyFSILrcG213ymcDo3vK5awES-- --jKgCVaeKqqox6f9YS6bpsYK19q6peySg8 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 - https://www.enigmail.net/ iQEzBAEBCAAdFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAl1i8ZMACgkQAcXqBBDI oXodiAf9Fzb437A8bGQkKOxGR0NIJTS5vazLwMmq1dyqz5mkCleCCHI6v+4MRkWG aKIoF3RlCT+cGf50h+spsngimfUL3PjjQY/fdIwqv0jcf8ZKnlce6sYgR/JwX4ik O3s8gZKfNUALSewTSxoY4RvmtJohJukrT7nhlMZd0lEBD6FKHiJbd7Dh2Q2gOs2c OoneDepaTC0cjXM9ANN6tDtqfFfwW/O3YlOUTAEmfAdEUovgEiOdSroRW68A+asm C5Cn30RXfSJGi09YlCwyXVgY/TV+YeS20wneEOBJMt1jyojrc2m9ZSSL5FmtuGeI xXQ9xpOizu5saiStKsRzn1sN0OcVJg== =oaM3 -----END PGP SIGNATURE----- --jKgCVaeKqqox6f9YS6bpsYK19q6peySg8-- From owner-freebsd-net@freebsd.org Sun Aug 25 21:01:11 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B18C1C4228 for ; Sun, 25 Aug 2019 21:01:11 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 46Gnc74HRjz4TQ5 for ; Sun, 25 Aug 2019 21:01:11 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: by mailman.nyi.freebsd.org (Postfix) id 93049C4225; Sun, 25 Aug 2019 21:01:11 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 92C5EC4223 for ; Sun, 25 Aug 2019 21:01:11 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46Gnc73PnBz4TQ2 for ; Sun, 25 Aug 2019 21:01:11 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 583F9236C0 for ; Sun, 25 Aug 2019 21:01:11 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x7PL1BgM045507 for ; Sun, 25 Aug 2019 21:01:11 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x7PL1BAV045474 for net@FreeBSD.org; Sun, 25 Aug 2019 21:01:11 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201908252101.x7PL1BAV045474@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: net@FreeBSD.org Subject: Problem reports for net@FreeBSD.org that need special attention Date: Sun, 25 Aug 2019 21:01:11 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2019 21:01:11 -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 | 221146 | [ixgbe] Problem with second laggport In Progress | 235700 | oce(4) driver causes fatal trap 12 on boot with e New | 204438 | setsockopt() handling of kern.ipc.maxsockbuf limi New | 205592 | TCP processing in IPSec causes kernel panic New | 213410 | [carp] service netif restart causes hang only whe Open | 193452 | Dell PowerEdge 210 II -- Kernel panic bce (broadc Open | 194485 | Userland cannot add IPv6 prefix routes Open | 200319 | Bridge+CARP crashes/freezes Open | 202510 | [CARP] advertisements sourced from CARP IP cause Open | 222273 | igb(4): Kernel panic (fatal trap 12) due to netwo Open | 225438 | panic in6_unlink_ifa() due to race Open | 227720 | Kernel panic in ppp server Open | 233952 | jme NICs non functional after 11.2 to 12.0 upgrad Open | 236888 | ppp daemon: Allow MTU to be overridden for PPPoE Open | 236983 | bnxt(4) VLAN not operational unless explicit "ifc Open | 237072 | netgraph(4): performance issue [on HardenedBSD]? Open | 237391 | route get returns no result for network addresses Open | 237840 | Removed dummynet dependency on ipfw 18 problems total for which you should take action. From owner-freebsd-net@freebsd.org Mon Aug 26 00:30:41 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A7628CA0CA for ; Mon, 26 Aug 2019 00:30:41 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (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 46GtFr5YWbz4frh for ; Mon, 26 Aug 2019 00:30:40 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id x7Q0URNA027942 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 26 Aug 2019 00:30:29 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: bu7cher@yandex.ru Received: from [10.58.0.4] (dadv@[10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id x7Q0UNhx067499 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 26 Aug 2019 07:30:23 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: finding optimal ipfw strategy To: "Andrey V. Elsukov" , Victor Gamov , freebsd-net@freebsd.org References: <4ff39c8f-341c-5d72-1b26-6558c57bff8d@grosbein.net> <270233d9-fcdb-fee9-2557-c2d1ec7bf9e6@yandex.ru> From: Eugene Grosbein Message-ID: <25f37482-80b7-3aea-2c67-20faedadf429@grosbein.net> Date: Mon, 26 Aug 2019 07:30:22 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <270233d9-fcdb-fee9-2557-c2d1ec7bf9e6@yandex.ru> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -0.0 SPF_PASS SPF: sender matches SPF record * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 46GtFr5YWbz4frh X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-4.45 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_PERMFAIL(0.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.977,0]; IP_SCORE(-1.38)[ip: (-3.12), ipnet: 2a01:4f8::/29(-1.96), asn: 24940(-1.79), country: DE(-0.01)]; FREEMAIL_TO(0.00)[yandex.ru]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 00:30:41 -0000 26.08.2019 3:37, Andrey V. Elsukov wrote: > On 24.08.2019 22:34, Eugene Grosbein wrote: >> If you are concerned of performance, general rule applies: less checks, better performance. >> >> First, use 'out xmit' instead of 'out via'. They are semantically equal and this is micro-optimization >> but it still saves extra check unneeded when combined with "out" keyword. >> >> Also, you should use old table numbers instead of new symbolic table names >> when you have many rules checking for interface names and much traffic >> because checks for numbered tables are slightly more efficient. >> You may use symbolic names still at source level: > > There isn't any old tables, all tables have symbolic names. Even when > you are creating "table(1)", its name is converted into symbolic name. Yes, and this code path is slightly more efficient. A bit. From owner-freebsd-net@freebsd.org Mon Aug 26 08:34:30 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AA495D480B for ; Mon, 26 Aug 2019 08:34:30 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward100p.mail.yandex.net (forward100p.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46H5051ft6z45Xv for ; Mon, 26 Aug 2019 08:34:28 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from mxback11o.mail.yandex.net (mxback11o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::62]) by forward100p.mail.yandex.net (Yandex) with ESMTP id B1F2F5980F54; Mon, 26 Aug 2019 11:34:24 +0300 (MSK) Received: from smtp3o.mail.yandex.net (smtp3o.mail.yandex.net [2a02:6b8:0:1a2d::27]) by mxback11o.mail.yandex.net (nwsmtp/Yandex) with ESMTP id HYT0qLw4er-YNPe3JoU; Mon, 26 Aug 2019 11:34:24 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1566808464; bh=noqQPoVx7RZTODUZFPqsQWVgX35hFh8BHkQ5s77qXWg=; h=In-Reply-To:From:Date:References:To:Subject:Message-ID; b=TMKI4TYCBp8tjJ1EneMOqNejKAapgJU+rnKIt5C6eoF6GxrgIyUE5yWxNZD2q5md7 /NfIhRr3JPRNJZruk4H2c3XG8KIyatGq0wBKMEwXl+8YsXdcQfSMDqVsdJcv2IiYkq MbicBGFnxtT4D2jsgh6Idl2B1faB5WCaTzK0/sWc= Received: by smtp3o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id ycOkKgeDcV-YNc05FTD; Mon, 26 Aug 2019 11:34:23 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) Subject: Re: finding optimal ipfw strategy To: Eugene Grosbein , Victor Gamov , freebsd-net@freebsd.org References: <4ff39c8f-341c-5d72-1b26-6558c57bff8d@grosbein.net> <270233d9-fcdb-fee9-2557-c2d1ec7bf9e6@yandex.ru> <25f37482-80b7-3aea-2c67-20faedadf429@grosbein.net> From: "Andrey V. Elsukov" Openpgp: id=E6591E1B41DA1516F0C9BC0001C5EA0410C8A17A Autocrypt: addr=bu7cher@yandex.ru; prefer-encrypt=mutual; keydata= mQENBEwBF1kBCADB9sXFhBEUy8qQ4X63Y8eBatYMHGEFWN9ypS5lI3RE6qQW2EYbxNk7qUC5 21YIIS1mMFVBEfvR7J9uc7yaYgFCEb6Sce1RSO4ULN2mRKGHP3/Sl0ijZEjWHV91hY1YTHEF ZW/0GYinDf56sYpDDehaBF5wkWIo1+QK5nmj3vl0DIDCMNd7QEiWpyLVwECgLX2eOAXByT8B bCqVhJGcG6iFP7/B9Ll6uX5gb8thM9LM+ibwErDBVDGiOgvfxqidab7fdkh893IBCXa82H9N CNwnEtcgzh+BSKK5BgvPohFMgRwjti37TSxwLu63QejRGbZWSz3OK3jMOoF63tCgn7FvABEB AAG0JUFuZHJleSBWLiBFbHN1a292IDxidTdjaGVyQHlhbmRleC5ydT6JATgEEwECACIFAkwB F1kCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEAHF6gQQyKF6qmYIAI6ekfm1VA4T vqankI1ISE6ku4jV7UlpIQlEbE7/8n3Zd6teJ+pGOQhN5qk8QE7utdPdbktAzi+x7LIJVzUw 4TywZLXGrkP7VKYkfg6oyCGyzITghefQeJtr2TN4hYCkzPWpylkue8MtmqfZv/6royqwTbN+ +E09FQNvTgRUYJYTeQ1qOsxNRycwvw3dr2rOfuxShbzaHBB1pBIjGrMg8fC5pd65ACH5zuFV A0CoTNGMDrEZSfBkTW604UUHFFXeCoC3dwDZRKOWJ3GmMXns65Ai5YkA63BSHEE1Qle3VBhd cG1w0CB5FBV3pB27UVnf0jEbysrDqW4qN7XMRFSWNAy5AQ0ETAEXWQEIAJ2p6l9LBoqdH/0J PEFDY2t2gTvAuzz+8zs3R03dFuHcNbOwjvWCG0aOmVpAzkRa8egn5JB4sZaFUtKPYJEQ1Iu+ LUBwgvtXf4vWpzC67zs2dDuiW4LamH5p6xkTD61aHR7mCB3bg2TUjrDWn2Jt44cvoYxj3dz4 S49U1rc9ZPgD5axCNv45j72tggWlZvpefThP7xT1OlNTUqye2gAwQravXpZkl5JG4eOqJVIU X316iE3qso0iXRUtO7OseBf0PiVmk+wCahdreHOeOxK5jMhYkPKVn7z1sZiB7W2H2TojbmcK HZC22sz7Z/H36Lhg1+/RCnGzdEcjGc8oFHXHCxUAEQEAAYkBHwQYAQIACQUCTAEXWQIbDAAK CRABxeoEEMihegkYCAC3ivGYNe2taNm/4Nx5GPdzuaAJGKWksV+w9mo7dQvU+NmI2az5w8vw 98OmX7G0OV9snxMW+6cyNqBrVFTu33VVNzz9pnqNCHxGvj5dL5ltP160JV2zw2bUwJBYsgYQ WfyJJIM7l3gv5ZS3DGqaGIm9gOK1ANxfrR5PgPzvI9VxDhlr2juEVMZYAqPLEJe+SSxbwLoz BcFCNdDAyXcaAzXsx/E02YWm1hIWNRxanAe7Vlg7OL+gvLpdtrYCMg28PNqKNyrQ87LQ49O9 50IIZDOtNFeR0FGucjcLPdS9PiEqCoH7/waJxWp6ydJ+g4OYRBYNM0EmMgy1N85JJrV1mi5i Message-ID: <0545745c-a6ee-b6d3-09ac-a8c74295de75@yandex.ru> Date: Mon, 26 Aug 2019 11:31:20 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <25f37482-80b7-3aea-2c67-20faedadf429@grosbein.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4bFNlAvtUTZYhicmzK2qo2ePaDhEWTmAC" X-Rspamd-Queue-Id: 46H5051ft6z45Xv X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yandex.ru header.s=mail header.b=TMKI4TYC; dmarc=pass (policy=none) header.from=yandex.ru; spf=pass (mx1.freebsd.org: domain of bu7cher@yandex.ru designates 2a02:6b8:0:1472:2741:0:8b7:100 as permitted sender) smtp.mailfrom=bu7cher@yandex.ru X-Spamd-Result: default: False [-6.19 / 15.00]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a02:6b8:0:1000::/52]; FREEMAIL_FROM(0.00)[yandex.ru]; HAS_ATTACHMENT(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[yandex.ru:+]; DMARC_POLICY_ALLOW(-0.50)[yandex.ru,none]; NEURAL_HAM_SHORT(-0.99)[-0.994,0]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[0.0.1.0.7.b.8.0.0.0.0.0.1.4.7.2.2.7.4.1.0.0.0.0.8.b.6.0.2.0.a.2.list.dnswl.org : 127.0.5.1]; ASN(0.00)[asn:13238, ipnet:2a02:6b8::/32, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yandex.ru.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[yandex.ru:s=mail]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; IP_SCORE(0.00)[ip: (-8.84), ipnet: 2a02:6b8::/32(-4.63), asn: 13238(-3.71), country: RU(0.01)]; FREEMAIL_ENVFROM(0.00)[yandex.ru]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 08:34:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4bFNlAvtUTZYhicmzK2qo2ePaDhEWTmAC Content-Type: multipart/mixed; boundary="UivDHSUw0OzG4m32Z0Wvvq7hn3OVkj6c9"; protected-headers="v1" From: "Andrey V. Elsukov" To: Eugene Grosbein , Victor Gamov , freebsd-net@freebsd.org Message-ID: <0545745c-a6ee-b6d3-09ac-a8c74295de75@yandex.ru> Subject: Re: finding optimal ipfw strategy References: <4ff39c8f-341c-5d72-1b26-6558c57bff8d@grosbein.net> <270233d9-fcdb-fee9-2557-c2d1ec7bf9e6@yandex.ru> <25f37482-80b7-3aea-2c67-20faedadf429@grosbein.net> In-Reply-To: <25f37482-80b7-3aea-2c67-20faedadf429@grosbein.net> --UivDHSUw0OzG4m32Z0Wvvq7hn3OVkj6c9 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 26.08.2019 03:30, Eugene Grosbein wrote: >>> Also, you should use old table numbers instead of new symbolic table = names >>> when you have many rules checking for interface names and much traffi= c >>> because checks for numbered tables are slightly more efficient. >>> You may use symbolic names still at source level: >> >> There isn't any old tables, all tables have symbolic names. Even when >> you are creating "table(1)", its name is converted into symbolic name.= >=20 > Yes, and this code path is slightly more efficient. A bit. I have not any performance measurements, but this code is for compatibility and it has more checks to implement this compatibility. So, I doubt it is more efficient :) Internally all symbolic names are mapped into indexes and there should not be any performance impact on packets processing. --=20 WBR, Andrey V. Elsukov --UivDHSUw0OzG4m32Z0Wvvq7hn3OVkj6c9-- --4bFNlAvtUTZYhicmzK2qo2ePaDhEWTmAC 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 - https://www.enigmail.net/ iQEzBAEBCAAdFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAl1jmNgACgkQAcXqBBDI oXqkNQf9GfZJ16hv+7jIRDkylfxkjy/01nT2X6b+wfP7JpbRFXzoPdRE9H2Y8uQN kfLDg9QOjxuVBHJAcpMEeKjEA5Z78V1ZiQym0X/kmbhfvx13vZLqE9fWRwE6PPBb 2l5QdmGNPAeayNEDSL4aEOjcd4P1cIpngIvB2JbqWHEB2uBJritDBAwYSZqvArtJ yGKoiRrhKTFlIqUaZks/mOol9OGBB4adrCLxIsYOt5ep7hXK0IkalgoTk8c8iylh QUvsZ5laiwdCYNMX3SJaL+yVoUk10fk/zVvC8T1i9lC5RSB/htbQ0Oz19drMX1GZ 1jXjWEgxqcgFPOs+dd8bcB+vGT6YSQ== =E92W -----END PGP SIGNATURE----- --4bFNlAvtUTZYhicmzK2qo2ePaDhEWTmAC-- From owner-freebsd-net@freebsd.org Mon Aug 26 16:25:39 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1F4F5DF774 for ; Mon, 26 Aug 2019 16:25:39 +0000 (UTC) (envelope-from vit@otcnet.ru) Received: from mail.otcnet.ru (mail.otcnet.ru [194.190.78.3]) by mx1.freebsd.org (Postfix) with ESMTP id 46HHRk06Gkz4cTD for ; Mon, 26 Aug 2019 16:25:37 +0000 (UTC) (envelope-from vit@otcnet.ru) Received: from Victors-MacBook-Air-2.local (unknown [194.190.78.9]) by mail.otcnet.ru (Postfix) with ESMTPSA id EF71789C2F; Mon, 26 Aug 2019 19:25:28 +0300 (MSK) Subject: Re: finding optimal ipfw strategy To: Eugene Grosbein , freebsd-net@freebsd.org References: <4ff39c8f-341c-5d72-1b26-6558c57bff8d@grosbein.net> From: Victor Gamov Organization: OTCnet Message-ID: Date: Mon, 26 Aug 2019 19:25:27 +0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <4ff39c8f-341c-5d72-1b26-6558c57bff8d@grosbein.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 46HHRk06Gkz4cTD X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of vit@otcnet.ru designates 194.190.78.3 as permitted sender) smtp.mailfrom=vit@otcnet.ru X-Spamd-Result: default: False [-2.56 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.990,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.otcnet.ru]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[otcnet.ru]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.38)[-0.375,0]; RCPT_COUNT_TWO(0.00)[2]; IP_SCORE(0.00)[country: RU(0.01)]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:50822, ipnet:194.190.78.0/24, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 16:25:39 -0000 On 24/08/2019 22:34, Eugene Grosbein wrote: > 25.08.2019 1:13, Victor Gamov wrote: > >> I have nonstandard network task for my FreeBSD box: >> many VLANs bridged together via bridge interface and specific multicast traffic must be send >> from one VLAN to many (but not all) other VLANs. > > It is quite standard filtering bridge :-) Hi All More general question about my current config. I have about 200Mbit input multicasts which bridged and filtered later (about 380 Mbit bridged if trafshow does not lie me :-) ) My FreeBSD box (12.0-STABLE r348449 GENERIC amd64) has one "Intel(R) Xeon(R) CPU E31270 @ 3.40GHz" and 4-ports "Intel(R) PRO/1000 PCI-Express Network Driver". HT disabled and traffic mainly income via igb0 and out both via igb0 and igb2. About 30 VLANs now active some at igb0 and some at igb2. And I have following `top` stat: ===== CPU 0: 0.0% user, 0.0% nice, 80.5% system, 0.0% interrupt, 19.5% idle CPU 1: 0.0% user, 0.0% nice, 34.1% system, 0.0% interrupt, 65.9% idle CPU 2: 0.0% user, 0.0% nice, 17.1% system, 0.0% interrupt, 82.9% idle CPU 3: 0.0% user, 0.0% nice, 46.3% system, 0.0% interrupt, 53.7% idle ===== Also `vmstat -i |grep igb`: ===== irq264: igb0:rxq0 9310734762 5471 irq265: igb0:rxq1 10186691956 5985 irq266: igb0:rxq2 8190475727 4812 irq267: igb0:rxq3 10063786697 5913 irq268: igb0:aq 34 0 irq273: igb1:aq 1 0 irq274: igb2:rxq0 11010248236 6469 irq275: igb2:rxq1 10843712062 6371 irq276: igb2:rxq2 8810194905 5177 irq277: igb2:rxq3 10975949272 6449 irq278: igb2:aq 10 0 irq283: igb3:aq 1 0 ===== Is it possible to get CPU load about 30% at this config after ipfw optimization? Or may be main bottleneck is not ipfw-specific? -- CU, Victor Gamov From owner-freebsd-net@freebsd.org Mon Aug 26 16:48:10 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5EDDADFD92 for ; Mon, 26 Aug 2019 16:48:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 46HHxk1tlDz4dY5 for ; Mon, 26 Aug 2019 16:48:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 3EE20DFD91; Mon, 26 Aug 2019 16:48:10 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3EAA8DFD90 for ; Mon, 26 Aug 2019 16:48:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46HHxk0zcyz4dY3 for ; Mon, 26 Aug 2019 16:48:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 009988FF6 for ; Mon, 26 Aug 2019 16:48:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x7QGm9fm045169 for ; Mon, 26 Aug 2019 16:48:09 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x7QGm9lI045168 for net@FreeBSD.org; Mon, 26 Aug 2019 16:48:09 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 240023] netmap lb pointer out of bounds on ixgbe Date: Mon, 26 Aug 2019 16:48:09 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.3-RELEASE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: maware@ucsc.edu X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@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.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 16:48:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D240023 --- Comment #5 from mike --- This is the binary build of 11.2p9 (working) and 11.3p2 (non working) with netmap and ixgbe built in to kernel. Nic is 82599 (intel x520). Using Bro/Z= eek 2.6.3 with bro-netmap plugin. Issue seems to really trigger once it starts pulling packets from the buffers which seems to trigger the out of bounds pointer.=20 Nic output in dmesg: ix2: po= rt 0x8020-0x803f mem 0xca080000-0xca0fffff,0xca104000-0xca107fff irq 64 at dev= ice 0.0 numa-domain 1 on pci21 ix2: Using MSI-X interrupts with 17 vectors ix2: Ethernet address: ac:1f:6b:2d:f2:3c ix2: PCI Express Bus: Speed 5.0GT/s Width x8 ix2: netmap queues/slots: TX 16/4096, RX 16/4096 ix2: permanently promiscuous mode enabled Please let me know anything else I can include to help. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Aug 26 17:15:25 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 954CCE0D08 for ; Mon, 26 Aug 2019 17:15:25 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (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 46HJY83qvyz4gL1 for ; Mon, 26 Aug 2019 17:15:23 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id x7QHFGMl038833 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 26 Aug 2019 17:15:18 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: vit@otcnet.ru Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id x7QHF7M1078165 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 27 Aug 2019 00:15:07 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: finding optimal ipfw strategy To: Victor Gamov , freebsd-net@freebsd.org References: <4ff39c8f-341c-5d72-1b26-6558c57bff8d@grosbein.net> From: Eugene Grosbein Message-ID: Date: Tue, 27 Aug 2019 00:15:01 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -0.0 SPF_PASS SPF: sender matches SPF record * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 46HJY83qvyz4gL1 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-4.48 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_PERMFAIL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.98)[-0.979,0]; IP_SCORE(-1.40)[ip: (-3.24), ipnet: 2a01:4f8::/29(-1.96), asn: 24940(-1.79), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 17:15:25 -0000 26.08.2019 23:25, Victor Gamov wrote: > More general question about my current config. I have about 200Mbit input multicasts which bridged and filtered later (about 380 Mbit bridged if trafshow does not lie me :-) ) Don't trust trafshow. Use: systat -ifstat 1 > My FreeBSD box (12.0-STABLE r348449 GENERIC amd64) has one "Intel(R) Xeon(R) CPU E31270 @ 3.40GHz" and 4-ports "Intel(R) PRO/1000 PCI-Express Network Driver". HT disabled and traffic mainly income via igb0 and out both via igb0 and igb2. About 30 VLANs now active some at igb0 and some at igb2. > > > And I have following `top` stat: > ===== > CPU 0: 0.0% user, 0.0% nice, 80.5% system, 0.0% interrupt, 19.5% idle > CPU 1: 0.0% user, 0.0% nice, 34.1% system, 0.0% interrupt, 65.9% idle > CPU 2: 0.0% user, 0.0% nice, 17.1% system, 0.0% interrupt, 82.9% idle > CPU 3: 0.0% user, 0.0% nice, 46.3% system, 0.0% interrupt, 53.7% idle > ===== > > Also `vmstat -i |grep igb`: > ===== > irq264: igb0:rxq0 9310734762 5471 > irq265: igb0:rxq1 10186691956 5985 > irq266: igb0:rxq2 8190475727 4812 > irq267: igb0:rxq3 10063786697 5913 > irq268: igb0:aq 34 0 > irq273: igb1:aq 1 0 > irq274: igb2:rxq0 11010248236 6469 > irq275: igb2:rxq1 10843712062 6371 > irq276: igb2:rxq2 8810194905 5177 > irq277: igb2:rxq3 10975949272 6449 > irq278: igb2:aq 10 0 > irq283: igb3:aq 1 0 > ===== > > > Is it possible to get CPU load about 30% at this config after ipfw optimization? Or may be main bottleneck is not ipfw-specific? You won't know until you try and nobody can tell. Too many variables. And you better compare it with 11.3 because 12.0 may have some unsolved preformance regressions. From owner-freebsd-net@freebsd.org Mon Aug 26 21:56:20 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9F440E61A9 for ; Mon, 26 Aug 2019 21:56:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 46HQnJ3nt6z3y5X for ; Mon, 26 Aug 2019 21:56:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 8018DE61A8; Mon, 26 Aug 2019 21:56:20 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7FDB1E61A7 for ; Mon, 26 Aug 2019 21:56:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46HQnJ2p9xz3y5W for ; Mon, 26 Aug 2019 21:56:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 5678BCB88 for ; Mon, 26 Aug 2019 21:56:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x7QLuKVp084143 for ; Mon, 26 Aug 2019 21:56:20 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x7QLuKtg084142 for net@FreeBSD.org; Mon, 26 Aug 2019 21:56:20 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 240135] Correctness issue in IPv6 extension headers input processing routines Date: Mon, 26 Aug 2019 21:56:20 +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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: cem@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 21:56:20 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D240135 Conrad Meyer changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cem@freebsd.org Assignee|bugs@FreeBSD.org |net@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Tue Aug 27 01:15:47 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 659B9C2D5C for ; Tue, 27 Aug 2019 01:15:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 46HWCR1Cw6z48jy for ; Tue, 27 Aug 2019 01:15:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 25942C2D5B; Tue, 27 Aug 2019 01:15:47 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 25582C2D5A for ; Tue, 27 Aug 2019 01:15:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46HWCQ6mHWz48jx for ; Tue, 27 Aug 2019 01:15:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id CA6A4F078 for ; Tue, 27 Aug 2019 01:15:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x7R1FkVw079712 for ; Tue, 27 Aug 2019 01:15:46 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x7R1FkFZ079711 for net@FreeBSD.org; Tue, 27 Aug 2019 01:15:46 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 240137] Multicast source blocking using IP_BLOCK_SOURCE not working? Date: Tue, 27 Aug 2019 01:15:41 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: glewis@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter attachments.mimetype attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 01:15:47 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D240137 Bug ID: 240137 Summary: Multicast source blocking using IP_BLOCK_SOURCE not working? Product: Base System Version: 12.0-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: net@FreeBSD.org Reporter: glewis@FreeBSD.org Attachment #206944 text/plain mime type: Created attachment 206944 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D206944&action= =3Dedit Test program While testing Java on FreeBSD, I noticed a test failure due to multicast so= urce blocking not working. I can supply the Java code if that would be helpful,= but I've boiled down the test into some C code which does the same thing which I think will be more useful. The test code will attempt to first send and receive a multicast packet. It will then block the source and try it again. This should result in the sec= ond receive just blocking since no packet should come through. However, on Fre= eBSD it does. The same test program on Linux behaves as expected (i.e., the sec= ond receive blocks). Please let me know if the test program is doing something incorrectly on FreeBSD. This is based on my reading of the section of ip(4) regarding IP_BLOCK_SOURCE and testing on Linux. Note that I've tested the code on both 11.3 and 12.0, with the same result. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Tue Aug 27 07:27:09 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5F8D3CD721 for ; Tue, 27 Aug 2019 07:27:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 46HgRx1sBLz4WmY for ; Tue, 27 Aug 2019 07:27:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 3DABCCD720; Tue, 27 Aug 2019 07:27:09 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3B49ECD71F for ; Tue, 27 Aug 2019 07:27:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46HgRx0kc0z4WmX for ; Tue, 27 Aug 2019 07:27:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id EF3B31B3F9 for ; Tue, 27 Aug 2019 07:27:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x7R7R8qV025597 for ; Tue, 27 Aug 2019 07:27:08 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x7R7R8G8025596 for net@FreeBSD.org; Tue, 27 Aug 2019 07:27:08 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 240144] ipnat: redirect (rdr) rule does not work Date: Tue, 27 Aug 2019 07:27:08 +0000 X-Bugzilla-Reason: CC AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.0-STABLE X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: product version assigned_to keywords component bug_status short_desc cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 07:27:09 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D240144 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Product|Ports & Packages |Base System Version|Latest |12.0-STABLE Assignee|ports-bugs@FreeBSD.org |net@FreeBSD.org Keywords| |needs-qa Component|Individual Port(s) |kern Status|New |Open Summary|Ipnat.rules rdr & |ipnat: redirect (rdr) rule | |does not work CC| |net@FreeBSD.org --=20 You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Tue Aug 27 07:27:17 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A2896CD753 for ; Tue, 27 Aug 2019 07:27:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 46HgS52rhmz4Wqd for ; Tue, 27 Aug 2019 07:27:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 618CCCD751; Tue, 27 Aug 2019 07:27:17 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5F1FBCD74D for ; Tue, 27 Aug 2019 07:27:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46HgS517pHz4WqZ for ; Tue, 27 Aug 2019 07:27:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 08CA81B3FD for ; Tue, 27 Aug 2019 07:27:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x7R7RGXI025737 for ; Tue, 27 Aug 2019 07:27:16 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x7R7RGKM025736 for net@FreeBSD.org; Tue, 27 Aug 2019 07:27:16 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 240144] ipnat: redirect (rdr) rule does not work Date: Tue, 27 Aug 2019 07:27:17 +0000 X-Bugzilla-Reason: CC AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.0-STABLE X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: rep_platform Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 07:27:17 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D240144 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Hardware|Any |amd64 --=20 You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Tue Aug 27 07:29:38 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id ABDEFCD978 for ; Tue, 27 Aug 2019 07:29:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 46HgVp4B3Hz4X1J for ; Tue, 27 Aug 2019 07:29:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 8F8A6CD977; Tue, 27 Aug 2019 07:29:38 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8F534CD976 for ; Tue, 27 Aug 2019 07:29:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46HgVp3JKwz4X1H for ; Tue, 27 Aug 2019 07:29:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 5279C1B40B for ; Tue, 27 Aug 2019 07:29:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x7R7TcxE028880 for ; Tue, 27 Aug 2019 07:29:38 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x7R7Tctn028879 for net@FreeBSD.org; Tue, 27 Aug 2019 07:29:38 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 240023] netmap lb pointer out of bounds on ixgbe Date: Tue, 27 Aug 2019 07:29:37 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.3-RELEASE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: see_also Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 07:29:38 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D240023 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://github.com/luigiriz | |zo/netmap/issues/600 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Tue Aug 27 07:31:43 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D1488CDAD1 for ; Tue, 27 Aug 2019 07:31:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 46HgYC5FWfz4X9y for ; Tue, 27 Aug 2019 07:31:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id B4271CDAD0; Tue, 27 Aug 2019 07:31:43 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B3EB9CDACE for ; Tue, 27 Aug 2019 07:31:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46HgYC4Gr8z4X9v for ; Tue, 27 Aug 2019 07:31:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 760EF1B475 for ; Tue, 27 Aug 2019 07:31:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x7R7Vha1038669 for ; Tue, 27 Aug 2019 07:31:43 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x7R7Vhf9038668 for net@FreeBSD.org; Tue, 27 Aug 2019 07:31:43 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 238796] ipfilter: failure to detect the same rules when arguments ordered differently Date: Tue, 27 Aug 2019 07:31:43 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: cy@FreeBSD.org X-Bugzilla-Flags: mfc-stable11+ mfc-stable12+ X-Bugzilla-Changed-Fields: flagtypes.name Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 07:31:43 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238796 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|mfc-stable11?, |mfc-stable11+, |mfc-stable12? |mfc-stable12+ --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Tue Aug 27 07:33:31 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E0142CDD0E for ; Tue, 27 Aug 2019 07:33:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 46HgbH5dxQz4XQW for ; Tue, 27 Aug 2019 07:33:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id C1963CDD0D; Tue, 27 Aug 2019 07:33:31 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C15A4CDD0C for ; Tue, 27 Aug 2019 07:33:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46HgbH4j0dz4XQV for ; Tue, 27 Aug 2019 07:33:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 84AC61B5E7 for ; Tue, 27 Aug 2019 07:33:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x7R7XVcs045192 for ; Tue, 27 Aug 2019 07:33:31 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x7R7XVcs045191 for net@FreeBSD.org; Tue, 27 Aug 2019 07:33:31 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 239982] IPv6 network stack panics since upgrading to 11.3 Date: Tue, 27 Aug 2019 07:33:30 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.3-RELEASE X-Bugzilla-Keywords: crash, needs-qa, regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status keywords Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 07:33:31 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D239982 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Open Keywords| |crash, needs-qa --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Tue Aug 27 07:33:50 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 551BDCDD8A for ; Tue, 27 Aug 2019 07:33:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 46Hgbf1fYGz4XVK for ; Tue, 27 Aug 2019 07:33:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 38BCBCDD89; Tue, 27 Aug 2019 07:33:50 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 38841CDD88 for ; Tue, 27 Aug 2019 07:33:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46Hgbf0dqpz4XVH for ; Tue, 27 Aug 2019 07:33:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id ED49A1B5E9 for ; Tue, 27 Aug 2019 07:33:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x7R7Xnn2045567 for ; Tue, 27 Aug 2019 07:33:49 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x7R7XnSQ045564 for net@FreeBSD.org; Tue, 27 Aug 2019 07:33:49 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 240144] ipnat: redirect (rdr) rule does not work Date: Tue, 27 Aug 2019 07:33:50 +0000 X-Bugzilla-Reason: CC AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.0-STABLE X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: Z462vasa@mail.lviv.ua X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@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.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 07:33:50 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D240144 --- Comment #1 from Aleks --- work --=20 You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Tue Aug 27 13:03:34 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0C2B3D56F0 for ; Tue, 27 Aug 2019 13:03:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 46Hpw56cwTz3MRp for ; Tue, 27 Aug 2019 13:03:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id E179BD56EF; Tue, 27 Aug 2019 13:03:33 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E1405D56EE for ; Tue, 27 Aug 2019 13:03:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46Hpw55dYYz3MRm for ; Tue, 27 Aug 2019 13:03:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id A344C1F1F9 for ; Tue, 27 Aug 2019 13:03:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x7RD3XHp098862 for ; Tue, 27 Aug 2019 13:03:33 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x7RD3XRB098861 for net@FreeBSD.org; Tue, 27 Aug 2019 13:03:33 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 239240] igb: TX(2) desc avail = 1024, pidx = 0 messages appear when the network card loses ethernet link Date: Tue, 27 Aug 2019 13:03:33 +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: 12.0-RELEASE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: webmaster@rgcwireless.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 13:03:34 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D239240 John Delano changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |webmaster@rgcwireless.com --- Comment #2 from John Delano --- I am seeing the problem as well on RELEASE-p10. It is affecting IGB and IX interfaces. The problem occurs when I disconnect an active network cable. A= fter about 10 minutes, the error messages begin. Nothing other than a reboot will restore the interface to working after this occurs. Connecting the cable back to the interface, ifconfig still reports the cable status as "no carrier". I am going to try to make a script to down/up all the interfaces according = to the interface connection status to mitigate this until a fix is available. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Tue Aug 27 14:24:25 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AE0E6D7110 for ; Tue, 27 Aug 2019 14:24:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 46HrjP4DPwz3wxc for ; Tue, 27 Aug 2019 14:24:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 911DDD710F; Tue, 27 Aug 2019 14:24:25 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 90DFCD710E for ; Tue, 27 Aug 2019 14:24:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46HrjP3Hc7z3wxb for ; Tue, 27 Aug 2019 14:24:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 53E1F200CE for ; Tue, 27 Aug 2019 14:24:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x7REOPqI008994 for ; Tue, 27 Aug 2019 14:24:25 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x7REOPqK008993 for net@FreeBSD.org; Tue, 27 Aug 2019 14:24:25 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 239240] igb: TX(2) desc avail = 1024, pidx = 0 messages appear when the network card loses ethernet link Date: Tue, 27 Aug 2019 14:24:25 +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: 12.0-RELEASE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: webmaster@rgcwireless.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@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.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 14:24:25 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D239240 --- Comment #3 from John Delano --- I have discovered that if I unplug the ethernet cable, ifconfig still shows= the cable is "status: active"! FreeBSD 11 immediately goes to "status: no carrier" when I do the same. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Tue Aug 27 17:17:03 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C665BDAAC7 for ; Tue, 27 Aug 2019 17:17:03 +0000 (UTC) (envelope-from vit@otcnet.ru) Received: from mail.otcnet.ru (mail.otcnet.ru [194.190.78.3]) by mx1.freebsd.org (Postfix) with ESMTP id 46HwXZ5RB5z46Xn for ; Tue, 27 Aug 2019 17:17:02 +0000 (UTC) (envelope-from vit@otcnet.ru) Received: from Victors-MacBook-Air-2.local (unknown [195.91.148.145]) by mail.otcnet.ru (Postfix) with ESMTPSA id E5CF789D90; Tue, 27 Aug 2019 20:16:54 +0300 (MSK) Subject: Re: finding optimal ipfw strategy To: Eugene Grosbein , freebsd-net@freebsd.org References: <4ff39c8f-341c-5d72-1b26-6558c57bff8d@grosbein.net> From: Victor Gamov Organization: OTCnet Message-ID: <7f1d41d7-3d6c-a918-ea1a-6336caaae151@otcnet.ru> Date: Tue, 27 Aug 2019 20:16:54 +0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 46HwXZ5RB5z46Xn X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of vit@otcnet.ru designates 194.190.78.3 as permitted sender) smtp.mailfrom=vit@otcnet.ru X-Spamd-Result: default: False [-2.57 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.989,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.otcnet.ru]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[otcnet.ru]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.38)[-0.384,0]; RCPT_COUNT_TWO(0.00)[2]; IP_SCORE(0.00)[country: RU(0.01)]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:50822, ipnet:194.190.78.0/24, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 17:17:03 -0000 On 26/08/2019 20:15, Eugene Grosbein wrote: > 26.08.2019 23:25, Victor Gamov wrote: > >> More general question about my current config. I have about >> 200Mbit input multicasts which bridged and filtered later (about >> 380 Mbit bridged if trafshow does not lie me :-) ) > > Don't trust trafshow. Use: systat -ifstat 1 This! systat show me more real picture: 750Mbit in, 650 Mbit out via bridge >> Is it possible to get CPU load about 30% at this config after ipfw >> optimization? Or may be main bottleneck is not ipfw-specific? > > You won't know until you try and nobody can tell. Too many > variables. And you better compare it with 11.3 because 12.0 may have > some unsolved preformance regressions. I see. I will try 11.3 later. Now after output optimization as Eugene recommended one core load decreased from 88 to 77 percents. But many loads decreased when unused rules removed. Now I'll try to optimize input rules too like ===== table All_Ifaces create type iface table All_Ifaces add vlan10 20010 table All_Ifaces add vlan20 20020 table All_Ifaces add vlan30 20030 12000 skipto tablearg ip from any to any in recv table(All_Ifaces) 20010 allow udp from src1 to mcast1 in recv via vlan10 20011 deny ip from any to any 20020 allow udp from src2 to mcast2 in recv via vlan20 20021 deny ip from any to any ===== -- CU, Victor Gamov From owner-freebsd-net@freebsd.org Tue Aug 27 18:06:30 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 978F7DB9FD for ; Tue, 27 Aug 2019 18:06:30 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward104j.mail.yandex.net (forward104j.mail.yandex.net [5.45.198.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46Hxdd1sPPz49Jb for ; Tue, 27 Aug 2019 18:06:28 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from mxback29g.mail.yandex.net (mxback29g.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:329]) by forward104j.mail.yandex.net (Yandex) with ESMTP id CD60B4A01B7; Tue, 27 Aug 2019 21:06:25 +0300 (MSK) Received: from smtp3o.mail.yandex.net (smtp3o.mail.yandex.net [2a02:6b8:0:1a2d::27]) by mxback29g.mail.yandex.net (nwsmtp/Yandex) with ESMTP id mgTQ0uvA3K-6PAKvaPS; Tue, 27 Aug 2019 21:06:25 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1566929185; bh=ZAP4MojBQDbq6iBPdWnO71KRdPj8pmXjXdB0G6eVjDw=; h=In-Reply-To:From:Date:References:To:Subject:Message-ID; b=AKg4V13bX/dSEGBbL2Kt/UgSh/La6n9ALA4drAUo8OnKj9ax/RUhS3igKfa8prkao 1rfpnphFUywTdFULBPq2UkK4Ek7Kk0ioqPahT8LQlFARMUhtsS8chly5V7/0n1fAk2 bXQwVDBBkMJDAjmY9a1PULqW7NkQmmUtg2rLWblE= Received: by smtp3o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id G63pF4Vsbn-6PGO7vxW; Tue, 27 Aug 2019 21:06:25 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) Subject: Re: finding optimal ipfw strategy To: Victor Gamov , Eugene Grosbein , freebsd-net@freebsd.org References: <4ff39c8f-341c-5d72-1b26-6558c57bff8d@grosbein.net> From: "Andrey V. Elsukov" Openpgp: id=E6591E1B41DA1516F0C9BC0001C5EA0410C8A17A Autocrypt: addr=bu7cher@yandex.ru; prefer-encrypt=mutual; keydata= mQENBEwBF1kBCADB9sXFhBEUy8qQ4X63Y8eBatYMHGEFWN9ypS5lI3RE6qQW2EYbxNk7qUC5 21YIIS1mMFVBEfvR7J9uc7yaYgFCEb6Sce1RSO4ULN2mRKGHP3/Sl0ijZEjWHV91hY1YTHEF ZW/0GYinDf56sYpDDehaBF5wkWIo1+QK5nmj3vl0DIDCMNd7QEiWpyLVwECgLX2eOAXByT8B bCqVhJGcG6iFP7/B9Ll6uX5gb8thM9LM+ibwErDBVDGiOgvfxqidab7fdkh893IBCXa82H9N CNwnEtcgzh+BSKK5BgvPohFMgRwjti37TSxwLu63QejRGbZWSz3OK3jMOoF63tCgn7FvABEB AAG0JUFuZHJleSBWLiBFbHN1a292IDxidTdjaGVyQHlhbmRleC5ydT6JATgEEwECACIFAkwB F1kCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEAHF6gQQyKF6qmYIAI6ekfm1VA4T vqankI1ISE6ku4jV7UlpIQlEbE7/8n3Zd6teJ+pGOQhN5qk8QE7utdPdbktAzi+x7LIJVzUw 4TywZLXGrkP7VKYkfg6oyCGyzITghefQeJtr2TN4hYCkzPWpylkue8MtmqfZv/6royqwTbN+ +E09FQNvTgRUYJYTeQ1qOsxNRycwvw3dr2rOfuxShbzaHBB1pBIjGrMg8fC5pd65ACH5zuFV A0CoTNGMDrEZSfBkTW604UUHFFXeCoC3dwDZRKOWJ3GmMXns65Ai5YkA63BSHEE1Qle3VBhd cG1w0CB5FBV3pB27UVnf0jEbysrDqW4qN7XMRFSWNAy5AQ0ETAEXWQEIAJ2p6l9LBoqdH/0J PEFDY2t2gTvAuzz+8zs3R03dFuHcNbOwjvWCG0aOmVpAzkRa8egn5JB4sZaFUtKPYJEQ1Iu+ LUBwgvtXf4vWpzC67zs2dDuiW4LamH5p6xkTD61aHR7mCB3bg2TUjrDWn2Jt44cvoYxj3dz4 S49U1rc9ZPgD5axCNv45j72tggWlZvpefThP7xT1OlNTUqye2gAwQravXpZkl5JG4eOqJVIU X316iE3qso0iXRUtO7OseBf0PiVmk+wCahdreHOeOxK5jMhYkPKVn7z1sZiB7W2H2TojbmcK HZC22sz7Z/H36Lhg1+/RCnGzdEcjGc8oFHXHCxUAEQEAAYkBHwQYAQIACQUCTAEXWQIbDAAK CRABxeoEEMihegkYCAC3ivGYNe2taNm/4Nx5GPdzuaAJGKWksV+w9mo7dQvU+NmI2az5w8vw 98OmX7G0OV9snxMW+6cyNqBrVFTu33VVNzz9pnqNCHxGvj5dL5ltP160JV2zw2bUwJBYsgYQ WfyJJIM7l3gv5ZS3DGqaGIm9gOK1ANxfrR5PgPzvI9VxDhlr2juEVMZYAqPLEJe+SSxbwLoz BcFCNdDAyXcaAzXsx/E02YWm1hIWNRxanAe7Vlg7OL+gvLpdtrYCMg28PNqKNyrQ87LQ49O9 50IIZDOtNFeR0FGucjcLPdS9PiEqCoH7/waJxWp6ydJ+g4OYRBYNM0EmMgy1N85JJrV1mi5i Message-ID: Date: Tue, 27 Aug 2019 21:03:19 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="t4aIzluZvDmDHeKPHFtgv72lbWVPGkAP8" X-Rspamd-Queue-Id: 46Hxdd1sPPz49Jb X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yandex.ru header.s=mail header.b=AKg4V13b; dmarc=pass (policy=none) header.from=yandex.ru; spf=pass (mx1.freebsd.org: domain of bu7cher@yandex.ru designates 5.45.198.247 as permitted sender) smtp.mailfrom=bu7cher@yandex.ru X-Spamd-Result: default: False [-6.19 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yandex.ru]; R_SPF_ALLOW(-0.20)[+ip4:5.45.192.0/19]; HAS_ATTACHMENT(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[yandex.ru:+]; DMARC_POLICY_ALLOW(-0.50)[yandex.ru,none]; NEURAL_HAM_SHORT(-0.99)[-0.993,0]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[247.198.45.5.list.dnswl.org : 127.0.5.1]; ASN(0.00)[asn:13238, ipnet:5.45.192.0/18, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yandex.ru.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[yandex.ru:s=mail]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; IP_SCORE(0.00)[ipnet: 5.45.192.0/18(-4.81), asn: 13238(-3.71), country: RU(0.01)]; FREEMAIL_ENVFROM(0.00)[yandex.ru]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 18:06:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --t4aIzluZvDmDHeKPHFtgv72lbWVPGkAP8 Content-Type: multipart/mixed; boundary="eLoN6jvRA70jdKvRzdV2b1T5l5r22FWpQ"; protected-headers="v1" From: "Andrey V. Elsukov" To: Victor Gamov , Eugene Grosbein , freebsd-net@freebsd.org Message-ID: Subject: Re: finding optimal ipfw strategy References: <4ff39c8f-341c-5d72-1b26-6558c57bff8d@grosbein.net> In-Reply-To: --eLoN6jvRA70jdKvRzdV2b1T5l5r22FWpQ Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 26.08.2019 19:25, Victor Gamov wrote: > More general question about my current config.=C2=A0 I have about 200Mb= it > input multicasts which bridged and filtered later (about 380 Mbit > bridged if trafshow does not lie me :-) ) >=20 > My FreeBSD box (12.0-STABLE r348449 GENERIC=C2=A0 amd64)=C2=A0 has one = "Intel(R) > Xeon(R) CPU E31270 @ 3.40GHz"=C2=A0 and 4-ports=C2=A0 "Intel(R) PRO/100= 0 > PCI-Express Network Driver".=C2=A0 HT disabled and traffic mainly incom= e via > igb0 and out both via igb0 and igb2.=C2=A0 About 30 VLANs now active so= me at > igb0 and some at igb2. >=20 >=20 > And I have following `top` stat: > =3D=3D=3D=3D=3D > CPU 0:=C2=A0 0.0% user,=C2=A0 0.0% nice, 80.5% system,=C2=A0 0.0% inter= rupt, 19.5% idle > CPU 1:=C2=A0 0.0% user,=C2=A0 0.0% nice, 34.1% system,=C2=A0 0.0% inter= rupt, 65.9% idle > CPU 2:=C2=A0 0.0% user,=C2=A0 0.0% nice, 17.1% system,=C2=A0 0.0% inter= rupt, 82.9% idle > CPU 3:=C2=A0 0.0% user,=C2=A0 0.0% nice, 46.3% system,=C2=A0 0.0% inter= rupt, 53.7% idle > =3D=3D=3D=3D=3D This doesn't look like heavy ipfw load. E.g. this is top output from slightly loaded firewall (300Mbytes/s ~500kpps): last pid: 58184; load averages: 9.07, 8.98, 8.83 up 72+07:45:55 21:01:36 821 processes: 36 running, 680 sleeping, 105 waiting CPU 0: 0.0% user, 0.0% nice, 0.0% system, 28.1% interrupt, 71.9% idle= CPU 1: 0.0% user, 0.0% nice, 0.0% system, 33.6% interrupt, 66.4% idle= CPU 2: 0.0% user, 0.0% nice, 0.0% system, 28.9% interrupt, 71.1% idle= CPU 3: 0.0% user, 0.0% nice, 0.0% system, 27.3% interrupt, 72.7% idle= CPU 4: 0.0% user, 0.0% nice, 0.0% system, 21.1% interrupt, 78.9% idle= CPU 5: 0.0% user, 0.0% nice, 0.0% system, 26.6% interrupt, 73.4% idle= CPU 6: 0.0% user, 0.0% nice, 0.0% system, 28.1% interrupt, 71.9% idle= CPU 7: 0.0% user, 0.0% nice, 0.0% system, 21.1% interrupt, 78.9% idle= CPU 8: 0.0% user, 0.0% nice, 0.0% system, 35.2% interrupt, 64.8% idle= CPU 9: 0.0% user, 0.0% nice, 0.0% system, 29.7% interrupt, 70.3% idle= CPU 10: 0.0% user, 0.0% nice, 0.0% system, 27.3% interrupt, 72.7% idle= CPU 11: 0.0% user, 0.0% nice, 0.0% system, 19.5% interrupt, 80.5% idle= CPU 12: 0.0% user, 0.0% nice, 0.0% system, 32.8% interrupt, 67.2% idle= CPU 13: 0.0% user, 0.0% nice, 0.0% system, 34.4% interrupt, 65.6% idle= CPU 14: 0.0% user, 0.0% nice, 0.0% system, 29.7% interrupt, 70.3% idle= CPU 15: 0.0% user, 0.0% nice, 0.0% system, 26.6% interrupt, 73.4% idle= CPU 16: 0.0% user, 0.0% nice, 0.0% system, 28.9% interrupt, 71.1% idle= CPU 17: 0.0% user, 0.0% nice, 0.0% system, 34.4% interrupt, 65.6% idle= CPU 18: 0.0% user, 0.0% nice, 0.0% system, 36.7% interrupt, 63.3% idle= CPU 19: 0.0% user, 0.0% nice, 0.0% system, 21.9% interrupt, 78.1% idle= CPU 20: 0.0% user, 0.0% nice, 0.0% system, 21.1% interrupt, 78.9% idle= CPU 21: 0.0% user, 0.0% nice, 0.0% system, 32.0% interrupt, 68.0% idle= CPU 22: 0.0% user, 0.0% nice, 0.0% system, 33.6% interrupt, 66.4% idle= CPU 23: 0.0% user, 0.0% nice, 0.0% system, 26.6% interrupt, 73.4% idle= CPU 24: 0.0% user, 0.0% nice, 0.0% system, 21.9% interrupt, 78.1% idle= CPU 25: 0.0% user, 0.0% nice, 0.0% system, 21.1% interrupt, 78.9% idle= CPU 26: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle= CPU 27: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle= # pmcstat -S instructions -Tw1 PMC: [INSTR_RETIRED_ANY] Samples: 443074 (100.0%) , 0 unresolved Key: q =3D> exiting... %SAMP IMAGE FUNCTION CALLERS 39.2 kernel sched_idletd fork_exit 10.9 ipfw.ko ipfw_chk ipfw_check_packet 3.6 kernel cpu_search_lowest cpu_search_lowest 2.8 kernel lock_delay _mtx_lock_spin_cookie 2.5 kernel _rm_rlock in6_localip:1.3 pfil_run_hooks:0.6 2.2 kernel rn_match ta_lookup_radix:1.5 fib6_lookup_nh_basic:0.6 As you can see, when ipfw produces high load, interrupt column is more than system. --=20 WBR, Andrey V. Elsukov --eLoN6jvRA70jdKvRzdV2b1T5l5r22FWpQ-- --t4aIzluZvDmDHeKPHFtgv72lbWVPGkAP8 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 - https://www.enigmail.net/ iQEzBAEBCAAdFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAl1lcGcACgkQAcXqBBDI oXqHjAf/WcebHfqWh98HZQGOWchcfjl321Gvvw9+kJ9HCIB201ZQ7xzEXIDl8IST 5W8lMAHh4UkYqyd/Om9thL4T5lQCDO9jAw/B8A4VmQuheMY5dVvO2mGd2mk6+gH/ 7QHVVK/BU9r5tiX8oCXFEGBs6T3cZPT7HaWF4BLuFV0B0VRF7V9fH/XxgkLRzsLm nTVvAXjRekHuK5CXOI8kJBgwV0hA83GwnRGdwZaL33q/vQpWJRK6D1xHZ3477lg3 hykidpvwoQw1bJhR0LWtAAZ0CaDjv2SLCplDsG89ZmREsImWZmgU9DC1RiPdSgKb Bnv4joEkFEYXz8k87einnE2xHCsdbg== =GzyU -----END PGP SIGNATURE----- --t4aIzluZvDmDHeKPHFtgv72lbWVPGkAP8-- From owner-freebsd-net@freebsd.org Tue Aug 27 18:46:35 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 61318DC3B1 for ; Tue, 27 Aug 2019 18:46:35 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (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 46HyWt1tKxz4C0S for ; Tue, 27 Aug 2019 18:46:33 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id x7RIkGHO055171 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Aug 2019 18:46:22 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: bu7cher@yandex.ru Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id x7RIkAtM004145 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 28 Aug 2019 01:46:10 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: finding optimal ipfw strategy To: "Andrey V. Elsukov" , Victor Gamov , freebsd-net@freebsd.org References: <4ff39c8f-341c-5d72-1b26-6558c57bff8d@grosbein.net> From: Eugene Grosbein Message-ID: Date: Wed, 28 Aug 2019 01:46:03 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 46HyWt1tKxz4C0S X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-4.50 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_PERMFAIL(0.00)[]; NEURAL_HAM_SHORT(-0.97)[-0.975,0]; IP_SCORE(-1.43)[ip: (-3.35), ipnet: 2a01:4f8::/29(-1.97), asn: 24940(-1.80), country: DE(-0.01)]; FREEMAIL_TO(0.00)[yandex.ru]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 18:46:35 -0000 28.08.2019 1:03, Andrey V. Elsukov wrote: > As you can see, when ipfw produces high load, interrupt column is more > than system. Interrupt numbers higher than others generally mean that traffic is processed without netisr queueing mostly. That is expected for plain routing. I'm not sure if this would be same in case of bridging. Victor, do you have some non-default tuning in your /boot/loader.conf or /etc/sysctl.conf? If yes, could you show them? If not, you should try something like this. For loader.conf: hw.igb.rxd=4096 hw.igb.txd=4096 net.isr.bindthreads=1 net.isr.defaultqlimit=4096 #substitute total number of CPU cores in the system here net.isr.maxthreads=4 # EOF For /etc/sysctl.conf: dev.igb.0.rx_processing_limit=-1 dev.igb.1.rx_processing_limit=-1 net.inet.ip.intr_queue_maxlen=40960 And if you haven't already seen it, you may find useful my blog post (in Russian) https://dadv.livejournal.com/139170.html It's a bit old but still can give you some light. From owner-freebsd-net@freebsd.org Tue Aug 27 18:50:11 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 77933DC487 for ; Tue, 27 Aug 2019 18:50:11 +0000 (UTC) (envelope-from vit@otcnet.ru) Received: from mail.otcnet.ru (mail.otcnet.ru [194.190.78.3]) by mx1.freebsd.org (Postfix) with ESMTP id 46Hyc23yLMz4C6b for ; Tue, 27 Aug 2019 18:50:09 +0000 (UTC) (envelope-from vit@otcnet.ru) Received: from Victors-MacBook-Air-2.local (unknown [195.91.148.145]) by mail.otcnet.ru (Postfix) with ESMTPSA id 2961289DB5 for ; Tue, 27 Aug 2019 21:50:09 +0300 (MSK) Subject: Re: finding optimal ipfw strategy To: freebsd-net@freebsd.org References: <4ff39c8f-341c-5d72-1b26-6558c57bff8d@grosbein.net> From: Victor Gamov Organization: OTCnet Message-ID: Date: Tue, 27 Aug 2019 21:50:08 +0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 46Hyc23yLMz4C6b X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of vit@otcnet.ru designates 194.190.78.3 as permitted sender) smtp.mailfrom=vit@otcnet.ru X-Spamd-Result: default: False [-2.58 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.985,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.otcnet.ru]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; HAS_ORG_HEADER(0.00)[]; DMARC_NA(0.00)[otcnet.ru]; NEURAL_HAM_LONG(-1.00)[-0.996,0]; NEURAL_HAM_SHORT(-0.41)[-0.406,0]; IP_SCORE(0.00)[country: RU(0.01)]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:50822, ipnet:194.190.78.0/24, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 18:50:11 -0000 On 27/08/2019 21:03, Andrey V. Elsukov wrote: > On 26.08.2019 19:25, Victor Gamov wrote: >> More general question about my current config.  I have about 200Mbit >> input multicasts which bridged and filtered later (about 380 Mbit >> bridged if trafshow does not lie me :-) ) >> >> My FreeBSD box (12.0-STABLE r348449 GENERIC  amd64)  has one "Intel(R) >> Xeon(R) CPU E31270 @ 3.40GHz"  and 4-ports  "Intel(R) PRO/1000 >> PCI-Express Network Driver".  HT disabled and traffic mainly income via >> igb0 and out both via igb0 and igb2.  About 30 VLANs now active some at >> igb0 and some at igb2. >> >> >> And I have following `top` stat: >> ===== >> CPU 0:  0.0% user,  0.0% nice, 80.5% system,  0.0% interrupt, 19.5% idle >> CPU 1:  0.0% user,  0.0% nice, 34.1% system,  0.0% interrupt, 65.9% idle >> CPU 2:  0.0% user,  0.0% nice, 17.1% system,  0.0% interrupt, 82.9% idle >> CPU 3:  0.0% user,  0.0% nice, 46.3% system,  0.0% interrupt, 53.7% idle >> ===== > > This doesn't look like heavy ipfw load. Andrew, I have 0.0% interrupt but 80.5% system load. As this box hasn't any processes running (besides kernel + ntp + bsnmp) so I think this load produced by ipfw. Also I think this load source may be packets processing by bridge: get one packet, bridge it (copy/malloc?) into many interfaces, drop packets on unnecessary ifaces (free?) > E.g. this is top output from slightly loaded firewall (300Mbytes/s > ~500kpps): Yes, it's not a problem for 28 cores :-) I have 4 cores only and about 700Mbit in/out via bridge > last pid: 58184; load averages: 9.07, 8.98, 8.83 > up > 72+07:45:55 21:01:36 > 821 processes: 36 running, 680 sleeping, 105 waiting > CPU 0: 0.0% user, 0.0% nice, 0.0% system, 28.1% interrupt, 71.9% idle > CPU 27: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle > > # pmcstat -S instructions -Tw1 > PMC: [INSTR_RETIRED_ANY] Samples: 443074 (100.0%) , 0 unresolved > Key: q => exiting... > %SAMP IMAGE FUNCTION CALLERS > 39.2 kernel sched_idletd fork_exit > 10.9 ipfw.ko ipfw_chk ipfw_check_packet > 3.6 kernel cpu_search_lowest cpu_search_lowest > 2.8 kernel lock_delay _mtx_lock_spin_cookie > 2.5 kernel _rm_rlock in6_localip:1.3 pfil_run_hooks:0.6 > 2.2 kernel rn_match ta_lookup_radix:1.5 > fib6_lookup_nh_basic:0.6 > > As you can see, when ipfw produces high load, interrupt column is more > than system. -- С уважением, Гамов Виктор From owner-freebsd-net@freebsd.org Tue Aug 27 18:50:53 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4660BDC533 for ; Tue, 27 Aug 2019 18:50:53 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (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 46Hycr44qLz4CK8 for ; Tue, 27 Aug 2019 18:50:52 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id x7RIonWV055221 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Aug 2019 18:50:49 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: bu7cher@yandex.ru Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id x7RIojJ5004357 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 28 Aug 2019 01:50:45 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: finding optimal ipfw strategy To: "Andrey V. Elsukov" , Victor Gamov , freebsd-net@freebsd.org References: <4ff39c8f-341c-5d72-1b26-6558c57bff8d@grosbein.net> From: Eugene Grosbein Message-ID: <50b0748d-bf8a-4de9-58bf-800ddd4f9c27@grosbein.net> Date: Wed, 28 Aug 2019 01:50:38 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 46Hycr44qLz4CK8 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-4.53 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_PERMFAIL(0.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.979,0]; IP_SCORE(-1.45)[ip: (-3.46), ipnet: 2a01:4f8::/29(-1.97), asn: 24940(-1.80), country: DE(-0.01)]; FREEMAIL_TO(0.00)[yandex.ru]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 18:50:53 -0000 28.08.2019 1:46, Eugene Grosbein wrote: > 28.08.2019 1:03, Andrey V. Elsukov wrote: > >> As you can see, when ipfw produces high load, interrupt column is more >> than system. > > Interrupt numbers higher than others generally mean that traffic is processed without netisr queueing mostly. > That is expected for plain routing. I'm not sure if this would be same in case of bridging. > > Victor, do you have some non-default tuning in your /boot/loader.conf or /etc/sysctl.conf? > If yes, could you show them? If not, you should try something like this. For loader.conf: > > hw.igb.rxd=4096 > hw.igb.txd=4096 > net.isr.bindthreads=1 > net.isr.defaultqlimit=4096 > #substitute total number of CPU cores in the system here > net.isr.maxthreads=4 > # EOF Also, you should monitor interrupt numbers shown by "systat -vm 3" for igb* devices at hours of most load. If they approach 8000 limit but not exceed it, you may be suffering from this and should raise the limit with /boot/loader.conf: hw.igb.max_interrupt_rate=32000 From owner-freebsd-net@freebsd.org Tue Aug 27 19:20:05 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C1E5CDCE48 for ; Tue, 27 Aug 2019 19:20:05 +0000 (UTC) (envelope-from vit@otcnet.ru) Received: from mail.otcnet.ru (mail.otcnet.ru [194.190.78.3]) by mx1.freebsd.org (Postfix) with ESMTP id 46HzGY0gxtz4Dcs for ; Tue, 27 Aug 2019 19:20:04 +0000 (UTC) (envelope-from vit@otcnet.ru) Received: from Victors-MacBook-Air-2.local (unknown [195.91.148.145]) by mail.otcnet.ru (Postfix) with ESMTPSA id 99E3489DCC; Tue, 27 Aug 2019 22:20:03 +0300 (MSK) Subject: Re: finding optimal ipfw strategy To: Eugene Grosbein , "Andrey V. Elsukov" , freebsd-net@freebsd.org References: <4ff39c8f-341c-5d72-1b26-6558c57bff8d@grosbein.net> From: Victor Gamov Organization: OTCnet Message-ID: Date: Tue, 27 Aug 2019 22:20:02 +0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 46HzGY0gxtz4Dcs X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of vit@otcnet.ru designates 194.190.78.3 as permitted sender) smtp.mailfrom=vit@otcnet.ru X-Spamd-Result: default: False [-2.51 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.994,0]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.otcnet.ru:c]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[otcnet.ru]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.32)[-0.319,0]; IP_SCORE(0.00)[country: RU(0.01)]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:50822, ipnet:194.190.78.0/24, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 19:20:05 -0000 On 27/08/2019 21:46, Eugene Grosbein wrote: > 28.08.2019 1:03, Andrey V. Elsukov wrote: > >> As you can see, when ipfw produces high load, interrupt column is more >> than system. > > Interrupt numbers higher than others generally mean that traffic is processed without netisr queueing mostly. > That is expected for plain routing. I'm not sure if this would be same in case of bridging. > > Victor, do you have some non-default tuning in your /boot/loader.conf or /etc/sysctl.conf? > If yes, could you show them? Eugene, Nothing special. loader.conf ===== machdep.hyperthreading_allowed="0" net.inet.ip.fw.default_to_accept=1 ===== sysctl.conf ===== net.link.ether.ipfw=1 net.link.bridge.ipfw=1 net.link.bridge.ipfw_arp=1 net.link.bridge.pfil_member=1 net.inet.ip.fw.verbose_limit=100 net.inet.ip.fw.verbose=1 ===== `sysctl net.isr` ===== sysctl net.isr net.isr.numthreads: 1 net.isr.maxprot: 16 net.isr.defaultqlimit: 256 net.isr.maxqlimit: 10240 net.isr.bindthreads: 0 net.isr.maxthreads: 1 net.isr.dispatch: direct ===== I don't know about internals but I think high interrupt load is bad and it because NIC does not support per CPU-queue for example. > If not, you should try something like this. For loader.conf: Sorry, it's a production system and I can reboot it at the middle of October only. > #substitute total number of CPU cores in the system here > net.isr.maxthreads=4 > # EOF Is it ok for multicast? It's UDP traffic which must be ordered. I read 'maxthreads=1' used to keep TCP traffic ordered. > And if you haven't already seen it, you may find useful my blog post > (in Russian) https://dadv.livejournal.com/139170.html > > It's a bit old but still can give you some light. Yes, I read it already :-) Also some Calomel articles. I'll try to tune system at next reboot. The main question for myself now is "how is this architecture correct" and "how many traffic is possible to process". -- CU, Victor Gamov From owner-freebsd-net@freebsd.org Tue Aug 27 19:22:50 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 17DC9DD06F for ; Tue, 27 Aug 2019 19:22:50 +0000 (UTC) (envelope-from vit@otcnet.ru) Received: from mail.otcnet.ru (mail.otcnet.ru [194.190.78.3]) by mx1.freebsd.org (Postfix) with ESMTP id 46HzKh64Gfz4Dwv for ; Tue, 27 Aug 2019 19:22:48 +0000 (UTC) (envelope-from vit@otcnet.ru) Received: from Victors-MacBook-Air-2.local (unknown [195.91.148.145]) by mail.otcnet.ru (Postfix) with ESMTPSA id E2A9689DCC; Tue, 27 Aug 2019 22:22:47 +0300 (MSK) Subject: Re: finding optimal ipfw strategy To: Eugene Grosbein , "Andrey V. Elsukov" , freebsd-net@freebsd.org References: <4ff39c8f-341c-5d72-1b26-6558c57bff8d@grosbein.net> <50b0748d-bf8a-4de9-58bf-800ddd4f9c27@grosbein.net> From: Victor Gamov Organization: OTCnet Message-ID: <60d075ee-0d39-6606-ea5a-35e27818162a@otcnet.ru> Date: Tue, 27 Aug 2019 22:22:47 +0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <50b0748d-bf8a-4de9-58bf-800ddd4f9c27@grosbein.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 46HzKh64Gfz4Dwv X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of vit@otcnet.ru designates 194.190.78.3 as permitted sender) smtp.mailfrom=vit@otcnet.ru X-Spamd-Result: default: False [-2.55 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.989,0]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.otcnet.ru:c]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[otcnet.ru]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.36)[-0.361,0]; IP_SCORE(0.00)[country: RU(0.01)]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:50822, ipnet:194.190.78.0/24, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 19:22:50 -0000 On 27/08/2019 21:50, Eugene Grosbein wrote: > 28.08.2019 1:46, Eugene Grosbein wrote: > >> 28.08.2019 1:03, Andrey V. Elsukov wrote: >> >>> As you can see, when ipfw produces high load, interrupt column is more >>> than system. >> >> Interrupt numbers higher than others generally mean that traffic is processed without netisr queueing mostly. >> That is expected for plain routing. I'm not sure if this would be same in case of bridging. >> >> Victor, do you have some non-default tuning in your /boot/loader.conf or /etc/sysctl.conf? >> If yes, could you show them? If not, you should try something like this. For loader.conf: >> >> hw.igb.rxd=4096 >> hw.igb.txd=4096 >> net.isr.bindthreads=1 >> net.isr.defaultqlimit=4096 >> #substitute total number of CPU cores in the system here >> net.isr.maxthreads=4 >> # EOF > > Also, you should monitor interrupt numbers shown by "systat -vm 3" for igb* devices > at hours of most load. If they approach 8000 limit but not exceed it, > you may be suffering from this and should raise the limit with /boot/loader.conf: > > hw.igb.max_interrupt_rate=32000 It's about 5000-7000 per rxq -- CU, Victor Gamov From owner-freebsd-net@freebsd.org Tue Aug 27 19:26:48 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 252CCDD185 for ; Tue, 27 Aug 2019 19:26:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 46HzQJ0Dsmz4F3x for ; Tue, 27 Aug 2019 19:26:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 06242DD184; Tue, 27 Aug 2019 19:26:48 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 05EB4DD183 for ; Tue, 27 Aug 2019 19:26:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46HzQH6M3lz4F3v for ; Tue, 27 Aug 2019 19:26:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id B919A2379A for ; Tue, 27 Aug 2019 19:26:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x7RJQlQU027276 for ; Tue, 27 Aug 2019 19:26:47 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x7RJQlqj027275 for net@FreeBSD.org; Tue, 27 Aug 2019 19:26:47 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 236724] igb(4): Interfaces fail to switch active to inactive state Date: Tue, 27 Aug 2019 19:26:47 +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: 12.0-RELEASE X-Bugzilla-Keywords: IntelNetworking, needs-qa, regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: webmaster@rgcwireless.com X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: mfc-stable12? X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 19:26:48 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D236724 John Delano changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |webmaster@rgcwireless.com --- Comment #9 from John Delano --- This looks similar to what I reported in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D239240.=20 Unplugging the LAN cable results in not getting notification in ifconfig of= the link dropping. Furthermore, Leaving the cable unplugged for any extended ti= me makes the interface unusable throwing "igb0: TX(0) desc avail =3D 1024, pid= x =3D 0" or "ix0: TX(0) desc avail =3D 1024, pidx =3D 0".=20 The interface will not resume working until a reboot. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Tue Aug 27 19:59:30 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BCB69DE23D for ; Tue, 27 Aug 2019 19:59:30 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (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 46J0806Yhnz4GZS for ; Tue, 27 Aug 2019 19:59:28 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id x7RJxLUq056117 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Aug 2019 19:59:24 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: vit@otcnet.ru Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id x7RJxC3n007542 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 28 Aug 2019 02:59:12 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: finding optimal ipfw strategy To: Victor Gamov , "Andrey V. Elsukov" , freebsd-net@freebsd.org References: <4ff39c8f-341c-5d72-1b26-6558c57bff8d@grosbein.net> <50b0748d-bf8a-4de9-58bf-800ddd4f9c27@grosbein.net> <60d075ee-0d39-6606-ea5a-35e27818162a@otcnet.ru> From: Eugene Grosbein Message-ID: <032b67e1-5359-4f00-a449-26c43b70a467@grosbein.net> Date: Wed, 28 Aug 2019 02:59:05 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <60d075ee-0d39-6606-ea5a-35e27818162a@otcnet.ru> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 46J0806Yhnz4GZS X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-4.54 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_PERMFAIL(0.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.979,0]; IP_SCORE(-1.47)[ip: (-3.55), ipnet: 2a01:4f8::/29(-1.97), asn: 24940(-1.80), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 19:59:30 -0000 28.08.2019 2:22, Victor Gamov wrote: >> Also, you should monitor interrupt numbers shown by "systat -vm 3" for igb* devices >> at hours of most load. If they approach 8000 limit but not exceed it, >> you may be suffering from this and should raise the limit with /boot/loader.conf: >> >> hw.igb.max_interrupt_rate=32000 > > It's about 5000-7000 per rxq 7000 is quite close considering it is average for quite long period (a second or seconds). It can hit 8000 for some ticks easily in your case. You should raise the limit as soon as possible. I'd advise to double it upto 16000 first but if you cannot afford extra reboot better use 32000 as it's just fine for 1Gbps link. From owner-freebsd-net@freebsd.org Tue Aug 27 20:20:21 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E3D42DE984 for ; Tue, 27 Aug 2019 20:20:21 +0000 (UTC) (envelope-from vit@otcnet.ru) Received: from mail.otcnet.ru (mail.otcnet.ru [194.190.78.3]) by mx1.freebsd.org (Postfix) with ESMTP id 46J0c50RYYz4Hsr for ; Tue, 27 Aug 2019 20:20:20 +0000 (UTC) (envelope-from vit@otcnet.ru) Received: from Victors-MacBook-Air-2.local (unknown [195.91.148.145]) by mail.otcnet.ru (Postfix) with ESMTPSA id 6A4CD89DE4; Tue, 27 Aug 2019 23:20:18 +0300 (MSK) Subject: Re: finding optimal ipfw strategy To: Eugene Grosbein , "Andrey V. Elsukov" , freebsd-net@freebsd.org References: <4ff39c8f-341c-5d72-1b26-6558c57bff8d@grosbein.net> <50b0748d-bf8a-4de9-58bf-800ddd4f9c27@grosbein.net> <60d075ee-0d39-6606-ea5a-35e27818162a@otcnet.ru> <032b67e1-5359-4f00-a449-26c43b70a467@grosbein.net> From: Victor Gamov Organization: OTCnet Message-ID: <328ff261-f247-976f-ccba-e4b4e9098d8c@otcnet.ru> Date: Tue, 27 Aug 2019 23:20:16 +0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <032b67e1-5359-4f00-a449-26c43b70a467@grosbein.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 46J0c50RYYz4Hsr X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of vit@otcnet.ru designates 194.190.78.3 as permitted sender) smtp.mailfrom=vit@otcnet.ru X-Spamd-Result: default: False [-6.51 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+a:mail.otcnet.ru]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[otcnet.ru]; TO_DN_SOME(0.00)[]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.984,0]; IP_SCORE(-3.33)[ip: (-8.76), ipnet: 194.190.78.0/24(-4.38), asn: 50822(-3.50), country: RU(0.01)]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:50822, ipnet:194.190.78.0/24, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 20:20:21 -0000 On 27/08/2019 22:59, Eugene Grosbein wrote: > 28.08.2019 2:22, Victor Gamov wrote: > >>> Also, you should monitor interrupt numbers shown by "systat -vm 3" for igb* devices >>> at hours of most load. If they approach 8000 limit but not exceed it, >>> you may be suffering from this and should raise the limit with /boot/loader.conf: >>> >>> hw.igb.max_interrupt_rate=32000 >> >> It's about 5000-7000 per rxq > > 7000 is quite close considering it is average for quite long period (a second or seconds). > It can hit 8000 for some ticks easily in your case. Eugene, can you explain me what max_interrupt_rate means? Calomel explain it as "# maximum number of interrupts per second generated by single igb". So if I increase it then more irq per sec will be generated and more context switch produced. Why I need to increase it? > You should raise the limit as soon as possible. I'd advise to double it upto 16000 first > but if you cannot afford extra reboot better use 32000 as it's just fine for 1Gbps link. # sysctl hw.igb.max_interrupt_rate sysctl: unknown oid 'hw.igb.max_interrupt_rate' # Is it possible to set it at boot time only? -- CU, Victor Gamov From owner-freebsd-net@freebsd.org Tue Aug 27 20:31:06 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id ABA8FDEDC9 for ; Tue, 27 Aug 2019 20:31:06 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (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 46J0rT729Xz4JXQ for ; Tue, 27 Aug 2019 20:31:05 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id x7RKV1sw056413 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Aug 2019 20:31:02 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: vit@otcnet.ru Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id x7RKUrd5009730 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 28 Aug 2019 03:30:53 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: finding optimal ipfw strategy To: Victor Gamov , "Andrey V. Elsukov" , freebsd-net@freebsd.org References: <4ff39c8f-341c-5d72-1b26-6558c57bff8d@grosbein.net> From: Eugene Grosbein Message-ID: Date: Wed, 28 Aug 2019 03:30:46 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 46J0rT729Xz4JXQ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-4.56 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_PERMFAIL(0.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.976,0]; IP_SCORE(-1.48)[ip: (-3.64), ipnet: 2a01:4f8::/29(-1.97), asn: 24940(-1.80), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 20:31:06 -0000 28.08.2019 2:20, Victor Gamov wrote: >> Victor, do you have some non-default tuning in your /boot/loader.conf or /etc/sysctl.conf? >> If yes, could you show them? > Nothing special. > > loader.conf > ===== > machdep.hyperthreading_allowed="0" > net.inet.ip.fw.default_to_accept=1 > ===== > > sysctl.conf > ===== > net.link.ether.ipfw=1 > net.link.bridge.ipfw=1 > net.link.bridge.ipfw_arp=1 > net.link.bridge.pfil_member=1 > > net.inet.ip.fw.verbose_limit=100 > net.inet.ip.fw.verbose=1 > ===== You should avoid passing same packet multiple times through the ruleset. Less checks, better performance. Do you really use ipfw filtering based on layer2 parameters like MAC addresses? If not, you should disable net.link.ether.ipfw. If yes, you should use "layer2" keyword explicily in rules filtering by ethernet headers and place these rules above others and use "allow ip from any to any layer2" after L2 filtering is done, so L2 packets do not go through other rules extra time. Do you really need to filter each bridged L3 packet twice? Once as "out xmit $bridge" and once as "out xmit $brige_member"? If not, you should disable net.link.bridge.ipfw and keep net.link.bridge.pfil_member=1 only. Perhaps, you are ruining the performance with such settings making same work 3 times without real need. Do you really need filtering ARP? Disable net.link.bridge.ipfw_arp if not. > `sysctl net.isr` > ===== > sysctl net.isr > net.isr.numthreads: 1 > net.isr.maxprot: 16 > net.isr.defaultqlimit: 256 > net.isr.maxqlimit: 10240 > net.isr.bindthreads: 0 > net.isr.maxthreads: 1 > net.isr.dispatch: direct > ===== > > I don't know about internals but I think high interrupt load is bad and it because NIC does not support per CPU-queue for example. All decent igb(4) NICs support at least 8 hardware input queues unless disabled by driver/kernel. However, net.isr settings are not about such queues. High interrupt number is definitely better than dropping input frames by NIC chip due to overflow of its internal buffers just because CPU was not notified it's time to get traffic out of these buffers. The driver tries not to overload CPU with interrupts and that's fine but default 8000 limit is not adequate to modern CPU and was not adequate for many years. Raise limit to 32000. >> If not, you should try something like this. For loader.conf: > > Sorry, it's a production system and I can reboot it at the middle of October only. > >> #substitute total number of CPU cores in the system here >> net.isr.maxthreads=4 >> # EOF > > Is it ok for multicast? It's UDP traffic which must be ordered. I read 'maxthreads=1' used to keep TCP traffic ordered. It's a job for uplink to feed your bridge with ordered UDP flows. If you use igb(4) driver, FreeBSD kernel will keep flows ordered automatically. There is no place in the code where they could be reordered if you do not use lagg(4) without LACP. >> And if you haven't already seen it, you may find useful my blog post >> (in Russian) https://dadv.livejournal.com/139170.html >> It's a bit old but still can give you some light. > Yes, I read it already :-) Also some Calomel articles. I'll try to tune system at next reboot. > The main question for myself now is "how is this architecture correct" and "how many traffic is possible to process". You have read numbers from my posts. ipfw+dummynet+PPPoE+routing+LACP+vlan tagging takes much more CPU power than just ipfw+bridging and my system still processed much more traffic. Make sure you don't pass same packets multiple times through ipfw rules. ipfw has its counters for rules and you should use them to summarize octets carefully and compare with numbers shown by netstat or systat (they both have same in-kernel source) to verify whether packets go through ipfw extra times or not. From owner-freebsd-net@freebsd.org Tue Aug 27 20:59:33 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D2464DF7CF for ; Tue, 27 Aug 2019 20:59:33 +0000 (UTC) (envelope-from vit@otcnet.ru) Received: from mail.otcnet.ru (mail.otcnet.ru [194.190.78.3]) by mx1.freebsd.org (Postfix) with ESMTP id 46J1TJ5SZJz4L9c for ; Tue, 27 Aug 2019 20:59:32 +0000 (UTC) (envelope-from vit@otcnet.ru) Received: from Victors-MacBook-Air-2.local (unknown [195.91.148.145]) by mail.otcnet.ru (Postfix) with ESMTPSA id 8CA8689DF2; Tue, 27 Aug 2019 23:59:31 +0300 (MSK) Subject: Re: finding optimal ipfw strategy To: Eugene Grosbein , "Andrey V. Elsukov" , freebsd-net@freebsd.org References: <4ff39c8f-341c-5d72-1b26-6558c57bff8d@grosbein.net> From: Victor Gamov Organization: OTCnet Message-ID: Date: Tue, 27 Aug 2019 23:59:29 +0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 46J1TJ5SZJz4L9c X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of vit@otcnet.ru designates 194.190.78.3 as permitted sender) smtp.mailfrom=vit@otcnet.ru X-Spamd-Result: default: False [-6.51 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+a:mail.otcnet.ru:c]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[otcnet.ru]; TO_DN_SOME(0.00)[]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.982,0]; IP_SCORE(-3.33)[ip: (-8.76), ipnet: 194.190.78.0/24(-4.38), asn: 50822(-3.50), country: RU(0.01)]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:50822, ipnet:194.190.78.0/24, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 20:59:33 -0000 On 27/08/2019 23:30, Eugene Grosbein wrote: > 28.08.2019 2:20, Victor Gamov wrote: > >> sysctl.conf >> ===== >> net.link.ether.ipfw=1 >> net.link.bridge.ipfw=1 >> net.link.bridge.ipfw_arp=1 >> net.link.bridge.pfil_member=1 >> >> net.inet.ip.fw.verbose_limit=100 >> net.inet.ip.fw.verbose=1 >> ===== > > You should avoid passing same packet multiple times through the ruleset. > Less checks, better performance. Yes, I feel it :-) > Do you really use ipfw filtering based on layer2 parameters like MAC addresses? > If not, you should disable net.link.ether.ipfw. If yes, you should use "layer2" keyword > explicily in rules filtering by ethernet headers and place these rules above others > and use "allow ip from any to any layer2" after L2 filtering is done, > so L2 packets do not go through other rules extra time. > > Do you really need to filter each bridged L3 packet twice? Once as "out xmit $bridge" > and once as "out xmit $brige_member"? If not, you should disable > net.link.bridge.ipfw and keep net.link.bridge.pfil_member=1 only. Packets must be filtered on input VLANs (bridge members) and on output VLANs. So net.link.bridge.pfil_member=1 > Perhaps, you are ruining the performance with such settings making same work 3 times without real need. > > Do you really need filtering ARP? Disable net.link.bridge.ipfw_arp if not. I need to drop ARP moving via bridge. As I use many VLANs all VLAN must be isolated and only multicast must be bridged from one VLAN to others. To block ARP following rule used: deny ip from any to any mac-type 0x0806 via bridge1202 As I understand correctly I need net.link.bridge.ipfw_arp and net.link.bridge.ipfw to do it. I'm not sure about net.link.ether.ipfw >> `sysctl net.isr` >> ===== >> sysctl net.isr >> net.isr.numthreads: 1 >> net.isr.maxprot: 16 >> net.isr.defaultqlimit: 256 >> net.isr.maxqlimit: 10240 >> net.isr.bindthreads: 0 >> net.isr.maxthreads: 1 >> net.isr.dispatch: direct >> ===== >> >> I don't know about internals but I think high interrupt load is bad and it because NIC does >> not support per CPU-queue for example. > > All decent igb(4) NICs support at least 8 hardware input queues unless disabled by driver/kernel. > However, net.isr settings are not about such queues. > > High interrupt number is definitely better than dropping input frames by NIC chip > due to overflow of its internal buffers just because CPU was not notified it's time to get traffic > out of these buffers. The driver tries not to overload CPU with interrupts and that's fine > but default 8000 limit is not adequate to modern CPU and was not adequate for many years. > Raise limit to 32000. I see. Thanks! I'll tune net.isr ASAP. >>> If not, you should try something like this. For loader.conf: >> >> Sorry, it's a production system and I can reboot it at the middle of October only. >> >>> #substitute total number of CPU cores in the system here >>> net.isr.maxthreads=4 >>> # EOF >> >> Is it ok for multicast? It's UDP traffic which must be ordered. I read 'maxthreads=1' used to keep TCP traffic ordered. > > It's a job for uplink to feed your bridge with ordered UDP flows. If you use igb(4) driver, > FreeBSD kernel will keep flows ordered automatically. There is no place in the code > where they could be reordered if you do not use lagg(4) without LACP. Thanks again. I'll set maxthreads=4 at next reboot. >>> And if you haven't already seen it, you may find useful my blog post >>> (in Russian) https://dadv.livejournal.com/139170.html >>> It's a bit old but still can give you some light. >> Yes, I read it already :-) Also some Calomel articles. I'll try to tune system at next reboot. >> The main question for myself now is "how is this architecture correct" and "how many traffic is possible to process". > > You have read numbers from my posts. ipfw+dummynet+PPPoE+routing+LACP+vlan tagging takes much more CPU power > than just ipfw+bridging and my system still processed much more traffic. > > Make sure you don't pass same packets multiple times through ipfw rules. > ipfw has its counters for rules and you should use them to summarize octets carefully > and compare with numbers shown by netstat or systat (they both have same in-kernel source) > to verify whether packets go through ipfw extra times or not. It's not too easy but I'll try to build test system and check on it. If 'bridge + drop on outgoing' is not a bottleneck I'll tune system and use this approach while it's possible. -- CU, Victor Gamov From owner-freebsd-net@freebsd.org Tue Aug 27 21:45:56 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 22CDAC8A85 for ; Tue, 27 Aug 2019 21:45:56 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (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 46J2Vq1LLKz4NmV for ; Tue, 27 Aug 2019 21:45:54 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id x7RLjldn057065 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Aug 2019 21:45:50 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: vit@otcnet.ru Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id x7RLjhOv013107 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 28 Aug 2019 04:45:43 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: finding optimal ipfw strategy To: Victor Gamov , "Andrey V. Elsukov" , freebsd-net@freebsd.org References: <4ff39c8f-341c-5d72-1b26-6558c57bff8d@grosbein.net> From: Eugene Grosbein Message-ID: <568ed3e1-caec-3988-16a5-0feea80f1630@grosbein.net> Date: Wed, 28 Aug 2019 04:45:36 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 46J2Vq1LLKz4NmV X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-4.58 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_PERMFAIL(0.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.980,0]; IP_SCORE(-1.50)[ip: (-3.73), ipnet: 2a01:4f8::/29(-1.97), asn: 24940(-1.80), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 21:45:56 -0000 28.08.2019 3:59, Victor Gamov wrote: >>> sysctl.conf >>> ===== >>> net.link.ether.ipfw=1 >>> net.link.bridge.ipfw=1 >>> net.link.bridge.ipfw_arp=1 >>> net.link.bridge.pfil_member=1 >>> >>> net.inet.ip.fw.verbose_limit=100 >>> net.inet.ip.fw.verbose=1 >>> ===== >> Do you really use ipfw filtering based on layer2 parameters like MAC addresses? >> If not, you should disable net.link.ether.ipfw. If yes, you should use "layer2" keyword >> explicily in rules filtering by ethernet headers and place these rules above others >> and use "allow ip from any to any layer2" after L2 filtering is done, >> so L2 packets do not go through other rules extra time. >> >> Do you really need to filter each bridged L3 packet twice? Once as "out xmit $bridge" >> and once as "out xmit $brige_member"? If not, you should disable >> net.link.bridge.ipfw and keep net.link.bridge.pfil_member=1 only. > > Packets must be filtered on input VLANs (bridge members) and on output VLANs. So net.link.bridge.pfil_member=1 >> Perhaps, you are ruining the performance with such settings making same work 3 times without real need. >> Do you really need filtering ARP? Disable net.link.bridge.ipfw_arp if not. > I need to drop ARP moving via bridge. As I use many VLANs all VLAN must be isolated and only multicast must be bridged from one VLAN to others. To block ARP following rule used: > deny ip from any to any mac-type 0x0806 via bridge1202 > As I understand correctly I need net.link.bridge.ipfw_arp and net.link.bridge.ipfw to do it. I'm not sure about net.link.ether.ipfw Why do you need to filter ARP on bridge? That's unusial. VLANs are isolated by default and by definition, unless you explicitly enable inter-vlan routing and setup your routing table. Anyway, you can skip entire ipfw pass over a bridge because you filter its members anyway, so just drop ARP coming from any vlan with exception of controlling one: allow ip from any to any layer2 mac-type 0x0806 in recv $controlvlan deny ip from any to any layer2 mac-type 0x0806 in allow ip from any to any layer2 And then disable filtering for bridge itself altogether. Decreasing number of passes over ipfw should be your top priority because that's what can provide you with most benefit. You should even rewrite your ruleset if that is needed to achieve this goal. From owner-freebsd-net@freebsd.org Tue Aug 27 21:54:22 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 19CA9C8D57 for ; Tue, 27 Aug 2019 21:54:22 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (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 46J2hY35byz4P7n for ; Tue, 27 Aug 2019 21:54:21 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id x7RLsHJx057131 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Aug 2019 21:54:18 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: vit@otcnet.ru Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id x7RLsD6C013293 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 28 Aug 2019 04:54:13 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: finding optimal ipfw strategy To: Victor Gamov , "Andrey V. Elsukov" , freebsd-net@freebsd.org References: <4ff39c8f-341c-5d72-1b26-6558c57bff8d@grosbein.net> <50b0748d-bf8a-4de9-58bf-800ddd4f9c27@grosbein.net> <60d075ee-0d39-6606-ea5a-35e27818162a@otcnet.ru> <032b67e1-5359-4f00-a449-26c43b70a467@grosbein.net> <328ff261-f247-976f-ccba-e4b4e9098d8c@otcnet.ru> From: Eugene Grosbein Message-ID: Date: Wed, 28 Aug 2019 04:54:06 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <328ff261-f247-976f-ccba-e4b4e9098d8c@otcnet.ru> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 46J2hY35byz4P7n X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-4.59 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_PERMFAIL(0.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.976,0]; IP_SCORE(-1.52)[ip: (-3.81), ipnet: 2a01:4f8::/29(-1.97), asn: 24940(-1.80), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 21:54:22 -0000 28.08.2019 3:20, Victor Gamov wrote: >>>> hw.igb.max_interrupt_rate=32000 >>> >>> It's about 5000-7000 per rxq >> >> 7000 is quite close considering it is average for quite long period (a second or seconds). >> It can hit 8000 for some ticks easily in your case. > > Eugene, can you explain me what max_interrupt_rate means? Calomel explain it as "# maximum number of interrupts per second generated by single igb". So if I increase it then more irq per sec will be generated and more context switch produced. Why I need to increase it? Already did in another post. >> You should raise the limit as soon as possible. I'd advise to double it upto 16000 first >> but if you cannot afford extra reboot better use 32000 as it's just fine for 1Gbps link. > # sysctl hw.igb.max_interrupt_rate > sysctl: unknown oid 'hw.igb.max_interrupt_rate' > # > Is it possible to set it at boot time only? Yes, unless you patched igb(4) sources with a patch as described in by blog: http://www.grosbein.net/freebsd/patches/igb_sysctl-11.0.diff.gz It adds per-interface sysctls to change this on-the-fly: dev.igb.0.max_interrupt_rate=32000 dev.igb.1.max_interrupt_rate=32000 Be warned that you still need to re-initialize the NIC to write changed value to the chip and this will temporary stop traffic. Easiest way is to bring the interface down/up: ifconfig igb0 down; ifconfig igb0 up hw.igb.max_interrupt_rate is used as default value for sysctls so if you raise the limit in loader.conf, it is used by chip on first "up" of interface at boot time. From owner-freebsd-net@freebsd.org Wed Aug 28 10:18:49 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 020B7D84A9 for ; Wed, 28 Aug 2019 10:18:49 +0000 (UTC) (envelope-from vit@otcnet.ru) Received: from mail.otcnet.ru (mail.otcnet.ru [194.190.78.3]) by mx1.freebsd.org (Postfix) with ESMTP id 46JMCW5lrzz42Y9 for ; Wed, 28 Aug 2019 10:18:47 +0000 (UTC) (envelope-from vit@otcnet.ru) Received: from Victors-MacBook-Air-2.local (unknown [188.164.215.2]) by mail.otcnet.ru (Postfix) with ESMTPSA id 9C00B5CD20; Wed, 28 Aug 2019 13:18:44 +0300 (MSK) Subject: Re: finding optimal ipfw strategy To: Eugene Grosbein , "Andrey V. Elsukov" , freebsd-net@freebsd.org References: <4ff39c8f-341c-5d72-1b26-6558c57bff8d@grosbein.net> <568ed3e1-caec-3988-16a5-0feea80f1630@grosbein.net> From: Victor Gamov Organization: OTCnet Message-ID: <56f81118-a584-01b4-238f-57f9d52a0fc6@otcnet.ru> Date: Wed, 28 Aug 2019 13:18:43 +0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <568ed3e1-caec-3988-16a5-0feea80f1630@grosbein.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 46JMCW5lrzz42Y9 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of vit@otcnet.ru designates 194.190.78.3 as permitted sender) smtp.mailfrom=vit@otcnet.ru X-Spamd-Result: default: False [-6.51 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+a:mail.otcnet.ru]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[otcnet.ru]; TO_DN_SOME(0.00)[]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.985,0]; IP_SCORE(-3.33)[ip: (-8.76), ipnet: 194.190.78.0/24(-4.38), asn: 50822(-3.50), country: RU(0.01)]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:50822, ipnet:194.190.78.0/24, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 10:18:49 -0000 On 28/08/2019 24:45, Eugene Grosbein wrote: > 28.08.2019 3:59, Victor Gamov wrote: > >>>> sysctl.conf ===== net.link.ether.ipfw=1 net.link.bridge.ipfw=1 >>>> net.link.bridge.ipfw_arp=1 net.link.bridge.pfil_member=1 >>>> >>>> net.inet.ip.fw.verbose_limit=100 net.inet.ip.fw.verbose=1 >>>> ===== > >>> Do you really use ipfw filtering based on layer2 parameters like >>> MAC addresses? If not, you should disable net.link.ether.ipfw. If >>> yes, you should use "layer2" keyword explicily in rules filtering >>> by ethernet headers and place these rules above others and use >>> "allow ip from any to any layer2" after L2 filtering is done, so >>> L2 packets do not go through other rules extra time. >>> >>> Do you really need to filter each bridged L3 packet twice? Once >>> as "out xmit $bridge" and once as "out xmit $brige_member"? If >>> not, you should disable net.link.bridge.ipfw and keep >>> net.link.bridge.pfil_member=1 only. >> >> Packets must be filtered on input VLANs (bridge members) and on >> output VLANs. So net.link.bridge.pfil_member=1 >>> Perhaps, you are ruining the performance with such settings >>> making same work 3 times without real need. Do you really need >>> filtering ARP? Disable net.link.bridge.ipfw_arp if not. >> I need to drop ARP moving via bridge. As I use many VLANs all VLAN >> must be isolated and only multicast must be bridged from one VLAN >> to others. To block ARP following rule used: deny ip from any to >> any mac-type 0x0806 via bridge1202 As I understand correctly I need >> net.link.bridge.ipfw_arp and net.link.bridge.ipfw to do it. I'm >> not sure about net.link.ether.ipfw > > Why do you need to filter ARP on bridge? That's unusial. VLANs are > isolated by default and by definition, unless you explicitly enable > inter-vlan routing and setup your routing table. May be I have some misunderstood here but... If I have many VLANs bridged via bridge interface then ARP received from one VLAN will be send to all bridge members. So it will be send to all unwanted VLANs. Is it correct? > Anyway, you can skip entire ipfw pass over a bridge because you > filter its members anyway, so just drop ARP coming from any vlan with > exception of controlling one: > > allow ip from any to any layer2 mac-type 0x0806 in recv $controlvlan > deny ip from any to any layer2 mac-type 0x0806 in allow ip from any > to any layer2 > > And then disable filtering for bridge itself altogether. Decreasing > number of passes over ipfw should be your top priority because that's > what can provide you with most benefit. You should even rewrite your > ruleset if that is needed to achieve this goal. If I set net.link.bridge.ipfw=0 but net.link.ether.ipfw and net.link.bridge.ipfw still set to 1 is it still possible block unwanted ARP received from one VLAN and bridged to other on outgoing VLAN like deny ip from any to any layer2 mac-type 0x0806 out xmit MAC not $mymac any Is it correct and more effective than net.link.bridge.ipfw=1 if I have "deny mac-type 0x0806 via bridge" at rules top? -- CU, Victor Gamov From owner-freebsd-net@freebsd.org Wed Aug 28 13:32:35 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 88674DCDBC for ; Wed, 28 Aug 2019 13:32:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 46JRW736mNz4Cb8 for ; Wed, 28 Aug 2019 13:32:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 6B113DCDBB; Wed, 28 Aug 2019 13:32:35 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6ADB3DCDBA for ; Wed, 28 Aug 2019 13:32:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46JRW724W1z4Cb7 for ; Wed, 28 Aug 2019 13:32:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 29FD980FE for ; Wed, 28 Aug 2019 13:32:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x7SDWZPg029046 for ; Wed, 28 Aug 2019 13:32:35 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x7SDWZAB029045 for net@FreeBSD.org; Wed, 28 Aug 2019 13:32:35 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 239982] IPv6 network stack panics since upgrading to 11.3 Date: Wed, 28 Aug 2019 13:32:34 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.3-RELEASE X-Bugzilla-Keywords: crash, needs-qa, regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: j.david.lists@gmail.com X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 13:32:35 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D239982 j.david.lists@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Open |Closed Resolution|--- |FIXED --- Comment #3 from j.david.lists@gmail.com --- Closing this as the FreeBSD-SA-19:22.mbuf fix appears to have completely resolved the issue. (No crashes in 7 days.) --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Wed Aug 28 15:49:00 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6D5CCDFDF8 for ; Wed, 28 Aug 2019 15:49:00 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (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 46JVXW2pqMz4M43 for ; Wed, 28 Aug 2019 15:48:59 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id x7SFmoQD076095 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 28 Aug 2019 15:48:53 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: vit@otcnet.ru Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id x7SFmjJh027872 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 28 Aug 2019 22:48:45 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: finding optimal ipfw strategy To: Victor Gamov , freebsd-net@freebsd.org References: <4ff39c8f-341c-5d72-1b26-6558c57bff8d@grosbein.net> <568ed3e1-caec-3988-16a5-0feea80f1630@grosbein.net> <56f81118-a584-01b4-238f-57f9d52a0fc6@otcnet.ru> From: Eugene Grosbein Message-ID: <2751a318-c26b-a14d-0a18-bbd810849606@grosbein.net> Date: Wed, 28 Aug 2019 22:48:37 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <56f81118-a584-01b4-238f-57f9d52a0fc6@otcnet.ru> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 46JVXW2pqMz4M43 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-4.61 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_PERMFAIL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.98)[-0.982,0]; IP_SCORE(-1.53)[ip: (-3.88), ipnet: 2a01:4f8::/29(-1.97), asn: 24940(-1.80), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 15:49:00 -0000 28.08.2019 17:18, Victor Gamov wrote: >> Why do you need to filter ARP on bridge? That's unusial. VLANs are >> isolated by default and by definition, unless you explicitly enable >> inter-vlan routing and setup your routing table. > > May be I have some misunderstood here but... > If I have many VLANs bridged via bridge interface then ARP received > from one VLAN will be send to all bridge members. So it will be send > to all unwanted VLANs. Is it correct? Yes. So, you really do not want any kind of unicast bridging at all and use bridge as "poor man's" replacement for inter-vlan multicast routing, right? In such case you could benefit from small patch that allows you to block ARP packets unconditionally as if they were filtered by ipfw without really passing them through the ruleset. Use sysctl net.link.bridge.ipfw_arp=-1 with the patch (untested): --- if_bridge.c.orig 2019-04-19 17:20:09.724804000 +0700 +++ if_bridge.c 2019-08-28 22:35:14.788891000 +0700 @@ -3153,6 +3153,10 @@ bridge_pfil(struct mbuf **mp, struct ifn switch (ether_type) { case ETHERTYPE_ARP: case ETHERTYPE_REVARP: + if (V_pfil_ipfw_arp == -1) { + error = 0; + goto bad; /* Automatically drop */ + } if (V_pfil_ipfw_arp == 0) return (0); /* Automatically pass */ break; >> Anyway, you can skip entire ipfw pass over a bridge because you >> filter its members anyway, so just drop ARP coming from any vlan with >> exception of controlling one: >> >> allow ip from any to any layer2 mac-type 0x0806 in recv $controlvlan deny ip from any to any layer2 mac-type 0x0806 in allow ip from any >> to any layer2 >> >> And then disable filtering for bridge itself altogether. Decreasing >> number of passes over ipfw should be your top priority because that's >> what can provide you with most benefit. You should even rewrite your >> ruleset if that is needed to achieve this goal. > > If I set net.link.bridge.ipfw=0 but net.link.ether.ipfw and net.link.bridge.ipfw still set to 1 > is it still possible block unwanted ARP received from one VLAN and bridged to other on outgoing VLAN like > > deny ip from any to any layer2 mac-type 0x0806 out xmit MAC not $mymac any > > Is it correct and more effective than net.link.bridge.ipfw=1 if I have "deny mac-type 0x0806 via bridge" at rules top? Yes. And anything decreasing number of traffic passes over entire ipfw ruleset is efficient. From owner-freebsd-net@freebsd.org Wed Aug 28 16:58:31 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 11007E1703 for ; Wed, 28 Aug 2019 16:58:31 +0000 (UTC) (envelope-from vit@otcnet.ru) Received: from mail.otcnet.ru (mail.otcnet.ru [194.190.78.3]) by mx1.freebsd.org (Postfix) with ESMTP id 46JX4j4ktfz4R4C for ; Wed, 28 Aug 2019 16:58:29 +0000 (UTC) (envelope-from vit@otcnet.ru) Received: from Victors-MacBook-Air-2.local (unknown [188.164.215.2]) by mail.otcnet.ru (Postfix) with ESMTPSA id 2A19A65380; Wed, 28 Aug 2019 19:58:27 +0300 (MSK) Subject: Re: finding optimal ipfw strategy To: Eugene Grosbein , freebsd-net@freebsd.org References: <4ff39c8f-341c-5d72-1b26-6558c57bff8d@grosbein.net> <568ed3e1-caec-3988-16a5-0feea80f1630@grosbein.net> <56f81118-a584-01b4-238f-57f9d52a0fc6@otcnet.ru> <2751a318-c26b-a14d-0a18-bbd810849606@grosbein.net> From: Victor Gamov Organization: OTCnet Message-ID: Date: Wed, 28 Aug 2019 19:58:25 +0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <2751a318-c26b-a14d-0a18-bbd810849606@grosbein.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 46JX4j4ktfz4R4C X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of vit@otcnet.ru designates 194.190.78.3 as permitted sender) smtp.mailfrom=vit@otcnet.ru X-Spamd-Result: default: False [-6.51 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.otcnet.ru]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[otcnet.ru]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.986,0]; RCPT_COUNT_TWO(0.00)[2]; IP_SCORE(-3.32)[ip: (-8.75), ipnet: 194.190.78.0/24(-4.38), asn: 50822(-3.50), country: RU(0.01)]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:50822, ipnet:194.190.78.0/24, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 16:58:31 -0000 On 28/08/2019 18:48, Eugene Grosbein wrote: > 28.08.2019 17:18, Victor Gamov wrote: > >>> Why do you need to filter ARP on bridge? That's unusial. VLANs are >>> isolated by default and by definition, unless you explicitly enable >>> inter-vlan routing and setup your routing table. >> >> May be I have some misunderstood here but... >> If I have many VLANs bridged via bridge interface then ARP received >> from one VLAN will be send to all bridge members. So it will be send >> to all unwanted VLANs. Is it correct? > > Yes. So, you really do not want any kind of unicast bridging at all > and use bridge as "poor man's" replacement for inter-vlan multicast routing, right? :-) Looks like this But I start this project as experiment (now in production) to get "router" which allowed implicitly send multicast whithout needs to igmp-join from attached VLANs and with my own multicast policy. > In such case you could benefit from small patch that allows you to block ARP packets unconditionally > as if they were filtered by ipfw without really passing them through the ruleset. > Use sysctl net.link.bridge.ipfw_arp=-1 with the patch (untested): I'll try it when make test server. Thanks! >>> Anyway, you can skip entire ipfw pass over a bridge because you >>> filter its members anyway, so just drop ARP coming from any vlan with >>> exception of controlling one: >>> >>> allow ip from any to any layer2 mac-type 0x0806 in recv $controlvlan deny ip from any to any layer2 mac-type 0x0806 in allow ip from any >>> to any layer2 >>> >>> And then disable filtering for bridge itself altogether. Decreasing >>> number of passes over ipfw should be your top priority because that's >>> what can provide you with most benefit. You should even rewrite your >>> ruleset if that is needed to achieve this goal. >> >> If I set net.link.bridge.ipfw=0 but net.link.ether.ipfw and net.link.bridge.ipfw still set to 1 >> is it still possible block unwanted ARP received from one VLAN and bridged to other on outgoing VLAN like >> >> deny ip from any to any layer2 mac-type 0x0806 out xmit MAC not $mymac any >> >> Is it correct and more effective than net.link.bridge.ipfw=1 if I have "deny mac-type 0x0806 via bridge" at rules top? > > Yes. And anything decreasing number of traffic passes over entire ipfw ruleset is efficient. ok, will try it some later. Hope no problem to switch on/off this sysctl on production server :-) Many thanks, Eugene! P.S. Two questions about rules syntax optimization. What is more effective: skipto tablearg udp from any to table(AllMcast_out) or skipto tablearg udp from any to table(AllMcast_out) out xmit vlan* I hope I can place such rule at top of ruleset and only allowed multicast packets outgoing via VLANs interfaces will hit this rule. and second: allow udp from $src1 to { 239.1.2.55 or 239.1.2.56 } or allow udp from src1 to 239.1.2.0/24{55,56} Thanks again! -- CU, Victor Gamov From owner-freebsd-net@freebsd.org Wed Aug 28 17:20:07 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B15FFE20FE for ; Wed, 28 Aug 2019 17:20:07 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (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 46JXYf6D6Fz4SZK for ; Wed, 28 Aug 2019 17:20:06 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id x7SHK2hT076927 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 28 Aug 2019 17:20:03 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: vit@otcnet.ru Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id x7SHJww1028691 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 29 Aug 2019 00:19:58 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: finding optimal ipfw strategy To: Victor Gamov , freebsd-net@freebsd.org References: <4ff39c8f-341c-5d72-1b26-6558c57bff8d@grosbein.net> <568ed3e1-caec-3988-16a5-0feea80f1630@grosbein.net> <56f81118-a584-01b4-238f-57f9d52a0fc6@otcnet.ru> <2751a318-c26b-a14d-0a18-bbd810849606@grosbein.net> From: Eugene Grosbein Message-ID: Date: Thu, 29 Aug 2019 00:19:50 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 46JXYf6D6Fz4SZK X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-4.63 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_PERMFAIL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.98)[-0.981,0]; IP_SCORE(-1.55)[ip: (-3.95), ipnet: 2a01:4f8::/29(-1.97), asn: 24940(-1.80), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 17:20:07 -0000 28.08.2019 23:58, Victor Gamov wrote: > P.S. Two questions about rules syntax optimization. What is more effective: > skipto tablearg udp from any to table(AllMcast_out) > or > skipto tablearg udp from any to table(AllMcast_out) out xmit vlan* Can't tell, this heavily depends on table contents and internal order of checks in kernel part of ipfw but general rule should still apply: less checks, better performance. > I hope I can place such rule at top of ruleset and only allowed multicast packets outgoing via VLANs interfaces will hit this rule. > > and second: > allow udp from $src1 to { 239.1.2.55 or 239.1.2.56 } > or > allow udp from src1 to 239.1.2.0/24{55,56} Last one should me much more efficient as it just needs to perform a couple of 32-bit masking operations and previous one is more general (IP addresses may belong to different networks) and requires slower search. From owner-freebsd-net@freebsd.org Thu Aug 29 00:45:42 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C93B0EADDE for ; Thu, 29 Aug 2019 00:45:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 46JkRp50Tfz3y6t for ; Thu, 29 Aug 2019 00:45:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id AB94FEADDD; Thu, 29 Aug 2019 00:45:42 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AB5A9EADDC for ; Thu, 29 Aug 2019 00:45:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46JkRp44lsz3y6s for ; Thu, 29 Aug 2019 00:45:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 6DCB8FE16 for ; Thu, 29 Aug 2019 00:45:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x7T0jg7R060172 for ; Thu, 29 Aug 2019 00:45:42 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x7T0jg46060157 for net@FreeBSD.org; Thu, 29 Aug 2019 00:45:42 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 239704] ixgbe(4): Only one queue (of eight) enabled on 12.0-RELEASE (ProLiant DL380 Gen10) Date: Thu, 29 Aug 2019 00:45:34 +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: 12.0-RELEASE X-Bugzilla-Keywords: IntelNetworking, needs-qa, regression X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: gcr@tharned.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: mfc-stable12? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 00:45:42 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D239704 --- Comment #5 from Greg Rivers --- Another data point: I get the same result on a ProLiant DL380 Gen9 with the same NIC. Please let me know if there's anything I can do to facilitate. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Thu Aug 29 10:55:02 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 26EADD2381 for ; Thu, 29 Aug 2019 10:55:02 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from sender-of-o53.zoho.com (sender-of-o53.zoho.com [135.84.80.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46Jzys13Ytz4W8X for ; Thu, 29 Aug 2019 10:55:00 +0000 (UTC) (envelope-from patfbsd@davenulle.org) ARC-Seal: i=1; a=rsa-sha256; t=1567076091; cv=none; d=zoho.com; s=zohoarc; b=kDlQUWQh9ECGouGGMK7zB5aUDLEIKyX3UgVroRLbnpDKt9Ufz2s5Pzkk6jWLCWmW1LGuyanuqJ6kyeF2isjdc795r4lhVCGtqmVfsssZfE/3BWPReIk9m9NdconuGrmwWtsf1erc6XtA8fWcJTsYdR9LyOwP/mLM1wafoJn+tcg= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1567076091; h=Content-Type:Content-Transfer-Encoding:Date:From:MIME-Version:Message-ID:Subject:To:ARC-Authentication-Results; bh=fj19R9VaZi+2aKHKsz4gycUpXgb9UmLl0u5BF6r/LXM=; b=lCUmJOaxq+xBdbGO0BLuBkOyVQB0zphWv0EdqEvVCflAcr07lGEWXrguPnwRAL5BegVXZqRAHdnoQ+R7X2f6pZbpVABF5iboiOTCx9xVBALoc5Vf7jgD3koMAYWOBRLvr27OMzomfDo0pNQLAJfMOztzJ2DIeZxwJXjaEgTQvNk= ARC-Authentication-Results: i=1; mx.zoho.com; dkim=pass header.i=davenulle.org; spf=pass smtp.mailfrom=patfbsd@davenulle.org; dmarc=pass header.from= header.from= Received: from mr185033.univ-rennes1.fr (mr185033.univ-rennes1.fr [129.20.185.33]) by mx.zohomail.com with SMTPS id 1567076090265489.6827239555482; Thu, 29 Aug 2019 03:54:50 -0700 (PDT) Date: Thu, 29 Aug 2019 12:54:41 +0200 From: Patrick Lamaiziere To: "freebsd-net@freebsd.org" Subject: problem with carp on 11.3-RELEASE Message-ID: <20190829125441.12197ea8@mr185033.univ-rennes1.fr> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ZohoMailClient: External X-Rspamd-Queue-Id: 46Jzys13Ytz4W8X X-Spamd-Bar: ------- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of patfbsd@davenulle.org has no SPF policy when checking 135.84.80.218) smtp.mailfrom=patfbsd@davenulle.org X-Spamd-Result: default: False [-7.47 / 15.00]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[davenulle.org]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-3.38)[ip: (-8.76), ipnet: 135.84.80.0/24(-4.71), asn: 2639(-3.36), country: US(-0.05)]; NEURAL_HAM_SHORT(-0.99)[-0.990,0]; RCVD_IN_DNSWL_NONE(0.00)[218.80.84.135.list.dnswl.org : 127.0.15.0]; TO_DN_EQ_ADDR_ALL(0.00)[]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:2639, ipnet:135.84.80.0/24, country:US]; RCVD_COUNT_TWO(0.00)[2]; ARC_ALLOW(-1.00)[i=1] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 10:55:02 -0000 Hello, I've upgraded our two firewalls from 11.2-RELEASE-p11 to 11.3 release p3 and I'm seeing a problem with carp, the carp slave becomes briefly MASTER and returns to the slave state. This occurs often. the firewalls use PF / PFSYNC / CARP and the configuration is the same as on 11.2. On 11.2 that works very well. there are two firewalls, the first firewall (fucop1) is normally the carp master but at boot time it starts demoted (via sysctl net.inet.carp.demotion=1000) to prevent it to become master (we promote it manually). The second fw (fucop2) is normally the carp slave. rc.conf --- fucop1--- #-------------------------------- # Packet Filter + pfsync #- pf_enable="YES" pf_rules="/etc/pf.conf" pflog_enable="YES" pfsync_enable="YES" pfsync_syncdev="igb3" pfsync_ifconfig="maxupd 254" pfsync_syncpeer="192.168.255.254" # ix2 : ifconfig_ix2="inet XX.XX.XX.251/24 -tso -lro -vlanhwtso description RI_PF_CKP group CARPDEV group IFCKP" ifconfig_ix2_alias0="inet vhid 3 advskew 0 pass abcdef alias XX.XX.XX.254/32" # igb0 : ifconfig_igb0="inet YY.YY.YY.251/24 -tso -lro -vlanhwtso description PUBLIC_UR1 group CARPDEV group IFPUB1UR" ifconfig_igb0_alias0="inet vhid 2 advskew 0 pass abcdef alias YY.YY.YY.254/32" # igb1 : ifconfig_igb1="inet 192.168.20.251/24 -tso -lro -vlanhwtso description RI_UR1_CHU group CARPDEV group IFCHU" ifconfig_igb1_alias0="inet vhid 6 advskew 0 pass abcdef alias 192.168.20.254/32" # igb3 : pfsync ifconfig_igb3="inet 192.168.255.253/30 -tso -lro -vlanhwtso description PF_SYNC" --- fucop2 --- #-------------------------------- # Packet Filter + pfsync #- pf_enable="YES" pf_rules="/etc/pf.conf" pflog_enable="YES" pfsync_enable="YES" pfsync_syncdev="igb3" pfsync_ifconfig="maxupd 254" pfsync_syncpeer="192.168.255.253" # ix2 : ifconfig_ix2="inet XX.XX.XX.252/24 -tso -lro -vlanhwtso description RI_PF_CKP group CARPDEV group IFCKP" ifconfig_ix2_alias0="inet vhid 3 advskew 100 pass abcdef alias XX.XX.XX.254/32" # igb0 : ifconfig_igb0="inet YY.YY.YY.YY/24 -tso -lro -vlanhwtso description PUBLIC_UR1 group CARPDEV group IFPUB1UR" ifconfig_igb0_alias0="inet vhid 2 advskew 100 pass abcdef alias YY.YY.YY.254/32" # igb1 : ifconfig_igb1="inet 192.168.20.252/24 -tso -lro -vlanhwtso description RI_UR1_CHU group CARPDEV group IFCHU" ifconfig_igb1_alias0="inet vhid 6 advskew 100 pass abcdef alias 192.168.20.254/32" # igb3 : pfsync ifconfig_igb3="inet 192.168.255.254/30 -tso -lro -vlanhwtso description PF_SYNC" ------- Log: here fucop2 is the carp MASTER, fucop1 just booted but not promoted. fucop1 becomes briefly master from time to time. ex: Aug 28 15:08:28 fucop1 kernel: carp: 2@igb0: BACKUP -> MASTER (master timed out) Aug 28 15:05:39 fucop1 kernel: carp: demoted by 1000 to 1000 (sysctl) Aug 28 15:05:39 fucop1 kernel: carp: demoted by 240 to 1240 (interface down) Aug 28 15:05:39 fucop1 kernel: carp: demoted by 240 to 1480 (interface down) Aug 28 15:05:39 fucop1 kernel: carp: demoted by 240 to 1720 (interface down) Aug 28 15:05:39 fucop1 kernel: carp: 3@ix2: INIT -> BACKUP (initialization complete) Aug 28 15:05:39 fucop1 kernel: carp: demoted by -240 to 1480 (interface up) Aug 28 15:05:39 fucop1 kernel: carp: 6@igb1: INIT -> BACKUP (initialization complete) Aug 28 15:05:39 fucop1 kernel: carp: demoted by -240 to 1240 (interface up) Aug 28 15:05:39 fucop1 kernel: carp: 2@igb0: INIT -> BACKUP (initialization complete) Aug 28 15:05:39 fucop1 kernel: carp: demoted by -240 to 1000 (interface up) Aug 28 15:05:39 fucop1 kernel: carp: demoted by 0 to 1000 (pfsync bulk start) Aug 28 15:05:42 fucop1 kernel: carp: demoted by 1000 to 2000 (sysctl) Aug 28 15:05:44 fucop1 kernel: carp: demoted by 1000 to 3000 (sysctl) Aug 28 15:08:28 fucop1 kernel: carp: 2@igb0: BACKUP -> MASTER (master timed out) Aug 28 15:08:28 fucop1 kernel: carp: 3@ix2: BACKUP -> MASTER (master timed out) Aug 28 15:08:28 fucop1 kernel: carp: 6@igb1: BACKUP -> MASTER (master timed out) Aug 28 15:08:28 fucop1 kernel: carp: 3@ix2: MASTER -> BACKUP (more frequent advertisement received) Aug 28 15:08:28 fucop1 kernel: carp: 2@igb0: MASTER -> BACKUP (more frequent advertisement received) Aug 28 15:08:28 fucop1 kernel: carp: 6@igb1: MASTER -> BACKUP (more frequent advertisement received) Aug 28 15:12:31 fucop1 kernel: carp: 6@igb1: BACKUP -> MASTER (master timed out) Aug 28 15:12:31 fucop1 kernel: carp: 2@igb0: BACKUP -> MASTER (master timed out) Aug 28 15:12:31 fucop1 kernel: carp: 3@ix2: BACKUP -> MASTER (master timed out) Aug 28 15:12:31 fucop1 kernel: carp: 2@igb0: MASTER -> BACKUP (more frequent advertisement received) Aug 28 15:12:31 fucop1 kernel: carp: 6@igb1: MASTER -> BACKUP (more frequent advertisement received) Aug 28 15:12:31 fucop1 kernel: carp: 3@ix2: MASTER -> BACKUP (more frequent advertisement received) Aug 28 15:14:10 fucop1 kernel: carp: demoted by 0 to 3000 (pfsync bulk done) Aug 28 15:18:40 fucop1 kernel: carp: 6@igb1: BACKUP -> MASTER (master timed out) Aug 28 15:18:40 fucop1 kernel: carp: 3@ix2: BACKUP -> MASTER (master timed out) Aug 28 15:18:40 fucop1 kernel: carp: 2@igb0: BACKUP -> MASTER (master timed out) Aug 28 15:18:42 fucop1 kernel: carp: 3@ix2: MASTER -> BACKUP (more frequent advertisement received) Aug 28 15:18:42 fucop1 kernel: carp: 6@igb1: MASTER -> BACKUP (more frequent advertisement received) Aug 28 15:18:42 fucop1 kernel: carp: 2@igb0: MASTER -> BACKUP (more frequent advertisement received) Aug 28 15:23:46 fucop1 kernel: carp: 6@igb1: BACKUP -> MASTER (master timed out) Aug 28 15:23:46 fucop1 kernel: carp: 2@igb0: BACKUP -> MASTER (master timed out) Aug 28 15:23:46 fucop1 kernel: carp: 3@ix2: BACKUP -> MASTER (master timed out) Aug 28 15:23:47 fucop1 kernel: carp: 6@igb1: MASTER -> BACKUP (more frequent advertisement received) Aug 28 15:23:47 fucop1 kernel: carp: 2@igb0: MASTER -> BACKUP (more frequent advertisement received) Aug 28 15:23:47 fucop1 kernel: carp: 3@ix2: MASTER -> BACKUP (more frequent advertisement received) Aug 28 15:24:51 fucop1 kernel: carp: 6@igb1: BACKUP -> MASTER (master timed out) Aug 28 15:24:51 fucop1 kernel: carp: 2@igb0: BACKUP -> MASTER (master timed out) Aug 28 15:24:51 fucop1 kernel: carp: 3@ix2: BACKUP -> MASTER (master timed out) Aug 28 15:24:51 fucop1 kernel: carp: 6@igb1: MASTER -> BACKUP (more frequent advertisement received) Aug 28 15:24:51 fucop1 kernel: carp: 3@ix2: MASTER -> BACKUP (more frequent advertisement received) Aug 28 15:24:51 fucop1 kernel: carp: 2@igb0: MASTER -> BACKUP (more frequent advertisement received) Aug 28 15:29:58 fucop1 kernel: carp: 3@ix2: BACKUP -> MASTER (master timed out) Aug 28 15:29:58 fucop1 kernel: carp: 6@igb1: BACKUP -> MASTER (master timed out) Aug 28 15:29:58 fucop1 kernel: carp: 2@igb0: BACKUP -> MASTER (master timed out) Aug 28 15:29:58 fucop1 kernel: carp: 3@ix2: MASTER -> BACKUP (more frequent advertisement received) Aug 28 15:29:58 fucop1 kernel: carp: 6@igb1: MASTER -> BACKUP (more frequent advertisement received) Aug 28 15:29:58 fucop1 kernel: carp: 2@igb0: MASTER -> BACKUP (more frequent advertisement received) Aug 28 15:34:01 fucop1 kernel: carp: 6@igb1: BACKUP -> MASTER (master timed out) Aug 28 15:34:01 fucop1 kernel: carp: 2@igb0: BACKUP -> MASTER (master timed out) Aug 28 15:34:01 fucop1 kernel: carp: 3@ix2: BACKUP -> MASTER (master timed out) The log on the other firewall (fucop2) contains nothing related to carp. Any clue will be welcome. A question anyway, is pfsync compatible between 11.2 and 11.3 ? Because when we upgrade we start to upgrade fucop2, keeping fucop1 in production. Then we put fucop2 in production (doing a pfsync bulk) and upgrade fucop1. I'm not sure if it could be a concern, looks like there are a lot of changes in pfsync since 11.2. I've put the firewalls back to 11.2 and they work fine. Thanks, best regards. From owner-freebsd-net@freebsd.org Thu Aug 29 11:41:35 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 687A9D30D7 for ; Thu, 29 Aug 2019 11:41:35 +0000 (UTC) (envelope-from robert@heron.pl) Received: from sys.heron.com.pl (sys.heron.com.pl [89.25.217.130]) by mx1.freebsd.org (Postfix) with ESMTP id 46K10Z3DZXz4XvF for ; Thu, 29 Aug 2019 11:41:34 +0000 (UTC) (envelope-from robert@heron.pl) Received: from [79.189.180.154] (helo=[192.168.0.230]) by sys.heron.com.pl with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1i3Io1-000Hrm-FP for freebsd-net@freebsd.org; Thu, 29 Aug 2019 13:41:33 +0200 From: Robert Heron Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: 10 Gbps NIC - advice needed Date: Thu, 29 Aug 2019 13:41:32 +0200 References: <380fff29-8df3-2671-69c3-ef47131aaf58@monkeybrains.net> To: freebsd-net@freebsd.org In-Reply-To: <380fff29-8df3-2671-69c3-ef47131aaf58@monkeybrains.net> Message-Id: <325FE312-A230-4BFB-B582-F61477CD1E46@heron.pl> X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: 46K10Z3DZXz4XvF X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of robert@heron.pl designates 89.25.217.130 as permitted sender) smtp.mailfrom=robert@heron.pl X-Spamd-Result: default: False [-1.33 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-0.91)[-0.910,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:89.25.217.128/28]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[heron.pl]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.97)[-0.971,0]; IP_SCORE(0.20)[asn: 31242(0.95), country: PL(0.06)]; MV_CASE(0.50)[]; RCVD_IN_DNSWL_NONE(0.00)[130.217.25.89.list.dnswl.org : 127.0.10.0]; NEURAL_SPAM_SHORT(0.05)[0.049,0]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:31242, ipnet:89.25.128.0/17, country:PL]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 11:41:35 -0000 Hi, I need to use a 10 Gbps, 2 port NIC (copper RJ-45) with FreeBSD 11.3R = amd64. Which NIC (manufacturer and model) would you recommend as the = most trouble-free and reliable? Maybe some Intel? Robert =20= From owner-freebsd-net@freebsd.org Thu Aug 29 16:53:47 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EF8E2DB233 for ; Thu, 29 Aug 2019 16:53:47 +0000 (UTC) (envelope-from vit@otcnet.ru) Received: from mail.otcnet.ru (mail.otcnet.ru [194.190.78.3]) by mx1.freebsd.org (Postfix) with ESMTP id 46K7wp6szZz3QST for ; Thu, 29 Aug 2019 16:53:46 +0000 (UTC) (envelope-from vit@otcnet.ru) Received: from Victors-MacBook-Air-2.local (unknown [194.190.78.9]) by mail.otcnet.ru (Postfix) with ESMTPSA id 1A8B56D178 for ; Thu, 29 Aug 2019 19:53:39 +0300 (MSK) Subject: Re: how to down interface at startup To: freebsd-net@freebsd.org References: <8e49d9c0-6950-dcb3-ac62-25a9a1f86c2e@otcnet.ru> <9e135f5f-48c1-44b0-1eea-fe47f7a61fc7@grosbein.net> From: Victor Gamov Organization: OTCnet Message-ID: Date: Thu, 29 Aug 2019 19:53:38 +0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 46K7wp6szZz3QST X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of vit@otcnet.ru designates 194.190.78.3 as permitted sender) smtp.mailfrom=vit@otcnet.ru X-Spamd-Result: default: False [-6.51 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.otcnet.ru]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; HAS_ORG_HEADER(0.00)[]; DMARC_NA(0.00)[otcnet.ru]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.988,0]; IP_SCORE(-3.32)[ip: (-8.75), ipnet: 194.190.78.0/24(-4.38), asn: 50822(-3.50), country: RU(0.01)]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:50822, ipnet:194.190.78.0/24, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 16:53:48 -0000 When I configure vlans like this ===== cloned_interfaces="${cloned_interfaces} vlan221" ifconfig_vlan221="inet 10.2.2.241/28 vlan 221 vlandev igb0 NOAUTO" ===== then NOAUTO clause has no effect Small patch to allow NOAUTO for any interface: ===cut here=== *** /etc/network.subr.orig Tue Aug 13 19:24:33 2019 --- /etc/network.subr Tue Aug 20 18:54:22 2019 *************** *** 226,232 **** /etc/rc.d/hostapd start $1 _cfg=0 elif [ ${_cfg} -eq 0 ]; then ! ${IFCONFIG_CMD} $1 up fi if dhcpif $1; then --- 226,236 ---- /etc/rc.d/hostapd start $1 _cfg=0 elif [ ${_cfg} -eq 0 ]; then ! if autoif $1; then ! ${IFCONFIG_CMD} $1 up ! else ! ${IFCONFIG_CMD} $1 down ! fi fi if dhcpif $1; then ===/cut here=== On 28/07/2019 18:33, Victor Gamov wrote: > On 28/07/2019 18:08, Eugene Grosbein wrote: >> 28.07.2019 21:50, Victor Gamov wrote: >> >>> I have configuration where bridge interface need to be down at startup. >>> >>> But "ifconfig_bridge2="down" is not working: bridge always up >>> >>> How I can 'down' bridge interface at startup? >> >> If you use rc.conf to configure it, please read rc.conf(5) manual page >> carefully: >> >>          ... Interfaces that the >>                   administrator wishes to store configuration for, but >> not >>                   start at boot should be configured with the "NOAUTO" >> keyword >>                   in their ifconfig_ variables as described >> below. > > Eugene > > Thank you very much! > > I really need be more carefully while reading docs. > > Thanks! -- CU Victor Gamov From owner-freebsd-net@freebsd.org Thu Aug 29 18:39:59 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 05C3EDD311 for ; Thu, 29 Aug 2019 18:39:59 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.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 46KBHK63Ngz430r for ; Thu, 29 Aug 2019 18:39:57 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x7TIdlvW091177; Thu, 29 Aug 2019 11:39:47 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x7TIdlmh091176; Thu, 29 Aug 2019 11:39:47 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201908291839.x7TIdlmh091176@gndrsh.dnsmgr.net> Subject: Re: finding optimal ipfw strategy In-Reply-To: To: Eugene Grosbein Date: Thu, 29 Aug 2019 11:39:47 -0700 (PDT) CC: Victor Gamov , 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-Rspamd-Queue-Id: 46KBHK63Ngz430r X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-rwg@gndrsh.dnsmgr.net has no SPF policy when checking 69.59.192.140) smtp.mailfrom=freebsd-rwg@gndrsh.dnsmgr.net X-Spamd-Result: default: False [1.01 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.52)[-0.519,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.73)[0.733,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.14)[-0.144,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.04)[ip: (0.15), ipnet: 69.59.192.0/19(0.07), asn: 13868(0.05), country: US(-0.05)]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 18:39:59 -0000 > 28.08.2019 23:58, Victor Gamov wrote: > > > P.S. Two questions about rules syntax optimization. What is more effective: > > skipto tablearg udp from any to table(AllMcast_out) > > or > > skipto tablearg udp from any to table(AllMcast_out) out xmit vlan* > > Can't tell, this heavily depends on table contents and internal order of checks > in kernel part of ipfw but general rule should still apply: less checks, better performance. Given that the base part of the rule is identical it would seem that the first rule should be faster as it does not have to do the checks for "out xmit vlan*". One of the things I do when writting a firewall is very early break up the traffic based on which interface(s) it is coming in/out of and do a skipto based on that, then further classify based on layers so that I am usually only doing 1 compare as it traverse down what is in effect a trie. dispatch on interface(s) dispatch on protocol (IP, ESP, OSPF, IGMP, ICMP, etc) IP: dispatch on transport (TCP, UDP, SCTP...) IPTCP: dispatch on setup, established.. IPTCPsetup: dispatch on ports IPUDP: ... I try to write my sets so that I never do the same comparison on a packet at any point in the firewall. Ie, once your in the IPTCP set of rules I no longer check for tcp, only check port numbers and flags (setup, established, etc) Does this seem like a reasonable and efficient approach? > > I hope I can place such rule at top of ruleset and only allowed multicast packets outgoing via VLANs interfaces will hit this rule. > > > > and second: > > allow udp from $src1 to { 239.1.2.55 or 239.1.2.56 } > > or > > allow udp from src1 to 239.1.2.0/24{55,56} > > Last one should me much more efficient as it just needs to perform a couple of 32-bit masking operations > and previous one is more general (IP addresses may belong to different networks) and requires slower search. I disagree, the first one should be 2 simple 32 bit compares, the second one is a 32 bit AND (mask), and then 2 8 bit compares, and actually probably actually 32 bit compares due to data type promotion. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-net@freebsd.org Thu Aug 29 19:02:01 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E95BADD9E5 for ; Thu, 29 Aug 2019 19:02:01 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (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 46KBmm6PP3z44ZQ for ; Thu, 29 Aug 2019 19:02:00 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id x7TJ1rrK009221 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 29 Aug 2019 19:01:55 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: freebsd-rwg@gndrsh.dnsmgr.net Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id x7TJ1nss044696 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 30 Aug 2019 02:01:49 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: finding optimal ipfw strategy To: "Rodney W. Grimes" References: <201908291839.x7TIdlmh091176@gndrsh.dnsmgr.net> Cc: freebsd-net@freebsd.org, Victor Gamov From: Eugene Grosbein Message-ID: <46399afc-89d9-ceea-5144-a6d2f5f102ab@grosbein.net> Date: Fri, 30 Aug 2019 02:01:40 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <201908291839.x7TIdlmh091176@gndrsh.dnsmgr.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 46KBmm6PP3z44ZQ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-4.65 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_PERMFAIL(0.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.980,0]; IP_SCORE(-1.57)[ip: (-4.08), ipnet: 2a01:4f8::/29(-1.97), asn: 24940(-1.80), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 19:02:02 -0000 30.08.2019 1:39, Rodney W. Grimes wrote: > One of the things I do when writting a firewall is very early break > up the traffic based on which interface(s) it is coming in/out of > and do a skipto based on that, then further classify based on layers > so that I am usually only doing 1 compare as it traverse down what > is in effect a trie. > > dispatch on interface(s) > dispatch on protocol (IP, ESP, OSPF, IGMP, ICMP, etc) > IP: dispatch on transport (TCP, UDP, SCTP...) > IPTCP: dispatch on setup, established.. > IPTCPsetup: dispatch on ports > IPUDP: ... > > I try to write my sets so that I never do the same comparison on > a packet at any point in the firewall. Ie, once your in the IPTCP > set of rules I no longer check for tcp, only check port numbers > and flags (setup, established, etc) > > Does this seem like a reasonable and efficient approach? Correct but that's important for high-load scenario only and when firewall processing constitutes most or significant part of work performed by the box. If userland work's much heavier, this could be unimportant complication :-) >>> I hope I can place such rule at top of ruleset and only allowed multicast packets outgoing via VLANs interfaces will hit this rule. >>> and second: >>> allow udp from $src1 to { 239.1.2.55 or 239.1.2.56 } >>> or >>> allow udp from src1 to 239.1.2.0/24{55,56} >> Last one should me much more efficient as it just needs to perform a couple of 32-bit masking operations >> and previous one is more general (IP addresses may belong to different networks) and requires slower search. > I disagree, the first one should be 2 simple 32 bit compares, > the second one is a 32 bit AND (mask), and then 2 8 bit compares, > and actually probably actually 32 bit compares due to data type promotion. That's an example only and I've answered considering scaled picture where there are many more IPs to check for. From owner-freebsd-net@freebsd.org Fri Aug 30 02:12:31 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B1131E6A41 for ; Fri, 30 Aug 2019 02:12:31 +0000 (UTC) (envelope-from vas@mpeks.tomsk.su) Received: from admin.sibptus.ru (admin.sibptus.ru [IPv6:2001:19f0:5001:21dc::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46KNKV44KYz4Wy0 for ; Fri, 30 Aug 2019 02:12:30 +0000 (UTC) (envelope-from vas@mpeks.tomsk.su) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sibptus.ru; s=20181118; h=Message-ID:Subject:To:From:Date:In-Reply-To; bh=x/g1yPnIeCJbnWKco4g3xLyriEcyhTyLpPXwSp9vyiE=; b=Nc6+kbSIHXTIsALAVXH6OeJQXk R1G0QeMwP8mFV7l8QJJEE6r7ZVmHngaE6xWMS9IHi1hqvterWHtbpLEfUro/wS80WmCZ3JRB0QUz9 CSeVLKZ+F+/3KG9dhdc6Iz8LbCSEw+Yvvar+NMLhUly0rcy1EfyVrbjgALJ8vIEvKWR4=; Received: from vas by admin.sibptus.ru with local (Exim 4.92.1 (FreeBSD)) (envelope-from ) id 1i3WOq-000HLV-5g for freebsd-net@freebsd.org; Fri, 30 Aug 2019 09:12:28 +0700 Date: Fri, 30 Aug 2019 09:12:28 +0700 From: Victor Sudakov To: freebsd-net@freebsd.org Subject: Several IPv6 routers and default gateway choice Message-ID: <20190830021228.GA66465@admin.sibptus.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SUOF0GtieIMvvwua" Content-Disposition: inline X-PGP-Key: http://admin.sibptus.ru/~vas/ X-PGP-Fingerprint: 10E3 1171 1273 E007 C2E9 3532 0DA4 F259 9B5E C634 User-Agent: Mutt/1.12.1 (2019-06-15) Sender: Victor Sudakov X-Rspamd-Queue-Id: 46KNKV44KYz4Wy0 X-Spamd-Bar: -------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=sibptus.ru header.s=20181118 header.b=Nc6+kbSI; dmarc=none; spf=pass (mx1.freebsd.org: domain of vas@mpeks.tomsk.su designates 2001:19f0:5001:21dc::10 as permitted sender) smtp.mailfrom=vas@mpeks.tomsk.su X-Spamd-Result: default: False [-8.55 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[sibptus.ru:s=20181118]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[tomsk.su]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE(-2.96)[ip: (-9.42), ipnet: 2001:19f0:5000::/38(-4.71), asn: 20473(-0.64), country: US(-0.05)]; DKIM_TRACE(0.00)[sibptus.ru:+]; NEURAL_HAM_SHORT(-0.99)[-0.991,0]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:20473, ipnet:2001:19f0:5000::/38, country:US]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 02:12:31 -0000 --SUOF0GtieIMvvwua Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dear Colleagues, If a FreeBSD host receives router advertisements from several IPv6 routers, on a LAN segment, which would be chosen as the default gateway? Can this be used for failover? --=20 Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ --SUOF0GtieIMvvwua Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJdaIYMAAoJEA2k8lmbXsY0ODQH/3Q1jzh0wOUVJSYQBZO4T1UD m+2bRGMuNoFciiYrHiy425QOejlBKZgis9s1NOpDW4qAcyt47Rtn2TBs09nQFbMq JlZm2v4uajpHn41D3Ha1hBUW3XZjlVy7EEa7TmqeqzXJFr5VIUP+IMJotmoSWIWE rfk4vj89itVH3s7kV5GH0/mv674xWYhIHQwqXc0lXPLoZPbp/YSAugKccZMHPgnP kXkPx520+b4iLWX/iGjeHuuB8TdQ4tPcqo9cydIufqMJryKrWTX8uTEIQmVvn0DX tT/zuFdeukOMQndv7SH5GJzuYEVFrse6GLQYhxSx/nZ10uPL54rLcUlN/ER2k94= =CFxA -----END PGP SIGNATURE----- --SUOF0GtieIMvvwua-- From owner-freebsd-net@freebsd.org Fri Aug 30 03:16:58 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EF68DE7B2E for ; Fri, 30 Aug 2019 03:16:58 +0000 (UTC) (envelope-from hrs@allbsd.org) Received: from mail.allbsd.org (mx.allbsd.org [IPv6:2001:2f0:104:e001::41]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature ECDSA (P-384) client-digest SHA384) (Client CN "mail.allbsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46KPlr1LqFz4ZGd for ; Fri, 30 Aug 2019 03:16:55 +0000 (UTC) (envelope-from hrs@allbsd.org) Received: from mail-d.allbsd.org ([IPv6:2409:11:a740:4700:58:65ff:fe00:b0b]) (authenticated bits=56) by mail.allbsd.org (8.15.2/8.15.2) with ESMTPSA id x7U3GAEx068852 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=OK) (Client CN "/CN=mail-d.allbsd.org", Issuer "/C=US/O=Let's+20Encrypt/CN=Let's+20Encrypt+20Authority+20X3"); Fri, 30 Aug 2019 12:16:28 +0900 (JST) (envelope-from hrs@allbsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=allbsd.org; s=20190220; t=1567134999; bh=Xnw+T+T6jsAnkXtQeaitynaY2FDPDv/CZB9RGdcau44=; h=Date:To:Cc:From:In-Reply-To:References; b=sNWhVb/ilaeIR31puj+LeduEuLR6hlNP/oGJ/u0NOWW3bgdPRfuAo5hVJqBCaBOS+ ISsrRxcmDqK9SWA7gAZzwrQpa5+8f7h0fW3za59EiQedYazcc0UDafZRKAJQDBRpB9 opq2BQq5jQPbdx3Pbjex3aa6UoOWtg6ePtsiAQzA= Received: from alph.d.allbsd.org ([IPv6:2409:11:a740:4700:16:ceff:fe34:2700]) by mail-d.allbsd.org (8.15.2/8.15.2) with ESMTPS id x7U3G405010826 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 30 Aug 2019 12:16:04 +0900 (JST) (envelope-from hrs@allbsd.org) Received: from localhost (localhost [[UNIX: localhost]]) (authenticated bits=0) by alph.d.allbsd.org (8.15.2/8.15.2) with ESMTPA id x7U3G0eZ010822; Fri, 30 Aug 2019 12:16:04 +0900 (JST) (envelope-from hrs@allbsd.org) Date: Fri, 30 Aug 2019 12:15:43 +0900 (JST) Message-Id: <20190830.121543.1108900942284640156.hrs@allbsd.org> To: vas@mpeks.tomsk.su Cc: freebsd-net@freebsd.org Subject: Re: Several IPv6 routers and default gateway choice From: Hiroki Sato In-Reply-To: <20190830021228.GA66465@admin.sibptus.ru> References: <20190830021228.GA66465@admin.sibptus.ru> X-Old-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-PGPkey-fingerprint: 6C0D 2353 27CF 80C7 901E FDD2 DBB0 7DC6 6F1F 737F X-Mailer: Mew version 6.8 on Emacs 26.2 Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="--Security_Multipart(Fri_Aug_30_12_15_43_2019_253)--" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (mail.allbsd.org [IPv6:2001:2f0:104:e001:0:0:0:41]); Fri, 30 Aug 2019 12:16:39 +0900 (JST) X-Rspamd-Queue-Id: 46KPlr1LqFz4ZGd X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=allbsd.org header.s=20190220 header.b=sNWhVb/i; dmarc=none; spf=pass (mx1.freebsd.org: domain of hrs@allbsd.org designates 2001:2f0:104:e001::41 as permitted sender) smtp.mailfrom=hrs@allbsd.org X-Spamd-Result: default: False [-6.24 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[allbsd.org:s=20190220]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MV_CASE(0.50)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[allbsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[allbsd.org:+]; RCPT_COUNT_TWO(0.00)[2]; MID_CONTAINS_FROM(1.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.989,0]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:7514, ipnet:2001:2f0::/32, country:JP]; IP_SCORE(-2.15)[ip: (-9.76), ipnet: 2001:2f0::/32(-4.31), asn: 7514(3.33), country: JP(-0.03)] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 03:16:59 -0000 ----Security_Multipart(Fri_Aug_30_12_15_43_2019_253)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Victor Sudakov wrote in <20190830021228.GA66465@admin.sibptus.ru>: va> Dear Colleagues, va> va> If a FreeBSD host receives router advertisements from several IPv6 va> routers, on a LAN segment, which would be chosen as the default gateway? One reachable router will be selected based on the default router preference value in RA, which is defined in RFC 4191. If all of the routers have the same preference, the first one will win. va> Can this be used for failover? Yes. Another way to realize failover is to use a common anycast address on multiple routers. For example, a router is always able to have fe80::/64 as an anycast address like this: router# ifconfig igb0 inet6 fe80::/64 anycast and you can simply configure fe80::/64 as the default router on the hosts. Multiple routers with the same fe80::/64 can coexist on the same segment, and hosts will choose one of them with no further configuration. A caveat in this case is that the first router always wins and there is no knob to set the preferences across the routers with the same anycast address configured. -- Hiroki ----Security_Multipart(Fri_Aug_30_12_15_43_2019_253)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iMgEABMKAC0WIQRsDSNTJ8+Ax5Ae/dLbsH3Gbx9zfwUCXWiU3w8caHJzQGFsbGJz ZC5vcmcACgkQ27B9xm8fc3/TcAIIpMfBK171VP5Wr0/6zkFZo3liHRZWReklB/dY 5Ot4kIBkzuogJLAImvikDG2M7RAPQ2O9tu26iq5/+8dSWM7WsSsCCQHQUtZvtqKp XuRAfgfyru94ji3gdN0liAWdpkBxEMPlUgUsTlSVnA9s+JUKitChfAICvnEAbd6N WYsQrM4fLdEHbg== =qcBz -----END PGP SIGNATURE----- ----Security_Multipart(Fri_Aug_30_12_15_43_2019_253)---- From owner-freebsd-net@freebsd.org Fri Aug 30 10:27:42 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DFBECCA2D7 for ; Fri, 30 Aug 2019 10:27:42 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46KbJt5bcvz3xdx; Fri, 30 Aug 2019 10:27:42 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.codepro.be", Issuer "Let's Encrypt Authority X3" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id 577594EF8; Fri, 30 Aug 2019 10:27:42 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from [10.0.2.193] (ptr-8rh08k1b8redszod2a3.18120a2.ip6.access.telenet.be [IPv6:2a02:1811:240e:402:d582:93b8:315d:d0cb]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id 1217F397E8; Fri, 30 Aug 2019 12:27:41 +0200 (CEST) From: "Kristof Provost" To: "Goran =?utf-8?q?Meki=C4=87?=" Cc: "Andrew White" , freebsd-net@freebsd.org Subject: Re: pf (rules and nat) + (ipfw + dummynet) Date: Fri, 30 Aug 2019 12:27:40 +0200 X-Mailer: MailMate (2.0BETAr6137) Message-ID: In-Reply-To: <20190818093346.jjxdjkd5twzfg56c@hal9000.home.meka.rs> References: <20190817215151.GA8888@vega.codepro.be> <20190818093346.jjxdjkd5twzfg56c@hal9000.home.meka.rs> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 10:27:42 -0000 On 18 Aug 2019, at 11:33, Goran Meki=C4=87 wrote: > Hello, > > If I knew we almost made it compile and boot (with dummynet, pf and = > pflog loaded), > I would postpone the previous email. :o) > > The code I'm working on is = > https://github.com/mekanix/freebsd/tree/feature/pf+dummynet/12.0. > It is nothing more than releng/12.0 branch into which I copied parts = > of PFSense > code until it started working. I still don't know how to test it, as = > I'm not > sure what's the PFSense's syntax for pf.conf. I know you can use "ipfw > pipe list" to show the pipes without ipfw module loaded. Once loaded, > ipfw lets you manage dummynet. What I do for now is load ipfw, set the > pipes, unload ipfw. > > If anyone knows how to configure pf.conf so that it passes everything > it receives to dummynet, I'm all ears. I will "fork" /sbin/ipfw and > create /sbin/dnctl so we don't have to depend on IPFW at all, but I > would like it to start working like this, first. > Apple do this through dnctl as you=E2=80=99re proposing: = http://www.manpagez.com/man/8/dnctl/ They=E2=80=99ve even published source code for it: = https://opensource.apple.com/source/network_cmds/network_cmds-543.260.3/d= nctl/ I=E2=80=99m somewhat tempted towards an approach where the pipe definitio= ns = are part of pf.conf, for similarity with how ALTQ worked in pf, and how = dummynet now works in ipfw. That=E2=80=99s probably not a hard requiremen= t = though. If it makes more sense to have two tools then let=E2=80=99s go fo= r = that. > My concerns about this patch is that it changes IPFW, too. I don't = > know > if the following link is visible if you're not logged into github, but > it shows the difference between releng/12.0 and this branch: > https://github.com/freebsd/freebsd/compare/releng/12.0...mekanix:featur= e/pf+dummynet/12.0?expand=3D1 > One of the issues I have with the PFSense patches is that they=E2=80=99re= not = broken down into usefully documented chunks. From a quick look that diff = seems to contain completely unrelated changes. Part of the effort is certainly going to be to tease that apart, and = work out what bits are relevant (and *why*). Best regards, Kristof From owner-freebsd-net@freebsd.org Fri Aug 30 11:19:06 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4A9D5CB45F for ; Fri, 30 Aug 2019 11:19:06 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from sender4-of-o59.zoho.com (sender4-of-o59.zoho.com [136.143.188.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46KcS85cN3z4109 for ; Fri, 30 Aug 2019 11:19:04 +0000 (UTC) (envelope-from patfbsd@davenulle.org) ARC-Seal: i=1; a=rsa-sha256; t=1567163941; cv=none; d=zoho.com; s=zohoarc; b=Lbkog3vtZ0njz1v3vRcEVVAT+BoOt7B5BcqiiAmTCmxuDRamPv4RrfaFSaBKIAr63KBSj+EvD+kxrX/Y+l1Gc80LzfFiQeJaJVFhcAkXT3hDLWt3kNfcbHvfI9jGlyVQvLiUjxVm6Ax7hrTJMtdo1QGW5GeKH0eqnj48rsSEFLg= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1567163941; h=Content-Type:Content-Transfer-Encoding:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results; bh=7z8QAvzBA8XXn2axV+W6V7qsi30wSwDOm5XMz3upOs0=; b=Xn6kSDSQukxYgw7pz80YCeW/lwdE3gCedqfnYZO2B9mZdFCudtYv/Xibzu007gx4NtXCJL5A1eyI19qcwMTnHpWEOJX7GbFOfTZpY2F5sNi+KJmZqrlhXyYFXaX5yYjS8A3ddnjq06c+Mq+EA222w40pMnIMEiTQK7OAi9XaXYI= ARC-Authentication-Results: i=1; mx.zoho.com; dkim=pass header.i=davenulle.org; spf=pass smtp.mailfrom=patfbsd@davenulle.org; dmarc=pass header.from= header.from= Received: from mr185033.univ-rennes1.fr (mr185033.univ-rennes1.fr [129.20.185.33]) by mx.zohomail.com with SMTPS id 1567163939869532.453351156497; Fri, 30 Aug 2019 04:18:59 -0700 (PDT) Date: Fri, 30 Aug 2019 13:18:52 +0200 From: Patrick Lamaiziere To: freebsd-net@freebsd.org Subject: Re: problem with carp on 11.3-RELEASE Message-ID: <20190830131852.42604d56@mr185033.univ-rennes1.fr> In-Reply-To: <20190829125441.12197ea8@mr185033.univ-rennes1.fr> References: <20190829125441.12197ea8@mr185033.univ-rennes1.fr> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ZohoMailClient: External X-Rspamd-Queue-Id: 46KcS85cN3z4109 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of patfbsd@davenulle.org has no SPF policy when checking 136.143.188.59) smtp.mailfrom=patfbsd@davenulle.org X-Spamd-Result: default: False [-5.75 / 15.00]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[davenulle.org]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-1.66)[ipnet: 136.143.188.0/24(-4.86), asn: 2639(-3.39), country: US(-0.05)]; NEURAL_HAM_SHORT(-0.99)[-0.987,0]; RCVD_IN_DNSWL_NONE(0.00)[59.188.143.136.list.dnswl.org : 127.0.15.0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:2639, ipnet:136.143.188.0/24, country:US]; ARC_ALLOW(-1.00)[i=1] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 11:19:06 -0000 On Thu, 29 Aug 2019 12:54:41 +0200 Patrick Lamaiziere wrote: Hello, > I've upgraded our two firewalls from 11.2-RELEASE-p11 to 11.3 release > p3 and I'm seeing a problem with carp, the carp slave becomes briefly > MASTER and returns to the slave state. This occurs often. ... I've made an other attempt today and all is working fine. I don't know where was the issue but I think that's not related to FreeBSD. Sorry for the noise :-) Regards. From owner-freebsd-net@freebsd.org Fri Aug 30 11:48:55 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DD791CBF1B for ; Fri, 30 Aug 2019 11:48:55 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from sender4-of-o59.zoho.com (sender4-of-o59.zoho.com [136.143.188.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46Kd6b1BXjz42Gg for ; Fri, 30 Aug 2019 11:48:54 +0000 (UTC) (envelope-from patfbsd@davenulle.org) ARC-Seal: i=1; a=rsa-sha256; t=1567165733; cv=none; d=zoho.com; s=zohoarc; b=dsHh4gPdPFI6+VED4ewT5K339i6EMaD/pOZRv6cQ7vbg356UrGn+U1Zm1srj1mKRjgOzlIJNer2saeUzfxBrX5bHHbZ/SJtd9krPHsa9fbwN5HfYmJXUOd4BNaiYD5xDU+6OmgbcZxJ0cCpDv676GHwcXmFFtjHWXD2xFVzNuWw= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1567165733; h=Content-Type:Content-Transfer-Encoding:Date:From:MIME-Version:Message-ID:Subject:To:ARC-Authentication-Results; bh=qduM/vUwMKm0NWyVxpbECfY6LAC0xq22YHqPx/paXRg=; b=KjK86Wve5PuHnKUpsHEEaUSUms2H9uAXJQp8BmQndewrSLPfIMdLV5EJLqQ9OHkn2YQMJ49kit0N32vZuIuF6e3iFGe10f1WwOtaFoTVp2M8x207uW4WHURlO3nQEDX7uF9A6ikqgANIsGTCAB5WMYfBQtG1gYYacwee907CcYE= ARC-Authentication-Results: i=1; mx.zoho.com; dkim=pass header.i=davenulle.org; spf=pass smtp.mailfrom=patfbsd@davenulle.org; dmarc=pass header.from= header.from= Received: from mr185033.univ-rennes1.fr (mr185033.univ-rennes1.fr [129.20.185.33]) by mx.zohomail.com with SMTPS id 1567165732610289.05323946758983; Fri, 30 Aug 2019 04:48:52 -0700 (PDT) Date: Fri, 30 Aug 2019 13:48:45 +0200 From: Patrick Lamaiziere To: freebsd-net@freebsd.org Subject: (11.3) bsnmpd and trap Message-ID: <20190830134845.4b8a75ac@mr185033.univ-rennes1.fr> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ZohoMailClient: External X-Rspamd-Queue-Id: 46Kd6b1BXjz42Gg X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of patfbsd@davenulle.org has no SPF policy when checking 136.143.188.59) smtp.mailfrom=patfbsd@davenulle.org X-Spamd-Result: default: False [-5.75 / 15.00]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[davenulle.org]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-1.66)[ipnet: 136.143.188.0/24(-4.86), asn: 2639(-3.39), country: US(-0.05)]; NEURAL_HAM_SHORT(-0.99)[-0.987,0]; RCVD_IN_DNSWL_NONE(0.00)[59.188.143.136.list.dnswl.org : 127.0.15.0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:2639, ipnet:136.143.188.0/24, country:US]; RCVD_COUNT_TWO(0.00)[2]; ARC_ALLOW(-1.00)[i=1] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 11:48:55 -0000 Hello, bsnmpd sends a trap when an interface link goes up but not when the link goes down. Is there a way to have a trap when the link is down? Thanks, regards. From owner-freebsd-net@freebsd.org Fri Aug 30 12:19:06 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 214DECD52F for ; Fri, 30 Aug 2019 12:19:06 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (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 46KdnN2G4cz44KZ for ; Fri, 30 Aug 2019 12:19:03 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id x7UCIrYZ022829 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 30 Aug 2019 12:18:53 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: patfbsd@davenulle.org Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id x7UCIix8057353 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 30 Aug 2019 19:18:44 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: (11.3) bsnmpd and trap To: Patrick Lamaiziere , freebsd-net@freebsd.org References: <20190830134845.4b8a75ac@mr185033.univ-rennes1.fr> From: Eugene Grosbein Message-ID: Date: Fri, 30 Aug 2019 19:18:35 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20190830134845.4b8a75ac@mr185033.univ-rennes1.fr> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -0.0 SPF_PASS SPF: sender matches SPF record * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 46KdnN2G4cz44KZ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-4.68 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_PERMFAIL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.98)[-0.981,0]; IP_SCORE(-1.59)[ip: (-4.19), ipnet: 2a01:4f8::/29(-1.97), asn: 24940(-1.80), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 12:19:06 -0000 30.08.2019 18:48, Patrick Lamaiziere wrote: > bsnmpd sends a trap when an interface link goes up but not when the > link goes down. > > Is there a way to have a trap when the link is down? Are you sure you not trying to send a trap for broken link over same link? :-) From owner-freebsd-net@freebsd.org Fri Aug 30 12:38:07 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 98ECECDCAF for ; Fri, 30 Aug 2019 12:38:07 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from sender-of-o53.zoho.com (sender-of-o53.zoho.com [135.84.80.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46KfCL4v2Nz45Ct for ; Fri, 30 Aug 2019 12:38:06 +0000 (UTC) (envelope-from patfbsd@davenulle.org) ARC-Seal: i=1; a=rsa-sha256; t=1567168681; cv=none; d=zoho.com; s=zohoarc; b=n51ADnEhWJItbSDtX5BIgpB80pXBq7Bbo8iX1c6GaP+BMGYSxC3vl+gO5W0/zpUNIQ7Wk4w1bq6oZRR2rm2rAVVJRYdcjngYYNzTImFB4kqgnaTsuZ0WO0rYZ4kk5dDCRlGwTN1Kfm94fK9kn89m+7umFYAuFaKsWUJqPEg47q4= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1567168681; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:ARC-Authentication-Results; bh=VjRUgy7vhTNAiPD05IhumbMaAwkodHg7Rb2MKJ8GKZI=; b=LByJUlao3eS2jFLjnaO0kU+SOxpkb+aHE2uR11UrhyX2pKBHlMZ9t6YEV1eQbC4zvCii7y7nWxql5AGolGRWZFoox/q3cO4fmk9uNgBaY1itviplQZET52+MwviCeRDBX2NIhHecMowbiDXkLG6/4jYMEHOBF9imasJUx1LZdrg= ARC-Authentication-Results: i=1; mx.zoho.com; dkim=pass header.i=davenulle.org; spf=pass smtp.mailfrom=patfbsd@davenulle.org; dmarc=pass header.from= header.from= Received: from mr185033.univ-rennes1.fr (mr185033.univ-rennes1.fr [129.20.185.33]) by mx.zohomail.com with SMTPS id 1567168678811177.66384931733114; Fri, 30 Aug 2019 05:37:58 -0700 (PDT) Date: Fri, 30 Aug 2019 14:37:37 +0200 From: Patrick Lamaiziere Cc: Eugene Grosbein , freebsd-net@freebsd.org Subject: Re: (11.3) bsnmpd and trap Message-ID: <20190830143737.21767c38@mr185033.univ-rennes1.fr> In-Reply-To: References: <20190830134845.4b8a75ac@mr185033.univ-rennes1.fr> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ZohoMailClient: External X-Rspamd-Queue-Id: 46KfCL4v2Nz45Ct X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of patfbsd@davenulle.org has no SPF policy when checking 135.84.80.218) smtp.mailfrom=patfbsd@davenulle.org X-Spamd-Result: default: False [-5.40 / 15.00]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[davenulle.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.96)[-0.958,0]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[218.80.84.135.list.dnswl.org : 127.0.15.0]; MISSING_TO(2.00)[]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:2639, ipnet:135.84.80.0/24, country:US]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE(-3.34)[ip: (-8.55), ipnet: 135.84.80.0/24(-4.72), asn: 2639(-3.39), country: US(-0.05)]; ARC_ALLOW(-1.00)[i=1] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 12:38:07 -0000 On Fri, 30 Aug 2019 19:18:35 +0700 Eugene Grosbein wrote: > > bsnmpd sends a trap when an interface link goes up but not when the > > link goes down. > > > > Is there a way to have a trap when the link is down? > > Are you sure you not trying to send a trap for broken link over same > link? :-) Yes I'm sure :-) The interface to the snmp trap server is ix2 and i tried with the link of ibg0 (a link to a DMZ) Trap works fine with net-snmpd but I would like to remove it cause of some bugs. I've to patch it https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231996 Regards, From owner-freebsd-net@freebsd.org Sat Aug 31 00:30:57 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CD3ECDC457 for ; Sat, 31 Aug 2019 00:30:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 46Ky1s58JXz3F7w for ; Sat, 31 Aug 2019 00:30:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id B0B09DC456; Sat, 31 Aug 2019 00:30:57 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B06E4DC455 for ; Sat, 31 Aug 2019 00:30:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46Ky1s4Jyjz3F7v for ; Sat, 31 Aug 2019 00:30:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 760158691 for ; Sat, 31 Aug 2019 00:30:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x7V0Uuq3099650 for ; Sat, 31 Aug 2019 00:30:57 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x7V0Uubr099347 for net@FreeBSD.org; Sat, 31 Aug 2019 00:30:56 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 239240] igb: TX(2) desc avail = 1024, pidx = 0 messages appear when the network card loses ethernet link Date: Sat, 31 Aug 2019 00:30:23 +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: 12.0-RELEASE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: peterj@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_severity cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2019 00:30:57 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D239240 Peter Jeremy changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|Affects Only Me |Affects Some People CC| |peterj@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sat Aug 31 01:04:34 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 50F47DCECD for ; Sat, 31 Aug 2019 01:04:34 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (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 46Kymd0gbMz3HGQ for ; Sat, 31 Aug 2019 01:04:32 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id x7V14NOp038385 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 31 Aug 2019 01:04:24 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: patfbsd@davenulle.org Received: from [10.58.0.4] (dadv@[10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id x7V14JW0066398 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 31 Aug 2019 08:04:20 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: (11.3) bsnmpd and trap To: Patrick Lamaiziere References: <20190830134845.4b8a75ac@mr185033.univ-rennes1.fr> <20190830143737.21767c38@mr185033.univ-rennes1.fr> Cc: freebsd-net@freebsd.org From: Eugene Grosbein Message-ID: <53020df3-e555-e46e-301b-f5552397fa46@grosbein.net> Date: Sat, 31 Aug 2019 08:04:11 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20190830143737.21767c38@mr185033.univ-rennes1.fr> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 46Kymd0gbMz3HGQ X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-3.60 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; R_BAD_CTE_7BIT(1.05)[7bit,utf8]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_PERMFAIL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.97)[-0.969,0]; IP_SCORE(-1.58)[ip: (-4.10), ipnet: 2a01:4f8::/29(-1.97), asn: 24940(-1.81), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2019 01:04:34 -0000 30.08.2019 19:37, Patrick Lamaiziere пишет: > On Fri, 30 Aug 2019 19:18:35 +0700 > Eugene Grosbein wrote: > >>> bsnmpd sends a trap when an interface link goes up but not when the >>> link goes down. >>> >>> Is there a way to have a trap when the link is down? >> >> Are you sure you not trying to send a trap for broken link over same >> link? :-) > > Yes I'm sure :-) > The interface to the snmp trap server is ix2 and i tried with the > link of ibg0 (a link to a DMZ) Does your kernel write a notification to dmesg for this event? Have you verified that devd(8) is running meantime? From owner-freebsd-net@freebsd.org Sat Aug 31 01:04:49 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 84E8BDCF24 for ; Sat, 31 Aug 2019 01:04:49 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (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 46Kymw70qPz3HKf for ; Sat, 31 Aug 2019 01:04:48 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id x7V14hHf038406 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 31 Aug 2019 01:04:44 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: patfbsd@davenulle.org Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id x7V14eXY066407 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 31 Aug 2019 08:04:40 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: (11.3) bsnmpd and trap To: Patrick Lamaiziere References: <20190830134845.4b8a75ac@mr185033.univ-rennes1.fr> <20190830143737.21767c38@mr185033.univ-rennes1.fr> Cc: freebsd-net@freebsd.org From: Eugene Grosbein Message-ID: Date: Sat, 31 Aug 2019 08:04:26 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20190830143737.21767c38@mr185033.univ-rennes1.fr> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 46Kymw70qPz3HKf X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-4.67 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_PERMFAIL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.98)[-0.982,0]; IP_SCORE(-1.59)[ip: (-4.16), ipnet: 2a01:4f8::/29(-1.97), asn: 24940(-1.81), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2019 01:04:49 -0000 30.08.2019 19:37, Patrick Lamaiziere wrote: > On Fri, 30 Aug 2019 19:18:35 +0700 > Eugene Grosbein wrote: > >>> bsnmpd sends a trap when an interface link goes up but not when the >>> link goes down. >>> >>> Is there a way to have a trap when the link is down? >> >> Are you sure you not trying to send a trap for broken link over same >> link? :-) > > Yes I'm sure :-) > The interface to the snmp trap server is ix2 and i tried with the > link of ibg0 (a link to a DMZ) Does your kernel write a notification to dmesg for this event? Have you verified that devd(8) is running meantime? From owner-freebsd-net@freebsd.org Sat Aug 31 01:56:41 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E2042DFBCE for ; Sat, 31 Aug 2019 01:56:41 +0000 (UTC) (envelope-from rcv-YnNkLmxpc3RzQGg4c3BhbS5vcmcAQDE1NjcxOTQxODE=@vfemail.net) Received: from nl101-3.vfemail.net (nl101-3.vfemail.net [149.210.219.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46Kzwn03gtz3Lbj for ; Sat, 31 Aug 2019 01:56:40 +0000 (UTC) (envelope-from rcv-YnNkLmxpc3RzQGg4c3BhbS5vcmcAQDE1NjcxOTQxODE=@vfemail.net) Received: (qmail 22324 invoked from network); 30 Aug 2019 19:43:01 -0000 Received: by simscan 1.4.0 ppid: 22317, pid: 22322, t: 0.0058s scanners:none Received: from unknown (HELO dmZlbWFpbC5uZXRAMTU2NzE5NDE4MQ==) (YnNkLmxpc3RzQGg4c3BhbS5vcmdAMTU2NzE5NDE4MQ==@MTkyLjE2OC4xLjE5MkAxNTY3MTk0MTgx) by nl101.vfemail.net with ESMTPA; 30 Aug 2019 19:43:01 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 30 Aug 2019 18:56:39 -0700 From: bsd.lists@h8spam.org To: FreeBSD NET Subject: Difficulty using more than a 2 port NIC Message-ID: <7996a2e188386dff1d31f76621f5abae@h8spam.org> X-Sender: bsd.lists@h8spam.org User-Agent: Roundcube Webmail/1.2.3 X-Rspamd-Queue-Id: 46Kzwn03gtz3Lbj X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rcv-YnNkLmxpc3RzQGg4c3BhbS5vcmcAQDE1NjcxOTQxODE=@vfemail.net designates 149.210.219.33 as permitted sender) smtp.mailfrom=rcv-YnNkLmxpc3RzQGg4c3BhbS5vcmcAQDE1NjcxOTQxODE=@vfemail.net X-Spamd-Result: default: False [-4.41 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:149.210.219.33/32]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[h8spam.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-1.43)[ipnet: 149.210.128.0/17(-4.92), asn: 20857(-2.24), country: NL(0.01)]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.978,0]; FROM_NO_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FORGED_SENDER(0.30)[bsd.lists@h8spam.org,rcv-YnNkLmxpc3RzQGg4c3BhbS5vcmcAQDE1NjcxOTQxODE=@vfemail.net]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[vfemail.net]; ASN(0.00)[asn:20857, ipnet:149.210.128.0/17, country:NL]; FROM_NEQ_ENVFROM(0.00)[bsd.lists@h8spam.org,rcv-YnNkLmxpc3RzQGg4c3BhbS5vcmcAQDE1NjcxOTQxODE=@vfemail.net]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2019 01:56:41 -0000 I lease 7 public addresses. I'm running into a strange problem setting up a NIC with more than 2 (public) addresses. I initially did some research, and found an re(4) 2 port NIC that was well supported (RTL8169S). The host (box) I'm attempting all this on manages 3 addresses. So I simply set it up as follows ( rc.conf(5) ): hostname="sum.host-n.ame" # re0 ifconfig_re0="inet AA.BB.CC.83 netmask 255.255.255.0" # re1 ifconfig_re1="inet AA.BB.CC.82 netmask 255.255.255.0" ifconfig_re1_alias0="inet AA.BB.CC.86 netmask 255.255.255.0" defaultrouter="AA.BB.CC.1" ifconfig_re0_ipv6="inet6 accept_rtadv" ifconfig_re1_ipv6="inet6 accept_rtadv" And all worked as intended. HOWEVER, I wanted to have individual (NIC) ports for each address assigned to this server. So some more research, and I landed another realtek NIC with 4 ports (RTL8111G). Replaced the 2 port with this new one. The NIC was recognized, came up. But the network was hosed. I used the following ( rc.conf(5) ): hostname="sum.host-n.ame" # re0 ifconfig_re0="inet AA.BB.CC.83 netmask 255.255.255.0" # re1 ifconfig_re1="inet AA.BB.CC.82 netmask 255.255.255.0" # re2 ifconfig_re2="inet AA.BB.CC.86 netmask 255.255.255.0" defaultrouter="AA.BB.CC.1" ifconfig_re0_ipv6="inet6 accept_rtadv" ifconfig_re1_ipv6="inet6 accept_rtadv" ifconfig_re2_ipv6="inet6 accept_rtadv" Zero name resolution, and no other network services would work. The only service that required changes, was the DNS. Which only required adding the additional (listen on) stanza for the added NIC port. But the only network activity that seemed to work at all, was ping, and even then, only by IP address. Any thoughts on what might be the problem? Thank you for all your time, and consideration. --Chris OH not that it should really matter, but it's on an 11-STABLE box, destined for 12, or 13 CURRENT. Assuming I can sort this out. From owner-freebsd-net@freebsd.org Sat Aug 31 02:26:38 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E67C8E0C07 for ; Sat, 31 Aug 2019 02:26:38 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (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 46L0bK51Wdz3N5F for ; Sat, 31 Aug 2019 02:26:37 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id x7V2QXqb039501 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 31 Aug 2019 02:26:34 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: bsd.lists@h8spam.org Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id x7V2QTRK067128 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 31 Aug 2019 09:26:29 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Difficulty using more than a 2 port NIC To: bsd.lists@h8spam.org, FreeBSD NET References: <7996a2e188386dff1d31f76621f5abae@h8spam.org> From: Eugene Grosbein Message-ID: <1f71d773-9346-a811-1592-fa0d437df405@grosbein.net> Date: Sat, 31 Aug 2019 09:26:15 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <7996a2e188386dff1d31f76621f5abae@h8spam.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 46L0bK51Wdz3N5F X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-4.68 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_PERMFAIL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.98)[-0.982,0]; IP_SCORE(-1.60)[ip: (-4.21), ipnet: 2a01:4f8::/29(-1.97), asn: 24940(-1.81), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2019 02:26:39 -0000 31.08.2019 8:56, bsd.lists@h8spam.org wrote: > I lease 7 public addresses. > I'm running into a strange problem setting up a NIC > with more than 2 (public) addresses. > I initially did some research, and found an re(4) 2 > port NIC that was well supported (RTL8169S). > The host (box) I'm attempting all this on manages 3 > addresses. So I simply set it up as follows ( rc.conf(5) ): > > hostname="sum.host-n.ame" > # re0 > ifconfig_re0="inet AA.BB.CC.83 netmask 255.255.255.0" > # re1 > ifconfig_re1="inet AA.BB.CC.82 netmask 255.255.255.0" > ifconfig_re1_alias0="inet AA.BB.CC.86 netmask 255.255.255.0" > > defaultrouter="AA.BB.CC.1" > ifconfig_re0_ipv6="inet6 accept_rtadv" > ifconfig_re1_ipv6="inet6 accept_rtadv" > > And all worked as intended. You was a bit lucky. It is not supposed to work this way. Generally, you should not have more than single network interface attached to single IP subnet. Instead, you assign one of IPs as primary address and others as secondary addresses with mask /32. So you don't need additional physical ports to utilize any number of addresses. There are some cases when you use port aggregation for ports connected to same switch and subnet but then you still use single lagg(4) logical network interface to assign all your IPs. From owner-freebsd-net@freebsd.org Sat Aug 31 11:44:44 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C4773CF04E for ; Sat, 31 Aug 2019 11:44:44 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 46LDzJ0l5jz4Q43 for ; Sat, 31 Aug 2019 11:44:44 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: by mailman.nyi.freebsd.org (Postfix) id 19527CF04D; Sat, 31 Aug 2019 11:44:44 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 190C0CF04C for ; Sat, 31 Aug 2019 11:44:44 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 46LDzH1p0yz4Q42 for ; Sat, 31 Aug 2019 11:44:42 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from [192.168.0.102] (c110-21-101-228.carlnfd1.nsw.optusnet.com.au [110.21.101.228]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id 2BB8643DC5D; Sat, 31 Aug 2019 21:44:40 +1000 (AEST) Date: Sat, 31 Aug 2019 21:44:38 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Martin Birgmeier cc: net@freebsd.org Subject: Re: [Bug 235031] [em] em0: poor NFS performance, strange behavior In-Reply-To: Message-ID: <20190831212849.X1183@besplex.bde.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=FNpr/6gs c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=kj9zAlcOel0A:10 a=6I5d2MoRAAAA:8 a=TX4ivX0axYP3Q2pITWgA:9 a=CjuIK1q_8ugA:10 a=IjZwj45LgO3ly-622nXo:22 X-Rspamd-Queue-Id: 46LDzH1p0yz4Q42 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of brde@optusnet.com.au designates 211.29.132.246 as permitted sender) smtp.mailfrom=brde@optusnet.com.au X-Spamd-Result: default: False [-3.28 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCVD_IN_DNSWL_LOW(-0.10)[246.132.29.211.list.dnswl.org : 127.0.5.1]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:211.29.132.0/23:c]; FREEMAIL_FROM(0.00)[optusnet.com.au]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[optusnet.com.au]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.981,0]; RCPT_COUNT_TWO(0.00)[2]; IP_SCORE(0.00)[ip: (-7.01), ipnet: 211.28.0.0/14(-3.29), asn: 4804(-2.42), country: AU(0.01)]; FREEMAIL_TO(0.00)[aon.at]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[optusnet.com.au]; ASN(0.00)[asn:4804, ipnet:211.28.0.0/14, country:AU]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2019 11:44:44 -0000 On Thu, 15 Aug 2019 a bug that doesn't want replies@freebsd.org wrote: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235031 > > --- Comment #36 from Martin Birgmeier --- > I just notice that the console and syslog have about 20 messages of > > em: frame error: ignored > em: frame error: ignored > em: frame error: ignored > em: frame error: ignored > em: frame error: ignored > > Uptime is 2 1/2 hours. You seem to be using my old patch which is not in -current: Index: em_txrx.c XX =================================================================== XX --- em_txrx.c (revision 348771) XX +++ em_txrx.c (working copy) XX @@ -629,9 +629,20 @@ XX XX /* Make sure bad packets are discarded */ XX if (errors & E1000_RXD_ERR_FRAME_ERR_MASK) { XX +#if 0 XX adapter->dropped_pkts++; XX - /* XXX fixup if common */ XX return (EBADMSG); XX +#else XX + /* XX + * XXX the above error handling is worse than none. XX + * First it it drops 'i' packets before the current XX + * one and doesn't count them. Then it returns an XX + * error. iflib can't really handle this error. XX + * It just resets, and this usually drops many more XX + * packets (without counting them) and much time. XX + */ XX + printf("lem: frame error: ignored\n"); XX +#endif XX } XX XX ri->iri_frags[i].irf_flid = 0; XX @@ -692,8 +703,12 @@ XX XX /* Make sure bad packets are discarded */ XX if (staterr & E1000_RXDEXT_ERR_FRAME_ERR_MASK) { XX +#if 0 XX adapter->dropped_pkts++; XX return EBADMSG; XX +#else XX + printf("em: frame error: ignored\n"); XX +#endif XX } XX XX ri->iri_frags[i].irf_flid = 0; Without this patch, no message is printed and the device takes a long time to recover (when I wrote the patch, recovery was from something like a watchdog timeout after many seconds). With the patch, the recovery is good enough for nfs over udp to not lose any data or time out, but I don't trust this so I print the message. Pre-iflib versions of [l]em handled this correctly by dropping a single packet, which was easy to do. Unpatched iflib makes a mess by returning with subsequent packets unprocessed. It apparently just stops receiving until kicked by a watchdog. I don't know what causes this error. Maybe just a bad cable or switch. I don't see it for I218V with the same cable and switch. Bruce From owner-freebsd-net@freebsd.org Sat Aug 31 13:30:36 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DB49DD2277 for ; Sat, 31 Aug 2019 13:30:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 46LHKS4qWKz4VHv for ; Sat, 31 Aug 2019 13:30:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id A2F35D2276; Sat, 31 Aug 2019 13:30:36 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A2ABED2275 for ; Sat, 31 Aug 2019 13:30:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46LHKS35JCz4VHq for ; Sat, 31 Aug 2019 13:30:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4311319851 for ; Sat, 31 Aug 2019 13:30:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x7VDUaYX072368 for ; Sat, 31 Aug 2019 13:30:36 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x7VDUaLT072367 for net@FreeBSD.org; Sat, 31 Aug 2019 13:30:36 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 235031] [em] em0: poor NFS performance, strange behavior Date: Sat, 31 Aug 2019 13:30:34 +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: 12.0-RELEASE X-Bugzilla-Keywords: IntelNetworking, regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: d8zNeCFG@aon.at X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@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.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2019 13:30:36 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D235031 --- Comment #37 from Martin Birgmeier --- (Adding Bruce's mail here:) On 31.08.19 13:44, Bruce Evans wrote: > On Thu, 15 Aug 2019 a bug that doesn't want replies at freebsd.org wrote: > >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D235031 >> >> --- Comment #36 from Martin Birgmeier --- >> I just notice that the console and syslog have about 20 messages of >> >> em: frame error: ignored >> em: frame error: ignored >> em: frame error: ignored >> em: frame error: ignored >> em: frame error: ignored >> >> Uptime is 2 1/2 hours.=20 > > You seem to be using my old patch which is not in -current: > > Index: em_txrx.c > XX =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 > XX --- em_txrx.c (revision 348771) > XX +++ em_txrx.c (working copy) > XX @@ -629,9 +629,20 @@ > XX XX /* Make sure bad packets are discarded */ > XX if (errors & E1000_RXD_ERR_FRAME_ERR_MASK) { > XX +#if 0 > XX adapter->dropped_pkts++; > XX - /* XXX fixup if common */ > XX return (EBADMSG); > XX +#else > XX + /* > XX + * XXX the above error handling is worse than none. > XX + * First it it drops 'i' packets before the current > XX + * one and doesn't count them. Then it returns an > XX + * error. iflib can't really handle this error. > XX + * It just resets, and this usually drops many more > XX + * packets (without counting them) and much time. > XX + */ > XX + printf("lem: frame error: ignored\n"); > XX +#endif > XX } > XX XX ri->iri_frags[i].irf_flid =3D 0; > XX @@ -692,8 +703,12 @@ > XX XX /* Make sure bad packets are discarded */ > XX if (staterr & E1000_RXDEXT_ERR_FRAME_ERR_MASK) { > XX +#if 0 > XX adapter->dropped_pkts++; > XX return EBADMSG; > XX +#else > XX + printf("em: frame error: ignored\n"); > XX +#endif > XX } > XX XX ri->iri_frags[i].irf_flid =3D 0; > > Without this patch, no message is printed and the device takes a long > time to recover (when I wrote the patch, recovery was from something > like a watchdog timeout after many seconds). With the patch, the recovery > is good enough for nfs over udp to not lose any data or time out, but I > don't trust this so I print the message. > > Pre-iflib versions of [l]em handled this correctly by dropping a single > packet, which was easy to do. Unpatched iflib makes a mess by returning > with subsequent packets unprocessed. It apparently just stops receiving > until kicked by a watchdog. > > I don't know what causes this error. Maybe just a bad cable or switch. > I don't see it for I218V with the same cable and switch. > > Bruce --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sat Aug 31 13:35:22 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DB84DD2610 for ; Sat, 31 Aug 2019 13:35:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 46LHQy5WdVz4Vfh for ; Sat, 31 Aug 2019 13:35:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id BD6E0D260E; Sat, 31 Aug 2019 13:35:22 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BD1F6D260D for ; Sat, 31 Aug 2019 13:35:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46LHQy4SwYz4Vfg for ; Sat, 31 Aug 2019 13:35:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 7979B19A14 for ; Sat, 31 Aug 2019 13:35:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x7VDZM4I089317 for ; Sat, 31 Aug 2019 13:35:22 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x7VDZMJn089315 for net@FreeBSD.org; Sat, 31 Aug 2019 13:35:22 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 235031] [em] em0: poor NFS performance, strange behavior Date: Sat, 31 Aug 2019 13:35:21 +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: 12.0-RELEASE X-Bugzilla-Keywords: IntelNetworking, regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: d8zNeCFG@aon.at X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@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.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2019 13:35:22 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D235031 --- Comment #38 from Martin Birgmeier --- Your are right, I forgot to remove this patch when updating to the latest 1= 2.0 patchlevel. But I guess that should not adversely affect the driver. Anyway, with the patch performance was just good enough to let some NFS through. However, this certainly is no hardware problem because when using the driver from ports (net/intel-em-kmod) performance is perfect. Something is still very broken with the conversion of this driver to iflib. I just noticed that comment #34 just shows a merge to stable/12, but I am running releng/12.0. So I should probably merge this stuff and see how that works. -- Martin --=20 You are receiving this mail because: You are the assignee for the bug.=