<div dir="ltr"><div>LOL... One day, Internet via "Quantum Entanglement"! Oops, Neutron!     =P<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">I'll ignore the problems related to the "performance between two instances on different hypervisors" for now. My priority is the connectivity issue with the External networks... At least, internal is slow but it works.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">I'm about to remove the L3 Agent / Namespaces entirely from my topology... It is a shame because it is pretty cool! With Grizzly I had no problems at all. Plus, I need to put Havana into production ASAP!    :-/</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">Why I'm giving it up (of L3 / NS) for now? Because I tried:</div><div class="gmail_extra"><br></div><div class="gmail_extra">The option "tenant_network_type" with gre, vxlan and vlan (range physnet1:206:256 configured at the 3Com switch as tagged).</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">From the instances, the connection with External network <b>is always slow</b>, no matter if I choose for Tenants, GRE, VXLAN or VLAN.</div><div class="gmail_extra">

<br></div><div class="gmail_extra">For example, right now, I'm using VLAN, same problem.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Don't you guys think that this can be a problem with the bridge "br-ex" and its internals ? Since I swapped the "Tenant Network Type" 3 times, same result... But I still did not removed the br-ex from the scene.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">If someone wants to debug it, I can give the root password, no problem, it is just a lab...   =)</div><div class="gmail_extra"><br></div><div class="gmail_extra">

Thanks!</div><div class="gmail_extra">Thiago</div><div class="gmail_extra"><br><div class="gmail_quote">On 25 October 2013 19:45, Rick Jones <span dir="ltr"><<a href="mailto:rick.jones2@hp.com" target="_blank">rick.jones2@hp.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On 10/25/2013 02:37 PM, Martinx - $B%8%'!<%`%:(B wrote:<br>


<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
WOW!! Thank you for your time Rick! Awesome answer!!    =D<br>
<br>
I'll do this tests (with ethtool GRO / CKO) tonight but, do you think<br>
that this is the main root of the problem?!<br>
<br>
<br>
I mean, I'm seeing two distinct problems here:<br>
<br>
1- Slow connectivity to the External network plus SSH lags all over the<br>
cloud (everything that pass trough L3 / Namespace is problematic), and;<br>
<br>
2- Communication between two Instances on different hypervisors (i.e.<br>
maybe it is related to this GRO / CKO thing).<br>
<br>
<br>
So, two different problems, right?!<br>
</blockquote>
<br></div>
One or two problems I cannot say.    Certainly if one got the benefit of stateless offloads in one direction and not the other, one could see different performance limits in each direction.<br>
<br>
All I can really say is I liked it better when we were called Quantum, because then I could refer to it as "Spooky networking at a distance."  Sadly, describing Neutron as "Networking with no inherent charge" doesn't work as well :)<span class=""><font color="#888888"><br>


<br>
rick jones<br>
<br>
</font></span></blockquote></div><br></div></div>