-
Notifications
You must be signed in to change notification settings - Fork 237
/
ovn-northd.8.xml
5095 lines (4480 loc) · 191 KB
/
ovn-northd.8.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="utf-8"?>
<manpage program="ovn-northd" section="8" title="ovn-northd">
<h1>Name</h1>
<p>ovn-northd and ovn-northd-ddlog -- Open Virtual Network central control daemon</p>
<h1>Synopsis</h1>
<p><code>ovn-northd</code> [<var>options</var>]</p>
<h1>Description</h1>
<p>
<code>ovn-northd</code> is a centralized daemon responsible for
translating the high-level OVN configuration into logical
configuration consumable by daemons such as
<code>ovn-controller</code>. It translates the logical network
configuration in terms of conventional network concepts, taken
from the OVN Northbound Database (see <code>ovn-nb</code>(5)),
into logical datapath flows in the OVN Southbound Database (see
<code>ovn-sb</code>(5)) below it.
</p>
<p>
<code>ovn-northd</code> is implemented in C.
<code>ovn-northd-ddlog</code> is a compatible implementation written in
DDlog, a language for incremental database processing. This
documentation applies to both implementations, with differences indicated
where relevant.
</p>
<h1>Options</h1>
<dl>
<dt><code>--ovnnb-db=<var>database</var></code></dt>
<dd>
The OVSDB database containing the OVN Northbound Database. If the
<env>OVN_NB_DB</env> environment variable is set, its value is used
as the default. Otherwise, the default is
<code>unix:@RUNDIR@/ovnnb_db.sock</code>.
</dd>
<dt><code>--ovnsb-db=<var>database</var></code></dt>
<dd>
The OVSDB database containing the OVN Southbound Database. If the
<env>OVN_SB_DB</env> environment variable is set, its value is used
as the default. Otherwise, the default is
<code>unix:@RUNDIR@/ovnsb_db.sock</code>.
</dd>
<dt><code>--ddlog-record=<var>file</var></code></dt>
<dd>
This option is for <code>ovn-north-ddlog</code> only. It causes the
daemon to record the initial database state and later changes to
<var>file</var> in the text-based DDlog command format. The
<code>ovn_northd_cli</code> program can later replay these changes for
debugging purposes. This option has a performance impact. See
<code>debugging-ddlog.rst</code> in the OVN documentation for more
details.
</dd>
<dt><code>--dry-run</code></dt>
<dd>
<p>
Causes <code>ovn-northd</code> to start paused. In the paused state,
<code>ovn-northd</code> does not apply any changes to the databases,
although it continues to monitor them. For more information, see the
<code>pause</code> command, under <code>Runtime Management
Commands</code> below.
</p>
<p>
For <code>ovn-northd-ddlog</code>, one could use this option with
<code>--ddlog-record</code> to generate a replay log without
restarting a process or disturbing a running system.
</p>
</dd>
<dt><code>n-threads N</code></dt>
<dd>
<p>
In certain situations, it may be desirable to enable parallelization
on a system to decrease latency (at the potential cost of increasing
CPU usage).
</p>
<p>
This option will cause ovn-northd to use N threads when building
logical flows, when N is within [2-256].
If N is 1, parallelization is disabled (default behavior).
If N is less than 1, then N is set to 1, parallelization is disabled
and a warning is logged.
If N is more than 256, then N is set to 256, parallelization is
enabled (with 256 threads) and a warning is logged.
</p>
<p>
ovn-northd-ddlog does not support this option.
</p>
</dd>
</dl>
<p>
<var>database</var> in the above options must be an OVSDB active or
passive connection method, as described in <code>ovsdb</code>(7).
</p>
<h2>Daemon Options</h2>
<xi:include href="lib/daemon.xml" xmlns:xi="http://www.w3.org/2003/XInclude"/>
<h2>Logging Options</h2>
<xi:include href="lib/vlog.xml" xmlns:xi="http://www.w3.org/2003/XInclude"/>
<h2>PKI Options</h2>
<p>
PKI configuration is required in order to use SSL for the connections to
the Northbound and Southbound databases.
</p>
<xi:include href="lib/ssl.xml" xmlns:xi="http://www.w3.org/2003/XInclude"/>
<h2>Other Options</h2>
<xi:include href="lib/unixctl.xml"
xmlns:xi="http://www.w3.org/2003/XInclude"/>
<h3></h3>
<xi:include href="lib/common.xml"
xmlns:xi="http://www.w3.org/2003/XInclude"/>
<h1>Runtime Management Commands</h1>
<p>
<code>ovs-appctl</code> can send commands to a running
<code>ovn-northd</code> process. The currently supported commands
are described below.
<dl>
<dt><code>exit</code></dt>
<dd>
Causes <code>ovn-northd</code> to gracefully terminate.
</dd>
<dt><code>pause</code></dt>
<dd>
Pauses <code>ovn-northd</code>. When it is paused,
<code>ovn-northd</code> receives changes from the Northbound and
Southbound database changes as usual, but it does not send any updates.
A paused <code>ovn-northd</code> also drops database locks, which
allows any other non-paused instance of <code>ovn-northd</code> to take
over.
</dd>
<dt><code>resume</code></dt>
<dd>
Resumes the ovn-northd operation to process Northbound and
Southbound database contents and generate logical flows. This will
also instruct ovn-northd to aspire for the lock on SB DB.
</dd>
<dt><code>is-paused</code></dt>
<dd>
Returns "true" if ovn-northd is currently paused, "false" otherwise.
</dd>
<dt><code>status</code></dt>
<dd>
Prints this server's status. Status will be "active" if ovn-northd has
acquired OVSDB lock on SB DB, "standby" if it has not or "paused" if
this instance is paused.
</dd>
<dt><code>sb-cluster-state-reset</code></dt>
<dd>
<p>
Reset southbound database cluster status when databases are destroyed
and rebuilt.
</p>
<p>
If all databases in a clustered southbound database are removed from
disk, then the stored index of all databases will be reset to zero.
This will cause ovn-northd to be unable to read or write to the
southbound database, because it will always detect the data as stale.
In such a case, run this command so that ovn-northd will reset its
local index so that it can interact with the southbound database again.
</p>
</dd>
<dt><code>nb-cluster-state-reset</code></dt>
<dd>
<p>
Reset northbound database cluster status when databases are destroyed
and rebuilt.
</p>
<p>
This performs the same task as <code>sb-cluster-state-reset</code>
except for the northbound database client.
</p>
</dd>
<dt><code>set-n-threads N</code></dt>
<dd>
<p>
Set the number of threads used for building logical flows.
When N is within [2-256], parallelization is enabled.
When N is 1 parallelization is disabled.
When N is less than 1 or more than 256, an error is returned.
If ovn-northd fails to start parallelization (e.g. fails to setup
semaphores, parallelization is disabled and an error is returned.
</p>
</dd>
<dt><code>get-n-threads</code></dt>
<dd>
<p>
Return the number of threads used for building logical flows.
</p>
</dd>
<dt><code>inc-engine/show-stats</code></dt>
<dd>
<p>
Display <code>ovn-northd</code> engine counters. For each engine
node the following counters have been added:
<ul>
<li>
<code>recompute</code>
</li>
<li>
<code>compute</code>
</li>
<li>
<code>abort</code>
</li>
</ul>
</p>
</dd>
<dt><code>inc-engine/show-stats <var>engine_node_name</var> <var>counter_name</var></code></dt>
<dd>
<p>
Display the <code>ovn-northd</code> engine counter(s) for the specified
<var>engine_node_name</var>. <var>counter_name</var> is optional and
can be one of <code>recompute</code>, <code>compute</code> or
<code>abort</code>.
</p>
</dd>
<dt><code>inc-engine/clear-stats</code></dt>
<dd>
<p> Reset <code>ovn-northd</code> engine counters. </p>
</dd>
</dl>
</p>
<p>
Only <code>ovn-northd-ddlog</code> supports the following commands:
</p>
<dl>
<dt><code>enable-cpu-profiling</code></dt>
<dt><code>disable-cpu-profiling</code></dt>
<dd>
Enables or disables profiling of CPU time used by the DDlog engine.
When CPU profiling is enabled, the <code>profile</code> command (see
below) will include DDlog CPU usage statistics in its output. Enabling
CPU profiling will slow <code>ovn-northd-ddlog</code>. Disabling CPU
profiling does not clear any previously recorded statistics.
</dd>
<dt><code>profile</code></dt>
<dd>
Outputs a profile of the current and peak sizes of arrangements inside
DDlog. This profiling data can be useful for optimizing DDlog code.
If CPU profiling was previously enabled (even if it was later
disabled), the output also includes a CPU time profile. See
<code>Profiling</code> inside the tutorial in the DDlog repository for
an introduction to profiling DDlog.
</dd>
</dl>
<h1>Active-Standby for High Availability</h1>
<p>
You may run <code>ovn-northd</code> more than once in an OVN deployment.
When connected to a standalone or clustered DB setup, OVN will
automatically ensure that only one of them is active at a time.
If multiple instances of <code>ovn-northd</code> are running and the
active <code>ovn-northd</code> fails, one of the hot standby instances
of <code>ovn-northd</code> will automatically take over.
</p>
<h2> Active-Standby with multiple OVN DB servers</h2>
<p>
You may run multiple OVN DB servers in an OVN deployment with:
<ul>
<li>
OVN DB servers deployed in active/passive mode with one active
and multiple passive ovsdb-servers.
</li>
<li>
<code>ovn-northd</code> also deployed on all these nodes,
using unix ctl sockets to connect to the local OVN DB servers.
</li>
</ul>
</p>
<p>
In such deployments, the ovn-northds on the passive nodes will process
the DB changes and compute logical flows to be thrown out later,
because write transactions are not allowed by the passive ovsdb-servers.
It results in unnecessary CPU usage.
</p>
<p>
With the help of runtime management command <code>pause</code>, you can
pause <code>ovn-northd</code> on these nodes. When a passive node
becomes master, you can use the runtime management command
<code>resume</code> to resume the <code>ovn-northd</code> to process the
DB changes.
</p>
<h1>Logical Flow Table Structure</h1>
<p>
One of the main purposes of <code>ovn-northd</code> is to populate the
<code>Logical_Flow</code> table in the <code>OVN_Southbound</code>
database. This section describes how <code>ovn-northd</code> does this
for switch and router logical datapaths.
</p>
<h2>Logical Switch Datapaths</h2>
<h3>Ingress Table 0: Admission Control and Ingress Port Security check</h3>
<p>
Ingress table 0 contains these logical flows:
</p>
<ul>
<li>
Priority 100 flows to drop packets with VLAN tags or multicast Ethernet
source addresses.
</li>
<li>
For each disabled logical port, a priority 100 flow is added which
matches on all packets and applies the action
<code>REGBIT_PORT_SEC_DROP" = 1; next;"</code> so that the packets are
dropped in the next stage.
</li>
<li>
For each (enabled) vtep logical port, a priority 70 flow is added which
matches on all packets and applies the action
<code>next(pipeline=ingress, table=S_SWITCH_IN_L2_LKUP) = 1;</code>
to skip most stages of ingress pipeline and go directly to ingress L2
lookup table to determine the output port. Packets from VTEP (RAMP)
switch should not be subjected to any ACL checks. Egress pipeline will
do the ACL checks.
</li>
<li>
For each enabled logical port configured with qdisc queue id in the
<ref column="options:qdisc_queue_id" table="Logical_Switch_Port"
db="OVN_Northbound"/> column of <ref table="Logical_Switch_Port"
db="OVN_Northbound"/>, a priority 70 flow is added which
matches on all packets and applies the action
<code>set_queue(id);
REGBIT_PORT_SEC_DROP" = check_in_port_sec(); next;"</code>.
</li>
<li>
A priority 1 flow is added which matches on all packets for all the
logical ports and applies the action
<code>REGBIT_PORT_SEC_DROP" = check_in_port_sec(); next;</code> to
evaluate the port security. The action <code>check_in_port_sec</code>
applies the port security rules defined in the
<ref column="port_security" table="Logical_Switch_Port"
db="OVN_Northbound"/> column of <ref table="Logical_Switch_Port"
db="OVN_Northbound"/> table.
</li>
</ul>
<h3>Ingress Table 1: Ingress Port Security - Apply</h3>
<p>
This table drops the packets if the port security check failed
in the previous stage i.e the register bit
<code>REGBIT_PORT_SEC_DROP</code> is set to 1.
</p>
<p>
Ingress table 1 contains these logical flows:
</p>
<ul>
<li>
A priority-50 fallback flow that drops the packet if the register
bit <code>REGBIT_PORT_SEC_DROP</code> is set to 1.
</li>
<li>
One priority-0 fallback flow that matches all packets and advances to
the next table.
</li>
</ul>
<h3>Ingress Table 2: Lookup MAC address learning table</h3>
<p>
This table looks up the MAC learning table of the logical switch
datapath to check if the <code>port-mac</code> pair is present
or not. MAC is learnt only for logical switch VIF ports whose
port security is disabled and 'unknown' address set.
</p>
<ul>
<li>
<p>
For each such logical port <var>p</var> whose port security
is disabled and 'unknown' address set following flow
is added.
</p>
<ul>
<li>
Priority 100 flow with the match
<code>inport == <var>p</var></code> and action
<code>reg0[11] = lookup_fdb(inport, eth.src); next;</code>
</li>
</ul>
</li>
<li>
One priority-0 fallback flow that matches all packets and advances to
the next table.
</li>
</ul>
<h3>Ingress Table 3: Learn MAC of 'unknown' ports.</h3>
<p>
This table learns the MAC addresses seen on the logical ports
whose port security is disabled and 'unknown' address set
if the <code>lookup_fdb</code> action returned false in the
previous table.
</p>
<ul>
<li>
<p>
For each such logical port <var>p</var> whose port security
is disabled and 'unknown' address set following flow
is added.
</p>
<ul>
<li>
Priority 100 flow with the match
<code>inport == <var>p</var> && reg0[11] == 0</code> and
action <code>put_fdb(inport, eth.src); next;</code> which stores
the <code>port-mac</code> in the mac learning table of the
logical switch datapath and advances the packet to the next table.
</li>
</ul>
</li>
<li>
One priority-0 fallback flow that matches all packets and advances to
the next table.
</li>
</ul>
<h3>Ingress Table 4: <code>from-lport</code> Pre-ACLs</h3>
<p>
This table prepares flows for possible stateful ACL processing in
ingress table <code>ACLs</code>. It contains a priority-0 flow that
simply moves traffic to the next table. If stateful ACLs are used in the
logical datapath, a priority-100 flow is added that sets a hint
(with <code>reg0[0] = 1; next;</code>) for table
<code>Pre-stateful</code> to send IP packets to the connection tracker
before eventually advancing to ingress table <code>ACLs</code>. If
special ports such as route ports or localnet ports can't use ct(), a
priority-110 flow is added to skip over stateful ACLs. Multicast, IPv6
Neighbor Discovery and MLD traffic also skips stateful ACLs. For
"allow-stateless" ACLs, a flow is added to bypass setting the hint for
connection tracker processing when there are stateful ACLs or LB rules;
<code>REGBIT_ACL_STATELESS</code> is set for traffic matching stateless
ACL flows.
</p>
<p>
This table also has a priority-110 flow with the match
<code>eth.dst == <var>E</var></code> for all logical switch
datapaths to move traffic to the next table. Where <var>E</var>
is the service monitor mac defined in the
<ref column="options:svc_monitor_mac" table="NB_Global"
db="OVN_Northbound"/> column of <ref table="NB_Global"
db="OVN_Northbound"/> table.
</p>
<h3>Ingress Table 5: Pre-LB</h3>
<p>
This table prepares flows for possible stateful load balancing processing
in ingress table <code>LB</code> and <code>Stateful</code>. It contains
a priority-0 flow that simply moves traffic to the next table. Moreover
it contains two priority-110 flows to move multicast, IPv6 Neighbor
Discovery and MLD traffic to the next table. It also contains two
priority-110 flows to move stateless traffic, i.e traffic for which
<code>REGBIT_ACL_STATELESS</code> is set, to the next table. If load
balancing rules with virtual IP addresses (and ports) are configured in
<code>OVN_Northbound</code> database for a logical switch datapath, a
priority-100 flow is added with the match <code>ip</code> to match on IP
packets and sets the action <code>reg0[2] = 1; next;</code> to act as a
hint for table <code>Pre-stateful</code> to send IP packets to the
connection tracker for packet de-fragmentation (and to possibly do DNAT
for already established load balanced traffic) before eventually
advancing to ingress table <code>Stateful</code>.
If controller_event has been enabled and load balancing rules with
empty backends have been added in <code>OVN_Northbound</code>, a 130 flow
is added to trigger ovn-controller events whenever the chassis receives a
packet for that particular VIP. If <code>event-elb</code> meter has been
previously created, it will be associated to the empty_lb logical flow
</p>
<p>
Prior to <code>OVN 20.09</code> we were setting the
<code>reg0[0] = 1</code> only if the IP destination matches the load
balancer VIP. However this had few issues cases where a logical switch
doesn't have any ACLs with <code>allow-related</code> action.
To understand the issue lets a take a TCP load balancer -
<code>10.0.0.10:80=10.0.0.3:80</code>. If a logical port - p1 with
IP - 10.0.0.5 opens a TCP connection with the VIP - 10.0.0.10, then the
packet in the ingress pipeline of 'p1' is sent to the p1's conntrack zone
id and the packet is load balanced to the backend - 10.0.0.3. For the
reply packet from the backend lport, it is not sent to the conntrack of
backend lport's zone id. This is fine as long as the packet is valid.
Suppose the backend lport sends an invalid TCP packet (like incorrect
sequence number), the packet gets delivered to the lport 'p1' without
unDNATing the packet to the VIP - 10.0.0.10. And this causes the
connection to be reset by the lport p1's VIF.
</p>
<p>
We can't fix this issue by adding a logical flow to drop ct.inv packets
in the egress pipeline since it will drop all other connections not
destined to the load balancers. To fix this issue, we send all the
packets to the conntrack in the ingress pipeline if a load balancer is
configured. We can now add a lflow to drop ct.inv packets.
</p>
<p>
This table also has priority-120 flows that punt all IGMP/MLD packets to
<code>ovn-controller</code> if the switch is an interconnect switch
with multicast snooping enabled.
</p>
<p>
This table also has a priority-110 flow with the match
<code>eth.dst == <var>E</var></code> for all logical switch
datapaths to move traffic to the next table. Where <var>E</var>
is the service monitor mac defined in the
<ref column="options:svc_monitor_mac" table="NB_Global"
db="OVN_Northbound"/> column of <ref table="NB_Global"
db="OVN_Northbound"/> table.
</p>
<p>
This table also has a priority-110 flow with the match
<code>inport == <var>I</var></code> for all logical switch
datapaths to move traffic to the next table. Where <var>I</var>
is the peer of a logical router port. This flow is added to
skip the connection tracking of packets which enter from
logical router datapath to logical switch datapath.
</p>
<h3>Ingress Table 6: Pre-stateful</h3>
<p>
This table prepares flows for all possible stateful processing
in next tables. It contains a priority-0 flow that simply moves
traffic to the next table.
</p>
<ul>
<li>
Priority-120 flows that send the packets to connection tracker using
<code>ct_lb_mark;</code> as the action so that the already established
traffic destined to the load balancer VIP gets DNATted. These flows
match each VIPs IP and port. For IPv4 traffic the flows also load the
original destination IP and transport port in registers
<code>reg1</code> and <code>reg2</code>. For IPv6 traffic the flows
also load the original destination IP and transport port in
registers <code>xxreg1</code> and <code>reg2</code>.
</li>
<li>
A priority-110 flow sends the packets that don't match the above flows
to connection tracker based on a hint provided by the previous tables
(with a match for <code>reg0[2] == 1</code>) by using the
<code>ct_lb_mark;</code> action.
</li>
<li>
A priority-100 flow sends the packets to connection tracker based
on a hint provided by the previous tables
(with a match for <code>reg0[0] == 1</code>) by using the
<code>ct_next;</code> action.
</li>
</ul>
<h3>Ingress Table 7: <code>from-lport</code> ACL hints</h3>
<p>
This table consists of logical flows that set hints
(<code>reg0</code> bits) to be used in the next stage, in the ACL
processing table, if stateful ACLs or load balancers are configured.
Multiple hints can be set for the same packet.
The possible hints are:
</p>
<ul>
<li>
<code>reg0[7]</code>: the packet might match an
<code>allow-related</code> ACL and might have to commit the
connection to conntrack.
</li>
<li>
<code>reg0[8]</code>: the packet might match an
<code>allow-related</code> ACL but there will be no need to commit
the connection to conntrack because it already exists.
</li>
<li>
<code>reg0[9]</code>: the packet might match a
<code>drop/reject</code>.
</li>
<li>
<code>reg0[10]</code>: the packet might match a
<code>drop/reject</code> ACL but the connection was previously
allowed so it might have to be committed again with
<code>ct_label=1/1</code>.
</li>
</ul>
<p>
The table contains the following flows:
</p>
<ul>
<li>
A priority-65535 flow to advance to the next table if the logical
switch has <code>no</code> ACLs configured, otherwise a
priority-0 flow to advance to the next table.
</li>
</ul>
<ul>
<li>
A priority-7 flow that matches on packets that initiate a new session.
This flow sets <code>reg0[7]</code> and <code>reg0[9]</code> and
then advances to the next table.
</li>
<li>
A priority-6 flow that matches on packets that are in the request
direction of an already existing session that has been marked
as blocked. This flow sets <code>reg0[7]</code> and
<code>reg0[9]</code> and then advances to the next table.
</li>
<li>
A priority-5 flow that matches untracked packets. This flow sets
<code>reg0[8]</code> and <code>reg0[9]</code> and then advances to
the next table.
</li>
<li>
A priority-4 flow that matches on packets that are in the request
direction of an already existing session that has not been marked
as blocked. This flow sets <code>reg0[8]</code> and
<code>reg0[10]</code> and then advances to the next table.
</li>
<li>
A priority-3 flow that matches on packets that are in not part of
established sessions. This flow sets <code>reg0[9]</code> and then
advances to the next table.
</li>
<li>
A priority-2 flow that matches on packets that are part of an
established session that has been marked as blocked.
This flow sets <code>reg0[9]</code> and then advances to the next
table.
</li>
<li>
A priority-1 flow that matches on packets that are part of an
established session that has not been marked as blocked.
This flow sets <code>reg0[10]</code> and then advances to the next
table.
</li>
</ul>
<h3>Ingress table 8: <code>from-lport</code> ACLs before LB</h3>
<p>
Logical flows in this table closely reproduce those in the
<code>ACL</code> table in the <code>OVN_Northbound</code> database
for the <code>from-lport</code> direction without the option
<code>apply-after-lb</code> set or set to <code>false</code>.
The <code>priority</code> values from the <code>ACL</code> table have a
limited range and have 1000 added to them to leave room for OVN default
flows at both higher and lower priorities.
</p>
<ul>
<li>
<code>allow</code> ACLs translate into logical flows with
the <code>next;</code> action. If there are any stateful ACLs
on this datapath, then <code>allow</code> ACLs translate to
<code>ct_commit; next;</code> (which acts as a hint for the next tables
to commit the connection to conntrack). In case the <code>ACL</code>
has a label then <code>reg3</code> is loaded with the label value and
<code>reg0[13]</code> bit is set to 1 (which acts as a hint for the
next tables to commit the label to conntrack).
</li>
<li>
<code>allow-related</code> ACLs translate into logical
flows with the <code>ct_commit(ct_label=0/1); next;</code> actions
for new connections and <code>reg0[1] = 1; next;</code> for existing
connections. In case the <code>ACL</code> has a label then
<code>reg3</code> is loaded with the label value and
<code>reg0[13]</code> bit is set to 1 (which acts as a hint for the
next tables to commit the label to conntrack).
</li>
<li>
<code>allow-stateless</code> ACLs translate into logical
flows with the <code>next;</code> action.
</li>
<li>
<code>reject</code> ACLs translate into logical
flows with the
<code>tcp_reset { output <-> inport;
next(pipeline=egress,table=5);}</code>
action for TCP connections,<code>icmp4/icmp6</code> action
for UDP connections, and <code>sctp_abort {output <-%gt; inport;
next(pipeline=egress,table=5);}</code> action for SCTP associations.
</li>
<li>
Other ACLs translate to <code>drop;</code> for new or untracked
connections and <code>ct_commit(ct_label=1/1);</code> for known
connections. Setting <code>ct_label</code> marks a connection
as one that was previously allowed, but should no longer be
allowed due to a policy change.
</li>
</ul>
<p>
This table contains a priority-65535 flow to advance to the next table
if the logical switch has <code>no</code> ACLs configured, otherwise a
priority-0 flow to advance to the next table so that ACLs allow
packets by default if <ref column="options:default_acl_drop"
table="NB_Global" db="OVN_Northbound"/> column of <ref table="NB_Global"
db="OVN_Northbound"/> is <code>false</code> or not set. Otherwise
the flow action is set to <code>drop;</code> to implement a default
drop behavior.
</p>
<p>
If the logical datapath has a stateful ACL or a load balancer with VIP
configured, the following flows will also be added:
</p>
<ul>
<li>
If <ref column="options:default_acl_drop" table="NB_Global"
db="OVN_Northbound"/> column of <ref table="NB_Global"
db="OVN_Northbound"/> is <code>false</code> or not set, a priority-1
flow that sets the hint to commit IP traffic that is not part of
established sessions to the connection tracker (with action
<code>reg0[1] = 1; next;</code>). This is needed for
the default allow policy because, while the initiator's direction
may not have any stateful rules, the server's may and then
its return traffic would not be known and marked as invalid.
</li>
<li>
If <ref column="options:default_acl_drop" table="NB_Global"
db="OVN_Northbound"/> column of <ref table="NB_Global"
db="OVN_Northbound"/> is <code>true</code>, a priority-1
flow that drops IP traffic that is not part of established
sessions.
</li>
<li>
A priority-1 flow that sets the hint to commit IP traffic to the
connection tracker (with action <code>reg0[1] = 1; next;</code>). This
is needed for the default allow policy because, while the initiator's
direction may not have any stateful rules, the server's may and then
its return traffic would not be known and marked as invalid.
</li>
<li>
A priority-65532 flow that allows any traffic in the reply
direction for a connection that has been committed to the
connection tracker (i.e., established flows), as long as
the committed flow does not have <code>ct_mark.blocked</code> set.
We only handle traffic in the reply direction here because
we want all packets going in the request direction to still
go through the flows that implement the currently defined
policy based on ACLs. If a connection is no longer allowed by
policy, <code>ct_mark.blocked</code> will get set and packets in the
reply direction will no longer be allowed, either. This flow also
clears the register bits <code>reg0[9]</code> and
<code>reg0[10]</code>. If ACL logging and logging of related packets
is enabled, then a companion priority-65533 flow will be installed that
accomplishes the same thing but also logs the traffic.
</li>
<li>
A priority-65532 flow that allows any traffic that is considered
related to a committed flow in the connection tracker (e.g., an
ICMP Port Unreachable from a non-listening UDP port), as long
as the committed flow does not have <code>ct_mark.blocked</code> set.
This flow also applies NAT to the related traffic so that ICMP headers
and the inner packet have correct addresses.
If ACL logging and logging of related packets is enabled, then a
companion priority-65533 flow will be installed that accomplishes the
same thing but also logs the traffic.
</li>
<li>
A priority-65532 flow that drops all traffic marked by the
connection tracker as invalid.
</li>
<li>
A priority-65532 flow that drops all traffic in the reply direction
with <code>ct_mark.blocked</code> set meaning that the connection
should no longer be allowed due to a policy change. Packets
in the request direction are skipped here to let a newly created
ACL re-allow this connection.
</li>
<li>
A priority-65532 flow that allows IPv6 Neighbor solicitation,
Neighbor discover, Router solicitation, Router advertisement and MLD
packets.
</li>
</ul>
<p>
If the logical datapath has any ACL or a load balancer with VIP
configured, the following flow will also be added:
</p>
<ul>
<li>
A priority 34000 logical flow is added for each logical switch datapath
with the match <code>eth.dst = <var>E</var></code> to allow the service
monitor reply packet destined to <code>ovn-controller</code>
with the action <code>next</code>, where <var>E</var> is the
service monitor mac defined in the
<ref column="options:svc_monitor_mac" table="NB_Global"
db="OVN_Northbound"/> column of <ref table="NB_Global"
db="OVN_Northbound"/> table.
</li>
</ul>
<h3>Ingress Table 9: <code>from-lport</code> QoS Marking</h3>
<p>
Logical flows in this table closely reproduce those in the
<code>QoS</code> table with the <code>action</code> column set in
the <code>OVN_Northbound</code> database for the
<code>from-lport</code> direction.
</p>
<ul>
<li>
For every qos_rules entry in a logical switch with DSCP marking
enabled, a flow will be added at the priority mentioned in the
QoS table.
</li>
<li>
One priority-0 fallback flow that matches all packets and advances to
the next table.
</li>
</ul>
<h3>Ingress Table 10: <code>from-lport</code> QoS Meter</h3>
<p>
Logical flows in this table closely reproduce those in the
<code>QoS</code> table with the <code>bandwidth</code> column set
in the <code>OVN_Northbound</code> database for the
<code>from-lport</code> direction.
</p>
<ul>
<li>
For every qos_rules entry in a logical switch with metering
enabled, a flow will be added at the priority mentioned in the
QoS table.
</li>
<li>
One priority-0 fallback flow that matches all packets and advances to
the next table.
</li>
</ul>
<h3>Ingress Table 11: Load balancing affinity check</h3>
<p>
Load balancing affinity check table contains the following
logical flows:
</p>
<ul>
<li>
For all the configured load balancing rules for a switch in
<code>OVN_Northbound</code> database where a positive affinity timeout
is specified in <code>options</code> column, that includes a L4 port
<var>PORT</var> of protocol <var>P</var> and IP address <var>VIP</var>,
a priority-100 flow is added. For IPv4 <var>VIPs</var>, the flow
matches <code>ct.new && ip && ip4.dst == <var>VIP</var>
&& <var>P</var>.dst == <var>PORT</var></code>. For IPv6
<var>VIPs</var>, the flow matches <code>ct.new && ip &&
ip6.dst == <var>VIP</var>&& <var>P</var> &&
<var>P</var>.dst == <var> PORT</var></code>. The flow's action is
<code>reg9[6] = chk_lb_aff(); next;</code>.
</li>
<li>
A priority 0 flow is added which matches on all packets and applies
the action <code>next;</code>.
</li>
</ul>
<h3>Ingress Table 12: LB</h3>
<ul>
<li>
For all the configured load balancing rules for a switch in
<code>OVN_Northbound</code> database where a positive affinity timeout
is specified in <code>options</code> column, that includes a L4 port
<var>PORT</var> of protocol <var>P</var> and IP address <var>VIP</var>,
a priority-150 flow is added. For IPv4 <var>VIPs</var>, the flow
matches <code>reg9[6] == 1 && ct.new && ip &&
ip4.dst == <var>VIP</var> && <var>P</var>.dst == <var>PORT
</var></code>. For IPv6 <var>VIPs</var>, the flow matches
<code>reg9[6] == 1 && ct.new && ip &&
ip6.dst == <var> VIP </var>&& <var>P</var> &&
<var>P</var>.dst == <var> PORT</var></code>.
The flow's action is <code>ct_lb_mark(<var>args</var>)</code>, where
<var>args</var> contains comma separated IP addresses (and optional
port numbers) to load balance to. The address family of the IP
addresses of <var>args</var> is the same as the address family
of <var>VIP</var>.
</li>
<li>
For all the configured load balancing rules for a switch in
<code>OVN_Northbound</code> database that includes a L4 port
<var>PORT</var> of protocol <var>P</var> and IP address
<var>VIP</var>, a priority-120 flow is added. For IPv4 <var>VIPs
</var>, the flow matches <code>ct.new && ip &&
ip4.dst == <var>VIP</var> &&
<var>P</var>.dst == <var>PORT</var></code>. For IPv6 <var>VIPs</var>,
the flow matches <code>ct.new && ip && ip6.dst == <var>
VIP </var>&& <var>P</var> && <var>P</var>.dst == <var>
PORT</var></code>. The flow's action is <code>ct_lb_mark(<var>args</var>)
</code>, where <var>args</var> contains comma separated IP addresses
(and optional port numbers) to load balance to. The address family of
the IP addresses of <var>args</var> is the same as the address family
of <var>VIP</var>. If health check is enabled, then <var>args</var>
will only contain those endpoints whose service monitor status entry
in <code>OVN_Southbound</code> db is either <code>online</code> or
empty. For IPv4 traffic the flow also loads the original destination
IP and transport port in registers <code>reg1</code> and
<code>reg2</code>. For IPv6 traffic the flow also loads the original
destination IP and transport port in registers <code>xxreg1</code> and
<code>reg2</code>.
The above flow is created even if the load balancer is attached to a
logical router connected to the current logical switch and
the <code>install_ls_lb_from_router</code> variable in
<ref table="NB_Global" column="options"/> is set to true.
</li>
<li>
For all the configured load balancing rules for a switch in
<code>OVN_Northbound</code> database that includes just an IP address
<var>VIP</var> to match on, OVN adds a priority-110 flow. For IPv4
<var>VIPs</var>, the flow matches <code>ct.new && ip &&
ip4.dst == <var>VIP</var></code>. For IPv6 <var>VIPs</var>,
the flow matches <code>ct.new && ip && ip6.dst == <var>
VIP</var></code>. The action on this flow is <code>
ct_lb_mark(<var>args</var>)</code>, where <var>args</var> contains comma
separated IP addresses of the same address family as <var>VIP</var>.
For IPv4 traffic the flow also loads the original destination
IP and transport port in registers <code>reg1</code> and
<code>reg2</code>. For IPv6 traffic the flow also loads the original
destination IP and transport port in registers <code>xxreg1</code> and
<code>reg2</code>.
The above flow is created even if the load balancer is attached to a
logical router connected to the current logical switch and
the <code>install_ls_lb_from_router</code> variable in
<ref table="NB_Global" column="options"/> is set to true.
</li>
<li>
If the load balancer is created with <code>--reject</code> option and
it has no active backends, a TCP reset segment (for tcp) or an ICMP
port unreachable packet (for all other kind of traffic) will be sent
whenever an incoming packet is received for this load-balancer.
Please note using <code>--reject</code> option will disable
empty_lb SB controller event for this load balancer.