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>--ovsnb-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 logical datapaths.
112 <h2>Ingress Table 0: Admission Control and Ingress Port Security</h2>
115 Ingress table 0 contains these logical flows:
120 Priority 100 flows to drop packets with VLAN tags or multicast Ethernet
125 Priority 50 flows that implement ingress port security for each enabled
126 logical port. For logical ports on which port security is enabled,
127 these match the <code>inport</code> and the valid <code>eth.src</code>
128 address(es) and advance only those packets to the next flow table. For
129 logical ports on which port security is not enabled, these advance all
130 packets that match the <code>inport</code>.
135 There are no flows for disabled logical ports because the default-drop
136 behavior of logical flow tables causes packets that ingress from them to
140 <h2>Ingress table 1: <code>from-lport</code> ACLs</h2>
143 Logical flows in this table closely reproduce those in the
144 <code>ACL</code> table in the <code>OVN_Northbound</code> database for
145 the <code>from-lport</code> direction. <code>allow</code> and
146 <code>allow-related</code> ACLs translate into logical flows with the
147 <code>next;</code> action, others to <code>drop;</code>. The
148 <code>priority</code> values from the <code>ACL</code> table are used
153 Ingress table 1 also contains a priority 0 flow with action
154 <code>next;</code>, so that ACLs allow packets by default.
157 <h2>Ingress Table 2: Destination Lookup</h2>
160 This table implements switching behavior. It contains these logical
166 A priority-100 flow that outputs all packets with an Ethernet broadcast
167 or multicast <code>eth.dst</code> to the <code>MC_FLOOD</code>
168 multicast group, which <code>ovn-northd</code> populates with all
169 enabled logical ports.
173 One priority-50 flow that matches each known Ethernet address against
174 <code>eth.dst</code> and outputs the packet to the single associated
179 One priority-0 fallback flow that matches all packets and outputs them
180 to the <code>MC_UNKNOWN</code> multicast group, which
181 <code>ovn-northd</code> populates with all enabled logical ports that
182 accept unknown destination packets. As a small optimization, if no
183 logical ports accept unknown destination packets,
184 <code>ovn-northd</code> omits this multicast group and logical flow.
188 <h2>Egress Table 0: <code>to-lport</code> ACLs</h2>
191 This is similar to ingress table 1 except for <code>to-lport</code> ACLs.
194 <h2>Egress Table 1: Egress Port Security</h2>
197 This is similar to the ingress port security logic in ingress table 0,
198 but with important differences. Most obviously, <code>outport</code> and
199 <code>eth.dst</code> are checked instead of <code>inport</code> and
200 <code>eth.src</code>. Second, packets directed to broadcast or multicast
201 <code>eth.dst</code> are always accepted instead of being subject to the
202 port security rules; this is implemented through a priority-100 flow that
203 matches on <code>eth.dst[40]</code> with action <code>output;</code>.
204 Finally, to ensure that even broadcast and multicast packets are not
205 delivered to disabled logical ports, a priority-150 flow for each
206 disabled logical <code>outport</code> overrides the priority-100 flow
207 with a <code>drop;</code> action.