1ovn-northd(8) Open vSwitch Manual ovn-northd(8)
2
6 ovn-northd - Open Virtual Network central control daemon
7
9 ovn-northd [options]
10
12 ovn-northd is a centralized daemon responsible for translating the
13 high-level OVN configuration into logical configuration consumable by
14 daemons such as ovn-controller. It translates the logical network con‐
15 figuration in terms of conventional network concepts, taken from the
16 OVN Northbound Database (see ovn-nb(5)), into logical datapath flows in
17 the OVN Southbound Database (see ovn-sb(5)) below it.
18
20 --ovnnb-db=database
21 The OVSDB database containing the OVN Northbound Database. If
22 the OVN_NB_DB environment variable is set, its value is used as
23 the default. Otherwise, the default is unix:/var/run/open‐
24 vswitch/ovnnb_db.sock.
25 --ovnsb-db=database
27 The OVSDB database containing the OVN Southbound Database. If
28 the OVN_SB_DB environment variable is set, its value is used as
29 the default. Otherwise, the default is unix:/var/run/open‐
30 vswitch/ovnsb_db.sock.
31 database in the above options must be an OVSDB active or passive con‐
33 nection method, as described in ovsdb(7).
34 Daemon Options
36 --pidfile[=pidfile]
37 Causes a file (by default, program.pid) to be created indicating
38 the PID of the running process. If the pidfile argument is not
39 specified, or if it does not begin with /, then it is created in
40 /var/run/openvswitch.
41 If --pidfile is not specified, no pidfile is created.
43 --overwrite-pidfile
45 By default, when --pidfile is specified and the specified pid‐
46 file already exists and is locked by a running process, the dae‐
47 mon refuses to start. Specify --overwrite-pidfile to cause it to
48 instead overwrite the pidfile.
49 When --pidfile is not specified, this option has no effect.
51 --detach
53 Runs this program as a background process. The process forks,
54 and in the child it starts a new session, closes the standard
55 file descriptors (which has the side effect of disabling logging
56 to the console), and changes its current directory to the root
57 (unless --no-chdir is specified). After the child completes its
58 initialization, the parent exits.
59 --monitor
61 Creates an additional process to monitor this program. If it
62 dies due to a signal that indicates a programming error (SIGA‐
63 BRT, SIGALRM, SIGBUS, SIGFPE, SIGILL, SIGPIPE, SIGSEGV, SIGXCPU,
64 or SIGXFSZ) then the monitor process starts a new copy of it. If
65 the daemon dies or exits for another reason, the monitor process
66 exits.
67 This option is normally used with --detach, but it also func‐
69 tions without it.
70 --no-chdir
72 By default, when --detach is specified, the daemon changes its
73 current working directory to the root directory after it
74 detaches. Otherwise, invoking the daemon from a carelessly cho‐
75 sen directory would prevent the administrator from unmounting
76 the file system that holds that directory.
77 Specifying --no-chdir suppresses this behavior, preventing the
79 daemon from changing its current working directory. This may be
80 useful for collecting core files, since it is common behavior to
81 write core dumps into the current working directory and the root
82 directory is not a good directory to use.
83 This option has no effect when --detach is not specified.
85 --no-self-confinement
87 By default this daemon will try to self-confine itself to work
88 with files under well-known directories whitelisted at build
89 time. It is better to stick with this default behavior and not
90 to use this flag unless some other Access Control is used to
91 confine daemon. Note that in contrast to other access control
92 implementations that are typically enforced from kernel-space
93 (e.g. DAC or MAC), self-confinement is imposed from the user-
94 space daemon itself and hence should not be considered as a full
95 confinement strategy, but instead should be viewed as an addi‐
96 tional layer of security.
97 --user=user:group
99 Causes this program to run as a different user specified in
100 user:group, thus dropping most of the root privileges. Short
101 forms user and :group are also allowed, with current user or
102 group assumed, respectively. Only daemons started by the root
103 user accepts this argument.
104 On Linux, daemons will be granted CAP_IPC_LOCK and
106 CAP_NET_BIND_SERVICES before dropping root privileges. Daemons
107 that interact with a datapath, such as ovs-vswitchd, will be
108 granted three additional capabilities, namely CAP_NET_ADMIN,
109 CAP_NET_BROADCAST and CAP_NET_RAW. The capability change will
110 apply even if the new user is root.
111 On Windows, this option is not currently supported. For security
113 reasons, specifying this option will cause the daemon process
114 not to start.
115 Logging Options
117 -v[spec]
118 --verbose=[spec]
119 Sets logging levels. Without any spec, sets the log level for
120 every module and destination to dbg. Otherwise, spec is a list of
121 words separated by spaces or commas or colons, up to one from each
122 category below:
123 · A valid module name, as displayed by the vlog/list command
125 on ovs-appctl(8), limits the log level change to the speci‐
126 fied module.
127 · syslog, console, or file, to limit the log level change to
129 only to the system log, to the console, or to a file,
130 respectively. (If --detach is specified, the daemon closes
131 its standard file descriptors, so logging to the console
132 will have no effect.)
133 On Windows platform, syslog is accepted as a word and is
135 only useful along with the --syslog-target option (the word
136 has no effect otherwise).
137 · off, emer, err, warn, info, or dbg, to control the log
139 level. Messages of the given severity or higher will be
140 logged, and messages of lower severity will be filtered
141 out. off filters out all messages. See ovs-appctl(8) for a
142 definition of each log level.
143 Case is not significant within spec.
145 Regardless of the log levels set for file, logging to a file will
147 not take place unless --log-file is also specified (see below).
148 For compatibility with older versions of OVS, any is accepted as a
150 word but has no effect.
151 -v
153 --verbose
154 Sets the maximum logging verbosity level, equivalent to --ver‐
155 bose=dbg.
156 -vPATTERN:destination:pattern
158 --verbose=PATTERN:destination:pattern
159 Sets the log pattern for destination to pattern. Refer to
160 ovs-appctl(8) for a description of the valid syntax for pattern.
161 -vFACILITY:facility
163 --verbose=FACILITY:facility
164 Sets the RFC5424 facility of the log message. facility can be one
165 of kern, user, mail, daemon, auth, syslog, lpr, news, uucp, clock,
166 ftp, ntp, audit, alert, clock2, local0, local1, local2, local3,
167 local4, local5, local6 or local7. If this option is not specified,
168 daemon is used as the default for the local system syslog and
169 local0 is used while sending a message to the target provided via
170 the --syslog-target option.
171 --log-file[=file]
173 Enables logging to a file. If file is specified, then it is used
174 as the exact name for the log file. The default log file name used
175 if file is omitted is /var/log/openvswitch/program.log.
176 --syslog-target=host:port
178 Send syslog messages to UDP port on host, in addition to the sys‐
179 tem syslog. The host must be a numerical IP address, not a host‐
180 name.
181 --syslog-method=method
183 Specify method as how syslog messages should be sent to syslog
184 daemon. The following forms are supported:
185 · libc, to use the libc syslog() function. This is the
187 default behavior. Downside of using this options is that
188 libc adds fixed prefix to every message before it is actu‐
189 ally sent to the syslog daemon over /dev/log UNIX domain
190 socket.
191 · unix:file, to use a UNIX domain socket directly. It is pos‐
193 sible to specify arbitrary message format with this option.
194 However, rsyslogd 8.9 and older versions use hard coded
195 parser function anyway that limits UNIX domain socket use.
196 If you want to use arbitrary message format with older
197 rsyslogd versions, then use UDP socket to localhost IP
198 address instead.
199 · udp:ip:port, to use a UDP socket. With this method it is
201 possible to use arbitrary message format also with older
202 rsyslogd. When sending syslog messages over UDP socket
203 extra precaution needs to be taken into account, for exam‐
204 ple, syslog daemon needs to be configured to listen on the
205 specified UDP port, accidental iptables rules could be
206 interfering with local syslog traffic and there are some
207 security considerations that apply to UDP sockets, but do
208 not apply to UNIX domain sockets.
209 PKI Options
211 PKI configuration is required in order to use SSL for the connections
212 to the Northbound and Southbound databases.
213 -p privkey.pem
215 --private-key=privkey.pem
216 Specifies a PEM file containing the private key used as
217 identity for outgoing SSL connections.
218 -c cert.pem
220 --certificate=cert.pem
221 Specifies a PEM file containing a certificate that certi‐
222 fies the private key specified on -p or --private-key to be
223 trustworthy. The certificate must be signed by the certifi‐
224 cate authority (CA) that the peer in SSL connections will
225 use to verify it.
226 -C cacert.pem
228 --ca-cert=cacert.pem
229 Specifies a PEM file containing the CA certificate for ver‐
230 ifying certificates presented to this program by SSL peers.
231 (This may be the same certificate that SSL peers use to
232 verify the certificate specified on -c or --certificate, or
233 it may be a different one, depending on the PKI design in
234 use.)
235 -C none
237 --ca-cert=none
238 Disables verification of certificates presented by SSL
239 peers. This introduces a security risk, because it means
240 that certificates cannot be verified to be those of known
241 trusted hosts.
242 Other Options
244 --unixctl=socket
245 Sets the name of the control socket on which program listens for
246 runtime management commands (see RUNTIME MANAGEMENT COMMANDS,
247 below). If socket does not begin with /, it is interpreted as
248 relative to /var/run/openvswitch. If --unixctl is not used at
249 all, the default socket is /var/run/openvswitch/program.pid.ctl,
250 where pid is program’s process ID.
251 On Windows a local named pipe is used to listen for runtime man‐
253 agement commands. A file is created in the absolute path as
254 pointed by socket or if --unixctl is not used at all, a file is
255 created as program in the configured OVS_RUNDIR directory. The
256 file exists just to mimic the behavior of a Unix domain socket.
257 Specifying none for socket disables the control socket feature.
259 -h
263 --help
264 Prints a brief help message to the console.
265 -V
267 --version
268 Prints version information to the console.
269
271 ovs-appctl can send commands to a running ovn-northd process. The cur‐
272 rently supported commands are described below.
273 exit Causes ovn-northd to gracefully terminate.
275
277 You may run ovn-northd more than once in an OVN deployment. OVN will
278 automatically ensure that only one of them is active at a time. If mul‐
279 tiple instances of ovn-northd are running and the active ovn-northd
280 fails, one of the hot standby instances of ovn-northd will automati‐
281 cally take over.
282
284 One of the main purposes of ovn-northd is to populate the Logical_Flow
285 table in the OVN_Southbound database. This section describes how
286 ovn-northd does this for switch and router logical datapaths.
287 Logical Switch Datapaths
289 Ingress Table 0: Admission Control and Ingress Port Security - L2
290 Ingress table 0 contains these logical flows:
292 · Priority 100 flows to drop packets with VLAN tags or mul‐
294 ticast Ethernet source addresses.
295 · Priority 50 flows that implement ingress port security
297 for each enabled logical port. For logical ports on which
298 port security is enabled, these match the inport and the
299 valid eth.src address(es) and advance only those packets
300 to the next flow table. For logical ports on which port
301 security is not enabled, these advance all packets that
302 match the inport.
303 There are no flows for disabled logical ports because the default-drop
305 behavior of logical flow tables causes packets that ingress from them
306 to be dropped.
307 Ingress Table 1: Ingress Port Security - IP
309 Ingress table 1 contains these logical flows:
311 · For each element in the port security set having one or
313 more IPv4 or IPv6 addresses (or both),
314 · Priority 90 flow to allow IPv4 traffic if it has
316 IPv4 addresses which match the inport, valid
317 eth.src and valid ip4.src address(es).
318 · Priority 90 flow to allow IPv4 DHCP discovery
320 traffic if it has a valid eth.src. This is neces‐
321 sary since DHCP discovery messages are sent from
322 the unspecified IPv4 address (0.0.0.0) since the
323 IPv4 address has not yet been assigned.
324 · Priority 90 flow to allow IPv6 traffic if it has
326 IPv6 addresses which match the inport, valid
327 eth.src and valid ip6.src address(es).
328 · Priority 90 flow to allow IPv6 DAD (Duplicate
330 Address Detection) traffic if it has a valid
331 eth.src. This is is necessary since DAD include
332 requires joining an multicast group and sending
333 neighbor solicitations for the newly assigned
334 address. Since no address is yet assigned, these
335 are sent from the unspecified IPv6 address (::).
336 · Priority 80 flow to drop IP (both IPv4 and IPv6)
338 traffic which match the inport and valid eth.src.
339 · One priority-0 fallback flow that matches all packets and
341 advances to the next table.
342 Ingress Table 2: Ingress Port Security - Neighbor discovery
344 Ingress table 2 contains these logical flows:
346 · For each element in the port security set,
348 · Priority 90 flow to allow ARP traffic which match
350 the inport and valid eth.src and arp.sha. If the
351 element has one or more IPv4 addresses, then it
352 also matches the valid arp.spa.
353 · Priority 90 flow to allow IPv6 Neighbor Solicita‐
355 tion and Advertisement traffic which match the
356 inport, valid eth.src and nd.sll/nd.tll. If the
357 element has one or more IPv6 addresses, then it
358 also matches the valid nd.target address(es) for
359 Neighbor Advertisement traffic.
360 · Priority 80 flow to drop ARP and IPv6 Neighbor
362 Solicitation and Advertisement traffic which match
363 the inport and valid eth.src.
364 · One priority-0 fallback flow that matches all packets and
366 advances to the next table.
367 Ingress Table 3: from-lport Pre-ACLs
369 This table prepares flows for possible stateful ACL processing in
371 ingress table ACLs. It contains a priority-0 flow that simply moves
372 traffic to the next table. If stateful ACLs are used in the logical
373 datapath, a priority-100 flow is added that sets a hint (with reg0[0] =
374 1; next;) for table Pre-stateful to send IP packets to the connection
375 tracker before eventually advancing to ingress table ACLs. If special
376 ports such as route ports or localnet ports can’t use ct(), a prior‐
377 ity-110 flow is added to skip over stateful ACLs.
378 Ingress Table 4: Pre-LB
380 This table prepares flows for possible stateful load balancing process‐
382 ing in ingress table LB and Stateful. It contains a priority-0 flow
383 that simply moves traffic to the next table. Moreover it contains a
384 priority-110 flow to move IPv6 Neighbor Discovery traffic to the next
385 table. If load balancing rules with virtual IP addresses (and ports)
386 are configured in OVN_Northbound database for a logical switch data‐
387 path, a priority-100 flow is added for each configured virtual IP
388 address VIP. For IPv4 VIPs, the match is ip && ip4.dst == VIP. For IPv6
389 VIPs, the match is ip && ip6.dst == VIP. The flow sets an action
390 reg0[0] = 1; next; to act as a hint for table Pre-stateful to send IP
391 packets to the connection tracker for packet de-fragmentation before
392 eventually advancing to ingress table LB.
393 Ingress Table 5: Pre-stateful
395 This table prepares flows for all possible stateful processing in next
397 tables. It contains a priority-0 flow that simply moves traffic to the
398 next table. A priority-100 flow sends the packets to connection tracker
399 based on a hint provided by the previous tables (with a match for
400 reg0[0] == 1) by using the ct_next; action.
401 Ingress table 6: from-lport ACLs
403 Logical flows in this table closely reproduce those in the ACL table in
405 the OVN_Northbound database for the from-lport direction. The priority
406 values from the ACL table have a limited range and have 1000 added to
407 them to leave room for OVN default flows at both higher and lower pri‐
408 orities.
409 · allow ACLs translate into logical flows with the next;
411 action. If there are any stateful ACLs on this datapath,
412 then allow ACLs translate to ct_commit; next; (which acts
413 as a hint for the next tables to commit the connection to
414 conntrack),
415 · allow-related ACLs translate into logical flows with the
417 ct_commit(ct_label=0/1); next; actions for new connec‐
418 tions and reg0[1] = 1; next; for existing connections.
419 · Other ACLs translate to drop; for new or untracked con‐
421 nections and ct_commit(ct_label=1/1); for known connec‐
422 tions. Setting ct_label marks a connection as one that
423 was previously allowed, but should no longer be allowed
424 due to a policy change.
425 This table also contains a priority 0 flow with action next;, so that
427 ACLs allow packets by default. If the logical datapath has a statetful
428 ACL, the following flows will also be added:
429 · A priority-1 flow that sets the hint to commit IP traffic
431 to the connection tracker (with action reg0[1] = 1;
432 next;). This is needed for the default allow policy
433 because, while the initiator’s direction may not have any
434 stateful rules, the server’s may and then its return
435 traffic would not be known and marked as invalid.
436 · A priority-65535 flow that allows any traffic in the
438 reply direction for a connection that has been committed
439 to the connection tracker (i.e., established flows), as
440 long as the committed flow does not have ct_label.blocked
441 set. We only handle traffic in the reply direction here
442 because we want all packets going in the request direc‐
443 tion to still go through the flows that implement the
444 currently defined policy based on ACLs. If a connection
445 is no longer allowed by policy, ct_label.blocked will get
446 set and packets in the reply direction will no longer be
447 allowed, either.
448 · A priority-65535 flow that allows any traffic that is
450 considered related to a committed flow in the connection
451 tracker (e.g., an ICMP Port Unreachable from a non-lis‐
452 tening UDP port), as long as the committed flow does not
453 have ct_label.blocked set.
454 · A priority-65535 flow that drops all traffic marked by
456 the connection tracker as invalid.
457 · A priority-65535 flow that drops all trafic in the reply
459 direction with ct_label.blocked set meaning that the con‐
460 nection should no longer be allowed due to a policy
461 change. Packets in the request direction are skipped here
462 to let a newly created ACL re-allow this connection.
463 Ingress Table 7: from-lport QoS Marking
465 Logical flows in this table closely reproduce those in the QoS table
467 with the action column set in the OVN_Northbound database for the
468 from-lport direction.
469 · For every qos_rules entry in a logical switch with DSCP
471 marking enabled, a flow will be added at the priority
472 mentioned in the QoS table.
473 · One priority-0 fallback flow that matches all packets and
475 advances to the next table.
476 Ingress Table 8: from-lport QoS Meter
478 Logical flows in this table closely reproduce those in the QoS table
480 with the bandwidth column set in the OVN_Northbound database for the
481 from-lport direction.
482 · For every qos_rules entry in a logical switch with meter‐
484 ing enabled, a flow will be added at the priorirty men‐
485 tioned in the QoS table.
486 · One priority-0 fallback flow that matches all packets and
488 advances to the next table.
489 Ingress Table 9: LB
491 It contains a priority-0 flow that simply moves traffic to the next ta‐
493 ble. For established connections a priority 100 flow matches on ct.est
494 && !ct.rel && !ct.new && !ct.inv and sets an action reg0[2] = 1; next;
495 to act as a hint for table Stateful to send packets through connection
496 tracker to NAT the packets. (The packet will automatically get DNATed
497 to the same IP address as the first packet in that connection.)
498 Ingress Table 10: Stateful
500 · For all the configured load balancing rules for a switch
502 in OVN_Northbound database that includes a L4 port PORT
503 of protocol P and IP address VIP, a priority-120 flow is
504 added. For IPv4 VIPs , the flow matches ct.new && ip &&
505 ip4.dst == VIP && P && P.dst == PORT. For IPv6 VIPs, the
506 flow matches ct.new && ip && ip6.dst == VIP && P && P.dst
507 == PORT. The flow’s action is ct_lb(args) , where args
508 contains comma separated IP addresses (and optional port
509 numbers) to load balance to. The address family of the IP
510 addresses of args is the same as the address family of
511 VIP
512 · For all the configured load balancing rules for a switch
514 in OVN_Northbound database that includes just an IP
515 address VIP to match on, OVN adds a priority-110 flow.
516 For IPv4 VIPs, the flow matches ct.new && ip && ip4.dst
517 == VIP. For IPv6 VIPs, the flow matches ct.new && ip &&
518 ip6.dst == VIP. The action on this flow is ct_lb(args),
519 where args contains comma separated IP addresses of the
520 same address family as VIP.
521 · A priority-100 flow commits packets to connection tracker
523 using ct_commit; next; action based on a hint provided by
524 the previous tables (with a match for reg0[1] == 1).
525 · A priority-100 flow sends the packets to connection
527 tracker using ct_lb; as the action based on a hint pro‐
528 vided by the previous tables (with a match for reg0[2] ==
529 1).
530 · A priority-0 flow that simply moves traffic to the next
532 table.
533 Ingress Table 11: ARP/ND responder
535 This table implements ARP/ND responder in a logical switch for known
537 IPs. The advantage of the ARP responder flow is to limit ARP broadcasts
538 by locally responding to ARP requests without the need to send to other
539 hypervisors. One common case is when the inport is a logical port asso‐
540 ciated with a VIF and the broadcast is responded to on the local hyper‐
541 visor rather than broadcast across the whole network and responded to
542 by the destination VM. This behavior is proxy ARP.
543 ARP requests arrive from VMs from a logical switch inport of type
545 default. For this case, the logical switch proxy ARP rules can be for
546 other VMs or logical router ports. Logical switch proxy ARP rules may
547 be programmed both for mac binding of IP addresses on other logical
548 switch VIF ports (which are of the default logical switch port type,
549 representing connectivity to VMs or containers), and for mac binding of
550 IP addresses on logical switch router type ports, representing their
551 logical router port peers. In order to support proxy ARP for logical
552 router ports, an IP address must be configured on the logical switch
553 router type port, with the same value as the peer logical router port.
554 The configured MAC addresses must match as well. When a VM sends an ARP
555 request for a distributed logical router port and if the peer router
556 type port of the attached logical switch does not have an IP address
557 configured, the ARP request will be broadcast on the logical switch.
558 One of the copies of the ARP request will go through the logical switch
559 router type port to the logical router datapath, where the logical
560 router ARP responder will generate a reply. The MAC binding of a dis‐
561 tributed logical router, once learned by an associated VM, is used for
562 all that VM’s communication needing routing. Hence, the action of a VM
563 re-arping for the mac binding of the logical router port should be
564 rare.
565 Logical switch ARP responder proxy ARP rules can also be hit when
567 receiving ARP requests externally on a L2 gateway port. In this case,
568 the hypervisor acting as an L2 gateway, responds to the ARP request on
569 behalf of a destination VM.
570 Note that ARP requests received from localnet or vtep logical inports
572 can either go directly to VMs, in which case the VM responds or can hit
573 an ARP responder for a logical router port if the packet is used to
574 resolve a logical router port next hop address. In either case, logical
575 switch ARP responder rules will not be hit. It contains these logical
576 flows:
577 · Priority-100 flows to skip the ARP responder if inport is
579 of type localnet or vtep and advances directly to the
580 next table. ARP requests sent to localnet or vtep ports
581 can be received by multiple hypervisors. Now, because the
582 same mac binding rules are downloaded to all hypervisors,
583 each of the multiple hypervisors will respond. This will
584 confuse L2 learning on the source of the ARP requests.
585 ARP requests received on an inport of type router are not
586 expected to hit any logical switch ARP responder flows.
587 However, no skip flows are installed for these packets,
588 as there would be some additional flow cost for this and
589 the value appears limited.
590 · Priority-50 flows that match ARP requests to each known
592 IP address A of every logical switch port, and respond
593 with ARP replies directly with corresponding Ethernet
594 address E:
595 eth.dst = eth.src;
597 eth.src = E;
598 arp.op = 2; /* ARP reply. */
599 arp.tha = arp.sha;
600 arp.sha = E;
601 arp.tpa = arp.spa;
602 arp.spa = A;
603 outport = inport;
604 flags.loopback = 1;
605 output;
606 These flows are omitted for logical ports (other than
609 router ports or localport ports) that are down.
610 · Priority-50 flows that match IPv6 ND neighbor solicita‐
612 tions to each known IP address A (and A’s solicited node
613 address) of every logical switch port except of type
614 router, and respond with neighbor advertisements directly
615 with corresponding Ethernet address E:
616 nd_na {
618 eth.src = E;
619 ip6.src = A;
620 nd.target = A;
621 nd.tll = E;
622 outport = inport;
623 flags.loopback = 1;
624 output;
625 };
626 Priority-50 flows that match IPv6 ND neighbor solicita‐
629 tions to each known IP address A (and A’s solicited node
630 address) of logical switch port of type router, and
631 respond with neighbor advertisements directly with corre‐
632 sponding Ethernet address E:
633 nd_na_router {
635 eth.src = E;
636 ip6.src = A;
637 nd.target = A;
638 nd.tll = E;
639 outport = inport;
640 flags.loopback = 1;
641 output;
642 };
643 These flows are omitted for logical ports (other than
646 router ports or localport ports) that are down.
647 · Priority-100 flows with match criteria like the ARP and
649 ND flows above, except that they only match packets from
650 the inport that owns the IP addresses in question, with
651 action next;. These flows prevent OVN from replying to,
652 for example, an ARP request emitted by a VM for its own
653 IP address. A VM only makes this kind of request to
654 attempt to detect a duplicate IP address assignment, so
655 sending a reply will prevent the VM from accepting the IP
656 address that it owns.
657 In place of next;, it would be reasonable to use drop;
659 for the flows’ actions. If everything is working as it is
660 configured, then this would produce equivalent results,
661 since no host should reply to the request. But ARPing for
662 one’s own IP address is intended to detect situations
663 where the network is not working as configured, so drop‐
664 ping the request would frustrate that intent.
665 · One priority-0 fallback flow that matches all packets and
667 advances to the next table.
668 Ingress Table 12: DHCP option processing
670 This table adds the DHCPv4 options to a DHCPv4 packet from the logical
672 ports configured with IPv4 address(es) and DHCPv4 options, and simi‐
673 larly for DHCPv6 options.
674 · A priority-100 logical flow is added for these logical
676 ports which matches the IPv4 packet with udp.src = 68 and
677 udp.dst = 67 and applies the action put_dhcp_opts and
678 advances the packet to the next table.
679 reg0[3] = put_dhcp_opts(offer_ip = ip, options...);
681 next;
682 For DHCPDISCOVER and DHCPREQUEST, this transforms the
685 packet into a DHCP reply, adds the DHCP offer IP ip and
686 options to the packet, and stores 1 into reg0[3]. For
687 other kinds of packets, it just stores 0 into reg0[3].
688 Either way, it continues to the next table.
689 · A priority-100 logical flow is added for these logical
691 ports which matches the IPv6 packet with udp.src = 546
692 and udp.dst = 547 and applies the action put_dhcpv6_opts
693 and advances the packet to the next table.
694 reg0[3] = put_dhcpv6_opts(ia_addr = ip, options...);
696 next;
697 For DHCPv6 Solicit/Request/Confirm packets, this trans‐
700 forms the packet into a DHCPv6 Advertise/Reply, adds the
701 DHCPv6 offer IP ip and options to the packet, and stores
702 1 into reg0[3]. For other kinds of packets, it just
703 stores 0 into reg0[3]. Either way, it continues to the
704 next table.
705 · A priority-0 flow that matches all packets to advances to
707 table 11.
708 Ingress Table 13: DHCP responses
710 This table implements DHCP responder for the DHCP replies generated by
712 the previous table.
713 · A priority 100 logical flow is added for the logical
715 ports configured with DHCPv4 options which matches IPv4
716 packets with udp.src == 68 && udp.dst == 67 && reg0[3] ==
717 1 and responds back to the inport after applying these
718 actions. If reg0[3] is set to 1, it means that the action
719 put_dhcp_opts was successful.
720 eth.dst = eth.src;
722 eth.src = E;
723 ip4.dst = A;
724 ip4.src = S;
725 udp.src = 67;
726 udp.dst = 68;
727 outport = P;
728 flags.loopback = 1;
729 output;
730 where E is the server MAC address and S is the server
733 IPv4 address defined in the DHCPv4 options and A is the
734 IPv4 address defined in the logical port’s addresses col‐
735 umn.
736 (This terminates ingress packet processing; the packet
738 does not go to the next ingress table.)
739 · A priority 100 logical flow is added for the logical
741 ports configured with DHCPv6 options which matches IPv6
742 packets with udp.src == 546 && udp.dst == 547 && reg0[3]
743 == 1 and responds back to the inport after applying these
744 actions. If reg0[3] is set to 1, it means that the action
745 put_dhcpv6_opts was successful.
746 eth.dst = eth.src;
748 eth.src = E;
749 ip6.dst = A;
750 ip6.src = S;
751 udp.src = 547;
752 udp.dst = 546;
753 outport = P;
754 flags.loopback = 1;
755 output;
756 where E is the server MAC address and S is the server
759 IPv6 LLA address generated from the server_id defined in
760 the DHCPv6 options and A is the IPv6 address defined in
761 the logical port’s addresses column.
762 (This terminates packet processing; the packet does not
764 go on the next ingress table.)
765 · A priority-0 flow that matches all packets to advances to
767 table 12.
768 Ingress Table 14 DNS Lookup
770 This table looks up and resolves the DNS names to the corresponding
772 configured IP address(es).
773 · A priority-100 logical flow for each logical switch data‐
775 path if it is configured with DNS records, which matches
776 the IPv4 and IPv6 packets with udp.dst = 53 and applies
777 the action dns_lookup and advances the packet to the next
778 table.
779 reg0[4] = dns_lookup(); next;
781 For valid DNS packets, this transforms the packet into a
784 DNS reply if the DNS name can be resolved, and stores 1
785 into reg0[4]. For failed DNS resolution or other kinds of
786 packets, it just stores 0 into reg0[4]. Either way, it
787 continues to the next table.
788 Ingress Table 15 DNS Responses
790 This table implements DNS responder for the DNS replies generated by
792 the previous table.
793 · A priority-100 logical flow for each logical switch data‐
795 path if it is configured with DNS records, which matches
796 the IPv4 and IPv6 packets with udp.dst = 53 && reg0[4] ==
797 1 and responds back to the inport after applying these
798 actions. If reg0[4] is set to 1, it means that the action
799 dns_lookup was successful.
800 eth.dst <-> eth.src;
802 ip4.src <-> ip4.dst;
803 udp.dst = udp.src;
804 udp.src = 53;
805 outport = P;
806 flags.loopback = 1;
807 output;
808 (This terminates ingress packet processing; the packet
811 does not go to the next ingress table.)
812 Ingress Table 16 Destination Lookup
814 This table implements switching behavior. It contains these logical
816 flows:
817 · A priority-100 flow that outputs all packets with an Eth‐
819 ernet broadcast or multicast eth.dst to the MC_FLOOD mul‐
820 ticast group, which ovn-northd populates with all enabled
821 logical ports.
822 · One priority-50 flow that matches each known Ethernet
824 address against eth.dst and outputs the packet to the
825 single associated output port.
826 For the Ethernet address on a logical switch port of type
828 router, when that logical switch port’s addresses column
829 is set to router and the connected logical router port
830 specifies a redirect-chassis:
831 · The flow for the connected logical router port’s
833 Ethernet address is only programmed on the redi‐
834 rect-chassis.
835 · If the logical router has rules specified in nat
837 with external_mac, then those addresses are also
838 used to populate the switch’s destination lookup
839 on the chassis where logical_port is resident.
840 · One priority-0 fallback flow that matches all packets and
842 outputs them to the MC_UNKNOWN multicast group, which
843 ovn-northd populates with all enabled logical ports that
844 accept unknown destination packets. As a small optimiza‐
845 tion, if no logical ports accept unknown destination
846 packets, ovn-northd omits this multicast group and logi‐
847 cal flow.
848 Egress Table 0: Pre-LB
850 This table is similar to ingress table Pre-LB. It contains a priority-0
852 flow that simply moves traffic to the next table. Moreover it contains
853 a priority-110 flow to move IPv6 Neighbor Discovery traffic to the next
854 table. If any load balancing rules exist for the datapath, a prior‐
855 ity-100 flow is added with a match of ip and action of reg0[0] = 1;
856 next; to act as a hint for table Pre-stateful to send IP packets to the
857 connection tracker for packet de-fragmentation.
858 Egress Table 1: to-lport Pre-ACLs
860 This is similar to ingress table Pre-ACLs except for to-lport traffic.
862 Egress Table 2: Pre-stateful
864 This is similar to ingress table Pre-stateful.
866 Egress Table 3: LB
868 This is similar to ingress table LB.
870 Egress Table 4: to-lport ACLs
872 This is similar to ingress table ACLs except for to-lport ACLs.
874 In addition, the following flows are added.
876 · A priority 34000 logical flow is added for each logical
878 port which has DHCPv4 options defined to allow the DHCPv4
879 reply packet and which has DHCPv6 options defined to
880 allow the DHCPv6 reply packet from the Ingress Table 13:
881 DHCP responses.
882 · A priority 34000 logical flow is added for each logical
884 switch datapath configured with DNS records with the
885 match udp.dst = 53 to allow the DNS reply packet from the
886 Ingress Table 15:DNS responses.
887 Egress Table 5: to-lport QoS Marking
889 This is similar to ingress table QoS marking except they apply to
891 to-lport QoS rules.
892 Egress Table 6: to-lport QoS Meter
894 This is similar to ingress table QoS meter except they apply to
896 to-lport QoS rules.
897 Egress Table 7: Stateful
899 This is similar to ingress table Stateful except that there are no
901 rules added for load balancing new connections.
902 Egress Table 8: Egress Port Security - IP
904 This is similar to the port security logic in table Ingress Port Secu‐
906 rity - IP except that outport, eth.dst, ip4.dst and ip6.dst are checked
907 instead of inport, eth.src, ip4.src and ip6.src
908 Egress Table 9: Egress Port Security - L2
910 This is similar to the ingress port security logic in ingress table
912 Admission Control and Ingress Port Security - L2, but with important
913 differences. Most obviously, outport and eth.dst are checked instead of
914 inport and eth.src. Second, packets directed to broadcast or multicast
915 eth.dst are always accepted instead of being subject to the port secu‐
916 rity rules; this is implemented through a priority-100 flow that
917 matches on eth.mcast with action output;. Finally, to ensure that even
918 broadcast and multicast packets are not delivered to disabled logical
919 ports, a priority-150 flow for each disabled logical outport overrides
920 the priority-100 flow with a drop; action.
921 Logical Router Datapaths
923 Logical router datapaths will only exist for Logical_Router rows in the
924 OVN_Northbound database that do not have enabled set to false
925 Ingress Table 0: L2 Admission Control
927 This table drops packets that the router shouldn’t see at all based on
929 their Ethernet headers. It contains the following flows:
930 · Priority-100 flows to drop packets with VLAN tags or mul‐
932 ticast Ethernet source addresses.
933 · For each enabled router port P with Ethernet address E, a
935 priority-50 flow that matches inport == P && (eth.mcast
936 || eth.dst == E), with action next;.
937 For the gateway port on a distributed logical router
939 (where one of the logical router ports specifies a redi‐
940 rect-chassis), the above flow matching eth.dst == E is
941 only programmed on the gateway port instance on the redi‐
942 rect-chassis.
943 · For each dnat_and_snat NAT rule on a distributed router
945 that specifies an external Ethernet address E, a prior‐
946 ity-50 flow that matches inport == GW && eth.dst == E,
947 where GW is the logical router gateway port, with action
948 next;.
949 This flow is only programmed on the gateway port instance
951 on the chassis where the logical_port specified in the
952 NAT rule resides.
953 Other packets are implicitly dropped.
955 Ingress Table 1: IP Input
957 This table is the core of the logical router datapath functionality. It
959 contains the following flows to implement very basic IP host function‐
960 ality.
961 · L3 admission control: A priority-100 flow drops packets
963 that match any of the following:
964 · ip4.src[28..31] == 0xe (multicast source)
966 · ip4.src == 255.255.255.255 (broadcast source)
968 · ip4.src == 127.0.0.0/8 || ip4.dst == 127.0.0.0/8
970 (localhost source or destination)
971 · ip4.src == 0.0.0.0/8 || ip4.dst == 0.0.0.0/8 (zero
973 network source or destination)
974 · ip4.src or ip6.src is any IP address owned by the
976 router, unless the packet was recirculated due to
977 egress loopback as indicated by REG‐
978 BIT_EGRESS_LOOPBACK.
979 · ip4.src is the broadcast address of any IP network
981 known to the router.
982 · ICMP echo reply. These flows reply to ICMP echo requests
984 received for the router’s IP address. Let A be an IP
985 address owned by a router port. Then, for each A that is
986 an IPv4 address, a priority-90 flow matches on ip4.dst ==
987 A and icmp4.type == 8 && icmp4.code == 0 (ICMP echo
988 request). For each A that is an IPv6 address, a prior‐
989 ity-90 flow matches on ip6.dst == A and icmp6.type == 128
990 && icmp6.code == 0 (ICMPv6 echo request). The port of the
991 router that receives the echo request does not matter.
992 Also, the ip.ttl of the echo request packet is not
993 checked, so it complies with RFC 1812, section 4.2.2.9.
994 Flows for ICMPv4 echo requests use the following actions:
995 ip4.dst <-> ip4.src;
997 ip.ttl = 255;
998 icmp4.type = 0;
999 flags.loopback = 1;
1000 next;
1001 Flows for ICMPv6 echo requests use the following actions:
1004 ip6.dst <-> ip6.src;
1006 ip.ttl = 255;
1007 icmp6.type = 129;
1008 flags.loopback = 1;
1009 next;
1010 · Reply to ARP requests.
1013 These flows reply to ARP requests for the router’s own IP
1015 address and populates mac binding table of the logical
1016 router port. The ARP requests are handled only if the
1017 requestor’s IP belongs to the same subnets of the logical
1018 router port. For each router port P that owns IP address
1019 A, which belongs to subnet S with prefix length L, and
1020 Ethernet address E, a priority-90 flow matches inport ==
1021 P && arp.spa == S/L && arp.op == 1 && arp.tpa == A (ARP
1022 request) with the following actions:
1023 put_arp(inport, arp.spa, arp.sha);
1025 eth.dst = eth.src;
1026 eth.src = E;
1027 arp.op = 2; /* ARP reply. */
1028 arp.tha = arp.sha;
1029 arp.sha = E;
1030 arp.tpa = arp.spa;
1031 arp.spa = A;
1032 outport = P;
1033 flags.loopback = 1;
1034 output;
1035 For the gateway port on a distributed logical router
1038 (where one of the logical router ports specifies a redi‐
1039 rect-chassis), the above flows are only programmed on the
1040 gateway port instance on the redirect-chassis. This
1041 behavior avoids generation of multiple ARP responses from
1042 different chassis, and allows upstream MAC learning to
1043 point to the redirect-chassis.
1044 · These flows handles ARP requests not for router’s own IP
1046 address. They use the SPA and SHA to populate the logical
1047 router port’s mac binding table, with priority 80. The
1048 typical use case of these flows are GARP requests han‐
1049 dling. For the gateway port on a distributed logical
1050 router, these flows are only programmed on the gateway
1051 port instance on the redirect-chassis.
1052 · These flows reply to ARP requests for the virtual IP
1054 addresses configured in the router for DNAT or load bal‐
1055 ancing. For a configured DNAT IP address or a load bal‐
1056 ancer IPv4 VIP A, for each router port P with Ethernet
1057 address E, a priority-90 flow matches inport == P &&
1058 arp.op == 1 && arp.tpa == A (ARP request) with the fol‐
1059 lowing actions:
1060 eth.dst = eth.src;
1062 eth.src = E;
1063 arp.op = 2; /* ARP reply. */
1064 arp.tha = arp.sha;
1065 arp.sha = E;
1066 arp.tpa = arp.spa;
1067 arp.spa = A;
1068 outport = P;
1069 flags.loopback = 1;
1070 output;
1071 For the gateway port on a distributed logical router with
1074 NAT (where one of the logical router ports specifies a
1075 redirect-chassis):
1076 · If the corresponding NAT rule cannot be handled in
1078 a distributed manner, then this flow is only pro‐
1079 grammed on the gateway port instance on the redi‐
1080 rect-chassis. This behavior avoids generation of
1081 multiple ARP responses from different chassis, and
1082 allows upstream MAC learning to point to the redi‐
1083 rect-chassis.
1084 · If the corresponding NAT rule can be handled in a
1086 distributed manner, then this flow is only pro‐
1087 grammed on the gateway port instance where the
1088 logical_port specified in the NAT rule resides.
1089 Some of the actions are different for this case,
1091 using the external_mac specified in the NAT rule
1092 rather than the gateway port’s Ethernet address E:
1093 eth.src = external_mac;
1095 arp.sha = external_mac;
1096 This behavior avoids generation of multiple ARP
1099 responses from different chassis, and allows
1100 upstream MAC learning to point to the correct
1101 chassis.
1102 · ARP reply handling. This flow uses ARP replies to popu‐
1104 late the logical router’s ARP table. A priority-90 flow
1105 with match arp.op == 2 has actions put_arp(inport,
1106 arp.spa, arp.sha);.
1107 · Reply to IPv6 Neighbor Solicitations. These flows reply
1109 to Neighbor Solicitation requests for the router’s own
1110 IPv6 address and load balancing IPv6 VIPs and populate
1111 the logical router’s mac binding table.
1112 For each router port P that owns IPv6 address A,
1114 solicited node address S, and Ethernet address E, a pri‐
1115 ority-90 flow matches inport == P && nd_ns && ip6.dst ==
1116 {A, E} && nd.target == A with the following actions:
1117 put_nd(inport, ip6.src, nd.sll);
1119 nd_na_router {
1120 eth.src = E;
1121 ip6.src = A;
1122 nd.target = A;
1123 nd.tll = E;
1124 outport = inport;
1125 flags.loopback = 1;
1126 output;
1127 };
1128 For each router port P that has load balancing VIP A,
1131 solicited node address S, and Ethernet address E, a pri‐
1132 ority-90 flow matches inport == P && nd_ns && ip6.dst ==
1133 {A, E} && nd.target == A with the following actions:
1134 put_nd(inport, ip6.src, nd.sll);
1136 nd_na {
1137 eth.src = E;
1138 ip6.src = A;
1139 nd.target = A;
1140 nd.tll = E;
1141 outport = inport;
1142 flags.loopback = 1;
1143 output;
1144 };
1145 For the gateway port on a distributed logical router
1148 (where one of the logical router ports specifies a redi‐
1149 rect-chassis), the above flows replying to IPv6 Neighbor
1150 Solicitations are only programmed on the gateway port
1151 instance on the redirect-chassis. This behavior avoids
1152 generation of multiple replies from different chassis,
1153 and allows upstream MAC learning to point to the redi‐
1154 rect-chassis.
1155 · IPv6 neighbor advertisement handling. This flow uses
1157 neighbor advertisements to populate the logical router’s
1158 mac binding table. A priority-90 flow with match nd_na
1159 has actions put_nd(inport, nd.target, nd.tll);.
1160 · IPv6 neighbor solicitation for non-hosted addresses han‐
1162 dling. This flow uses neighbor solicitations to populate
1163 the logical router’s mac binding table (ones that were
1164 directed at the logical router would have matched the
1165 priority-90 neighbor solicitation flow already). A prior‐
1166 ity-80 flow with match nd_ns has actions put_nd(inport,
1167 ip6.src, nd.sll);.
1168 · UDP port unreachable. Priority-80 flows generate ICMP
1170 port unreachable messages in reply to UDP datagrams
1171 directed to the router’s IP address, except in the spe‐
1172 cial case of gateways, which accept traffic directed to a
1173 router IP for load balancing and NAT purposes.
1174 These flows should not match IP fragments with nonzero
1176 offset.
1177 · TCP reset. Priority-80 flows generate TCP reset messages
1179 in reply to TCP datagrams directed to the router’s IP
1180 address, except in the special case of gateways, which
1181 accept traffic directed to a router IP for load balancing
1182 and NAT purposes.
1183 These flows should not match IP fragments with nonzero
1185 offset.
1186 · Protocol or address unreachable. Priority-70 flows gener‐
1188 ate ICMP protocol or address unreachable messages for
1189 IPv4 and IPv6 respectively in reply to packets directed
1190 to the router’s IP address on IP protocols other than
1191 UDP, TCP, and ICMP, except in the special case of gate‐
1192 ways, which accept traffic directed to a router IP for
1193 load balancing purposes.
1194 These flows should not match IP fragments with nonzero
1196 offset.
1197 · Drop other IP traffic to this router. These flows drop
1199 any other traffic destined to an IP address of this
1200 router that is not already handled by one of the flows
1201 above, which amounts to ICMP (other than echo requests)
1202 and fragments with nonzero offsets. For each IP address A
1203 owned by the router, a priority-60 flow matches ip4.dst
1204 == A and drops the traffic. An exception is made and the
1205 above flow is not added if the router port’s own IP
1206 address is used to SNAT packets passing through that
1207 router.
1208 The flows above handle all of the traffic that might be directed to the
1210 router itself. The following flows (with lower priorities) handle the
1211 remaining traffic, potentially for forwarding:
1212 · Drop Ethernet local broadcast. A priority-50 flow with
1214 match eth.bcast drops traffic destined to the local Eth‐
1215 ernet broadcast address. By definition this traffic
1216 should not be forwarded.
1217 · ICMP time exceeded. For each router port P, whose IP
1219 address is A, a priority-40 flow with match inport == P
1220 && ip.ttl == {0, 1} && !ip.later_frag matches packets
1221 whose TTL has expired, with the following actions to send
1222 an ICMP time exceeded reply for IPv4 and IPv6 respec‐
1223 tively:
1224 icmp4 {
1226 icmp4.type = 11; /* Time exceeded. */
1227 icmp4.code = 0; /* TTL exceeded in transit. */
1228 ip4.dst = ip4.src;
1229 ip4.src = A;
1230 ip.ttl = 255;
1231 next;
1232 };
1233 icmp6 {
1234 icmp6.type = 3; /* Time exceeded. */
1235 icmp6.code = 0; /* TTL exceeded in transit. */
1236 ip6.dst = ip6.src;
1237 ip6.src = A;
1238 ip.ttl = 255;
1239 next;
1240 };
1241 · TTL discard. A priority-30 flow with match ip.ttl == {0,
1244 1} and actions drop; drops other packets whose TTL has
1245 expired, that should not receive a ICMP error reply (i.e.
1246 fragments with nonzero offset).
1247 · Next table. A priority-0 flows match all packets that
1249 aren’t already handled and uses actions next; to feed
1250 them to the next table.
1251 Ingress Table 2: DEFRAG
1253 This is to send packets to connection tracker for tracking and defrag‐
1255 mentation. It contains a priority-0 flow that simply moves traffic to
1256 the next table. If load balancing rules with virtual IP addresses (and
1257 ports) are configured in OVN_Northbound database for a Gateway router,
1258 a priority-100 flow is added for each configured virtual IP address
1259 VIP. For IPv4 VIPs the flow matches ip && ip4.dst == VIP. For IPv6
1260 VIPs, the flow matches ip && ip6.dst == VIP. The flow uses the action
1261 ct_next; to send IP packets to the connection tracker for packet de-
1262 fragmentation and tracking before sending it to the next table.
1263 Ingress Table 3: UNSNAT
1265 This is for already established connections’ reverse traffic. i.e.,
1267 SNAT has already been done in egress pipeline and now the packet has
1268 entered the ingress pipeline as part of a reply. It is unSNATted here.
1269 Ingress Table 3: UNSNAT on Gateway Routers
1271 · If the Gateway router has been configured to force SNAT
1273 any previously DNATted packets to B, a priority-110 flow
1274 matches ip && ip4.dst == B with an action ct_snat; .
1275 If the Gateway router has been configured to force SNAT
1277 any previously load-balanced packets to B, a priority-100
1278 flow matches ip && ip4.dst == B with an action ct_snat; .
1279 For each NAT configuration in the OVN Northbound data‐
1281 base, that asks to change the source IP address of a
1282 packet from A to B, a priority-90 flow matches ip &&
1283 ip4.dst == B with an action ct_snat; .
1284 A priority-0 logical flow with match 1 has actions next;.
1286 Ingress Table 3: UNSNAT on Distributed Routers
1288 · For each configuration in the OVN Northbound database,
1290 that asks to change the source IP address of a packet
1291 from A to B, a priority-100 flow matches ip && ip4.dst ==
1292 B && inport == GW, where GW is the logical router gateway
1293 port, with an action ct_snat;.
1294 If the NAT rule cannot be handled in a distributed man‐
1296 ner, then the priority-100 flow above is only programmed
1297 on the redirect-chassis.
1298 For each configuration in the OVN Northbound database,
1300 that asks to change the source IP address of a packet
1301 from A to B, a priority-50 flow matches ip && ip4.dst ==
1302 B with an action REGBIT_NAT_REDIRECT = 1; next;. This
1303 flow is for east/west traffic to a NAT destination IPv4
1304 address. By setting the REGBIT_NAT_REDIRECT flag, in the
1305 ingress table Gateway Redirect this will trigger a redi‐
1306 rect to the instance of the gateway port on the redi‐
1307 rect-chassis.
1308 A priority-0 logical flow with match 1 has actions next;.
1310 Ingress Table 4: DNAT
1312 Packets enter the pipeline with destination IP address that needs to be
1314 DNATted from a virtual IP address to a real IP address. Packets in the
1315 reverse direction needs to be unDNATed.
1316 Ingress Table 4: Load balancing DNAT rules
1318 Following load balancing DNAT flows are added for Gateway router or
1320 Router with gateway port. These flows are programmed only on the redi‐
1321 rect-chassis. These flows do not get programmed for load balancers with
1322 IPv6 VIPs.
1323 · For all the configured load balancing rules for a Gateway
1325 router or Router with gateway port in OVN_Northbound
1326 database that includes a L4 port PORT of protocol P and
1327 IPv4 address VIP, a priority-120 flow that matches on
1328 ct.new && ip && ip4.dst == VIP && P && P.dst == PORT
1329 with an action of ct_lb(args), where args contains comma
1330 separated IPv4 addresses (and optional port numbers) to
1331 load balance to. If the router is configured to force
1332 SNAT any load-balanced packets, the above action will be
1333 replaced by flags.force_snat_for_lb = 1; ct_lb(args);.
1334 · For all the configured load balancing rules for a router
1336 in OVN_Northbound database that includes a L4 port PORT
1337 of protocol P and IPv4 address VIP, a priority-120 flow
1338 that matches on ct.est && ip && ip4.dst == VIP && P &&
1339 P.dst == PORT
1340 with an action of ct_dnat;. If the router is configured
1341 to force SNAT any load-balanced packets, the above action
1342 will be replaced by flags.force_snat_for_lb = 1;
1343 ct_dnat;.
1344 · For all the configured load balancing rules for a router
1346 in OVN_Northbound database that includes just an IP
1347 address VIP to match on, a priority-110 flow that matches
1348 on ct.new && ip && ip4.dst == VIP with an action of
1349 ct_lb(args), where args contains comma separated IPv4
1350 addresses. If the router is configured to force SNAT any
1351 load-balanced packets, the above action will be replaced
1352 by flags.force_snat_for_lb = 1; ct_lb(args);.
1353 · For all the configured load balancing rules for a router
1355 in OVN_Northbound database that includes just an IP
1356 address VIP to match on, a priority-110 flow that matches
1357 on ct.est && ip && ip4.dst == VIP with an action of
1358 ct_dnat;. If the router is configured to force SNAT any
1359 load-balanced packets, the above action will be replaced
1360 by flags.force_snat_for_lb = 1; ct_dnat;.
1361 Ingress Table 4: DNAT on Gateway Routers
1363 · For each configuration in the OVN Northbound database,
1365 that asks to change the destination IP address of a
1366 packet from A to B, a priority-100 flow matches ip &&
1367 ip4.dst == A with an action flags.loopback = 1;
1368 ct_dnat(B);. If the Gateway router is configured to force
1369 SNAT any DNATed packet, the above action will be replaced
1370 by flags.force_snat_for_dnat = 1; flags.loopback = 1;
1371 ct_dnat(B);.
1372 · For all IP packets of a Gateway router, a priority-50
1374 flow with an action flags.loopback = 1; ct_dnat;.
1375 · A priority-0 logical flow with match 1 has actions next;.
1377 Ingress Table 4: DNAT on Distributed Routers
1379 On distributed routers, the DNAT table only handles packets with desti‐
1381 nation IP address that needs to be DNATted from a virtual IP address to
1382 a real IP address. The unDNAT processing in the reverse direction is
1383 handled in a separate table in the egress pipeline.
1384 · For each configuration in the OVN Northbound database,
1386 that asks to change the destination IP address of a
1387 packet from A to B, a priority-100 flow matches ip &&
1388 ip4.dst == B && inport == GW, where GW is the logical
1389 router gateway port, with an action ct_dnat(B);.
1390 If the NAT rule cannot be handled in a distributed man‐
1392 ner, then the priority-100 flow above is only programmed
1393 on the redirect-chassis.
1394 For each configuration in the OVN Northbound database,
1396 that asks to change the destination IP address of a
1397 packet from A to B, a priority-50 flow matches ip &&
1398 ip4.dst == B with an action REGBIT_NAT_REDIRECT = 1;
1399 next;. This flow is for east/west traffic to a NAT desti‐
1400 nation IPv4 address. By setting the REGBIT_NAT_REDIRECT
1401 flag, in the ingress table Gateway Redirect this will
1402 trigger a redirect to the instance of the gateway port on
1403 the redirect-chassis.
1404 A priority-0 logical flow with match 1 has actions next;.
1406 Ingress Table 5: IPv6 ND RA option processing
1408 · A priority-50 logical flow is added for each logical
1410 router port configured with IPv6 ND RA options which
1411 matches IPv6 ND Router Solicitation packet and applies
1412 the action put_nd_ra_opts and advances the packet to the
1413 next table.
1414 reg0[5] = put_nd_ra_opts(options);next;
1416 For a valid IPv6 ND RS packet, this transforms the packet
1419 into an IPv6 ND RA reply and sets the RA options to the
1420 packet and stores 1 into reg0[5]. For other kinds of
1421 packets, it just stores 0 into reg0[5]. Either way, it
1422 continues to the next table.
1423 · A priority-0 logical flow with match 1 has actions next;.
1425 Ingress Table 6: IPv6 ND RA responder
1427 This table implements IPv6 ND RA responder for the IPv6 ND RA replies
1429 generated by the previous table.
1430 · A priority-50 logical flow is added for each logical
1432 router port configured with IPv6 ND RA options which
1433 matches IPv6 ND RA packets and reg0[5] == 1 and responds
1434 back to the inport after applying these actions. If
1435 reg0[5] is set to 1, it means that the action
1436 put_nd_ra_opts was successful.
1437 eth.dst = eth.src;
1439 eth.src = E;
1440 ip6.dst = ip6.src;
1441 ip6.src = I;
1442 outport = P;
1443 flags.loopback = 1;
1444 output;
1445 where E is the MAC address and I is the IPv6 link local
1448 address of the logical router port.
1449 (This terminates packet processing in ingress pipeline;
1451 the packet does not go to the next ingress table.)
1452 · A priority-0 logical flow with match 1 has actions next;.
1454 Ingress Table 7: IP Routing
1456 A packet that arrives at this table is an IP packet that should be
1458 routed to the address in ip4.dst or ip6.dst. This table implements IP
1459 routing, setting reg0 (or xxreg0 for IPv6) to the next-hop IP address
1460 (leaving ip4.dst or ip6.dst, the packet’s final destination, unchanged)
1461 and advances to the next table for ARP resolution. It also sets reg1
1462 (or xxreg1) to the IP address owned by the selected router port
1463 (ingress table ARP Request will generate an ARP request, if needed,
1464 with reg0 as the target protocol address and reg1 as the source proto‐
1465 col address).
1466 This table contains the following logical flows:
1468 · For distributed logical routers where one of the logical
1470 router ports specifies a redirect-chassis, a priority-300
1471 logical flow with match REGBIT_NAT_REDIRECT == 1 has
1472 actions ip.ttl--; next;. The outport will be set later in
1473 the Gateway Redirect table.
1474 · IPv4 routing table. For each route to IPv4 network N with
1476 netmask M, on router port P with IP address A and Ether‐
1477 net address E, a logical flow with match ip4.dst == N/M,
1478 whose priority is the number of 1-bits in M, has the fol‐
1479 lowing actions:
1480 ip.ttl--;
1482 reg0 = G;
1483 reg1 = A;
1484 eth.src = E;
1485 outport = P;
1486 flags.loopback = 1;
1487 next;
1488 (Ingress table 1 already verified that ip.ttl--; will not
1491 yield a TTL exceeded error.)
1492 If the route has a gateway, G is the gateway IP address.
1494 Instead, if the route is from a configured static route,
1495 G is the next hop IP address. Else it is ip4.dst.
1496 · IPv6 routing table. For each route to IPv6 network N with
1498 netmask M, on router port P with IP address A and Ether‐
1499 net address E, a logical flow with match in CIDR notation
1500 ip6.dst == N/M, whose priority is the integer value of M,
1501 has the following actions:
1502 ip.ttl--;
1504 xxreg0 = G;
1505 xxreg1 = A;
1506 eth.src = E;
1507 outport = P;
1508 flags.loopback = 1;
1509 next;
1510 (Ingress table 1 already verified that ip.ttl--; will not
1513 yield a TTL exceeded error.)
1514 If the route has a gateway, G is the gateway IP address.
1516 Instead, if the route is from a configured static route,
1517 G is the next hop IP address. Else it is ip6.dst.
1518 If the address A is in the link-local scope, the route
1520 will be limited to sending on the ingress port.
1521 Ingress Table 8: ARP/ND Resolution
1523 Any packet that reaches this table is an IP packet whose next-hop IPv4
1525 address is in reg0 or IPv6 address is in xxreg0. (ip4.dst or ip6.dst
1526 contains the final destination.) This table resolves the IP address in
1527 reg0 (or xxreg0) into an output port in outport and an Ethernet address
1528 in eth.dst, using the following flows:
1529 · For distributed logical routers where one of the logical
1531 router ports specifies a redirect-chassis, a priority-200
1532 logical flow with match REGBIT_NAT_REDIRECT == 1 has
1533 actions eth.dst = E; next;, where E is the ethernet
1534 address of the router’s distributed gateway port.
1535 · Static MAC bindings. MAC bindings can be known statically
1537 based on data in the OVN_Northbound database. For router
1538 ports connected to logical switches, MAC bindings can be
1539 known statically from the addresses column in the Logi‐
1540 cal_Switch_Port table. For router ports connected to
1541 other logical routers, MAC bindings can be known stati‐
1542 cally from the mac and networks column in the Logi‐
1543 cal_Router_Port table.
1544 For each IPv4 address A whose host is known to have Eth‐
1546 ernet address E on router port P, a priority-100 flow
1547 with match outport === P && reg0 == A has actions eth.dst
1548 = E; next;.
1549 For each IPv6 address A whose host is known to have Eth‐
1551 ernet address E on router port P, a priority-100 flow
1552 with match outport === P && xxreg0 == A has actions
1553 eth.dst = E; next;.
1554 For each logical router port with an IPv4 address A and a
1556 mac address of E that is reachable via a different logi‐
1557 cal router port P, a priority-100 flow with match outport
1558 === P && reg0 == A has actions eth.dst = E; next;.
1559 For each logical router port with an IPv6 address A and a
1561 mac address of E that is reachable via a different logi‐
1562 cal router port P, a priority-100 flow with match outport
1563 === P && xxreg0 == A has actions eth.dst = E; next;.
1564 · Dynamic MAC bindings. These flows resolve MAC-to-IP bind‐
1566 ings that have become known dynamically through ARP or
1567 neighbor discovery. (The ingress table ARP Request will
1568 issue an ARP or neighbor solicitation request for cases
1569 where the binding is not yet known.)
1570 A priority-0 logical flow with match ip4 has actions
1572 get_arp(outport, reg0); next;.
1573 A priority-0 logical flow with match ip6 has actions
1575 get_nd(outport, xxreg0); next;.
1576 Ingress Table 9: Gateway Redirect
1578 For distributed logical routers where one of the logical router ports
1580 specifies a redirect-chassis, this table redirects certain packets to
1581 the distributed gateway port instance on the redirect-chassis. This ta‐
1582 ble has the following flows:
1583 · A priority-200 logical flow with match REGBIT_NAT_REDI‐
1585 RECT == 1 has actions outport = CR; next;, where CR is
1586 the chassisredirect port representing the instance of the
1587 logical router distributed gateway port on the redi‐
1588 rect-chassis.
1589 · A priority-150 logical flow with match outport == GW &&
1591 eth.dst == 00:00:00:00:00:00 has actions outport = CR;
1592 next;, where GW is the logical router distributed gateway
1593 port and CR is the chassisredirect port representing the
1594 instance of the logical router distributed gateway port
1595 on the redirect-chassis.
1596 · For each NAT rule in the OVN Northbound database that can
1598 be handled in a distributed manner, a priority-100 logi‐
1599 cal flow with match ip4.src == B && outport == GW, where
1600 GW is the logical router distributed gateway port, with
1601 actions next;.
1602 · A priority-50 logical flow with match outport == GW has
1604 actions outport = CR; next;, where GW is the logical
1605 router distributed gateway port and CR is the chas‐
1606 sisredirect port representing the instance of the logical
1607 router distributed gateway port on the redirect-chassis.
1608 · A priority-0 logical flow with match 1 has actions next;.
1610 Ingress Table 10: ARP Request
1612 In the common case where the Ethernet destination has been resolved,
1614 this table outputs the packet. Otherwise, it composes and sends an ARP
1615 or IPv6 Neighbor Solicitation request. It holds the following flows:
1616 · Unknown MAC address. A priority-100 flow for IPv4 packets
1618 with match eth.dst == 00:00:00:00:00:00 has the following
1619 actions:
1620 arp {
1622 eth.dst = ff:ff:ff:ff:ff:ff;
1623 arp.spa = reg1;
1624 arp.tpa = reg0;
1625 arp.op = 1; /* ARP request. */
1626 output;
1627 };
1628 Unknown MAC address. A priority-100 flow for IPv6 packets
1631 with match eth.dst == 00:00:00:00:00:00 has the following
1632 actions:
1633 nd_ns {
1635 nd.target = xxreg0;
1636 output;
1637 };
1638 (Ingress table IP Routing initialized reg1 with the IP
1641 address owned by outport and (xx)reg0 with the next-hop
1642 IP address)
1643 The IP packet that triggers the ARP/IPv6 NS request is
1645 dropped.
1646 · Known MAC address. A priority-0 flow with match 1 has
1648 actions output;.
1649 Egress Table 0: UNDNAT
1651 This is for already established connections’ reverse traffic. i.e.,
1653 DNAT has already been done in ingress pipeline and now the packet has
1654 entered the egress pipeline as part of a reply. For NAT on a distrib‐
1655 uted router, it is unDNATted here. For Gateway routers, the unDNAT pro‐
1656 cessing is carried out in the ingress DNAT table.
1657 · For all the configured load balancing rules for a router
1659 with gateway port in OVN_Northbound database that
1660 includes an IPv4 address VIP, for every backend IPv4
1661 address B defined for the VIP a priority-120 flow is pro‐
1662 grammed on redirect-chassis that matches ip && ip4.src ==
1663 B && outport == GW, where GW is the logical router gate‐
1664 way port with an action ct_dnat;. If the backend IPv4
1665 address B is also configured with L4 port PORT of proto‐
1666 col P, then the match also includes P.src == PORT. These
1667 flows are not added for load balancers with IPv6 VIPs.
1668 If the router is configured to force SNAT any load-bal‐
1670 anced packets, above action will be replaced by
1671 flags.force_snat_for_lb = 1; ct_dnat;.
1672 · For each configuration in the OVN Northbound database
1674 that asks to change the destination IP address of a
1675 packet from an IP address of A to B, a priority-100 flow
1676 matches ip && ip4.src == B && outport == GW, where GW is
1677 the logical router gateway port, with an action ct_dnat;.
1678 If the NAT rule cannot be handled in a distributed man‐
1680 ner, then the priority-100 flow above is only programmed
1681 on the redirect-chassis.
1682 If the NAT rule can be handled in a distributed manner,
1684 then there is an additional action eth.src = EA;, where
1685 EA is the ethernet address associated with the IP address
1686 A in the NAT rule. This allows upstream MAC learning to
1687 point to the correct chassis.
1688 · A priority-0 logical flow with match 1 has actions next;.
1690 Egress Table 1: SNAT
1692 Packets that are configured to be SNATed get their source IP address
1694 changed based on the configuration in the OVN Northbound database.
1695 Egress Table 1: SNAT on Gateway Routers
1697 · If the Gateway router in the OVN Northbound database has
1699 been configured to force SNAT a packet (that has been
1700 previously DNATted) to B, a priority-100 flow matches
1701 flags.force_snat_for_dnat == 1 && ip with an action
1702 ct_snat(B);.
1703 If the Gateway router in the OVN Northbound database has
1705 been configured to force SNAT a packet (that has been
1706 previously load-balanced) to B, a priority-100 flow
1707 matches flags.force_snat_for_lb == 1 && ip with an action
1708 ct_snat(B);.
1709 For each configuration in the OVN Northbound database,
1711 that asks to change the source IP address of a packet
1712 from an IP address of A or to change the source IP
1713 address of a packet that belongs to network A to B, a
1714 flow matches ip && ip4.src == A with an action
1715 ct_snat(B);. The priority of the flow is calculated based
1716 on the mask of A, with matches having larger masks get‐
1717 ting higher priorities.
1718 A priority-0 logical flow with match 1 has actions next;.
1720 Egress Table 1: SNAT on Distributed Routers
1722 · For each configuration in the OVN Northbound database,
1724 that asks to change the source IP address of a packet
1725 from an IP address of A or to change the source IP
1726 address of a packet that belongs to network A to B, a
1727 flow matches ip && ip4.src == A && outport == GW, where
1728 GW is the logical router gateway port, with an action
1729 ct_snat(B);. The priority of the flow is calculated based
1730 on the mask of A, with matches having larger masks get‐
1731 ting higher priorities.
1732 If the NAT rule cannot be handled in a distributed man‐
1734 ner, then the flow above is only programmed on the redi‐
1735 rect-chassis.
1736 If the NAT rule can be handled in a distributed manner,
1738 then there is an additional action eth.src = EA;, where
1739 EA is the ethernet address associated with the IP address
1740 A in the NAT rule. This allows upstream MAC learning to
1741 point to the correct chassis.
1742 · A priority-0 logical flow with match 1 has actions next;.
1744 Egress Table 2: Egress Loopback
1746 For distributed logical routers where one of the logical router ports
1748 specifies a redirect-chassis.
1749 Earlier in the ingress pipeline, some east-west traffic was redirected
1751 to the chassisredirect port, based on flows in the UNSNAT and DNAT
1752 ingress tables setting the REGBIT_NAT_REDIRECT flag, which then trig‐
1753 gered a match to a flow in the Gateway Redirect ingress table. The
1754 intention was not to actually send traffic out the distributed gateway
1755 port instance on the redirect-chassis. This traffic was sent to the
1756 distributed gateway port instance in order for DNAT and/or SNAT pro‐
1757 cessing to be applied.
1758 While UNDNAT and SNAT processing have already occurred by this point,
1760 this traffic needs to be forced through egress loopback on this dis‐
1761 tributed gateway port instance, in order for UNSNAT and DNAT processing
1762 to be applied, and also for IP routing and ARP resolution after all of
1763 the NAT processing, so that the packet can be forwarded to the destina‐
1764 tion.
1765 This table has the following flows:
1767 · For each NAT rule in the OVN Northbound database on a
1769 distributed router, a priority-100 logical flow with
1770 match ip4.dst == E && outport == GW, where E is the
1771 external IP address specified in the NAT rule, and GW is
1772 the logical router distributed gateway port, with the
1773 following actions:
1774 clone {
1776 ct_clear;
1777 inport = outport;
1778 outport = "";
1779 flags = 0;
1780 flags.loopback = 1;
1781 reg0 = 0;
1782 reg1 = 0;
1783 ...
1784 reg9 = 0;
1785 REGBIT_EGRESS_LOOPBACK = 1;
1786 next(pipeline=ingress, table=0);
1787 };
1788 flags.loopback is set since in_port is unchanged and the
1791 packet may return back to that port after NAT processing.
1792 REGBIT_EGRESS_LOOPBACK is set to indicate that egress
1793 loopback has occurred, in order to skip the source IP
1794 address check against the router address.
1795 · A priority-0 logical flow with match 1 has actions next;.
1797 Egress Table 3: Delivery
1799 Packets that reach this table are ready for delivery. It contains pri‐
1801 ority-100 logical flows that match packets on each enabled logical
1802 router port, with action output;.
1803Open vSwitch 2.10.1 ovn-northd ovn-northd(8)