Re: FBSD 15 :: if_bridge help needed

From: Lexi Winter <ivy_at_freebsd.org>
Date: Fri, 10 Oct 2025 06:50:58 UTC
Paul Procacci wrote in <CAFbbPui_Row=voSgcnGzmFOx=Pg6Vn7kVTjvyriTg6nNU3DCKQ@mail.gmail.com>:
> Alright, so what's the correct method here for getting the host
> assigned an ip within that 1843 vlan.
> Is it:
>   a) create a lagg0.1843 interface and assign an ip
>   b) create a bridge0.1843 interface and assign an ip

option b) is correct.  VLAN subinterfaces on bridge(4) is a new feature
in 15.0 and this is now the correct way to connect the host to a VLAN
in a bridge, especially when using VLAN filtering.

creating a VLAN subinterface on a bridge member was supported, sort of,
but the behaviour was confusing: whether the frame is handled by vlan or
bridge depends on its destination Ethernet address.  in 15.0, i changed
this so that if you create a vlan(4) interface on an interface which is
also a member of a bridge, all tagged packets will go the vlan, not the
bridge.  this preserves the ability to put the interface in a bridge for
untagged packets and also handle tagged packets via a vlan(4) interface
(which may also be in a bridge, although i don't recommend that).

> From remote host: tcpdump -n -e -ttt -i igc1 host 192.168.35.154
> 00:00:01.063499 58:9c:fc:10:6f:fa > 60:be:b4:01:bf:0d, ethertype IPv4
> (0x0800), length 98: 192.168.35.154 > 192.168.35.1: ICMP echo request,
> id 5948, seq 8, length 64
> So I'm seeing untagged packets arriving when they should be tagged.

hm, your configuration looks correct, so i'm not sure what is causing
this.  could you please show the tcpdump -ev output for the packet on
bridge0.1843, lagg0, and whichever external interface(s) in the lagg
are handling the packet?  i'd like to see whether the tag is being
removed somewhere, or if it's not being added at all.

could you also include the output of "ifconfig -a" on the system with
the bridge?

note, there is an outstanding issue where if you create bridge0.N, then
destroy the bridge, then recreate the bridge, the bridge0.N interface
will still exist but it won't be associated with the correct device.
this doesn't seem to be the case in your situation, but it can come up
when you're deleting/recreating bridges for testing, so i thought it was
worth mentioning.