cls_flower vlan matching

cls_flower vlan matching

[Vlad Buslov]

Hi Jiri,

I've been debugging an issue that we encounter with OvS-created rules
for single and double-VLAN packets.

Basically, for flows with single VLAN OvS creates following tc filter:

filter protocol 802.1Q pref 2 flower chain 0 
filter protocol 802.1Q pref 2 flower chain 0 handle 0x1 
  vlan_id 10                                                                                                            
  vlan_prio 0             
  vlan_ethtype ip                                                                                                       
  dst_mac e4:2c:0b:08:00:02     
  src_mac b8:ce:f6:05:e7:3a
  eth_type ipv4
  ip_flags nofrag                                                                                                       
  skip_hw                                                                                                               
  not_in_hw               
        action order 1: vlan  pop pipe                                                                                  
         index 2 ref 1 bind 1 installed 11 sec used 0 sec firstused 10 sec
        Action statistics:                     
        Sent 860 bytes 10 pkt (dropped 0, overlimits 0 requeues 0) 
        backlog 0b 0p requeues 0
        no_percpu

        action order 2: mirred (Egress Redirect to device enp8s0f0_0) stolen
        index 2 ref 1 bind 1 installed 11 sec used 0 sec firstused 10 sec
        Action statistics:
        Sent 860 bytes 10 pkt (dropped 0, overlimits 0 requeues 0) 
        backlog 0b 0p requeues 0
        cookie 16a9b603144b3e0c64a887aeb972a269
        no_percpu

Such rule also matches packets that have additional second VLAN header,
even though filter has both eth_type and vlan_ethtype set to "ipv4".
Looking at the code this seems to be mostly an artifact of the way
flower uses flow dissector. First, even though looking at the uAPI
eth_type and vlan_ethtype appear like a distinct fields, in flower they
are all mapped to the same key->basic.n_proto. Second, flow dissector
skips following VLAN header as no keys for FLOW_DISSECTOR_KEY_CVLAN are
set and eventually assigns the value of n_proto to last parsed header.
With these, such filters ignore any headers present between first VLAN
header and first "non magic" header (ipv4 in this case) that doesn't
result FLOW_DISSECT_RET_PROTO_AGAIN.

Is described behavior intentional? Any way to enforce matching for
header following the VLAN header?

Regards,
Vlad

Re: cls_flower vlan matching

[Jiri Pirko]

Mon, Mar 14, 2022 at 06:26:38PM CET, vladbu@nvidia.com wrote:
>Hi Jiri,
>
>I've been debugging an issue that we encounter with OvS-created rules
>for single and double-VLAN packets.
>
>Basically, for flows with single VLAN OvS creates following tc filter:
>
>filter protocol 802.1Q pref 2 flower chain 0 
>filter protocol 802.1Q pref 2 flower chain 0 handle 0x1 
>  vlan_id 10                                                                                                            
>  vlan_prio 0             
>  vlan_ethtype ip                                                                                                       
>  dst_mac e4:2c:0b:08:00:02     
>  src_mac b8:ce:f6:05:e7:3a
>  eth_type ipv4
>  ip_flags nofrag                                                                                                       
>  skip_hw                                                                                                               
>  not_in_hw               
>        action order 1: vlan  pop pipe                                                                                  
>         index 2 ref 1 bind 1 installed 11 sec used 0 sec firstused 10 sec
>        Action statistics:                     
>        Sent 860 bytes 10 pkt (dropped 0, overlimits 0 requeues 0) 
>        backlog 0b 0p requeues 0
>        no_percpu
>
>        action order 2: mirred (Egress Redirect to device enp8s0f0_0) stolen
>        index 2 ref 1 bind 1 installed 11 sec used 0 sec firstused 10 sec
>        Action statistics:
>        Sent 860 bytes 10 pkt (dropped 0, overlimits 0 requeues 0) 
>        backlog 0b 0p requeues 0
>        cookie 16a9b603144b3e0c64a887aeb972a269
>        no_percpu
>
>Such rule also matches packets that have additional second VLAN header,
>even though filter has both eth_type and vlan_ethtype set to "ipv4".
>Looking at the code this seems to be mostly an artifact of the way
>flower uses flow dissector. First, even though looking at the uAPI
>eth_type and vlan_ethtype appear like a distinct fields, in flower they
>are all mapped to the same key->basic.n_proto. Second, flow dissector
>skips following VLAN header as no keys for FLOW_DISSECTOR_KEY_CVLAN are
>set and eventually assigns the value of n_proto to last parsed header.
>With these, such filters ignore any headers present between first VLAN
>header and first "non magic" header (ipv4 in this case) that doesn't
>result FLOW_DISSECT_RET_PROTO_AGAIN.
>
>Is described behavior intentional? Any way to enforce matching for
>header following the VLAN header?

Looks very much like a bug to me.

>
>Regards,
>Vlad