Hi,
On 3/19/24 5:23 PM, Hans van Kranenburg wrote:
I wasn't sure if this script comes from Debian or Xen or somewhere else,
so I thought it safest to report it here.
These scripts/vif-* files are located in tools/hotplug/Linux in the Xen
source tree, we ship them as such in the Debian package. So, yes,
changes to them should first go upstream. However, it's perfectly fine
to have a discussion here, so we can figure out what the right changes
should be.
Fair.
+ set_mtu "$bridge" "$dev" "$type_if"
Ah, interesting. I had some difficulties getting it to work back then.
But, when putting the set_mtu line back like this, it also gives me the
desired outcome now!
I think the scripts were different back then. I wrote my own vif scripts
as well, to get the MTU thing and a couple of other things right,
because I couldn't figure out how to get the built in scripts to do it.
I was building a couple of new Xen hosts this winter, and noticed that
the scripts looked much better now, and gave them a go, and only found
the MTU issue and the IPv6 link locals that were bugging me.
When I grepped the script dir for mtu, I noticed the shared function in
network tools that only vif-bridge was using, and tried that. I suspect
it could be added into a lot of the other vif scripts as well...
My use case is about setting up a PPPoE connection from a Xen domU over
vlan 6. I want an mtu of 1500 for the traffic inside the PPPoE
connection, so I need mtu 1508 for the connection between the PPPoE
client in the domU -> openvswitch in the dom0 -> physical interface ->
switchports -> ISP NTU device.
For some reason I had troubles to get the vifX.Y interface, as seen
inside dom0 set to mtu 1508. It seemed not to have any effect (using ip
link set mtu <M> dev <D>), or, openvswitch kept resetting it back to
1500 all the time. When I would use ovs-vsctl set interface <D>
mtu_request=<M> instead, it actually sticked. That's what I remember.
I just did some more testing, and I cannot really reproduce that
situation... :| I can also just use ip link in the dom0 now.
Interesting, but good, since it would mean that we can indeed just
(re)use that set_mtu function! :) I'm still curious what the problem was
when I tried earlier... Maybe anyone else reading this knows more?
I wonder if some other component in ovs had the wrong MTU and that kept
overriding the others... There's the uplink port, the virtual switch and
the vif port. I think the virtual switch is picky that all the ports
should be the same MTU.
Another issue I remember having like a decade ago was that some IXGBE
card seemed to refuse to take new MTU settings after it was already in
production.
Are you familiar with the process of sending patches upstream? Otherwise
we (Debian Xen team) can assist with that.
Ah, no. Any help is much appreciated.
Best Regards,
--
Aleksi Suhonen
() ascii ribbon campaign
/\ support plain text e-mail
