[ovs-dev] [PATCH v1 0/4] OVN: Vlan backed DVR, enable N-S packet flow
ankur.sharma at nutanix.com
Wed Jul 31 02:23:12 UTC 2019
I will be sending the same series in OVN repo.
From: Ankur Sharma
Sent: Tuesday, July 30, 2019 3:20 PM
To: ovs-dev at openvswitch.org
Cc: Ankur Sharma <ankur.sharma at nutanix.com>
Subject: [PATCH v1 0/4] OVN: Vlan backed DVR, enable N-S packet flow
Redirection to chassisredirect ports happens only via tunnel encapsulation. As a result, same cannot be leveraged upon for vlan backed environments.
This series addresses the issue by allowing redirection to happen without encapsulation.
a. High level design is that CMS/user will provision "redirect-type"
on a gateway chassis attached logical router port.
b. If the redirect-type is set as "vlan", then redirected packet
from compute chassis to gateway chassis will go via the localnet
c. This redirected vlan packet will have following attributes:
i. Source Mac ==> Chassis mac of compute chassis.
ii. Destination Mac ==> Mac address of chassisredirect router port.
iii. Vlan id ==> Vlan id of peer logical switch of gateway chassis
attached logical router port.
d. To attain c. above a logical flow added in table=33 will send the
packet to table=65, where it will hit regular flow which will
send the packet out of localnet port.
It is mostly a bug fix. Fix is to make sure that on gateway chassis we DO NOT replace source mac with chassis mac. This is done because this gateway chassis is the entry point for all the North->South traffic , hence north bound endpoint will use router port mac as destination mac.
If we replace router port mac with chassis mac on its gateway chassis as well, then router port mac will not learnt by physical network.
ovn-nbctl and ovn-northd changes to accept a "redirect-type" option associated with a logical router port. This configuration is added so that we have a parameter to decide if want to send a redirected packet via tunnel port or localnet port.
Adding a logical flow in lrp_in_arp_resolve to make sure that ARP requests from logical router are generated on gateway chassis only. This flow will make sure that we DO NOT call get_arp on compute chassis.
Changes in ovn-controller, to add the redirect related OVS flow based on configuration parameter added in Patch 2. i.e if redirect-type is 'overlay', then flow in table=32 will be added (to send the packet out via tunnel port), if redirect-type is 'vlan', then flow in table=33 will be added, to send the packet out via localnet port.
There has been an effort done in solving same problem.
https://patchwork.ozlabs.org/patch/920447/ by vkommadi at redhat.com
This patch differs from above changes in following areas:
a. Existing patch adds an additional flow in lr_in_ip_routing to mark the packet
as NAT_REDIRECT in compute chassis. This approach looks reasonable,
especially since through this we can avoid Patch 3 in this series.
However, using something similar based on our approach lead to following:
i. For each route pointing to gateway router port, we will need 2 flows
in lr_in_ip_routing, one which executes ONLY on compute chassis
and marks the packet for NAT_REDIRECT and one which executes ONLY
on gateway chassis and does not mark the packet.
Since, we cannot change the priority of a route flow
(prefix length decides the priority), hence we will end up with
2 logical flows with same match (with is_chassis_resident being the
only differentiating factor). OVN controller considered both such
flows as duplicate and ends up considering only one of them, i.e either
either only the compute chassis got is relevant flow or only
b. Existing patch considers a tenant as VLAN backed. Whereas this patch
considers overlay/vlan as the property of gateway logical switch. And
from a router's perspective, configuration is done on the peer router port.
c. Existing patch sends the packet to gateway router port mac, but uses
source logical switch (tenant logical switch's) vlan id.
This will always cause flooding in physical network, because
gateway router port mac will be learnt on the peer logical switch.
Using a different vlan id will always cause flooding of
redirected packets from compute chassis to gateway chassis.
d. Because of c. above, existing patch needs changes on receiving side as well.
This is because since packet's vlan id is not of the correct logical switch,
hence on receiving node (gateway chassis), packet has to be forced forwaded to
the logical router pipeline.
Ankur Sharma (4):
OVN: Do not replace router port mac on gateway chassis.
OVN: Vlan backed DVR N-S, redirect-type option
OVN: Vlan backed DVR N-S, avoid get_arp on non redirect chassis.
OVN: Vlan backed DVR N-S, redirect packet via localnet port
ovn/controller/physical.c | 274 +++++++++++++-------
ovn/controller/pinctrl.c | 37 +--
ovn/controller/pinctrl.h | 5 +
ovn/lib/ovn-util.c | 33 +++
ovn/lib/ovn-util.h | 5 +
ovn/northd/ovn-northd.c | 28 ++
ovn/ovn-architecture.7.xml | 64 +++++
ovn/ovn-nb.xml | 43 ++++
ovn/utilities/ovn-nbctl.c | 58 +++++
tests/ovn-nbctl.at | 25 ++
tests/ovn-northd.at | 31 +++
tests/ovn.at | 620 +++++++++++++++++++++++++++++++++++++++++++++
12 files changed, 1120 insertions(+), 103 deletions(-)
More information about the dev