From nobody Wed Jul 30 20:42:11 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 4bskfX0Xphz631TQ for ; Wed, 30 Jul 2025 20:42:12 +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 4bskfX01Jpz3Thd; Wed, 30 Jul 2025 20:42:12 +0000 (UTC) (envelope-from ivy@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1753908132; 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=ssWy1oOJdESeq6PrJd56EFu/3kvD4XR/kATZzVOZgKk=; b=qWf+wDQWLvcjGS56mZ4t7jpwqja/UtuTi6mi/u4ee2fxZUUmDZPAvqCwkqeDLjS393n5fC egVlxWFW8UomKaPOST/5h++wX7jLa6fm7iXg+ty7gDxpvCBEQhHruAoVAWWh/e8H2e87U5 kjjhcVLrqBBKRZRtd3h9qV1xAENGNgYsuc2tZ6c2alaTnOaOgG3RO5pPZxSeroekToNeRK wAlFLc4Yz20D/LhIxq6eBUw9ftbgfrgrRKb1wMnupfGi1xMJMhqfYUe16MGYLru2B7EzYB HXkcRBUaa0qj8TXy3qqiQWRteTxBi0OFQlLI1Cbi3Ik1D6rsSJ/c73CKRm8k5w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1753908132; 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=ssWy1oOJdESeq6PrJd56EFu/3kvD4XR/kATZzVOZgKk=; b=w1i694wD3nouZ9RTKI7GQXVUC0fNV9GYk3EGFEWT/CWUc+EMx1iYXqqIDRJA7l9/Ro5P2C cDiE9KfXL/6IdaC5SfWZ1dabHOagUtrFI5+N69bWmFDOPxhDv70XwYD5ZFhgn4tJwS3EKc Txhk6Un8jE1ZhCAAy7l/cSBME6o0syQqXbihPvMElLiE5ztjwqiIDMR6jqUHhfjU8uMB7G liIU4e2hnb2qu+CE2Zhwafo7dXgql+x8SMJTfKIVThjVL7i7DcI/yqziM93HnXPawMwxTL SxkYUvVLaNsQtenlM9DATGcNbLu3EQFF+lLV1l3CWvBNsARXnFOy5pYT8V5xwQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1753908132; a=rsa-sha256; cv=none; b=nuQHvnSj1OwGNPImPw6PwlaGOFpcq/ZenM4ug2mpNiO7iIJ/UYmVaVBjWtzdhEOZeZyd1K hKbID/feeS8cKoVRrk2KpH7UEH658Ec8eH+C8qQ3hhSf6jps4/CGPJO+6wFHCOce3gFo7e 8S9tlmQjJYyV3f2ChM8yk9OGOMgxcveqbml5o01FBYI1EtYpbr0nEJpG5NZKL3XaVsscXG RFtoLhvSe48sVbCE2iRI+OrPMpE0+yjFroAiLGZztQuAWShwMgR/AgjSS07vg1lMn+0tfQ srmt9ET90j9DbYxXeyMJzuAQEnwnhHZ5GwHeF7RrB+aAINqbbF6bw4ZzkjHpsA== Received: by freefall.freebsd.org (Postfix, from userid 1532) id DA8CE23B6D; Wed, 30 Jul 2025 20:42:11 +0000 (UTC) Date: Wed, 30 Jul 2025 21:42:11 +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: 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="vRn6FFb7P4EhXPXo" Content-Disposition: inline In-Reply-To: --vRn6FFb7P4EhXPXo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Bjoern A. Zeeb: > On Wed, 30 Jul 2025, Lexi Winter wrote: > > 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. > Do you intend to make it a sysctl in 15 already so people can forbid it > upfront before migrating to 16, and in 16 before stable/16 just remove > it all together? >=20 > Or if it is not too late for 15, simply have the sysctl disabled by > default in 15 and people can rescue themselves flipping it for the > lifetime of 15? > Given the other changes, I wonder if it would just make sense to get > all the cases/possible breakage sorted in one go that way? =20 considering how close stable/15 is i wasn't planning to make any change here for 15.0, but if there's consensus this is the right way to go,=20 we could add a WARNING printf for 15.0 indicating this might be removed in the future, then add a sysctl which is disabled by default in 16.0 and remove it in 17.0. since many instances of this type of configuration can be replaced by vlan filtering, this gives users one release to convert their network setup without having to enable non-default sysctls. i have a related change (currently part of D51260, but that probably won't be landed as-is) which changes the behaviour here so if that any vlan(4) is configured on the interface, *all* tagged packets go to vlan and are ignored by bridge. this makes the code cleaner and i think is also more understandable to users, but it does somewhat change the behaviour. > dwc0 inet6 > bridge0 addm dwc0 addm epair0a ; epair0b in another vnet with another 3 v= lans on top > vlan100 inet6 on dwc0 > vlan200 inet6 on dwc0 >=20 > Normally I would have put the vlan interfaces into the vnet without > bridge but you cannot have the same vlan N twice on the same parent > interface. Hence the bridge in the middle. Should really be three > bridges and 3 epairs on 3 vlan interfaces in the base for the vnet > but .. =20 i think bridge is the right solution here, but with vlan filtering, you could do it this way instead: ifconfig bridge0 create vlanfilter addm dwc0 tagged dwc0 100-399 ifconfig bridge0 addm epair0a untagged epair0a 100 # epair0b in a jail ifconfig bridge0 addm epair1a untagged epair1a 200 # epair1b in a jail ifconfig bridge0 addm epair2a untagged epair2a 300 # epair2b in a jail ifconfig bridge0.100 create # in the host ifconfig bridge0.200 create # in the host essentially, i would like to be in a situation where if you're doing switching you use bridge, and if you're doing routing you use vlan(4), and there's never a need for both on the same interface. (if you're doing both switching and routing, you use vlan on top of the bridge, as in this example.) > > - can you switch your untagged traffic to tagged instead and use a > > vlan(4) in a bridge? e.g., > > % ifconfig ix0.100 create > > % ifconfig ix0.101 create > > % ifconfig bridge0 create addm ix0.101 > Is this the same setup as above as we are no longer bridging the trunk > in addition to having a local access VLAN or do I have a different use > case in mind? this was supposed to be the same as the "bad" example, except that instead of creating the vlan(4) on the external interface, you create it on the bridge instead. so this would be the simplest migration path for users, but i don't think you can set the vlan(4) vlan id to 0, so this requires changing your upstream device to tag all traffic. (if it is possible to set vlan id to 0 - which thinking about it, should be allowed - then this might be the easiest migration path for everyone, but i haven't tested this with bridge before.) > If I were to take my above setup, would the following do the job? > (syntax may be wrong) >=20 > ifconfig bridge0 addm dwc0 [vlanfilter] untagged dwc0 4000 tagged dwc0 10= 0,200,300,400 > ifconfig bridge0.4000 inet6 ... # that's the base address formerly on d= wc0 for untagged on the wire > ifconfig bridge0.100 inet6 .. > ifconfig bridge0.200 inet6 .. > ifconfig bridge0 addm epair0a [vlanfilter] tagged epair0a 100,300,400 =20 i wrote my example above before i read this part of your mail, but yes, this looks reasonable. for now you need 'ifconfig bridge0 addm X vlanfilter X tagged X...', but once D51600 lands (hopefully very soon) you will only need to set vlanfilter once on the bridge itself. > The only problem I need to figure out is how to transition from a > netboot setup (address is on the physical interface) to something where > the address migrates to the bridge without losing the NFS root mount... > Has anyone found a solution for that already? there was a discussion about this on the list a couple of weeks back, but for now i think the answer is no (as in, it should be possible, just no one has written the code yet). --vRn6FFb7P4EhXPXo Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQSyjTg96lp3RifySyn1nT63mIK/YAUCaIqDnwAKCRD1nT63mIK/ YK5CAP9LmWhL1aJtA5hB5Y8n6QVLDZt1YItpMg7L7kZi8rDhxgEAgIJPR2+fFibW XITW1kApbiK2luGHWTRdk941NrD18wI= =o1Sg -----END PGP SIGNATURE----- --vRn6FFb7P4EhXPXo--