From nobody Wed Jul 30 23:28:05 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 4bspKx4X0zz6399Z for ; Wed, 30 Jul 2025 23:28:05 +0000 (UTC) (envelope-from ivy@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4bspKx3vb6z3pLg; Wed, 30 Jul 2025 23:28:05 +0000 (UTC) (envelope-from ivy@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1753918085; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=31lPPgFM9bbFPWjNsTrWbcHtJhs3CfeHN3KRvBSx4M0=; b=ukZXwGoZwVyh3iXp6LrkP10nBRLZdk2KKtjNRd4Jd4hT0kzSczJFdFkwvT9Op+zyokqWft oxQlk+hzR6IaxJXST31i/Pp06S5/CT+CyDXPxw0MpHlsNv3Va0CEAD6IvPvKOa7EUTaXv5 RW2mux3uE3lULLu+eVC2S0Az/FuYjx0NQbLaR+2O6NRQpGz/sOf0MOpG4A0nqpdB2p+SKZ gfaXzCaw3mjx/VLqQNCynwqWwSlcRDEvJgt9dzoxy4cwKo88C7enOBAwNGctVAc5sJEAjE q12vym62uHdAON8ZnZbTF+v/dJ4I5BhQxGi/c+BtSZLeQGH+jr4cWPyQETeLMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1753918085; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=31lPPgFM9bbFPWjNsTrWbcHtJhs3CfeHN3KRvBSx4M0=; b=JoBhamfriHeQj9JOB3P3VQhy3EV5Ou9if6gg2nRTarccKG8HyfHVTCSM0cGA53C3MwVRPr kwFK72LcA0WSQI7992ZzegUKDyykOUHU8ZRESuJvrANNkD0Q18cbw/LQlLcBDcqdr8ggjq NNmFZI27xLFJ1hmeNfN028evwOOnpMrrsRRFERJ25jG/y/CKqPn3iPKbNWlXM46k17baqd qJIYonNNcdC4qzi0Z4ZnovPuzZzdZp43wJ0Srj9/2nz3l5aIpdjT2/dcDsMt99CSIoY4vJ hTTIJi7ML0ZEP+IwOJWJcfD4JlNNXO3VXSimCgetCQlzfBee+jHy+LWe/tjEhQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1753918085; a=rsa-sha256; cv=none; b=JzWBiFVeM4CLqvniHwd+NZ98oMyA6/Cu+MPy41iahVM0ZtMV2GUQ8so7b5tPVmIIOnznVb Moclmp/NiHNY7r7BquILE8icY7+P4p1/1KYVjKM5n1u3v3fHMlUlRcK4ltNSJ+a1rvKBMl wZnZCUo8dOc4DIr5ds+DhUqNlFWPCR7CxKXqWRF69nXOUnjKf8xH8ErKIiJmihKhlk4T16 LGWsAa3vmK6V8qvnIJJOQPAvB2TjLuZ19UvQ/mZleCCXHWCKgFnmYFWetzxKPxVxRH3I6r s4RpkM3rrRO1QPkmftY1xkjd2WsSAyFz0HF9H1+1Fc0/CDv32EvxYRC5boBF+w== Received: by freefall.freebsd.org (Postfix, from userid 1532) id 6FB07241DE; Wed, 30 Jul 2025 23:28:05 +0000 (UTC) Date: Thu, 31 Jul 2025 00:28:05 +0100 From: Lexi Winter To: "Bjoern A. Zeeb" Cc: net@freebsd.org Subject: Re: vlan(4) and bridge(4) on same interface Message-ID: Mail-Followup-To: "Bjoern A. Zeeb" , net@freebsd.org References: <187902p9-2p89-2684-2639-85prs4o57n42@yvfgf.mnoonqbm.arg> 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 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="DJPfQnIvMxk9upKg" Content-Disposition: inline In-Reply-To: <187902p9-2p89-2684-2639-85prs4o57n42@yvfgf.mnoonqbm.arg> --DJPfQnIvMxk9upKg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Bjoern A. Zeeb: > Am I correct that if I do want to leave the untagged packets of a trunk > connected to the bridge "untagged" I would still be able to configure > the host IP on bridge0 without any need for "untagged" if no vlanfilter > is in place? if you aren't using 'vlanfilter', then you can't use 'untagged' at all and all packets retain the vlan they entered the system with (which is 0 for untagged packets). in that case you would need to assign IP addresses to the bridge itself to access "vlan 0". if you do that, you can still create vlan interfaces on the bridge -- this isn't really how i intended that to be used but there seemed to be no reason to prohibit it. this might be useful in some existing setups where the only way to access the non-zero VLAN is to put an epair in the bridge then create a vlan on that. however be aware that in this configuration any port can send traffic on any vlan, so this isn't very secure. > But the moment vlanfilter is in place these untagged packets would be > dropped and I will always need a spare VLAN ID to sacrifice (even though > only internally to that bridge and not visible outside -- unless that > pvid matches the vlan ID on a differnt trunk connected to the bridge) > and need to use the 'untagged' keyword? Or is it still possible to > directly configure the Host IP on bridge0 and leave untagged packets > as such? with vlanfilter, *all* packets have a (non-zero) VLAN; if you don't configure 'untagged' on an interface, that means this interface should not be permitted to send/receive untagged frames, so all untagged incoming traffic will be dropped. so yes, to receive untagged frames in that case, you must use 'untagged' to assign them to a VLAN. i'm not i would describe that as "sacrificing" a vlan id though, it's more that you're simply creating N different VLANs to segment your traffic into, and assigning VLAN IDs 1..N (or whatever) to those VLANs. =20 the fact that one of those VLANs is untagged on some (or all) ports is just incidental. it's true that with the old bridge you get VLAN 0 "for free", but with 4094 [0] VLAN IDs you're not likely to run out [1]. incidentally, if the device on the other side of your trunk port (dwc0) is 802.1Q-aware, i would always suggest tagging all traffic and never mixing tagged and untagged traffic on the same port. however i appreciate this isn't possible in some situations, like network boot. [0] or 4093 if you avoid vlan 1, which is often a good idea because some network gear treats vlan 1 as special. in that case you might also avoid vlan 2 since that's slightly special in 802.1Q. i usually start at 100 to avoid all that. [1] if you do run out, you need vxlan instead, which isn't directly supported by bridge yet... something that may or may not change in the future. --DJPfQnIvMxk9upKg Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQSyjTg96lp3RifySyn1nT63mIK/YAUCaIqqgQAKCRD1nT63mIK/ YE20AQDm2UT44tsMHtaF0f88BRX17tQdlTP0tFXPcr8zK0maMQEAxoAz/Nx0KD1S 08xPTUGdqTyjxlxAjmju6HGgwzS8BwE= =1771 -----END PGP SIGNATURE----- --DJPfQnIvMxk9upKg--