Date: Wed, 30 Jul 2025 21:54:01 +0000 From: "Patrick M. Hausen" <hausen@punkt.de> To: Lexi Winter <ivy@freebsd.org> Cc: "net@freebsd.org" <net@freebsd.org> Subject: Re: vlan(4) and bridge(4) on same interface Message-ID: <3BDCB8E6-5E49-4242-B00E-BBBCAD51EEC3@punkt.de> In-Reply-To: <aIqT4lOqRZD8kOCn@freefall.freebsd.org> References: <aIo0kN79B6JymlAh@freefall.freebsd.org> <s124p67o-os20-16s9-n227-599184n43s7o@yvfgf.mnoonqbm.arg> <aIqDoyIbOf9VNo3d@freefall.freebsd.org> <83AAB529-4AA4-4C71-9B9E-9CD568128A67@punkt.de> <aIqMp6LhOMK1LEj7@freefall.freebsd.org> <F5B57005-EFFA-4DDA-AB0D-503E04D6A23D@punkt.de> <aIqT4lOqRZD8kOCn@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, > Am 30.07.2025 um 23:51 schrieb Lexi Winter <ivy@freebsd.org>: > > Patrick M. Hausen: >>> Am 30.07.2025 um 23:20 schrieb Lexi Winter <ivy@freebsd.org>: >>> the situation i'm talking about is when you have a vlan(4) configured on >>> an interface, and the underlying interface (not the vlan interface) is >>> also in a bridge, for example: >> >> But that configuration has always been illegal and known to fail >> in weird ways. Just like putting a layer 3 address on a bridge member >> interface. >> >> So I still wonder what the problem seems to be. > > it seems like you agree with me that we shouldn't allow this. the > problem is that we *do* currently allow this, so what i'm proposing > is that we disallow it and produce an error message instead. > > does that sound reasonable to you or have i misunderstood? Absolutely. We should prohibit configurations that were never supported in the first place. Repeating my "fail early, fail hard" argument. I am not debating you in this thread ;-) Kind regards, Patrick -- punkt.de GmbH Patrick M. Hausen .infrastructure Sophienstr. 187 76185 Karlsruhe Tel. +49 721 9109500 https://infrastructure.punkt.de info@punkt.de AG Mannheim 108285 Geschäftsführer: Daniel Lienert, Fabian Stein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3BDCB8E6-5E49-4242-B00E-BBBCAD51EEC3>