From nobody Wed Jul 30 17:28:08 2025 X-Original-To: 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 4bsfM21QSGz62pn9 for ; Wed, 30 Jul 2025 17:28:30 +0000 (UTC) (envelope-from vova@fbsd.ru) Received: from fbsd.ru (mx.fbsd.ru [178.213.227.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4bsfM158f4z3t2d; Wed, 30 Jul 2025 17:28:29 +0000 (UTC) (envelope-from vova@fbsd.ru) Authentication-Results: mx1.freebsd.org; none Received: from [172.22.9.9] (helo=smtpclient.apple) by fbsd.ru with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2 (FreeBSD)) (envelope-from ) id 1uhAbD-00000000HEJ-2rpB; Wed, 30 Jul 2025 20:28:19 +0300 Content-Type: text/plain; charset=utf-8 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 (Mac OS X Mail 16.0 \(3826.600.51.1.1\)) Subject: Re: vlan(4) and bridge(4) on same interface From: "Vladimir B. Grebenschikov" In-Reply-To: Date: Wed, 30 Jul 2025 19:28:08 +0200 Cc: net@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <41044116-542D-447B-9831-B31F75688D56@fbsd.ru> References: To: Lexi Winter X-Mailer: Apple Mail (2.3826.600.51.1.1) X-Rspamd-Queue-Id: 4bsfM158f4z3t2d X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:51705, ipnet:178.213.227.0/24, country:RU] hi=20 > if the answer to both these questions is no, it would be helpful if = you > could explain why. I wouldn=E2=80=99t say it=E2=80=99s a definite no to both. But I can explain a scenario where such superposition makes sense (as I = am a user of such a setup): % ifconfig ix0 description "trunked uplink" % ifconfig ix1 description "another trunked link" % ifconfig bridge0 create addm ix0 ix1 % ifconfig bridge0.100 create description "Host interface here" so far everything fine - normal usage, bridge handels trunked traffic now I wish to have a number of jails attached to VLAN 101, so I will: % ifconfig bridge0.101 create up description "unwrap VLAN 101" % cbsd jcreate jname=3Dservice1 vnet=3D1 interface=3Dbridge0.101 ... % cbsd jcreate jname=3Dservice2 vnet=3D1 interface=3Dbridge0.101 ... % cbsd jcreate jname=3Dservice3 vnet=3D1 interface=3Dbridge0.101 ... ... sounds quite logical what cbsd (just another jail management software) will do underneath? something like: % ifconfig bridge1 addm bridge0.101 addm epair0a addm epair1a addm = epair2a others ends of the epairs will be landed in jails The jails should be able to talk to each other and should not be aware = (internally) of any VLANs. Yes, you can argue, that instead, we should evolve the cbsd tool to = acknoledge new functionality like=20 % cbsd jcreate jname=3Dservice1 vnet=3D1 interface=3Dbridge0 vlan=3D101 and then, plug all these jails into bridge0 with proper VLAN unwrapping = and filtering But on the other hand, having something that in the real world can be = represented as a dumb switch with no VLAN support (and no way to misconfigure it) to = connect a room of PCs, where all unwrapping and ACLs are configured once on the smart switch = port where the dumb switch is plugged in =E2=80=93 also makes sense. I wouldn=E2=80=99t argue about disabling this in 16.x, just wanted to highlight a scenario that does have merit. just my 5 cents, and thank you for your work > On Jul 30, 2025, at 17:04, Lexi Winter wrote: >=20 > hello, >=20 > currently we allow users to create a vlan and a bridge on the same > interface, like this: >=20 > % ifconfig ix0.100 create > % ifconfig bridge0 create addm ix0 >=20 > i am aware that some people are using this in production, but because = it > doesn't work properly[0], i would like to forbid this configuration in > 16.0, i.e. it would not be possible to add an interface to a bridge if > vlans are present on that interface, and vice versa. >=20 > i am looking for feedback from people who are currently using this: >=20 > - can you switch your untagged traffic to tagged instead and use a > vlan(4) in a bridge? e.g., >=20 > % ifconfig ix0.100 create > % ifconfig ix0.101 create > % ifconfig bridge0 create addm ix0.101 >=20 > - can you switch to a vlan filtering bridge instead? e.g., >=20 > % ifconfig bridge0 create addm ix0 vlanfilter tagged ix0 100,101 > % ifconfig bridge0.100 create > % ifconfig bridge0.101 create >=20 > if the answer to both these questions is no, it would be helpful if = you > could explain why. >=20 > [0] specifically, because both bridge(4) and vlan(4) expect to handle > tagged traffic, it is not clear how the tagged packets on the > interface should be handled. currently, they are processed by > bridge(4) unless they are destined for a local Ethernet address, > in which case they processed by vlan(4), but this behaviour is > somewhat non-obvious and breaks things that require promiscuous > mode on the vlan interface (e.g., tcpdump). -- Vladimir Grebenshchikov vova@fbsd.ru