[ovs-discuss] mtu setting lost

[Andreas Pflug]

Am 13.11.13 07:20, schrieb Jesse Gross:
> On Tue, Nov 12, 2013 at 3:18 PM, Andreas Pflug
> <pgadmin at pse-consulting.de> wrote:
>> Am 12.11.13 01:54, schrieb Jesse Gross:
>>> On Mon, Nov 11, 2013 at 5:39 PM, Andreas Pflug
>>> <pgadmin at pse-consulting.de> wrote:
>>>> I'm running ovs (1.4.2) for xen bridging from debian 7.1.
>>>>
>>>> The physical interface is configured to the max possible MTU of 9216,
>>>> because there's one ovs port configured for san access with a VLAN tag
>>>> and MTU of 9190 that's used by open-iscsi initiator exclusively. The
>>>> machine's main/management interface is configured to default MTU 1500.
>>>>
>>>> If I start a VM, its VIFs will be created with MTU=1500. When they are
>>>> added to the ovs bridge, subsequently all non-physical interfaces will
>>>> be reset to MTU=1500, including the (for common network traffic unused)
>>>> san port. The same will happen if I further reduce one interface MTU
>>>> manually; its setting will propagate to all ports. This appears
>>>> unexpected to me and is undesirable.
>>> The Ethernet bridging spec requires all interfaces on a single L2
>>> domain to have the same MTU, which is why OVS is automatically
>>> adjusting the MTU of the interfaces that it has control over. If there
>>> truly is no overlap between domains then you could use separate OVS
>>> bridges.
>> Hm so OVS is the first switch I've seen that enforces this. I'd expect a
>> packet incoming with a larger MTU than configured outbound being
>> truncated/dropped, not my switch reconfigured unexpectedly.
>> The SAN port and the Xen bridging just happen to share the same physical
>> interface, but no traffic, so they definitely belong to different L2
>> domains. OVS can't really know upfront about L2 domains, so IMHO this
>> automatism is over-designed. Apparently, I'll have to bypass OVS for SAN
>> traffic using a standard linux VLAN interface, I intended to avoid that.
> The Linux bridge also does this, since that's where the behavior was
> inherited from. I actually agree that it's a little too prescriptive
> in the context of OVS but you are the first to complain about it. If
> you have a clean way to fix it, I would be fine with that.

Linux bridging acts just as interface multiplier, so I understand that
behaviour, but not on ovs.
I fixed it by removing the san port from ovs bridge, and create a vlan
interface on the physical nic (more specific: on a linux bond; I had
unresolved trouble with ovs lacp). This is too business critical to
tamper on the sources for me, and 1.4.2 isn't too recent anyway...
Wondering why debian is so outdated btw.
SAN VLAN packets are now double-filtered, once in the linux stack and
then dropped in ovs, instead only once in ovs, but it works.

Regards,
Andreas