Open Stack

I also forgot to mention: I'm using a typical Openvswitch setup with GRE 
encapsulation.
I can't proof, but would GRE not able to work with PathMTU ?

-Sylvain

Le 11/03/2013 09:40, Sylvain Bauza a écrit :
> 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
>