forked from ovn-org/ovn
-
Notifications
You must be signed in to change notification settings - Fork 0
/
ovn-nb.xml
2844 lines (2473 loc) · 106 KB
/
ovn-nb.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"?>
<database name="ovn-nb" title="OVN Northbound Database">
<p>
This database is the interface between OVN and the cloud management system
(CMS), such as OpenStack, running above it. The CMS produces almost all of
the contents of the database. The <code>ovn-northd</code> program
monitors the database contents, transforms it, and stores it into the <ref
db="OVN_Southbound"/> database.
</p>
<p>
We generally speak of ``the'' CMS, but one can imagine scenarios in
which multiple CMSes manage different parts of an OVN deployment.
</p>
<h2>External IDs</h2>
<p>
Each of the tables in this database contains a special column, named
<code>external_ids</code>. This column has the same form and purpose each
place it appears.
</p>
<dl>
<dt><code>external_ids</code>: map of string-string pairs</dt>
<dd>
Key-value pairs for use by the CMS. The CMS might use certain pairs, for
example, to identify entities in its own configuration that correspond to
those in this database.
</dd>
</dl>
<table name="NB_Global" title="Northbound configuration">
<p>
Northbound configuration for an OVN system. This table must have exactly
one row.
</p>
<group title="Status">
These columns allow a client to track the overall configuration state of
the system.
<column name="nb_cfg">
Sequence number for client to increment. When a client modifies any
part of the northbound database configuration and wishes to wait for
<code>ovn-northd</code> and possibly all of the hypervisors to finish
applying the changes, it may increment this sequence number.
</column>
<column name="sb_cfg">
Sequence number that <code>ovn-northd</code> sets to the value of <ref
column="nb_cfg"/> after it finishes applying the corresponding
configuration changes to the <ref db="OVN_Southbound"/> database.
</column>
<column name="hv_cfg">
Sequence number that <code>ovn-northd</code> sets to the smallest
sequence number of all the chassis in the system, as reported in the
<code>Chassis</code> table in the southbound database. Thus, <ref
column="hv_cfg"/> equals <ref column="nb_cfg"/> if all chassis are
caught up with the northbound configuration (which may never happen, if
any chassis is down). This value can regress, if a chassis was removed
from the system and rejoins before catching up.
</column>
</group>
<group title="Common Columns">
<column name="external_ids">
See <em>External IDs</em> at the beginning of this document.
</column>
</group>
<group title="Common options">
<column name="options">
This column provides general key/value settings. The supported
options are described individually below.
</column>
<group title="Options for configuring BFD">
<p>
These options apply when <code>ovn-controller</code> configures
BFD on tunnels interfaces.
</p>
<column name="options" key="bfd-min-rx">
BFD option <code>min-rx</code> value to use when configuring BFD on
tunnel interfaces.
</column>
<column name="options" key="bfd-decay-min-rx">
BFD option <code>decay-min-rx</code> value to use when configuring
BFD on tunnel interfaces.
</column>
<column name="options" key="bfd-min-tx">
BFD option <code>min-tx</code> value to use when configuring BFD on
tunnel interfaces.
</column>
<column name="options" key="bfd-mult">
BFD option <code>mult</code> value to use when configuring BFD on
tunnel interfaces.
</column>
</group>
<column name="options" key="mac_prefix">
Configure a given OUI to be used as prefix when L2 address is
dynamically assigned, e.g. <code>00:11:22</code>
</column>
</group>
<group title="Connection Options">
<column name="connections">
Database clients to which the Open vSwitch database server should
connect or on which it should listen, along with options for how these
connections should be configured. See the <ref table="Connection"/>
table for more information.
</column>
<column name="ssl">
Global SSL configuration.
</column>
</group>
<group title="Security Configurations">
<column name="ipsec">
Tunnel encryption configuration. If this column is set to be true, all
OVN tunnels will be encrypted with IPsec.
</column>
</group>
</table>
<table name="Logical_Switch" title="L2 logical switch">
<p>
Each row represents one L2 logical switch.
</p>
<p>
There are two kinds of logical switches, that is, ones that fully
virtualize the network (overlay logical switches) and ones that provide
simple connectivity to a physical network (bridged logical switches).
They work in the same way when providing connectivity between logical
ports on same chasis, but differently when connecting remote logical
ports. Overlay logical switches connect remote logical ports by tunnels,
while bridged logical switches provide connectivity to remote ports by
bridging the packets to directly connected physical L2 segment with the
help of <code>localnet</code> ports. Each bridged logical switch has
one and only one <code>localnet</code> port, which has only one special
address <code>unknown</code>.
</p>
<column name="ports">
<p>
The logical ports connected to the logical switch.
</p>
<p>
It is an error for multiple logical switches to include the same
logical port.
</p>
</column>
<column name="load_balancer">
Load balance a virtual ip address to a set of logical port endpoint
ip addresses.
</column>
<column name="acls">
Access control rules that apply to packets within the logical switch.
</column>
<column name="qos_rules">
QoS marking and metering rules that apply to packets within the
logical switch.
</column>
<column name="dns_records">
This column defines the DNS records to be used for resolving internal
DNS queries within the logical switch by the native DNS resolver.
Please see the <ref table="DNS"/> table.
</column>
<group title="Naming">
<p>
These columns provide names for the logical switch. From OVN's
perspective, these names have no special meaning or purpose other than
to provide convenience for human interaction with the database.
There is no requirement for the name to be unique. (For a unique
identifier for a logical switch, use its row UUID.)
</p>
<p>
(Originally, <ref column="name"/> was intended to serve the purpose of
a human-friendly name, but the Neutron integration used it to uniquely
identify its own switch object, in the format
<code>neutron-<var>uuid</var></code>. Later on, Neutron started
propagating the friendly name of a switch as <ref column="external_ids"
key="neutron:network_name"/>. Perhaps this can be cleaned up someday.)
</p>
<column name="name">
A name for the logical switch.
</column>
<column name="external_ids" key="neutron:network_name">
Another name for the logical switch.
</column>
</group>
<group title="IP Address Assignment">
<p>
These options control automatic IP address management (IPAM) for ports
attached to the logical switch. To enable IPAM for IPv4, set <ref
column="other_config" key="subnet"/> and optionally <ref
column="other_config:exclude_ips"/>. To enable IPAM for IPv6, set
<ref column="other_config" key="ipv6_prefix"/>. IPv4 and IPv6 may
be enabled together or separately.
</p>
<p>
To request dynamic address assignment for a particular port, use the
<code>dynamic</code> keyword in the <ref table="Logical_Switch_Port"
column="addresses"/> column of the port's <ref
table="Logical_Switch_Port"/> row. This requests both an IPv4 and an
IPv6 address, if IPAM for IPv4 and IPv6 are both enabled.
</p>
<column name="other_config" key="subnet">
Set this to an IPv4 subnet, e.g. <code>192.168.0.0/24</code>, to enable
<code>ovn-northd</code> to automatically assign IP addresses within
that subnet.
</column>
<column name="other_config" key="exclude_ips">
<p>
To exclude some addresses from automatic IP address management, set
this to a list of the IPv4 addresses or <code>..</code>-delimited
ranges to exclude. The addresses or ranges should be a subset of
those in <ref column="other_config" key="subnet"/>.
</p>
<p>
Whether listed or not, <code>ovn-northd</code> will never allocate
the first or last address in a subnet, such as 192.168.0.0 or
192.168.0.255 in 192.168.0.0/24.
</p>
<p>
Examples:
</p>
<ul>
<li><code>192.168.0.2 192.168.0.10</code></li>
<li><code>192.168.0.4 192.168.0.30..192.168.0.60 192.168.0.110..192.168.0.120</code></li>
<li><code>192.168.0.110..192.168.0.120 192.168.0.25..192.168.0.30 192.168.0.144</code></li>
</ul>
</column>
<column name="other_config" key="ipv6_prefix">
Set this to an IPv6 prefix to enable <code>ovn-northd</code> to
automatically assign IPv6 addresses using this prefix. The assigned
IPv6 address will be generated using the IPv6 prefix and the MAC
address (converted to an IEEE EUI64 identifier) of the port. The IPv6
prefix defined here should be a valid IPv6 address ending with
<code>::</code>.
<p>
Examples:
</p>
<ul>
<li><code>aef0::</code></li>
<li><code>bef0:1234:a890:5678::</code></li>
<li><code>8230:5678::</code></li>
</ul>
</column>
<column name="other_config" key="mac_only" type='{"type": "boolean"}'>
Value used to request to assign L2 address only if neither subnet
nor ipv6_prefix are specified
</column>
</group>
<group title="Common Columns">
<column name="external_ids">
See <em>External IDs</em> at the beginning of this document.
</column>
</group>
</table>
<table name="Logical_Switch_Port" title="L2 logical switch port">
<p>
A port within an L2 logical switch.
</p>
<group title="Core Features">
<column name="name">
<p>
The logical port name.
</p>
<p>
For entities (VMs or containers) that are spawned in the hypervisor,
the name used here must match those used in the <ref key="iface-id"
table="Interface" column="external_ids" db="Open_vSwitch"/> in the
<ref db="Open_vSwitch"/> database's <ref table="Interface"
db="Open_vSwitch"/> table, because hypervisors use <ref key="iface-id"
table="Interface" column="external_ids" db="Open_vSwitch"/> as a lookup
key to identify the network interface of that entity.
</p>
<p>
For containers that share a VIF within a VM, the name can be any
unique identifier. See <code>Containers</code>, below, for more
information.
</p>
</column>
<column name="type">
<p>
Specify a type for this logical port. Logical ports can be used to
model other types of connectivity into an OVN logical switch. The
following types are defined:
</p>
<dl>
<dt>(empty string)</dt>
<dd>
A VM (or VIF) interface.
</dd>
<dt><code>router</code></dt>
<dd>
A connection to a logical router.
</dd>
<dt><code>localnet</code></dt>
<dd>
A connection to a locally accessible network from each
<code>ovn-controller</code> instance. A logical switch can only
have a single <code>localnet</code> port attached. This is used
to model direct connectivity to an existing network.
</dd>
<dt><code>localport</code></dt>
<dd>
A connection to a local VIF. Traffic that arrives on a
<code>localport</code> is never forwarded over a tunnel to another
chassis. These ports are present on every chassis and have the same
address in all of them. This is used to model connectivity to local
services that run on every hypervisor.
</dd>
<dt><code>l2gateway</code></dt>
<dd>
A connection to a physical network.
</dd>
<dt><code>vtep</code></dt>
<dd>
A port to a logical switch on a VTEP gateway.
</dd>
<dt><code>external</code></dt>
<dd>
<p>
Represents a logical port which is external and not having
an OVS port in the integration bridge.
<code>OVN</code> will never receive any traffic from this port or
send any traffic to this port. <code>OVN</code> can support
native services like DHCPv4/DHCPv6/DNS for this port.
If <ref column="ha_chassis_group"/> is defined,
<code>ovn-controller</code> running in the master chassis of
the HA chassis group will bind this port to provide these native
services. It is expected that this port belong to a bridged
logical switch (with a <code>localnet</code> port).
</p>
<p>
It is recommended to use the same HA chassis group for all the
external ports of a logical switch. Otherwise, the physical
switch might see MAC flap issue when different chassis provide
the native services. For example when supporting native DHCPv4
service, DHCPv4 server mac (configured in
<ref column="options:server_mac" table="DHCP_Options"
db="OVN_NB"/> column in table <ref table="DHCP_Options"/>)
originating from different ports can cause MAC flap issue.
The MAC of the logical router IP(s) can also flap if the
same HA chassis group is not set for all the external ports
of a logical switch.
</p>
<p>
Below are some of the use cases where <code>external</code>
ports can be used.
</p>
<ul>
<li>
VMs connected to SR-IOV nics - Traffic from these VMs by passes
the kernel stack and local <code>ovn-controller</code> do not
bind these ports and cannot serve the native services.
</li>
<li>
When CMS supports provisioning baremetal servers.
</li>
</ul>
</dd>
</dl>
</column>
</group>
<group title="Options">
<column name="options">
This column provides key/value settings specific to the logical port
<ref column="type"/>. The type-specific options are described
individually below.
</column>
<group title="Options for router ports">
<p>
These options apply when <ref column="type"/> is <code>router</code>.
</p>
<column name="options" key="router-port">
Required. The <ref column="name"/> of the <ref
table="Logical_Router_Port"/> to which this logical switch port is
connected.
</column>
<column name="options" key="nat-addresses">
<p>
This is used to send gratuitous ARPs for SNAT and DNAT IP
addresses via the <code>localnet</code> port that is attached
to the same logical switch as this type <code>router</code>
port. This option is specified on a logical switch port that is
connected to a gateway router, or a logical switch port that is
connected to a distributed gateway port on a logical router.
</p>
<p>
This must take one of the following forms:
</p>
<dl>
<dt><code>router</code></dt>
<dd>
<p>
Gratuitous ARPs will be sent for all SNAT and DNAT external IP
addresses and for all load balancer IP addresses defined on the
<ref column="options" key="router-port"/>'s logical router,
using the <ref column="options" key="router-port"/>'s MAC
address.
</p>
<p>
This form of <ref column="options" key="nat-addresses"/> is
valid for logical switch ports where <ref column="options"
key="router-port"/> is the name of a port on a gateway router,
or the name of a distributed gateway port.
</p>
<p>
Supported only in OVN 2.8 and later. Earlier versions required
NAT addresses to be manually synchronized.
</p>
</dd>
<dt><code>Ethernet address followed by one or more IPv4 addresses</code></dt>
<dd>
<p>
Example: <code>80:fa:5b:06:72:b7 158.36.44.22
158.36.44.24</code>. This would result in generation of
gratuitous ARPs for IP addresses 158.36.44.22 and 158.36.44.24
with a MAC address of 80:fa:5b:06:72:b7.
</p>
<p>
This form of <ref column="options" key="nat-addresses"/> is
only valid for logical switch ports where <ref column="options"
key="router-port"/> is the name of a port on a gateway router.
</p>
</dd>
</dl>
</column>
</group>
<group title="Options for localnet ports">
<p>
These options apply when <ref column="type"/> is
<code>localnet</code>.
</p>
<column name="options" key="network_name">
Required. The name of the network to which the <code>localnet</code>
port is connected. Each hypervisor, via <code>ovn-controller</code>,
uses its local configuration to determine exactly how to connect to
this locally accessible network.
</column>
</group>
<group title="Options for l2gateway ports">
<p>
These options apply when <ref column="type"/> is
<code>l2gateway</code>.
</p>
<column name="options" key="network_name">
Required. The name of the network to which the <code>l2gateway</code>
port is connected. The L2 gateway, via <code>ovn-controller</code>,
uses its local configuration to determine exactly how to connect to
this network.
</column>
<column name="options" key="l2gateway-chassis">
Required. The chassis on which the <code>l2gateway</code> logical
port should be bound to. <code>ovn-controller</code> running on the
defined chassis will connect this logical port to the physical network.
</column>
</group>
<group title="Options for vtep ports">
<p>
These options apply when <ref column="type"/> is <code>vtep</code>.
</p>
<column name="options" key="vtep-physical-switch">
Required. The name of the VTEP gateway.
</column>
<column name="options" key="vtep-logical-switch">
Required. A logical switch name connected by the VTEP gateway.
</column>
</group>
<group title="VMI (or VIF) Options">
<p>
These options apply to logical ports with <ref column="type"/> having
(empty string)
</p>
<column name="options" key="requested-chassis">
If set, identifies a specific chassis (by name or hostname) that
is allowed to bind this port. Using this option will prevent
thrashing between two chassis trying to bind the same port during
a live migration. It can also prevent similar thrashing due to a
mis-configuration, if a port is accidentally created on more than
one chassis.
</column>
<column name="options" key="qos_max_rate">
If set, indicates the maximum rate for data sent from this interface,
in bit/s. The traffic will be shaped according to this limit.
</column>
<column name="options" key="qos_burst">
If set, indicates the maximum burst size for data sent from this
interface, in bits.
</column>
</group>
</group>
<group title="Containers">
<p>
When a large number of containers are nested within a VM, it may be too
expensive to dedicate a VIF to each container. OVN can use VLAN tags
to support such cases. Each container is assigned a VLAN ID and each
packet that passes between the hypervisor and the VM is tagged with the
appropriate ID for the container. Such VLAN IDs never appear on a
physical wire, even inside a tunnel, so they need not be unique except
relative to a single VM on a hypervisor.
</p>
<p>
These columns are used for VIFs that represent nested containers using
shared VIFs. For VMs and for containers that have dedicated VIFs, they
are empty.
</p>
<column name="parent_name">
The VM interface through which the nested container sends its network
traffic. This must match the <ref column="name"/> column for some
other <ref table="Logical_Switch_Port"/>.
</column>
<column name="tag_request">
<p>
The VLAN tag in the network traffic associated with a container's
network interface. The client can request <code>ovn-northd</code>
to allocate a tag that is unique within the scope of a specific
parent (specified in <ref column="parent_name"/>) by setting a value
of <code>0</code> in this column. The allocated value is written
by <code>ovn-northd</code> in the <ref column="tag"/> column.
(Note that these tags are allocated and managed locally in
<code>ovn-northd</code>, so they cannot be reconstructed in the event
that the database is lost.) The client can also request a specific
non-zero tag and <code>ovn-northd</code> will honor it and copy that
value to the <ref column="tag"/> column.
</p>
<p>
When <ref column="type"/> is set to <code>localnet</code> or
<code>l2gateway</code>, this can
be set to indicate that the port represents a connection to a
specific VLAN on a locally accessible network. The VLAN ID is used
to match incoming traffic and is also added to outgoing traffic.
</p>
</column>
<column name="tag">
<p>
The VLAN tag allocated by <code>ovn-northd</code> based on the
contents of the <ref column="tag_request"/> column.
</p>
</column>
</group>
<group title="Port State">
<column name="up">
<p>
This column is populated by <code>ovn-northd</code>, rather
than by the CMS plugin as is most of this database. When a
logical port is bound to a physical location in the OVN
Southbound database <ref db="OVN_Southbound"
table="Binding"/> table, <code>ovn-northd</code> sets this
column to <code>true</code>; otherwise, or if the port
becomes unbound later, it sets it to <code>false</code>.
This allows the CMS to wait for a VM's (or container's)
networking to become active before it allows the VM (or
container) to start.
</p>
<p>
Logical ports of router type are an exception to this rule.
They are considered to be always up, that is this column is
always set to <code>true</code>.
</p>
</column>
<column name="enabled">
This column is used to administratively set port state. If this column
is empty or is set to <code>true</code>, the port is enabled. If this
column is set to <code>false</code>, the port is disabled. A disabled
port has all ingress and egress traffic dropped.
</column>
</group>
<group title="Addressing">
<column name="addresses">
<p>
Addresses owned by the logical port.
</p>
<p>
Each element in the set must take one of the following forms:
</p>
<dl>
<dt><code>Ethernet address followed by zero or more IPv4 or IPv6 addresses (or both)</code></dt>
<dd>
<p>
An Ethernet address defined is owned by the logical port.
Like a physical Ethernet NIC, a logical port ordinarily has
a single fixed Ethernet address.
</p>
<p>
When a OVN logical switch processes a unicast Ethernet frame
whose destination MAC address is in a logical port's <ref
column="addresses"/> column, it delivers it only to that port, as
if a MAC learning process had learned that MAC address on the
port.
</p>
<p>
If IPv4 or IPv6 address(es) (or both) are defined, it indicates
that the logical port owns the given IP addresses.
</p>
<p>
If IPv4 address(es) are defined, the OVN logical switch uses this
information to synthesize responses to ARP requests without
traversing the physical network. The OVN logical router connected
to the logical switch, if any, uses this information to avoid
issuing ARP requests for logical switch ports.
</p>
<p>
Note that the order here is important. The Ethernet address must
be listed before the IP address(es) if defined.
</p>
<p>
Examples:
</p>
<dl>
<dt><code>80:fa:5b:06:72:b7</code></dt>
<dd>
This indicates that the logical port owns the above mac address.
</dd>
<dt><code>80:fa:5b:06:72:b7 10.0.0.4 20.0.0.4</code></dt>
<dd>
This indicates that the logical port owns the mac address and two
IPv4 addresses.
</dd>
<dt><code>80:fa:5b:06:72:b7 fdaa:15f2:72cf:0:f816:3eff:fe20:3f41</code></dt>
<dd>
This indicates that the logical port owns the mac address and
1 IPv6 address.
</dd>
<dt><code>80:fa:5b:06:72:b7 10.0.0.4 fdaa:15f2:72cf:0:f816:3eff:fe20:3f41</code></dt>
<dd>
This indicates that the logical port owns the mac address and
1 IPv4 address and 1 IPv6 address.
</dd>
</dl>
</dd>
<dt><code>unknown</code></dt>
<dd>
This indicates that the logical port has an unknown set of Ethernet
addresses. When an OVN logical switch processes a unicast Ethernet
frame whose destination MAC address is not in any logical port's
<ref column="addresses"/> column, it delivers it to the port (or
ports) whose <ref column="addresses"/> columns include
<code>unknown</code>.
</dd>
<dt><code>dynamic</code></dt>
<dd>
Use this keyword to make <code>ovn-northd</code> generate a
globally unique MAC address and choose an unused IPv4 address with
the logical port's subnet and store them in the port's <ref
column="dynamic_addresses"/> column. <code>ovn-northd</code> will
use the subnet specified in <ref table="Logical_Switch"
column="other_config" key="subnet"/> in the port's <ref
table="Logical_Switch"/>.
</dd>
<dt><code>Ethernet address followed by keyword "dynamic"</code></dt>
<dd>
<p>
The keyword <code>dynamic</code> after the MAC address indicates
that <code>ovn-northd</code> should choose an unused IPv4 address
from the logical port's subnet and store it with the specified
MAC in the port's <ref column="dynamic_addresses"/> column.
<code>ovn-northd</code> will use the subnet specified in <ref
table="Logical_Switch" column="other_config" key="subnet"/> in
the port's <ref table="Logical_Switch"/> table.
</p>
<p>
Examples:
</p>
<dl>
<dt><code>80:fa:5b:06:72:b7 dynamic</code></dt>
<dd>
This indicates that the logical port owns the specified
MAC address and <code>ovn-northd</code> should allocate an
unused IPv4 address for the logical port from the corresponding
logical switch subnet.
</dd>
</dl>
</dd>
<dt><code>Keyword "dynamic" followed by an IPv4/IPv6 address</code></dt>
<dd>
<p>
The keyword <code>dynamic</code> followed by an IPv4/IPv6
address indicates that <code>ovn-northd</code> should choose
a dynamic ethernet address and use the provided IPv4/IPv6 address
as network address.
</p>
<p>
Examples:
</p>
<dl>
<dt><code>dynamic 192.168.0.1 2001::1</code></dt>
<dd>
This indicates that <code>ovn-northd</code> should allocate
a unique MAC address and use the provided IPv4/IPv6 address
for the related port
</dd>
</dl>
</dd>
<dt><code>router</code></dt>
<dd>
<p>
Accepted only when <ref column="type"/> is <code>router</code>.
This indicates that the Ethernet, IPv4, and IPv6 addresses for
this logical switch port should be obtained from the connected
logical router port, as specified by <code>router-port</code> in
<ref column="options"/>.
</p>
<p>
The resulting addresses are used to populate the logical
switch's destination lookup, and also for the logical switch
to generate ARP and ND replies.
</p>
<p>
If the connected logical router port has a
<code>redirect-chassis</code> specified and the logical router
has rules specified in <ref column="nat" table="Logical_Router"/>
with <ref column="external_mac" table="NAT"/>, then those
addresses are also used to populate the switch's destination
lookup.
</p>
<p>
Supported only in OVN 2.7 and later. Earlier versions required
router addresses to be manually synchronized.
</p>
</dd>
</dl>
</column>
<column name="dynamic_addresses">
<p>
Addresses assigned to the logical port by <code>ovn-northd</code>, if
<code>dynamic</code> is specified in <ref column="addresses"/>.
Addresses will be of the same format as those that populate the <ref
column="addresses"/> column. Note that dynamically assigned
addresses are constructed and managed locally in ovn-northd, so they
cannot be reconstructed in the event that the database is lost.
</p>
</column>
<column name="port_security">
<p>
This column controls the addresses from which the host attached to the
logical port (``the host'') is allowed to send packets and to which it
is allowed to receive packets. If this column is empty, all addresses
are permitted.
</p>
<p>
Each element in the set must begin with one Ethernet address.
This would restrict the host to sending packets from and receiving
packets to the ethernet addresses defined in the logical port's
<ref column="port_security"/> column. It also restricts the inner
source MAC addresses that the host may send in ARP and IPv6
Neighbor Discovery packets. The host is always allowed to receive packets
to multicast and broadcast Ethernet addresses.
</p>
<p>
Each element in the set may additionally contain one or more IPv4 or
IPv6 addresses (or both), with optional masks. If a mask is given, it
must be a CIDR mask. In addition to the restrictions described for
Ethernet addresses above, such an element restricts the IPv4 or IPv6
addresses from which the host may send and to which it may receive
packets to the specified addresses. A masked address, if the host part
is zero, indicates that the host is allowed to use any address in the
subnet; if the host part is nonzero, the mask simply indicates the size
of the subnet. In addition:
</p>
<ul>
<li>
<p>
If any IPv4 address is given, the host is also allowed to receive
packets to the IPv4 local broadcast address 255.255.255.255 and to
IPv4 multicast addresses (224.0.0.0/4). If an IPv4 address with a
mask is given, the host is also allowed to receive packets to the
broadcast address in that specified subnet.
</p>
<p>
If any IPv4 address is given, the host is additionally restricted
to sending ARP packets with the specified source IPv4 address.
(RARP is not restricted.)
</p>
</li>
<li>
<p>
If any IPv6 address is given, the host is also allowed to receive
packets to IPv6 multicast addresses (ff00::/8).
</p>
<p>
If any IPv6 address is given, the host is additionally restricted
to sending IPv6 Neighbor Discovery Solicitation or Advertisement
packets with the specified source address or, for solicitations,
the unspecified address.
</p>
</li>
</ul>
<p>
If an element includes an IPv4 address, but no IPv6 addresses, then
IPv6 traffic is not allowed. If an element includes an IPv6 address,
but no IPv4 address, then IPv4 and ARP traffic is not allowed.
</p>
<p>
This column uses the same lexical syntax as the <ref column="match"
table="Pipeline" db="OVN_Southbound"/> column in the OVN Southbound
database's <ref table="Pipeline" db="OVN_Southbound"/> table. Multiple
addresses within an element may be space or comma separated.
</p>
<p>
This column is provided as a convenience to cloud management systems,
but all of the features that it implements can be implemented as ACLs
using the <ref table="ACL"/> table.
</p>
<p>
Examples:
</p>
<dl>
<dt><code>80:fa:5b:06:72:b7</code></dt>
<dd>
The host may send traffic from and receive traffic to the specified
MAC address, and to receive traffic to Ethernet multicast and
broadcast addresses, but not otherwise. The host may not send ARP or
IPv6 Neighbor Discovery packets with inner source Ethernet addresses
other than the one specified.
</dd>
<dt><code>80:fa:5b:06:72:b7 192.168.1.10/24</code></dt>
<dd>
This adds further restrictions to the first example. The host may
send IPv4 packets from or receive IPv4 packets to only 192.168.1.10,
except that it may also receive IPv4 packets to 192.168.1.255 (based
on the subnet mask), 255.255.255.255, and any address in 224.0.0.0/4.
The host may not send ARPs with a source Ethernet address other than
80:fa:5b:06:72:b7 or source IPv4 address other than 192.168.1.10.
The host may not send or receive any IPv6 (including IPv6 Neighbor
Discovery) traffic.
</dd>
<dt><code>"80:fa:5b:12:42:ba", "80:fa:5b:06:72:b7 192.168.1.10/24"</code></dt>
<dd>
The host may send traffic from and receive traffic to the
specified MAC addresses, and
to receive traffic to Ethernet multicast and broadcast addresses,
but not otherwise. With MAC 80:fa:5b:12:42:ba, the host may
send traffic from and receive traffic to any L3 address.
With MAC 80:fa:5b:06:72:b7, the host may send IPv4 packets from or
receive IPv4 packets to only 192.168.1.10, except that it may also
receive IPv4 packets to 192.168.1.255 (based on the subnet mask),
255.255.255.255, and any address in 224.0.0.0/4. The host may not
send or receive any IPv6 (including IPv6 Neighbor Discovery) traffic.
</dd>
</dl>
</column>
</group>
<group title="DHCP">
<column name="dhcpv4_options">
This column defines the DHCPv4 Options to be included by the
<code>ovn-controller</code> when it replies to the DHCPv4 requests.
Please see the <ref table="DHCP_Options"/> table.
</column>
<column name="dhcpv6_options">
This column defines the DHCPv6 Options to be included by the
<code>ovn-controller</code> when it replies to the DHCPv6 requests.
Please see the <ref table="DHCP_Options"/> table.
</column>
</group>
<column name="ha_chassis_group">
References a row in the OVN Northbound database's
<ref table="HA_Chassis_Group" db="OVN_Northbound"/> table.
It indicates the HA chassis group to use if the
<ref column="type"/> is set to <code>external</code>.
If <ref column="type"/> is not <code>external</code>, this
column is ignored.
</column>
<group title="Naming">
<column name="external_ids" key="neutron:port_name">
<p>
This column gives an optional human-friendly name for the port. This
name has no special meaning or purpose other than to provide
convenience for human interaction with the northbound database.
</p>
<p>
Neutron copies this from its own port object's name. (Neutron ports
do are not assigned human-friendly names by default, so it will often
be empty.)
</p>
</column>
</group>
<group title="Common Columns">