Open Stack

Can you clarify what you mean with the thrashing condition? MAC addresses
only need to be unique per-VLAN so I don't see how the same MAC on multiple
VLANs from the same physical port would lead to any issues.

On Wed, Sep 17, 2014 at 12:41 PM, Armando M. <armamig at gmail.com> wrote:

> VLAN is on the radar, vxlan/gre was done to start with.
>
> I believe Vivek mentioned the rationale in some other thread. The gist
> of it below:
>
> In the current architecture, we use a unique DVR MAC per compute node
> to forward DVR Routed traffic directly to destination compute node.
> The DVR routed traffic from the source compute node will carry
> 'destination VMs underlay VLAN' in the frame, but the Source Mac in
> that same frame will be the DVR Unique MAC. So, same DVR Unique Mac is
> used for potentially a number of overlay network VMs that would exist
> on that same source compute node.
>
> The underlay infrastructure switches will see the same DVR Unique MAC
> being associated with different VLANs on incoming frames, and so this
> would result in VLAN Thrashing on the switches in the physical cloud
> infrastructure. Since tunneling protocols carry the entire DVR routed
> inner frames as tunnel payloads, there is no thrashing effect on
> underlay switches.
>
> There will still be thrashing effect on endpoints on CNs themselves,
> when they try to learn that association between inner frame source MAC
> and the TEP port on which the tunneled frame is received. But that we
> have addressed in L2 Agent by having a 'DVR Learning Blocker' table,
> which ensures that learning for DVR routed packets alone is
> side-stepped.
>
> As a result, VLAN was not promoted as a supported underlay for the
> initial DVR architecture.
>
> Cheers,
> Armando
>
> On 16 September 2014 20:35, 龚永生 <gongysh at unitedstack.com> wrote:
> > I think the VLAN should also be supported later.  The tunnel should not
> be
> > the prerequisite for the DVR feature.
> >
> >
> > ------------------ Original ------------------
> > From:  "Steve Wormley"<openstack at wormley.com>;
> > Date:  Wed, Sep 17, 2014 10:29 AM
> > To:  "openstack-dev"<openstack-dev at lists.openstack.org>;
> > Subject:  [openstack-dev] [neutron] DVR Tunnel Design Question
> >
> > In our environment using VXLAN/GRE would make it difficult to keep some
> of
> > the features we currently offer our customers. So for a while now I've
> been
> > looking at the DVR code, blueprints and Google drive docs and other than
> it
> > being the way the code was written I can't find anything indicating why a
> > Tunnel/Overlay network is required for DVR or what problem it was
> solving.
> >
> > Basically I'm just trying to see if I missed anything as I look into
> doing a
> > VLAN/OVS implementation.
> >
> > Thanks,
> > -Steve Wormley
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140917/532e8e29/attachment.html>