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 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 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 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.

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.

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.

This is similar to ingress table 1 except for to-lport traffic.

This is similar to ingress table 2 except for to-lport ACLs.

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

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.

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.

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.

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.

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;.