Re: FBSD 15 :: if_bridge help needed
- Reply: Paul Procacci : "Re: FBSD 15 :: if_bridge help needed"
- In reply to: Paul Procacci : "Re: FBSD 15 :: if_bridge help needed"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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.