From nobody Tue Jul 29 01:26:23 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 4brd3h25zgz63gXm for ; Tue, 29 Jul 2025 01:26:40 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (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 (2048 bits) client-digest SHA256) (Client CN "vps1.elischer.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4brd3g6fyfz3C5k; Tue, 29 Jul 2025 01:26:39 +0000 (UTC) (envelope-from julian@freebsd.org) Authentication-Results: mx1.freebsd.org; none Received: from [192.168.20.14] (180-150-86-67.b49656.per.static.aussiebb.net [180.150.86.67]) (authenticated bits=0) by vps1.elischer.org (8.17.2/8.16.1) with ESMTPSA id 56T1QTbm088530 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT); Mon, 28 Jul 2025 18:26:32 -0700 (PDT) (envelope-from julian@freebsd.org) X-Authentication-Warning: vps1.elischer.org: Host 180-150-86-67.b49656.per.static.aussiebb.net [180.150.86.67] claimed to be [192.168.20.14] Message-ID: Date: Tue, 29 Jul 2025 09:26:23 +0800 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 User-Agent: Mozilla Thunderbird Subject: Re: bridge gone wrong? To: "Bjoern A. Zeeb" , Lexi Winter Cc: net@freebsd.org References: <88846585-6r86-p832-sro5-n4q14n170p06@yvfgf.mnoonqbm.arg> Content-Language: en-US From: Julian Elischer In-Reply-To: <88846585-6r86-p832-sro5-n4q14n170p06@yvfgf.mnoonqbm.arg> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4brd3g6fyfz3C5k 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:36236, ipnet:204.109.60.0/22, country:US] considered if using the netgraph bridging and vlan support might be a cleaner solution? On 7/28/25 12:12 PM, Bjoern A. Zeeb wrote: > 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 >