[ovs-dev] 答复: Re: 答复: Re: 答复: Re: [PATCH] ovn-controller: Support vxlan tunnel in ovn

Macauley Cheng macauley_cheng at accton.com
Tue May 9 03:16:30 UTC 2017


Hi Qianyu,
Did you try the ovn-controller-vtep before?
You can use the ovn-controller-vtep with HW switch to setup the vxlan tunnel with host which run ovn-controller.


-----Original Message-----
From: ovs-dev-bounces at openvswitch.org [mailto:ovs-dev-bounces at openvswitch.org] On Behalf Of wang.qianyu at zte.com.cn
Sent: Tuesday, May 09, 2017 9:29 AM
To: ovs-dev-bounces at openvswitch.org; blp at ovn.org; mickeys.dev at gmail.com
Cc: ovs dev; xu.rong at zte.com.cn; ovs-dev-bounces at openvswitch.org
Subject: [ovs-dev] 答复: Re: 答复: Re: 答复: Re: [PATCH] ovn-controller: Support vxlan tunnel in ovn

Hi Ben and Mikey, thank you for your review and analysis.

As we discribed below, vxlan is used very common, and the use case that we mentioned below is typical architecture of telecom operators' networks.
So, we think it is very necessary to support vxlan between ovs and HW switch. If ovn does not support the use case we discribed before, we think the the ovn features may be imperfect. For this reason, we do the changes as this patch.

Because vxlan tunnel can not carry enough information like genev to fulfill ovn current pipeline, so we do some assumptions. As Michkey and Ben said, these assumptions may not hold going forward, such as S_SWITCH_IN_L2_LKUP and  more than one chassisredirect ports and so on.

We think these incompatibles are not impossibly hard problems. If we have the consensus of the necessity to support vxlan, we think we could together to talk over a blueprint that less influence of current planning features and more effective to solve the problem we mentioned. 

Waiting for your suggestions,Thanks






Mickey Spiegel <mickeys.dev at gmail.com>
发件人: ovs-dev-bounces at openvswitch.org
2017/05/08 04:58
 
        收件人:        xu.rong at zte.com.cn, 
        抄送:  ovs dev <dev at openvswitch.org>, ovs-dev-bounces at openvswitch.org
        主题:  Re: [ovs-dev]   答复: Re: 答复: Re: [PATCH] 
ovn-controller: Support vxlan tunnel in ovn


There are some assumptions that you are making which need to be called 
out.
These assumptions may not hold going forward. In fact I refer to two
different patches below that are currently under review, that break your
assumptions.

On Fri, May 5, 2017 at 7:18 PM, <xu.rong at zte.com.cn> wrote:

> Hi,Russell
>
> We think vxlan is the most commonly used tunnel encapsulation in the
> overlay network openstack,ovn should better consider it.
>
> As my workmate wang qianyu said,we would consider computer node connect
> with existing hardware switches which associates with SR-IOV as VTEP.
>
> After discussion, we feel that as long as the following changes for 
vxlan
> tunnel in the table0:
>
> 1.For local switch, move MFF_TUN_ID to MFF_LOG_DATAPATH, resubmit to
> OFTABLE_ETH_UCAST(table29)
>

It looks like you are overloading OFTABLE_ETH_UCAST that you define here
with S_SWITCH_IN_L2_LKUP in ovn/northd/ovn-northd.c. Hardcoding the value
to 29 in ovn/controller/lflow.h is not the way to do this. This pipeline
stage does move back as new features are added. In fact it is now table 31
due to the recent addition of 2 tables for DNS lookup.


> //---In table29, we can find out dst port based on dst mac
>

You are assuming that outport determination is only based on
S_SWITCH_IN_L2_LKUP with no impact from any other ingress pipeline stages.
This may not always be true, which I think is the point of Ben's 
complaint.
For example the SFC patch that is currently under review (
http://patchwork.ozlabs.org/patch/754427/) may set outport and then do
"output" in the ingress pipeline, in a pipeline stage other than
S_SWITCH_IN_L2_LKUP.

The alternative is to go through the entire ingress pipeline, but here you
have a problem since you do not know the inport. The current VTEP-centric
VXLAN code assumes that there is only one port binding per datapath from
the VTEP chassis. For the general case that you are trying to address, 
this
assumption does not hold, so you cannot properly determine the inport. The
inport may affect the ultimate decision on outport. This is certainly the
case for the SFC patch currently under review.

You are also assuming that inport does not affect anything in the egress
pipeline. This seems to be true at the moment, but this might not always 
be
true as features are added.

The existing VTEP functionality does not rely on the assumptions that you
made, but since you changed the logic to determine inport in case of 
VXLAN,
you are changing existing functionality.


> 2.For local chassisredirect port, move MFF_TUN_ID to MFF_LOG_DATAPATH, 
set
> port tunnel_key to MFF_LOG_OUTPORT and then resubmit to
> OFTABLE_LOCAL_OUTPUT.
> //---In table 33, we can find out dst local sw and sw patch port based 
on
> the local chassisredirect port,and then follow the exsiting flows.
>

At the moment, the only case where a tunnel is used for a datapath
representing a logical router is when the outport is a chassisredirect
port. Your code assumes that will always be the case. If we do what you 
are
suggesting, then that becomes a restriction for all logical router 
features
going forward.

This code also assumes that there can only be one chassisredirect port per
datapath per chassis. There is a patch that has not yet been reviewed (
http://patchwork.ozlabs.org/patch/732815/) that proposes multiple
distributed gateway ports (and correspondingly chassisredirect ports) on
one datapath. I am not sure what the use case is, but if that feature were
added and more than one distributed gateway port on one datapath specified
the same redirect-chassis, it would break this code.

This version of the code is better than the original version, which was
based on a hack that used table 29 on a datapath for a logical router
(!!!), adding contrived flows that matched VXLAN tunnel bit, metadata ==
datapath->tunnel_key, and MAC address from the SB MAC_Binding table in
order to set the outport to a chassisredirect port, based on the 
assumption
that tunnels are only used for logical routers when the outport is a
chassisredirect port.

Mickey



> Next step, we will consider how ovn-controller-hw manages SR-IOV as 
well.
>
> Waiting for your suggestions,Thanks.
>
> ---
>  ovn/controller/lflow.h    |  1 +
>  ovn/controller/physical.c | 17 +++++++++++++----
>  2 files changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/ovn/controller/lflow.h b/ovn/controller/lflow.h
> index 4f284a0..418f59e 100644
> --- a/ovn/controller/lflow.h
> +++ b/ovn/controller/lflow.h
> @@ -50,6 +50,7 @@ struct uuid;
>   * you make any changes. */
>  #define OFTABLE_PHY_TO_LOG            0
>  #define OFTABLE_LOG_INGRESS_PIPELINE 16 /* First of LOG_PIPELINE_LEN
> tables. */
> +#define OFTABLE_ETH_UCAST            29
>  #define OFTABLE_REMOTE_OUTPUT        32
>  #define OFTABLE_LOCAL_OUTPUT         33
>  #define OFTABLE_CHECK_LOOPBACK       34
> diff --git a/ovn/controller/physical.c b/ovn/controller/physical.c
> index 0f1aa63..d34140f 100644
> --- a/ovn/controller/physical.c
> +++ b/ovn/controller/physical.c
> @@ -963,9 +963,9 @@ physical_run(struct controller_ctx *ctx, enum
> mf_field_id mff_ovn_geneve,
>
>          SBREC_PORT_BINDING_FOR_EACH (binding, ctx->ovnsb_idl) {
>              struct match match = MATCH_CATCHALL_INITIALIZER;
> -
> +            /* here need to optimize to do only once for every datapath
> */
>              if (!binding->chassis ||
> -                strcmp(tun->chassis_id, binding->chassis->name)) {
> +                binding->chassis != chassis) {
>                  continue;
>              }
>
> @@ -974,11 +974,20 @@ physical_run(struct controller_ctx *ctx, enum
> mf_field_id mff_ovn_geneve,
>
>              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);
> -            put_resubmit(OFTABLE_LOG_INGRESS_PIPELINE, &ofpacts);
> +            if (!strcmp(binding->type, "chassisredirect"))
> +            {
> +                put_load(binding->tunnel_key, MFF_LOG_OUTPORT, 0, 16,
> &ofpacts);
> +                put_resubmit(OFTABLE_LOCAL_OUTPUT, &ofpacts);
> +            }
> +            else
> +            {
> +                put_resubmit(OFTABLE_ETH_UCAST, &ofpacts);
> +            }
>
>              ofctrl_add_flow(flow_table, OFTABLE_PHY_TO_LOG, 100, 0,
> &match,
>                              &ofpacts);
> --
>
>
>
>
>
> 发件人:         王前宇10110202/user/zte_ltd
> 收件人:         Russell Bryant <russell at ovn.org>,
> 抄送:   Ben Pfaff <blp at ovn.org>, ovs dev <dev at openvswitch.org>,
> ovs-dev-bounces at openvswitch.org, xurong00037997 <xu.rong at zte.com.cn>
> 日期:   2017/05/05 09:30
> 主题:   答复: Re: [ovs-dev] 答复: Re: [PATCH] ovn-controller: Support
> vxlan tunnel in ovn
>
>
> We want to use ovn in the scenary that ovs-computer node and sriov
> computer node all managed by openstack.
> However, in our analysis that ovn-controller-vtep could only be used to
> forwards traffic between  networks managed by openstack and physical
> network openstack not managed.
> Do we misunderstand of the use of ovn-controller-vtep?
> Thanks,
>
>
>
>
>
>
> Russell Bryant <russell at ovn.org>
> 2017/05/05 02:12
>
>         收件人:        Ben Pfaff <blp at ovn.org>,
>         抄送:  wang.qianyu at zte.com.cn, ovs dev <dev at openvswitch.org>,
> xurong00037997 <xu.rong at zte.com.cn>, ovs-dev-bounces at openvswitch.org
>         主题:  Re: [ovs-dev] 答复: Re: [PATCH] ovn-controller: Support
> vxlan tunnel in ovn
>
>
> ovn-controller-vtep is discussed in the "Life Cycle of a VTEP Gateway"
> section in ovn-architecture(7).
>
> http://openvswitch.org/support/dist-docs/ovn-architecture.7.html
>
> On Thu, May 4, 2017 at 12:41 PM, Ben Pfaff <blp at ovn.org> wrote:
> > OVS already has a VXLAN hardware switch story via ovn-controller-vtep.
> >
> > On Thu, May 04, 2017 at 07:51:01PM +0800, wang.qianyu at zte.com.cn 
wrote:
> >> In most telecom carriers network architecture, they may demand 
hardware
> >> switches for performance consideration.
> >> The network architecture is as follow:
> >>
> >>         ---------------
> >>         |  ovn-sb     |
> >>         ---------------
> >>          |            |
> >>          |            |
> >> --------------     -----------------
> >> |ovn-controller|  |ovn-controller-hw|
> >> ---------------    ------------------
> >>    |   |                     |
> >> ----------------      ------------------
> >> |              |      |  hardware switch |
> >> |              |      -------------------
> >> |    ovs       |             |
> >> |computer node |      |----------------|
> >> |              |      |   sriov        |
> >> |              |      |                |
> >> |--------------|      | computer node  |
> >>                       ------------------
> >> Now, most hardware switches only support vxlan encapsulation. So we
> think
> >> if ovn could support vxlan
> >> encapsulation will be better. this is the reason that why we do the
> modify
> >> as the patch.
> >> Now, ovn used for the scenary of hardware-switches link to sriov
> >> network-card is very difficult,
> >> and we want do more works for ovn-controller-hw to support hardware
> >> switch.
> >> Do have some good idea about this scenary?
> >> Thanks
> >>
> >>
> >>
> >>
> >>
> >> Russell Bryant <russell at ovn.org>
> >> 发件人: ovs-dev-bounces at openvswitch.org
> >> 2017/05/04 10:57
> >>
> >>         收件人:        xurong00037997 <xu.rong at zte.com.cn>,
> >>         抄送:  ovs dev <dev at openvswitch.org>
> >>         主题:  Re: [ovs-dev] [PATCH] ovn-controller: Support vxlan
> tunnel
> >> in ovn
> >>
> >>
> >> On Wed, May 3, 2017 at 10:17 PM, xurong00037997 <xu.rong at zte.com.cn>
> >> wrote:
> >> > Because vxlan envelope have no enough fields to carry pipeline
> >> information
> >> > between ovs, so current ovn version do not support vxlan tunnel.
> >> > However, may only vxlan tunnel can be used in some special 
scenario.
> so
> >> we
> >> > think it is necessary to implement the function of vxlan. For this
> >> > purpose, we do the modifications as follow:
> >> >     1. packets received from vxlan jump to table 29 for outport
> finding
> >> >     2. add mac-binding information to table 29
> >> > ---
> >> >  ovn/controller/lflow.c    | 51
> >> +++++++++++++++++++++++++++++++++++++++++++++++
> >> >  ovn/controller/lflow.h    |  1 +
> >> >  ovn/controller/physical.c |  9 +++++----
> >> >  3 files changed, 57 insertions(+), 4 deletions(-)
> >> >  mode change 100644 => 100755 ovn/controller/lflow.c
> >> >  mode change 100644 => 100755 ovn/controller/lflow.h
> >> >  mode change 100644 => 100755 ovn/controller/physical.c
> >> >
> >>
> >> I'm interested in how you concluded that VXLAN support was needed.
> >> I've been looking at this question pretty extensively and have not
> >> been able to find any good justification for why VXLAN support should
> >> be added to OVN.
> >>
> >> Can you expand on what special scenarios you have in mind?
> >>
> >> Thanks,
> >>
> >> --
> >> Russell Bryant
> >> _______________________________________________
> >> dev mailing list
> >> dev at openvswitch.org
> >> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> >>
> >>
> >>
> >> _______________________________________________
> >> dev mailing list
> >> dev at openvswitch.org
> >> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> > _______________________________________________
> > dev mailing list
> > dev at openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
>
>
> --
> Russell Bryant
>
>
>
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
_______________________________________________
dev mailing list
dev at openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


_______________________________________________
dev mailing list
dev at openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


More information about the dev mailing list