Solved Bhyve and Automatically Setting Tap MTU?

Hey folks -

Is there any way to automatically set the MTU of the tap interfaces that are created for bhyve VMs? I tried:

Code:
network0_mtu="9216"

in the VM's .conf file, but that didn't do anything. It didn't throw an error, either, for what it's worth.

Is there a trick to it that I just don't know about yet? I can do it all manually by pulling the taps from the bridge, setting their MTUs, and putting them back in. But that's a sub-optimal way to handle it.

Thanks!
 
The MTU is dictated by the bridge(4) it's connected to. And the MTU of the bridge is dictated by the MTU of the uplink (physical) interface.

Code:
cloned_interfaces="lagg0 bridge10"
ifconfig_igb0="up mtu 9014"
ifconfig_igb1="up mtu 9014"
ifconfig_lagg0="laggproto lacp laggport igb0 laggport igb1"
vlans_lagg0="10"
ifconfig_lagg0_10="inet 192.168.10.180 netmask 255.255.255.0"
ifconfig_bridge10="addm lagg0.10"
My VMs are all tied to bridge10:
Code:
dice@hosaka:~ % ifconfig bridge10
bridge10: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 9014
        description: vm-public
        ether 02:68:5a:63:7b:0a
        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
        member: tap7 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 18 priority 128 path cost 2000000
        member: tap6 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 17 priority 128 path cost 2000000
        member: tap5 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 16 priority 128 path cost 2000000
        member: tap4 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 15 priority 128 path cost 2000000
        member: tap3 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 14 priority 128 path cost 2000000
        member: tap2 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 13 priority 128 path cost 2000000
        member: tap1 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 12 priority 128 path cost 2000000
        member: tap0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 11 priority 128 path cost 2000000
        member: lagg0.10 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 8 priority 128 path cost 2000000
        groups: bridge vm-switch viid-4c918@
        nd6 options=9<PERFORMNUD,IFDISABLED>
Everything has the same MTU, tap1 for example:
Code:
dice@hosaka:~ % ifconfig tap1
tap1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 9014
        description: vmnet-kdc-0-public
        options=80000<LINKSTATE>
        ether 00:bd:bf:36:f7:01
        inet6 fe80::2bd:bfff:fe36:f701%tap1 prefixlen 64 tentative scopeid 0xc
        groups: tap vm-port
        media: Ethernet autoselect
        status: active
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        Opened by PID 2217
 
The MTU is dictated by the bridge(4) it's connected to. And the MTU of the bridge is dictated by the MTU of the uplink (physical) interface.

Yes, I'm aware that's how it works with an uplink-style bridge. But that's not what I'm doing here. I have a series of bridges created to mimic point-to-point direct connections between VMs and I need those to support jumbos. Each bridge only has 2 taps in it.
 
Have you tried setting the MTU on the bridge, then adding the tap(4) interfaces? Adding them should simply use the MTU of the bridge without having to specify it.
 
Have you tried setting the MTU on the bridge, then adding the tap(4) interfaces? Adding them should simply use the MTU of the bridge without having to specify it.

You can't manually set the MTU on a bridge interface. I've already tried that. Ifconfig errors out.
 
Yes, you can, but not if it already contains members:
Code:
root@hosaka:~ # ifconfig bridge100 create
root@hosaka:~ # ifconfig bridge100 mtu 9000
root@hosaka:~ # ifconfig bridge100
bridge100: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 9000
        ether 02:68:5a:63:7b:64
        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 0 ifcost 0 port 0
        groups: bridge
        nd6 options=9<PERFORMNUD,IFDISABLED>
Code:
root@hosaka:~ # ifconfig bridge100 destroy
root@hosaka:~ # ifconfig bridge100
ifconfig: interface bridge100 does not exist
root@hosaka:~ # ifconfig bridge100 create
root@hosaka:~ # ifconfig tap99 create
root@hosaka:~ # ifconfig bridge100 addm tap99
root@hosaka:~ # ifconfig bridge100 mtu 9000
ifconfig: ioctl SIOCSIFMTU (set mtu): Invalid argument
root@hosaka:~ #
 
Yes, you can, but not if it already contains members:

Thanks. That must have been what I'd tried a number of times. Also, it's somewhat annoying that the -m flag for vm doesn't appear to support anything higher than 9000 apparently?.

From vm():

Code:
     vm switch create [-t type] [-i interface] [-n vlan-id] [-b bridge]
        [-m mtu] [-a address] [-p] name

Code:
joker# vm switch destroy spn01-lf01
joker# vm switch create -m 9216 spn01-lf01
/usr/local/sbin/vm: ERROR: invalid mtu
joker# vm switch create -m 1500 spn01-lf01
joker# vm switch destroy spn01-lf01
joker# vm switch create -m 9200 spn01-lf01
/usr/local/sbin/vm: ERROR: invalid mtu
joker# vm switch create -m 9000 spn01-lf01
joker# ifconfig vm-spn01-lf01
vm-spn01-lf01: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 9000
    ether d6:f7:29:34:37:5c
    nd6 options=1<PERFORMNUD>
    groups: bridge vm-switch viid-1c2d6@ 
    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
joker# ifconfig vm-spn01-lf01 mtu 9216
joker# ifconfig vm-spn01-lf01
vm-spn01-lf01: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 9216
    ether d6:f7:29:34:37:5c
    nd6 options=1<PERFORMNUD>
    groups: bridge vm-switch viid-1c2d6@ 
    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

Thanks for the help. Looks like I'll lower the VMs' interfaces to 9000 and go from there. Shouldn't make enough of a difference to matter.
 
Back
Top