Pkg xen devel - Mar 2024 - Bug#1067151: xen-utils-common: vif-openvswitch ignores MTU

Package: src:xen
Version: 4.17.3+10-g091466ba55-1~deb12u1
Severity: wishlist

I wasn't sure if this script comes from Debian or Xen or somewhere else, 
so I thought it safest to report it here.

/etc/xen/scripts/vif-bridge handles MTU settings in the vif, but the 
otherwise similar /etc/xen/scripts/vif-openvswitch does not. I added it 
in, here's the diff-c and the full fixed file is also attached.

*** vif-openvswitch.orig        2024-03-19 11:53:13.000000000 +0200
--- vif-openvswitch     2024-03-19 11:56:17.000000000 +0200
***************
*** 89,94 ****
--- 89,95 ----
       add|online)
           check_tools
           setup_virtual_bridge_port $dev
+         set_mtu "$bridge" "$dev" "$type_if"
           add_to_openvswitch $dev
           ;;



-- 
	Aleksi Suhonen

	() ascii ribbon campaign
	/\ support plain text e-mail
-------------- next part --------------
#!/bin/bash
#===========================================================================#
${XEN_SCRIPT_DIR}/vif-openvswitch
#
# Script for configuring a vif in openvswitch mode.
#
# Usage:
# vif-openvswitch (add|remove|online|offline)
#
# Environment vars:
# vif         vif interface name (required).
# XENBUS_PATH path to this device's details in the XenStore (required).
#
# Read from the store:
# bridge  openvswitch to add the vif to (required).
# ip      list of IP networks for the vif, space-separated (optional).
#
# up:
# Enslaves the vif interface to the bridge and adds iptables rules
# for its ip addresses (if any).
#
# down:
# Removes the vif interface from the bridge and removes the iptables
# rules for its ip addresses (if any).
#===========================================================================
dir=$(dirname "$0")
. "$dir/vif-common.sh"

check_tools()
{
    if ! command -v ovs-vsctl > /dev/null 2>&1; then
        fatal "Unable to find ovs-vsctl tool"
    fi
    if ! command -v ip > /dev/null 2>&1; then
        fatal "Unable to find ip tool"
    fi
}
openvswitch_external_id() {
    local dev=$1
    local key=$2
    local value=$3

    echo "-- set interface $dev
external-ids:\"$key\"=\"$value\""
}

openvswitch_external_id_all() {
    local dev=$1
    local frontend_id=$(xenstore_read "$XENBUS_PATH/frontend-id")
    local vm_path=$(xenstore_read "/local/domain/${frontend_id}/vm")
    local name=$(xenstore_read "${vm_path}/name")
    openvswitch_external_id $dev "xen-vm-name" "$name"
    local uuid=$(xenstore_read "${vm_path}/uuid")
    openvswitch_external_id $dev "xen-vm-uuid" "$uuid"
    local mac=$(xenstore_read "$XENBUS_PATH/mac")
    openvswitch_external_id $dev "attached-mac" "$mac"
}

add_to_openvswitch () {
    local dev=$1
    local bridge="$(xenstore_read_default "$XENBUS_PATH/bridge"
"$bridge")"
    local tag trunk

    if [[ $bridge =~
^([^.:]+)(\.([[:digit:]]+))?(:([[:digit:]]+(:[[:digit:]]+)*))?$ ]]; then
        bridge="${BASH_REMATCH[1]}"
        tag="${BASH_REMATCH[3]}"
        trunk="${BASH_REMATCH[5]//:/,}"
    else
        fatal "No valid bridge was specified"
    fi

    if [ $trunk ]; then
        local trunk_arg="trunk=$trunk"
    fi

    if [ $tag ]; then
        local tag_arg="tag=$tag"
    fi

    local vif_details="$(openvswitch_external_id_all $dev)"

    do_or_die ovs-vsctl --timeout=30 \
        -- --if-exists del-port $dev \
        -- add-port "$bridge" $dev $tag_arg $trunk_arg $vif_details
    do_or_die ip link set $dev up
}

case "$command" in
    add|online)
        check_tools
        setup_virtual_bridge_port $dev
        set_mtu "$bridge" "$dev" "$type_if"
        add_to_openvswitch $dev
        ;;

    remove|offline)
        do_without_error ovs-vsctl --timeout=30 \
            -- --if-exists del-port $dev
        do_without_error ip link set $dev down
        ;;
esac

if [ "$type_if" = vif ]; then
    handle_iptable
fi

log debug "Successful vif-openvswitch $command for $dev."
if [ "$type_if" = vif -a "$command" = "online" ];
then
    success
fi

Hi Aleksi,

Thanks for the report. I actually ran into the same situation recently,
wanting to set up a PPPoE connection from within a Xen domU, also using
openvswitch as bridge.

On 19/03/2024 12:21, Aleksi Suhonen wrote:
> Package: src:xen
> Version: 4.17.3+10-g091466ba55-1~deb12u1
> Severity: wishlist
> 
> 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.
> /etc/xen/scripts/vif-bridge handles MTU settings in the vif, but the 
> otherwise similar /etc/xen/scripts/vif-openvswitch does not. I added it 
> in, here's the diff-c and the full fixed file is also attached.
> 
> *** vif-openvswitch.orig        2024-03-19 11:53:13.000000000 +0200
> --- vif-openvswitch     2024-03-19 11:56:17.000000000 +0200
> ***************
> *** 89,94 ****
> --- 89,95 ----
>        add|online)
>            check_tools
>            setup_virtual_bridge_port $dev
> +         set_mtu "$bridge" "$dev" "$type_if"
>            add_to_openvswitch $dev
>            ;;
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!

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?

Are you familiar with the process of sending patches upstream? Otherwise
we (Debian Xen team) can assist with that.

Regards,
Hans

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