From patchwork Wed May 12 20:15:44 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ben Pfaff X-Patchwork-Id: 1477824 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=openvswitch.org (client-ip=140.211.166.138; helo=smtp1.osuosl.org; envelope-from=ovs-dev-bounces@openvswitch.org; receiver=) Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4FgQz36Blbz9tk6 for ; Thu, 13 May 2021 06:15:59 +1000 (AEST) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 16090843D1; Wed, 12 May 2021 20:15:58 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InsjCM3rS-EC; Wed, 12 May 2021 20:15:56 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [IPv6:2605:bc80:3010:104::8cd3:938]) by smtp1.osuosl.org (Postfix) with ESMTP id DB0A8843D2; Wed, 12 May 2021 20:15:55 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id AA3D2C000D; Wed, 12 May 2021 20:15:55 +0000 (UTC) X-Original-To: dev@openvswitch.org Delivered-To: ovs-dev@lists.linuxfoundation.org Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 15958C0001 for ; Wed, 12 May 2021 20:15:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id EF71440F87 for ; Wed, 12 May 2021 20:15:54 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3Sx7lDYqrkJ for ; Wed, 12 May 2021 20:15:53 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from relay8-d.mail.gandi.net (relay8-d.mail.gandi.net [217.70.183.201]) by smtp4.osuosl.org (Postfix) with ESMTPS id D37B640F84 for ; Wed, 12 May 2021 20:15:52 +0000 (UTC) X-Originating-IP: 75.54.222.30 Received: from sigfpe.attlocal.net (75-54-222-30.lightspeed.rdcyca.sbcglobal.net [75.54.222.30]) (Authenticated sender: blp@ovn.org) by relay8-d.mail.gandi.net (Postfix) with ESMTPSA id 184FF1BF206; Wed, 12 May 2021 20:15:48 +0000 (UTC) From: Ben Pfaff To: dev@openvswitch.org Date: Wed, 12 May 2021 13:15:44 -0700 Message-Id: <20210512201544.1390419-1-blp@ovn.org> X-Mailer: git-send-email 2.31.1 MIME-Version: 1.0 Cc: Ben Pfaff Subject: [ovs-dev] [PATCH v2] ovs-actions: Document normal pipeline. X-BeenThere: ovs-dev@openvswitch.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ovs-dev-bounces@openvswitch.org Sender: "dev" Signed-off-by: Ben Pfaff Acked-by: Ilya Maximets --- v1->v2: Break bond admissibility step into two steps to make it clearer. Fix a typo. Rephrase some text for clarity. Thanks to Ilya Maximets for the review. lib/ovs-actions.xml | 304 +++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 302 insertions(+), 2 deletions(-) diff --git a/lib/ovs-actions.xml b/lib/ovs-actions.xml index a2778de4bcd6..7beafa7943bb 100644 --- a/lib/ovs-actions.xml +++ b/lib/ovs-actions.xml @@ -509,7 +509,8 @@ $ ovs-ofctl -O OpenFlow10 add-flow br0 actions=mod_nw_src:1.2.3.4
Subjects the packet to the device's normal L2/L3 processing. This action is not implemented by all OpenFlow switches, and each switch - implements it differently. + implements it differently. The section ``The OVS Normal Pipeline'' + below documents the OVS implementation.
flood
@@ -582,7 +583,6 @@ $ ovs-ofctl -O OpenFlow10 add-flow br0 actions=mod_nw_src:1.2.3.4 OpenFlow allows switches to reject such actions.

-

Output to the Input Port

@@ -664,6 +664,306 @@ $ ovs-ofctl -O OpenFlow10 add-flow br0 actions=mod_nw_src:1.2.3.4 +

The OVS Normal Pipeline

+ +

+ This section documents how Open vSwitch implements output to the + normal port. The OpenFlow specification places no + requirements on how this port works, so all of this documentation is + specific to Open vSwitch. +

+ +

+ Open vSwitch uses the Open_vSwitch database, detailed in + ovs-vswitchd.conf.db(5), to determine the details of the + normal pipeline. +

+ +

+ The normal pipeline executes the following ingress stages for each + packet. Each stage either accepts the packet, in which case the packet + goes on to the next stage, or drops the packet, which terminates the + pipeline. The result of the ingress stages is a set of output ports, + which is the empty set if some ingress stage drops the packet: +

+ +
    +
  1. +

    + Input port lookup: Looks up the OpenFlow + in_port field's value to the corresponding + Port and Interface record in the database. +

    + +

    + The in_port is normally the OpenFlow port that the + packet was received on. If set_field or another actions + changes the in_port, the updated value is honored. + Accept the packet if the lookup succeeds, which it normally will. If + the lookupn fails, for example because in_port was + changed to an unknown value, drop the packet. +

    +
    2. + +
  2. + Drop malformed packet: If the packet is malformed enough that it + contains only part of an 802.1Q header, then drop the packet with an + error. +
    3. + +
  3. + Drop packets sent to a port reserved for mirroring: If the + packet was received on a port that is configured as the output port for + a mirror (that is, it is the output_port in some + Mirror record), then drop the packet. +
    4. + +
  4. +

    + VLAN input processing: This stage determines what VLAN the + packet is in. It also verifies that this VLAN is valid for the port; + if not, drop the packet. How the VLAN is determined and which ones + are valid vary based on the vlan-mode in the input + port's Port record: +

    + +
    +
    trunk
    +
    + The packet is in the VLAN specified in its 802.1Q header, or in + VLAN 0 if there is no 802.1Q header. The trunks + column in the Port record lists the valid VLANs; if it + is empty, all VLANs are valid. +
    + +
    access
    +
    + The packet is in the VLAN specified in the tag column + of its Port record. The packet must not have an + 802.1Q header with a nonzero VLAN ID; if it does, drop the packet. +
    + +
    native-tagged
    +
    native-untagged
    +
    + Same as trunk except that the VLAN of a packet without + an 802.1Q header is not necessarily zero; instead, it is taken from + the tag column. +
    + +
    dot1q-tunnel
    +
    + The packet is in the VLAN specified in the tag column + of its Port record, which is a QinQ service VLAN with + the Ethertype specified by the Port's + other_config : qinq-ethtype. If the + packet has an 802.1Q header, then it specifies the customer VLAN. + The cvlans column specifies the valid customer VLANs; + if it is empty, all customer VLANs are valid. +
    +
    +
    5. + +
  5. + Drop reserved multicast addresses: If the packet is addressed to + a reserved Ethernet multicast address and the Bridge + record does not have other_config : + forward-bpdu set to true, drop the packet. +
    6. + +
  6. +

    + LACP bond admissibility: This step applies only if the input + port is a member of a bond (a Port with more than one + Interface) and that bond is configured to use LACP. + Otherwise, skip to the next step. +

    + +

    + The behavior here depends on the state of LACP negotiation: +

    + +
      +
    • + If LACP has been negotiated with the peer, accept the packet if the + bond member is enabled (i.e. carrier is up and it hasn't been + administratively disabled). Otherwise, drop the packet. +
      • + +
    • + If LACP negotiation is incomplete, then drop the packet. There is + one exception: if fallback to active-backup mode is enabled, + continue with the next step, pretending that the active-backup + balancing mode is in use. +
      • +
    +
    7. + +
  7. +

    + Non-LACP bond admissibility: This step applies if the input + port is a member of a bond without LACP configured, or if a LACP bond + falls back to active-backup as described in the previous step. If + neither of these applies, skip to the next step. +

    + +

    + If the packet is an Ethernet multicast or broadcast, and not received + on the bond's active member, drop the packet. +

    + +

    + The remaining behavior depends on the bond's balancing mode: +

    + +
    +
    L4 (aka TCP balancing)
    +
    + Drop the packet (this balancing mode is only supported with LACP). +
    + +
    Active-backup
    +
    + Accept the packet only if and only it was received on the active + member. +
    + +
    SLB (Source Load Balancing)
    +
    + Drop the packet if the bridge has not learned the packet's source + address (in its VLAN) on the port that received it. Otherwise, + accept the packet unless it is a gratuituous ARP. Otherwise, + accept the packet if the MAC entry we found is ARP-locked. + Otherwise, drop the packet. (See the ``SLB Bonding'' section in + the OVS bonding document for more information and a rationale.) +
    +
    +
    8. + +
  8. +

    + Learn source MAC: If the source Ethernet address is not a + multicast address, then insert a mapping from packet's source + Ethernet address and VLAN to the input port in the bridge's MAC + learning table. (This is skipped if the packet's VLAN is listed in + the switch's Bridge record in the + flood_vlans column, since there is no use for MAC + learning when all packets are flooded.) +

    + +

    + When learning happens on a non-bond port, if the packet is a + gratuitous ARP, the entry is marked as ARP-locked. The lock expires + after 5 seconds. (See the ``SLB Bonding'' section in the OVS bonding + document for more information and a rationale.) +

    +
    9. + +
  9. + IP multicast path: If multicast snooping is enabled on the + bridge, and the packet is an Ethernet multicast but not an Ethernet + broadcast, and the packet is an IP packet, then the packet takes a + special processing path. This path is not yet documented here. +
    10. + +
  10. +

    + Output port set: Search the MAC learning table for the port + corresponding to the packet's Ethernet destination and VLAN. If the + search finds an entry, the output port set is the just the learned + port. Otherwise (including the case where the packet is an Ethernet + multicast or in flood_vlans), the output port set is all + of the ports in the bridge that belong to the packet's VLAN, except + for any ports that were disabled for flooding via OpenFlow or that + are configured in a Mirror record as a mirror + destination port. +

    +
    11. +
+ +

+ The following egress stages execute once for each element in the set of + output ports. They execute (conceptually) in parallel, so that a + decision or action taken for a given output port has no effect on those + for another one: +

+ +
    +
  1. + Drop loopback: If the output port is the same as the input port, + drop the packet. +
    2. + +
  2. +

    + VLAN output processing: This stage adjusts the packet to + represent the VLAN in the correct way for the output port. Its + behavior varies based on the vlan-mode in the output + port's Port record: +

    + +
    +
    trunk
    +
    native-tagged
    +
    native-untagged
    +
    + If the packet is in VLAN 0 (for native-untagged, if + the packet is in the native VLAN) drops any 802.1Q header. + Otherwise, ensures that there is an 802.1Q header designating the + VLAN. +
    + +
    access
    +
    + Remove any 802.1Q header that was present. +
    + +
    dot1q-tunnel
    +
    + Ensures that the packet has an outer 802.1Q header with the QinQ + Ethertype and the specified configured tag, and an inner 802.1Q + header with the packet's VLAN. +
    +
    +
    3. + +
  3. + VLAN priority tag processing: If VLAN output processing + discarded the 802.1Q headers, but priority tags are enabled with + other_config : priority-tags in the output + port's Port record, then a priority-only tag is added + (perhaps only if the priority woule be nonzero, depending on the + configuration). +
    4. + +
  4. +

    + Bond member choice: If the output port is a bond, the code + chooses a particular member. This step is skipped for non-bonded + ports. +

    + +

    + If the bond is configured to use LACP, but LACP negotiation is + incomplete, then normally the packet is dropped. The exception is + that if fallback to active-backup mode is enabled, the egress + pipeline continues choosing a bond member as if active-backup mode + was in use. +

    + +

    + For active-backup mode, the output member is the active member. + Other modes hash appropriate header fields and use the hash value to + choose one of the enabled members. +

    +
    5. + +
  5. + Output: The pipeline sends the packet to the output port. +
    6. +
+

The controller action

controller