Provided by: ovn-central_2.5.9-0ubuntu0.16.04.3_amd64 
NAME
ovn-northd - Open Virtual Network central control daemon
SYNOPSIS
ovn-northd [options]
DESCRIPTION
ovn-northd is a centralized daemon responsible for translating the high-level OVN
configuration into logical configuration consumable by daemons such as ovn-controller. It
translates the logical network configuration in terms of conventional network concepts,
taken from the OVN Northbound Database (see ovn-nb(5)), into logical datapath flows in the
OVN Southbound Database (see ovn-sb(5)) below it.
CONFIGURATION
ovn-northd requires a connection to the Northbound and Southbound databases. The default
is db.sock in the local Open vSwitch’s "run" directory. This may be overridden with the
following commands:
• --ovnnb-db=database
The database containing the OVN Northbound Database.
• --ovsnb-db=database
The database containing the OVN Southbound Database.
The database argument must take one of the following forms:
• ssl:ip:port
The specified SSL port on the host at the given ip, which must be expressed
as an IP address (not a DNS name) in IPv4 or IPv6 address format. If ip is
an IPv6 address, then wrap ip with square brackets, e.g.: ssl:[::1]:6640.
The --private-key, --certificate, and --ca-cert options are mandatory when
this form is used.
• tcp:ip:port
Connect to the given TCP port on ip, where ip can be IPv4 or IPv6 address.
If ip is an IPv6 address, then wrap ip with square brackets, e.g.:
tcp:[::1]:6640.
• unix:file
On POSIX, connect to the Unix domain server socket named file.
On Windows, connect to a localhost TCP port whose value is written in file.
RUNTIME MANAGEMENT COMMANDS
ovs-appctl can send commands to a running ovn-northd process. The currently supported
commands are described below.
exit Causes ovn-northd to gracefully terminate.
LOGICAL FLOW TABLE STRUCTURE
One of the main purposes of ovn-northd is to populate the Logical_Flow table in the
OVN_Southbound database. This section describes how ovn-northd does this for switch and
router logical datapaths.
Logical Switch Datapaths
Ingress Table 0: Admission Control and Ingress Port Security
Ingress table 0 contains these logical flows:
• Priority 100 flows to drop packets with VLAN tags or multicast Ethernet
source addresses.
• Priority 50 flows that implement ingress port security for each enabled
logical port. For logical ports on which port security is enabled, these
match the inport and the valid eth.src address(es) and advance only those
packets to the next flow table. For logical ports on which port security is
not enabled, these advance all packets that match the inport.
There are no flows for disabled logical ports because the default-drop behavior of logical
flow tables causes packets that ingress from them to be dropped.
Ingress Table 1: from-lport Pre-ACLs
Ingress table 1 prepares flows for possible stateful ACL processing in table 2. It
contains a priority-0 flow that simply moves traffic to table 2. If stateful ACLs are
used in the logical datapath, a priority-100 flow is added that sends IP packets to the
connection tracker before advancing to table 2.
Ingress table 2: from-lport ACLs
Logical flows in this table closely reproduce those in the ACL table in the OVN_Northbound
database for the from-lport direction. allow ACLs translate into logical flows with the
next; action, allow-related ACLs translate into logical flows with the ct_next; action,
other ACLs translate to drop;. The priority values from the ACL table are used directly.
Ingress table 2 also contains a priority 0 flow with action next;, so that ACLs allow
packets by default. If the logical datapath has a statetful ACL, the following flows will
also be added:
• A priority-1 flow to commit IP traffic to the connection tracker. This is
needed for the default allow policy because, while the initiater’s direction
may not have any stateful rules, the server’s may and then its return
traffic would not be known and marked as invalid.
• A priority-65535 flow that allows any traffic that has been committed to the
connection tracker (i.e., established flows).
• A priority-65535 flow that allows any traffic that is considered related to
a committed flow in the connection tracker (e.g., an ICMP Port Unreachable
from a non-listening UDP port).
• A priority-65535 flow that drops all traffic marked by the connection
tracker as invalid.
Ingress Table 3: Destination Lookup
This table implements switching behavior. It contains these logical flows:
• A priority-100 flow that outputs all packets with an Ethernet broadcast or
multicast eth.dst to the MC_FLOOD multicast group, which ovn-northd
populates with all enabled logical ports.
• One priority-50 flow that matches each known Ethernet address against
eth.dst and outputs the packet to the single associated output port.
• One priority-0 fallback flow that matches all packets and outputs them to
the MC_UNKNOWN multicast group, which ovn-northd populates with all enabled
logical ports that accept unknown destination packets. As a small
optimization, if no logical ports accept unknown destination packets,
ovn-northd omits this multicast group and logical flow.
Egress Table 0: to-lport Pre-ACLs
This is similar to ingress table 1 except for to-lport traffic.
Egress Table 1: to-lport ACLs
This is similar to ingress table 2 except for to-lport ACLs.
Egress Table 2: Egress Port Security
This is similar to the ingress port security logic in ingress table 0, but with important
differences. Most obviously, outport and eth.dst are checked instead of inport and
eth.src. Second, packets directed to broadcast or multicast eth.dst are always accepted
instead of being subject to the port security rules; this is implemented through a
priority-100 flow that matches on eth.mcast with action output;. Finally, to ensure that
even broadcast and multicast packets are not delivered to disabled logical ports, a
priority-150 flow for each disabled logical outport overrides the priority-100 flow with a
drop; action.
Logical Router Datapaths
Ingress Table 0: L2 Admission Control
This table drops packets that the router shouldn’t see at all based on their Ethernet
headers. It contains the following flows:
• Priority-100 flows to drop packets with VLAN tags or multicast Ethernet
source addresses.
• For each enabled router port P with Ethernet address E, a priority-50 flow
that matches inport == P && (eth.mcast || eth.dst == E), with action next;.
Other packets are implicitly dropped.
Ingress Table 1: IP Input
This table is the core of the logical router datapath functionality. It contains the
following flows to implement very basic IP host functionality.
• L3 admission control: A priority-100 flow drops packets that match any of
the following:
• ip4.src[28..31] == 0xe (multicast source)
• ip4.src == 255.255.255.255 (broadcast source)
• ip4.src == 127.0.0.0/8 || ip4.dst == 127.0.0.0/8 (localhost source or
destination)
• ip4.src == 0.0.0.0/8 || ip4.dst == 0.0.0.0/8 (zero network source or
destination)
• ip4.src is any IP address owned by the router.
• ip4.src is the broadcast address of any IP network known to the
router.
• ICMP echo reply. These flows reply to ICMP echo requests received for the
router’s IP address. Let A be an IP address or broadcast address owned by a
router port. Then, for each A, a priority-90 flow matches on ip4.dst == A
and icmp4.type == 8 && icmp4.code == 0 (ICMP echo request). These flows use
the following actions where, if A is unicast, then S is A, and if A is
broadcast, S is the router’s IP address in A’s network:
ip4.dst = ip4.src;
ip4.src = S;
ip.ttl = 255;
icmp4.type = 0;
inport = ""; /* Allow sending out inport. */
next;
Similar flows match on ip4.dst == 255.255.255.255 and each individual
inport, and use the same actions in which S is a function of inport.
• ARP reply. These flows reply to ARP requests for the router’s own IP
address. For each router port P that owns IP address A and Ethernet address
E, a priority-90 flow matches inport == P && arp.tpa == A && arp.op == 1
(ARP request) with the following actions:
eth.dst = eth.src;
eth.src = E;
arp.op = 2; /* ARP reply. */
arp.tha = arp.sha;
arp.sha = E;
arp.tpa = arp.spa;
arp.spa = A;
outport = P;
inport = ""; /* Allow sending out inport. */
output;
• UDP port unreachable. Priority-80 flows generate ICMP port unreachable
messages in reply to UDP datagrams directed to the router’s IP address. The
logical router doesn’t accept any UDP traffic so it always generates such a
reply.
These flows should not match IP fragments with nonzero offset.
Details TBD. Not yet implemented.
• TCP reset. Priority-80 flows generate TCP reset messages in reply to TCP
datagrams directed to the router’s IP address. The logical router doesn’t
accept any TCP traffic so it always generates such a reply.
These flows should not match IP fragments with nonzero offset.
Details TBD. Not yet implemented.
• Protocol unreachable. Priority-70 flows generate ICMP protocol unreachable
messages in reply to packets directed to the router’s IP address on IP
protocols other than UDP, TCP, and ICMP.
These flows should not match IP fragments with nonzero offset.
Details TBD. Not yet implemented.
• Drop other IP traffic to this router. These flows drop any other traffic
destined to an IP address of this router that is not already handled by one
of the flows above, which amounts to ICMP (other than echo requests) and
fragments with nonzero offsets. For each IP address A owned by the router,
a priority-60 flow matches ip4.dst == A and drops the traffic.
The flows above handle all of the traffic that might be directed to the router itself.
The following flows (with lower priorities) handle the remaining traffic, potentially for
forwarding:
• Drop Ethernet local broadcast. A priority-50 flow with match eth.bcast
drops traffic destined to the local Ethernet broadcast address. By
definition this traffic should not be forwarded.
• Drop IP multicast. A priority-50 flow with match ip4.mcast drops IP
multicast traffic.
• ICMP time exceeded. For each router port P, whose IP address is A, a
priority-40 flow with match inport == P && ip.ttl == {0, 1} &&
!ip.later_frag matches packets whose TTL has expired, with the following
actions to send an ICMP time exceeded reply:
icmp4 {
icmp4.type = 11; /* Time exceeded. */
icmp4.code = 0; /* TTL exceeded in transit. */
ip4.dst = ip4.src;
ip4.src = A;
ip.ttl = 255;
next;
};
Not yet implemented.
• TTL discard. A priority-30 flow with match ip.ttl == {0, 1} and actions
drop; drops other packets whose TTL has expired, that should not receive a
ICMP error reply (i.e. fragments with nonzero offset).
• Next table. A priority-0 flows match all packets that aren’t already
handled and uses actions next; to feed them to the ingress table for
routing.
Ingress Table 2: IP Routing
A packet that arrives at this table is an IP packet that should be routed to the address
in ip4.dst. This table implements IP routing, setting reg0 to the next-hop IP address
(leaving ip4.dst, the packet’s final destination, unchanged) and advances to the next
table for ARP resolution.
This table contains the following logical flows:
• Routing table. For each route to IPv4 network N with netmask M, a logical
flow with match ip4.dst == N/M, whose priority is the number of 1-bits in M,
has the following actions:
ip.ttl--;
reg0 = G;
next;
(Ingress table 1 already verified that ip.ttl--; will not yield a TTL
exceeded error.)
If the route has a gateway, G is the gateway IP address, otherwise it is
ip4.dst.
• Destination unreachable. For each router port P, which owns IP address A, a
priority-0 logical flow with match in_port == P && !ip.later_frag && !icmp
has the following actions:
icmp4 {
icmp4.type = 3; /* Destination unreachable. */
icmp4.code = 0; /* Network unreachable. */
ip4.dst = ip4.src;
ip4.src = A;
ip.ttl = 255;
next(2);
};
(The !icmp check prevents recursion if the destination unreachable message
itself cannot be routed.)
These flows are omitted if the logical router has a default route, that is,
a route with netmask 0.0.0.0.
Ingress Table 3: ARP Resolution
Any packet that reaches this table is an IP packet whose next-hop IP address is in reg0.
(ip4.dst is the final destination.) This table resolves the IP address in reg0 into an
output port in outport and an Ethernet address in eth.dst, using the following flows:
• Known MAC bindings. For each IP address A whose host is known to have
Ethernet address HE and reside on router port P with Ethernet address PE, a
priority-200 flow with match reg0 == A has the following actions:
eth.src = PE;
eth.dst = HE;
outport = P;
output;
MAC bindings can be known statically based on data in the OVN_Northbound
database. For router ports connected to logical switches, MAC bindings can
be known statically from the addresses column in the Logical_Port table.
For router ports connected to other logical routers, MAC bindings can be
known statically from the mac and network column in the Logical_Router_Port
table.
• Unknown MAC bindings. For each non-gateway route to IPv4 network N with
netmask M on router port P that owns IP address A and Ethernet address E, a
logical flow with match ip4.dst == N/M, whose priority is the number of
1-bits in M, has the following actions:
arp {
eth.dst = ff:ff:ff:ff:ff:ff;
eth.src = E;
arp.sha = E;
arp.tha = 00:00:00:00:00:00;
arp.spa = A;
arp.tpa = ip4.dst;
arp.op = 1; /* ARP request. */
outport = P;
output;
};
TBD: How to install MAC bindings when an ARP response comes back.
(Implement a "learn" action?)
Not yet implemented.
Egress Table 0: Delivery
Packets that reach this table are ready for delivery. It contains priority-100 logical
flows that match packets on each enabled logical router port, with action output;.