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 default is <code>db.sock</code>
25 in the local Open vSwitch's "run" directory. This may be
26 overridden with the following commands:
31 <code>--ovnnb-db=<var>database</var></code>
34 The database containing the OVN Northbound Database.
39 <code>--ovnsb-db=<var>database</var></code>
42 The database containing the OVN Southbound Database.
47 The <var>database</var> argument must take one of the following forms:
52 <code>ssl:<var>ip</var>:<var>port</var></code>
55 The specified SSL <var>port</var> on the host at the given
56 <var>ip</var>, which must be expressed as an IP address (not a DNS
57 name) in IPv4 or IPv6 address format. If <var>ip</var> is an IPv6
58 address, then wrap <var>ip</var> with square brackets, e.g.:
59 <code>ssl:[::1]:6640</code>. The <code>--private-key</code>,
60 <code>--certificate</code>, and <code>--ca-cert</code> options are
61 mandatory when this form is used.
66 <code>tcp:<var>ip</var>:<var>port</var></code>
69 Connect to the given TCP <var>port</var> on <var>ip</var>, where
70 <var>ip</var> can be IPv4 or IPv6 address. If <var>ip</var> is an
71 IPv6 address, then wrap <var>ip</var> with square brackets, e.g.:
72 <code>tcp:[::1]:6640</code>.
77 <code>unix:<var>file</var></code>
80 On POSIX, connect to the Unix domain server socket named
84 On Windows, connect to a localhost TCP port whose value is written
90 <h1>Runtime Management Commands</h1>
92 <code>ovs-appctl</code> can send commands to a running
93 <code>ovn-northd</code> process. The currently supported commands
96 <dt><code>exit</code></dt>
98 Causes <code>ovn-northd</code> to gracefully terminate.
103 <h1>Logical Flow Table Structure</h1>
106 One of the main purposes of <code>ovn-northd</code> is to populate the
107 <code>Logical_Flow</code> table in the <code>OVN_Southbound</code>
108 database. This section describes how <code>ovn-northd</code> does this
109 for switch and router logical datapaths.
112 <h2>Logical Switch Datapaths</h2>
114 <h3>Ingress Table 0: Admission Control and Ingress Port Security - L2</h3>
117 Ingress table 0 contains these logical flows:
122 Priority 100 flows to drop packets with VLAN tags or multicast Ethernet
127 Priority 50 flows that implement ingress port security for each enabled
128 logical port. For logical ports on which port security is enabled,
129 these match the <code>inport</code> and the valid <code>eth.src</code>
130 address(es) and advance only those packets to the next flow table. For
131 logical ports on which port security is not enabled, these advance all
132 packets that match the <code>inport</code>.
137 There are no flows for disabled logical ports because the default-drop
138 behavior of logical flow tables causes packets that ingress from them to
142 <h3>Ingress Table 1: Ingress Port Security - IP</h3>
145 Ingress table 1 contains these logical flows:
151 For each element in the port security set having one or more IPv4 or
152 IPv6 addresses (or both),
157 Priority 90 flow to allow IPv4 traffic if it has IPv4 addresses
158 which match the <code>inport</code>, valid <code>eth.src</code>
159 and valid <code>ip4.src</code> address(es).
163 Priority 90 flow to allow IPv6 traffic if it has IPv6 addresses
164 which match the <code>inport</code>, valid <code>eth.src</code> and
165 valid <code>ip6.src</code> address(es).
169 Priority 80 flow to drop IP (both IPv4 and IPv6) traffic which
170 match the <code>inport</code> and valid <code>eth.src</code>.
176 One priority-0 fallback flow that matches all packets and advances to
181 <h3>Ingress Table 2: Ingress Port Security - Neighbor discovery</h3>
184 Ingress table 2 contains these logical flows:
190 For each element in the port security set,
195 Priority 90 flow to allow ARP traffic which match the
196 <code>inport</code> and valid <code>eth.src</code> and
197 <code>arp.sha</code>. If the element has one or more
198 IPv4 addresses, then it also matches the valid
199 <code>arp.spa</code>.
203 Priority 90 flow to allow IPv6 Neighbor Solicitation and
204 Advertisement traffic which match the <code>inport</code>,
205 valid <code>eth.src</code> and
206 <code>nd.sll</code>/<code>nd.tll</code>.
207 If the element has one or more IPv6 addresses, then it also
208 matches the valid <code>nd.target</code> address(es) for Neighbor
209 Advertisement traffic.
213 Priority 80 flow to drop ARP and IPv6 Neighbor Solicitation and
214 Advertisement traffic which match the <code>inport</code> and
215 valid <code>eth.src</code>.
221 One priority-0 fallback flow that matches all packets and advances to
226 <h3>Ingress Table 3: <code>from-lport</code> Pre-ACLs</h3>
229 Ingress table 3 prepares flows for possible stateful ACL processing
230 in table 4. It contains a priority-0 flow that simply moves
231 traffic to table 4. If stateful ACLs are used in the logical
232 datapath, a priority-100 flow is added that sends IP packets to
233 the connection tracker before advancing to table 4.
236 <h3>Ingress table 4: <code>from-lport</code> ACLs</h3>
239 Logical flows in this table closely reproduce those in the
240 <code>ACL</code> table in the <code>OVN_Northbound</code> database
241 for the <code>from-lport</code> direction. <code>allow</code>
242 ACLs translate into logical flows with the <code>next;</code>
243 action, <code>allow-related</code> ACLs translate into logical
244 flows with the <code>ct_commit; next;</code> actions, other ACLs
245 translate to <code>drop;</code>. The <code>priority</code> values
246 from the <code>ACL</code> table have a limited range and have 1000
247 added to them to leave room for OVN default flows at both higher
248 and lower priorities.
252 Ingress table 4 also contains a priority 0 flow with action
253 <code>next;</code>, so that ACLs allow packets by default. If the
254 logical datapath has a statetful ACL, the following flows will
260 A priority-1 flow to commit IP traffic to the connection
261 tracker. This is needed for the default allow policy because,
262 while the initiater's direction may not have any stateful rules,
263 the server's may and then its return traffic would not be known
264 and marked as invalid.
268 A priority-65535 flow that allows any traffic that has been
269 committed to the connection tracker (i.e., established flows).
273 A priority-65535 flow that allows any traffic that is considered
274 related to a committed flow in the connection tracker (e.g., an
275 ICMP Port Unreachable from a non-listening UDP port).
279 A priority-65535 flow that drops all traffic marked by the
280 connection tracker as invalid.
284 <h3>Ingress Table 5: ARP responder</h3>
287 This table implements ARP responder for known IPs. It contains these
293 Priority-100 flows to skip ARP responder if inport is of type
294 <code>localnet</code>, and advances directly to table 6.
299 Priority-50 flows that matches ARP requests to each known IP address
300 <var>A</var> of logical port <var>P</var>, and respond with ARP
301 replies directly with corresponding Ethernet address <var>E</var>:
306 eth.src = <var>E</var>;
307 arp.op = 2; /* ARP reply. */
309 arp.sha = <var>E</var>;
311 arp.spa = <var>A</var>;
312 outport = <var>P</var>;
313 inport = ""; /* Allow sending out inport. */
318 These flows are omitted for logical ports (other than router ports)
324 One priority-0 fallback flow that matches all packets and advances to
329 <h3>Ingress Table 6: Destination Lookup</h3>
332 This table implements switching behavior. It contains these logical
338 A priority-100 flow that outputs all packets with an Ethernet broadcast
339 or multicast <code>eth.dst</code> to the <code>MC_FLOOD</code>
340 multicast group, which <code>ovn-northd</code> populates with all
341 enabled logical ports.
345 One priority-50 flow that matches each known Ethernet address against
346 <code>eth.dst</code> and outputs the packet to the single associated
351 One priority-0 fallback flow that matches all packets and outputs them
352 to the <code>MC_UNKNOWN</code> multicast group, which
353 <code>ovn-northd</code> populates with all enabled logical ports that
354 accept unknown destination packets. As a small optimization, if no
355 logical ports accept unknown destination packets,
356 <code>ovn-northd</code> omits this multicast group and logical flow.
360 <h3>Egress Table 0: <code>to-lport</code> Pre-ACLs</h3>
363 This is similar to ingress table 3 except for <code>to-lport</code>
367 <h3>Egress Table 1: <code>to-lport</code> ACLs</h3>
370 This is similar to ingress table 4 except for <code>to-lport</code> ACLs.
373 <h3>Egress Table 2: Egress Port Security - IP</h3>
376 This is similar to the ingress port security logic in table 1 except
377 that <code>outport</code>, <code>eth.dst</code>, <code>ip4.dst</code>
378 and <code>ip6.dst</code> are checked instead of <code>inport</code>,
379 <code>eth.src</code>, <code>ip4.src</code> and <code>ip6.src</code>
382 <h3>Egress Table 3: Egress Port Security - L2</h3>
385 This is similar to the ingress port security logic in ingress table 0,
386 but with important differences. Most obviously, <code>outport</code> and
387 <code>eth.dst</code> are checked instead of <code>inport</code> and
388 <code>eth.src</code>. Second, packets directed to broadcast or multicast
389 <code>eth.dst</code> are always accepted instead of being subject to the
390 port security rules; this is implemented through a priority-100 flow that
391 matches on <code>eth.mcast</code> with action <code>output;</code>.
392 Finally, to ensure that even broadcast and multicast packets are not
393 delivered to disabled logical ports, a priority-150 flow for each
394 disabled logical <code>outport</code> overrides the priority-100 flow
395 with a <code>drop;</code> action.
398 <h2>Logical Router Datapaths</h2>
400 <h3>Ingress Table 0: L2 Admission Control</h3>
403 This table drops packets that the router shouldn't see at all based on
404 their Ethernet headers. It contains the following flows:
409 Priority-100 flows to drop packets with VLAN tags or multicast Ethernet
414 For each enabled router port <var>P</var> with Ethernet address
415 <var>E</var>, a priority-50 flow that matches <code>inport ==
416 <var>P</var> && (eth.mcast || eth.dst ==
417 <var>E</var></code>), with action <code>next;</code>.
422 Other packets are implicitly dropped.
425 <h3>Ingress Table 1: IP Input</h3>
428 This table is the core of the logical router datapath functionality. It
429 contains the following flows to implement very basic IP host
436 L3 admission control: A priority-100 flow drops packets that match
437 any of the following:
442 <code>ip4.src[28..31] == 0xe</code> (multicast source)
445 <code>ip4.src == 255.255.255.255</code> (broadcast source)
448 <code>ip4.src == 127.0.0.0/8 || ip4.dst == 127.0.0.0/8</code>
449 (localhost source or destination)
452 <code>ip4.src == 0.0.0.0/8 || ip4.dst == 0.0.0.0/8</code> (zero
453 network source or destination)
456 <code>ip4.src</code> is any IP address owned by the router.
459 <code>ip4.src</code> is the broadcast address of any IP network
467 ICMP echo reply. These flows reply to ICMP echo requests received
468 for the router's IP address. Let <var>A</var> be an IP address or
469 broadcast address owned by a router port. Then, for each
470 <var>A</var>, a priority-90 flow matches on <code>ip4.dst ==
471 <var>A</var></code> and <code>icmp4.type == 8 && icmp4.code
472 == 0</code> (ICMP echo request). These flows use the following
473 actions where, if <var>A</var> is unicast, then <var>S</var> is
474 <var>A</var>, and if <var>A</var> is broadcast, <var>S</var> is the
475 router's IP address in <var>A</var>'s network:
480 ip4.src = <var>S</var>;
483 inport = ""; /* Allow sending out inport. */
488 Similar flows match on <code>ip4.dst == 255.255.255.255</code> and
489 each individual <code>inport</code>, and use the same actions in
490 which <var>S</var> is a function of <code>inport</code>.
496 Reply to ARP requests. These flows reply to ARP requests for the
497 router's own IP address. For each router port <var>P</var> that owns
498 IP address <var>A</var> and Ethernet address <var>E</var>, a
499 priority-90 flow matches <code>inport == <var>P</var> &&
500 arp.op == 1 && arp.tpa == <var>A</var></code> (ARP request)
501 with the following actions:
506 eth.src = <var>E</var>;
507 arp.op = 2; /* ARP reply. */
509 arp.sha = <var>E</var>;
511 arp.spa = <var>A</var>;
512 outport = <var>P</var>;
513 inport = ""; /* Allow sending out inport. */
519 ARP reply handling. These flows use ARP replies to populate the
520 logical router's ARP table. A priority-90 flow with match <code>arp.op
521 == 2</code> has actions <code>put_arp(inport, arp.spa,
527 UDP port unreachable. Priority-80 flows generate ICMP port
528 unreachable messages in reply to UDP datagrams directed to the
529 router's IP address. The logical router doesn't accept any UDP
530 traffic so it always generates such a reply.
534 These flows should not match IP fragments with nonzero offset.
538 Details TBD. Not yet implemented.
544 TCP reset. Priority-80 flows generate TCP reset messages in reply to
545 TCP datagrams directed to the router's IP address. The logical
546 router doesn't accept any TCP traffic so it always generates such a
551 These flows should not match IP fragments with nonzero offset.
555 Details TBD. Not yet implemented.
561 Protocol unreachable. Priority-70 flows generate ICMP protocol
562 unreachable messages in reply to packets directed to the router's IP
563 address on IP protocols other than UDP, TCP, and ICMP.
567 These flows should not match IP fragments with nonzero offset.
571 Details TBD. Not yet implemented.
576 Drop other IP traffic to this router. These flows drop any other
577 traffic destined to an IP address of this router that is not already
578 handled by one of the flows above, which amounts to ICMP (other than
579 echo requests) and fragments with nonzero offsets. For each IP address
580 <var>A</var> owned by the router, a priority-60 flow matches
581 <code>ip4.dst == <var>A</var></code> and drops the traffic.
586 The flows above handle all of the traffic that might be directed to the
587 router itself. The following flows (with lower priorities) handle the
588 remaining traffic, potentially for forwarding:
593 Drop Ethernet local broadcast. A priority-50 flow with match
594 <code>eth.bcast</code> drops traffic destined to the local Ethernet
595 broadcast address. By definition this traffic should not be forwarded.
599 Drop IP multicast. A priority-50 flow with match
600 <code>ip4.mcast</code> drops IP multicast traffic.
605 ICMP time exceeded. For each router port <var>P</var>, whose IP
606 address is <var>A</var>, a priority-40 flow with match <code>inport
607 == <var>P</var> && ip.ttl == {0, 1} &&
608 !ip.later_frag</code> matches packets whose TTL has expired, with the
609 following actions to send an ICMP time exceeded reply:
614 icmp4.type = 11; /* Time exceeded. */
615 icmp4.code = 0; /* TTL exceeded in transit. */
617 ip4.src = <var>A</var>;
629 TTL discard. A priority-30 flow with match <code>ip.ttl == {0,
630 1}</code> and actions <code>drop;</code> drops other packets whose TTL
631 has expired, that should not receive a ICMP error reply (i.e. fragments
632 with nonzero offset).
636 Next table. A priority-0 flows match all packets that aren't already
637 handled and uses actions <code>next;</code> to feed them to the ingress
642 <h3>Ingress Table 2: IP Routing</h3>
645 A packet that arrives at this table is an IP packet that should be routed
646 to the address in <code>ip4.dst</code>. This table implements IP
647 routing, setting <code>reg0</code> to the next-hop IP address (leaving
648 <code>ip4.dst</code>, the packet's final destination, unchanged) and
649 advances to the next table for ARP resolution. It also sets
650 <code>reg1</code> to the IP address owned by the selected router port
651 (which is used later in table 4 as the IP source address for an ARP
656 This table contains the following logical flows:
662 Routing table. For each route to IPv4 network <var>N</var> with
663 netmask <var>M</var>, on router port <var>P</var> with IP address
664 <var>A</var> and Ethernet
665 address <var>E</var>, a logical flow with match <code>ip4.dst ==
666 <var>N</var>/<var>M</var></code>, whose priority is the number of
667 1-bits in <var>M</var>, has the following actions:
674 eth.src = <var>E</var>;
675 outport = <var>P</var>;
680 (Ingress table 1 already verified that <code>ip.ttl--;</code> will
681 not yield a TTL exceeded error.)
685 If the route has a gateway, <var>G</var> is the gateway IP address,
686 otherwise it is <code>ip4.dst</code>.
692 Destination unreachable. For each router port <var>P</var>, which
693 owns IP address <var>A</var>, a priority-0 logical flow with match
694 <code>in_port == <var>P</var> && !ip.later_frag &&
695 !icmp</code> has the following actions:
700 icmp4.type = 3; /* Destination unreachable. */
701 icmp4.code = 0; /* Network unreachable. */
703 ip4.src = <var>A</var>;
710 (The <code>!icmp</code> check prevents recursion if the destination
711 unreachable message itself cannot be routed.)
715 These flows are omitted if the logical router has a default route,
716 that is, a route with netmask 0.0.0.0.
721 <h3>Ingress Table 3: ARP Resolution</h3>
724 Any packet that reaches this table is an IP packet whose next-hop IP
725 address is in <code>reg0</code>. (<code>ip4.dst</code> is the final
726 destination.) This table resolves the IP address in <code>reg0</code>
727 into an output port in <code>outport</code> and an Ethernet address in
728 <code>eth.dst</code>, using the following flows:
734 Static MAC bindings. MAC bindings can be known statically based on
735 data in the <code>OVN_Northbound</code> database. For router ports
736 connected to logical switches, MAC bindings can be known statically
737 from the <code>addresses</code> column in the
738 <code>Logical_Port</code> table. For router ports connected to other
739 logical routers, MAC bindings can be known statically from the
740 <code>mac</code> and <code>network</code> column in the
741 <code>Logical_Router_Port</code> table.
745 For each IP address <var>A</var> whose host is known to have Ethernet
746 address <var>E</var> on router port <var>P</var>, a priority-100 flow
747 with match <code>outport === <var>P</var> && reg0 ==
748 <var>A</var></code> has actions <code>eth.dst = <var>E</var>;
753 For each logical router port with an IP address <var>A</var> and
754 a mac address of <var>E</var> that is reachable via a different
755 logical router port <var>P</var>, a priority-100 flow with
756 match <code>outport === <var>P</var> && reg0 ==
757 <var>A</var></code> has actions <code>eth.dst = <var>E</var>;
764 Dynamic MAC bindings. This flows resolves MAC-to-IP bindings that
765 have become known dynamically through ARP. (The next table will
766 issue an ARP request for cases where the binding is not yet known.)
770 A priority-0 logical flow with match <code>1</code> has actions
771 <code>get_arp(outport, reg0); next;</code>.
776 <h3>Ingress Table 4: ARP Request</h3>
779 In the common case where the Ethernet destination has been resolved, this
780 table outputs the packet. Otherwise, it composes and sends an ARP
781 request. It holds the following flows:
787 Unknown MAC address. A priority-100 flow with match <code>eth.dst ==
788 00:00:00:00:00:00</code> has the following actions:
793 eth.dst = ff:ff:ff:ff:ff:ff;
795 arp.op = 1; /* ARP request. */
801 (Ingress table 2 initialized <code>reg1</code> with the IP address
802 owned by <code>outport</code>.)
806 The IP packet that triggers the ARP request is dropped.
811 Known MAC address. A priority-0 flow with match <code>1</code> has
812 actions <code>output;</code>.
816 <h3>Egress Table 0: Delivery</h3>
819 Packets that reach this table are ready for delivery. It contains
820 priority-100 logical flows that match packets on each enabled logical
821 router port, with action <code>output;</code>.