[ovs-dev,3/3] 802.1AD: Flow handling, actions, vlan parsing and netlink attributes
diff mbox

Message ID 56044031.5000303@gmail.com
State Not Applicable
Headers show

Commit Message

Thomas F Herbert Sept. 24, 2015, 6:25 p.m. UTC
Pravin,

I am you hoping you can take a look at a potential problem with my 
kernel module patch submitted to net-dev today. I decided to submit it 
anyway because that is the best way to get eyes on it.

I am still seeing a problem where the 4 conntrak attributes show up in 
an upcall when a double tagged packet is received. The attribute lengths 
for the 4 unknown attributes should be -1 but are showing up as odd 
lengths. I can't see where my patch below is causing this problem but I 
don't see similar errors with missed upcall in either single tagged or 
untagged packets. I have applied my companion patch to the user space 
for 802.1ad so the problem could be in that patch with de-serializing 
"unknown" attributes.

Also, this may not be a problem at all because the kernel module 
includes the conntrak patches but the user space does not as yet.

I am running ovs commit ca92d173 with my user space 802.1ad patch.

The error message is below:

Sep 24 14:01:34 Centos7Bld ovs-vswitchd[2666]: 
recirc_id(0),dp_hash(0),skb_priority(0),in_port(3),skb_mark(0),key22(bad 
key length 1, expected -1)(00),key23(bad key length 2, expected -1)(00 
00),key24(bad key length 4, expected -1)(00 00 00 00),key25(bad key 
length 16, expected -1)(00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00),eth(src=52:f6:ef:24:b6:4e,dst=08:00:27:7f:8f:e1),eth_type(0x88a8),
vlan(vid=100,pcp=0),encap(eth_type(0x8100),vlan(vid=999,pcp=0),encap(eth_type(0x0800),
ipv4(src=192.168.1.3,dst=192.168.1.2,proto=1,tos=0,ttl=64,frag=no),icmp(type=0,code=0)))

Thanks in advance,

Tom Herbert
Red Hat


-------- Forwarded Message --------
Subject: [PATCH 3/3] 802.1AD: Flow handling, actions, vlan parsing and 
netlink attributes
Date: Thu, 24 Sep 2015 13:58:18 -0400
From: Thomas F Herbert <thomasfherbert@gmail.com>
To: netdev@vger.kernel.org, pshelar@nicira.com
CC: therbert@redhat.com, dev@openvswitch.org, Thomas F Herbert 
<thomasfherbert@gmail.com>

Add support for 802.1ad including the ability to push and pop double
tagged vlans. Add support for 802.1ad to netlink parsing and flow
conversion. Uses double nested encap attributes to represent double
tagged vlan. Inner TPID encoded along with ctci in nested attributes.

Signed-off-by: Thomas F Herbert <thomasfherbert@gmail.com>
---
  net/openvswitch/flow.c         |  83 +++++++++++++++++----
  net/openvswitch/flow.h         |   5 ++
  net/openvswitch/flow_netlink.c | 166 
++++++++++++++++++++++++++++++++++++++---
  3 files changed, 230 insertions(+), 24 deletions(-)

*match,
  				u64 attrs, const struct nlattr **a,
  				bool is_mask, bool log)
@@ -1064,6 +1085,80 @@ static void mask_set_nlattr(struct nlattr *attr, 
u8 val)
  	nlattr_set(attr, val, ovs_key_lens);
  }

+static int parse_vlan_from_nlattrs(const struct nlattr **nla,
+				   struct sw_flow_match *match,
+				   u64 *key_attrs, bool *ie_valid,
+				   const struct nlattr **a, bool is_mask,
+				   bool log)
+{
+	int err;
+	const struct nlattr *encap;
+
+	*ie_valid = false;
+	if (!is_mask) {
+		u64 v_attrs = 0;
+
+		err = parse_flow_nlattrs(*nla, a, &v_attrs, log);
+		if (err)
+			return err;
+		/* Another encap attribute here indicates
+		 * the presence of a double tagged vlan.
+		 */
+		if ((v_attrs & (1 << OVS_KEY_ATTR_ETHERTYPE)) &&
+		    eth_type_vlan(nla_get_be16(a[OVS_KEY_ATTR_ETHERTYPE]))) {
+			if (!((v_attrs & (1ULL << OVS_KEY_ATTR_VLAN)) &&
+			      (v_attrs & (1ULL << OVS_KEY_ATTR_ENCAP)))) {
+				OVS_NLERR(log, "Invalid Inner VLAN frame");
+				return -EINVAL;
+			}
+			encap = a[OVS_KEY_ATTR_ENCAP];
+			v_attrs &= ~(1 << OVS_KEY_ATTR_ENCAP);
+
+			err = cust_vlan_from_nlattrs(match, a, is_mask, log);
+			if (err)
+				return err;
+			*ie_valid = true;
+			*nla = encap;
+
+			/* Insure that tci key attribute isn't
+			 * overwritten by encapsulated customer tci.
+			 * Ethertype is cleared because it is c_tpid.
+			 */
+			v_attrs &= ~(1 << OVS_KEY_ATTR_VLAN);
+			v_attrs &= ~(1 << OVS_KEY_ATTR_ETHERTYPE);
+		}
+		*key_attrs |= v_attrs;
+
+	} else {
+		u64 mask_v_attrs = 0;
+
+		err = parse_flow_mask_nlattrs(*nla, a, &mask_v_attrs, log);
+		if (err)
+			return err;
+
+		if (mask_v_attrs & 1 << OVS_KEY_ATTR_ENCAP) {
+			if (!*ie_valid) {
+				OVS_NLERR(log, "Encap mask attribute is set for non-CVLAN frame.");
+				err = -EINVAL;
+				return err;
+			}
+			encap = a[OVS_KEY_ATTR_ENCAP];
+			mask_v_attrs &= ~(1 << OVS_KEY_ATTR_ENCAP);
+
+			err = cust_vlan_from_nlattrs(match, a, is_mask, log);
+			if (err)
+				return err;
+			*nla = encap;
+
+			mask_v_attrs &= ~(1ULL << OVS_KEY_ATTR_VLAN);
+			mask_v_attrs &= ~(1ULL << OVS_KEY_ATTR_ETHERTYPE);
+		}
+
+		*key_attrs |= mask_v_attrs;
+	}
+	return 0;
+}
+
  /**
   * ovs_nla_get_match - parses Netlink attributes into a flow key and
   * mask. In case the 'mask' is NULL, the flow is treated as exact match
@@ -1091,6 +1186,7 @@ int ovs_nla_get_match(struct net *net, struct 
sw_flow_match *match,
  	u64 key_attrs = 0;
  	u64 mask_attrs = 0;
  	bool encap_valid = false;
+	bool i_encap_valid = false;
  	int err;

  	err = parse_flow_nlattrs(nla_key, a, &key_attrs, log);
@@ -1099,11 +1195,11 @@ int ovs_nla_get_match(struct net *net, struct 
sw_flow_match *match,

  	if ((key_attrs & (1 << OVS_KEY_ATTR_ETHERNET)) &&
  	    (key_attrs & (1 << OVS_KEY_ATTR_ETHERTYPE)) &&
-	    (nla_get_be16(a[OVS_KEY_ATTR_ETHERTYPE]) == htons(ETH_P_8021Q))) {
+	    eth_type_vlan(nla_get_be16(a[OVS_KEY_ATTR_ETHERTYPE]))) {
  		__be16 tci;

-		if (!((key_attrs & (1 << OVS_KEY_ATTR_VLAN)) &&
-		      (key_attrs & (1 << OVS_KEY_ATTR_ENCAP)))) {
+		if (!((key_attrs & (1ULL << OVS_KEY_ATTR_VLAN)) &&
+		      (key_attrs & (1ULL << OVS_KEY_ATTR_ENCAP)))) {
  			OVS_NLERR(log, "Invalid Vlan frame.");
  			return -EINVAL;
  		}
@@ -1115,9 +1211,19 @@ int ovs_nla_get_match(struct net *net, struct 
sw_flow_match *match,
  		encap_valid = true;

  		if (tci & htons(VLAN_TAG_PRESENT)) {
-			err = parse_flow_nlattrs(encap, a, &key_attrs, log);
+			err = parse_vlan_from_nlattrs(&encap, match, &key_attrs,
+						      &i_encap_valid, a, false,
+						      log);
  			if (err)
  				return err;
+
+			if (i_encap_valid) {
+				err = parse_flow_nlattrs(encap, a,
+							 &key_attrs,
+							 log);
+				if (err)
+					return err;
+			}
  		} else if (!tci) {
  			/* Corner case for truncated 802.1Q header. */
  			if (nla_len(encap)) {
@@ -1188,10 +1294,21 @@ int ovs_nla_get_match(struct net *net, struct 
sw_flow_match *match,
  			if (eth_type == htons(0xffff)) {
  				mask_attrs &= ~(1 << OVS_KEY_ATTR_ETHERTYPE);
  				encap = a[OVS_KEY_ATTR_ENCAP];
-				err = parse_flow_mask_nlattrs(encap, a,
-							      &mask_attrs, log);
+				err = parse_vlan_from_nlattrs(&encap, match,
+							      &mask_attrs,
+							      &i_encap_valid,
+							      a, true, log);
  				if (err)
  					goto free_newmask;
+
+				if (i_encap_valid) {
+					err =
+					    parse_flow_mask_nlattrs(encap, a,
+								    &mask_attrs,
+								    log);
+					if (err)
+						goto free_newmask;
+				}
  			} else {
  				OVS_NLERR(log, "VLAN frames must have an exact match on the TPID 
(mask=%x).",
  					  ntohs(eth_type));
@@ -1320,6 +1437,7 @@ static int __ovs_nla_put_key(const struct 
sw_flow_key *swkey,
  {
  	struct ovs_key_ethernet *eth_key;
  	struct nlattr *nla, *encap;
+	struct nlattr *in_encap = NULL;

  	if (nla_put_u32(skb, OVS_KEY_ATTR_RECIRC_ID, output->recirc_id))
  		goto nla_put_failure;
@@ -1368,17 +1486,42 @@ static int __ovs_nla_put_key(const struct 
sw_flow_key *swkey,
  	ether_addr_copy(eth_key->eth_src, output->eth.src);
  	ether_addr_copy(eth_key->eth_dst, output->eth.dst);

-	if (swkey->eth.tci || swkey->eth.type == htons(ETH_P_8021Q)) {
+	if (swkey->eth.tci || eth_type_vlan(swkey->eth.type)) {
  		__be16 eth_type;
-		eth_type = !is_mask ? htons(ETH_P_8021Q) : htons(0xffff);
+
+		if (swkey->eth.cvlan.ctci ||
+		    eth_type_vlan(swkey->eth.cvlan.c_tpid))
+			eth_type = !is_mask ? htons(ETH_P_8021AD) :
+					      htons(0xffff);
+		else
+			eth_type = !is_mask ? htons(ETH_P_8021Q) :
+					      htons(0xffff);
+
  		if (nla_put_be16(skb, OVS_KEY_ATTR_ETHERTYPE, eth_type) ||
  		    nla_put_be16(skb, OVS_KEY_ATTR_VLAN, output->eth.tci))
  			goto nla_put_failure;
  		encap = nla_nest_start(skb, OVS_KEY_ATTR_ENCAP);
  		if (!swkey->eth.tci)
  			goto unencap;
-	} else
+		if (swkey->eth.cvlan.ctci || eth_type_vlan(swkey->eth.type)) {
+			__be16 eth_type;
+
+			/* Customer tci is nested but uses same key attribute.
+			 */
+			eth_type = !is_mask ? htons(ETH_P_8021Q) :
+					      htons(0xffff);
+			if (nla_put_be16(skb, OVS_KEY_ATTR_ETHERTYPE,
+					 eth_type) ||
+			    nla_put_be16(skb, OVS_KEY_ATTR_VLAN,
+					 output->eth.cvlan.ctci))
+				goto nla_put_failure;
+			in_encap = nla_nest_start(skb, OVS_KEY_ATTR_ENCAP);
+			if (!swkey->eth.cvlan.ctci)
+				goto unencap;
+		}
+	} else {
  		encap = NULL;
+	}

  	if (swkey->eth.type == htons(ETH_P_802_2)) {
  		/*
@@ -1525,6 +1668,8 @@ static int __ovs_nla_put_key(const struct 
sw_flow_key *swkey,
  unencap:
  	if (encap)
  		nla_nest_end(skb, encap);
+	if (in_encap)
+		nla_nest_end(skb, in_encap);

  	return 0;

@@ -2174,7 +2319,8 @@ static int __ovs_nla_copy_actions(struct net *net, 
const struct nlattr *attr,

  		case OVS_ACTION_ATTR_PUSH_VLAN:
  			vlan = nla_data(a);
-			if (vlan->vlan_tpid != htons(ETH_P_8021Q))
+			if ((vlan->vlan_tpid != htons(ETH_P_8021Q)) &&
+			    (vlan->vlan_tpid != htons(ETH_P_8021AD)))
  				return -EINVAL;
  			if (!(vlan->vlan_tci & htons(VLAN_TAG_PRESENT)))
  				return -EINVAL;

Comments

Pravin B Shelar Sept. 24, 2015, 11:43 p.m. UTC | #1
On Thu, Sep 24, 2015 at 11:25 AM, Thomas F Herbert
<thomasfherbert@gmail.com> wrote:
> Pravin,
>
> I am you hoping you can take a look at a potential problem with my kernel
> module patch submitted to net-dev today. I decided to submit it anyway
> because that is the best way to get eyes on it.
>
> I am still seeing a problem where the 4 conntrak attributes show up in an
> upcall when a double tagged packet is received. The attribute lengths for
> the 4 unknown attributes should be -1 but are showing up as odd lengths. I
> can't see where my patch below is causing this problem but I don't see
> similar errors with missed upcall in either single tagged or untagged
> packets. I have applied my companion patch to the user space for 802.1ad so
> the problem could be in that patch with de-serializing "unknown" attributes.
>
> Also, this may not be a problem at all because the kernel module includes
> the conntrak patches but the user space does not as yet.
>
> I am running ovs commit ca92d173 with my user space 802.1ad patch.
>
> The error message is below:
>
> Sep 24 14:01:34 Centos7Bld ovs-vswitchd[2666]:
> recirc_id(0),dp_hash(0),skb_priority(0),in_port(3),skb_mark(0),key22(bad key
> length 1, expected -1)(00),key23(bad key length 2, expected -1)(00
> 00),key24(bad key length 4, expected -1)(00 00 00 00),key25(bad key length
> 16, expected -1)(00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00),eth(src=52:f6:ef:24:b6:4e,dst=08:00:27:7f:8f:e1),eth_type(0x88a8),
> vlan(vid=100,pcp=0),encap(eth_type(0x8100),vlan(vid=999,pcp=0),encap(eth_type(0x0800),
> ipv4(src=192.168.1.3,dst=192.168.1.2,proto=1,tos=0,ttl=64,frag=no),icmp(type=0,code=0)))
>

I am not sure. can you send me github link to user-space patch, so
that I can check.
Thomas F Herbert Sept. 25, 2015, 12:10 p.m. UTC | #2
On 9/24/15 7:43 PM, Pravin Shelar wrote:
> On Thu, Sep 24, 2015 at 11:25 AM, Thomas F Herbert
> <thomasfherbert@gmail.com> wrote:
>> Pravin,
>>
>> I am you hoping you can take a look at a potential problem with my kernel
>> module patch submitted to net-dev today. I decided to submit it anyway
>> because that is the best way to get eyes on it.
>>
>> I am still seeing a problem where the 4 conntrak attributes show up in an
>> upcall when a double tagged packet is received. The attribute lengths for
>> the 4 unknown attributes should be -1 but are showing up as odd lengths. I
>> can't see where my patch below is causing this problem but I don't see
>> similar errors with missed upcall in either single tagged or untagged
>> packets. I have applied my companion patch to the user space for 802.1ad so
>> the problem could be in that patch with de-serializing "unknown" attributes.
>>
>> Also, this may not be a problem at all because the kernel module includes
>> the conntrak patches but the user space does not as yet.
>>
>> I am running ovs commit ca92d173 with my user space 802.1ad patch.
>>
>> The error message is below:
>>
>> Sep 24 14:01:34 Centos7Bld ovs-vswitchd[2666]:
>> recirc_id(0),dp_hash(0),skb_priority(0),in_port(3),skb_mark(0),key22(bad key
>> length 1, expected -1)(00),key23(bad key length 2, expected -1)(00
>> 00),key24(bad key length 4, expected -1)(00 00 00 00),key25(bad key length
>> 16, expected -1)(00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> 00),eth(src=52:f6:ef:24:b6:4e,dst=08:00:27:7f:8f:e1),eth_type(0x88a8),
>> vlan(vid=100,pcp=0),encap(eth_type(0x8100),vlan(vid=999,pcp=0),encap(eth_type(0x0800),
>> ipv4(src=192.168.1.3,dst=192.168.1.2,proto=1,tos=0,ttl=64,frag=no),icmp(type=0,code=0)))
>>
>
> I am not sure. can you send me github link to user-space patch, so
> that I can check.
Pravin,

OK, also I noticed that the user space patch for conntrak was submitted 
on 9/17. I think I will try to rebase user space patch on top of 
conntrak patch and re-test after fixing issues in kernel patch.

Thanks,
>
Joe Stringer Sept. 25, 2015, 5:56 p.m. UTC | #3
On 25 September 2015 at 05:10, Thomas F Herbert
<thomasfherbert@gmail.com> wrote:
> On 9/24/15 7:43 PM, Pravin Shelar wrote:
>>
>> On Thu, Sep 24, 2015 at 11:25 AM, Thomas F Herbert
>> <thomasfherbert@gmail.com> wrote:
>>>
>>> Pravin,
>>>
>>> I am you hoping you can take a look at a potential problem with my kernel
>>> module patch submitted to net-dev today. I decided to submit it anyway
>>> because that is the best way to get eyes on it.
>>>
>>> I am still seeing a problem where the 4 conntrak attributes show up in an
>>> upcall when a double tagged packet is received. The attribute lengths for
>>> the 4 unknown attributes should be -1 but are showing up as odd lengths.
>>> I
>>> can't see where my patch below is causing this problem but I don't see
>>> similar errors with missed upcall in either single tagged or untagged
>>> packets. I have applied my companion patch to the user space for 802.1ad
>>> so
>>> the problem could be in that patch with de-serializing "unknown"
>>> attributes.
>>>
>>> Also, this may not be a problem at all because the kernel module includes
>>> the conntrak patches but the user space does not as yet.
>>>
>>> I am running ovs commit ca92d173 with my user space 802.1ad patch.
>>>
>>> The error message is below:
>>>
>>> Sep 24 14:01:34 Centos7Bld ovs-vswitchd[2666]:
>>> recirc_id(0),dp_hash(0),skb_priority(0),in_port(3),skb_mark(0),key22(bad
>>> key
>>> length 1, expected -1)(00),key23(bad key length 2, expected -1)(00
>>> 00),key24(bad key length 4, expected -1)(00 00 00 00),key25(bad key
>>> length
>>> 16, expected -1)(00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> 00),eth(src=52:f6:ef:24:b6:4e,dst=08:00:27:7f:8f:e1),eth_type(0x88a8),
>>>
>>> vlan(vid=100,pcp=0),encap(eth_type(0x8100),vlan(vid=999,pcp=0),encap(eth_type(0x0800),
>>>
>>> ipv4(src=192.168.1.3,dst=192.168.1.2,proto=1,tos=0,ttl=64,frag=no),icmp(type=0,code=0)))
>>>
>>
>> I am not sure. can you send me github link to user-space patch, so
>> that I can check.
>
> Pravin,
>
> OK, also I noticed that the user space patch for conntrak was submitted on
> 9/17. I think I will try to rebase user space patch on top of conntrak patch
> and re-test after fixing issues in kernel patch.
>
> Thanks,

Thomas,

It looks like a mismatch between your kernel module headers and
userspace headers. The conntrack changes upstream introduce four new
KEY_ATTRs, but those haven't been backported to the userspace yet. So,
if you add new KEY_ATTR numbers in
$OVS_GIT/datapath/linux/compat/include/linux/openvswitch.h, then they
may conflict with the numbers that the kernel uses in
$LINUX_GIT/include/uapi/linux/openvswich. The kernel version is the
source of truth for these.

You're right, there was patches submitted for this recently and I'm
actively working on trying to get those integrated into the OVS tree.
Thomas F Herbert Sept. 30, 2015, 12:39 a.m. UTC | #4
On 9/25/15 1:56 PM, Joe Stringer wrote:
> On 25 September 2015 at 05:10, Thomas F Herbert
> <thomasfherbert@gmail.com> wrote:
>> On 9/24/15 7:43 PM, Pravin Shelar wrote:
>>> On Thu, Sep 24, 2015 at 11:25 AM, Thomas F Herbert
>>> <thomasfherbert@gmail.com> wrote:
>>>> Pravin,
>>>>
>>>> I am you hoping you can take a look at a potential problem with my kernel
>>>> module patch submitted to net-dev today. I decided to submit it anyway
>>>> because that is the best way to get eyes on it.
>>>>
>>>> I am still seeing a problem where the 4 conntrak attributes show up in an
>>>> upcall when a double tagged packet is received. The attribute lengths for
>>>> the 4 unknown attributes should be -1 but are showing up as odd lengths.
>>>> I
>>>> can't see where my patch below is causing this problem but I don't see
>>>> similar errors with missed upcall in either single tagged or untagged
>>>> packets. I have applied my companion patch to the user space for 802.1ad
>>>> so
>>>> the problem could be in that patch with de-serializing "unknown"
>>>> attributes.
>>>>
>>>> Also, this may not be a problem at all because the kernel module includes
>>>> the conntrak patches but the user space does not as yet.
>>>>
>>>> I am running ovs commit ca92d173 with my user space 802.1ad patch.
>>>>
>>>> The error message is below:
>>>>
>>>> Sep 24 14:01:34 Centos7Bld ovs-vswitchd[2666]:
>>>> recirc_id(0),dp_hash(0),skb_priority(0),in_port(3),skb_mark(0),key22(bad
>>>> key
>>>> length 1, expected -1)(00),key23(bad key length 2, expected -1)(00
>>>> 00),key24(bad key length 4, expected -1)(00 00 00 00),key25(bad key
>>>> length
>>>> 16, expected -1)(00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>> 00),eth(src=52:f6:ef:24:b6:4e,dst=08:00:27:7f:8f:e1),eth_type(0x88a8),
>>>>
>>>> vlan(vid=100,pcp=0),encap(eth_type(0x8100),vlan(vid=999,pcp=0),encap(eth_type(0x0800),
>>>>
>>>> ipv4(src=192.168.1.3,dst=192.168.1.2,proto=1,tos=0,ttl=64,frag=no),icmp(type=0,code=0)))
>>>>
>>> I am not sure. can you send me github link to user-space patch, so
>>> that I can check.
>> Pravin,
>>
>> OK, also I noticed that the user space patch for conntrak was submitted on
>> 9/17. I think I will try to rebase user space patch on top of conntrak patch
>> and re-test after fixing issues in kernel patch.
>>
>> Thanks,
> Thomas,
>
> It looks like a mismatch between your kernel module headers and
> userspace headers. The conntrack changes upstream introduce four new
> KEY_ATTRs, but those haven't been backported to the userspace yet. So,
> if you add new KEY_ATTR numbers in
> $OVS_GIT/datapath/linux/compat/include/linux/openvswitch.h, then they
> may conflict with the numbers that the kernel uses in
> $LINUX_GIT/include/uapi/linux/openvswich. The kernel version is the
> source of truth for these.
>
> You're right, there was patches submitted for this recently and I'm
> actively working on trying to get those integrated into the OVS tree.
Yes, that is what I figured. Thanks, Joe.
>

Patch
diff mbox

diff --git a/net/openvswitch/flow.c b/net/openvswitch/flow.c
index c8db44a..db58e47 100644
--- a/net/openvswitch/flow.c
+++ b/net/openvswitch/flow.c
@@ -305,21 +305,77 @@  static bool icmp6hdr_ok(struct sk_buff *skb)
  static int parse_vlan(struct sk_buff *skb, struct sw_flow_key *key)
  {
  	struct qtag_prefix {
-		__be16 eth_type; /* ETH_P_8021Q */
+		__be16 eth_type; /* ETH_P_8021Q  or ETH_P_8021AD */
  		__be16 tci;
  	};
-	struct qtag_prefix *qp;
+	struct qtag_prefix *qp = (struct qtag_prefix *)skb->data;

-	if (unlikely(skb->len < sizeof(struct qtag_prefix) + sizeof(__be16)))
+	struct qinqtag_prefix {
+		__be16 eth_type; /* ETH_P_8021Q  or ETH_P_8021AD */
+		__be16 tci;
+		__be16 inner_tpid; /* ETH_P_8021Q */
+		__be16 ctci;
+	};
+
+	if (likely(skb_vlan_tag_present(skb))) {
+		key->eth.tci = htons(skb->vlan_tci);
+
+		/* Case where upstream
+		 * processing has already stripped the outer vlan tag.
+		 */
+		if (unlikely(skb->vlan_proto == htons(ETH_P_8021AD))) {
+			if (unlikely(skb->len < sizeof(struct qtag_prefix) +
+					sizeof(__be16))) {
+				key->eth.tci = 0;
+				return 0;
+			}
+
+			if (unlikely(!pskb_may_pull(skb,
+						    sizeof(struct qtag_prefix) +
+						    sizeof(__be16))))
+				return -ENOMEM;
+
+			key->eth.cvlan.ctci =
+				qp->tci | htons(VLAN_TAG_PRESENT);
+			key->eth.cvlan.c_tpid = qp->eth_type;
+
+			__skb_pull(skb, sizeof(struct qtag_prefix));
+		}
  		return 0;
+	}

-	if (unlikely(!pskb_may_pull(skb, sizeof(struct qtag_prefix) +
-					 sizeof(__be16))))
-		return -ENOMEM;

-	qp = (struct qtag_prefix *) skb->data;
-	key->eth.tci = qp->tci | htons(VLAN_TAG_PRESENT);
-	__skb_pull(skb, sizeof(struct qtag_prefix));
+	if (qp->eth_type == htons(ETH_P_8021AD)) {
+		struct qinqtag_prefix *qinqp =
+					(struct qinqtag_prefix *)skb->data;
+
+		if (unlikely(skb->len < sizeof(struct qinqtag_prefix) +
+					sizeof(__be16)))
+			return 0;
+
+		if (unlikely(!pskb_may_pull(skb, sizeof(struct qinqtag_prefix) +
+				sizeof(__be16))))
+			return -ENOMEM;
+		key->eth.tci = qinqp->tci | htons(VLAN_TAG_PRESENT);
+		key->eth.cvlan.ctci = qinqp->ctci | htons(VLAN_TAG_PRESENT);
+		key->eth.cvlan.c_tpid = qinqp->inner_tpid;
+
+		__skb_pull(skb, sizeof(struct qinqtag_prefix));
+
+		return 0;
+	}
+	if (qp->eth_type == htons(ETH_P_8021Q)) {
+		if (unlikely(skb->len < sizeof(struct qtag_prefix) +
+					sizeof(__be16)))
+			return -ENOMEM;
+
+		if (unlikely(!pskb_may_pull(skb, sizeof(struct qtag_prefix) +
+				sizeof(__be16))))
+			return 0;
+		key->eth.tci = qp->tci | htons(VLAN_TAG_PRESENT);
+
+		__skb_pull(skb, sizeof(struct qtag_prefix));
+	}

  	return 0;
  }
@@ -481,11 +537,10 @@  static int key_extract(struct sk_buff *skb, struct 
sw_flow_key *key)
  	 */

  	key->eth.tci = 0;
-	if (skb_vlan_tag_present(skb))
-		key->eth.tci = htons(skb->vlan_tci);
-	else if (eth->h_proto == htons(ETH_P_8021Q))
-		if (unlikely(parse_vlan(skb, key)))
-			return -ENOMEM;
+	key->eth.cvlan.ctci = 0;
+	key->eth.cvlan.c_tpid = 0;
+	if (unlikely(parse_vlan(skb, key)))
+		return -ENOMEM;

  	key->eth.type = parse_ethertype(skb);
  	if (unlikely(key->eth.type == htons(0)))
diff --git a/net/openvswitch/flow.h b/net/openvswitch/flow.h
index fe527d2..2c491e8 100644
--- a/net/openvswitch/flow.h
+++ b/net/openvswitch/flow.h
@@ -69,6 +69,11 @@  struct sw_flow_key {
  		u8     src[ETH_ALEN];	/* Ethernet source address. */
  		u8     dst[ETH_ALEN];	/* Ethernet destination address. */
  		__be16 tci;		/* 0 if no VLAN, VLAN_TAG_PRESENT set otherwise. */
+		struct {
+			__be16 c_tpid;	/* Vlan DL_type 802.1q or 802.1ad */
+			__be16 ctci;	/* 0 if no CVLAN, VLAN_TAG_PRESENT */
+					/* set otherwise. */
+		} cvlan;
  		__be16 type;		/* Ethernet frame type. */
  	} eth;
  	union {
diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
index c92d6a2..5fe415d 100644
--- a/net/openvswitch/flow_netlink.c
+++ b/net/openvswitch/flow_netlink.c
@@ -811,6 +811,27 @@  static int metadata_from_nlattrs(struct net *net, 
struct sw_flow_match *match,
  	return 0;
  }

+static int cust_vlan_from_nlattrs(struct sw_flow_match *match,
+				  const struct nlattr *a[],
+				  bool is_mask, bool log)
+{
+	__be16 ctci = 0;
+	__be16 c_tpid = 0;
+
+	ctci = nla_get_be16(a[OVS_KEY_ATTR_VLAN]);
+	if (!(ctci & htons(VLAN_TAG_PRESENT))) {
+		if (is_mask)
+			OVS_NLERR(log, "VLAN CTCI mask does not have exact match for 
VLAN_TAG_PRESENT bit.");
+		else
+			OVS_NLERR(log, "VLAN CTCI does not have VLAN_TAG_PRESENT bit set.");
+		return -EINVAL;
+	}
+	c_tpid = nla_get_be16(a[OVS_KEY_ATTR_ETHERTYPE]);
+	SW_FLOW_KEY_PUT(match, eth.cvlan.c_tpid, c_tpid, is_mask);
+	SW_FLOW_KEY_PUT(match, eth.cvlan.ctci, ctci, is_mask);
+	return 0;
+}
+
  static int ovs_key_from_nlattrs(struct net *net, struct sw_flow_match