[ovs-dev] [PATCH v4 1/4] Add support for 802.1ad (QinQ tunneling)

Xiao Liang shaw.leon at gmail.com
Fri Sep 9 15:06:01 UTC 2016


On Fri, Sep 9, 2016 at 6:18 PM, Mooney, Sean K <sean.k.mooney at intel.com> wrote:
>
>
>> -----Original Message-----
>> From: Xiao Liang [mailto:shaw.leon at gmail.com]
>> Sent: Friday, September 9, 2016 5:27 AM
>> To: Mooney, Sean K <sean.k.mooney at intel.com>
>> Cc: Ben Pfaff <blp at ovn.org>; dev at openvswitch.org
>> Subject: Re: [ovs-dev] [PATCH v4 1/4] Add support for 802.1ad (QinQ
>> tunneling)
>>
>> On Sat, Aug 20, 2016 at 9:41 AM, Mooney, Sean K
>> <sean.k.mooney at intel.com> wrote:
>> >
>> >
>> >> -----Original Message-----
>> >> From: dev [mailto:dev-bounces at openvswitch.org] On Behalf Of Ben
>> Pfaff
>> >> Sent: Friday, August 19, 2016 9:57 PM
>> >> To: Xiao Liang <shaw.leon at gmail.com>; dev at openvswitch.org
>> >> Subject: Re: [ovs-dev] [PATCH v4 1/4] Add support for 802.1ad (QinQ
>> >> tunneling)
>> >>
>> >> On Fri, Aug 19, 2016 at 04:42:18PM -0400, Eric Garver wrote:
>> >> > On Fri, Aug 19, 2016 at 01:24:10PM -0700, Ben Pfaff wrote:
>> >> > > On Fri, Aug 19, 2016 at 04:19:31PM -0400, Eric Garver wrote:
>> >> > > > On Sat, Aug 06, 2016 at 08:04:44PM -0700, Ben Pfaff wrote:
>> >> > > > > On Sun, Aug 07, 2016 at 10:54:00AM +0800, Xiao Liang wrote:
>> >> > > > > > On Thu, Aug 4, 2016 at 6:07 AM, Ben Pfaff <blp at ovn.org>
>> wrote:
>> >> > > > > > > Thanks for the replies, I have some further responses
>> below.
>> >> > > > > > >
>> >> > > > > > > On Sun, Jul 31, 2016 at 08:22:47AM +0800, Xiao Liang
>> wrote:
>> >> > > > > > >> On Thu, Jul 28, 2016 at 2:40 AM, Ben Pfaff
>> <blp at ovn.org> wrote:
>> >> > > > > > >> > I'm concerned about backward compatibility.  Consider
>> >> > > > > > >> > some application built on Open vSwitch using
>> OpenFlow.
>> >> > > > > > >> > Today, it can distinguish single-tagged and
>> >> > > > > > >> > double-tagged packets (that use outer Ethertype
>> 0x8100), as follows:
>> >> > > > > > >> >
>> >> > > > > > >> >     - A single-tagged packet has vlan_tci != 0 and
>> some non-VLAN
>> >> > > > > > >> >       dl_type.
>> >> > > > > > >> >
>> >> > > > > > >> >     - A double-tagged packet has vlan_tci != 0 and a
>> VLAN dl_type.
>> >> > > > > > >> >
>> >> > > > > > >> > With this patch, this won't work, because neither
>> kind
>> >> > > > > > >> > of packet has a VLAN dl_type.  Instead, applications
>> >> > > > > > >> > need to first match on the outer VLAN, then pop it
>> >> > > > > > >> > off, then match on the inner VLAN.  This difference
>> >> > > > > > >> > could lead to security problems in applications.  An
>> >> > > > > > >> > application might, for example, want to pop an outer
>> >> > > > > > >> > VLAN and forward the packet, but only if there is no
>> >> > > > > > >> > inner VLAN.  If it is implemented
>> >> according to the previous rules, then it will not notice the inner
>> VLAN.
>> >> > > > > > >>
>> >> > > > > > >> Maybe some applications are implemented this way, but
>> >> > > > > > >> they are probably wrong. OpenFlow says eth_type is
>> >> > > > > > >> "ethernet type of the OpenFlow packet payload, after
>> >> > > > > > >> VLAN tags", so it is the payload ethtype for a
>> >> > > > > > >> double-tagged packet. It's the same for single-tagged
>> >> > > > > > >> packet: application must explicitly match vlan_tci to
>> >> > > > > > >> decide whether it has VLAN tag.
>> >> > > > > > >
>> >> > > > > > > OpenFlow does say that, but it's inconsistent with
>> >> > > > > > > long-standing Open vSwitch practice and will cause
>> >> > > > > > > backward incompatibility and, worse, security problems.
>> >> > > > > > > If we need the official OpenFlow behavior then I think
>> >> > > > > > > we'll need to add a feature
>> >> switch to turn on that behavior.
>> >> > > > > >
>> >> > > > > > It's a good idea to add a switch. I think QinQ can be
>> >> > > > > > disabled and fallback to current behavior if the switch is
>> >> > > > > > off, since these legacy applications are not written for
>> QinQ.
>> >> > > > >
>> >> > > > > OK.  I'm happy with that solution, as long as the
>> >> > > > > implementation is clean.
>> >> > > >
>> >> > > > Is a new flag, i.e. OVS_DP_F_8021AD, passed via
>> > [Mooney, Sean K]  am I correct in assuming that this new flag will be
>> > set in the ovsdb Either on the bridge or prereably globally in the
>> other_config section fo the Open_vSwitch table.
>> > Both will allow easy detection of the feature form openstack so we
>> can detect if qinq can be used.
>> > The openstack ovs neutron agent currently uses vlans for tenant
>> > isolatation so this would enable Vlan transparency when qinq is
>> available.
>> >> > > > OVS_DP_ATTR_USER_FEATURES an appropriate way to communicate
>> >> > > > this to the kernel?
>> >> > >
>> >> > > Why does the kernel need to know?
>> >> >
>> >> > When extracting the key from a double tagged frame how does the
>> >> > kernel know whether the second tag should be classified as second
>> >> > VLAN or an Ethertype?
>> >>
>> >> The kernel should always classify it as a second VLAN.
>> >> datapath/README.md explains this in detail, under "Basic rule for
>> >> evolving flow keys".
>> > [Mooney, Sean K] out of interest would it be possible to support 3
>> laryers of vlans and still be able to match on the inner packet
>> headers.
>> > As I said about neutron currently uses on level of vlans for tenant
>> > isolation Having qinq would allow the tenant to send one level of
>> vlan
>> > and neutron to use one Layer of vlans for isolation. Support 3
>> layares
>> > fo vlans in ovs would allow the guest to use qinq Neutron to use
>> vlans for isolation at the same time.
>>
>> I believe OVS doesn't have to be aware of the third VLAN in this case.
>> It can be treated as payload.
> [Mooney, Sean K] correct ovs would not have to be aware of the third vlan in this case but
> It would have to be able to look past it and read the l2 heardse of the packet for the normal action to work.

I think MAC addresses and top two VLANs should be enough for normal action.



More information about the dev mailing list