[ovs-git] [openvswitch/ovs] 6e2e18: ofproto-dpif-xlate: Fix zone set from non-frozen-m...

Peng He noreply at github.com
Thu Oct 14 10:00:10 UTC 2021


  Branch: refs/heads/branch-2.13
  Home:   https://github.com/openvswitch/ovs
  Commit: 6e2e1808515b2ffb96817aacd016f73b239a3c95
      https://github.com/openvswitch/ovs/commit/6e2e1808515b2ffb96817aacd016f73b239a3c95
  Author: Peng He <xnhp0320 at gmail.com>
  Date:   2021-10-13 (Wed, 13 Oct 2021)

  Changed paths:
    M include/openvswitch/meta-flow.h
    M lib/meta-flow.c
    M ofproto/ofproto-dpif-xlate.c
    M tests/system-traffic.at

  Log Message:
  -----------
  ofproto-dpif-xlate: Fix zone set from non-frozen-metadata fields.

CT zone could be set from a field that is not included in frozen
metadata. Consider the example rules which are typically seen in
OpenStack security group rules:

priority=100,in_port=1,tcp,ct_state=-trk,action=ct(zone=5,table=0)
priority=100,in_port=1,tcp,ct_state=+trk,action=ct(commit,zone=NXM_NX_CT_ZONE[]),2

The zone is set from the first rule's ct action. These two rules will
generate two megaflows: the first one uses zone=5 to query the CT module,
the second one sets the zone-id from the first megaflow and commit to CT.

The current implementation will generate a megaflow that does not use
ct_zone=5 as a match, but directly commit into the ct using zone=5, as zone is
set by an Imm not a field.

Consider a situation that one changes the zone id (for example to 15)
in the first rule, however, still keep the second rule unchanged. During
this change, there is traffic hitting the two generated megaflows, the
revaldiator would revalidate all megaflows, however, the revalidator will
not change the second megaflow, because zone=5 is recorded in the
megaflow, so the xlate will still translate the commit action into zone=5,
and the new traffic will still commit to CT as zone=5, not zone=15,
resulting in taffic drops and other issues.

Just like OVS set-field convention, if a field X is set by Y
(Y is a variable not an Imm), we should also mask Y as a match
in the generated megaflow. An exception is that if the zone-id is
set by the field that is included in the frozen state (i.e. regs) and this
upcall is a resume of a thawed xlate, the un-wildcarding can be skipped,
as the recirc_id is a hash of the values in these fields, and it will change
following the changes of these fields. When the recirc_id changes,
all megaflows with the old recirc id will be invalid later.

Fixes: 07659514c3 ("Add support for connection tracking.")
Reported-by: Sai Su <susai.ss at bytedance.com>
Signed-off-by: Peng He <hepeng.0320 at bytedance.com>
Acked-by: Mark D. Gray <mark.d.gray at redhat.com>
Signed-off-by: Ilya Maximets <i.maximets at ovn.org>




More information about the git mailing list