</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">
+ The hostname of the chassis, if applicable. ovn-controller will populate
+ this column with the hostname of the host it is running on.
+ 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
<dt><code>ct_commit;</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>.
+ </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>.
+ </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 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>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>
<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">
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
</column>
</group>
+ <group title="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 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">
projects / cascardo / ovs.git / blobdiff