From nobody Mon Jan 17 05:09:50 2022 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6096D196DD24 for ; Mon, 17 Jan 2022 05:10:05 +0000 (UTC) (envelope-from ggm@algebras.org) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jcg2N3gSTz3s8v for ; Mon, 17 Jan 2022 05:10:04 +0000 (UTC) (envelope-from ggm@algebras.org) Received: by mail-lf1-x12b.google.com with SMTP id d3so53038658lfv.13 for ; Sun, 16 Jan 2022 21:10:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Yy5U+E7YKmMUxTT+SKrikDxB+sVfoAdsoFTnsTF5rAs=; b=oTbds6uFQDEglQNoNzZhJsqbKWHxH+aovp17AMofxl+H4EHPcLZT/aQ00yHFrBbdkB QnvpLhq5uIFEOqPopWnyKT5mpYKyeDeTjPjv8+9Z+1/AaKyYULBp6tTIvXeoZBJFgmLG RajV3KxIUVXI2bYo+Qm3moGPV4jid7r1AfDIGooSOEOqPDJOdQKFQJ9zTNT6HXOWf77U CfqAksFbF53PZj1GvRyIFQmyu7b6L68GUyeg5q1jgH9937XbQ4HQN2e8ZNYarmERMrtD 5Vh5KEmNLZP0SOxa9T7hkLJvoHG+jvmzfMVpoRP7XdJynZAfz8W+7hv0N5C/dul+Wpgo Ugqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Yy5U+E7YKmMUxTT+SKrikDxB+sVfoAdsoFTnsTF5rAs=; b=DyufMeZHqg3+tMLnV8SnpTh76y/i7XLWSX7NUMI5x/UMe/kZZnMtoDJOJ5hsUqhIPJ Ig+VSCyYF2JSYD4C5mKSb+Y9QSw1Zf+sHBSClF3CFQO8VHCBYBv5UCTtB6eWYY8Q+7VL E0JfmwMG0aPtUiDJDvkp7qMMDeaEwFdWdrAlg6TsZ4amzuqHig7WS4/N3NOu5wlZMvY1 mI1kKUdpoB6LtoZCO99Y0FF4ip5GZRCyDybRPNOqXM95UTRlxntpenR1d+EtmnFaGkIk XbmOCj3D6jPoCpXEdLkaEJ+1SjohibMFqRUh/RqJnAwSe3bLx09ouqO/bCF4xJRCFCkh zSPw== X-Gm-Message-State: AOAM533H7GFd0QogFuY+F0gCXLHNRtXyHm7pE88ef8twylEVfcCwhnXt IsP5TWHLwQgLqa7zBP7WTGmTakVuShftwqg1UvBnK47rozM= X-Google-Smtp-Source: ABdhPJzH1rNhmfkwNCXbybaRR7UjvrfcZxUzqAqy1PX67mEvHyFpHoaZSzLRHhjEI9InZlD8cy3X+JqsiRfeqLVQ+A0= X-Received: by 2002:a2e:a5c9:: with SMTP id n9mr15035147ljp.220.1642396201875; Sun, 16 Jan 2022 21:10:01 -0800 (PST) List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: George Michaelson Date: Mon, 17 Jan 2022 15:09:50 +1000 Message-ID: Subject: Re: can't bridge an I/F with jumbo to taps, deleted bridge 'flags' are sticky if you remake them To: "Patrick M. Hausen" Cc: freebsd-net@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4Jcg2N3gSTz3s8v X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=algebras-org.20210112.gappssmtp.com header.s=20210112 header.b=oTbds6uF; dmarc=none; spf=pass (mx1.freebsd.org: domain of ggm@algebras.org designates 2a00:1450:4864:20::12b as permitted sender) smtp.mailfrom=ggm@algebras.org X-Spamd-Result: default: False [0.50 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; R_DKIM_ALLOW(-0.20)[algebras-org.20210112.gappssmtp.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; NEURAL_SPAM_SHORT(1.00)[1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; DMARC_NA(0.00)[algebras.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[algebras-org.20210112.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::12b:from]; NEURAL_SPAM_LONG(1.00)[1.000]; MLMMJ_DEST(0.00)[freebsd-net]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N I tested on FreeBSD 13 and the behaviour is the same. But, I want to withdraw an imputation this is a bug. The underlying behaviour is that you can't bond an MTU9000 and an MTU1500 interface. If the base device is set jumbo, then the tapX instances must be set jumbo. once you set MTU to match, it works fine on both FreeBSD12 and on FreeBSD13. It's probably a documentation nit, if anything: bridged devices should have identical MTU. The ifconfig bridge command will refuse to addm if the MTU is not correct for the any other member of the bridge group. cheers -George On Thu, Jan 13, 2022 at 6:15 PM Patrick M. Hausen wrote: > > Hi all, > > > Am 13.01.2022 um 06:41 schrieb George Michaelson : > > > > I just found a couple of odd quirks in bridge > > > > 1) you can't bridge an MTU 9000 interface to taps. If you dial it back > > to 1500 it works fine. I might have missed this being a limit in the > > man > > > > 2) when you delete a bridge, and re-create it, some of the addm > > "history" can come live. faulty debug suggests some state in the > > kernel/network space isn't wiped clean. Maybe this is a good thing, > > the most likely outcome is you wanted much the same but.... POLA > > > > FreeBSD 12-2-RELEASE-p6 (if this is fixed in newer FreeBSD) > > Are you in a position to test FreeBSD 13? The bridge code has been > more or less completely rewritten. > > Kind regards, > Patrick > -- > punkt.de GmbH > Patrick M. Hausen > .infrastructure > > Kaiserallee 13a > 76133 Karlsruhe > > Tel. +49 721 9109500 > > https://infrastructure.punkt.de > info@punkt.de > > AG Mannheim 108285 > Gesch=C3=A4ftsf=C3=BChrer: J=C3=BCrgen Egeling, Daniel Lienert, Fabian St= ein >