ovn/northd/ovn-northd.8.xml

   1 <?xml version="1.0" encoding="utf-8"?>
   2 <manpage program="ovn-northd" section="8" title="ovn-northd">
   3     <h1>Name</h1>
   4     <p>ovn-northd -- Open Virtual Network central control daemon</p>
   5
   6     <h1>Synopsis</h1>
   7     <p><code>ovn-northd</code> [<var>options</var>]</p>
   8
   9     <h1>Description</h1>
  10     <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.
  19     </p>
  20
  21     <h1>Configuration</h1>
  22     <p>
  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:
  27     </p>
  28     <ul>
  29       <li>
  30         <p>
  31           <code>--ovnnb-db=<var>database</var></code>
  32         </p>
  33         <p>
  34           The database containing the OVN Northbound Database.
  35         </p>
  36       </li>
  37       <li>
  38         <p>
  39           <code>--ovsnb-db=<var>database</var></code>
  40         </p>
  41         <p>
  42           The database containing the OVN Southbound Database.
  43         </p>
  44       </li>
  45     </ul>
  46     <p>
  47       The <var>database</var> argument must take one of the following forms:
  48     </p>
  49     <ul>
  50       <li>
  51         <p>
  52           <code>ssl:<var>ip</var>:<var>port</var></code>
  53         </p>
  54         <p>
  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.
  62         </p>
  63       </li>
  64       <li>
  65         <p>
  66           <code>tcp:<var>ip</var>:<var>port</var></code>
  67         </p>
  68         <p>
  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>.
  73         </p>
  74       </li>
  75       <li>
  76         <p>
  77           <code>unix:<var>file</var></code>
  78         </p>
  79         <p>
  80           On POSIX, connect to the Unix domain server socket named
  81           <var>file</var>.
  82         </p>
  83         <p>
  84           On Windows, connect to a localhost TCP port whose value is written
  85           in <var>file</var>.
  86         </p>
  87       </li>
  88     </ul>
  89
  90     <h1>RUNTIME MANAGEMENT COMMANDS</h1>
  91     <p>
  92       <code>ovs-appctl</code> can send commands to a running
  93       <code>ovn-northd</code> process.  The currently supported commands
  94       are described below.
  95       <dl>
  96       <dt><code>exit</code></dt>
  97       <dd>
  98         Causes <code>ovn-northd</code> to gracefully terminate.
  99       </dd>
 100       </dl>
 101     </p>
 102
 103     <h1>Logical Flow Table Structure</h1>
 104
 105     <p>
 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.
 110     </p>
 111
 112     <h2>Ingress Table 0: Admission Control and Ingress Port Security</h2>
 113
 114     <p>
 115       Ingress table 0 contains these logical flows:
 116     </p>
 117
 118     <ul>
 119       <li>
 120         Priority 100 flows to drop packets with VLAN tags or multicast Ethernet
 121         source addresses.
 122       </li>
 123
 124       <li>
 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>.
 131       </li>
 132     </ul>
 133
 134     <p>
 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
 137       be dropped.
 138     </p>
 139
 140     <h2>Ingress table 1: <code>from-lport</code> ACLs</h2>
 141
 142     <p>
 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
 149       directly.
 150     </p>
 151
 152     <p>
 153       Ingress table 1 also contains a priority 0 flow with action
 154       <code>next;</code>, so that ACLs allow packets by default.
 155     </p>
 156
 157     <h2>Ingress Table 2: Destination Lookup</h2>
 158
 159     <p>
 160       This table implements switching behavior.  It contains these logical
 161       flows:
 162     </p>
 163
 164     <ul>
 165       <li>
 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.
 170       </li>
 171
 172       <li>
 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
 175         output port.
 176       </li>
 177
 178       <li>
 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.
 185       </li>
 186     </ul>
 187
 188     <h2>Egress Table 0: <code>to-lport</code> ACLs</h2>
 189
 190     <p>
 191       This is similar to ingress table 1 except for <code>to-lport</code> ACLs.
 192     </p>
 193
 194     <h2>Egress Table 1: Egress Port Security</h2>
 195
 196     <p>
 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.
 208     </p>
 209 </manpage>