Hi Thiago,
I updated your bug report with my own tests and I don't experience your
performance issues.
George
On Tue, Nov 19, 2013 at 6:53 PM, Martinx - ジェームズ
thiagocmarti...@gmail.comwrote:
Okay!
BUG filled: https://bugs.launchpad.net/neutron/+bug/1252900
Regards,
Thiago
On 19
Yup :)
On 18 Nov 2013, at 22:09, Martinx - ジェームズ wrote:
Guys,
Can I fill a BUG about this issue?! If yes, where?! Neutron Launchpad
page?
Tks,
Thiago
On 12 November 2013 04:24, Martinx - ジェームズ
thiagocmarti...@gmail.comwrote:
At least one guy from Rackspace is aware of this problem,
Okay!
BUG filled: https://bugs.launchpad.net/neutron/+bug/1252900
Regards,
Thiago
On 19 November 2013 16:00, Razique Mahroua razique.mahr...@gmail.comwrote:
Yup :)
On 18 Nov 2013, at 22:09, Martinx - ジェームズ wrote:
Guys,
Can I fill a BUG about this issue?! If yes, where?! Neutron
I suddenly have the identical situation occurring here - of note I am
using grizzly and there have been two changes to the environment that have
seemingly caused this : upgrade of OVS to 1.11 and upgrade of quantum-*
from 2013.1.2 to 2013.1.3
I haven’t tried the default 1.04 from 12.04 and I
On 11/09/2013 07:09 PM, Martinx - ジェームズ wrote:
Guys,
This problem is kind of a deal breaker... I was counting on OpenStack
Havana (and with Ubuntu) for my first public cloud that I'm (was) about
to announce / launch but, this problem changed everything.
I can not put Havana with Ubuntu LTS
Hi Jay!
Thank you! I'll definitely take a look at those cookbooks but, I already
tried Havana (Cloud Archive) with OVS 1.11.0, same poor results.
Also, my previous region based on Grizzly / Quantum / GRE, worked perfectly
for months (except with MTU = 1400) and, Havana is somehow different.
On 11/10/2013 01:35 PM, Martinx - ジェームズ wrote:
Hi Jay!
Thank you! I'll definitely take a look at those cookbooks but, I already
tried Havana (Cloud Archive) with OVS 1.11.0, same poor results.
Also, my previous region based on Grizzly / Quantum / GRE, worked
perfectly for months (except
Cool! Let me know what do you'll need.
I'll make a tenant / project / user for you here at my cloud and I can give
you root access to the network node (or any openstack node).
Let me know if it is enough for you to debug / test it.
Cheers!
Thiago
On 10 November 2013 07:34, James Page
Guys,
This problem is kind of a deal breaker... I was counting on OpenStack
Havana (and with Ubuntu) for my first public cloud that I'm (was) about to
announce / launch but, this problem changed everything.
I can not put Havana with Ubuntu LTS into production because of this
network issue. This
Thiago,
some more answers below.
Btw: I saw the problem with a qemu-nbd -c process using all the cpu on the
compute. It happened just once - must be a bug in it. You can disable libvirt
injection if you don't want it by setting libvirt_inject_partition = -2 in
nova.conf.
On Saturday, 26
Stackers,
I have a small report from my latest tests.
Tests:
* Namespace (br-ex) *-* Internet - OK
* Namespace (vxlan,gre,vlan) *-* Tenant - OK
* Tenant *-* Namespace *-* Internet - *NOT-OK* (Very slow / Unstable /
Intermittent)
Since the connectivity from Tenant to its Namespace is fine
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
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
Hi Thiago,
you have configured DHCP to push out a MTU of 1400. Can you confirm that the
1400 MTU is actually getting out to the instances by running 'ip link' on them?
There is an open problem where the veth used to connect the OVS and Linux
bridges causes a performance drop on some kernels -
Hi Thiago,
for the VIF error: you will need to change qemu.conf as described here:
http://openvswitch.org/openstack/documentation/
Re, Darragh.
On Friday, 25 October 2013, 15:14, Martinx - ジェームズ thiagocmarti...@gmail.com
wrote:
Hi Darragh,
Yes, Instances are getting MTU 1400.
I'm
the uneven ssh performance is strange - maybe learning on the tunnel mesh is
not stablizing. It is easy to mess it up by giving a wrong local_ip in the
ovs-plugin config file. Check the tunnels ports on br-tun with 'ovs-vsctl
show'. Is each one using the correct IPs? Br-tun should have N-1
Here we go:
---
root@net-node-1:~# grep local_ip
/etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini
local_ip = 10.20.2.52
root@net-node-1:~# ip r | grep 10.\20
10.20.2.0/24 dev eth1 proto kernel scope link src 10.20.2.52
---
---
root@hypervisor-1:~# grep local_ip
ok, the tunnels look fine. One thing that looks funny on the network node are
these untagged tap* devices. I guess you switched to using veths and then
switched back to not using them. I don't know if they matter, but you should
clean them up by stopping everthing, running
Okay, cool!
tap** removed, neutron-ovs-cleanup ok, bridges empty, all nodes rebooted.
BUT, still poor performance when reaching External network from within a
Instance (plus SSH lags)... [?]
I'll install a new Network Node, in another hardware, to test it more...
Weird thing is, my Grizzly
Hi Rick,
On 25 October 2013 13:44, Rick Jones rick.jon...@hp.com wrote:
On 10/25/2013 08:19 AM, Martinx - ジェームズ wrote:
I think can say... YAY!!:-D
With LibvirtOpenVswitchDriver my internal communication is the double
now! It goes from ~200 (with LibvirtHybridOVSBridgeDriver) to
You can use ethtool -k eth0 to view the setting and use ethtool -K eth0
gro off to turn off GRO.
On Fri, Oct 25, 2013 at 3:03 PM, Martinx - ジェームズ
thiagocmarti...@gmail.comwrote:
Hi Rick,
On 25 October 2013 13:44, Rick Jones rick.jon...@hp.com wrote:
On 10/25/2013 08:19 AM, Martinx - ジェームズ
Listen, maybe this sounds too dumb from my part but, it is the first
time I'm talking about this stuff (like NIC peer-into GRE ?, or GRO
/ CKO...
No worries.
So, a slightly brief history of stateless offloads in NICs. It may be
too basic, and I may get some details wrong, but it should give
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
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
I was able to enable ovs_use_veth and start Instances (VXLAN / DHCP /
Metadata Okay)... But, same problem when accessing External network.
BTW, I have valid Floating IPs and easy access to the Internet from the
Network Node, if someone wants to debug, just ping a message.
On 26 October 2013
To: Martinx - ジェームズ
Cc: Speichert,Daniel; openstack@lists.openstack.org
Subject: Re: [Openstack] Directional network performance issues with Neutron
+ OpenvSwitch
On Thu, Oct 24, 2013 at 10:37 AM, Martinx - ジェームズ
thiagocmarti...@gmail.com wrote:
Precisely!
The doc currently says
James,
I think I'm hitting this problem.
I'm using Per-Tenant Routers with Private Networks, GRE tunnels and
L3+DHCP Network Node.
The connectivity from behind my Instances is very slow. It takes an
eternity to finish apt-get update.
If I run apt-get update from within tenant's Namespace, it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 03/10/13 04:43, Martinx - ジェームズ wrote:
Mmm... I am unable to compile openvswitch-datapath-dkms from
Havana Ubuntu Cloud Archive (on top of a fresh install of Ubuntu
12.04.3), look:
There is a bug in that version; I'm deploying from
Cool! The `ppa:ubuntu-cloud-archive/havana-staging' is the repository I was
looking for. It works now... Thanks!
On 3 October 2013 03:02, James Page james.p...@ubuntu.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 03/10/13 04:43, Martinx - ジェームズ wrote:
Mmm... I am unable to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/10/13 22:49, James Page wrote:
sudo ip netns exec qrouter-d3baf1b1-55ee-42cb-a3f6-9629288e3221
traceroute -n 10.5.0.2 -p 4 --mtu traceroute to 10.5.0.2
(10.5.0.2), 30 hops max, 65000 byte packets 1 10.5.0.2 0.950
ms F=1500 0.598 ms
On 10/02/2013 02:14 AM, James Page wrote:
I tcpdump'ed the traffic and I see alot of duplicate acks which makes
me suspect some sort of packet fragmentation but its got me puzzled.
Anyone have any ideas about how to debug this further? or has anyone
seen anything like this before?
Duplicate
Hi James, have you tried setting the MTU to a lower number of bytes,
instead of a higher-than-1500 setting? Say... 1454 instead of 1546?
Curious to see if that resolves the issue. If it does, then perhaps
there is a path somewhere that had a 1546 PMTU?
-jay
On 10/02/2013 05:14 AM, James
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi Gangur
On 02/10/13 17:24, Gangur, Hrushikesh (R D HP Cloud) wrote:
http://techbackground.blogspot.co.uk/2013/06/path-mtu-discovery-and-gre.html
Yeah
- - I read that already:
sudo ip netns exec qrouter-d3baf1b1-55ee-42cb-a3f6-9629288e3221
On 10/02/2013 12:17 PM, James Page wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi Jay
On 02/10/13 16:37, Jay Pipes wrote:
Hi James, have you tried setting the MTU to a lower number of
bytes, instead of a higher-than-1500 setting? Say... 1454 instead
of 1546?
Curious to see if that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/10/13 17:28, Jay Pipes wrote:
On 02/10/13 16:37, Jay Pipes wrote:
Hi James, have you tried setting the MTU to a lower number of
bytes, instead of a higher-than-1500 setting? Say... 1454
instead of 1546?
Curious to see if that resolves
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/10/13 17:33, James Page wrote:
On 02/10/13 17:24, Gangur, Hrushikesh (R D HP Cloud) wrote:
http://techbackground.blogspot.co.uk/2013/06/path-mtu-discovery-and-gre.html
Yeah
- I read that already:
sudo ip netns exec
Hi James,
Let me ask you something...
Are you using the package `openvswitch-datapath-dkms' from Havana Ubuntu
Cloud Archive with Linux 3.8?
I am unable to compile that module on top of Ubuntu 12.04.3 (with Linux
3.8) and I'm wondering if it is still required or not...
Thanks!
Thiago
On 2
I believe it's still needed: upstream kernel have pushed back against
the modules it provides, but neutron needs them to deliver the gre
tunnels.
-Rob
On 3 October 2013 13:15, Martinx - ジェームズ thiagocmarti...@gmail.com wrote:
Hi James,
Let me ask you something...
Are you using the package
Mmm... I am unable to compile openvswitch-datapath-dkms from Havana Ubuntu
Cloud Archive (on top of a fresh install of Ubuntu 12.04.3), look:
--
root@havabuntu-1:~# uname -a
Linux havabuntu-1 3.8.0-31-generic #46~precise1-Ubuntu SMP Wed Sep 11
18:21:16 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
39 matches
Mail list logo
