FreeBSD 15 Bridges, VLANs and Jails - Nice!

With version 15's new VLAN aware bridges, we only need one bridge at the host level and one epair per jail to handle networking for every jail's needs.

Prior to version 15, when I was trying to build a vnet jailed gateway with a handful of VLANs I had to create an octopus of bridges (one per VLAN) and lots of dangling epairs. Version 15's new tech changed all that. Not only can all of the external VLANs collapse into one bridge, but now we can fold all private bridges into the one host bridge (add internal-only VLAN IDs to isolate communications).

With the VLAN aware bridges you only need one bridge on the host and one (possibly trunked) epair dropped into the jail. Make an epair VLAN aware epair and configure each epair/bridge connection to the subset of VLANs used by the jail. For any private jail-to-jail internal networks, use a new VLAN ID to connect a subgroup of jails via their epairs through the bridge.

The key is to get the ifconfig settings correct. Here's an example for the set up (without the jail configuration files) for a host, a physical interface (igb0 with VLANs 10,20) and two subjails with three VLANs (10, 20, 2001):

Code:
ifconfig epair0  create up
ifconfig epair0b up
ifconfig epair1  create up
ifconfig epair1b up
ifconfig bridge0 create up
ifconfig bridge0 vlanfilter addm igb0 tagged 10,20 up
ifconfig bridge0 addm epair0a tagged 10,2001
ifconfig bridge0 addm epair1a tagged 20,2001

# Pass epair0b into jail0 (vnet.interface = epair0b)
# Pass epair1b into jail1 (vnet.interface = epair1b)

With the above configuration, external packets arriving on VLAN 10 go to jail0 and those arriving on VLAN 20 go to jail1. Meanwhile, for jail0 and jail1 to communicate, they can use VLAN 2001.

Inside the jail, the epair VLANs can be splintered off:

Code:
ifconfig -j jail0 epair0b.10   create inet 192.168.10.55/24 up
ifconfig -j jail0 epair0b.2001 create inet 10.20.01.0/31 up
ifconfig -j jail1 epair1b.20   create inet 192.168.20.55/24 up
ifconfig -j jail0 epair1b.2001 create inet 10.20.01.1/31 up

jail0 communicates with the external network via epair0b.10.
jail1 communicates with the external network via epair1b.20.
Both jails communicate with each other using epair0b.2001 and epair1b.2001.

I built a complex test platform and watched ICMP packets zip around. I can share the code.
Hat tip to reddit user u/-iwantmy2dollars- for their post, which prompted my testing and this post.
 
Last edited:
I think this looks very nifty and and clean. I've looked at both the reddit thread and this one, but apparenty I fail to understand the concept?

If I want to set an IP on the host, in the best of my understanding it should not be on the vlan nor the bridge interface?
I try to set up a simpler case with a bridge containing tagged vlans, and the plan would be to create vnet epairs for jails and bhyve guests, but I do not grasp where the host IP could be set (epair also for the host?) for this setup to be functional.
 
Allright, my issue were twofold. At first I had an attempt with a lagg that I failed to setup, but (as I have this host running another system...) I switched to another port on the switch instead of reconfiguring the aggregation, but forgot to add the jail vlan to that port.
Then, the other failure I had was that when a jail started (during the creation of epair), the host lost its connectivity. At a glance, it looks like I've managed to solve that issue as well, with a vlan interface on the host.


Code:
cloned_interfaces="bridge0 vlan999"
ifconfig_ixl3="-vlanhwfilter up"
ifconfig_ixl3_description="Trunk"
ifconfig_bridge0="vlanfilter addm ixl3 tagged 24,442,900-999"
create_args_vlan999="vlan 999 vlandev bridge0"
ifconfig_vlan999="inet 172.28.12.4/28"
 
Last edited by a moderator:
It was a temporary success. During jail start up (creation) of epair, the host connectivity stops - about 30 packets lost during ping (tcpdump shows absence of icmp replies during 34 seconds). The same happens during destroy of the epair.
 
It's only the first (and/or only) epair that breaks the connection. Subsequent jails does not seem to affect the host connectivity. So a placeholder jail might be a workaround.
 
Okay, everything seem to work as expected.. The machine was previously setup with several virtual guests using dedicated interfaces (pass through devices), but I haven't gotten that far yet to exclude the interfaces from the host and it seem that those interfaces now caused a spanning tree loop (and the host got blocked from the switches while negotiating RTSP).
 
You have a complex network you're integrating into with quite a bit going on. I don't know if I have the chops to advise you. My recommendation would be to isolate these things, work on them separately and then recombine them once you're convinced they work as expected.

For your very first question if you haven't already solved it, in your case for adding host level IP addresses on the VLANs coming in from the NIC, they'd hang off of ixl3. They'd look like ixl3.24, ixl3.442, etc. For internal IP addresses, I haven't tested those in v15, yet. You used to be able to assign them to a bridge, but I believe that's no longer possible. My hack (until I think of something better) would be to create and attach an epair to the bridge and leave it in the host (say, epair0a gets attached to the bridge). Then, you can assign an IP address to the other end of the epair. If it's a trunked epair, then you'd splinter it off and assign the IP address to the splinter (epair0b.900 gets 10.90.0.1, epair0b,901 gets 10.90.1.1, etc).

Hope that helps.
 
You have a complex network you're integrating into with quite a bit going on. I don't know if I have the chops to advise you. My recommendation would be to isolate these things, work on them separately and then recombine them once you're convinced they work as expected.

For your very first question if you haven't already solved it, in your case for adding host level IP addresses on the VLANs coming in from the NIC, they'd hang off of ixl3. They'd look like ixl3.24, ixl3.442, etc. For internal IP addresses, I haven't tested those in v15, yet. You used to be able to assign them to a bridge, but I believe that's no longer possible. My hack (until I think of something better) would be to create and attach an epair to the bridge and leave it in the host (say, epair0a gets attached to the bridge). Then, you can assign an IP address to the other end of the epair. If it's a trunked epair, then you'd splinter it off and assign the IP address to the splinter (epair0b.900 gets 10.90.0.1, epair0b,901 gets 10.90.1.1, etc).

Hope that helps.
Thanks, I'm still a bit baffled on how I ended up in my situation, but when I first had issues setting up the lagg, I believe that the interfaces that I so far did not set up as pass through devides were causing me my first issues (which I then thought were due to the lagg)... and I thought about that epair and while it worked to set an IP to that, I still had the loops that were bugging me (I did not yet know about them at that time). I don't know what kind of device this "vlan" device is and if it has any performance penalties, but it seem to behave at least.

Adding the pass through devices in loader.conf solved my headache:
Code:
tail -2 /boot/loader.conf
vmm_load="YES"
pptdevs="102/0/0 102/0/1 102/0/2 102/0/3 183/0/0 183/0/1"

Then in the /etc/rc.conf (my ixl2 and ixl3 became ixl0 and ixl1 respectivelly, due to pptdevs):
Code:
cloned_interfaces="bridge0 lagg0 vlan999"
ifconfig_ixl0="-vlanhwfilter up"
ifconfig_ixl1="-vlanhwfilter up"
ifconfig_lagg0="laggproto lacp laggport ixl0 laggport ixl1 up"
ifconfig_lagg0_description="VM Trunk"
ifconfig_bridge0="vlanfilter addm lagg0 tagged 24,442,900-999"
create_args_vlan999="vlan 999 vlandev bridge0"
ifconfig_vlan999="inet 172.28.12.4/28"

then in my /etc/jails.conf.d/jail.conf I have this:
Code:
jail {
  # STARTUP/LOGGING
  exec.start = "/bin/sh /etc/rc";
  exec.stop  = "/bin/sh /etc/rc.shutdown";
  exec.consolelog = "/var/log/jail_console_${name}.log";

  # PERMISSIONS
  allow.raw_sockets;
  exec.clean;
  mount.devfs;
  devfs_ruleset = 5;

  # PATH/HOSTNAME
  path = "/jails/containers/${name}";
  host.hostname = "${name}";

  # VNET/VIMAGE
  vnet;
  vnet.interface = "${epair}b";

  # NETWORKS/INTERFACES
  $id = "32";
  $ip = "10.24.0.${id}/24";
  $gateway = "10.24.0.1";
  $bridge = "bridge0";
  $epair = "epair${id}";

  # ADD TO bridge INTERFACE
  exec.prestart += "ifconfig ${epair} create -vlanhwfilter up";
  exec.prestart += "ifconfig ${bridge} vlanfilter addm ${epair}a untagged 24 up";
  exec.start    += "ifconfig ${epair}b -vlanhwfilter ${ip} up";
  exec.poststop = "ifconfig bridge0 deletem ${epair}a";
  exec.poststop += "ifconfig ${epair}a destroy";
}

My next stop will be bhyve and jailed bhyve, but so far I like the new implementation of the bridge as it feels a lot cleaner. I have yet to figure out if there is some kind of spoof protection available to block a jail from setting up a not allowed IP, but this is my home network so it's not that critical (but could be a nice bonus).
 
I saw this on the r/freebsd. Nice write up!

BTW, I've recently found some trouble with epairs not applying checksums, but advertising they do so packets are dropped when they're received on the physical network by other machines and those packets are not NAT'd. That's a mouthful, so to be clear for packets originating from an epair:

Source
Route
Destination
Result
Notes
epair> bridge >host or another jailOKno checksum, all virtual
epair> bridge > host(NAT) > NIC >LAN deviceOKno checksum, host computes checksum at NAT
epair> bridge > NIC > edge router(NAT) >WAN deviceOKno checksum, edge router computes checksum at NAT
epair> bridge > NIC >LAN deviceDroppedno checksum, arrives empty, packet dropped

So, the problem is as far as I can tell epairs lie about their ability to checksum. To solve this, use ifconfig <if> -txcsum -rxcsum

This killed my network for 14 hours because DNS was broken. It's always DNS...
 
With version 15's new VLAN aware bridges, we only need one bridge at the host level and one epair per jail to handle networking for every jail's needs.

Prior to version 15, when I was trying to build a vnet jailed gateway with a handful of VLANs I had to create an octopus of bridges (one per VLAN) and lots of dangling epairs. Version 15's new tech changed all that. Not only can all of the external VLANs collapse into one bridge, but now we can fold all private bridges into the one host bridge (add internal-only VLAN IDs to isolate communications).

With the VLAN aware bridges you only need one bridge on the host and one (possibly trunked) epair dropped into the jail. Make an epair VLAN aware epair and configure each epair/bridge connection to the subset of VLANs used by the jail. For any private jail-to-jail internal networks, use a new VLAN ID to connect a subgroup of jails via their epairs through the bridge.

The key is to get the ifconfig settings correct. Here's an example for the set up (without the jail configuration files) for a host, a physical interface (igb0 with VLANs 10,20) and two subjails with three VLANs (10, 20, 2001):

Code:
ifconfig epair0  create up
ifconfig epair0b up
ifconfig epair1  create up
ifconfig epair1b up
ifconfig bridge0 create up
ifconfig bridge0 vlanfilter addm igb0 tagged 10,20 up
ifconfig bridge0 addm epair0a tagged 10,2001
ifconfig bridge0 addm epair1a tagged 20,2001

# Pass epair0b into jail0 (vnet.interface = epair0b)
# Pass epair1b into jail1 (vnet.interface = epair1b)

With the above configuration, external packets arriving on VLAN 10 go to jail0 and those arriving on VLAN 20 go to jail1. Meanwhile, for jail0 and jail1 to communicate, they can use VLAN 2001.

Inside the jail, the epair VLANs can be splintered off:

Code:
ifconfig -j jail0 epair0b.10   create inet 192.168.10.55/24 up
ifconfig -j jail0 epair0b.2001 create inet 10.20.01.0/31 up
ifconfig -j jail1 epair1b.20   create inet 192.168.20.55/24 up
ifconfig -j jail0 epair1b.2001 create inet 10.20.01.1/31 up

jail0 communicates with the external network via epair0b.10.
jail1 communicates with the external network via epair1b.20.
Both jails communicate with each other using epair0b.2001 and epair1b.2001.

I built a complex test platform and watched ICMP packets zip around. I can share the code.
Hat tip to reddit user u/-iwantmy2dollars- for their post, which prompted my testing and this post.
I wish I understood a word of all that!

Maybe I need a whole load more brain cells....
 
IIRC, -vlanhwfilter is only needed if the physical interface offers tag processing in hw etc. This is separate from hw checksum offloading. May be your h/w doesn't deal with checksum in vlan tagged frames properly?
 
BiG problem. anyone can help me ?
now my bridge was working . but new problem coming .... when i start vm or stop vm . the bridge will lost default router about 4 seconds...then autocome back....jesus.....
16 bytes from 2620:1ec:33:1::10, icmp_seq=31 hlim=48 time=91.120 ms
16 bytes from 2620:1ec:33:1::10, icmp_seq=32 hlim=48 time=92.485 ms
ping: sendmsg: Network is down
ping: wrote bing.com 16 chars, ret=-1
ping: sendmsg: Network is down
ping: wrote bing.com 16 chars, ret=-1
ping: sendmsg: Network is down
ping: wrote bing.com 16 chars, ret=-1
ping: sendmsg: Network is down
ping: wrote bing.com 16 chars, ret=-1
16 bytes from 2620:1ec:33:1::10, icmp_seq=37 hlim=48 time=92.775 ms
16 bytes from 2620:1ec:33:1::10, icmp_seq=38 hlim=48 time=92.720 ms
16 bytes from 2620:1ec:33:1::10, icmp_seq=39 hlim=48 time=92.859 ms

do you know what happened to me ?

{only one physical network card} em0 ----as member----->bridge5<--------all vms and jails

em0 no IP configured ....
bridge5 have daul-stack (ipv4 static and ipv6 SLAAC) . thanks.
 
codeedog : please take look my post about bridge . do really use freebsd15 bridge ? please test my problem. thanks.
thanks...
 
codeedog : please take look my post about bridge . do really use freebsd15 bridge ? please test my problem. thanks.
thanks...

This happens when the capabilities don't match across the bridge members.
The easiest way to solve this is to disable options on the physical card so that when members are added there's no hardware reset that needs to occur.

If you provide ifconfig output (options in particular) for each of the physical interface and interface that would be added to the bridge then someone would be able to give you very very specific instructions on which options you need to disable.
 
This happens when the capabilities don't match across the bridge members.
The easiest way to solve this is to disable options on the physical card so that when members are added there's no hardware reset that needs to occur.

If you provide ifconfig output (options in particular) for each of the physical interface and interface that would be added to the bridge then someone would be able to give you very very specific instructions on which options you need to disable.
Dear pprocacci :
thanks for your help . i post a attachment about ifconfig ...thanks.
 

Attachments

So you're using `re' ... ugh. These are super low budget cards.

You need to get re0 in a state where it's options are that of the `lowest common denominator' for all members of the bridge.

So baby steps, try this first:

# ifconfig re0 -rxcsum -txcsum

Then add additional members. See what happens.
If that doesn't solve it's most certainly going to be related to linkstate.

You can then try:
# ifconfig re0 -rxcsum -txcsum -linkstate

Finally, if you aren't using RSTP, just disable it entirely.

I have a feeling this is going to be linkstate related but without some testing, it's really hard to diagnose these re cards.
 
try this 2weeks ago , not work . and that was not rexxx problem.. all network card just like this.
So you're using `re' ... ugh. These are super low budget cards.

You need to get re0 in a state where it's options are that of the `lowest common denominator' for all members of the bridge.

So baby steps, try this first:

# ifconfig re0 -rxcsum -txcsum

Then add additional members. See what happens.
If that doesn't solve it's most certainly going to be related to linkstate.

You can then try:
# ifconfig re0 -rxcsum -txcsum -linkstate

Finally, if you aren't using RSTP, just disable it entirely.

I have a feeling this is going to be linkstate related but without some testing, it's really hard to diagnose these re cards.
 
codeedog

I'm trying this in a VirtualBox VM, using this script (modified from your example to fit my network of where my host net interface is em0 at 192.168.0.2):

Bash:
#!/bin/sh
ifconfig

sudo ifconfig epair0  create up
sudo ifconfig epair0b up
sudo ifconfig epair1  create up
sudo ifconfig epair1b up
sudo ifconfig bridge0 create up
sudo ifconfig bridge0 vlanfilter addm em0 tagged 10,20 up
sudo ifconfig bridge0 addm epair0a tagged 10,2001
sudo ifconfig bridge0 addm epair1a tagged 20,2001
sudo ifconfig epair0b.10   create inet 192.168.0.100/24 up
sudo ifconfig epair0b.2001 create inet 10.20.01.0/31 up
sudo ifconfig epair1b.20   create inet 192.168.0.200/24 up
sudo ifconfig epair1b.2001 create inet 10.20.01.1/31 up

ifconfig

This gives me the following output:

Initial state...

Bash:
em0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
    options=48505bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,LRO,VLAN_HWFILTER,VLAN_HWTSO,HWSTATS,MEXTPG>
    ether 08:00:27:7f:a5:81
    inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255
    media: Ethernet autoselect (1000baseT <full-duplex>)
    status: active
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
lo0: flags=1008049<UP,LOOPBACK,RUNNING,MULTICAST,LOWER_UP> metric 0 mtu 16384
    options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
    inet 127.0.0.1 netmask 0xff000000
    inet6 ::1 prefixlen 128
    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
    groups: lo
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
pflog0: flags=100<PROMISC> metric 0 mtu 33152
    options=0
    groups: pflog

Followed by the output from adding the epairs...
Bash:
epair0a
epair1a

Followed by the final state
Bash:
em0: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
    options=8500bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWFILTER,VLAN_HWTSO,HWSTATS>
    ether 08:00:27:7f:a5:81
    media: Ethernet autoselect (1000baseT <full-duplex>)
    status: active
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
lo0: flags=1008049<UP,LOOPBACK,RUNNING,MULTICAST,LOWER_UP> metric 0 mtu 16384
    options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
    inet 127.0.0.1 netmask 0xff000000
    inet6 ::1 prefixlen 128
    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
    groups: lo
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
pflog0: flags=100<PROMISC> metric 0 mtu 33152
    options=0
    groups: pflog
epair0a: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
    options=20001b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,RXCSUM_IPV6>
    ether 58:9c:fc:10:78:27
    groups: epair
    media: Ethernet 10Gbase-T (10Gbase-T <full-duplex>)
    status: active
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
epair0b: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
    options=20001b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,RXCSUM_IPV6>
    ether 58:9c:fc:10:78:1c
    groups: epair
    media: Ethernet 10Gbase-T (10Gbase-T <full-duplex>)
    status: active
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
epair1a: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
    options=20001b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,RXCSUM_IPV6>
    ether 58:9c:fc:10:a9:c6
    groups: epair
    media: Ethernet 10Gbase-T (10Gbase-T <full-duplex>)
    status: active
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
epair1b: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
    options=20001b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,RXCSUM_IPV6>
    ether 58:9c:fc:10:37:76
    groups: epair
    media: Ethernet 10Gbase-T (10Gbase-T <full-duplex>)
    status: active
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
bridge0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
    options=10<VLAN_HWTAGGING>
    ether 58:9c:fc:10:7e:44
    id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
    maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
    root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
    bridge flags=1<VLANFILTER>
    member: epair1a flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
            port 6 priority 128 path cost 2000 vlan protocol 802.1q tagged 20,2001
    member: epair0a flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
            port 3 priority 128 path cost 2000 vlan protocol 802.1q tagged 10,2001
    member: em0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
            port 1 priority 128 path cost 20000 vlan protocol 802.1q tagged 10,20
    groups: bridge
    nd6 options=9<PERFORMNUD,IFDISABLED>
epair0b.10: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
    options=0
    ether 58:9c:fc:10:78:1c
    inet 192.168.0.100 netmask 0xffffff00 broadcast 192.168.0.255
    groups: vlan
    vlan: 10 vlanproto: 802.1q vlanpcp: 0 parent interface: epair0b
    media: Ethernet 10Gbase-T (10Gbase-T <full-duplex>)
    status: active
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
epair0b.2001: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
    options=0
    ether 58:9c:fc:10:78:1c
    inet 10.20.1.0 netmask 0xfffffffe broadcast 255.255.255.255
    groups: vlan
    vlan: 2001 vlanproto: 802.1q vlanpcp: 0 parent interface: epair0b
    media: Ethernet 10Gbase-T (10Gbase-T <full-duplex>)
    status: active
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
epair1b.20: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
    options=0
    ether 58:9c:fc:10:37:76
    inet 192.168.0.200 netmask 0xffffff00 broadcast 192.168.0.255
    groups: vlan
    vlan: 20 vlanproto: 802.1q vlanpcp: 0 parent interface: epair1b
    media: Ethernet 10Gbase-T (10Gbase-T <full-duplex>)
    status: active
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
epair1b.2001: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
    options=0
    ether 58:9c:fc:10:37:76
    inet 10.20.1.1 netmask 0xfffffffe broadcast 255.255.255.255
    groups: vlan
    vlan: 2001 vlanproto: 802.1q vlanpcp: 0 parent interface: epair1b
    media: Ethernet 10Gbase-T (10Gbase-T <full-duplex>)
    status: active
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

This is basic networking question.

When I run this, my host's net interface, em0, is moved into the bridge. This is expected. But I lose connectivity (ssh) to that host.

So my question is:

Q: How do I move em0 into the bridge, but also not lose connectivity to the host? Note em0 address is DHCP'd.


Note: I have tried replacing the line above that creates the bridge with:

Bash:
sudo ifconfig bridge0 vlanfilter addm em0 DHCP tagged 10,20 up

But that didn't help. Per the docs here, "To allow the host to communicate with bridge members, IP addresses should
be assigned to the if_bridge interface itself, not to the bridge's member interfaces."

But how?
 
From what I gather from the information you provided em0 is a trunk.... so

1) Add em0 to bridge0 (w/out it having an address)
2) Create a vlan interface off of bridge0 (bridge0.10 for example)
3) DHCP on bridge0.10 (or whatever)

When you are done, it should look something like this (except I'm using ixl0 here):
ixl0: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
options=a500b9<RXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,HWSTATS>
ether 3c:fd:fe:aa:df:a8
media: Ethernet autoselect (10Gbase-SR <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

bridge0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
options=10<VLAN_HWTAGGING>
member: ixl0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
port 1 priority 128 path cost 55 vlan protocol 802.1q untagged 1 tagged 10,20,30,40,50,60,70
groups: bridge
nd6 options=9<PERFORMNUD,IFDISABLED>

bridge0.10: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1496
options=0
ether 58:9c:fc:10:6f:fa
inet 192.168.10.2 netmask 0xffffff00 broadcast 192.168.10.255
groups: vlan
vlan: 10 vlanproto: 802.1q vlanpcp: 0 parent interface: bridge0
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>


If you want an rc.conf configuration here's mine. Substitute ixl0 and vlans as necessary:
ifconfig_ixl0="-txcsum -txcsum6 up"
ifconfig_bridge0="vlanfilter addm ixl0 tagged 10,20,30,40,50,60,70 untagged 1 up"
vlans_bridge0="10"
ifconfig_bridge0_10="SYNCDHCP up"

The above will send traffic on vlan 10 as you desire.
 
Back
Top