From nobody Mon Jul 28 04:12:54 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 4br4p91PpQz63VSL for ; Mon, 28 Jul 2025 04:13:05 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx-01.divo.sbone.de (mx-01.divo.sbone.de [IPv6:2003:a:140a:2200:6:594:fffe:19]) (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 ECDSA (prime256v1) client-digest SHA256) (Client CN "mx-01.divo.sbone.de", Issuer "E5" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4br4p76qMkz3ymm; Mon, 28 Jul 2025 04:13:03 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zabbadoz.net header.s=20240622 header.b=Y8jL3eLv; spf=pass (mx1.freebsd.org: domain of bzeeb-lists@lists.zabbadoz.net designates 2003:a:140a:2200:6:594:fffe:19 as permitted sender) smtp.mailfrom=bzeeb-lists@lists.zabbadoz.net; dmarc=pass (policy=none) header.from=zabbadoz.net Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by mx-01.divo.sbone.de (Postfix) with ESMTPS id 90CF5A64805; Mon, 28 Jul 2025 04:12:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=zabbadoz.net; s=20240622; t=1753675971; bh=xMAv2deeIGyl1T+n0w5D2Q0LPlbznhhYWiop/X10w3Y=; h=Date:From:To:cc:Subject; b=Y8jL3eLvZHVyqY6vbOTIQ/ei5H/HwsKF0COz7pANQ9NV1oMNlMIKpygPCT13i/mbH 46XGGmw/f7i9gRSaOTq5w2MAcqNxrwB52Icjz0M1+CvKaT6eD1FLC17oNXttuVp/9M GLVs/VbuEPMjtSoNXh5grD86iuqIMLd95bQqzoMXq8H2vWMcfiyC9Il8B8m648GrrW CPr4QUNUt3ELQMXord4HSLdY4r+KFESR8PG0R1eMmiBAb/DnxB9asuug2V2C2ZAGdR VhF3CeKhr/f+9L0+5nrCEINVog/UHSfZGw9lGYg+MxYteTdpGjBHWTWcbGfChqmsDa sX1zPBqnkspskeY6UkCAc2qX5pt8Bhh8OP5aRjpinlQfinY8NOJegIua0d8UvQy0ha 9KO/snknOAvhfNlthD5UrOmPA92fbhTL9pPN66oJm86OyJ8+UEtCccpyubl8S8PCHJ W9p8eiRxtKC4Mcxu6pz8UInmX+JVCTVDBdK+Fzri3a2o1g0BJMlird6+1c8gFUqyyn 7ZsffvyGqKP57Q6lXMTgaKTWniMijg0hbYQaVZo8Eac3gDbOenUOuxRyqIU/w8jNs9 BpECWkBZv0TXDxgZN3HsTy1fyRx5AXZYJkRJAOARiKYUTq9vh5qCcuLQf14scsBW4y pmnaP9MI3lG1qa6Z5yXjSDio= Received: from content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (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) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 4963A2D029E1; Mon, 28 Jul 2025 04:12:56 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) by content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (amavisd-new, port 10024) with ESMTP id iLAqx6buaiv1; Mon, 28 Jul 2025 04:12:55 +0000 (UTC) Received: from strong-iwl0.sbone.de (strong-iwl0.sbone.de [IPv6:fde9:577b:c1a9:4902:a66b:b6ff:fe40:39a9]) (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) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 1999D2D029D8; Mon, 28 Jul 2025 04:12:55 +0000 (UTC) Date: Mon, 28 Jul 2025 04:12:54 +0000 (UTC) From: "Bjoern A. Zeeb" To: Lexi Winter cc: net@freebsd.org Subject: bridge gone wrong? Message-ID: <88846585-6r86-p832-sro5-n4q14n170p06@yvfgf.mnoonqbm.arg> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 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: text/plain; format=flowed; charset=US-ASCII X-Spamd-Result: default: False [-2.98 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-0.99)[-0.994]; NEURAL_HAM_SHORT(-0.99)[-0.990]; DMARC_POLICY_ALLOW(-0.50)[zabbadoz.net,none]; R_DKIM_ALLOW(-0.20)[zabbadoz.net:s=20240622]; R_SPF_ALLOW(-0.20)[+ip6:2003:a:140a:2200:6:594:fffe:19:c]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:3320, ipnet:2003::/19, country:DE]; MISSING_XM_UA(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; MLMMJ_DEST(0.00)[net@freebsd.org]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[zabbadoz.net:+] X-Rspamd-Queue-Id: 4br4p76qMkz3ymm X-Spamd-Bar: -- Hi, I wish I would not have had to look into this but I got bitten over the weekend. My topology on boot looks simplified for the example) like: physical interface +--- vlan1 +--- vlan2 +--- vlan3 I need addresses on the VLAN interfaces to be able to reach the machine in the default setup. Now there are use cases that duing the liftime of a boot I need to add a bridge interface to a vlanN + fanout: physical interface +--- vlan1 --- bridge0 ---++++ other interface[s] +--- vlan2 +--- vlan3 --- bridge1 ---++++ other interface[s] And that's where things obviously went south after the member_ifaddrs sysctl changed (which I had missed). Sitting on a 14.3-STABLE machine didn't help the confusion until I pulled the git tree and checked the log and UPDATING. So my setup seems to be reverse to what most poeple think they should do -- broadcast all packets including vlans over the bridge and deal with it behind. So for that case vlan filtering tries to solve this makes half-way sense. I wished we would have added vlan filtering/handling generically to interfaces as a "sub-layer" stacking things properly but that's a discussion for another decade I fear; but that's where I tink "bridge went wrong" now. I feels like we tried to make the bridge a switch just not quite right (yet). I have a few suggestions at least to improve a few things given you are active there, and some question. I think at least ifconfig(8) needs a few changes (some old problems): (a) "Bridge VLAN Filtering Parameters" belongs under "Bridge Interface Parameters" and is not another equal .Ss subsection. (new) (b) "Bridge Interface Parameters" really also should have a reference to bridge.4 and mention that the bridge.4 man page documents more specific bits and the sysctls to change other behaviour in addition to the ifocnfig options. This is good for the vlan filtering part already. (c) both ifocnfig "Bridge VLAN Filtering Parameters" and the bridge(4) "VLAN SUPPORT" parts are talking about "interfaces". I think using "bridge members" or "member interafce(s)" here for clarity would help a lot to have a distinction from (bridge) interface to (bridge) member (interface). This is not a new problem as other older options have that ambiguity as well and should probably be improved along. (d) bridge.4 "VLAN SUPPORT" says: "" Traffic sent to or from the host is not assigned to a VLAN by default. To allow the host to communicate on a VLAN, configure a vlan(4) interface on the bridge and (if necessary) assign IP addresses there. "" Question: which VLAN do the addresses on the bridge interface belong to now? 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? Or in yet another way, how do you set the untagged vlan-id for the bridge interface itself? You can do so for all possible VLANs which are tagged by adding the vlan(4) interface on top but that does not help the untagged case. (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? (e) Something no one seems to have thought of was how this all aligns with etherswitch? Different program different arguments and names for some things which do this "in hw" rather than using the software implementation. Did we loose a chance to fix this and harmonize it? (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. "" Is this a distinct error for the addm case? If we can poinpoint it to that problem (along with the sysctl value), we should really give the user a better error message. That might help all the surprised users now. If we return EINVAL for other addm errors as well we probably lost on this too. My .05cts /bz -- Bjoern A. Zeeb r15:7