openstack team mailing list archive

[Sylvain Bauza <sylvain.bauza@xxxxxxxxxxxx>]

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@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?

[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