Re: Xen, Bridge, VLANs

[christos%astron.com@localhost (Christos Zoulas)]

In article <20151119105018.GQ23745%caravaggio.net.espci.fr@localhost>,
 <Jean-Jacques.Puig%espci.fr@localhost> wrote:
>-=-=-=-=-=-
>
>Hi,
>
>I submit the attached patch to your consideration for inclusion
>(possibly with amendments) to the kernel source.
>
>It deals with an old issue raised on the port-xen ML on the 2008/06/21
>(http://mail-index.netbsd.org/port-xen/2008/06/21/msg003915.html).
>
>* Summary:
>Where VLAN interfaces are required in a domU, Ethernet frames (sent and
>received) on these interfaces are limited to a 1496 bytes MTU, because
>xennet interface does not currently support the VLAN_MTU capability.
>
>Furthermore, the frame size check on dom0's xen interface does not
>account for the possibility of an extended MTU for VLAN traffic and does
>not support the capability either.
>
>This patch adds the VLAN_MTU capability to these interfaces. In
>particular, the frame size check takes ETHER_VLAN_ENCAP_LEN into
>consideration *if the capability is enabled*.
>
>Where a VLAN interface is attached to such interfaces, the VLAN_MTU
>capability will be enabled. Most probable use for this configuration is
>on the domU side. On the dom0 side, however, xen interfaces are usually
>members of a bridge interface.
>
>This patch also modifies the bridge interface in order to enable the
>VLAN_MTU capability on interfaces added to the bridge and to disable
>this capability on interfaces removed from the bridge, only if they do
>not already deal with VLAN traffic as the result of another
>configuration.
>
>This does not actually change the traffic processing operations on the
>bridge side (but may on the member interface side as a result of the
>capability being enabled), because a bridge interface sets promiscuous
>mode on member interfaces. In this mode, received frames bigger than
>member interface's configured MTU actually get through; this is why
>tcpdump can show frames that are actually dropped by normal
>(non-promiscuous) receiving routines on the interface.
>
>* Background:
>This patch was developped to address MTU issues on a wireless LAN
>infrastructure, where multiple SSIDs (currently eduroam and eduspot) and
>management traffic are each mapped on a different VLAN, as is often
>mandatory while dealing with enterprise class access-points. Tagged VLAN
>traffic is then bridged to a domU which acts as the wireless LAN
>gateway. Alternatives involved a mix of DHCP interface-mtu option
>(ignored by many clients), MSS clamping, RADIUS framed-mtu property and
>kernel tcp.mss_ifmtu state and still could not resolve issues with some
>traffics.
>
>We've been using a first version of this patch since Oct 29, and current
>version since Nov. 16.

Thanks, I applied your changes to -current. Can you please test?

Best,

christos