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