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 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 prior‐
       ity-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., estab‐
                     lished 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-lis‐
                     tening 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 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 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  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-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 traf‐
                     fic 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 Eth‐
                     ernet 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 fol‐
                     lowing 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 pri‐
       ority-100  logical  flows  that  match  packets on each enabled logical
       router port, with action output;.



Open vSwitch 2.5.1                ovn-northd                     ovn-northd(8)