This bug is awaiting verification that the linux-bluefield/5.4.0-1037.40
kernel in -proposed solves the problem. Please test the kernel and
update this bug with the results. If the problem is solved, change the
tag 'verification-needed-focal' to 'verification-done-focal'. If the
problem still exists, change the tag 'verification-needed-focal' to
'verification-failed-focal'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-focal

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-bluefield in Ubuntu.
https://bugs.launchpad.net/bugs/1974096

Title:
  cls_flower: Fix inability to match GRE/IPIP packets

Status in linux-bluefield package in Ubuntu:
  Invalid
Status in linux-bluefield source package in Focal:
  Fix Committed

Bug description:
  * Explain the bug
      When a packet of a new flow arrives in openvswitch kernel module, it 
dissects
      the packet and passes the extracted flow key to ovs-vswtichd daemon. If 
hw-
      offload configuration is enabled, the daemon creates a new TC flower 
entry to
      bypass openvswitch kernel module for the flow (TC flower can also offload 
flows
      to NICs but this time that does not matter).

      In this processing flow, I found the following issue in cases of GRE/IPIP
      packets.

      When ovs_flow_key_extract() in openvswitch module parses a packet of a new
      GRE (or IPIP) flow received on non-tunneling vports, it extracts 
information
      of the outer IP header for ip_proto/src_ip/dst_ip match keys.

      This means ovs-vswitchd creates a TC flower entry with IP 
protocol/addresses
      match keys whose values are those of the outer IP header. OTOH, TC flower,
      which uses flow_dissector (different parser from openvswitch module), 
extracts
      information of the inner IP header.

  * How to test
      The following flow is an example to describe the issue in more detail.

         <----------- Outer IP -----------------> <---------- Inner IP 
---------->
        
+----------+--------------+--------------+----------+----------+----------+
        | ip_proto | src_ip       | dst_ip       | ip_proto | src_ip   | dst_ip 
  |
        | 47 (GRE) | 192.168.10.1 | 192.168.10.2 | 6 (TCP)  | 10.0.0.1 | 
10.0.0.2 |
        
+----------+--------------+--------------+----------+----------+----------+

      In this case, TC flower entry and extracted information are shown
  as below:

        - ovs-vswitchd creates TC flower entry with:
            - ip_proto: 47
            - src_ip: 192.168.10.1
            - dst_ip: 192.168.10.2

        - TC flower extracts below for IP header matches:
            - ip_proto: 6
            - src_ip: 10.0.0.1
            - dst_ip: 10.0.0.2

      Thus, GRE or IPIP packets never match the TC flower entry, as each
      dissector behaves differently.

      IMHO, the behavior of TC flower (flow dissector) does not look correct,
      as ip_proto/src_ip/dst_ip in TC flower match means the outermost IP
      header information except for GRE/IPIP cases. This patch adds a new
      flow_dissector flag FLOW_DISSECTOR_F_STOP_BEFORE_ENCAP which skips
      dissection of the encapsulated inner GRE/IPIP header in TC flower
      classifier.

  * What it could break.
      N/A

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1974096/+subscriptions


-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to     : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to