ovn-northd(8) Open vSwitch Manual ovn-northd(8)
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 con‐
figuration 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 data‐
bases. The default is db.sock in the local Open vSwitch’s "run" direc‐
tory. 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 cur‐
rently 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 mul‐
ticast 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 ACLs
Logical flows in this table closely reproduce those in the ACL table in
the OVN_Northbound database for the from-lport direction. allow and
allow-related ACLs translate into logical flows with the next; action,
others to drop;. The priority values from the ACL table are used
directly.
Ingress table 1 also contains a priority 0 flow with action next;, so
that ACLs allow packets by default.
Ingress Table 2: Destination Lookup
This table implements switching behavior. It contains these logical
flows:
· A priority-100 flow that outputs all packets with an Eth‐
ernet broadcast or multicast eth.dst to the MC_FLOOD mul‐
ticast 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 optimiza‐
tion, if no logical ports accept unknown destination
packets, ovn-northd omits this multicast group and logi‐
cal flow.
Egress Table 0: to-lport ACLs
This is similar to ingress table 1 except for to-lport ACLs.
Egress Table 1: 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 pri‐
ority-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 logi‐
cal 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 mul‐
ticast 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 func‐
tionality.
· L3 admission control: A priority-220 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-210 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;
ip4.ttl = 255;
icmp4.type = 0;
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-210
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 = 0; /* Allow sending out inport. */
output;
· UDP port unreachable. These 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.
· TCP reset. These 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 traf‐
fic so it always generates such a reply.
These flows should not match IP fragments with nonzero
offset.
Details TBD.
· Protocol unreachable. These 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.
· 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. For each IP address A owned by the router, a pri‐
ority-200 flow matches ip4.dst == A and drops the traf‐
fic.
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-190 flow with
match eth.bcast drops traffic destined to the local Eth‐
ernet broadcast address. By definition this traffic
should not be forwarded.
· Drop IP multicast. A priority-190 flow with match
ip4.dst[28..31] == 0xe drops IP multicast traffic.
· ICMP time exceeded. For each router port P, whose IP
address is A, a priority-180 flow with match inport == P
&&&& ip4.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;
ip4.ttl = 255;
next;
};
· TTL discard. A priority-170 flow with match ip4.ttl 2
and actions drop; drops other packets whose TTL has
expired, that should not receive a ICMP error reply.
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 fol‐
lowing actions:
ip4.ttl--;
reg0 = G;
next;
(Ingress table 1 already verified that ip4.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;
ip4.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?)
Egress Table 0: Delivery
Packets that reach this table are ready for delivery. It contains pri‐
ority-100 logical flows that match packets on each enabled logical
router port, with action output;.
Open vSwitch 2.4.90 ovn-northd ovn-northd(8)