Open Stack

On 03/08/2013 09:55 AM, Aaron Rosen wrote:
> Hi Sylvain,
>
>
> This seems very odd to me. The reason this should happen is if your
> client is sending packets with the DF (don't fragment) bit set in the
> TCP header of the packets you are sending. I'd confirm that  your
> version of 'curl' is doing this (which it should definitely not do!).

Why shouldn't a TCP connection initiated by curl (or anything else) have 
Path MTU discovery enabled? (ie the DF bit set in the IP datagrams 
carrying the TCP segments)

> What should happen is the router should fragment the packets for you
> and if a fragment is lost TCP will just re-transmit the full packet
> again and things should eventually work....

Here I thought all the IETF demigods considered IP Fragmentation 'To Be 
Avoided (tm)' - hence the creation of Path MTU discovery in the first 
place. :)

FWIW, in the IPv6 world, routers do not fragment.  That implies either 
functioning PathMTU discovery, or lowest common MTU...

>
> Aaron
>
>
> On Fri, Mar 8, 2013 at 9:08 AM, Sylvain Bauza
> <sylvain.bauza at digimind.com> wrote:
>> Hi,
>>
>> I recently observed a strange behaviour with L3 Quantum routing (Openvswitch
>> setup with Provider Router). A simple curl to an external website is
>> sometimes failing due to packet size  :
>>
>>      192.168.10.3 > X.X.X.X: ICMP 192.168.10.3 unreachable - need to frag
>> (mtu 1454), length 556
>>      IP (tos 0x0, ttl 48, id 25918, offset 0, flags [DF], proto TCP (6),
>> length 1500)

Why is the ICMP Destination Unreachable datagram being sent back so 
large?  I would have expected it to be rather smaller - an Ethernet, IP 
and ICMP header, and then the original IP header and something like 8 
bytes or so of the original IP datagram's payload.

I take it that ICMP is not getting back to the original sender? Or is 
being ignored?


>>
>> Only changing the VM MTU to 1454 does the trick ('ifconfig eth0 mtu 1454').
>>
>> For info, 192.168.10.3 is the floating IP bound to 10.0.0.4 (private IP).

I suppose if 10.0.0.4 doesn't explicitly know about 192.168.10.3 it 
might indeed ignore the ICMP message.  Assuming it isn't getting 
un-NATted on the way back.

rick jones

>>
>> I can't provide the URL for reproducing, as the external website is actually
>> an external corporate webservice.
>> Do you have any idea on what could be the root cause, and how to fix it ?
>>
>> Thanks,
>> -Sylvain
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack at lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>