{"id":2229777,"url":"http://patchwork.ozlabs.org/api/1.1/patches/2229777/?format=json","web_url":"http://patchwork.ozlabs.org/project/ovn/patch/20260428174509.145440-4-mmichels@redhat.com/","project":{"id":68,"url":"http://patchwork.ozlabs.org/api/1.1/projects/68/?format=json","name":"Open Virtual Network development","link_name":"ovn","list_id":"ovs-dev.openvswitch.org","list_email":"ovs-dev@openvswitch.org","web_url":"http://openvswitch.org/","scm_url":"","webscm_url":""},"msgid":"<20260428174509.145440-4-mmichels@redhat.com>","date":"2026-04-28T17:45:03","name":"[ovs-dev,3/5] northd: Split logical flow docs into ovn-logical-flows(7).","commit_ref":null,"pull_url":null,"state":"new","archived":false,"hash":"fe5923b0224df923ad768056fe0797abf3a6f014","submitter":{"id":71978,"url":"http://patchwork.ozlabs.org/api/1.1/people/71978/?format=json","name":"Mark Michelson","email":"mmichels@redhat.com"},"delegate":null,"mbox":"http://patchwork.ozlabs.org/project/ovn/patch/20260428174509.145440-4-mmichels@redhat.com/mbox/","series":[{"id":501914,"url":"http://patchwork.ozlabs.org/api/1.1/series/501914/?format=json","web_url":"http://patchwork.ozlabs.org/project/ovn/list/?series=501914","date":"2026-04-28T17:45:02","name":"Fix up northd documentation.","version":1,"mbox":"http://patchwork.ozlabs.org/series/501914/mbox/"}],"comments":"http://patchwork.ozlabs.org/api/patches/2229777/comments/","check":"fail","checks":"http://patchwork.ozlabs.org/api/patches/2229777/checks/","tags":{},"headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","dev@openvswitch.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","ovs-dev@lists.linuxfoundation.org"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256\n header.s=mimecast20190719 header.b=KUcU0B7N;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=openvswitch.org\n (client-ip=140.211.166.133; helo=smtp2.osuosl.org;\n envelope-from=ovs-dev-bounces@openvswitch.org; receiver=patchwork.ozlabs.org)","smtp2.osuosl.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key)\n header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256\n header.s=mimecast20190719 header.b=KUcU0B7N","smtp1.osuosl.org; dmarc=pass (p=quarantine dis=none)\n header.from=redhat.com","smtp1.osuosl.org;\n dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com\n header.a=rsa-sha256 header.s=mimecast20190719 header.b=KUcU0B7N"],"Received":["from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g4nsd2d5Tz1xvV\n\tfor ; Wed, 29 Apr 2026 03:45:56 +1000 (AEST)","from localhost (localhost [127.0.0.1])\n\tby smtp2.osuosl.org (Postfix) with ESMTP id B0B9940863;\n\tTue, 28 Apr 2026 17:45:54 +0000 (UTC)","from smtp2.osuosl.org ([127.0.0.1])\n by localhost (smtp2.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP\n id 8V6Lfe4Hl89M; Tue, 28 Apr 2026 17:45:51 +0000 (UTC)","from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56])\n\tby smtp2.osuosl.org (Postfix) with ESMTPS id 1AD654083D;\n\tTue, 28 Apr 2026 17:45:51 +0000 (UTC)","from lf-lists.osuosl.org (localhost [127.0.0.1])\n\tby lists.linuxfoundation.org (Postfix) with ESMTP id E0FC2C04FB;\n\tTue, 28 Apr 2026 17:45:50 +0000 (UTC)","from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])\n by lists.linuxfoundation.org (Postfix) with ESMTP id 2A31CC04FA\n for ; Tue, 28 Apr 2026 17:45:49 +0000 (UTC)","from localhost (localhost [127.0.0.1])\n by smtp1.osuosl.org (Postfix) with ESMTP id 97277834F4\n for ; Tue, 28 Apr 2026 17:45:31 +0000 (UTC)","from smtp1.osuosl.org ([127.0.0.1])\n by localhost (smtp1.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP\n id lUI2Of4HP3rq for ;\n Tue, 28 Apr 2026 17:45:24 +0000 (UTC)","from us-smtp-delivery-124.mimecast.com\n (us-smtp-delivery-124.mimecast.com [170.10.129.124])\n by smtp1.osuosl.org (Postfix) with ESMTPS id 5E47883409\n for ; Tue, 28 Apr 2026 17:45:22 +0000 (UTC)","from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com\n (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by\n relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,\n cipher=TLS_AES_256_GCM_SHA384) id us-mta-597-yg7Zn2ZvMkyX-uJEGtKwDQ-1; Tue,\n 28 Apr 2026 13:45:14 -0400","from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com\n (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest\n SHA256)\n (No client certificate requested)\n by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS\n id DB1FA195609D\n for ; Tue, 28 Apr 2026 17:45:13 +0000 (UTC)","from localhost.localdomain.com (unknown [10.22.88.208])\n by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP\n id 063BD19560B7\n for ; Tue, 28 Apr 2026 17:45:12 +0000 (UTC)"],"X-Virus-Scanned":["amavis at osuosl.org","amavis at osuosl.org"],"X-Comment":"SPF check N/A for local connections - client-ip=140.211.9.56;\n helo=lists.linuxfoundation.org;\n envelope-from=ovs-dev-bounces@openvswitch.org; receiver= ","DKIM-Filter":["OpenDKIM Filter v2.11.0 smtp2.osuosl.org 1AD654083D","OpenDKIM Filter v2.11.0 smtp1.osuosl.org 5E47883409"],"Received-SPF":"Pass (mailfrom) identity=mailfrom; client-ip=170.10.129.124;\n helo=us-smtp-delivery-124.mimecast.com; envelope-from=mmichels@redhat.com;\n receiver=","DMARC-Filter":"OpenDMARC Filter v1.4.2 smtp1.osuosl.org 5E47883409","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n s=mimecast20190719; t=1777398321;\n h=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n to:to:cc:mime-version:mime-version:content-type:content-type:\n content-transfer-encoding:content-transfer-encoding:\n in-reply-to:in-reply-to:references:references;\n bh=4MlCRUuvywFWV0+R98WVT4LktWlovIqQPQO2kONVL0M=;\n b=KUcU0B7NU2RPhMDv4jMXYQiezbqKj8nRBOKPRB5eo5mja8kKR5Y3OgSutCsEz4Yz1uAFPx\n 34O+g+yulTkfOAIqsMP8lnLjzolq50O/ZWKjY2xngHu35yxd8rErWQbk4HH3v/e37RXn38\n 5nEQO83nwv38ZCd6sTh7l4E4N263Foo=","X-MC-Unique":"yg7Zn2ZvMkyX-uJEGtKwDQ-1","X-Mimecast-MFC-AGG-ID":"yg7Zn2ZvMkyX-uJEGtKwDQ_1777398314","To":"dev@openvswitch.org","Date":"Tue, 28 Apr 2026 13:45:03 -0400","Message-ID":"<20260428174509.145440-4-mmichels@redhat.com>","In-Reply-To":"<20260428174509.145440-1-mmichels@redhat.com>","References":"<20260428174509.145440-1-mmichels@redhat.com>","MIME-Version":"1.0","X-Scanned-By":"MIMEDefang 3.0 on 10.30.177.12","X-Mimecast-Spam-Score":"0","X-Mimecast-MFC-PROC-ID":"lU2VETdYzhliCu9pL0n-elvgwYsv9keE8jzjkHPRR48_1777398314","X-Mimecast-Originator":"redhat.com","Subject":"[ovs-dev] [PATCH ovn 3/5] northd: Split logical flow docs into\n ovn-logical-flows(7).","X-BeenThere":"ovs-dev@openvswitch.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","From":"Mark Michelson via dev ","Reply-To":"Mark Michelson ","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Errors-To":"ovs-dev-bounces@openvswitch.org","Sender":"\"dev\" "},"content":"Move the \"Logical Flow Table Structure\" and \"Drop sampling\" sections\nfrom ovn-northd.8.xml into a new ovn-logical-flows.7.xml manpage.\nThis separates the logical flow pipeline reference documentation from\nthe ovn-northd daemon description. A cross-reference stub remains in\novn-northd(8) pointing readers to the new manpage.\n\nAssisted-by: Claude Code (Claude Opus 4.6)\nSigned-off-by: Mark Michelson \n---\n northd/automake.mk | 3 +\n northd/ovn-logical-flows.7.xml | 6080 ++++++++++++++++++++++++++++++++\n northd/ovn-northd.8.xml | 6065 +------------------------------\n 3 files changed, 6088 insertions(+), 6060 deletions(-)\n create mode 100644 northd/ovn-logical-flows.7.xml","diff":"diff --git a/northd/automake.mk b/northd/automake.mk\nindex 8cd4fb3a1..47142a5b0 100644\n--- a/northd/automake.mk\n+++ b/northd/automake.mk\n@@ -71,3 +71,6 @@ northd_ovn_northd_LDADD = \\\n man_MANS += northd/ovn-northd.8\n EXTRA_DIST += northd/ovn-northd.8.xml\n CLEANFILES += northd/ovn-northd.8\n+man_MANS += northd/ovn-logical-flows.7\n+EXTRA_DIST += northd/ovn-logical-flows.7.xml\n+CLEANFILES += northd/ovn-logical-flows.7\ndiff --git a/northd/ovn-logical-flows.7.xml b/northd/ovn-logical-flows.7.xml\nnew file mode 100644\nindex 000000000..b8d353695\n--- /dev/null\n+++ b/northd/ovn-logical-flows.7.xml\n@@ -0,0 +1,6080 @@\n+\n+\n+

Name

\n+

ovn-logical-flows -- OVN logical flow table reference

\n+\n+

Description

\n+

\n+ This document describes the logical flow tables that\n+ ovn-northd(8) populates in the\n+ OVN_Southbound database. It covers both logical\n+ switch and logical router datapath pipelines, as well as\n+ drop sampling behavior.\n+

\n+\n+

Logical Flow Table Structure

\n+\n+

\n+ One of the main purposes of ovn-northd is to populate the\n+ Logical_Flow table in the OVN_Southbound\n+ database. This section describes how ovn-northd does this\n+ for switch and router logical datapaths.\n+

\n+\n+

Logical Switch Datapaths

\n+\n+

Ingress Table 0: Admission Control and Ingress Port Security check

\n+\n+

\n+ Ingress table 0 contains these logical flows:\n+

\n+\n+
    \n+
  • \n+ Priority 100 flows to drop packets with VLAN tags or multicast Ethernet\n+ source addresses.\n+
    • \n+\n+
  • \n+ For each disabled logical port, a priority 100 flow is added which\n+ matches on all packets and applies the action\n+ REGBIT_PORT_SEC_DROP\" = 1; next;\" so that the packets are\n+ dropped in the next stage.\n+
    • \n+\n+
  • \n+

    \n+ For each logical port that's defined as a target of routing protocol\n+ redirecting (via routing-protocol-redirect option set on\n+ Logical Router Port), a filter is set in place that disallows\n+ following traffic exiting this port:\n+

    \n+
      \n+
    • \n+ ARP replies\n+
      • \n+
    • \n+ IPv6 Neighbor Discovery - Router Advertisements\n+
      • \n+
    • \n+ IPv6 Neighbor Discovery - Neighbor Advertisements\n+
      • \n+
    \n+

    \n+ Since this port shares IP and MAC addresses with the Logical Router\n+ Port, we wan't to prevent duplicate replies and advertisements. This\n+ is achieved by a rule with priority 80 that sets\n+ REGBIT_PORT_SEC_DROP\" = 1; next;\".\n+

    \n+
    • \n+\n+
  • \n+ For each logical switch that has connected physical ports\n+ (localnet or l2gateway) and is also connected to a distributed router,\n+ filtering rules are added for ARP requests coming from localnet or\n+ l2gateway ports, allowed for processing on gateway chassis.\n+ The REGBIT_EXT_ARP register is set for all ARP requests\n+ originating from physical ports with priority 75 flow.\n+
    • \n+\n+
  • \n+ For each (enabled) vtep logical port, a priority 70 flow is added which\n+ matches on all packets and applies the action\n+ next(pipeline=ingress, table=S_SWITCH_IN_L3_LKUP) = 1;\n+ to skip most stages of ingress pipeline and go directly to ingress L2\n+ lookup table to determine the output port. Packets from VTEP (RAMP)\n+ switch should not be subjected to any ACL checks. Egress pipeline will\n+ do the ACL checks.\n+
    • \n+\n+
  • \n+ For each enabled logical port configured with qdisc queue id in the\n+ column of , a priority 70 flow is added which\n+ matches on all packets and applies the action\n+ set_queue(id);\n+ REGBIT_PORT_SEC_DROP\" = check_in_port_sec(); next;\".\n+
    • \n+\n+
  • \n+ A priority 1 flow is added which matches on all packets for all the\n+ logical ports and applies the action\n+ REGBIT_PORT_SEC_DROP\" = check_in_port_sec(); next; to\n+ evaluate the port security. The action check_in_port_sec\n+ applies the port security rules defined in the\n+ column of table.\n+
    • \n+
\n+\n+

Ingress Table 1: Ingress Port Security - Apply

\n+\n+

\n+ For each logical switch port P of type router connected to a\n+ gw router a priority-120 flow that matches 'recirculated' icmp{4,6} error\n+ 'packet too big' and eth.src == D &&\n+ outport == P && flags.tunnel_rx == 1 where\n+ D is the peer logical router port RP mac address,\n+ swaps inport and outport and applies the action next.\n+

\n+\n+

\n+ For each logical switch port P of type router connected to a\n+ distributed router a priority-120 flow that matches 'recirculated'\n+ icmp{4,6} error 'packet too big' and eth.dst == D\n+ && flags.tunnel_rx == 1 where D is the peer\n+ logical router port RP mac address, swaps inport and outport\n+ and applies the action next(pipeline=S_SWITCH_IN_L2_LKUP).\n+

\n+\n+

\n+ For each logical switch port P a priority-110 flow that\n+ matches 'recirculated' icmp{4,6} error 'packet too big' and \n+ eth.src == D && outport == P &&\n+ !is_chassis_resident(\"P\") && flags.tunnel_rx == 1\n+ where D is the logical switch port mac address,\n+ swaps inport and outport and applies the action next.\n+

\n+\n+

\n+ This table adds a priority-105 flow that matches 'recirculated' icmp{4,6}\n+ error 'packet too big' to drop the packet.\n+

\n+\n+

\n+ This table drops the packets if the port security check failed\n+ in the previous stage i.e the register bit\n+ REGBIT_PORT_SEC_DROP is set to 1.\n+

\n+\n+

\n+ Ingress table 1 contains these logical flows:\n+

\n+\n+
    \n+
  • \n+ A priority-50 fallback flow that drops the packet if the register\n+ bit REGBIT_PORT_SEC_DROP is set to 1.\n+
    • \n+\n+
  • \n+ One priority-0 fallback flow that matches all packets and advances to\n+ the next table.\n+
    • \n+\n+
  • \n+ Priority 75: Allows REGBIT_EXT_ARP packets only on gateway\n+ chassis and chassis with distributed NAT entries.\n+ Priority 70: Drops REGBIT_EXT_ARP packets on non-gateway\n+ chassis (complements the priority 75 flow).\n+
    • \n+
\n+\n+

Ingress Table 2: Mirror

\n+\n+

\n+ Overlay remote mirror table contains the following\n+ logical flows:\n+

\n+\n+
    \n+
  • \n+ For each logical switch port with an attached mirror, a logical flow\n+ with a priority of 100 is added. This flow matches all incoming packets\n+ to the attached port, clones them, and forwards the cloned packets to\n+ the mirror target port.\n+
    • \n+\n+
  • \n+ A priority 0 flow is added which matches on all packets and applies\n+ the action next;.\n+
    • \n+\n+
  • \n+ A logical flow added for each Mirror Rule in Mirror table attached\n+ to logical switch ports, matches all incoming packets that match\n+ rules and clones the packet and sends cloned packet to mirror\n+ target port.\n+
    • \n+
\n+\n+

Ingress Table 3: Lookup MAC address learning table

\n+\n+

\n+ This table looks up the MAC learning table of the logical switch\n+ datapath to check if the port-mac pair is present\n+ or not. MAC is learnt for logical switch VIF ports whose\n+ port security is disabled and 'unknown' address setn as well as\n+ for localnet ports with option localnet_learn_fdb. A localnet\n+ port entry does not overwrite a VIF port entry.\n+ Logical switch ports with type switch have implicit\n+ 'unknown' addresses and so they are also eligible for MAC learning.\n+

\n+\n+
    \n+
  • \n+

    \n+ For each such VIF logical port p whose port security\n+ is disabled and 'unknown' address set following flow\n+ is added.\n+

    \n+\n+
      \n+
    • \n+ Priority 100 flow with the match\n+ inport == p and action\n+ reg0[11] = lookup_fdb(inport, eth.src); next;\n+
      • \n+
    \n+
    • \n+\n+
  • \n+

    \n+ For each such localnet logical port p following flow\n+ is added.\n+

    \n+\n+
      \n+
    • \n+ Priority 100 flow with the match\n+ inport == p and action\n+ flags.localnet = 1;\n+ reg0[11] = lookup_fdb(inport, eth.src); next;\n+
      • \n+
    \n+
    • \n+\n+
  • \n+ One priority-0 fallback flow that matches all packets and advances to\n+ the next table.\n+
    • \n+
\n+\n+

Ingress Table 4: Learn MAC of 'unknown' ports.

\n+\n+

\n+ This table learns the MAC addresses seen on the VIF or 'switch' logical\n+ ports whose port security is disabled and 'unknown' address set (note:\n+ 'switch' ports have implicit 'unknown' addresses) as well\n+ as on localnet ports with localnet_learn_fdb option set\n+ if the lookup_fdb action returned false in the\n+ previous table. For localnet ports (with flags.localnet = 1),\n+ lookup_fdb returns true if (port, mac) is found or if a mac\n+ is found for a port of type vif.\n+

\n+\n+
    \n+
  • \n+

    \n+ For each such VIF logical port p whose port security is\n+ disabled and 'unknown' address set and localnet port following flow\n+ is added.\n+

    \n+\n+
      \n+
    • \n+ Priority 100 flow with the match\n+ inport == p && reg0[11] == 0 and\n+ action put_fdb(inport, eth.src); next; which stores\n+ the port-mac in the mac learning table of the\n+ logical switch datapath and advances the packet to the next table.\n+
      • \n+
    \n+
    • \n+\n+
  • \n+ One priority-0 fallback flow that matches all packets and advances to\n+ the next table.\n+
    • \n+
\n+\n+

Ingress Table 5: from-lport Pre-ACLs

\n+\n+

\n+ This table prepares flows for possible stateful ACL processing in\n+ ingress table ACLs. It contains a priority-0 flow that\n+ simply moves traffic to the next table. If stateful ACLs are used in the\n+ logical datapath, a priority-100 flow is added that sets a hint\n+ (with reg0[0] = 1; next;) for table\n+ Pre-stateful to send IP packets to the connection tracker\n+ before eventually advancing to ingress table ACLs. If\n+ special ports such as route ports or localnet ports can't use ct(), a\n+ priority-110 flow is added to skip over stateful ACLs. This\n+ priority-110 flow is not addd for router ports if the option\n+ enable_router_port_acl is set to true in\n+ column of\n+ . Multicast, IPv6\n+ Neighbor Discovery and MLD traffic also skips stateful ACLs. For\n+ \"allow-stateless\" ACLs, a flow is added to bypass setting the hint for\n+ connection tracker processing when there are stateful ACLs or LB rules;\n+ REGBIT_ACL_STATELESS is set for traffic matching stateless\n+ ACL flows.\n+

\n+\n+

\n+ This table also has a priority-110 flow with the match\n+ eth.dst == E for all logical switch\n+ datapaths to move traffic to the next table. Where E\n+ is the service monitor mac defined in the\n+ column of table.\n+

\n+\n+

Ingress Table 6: Pre-LB

\n+\n+

\n+ This table prepares flows for possible stateful load balancing processing\n+ in ingress table LB and Stateful. It contains\n+ a priority-0 flow that simply moves traffic to the next table. Moreover\n+ it contains two priority-110 flows to move multicast, IPv6 Neighbor\n+ Discovery and MLD traffic to the next table. It also contains two\n+ priority-110 flows to move stateless traffic, i.e traffic for which\n+ REGBIT_ACL_STATELESS is set, to the next table. If load\n+ balancing rules with virtual IP addresses (and ports) are configured in\n+ OVN_Northbound database for a logical switch datapath, a\n+ priority-100 flow is added with the match ip to match on IP\n+ packets and sets the action reg0[2] = 1; next; to act as a\n+ hint for table Pre-stateful to send IP packets to the\n+ connection tracker for packet de-fragmentation (and to possibly do DNAT\n+ for already established load balanced traffic) before eventually\n+ advancing to ingress table Stateful.\n+ If controller_event has been enabled and load balancing rules with\n+ empty backends have been added in OVN_Northbound, a 130 flow\n+ is added to trigger ovn-controller events whenever the chassis receives a\n+ packet for that particular VIP. If event-elb meter has been\n+ previously created, it will be associated to the empty_lb logical flow\n+

\n+\n+

\n+ Prior to OVN 20.09 we were setting the\n+ reg0[0] = 1 only if the IP destination matches the load\n+ balancer VIP. However this had few issues cases where a logical switch\n+ doesn't have any ACLs with allow-related action.\n+ To understand the issue lets a take a TCP load balancer -\n+ 10.0.0.10:80=10.0.0.3:80. If a logical port - p1 with\n+ IP - 10.0.0.5 opens a TCP connection with the VIP - 10.0.0.10, then the\n+ packet in the ingress pipeline of 'p1' is sent to the p1's conntrack zone\n+ id and the packet is load balanced to the backend - 10.0.0.3. For the\n+ reply packet from the backend lport, it is not sent to the conntrack of\n+ backend lport's zone id. This is fine as long as the packet is valid.\n+ Suppose the backend lport sends an invalid TCP packet (like incorrect\n+ sequence number), the packet gets delivered to the lport 'p1' without\n+ unDNATing the packet to the VIP - 10.0.0.10. And this causes the\n+ connection to be reset by the lport p1's VIF.\n+

\n+\n+

\n+ We can't fix this issue by adding a logical flow to drop ct.inv packets\n+ in the egress pipeline since it will drop all other connections not\n+ destined to the load balancers. To fix this issue, we send all the\n+ packets to the conntrack in the ingress pipeline if a load balancer is\n+ configured. We can now add a lflow to drop ct.inv packets.\n+

\n+\n+

\n+ This table also has priority-120 flows that punt all IGMP/MLD packets to\n+ ovn-controller if the switch is an interconnect switch\n+ with multicast snooping enabled.\n+

\n+\n+

\n+ This table also has a priority-110 flow with the match\n+ eth.dst == E for all logical switch\n+ datapaths to move traffic to the next table. Where E\n+ is the service monitor mac defined in the\n+ column of table.\n+

\n+\n+

\n+ This table also has a priority-110 flow with the match\n+ inport == I for all logical switch\n+ datapaths to move traffic to the next table. Where I\n+ is the peer of a logical router port. This flow is added to\n+ skip the connection tracking of packets which enter from\n+ logical router datapath to logical switch datapath.\n+

\n+\n+

Ingress Table 7: Pre-stateful

\n+\n+

\n+ This table prepares flows for all possible stateful processing\n+ in next tables. It contains a priority-0 flow that simply moves\n+ traffic to the next table.\n+

\n+
    \n+
  • \n+ Priority-120 flows that send the packets to connection tracker using\n+ ct_lb_mark; as the action so that the already established\n+ traffic destined to the load balancer VIP gets DNATted. These flows\n+ match each VIPs IP and port. For IPv4 traffic the flows also load the\n+ original destination IP and transport port in registers\n+ reg1 and reg2. For IPv6 traffic the flows\n+ also load the original destination IP and transport port in\n+ registers xxreg1 and reg2.\n+
    • \n+\n+
  • \n+ A priority-110 flow sends the packets that don't match the above flows\n+ to connection tracker based on a hint provided by the previous tables\n+ (with a match for reg0[2] == 1) by using the\n+ ct_lb_mark; action.\n+
    • \n+\n+
  • \n+ A priority-105 added enabled when enable-stateless-acl-with-lb and\n+ send all packet directed to VIP that don't match the above flows to\n+ connection tracker.\n+
    • \n+\n+
  • \n+ A priority-100 flow sends the packets to connection tracker based\n+ on a hint provided by the previous tables\n+ (with a match for reg0[0] == 1) by using the\n+ ct_next; action.\n+
    • \n+
\n+\n+

Ingress Table 8: from-lport ACL hints

\n+\n+

\n+ This table consists of logical flows that set hints\n+ (reg0 bits) to be used in the next stage, in the ACL\n+ processing table, if stateful ACLs or load balancers are configured.\n+ Multiple hints can be set for the same packet.\n+ The possible hints are:\n+

\n+
    \n+
  • \n+ reg0[7]: the packet might match an\n+ allow-related ACL and might have to commit the\n+ connection to conntrack.\n+
    • \n+
  • \n+ reg0[8]: the packet might match an\n+ allow-related ACL but there will be no need to commit\n+ the connection to conntrack because it already exists.\n+
    • \n+
  • \n+ reg0[9]: the packet might match a\n+ drop/reject.\n+
    • \n+
  • \n+ reg0[10]: the packet might match a\n+ drop/reject ACL but the connection was previously\n+ allowed so it might have to be committed again with\n+ ct_label=1/1.\n+
    • \n+
\n+\n+

\n+ The table contains the following flows:\n+

\n+
    \n+
  • \n+ A priority-65535 flow to advance to the next table if the logical\n+ switch has no ACLs configured, otherwise a\n+ priority-0 flow to advance to the next table.\n+
    • \n+
\n+\n+
    \n+
  • \n+ A priority-7 flow that matches on packets that initiate a new session.\n+ This flow sets reg0[7] and reg0[9] and\n+ then advances to the next table.\n+
    • \n+
  • \n+ A priority-6 flow that matches on packets that are in the request\n+ direction of an already existing session that has been marked\n+ as blocked. This flow sets reg0[7] and\n+ reg0[9] and then advances to the next table.\n+
    • \n+
  • \n+ A priority-5 flow that matches untracked packets. This flow sets\n+ reg0[8] and reg0[9] and then advances to\n+ the next table.\n+
    • \n+
  • \n+ A priority-4 flow that matches on packets that are in the request\n+ direction of an already existing session that has not been marked\n+ as blocked. This flow sets reg0[8] and\n+ reg0[10] and then advances to the next table.\n+
    • \n+
  • \n+ A priority-3 flow that matches on packets that are in not part of\n+ established sessions. This flow sets reg0[9] and then\n+ advances to the next table.\n+
    • \n+
  • \n+ A priority-2 flow that matches on packets that are part of an\n+ established session that has been marked as blocked.\n+ This flow sets reg0[9] and then advances to the next\n+ table.\n+
    • \n+
  • \n+ A priority-1 flow that matches on packets that are part of an\n+ established session that has not been marked as blocked.\n+ This flow sets reg0[10] and then advances to the next\n+ table.\n+
    • \n+
\n+\n+

Ingress table 9: from-lport ACL evaluation before LB

\n+\n+

\n+ Logical flows in this table closely reproduce those in the\n+ ACL table in the OVN_Northbound database\n+ for the from-lport direction without the option\n+ apply-after-lb set or set to false.\n+ The priority values from the ACL table have a\n+ limited range and have 1000 added to them to leave room for OVN default\n+ flows at both higher and lower priorities.\n+

\n+
    \n+
  • \n+ This table is responsible for evaluating ACLs, and setting a register\n+ bit to indicate whether the ACL decided to allow, drop, or reject the\n+ traffic. The allow bit is reg8[16]. The drop bit is\n+ reg8[17]. All flows in this table will advance the packet\n+ to the next table, where the bits from before are evaluated to\n+ determine what to do with the packet. Any flows in this table that\n+ intend for the packet to pass will set reg8[16] to 1,\n+ even if an ACL with an allow-type action was not matched. This lets the\n+ next table know to allow the traffic to pass. These bits will be\n+ referred to as the \"allow\", \"drop\", and \"reject\" bits in the upcoming\n+ paragraphs.\n+
    • \n+
  • \n+ If the tier column has been configured on the ACL, then\n+ OVN will also match the current tier counter against the configured\n+ ACL tier. OVN keeps count of the current tier in\n+ reg8[30..31].\n+
    • \n+
  • \n+ allow ACLs translate into logical flows that set the allow\n+ bit to 1 and advance the packet to the next table. If there are any\n+ stateful ACLs on this datapath, then allow ACLs set the\n+ allow bit to one and in addition perform ct_commit; (which\n+ acts as a hint for future tables to commit the connection to\n+ conntrack). In case the ACL has a label then\n+ reg3 is loaded with the label value and\n+ reg0[13] bit is set to 1 (which acts as a hint for the\n+ next tables to commit the label to conntrack).\n+
    • \n+
  • \n+ allow-related ACLs translate into logical flows that set\n+ the allow bit and additionally have ct_commit { ct_label=0/1; };\n+ next; actions for new connections and reg0[1] = 1;\n+ next; for existing connections. In case the ACL\n+ has a label then reg3 is loaded with the label value and\n+ reg0[13] bit is set to 1 (which acts as a hint for the\n+ next tables to commit the label to conntrack).\n+
    • \n+
  • \n+ For allow and allow-related ACL, an\n+ additonal set of registers get set in case the ACL has the column\n+ network_function_group set to the id of one\n+ of the entities in Network_Function_Group table. The\n+ id is an internally generated unique identifier for a\n+ Network_Function_Group entity. The flow sets\n+ reg8[21] = 1 (to indicate need for packet redirection),\n+ reg8[22] = 1 (to indicate this is a request packet) and\n+ reg0[22..29] = id. These registers are later\n+ used in the Network Function table.\n+
    • \n+\n+
  • \n+ allow-stateless ACLs translate into logical flows that set\n+ the allow bit and advance to the next table.\n+
    • \n+
  • \n+ reject ACLs translate into logical flows with that set the\n+ reject bit and advance to the next table.\n+
    • \n+
  • \n+ pass ACLs translate into logical flows that do not set the\n+ allow, drop, or reject bit and advance to the next table.\n+
    • \n+
  • \n+ Other ACLs set the drop bit and advance to the next table for new or\n+ untracked connections. For known connections, they set the drop bit,\n+ as well as running the ct_commit { ct_label=1/1; };\n+ action. Setting ct_label marks a connection as one that\n+ was previously allowed, but should no longer be allowed due to a policy\n+ change.\n+
    • \n+
\n+\n+

\n+ This table contains a priority-65535 flow to set the allow bit and\n+ advance to the next table if the logical switch has no\n+ ACLs configured, otherwise a priority-0 flow to advance to the next\n+ table is added. This flow does not set the allow bit, so that the next\n+ table can decide whether to allow or drop the packet based on the value\n+ of the column of the table.\n+

\n+\n+

\n+ A priority-65532 flow is added that sets the allow bit for\n+ IPv6 Neighbor solicitation, Neighbor discover, Router solicitation,\n+ Router advertisement and MLD packets regardless of other ACLs defined.\n+

\n+\n+

\n+ If the logical datapath has a stateful ACL or a load balancer with VIP\n+ configured, the following flows will also be added:\n+

\n+\n+
    \n+
  • \n+ If column of is false or not set, a priority-1\n+ flow that sets the hint to commit IP traffic that is not part of\n+ established sessions to the connection tracker (with action\n+ reg0[1] = 1; next;). This is needed for\n+ the default allow policy because, while the initiator's direction\n+ may not have any stateful rules, the server's may and then\n+ its return traffic would not be known and marked as invalid.\n+
    • \n+\n+
  • \n+ A priority-1 flow that sets the allow bit and sets the hint to commit\n+ IP traffic to the connection tracker (with action reg0[1] = 1;\n+ next;). This is needed for the default allow policy because,\n+ while the initiator's direction may not have any stateful rules, the\n+ server's may and then its return traffic would not be known and marked\n+ as invalid.\n+
    • \n+\n+
  • \n+ A priority-65532 flow that sets the allow bit for any traffic in the\n+ reply direction for a connection that has been committed to the\n+ connection tracker (i.e., established flows), as long as\n+ the committed flow does not have ct_mark.blocked set.\n+ We only handle traffic in the reply direction here because\n+ we want all packets going in the request direction to still\n+ go through the flows that implement the currently defined\n+ policy based on ACLs. If a connection is no longer allowed by\n+ policy, ct_mark.blocked will get set and packets in the\n+ reply direction will no longer be allowed, either. This flow also\n+ clears the register bits reg0[9] and\n+ reg0[10] and sets register bit reg0[17].\n+ If ACL logging and logging of related packets is enabled, then a\n+ companion priority-65533 flow will be installed that\n+ accomplishes the same thing but also logs the traffic.\n+
    • \n+\n+
  • \n+ The priority-65532 flows that allow response and related traffic, also\n+ set reg8[21] = ct_label.nf, which gets checked in\n+ the Network Function table.\n+
    • \n+\n+
  • \n+ A priority-65532 flow that sets the allow bit for any traffic that is\n+ considered related to a committed flow in the connection tracker (e.g.,\n+ an ICMP Port Unreachable from a non-listening UDP port), as long\n+ as the committed flow does not have ct_mark.blocked set.\n+ This flow also applies NAT to the related traffic so that ICMP headers\n+ and the inner packet have correct addresses.\n+ If ACL logging and logging of related packets is enabled, then a\n+ companion priority-65533 flow will be installed that accomplishes the\n+ same thing but also logs the traffic.\n+
    • \n+\n+
  • \n+ A priority-65532 flow that sets the drop bit for all traffic marked by\n+ the connection tracker as invalid.\n+
    • \n+\n+
  • \n+ A priority-65532 flow that sets the drop bit for all traffic in the\n+ reply direction with ct_mark.blocked set meaning that the\n+ connection should no longer be allowed due to a policy change. Packets\n+ in the request direction are skipped here to let a newly created\n+ ACL re-allow this connection.\n+
    • \n+
\n+\n+

\n+ If the logical datapath has any ACL or a load balancer with VIP\n+ configured, the following flow will also be added:\n+

\n+\n+
    \n+
  • \n+ A priority 34000 logical flow is added for each logical switch datapath\n+ with the match eth.dst = E to allow the service\n+ monitor reply packet destined to ovn-controller\n+ that sets the allow bit, where E is the\n+ service monitor mac defined in the\n+ column of table.\n+
    • \n+
\n+\n+

Ingress Table 10: from-lport ACL sampling

\n+\n+

\n+ Logical flows in this table sample traffic matched by\n+ from-lport ACLs with sampling enabled.\n+

\n+\n+
    \n+
  • \n+ If no ACLs have sampling enabled, then a priority 0 flow is installed\n+ that matches everything and advances to the next table.\n+
    • \n+\n+
  • \n+ For each ACL with sample_new configured a priority 1100 flow is\n+ installed that matches on the saved observation_point_id value.\n+ This flow generates a sample() action and then advances\n+ the packet to the next table.\n+
    • \n+\n+
  • \n+ For each ACL with sample_est configured a priority 1200 flow is\n+ installed that matches on the saved observation_point_id value\n+ for established traffic in the original direction. This flow\n+ generates a sample() action and then advances\n+ the packet to the next table.\n+
    • \n+\n+
  • \n+ For each ACL with sample_est configured a priority 1200 flow is\n+ installed that matches on the saved observation_point_id\n+ value for established traffic in the reply direction. This flow\n+ generates a sample() action and then advances\n+ the packet to the next table. Note: this flow is installed in the\n+ opposite pipeline (in the ingress pipeline for ACLs applied in the\n+ egress direction and in the egress pipeline for ACLs applied in the\n+ ingress direction).\n+
    • \n+
\n+\n+

Ingress Table 11: from-lport ACL action

\n+\n+

\n+ Logical flows in this table decide how to proceed based on the values of\n+ the allow, drop, and reject bits that may have been set in the previous\n+ table.\n+

\n+\n+
    \n+
  • \n+ If no ACLs are configured, then a priority 0 flow is installed that\n+ matches everything and advances to the next table.\n+
    • \n+\n+
  • \n+ A priority 1000 flow is installed that will advance the packet to the\n+ next table if the allow bit is set.\n+
    • \n+\n+
  • \n+ A priority 1000 flow is installed that will run the drop;\n+ action if the drop bit is set.\n+
    • \n+\n+
  • \n+ A priority 1000 flow is installed that will run the tcp_reset\n+ { output <-> inport; next(pipeline=egress,table=5);}\n+ action for TCP connections,icmp4/icmp6 action\n+ for UDP connections, and sctp_abort {output <-%gt; inport;\n+ next(pipeline=egress,table=5);} action for SCTP associations.\n+
    • \n+\n+
  • \n+ If any ACLs have tiers configured on them, then three priority 500\n+ flows are installed. If the current tier counter is 0, 1, or 2, then\n+ the current tier counter is incremented by one and the packet is sent\n+ back to the previous table for re-evaluation.\n+
    • \n+
\n+\n+

Ingress Table 12: from-lport QoS

\n+\n+

\n+ Logical flows in this table closely reproduce those in the\n+ QoS table with the action or\n+ bandwidth column set in the\n+ OVN_Northbound database for the\n+ from-lport direction.\n+

\n+\n+
    \n+
  • \n+ For every qos_rules entry in a logical switch with DSCP marking,\n+ packet marking or metering enabled a flow will be added at the priority\n+ mentioned in the QoS table.\n+
    • \n+\n+
  • \n+ One priority-0 fallback flow that matches all packets and advances to\n+ the next table.\n+
    • \n+
\n+\n+

Ingress Table 13: Connection Tracking Field Extraction

\n+\n+

\n+ This table extracts connection tracking fields for new connections\n+ to be used by subsequent load balancing stages.\n+

\n+\n+
    \n+
  • \n+ A priority-100 flow matches ct.new && ip and\n+ extracts connection tracking protocol and destination port information\n+ into registers reg1[16..23] (protocol) and\n+ reg1[0..15] (destination port) using the actions\n+ reg1[16..23] = ct_proto(); reg1[0..15] = ct_tp_dst(); next;.\n+
    • \n+\n+
  • \n+ A priority-0 flow matches all packets and advances to the next table.\n+
    • \n+
\n+\n+

Ingress Table 14: Load balancing affinity check

\n+\n+

\n+ Load balancing affinity check table contains the following\n+ logical flows:\n+

\n+\n+
    \n+
  • \n+ For all the configured load balancing rules for a switch in\n+ OVN_Northbound database where a positive affinity timeout\n+ is specified in options column, that includes a L4 port\n+ PORT of protocol P and IP address VIP,\n+ a priority-100 flow is added. For IPv4 VIPs, the flow\n+ matches ct.new && ip && ip4.dst == VIP\n+ && reg1[16..23] == PROTO_NUM &&\n+ reg1[0..15] == PORT. For IPv6\n+ VIPs, the flow matches ct.new && ip &&\n+ ip6.dst == VIP && reg1[16..23] ==\n+ PROTO_NUM && reg1[0..15] == PORT.\n+ The flow's action is reg9[6] = chk_lb_aff(); next;.\n+
    • \n+\n+
  • \n+ A priority 0 flow is added which matches on all packets and applies\n+ the action next;.\n+
    • \n+
\n+\n+

Ingress Table 15: LB

\n+\n+
    \n+
  • \n+ For all the configured load balancing rules for a switch in\n+ OVN_Northbound database where a positive affinity timeout\n+ is specified in options column, that includes a L4 port\n+ PORT of protocol P and IP address VIP,\n+ a priority-150 flow is added. For IPv4 VIPs, the flow\n+ matches reg9[6] == 1 && ct.new && ip &&\n+ ip4.dst == VIP && P.dst == PORT\n+ . For IPv6 VIPs, the flow matches\n+ reg9[6] == 1 && ct.new && ip &&\n+ ip6.dst == VIP && P &&\n+ P.dst == PORT.\n+ The flow's action is ct_lb_mark(args), where\n+ args contains comma separated IP addresses (and optional\n+ port numbers) to load balance to. The address family of the IP\n+ addresses of args is the same as the address family\n+ of VIP.\n+
    • \n+\n+
  • \n+ For all the configured load balancing rules for a switch in\n+ OVN_Northbound database that includes a L4 port\n+ PORT of protocol P and IP address\n+ VIP, a priority-120 flow is added. For IPv4 VIPs\n+ , the flow matches ct.new && ip &&\n+ ip4.dst == VIP && reg1[16..23] ==\n+ PROTO_NUM && reg1[0..15] == PORT.\n+ For IPv6 VIPs,\n+ the flow matches ct.new && ip && ip6.dst == \n+ VIP && reg1[16..23] == PROTO_NUM &&\n+ reg1[0..15] == PORT. The flow's action is\n+ ct_lb_mark(args)\n+ , where args contains comma separated IP addresses\n+ (and optional port numbers) to load balance to. The address family of\n+ the IP addresses of args is the same as the address family\n+ of VIP. If health check is enabled, then args\n+ will only contain those endpoints whose service monitor status entry\n+ in OVN_Southbound db is either online or\n+ empty. For IPv4 traffic the flow also loads the original destination\n+ IP and transport port in registers reg1 and\n+ reg2. For IPv6 traffic the flow also loads the original\n+ destination IP and transport port in registers xxreg1 and\n+ reg2.\n+ The above flow is created even if the load balancer is attached to a\n+ logical router connected to the current logical switch and\n+ the install_ls_lb_from_router variable in\n+ is set to true.\n+
    • \n+
  • \n+ For all the configured load balancing rules for a switch in\n+ OVN_Northbound database that includes just an IP address\n+ VIP to match on, OVN adds a priority-110 flow. For IPv4\n+ VIPs, the flow matches ct.new && ip &&\n+ ip4.dst == VIP. For IPv6 VIPs,\n+ the flow matches ct.new && ip && ip6.dst == \n+ VIP. The action on this flow is \n+ ct_lb_mark(args), where args contains comma\n+ separated IP addresses of the same address family as VIP.\n+ For IPv4 traffic the flow also loads the original destination\n+ IP and transport port in registers reg1 and\n+ reg2. For IPv6 traffic the flow also loads the original\n+ destination IP and transport port in registers xxreg1 and\n+ reg2.\n+ The above flow is created even if the load balancer is attached to a\n+ logical router connected to the current logical switch and\n+ the install_ls_lb_from_router variable in\n+ is set to true.\n+
    • \n+\n+
  • \n+ If the load balancer is created with --reject option and\n+ it has no active backends, a TCP reset segment (for tcp) or an ICMP\n+ port unreachable packet (for all other kind of traffic) will be sent\n+ whenever an incoming packet is received for this load-balancer.\n+ Please note using --reject option will disable\n+ empty_lb SB controller event for this load balancer.\n+
    • \n+
\n+\n+

Ingress Table 16: Load balancing affinity learn

\n+\n+

\n+ Load balancing affinity learn table contains the following\n+ logical flows:\n+

\n+\n+
    \n+
  • \n+ For all the configured load balancing rules for a switch in\n+ OVN_Northbound database where a positive affinity timeout\n+ T is specified in options column, that includes\n+ a L4 port PORT of protocol P and IP address\n+ VIP, a priority-100 flow is added. For IPv4 VIPs,\n+ the flow matches reg9[6] == 0 && ct.new && ip\n+ && ip4.dst == VIP && P.dst ==\n+ PORT. For IPv6 VIPs, the flow matches\n+ ct.new && ip && ip6.dst == VIP\n+ && P && P.dst == PORT\n+ . The flow's action is commit_lb_aff(vip =\n+ VIP:PORT, backend = backend ip:\n+ backend port, proto = P, timeout = T);\n+ .\n+
    • \n+\n+
  • \n+ A priority 0 flow is added which matches on all packets and applies\n+ the action next;.\n+
    • \n+
\n+\n+

Ingress Table 17: Pre-Hairpin

\n+
    \n+
  • \n+ If the logical switch has load balancer(s) configured, then a\n+ priority-100 flow is added with the match\n+ ip && ct.trk to check if the\n+ packet needs to be hairpinned (if after load balancing the destination\n+ IP matches the source IP) or not by executing the actions\n+ reg0[6] = chk_lb_hairpin(); and\n+ reg0[12] = chk_lb_hairpin_reply(); and advances the packet\n+ to the next table.\n+
    • \n+\n+
  • \n+ A priority-0 flow that simply moves traffic to the next table.\n+
    • \n+
\n+\n+

Ingress Table 18: Nat-Hairpin

\n+
    \n+
  • \n+ If the logical switch has load balancer(s) configured, then a\n+ priority-100 flow is added with the match\n+ ip && ct.new && ct.trk &&\n+ reg0[6] == 1 which hairpins the traffic by\n+ NATting source IP to the load balancer VIP by executing the action\n+ ct_snat_to_vip and advances the packet to the next table.\n+
    • \n+\n+
  • \n+ If the logical switch has load balancer(s) configured, then a\n+ priority-100 flow is added with the match\n+ ip && ct.est && ct.trk &&\n+ reg0[6] == 1 which hairpins the traffic by\n+ NATting source IP to the load balancer VIP by executing the action\n+ ct_snat and advances the packet to the next table.\n+
    • \n+\n+
  • \n+ If the logical switch has load balancer(s) configured, then a\n+ priority-90 flow is added with the match\n+ ip && reg0[12] == 1 which matches on the replies\n+ of hairpinned traffic (i.e., destination IP is VIP,\n+ source IP is the backend IP and source L4 port is backend port for L4\n+ load balancers) and executes ct_snat and advances the\n+ packet to the next table.\n+
    • \n+\n+
  • \n+ A priority-0 flow that simply moves traffic to the next table.\n+
    • \n+
\n+\n+

Ingress Table 19: Hairpin

\n+
    \n+
  • \n+

    \n+ If logical switch has attached logical switch port of vtep\n+ type, then for each distributed gateway router port RP\n+ attached to this logical switch and has chassis redirect port\n+ cr-RP, a priority-2000 flow is added with the match\n+ 

    \n+reg0[14] == 1 && is_chassis_resident(cr-RP)\n+
    \n+ and action next;.\n+

    \n+\n+

    \n+ reg0[14] register bit is set in the ingress L2 port\n+ security check table for traffic received from HW VTEP (ramp) ports.\n+

    \n+
    • \n+\n+
  • \n+ If logical switch has attached logical switch port of vtep\n+ type, then a priority-1000 flow that matches on\n+ reg0[14] register bit for the traffic received from HW\n+ VTEP (ramp) ports. This traffic is passed to ingress table\n+ ls_in_l2_lkup.\n+
    • \n+
  • \n+ A priority-1 flow that hairpins traffic matched by non-default\n+ flows in the Pre-Hairpin table. Hairpinning is done at L2, Ethernet\n+ addresses are swapped and the packets are looped back on the input\n+ port.\n+
    • \n+
  • \n+ A priority-0 flow that simply moves traffic to the next table.\n+
    • \n+
\n+\n+

Ingress table 20: from-lport ACL evaluation after LB

\n+\n+

\n+ Logical flows in this table closely reproduce those in the\n+ ACL eval table in the OVN_Northbound database\n+ for the from-lport direction with the option\n+ apply-after-lb set to true.\n+ The priority values from the ACL table have a\n+ limited range and have 1000 added to them to leave room for OVN default\n+ flows at both higher and lower priorities. The flows in this table\n+ indicate the ACL verdict by setting reg8[16] for\n+ allow-type ACLs, reg8[17] for drop\n+ ACLs, and reg8[17] for reject ACLs, and then\n+ advancing the packet to the next table. These will be reffered to as the\n+ allow bit, drop bit, and reject bit throughout the documentation for this\n+ table and the next one.\n+

\n+\n+

\n+ Like with ACLs that are evaluated before load balancers, if the ACL is\n+ configured with a tier value, then the current tier counter, supplied\n+ in reg8[30..31] is matched against the ACL's configured tier in addition\n+ to the ACL's match.\n+

\n+\n+
    \n+
  • \n+ allow apply-after-lb ACLs translate into logical flows\n+ that set the allow bit. If there are any stateful ACLs\n+ (including both before-lb and after-lb ACLs)\n+ on this datapath, then allow ACLs also run\n+ ct_commit; next; (which acts as a hint for an upcoming\n+ table to commit the connection to conntrack). In case the\n+ ACL has a label then reg3 is loaded with the\n+ label value and reg0[13] bit is set to 1 (which acts as a\n+ hint for the next tables to commit the label to conntrack).\n+
    • \n+
  • \n+ allow-related apply-after-lb ACLs translate into logical\n+ flows that set the allow bit and run the\n+ ct_commit {ct_label=0/1; }; next; actions for new\n+ connections and reg0[1] = 1; next; for existing\n+ connections. In case the ACL has a label then\n+ reg3 is loaded with the label value and\n+ reg0[13] bit is set to 1 (which acts as a hint for the\n+ next tables to commit the label to conntrack).\n+
    • \n+
  • \n+ allow-stateless apply-after-lb ACLs translate into logical\n+ flows that set the allow bit and advance to the next table.\n+
    • \n+
  • \n+ reject apply-after-lb ACLs translate into logical\n+ flows that set the reject bit and advance to the next table.\n+
    • \n+
  • \n+ pass apply-after-lb ACLs translate into logical flows that\n+ do not set the allow, drop, or reject bit and advance to the next\n+ table.\n+
    • \n+
  • \n+ Other apply-after-lb ACLs set the drop bit for new or untracked\n+ connections and ct_commit { ct_label=1/1; } for known\n+ connections. Setting ct_label marks a connection\n+ as one that was previously allowed, but should no longer be\n+ allowed due to a policy change.\n+
    • \n+
\n+\n+
    \n+
  • \n+ One priority-65532 flow matching packets with reg0[17]\n+ set (either replies to existing sessions or traffic related to\n+ existing sessions) and allows these by setting the allow bit and\n+ advancing to the next table.\n+
    • \n+
\n+\n+
    \n+
  • \n+ One priority-0 fallback flow that matches all packets and advances to\n+ the next table.\n+
    • \n+
\n+\n+

Ingress Table 21: from-lport ACL sampling after LB

\n+\n+

\n+ Logical flows in this table sample traffic matched by\n+ from-lport ACLs (evaluation after LB) with sampling enabled.\n+

\n+\n+
    \n+
  • \n+ If no ACLs have sampling enabled, then a priority 0 flow is installed\n+ that matches everything and advances to the next table.\n+
    • \n+\n+
  • \n+ For each ACL with sample_new configured a priority 1100 flow is\n+ installed that matches on the saved observation_point_id value.\n+ This flow generates a sample() action and then advances\n+ the packet to the next table.\n+
    • \n+\n+
  • \n+ For each ACL with sample_est configured a priority 1200 flow is\n+ installed that matches on the saved observation_point_id value\n+ for established traffic in the original direction. This flow\n+ generates a sample() action and then advances\n+ the packet to the next table.\n+
    • \n+\n+
  • \n+ For each ACL with sample_est configured a priority 1200 flow is\n+ installed that matches on the saved observation_point_id\n+ value for established traffic in the reply direction. This flow\n+ generates a sample() action and then advances\n+ the packet to the next table. Note: this flow is installed in the\n+ opposite pipeline (in the ingress pipeline for ACLs applied in the\n+ egress direction and in the egress pipeline for ACLs applied in the\n+ ingress direction).\n+
    • \n+
\n+\n+

Ingress Table 22: from-lport ACL action after LB

\n+\n+

\n+ Logical flows in this table decide how to proceed based on the values of\n+ the allow, drop, and reject bits that may have been set in the previous\n+ table.\n+

\n+\n+
    \n+
  • \n+ If no ACLs are configured, then a priority 0 flow is installed that\n+ matches everything and advances to the next table.\n+
    • \n+\n+
  • \n+ A priority 1000 flow is installed that will advance the packet to the\n+ next table if the allow bit is set.\n+
    • \n+\n+
  • \n+ A priority 1000 flow is installed that will run the drop;\n+ action if the drop bit is set.\n+
    • \n+\n+
  • \n+ A priority 1000 flow is installed that will run the tcp_reset\n+ { output <-> inport; next(pipeline=egress,table=5);}\n+ action for TCP connections,icmp4/icmp6 action\n+ for UDP connections, and sctp_abort {output <-%gt; inport;\n+ next(pipeline=egress,table=5);} action for SCTP associations.\n+
    • \n+\n+
  • \n+ If any ACLs have tiers configured on them, then three priority 500\n+ flows are installed. If the current tier counter is 0, 1, or 2, then\n+ the current tier counter is incremented by one and the packet is sent\n+ back to the previous table for re-evaluation.\n+
    • \n+
\n+\n+

Ingress Table 23: Pre Network Function

\n+

\n+ This stage selects the active network function from a\n+ Network_Function_Group based on the network function group\n+ ID set by the ACL eval stage earlier. This stage is applicable for\n+ request packets of from-lport ACLs\n+ (reg8[22] == 1). Response packets for\n+ to-lport ACLs bypass this stage and use\n+ ct_label.nf_id directly in the Network Function table.\n+

\n+\n+

\n+ A network function group can contain one or more network functions.\n+ Health monitoring is performed by sending datapath probes as per\n+ parameters defined in Network_Function_Health_Check. This\n+ stage selects one of the healthy network functions. If none are healthy,\n+ the behavior follows the fallback column configured in the\n+ Network_Function_Group table. If health monitoring is not\n+ configured, any one from the group is selected.\n+

\n+\n+

\n+ When a request packet matches a from-lport ACL with\n+ network_function_group set, the ACL eval stage sets\n+ reg8[21] = 1 (NF enabled), reg8[22] = 1\n+ (request direction), and reg0[22..29] to the network\n+ function group ID. This table then selects the active network function\n+ from the group and overwrites reg0[22..29] with the\n+ specific id of a Network_Function table entry.\n+ The subsequent Network Function table uses this NF ID to redirect packets\n+ to the appropriate network function port. In the future, this stage will\n+ be extended to support network function load balancing.\n+

\n+\n+
    \n+
  • \n+ For each network_function_group id with an active network\n+ function, a priority-99 flow matches reg8[21] == 1 &&\n+ reg8[22] == 1 && reg0[22..29] == id and\n+ sets reg0[22..29] = nf_id; next; where\n+ nf_id is the ID of the active network function. This\n+ prepares request packets that matched a from-lport ACL\n+ with network_function_group for redirection in the subsequent Network\n+ Function table.\n+
    • \n+\n+
  • \n+ For each network function group with id that has\n+ fallback set to fail-open, a priority-10 flow\n+ matches reg8[21] == 1 && reg8[22] == 1 &&\n+ reg0[22..29] == id and sets reg8[21] = 0;\n+ reg0[22..29] = 0; next;. This clears both the NF enabled bit and\n+ the NF group ID, allowing packets to continue processing through the\n+ pipeline without network function redirection when no active network\n+ function is available (fail-open behavior).\n+
    • \n+\n+
  • \n+ A priority-1 flow matches reg8[21] == 1 && reg8[22] == 1\n+ and sets reg0[22..29] = 0; next;. This is a\n+ catch-all flow for network function groups with fallback\n+ set to fail-close (or default) when no active network\n+ function is available. It clears only the NF group ID, leaving the NF\n+ enabled bit set. These packets will be dropped by the priority-1 drop\n+ rule in the subsequent Network Function table (fail-close behavior).\n+
    • \n+\n+
  • \n+ A priority-0 flow that simply moves traffic to the next table.\n+
    • \n+
\n+\n+

Ingress Table 24: Stateful

\n+\n+
    \n+
  • \n+ A priority 100 flow is added which commits the packet to the conntrack\n+ and sets the most significant 32-bits of ct_label with the\n+ reg3 value based on the hint provided by previous tables\n+ (with a match for reg0[1] == 1 && reg0[13] == 1).\n+ This is used by the ACLs with label to commit the label\n+ value to conntrack.\n+
    • \n+\n+
  • \n+ For ACLs without label, a second priority-100 flow commits\n+ packets to connection tracker using ct_commit; next;\n+ action based on a hint provided by the previous tables (with a match\n+ for reg0[1] == 1 && reg0[13] == 0).\n+
    • \n+\n+
  • \n+ Corresponding to each of the two priority 100 flows above, a priority\n+ 110 flow is added, which has the following extra match and\n+ action, but otherwise identical to the priority 100 flow.\n+ Match: reg8[21] == 1 (packet matched an ACL with\n+ network_function_group set)\n+ Action: ct_label.nf = 1;\n+ ct_label.nf_id = reg0[22..29];\n+ This is to commit the network_function information in conntrack so that\n+ the response and related packets can be redirected to it as well.\n+
    • \n+\n+
  • \n+ A priority-0 flow that simply moves traffic to the next table.\n+
    • \n+
\n+\n+

Ingress Table 25: Network Function

\n+

\n+ This table implements packet redirection to network functions. When a\n+ packet matches an ACL with network_function_group column\n+ set to the id of a Network_Function_Group\n+ table entry, the ACL eval stage sets reg8[21] = 1 (NF\n+ enabled), reg8[22] = 1 (request direction), and\n+ reg0[22..29] to the network function group ID. The Pre\n+ Network Function stage then selects the active network function from the\n+ group and overwrites reg0[22..29] with the specific\n+ id of a Network_Function table entry. This\n+ table uses that NF ID to redirect packets to the appropriate network\n+ function port.\n+

\n+\n+

\n+ This table handles request packets for from-lport ACLs\n+ and response packets for to-lport ACLs. For\n+ from-lport ACLs, request packets are redirected to the\n+ network function's inport, and corresponding\n+ response/related packets are handled in the egress pipeline. For\n+ to-lport ACLs, request packets are handled in the egress\n+ pipeline, but corresponding response/related packets for those flows\n+ are redirected here using the network function ID stored in\n+ ct_label.nf_id during request processing.\n+

\n+\n+

\n+ If the network function ports are not present on this logical switch,\n+ their child ports (if any) are used. In the statements below, network\n+ function ports refer to either the parent or child ports as applicable to\n+ this logical switch.\n+

\n+\n+
    \n+
  • \n+ For each network_function port P, a priority-100 flow is\n+ added that matches inport == P and advances\n+ packets to the next table. Thus packets coming from network function\n+ are not subject to redirection. This flow also sets\n+ reg5[16..31] = ct_label.tun_if_id. This is used for\n+ tunneling packet to originating host in case of cross host traffic\n+ redirection for VLAN subnet. This ct_label field stores the openflow\n+ tunnel interface id of the originating host for this connection and\n+ gets populated in egress Stateful table.\n+
    • \n+\n+
  • \n+ For each active network function with id that is referenced\n+ in a network function group, a priority-99 flow matches\n+ reg8[21] == 1 && reg8[22] == 1 &&\n+ reg0[22..29] == id and sets\n+ outport=P; output; where P is the\n+ inport of that network function. This redirects request\n+ packets for flows matching from-lport ACLs with\n+ network_function_group to the specific network function selected by\n+ the Pre Network Function stage.\n+
    • \n+\n+
  • \n+ For each active network function with id that is referenced\n+ in a network function group, a priority-99 rule matches\n+ reg8[21] == 1 && reg8[22] == 0 &&\n+ ct_label.nf_id == id and takes identical action as\n+ above. This redirects response and related packets for\n+ to-lport ACLs to the same network function that handled\n+ the request, using the NF ID stored in the connection tracking label.\n+
    • \n+\n+
  • \n+ In each of the above cases, when the same packet comes out unchanged\n+ through the other port of the network_function, it would match the\n+ priority 100 flow and be forwarded to the next table.\n+
    • \n+\n+
  • \n+ One priority-100 rule to skip redirection of multicast packets that hit\n+ a network_function ACL. Match on reg8[21] == 1 &&\n+ eth.mcast and action is to advance to the next table.\n+
    • \n+\n+
  • \n+ One priority-1 rule that checks reg8[21] == 1, and drops\n+ such packets. This is to address the case where a packet hit an ACL\n+ with network function but the network function does not have ports or\n+ child ports on this logical switch.\n+
    • \n+\n+
  • \n+ One priority-0 fallback flow that matches all packets and advances to\n+ the next table.\n+
    • \n+
\n+\n+

Ingress Table 26: ARP/ND responder

\n+\n+

\n+ This table implements ARP/ND responder in a logical switch for known\n+ IPs. The advantage of the ARP responder flow is to limit ARP\n+ broadcasts by locally responding to ARP requests without the need to\n+ send to other hypervisors. One common case is when the inport is a\n+ logical port associated with a VIF and the broadcast is responded to\n+ on the local hypervisor rather than broadcast across the whole\n+ network and responded to by the destination VM. This behavior is\n+ proxy ARP.\n+

\n+\n+

\n+ ARP requests arrive from VMs from a logical switch inport of type\n+ default. For this case, the logical switch proxy ARP rules can be\n+ for other VMs or logical router ports. Logical switch proxy ARP\n+ rules may be programmed both for mac binding of IP addresses on\n+ other logical switch VIF ports (which are of the default logical\n+ switch port type, representing connectivity to VMs or containers),\n+ and for mac binding of IP addresses on logical switch router type\n+ ports, representing their logical router port peers. In order to\n+ support proxy ARP for logical router ports, an IP address must be\n+ configured on the logical switch router type port, with the same\n+ value as the peer logical router port. The configured MAC addresses\n+ must match as well. When a VM sends an ARP request for a distributed\n+ logical router port and if the peer router type port of the attached\n+ logical switch does not have an IP address configured, the ARP request\n+ will be broadcast on the logical switch. One of the copies of the ARP\n+ request will go through the logical switch router type port to the\n+ logical router datapath, where the logical router ARP responder will\n+ generate a reply. The MAC binding of a distributed logical router,\n+ once learned by an associated VM, is used for all that VM's\n+ communication needing routing. Hence, the action of a VM re-arping for\n+ the mac binding of the logical router port should be rare.\n+

\n+\n+

\n+ Logical switch ARP responder proxy ARP rules can also be hit when\n+ receiving ARP requests externally on a L2 gateway port. In this case,\n+ the hypervisor acting as an L2 gateway, responds to the ARP request on\n+ behalf of a destination VM.\n+

\n+\n+

\n+ Note that ARP requests received from localnet logical\n+ inports can either go directly to VMs, in which case the VM responds or\n+ can hit an ARP responder for a logical router port if the packet is used\n+ to resolve a logical router port next hop address. In either case,\n+ logical switch ARP responder rules will not be hit. It contains these\n+ logical flows:\n+

\n+\n+
    \n+
  • \n+ If packet was received from HW VTEP (ramp switch), and this packet is\n+ ARP or Neighbor Solicitation, such packet is passed to next table with\n+ max proirity. ARP/ND requests from HW VTEP must be handled in logical\n+ router ingress pipeline.\n+
    • \n+
  • \n+ If the logical switch has no router ports with options:arp_proxy\n+ configured add a priority-100 flows to skip the ARP responder if inport\n+ is of type localnet advances directly to the next table.\n+ ARP requests sent to localnet ports can be received by\n+ multiple hypervisors. Now, because the same mac binding rules are\n+ downloaded to all hypervisors, each of the multiple hypervisors will\n+ respond. This will confuse L2 learning on the source of the ARP\n+ requests. ARP requests received on an inport of type\n+ router are not expected to hit any logical switch ARP\n+ responder flows. However, no skip flows are installed for these\n+ packets, as there would be some additional flow cost for this and the\n+ value appears limited.\n+
    • \n+\n+
  • \n+

    \n+ If inport V is of type virtual adds a\n+ priority-100 logical flows for each P configured in the\n+ \n+ column with the match\n+

    \n+ 
    \n+inport == P && && ((arp.op == 1 && arp.spa == VIP && arp.tpa == VIP) || (arp.op == 2 && arp.spa == VIP))\n+inport == P && && ((nd_ns && ip6.dst == {VIP, NS_MULTICAST_ADDR} && nd.target == VIP) || (nd_na && nd.target == VIP))\n+
    \n+\n+

    \n+ and applies the action\n+

    \n+ 
    \n+bind_vport(V, inport);\n+
    \n+\n+

    \n+ and advances the packet to the next table.\n+

    \n+\n+

    \n+ Where VIP is the virtual ip configured in the column\n+ and\n+ NS_MULTICAST_ADDR is solicited-node multicast address corresponding\n+ to the VIP.\n+

    \n+
    • \n+\n+
  • \n+

    \n+ Priority-50 flows that match only broadcast ARP requests to each\n+ known IPv4 address A of every logical switch port, and\n+ respond with ARP replies directly with corresponding Ethernet\n+ address E:\n+

    \n+\n+ 
    \n+eth.dst = eth.src;\n+eth.src = E;\n+arp.op = 2; /* ARP reply. */\n+arp.tha = arp.sha;\n+arp.sha = E;\n+arp.tpa = arp.spa;\n+arp.spa = A;\n+outport = inport;\n+flags.loopback = 1;\n+output;\n+
    \n+\n+

    \n+ These flows are omitted for logical ports (other than router ports or\n+ localport ports) that are down (unless \n+ ignore_lsp_down is configured as true in options\n+ column of NB_Global table of the Northbound\n+ database), for logical ports of type virtual, for\n+ logical ports with 'unknown' address set, for logical ports with\n+ the options:disable_arp_nd_rsp=true and for logical\n+ ports of a logical switch configured with\n+ other_config:vlan-passthru=true.\n+

    \n+\n+

    \n+ The above ARP responder flows are added for the list of IPv4 addresses\n+ if defined in options:arp_proxy column of\n+ Logical_Switch_Port table for logical switch ports of\n+ type router.\n+

    \n+
    • \n+\n+
  • \n+

    \n+ Priority-50 flows that match IPv6 ND neighbor solicitations to\n+ each known IP address A (and A's\n+ solicited node address) of every logical switch port except of type\n+ router, and respond with neighbor advertisements directly with\n+ corresponding Ethernet address E:\n+

    \n+\n+ 
    \n+nd_na {\n+    eth.src = E;\n+    ip6.src = A;\n+    nd.target = A;\n+    nd.tll = E;\n+    outport = inport;\n+    flags.loopback = 1;\n+    output;\n+};\n+
    \n+\n+

    \n+ Priority-50 flows that match IPv6 ND neighbor solicitations to\n+ each known IP address A (and A's\n+ solicited node address) of logical switch port of type router, and\n+ respond with neighbor advertisements directly with\n+ corresponding Ethernet address E:\n+

    \n+\n+ 
    \n+nd_na_router {\n+    eth.src = E;\n+    ip6.src = A;\n+    nd.target = A;\n+    nd.tll = E;\n+    outport = inport;\n+    flags.loopback = 1;\n+    output;\n+};\n+
    \n+\n+

    \n+ These flows are omitted for logical ports (other than router ports or\n+ localport ports) that are down (unless \n+ ignore_lsp_down is configured as true in options\n+ column of NB_Global table of the Northbound\n+ database), for logical ports of type virtual and for\n+ logical ports with 'unknown' address set.\n+

    \n+\n+

    \n+ The above NDP responder flows are added for the list of\n+ IPv6 addresses if defined in options:arp_proxy column of\n+ Logical_Switch_Port table for logical switch ports of\n+ type router.\n+

    \n+
    • \n+\n+
  • \n+

    \n+ Priority-100 flows with match criteria like the ARP and ND flows\n+ above, except that they only match packets from the\n+ inport that owns the IP addresses in question, with\n+ action next;. These flows prevent OVN from replying to,\n+ for example, an ARP request emitted by a VM for its own IP address.\n+ A VM only makes this kind of request to attempt to detect a duplicate\n+ IP address assignment, so sending a reply will prevent the VM from\n+ accepting the IP address that it owns.\n+

    \n+\n+

    \n+ In place of next;, it would be reasonable to use\n+ drop; for the flows' actions. If everything is working\n+ as it is configured, then this would produce equivalent results,\n+ since no host should reply to the request. But ARPing for one's own\n+ IP address is intended to detect situations where the network is not\n+ working as configured, so dropping the request would frustrate that\n+ intent.\n+

    \n+
    • \n+\n+
  • \n+

    \n+ For each SVC_MON_SRC_IP defined in the value of\n+ the column of\n+ table, priority-110\n+ logical flow is added with the match\n+ arp.tpa == SVC_MON_SRC_IP\n+ && && arp.op == 1 and applies the action\n+

    \n+\n+ 
    \n+eth.dst = eth.src;\n+eth.src = E;\n+arp.op = 2; /* ARP reply. */\n+arp.tha = arp.sha;\n+arp.sha = E;\n+arp.tpa = arp.spa;\n+arp.spa = A;\n+outport = inport;\n+flags.loopback = 1;\n+output;\n+
    \n+\n+

    \n+ where E is the service monitor source mac defined in\n+ the column in the table. This mac is used as the source mac\n+ in the service monitor packets for the load balancer endpoint IP\n+ health checks.\n+

    \n+\n+

    \n+ SVC_MON_SRC_IP is used as the source ip in the\n+ service monitor IPv4 packets for the load balancer endpoint IP\n+ health checks.\n+

    \n+\n+

    \n+ These flows are required if an ARP request is sent for the IP\n+ SVC_MON_SRC_IP.\n+

    \n+\n+

    \n+ For IPv6 the similar flow is added with the following action\n+

    \n+\n+ 
    \n+nd_na {\n+    eth.dst = eth.src;\n+    eth.src = E;\n+    ip6.src = A;\n+    nd.target = A;\n+    nd.tll = E;\n+    outport = inport;\n+    flags.loopback = 1;\n+    output;\n+};\n+
    \n+
    • \n+\n+
  • \n+

    \n+ For each VIP configured in the table\n+ \n+ a priority-50 logical flow is added with the match\n+ arp.tpa == vip && && arp.op == 1\n+ and applies the action\n+

    \n+\n+ 
    \n+eth.dst = eth.src;\n+eth.src = E;\n+arp.op = 2; /* ARP reply. */\n+arp.tha = arp.sha;\n+arp.sha = E;\n+arp.tpa = arp.spa;\n+arp.spa = A;\n+outport = inport;\n+flags.loopback = 1;\n+output;\n+
    \n+\n+

    \n+ where E is the forwarding group's mac defined in\n+ the .\n+

    \n+\n+

    \n+ A is used as either the destination ip for load balancing\n+ traffic to child ports or as nexthop to hosts behind the child ports.\n+

    \n+\n+

    \n+ These flows are required to respond to an ARP request if an ARP\n+ request is sent for the IP vip.\n+

    \n+
    • \n+\n+
  • \n+ One priority-0 fallback flow that matches all packets and advances to\n+ the next table.\n+
    • \n+
\n+\n+

Ingress Table 27: DHCP option processing

\n+\n+

\n+ This table adds the DHCPv4 options to a DHCPv4 packet from the\n+ logical ports configured with IPv4 address(es) and DHCPv4 options,\n+ and similarly for DHCPv6 options. This table also adds flows for the\n+ logical ports of type external.\n+

\n+\n+
    \n+
  • \n+

    \n+ A priority-100 logical flow is added for these logical ports\n+ which matches the IPv4 packet with udp.src = 68 and\n+ udp.dst = 67 and applies the action\n+ put_dhcp_opts and advances the packet to the next table.\n+

    \n+\n+ 
    \n+reg0[3] = put_dhcp_opts(offer_ip = ip, options...);\n+next;\n+
    \n+\n+

    \n+ For DHCPDISCOVER and DHCPREQUEST, this transforms the packet into a\n+ DHCP reply, adds the DHCP offer IP ip and options to the\n+ packet, and stores 1 into reg0[3]. For other kinds of packets, it\n+ just stores 0 into reg0[3]. Either way, it continues to the next\n+ table.\n+

    \n+\n+
    • \n+\n+
  • \n+

    \n+ A priority-100 logical flow is added for these logical ports\n+ which matches the IPv6 packet with udp.src = 546 and\n+ udp.dst = 547 and applies the action\n+ put_dhcpv6_opts and advances the packet to the next\n+ table.\n+

    \n+\n+ 
    \n+reg0[3] = put_dhcpv6_opts(ia_addr = ip, options...);\n+next;\n+
    \n+\n+

    \n+ For DHCPv6 Solicit/Request/Confirm packets, this transforms the\n+ packet into a DHCPv6 Advertise/Reply, adds the DHCPv6 offer IP\n+ ip and options to the packet, and stores 1 into reg0[3].\n+ For other kinds of packets, it just stores 0 into reg0[3]. Either\n+ way, it continues to the next table.\n+

    \n+
    • \n+\n+
  • \n+ A priority-0 flow that matches all packets to advances to table 16.\n+
    • \n+
\n+\n+

Ingress Table 28: DHCP responses

\n+\n+

\n+ This table implements DHCP responder for the DHCP replies generated by\n+ the previous table.\n+

\n+\n+
    \n+
  • \n+

    \n+ A priority 100 logical flow is added for the logical ports configured\n+ with DHCPv4 options which matches IPv4 packets with udp.src == 68\n+ && udp.dst == 67 && reg0[3] == 1 and\n+ responds back to the inport after applying these\n+ actions. If reg0[3] is set to 1, it means that the\n+ action put_dhcp_opts was successful.\n+

    \n+\n+ 
    \n+eth.dst = eth.src;\n+eth.src = E;\n+ip4.src = S;\n+udp.src = 67;\n+udp.dst = 68;\n+outport = P;\n+flags.loopback = 1;\n+output;\n+
    \n+\n+

    \n+ where E is the server MAC address and S is the\n+ server IPv4 address defined in the DHCPv4 options. Note that\n+ ip4.dst field is handled by put_dhcp_opts.\n+

    \n+\n+

    \n+ (This terminates ingress packet processing; the packet does not go\n+ to the next ingress table.)\n+

    \n+
    • \n+\n+
  • \n+

    \n+ A priority 100 logical flow is added for the logical ports configured\n+ with DHCPv6 options which matches IPv6 packets with udp.src == 546\n+ && udp.dst == 547 && reg0[3] == 1 and\n+ responds back to the inport after applying these\n+ actions. If reg0[3] is set to 1, it means that the\n+ action put_dhcpv6_opts was successful.\n+

    \n+\n+ 
    \n+eth.dst = eth.src;\n+eth.src = E;\n+ip6.dst = A;\n+ip6.src = S;\n+udp.src = 547;\n+udp.dst = 546;\n+outport = P;\n+flags.loopback = 1;\n+output;\n+
    \n+\n+

    \n+ where E is the server MAC address and S is the\n+ server IPv6 LLA address generated from the server_id\n+ defined in the DHCPv6 options and A is\n+ the IPv6 address defined in the logical port's addresses column.\n+

    \n+\n+

    \n+ (This terminates packet processing; the packet does not go on the\n+ next ingress table.)\n+

    \n+
    • \n+\n+
  • \n+ A priority-0 flow that matches all packets to advances to table 17.\n+
    • \n+
\n+\n+

Ingress Table 29 DNS Lookup

\n+\n+

\n+ This table looks up and resolves the DNS names to the corresponding\n+ configured IP address(es).\n+

\n+\n+
    \n+
  • \n+

    \n+ A priority-100 logical flow for each logical switch datapath\n+ if it is configured with DNS records, which matches the IPv4 and IPv6\n+ packets with udp.dst = 53 and applies the action\n+ dns_lookup and advances the packet to the next table.\n+

    \n+\n+ 
    \n+reg0[4] = dns_lookup(); next;\n+
    \n+\n+

    \n+ For valid DNS packets, this transforms the packet into a DNS\n+ reply if the DNS name can be resolved, and stores 1 into reg0[4].\n+ For failed DNS resolution or other kinds of packets, it just stores\n+ 0 into reg0[4]. Either way, it continues to the next table.\n+

    \n+
    • \n+
\n+\n+

Ingress Table 30 DNS Responses

\n+\n+

\n+ This table implements DNS responder for the DNS replies generated by\n+ the previous table.\n+

\n+\n+
    \n+
  • \n+

    \n+ A priority-100 logical flow for each logical switch datapath\n+ if it is configured with DNS records, which matches the IPv4 and IPv6\n+ packets with udp.dst = 53 && reg0[4] == 1\n+ and responds back to the inport after applying these\n+ actions. If reg0[4] is set to 1, it means that the\n+ action dns_lookup was successful.\n+

    \n+\n+ 
    \n+eth.dst <-> eth.src;\n+ip4.src <-> ip4.dst;\n+udp.dst = udp.src;\n+udp.src = 53;\n+outport = P;\n+flags.loopback = 1;\n+output;\n+
    \n+\n+

    \n+ (This terminates ingress packet processing; the packet does not go\n+ to the next ingress table.)\n+

    \n+
    • \n+
\n+\n+

Ingress table 31 External ports

\n+\n+

\n+ Traffic from the external logical ports enter the ingress\n+ datapath pipeline via the localnet port. This table adds the\n+ below logical flows to handle the traffic from these ports.\n+

\n+\n+
    \n+
  • \n+

    \n+ A priority-100 flow is added for each external logical\n+ port which doesn't reside on a chassis to drop the ARP/IPv6 NS\n+ request to the router IP(s) (of the logical switch) which matches\n+ on the inport of the external logical port\n+ and the valid eth.src address(es) of the\n+ external logical port.\n+

    \n+\n+

    \n+ This flow guarantees that the ARP/NS request to the router IP\n+ address from the external ports is responded by only the chassis\n+ which has claimed these external ports. All the other chassis,\n+ drops these packets.\n+

    \n+\n+

    \n+ A priority-100 flow is added for each external logical\n+ port which doesn't reside on a chassis to drop any packet destined\n+ to the router mac - with the match\n+ inport == external &&\n+ eth.src == E && eth.dst == R\n+ && !is_chassis_resident(\"external\")\n+ where E is the external port mac and R is the\n+ router port mac.\n+

    \n+
    • \n+\n+
  • \n+ A priority-0 flow that matches all packets to advances to table 20.\n+
    • \n+
\n+\n+

Ingress Table 32 Destination Lookup

\n+\n+

\n+ This table implements switching behavior. It contains these logical\n+ flows:\n+

\n+\n+
    \n+
  • \n+ A priority-110 flow with the match\n+ eth.src == E for all logical switch\n+ datapaths and applies the action handle_svc_check(inport).\n+ Where E is the service monitor mac defined in the\n+ column of table.\n+
    • \n+\n+
  • \n+ A priority-100 flow that punts all IGMP/MLD packets to\n+ ovn-controller if multicast snooping is enabled on the\n+ logical switch.\n+
    • \n+\n+
  • \n+ A priority-100 flow that forwards all DHCP broadcast packets coming\n+ from VIFs to the logical router port's MAC when DHCP relay is enabled\n+ on the logical switch.\n+
    • \n+\n+
  • \n+ A priority-100 flow that matches reg8[23] == 1 and does\n+ output action. This ensures that packets that got injected\n+ back into this table from egress table Network Function\n+ (after it set the outport for packet redirection) get\n+ forwarded without any further processing.\n+
    • \n+\n+
  • \n+

    \n+ For any logical port that's defined as a target of routing protocol\n+ redirecting (via routing-protocol-redirect option set on\n+ Logical Router Port), we redirect the traffic related to protocols\n+ specified in routing-protocols option. It's acoomplished\n+ with following priority-100 flows:\n+

    \n+
      \n+
    • \n+ Flows that match Logical Router Port's IPs and destination port of\n+ the routing daemon are redirected to this port to allow external\n+ peers' connection to the daemon listening on this port.\n+
      • \n+
    • \n+ Flows that match Logical Router Port's IPs and source port of\n+ the routing daemon are redirected to this port to allow replies\n+ from the peers.\n+
      • \n+
    \n+

    \n+ In addition to this, we add priority-100 rules that\n+ clone ARP replies and IPv6 Neighbor Advertisements to\n+ this port as well. These allow to build proper ARP/IPv6 neighbor\n+ list on this port.\n+

    \n+
    • \n+\n+
  • \n+ Priority-90 flows for transit switches that forward registered\n+ IP multicast traffic to their corresponding multicast group , which\n+ ovn-northd creates based on learnt\n+ entries.\n+
    • \n+\n+
  • \n+ Priority-90 flows that forward registered IP multicast traffic to\n+ their corresponding multicast group, which ovn-northd\n+ creates based on learnt \n+ entries. The flows also forward packets to the\n+ MC_MROUTER_FLOOD multicast group, which\n+ ovn-nortdh populates with all the logical ports that\n+ are connected to logical routers with\n+ :mcast_relay='true'.\n+
    • \n+\n+
  • \n+ A priority-85 flow that forwards all IP multicast traffic destined to\n+ 224.0.0.X to the MC_FLOOD_L2 multicast group, which\n+ ovn-northd populates with all non-router logical ports.\n+
    • \n+\n+
  • \n+ A priority-85 flow that forwards all IP multicast traffic destined to\n+ reserved multicast IPv6 addresses (RFC 4291, 2.7.1, e.g.,\n+ Solicited-Node multicast) to the MC_FLOOD multicast\n+ group, which ovn-northd populates with all enabled\n+ logical ports.\n+
    • \n+\n+
  • \n+ A priority-80 flow that forwards all unregistered IP multicast traffic\n+ to the MC_STATIC multicast group, which\n+ ovn-northd populates with all the logical ports that\n+ have \n+ :mcast_flood='true'. The flow also forwards\n+ unregistered IP multicast traffic to the MC_MROUTER_FLOOD\n+ multicast group, which ovn-northd populates with all the\n+ logical ports connected to logical routers that have\n+ \n+ :mcast_relay='true'.\n+
    • \n+\n+
  • \n+ A priority-80 flow that drops all unregistered IP multicast traffic\n+ if \n+ :mcast_snoop='true' and\n+ \n+ :mcast_flood_unregistered='false' and the switch is\n+ not connected to a logical router that has\n+ \n+ :mcast_relay='true' and the switch doesn't have any\n+ logical port with \n+ :mcast_flood='true'.\n+
    • \n+\n+
  • \n+ Priority-80 flows for each IP address/VIP/NAT address owned by a\n+ router port connected to the switch. These flows match ARP requests\n+ and ND packets for the specific IP addresses. Matched packets are\n+ forwarded only to the router that owns the IP address and to the\n+ MC_FLOOD_L2 multicast group which contains all non-router\n+ logical ports.\n+
    • \n+\n+
  • \n+ Priority-75 flows for each port connected to a logical router\n+ matching self originated ARP request/RARP request/ND packets. These\n+ packets are flooded to the MC_FLOOD_L2 which contains all\n+ non-router logical ports.\n+
    • \n+\n+
  • \n+ A priority-72 flow that outputs all ND NA (Neighbor Advertisement),\n+ ND RS (Router Solicitation) and ND RA (Router Advertisement) packets\n+ with an Ethernet broadcast or multicast eth.dst to the\n+ MC_FLOOD multicast group, which includes all ports.\n+ ND NA must reach routers for neighbor learning; ND RS must reach\n+ routers so they can respond with Router Advertisements; ND RA must\n+ reach routers for proper IPv6 network operation.\n+
    • \n+\n+
  • \n+ A priority-72 flow that outputs all ARP requests and ND NS (Neighbor\n+ Solicitation) packets with an Ethernet broadcast or multicast\n+ eth.dst to the MC_FLOOD_L2 multicast group\n+ if other_config:broadcast-arps-to-all-routers=false.\n+
    • \n+\n+
  • \n+ A priority-71 flow that outputs all ARP packets with an Ethernet\n+ broadcast or multicast eth.dst to the\n+ MC_FLOOD multicast group.\n+
    • \n+\n+
  • \n+ A priority-71 flow that outputs all IP packets with an Ethernet\n+ broadcast or multicast eth.dst to the\n+ MC_FLOOD_L2 multicast group, which contains only\n+ non-router logical ports. If any connected router has\n+ options:mcast_relay=true, the packet is also cloned to\n+ the MC_MROUTER_FLOOD multicast group (which contains\n+ only the router ports with relay enabled). If any port has\n+ options:mcast_flood=true, it is also cloned to the\n+ MC_STATIC multicast group. This prevents IP multicast\n+ from being unnecessarily forwarded to routers that would drop it.\n+
    • \n+\n+
  • \n+ A priority-70 flow that outputs all packets with an Ethernet broadcast\n+ or multicast eth.dst to the MC_FLOOD_L2\n+ multicast group.\n+
    • \n+\n+
  • \n+

    \n+ One priority-50 flow that matches each known Ethernet address against\n+ eth.dst. Action of this flow outputs the packet to the\n+ single associated output port if it is enabled. drop;\n+ action is applied if LSP is disabled. If the logical switch port\n+ of type VIF has the option options:pkt_clone_type\n+ is set to the value mc_unknown, then the packet is\n+ also forwarded to the MC_UNKNOWN multicast group.\n+

    \n+\n+

    \n+ The above flow is not added if the logical switch port is of type\n+ VIF, has unknown as one of its address and has the\n+ option options:force_fdb_lookup set to true.\n+

    \n+\n+

    \n+ For the Ethernet address on a logical switch port of type\n+ router, when that logical switch port's\n+ column is set to router and\n+ the connected logical router port has a gateway chassis:\n+

    \n+\n+
      \n+
    • \n+ The flow for the connected logical router port's Ethernet\n+ address is only programmed on the gateway chassis.\n+
      • \n+\n+
    • \n+ If the logical router has rules specified in\n+ with\n+ , then\n+ those addresses are also used to populate the switch's destination\n+ lookup on the chassis where\n+ is\n+ resident.\n+
      • \n+
    \n+\n+

    \n+ For the Ethernet address on a logical switch port of type\n+ router, when that logical switch port's\n+ column is set to router and\n+ the connected logical router port specifies a\n+ reside-on-redirect-chassis and the logical router\n+ to which the connected logical router port belongs to has a\n+ distributed gateway LRP:\n+

    \n+\n+
      \n+
    • \n+ The flow for the connected logical router port's Ethernet\n+ address is only programmed on the gateway chassis.\n+
      • \n+
    \n+\n+

    \n+ For each forwarding group configured on the logical switch datapath,\n+ a priority-50 flow that matches on eth.dst == VIP\n+ with an action of fwd_group(childports=args\n+ ), where args contains comma separated\n+ logical switch child ports to load balance to.\n+ If liveness is enabled, then action also includes\n+ liveness=true.\n+

    \n+
    • \n+\n+
  • \n+ One priority-0 fallback flow that matches all packets with the\n+ action outport = get_fdb(eth.dst); next;. The action\n+ get_fdb gets the port for the eth.dst\n+ in the MAC learning table of the logical switch datapath. If there\n+ is no entry for eth.dst in the MAC learning table,\n+ then it stores none in the outport.\n+
    • \n+
\n+\n+

Ingress Table 33 Destination unknown

\n+\n+

\n+ This table handles the packets whose destination was not found or\n+ and looked up in the MAC learning table of the logical switch\n+ datapath. It contains the following flows.\n+

\n+\n+
    \n+
  • \n+

    \n+ Priority 50 flow with the match outport == P\n+ is added for each disabled Logical Switch Port P. This\n+ flow has action drop;.\n+

    \n+
    • \n+
  • \n+

    \n+ If the logical switch has logical ports with 'unknown' addresses set,\n+ then the below logical flow is added\n+

    \n+\n+
      \n+
    • \n+ Priority 50 flow with the match outport == \"none\" then\n+ outputs them to the MC_UNKNOWN multicast group, which\n+ ovn-northd populates with all enabled logical ports\n+ that accept unknown destination packets. As a small optimization,\n+ if no logical ports accept unknown destination packets,\n+ ovn-northd omits this multicast group and logical\n+ flow.\n+
      • \n+
    \n+\n+

    \n+ If the logical switch has no logical ports with 'unknown' address\n+ set, then the below logical flow is added\n+

    \n+\n+
      \n+
    • \n+ Priority 50 flow with the match outport == none\n+ and drops the packets.\n+
      • \n+
    \n+
    • \n+\n+
  • \n+ One priority-0 fallback flow that outputs the packet to the egress\n+ stage with the outport learnt from get_fdb action.\n+
    • \n+
\n+\n+

Egress Table 0: Lookup MAC address learning table

\n+

\n+ This is similar to ingress table Lookup MAC address learning table\n+ with the difference that MAC address learning lookup is only\n+ happening for ports with type remote whose port security is\n+ disabled and 'unknown' address set. This stage facilitates MAC learning\n+ on a transit switch connecting multiple availability zones.\n+

\n+\n+

Egress Table 1: Learn MAC of 'unknown' ports.

\n+

\n+ This is similar to ingress table Learn MAC of 'unknown' ports\n+ with the difference that MAC address learning is only happening\n+ for ports with type remote whose port security is disabled\n+ and 'unknown' address set. This stage facilitates MAC learning on a\n+ transit switch connecting multiple availability zones.\n+

\n+\n+

Egress Table 2: to-lport Pre-ACLs

\n+\n+

\n+ This is similar to ingress table Pre-ACLs except for\n+ to-lport traffic.\n+

\n+\n+

\n+ This table also has a priority-110 flow with the match\n+ eth.src == E for all logical switch\n+ datapaths to move traffic to the next table. Where E\n+ is the service monitor mac defined in the\n+ column of table.\n+

\n+\n+

\n+ This table also has a priority-110 flow with the match\n+ outport == I for all logical switch\n+ datapaths to move traffic to the next table. Where I\n+ is the peer of a logical router port. This flow is added to\n+ skip the connection tracking of packets which will be entering\n+ logical router datapath from logical switch datapath for routing.\n+

\n+\n+

\n+ This table also has a priority-110 flow for each network_function\n+ inport P that matches inport ==\n+ P. The action is to skip all the egress tables up to\n+ the Network Function table and advance the packet directly\n+ to the table after that. This is for the case where packet redirection\n+ happens in egress Network Function table. The same packet\n+ when it comes out of the other port of network function, they should not\n+ be processed again by the same egress stages, specially they should\n+ skip the conntrack processing.\n+

\n+\n+

Egress Table 3: Pre-LB

\n+\n+

\n+ This table is similar to ingress table Pre-LB. It\n+ contains a priority-0 flow that simply moves traffic to the next table.\n+ Moreover it contains two priority-110 flows to move multicast, IPv6\n+ Neighbor Discovery and MLD traffic to the next table. If any load\n+ balancing rules exist for the datapath, a priority-100 flow is added with\n+ a match of ip and action of reg0[2] = 1; next;\n+ to act as a hint for table Pre-stateful to send IP packets\n+ to the connection tracker for packet de-fragmentation and possibly DNAT\n+ the destination VIP to one of the selected backend for already committed\n+ load balanced traffic.\n+

\n+\n+

\n+ This table also has a priority-110 flow with the match\n+ eth.src == E for all logical switch\n+ datapaths to move traffic to the next table. Where E\n+ is the service monitor mac defined in the\n+ column of table.\n+

\n+\n+

\n+ This table also has a priority-110 flow with the match\n+ outport == I for all logical switch\n+ datapaths to move traffic to the next table, and, if there are no\n+ stateful_acl, clear the ct_state. Where I\n+ is the peer of a logical router port. This flow is added to\n+ skip the connection tracking of packets which will be entering\n+ logical router datapath from logical switch datapath for routing.\n+

\n+\n+

\n+ When enable-stateless-acl-with-lb is enabled,\n+ additional priority-115 flow is added to match traffic with\n+ REGBIT_ACL_STATELESS set and pass connection tracking.\n+

\n+\n+

Egress Table 4: Pre-stateful

\n+\n+

\n+ This is similar to ingress table Pre-stateful. This table\n+ adds the below 3 logical flows.\n+

\n+\n+
    \n+
  • \n+ A Priority-120 flow that send the packets to connection tracker using\n+ ct_lb_mark; as the action so that the already established\n+ traffic gets unDNATted from the backend IP to the load balancer VIP\n+ based on a hint provided by the previous tables with a match\n+ for reg0[2] == 1. If the packet was not DNATted earlier,\n+ then ct_lb_mark functions like ct_next.\n+
    • \n+\n+
  • \n+ A priority-100 flow sends the packets to connection tracker based\n+ on a hint provided by the previous tables\n+ (with a match for reg0[0] == 1) by using the\n+ ct_next; action.\n+
    • \n+\n+
  • \n+ A priority-0 flow that matches all packets to advance to the next\n+ table.\n+
    • \n+
\n+\n+

Egress Table 5: from-lport ACL hints

\n+

\n+ This is similar to ingress table ACL hints.\n+

\n+\n+

Egress Table 6: to-lport ACL evaluation

\n+\n+

\n+ This is similar to ingress table ACL eval except for\n+ to-lport ACLs. As a reminder, these flows use the\n+ following register bits to indicate their verdicts.\n+ Allow-type ACLs set reg8[16], drop\n+ ACLs set reg8[17], and reject ACLs set\n+ reg8[18].\n+

\n+\n+

\n+ Also like with ingress ACLs, egress ACLs can have network_function_group\n+ id and in that case the flow will set reg8[21] = 1;\n+ reg8[22] = 1; reg0[22..29] = id. These registers are used\n+ in the Network Function table.\n+

\n+\n+

\n+ Also like with ingress ACLs, egress ACLs can have a configured\n+ tier. If a tier is configured, then the current tier\n+ counter is evaluated against the ACL's configured tier in addition\n+ to the ACL's match. The current tier counter is stored in\n+ reg8[30..31].\n+

\n+\n+

\n+ Similar to ingress table, a priority-65532 flow is added to allow IPv6\n+ Neighbor solicitation, Neighbor discover, Router solicitation, Router\n+ advertisement and MLD packets regardless of other ACLs defined.\n+

\n+\n+

\n+ In addition, the following flows are added.\n+

\n+
    \n+
  • \n+ A priority 34000 logical flow is added for each logical port which\n+ has DHCPv4 options defined to allow the DHCPv4 reply packet and which has\n+ DHCPv6 options defined to allow the DHCPv6 reply packet from the\n+ Ingress Table 26: DHCP responses. This is indicated by\n+ setting the allow bit.\n+
    • \n+\n+
  • \n+ A priority 34000 logical flow is added for each logical switch datapath\n+ configured with DNS records with the match udp.dst = 53\n+ to allow the DNS reply packet from the\n+ Ingress Table 28: DNS responses. This is indicated by\n+ setting the allow bit.\n+
    • \n+\n+
  • \n+ A priority 34000 logical flow is added for each logical switch datapath\n+ with the match eth.src = E to allow the service\n+ monitor request packet generated by ovn-controller\n+ with the action next, where E is the\n+ service monitor mac defined in the\n+ column of table. This is indicated by setting the allow\n+ bit.\n+
    • \n+
\n+\n+

Egress Table 7: to-lport ACL sampling

\n+

\n+ This is similar to ingress table ACL sampling.\n+

\n+\n+

Egress Table 8: to-lport ACL action

\n+

\n+ This is similar to ingress table ACL action.\n+

\n+\n+

Egress Table 9: Mirror

\n+\n+

\n+ Overlay remote mirror table contains the following\n+ logical flows:\n+

\n+\n+
    \n+
  • \n+ For each logical switch port with an attached mirror, a logical flow\n+ with a priority of 100 is added. This flow matches all outcoming\n+ packets to the attached port, clones them, and forwards the cloned\n+ packets to the mirror target port.\n+
    • \n+\n+
  • \n+ A priority 0 flow is added which matches on all packets and applies\n+ the action next;.\n+
    • \n+\n+
  • \n+ A logical flow added for each Mirror Rule in Mirror table attached\n+ to logical switch ports, matches all outcoming packets that match\n+ rules and clones the packet and sends cloned packet to mirror\n+ target port.\n+
    • \n+
\n+\n+

Egress Table 10: to-lport QoS

\n+\n+

\n+ This is similar to ingress table QoS except\n+ they apply to to-lport QoS rules.\n+

\n+\n+

Egress Table 11: Pre Network Function

\n+\n+

\n+ This stage selects the active network function from a\n+ Network_Function_Group based on the network function group\n+ ID set by the ACL eval stage earlier. This stage is applicable for\n+ request packets of to-lport ACLs\n+ (reg8[22] == 1). Response packets for\n+ from-lport ACLs bypass this stage and use\n+ ct_label.nf_id directly in the Network Function table.\n+

\n+\n+

\n+ A network function group can contain one or more network functions.\n+ Health monitoring is performed by sending datapath probes as per\n+ parameters defined in Network_Function_Health_Check. This\n+ stage selects one of the healthy network functions. If none are healthy,\n+ the behavior follows the fallback column configured in the\n+ Network_Function_Group table. If health monitoring is not\n+ configured, any one from the group is selected.\n+

\n+\n+

\n+ When a request packet matches a to-lport ACL with\n+ network_function_group set, the ACL eval stage sets\n+ reg8[21] = 1 (NF enabled), reg8[22] = 1\n+ (request direction), and reg0[22..29] to the network\n+ function group ID. This table then selects the active network function\n+ from the group and overwrites reg0[22..29] with the\n+ specific id of a Network_Function table entry.\n+ The subsequent Network Function table uses this NF ID to redirect packets\n+ to the appropriate network function port. In the future, this stage will\n+ be extended to support network function load balancing.\n+

\n+\n+
    \n+
  • \n+ For each network function group with id that has an active\n+ network function, a priority-99 flow matches reg8[21] == 1\n+ && reg8[22] == 1 && reg0[22..29] == id\n+ and sets reg0[22..29] = nf_id; next; where\n+ nf_id is the id of the active\n+ Network_Function selected from the group. This prepares\n+ request packets that matched a to-lport ACL with\n+ network_function_group for redirection in the subsequent Network\n+ Function table.\n+
    • \n+\n+
  • \n+ For each network function group with id that has\n+ fallback set to fail-open, a priority-10 flow\n+ matches reg8[21] == 1 && reg8[22] == 1 &&\n+ reg0[22..29] == id and sets reg8[21] = 0;\n+ reg0[22..29] = 0; next;. This clears both the NF enabled bit and\n+ the NF group ID, allowing packets to continue processing through the\n+ pipeline without network function redirection when no active network\n+ function is available (fail-open behavior).\n+
    • \n+\n+
  • \n+ A priority-1 flow matches reg8[21] == 1 && reg8[22] == 1\n+ and sets reg0[22..29] = 0; next;. This is a\n+ catch-all flow for network function groups with fallback\n+ set to fail-close (or default) when no active network\n+ function is available. It clears only the NF group ID, leaving the NF\n+ enabled bit set. These packets will be dropped by the priority-1 drop\n+ rule in the subsequent Network Function table (fail-close behavior).\n+
    • \n+\n+
  • \n+ A priority-0 flow that simply moves traffic to the next table.\n+
    • \n+
\n+\n+

Egress Table 12: Stateful

\n+\n+

\n+ This is similar to ingress table Stateful except that\n+ there are no rules added for load balancing new connections.\n+ When enable-stateless-acl-with-lb is enabled, new\n+ stateless connections bypass connection tracking.\n+

\n+\n+
    \n+
  • \n+ A priority 120 flow is added for each network function port\n+ P that is identical to the priority 100 flow except for\n+ additional match outport == P and additional\n+ action ct_label.tun_if_id = reg5[16..31]. In case packets\n+ redirected by network function logic gets tunneled from host1 to host2\n+ where the network function port resides, host2's physical table 0\n+ populates reg5[16..31] with the openflow tunnel interface id on which\n+ the packet was received. This priority 120 flow commits the tunnel id\n+ to the ct_label. That way, when the same packet comes out of the other\n+ port of the network function it can retrieve this information from the\n+ peer port's CT entry and tunnel the packet back to host1. This is\n+ required to make cross host traffic redirection work for VLAN subnet.\n+
    • \n+
\n+\n+

Egress Table 13: Network Function

\n+\n+

\n+ This table handles request packets for to-lport ACLs\n+ and response packets for from-lport ACLs. For\n+ to-lport ACLs, request packets are redirected to the\n+ network function's outport, and corresponding\n+ response/related packets are handled in the ingress pipeline. For\n+ from-lport ACLs, request packets are handled in the\n+ ingress pipeline, but corresponding response/related packets for those\n+ flows are redirected here using the network function ID stored in\n+ ct_label.nf_id during request processing.\n+

\n+\n+
    \n+
  • \n+ Similar to ingress Network Function a priority-100 flow is\n+ added for each network_function port, that matches the inport with the\n+ network function port and advances the packet to the next table.\n+
    • \n+\n+
  • \n+ For each active network function with id that is\n+ referenced in a network function group, a priority-99 flow matches\n+ reg8[21] == 1 && reg8[22] == 1 &&\n+ reg0[22..29] == id and sets\n+ outport=P; reg8[23] = 1; next(pipeline=ingress,\n+ table=T) where P is the\n+ outport of that network function and T is\n+ the ingress table Destination Lookup. This redirects\n+ request packets matching to-lport ACLs with\n+ network_function_group to the specific network function selected by\n+ the Pre Network Function stage. The packets are injected back to the\n+ ingress pipeline from where they get sent out, skipping any further\n+ lookup because of reg8[23].\n+
    • \n+\n+
  • \n+ For each active network function with id that is referenced\n+ in a network function group, a priority-99 rule matches\n+ reg8[21] == 1 && reg8[22] == 0 &&\n+ ct_label.nf_id == id and takes identical action as\n+ above. This redirects response and related packets for\n+ from-lport ACLs to the same network function that handled\n+ the request, using the NF ID stored in the connection tracking label.\n+
    • \n+\n+
  • \n+ In each of the above cases, when the same packet comes out unchanged\n+ through the other port of the network_function, it would match the\n+ priority 100 flow and be forwarded to the next table.\n+
    • \n+\n+
  • \n+ One priority-100 multicast match flow same as\n+ ingress Network Function.\n+
    • \n+\n+
  • \n+ One priority-1 flow same as ingress Network Function.\n+
    • \n+\n+
  • \n+ One priority-0 flow same as ingress Network Function.\n+
    • \n+
\n+\n+

Egress Table 14: Egress Port Security - check

\n+\n+

\n+ This is similar to the port security logic in table\n+ Ingress Port Security check except that action\n+ check_out_port_sec is used to check the port security\n+ rules. This table adds the below logical flows.\n+

\n+\n+
    \n+
  • \n+ A priority 100 flow which matches on the multicast traffic and applies\n+ the action REGBIT_PORT_SEC_DROP\" = 0; next;\" to skip\n+ the out port security checks.\n+
    • \n+\n+
  • \n+ A priority 0 logical flow is added which matches on all the packets\n+ and applies the action\n+ REGBIT_PORT_SEC_DROP\" = check_out_port_sec(); next;\".\n+ The action check_out_port_sec applies the port security\n+ rules based on the addresses defined in the\n+ column of table before delivering the packet to the\n+ outport.\n+
    • \n+
\n+\n+

Egress Table 15: Egress Port Security - Apply

\n+\n+

\n+ This is similar to the ingress port security logic in ingress table\n+ A Ingress Port Security - Apply. This table drops the\n+ packets if the port security check failed in the previous stage i.e\n+ the register bit REGBIT_PORT_SEC_DROP is set to 1.\n+

\n+\n+

\n+ The following flows are added.\n+

\n+\n+
    \n+
  • \n+

    \n+ For each port configured with egress qos in the\n+ column of , running a localnet port on the same logical\n+ switch, a priority 110 flow is added which matches on the localnet\n+ outport and on the port inport and\n+ applies the action set_queue(id); output;\".\n+

    \n+
    • \n+\n+
  • \n+

    \n+ For each localnet port configured with egress qos in the\n+ column of , a priority 100 flow is added which\n+ matches on the localnet outport and applies the action\n+ set_queue(id); output;\".\n+

    \n+\n+

    \n+ Please remember to mark the corresponding physical interface with\n+ ovn-egress-iface set to true in\n+ .\n+

    \n+
    • \n+\n+
  • \n+ A priority-50 flow that drops the packet if the register\n+ bit REGBIT_PORT_SEC_DROP is set to 1.\n+
    • \n+\n+
  • \n+ A priority-0 flow that outputs the packet to the outport.\n+
    • \n+
\n+\n+

Logical Router Datapaths

\n+\n+

\n+ Logical router datapaths will only exist for rows in the database\n+ that do not have set to false\n+

\n+\n+

Ingress Table 0: L2 Admission Control

\n+\n+

\n+ This table drops packets that the router shouldn't see at all based on\n+ their Ethernet headers. It contains the following flows:\n+

\n+\n+
    \n+
  • \n+ Priority-100 flows to drop packets with VLAN tags or multicast Ethernet\n+ source addresses.\n+
    • \n+\n+
  • \n+

    \n+ For each enabled router port P with Ethernet address\n+ E, a priority-50 flow that matches inport ==\n+ P && (eth.mcast || eth.dst ==\n+ E), stores the router port ethernet address\n+ and advances to next table, with action\n+ xreg0[0..47]=E; next;.\n+

    \n+\n+

    \n+ For the gateway port on a distributed logical router (where\n+ one of the logical router ports specifies a\n+ gateway chassis), the above flow matching\n+ eth.dst == E is only programmed on\n+ the gateway port instance on the gateway chassis.\n+ If LRP's logical switch has attached LSP of vtep type,\n+ the is_chassis_resident() part is not added to lflow to\n+ allow traffic originated from logical switch to reach LR services\n+ (LBs, NAT).\n+

    \n+\n+

    \n+ For each gateway port GW on a distributed logical router\n+ a priority-120 flow that matches 'recirculated' icmp{4,6} error\n+ 'packet too big' and eth.dst == D &&\n+ !is_chassis_resident( cr-GW) where D\n+ is the gateway port mac address and cr-GW is the chassis\n+ resident port of GW, swap inport and outport and stores\n+ GW as inport.\n+

    \n+\n+

    \n+ This table adds a priority-105 flow that matches 'recirculated'\n+ icmp{4,6} error 'packet too big' to drop the packet.\n+

    \n+\n+

    \n+ For unicast L2 traffic on a distributed logical router or for\n+ gateway router where the port is configured with\n+ options:gateway_mtu the action of the above flow\n+ is modified adding check_pkt_larger in order to mark\n+ the packet setting REGBIT_PKT_LARGER if the size is\n+ greater than the MTU.\n+\n+ If the port is also configured with\n+ options:gateway_mtu_bypass then another flow is\n+ added, with priority-55, to bypass the check_pkt_larger\n+ flow. This is useful for traffic that normally doesn't need to be\n+ fragmented and for which check_pkt_larger, which might not be\n+ offloadable, is not really needed. One such example is TCP traffic.\n+

    \n+
    • \n+\n+
  • \n+

    \n+ For each dnat_and_snat NAT rule on a distributed\n+ router that specifies an external Ethernet address E,\n+ a priority-50 flow that matches inport == GW\n+ && eth.dst == E, where GW\n+ is the logical router distributed gateway port corresponding to the\n+ NAT rule (specified or inferred), with action\n+ xreg0[0..47]=E; next;.\n+

    \n+\n+

    \n+ This flow is only programmed on the gateway port instance on\n+ the chassis where the logical_port specified in\n+ the NAT rule resides.\n+

    \n+
    • \n+\n+
  • \n+ A priority-0 logical flow that matches all packets not already handled\n+ (match 1) and drops them (action drop;).\n+
    • \n+
\n+\n+

\n+ Other packets are implicitly dropped.\n+

\n+\n+

Ingress Table 1: Neighbor lookup

\n+\n+

\n+ For ARP and IPv6 Neighbor Discovery packets, this table looks into the\n+ records to determine\n+ if OVN needs to learn the mac bindings. Following flows are added:\n+

\n+\n+
    \n+
  • \n+

    \n+ For each router port P that owns IP address A,\n+ which belongs to subnet S with prefix length L,\n+ if the option always_learn_from_arp_request is\n+ true for this router, a priority-100 flow is added which\n+ matches inport == P && arp.spa ==\n+ S/L && arp.op == 1 (ARP request)\n+ with the following actions:\n+

    \n+\n+ 
    \n+reg9[2] = lookup_arp(inport, arp.spa, arp.sha);\n+next;\n+
    \n+\n+

    \n+ If the option always_learn_from_arp_request is\n+ false, the following two flows are added.\n+

    \n+\n+

    \n+ A priority-110 flow is added which matches inport ==\n+ P && arp.spa == S/L\n+ && arp.tpa == A && arp.op == 1\n+ (ARP request) with the following actions:\n+

    \n+\n+ 
    \n+reg9[2] = lookup_arp(inport, arp.spa, arp.sha);\n+reg9[3] = 1;\n+next;\n+
    \n+\n+

    \n+ A priority-100 flow is added which matches inport ==\n+ P && arp.spa == S/L\n+ && arp.op == 1 (ARP request) with the following\n+ actions:\n+

    \n+\n+ 
    \n+reg9[2] = lookup_arp(inport, arp.spa, arp.sha);\n+reg9[3] = lookup_arp_ip(inport, arp.spa);\n+next;\n+
    \n+\n+

    \n+ If the logical router port P is a distributed gateway\n+ router port, additional match\n+ is_chassis_resident(cr-P) is added for all\n+ these flows.\n+

    \n+
    • \n+\n+
  • \n+

    \n+ A priority-100 flow which matches on ARP reply packets and applies\n+ the actions if the option always_learn_from_arp_request\n+ is true:\n+

    \n+\n+ 
    \n+reg9[2] = lookup_arp(inport, arp.spa, arp.sha);\n+next;\n+
    \n+\n+

    \n+ If the option always_learn_from_arp_request\n+ is false, the above actions will be:\n+

    \n+\n+ 
    \n+reg9[2] = lookup_arp(inport, arp.spa, arp.sha);\n+reg9[3] = 1;\n+next;\n+
    \n+\n+
    • \n+\n+
  • \n+

    \n+ A priority-100 flow which matches on IPv6 Neighbor Discovery\n+ advertisement packet and applies the actions if the option\n+ always_learn_from_arp_request is true:\n+

    \n+\n+ 
    \n+reg9[2] = lookup_nd(inport, nd.target, nd.tll);\n+next;\n+
    \n+\n+

    \n+ If the option always_learn_from_arp_request\n+ is false, the above actions will be:\n+

    \n+\n+ 
    \n+reg9[2] = lookup_nd(inport, nd.target, nd.tll);\n+reg9[3] = 1;\n+next;\n+
    \n+
    • \n+\n+
  • \n+

    \n+ A priority-100 flow which matches on IPv6 Neighbor Discovery\n+ solicitation packet and applies the actions if the option\n+ always_learn_from_arp_request is true:\n+

    \n+\n+ 
    \n+reg9[2] = lookup_nd(inport, ip6.src, nd.sll);\n+next;\n+
    \n+\n+

    \n+ If the option always_learn_from_arp_request\n+ is false, the above actions will be:\n+

    \n+\n+ 
    \n+reg9[2] = lookup_nd(inport, ip6.src, nd.sll);\n+reg9[3] = lookup_nd_ip(inport, ip6.src);\n+next;\n+
    \n+
    • \n+\n+
  • \n+ A priority-0 fallback flow that matches all packets and applies\n+ the action reg9[2] = 1; next;\n+ advancing the packet to the next table.\n+
    • \n+
\n+\n+

Ingress Table 2: Neighbor learning

\n+\n+

\n+ This table adds flows to learn the mac bindings from the ARP and\n+ IPv6 Neighbor Solicitation/Advertisement packets if it is needed\n+ according to the lookup results from the previous stage.\n+

\n+\n+

\n+ reg9[2] will be 1 if the lookup_arp/lookup_nd\n+ in the previous table was successful or skipped, meaning no need\n+ to learn mac binding from the packet.\n+

\n+\n+

\n+ reg9[3] will be 1 if the\n+ lookup_arp_ip/lookup_nd_ip in the previous table was\n+ successful or skipped, meaning it is ok to learn mac binding from\n+ the packet (if reg9[2] is 0).\n+

\n+\n+
    \n+
  • \n+ A priority-100 flow with the match reg9[2] == 1 || reg9[3] ==\n+ 0 and advances the packet to the next table as there is no need\n+ to learn the neighbor.\n+
    • \n+\n+
  • \n+ A priority-95 flow with the match nd_ns &&\n+ (ip6.src == 0 || nd.sll == 0) and applies the action\n+ next;\n+
    • \n+\n+
  • \n+ A priority-90 flow with the match arp and\n+ applies the action\n+ put_arp(inport, arp.spa, arp.sha); next;\n+
    • \n+\n+
  • \n+ A priority-95 flow with the match nd_na &&\n+ nd.tll == 0 and applies the action\n+ put_nd(inport, nd.target, eth.src); next;\n+
    • \n+\n+
  • \n+ A priority-90 flow with the match nd_na and\n+ applies the action\n+ put_nd(inport, nd.target, nd.tll); next;\n+
    • \n+\n+
  • \n+ A priority-90 flow with the match nd_ns and\n+ applies the action\n+ put_nd(inport, ip6.src, nd.sll); next;\n+
    • \n+\n+
  • \n+ A priority-0 logical flow that matches all packets not already handled\n+ (match 1) and drops them (action drop;).\n+
    • \n+
\n+\n+

Ingress Table 3: IP Input

\n+\n+

\n+ This table is the core of the logical router datapath functionality. It\n+ contains the following flows to implement very basic IP host\n+ functionality.\n+

\n+\n+
    \n+
  • \n+

    \n+ For each dnat_and_snat NAT rule on a distributed\n+ logical routers or gateway routers with gateway port\n+ configured with options:gateway_mtu to a valid integer\n+ value M, a priority-160 flow with the match\n+ inport == LRP && REGBIT_PKT_LARGER\n+ && REGBIT_EGRESS_LOOPBACK == 0, where LRP\n+ is the logical router port and applies the following action for ipv4\n+ and ipv6 respectively:\n+

    \n+\n+ 
    \n+icmp4_error {\n+    icmp4.type = 3; /* Destination Unreachable. */\n+    icmp4.code = 4;  /* Frag Needed and DF was Set. */\n+    icmp4.frag_mtu = M;\n+    eth.dst = eth.src;\n+    eth.src = E;\n+    ip4.dst = ip4.src;\n+    ip4.src = I;\n+    ip.ttl = 255;\n+    REGBIT_EGRESS_LOOPBACK = 1;\n+    REGBIT_PKT_LARGER 0;\n+    outport = LRP;\n+    flags.loopback = 1;\n+    output;\n+};\n+\n+icmp6_error {\n+    icmp6.type = 2;\n+    icmp6.code = 0;\n+    icmp6.frag_mtu = M;\n+    eth.dst = eth.src;\n+    eth.src = E;\n+    ip6.dst = ip6.src;\n+    ip6.src = I;\n+    ip.ttl = 255;\n+    REGBIT_EGRESS_LOOPBACK = 1;\n+    REGBIT_PKT_LARGER 0;\n+    outport = LRP;\n+    flags.loopback = 1;\n+    output;\n+};\n+
    \n+

    \n+ where E and I are the NAT rule external mac\n+ and IP respectively.\n+

    \n+
    • \n+\n+
  • \n+

    \n+ For distributed logical routers or gateway routers with gateway port\n+ configured with options:gateway_mtu to a valid integer\n+ value, a priority-150 flow with the match inport ==\n+ LRP && REGBIT_PKT_LARGER &&\n+ REGBIT_EGRESS_LOOPBACK == 0, where LRP is the\n+ logical router port and applies the following action for ipv4\n+ and ipv6 respectively:\n+

    \n+\n+ 
    \n+icmp4_error {\n+    icmp4.type = 3; /* Destination Unreachable. */\n+    icmp4.code = 4;  /* Frag Needed and DF was Set. */\n+    icmp4.frag_mtu = M;\n+    eth.dst = E;\n+    ip4.dst = ip4.src;\n+    ip4.src = I;\n+    ip.ttl = 255;\n+    REGBIT_EGRESS_LOOPBACK = 1;\n+    REGBIT_PKT_LARGER 0;\n+    next(pipeline=ingress, table=0);\n+};\n+\n+icmp6_error {\n+    icmp6.type = 2;\n+    icmp6.code = 0;\n+    icmp6.frag_mtu = M;\n+    eth.dst = E;\n+    ip6.dst = ip6.src;\n+    ip6.src = I;\n+    ip.ttl = 255;\n+    REGBIT_EGRESS_LOOPBACK = 1;\n+    REGBIT_PKT_LARGER 0;\n+    next(pipeline=ingress, table=0);\n+};\n+
    \n+
    • \n+\n+
  • \n+

    \n+ For each NAT entry of a distributed logical router (with\n+ distributed gateway router port(s)) of type snat,\n+ a priority-120 flow with the match inport == P\n+ && ip4.src == A advances the packet to\n+ the next pipeline, where P is the distributed logical\n+ router port corresponding to the NAT entry (specified or inferred)\n+ and A is the external_ip set\n+ in the NAT entry. If A is an IPv6 address, then\n+ ip6.src is used for the match.\n+

    \n+\n+

    \n+ The above flow is required to handle the routing of the East/west NAT\n+ traffic.\n+

    \n+
    • \n+\n+
  • \n+

    \n+ For each BFD port the two following priority-110 flows are added\n+ to manage BFD traffic:\n+\n+

      \n+
    • \n+ if ip4.src or ip6.src is any IP\n+ address owned by the router port and udp.dst == 3784\n+ , the packet is advanced to the next pipeline stage.\n+
      • \n+\n+
    • \n+ if ip4.dst or ip6.dst is any IP\n+ address owned by the router port and udp.dst == 3784\n+ , the handle_bfd_msg action is executed.\n+
      • \n+
    \n+

    \n+
    • \n+\n+
  • \n+

    \n+ For each logical router port configured with DHCP relay the\n+ following priority-110 flows are added to manage the DHCP relay\n+ traffic:\n+\n+

      \n+
    • \n+

      \n+ if inport is lrp and ip4.src == 0.0.0.0\n+ and ip4.dst == 255.255.255.255 and\n+ ip4.frag == 0 and udp.src == 68\n+ and udp.dst == 67, the dhcp_relay_req_chk\n+ action is executed.\n+

      \n+\n+ 
      \n+                reg9[7] = dhcp_relay_req_chk(lrp_ip,\n+                                            dhcp_server_ip);next\n+
      \n+\n+

      \n+ if action is successful then, GIADDR in the dhcp header is\n+ updated with lrp ip and stores 1 into reg9[7] else stores 0\n+ into reg9[7].\n+

      \n+
      • \n+\n+
    • \n+ if ip4.src is DHCP server ip and ip4.dst\n+ is lrp IP and udp.src == 67 and\n+ udp.dst == 67, the packet is advanced to the next\n+ pipeline stage.\n+
      • \n+
    \n+

    \n+
    • \n+\n+
  • \n+

    \n+ L3 admission control: Priority-120 flows allows IGMP and MLD packets\n+ if the router has logical ports that have\n+ \n+ :mcast_flood='true'.\n+

    \n+
    • \n+\n+
  • \n+

    \n+ L3 admission control: A priority-100 flow drops packets that match\n+ any of the following:\n+

    \n+\n+
      \n+
    • \n+ ip4.src[28..31] == 0xe (multicast source)\n+
      • \n+
    • \n+ ip4.src == 255.255.255.255 (broadcast source)\n+
      • \n+
    • \n+ ip4.src == 127.0.0.0/8 || ip4.dst == 127.0.0.0/8\n+ (localhost source or destination)\n+
      • \n+
    • \n+ ip4.src == 0.0.0.0/8 || ip4.dst == 0.0.0.0/8 (zero\n+ network source or destination)\n+
      • \n+
    • \n+ ip4.src or ip6.src is any IP\n+ address owned by the router, unless the packet was recirculated\n+ due to egress loopback as indicated by\n+ REGBIT_EGRESS_LOOPBACK.\n+
      • \n+
    • \n+ ip4.src is the broadcast address of any IP network\n+ known to the router.\n+
      • \n+
    \n+
    • \n+\n+
  • \n+ A priority-100 flow parses DHCPv6 replies from IPv6 prefix\n+ delegation routers (udp.src == 547 &&\n+ udp.dst == 546). The handle_dhcpv6_reply\n+ is used to send IPv6 prefix delegation messages to the delegation\n+ router.\n+
    • \n+\n+
  • \n+ For each load balancer applied to this logical router configured\n+ with VIP template, a priority-100 flow matching\n+ ip4.dst or ip6.dst with the configured\n+ load balancer VIP and action next;.\n+ These flows avoid dropping the packet if the VIP is\n+ set to one of the router IPs.\n+
    • \n+\n+
  • \n+

    \n+ ICMP echo reply. These flows reply to ICMP echo requests received\n+ for the router's IP address. Let A be an IP address\n+ owned by a router port. Then, for each A that is\n+ an IPv4 address, a priority-90 flow matches on\n+ ip4.dst == A and\n+ icmp4.type == 8 && icmp4.code == 0\n+ (ICMP echo request). For each A that is an IPv6\n+ address, a priority-90 flow matches on\n+ ip6.dst == A and\n+ icmp6.type == 128 && icmp6.code == 0\n+ (ICMPv6 echo request). The port of the router that receives the\n+ echo request does not matter. Also, the ip.ttl of\n+ the echo request packet is not checked, so it complies with\n+ RFC 1812, section 4.2.2.9. Flows for ICMPv4 echo requests use the\n+ following actions:\n+

    \n+\n+ 
    \n+ip4.dst <-> ip4.src;\n+ip.ttl = 255;\n+icmp4.type = 0;\n+flags.loopback = 1;\n+next;\n+
    \n+\n+

    \n+ Flows for ICMPv6 echo requests use the following actions:\n+

    \n+\n+ 
    \n+ip6.dst <-> ip6.src;\n+ip.ttl = 255;\n+icmp6.type = 129;\n+flags.loopback = 1;\n+next;\n+
    \n+
    • \n+\n+
  • \n+

    \n+ Reply to ARP requests.\n+

    \n+\n+

    \n+ These flows reply to ARP requests for the router's own IP address.\n+ The ARP requests are handled only if the requestor's IP belongs\n+ to the same subnets of the logical router port.\n+ For each router port P that owns IP address A,\n+ which belongs to subnet S with prefix length L,\n+ and Ethernet address E, a priority-90 flow matches\n+ inport == P &&\n+ arp.spa == S/L && arp.op == 1\n+ && arp.tpa == A (ARP request) with the\n+ following actions:\n+

    \n+\n+ 
    \n+eth.dst = eth.src;\n+eth.src = xreg0[0..47];\n+arp.op = 2; /* ARP reply. */\n+arp.tha = arp.sha;\n+arp.sha = xreg0[0..47];\n+arp.tpa = arp.spa;\n+arp.spa = A;\n+outport = inport;\n+flags.loopback = 1;\n+output;\n+
    \n+\n+

    \n+ For the gateway port on a distributed logical router (where\n+ one of the logical router ports specifies a\n+ gateway chassis), the above flows are only\n+ programmed on the gateway port instance on the\n+ gateway chassis. This behavior avoids generation\n+ of multiple ARP responses from different chassis, and allows\n+ upstream MAC learning to point to the gateway chassis.\n+

    \n+\n+

    \n+ For the logical router port with the option\n+ reside-on-redirect-chassis set (which is centralized),\n+ the above flows are only programmed on the gateway port instance on\n+ the gateway chassis (if the logical router has a\n+ distributed gateway port). This behavior avoids generation\n+ of multiple ARP responses from different chassis, and allows\n+ upstream MAC learning to point to the gateway chassis.\n+

    \n+
    • \n+\n+
  • \n+

    \n+ Reply to IPv6 Neighbor Solicitations. These flows reply to\n+ Neighbor Solicitation requests for the router's own IPv6\n+ address and populate the logical router's mac binding table.\n+

    \n+\n+

    \n+ For each router port P that\n+ owns IPv6 address A, solicited node address S,\n+ and Ethernet address E, a priority-90 flow matches\n+ inport == P &&\n+ nd_ns && ip6.dst == {A, E} &&\n+ nd.target == A with the following actions:\n+

    \n+\n+ 
    \n+nd_na_router {\n+    eth.src = xreg0[0..47];\n+    ip6.src = A;\n+    nd.target = A;\n+    nd.tll = xreg0[0..47];\n+    outport = inport;\n+    flags.loopback = 1;\n+    output;\n+};\n+
    \n+\n+

    \n+ For the gateway port on a distributed logical router (where\n+ one of the logical router ports specifies a\n+ gateway chassis), the above flows replying to\n+ IPv6 Neighbor Solicitations are only programmed on the\n+ gateway port instance on the gateway chassis.\n+ This behavior avoids generation of multiple replies from\n+ different chassis, and allows upstream MAC learning to point\n+ to the gateway chassis.\n+

    \n+
    • \n+\n+
  • \n+

    \n+ These flows reply to ARP requests or IPv6 neighbor solicitation\n+ for the virtual IP addresses configured in the router for NAT\n+ (both DNAT and SNAT) or load balancing.\n+

    \n+\n+

    \n+ IPv4: For a configured NAT (both DNAT and SNAT) IP address or a\n+ load balancer IPv4 VIP A, for each router port\n+ P with Ethernet address E, a priority-90 flow\n+ matches arp.op == 1 && arp.tpa == A\n+ (ARP request) with the following actions:\n+

    \n+\n+ 
    \n+eth.dst = eth.src;\n+eth.src = xreg0[0..47];\n+arp.op = 2; /* ARP reply. */\n+arp.tha = arp.sha;\n+arp.sha = xreg0[0..47];\n+arp.tpa <-> arp.spa;\n+outport = inport;\n+flags.loopback = 1;\n+output;\n+
    \n+\n+

    \n+ IPv4: For a configured load balancer IPv4 VIP, a similar flow is\n+ added with the additional match inport == P\n+ if the VIP is reachable from any logical router port of the logical\n+ router.\n+

    \n+\n+

    \n+ If the router port P is a distributed gateway router\n+ port, then the is_chassis_resident(P) is\n+ also added in the match condition for the load balancer IPv4\n+ VIP A.\n+

    \n+\n+

    \n+ IPv6: For a configured NAT (both DNAT and SNAT) IP address or a\n+ load balancer IPv6 VIP A (if the VIP is reachable from any\n+ logical router port of the logical router), solicited node address\n+ S, for each router port P with\n+ Ethernet address E, a priority-90 flow matches\n+ inport == P && nd_ns &&\n+ ip6.dst == {A, S} &&\n+ nd.target == A\n+ with the following actions:\n+

    \n+\n+ 
    \n+eth.dst = eth.src;\n+nd_na {\n+    eth.src = xreg0[0..47];\n+    nd.tll = xreg0[0..47];\n+    ip6.src = A;\n+    nd.target = A;\n+    outport = inport;\n+    flags.loopback = 1;\n+    output;\n+}\n+
    \n+\n+

    \n+ If the router port P is a distributed gateway router\n+ port, then the is_chassis_resident(P)\n+ is also added in the match condition for the load balancer IPv6\n+ VIP A.\n+

    \n+\n+

    \n+ For the gateway port on a distributed logical router with NAT\n+ (where one of the logical router ports specifies a\n+ gateway chassis):\n+

    \n+\n+
      \n+
    • \n+ If the corresponding NAT rule cannot be handled in a\n+ distributed manner, then a priority-92 flow is programmed on\n+ the gateway port instance on the\n+ gateway chassis. A priority-91 drop flow is\n+ programmed on the other chassis when ARP requests/NS packets\n+ are received on the gateway port. This behavior avoids\n+ generation of multiple ARP responses from different chassis,\n+ and allows upstream MAC learning to point to the\n+ gateway chassis.\n+
      • \n+\n+
    • \n+

      \n+ If the corresponding NAT rule can be handled in a distributed\n+ manner, then this flow is only programmed on the gateway port\n+ instance where the logical_port specified in the\n+ NAT rule resides.\n+

      \n+\n+

      \n+ Some of the actions are different for this case, using the\n+ external_mac specified in the NAT rule rather\n+ than the gateway port's Ethernet address E:\n+

      \n+\n+ 
      \n+eth.src = external_mac;\n+arp.sha = external_mac;\n+
      \n+\n+

      \n+ or in the case of IPv6 neighbor solicition:\n+

      \n+\n+ 
      \n+eth.src = external_mac;\n+nd.tll = external_mac;\n+
      \n+\n+

      \n+ This behavior avoids generation of multiple ARP responses\n+ from different chassis, and allows upstream MAC learning to\n+ point to the correct chassis.\n+

      \n+
      • \n+
    \n+
    • \n+\n+
  • \n+ Priority-85 flows which drops the ARP and IPv6 Neighbor Discovery\n+ packets.\n+
    • \n+\n+
  • \n+

    \n+ A priority-84 flow explicitly allows IPv6 multicast traffic that is\n+ supposed to reach the router pipeline (i.e., router solicitation\n+ and router advertisement packets).\n+

    \n+
    • \n+\n+
  • \n+

    \n+ A priority-83 flow explicitly drops IPv6 multicast traffic that is\n+ destined to reserved multicast groups.\n+

    \n+
    • \n+\n+
  • \n+

    \n+ A priority-82 flow allows IP multicast traffic if\n+ :mcast_relay='true',\n+ otherwise drops it.\n+

    \n+
    • \n+\n+
  • \n+

    \n+ UDP port unreachable. Priority-80 flows generate ICMP port\n+ unreachable messages in reply to UDP datagrams directed to the\n+ router's IP address, except in the special case of gateways,\n+ which accept traffic directed to a router IP for load balancing\n+ and NAT purposes.\n+

    \n+\n+

    \n+ These flows should not match IP fragments with nonzero offset.\n+

    \n+
    • \n+\n+
  • \n+

    \n+ TCP reset. Priority-80 flows generate TCP reset messages in reply\n+ to TCP datagrams directed to the router's IP address, except in\n+ the special case of gateways, which accept traffic directed to a\n+ router IP for load balancing and NAT purposes.\n+

    \n+\n+

    \n+ These flows should not match IP fragments with nonzero offset.\n+

    \n+
    • \n+\n+
  • \n+

    \n+ Protocol or address unreachable. Priority-70 flows generate ICMP\n+ protocol or address unreachable messages for IPv4 and IPv6\n+ respectively in reply to packets directed to the router's IP\n+ address on IP protocols other than UDP, TCP, and ICMP, except in the\n+ special case of gateways, which accept traffic directed to a router\n+ IP for load balancing purposes.\n+

    \n+\n+

    \n+ These flows should not match IP fragments with nonzero offset.\n+

    \n+
    • \n+\n+
  • \n+ Drop other IP traffic to this router. These flows drop any other\n+ traffic destined to an IP address of this router that is not already\n+ handled by one of the flows above, which amounts to ICMP (other than\n+ echo requests) and fragments with nonzero offsets. For each IP address\n+ A owned by the router, a priority-60 flow matches\n+ ip4.dst == A or\n+ ip6.dst == A\n+ and drops the traffic. An exception is made and the above flow\n+ is not added if the router port's own IP address is used to SNAT\n+ packets passing through that router or if it is used as a\n+ load balancer VIP.\n+
    • \n+
\n+\n+

\n+ The flows above handle all of the traffic that might be directed to the\n+ router itself. The following flows (with lower priorities) handle the\n+ remaining traffic, potentially for forwarding:\n+

\n+\n+
    \n+
  • \n+ Drop Ethernet local broadcast. A priority-50 flow with match\n+ eth.bcast drops traffic destined to the local Ethernet\n+ broadcast address. By definition this traffic should not be forwarded.\n+
    • \n+\n+
  • \n+ Avoid ICMP time exceeded for multicast. A priority-32 flow with match\n+ ip.ttl == {0, 1} && !ip.later_frag &&\n+ (ip4.mcast || ip6.mcast) and actions drop; drops\n+ multicast packets whose TTL has expired without sending ICMP time\n+ exceeded.\n+
    • \n+\n+
  • \n+

    \n+ ICMP time exceeded. For each router port P, whose IP\n+ address is A, a priority-31 flow with match inport\n+ == P && ip.ttl == {0, 1} &&\n+ !ip.later_frag matches packets whose TTL has expired, with the\n+ following actions to send an ICMP time exceeded reply for IPv4 and\n+ IPv6 respectively:\n+

    \n+\n+ 
    \n+icmp4 {\n+    icmp4.type = 11; /* Time exceeded. */\n+    icmp4.code = 0;  /* TTL exceeded in transit. */\n+    ip4.dst = ip4.src;\n+    ip4.src = A;\n+    ip.ttl = 254;\n+    next;\n+};\n+\n+icmp6 {\n+    icmp6.type = 3; /* Time exceeded. */\n+    icmp6.code = 0;  /* TTL exceeded in transit. */\n+    ip6.dst = ip6.src;\n+    ip6.src = A;\n+    ip.ttl = 254;\n+    next;\n+};\n+
    \n+
    • \n+\n+
  • \n+ TTL discard. A priority-30 flow with match ip.ttl == {0,\n+ 1} and actions drop; drops other packets whose TTL\n+ has expired, that should not receive a ICMP error reply (i.e. fragments\n+ with nonzero offset).\n+
    • \n+\n+
  • \n+ Next table. A priority-0 flows match all packets that aren't already\n+ handled and uses actions next; to feed them to the next\n+ table.\n+
    • \n+
\n+\n+\n+

Ingress Table 4: DHCP Relay Request

\n+

\n+ This stage process the DHCP request packets on which\n+ dhcp_relay_req_chk action is applied in the IP input stage.\n+

\n+
    \n+
  • \n+

    \n+ A priority-100 logical flow is added for each logical router port\n+ configured with DHCP relay that matches inport is lrp\n+ and ip4.src == 0.0.0.0 and\n+ ip4.dst == 255.255.255.255 and udp.src == 68\n+ and udp.dst == 67 and reg9[7] == 1\n+ and applies following actions. If reg9[7] is set to 1\n+ then, dhcp_relay_req_chk action was successful.\n+

    \n+\n+ 
    \n+ip4.src=lrp ip;\n+ip4.dst=dhcp server ip;\n+udp.src = 67;\n+next;\n+
    \n+
    • \n+\n+
  • \n+

    \n+ A priority-1 logical flow is added for each logical router port\n+ configured with DHCP relay that matches inport is lrp\n+ and ip4.src == 0.0.0.0 and\n+ ip4.dst == 255.255.255.255 and udp.src == 68\n+ and udp.dst == 67 and reg9[7] == 0\n+ and drops the packet. If reg9[7] is set to 0 then,\n+ dhcp_relay_req_chk action was unsuccessful.\n+

    \n+
    • \n+\n+
  • \n+ A priority-0 flow that matches all packets to advance to the next\n+ table.\n+
    • \n+
\n+\n+

Ingress Table 5: UNSNAT

\n+\n+

\n+ This is for already established connections' reverse traffic.\n+ i.e., SNAT has already been done in egress pipeline and now the\n+ packet has entered the ingress pipeline as part of a reply. It is\n+ unSNATted here.\n+

\n+\n+

Ingress Table 5: UNSNAT on Gateway and Distributed Routers

\n+
    \n+
  • \n+

    \n+ If the Router (Gateway or Distributed) is configured with\n+ load balancers, then below lflows are added:\n+

    \n+\n+

    \n+ For each IPv4 address A defined as load balancer\n+ VIP with the protocol P (and the protocol port\n+ T if defined) is also present as an\n+ external_ip in the NAT table,\n+ a priority-120 logical flow is added with the match\n+ ip4 && ip4.dst == A &&\n+ P with the action next; to\n+ advance the packet to the next table. If the load balancer\n+ has protocol port B defined, then the match also has\n+ P.dst == B.\n+

    \n+\n+

    \n+ The above flows are also added for IPv6 load balancers.\n+

    \n+
    • \n+
\n+\n+

Ingress Table 5: UNSNAT on Gateway Routers

\n+\n+
    \n+
  • \n+

    \n+ If the Gateway router has been configured to force SNAT any\n+ previously DNATted packets to B, a priority-110 flow\n+ matches ip && ip4.dst == B or\n+ ip && ip6.dst == B\n+ with an action ct_snat; .\n+

    \n+\n+

    \n+ If the Gateway router is configured with\n+ lb_force_snat_ip=router_ip then for every logical router\n+ port P attached to the Gateway router with the router ip\n+ B, a priority-110 flow is added with the match\n+ inport == P &&\n+ ip4.dst == B or inport == P\n+ && ip6.dst == B with an action\n+ ct_snat; .\n+

    \n+\n+

    \n+ If the Gateway router has been configured to force SNAT any\n+ previously load-balanced packets to B, a priority-100 flow\n+ matches ip && ip4.dst == B or\n+ ip && ip6.dst == B\n+ with an action ct_snat; .\n+

    \n+\n+

    \n+ For each NAT configuration in the OVN Northbound database, that asks\n+ to change the source IP address of a packet from A to\n+ B, a priority-90 flow matches\n+ ip && ip4.dst == B or\n+ ip && ip6.dst == B\n+ with an action ct_snat; . If the NAT rule is of type\n+ dnat_and_snat and has stateless=true in the\n+ options, then the action would be next;.\n+

    \n+\n+

    \n+ A priority-0 logical flow with match 1 has actions\n+ next;.\n+

    \n+
    • \n+
\n+\n+

Ingress Table 5: UNSNAT on Distributed Routers

\n+\n+
    \n+
  • \n+

    \n+ For each configuration in the OVN Northbound database, that asks\n+ to change the source IP address of a packet from A to\n+ B, two priority-100 flows are added.\n+

    \n+\n+

    \n+ If the NAT rule cannot be handled in a distributed manner, then\n+ the below priority-100 flows are only programmed on the\n+ gateway chassis.\n+

    \n+\n+
      \n+
    • \n+

      \n+ The first flow matches ip &&\n+ ip4.dst == B && inport == GW\n+ or ip && ip6.dst == B &&\n+ inport == GW\n+ where GW is the distributed gateway port\n+ corresponding to the NAT rule (specified or inferred), with an\n+ action ct_snat; to unSNAT in the common\n+ zone. If the NAT rule is of type dnat_and_snat and has\n+ stateless=true in the options, then the action\n+ would be next;.\n+

      \n+\n+

      \n+ If the NAT entry is of type snat, then there is an\n+ additional match is_chassis_resident(cr-GW)\n+ where cr-GW is the chassis resident port of\n+ GW.\n+

      \n+
      • \n+
    \n+\n+

    \n+ A priority-0 logical flow with match 1 has actions\n+ next;.\n+

    \n+
    • \n+
\n+\n+

Ingress Table 6: POST USNAT

\n+\n+

\n+ This is to check whether the packet is already tracked in SNAT zone.\n+ It contains a priority-0 flow that simply moves traffic to the next\n+ table.\n+

\n+\n+

\n+ If the options:ct-commit-all is set to true the\n+ following two flows are configured matching on ip &&\n+ ct.new with an action flags.unsnat_new = 1; next; \n+ and ip && !ct.trk with an action\n+ flags.unsnat_not_tracked = 1; next; Which sets one of the\n+ flags that is used in later stages. There is extra match on both when\n+ there is configured DGP\n+ inport == DGP && is_chassis_resident(CHASSIS).\n+

\n+\n+

Ingress Table 7: DEFRAG

\n+\n+

\n+ This is to send packets to connection tracker for tracking and\n+ defragmentation. It contains a priority-0 flow that simply moves traffic\n+ to the next table.\n+

\n+\n+

\n+ For all load balancing rules that are configured in\n+ OVN_Northbound database for a Gateway router,\n+ a priority-100 flow is added for each configured virtual IP address\n+ VIP. For IPv4 VIPs the flow matches\n+ ip && ip4.dst == VIP. For IPv6\n+ VIPs, the flow matches ip && ip6.dst ==\n+ VIP. The flow applies the action ct_dnat;\n+ to send IP packets to the connection tracker for packet de-fragmentation\n+ and to dnat the destination IP for the committed connection before\n+ sending it to the next table.\n+

\n+\n+

\n+ If ECMP routes with symmetric reply are configured in the\n+ OVN_Northbound database for a gateway router, a priority-100\n+ flow is added for each router port on which symmetric replies are\n+ configured. The matching logic for these ports essentially reverses the\n+ configured logic of the ECMP route. So for instance, a route with a\n+ destination routing policy will instead match if the source IP address\n+ matches the static route's prefix. The flow uses the actions\n+ chk_ecmp_nh_mac(); ct_next or\n+ chk_ecmp_nh(); ct_next to send IP packets to table\n+ 76 or to table 77 in order to check if source\n+ info are already stored by OVN and then to the connection tracker for\n+ packet de-fragmentation and tracking before sending it to the next table.\n+

\n+\n+

\n+ If load balancing rules are configured in OVN_Northbound\n+ database for a Gateway router, a priority 50 flow that matches\n+ icmp || icmp6 with an action of ct_dnat;,\n+ this allows potentially related ICMP traffic to pass through CT.\n+

\n+\n+

\n+ If the options:ct-commit-all is set to true\n+ the following flow is configured matching on ip &&\n+ (!ct.trk || !ct.rpl) with an action ct_next(dnat);.\n+ There is extra match when the LR is configured as DGP\n+ inport == DGP && is_chassis_resident(CHASSIS).\n+

\n+\n+

Ingress Table 8: Connection tracking field extraction

\n+\n+

\n+ This table extracts connection tracking fields for new connections\n+ and stores them in registers for use by subsequent load balancing\n+ stages.\n+

\n+\n+
    \n+
  • \n+

    \n+ For all new connections (ct.new), a priority-100 flow\n+ extracts the connection tracking protocol and destination port\n+ information into registers:\n+

    \n+\n+ 
    \n+reg1[16..23] = ct_proto();\n+reg1[0..15] = ct_tp_dst();\n+next;\n+
    \n+\n+

    \n+ This stores the connection tracking destination port in\n+ REG_CT_TP_DST (reg1[0..15]) and the protocol\n+ in REG_CT_PROTO (reg1[16..23]).\n+

    \n+
    • \n+\n+
  • \n+ A priority-0 flow that matches all packets and advances to the\n+ next table with action next;.\n+
    • \n+
\n+\n+

Ingress Table 9: Load balancing affinity check

\n+\n+

\n+ Load balancing affinity check table contains the following\n+ logical flows:\n+

\n+\n+
    \n+
  • \n+ For all the configured load balancing rules for a logical router where\n+ a positive affinity timeout is specified in options\n+ column, that includes a L4 port PORT of protocol\n+ P and IPv4 or IPv6 address VIP, a priority-100\n+ flow that matches on ct.new && ip &&\n+ ip.dst == VIP && REG_CT_PROTO == P_NUM\n+ && REG_CT_TP_DST == PORT (xxreg0 ==\n+ VIP in the IPv6 case) with an action of\n+ reg0 = ip.dst; reg9[16..31] = P.dst; reg9[6] = chk_lb_aff();\n+ next; (xxreg0 == ip6.dst in the IPv6\n+ case), where P_NUM is the protocol number (6 for TCP, 17\n+ for UDP, 132 for SCTP).\n+
    • \n+\n+
  • \n+ A priority 0 flow is added which matches on all packets and applies\n+ the action next;.\n+
    • \n+
\n+\n+

Ingress Table 10: DNAT

\n+\n+

\n+ Packets enter the pipeline with destination IP address that needs to\n+ be DNATted from a virtual IP address to a real IP address. Packets\n+ in the reverse direction needs to be unDNATed.\n+

\n+\n+

Ingress Table 8: Load balancing DNAT rules

\n+\n+

\n+ Following load balancing DNAT flows are added for Gateway router or\n+ Router with gateway port. These flows are programmed only on the\n+ gateway chassis. These flows do not get programmed for\n+ load balancers with IPv6 VIPs.\n+

\n+\n+
    \n+
  • \n+ For all the configured load balancing rules for a logical router where\n+ a positive affinity timeout is specified in options\n+ column, that includes a L4 port PORT of protocol\n+ P and IPv4 or IPv6 address VIP, a priority-150\n+ flow that matches on reg9[6] == 1 && ct.new &&\n+ ip && ip.dst == VIP && REG_CT_PROTO ==\n+ P_NUM &&\n+ REG_CT_TP_DST == PORT with an action of\n+ ct_lb_mark(args) , where args\n+ contains comma separated IP addresses (and optional port numbers)\n+ to load balance to, and P_NUM is the protocol number\n+ (6 for TCP, 17 for UDP, 132 for SCTP). The address family of the IP\n+ addresses of args is the same as the address family of\n+ VIP.\n+
    • \n+\n+
  • \n+ If controller_event has been enabled for all the configured load\n+ balancing rules for a Gateway router or Router with gateway port\n+ in OVN_Northbound database that does not have configured\n+ backends, a priority-130 flow is added to trigger ovn-controller events\n+ whenever the chassis receives a packet for that particular VIP.\n+ If event-elb meter has been previously created, it will be\n+ associated to the empty_lb logical flow\n+
    • \n+\n+
  • \n+

    \n+ For all the configured load balancing rules for a Gateway router or\n+ Router with gateway port in OVN_Northbound database that\n+ includes a L4 port PORT of protocol P and IPv4\n+ or IPv6 address VIP, a priority-120 flow that matches on\n+ ct.new && !ct.rel && ip && ip.dst ==\n+ VIP && REG_CT_PROTO == P_NUM &&\n+ REG_CT_TP_DST == PORT with an action of\n+ ct_lb_mark(args), where args contains\n+ comma separated IPv4 or IPv6 addresses (and optional port numbers) to\n+ load balance to, and P_NUM is the protocol number\n+ (6 for TCP, 17 for UDP, 132 for SCTP). If the router is configured\n+ to force SNAT any\n+ load-balanced packets, the above action will be replaced by\n+ flags.force_snat_for_lb = 1; ct_lb_mark(args;\n+ force_snat);.\n+ If the load balancing rule is configured with skip_snat\n+ set to true, the above action will be replaced by\n+ flags.skip_snat_for_lb = 1; ct_lb_mark(args;\n+ skip_snat);.\n+ If health check is enabled, then\n+ args will only contain those endpoints whose service\n+ monitor status entry in OVN_Southbound db is\n+ either online or empty.\n+

    \n+\n+
    • \n+\n+
  • \n+

    \n+ For all the configured load balancing rules for a router in\n+ OVN_Northbound database that includes just an IP address\n+ VIP to match on, a priority-110 flow that matches on\n+ ct.new && !ct.rel && ip4 && ip.dst ==\n+ VIP with an action of\n+ ct_lb_mark(args), where args contains\n+ comma separated IPv4 or IPv6 addresses. If the router is configured\n+ to force SNAT any load-balanced packets, the above action will be\n+ replaced by flags.force_snat_for_lb = 1;\n+ ct_lb_mark(args; force_snat);.\n+ If the load balancing rule is configured with skip_snat\n+ set to true, the above action will be replaced by\n+ flags.skip_snat_for_lb = 1; ct_lb_mark(args;\n+ skip_snat);.\n+

    \n+\n+

    \n+ The previous table lr_in_defrag sets the register\n+ reg0 (or xxreg0 for IPv6) and does\n+ ct_dnat. Hence for established traffic, this\n+ table just advances the packet to the next stage.\n+

    \n+
    • \n+\n+
  • \n+ If the load balancer is created with --reject option and\n+ it has no active backends, a TCP reset segment (for tcp) or an ICMP\n+ port unreachable packet (for all other kind of traffic) will be sent\n+ whenever an incoming packet is received for this load-balancer.\n+ Please note using --reject option will disable\n+ empty_lb SB controller event for this load balancer.\n+
    • \n+\n+
  • \n+

    \n+ For the related traffic, a priority 50 flow that matches\n+ ct.rel && !ct.est && !ct.new \n+ with an action of ct_commit_nat;, if the router\n+ has load balancer assigned to it. Along with two priority 70 flows\n+ that match skip_snat and force_snat\n+ flags, setting the flags.force_snat_for_lb = 1 or\n+ flags.skip_snat_for_lb = 1 accordingly.\n+

    \n+
    • \n+
  • \n+

    \n+ For the established traffic, a priority 50 flow that matches\n+ ct.est && !ct.rel && !ct.new &&\n+ ct_mark.natted with an action of next;,\n+ if the router has load balancer assigned to it. Along with two\n+ priority 70 flows that match skip_snat and\n+ force_snat flags, setting the\n+ flags.force_snat_for_lb = 1 or\n+ flags.skip_snat_for_lb = 1 accordingly.\n+

    \n+
    • \n+
\n+\n+

Ingress Table 9: DNAT on Gateway Routers

\n+\n+
    \n+
  • \n+ For each configuration in the OVN Northbound database, that asks\n+ to change the destination IP address of a packet from A to\n+ B, a priority-100 flow matches ip &&\n+ ip4.dst == A or ip &&\n+ ip6.dst == A with an action\n+ flags.loopback = 1; ct_dnat(B);. If the\n+ Gateway router is configured to force SNAT any DNATed packet,\n+ the above action will be replaced by\n+ flags.force_snat_for_dnat = 1; flags.loopback = 1;\n+ ct_dnat(B);. If the NAT rule is of type\n+ dnat_and_snat and has stateless=true in the\n+ options, then the action would be ip4/6.dst=\n+ (B).\n+\n+

    \n+ If the NAT rule has allowed_ext_ips configured, then\n+ there is an additional match ip4.src == allowed_ext_ips\n+ . Similarly, for IPV6, match would be ip6.src ==\n+ allowed_ext_ips.\n+

    \n+\n+

    \n+ If the NAT rule has exempted_ext_ips set, then\n+ there is an additional flow configured at priority 101.\n+ The flow matches if source ip is an exempted_ext_ip\n+ and the action is next; . This flow is used to\n+ bypass the ct_dnat action for a packet originating from\n+ exempted_ext_ips.\n+

    \n+\n+

    \n+ For each configuration in the OVN Northbound database, that asks\n+ to change the destination IP address of a packet from A\n+ to B, match M and priority P,\n+ a logical flow that matches ip && ip4.dst ==\n+ A or ip && ip6.dst == A\n+ && (M) with an action\n+ flags.loopback = 1; ct_dnat(B);.\n+ The priority of the flow is calculated based as\n+ 300 + P. If the Gateway router is\n+ configured to force SNAT any DNATed packet, the above action will\n+ be replaced by flags.force_snat_for_dnat = 1;\n+ flags.loopback = 1; ct_dnat(B);. If the NAT rule\n+ is of type dnat_and_snat and has stateless=true in the\n+ options, then the action would be ip4/6.dst=\n+ (B).\n+

    \n+
    • \n+\n+
  • \n+

    \n+ If the options:ct-commit-all is set to true\n+ the following flow is configured matching on ip &&\n+ ct.new with an action ct_commit_to_zone(dnat);.\n+

    \n+
    • \n+\n+
  • \n+ A priority-0 logical flow with match 1 has actions\n+ next;.\n+
    • \n+
\n+\n+

Ingress Table 9: DNAT on Distributed Routers

\n+\n+

\n+ On distributed routers, the DNAT table only handles packets\n+ with destination IP address that needs to be DNATted from a\n+ virtual IP address to a real IP address. The unDNAT processing\n+ in the reverse direction is handled in a separate table in the\n+ egress pipeline.\n+

\n+\n+
    \n+
  • \n+

    \n+ For each configuration in the OVN Northbound database, that asks\n+ to change the destination IP address of a packet from A to\n+ B, a priority-100 flow matches ip &&\n+ ip4.dst == B && inport == GW,\n+ where GW is the logical router gateway port corresponding\n+ to the NAT rule (specified or inferred), with an action\n+ ct_dnat(B);. The match will include\n+ ip6.dst == B in the IPv6 case.\n+ If the NAT rule is of type dnat_and_snat and has\n+ stateless=true in the options, then the action\n+ would be ip4/6.dst=(B).\n+

    \n+\n+

    \n+ If the NAT rule cannot be handled in a distributed manner, then\n+ the priority-100 flow above is only programmed on the\n+ gateway chassis.\n+

    \n+\n+

    \n+ If the NAT rule has allowed_ext_ips configured, then\n+ there is an additional match ip4.src == allowed_ext_ips\n+ . Similarly, for IPV6, match would be ip6.src ==\n+ allowed_ext_ips.\n+

    \n+\n+

    \n+ If the NAT rule has exempted_ext_ips set, then\n+ there is an additional flow configured at priority 101.\n+ The flow matches if source ip is an exempted_ext_ip\n+ and the action is next; . This flow is used to\n+ bypass the ct_dnat action for a packet originating from\n+ exempted_ext_ips.\n+

    \n+\n+

    \n+ If the options:ct-commit-all is set to true\n+ the following flow is configured matching on ip &&\n+ ct.new && inport == DGP &&\n+ is_chassis_resident(CHASSIS) with an action\n+ ct_commit_to_zone(dnat);.\n+

    \n+\n+

    \n+ A priority-0 logical flow with match 1 has actions\n+ next;.\n+

    \n+
    • \n+
\n+\n+

Ingress Table 11: Load balancing affinity learn

\n+\n+

\n+ Load balancing affinity learn table contains the following\n+ logical flows:\n+

\n+\n+
    \n+
  • \n+ For all the configured load balancing rules for a logical router where\n+ a positive affinity timeout T is specified in options\n+ column, that includes a L4 port PORT of protocol\n+ P and IPv4 or IPv6 address VIP, a priority-100\n+ flow that matches on reg9[6] == 0 && ct.new &&\n+ ip && reg0 == VIP && P &&\n+ reg9[16..31] == PORT (xxreg0 ==\n+ VIP in the IPv6 case) with an action of\n+ commit_lb_aff(vip = VIP:PORT, backend =\n+ backend ip: backend port, proto = P,\n+ timeout = T);.\n+
    • \n+\n+
  • \n+ A priority 0 flow is added which matches on all packets and applies\n+ the action next;.\n+
    • \n+
\n+\n+

Ingress Table 12: ECMP symmetric reply processing

\n+
    \n+
  • \n+ If ECMP routes with symmetric reply are configured in the\n+ OVN_Northbound database for a gateway router, a\n+ priority-100 flow is added for each router port on which symmetric\n+ replies are configured. The matching logic for these ports essentially\n+ reverses the configured logic of the ECMP route. So for instance, a\n+ route with a destination routing policy will instead match if the\n+ source IP address matches the static route's prefix. The flow uses\n+ the action ct_commit { ct_label.ecmp_reply_eth = eth.src;\"\n+ \" ct_mark.ecmp_reply_port = K;}; commit_ecmp_nh(); next;\n+ to commit the connection and storing eth.src and\n+ the ECMP reply port binding tunnel key K in the\n+ ct_label and the traffic pattern to table\n+ 76 or 77.\n+
    • \n+
\n+\n+

Ingress Table 13: IPv6 ND RA option processing

\n+\n+
    \n+
  • \n+

    \n+ A priority-50 logical flow is added for each logical router port\n+ configured with IPv6 ND RA options which matches IPv6 ND Router\n+ Solicitation packet and applies the action\n+ put_nd_ra_opts and advances the packet to the next\n+ table.\n+

    \n+\n+ 
    \n+reg0[5] = put_nd_ra_opts(options);next;\n+
    \n+\n+

    \n+ For a valid IPv6 ND RS packet, this transforms the packet into an\n+ IPv6 ND RA reply and sets the RA options to the packet and stores 1\n+ into reg0[5]. For other kinds of packets, it just stores 0 into\n+ reg0[5]. Either way, it continues to the next table.\n+

    \n+
    • \n+\n+
  • \n+ A priority-0 logical flow with match 1 has actions\n+ next;.\n+
    • \n+
\n+\n+

Ingress Table 14: IPv6 ND RA responder

\n+\n+

\n+ This table implements IPv6 ND RA responder for the IPv6 ND RA replies\n+ generated by the previous table.\n+

\n+\n+
    \n+
  • \n+

    \n+ A priority-50 logical flow is added for each logical router port\n+ configured with IPv6 ND RA options which matches IPv6 ND RA\n+ packets and reg0[5] == 1 and responds back to the\n+ inport after applying these actions.\n+ If reg0[5] is set to 1, it means that the action\n+ put_nd_ra_opts was successful.\n+

    \n+\n+ 
    \n+eth.dst = eth.src;\n+eth.src = E;\n+ip6.dst = ip6.src;\n+ip6.src = I;\n+outport = P;\n+flags.loopback = 1;\n+output;\n+
    \n+\n+

    \n+ where E is the MAC address and I is the IPv6\n+ link local address of the logical router port.\n+

    \n+\n+

    \n+ (This terminates packet processing in ingress pipeline; the packet\n+ does not go to the next ingress table.)\n+

    \n+
    • \n+\n+
  • \n+ A priority-0 logical flow with match 1 has actions\n+ next;.\n+
    • \n+
\n+\n+

Ingress Table 15: IP Routing Pre

\n+\n+

\n+ If a packet arrived at this table from Logical Router Port P\n+ which has options:route_table value set, a logical flow with\n+ match inport == \"P\" with priority 100 and action\n+ setting unique-generated per-datapath 32-bit value (non-zero) in OVS\n+ register 7. This register's value is checked in next table. If packet\n+ didn't match any configured inport (<main> route table),\n+ register 7 value is set to 0.\n+

\n+\n+

\n+ This table contains the following logical flows:\n+

\n+\n+
    \n+
  • \n+

    \n+ Priority-100 flow with match inport == \"LRP_NAME\" value\n+ and action, which set route table identifier in reg7.\n+

    \n+\n+

    \n+ A priority-0 logical flow with match 1 has actions\n+ reg7 = 0; next;.\n+

    \n+
    • \n+
\n+\n+

Ingress Table 16: IP Routing

\n+\n+

\n+ A packet that arrives at this table is an IP packet that should be\n+ routed to the address in ip4.dst or\n+ ip6.dst. This table implements IP routing, setting\n+ reg0 (or xxreg0 for IPv6) to the next-hop IP\n+ address (leaving ip4.dst or ip6.dst, the\n+ packet's final destination, unchanged) and advances to the next\n+ table for ARP resolution. It also sets reg1 (or\n+ xxreg1) to the IP address owned by the selected router\n+ port (ingress table ARP Request will generate an ARP\n+ request, if needed, with reg0 as the target protocol\n+ address and reg1 as the source protocol address).\n+

\n+\n+

\n+ For ECMP routes, i.e. multiple static routes with same policy and\n+ prefix but different nexthops, the above actions are deferred to next\n+ table. This table, instead, is responsible for determine the ECMP\n+ group id and select a member id within the group based on 5-tuple\n+ hashing. It stores group id in reg8[0..15] and member id in\n+ reg8[16..31]. This step is skipped with a priority-10300\n+ rule if the traffic going out the ECMP route is reply traffic, and the\n+ ECMP route was configured to use symmetric replies. Instead, the stored\n+ values in conntrack is used to choose the destination. The\n+ ct_label.ecmp_reply_eth tells the destination MAC address to\n+ which the packet should be sent. The ct_mark.ecmp_reply_port\n+ tells the logical router port on which the packet should be sent. These\n+ values saved to the conntrack fields when the initial ingress traffic is\n+ received over the ECMP route and committed to conntrack.\n+ If REGBIT_KNOWN_ECMP_NH is set, the priority-10300\n+ flows in this stage set the outport, while the\n+ eth.dst is set by flows at the ARP/ND Resolution stage.\n+

\n+\n+

\n+ This table contains the following logical flows:\n+

\n+\n+
    \n+
  • \n+

    \n+ Priority-10550 flow that drops IPv6 Router Solicitation/Advertisement\n+ packets that were not processed in previous tables.\n+

    \n+
    • \n+\n+
  • \n+

    \n+ Priority-10550 flows that drop IGMP and MLD packets with source MAC\n+ address owned by the router. These are used to prevent looping\n+ statically forwarded IGMP and MLD packets for which TTL is not\n+ decremented (it is always 1).\n+

    \n+
    • \n+\n+
  • \n+

    \n+ Priority-10500 flows that match IP multicast traffic destined to\n+ groups registered on any of the attached switches and sets\n+ outport to the associated multicast group that will\n+ eventually flood the traffic to all interested attached logical\n+ switches. The flows also decrement TTL.\n+

    \n+
    • \n+\n+
  • \n+

    \n+ Priority-10460 flows that match IGMP and MLD control packets,\n+ set outport to the MC_STATIC\n+ multicast group, which ovn-northd\n+ populates with the logical ports that have\n+ \n+ :mcast_flood='true'. If no router ports are configured\n+ to flood multicast traffic the packets are dropped.\n+

    \n+
    • \n+\n+
  • \n+

    \n+ Priority-10450 flow that matches unregistered IP multicast traffic\n+ decrements TTL and sets outport to the\n+ MC_STATIC multicast group, which ovn-northd\n+ populates with the logical ports that have\n+ \n+ :mcast_flood='true'. If no router ports are configured\n+ to flood multicast traffic the packets are dropped.\n+

    \n+
    • \n+\n+
  • \n+

    \n+ IPv4 routing table. For each route to IPv4 network N with\n+ netmask M, on router port P with IP address\n+ A and Ethernet\n+ address E, a logical flow with match ip4.dst ==\n+ N/M, whose priority is the number of\n+ 1-bits in M, has the following actions:\n+

    \n+\n+ 
    \n+ip.ttl--;\n+reg8[0..15] = 0;\n+reg0 = G;\n+reg1 = A;\n+eth.src = E;\n+outport = P;\n+flags.loopback = 1;\n+next;\n+
    \n+\n+

    \n+ (Ingress table 1 already verified that ip.ttl--; will\n+ not yield a TTL exceeded error.)\n+

    \n+\n+

    \n+ If the route has a gateway, G is the gateway IP address.\n+ Instead, if the route is from a configured static route, G\n+ is the next hop IP address. Else it is ip4.dst.\n+

    \n+
    • \n+\n+
  • \n+

    \n+ IPv6 routing table. For each route to IPv6 network\n+ N with netmask M, on router port\n+ P with IP address A and Ethernet address\n+ E, a logical flow with match in CIDR notation\n+ ip6.dst == N/M,\n+ whose priority is the integer value of M, has the\n+ following actions:\n+

    \n+\n+ 
    \n+ip.ttl--;\n+reg8[0..15] = 0;\n+xxreg0 = G;\n+xxreg1 = A;\n+eth.src = E;\n+outport = inport;\n+flags.loopback = 1;\n+next;\n+
    \n+\n+

    \n+ (Ingress table 1 already verified that ip.ttl--; will\n+ not yield a TTL exceeded error.)\n+

    \n+\n+

    \n+ If the route has a gateway, G is the gateway IP address.\n+ Instead, if the route is from a configured static route, G\n+ is the next hop IP address. Else it is ip6.dst.\n+

    \n+\n+

    \n+ If the address A is in the link-local scope, the\n+ route will be limited to sending on the ingress port.\n+

    \n+\n+

    \n+ For each static route the reg7 == id && is\n+ prefixed in logical flow match portion. For routes with\n+ route_table value set a unique non-zero id is used.\n+ For routes within <main> route table (no route\n+ table set), this id value is 0.\n+

    \n+

    \n+ For each connected route (route to the LRP's subnet CIDR)\n+ the logical flow match portion has no\n+ reg7 == id && prefix to have route to LRP's\n+ subnets in all routing tables.\n+

    \n+
    • \n+\n+
  • \n+

    \n+ For ECMP routes, they are grouped by policy and prefix. An unique id\n+ (non-zero) is assigned to each group, and each member is also\n+ assigned an unique id (non-zero) within each group.\n+

    \n+\n+

    \n+ For each IPv4/IPv6 ECMP group with group id GID and member\n+ ids MID1, MID2, ..., a logical flow with match\n+ in CIDR notation ip4.dst == N/M,\n+ or ip6.dst == N/M, whose priority\n+ is the integer value of M, has the following actions:\n+

    \n+\n+ 
    \n+ip.ttl--;\n+flags.loopback = 1;\n+reg8[0..15] = GID;\n+reg8[16..31] = select(MID1, MID2, ...);\n+
    \n+

    \n+ However, when there is only one route in an ECMP group, group actions\n+ will be:\n+

    \n+\n+ 
    \n+ip.ttl--;\n+flags.loopback = 1;\n+reg8[0..15] = GID;\n+reg8[16..31] = MID1);\n+
    \n+
    • \n+\n+
  • \n+ A priority-0 logical flow that matches all packets not already handled\n+ (match 1) and drops them (action drop;).\n+
    • \n+
\n+\n+

Ingress Table 17: IP_ROUTING_ECMP

\n+\n+

\n+ This table implements the second part of IP routing for ECMP routes\n+ following the previous table. If a packet matched a ECMP group in the\n+ previous table, this table matches the group id and member id stored\n+ from the previous table, setting reg0\n+ (or xxreg0 for IPv6) to the next-hop IP address\n+ (leaving ip4.dst or ip6.dst, the\n+ packet's final destination, unchanged) and advances to the next\n+ table for ARP resolution. It also sets reg1 (or\n+ xxreg1) to the IP address owned by the selected router\n+ port (ingress table ARP Request will generate an ARP\n+ request, if needed, with reg0 as the target protocol\n+ address and reg1 as the source protocol address).\n+

\n+\n+

\n+ This processing is skipped for reply traffic being sent out of an ECMP\n+ route if the route was configured to use symmetric replies.\n+

\n+\n+

\n+ This table contains the following logical flows:\n+

\n+\n+
    \n+
  • \n+

    \n+ A priority-150 flow that matches reg8[0..15] == 0\n+ with action next; directly bypasses packets of non-ECMP\n+ routes.\n+

    \n+
    • \n+\n+
  • \n+

    \n+ For each member with ID MID in each ECMP group with ID\n+ GID, a priority-100 flow with match\n+ reg8[0..15] == GID && reg8[16..31] == MID\n+ has following actions:\n+

    \n+\n+ 
    \n+[xx]reg0 = G;\n+[xx]reg1 = A;\n+eth.src = E;\n+outport = P;\n+
    \n+
    • \n+\n+
  • \n+ A priority-0 logical flow that matches all packets not already handled\n+ (match 1) and drops them (action drop;).\n+
    • \n+
\n+\n+

Ingress Table 18: Router policies

\n+

\n+ This table adds flows for the logical router policies configured\n+ on the logical router. Please see the\n+ OVN_Northbound database Logical_Router_Policy\n+ table documentation in ovn-nb for supported actions.\n+

\n+\n+
    \n+
  • \n+

    \n+ For each router policy configured on the logical router, a\n+ logical flow is added with specified priority, match and\n+ actions.\n+

    \n+
    • \n+\n+
  • \n+

    \n+ If the policy action is reroute with 2 or more nexthops\n+ defined, then the logical flow is added with the following actions:\n+

    \n+\n+ 
    \n+reg8[0..15] = GID;\n+reg8[16..31] = select(1,..n);\n+
    \n+\n+

    \n+ where GID is the ECMP group id generated by\n+ ovn-northd for this policy and n\n+ is the number of nexthops. select action\n+ selects one of the nexthop member id, stores it in the register\n+ reg8[16..31] and advances the packet to the\n+ next stage.\n+

    \n+
    • \n+\n+
  • \n+

    \n+ If the policy action is reroute with just one nexhop,\n+ then the logical flow is added with the following actions:\n+

    \n+\n+ 
    \n+[xx]reg0 = H;\n+eth.src = E;\n+outport = P;\n+reg8[0..15] = 0;\n+flags.loopback = 1;\n+next;\n+
    \n+\n+

    \n+ where H is the nexthop defined in the\n+ router policy, E is the ethernet address of the\n+ logical router port from which the nexthop is\n+ reachable and P is the logical router port from\n+ which the nexthop is reachable.\n+

    \n+
    • \n+\n+
  • \n+

    \n+ If a router policy has the option pkt_mark=m\n+ set and if the action is not drop, then the action also\n+ includes pkt.mark = m to mark the packet\n+ with the marker m.\n+

    \n+
    • \n+
\n+\n+

Ingress Table 19: ECMP handling for router policies

\n+

\n+ This table handles the ECMP for the router policies configured\n+ with multiple nexthops.\n+

\n+\n+
    \n+
  • \n+

    \n+ A priority-150 flow is added to advance the packet to the next stage\n+ if the ECMP group id register reg8[0..15] is 0.\n+

    \n+
    • \n+\n+
  • \n+

    \n+ For each ECMP reroute router policy with multiple nexthops,\n+ a priority-100 flow is added for each nexthop H\n+ with the match reg8[0..15] == GID &&\n+ reg8[16..31] == M where GID\n+ is the router policy group id generated by ovn-northd\n+ and M is the member id of the nexthop H\n+ generated by ovn-northd. The following actions are added\n+ to the flow:\n+

    \n+\n+ 
    \n+[xx]reg0 = H;\n+eth.src = E;\n+outport = P\n+\"flags.loopback = 1; \"\n+\"next;\"\n+
    \n+\n+

    \n+ where H is the nexthop defined in the\n+ router policy, E is the ethernet address of the\n+ logical router port from which the nexthop is\n+ reachable and P is the logical router port from\n+ which the nexthop is reachable.\n+

    \n+
    • \n+\n+
  • \n+ A priority-0 logical flow that matches all packets not already handled\n+ (match 1) and drops them (action drop;).\n+
    • \n+
\n+\n+

Ingress Table 20: DHCP Relay Response Check

\n+

\n+ This stage process the DHCP response packets coming from the DHCP server.\n+

\n+\n+
    \n+
  • \n+

    \n+ A priority 100 logical flow is added for each logical router port\n+ configured with DHCP relay that matches ip4.src is\n+ DHCP server ip and ip4.dst is lrp IP and\n+ ip4.frag == 0 and udp.src == 67 and\n+ udp.dst == 67 and applies dhcp_relay_resp_chk\n+ action. Original destination ip is stored in reg2.\n+

    \n+\n+ 
    \n+        reg9[8] = dhcp_relay_resp_chk(lrp_ip,\n+                                      dhcp_server_ip);next\n+
    \n+\n+

    \n+ if action is successful then, dest mac and dest IP addresses are\n+ updated in the packet and stores 1 into reg9[8] else stores 0 into\n+ reg9[8].\n+

    \n+
    • \n+\n+
  • \n+ A priority-0 flow that matches all packets to advance to the next\n+ table.\n+
    • \n+
\n+\n+

Ingress Table 21: DHCP Relay Response

\n+

\n+ This stage process the DHCP response packets on which\n+ dhcp_relay_resp_chk action is applied in the previous stage.\n+

\n+
    \n+
  • \n+

    \n+ A priority 100 logical flow is added for each logical router port\n+ configured with DHCP relay that matches ip4.src is\n+ DHCP server ip and reg2 is lrp IP and\n+ udp.src == 67 and udp.dst == 67\n+ and reg9[8] == 1 and applies following actions. If\n+ reg9[8] is set to 1 then,\n+ dhcp_relay_resp_chk was successful.\n+

    \n+\n+ 
    \n+ip4.src = lrp ip;\n+udp.dst = 68;\n+outport = lrp port;\n+output;\n+
    \n+
    • \n+\n+
  • \n+

    \n+ A priority 1 logical flow is added for the logical router port\n+ on which DHCP relay is enabled that matches ip4.src\n+ is DHCP server ip and reg2 is lrp IP and\n+ udp.src == 67 and udp.dst == 67\n+ and reg9[8] == 0 and drops the packet. If\n+ reg9[8] is set to 0 then,\n+ dhcp_relay_resp_chk was unsuccessful.\n+

    \n+
    • \n+\n+
  • \n+ A priority-0 flow that matches all packets to advance to the next\n+ table.\n+
    • \n+
\n+\n+

Ingress Table 22: ARP/ND Resolution

\n+\n+

\n+ Any packet that reaches this table is an IP packet whose next-hop\n+ IPv4 address is in reg0 or IPv6 address is in\n+ xxreg0. (ip4.dst or\n+ ip6.dst contains the final destination.) This table\n+ resolves the IP address in reg0 (or\n+ xxreg0) into an output port in outport\n+ and an Ethernet address in eth.dst, using the\n+ following flows:\n+

\n+\n+
    \n+
  • \n+

    \n+ A priority-500 flow that matches IP multicast traffic that was\n+ allowed in the routing pipeline. For this kind of traffic the\n+ outport was already set so the flow just advances to\n+ the next table.\n+

    \n+
    • \n+\n+
  • \n+

    \n+ Priority-200 flows that match ECMP reply traffic for the routes\n+ configured to use symmetric replies, with actions\n+ push(xxreg1); xxreg1 = ct_label; eth.dst = xxreg1[32..79]; pop(xxreg1); next;.\n+ xxreg1 is used here to avoid masked access to ct_label,\n+ to make the flow HW-offloading friendly.\n+

    \n+
    • \n+\n+
  • \n+

    \n+ Static MAC bindings. MAC bindings can be known statically based on\n+ data in the OVN_Northbound database. For router ports\n+ connected to logical switches, MAC bindings can be known statically\n+ from the addresses column in the\n+ Logical_Switch_Port table. (Note: the flow is not\n+ installed for IPs of logical switch ports of type\n+ virtual, and dynamic MAC binding is used for those IPs\n+ instead, so that virtual parent failover does not depend on \n+ ovn-northd, to achieve better failover performance.) For\n+ router ports connected to other logical routers, MAC bindings can be\n+ known statically from the mac and networks\n+ column in the Logical_Router_Port table. (Note: the\n+ flow is NOT installed for the IP addresses that belong to a neighbor\n+ logical router port if the current router has the\n+ options:dynamic_neigh_routers set to true)\n+

    \n+\n+

    \n+ For each IPv4 address A whose host is known to have\n+ Ethernet address E on router port P, a\n+ priority-100 flow with match outport === P\n+ && reg0 == A has actions\n+ eth.dst = E; next;.\n+

    \n+\n+

    \n+ For each IPv6 address A whose host is known to have\n+ Ethernet address E on router port P, a\n+ priority-100 flow with match outport === P\n+ && xxreg0 == A has actions\n+ eth.dst = E; next;.\n+

    \n+\n+

    \n+ For each logical router port with an IPv4 address A and\n+ a mac address of E that is reachable via a different\n+ logical router port P, a priority-100 flow with\n+ match outport === P && reg0 ==\n+ A has actions eth.dst = E;\n+ next;.\n+

    \n+\n+

    \n+ For each logical router port with an IPv6 address A and\n+ a mac address of E that is reachable via a different\n+ logical router port P, a priority-100 flow with\n+ match outport === P && xxreg0 ==\n+ A has actions eth.dst = E;\n+ next;.\n+

    \n+
    • \n+\n+
  • \n+

    \n+ Static MAC bindings from NAT entries. MAC bindings can also be known\n+ for the entries in the NAT table. Below flows are\n+ programmed for distributed logical routers i.e with a distributed\n+ router port.\n+

    \n+\n+

    \n+ For each row in the NAT table with IPv4 address\n+ A in the column of\n+ table, below two flows are\n+ programmed:\n+

    \n+\n+

    \n+ A priority-100 flow with the match outport == P\n+ && reg0 == A has actions eth.dst =\n+ E; next;, where P is the distributed\n+ logical router port, E is the Ethernet address if set in\n+ the \n+ column of table for of type\n+ dnat_and_snat, otherwise the Ethernet address of the\n+ distributed logical router port. Note that if the\n+ is not\n+ within a subnet on the owning logical router, then OVN will only\n+ create ARP resolution flows if the \n+ is set to true. Otherwise, no ARP resolution flows\n+ will be added.\n+

    \n+\n+

    \n+ Corresponding to the above flow, a priority-150 flow with the match\n+ inport == P && outport == P\n+ && ip4.dst == A has actions\n+ drop; to exclude packets that have gone through\n+ DNAT/unSNAT stage but failed to convert the destination, to avoid\n+ loop.\n+

    \n+\n+

    \n+ For IPv6 NAT entries, same flows are added, but using the register\n+ xxreg0 and field ip6 for the match.\n+

    \n+
    • \n+\n+
  • \n+

    \n+ If the router datapath runs a port with redirect-type\n+ set to bridged, for each distributed NAT rule with IP\n+ A in the\n+ column\n+ and logical port P in the\n+ column\n+ of table, a priority-90 flow\n+ with the match outport == Q && ip.src ===\n+ A && is_chassis_resident(P),\n+ where Q is the distributed logical router port and\n+ action get_arp(outport, reg0); next; for IPv4 and\n+ get_nd(outport, xxreg0); next; for IPv6.\n+

    \n+
    • \n+\n+
  • \n+

    \n+ Traffic with IP destination an address owned by the router should be\n+ dropped. Such traffic is normally dropped in ingress table\n+ IP Input except for IPs that are also shared with SNAT\n+ rules. However, if there was no unSNAT operation that happened\n+ successfully until this point in the pipeline and the destination IP\n+ of the packet is still a router owned IP, the packets can be safely\n+ dropped.\n+

    \n+\n+

    \n+ A priority-2 logical flow with match ip4.dst = {..}\n+ matches on traffic destined to router owned IPv4 addresses which are\n+ also SNAT IPs. This flow has action drop;.\n+

    \n+\n+

    \n+ A priority-2 logical flow with match ip6.dst = {..}\n+ matches on traffic destined to router owned IPv6 addresses which are\n+ also SNAT IPs. This flow has action drop;.\n+

    \n+\n+

    \n+ A priority-0 logical that flow matches all packets not already\n+ handled (match 1) and drops them\n+ (action drop;).\n+

    \n+
    • \n+\n+
  • \n+

    \n+ Dynamic MAC bindings. These flows resolve MAC-to-IP bindings\n+ that have become known dynamically through ARP or neighbor\n+ discovery. (The ingress table ARP Request will\n+ issue an ARP or neighbor solicitation request for cases where\n+ the binding is not yet known.)\n+

    \n+\n+

    \n+ A priority-0 logical flow with match ip4 has actions\n+ get_arp(outport, reg0); next;.\n+

    \n+\n+

    \n+ A priority-0 logical flow with match ip6 has actions\n+ get_nd(outport, xxreg0); next;.\n+

    \n+
    • \n+\n+
  • \n+

    \n+ For a distributed gateway LRP with redirect-type\n+ set to bridged, a priority-50 flow will match\n+ outport == \"ROUTER_PORT\" and !is_chassis_resident\n+ (\"cr-ROUTER_PORT\") has actions eth.dst = E;\n+ next;, where E is the ethernet address of the\n+ logical router port.\n+

    \n+
    • \n+\n+
\n+\n+

Ingress Table 23: Check packet length

\n+\n+

\n+ For distributed logical routers or gateway routers with gateway\n+ port configured with options:gateway_mtu to a valid\n+ integer value, this table adds a priority-50 logical flow with\n+ the match outport == GW_PORT where\n+ GW_PORT is the gateway router port and applies the\n+ actions check_pkt_larger and ct_state_save\n+ and then advances the packet to the next table.\n+

\n+\n+ 
\n+REGBIT_PKT_LARGER = check_pkt_larger(L);\n+REG_CT_STATE = ct_state_save();\n+next;\n+
\n+\n+

\n+ where L is the packet length to check for. If the packet\n+ is larger than L, it stores 1 in the register bit\n+ REGBIT_PKT_LARGER. The value of\n+ L is taken from column of\n+ row.\n+

\n+\n+

\n+ If the port is also configured with\n+ options:gateway_mtu_bypass then another flow is\n+ added, with priority-55, to bypass the check_pkt_larger\n+ flow.\n+

\n+\n+

\n+ This table adds one priority-0 fallback flow that matches all packets\n+ and advances to the next table.\n+

\n+\n+

Ingress Table 24: Handle larger packets

\n+\n+

\n+ For distributed logical routers or gateway routers with gateway port\n+ configured with options:gateway_mtu to a valid integer\n+ value, this table adds the following priority-150 logical flow for each\n+ logical router port with the match inport == LRP\n+ && outport == GW_PORT && REGBIT_PKT_LARGER\n+ && !REGBIT_EGRESS_LOOPBACK, where LRP is the\n+ logical router port and GW_PORT is the gateway port and\n+ applies the following action for ipv4 and ipv6 respectively:\n+

\n+\n+ 
\n+icmp4 {\n+    icmp4.type = 3; /* Destination Unreachable. */\n+    icmp4.code = 4;  /* Frag Needed and DF was Set. */\n+    icmp4.frag_mtu = M;\n+    eth.dst = E;\n+    ip4.dst = ip4.src;\n+    ip4.src = I;\n+    ip.ttl = 255;\n+    REGBIT_EGRESS_LOOPBACK = 1;\n+    REGBIT_PKT_LARGER = 0;\n+    next(pipeline=ingress, table=0);\n+};\n+\n+icmp6 {\n+    icmp6.type = 2;\n+    icmp6.code = 0;\n+    icmp6.frag_mtu = M;\n+    eth.dst = E;\n+    ip6.dst = ip6.src;\n+    ip6.src = I;\n+    ip.ttl = 255;\n+    REGBIT_EGRESS_LOOPBACK = 1;\n+    REGBIT_PKT_LARGER = 0;\n+    next(pipeline=ingress, table=0);\n+};\n+
\n+\n+
    \n+
  • \n+ Where M is the (fragment MTU - 58) whose value is taken from\n+ column of\n+ row.\n+
    • \n+\n+
  • \n+ E is the Ethernet address of the logical router port.\n+
    • \n+\n+
  • \n+ I is the IPv4/IPv6 address of the logical router port.\n+
    • \n+
\n+\n+

\n+ This table adds one priority-0 fallback flow that matches all packets\n+ and advances to the next table.\n+

\n+\n+

Ingress Table 25: Gateway Redirect

\n+\n+

\n+ For distributed logical routers where one or more of the logical router\n+ ports specifies a gateway chassis, this table redirects\n+ certain packets to the distributed gateway port instances on the\n+ gateway chassises. This table has the following flows:\n+

\n+\n+
    \n+
  • \n+ For all the configured load balancing rules that include an IPv4\n+ address VIP, and a list of IPv4 backend addresses\n+ B0, B1 .. Bn defined for the\n+ VIP a priority-200 flow is added that matches \n+ ip4 && (ip4.src == B0 || ip4.src == B1\n+ || ... || ip4.src == Bn) with an action \n+ outport = CR; next; where CR is the\n+ chassisredirect port representing the instance of the\n+ logical router distributed gateway port on the gateway chassis.\n+ If the backend IPv4 address Bx is also configured with\n+ L4 port PORT of protocol P, then the match\n+ also includes P.src == PORT.\n+ Similar flows are added for IPv6.\n+
    • \n+\n+
  • \n+ For each NAT rule in the OVN Northbound database that can\n+ be handled in a distributed manner, a priority-100 logical\n+ flow with match ip4.src == B &&\n+ outport == GW &&\n+ is_chassis_resident(P), where GW is\n+ the distributed gateway port specified in the\n+ NAT rule and P is the NAT logical port. IP traffic\n+ matching the above rule will be managed locally setting\n+ reg1 to C and\n+ eth.src to D, where C is NAT\n+ external ip and D is NAT external mac.\n+
    • \n+\n+
  • \n+ For each dnat_and_snat NAT rule with\n+ stateless=true and allowed_ext_ips\n+ configured, a priority-75 flow is programmed with match\n+ ip4.dst == B and action\n+ outport = CR; next; where B\n+ is the NAT rule external IP and CR is the\n+ chassisredirect port representing the instance\n+ of the logical router distributed gateway port on the\n+ gateway chassis. Moreover a priority-70 flow is programmed\n+ with same match and action drop;.\n+ For each dnat_and_snat NAT rule with\n+ stateless=true and exempted_ext_ips\n+ configured, a priority-75 flow is programmed with match\n+ ip4.dst == B and action\n+ drop; where B is the NAT rule\n+ external IP.\n+ A similar flow is added for IPv6 traffic.\n+
    • \n+\n+
  • \n+ For each NAT rule in the OVN Northbound database that can\n+ be handled in a distributed manner, a priority-80 logical flow\n+ with drop action if the NAT logical port is a virtual port not\n+ claimed by any chassis yet.\n+
    • \n+\n+
  • \n+ A priority-50 logical flow with match\n+ outport == GW has actions\n+ outport = CR; next;, where\n+ GW is the logical router distributed gateway\n+ port and CR is the chassisredirect\n+ port representing the instance of the logical router\n+ distributed gateway port on the\n+ gateway chassis.\n+
    • \n+\n+
  • \n+ A priority-0 logical flow with match 1 has actions\n+ next;.\n+
    • \n+
\n+\n+

Ingress Table 26: Network ID

\n+\n+

\n+ This table contains flows that set flags.network_id for\n+ IP packets:\n+

\n+\n+
    \n+
  • \n+

    \n+ A priority-110 flow with match:\n+

      \n+
    • \n+ for IPv4: outport == P &&\n+ REG_NEXT_HOP_IPV4 == I/C &&\n+ ip4\n+
      • \n+
    • \n+ for IPv6: outport == P &&\n+ REG_NEXT_HOP_IPV6 == I/C &&\n+ ip6\n+
      • \n+
    \n+

    \n+\n+

    \n+ and actions flags.network_id = N; next;.\n+ Where P is the outport, I/C is a\n+ network CIDR of the port P, and N is the\n+ network id (index). There is one flow like this per router port's\n+ network.\n+

    \n+\n+

    \n+ flags.network_id is 4 bits, and thus only 16 networks can\n+ be indexed. If the number of networks is greater than 16, networks 17\n+ and up will have the actions flags.network_id = 0; next;\n+ and only the lexicographically first IP will be considered for SNAT for\n+ those networks.\n+

    \n+
    • \n+\n+
  • \n+ A lower priority-105 flow with match 1 and actions\n+ flags.network_id = 0; next;. This is for the case that the\n+ next-hop doesn't belong to any of the port networks, so\n+ flags.network_id should be set to zero.\n+
    • \n+\n+
  • \n+ Catch-all: A priority-0 flow with match 1 has\n+ actions next;.\n+
    • \n+
\n+\n+

Ingress Table 27: ARP Request

\n+\n+

\n+ In the common case where the Ethernet destination has been resolved, this\n+ table advances the packet to the next table. Otherwise, it composes and\n+ sends an ARP or IPv6 Neighbor Solicitation request. It holds the\n+ following flows:\n+

\n+\n+
    \n+
  • \n+

    \n+ Unknown MAC address. A priority-100 flow for IPv4 packets with match\n+ eth.dst == 00:00:00:00:00:00 has the following actions:\n+

    \n+\n+ 
    \n+arp {\n+    eth.dst = ff:ff:ff:ff:ff:ff;\n+    arp.spa = reg1;\n+    arp.tpa = reg0;\n+    arp.op = 1;  /* ARP request. */\n+    output;\n+};\n+
    \n+\n+

    \n+ Unknown MAC address. For each IPv6 static route associated with the\n+ router with the nexthop IP: G, a priority-200 flow\n+ for IPv6 packets with match\n+ eth.dst == 00:00:00:00:00:00 &&\n+ xxreg0 == G\n+ with the following actions is added:\n+

    \n+\n+ 
    \n+nd_ns {\n+    eth.dst = E;\n+    ip6.dst = I\n+    nd.target = G;\n+    output;\n+};\n+
    \n+\n+

    \n+ Where E is the multicast mac derived from the Gateway IP,\n+ I is the solicited-node multicast address corresponding\n+ to the target address G.\n+

    \n+\n+

    \n+ Unknown MAC address. A priority-100 flow for IPv6 packets with match\n+ eth.dst == 00:00:00:00:00:00 has the following actions:\n+

    \n+\n+ 
    \n+nd_ns {\n+    nd.target = xxreg0;\n+    output;\n+};\n+
    \n+\n+

    \n+ (Ingress table IP Routing initialized reg1\n+ with the IP address owned by outport and\n+ (xx)reg0 with the next-hop IP address)\n+

    \n+\n+

    \n+ The IP packet that triggers the ARP/IPv6 NS request is dropped.\n+

    \n+
    • \n+\n+
  • \n+ Known MAC address. A priority-0 flow with match 1 has\n+ actions next;.\n+
    • \n+
\n+\n+

Ingress Table 28: ECMP symmetric reply processing for egress

\n+

\n+ This table contains logical flows that commit IP traffic forwarded by\n+ ECMP symmetric reply static routes in the \"route direction\", that is,\n+ for sessions initiated from behind such routes. These flows can be hit\n+ only on gateway routers, the only type of routers that supports ECMP\n+ symmetric reply routes. As the egress port of the traffic needs to be\n+ stored in conntrack for these sessions, one logical flow is added for\n+ each logical router port.\n+

\n+\n+

Egress Table 0: Check DNAT local

\n+\n+

\n+ This table checks if the packet needs to be DNATed in the router ingress\n+ table lr_in_dnat after it is SNATed and looped back\n+ to the ingress pipeline. This check is done only for routers configured\n+ with distributed gateway ports and NAT entries. This check is done\n+ so that SNAT and DNAT is done in different zones instead of a common\n+ zone.\n+

\n+\n+
    \n+
  • \n+ A priority-0 logical flow with match 1 has actions\n+ REGBIT_DST_NAT_IP_LOCAL = 0; next;.\n+
    • \n+
\n+\n+

Egress Table 1: UNDNAT

\n+\n+

\n+ This is for already established connections' reverse traffic.\n+ i.e., DNAT has already been done in ingress pipeline and now the\n+ packet has entered the egress pipeline as part of a reply. This traffic\n+ is unDNATed here.\n+

\n+\n+
    \n+
  • \n+ A priority-0 logical flow with match 1 has actions\n+ next;.\n+
    • \n+
\n+\n+

Egress Table 1: UNDNAT on Gateway Routers

\n+\n+
    \n+
  • \n+ For IPv6 Neighbor Discovery or Router Solicitation/Advertisement\n+ traffic, a priority-100 flow with action next;.\n+
    • \n+\n+
  • \n+ For all IP packets, a priority-50 flow with an action\n+ flags.loopback = 1; ct_dnat;.\n+
    • \n+
\n+\n+

Egress Table 1: UNDNAT on Distributed Routers

\n+
    \n+
  • \n+

    \n+ For all the configured load balancing rules for a router with gateway\n+ port in OVN_Northbound database that includes an IPv4\n+ address VIP, for every backend IPv4 address B\n+ defined for the VIP a priority-120 flow is programmed on\n+ gateway chassis that matches\n+ ip && ip4.src == B &&\n+ outport == GW, where GW is the logical\n+ router gateway port with an action ct_dnat;.\n+ If the backend IPv4 address B is also configured with\n+ L4 port PORT of protocol P, then the\n+ match also includes P.src == PORT. These\n+ flows are not added for load balancers with IPv6 VIPs.\n+

    \n+\n+

    \n+ If the router is configured to force SNAT any load-balanced packets,\n+ above action will be replaced by\n+ flags.force_snat_for_lb = 1; ct_dnat;.\n+

    \n+
    • \n+\n+
  • \n+

    \n+ For each configuration in the OVN Northbound database that asks\n+ to change the destination IP address of a packet from an IP\n+ address of A to B, a priority-100 flow\n+ matches ip && ip4.src == B\n+ && outport == GW, where GW\n+ is the logical router gateway port, with an action\n+ ct_dnat;. If the NAT rule is of type\n+ dnat_and_snat and has stateless=true in the\n+ options, then the action would be next;.\n+

    \n+\n+

    \n+ If the NAT rule cannot be handled in a distributed manner, then\n+ the priority-100 flow above is only programmed on the\n+ gateway chassis with the action ct_dnat.\n+

    \n+\n+

    \n+ If the NAT rule can be handled in a distributed manner, then\n+ there is an additional action\n+ eth.src = EA;, where EA\n+ is the ethernet address associated with the IP address\n+ A in the NAT rule. This allows upstream MAC\n+ learning to point to the correct chassis.\n+

    \n+
    • \n+\n+
\n+\n+

Egress Table 2: Post UNDNAT

\n+\n+

\n+

    \n+
  • \n+ A priority-70 logical flow is added that initiates CT state for\n+ traffic that is configured to be SNATed on Distributed routers.\n+ This allows the next table, lr_out_snat, to\n+ effectively match on various CT states.\n+
    • \n+\n+
  • \n+ A priority-50 logical flow is added that commits any untracked flows\n+ from the previous table lr_out_undnat for Gateway\n+ routers. This flow matches on ct.new && ip\n+ with action ct_commit { } ; next; .\n+
    • \n+\n+
  • \n+ If the options:ct-commit-all is set to true\n+ the following flows are configured matching on ip &&\n+ (!ct.trk || !ct.rpl) && flags.unsnat_not_tracked == 1\n+ with an action ct_next(snat); and ip &&\n+ flags.unsnat_new == 1 with an action next;. There\n+ is extra match when there is configured DGP\n+ outport == DGP && is_chassis_resident(CHASSIS).\n+
    • \n+\n+
  • \n+ A priority-0 logical flow with match 1 has actions\n+ next;.\n+
    • \n+\n+
\n+

\n+\n+

Egress Table 3: SNAT

\n+\n+

\n+ Packets that are configured to be SNATed get their source IP address\n+ changed based on the configuration in the OVN Northbound database.\n+

\n+\n+
    \n+
  • \n+ A priority-120 flow to advance the IPv6 Neighbor solicitation packet\n+ to next table to skip SNAT. In the case where ovn-controller injects\n+ an IPv6 Neighbor Solicitation packet (for nd_ns action)\n+ we don't want the packet to go through conntrack.\n+
    • \n+
\n+\n+

Egress Table 3: SNAT on Gateway Routers

\n+\n+
    \n+
  • \n+

    \n+ If the Gateway router in the OVN Northbound database has been\n+ configured to force SNAT a packet (that has been previously DNATted)\n+ to B, a priority-100 flow matches\n+ flags.force_snat_for_dnat == 1 && ip with an\n+ action ct_snat(B);.\n+

    \n+
    • \n+\n+
  • \n+

    \n+ If a load balancer configured to skip snat has been applied to\n+ the Gateway router pipeline, a priority-120 flow matches\n+ flags.skip_snat_for_lb == 1 && ip with an\n+ action next;.\n+

    \n+
    • \n+\n+
  • \n+

    \n+ If the Gateway router in the OVN Northbound database has been\n+ configured to force SNAT a packet (that has been previously\n+ load-balanced) using router IP (i.e :lb_force_snat_ip=router_ip), then for\n+ each logical router port P attached to the Gateway\n+ router, and for each network configured for this port, a priority-110\n+ flow matches flags.force_snat_for_lb == 1 &&\n+ ip4 &&\n+ flags.network_id == N &&\n+ outport == P, where N is the\n+ network index, with an action ct_snat(R);\n+ where R is the IP configured on the router port. A similar\n+ flow is created for IPv6, with ip6 instead of\n+ ip4. N, the network index, will be 0 for\n+ networks 17 and up.\n+

    \n+\n+

    \n+ If the logical router port P is configured with multiple\n+ IPv4 and multiple IPv6 addresses, the IPv4 and IPv6 address within\n+ the same network as the next-hop will be chosen as R for\n+ SNAT. However, if there are more than 16 networks configured, the\n+ lexicographically first IP will be considered for SNAT for networks\n+ 17 and up.\n+

    \n+
    • \n+
  • \n+

    \n+ A priority-105 flow matches the old behavior for if northd is\n+ upgraded before controller and flags.network_id is not\n+ recognized. It is only added if there's at least one network\n+ configured (excluding LLA for IPv6). It matches on:\n+ flags.force_snat_for_lb == 1 && ip4\n+ && outport == P, with action:\n+ ct_snat(R).\n+ R is the lexicographically first IP address configured.\n+ There is a similar flow for IPv6 with ip6 instead of\n+ ip4.\n+

    \n+
    • \n+\n+
  • \n+

    \n+ If the Gateway router in the OVN Northbound database has been\n+ configured to force SNAT a packet (that has been previously\n+ load-balanced) to B, a priority-100 flow matches\n+ flags.force_snat_for_lb == 1 && ip with an\n+ action ct_snat(B);.\n+

    \n+
    • \n+\n+
  • \n+

    \n+ For each configuration in the OVN Northbound database, that asks\n+ to change the source IP address of a packet from an IP address of\n+ A or to change the source IP address of a packet that\n+ belongs to network A to B, a flow matches\n+ ip && ip4.src == A &&\n+ (!ct.trk || !ct.rpl) with an action\n+ ct_snat(B);. The priority of the flow\n+ is calculated based on the mask of A, with matches\n+ having larger masks getting higher priorities. If the NAT rule is\n+ of type dnat_and_snat and has stateless=true in the\n+ options, then the action would be ip4/6.src=\n+ (B).\n+

    \n+\n+

    \n+ For each configuration in the OVN Northbound database, that asks\n+ to change the source IP address of a packet from an IP address of\n+ A or to change the source IP address of a packet that\n+ belongs to network A to B, match M\n+ and priority P, a flow matches ip &&\n+ ip4.src == A && (!ct.trk || !ct.rpl) &&\n+ (M) with an action ct_snat(B);\n+ . The priority of the flow is calculated based as\n+ 300 + P. If the NAT rule is of type\n+ dnat_and_snat and has stateless=true in the options,\n+ then the action would be ip4/6.src=(B).\n+

    \n+
    • \n+\n+
  • \n+

    \n+ If the NAT rule has allowed_ext_ips configured, then\n+ there is an additional match ip4.dst == allowed_ext_ips\n+ . Similarly, for IPV6, match would be ip6.dst ==\n+ allowed_ext_ips.\n+

    \n+
    • \n+\n+
  • \n+

    \n+ If the NAT rule has exempted_ext_ips set, then\n+ there is an additional flow configured at the priority + 1 of\n+ corresponding NAT rule. The flow matches if destination ip\n+ is an exempted_ext_ip and the action is next;\n+ . This flow is used to bypass the ct_snat action for a packet\n+ which is destinted to exempted_ext_ips.\n+

    \n+
    • \n+\n+
  • \n+

    \n+ If the options:ct-commit-all is set to true\n+ the following two flows are configured matching on ip\n+ && (!ct.trk || !ct.rpl) &&\n+ flags.unsnat_new == 1 and\n+ ip && ct.new && flags.unsnat_not_tracked == 1\n+ both with an action ct_commit_to_zone(snat);.\n+

    \n+
    • \n+\n+
  • \n+

    \n+ A priority-0 logical flow with match 1 has actions\n+ next;.\n+

    \n+
    • \n+
\n+\n+

Egress Table 3: SNAT on Distributed Routers

\n+\n+
    \n+
  • \n+

    \n+ For each configuration in the OVN Northbound database, that asks\n+ to change the source IP address of a packet from an IP address of\n+ A or to change the source IP address of a packet that\n+ belongs to network A to B, two flows are\n+ added. The priority P of these flows are calculated\n+ based on the mask of A, with matches having larger\n+ masks getting higher priorities.\n+

    \n+\n+

    \n+ If the NAT rule cannot be handled in a distributed manner, then\n+ the below flows are only programmed on the gateway chassis increasing\n+ flow priority by 128 in order to be run first.\n+

    \n+\n+
      \n+
    • \n+ The first flow is added with the calculated priority P\n+ and match ip && ip4.src == A &&\n+ outport == GW, where GW is the\n+ logical router gateway port, with an action\n+ ct_snat(B); to SNATed in the\n+ common zone. If the NAT rule is of type dnat_and_snat and has\n+ stateless=true in the options, then the action\n+ would be ip4/6.src=(B).\n+
      • \n+
    \n+\n+

    \n+ If the NAT rule can be handled in a distributed manner, then\n+ there is an additional action (for both the flows)\n+ eth.src = EA;, where EA\n+ is the ethernet address associated with the IP address\n+ A in the NAT rule. This allows upstream MAC\n+ learning to point to the correct chassis.\n+

    \n+\n+

    \n+ If the NAT rule has allowed_ext_ips configured, then\n+ there is an additional match ip4.dst == allowed_ext_ips\n+ . Similarly, for IPV6, match would be ip6.dst ==\n+ allowed_ext_ips.\n+

    \n+\n+

    \n+ If the NAT rule has exempted_ext_ips set, then\n+ there is an additional flow configured at the priority\n+ P + 2 of\n+ corresponding NAT rule. The flow matches if destination ip\n+ is an exempted_ext_ip and the action is next;\n+ . This flow is used to bypass the ct_snat action for a flow\n+ which is destinted to exempted_ext_ips.\n+

    \n+\n+
    • \n+\n+
  • \n+ An additional flow is added for traffic that goes in opposite\n+ direction (i.e. it enters a network with configured SNAT). Where the\n+ flow above matched on ip4.src == A && outport\n+ == GW, this flow matches on ip4.dst ==\n+ A && inport == GW. A CT state is\n+ initiated for this traffic so that the following table, \n+ lr_out_post_snat, can identify whether the traffic flow was\n+ initiated from the internal or external network.\n+
    • \n+\n+
  • \n+

    \n+ If the options:ct-commit-all is set to true\n+ the following two flows are configured matching on ip\n+ && (!ct.trk || !ct.rpl) && flags.unsnat_new == 1\n+ && outport == DGP && is_chassis_resident(CHASSIS)\n+ and ip && ct.new &&\n+ flags.unsnat_not_tracked == 1 && outport == DGP &&\n+ is_chassis_resident(CHASSIS)both with an action\n+ ct_commit_to_zone(snat);.\n+

    \n+
    • \n+\n+
  • \n+ A priority-0 logical flow with match 1 has actions\n+ next;.\n+
    • \n+
\n+\n+

Egress Table 4: Post SNAT

\n+\n+

\n+ Packets reaching this table are processed according to the flows below:\n+

    \n+
  • \n+ Traffic that goes directly into a network configured with SNAT on\n+ Distributed routers, and was initiated from an external network (i.e.\n+ it matches ct.new), is committed to the SNAT CT zone.\n+ This ensures that replies returning from the SNATed network do not\n+ have their source address translated. For details about match rules\n+ and priority see section \"Egress Table 3: SNAT on Distributed\n+ Routers\".\n+
    • \n+\n+
  • \n+ A priority-0 logical flow that matches all packets not already\n+ handled (match 1) and action next;.\n+
    • \n+
\n+

\n+\n+

Egress Table 5: Egress Loopback

\n+\n+

\n+ For distributed logical routers where one of the logical router\n+ ports specifies a gateway chassis.\n+

\n+\n+

\n+ While UNDNAT and SNAT processing have already occurred by this\n+ point, this traffic needs to be forced through egress loopback on\n+ this distributed gateway port instance, in order for UNSNAT and\n+ DNAT processing to be applied, and also for IP routing and ARP\n+ resolution after all of the NAT processing, so that the packet can\n+ be forwarded to the destination.\n+

\n+\n+

\n+ This table has the following flows:\n+

\n+\n+
    \n+
  • \n+

    \n+ For each NAT rule in the OVN Northbound database on a\n+ distributed router, a priority-100 logical flow with match\n+ ip4.dst == E &&\n+ outport == GW &&\n+ is_chassis_resident(P), where E is the\n+ external IP address specified in the NAT rule, GW\n+ is the distributed gateway port corresponding to the NAT rule\n+ (specified or inferred).\n+ For dnat_and_snat NAT rule, P is the logical port\n+ specified in the NAT rule.\n+ If column of\n+ table is NOT set, then\n+ P is the chassisredirect port of\n+ GW with the following actions:\n+

    \n+\n+ 
    \n+clone {\n+    ct_clear;\n+    inport = outport;\n+    outport = \"\";\n+    flags = 0;\n+    flags.loopback = 1;\n+    reg0 = 0;\n+    reg1 = 0;\n+    ...\n+    reg9 = 0;\n+    REGBIT_EGRESS_LOOPBACK = 1;\n+    next(pipeline=ingress, table=0);\n+};\n+
    \n+\n+

    \n+ flags.loopback is set since in_port is unchanged\n+ and the packet may return back to that port after NAT processing.\n+ REGBIT_EGRESS_LOOPBACK is set to indicate that\n+ egress loopback has occurred, in order to skip the source IP\n+ address check against the router address.\n+

    \n+
    • \n+\n+
  • \n+ A priority-0 logical flow with match 1 has actions\n+ next;.\n+
    • \n+
\n+\n+

Egress Table 6: Delivery

\n+\n+

\n+ Packets that reach this table are ready for delivery. It contains:\n+

    \n+
  • \n+ Priority-110 logical flows that match IP multicast packets on each\n+ enabled logical router port and modify the Ethernet source address\n+ of the packets to the Ethernet address of the port and then execute\n+ action output;.\n+
    • \n+
  • \n+ Priority-100 logical flows that match packets on each enabled\n+ logical router port, with action output;.\n+
    • \n+
  • \n+ A priority-0 logical flow that matches all packets not already\n+ handled (match 1) and drops them\n+ (action drop;).\n+
    • \n+
\n+

\n+\n+

Drop sampling

\n+\n+

\n+ As described in the previous section, there are several places where\n+ ovn-northd might decided to drop a packet by explicitly creating a\n+ Logical_Flow with the drop; action.\n+

\n+\n+

\n+ When debug drop-sampling has been cofigured in the OVN Northbound\n+ database, the ovn-northd will replace all the drop;\n+ actions with a sample(priority=65535, collector_set=id,\n+ obs_domain=obs_id, obs_point=@cookie) action, where:\n+

    \n+
  • \n+ id is the value the debug_drop_collector_set\n+ option configured in the OVN Northbound.\n+
    • \n+
  • \n+ obs_id has it's 8 most significant bits equal to the value\n+ of the debug_drop_domain_id option in the OVN Northbound\n+ and it's 24 least significant bits equal to the datapath's tunnel key.\n+
    • \n+
\n+

\n+\n+\ndiff --git a/northd/ovn-northd.8.xml b/northd/ovn-northd.8.xml\nindex 4d6370da6..e5d460382 100644\n--- a/northd/ovn-northd.8.xml\n+++ b/northd/ovn-northd.8.xml\n@@ -255,6068 +255,13 @@\n

\n \n

Logical Flow Table Structure

\n-\n-

\n- One of the main purposes of ovn-northd is to populate the\n- Logical_Flow table in the OVN_Southbound\n- database. This section describes how ovn-northd does this\n- for switch and router logical datapaths.\n-

\n-\n-

Logical Switch Datapaths

\n-\n-

Ingress Table 0: Admission Control and Ingress Port Security check

\n-\n-

\n- Ingress table 0 contains these logical flows:\n-

\n-\n-
    \n-
  • \n- Priority 100 flows to drop packets with VLAN tags or multicast Ethernet\n- source addresses.\n-
    • \n-\n-
  • \n- For each disabled logical port, a priority 100 flow is added which\n- matches on all packets and applies the action\n- REGBIT_PORT_SEC_DROP\" = 1; next;\" so that the packets are\n- dropped in the next stage.\n-
    • \n-\n-
  • \n-

    \n- For each logical port that's defined as a target of routing protocol\n- redirecting (via routing-protocol-redirect option set on\n- Logical Router Port), a filter is set in place that disallows\n- following traffic exiting this port:\n-

    \n-
      \n-
    • \n- ARP replies\n-
      • \n-
    • \n- IPv6 Neighbor Discovery - Router Advertisements\n-
      • \n-
    • \n- IPv6 Neighbor Discovery - Neighbor Advertisements\n-
      • \n-
    \n-

    \n- Since this port shares IP and MAC addresses with the Logical Router\n- Port, we wan't to prevent duplicate replies and advertisements. This\n- is achieved by a rule with priority 80 that sets\n- REGBIT_PORT_SEC_DROP\" = 1; next;\".\n-

    \n-
    • \n-\n-
  • \n- For each logical switch that has connected physical ports\n- (localnet or l2gateway) and is also connected to a distributed router,\n- filtering rules are added for ARP requests coming from localnet or\n- l2gateway ports, allowed for processing on gateway chassis.\n- The REGBIT_EXT_ARP register is set for all ARP requests\n- originating from physical ports with priority 75 flow.\n-
    • \n-\n-
  • \n- For each (enabled) vtep logical port, a priority 70 flow is added which\n- matches on all packets and applies the action\n- next(pipeline=ingress, table=S_SWITCH_IN_L3_LKUP) = 1;\n- to skip most stages of ingress pipeline and go directly to ingress L2\n- lookup table to determine the output port. Packets from VTEP (RAMP)\n- switch should not be subjected to any ACL checks. Egress pipeline will\n- do the ACL checks.\n-
    • \n-\n-
  • \n- For each enabled logical port configured with qdisc queue id in the\n- column of , a priority 70 flow is added which\n- matches on all packets and applies the action\n- set_queue(id);\n- REGBIT_PORT_SEC_DROP\" = check_in_port_sec(); next;\".\n-
    • \n-\n-
  • \n- A priority 1 flow is added which matches on all packets for all the\n- logical ports and applies the action\n- REGBIT_PORT_SEC_DROP\" = check_in_port_sec(); next; to\n- evaluate the port security. The action check_in_port_sec\n- applies the port security rules defined in the\n- column of table.\n-
    • \n-
\n-\n-

Ingress Table 1: Ingress Port Security - Apply

\n-\n-

\n- For each logical switch port P of type router connected to a\n- gw router a priority-120 flow that matches 'recirculated' icmp{4,6} error\n- 'packet too big' and eth.src == D &&\n- outport == P && flags.tunnel_rx == 1 where\n- D is the peer logical router port RP mac address,\n- swaps inport and outport and applies the action next.\n-

\n-\n-

\n- For each logical switch port P of type router connected to a\n- distributed router a priority-120 flow that matches 'recirculated'\n- icmp{4,6} error 'packet too big' and eth.dst == D\n- && flags.tunnel_rx == 1 where D is the peer\n- logical router port RP mac address, swaps inport and outport\n- and applies the action next(pipeline=S_SWITCH_IN_L2_LKUP).\n-

\n-\n-

\n- For each logical switch port P a priority-110 flow that\n- matches 'recirculated' icmp{4,6} error 'packet too big' and \n- eth.src == D && outport == P &&\n- !is_chassis_resident(\"P\") && flags.tunnel_rx == 1\n- where D is the logical switch port mac address,\n- swaps inport and outport and applies the action next.\n-

\n-\n-

\n- This table adds a priority-105 flow that matches 'recirculated' icmp{4,6}\n- error 'packet too big' to drop the packet.\n-

\n-\n-

\n- This table drops the packets if the port security check failed\n- in the previous stage i.e the register bit\n- REGBIT_PORT_SEC_DROP is set to 1.\n-

\n-\n-

\n- Ingress table 1 contains these logical flows:\n-

\n-\n-
    \n-
  • \n- A priority-50 fallback flow that drops the packet if the register\n- bit REGBIT_PORT_SEC_DROP is set to 1.\n-
    • \n-\n-
  • \n- One priority-0 fallback flow that matches all packets and advances to\n- the next table.\n-
    • \n-\n-
  • \n- Priority 75: Allows REGBIT_EXT_ARP packets only on gateway\n- chassis and chassis with distributed NAT entries.\n- Priority 70: Drops REGBIT_EXT_ARP packets on non-gateway\n- chassis (complements the priority 75 flow).\n-
    • \n-
\n-\n-

Ingress Table 2: Mirror

\n-\n-

\n- Overlay remote mirror table contains the following\n- logical flows:\n-

\n-\n-
    \n-
  • \n- For each logical switch port with an attached mirror, a logical flow\n- with a priority of 100 is added. This flow matches all incoming packets\n- to the attached port, clones them, and forwards the cloned packets to\n- the mirror target port.\n-
    • \n-\n-
  • \n- A priority 0 flow is added which matches on all packets and applies\n- the action next;.\n-
    • \n-\n-
  • \n- A logical flow added for each Mirror Rule in Mirror table attached\n- to logical switch ports, matches all incoming packets that match\n- rules and clones the packet and sends cloned packet to mirror\n- target port.\n-
    • \n-
\n-\n-

Ingress Table 3: Lookup MAC address learning table

\n-\n-

\n- This table looks up the MAC learning table of the logical switch\n- datapath to check if the port-mac pair is present\n- or not. MAC is learnt for logical switch VIF ports whose\n- port security is disabled and 'unknown' address setn as well as\n- for localnet ports with option localnet_learn_fdb. A localnet\n- port entry does not overwrite a VIF port entry.\n- Logical switch ports with type switch have implicit\n- 'unknown' addresses and so they are also eligible for MAC learning.\n-

\n-\n-
    \n-
  • \n-

    \n- For each such VIF logical port p whose port security\n- is disabled and 'unknown' address set following flow\n- is added.\n-

    \n-\n-
      \n-
    • \n- Priority 100 flow with the match\n- inport == p and action\n- reg0[11] = lookup_fdb(inport, eth.src); next;\n-
      • \n-
    \n-
    • \n-\n-
  • \n-

    \n- For each such localnet logical port p following flow\n- is added.\n-

    \n-\n-
      \n-
    • \n- Priority 100 flow with the match\n- inport == p and action\n- flags.localnet = 1;\n- reg0[11] = lookup_fdb(inport, eth.src); next;\n-
      • \n-
    \n-
    • \n-\n-
  • \n- One priority-0 fallback flow that matches all packets and advances to\n- the next table.\n-
    • \n-
\n-\n-

Ingress Table 4: Learn MAC of 'unknown' ports.

\n-\n-

\n- This table learns the MAC addresses seen on the VIF or 'switch' logical\n- ports whose port security is disabled and 'unknown' address set (note:\n- 'switch' ports have implicit 'unknown' addresses) as well\n- as on localnet ports with localnet_learn_fdb option set\n- if the lookup_fdb action returned false in the\n- previous table. For localnet ports (with flags.localnet = 1),\n- lookup_fdb returns true if (port, mac) is found or if a mac\n- is found for a port of type vif.\n-

\n-\n-
    \n-
  • \n-

    \n- For each such VIF logical port p whose port security is\n- disabled and 'unknown' address set and localnet port following flow\n- is added.\n-

    \n-\n-
      \n-
    • \n- Priority 100 flow with the match\n- inport == p && reg0[11] == 0 and\n- action put_fdb(inport, eth.src); next; which stores\n- the port-mac in the mac learning table of the\n- logical switch datapath and advances the packet to the next table.\n-
      • \n-
    \n-
    • \n-\n-
  • \n- One priority-0 fallback flow that matches all packets and advances to\n- the next table.\n-
    • \n-
\n-\n-

Ingress Table 5: from-lport Pre-ACLs

\n-\n-

\n- This table prepares flows for possible stateful ACL processing in\n- ingress table ACLs. It contains a priority-0 flow that\n- simply moves traffic to the next table. If stateful ACLs are used in the\n- logical datapath, a priority-100 flow is added that sets a hint\n- (with reg0[0] = 1; next;) for table\n- Pre-stateful to send IP packets to the connection tracker\n- before eventually advancing to ingress table ACLs. If\n- special ports such as route ports or localnet ports can't use ct(), a\n- priority-110 flow is added to skip over stateful ACLs. This\n- priority-110 flow is not addd for router ports if the option\n- enable_router_port_acl is set to true in\n- column of\n- . Multicast, IPv6\n- Neighbor Discovery and MLD traffic also skips stateful ACLs. For\n- \"allow-stateless\" ACLs, a flow is added to bypass setting the hint for\n- connection tracker processing when there are stateful ACLs or LB rules;\n- REGBIT_ACL_STATELESS is set for traffic matching stateless\n- ACL flows.\n-

\n-\n-

\n- This table also has a priority-110 flow with the match\n- eth.dst == E for all logical switch\n- datapaths to move traffic to the next table. Where E\n- is the service monitor mac defined in the\n- column of table.\n-

\n-\n-

Ingress Table 6: Pre-LB

\n-\n-

\n- This table prepares flows for possible stateful load balancing processing\n- in ingress table LB and Stateful. It contains\n- a priority-0 flow that simply moves traffic to the next table. Moreover\n- it contains two priority-110 flows to move multicast, IPv6 Neighbor\n- Discovery and MLD traffic to the next table. It also contains two\n- priority-110 flows to move stateless traffic, i.e traffic for which\n- REGBIT_ACL_STATELESS is set, to the next table. If load\n- balancing rules with virtual IP addresses (and ports) are configured in\n- OVN_Northbound database for a logical switch datapath, a\n- priority-100 flow is added with the match ip to match on IP\n- packets and sets the action reg0[2] = 1; next; to act as a\n- hint for table Pre-stateful to send IP packets to the\n- connection tracker for packet de-fragmentation (and to possibly do DNAT\n- for already established load balanced traffic) before eventually\n- advancing to ingress table Stateful.\n- If controller_event has been enabled and load balancing rules with\n- empty backends have been added in OVN_Northbound, a 130 flow\n- is added to trigger ovn-controller events whenever the chassis receives a\n- packet for that particular VIP. If event-elb meter has been\n- previously created, it will be associated to the empty_lb logical flow\n-

\n-\n-

\n- Prior to OVN 20.09 we were setting the\n- reg0[0] = 1 only if the IP destination matches the load\n- balancer VIP. However this had few issues cases where a logical switch\n- doesn't have any ACLs with allow-related action.\n- To understand the issue lets a take a TCP load balancer -\n- 10.0.0.10:80=10.0.0.3:80. If a logical port - p1 with\n- IP - 10.0.0.5 opens a TCP connection with the VIP - 10.0.0.10, then the\n- packet in the ingress pipeline of 'p1' is sent to the p1's conntrack zone\n- id and the packet is load balanced to the backend - 10.0.0.3. For the\n- reply packet from the backend lport, it is not sent to the conntrack of\n- backend lport's zone id. This is fine as long as the packet is valid.\n- Suppose the backend lport sends an invalid TCP packet (like incorrect\n- sequence number), the packet gets delivered to the lport 'p1' without\n- unDNATing the packet to the VIP - 10.0.0.10. And this causes the\n- connection to be reset by the lport p1's VIF.\n-

\n-\n-

\n- We can't fix this issue by adding a logical flow to drop ct.inv packets\n- in the egress pipeline since it will drop all other connections not\n- destined to the load balancers. To fix this issue, we send all the\n- packets to the conntrack in the ingress pipeline if a load balancer is\n- configured. We can now add a lflow to drop ct.inv packets.\n-

\n-\n-

\n- This table also has priority-120 flows that punt all IGMP/MLD packets to\n- ovn-controller if the switch is an interconnect switch\n- with multicast snooping enabled.\n-

\n-\n-

\n- This table also has a priority-110 flow with the match\n- eth.dst == E for all logical switch\n- datapaths to move traffic to the next table. Where E\n- is the service monitor mac defined in the\n- column of table.\n-

\n-\n-

\n- This table also has a priority-110 flow with the match\n- inport == I for all logical switch\n- datapaths to move traffic to the next table. Where I\n- is the peer of a logical router port. This flow is added to\n- skip the connection tracking of packets which enter from\n- logical router datapath to logical switch datapath.\n-

\n-\n-

Ingress Table 7: Pre-stateful

\n-\n-

\n- This table prepares flows for all possible stateful processing\n- in next tables. It contains a priority-0 flow that simply moves\n- traffic to the next table.\n-

\n-
    \n-
  • \n- Priority-120 flows that send the packets to connection tracker using\n- ct_lb_mark; as the action so that the already established\n- traffic destined to the load balancer VIP gets DNATted. These flows\n- match each VIPs IP and port. For IPv4 traffic the flows also load the\n- original destination IP and transport port in registers\n- reg1 and reg2. For IPv6 traffic the flows\n- also load the original destination IP and transport port in\n- registers xxreg1 and reg2.\n-
    • \n-\n-
  • \n- A priority-110 flow sends the packets that don't match the above flows\n- to connection tracker based on a hint provided by the previous tables\n- (with a match for reg0[2] == 1) by using the\n- ct_lb_mark; action.\n-
    • \n-\n-
  • \n- A priority-105 added enabled when enable-stateless-acl-with-lb and\n- send all packet directed to VIP that don't match the above flows to\n- connection tracker.\n-
    • \n-\n-
  • \n- A priority-100 flow sends the packets to connection tracker based\n- on a hint provided by the previous tables\n- (with a match for reg0[0] == 1) by using the\n- ct_next; action.\n-
    • \n-
\n-\n-

Ingress Table 8: from-lport ACL hints

\n-\n-

\n- This table consists of logical flows that set hints\n- (reg0 bits) to be used in the next stage, in the ACL\n- processing table, if stateful ACLs or load balancers are configured.\n- Multiple hints can be set for the same packet.\n- The possible hints are:\n-

\n-
    \n-
  • \n- reg0[7]: the packet might match an\n- allow-related ACL and might have to commit the\n- connection to conntrack.\n-
    • \n-
  • \n- reg0[8]: the packet might match an\n- allow-related ACL but there will be no need to commit\n- the connection to conntrack because it already exists.\n-
    • \n-
  • \n- reg0[9]: the packet might match a\n- drop/reject.\n-
    • \n-
  • \n- reg0[10]: the packet might match a\n- drop/reject ACL but the connection was previously\n- allowed so it might have to be committed again with\n- ct_label=1/1.\n-
    • \n-
\n-\n-

\n- The table contains the following flows:\n-

\n-
    \n-
  • \n- A priority-65535 flow to advance to the next table if the logical\n- switch has no ACLs configured, otherwise a\n- priority-0 flow to advance to the next table.\n-
    • \n-
\n-\n-
    \n-
  • \n- A priority-7 flow that matches on packets that initiate a new session.\n- This flow sets reg0[7] and reg0[9] and\n- then advances to the next table.\n-
    • \n-
  • \n- A priority-6 flow that matches on packets that are in the request\n- direction of an already existing session that has been marked\n- as blocked. This flow sets reg0[7] and\n- reg0[9] and then advances to the next table.\n-
    • \n-
  • \n- A priority-5 flow that matches untracked packets. This flow sets\n- reg0[8] and reg0[9] and then advances to\n- the next table.\n-
    • \n-
  • \n- A priority-4 flow that matches on packets that are in the request\n- direction of an already existing session that has not been marked\n- as blocked. This flow sets reg0[8] and\n- reg0[10] and then advances to the next table.\n-
    • \n-
  • \n- A priority-3 flow that matches on packets that are in not part of\n- established sessions. This flow sets reg0[9] and then\n- advances to the next table.\n-
    • \n-
  • \n- A priority-2 flow that matches on packets that are part of an\n- established session that has been marked as blocked.\n- This flow sets reg0[9] and then advances to the next\n- table.\n-
    • \n-
  • \n- A priority-1 flow that matches on packets that are part of an\n- established session that has not been marked as blocked.\n- This flow sets reg0[10] and then advances to the next\n- table.\n-
    • \n-
\n-\n-

Ingress table 9: from-lport ACL evaluation before LB

\n-\n-

\n- Logical flows in this table closely reproduce those in the\n- ACL table in the OVN_Northbound database\n- for the from-lport direction without the option\n- apply-after-lb set or set to false.\n- The priority values from the ACL table have a\n- limited range and have 1000 added to them to leave room for OVN default\n- flows at both higher and lower priorities.\n-

\n-
    \n-
  • \n- This table is responsible for evaluating ACLs, and setting a register\n- bit to indicate whether the ACL decided to allow, drop, or reject the\n- traffic. The allow bit is reg8[16]. The drop bit is\n- reg8[17]. All flows in this table will advance the packet\n- to the next table, where the bits from before are evaluated to\n- determine what to do with the packet. Any flows in this table that\n- intend for the packet to pass will set reg8[16] to 1,\n- even if an ACL with an allow-type action was not matched. This lets the\n- next table know to allow the traffic to pass. These bits will be\n- referred to as the \"allow\", \"drop\", and \"reject\" bits in the upcoming\n- paragraphs.\n-
    • \n-
  • \n- If the tier column has been configured on the ACL, then\n- OVN will also match the current tier counter against the configured\n- ACL tier. OVN keeps count of the current tier in\n- reg8[30..31].\n-
    • \n-
  • \n- allow ACLs translate into logical flows that set the allow\n- bit to 1 and advance the packet to the next table. If there are any\n- stateful ACLs on this datapath, then allow ACLs set the\n- allow bit to one and in addition perform ct_commit; (which\n- acts as a hint for future tables to commit the connection to\n- conntrack). In case the ACL has a label then\n- reg3 is loaded with the label value and\n- reg0[13] bit is set to 1 (which acts as a hint for the\n- next tables to commit the label to conntrack).\n-
    • \n-
  • \n- allow-related ACLs translate into logical flows that set\n- the allow bit and additionally have ct_commit { ct_label=0/1; };\n- next; actions for new connections and reg0[1] = 1;\n- next; for existing connections. In case the ACL\n- has a label then reg3 is loaded with the label value and\n- reg0[13] bit is set to 1 (which acts as a hint for the\n- next tables to commit the label to conntrack).\n-
    • \n-
  • \n- For allow and allow-related ACL, an\n- additonal set of registers get set in case the ACL has the column\n- network_function_group set to the id of one\n- of the entities in Network_Function_Group table. The\n- id is an internally generated unique identifier for a\n- Network_Function_Group entity. The flow sets\n- reg8[21] = 1 (to indicate need for packet redirection),\n- reg8[22] = 1 (to indicate this is a request packet) and\n- reg0[22..29] = id. These registers are later\n- used in the Network Function table.\n-
    • \n-\n-
  • \n- allow-stateless ACLs translate into logical flows that set\n- the allow bit and advance to the next table.\n-
    • \n-
  • \n- reject ACLs translate into logical flows with that set the\n- reject bit and advance to the next table.\n-
    • \n-
  • \n- pass ACLs translate into logical flows that do not set the\n- allow, drop, or reject bit and advance to the next table.\n-
    • \n-
  • \n- Other ACLs set the drop bit and advance to the next table for new or\n- untracked connections. For known connections, they set the drop bit,\n- as well as running the ct_commit { ct_label=1/1; };\n- action. Setting ct_label marks a connection as one that\n- was previously allowed, but should no longer be allowed due to a policy\n- change.\n-
    • \n-
\n-\n-

\n- This table contains a priority-65535 flow to set the allow bit and\n- advance to the next table if the logical switch has no\n- ACLs configured, otherwise a priority-0 flow to advance to the next\n- table is added. This flow does not set the allow bit, so that the next\n- table can decide whether to allow or drop the packet based on the value\n- of the column of the table.\n-

\n-\n-

\n- A priority-65532 flow is added that sets the allow bit for\n- IPv6 Neighbor solicitation, Neighbor discover, Router solicitation,\n- Router advertisement and MLD packets regardless of other ACLs defined.\n-

\n-\n-

\n- If the logical datapath has a stateful ACL or a load balancer with VIP\n- configured, the following flows will also be added:\n-

\n-\n-
    \n-
  • \n- If column of is false or not set, a priority-1\n- flow that sets the hint to commit IP traffic that is not part of\n- established sessions to the connection tracker (with action\n- reg0[1] = 1; next;). This is needed for\n- the default allow policy because, while the initiator's direction\n- may not have any stateful rules, the server's may and then\n- its return traffic would not be known and marked as invalid.\n-
    • \n-\n-
  • \n- A priority-1 flow that sets the allow bit and sets the hint to commit\n- IP traffic to the connection tracker (with action reg0[1] = 1;\n- next;). This is needed for the default allow policy because,\n- while the initiator's direction may not have any stateful rules, the\n- server's may and then its return traffic would not be known and marked\n- as invalid.\n-
    • \n-\n-
  • \n- A priority-65532 flow that sets the allow bit for any traffic in the\n- reply direction for a connection that has been committed to the\n- connection tracker (i.e., established flows), as long as\n- the committed flow does not have ct_mark.blocked set.\n- We only handle traffic in the reply direction here because\n- we want all packets going in the request direction to still\n- go through the flows that implement the currently defined\n- policy based on ACLs. If a connection is no longer allowed by\n- policy, ct_mark.blocked will get set and packets in the\n- reply direction will no longer be allowed, either. This flow also\n- clears the register bits reg0[9] and\n- reg0[10] and sets register bit reg0[17].\n- If ACL logging and logging of related packets is enabled, then a\n- companion priority-65533 flow will be installed that\n- accomplishes the same thing but also logs the traffic.\n-
    • \n-\n-
  • \n- The priority-65532 flows that allow response and related traffic, also\n- set reg8[21] = ct_label.nf, which gets checked in\n- the Network Function table.\n-
    • \n-\n-
  • \n- A priority-65532 flow that sets the allow bit for any traffic that is\n- considered related to a committed flow in the connection tracker (e.g.,\n- an ICMP Port Unreachable from a non-listening UDP port), as long\n- as the committed flow does not have ct_mark.blocked set.\n- This flow also applies NAT to the related traffic so that ICMP headers\n- and the inner packet have correct addresses.\n- If ACL logging and logging of related packets is enabled, then a\n- companion priority-65533 flow will be installed that accomplishes the\n- same thing but also logs the traffic.\n-
    • \n-\n-
  • \n- A priority-65532 flow that sets the drop bit for all traffic marked by\n- the connection tracker as invalid.\n-
    • \n-\n-
  • \n- A priority-65532 flow that sets the drop bit for all traffic in the\n- reply direction with ct_mark.blocked set meaning that the\n- connection should no longer be allowed due to a policy change. Packets\n- in the request direction are skipped here to let a newly created\n- ACL re-allow this connection.\n-
    • \n-
\n-\n-

\n- If the logical datapath has any ACL or a load balancer with VIP\n- configured, the following flow will also be added:\n-

\n-\n-
    \n-
  • \n- A priority 34000 logical flow is added for each logical switch datapath\n- with the match eth.dst = E to allow the service\n- monitor reply packet destined to ovn-controller\n- that sets the allow bit, where E is the\n- service monitor mac defined in the\n- column of table.\n-
    • \n-
\n-\n-

Ingress Table 10: from-lport ACL sampling

\n-\n-

\n- Logical flows in this table sample traffic matched by\n- from-lport ACLs with sampling enabled.\n-

\n-\n-
    \n-
  • \n- If no ACLs have sampling enabled, then a priority 0 flow is installed\n- that matches everything and advances to the next table.\n-
    • \n-\n-
  • \n- For each ACL with sample_new configured a priority 1100 flow is\n- installed that matches on the saved observation_point_id value.\n- This flow generates a sample() action and then advances\n- the packet to the next table.\n-
    • \n-\n-
  • \n- For each ACL with sample_est configured a priority 1200 flow is\n- installed that matches on the saved observation_point_id value\n- for established traffic in the original direction. This flow\n- generates a sample() action and then advances\n- the packet to the next table.\n-
    • \n-\n-
  • \n- For each ACL with sample_est configured a priority 1200 flow is\n- installed that matches on the saved observation_point_id\n- value for established traffic in the reply direction. This flow\n- generates a sample() action and then advances\n- the packet to the next table. Note: this flow is installed in the\n- opposite pipeline (in the ingress pipeline for ACLs applied in the\n- egress direction and in the egress pipeline for ACLs applied in the\n- ingress direction).\n-
    • \n-
\n-\n-

Ingress Table 11: from-lport ACL action

\n-\n-

\n- Logical flows in this table decide how to proceed based on the values of\n- the allow, drop, and reject bits that may have been set in the previous\n- table.\n-

\n-\n-
    \n-
  • \n- If no ACLs are configured, then a priority 0 flow is installed that\n- matches everything and advances to the next table.\n-
    • \n-\n-
  • \n- A priority 1000 flow is installed that will advance the packet to the\n- next table if the allow bit is set.\n-
    • \n-\n-
  • \n- A priority 1000 flow is installed that will run the drop;\n- action if the drop bit is set.\n-
    • \n-\n-
  • \n- A priority 1000 flow is installed that will run the tcp_reset\n- { output <-> inport; next(pipeline=egress,table=5);}\n- action for TCP connections,icmp4/icmp6 action\n- for UDP connections, and sctp_abort {output <-%gt; inport;\n- next(pipeline=egress,table=5);} action for SCTP associations.\n-
    • \n-\n-
  • \n- If any ACLs have tiers configured on them, then three priority 500\n- flows are installed. If the current tier counter is 0, 1, or 2, then\n- the current tier counter is incremented by one and the packet is sent\n- back to the previous table for re-evaluation.\n-
    • \n-
\n-\n-

Ingress Table 12: from-lport QoS

\n-\n-

\n- Logical flows in this table closely reproduce those in the\n- QoS table with the action or\n- bandwidth column set in the\n- OVN_Northbound database for the\n- from-lport direction.\n-

\n-\n-
    \n-
  • \n- For every qos_rules entry in a logical switch with DSCP marking,\n- packet marking or metering enabled a flow will be added at the priority\n- mentioned in the QoS table.\n-
    • \n-\n-
  • \n- One priority-0 fallback flow that matches all packets and advances to\n- the next table.\n-
    • \n-
\n-\n-

Ingress Table 13: Connection Tracking Field Extraction

\n-\n-

\n- This table extracts connection tracking fields for new connections\n- to be used by subsequent load balancing stages.\n-

\n-\n-
    \n-
  • \n- A priority-100 flow matches ct.new && ip and\n- extracts connection tracking protocol and destination port information\n- into registers reg1[16..23] (protocol) and\n- reg1[0..15] (destination port) using the actions\n- reg1[16..23] = ct_proto(); reg1[0..15] = ct_tp_dst(); next;.\n-
    • \n-\n-
  • \n- A priority-0 flow matches all packets and advances to the next table.\n-
    • \n-
\n-\n-

Ingress Table 14: Load balancing affinity check

\n-\n-

\n- Load balancing affinity check table contains the following\n- logical flows:\n-

\n-\n-
    \n-
  • \n- For all the configured load balancing rules for a switch in\n- OVN_Northbound database where a positive affinity timeout\n- is specified in options column, that includes a L4 port\n- PORT of protocol P and IP address VIP,\n- a priority-100 flow is added. For IPv4 VIPs, the flow\n- matches ct.new && ip && ip4.dst == VIP\n- && reg1[16..23] == PROTO_NUM &&\n- reg1[0..15] == PORT. For IPv6\n- VIPs, the flow matches ct.new && ip &&\n- ip6.dst == VIP && reg1[16..23] ==\n- PROTO_NUM && reg1[0..15] == PORT.\n- The flow's action is reg9[6] = chk_lb_aff(); next;.\n-
    • \n-\n-
  • \n- A priority 0 flow is added which matches on all packets and applies\n- the action next;.\n-
    • \n-
\n-\n-

Ingress Table 15: LB

\n-\n-
    \n-
  • \n- For all the configured load balancing rules for a switch in\n- OVN_Northbound database where a positive affinity timeout\n- is specified in options column, that includes a L4 port\n- PORT of protocol P and IP address VIP,\n- a priority-150 flow is added. For IPv4 VIPs, the flow\n- matches reg9[6] == 1 && ct.new && ip &&\n- ip4.dst == VIP && P.dst == PORT\n- . For IPv6 VIPs, the flow matches\n- reg9[6] == 1 && ct.new && ip &&\n- ip6.dst == VIP && P &&\n- P.dst == PORT.\n- The flow's action is ct_lb_mark(args), where\n- args contains comma separated IP addresses (and optional\n- port numbers) to load balance to. The address family of the IP\n- addresses of args is the same as the address family\n- of VIP.\n-
    • \n-\n-
  • \n- For all the configured load balancing rules for a switch in\n- OVN_Northbound database that includes a L4 port\n- PORT of protocol P and IP address\n- VIP, a priority-120 flow is added. For IPv4 VIPs\n- , the flow matches ct.new && ip &&\n- ip4.dst == VIP && reg1[16..23] ==\n- PROTO_NUM && reg1[0..15] == PORT.\n- For IPv6 VIPs,\n- the flow matches ct.new && ip && ip6.dst == \n- VIP && reg1[16..23] == PROTO_NUM &&\n- reg1[0..15] == PORT. The flow's action is\n- ct_lb_mark(args)\n- , where args contains comma separated IP addresses\n- (and optional port numbers) to load balance to. The address family of\n- the IP addresses of args is the same as the address family\n- of VIP. If health check is enabled, then args\n- will only contain those endpoints whose service monitor status entry\n- in OVN_Southbound db is either online or\n- empty. For IPv4 traffic the flow also loads the original destination\n- IP and transport port in registers reg1 and\n- reg2. For IPv6 traffic the flow also loads the original\n- destination IP and transport port in registers xxreg1 and\n- reg2.\n- The above flow is created even if the load balancer is attached to a\n- logical router connected to the current logical switch and\n- the install_ls_lb_from_router variable in\n- is set to true.\n-
    • \n-
  • \n- For all the configured load balancing rules for a switch in\n- OVN_Northbound database that includes just an IP address\n- VIP to match on, OVN adds a priority-110 flow. For IPv4\n- VIPs, the flow matches ct.new && ip &&\n- ip4.dst == VIP. For IPv6 VIPs,\n- the flow matches ct.new && ip && ip6.dst == \n- VIP. The action on this flow is \n- ct_lb_mark(args), where args contains comma\n- separated IP addresses of the same address family as VIP.\n- For IPv4 traffic the flow also loads the original destination\n- IP and transport port in registers reg1 and\n- reg2. For IPv6 traffic the flow also loads the original\n- destination IP and transport port in registers xxreg1 and\n- reg2.\n- The above flow is created even if the load balancer is attached to a\n- logical router connected to the current logical switch and\n- the install_ls_lb_from_router variable in\n- is set to true.\n-
    • \n-\n-
  • \n- If the load balancer is created with --reject option and\n- it has no active backends, a TCP reset segment (for tcp) or an ICMP\n- port unreachable packet (for all other kind of traffic) will be sent\n- whenever an incoming packet is received for this load-balancer.\n- Please note using --reject option will disable\n- empty_lb SB controller event for this load balancer.\n-
    • \n-
\n-\n-

Ingress Table 16: Load balancing affinity learn

\n-\n-

\n- Load balancing affinity learn table contains the following\n- logical flows:\n-

\n-\n-
    \n-
  • \n- For all the configured load balancing rules for a switch in\n- OVN_Northbound database where a positive affinity timeout\n- T is specified in options column, that includes\n- a L4 port PORT of protocol P and IP address\n- VIP, a priority-100 flow is added. For IPv4 VIPs,\n- the flow matches reg9[6] == 0 && ct.new && ip\n- && ip4.dst == VIP && P.dst ==\n- PORT. For IPv6 VIPs, the flow matches\n- ct.new && ip && ip6.dst == VIP\n- && P && P.dst == PORT\n- . The flow's action is commit_lb_aff(vip =\n- VIP:PORT, backend = backend ip:\n- backend port, proto = P, timeout = T);\n- .\n-
    • \n-\n-
  • \n- A priority 0 flow is added which matches on all packets and applies\n- the action next;.\n-
    • \n-
\n-\n-

Ingress Table 17: Pre-Hairpin

\n-
    \n-
  • \n- If the logical switch has load balancer(s) configured, then a\n- priority-100 flow is added with the match\n- ip && ct.trk to check if the\n- packet needs to be hairpinned (if after load balancing the destination\n- IP matches the source IP) or not by executing the actions\n- reg0[6] = chk_lb_hairpin(); and\n- reg0[12] = chk_lb_hairpin_reply(); and advances the packet\n- to the next table.\n-
    • \n-\n-
  • \n- A priority-0 flow that simply moves traffic to the next table.\n-
    • \n-
\n-\n-

Ingress Table 18: Nat-Hairpin

\n-
    \n-
  • \n- If the logical switch has load balancer(s) configured, then a\n- priority-100 flow is added with the match\n- ip && ct.new && ct.trk &&\n- reg0[6] == 1 which hairpins the traffic by\n- NATting source IP to the load balancer VIP by executing the action\n- ct_snat_to_vip and advances the packet to the next table.\n-
    • \n-\n-
  • \n- If the logical switch has load balancer(s) configured, then a\n- priority-100 flow is added with the match\n- ip && ct.est && ct.trk &&\n- reg0[6] == 1 which hairpins the traffic by\n- NATting source IP to the load balancer VIP by executing the action\n- ct_snat and advances the packet to the next table.\n-
    • \n-\n-
  • \n- If the logical switch has load balancer(s) configured, then a\n- priority-90 flow is added with the match\n- ip && reg0[12] == 1 which matches on the replies\n- of hairpinned traffic (i.e., destination IP is VIP,\n- source IP is the backend IP and source L4 port is backend port for L4\n- load balancers) and executes ct_snat and advances the\n- packet to the next table.\n-
    • \n-\n-
  • \n- A priority-0 flow that simply moves traffic to the next table.\n-
    • \n-
\n-\n-

Ingress Table 19: Hairpin

\n-
    \n-
  • \n-

    \n- If logical switch has attached logical switch port of vtep\n- type, then for each distributed gateway router port RP\n- attached to this logical switch and has chassis redirect port\n- cr-RP, a priority-2000 flow is added with the match\n- 

    \n-reg0[14] == 1 && is_chassis_resident(cr-RP)\n-
    \n- and action next;.\n-

    \n-\n-

    \n- reg0[14] register bit is set in the ingress L2 port\n- security check table for traffic received from HW VTEP (ramp) ports.\n-

    \n-
    • \n-\n-
  • \n- If logical switch has attached logical switch port of vtep\n- type, then a priority-1000 flow that matches on\n- reg0[14] register bit for the traffic received from HW\n- VTEP (ramp) ports. This traffic is passed to ingress table\n- ls_in_l2_lkup.\n-
    • \n-
  • \n- A priority-1 flow that hairpins traffic matched by non-default\n- flows in the Pre-Hairpin table. Hairpinning is done at L2, Ethernet\n- addresses are swapped and the packets are looped back on the input\n- port.\n-
    • \n-
  • \n- A priority-0 flow that simply moves traffic to the next table.\n-
    • \n-
\n-\n-

Ingress table 20: from-lport ACL evaluation after LB

\n-\n-

\n- Logical flows in this table closely reproduce those in the\n- ACL eval table in the OVN_Northbound database\n- for the from-lport direction with the option\n- apply-after-lb set to true.\n- The priority values from the ACL table have a\n- limited range and have 1000 added to them to leave room for OVN default\n- flows at both higher and lower priorities. The flows in this table\n- indicate the ACL verdict by setting reg8[16] for\n- allow-type ACLs, reg8[17] for drop\n- ACLs, and reg8[17] for reject ACLs, and then\n- advancing the packet to the next table. These will be reffered to as the\n- allow bit, drop bit, and reject bit throughout the documentation for this\n- table and the next one.\n-

\n-\n-

\n- Like with ACLs that are evaluated before load balancers, if the ACL is\n- configured with a tier value, then the current tier counter, supplied\n- in reg8[30..31] is matched against the ACL's configured tier in addition\n- to the ACL's match.\n-

\n-\n-
    \n-
  • \n- allow apply-after-lb ACLs translate into logical flows\n- that set the allow bit. If there are any stateful ACLs\n- (including both before-lb and after-lb ACLs)\n- on this datapath, then allow ACLs also run\n- ct_commit; next; (which acts as a hint for an upcoming\n- table to commit the connection to conntrack). In case the\n- ACL has a label then reg3 is loaded with the\n- label value and reg0[13] bit is set to 1 (which acts as a\n- hint for the next tables to commit the label to conntrack).\n-
    • \n-
  • \n- allow-related apply-after-lb ACLs translate into logical\n- flows that set the allow bit and run the\n- ct_commit {ct_label=0/1; }; next; actions for new\n- connections and reg0[1] = 1; next; for existing\n- connections. In case the ACL has a label then\n- reg3 is loaded with the label value and\n- reg0[13] bit is set to 1 (which acts as a hint for the\n- next tables to commit the label to conntrack).\n-
    • \n-
  • \n- allow-stateless apply-after-lb ACLs translate into logical\n- flows that set the allow bit and advance to the next table.\n-
    • \n-
  • \n- reject apply-after-lb ACLs translate into logical\n- flows that set the reject bit and advance to the next table.\n-
    • \n-
  • \n- pass apply-after-lb ACLs translate into logical flows that\n- do not set the allow, drop, or reject bit and advance to the next\n- table.\n-
    • \n-
  • \n- Other apply-after-lb ACLs set the drop bit for new or untracked\n- connections and ct_commit { ct_label=1/1; } for known\n- connections. Setting ct_label marks a connection\n- as one that was previously allowed, but should no longer be\n- allowed due to a policy change.\n-
    • \n-
\n-\n-
    \n-
  • \n- One priority-65532 flow matching packets with reg0[17]\n- set (either replies to existing sessions or traffic related to\n- existing sessions) and allows these by setting the allow bit and\n- advancing to the next table.\n-
    • \n-
\n-\n-
    \n-
  • \n- One priority-0 fallback flow that matches all packets and advances to\n- the next table.\n-
    • \n-
\n-\n-

Ingress Table 21: from-lport ACL sampling after LB

\n-\n-

\n- Logical flows in this table sample traffic matched by\n- from-lport ACLs (evaluation after LB) with sampling enabled.\n-

\n-\n-
    \n-
  • \n- If no ACLs have sampling enabled, then a priority 0 flow is installed\n- that matches everything and advances to the next table.\n-
    • \n-\n-
  • \n- For each ACL with sample_new configured a priority 1100 flow is\n- installed that matches on the saved observation_point_id value.\n- This flow generates a sample() action and then advances\n- the packet to the next table.\n-
    • \n-\n-
  • \n- For each ACL with sample_est configured a priority 1200 flow is\n- installed that matches on the saved observation_point_id value\n- for established traffic in the original direction. This flow\n- generates a sample() action and then advances\n- the packet to the next table.\n-
    • \n-\n-
  • \n- For each ACL with sample_est configured a priority 1200 flow is\n- installed that matches on the saved observation_point_id\n- value for established traffic in the reply direction. This flow\n- generates a sample() action and then advances\n- the packet to the next table. Note: this flow is installed in the\n- opposite pipeline (in the ingress pipeline for ACLs applied in the\n- egress direction and in the egress pipeline for ACLs applied in the\n- ingress direction).\n-
    • \n-
\n-\n-

Ingress Table 22: from-lport ACL action after LB

\n-\n-

\n- Logical flows in this table decide how to proceed based on the values of\n- the allow, drop, and reject bits that may have been set in the previous\n- table.\n-

\n-\n-
    \n-
  • \n- If no ACLs are configured, then a priority 0 flow is installed that\n- matches everything and advances to the next table.\n-
    • \n-\n-
  • \n- A priority 1000 flow is installed that will advance the packet to the\n- next table if the allow bit is set.\n-
    • \n-\n-
  • \n- A priority 1000 flow is installed that will run the drop;\n- action if the drop bit is set.\n-
    • \n-\n-
  • \n- A priority 1000 flow is installed that will run the tcp_reset\n- { output <-> inport; next(pipeline=egress,table=5);}\n- action for TCP connections,icmp4/icmp6 action\n- for UDP connections, and sctp_abort {output <-%gt; inport;\n- next(pipeline=egress,table=5);} action for SCTP associations.\n-
    • \n-\n-
  • \n- If any ACLs have tiers configured on them, then three priority 500\n- flows are installed. If the current tier counter is 0, 1, or 2, then\n- the current tier counter is incremented by one and the packet is sent\n- back to the previous table for re-evaluation.\n-
    • \n-
\n-\n-

Ingress Table 23: Pre Network Function

\n-

\n- This stage selects the active network function from a\n- Network_Function_Group based on the network function group\n- ID set by the ACL eval stage earlier. This stage is applicable for\n- request packets of from-lport ACLs\n- (reg8[22] == 1). Response packets for\n- to-lport ACLs bypass this stage and use\n- ct_label.nf_id directly in the Network Function table.\n-

\n-\n-

\n- A network function group can contain one or more network functions.\n- Health monitoring is performed by sending datapath probes as per\n- parameters defined in Network_Function_Health_Check. This\n- stage selects one of the healthy network functions. If none are healthy,\n- the behavior follows the fallback column configured in the\n- Network_Function_Group table. If health monitoring is not\n- configured, any one from the group is selected.\n-

\n-\n-

\n- When a request packet matches a from-lport ACL with\n- network_function_group set, the ACL eval stage sets\n- reg8[21] = 1 (NF enabled), reg8[22] = 1\n- (request direction), and reg0[22..29] to the network\n- function group ID. This table then selects the active network function\n- from the group and overwrites reg0[22..29] with the\n- specific id of a Network_Function table entry.\n- The subsequent Network Function table uses this NF ID to redirect packets\n- to the appropriate network function port. In the future, this stage will\n- be extended to support network function load balancing.\n-

\n-\n-
    \n-
  • \n- For each network_function_group id with an active network\n- function, a priority-99 flow matches reg8[21] == 1 &&\n- reg8[22] == 1 && reg0[22..29] == id and\n- sets reg0[22..29] = nf_id; next; where\n- nf_id is the ID of the active network function. This\n- prepares request packets that matched a from-lport ACL\n- with network_function_group for redirection in the subsequent Network\n- Function table.\n-
    • \n-\n-
  • \n- For each network function group with id that has\n- fallback set to fail-open, a priority-10 flow\n- matches reg8[21] == 1 && reg8[22] == 1 &&\n- reg0[22..29] == id and sets reg8[21] = 0;\n- reg0[22..29] = 0; next;. This clears both the NF enabled bit and\n- the NF group ID, allowing packets to continue processing through the\n- pipeline without network function redirection when no active network\n- function is available (fail-open behavior).\n-
    • \n-\n-
  • \n- A priority-1 flow matches reg8[21] == 1 && reg8[22] == 1\n- and sets reg0[22..29] = 0; next;. This is a\n- catch-all flow for network function groups with fallback\n- set to fail-close (or default) when no active network\n- function is available. It clears only the NF group ID, leaving the NF\n- enabled bit set. These packets will be dropped by the priority-1 drop\n- rule in the subsequent Network Function table (fail-close behavior).\n-
    • \n-\n-
  • \n- A priority-0 flow that simply moves traffic to the next table.\n-
    • \n-
\n-\n-

Ingress Table 24: Stateful

\n-\n-
    \n-
  • \n- A priority 100 flow is added which commits the packet to the conntrack\n- and sets the most significant 32-bits of ct_label with the\n- reg3 value based on the hint provided by previous tables\n- (with a match for reg0[1] == 1 && reg0[13] == 1).\n- This is used by the ACLs with label to commit the label\n- value to conntrack.\n-
    • \n-\n-
  • \n- For ACLs without label, a second priority-100 flow commits\n- packets to connection tracker using ct_commit; next;\n- action based on a hint provided by the previous tables (with a match\n- for reg0[1] == 1 && reg0[13] == 0).\n-
    • \n-\n-
  • \n- Corresponding to each of the two priority 100 flows above, a priority\n- 110 flow is added, which has the following extra match and\n- action, but otherwise identical to the priority 100 flow.\n- Match: reg8[21] == 1 (packet matched an ACL with\n- network_function_group set)\n- Action: ct_label.nf = 1;\n- ct_label.nf_id = reg0[22..29];\n- This is to commit the network_function information in conntrack so that\n- the response and related packets can be redirected to it as well.\n-
    • \n-\n-
  • \n- A priority-0 flow that simply moves traffic to the next table.\n-
    • \n-
\n-\n-

Ingress Table 25: Network Function

\n-

\n- This table implements packet redirection to network functions. When a\n- packet matches an ACL with network_function_group column\n- set to the id of a Network_Function_Group\n- table entry, the ACL eval stage sets reg8[21] = 1 (NF\n- enabled), reg8[22] = 1 (request direction), and\n- reg0[22..29] to the network function group ID. The Pre\n- Network Function stage then selects the active network function from the\n- group and overwrites reg0[22..29] with the specific\n- id of a Network_Function table entry. This\n- table uses that NF ID to redirect packets to the appropriate network\n- function port.\n-

\n-\n-

\n- This table handles request packets for from-lport ACLs\n- and response packets for to-lport ACLs. For\n- from-lport ACLs, request packets are redirected to the\n- network function's inport, and corresponding\n- response/related packets are handled in the egress pipeline. For\n- to-lport ACLs, request packets are handled in the egress\n- pipeline, but corresponding response/related packets for those flows\n- are redirected here using the network function ID stored in\n- ct_label.nf_id during request processing.\n-

\n-\n-

\n- If the network function ports are not present on this logical switch,\n- their child ports (if any) are used. In the statements below, network\n- function ports refer to either the parent or child ports as applicable to\n- this logical switch.\n-

\n-\n-
    \n-
  • \n- For each network_function port P, a priority-100 flow is\n- added that matches inport == P and advances\n- packets to the next table. Thus packets coming from network function\n- are not subject to redirection. This flow also sets\n- reg5[16..31] = ct_label.tun_if_id. This is used for\n- tunneling packet to originating host in case of cross host traffic\n- redirection for VLAN subnet. This ct_label field stores the openflow\n- tunnel interface id of the originating host for this connection and\n- gets populated in egress Stateful table.\n-
    • \n-\n-
  • \n- For each active network function with id that is referenced\n- in a network function group, a priority-99 flow matches\n- reg8[21] == 1 && reg8[22] == 1 &&\n- reg0[22..29] == id and sets\n- outport=P; output; where P is the\n- inport of that network function. This redirects request\n- packets for flows matching from-lport ACLs with\n- network_function_group to the specific network function selected by\n- the Pre Network Function stage.\n-
    • \n-\n-
  • \n- For each active network function with id that is referenced\n- in a network function group, a priority-99 rule matches\n- reg8[21] == 1 && reg8[22] == 0 &&\n- ct_label.nf_id == id and takes identical action as\n- above. This redirects response and related packets for\n- to-lport ACLs to the same network function that handled\n- the request, using the NF ID stored in the connection tracking label.\n-
    • \n-\n-
  • \n- In each of the above cases, when the same packet comes out unchanged\n- through the other port of the network_function, it would match the\n- priority 100 flow and be forwarded to the next table.\n-
    • \n-\n-
  • \n- One priority-100 rule to skip redirection of multicast packets that hit\n- a network_function ACL. Match on reg8[21] == 1 &&\n- eth.mcast and action is to advance to the next table.\n-
    • \n-\n-
  • \n- One priority-1 rule that checks reg8[21] == 1, and drops\n- such packets. This is to address the case where a packet hit an ACL\n- with network function but the network function does not have ports or\n- child ports on this logical switch.\n-
    • \n-\n-
  • \n- One priority-0 fallback flow that matches all packets and advances to\n- the next table.\n-
    • \n-
\n-\n-

Ingress Table 26: ARP/ND responder

\n-\n-

\n- This table implements ARP/ND responder in a logical switch for known\n- IPs. The advantage of the ARP responder flow is to limit ARP\n- broadcasts by locally responding to ARP requests without the need to\n- send to other hypervisors. One common case is when the inport is a\n- logical port associated with a VIF and the broadcast is responded to\n- on the local hypervisor rather than broadcast across the whole\n- network and responded to by the destination VM. This behavior is\n- proxy ARP.\n-

\n-\n-

\n- ARP requests arrive from VMs from a logical switch inport of type\n- default. For this case, the logical switch proxy ARP rules can be\n- for other VMs or logical router ports. Logical switch proxy ARP\n- rules may be programmed both for mac binding of IP addresses on\n- other logical switch VIF ports (which are of the default logical\n- switch port type, representing connectivity to VMs or containers),\n- and for mac binding of IP addresses on logical switch router type\n- ports, representing their logical router port peers. In order to\n- support proxy ARP for logical router ports, an IP address must be\n- configured on the logical switch router type port, with the same\n- value as the peer logical router port. The configured MAC addresses\n- must match as well. When a VM sends an ARP request for a distributed\n- logical router port and if the peer router type port of the attached\n- logical switch does not have an IP address configured, the ARP request\n- will be broadcast on the logical switch. One of the copies of the ARP\n- request will go through the logical switch router type port to the\n- logical router datapath, where the logical router ARP responder will\n- generate a reply. The MAC binding of a distributed logical router,\n- once learned by an associated VM, is used for all that VM's\n- communication needing routing. Hence, the action of a VM re-arping for\n- the mac binding of the logical router port should be rare.\n-

\n-\n-

\n- Logical switch ARP responder proxy ARP rules can also be hit when\n- receiving ARP requests externally on a L2 gateway port. In this case,\n- the hypervisor acting as an L2 gateway, responds to the ARP request on\n- behalf of a destination VM.\n-

\n-\n-

\n- Note that ARP requests received from localnet logical\n- inports can either go directly to VMs, in which case the VM responds or\n- can hit an ARP responder for a logical router port if the packet is used\n- to resolve a logical router port next hop address. In either case,\n- logical switch ARP responder rules will not be hit. It contains these\n- logical flows:\n-

\n-\n-
    \n-
  • \n- If packet was received from HW VTEP (ramp switch), and this packet is\n- ARP or Neighbor Solicitation, such packet is passed to next table with\n- max proirity. ARP/ND requests from HW VTEP must be handled in logical\n- router ingress pipeline.\n-
    • \n-
  • \n- If the logical switch has no router ports with options:arp_proxy\n- configured add a priority-100 flows to skip the ARP responder if inport\n- is of type localnet advances directly to the next table.\n- ARP requests sent to localnet ports can be received by\n- multiple hypervisors. Now, because the same mac binding rules are\n- downloaded to all hypervisors, each of the multiple hypervisors will\n- respond. This will confuse L2 learning on the source of the ARP\n- requests. ARP requests received on an inport of type\n- router are not expected to hit any logical switch ARP\n- responder flows. However, no skip flows are installed for these\n- packets, as there would be some additional flow cost for this and the\n- value appears limited.\n-
    • \n-\n-
  • \n-

    \n- If inport V is of type virtual adds a\n- priority-100 logical flows for each P configured in the\n- \n- column with the match\n-

    \n- 
    \n-inport == P && && ((arp.op == 1 && arp.spa == VIP && arp.tpa == VIP) || (arp.op == 2 && arp.spa == VIP))\n-inport == P && && ((nd_ns && ip6.dst == {VIP, NS_MULTICAST_ADDR} && nd.target == VIP) || (nd_na && nd.target == VIP))\n-
    \n-\n-

    \n- and applies the action\n-

    \n- 
    \n-bind_vport(V, inport);\n-
    \n-\n-

    \n- and advances the packet to the next table.\n-

    \n-\n-

    \n- Where VIP is the virtual ip configured in the column\n- and\n- NS_MULTICAST_ADDR is solicited-node multicast address corresponding\n- to the VIP.\n-

    \n-
    • \n-\n-
  • \n-

    \n- Priority-50 flows that match only broadcast ARP requests to each\n- known IPv4 address A of every logical switch port, and\n- respond with ARP replies directly with corresponding Ethernet\n- address E:\n-

    \n-\n- 
    \n-eth.dst = eth.src;\n-eth.src = E;\n-arp.op = 2; /* ARP reply. */\n-arp.tha = arp.sha;\n-arp.sha = E;\n-arp.tpa = arp.spa;\n-arp.spa = A;\n-outport = inport;\n-flags.loopback = 1;\n-output;\n-
    \n-\n-

    \n- These flows are omitted for logical ports (other than router ports or\n- localport ports) that are down (unless \n- ignore_lsp_down is configured as true in options\n- column of NB_Global table of the Northbound\n- database), for logical ports of type virtual, for\n- logical ports with 'unknown' address set, for logical ports with\n- the options:disable_arp_nd_rsp=true and for logical\n- ports of a logical switch configured with\n- other_config:vlan-passthru=true.\n-

    \n-\n-

    \n- The above ARP responder flows are added for the list of IPv4 addresses\n- if defined in options:arp_proxy column of\n- Logical_Switch_Port table for logical switch ports of\n- type router.\n-

    \n-
    • \n-\n-
  • \n-

    \n- Priority-50 flows that match IPv6 ND neighbor solicitations to\n- each known IP address A (and A's\n- solicited node address) of every logical switch port except of type\n- router, and respond with neighbor advertisements directly with\n- corresponding Ethernet address E:\n-

    \n-\n- 
    \n-nd_na {\n-    eth.src = E;\n-    ip6.src = A;\n-    nd.target = A;\n-    nd.tll = E;\n-    outport = inport;\n-    flags.loopback = 1;\n-    output;\n-};\n-
    \n-\n-

    \n- Priority-50 flows that match IPv6 ND neighbor solicitations to\n- each known IP address A (and A's\n- solicited node address) of logical switch port of type router, and\n- respond with neighbor advertisements directly with\n- corresponding Ethernet address E:\n-

    \n-\n- 
    \n-nd_na_router {\n-    eth.src = E;\n-    ip6.src = A;\n-    nd.target = A;\n-    nd.tll = E;\n-    outport = inport;\n-    flags.loopback = 1;\n-    output;\n-};\n-
    \n-\n-

    \n- These flows are omitted for logical ports (other than router ports or\n- localport ports) that are down (unless \n- ignore_lsp_down is configured as true in options\n- column of NB_Global table of the Northbound\n- database), for logical ports of type virtual and for\n- logical ports with 'unknown' address set.\n-

    \n-\n-

    \n- The above NDP responder flows are added for the list of\n- IPv6 addresses if defined in options:arp_proxy column of\n- Logical_Switch_Port table for logical switch ports of\n- type router.\n-

    \n-
    • \n-\n-
  • \n-

    \n- Priority-100 flows with match criteria like the ARP and ND flows\n- above, except that they only match packets from the\n- inport that owns the IP addresses in question, with\n- action next;. These flows prevent OVN from replying to,\n- for example, an ARP request emitted by a VM for its own IP address.\n- A VM only makes this kind of request to attempt to detect a duplicate\n- IP address assignment, so sending a reply will prevent the VM from\n- accepting the IP address that it owns.\n-

    \n-\n-

    \n- In place of next;, it would be reasonable to use\n- drop; for the flows' actions. If everything is working\n- as it is configured, then this would produce equivalent results,\n- since no host should reply to the request. But ARPing for one's own\n- IP address is intended to detect situations where the network is not\n- working as configured, so dropping the request would frustrate that\n- intent.\n-

    \n-
    • \n-\n-
  • \n-

    \n- For each SVC_MON_SRC_IP defined in the value of\n- the column of\n- table, priority-110\n- logical flow is added with the match\n- arp.tpa == SVC_MON_SRC_IP\n- && && arp.op == 1 and applies the action\n-

    \n-\n- 
    \n-eth.dst = eth.src;\n-eth.src = E;\n-arp.op = 2; /* ARP reply. */\n-arp.tha = arp.sha;\n-arp.sha = E;\n-arp.tpa = arp.spa;\n-arp.spa = A;\n-outport = inport;\n-flags.loopback = 1;\n-output;\n-
    \n-\n-

    \n- where E is the service monitor source mac defined in\n- the column in the table. This mac is used as the source mac\n- in the service monitor packets for the load balancer endpoint IP\n- health checks.\n-

    \n-\n-

    \n- SVC_MON_SRC_IP is used as the source ip in the\n- service monitor IPv4 packets for the load balancer endpoint IP\n- health checks.\n-

    \n-\n-

    \n- These flows are required if an ARP request is sent for the IP\n- SVC_MON_SRC_IP.\n-

    \n-\n-

    \n- For IPv6 the similar flow is added with the following action\n-

    \n-\n- 
    \n-nd_na {\n-    eth.dst = eth.src;\n-    eth.src = E;\n-    ip6.src = A;\n-    nd.target = A;\n-    nd.tll = E;\n-    outport = inport;\n-    flags.loopback = 1;\n-    output;\n-};\n-
    \n-
    • \n-\n-
  • \n-

    \n- For each VIP configured in the table\n- \n- a priority-50 logical flow is added with the match\n- arp.tpa == vip && && arp.op == 1\n- and applies the action\n-

    \n-\n- 
    \n-eth.dst = eth.src;\n-eth.src = E;\n-arp.op = 2; /* ARP reply. */\n-arp.tha = arp.sha;\n-arp.sha = E;\n-arp.tpa = arp.spa;\n-arp.spa = A;\n-outport = inport;\n-flags.loopback = 1;\n-output;\n-
    \n-\n-

    \n- where E is the forwarding group's mac defined in\n- the .\n-

    \n-\n-

    \n- A is used as either the destination ip for load balancing\n- traffic to child ports or as nexthop to hosts behind the child ports.\n-

    \n-\n-

    \n- These flows are required to respond to an ARP request if an ARP\n- request is sent for the IP vip.\n-

    \n-
    • \n-\n-
  • \n- One priority-0 fallback flow that matches all packets and advances to\n- the next table.\n-
    • \n-
\n-\n-

Ingress Table 27: DHCP option processing

\n-\n-

\n- This table adds the DHCPv4 options to a DHCPv4 packet from the\n- logical ports configured with IPv4 address(es) and DHCPv4 options,\n- and similarly for DHCPv6 options. This table also adds flows for the\n- logical ports of type external.\n-

\n-\n-
    \n-
  • \n-

    \n- A priority-100 logical flow is added for these logical ports\n- which matches the IPv4 packet with udp.src = 68 and\n- udp.dst = 67 and applies the action\n- put_dhcp_opts and advances the packet to the next table.\n-

    \n-\n- 
    \n-reg0[3] = put_dhcp_opts(offer_ip = ip, options...);\n-next;\n-
    \n-\n-

    \n- For DHCPDISCOVER and DHCPREQUEST, this transforms the packet into a\n- DHCP reply, adds the DHCP offer IP ip and options to the\n- packet, and stores 1 into reg0[3]. For other kinds of packets, it\n- just stores 0 into reg0[3]. Either way, it continues to the next\n- table.\n-

    \n-\n-
    • \n-\n-
  • \n-

    \n- A priority-100 logical flow is added for these logical ports\n- which matches the IPv6 packet with udp.src = 546 and\n- udp.dst = 547 and applies the action\n- put_dhcpv6_opts and advances the packet to the next\n- table.\n-

    \n-\n- 
    \n-reg0[3] = put_dhcpv6_opts(ia_addr = ip, options...);\n-next;\n-
    \n-\n-

    \n- For DHCPv6 Solicit/Request/Confirm packets, this transforms the\n- packet into a DHCPv6 Advertise/Reply, adds the DHCPv6 offer IP\n- ip and options to the packet, and stores 1 into reg0[3].\n- For other kinds of packets, it just stores 0 into reg0[3]. Either\n- way, it continues to the next table.\n-

    \n-
    • \n-\n-
  • \n- A priority-0 flow that matches all packets to advances to table 16.\n-
    • \n-
\n-\n-

Ingress Table 28: DHCP responses

\n-\n-

\n- This table implements DHCP responder for the DHCP replies generated by\n- the previous table.\n-

\n-\n-
    \n-
  • \n-

    \n- A priority 100 logical flow is added for the logical ports configured\n- with DHCPv4 options which matches IPv4 packets with udp.src == 68\n- && udp.dst == 67 && reg0[3] == 1 and\n- responds back to the inport after applying these\n- actions. If reg0[3] is set to 1, it means that the\n- action put_dhcp_opts was successful.\n-

    \n-\n- 
    \n-eth.dst = eth.src;\n-eth.src = E;\n-ip4.src = S;\n-udp.src = 67;\n-udp.dst = 68;\n-outport = P;\n-flags.loopback = 1;\n-output;\n-
    \n-\n-

    \n- where E is the server MAC address and S is the\n- server IPv4 address defined in the DHCPv4 options. Note that\n- ip4.dst field is handled by put_dhcp_opts.\n-

    \n-\n-

    \n- (This terminates ingress packet processing; the packet does not go\n- to the next ingress table.)\n-

    \n-
    • \n-\n-
  • \n-

    \n- A priority 100 logical flow is added for the logical ports configured\n- with DHCPv6 options which matches IPv6 packets with udp.src == 546\n- && udp.dst == 547 && reg0[3] == 1 and\n- responds back to the inport after applying these\n- actions. If reg0[3] is set to 1, it means that the\n- action put_dhcpv6_opts was successful.\n-

    \n-\n- 
    \n-eth.dst = eth.src;\n-eth.src = E;\n-ip6.dst = A;\n-ip6.src = S;\n-udp.src = 547;\n-udp.dst = 546;\n-outport = P;\n-flags.loopback = 1;\n-output;\n-
    \n-\n-

    \n- where E is the server MAC address and S is the\n- server IPv6 LLA address generated from the server_id\n- defined in the DHCPv6 options and A is\n- the IPv6 address defined in the logical port's addresses column.\n-

    \n-\n-

    \n- (This terminates packet processing; the packet does not go on the\n- next ingress table.)\n-

    \n-
    • \n-\n-
  • \n- A priority-0 flow that matches all packets to advances to table 17.\n-
    • \n-
\n-\n-

Ingress Table 29 DNS Lookup

\n-\n-

\n- This table looks up and resolves the DNS names to the corresponding\n- configured IP address(es).\n-

\n-\n-
    \n-
  • \n-

    \n- A priority-100 logical flow for each logical switch datapath\n- if it is configured with DNS records, which matches the IPv4 and IPv6\n- packets with udp.dst = 53 and applies the action\n- dns_lookup and advances the packet to the next table.\n-

    \n-\n- 
    \n-reg0[4] = dns_lookup(); next;\n-
    \n-\n-

    \n- For valid DNS packets, this transforms the packet into a DNS\n- reply if the DNS name can be resolved, and stores 1 into reg0[4].\n- For failed DNS resolution or other kinds of packets, it just stores\n- 0 into reg0[4]. Either way, it continues to the next table.\n-

    \n-
    • \n-
\n-\n-

Ingress Table 30 DNS Responses

\n-\n-

\n- This table implements DNS responder for the DNS replies generated by\n- the previous table.\n-

\n-\n-
    \n-
  • \n-

    \n- A priority-100 logical flow for each logical switch datapath\n- if it is configured with DNS records, which matches the IPv4 and IPv6\n- packets with udp.dst = 53 && reg0[4] == 1\n- and responds back to the inport after applying these\n- actions. If reg0[4] is set to 1, it means that the\n- action dns_lookup was successful.\n-

    \n-\n- 
    \n-eth.dst <-> eth.src;\n-ip4.src <-> ip4.dst;\n-udp.dst = udp.src;\n-udp.src = 53;\n-outport = P;\n-flags.loopback = 1;\n-output;\n-
    \n-\n-

    \n- (This terminates ingress packet processing; the packet does not go\n- to the next ingress table.)\n-

    \n-
    • \n-
\n-\n-

Ingress table 31 External ports

\n-\n-

\n- Traffic from the external logical ports enter the ingress\n- datapath pipeline via the localnet port. This table adds the\n- below logical flows to handle the traffic from these ports.\n-

\n-\n-
    \n-
  • \n-

    \n- A priority-100 flow is added for each external logical\n- port which doesn't reside on a chassis to drop the ARP/IPv6 NS\n- request to the router IP(s) (of the logical switch) which matches\n- on the inport of the external logical port\n- and the valid eth.src address(es) of the\n- external logical port.\n-

    \n-\n-

    \n- This flow guarantees that the ARP/NS request to the router IP\n- address from the external ports is responded by only the chassis\n- which has claimed these external ports. All the other chassis,\n- drops these packets.\n-

    \n-\n-

    \n- A priority-100 flow is added for each external logical\n- port which doesn't reside on a chassis to drop any packet destined\n- to the router mac - with the match\n- inport == external &&\n- eth.src == E && eth.dst == R\n- && !is_chassis_resident(\"external\")\n- where E is the external port mac and R is the\n- router port mac.\n-

    \n-
    • \n-\n-
  • \n- A priority-0 flow that matches all packets to advances to table 20.\n-
    • \n-
\n-\n-

Ingress Table 32 Destination Lookup

\n-\n-

\n- This table implements switching behavior. It contains these logical\n- flows:\n-

\n-\n-
    \n-
  • \n- A priority-110 flow with the match\n- eth.src == E for all logical switch\n- datapaths and applies the action handle_svc_check(inport).\n- Where E is the service monitor mac defined in the\n- column of table.\n-
    • \n-\n-
  • \n- A priority-100 flow that punts all IGMP/MLD packets to\n- ovn-controller if multicast snooping is enabled on the\n- logical switch.\n-
    • \n-\n-
  • \n- A priority-100 flow that forwards all DHCP broadcast packets coming\n- from VIFs to the logical router port's MAC when DHCP relay is enabled\n- on the logical switch.\n-
    • \n-\n-
  • \n- A priority-100 flow that matches reg8[23] == 1 and does\n- output action. This ensures that packets that got injected\n- back into this table from egress table Network Function\n- (after it set the outport for packet redirection) get\n- forwarded without any further processing.\n-
    • \n-\n-
  • \n-

    \n- For any logical port that's defined as a target of routing protocol\n- redirecting (via routing-protocol-redirect option set on\n- Logical Router Port), we redirect the traffic related to protocols\n- specified in routing-protocols option. It's acoomplished\n- with following priority-100 flows:\n-

    \n-
      \n-
    • \n- Flows that match Logical Router Port's IPs and destination port of\n- the routing daemon are redirected to this port to allow external\n- peers' connection to the daemon listening on this port.\n-
      • \n-
    • \n- Flows that match Logical Router Port's IPs and source port of\n- the routing daemon are redirected to this port to allow replies\n- from the peers.\n-
      • \n-
    \n-

    \n- In addition to this, we add priority-100 rules that\n- clone ARP replies and IPv6 Neighbor Advertisements to\n- this port as well. These allow to build proper ARP/IPv6 neighbor\n- list on this port.\n-

    \n-
    • \n-\n-
  • \n- Priority-90 flows for transit switches that forward registered\n- IP multicast traffic to their corresponding multicast group , which\n- ovn-northd creates based on learnt\n- entries.\n-
    • \n-\n-
  • \n- Priority-90 flows that forward registered IP multicast traffic to\n- their corresponding multicast group, which ovn-northd\n- creates based on learnt \n- entries. The flows also forward packets to the\n- MC_MROUTER_FLOOD multicast group, which\n- ovn-nortdh populates with all the logical ports that\n- are connected to logical routers with\n- :mcast_relay='true'.\n-
    • \n-\n-
  • \n- A priority-85 flow that forwards all IP multicast traffic destined to\n- 224.0.0.X to the MC_FLOOD_L2 multicast group, which\n- ovn-northd populates with all non-router logical ports.\n-
    • \n-\n-
  • \n- A priority-85 flow that forwards all IP multicast traffic destined to\n- reserved multicast IPv6 addresses (RFC 4291, 2.7.1, e.g.,\n- Solicited-Node multicast) to the MC_FLOOD multicast\n- group, which ovn-northd populates with all enabled\n- logical ports.\n-
    • \n-\n-
  • \n- A priority-80 flow that forwards all unregistered IP multicast traffic\n- to the MC_STATIC multicast group, which\n- ovn-northd populates with all the logical ports that\n- have \n- :mcast_flood='true'. The flow also forwards\n- unregistered IP multicast traffic to the MC_MROUTER_FLOOD\n- multicast group, which ovn-northd populates with all the\n- logical ports connected to logical routers that have\n- \n- :mcast_relay='true'.\n-
    • \n-\n-
  • \n- A priority-80 flow that drops all unregistered IP multicast traffic\n- if \n- :mcast_snoop='true' and\n- \n- :mcast_flood_unregistered='false' and the switch is\n- not connected to a logical router that has\n- \n- :mcast_relay='true' and the switch doesn't have any\n- logical port with \n- :mcast_flood='true'.\n-
    • \n-\n-
  • \n- Priority-80 flows for each IP address/VIP/NAT address owned by a\n- router port connected to the switch. These flows match ARP requests\n- and ND packets for the specific IP addresses. Matched packets are\n- forwarded only to the router that owns the IP address and to the\n- MC_FLOOD_L2 multicast group which contains all non-router\n- logical ports.\n-
    • \n-\n-
  • \n- Priority-75 flows for each port connected to a logical router\n- matching self originated ARP request/RARP request/ND packets. These\n- packets are flooded to the MC_FLOOD_L2 which contains all\n- non-router logical ports.\n-
    • \n-\n-
  • \n- A priority-72 flow that outputs all ND NA (Neighbor Advertisement),\n- ND RS (Router Solicitation) and ND RA (Router Advertisement) packets\n- with an Ethernet broadcast or multicast eth.dst to the\n- MC_FLOOD multicast group, which includes all ports.\n- ND NA must reach routers for neighbor learning; ND RS must reach\n- routers so they can respond with Router Advertisements; ND RA must\n- reach routers for proper IPv6 network operation.\n-
    • \n-\n-
  • \n- A priority-72 flow that outputs all ARP requests and ND NS (Neighbor\n- Solicitation) packets with an Ethernet broadcast or multicast\n- eth.dst to the MC_FLOOD_L2 multicast group\n- if other_config:broadcast-arps-to-all-routers=false.\n-
    • \n-\n-
  • \n- A priority-71 flow that outputs all ARP packets with an Ethernet\n- broadcast or multicast eth.dst to the\n- MC_FLOOD multicast group.\n-
    • \n-\n-
  • \n- A priority-71 flow that outputs all IP packets with an Ethernet\n- broadcast or multicast eth.dst to the\n- MC_FLOOD_L2 multicast group, which contains only\n- non-router logical ports. If any connected router has\n- options:mcast_relay=true, the packet is also cloned to\n- the MC_MROUTER_FLOOD multicast group (which contains\n- only the router ports with relay enabled). If any port has\n- options:mcast_flood=true, it is also cloned to the\n- MC_STATIC multicast group. This prevents IP multicast\n- from being unnecessarily forwarded to routers that would drop it.\n-
    • \n-\n-
  • \n- A priority-70 flow that outputs all packets with an Ethernet broadcast\n- or multicast eth.dst to the MC_FLOOD_L2\n- multicast group.\n-
    • \n-\n-
  • \n-

    \n- One priority-50 flow that matches each known Ethernet address against\n- eth.dst. Action of this flow outputs the packet to the\n- single associated output port if it is enabled. drop;\n- action is applied if LSP is disabled. If the logical switch port\n- of type VIF has the option options:pkt_clone_type\n- is set to the value mc_unknown, then the packet is\n- also forwarded to the MC_UNKNOWN multicast group.\n-

    \n-\n-

    \n- The above flow is not added if the logical switch port is of type\n- VIF, has unknown as one of its address and has the\n- option options:force_fdb_lookup set to true.\n-

    \n-\n-

    \n- For the Ethernet address on a logical switch port of type\n- router, when that logical switch port's\n- column is set to router and\n- the connected logical router port has a gateway chassis:\n-

    \n-\n-
      \n-
    • \n- The flow for the connected logical router port's Ethernet\n- address is only programmed on the gateway chassis.\n-
      • \n-\n-
    • \n- If the logical router has rules specified in\n- with\n- , then\n- those addresses are also used to populate the switch's destination\n- lookup on the chassis where\n- is\n- resident.\n-
      • \n-
    \n-\n-

    \n- For the Ethernet address on a logical switch port of type\n- router, when that logical switch port's\n- column is set to router and\n- the connected logical router port specifies a\n- reside-on-redirect-chassis and the logical router\n- to which the connected logical router port belongs to has a\n- distributed gateway LRP:\n-

    \n-\n-
      \n-
    • \n- The flow for the connected logical router port's Ethernet\n- address is only programmed on the gateway chassis.\n-
      • \n-
    \n-\n-

    \n- For each forwarding group configured on the logical switch datapath,\n- a priority-50 flow that matches on eth.dst == VIP\n- with an action of fwd_group(childports=args\n- ), where args contains comma separated\n- logical switch child ports to load balance to.\n- If liveness is enabled, then action also includes\n- liveness=true.\n-

    \n-
    • \n-\n-
  • \n- One priority-0 fallback flow that matches all packets with the\n- action outport = get_fdb(eth.dst); next;. The action\n- get_fdb gets the port for the eth.dst\n- in the MAC learning table of the logical switch datapath. If there\n- is no entry for eth.dst in the MAC learning table,\n- then it stores none in the outport.\n-
    • \n-
\n-\n-

Ingress Table 33 Destination unknown

\n-\n-

\n- This table handles the packets whose destination was not found or\n- and looked up in the MAC learning table of the logical switch\n- datapath. It contains the following flows.\n-

\n-\n-
    \n-
  • \n-

    \n- Priority 50 flow with the match outport == P\n- is added for each disabled Logical Switch Port P. This\n- flow has action drop;.\n-

    \n-
    • \n-
  • \n-

    \n- If the logical switch has logical ports with 'unknown' addresses set,\n- then the below logical flow is added\n-

    \n-\n-
      \n-
    • \n- Priority 50 flow with the match outport == \"none\" then\n- outputs them to the MC_UNKNOWN multicast group, which\n- ovn-northd populates with all enabled logical ports\n- that accept unknown destination packets. As a small optimization,\n- if no logical ports accept unknown destination packets,\n- ovn-northd omits this multicast group and logical\n- flow.\n-
      • \n-
    \n-\n-

    \n- If the logical switch has no logical ports with 'unknown' address\n- set, then the below logical flow is added\n-

    \n-\n-
      \n-
    • \n- Priority 50 flow with the match outport == none\n- and drops the packets.\n-
      • \n-
    \n-
    • \n-\n-
  • \n- One priority-0 fallback flow that outputs the packet to the egress\n- stage with the outport learnt from get_fdb action.\n-
    • \n-
\n-\n-

Egress Table 0: Lookup MAC address learning table

\n-

\n- This is similar to ingress table Lookup MAC address learning table\n- with the difference that MAC address learning lookup is only\n- happening for ports with type remote whose port security is\n- disabled and 'unknown' address set. This stage facilitates MAC learning\n- on a transit switch connecting multiple availability zones.\n-

\n-\n-

Egress Table 1: Learn MAC of 'unknown' ports.

\n-

\n- This is similar to ingress table Learn MAC of 'unknown' ports\n- with the difference that MAC address learning is only happening\n- for ports with type remote whose port security is disabled\n- and 'unknown' address set. This stage facilitates MAC learning on a\n- transit switch connecting multiple availability zones.\n-

\n-\n-

Egress Table 2: to-lport Pre-ACLs

\n-\n-

\n- This is similar to ingress table Pre-ACLs except for\n- to-lport traffic.\n-

\n-\n-

\n- This table also has a priority-110 flow with the match\n- eth.src == E for all logical switch\n- datapaths to move traffic to the next table. Where E\n- is the service monitor mac defined in the\n- column of table.\n-

\n-\n-

\n- This table also has a priority-110 flow with the match\n- outport == I for all logical switch\n- datapaths to move traffic to the next table. Where I\n- is the peer of a logical router port. This flow is added to\n- skip the connection tracking of packets which will be entering\n- logical router datapath from logical switch datapath for routing.\n-

\n-\n-

\n- This table also has a priority-110 flow for each network_function\n- inport P that matches inport ==\n- P. The action is to skip all the egress tables up to\n- the Network Function table and advance the packet directly\n- to the table after that. This is for the case where packet redirection\n- happens in egress Network Function table. The same packet\n- when it comes out of the other port of network function, they should not\n- be processed again by the same egress stages, specially they should\n- skip the conntrack processing.\n-

\n-\n-

Egress Table 3: Pre-LB

\n-\n-

\n- This table is similar to ingress table Pre-LB. It\n- contains a priority-0 flow that simply moves traffic to the next table.\n- Moreover it contains two priority-110 flows to move multicast, IPv6\n- Neighbor Discovery and MLD traffic to the next table. If any load\n- balancing rules exist for the datapath, a priority-100 flow is added with\n- a match of ip and action of reg0[2] = 1; next;\n- to act as a hint for table Pre-stateful to send IP packets\n- to the connection tracker for packet de-fragmentation and possibly DNAT\n- the destination VIP to one of the selected backend for already committed\n- load balanced traffic.\n-

\n-\n-

\n- This table also has a priority-110 flow with the match\n- eth.src == E for all logical switch\n- datapaths to move traffic to the next table. Where E\n- is the service monitor mac defined in the\n- column of table.\n-

\n-\n-

\n- This table also has a priority-110 flow with the match\n- outport == I for all logical switch\n- datapaths to move traffic to the next table, and, if there are no\n- stateful_acl, clear the ct_state. Where I\n- is the peer of a logical router port. This flow is added to\n- skip the connection tracking of packets which will be entering\n- logical router datapath from logical switch datapath for routing.\n-

\n-\n-

\n- When enable-stateless-acl-with-lb is enabled,\n- additional priority-115 flow is added to match traffic with\n- REGBIT_ACL_STATELESS set and pass connection tracking.\n-

\n-\n-

Egress Table 4: Pre-stateful

\n-\n-

\n- This is similar to ingress table Pre-stateful. This table\n- adds the below 3 logical flows.\n-

\n-\n-
    \n-
  • \n- A Priority-120 flow that send the packets to connection tracker using\n- ct_lb_mark; as the action so that the already established\n- traffic gets unDNATted from the backend IP to the load balancer VIP\n- based on a hint provided by the previous tables with a match\n- for reg0[2] == 1. If the packet was not DNATted earlier,\n- then ct_lb_mark functions like ct_next.\n-
    • \n-\n-
  • \n- A priority-100 flow sends the packets to connection tracker based\n- on a hint provided by the previous tables\n- (with a match for reg0[0] == 1) by using the\n- ct_next; action.\n-
    • \n-\n-
  • \n- A priority-0 flow that matches all packets to advance to the next\n- table.\n-
    • \n-
\n-\n-

Egress Table 5: from-lport ACL hints

\n-

\n- This is similar to ingress table ACL hints.\n-

\n-\n-

Egress Table 6: to-lport ACL evaluation

\n-\n-

\n- This is similar to ingress table ACL eval except for\n- to-lport ACLs. As a reminder, these flows use the\n- following register bits to indicate their verdicts.\n- Allow-type ACLs set reg8[16], drop\n- ACLs set reg8[17], and reject ACLs set\n- reg8[18].\n-

\n-\n-

\n- Also like with ingress ACLs, egress ACLs can have network_function_group\n- id and in that case the flow will set reg8[21] = 1;\n- reg8[22] = 1; reg0[22..29] = id. These registers are used\n- in the Network Function table.\n-

\n-\n-

\n- Also like with ingress ACLs, egress ACLs can have a configured\n- tier. If a tier is configured, then the current tier\n- counter is evaluated against the ACL's configured tier in addition\n- to the ACL's match. The current tier counter is stored in\n- reg8[30..31].\n-

\n-\n-

\n- Similar to ingress table, a priority-65532 flow is added to allow IPv6\n- Neighbor solicitation, Neighbor discover, Router solicitation, Router\n- advertisement and MLD packets regardless of other ACLs defined.\n-

\n-\n-

\n- In addition, the following flows are added.\n-

\n-
    \n-
  • \n- A priority 34000 logical flow is added for each logical port which\n- has DHCPv4 options defined to allow the DHCPv4 reply packet and which has\n- DHCPv6 options defined to allow the DHCPv6 reply packet from the\n- Ingress Table 26: DHCP responses. This is indicated by\n- setting the allow bit.\n-
    • \n-\n-
  • \n- A priority 34000 logical flow is added for each logical switch datapath\n- configured with DNS records with the match udp.dst = 53\n- to allow the DNS reply packet from the\n- Ingress Table 28: DNS responses. This is indicated by\n- setting the allow bit.\n-
    • \n-\n-
  • \n- A priority 34000 logical flow is added for each logical switch datapath\n- with the match eth.src = E to allow the service\n- monitor request packet generated by ovn-controller\n- with the action next, where E is the\n- service monitor mac defined in the\n- column of table. This is indicated by setting the allow\n- bit.\n-
    • \n-
\n-\n-

Egress Table 7: to-lport ACL sampling

\n-

\n- This is similar to ingress table ACL sampling.\n-

\n-\n-

Egress Table 8: to-lport ACL action

\n-

\n- This is similar to ingress table ACL action.\n-

\n-\n-

Egress Table 9: Mirror

\n-\n-

\n- Overlay remote mirror table contains the following\n- logical flows:\n-

\n-\n-
    \n-
  • \n- For each logical switch port with an attached mirror, a logical flow\n- with a priority of 100 is added. This flow matches all outcoming\n- packets to the attached port, clones them, and forwards the cloned\n- packets to the mirror target port.\n-
    • \n-\n-
  • \n- A priority 0 flow is added which matches on all packets and applies\n- the action next;.\n-
    • \n-\n-
  • \n- A logical flow added for each Mirror Rule in Mirror table attached\n- to logical switch ports, matches all outcoming packets that match\n- rules and clones the packet and sends cloned packet to mirror\n- target port.\n-
    • \n-
\n-\n-

Egress Table 10: to-lport QoS

\n-\n-

\n- This is similar to ingress table QoS except\n- they apply to to-lport QoS rules.\n-

\n-\n-

Egress Table 11: Pre Network Function

\n-\n-

\n- This stage selects the active network function from a\n- Network_Function_Group based on the network function group\n- ID set by the ACL eval stage earlier. This stage is applicable for\n- request packets of to-lport ACLs\n- (reg8[22] == 1). Response packets for\n- from-lport ACLs bypass this stage and use\n- ct_label.nf_id directly in the Network Function table.\n-

\n-\n-

\n- A network function group can contain one or more network functions.\n- Health monitoring is performed by sending datapath probes as per\n- parameters defined in Network_Function_Health_Check. This\n- stage selects one of the healthy network functions. If none are healthy,\n- the behavior follows the fallback column configured in the\n- Network_Function_Group table. If health monitoring is not\n- configured, any one from the group is selected.\n-

\n-\n-

\n- When a request packet matches a to-lport ACL with\n- network_function_group set, the ACL eval stage sets\n- reg8[21] = 1 (NF enabled), reg8[22] = 1\n- (request direction), and reg0[22..29] to the network\n- function group ID. This table then selects the active network function\n- from the group and overwrites reg0[22..29] with the\n- specific id of a Network_Function table entry.\n- The subsequent Network Function table uses this NF ID to redirect packets\n- to the appropriate network function port. In the future, this stage will\n- be extended to support network function load balancing.\n-

\n-\n-
    \n-
  • \n- For each network function group with id that has an active\n- network function, a priority-99 flow matches reg8[21] == 1\n- && reg8[22] == 1 && reg0[22..29] == id\n- and sets reg0[22..29] = nf_id; next; where\n- nf_id is the id of the active\n- Network_Function selected from the group. This prepares\n- request packets that matched a to-lport ACL with\n- network_function_group for redirection in the subsequent Network\n- Function table.\n-
    • \n-\n-
  • \n- For each network function group with id that has\n- fallback set to fail-open, a priority-10 flow\n- matches reg8[21] == 1 && reg8[22] == 1 &&\n- reg0[22..29] == id and sets reg8[21] = 0;\n- reg0[22..29] = 0; next;. This clears both the NF enabled bit and\n- the NF group ID, allowing packets to continue processing through the\n- pipeline without network function redirection when no active network\n- function is available (fail-open behavior).\n-
    • \n-\n-
  • \n- A priority-1 flow matches reg8[21] == 1 && reg8[22] == 1\n- and sets reg0[22..29] = 0; next;. This is a\n- catch-all flow for network function groups with fallback\n- set to fail-close (or default) when no active network\n- function is available. It clears only the NF group ID, leaving the NF\n- enabled bit set. These packets will be dropped by the priority-1 drop\n- rule in the subsequent Network Function table (fail-close behavior).\n-
    • \n-\n-
  • \n- A priority-0 flow that simply moves traffic to the next table.\n-
    • \n-
\n-\n-

Egress Table 12: Stateful

\n-\n-

\n- This is similar to ingress table Stateful except that\n- there are no rules added for load balancing new connections.\n- When enable-stateless-acl-with-lb is enabled, new\n- stateless connections bypass connection tracking.\n-

\n-\n-
    \n-
  • \n- A priority 120 flow is added for each network function port\n- P that is identical to the priority 100 flow except for\n- additional match outport == P and additional\n- action ct_label.tun_if_id = reg5[16..31]. In case packets\n- redirected by network function logic gets tunneled from host1 to host2\n- where the network function port resides, host2's physical table 0\n- populates reg5[16..31] with the openflow tunnel interface id on which\n- the packet was received. This priority 120 flow commits the tunnel id\n- to the ct_label. That way, when the same packet comes out of the other\n- port of the network function it can retrieve this information from the\n- peer port's CT entry and tunnel the packet back to host1. This is\n- required to make cross host traffic redirection work for VLAN subnet.\n-
    • \n-
\n-\n-

Egress Table 13: Network Function

\n-\n-

\n- This table handles request packets for to-lport ACLs\n- and response packets for from-lport ACLs. For\n- to-lport ACLs, request packets are redirected to the\n- network function's outport, and corresponding\n- response/related packets are handled in the ingress pipeline. For\n- from-lport ACLs, request packets are handled in the\n- ingress pipeline, but corresponding response/related packets for those\n- flows are redirected here using the network function ID stored in\n- ct_label.nf_id during request processing.\n-

\n-\n-
    \n-
  • \n- Similar to ingress Network Function a priority-100 flow is\n- added for each network_function port, that matches the inport with the\n- network function port and advances the packet to the next table.\n-
    • \n-\n-
  • \n- For each active network function with id that is\n- referenced in a network function group, a priority-99 flow matches\n- reg8[21] == 1 && reg8[22] == 1 &&\n- reg0[22..29] == id and sets\n- outport=P; reg8[23] = 1; next(pipeline=ingress,\n- table=T) where P is the\n- outport of that network function and T is\n- the ingress table Destination Lookup. This redirects\n- request packets matching to-lport ACLs with\n- network_function_group to the specific network function selected by\n- the Pre Network Function stage. The packets are injected back to the\n- ingress pipeline from where they get sent out, skipping any further\n- lookup because of reg8[23].\n-
    • \n-\n-
  • \n- For each active network function with id that is referenced\n- in a network function group, a priority-99 rule matches\n- reg8[21] == 1 && reg8[22] == 0 &&\n- ct_label.nf_id == id and takes identical action as\n- above. This redirects response and related packets for\n- from-lport ACLs to the same network function that handled\n- the request, using the NF ID stored in the connection tracking label.\n-
    • \n-\n-
  • \n- In each of the above cases, when the same packet comes out unchanged\n- through the other port of the network_function, it would match the\n- priority 100 flow and be forwarded to the next table.\n-
    • \n-\n-
  • \n- One priority-100 multicast match flow same as\n- ingress Network Function.\n-
    • \n-\n-
  • \n- One priority-1 flow same as ingress Network Function.\n-
    • \n-\n-
  • \n- One priority-0 flow same as ingress Network Function.\n-
    • \n-
\n-\n-

Egress Table 14: Egress Port Security - check

\n-\n-

\n- This is similar to the port security logic in table\n- Ingress Port Security check except that action\n- check_out_port_sec is used to check the port security\n- rules. This table adds the below logical flows.\n-

\n-\n-
    \n-
  • \n- A priority 100 flow which matches on the multicast traffic and applies\n- the action REGBIT_PORT_SEC_DROP\" = 0; next;\" to skip\n- the out port security checks.\n-
    • \n-\n-
  • \n- A priority 0 logical flow is added which matches on all the packets\n- and applies the action\n- REGBIT_PORT_SEC_DROP\" = check_out_port_sec(); next;\".\n- The action check_out_port_sec applies the port security\n- rules based on the addresses defined in the\n- column of table before delivering the packet to the\n- outport.\n-
    • \n-
\n-\n-

Egress Table 15: Egress Port Security - Apply

\n-\n-

\n- This is similar to the ingress port security logic in ingress table\n- A Ingress Port Security - Apply. This table drops the\n- packets if the port security check failed in the previous stage i.e\n- the register bit REGBIT_PORT_SEC_DROP is set to 1.\n-

\n-\n-

\n- The following flows are added.\n-

\n-\n-
    \n-
  • \n-

    \n- For each port configured with egress qos in the\n- column of , running a localnet port on the same logical\n- switch, a priority 110 flow is added which matches on the localnet\n- outport and on the port inport and\n- applies the action set_queue(id); output;\".\n-

    \n-
    • \n-\n-
  • \n-

    \n- For each localnet port configured with egress qos in the\n- column of , a priority 100 flow is added which\n- matches on the localnet outport and applies the action\n- set_queue(id); output;\".\n-

    \n-\n-

    \n- Please remember to mark the corresponding physical interface with\n- ovn-egress-iface set to true in\n- .\n-

    \n-
    • \n-\n-
  • \n- A priority-50 flow that drops the packet if the register\n- bit REGBIT_PORT_SEC_DROP is set to 1.\n-
    • \n-\n-
  • \n- A priority-0 flow that outputs the packet to the outport.\n-
    • \n-
\n-\n-

Logical Router Datapaths

\n-\n-

\n- Logical router datapaths will only exist for rows in the database\n- that do not have set to false\n-

\n-\n-

Ingress Table 0: L2 Admission Control

\n-\n-

\n- This table drops packets that the router shouldn't see at all based on\n- their Ethernet headers. It contains the following flows:\n-

\n-\n-
    \n-
  • \n- Priority-100 flows to drop packets with VLAN tags or multicast Ethernet\n- source addresses.\n-
    • \n-\n-
  • \n-

    \n- For each enabled router port P with Ethernet address\n- E, a priority-50 flow that matches inport ==\n- P && (eth.mcast || eth.dst ==\n- E), stores the router port ethernet address\n- and advances to next table, with action\n- xreg0[0..47]=E; next;.\n-

    \n-\n-

    \n- For the gateway port on a distributed logical router (where\n- one of the logical router ports specifies a\n- gateway chassis), the above flow matching\n- eth.dst == E is only programmed on\n- the gateway port instance on the gateway chassis.\n- If LRP's logical switch has attached LSP of vtep type,\n- the is_chassis_resident() part is not added to lflow to\n- allow traffic originated from logical switch to reach LR services\n- (LBs, NAT).\n-

    \n-\n-

    \n- For each gateway port GW on a distributed logical router\n- a priority-120 flow that matches 'recirculated' icmp{4,6} error\n- 'packet too big' and eth.dst == D &&\n- !is_chassis_resident( cr-GW) where D\n- is the gateway port mac address and cr-GW is the chassis\n- resident port of GW, swap inport and outport and stores\n- GW as inport.\n-

    \n-\n-

    \n- This table adds a priority-105 flow that matches 'recirculated'\n- icmp{4,6} error 'packet too big' to drop the packet.\n-

    \n-\n-

    \n- For unicast L2 traffic on a distributed logical router or for\n- gateway router where the port is configured with\n- options:gateway_mtu the action of the above flow\n- is modified adding check_pkt_larger in order to mark\n- the packet setting REGBIT_PKT_LARGER if the size is\n- greater than the MTU.\n-\n- If the port is also configured with\n- options:gateway_mtu_bypass then another flow is\n- added, with priority-55, to bypass the check_pkt_larger\n- flow. This is useful for traffic that normally doesn't need to be\n- fragmented and for which check_pkt_larger, which might not be\n- offloadable, is not really needed. One such example is TCP traffic.\n-

    \n-
    • \n-\n-
  • \n-

    \n- For each dnat_and_snat NAT rule on a distributed\n- router that specifies an external Ethernet address E,\n- a priority-50 flow that matches inport == GW\n- && eth.dst == E, where GW\n- is the logical router distributed gateway port corresponding to the\n- NAT rule (specified or inferred), with action\n- xreg0[0..47]=E; next;.\n-

    \n-\n-

    \n- This flow is only programmed on the gateway port instance on\n- the chassis where the logical_port specified in\n- the NAT rule resides.\n-

    \n-
    • \n-\n-
  • \n- A priority-0 logical flow that matches all packets not already handled\n- (match 1) and drops them (action drop;).\n-
    • \n-
\n-\n-

\n- Other packets are implicitly dropped.\n-

\n-\n-

Ingress Table 1: Neighbor lookup

\n-\n-

\n- For ARP and IPv6 Neighbor Discovery packets, this table looks into the\n- records to determine\n- if OVN needs to learn the mac bindings. Following flows are added:\n-

\n-\n-
    \n-
  • \n-

    \n- For each router port P that owns IP address A,\n- which belongs to subnet S with prefix length L,\n- if the option always_learn_from_arp_request is\n- true for this router, a priority-100 flow is added which\n- matches inport == P && arp.spa ==\n- S/L && arp.op == 1 (ARP request)\n- with the following actions:\n-

    \n-\n- 
    \n-reg9[2] = lookup_arp(inport, arp.spa, arp.sha);\n-next;\n-
    \n-\n-

    \n- If the option always_learn_from_arp_request is\n- false, the following two flows are added.\n-

    \n-\n-

    \n- A priority-110 flow is added which matches inport ==\n- P && arp.spa == S/L\n- && arp.tpa == A && arp.op == 1\n- (ARP request) with the following actions:\n-

    \n-\n- 
    \n-reg9[2] = lookup_arp(inport, arp.spa, arp.sha);\n-reg9[3] = 1;\n-next;\n-
    \n-\n-

    \n- A priority-100 flow is added which matches inport ==\n- P && arp.spa == S/L\n- && arp.op == 1 (ARP request) with the following\n- actions:\n-

    \n-\n- 
    \n-reg9[2] = lookup_arp(inport, arp.spa, arp.sha);\n-reg9[3] = lookup_arp_ip(inport, arp.spa);\n-next;\n-
    \n-\n-

    \n- If the logical router port P is a distributed gateway\n- router port, additional match\n- is_chassis_resident(cr-P) is added for all\n- these flows.\n-

    \n-
    • \n-\n-
  • \n-

    \n- A priority-100 flow which matches on ARP reply packets and applies\n- the actions if the option always_learn_from_arp_request\n- is true:\n-

    \n-\n- 
    \n-reg9[2] = lookup_arp(inport, arp.spa, arp.sha);\n-next;\n-
    \n-\n-

    \n- If the option always_learn_from_arp_request\n- is false, the above actions will be:\n-

    \n-\n- 
    \n-reg9[2] = lookup_arp(inport, arp.spa, arp.sha);\n-reg9[3] = 1;\n-next;\n-
    \n-\n-
    • \n-\n-
  • \n-

    \n- A priority-100 flow which matches on IPv6 Neighbor Discovery\n- advertisement packet and applies the actions if the option\n- always_learn_from_arp_request is true:\n-

    \n-\n- 
    \n-reg9[2] = lookup_nd(inport, nd.target, nd.tll);\n-next;\n-
    \n-\n-

    \n- If the option always_learn_from_arp_request\n- is false, the above actions will be:\n-

    \n-\n- 
    \n-reg9[2] = lookup_nd(inport, nd.target, nd.tll);\n-reg9[3] = 1;\n-next;\n-
    \n-
    • \n-\n-
  • \n-

    \n- A priority-100 flow which matches on IPv6 Neighbor Discovery\n- solicitation packet and applies the actions if the option\n- always_learn_from_arp_request is true:\n-

    \n-\n- 
    \n-reg9[2] = lookup_nd(inport, ip6.src, nd.sll);\n-next;\n-
    \n-\n-

    \n- If the option always_learn_from_arp_request\n- is false, the above actions will be:\n-

    \n-\n- 
    \n-reg9[2] = lookup_nd(inport, ip6.src, nd.sll);\n-reg9[3] = lookup_nd_ip(inport, ip6.src);\n-next;\n-
    \n-
    • \n-\n-
  • \n- A priority-0 fallback flow that matches all packets and applies\n- the action reg9[2] = 1; next;\n- advancing the packet to the next table.\n-
    • \n-
\n-\n-

Ingress Table 2: Neighbor learning

\n-\n-

\n- This table adds flows to learn the mac bindings from the ARP and\n- IPv6 Neighbor Solicitation/Advertisement packets if it is needed\n- according to the lookup results from the previous stage.\n-

\n-\n-

\n- reg9[2] will be 1 if the lookup_arp/lookup_nd\n- in the previous table was successful or skipped, meaning no need\n- to learn mac binding from the packet.\n-

\n-\n-

\n- reg9[3] will be 1 if the\n- lookup_arp_ip/lookup_nd_ip in the previous table was\n- successful or skipped, meaning it is ok to learn mac binding from\n- the packet (if reg9[2] is 0).\n-

\n-\n-
    \n-
  • \n- A priority-100 flow with the match reg9[2] == 1 || reg9[3] ==\n- 0 and advances the packet to the next table as there is no need\n- to learn the neighbor.\n-
    • \n-\n-
  • \n- A priority-95 flow with the match nd_ns &&\n- (ip6.src == 0 || nd.sll == 0) and applies the action\n- next;\n-
    • \n-\n-
  • \n- A priority-90 flow with the match arp and\n- applies the action\n- put_arp(inport, arp.spa, arp.sha); next;\n-
    • \n-\n-
  • \n- A priority-95 flow with the match nd_na &&\n- nd.tll == 0 and applies the action\n- put_nd(inport, nd.target, eth.src); next;\n-
    • \n-\n-
  • \n- A priority-90 flow with the match nd_na and\n- applies the action\n- put_nd(inport, nd.target, nd.tll); next;\n-
    • \n-\n-
  • \n- A priority-90 flow with the match nd_ns and\n- applies the action\n- put_nd(inport, ip6.src, nd.sll); next;\n-
    • \n-\n-
  • \n- A priority-0 logical flow that matches all packets not already handled\n- (match 1) and drops them (action drop;).\n-
    • \n-
\n-\n-

Ingress Table 3: IP Input

\n-\n-

\n- This table is the core of the logical router datapath functionality. It\n- contains the following flows to implement very basic IP host\n- functionality.\n-

\n-\n-
    \n-
  • \n-

    \n- For each dnat_and_snat NAT rule on a distributed\n- logical routers or gateway routers with gateway port\n- configured with options:gateway_mtu to a valid integer\n- value M, a priority-160 flow with the match\n- inport == LRP && REGBIT_PKT_LARGER\n- && REGBIT_EGRESS_LOOPBACK == 0, where LRP\n- is the logical router port and applies the following action for ipv4\n- and ipv6 respectively:\n-

    \n-\n- 
    \n-icmp4_error {\n-    icmp4.type = 3; /* Destination Unreachable. */\n-    icmp4.code = 4;  /* Frag Needed and DF was Set. */\n-    icmp4.frag_mtu = M;\n-    eth.dst = eth.src;\n-    eth.src = E;\n-    ip4.dst = ip4.src;\n-    ip4.src = I;\n-    ip.ttl = 255;\n-    REGBIT_EGRESS_LOOPBACK = 1;\n-    REGBIT_PKT_LARGER 0;\n-    outport = LRP;\n-    flags.loopback = 1;\n-    output;\n-};\n-\n-icmp6_error {\n-    icmp6.type = 2;\n-    icmp6.code = 0;\n-    icmp6.frag_mtu = M;\n-    eth.dst = eth.src;\n-    eth.src = E;\n-    ip6.dst = ip6.src;\n-    ip6.src = I;\n-    ip.ttl = 255;\n-    REGBIT_EGRESS_LOOPBACK = 1;\n-    REGBIT_PKT_LARGER 0;\n-    outport = LRP;\n-    flags.loopback = 1;\n-    output;\n-};\n-
    \n-

    \n- where E and I are the NAT rule external mac\n- and IP respectively.\n-

    \n-
    • \n-\n-
  • \n-

    \n- For distributed logical routers or gateway routers with gateway port\n- configured with options:gateway_mtu to a valid integer\n- value, a priority-150 flow with the match inport ==\n- LRP && REGBIT_PKT_LARGER &&\n- REGBIT_EGRESS_LOOPBACK == 0, where LRP is the\n- logical router port and applies the following action for ipv4\n- and ipv6 respectively:\n-

    \n-\n- 
    \n-icmp4_error {\n-    icmp4.type = 3; /* Destination Unreachable. */\n-    icmp4.code = 4;  /* Frag Needed and DF was Set. */\n-    icmp4.frag_mtu = M;\n-    eth.dst = E;\n-    ip4.dst = ip4.src;\n-    ip4.src = I;\n-    ip.ttl = 255;\n-    REGBIT_EGRESS_LOOPBACK = 1;\n-    REGBIT_PKT_LARGER 0;\n-    next(pipeline=ingress, table=0);\n-};\n-\n-icmp6_error {\n-    icmp6.type = 2;\n-    icmp6.code = 0;\n-    icmp6.frag_mtu = M;\n-    eth.dst = E;\n-    ip6.dst = ip6.src;\n-    ip6.src = I;\n-    ip.ttl = 255;\n-    REGBIT_EGRESS_LOOPBACK = 1;\n-    REGBIT_PKT_LARGER 0;\n-    next(pipeline=ingress, table=0);\n-};\n-
    \n-
    • \n-\n-
  • \n-

    \n- For each NAT entry of a distributed logical router (with\n- distributed gateway router port(s)) of type snat,\n- a priority-120 flow with the match inport == P\n- && ip4.src == A advances the packet to\n- the next pipeline, where P is the distributed logical\n- router port corresponding to the NAT entry (specified or inferred)\n- and A is the external_ip set\n- in the NAT entry. If A is an IPv6 address, then\n- ip6.src is used for the match.\n-

    \n-\n-

    \n- The above flow is required to handle the routing of the East/west NAT\n- traffic.\n-

    \n-
    • \n-\n-
  • \n-

    \n- For each BFD port the two following priority-110 flows are added\n- to manage BFD traffic:\n-\n-

      \n-
    • \n- if ip4.src or ip6.src is any IP\n- address owned by the router port and udp.dst == 3784\n- , the packet is advanced to the next pipeline stage.\n-
      • \n-\n-
    • \n- if ip4.dst or ip6.dst is any IP\n- address owned by the router port and udp.dst == 3784\n- , the handle_bfd_msg action is executed.\n-
      • \n-
    \n-

    \n-
    • \n-\n-
  • \n-

    \n- For each logical router port configured with DHCP relay the\n- following priority-110 flows are added to manage the DHCP relay\n- traffic:\n-\n-

      \n-
    • \n-

      \n- if inport is lrp and ip4.src == 0.0.0.0\n- and ip4.dst == 255.255.255.255 and\n- ip4.frag == 0 and udp.src == 68\n- and udp.dst == 67, the dhcp_relay_req_chk\n- action is executed.\n-

      \n-\n- 
      \n-                reg9[7] = dhcp_relay_req_chk(lrp_ip,\n-                                            dhcp_server_ip);next\n-
      \n-\n-

      \n- if action is successful then, GIADDR in the dhcp header is\n- updated with lrp ip and stores 1 into reg9[7] else stores 0\n- into reg9[7].\n-

      \n-
      • \n-\n-
    • \n- if ip4.src is DHCP server ip and ip4.dst\n- is lrp IP and udp.src == 67 and\n- udp.dst == 67, the packet is advanced to the next\n- pipeline stage.\n-
      • \n-
    \n-

    \n-
    • \n-\n-
  • \n-

    \n- L3 admission control: Priority-120 flows allows IGMP and MLD packets\n- if the router has logical ports that have\n- \n- :mcast_flood='true'.\n-

    \n-
    • \n-\n-
  • \n-

    \n- L3 admission control: A priority-100 flow drops packets that match\n- any of the following:\n-

    \n-\n-
      \n-
    • \n- ip4.src[28..31] == 0xe (multicast source)\n-
      • \n-
    • \n- ip4.src == 255.255.255.255 (broadcast source)\n-
      • \n-
    • \n- ip4.src == 127.0.0.0/8 || ip4.dst == 127.0.0.0/8\n- (localhost source or destination)\n-
      • \n-
    • \n- ip4.src == 0.0.0.0/8 || ip4.dst == 0.0.0.0/8 (zero\n- network source or destination)\n-
      • \n-
    • \n- ip4.src or ip6.src is any IP\n- address owned by the router, unless the packet was recirculated\n- due to egress loopback as indicated by\n- REGBIT_EGRESS_LOOPBACK.\n-
      • \n-
    • \n- ip4.src is the broadcast address of any IP network\n- known to the router.\n-
      • \n-
    \n-
    • \n-\n-
  • \n- A priority-100 flow parses DHCPv6 replies from IPv6 prefix\n- delegation routers (udp.src == 547 &&\n- udp.dst == 546). The handle_dhcpv6_reply\n- is used to send IPv6 prefix delegation messages to the delegation\n- router.\n-
    • \n-\n-
  • \n- For each load balancer applied to this logical router configured\n- with VIP template, a priority-100 flow matching\n- ip4.dst or ip6.dst with the configured\n- load balancer VIP and action next;.\n- These flows avoid dropping the packet if the VIP is\n- set to one of the router IPs.\n-
    • \n-\n-
  • \n-

    \n- ICMP echo reply. These flows reply to ICMP echo requests received\n- for the router's IP address. Let A be an IP address\n- owned by a router port. Then, for each A that is\n- an IPv4 address, a priority-90 flow matches on\n- ip4.dst == A and\n- icmp4.type == 8 && icmp4.code == 0\n- (ICMP echo request). For each A that is an IPv6\n- address, a priority-90 flow matches on\n- ip6.dst == A and\n- icmp6.type == 128 && icmp6.code == 0\n- (ICMPv6 echo request). The port of the router that receives the\n- echo request does not matter. Also, the ip.ttl of\n- the echo request packet is not checked, so it complies with\n- RFC 1812, section 4.2.2.9. Flows for ICMPv4 echo requests use the\n- following actions:\n-

    \n-\n- 
    \n-ip4.dst <-> ip4.src;\n-ip.ttl = 255;\n-icmp4.type = 0;\n-flags.loopback = 1;\n-next;\n-
    \n-\n-

    \n- Flows for ICMPv6 echo requests use the following actions:\n-

    \n-\n- 
    \n-ip6.dst <-> ip6.src;\n-ip.ttl = 255;\n-icmp6.type = 129;\n-flags.loopback = 1;\n-next;\n-
    \n-
    • \n-\n-
  • \n-

    \n- Reply to ARP requests.\n-

    \n-\n-

    \n- These flows reply to ARP requests for the router's own IP address.\n- The ARP requests are handled only if the requestor's IP belongs\n- to the same subnets of the logical router port.\n- For each router port P that owns IP address A,\n- which belongs to subnet S with prefix length L,\n- and Ethernet address E, a priority-90 flow matches\n- inport == P &&\n- arp.spa == S/L && arp.op == 1\n- && arp.tpa == A (ARP request) with the\n- following actions:\n-

    \n-\n- 
    \n-eth.dst = eth.src;\n-eth.src = xreg0[0..47];\n-arp.op = 2; /* ARP reply. */\n-arp.tha = arp.sha;\n-arp.sha = xreg0[0..47];\n-arp.tpa = arp.spa;\n-arp.spa = A;\n-outport = inport;\n-flags.loopback = 1;\n-output;\n-
    \n-\n-

    \n- For the gateway port on a distributed logical router (where\n- one of the logical router ports specifies a\n- gateway chassis), the above flows are only\n- programmed on the gateway port instance on the\n- gateway chassis. This behavior avoids generation\n- of multiple ARP responses from different chassis, and allows\n- upstream MAC learning to point to the gateway chassis.\n-

    \n-\n-

    \n- For the logical router port with the option\n- reside-on-redirect-chassis set (which is centralized),\n- the above flows are only programmed on the gateway port instance on\n- the gateway chassis (if the logical router has a\n- distributed gateway port). This behavior avoids generation\n- of multiple ARP responses from different chassis, and allows\n- upstream MAC learning to point to the gateway chassis.\n-

    \n-
    • \n-\n-
  • \n-

    \n- Reply to IPv6 Neighbor Solicitations. These flows reply to\n- Neighbor Solicitation requests for the router's own IPv6\n- address and populate the logical router's mac binding table.\n-

    \n-\n-

    \n- For each router port P that\n- owns IPv6 address A, solicited node address S,\n- and Ethernet address E, a priority-90 flow matches\n- inport == P &&\n- nd_ns && ip6.dst == {A, E} &&\n- nd.target == A with the following actions:\n-

    \n-\n- 
    \n-nd_na_router {\n-    eth.src = xreg0[0..47];\n-    ip6.src = A;\n-    nd.target = A;\n-    nd.tll = xreg0[0..47];\n-    outport = inport;\n-    flags.loopback = 1;\n-    output;\n-};\n-
    \n-\n-

    \n- For the gateway port on a distributed logical router (where\n- one of the logical router ports specifies a\n- gateway chassis), the above flows replying to\n- IPv6 Neighbor Solicitations are only programmed on the\n- gateway port instance on the gateway chassis.\n- This behavior avoids generation of multiple replies from\n- different chassis, and allows upstream MAC learning to point\n- to the gateway chassis.\n-

    \n-
    • \n-\n-
  • \n-

    \n- These flows reply to ARP requests or IPv6 neighbor solicitation\n- for the virtual IP addresses configured in the router for NAT\n- (both DNAT and SNAT) or load balancing.\n-

    \n-\n-

    \n- IPv4: For a configured NAT (both DNAT and SNAT) IP address or a\n- load balancer IPv4 VIP A, for each router port\n- P with Ethernet address E, a priority-90 flow\n- matches arp.op == 1 && arp.tpa == A\n- (ARP request) with the following actions:\n-

    \n-\n- 
    \n-eth.dst = eth.src;\n-eth.src = xreg0[0..47];\n-arp.op = 2; /* ARP reply. */\n-arp.tha = arp.sha;\n-arp.sha = xreg0[0..47];\n-arp.tpa <-> arp.spa;\n-outport = inport;\n-flags.loopback = 1;\n-output;\n-
    \n-\n-

    \n- IPv4: For a configured load balancer IPv4 VIP, a similar flow is\n- added with the additional match inport == P\n- if the VIP is reachable from any logical router port of the logical\n- router.\n-

    \n-\n-

    \n- If the router port P is a distributed gateway router\n- port, then the is_chassis_resident(P) is\n- also added in the match condition for the load balancer IPv4\n- VIP A.\n-

    \n-\n-

    \n- IPv6: For a configured NAT (both DNAT and SNAT) IP address or a\n- load balancer IPv6 VIP A (if the VIP is reachable from any\n- logical router port of the logical router), solicited node address\n- S, for each router port P with\n- Ethernet address E, a priority-90 flow matches\n- inport == P && nd_ns &&\n- ip6.dst == {A, S} &&\n- nd.target == A\n- with the following actions:\n-

    \n-\n- 
    \n-eth.dst = eth.src;\n-nd_na {\n-    eth.src = xreg0[0..47];\n-    nd.tll = xreg0[0..47];\n-    ip6.src = A;\n-    nd.target = A;\n-    outport = inport;\n-    flags.loopback = 1;\n-    output;\n-}\n-
    \n-\n-

    \n- If the router port P is a distributed gateway router\n- port, then the is_chassis_resident(P)\n- is also added in the match condition for the load balancer IPv6\n- VIP A.\n-

    \n-\n-

    \n- For the gateway port on a distributed logical router with NAT\n- (where one of the logical router ports specifies a\n- gateway chassis):\n-

    \n-\n-
      \n-
    • \n- If the corresponding NAT rule cannot be handled in a\n- distributed manner, then a priority-92 flow is programmed on\n- the gateway port instance on the\n- gateway chassis. A priority-91 drop flow is\n- programmed on the other chassis when ARP requests/NS packets\n- are received on the gateway port. This behavior avoids\n- generation of multiple ARP responses from different chassis,\n- and allows upstream MAC learning to point to the\n- gateway chassis.\n-
      • \n-\n-
    • \n-

      \n- If the corresponding NAT rule can be handled in a distributed\n- manner, then this flow is only programmed on the gateway port\n- instance where the logical_port specified in the\n- NAT rule resides.\n-

      \n-\n-

      \n- Some of the actions are different for this case, using the\n- external_mac specified in the NAT rule rather\n- than the gateway port's Ethernet address E:\n-

      \n-\n- 
      \n-eth.src = external_mac;\n-arp.sha = external_mac;\n-
      \n-\n-

      \n- or in the case of IPv6 neighbor solicition:\n-

      \n-\n- 
      \n-eth.src = external_mac;\n-nd.tll = external_mac;\n-
      \n-\n-

      \n- This behavior avoids generation of multiple ARP responses\n- from different chassis, and allows upstream MAC learning to\n- point to the correct chassis.\n-

      \n-
      • \n-
    \n-
    • \n-\n-
  • \n- Priority-85 flows which drops the ARP and IPv6 Neighbor Discovery\n- packets.\n-
    • \n-\n-
  • \n-

    \n- A priority-84 flow explicitly allows IPv6 multicast traffic that is\n- supposed to reach the router pipeline (i.e., router solicitation\n- and router advertisement packets).\n-

    \n-
    • \n-\n-
  • \n-

    \n- A priority-83 flow explicitly drops IPv6 multicast traffic that is\n- destined to reserved multicast groups.\n-

    \n-
    • \n-\n-
  • \n-

    \n- A priority-82 flow allows IP multicast traffic if\n- :mcast_relay='true',\n- otherwise drops it.\n-

    \n-
    • \n-\n-
  • \n-

    \n- UDP port unreachable. Priority-80 flows generate ICMP port\n- unreachable messages in reply to UDP datagrams directed to the\n- router's IP address, except in the special case of gateways,\n- which accept traffic directed to a router IP for load balancing\n- and NAT purposes.\n-

    \n-\n-

    \n- These flows should not match IP fragments with nonzero offset.\n-

    \n-
    • \n-\n-
  • \n-

    \n- TCP reset. Priority-80 flows generate TCP reset messages in reply\n- to TCP datagrams directed to the router's IP address, except in\n- the special case of gateways, which accept traffic directed to a\n- router IP for load balancing and NAT purposes.\n-

    \n-\n-

    \n- These flows should not match IP fragments with nonzero offset.\n-

    \n-
    • \n-\n-
  • \n-

    \n- Protocol or address unreachable. Priority-70 flows generate ICMP\n- protocol or address unreachable messages for IPv4 and IPv6\n- respectively in reply to packets directed to the router's IP\n- address on IP protocols other than UDP, TCP, and ICMP, except in the\n- special case of gateways, which accept traffic directed to a router\n- IP for load balancing purposes.\n-

    \n-\n-

    \n- These flows should not match IP fragments with nonzero offset.\n-

    \n-
    • \n-\n-
  • \n- Drop other IP traffic to this router. These flows drop any other\n- traffic destined to an IP address of this router that is not already\n- handled by one of the flows above, which amounts to ICMP (other than\n- echo requests) and fragments with nonzero offsets. For each IP address\n- A owned by the router, a priority-60 flow matches\n- ip4.dst == A or\n- ip6.dst == A\n- and drops the traffic. An exception is made and the above flow\n- is not added if the router port's own IP address is used to SNAT\n- packets passing through that router or if it is used as a\n- load balancer VIP.\n-
    • \n-
\n-\n-

\n- The flows above handle all of the traffic that might be directed to the\n- router itself. The following flows (with lower priorities) handle the\n- remaining traffic, potentially for forwarding:\n-

\n-\n-
    \n-
  • \n- Drop Ethernet local broadcast. A priority-50 flow with match\n- eth.bcast drops traffic destined to the local Ethernet\n- broadcast address. By definition this traffic should not be forwarded.\n-
    • \n-\n-
  • \n- Avoid ICMP time exceeded for multicast. A priority-32 flow with match\n- ip.ttl == {0, 1} && !ip.later_frag &&\n- (ip4.mcast || ip6.mcast) and actions drop; drops\n- multicast packets whose TTL has expired without sending ICMP time\n- exceeded.\n-
    • \n-\n-
  • \n-

    \n- ICMP time exceeded. For each router port P, whose IP\n- address is A, a priority-31 flow with match inport\n- == P && ip.ttl == {0, 1} &&\n- !ip.later_frag matches packets whose TTL has expired, with the\n- following actions to send an ICMP time exceeded reply for IPv4 and\n- IPv6 respectively:\n-

    \n-\n- 
    \n-icmp4 {\n-    icmp4.type = 11; /* Time exceeded. */\n-    icmp4.code = 0;  /* TTL exceeded in transit. */\n-    ip4.dst = ip4.src;\n-    ip4.src = A;\n-    ip.ttl = 254;\n-    next;\n-};\n-\n-icmp6 {\n-    icmp6.type = 3; /* Time exceeded. */\n-    icmp6.code = 0;  /* TTL exceeded in transit. */\n-    ip6.dst = ip6.src;\n-    ip6.src = A;\n-    ip.ttl = 254;\n-    next;\n-};\n-
    \n-
    • \n-\n-
  • \n- TTL discard. A priority-30 flow with match ip.ttl == {0,\n- 1} and actions drop; drops other packets whose TTL\n- has expired, that should not receive a ICMP error reply (i.e. fragments\n- with nonzero offset).\n-
    • \n-\n-
  • \n- Next table. A priority-0 flows match all packets that aren't already\n- handled and uses actions next; to feed them to the next\n- table.\n-
    • \n-
\n-\n-\n-

Ingress Table 4: DHCP Relay Request

\n-

\n- This stage process the DHCP request packets on which\n- dhcp_relay_req_chk action is applied in the IP input stage.\n-

\n-
    \n-
  • \n-

    \n- A priority-100 logical flow is added for each logical router port\n- configured with DHCP relay that matches inport is lrp\n- and ip4.src == 0.0.0.0 and\n- ip4.dst == 255.255.255.255 and udp.src == 68\n- and udp.dst == 67 and reg9[7] == 1\n- and applies following actions. If reg9[7] is set to 1\n- then, dhcp_relay_req_chk action was successful.\n-

    \n-\n- 
    \n-ip4.src=lrp ip;\n-ip4.dst=dhcp server ip;\n-udp.src = 67;\n-next;\n-
    \n-
    • \n-\n-
  • \n-

    \n- A priority-1 logical flow is added for each logical router port\n- configured with DHCP relay that matches inport is lrp\n- and ip4.src == 0.0.0.0 and\n- ip4.dst == 255.255.255.255 and udp.src == 68\n- and udp.dst == 67 and reg9[7] == 0\n- and drops the packet. If reg9[7] is set to 0 then,\n- dhcp_relay_req_chk action was unsuccessful.\n-

    \n-
    • \n-\n-
  • \n- A priority-0 flow that matches all packets to advance to the next\n- table.\n-
    • \n-
\n-\n-

Ingress Table 5: UNSNAT

\n-\n-

\n- This is for already established connections' reverse traffic.\n- i.e., SNAT has already been done in egress pipeline and now the\n- packet has entered the ingress pipeline as part of a reply. It is\n- unSNATted here.\n-

\n-\n-

Ingress Table 5: UNSNAT on Gateway and Distributed Routers

\n-
    \n-
  • \n-

    \n- If the Router (Gateway or Distributed) is configured with\n- load balancers, then below lflows are added:\n-

    \n-\n-

    \n- For each IPv4 address A defined as load balancer\n- VIP with the protocol P (and the protocol port\n- T if defined) is also present as an\n- external_ip in the NAT table,\n- a priority-120 logical flow is added with the match\n- ip4 && ip4.dst == A &&\n- P with the action next; to\n- advance the packet to the next table. If the load balancer\n- has protocol port B defined, then the match also has\n- P.dst == B.\n-

    \n-\n-

    \n- The above flows are also added for IPv6 load balancers.\n-

    \n-
    • \n-
\n-\n-

Ingress Table 5: UNSNAT on Gateway Routers

\n-\n-
    \n-
  • \n-

    \n- If the Gateway router has been configured to force SNAT any\n- previously DNATted packets to B, a priority-110 flow\n- matches ip && ip4.dst == B or\n- ip && ip6.dst == B\n- with an action ct_snat; .\n-

    \n-\n-

    \n- If the Gateway router is configured with\n- lb_force_snat_ip=router_ip then for every logical router\n- port P attached to the Gateway router with the router ip\n- B, a priority-110 flow is added with the match\n- inport == P &&\n- ip4.dst == B or inport == P\n- && ip6.dst == B with an action\n- ct_snat; .\n-

    \n-\n-

    \n- If the Gateway router has been configured to force SNAT any\n- previously load-balanced packets to B, a priority-100 flow\n- matches ip && ip4.dst == B or\n- ip && ip6.dst == B\n- with an action ct_snat; .\n-

    \n-\n-

    \n- For each NAT configuration in the OVN Northbound database, that asks\n- to change the source IP address of a packet from A to\n- B, a priority-90 flow matches\n- ip && ip4.dst == B or\n- ip && ip6.dst == B\n- with an action ct_snat; . If the NAT rule is of type\n- dnat_and_snat and has stateless=true in the\n- options, then the action would be next;.\n-

    \n-\n-

    \n- A priority-0 logical flow with match 1 has actions\n- next;.\n-

    \n-
    • \n-
\n-\n-

Ingress Table 5: UNSNAT on Distributed Routers

\n-\n-
    \n-
  • \n-

    \n- For each configuration in the OVN Northbound database, that asks\n- to change the source IP address of a packet from A to\n- B, two priority-100 flows are added.\n-

    \n-\n-

    \n- If the NAT rule cannot be handled in a distributed manner, then\n- the below priority-100 flows are only programmed on the\n- gateway chassis.\n-

    \n-\n-
      \n-
    • \n-

      \n- The first flow matches ip &&\n- ip4.dst == B && inport == GW\n- or ip && ip6.dst == B &&\n- inport == GW\n- where GW is the distributed gateway port\n- corresponding to the NAT rule (specified or inferred), with an\n- action ct_snat; to unSNAT in the common\n- zone. If the NAT rule is of type dnat_and_snat and has\n- stateless=true in the options, then the action\n- would be next;.\n-

      \n-\n-

      \n- If the NAT entry is of type snat, then there is an\n- additional match is_chassis_resident(cr-GW)\n- where cr-GW is the chassis resident port of\n- GW.\n-

      \n-
      • \n-
    \n-\n-

    \n- A priority-0 logical flow with match 1 has actions\n- next;.\n-

    \n-
    • \n-
\n-\n-

Ingress Table 6: POST USNAT

\n-\n-

\n- This is to check whether the packet is already tracked in SNAT zone.\n- It contains a priority-0 flow that simply moves traffic to the next\n- table.\n-

\n-\n-

\n- If the options:ct-commit-all is set to true the\n- following two flows are configured matching on ip &&\n- ct.new with an action flags.unsnat_new = 1; next; \n- and ip && !ct.trk with an action\n- flags.unsnat_not_tracked = 1; next; Which sets one of the\n- flags that is used in later stages. There is extra match on both when\n- there is configured DGP\n- inport == DGP && is_chassis_resident(CHASSIS).\n-

\n-\n-

Ingress Table 7: DEFRAG

\n-\n-

\n- This is to send packets to connection tracker for tracking and\n- defragmentation. It contains a priority-0 flow that simply moves traffic\n- to the next table.\n-

\n-\n-

\n- For all load balancing rules that are configured in\n- OVN_Northbound database for a Gateway router,\n- a priority-100 flow is added for each configured virtual IP address\n- VIP. For IPv4 VIPs the flow matches\n- ip && ip4.dst == VIP. For IPv6\n- VIPs, the flow matches ip && ip6.dst ==\n- VIP. The flow applies the action ct_dnat;\n- to send IP packets to the connection tracker for packet de-fragmentation\n- and to dnat the destination IP for the committed connection before\n- sending it to the next table.\n-

\n-\n-

\n- If ECMP routes with symmetric reply are configured in the\n- OVN_Northbound database for a gateway router, a priority-100\n- flow is added for each router port on which symmetric replies are\n- configured. The matching logic for these ports essentially reverses the\n- configured logic of the ECMP route. So for instance, a route with a\n- destination routing policy will instead match if the source IP address\n- matches the static route's prefix. The flow uses the actions\n- chk_ecmp_nh_mac(); ct_next or\n- chk_ecmp_nh(); ct_next to send IP packets to table\n- 76 or to table 77 in order to check if source\n- info are already stored by OVN and then to the connection tracker for\n- packet de-fragmentation and tracking before sending it to the next table.\n-

\n-\n-

\n- If load balancing rules are configured in OVN_Northbound\n- database for a Gateway router, a priority 50 flow that matches\n- icmp || icmp6 with an action of ct_dnat;,\n- this allows potentially related ICMP traffic to pass through CT.\n-

\n-\n-

\n- If the options:ct-commit-all is set to true\n- the following flow is configured matching on ip &&\n- (!ct.trk || !ct.rpl) with an action ct_next(dnat);.\n- There is extra match when the LR is configured as DGP\n- inport == DGP && is_chassis_resident(CHASSIS).\n-

\n-\n-

Ingress Table 8: Connection tracking field extraction

\n-\n-

\n- This table extracts connection tracking fields for new connections\n- and stores them in registers for use by subsequent load balancing\n- stages.\n-

\n-\n-
    \n-
  • \n-

    \n- For all new connections (ct.new), a priority-100 flow\n- extracts the connection tracking protocol and destination port\n- information into registers:\n-

    \n-\n- 
    \n-reg1[16..23] = ct_proto();\n-reg1[0..15] = ct_tp_dst();\n-next;\n-
    \n-\n-

    \n- This stores the connection tracking destination port in\n- REG_CT_TP_DST (reg1[0..15]) and the protocol\n- in REG_CT_PROTO (reg1[16..23]).\n-

    \n-
    • \n-\n-
  • \n- A priority-0 flow that matches all packets and advances to the\n- next table with action next;.\n-
    • \n-
\n-\n-

Ingress Table 9: Load balancing affinity check

\n-\n-

\n- Load balancing affinity check table contains the following\n- logical flows:\n-

\n-\n-
    \n-
  • \n- For all the configured load balancing rules for a logical router where\n- a positive affinity timeout is specified in options\n- column, that includes a L4 port PORT of protocol\n- P and IPv4 or IPv6 address VIP, a priority-100\n- flow that matches on ct.new && ip &&\n- ip.dst == VIP && REG_CT_PROTO == P_NUM\n- && REG_CT_TP_DST == PORT (xxreg0 ==\n- VIP in the IPv6 case) with an action of\n- reg0 = ip.dst; reg9[16..31] = P.dst; reg9[6] = chk_lb_aff();\n- next; (xxreg0 == ip6.dst in the IPv6\n- case), where P_NUM is the protocol number (6 for TCP, 17\n- for UDP, 132 for SCTP).\n-
    • \n-\n-
  • \n- A priority 0 flow is added which matches on all packets and applies\n- the action next;.\n-
    • \n-
\n-\n-

Ingress Table 10: DNAT

\n-\n-

\n- Packets enter the pipeline with destination IP address that needs to\n- be DNATted from a virtual IP address to a real IP address. Packets\n- in the reverse direction needs to be unDNATed.\n-

\n-\n-

Ingress Table 8: Load balancing DNAT rules

\n-\n-

\n- Following load balancing DNAT flows are added for Gateway router or\n- Router with gateway port. These flows are programmed only on the\n- gateway chassis. These flows do not get programmed for\n- load balancers with IPv6 VIPs.\n-

\n-\n-
    \n-
  • \n- For all the configured load balancing rules for a logical router where\n- a positive affinity timeout is specified in options\n- column, that includes a L4 port PORT of protocol\n- P and IPv4 or IPv6 address VIP, a priority-150\n- flow that matches on reg9[6] == 1 && ct.new &&\n- ip && ip.dst == VIP && REG_CT_PROTO ==\n- P_NUM &&\n- REG_CT_TP_DST == PORT with an action of\n- ct_lb_mark(args) , where args\n- contains comma separated IP addresses (and optional port numbers)\n- to load balance to, and P_NUM is the protocol number\n- (6 for TCP, 17 for UDP, 132 for SCTP). The address family of the IP\n- addresses of args is the same as the address family of\n- VIP.\n-
    • \n-\n-
  • \n- If controller_event has been enabled for all the configured load\n- balancing rules for a Gateway router or Router with gateway port\n- in OVN_Northbound database that does not have configured\n- backends, a priority-130 flow is added to trigger ovn-controller events\n- whenever the chassis receives a packet for that particular VIP.\n- If event-elb meter has been previously created, it will be\n- associated to the empty_lb logical flow\n-
    • \n-\n-
  • \n-

    \n- For all the configured load balancing rules for a Gateway router or\n- Router with gateway port in OVN_Northbound database that\n- includes a L4 port PORT of protocol P and IPv4\n- or IPv6 address VIP, a priority-120 flow that matches on\n- ct.new && !ct.rel && ip && ip.dst ==\n- VIP && REG_CT_PROTO == P_NUM &&\n- REG_CT_TP_DST == PORT with an action of\n- ct_lb_mark(args), where args contains\n- comma separated IPv4 or IPv6 addresses (and optional port numbers) to\n- load balance to, and P_NUM is the protocol number\n- (6 for TCP, 17 for UDP, 132 for SCTP). If the router is configured\n- to force SNAT any\n- load-balanced packets, the above action will be replaced by\n- flags.force_snat_for_lb = 1; ct_lb_mark(args;\n- force_snat);.\n- If the load balancing rule is configured with skip_snat\n- set to true, the above action will be replaced by\n- flags.skip_snat_for_lb = 1; ct_lb_mark(args;\n- skip_snat);.\n- If health check is enabled, then\n- args will only contain those endpoints whose service\n- monitor status entry in OVN_Southbound db is\n- either online or empty.\n-

    \n-\n-
    • \n-\n-
  • \n-

    \n- For all the configured load balancing rules for a router in\n- OVN_Northbound database that includes just an IP address\n- VIP to match on, a priority-110 flow that matches on\n- ct.new && !ct.rel && ip4 && ip.dst ==\n- VIP with an action of\n- ct_lb_mark(args), where args contains\n- comma separated IPv4 or IPv6 addresses. If the router is configured\n- to force SNAT any load-balanced packets, the above action will be\n- replaced by flags.force_snat_for_lb = 1;\n- ct_lb_mark(args; force_snat);.\n- If the load balancing rule is configured with skip_snat\n- set to true, the above action will be replaced by\n- flags.skip_snat_for_lb = 1; ct_lb_mark(args;\n- skip_snat);.\n-

    \n-\n-

    \n- The previous table lr_in_defrag sets the register\n- reg0 (or xxreg0 for IPv6) and does\n- ct_dnat. Hence for established traffic, this\n- table just advances the packet to the next stage.\n-

    \n-
    • \n-\n-
  • \n- If the load balancer is created with --reject option and\n- it has no active backends, a TCP reset segment (for tcp) or an ICMP\n- port unreachable packet (for all other kind of traffic) will be sent\n- whenever an incoming packet is received for this load-balancer.\n- Please note using --reject option will disable\n- empty_lb SB controller event for this load balancer.\n-
    • \n-\n-
  • \n-

    \n- For the related traffic, a priority 50 flow that matches\n- ct.rel && !ct.est && !ct.new \n- with an action of ct_commit_nat;, if the router\n- has load balancer assigned to it. Along with two priority 70 flows\n- that match skip_snat and force_snat\n- flags, setting the flags.force_snat_for_lb = 1 or\n- flags.skip_snat_for_lb = 1 accordingly.\n-

    \n-
    • \n-
  • \n-

    \n- For the established traffic, a priority 50 flow that matches\n- ct.est && !ct.rel && !ct.new &&\n- ct_mark.natted with an action of next;,\n- if the router has load balancer assigned to it. Along with two\n- priority 70 flows that match skip_snat and\n- force_snat flags, setting the\n- flags.force_snat_for_lb = 1 or\n- flags.skip_snat_for_lb = 1 accordingly.\n-

    \n-
    • \n-
\n-\n-

Ingress Table 9: DNAT on Gateway Routers

\n-\n-
    \n-
  • \n- For each configuration in the OVN Northbound database, that asks\n- to change the destination IP address of a packet from A to\n- B, a priority-100 flow matches ip &&\n- ip4.dst == A or ip &&\n- ip6.dst == A with an action\n- flags.loopback = 1; ct_dnat(B);. If the\n- Gateway router is configured to force SNAT any DNATed packet,\n- the above action will be replaced by\n- flags.force_snat_for_dnat = 1; flags.loopback = 1;\n- ct_dnat(B);. If the NAT rule is of type\n- dnat_and_snat and has stateless=true in the\n- options, then the action would be ip4/6.dst=\n- (B).\n-\n-

    \n- If the NAT rule has allowed_ext_ips configured, then\n- there is an additional match ip4.src == allowed_ext_ips\n- . Similarly, for IPV6, match would be ip6.src ==\n- allowed_ext_ips.\n-

    \n-\n-

    \n- If the NAT rule has exempted_ext_ips set, then\n- there is an additional flow configured at priority 101.\n- The flow matches if source ip is an exempted_ext_ip\n- and the action is next; . This flow is used to\n- bypass the ct_dnat action for a packet originating from\n- exempted_ext_ips.\n-

    \n-\n-

    \n- For each configuration in the OVN Northbound database, that asks\n- to change the destination IP address of a packet from A\n- to B, match M and priority P,\n- a logical flow that matches ip && ip4.dst ==\n- A or ip && ip6.dst == A\n- && (M) with an action\n- flags.loopback = 1; ct_dnat(B);.\n- The priority of the flow is calculated based as\n- 300 + P. If the Gateway router is\n- configured to force SNAT any DNATed packet, the above action will\n- be replaced by flags.force_snat_for_dnat = 1;\n- flags.loopback = 1; ct_dnat(B);. If the NAT rule\n- is of type dnat_and_snat and has stateless=true in the\n- options, then the action would be ip4/6.dst=\n- (B).\n-

    \n-
    • \n-\n-
  • \n-

    \n- If the options:ct-commit-all is set to true\n- the following flow is configured matching on ip &&\n- ct.new with an action ct_commit_to_zone(dnat);.\n-

    \n-
    • \n-\n-
  • \n- A priority-0 logical flow with match 1 has actions\n- next;.\n-
    • \n-
\n-\n-

Ingress Table 9: DNAT on Distributed Routers

\n-\n-

\n- On distributed routers, the DNAT table only handles packets\n- with destination IP address that needs to be DNATted from a\n- virtual IP address to a real IP address. The unDNAT processing\n- in the reverse direction is handled in a separate table in the\n- egress pipeline.\n-

\n-\n-
    \n-
  • \n-

    \n- For each configuration in the OVN Northbound database, that asks\n- to change the destination IP address of a packet from A to\n- B, a priority-100 flow matches ip &&\n- ip4.dst == B && inport == GW,\n- where GW is the logical router gateway port corresponding\n- to the NAT rule (specified or inferred), with an action\n- ct_dnat(B);. The match will include\n- ip6.dst == B in the IPv6 case.\n- If the NAT rule is of type dnat_and_snat and has\n- stateless=true in the options, then the action\n- would be ip4/6.dst=(B).\n-

    \n-\n-

    \n- If the NAT rule cannot be handled in a distributed manner, then\n- the priority-100 flow above is only programmed on the\n- gateway chassis.\n-

    \n-\n-

    \n- If the NAT rule has allowed_ext_ips configured, then\n- there is an additional match ip4.src == allowed_ext_ips\n- . Similarly, for IPV6, match would be ip6.src ==\n- allowed_ext_ips.\n-

    \n-\n-

    \n- If the NAT rule has exempted_ext_ips set, then\n- there is an additional flow configured at priority 101.\n- The flow matches if source ip is an exempted_ext_ip\n- and the action is next; . This flow is used to\n- bypass the ct_dnat action for a packet originating from\n- exempted_ext_ips.\n-

    \n-\n-

    \n- If the options:ct-commit-all is set to true\n- the following flow is configured matching on ip &&\n- ct.new && inport == DGP &&\n- is_chassis_resident(CHASSIS) with an action\n- ct_commit_to_zone(dnat);.\n-

    \n-\n-

    \n- A priority-0 logical flow with match 1 has actions\n- next;.\n-

    \n-
    • \n-
\n-\n-

Ingress Table 11: Load balancing affinity learn

\n-\n-

\n- Load balancing affinity learn table contains the following\n- logical flows:\n-

\n-\n-
    \n-
  • \n- For all the configured load balancing rules for a logical router where\n- a positive affinity timeout T is specified in options\n- column, that includes a L4 port PORT of protocol\n- P and IPv4 or IPv6 address VIP, a priority-100\n- flow that matches on reg9[6] == 0 && ct.new &&\n- ip && reg0 == VIP && P &&\n- reg9[16..31] == PORT (xxreg0 ==\n- VIP in the IPv6 case) with an action of\n- commit_lb_aff(vip = VIP:PORT, backend =\n- backend ip: backend port, proto = P,\n- timeout = T);.\n-
    • \n-\n-
  • \n- A priority 0 flow is added which matches on all packets and applies\n- the action next;.\n-
    • \n-
\n-\n-

Ingress Table 12: ECMP symmetric reply processing

\n-
    \n-
  • \n- If ECMP routes with symmetric reply are configured in the\n- OVN_Northbound database for a gateway router, a\n- priority-100 flow is added for each router port on which symmetric\n- replies are configured. The matching logic for these ports essentially\n- reverses the configured logic of the ECMP route. So for instance, a\n- route with a destination routing policy will instead match if the\n- source IP address matches the static route's prefix. The flow uses\n- the action ct_commit { ct_label.ecmp_reply_eth = eth.src;\"\n- \" ct_mark.ecmp_reply_port = K;}; commit_ecmp_nh(); next;\n- to commit the connection and storing eth.src and\n- the ECMP reply port binding tunnel key K in the\n- ct_label and the traffic pattern to table\n- 76 or 77.\n-
    • \n-
\n-\n-

Ingress Table 13: IPv6 ND RA option processing

\n-\n-
    \n-
  • \n-

    \n- A priority-50 logical flow is added for each logical router port\n- configured with IPv6 ND RA options which matches IPv6 ND Router\n- Solicitation packet and applies the action\n- put_nd_ra_opts and advances the packet to the next\n- table.\n-

    \n-\n- 
    \n-reg0[5] = put_nd_ra_opts(options);next;\n-
    \n-\n-

    \n- For a valid IPv6 ND RS packet, this transforms the packet into an\n- IPv6 ND RA reply and sets the RA options to the packet and stores 1\n- into reg0[5]. For other kinds of packets, it just stores 0 into\n- reg0[5]. Either way, it continues to the next table.\n-

    \n-
    • \n-\n-
  • \n- A priority-0 logical flow with match 1 has actions\n- next;.\n-
    • \n-
\n-\n-

Ingress Table 14: IPv6 ND RA responder

\n-\n-

\n- This table implements IPv6 ND RA responder for the IPv6 ND RA replies\n- generated by the previous table.\n-

\n-\n-
    \n-
  • \n-

    \n- A priority-50 logical flow is added for each logical router port\n- configured with IPv6 ND RA options which matches IPv6 ND RA\n- packets and reg0[5] == 1 and responds back to the\n- inport after applying these actions.\n- If reg0[5] is set to 1, it means that the action\n- put_nd_ra_opts was successful.\n-

    \n-\n- 
    \n-eth.dst = eth.src;\n-eth.src = E;\n-ip6.dst = ip6.src;\n-ip6.src = I;\n-outport = P;\n-flags.loopback = 1;\n-output;\n-
    \n-\n-

    \n- where E is the MAC address and I is the IPv6\n- link local address of the logical router port.\n-

    \n-\n-

    \n- (This terminates packet processing in ingress pipeline; the packet\n- does not go to the next ingress table.)\n-

    \n-
    • \n-\n-
  • \n- A priority-0 logical flow with match 1 has actions\n- next;.\n-
    • \n-
\n-\n-

Ingress Table 15: IP Routing Pre

\n-\n-

\n- If a packet arrived at this table from Logical Router Port P\n- which has options:route_table value set, a logical flow with\n- match inport == \"P\" with priority 100 and action\n- setting unique-generated per-datapath 32-bit value (non-zero) in OVS\n- register 7. This register's value is checked in next table. If packet\n- didn't match any configured inport (<main> route table),\n- register 7 value is set to 0.\n-

\n-\n-

\n- This table contains the following logical flows:\n-

\n-\n-
    \n-
  • \n-

    \n- Priority-100 flow with match inport == \"LRP_NAME\" value\n- and action, which set route table identifier in reg7.\n-

    \n-\n-

    \n- A priority-0 logical flow with match 1 has actions\n- reg7 = 0; next;.\n-

    \n-
    • \n-
\n-\n-

Ingress Table 16: IP Routing

\n-\n-

\n- A packet that arrives at this table is an IP packet that should be\n- routed to the address in ip4.dst or\n- ip6.dst. This table implements IP routing, setting\n- reg0 (or xxreg0 for IPv6) to the next-hop IP\n- address (leaving ip4.dst or ip6.dst, the\n- packet's final destination, unchanged) and advances to the next\n- table for ARP resolution. It also sets reg1 (or\n- xxreg1) to the IP address owned by the selected router\n- port (ingress table ARP Request will generate an ARP\n- request, if needed, with reg0 as the target protocol\n- address and reg1 as the source protocol address).\n-

\n-\n-

\n- For ECMP routes, i.e. multiple static routes with same policy and\n- prefix but different nexthops, the above actions are deferred to next\n- table. This table, instead, is responsible for determine the ECMP\n- group id and select a member id within the group based on 5-tuple\n- hashing. It stores group id in reg8[0..15] and member id in\n- reg8[16..31]. This step is skipped with a priority-10300\n- rule if the traffic going out the ECMP route is reply traffic, and the\n- ECMP route was configured to use symmetric replies. Instead, the stored\n- values in conntrack is used to choose the destination. The\n- ct_label.ecmp_reply_eth tells the destination MAC address to\n- which the packet should be sent. The ct_mark.ecmp_reply_port\n- tells the logical router port on which the packet should be sent. These\n- values saved to the conntrack fields when the initial ingress traffic is\n- received over the ECMP route and committed to conntrack.\n- If REGBIT_KNOWN_ECMP_NH is set, the priority-10300\n- flows in this stage set the outport, while the\n- eth.dst is set by flows at the ARP/ND Resolution stage.\n-

\n-\n-

\n- This table contains the following logical flows:\n-

\n-\n-
    \n-
  • \n-

    \n- Priority-10550 flow that drops IPv6 Router Solicitation/Advertisement\n- packets that were not processed in previous tables.\n-

    \n-
    • \n-\n-
  • \n-

    \n- Priority-10550 flows that drop IGMP and MLD packets with source MAC\n- address owned by the router. These are used to prevent looping\n- statically forwarded IGMP and MLD packets for which TTL is not\n- decremented (it is always 1).\n-

    \n-
    • \n-\n-
  • \n-

    \n- Priority-10500 flows that match IP multicast traffic destined to\n- groups registered on any of the attached switches and sets\n- outport to the associated multicast group that will\n- eventually flood the traffic to all interested attached logical\n- switches. The flows also decrement TTL.\n-

    \n-
    • \n-\n-
  • \n-

    \n- Priority-10460 flows that match IGMP and MLD control packets,\n- set outport to the MC_STATIC\n- multicast group, which ovn-northd\n- populates with the logical ports that have\n- \n- :mcast_flood='true'. If no router ports are configured\n- to flood multicast traffic the packets are dropped.\n-

    \n-
    • \n-\n-
  • \n-

    \n- Priority-10450 flow that matches unregistered IP multicast traffic\n- decrements TTL and sets outport to the\n- MC_STATIC multicast group, which ovn-northd\n- populates with the logical ports that have\n- \n- :mcast_flood='true'. If no router ports are configured\n- to flood multicast traffic the packets are dropped.\n-

    \n-
    • \n-\n-
  • \n-

    \n- IPv4 routing table. For each route to IPv4 network N with\n- netmask M, on router port P with IP address\n- A and Ethernet\n- address E, a logical flow with match ip4.dst ==\n- N/M, whose priority is the number of\n- 1-bits in M, has the following actions:\n-

    \n-\n- 
    \n-ip.ttl--;\n-reg8[0..15] = 0;\n-reg0 = G;\n-reg1 = A;\n-eth.src = E;\n-outport = P;\n-flags.loopback = 1;\n-next;\n-
    \n-\n-

    \n- (Ingress table 1 already verified that ip.ttl--; will\n- not yield a TTL exceeded error.)\n-

    \n-\n-

    \n- If the route has a gateway, G is the gateway IP address.\n- Instead, if the route is from a configured static route, G\n- is the next hop IP address. Else it is ip4.dst.\n-

    \n-
    • \n-\n-
  • \n-

    \n- IPv6 routing table. For each route to IPv6 network\n- N with netmask M, on router port\n- P with IP address A and Ethernet address\n- E, a logical flow with match in CIDR notation\n- ip6.dst == N/M,\n- whose priority is the integer value of M, has the\n- following actions:\n-

    \n-\n- 
    \n-ip.ttl--;\n-reg8[0..15] = 0;\n-xxreg0 = G;\n-xxreg1 = A;\n-eth.src = E;\n-outport = inport;\n-flags.loopback = 1;\n-next;\n-
    \n-\n-

    \n- (Ingress table 1 already verified that ip.ttl--; will\n- not yield a TTL exceeded error.)\n-

    \n-\n-

    \n- If the route has a gateway, G is the gateway IP address.\n- Instead, if the route is from a configured static route, G\n- is the next hop IP address. Else it is ip6.dst.\n-

    \n-\n-

    \n- If the address A is in the link-local scope, the\n- route will be limited to sending on the ingress port.\n-

    \n-\n-

    \n- For each static route the reg7 == id && is\n- prefixed in logical flow match portion. For routes with\n- route_table value set a unique non-zero id is used.\n- For routes within <main> route table (no route\n- table set), this id value is 0.\n-

    \n-

    \n- For each connected route (route to the LRP's subnet CIDR)\n- the logical flow match portion has no\n- reg7 == id && prefix to have route to LRP's\n- subnets in all routing tables.\n-

    \n-
    • \n-\n-
  • \n-

    \n- For ECMP routes, they are grouped by policy and prefix. An unique id\n- (non-zero) is assigned to each group, and each member is also\n- assigned an unique id (non-zero) within each group.\n-

    \n-\n-

    \n- For each IPv4/IPv6 ECMP group with group id GID and member\n- ids MID1, MID2, ..., a logical flow with match\n- in CIDR notation ip4.dst == N/M,\n- or ip6.dst == N/M, whose priority\n- is the integer value of M, has the following actions:\n-

    \n-\n- 
    \n-ip.ttl--;\n-flags.loopback = 1;\n-reg8[0..15] = GID;\n-reg8[16..31] = select(MID1, MID2, ...);\n-
    \n-

    \n- However, when there is only one route in an ECMP group, group actions\n- will be:\n-

    \n-\n- 
    \n-ip.ttl--;\n-flags.loopback = 1;\n-reg8[0..15] = GID;\n-reg8[16..31] = MID1);\n-
    \n-
    • \n-\n-
  • \n- A priority-0 logical flow that matches all packets not already handled\n- (match 1) and drops them (action drop;).\n-
    • \n-
\n-\n-

Ingress Table 17: IP_ROUTING_ECMP

\n-\n-

\n- This table implements the second part of IP routing for ECMP routes\n- following the previous table. If a packet matched a ECMP group in the\n- previous table, this table matches the group id and member id stored\n- from the previous table, setting reg0\n- (or xxreg0 for IPv6) to the next-hop IP address\n- (leaving ip4.dst or ip6.dst, the\n- packet's final destination, unchanged) and advances to the next\n- table for ARP resolution. It also sets reg1 (or\n- xxreg1) to the IP address owned by the selected router\n- port (ingress table ARP Request will generate an ARP\n- request, if needed, with reg0 as the target protocol\n- address and reg1 as the source protocol address).\n-

\n-\n-

\n- This processing is skipped for reply traffic being sent out of an ECMP\n- route if the route was configured to use symmetric replies.\n-

\n-\n-

\n- This table contains the following logical flows:\n-

\n-\n-
    \n-
  • \n-

    \n- A priority-150 flow that matches reg8[0..15] == 0\n- with action next; directly bypasses packets of non-ECMP\n- routes.\n-

    \n-
    • \n-\n-
  • \n-

    \n- For each member with ID MID in each ECMP group with ID\n- GID, a priority-100 flow with match\n- reg8[0..15] == GID && reg8[16..31] == MID\n- has following actions:\n-

    \n-\n- 
    \n-[xx]reg0 = G;\n-[xx]reg1 = A;\n-eth.src = E;\n-outport = P;\n-
    \n-
    • \n-\n-
  • \n- A priority-0 logical flow that matches all packets not already handled\n- (match 1) and drops them (action drop;).\n-
    • \n-
\n-\n-

Ingress Table 18: Router policies

\n-

\n- This table adds flows for the logical router policies configured\n- on the logical router. Please see the\n- OVN_Northbound database Logical_Router_Policy\n- table documentation in ovn-nb for supported actions.\n-

\n-\n-
    \n-
  • \n-

    \n- For each router policy configured on the logical router, a\n- logical flow is added with specified priority, match and\n- actions.\n-

    \n-
    • \n-\n-
  • \n-

    \n- If the policy action is reroute with 2 or more nexthops\n- defined, then the logical flow is added with the following actions:\n-

    \n-\n- 
    \n-reg8[0..15] = GID;\n-reg8[16..31] = select(1,..n);\n-
    \n-\n-

    \n- where GID is the ECMP group id generated by\n- ovn-northd for this policy and n\n- is the number of nexthops. select action\n- selects one of the nexthop member id, stores it in the register\n- reg8[16..31] and advances the packet to the\n- next stage.\n-

    \n-
    • \n-\n-
  • \n-

    \n- If the policy action is reroute with just one nexhop,\n- then the logical flow is added with the following actions:\n-

    \n-\n- 
    \n-[xx]reg0 = H;\n-eth.src = E;\n-outport = P;\n-reg8[0..15] = 0;\n-flags.loopback = 1;\n-next;\n-
    \n-\n-

    \n- where H is the nexthop defined in the\n- router policy, E is the ethernet address of the\n- logical router port from which the nexthop is\n- reachable and P is the logical router port from\n- which the nexthop is reachable.\n-

    \n-
    • \n-\n-
  • \n-

    \n- If a router policy has the option pkt_mark=m\n- set and if the action is not drop, then the action also\n- includes pkt.mark = m to mark the packet\n- with the marker m.\n-

    \n-
    • \n-
\n-\n-

Ingress Table 19: ECMP handling for router policies

\n-

\n- This table handles the ECMP for the router policies configured\n- with multiple nexthops.\n-

\n-\n-
    \n-
  • \n-

    \n- A priority-150 flow is added to advance the packet to the next stage\n- if the ECMP group id register reg8[0..15] is 0.\n-

    \n-
    • \n-\n-
  • \n-

    \n- For each ECMP reroute router policy with multiple nexthops,\n- a priority-100 flow is added for each nexthop H\n- with the match reg8[0..15] == GID &&\n- reg8[16..31] == M where GID\n- is the router policy group id generated by ovn-northd\n- and M is the member id of the nexthop H\n- generated by ovn-northd. The following actions are added\n- to the flow:\n-

    \n-\n- 
    \n-[xx]reg0 = H;\n-eth.src = E;\n-outport = P\n-\"flags.loopback = 1; \"\n-\"next;\"\n-
    \n-\n-

    \n- where H is the nexthop defined in the\n- router policy, E is the ethernet address of the\n- logical router port from which the nexthop is\n- reachable and P is the logical router port from\n- which the nexthop is reachable.\n-

    \n-
    • \n-\n-
  • \n- A priority-0 logical flow that matches all packets not already handled\n- (match 1) and drops them (action drop;).\n-
    • \n-
\n-\n-

Ingress Table 20: DHCP Relay Response Check

\n-

\n- This stage process the DHCP response packets coming from the DHCP server.\n-

\n-\n-
    \n-
  • \n-

    \n- A priority 100 logical flow is added for each logical router port\n- configured with DHCP relay that matches ip4.src is\n- DHCP server ip and ip4.dst is lrp IP and\n- ip4.frag == 0 and udp.src == 67 and\n- udp.dst == 67 and applies dhcp_relay_resp_chk\n- action. Original destination ip is stored in reg2.\n-

    \n-\n- 
    \n-        reg9[8] = dhcp_relay_resp_chk(lrp_ip,\n-                                      dhcp_server_ip);next\n-
    \n-\n-

    \n- if action is successful then, dest mac and dest IP addresses are\n- updated in the packet and stores 1 into reg9[8] else stores 0 into\n- reg9[8].\n-

    \n-
    • \n-\n-
  • \n- A priority-0 flow that matches all packets to advance to the next\n- table.\n-
    • \n-
\n-\n-

Ingress Table 21: DHCP Relay Response

\n-

\n- This stage process the DHCP response packets on which\n- dhcp_relay_resp_chk action is applied in the previous stage.\n-

\n-
    \n-
  • \n-

    \n- A priority 100 logical flow is added for each logical router port\n- configured with DHCP relay that matches ip4.src is\n- DHCP server ip and reg2 is lrp IP and\n- udp.src == 67 and udp.dst == 67\n- and reg9[8] == 1 and applies following actions. If\n- reg9[8] is set to 1 then,\n- dhcp_relay_resp_chk was successful.\n-

    \n-\n- 
    \n-ip4.src = lrp ip;\n-udp.dst = 68;\n-outport = lrp port;\n-output;\n-
    \n-
    • \n-\n-
  • \n-

    \n- A priority 1 logical flow is added for the logical router port\n- on which DHCP relay is enabled that matches ip4.src\n- is DHCP server ip and reg2 is lrp IP and\n- udp.src == 67 and udp.dst == 67\n- and reg9[8] == 0 and drops the packet. If\n- reg9[8] is set to 0 then,\n- dhcp_relay_resp_chk was unsuccessful.\n-

    \n-
    • \n-\n-
  • \n- A priority-0 flow that matches all packets to advance to the next\n- table.\n-
    • \n-
\n-\n-

Ingress Table 22: ARP/ND Resolution

\n-\n-

\n- Any packet that reaches this table is an IP packet whose next-hop\n- IPv4 address is in reg0 or IPv6 address is in\n- xxreg0. (ip4.dst or\n- ip6.dst contains the final destination.) This table\n- resolves the IP address in reg0 (or\n- xxreg0) into an output port in outport\n- and an Ethernet address in eth.dst, using the\n- following flows:\n-

\n-\n-
    \n-
  • \n-

    \n- A priority-500 flow that matches IP multicast traffic that was\n- allowed in the routing pipeline. For this kind of traffic the\n- outport was already set so the flow just advances to\n- the next table.\n-

    \n-
    • \n-\n-
  • \n-

    \n- Priority-200 flows that match ECMP reply traffic for the routes\n- configured to use symmetric replies, with actions\n- push(xxreg1); xxreg1 = ct_label; eth.dst = xxreg1[32..79]; pop(xxreg1); next;.\n- xxreg1 is used here to avoid masked access to ct_label,\n- to make the flow HW-offloading friendly.\n-

    \n-
    • \n-\n-
  • \n-

    \n- Static MAC bindings. MAC bindings can be known statically based on\n- data in the OVN_Northbound database. For router ports\n- connected to logical switches, MAC bindings can be known statically\n- from the addresses column in the\n- Logical_Switch_Port table. (Note: the flow is not\n- installed for IPs of logical switch ports of type\n- virtual, and dynamic MAC binding is used for those IPs\n- instead, so that virtual parent failover does not depend on \n- ovn-northd, to achieve better failover performance.) For\n- router ports connected to other logical routers, MAC bindings can be\n- known statically from the mac and networks\n- column in the Logical_Router_Port table. (Note: the\n- flow is NOT installed for the IP addresses that belong to a neighbor\n- logical router port if the current router has the\n- options:dynamic_neigh_routers set to true)\n-

    \n-\n-

    \n- For each IPv4 address A whose host is known to have\n- Ethernet address E on router port P, a\n- priority-100 flow with match outport === P\n- && reg0 == A has actions\n- eth.dst = E; next;.\n-

    \n-\n-

    \n- For each IPv6 address A whose host is known to have\n- Ethernet address E on router port P, a\n- priority-100 flow with match outport === P\n- && xxreg0 == A has actions\n- eth.dst = E; next;.\n-

    \n-\n-

    \n- For each logical router port with an IPv4 address A and\n- a mac address of E that is reachable via a different\n- logical router port P, a priority-100 flow with\n- match outport === P && reg0 ==\n- A has actions eth.dst = E;\n- next;.\n-

    \n-\n-

    \n- For each logical router port with an IPv6 address A and\n- a mac address of E that is reachable via a different\n- logical router port P, a priority-100 flow with\n- match outport === P && xxreg0 ==\n- A has actions eth.dst = E;\n- next;.\n-

    \n-
    • \n-\n-
  • \n-

    \n- Static MAC bindings from NAT entries. MAC bindings can also be known\n- for the entries in the NAT table. Below flows are\n- programmed for distributed logical routers i.e with a distributed\n- router port.\n-

    \n-\n-

    \n- For each row in the NAT table with IPv4 address\n- A in the column of\n- table, below two flows are\n- programmed:\n-

    \n-\n-

    \n- A priority-100 flow with the match outport == P\n- && reg0 == A has actions eth.dst =\n- E; next;, where P is the distributed\n- logical router port, E is the Ethernet address if set in\n- the \n- column of table for of type\n- dnat_and_snat, otherwise the Ethernet address of the\n- distributed logical router port. Note that if the\n- is not\n- within a subnet on the owning logical router, then OVN will only\n- create ARP resolution flows if the \n- is set to true. Otherwise, no ARP resolution flows\n- will be added.\n-

    \n-\n-

    \n- Corresponding to the above flow, a priority-150 flow with the match\n- inport == P && outport == P\n- && ip4.dst == A has actions\n- drop; to exclude packets that have gone through\n- DNAT/unSNAT stage but failed to convert the destination, to avoid\n- loop.\n-

    \n-\n-

    \n- For IPv6 NAT entries, same flows are added, but using the register\n- xxreg0 and field ip6 for the match.\n-

    \n-
    • \n-\n-
  • \n-

    \n- If the router datapath runs a port with redirect-type\n- set to bridged, for each distributed NAT rule with IP\n- A in the\n- column\n- and logical port P in the\n- column\n- of table, a priority-90 flow\n- with the match outport == Q && ip.src ===\n- A && is_chassis_resident(P),\n- where Q is the distributed logical router port and\n- action get_arp(outport, reg0); next; for IPv4 and\n- get_nd(outport, xxreg0); next; for IPv6.\n-

    \n-
    • \n-\n-
  • \n-

    \n- Traffic with IP destination an address owned by the router should be\n- dropped. Such traffic is normally dropped in ingress table\n- IP Input except for IPs that are also shared with SNAT\n- rules. However, if there was no unSNAT operation that happened\n- successfully until this point in the pipeline and the destination IP\n- of the packet is still a router owned IP, the packets can be safely\n- dropped.\n-

    \n-\n-

    \n- A priority-2 logical flow with match ip4.dst = {..}\n- matches on traffic destined to router owned IPv4 addresses which are\n- also SNAT IPs. This flow has action drop;.\n-

    \n-\n-

    \n- A priority-2 logical flow with match ip6.dst = {..}\n- matches on traffic destined to router owned IPv6 addresses which are\n- also SNAT IPs. This flow has action drop;.\n-

    \n-\n-

    \n- A priority-0 logical that flow matches all packets not already\n- handled (match 1) and drops them\n- (action drop;).\n-

    \n-
    • \n-\n-
  • \n-

    \n- Dynamic MAC bindings. These flows resolve MAC-to-IP bindings\n- that have become known dynamically through ARP or neighbor\n- discovery. (The ingress table ARP Request will\n- issue an ARP or neighbor solicitation request for cases where\n- the binding is not yet known.)\n-

    \n-\n-

    \n- A priority-0 logical flow with match ip4 has actions\n- get_arp(outport, reg0); next;.\n-

    \n-\n-

    \n- A priority-0 logical flow with match ip6 has actions\n- get_nd(outport, xxreg0); next;.\n-

    \n-
    • \n-\n-
  • \n-

    \n- For a distributed gateway LRP with redirect-type\n- set to bridged, a priority-50 flow will match\n- outport == \"ROUTER_PORT\" and !is_chassis_resident\n- (\"cr-ROUTER_PORT\") has actions eth.dst = E;\n- next;, where E is the ethernet address of the\n- logical router port.\n-

    \n-
    • \n-\n-
\n-\n-

Ingress Table 23: Check packet length

\n-\n-

\n- For distributed logical routers or gateway routers with gateway\n- port configured with options:gateway_mtu to a valid\n- integer value, this table adds a priority-50 logical flow with\n- the match outport == GW_PORT where\n- GW_PORT is the gateway router port and applies the\n- actions check_pkt_larger and ct_state_save\n- and then advances the packet to the next table.\n-

\n-\n- 
\n-REGBIT_PKT_LARGER = check_pkt_larger(L);\n-REG_CT_STATE = ct_state_save();\n-next;\n-
\n-\n-

\n- where L is the packet length to check for. If the packet\n- is larger than L, it stores 1 in the register bit\n- REGBIT_PKT_LARGER. The value of\n- L is taken from column of\n- row.\n-

\n-\n-

\n- If the port is also configured with\n- options:gateway_mtu_bypass then another flow is\n- added, with priority-55, to bypass the check_pkt_larger\n- flow.\n-

\n-\n-

\n- This table adds one priority-0 fallback flow that matches all packets\n- and advances to the next table.\n-

\n-\n-

Ingress Table 24: Handle larger packets

\n-\n-

\n- For distributed logical routers or gateway routers with gateway port\n- configured with options:gateway_mtu to a valid integer\n- value, this table adds the following priority-150 logical flow for each\n- logical router port with the match inport == LRP\n- && outport == GW_PORT && REGBIT_PKT_LARGER\n- && !REGBIT_EGRESS_LOOPBACK, where LRP is the\n- logical router port and GW_PORT is the gateway port and\n- applies the following action for ipv4 and ipv6 respectively:\n-

\n-\n- 
\n-icmp4 {\n-    icmp4.type = 3; /* Destination Unreachable. */\n-    icmp4.code = 4;  /* Frag Needed and DF was Set. */\n-    icmp4.frag_mtu = M;\n-    eth.dst = E;\n-    ip4.dst = ip4.src;\n-    ip4.src = I;\n-    ip.ttl = 255;\n-    REGBIT_EGRESS_LOOPBACK = 1;\n-    REGBIT_PKT_LARGER = 0;\n-    next(pipeline=ingress, table=0);\n-};\n-\n-icmp6 {\n-    icmp6.type = 2;\n-    icmp6.code = 0;\n-    icmp6.frag_mtu = M;\n-    eth.dst = E;\n-    ip6.dst = ip6.src;\n-    ip6.src = I;\n-    ip.ttl = 255;\n-    REGBIT_EGRESS_LOOPBACK = 1;\n-    REGBIT_PKT_LARGER = 0;\n-    next(pipeline=ingress, table=0);\n-};\n-
\n-\n-
    \n-
  • \n- Where M is the (fragment MTU - 58) whose value is taken from\n- column of\n- row.\n-
    • \n-\n-
  • \n- E is the Ethernet address of the logical router port.\n-
    • \n-\n-
  • \n- I is the IPv4/IPv6 address of the logical router port.\n-
    • \n-
\n-\n-

\n- This table adds one priority-0 fallback flow that matches all packets\n- and advances to the next table.\n-

\n-\n-

Ingress Table 25: Gateway Redirect

\n-\n-

\n- For distributed logical routers where one or more of the logical router\n- ports specifies a gateway chassis, this table redirects\n- certain packets to the distributed gateway port instances on the\n- gateway chassises. This table has the following flows:\n-

\n-\n-
    \n-
  • \n- For all the configured load balancing rules that include an IPv4\n- address VIP, and a list of IPv4 backend addresses\n- B0, B1 .. Bn defined for the\n- VIP a priority-200 flow is added that matches \n- ip4 && (ip4.src == B0 || ip4.src == B1\n- || ... || ip4.src == Bn) with an action \n- outport = CR; next; where CR is the\n- chassisredirect port representing the instance of the\n- logical router distributed gateway port on the gateway chassis.\n- If the backend IPv4 address Bx is also configured with\n- L4 port PORT of protocol P, then the match\n- also includes P.src == PORT.\n- Similar flows are added for IPv6.\n-
    • \n-\n-
  • \n- For each NAT rule in the OVN Northbound database that can\n- be handled in a distributed manner, a priority-100 logical\n- flow with match ip4.src == B &&\n- outport == GW &&\n- is_chassis_resident(P), where GW is\n- the distributed gateway port specified in the\n- NAT rule and P is the NAT logical port. IP traffic\n- matching the above rule will be managed locally setting\n- reg1 to C and\n- eth.src to D, where C is NAT\n- external ip and D is NAT external mac.\n-
    • \n-\n-
  • \n- For each dnat_and_snat NAT rule with\n- stateless=true and allowed_ext_ips\n- configured, a priority-75 flow is programmed with match\n- ip4.dst == B and action\n- outport = CR; next; where B\n- is the NAT rule external IP and CR is the\n- chassisredirect port representing the instance\n- of the logical router distributed gateway port on the\n- gateway chassis. Moreover a priority-70 flow is programmed\n- with same match and action drop;.\n- For each dnat_and_snat NAT rule with\n- stateless=true and exempted_ext_ips\n- configured, a priority-75 flow is programmed with match\n- ip4.dst == B and action\n- drop; where B is the NAT rule\n- external IP.\n- A similar flow is added for IPv6 traffic.\n-
    • \n-\n-
  • \n- For each NAT rule in the OVN Northbound database that can\n- be handled in a distributed manner, a priority-80 logical flow\n- with drop action if the NAT logical port is a virtual port not\n- claimed by any chassis yet.\n-
    • \n-\n-
  • \n- A priority-50 logical flow with match\n- outport == GW has actions\n- outport = CR; next;, where\n- GW is the logical router distributed gateway\n- port and CR is the chassisredirect\n- port representing the instance of the logical router\n- distributed gateway port on the\n- gateway chassis.\n-
    • \n-\n-
  • \n- A priority-0 logical flow with match 1 has actions\n- next;.\n-
    • \n-
\n-\n-

Ingress Table 26: Network ID

\n-\n-

\n- This table contains flows that set flags.network_id for\n- IP packets:\n-

\n-\n-
    \n-
  • \n-

    \n- A priority-110 flow with match:\n-

      \n-
    • \n- for IPv4: outport == P &&\n- REG_NEXT_HOP_IPV4 == I/C &&\n- ip4\n-
      • \n-
    • \n- for IPv6: outport == P &&\n- REG_NEXT_HOP_IPV6 == I/C &&\n- ip6\n-
      • \n-
    \n-

    \n-\n-

    \n- and actions flags.network_id = N; next;.\n- Where P is the outport, I/C is a\n- network CIDR of the port P, and N is the\n- network id (index). There is one flow like this per router port's\n- network.\n-

    \n-\n-

    \n- flags.network_id is 4 bits, and thus only 16 networks can\n- be indexed. If the number of networks is greater than 16, networks 17\n- and up will have the actions flags.network_id = 0; next;\n- and only the lexicographically first IP will be considered for SNAT for\n- those networks.\n-

    \n-
    • \n-\n-
  • \n- A lower priority-105 flow with match 1 and actions\n- flags.network_id = 0; next;. This is for the case that the\n- next-hop doesn't belong to any of the port networks, so\n- flags.network_id should be set to zero.\n-
    • \n-\n-
  • \n- Catch-all: A priority-0 flow with match 1 has\n- actions next;.\n-
    • \n-
\n-\n-

Ingress Table 27: ARP Request

\n-\n-

\n- In the common case where the Ethernet destination has been resolved, this\n- table advances the packet to the next table. Otherwise, it composes and\n- sends an ARP or IPv6 Neighbor Solicitation request. It holds the\n- following flows:\n-

\n-\n-
    \n-
  • \n-

    \n- Unknown MAC address. A priority-100 flow for IPv4 packets with match\n- eth.dst == 00:00:00:00:00:00 has the following actions:\n-

    \n-\n- 
    \n-arp {\n-    eth.dst = ff:ff:ff:ff:ff:ff;\n-    arp.spa = reg1;\n-    arp.tpa = reg0;\n-    arp.op = 1;  /* ARP request. */\n-    output;\n-};\n-
    \n-\n-

    \n- Unknown MAC address. For each IPv6 static route associated with the\n- router with the nexthop IP: G, a priority-200 flow\n- for IPv6 packets with match\n- eth.dst == 00:00:00:00:00:00 &&\n- xxreg0 == G\n- with the following actions is added:\n-

    \n-\n- 
    \n-nd_ns {\n-    eth.dst = E;\n-    ip6.dst = I\n-    nd.target = G;\n-    output;\n-};\n-
    \n-\n-

    \n- Where E is the multicast mac derived from the Gateway IP,\n- I is the solicited-node multicast address corresponding\n- to the target address G.\n-

    \n-\n-

    \n- Unknown MAC address. A priority-100 flow for IPv6 packets with match\n- eth.dst == 00:00:00:00:00:00 has the following actions:\n-

    \n-\n- 
    \n-nd_ns {\n-    nd.target = xxreg0;\n-    output;\n-};\n-
    \n-\n-

    \n- (Ingress table IP Routing initialized reg1\n- with the IP address owned by outport and\n- (xx)reg0 with the next-hop IP address)\n-

    \n-\n-

    \n- The IP packet that triggers the ARP/IPv6 NS request is dropped.\n-

    \n-
    • \n-\n-
  • \n- Known MAC address. A priority-0 flow with match 1 has\n- actions next;.\n-
    • \n-
\n-\n-

Ingress Table 28: ECMP symmetric reply processing for egress

\n-

\n- This table contains logical flows that commit IP traffic forwarded by\n- ECMP symmetric reply static routes in the \"route direction\", that is,\n- for sessions initiated from behind such routes. These flows can be hit\n- only on gateway routers, the only type of routers that supports ECMP\n- symmetric reply routes. As the egress port of the traffic needs to be\n- stored in conntrack for these sessions, one logical flow is added for\n- each logical router port.\n-

\n-\n-

Egress Table 0: Check DNAT local

\n-\n-

\n- This table checks if the packet needs to be DNATed in the router ingress\n- table lr_in_dnat after it is SNATed and looped back\n- to the ingress pipeline. This check is done only for routers configured\n- with distributed gateway ports and NAT entries. This check is done\n- so that SNAT and DNAT is done in different zones instead of a common\n- zone.\n-

\n-\n-
    \n-
  • \n- A priority-0 logical flow with match 1 has actions\n- REGBIT_DST_NAT_IP_LOCAL = 0; next;.\n-
    • \n-
\n-\n-

Egress Table 1: UNDNAT

\n-\n-

\n- This is for already established connections' reverse traffic.\n- i.e., DNAT has already been done in ingress pipeline and now the\n- packet has entered the egress pipeline as part of a reply. This traffic\n- is unDNATed here.\n-

\n-\n-
    \n-
  • \n- A priority-0 logical flow with match 1 has actions\n- next;.\n-
    • \n-
\n-\n-

Egress Table 1: UNDNAT on Gateway Routers

\n-\n-
    \n-
  • \n- For IPv6 Neighbor Discovery or Router Solicitation/Advertisement\n- traffic, a priority-100 flow with action next;.\n-
    • \n-\n-
  • \n- For all IP packets, a priority-50 flow with an action\n- flags.loopback = 1; ct_dnat;.\n-
    • \n-
\n-\n-

Egress Table 1: UNDNAT on Distributed Routers

\n-
    \n-
  • \n-

    \n- For all the configured load balancing rules for a router with gateway\n- port in OVN_Northbound database that includes an IPv4\n- address VIP, for every backend IPv4 address B\n- defined for the VIP a priority-120 flow is programmed on\n- gateway chassis that matches\n- ip && ip4.src == B &&\n- outport == GW, where GW is the logical\n- router gateway port with an action ct_dnat;.\n- If the backend IPv4 address B is also configured with\n- L4 port PORT of protocol P, then the\n- match also includes P.src == PORT. These\n- flows are not added for load balancers with IPv6 VIPs.\n-

    \n-\n-

    \n- If the router is configured to force SNAT any load-balanced packets,\n- above action will be replaced by\n- flags.force_snat_for_lb = 1; ct_dnat;.\n-

    \n-
    • \n-\n-
  • \n-

    \n- For each configuration in the OVN Northbound database that asks\n- to change the destination IP address of a packet from an IP\n- address of A to B, a priority-100 flow\n- matches ip && ip4.src == B\n- && outport == GW, where GW\n- is the logical router gateway port, with an action\n- ct_dnat;. If the NAT rule is of type\n- dnat_and_snat and has stateless=true in the\n- options, then the action would be next;.\n-

    \n-\n-

    \n- If the NAT rule cannot be handled in a distributed manner, then\n- the priority-100 flow above is only programmed on the\n- gateway chassis with the action ct_dnat.\n-

    \n-\n-

    \n- If the NAT rule can be handled in a distributed manner, then\n- there is an additional action\n- eth.src = EA;, where EA\n- is the ethernet address associated with the IP address\n- A in the NAT rule. This allows upstream MAC\n- learning to point to the correct chassis.\n-

    \n-
    • \n-\n-
\n-\n-

Egress Table 2: Post UNDNAT

\n-\n-

\n-

    \n-
  • \n- A priority-70 logical flow is added that initiates CT state for\n- traffic that is configured to be SNATed on Distributed routers.\n- This allows the next table, lr_out_snat, to\n- effectively match on various CT states.\n-
    • \n-\n-
  • \n- A priority-50 logical flow is added that commits any untracked flows\n- from the previous table lr_out_undnat for Gateway\n- routers. This flow matches on ct.new && ip\n- with action ct_commit { } ; next; .\n-
    • \n-\n-
  • \n- If the options:ct-commit-all is set to true\n- the following flows are configured matching on ip &&\n- (!ct.trk || !ct.rpl) && flags.unsnat_not_tracked == 1\n- with an action ct_next(snat); and ip &&\n- flags.unsnat_new == 1 with an action next;. There\n- is extra match when there is configured DGP\n- outport == DGP && is_chassis_resident(CHASSIS).\n-
    • \n-\n-
  • \n- A priority-0 logical flow with match 1 has actions\n- next;.\n-
    • \n-\n-
\n-

\n-\n-

Egress Table 3: SNAT

\n-\n-

\n- Packets that are configured to be SNATed get their source IP address\n- changed based on the configuration in the OVN Northbound database.\n-

\n-\n-
    \n-
  • \n- A priority-120 flow to advance the IPv6 Neighbor solicitation packet\n- to next table to skip SNAT. In the case where ovn-controller injects\n- an IPv6 Neighbor Solicitation packet (for nd_ns action)\n- we don't want the packet to go through conntrack.\n-
    • \n-
\n-\n-

Egress Table 3: SNAT on Gateway Routers

\n-\n-
    \n-
  • \n-

    \n- If the Gateway router in the OVN Northbound database has been\n- configured to force SNAT a packet (that has been previously DNATted)\n- to B, a priority-100 flow matches\n- flags.force_snat_for_dnat == 1 && ip with an\n- action ct_snat(B);.\n-

    \n-
    • \n-\n-
  • \n-

    \n- If a load balancer configured to skip snat has been applied to\n- the Gateway router pipeline, a priority-120 flow matches\n- flags.skip_snat_for_lb == 1 && ip with an\n- action next;.\n-

    \n-
    • \n-\n-
  • \n-

    \n- If the Gateway router in the OVN Northbound database has been\n- configured to force SNAT a packet (that has been previously\n- load-balanced) using router IP (i.e :lb_force_snat_ip=router_ip), then for\n- each logical router port P attached to the Gateway\n- router, and for each network configured for this port, a priority-110\n- flow matches flags.force_snat_for_lb == 1 &&\n- ip4 &&\n- flags.network_id == N &&\n- outport == P, where N is the\n- network index, with an action ct_snat(R);\n- where R is the IP configured on the router port. A similar\n- flow is created for IPv6, with ip6 instead of\n- ip4. N, the network index, will be 0 for\n- networks 17 and up.\n-

    \n-\n-

    \n- If the logical router port P is configured with multiple\n- IPv4 and multiple IPv6 addresses, the IPv4 and IPv6 address within\n- the same network as the next-hop will be chosen as R for\n- SNAT. However, if there are more than 16 networks configured, the\n- lexicographically first IP will be considered for SNAT for networks\n- 17 and up.\n-

    \n-
    • \n-
  • \n-

    \n- A priority-105 flow matches the old behavior for if northd is\n- upgraded before controller and flags.network_id is not\n- recognized. It is only added if there's at least one network\n- configured (excluding LLA for IPv6). It matches on:\n- flags.force_snat_for_lb == 1 && ip4\n- && outport == P, with action:\n- ct_snat(R).\n- R is the lexicographically first IP address configured.\n- There is a similar flow for IPv6 with ip6 instead of\n- ip4.\n-

    \n-
    • \n-\n-
  • \n-

    \n- If the Gateway router in the OVN Northbound database has been\n- configured to force SNAT a packet (that has been previously\n- load-balanced) to B, a priority-100 flow matches\n- flags.force_snat_for_lb == 1 && ip with an\n- action ct_snat(B);.\n-

    \n-
    • \n-\n-
  • \n-

    \n- For each configuration in the OVN Northbound database, that asks\n- to change the source IP address of a packet from an IP address of\n- A or to change the source IP address of a packet that\n- belongs to network A to B, a flow matches\n- ip && ip4.src == A &&\n- (!ct.trk || !ct.rpl) with an action\n- ct_snat(B);. The priority of the flow\n- is calculated based on the mask of A, with matches\n- having larger masks getting higher priorities. If the NAT rule is\n- of type dnat_and_snat and has stateless=true in the\n- options, then the action would be ip4/6.src=\n- (B).\n-

    \n-\n-

    \n- For each configuration in the OVN Northbound database, that asks\n- to change the source IP address of a packet from an IP address of\n- A or to change the source IP address of a packet that\n- belongs to network A to B, match M\n- and priority P, a flow matches ip &&\n- ip4.src == A && (!ct.trk || !ct.rpl) &&\n- (M) with an action ct_snat(B);\n- . The priority of the flow is calculated based as\n- 300 + P. If the NAT rule is of type\n- dnat_and_snat and has stateless=true in the options,\n- then the action would be ip4/6.src=(B).\n-

    \n-
    • \n-\n-
  • \n-

    \n- If the NAT rule has allowed_ext_ips configured, then\n- there is an additional match ip4.dst == allowed_ext_ips\n- . Similarly, for IPV6, match would be ip6.dst ==\n- allowed_ext_ips.\n-

    \n-
    • \n-\n-
  • \n-

    \n- If the NAT rule has exempted_ext_ips set, then\n- there is an additional flow configured at the priority + 1 of\n- corresponding NAT rule. The flow matches if destination ip\n- is an exempted_ext_ip and the action is next;\n- . This flow is used to bypass the ct_snat action for a packet\n- which is destinted to exempted_ext_ips.\n-

    \n-
    • \n-\n-
  • \n-

    \n- If the options:ct-commit-all is set to true\n- the following two flows are configured matching on ip\n- && (!ct.trk || !ct.rpl) &&\n- flags.unsnat_new == 1 and\n- ip && ct.new && flags.unsnat_not_tracked == 1\n- both with an action ct_commit_to_zone(snat);.\n-

    \n-
    • \n-\n-
  • \n-

    \n- A priority-0 logical flow with match 1 has actions\n- next;.\n-

    \n-
    • \n-
\n-\n-

Egress Table 3: SNAT on Distributed Routers

\n-\n-
    \n-
  • \n-

    \n- For each configuration in the OVN Northbound database, that asks\n- to change the source IP address of a packet from an IP address of\n- A or to change the source IP address of a packet that\n- belongs to network A to B, two flows are\n- added. The priority P of these flows are calculated\n- based on the mask of A, with matches having larger\n- masks getting higher priorities.\n-

    \n-\n-

    \n- If the NAT rule cannot be handled in a distributed manner, then\n- the below flows are only programmed on the gateway chassis increasing\n- flow priority by 128 in order to be run first.\n-

    \n-\n-
      \n-
    • \n- The first flow is added with the calculated priority P\n- and match ip && ip4.src == A &&\n- outport == GW, where GW is the\n- logical router gateway port, with an action\n- ct_snat(B); to SNATed in the\n- common zone. If the NAT rule is of type dnat_and_snat and has\n- stateless=true in the options, then the action\n- would be ip4/6.src=(B).\n-
      • \n-
    \n-\n-

    \n- If the NAT rule can be handled in a distributed manner, then\n- there is an additional action (for both the flows)\n- eth.src = EA;, where EA\n- is the ethernet address associated with the IP address\n- A in the NAT rule. This allows upstream MAC\n- learning to point to the correct chassis.\n-

    \n-\n-

    \n- If the NAT rule has allowed_ext_ips configured, then\n- there is an additional match ip4.dst == allowed_ext_ips\n- . Similarly, for IPV6, match would be ip6.dst ==\n- allowed_ext_ips.\n-

    \n-\n-

    \n- If the NAT rule has exempted_ext_ips set, then\n- there is an additional flow configured at the priority\n- P + 2 of\n- corresponding NAT rule. The flow matches if destination ip\n- is an exempted_ext_ip and the action is next;\n- . This flow is used to bypass the ct_snat action for a flow\n- which is destinted to exempted_ext_ips.\n-

    \n-\n-
    • \n-\n-
  • \n- An additional flow is added for traffic that goes in opposite\n- direction (i.e. it enters a network with configured SNAT). Where the\n- flow above matched on ip4.src == A && outport\n- == GW, this flow matches on ip4.dst ==\n- A && inport == GW. A CT state is\n- initiated for this traffic so that the following table, \n- lr_out_post_snat, can identify whether the traffic flow was\n- initiated from the internal or external network.\n-
    • \n-\n-
  • \n-

    \n- If the options:ct-commit-all is set to true\n- the following two flows are configured matching on ip\n- && (!ct.trk || !ct.rpl) && flags.unsnat_new == 1\n- && outport == DGP && is_chassis_resident(CHASSIS)\n- and ip && ct.new &&\n- flags.unsnat_not_tracked == 1 && outport == DGP &&\n- is_chassis_resident(CHASSIS)both with an action\n- ct_commit_to_zone(snat);.\n-

    \n-
    • \n-\n-
  • \n- A priority-0 logical flow with match 1 has actions\n- next;.\n-
    • \n-
\n-\n-

Egress Table 4: Post SNAT

\n-\n-

\n- Packets reaching this table are processed according to the flows below:\n-

    \n-
  • \n- Traffic that goes directly into a network configured with SNAT on\n- Distributed routers, and was initiated from an external network (i.e.\n- it matches ct.new), is committed to the SNAT CT zone.\n- This ensures that replies returning from the SNATed network do not\n- have their source address translated. For details about match rules\n- and priority see section \"Egress Table 3: SNAT on Distributed\n- Routers\".\n-
    • \n-\n-
  • \n- A priority-0 logical flow that matches all packets not already\n- handled (match 1) and action next;.\n-
    • \n-
\n-

\n-\n-

Egress Table 5: Egress Loopback

\n-\n-

\n- For distributed logical routers where one of the logical router\n- ports specifies a gateway chassis.\n-

\n-\n-

\n- While UNDNAT and SNAT processing have already occurred by this\n- point, this traffic needs to be forced through egress loopback on\n- this distributed gateway port instance, in order for UNSNAT and\n- DNAT processing to be applied, and also for IP routing and ARP\n- resolution after all of the NAT processing, so that the packet can\n- be forwarded to the destination.\n-

\n-\n

\n- This table has the following flows:\n+ For a detailed description of the logical flow tables that\n+ ovn-northd populates in the\n+ OVN_Southbound database, including logical switch\n+ and router datapath pipelines and drop sampling behavior, see\n+ ovn-logical-flows(7).\n

\n \n-
    \n-
  • \n-

    \n- For each NAT rule in the OVN Northbound database on a\n- distributed router, a priority-100 logical flow with match\n- ip4.dst == E &&\n- outport == GW &&\n- is_chassis_resident(P), where E is the\n- external IP address specified in the NAT rule, GW\n- is the distributed gateway port corresponding to the NAT rule\n- (specified or inferred).\n- For dnat_and_snat NAT rule, P is the logical port\n- specified in the NAT rule.\n- If column of\n- table is NOT set, then\n- P is the chassisredirect port of\n- GW with the following actions:\n-

    \n-\n- 
    \n-clone {\n-    ct_clear;\n-    inport = outport;\n-    outport = \"\";\n-    flags = 0;\n-    flags.loopback = 1;\n-    reg0 = 0;\n-    reg1 = 0;\n-    ...\n-    reg9 = 0;\n-    REGBIT_EGRESS_LOOPBACK = 1;\n-    next(pipeline=ingress, table=0);\n-};\n-
    \n-\n-

    \n- flags.loopback is set since in_port is unchanged\n- and the packet may return back to that port after NAT processing.\n- REGBIT_EGRESS_LOOPBACK is set to indicate that\n- egress loopback has occurred, in order to skip the source IP\n- address check against the router address.\n-

    \n-
    • \n-\n-
  • \n- A priority-0 logical flow with match 1 has actions\n- next;.\n-
    • \n-
\n-\n-

Egress Table 6: Delivery

\n-\n-

\n- Packets that reach this table are ready for delivery. It contains:\n-

    \n-
  • \n- Priority-110 logical flows that match IP multicast packets on each\n- enabled logical router port and modify the Ethernet source address\n- of the packets to the Ethernet address of the port and then execute\n- action output;.\n-
    • \n-
  • \n- Priority-100 logical flows that match packets on each enabled\n- logical router port, with action output;.\n-
    • \n-
  • \n- A priority-0 logical flow that matches all packets not already\n- handled (match 1) and drops them\n- (action drop;).\n-
    • \n-
\n-

\n-\n-

Drop sampling

\n-\n-

\n- As described in the previous section, there are several places where\n- ovn-northd might decided to drop a packet by explicitly creating a\n- Logical_Flow with the drop; action.\n-

\n-\n-

\n- When debug drop-sampling has been cofigured in the OVN Northbound\n- database, the ovn-northd will replace all the drop;\n- actions with a sample(priority=65535, collector_set=id,\n- obs_domain=obs_id, obs_point=@cookie) action, where:\n-

    \n-
  • \n- id is the value the debug_drop_collector_set\n- option configured in the OVN Northbound.\n-
    • \n-
  • \n- obs_id has it's 8 most significant bits equal to the value\n- of the debug_drop_domain_id option in the OVN Northbound\n- and it's 24 least significant bits equal to the datapath's tunnel key.\n-
    • \n-
\n-

\n \n \n","prefixes":["ovs-dev","3/5"]}