Open Stack

Hi Rick!

Back with Grizzly, I faced that problem and I was able to detect it, at the
Network Node with tcpdump and fix it by running "ip link set mtu 1454 dev
eth0" within the Instance.

Not this time... This is another problem...   ;-/


On 22 October 2013 13:25, Rick Jones <rick.jones2 at hp.com> wrote:

> On 10/22/2013 01:32 AM, Martinx - ジェームズ wrote:
>
>> Stackers,
>>
>> I'm trying to put my Havana into production and I'm facing a very
>> strange problem.
>>
>> The Internet connectivity from tenant's subnet is very, very slow. It is
>> useless in fact... I can not even use "apt-get update" from a Instance.
>>
>> The following command works (apt update from the tenant namespace):
>>
>> ---
>> root at net-node-1:~# ip netns exec qrouter-XXXXXXXXX aptitude update
>> ---
>>
>> But not from the tenant subnet...
>>
>> I'm following this topology:
>>
>> http://docs.openstack.org/**trunk/install-guide/install/**
>> apt/content/section_use-cases-**tenant-router.html<http://docs.openstack.org/trunk/install-guide/install/apt/content/section_use-cases-tenant-router.html>
>>
>> Already tried to change MTUs (via DHCP agent)... Nothing had fixed this
>> weird issue.
>>
>> Any thoughts?!
>>
>> Right now, my "aptitude safe-upgrade" will take 2 days to download
>> 60MB... During this network outages, even the SSH session stops
>> responding for a few seconds...
>>
>> Everything else seems to be working as expected, as for example, DHCP,
>> Floating IPs, Security Groups...
>>
>> Sometimes, even the first ssh connection to the Instance Floating IP,
>> have a lag.
>>
>
> It is but a guess, but I wonder if, even with changing MTUs (to what
> values?) you may still be experiencing a PathMTU+ICMP blackhole problem
> accessing nodes on the Internet.  Can you access something that is a bit
> "closer" but still outside your stack so you have a shot at looking at
> netstat statistics on the sender and/or get packet traces on the sender?
>
> You could still try taking packet traces at the instance or perhaps the
> namespace and try to discern packet losses at the receiving side, though it
> can be a bit more difficult.
>
> rick jones
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20131022/051a27e4/attachment.html>