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-stateful</h3>
258 This table prepares flows for all possible stateful processing
259 in next tables. It contains a priority-0 flow that simply moves
260 traffic to the next table. A priority-100 flow sends the packets to
261 connection tracker based on a hint provided by the previous tables
262 (with a match for <code>reg0[0] == 1</code>) by using the
263 <code>ct_next;</code> action.
266 <h3>Ingress table 5: <code>from-lport</code> ACLs</h3>
269 Logical flows in this table closely reproduce those in the
270 <code>ACL</code> table in the <code>OVN_Northbound</code> database
271 for the <code>from-lport</code> direction. <code>allow</code>
272 ACLs translate into logical flows with the <code>next;</code>
273 action, <code>allow-related</code> ACLs translate into logical
274 flows with the <code>reg0[1] = 1; next;</code> actions (which acts
275 as a hint for the next tables to commit the connection to conntrack),
276 other ACLs translate to <code>drop;</code>. The <code>priority</code>
277 values from the <code>ACL</code> table have a limited range and have 1000
278 added to them to leave room for OVN default flows at both higher
279 and lower priorities.
283 This table also contains a priority 0 flow with action
284 <code>next;</code>, so that ACLs allow packets by default. If the
285 logical datapath has a statetful ACL, the following flows will
291 A priority-1 flow that sets the hint to commit IP traffic to the
292 connection tracker (with action <code>reg0[1] = 1; next;</code>). This
293 is needed for the default allow policy because, while the initiator's
294 direction may not have any stateful rules, the server's may and then
295 its return traffic would not be known and marked as invalid.
299 A priority-65535 flow that allows any traffic that has been
300 committed to the connection tracker (i.e., established flows).
304 A priority-65535 flow that allows any traffic that is considered
305 related to a committed flow in the connection tracker (e.g., an
306 ICMP Port Unreachable from a non-listening UDP port).
310 A priority-65535 flow that drops all traffic marked by the
311 connection tracker as invalid.
315 <h3>Ingress Table 6: Stateful</h3>
318 It contains a priority-0 flow that simply moves traffic to the next
319 table. A priority-100 flow commits packets to connection tracker using
320 <code>ct_commit; next;</code> action based on a hint provided by
321 the previous tables (with a match for <code>reg0[1] == 1</code>).
324 <h3>Ingress Table 7: ARP responder</h3>
327 This table implements ARP responder for known IPs. It contains these
333 Priority-100 flows to skip ARP responder if inport is of type
334 <code>localnet</code>, and advances directly to the next table.
339 Priority-50 flows that matches ARP requests to each known IP address
340 <var>A</var> of logical port <var>P</var>, and respond with ARP
341 replies directly with corresponding Ethernet address <var>E</var>:
346 eth.src = <var>E</var>;
347 arp.op = 2; /* ARP reply. */
349 arp.sha = <var>E</var>;
351 arp.spa = <var>A</var>;
352 outport = <var>P</var>;
353 inport = ""; /* Allow sending out inport. */
358 These flows are omitted for logical ports (other than router ports)
364 One priority-0 fallback flow that matches all packets and advances to
369 <h3>Ingress Table 8: Destination Lookup</h3>
372 This table implements switching behavior. It contains these logical
378 A priority-100 flow that outputs all packets with an Ethernet broadcast
379 or multicast <code>eth.dst</code> to the <code>MC_FLOOD</code>
380 multicast group, which <code>ovn-northd</code> populates with all
381 enabled logical ports.
385 One priority-50 flow that matches each known Ethernet address against
386 <code>eth.dst</code> and outputs the packet to the single associated
391 One priority-0 fallback flow that matches all packets and outputs them
392 to the <code>MC_UNKNOWN</code> multicast group, which
393 <code>ovn-northd</code> populates with all enabled logical ports that
394 accept unknown destination packets. As a small optimization, if no
395 logical ports accept unknown destination packets,
396 <code>ovn-northd</code> omits this multicast group and logical flow.
400 <h3>Egress Table 0: <code>to-lport</code> Pre-ACLs</h3>
403 This is similar to ingress table <code>Pre-ACLs</code> except for
404 <code>to-lport</code> traffic.
407 <h3>Egress Table 1: Pre-stateful</h3>
410 This is similar to ingress table <code>Pre-stateful</code>.
413 <h3>Egress Table 2: <code>to-lport</code> ACLs</h3>
416 This is similar to ingress table <code>ACLs</code> except for
417 <code>to-lport</code> ACLs.
420 <h3>Egress Table 3: Stateful</h3>
423 This is similar to ingress table <code>Stateful</code>.
426 <h3>Egress Table 4: Egress Port Security - IP</h3>
429 This is similar to the port security logic in table
430 <code>Ingress Port Security - IP</code> except that <code>outport</code>,
431 <code>eth.dst</code>, <code>ip4.dst</code> and <code>ip6.dst</code>
432 are checked instead of <code>inport</code>, <code>eth.src</code>,
433 <code>ip4.src</code> and <code>ip6.src</code>
436 <h3>Egress Table 5: Egress Port Security - L2</h3>
439 This is similar to the ingress port security logic in ingress table
440 <code>Admission Control and Ingress Port Security - L2</code>,
441 but with important differences. Most obviously, <code>outport</code> and
442 <code>eth.dst</code> are checked instead of <code>inport</code> and
443 <code>eth.src</code>. Second, packets directed to broadcast or multicast
444 <code>eth.dst</code> are always accepted instead of being subject to the
445 port security rules; this is implemented through a priority-100 flow that
446 matches on <code>eth.mcast</code> with action <code>output;</code>.
447 Finally, to ensure that even broadcast and multicast packets are not
448 delivered to disabled logical ports, a priority-150 flow for each
449 disabled logical <code>outport</code> overrides the priority-100 flow
450 with a <code>drop;</code> action.
453 <h2>Logical Router Datapaths</h2>
456 Logical router datapaths will only exist for <ref table="Logical_Router"
457 db="OVN_Northbound"/> rows in the <ref db="OVN_Northbound"/> database
458 that do not have <ref column="enabled" table="Logical_Router"
459 db="OVN_Northbound"/> set to <code>false</code>
462 <h3>Ingress Table 0: L2 Admission Control</h3>
465 This table drops packets that the router shouldn't see at all based on
466 their Ethernet headers. It contains the following flows:
471 Priority-100 flows to drop packets with VLAN tags or multicast Ethernet
476 For each enabled router port <var>P</var> with Ethernet address
477 <var>E</var>, a priority-50 flow that matches <code>inport ==
478 <var>P</var> && (eth.mcast || eth.dst ==
479 <var>E</var></code>), with action <code>next;</code>.
484 Other packets are implicitly dropped.
487 <h3>Ingress Table 1: IP Input</h3>
490 This table is the core of the logical router datapath functionality. It
491 contains the following flows to implement very basic IP host
498 L3 admission control: A priority-100 flow drops packets that match
499 any of the following:
504 <code>ip4.src[28..31] == 0xe</code> (multicast source)
507 <code>ip4.src == 255.255.255.255</code> (broadcast source)
510 <code>ip4.src == 127.0.0.0/8 || ip4.dst == 127.0.0.0/8</code>
511 (localhost source or destination)
514 <code>ip4.src == 0.0.0.0/8 || ip4.dst == 0.0.0.0/8</code> (zero
515 network source or destination)
518 <code>ip4.src</code> is any IP address owned by the router.
521 <code>ip4.src</code> is the broadcast address of any IP network
529 ICMP echo reply. These flows reply to ICMP echo requests received
530 for the router's IP address. Let <var>A</var> be an IP address
531 owned by a router port. Then, for each <var>A</var>, a priority-90
532 flow matches on <code>ip4.dst == <var>A</var></code> and <code>
533 icmp4.type == 8 && icmp4.code == 0</code> (ICMP echo
534 request). The port of the router that receives the echo request
535 does not matter. Also, the ip.ttl of the echo request packet is not
536 checked, so it complies with RFC 1812, section 4.2.2.9. These flows
537 use the following actions where <var>S</var> is the router's IP
543 ip4.src = <var>S</var>;
546 inport = ""; /* Allow sending out inport. */
553 Reply to ARP requests.
557 These flows reply to ARP requests for the router's own IP address.
558 For each router port <var>P</var> that owns IP address <var>A</var>
559 and Ethernet address <var>E</var>, a priority-90 flow matches
560 <code>inport == <var>P</var> && arp.op == 1 &&
561 arp.tpa == <var>A</var></code> (ARP request) with the following
567 eth.src = <var>E</var>;
568 arp.op = 2; /* ARP reply. */
570 arp.sha = <var>E</var>;
572 arp.spa = <var>A</var>;
573 outport = <var>P</var>;
574 inport = ""; /* Allow sending out inport. */
581 These flows reply to ARP requests for the virtual IP addresses
582 configured in the router for DNAT. For a configured DNAT IP address
583 <var>A</var>, for each router port <var>P</var> with Ethernet
584 address <var>E</var>, a priority-90 flow matches
585 <code>inport == <var>P</var> && arp.op == 1 &&
586 arp.tpa == <var>A</var></code> (ARP request)
587 with the following actions:
592 eth.src = <var>E</var>;
593 arp.op = 2; /* ARP reply. */
595 arp.sha = <var>E</var>;
597 arp.spa = <var>A</var>;
598 outport = <var>P</var>;
599 inport = ""; /* Allow sending out inport. */
605 ARP reply handling. These flows use ARP replies to populate the
606 logical router's ARP table. A priority-90 flow with match <code>arp.op
607 == 2</code> has actions <code>put_arp(inport, arp.spa,
613 UDP port unreachable. Priority-80 flows generate ICMP port
614 unreachable messages in reply to UDP datagrams directed to the
615 router's IP address. The logical router doesn't accept any UDP
616 traffic so it always generates such a reply.
620 These flows should not match IP fragments with nonzero offset.
624 Details TBD. Not yet implemented.
630 TCP reset. Priority-80 flows generate TCP reset messages in reply to
631 TCP datagrams directed to the router's IP address. The logical
632 router doesn't accept any TCP traffic so it always generates such a
637 These flows should not match IP fragments with nonzero offset.
641 Details TBD. Not yet implemented.
647 Protocol unreachable. Priority-70 flows generate ICMP protocol
648 unreachable messages in reply to packets directed to the router's IP
649 address on IP protocols other than UDP, TCP, and ICMP.
653 These flows should not match IP fragments with nonzero offset.
657 Details TBD. Not yet implemented.
662 Drop other IP traffic to this router. These flows drop any other
663 traffic destined to an IP address of this router that is not already
664 handled by one of the flows above, which amounts to ICMP (other than
665 echo requests) and fragments with nonzero offsets. For each IP address
666 <var>A</var> owned by the router, a priority-60 flow matches
667 <code>ip4.dst == <var>A</var></code> and drops the traffic. An
668 exception is made and the above flow is not added if the router
669 port's own IP address is used to SNAT packets passing through that
675 The flows above handle all of the traffic that might be directed to the
676 router itself. The following flows (with lower priorities) handle the
677 remaining traffic, potentially for forwarding:
682 Drop Ethernet local broadcast. A priority-50 flow with match
683 <code>eth.bcast</code> drops traffic destined to the local Ethernet
684 broadcast address. By definition this traffic should not be forwarded.
688 Drop IP multicast. A priority-50 flow with match
689 <code>ip4.mcast</code> drops IP multicast traffic.
694 ICMP time exceeded. For each router port <var>P</var>, whose IP
695 address is <var>A</var>, a priority-40 flow with match <code>inport
696 == <var>P</var> && ip.ttl == {0, 1} &&
697 !ip.later_frag</code> matches packets whose TTL has expired, with the
698 following actions to send an ICMP time exceeded reply:
703 icmp4.type = 11; /* Time exceeded. */
704 icmp4.code = 0; /* TTL exceeded in transit. */
706 ip4.src = <var>A</var>;
718 TTL discard. A priority-30 flow with match <code>ip.ttl == {0,
719 1}</code> and actions <code>drop;</code> drops other packets whose TTL
720 has expired, that should not receive a ICMP error reply (i.e. fragments
721 with nonzero offset).
725 Next table. A priority-0 flows match all packets that aren't already
726 handled and uses actions <code>next;</code> to feed them to the ingress
731 <h3>Ingress Table 2: UNSNAT</h3>
734 This is for already established connections' reverse traffic.
735 i.e., SNAT has already been done in egress pipeline and now the
736 packet has entered the ingress pipeline as part of a reply. It is
743 For each configuration in the OVN Northbound database, that asks
744 to change the source IP address of a packet from <var>A</var> to
745 <var>B</var>, a priority-100 flow matches <code>ip &&
746 ip4.dst == <var>B</var></code> with an action
747 <code>ct_snat; next;</code>.
751 A priority-0 logical flow with match <code>1</code> has actions
757 <h3>Ingress Table 3: DNAT</h3>
760 Packets enter the pipeline with destination IP address that needs to
761 be DNATted from a virtual IP address to a real IP address. Packets
762 in the reverse direction needs to be unDNATed.
767 For each configuration in the OVN Northbound database, that asks
768 to change the destination IP address of a packet from <var>A</var> to
769 <var>B</var>, a priority-100 flow matches <code>ip &&
770 ip4.dst == <var>A</var></code> with an action <code>inport = "";
771 ct_dnat(<var>B</var>);</code>.
775 For all IP packets of a Gateway router, a priority-50 flow with an
776 action <code>inport = ""; ct_dnat;</code>.
780 A priority-0 logical flow with match <code>1</code> has actions
786 <h3>Ingress Table 4: IP Routing</h3>
789 A packet that arrives at this table is an IP packet that should be routed
790 to the address in <code>ip4.dst</code>. This table implements IP
791 routing, setting <code>reg0</code> to the next-hop IP address (leaving
792 <code>ip4.dst</code>, the packet's final destination, unchanged) and
793 advances to the next table for ARP resolution. It also sets
794 <code>reg1</code> to the IP address owned by the selected router port
795 (which is used later in table 6 as the IP source address for an ARP
800 This table contains the following logical flows:
806 Routing table. For each route to IPv4 network <var>N</var> with
807 netmask <var>M</var>, on router port <var>P</var> with IP address
808 <var>A</var> and Ethernet
809 address <var>E</var>, a logical flow with match <code>ip4.dst ==
810 <var>N</var>/<var>M</var></code>, whose priority is the number of
811 1-bits in <var>M</var>, has the following actions:
818 eth.src = <var>E</var>;
819 outport = <var>P</var>;
824 (Ingress table 1 already verified that <code>ip.ttl--;</code> will
825 not yield a TTL exceeded error.)
829 If the route has a gateway, <var>G</var> is the gateway IP address.
830 Instead, if the route is from a configured static route, <var>G</var>
831 is the next hop IP address. Else it is <code>ip4.dst</code>.
837 Destination unreachable. For each router port <var>P</var>, which
838 owns IP address <var>A</var>, a priority-0 logical flow with match
839 <code>in_port == <var>P</var> && !ip.later_frag &&
840 !icmp</code> has the following actions:
845 icmp4.type = 3; /* Destination unreachable. */
846 icmp4.code = 0; /* Network unreachable. */
848 ip4.src = <var>A</var>;
855 (The <code>!icmp</code> check prevents recursion if the destination
856 unreachable message itself cannot be routed.)
860 These flows are omitted if the logical router has a default route,
861 that is, a route with netmask 0.0.0.0.
866 <h3>Ingress Table 5: ARP Resolution</h3>
869 Any packet that reaches this table is an IP packet whose next-hop IP
870 address is in <code>reg0</code>. (<code>ip4.dst</code> is the final
871 destination.) This table resolves the IP address in <code>reg0</code>
872 into an output port in <code>outport</code> and an Ethernet address in
873 <code>eth.dst</code>, using the following flows:
879 Static MAC bindings. MAC bindings can be known statically based on
880 data in the <code>OVN_Northbound</code> database. For router ports
881 connected to logical switches, MAC bindings can be known statically
882 from the <code>addresses</code> column in the
883 <code>Logical_Switch_Port</code> table. For router ports
884 connected to other logical routers, MAC bindings can be known
885 statically from the <code>mac</code> and <code>network</code>
886 column in the <code>Logical_Router_Port</code> table.
890 For each IP address <var>A</var> whose host is known to have Ethernet
891 address <var>E</var> on router port <var>P</var>, a priority-100 flow
892 with match <code>outport === <var>P</var> && reg0 ==
893 <var>A</var></code> has actions <code>eth.dst = <var>E</var>;
898 For each logical router port with an IP address <var>A</var> and
899 a mac address of <var>E</var> that is reachable via a different
900 logical router port <var>P</var>, a priority-100 flow with
901 match <code>outport === <var>P</var> && reg0 ==
902 <var>A</var></code> has actions <code>eth.dst = <var>E</var>;
909 Dynamic MAC bindings. This flows resolves MAC-to-IP bindings that
910 have become known dynamically through ARP. (The next table will
911 issue an ARP request for cases where the binding is not yet known.)
915 A priority-0 logical flow with match <code>1</code> has actions
916 <code>get_arp(outport, reg0); next;</code>.
921 <h3>Ingress Table 6: ARP Request</h3>
924 In the common case where the Ethernet destination has been resolved, this
925 table outputs the packet. Otherwise, it composes and sends an ARP
926 request. It holds the following flows:
932 Unknown MAC address. A priority-100 flow with match <code>eth.dst ==
933 00:00:00:00:00:00</code> has the following actions:
938 eth.dst = ff:ff:ff:ff:ff:ff;
940 arp.op = 1; /* ARP request. */
946 (Ingress table 4 initialized <code>reg1</code> with the IP address
947 owned by <code>outport</code>.)
951 The IP packet that triggers the ARP request is dropped.
956 Known MAC address. A priority-0 flow with match <code>1</code> has
957 actions <code>output;</code>.
961 <h3>Egress Table 0: SNAT</h3>
964 Packets that are configured to be SNATed get their source IP address
965 changed based on the configuration in the OVN Northbound database.
970 For each configuration in the OVN Northbound database, that asks
971 to change the source IP address of a packet from an IP address of
972 <var>A</var> or to change the source IP address of a packet that
973 belongs to network <var>A</var> to <var>B</var>, a flow matches
974 <code>ip && ip4.src == <var>A</var></code> with an action
975 <code>ct_snat(<var>B</var>);</code>. The priority of the flow
976 is calculated based on the mask of <var>A</var>, with matches
977 having larger masks getting higher priorities.
980 A priority-0 logical flow with match <code>1</code> has actions
986 <h3>Egress Table 1: Delivery</h3>
989 Packets that reach this table are ready for delivery. It contains
990 priority-100 logical flows that match packets on each enabled logical
991 router port, with action <code>output;</code>.