'\" p .\" -*- nroff -*- .TH "ovn-sb" 5 " DB Schema 20.27.0" "Open vSwitch 22.12.0" "Open vSwitch Manual" .fp 5 L CR \\" Make fixed-width font available as \\fL. .de TQ . br . ns . TP "\\$1" .. .de ST . PP . RS -0.15in . I "\\$1" . RE .. .SH NAME ovn-sb \- OVN_Southbound database schema .PP .PP .PP .PP This database holds logical and physical configuration and state for the Open Virtual Network (OVN) system to support virtual network abstraction\[char46] For an introduction to OVN, please see \fBovn\-architecture\fR(7)\[char46] .PP .PP The OVN Southbound database sits at the center of the OVN architecture\[char46] It is the one component that speaks both southbound directly to all the hypervisors and gateways, via \fBovn\-controller\fR/\fBovn\-controller\-vtep\fR, and northbound to the Cloud Management System, via \fBovn\-northd\fR: .SS "Database Structure" .PP .PP The OVN Southbound database contains classes of data with different properties, as described in the sections below\[char46] .ST "Physical network" .PP .PP Physical network tables contain information about the chassis nodes in the system\[char46] This contains all the information necessary to wire the overlay, such as IP addresses, supported tunnel types, and security keys\[char46] .PP .PP The amount of physical network data is small (O(n) in the number of chassis) and it changes infrequently, so it can be replicated to every chassis\[char46] .PP .PP The \fBChassis\fR and \fBEncap\fR tables are the physical network tables\[char46] .ST "Logical Network" .PP .PP Logical network tables contain the topology of logical switches and routers, ACLs, firewall rules, and everything needed to describe how packets traverse a logical network, represented as logical datapath flows (see Logical Datapath Flows, below)\[char46] .PP .PP Logical network data may be large (O(n) in the number of logical ports, ACL rules, etc\[char46])\[char46] Thus, to improve scaling, each chassis should receive only data related to logical networks in which that chassis participates\[char46] .PP .PP The logical network data is ultimately controlled by the cloud management system (CMS) running northbound of OVN\[char46] That CMS determines the entire OVN logical configuration and therefore the logical network data at any given time is a deterministic function of the CMS\(cqs configuration, although that happens indirectly via the \fBOVN_Northbound\fR database and \fBovn\-northd\fR\[char46] .PP .PP Logical network data is likely to change more quickly than physical network data\[char46] This is especially true in a container environment where containers are created and destroyed (and therefore added to and deleted from logical switches) quickly\[char46] .PP .PP The \fBLogical_Flow\fR, \fBMulticast_Group\fR, \fBAddress_Group\fR, \fBDHCP_Options\fR, \fBDHCPv6_Options\fR, and \fBDNS\fR tables contain logical network data\[char46] .ST "Logical-physical bindings" .PP .PP These tables link logical and physical components\[char46] They show the current placement of logical components (such as VMs and VIFs) onto chassis, and map logical entities to the values that represent them in tunnel encapsulations\[char46] .PP .PP These tables change frequently, at least every time a VM powers up or down or migrates, and especially quickly in a container environment\[char46] The amount of data per VM (or VIF) is small\[char46] .PP .PP Each chassis is authoritative about the VMs and VIFs that it hosts at any given time and can efficiently flood that state to a central location, so the consistency needs are minimal\[char46] .PP .PP The \fBPort_Binding\fR and \fBDatapath_Binding\fR tables contain binding data\[char46] .ST "MAC bindings" .PP .PP The \fBMAC_Binding\fR table tracks the bindings from IP addresses to Ethernet addresses that are dynamically discovered using ARP (for IPv4) and neighbor discovery (for IPv6)\[char46] Usually, IP-to-MAC bindings for virtual machines are statically populated into the \fBPort_Binding\fR table, so \fBMAC_Binding\fR is primarily used to discover bindings on physical networks\[char46] .SS "Common Columns" .PP .PP Some tables contain a special column named \fBexternal_ids\fR\[char46] This column has the same form and purpose each place that it appears, so we describe it here to save space later\[char46] .RS .TP \fBexternal_ids\fR: map of string-string pairs Key-value pairs for use by the software that manages the OVN Southbound database rather than by \fBovn\-controller\fR/\fBovn\-controller\-vtep\fR\[char46] In particular, \fBovn\-northd\fR can use key-value pairs in this column to relate entities in the southbound database to higher-level entities (such as entities in the OVN Northbound database)\[char46] Individual key-value pairs in this column may be documented in some cases to aid in understanding and troubleshooting, but the reader should not mistake such documentation as comprehensive\[char46] .RE .SH "TABLE SUMMARY" .PP The following list summarizes the purpose of each of the tables in the \fBOVN_Southbound\fR database. Each table is described in more detail on a later page. .IP "Table" 1in Purpose .TQ 1in \fBSB_Global\fR Southbound configuration .TQ 1in \fBChassis\fR Physical Network Hypervisor and Gateway Information .TQ 1in \fBChassis_Private\fR Chassis Private .TQ 1in \fBEncap\fR Encapsulation Types .TQ 1in \fBAddress_Set\fR Address Sets .TQ 1in \fBPort_Group\fR Port Groups .TQ 1in \fBLogical_Flow\fR Logical Network Flows .TQ 1in \fBLogical_DP_Group\fR Logical Datapath Groups .TQ 1in \fBMulticast_Group\fR Logical Port Multicast Groups .TQ 1in \fBMirror\fR Mirror Entry .TQ 1in \fBMeter\fR Meter entry .TQ 1in \fBMeter_Band\fR Band for meter entries .TQ 1in \fBDatapath_Binding\fR Physical-Logical Datapath Bindings .TQ 1in \fBPort_Binding\fR Physical-Logical Port Bindings .TQ 1in \fBMAC_Binding\fR IP to MAC bindings .TQ 1in \fBDHCP_Options\fR DHCP Options supported by native OVN DHCP .TQ 1in \fBDHCPv6_Options\fR DHCPv6 Options supported by native OVN DHCPv6 .TQ 1in \fBConnection\fR OVSDB client connections\[char46] .TQ 1in \fBSSL\fR SSL configuration\[char46] .TQ 1in \fBDNS\fR Native DNS resolution .TQ 1in \fBRBAC_Role\fR RBAC_Role configuration\[char46] .TQ 1in \fBRBAC_Permission\fR RBAC_Permission configuration\[char46] .TQ 1in \fBGateway_Chassis\fR Gateway_Chassis configuration\[char46] .TQ 1in \fBHA_Chassis\fR HA_Chassis configuration\[char46] .TQ 1in \fBHA_Chassis_Group\fR HA_Chassis_Group configuration\[char46] .TQ 1in \fBController_Event\fR Controller Event table .TQ 1in \fBIP_Multicast\fR IP_Multicast configuration\[char46] .TQ 1in \fBIGMP_Group\fR IGMP_Group configuration\[char46] .TQ 1in \fBService_Monitor\fR Service_Monitor configuration\[char46] .TQ 1in \fBLoad_Balancer\fR Load_Balancer configuration\[char46] .TQ 1in \fBBFD\fR BFD configuration\[char46] .TQ 1in \fBFDB\fR Port to MAC bindings .TQ 1in \fBStatic_MAC_Binding\fR IP to MAC bindings .TQ 1in \fBChassis_Template_Var\fR Chassis_Template_Var configuration\[char46] .\" check if in troff mode (TTY) .if t \{ .bp .SH "TABLE RELATIONSHIPS" .PP The following diagram shows the relationship among tables in the database. Each node represents a table. Tables that are part of the ``root set'' are shown with double borders. Each edge leads from the table that contains it and points to the table that its value represents. Edges are labeled with their column names, followed by a constraint on the number of allowed values: \fB?\fR for zero or one, \fB*\fR for zero or more, \fB+\fR for one or more. Thick lines represent strong references; thin lines represent weak references. .RS -1in .ps -3 .PS linethick = 1; linethick = 0.500000; box at 0.231174,0.118888 wid 0.235131 height 0.095110 "SB_Global" box at 0.231174,0.118888 wid 0.179575 height 0.039554 linethick = 1.000000; box at 1.130744,0.190220 wid 0.256264 height 0.095110 "Connection" linethick = 1.000000; box at 1.130744,0.047555 wid 0.142665 height 0.095110 "SSL" linethick = 0.500000; box at 3.567957,2.353972 wid 0.187578 height 0.095110 "Chassis" box at 3.567957,2.353972 wid 0.132022 height 0.039554 linethick = 1.000000; box at 4.001278,1.698779 wid 0.161158 height 0.095110 "Encap" linethick = 0.500000; box at 3.038194,2.211308 wid 0.343461 height 0.095110 "Chassis_Private" box at 3.038194,2.211308 wid 0.287906 height 0.039554 linethick = 0.500000; box at 0.231174,2.240411 wid 0.277398 height 0.095110 "Address_Set" box at 0.231174,2.240411 wid 0.221842 height 0.039554 linethick = 0.500000; box at 0.231174,2.668406 wid 0.258908 height 0.095110 "Port_Group" box at 0.231174,2.668406 wid 0.203353 height 0.039554 linethick = 0.500000; box at 0.231174,0.552171 wid 0.287974 height 0.095110 "Logical_Flow" box at 0.231174,0.552171 wid 0.232419 height 0.039554 linethick = 0.500000; box at 1.990652,0.961676 wid 0.383084 height 0.095110 "Datapath_Binding" box at 1.990652,0.961676 wid 0.327529 height 0.039554 linethick = 1.000000; box at 1.130744,0.610283 wid 0.385728 height 0.095110 "Logical_DP_Group" linethick = 0.500000; box at 0.231174,1.955081 wid 0.356662 height 0.095110 "Multicast_Group" box at 0.231174,1.955081 wid 0.301107 height 0.039554 linethick = 0.500000; box at 1.130744,1.955081 wid 0.287974 height 0.095110 "Port_Binding" box at 1.130744,1.955081 wid 0.232419 height 0.039554 linethick = 0.500000; box at 1.990652,1.685558 wid 0.169085 height 0.095110 "Mirror" box at 1.990652,1.685558 wid 0.113529 height 0.039554 linethick = 0.500000; box at 0.231174,2.953736 wid 0.158516 height 0.095110 "Meter" box at 0.231174,2.953736 wid 0.102960 height 0.039554 linethick = 1.000000; box at 1.130744,2.953736 wid 0.274754 height 0.095110 "Meter_Band" linethick = 1.000000; box at 2.523078,2.475523 wid 0.369864 height 0.095110 "Gateway_Chassis" linethick = 0.500000; box at 1.990652,2.076632 wid 0.398929 height 0.095110 "HA_Chassis_Group" box at 1.990652,2.076632 wid 0.343374 height 0.039554 linethick = 0.500000; box at 1.130744,0.332885 wid 0.298531 height 0.095110 "MAC_Binding" box at 1.130744,0.332885 wid 0.242976 height 0.039554 linethick = 0.500000; box at 0.231174,3.096401 wid 0.322309 height 0.095110 "DHCP_Options" box at 0.231174,3.096401 wid 0.266753 height 0.039554 linethick = 0.500000; box at 0.231174,3.239066 wid 0.369864 height 0.095110 "DHCPv6_Options" box at 0.231174,3.239066 wid 0.314308 height 0.039554 linethick = 0.500000; box at 1.130744,1.173030 wid 0.142665 height 0.095110 "DNS" box at 1.130744,1.173030 wid 0.087109 height 0.039554 linethick = 0.500000; box at 0.231174,3.381731 wid 0.253620 height 0.095110 "RBAC_Role" box at 0.231174,3.381731 wid 0.198065 height 0.039554 linethick = 0.500000; box at 1.130744,3.381731 wid 0.377796 height 0.095110 "RBAC_Permission" box at 1.130744,3.381731 wid 0.322240 height 0.039554 linethick = 1.000000; box at 3.038194,2.353972 wid 0.264197 height 0.095110 "HA_Chassis" linethick = 0.500000; box at 3.038194,1.833512 wid 0.364595 height 0.095110 "Controller_Event" box at 3.038194,1.833512 wid 0.309039 height 0.039554 linethick = 0.500000; box at 1.130744,1.030365 wid 0.280042 height 0.095110 "IP_Multicast" box at 1.130744,1.030365 wid 0.224486 height 0.039554 linethick = 0.500000; box at 0.231174,1.812378 wid 0.285330 height 0.095110 "IGMP_Group" box at 0.231174,1.812378 wid 0.229774 height 0.039554 linethick = 0.500000; box at 0.231174,3.524396 wid 0.354018 height 0.095110 "Service_Monitor" box at 0.231174,3.524396 wid 0.298463 height 0.039554 linethick = 0.500000; box at 0.231174,0.739747 wid 0.319684 height 0.095110 "Load_Balancer" box at 0.231174,0.739747 wid 0.264128 height 0.039554 linethick = 0.500000; box at 0.231174,3.667061 wid 0.142665 height 0.095110 "BFD" box at 0.231174,3.667061 wid 0.087109 height 0.039554 linethick = 0.500000; box at 0.231174,3.809726 wid 0.142665 height 0.095110 "FDB" box at 0.231174,3.809726 wid 0.087109 height 0.039554 linethick = 0.500000; box at 1.130744,0.752948 wid 0.427995 height 0.095110 "Static_MAC_Binding" box at 1.130744,0.752948 wid 0.372439 height 0.039554 linethick = 0.500000; box at 0.231174,3.952391 wid 0.462349 height 0.095110 "Chassis_Template_Var" box at 0.231174,3.952391 wid 0.406793 height 0.039554 linethick = 1.000000; spline -> from 0.348902,0.128068 to 0.348902,0.128068 to 0.516847,0.141463 to 0.827952,0.166279 to 1.001946,0.180157 "connections*" at 0.689547,0.191533 linethick = 1.000000; spline -> from 0.349282,0.107244 to 0.349282,0.107244 to 0.398720,0.102413 to 0.457118,0.096909 to 0.509904,0.092468 to 0.708817,0.075727 to 0.944062,0.059666 to 1.058536,0.052088 "ssl?" at 0.689547,0.112283 linethick = 1.000000; spline -> from 3.602006,2.305847 to 3.602006,2.305847 to 3.681137,2.184677 to 3.887907,1.868265 to 3.967038,1.747019 "encaps+" at 3.791275,2.143970 linethick = 0.500000; spline -> from 3.209963,2.247449 to 3.209963,2.247449 to 3.277871,2.263238 to 3.356432,2.282640 to 3.426623,2.303754 to 3.442031,2.308320 to 3.458390,2.313836 to 3.473988,2.319352 "chassis?" at 3.347301,2.323537 linethick = 1.000000; spline -> from 0.375627,0.510379 to 0.375627,0.510379 to 0.663411,0.434767 to 1.324178,0.308974 to 1.743690,0.605014 to 1.857137,0.685077 to 1.934157,0.835675 to 1.968206,0.913056 "logical_datapath?" at 1.130744,0.463661 linethick = 1.000000; spline -> from 0.375513,0.561377 to 0.375513,0.561377 to 0.527214,0.571231 to 0.768736,0.586924 to 0.937138,0.597880 "logical_dp_group?" at 0.689547,0.614258 linethick = 0.500000; spline -> from 1.324007,0.610017 to 1.324007,0.610017 to 1.449572,0.617017 to 1.614093,0.640357 to 1.743690,0.708037 to 1.836897,0.756733 to 1.915135,0.854487 to 1.956413,0.913398 "datapaths*" at 1.568002,0.727858 linethick = 1.000000; spline -> from 0.410457,1.908287 to 0.410457,1.908287 to 0.428433,1.901078 to 0.446066,1.892917 to 0.462349,1.883711 to 0.486963,1.869787 to 0.486221,1.856909 to 0.509904,1.841444 to 0.636210,1.758850 to 1.625278,1.366978 to 1.743690,1.273409 to 1.839732,1.197530 to 1.920271,1.076455 to 1.960598,1.009726 "datapath" at 1.130744,1.668382 linethick = 0.500000; spline -> from 0.410495,1.955081 to 0.410495,1.955081 to 0.579239,1.955081 to 0.830310,1.955081 to 0.986348,1.955081 "ports*" at 0.689547,1.974864 linethick = 0.500000; spline -> from 1.274835,1.936630 to 1.274835,1.936630 to 1.616794,1.896684 to 2.512426,1.821337 to 3.220615,2.018424 to 3.317247,2.045436 to 3.352247,2.043533 to 3.426623,2.110871 to 3.486733,2.165464 to 3.527440,2.252205 to 3.548364,2.306037 "chassis?" at 2.523078,1.953750 linethick = 0.500000; spline -> from 1.134795,2.002636 to 1.134795,2.002636 to 1.141396,2.138453 to 1.178946,2.532018 to 1.392296,2.747538 to 1.523967,2.880692 to 1.606579,2.851968 to 1.791245,2.882404 to 2.204269,2.950122 to 3.180288,3.059879 to 3.426623,2.869088 to 3.501189,2.811261 to 3.544940,2.518513 to 3.559777,2.401908 "additional_chassis*" at 2.523078,2.994633 linethick = 0.500000; spline -> from 1.134206,2.002826 to 1.134206,2.002826 to 1.139323,2.132937 to 1.173505,2.494355 to 1.392296,2.647292 to 1.577628,2.776641 to 3.236213,2.769033 to 3.426623,2.647292 to 3.512032,2.592699 to 3.545891,2.469816 to 3.558446,2.401718 "requested_chassis?" at 2.523078,2.759522 linethick = 0.500000; spline -> from 1.159334,2.003397 to 1.159334,2.003397 to 1.199813,2.074159 to 1.284689,2.205981 to 1.392296,2.279977 to 1.717078,2.503105 to 1.848311,2.486746 to 2.237748,2.546856 to 2.669547,2.613433 to 2.790718,2.599166 to 3.220615,2.520415 to 3.314774,2.503105 to 3.341024,2.500252 to 3.426623,2.457072 to 3.456107,2.442044 to 3.485781,2.420930 to 3.510130,2.401718 "requested_additional_chassis*" at 2.523078,2.608867 linethick = 0.500000; spline -> from 1.275064,1.915135 to 1.275064,1.915135 to 1.312936,1.905624 to 1.353986,1.896018 to 1.392296,1.888999 to 2.036305,1.770815 to 2.202748,1.766383 to 2.855963,1.722556 to 3.255425,1.695735 to 3.734970,1.696420 to 3.920244,1.697904 "encap?" at 3.038194,1.742358 linethick = 0.500000; spline -> from 1.169263,1.906575 to 1.169263,1.906575 to 1.226234,1.831115 to 1.336676,1.690961 to 1.392296,1.661781 to 1.503499,1.603459 to 2.318592,1.564027 to 2.520415,1.564027 to 2.520415,1.564027 to 2.520415,1.564027 to 3.570620,1.564027 to 3.697496,1.564027 to 3.836357,1.618658 to 3.920434,1.658338 "additional_encap*" at 3.038194,1.583848 linethick = 1.000000; spline -> from 1.146190,1.907146 to 1.146190,1.907146 to 1.173886,1.813310 to 1.248775,1.606123 to 1.392296,1.505915 to 1.522255,1.415180 to 1.616280,1.539412 to 1.743690,1.445139 to 1.892632,1.334945 to 1.956983,1.108051 to 1.978859,1.009307 "datapath" at 1.568002,1.525717 linethick = 0.500000; spline -> from 1.171432,1.907336 to 1.171432,1.907336 to 1.217370,1.853618 to 1.300040,1.768932 to 1.392296,1.730469 to 1.563684,1.659061 to 1.786679,1.665547 to 1.905244,1.675914 "mirror_rules*" at 1.568002,1.750290 linethick = 1.000000; spline -> from 1.215677,2.003017 to 1.215677,2.003017 to 1.265762,2.031169 to 1.331578,2.066170 to 1.392296,2.092420 to 1.724611,2.235846 to 2.129703,2.362152 to 2.352831,2.427778 "gateway_chassis*" at 1.568002,2.249542 linethick = 1.000000; spline -> from 1.275159,1.975244 to 1.275159,1.975244 to 1.313203,1.980761 to 1.354328,1.986658 to 1.392296,1.991984 to 1.525203,2.011006 to 1.674792,2.032120 to 1.790826,2.048669 "ha_chassis_group?" at 1.568002,2.061985 linethick = 1.000000; spline -> from 0.310839,2.953736 to 0.310839,2.953736 to 0.462729,2.953736 to 0.802595,2.953736 to 0.992739,2.953736 "bands+" at 0.689547,2.973519 linethick = 0.500000; spline -> from 2.708352,2.476474 to 2.708352,2.476474 to 2.892105,2.474001 to 3.182190,2.460115 to 3.426623,2.404191 to 3.442031,2.400576 to 3.458200,2.395821 to 3.473798,2.390685 "chassis?" at 3.038194,2.489980 linethick = 0.500000; spline -> from 2.190764,2.044675 to 2.190764,2.044675 to 2.438620,2.012718 to 2.873273,1.983234 to 3.220615,2.100409 to 3.343687,2.141877 to 3.459531,2.245167 to 3.520592,2.306417 "ref_chassis*" at 3.038194,2.120192 linethick = 1.000000; spline -> from 2.172503,2.124187 to 2.172503,2.124187 to 2.381174,2.179731 to 2.720717,2.270085 to 2.905610,2.319352 "ha_chassis*" at 2.523078,2.307749 linethick = 1.000000; spline -> from 1.281303,0.309887 to 1.281303,0.309887 to 1.414970,0.297466 to 1.610650,0.301023 to 1.743690,0.398929 to 1.916466,0.526149 to 1.968777,0.801739 to 1.983044,0.913303 "datapath" at 1.568002,0.418750 linethick = 1.000000; spline -> from 1.202152,1.164717 to 1.202152,1.164717 to 1.316227,1.149918 to 1.551168,1.115260 to 1.743690,1.059411 to 1.789761,1.046058 to 1.839161,1.027207 to 1.881390,1.009631 "datapaths+" at 1.568002,1.155853 linethick = 0.500000; spline -> from 0.358165,3.381731 to 0.358165,3.381731 to 0.509580,3.381731 to 0.766758,3.381731 to 0.941836,3.381731 "permissions value*" at 0.689547,3.401514 linethick = 0.500000; spline -> from 3.170587,2.353972 to 3.170587,2.353972 to 3.264556,2.353972 to 3.389340,2.353972 to 3.473417,2.353972 "chassis?" at 3.347301,2.373755 linethick = 0.500000; spline -> from 3.220805,1.814014 to 3.220805,1.814014 to 3.292138,1.815821 to 3.370508,1.831001 to 3.426623,1.878423 to 3.555402,1.987228 to 3.568337,2.208264 to 3.567196,2.305847 "chassis?" at 3.347301,1.898243 linethick = 0.500000; spline -> from 1.271659,1.019237 to 1.271659,1.019237 to 1.414818,1.007748 to 1.639430,0.989696 to 1.798968,0.976875 "datapath" at 1.568002,1.029033 linethick = 0.500000; spline -> from 0.374848,1.835014 to 0.374848,1.835014 to 0.406576,1.845572 to 0.438020,1.861036 to 0.462349,1.883711 to 0.504768,1.923314 to 0.481713,1.954511 to 0.509904,2.005299 to 0.732899,2.406283 to 0.669232,2.832186 to 1.128119,2.832186 to 1.128119,2.832186 to 1.128119,2.832186 to 3.040857,2.832186 to 3.221376,2.832186 to 3.295371,2.829142 to 3.426623,2.705309 to 3.514315,2.622563 to 3.547603,2.477235 to 3.559397,2.402098 "chassis?" at 1.990652,2.851968 linethick = 0.500000; spline -> from 0.252327,1.764500 to 0.252327,1.764500 to 0.288050,1.678920 to 0.375133,1.500531 to 0.509904,1.413449 to 0.978168,1.110790 to 1.244724,1.435077 to 1.743690,1.186231 to 1.829270,1.143546 to 1.906575,1.061789 to 1.950516,1.009593 "datapath?" at 1.130744,1.309075 linethick = 0.500000; spline -> from 0.374182,1.830868 to 0.374182,1.830868 to 0.503132,1.848330 to 0.699401,1.876045 to 0.869191,1.904863 to 0.907349,1.911331 to 0.948513,1.918939 to 0.986557,1.926358 "ports*" at 0.689547,1.924646 linethick = 1.000000; spline -> from 0.391035,0.759625 to 0.391035,0.759625 to 0.713972,0.800484 to 1.450827,0.893711 to 1.799082,0.937766 "datapaths*" at 1.130744,0.902232 linethick = 1.000000; spline -> from 0.391644,0.716901 to 0.391644,0.716901 to 0.544067,0.694836 to 0.775127,0.661395 to 0.937709,0.637846 "datapath_group?" at 0.689547,0.719926 linethick = 1.000000; spline -> from 1.344893,0.754146 to 1.344893,0.754146 to 1.464523,0.760157 to 1.615386,0.776763 to 1.743690,0.819011 to 1.809011,0.840506 to 1.875969,0.881156 to 1.923314,0.913589 "datapath" at 1.568002,0.838813 .ps +3 .PE .RE\} .bp .SH "SB_Global TABLE" .PP .PP .PP Southbound configuration for an OVN system\[char46] This table must have exactly one row\[char46] .SS "Summary: .TQ .25in \fIStatus:\fR .RS .25in .TQ 2.75in \fBnb_cfg\fR integer .RE .TQ .25in \fICommon Columns:\fR .RS .25in .TQ 2.75in \fBexternal_ids\fR map of string-string pairs .TQ 2.75in \fBoptions\fR map of string-string pairs .RE .TQ .25in \fICommon options:\fR .RS .25in .TQ 2.75in \fBoptions\fR map of string-string pairs .TQ .25in \fIOptions for configuring BFD:\fR .RS .25in .TQ 2.50in \fBoptions : bfd-min-rx\fR optional string .TQ 2.50in \fBoptions : bfd-decay-min-rx\fR optional string .TQ 2.50in \fBoptions : bfd-min-tx\fR optional string .TQ 2.50in \fBoptions : bfd-mult\fR optional string .TQ 2.50in \fBoptions : debug_drop_domain_id\fR optional string .TQ 2.50in \fBoptions : debug_drop_collector_set\fR optional string .RE .TQ .25in \fIOptions for configuring Load Balancers:\fR .RS .25in .TQ 2.50in \fBoptions : lb_hairpin_use_ct_mark\fR optional string .RE .RE .TQ .25in \fIConnection Options:\fR .RS .25in .TQ 2.75in \fBconnections\fR set of \fBConnection\fRs .TQ 2.75in \fBssl\fR optional \fBSSL\fR .RE .TQ .25in \fISecurity Configurations:\fR .RS .25in .TQ 2.75in \fBipsec\fR boolean .RE .SS "Details: .ST "Status:" .PP This column allow a client to track the overall configuration state of the system\[char46] .IP "\fBnb_cfg\fR: integer" Sequence number for the configuration\[char46] When a CMS or \fBovn\-nbctl\fR updates the northbound database, it increments the \fBnb_cfg\fR column in the \fBNB_Global\fR table in the northbound database\[char46] In turn, when \fBovn\-northd\fR updates the southbound database to bring it up to date with these changes, it updates this column to the same value\[char46] .ST "Common Columns:" .PP .IP "\fBexternal_ids\fR: map of string-string pairs" See \fBExternal IDs\fR at the beginning of this document\[char46] .IP "\fBoptions\fR: map of string-string pairs" .ST "Common options:" .PP .IP "\fBoptions\fR: map of string-string pairs" This column provides general key/value settings\[char46] The supported options are described individually below\[char46] .ST "Options for configuring BFD:" .PP .PP .PP These options apply when \fBovn\-controller\fR configures BFD on tunnels interfaces\[char46] .IP "\fBoptions : bfd-min-rx\fR: optional string" BFD option \fBmin\-rx\fR value to use when configuring BFD on tunnel interfaces\[char46] .IP "\fBoptions : bfd-decay-min-rx\fR: optional string" BFD option \fBdecay\-min\-rx\fR value to use when configuring BFD on tunnel interfaces\[char46] .IP "\fBoptions : bfd-min-tx\fR: optional string" BFD option \fBmin\-tx\fR value to use when configuring BFD on tunnel interfaces\[char46] .IP "\fBoptions : bfd-mult\fR: optional string" BFD option \fBmult\fR value to use when configuring BFD on tunnel interfaces\[char46] .IP "\fBoptions : debug_drop_domain_id\fR: optional string" If set to a 8-bit number and if \fBdebug_drop_collector_set\fR is also configured, \fBovn\-controller\fR will add a \fBsample\fR action to every flow that does not come from a logical flow that contains a \(cqdrop\(cq action\[char46] The 8 most significant bits of the observation_domain_id field will be those specified in the \fB debug_drop_domain_id\fR\[char46] The 24 least significant bits of the observation_domain_id field will be zero\[char46] .IP The observation_point_id will be set to the OpenFlow table number\[char46] .IP "\fBoptions : debug_drop_collector_set\fR: optional string" If set to a 32-bit number \fBovn\-controller\fR will add a \fBsample\fR action to every flow that does not come from a logical flow that contains a \(cqdrop\(cq action\[char46] The sample action will have the specified collector_set_id\[char46] The value must match that of the local OVS configuration as described in \fBovs\-actions\fR(7)\[char46] .ST "Options for configuring Load Balancers:" .PP .PP .PP These options apply when \fBovn\-controller\fR configures load balancer related flows\[char46] .IP "\fBoptions : lb_hairpin_use_ct_mark\fR: optional string" By default this option is turned on (even if not present in the database) unless its value is explicitly set to \fBfalse\fR\[char46] This value is automatically set to \fBfalse\fR by \fBovn\-northd\fR when action \fBct_lb_mark\fR cannot be used for new load balancer sessions and action \fBct_lb\fR will be used instead\[char46] \fBovn\-controller\fR then knows that it should check \fBct_label\[char46]natted\fR to detect load balanced traffic\[char46] .ST "Connection Options:" .PP .IP "\fBconnections\fR: set of \fBConnection\fRs" 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\[char46] See the \fBConnection\fR table for more information\[char46] .IP "\fBssl\fR: optional \fBSSL\fR" Global SSL configuration\[char46] .ST "Security Configurations:" .PP .IP "\fBipsec\fR: boolean" Tunnel encryption configuration\[char46] If this column is set to be true, all OVN tunnels will be encrypted with IPsec\[char46] .bp .SH "Chassis TABLE" .PP .PP .PP Each row in this table represents a hypervisor or gateway (a chassis) in the physical network\[char46] Each chassis, via \fBovn\-controller\fR/\fBovn\-controller\-vtep\fR, adds and updates its own row, and keeps a copy of the remaining rows to determine how to reach other hypervisors\[char46] .PP .PP When a chassis shuts down gracefully, it should remove its own row\[char46] (This is not critical because resources hosted on the chassis are equally unreachable regardless of whether the row is present\[char46]) If a chassis shuts down permanently without removing its row, some kind of manual or automatic cleanup is eventually needed; we can devise a process for that as necessary\[char46] .SS "Summary: .TQ 3.00in \fBname\fR string (must be unique within table) .TQ 3.00in \fBhostname\fR string .TQ 3.00in \fBnb_cfg\fR integer .TQ 3.00in \fBother_config : ovn-bridge-mappings\fR optional string .TQ 3.00in \fBother_config : datapath-type\fR optional string .TQ 3.00in \fBother_config : iface-types\fR optional string .TQ 3.00in \fBother_config : ovn-cms-options\fR optional string .TQ 3.00in \fBother_config : is-interconn\fR optional string .TQ 3.00in \fBother_config : is-remote\fR optional string .TQ 3.00in \fBtransport_zones\fR set of strings .TQ 3.00in \fBother_config : ovn-chassis-mac-mappings\fR optional string .TQ 3.00in \fBother_config : port-up-notif\fR optional string .TQ .25in \fICommon Columns:\fR .RS .25in .TQ 2.75in \fBexternal_ids\fR map of string-string pairs .RE .TQ .25in \fIEncapsulation Configuration:\fR .RS .25in .TQ 2.75in \fBencaps\fR set of 1 or more \fBEncap\fRs .RE .TQ .25in \fIGateway Configuration:\fR .RS .25in .TQ 2.75in \fBvtep_logical_switches\fR set of strings .RE .SS "Details: .IP "\fBname\fR: string (must be unique within table)" OVN does not prescribe a particular format for chassis names\[char46] ovn-controller populates this column using \fBexternal_ids:system-id\fR in the Open_vSwitch database\(cqs \fBOpen_vSwitch\fR table\[char46] ovn-controller-vtep populates this column with \fBname\fR in the hardware_vtep database\(cqs \fBPhysical_Switch\fR table\[char46] .IP "\fBhostname\fR: string" The hostname of the chassis, if applicable\[char46] ovn-controller will populate this column with the hostname of the host it is running on\[char46] ovn-controller-vtep will leave this column empty\[char46] .IP "\fBnb_cfg\fR: integer" Deprecated\[char46] This column is replaced by the \fBnb_cfg\fR column of the \fBChassis_Private\fR table\[char46] .IP "\fBother_config : ovn-bridge-mappings\fR: optional string" \fBovn\-controller\fR populates this key with the set of bridge mappings it has been configured to use\[char46] Other applications should treat this key as read-only\[char46] See \fBovn\-controller\fR(8) for more information\[char46] .IP "\fBother_config : datapath-type\fR: optional string" \fBovn\-controller\fR populates this key with the datapath type configured in the \fBdatapath_type\fR column of the Open_vSwitch database\(cqs \fBBridge\fR table\[char46] Other applications should treat this key as read-only\[char46] See \fBovn\-controller\fR(8) for more information\[char46] .IP "\fBother_config : iface-types\fR: optional string" \fBovn\-controller\fR populates this key with the interface types configured in the \fBiface_types\fR column of the Open_vSwitch database\(cqs \fBOpen_vSwitch\fR table\[char46] Other applications should treat this key as read-only\[char46] See \fBovn\-controller\fR(8) for more information\[char46] .IP "\fBother_config : ovn-cms-options\fR: optional string" \fBovn\-controller\fR populates this key with the set of options configured in the \fBexternal_ids:ovn-cms-options\fR column of the Open_vSwitch database\(cqs \fBOpen_vSwitch\fR table\[char46] See \fBovn\-controller\fR(8) for more information\[char46] .IP "\fBother_config : is-interconn\fR: optional string" \fBovn\-controller\fR populates this key with the setting configured in the \fBexternal_ids:ovn-is-interconn\fR column of the Open_vSwitch database\(cqs \fBOpen_vSwitch\fR table\[char46] If set to true, the chassis is used as an interconnection gateway\[char46] See \fBovn\-controller\fR(8) for more information\[char46] .IP "\fBother_config : is-remote\fR: optional string" \fBovn\-ic\fR set this key to true for remote interconnection gateway chassises learned from the interconnection southbound database\[char46] See \fBovn\-ic\fR(8) for more information\[char46] .IP "\fBtransport_zones\fR: set of strings" \fBovn\-controller\fR populates this key with the transport zones configured in the \fBexternal_ids:ovn-transport-zones\fR column of the Open_vSwitch database\(cqs \fBOpen_vSwitch\fR table\[char46] See \fBovn\-controller\fR(8) for more information\[char46] .IP "\fBother_config : ovn-chassis-mac-mappings\fR: optional string" \fBovn\-controller\fR populates this key with the set of options configured in the \fBexternal_ids:ovn-chassis-mac-mappings\fR column of the Open_vSwitch database\(cqs \fBOpen_vSwitch\fR table\[char46] See \fBovn\-controller\fR(8) for more information\[char46] .IP "\fBother_config : port-up-notif\fR: optional string" \fBovn\-controller\fR populates this key with \fBtrue\fR when it supports \fBPort_Binding\[char46]up\fR\[char46] .ST "Common Columns:" .PP The overall purpose of these columns is described under \fBCommon Columns\fR at the beginning of this document\[char46] .IP "\fBexternal_ids\fR: map of string-string pairs" .ST "Encapsulation Configuration:" .PP .PP .PP OVN uses encapsulation to transmit logical dataplane packets between chassis\[char46] .IP "\fBencaps\fR: set of 1 or more \fBEncap\fRs" Points to supported encapsulation configurations to transmit logical dataplane packets to this chassis\[char46] Each entry is a \fBEncap\fR record that describes the configuration\[char46] .ST "Gateway Configuration:" .PP .PP .PP A \fIgateway\fR is a chassis that forwards traffic between the OVN-managed part of a logical network and a physical VLAN, extending a tunnel-based logical network into a physical network\[char46] Gateways are typically dedicated nodes that do not host VMs and will be controlled by \fBovn\-controller\-vtep\fR\[char46] .IP "\fBvtep_logical_switches\fR: set of strings" Stores all VTEP logical switch names connected by this gateway chassis\[char46] The \fBPort_Binding\fR table entry with \fBoptions\fR:\fBvtep\-physical\-switch\fR equal \fBChassis\fR \fBname\fR, and \fBoptions\fR:\fBvtep\-logical\-switch\fR value in \fBChassis\fR \fBvtep_logical_switches\fR, will be associated with this \fBChassis\fR\[char46] .bp .SH "Chassis_Private TABLE" .PP .PP .PP Each row in this table maintains per chassis private data that are accessed only by the owning chassis (write only) and ovn-northd, not by any other chassis\[char46] These data are stored in this separate table instead of the \fBChassis\fR table for performance considerations: the rows in this table can be conditionally monitored by chassises so that each chassis only get update notifications for its own row, to avoid unnecessary chassis private data update flooding in a large scale deployment\[char46] .SS "Summary: .TQ 3.00in \fBname\fR string (must be unique within table) .TQ 3.00in \fBchassis\fR optional weak reference to \fBChassis\fR .TQ 3.00in \fBnb_cfg\fR integer .TQ 3.00in \fBnb_cfg_timestamp\fR integer .TQ .25in \fICommon Columns:\fR .RS .25in .TQ 2.75in \fBexternal_ids\fR map of string-string pairs .RE .SS "Details: .IP "\fBname\fR: string (must be unique within table)" The name of the chassis that owns these chassis-private data\[char46] .IP "\fBchassis\fR: optional weak reference to \fBChassis\fR" The reference to \fBChassis\fR table for the chassis that owns these chassis-private data\[char46] .IP "\fBnb_cfg\fR: integer" Sequence number for the configuration\[char46] When \fBovn\-controller\fR updates the configuration of a chassis from the contents of the southbound database, it copies \fBnb_cfg\fR from the \fBSB_Global\fR table into this column\[char46] .IP "\fBnb_cfg_timestamp\fR: integer" The timestamp when \fBovn\-controller\fR finishes processing the change corresponding to \fBnb_cfg\fR\[char46] .ST "Common Columns:" .PP The overall purpose of these columns is described under \fBCommon Columns\fR at the beginning of this document\[char46] .IP "\fBexternal_ids\fR: map of string-string pairs" .bp .SH "Encap TABLE" .PP .PP .PP The \fBencaps\fR column in the \fBChassis\fR table refers to rows in this table to identify how OVN may transmit logical dataplane packets to this chassis\[char46] Each chassis, via \fBovn\-controller\fR(8) or \fBovn\-controller\-vtep\fR(8), adds and updates its own rows and keeps a copy of the remaining rows to determine how to reach other chassis\[char46] .SS "Summary: .TQ 3.00in \fBtype\fR string, one of \fBgeneve\fR, \fBstt\fR, or \fBvxlan\fR .TQ 3.00in \fBoptions\fR map of string-string pairs .TQ 3.00in \fBoptions : csum\fR optional string, either \fBtrue\fR or \fBfalse\fR .TQ 3.00in \fBoptions : dst_port\fR optional string, containing an integer .TQ 3.00in \fBip\fR string .TQ 3.00in \fBchassis_name\fR string .SS "Details: .IP "\fBtype\fR: string, one of \fBgeneve\fR, \fBstt\fR, or \fBvxlan\fR" The encapsulation to use to transmit packets to this chassis\[char46] Hypervisors must use either \fBgeneve\fR or \fBstt\fR\[char46] Gateways may use \fBvxlan\fR, \fBgeneve\fR, or \fBstt\fR\[char46] .IP "\fBoptions\fR: map of string-string pairs" Options for configuring the encapsulation, which may be \fBtype\fR specific\[char46] .IP "\fBoptions : csum\fR: optional string, either \fBtrue\fR or \fBfalse\fR" \fBcsum\fR indicates whether this chassis can transmit and receive packets that include checksums with reasonable performance\[char46] It hints to senders transmitting data to this chassis that they should use checksums to protect OVN metadata\[char46] \fBovn\-controller\fR populates this key with the value defined in \fBexternal_ids:ovn-encap-csum\fR column of the Open_vSwitch database\(cqs \fBOpen_vSwitch\fR table\[char46] Other applications should treat this key as read-only\[char46] See \fBovn\-controller\fR(8) for more information\[char46] .IP In terms of performance, checksumming actually significantly increases throughput in most common cases when running on Linux based hosts without NICs supporting encapsulation hardware offload (around 60% for bulk traffic)\[char46] The reason is that generally all NICs are capable of offloading transmitted and received TCP/UDP checksums (viewed as ordinary data packets and not as tunnels)\[char46] The benefit comes on the receive side where the validated outer checksum can be used to additionally validate an inner checksum (such as TCP), which in turn allows aggregation of packets to be more efficiently handled by the rest of the stack\[char46] .IP Not all devices see such a benefit\[char46] The most notable exception is hardware VTEPs\[char46] These devices are designed to not buffer entire packets in their switching engines and are therefore unable to efficiently compute or validate full packet checksums\[char46] In addition certain versions of the Linux kernel are not able to fully take advantage of encapsulation NIC offloads in the presence of checksums\[char46] (This is actually a pretty narrow corner case though: earlier versions of Linux don\(cqt support encapsulation offloads at all and later versions support both offloads and checksums well\[char46]) .IP \fBcsum\fR defaults to \fBfalse\fR for hardware VTEPs and \fBtrue\fR for all other cases\[char46] .IP This option applies to \fBgeneve\fR and \fBvxlan\fR encapsulations\[char46] .IP "\fBoptions : dst_port\fR: optional string, containing an integer" If set, overrides the UDP (for \fBgeneve\fR and \fBvxlan\fR) or TCP (for \fBstt\fR) destination port\[char46] .IP "\fBip\fR: string" The IPv4 address of the encapsulation tunnel endpoint\[char46] .IP "\fBchassis_name\fR: string" The name of the chassis that created this encap\[char46] .bp .SH "Address_Set TABLE" .PP .PP .PP This table contains address sets synced from the \fBAddress_Set\fR table in the \fBOVN_Northbound\fR database and address sets generated from the \fBPort_Group\fR table in the \fBOVN_Northbound\fR database\[char46] .PP .PP See the documentation for the \fBAddress_Set\fR table and \fBPort_Group\fR table in the \fBOVN_Northbound\fR database for details\[char46] .SS "Summary: .TQ 3.00in \fBname\fR string (must be unique within table) .TQ 3.00in \fBaddresses\fR set of strings .SS "Details: .IP "\fBname\fR: string (must be unique within table)" .IP "\fBaddresses\fR: set of strings" .bp .SH "Port_Group TABLE" .PP .PP .PP This table contains names for the logical switch ports in the \fBOVN_Northbound\fR database that belongs to the same group that is defined in \fBPort_Group\fR in the \fBOVN_Northbound\fR database\[char46] .SS "Summary: .TQ 3.00in \fBname\fR string (must be unique within table) .TQ 3.00in \fBports\fR set of strings .SS "Details: .IP "\fBname\fR: string (must be unique within table)" .IP "\fBports\fR: set of strings" .bp .SH "Logical_Flow TABLE" .PP .PP .PP Each row in this table represents one logical flow\[char46] \fBovn\-northd\fR populates this table with logical flows that implement the L2 and L3 topologies specified in the \fBOVN_Northbound\fR database\[char46] Each hypervisor, via \fBovn\-controller\fR, translates the logical flows into OpenFlow flows specific to its hypervisor and installs them into Open vSwitch\[char46] .PP .PP Logical flows are expressed in an OVN-specific format, described here\[char46] A logical datapath flow is much like an OpenFlow flow, except that the flows are written in terms of logical ports and logical datapaths instead of physical ports and physical datapaths\[char46] Translation between logical and physical flows helps to ensure isolation between logical datapaths\[char46] (The logical flow abstraction also allows the OVN centralized components to do less work, since they do not have to separately compute and push out physical flows to each chassis\[char46]) .PP .PP The default action when no flow matches is to drop packets\[char46] .PP \fBArchitectural Logical Life Cycle of a Packet\fR .PP .PP This following description focuses on the life cycle of a packet through a logical datapath, ignoring physical details of the implementation\[char46] Please refer to \fBArchitectural Physical Life Cycle of a Packet\fR in \fBovn\-architecture\fR(7) for the physical information\[char46] .PP .PP The description here is written as if OVN itself executes these steps, but in fact OVN (that is, \fBovn\-controller\fR) programs Open vSwitch, via OpenFlow and OVSDB, to execute them on its behalf\[char46] .PP .PP At a high level, OVN passes each packet through the logical datapath\(cqs logical ingress pipeline, which may output the packet to one or more logical port or logical multicast groups\[char46] For each such logical output port, OVN passes the packet through the datapath\(cqs logical egress pipeline, which may either drop the packet or deliver it to the destination\[char46] Between the two pipelines, outputs to logical multicast groups are expanded into logical ports, so that the egress pipeline only processes a single logical output port at a time\[char46] Between the two pipelines is also where, when necessary, OVN encapsulates a packet in a tunnel (or tunnels) to transmit to remote hypervisors\[char46] .PP .PP In more detail, to start, OVN searches the \fBLogical_Flow\fR table for a row with correct \fBlogical_datapath\fR or a \fBlogical_dp_group\fR, a \fBpipeline\fR of \fBingress\fR, a \fBtable_id\fR of 0, and a \fBmatch\fR that is true for the packet\[char46] If none is found, OVN drops the packet\[char46] If OVN finds more than one, it chooses the match with the highest \fBpriority\fR\[char46] Then OVN executes each of the actions specified in the row\(cqs \fBactions\fR column, in the order specified\[char46] Some actions, such as those to modify packet headers, require no further details\[char46] The \fBnext\fR and \fBoutput\fR actions are special\[char46] .PP .PP The \fBnext\fR action causes the above process to be repeated recursively, except that OVN searches for \fBtable_id\fR of 1 instead of 0\[char46] Similarly, any \fBnext\fR action in a row found in that table would cause a further search for a \fBtable_id\fR of 2, and so on\[char46] When recursive processing completes, flow control returns to the action following \fBnext\fR\[char46] .PP .PP The \fBoutput\fR action also introduces recursion\[char46] Its effect depends on the current value of the \fBoutport\fR field\[char46] Suppose \fBoutport\fR designates a logical port\[char46] First, OVN compares \fBinport\fR to \fBoutport\fR; if they are equal, it treats the \fBoutput\fR as a no-op by default\[char46] In the common case, where they are different, the packet enters the egress pipeline\[char46] This transition to the egress pipeline discards register data, e\[char46]g\[char46] \fBreg0\fR \[char46]\[char46]\[char46] \fBreg9\fR and connection tracking state, to achieve uniform behavior regardless of whether the egress pipeline is on a different hypervisor (because registers aren\(cqt preserve across tunnel encapsulation)\[char46] .PP .PP To execute the egress pipeline, OVN again searches the \fBLogical_Flow\fR table for a row with correct \fBlogical_datapath\fR or a \fBlogical_dp_group\fR, a \fBtable_id\fR of 0, a \fBmatch\fR that is true for the packet, but now looking for a \fBpipeline\fR of \fBegress\fR\[char46] If no matching row is found, the output becomes a no-op\[char46] Otherwise, OVN executes the actions for the matching flow (which is chosen from multiple, if necessary, as already described)\[char46] .PP .PP In the \fBegress\fR pipeline, the \fBnext\fR action acts as already described, except that it, of course, searches for \fBegress\fR flows\[char46] The \fBoutput\fR action, however, now directly outputs the packet to the output port (which is now fixed, because \fBoutport\fR is read-only within the egress pipeline)\[char46] .PP .PP The description earlier assumed that \fBoutport\fR referred to a logical port\[char46] If it instead designates a logical multicast group, then the description above still applies, with the addition of fan-out from the logical multicast group to each logical port in the group\[char46] For each member of the group, OVN executes the logical pipeline as described, with the logical output port replaced by the group member\[char46] .PP \fBPipeline Stages\fR .PP .PP \fBovn\-northd\fR populates the \fBLogical_Flow\fR table with the logical flows described in detail in \fBovn\-northd\fR(8)\[char46] .SS "Summary: .TQ 3.00in \fBlogical_datapath\fR optional \fBDatapath_Binding\fR .TQ 3.00in \fBlogical_dp_group\fR optional \fBLogical_DP_Group\fR .TQ 3.00in \fBpipeline\fR string, either \fBegress\fR or \fBingress\fR .TQ 3.00in \fBtable_id\fR integer, in range 0 to 32 .TQ 3.00in \fBpriority\fR integer, in range 0 to 65,535 .TQ 3.00in \fBmatch\fR string .TQ 3.00in \fBactions\fR string .TQ 3.00in \fBtags\fR map of string-string pairs .TQ 3.00in \fBcontroller_meter\fR optional string .TQ 3.00in \fBexternal_ids : stage-name\fR optional string .TQ 3.00in \fBexternal_ids : stage-hint\fR optional string, containing an uuid .TQ 3.00in \fBexternal_ids : source\fR optional string .TQ .25in \fICommon Columns:\fR .RS .25in .TQ 2.75in \fBexternal_ids\fR map of string-string pairs .RE .SS "Details: .IP "\fBlogical_datapath\fR: optional \fBDatapath_Binding\fR" The logical datapath to which the logical flow belongs\[char46] .IP "\fBlogical_dp_group\fR: optional \fBLogical_DP_Group\fR" The group of logical datapaths to which the logical flow belongs\[char46] This means that the same logical flow belongs to all datapaths in a group\[char46] .IP "\fBpipeline\fR: string, either \fBegress\fR or \fBingress\fR" The primary flows used for deciding on a packet\(cqs destination are the \fBingress\fR flows\[char46] The \fBegress\fR flows implement ACLs\[char46] See \fBLogical Life Cycle of a Packet\fR, above, for details\[char46] .IP "\fBtable_id\fR: integer, in range 0 to 32" The stage in the logical pipeline, analogous to an OpenFlow table number\[char46] .IP "\fBpriority\fR: integer, in range 0 to 65,535" The flow\(cqs priority\[char46] Flows with numerically higher priority take precedence over those with lower\[char46] If two logical datapath flows with the same priority both match, then the one actually applied to the packet is undefined\[char46] .IP "\fBmatch\fR: string" A matching expression\[char46] OVN provides a superset of OpenFlow matching capabilities, using a syntax similar to Boolean expressions in a programming language\[char46] .IP The most important components of match expression are \fIcomparisons\fR between \fIsymbols\fR and \fIconstants\fR, e\[char46]g\[char46] \fBip4\[char46]dst == 192\[char46]168\[char46]0\[char46]1\fR, \fBip\[char46]proto == 6\fR, \fBarp\[char46]op == 1\fR, \fBeth\[char46]type == 0x800\fR\[char46] The logical AND operator \fB&&\fR and logical OR operator \fB||\fR can combine comparisons into a larger expression\[char46] .IP Matching expressions also support parentheses for grouping, the logical NOT prefix operator \fB!\fR, and literals \fB0\fR and \fB1\fR to express ``false\(cq\(cq or ``true,\(cq\(cq respectively\[char46] The latter is useful by itself as a catch-all expression that matches every packet\[char46] .IP Match expressions also support a kind of function syntax\[char46] The following functions are supported: .RS .TP \fBis_chassis_resident(\fIlport\fB)\fR Evaluates to true on a chassis on which logical port \fIlport\fR (a quoted string) resides, and to false elsewhere\[char46] This function was introduced in OVN 2\[char46]7\[char46] .RE .IP \fBSymbols\fR .IP \fBType\fR\[char46] Symbols have \fIinteger\fR or \fIstring\fR type\[char46] Integer symbols have a \fIwidth\fR in bits\[char46] .IP \fBKinds\fR\[char46] There are three kinds of symbols: .RS .IP \(bu \fIFields\fR\[char46] A field symbol represents a packet header or metadata field\[char46] For example, a field named \fBvlan\[char46]tci\fR might represent the VLAN TCI field in a packet\[char46] .IP A field symbol can have integer or string type\[char46] Integer fields can be nominal or ordinal (see \fBLevel of Measurement\fR, below)\[char46] .IP \(bu \fISubfields\fR\[char46] A subfield represents a subset of bits from a larger field\[char46] For example, a field \fBvlan\[char46]vid\fR might be defined as an alias for \fBvlan\[char46]tci[0\[char46]\[char46]11]\fR\[char46] Subfields are provided for syntactic convenience, because it is always possible to instead refer to a subset of bits from a field directly\[char46] .IP Only ordinal fields (see \fBLevel of Measurement\fR, below) may have subfields\[char46] Subfields are always ordinal\[char46] .IP \(bu \fIPredicates\fR\[char46] A predicate is shorthand for a Boolean expression\[char46] Predicates may be used much like 1-bit fields\[char46] For example, \fBip4\fR might expand to \fBeth\[char46]type == 0x800\fR\[char46] Predicates are provided for syntactic convenience, because it is always possible to instead specify the underlying expression directly\[char46] .IP A predicate whose expansion refers to any nominal field or predicate (see \fBLevel of Measurement\fR, below) is nominal; other predicates have Boolean level of measurement\[char46] .RE .IP \fBLevel of Measurement\fR\[char46] See http://en\[char46]wikipedia\[char46]org/wiki/Level_of_measurement for the statistical concept on which this classification is based\[char46] There are three levels: .RS .IP \(bu \fIOrdinal\fR\[char46] In statistics, ordinal values can be ordered on a scale\[char46] OVN considers a field (or subfield) to be ordinal if its bits can be examined individually\[char46] This is true for the OpenFlow fields that OpenFlow or Open vSwitch makes ``maskable\[char46]\(cq\(cq .IP Any use of a ordinal field may specify a single bit or a range of bits, e\[char46]g\[char46] \fBvlan\[char46]tci[13\[char46]\[char46]15]\fR refers to the PCP field within the VLAN TCI, and \fBeth\[char46]dst[40]\fR refers to the multicast bit in the Ethernet destination address\[char46] .IP OVN supports all the usual arithmetic relations (\fB==\fR, \fB!=\fR, \fB<\fR, \fB<=\fR, \fB>\fR, and \fB>=\fR) on ordinal fields and their subfields, because OVN can implement these in OpenFlow and Open vSwitch as collections of bitwise tests\[char46] .IP \(bu \fINominal\fR\[char46] In statistics, nominal values cannot be usefully compared except for equality\[char46] This is true of OpenFlow port numbers, Ethernet types, and IP protocols are examples: all of these are just identifiers assigned arbitrarily with no deeper meaning\[char46] In OpenFlow and Open vSwitch, bits in these fields generally aren\(cqt individually addressable\[char46] .IP OVN only supports arithmetic tests for equality on nominal fields, because OpenFlow and Open vSwitch provide no way for a flow to efficiently implement other comparisons on them\[char46] (A test for inequality can be sort of built out of two flows with different priorities, but OVN matching expressions always generate flows with a single priority\[char46]) .IP String fields are always nominal\[char46] .IP \(bu \fIBoolean\fR\[char46] A nominal field that has only two values, 0 and 1, is somewhat exceptional, since it is easy to support both equality and inequality tests on such a field: either one can be implemented as a test for 0 or 1\[char46] .IP Only predicates (see above) have a Boolean level of measurement\[char46] .IP This isn\(cqt a standard level of measurement\[char46] .RE .IP \fBPrerequisites\fR\[char46] Any symbol can have prerequisites, which are additional condition implied by the use of the symbol\[char46] For example, For example, \fBicmp4\[char46]type\fR symbol might have prerequisite \fBicmp4\fR, which would cause an expression \fBicmp4\[char46]type == 0\fR to be interpreted as \fBicmp4\[char46]type == 0 && icmp4\fR, which would in turn expand to \fBicmp4\[char46]type == 0 && eth\[char46]type == 0x800 && ip4\[char46]proto == 1\fR (assuming \fBicmp4\fR is a predicate defined as suggested under \fBTypes\fR above)\[char46] .IP \fBRelational operators\fR .IP All of the standard relational operators \fB==\fR, \fB!=\fR, \fB<\fR, \fB<=\fR, \fB>\fR, and \fB>=\fR are supported\[char46] Nominal fields support only \fB==\fR and \fB!=\fR, and only in a positive sense when outer \fB!\fR are taken into account, e\[char46]g\[char46] given string field \fBinport\fR, \fBinport == \(dqeth0\(dq\fR and \fB!(inport != \(dqeth0\(dq)\fR are acceptable, but not \fBinport != \(dqeth0\(dq\fR\[char46] .IP The implementation of \fB==\fR (or \fB!=\fR when it is negated), is more efficient than that of the other relational operators\[char46] .IP \fBConstants\fR .IP Integer constants may be expressed in decimal, hexadecimal prefixed by \fB0x\fR, or as dotted-quad IPv4 addresses, IPv6 addresses in their standard forms, or Ethernet addresses as colon-separated hex digits\[char46] A constant in any of these forms may be followed by a slash and a second constant (the mask) in the same form, to form a masked constant\[char46] IPv4 and IPv6 masks may be given as integers, to express CIDR prefixes\[char46] .IP String constants have the same syntax as quoted strings in JSON (thus, they are Unicode strings)\[char46] .IP Some operators support sets of constants written inside curly braces \fB{\fR \[char46]\[char46]\[char46] \fB}\fR\[char46] Commas between elements of a set, and after the last elements, are optional\[char46] With \fB==\fR, ``\fB\fIfield\fB == { \fIconstant1\fB, \fIconstant2\fB,\fR \[char46]\[char46]\[char46] \fB}\fR\(cq\(cq is syntactic sugar for ``\fB\fIfield\fB == \fIconstant1\fB || \fIfield\fB == \fIconstant2\fB || \fR\[char46]\[char46]\[char46]\fB\fR\[char46] Similarly, ``\fB\fIfield\fB != { \fIconstant1\fB, \fIconstant2\fB, \fR\[char46]\[char46]\[char46]\fB }\fR\(cq\(cq is equivalent to ``\fB\fIfield\fB != \fIconstant1\fB && \fIfield\fB != \fIconstant2\fB && \fR\[char46]\[char46]\[char46]\fB\fR\(cq\(cq\[char46] .IP You may refer to a set of IPv4, IPv6, or MAC addresses stored in the \fBAddress_Set\fR table by its \fBname\fR\[char46] An \fBAddress_Set\fR with a name of \fBset1\fR can be referred to as \fB$set1\fR\[char46] .IP You may refer to a group of logical switch ports stored in the \fBPort_Group\fR table by its \fBname\fR\[char46] An \fBPort_Group\fR with a name of \fBport_group1\fR can be referred to as \fB@port_group1\fR\[char46] .IP Additionally, you may refer to the set of addresses belonging to a group of logical switch ports stored in the \fBPort_Group\fR table by its \fBname\fR followed by a suffix \(cq_ip4\(cq/\(cq_ip6\(cq\[char46] The IPv4 address set of a \fBPort_Group\fR with a name of \fBport_group1\fR can be referred to as \fB$port_group1_ip4\fR, and the IPv6 address set of the same \fBPort_Group\fR can be referred to as \fB$port_group1_ip6\fR .IP \fBMiscellaneous\fR .IP Comparisons may name the symbol or the constant first, e\[char46]g\[char46] \fBtcp\[char46]src == 80\fR and \fB80 == tcp\[char46]src\fR are both acceptable\[char46] .IP Tests for a range may be expressed using a syntax like \fB1024 <= tcp\[char46]src <= 49151\fR, which is equivalent to \fB1024 <= tcp\[char46]src && tcp\[char46]src <= 49151\fR\[char46] .IP For a one-bit field or predicate, a mention of its name is equivalent to \fB\fIsymobl\fB == 1\fR, e\[char46]g\[char46] \fBvlan\[char46]present\fR is equivalent to \fBvlan\[char46]present == 1\fR\[char46] The same is true for one-bit subfields, e\[char46]g\[char46] \fBvlan\[char46]tci[12]\fR\[char46] There is no technical limitation to implementing the same for ordinal fields of all widths, but the implementation is expensive enough that the syntax parser requires writing an explicit comparison against zero to make mistakes less likely, e\[char46]g\[char46] in \fBtcp\[char46]src != 0\fR the comparison against 0 is required\[char46] .IP \fBOperator precedence\fR is as shown below, from highest to lowest\[char46] There are two exceptions where parentheses are required even though the table would suggest that they are not: \fB&&\fR and \fB||\fR require parentheses when used together, and \fB!\fR requires parentheses when applied to a relational expression\[char46] Thus, in \fB(eth\[char46]type == 0x800 || eth\[char46]type == 0x86dd) && ip\[char46]proto == 6\fR or \fB!(arp\[char46]op == 1)\fR, the parentheses are mandatory\[char46] .RS .IP \(bu \fB()\fR .IP \(bu \fB== != < <= > >=\fR .IP \(bu \fB!\fR .IP \(bu \fB&& ||\fR .RE .IP \fBComments\fR may be introduced by \fB//\fR, which extends to the next new-line\[char46] Comments within a line may be bracketed by \fB/*\fR and \fB*/\fR\[char46] Multiline comments are not supported\[char46] .IP \fBSymbols\fR .IP Most of the symbols below have integer type\[char46] Only \fBinport\fR and \fBoutport\fR have string type\[char46] \fBinport\fR names a logical port\[char46] Thus, its value is a \fBlogical_port\fR name from the \fBPort_Binding\fR table\[char46] \fBoutport\fR may name a logical port, as \fBinport\fR, or a logical multicast group defined in the \fBMulticast_Group\fR table\[char46] For both symbols, only names within the flow\(cqs logical datapath may be used\[char46] .IP The \fBreg\fR\fIX\fR symbols are 32-bit integers\[char46] The \fBxxreg\fR\fIX\fR symbols are 128-bit integers, which overlay four of the 32-bit registers: \fBxxreg0\fR overlays \fBreg0\fR through \fBreg3\fR, with \fBreg0\fR supplying the most-significant bits of \fBxxreg0\fR and \fBreg3\fR the least-significant\[char46] \fBxxreg1\fR similarly overlays \fBreg4\fR through \fBreg7\fR\[char46] .RS .IP \(bu \fBreg0\fR\[char46]\[char46]\[char46]\fBreg9\fR .IP \(bu \fBxxreg0\fR \fBxxreg1\fR .IP \(bu \fBinport\fR \fBoutport\fR .IP \(bu \fBflags\[char46]loopback\fR .IP \(bu \fBpkt\[char46]mark\fR .IP \(bu \fBeth\[char46]src\fR \fBeth\[char46]dst\fR \fBeth\[char46]type\fR .IP \(bu \fBvlan\[char46]tci\fR \fBvlan\[char46]vid\fR \fBvlan\[char46]pcp\fR \fBvlan\[char46]present\fR .IP \(bu \fBip\[char46]proto\fR \fBip\[char46]dscp\fR \fBip\[char46]ecn\fR \fBip\[char46]ttl\fR \fBip\[char46]frag\fR .IP \(bu \fBip4\[char46]src\fR \fBip4\[char46]dst\fR .IP \(bu \fBip6\[char46]src\fR \fBip6\[char46]dst\fR \fBip6\[char46]label\fR .IP \(bu \fBarp\[char46]op\fR \fBarp\[char46]spa\fR \fBarp\[char46]tpa\fR \fBarp\[char46]sha\fR \fBarp\[char46]tha\fR .IP \(bu \fBrarp\[char46]op\fR \fBrarp\[char46]spa\fR \fBrarp\[char46]tpa\fR \fBrarp\[char46]sha\fR \fBrarp\[char46]tha\fR .IP \(bu \fBtcp\[char46]src\fR \fBtcp\[char46]dst\fR \fBtcp\[char46]flags\fR .IP \(bu \fBudp\[char46]src\fR \fBudp\[char46]dst\fR .IP \(bu \fBsctp\[char46]src\fR \fBsctp\[char46]dst\fR .IP \(bu \fBicmp4\[char46]type\fR \fBicmp4\[char46]code\fR .IP \(bu \fBicmp6\[char46]type\fR \fBicmp6\[char46]code\fR .IP \(bu \fBnd\[char46]target\fR \fBnd\[char46]sll\fR \fBnd\[char46]tll\fR .IP \(bu \fBct_mark\fR \fBct_label\fR .IP \(bu \fBct_state\fR, which has several Boolean subfields\[char46] The \fBct_next\fR action initializes the following subfields: .RS .IP \(bu \fBct\[char46]trk\fR: Always set to true by \fBct_next\fR to indicate that connection tracking has taken place\[char46] All other \fBct\fR subfields have \fBct\[char46]trk\fR as a prerequisite\[char46] .IP \(bu \fBct\[char46]new\fR: True for a new flow .IP \(bu \fBct\[char46]est\fR: True for an established flow .IP \(bu \fBct\[char46]rel\fR: True for a related flow .IP \(bu \fBct\[char46]rpl\fR: True for a reply flow .IP \(bu \fBct\[char46]inv\fR: True for a connection entry in a bad state .RE .IP The \fBct_dnat\fR, \fBct_snat\fR, and \fBct_lb\fR actions initialize the following subfields: .RS .IP \(bu \fBct\[char46]dnat\fR: True for a packet whose destination IP address has been changed\[char46] .IP \(bu \fBct\[char46]snat\fR: True for a packet whose source IP address has been changed\[char46] .RE .RE .IP The following predicates are supported: .RS .IP \(bu \fBeth\[char46]bcast\fR expands to \fBeth\[char46]dst == ff:ff:ff:ff:ff:ff\fR .IP \(bu \fBeth\[char46]mcast\fR expands to \fBeth\[char46]dst[40]\fR .IP \(bu \fBvlan\[char46]present\fR expands to \fBvlan\[char46]tci[12]\fR .IP \(bu \fBip4\fR expands to \fBeth\[char46]type == 0x800\fR .IP \(bu \fBip4\[char46]src_mcast\fR expands to \fBip4\[char46]src[28\[char46]\[char46]31] == 0xe\fR .IP \(bu \fBip4\[char46]mcast\fR expands to \fBip4\[char46]dst[28\[char46]\[char46]31] == 0xe\fR .IP \(bu \fBip6\fR expands to \fBeth\[char46]type == 0x86dd\fR .IP \(bu \fBip\fR expands to \fBip4 || ip6\fR .IP \(bu \fBicmp4\fR expands to \fBip4 && ip\[char46]proto == 1\fR .IP \(bu \fBicmp6\fR expands to \fBip6 && ip\[char46]proto == 58\fR .IP \(bu \fBicmp\fR expands to \fBicmp4 || icmp6\fR .IP \(bu \fBip\[char46]is_frag\fR expands to \fBip\[char46]frag[0]\fR .IP \(bu \fBip\[char46]later_frag\fR expands to \fBip\[char46]frag[1]\fR .IP \(bu \fBip\[char46]first_frag\fR expands to \fBip\[char46]is_frag && !ip\[char46]later_frag\fR .IP \(bu \fBarp\fR expands to \fBeth\[char46]type == 0x806\fR .IP \(bu \fBrarp\fR expands to \fBeth\[char46]type == 0x8035\fR .IP \(bu \fBnd\fR expands to \fBicmp6\[char46]type == {135, 136} && icmp6\[char46]code == 0 && ip\[char46]ttl == 255\fR .IP \(bu \fBnd_ns\fR expands to \fBicmp6\[char46]type == 135 && icmp6\[char46]code == 0 && ip\[char46]ttl == 255\fR .IP \(bu \fBnd_na\fR expands to \fBicmp6\[char46]type == 136 && icmp6\[char46]code == 0 && ip\[char46]ttl == 255\fR .IP \(bu \fBnd_rs\fR expands to \fBicmp6\[char46]type == 133 && icmp6\[char46]code == 0 && ip\[char46]ttl == 255\fR .IP \(bu \fBnd_ra\fR expands to \fBicmp6\[char46]type == 134 && icmp6\[char46]code == 0 && ip\[char46]ttl == 255\fR .IP \(bu \fBtcp\fR expands to \fBip\[char46]proto == 6\fR .IP \(bu \fBudp\fR expands to \fBip\[char46]proto == 17\fR .IP \(bu \fBsctp\fR expands to \fBip\[char46]proto == 132\fR .RE .IP "\fBactions\fR: string" Logical datapath actions, to be executed when the logical flow represented by this row is the highest-priority match\[char46] .IP Actions share lexical syntax with the \fBmatch\fR column\[char46] An empty set of actions (or one that contains just white space or comments), or a set of actions that consists of just \fBdrop;\fR, causes the matched packets to be dropped\[char46] Otherwise, the column should contain a sequence of actions, each terminated by a semicolon\[char46] .IP The following actions are defined: .RS .TP \fBoutput;\fR In the ingress pipeline, this action executes the \fBegress\fR pipeline as a subroutine\[char46] If \fBoutport\fR names a logical port, the egress pipeline executes once; if it is a multicast group, the egress pipeline runs once for each logical port in the group\[char46] .IP In the egress pipeline, this action performs the actual output to the \fBoutport\fR logical port\[char46] (In the egress pipeline, \fBoutport\fR never names a multicast group\[char46]) .IP By default, output to the input port is implicitly dropped, that is, \fBoutput\fR becomes a no-op if \fBoutport\fR == \fBinport\fR\[char46] Occasionally it may be useful to override this behavior, e\[char46]g\[char46] to send an ARP reply to an ARP request; to do so, use \fBflags\[char46]loopback = 1\fR to allow the packet to \(dqhair-pin\(dq back to the input port\[char46] .TP \fBnext;\fR .TQ .5in \fBnext(\fItable\fB);\fR .TQ .5in \fBnext(pipeline=\fIpipeline\fB, table=\fItable\fB);\fR Executes the given logical datapath \fItable\fR in \fIpipeline\fR as a subroutine\[char46] The default \fItable\fR is just after the current one\[char46] If \fIpipeline\fR is specified, it may be \fBingress\fR or \fBegress\fR; the default \fIpipeline\fR is the one currently executing\[char46] Actions in the both ingress and egress pipeline can use \fBnext\fR to jump across the other pipeline\[char46] Actions in the ingress pipeline should use \fBnext\fR to jump into the specific table of egress pipeline only if it is certain that the packets are local and not tunnelled and wants to skip certain stages in the packet processing\[char46] .TP \fB\fIfield\fB = \fIconstant\fB;\fR Sets data or metadata field \fIfield\fR to constant value \fIconstant\fR, e\[char46]g\[char46] \fBoutport = \(dqvif0\(dq;\fR to set the logical output port\[char46] To set only a subset of bits in a field, specify a subfield for \fIfield\fR or a masked \fIconstant\fR, e\[char46]g\[char46] one may use \fBvlan\[char46]pcp[2] = 1;\fR or \fBvlan\[char46]pcp = 4/4;\fR to set the most significant bit of the VLAN PCP\[char46] .IP Assigning to a field with prerequisites implicitly adds those prerequisites to \fBmatch\fR; thus, for example, a flow that sets \fBtcp\[char46]dst\fR applies only to TCP flows, regardless of whether its \fBmatch\fR mentions any TCP field\[char46] .IP Not all fields are modifiable (e\[char46]g\[char46] \fBeth\[char46]type\fR and \fBip\[char46]proto\fR are read-only), and not all modifiable fields may be partially modified (e\[char46]g\[char46] \fBip\[char46]ttl\fR must assigned as a whole)\[char46] The \fBoutport\fR field is modifiable in the \fBingress\fR pipeline but not in the \fBegress\fR pipeline\[char46] .TP \fB\fIovn_field\fB = \fIconstant\fB;\fR Sets OVN field \fIovn_field\fR to constant value \fIconstant\fR\[char46] .IP \fBOVN\fR supports setting the values of certain fields which are not yet supported in OpenFlow to set or modify them\[char46] .IP Below are the supported \fBOVN fields\fR: .RS .IP \(bu \fBicmp4\[char46]frag_mtu\fR \fBicmp6\[char46]frag_mtu\fR .IP This field sets the low-order 16 bits of the ICMP{4,6} header field that is labelled \(dqunused\(dq in the ICMP specification as defined in the RFC 1191 with the value specified in \fIconstant\fR\[char46] .IP Eg\[char46] icmp4\[char46]frag_mtu = 1500; .RE .TP \fB\fIfield1\fB = \fIfield2\fB;\fR Sets data or metadata field \fIfield1\fR to the value of data or metadata field \fIfield2\fR, e\[char46]g\[char46] \fBreg0 = ip4\[char46]src;\fR copies \fBip4\[char46]src\fR into \fBreg0\fR\[char46] To modify only a subset of a field\(cqs bits, specify a subfield for \fIfield1\fR or \fIfield2\fR or both, e\[char46]g\[char46] \fBvlan\[char46]pcp = reg0[0\[char46]\[char46]2];\fR copies the least-significant bits of \fBreg0\fR into the VLAN PCP\[char46] .IP \fIfield1\fR and \fIfield2\fR must be the same type, either both string or both integer fields\[char46] If they are both integer fields, they must have the same width\[char46] .IP If \fIfield1\fR or \fIfield2\fR has prerequisites, they are added implicitly to \fBmatch\fR\[char46] It is possible to write an assignment with contradictory prerequisites, such as \fBip4\[char46]src = ip6\[char46]src[0\[char46]\[char46]31];\fR, but the contradiction means that a logical flow with such an assignment will never be matched\[char46] .TP \fB\fIfield1\fB <\-> \fIfield2\fB;\fR Similar to \fB\fIfield1\fB = \fIfield2\fB;\fR except that the two values are exchanged instead of copied\[char46] Both \fIfield1\fR and \fIfield2\fR must modifiable\[char46] .TP \fBpush(\fIfield\fB);\fR Push the value of \fIfield\fR to the stack top\[char46] .TP \fBpop(\fIfield\fB);\fR Pop the stack top and store the value to \fIfield\fR, which must be modifiable\[char46] .TP \fBip\[char46]ttl\-\-;\fR Decrements the IPv4 or IPv6 TTL\[char46] If this would make the TTL zero or negative, then processing of the packet halts; no further actions are processed\[char46] (To properly handle such cases, a higher-priority flow should match on \fBip\[char46]ttl == {0, 1};\fR\[char46]) .IP \fBPrerequisite:\fR \fBip\fR .TP \fBct_next;\fR Apply connection tracking to the flow, initializing \fBct_state\fR for matching in later tables\[char46] Automatically moves on to the next table, as if followed by \fBnext\fR\[char46] .IP As a side effect, IP fragments will be reassembled for matching\[char46] If a fragmented packet is output, then it will be sent with any overlapping fragments squashed\[char46] The connection tracking state is scoped by the logical port when the action is used in a flow for a logical switch, so overlapping addresses may be used\[char46] To allow traffic related to the matched flow, execute \fBct_commit \fR\[char46] Connection tracking state is scoped by the logical topology when the action is used in a flow for a router\[char46] .IP It is possible to have actions follow \fBct_next\fR, but they will not have access to any of its side-effects and is not generally useful\[char46] .TP \fBct_commit { };\fR .TQ .5in \fBct_commit { ct_mark=\fIvalue[/mask]\fB; };\fR .TQ .5in \fBct_commit { ct_label=\fIvalue[/mask]\fB; };\fR .TQ .5in \fBct_commit { ct_mark=\fIvalue[/mask]\fB; ct_label=\fIvalue[/mask]\fB; };\fR Commit the flow to the connection tracking entry associated with it by a previous call to \fBct_next\fR\[char46] When \fBct_mark=\fIvalue[/mask]\fB\fR and/or \fBct_label=\fIvalue[/mask]\fB\fR are supplied, \fBct_mark\fR and/or \fBct_label\fR will be set to the values indicated by \fIvalue[/mask]\fR on the connection tracking entry\[char46] \fBct_mark\fR is a 32-bit field\[char46] \fBct_label\fR is a 128-bit field\[char46] The \fIvalue[/mask]\fR should be specified in hex string if more than 64bits are to be used\[char46] Registers and other named fields can be used for \fIvalue\fR\[char46] \fBct_mark\fR and \fBct_label\fR may be sub-addressed in order to have specific bits set\[char46] .IP Note that if you want processing to continue in the next table, you must execute the \fBnext\fR action after \fBct_commit\fR\[char46] You may also leave out \fBnext\fR which will commit connection tracking state, and then drop the packet\[char46] This could be useful for setting \fBct_mark\fR on a connection tracking entry before dropping a packet, for example\[char46] .TP \fBct_dnat;\fR .TQ .5in \fBct_dnat(\fIIP\fB);\fR \fBct_dnat\fR sends the packet through the DNAT zone in connection tracking table to unDNAT any packet that was DNATed in the opposite direction\[char46] The packet is then automatically sent to to the next tables as if followed by \fBnext;\fR action\[char46] The next tables will see the changes in the packet caused by the connection tracker\[char46] .IP \fBct_dnat(\fIIP\fB)\fR sends the packet through the DNAT zone to change the destination IP address of the packet to the one provided inside the parentheses and commits the connection\[char46] The packet is then automatically sent to the next tables as if followed by \fBnext;\fR action\[char46] The next tables will see the changes in the packet caused by the connection tracker\[char46] .TP \fBct_snat;\fR .TQ .5in \fBct_snat(\fIIP\fB);\fR \fBct_snat\fR sends the packet through the SNAT zone to unSNAT any packet that was SNATed in the opposite direction\[char46] The packet is automatically sent to the next tables as if followed by the \fBnext;\fR action\[char46] The next tables will see the changes in the packet caused by the connection tracker\[char46] .IP \fBct_snat(\fIIP\fB)\fR sends the packet through the SNAT zone to change the source IP address of the packet to the one provided inside the parenthesis and commits the connection\[char46] The packet is then automatically sent to the next tables as if followed by \fBnext;\fR action\[char46] The next tables will see the changes in the packet caused by the connection tracker\[char46] .TP \fBct_dnat_in_czone;\fR .TQ .5in \fBct_dnat_in_czone(\fIIP\fB);\fR \fBct_dnat_in_czone\fR sends the packet through the common NAT zone (used for both DNAT and SNAT) in connection tracking table to unDNAT any packet that was DNATed in the opposite direction\[char46] The packet is then automatically sent to to the next tables as if followed by \fBnext;\fR action\[char46] The next tables will see the changes in the packet caused by the connection tracker\[char46] .IP \fBct_dnat_in_czone(\fIIP\fB)\fR sends the packet through the common NAT zone to change the destination IP address of the packet to the one provided inside the parentheses and commits the connection\[char46] The packet is then automatically sent to the next tables as if followed by \fBnext;\fR action\[char46] The next tables will see the changes in the packet caused by the connection tracker\[char46] .TP \fBct_snat_in_czone;\fR .TQ .5in \fBct_snat_in_czone(\fIIP\fB);\fR \fBct_snat_in_czone\fR sends the packet through the common NAT zone to unSNAT any packet that was SNATed in the opposite direction\[char46] The packet is automatically sent to the next tables as if followed by the \fBnext;\fR action\[char46] The next tables will see the changes in the packet caused by the connection tracker\[char46] .IP \fBct_snat_in_czone(\fIIP\fB)\fR sends the packet\e through the common NAT zone to change the source IP address of the packet to the one provided inside the parenthesis and commits the connection\[char46] The packet is then automatically sent to the next tables as if followed by \fBnext;\fR action\[char46] The next tables will see the changes in the packet caused by the connection tracker\[char46] .TP \fBct_clear;\fR Clears connection tracking state\[char46] .TP \fBct_commit_nat;\fR Applies NAT and commits the connection to the CT\[char46] Automatically moves on to the next table, as if followed by \fBnext\fR\[char46] This is very useful for connections that are in related state for already existing connections and allows the NAT to be applied to them as well\[char46] .TP \fBclone { \fIaction\fB; \fR\[char46]\[char46]\[char46]\fB };\fR Makes a copy of the packet being processed and executes each \fBaction\fR on the copy\[char46] Actions following the \fIclone\fR action, if any, apply to the original, unmodified packet\[char46] This can be used as a way to ``save and restore\(cq\(cq the packet around a set of actions that may modify it and should not persist\[char46] .TP \fBarp { \fIaction\fB; \fR\[char46]\[char46]\[char46]\fB };\fR Temporarily replaces the IPv4 packet being processed by an ARP packet and executes each nested \fIaction\fR on the ARP packet\[char46] Actions following the \fIarp\fR action, if any, apply to the original, unmodified packet\[char46] .IP The ARP packet that this action operates on is initialized based on the IPv4 packet being processed, as follows\[char46] These are default values that the nested actions will probably want to change: .RS .IP \(bu \fBeth\[char46]src\fR unchanged .IP \(bu \fBeth\[char46]dst\fR unchanged .IP \(bu \fBeth\[char46]type = 0x0806\fR .IP \(bu \fBarp\[char46]op = 1\fR (ARP request) .IP \(bu \fBarp\[char46]sha\fR copied from \fBeth\[char46]src\fR .IP \(bu \fBarp\[char46]spa\fR copied from \fBip4\[char46]src\fR .IP \(bu \fBarp\[char46]tha = 00:00:00:00:00:00\fR .IP \(bu \fBarp\[char46]tpa\fR copied from \fBip4\[char46]dst\fR .RE .IP The ARP packet has the same VLAN header, if any, as the IP packet it replaces\[char46] .IP \fBPrerequisite:\fR \fBip4\fR .TP \fBget_arp(\fIP\fB, \fIA\fB);\fR \fBParameters\fR: logical port string field \fIP\fR, 32-bit IP address field \fIA\fR\[char46] .IP Looks up \fIA\fR in \fIP\fR\(cqs mac binding table\[char46] If an entry is found, stores its Ethernet address in \fBeth\[char46]dst\fR, otherwise stores \fB00:00:00:00:00:00\fR in \fBeth\[char46]dst\fR\[char46] .IP \fBExample:\fR \fBget_arp(outport, ip4\[char46]dst);\fR .TP \fBput_arp(\fIP\fB, \fIA\fB, \fIE\fB);\fR \fBParameters\fR: logical port string field \fIP\fR, 32-bit IP address field \fIA\fR, 48-bit Ethernet address field \fIE\fR\[char46] .IP Adds or updates the entry for IP address \fIA\fR in logical port \fIP\fR\(cqs mac binding table, setting its Ethernet address to \fIE\fR\[char46] .IP \fBExample:\fR \fBput_arp(inport, arp\[char46]spa, arp\[char46]sha);\fR .TP \fB\fIR\fB = lookup_arp(\fIP\fB, \fIA\fB, \fIM\fB);\fR \fBParameters\fR: logical port string field \fIP\fR, 32-bit IP address field \fIA\fR, 48-bit MAC address field \fIM\fR\[char46] .IP \fBResult\fR: stored to a 1-bit subfield \fIR\fR\[char46] .IP Looks up \fIA\fR and \fIM\fR in \fIP\fR\(cqs mac binding table\[char46] If an entry is found, stores \fB1\fR in the 1-bit subfield \fIR\fR, else 0\[char46] .IP \fBExample:\fR \fB reg0[0] = lookup_arp(inport, arp\[char46]spa, arp\[char46]sha); \fR .TP \fB\fIR\fB = lookup_arp_ip(\fIP\fB, \fIA\fB);\fR \fBParameters\fR: logical port string field \fIP\fR, 32-bit IP address field \fIA\fR\[char46] .IP \fBResult\fR: stored to a 1-bit subfield \fIR\fR\[char46] .IP Looks up \fIA\fR in \fIP\fR\(cqs mac binding table\[char46] If an entry is found, stores \fB1\fR in the 1-bit subfield \fIR\fR, else 0\[char46] .IP \fBExample:\fR \fB reg0[0] = lookup_arp_ip(inport, arp\[char46]spa); \fR .TP \fB\fIP\fB = get_fdb(\fIA\fB);\fR \fBParameters\fR:48-bit MAC address field \fIA\fR\[char46] .IP Looks up \fIA\fR in fdb table\[char46] If an entry is found, stores the logical port key to the out parameter \fBP\fR\[char46] .IP \fBExample:\fR \fBoutport = get_fdb(eth\[char46]src);\fR .TP \fBput_fdb(\fIP\fB, \fIA\fB);\fR \fBParameters\fR: logical port string field \fIP\fR, 48-bit MAC address field \fIA\fR\[char46] .IP Adds or updates the entry for Ethernet address \fIA\fR in fdb table, setting its logical port key to \fIP\fR\[char46] .IP \fBExample:\fR \fBput_fdb(inport, arp\[char46]spa);\fR .TP \fB\fIR\fB = lookup_fdb(\fIP\fB, \fIA\fB);\fR \fBParameters\fR: 48-bit MAC address field \fIM\fR, logical port string field \fIP\fR\[char46] .IP \fBResult\fR: stored to a 1-bit subfield \fIR\fR\[char46] .IP Looks up \fIA\fR in fdb table\[char46] If an entry is found and the the logical port key is \fIP\fR, \fBP\fR, stores \fB1\fR in the 1-bit subfield \fIR\fR, else 0\[char46] .IP \fBExample:\fR \fB reg0[0] = lookup_fdb(inport, eth\[char46]src); \fR .TP \fBnd_ns { \fIaction\fB; \fR\[char46]\[char46]\[char46]\fB };\fR Temporarily replaces the IPv6 packet being processed by an IPv6 Neighbor Solicitation packet and executes each nested \fIaction\fR on the IPv6 NS packet\[char46] Actions following the \fInd_ns\fR action, if any, apply to the original, unmodified packet\[char46] .IP The IPv6 NS packet that this action operates on is initialized based on the IPv6 packet being processed, as follows\[char46] These are default values that the nested actions will probably want to change: .RS .IP \(bu \fBeth\[char46]src\fR unchanged .IP \(bu \fBeth\[char46]dst\fR set to IPv6 multicast MAC address .IP \(bu \fBeth\[char46]type = 0x86dd\fR .IP \(bu \fBip6\[char46]src\fR copied from \fBip6\[char46]src\fR .IP \(bu \fBip6\[char46]dst\fR set to IPv6 Solicited-Node multicast address .IP \(bu \fBicmp6\[char46]type = 135\fR (Neighbor Solicitation) .IP \(bu \fBnd\[char46]target\fR copied from \fBip6\[char46]dst\fR .RE .IP The IPv6 NS packet has the same VLAN header, if any, as the IP packet it replaces\[char46] .IP \fBPrerequisite:\fR \fBip6\fR .TP \fBnd_na { \fIaction\fB; \fR\[char46]\[char46]\[char46]\fB };\fR Temporarily replaces the IPv6 neighbor solicitation packet being processed by an IPv6 neighbor advertisement (NA) packet and executes each nested \fIaction\fR on the NA packet\[char46] Actions following the \fBnd_na\fR action, if any, apply to the original, unmodified packet\[char46] .IP The NA packet that this action operates on is initialized based on the IPv6 packet being processed, as follows\[char46] These are default values that the nested actions will probably want to change: .RS .IP \(bu \fBeth\[char46]dst\fR exchanged with \fBeth\[char46]src\fR .IP \(bu \fBeth\[char46]type = 0x86dd\fR .IP \(bu \fBip6\[char46]dst\fR copied from \fBip6\[char46]src\fR .IP \(bu \fBip6\[char46]src\fR copied from \fBnd\[char46]target\fR .IP \(bu \fBicmp6\[char46]type = 136\fR (Neighbor Advertisement) .IP \(bu \fBnd\[char46]target\fR unchanged .IP \(bu \fBnd\[char46]sll = 00:00:00:00:00:00\fR .IP \(bu \fBnd\[char46]tll\fR copied from \fBeth\[char46]dst\fR .RE .IP The ND packet has the same VLAN header, if any, as the IPv6 packet it replaces\[char46] .IP \fBPrerequisite:\fR \fBnd_ns\fR .TP \fBnd_na_router { \fIaction\fB; \fR\[char46]\[char46]\[char46]\fB };\fR Temporarily replaces the IPv6 neighbor solicitation packet being processed by an IPv6 neighbor advertisement (NA) packet, sets ND_NSO_ROUTER in the RSO flags and executes each nested \fIaction\fR on the NA packet\[char46] Actions following the \fBnd_na_router\fR action, if any, apply to the original, unmodified packet\[char46] .IP The NA packet that this action operates on is initialized based on the IPv6 packet being processed, as follows\[char46] These are default values that the nested actions will probably want to change: .RS .IP \(bu \fBeth\[char46]dst\fR exchanged with \fBeth\[char46]src\fR .IP \(bu \fBeth\[char46]type = 0x86dd\fR .IP \(bu \fBip6\[char46]dst\fR copied from \fBip6\[char46]src\fR .IP \(bu \fBip6\[char46]src\fR copied from \fBnd\[char46]target\fR .IP \(bu \fBicmp6\[char46]type = 136\fR (Neighbor Advertisement) .IP \(bu \fBnd\[char46]target\fR unchanged .IP \(bu \fBnd\[char46]sll = 00:00:00:00:00:00\fR .IP \(bu \fBnd\[char46]tll\fR copied from \fBeth\[char46]dst\fR .RE .IP The ND packet has the same VLAN header, if any, as the IPv6 packet it replaces\[char46] .IP \fBPrerequisite:\fR \fBnd_ns\fR .TP \fBget_nd(\fIP\fB, \fIA\fB);\fR \fBParameters\fR: logical port string field \fIP\fR, 128-bit IPv6 address field \fIA\fR\[char46] .IP Looks up \fIA\fR in \fIP\fR\(cqs mac binding table\[char46] If an entry is found, stores its Ethernet address in \fBeth\[char46]dst\fR, otherwise stores \fB00:00:00:00:00:00\fR in \fBeth\[char46]dst\fR\[char46] .IP \fBExample:\fR \fBget_nd(outport, ip6\[char46]dst);\fR .TP \fBput_nd(\fIP\fB, \fIA\fB, \fIE\fB);\fR \fBParameters\fR: logical port string field \fIP\fR, 128-bit IPv6 address field \fIA\fR, 48-bit Ethernet address field \fIE\fR\[char46] .IP Adds or updates the entry for IPv6 address \fIA\fR in logical port \fIP\fR\(cqs mac binding table, setting its Ethernet address to \fIE\fR\[char46] .IP \fBExample:\fR \fBput_nd(inport, nd\[char46]target, nd\[char46]tll);\fR .TP \fB\fIR\fB = lookup_nd(\fIP\fB, \fIA\fB, \fIM\fB);\fR \fBParameters\fR: logical port string field \fIP\fR, 128-bit IP address field \fIA\fR, 48-bit MAC address field \fIM\fR\[char46] .IP \fBResult\fR: stored to a 1-bit subfield \fIR\fR\[char46] .IP Looks up \fIA\fR and \fIM\fR in \fIP\fR\(cqs mac binding table\[char46] If an entry is found, stores \fB1\fR in the 1-bit subfield \fIR\fR, else 0\[char46] .IP \fBExample:\fR \fB reg0[0] = lookup_nd(inport, ip6\[char46]src, eth\[char46]src); \fR .TP \fB\fIR\fB = lookup_nd_ip(\fIP\fB, \fIA\fB);\fR \fBParameters\fR: logical port string field \fIP\fR, 128-bit IP address field \fIA\fR\[char46] .IP \fBResult\fR: stored to a 1-bit subfield \fIR\fR\[char46] .IP Looks up \fIA\fR in \fIP\fR\(cqs mac binding table\[char46] If an entry is found, stores \fB1\fR in the 1-bit subfield \fIR\fR, else 0\[char46] .IP \fBExample:\fR \fB reg0[0] = lookup_nd_ip(inport, ip6\[char46]src); \fR .TP \fB\fIR\fB = put_dhcp_opts(\fID1\fB = \fIV1\fB, \fID2\fB = \fIV2\fB, \[char46]\[char46]\[char46], \fIDn\fB = \fIVn\fB);\fR \fBParameters\fR: one or more DHCP option/value pairs, which must include an \fBofferip\fR option (with code 0)\[char46] .IP \fBResult\fR: stored to a 1-bit subfield \fIR\fR\[char46] .IP Valid only in the ingress pipeline\[char46] .IP When this action is applied to a DHCP request packet (DHCPDISCOVER or DHCPREQUEST), it changes the packet into a DHCP reply (DHCPOFFER or DHCPACK, respectively), replaces the options by those specified as parameters, and stores 1 in \fIR\fR\[char46] .IP When this action is applied to a non-DHCP packet or a DHCP packet that is not DHCPDISCOVER or DHCPREQUEST, it leaves the packet unchanged and stores 0 in \fIR\fR\[char46] .IP The contents of the \fBDHCP_Option\fR table control the DHCP option names and values that this action supports\[char46] .IP \fBExample:\fR \fB reg0[0] = put_dhcp_opts(offerip = 10\[char46]0\[char46]0\[char46]2, router = 10\[char46]0\[char46]0\[char46]1, netmask = 255\[char46]255\[char46]255\[char46]0, dns_server = {8\[char46]8\[char46]8\[char46]8, 7\[char46]7\[char46]7\[char46]7}); \fR .TP \fB\fIR\fB = put_dhcpv6_opts(\fID1\fB = \fIV1\fB, \fID2\fB = \fIV2\fB, \[char46]\[char46]\[char46], \fIDn\fB = \fIVn\fB);\fR \fBParameters\fR: one or more DHCPv6 option/value pairs\[char46] .IP \fBResult\fR: stored to a 1-bit subfield \fIR\fR\[char46] .IP Valid only in the ingress pipeline\[char46] .IP When this action is applied to a DHCPv6 request packet, it changes the packet into a DHCPv6 reply, replaces the options by those specified as parameters, and stores 1 in \fIR\fR\[char46] .IP When this action is applied to a non-DHCPv6 packet or an invalid DHCPv6 request packet , it leaves the packet unchanged and stores 0 in \fIR\fR\[char46] .IP The contents of the \fBDHCPv6_Options\fR table control the DHCPv6 option names and values that this action supports\[char46] .IP \fBExample:\fR \fB reg0[3] = put_dhcpv6_opts(ia_addr = aef0::4, server_id = 00:00:00:00:10:02, dns_server={ae70::1,ae70::2}); \fR .TP \fBset_queue(\fIqueue_number\fB);\fR \fBParameters\fR: Queue number \fIqueue_number\fR, in the range 0 to 61440\[char46] .IP This is a logical equivalent of the OpenFlow \fBset_queue\fR action\[char46] It affects packets that egress a hypervisor through a physical interface\[char46] For nonzero \fIqueue_number\fR, it configures packet queuing to match the settings configured for the \fBPort_Binding\fR with \fBoptions:qdisc_queue_id\fR matching \fIqueue_number\fR\[char46] When \fIqueue_number\fR is zero, it resets queuing to the default strategy\[char46] .IP \fBExample:\fR \fBset_queue(10);\fR .TP \fBct_lb;\fR .TQ .5in \fBct_lb(backends=\fIip\fB[:\fIport\fB][,\[char46]\[char46]\[char46]][; hash_fields=\fIfield1\fB,\fIfield2\fB,\[char46]\[char46]\[char46]][; ct_flag]);\fR With arguments, \fBct_lb\fR commits the packet to the connection tracking table and DNATs the packet\(cqs destination IP address (and port) to the IP address or addresses (and optional ports) specified in the \fBbackends\fR\[char46] If multiple comma-separated IP addresses are specified, each is given equal weight for picking the DNAT address\[char46] By default, \fBdp_hash\fR is used as the OpenFlow group selection method, but if \fBhash_fields\fR is specified, \fBhash\fR is used as the selection method, and the fields listed are used as the hash fields\[char46] The \fBct_flag\fR field represents one of supported flag: \fBskip_snat\fR or \fBforce_snat\fR, this flag will be stored in \fBct_label\fR register\[char46] .IP Without arguments, \fBct_lb\fR sends the packet to the connection tracking table to NAT the packets\[char46] If the packet is part of an established connection that was previously committed to the connection tracker via \fBct_lb(\fR\[char46]\[char46]\[char46]\fB)\fR, it will automatically get DNATed to the same IP address as the first packet in that connection\[char46] .IP Processing automatically moves on to the next table, as if \fBnext;\fR were specified, and later tables act on the packet as modified by the connection tracker\[char46] Connection tracking state is scoped by the logical port when the action is used in a flow for a logical switch, so overlapping addresses may be used\[char46] Connection tracking state is scoped by the logical topology when the action is used in a flow for a router\[char46] .TP \fBct_lb_mark;\fR .TQ .5in \fBct_lb_mark(backends=\fIip\fB[:\fIport\fB][,\[char46]\[char46]\[char46]][; hash_fields=\fIfield1\fB,\fIfield2\fB,\[char46]\[char46]\[char46]][; ct_flag]);\fR Same as \fBct_lb\fR, except that it internally uses ct_mark to store the NAT flag, while \fBct_lb\fR uses ct_label for the same purpose\[char46] .TP \fB\fIR\fB = dns_lookup();\fR \fBParameters\fR: No parameters\[char46] .IP \fBResult\fR: stored to a 1-bit subfield \fIR\fR\[char46] .IP Valid only in the ingress pipeline\[char46] .IP When this action is applied to a valid DNS request (a UDP packet typically directed to port 53), it attempts to resolve the query using the contents of the \fBDNS\fR table\[char46] If it is successful, it changes the packet into a DNS reply and stores 1 in \fIR\fR\[char46] If the action is applied to a non-DNS packet, an invalid DNS request packet, or a valid DNS request for which the \fBDNS\fR table does not supply an answer, it leaves the packet unchanged and stores 0 in \fIR\fR\[char46] .IP Regardless of success, the action does not make any of the changes to the flow that are necessary to direct the packet back to the requester\[char46] The logical pipeline can implement this behavior with matches and actions in later tables\[char46] .IP \fBExample:\fR \fB reg0[3] = dns_lookup(); \fR .IP \fBPrerequisite:\fR \fBudp\fR .TP \fB\fIR\fB = put_nd_ra_opts(\fID1\fB = \fIV1\fB, \fID2\fB = \fIV2\fB, \[char46]\[char46]\[char46], \fIDn\fB = \fIVn\fB);\fR \fBParameters\fR: The following IPv6 ND Router Advertisement option/value pairs as defined in RFC 4861\[char46] .RS .IP \(bu \fBaddr_mode\fR .IP Mandatory parameter which specifies the address mode flag to be set in the RA flag options field\[char46] The value of this option is a string and the following values can be defined - \(dqslaac\(dq, \(dqdhcpv6_stateful\(dq and \(dqdhcpv6_stateless\(dq\[char46] .IP \(bu \fBslla\fR .IP Mandatory parameter which specifies the link-layer address of the interface from which the Router Advertisement is sent\[char46] .IP \(bu \fBmtu\fR .IP Optional parameter which specifies the MTU\[char46] .IP \(bu \fBprefix\fR .IP Optional parameter which should be specified if the addr_mode is \(dqslaac\(dq or \(dqdhcpv6_stateless\(dq\[char46] The value should be an IPv6 prefix which will be used for stateless IPv6 address configuration\[char46] This option can be defined multiple times\[char46] .RE .IP \fBResult\fR: stored to a 1-bit subfield \fIR\fR\[char46] .IP Valid only in the ingress pipeline\[char46] .IP When this action is applied to an IPv6 Router solicitation request packet, it changes the packet into an IPv6 Router Advertisement reply and adds the options specified in the parameters, and stores 1 in \fIR\fR\[char46] .IP When this action is applied to a non-IPv6 Router solicitation packet or an invalid IPv6 request packet , it leaves the packet unchanged and stores 0 in \fIR\fR\[char46] .IP \fBExample:\fR \fB reg0[3] = put_nd_ra_opts(addr_mode = \(dqslaac\(dq, slla = 00:00:00:00:10:02, prefix = aef0::/64, mtu = 1450); \fR .TP \fBset_meter(\fIrate\fB);\fR .TQ .5in \fBset_meter(\fIrate\fB, \fIburst\fB);\fR \fBParameters\fR: rate limit int field \fIrate\fR in kbps, burst rate limits int field \fIburst\fR in kbps\[char46] .IP This action sets the rate limit for a flow\[char46] .IP \fBExample:\fR \fBset_meter(100, 1000);\fR .TP \fB\fIR\fB = check_pkt_larger(\fIL\fB)\fR \fBParameters\fR: packet length \fIL\fR to check for in bytes\[char46] .IP \fBResult\fR: stored to a 1-bit subfield \fIR\fR\[char46] .IP This is a logical equivalent of the OpenFlow \fBcheck_pkt_larger\fR action\[char46] If the packet is larger than the length specified in \fIL\fR, it stores 1 in the subfield \fIR\fR\[char46] .IP \fBExample: \fR\fBreg0[6] = check_pkt_larger(1000);\fR .RE .RS .TP \fBlog(\fIkey\fB=\fIvalue\fB, \fR\[char46]\[char46]\[char46]\fB);\fR Causes \fBovn\-controller\fR to log the packet on the chassis that processes it\[char46] Packet logging currently uses the same logging mechanism as other Open vSwitch and OVN messages, which means that whether and where log messages appear depends on the local logging configuration that can be configured with \fBovs\-appctl\fR, etc\[char46] .IP The \fBlog\fR action takes zero or more of the following key-value pair arguments that control what is logged: .RS .TP \fBname=\fR\fIstring\fR An optional name for the ACL\[char46] The \fIstring\fR is currently limited to 64 bytes\[char46] .TP \fBseverity=\fR\fIlevel\fR Indicates the severity of the event\[char46] The \fIlevel\fR is one of following (from more to less serious): \fBalert\fR, \fBwarning\fR, \fBnotice\fR, \fBinfo\fR, or \fBdebug\fR\[char46] If a severity is not provided, the default is \fBinfo\fR\[char46] .TP \fBverdict=\fR\fIvalue\fR The verdict for packets matching the flow\[char46] The value must be one of \fBallow\fR, \fBdeny\fR, or \fBreject\fR\[char46] .TP \fBmeter=\fR\fIstring\fR An optional rate-limiting meter to be applied to the logs\[char46] The \fIstring\fR should reference a \fBname\fR entry from the \fBMeter\fR table\[char46] The only meter \fBaction\fR that is appropriate is \fBdrop\fR\[char46] .RE .TP \fBfwd_group(liveness=\fIbool\fB, childports=\fIport\fB, \[char46]\[char46]\[char46]);\fR \fBParameters\fR: optional \fBliveness\fR, either \fBtrue\fR or \fBfalse\fR, defaulting to false; \fBchildports\fR, a comma-delimited list of strings denoting logical ports to load balance across\[char46] .IP Load balance traffic to one or more child ports in a logical switch\[char46] \fBovn\-controller\fR translates the \fBfwd_group\fR into an OpenFlow group with one bucket for each child port\[char46] If \fBliveness=true\fR is specified, it also integrates the bucket selection with BFD status on the tunnel interface corresponding to child port\[char46] .IP \fBExample:\fR \fBfwd_group(liveness=true, childports=\(dqp1\(dq, \(dqp2\(dq);\fR .RE .RS .TP \fBicmp4 { \fIaction\fB; \fR\[char46]\[char46]\[char46]\fB };\fR .TQ .5in \fBicmp4_error { \fIaction\fB; \fR\[char46]\[char46]\[char46]\fB };\fR Temporarily replaces the IPv4 packet being processed by an ICMPv4 packet and executes each nested \fIaction\fR on the ICMPv4 packet\[char46] Actions following these actions, if any, apply to the original, unmodified packet\[char46] .IP The ICMPv4 packet that these actions operates on is initialized based on the IPv4 packet being processed, as follows\[char46] These are default values that the nested actions will probably want to change\[char46] Ethernet and IPv4 fields not listed here are not changed: .RS .IP \(bu \fBip\[char46]proto = 1\fR (ICMPv4) .IP \(bu \fBip\[char46]frag = 0\fR (not a fragment) .IP \(bu \fBip\[char46]ttl = 255\fR .IP \(bu \fBicmp4\[char46]type = 3\fR (destination unreachable) .IP \(bu \fBicmp4\[char46]code = 1\fR (host unreachable) .RE .IP \fBicmp4_error\fR action is expected to be used to generate an ICMPv4 packet in response to an error in original IP packet\[char46] When this action generates the ICMPv4 packet, it also copies the original IP datagram following the ICMPv4 header as per RFC 1122: 3\[char46]2\[char46]2\[char46] .IP \fBPrerequisite:\fR \fBip4\fR .TP \fBicmp6 { \fIaction\fB; \fR\[char46]\[char46]\[char46]\fB };\fR .TQ .5in \fBicmp6_error { \fIaction\fB; \fR\[char46]\[char46]\[char46]\fB };\fR Temporarily replaces the IPv6 packet being processed by an ICMPv6 packet and executes each nested \fIaction\fR on the ICMPv6 packet\[char46] Actions following the \fIicmp6\fR action, if any, apply to the original, unmodified packet\[char46] .IP The ICMPv6 packet that this action operates on is initialized based on the IPv6 packet being processed, as follows\[char46] These are default values that the nested actions will probably want to change\[char46] Ethernet and IPv6 fields not listed here are not changed: .RS .IP \(bu \fBip\[char46]proto = 58\fR (ICMPv6) .IP \(bu \fBip\[char46]ttl = 255\fR .IP \(bu \fBicmp6\[char46]type = 1\fR (destination unreachable) .IP \(bu \fBicmp6\[char46]code = 1\fR (administratively prohibited) .RE .IP \fBicmp6_error\fR action is expected to be used to generate an ICMPv6 packet in response to an error in original IPv6 packet\[char46] .IP \fBPrerequisite:\fR \fBip6\fR .TP \fBtcp_reset;\fR This action transforms the current TCP packet according to the following pseudocode: .IP .nf \fB .br \fBif (tcp\[char46]ack) { .br \fB tcp\[char46]seq = tcp\[char46]ack; .br \fB} else { .br \fB tcp\[char46]ack = tcp\[char46]seq + length(tcp\[char46]payload); .br \fB tcp\[char46]seq = 0; .br \fB} .br \fBtcp\[char46]flags = RST; .br \fB\fR .fi .IP Then, the action drops all TCP options and payload data, and updates the TCP checksum\[char46] IP ttl is set to 255\[char46] .IP \fBPrerequisite:\fR \fBtcp\fR .TP \fBreject { \fIaction\fB; \fR\[char46]\[char46]\[char46]\fB };\fR If the original packet is IPv4 or IPv6 TCP packet, it replaces it with IPv4 or IPv6 TCP RST packet and executes the inner actions\[char46] Otherwise it replaces it with an ICMPv4 or ICMPv6 packet and executes the inner actions\[char46] .IP The inner actions should not attempt to swap eth source with eth destination and IP source with IP destination as this action implicitly does that\[char46] .TP \fBtrigger_event;\fR This action is used to allow ovs-vswitchd to report CMS related events writing them in \fBController_Event\fR table\[char46] It is possible to associate a meter to a each event in order to not overload pinctrl thread under heavy load; each meter is identified though a defined naming convention\[char46] Supported events: .RS .IP \(bu \fIempty_lb_backends\fR\[char46] This event is raised if a received packet is destined for a load balancer VIP that has no configured backend destinations\[char46] For this event, the event info includes the load balancer VIP, the load balancer UUID, and the transport protocol\[char46] Associated meter: \fBevent\-elb\fR .RE .TP \fBigmp;\fR This action sends the packet to \fBovn\-controller\fR for multicast snooping\[char46] .IP \fBPrerequisite:\fR \fBigmp\fR .TP \fBbind_vport(\fIV\fB, \fIP\fB);\fR \fBParameters\fR: logical port string field \fIV\fR of type \fBvirtual\fR, logical port string field \fIP\fR\[char46] .IP Binds the virtual logical port \fIV\fR and sets the \fBchassis\fR column and \fBvirtual_parent\fR of the table \fBPort_Binding\fR\[char46] \fBvirtual_parent\fR is set to \fIP\fR\[char46] .TP \fBhandle_svc_check(\fIP\fB);\fR \fBParameters\fR: logical port string field \fIP\fR\[char46] .IP Handles the service monitor reply received from the VIF of the logical port \fIP\fR\[char46] \fBovn\-controller\fR periodically sends out the service monitor packets for the services configured in the \fBService_Monitor\fR table and this action updates the status of those services\[char46] .IP \fBExample:\fR \fBhandle_svc_check(inport);\fR .TP \fBhandle_dhcpv6_reply;\fR Handle DHCPv6 prefix delegation advertisements/replies from a IPv6 delegation server\[char46] \fBovn\-controller\fR will add an entry \fBipv6_ra_pd_list\fR in the \fBoptions\fR table for each prefix received from the delegation server .TP \fB\fIR\fB = select(\fIN1\fB[=\fIW1\fB], \fIN2\fB[=\fIW2\fB], \[char46]\[char46]\[char46]);\fR \fBParameters\fR: Integer \fIN1\fR, \fIN2\fR\[char46]\[char46]\[char46], with optional weight \fIW1\fR, \fIW2\fR, \[char46]\[char46]\[char46] .IP \fBResult\fR: stored to a logical field or subfield \fIR\fR\[char46] .IP Select from a list of integers \fIN1\fR, \fIN2\fR\[char46]\[char46]\[char46], each within the range 0 ~ 65535, and store the selected one in the field \fIR\fR\[char46] There must be 2 or more integers listed, each with an optional weight, which is an integer within the range 1 ~ 65535\[char46] If weight is not specified, it defaults to 100\[char46] The selection method is based on the 5-tuple hash of packet header\[char46] .IP Processing automatically moves on to the next table, as if \fBnext;\fR were specified\[char46] The \fBselect\fR action must be put as the last action of the logical flow when there are multiple actions (actions put after \fBselect\fR will not take effect)\[char46] .IP \fBExample:\fR \fBreg8[16\[char46]\[char46]31] = select(1=20, 2=30, 3=50);\fR .TP \fBhandle_dhcpv6_reply;\fR This action is used to parse DHCPv6 replies from IPv6 Delegation Router and managed IPv6 Prefix delegation state machine .TP \fB\fIR\fB = chk_lb_hairpin();\fR This action checks if the packet under consideration was destined to a load balancer VIP and it is hairpinned, i\[char46]e\[char46], after load balancing the destination IP matches the source IP\[char46] If it is so, then the 1-bit destination register \fIR\fR is set to 1\[char46] .TP \fB\fIR\fB = chk_lb_hairpin_reply();\fR This action checks if the packet under consideration is from one of the backend IP of a load balancer VIP and the destination IP is the load balancer VIP\[char46] If it is so, then the 1-bit destination register \fIR\fR is set to 1\[char46] .TP \fB\fIR\fB = ct_snat_to_vip;\fR This action sends the packet through the SNAT zone to change the source IP address of the packet to the load balancer VIP if the original destination IP was load balancer VIP and commits the connection\[char46] This action applies successfully only for the hairpinned traffic i\[char46]e if the action \fBchk_lb_hairpin\fR returned success\[char46] This action doesn\(cqt take any arguments and it determines the SNAT IP internally\[char46] The packet is not automatically sent to the next table\[char46] The caller has to execute the \fBnext;\fR action explicitly after this action to advance the packet to the next stage\[char46] .TP \fB\fIR\fB = check_in_port_sec();\fR This action checks if the packet under consideration passes the inport port security checks\[char46] If the packet fails the port security checks, then \fB1\fR is stored in the destination register \fIR\fR\[char46] Else 0 is stored\[char46] The port security values to check are retrieved from the the \fBinport\fR logical port\[char46] .IP This action should be used in the ingress logical switch pipeline\[char46] .IP \fBExample:\fR \fBreg8[0\[char46]\[char46]7] = check_in_port_sec();\fR .TP \fB\fIR\fB = check_out_port_sec();\fR This action checks if the packet under consideration passes the outport port security checks\[char46] If the packet fails the port security checks, then \fB1\fR is stored in the destination register \fIR\fR\[char46] Else 0 is stored\[char46] The port security values to check are retrieved from the the \fBoutport\fR logical port\[char46] .IP This action should be used in the egress logical switch pipeline\[char46] .IP \fBExample:\fR \fBreg8[0\[char46]\[char46]7] = check_out_port_sec();\fR .TP \fBcommit_ecmp_nh(\fIipv6\fB);\fR \fBParameters\fR: IPv4/IPv6 traffic\[char46] .IP This action translates to an openflow \(dqlearn\(dq action that inserts two new flows in tables 76 and 77\[char46] .RS .IP \(bu Match on the the 5-tuple and the expected next-hop mac address in table 76: \fBnw_src=ip0\fR, \fBnw_dst=ip1\fR, \fBip_proto\fR,\fBtp_src=l4_port0\fR, \fBtp_dst=l4_port1\fR,\fBdl_src=ethaddr\fR and set \fBreg9[5]\fR\[char46] .IP \(bu Match on the 5-tuple in table 77: \fBnw_src=ip1\fR, \fBnw_dst=ip0\fR, \fBip_proto\fR, \fBtp_src=l4_port1\fR, \fBtp_dst=l4_port0\fR and set \fBreg9[5]\fR to 1 .RE .IP This action is applied if the packet arrives via ECMP route or if it is routed via an ECMP route .TP \fB\fIR\fB = check_ecmp_nh_mac();\fR This action checks if the packet under consideration matches any flow in table 76\[char46] If it is so, then the 1-bit destination register \fIR\fR is set to 1\[char46] .TP \fB\fIR\fB = check_ecmp_nh();\fR This action checks if the packet under consideration matches the any flow in table 77\[char46] If it is so, then the 1-bit destination register \fIR\fR is set to 1\[char46] .TP \fB commit_lb_aff(\fIvip\fB, \fIbackend\fB, \fIproto\fB, \fItimeout\fB); \fR \fBParameters\fR: load-balancer virtual ip:port \fIvip\fR, load-balancer backend ip:port \fIbackend\fR, load-balancer protocol \fIproto\fR, affinity timeout \fItimeout\fR\[char46] .IP This action translates to an openflow \(dqlearn\(dq action that inserts a new flow in table 78\[char46] .RS .IP \(bu Match on the 4-tuple in table 78: \fBnw_src=ip client\fR, \fBnw_dst=vip ip\fR, \fBip_proto\fR, \fBtp_dst=vip port\fR and set \fBreg9[6]\fR to 1, \fBreg4\fR and \fBreg8\fR to backend ip and port respectively\[char46] For IPv6 register \fBxxreg1\fR is used to store the backend ip\[char46] .RE .IP This action is applied for new connections received by a specific load-balacer with affinity timeout configured\[char46] .TP \fB\fIR\fB = chk_lb_aff();\fR This action checks if the packet under consideration matches any flow in table 78\[char46] If it is so, then the 1-bit destination register \fIR\fR is set to 1\[char46] .TP \fBsample(probability=\fIpackets\fB, \[char46]\[char46]\[char46])\fR This action causes the matched traffic to be sampled using IPFIX protocol\[char46] More information about how per-flow IPFIX sampling works in OVS can be found in \fBovs\-actions\fR(7) and \fBovs\-vswitchd\[char46]conf\[char46]db\fR(5)\[char46] .IP In order to reliably identify each sampled packet when it is received by the IPFIX collector, this action sets the content of the \fBObservationDomainID\fR and \fBObservationPointID\fR IPFIX fields (see argument description below)\[char46] .IP The following key-value arguments are supported: .RS .TP \fBprobability=\fR\fIpackets\fR The number of sampled packets out of 65535\[char46] It must be greater or equal to 1\[char46] .TP \fBcollector_set=\fR\fIid\fR The unsigned 32-bit integer identifier of the sample collector to send sampled packets to\[char46] It must match the value configured in the \fBFlow_Sample_Collector_Set\fR Table in OVS\[char46] Defaults to 0\[char46] .TP \fBobs_domain=\fR\fIid\fR An unsigned 8-bit integer that identifies the sampling application\[char46] It will be placed in the 8 most significant bits of the \fBObservationDomainID\fR field of IPFIX samples\[char46] The 24 less significant bits will be automatically filled in with the datapath key\[char46] Defaults to 0\[char46] .TP \fBobs_point=\fR\fIid\fR An unsigned 32-bit integer to be used as \fBObsservationPointID\fR or the string \fB@cookie\fR to indicate that the first 32 bits of the \fBLogical_Flow\fR\(cqs UUID shall be used instead\[char46] .RE .RE .IP "\fBtags\fR: map of string-string pairs" Key-value pairs that provide additional information to help ovn-controller processing the logical flow\[char46] Below are the tags used by ovn-controller\[char46] .RS .TP in_out_port In the logical flow\(cqs \(dqmatch\(dq column, if a logical port P is compared with \(dqinport\(dq and the logical flow is on a logical switch ingress pipeline, or if P is compared with \(dqoutport\(dq and the logical flow is on a logical switch egress pipeline, and the expression is combined with other expressions (if any) using the operator &&, then the port P should be added as the value in this tag\[char46] If there are multiple logical ports meeting this criteria, one of them can be added\[char46] ovn-controller uses this information to skip parsing flows that are not needed on the chassis\[char46] Failing to add the tag will affect efficiency, while adding wrong value will affect correctness\[char46] .RE .IP "\fBcontroller_meter\fR: optional string" The name of the meter in table \fBMeter\fR to be used for all packets that the logical flow might send to \fBovn\-controller\fR\[char46] .IP "\fBexternal_ids : stage-name\fR: optional string" Human-readable name for this flow\(cqs stage in the pipeline\[char46] .IP "\fBexternal_ids : stage-hint\fR: optional string, containing an uuid" UUID of a \fBOVN_Northbound\fR record that caused this logical flow to be created\[char46] Currently used only for attribute of logical flows to northbound \fBACL\fR records\[char46] .IP "\fBexternal_ids : source\fR: optional string" Source file and line number of the code that added this flow to the pipeline\[char46] .ST "Common Columns:" .PP The overall purpose of these columns is described under \fBCommon Columns\fR at the beginning of this document\[char46] .IP "\fBexternal_ids\fR: map of string-string pairs" .bp .SH "Logical_DP_Group TABLE" .PP .PP .PP Each row in this table represents a group of logical datapaths referenced by the \fBlogical_dp_group\fR column in the \fBLogical_Flow\fR table\[char46] .SS "Summary: .TQ 3.00in \fBdatapaths\fR set of weak reference to \fBDatapath_Binding\fRs .SS "Details: .IP "\fBdatapaths\fR: set of weak reference to \fBDatapath_Binding\fRs" List of \fBDatapath_Binding\fR entries\[char46] .bp .SH "Multicast_Group TABLE" .PP .PP .PP The rows in this table define multicast groups of logical ports\[char46] Multicast groups allow a single packet transmitted over a tunnel to a hypervisor to be delivered to multiple VMs on that hypervisor, which uses bandwidth more efficiently\[char46] .PP .PP Each row in this table defines a logical multicast group numbered \fBtunnel_key\fR within \fBdatapath\fR, whose logical ports are listed in the \fBports\fR column\[char46] .SS "Summary: .TQ 3.00in \fBdatapath\fR \fBDatapath_Binding\fR .TQ 3.00in \fBtunnel_key\fR integer, in range 32,768 to 65,535 .TQ 3.00in \fBname\fR string .TQ 3.00in \fBports\fR set of weak reference to \fBPort_Binding\fRs .SS "Details: .IP "\fBdatapath\fR: \fBDatapath_Binding\fR" The logical datapath in which the multicast group resides\[char46] .IP "\fBtunnel_key\fR: integer, in range 32,768 to 65,535" The value used to designate this logical egress port in tunnel encapsulations\[char46] An index forces the key to be unique within the \fBdatapath\fR\[char46] The unusual range ensures that multicast group IDs do not overlap with logical port IDs\[char46] .IP "\fBname\fR: string" The logical multicast group\(cqs name\[char46] An index forces the name to be unique within the \fBdatapath\fR\[char46] Logical flows in the ingress pipeline may output to the group just as for individual logical ports, by assigning the group\(cqs name to \fBoutport\fR and executing an \fBoutput\fR action\[char46] .IP Multicast group names and logical port names share a single namespace and thus should not overlap (but the database schema cannot enforce this)\[char46] To try to avoid conflicts, \fBovn\-northd\fR uses names that begin with \fB_MC_\fR\[char46] .IP "\fBports\fR: set of weak reference to \fBPort_Binding\fRs" The logical ports included in the multicast group\[char46] All of these ports must be in the \fBdatapath\fR logical datapath (but the database schema cannot enforce this)\[char46] .bp .SH "Mirror TABLE" .PP .PP .PP Each row in this table represents a mirror that can be used for port mirroring\[char46] These mirrors are referenced by the \fBmirror_rules\fR column in the \fBPort_Binding\fR table\[char46] .SS "Summary: .TQ 3.00in \fBname\fR string (must be unique within table) .TQ 3.00in \fBfilter\fR string, either \fBfrom\-lport\fR or \fBto\-lport\fR .TQ 3.00in \fBsink\fR string .TQ 3.00in \fBtype\fR string, either \fBerspan\fR or \fBgre\fR .TQ 3.00in \fBindex\fR integer .TQ 3.00in \fBexternal_ids\fR map of string-string pairs .SS "Details: .IP "\fBname\fR: string (must be unique within table)" Represents the name of the mirror\[char46] .IP "\fBfilter\fR: string, either \fBfrom\-lport\fR or \fBto\-lport\fR" The value of this field represents selection criteria of the mirror\[char46] .IP "\fBsink\fR: string" The value of this field represents the destination/sink of the mirror\[char46] .IP "\fBtype\fR: string, either \fBerspan\fR or \fBgre\fR" The value of this field represents the type of the tunnel used for sending the mirrored packets .IP "\fBindex\fR: integer" The value of this field represents the key/idx depending on the tunnel type configured .IP "\fBexternal_ids\fR: map of string-string pairs" See \fBExternal IDs\fR at the beginning of this document\[char46] .bp .SH "Meter TABLE" .PP .PP .PP Each row in this table represents a meter that can be used for QoS or rate-limiting\[char46] .SS "Summary: .TQ 3.00in \fBname\fR string (must be unique within table) .TQ 3.00in \fBunit\fR string, either \fBkbps\fR or \fBpktps\fR .TQ 3.00in \fBbands\fR set of 1 or more \fBMeter_Band\fRs .SS "Details: .IP "\fBname\fR: string (must be unique within table)" A name for this meter\[char46] .IP Names that begin with \(dq__\(dq (two underscores) are reserved for OVN internal use and should not be added manually\[char46] .IP "\fBunit\fR: string, either \fBkbps\fR or \fBpktps\fR" The unit for \fBrate\fR and \fBburst_rate\fR parameters in the \fBbands\fR entry\[char46] \fBkbps\fR specifies kilobits per second, and \fBpktps\fR specifies packets per second\[char46] .IP "\fBbands\fR: set of 1 or more \fBMeter_Band\fRs" The bands associated with this meter\[char46] Each band specifies a rate above which the band is to take the action \fBaction\fR\[char46] If multiple bands\(cq rates are exceeded, then the band with the highest rate among the exceeded bands is selected\[char46] .bp .SH "Meter_Band TABLE" .PP .PP .PP Each row in this table represents a meter band which specifies the rate above which the configured action should be applied\[char46] These bands are referenced by the \fBbands\fR column in the \fBMeter\fR table\[char46] .SS "Summary: .TQ 3.00in \fBaction\fR string, must be \fBdrop\fR .TQ 3.00in \fBrate\fR integer, in range 1 to 4,294,967,295 .TQ 3.00in \fBburst_size\fR integer, in range 0 to 4,294,967,295 .SS "Details: .IP "\fBaction\fR: string, must be \fBdrop\fR" The action to execute when this band matches\[char46] The only supported action is \fBdrop\fR\[char46] .IP "\fBrate\fR: integer, in range 1 to 4,294,967,295" The rate limit for this band, in kilobits per second or bits per second, depending on whether the parent \fBMeter\fR entry\(cqs \fBunit\fR column specified \fBkbps\fR or \fBpktps\fR\[char46] .IP "\fBburst_size\fR: integer, in range 0 to 4,294,967,295" The maximum burst allowed for the band in kilobits or packets, depending on whether \fBkbps\fR or \fBpktps\fR was selected in the parent \fBMeter\fR entry\(cqs \fBunit\fR column\[char46] If the size is zero, the switch is free to select some reasonable value depending on its configuration\[char46] .bp .SH "Datapath_Binding TABLE" .PP .PP .PP Each row in this table represents a logical datapath, which implements a logical pipeline among the ports in the \fBPort_Binding\fR table associated with it\[char46] In practice, the pipeline in a given logical datapath implements either a logical switch or a logical router\[char46] .PP .PP The main purpose of a row in this table is provide a physical binding for a logical datapath\[char46] A logical datapath does not have a physical location, so its physical binding information is limited: just \fBtunnel_key\fR\[char46] The rest of the data in this table does not affect packet forwarding\[char46] .SS "Summary: .TQ 3.00in \fBtunnel_key\fR integer, in range 1 to 16,777,215 (must be unique within table) .TQ 3.00in \fBload_balancers\fR set of uuids .TQ .25in \fIOVN_Northbound Relationship:\fR .RS .25in .TQ 2.75in \fBexternal_ids : logical-switch\fR optional string, containing an uuid .TQ 2.75in \fBexternal_ids : logical-router\fR optional string, containing an uuid .TQ 2.75in \fBexternal_ids : interconn-ts\fR optional string .TQ .25in \fINaming:\fR .RS .25in .TQ 2.50in \fBexternal_ids : name\fR optional string .TQ 2.50in \fBexternal_ids : name2\fR optional string .RE .RE .TQ .25in \fICommon Columns:\fR .RS .25in .TQ 2.75in \fBexternal_ids\fR map of string-string pairs .RE .SS "Details: .IP "\fBtunnel_key\fR: integer, in range 1 to 16,777,215 (must be unique within table)" The tunnel key value to which the logical datapath is bound\[char46] The \fBTunnel Encapsulation\fR section in \fBovn\-architecture\fR(7) describes how tunnel keys are constructed for each supported encapsulation\[char46] .IP "\fBload_balancers\fR: set of uuids" Not used anymore; kept for backwards compatibility of the schema\[char46] .ST "OVN_Northbound Relationship:" .PP .PP .PP Each row in \fBDatapath_Binding\fR is associated with some logical datapath\[char46] \fBovn\-northd\fR uses these keys to track the association of a logical datapath with concepts in the \fBOVN_Northbound\fR database\[char46] .IP "\fBexternal_ids : logical-switch\fR: optional string, containing an uuid" For a logical datapath that represents a logical switch, \fBovn\-northd\fR stores in this key the UUID of the corresponding \fBLogical_Switch\fR row in the \fBOVN_Northbound\fR database\[char46] .IP "\fBexternal_ids : logical-router\fR: optional string, containing an uuid" For a logical datapath that represents a logical router, \fBovn\-northd\fR stores in this key the UUID of the corresponding \fBLogical_Router\fR row in the \fBOVN_Northbound\fR database\[char46] .IP "\fBexternal_ids : interconn-ts\fR: optional string" For a logical datapath that represents a logical switch that represents a transit switch for interconnection, \fBovn\-northd\fR stores in this key the value of the same \fBinterconn\-ts\fR key of the \fBexternal_ids\fR column of the corresponding \fBLogical_Switch\fR row in the \fBOVN_Northbound\fR database\[char46] .ST "Naming:" .PP .PP .PP \fBovn\-northd\fR copies these from the name fields in the \fBOVN_Northbound\fR database, either from \fBname\fR and \fBexternal_ids:neutron:router_name\fR in the \fBLogical_Router\fR table or from \fBname\fR and \fBexternal_ids:neutron:network_name\fR in the \fBLogical_Switch\fR table\[char46] .IP "\fBexternal_ids : name\fR: optional string" A name for the logical datapath\[char46] .IP "\fBexternal_ids : name2\fR: optional string" Another name for the logical datapath\[char46] .ST "Common Columns:" .PP The overall purpose of these columns is described under \fBCommon Columns\fR at the beginning of this document\[char46] .IP "\fBexternal_ids\fR: map of string-string pairs" .bp .SH "Port_Binding TABLE" .PP .PP .PP Each row in this table binds a logical port to a realization\[char46] For most logical ports, this means binding to some physical location, for example by binding a logical port to a VIF that belongs to a VM running on a particular hypervisor\[char46] Other logical ports, such as logical patch ports, can be realized without a specific physical location, but their bindings are still expressed through rows in this table\[char46] .PP .PP For every \fBLogical_Switch_Port\fR record in \fBOVN_Northbound\fR database, \fBovn\-northd\fR creates a record in this table\[char46] \fBovn\-northd\fR populates and maintains every column except the \fBchassis\fR and \fBvirtual_parent\fR columns, which it leaves empty in new records\[char46] .PP .PP \fBovn\-controller\fR/\fBovn\-controller\-vtep\fR populates the \fBchassis\fR column for the records that identify the logical ports that are located on its hypervisor/gateway, which \fBovn\-controller\fR/\fBovn\-controller\-vtep\fR in turn finds out by monitoring the local hypervisor\(cqs Open_vSwitch database, which identifies logical ports via the conventions described in \fBIntegrationGuide\[char46]rst\fR\[char46] (The exceptions are for \fBPort_Binding\fR records with \fBtype\fR of \fBl3gateway\fR, whose locations are identified by \fBovn\-northd\fR via the \fBoptions:l3gateway\-chassis\fR column in this table\[char46] \fBovn\-controller\fR is still responsible to populate the \fBchassis\fR column\[char46]) .PP .PP \fBovn\-controller\fR also populates the \fBvirtual_parent\fR column of records whose \fBtype\fR is \fBvirtual\fR\[char46] .PP .PP When a chassis shuts down gracefully, it should clean up the \fBchassis\fR column that it previously had populated\[char46] (This is not critical because resources hosted on the chassis are equally unreachable regardless of whether their rows are present\[char46]) To handle the case where a VM is shut down abruptly on one chassis, then brought up again on a different one, \fBovn\-controller\fR/\fBovn\-controller\-vtep\fR must overwrite the \fBchassis\fR column with new information\[char46] .SS "Summary: .TQ .25in \fICore Features:\fR .RS .25in .TQ 2.75in \fBdatapath\fR \fBDatapath_Binding\fR .TQ 2.75in \fBlogical_port\fR string (must be unique within table) .TQ 2.75in \fBencap\fR optional weak reference to \fBEncap\fR .TQ 2.75in \fBadditional_encap\fR set of weak reference to \fBEncap\fRs .TQ 2.75in \fBchassis\fR optional weak reference to \fBChassis\fR .TQ 2.75in \fBadditional_chassis\fR set of weak reference to \fBChassis\fR .TQ 2.75in \fBgateway_chassis\fR set of \fBGateway_Chassis\fRes .TQ 2.75in \fBha_chassis_group\fR optional \fBHA_Chassis_Group\fR .TQ 2.75in \fBup\fR optional boolean .TQ 2.75in \fBtunnel_key\fR integer, in range 1 to 32,767 .TQ 2.75in \fBmac\fR set of strings .TQ 2.75in \fBport_security\fR set of strings .TQ 2.75in \fBtype\fR string .TQ 2.75in \fBrequested_chassis\fR optional weak reference to \fBChassis\fR .TQ 2.75in \fBrequested_additional_chassis\fR set of weak reference to \fBChassis\fR .RE .TQ 3.00in \fBmirror_rules\fR set of weak reference to \fBMirror\fRs .TQ .25in \fIPatch Options:\fR .RS .25in .TQ 2.75in \fBoptions : peer\fR optional string .TQ 2.75in \fBnat_addresses\fR set of strings .RE .TQ .25in \fIL3 Gateway Options:\fR .RS .25in .TQ 2.75in \fBoptions : peer\fR optional string .TQ 2.75in \fBoptions : l3gateway-chassis\fR optional string .TQ 2.75in \fBnat_addresses\fR set of strings .RE .TQ .25in \fILocalnet Options:\fR .RS .25in .TQ 2.75in \fBoptions : network_name\fR optional string .TQ 2.75in \fBtag\fR optional integer, in range 1 to 4,095 .RE .TQ .25in \fIL2 Gateway Options:\fR .RS .25in .TQ 2.75in \fBoptions : network_name\fR optional string .TQ 2.75in \fBoptions : l2gateway-chassis\fR optional string .TQ 2.75in \fBtag\fR optional integer, in range 1 to 4,095 .RE .TQ .25in \fIVTEP Options:\fR .RS .25in .TQ 2.75in \fBoptions : vtep-physical-switch\fR optional string .TQ 2.75in \fBoptions : vtep-logical-switch\fR optional string .RE .TQ .25in \fIVMI (or VIF) Options:\fR .RS .25in .TQ 2.75in \fBoptions : requested-chassis\fR optional string .TQ 2.75in \fBoptions : activation-strategy\fR optional string .TQ 2.75in \fBoptions : additional-chassis-activated\fR optional string .TQ 2.75in \fBoptions : iface-id-ver\fR optional string .TQ 2.75in \fBoptions : qos_min_rate\fR optional string .TQ 2.75in \fBoptions : qos_max_rate\fR optional string .TQ 2.75in \fBoptions : qos_burst\fR optional string .TQ 2.75in \fBoptions : qdisc_queue_id\fR optional string, containing an integer, in range 1 to 61,440 .RE .TQ .25in \fIDistributed Gateway Port Options:\fR .RS .25in .TQ 2.75in \fBoptions : chassis-redirect-port\fR optional string .RE .TQ .25in \fIChassis Redirect Options:\fR .RS .25in .TQ 2.75in \fBoptions : distributed-port\fR optional string .TQ 2.75in \fBoptions : redirect-type\fR optional string .TQ 2.75in \fBoptions : always-redirect\fR optional string .RE .TQ .25in \fINested Containers:\fR .RS .25in .TQ 2.75in \fBparent_port\fR optional string .TQ 2.75in \fBtag\fR optional integer, in range 1 to 4,095 .RE .TQ .25in \fIVirtual ports:\fR .RS .25in .TQ 2.75in \fBvirtual_parent\fR optional string .RE .TQ .25in \fINaming:\fR .RS .25in .TQ 2.75in \fBexternal_ids : name\fR optional string .RE .TQ .25in \fICommon Columns:\fR .RS .25in .TQ 2.75in \fBexternal_ids\fR map of string-string pairs .RE .SS "Details: .ST "Core Features:" .PP .IP "\fBdatapath\fR: \fBDatapath_Binding\fR" The logical datapath to which the logical port belongs\[char46] .IP "\fBlogical_port\fR: string (must be unique within table)" A logical port\[char46] For a logical switch port, this is taken from \fBname\fR in the OVN_Northbound database\(cqs \fBLogical_Switch_Port\fR table\[char46] For a logical router port, this is taken from \fBname\fR in the OVN_Northbound database\(cqs \fBLogical_Router_port\fR table\[char46] (This means that logical switch ports and router port names must not share names in an OVN deployment\[char46]) OVN does not prescribe a particular format for the logical port ID\[char46] .IP "\fBencap\fR: optional weak reference to \fBEncap\fR" Points to preferred encapsulation configuration to transmit logical dataplane packets to this chassis\[char46] The entry is reference to a \fBEncap\fR record\[char46] .IP "\fBadditional_encap\fR: set of weak reference to \fBEncap\fRs" Points to preferred encapsulation configuration to transmit logical dataplane packets to this additional chassis\[char46] The entry is reference to a \fBEncap\fR record\[char46] See also \fBadditional_chassis\fR\[char46] .IP "\fBchassis\fR: optional weak reference to \fBChassis\fR" The meaning of this column depends on the value of the \fBtype\fR column\[char46] This is the meaning for each \fBtype\fR .RS .TP (empty string) The physical location of the logical port\[char46] To successfully identify a chassis, this column must be a \fBChassis\fR record\[char46] This is populated by \fBovn\-controller\fR\[char46] .TP vtep The physical location of the hardware_vtep gateway\[char46] To successfully identify a chassis, this column must be a \fBChassis\fR record\[char46] This is populated by \fBovn\-controller\-vtep\fR\[char46] .TP localnet Always empty\[char46] A localnet port is realized on every chassis that has connectivity to the corresponding physical network\[char46] .TP localport Always empty\[char46] A localport port is present on every chassis\[char46] .TP l3gateway The physical location of the L3 gateway\[char46] To successfully identify a chassis, this column must be a \fBChassis\fR record\[char46] This is populated by \fBovn\-controller\fR based on the value of the \fBoptions:l3gateway\-chassis\fR column in this table\[char46] .TP l2gateway The physical location of this L2 gateway\[char46] To successfully identify a chassis, this column must be a \fBChassis\fR record\[char46] This is populated by \fBovn\-controller\fR based on the value of the \fBoptions:l2gateway\-chassis\fR column in this table\[char46] .RE .IP "\fBadditional_chassis\fR: set of weak reference to \fBChassis\fR" The meaning of this column is the same as for the \fBchassis\fR\[char46] The column is used to track an additional physical location of the logical port\[char46] Used with regular (empty \fBtype\fR) port bindings\[char46] .IP "\fBgateway_chassis\fR: set of \fBGateway_Chassis\fRes" A list of \fBGateway_Chassis\fR\[char46] .IP This should only be populated for ports with \fBtype\fR set to \fBchassisredirect\fR\[char46] This column defines the list of chassis used as gateways where traffic will be redirected through\[char46] .IP "\fBha_chassis_group\fR: optional \fBHA_Chassis_Group\fR" This should only be populated for ports with \fBtype\fR set to \fBchassisredirect\fR\[char46] This column defines the HA chassis group with a list of HA chassis used as gateways where traffic will be redirected through\[char46] .IP "\fBup\fR: optional boolean" This is set to \fBtrue\fR whenever all OVS flows required by this Port_Binding have been installed\[char46] This is populated by \fBovn\-controller\fR\[char46] .IP "\fBtunnel_key\fR: integer, in range 1 to 32,767" A number that represents the logical port in the key (e\[char46]g\[char46] STT key or Geneve TLV) field carried within tunnel protocol packets\[char46] .IP The tunnel ID must be unique within the scope of a logical datapath\[char46] .IP "\fBmac\fR: set of strings" This column is a misnomer as it may contain MAC addresses and IP addresses\[char46] It is copied from the \fBaddresses\fR column in the \fBLogical_Switch_Port\fR table in the Northbound database\[char46] It follows the same format as that column\[char46] .IP "\fBport_security\fR: set of strings" This column controls the addresses from which the host attached to the logical port (``the host\(cq\(cq) is allowed to send packets and to which it is allowed to receive packets\[char46] If this column is empty, all addresses are permitted\[char46] .IP It is copied from the \fBport_security\fR column in the \fBLogical_Switch_Port\fR table in the Northbound database\[char46] It follows the same format as that column\[char46] .IP "\fBtype\fR: string" A type for this logical port\[char46] Logical ports can be used to model other types of connectivity into an OVN logical switch\[char46] The following types are defined: .RS .TP (empty string) VM (or VIF) interface\[char46] .TP \fBpatch\fR One of a pair of logical ports that act as if connected by a patch cable\[char46] Useful for connecting two logical datapaths, e\[char46]g\[char46] to connect a logical router to a logical switch or to another logical router\[char46] .TP \fBl3gateway\fR One of a pair of logical ports that act as if connected by a patch cable across multiple chassis\[char46] Useful for connecting a logical switch with a Gateway router (which is only resident on a particular chassis)\[char46] .TP \fBlocalnet\fR A connection to a locally accessible network from \fBovn\-controller\fR instances that have a corresponding bridge mapping\[char46] A logical switch can have multiple \fBlocalnet\fR ports attached\[char46] This type is used to model direct connectivity to existing networks\[char46] In this case, each chassis should have a mapping for one of the physical networks only\[char46] Note: nothing said above implies that a chassis cannot be plugged to multiple physical networks as long as they belong to different switches\[char46] .TP \fBlocalport\fR A connection to a local VIF\[char46] Traffic that arrives on a \fBlocalport\fR is never forwarded over a tunnel to another chassis\[char46] These ports are present on every chassis and have the same address in all of them\[char46] This is used to model connectivity to local services that run on every hypervisor\[char46] .TP \fBl2gateway\fR An L2 connection to a physical network\[char46] The chassis this \fBPort_Binding\fR is bound to will serve as an L2 gateway to the network named by \fBoptions\fR:\fBnetwork_name\fR\[char46] .TP \fBvtep\fR A port to a logical switch on a VTEP gateway chassis\[char46] In order to get this port correctly recognized by the OVN controller, the \fBoptions\fR:\fBvtep\-physical\-switch\fR and \fBoptions\fR:\fBvtep\-logical\-switch\fR must also be defined\[char46] .TP \fBchassisredirect\fR A logical port that represents a particular instance, bound to a specific chassis, of an otherwise distributed parent port (e\[char46]g\[char46] of type \fBpatch\fR)\[char46] A \fBchassisredirect\fR port should never be used as an \fBinport\fR\[char46] When an ingress pipeline sets the \fBoutport\fR, it may set the value to a logical port of type \fBchassisredirect\fR\[char46] This will cause the packet to be directed to a specific chassis to carry out the egress pipeline\[char46] At the beginning of the egress pipeline, the \fBoutport\fR will be reset to the value of the distributed port\[char46] .TP \fBvirtual\fR Represents a logical port with an \fBvirtual ip\fR\[char46] This \fBvirtual ip\fR can be configured on a logical port (which is referred as virtual parent)\[char46] .RE .IP "\fBrequested_chassis\fR: optional weak reference to \fBChassis\fR" This column exists so that the ovn-controller can effectively monitor all \fBPort_Binding\fR records destined for it, and is a supplement to the \fBoptions:requested-chassis\fR option\[char46] The option is still required so that the ovn-controller can check the CMS intent when the chassis pointed to does not currently exist, which for example occurs when the ovn-controller is stopped without passing the \-restart argument\[char46] This column must be a \fBChassis\fR record\[char46] This is populated by \fBovn\-northd\fR when the \fBoptions:requested-chassis\fR is defined and contains a string matching the name or hostname of an existing chassis\[char46] See also \fBrequested_additional_chassis\fR\[char46] .IP "\fBrequested_additional_chassis\fR: set of weak reference to \fBChassis\fR" This column exists so that the ovn-controller can effectively monitor all \fBPort_Binding\fR records destined for it, and is a supplement to the \fBoptions:requested-chassis\fR option when multiple chassis are listed\[char46] This column must be a list of \fBChassis\fR records\[char46] This is populated by \fBovn\-northd\fR when the \fBoptions:requested-chassis\fR is defined as a list of chassis names or hostnames\[char46] See also \fBrequested_chassis\fR\[char46] .IP "\fBmirror_rules\fR: set of weak reference to \fBMirror\fRs" Mirror rules that apply to the port binding\[char46] Please see the \fBMirror\fR table\[char46] .ST "Patch Options:" .PP .PP .PP These options apply to logical ports with \fBtype\fR of \fBpatch\fR\[char46] .IP "\fBoptions : peer\fR: optional string" The \fBlogical_port\fR in the \fBPort_Binding\fR record for the other side of the patch\[char46] The named \fBlogical_port\fR must specify this \fBlogical_port\fR in its own \fBpeer\fR option\[char46] That is, the two patch logical ports must have reversed \fBlogical_port\fR and \fBpeer\fR values\[char46] .IP "\fBnat_addresses\fR: set of strings" MAC address followed by a list of SNAT and DNAT external IP addresses, followed by \fBis_chassis_resident(\(dq\fIlport\fB\(dq)\fR, where \fIlport\fR is the name of a logical port on the same chassis where the corresponding NAT rules are applied\[char46] This is used to send gratuitous ARPs for SNAT and DNAT external IP addresses via \fBlocalnet\fR, from the chassis where \fIlport\fR resides\[char46] Example: \fB80:fa:5b:06:72:b7 158\[char46]36\[char46]44\[char46]22 158\[char46]36\[char46]44\[char46]24 is_chassis_resident(\(dqfoo1\(dq)\fR\[char46] This would result in generation of gratuitous ARPs for IP addresses 158\[char46]36\[char46]44\[char46]22 and 158\[char46]36\[char46]44\[char46]24 with a MAC address of 80:fa:5b:06:72:b7 from the chassis where the logical port \(dqfoo1\(dq resides\[char46] .ST "L3 Gateway Options:" .PP .PP .PP These options apply to logical ports with \fBtype\fR of \fBl3gateway\fR\[char46] .IP "\fBoptions : peer\fR: optional string" The \fBlogical_port\fR in the \fBPort_Binding\fR record for the other side of the \(cql3gateway\(cq port\[char46] The named \fBlogical_port\fR must specify this \fBlogical_port\fR in its own \fBpeer\fR option\[char46] That is, the two \(cql3gateway\(cq logical ports must have reversed \fBlogical_port\fR and \fBpeer\fR values\[char46] .IP "\fBoptions : l3gateway-chassis\fR: optional string" The \fBchassis\fR in which the port resides\[char46] .IP "\fBnat_addresses\fR: set of strings" MAC address of the \fBl3gateway\fR port followed by a list of SNAT and DNAT external IP addresses\[char46] This is used to send gratuitous ARPs for SNAT and DNAT external IP addresses via \fBlocalnet\fR\[char46] Example: \fB80:fa:5b:06:72:b7 158\[char46]36\[char46]44\[char46]22 158\[char46]36\[char46]44\[char46]24\fR\[char46] This would result in generation of gratuitous ARPs for IP addresses 158\[char46]36\[char46]44\[char46]22 and 158\[char46]36\[char46]44\[char46]24 with a MAC address of 80:fa:5b:06:72:b7\[char46] This is used in OVS version 2\[char46]8 and later versions\[char46] .ST "Localnet Options:" .PP .PP .PP These options apply to logical ports with \fBtype\fR of \fBlocalnet\fR\[char46] .IP "\fBoptions : network_name\fR: optional string" Required\[char46] \fBovn\-controller\fR uses the configuration entry \fBovn\-bridge\-mappings\fR to determine how to connect to this network\[char46] \fBovn\-bridge\-mappings\fR is a list of network names mapped to a local OVS bridge that provides access to that network\[char46] An example of configuring \fBovn\-bridge\-mappings\fR would be: .IP .nf \fB$ ovs\-vsctl set open \[char46] external\-ids:ovn\-bridge\-mappings=physnet1:br\-eth0,physnet2:br\-eth1\fR .fi .IP When a logical switch has a \fBlocalnet\fR port attached, every chassis that may have a local vif attached to that logical switch must have a bridge mapping configured to reach that \fBlocalnet\fR\[char46] Traffic that arrives on a \fBlocalnet\fR port is never forwarded over a tunnel to another chassis\[char46] If there are multiple \fBlocalnet\fR ports in a logical switch, each chassis should only have a single bridge mapping for one of the physical networks\[char46] Note: In case of multiple \fBlocalnet\fR ports, to provide interconnectivity between all VIFs located on different chassis with different fabric connectivity, the fabric should implement some form of routing between the segments\[char46] .IP "\fBtag\fR: optional integer, in range 1 to 4,095" If set, indicates that the port represents a connection to a specific VLAN on a locally accessible network\[char46] The VLAN ID is used to match incoming traffic and is also added to outgoing traffic\[char46] .ST "L2 Gateway Options:" .PP .PP .PP These options apply to logical ports with \fBtype\fR of \fBl2gateway\fR\[char46] .IP "\fBoptions : network_name\fR: optional string" Required\[char46] \fBovn\-controller\fR uses the configuration entry \fBovn\-bridge\-mappings\fR to determine how to connect to this network\[char46] \fBovn\-bridge\-mappings\fR is a list of network names mapped to a local OVS bridge that provides access to that network\[char46] An example of configuring \fBovn\-bridge\-mappings\fR would be: .IP .nf \fB$ ovs\-vsctl set open \[char46] external\-ids:ovn\-bridge\-mappings=physnet1:br\-eth0,physnet2:br\-eth1\fR .fi .IP When a logical switch has a \fBl2gateway\fR port attached, the chassis that the \fBl2gateway\fR port is bound to must have a bridge mapping configured to reach the network identified by \fBnetwork_name\fR\[char46] .IP "\fBoptions : l2gateway-chassis\fR: optional string" Required\[char46] The \fBchassis\fR in which the port resides\[char46] .IP "\fBtag\fR: optional integer, in range 1 to 4,095" If set, indicates that the gateway is connected to a specific VLAN on the physical network\[char46] The VLAN ID is used to match incoming traffic and is also added to outgoing traffic\[char46] .ST "VTEP Options:" .PP .PP .PP These options apply to logical ports with \fBtype\fR of \fBvtep\fR\[char46] .IP "\fBoptions : vtep-physical-switch\fR: optional string" Required\[char46] The name of the VTEP gateway\[char46] .IP "\fBoptions : vtep-logical-switch\fR: optional string" Required\[char46] A logical switch name connected by the VTEP gateway\[char46] Must be set when \fBtype\fR is \fBvtep\fR\[char46] .ST "VMI (or VIF) Options:" .PP .PP .PP These options apply to logical ports with \fBtype\fR having (empty string) .IP "\fBoptions : requested-chassis\fR: optional string" If set, identifies a specific chassis (by name or hostname) that is allowed to bind this port\[char46] Using this option will prevent thrashing between two chassis trying to bind the same port during a live migration\[char46] It can also prevent similar thrashing due to a mis-configuration, if a port is accidentally created on more than one chassis\[char46] .IP If set to a comma separated list, the first entry identifies the main chassis and the rest are one or more additional chassis that are allowed to bind the same port\[char46] .IP When multiple chassis are set for the port, and the logical switch is connected to an external network through a \fBlocalnet\fR port, tunneling is enforced for the port to guarantee delivery of packets directed to the port to all its locations\[char46] This has MTU implications because the network used for tunneling must have MTU larger than \fBlocalnet\fR for stable connectivity\[char46] .IP "\fBoptions : activation-strategy\fR: optional string" If used with multiple chassis set in \fBrequested-chassis\fR, specifies an activation strategy for all additional chassis\[char46] By default, no activation strategy is used, meaning additional port locations are immediately available for use\[char46] When set to \(dqrarp\(dq, the port is blocked for ingress and egress communication until a RARP packet is sent from a new location\[char46] The \(dqrarp\(dq strategy is useful in live migration scenarios for virtual machines\[char46] .IP "\fBoptions : additional-chassis-activated\fR: optional string" When \fBactivation-strategy\fR is set, this option indicates that the port was activated using the strategy specified\[char46] .IP "\fBoptions : iface-id-ver\fR: optional string" If set, this port will be bound by \fBovn\-controller\fR only if this same key and value is configured in the \fBexternal_ids\fR column in the Open_vSwitch database\(cqs \fBInterface\fR table\[char46] .IP "\fBoptions : qos_min_rate\fR: optional string" If set, indicates the minimum guaranteed rate available for data sent from this interface, in bit/s\[char46] .IP "\fBoptions : qos_max_rate\fR: optional string" If set, indicates the maximum rate for data sent from this interface, in bit/s\[char46] The traffic will be shaped according to this limit\[char46] .IP "\fBoptions : qos_burst\fR: optional string" If set, indicates the maximum burst size for data sent from this interface, in bits\[char46] .IP "\fBoptions : qdisc_queue_id\fR: optional string, containing an integer, in range 1 to 61,440" Indicates the queue number on the physical device\[char46] This is same as the \fBqueue_id\fR used in OpenFlow in \fBstruct ofp_action_enqueue\fR\[char46] .ST "Distributed Gateway Port Options:" .PP .PP .PP These options apply to the distributed parent ports of logical ports with \fBtype\fR of \fBchasssisredirect\fR\[char46] .IP "\fBoptions : chassis-redirect-port\fR: optional string" The name of the chassis redirect port derived from this port if this port is a distributed parent of a chassis redirect port\[char46] .ST "Chassis Redirect Options:" .PP .PP .PP These options apply to logical ports with \fBtype\fR of \fBchassisredirect\fR\[char46] .IP "\fBoptions : distributed-port\fR: optional string" The name of the distributed port for which this \fBchassisredirect\fR port represents a particular instance\[char46] .IP "\fBoptions : redirect-type\fR: optional string" The value is copied from the column \fBoptions\fR in the OVN_Northbound database\(cqs \fBLogical_Router_Port\fR table for the distributed parent of this port\[char46] .IP "\fBoptions : always-redirect\fR: optional string" A boolean option that is set to true if the distributed parent of this chassis redirect port does not need distributed processing\[char46] .ST "Nested Containers:" .PP .PP .PP These columns support containers nested within a VM\[char46] Specifically, they are used when \fBtype\fR is empty and \fBlogical_port\fR identifies the interface of a container spawned inside a VM\[char46] They are empty for containers or VMs that run directly on a hypervisor\[char46] .IP "\fBparent_port\fR: optional string" This is taken from \fBparent_name\fR in the OVN_Northbound database\(cqs \fBLogical_Switch_Port\fR table\[char46] .IP "\fBtag\fR: optional integer, in range 1 to 4,095" Identifies the VLAN tag in the network traffic associated with that container\(cqs network interface\[char46] .IP This column is used for a different purpose when \fBtype\fR is \fBlocalnet\fR (see \fBLocalnet Options\fR, above) or \fBl2gateway\fR (see \fBL2 Gateway Options\fR, above)\[char46] .ST "Virtual ports:" .PP .IP "\fBvirtual_parent\fR: optional string" This column is set by \fBovn\-controller\fR with one of the value from the \fBoptions:virtual-parents\fR in the OVN_Northbound database\(cqs \fBLogical_Switch_Port\fR table when the OVN action \fBbind_vport\fR is executed\[char46] \fBovn\-controller\fR also sets the \fBchassis\fR column when it executes this action with its chassis id\[char46] .IP \fBovn\-controller\fR sets this column only if the \fBtype\fR is \(dqvirtual\(dq\[char46] .ST "Naming:" .PP .IP "\fBexternal_ids : name\fR: optional string" For a logical switch port, \fBovn\-northd\fR copies this from \fBexternal_ids:neutron:port_name\fR in the \fBLogical_Switch_Port\fR table in the OVN_Northbound database, if it is a nonempty string\[char46] .IP For a logical switch port, \fBovn\-northd\fR does not currently set this key\[char46] .ST "Common Columns:" .PP .IP "\fBexternal_ids\fR: map of string-string pairs" See \fBExternal IDs\fR at the beginning of this document\[char46] .IP The \fBovn\-northd\fR program populates this column with all entries into the \fBexternal_ids\fR column of the \fBLogical_Switch_Port\fR and \fBLogical_Router_Port\fR tables of the \fBOVN_Northbound\fR database\[char46] .bp .SH "MAC_Binding TABLE" .PP .PP .PP Each row in this table specifies a binding from an IP address to an Ethernet address that has been discovered through ARP (for IPv4) or neighbor discovery (for IPv6)\[char46] This table is primarily used to discover bindings on physical networks, because IP-to-MAC bindings for virtual machines are usually populated statically into the \fBPort_Binding\fR table\[char46] .PP .PP This table expresses a functional relationship: \fBMAC_Binding\fR(\fBlogical_port\fR, \fBip\fR) = \fBmac\fR\[char46] .PP .PP In outline, the lifetime of a logical router\(cqs MAC binding looks like this: .RS .IP 1. .4in On hypervisor 1, a logical router determines that a packet should be forwarded to IP address \fIA\fR on one of its router ports\[char46] It uses its logical flow table to determine that \fIA\fR lacks a static IP-to-MAC binding and the \fBget_arp\fR action to determine that it lacks a dynamic IP-to-MAC binding\[char46] .IP 2. .4in Using an OVN logical \fBarp\fR action, the logical router generates and sends a broadcast ARP request to the router port\[char46] It drops the IP packet\[char46] .IP 3. .4in The logical switch attached to the router port delivers the ARP request to all of its ports\[char46] (It might make sense to deliver it only to ports that have no static IP-to-MAC bindings, but this could also be surprising behavior\[char46]) .IP 4. .4in A host or VM on hypervisor 2 (which might be the same as hypervisor 1) attached to the logical switch owns the IP address in question\[char46] It composes an ARP reply and unicasts it to the logical router port\(cqs Ethernet address\[char46] .IP 5. .4in The logical switch delivers the ARP reply to the logical router port\[char46] .IP 6. .4in The logical router flow table executes a \fBput_arp\fR action\[char46] To record the IP-to-MAC binding, \fBovn\-controller\fR adds a row to the \fBMAC_Binding\fR table\[char46] .IP 7. .4in On hypervisor 1, \fBovn\-controller\fR receives the updated \fBMAC_Binding\fR table from the OVN southbound database\[char46] The next packet destined to \fIA\fR through the logical router is sent directly to the bound Ethernet address\[char46] .RE .SS "Summary: .TQ 3.00in \fBlogical_port\fR string .TQ 3.00in \fBip\fR string .TQ 3.00in \fBmac\fR string .TQ 3.00in \fBtimestamp\fR integer .TQ 3.00in \fBdatapath\fR \fBDatapath_Binding\fR .SS "Details: .IP "\fBlogical_port\fR: string" The logical port on which the binding was discovered\[char46] .IP "\fBip\fR: string" The bound IP address\[char46] .IP "\fBmac\fR: string" The Ethernet address to which the IP is bound\[char46] .IP "\fBtimestamp\fR: integer" The timestamp in msec when the MAC binding was added or updated\[char46] Records that existed before this column will have 0\[char46] .IP "\fBdatapath\fR: \fBDatapath_Binding\fR" The logical datapath to which the logical port belongs\[char46] .bp .SH "DHCP_Options TABLE" .PP .PP .PP Each row in this table stores the DHCP Options supported by native OVN DHCP\[char46] \fBovn\-northd\fR populates this table with the supported DHCP options\[char46] \fBovn\-controller\fR looks up this table to get the DHCP codes of the DHCP options defined in the \(dqput_dhcp_opts\(dq action\[char46] Please refer to the RFC 2132 \fB\(dqhttps://tools\[char46]ietf\[char46]org/html/rfc2132\(dq\fR for the possible list of DHCP options that can be defined here\[char46] .SS "Summary: .TQ 3.00in \fBname\fR string .TQ 3.00in \fBcode\fR integer, in range 0 to 254 .TQ 3.00in \fBtype\fR string, one of \fBbool\fR, \fBdomains\fR, \fBhost_id\fR, \fBipv4\fR, \fBstatic_routes\fR, \fBstr\fR, \fBuint16\fR, \fBuint32\fR, or \fBuint8\fR .SS "Details: .IP "\fBname\fR: string" Name of the DHCP option\[char46] .IP Example\[char46] name=\(dqrouter\(dq .IP "\fBcode\fR: integer, in range 0 to 254" DHCP option code for the DHCP option as defined in the RFC 2132\[char46] .IP Example\[char46] code=3 .IP "\fBtype\fR: string, one of \fBbool\fR, \fBdomains\fR, \fBhost_id\fR, \fBipv4\fR, \fBstatic_routes\fR, \fBstr\fR, \fBuint16\fR, \fBuint32\fR, or \fBuint8\fR" Data type of the DHCP option code\[char46] .RS .TP \fBvalue: bool\fR This indicates that the value of the DHCP option is a bool\[char46] .IP Example\[char46] \(dqname=ip_forward_enable\(dq, \(dqcode=19\(dq, \(dqtype=bool\(dq\[char46] .IP put_dhcp_opts(\[char46]\[char46]\[char46], ip_forward_enable = 1,\[char46]\[char46]\[char46]) .TP \fBvalue: uint8\fR This indicates that the value of the DHCP option is an unsigned int8 (8 bits) .IP Example\[char46] \(dqname=default_ttl\(dq, \(dqcode=23\(dq, \(dqtype=uint8\(dq\[char46] .IP put_dhcp_opts(\[char46]\[char46]\[char46], default_ttl = 50,\[char46]\[char46]\[char46]) .TP \fBvalue: uint16\fR This indicates that the value of the DHCP option is an unsigned int16 (16 bits)\[char46] .IP Example\[char46] \(dqname=mtu\(dq, \(dqcode=26\(dq, \(dqtype=uint16\(dq\[char46] .IP put_dhcp_opts(\[char46]\[char46]\[char46], mtu = 1450,\[char46]\[char46]\[char46]) .TP \fBvalue: uint32\fR This indicates that the value of the DHCP option is an unsigned int32 (32 bits)\[char46] .IP Example\[char46] \(dqname=lease_time\(dq, \(dqcode=51\(dq, \(dqtype=uint32\(dq\[char46] .IP put_dhcp_opts(\[char46]\[char46]\[char46], lease_time = 86400,\[char46]\[char46]\[char46]) .TP \fBvalue: ipv4\fR This indicates that the value of the DHCP option is an IPv4 address or addresses\[char46] .IP Example\[char46] \(dqname=router\(dq, \(dqcode=3\(dq, \(dqtype=ipv4\(dq\[char46] .IP put_dhcp_opts(\[char46]\[char46]\[char46], router = 10\[char46]0\[char46]0\[char46]1,\[char46]\[char46]\[char46]) .IP Example\[char46] \(dqname=dns_server\(dq, \(dqcode=6\(dq, \(dqtype=ipv4\(dq\[char46] .IP put_dhcp_opts(\[char46]\[char46]\[char46], dns_server = {8\[char46]8\[char46]8\[char46]8 7\[char46]7\[char46]7\[char46]7},\[char46]\[char46]\[char46]) .TP \fBvalue: static_routes\fR This indicates that the value of the DHCP option contains a pair of IPv4 route and next hop addresses\[char46] .IP Example\[char46] \(dqname=classless_static_route\(dq, \(dqcode=121\(dq, \(dqtype=static_routes\(dq\[char46] .IP put_dhcp_opts(\[char46]\[char46]\[char46], classless_static_route = {30\[char46]0\[char46]0\[char46]0/24,10\[char46]0\[char46]0\[char46]4,0\[char46]0\[char46]0\[char46]0/0,10\[char46]0\[char46]0\[char46]1}\[char46]\[char46]\[char46]) .TP \fBvalue: str\fR This indicates that the value of the DHCP option is a string\[char46] .IP Example\[char46] \(dqname=host_name\(dq, \(dqcode=12\(dq, \(dqtype=str\(dq\[char46] .TP \fBvalue: host_id\fR This indicates that the value of the DHCP option is a host_id\[char46] It can either be a host_name or an IP address\[char46] .IP Example\[char46] \(dqname=tftp_server\(dq, \(dqcode=66\(dq, \(dqtype=host_id\(dq\[char46] .TP \fBvalue: domains\fR This indicates that the value of the DHCP option is a domain name or a comma separated list of domain names\[char46] .IP Example\[char46] \(dqname=domain_search_list\(dq, \(dqcode=119\(dq, \(dqtype=domains\(dq\[char46] .RE .bp .SH "DHCPv6_Options TABLE" .PP .PP .PP Each row in this table stores the DHCPv6 Options supported by native OVN DHCPv6\[char46] \fBovn\-northd\fR populates this table with the supported DHCPv6 options\[char46] \fBovn\-controller\fR looks up this table to get the DHCPv6 codes of the DHCPv6 options defined in the \fBput_dhcpv6_opts\fR action\[char46] Please refer to RFC 3315 and RFC 3646 for the list of DHCPv6 options that can be defined here\[char46] .SS "Summary: .TQ 3.00in \fBname\fR string .TQ 3.00in \fBcode\fR integer, in range 0 to 254 .TQ 3.00in \fBtype\fR string, one of \fBipv6\fR, \fBmac\fR, or \fBstr\fR .SS "Details: .IP "\fBname\fR: string" Name of the DHCPv6 option\[char46] .IP Example\[char46] name=\(dqia_addr\(dq .IP "\fBcode\fR: integer, in range 0 to 254" DHCPv6 option code for the DHCPv6 option as defined in the appropriate RFC\[char46] .IP Example\[char46] code=3 .IP "\fBtype\fR: string, one of \fBipv6\fR, \fBmac\fR, or \fBstr\fR" Data type of the DHCPv6 option code\[char46] .RS .TP \fBvalue: ipv6\fR This indicates that the value of the DHCPv6 option is an IPv6 address(es)\[char46] .IP Example\[char46] \(dqname=ia_addr\(dq, \(dqcode=5\(dq, \(dqtype=ipv6\(dq\[char46] .IP put_dhcpv6_opts(\[char46]\[char46]\[char46], ia_addr = ae70::4,\[char46]\[char46]\[char46]) .TP \fBvalue: str\fR This indicates that the value of the DHCPv6 option is a string\[char46] .IP Example\[char46] \(dqname=domain_search\(dq, \(dqcode=24\(dq, \(dqtype=str\(dq\[char46] .IP put_dhcpv6_opts(\[char46]\[char46]\[char46], domain_search = ovn\[char46]domain,\[char46]\[char46]\[char46]) .TP \fBvalue: mac\fR This indicates that the value of the DHCPv6 option is a MAC address\[char46] .IP Example\[char46] \(dqname=server_id\(dq, \(dqcode=2\(dq, \(dqtype=mac\(dq\[char46] .IP put_dhcpv6_opts(\[char46]\[char46]\[char46], server_id = 01:02:03:04L05:06,\[char46]\[char46]\[char46]) .RE .bp .SH "Connection TABLE" .PP .PP .PP Configuration for a database connection to an Open vSwitch database (OVSDB) client\[char46] .PP .PP This table primarily configures the Open vSwitch database server (\fBovsdb\-server\fR)\[char46] .PP .PP The Open vSwitch database server can initiate and maintain active connections to remote clients\[char46] It can also listen for database connections\[char46] .SS "Summary: .TQ .25in \fICore Features:\fR .RS .25in .TQ 2.75in \fBtarget\fR string (must be unique within table) .TQ 2.75in \fBread_only\fR boolean .TQ 2.75in \fBrole\fR string .RE .TQ .25in \fIClient Failure Detection and Handling:\fR .RS .25in .TQ 2.75in \fBmax_backoff\fR optional integer, at least 1,000 .TQ 2.75in \fBinactivity_probe\fR optional integer .RE .TQ .25in \fIStatus:\fR .RS .25in .TQ 2.75in \fBis_connected\fR boolean .TQ 2.75in \fBstatus : last_error\fR optional string .TQ 2.75in \fBstatus : state\fR optional string, one of \fBACTIVE\fR, \fBBACKOFF\fR, \fBCONNECTING\fR, \fBIDLE\fR, or \fBVOID\fR .TQ 2.75in \fBstatus : sec_since_connect\fR optional string, containing an integer, at least 0 .TQ 2.75in \fBstatus : sec_since_disconnect\fR optional string, containing an integer, at least 0 .TQ 2.75in \fBstatus : locks_held\fR optional string .TQ 2.75in \fBstatus : locks_waiting\fR optional string .TQ 2.75in \fBstatus : locks_lost\fR optional string .TQ 2.75in \fBstatus : n_connections\fR optional string, containing an integer, at least 2 .TQ 2.75in \fBstatus : bound_port\fR optional string, containing an integer .RE .TQ .25in \fICommon Columns:\fR .RS .25in .TQ 2.75in \fBexternal_ids\fR map of string-string pairs .TQ 2.75in \fBother_config\fR map of string-string pairs .RE .SS "Details: .ST "Core Features:" .PP .IP "\fBtarget\fR: string (must be unique within table)" Connection methods for clients\[char46] .IP The following connection methods are currently supported: .RS .TP \fBssl:\fIhost\fB\fR[\fB:\fIport\fB\fR] The specified SSL \fIport\fR on the given \fIhost\fR, which can either be a DNS name (if built with unbound library) or an IP address\[char46] A valid SSL configuration must be provided when this form is used, this configuration can be specified via command-line options or the \fBSSL\fR table\[char46] .IP If \fIport\fR is not specified, it defaults to 6640\[char46] .IP SSL support is an optional feature that is not always built as part of Open vSwitch\[char46] .TP \fBtcp:\fIhost\fB\fR[\fB:\fIport\fB\fR] The specified TCP \fIport\fR on the given \fIhost\fR, which can either be a DNS name (if built with unbound library) or an IP address (IPv4 or IPv6)\[char46] If \fIhost\fR is an IPv6 address, wrap it in square brackets, e\[char46]g\[char46] \fBtcp:[::1]:6640\fR\[char46] .IP If \fIport\fR is not specified, it defaults to 6640\[char46] .TP \fBpssl:\fR[\fIport\fR][\fB:\fIhost\fB\fR] Listens for SSL connections on the specified TCP \fIport\fR\[char46] Specify 0 for \fIport\fR to have the kernel automatically choose an available port\[char46] If \fIhost\fR, which can either be a DNS name (if built with unbound library) or an IP address, is specified, then connections are restricted to the resolved or specified local IP address (either IPv4 or IPv6 address)\[char46] If \fIhost\fR is an IPv6 address, wrap in square brackets, e\[char46]g\[char46] \fBpssl:6640:[::1]\fR\[char46] If \fIhost\fR is not specified then it listens only on IPv4 (but not IPv6) addresses\[char46] A valid SSL configuration must be provided when this form is used, this can be specified either via command-line options or the \fBSSL\fR table\[char46] .IP If \fIport\fR is not specified, it defaults to 6640\[char46] .IP SSL support is an optional feature that is not always built as part of Open vSwitch\[char46] .TP \fBptcp:\fR[\fIport\fR][\fB:\fIhost\fB\fR] Listens for connections on the specified TCP \fIport\fR\[char46] Specify 0 for \fIport\fR to have the kernel automatically choose an available port\[char46] If \fIhost\fR, which can either be a DNS name (if built with unbound library) or an IP address, is specified, then connections are restricted to the resolved or specified local IP address (either IPv4 or IPv6 address)\[char46] If \fIhost\fR is an IPv6 address, wrap it in square brackets, e\[char46]g\[char46] \fBptcp:6640:[::1]\fR\[char46] If \fIhost\fR is not specified then it listens only on IPv4 addresses\[char46] .IP If \fIport\fR is not specified, it defaults to 6640\[char46] .RE .IP When multiple clients are configured, the \fBtarget\fR values must be unique\[char46] Duplicate \fBtarget\fR values yield unspecified results\[char46] .IP "\fBread_only\fR: boolean" \fBtrue\fR to restrict these connections to read-only transactions, \fBfalse\fR to allow them to modify the database\[char46] .IP "\fBrole\fR: string" String containing role name for this connection entry\[char46] .ST "Client Failure Detection and Handling:" .PP .IP "\fBmax_backoff\fR: optional integer, at least 1,000" Maximum number of milliseconds to wait between connection attempts\[char46] Default is implementation-specific\[char46] .IP "\fBinactivity_probe\fR: optional integer" Maximum number of milliseconds of idle time on connection to the client before sending an inactivity probe message\[char46] If Open vSwitch does not communicate with the client for the specified number of seconds, it will send a probe\[char46] If a response is not received for the same additional amount of time, Open vSwitch assumes the connection has been broken and attempts to reconnect\[char46] Default is implementation-specific\[char46] A value of 0 disables inactivity probes\[char46] .ST "Status:" .PP .PP .PP Key-value pair of \fBis_connected\fR is always updated\[char46] Other key-value pairs in the status columns may be updated depends on the \fBtarget\fR type\[char46] .PP .PP When \fBtarget\fR specifies a connection method that listens for inbound connections (e\[char46]g\[char46] \fBptcp:\fR or \fBpunix:\fR), both \fBn_connections\fR and \fBis_connected\fR may also be updated while the remaining key-value pairs are omitted\[char46] .PP .PP On the other hand, when \fBtarget\fR specifies an outbound connection, all key-value pairs may be updated, except the above-mentioned two key-value pairs associated with inbound connection targets\[char46] They are omitted\[char46] .IP "\fBis_connected\fR: boolean" \fBtrue\fR if currently connected to this client, \fBfalse\fR otherwise\[char46] .IP "\fBstatus : last_error\fR: optional string" A human-readable description of the last error on the connection to the manager; i\[char46]e\[char46] \fBstrerror(errno)\fR\[char46] This key will exist only if an error has occurred\[char46] .IP "\fBstatus : state\fR: optional string, one of \fBACTIVE\fR, \fBBACKOFF\fR, \fBCONNECTING\fR, \fBIDLE\fR, or \fBVOID\fR" The state of the connection to the manager: .RS .TP \fBVOID\fR Connection is disabled\[char46] .TP \fBBACKOFF\fR Attempting to reconnect at an increasing period\[char46] .TP \fBCONNECTING\fR Attempting to connect\[char46] .TP \fBACTIVE\fR Connected, remote host responsive\[char46] .TP \fBIDLE\fR Connection is idle\[char46] Waiting for response to keep-alive\[char46] .RE .IP These values may change in the future\[char46] They are provided only for human consumption\[char46] .IP "\fBstatus : sec_since_connect\fR: optional string, containing an integer, at least 0" The amount of time since this client last successfully connected to the database (in seconds)\[char46] Value is empty if client has never successfully been connected\[char46] .IP "\fBstatus : sec_since_disconnect\fR: optional string, containing an integer, at least 0" The amount of time since this client last disconnected from the database (in seconds)\[char46] Value is empty if client has never disconnected\[char46] .IP "\fBstatus : locks_held\fR: optional string" Space-separated list of the names of OVSDB locks that the connection holds\[char46] Omitted if the connection does not hold any locks\[char46] .IP "\fBstatus : locks_waiting\fR: optional string" Space-separated list of the names of OVSDB locks that the connection is currently waiting to acquire\[char46] Omitted if the connection is not waiting for any locks\[char46] .IP "\fBstatus : locks_lost\fR: optional string" Space-separated list of the names of OVSDB locks that the connection has had stolen by another OVSDB client\[char46] Omitted if no locks have been stolen from this connection\[char46] .IP "\fBstatus : n_connections\fR: optional string, containing an integer, at least 2" When \fBtarget\fR specifies a connection method that listens for inbound connections (e\[char46]g\[char46] \fBptcp:\fR or \fBpssl:\fR) and more than one connection is actually active, the value is the number of active connections\[char46] Otherwise, this key-value pair is omitted\[char46] .IP "\fBstatus : bound_port\fR: optional string, containing an integer" When \fBtarget\fR is \fBptcp:\fR or \fBpssl:\fR, this is the TCP port on which the OVSDB server is listening\[char46] (This is particularly useful when \fBtarget\fR specifies a port of 0, allowing the kernel to choose any available port\[char46]) .ST "Common Columns:" .PP The overall purpose of these columns is described under \fBCommon Columns\fR at the beginning of this document\[char46] .IP "\fBexternal_ids\fR: map of string-string pairs" .IP "\fBother_config\fR: map of string-string pairs" .bp .SH "SSL TABLE" .PP SSL configuration for ovn-sb database access\[char46] .SS "Summary: .TQ 3.00in \fBprivate_key\fR string .TQ 3.00in \fBcertificate\fR string .TQ 3.00in \fBca_cert\fR string .TQ 3.00in \fBbootstrap_ca_cert\fR boolean .TQ 3.00in \fBssl_protocols\fR string .TQ 3.00in \fBssl_ciphers\fR string .TQ .25in \fICommon Columns:\fR .RS .25in .TQ 2.75in \fBexternal_ids\fR map of string-string pairs .RE .SS "Details: .IP "\fBprivate_key\fR: string" Name of a PEM file containing the private key used as the switch\(cqs identity for SSL connections to the controller\[char46] .IP "\fBcertificate\fR: string" Name of a PEM file containing a certificate, signed by the certificate authority (CA) used by the controller and manager, that certifies the switch\(cqs private key, identifying a trustworthy switch\[char46] .IP "\fBca_cert\fR: string" Name of a PEM file containing the CA certificate used to verify that the switch is connected to a trustworthy controller\[char46] .IP "\fBbootstrap_ca_cert\fR: boolean" If set to \fBtrue\fR, then Open vSwitch will attempt to obtain the CA certificate from the controller on its first SSL connection and save it to the named PEM file\[char46] If it is successful, it will immediately drop the connection and reconnect, and from then on all SSL connections must be authenticated by a certificate signed by the CA certificate thus obtained\[char46] \fBThis option exposes the SSL connection to a man\-in\-the\-middle attack obtaining the initial CA certificate\[char46]\fR It may still be useful for bootstrapping\[char46] .IP "\fBssl_protocols\fR: string" List of SSL protocols to be enabled for SSL connections\[char46] The default when this option is omitted is \fBTLSv1,TLSv1\[char46]1,TLSv1\[char46]2\fR\[char46] .IP "\fBssl_ciphers\fR: string" List of ciphers (in OpenSSL cipher string format) to be supported for SSL connections\[char46] The default when this option is omitted is \fBHIGH:!aNULL:!MD5\fR\[char46] .ST "Common Columns:" .PP The overall purpose of these columns is described under \fBCommon Columns\fR at the beginning of this document\[char46] .IP "\fBexternal_ids\fR: map of string-string pairs" .bp .SH "DNS TABLE" .PP .PP .PP Each row in this table stores the DNS records\[char46] The OVN action \fBdns_lookup\fR uses this table for DNS resolution\[char46] .SS "Summary: .TQ 3.00in \fBrecords\fR map of string-string pairs .TQ 3.00in \fBdatapaths\fR set of 1 or more \fBDatapath_Binding\fRs .TQ .25in \fICommon Columns:\fR .RS .25in .TQ 2.75in \fBexternal_ids\fR map of string-string pairs .RE .SS "Details: .IP "\fBrecords\fR: map of string-string pairs" Key-value pair of DNS records with \fBDNS query name\fR as the key and a string of IP address(es) separated by comma or space as the value\[char46] ovn-northd stores the DNS query name in all lowercase in order to facilitate case-insensitive lookups\[char46] .IP \fBExample: \fR \(dqvm1\[char46]ovn\[char46]org\(dq = \(dq10\[char46]0\[char46]0\[char46]4 aef0::4\(dq .IP "\fBdatapaths\fR: set of 1 or more \fBDatapath_Binding\fRs" The DNS records defined in the column \fBrecords\fR will be applied only to the DNS queries originating from the datapaths defined in this column\[char46] .ST "Common Columns:" .PP .IP "\fBexternal_ids\fR: map of string-string pairs" See \fBExternal IDs\fR at the beginning of this document\[char46] .bp .SH "RBAC_Role TABLE" .PP Role table for role-based access controls\[char46] .SS "Summary: .TQ 3.00in \fBname\fR string .TQ 3.00in \fBpermissions\fR map of string-weak reference to \fBRBAC_Permission\fR pairs .SS "Details: .IP "\fBname\fR: string" The role name, corresponding to the \fBrole\fR column in the \fBConnection\fR table\[char46] .IP "\fBpermissions\fR: map of string-weak reference to \fBRBAC_Permission\fR pairs" A mapping of table names to rows in the \fBRBAC_Permission\fR table\[char46] .bp .SH "RBAC_Permission TABLE" .PP Permissions table for role-based access controls\[char46] .SS "Summary: .TQ 3.00in \fBtable\fR string .TQ 3.00in \fBauthorization\fR set of strings .TQ 3.00in \fBinsert_delete\fR boolean .TQ 3.00in \fBupdate\fR set of strings .SS "Details: .IP "\fBtable\fR: string" Name of table to which this row applies\[char46] .IP "\fBauthorization\fR: set of strings" Set of strings identifying columns and column:key pairs to be compared with client ID\[char46] At least one match is required in order to be authorized\[char46] A zero-length string is treated as a special value indicating all clients should be considered authorized\[char46] .IP "\fBinsert_delete\fR: boolean" When \(dqtrue\(dq, row insertions and authorized row deletions are permitted\[char46] .IP "\fBupdate\fR: set of strings" Set of strings identifying columns and column:key pairs that authorized clients are allowed to modify\[char46] .bp .SH "Gateway_Chassis TABLE" .PP .PP .PP Association of \fBPort_Binding\fR rows of \fBtype\fR \fBchassisredirect\fR to a \fBChassis\fR\[char46] The traffic going out through a specific \fBchassisredirect\fR port will be redirected to a chassis, or a set of them in high availability configurations\[char46] .SS "Summary: .TQ 3.00in \fBname\fR string (must be unique within table) .TQ 3.00in \fBchassis\fR optional weak reference to \fBChassis\fR .TQ 3.00in \fBpriority\fR integer, in range 0 to 32,767 .TQ 3.00in \fBoptions\fR map of string-string pairs .TQ .25in \fICommon Columns:\fR .RS .25in .TQ 2.75in \fBexternal_ids\fR map of string-string pairs .RE .SS "Details: .IP "\fBname\fR: string (must be unique within table)" Name of the \fBGateway_Chassis\fR\[char46] .IP A suggested, but not required naming convention is \fB${port_name}_${chassis_name}\fR\[char46] .IP "\fBchassis\fR: optional weak reference to \fBChassis\fR" The \fBChassis\fR to which we send the traffic\[char46] .IP "\fBpriority\fR: integer, in range 0 to 32,767" This is the priority the specific \fBChassis\fR among all Gateway_Chassis belonging to the same \fBPort_Binding\fR\[char46] .IP "\fBoptions\fR: map of string-string pairs" Reserved for future use\[char46] .ST "Common Columns:" .PP The overall purpose of these columns is described under \fBCommon Columns\fR at the beginning of this document\[char46] .IP "\fBexternal_ids\fR: map of string-string pairs" .bp .SH "HA_Chassis TABLE" .PP .SS "Summary: .TQ 3.00in \fBchassis\fR optional weak reference to \fBChassis\fR .TQ 3.00in \fBpriority\fR integer, in range 0 to 32,767 .TQ .25in \fICommon Columns:\fR .RS .25in .TQ 2.75in \fBexternal_ids\fR map of string-string pairs .RE .SS "Details: .IP "\fBchassis\fR: optional weak reference to \fBChassis\fR" The \fBChassis\fR which provides the HA functionality\[char46] .IP "\fBpriority\fR: integer, in range 0 to 32,767" Priority of the HA chassis\[char46] Chassis with highest priority will be the master in the HA chassis group\[char46] .ST "Common Columns:" .PP .IP "\fBexternal_ids\fR: map of string-string pairs" See \fBExternal IDs\fR at the beginning of this document\[char46] .bp .SH "HA_Chassis_Group TABLE" .PP .PP .PP Table representing a group of chassis which can provide High availability services\[char46] Each chassis in the group is represented by the table \fBHA_Chassis\fR\[char46] The HA chassis with highest priority will be the master of this group\[char46] If the master chassis failover is detected, the HA chassis with the next higher priority takes over the responsibility of providing the HA\[char46] If \fBha_chassis_group\fR column of the table \fBPort_Binding\fR references this table, then this HA chassis group provides the gateway functionality and redirects the gateway traffic to the master of this group\[char46] .SS "Summary: .TQ 3.00in \fBname\fR string (must be unique within table) .TQ 3.00in \fBha_chassis\fR set of \fBHA_Chassis\fRes .TQ 3.00in \fBref_chassis\fR set of weak reference to \fBChassis\fR .TQ .25in \fICommon Columns:\fR .RS .25in .TQ 2.75in \fBexternal_ids\fR map of string-string pairs .RE .SS "Details: .IP "\fBname\fR: string (must be unique within table)" Name of the \fBHA_Chassis_Group\fR\[char46] Name should be unique\[char46] .IP "\fBha_chassis\fR: set of \fBHA_Chassis\fRes" A list of \fBHA_Chassis\fR which belongs to this group\[char46] .IP "\fBref_chassis\fR: set of weak reference to \fBChassis\fR" The set of \fBChassis\fR that reference this HA chassis group\[char46] To determine the correct \fBChassis\fR, find the \fBchassisredirect\fR type \fBPort_Binding\fR that references this \fBHA_Chassis_Group\fR\[char46] This \fBPort_Binding\fR is derived from some particular logical router\[char46] Starting from that LR, find the set of all logical switches and routers connected to it, directly or indirectly, across router ports that link one LRP to another or to a LSP\[char46] For each LSP in these logical switches, find the corresponding \fBPort_Binding\fR and add its bound \fBChassis\fR (if any) to \fBref_chassis\fR\[char46] .ST "Common Columns:" .PP .IP "\fBexternal_ids\fR: map of string-string pairs" See \fBExternal IDs\fR at the beginning of this document\[char46] .bp .SH "Controller_Event TABLE" .PP .PP .PP Database table used by \fBovn\-controller\fR to report CMS related events\[char46] Please note there is no guarantee a given event is written exactly once in the db\[char46] It is CMS responsibility to squash duplicated lines or to filter out duplicated events .SS "Summary: .TQ 3.00in \fBevent_type\fR string, must be \fBempty_lb_backends\fR .TQ 3.00in \fBevent_info\fR map of string-string pairs .TQ 3.00in \fBchassis\fR optional weak reference to \fBChassis\fR .TQ 3.00in \fBseq_num\fR integer .SS "Details: .IP "\fBevent_type\fR: string, must be \fBempty_lb_backends\fR" Event type occurred .IP "\fBevent_info\fR: map of string-string pairs" Key-value pairs used to specify event info to the CMS\[char46] Possible values are: .RS .IP \(bu \fBvip\fR: VIP reported for the \fBempty_lb_backends\fR event .IP \(bu \fBprotocol\fR: Transport protocol reported for the \fBempty_lb_backends\fR event .IP \(bu \fBload_balancer\fR: UUID of the load balancer reported for the \fBempty_lb_backends\fR event .RE .IP "\fBchassis\fR: optional weak reference to \fBChassis\fR" This column is a \fBChassis\fR record to identify the chassis that has managed a given event\[char46] .IP "\fBseq_num\fR: integer" Event sequence number\[char46] Global counter for controller generated events\[char46] It can be used by the CMS to detect possible duplication of the same event\[char46] .bp .SH "IP_Multicast TABLE" .PP .PP .PP IP Multicast configuration options\[char46] For now only applicable to IGMP\[char46] .SS "Summary: .TQ 3.00in \fBdatapath\fR weak reference to \fBDatapath_Binding\fR (must be unique within table) .TQ 3.00in \fBenabled\fR optional boolean .TQ 3.00in \fBquerier\fR optional boolean .TQ 3.00in \fBtable_size\fR optional integer .TQ 3.00in \fBidle_timeout\fR optional integer .TQ 3.00in \fBquery_interval\fR optional integer .TQ 3.00in \fBseq_no\fR integer .TQ .25in \fIQuerier configuration options:\fR .RS .25in .TQ 2.75in \fBeth_src\fR string .TQ 2.75in \fBip4_src\fR string .TQ 2.75in \fBip6_src\fR string .TQ 2.75in \fBquery_max_resp\fR optional integer .RE .SS "Details: .IP "\fBdatapath\fR: weak reference to \fBDatapath_Binding\fR (must be unique within table)" \fBDatapath_Binding\fR entry for which these configuration options are defined\[char46] .IP "\fBenabled\fR: optional boolean" Enables/disables multicast snooping\[char46] Default: disabled\[char46] .IP "\fBquerier\fR: optional boolean" Enables/disables multicast querying\[char46] If \fBenabled\fR then multicast querying is enabled by default\[char46] .IP "\fBtable_size\fR: optional integer" Limits the number of multicast groups that can be learned\[char46] Default: 2048 groups per datapath\[char46] .IP "\fBidle_timeout\fR: optional integer" Configures the idle timeout (in seconds) for IP multicast groups if multicast snooping is enabled\[char46] Default: 300 seconds\[char46] .IP "\fBquery_interval\fR: optional integer" Configures the interval (in seconds) for sending multicast queries if snooping and querier are enabled\[char46] Default: \fBidle_timeout\fR/2 seconds\[char46] .IP "\fBseq_no\fR: integer" \fBovn\-controller\fR reads this value and flushes all learned multicast groups when it detects that \fBseq_no\fR was changed\[char46] .ST "Querier configuration options:" .PP The \fBovn\-controller\fR process that runs on OVN hypervisor nodes uses the following columns to determine field values in IGMP/MLD queries that it originates: .IP "\fBeth_src\fR: string" Source Ethernet address\[char46] .IP "\fBip4_src\fR: string" Source IPv4 address\[char46] .IP "\fBip6_src\fR: string" Source IPv6 address\[char46] .IP "\fBquery_max_resp\fR: optional integer" Value (in seconds) to be used as \(dqmax-response\(dq field in multicast queries\[char46] Default: 1 second\[char46] .bp .SH "IGMP_Group TABLE" .PP .PP .PP Contains learned IGMP groups indexed by address/datapath/chassis\[char46] .SS "Summary: .TQ 3.00in \fBaddress\fR string .TQ 3.00in \fBdatapath\fR optional weak reference to \fBDatapath_Binding\fR .TQ 3.00in \fBchassis\fR optional weak reference to \fBChassis\fR .TQ 3.00in \fBports\fR set of weak reference to \fBPort_Binding\fRs .SS "Details: .IP "\fBaddress\fR: string" Destination IPv4 address for the IGMP group\[char46] .IP "\fBdatapath\fR: optional weak reference to \fBDatapath_Binding\fR" Datapath to which this IGMP group belongs\[char46] .IP "\fBchassis\fR: optional weak reference to \fBChassis\fR" Chassis to which this IGMP group belongs\[char46] .IP "\fBports\fR: set of weak reference to \fBPort_Binding\fRs" The destination port bindings for this IGMP group\[char46] .bp .SH "Service_Monitor TABLE" .PP .PP .PP Each row in this table configures monitoring a service for its liveness\[char46] The service can be an IPv4 TCP or UDP service\[char46] \fBovn\-controller\fR periodically sends out service monitor packets and updates the status of the service\[char46] Service monitoring for IPv6 services is not supported\[char46] .PP .PP \fBovn\-northd\fR uses this feature to implement the load balancer health check feature offered to the CMS through the northbound database\[char46] .SS "Summary: .TQ .25in \fIConfiguration:\fR .RS .25in .TQ 2.75in \fBip\fR string .TQ 2.75in \fBprotocol\fR optional string, either \fBtcp\fR or \fBudp\fR .TQ 2.75in \fBport\fR integer, in range 0 to 65,535 .TQ 2.75in \fBlogical_port\fR string .TQ 2.75in \fBsrc_mac\fR string .TQ 2.75in \fBsrc_ip\fR string .TQ 2.75in \fBoptions : interval\fR optional string, containing an integer .TQ 2.75in \fBoptions : timeout\fR optional string, containing an integer .TQ 2.75in \fBoptions : success_count\fR optional string, containing an integer .TQ 2.75in \fBoptions : failure_count\fR optional string, containing an integer .RE .TQ .25in \fIStatus Reporting:\fR .RS .25in .TQ 2.75in \fBstatus\fR optional string, one of \fBerror\fR, \fBoffline\fR, or \fBonline\fR .RE .TQ .25in \fICommon Columns:\fR .RS .25in .TQ 2.75in \fBexternal_ids\fR map of string-string pairs .RE .SS "Details: .ST "Configuration:" .PP .PP .PP \fBovn\-northd\fR sets these columns and values to configure the service monitor\[char46] .IP "\fBip\fR: string" IP of the service to be monitored\[char46] Only IPv4 is supported\[char46] .IP "\fBprotocol\fR: optional string, either \fBtcp\fR or \fBudp\fR" The protocol of the service\[char46] .IP "\fBport\fR: integer, in range 0 to 65,535" The TCP or UDP port of the service\[char46] .IP "\fBlogical_port\fR: string" The VIF of the logical port on which the service is running\[char46] The \fBovn\-controller\fR that binds this \fBlogical_port\fR monitors the service by sending periodic monitor packets\[char46] .IP "\fBsrc_mac\fR: string" Source Ethernet address to use in the service monitor packet\[char46] .IP "\fBsrc_ip\fR: string" Source IPv4 address to use in the service monitor packet\[char46] .IP "\fBoptions : interval\fR: optional string, containing an integer" The interval, in seconds, between service monitor checks\[char46] .IP "\fBoptions : timeout\fR: optional string, containing an integer" The time, in seconds, after which the service monitor check times out\[char46] .IP "\fBoptions : success_count\fR: optional string, containing an integer" The number of successful checks after which the service is considered \fBonline\fR\[char46] .IP "\fBoptions : failure_count\fR: optional string, containing an integer" The number of failure checks after which the service is considered \fBoffline\fR\[char46] .ST "Status Reporting:" .PP .PP .PP The \fBovn\-controller\fR on the chassis that hosts the \fBlogical_port\fR updates this column to report the service\(cqs status\[char46] .IP "\fBstatus\fR: optional string, one of \fBerror\fR, \fBoffline\fR, or \fBonline\fR" For TCP service, \fBovn\-controller\fR sends a SYN to the service and expects an ACK response to consider the service to be \fBonline\fR\[char46] .IP For UDP service, \fBovn\-controller\fR sends a UDP packet to the service and doesn\(cqt expect any reply\[char46] If it receives an ICMP reply, then it considers the service to be \fBoffline\fR\[char46] .ST "Common Columns:" .PP .IP "\fBexternal_ids\fR: map of string-string pairs" See \fBExternal IDs\fR at the beginning of this document\[char46] .bp .SH "Load_Balancer TABLE" .PP .PP .PP Each row represents a load balancer\[char46] .SS "Summary: .TQ 3.00in \fBname\fR string .TQ 3.00in \fBvips\fR map of string-string pairs .TQ 3.00in \fBprotocol\fR optional string, one of \fBsctp\fR, \fBtcp\fR, or \fBudp\fR .TQ 3.00in \fBdatapaths\fR set of \fBDatapath_Binding\fRs .TQ 3.00in \fBdatapath_group\fR optional \fBLogical_DP_Group\fR .TQ .25in \fILoad_Balancer options:\fR .RS .25in .TQ 2.75in \fBoptions : hairpin_snat_ip\fR optional string .TQ 2.75in \fBoptions : hairpin_orig_tuple\fR optional string, either \fBtrue\fR or \fBfalse\fR .RE .TQ .25in \fICommon Columns:\fR .RS .25in .TQ 2.75in \fBexternal_ids\fR map of string-string pairs .RE .SS "Details: .IP "\fBname\fR: string" A name for the load balancer\[char46] This name has no special meaning or purpose other than to provide convenience for human interaction with the ovn-nb database\[char46] .IP "\fBvips\fR: map of string-string pairs" A map of virtual IP addresses (and an optional port number with \fB:\fR as a separator) associated with this load balancer and their corresponding endpoint IP addresses (and optional port numbers with \fB:\fR as separators) separated by commas\[char46] .IP "\fBprotocol\fR: optional string, one of \fBsctp\fR, \fBtcp\fR, or \fBudp\fR" Valid protocols are \fBtcp\fR, \fBudp\fR, or \fBsctp\fR\[char46] This column is useful when a port number is provided as part of the \fBvips\fR column\[char46] If this column is empty and a port number is provided as part of \fBvips\fR column, OVN assumes the protocol to be \fBtcp\fR\[char46] .IP "\fBdatapaths\fR: set of \fBDatapath_Binding\fRs" Datapaths to which this load balancer applies to\[char46] .IP "\fBdatapath_group\fR: optional \fBLogical_DP_Group\fR" The group of datapaths to which this load balancer applies to\[char46] This means that the same load balancer applies to all datapaths in a group\[char46] .ST "Load_Balancer options:" .PP .IP "\fBoptions : hairpin_snat_ip\fR: optional string" IP to be used as source IP for packets that have been hair-pinned after load balancing\[char46] This value is automatically populated by \fBovn\-northd\fR\[char46] .IP "\fBoptions : hairpin_orig_tuple\fR: optional string, either \fBtrue\fR or \fBfalse\fR" This value is automatically set to \fBtrue\fR by \fBovn\-northd\fR when original destination IP and transport port of the load balanced packets are stored in registers \fBreg1, reg2, xxreg1\fR\[char46] .ST "Common Columns:" .PP .IP "\fBexternal_ids\fR: map of string-string pairs" See \fBExternal IDs\fR at the beginning of this document\[char46] .bp .SH "BFD TABLE" .PP .PP .PP Contains BFD parameter for ovn-controller bfd configuration\[char46] .SS "Summary: .TQ .25in \fIConfiguration:\fR .RS .25in .TQ 2.75in \fBsrc_port\fR integer, in range 49,152 to 65,535 .TQ 2.75in \fBdisc\fR integer .TQ 2.75in \fBlogical_port\fR string .TQ 2.75in \fBdst_ip\fR string .TQ 2.75in \fBmin_tx\fR integer .TQ 2.75in \fBmin_rx\fR integer .TQ 2.75in \fBdetect_mult\fR integer .TQ 2.75in \fBoptions\fR map of string-string pairs .TQ 2.75in \fBexternal_ids\fR map of string-string pairs .RE .TQ .25in \fIStatus Reporting:\fR .RS .25in .TQ 2.75in \fBstatus\fR string, one of \fBadmin_down\fR, \fBdown\fR, \fBinit\fR, or \fBup\fR .RE .SS "Details: .ST "Configuration:" .PP .IP "\fBsrc_port\fR: integer, in range 49,152 to 65,535" udp source port used in bfd control packets\[char46] The source port MUST be in the range 49152 through 65535 (RFC5881 section 4)\[char46] .IP "\fBdisc\fR: integer" A unique, nonzero discriminator value generated by the transmitting system, used to demultiplex multiple BFD sessions between the same pair of systems\[char46] .IP "\fBlogical_port\fR: string" OVN logical port when BFD engine is running\[char46] .IP "\fBdst_ip\fR: string" BFD peer IP address\[char46] .IP "\fBmin_tx\fR: integer" This is the minimum interval, in milliseconds, that the local system would like to use when transmitting BFD Control packets, less any jitter applied\[char46] The value zero is reserved\[char46] .IP "\fBmin_rx\fR: integer" This is the minimum interval, in milliseconds, between received BFD Control packets that this system is capable of supporting, less any jitter applied by the sender\[char46] If this value is zero, the transmitting system does not want the remote system to send any periodic BFD Control packets\[char46] .IP "\fBdetect_mult\fR: integer" Detection time multiplier\[char46] The negotiated transmit interval, multiplied by this value, provides the Detection Time for the receiving system in Asynchronous mode\[char46] .IP "\fBoptions\fR: map of string-string pairs" Reserved for future use\[char46] .IP "\fBexternal_ids\fR: map of string-string pairs" See \fBExternal IDs\fR at the beginning of this document\[char46] .ST "Status Reporting:" .PP .IP "\fBstatus\fR: string, one of \fBadmin_down\fR, \fBdown\fR, \fBinit\fR, or \fBup\fR" BFD port logical states\[char46] Possible values are: .RS .IP \(bu \fBadmin_down\fR .IP \(bu \fBdown\fR .IP \(bu \fBinit\fR .IP \(bu \fBup\fR .RE .bp .SH "FDB TABLE" .PP .PP .PP This table is primarily used to learn the MACs observed on a VIF (or a localnet port with \(cqlocalnet_learn_fdb\(cq enabled) which belongs to a \fBLogical_Switch_Port\fR record in \fBOVN_Northbound\fR whose port security is disabled and \(cqunknown\(cq address set\[char46] If port security is disabled on a \fBLogical_Switch_Port\fR record, OVN should allow traffic with any source mac from the VIF\[char46] This table will be used to deliver a packet to the VIF, If a packet\(cqs \fBeth\[char46]dst\fR is learnt\[char46] .SS "Summary: .TQ 3.00in \fBmac\fR string .TQ 3.00in \fBdp_key\fR integer, in range 1 to 16,777,215 .TQ 3.00in \fBport_key\fR integer, in range 1 to 16,777,215 .SS "Details: .IP "\fBmac\fR: string" The learnt mac address\[char46] .IP "\fBdp_key\fR: integer, in range 1 to 16,777,215" The key of the datapath on which this FDB was learnt\[char46] .IP "\fBport_key\fR: integer, in range 1 to 16,777,215" The key of the port binding on which this FDB was learnt\[char46] .bp .SH "Static_MAC_Binding TABLE" .PP .PP .PP Each record represents a Static_MAC_Binding entry for a logical router\[char46] .SS "Summary: .TQ 3.00in \fBlogical_port\fR string .TQ 3.00in \fBip\fR string .TQ 3.00in \fBmac\fR string .TQ 3.00in \fBoverride_dynamic_mac\fR boolean .TQ 3.00in \fBdatapath\fR \fBDatapath_Binding\fR .SS "Details: .IP "\fBlogical_port\fR: string" The logical router port for the binding\[char46] .IP "\fBip\fR: string" The bound IP address\[char46] .IP "\fBmac\fR: string" The Ethernet address to which the IP is bound\[char46] .IP "\fBoverride_dynamic_mac\fR: boolean" Override dynamically learnt MACs\[char46] .IP "\fBdatapath\fR: \fBDatapath_Binding\fR" The logical datapath to which the logical router port belongs\[char46] .bp .SH "Chassis_Template_Var TABLE" .PP .PP .PP Each record represents the set of template variable instantiations for a given chassis and is populated by \fBovn\-northd\fR from the contents of the \fBOVN_Northbound\[char46]Chassis_Template_Var\fR table\[char46] .SS "Summary: .TQ 3.00in \fBchassis\fR string (must be unique within table) .TQ 3.00in \fBvariables\fR map of string-string pairs .SS "Details: .IP "\fBchassis\fR: string (must be unique within table)" The chassis this set of variable values applies to\[char46] .IP "\fBvariables\fR: map of string-string pairs" The set of variable values for a given chassis\[char46]