openstack team mailing list archive

[Aaron Rosen <arosen@xxxxxxxxxx>]

Hi Rick,

You are right. I just ran curl to test for myself and it does set the
DF bit. Why is this? Any ideas why it specifies that the packet cannot
be fragmented?

Thanks,

Aaron

On Fri, Mar 8, 2013 at 11:27 AM, Rick Jones <rick.jones2@xxxxxx> wrote:
> 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@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>