@@ -108,10 +108,12 @@ Q: Why does OVN use STT and Geneve instead of VLANs or VXLAN (or GRE)?
may need to allocate more bits to the datapath or egress port
identifiers.
- As a side note, OVN does support VXLAN for use with ASIC-based top of rack
- switches, using ``ovn-controller-vtep(8)`` and the OVSDB VTEP schema
- described in ``vtep(5)``, but this limits the features available from OVN
- to the subset available from the VTEP schema.
+ As a side note, OVN does support VXLAN for use with "ramp
+ gateways" that allow ASIC-based top of rack switches to act as
+ on-ramp from a physical network into an OVN logical network. Ramp
+ switches use ``ovn-controller-vtep(8)`` and the OVSDB VTEP schema
+ described in ``vtep(5)``. This limits the features available from
+ OVN to the subset available from the VTEP schema.
Q: How can I contribute to the OVN Community?
@@ -52,11 +52,11 @@ OVN Gateway High Availability Plan
The OVN gateway is responsible for shuffling traffic between the tunneled
overlay network (governed by ovn-northd), and the legacy physical network. In
-a naive implementation, the gateway is a single x86 server, or hardware VTEP.
-For most deployments, a single system has enough forwarding capacity to service
-the entire virtualized network, however, it introduces a single point of
-failure. If this system dies, the entire OVN deployment becomes unavailable.
-To mitigate this risk, an HA solution is critical -- by spreading
+a naive implementation, the gateway is a single x86 server or a hardware ToR
+switch. For most deployments, a single system has enough forwarding capacity
+to service the entire virtualized network, however, it introduces a single
+point of failure. If this system dies, the entire OVN deployment becomes
+unavailable. To mitigate this risk, an HA solution is critical -- by spreading
responsibility across multiple systems, no single server failure can take down
the network.
@@ -1959,4 +1959,4 @@ explore some of these directions:
* Other kinds of gateways. In addition to floating IPs with NAT, OVN
supports directly attaching VMs to a physical network and connecting
- logical switches to VTEP hardware.
+ logical switches to hardware top-of-rack switches.
@@ -1,5 +1,7 @@
Post-v20.03.0
--------------------------
+ - "VTEP" gateways and switches have been renamed "ramp" gateways and
+ switches, to better distinguish them from everyday use of VXLAN.
OVN v20.03.0 - xx xxx xxxx
@@ -1668,9 +1668,8 @@ physical_run(struct physical_ctx *p_ctx,
ofpbuf_clear(&ofpacts);
put_move(MFF_TUN_ID, 0, MFF_LOG_DATAPATH, 0, 24, &ofpacts);
put_load(binding->tunnel_key, MFF_LOG_INPORT, 0, 15, &ofpacts);
- /* For packets received from a vxlan tunnel, set a flag to that
- * effect. */
- put_load(1, MFF_LOG_FLAGS, MLF_RCV_FROM_VXLAN_BIT, 1, &ofpacts);
+ /* Packets received from a VXLAN tunnel lack an egress port. */
+ put_load(1, MFF_LOG_FLAGS, MLF_NO_EGRESS_PORT_BIT, 1, &ofpacts);
put_resubmit(OFTABLE_LOG_INGRESS_PIPELINE, &ofpacts);
ofctrl_add_flow(flow_table, OFTABLE_PHY_TO_LOG, 100,
@@ -1682,15 +1681,15 @@ physical_run(struct physical_ctx *p_ctx,
/* Table 32, priority 150.
* =======================
*
- * Handles packets received from a VXLAN tunnel which get resubmitted to
- * OFTABLE_LOG_INGRESS_PIPELINE due to lack of needed metadata in VXLAN,
- * explicitly skip sending back out any tunnels and resubmit to table 33
- * for local delivery.
+ * For packets received without an egress port (e.g. from a VXLAN tunnel),
+ * resubmit them to OFTABLE_LOG_INGRESS_PIPELINE to rediscover the egress
+ * port, but explicitly skip sending back out any tunnels and resubmit to
+ * table 33 for local delivery.
*/
struct match match;
match_init_catchall(&match);
match_set_reg_masked(&match, MFF_LOG_FLAGS - MFF_REG0,
- MLF_RCV_FROM_VXLAN, MLF_RCV_FROM_VXLAN);
+ MLF_NO_EGRESS_PORT, MLF_NO_EGRESS_PORT);
/* Resubmit to table 33. */
ofpbuf_clear(&ofpacts);
@@ -51,7 +51,7 @@ void ovn_init_symtab(struct shash *symtab);
/* MFF_LOG_FLAGS_REG bit assignments */
enum mff_log_flags_bits {
MLF_ALLOW_LOOPBACK_BIT = 0,
- MLF_RCV_FROM_VXLAN_BIT = 1,
+ MLF_NO_EGRESS_PORT_BIT = 1,
MLF_FORCE_SNAT_FOR_DNAT_BIT = 2,
MLF_FORCE_SNAT_FOR_LB_BIT = 3,
MLF_LOCAL_ONLY_BIT = 4,
@@ -64,11 +64,9 @@ enum mff_log_flags {
/* Allow outputting back to inport. */
MLF_ALLOW_LOOPBACK = (1 << MLF_ALLOW_LOOPBACK_BIT),
- /* Indicate that a packet was received from a VXLAN tunnel to
- * compensate for the lack of egress port information available in
- * VXLAN encapsulation. Egress port information is available for
- * Geneve and STT tunnel types. */
- MLF_RCV_FROM_VXLAN = (1 << MLF_RCV_FROM_VXLAN_BIT),
+ /* Indicate that a packet was received without egress port information,
+ * which is not available, e.g., in packets received from ramp switches. */
+ MLF_NO_EGRESS_PORT = (1 << MLF_NO_EGRESS_PORT_BIT),
/* Indicate that a packet needs a force SNAT in the gateway router when
* DNAT has taken place. */
@@ -225,7 +225,7 @@ enum ovn_stage {
#define REG_ECMP_GROUP_ID "reg8[0..15]"
#define REG_ECMP_MEMBER_ID "reg8[16..31]"
-#define FLAGBIT_NOT_VXLAN "flags[1] == 0"
+#define FLAGBIT_HAS_EGRESS_PORT "flags[1] == 0"
/* Returns an "enum ovn_stage" built from the arguments. */
static enum ovn_stage
@@ -5894,12 +5894,13 @@ build_lswitch_rport_arp_req_flow_for_ip(struct sset *ips,
struct ds match = DS_EMPTY_INITIALIZER;
struct ds actions = DS_EMPTY_INITIALIZER;
- /* Packets received from VXLAN tunnels have already been through the
- * router pipeline so we should skip them. Normally this is done by the
- * multicast_group implementation (VXLAN packets skip table 32 which
- * delivers to patch ports) but we're bypassing multicast_groups.
+ /* Packets that have an egress port have already been through the router
+ * pipeline so we should skip them. Normally this is done by the
+ * multicast_group implementation (packets lacking an egress port skip
+ * table 32 which delivers to patch ports) but we're bypassing
+ * multicast_groups.
*/
- ds_put_cstr(&match, FLAGBIT_NOT_VXLAN " && ");
+ ds_put_cstr(&match, FLAGBIT_HAS_EGRESS_PORT" && ");
if (addr_family == AF_INET) {
ds_put_cstr(&match, "arp.op == 1 && arp.tpa == { ");
@@ -77,8 +77,8 @@
logical network into a physical network by bidirectionally forwarding
packets between tunnels and a physical Ethernet port. This allows
non-virtualized machines to participate in logical networks. A gateway
- may be a physical host, a virtual machine, or an ASIC-based hardware
- switch that supports the <code>vtep</code>(5) schema.
+ may be a physical host, a virtual machine, or a hardware switch (see
+ <code>Ramp Gateways</code>, below).
</p>
<p>
@@ -529,20 +529,27 @@
ones. OVN support multiple kinds of gateways.
</p>
- <h3>VTEP Gateways</h3>
+ <h3>Ramp Gateways</h3>
<p>
- A ``VTEP gateway'' connects an OVN logical network to a physical (or
- virtual) switch that implements the OVSDB VTEP schema that accompanies Open
- vSwitch. (The ``VTEP gateway'' term is a misnomer, since a VTEP is just a
- VXLAN Tunnel Endpoint, but it is a well established name.) See <code>Life
- Cycle of a VTEP gateway</code>, below, for more information.
+ A ``ramp gateway'' acts like an on-ramp to an OVN logical network from a
+ physical (or virtual) switch, called a ``ramp switch'', that implements the
+ OVSDB VTEP schema that accompanies Open vSwitch. See <code>Life Cycle of a
+ ramp gateway</code>, below, for more information.
</p>
<p>
- The main intended use case for VTEP gateways is to attach physical servers
- to an OVN logical network using a physical top-of-rack switch that supports
- the OVSDB VTEP schema.
+ The main intended use case for ramp gateways is to attach physical servers
+ to an OVN logical network using a physical top-of-rack switch instead of a
+ server. Reasons to do this include convenience (the switch is already
+ there and supports this feature) or density (the switch has 40 ports and
+ it's difficult to add that many to a server).
+ </p>
+
+ <p>
+ Previous versions of OVN referred to ramp gateways and ramp switches as
+ ``VTEP gateways'' and ``VTEP switches,'' respectively, but these terms are
+ misnomers, since a VTEP is just a VXLAN Tunnel Endpoint.
</p>
<h3>L2 Gateways</h3>
@@ -568,7 +575,7 @@
the transport between hypervisors. With an L2 gateway, packets are still
transported between hypervisors over tunnels and the <code>l2gateway</code>
port is only used for the packets that are on the physical network. The
- application for L2 gateways is similar to that for VTEP gateways, e.g. to
+ application for L2 gateways is similar to that for ramp gateways, e.g. to
add non-virtualized machines to a logical network, but L2 gateways do not
require special support from top-of-rack hardware switches.
</p>
@@ -1134,7 +1141,7 @@
<p>
Geneve and STT tunnels pass this field as part of the tunnel key.
Although VXLAN tunnels do not explicitly carry a logical input port,
- OVN only uses VXLAN to communicate with gateways that from OVN's
+ OVN only uses VXLAN to communicate with ramp gateways, which from OVN's
perspective consist of only a single logical port, so that OVN can set
the logical input port field to this one on ingress to the OVN logical
pipeline.
@@ -1160,7 +1167,7 @@
an OVN hypervisor, the packet is resubmitted to table 8 to
determine the output port(s); when the packet reaches table 32,
these packets are resubmitted to table 33 for local delivery by
- checking a MLF_RCV_FROM_VXLAN flag, which is set when the packet
+ checking a MLF_NO_EGRESS_PORT flag, which is set when the packet
arrives from a VXLAN tunnel.
</p>
</dd>
@@ -1399,12 +1406,12 @@
<ul>
<li>
- A higher-priority rule to match packets received from VXLAN tunnels,
- based on flag MLF_RCV_FROM_VXLAN, and resubmit these packets to table
- 33 for local delivery. Packets received from VXLAN tunnels reach
- here because of a lack of logical output port field in the tunnel key
- and thus these packets needed to be submitted to table 8 to
- determine the output port.
+ A higher-priority rule to match packets that were received without
+ egress port metadata, based on flag MLF_NO_EGRESS_PORT. The actions
+ resubmit these packets to table 33 for local delivery. This catches
+ packets received from VXLAN tunnels because of a lack of logical
+ output port field in the tunnel key and thus these packets needed to
+ be submitted to table 8 to determine the output port.
</li>
<li>
A higher-priority rule to match packets received from ports of type
@@ -2062,12 +2069,15 @@
</ol>
- <h2>Life Cycle of a VTEP gateway</h2>
+ <h2>Life Cycle of a ramp gateway</h2>
<p>
- A gateway 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.
+ A gateway 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. A ``ramp gateway'' acts like an on-ramp
+ to an OVN logical network from a physical (or virtual) switch, called a
+ ``ramp switch'', that implements the OVSDB VTEP schema that accompanies
+ Open vSwitch. See <code>Ramp Gateways</code>, above, for more information.
</p>
<p>
@@ -2079,19 +2089,19 @@
<ol>
<li>
- A VTEP gateway's life cycle begins with the administrator registering
- the VTEP gateway as a <code>Physical_Switch</code> table entry in the
+ A ramp gateway's life cycle begins with the administrator registering
+ the ramp gateway as a <code>Physical_Switch</code> table entry in the
<code>VTEP</code> database. The <code>ovn-controller-vtep</code>
- connected to this VTEP database, will recognize the new VTEP gateway
+ connected to this VTEP database, will recognize the new ramp gateway
and create a new <code>Chassis</code> table entry for it in the
<code>OVN_Southbound</code> database.
</li>
<li>
The administrator can then create a new <code>Logical_Switch</code>
- table entry, and bind a particular vlan on a VTEP gateway's port to
+ table entry, and bind a particular vlan on a ramp gateway's port to
any VTEP logical switch. Once a VTEP logical switch is bound to
- a VTEP gateway, the <code>ovn-controller-vtep</code> will detect
+ a ramp gateway, the <code>ovn-controller-vtep</code> will detect
it and add its name to the <var>vtep_logical_switches</var>
column of the <code>Chassis</code> table in the <code>
OVN_Southbound</code> database. Note, the <var>tunnel_key</var>
@@ -2108,7 +2118,7 @@
of this entry must be set to "vtep". Next, the <var>
vtep-logical-switch</var> and <var>vtep-physical-switch</var> keys
in the <var>options</var> column must also be specified, since
- multiple VTEP gateways can attach to the same VTEP logical switch.
+ multiple ramp gateways can attach to the same VTEP logical switch.
</li>
<li>
@@ -2116,14 +2126,14 @@
database and its configuration will be passed down to the <code>
OVN_Southbound</code> database as a new <code>Port_Binding</code>
table entry. The <code>ovn-controller-vtep</code> will recognize the
- change and bind the logical port to the corresponding VTEP gateway
+ change and bind the logical port to the corresponding ramp gateway
chassis. Configuration of binding the same VTEP logical switch to
a different OVN logical networks is not allowed and a warning will be
generated in the log.
</li>
<li>
- Beside binding to the VTEP gateway chassis, the <code>
+ Beside binding to the ramp gateway chassis, the <code>
ovn-controller-vtep</code> will update the <var>tunnel_key</var>
column of the VTEP logical switch to the corresponding <code>
Datapath_Binding</code> table entry's <var>tunnel_key</var> for the
@@ -2135,13 +2145,13 @@
configuration change in the <code>Port_Binding</code> in the
<code>OVN_Northbound</code> database, and updating the
<code>Ucast_Macs_Remote</code> table in the <code>VTEP</code> database.
- This allows the VTEP gateway to understand where to forward the unicast
+ This allows the ramp gateway to understand where to forward the unicast
traffic coming from the extended external network.
</li>
<li>
- Eventually, the VTEP gateway's life cycle ends when the administrator
- unregisters the VTEP gateway from the <code>VTEP</code> database.
+ Eventually, the ramp gateway's life cycle ends when the administrator
+ unregisters the ramp gateway from the <code>VTEP</code> database.
The <code>ovn-controller-vtep</code> will recognize the event and
remove all related configurations (<code>Chassis</code> table entry
and port bindings) in the <code>OVN_Southbound</code> database.
@@ -2151,7 +2161,7 @@
When the <code>ovn-controller-vtep</code> is terminated, all related
configurations in the <code>OVN_Southbound</code> database and
the <code>VTEP</code> database will be cleaned, including
- <code>Chassis</code> table entries for all registered VTEP gateways
+ <code>Chassis</code> table entries for all registered ramp gateways
and their port bindings, and all <code>Ucast_Macs_Remote</code> table
entries and the <code>Logical_Switch</code> tunnel keys.
</li>
@@ -2658,7 +2668,7 @@
</diagram>
<p>
- For connecting to gateways, in addition to Geneve and STT, OVN supports
+ For connecting to ramp gateways, in addition to Geneve and STT, OVN supports
VXLAN, because only VXLAN support is common on top-of-rack (ToR) switches.
Currently, gateways have a feature set that matches the capabilities as
defined by the VTEP schema, so fewer bits of metadata are necessary. In
@@ -549,7 +549,7 @@
<dt><code>vtep</code></dt>
<dd>
- A port to a logical switch on a VTEP gateway.
+ A port to a logical switch on a ramp gateway.
</dd>
<dt><code>external</code></dt>
@@ -746,17 +746,19 @@
</group>
- <group title="Options for vtep ports">
+ <group title="Options for ramp ports">
<p>
- These options apply when <ref column="type"/> is <code>vtep</code>.
+ These options apply when <ref column="type"/> is <code>vtep</code>,
+ that is, when the port is used to attach a ramp gateway to an OVN
+ logical switch.
</p>
<column name="options" key="vtep-physical-switch">
- Required. The name of the VTEP gateway.
+ Required. The name of the ramp gateway.
</column>
<column name="options" key="vtep-logical-switch">
- Required. A logical switch name connected by the VTEP gateway.
+ Required. A logical switch name connected by the ramp gateway.
</column>
</group>
@@ -354,7 +354,7 @@
</p>
<column name="vtep_logical_switches">
- Stores all VTEP logical switch names connected by this gateway
+ Stores all ramp logical switch names connected by this gateway
chassis. The <ref table="Port_Binding"/> table entry with
<ref column="options" table="Port_Binding"/>:<code>vtep-physical-switch</code>
equal <ref table="Chassis"/> <ref column="name" table="Chassis"/>, and
@@ -417,7 +417,7 @@
<p>
Not all devices see such a benefit. The most notable exception is
- hardware VTEPs. These devices are designed to not buffer entire
+ ramp switches. 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. In addition
certain versions of the Linux kernel are not able to fully take
@@ -428,7 +428,7 @@
</p>
<p>
- <code>csum</code> defaults to <code>false</code> for hardware VTEPs and
+ <code>csum</code> defaults to <code>false</code> for ramp switches and
<code>true</code> for all other cases.
</p>
@@ -2494,7 +2494,7 @@ tcp.flags = RST;
<dt>vtep</dt>
<dd>
- The physical location of the hardware_vtep gateway. To successfully
+ The physical location of the ramp 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>
@@ -2631,7 +2631,7 @@ tcp.flags = RST;
<dt><code>vtep</code></dt>
<dd>
- A port to a logical switch on a VTEP gateway chassis. In order to
+ A port to a logical switch on a ramp gateway chassis. In order to
get this port correctly recognized by the OVN controller, the <ref
column="options"
table="Port_Binding"/>:<code>vtep-physical-switch</code> and <ref
@@ -2802,18 +2802,19 @@ tcp.flags = RST;
</column>
</group>
- <group title="VTEP Options">
+ <group title="Ramp Switch Options">
<p>
These options apply to logical ports with <ref column="type"/> of
- <code>vtep</code>.
+ <code>vtep</code>, that is, ports that attach a ramp gateway to an OVN
+ logical switch.
</p>
<column name="options" key="vtep-physical-switch">
- Required. The name of the VTEP gateway.
+ Required. The name of the ramp gateway.
</column>
<column name="options" key="vtep-logical-switch">
- Required. A logical switch name connected by the VTEP gateway. Must
+ Required. A logical switch name connected by the ramp gateway. Must
be set when <ref column="type"/> is <code>vtep</code>.
</column>
</group>
@@ -429,7 +429,7 @@
<dt><code>vtep</code></dt>
<dd>
- A port to a logical switch on a VTEP gateway.
+ A port to a logical switch on a ramp gateway.
</dd>
</dl>