[ovs-dev] [PATCH v1 0/4] OVN: Vlan backed DVR, enable N-S packet flow

Ankur Sharma ankur.sharma at nutanix.com
Wed Jul 31 05:56:50 UTC 2019


Hi,

Sent out the same series (with same version) on OVN repo.

Thanks

Regards,
Ankur

-----Original Message-----
From: Ankur Sharma 
Sent: Tuesday, July 30, 2019 7:23 PM
To: ovs-dev at openvswitch.org
Subject: RE: [PATCH v1 0/4] OVN: Vlan backed DVR, enable N-S packet flow

Hi,

I will be sending the same series in OVN repo.

Thanks

Regards,
Ankur
-----Original Message-----
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

Problem Description:
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.


Design:
=======
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
   port.

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.
                          i.e cr-lrp-*
 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.


This Series:
============

Patch 1
-------
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.

Patch 2
-------
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.

Patch 3
-------
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.

Patch 4
-------
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.


Existing Efforts:
=================
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
      gateway chassis.

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(-)

--
1.8.3.1



More information about the dev mailing list