</p>
<p>
- The <ref table="Chassis"/> and <ref table="Gateway"/> tables comprise the
- PN tables.
+ The <ref table="Chassis"/> table comprises the PN tables.
</p>
<h3>Logical Network (LN) data</h3>
The LN is a slave of the cloud management system running northbound of OVN.
That CMS determines the entire OVN logical configuration and therefore the
LN's content at any given time is a deterministic function of the CMS's
- configuration, although that happens indirectly via the OVN Northbound DB
- and <code>ovn-northd</code>.
+ configuration, although that happens indirectly via the
+ <ref db="OVN_Northbound"/> database and <code>ovn-northd</code>.
</p>
<p>
</column>
</group>
- <group title="Gateway Configuration">
- <p>
- A <dfn>gateway</dfn> is a chassis that forwards traffic between a
- logical network and a physical VLAN. Gateways are typically dedicated
- nodes that do not host VMs.
+ <group title="Gateway Configuration">
+ <p>
+ A <dfn>gateway</dfn> 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. Gateways are
+ typically dedicated nodes that do not host VMs.
</p>
- <column name="gateway_ports">
- Maps from the name of a port attached to the OVN integration bridge
- (typically a physical port or an Open vSwitch patch port) to a <ref
- table="Gateway"/> record that describes the details of the gatewaying
- function.
+ <column name="vtep_logical_switches">
+ Stores all vtep logical switch names connected by this gateway
+ chassis.
</column>
- </group>
+ </group>
</table>
<table name="Encap" title="Encapsulation Types">
</column>
</table>
- <table name="Gateway" title="Physical Network Gateway Ports">
- <p>
- The <ref column="gateway_ports" table="Chassis"/> column in the <ref
- table="Chassis"/> table refers to rows in this table to connect a chassis
- port to a gateway function. Each row in this table describes the logical
- networks to which a gateway port is attached. Each chassis, via
- <code>ovn-controller</code>(8), adds and updates its own rows, if any
- (since most chassis are not gateways), and keeps a copy of the remaining
- rows to determine how to reach other chassis.
- </p>
-
- <column name="vlan_map">
- Maps from a VLAN ID to a logical port name. Thus, each named logical
- port corresponds to one VLAN on the gateway port.
- </column>
- </table>
-
<table name="Logical_Flow" title="Logical Network Flows">
<p>
- Each row in this table represents one logical flow. The cloud management
- system, via its OVN integration, populates this table with logical flows
- that implement the L2 and L3 topology specified in the CMS configuration.
- Each hypervisor, via <code>ovn-controller</code>, translates the logical
- flows into OpenFlow flows specific to its hypervisor and installs them
- into Open vSwitch.
+ Each row in this table represents one logical flow.
+ <code>ovn-northd</code> populates this table with logical flows
+ that implement the L2 and L3 topologies specified in the
+ <ref db="OVN_Northbound"/> database. Each hypervisor, via
+ <code>ovn-controller</code>, translates the logical flows into
+ OpenFlow flows specific to its hypervisor and installs them into
+ Open vSwitch.
</p>
<p>
flows are written in terms of logical ports and logical datapaths instead
of physical ports and physical datapaths. Translation between logical
and physical flows helps to ensure isolation between logical datapaths.
- (The logical flow abstraction also allows the CMS to do less work, since
- it does not have to separately compute and push out physical flows to each
- chassis.)
+ (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.)
</p>
<p>
the logical output port replaced by the group member.
</p>
+ <p><em>Pipeline Stages</em></p>
+
+ <p>
+ <code>ovn-northd</code> is responsible for populating the
+ <ref table="Logical_Flow"/> table, so the stages are an
+ implementation detail and subject to change. This section
+ describes the current logical flow table.
+ </p>
+
+ <p>
+ The ingress pipeline consists of the following stages:
+ </p>
+ <ul>
+ <li>
+ Port Security (Table 0): Validates the source address, drops
+ packets with a VLAN tag, and, if configured, verifies that the
+ logical port is allowed to send with the source address.
+ </li>
+
+ <li>
+ L2 Destination Lookup (Table 1): Forwards known unicast
+ addresses to the appropriate logical port. Unicast packets to
+ unknown hosts are forwarded to logical ports configured with the
+ special <code>unknown</code> mac address. Broadcast, and
+ multicast are flooded to all ports in the logical switch.
+ </li>
+ </ul>
+
+ <p>
+ The egress pipeline consists of the following stages:
+ </p>
+ <ul>
+ <li>
+ ACL (Table 0): Applies any specified access control lists.
+ </li>
+
+ <li>
+ Port Security (Table 1): If configured, verifies that the
+ logical port is allowed to receive packets with the destination
+ address.
+ </li>
+ </ul>
+
<column name="logical_datapath">
The logical datapath to which the logical flow belongs.
</column>
Most of the symbols below have integer type. Only <code>inport</code>
and <code>outport</code> have string type. <code>inport</code> names a
logical port. Thus, its value is a <ref column="logical_port"/> name
- from the <ref table="Port_Binding"/> or <ref table="Gateway"/> tables.
- <code>outport</code> may name a logical port, as <code>inport</code>,
- or a logical multicast group defined in the <ref
- table="Multicast_Group"/> table. For both symbols, only names within
- the flow's logical datapath may be used.
+ from the <ref table="Port_Binding"/> table. <code>outport</code> may
+ name a logical port, as <code>inport</code>, or a logical multicast
+ group defined in the <ref table="Multicast_Group"/> table. For both
+ symbols, only names within the flow's logical datapath may be used.
</p>
<ul>
<li><code>nd.target</code> <code>nd.sll</code> <code>nd.tll</code></li>
</ul>
+ <p>
+ The following predicates are supported:
+ </p>
+
+ <ul>
+ <li><code>vlan.present</code> expands to <code>vlan.tci[12]</code></li>
+ <li><code>ip4</code> expands to <code>eth.type == 0x800</code></li>
+ <li><code>ip6</code> expands to <code>eth.type == 0x86dd</code></li>
+ <li><code>ip</code> expands to <code>ip4 || ip6</code></li>
+ <li><code>icmp4</code> expands to <code>ip4 && ip.proto == 1</code></li>
+ <li><code>icmp6</code> expands to <code>ip6 && ip.proto == 58</code></li>
+ <li><code>icmp</code> expands to <code>icmp4 || icmp6</code></li>
+ <li><code>ip.is_frag</code> expands to <code>ip.frag[0]</code></li>
+ <li><code>ip.later_frag</code> expands to <code>ip.frag[1]</code></li>
+ <li><code>ip.first_frag</code> expands to <code>ip.is_frag && !ip.later_frag</code></li>
+ <li><code>arp</code> expands to <code>eth.type == 0x806</code></li>
+ <li><code>nd</code> expands to <code>icmp6.type == {135, 136} && icmp6.code == 0</code></li>
+ <li><code>tcp</code> expands to <code>ip.proto == 6</code></li>
+ <li><code>udp</code> expands to <code>ip.proto == 17</code></li>
+ <li><code>sctp</code> expands to <code>ip.proto == 132</code></li>
+ </ul>
</column>
<column name="actions">
<dd>generate ARP from packet, execute <var>action</var>s</dd>
</dl>
</column>
+
+ <column name="external_ids" key="stage-name">
+ Human-readable name for this flow's stage in the pipeline.
+ </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>
</table>
<table name="Multicast_Group" title="Logical Port Multicast Groups">
projects / cascardo / ovs.git / blobdiff