diff --git a/src/static/support/dist-docs-branch-24.03/ovn-appctl.8.pdf b/src/static/support/dist-docs-branch-24.03/ovn-appctl.8.pdf
index 00a22a9..7af66e9 100644
Binary files a/src/static/support/dist-docs-branch-24.03/ovn-appctl.8.pdf and b/src/static/support/dist-docs-branch-24.03/ovn-appctl.8.pdf differ
diff --git a/src/static/support/dist-docs-branch-24.03/ovn-architecture.7.pdf b/src/static/support/dist-docs-branch-24.03/ovn-architecture.7.pdf
index b83c159..ea4ae94 100644
Binary files a/src/static/support/dist-docs-branch-24.03/ovn-architecture.7.pdf and b/src/static/support/dist-docs-branch-24.03/ovn-architecture.7.pdf differ
diff --git a/src/static/support/dist-docs-branch-24.03/ovn-controller-vtep.8.pdf b/src/static/support/dist-docs-branch-24.03/ovn-controller-vtep.8.pdf
index 07cc826..be199ff 100644
Binary files a/src/static/support/dist-docs-branch-24.03/ovn-controller-vtep.8.pdf and b/src/static/support/dist-docs-branch-24.03/ovn-controller-vtep.8.pdf differ
diff --git a/src/static/support/dist-docs-branch-24.03/ovn-controller.8.pdf b/src/static/support/dist-docs-branch-24.03/ovn-controller.8.pdf
index 1596627..fd0edad 100644
Binary files a/src/static/support/dist-docs-branch-24.03/ovn-controller.8.pdf and b/src/static/support/dist-docs-branch-24.03/ovn-controller.8.pdf differ
diff --git a/src/static/support/dist-docs-branch-24.03/ovn-ctl.8.pdf b/src/static/support/dist-docs-branch-24.03/ovn-ctl.8.pdf
index 30f1282..464f959 100644
Binary files a/src/static/support/dist-docs-branch-24.03/ovn-ctl.8.pdf and b/src/static/support/dist-docs-branch-24.03/ovn-ctl.8.pdf differ
diff --git a/src/static/support/dist-docs-branch-24.03/ovn-debug.8.pdf b/src/static/support/dist-docs-branch-24.03/ovn-debug.8.pdf
index fbf4143..e08a7b6 100644
Binary files a/src/static/support/dist-docs-branch-24.03/ovn-debug.8.pdf and b/src/static/support/dist-docs-branch-24.03/ovn-debug.8.pdf differ
diff --git a/src/static/support/dist-docs-branch-24.03/ovn-detrace.1.pdf b/src/static/support/dist-docs-branch-24.03/ovn-detrace.1.pdf
index d416719..8e28a93 100644
Binary files a/src/static/support/dist-docs-branch-24.03/ovn-detrace.1.pdf and b/src/static/support/dist-docs-branch-24.03/ovn-detrace.1.pdf differ
diff --git a/src/static/support/dist-docs-branch-24.03/ovn-ic-nb.5.pdf b/src/static/support/dist-docs-branch-24.03/ovn-ic-nb.5.pdf
index e745d01..e4d632f 100644
Binary files a/src/static/support/dist-docs-branch-24.03/ovn-ic-nb.5.pdf and b/src/static/support/dist-docs-branch-24.03/ovn-ic-nb.5.pdf differ
diff --git a/src/static/support/dist-docs-branch-24.03/ovn-ic-nbctl.8.pdf b/src/static/support/dist-docs-branch-24.03/ovn-ic-nbctl.8.pdf
index b9babb6..cb37ac7 100644
Binary files a/src/static/support/dist-docs-branch-24.03/ovn-ic-nbctl.8.pdf and b/src/static/support/dist-docs-branch-24.03/ovn-ic-nbctl.8.pdf differ
diff --git a/src/static/support/dist-docs-branch-24.03/ovn-ic-sb.5.pdf b/src/static/support/dist-docs-branch-24.03/ovn-ic-sb.5.pdf
index 725c95f..ee3b3eb 100644
Binary files a/src/static/support/dist-docs-branch-24.03/ovn-ic-sb.5.pdf and b/src/static/support/dist-docs-branch-24.03/ovn-ic-sb.5.pdf differ
diff --git a/src/static/support/dist-docs-branch-24.03/ovn-ic-sbctl.8.pdf b/src/static/support/dist-docs-branch-24.03/ovn-ic-sbctl.8.pdf
index 32df0d5..89b6b49 100644
Binary files a/src/static/support/dist-docs-branch-24.03/ovn-ic-sbctl.8.pdf and b/src/static/support/dist-docs-branch-24.03/ovn-ic-sbctl.8.pdf differ
diff --git a/src/static/support/dist-docs-branch-24.03/ovn-ic.8.pdf b/src/static/support/dist-docs-branch-24.03/ovn-ic.8.pdf
index a021476..8d2113a 100644
Binary files a/src/static/support/dist-docs-branch-24.03/ovn-ic.8.pdf and b/src/static/support/dist-docs-branch-24.03/ovn-ic.8.pdf differ
diff --git a/src/static/support/dist-docs-branch-24.03/ovn-nb.5.pdf b/src/static/support/dist-docs-branch-24.03/ovn-nb.5.pdf
index 894aa65..64d8602 100644
Binary files a/src/static/support/dist-docs-branch-24.03/ovn-nb.5.pdf and b/src/static/support/dist-docs-branch-24.03/ovn-nb.5.pdf differ
diff --git a/src/static/support/dist-docs-branch-24.03/ovn-nbctl.8.pdf b/src/static/support/dist-docs-branch-24.03/ovn-nbctl.8.pdf
index 4f926f4..7e42c78 100644
Binary files a/src/static/support/dist-docs-branch-24.03/ovn-nbctl.8.pdf and b/src/static/support/dist-docs-branch-24.03/ovn-nbctl.8.pdf differ
diff --git a/src/static/support/dist-docs-branch-24.03/ovn-northd.8 b/src/static/support/dist-docs-branch-24.03/ovn-northd.8
index 013cd55..4acc777 100644
--- a/src/static/support/dist-docs-branch-24.03/ovn-northd.8
+++ b/src/static/support/dist-docs-branch-24.03/ovn-northd.8
@@ -2250,7 +2250,23 @@ For each IPv4/IPv6 ECMP group with group id \fIGID\fR and member ids \fIMID1\fR,
.br
\fBreg8[0\[char46]\[char46]15] = \fR\fIGID\fB\fR;
.br
-\fBselect(reg8[16\[char46]\[char46]31], \fR\fIMID1\fB\fR, \fR\fIMID2\fB\fR, \[char46]\[char46]\[char46]);
+\fBreg8[16\[char46]\[char46]31] = select(\fR\fIMID1\fB\fR, \fR\fIMID2\fB\fR, \[char46]\[char46]\[char46]);
+.br
+\fB \fR
+.fi
+.IP
+However, when there is only one route in an ECMP group, group actions will be:
+.IP
+.nf
+\fB
+.br
+\fBip\[char46]ttl\-\-;
+.br
+\fBflags\[char46]loopback = 1;
+.br
+\fBreg8[0\[char46]\[char46]15] = \fR\fIGID\fB\fR;
+.br
+\fBreg8[16\[char46]\[char46]31] = \fR\fIMID1\fB\fR);
.br
\fB \fR
.fi
diff --git a/src/static/support/dist-docs-branch-24.03/ovn-northd.8.html b/src/static/support/dist-docs-branch-24.03/ovn-northd.8.html
index 836bd85..623cbb8 100644
--- a/src/static/support/dist-docs-branch-24.03/ovn-northd.8.html
+++ b/src/static/support/dist-docs-branch-24.03/ovn-northd.8.html
@@ -3031,35 +3031,44 @@
ip.ttl--;
flags.loopback = 1;
reg8[0..15] = GID;
- select(reg8[16..31], MID1, MID2, ...);
+ reg8[16..31] = select(MID1, MID2, ...);
- • A priority-0 logical flow that matches all packets not
+ However, when there is only one route in an ECMP group,
+ group actions will be:
+
+ ip.ttl--;
+ flags.loopback = 1;
+ reg8[0..15] = GID;
+ reg8[16..31] = MID1);
+
+
+ • A priority-0 logical flow that matches all packets not
already handled (match 1) and drops them (action drop;).
Ingress Table 14: IP_ROUTING_ECMP
- This table implements the second part of IP routing for ECMP routes
- following the previous table. If a packet matched a ECMP group in the
- previous table, this table matches the group id and member id stored
+ This table implements the second part of IP routing for ECMP routes
+ following the previous table. If a packet matched a ECMP group in the
+ previous table, this table matches the group id and member id stored
from the previous table, setting reg0 (or xxreg0 for IPv6) to the next-
hop IP address (leaving ip4.dst or ip6.dst, the packet’s final destina‐
- tion, unchanged) and advances to the next table for ARP resolution. It
- also sets reg1 (or xxreg1) to the IP address owned by the selected
+ tion, 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).
- This processing is skipped for reply traffic being sent out of an ECMP
+ This processing is skipped for reply traffic being sent out of an ECMP
route if the route was configured to use symmetric replies.
This table contains the following logical flows:
- • A priority-150 flow that matches reg8[0..15] == 0 with
- action next; directly bypasses packets of non-ECMP
+ • A priority-150 flow that matches reg8[0..15] == 0 with
+ action next; directly bypasses packets of non-ECMP
routes.
- • For each member with ID MID in each ECMP group with ID
+ • For each member with ID MID in each ECMP group with ID
GID, a priority-100 flow with match reg8[0..15] == GID &&&&
reg8[16..31] == MID has following actions:
@@ -3069,35 +3078,35 @@
outport = P;
- • A priority-0 logical flow that matches all packets not
+ • A priority-0 logical flow that matches all packets not
already handled (match 1) and drops them (action drop;).
Ingress Table 15: Router policies
This table adds flows for the logical router policies configured on the
- logical router. Please see the OVN_Northbound database Logi‐‐
+ logical router. Please see the OVN_Northbound database Logi‐‐
cal_Router_Policy table documentation in ovn-nb for supported actions.
- • For each router policy configured on the logical router,
- a logical flow is added with specified priority, match
+ • For each router policy configured on the logical router,
+ a logical flow is added with specified priority, match
and actions.
- • If the policy action is reroute with 2 or more nexthops
- defined, then the logical flow is added with the follow‐
+ • If the policy action is reroute with 2 or more nexthops
+ defined, then the logical flow is added with the follow‐
ing actions:
reg8[0..15] = GID;
reg8[16..31] = select(1,..n);
- where GID is the ECMP group id generated by ovn-northd
- for this policy and n is the number of nexthops. select
+ where GID is the ECMP group id generated by ovn-northd
+ for this policy and n is the number of nexthops. select
action selects one of the nexthop member id, stores it in
- the register reg8[16..31] and advances the packet to the
+ the register reg8[16..31] and advances the packet to the
next stage.
- • If the policy action is reroute with just one nexhop,
- then the logical flow is added with the following ac‐
+ • If the policy action is reroute with just one nexhop,
+ then the logical flow is added with the following ac‐
tions:
[xx]reg0 = H;
@@ -3108,30 +3117,30 @@
next;
- where H is the nexthop defined in the router policy, E
- is the ethernet address of the logical router port from
- which the nexthop is reachable and P is the logical
+ where H is the nexthop defined in the router policy, E
+ is the ethernet address of the logical router port from
+ which the nexthop is reachable and P is the logical
router port from which the nexthop is reachable.
- • If a router policy has the option pkt_mark=m set and if
- the action is not drop, then the action also includes
+ • If a router policy has the option pkt_mark=m set and if
+ the action is not drop, then the action also includes
pkt.mark = m to mark the packet with the marker m.
Ingress Table 16: ECMP handling for router policies
- This table handles the ECMP for the router policies configured with
+ This table handles the ECMP for the router policies configured with
multiple nexthops.
• A priority-150 flow is added to advance the packet to the
- next stage if the ECMP group id register reg8[0..15] is
+ next stage if the ECMP group id register reg8[0..15] is
0.
- • For each ECMP reroute router policy with multiple nex‐
- thops, a priority-100 flow is added for each nexthop H
- with the match reg8[0..15] == GID &&&& reg8[16..31] == M
- where GID is the router policy group id generated by
+ • For each ECMP reroute router policy with multiple nex‐
+ thops, a priority-100 flow is added for each nexthop H
+ with the match reg8[0..15] == GID &&&& reg8[16..31] == M
+ where GID is the router policy group id generated by
ovn-northd and M is the member id of the nexthop H gener‐
- ated by ovn-northd. The following actions are added to
+ ated by ovn-northd. The following actions are added to
the flow:
[xx]reg0 = H;
@@ -3141,154 +3150,154 @@
"next;"
- where H is the nexthop defined in the router policy, E
- is the ethernet address of the logical router port from
- which the nexthop is reachable and P is the logical
+ where H is the nexthop defined in the router policy, E
+ is the ethernet address of the logical router port from
+ which the nexthop is reachable and P is the logical
router port from which the nexthop is reachable.
- • A priority-0 logical flow that matches all packets not
+ • A priority-0 logical flow that matches all packets not
already handled (match 1) and drops them (action drop;).
Ingress Table 17: ARP/ND Resolution
- Any packet that reaches this table is an IP packet whose next-hop IPv4
- address is in reg0 or IPv6 address is in xxreg0. (ip4.dst or ip6.dst
- contains the final destination.) This table resolves the IP address in
+ Any packet that reaches this table is an IP packet whose next-hop IPv4
+ address is in reg0 or IPv6 address is in xxreg0. (ip4.dst or ip6.dst
+ contains the final destination.) This table resolves the IP address in
reg0 (or xxreg0) into an output port in outport and an Ethernet address
in eth.dst, using the following flows:
- • A priority-500 flow that matches IP multicast traffic
- that was allowed in the routing pipeline. For this kind
- of traffic the outport was already set so the flow just
+ • A priority-500 flow that matches IP multicast traffic
+ that was allowed in the routing pipeline. For this kind
+ of traffic the outport was already set so the flow just
advances to the next table.
- • Priority-200 flows that match ECMP reply traffic for the
- routes configured to use symmetric replies, with actions
+ • Priority-200 flows that match ECMP reply traffic for the
+ routes configured to use symmetric replies, with actions
push(xxreg1); xxreg1 = ct_label; eth.dst =
- xxreg1[32..79]; pop(xxreg1); next;. xxreg1 is used here
- to avoid masked access to ct_label, to make the flow HW-
+ xxreg1[32..79]; pop(xxreg1); next;. xxreg1 is used here
+ to avoid masked access to ct_label, to make the flow HW-
offloading friendly.
• Static MAC bindings. MAC bindings can be known statically
- based on data in the OVN_Northbound database. For router
- ports connected to logical switches, MAC bindings can be
- known statically from the addresses column in the Logi‐‐
- cal_Switch_Port table. (Note: the flow is not installed
- for IPs of logical switch ports of type virtual, and dy‐
- namic MAC binding is used for those IPs instead, so that
+ based on data in the OVN_Northbound database. For router
+ ports connected to logical switches, MAC bindings can be
+ known statically from the addresses column in the Logi‐‐
+ cal_Switch_Port table. (Note: the flow is not installed
+ for IPs of logical switch ports of type virtual, and dy‐
+ namic MAC binding is used for those IPs instead, so that
virtual parent failover does not depend on ovn-northd, to
- achieve better failover performance.) For router ports
- connected to other logical routers, MAC bindings can be
- known statically from the mac and networks column in the
- Logical_Router_Port table. (Note: the flow is NOT in‐
- stalled for the IP addresses that belong to a neighbor
- logical router port if the current router has the op‐‐
+ achieve better failover performance.) For router ports
+ connected to other logical routers, MAC bindings can be
+ known statically from the mac and networks column in the
+ Logical_Router_Port table. (Note: the flow is NOT in‐
+ stalled for the IP addresses that belong to a neighbor
+ logical router port if the current router has the op‐‐
tions:dynamic_neigh_routers set to true)
- For each IPv4 address A whose host is known to have Eth‐
- ernet address E on router port P, a priority-100 flow
+ For each IPv4 address A whose host is known to have Eth‐
+ ernet address E on router port P, a priority-100 flow
with match outport === P &&&& reg0 == A has actions eth.dst
= E; next;.
- For each IPv6 address A whose host is known to have Eth‐
- ernet address E on router port P, a priority-100 flow
- with match outport === P &&&& xxreg0 == A has actions
+ For each IPv6 address A whose host is known to have Eth‐
+ ernet address E on router port P, a priority-100 flow
+ with match outport === P &&&& xxreg0 == A has actions
eth.dst = E; next;.
For each logical router port with an IPv4 address A and a
- mac address of E that is reachable via a different logi‐
+ mac address of E that is reachable via a different logi‐
cal router port P, a priority-100 flow with match outport
=== P &&&& reg0 == A has actions eth.dst = E; next;.
For each logical router port with an IPv6 address A and a
- mac address of E that is reachable via a different logi‐
+ mac address of E that is reachable via a different logi‐
cal router port P, a priority-100 flow with match outport
=== P &&&& xxreg0 == A has actions eth.dst = E; next;.
- • Static MAC bindings from NAT entries. MAC bindings can
- also be known for the entries in the NAT table. Below
- flows are programmed for distributed logical routers i.e
+ • Static MAC bindings from NAT entries. MAC bindings can
+ also be known for the entries in the NAT table. Below
+ flows are programmed for distributed logical routers i.e
with a distributed router port.
- For each row in the NAT table with IPv4 address A in the
+ For each row in the NAT table with IPv4 address A in the
external_ip column of NAT table, below two flows are pro‐
grammed:
- A priority-100 flow with the match outport == P &&&& reg0
- == A has actions eth.dst = E; next;, where P is the dis‐
- tributed logical router port, E is the Ethernet address
- if set in the external_mac column of NAT table for of
+ A priority-100 flow with the match outport == P &&&& reg0
+ == A has actions eth.dst = E; next;, where P is the dis‐
+ tributed logical router port, E is the Ethernet address
+ if set in the external_mac column of NAT table for of
type dnat_and_snat, otherwise the Ethernet address of the
- distributed logical router port. Note that if the exter‐‐
- nal_ip is not within a subnet on the owning logical
+ distributed logical router port. Note that if the exter‐‐
+ nal_ip is not within a subnet on the owning logical
router, then OVN will only create ARP resolution flows if
- the options:add_route is set to true. Otherwise, no ARP
+ the options:add_route is set to true. Otherwise, no ARP
resolution flows will be added.
Corresponding to the above flow, a priority-150 flow with
the match inport == P &&&& outport == P &&&& ip4.dst == A has
- actions drop; to exclude packets that have gone through
- DNAT/unSNAT stage but failed to convert the destination,
+ actions drop; to exclude packets that have gone through
+ DNAT/unSNAT stage but failed to convert the destination,
to avoid loop.
For IPv6 NAT entries, same flows are added, but using the
register xxreg0 and field ip6 for the match.
• If the router datapath runs a port with redirect-type set
- to bridged, for each distributed NAT rule with IP A in
- the logical_ip column and logical port P in the logi‐‐
+ to bridged, for each distributed NAT rule with IP A in
+ the logical_ip column and logical port P in the logi‐‐
cal_port column of NAT table, a priority-90 flow with the
- match outport == Q &&&& ip.src === A &&&& is_chassis_resi‐‐
- dent(P), where Q is the distributed logical router port
- and action get_arp(outport, reg0); next; for IPv4 and
+ match outport == Q &&&& ip.src === A &&&& is_chassis_resi‐‐
+ dent(P), where Q is the distributed logical router port
+ and action get_arp(outport, reg0); next; for IPv4 and
get_nd(outport, xxreg0); next; for IPv6.
- • Traffic with IP destination an address owned by the
+ • 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 un‐
- SNAT 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
+ SNAT 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 ad‐
- dresses which are also SNAT IPs. This flow has action
+ A priority-2 logical flow with match ip4.dst = {..}
+ matches on traffic destined to router owned IPv4 ad‐
+ dresses which are also SNAT IPs. This flow has action
drop;.
- A priority-2 logical flow with match ip6.dst = {..}
- matches on traffic destined to router owned IPv6 ad‐
- dresses which are also SNAT IPs. This flow has action
+ A priority-2 logical flow with match ip6.dst = {..}
+ matches on traffic destined to router owned IPv6 ad‐
+ dresses which are also SNAT IPs. This flow has action
drop;.
- A priority-0 logical that flow matches all packets not
+ A priority-0 logical that flow matches all packets not
already handled (match 1) and drops them (action drop;).
• Dynamic MAC bindings. These flows resolve MAC-to-IP bind‐
- ings 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
+ ings 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.)
- A priority-0 logical flow with match ip4 has actions
+ A priority-0 logical flow with match ip4 has actions
get_arp(outport, reg0); next;.
- A priority-0 logical flow with match ip6 has actions
+ A priority-0 logical flow with match ip6 has actions
get_nd(outport, xxreg0); next;.
- • For a distributed gateway LRP with redirect-type set to
- bridged, a priority-50 flow will match outport ==
+ • For a distributed gateway LRP with redirect-type set to
+ bridged, a priority-50 flow will match outport ==
"ROUTER_PORT" and !is_chassis_resident ("cr-ROUTER_PORT")
- has actions eth.dst = E; next;, where E is the ethernet
+ has actions eth.dst = E; next;, where E is the ethernet
address of the logical router port.
Ingress Table 18: Check packet length
- For distributed logical routers or gateway routers with gateway port
- configured with options:gateway_mtu to a valid integer value, this ta‐
- ble adds a priority-50 logical flow with the match outport == GW_PORT
- where GW_PORT is the gateway router port and applies the action
+ For distributed logical routers or gateway routers with gateway port
+ configured with options:gateway_mtu to a valid integer value, this ta‐
+ ble adds a priority-50 logical flow with the match outport == GW_PORT
+ where GW_PORT is the gateway router port and applies the action
check_pkt_larger and advances the packet to the next table.
REGBIT_PKT_LARGER = check_pkt_larger(L); next;
@@ -3299,20 +3308,20 @@
taken from options:gateway_mtu column of Logical_Router_Port row.
If the port is also configured with options:gateway_mtu_bypass then an‐
- other flow is added, with priority-55, to bypass the check_pkt_larger
+ other 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
+ This table adds one priority-0 fallback flow that matches all packets
and advances to the next table.
Ingress Table 19: Handle larger packets
- For distributed logical routers or gateway routers with gateway port
- configured with options:gateway_mtu to a valid integer value, this ta‐
- ble adds the following priority-150 logical flow for each logical
- router port with the match inport == LRP &&&& outport == GW_PORT &&&& REG‐‐
- BIT_PKT_LARGER &&&& !REGBIT_EGRESS_LOOPBACK, where LRP is the logical
- router port and GW_PORT is the gateway port and applies the following
+ For distributed logical routers or gateway routers with gateway port
+ configured with options:gateway_mtu to a valid integer value, this ta‐
+ ble adds the following priority-150 logical flow for each logical
+ router port with the match inport == LRP &&&& outport == GW_PORT &&&& REG‐‐
+ BIT_PKT_LARGER &&&& !REGBIT_EGRESS_LOOPBACK, where LRP is the logical
+ router port and GW_PORT is the gateway port and applies the following
action for ipv4 and ipv6 respectively:
icmp4 {
@@ -3341,66 +3350,66 @@
};
- • Where M is the (fragment MTU - 58) whose value is taken
- from options:gateway_mtu column of Logical_Router_Port
+ • Where M is the (fragment MTU - 58) whose value is taken
+ from options:gateway_mtu column of Logical_Router_Port
row.
• E is the Ethernet address of the logical router port.
• I is the IPv4/IPv6 address of the logical router port.
- This table adds one priority-0 fallback flow that matches all packets
+ This table adds one priority-0 fallback flow that matches all packets
and advances to the next table.
Ingress Table 20: Gateway Redirect
For distributed logical routers where one or more of the logical router
ports specifies a gateway chassis, this table redirects certain packets
- to the distributed gateway port instances on the gateway chassises.
+ to the distributed gateway port instances on the gateway chassises.
This table has the following flows:
- • For all the configured load balancing rules that include
+ • For all the configured load balancing rules that include
an IPv4 address VIP, and a list of IPv4 backend addresses
- B0, B1 .. Bn defined for the VIP a priority-200 flow is
+ B0, B1 .. Bn defined for the VIP a priority-200 flow is
added that matches ip4 &&&& (ip4.src == B0 || ip4.src == B1
- || ... || ip4.src == Bn) with an action outport = CR;
- next; where CR is the chassisredirect port representing
- the instance of the logical router distributed gateway
- port on the gateway chassis. If the backend IPv4 address
- Bx is also configured with L4 port PORT of protocol P,
+ || ... || ip4.src == Bn) with an action outport = CR;
+ next; where CR is the chassisredirect port representing
+ the instance of the logical router distributed gateway
+ port on the gateway chassis. If the backend IPv4 address
+ Bx is also configured with L4 port PORT of protocol P,
then the match also includes P.src == PORT. Similar flows
are added for IPv6.
• For each NAT rule in the OVN Northbound database that can
- be handled in a distributed manner, a priority-100 logi‐
- cal flow with match ip4.src == B &&&& outport == GW &&
+ be handled in a distributed manner, a priority-100 logi‐
+ cal flow with match ip4.src == B &&&& outport == GW &&
is_chassis_resident(P), where GW is the distributed gate‐
way port specified in the NAT rule and P is the NAT logi‐
cal port. IP traffic matching the above rule will be man‐
- aged locally setting reg1 to C and eth.src to D, where C
+ aged locally setting reg1 to C and eth.src to D, where C
is NAT external ip and D is NAT external mac.
- • For each dnat_and_snat NAT rule with stateless=true and
- allowed_ext_ips configured, a priority-75 flow is pro‐
- grammed with match ip4.dst == B and action outport = CR;
- next; where B is the NAT rule external IP and CR is the
- chassisredirect port representing the instance of the
- logical router distributed gateway port on the gateway
- chassis. Moreover a priority-70 flow is programmed with
- same match and action drop;. For each dnat_and_snat NAT
+ • For each dnat_and_snat NAT rule with stateless=true and
+ allowed_ext_ips configured, a priority-75 flow is pro‐
+ grammed with match ip4.dst == B and action outport = CR;
+ next; where B is the NAT rule external IP and CR is the
+ chassisredirect port representing the instance of the
+ logical router distributed gateway port on the gateway
+ chassis. Moreover a priority-70 flow is programmed with
+ same match and action drop;. For each dnat_and_snat NAT
rule with stateless=true and exempted_ext_ips configured,
- a priority-75 flow is programmed with match ip4.dst == B
- and action drop; where B is the NAT rule external IP. A
+ a priority-75 flow is programmed with match ip4.dst == B
+ and action drop; where B is the NAT rule external IP. A
similar flow is added for IPv6 traffic.
• For each NAT rule in the OVN Northbound database that can
be handled in a distributed manner, a priority-80 logical
- flow with drop action if the NAT logical port is a vir‐
+ flow with drop action if the NAT logical port is a vir‐
tual port not claimed by any chassis yet.
- • A priority-50 logical flow with match outport == GW has
- actions outport = CR; next;, where GW is the logical
- router distributed gateway port and CR is the chas‐‐
+ • A priority-50 logical flow with match outport == GW has
+ actions outport = CR; next;, where GW is the logical
+ router distributed gateway port and CR is the chas‐‐
sisredirect port representing the instance of the logical
router distributed gateway port on the gateway chassis.
@@ -3408,8 +3417,8 @@
Ingress Table 21: ARP Request
- In the common case where the Ethernet destination has been resolved,
- this table outputs the packet. Otherwise, it composes and sends an ARP
+ In the common case where the Ethernet destination has been resolved,
+ this table outputs the packet. Otherwise, it composes and sends an ARP
or IPv6 Neighbor Solicitation request. It holds the following flows:
• Unknown MAC address. A priority-100 flow for IPv4 packets
@@ -3425,10 +3434,10 @@
};
- Unknown MAC address. For each IPv6 static route associ‐
- ated with the router with the nexthop IP: G, a prior‐
- ity-200 flow for IPv6 packets with match eth.dst ==
- 00:00:00:00:00:00 &&&& xxreg0 == G with the following ac‐
+ Unknown MAC address. For each IPv6 static route associ‐
+ ated with the router with the nexthop IP: G, a prior‐
+ ity-200 flow for IPv6 packets with match eth.dst ==
+ 00:00:00:00:00:00 &&&& xxreg0 == G with the following ac‐
tions is added:
nd_ns {
@@ -3440,7 +3449,7 @@
Where E is the multicast mac derived from the Gateway IP,
- I is the solicited-node multicast address corresponding
+ I is the solicited-node multicast address corresponding
to the target address G.
Unknown MAC address. A priority-100 flow for IPv6 packets
@@ -3453,11 +3462,11 @@
};
- (Ingress table IP Routing initialized reg1 with the IP
- address owned by outport and (xx)reg0 with the next-hop
+ (Ingress table IP Routing 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
+ The IP packet that triggers the ARP/IPv6 NS request is
dropped.
• Known MAC address. A priority-0 flow with match 1 has ac‐
@@ -3465,20 +3474,20 @@
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
+ 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.
- • A priority-0 logical flow with match 1 has actions REG‐‐
+ • A priority-0 logical flow with match 1 has actions REG‐‐
BIT_DST_NAT_IP_LOCAL = 0; next;.
Egress Table 1: UNDNAT
- This is for already established connections’ reverse traffic. i.e.,
- DNAT has already been done in ingress pipeline and now the packet has
- entered the egress pipeline as part of a reply. This traffic is unD‐
+ This is for already established connections’ reverse traffic. i.e.,
+ DNAT has already been done in ingress pipeline and now the packet has
+ entered the egress pipeline as part of a reply. This traffic is unD‐
NATed here.
• A priority-0 logical flow with match 1 has actions next;.
@@ -3488,177 +3497,177 @@
• For IPv6 Neighbor Discovery or Router Solicitation/Adver‐
tisement traffic, a priority-100 flow with action next;.
- • For all IP packets, a priority-50 flow with an action
+ • For all IP packets, a priority-50 flow with an action
flags.loopback = 1; ct_dnat;.
Egress Table 1: UNDNAT on Distributed Routers
- • For all the configured load balancing rules for a router
- with gateway port in OVN_Northbound database that in‐
- cludes an IPv4 address VIP, for every backend IPv4 ad‐
- dress B defined for the VIP a priority-120 flow is pro‐
- grammed on gateway chassis that matches ip &&&& ip4.src ==
- B &&&& outport == GW, where GW is the logical router gate‐
+ • For all the configured load balancing rules for a router
+ with gateway port in OVN_Northbound database that in‐
+ cludes an IPv4 address VIP, for every backend IPv4 ad‐
+ dress B defined for the VIP a priority-120 flow is pro‐
+ grammed on gateway chassis that matches ip &&&& ip4.src ==
+ B &&&& outport == GW, where GW is the logical router gate‐
way port with an action ct_dnat;. If the backend IPv4 ad‐
- dress B is also configured with L4 port PORT of protocol
- P, then the match also includes P.src == PORT. These
+ dress B is also configured with L4 port PORT of protocol
+ P, then the match also includes P.src == PORT. These
flows are not added for load balancers with IPv6 VIPs.
- If the router is configured to force SNAT any load-bal‐
- anced packets, above action will be replaced by
+ If the router is configured to force SNAT any load-bal‐
+ anced packets, above action will be replaced by
flags.force_snat_for_lb = 1; ct_dnat;.
- • For each configuration in the OVN Northbound database
- that asks to change the destination IP address of a
- packet from an IP address of A to B, a priority-100 flow
- matches ip &&&& ip4.src == B &&&& outport == GW, where GW is
+ • For each configuration in the OVN Northbound database
+ that asks to change the destination IP address of a
+ packet from an IP address of A to B, a priority-100 flow
+ matches ip &&&& ip4.src == B &&&& outport == GW, where GW is
the logical router gateway port, with an action ct_dnat;.
- If the NAT rule is of type dnat_and_snat and has state‐‐
+ If the NAT rule is of type dnat_and_snat and has state‐‐
less=true in the options, then the action would be next;.
- If the NAT rule cannot be handled in a distributed man‐
- ner, then the priority-100 flow above is only programmed
+ If the NAT rule cannot be handled in a distributed man‐
+ ner, then the priority-100 flow above is only programmed
on the gateway chassis with the action ct_dnat.
- If the NAT rule can be handled in a distributed manner,
- then there is an additional action eth.src = EA;, where
+ If the NAT rule can be handled in a distributed manner,
+ then there is an additional action eth.src = EA;, where
EA is the ethernet address associated with the IP address
- A in the NAT rule. This allows upstream MAC learning to
+ A in the NAT rule. This allows upstream MAC learning to
point to the correct chassis.
Egress Table 2: Post UNDNAT
- • A priority-70 logical flow is added that initiates CT
+ • A priority-70 logical flow is added that initiates CT
state for traffic that is configured to be SNATed on Dis‐
tributed routers. This allows the next table,
lr_out_snat, to effectively match on various CT states.
- • A priority-50 logical flow is added that commits any un‐
- tracked flows from the previous table lr_out_undnat for
- Gateway routers. This flow matches on ct.new &&&& ip with
+ • A priority-50 logical flow is added that commits any un‐
+ tracked flows from the previous table lr_out_undnat for
+ Gateway routers. This flow matches on ct.new &&&& ip with
action ct_commit { } ; next; .
• A priority-0 logical flow with match 1 has actions next;.
Egress Table 3: SNAT
- Packets that are configured to be SNATed get their source IP address
+ Packets that are configured to be SNATed get their source IP address
changed based on the configuration in the OVN Northbound database.
- • A priority-120 flow to advance the IPv6 Neighbor solici‐
- tation packet to next table to skip SNAT. In the case
- where ovn-controller injects an IPv6 Neighbor Solicita‐
- tion packet (for nd_ns action) we don’t want the packet
+ • A priority-120 flow to advance the IPv6 Neighbor solici‐
+ tation packet to next table to skip SNAT. In the case
+ where ovn-controller injects an IPv6 Neighbor Solicita‐
+ tion packet (for nd_ns action) we don’t want the packet
to go through conntrack.
Egress Table 3: SNAT on Gateway Routers
- • If the Gateway router in the OVN Northbound database has
- been configured to force SNAT a packet (that has been
- previously DNATted) to B, a priority-100 flow matches
- flags.force_snat_for_dnat == 1 &&&& ip with an action
+ • If the Gateway router in the OVN Northbound database has
+ been configured to force SNAT a packet (that has been
+ previously DNATted) to B, a priority-100 flow matches
+ flags.force_snat_for_dnat == 1 &&&& ip with an action
ct_snat(B);.
- • If a load balancer configured to skip snat has been ap‐
+ • If a load balancer configured to skip snat has been ap‐
plied to the Gateway router pipeline, a priority-120 flow
- matches flags.skip_snat_for_lb == 1 &&&& ip with an action
+ matches flags.skip_snat_for_lb == 1 &&&& ip with an action
next;.
- • If the Gateway router in the OVN Northbound database has
- been configured to force SNAT a packet (that has been
- previously load-balanced) using router IP (i.e op‐‐
- tions:lb_force_snat_ip=router_ip), then for each logical
- router port P attached to the Gateway router, a prior‐
+ • If the Gateway router in the OVN Northbound database has
+ been configured to force SNAT a packet (that has been
+ previously load-balanced) using router IP (i.e op‐‐
+ tions:lb_force_snat_ip=router_ip), then for each logical
+ router port P attached to the Gateway router, a prior‐
ity-110 flow matches flags.force_snat_for_lb == 1 &&&& out‐‐
port == P
- with an action ct_snat(R); where R is the IP configured
- on the router port. If R is an IPv4 address then the
+ with an action ct_snat(R); where R is the IP configured
+ on the router port. If R is an IPv4 address then the
match will also include ip4 and if it is an IPv6 address,
then the match will also include ip6.
- If the logical router port P is configured with multiple
+ If the logical router port P is configured with multiple
IPv4 and multiple IPv6 addresses, only the first IPv4 and
first IPv6 address is considered.
- • If the Gateway router in the OVN Northbound database has
- been configured to force SNAT a packet (that has been
+ • If the Gateway router in the OVN Northbound database has
+ been configured to force SNAT a packet (that has been
previously load-balanced) to B, a priority-100 flow
matches flags.force_snat_for_lb == 1 &&&& ip with an action
ct_snat(B);.
- • For each configuration in the OVN Northbound database,
- that asks to change the source IP address of a packet
- from an IP address of A or to change the source IP ad‐
- dress of a packet that belongs to network A to B, a flow
- matches ip &&&& ip4.src == A &&&& (!ct.trk || !ct.rpl) with
+ • For each configuration in the OVN Northbound database,
+ that asks to change the source IP address of a packet
+ from an IP address of A or to change the source IP ad‐
+ dress of a packet that belongs to network A to B, a flow
+ matches ip &&&& ip4.src == A &&&& (!ct.trk || !ct.rpl) with
an action ct_snat(B);. The priority of the flow is calcu‐
- lated based on the mask of A, with matches having larger
- masks getting higher priorities. If the NAT rule is of
+ lated based on the mask of A, with matches having larger
+ masks getting higher priorities. 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).
- • If the NAT rule has allowed_ext_ips configured, then
+ • If the NAT rule has allowed_ext_ips configured, then
there is an additional match ip4.dst == allowed_ext_ips .
- Similarly, for IPV6, match would be ip6.dst == al
+ Similarly, for IPV6, match would be ip6.dst == al
lowed_ext_ips.
- • If the NAT rule has exempted_ext_ips set, then there is
+ • If the NAT rule has exempted_ext_ips set, then there is
an additional flow configured at the priority + 1 of cor‐
- responding NAT rule. The flow matches if destination ip
+ responding NAT rule. The flow matches if destination ip
is an exempted_ext_ip and the action is next; . This flow
- is used to bypass the ct_snat action for a packet which
+ is used to bypass the ct_snat action for a packet which
is destinted to exempted_ext_ips.
• A priority-0 logical flow with match 1 has actions next;.
Egress Table 3: SNAT on Distributed Routers
- • For each configuration in the OVN Northbound database,
- that asks to change the source IP address of a packet
- from an IP address of A or to change the source IP ad‐
- dress of a packet that belongs to network A to B, two
+ • For each configuration in the OVN Northbound database,
+ that asks to change the source IP address of a packet
+ from an IP address of A or to change the source IP ad‐
+ dress of a packet that belongs to network A to B, two
flows are added. The priority P of these flows are calcu‐
- lated based on the mask of A, with matches having larger
+ lated based on the mask of A, with matches having larger
masks getting higher priorities.
- If the NAT rule cannot be handled in a distributed man‐
- ner, then the below flows are only programmed on the
- gateway chassis increasing flow priority by 128 in order
+ If the NAT rule cannot be handled in a distributed man‐
+ ner, then the below flows are only programmed on the
+ gateway chassis increasing flow priority by 128 in order
to be run first.
• The first flow is added with the calculated prior‐
- ity P and match ip &&&& ip4.src == A &&&& outport ==
- GW, where GW is the logical router gateway port,
+ ity 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 NAT rule is of type dnat_and_snat and
has stateless=true in the options, then the action
would be ip4/6.src=(B).
- If the NAT rule can be handled in a distributed manner,
- then there is an additional action (for both the flows)
- eth.src = EA;, where EA is the ethernet address associ‐
- ated with the IP address A in the NAT rule. This allows
+ If the NAT rule can be handled in a distributed manner,
+ then there is an additional action (for both the flows)
+ eth.src = EA;, where EA is the ethernet address associ‐
+ ated with the IP address A in the NAT rule. This allows
upstream MAC learning to point to the correct chassis.
- If the NAT rule has allowed_ext_ips configured, then
+ If the NAT rule has allowed_ext_ips configured, then
there is an additional match ip4.dst == allowed_ext_ips .
- Similarly, for IPV6, match would be ip6.dst == al
+ Similarly, for IPV6, match would be ip6.dst == al
lowed_ext_ips.
- If the NAT rule has exempted_ext_ips set, then there is
- an additional flow configured at the priority P + 2 of
- corresponding NAT rule. The flow matches if destination
- ip is an exempted_ext_ip and the action is next; . This
- flow is used to bypass the ct_snat action for a flow
+ If the NAT rule has exempted_ext_ips set, then there is
+ an additional flow configured at the priority P + 2 of
+ corresponding NAT rule. The flow matches if destination
+ ip is an exempted_ext_ip and the action is next; . This
+ flow is used to bypass the ct_snat action for a flow
which is destinted to exempted_ext_ips.
- • An additional flow is added for traffic that goes in op‐
- posite direction (i.e. it enters a network with config‐
- ured SNAT). Where the flow above matched on ip4.src == A
- &&&& outport == GW, this flow matches on ip4.dst == A &&&&
+ • An additional flow is added for traffic that goes in op‐
+ posite direction (i.e. it enters a network with config‐
+ ured SNAT). Where the flow above matched on ip4.src == A
+ &&&& outport == GW, this flow matches on ip4.dst == A &&&&
inport == GW. A CT state is initiated for this traffic so
- that the following table, lr_out_post_snat, can identify
- whether the traffic flow was initiated from the internal
+ that the following table, lr_out_post_snat, can identify
+ whether the traffic flow was initiated from the internal
or external network.
• A priority-0 logical flow with match 1 has actions next;.
@@ -3668,40 +3677,40 @@
Packets reaching this table are processed according to the flows below:
• Traffic that goes directly into a network configured with
- SNAT on Distributed 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
+ SNAT on Distributed 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".
- • A priority-0 logical flow that matches all packets not
+ • A priority-0 logical flow that matches all packets not
already handled (match 1) and action next;.
Egress Table 5: Egress Loopback
- For distributed logical routers where one of the logical router ports
+ For distributed logical routers where one of the logical router ports
specifies a gateway chassis.
- While UNDNAT and SNAT processing have already occurred by this point,
- this traffic needs to be forced through egress loopback on this dis‐
+ While UNDNAT and SNAT processing have already occurred by this point,
+ this traffic needs to be forced through egress loopback on this dis‐
tributed gateway port instance, in order for UNSNAT and DNAT processing
- to be applied, and also for IP routing and ARP resolution after all of
+ to be applied, and also for IP routing and ARP resolution after all of
the NAT processing, so that the packet can be forwarded to the destina‐
tion.
This table has the following flows:
- • For each NAT rule in the OVN Northbound database on a
- distributed router, a priority-100 logical flow with
- match ip4.dst == E &&&& outport == GW &&&& is_chassis_resi‐‐
- dent(P), where E is the external IP address specified in
- the NAT rule, GW is the distributed gateway port corre‐
- sponding to the NAT rule (specified or inferred). For
- dnat_and_snat NAT rule, P is the logical port specified
- in the NAT rule. If logical_port column of NAT table is
- NOT set, then P is the chassisredirect port of GW with
+ • For each NAT rule in the OVN Northbound database on a
+ distributed router, a priority-100 logical flow with
+ match ip4.dst == E &&&& outport == GW &&&& is_chassis_resi‐‐
+ dent(P), where E is the external IP address specified in
+ the NAT rule, GW is the distributed gateway port corre‐
+ sponding to the NAT rule (specified or inferred). For
+ dnat_and_snat NAT rule, P is the logical port specified
+ in the NAT rule. If logical_port column of NAT table is
+ NOT set, then P is the chassisredirect port of GW with
the following actions:
clone {
@@ -3719,9 +3728,9 @@
};
- flags.loopback is set since in_port is unchanged and the
+ flags.loopback is set since in_port is unchanged and the
packet may return back to that port after NAT processing.
- REGBIT_EGRESS_LOOPBACK is set to indicate that egress
+ REGBIT_EGRESS_LOOPBACK is set to indicate that egress
loopback has occurred, in order to skip the source IP ad‐
dress check against the router address.
@@ -3731,33 +3740,33 @@
Packets that reach this table are ready for delivery. It contains:
- • Priority-110 logical flows that match IP multicast pack‐
- ets on each enabled logical router port and modify the
- Ethernet source address of the packets to the Ethernet
+ • Priority-110 logical flows that match IP multicast pack‐
+ ets on each enabled logical router port and modify the
+ Ethernet source address of the packets to the Ethernet
address of the port and then execute action output;.
• Priority-100 logical flows that match packets on each en‐
abled logical router port, with action output;.
- • A priority-0 logical flow that matches all packets not
+ • A priority-0 logical flow that matches all packets not
already handled (match 1) and drops them (action drop;).
DROP SAMPLING
- As described in the previous section, there are several places where
+ As described in the previous section, there are several places where
ovn-northd might decided to drop a packet by explicitly creating a Log‐‐
ical_Flow with the drop; action.
When debug drop-sampling has been cofigured in the OVN Northbound data‐
- base, the ovn-northd will replace all the drop; actions with a sam‐‐
- ple(priority=65535, collector_set=id, obs_domain=obs_id,
+ base, the ovn-northd will replace all the drop; actions with a sam‐‐
+ ple(priority=65535, collector_set=id, obs_domain=obs_id,
obs_point=@cookie) action, where:
- • id is the value the debug_drop_collector_set option con‐
+ • id is the value the debug_drop_collector_set option con‐
figured in the OVN Northbound.
- • obs_id has it’s 8 most significant bits equal to the
- value of the debug_drop_domain_id option in the OVN
- Northbound and it’s 24 least significant bits equal to
+ • obs_id has it’s 8 most significant bits equal to the
+ value of the debug_drop_domain_id option in the OVN
+ Northbound and it’s 24 least significant bits equal to
the datapath’s tunnel key.
OVN 24.03.4 ovn-northd ovn-northd(8)
diff --git a/src/static/support/dist-docs-branch-24.03/ovn-northd.8.pdf b/src/static/support/dist-docs-branch-24.03/ovn-northd.8.pdf
index d8b53f7..f26df7f 100644
Binary files a/src/static/support/dist-docs-branch-24.03/ovn-northd.8.pdf and b/src/static/support/dist-docs-branch-24.03/ovn-northd.8.pdf differ
diff --git a/src/static/support/dist-docs-branch-24.03/ovn-northd.8.txt b/src/static/support/dist-docs-branch-24.03/ovn-northd.8.txt
index 7835b8a..dbb6f77 100644
--- a/src/static/support/dist-docs-branch-24.03/ovn-northd.8.txt
+++ b/src/static/support/dist-docs-branch-24.03/ovn-northd.8.txt
@@ -3030,35 +3030,44 @@ LOGICAL FLOW TABLE STRUCTURE
ip.ttl--;
flags.loopback = 1;
reg8[0..15] = GID;
- select(reg8[16..31], MID1, MID2, ...);
+ reg8[16..31] = select(MID1, MID2, ...);
- • A priority-0 logical flow that matches all packets not
+ However, when there is only one route in an ECMP group,
+ group actions will be:
+
+ ip.ttl--;
+ flags.loopback = 1;
+ reg8[0..15] = GID;
+ reg8[16..31] = MID1);
+
+
+ • A priority-0 logical flow that matches all packets not
already handled (match 1) and drops them (action drop;).
Ingress Table 14: IP_ROUTING_ECMP
- This table implements the second part of IP routing for ECMP routes
- following the previous table. If a packet matched a ECMP group in the
- previous table, this table matches the group id and member id stored
+ This table implements the second part of IP routing for ECMP routes
+ following the previous table. If a packet matched a ECMP group in the
+ previous table, this table matches the group id and member id stored
from the previous table, setting reg0 (or xxreg0 for IPv6) to the next-
hop IP address (leaving ip4.dst or ip6.dst, the packet’s final destina‐
- tion, unchanged) and advances to the next table for ARP resolution. It
- also sets reg1 (or xxreg1) to the IP address owned by the selected
+ tion, 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).
- This processing is skipped for reply traffic being sent out of an ECMP
+ This processing is skipped for reply traffic being sent out of an ECMP
route if the route was configured to use symmetric replies.
This table contains the following logical flows:
- • A priority-150 flow that matches reg8[0..15] == 0 with
- action next; directly bypasses packets of non-ECMP
+ • A priority-150 flow that matches reg8[0..15] == 0 with
+ action next; directly bypasses packets of non-ECMP
routes.
- • For each member with ID MID in each ECMP group with ID
+ • For each member with ID MID in each ECMP group with ID
GID, a priority-100 flow with match reg8[0..15] == GID &&
reg8[16..31] == MID has following actions:
@@ -3068,35 +3077,35 @@ LOGICAL FLOW TABLE STRUCTURE
outport = P;
- • A priority-0 logical flow that matches all packets not
+ • A priority-0 logical flow that matches all packets not
already handled (match 1) and drops them (action drop;).
Ingress Table 15: Router policies
This table adds flows for the logical router policies configured on the
- logical router. Please see the OVN_Northbound database Logi‐
+ logical router. Please see the OVN_Northbound database Logi‐
cal_Router_Policy table documentation in ovn-nb for supported actions.
- • For each router policy configured on the logical router,
- a logical flow is added with specified priority, match
+ • For each router policy configured on the logical router,
+ a logical flow is added with specified priority, match
and actions.
- • If the policy action is reroute with 2 or more nexthops
- defined, then the logical flow is added with the follow‐
+ • If the policy action is reroute with 2 or more nexthops
+ defined, then the logical flow is added with the follow‐
ing actions:
reg8[0..15] = GID;
reg8[16..31] = select(1,..n);
- where GID is the ECMP group id generated by ovn-northd
- for this policy and n is the number of nexthops. select
+ where GID is the ECMP group id generated by ovn-northd
+ for this policy and n is the number of nexthops. select
action selects one of the nexthop member id, stores it in
- the register reg8[16..31] and advances the packet to the
+ the register reg8[16..31] and advances the packet to the
next stage.
- • If the policy action is reroute with just one nexhop,
- then the logical flow is added with the following ac‐
+ • If the policy action is reroute with just one nexhop,
+ then the logical flow is added with the following ac‐
tions:
[xx]reg0 = H;
@@ -3107,30 +3116,30 @@ LOGICAL FLOW TABLE STRUCTURE
next;
- where H is the nexthop defined in the router policy, E
- is the ethernet address of the logical router port from
- which the nexthop is reachable and P is the logical
+ where H is the nexthop defined in the router policy, E
+ is the ethernet address of the logical router port from
+ which the nexthop is reachable and P is the logical
router port from which the nexthop is reachable.
- • If a router policy has the option pkt_mark=m set and if
- the action is not drop, then the action also includes
+ • If a router policy has the option pkt_mark=m set and if
+ the action is not drop, then the action also includes
pkt.mark = m to mark the packet with the marker m.
Ingress Table 16: ECMP handling for router policies
- This table handles the ECMP for the router policies configured with
+ This table handles the ECMP for the router policies configured with
multiple nexthops.
• A priority-150 flow is added to advance the packet to the
- next stage if the ECMP group id register reg8[0..15] is
+ next stage if the ECMP group id register reg8[0..15] is
0.
- • For each ECMP reroute router policy with multiple nex‐
- thops, a priority-100 flow is added for each nexthop H
- with the match reg8[0..15] == GID && reg8[16..31] == M
- where GID is the router policy group id generated by
+ • For each ECMP reroute router policy with multiple nex‐
+ thops, a priority-100 flow is added for each nexthop H
+ with the match reg8[0..15] == GID && reg8[16..31] == M
+ where GID is the router policy group id generated by
ovn-northd and M is the member id of the nexthop H gener‐
- ated by ovn-northd. The following actions are added to
+ ated by ovn-northd. The following actions are added to
the flow:
[xx]reg0 = H;
@@ -3140,154 +3149,154 @@ LOGICAL FLOW TABLE STRUCTURE
"next;"
- where H is the nexthop defined in the router policy, E
- is the ethernet address of the logical router port from
- which the nexthop is reachable and P is the logical
+ where H is the nexthop defined in the router policy, E
+ is the ethernet address of the logical router port from
+ which the nexthop is reachable and P is the logical
router port from which the nexthop is reachable.
- • A priority-0 logical flow that matches all packets not
+ • A priority-0 logical flow that matches all packets not
already handled (match 1) and drops them (action drop;).
Ingress Table 17: ARP/ND Resolution
- Any packet that reaches this table is an IP packet whose next-hop IPv4
- address is in reg0 or IPv6 address is in xxreg0. (ip4.dst or ip6.dst
- contains the final destination.) This table resolves the IP address in
+ Any packet that reaches this table is an IP packet whose next-hop IPv4
+ address is in reg0 or IPv6 address is in xxreg0. (ip4.dst or ip6.dst
+ contains the final destination.) This table resolves the IP address in
reg0 (or xxreg0) into an output port in outport and an Ethernet address
in eth.dst, using the following flows:
- • A priority-500 flow that matches IP multicast traffic
- that was allowed in the routing pipeline. For this kind
- of traffic the outport was already set so the flow just
+ • A priority-500 flow that matches IP multicast traffic
+ that was allowed in the routing pipeline. For this kind
+ of traffic the outport was already set so the flow just
advances to the next table.
- • Priority-200 flows that match ECMP reply traffic for the
- routes configured to use symmetric replies, with actions
+ • Priority-200 flows that match ECMP reply traffic for the
+ routes configured to use symmetric replies, with actions
push(xxreg1); xxreg1 = ct_label; eth.dst =
- xxreg1[32..79]; pop(xxreg1); next;. xxreg1 is used here
- to avoid masked access to ct_label, to make the flow HW-
+ xxreg1[32..79]; pop(xxreg1); next;. xxreg1 is used here
+ to avoid masked access to ct_label, to make the flow HW-
offloading friendly.
• Static MAC bindings. MAC bindings can be known statically
- based on data in the OVN_Northbound database. For router
- ports connected to logical switches, MAC bindings can be
- known statically from the addresses column in the Logi‐
- cal_Switch_Port table. (Note: the flow is not installed
- for IPs of logical switch ports of type virtual, and dy‐
- namic MAC binding is used for those IPs instead, so that
+ based on data in the OVN_Northbound database. For router
+ ports connected to logical switches, MAC bindings can be
+ known statically from the addresses column in the Logi‐
+ cal_Switch_Port table. (Note: the flow is not installed
+ for IPs of logical switch ports of type virtual, and dy‐
+ namic MAC binding is used for those IPs instead, so that
virtual parent failover does not depend on ovn-northd, to
- achieve better failover performance.) For router ports
- connected to other logical routers, MAC bindings can be
- known statically from the mac and networks column in the
- Logical_Router_Port table. (Note: the flow is NOT in‐
- stalled for the IP addresses that belong to a neighbor
- logical router port if the current router has the op‐
+ achieve better failover performance.) For router ports
+ connected to other logical routers, MAC bindings can be
+ known statically from the mac and networks column in the
+ Logical_Router_Port table. (Note: the flow is NOT in‐
+ stalled for the IP addresses that belong to a neighbor
+ logical router port if the current router has the op‐
tions:dynamic_neigh_routers set to true)
- For each IPv4 address A whose host is known to have Eth‐
- ernet address E on router port P, a priority-100 flow
+ For each IPv4 address A whose host is known to have Eth‐
+ ernet address E on router port P, a priority-100 flow
with match outport === P && reg0 == A has actions eth.dst
= E; next;.
- For each IPv6 address A whose host is known to have Eth‐
- ernet address E on router port P, a priority-100 flow
- with match outport === P && xxreg0 == A has actions
+ For each IPv6 address A whose host is known to have Eth‐
+ ernet address E on router port P, a priority-100 flow
+ with match outport === P && xxreg0 == A has actions
eth.dst = E; next;.
For each logical router port with an IPv4 address A and a
- mac address of E that is reachable via a different logi‐
+ mac address of E that is reachable via a different logi‐
cal router port P, a priority-100 flow with match outport
=== P && reg0 == A has actions eth.dst = E; next;.
For each logical router port with an IPv6 address A and a
- mac address of E that is reachable via a different logi‐
+ mac address of E that is reachable via a different logi‐
cal router port P, a priority-100 flow with match outport
=== P && xxreg0 == A has actions eth.dst = E; next;.
- • Static MAC bindings from NAT entries. MAC bindings can
- also be known for the entries in the NAT table. Below
- flows are programmed for distributed logical routers i.e
+ • Static MAC bindings from NAT entries. MAC bindings can
+ also be known for the entries in the NAT table. Below
+ flows are programmed for distributed logical routers i.e
with a distributed router port.
- For each row in the NAT table with IPv4 address A in the
+ For each row in the NAT table with IPv4 address A in the
external_ip column of NAT table, below two flows are pro‐
grammed:
- A priority-100 flow with the match outport == P && reg0
- == A has actions eth.dst = E; next;, where P is the dis‐
- tributed logical router port, E is the Ethernet address
- if set in the external_mac column of NAT table for of
+ A priority-100 flow with the match outport == P && reg0
+ == A has actions eth.dst = E; next;, where P is the dis‐
+ tributed logical router port, E is the Ethernet address
+ if set in the external_mac column of NAT table for of
type dnat_and_snat, otherwise the Ethernet address of the
- distributed logical router port. Note that if the exter‐
- nal_ip is not within a subnet on the owning logical
+ distributed logical router port. Note that if the exter‐
+ nal_ip is not within a subnet on the owning logical
router, then OVN will only create ARP resolution flows if
- the options:add_route is set to true. Otherwise, no ARP
+ the options:add_route is set to true. Otherwise, no ARP
resolution flows will be added.
Corresponding to the above flow, a priority-150 flow with
the match inport == P && outport == P && ip4.dst == A has
- actions drop; to exclude packets that have gone through
- DNAT/unSNAT stage but failed to convert the destination,
+ actions drop; to exclude packets that have gone through
+ DNAT/unSNAT stage but failed to convert the destination,
to avoid loop.
For IPv6 NAT entries, same flows are added, but using the
register xxreg0 and field ip6 for the match.
• If the router datapath runs a port with redirect-type set
- to bridged, for each distributed NAT rule with IP A in
- the logical_ip column and logical port P in the logi‐
+ to bridged, for each distributed NAT rule with IP A in
+ the logical_ip column and logical port P in the logi‐
cal_port column of NAT table, a priority-90 flow with the
- match outport == Q && ip.src === A && is_chassis_resi‐
- dent(P), where Q is the distributed logical router port
- and action get_arp(outport, reg0); next; for IPv4 and
+ match outport == Q && ip.src === A && is_chassis_resi‐
+ dent(P), where Q is the distributed logical router port
+ and action get_arp(outport, reg0); next; for IPv4 and
get_nd(outport, xxreg0); next; for IPv6.
- • Traffic with IP destination an address owned by the
+ • 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 un‐
- SNAT 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
+ SNAT 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 ad‐
- dresses which are also SNAT IPs. This flow has action
+ A priority-2 logical flow with match ip4.dst = {..}
+ matches on traffic destined to router owned IPv4 ad‐
+ dresses which are also SNAT IPs. This flow has action
drop;.
- A priority-2 logical flow with match ip6.dst = {..}
- matches on traffic destined to router owned IPv6 ad‐
- dresses which are also SNAT IPs. This flow has action
+ A priority-2 logical flow with match ip6.dst = {..}
+ matches on traffic destined to router owned IPv6 ad‐
+ dresses which are also SNAT IPs. This flow has action
drop;.
- A priority-0 logical that flow matches all packets not
+ A priority-0 logical that flow matches all packets not
already handled (match 1) and drops them (action drop;).
• Dynamic MAC bindings. These flows resolve MAC-to-IP bind‐
- ings 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
+ ings 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.)
- A priority-0 logical flow with match ip4 has actions
+ A priority-0 logical flow with match ip4 has actions
get_arp(outport, reg0); next;.
- A priority-0 logical flow with match ip6 has actions
+ A priority-0 logical flow with match ip6 has actions
get_nd(outport, xxreg0); next;.
- • For a distributed gateway LRP with redirect-type set to
- bridged, a priority-50 flow will match outport ==
+ • For a distributed gateway LRP with redirect-type set to
+ bridged, a priority-50 flow will match outport ==
"ROUTER_PORT" and !is_chassis_resident ("cr-ROUTER_PORT")
- has actions eth.dst = E; next;, where E is the ethernet
+ has actions eth.dst = E; next;, where E is the ethernet
address of the logical router port.
Ingress Table 18: Check packet length
- For distributed logical routers or gateway routers with gateway port
- configured with options:gateway_mtu to a valid integer value, this ta‐
- ble adds a priority-50 logical flow with the match outport == GW_PORT
- where GW_PORT is the gateway router port and applies the action
+ For distributed logical routers or gateway routers with gateway port
+ configured with options:gateway_mtu to a valid integer value, this ta‐
+ ble adds a priority-50 logical flow with the match outport == GW_PORT
+ where GW_PORT is the gateway router port and applies the action
check_pkt_larger and advances the packet to the next table.
REGBIT_PKT_LARGER = check_pkt_larger(L); next;
@@ -3298,20 +3307,20 @@ LOGICAL FLOW TABLE STRUCTURE
taken from options:gateway_mtu column of Logical_Router_Port row.
If the port is also configured with options:gateway_mtu_bypass then an‐
- other flow is added, with priority-55, to bypass the check_pkt_larger
+ other 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
+ This table adds one priority-0 fallback flow that matches all packets
and advances to the next table.
Ingress Table 19: Handle larger packets
- For distributed logical routers or gateway routers with gateway port
- configured with options:gateway_mtu to a valid integer value, this ta‐
- ble adds the following priority-150 logical flow for each logical
- router port with the match inport == LRP && outport == GW_PORT && REG‐
- BIT_PKT_LARGER && !REGBIT_EGRESS_LOOPBACK, where LRP is the logical
- router port and GW_PORT is the gateway port and applies the following
+ For distributed logical routers or gateway routers with gateway port
+ configured with options:gateway_mtu to a valid integer value, this ta‐
+ ble adds the following priority-150 logical flow for each logical
+ router port with the match inport == LRP && outport == GW_PORT && REG‐
+ BIT_PKT_LARGER && !REGBIT_EGRESS_LOOPBACK, where LRP is the logical
+ router port and GW_PORT is the gateway port and applies the following
action for ipv4 and ipv6 respectively:
icmp4 {
@@ -3340,66 +3349,66 @@ LOGICAL FLOW TABLE STRUCTURE
};
- • Where M is the (fragment MTU - 58) whose value is taken
- from options:gateway_mtu column of Logical_Router_Port
+ • Where M is the (fragment MTU - 58) whose value is taken
+ from options:gateway_mtu column of Logical_Router_Port
row.
• E is the Ethernet address of the logical router port.
• I is the IPv4/IPv6 address of the logical router port.
- This table adds one priority-0 fallback flow that matches all packets
+ This table adds one priority-0 fallback flow that matches all packets
and advances to the next table.
Ingress Table 20: Gateway Redirect
For distributed logical routers where one or more of the logical router
ports specifies a gateway chassis, this table redirects certain packets
- to the distributed gateway port instances on the gateway chassises.
+ to the distributed gateway port instances on the gateway chassises.
This table has the following flows:
- • For all the configured load balancing rules that include
+ • For all the configured load balancing rules that include
an IPv4 address VIP, and a list of IPv4 backend addresses
- B0, B1 .. Bn defined for the VIP a priority-200 flow is
+ B0, B1 .. Bn defined for the VIP a priority-200 flow is
added that matches ip4 && (ip4.src == B0 || ip4.src == B1
- || ... || ip4.src == Bn) with an action outport = CR;
- next; where CR is the chassisredirect port representing
- the instance of the logical router distributed gateway
- port on the gateway chassis. If the backend IPv4 address
- Bx is also configured with L4 port PORT of protocol P,
+ || ... || ip4.src == Bn) with an action outport = CR;
+ next; where CR is the chassisredirect port representing
+ the instance of the logical router distributed gateway
+ port on the gateway chassis. If the backend IPv4 address
+ Bx is also configured with L4 port PORT of protocol P,
then the match also includes P.src == PORT. Similar flows
are added for IPv6.
• For each NAT rule in the OVN Northbound database that can
- be handled in a distributed manner, a priority-100 logi‐
- cal flow with match ip4.src == B && outport == GW &&
+ be handled in a distributed manner, a priority-100 logi‐
+ cal flow with match ip4.src == B && outport == GW &&
is_chassis_resident(P), where GW is the distributed gate‐
way port specified in the NAT rule and P is the NAT logi‐
cal port. IP traffic matching the above rule will be man‐
- aged locally setting reg1 to C and eth.src to D, where C
+ aged locally setting reg1 to C and eth.src to D, where C
is NAT external ip and D is NAT external mac.
- • For each dnat_and_snat NAT rule with stateless=true and
- allowed_ext_ips configured, a priority-75 flow is pro‐
- grammed with match ip4.dst == B and action outport = CR;
- next; where B is the NAT rule external IP and CR is the
- chassisredirect port representing the instance of the
- logical router distributed gateway port on the gateway
- chassis. Moreover a priority-70 flow is programmed with
- same match and action drop;. For each dnat_and_snat NAT
+ • For each dnat_and_snat NAT rule with stateless=true and
+ allowed_ext_ips configured, a priority-75 flow is pro‐
+ grammed with match ip4.dst == B and action outport = CR;
+ next; where B is the NAT rule external IP and CR is the
+ chassisredirect port representing the instance of the
+ logical router distributed gateway port on the gateway
+ chassis. Moreover a priority-70 flow is programmed with
+ same match and action drop;. For each dnat_and_snat NAT
rule with stateless=true and exempted_ext_ips configured,
- a priority-75 flow is programmed with match ip4.dst == B
- and action drop; where B is the NAT rule external IP. A
+ a priority-75 flow is programmed with match ip4.dst == B
+ and action drop; where B is the NAT rule external IP. A
similar flow is added for IPv6 traffic.
• For each NAT rule in the OVN Northbound database that can
be handled in a distributed manner, a priority-80 logical
- flow with drop action if the NAT logical port is a vir‐
+ flow with drop action if the NAT logical port is a vir‐
tual port not claimed by any chassis yet.
- • A priority-50 logical flow with match outport == GW has
- actions outport = CR; next;, where GW is the logical
- router distributed gateway port and CR is the chas‐
+ • A priority-50 logical flow with match outport == GW has
+ actions outport = CR; next;, where GW is the logical
+ router distributed gateway port and CR is the chas‐
sisredirect port representing the instance of the logical
router distributed gateway port on the gateway chassis.
@@ -3407,8 +3416,8 @@ LOGICAL FLOW TABLE STRUCTURE
Ingress Table 21: ARP Request
- In the common case where the Ethernet destination has been resolved,
- this table outputs the packet. Otherwise, it composes and sends an ARP
+ In the common case where the Ethernet destination has been resolved,
+ this table outputs the packet. Otherwise, it composes and sends an ARP
or IPv6 Neighbor Solicitation request. It holds the following flows:
• Unknown MAC address. A priority-100 flow for IPv4 packets
@@ -3424,10 +3433,10 @@ LOGICAL FLOW TABLE STRUCTURE
};
- Unknown MAC address. For each IPv6 static route associ‐
- ated with the router with the nexthop IP: G, a prior‐
- ity-200 flow for IPv6 packets with match eth.dst ==
- 00:00:00:00:00:00 && xxreg0 == G with the following ac‐
+ Unknown MAC address. For each IPv6 static route associ‐
+ ated with the router with the nexthop IP: G, a prior‐
+ ity-200 flow for IPv6 packets with match eth.dst ==
+ 00:00:00:00:00:00 && xxreg0 == G with the following ac‐
tions is added:
nd_ns {
@@ -3439,7 +3448,7 @@ LOGICAL FLOW TABLE STRUCTURE
Where E is the multicast mac derived from the Gateway IP,
- I is the solicited-node multicast address corresponding
+ I is the solicited-node multicast address corresponding
to the target address G.
Unknown MAC address. A priority-100 flow for IPv6 packets
@@ -3452,11 +3461,11 @@ LOGICAL FLOW TABLE STRUCTURE
};
- (Ingress table IP Routing initialized reg1 with the IP
- address owned by outport and (xx)reg0 with the next-hop
+ (Ingress table IP Routing 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
+ The IP packet that triggers the ARP/IPv6 NS request is
dropped.
• Known MAC address. A priority-0 flow with match 1 has ac‐
@@ -3464,20 +3473,20 @@ LOGICAL FLOW TABLE STRUCTURE
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
+ 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.
- • A priority-0 logical flow with match 1 has actions REG‐
+ • A priority-0 logical flow with match 1 has actions REG‐
BIT_DST_NAT_IP_LOCAL = 0; next;.
Egress Table 1: UNDNAT
- This is for already established connections’ reverse traffic. i.e.,
- DNAT has already been done in ingress pipeline and now the packet has
- entered the egress pipeline as part of a reply. This traffic is unD‐
+ This is for already established connections’ reverse traffic. i.e.,
+ DNAT has already been done in ingress pipeline and now the packet has
+ entered the egress pipeline as part of a reply. This traffic is unD‐
NATed here.
• A priority-0 logical flow with match 1 has actions next;.
@@ -3487,177 +3496,177 @@ LOGICAL FLOW TABLE STRUCTURE
• For IPv6 Neighbor Discovery or Router Solicitation/Adver‐
tisement traffic, a priority-100 flow with action next;.
- • For all IP packets, a priority-50 flow with an action
+ • For all IP packets, a priority-50 flow with an action
flags.loopback = 1; ct_dnat;.
Egress Table 1: UNDNAT on Distributed Routers
- • For all the configured load balancing rules for a router
- with gateway port in OVN_Northbound database that in‐
- cludes an IPv4 address VIP, for every backend IPv4 ad‐
- dress B defined for the VIP a priority-120 flow is pro‐
- grammed on gateway chassis that matches ip && ip4.src ==
- B && outport == GW, where GW is the logical router gate‐
+ • For all the configured load balancing rules for a router
+ with gateway port in OVN_Northbound database that in‐
+ cludes an IPv4 address VIP, for every backend IPv4 ad‐
+ dress B defined for the VIP a priority-120 flow is pro‐
+ grammed on gateway chassis that matches ip && ip4.src ==
+ B && outport == GW, where GW is the logical router gate‐
way port with an action ct_dnat;. If the backend IPv4 ad‐
- dress B is also configured with L4 port PORT of protocol
- P, then the match also includes P.src == PORT. These
+ dress B is also configured with L4 port PORT of protocol
+ P, then the match also includes P.src == PORT. These
flows are not added for load balancers with IPv6 VIPs.
- If the router is configured to force SNAT any load-bal‐
- anced packets, above action will be replaced by
+ If the router is configured to force SNAT any load-bal‐
+ anced packets, above action will be replaced by
flags.force_snat_for_lb = 1; ct_dnat;.
- • For each configuration in the OVN Northbound database
- that asks to change the destination IP address of a
- packet from an IP address of A to B, a priority-100 flow
- matches ip && ip4.src == B && outport == GW, where GW is
+ • For each configuration in the OVN Northbound database
+ that asks to change the destination IP address of a
+ packet from an IP address of A to B, a priority-100 flow
+ matches ip && ip4.src == B && outport == GW, where GW is
the logical router gateway port, with an action ct_dnat;.
- If the NAT rule is of type dnat_and_snat and has state‐
+ If the NAT rule is of type dnat_and_snat and has state‐
less=true in the options, then the action would be next;.
- If the NAT rule cannot be handled in a distributed man‐
- ner, then the priority-100 flow above is only programmed
+ If the NAT rule cannot be handled in a distributed man‐
+ ner, then the priority-100 flow above is only programmed
on the gateway chassis with the action ct_dnat.
- If the NAT rule can be handled in a distributed manner,
- then there is an additional action eth.src = EA;, where
+ If the NAT rule can be handled in a distributed manner,
+ then there is an additional action eth.src = EA;, where
EA is the ethernet address associated with the IP address
- A in the NAT rule. This allows upstream MAC learning to
+ A in the NAT rule. This allows upstream MAC learning to
point to the correct chassis.
Egress Table 2: Post UNDNAT
- • A priority-70 logical flow is added that initiates CT
+ • A priority-70 logical flow is added that initiates CT
state for traffic that is configured to be SNATed on Dis‐
tributed routers. This allows the next table,
lr_out_snat, to effectively match on various CT states.
- • A priority-50 logical flow is added that commits any un‐
- tracked flows from the previous table lr_out_undnat for
- Gateway routers. This flow matches on ct.new && ip with
+ • A priority-50 logical flow is added that commits any un‐
+ tracked flows from the previous table lr_out_undnat for
+ Gateway routers. This flow matches on ct.new && ip with
action ct_commit { } ; next; .
• A priority-0 logical flow with match 1 has actions next;.
Egress Table 3: SNAT
- Packets that are configured to be SNATed get their source IP address
+ Packets that are configured to be SNATed get their source IP address
changed based on the configuration in the OVN Northbound database.
- • A priority-120 flow to advance the IPv6 Neighbor solici‐
- tation packet to next table to skip SNAT. In the case
- where ovn-controller injects an IPv6 Neighbor Solicita‐
- tion packet (for nd_ns action) we don’t want the packet
+ • A priority-120 flow to advance the IPv6 Neighbor solici‐
+ tation packet to next table to skip SNAT. In the case
+ where ovn-controller injects an IPv6 Neighbor Solicita‐
+ tion packet (for nd_ns action) we don’t want the packet
to go through conntrack.
Egress Table 3: SNAT on Gateway Routers
- • If the Gateway router in the OVN Northbound database has
- been configured to force SNAT a packet (that has been
- previously DNATted) to B, a priority-100 flow matches
- flags.force_snat_for_dnat == 1 && ip with an action
+ • If the Gateway router in the OVN Northbound database has
+ been configured to force SNAT a packet (that has been
+ previously DNATted) to B, a priority-100 flow matches
+ flags.force_snat_for_dnat == 1 && ip with an action
ct_snat(B);.
- • If a load balancer configured to skip snat has been ap‐
+ • If a load balancer configured to skip snat has been ap‐
plied to the Gateway router pipeline, a priority-120 flow
- matches flags.skip_snat_for_lb == 1 && ip with an action
+ matches flags.skip_snat_for_lb == 1 && ip with an action
next;.
- • If the Gateway router in the OVN Northbound database has
- been configured to force SNAT a packet (that has been
- previously load-balanced) using router IP (i.e op‐
- tions:lb_force_snat_ip=router_ip), then for each logical
- router port P attached to the Gateway router, a prior‐
+ • If the Gateway router in the OVN Northbound database has
+ been configured to force SNAT a packet (that has been
+ previously load-balanced) using router IP (i.e op‐
+ tions:lb_force_snat_ip=router_ip), then for each logical
+ router port P attached to the Gateway router, a prior‐
ity-110 flow matches flags.force_snat_for_lb == 1 && out‐
port == P
- with an action ct_snat(R); where R is the IP configured
- on the router port. If R is an IPv4 address then the
+ with an action ct_snat(R); where R is the IP configured
+ on the router port. If R is an IPv4 address then the
match will also include ip4 and if it is an IPv6 address,
then the match will also include ip6.
- If the logical router port P is configured with multiple
+ If the logical router port P is configured with multiple
IPv4 and multiple IPv6 addresses, only the first IPv4 and
first IPv6 address is considered.
- • If the Gateway router in the OVN Northbound database has
- been configured to force SNAT a packet (that has been
+ • If the Gateway router in the OVN Northbound database has
+ been configured to force SNAT a packet (that has been
previously load-balanced) to B, a priority-100 flow
matches flags.force_snat_for_lb == 1 && ip with an action
ct_snat(B);.
- • For each configuration in the OVN Northbound database,
- that asks to change the source IP address of a packet
- from an IP address of A or to change the source IP ad‐
- dress of a packet that belongs to network A to B, a flow
- matches ip && ip4.src == A && (!ct.trk || !ct.rpl) with
+ • For each configuration in the OVN Northbound database,
+ that asks to change the source IP address of a packet
+ from an IP address of A or to change the source IP ad‐
+ dress of a packet that belongs to network A to B, a flow
+ matches ip && ip4.src == A && (!ct.trk || !ct.rpl) with
an action ct_snat(B);. The priority of the flow is calcu‐
- lated based on the mask of A, with matches having larger
- masks getting higher priorities. If the NAT rule is of
+ lated based on the mask of A, with matches having larger
+ masks getting higher priorities. 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).
- • If the NAT rule has allowed_ext_ips configured, then
+ • If the NAT rule has allowed_ext_ips configured, then
there is an additional match ip4.dst == allowed_ext_ips .
- Similarly, for IPV6, match would be ip6.dst == al‐
+ Similarly, for IPV6, match would be ip6.dst == al‐
lowed_ext_ips.
- • If the NAT rule has exempted_ext_ips set, then there is
+ • If the NAT rule has exempted_ext_ips set, then there is
an additional flow configured at the priority + 1 of cor‐
- responding NAT rule. The flow matches if destination ip
+ responding NAT rule. The flow matches if destination ip
is an exempted_ext_ip and the action is next; . This flow
- is used to bypass the ct_snat action for a packet which
+ is used to bypass the ct_snat action for a packet which
is destinted to exempted_ext_ips.
• A priority-0 logical flow with match 1 has actions next;.
Egress Table 3: SNAT on Distributed Routers
- • For each configuration in the OVN Northbound database,
- that asks to change the source IP address of a packet
- from an IP address of A or to change the source IP ad‐
- dress of a packet that belongs to network A to B, two
+ • For each configuration in the OVN Northbound database,
+ that asks to change the source IP address of a packet
+ from an IP address of A or to change the source IP ad‐
+ dress of a packet that belongs to network A to B, two
flows are added. The priority P of these flows are calcu‐
- lated based on the mask of A, with matches having larger
+ lated based on the mask of A, with matches having larger
masks getting higher priorities.
- If the NAT rule cannot be handled in a distributed man‐
- ner, then the below flows are only programmed on the
- gateway chassis increasing flow priority by 128 in order
+ If the NAT rule cannot be handled in a distributed man‐
+ ner, then the below flows are only programmed on the
+ gateway chassis increasing flow priority by 128 in order
to be run first.
• The first flow is added with the calculated prior‐
- ity P and match ip && ip4.src == A && outport ==
- GW, where GW is the logical router gateway port,
+ ity 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 NAT rule is of type dnat_and_snat and
has stateless=true in the options, then the action
would be ip4/6.src=(B).
- If the NAT rule can be handled in a distributed manner,
- then there is an additional action (for both the flows)
- eth.src = EA;, where EA is the ethernet address associ‐
- ated with the IP address A in the NAT rule. This allows
+ If the NAT rule can be handled in a distributed manner,
+ then there is an additional action (for both the flows)
+ eth.src = EA;, where EA is the ethernet address associ‐
+ ated with the IP address A in the NAT rule. This allows
upstream MAC learning to point to the correct chassis.
- If the NAT rule has allowed_ext_ips configured, then
+ If the NAT rule has allowed_ext_ips configured, then
there is an additional match ip4.dst == allowed_ext_ips .
- Similarly, for IPV6, match would be ip6.dst == al‐
+ Similarly, for IPV6, match would be ip6.dst == al‐
lowed_ext_ips.
- If the NAT rule has exempted_ext_ips set, then there is
- an additional flow configured at the priority P + 2 of
- corresponding NAT rule. The flow matches if destination
- ip is an exempted_ext_ip and the action is next; . This
- flow is used to bypass the ct_snat action for a flow
+ If the NAT rule has exempted_ext_ips set, then there is
+ an additional flow configured at the priority P + 2 of
+ corresponding NAT rule. The flow matches if destination
+ ip is an exempted_ext_ip and the action is next; . This
+ flow is used to bypass the ct_snat action for a flow
which is destinted to exempted_ext_ips.
- • An additional flow is added for traffic that goes in op‐
- posite direction (i.e. it enters a network with config‐
- ured SNAT). Where the flow above matched on ip4.src == A
- && outport == GW, this flow matches on ip4.dst == A &&
+ • An additional flow is added for traffic that goes in op‐
+ posite direction (i.e. it enters a network with config‐
+ ured SNAT). Where the flow above matched on ip4.src == A
+ && outport == GW, this flow matches on ip4.dst == A &&
inport == GW. A CT state is initiated for this traffic so
- that the following table, lr_out_post_snat, can identify
- whether the traffic flow was initiated from the internal
+ that the following table, lr_out_post_snat, can identify
+ whether the traffic flow was initiated from the internal
or external network.
• A priority-0 logical flow with match 1 has actions next;.
@@ -3667,40 +3676,40 @@ LOGICAL FLOW TABLE STRUCTURE
Packets reaching this table are processed according to the flows below:
• Traffic that goes directly into a network configured with
- SNAT on Distributed 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
+ SNAT on Distributed 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".
- • A priority-0 logical flow that matches all packets not
+ • A priority-0 logical flow that matches all packets not
already handled (match 1) and action next;.
Egress Table 5: Egress Loopback
- For distributed logical routers where one of the logical router ports
+ For distributed logical routers where one of the logical router ports
specifies a gateway chassis.
- While UNDNAT and SNAT processing have already occurred by this point,
- this traffic needs to be forced through egress loopback on this dis‐
+ While UNDNAT and SNAT processing have already occurred by this point,
+ this traffic needs to be forced through egress loopback on this dis‐
tributed gateway port instance, in order for UNSNAT and DNAT processing
- to be applied, and also for IP routing and ARP resolution after all of
+ to be applied, and also for IP routing and ARP resolution after all of
the NAT processing, so that the packet can be forwarded to the destina‐
tion.
This table has the following flows:
- • For each NAT rule in the OVN Northbound database on a
- distributed router, a priority-100 logical flow with
- match ip4.dst == E && outport == GW && is_chassis_resi‐
- dent(P), where E is the external IP address specified in
- the NAT rule, GW is the distributed gateway port corre‐
- sponding to the NAT rule (specified or inferred). For
- dnat_and_snat NAT rule, P is the logical port specified
- in the NAT rule. If logical_port column of NAT table is
- NOT set, then P is the chassisredirect port of GW with
+ • For each NAT rule in the OVN Northbound database on a
+ distributed router, a priority-100 logical flow with
+ match ip4.dst == E && outport == GW && is_chassis_resi‐
+ dent(P), where E is the external IP address specified in
+ the NAT rule, GW is the distributed gateway port corre‐
+ sponding to the NAT rule (specified or inferred). For
+ dnat_and_snat NAT rule, P is the logical port specified
+ in the NAT rule. If logical_port column of NAT table is
+ NOT set, then P is the chassisredirect port of GW with
the following actions:
clone {
@@ -3718,9 +3727,9 @@ LOGICAL FLOW TABLE STRUCTURE
};
- flags.loopback is set since in_port is unchanged and the
+ flags.loopback is set since in_port is unchanged and the
packet may return back to that port after NAT processing.
- REGBIT_EGRESS_LOOPBACK is set to indicate that egress
+ REGBIT_EGRESS_LOOPBACK is set to indicate that egress
loopback has occurred, in order to skip the source IP ad‐
dress check against the router address.
@@ -3730,33 +3739,33 @@ LOGICAL FLOW TABLE STRUCTURE
Packets that reach this table are ready for delivery. It contains:
- • Priority-110 logical flows that match IP multicast pack‐
- ets on each enabled logical router port and modify the
- Ethernet source address of the packets to the Ethernet
+ • Priority-110 logical flows that match IP multicast pack‐
+ ets on each enabled logical router port and modify the
+ Ethernet source address of the packets to the Ethernet
address of the port and then execute action output;.
• Priority-100 logical flows that match packets on each en‐
abled logical router port, with action output;.
- • A priority-0 logical flow that matches all packets not
+ • A priority-0 logical flow that matches all packets not
already handled (match 1) and drops them (action drop;).
DROP SAMPLING
- As described in the previous section, there are several places where
+ As described in the previous section, there are several places where
ovn-northd might decided to drop a packet by explicitly creating a Log‐
ical_Flow with the drop; action.
When debug drop-sampling has been cofigured in the OVN Northbound data‐
- base, the ovn-northd will replace all the drop; actions with a sam‐
- ple(priority=65535, collector_set=id, obs_domain=obs_id,
+ base, the ovn-northd will replace all the drop; actions with a sam‐
+ ple(priority=65535, collector_set=id, obs_domain=obs_id,
obs_point=@cookie) action, where:
- • id is the value the debug_drop_collector_set option con‐
+ • id is the value the debug_drop_collector_set option con‐
figured in the OVN Northbound.
- • obs_id has it’s 8 most significant bits equal to the
- value of the debug_drop_domain_id option in the OVN
- Northbound and it’s 24 least significant bits equal to
+ • obs_id has it’s 8 most significant bits equal to the
+ value of the debug_drop_domain_id option in the OVN
+ Northbound and it’s 24 least significant bits equal to
the datapath’s tunnel key.
OVN 24.03.4 ovn-northd ovn-northd(8)
diff --git a/src/static/support/dist-docs-branch-24.03/ovn-sb.5.pdf b/src/static/support/dist-docs-branch-24.03/ovn-sb.5.pdf
index 9fc66a3..692e680 100644
Binary files a/src/static/support/dist-docs-branch-24.03/ovn-sb.5.pdf and b/src/static/support/dist-docs-branch-24.03/ovn-sb.5.pdf differ
diff --git a/src/static/support/dist-docs-branch-24.03/ovn-sbctl.8.pdf b/src/static/support/dist-docs-branch-24.03/ovn-sbctl.8.pdf
index 1b8de84..da20702 100644
Binary files a/src/static/support/dist-docs-branch-24.03/ovn-sbctl.8.pdf and b/src/static/support/dist-docs-branch-24.03/ovn-sbctl.8.pdf differ
diff --git a/src/static/support/dist-docs-branch-24.03/ovn-trace.8.pdf b/src/static/support/dist-docs-branch-24.03/ovn-trace.8.pdf
index 58205c5..2c77e2a 100644
Binary files a/src/static/support/dist-docs-branch-24.03/ovn-trace.8.pdf and b/src/static/support/dist-docs-branch-24.03/ovn-trace.8.pdf differ