</p>
<column name="name">
- A chassis name, taken from <ref key="system-id" table="Open_vSwitch"
- column="external_ids" db="Open_vSwitch"/> in the Open_vSwitch
- database's <ref table="Open_vSwitch" db="Open_vSwitch"/> table. OVN does
- not prescribe a particular format for chassis names.
+ OVN does not prescribe a particular format for chassis names.
+ ovn-controller populates this column using <ref key="system-id"
+ table="Open_vSwitch" column="external_ids" db="Open_vSwitch"/>
+ in the Open_vSwitch database's <ref table="Open_vSwitch"
+ db="Open_vSwitch"/> table. ovn-controller-vtep populates this
+ column with <ref table="Physical_Switch" column="name"
+ db="hardware_vtep"/> in the hardware_vtep database's
+ <ref table="Physical_Switch" db="hardware_vtep"/> table.
</column>
<column name="hostname">
ovn-controller-vtep will leave this column empty.
</column>
+ <column name="external_ids" key="ovn-bridge-mappings">
+ <code>ovn-controller</code> populates this key with the set of bridge
+ mappings it has been configured to use. Other applications should treat
+ this key as read-only. See <code>ovn-controller</code>(8) for more
+ information.
+ </column>
+
+ <group title="Common Columns">
+ The overall purpose of these columns is described under <code>Common
+ Columns</code> at the beginning of this document.
+
+ <column name="external_ids"/>
+ </group>
+
<group title="Encapsulation Configuration">
<p>
OVN uses encapsulation to transmit logical dataplane packets
</column>
</table>
+ <table name="Address_Set" title="Address Sets">
+ <p>
+ See the documentation for the <ref table="Address_Set"
+ db="OVN_Northbound"/> table in the <ref db="OVN_Northbound"/> database
+ for details.
+ </p>
+
+ <column name="name"/>
+ <column name="addresses"/>
+ </table>
+
<table name="Logical_Flow" title="Logical Network Flows">
<p>
Each row in this table represents one logical flow.
the <code>output</code> as a no-op. In the common case, where they are
different, the packet enters the egress pipeline. This transition to the
egress pipeline discards register data, e.g. <code>reg0</code> ...
- <code>reg4</code> and connection tracking state, to achieve
+ <code>reg9</code> and connection tracking state, to achieve
uniform behavior regardless of whether the egress pipeline is on a
different hypervisor (because registers aren't preserve across
tunnel encapsulation).
</code>...<code></code>''.
</p>
+ <p>
+ You may refer to a set of IPv4, IPv6, or MAC addresses stored in the
+ <ref table="Address_Set"/> table by its <ref column="name"
+ table="Address_Set"/>. An <ref table="Address_Set"/> with a name
+ of <code>set1</code> can be referred to as
+ <code>$set1</code>.
+ </p>
+
<p><em>Miscellaneous</em></p>
<p>
symbols, only names within the flow's logical datapath may be used.
</p>
+ <p>
+ The <code>reg</code><var>X</var> symbols are 32-bit integers.
+ The <code>xxreg</code><var>X</var> symbols are 128-bit integers,
+ which overlay four of the 32-bit registers: <code>xxreg0</code>
+ overlays <code>reg0</code> through <code>reg3</code>, with
+ <code>reg0</code> supplying the most-significant bits of
+ <code>xxreg0</code> and <code>reg3</code> the least-signficant.
+ <code>xxreg1</code> similarly overlays <code>reg4</code> through
+ <code>reg7</code>.
+ </p>
+
<ul>
- <li><code>reg0</code>...<code>reg4</code></li>
+ <li><code>reg0</code>...<code>reg9</code></li>
+ <li><code>xxreg0</code> <code>xxreg1</code></li>
<li><code>inport</code> <code>outport</code></li>
<li><code>eth.src</code> <code>eth.dst</code> <code>eth.type</code></li>
<li><code>vlan.tci</code> <code>vlan.vid</code> <code>vlan.pcp</code> <code>vlan.present</code></li>
</dd>
<dt><code>ct_commit;</code></dt>
+ <dt><code>ct_commit(ct_mark=<var>value[/mask]</var>);</code></dt>
+ <dt><code>ct_commit(ct_label=<var>value[/mask]</var>);</code></dt>
+ <dt><code>ct_commit(ct_mark=<var>value[/mask]</var>, ct_label=<var>value[/mask]</var>);</code></dt>
<dd>
- Commit the flow to the connection tracking entry associated
- with it by a previous call to <code>ct_next</code>.
+ <p>
+ Commit the flow to the connection tracking entry associated with it
+ by a previous call to <code>ct_next</code>. When
+ <code>ct_mark=<var>value[/mask]</var></code> and/or
+ <code>ct_label=<var>value[/mask]</var></code> are supplied,
+ <code>ct_mark</code> and/or <code>ct_label</code> will be set to the
+ values indicated by <var>value[/mask]</var> on the connection
+ tracking entry. <code>ct_mark</code> is a 32-bit field.
+ <code>ct_label</code> is a 128-bit field. The <var>value[/mask]</var>
+ should be specified in hex string if more than 64bits are to be used.
+ </p>
+
+ <p>
+ Note that if you want processing to continue in the next table,
+ you must execute the <code>next</code> action after
+ <code>ct_commit</code>. You may also leave out <code>next</code>
+ which will commit connection tracking state, and then drop the
+ packet. This could be useful for setting <code>ct_mark</code>
+ on a connection tracking entry before dropping a packet,
+ for example.
+ </p>
+ </dd>
+
+ <dt><code>ct_dnat;</code></dt>
+ <dt><code>ct_dnat(<var>IP</var>);</code></dt>
+ <dd>
+ <p>
+ <code>ct_dnat</code> sends the packet through the DNAT zone in
+ connection tracking table to unDNAT any packet that was DNATed in
+ the opposite direction. The packet is then automatically sent to
+ to the next tables as if followed by <code>next;</code> action.
+ The next tables will see the changes in the packet caused by
+ the connection tracker.
+ </p>
+ <p>
+ <code>ct_dnat(<var>IP</var>)</code> 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.
+ The packet is then automatically sent to the next tables as if
+ followed by <code>next;</code> action. The next tables will see
+ the changes in the packet caused by the connection tracker.
+ </p>
+ </dd>
+
+ <dt><code>ct_snat;</code></dt>
+ <dt><code>ct_snat(<var>IP</var>);</code></dt>
+ <dd>
+ <p>
+ <code>ct_snat</code> sends the packet through the SNAT zone to
+ unSNAT any packet that was SNATed in the opposite direction. If
+ the packet needs to be sent to the next tables, then it should be
+ followed by a <code>next;</code> action. The next tables will not
+ see the changes in the packet caused by the connection tracker.
+ </p>
+ <p>
+ <code>ct_snat(<var>IP</var>)</code> 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.
+ The packet is then automatically sent to the next tables as if
+ followed by <code>next;</code> action. The next tables will see the
+ changes in the packet caused by the connection tracker.
+ </p>
</dd>
<dt><code>arp { <var>action</var>; </code>...<code> };</code></dt>
<p><b>Prerequisite:</b> <code>ip4</code></p>
</dd>
+ <dt>
+ <code>na { <var>action</var>; </code>...<code> };</code>
+ </dt>
+
+ <dd>
+ <p>
+ Temporarily replaces the IPv6 packet being processed by an IPv6
+ neighbor advertisement (NA) packet and executes each nested
+ <var>action</var> on the NA packet. Actions following the
+ <var>na</var> action, if any, apply to the original, unmodified
+ packet.
+ </p>
+
+ <p>
+ The NA packet that this action operates on is initialized based on
+ the IPv6 packet being processed, as follows. These are default
+ values that the nested actions will probably want to change:
+ </p>
+
+ <ul>
+ <li><code>eth.dst</code> exchanged with <code>eth.src</code></li>
+ <li><code>eth.type = 0x86dd</code></li>
+ <li><code>ip6.dst</code> copied from <code>ip6.src</code></li>
+ <li><code>ip6.src</code> copied from <code>nd.target</code></li>
+ <li><code>icmp6.type = 136</code> (Neighbor Advertisement)</li>
+ <li><code>nd.target</code> unchanged</li>
+ <li><code>nd.sll = 00:00:00:00:00:00</code></li>
+ <li><code>nd.tll</code> copied from <code>eth.dst</code></li>
+ </ul>
+
+ <p>
+ The ND packet has the same VLAN header, if any, as the IPv6 packet
+ it replaces.
+ </p>
+
+ <p>
+ <b>Prerequisite:</b> <code>nd</code>
+ </p>
+ </dd>
+
<dt><code>get_arp(<var>P</var>, <var>A</var>);</code></dt>
<dd>
<p><b>Example:</b> <code>put_arp(inport, arp.spa, arp.sha);</code></p>
</dd>
+
+ <dt>
+ <code><var>R</var> = put_dhcp_opts(<code>offerip</code> = <var>IP</var>, <var>D1</var> = <var>V1</var>, <var>D2</var> = <var>V2</var>, ..., <var>Dn</var> = <var>Vn</var>);</code>
+ </dt>
+
+ <dd>
+ <p>
+ <b>Parameters</b>: one or more DHCP option/value pairs, the first
+ of which must set a value for the offered IP, <code>offerip</code>.
+ </p>
+
+ <p>
+ <b>Result</b>: stored to a 1-bit subfield <var>R</var>.
+ </p>
+
+ <p>
+ Valid only in the ingress pipeline.
+ </p>
+
+ <p>
+ 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 <var>R</var>.
+ </p>
+
+ <p>
+ 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 <var>R</var>.
+ </p>
+
+ <p>
+ The contents of the <ref table="DHCP_Option"/> table control the
+ DHCP option names and values that this action supports.
+ </p>
+
+ <p>
+ <b>Example:</b>
+ <code>
+ reg0[0] = put_dhcp_opts(offerip = 10.0.0.2, router = 10.0.0.1,
+ netmask = 255.255.255.0, dns_server = {8.8.8.8, 7.7.7.7});
+ </code>
+ </p>
+ </dd>
+
+ <dt><code>ct_lb;</code></dt>
+ <dt><code>ct_lb(</code><var>ip</var>[<code>:</code><var>port</var>]...<code>);</code></dt>
+ <dd>
+ <p>
+ With one or more arguments, <code>ct_lb</code> commits the packet
+ to the connection tracking table and DNATs the packet's destination
+ IP address (and port) to the IP address or addresses (and optional
+ ports) specified in the string. If multiple comma-separated IP
+ addresses are specified, each is given equal weight for picking the
+ DNAT address. Processing automatically moves on to the next table,
+ as if <code>next;</code> were specified, and later tables act on
+ the packet as modified by the connection tracker. Connection
+ tracking state is scoped by the logical port, so overlapping
+ addresses may be used.
+ </p>
+ <p>
+ Without arguments, <code>ct_lb</code> sends the packet to the
+ connection tracking table to NAT the packets. If the packet is
+ part of an established connection that was previously committed to
+ the connection tracker via <code>ct_lb(</code>...<code>)</code>, it
+ will automatically get DNATed to the same IP address as the first
+ packet in that connection.
+ </p>
+ </dd>
</dl>
<p>
</p>
<p>
- For every <code>Logical_Port</code> record in <code>OVN_Northbound</code>
- database, <code>ovn-northd</code> creates a record in this table.
- <code>ovn-northd</code> populates and maintains every column except
- the <code>chassis</code> column, which it leaves empty in new records.
+ For every <code>Logical_Switch_Port</code> record in
+ <code>OVN_Northbound</code> database, <code>ovn-northd</code>
+ creates a record in this table. <code>ovn-northd</code> populates
+ and maintains every column except the <code>chassis</code> column,
+ which it leaves empty in new records.
</p>
<p>
which <code>ovn-controller</code>/<code>ovn-controller-vtep</code> in
turn finds out by monitoring the local hypervisor's Open_vSwitch
database, which identifies logical ports via the conventions described
- in <code>IntegrationGuide.md</code>.
+ in <code>IntegrationGuide.md</code>. (The exceptions are for
+ <code>Port_Binding</code> records with <code>type</code> of
+ <code>gateway</code>, whose locations are identified by
+ <code>ovn-northd</code> via the <code>options:gateway-chassis</code>
+ column in this table. <code>ovn-controller</code> is still responsible
+ to populate the <code>chassis</code> column.)
</p>
<p>
</column>
<column name="logical_port">
- A logical port, taken from <ref table="Logical_Port" column="name"
- db="OVN_Northbound"/> in the OVN_Northbound database's <ref
- table="Logical_Port" db="OVN_Northbound"/> table. OVN does not
- prescribe a particular format for the logical port ID.
+ A logical port, taken from <ref table="Logical_Switch_Port"
+ column="name" db="OVN_Northbound"/> in the OVN_Northbound
+ database's <ref table="Logical_Switch_Port" db="OVN_Northbound"/>
+ table. OVN does not prescribe a particular format for the
+ logical port ID.
</column>
<column name="chassis">
- The physical location of the logical port. To successfully identify a
- chassis, this column must be a <ref table="Chassis"/> record. This is
- populated by
- <code>ovn-controller</code>/<code>ovn-controller-vtep</code>.
+ The meaning of this column depends on the value of the <ref column="type"/>
+ column. This is the meaning for each <ref column="type"/>
+
+ <dl>
+ <dt>(empty string)</dt>
+ <dd>
+ The physical location of the logical port. To successfully identify a
+ chassis, this column must be a <ref table="Chassis"/> record. This is
+ populated by <code>ovn-controller</code>.
+ </dd>
+
+ <dt>vtep</dt>
+ <dd>
+ The physical location of the hardware_vtep gateway. To successfully
+ identify a chassis, this column must be a <ref table="Chassis"/> record.
+ This is populated by <code>ovn-controller-vtep</code>.
+ </dd>
+
+ <dt>localnet</dt>
+ <dd>
+ Always empty. A localnet port is realized on every chassis that has
+ connectivity to the corresponding physical network.
+ </dd>
+
+ <dt>gateway</dt>
+ <dd>
+ The physical location of the L3 gateway. To successfully identify a
+ chassis, this column must be a <ref table="Chassis"/> record. This is
+ populated by <code>ovn-controller</code> based on the value of
+ the <code>options:gateway-chassis</code> column in this table.
+ </dd>
+
+ <dt>l2gateway</dt>
+ <dd>
+ The physical location of this L2 gateway. To successfully identify a
+ chassis, this column must be a <ref table="Chassis"/> record.
+ This is populated by <code>ovn-controller</code> based on the value
+ of the <code>options:l2gateway-chassis</code> column in this table.
+ </dd>
+ </dl>
+
</column>
<column name="tunnel_key">
a logical router to a logical switch or to another logical router.
</dd>
+ <dt><code>gateway</code></dt>
+ <dd>
+ One of a pair of logical ports that act as if connected by a patch
+ cable across multiple chassis. Useful for connecting a logical
+ switch with a Gateway router (which is only resident on a
+ particular chassis).
+ </dd>
+
<dt><code>localnet</code></dt>
<dd>
A connection to a locally accessible network from each
to model direct connectivity to an existing network.
</dd>
+ <dt><code>l2gateway</code></dt>
+ <dd>
+ An L2 connection to a physical network. The chassis this
+ <ref table="Port_Binding"/> is bound to will serve as
+ an L2 gateway to the network named by
+ <ref column="options" table="Port_Binding"/>:<code>network_name</code>.
+ </dd>
+
<dt><code>vtep</code></dt>
<dd>
A port to a logical switch on a VTEP gateway chassis. In order to
</column>
</group>
+ <group title="L3 Gateway Options">
+ <p>
+ These options apply to logical ports with <ref column="type"/> of
+ <code>gateway</code>.
+ </p>
+
+ <column name="options" key="peer">
+ The <ref column="logical_port"/> in the <ref table="Port_Binding"/>
+ record for the other side of the 'gateway' port. The named <ref
+ column="logical_port"/> must specify this <ref column="logical_port"/>
+ in its own <code>peer</code> option. That is, the two 'gateway'
+ logical ports must have reversed <ref column="logical_port"/> and
+ <code>peer</code> values.
+ </column>
+
+ <column name="options" key="gateway-chassis">
+ The <code>chassis</code> in which the port resides.
+ </column>
+ </group>
+
<group title="Localnet Options">
<p>
These options apply to logical ports with <ref column="type"/> of
</column>
</group>
+ <group title="L2 Gateway Options">
+ <p>
+ These options apply to logical ports with <ref column="type"/> of
+ <code>l2gateway</code>.
+ </p>
+
+ <column name="options" key="network_name">
+ Required. <code>ovn-controller</code> uses the configuration entry
+ <code>ovn-bridge-mappings</code> to determine how to connect to this
+ network. <code>ovn-bridge-mappings</code> is a list of network names
+ mapped to a local OVS bridge that provides access to that network. An
+ example of configuring <code>ovn-bridge-mappings</code> would be:
+
+ <pre>$ ovs-vsctl set open . external-ids:ovn-bridge-mappings=physnet1:br-eth0,physnet2:br-eth1</pre>
+
+ <p>
+ When a logical switch has a <code>l2gateway</code> port attached,
+ the chassis that the <code>l2gateway</code> port is bound to
+ must have a bridge mapping configured to reach the network
+ identified by <code>network_name</code>.
+ </p>
+ </column>
+
+ <column name="options" key="l2gateway-chassis">
+ Required. The <code>chassis</code> in which the port resides.
+ </column>
+
+ <column name="tag">
+ If set, indicates that the gateway is connected to a specific
+ VLAN on the physical network. The VLAN ID is used to match
+ incoming traffic and is also added to outgoing traffic.
+ </column>
+ </group>
+
<group title="VTEP Options">
<p>
These options apply to logical ports with <ref column="type"/> of
<column name="parent_port">
This is taken from
- <ref table="Logical_Port" column="parent_name" db="OVN_Northbound"/>
- in the OVN_Northbound database's <ref table="Logical_Port"
- db="OVN_Northbound"/> table.
+ <ref table="Logical_Switch_Port" column="parent_name"
+ db="OVN_Northbound"/> in the OVN_Northbound database's
+ <ref table="Logical_Switch_Port" db="OVN_Northbound"/> table.
</column>
<column name="tag">
<p>
This column is used for a different purpose when <ref column="type"/>
- is <code>localnet</code> (see <code>Localnet Options</code>, above).
+ is <code>localnet</code> (see <code>Localnet Options</code>, above)
+ or <code>l2gateway</code> (see <code>L2 Gateway Options</code>, above).
</p>
</column>
</group>
<column name="mac">
The Ethernet address to which the IP is bound.
</column>
+ <column name="datapath">
+ The logical datapath to which the logical port belongs.
+ </column>
+ </table>
+
+ <table name="DHCP_Options" title="DHCP Options supported by native OVN DHCP">
+ <p>
+ Each row in this table stores the DHCP Options supported by native OVN
+ DHCP. <code>ovn-northd</code> populates this table with the supported
+ DHCP options. <code>ovn-controller</code> looks up this table to get the
+ DHCP codes of the DHCP options defined in the "put_dhcp_opts" action.
+ Please refer to the RFC 2132 <code>"https://tools.ietf.org/html/rfc2132"</code>
+ for the possible list of DHCP options that can be defined here.
+ </p>
+
+ <column name="name">
+ <p>
+ Name of the DHCP option.
+ </p>
+
+ <p>
+ Example. name="router"
+ </p>
+ </column>
+
+ <column name="code">
+ <p>
+ DHCP option code for the DHCP option as defined in the RFC 2132.
+ </p>
+
+ <p>
+ Example. code=3
+ </p>
+ </column>
+
+ <column name="type">
+ <p>
+ Data type of the DHCP option code.
+ </p>
+
+ <dl>
+ <dt><code>value: bool</code></dt>
+ <dd>
+ <p>
+ This indicates that the value of the DHCP option is a bool.
+ </p>
+
+ <p>
+ Example. "name=ip_forward_enable", "code=19", "type=bool".
+ </p>
+
+ <p>
+ put_dhcp_opts(..., ip_forward_enable = 1,...)
+ </p>
+ </dd>
+
+ <dt><code>value: uint8</code></dt>
+ <dd>
+ <p>
+ This indicates that the value of the DHCP option is an unsigned
+ int8 (8 bits)
+ </p>
+
+ <p>
+ Example. "name=default_ttl", "code=23", "type=uint8".
+ </p>
+
+ <p>
+ put_dhcp_opts(..., default_ttl = 50,...)
+ </p>
+ </dd>
+
+ <dt><code>value: uint16</code></dt>
+ <dd>
+ <p>
+ This indicates that the value of the DHCP option is an unsigned
+ int16 (16 bits).
+ </p>
+
+ <p>
+ Example. "name=mtu", "code=26", "type=uint16".
+ </p>
+
+ <p>
+ put_dhcp_opts(..., mtu = 1450,...)
+ </p>
+ </dd>
+
+ <dt><code>value: uint32</code></dt>
+ <dd>
+ <p>
+ This indicates that the value of the DHCP option is an unsigned
+ int32 (32 bits).
+ </p>
+
+ <p>
+ Example. "name=lease_time", "code=51", "type=uint32".
+ </p>
+
+ <p>
+ put_dhcp_opts(..., lease_time = 86400,...)
+ </p>
+ </dd>
+
+ <dt><code>value: ipv4</code></dt>
+ <dd>
+ <p>
+ This indicates that the value of the DHCP option is an IPv4
+ address or addresses.
+ </p>
+
+ <p>
+ Example. "name=router", "code=3", "type=ipv4".
+ </p>
+
+ <p>
+ put_dhcp_opts(..., router = 10.0.0.1,...)
+ </p>
+
+ <p>
+ Example. "name=dns_server", "code=6", "type=ipv4".
+ </p>
+
+ <p>
+ put_dhcp_opts(..., dns_server = {8.8.8.8 7.7.7.7},...)
+ </p>
+ </dd>
+
+ <dt><code>value: static_routes</code></dt>
+ <dd>
+ <p>
+ This indicates that the value of the DHCP option contains a pair of
+ IPv4 route and next hop addresses.
+ </p>
+
+ <p>
+ Example. "name=classless_static_route", "code=121", "type=static_routes".
+ </p>
+
+ <p>
+ put_dhcp_opts(..., classless_static_route = {30.0.0.0/24,10.0.0.4,0.0.0.0/0,10.0.0.1}...)
+ </p>
+ </dd>
+
+ <dt><code>value: str</code></dt>
+ <dd>
+ <p>
+ This indicates that the value of the DHCP option is a string.
+ </p>
+
+ <p>
+ Example. "name=host_name", "code=12", "type=str".
+ </p>
+ </dd>
+ </dl>
+ </column>
</table>
</database>
projects / cascardo / ovs.git / blobdiff