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 <[email protected]> --- 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 _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
