Re: FBSD 15 :: if_bridge help needed

On Fri, Oct 10, 2025 at 2:51 AM Lexi Winter <[email protected]> wrote:
>
> 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.

Everything is ok.  I swear it is.
It was a setting on a switch forcing the id to 1.

This is another 3:00am special from me trying to get this thing setup.
This machine was serving a different purpose until 2 nights ago so
there were some old configs still being applied.
Ugh!

Well on the bright side, through all my testing I can tell ya'll
everything appears to working except for one thing:  me

Jesus H.  You guys are awesome.  2 Beers now.

Oh and Mark (I know you're watching) ... stop laughing.  This is
embarrassing.  ;)

Thanks again ..
~Paul

-- 
__________________

:(){ :|:& };: