diff mbox series

[ovs-dev,v9,1/6] northd: fix symmetric ECMP reply flows documentation

Message ID 20211119160721.60612-2-odivlad@gmail.com
State Accepted
Headers show
Series Add multiple routing tables support to Logical Routers | expand

Checks

Context Check Description
ovsrobot/apply-robot success apply and check: success
ovsrobot/github-robot-_Build_and_Test success github build: passed
ovsrobot/github-robot-_ovn-kubernetes fail github build: failed

Commit Message

Vladislav Odintsov Nov. 19, 2021, 4:07 p.m. UTC
This patch fixes a flow priority which is added in IP Defrag table and
adds priority value for symmetric ECMP reply flow in IP Routing table.

Fixes: 384a7c6 (northd: Refactor Logical Flows for routers with DNAT/Load Balancers)
Signed-off-by: Vladislav Odintsov <odivlad@gmail.com>
---
 northd/ovn-northd.8.xml | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)
diff mbox series

Patch

diff --git a/northd/ovn-northd.8.xml b/northd/ovn-northd.8.xml
index 21d83718c..a56a54955 100644
--- a/northd/ovn-northd.8.xml
+++ b/northd/ovn-northd.8.xml
@@ -2945,7 +2945,7 @@  icmp6 {
 
     <p>
       If ECMP routes with symmetric reply are configured in the
-      <code>OVN_Northbound</code> database for a gateway router, a priority-300
+      <code>OVN_Northbound</code> database for a gateway router, a priority-100
       flow is added for each router port on which symmetric replies are
       configured. The matching logic for these ports essentially reverses the
       configured logic of the ECMP route. So for instance, a route with a
@@ -3313,14 +3313,14 @@  output;
       table.  This table, instead, is responsible for determine the ECMP
       group id and select a member id within the group based on 5-tuple
       hashing.  It stores group id in <code>reg8[0..15]</code> and member id in
-      <code>reg8[16..31]</code>. This step is skipped if the traffic going
-      out the ECMP route is reply traffic, and the ECMP route was configured
-      to use symmetric replies. Instead, the stored <code>ct_label</code> value
-      is used to choose the destination. The least significant 48 bits of the
-      <code>ct_label</code> tell the destination MAC address to which the
-      packet should be sent. The next 16 bits tell the logical router port on
-      which the packet should be sent. These values in the
-      <code>ct_label</code> are set when the initial ingress traffic is
+      <code>reg8[16..31]</code>. This step is skipped with a priority-300 rule
+      if the traffic going out the ECMP route is reply traffic, and the ECMP
+      route was configured to use symmetric replies. Instead, the stored
+      <code>ct_label</code> value is used to choose the destination. The least
+      significant 48 bits of the <code>ct_label</code> tell the destination MAC
+      address to which the packet should be sent. The next 16 bits tell the
+      logical router port on which the packet should be sent. These values in
+      the <code>ct_label</code> are set when the initial ingress traffic is
       received over the ECMP route.
     </p>