• <var id="lvoaz"></var>
      1. <output id="lvoaz"></output>
          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)
          
          现金李逵劈鱼