11.1 xen bridging breaks jumbo frames

[normmackey]

The new Xen network bridging in OpenSuse 11.1 is crippling my ability to relay jumbo frames to my Xen virtual machines, preventing me from migrating them to hosts running 11.1 as I had planned.

Although the host bridges (br1 device in my case) accept an MTU value of 8500 in yast, they limit the value to 1500 bytes in actual application.

This was not a problem in 11.0. Is there any way I can adjust this, and continue using DRBD replication and iSCSI at decent speeds?

[normmackey]

Apologies, this is an update rather than a reply, with more information.

To reproduce the problem: On a system with two NICs, install a default Opensuse 64-bit, Xfce desktop, adding Xen server to the software selection. Choose the recommended Xen bridging network configuration during the installation (or unconfigure the NICs and configure the bridges br0->eth0 and br1->eth1 manually afterwards).

Using YAST Network Devices during or after the install, under the general tab for br1, enter an MTU value of 8500.

There will be no error message shown exiting YAST. There will be no sign of problems in /var/log/messages:

Mar 5 13:37:29 crowley SuSEfirewall2: /var/lock/SuSEfirewall2.booting exists which means system boot in progress, exit.
Mar 5 13:37:30 crowley ifup: br1
Mar 5 13:37:30 crowley kernel: igb 0000:04:00.1: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Mar 5 13:37:30 crowley kernel: ADDRCONF(NETDEV_UP): eth1: link is not ready
Mar 5 13:37:30 crowley kernel: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
Mar 5 13:37:30 crowley kernel: device eth1 entered promiscuous mode
Mar 5 13:37:30 crowley kernel: br1: topology change detected, propagating
Mar 5 13:37:30 crowley kernel: br1: port 1(eth1) entering forwarding state
Mar 5 13:37:30 crowley ifup-bridge: br1 forwarddelay (see man ifcfg-bridge)
Mar 5 13:37:30 crowley ifup-bridge: ... ready
Mar 5 13:37:30 crowley ifup: br1
Mar 5 13:37:30 crowley ifup: IP address: 192.168.177.1/24
Mar 5 13:37:30 crowley ifup:
Mar 5 13:37:30 crowley avahi-daemon[4413]: Joining mDNS multicast group on interface br1.IPv4 with address 192.168.177.1.

However, ifconfig shows an MTU of 1500 for br1 and the bridged eth1 device, and when booting on the console, or during an rcnetwork restart, you can see:

br1
br1 Ports: [eth1]
br1 forwarddelay (see man ifcfg-bridge) ... ready
RTNETLINK answers: Invalid argument
RTNETLINK answers: Invalid argument
Cannot set mtu of 8500 to interface br1.
br1 IP address: 192.168.177.1/24

/etc/sysconfig/network/ifcfg-br1 contains:

BOOTPROTO='static'
BRIDGE='yes'
BRIDGE_FORWARDDELAY='0'
BRIDGE_PORTS='eth1'
BRIDGE_STP='off'
BROADCAST=''
ETHTOOL_OPTIONS=''
IPADDR='192.168.177.1/24'
MTU='8500'
NAME=''
NETWORK=''
REMOTE_IPADDR=''
STARTMODE='auto'
USERCONTROL='no'

The problem also does not occur when the mtu value is set to less than 1500, in which case the reduced mtu is applied, again according to ifconfig.

[udosoft]

I have the same problem.
What I have till now:

the bridge automatically use the rule: mtu = min(mnt of all member inferfaces), so setting MTU in the config file does nothing...
I think that was the easiest way to implement the bridge and give good performance. It would be better if the bridge would set the interface (tries to the given mtu, than go down till the interface accepts and than set all other to the same mtu.. not the best, but would be a better solution)...

So the main problem is:
I modified the xm command files to enable mtu= setting in the vm file...
Now it can be used in the configfile and in the /etc/xen/scripts

But!
I do not why, the virtual interface in that state only accept maximal mtu 1500!!!!

But if the domain has started... I can set it to 9000 in my case...

so I have used vifname in the configfile to easily change settings by the a script afterwards.

The problem is the time between the xm create command and the ipconfig command, it will be go down to MTU 1500 for some seconds. If I have other domains running, this will be a affect to them.

So anybody does know why I am not able to set the MTU higher than 1500 in the vif-common or the vif-bridge and why can I set it afterwards?

Ok now I can try to make another unused bridge, set it in the config file, set the vif mtu, remove it from the vridge, add it to the right bridge... But it is not the best way I think.. Or I hack the script, and if no bridge is set in the config file, than it does not add it to any bridge.. But this is all about dirty workarounds...

************************************************** *
So the main question is :

Why does not the virtual interface allow higher MTU setting in the initial phase aka in the vif-common or the vif-bridge scripts?

[udosoft]

Additonal info I have to wait for 2 seconds after the domU has started and only than can I set the MTU higher...
So maybe the DomU have to communicate with the xen hypervisior or something like that?