1 <?xml version="1.0" encoding="utf-8"?>
2 <manpage program="ovn-northd" section="8" title="ovn-northd">
4 <p>ovn-northd -- Open Virtual Network central control daemon</p>
7 <p><code>ovn-northd</code> [<var>options</var>]</p>
11 <code>ovn-northd</code> is a centralized daemon responsible for
12 translating the high-level OVN configuration into logical
13 configuration consumable by daemons such as
14 <code>ovn-controller</code>. It translates the logical network
15 configuration in terms of conventional network concepts, taken
16 from the OVN Northbound Database (see <code>ovn-nb</code>(5)),
17 into logical datapath flows in the OVN Southbound Database (see
18 <code>ovn-sb</code>(5)) below it.
21 <h1>Configuration</h1>
23 <code>ovn-northd</code> requires a connection to the Northbound
24 and Southbound databases. The defaults are <code>ovnnb_db.sock</code>
25 and <code>ovnsb_db.sock</code> respectively
26 in the local Open vSwitch's "run" directory. This may be
27 overridden with the following commands:
32 <code>--ovnnb-db=<var>database</var></code>
35 The database containing the OVN Northbound Database.
40 <code>--ovnsb-db=<var>database</var></code>
43 The database containing the OVN Southbound Database.
48 The <var>database</var> argument must take one of the following forms:
53 <code>ssl:<var>ip</var>:<var>port</var></code>
56 The specified SSL <var>port</var> on the host at the given
57 <var>ip</var>, which must be expressed as an IP address (not a DNS
58 name) in IPv4 or IPv6 address format. If <var>ip</var> is an IPv6
59 address, then wrap <var>ip</var> with square brackets, e.g.:
60 <code>ssl:[::1]:6640</code>. The <code>--private-key</code>,
61 <code>--certificate</code>, and <code>--ca-cert</code> options are
62 mandatory when this form is used.
67 <code>tcp:<var>ip</var>:<var>port</var></code>
70 Connect to the given TCP <var>port</var> on <var>ip</var>, where
71 <var>ip</var> can be IPv4 or IPv6 address. If <var>ip</var> is an
72 IPv6 address, then wrap <var>ip</var> with square brackets, e.g.:
73 <code>tcp:[::1]:6640</code>.
78 <code>unix:<var>file</var></code>
81 On POSIX, connect to the Unix domain server socket named
85 On Windows, connect to a localhost TCP port whose value is written
91 <h1>Runtime Management Commands</h1>
93 <code>ovs-appctl</code> can send commands to a running
94 <code>ovn-northd</code> process. The currently supported commands
97 <dt><code>exit</code></dt>
99 Causes <code>ovn-northd</code> to gracefully terminate.
104 <h1>Logical Flow Table Structure</h1>
107 One of the main purposes of <code>ovn-northd</code> is to populate the
108 <code>Logical_Flow</code> table in the <code>OVN_Southbound</code>
109 database. This section describes how <code>ovn-northd</code> does this
110 for switch and router logical datapaths.
113 <h2>Logical Switch Datapaths</h2>
115 <h3>Ingress Table 0: Admission Control and Ingress Port Security - L2</h3>
118 Ingress table 0 contains these logical flows:
123 Priority 100 flows to drop packets with VLAN tags or multicast Ethernet
128 Priority 50 flows that implement ingress port security for each enabled
129 logical port. For logical ports on which port security is enabled,
130 these match the <code>inport</code> and the valid <code>eth.src</code>
131 address(es) and advance only those packets to the next flow table. For
132 logical ports on which port security is not enabled, these advance all
133 packets that match the <code>inport</code>.
138 There are no flows for disabled logical ports because the default-drop
139 behavior of logical flow tables causes packets that ingress from them to
143 <h3>Ingress Table 1: Ingress Port Security - IP</h3>
146 Ingress table 1 contains these logical flows:
152 For each element in the port security set having one or more IPv4 or
153 IPv6 addresses (or both),
158 Priority 90 flow to allow IPv4 traffic if it has IPv4 addresses
159 which match the <code>inport</code>, valid <code>eth.src</code>
160 and valid <code>ip4.src</code> address(es).
164 Priority 90 flow to allow IPv4 DHCP discovery traffic if it has a
165 valid <code>eth.src</code>. This is necessary since DHCP discovery
166 messages are sent from the unspecified IPv4 address (0.0.0.0) since
167 the IPv4 address has not yet been assigned.
171 Priority 90 flow to allow IPv6 traffic if it has IPv6 addresses
172 which match the <code>inport</code>, valid <code>eth.src</code> and
173 valid <code>ip6.src</code> address(es).
177 Priority 90 flow to allow IPv6 DAD (Duplicate Address Detection)
178 traffic if it has a valid <code>eth.src</code>. This is is
179 necessary since DAD include requires joining an multicast group and
180 sending neighbor solicitations for the newly assigned address. Since
181 no address is yet assigned, these are sent from the unspecified
186 Priority 80 flow to drop IP (both IPv4 and IPv6) traffic which
187 match the <code>inport</code> and valid <code>eth.src</code>.
193 One priority-0 fallback flow that matches all packets and advances to
198 <h3>Ingress Table 2: Ingress Port Security - Neighbor discovery</h3>
201 Ingress table 2 contains these logical flows:
207 For each element in the port security set,
212 Priority 90 flow to allow ARP traffic which match the
213 <code>inport</code> and valid <code>eth.src</code> and
214 <code>arp.sha</code>. If the element has one or more
215 IPv4 addresses, then it also matches the valid
216 <code>arp.spa</code>.
220 Priority 90 flow to allow IPv6 Neighbor Solicitation and
221 Advertisement traffic which match the <code>inport</code>,
222 valid <code>eth.src</code> and
223 <code>nd.sll</code>/<code>nd.tll</code>.
224 If the element has one or more IPv6 addresses, then it also
225 matches the valid <code>nd.target</code> address(es) for Neighbor
226 Advertisement traffic.
230 Priority 80 flow to drop ARP and IPv6 Neighbor Solicitation and
231 Advertisement traffic which match the <code>inport</code> and
232 valid <code>eth.src</code>.
238 One priority-0 fallback flow that matches all packets and advances to
243 <h3>Ingress Table 3: <code>from-lport</code> Pre-ACLs</h3>
246 This table prepares flows for possible stateful ACL processing in
247 ingress table <code>ACLs</code>. It contains a priority-0 flow that
248 simply moves traffic to the next table. If stateful ACLs are used in the
249 logical datapath, a priority-100 flow is added that sets a hint
250 (with <code>reg0[0] = 1; next;</code>) for table
251 <code>Pre-stateful</code> to send IP packets to the connection tracker
252 before eventually advancing to ingress table <code>ACLs</code>.
255 <h3>Ingress Table 4: Pre-LB</h3>
258 This table prepares flows for possible stateful load balancing processing
259 in ingress table <code>LB</code> and <code>Stateful</code>. It contains
260 a priority-0 flow that simply moves traffic to the next table. If load
261 balancing rules with virtual IP addresses (and ports) are configured in
262 <code>OVN_Northbound</code> database for a logical datapath, a
263 priority-100 flow is added for each configured virtual IP address
264 <var>VIP</var> with a match <code>ip && ip4.dst == <var>VIP</var>
265 </code> that sets an action <code>reg0[0] = 1; next;</code> to act as a
266 hint for table <code>Pre-stateful</code> to send IP packets to the
267 connection tracker for packet de-fragmentation before eventually
268 advancing to ingress table <code>LB</code>.
271 <h3>Ingress Table 5: Pre-stateful</h3>
274 This table prepares flows for all possible stateful processing
275 in next tables. It contains a priority-0 flow that simply moves
276 traffic to the next table. A priority-100 flow sends the packets to
277 connection tracker based on a hint provided by the previous tables
278 (with a match for <code>reg0[0] == 1</code>) by using the
279 <code>ct_next;</code> action.
282 <h3>Ingress table 6: <code>from-lport</code> ACLs</h3>
285 Logical flows in this table closely reproduce those in the
286 <code>ACL</code> table in the <code>OVN_Northbound</code> database
287 for the <code>from-lport</code> direction. The <code>priority</code>
288 values from the <code>ACL</code> table have a limited range and have
289 1000 added to them to leave room for OVN default flows at both
290 higher and lower priorities.
294 <code>allow</code> ACLs translate into logical flows with
295 the <code>next;</code> action. If there are any stateful ACLs
296 on this datapath, then <code>allow</code> ACLs translate to
297 <code>ct_commit; next;</code> (which acts as a hint for the next tables
298 to commit the connection to conntrack),
301 <code>allow-related</code> ACLs translate into logical
302 flows with the <code>ct_commit(ct_label=0/1); next;</code> actions
303 for new connections and <code>reg0[1] = 1; next;</code> for existing
307 Other ACLs translate to <code>drop;</code> for new or untracked
308 connections and <code>ct_commit(ct_label=1/1);</code> for known
309 connections. Setting <code>ct_label</code> marks a connection
310 as one that was previously allowed, but should no longer be
311 allowed due to a policy change.
316 This table also contains a priority 0 flow with action
317 <code>next;</code>, so that ACLs allow packets by default. If the
318 logical datapath has a statetful ACL, the following flows will
324 A priority-1 flow that sets the hint to commit IP traffic to the
325 connection tracker (with action <code>reg0[1] = 1; next;</code>). This
326 is needed for the default allow policy because, while the initiator's
327 direction may not have any stateful rules, the server's may and then
328 its return traffic would not be known and marked as invalid.
332 A priority-65535 flow that allows any traffic in the reply
333 direction for a connection that has been committed to the
334 connection tracker (i.e., established flows), as long as
335 the committed flow does not have <code>ct_label[0]</code> set.
336 We only handle traffic in the reply direction here because
337 we want all packets going in the request direction to still
338 go through the flows that implement the currently defined
339 policy based on ACLs. If a connection is no longer allowed by
340 policy, <code>ct_label[0]</code> will get set and packets in the
341 reply direction will no longer be allowed, either.
345 A priority-65535 flow that allows any traffic that is considered
346 related to a committed flow in the connection tracker (e.g., an
347 ICMP Port Unreachable from a non-listening UDP port), as long
348 as the committed flow does not have <code>ct_label[0]</code> set.
352 A priority-65535 flow that drops all traffic marked by the
353 connection tracker as invalid.
357 A priority-65535 flow that drops all trafic in the reply direction
358 with <code>ct_label[0]</code> set meaning that the connection
359 should no longer be allowed due to a policy change. Packets
360 in the request direction are skipped here to let a newly created
361 ACL re-allow this connection.
365 <h3>Ingress Table 7: LB</h3>
368 It contains a priority-0 flow that simply moves traffic to the next
369 table. For established connections a priority 100 flow matches on
370 <code>ct.est && !ct.rel && !ct.new &&
371 !ct.inv</code> and sets an action <code>reg0[2] = 1; next;</code> to act
372 as a hint for table <code>Stateful</code> to send packets through
373 connection tracker to NAT the packets. (The packet will automatically
374 get DNATed to the same IP address as the first packet in that
378 <h3>Ingress Table 8: Stateful</h3>
382 For all the configured load balancing rules in
383 <code>OVN_Northbound</code> database that includes a L4 port
384 <var>PORT</var> of protocol <var>P</var> and IPv4 address
385 <var>VIP</var>, a priority-120 flow that matches on
386 <code>ct.new && ip && ip4.dst == <var>VIP
387 </var>&& <var>P</var> && <var>P</var>.dst == <var>PORT
388 </var></code> with an action of <code>ct_lb(<var>args</var>)</code>,
389 where <var>args</var> contains comma separated IPv4 addresses (and
390 optional port numbers) to load balance to.
393 For all the configured load balancing rules in
394 <code>OVN_Northbound</code> database that includes just an IP address
395 <var>VIP</var> to match on, a priority-110 flow that matches on
396 <code>ct.new && ip && ip4.dst == <var>VIP</var></code>
397 with an action of <code>ct_lb(<var>args</var>)</code>, where
398 <var>args</var> contains comma separated IPv4 addresses.
401 A priority-100 flow commits packets to connection tracker using
402 <code>ct_commit; next;</code> action based on a hint provided by
403 the previous tables (with a match for <code>reg0[1] == 1</code>).
406 A priority-100 flow sends the packets to connection tracker using
407 <code>ct_lb;</code> as the action based on a hint provided by the
408 previous tables (with a match for <code>reg0[2] == 1</code>).
411 A priority-0 flow that simply moves traffic to the next table.
415 <h3>Ingress Table 9: ARP responder</h3>
418 This table implements ARP responder for known IPs. It contains these
424 Priority-100 flows to skip ARP responder if inport is of type
425 <code>localnet</code>, and advances directly to the next table.
430 Priority-50 flows that matches ARP requests to each known IP address
431 <var>A</var> of logical port <var>P</var>, and respond with ARP
432 replies directly with corresponding Ethernet address <var>E</var>:
437 eth.src = <var>E</var>;
438 arp.op = 2; /* ARP reply. */
440 arp.sha = <var>E</var>;
442 arp.spa = <var>A</var>;
443 outport = <var>P</var>;
444 inport = ""; /* Allow sending out inport. */
449 These flows are omitted for logical ports (other than router ports)
455 One priority-0 fallback flow that matches all packets and advances to
460 <h3>Ingress Table 10: DHCP option processing</h3>
463 This table adds the DHCPv4 options to a DHCPv4 packet from the
464 logical ports configured with IPv4 address(es) and DHCPv4 options.
470 A priority-100 logical flow is added for these logical ports
471 which matches the IPv4 packet with <code>udp.src</code> = 68 and
472 <code>udp.dst</code> = 67 and applies the action
473 <code>put_dhcp_opts</code> and advances the packet to the next table.
477 reg0[3] = put_dhcp_opts(offer_ip = <var>O</var>, <i>options</i>...);
482 For DHCPDISCOVER and DHCPREQUEST, this transforms the packet into a
483 DHCP reply, adds the DHCP offer IP <var>O</var> and options to the
484 packet, and stores 1 into reg0[3]. For other kinds of packets, it
485 just stores 0 into reg0[3]. Either way, it continues to the next
492 A priority-0 flow that matches all packets to advances to table 11.
496 <h3>Ingress Table 11: DHCP responses</h3>
499 This table implements DHCP responder for the DHCP replies generated by
506 A priority 100 logical flow is added for the logical ports configured
507 with DHCPv4 options which matches IPv4 packets with <code>udp.src == 68
508 && udp.dst == 67 && reg0[3] == 1</code> and
509 responds back to the <code>inport</code> after applying these
510 actions. If <code>reg0[3]</code> is set to 1, it means that the
511 action <code>put_dhcp_opts</code> was successful.
516 eth.src = <var>E</var>;
517 ip4.dst = <var>O</var>;
518 ip4.src = <var>S</var>;
521 outport = <var>P</var>;
522 inport = ""; /* Allow sending out inport. */
527 where <var>E</var> is the server MAC address and <var>S</var> is the
528 server IPv4 address defined in the DHCPv4 options and <var>O</var> is
529 the IPv4 address defined in the logical port's addresses column.
533 (This terminates ingress packet processing; the packet does not go
534 to the next ingress table.)
539 A priority-0 flow that matches all packets to advances to table 12.
543 <h3>Ingress Table 12: Destination Lookup</h3>
546 This table implements switching behavior. It contains these logical
552 A priority-100 flow that outputs all packets with an Ethernet broadcast
553 or multicast <code>eth.dst</code> to the <code>MC_FLOOD</code>
554 multicast group, which <code>ovn-northd</code> populates with all
555 enabled logical ports.
559 One priority-50 flow that matches each known Ethernet address against
560 <code>eth.dst</code> and outputs the packet to the single associated
565 One priority-0 fallback flow that matches all packets and outputs them
566 to the <code>MC_UNKNOWN</code> multicast group, which
567 <code>ovn-northd</code> populates with all enabled logical ports that
568 accept unknown destination packets. As a small optimization, if no
569 logical ports accept unknown destination packets,
570 <code>ovn-northd</code> omits this multicast group and logical flow.
574 <h3>Egress Table 0: Pre-LB</h3>
577 This table is similar to ingress table <code>Pre-LB</code>. It
578 contains a priority-0 flow that simply moves traffic to the next table.
579 If any load balancing rules exist for the datapath, a priority-100 flow
580 is added with a match of <code>ip</code> and action of <code>reg0[0] = 1;
581 next;</code> to act as a hint for table <code>Pre-stateful</code> to
582 send IP packets to the connection tracker for packet de-fragmentation.
585 <h3>Egress Table 1: <code>to-lport</code> Pre-ACLs</h3>
588 This is similar to ingress table <code>Pre-ACLs</code> except for
589 <code>to-lport</code> traffic.
592 <h3>Egress Table 2: Pre-stateful</h3>
595 This is similar to ingress table <code>Pre-stateful</code>.
598 <h3>Egress Table 3: LB</h3>
600 This is similar to ingress table <code>LB</code>.
603 <h3>Egress Table 4: <code>to-lport</code> ACLs</h3>
606 This is similar to ingress table <code>ACLs</code> except for
607 <code>to-lport</code> ACLs.
610 <h3>Egress Table 5: Stateful</h3>
613 This is similar to ingress table <code>Stateful</code> except that
614 there are no rules added for load balancing new connections.
618 Also a priority 34000 logical flow is added for each logical port which
619 has DHCPv4 options defined to allow the DHCPv4 reply packet from the
620 <code>Ingress Table 11: DHCP responses</code>.
623 <h3>Egress Table 6: Egress Port Security - IP</h3>
626 This is similar to the port security logic in table
627 <code>Ingress Port Security - IP</code> except that <code>outport</code>,
628 <code>eth.dst</code>, <code>ip4.dst</code> and <code>ip6.dst</code>
629 are checked instead of <code>inport</code>, <code>eth.src</code>,
630 <code>ip4.src</code> and <code>ip6.src</code>
633 <h3>Egress Table 7: Egress Port Security - L2</h3>
636 This is similar to the ingress port security logic in ingress table
637 <code>Admission Control and Ingress Port Security - L2</code>,
638 but with important differences. Most obviously, <code>outport</code> and
639 <code>eth.dst</code> are checked instead of <code>inport</code> and
640 <code>eth.src</code>. Second, packets directed to broadcast or multicast
641 <code>eth.dst</code> are always accepted instead of being subject to the
642 port security rules; this is implemented through a priority-100 flow that
643 matches on <code>eth.mcast</code> with action <code>output;</code>.
644 Finally, to ensure that even broadcast and multicast packets are not
645 delivered to disabled logical ports, a priority-150 flow for each
646 disabled logical <code>outport</code> overrides the priority-100 flow
647 with a <code>drop;</code> action.
650 <h2>Logical Router Datapaths</h2>
653 Logical router datapaths will only exist for <ref table="Logical_Router"
654 db="OVN_Northbound"/> rows in the <ref db="OVN_Northbound"/> database
655 that do not have <ref column="enabled" table="Logical_Router"
656 db="OVN_Northbound"/> set to <code>false</code>
659 <h3>Ingress Table 0: L2 Admission Control</h3>
662 This table drops packets that the router shouldn't see at all based on
663 their Ethernet headers. It contains the following flows:
668 Priority-100 flows to drop packets with VLAN tags or multicast Ethernet
673 For each enabled router port <var>P</var> with Ethernet address
674 <var>E</var>, a priority-50 flow that matches <code>inport ==
675 <var>P</var> && (eth.mcast || eth.dst ==
676 <var>E</var></code>), with action <code>next;</code>.
681 Other packets are implicitly dropped.
684 <h3>Ingress Table 1: IP Input</h3>
687 This table is the core of the logical router datapath functionality. It
688 contains the following flows to implement very basic IP host
695 L3 admission control: A priority-100 flow drops packets that match
696 any of the following:
701 <code>ip4.src[28..31] == 0xe</code> (multicast source)
704 <code>ip4.src == 255.255.255.255</code> (broadcast source)
707 <code>ip4.src == 127.0.0.0/8 || ip4.dst == 127.0.0.0/8</code>
708 (localhost source or destination)
711 <code>ip4.src == 0.0.0.0/8 || ip4.dst == 0.0.0.0/8</code> (zero
712 network source or destination)
715 <code>ip4.src</code> is any IP address owned by the router.
718 <code>ip4.src</code> is the broadcast address of any IP network
726 ICMP echo reply. These flows reply to ICMP echo requests received
727 for the router's IP address. Let <var>A</var> be an IP address
728 owned by a router port. Then, for each <var>A</var>, a priority-90
729 flow matches on <code>ip4.dst == <var>A</var></code> and <code>
730 icmp4.type == 8 && icmp4.code == 0</code> (ICMP echo
731 request). The port of the router that receives the echo request
732 does not matter. Also, the ip.ttl of the echo request packet is not
733 checked, so it complies with RFC 1812, section 4.2.2.9. These flows
734 use the following actions:
738 ip4.dst <-> ip4.src;
741 inport = ""; /* Allow sending out inport. */
748 Reply to ARP requests.
752 These flows reply to ARP requests for the router's own IP address.
753 For each router port <var>P</var> that owns IP address <var>A</var>
754 and Ethernet address <var>E</var>, a priority-90 flow matches
755 <code>inport == <var>P</var> && arp.op == 1 &&
756 arp.tpa == <var>A</var></code> (ARP request) with the following
762 eth.src = <var>E</var>;
763 arp.op = 2; /* ARP reply. */
765 arp.sha = <var>E</var>;
767 arp.spa = <var>A</var>;
768 outport = <var>P</var>;
769 inport = ""; /* Allow sending out inport. */
776 These flows reply to ARP requests for the virtual IP addresses
777 configured in the router for DNAT. For a configured DNAT IP address
778 <var>A</var>, for each router port <var>P</var> with Ethernet
779 address <var>E</var>, a priority-90 flow matches
780 <code>inport == <var>P</var> && arp.op == 1 &&
781 arp.tpa == <var>A</var></code> (ARP request)
782 with the following actions:
787 eth.src = <var>E</var>;
788 arp.op = 2; /* ARP reply. */
790 arp.sha = <var>E</var>;
792 arp.spa = <var>A</var>;
793 outport = <var>P</var>;
794 inport = ""; /* Allow sending out inport. */
800 ARP reply handling. These flows use ARP replies to populate the
801 logical router's ARP table. A priority-90 flow with match <code>arp.op
802 == 2</code> has actions <code>put_arp(inport, arp.spa,
808 UDP port unreachable. Priority-80 flows generate ICMP port
809 unreachable messages in reply to UDP datagrams directed to the
810 router's IP address. The logical router doesn't accept any UDP
811 traffic so it always generates such a reply.
815 These flows should not match IP fragments with nonzero offset.
819 Details TBD. Not yet implemented.
825 TCP reset. Priority-80 flows generate TCP reset messages in reply to
826 TCP datagrams directed to the router's IP address. The logical
827 router doesn't accept any TCP traffic so it always generates such a
832 These flows should not match IP fragments with nonzero offset.
836 Details TBD. Not yet implemented.
842 Protocol unreachable. Priority-70 flows generate ICMP protocol
843 unreachable messages in reply to packets directed to the router's IP
844 address on IP protocols other than UDP, TCP, and ICMP.
848 These flows should not match IP fragments with nonzero offset.
852 Details TBD. Not yet implemented.
857 Drop other IP traffic to this router. These flows drop any other
858 traffic destined to an IP address of this router that is not already
859 handled by one of the flows above, which amounts to ICMP (other than
860 echo requests) and fragments with nonzero offsets. For each IP address
861 <var>A</var> owned by the router, a priority-60 flow matches
862 <code>ip4.dst == <var>A</var></code> and drops the traffic. An
863 exception is made and the above flow is not added if the router
864 port's own IP address is used to SNAT packets passing through that
870 The flows above handle all of the traffic that might be directed to the
871 router itself. The following flows (with lower priorities) handle the
872 remaining traffic, potentially for forwarding:
877 Drop Ethernet local broadcast. A priority-50 flow with match
878 <code>eth.bcast</code> drops traffic destined to the local Ethernet
879 broadcast address. By definition this traffic should not be forwarded.
884 ICMP time exceeded. For each router port <var>P</var>, whose IP
885 address is <var>A</var>, a priority-40 flow with match <code>inport
886 == <var>P</var> && ip.ttl == {0, 1} &&
887 !ip.later_frag</code> matches packets whose TTL has expired, with the
888 following actions to send an ICMP time exceeded reply:
893 icmp4.type = 11; /* Time exceeded. */
894 icmp4.code = 0; /* TTL exceeded in transit. */
896 ip4.src = <var>A</var>;
908 TTL discard. A priority-30 flow with match <code>ip.ttl == {0,
909 1}</code> and actions <code>drop;</code> drops other packets whose TTL
910 has expired, that should not receive a ICMP error reply (i.e. fragments
911 with nonzero offset).
915 Next table. A priority-0 flows match all packets that aren't already
916 handled and uses actions <code>next;</code> to feed them to the ingress
921 <h3>Ingress Table 2: UNSNAT</h3>
924 This is for already established connections' reverse traffic.
925 i.e., SNAT has already been done in egress pipeline and now the
926 packet has entered the ingress pipeline as part of a reply. It is
933 For each configuration in the OVN Northbound database, that asks
934 to change the source IP address of a packet from <var>A</var> to
935 <var>B</var>, a priority-100 flow matches <code>ip &&
936 ip4.dst == <var>B</var></code> with an action
937 <code>ct_snat; next;</code>.
941 A priority-0 logical flow with match <code>1</code> has actions
947 <h3>Ingress Table 3: DNAT</h3>
950 Packets enter the pipeline with destination IP address that needs to
951 be DNATted from a virtual IP address to a real IP address. Packets
952 in the reverse direction needs to be unDNATed.
957 For each configuration in the OVN Northbound database, that asks
958 to change the destination IP address of a packet from <var>A</var> to
959 <var>B</var>, a priority-100 flow matches <code>ip &&
960 ip4.dst == <var>A</var></code> with an action <code>inport = "";
961 ct_dnat(<var>B</var>);</code>.
965 For all IP packets of a Gateway router, a priority-50 flow with an
966 action <code>inport = ""; ct_dnat;</code>.
970 A priority-0 logical flow with match <code>1</code> has actions
976 <h3>Ingress Table 4: IP Routing</h3>
979 A packet that arrives at this table is an IP packet that should be routed
980 to the address in <code>ip4.dst</code>. This table implements IP
981 routing, setting <code>reg0</code> to the next-hop IP address (leaving
982 <code>ip4.dst</code>, the packet's final destination, unchanged) and
983 advances to the next table for ARP resolution. It also sets
984 <code>reg1</code> to the IP address owned by the selected router port
985 (which is used later in table 6 as the IP source address for an ARP
990 This table contains the following logical flows:
996 Routing table. For each route to IPv4 network <var>N</var> with
997 netmask <var>M</var>, on router port <var>P</var> with IP address
998 <var>A</var> and Ethernet
999 address <var>E</var>, a logical flow with match <code>ip4.dst ==
1000 <var>N</var>/<var>M</var></code>, whose priority is the number of
1001 1-bits in <var>M</var>, has the following actions:
1006 reg0 = <var>G</var>;
1007 reg1 = <var>A</var>;
1008 eth.src = <var>E</var>;
1009 outport = <var>P</var>;
1010 inport = ""; /* Allow sending out inport. */
1015 (Ingress table 1 already verified that <code>ip.ttl--;</code> will
1016 not yield a TTL exceeded error.)
1020 If the route has a gateway, <var>G</var> is the gateway IP address.
1021 Instead, if the route is from a configured static route, <var>G</var>
1022 is the next hop IP address. Else it is <code>ip4.dst</code>.
1028 Destination unreachable. For each router port <var>P</var>, which
1029 owns IP address <var>A</var>, a priority-0 logical flow with match
1030 <code>in_port == <var>P</var> && !ip.later_frag &&
1031 !icmp</code> has the following actions:
1036 icmp4.type = 3; /* Destination unreachable. */
1037 icmp4.code = 0; /* Network unreachable. */
1039 ip4.src = <var>A</var>;
1046 (The <code>!icmp</code> check prevents recursion if the destination
1047 unreachable message itself cannot be routed.)
1051 These flows are omitted if the logical router has a default route,
1052 that is, a route with netmask 0.0.0.0.
1057 <h3>Ingress Table 5: ARP Resolution</h3>
1060 Any packet that reaches this table is an IP packet whose next-hop IP
1061 address is in <code>reg0</code>. (<code>ip4.dst</code> is the final
1062 destination.) This table resolves the IP address in <code>reg0</code>
1063 into an output port in <code>outport</code> and an Ethernet address in
1064 <code>eth.dst</code>, using the following flows:
1070 Static MAC bindings. MAC bindings can be known statically based on
1071 data in the <code>OVN_Northbound</code> database. For router ports
1072 connected to logical switches, MAC bindings can be known statically
1073 from the <code>addresses</code> column in the
1074 <code>Logical_Switch_Port</code> table. For router ports
1075 connected to other logical routers, MAC bindings can be known
1076 statically from the <code>mac</code> and <code>networks</code>
1077 column in the <code>Logical_Router_Port</code> table.
1081 For each IP address <var>A</var> whose host is known to have Ethernet
1082 address <var>E</var> on router port <var>P</var>, a priority-100 flow
1083 with match <code>outport === <var>P</var> && reg0 ==
1084 <var>A</var></code> has actions <code>eth.dst = <var>E</var>;
1089 For each logical router port with an IP address <var>A</var> and
1090 a mac address of <var>E</var> that is reachable via a different
1091 logical router port <var>P</var>, a priority-100 flow with
1092 match <code>outport === <var>P</var> && reg0 ==
1093 <var>A</var></code> has actions <code>eth.dst = <var>E</var>;
1100 Dynamic MAC bindings. This flows resolves MAC-to-IP bindings that
1101 have become known dynamically through ARP. (The next table will
1102 issue an ARP request for cases where the binding is not yet known.)
1106 A priority-0 logical flow with match <code>1</code> has actions
1107 <code>get_arp(outport, reg0); next;</code>.
1112 <h3>Ingress Table 6: ARP Request</h3>
1115 In the common case where the Ethernet destination has been resolved, this
1116 table outputs the packet. Otherwise, it composes and sends an ARP
1117 request. It holds the following flows:
1123 Unknown MAC address. A priority-100 flow with match <code>eth.dst ==
1124 00:00:00:00:00:00</code> has the following actions:
1129 eth.dst = ff:ff:ff:ff:ff:ff;
1131 arp.op = 1; /* ARP request. */
1137 (Ingress table 4 initialized <code>reg1</code> with the IP address
1138 owned by <code>outport</code>.)
1142 The IP packet that triggers the ARP request is dropped.
1147 Known MAC address. A priority-0 flow with match <code>1</code> has
1148 actions <code>output;</code>.
1152 <h3>Egress Table 0: SNAT</h3>
1155 Packets that are configured to be SNATed get their source IP address
1156 changed based on the configuration in the OVN Northbound database.
1161 For each configuration in the OVN Northbound database, that asks
1162 to change the source IP address of a packet from an IP address of
1163 <var>A</var> or to change the source IP address of a packet that
1164 belongs to network <var>A</var> to <var>B</var>, a flow matches
1165 <code>ip && ip4.src == <var>A</var></code> with an action
1166 <code>ct_snat(<var>B</var>);</code>. The priority of the flow
1167 is calculated based on the mask of <var>A</var>, with matches
1168 having larger masks getting higher priorities.
1171 A priority-0 logical flow with match <code>1</code> has actions
1177 <h3>Egress Table 1: Delivery</h3>
1180 Packets that reach this table are ready for delivery. It contains
1181 priority-100 logical flows that match packets on each enabled logical
1182 router port, with action <code>output;</code>.