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. Downside of using
187 this options is that libc adds fixed prefix to every mes‐
188 sage before it is actually sent to the syslog daemon over
189 /dev/log UNIX domain socket.
190 · unix:file, to use a UNIX domain socket directly. It is pos‐
192 sible to specify arbitrary message format with this option.
193 However, rsyslogd 8.9 and older versions use hard coded
194 parser function anyway that limits UNIX domain socket use.
195 If you want to use arbitrary message format with older
196 rsyslogd versions, then use UDP socket to localhost IP
197 address instead.
198 · udp:ip:port, to use a UDP socket. With this method it is
200 possible to use arbitrary message format also with older
201 rsyslogd. When sending syslog messages over UDP socket
202 extra precaution needs to be taken into account, for exam‐
203 ple, syslog daemon needs to be configured to listen on the
204 specified UDP port, accidental iptables rules could be
205 interfering with local syslog traffic and there are some
206 security considerations that apply to UDP sockets, but do
207 not apply to UNIX domain sockets.
208 · null, to discard all messages logged to syslog.
210 The default is taken from the OVS_SYSLOG_METHOD environment vari‐
212 able; if it is unset, the default is libc.
213 PKI Options
215 PKI configuration is required in order to use SSL for the connections
216 to the Northbound and Southbound databases.
217 -p privkey.pem
219 --private-key=privkey.pem
220 Specifies a PEM file containing the private key used as
221 identity for outgoing SSL connections.
222 -c cert.pem
224 --certificate=cert.pem
225 Specifies a PEM file containing a certificate that certi‐
226 fies the private key specified on -p or --private-key to be
227 trustworthy. The certificate must be signed by the certifi‐
228 cate authority (CA) that the peer in SSL connections will
229 use to verify it.
230 -C cacert.pem
232 --ca-cert=cacert.pem
233 Specifies a PEM file containing the CA certificate for ver‐
234 ifying certificates presented to this program by SSL peers.
235 (This may be the same certificate that SSL peers use to
236 verify the certificate specified on -c or --certificate, or
237 it may be a different one, depending on the PKI design in
238 use.)
239 -C none
241 --ca-cert=none
242 Disables verification of certificates presented by SSL
243 peers. This introduces a security risk, because it means
244 that certificates cannot be verified to be those of known
245 trusted hosts.
246 Other Options
248 --unixctl=socket
249 Sets the name of the control socket on which program listens for
250 runtime management commands (see RUNTIME MANAGEMENT COMMANDS,
251 below). If socket does not begin with /, it is interpreted as
252 relative to /var/run/openvswitch. If --unixctl is not used at
253 all, the default socket is /var/run/openvswitch/program.pid.ctl,
254 where pid is program’s process ID.
255 On Windows a local named pipe is used to listen for runtime man‐
257 agement commands. A file is created in the absolute path as
258 pointed by socket or if --unixctl is not used at all, a file is
259 created as program in the configured OVS_RUNDIR directory. The
260 file exists just to mimic the behavior of a Unix domain socket.
261 Specifying none for socket disables the control socket feature.
263 -h
267 --help
268 Prints a brief help message to the console.
269 -V
271 --version
272 Prints version information to the console.
273
275 ovs-appctl can send commands to a running ovn-northd process. The cur‐
276 rently supported commands are described below.
277 exit Causes ovn-northd to gracefully terminate.
279
281 You may run ovn-northd more than once in an OVN deployment. OVN will
282 automatically ensure that only one of them is active at a time. If mul‐
283 tiple instances of ovn-northd are running and the active ovn-northd
284 fails, one of the hot standby instances of ovn-northd will automati‐
285 cally take over.
286
288 One of the main purposes of ovn-northd is to populate the Logical_Flow
289 table in the OVN_Southbound database. This section describes how
290 ovn-northd does this for switch and router logical datapaths.
291 Logical Switch Datapaths
293 Ingress Table 0: Admission Control and Ingress Port Security - L2
294 Ingress table 0 contains these logical flows:
296 · Priority 100 flows to drop packets with VLAN tags or mul‐
298 ticast Ethernet source addresses.
299 · Priority 50 flows that implement ingress port security
301 for each enabled logical port. For logical ports on which
302 port security is enabled, these match the inport and the
303 valid eth.src address(es) and advance only those packets
304 to the next flow table. For logical ports on which port
305 security is not enabled, these advance all packets that
306 match the inport.
307 There are no flows for disabled logical ports because the default-drop
309 behavior of logical flow tables causes packets that ingress from them
310 to be dropped.
311 Ingress Table 1: Ingress Port Security - IP
313 Ingress table 1 contains these logical flows:
315 · For each element in the port security set having one or
317 more IPv4 or IPv6 addresses (or both),
318 · Priority 90 flow to allow IPv4 traffic if it has
320 IPv4 addresses which match the inport, valid
321 eth.src and valid ip4.src address(es).
322 · Priority 90 flow to allow IPv4 DHCP discovery
324 traffic if it has a valid eth.src. This is neces‐
325 sary since DHCP discovery messages are sent from
326 the unspecified IPv4 address (0.0.0.0) since the
327 IPv4 address has not yet been assigned.
328 · Priority 90 flow to allow IPv6 traffic if it has
330 IPv6 addresses which match the inport, valid
331 eth.src and valid ip6.src address(es).
332 · Priority 90 flow to allow IPv6 DAD (Duplicate
334 Address Detection) traffic if it has a valid
335 eth.src. This is is necessary since DAD include
336 requires joining an multicast group and sending
337 neighbor solicitations for the newly assigned
338 address. Since no address is yet assigned, these
339 are sent from the unspecified IPv6 address (::).
340 · Priority 80 flow to drop IP (both IPv4 and IPv6)
342 traffic which match the inport and valid eth.src.
343 · One priority-0 fallback flow that matches all packets and
345 advances to the next table.
346 Ingress Table 2: Ingress Port Security - Neighbor discovery
348 Ingress table 2 contains these logical flows:
350 · For each element in the port security set,
352 · Priority 90 flow to allow ARP traffic which match
354 the inport and valid eth.src and arp.sha. If the
355 element has one or more IPv4 addresses, then it
356 also matches the valid arp.spa.
357 · Priority 90 flow to allow IPv6 Neighbor Solicita‐
359 tion and Advertisement traffic which match the
360 inport, valid eth.src and nd.sll/nd.tll. If the
361 element has one or more IPv6 addresses, then it
362 also matches the valid nd.target address(es) for
363 Neighbor Advertisement traffic.
364 · Priority 80 flow to drop ARP and IPv6 Neighbor
366 Solicitation and Advertisement traffic which match
367 the inport and valid eth.src.
368 · One priority-0 fallback flow that matches all packets and
370 advances to the next table.
371 Ingress Table 3: from-lport Pre-ACLs
373 This table prepares flows for possible stateful ACL processing in
375 ingress table ACLs. It contains a priority-0 flow that simply moves
376 traffic to the next table. If stateful ACLs are used in the logical
377 datapath, a priority-100 flow is added that sets a hint (with reg0[0] =
378 1; next;) for table Pre-stateful to send IP packets to the connection
379 tracker before eventually advancing to ingress table ACLs. If special
380 ports such as route ports or localnet ports can’t use ct(), a prior‐
381 ity-110 flow is added to skip over stateful ACLs.
382 Ingress Table 4: Pre-LB
384 This table prepares flows for possible stateful load balancing process‐
386 ing in ingress table LB and Stateful. It contains a priority-0 flow
387 that simply moves traffic to the next table. Moreover it contains a
388 priority-110 flow to move IPv6 Neighbor Discovery traffic to the next
389 table. If load balancing rules with virtual IP addresses (and ports)
390 are configured in OVN_Northbound database for a logical switch data‐
391 path, a priority-100 flow is added for each configured virtual IP
392 address VIP. For IPv4 VIPs, the match is ip && ip4.dst == VIP. For IPv6
393 VIPs, the match is ip && ip6.dst == VIP. The flow sets an action
394 reg0[0] = 1; next; to act as a hint for table Pre-stateful to send IP
395 packets to the connection tracker for packet de-fragmentation before
396 eventually advancing to ingress table LB.
397 Ingress Table 5: Pre-stateful
399 This table prepares flows for all possible stateful processing in next
401 tables. It contains a priority-0 flow that simply moves traffic to the
402 next table. A priority-100 flow sends the packets to connection tracker
403 based on a hint provided by the previous tables (with a match for
404 reg0[0] == 1) by using the ct_next; action.
405 Ingress table 6: from-lport ACLs
407 Logical flows in this table closely reproduce those in the ACL table in
409 the OVN_Northbound database for the from-lport direction. The priority
410 values from the ACL table have a limited range and have 1000 added to
411 them to leave room for OVN default flows at both higher and lower pri‐
412 orities.
413 · allow ACLs translate into logical flows with the next;
415 action. If there are any stateful ACLs on this datapath,
416 then allow ACLs translate to ct_commit; next; (which acts
417 as a hint for the next tables to commit the connection to
418 conntrack),
419 · allow-related ACLs translate into logical flows with the
421 ct_commit(ct_label=0/1); next; actions for new connec‐
422 tions and reg0[1] = 1; next; for existing connections.
423 · Other ACLs translate to drop; for new or untracked con‐
425 nections and ct_commit(ct_label=1/1); for known connec‐
426 tions. Setting ct_label marks a connection as one that
427 was previously allowed, but should no longer be allowed
428 due to a policy change.
429 This table also contains a priority 0 flow with action next;, so that
431 ACLs allow packets by default. If the logical datapath has a statetful
432 ACL, the following flows will also be added:
433 · A priority-1 flow that sets the hint to commit IP traffic
435 to the connection tracker (with action reg0[1] = 1;
436 next;). This is needed for the default allow policy
437 because, while the initiator’s direction may not have any
438 stateful rules, the server’s may and then its return
439 traffic would not be known and marked as invalid.
440 · A priority-65535 flow that allows any traffic in the
442 reply direction for a connection that has been committed
443 to the connection tracker (i.e., established flows), as
444 long as the committed flow does not have ct_label.blocked
445 set. We only handle traffic in the reply direction here
446 because we want all packets going in the request direc‐
447 tion to still go through the flows that implement the
448 currently defined policy based on ACLs. If a connection
449 is no longer allowed by policy, ct_label.blocked will get
450 set and packets in the reply direction will no longer be
451 allowed, either.
452 · A priority-65535 flow that allows any traffic that is
454 considered related to a committed flow in the connection
455 tracker (e.g., an ICMP Port Unreachable from a non-lis‐
456 tening UDP port), as long as the committed flow does not
457 have ct_label.blocked set.
458 · A priority-65535 flow that drops all traffic marked by
460 the connection tracker as invalid.
461 · A priority-65535 flow that drops all traffic in the reply
463 direction with ct_label.blocked set meaning that the con‐
464 nection should no longer be allowed due to a policy
465 change. Packets in the request direction are skipped here
466 to let a newly created ACL re-allow this connection.
467 Ingress Table 7: from-lport QoS Marking
469 Logical flows in this table closely reproduce those in the QoS table
471 with the action column set in the OVN_Northbound database for the
472 from-lport direction.
473 · For every qos_rules entry in a logical switch with DSCP
475 marking enabled, a flow will be added at the priority
476 mentioned in the QoS table.
477 · One priority-0 fallback flow that matches all packets and
479 advances to the next table.
480 Ingress Table 8: from-lport QoS Meter
482 Logical flows in this table closely reproduce those in the QoS table
484 with the bandwidth column set in the OVN_Northbound database for the
485 from-lport direction.
486 · For every qos_rules entry in a logical switch with meter‐
488 ing enabled, a flow will be added at the priorirty men‐
489 tioned in the QoS table.
490 · One priority-0 fallback flow that matches all packets and
492 advances to the next table.
493 Ingress Table 9: LB
495 It contains a priority-0 flow that simply moves traffic to the next ta‐
497 ble. For established connections a priority 100 flow matches on ct.est
498 && !ct.rel && !ct.new && !ct.inv and sets an action reg0[2] = 1; next;
499 to act as a hint for table Stateful to send packets through connection
500 tracker to NAT the packets. (The packet will automatically get DNATed
501 to the same IP address as the first packet in that connection.)
502 Ingress Table 10: Stateful
504 · For all the configured load balancing rules for a switch
506 in OVN_Northbound database that includes a L4 port PORT
507 of protocol P and IP address VIP, a priority-120 flow is
508 added. For IPv4 VIPs , the flow matches ct.new && ip &&
509 ip4.dst == VIP && P && P.dst == PORT. For IPv6 VIPs, the
510 flow matches ct.new && ip && ip6.dst == VIP && P && P.dst
511 == PORT. The flow’s action is ct_lb(args) , where args
512 contains comma separated IP addresses (and optional port
513 numbers) to load balance to. The address family of the IP
514 addresses of args is the same as the address family of
515 VIP
516 · For all the configured load balancing rules for a switch
518 in OVN_Northbound database that includes just an IP
519 address VIP to match on, OVN adds a priority-110 flow.
520 For IPv4 VIPs, the flow matches ct.new && ip && ip4.dst
521 == VIP. For IPv6 VIPs, the flow matches ct.new && ip &&
522 ip6.dst == VIP. The action on this flow is ct_lb(args),
523 where args contains comma separated IP addresses of the
524 same address family as VIP.
525 · A priority-100 flow commits packets to connection tracker
527 using ct_commit; next; action based on a hint provided by
528 the previous tables (with a match for reg0[1] == 1).
529 · A priority-100 flow sends the packets to connection
531 tracker using ct_lb; as the action based on a hint pro‐
532 vided by the previous tables (with a match for reg0[2] ==
533 1).
534 · A priority-0 flow that simply moves traffic to the next
536 table.
537 Ingress Table 11: ARP/ND responder
539 This table implements ARP/ND responder in a logical switch for known
541 IPs. The advantage of the ARP responder flow is to limit ARP broadcasts
542 by locally responding to ARP requests without the need to send to other
543 hypervisors. One common case is when the inport is a logical port asso‐
544 ciated with a VIF and the broadcast is responded to on the local hyper‐
545 visor rather than broadcast across the whole network and responded to
546 by the destination VM. This behavior is proxy ARP.
547 ARP requests arrive from VMs from a logical switch inport of type
549 default. For this case, the logical switch proxy ARP rules can be for
550 other VMs or logical router ports. Logical switch proxy ARP rules may
551 be programmed both for mac binding of IP addresses on other logical
552 switch VIF ports (which are of the default logical switch port type,
553 representing connectivity to VMs or containers), and for mac binding of
554 IP addresses on logical switch router type ports, representing their
555 logical router port peers. In order to support proxy ARP for logical
556 router ports, an IP address must be configured on the logical switch
557 router type port, with the same value as the peer logical router port.
558 The configured MAC addresses must match as well. When a VM sends an ARP
559 request for a distributed logical router port and if the peer router
560 type port of the attached logical switch does not have an IP address
561 configured, the ARP request will be broadcast on the logical switch.
562 One of the copies of the ARP request will go through the logical switch
563 router type port to the logical router datapath, where the logical
564 router ARP responder will generate a reply. The MAC binding of a dis‐
565 tributed logical router, once learned by an associated VM, is used for
566 all that VM’s communication needing routing. Hence, the action of a VM
567 re-arping for the mac binding of the logical router port should be
568 rare.
569 Logical switch ARP responder proxy ARP rules can also be hit when
571 receiving ARP requests externally on a L2 gateway port. In this case,
572 the hypervisor acting as an L2 gateway, responds to the ARP request on
573 behalf of a destination VM.
574 Note that ARP requests received from localnet or vtep logical inports
576 can either go directly to VMs, in which case the VM responds or can hit
577 an ARP responder for a logical router port if the packet is used to
578 resolve a logical router port next hop address. In either case, logical
579 switch ARP responder rules will not be hit. It contains these logical
580 flows:
581 · Priority-100 flows to skip the ARP responder if inport is
583 of type localnet or vtep and advances directly to the
584 next table. ARP requests sent to localnet or vtep ports
585 can be received by multiple hypervisors. Now, because the
586 same mac binding rules are downloaded to all hypervisors,
587 each of the multiple hypervisors will respond. This will
588 confuse L2 learning on the source of the ARP requests.
589 ARP requests received on an inport of type router are not
590 expected to hit any logical switch ARP responder flows.
591 However, no skip flows are installed for these packets,
592 as there would be some additional flow cost for this and
593 the value appears limited.
594 · Priority-50 flows that match ARP requests to each known
596 IP address A of every logical switch port, and respond
597 with ARP replies directly with corresponding Ethernet
598 address E:
599 eth.dst = eth.src;
601 eth.src = E;
602 arp.op = 2; /* ARP reply. */
603 arp.tha = arp.sha;
604 arp.sha = E;
605 arp.tpa = arp.spa;
606 arp.spa = A;
607 outport = inport;
608 flags.loopback = 1;
609 output;
610 These flows are omitted for logical ports (other than
613 router ports or localport ports) that are down.
614 · Priority-50 flows that match IPv6 ND neighbor solicita‐
616 tions to each known IP address A (and A’s solicited node
617 address) of every logical switch port except of type
618 router, and respond with neighbor advertisements directly
619 with corresponding Ethernet address E:
620 nd_na {
622 eth.src = E;
623 ip6.src = A;
624 nd.target = A;
625 nd.tll = E;
626 outport = inport;
627 flags.loopback = 1;
628 output;
629 };
630 Priority-50 flows that match IPv6 ND neighbor solicita‐
633 tions to each known IP address A (and A’s solicited node
634 address) of logical switch port of type router, and
635 respond with neighbor advertisements directly with corre‐
636 sponding Ethernet address E:
637 nd_na_router {
639 eth.src = E;
640 ip6.src = A;
641 nd.target = A;
642 nd.tll = E;
643 outport = inport;
644 flags.loopback = 1;
645 output;
646 };
647 These flows are omitted for logical ports (other than
650 router ports or localport ports) that are down.
651 · Priority-100 flows with match criteria like the ARP and
653 ND flows above, except that they only match packets from
654 the inport that owns the IP addresses in question, with
655 action next;. These flows prevent OVN from replying to,
656 for example, an ARP request emitted by a VM for its own
657 IP address. A VM only makes this kind of request to
658 attempt to detect a duplicate IP address assignment, so
659 sending a reply will prevent the VM from accepting the IP
660 address that it owns.
661 In place of next;, it would be reasonable to use drop;
663 for the flows’ actions. If everything is working as it is
664 configured, then this would produce equivalent results,
665 since no host should reply to the request. But ARPing for
666 one’s own IP address is intended to detect situations
667 where the network is not working as configured, so drop‐
668 ping the request would frustrate that intent.
669 · One priority-0 fallback flow that matches all packets and
671 advances to the next table.
672 Ingress Table 12: DHCP option processing
674 This table adds the DHCPv4 options to a DHCPv4 packet from the logical
676 ports configured with IPv4 address(es) and DHCPv4 options, and simi‐
677 larly for DHCPv6 options. This table also adds flows for the logical
678 ports of type external.
679 · A priority-100 logical flow is added for these logical
681 ports which matches the IPv4 packet with udp.src = 68 and
682 udp.dst = 67 and applies the action put_dhcp_opts and
683 advances the packet to the next table.
684 reg0[3] = put_dhcp_opts(offer_ip = ip, options...);
686 next;
687 For DHCPDISCOVER and DHCPREQUEST, this transforms the
690 packet into a DHCP reply, adds the DHCP offer IP ip and
691 options to the packet, and stores 1 into reg0[3]. For
692 other kinds of packets, it just stores 0 into reg0[3].
693 Either way, it continues to the next table.
694 · A priority-100 logical flow is added for these logical
696 ports which matches the IPv6 packet with udp.src = 546
697 and udp.dst = 547 and applies the action put_dhcpv6_opts
698 and advances the packet to the next table.
699 reg0[3] = put_dhcpv6_opts(ia_addr = ip, options...);
701 next;
702 For DHCPv6 Solicit/Request/Confirm packets, this trans‐
705 forms the packet into a DHCPv6 Advertise/Reply, adds the
706 DHCPv6 offer IP ip and options to the packet, and stores
707 1 into reg0[3]. For other kinds of packets, it just
708 stores 0 into reg0[3]. Either way, it continues to the
709 next table.
710 · A priority-0 flow that matches all packets to advances to
712 table 11.
713 Ingress Table 13: DHCP responses
715 This table implements DHCP responder for the DHCP replies generated by
717 the previous table.
718 · A priority 100 logical flow is added for the logical
720 ports configured with DHCPv4 options which matches IPv4
721 packets with udp.src == 68 && udp.dst == 67 && reg0[3] ==
722 1 and responds back to the inport after applying these
723 actions. If reg0[3] is set to 1, it means that the action
724 put_dhcp_opts was successful.
725 eth.dst = eth.src;
727 eth.src = E;
728 ip4.dst = A;
729 ip4.src = S;
730 udp.src = 67;
731 udp.dst = 68;
732 outport = P;
733 flags.loopback = 1;
734 output;
735 where E is the server MAC address and S is the server
738 IPv4 address defined in the DHCPv4 options and A is the
739 IPv4 address defined in the logical port’s addresses col‐
740 umn.
741 (This terminates ingress packet processing; the packet
743 does not go to the next ingress table.)
744 · A priority 100 logical flow is added for the logical
746 ports configured with DHCPv6 options which matches IPv6
747 packets with udp.src == 546 && udp.dst == 547 && reg0[3]
748 == 1 and responds back to the inport after applying these
749 actions. If reg0[3] is set to 1, it means that the action
750 put_dhcpv6_opts was successful.
751 eth.dst = eth.src;
753 eth.src = E;
754 ip6.dst = A;
755 ip6.src = S;
756 udp.src = 547;
757 udp.dst = 546;
758 outport = P;
759 flags.loopback = 1;
760 output;
761 where E is the server MAC address and S is the server
764 IPv6 LLA address generated from the server_id defined in
765 the DHCPv6 options and A is the IPv6 address defined in
766 the logical port’s addresses column.
767 (This terminates packet processing; the packet does not
769 go on the next ingress table.)
770 · A priority-0 flow that matches all packets to advances to
772 table 12.
773 Ingress Table 14 DNS Lookup
775 This table looks up and resolves the DNS names to the corresponding
777 configured IP address(es).
778 · A priority-100 logical flow for each logical switch data‐
780 path if it is configured with DNS records, which matches
781 the IPv4 and IPv6 packets with udp.dst = 53 and applies
782 the action dns_lookup and advances the packet to the next
783 table.
784 reg0[4] = dns_lookup(); next;
786 For valid DNS packets, this transforms the packet into a
789 DNS reply if the DNS name can be resolved, and stores 1
790 into reg0[4]. For failed DNS resolution or other kinds of
791 packets, it just stores 0 into reg0[4]. Either way, it
792 continues to the next table.
793 Ingress Table 15 DNS Responses
795 This table implements DNS responder for the DNS replies generated by
797 the previous table.
798 · A priority-100 logical flow for each logical switch data‐
800 path if it is configured with DNS records, which matches
801 the IPv4 and IPv6 packets with udp.dst = 53 && reg0[4] ==
802 1 and responds back to the inport after applying these
803 actions. If reg0[4] is set to 1, it means that the action
804 dns_lookup was successful.
805 eth.dst <-> eth.src;
807 ip4.src <-> ip4.dst;
808 udp.dst = udp.src;
809 udp.src = 53;
810 outport = P;
811 flags.loopback = 1;
812 output;
813 (This terminates ingress packet processing; the packet
816 does not go to the next ingress table.)
817 Ingress table 16 External ports
819 Traffic from the external logical ports enter the ingress datapath
821 pipeline via the localnet port. This table adds the below logical flows
822 to handle the traffic from these ports.
823 · A priority-100 flow is added for each external logical
825 port which doesn’t reside on a chassis to drop the
826 ARP/IPv6 NS request to the router IP(s) (of the logical
827 switch) which matches on the inport of the external logi‐
828 cal port and the valid eth.src address(es) of the exter‐
829 nal logical port.
830 This flow guarantees that the ARP/NS request to the
832 router IP address from the external ports is responded by
833 only the chassis which has claimed these external ports.
834 All the other chassis, drops these packets.
835 · A priority-0 flow that matches all packets to advances to
837 table 17.
838 Ingress Table 17 Destination Lookup
840 This table implements switching behavior. It contains these logical
842 flows:
843 · A priority-100 flow that outputs all packets with an Eth‐
845 ernet broadcast or multicast eth.dst to the MC_FLOOD mul‐
846 ticast group, which ovn-northd populates with all enabled
847 logical ports.
848 · One priority-50 flow that matches each known Ethernet
850 address against eth.dst and outputs the packet to the
851 single associated output port.
852 For the Ethernet address on a logical switch port of type
854 router, when that logical switch port’s addresses column
855 is set to router and the connected logical router port
856 specifies a redirect-chassis:
857 · The flow for the connected logical router port’s
859 Ethernet address is only programmed on the redi‐
860 rect-chassis.
861 · If the logical router has rules specified in nat
863 with external_mac, then those addresses are also
864 used to populate the switch’s destination lookup
865 on the chassis where logical_port is resident.
866 For the Ethernet address on a logical switch port of type
868 router, when that logical switch port’s addresses column
869 is set to router and the connected logical router port
870 specifies a reside-on-redirect-chassis and the logical
871 router to which the connected logical router port belongs
872 to has a redirect-chassis distributed gateway logical
873 router port:
874 · The flow for the connected logical router port’s
876 Ethernet address is only programmed on the redi‐
877 rect-chassis.
878 · One priority-0 fallback flow that matches all packets and
880 outputs them to the MC_UNKNOWN multicast group, which
881 ovn-northd populates with all enabled logical ports that
882 accept unknown destination packets. As a small optimiza‐
883 tion, if no logical ports accept unknown destination
884 packets, ovn-northd omits this multicast group and logi‐
885 cal flow.
886 Egress Table 0: Pre-LB
888 This table is similar to ingress table Pre-LB. It contains a priority-0
890 flow that simply moves traffic to the next table. Moreover it contains
891 a priority-110 flow to move IPv6 Neighbor Discovery traffic to the next
892 table. If any load balancing rules exist for the datapath, a prior‐
893 ity-100 flow is added with a match of ip and action of reg0[0] = 1;
894 next; to act as a hint for table Pre-stateful to send IP packets to the
895 connection tracker for packet de-fragmentation.
896 Egress Table 1: to-lport Pre-ACLs
898 This is similar to ingress table Pre-ACLs except for to-lport traffic.
900 Egress Table 2: Pre-stateful
902 This is similar to ingress table Pre-stateful.
904 Egress Table 3: LB
906 This is similar to ingress table LB.
908 Egress Table 4: to-lport ACLs
910 This is similar to ingress table ACLs except for to-lport ACLs.
912 In addition, the following flows are added.
914 · A priority 34000 logical flow is added for each logical
916 port which has DHCPv4 options defined to allow the DHCPv4
917 reply packet and which has DHCPv6 options defined to
918 allow the DHCPv6 reply packet from the Ingress Table 13:
919 DHCP responses.
920 · A priority 34000 logical flow is added for each logical
922 switch datapath configured with DNS records with the
923 match udp.dst = 53 to allow the DNS reply packet from the
924 Ingress Table 15:DNS responses.
925 Egress Table 5: to-lport QoS Marking
927 This is similar to ingress table QoS marking except they apply to
929 to-lport QoS rules.
930 Egress Table 6: to-lport QoS Meter
932 This is similar to ingress table QoS meter except they apply to
934 to-lport QoS rules.
935 Egress Table 7: Stateful
937 This is similar to ingress table Stateful except that there are no
939 rules added for load balancing new connections.
940 Egress Table 8: Egress Port Security - IP
942 This is similar to the port security logic in table Ingress Port Secu‐
944 rity - IP except that outport, eth.dst, ip4.dst and ip6.dst are checked
945 instead of inport, eth.src, ip4.src and ip6.src
946 Egress Table 9: Egress Port Security - L2
948 This is similar to the ingress port security logic in ingress table
950 Admission Control and Ingress Port Security - L2, but with important
951 differences. Most obviously, outport and eth.dst are checked instead of
952 inport and eth.src. Second, packets directed to broadcast or multicast
953 eth.dst are always accepted instead of being subject to the port secu‐
954 rity rules; this is implemented through a priority-100 flow that
955 matches on eth.mcast with action output;. Finally, to ensure that even
956 broadcast and multicast packets are not delivered to disabled logical
957 ports, a priority-150 flow for each disabled logical outport overrides
958 the priority-100 flow with a drop; action.
959 Logical Router Datapaths
961 Logical router datapaths will only exist for Logical_Router rows in the
962 OVN_Northbound database that do not have enabled set to false
963 Ingress Table 0: L2 Admission Control
965 This table drops packets that the router shouldn’t see at all based on
967 their Ethernet headers. It contains the following flows:
968 · Priority-100 flows to drop packets with VLAN tags or mul‐
970 ticast Ethernet source addresses.
971 · For each enabled router port P with Ethernet address E, a
973 priority-50 flow that matches inport == P && (eth.mcast
974 || eth.dst == E), with action next;.
975 For the gateway port on a distributed logical router
977 (where one of the logical router ports specifies a redi‐
978 rect-chassis), the above flow matching eth.dst == E is
979 only programmed on the gateway port instance on the redi‐
980 rect-chassis.
981 · For each dnat_and_snat NAT rule on a distributed router
983 that specifies an external Ethernet address E, a prior‐
984 ity-50 flow that matches inport == GW && eth.dst == E,
985 where GW is the logical router gateway port, with action
986 next;.
987 This flow is only programmed on the gateway port instance
989 on the chassis where the logical_port specified in the
990 NAT rule resides.
991 Other packets are implicitly dropped.
993 Ingress Table 1: IP Input
995 This table is the core of the logical router datapath functionality. It
997 contains the following flows to implement very basic IP host function‐
998 ality.
999 · L3 admission control: A priority-100 flow drops packets
1001 that match any of the following:
1002 · ip4.src[28..31] == 0xe (multicast source)
1004 · ip4.src == 255.255.255.255 (broadcast source)
1006 · ip4.src == 127.0.0.0/8 || ip4.dst == 127.0.0.0/8
1008 (localhost source or destination)
1009 · ip4.src == 0.0.0.0/8 || ip4.dst == 0.0.0.0/8 (zero
1011 network source or destination)
1012 · ip4.src or ip6.src is any IP address owned by the
1014 router, unless the packet was recirculated due to
1015 egress loopback as indicated by REG‐
1016 BIT_EGRESS_LOOPBACK.
1017 · ip4.src is the broadcast address of any IP network
1019 known to the router.
1020 · ICMP echo reply. These flows reply to ICMP echo requests
1022 received for the router’s IP address. Let A be an IP
1023 address owned by a router port. Then, for each A that is
1024 an IPv4 address, a priority-90 flow matches on ip4.dst ==
1025 A and icmp4.type == 8 && icmp4.code == 0 (ICMP echo
1026 request). For each A that is an IPv6 address, a prior‐
1027 ity-90 flow matches on ip6.dst == A and icmp6.type == 128
1028 && icmp6.code == 0 (ICMPv6 echo request). The port of the
1029 router that receives the echo request does not matter.
1030 Also, the ip.ttl of the echo request packet is not
1031 checked, so it complies with RFC 1812, section 4.2.2.9.
1032 Flows for ICMPv4 echo requests use the following actions:
1033 ip4.dst <-> ip4.src;
1035 ip.ttl = 255;
1036 icmp4.type = 0;
1037 flags.loopback = 1;
1038 next;
1039 Flows for ICMPv6 echo requests use the following actions:
1042 ip6.dst <-> ip6.src;
1044 ip.ttl = 255;
1045 icmp6.type = 129;
1046 flags.loopback = 1;
1047 next;
1048 · Reply to ARP requests.
1051 These flows reply to ARP requests for the router’s own IP
1053 address and populates mac binding table of the logical
1054 router port. The ARP requests are handled only if the
1055 requestor’s IP belongs to the same subnets of the logical
1056 router port. For each router port P that owns IP address
1057 A, which belongs to subnet S with prefix length L, and
1058 Ethernet address E, a priority-90 flow matches inport ==
1059 P && arp.spa == S/L && arp.op == 1 && arp.tpa == A (ARP
1060 request) with the following actions:
1061 put_arp(inport, arp.spa, arp.sha);
1063 eth.dst = eth.src;
1064 eth.src = E;
1065 arp.op = 2; /* ARP reply. */
1066 arp.tha = arp.sha;
1067 arp.sha = E;
1068 arp.tpa = arp.spa;
1069 arp.spa = A;
1070 outport = P;
1071 flags.loopback = 1;
1072 output;
1073 For the gateway port on a distributed logical router
1076 (where one of the logical router ports specifies a redi‐
1077 rect-chassis), the above flows are only programmed on the
1078 gateway port instance on the redirect-chassis. This
1079 behavior avoids generation of multiple ARP responses from
1080 different chassis, and allows upstream MAC learning to
1081 point to the redirect-chassis.
1082 For the logical router port with the option reside-on-re‐
1084 direct-chassis set (which is centralized), the above
1085 flows are only programmed on the gateway port instance on
1086 the redirect-chassis (if the logical router has a dis‐
1087 tributed gateway port). This behavior avoids generation
1088 of multiple ARP responses from different chassis, and
1089 allows upstream MAC learning to point to the redi‐
1090 rect-chassis.
1091 · These flows handles ARP requests not for router’s own IP
1093 address. They use the SPA and SHA to populate the logical
1094 router port’s mac binding table, with priority 80. The
1095 typical use case of these flows are GARP requests han‐
1096 dling. For the gateway port on a distributed logical
1097 router, these flows are only programmed on the gateway
1098 port instance on the redirect-chassis.
1099 · These flows reply to ARP requests for the virtual IP
1101 addresses configured in the router for DNAT or load bal‐
1102 ancing. For a configured DNAT IP address or a load bal‐
1103 ancer IPv4 VIP A, for each router port P with Ethernet
1104 address E, a priority-90 flow matches inport == P &&
1105 arp.op == 1 && arp.tpa == A (ARP request) with the fol‐
1106 lowing actions:
1107 eth.dst = eth.src;
1109 eth.src = E;
1110 arp.op = 2; /* ARP reply. */
1111 arp.tha = arp.sha;
1112 arp.sha = E;
1113 arp.tpa = arp.spa;
1114 arp.spa = A;
1115 outport = P;
1116 flags.loopback = 1;
1117 output;
1118 For the gateway port on a distributed logical router with
1121 NAT (where one of the logical router ports specifies a
1122 redirect-chassis):
1123 · If the corresponding NAT rule cannot be handled in
1125 a distributed manner, then this flow is only pro‐
1126 grammed on the gateway port instance on the redi‐
1127 rect-chassis. This behavior avoids generation of
1128 multiple ARP responses from different chassis, and
1129 allows upstream MAC learning to point to the redi‐
1130 rect-chassis.
1131 · If the corresponding NAT rule can be handled in a
1133 distributed manner, then this flow is only pro‐
1134 grammed on the gateway port instance where the
1135 logical_port specified in the NAT rule resides.
1136 Some of the actions are different for this case,
1138 using the external_mac specified in the NAT rule
1139 rather than the gateway port’s Ethernet address E:
1140 eth.src = external_mac;
1142 arp.sha = external_mac;
1143 This behavior avoids generation of multiple ARP
1146 responses from different chassis, and allows
1147 upstream MAC learning to point to the correct
1148 chassis.
1149 · ARP reply handling. This flow uses ARP replies to popu‐
1151 late the logical router’s ARP table. A priority-90 flow
1152 with match arp.op == 2 has actions put_arp(inport,
1153 arp.spa, arp.sha);.
1154 · Reply to IPv6 Neighbor Solicitations. These flows reply
1156 to Neighbor Solicitation requests for the router’s own
1157 IPv6 address and load balancing IPv6 VIPs and populate
1158 the logical router’s mac binding table.
1159 For each router port P that owns IPv6 address A,
1161 solicited node address S, and Ethernet address E, a pri‐
1162 ority-90 flow matches inport == P && nd_ns && ip6.dst ==
1163 {A, E} && nd.target == A with the following actions:
1164 put_nd(inport, ip6.src, nd.sll);
1166 nd_na_router {
1167 eth.src = E;
1168 ip6.src = A;
1169 nd.target = A;
1170 nd.tll = E;
1171 outport = inport;
1172 flags.loopback = 1;
1173 output;
1174 };
1175 For each router port P that has load balancing VIP A,
1178 solicited node address S, and Ethernet address E, a pri‐
1179 ority-90 flow matches inport == P && nd_ns && ip6.dst ==
1180 {A, E} && nd.target == A with the following actions:
1181 put_nd(inport, ip6.src, nd.sll);
1183 nd_na {
1184 eth.src = E;
1185 ip6.src = A;
1186 nd.target = A;
1187 nd.tll = E;
1188 outport = inport;
1189 flags.loopback = 1;
1190 output;
1191 };
1192 For the gateway port on a distributed logical router
1195 (where one of the logical router ports specifies a redi‐
1196 rect-chassis), the above flows replying to IPv6 Neighbor
1197 Solicitations are only programmed on the gateway port
1198 instance on the redirect-chassis. This behavior avoids
1199 generation of multiple replies from different chassis,
1200 and allows upstream MAC learning to point to the redi‐
1201 rect-chassis.
1202 · IPv6 neighbor advertisement handling. This flow uses
1204 neighbor advertisements to populate the logical router’s
1205 mac binding table. A priority-90 flow with match nd_na
1206 has actions put_nd(inport, nd.target, nd.tll);.
1207 · IPv6 neighbor solicitation for non-hosted addresses han‐
1209 dling. This flow uses neighbor solicitations to populate
1210 the logical router’s mac binding table (ones that were
1211 directed at the logical router would have matched the
1212 priority-90 neighbor solicitation flow already). A prior‐
1213 ity-80 flow with match nd_ns has actions put_nd(inport,
1214 ip6.src, nd.sll);.
1215 · UDP port unreachable. Priority-80 flows generate ICMP
1217 port unreachable messages in reply to UDP datagrams
1218 directed to the router’s IP address, except in the spe‐
1219 cial case of gateways, which accept traffic directed to a
1220 router IP for load balancing and NAT purposes.
1221 These flows should not match IP fragments with nonzero
1223 offset.
1224 · TCP reset. Priority-80 flows generate TCP reset messages
1226 in reply to TCP datagrams directed to the router’s IP
1227 address, except in the special case of gateways, which
1228 accept traffic directed to a router IP for load balancing
1229 and NAT purposes.
1230 These flows should not match IP fragments with nonzero
1232 offset.
1233 · Protocol or address unreachable. Priority-70 flows gener‐
1235 ate ICMP protocol or address unreachable messages for
1236 IPv4 and IPv6 respectively in reply to packets directed
1237 to the router’s IP address on IP protocols other than
1238 UDP, TCP, and ICMP, except in the special case of gate‐
1239 ways, which accept traffic directed to a router IP for
1240 load balancing purposes.
1241 These flows should not match IP fragments with nonzero
1243 offset.
1244 · Drop other IP traffic to this router. These flows drop
1246 any other traffic destined to an IP address of this
1247 router that is not already handled by one of the flows
1248 above, which amounts to ICMP (other than echo requests)
1249 and fragments with nonzero offsets. For each IP address A
1250 owned by the router, a priority-60 flow matches ip4.dst
1251 == A and drops the traffic. An exception is made and the
1252 above flow is not added if the router port’s own IP
1253 address is used to SNAT packets passing through that
1254 router.
1255 The flows above handle all of the traffic that might be directed to the
1257 router itself. The following flows (with lower priorities) handle the
1258 remaining traffic, potentially for forwarding:
1259 · Drop Ethernet local broadcast. A priority-50 flow with
1261 match eth.bcast drops traffic destined to the local Eth‐
1262 ernet broadcast address. By definition this traffic
1263 should not be forwarded.
1264 · ICMP time exceeded. For each router port P, whose IP
1266 address is A, a priority-40 flow with match inport == P
1267 && ip.ttl == {0, 1} && !ip.later_frag matches packets
1268 whose TTL has expired, with the following actions to send
1269 an ICMP time exceeded reply for IPv4 and IPv6 respec‐
1270 tively:
1271 icmp4 {
1273 icmp4.type = 11; /* Time exceeded. */
1274 icmp4.code = 0; /* TTL exceeded in transit. */
1275 ip4.dst = ip4.src;
1276 ip4.src = A;
1277 ip.ttl = 255;
1278 next;
1279 };
1280 icmp6 {
1281 icmp6.type = 3; /* Time exceeded. */
1282 icmp6.code = 0; /* TTL exceeded in transit. */
1283 ip6.dst = ip6.src;
1284 ip6.src = A;
1285 ip.ttl = 255;
1286 next;
1287 };
1288 · TTL discard. A priority-30 flow with match ip.ttl == {0,
1291 1} and actions drop; drops other packets whose TTL has
1292 expired, that should not receive a ICMP error reply (i.e.
1293 fragments with nonzero offset).
1294 · Next table. A priority-0 flows match all packets that
1296 aren’t already handled and uses actions next; to feed
1297 them to the next table.
1298 Ingress Table 2: DEFRAG
1300 This is to send packets to connection tracker for tracking and defrag‐
1302 mentation. It contains a priority-0 flow that simply moves traffic to
1303 the next table. If load balancing rules with virtual IP addresses (and
1304 ports) are configured in OVN_Northbound database for a Gateway router,
1305 a priority-100 flow is added for each configured virtual IP address
1306 VIP. For IPv4 VIPs the flow matches ip && ip4.dst == VIP. For IPv6
1307 VIPs, the flow matches ip && ip6.dst == VIP. The flow uses the action
1308 ct_next; to send IP packets to the connection tracker for packet de-
1309 fragmentation and tracking before sending it to the next table.
1310 Ingress Table 3: UNSNAT
1312 This is for already established connections’ reverse traffic. i.e.,
1314 SNAT has already been done in egress pipeline and now the packet has
1315 entered the ingress pipeline as part of a reply. It is unSNATted here.
1316 Ingress Table 3: UNSNAT on Gateway Routers
1318 · If the Gateway router has been configured to force SNAT
1320 any previously DNATted packets to B, a priority-110 flow
1321 matches ip && ip4.dst == B with an action ct_snat; .
1322 If the Gateway router has been configured to force SNAT
1324 any previously load-balanced packets to B, a priority-100
1325 flow matches ip && ip4.dst == B with an action ct_snat; .
1326 For each NAT configuration in the OVN Northbound data‐
1328 base, that asks to change the source IP address of a
1329 packet from A to B, a priority-90 flow matches ip &&
1330 ip4.dst == B with an action ct_snat; .
1331 A priority-0 logical flow with match 1 has actions next;.
1333 Ingress Table 3: UNSNAT on Distributed Routers
1335 · For each configuration in the OVN Northbound database,
1337 that asks to change the source IP address of a packet
1338 from A to B, a priority-100 flow matches ip && ip4.dst ==
1339 B && inport == GW, where GW is the logical router gateway
1340 port, with an action ct_snat;.
1341 If the NAT rule cannot be handled in a distributed man‐
1343 ner, then the priority-100 flow above is only programmed
1344 on the redirect-chassis.
1345 For each configuration in the OVN Northbound database,
1347 that asks to change the source IP address of a packet
1348 from A to B, a priority-50 flow matches ip && ip4.dst ==
1349 B with an action REGBIT_NAT_REDIRECT = 1; next;. This
1350 flow is for east/west traffic to a NAT destination IPv4
1351 address. By setting the REGBIT_NAT_REDIRECT flag, in the
1352 ingress table Gateway Redirect this will trigger a redi‐
1353 rect to the instance of the gateway port on the redi‐
1354 rect-chassis.
1355 A priority-0 logical flow with match 1 has actions next;.
1357 Ingress Table 4: DNAT
1359 Packets enter the pipeline with destination IP address that needs to be
1361 DNATted from a virtual IP address to a real IP address. Packets in the
1362 reverse direction needs to be unDNATed.
1363 Ingress Table 4: Load balancing DNAT rules
1365 Following load balancing DNAT flows are added for Gateway router or
1367 Router with gateway port. These flows are programmed only on the redi‐
1368 rect-chassis. These flows do not get programmed for load balancers with
1369 IPv6 VIPs.
1370 · For all the configured load balancing rules for a Gateway
1372 router or Router with gateway port in OVN_Northbound
1373 database that includes a L4 port PORT of protocol P and
1374 IPv4 address VIP, a priority-120 flow that matches on
1375 ct.new && ip && ip4.dst == VIP && P && P.dst == PORT
1376 with an action of ct_lb(args), where args contains comma
1377 separated IPv4 addresses (and optional port numbers) to
1378 load balance to. If the router is configured to force
1379 SNAT any load-balanced packets, the above action will be
1380 replaced by flags.force_snat_for_lb = 1; ct_lb(args);.
1381 · For all the configured load balancing rules for a router
1383 in OVN_Northbound database that includes a L4 port PORT
1384 of protocol P and IPv4 address VIP, a priority-120 flow
1385 that matches on ct.est && ip && ip4.dst == VIP && P &&
1386 P.dst == PORT
1387 with an action of ct_dnat;. If the router is configured
1388 to force SNAT any load-balanced packets, the above action
1389 will be replaced by flags.force_snat_for_lb = 1;
1390 ct_dnat;.
1391 · For all the configured load balancing rules for a router
1393 in OVN_Northbound database that includes just an IP
1394 address VIP to match on, a priority-110 flow that matches
1395 on ct.new && ip && ip4.dst == VIP with an action of
1396 ct_lb(args), where args contains comma separated IPv4
1397 addresses. If the router is configured to force SNAT any
1398 load-balanced packets, the above action will be replaced
1399 by flags.force_snat_for_lb = 1; ct_lb(args);.
1400 · For all the configured load balancing rules for a router
1402 in OVN_Northbound database that includes just an IP
1403 address VIP to match on, a priority-110 flow that matches
1404 on ct.est && ip && ip4.dst == VIP with an action of
1405 ct_dnat;. If the router is configured to force SNAT any
1406 load-balanced packets, the above action will be replaced
1407 by flags.force_snat_for_lb = 1; ct_dnat;.
1408 Ingress Table 4: DNAT on Gateway Routers
1410 · For each configuration in the OVN Northbound database,
1412 that asks to change the destination IP address of a
1413 packet from A to B, a priority-100 flow matches ip &&
1414 ip4.dst == A with an action flags.loopback = 1;
1415 ct_dnat(B);. If the Gateway router is configured to force
1416 SNAT any DNATed packet, the above action will be replaced
1417 by flags.force_snat_for_dnat = 1; flags.loopback = 1;
1418 ct_dnat(B);.
1419 · For all IP packets of a Gateway router, a priority-50
1421 flow with an action flags.loopback = 1; ct_dnat;.
1422 · A priority-0 logical flow with match 1 has actions next;.
1424 Ingress Table 4: DNAT on Distributed Routers
1426 On distributed routers, the DNAT table only handles packets with desti‐
1428 nation IP address that needs to be DNATted from a virtual IP address to
1429 a real IP address. The unDNAT processing in the reverse direction is
1430 handled in a separate table in the egress pipeline.
1431 · For each configuration in the OVN Northbound database,
1433 that asks to change the destination IP address of a
1434 packet from A to B, a priority-100 flow matches ip &&
1435 ip4.dst == B && inport == GW, where GW is the logical
1436 router gateway port, with an action ct_dnat(B);.
1437 If the NAT rule cannot be handled in a distributed man‐
1439 ner, then the priority-100 flow above is only programmed
1440 on the redirect-chassis.
1441 For each configuration in the OVN Northbound database,
1443 that asks to change the destination IP address of a
1444 packet from A to B, a priority-50 flow matches ip &&
1445 ip4.dst == B with an action REGBIT_NAT_REDIRECT = 1;
1446 next;. This flow is for east/west traffic to a NAT desti‐
1447 nation IPv4 address. By setting the REGBIT_NAT_REDIRECT
1448 flag, in the ingress table Gateway Redirect this will
1449 trigger a redirect to the instance of the gateway port on
1450 the redirect-chassis.
1451 A priority-0 logical flow with match 1 has actions next;.
1453 Ingress Table 5: IPv6 ND RA option processing
1455 · A priority-50 logical flow is added for each logical
1457 router port configured with IPv6 ND RA options which
1458 matches IPv6 ND Router Solicitation packet and applies
1459 the action put_nd_ra_opts and advances the packet to the
1460 next table.
1461 reg0[5] = put_nd_ra_opts(options);next;
1463 For a valid IPv6 ND RS packet, this transforms the packet
1466 into an IPv6 ND RA reply and sets the RA options to the
1467 packet and stores 1 into reg0[5]. For other kinds of
1468 packets, it just stores 0 into reg0[5]. Either way, it
1469 continues to the next table.
1470 · A priority-0 logical flow with match 1 has actions next;.
1472 Ingress Table 6: IPv6 ND RA responder
1474 This table implements IPv6 ND RA responder for the IPv6 ND RA replies
1476 generated by the previous table.
1477 · A priority-50 logical flow is added for each logical
1479 router port configured with IPv6 ND RA options which
1480 matches IPv6 ND RA packets and reg0[5] == 1 and responds
1481 back to the inport after applying these actions. If
1482 reg0[5] is set to 1, it means that the action
1483 put_nd_ra_opts was successful.
1484 eth.dst = eth.src;
1486 eth.src = E;
1487 ip6.dst = ip6.src;
1488 ip6.src = I;
1489 outport = P;
1490 flags.loopback = 1;
1491 output;
1492 where E is the MAC address and I is the IPv6 link local
1495 address of the logical router port.
1496 (This terminates packet processing in ingress pipeline;
1498 the packet does not go to the next ingress table.)
1499 · A priority-0 logical flow with match 1 has actions next;.
1501 Ingress Table 7: IP Routing
1503 A packet that arrives at this table is an IP packet that should be
1505 routed to the address in ip4.dst or ip6.dst. This table implements IP
1506 routing, setting reg0 (or xxreg0 for IPv6) to the next-hop IP address
1507 (leaving ip4.dst or ip6.dst, the packet’s final destination, unchanged)
1508 and advances to the next table for ARP resolution. It also sets reg1
1509 (or xxreg1) to the IP address owned by the selected router port
1510 (ingress table ARP Request will generate an ARP request, if needed,
1511 with reg0 as the target protocol address and reg1 as the source proto‐
1512 col address).
1513 This table contains the following logical flows:
1515 · For distributed logical routers where one of the logical
1517 router ports specifies a redirect-chassis, a priority-400
1518 logical flow for each ip source/destination couple that
1519 matches the dnat_and_snat NAT rules configured. These
1520 flows will allow to properly forward traffic to the
1521 external connections if available and avoid sending it
1522 through the tunnel. Assuming the two following NAT rules
1523 have been configured:
1524 external_ip{0,1} = EIP{0,1};
1526 external_mac{0,1} = MAC{0,1};
1527 logical_ip{0,1} = LIP{0,1};
1528 the following action will be applied:
1531 eth.dst = MAC0;
1533 eth.src = MAC1;
1534 reg0 = ip4.dst;
1535 reg1 = EIP1;
1536 outport = redirect-chassis-port;
1537 REGBIT_DISTRIBUTED_NAT = 1; next;.
1538 · For distributed logical routers where one of the logical
1541 router ports specifies a redirect-chassis, a priority-300
1542 logical flow with match REGBIT_NAT_REDIRECT == 1 has
1543 actions ip.ttl--; next;. The outport will be set later in
1544 the Gateway Redirect table.
1545 · IPv4 routing table. For each route to IPv4 network N with
1547 netmask M, on router port P with IP address A and Ether‐
1548 net address E, a logical flow with match ip4.dst == N/M,
1549 whose priority is the number of 1-bits in M, has the fol‐
1550 lowing actions:
1551 ip.ttl--;
1553 reg0 = G;
1554 reg1 = A;
1555 eth.src = E;
1556 outport = P;
1557 flags.loopback = 1;
1558 next;
1559 (Ingress table 1 already verified that ip.ttl--; will not
1562 yield a TTL exceeded error.)
1563 If the route has a gateway, G is the gateway IP address.
1565 Instead, if the route is from a configured static route,
1566 G is the next hop IP address. Else it is ip4.dst.
1567 · IPv6 routing table. For each route to IPv6 network N with
1569 netmask M, on router port P with IP address A and Ether‐
1570 net address E, a logical flow with match in CIDR notation
1571 ip6.dst == N/M, whose priority is the integer value of M,
1572 has the following actions:
1573 ip.ttl--;
1575 xxreg0 = G;
1576 xxreg1 = A;
1577 eth.src = E;
1578 outport = P;
1579 flags.loopback = 1;
1580 next;
1581 (Ingress table 1 already verified that ip.ttl--; will not
1584 yield a TTL exceeded error.)
1585 If the route has a gateway, G is the gateway IP address.
1587 Instead, if the route is from a configured static route,
1588 G is the next hop IP address. Else it is ip6.dst.
1589 If the address A is in the link-local scope, the route
1591 will be limited to sending on the ingress port.
1592 Ingress Table 8: ARP/ND Resolution
1594 Any packet that reaches this table is an IP packet whose next-hop IPv4
1596 address is in reg0 or IPv6 address is in xxreg0. (ip4.dst or ip6.dst
1597 contains the final destination.) This table resolves the IP address in
1598 reg0 (or xxreg0) into an output port in outport and an Ethernet address
1599 in eth.dst, using the following flows:
1600 · For distributed logical routers where one of the logical
1602 router ports specifies a redirect-chassis, a priority-400
1603 logical flow with match REGBIT_DISTRIBUTED_NAT == 1 has
1604 action next;
1605 For distributed logical routers where one of the logical
1607 router ports specifies a redirect-chassis, a priority-200
1608 logical flow with match REGBIT_NAT_REDIRECT == 1 has
1609 actions eth.dst = E; next;, where E is the ethernet
1610 address of the router’s distributed gateway port.
1611 · Static MAC bindings. MAC bindings can be known statically
1613 based on data in the OVN_Northbound database. For router
1614 ports connected to logical switches, MAC bindings can be
1615 known statically from the addresses column in the Logi‐
1616 cal_Switch_Port table. For router ports connected to
1617 other logical routers, MAC bindings can be known stati‐
1618 cally from the mac and networks column in the Logi‐
1619 cal_Router_Port table.
1620 For each IPv4 address A whose host is known to have Eth‐
1622 ernet address E on router port P, a priority-100 flow
1623 with match outport === P && reg0 == A has actions eth.dst
1624 = E; next;.
1625 For each IPv6 address A whose host is known to have Eth‐
1627 ernet address E on router port P, a priority-100 flow
1628 with match outport === P && xxreg0 == A has actions
1629 eth.dst = E; next;.
1630 For each logical router port with an IPv4 address A and a
1632 mac address of E that is reachable via a different logi‐
1633 cal router port P, a priority-100 flow with match outport
1634 === P && reg0 == A has actions eth.dst = E; next;.
1635 For each logical router port with an IPv6 address A and a
1637 mac address of E that is reachable via a different logi‐
1638 cal router port P, a priority-100 flow with match outport
1639 === P && xxreg0 == A has actions eth.dst = E; next;.
1640 · Dynamic MAC bindings. These flows resolve MAC-to-IP bind‐
1642 ings that have become known dynamically through ARP or
1643 neighbor discovery. (The ingress table ARP Request will
1644 issue an ARP or neighbor solicitation request for cases
1645 where the binding is not yet known.)
1646 A priority-0 logical flow with match ip4 has actions
1648 get_arp(outport, reg0); next;.
1649 A priority-0 logical flow with match ip6 has actions
1651 get_nd(outport, xxreg0); next;.
1652 Ingress Table 9: Check packet length
1654 For distributed logical routers with distributed gateway port config‐
1656 ured with options:gateway_mtu to a valid integer value, this table adds
1657 a priority-50 logical flow with the match ip4 && outport == GW_PORT
1658 where GW_PORT is the distributed gateway router port and applies the
1659 action check_pkt_larger and advances the packet to the next table.
1660 REGBIT_PKT_LARGER = check_pkt_larger(L); next;
1662 where L is the packet length to check for. If the packet is larger than
1665 L, it stores 1 in the register bit REGBIT_PKT_LARGER. The value of L is
1666 taken from options:gateway_mtu column of Logical_Router_Port row.
1667 This table adds one priority-0 fallback flow that matches all packets
1669 and advances to the next table.
1670 Ingress Table 10: Handle larger packets
1672 For distributed logical routers with distributed gateway port config‐
1674 ured with options:gateway_mtu to a valid integer value, this table adds
1675 the following priority-50 logical flow for each logical router port
1676 with the match ip4 && inport == LRP && outport == GW_PORT && REG‐
1677 BIT_PKT_LARGER, where LRP is the logical router port and GW_PORT is the
1678 distributed gateway router port and applies the following action
1679 icmp4 {
1681 icmp4.type = 3; /* Destination Unreachable. */
1682 icmp4.code = 4; /* Frag Needed and DF was Set. */
1683 icmp4.frag_mtu = M;
1684 eth.dst = E;
1685 ip4.dst = ip4.src;
1686 ip4.src = I;
1687 ip.ttl = 255;
1688 REGBIT_EGRESS_LOOPBACK = 1;
1689 next(pipeline=ingress, table=0);
1690 };
1691 · Where M is the (fragment MTU - 58) whose value is taken
1694 from options:gateway_mtu column of Logical_Router_Port
1695 row.
1696 · E is the Ethernet address of the logical router port.
1698 · I is the IPv4 address of the logical router port.
1700 This table adds one priority-0 fallback flow that matches all packets
1702 and advances to the next table.
1703 Ingress Table 11: Gateway Redirect
1705 For distributed logical routers where one of the logical router ports
1707 specifies a redirect-chassis, this table redirects certain packets to
1708 the distributed gateway port instance on the redirect-chassis. This ta‐
1709 ble has the following flows:
1710 · A priority-300 logical flow with match REGBIT_DISTRIB‐
1712 UTED_NAT == 1 has action next;
1713 · A priority-200 logical flow with match REGBIT_NAT_REDI‐
1715 RECT == 1 has actions outport = CR; next;, where CR is
1716 the chassisredirect port representing the instance of the
1717 logical router distributed gateway port on the redi‐
1718 rect-chassis.
1719 · A priority-150 logical flow with match outport == GW &&
1721 eth.dst == 00:00:00:00:00:00 has actions outport = CR;
1722 next;, where GW is the logical router distributed gateway
1723 port and CR is the chassisredirect port representing the
1724 instance of the logical router distributed gateway port
1725 on the redirect-chassis.
1726 · For each NAT rule in the OVN Northbound database that can
1728 be handled in a distributed manner, a priority-100 logi‐
1729 cal flow with match ip4.src == B && outport == GW, where
1730 GW is the logical router distributed gateway port, with
1731 actions next;.
1732 · A priority-50 logical flow with match outport == GW has
1734 actions outport = CR; next;, where GW is the logical
1735 router distributed gateway port and CR is the chas‐
1736 sisredirect port representing the instance of the logical
1737 router distributed gateway port on the redirect-chassis.
1738 · A priority-0 logical flow with match 1 has actions next;.
1740 Ingress Table 12: ARP Request
1742 In the common case where the Ethernet destination has been resolved,
1744 this table outputs the packet. Otherwise, it composes and sends an ARP
1745 or IPv6 Neighbor Solicitation request. It holds the following flows:
1746 · Unknown MAC address. A priority-100 flow for IPv4 packets
1748 with match eth.dst == 00:00:00:00:00:00 has the following
1749 actions:
1750 arp {
1752 eth.dst = ff:ff:ff:ff:ff:ff;
1753 arp.spa = reg1;
1754 arp.tpa = reg0;
1755 arp.op = 1; /* ARP request. */
1756 output;
1757 };
1758 Unknown MAC address. For each IPv6 static route associ‐
1761 ated with the router with the nexthop IP: G, a prior‐
1762 ity-200 flow for IPv6 packets with match eth.dst ==
1763 00:00:00:00:00:00 && xxreg0 == G with the following
1764 actions is added:
1765 nd_ns {
1767 eth.dst = E;
1768 ip6.dst = I
1769 nd.target = G;
1770 output;
1771 };
1772 Where E is the multicast mac derived from the Gateway IP,
1775 I is the solicited-node multicast address corresponding
1776 to the target address G.
1777 Unknown MAC address. A priority-100 flow for IPv6 packets
1779 with match eth.dst == 00:00:00:00:00:00 has the following
1780 actions:
1781 nd_ns {
1783 nd.target = xxreg0;
1784 output;
1785 };
1786 (Ingress table IP Routing initialized reg1 with the IP
1789 address owned by outport and (xx)reg0 with the next-hop
1790 IP address)
1791 The IP packet that triggers the ARP/IPv6 NS request is
1793 dropped.
1794 · Known MAC address. A priority-0 flow with match 1 has
1796 actions output;.
1797 Egress Table 0: UNDNAT
1799 This is for already established connections’ reverse traffic. i.e.,
1801 DNAT has already been done in ingress pipeline and now the packet has
1802 entered the egress pipeline as part of a reply. For NAT on a distrib‐
1803 uted router, it is unDNATted here. For Gateway routers, the unDNAT pro‐
1804 cessing is carried out in the ingress DNAT table.
1805 · For all the configured load balancing rules for a router
1807 with gateway port in OVN_Northbound database that
1808 includes an IPv4 address VIP, for every backend IPv4
1809 address B defined for the VIP a priority-120 flow is pro‐
1810 grammed on redirect-chassis that matches ip && ip4.src ==
1811 B && outport == GW, where GW is the logical router gate‐
1812 way port with an action ct_dnat;. If the backend IPv4
1813 address B is also configured with L4 port PORT of proto‐
1814 col P, then the match also includes P.src == PORT. These
1815 flows are not added for load balancers with IPv6 VIPs.
1816 If the router is configured to force SNAT any load-bal‐
1818 anced packets, above action will be replaced by
1819 flags.force_snat_for_lb = 1; ct_dnat;.
1820 · For each configuration in the OVN Northbound database
1822 that asks to change the destination IP address of a
1823 packet from an IP address of A to B, a priority-100 flow
1824 matches ip && ip4.src == B && outport == GW, where GW is
1825 the logical router gateway port, with an action ct_dnat;.
1826 If the NAT rule cannot be handled in a distributed man‐
1828 ner, then the priority-100 flow above is only programmed
1829 on the redirect-chassis.
1830 If the NAT rule can be handled in a distributed manner,
1832 then there is an additional action eth.src = EA;, where
1833 EA is the ethernet address associated with the IP address
1834 A in the NAT rule. This allows upstream MAC learning to
1835 point to the correct chassis.
1836 · A priority-0 logical flow with match 1 has actions next;.
1838 Egress Table 1: SNAT
1840 Packets that are configured to be SNATed get their source IP address
1842 changed based on the configuration in the OVN Northbound database.
1843 Egress Table 1: SNAT on Gateway Routers
1845 · If the Gateway router in the OVN Northbound database has
1847 been configured to force SNAT a packet (that has been
1848 previously DNATted) to B, a priority-100 flow matches
1849 flags.force_snat_for_dnat == 1 && ip with an action
1850 ct_snat(B);.
1851 If the Gateway router in the OVN Northbound database has
1853 been configured to force SNAT a packet (that has been
1854 previously load-balanced) to B, a priority-100 flow
1855 matches flags.force_snat_for_lb == 1 && ip with an action
1856 ct_snat(B);.
1857 For each configuration in the OVN Northbound database,
1859 that asks to change the source IP address of a packet
1860 from an IP address of A or to change the source IP
1861 address of a packet that belongs to network A to B, a
1862 flow matches ip && ip4.src == A with an action
1863 ct_snat(B);. The priority of the flow is calculated based
1864 on the mask of A, with matches having larger masks get‐
1865 ting higher priorities.
1866 A priority-0 logical flow with match 1 has actions next;.
1868 Egress Table 1: SNAT on Distributed Routers
1870 · For each configuration in the OVN Northbound database,
1872 that asks to change the source IP address of a packet
1873 from an IP address of A or to change the source IP
1874 address of a packet that belongs to network A to B, a
1875 flow matches ip && ip4.src == A && outport == GW, where
1876 GW is the logical router gateway port, with an action
1877 ct_snat(B);. The priority of the flow is calculated based
1878 on the mask of A, with matches having larger masks get‐
1879 ting higher priorities.
1880 If the NAT rule cannot be handled in a distributed man‐
1882 ner, then the flow above is only programmed on the redi‐
1883 rect-chassis.
1884 If the NAT rule can be handled in a distributed manner,
1886 then there is an additional action eth.src = EA;, where
1887 EA is the ethernet address associated with the IP address
1888 A in the NAT rule. This allows upstream MAC learning to
1889 point to the correct chassis.
1890 · A priority-0 logical flow with match 1 has actions next;.
1892 Egress Table 2: Egress Loopback
1894 For distributed logical routers where one of the logical router ports
1896 specifies a redirect-chassis.
1897 Earlier in the ingress pipeline, some east-west traffic was redirected
1899 to the chassisredirect port, based on flows in the UNSNAT and DNAT
1900 ingress tables setting the REGBIT_NAT_REDIRECT flag, which then trig‐
1901 gered a match to a flow in the Gateway Redirect ingress table. The
1902 intention was not to actually send traffic out the distributed gateway
1903 port instance on the redirect-chassis. This traffic was sent to the
1904 distributed gateway port instance in order for DNAT and/or SNAT pro‐
1905 cessing to be applied.
1906 While UNDNAT and SNAT processing have already occurred by this point,
1908 this traffic needs to be forced through egress loopback on this dis‐
1909 tributed gateway port instance, in order for UNSNAT and DNAT processing
1910 to be applied, and also for IP routing and ARP resolution after all of
1911 the NAT processing, so that the packet can be forwarded to the destina‐
1912 tion.
1913 This table has the following flows:
1915 · For each dnat_and_snat NAT rule couple in the OVN North‐
1917 bound database on a distributed router, a priority-200
1918 logical with match ip4.dst == external_ip0 && ip4.src ==
1919 external_ip1, has action next;
1920 For each NAT rule in the OVN Northbound database on a
1922 distributed router, a priority-100 logical flow with
1923 match ip4.dst == E && outport == GW, where E is the
1924 external IP address specified in the NAT rule, and GW is
1925 the logical router distributed gateway port, with the
1926 following actions:
1927 clone {
1929 ct_clear;
1930 inport = outport;
1931 outport = "";
1932 flags = 0;
1933 flags.loopback = 1;
1934 reg0 = 0;
1935 reg1 = 0;
1936 ...
1937 reg9 = 0;
1938 REGBIT_EGRESS_LOOPBACK = 1;
1939 next(pipeline=ingress, table=0);
1940 };
1941 flags.loopback is set since in_port is unchanged and the
1944 packet may return back to that port after NAT processing.
1945 REGBIT_EGRESS_LOOPBACK is set to indicate that egress
1946 loopback has occurred, in order to skip the source IP
1947 address check against the router address.
1948 · A priority-0 logical flow with match 1 has actions next;.
1950 Egress Table 3: Delivery
1952 Packets that reach this table are ready for delivery. It contains pri‐
1954 ority-100 logical flows that match packets on each enabled logical
1955 router port, with action output;.
1956Open vSwitch 2.11.1 ovn-northd ovn-northd(8)