From nobody Mon Jul 28 08:57:04 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 4brC5r5kGyz62pxD for ; Mon, 28 Jul 2025 08:57:04 +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 4brC5r53wtz3Mrv; Mon, 28 Jul 2025 08:57:04 +0000 (UTC) (envelope-from ivy@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1753693024; 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=kOUm+LAUIYWC4xQWAjMXL8QurgaGBtz0m3lMnf2RTas=; b=XAmRqGgkZ0JrNmpA/2qULauFRFjZP6Bez9cbcF35BwhcPMer4nIstKlH7CW5U8iutX1atv IWiadckKZg6eIwUuAb2ce2mdibBQcgglSzEOmVdGIVc2RKXi40bjBLOdReka+YbP5b0HjC UAnxrLaUuHDZzqOo6Ti2s3DgYfV5R+gbi6b958zvqd4aeMNJDAUzaZxVrHAHMDuUYbJuUV JIouyAJHJT8RymTFdgRB6P++vPBFVWTR3EYfFa8vGQEHJyNlSUWcNyRY6rBfzUtF/LpX27 tpqAj3cYpDH4fsR+zXl3WODz+oMkxTxai12cmEGURmwDISv/a8Jp07N4lGTEnA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1753693024; 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=kOUm+LAUIYWC4xQWAjMXL8QurgaGBtz0m3lMnf2RTas=; b=qRq3Sd6PCkDnjKY7bbkQwexXh2wNLHy3vWZAsiK0LbG2yTOmBGqTRcbzJ45nW+lW358MIB ruvt/fi6OUdVihbzYxGe90V8Q1qlB0/yP5u4vKaTGMvyWDS5JGTFQ2U7Qzqscpv/D1c3yT jUINPbria/mkuLpbLsRHXjFPNwDtU18CI82/zr2Xdf+TuePXrsboJKvL9L79cmaYfLkzj1 Moya+8Yx+vjaGtufRLmws+1IxD8PQoVuU34tSlTQvp2C21P/CabaGazTiMIiHzZQjsRZ/B z2zan2gXttmGkbxomTg4aFA4Tza7+bjhQMA+sS3J6VYxjbE8RlGVWWlNIQSn/g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1753693024; a=rsa-sha256; cv=none; b=BwYHG6g0jngMDkqAAoyt8YfQarMM9G4YkhicU1TyxxDk7hPijJ61/LPANZH1T+u4ZenGWq rAdDRW6PDr0A+XA2AT1AYAJEUR5N6d7SdIkmB3gTRTnJiQ+kALRC4oHDoXqcd4vwwtvn8N 2Gd/KMYVEc1cNjZ9ZfT9QJOj6RoiIN5ofO5HmKCgtaCPJMRZDGJ6YAi7LsHJGGZZAGz/cc 1OnYF7rfouhVo7Lihd7WoZ/EZ4HkW6YLJ+yo0hVreESM+yi/VoY/5mD6hTCIRENLLyu5Os ZrJYb4IUfbsBhLEJu1cia/8Bj8FctEFTJP7Zd0ROyq3ZxAHQgDOEgHKuoYFtDg== Received: by freefall.freebsd.org (Postfix, from userid 1532) id 97A4B16321; Mon, 28 Jul 2025 08:57:04 +0000 (UTC) Date: Mon, 28 Jul 2025 09:57:04 +0100 From: Lexi Winter To: "Bjoern A. Zeeb" Cc: net@freebsd.org Subject: Re: bridge gone wrong? Message-ID: Mail-Followup-To: "Bjoern A. Zeeb" , net@freebsd.org References: <88846585-6r86-p832-sro5-n4q14n170p06@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="3Y2SKBQwoRCiRrk+" Content-Disposition: inline In-Reply-To: <88846585-6r86-p832-sro5-n4q14n170p06@yvfgf.mnoonqbm.arg> --3Y2SKBQwoRCiRrk+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Bjoern A. Zeeb: > Now there are use cases that duing the liftime of a boot I need to add > a bridge interface to a vlanN + fanout: =20 > physical interface > +--- vlan1 --- bridge0 ---++++ other interface[s] > +--- vlan2 > +--- vlan3 --- bridge1 ---++++ other interface[s] >=20 > And that's where things obviously went south after the member_ifaddrs > sysctl changed (which I had missed). member_ifaddrs should have no impact on this configuration; nothing has changed about putting vlan(4) interfaces in a bridge. the only thing that was briefly broken was putting a vlan(4) in a bridge *and* putting the vlan's underlying network interface in another bridge. that has never worked properly, but was (accidentally) broken entirely by member_ifaddrs, but that was fixed ages ago. also, note that vlan filtering is orthogonal to member_ifaddrs. you can use both, or neither, or one without the other. > (d) bridge.4 "VLAN SUPPORT" says: > "" > Traffic sent to or from the host is not assigned to a VLAN by defaul= t. > To allow the host to communicate on a VLAN, configure a vlan(4) inte= rface > on the bridge and (if necessary) assign IP addresses there. > "" >=20 > Question: which VLAN do the addresses on the bridge interface belong > to now? =20 addresses assigned to the bridge itself have always been in "VLAN 0" and this hasn't changed with VLAN filtering. this is not very useful since "VLAN 0" doesn't really exist and this traffic can't be tagged on the wire, so in a VLAN filtering setup, you would want to avoid assigning addresses to the bridge itself. when VLAN filtering is disabled, this works because untagged traffic on member interfaces is also on VLAN 0 (so the bridge acts like a non-VLAN bridge, except that it still implements IVL), but with filtering enabled, there is never any traffic on VLAN 0. again, to be clear: nothing has changed here in the non-filtering case, this is how bridge always worked. > If I do (unrelated to my setup, just in general): > ifconfig bridge0 inet6 auto_linklocal -ifdisabled up > ping -n ff02::1%bridge0 > where do the packets go? =20 if you don't enable VLAN filtering, nothing has changed here. if you enable VLAN filtering, then filtering ports will drop this traffic: because it doesn't have a VLAN attached it is impossible to filter or forward in a useful way. note that i plan to remove the idea of 'filtering ports' and just make filtering a per-bridge flag (D51228) but this hasn't landed yet. in the mean time, if you have unfiltered ports on the bridge, the multicast traffic will continue to be forwarded via those ports as before. > Or in yet another way, how do you set the untagged vlan-id for the > bridge interface itself? you cannot do that, you should use the SVI interface instead (i.e., a vlan on top of a bridge). i won't add this feature because it's not necessary. in a VLAN filtering setup, it doesn't make sense to have traffic which isn't assigned to a VLAN. > (d.1) > Untagged on one member interface could now with filtering be vlan-id > 123 and on another member interface it could be vlan-id 666. > Is that handled correctly on igress->bridge-IPs->egress? consider the following setup: ifconfig bridge0 create vlanfilter \ addm ix0 untagged ix0 123 \ addm ix1 untagged ix1 666 in this case, all untagged traffic entering on ix0 is assigned to VLAN 123, and all untagged traffic entering on ix1 is assigned to VLAN 666. to communicate with hosts in those VLANs, you would create interfaces bridge0.123 or bridge0.666. there is no need to assign any IP addresses to the bridge itself since there is no untagged traffic. if you are asking about "tag mapping", i.e. you want traffic on ix0 on VLAN 123 to be mapped to VLAN 666 on ix1, this is not currently supported and you should continue to use vlan(4) in a bridge for this unusual configuration. i would like to add support for this, but it definitely won't be in 15.0. > (e) Something no one seems to have thought of was how this all aligns > with etherswitch? i would like bridge to be able to program etherswitch automatically so that it automatically offloads whatever functionality the hardware is capable of. but this is a "would be nice in the future maybe" thing, i haven't even started to think about how it would work. =20 that said, based on my understanding of how typical switch chips are programmed, the VLAN filtering bridge is conceptually closer to how the underlying hardware works than the vlan(4)-in-a-bridge style of bridge. (this is different to how most network cards are programmed, which is closer to the vlan-in-a-bridge setup.) > (f) bridge.4 says > "" > Attempting to assign an IP address to a bridge member > interface, or add a member interface with an assigned IP address to a > bridge, will return an EINVAL ("Invalid argument") error. > "" >=20 > Is this a distinct error for the addm case? yes. > If we can poinpoint it to that problem (along with the sysctl value), we > should really give the user a better error message. i have already exterrorized bridge (D51181) and it's ready to land, i just didn't get around to it yet - depending on how a couple of other things go i might do that today. --3Y2SKBQwoRCiRrk+ Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQSyjTg96lp3RifySyn1nT63mIK/YAUCaIc7XAAKCRD1nT63mIK/ YJ3mAP9nQLxAr1FCT8kNPgX8rHPnTWPml8wIs8IYB4iQWfuSdwEA6WK7blWEeAGc 0CLWxulh6fmXuqZhBVMal5lawozacQM= =QCL7 -----END PGP SIGNATURE----- --3Y2SKBQwoRCiRrk+--