Add RST cross-reference labels to all section headings and convert inline references to other tables into :ref: links so the HTML output has navigable hyperlinks between sections. Reflow all prose to 80 columns.
Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]> Signed-off-by: Mark Michelson <[email protected]> --- Documentation/ref/ovn-logical-flows.7.rst | 438 ++++++++++++++++------ 1 file changed, 314 insertions(+), 124 deletions(-) diff --git a/Documentation/ref/ovn-logical-flows.7.rst b/Documentation/ref/ovn-logical-flows.7.rst index c46966ca5..b567e21c9 100644 --- a/Documentation/ref/ovn-logical-flows.7.rst +++ b/Documentation/ref/ovn-logical-flows.7.rst @@ -9,9 +9,13 @@ This document describes the logical flow tables that ``ovn-northd``\(8) populates in the ``OVN_Southbound`` database. It covers both logical switch and logical router datapath pipelines, as well as drop sampling behavior. +.. _ls-datapaths: + Logical Switch Datapaths ------------------------ +.. _ls-in-0: + Ingress Table 0: Admission Control and Ingress Port Security check ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -63,6 +67,8 @@ Ingress table 0 contains these logical flows: applies the port security rules defined in the ``port_security`` column of ``Logical_Switch_Port`` table. +.. _ls-in-1: + Ingress Table 1: Ingress Port Security - Apply ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -102,6 +108,8 @@ Ingress table 1 contains these logical flows: chassis with distributed NAT entries. Priority 70: Drops ``REGBIT_EXT_ARP`` packets on non-gateway chassis (complements the priority 75 flow). +.. _ls-in-2: + Ingress Table 2: Mirror ~~~~~~~~~~~~~~~~~~~~~~~~ @@ -119,6 +127,8 @@ Overlay remote mirror table contains the following logical flows: switch ports, matches all incoming packets that match rules and clones the packet and sends cloned packet to mirror target port. +.. _ls-in-3: + Ingress Table 3: Lookup MAC address learning table ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -144,6 +154,8 @@ learning. - One priority-0 fallback flow that matches all packets and advances to the next table. +.. _ls-in-4: + Ingress Table 4: Learn MAC of 'unknown' ports. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -165,20 +177,22 @@ true if (port, mac) is found or if a mac is found for a port of type vif. - One priority-0 fallback flow that matches all packets and advances to the next table. +.. _ls-in-5: + Ingress Table 5: ``from-lport`` Pre-ACLs ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This table prepares flows for possible stateful ACL processing in ingress table -``ACLs``. It contains a priority-0 flow that simply moves traffic to the next -table. If stateful ACLs are used in the logical datapath, a priority-100 flow -is added that sets a hint (with ``reg0[0] = 1; next;``) for table ``Pre- -stateful`` to send IP packets to the connection tracker before eventually -advancing to ingress table ``ACLs``. If special ports such as route ports or -localnet ports can't use ct(), a priority-110 flow is added to skip over -stateful ACLs. This priority-110 flow is not addd for router ports if the -option enable_router_port_acl is set to true in -``options:enable_router_port_acl`` column of ``Logical_Switch_Port``. -Multicast, IPv6 Neighbor Discovery and MLD traffic also skips stateful ACLs. For +:ref:`ACLs <ls-in-9>`. It contains a priority-0 flow that simply moves traffic +to the next table. If stateful ACLs are used in the logical datapath, a +priority-100 flow is added that sets a hint (with ``reg0[0] = 1; next;``) for +table :ref:`Pre-stateful <ls-in-7>` to send IP packets to the connection tracker +before eventually advancing to ingress table :ref:`ACLs <ls-in-9>`. If special +ports such as route ports or localnet ports can't use ct(), a priority-110 flow +is added to skip over stateful ACLs. This priority-110 flow is not addd for +router ports if the option enable_router_port_acl is set to true in +``options:enable_router_port_acl`` column of ``Logical_Switch_Port``. Multicast, +IPv6 Neighbor Discovery and MLD traffic also skips stateful ACLs. For "allow-stateless" ACLs, a flow is added to bypass setting the hint for connection tracker processing when there are stateful ACLs or LB rules; ``REGBIT_ACL_STATELESS`` is set for traffic matching stateless ACL flows. @@ -188,27 +202,29 @@ logical switch datapaths to move traffic to the next table. Where *E* is the service monitor mac defined in the ``options:svc_monitor_mac`` column of ``NB_Global`` table. +.. _ls-in-6: + Ingress Table 6: Pre-LB ~~~~~~~~~~~~~~~~~~~~~~~~ This table prepares flows for possible stateful load balancing processing in -ingress table ``LB`` and ``Stateful``. It contains a priority-0 flow that -simply moves traffic to the next table. Moreover it contains two priority-110 -flows to move multicast, IPv6 Neighbor Discovery and MLD traffic to the next -table. It also contains two priority-110 flows to move stateless traffic, i.e -traffic for which ``REGBIT_ACL_STATELESS`` is set, to the next table. If load -balancing rules with virtual IP addresses (and ports) are configured in -``OVN_Northbound`` database for a logical switch datapath, a priority-100 flow -is added with the match ``ip`` to match on IP packets and sets the action -``reg0[2] = 1; next;`` to act as a hint for table ``Pre-stateful`` to send IP -packets to the connection tracker for packet de-fragmentation (and to possibly -do DNAT for already established load balanced traffic) before eventually -advancing to ingress table ``Stateful``. If controller_event has been enabled -and load balancing rules with empty backends have been added in -``OVN_Northbound``, a 130 flow is added to trigger ovn-controller events -whenever the chassis receives a packet for that particular VIP. If ``event-elb`` -meter has been previously created, it will be associated to the empty_lb logical -flow +ingress table :ref:`LB <ls-in-15>` and :ref:`Stateful <ls-in-24>`. It contains +a priority-0 flow that simply moves traffic to the next table. Moreover it +contains two priority-110 flows to move multicast, IPv6 Neighbor Discovery and +MLD traffic to the next table. It also contains two priority-110 flows to move +stateless traffic, i.e traffic for which ``REGBIT_ACL_STATELESS`` is set, to the +next table. If load balancing rules with virtual IP addresses (and ports) are +configured in ``OVN_Northbound`` database for a logical switch datapath, a +priority-100 flow is added with the match ``ip`` to match on IP packets and sets +the action ``reg0[2] = 1; next;`` to act as a hint for table :ref:`Pre-stateful +<ls-in-7>` to send IP packets to the connection tracker for packet +de-fragmentation (and to possibly do DNAT for already established load balanced +traffic) before eventually advancing to ingress table :ref:`Stateful +<ls-in-24>`. If controller_event has been enabled and load balancing rules with +empty backends have been added in ``OVN_Northbound``, a 130 flow is added to +trigger ovn-controller events whenever the chassis receives a packet for that +particular VIP. If ``event-elb`` meter has been previously created, it will be +associated to the empty_lb logical flow Prior to ``OVN 20.09`` we were setting the ``reg0[0] = 1`` only if the IP destination matches the load balancer VIP. However this had few issues cases @@ -245,6 +261,8 @@ peer of a logical router port. This flow is added to skip the connection tracking of packets which enter from logical router datapath to logical switch datapath. +.. _ls-in-7: + Ingress Table 7: Pre-stateful ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -270,6 +288,8 @@ It contains a priority-0 flow that simply moves traffic to the next table. provided by the previous tables (with a match for ``reg0[0] == 1``) by using the ``ct_next;`` action. +.. _ls-in-8: + Ingress Table 8: ``from-lport`` ACL hints ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -321,6 +341,8 @@ The table contains the following flows: session that has not been marked as blocked. This flow sets ``reg0[10]`` and then advances to the next table. +.. _ls-in-9: + Ingress table 9: ``from-lport`` ACL evaluation before LB ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -424,8 +446,8 @@ configured, the following flows will also be added: accomplishes the same thing but also logs the traffic. - The priority-65532 flows that allow response and related traffic, also set - ``reg8[21] = ct_label.nf``, which gets checked in the ``Network Function`` - table. + ``reg8[21] = ct_label.nf``, which gets checked in the :ref:`Network Function + <ls-in-25>` table. - A priority-65532 flow that sets the allow bit for any traffic that is considered related to a committed flow in the connection tracker (e.g., an @@ -453,6 +475,8 @@ following flow will also be added: monitor mac defined in the ``options:svc_monitor_mac`` column of ``NB_Global`` table. +.. _ls-in-10: + Ingress Table 10: ``from-lport`` ACL sampling ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -478,6 +502,8 @@ sampling enabled. pipeline (in the ingress pipeline for ACLs applied in the egress direction and in the egress pipeline for ACLs applied in the ingress direction). +.. _ls-in-11: + Ingress Table 11: ``from-lport`` ACL action ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -503,6 +529,8 @@ allow, drop, and reject bits that may have been set in the previous table. counter is incremented by one and the packet is sent back to the previous table for re-evaluation. +.. _ls-in-12: + Ingress Table 12: ``from-lport`` QoS ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -517,6 +545,8 @@ for the ``from-lport`` direction. - One priority-0 fallback flow that matches all packets and advances to the next table. +.. _ls-in-13: + Ingress Table 13: Connection Tracking Field Extraction ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -530,6 +560,8 @@ subsequent load balancing stages. - A priority-0 flow matches all packets and advances to the next table. +.. _ls-in-14: + Ingress Table 14: Load balancing affinity check ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -547,6 +579,8 @@ Load balancing affinity check table contains the following logical flows: - A priority 0 flow is added which matches on all packets and applies the action ``next;``. +.. _ls-in-15: + Ingress Table 15: LB ~~~~~~~~~~~~~~~~~~~~~ @@ -587,7 +621,7 @@ Ingress Table 15: LB == VIP``. The action on this flow is ``ct_lb_mark(args)``, where *args* contains comma separated IP addresses of the same address family as *VIP*. For IPv4 traffic the flow also loads the original destination IP and transport - port in registers ``reg1`` and ``reg2``. For IPv6 traffic the flow also loads + port in registers ``reg1`` and ``reg2``. For IPv6 traffic the flow also loads the original destination IP and transport port in registers ``xxreg1`` and ``reg2``. The above flow is created even if the load balancer is attached to a logical router connected to the current logical switch and the @@ -600,6 +634,8 @@ Ingress Table 15: LB received for this load-balancer. Please note using ``--reject`` option will disable empty_lb SB controller event for this load balancer. +.. _ls-in-16: + Ingress Table 16: Load balancing affinity learn ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -617,6 +653,8 @@ Load balancing affinity learn table contains the following logical flows: - A priority 0 flow is added which matches on all packets and applies the action ``next;``. +.. _ls-in-17: + Ingress Table 17: Pre-Hairpin ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -629,6 +667,8 @@ Ingress Table 17: Pre-Hairpin - A priority-0 flow that simply moves traffic to the next table. +.. _ls-in-18: + Ingress Table 18: Nat-Hairpin ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -651,6 +691,8 @@ Ingress Table 18: Nat-Hairpin - A priority-0 flow that simply moves traffic to the next table. +.. _ls-in-19: + Ingress Table 19: Hairpin ~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -669,14 +711,16 @@ Ingress Table 19: Hairpin - If logical switch has attached logical switch port of *vtep* type, then a priority-1000 flow that matches on ``reg0[14]`` register bit for the traffic received from HW VTEP (ramp) ports. This traffic is passed to ingress table - ls_in_l2_lkup. + :ref:`Destination Lookup <ls-in-32>`. - A priority-1 flow that hairpins traffic matched by non-default flows in the - Pre-Hairpin table. Hairpinning is done at L2, Ethernet addresses are swapped - and the packets are looped back on the input port. + :ref:`Pre-Hairpin <ls-in-17>` table. Hairpinning is done at L2, Ethernet + addresses are swapped and the packets are looped back on the input port. - A priority-0 flow that simply moves traffic to the next table. +.. _ls-in-20: + Ingress table 20: ``from-lport`` ACL evaluation after LB ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -732,6 +776,8 @@ ACL's match. - One priority-0 fallback flow that matches all packets and advances to the next table. +.. _ls-in-21: + Ingress Table 21: ``from-lport`` ACL sampling after LB ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -757,6 +803,8 @@ Logical flows in this table sample traffic matched by ``from-lport`` ACLs pipeline (in the ingress pipeline for ACLs applied in the egress direction and in the egress pipeline for ACLs applied in the ingress direction). +.. _ls-in-22: + Ingress Table 22: ``from-lport`` ACL action after LB ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -782,6 +830,8 @@ allow, drop, and reject bits that may have been set in the previous table. counter is incremented by one and the packet is sent back to the previous table for re-evaluation. +.. _ls-in-23: + Ingress Table 23: Pre Network Function ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -830,6 +880,8 @@ future, this stage will be extended to support network function load balancing. - A priority-0 flow that simply moves traffic to the next table. +.. _ls-in-24: + Ingress Table 24: Stateful ~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -853,6 +905,8 @@ Ingress Table 24: Stateful - A priority-0 flow that simply moves traffic to the next table. +.. _ls-in-25: + Ingress Table 25: Network Function ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -883,7 +937,8 @@ refer to either the parent or child ports as applicable to this logical switch. ``reg5[16..31] = ct_label.tun_if_id``. This is used for tunneling packet to originating host in case of cross host traffic redirection for VLAN subnet. This ct_label field stores the openflow tunnel interface id of the originating - host for this connection and gets populated in egress ``Stateful`` table. + host for this connection and gets populated in egress :ref:`Stateful + <ls-out-12>` table. - For each active network function with *id* that is referenced in a network function group, a priority-99 flow matches ``reg8[21] == 1 && reg8[22] == 1 && @@ -915,6 +970,8 @@ refer to either the parent or child ports as applicable to this logical switch. - One priority-0 fallback flow that matches all packets and advances to the next table. +.. _ls-in-26: + Ingress Table 26: ARP/ND responder ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -1136,6 +1193,8 @@ hit. It contains these logical flows: - One priority-0 fallback flow that matches all packets and advances to the next table. +.. _ls-in-27: + Ingress Table 27: DHCP option processing ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -1169,6 +1228,8 @@ options. This table also adds flows for the logical ports of type ``external``. - A priority-0 flow that matches all packets to advances to table 16. +.. _ls-in-28: + Ingress Table 28: DHCP responses ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -1222,6 +1283,8 @@ previous table. - A priority-0 flow that matches all packets to advances to table 17. +.. _ls-in-29: + Ingress Table 29 DNS Lookup ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -1240,6 +1303,8 @@ IP address(es). other kinds of packets, it just stores 0 into reg0[4]. Either way, it continues to the next table. +.. _ls-in-30: + Ingress Table 30 DNS Responses ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -1263,6 +1328,8 @@ previous table. (This terminates ingress packet processing; the packet does not go to the next ingress table.) +.. _ls-in-31: + Ingress table 31 External ports ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -1288,6 +1355,8 @@ traffic from these ports. - A priority-0 flow that matches all packets to advances to table 20. +.. _ls-in-32: + Ingress Table 32 Destination Lookup ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -1307,8 +1376,8 @@ This table implements switching behavior. It contains these logical flows: - A priority-100 flow that matches ``reg8[23] == 1`` and does ``output`` action. This ensures that packets that got injected back into this table from egress - table ``Network Function`` (after it set the ``outport`` for packet - redirection) get forwarded without any further processing. + table :ref:`Network Function <ls-out-13>` (after it set the ``outport`` for + packet redirection) get forwarded without any further processing. - For any logical port that's defined as a target of routing protocol redirecting (via ``routing-protocol-redirect`` option set on Logical Router @@ -1439,6 +1508,8 @@ This table implements switching behavior. It contains these logical flows: If there is no entry for ``eth.dst`` in the MAC learning table, then it stores ``none`` in the ``outport``. +.. _ls-in-33: + Ingress Table 33 Destination unknown ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -1466,28 +1537,35 @@ following flows. - One priority-0 fallback flow that outputs the packet to the egress stage with the outport learnt from ``get_fdb`` action. +.. _ls-out-0: + Egress Table 0: Lookup MAC address learning table ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -This is similar to ingress table ``Lookup MAC address learning table`` with the -difference that MAC address learning lookup is only happening for ports with -type ``remote`` whose port security is disabled and 'unknown' address set. This -stage facilitates MAC learning on a transit switch connecting multiple -availability zones. +This is similar to ingress table :ref:`Lookup MAC address learning table +<ls-in-3>` with the difference that MAC address learning lookup is only +happening for ports with type ``remote`` whose port security is disabled and +'unknown' address set. This stage facilitates MAC learning on a transit switch +connecting multiple availability zones. + +.. _ls-out-1: Egress Table 1: Learn MAC of 'unknown' ports. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -This is similar to ingress table ``Learn MAC of 'unknown' ports`` with the -difference that MAC address learning is only happening for ports with type -``remote`` whose port security is disabled and 'unknown' address set. This +This is similar to ingress table :ref:`Learn MAC of 'unknown' ports <ls-in-4>` +with the difference that MAC address learning is only happening for ports with +type ``remote`` whose port security is disabled and 'unknown' address set. This stage facilitates MAC learning on a transit switch connecting multiple availability zones. +.. _ls-out-2: + Egress Table 2: ``to-lport`` Pre-ACLs ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -This is similar to ingress table ``Pre-ACLs`` except for ``to-lport`` traffic. +This is similar to ingress table :ref:`Pre-ACLs <ls-in-5>` except for +``to-lport`` traffic. This table also has a priority-110 flow with the match ``eth.src == E`` for all logical switch datapaths to move traffic to the next table. Where *E* is the @@ -1502,23 +1580,26 @@ switch datapath for routing. This table also has a priority-110 flow for each network_function ``inport`` *P* that matches ``inport == P``. The action is to skip all the egress tables up to -the ``Network Function`` table and advance the packet directly to the table -after that. This is for the case where packet redirection happens in egress -``Network Function`` table. The same packet when it comes out of the other port -of network function, they should not be processed again by the same egress -stages, specially they should skip the conntrack processing. +the :ref:`Network Function <ls-out-13>` table and advance the packet directly to +the table after that. This is for the case where packet redirection happens in +egress :ref:`Network Function <ls-out-13>` table. The same packet when it comes +out of the other port of network function, they should not be processed again by +the same egress stages, specially they should skip the conntrack processing. + +.. _ls-out-3: Egress Table 3: Pre-LB ~~~~~~~~~~~~~~~~~~~~~~~~ -This table is similar to ingress table ``Pre-LB``. It contains a priority-0 -flow that simply moves traffic to the next table. Moreover it contains two -priority-110 flows to move multicast, IPv6 Neighbor Discovery and MLD traffic to -the next table. If any load balancing rules exist for the datapath, a -priority-100 flow is added with a match of ``ip`` and action of ``reg0[2] = 1; -next;`` to act as a hint for table ``Pre-stateful`` to send IP packets to the -connection tracker for packet de-fragmentation and possibly DNAT the destination -VIP to one of the selected backend for already committed load balanced traffic. +This table is similar to ingress table :ref:`Pre-LB <ls-in-6>`. It contains a +priority-0 flow that simply moves traffic to the next table. Moreover it +contains two priority-110 flows to move multicast, IPv6 Neighbor Discovery and +MLD traffic to the next table. If any load balancing rules exist for the +datapath, a priority-100 flow is added with a match of ``ip`` and action of +``reg0[2] = 1; next;`` to act as a hint for table :ref:`Pre-stateful <ls-out-4>` +to send IP packets to the connection tracker for packet de-fragmentation and +possibly DNAT the destination VIP to one of the selected backend for already +committed load balanced traffic. This table also has a priority-110 flow with the match ``eth.src == E`` for all logical switch datapaths to move traffic to the next table. Where *E* is the @@ -1535,11 +1616,13 @@ When ``enable-stateless-acl-with-lb`` is enabled, additional priority-115 flow is added to match traffic with ``REGBIT_ACL_STATELESS`` set and pass connection tracking. +.. _ls-out-4: + Egress Table 4: Pre-stateful ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -This is similar to ingress table ``Pre-stateful``. This table adds the below 3 -logical flows. +This is similar to ingress table :ref:`Pre-stateful <ls-in-7>`. This table adds +the below 3 logical flows. - A Priority-120 flow that send the packets to connection tracker using ``ct_lb_mark;`` as the action so that the already established traffic gets @@ -1554,22 +1637,26 @@ logical flows. - A priority-0 flow that matches all packets to advance to the next table. +.. _ls-out-5: + Egress Table 5: ``from-lport`` ACL hints ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -This is similar to ingress table ``ACL hints``. +This is similar to ingress table :ref:`ACL hints <ls-in-8>`. + +.. _ls-out-6: Egress Table 6: ``to-lport`` ACL evaluation ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -This is similar to ingress table ``ACL eval`` except for ``to-lport`` ACLs. As a -reminder, these flows use the following register bits to indicate their -verdicts. ``Allow-type`` ACLs set ``reg8[16]``, ``drop`` ACLs set ``reg8[17]``, -and ``reject`` ACLs set ``reg8[18]``. +This is similar to ingress table :ref:`ACL eval <ls-in-9>` except for +``to-lport`` ACLs. As a reminder, these flows use the following register bits to +indicate their verdicts. ``Allow-type`` ACLs set ``reg8[16]``, ``drop`` ACLs set +``reg8[17]``, and ``reject`` ACLs set ``reg8[18]``. Also like with ingress ACLs, egress ACLs can have network_function_group *id* and in that case the flow will set ``reg8[21] = 1; reg8[22] = 1; reg0[22..29] = -id``. These registers are used in the ``Network Function`` table. +id``. These registers are used in the :ref:`Network Function <ls-out-13>` table. Also like with ingress ACLs, egress ACLs can have a configured ``tier``. If a tier is configured, then the current tier counter is evaluated against the ACL's @@ -1584,13 +1671,13 @@ In addition, the following flows are added. - A priority 34000 logical flow is added for each logical port which has DHCPv4 options defined to allow the DHCPv4 reply packet and which has DHCPv6 options - defined to allow the DHCPv6 reply packet from the ``Ingress Table 26: DHCP - responses``. This is indicated by setting the allow bit. + defined to allow the DHCPv6 reply packet from :ref:`Ingress Table 28: DHCP + responses <ls-in-28>`. This is indicated by setting the allow bit. - A priority 34000 logical flow is added for each logical switch datapath configured with DNS records with the match ``udp.dst = 53`` to allow the DNS - reply packet from the ``Ingress Table 28: DNS responses``. This is indicated - by setting the allow bit. + reply packet from :ref:`Ingress Table 30: DNS responses <ls-in-30>`. This is + indicated by setting the allow bit. - A priority 34000 logical flow is added for each logical switch datapath with the match ``eth.src = E`` to allow the service monitor request packet @@ -1598,15 +1685,21 @@ In addition, the following flows are added. service monitor mac defined in the ``options:svc_monitor_mac`` column of ``NB_Global`` table. This is indicated by setting the allow bit. +.. _ls-out-7: + Egress Table 7: ``to-lport`` ACL sampling ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -This is similar to ingress table ``ACL sampling``. +This is similar to ingress table :ref:`ACL sampling <ls-in-10>`. + +.. _ls-out-8: Egress Table 8: ``to-lport`` ACL action ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -This is similar to ingress table ``ACL action``. +This is similar to ingress table :ref:`ACL action <ls-in-11>`. + +.. _ls-out-9: Egress Table 9: Mirror ~~~~~~~~~~~~~~~~~~~~~~~~ @@ -1625,11 +1718,15 @@ Overlay remote mirror table contains the following logical flows: switch ports, matches all outcoming packets that match rules and clones the packet and sends cloned packet to mirror target port. +.. _ls-out-10: + Egress Table 10: ``to-lport`` QoS ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -This is similar to ingress table ``QoS`` except they apply to ``to-lport`` QoS -rules. +This is similar to ingress table :ref:`QoS <ls-in-12>` except they apply to +``to-lport`` QoS rules. + +.. _ls-out-11: Egress Table 11: Pre Network Function ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -1679,12 +1776,15 @@ support network function load balancing. - A priority-0 flow that simply moves traffic to the next table. +.. _ls-out-12: + Egress Table 12: Stateful ~~~~~~~~~~~~~~~~~~~~~~~~~~ -This is similar to ingress table ``Stateful`` except that there are no rules -added for load balancing new connections. When ``enable-stateless-acl-with-lb`` -is enabled, new stateless connections bypass connection tracking. +This is similar to ingress table :ref:`Stateful <ls-in-24>` except that there +are no rules added for load balancing new connections. When +``enable-stateless-acl-with-lb`` is enabled, new stateless connections bypass +connection tracking. - A priority 120 flow is added for each network function port *P* that is identical to the priority 100 flow except for additional match ``outport == @@ -1698,6 +1798,8 @@ is enabled, new stateless connections bypass connection tracking. packet back to host1. This is required to make cross host traffic redirection work for VLAN subnet. +.. _ls-out-13: + Egress Table 13: Network Function ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -1709,19 +1811,20 @@ packets are handled in the ingress pipeline, but corresponding response/related packets for those flows are redirected here using the network function ID stored in ``ct_label.nf_id`` during request processing. -- Similar to ingress ``Network Function`` a priority-100 flow is added for each - network_function port, that matches the inport with the network function port - and advances the packet to the next table. +- Similar to ingress :ref:`Network Function <ls-in-25>` a priority-100 flow is + added for each network_function port, that matches the inport with the network + function port and advances the packet to the next table. - For each active network function with *id* that is referenced in a network function group, a priority-99 flow matches ``reg8[21] == 1 && reg8[22] == 1 && reg0[22..29] == id`` and sets ``outport=P; reg8[23] = 1; next(pipeline=ingress, table=T)`` where *P* is the ``outport`` of that network - function and *T* is the ingress table ``Destination Lookup``. This redirects - request packets matching ``to-lport`` ACLs with network_function_group to the - specific network function selected by the Pre Network Function stage. The - packets are injected back to the ingress pipeline from where they get sent - out, skipping any further lookup because of ``reg8[23]``. + function and *T* is the ingress table :ref:`Destination Lookup <ls-in-32>`. + This redirects request packets matching ``to-lport`` ACLs with + network_function_group to the specific network function selected by the Pre + Network Function stage. The packets are injected back to the ingress pipeline + from where they get sent out, skipping any further lookup because of + ``reg8[23]``. - For each active network function with *id* that is referenced in a network function group, a priority-99 rule matches ``reg8[21] == 1 && reg8[22] == 0 && @@ -1734,18 +1837,21 @@ in ``ct_label.nf_id`` during request processing. the other port of the network_function, it would match the priority 100 flow and be forwarded to the next table. -- One priority-100 multicast match flow same as ingress ``Network Function``. +- One priority-100 multicast match flow same as ingress :ref:`Network Function + <ls-in-25>`. -- One priority-1 flow same as ingress ``Network Function``. +- One priority-1 flow same as ingress :ref:`Network Function <ls-in-25>`. -- One priority-0 flow same as ingress ``Network Function``. +- One priority-0 flow same as ingress :ref:`Network Function <ls-in-25>`. + +.. _ls-out-14: Egress Table 14: Egress Port Security - check ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -This is similar to the port security logic in table ``Ingress Port Security -check`` except that action ``check_out_port_sec`` is used to check the port -security rules. This table adds the below logical flows. +This is similar to the port security logic in table :ref:`Ingress Port Security +check <ls-in-0>` except that action ``check_out_port_sec`` is used to check the +port security rules. This table adds the below logical flows. - A priority 100 flow which matches on the multicast traffic and applies the action ``REGBIT_PORT_SEC_DROP" = 0; next;"`` to skip the out port security @@ -1757,13 +1863,15 @@ security rules. This table adds the below logical flows. addresses defined in the ``port_security`` column of ``Logical_Switch_Port`` table before delivering the packet to the ``outport``. +.. _ls-out-15: + Egress Table 15: Egress Port Security - Apply ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -This is similar to the ingress port security logic in ingress table ``A Ingress -Port Security - Apply``. This table drops the packets if the port security -check failed in the previous stage i.e the register bit ``REGBIT_PORT_SEC_DROP`` -is set to 1. +This is similar to the ingress port security logic in ingress table +:ref:`Ingress Port Security - Apply <ls-in-1>`. This table drops the packets if +the port security check failed in the previous stage i.e the register bit +``REGBIT_PORT_SEC_DROP`` is set to 1. The following flows are added. @@ -1785,12 +1893,16 @@ The following flows are added. - A priority-0 flow that outputs the packet to the ``outport``. +.. _lr-datapaths: + Logical Router Datapaths ------------------------ Logical router datapaths will only exist for ``Logical_Router`` rows in the OVN Northbound database that do not have ``enabled`` set to ``false`` +.. _lr-in-0: + Ingress Table 0: L2 Admission Control ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -1846,6 +1958,8 @@ Ethernet headers. It contains the following flows: Other packets are implicitly dropped. +.. _lr-in-1: + Ingress Table 1: Neighbor lookup ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -1926,6 +2040,8 @@ Following flows are added: - A priority-0 fallback flow that matches all packets and applies the action ``reg9[2] = 1; next;`` advancing the packet to the next table. +.. _lr-in-2: + Ingress Table 2: Neighbor learning ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -1962,6 +2078,8 @@ packet (if reg9[2] is 0). - A priority-0 logical flow that matches all packets not already handled (match ``1``) and drops them (action ``drop;``). +.. _lr-in-3: + Ingress Table 3: IP Input ~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -2352,6 +2470,8 @@ traffic, potentially for forwarding: and uses actions ``next;`` to feed them to the next table. +.. _lr-in-4: + Ingress Table 4: DHCP Relay Request ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -2377,6 +2497,8 @@ action is applied in the IP input stage. - A priority-0 flow that matches all packets to advance to the next table. +.. _lr-in-5: + Ingress Table 5: UNSNAT ~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -2443,6 +2565,8 @@ Ingress Table 5: UNSNAT on Distributed Routers A priority-0 logical flow with match ``1`` has actions ``next;``. +.. _lr-in-6: + Ingress Table 6: POST USNAT ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -2456,6 +2580,8 @@ next;`` Which sets one of the flags that is used in later stages. There is extra match on both when there is configured DGP ``inport == DGP && is_chassis_resident(CHASSIS)``. +.. _lr-in-7: + Ingress Table 7: DEFRAG ~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -2464,8 +2590,8 @@ It contains a priority-0 flow that simply moves traffic to the next table. For all load balancing rules that are configured in ``OVN_Northbound`` database for a Gateway router, a priority-100 flow is added for each configured virtual -IP address *VIP*. For IPv4 *VIPs* the flow matches ``ip && ip4.dst == VIP``. -For IPv6 *VIPs*, the flow matches ``ip && ip6.dst == VIP``. The flow applies the +IP address *VIP*. For IPv4 *VIPs* the flow matches ``ip && ip4.dst == VIP``. For +IPv6 *VIPs*, the flow matches ``ip && ip6.dst == VIP``. The flow applies the action ``ct_dnat;`` to send IP packets to the connection tracker for packet de- fragmentation and to dnat the destination IP for the committed connection before sending it to the next table. @@ -2491,6 +2617,8 @@ configured matching on ``ip && (!ct.trk || !ct.rpl)`` with an action ``ct_next(dnat);``. There is extra match when the LR is configured as DGP ``inport == DGP && is_chassis_resident(CHASSIS)``. +.. _lr-in-8: + Ingress Table 8: Connection tracking field extraction ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -2510,6 +2638,8 @@ them in registers for use by subsequent load balancing stages. - A priority-0 flow that matches all packets and advances to the next table with action ``next;``. +.. _lr-in-9: + Ingress Table 9: Load balancing affinity check ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -2527,6 +2657,8 @@ Load balancing affinity check table contains the following logical flows: - A priority 0 flow is added which matches on all packets and applies the action ``next;``. +.. _lr-in-10: + Ingress Table 10: DNAT ~~~~~~~~~~~~~~~~~~~~~~~ @@ -2583,9 +2715,9 @@ flows do not get programmed for load balancers with IPv6 *VIPs*. ``skip_snat`` set to true, the above action will be replaced by ``flags.skip_snat_for_lb = 1; ct_lb_mark(args; skip_snat);``. - The previous table ``lr_in_defrag`` sets the register ``reg0`` (or ``xxreg0`` - for IPv6) and does ``ct_dnat``. Hence for established traffic, this table - just advances the packet to the next stage. + The previous table :ref:`DEFRAG <lr-in-7>` sets the register ``reg0`` (or + ``xxreg0`` for IPv6) and does ``ct_dnat``. Hence for established traffic, + this table just advances the packet to the next stage. - If the load balancer is created with ``--reject`` option and it has no active backends, a TCP reset segment (for tcp) or an ICMP port unreachable packet @@ -2674,6 +2806,8 @@ the egress pipeline. A priority-0 logical flow with match ``1`` has actions ``next;``. +.. _lr-in-11: + Ingress Table 11: Load balancing affinity learn ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -2690,6 +2824,8 @@ Load balancing affinity learn table contains the following logical flows: - A priority 0 flow is added which matches on all packets and applies the action ``next;``. +.. _lr-in-12: + Ingress Table 12: ECMP symmetric reply processing ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -2704,6 +2840,8 @@ Ingress Table 12: ECMP symmetric reply processing ``eth.src`` and the ECMP reply port binding tunnel key *K* in the ``ct_label`` and the traffic pattern to table ``76`` or ``77``. +.. _lr-in-13: + Ingress Table 13: IPv6 ND RA option processing ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -2721,6 +2859,8 @@ Ingress Table 13: IPv6 ND RA option processing - A priority-0 logical flow with match ``1`` has actions ``next;``. +.. _lr-in-14: + Ingress Table 14: IPv6 ND RA responder ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -2749,6 +2889,8 @@ by the previous table. - A priority-0 logical flow with match ``1`` has actions ``next;``. +.. _lr-in-15: + Ingress Table 15: IP Routing Pre ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -2766,6 +2908,8 @@ This table contains the following logical flows: A priority-0 logical flow with match ``1`` has actions ``reg7 = 0; next;``. +.. _lr-in-16: + Ingress Table 16: IP Routing ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -2775,8 +2919,9 @@ setting ``reg0`` (or ``xxreg0`` for IPv6) to the next-hop IP address (leaving ``ip4.dst`` or ``ip6.dst``, the packet's final destination, unchanged) and advances to the next table for ARP resolution. It also sets ``reg1`` (or ``xxreg1``) to the IP address owned by the selected router port (ingress table -``ARP Request`` will generate an ARP request, if needed, with ``reg0`` as the -target protocol address and ``reg1`` as the source protocol address). +:ref:`ARP Request <lr-in-27>` will generate an ARP request, if needed, with +``reg0`` as the target protocol address and ``reg1`` as the source protocol +address). For ECMP routes, i.e. multiple static routes with same policy and prefix but different nexthops, the above actions are deferred to next table. This table, @@ -2898,6 +3043,8 @@ This table contains the following logical flows: - A priority-0 logical flow that matches all packets not already handled (match ``1``) and drops them (action ``drop;``). +.. _lr-in-17: + Ingress Table 17: IP_ROUTING_ECMP ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -2908,8 +3055,9 @@ setting ``reg0`` (or ``xxreg0`` for IPv6) to the next-hop IP address (leaving ``ip4.dst`` or ``ip6.dst``, the packet's final destination, unchanged) and advances to the next table for ARP resolution. It also sets ``reg1`` (or ``xxreg1``) to the IP address owned by the selected router port (ingress table -``ARP Request`` will generate an ARP request, if needed, with ``reg0`` as the -target protocol address and ``reg1`` as the source protocol address). +:ref:`ARP Request <lr-in-27>` will generate an ARP request, if needed, with +``reg0`` as the target protocol address and ``reg1`` as the source protocol +address). This processing is skipped for reply traffic being sent out of an ECMP route if the route was configured to use symmetric replies. @@ -2931,6 +3079,8 @@ This table contains the following logical flows: - A priority-0 logical flow that matches all packets not already handled (match ``1``) and drops them (action ``drop;``). +.. _lr-in-18: + Ingress Table 18: Router policies ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -2970,6 +3120,8 @@ table documentation in ``ovn-nb`` for supported actions. ``not`` drop, then the action also includes ``pkt.mark = m`` to mark the packet with the marker *m*. +.. _lr-in-19: + Ingress Table 19: ECMP handling for router policies ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -2998,6 +3150,8 @@ nexthops. - A priority-0 logical flow that matches all packets not already handled (match ``1``) and drops them (action ``drop;``). +.. _lr-in-20: + Ingress Table 20: DHCP Relay Response Check ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -3016,6 +3170,8 @@ This stage process the DHCP response packets coming from the DHCP server. - A priority-0 flow that matches all packets to advance to the next table. +.. _lr-in-21: + Ingress Table 21: DHCP Relay Response ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -3041,6 +3197,8 @@ action is applied in the previous stage. - A priority-0 flow that matches all packets to advance to the next table. +.. _lr-in-22: + Ingress Table 22: ARP/ND Resolution ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -3122,11 +3280,11 @@ contains the final destination.) This table resolves the IP address in ``reg0`` xxreg0); next;`` for IPv6. - Traffic with IP destination an address owned by the router should be dropped. - Such traffic is normally dropped in ingress table ``IP Input`` except for IPs - that are also shared with SNAT rules. However, if there was no unSNAT - operation that happened successfully until this point in the pipeline and the - destination IP of the packet is still a router owned IP, the packets can be - safely dropped. + Such traffic is normally dropped in ingress table :ref:`IP Input <lr-in-3>` + except for IPs that are also shared with SNAT rules. However, if there was no + unSNAT operation that happened successfully until this point in the pipeline + and the destination IP of the packet is still a router owned IP, the packets + can be safely dropped. A priority-2 logical flow with match ``ip4.dst = {..}`` matches on traffic destined to router owned IPv4 addresses which are also SNAT IPs. This flow has @@ -3140,9 +3298,9 @@ contains the final destination.) This table resolves the IP address in ``reg0`` ``1``) and drops them (action ``drop;``). - Dynamic MAC bindings. These flows resolve MAC-to-IP bindings that have become - known dynamically through ARP or neighbor discovery. (The ingress table ``ARP - Request`` will issue an ARP or neighbor solicitation request for cases where - the binding is not yet known.) + known dynamically through ARP or neighbor discovery. (The ingress table + :ref:`ARP Request <lr-in-27>` will issue an ARP or neighbor solicitation + request for cases where the binding is not yet known.) A priority-0 logical flow with match ``ip4`` has actions ``get_arp(outport, reg0); next;``. @@ -3155,6 +3313,8 @@ contains the final destination.) This table resolves the IP address in ``reg0`` !is_chassis_resident("cr-ROUTER_PORT")`` has actions ``eth.dst = E; next;``, where *E* is the ethernet address of the logical router port. +.. _lr-in-23: + Ingress Table 23: Check packet length ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -3178,6 +3338,8 @@ flow is added, with priority-55, to bypass the ``check_pkt_larger`` flow. This table adds one priority-0 fallback flow that matches all packets and advances to the next table. +.. _lr-in-24: + Ingress Table 24: Handle larger packets ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -3225,6 +3387,8 @@ respectively:: This table adds one priority-0 fallback flow that matches all packets and advances to the next table. +.. _lr-in-25: + Ingress Table 25: Gateway Redirect ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -3273,6 +3437,8 @@ following flows: - A priority-0 logical flow with match ``1`` has actions ``next;``. +.. _lr-in-26: + Ingress Table 26: Network ID ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -3299,6 +3465,8 @@ This table contains flows that set ``flags.network_id`` for IP packets: - Catch-all: A priority-0 flow with match ``1`` has actions ``next;``. +.. _lr-in-27: + Ingress Table 27: ARP Request ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -3340,13 +3508,15 @@ or IPv6 Neighbor Solicitation request. It holds the following flows: output; }; - (Ingress table ``IP Routing`` initialized ``reg1`` with the IP address owned - by ``outport`` and ``(xx)reg0`` with the next-hop IP address) + (Ingress table :ref:`IP Routing <lr-in-16>` initialized ``reg1`` with the IP + address owned by ``outport`` and ``(xx)reg0`` with the next-hop IP address) The IP packet that triggers the ARP/IPv6 NS request is dropped. - Known MAC address. A priority-0 flow with match ``1`` has actions ``next;``. +.. _lr-in-28: + Ingress Table 28: ECMP symmetric reply processing for egress ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -3357,18 +3527,22 @@ routers, the only type of routers that supports ECMP symmetric reply routes. As the egress port of the traffic needs to be stored in conntrack for these sessions, one logical flow is added for each logical router port. +.. _lr-out-0: + Egress Table 0: Check DNAT local ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This table checks if the packet needs to be DNATed in the router ingress table -``lr_in_dnat`` after it is SNATed and looped back to the ingress pipeline. -This check is done only for routers configured with distributed gateway ports -and NAT entries. This check is done so that SNAT and DNAT is done in different -zones instead of a common zone. +:ref:`DNAT <lr-in-10>` after it is SNATed and looped back to the ingress +pipeline. This check is done only for routers configured with distributed +gateway ports and NAT entries. This check is done so that SNAT and DNAT is done +in different zones instead of a common zone. - A priority-0 logical flow with match ``1`` has actions ``REGBIT_DST_NAT_IP_LOCAL = 0; next;``. +.. _lr-out-1: + Egress Table 1: UNDNAT ~~~~~~~~~~~~~~~~~~~~~~~ @@ -3378,6 +3552,8 @@ pipeline as part of a reply. This traffic is unDNATed here. - A priority-0 logical flow with match ``1`` has actions ``next;``. +.. _lr-out-1-undnat-on-gateway-routers: + Egress Table 1: UNDNAT on Gateway Routers ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -3387,6 +3563,8 @@ Egress Table 1: UNDNAT on Gateway Routers - For all IP packets, a priority-50 flow with an action ``flags.loopback = 1; ct_dnat;``. +.. _lr-out-1-undnat-on-distributed-routers: + Egress Table 1: UNDNAT on Distributed Routers ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -3418,6 +3596,8 @@ Egress Table 1: UNDNAT on Distributed Routers associated with the IP address *A* in the NAT rule. This allows upstream MAC learning to point to the correct chassis. +.. _lr-out-2: + Egress Table 2: Post UNDNAT ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -3426,8 +3606,8 @@ Egress Table 2: Post UNDNAT ``lr_out_snat``, to effectively match on various CT states. - A priority-50 logical flow is added that commits any untracked flows from the - previous table ``lr_out_undnat`` for Gateway routers. This flow matches on - ``ct.new && ip`` with action ``ct_commit { } ; next;``. + previous table :ref:`UNDNAT <lr-out-1>` for Gateway routers. This flow + matches on ``ct.new && ip`` with action ``ct_commit { } ; next;``. - If the ``options:ct-commit-all`` is set to ``true`` the following flows are configured matching on ``ip && (!ct.trk || !ct.rpl) && @@ -3437,6 +3617,8 @@ Egress Table 2: Post UNDNAT - A priority-0 logical flow with match ``1`` has actions ``next;``. +.. _lr-out-3: + Egress Table 3: SNAT ~~~~~~~~~~~~~~~~~~~~~ @@ -3501,7 +3683,7 @@ Egress Table 3: SNAT on Gateway Routers source IP address of a packet that belongs to network *A* to *B*, match *M* and priority *P*, a flow matches ``ip && ip4.src == A && (!ct.trk || !ct.rpl) && (M)`` with an action ``ct_snat(B);``. The priority of the flow is - calculated based as ``300 + P``. If the NAT rule is of type dnat_and_snat and + calculated based as ``300 + P``. If the NAT rule is of type dnat_and_snat and has ``stateless=true`` in the options, then the action would be ``ip4/6.src=(B)``. @@ -3536,7 +3718,7 @@ Egress Table 3: SNAT on Distributed Routers - The first flow is added with the calculated priority *P* and match ``ip && ip4.src == A && outport == GW``, where *GW* is the logical router gateway - port, with an action ``ct_snat(B);`` to SNATed in the common zone. If the + port, with an action ``ct_snat(B);`` to SNATed in the common zone. If the NAT rule is of type dnat_and_snat and has ``stateless=true`` in the options, then the action would be ``ip4/6.src=(B)``. @@ -3571,6 +3753,8 @@ Egress Table 3: SNAT on Distributed Routers - A priority-0 logical flow with match ``1`` has actions ``next;``. +.. _lr-out-4: + Egress Table 4: Post SNAT ~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -3580,12 +3764,14 @@ Packets reaching this table are processed according to the flows below: routers, and was initiated from an external network (i.e. it matches ``ct.new``), is committed to the SNAT CT zone. This ensures that replies returning from the SNATed network do not have their source address translated. - For details about match rules and priority see section "Egress Table 3: SNAT - on Distributed Routers". + For details about match rules and priority see section :ref:`SNAT on + Distributed Routers <lr-out-3>`. - A priority-0 logical flow that matches all packets not already handled (match ``1``) and action ``next;``. +.. _lr-out-5: + Egress Table 5: Egress Loopback ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -3630,6 +3816,8 @@ This table has the following flows: - A priority-0 logical flow with match ``1`` has actions ``next;``. +.. _lr-out-6: + Egress Table 6: Delivery ~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -3645,6 +3833,8 @@ Packets that reach this table are ready for delivery. It contains: - A priority-0 logical flow that matches all packets not already handled (match ``1``) and drops them (action ``drop;``). +.. _drop-sampling: + Drop sampling ------------- -- 2.52.0 _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
