Hi Darragh, Yes, on the same net-node machine, Grizzly works, Havana don't... But, for Grizzly, I have Ubuntu 12.04 with Linux 3.2 and OVS 1.4.0-1ubuntu1.6.
If I replace the Havana net-node hardware entirely, the problem persist (i.e. it "follows" Havana net-node), so, I think, it can not be related to the hardware. I tried Havana with both OVS 1.10.2 (from Cloud Archive) and with OVS 1.11.0 (compiled and installed by myself using dpkg-buildpackage / dpkg). My logs (including Open vSwitch) right after starting an Instance (nothing at OVS logs): http://paste.openstack.org/show/49870/ I tried everything, including installing the Network Node on top of a KVM virtual machine or directly on a dedicated server, same result, the problem follows Hanava node (virtual or physical). Grizzly Network Node works both on a KVM VM or on a dedicated server. Regards, Thiago On 26 October 2013 06:28, Darragh OReilly <darragh.orei...@yahoo.com> wrote: > Hi Thiago, > > so just to confirm - on the same netnode machine, with the same OS, kernal > and OVS versions - Grizzly is ok and Havana is not? > > Also, on the network node, are there any errors in the neutron logs, the > syslog, or /var/log/openvswitch/* ? > > Re, Darragh. > > > On Saturday, 26 October 2013, 5:25, Martinx - ジェームズ < > thiagocmarti...@gmail.com> wrote: > > LOL... One day, Internet via "Quantum Entanglement"! Oops, Neutron! =P > > 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. > > 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! :-/ > > Why I'm giving it up (of L3 / NS) for now? Because I tried: > > The option "tenant_network_type" with gre, vxlan and vlan (range > physnet1:206:256 configured at the 3Com switch as tagged). > > From the instances, the connection with External network *is always slow*, > no matter if I choose for Tenants, GRE, VXLAN or VLAN. > > For example, right now, I'm using VLAN, same problem. > > 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. > > If someone wants to debug it, I can give the root password, no problem, it > is just a lab... =) > > Thanks! > Thiago > > On 25 October 2013 19:45, Rick Jones <rick.jon...@hp.com> wrote: > > On 10/25/2013 02:37 PM, Martinx - ジェームズ wrote: > > WOW!! Thank you for your time Rick! Awesome answer!! =D > > I'll do this tests (with ethtool GRO / CKO) tonight but, do you think > that this is the main root of the problem?! > > > I mean, I'm seeing two distinct problems here: > > 1- Slow connectivity to the External network plus SSH lags all over the > cloud (everything that pass trough L3 / Namespace is problematic), and; > > 2- Communication between two Instances on different hypervisors (i.e. > maybe it is related to this GRO / CKO thing). > > > So, two different problems, right?! > > > 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. > > 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 :) > > rick jones > > > > >
_______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
