[ovs-dev] [PATCH ovn v2 3/7] ovn-nb: Better document distributed gateway ports.
Ben Pfaff
blp at ovn.org
Wed Mar 18 18:45:44 UTC 2020
The documentation was scattered across two places. This brings it
together. It also documents the two solutions for physical VLAN MTU
issues in a unified way.
Signed-off-by: Ben Pfaff <blp at ovn.org>
---
ovn-architecture.7.xml | 110 +++++++++++++++++++++++++--
ovn-nb.xml | 166 ++++++++++++++++++++---------------------
2 files changed, 181 insertions(+), 95 deletions(-)
diff --git a/ovn-architecture.7.xml b/ovn-architecture.7.xml
index d32978a9d5be..94a897fa693e 100644
--- a/ovn-architecture.7.xml
+++ b/ovn-architecture.7.xml
@@ -688,6 +688,100 @@
highest-priority gateway that is online.
</p>
+ <h4>Physical VLAN MTU Issues</h4>
+
+ <p>
+ Consider the preceding diagram again:
+ </p>
+
+ <pre fixed="yes">
+ LSlocal
+ |
+ LR1
+ |
+ +----+----+
+ | | |
+ LS1 ... LSn
+ </pre>
+
+ <p>
+ Suppose that each logical switch LS1, ..., LSn is bridged to a physical
+ VLAN-tagged network attached to a <code>localnet</code> port on LSlocal,
+ over a distributed gateway port on LR1. If a packet originating on
+ LS<var>i</var> is destined to the external network, OVN sends it to the
+ gateway chassis over a tunnel. There, the packet traverses LR1's logical
+ router pipeline, possibly undergoes NAT, and eventually ends up at
+ LSlocal's <code>localnet</code> port. If all of the physical links in the
+ network have the same MTU, then the packet's transit across a tunnel causes
+ an MTU problem: tunnel overhead prevents a packet that uses the full
+ physical MTU from crossing the tunnel to the gateway chassis (without
+ fragmentation).
+ </p>
+
+ <p>
+ OVN offers two solutions to this problem, the
+ <code>reside-on-redirect-chassis</code> and <code>redirect-type</code>
+ options. Both solutions require each logical switch LS1, ..., LSn to
+ include a <code>localnet</code> logical switch port LN1, ..., LNn
+ respectively, that is present on each chassis. Both cause packets to be
+ sent over the <code>localnet</code> ports instead of tunnels. They differ
+ in which packets--some or all--are sent this way. The most prominent
+ tradeoff between these options is that
+ <code>reside-on-redirect-chassis</code> is easier to configure and that
+ <code>redirect-type</code> performs better for east-west traffic.
+ </p>
+
+ <p>
+ The first solution is the <code>reside-on-redirect-chassis</code> option
+ for logical router ports. Setting this option on a LRP from (e.g.) LS1 to
+ LR1 disables forwarding from LS1 to LR1 except on the gateway chassis. On
+ chassis other than the gateway chassis, this single change means that
+ packets that would otherwise have been forwarded to LR1 are instead
+ forwarded to LN1. The instance of LN1 on the gateway chassis then receives
+ the packet and forwards it to LR1. The packet traverses the LR1 logical
+ router pipeline, possibly undergoes NAT, and eventually ends up at
+ LSlocal's <code>localnet</code> port. The packet never traverses a tunnel,
+ avoiding the MTU issue.
+ </p>
+
+ <p>
+ This option has the further consequence of centralizing ``distributed''
+ logical router LR1, since no packets are forwarded from LS1 to LR1 on any
+ chassis other than the gateway chassis. Therefore, east-west traffic
+ passes through the gateway chassis, not just north-south. (The naive
+ ``fix'' of allowing east-west traffic to flow directly between chassis over
+ LN1 does not work because routing sets the Ethernet source address to LR1's
+ source address. Seeing this single Ethernet source address originate from
+ all of the chassis will confuse the physical switch.)
+ </p>
+
+ <p>
+ Do not set the <code>reside-on-redirect-chassis</code> option on a
+ distributed gateway port. In the diagram above, it would be set on the
+ LRPs connecting LS1, ..., LSn to LR1.
+ </p>
+
+ <p>
+ The second solution is the <code>redirect-chassis</code> option for
+ distributed gateway ports. Setting this option to <code>bridged</code>
+ causes packets that are redirected to the gateway chassis to go over the
+ <code>localnet</code> ports instead of being tunneled. This option does
+ not change how OVN treats packets not redirected to the gateway chassis.
+ </p>
+
+ <p>
+ The <code>redirect-chassis</code> option requires the administrator or the
+ CMS to configure each participating chassis with a unique Ethernet address
+ for the locgical router by setting <code>ovn-chassis-mac-mappings</code> in
+ the Open vSwitch database, for use by <code>ovn-controller</code>. This
+ makes it more difficult to configure than
+ <code>reside-on-redirect-chassis</code>.
+ </p>
+
+ <p>
+ Set the <code>redirect-chassis</code> option on a distributed gateway port.
+ </p>
+
<h2>Life Cycle of a VIF</h2>
<p>
@@ -1892,14 +1986,14 @@
</ol>
<p>
- VLAN-based redirection:
-
- As an enhancement to <code>reside-on-redirect-chassis</code> we support
- VLAN-based redirection as well. By setting
- <code>options:redirect-type</code> to <code>bridged</code> on a gateway
- chassis attached router port, user can enforce that redirected packet
- should not use tunnel port but rather use localnet port of peer logical
- switch to go out on a physical VLAN.
+ As an alternative to <code>reside-on-redirect-chassis</code>, OVN supports
+ VLAN-based redirection. Whereas <code>reside-on-redirect-chassis</code>
+ centralizes all router functionality, VLAN-based redirection only changes
+ how OVN redirects packets to the gateway chassis. By setting
+ <code>options:redirect-type</code> to <code>bridged</code> on a distributed
+ gateway port, OVN redirects packets to the gateway chassis using the
+ <code>localnet</code> port of the router's peer logical switch, instead of
+ a tunnel.
</p>
<p>
diff --git a/ovn-nb.xml b/ovn-nb.xml
index ccd9bae991af..7f142bd35031 100644
--- a/ovn-nb.xml
+++ b/ovn-nb.xml
@@ -2038,8 +2038,9 @@
<p>
If any of these are set, this logical router port represents a
distributed gateway port that connects this router to a
- logical switch with a localnet port. There may be at most one
- such logical router port on each logical router.
+ logical switch with a <code>localnet</code> port. There may
+ be at most one such logical router port on each logical
+ router.
</p>
<p>
@@ -2096,6 +2097,82 @@
<column name="options" key="redirect-chassis">
Designates the named chassis as the gateway.
</column>
+
+ <group title="Options for Physical VLAN MTU Issues">
+ <p>
+ MTU issues arise in mixing tunnels with logical networks that are
+ bridged to a physical VLAN. For an explanation of the MTU issues,
+ see <code>Physical VLAN MTU Issues</code> in the OVN architecture
+ document. The following options, which are alternatives, provide
+ solutions. Both of them cause packets to be sent over
+ <code>localnet</code> instead of tunnels, but they differ in whether
+ some or all packets are sent this way. The most prominent
+ tradeoff between these options is that
+ <code>reside-on-redirect-chassis</code> is easier to configure and
+ that <code>redirect-type</code> performs better for east-west
+ traffic.
+ </p>
+
+ <column name="options" key="reside-on-redirect-chassis"
+ type='{"type": "boolean"}'>
+ <p>
+ If set to <code>true</code>, this option forces all traffic across
+ the logical router port to pass through the gateway chassis using a
+ hop across a <code>localnet</code> port. This changes behavior in
+ two ways:
+ </p>
+
+ <ul>
+ <li>
+ Without this option, east-west traffic passes directly between
+ source and destination chassis (or even within a single chassis,
+ for co-located VMs). With this option, all east-west traffic
+ passes through the gateway chassis.
+ </li>
+
+ <li>
+ Without this option, traffic between the gateway chassis and
+ other chassis is encapsulated in tunnels. With this option,
+ traffic passes over a <code>localnet</code> interface.
+ </li>
+ </ul>
+
+ <p>
+ This option may usefully be set only on logical router ports that
+ connect a distributed logical router to a logical switch with VIFs.
+ It should not be set on a distributed gateway port.
+ </p>
+
+ <p>
+ OVN honors this option only if the logical router has a distributed
+ gateway port and if the LRP's peer switch has a
+ <code>localnet</code> port.
+ </p>
+ </column>
+
+ <column name="options" key="redirect-type"
+ type='{"type": "string", "enum": ["set", ["overlay", "bridged"]]}'>
+ <p>
+ If set to <code>bridged</code> on a distributed gateway port, this
+ option causes OVN to redirect packets to the gateway chassis over a
+ <code>localnet</code> port instead of a tunnel. The relevant
+ chassis must share a <code>localnet</code> port.
+ </p>
+
+ <p>
+ This feature requires the administrator or the CMS to configure
+ each participating chassis with a unique Ethernet address for the
+ locgical router by setting <code>ovn-chassis-mac-mappings</code> in
+ the Open vSwitch database, for use by <code>ovn-controller</code>.
+ </p>
+
+ <p>
+ Setting this option to <code>overlay</code> or leaving it unset has
+ no effect. This option may usefully be set only on a distributed
+ gateway port. It is otherwise ignored.
+ </p>
+ </column>
+ </group>
</group>
<group title="ipv6_ra_configs">
@@ -2198,91 +2275,6 @@
Additional options for the logical router port.
</p>
- <column name="options" key="reside-on-redirect-chassis">
- <p>
- Generally routing is distributed in <code>OVN</code>. The packet
- from a logical port which needs to be routed hits the router pipeline
- in the source chassis. For the East-West traffic, the packet is
- sent directly to the destination chassis. For the outside traffic
- the packet is sent to the gateway chassis.
- </p>
-
- <p>
- When this option is set, <code>OVN</code> considers this only if
- </p>
-
- <ul>
- <li>
- The logical router to which this logical router port belongs to
- has a distributed gateway port.
- </li>
-
- <li>
- The peer's logical switch has a localnet port (representing
- a VLAN tagged network)
- </li>
- </ul>
-
- <p>
- When this option is set to <code>true</code>, then the packet
- which needs to be routed hits the router pipeline in the chassis
- hosting the distributed gateway router port. The source chassis
- pushes out this traffic via the localnet port. With this the
- East-West traffic is no more distributed and will always go through
- the gateway chassis.
- </p>
-
- <p>
- Without this option set, for any traffic destined to outside from a
- logical port which belongs to a logical switch with localnet port,
- the source chassis will send the traffic to the gateway chassis via
- the tunnel port instead of the localnet port and this could cause MTU
- issues.
- </p>
- </column>
-
- <column name="options" key="redirect-type">
- <p>
- This options dictates if a packet redirected to
- <code>gateway chassis</code> will be overlay encapsulated
- or go as a regular packet via the localnet port.
- </p>
-
- <p>
- Option takes following values
- </p>
-
- <ul>
- <li>
- OVERLAY
- </li>
-
- <li>
- BRIDGED
- </li>
- </ul>
-
- <p>
- OVERLAY option will ensure that redirected packet goes out as
- encapsulation via the tunnel port.
- </p>
-
- <p>
- BRIDGED option will ensure that redirected packet goes out
- via the localnet port tagged with vlan (if configured).
- </p>
-
- <p>
- OVERLAY is the default redirection type.
- </p>
-
- <p>
- Option is applicable only to gateway chassis attached logical
- router ports.
- </p>
-
- </column>
-
<column name="options" key="mcast_flood"
type='{"type": "boolean"}'>
<p>
--
2.24.1
More information about the dev
mailing list