Open Stack

Hi Rick, reply inline.

Le 08/03/2013 20:27, Rick Jones a écrit :
> 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)
>

[SBA] Thanks for the explanation of the DF flag
>> 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?
>
>

[SBA] I take the point. That means that PathMTU is not working for my 
Quantum installation. I also had a Nova-network (FlatDHCP mode) and I 
didn't noticed the issue. So, I assume something is wrong with my config.


>>>
>>> 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.
>

[SBA] This *is* un-NAT'd on the way back. By tcpdump'ing with the '-i 
any' interface, I can see the DNAT mapping on the way back :


Do you have any idea on what I should fix (or at least workaround) to 
have PathMTU working ?
By the way, I did check and both client (10.0.0.4) and server (X.X.X.X) 
have MTU set to 1500. I can't understand why the server is asking for a 
fragment size of 1454.

Thanks,
-Sylvain