On Tue, Nov 12, 2013 at 3:18 PM, Andreas Pflug <pgad...@pse-consulting.de> wrote: > Am 12.11.13 01:54, schrieb Jesse Gross: >> On Mon, Nov 11, 2013 at 5:39 PM, Andreas Pflug >> <pgad...@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. _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
