Open Stack

On 28 October 2014 00:30, Li Tianqing <jazeltq at 163.com> wrote:

> lan, you are right, the receiver only receive packet that small than 1450.
> Because the sender does not send large packets at the begining, so
> tcpdump can catch some small packets.
>
> Another question about the mtu, what if we clear the  DF in the ip
> packets?  Then l2 can split packets into smaller mtu size?
>

Routers can split packets.  L2 networks don't understand IP headers and
therefore can't fragment packets.  DF doesn't change that.

(DF is there to make PMTU discovery work, incidentially; it's what prompts
routers to return PMTU exceeded messages.)
-- 
Ian.

At 2014-10-28 15:15:51, "Li Tianqing" <jazeltq at 163.com> wrote:
>
> The problem is that it is not at the begining to transmit large file. It
> is after some packets trasmited, then the connection is choked.
> After the connection choked, from the bridge in compute host we can see
> the sender send packets, and the receiver can not get the packets.
> If it is the pmtud, then at the very begining, the packet can not transmit
> from the begining.
>
> At 2014-10-28 14:10:09, "Ian Wells" <ijw.ubuntu at cack.org.uk> wrote:
>
> Path MTU discovery works on a path - something with an L3 router in the
> way - where the outbound interface has a smaller MTU than the inbound one.
> You're transmitting across an L2 network - no L3 routers present.  You send
> a 1500 byte packet, the network fabric (which is not L3, has no address,
> and therefore has no means to answer you) does all that it can do with that
> packet - it drops it.  The sender retransmits, assuming congestion, but the
> same thing happens.  Eventually the sender decides there's a network
> problem and times out.
>
> This is a common problem with Openstack deployments, although various
> features of the virtual networking let you get away with it, with some
> configs and not others.  OVS used to fake a PMTU exceeded message from the
> destination if you tried to pass an overlarge packet - not in spec, but it
> hid the problem nicely.  I have a suspicion that some implementations will
> fragment the containing UDP packet, which is also not in spec and also
> solves the problem (albeit with poor performance).
>
> The right answer for you is to set the MTU in your machines to the same
> MTU you've given the network, that is, 1450 bytes.  You can do this by
> setting a DHCP option for MTU, providing your VMs support that option
> (search the web for the solution, I don't have it offhand) or lower the MTU
> by hand or by script when you start your VM.
>
> The right answer for everyone is to properly determine and advertise the
> network MTU to VMs (which, with provider networks, is not even consistent
> from one network to the next) and that's the spec Kyle is referring to.
> We'll be fixing this in Kilo.
> --
> Ian.
>
>
> On 27 October 2014 20:14, Li Tianqing <jazeltq at 163.com> wrote:
>
>>
>>
>>
>>
>>
>> --
>> Best
>>     Li Tianqing
>>
>>
>> At 2014-10-27 17:42:41, "Ihar Hrachyshka" <ihrachys at redhat.com> wrote:
>> >-----BEGIN PGP SIGNED MESSAGE-----
>> >Hash: SHA512
>> >
>> >On 27/10/14 02:18, Li Tianqing wrote:
>> >> Hello, Right now, we test neutron under havana release. We
>> >> configured network_device_mtu=1450 in neutron.conf, After create
>> >> vm, we found the vm interface's mtu is 1500, the ping, ssh, is ok.
>> >> But if we scp large file between vms then scp display 'stalled'.
>> >> And iperf is also can not completed. If we configured vm's mtu to
>> >> 1450, then iperf, scp all is ok. If we iperf with -M 1300, then the
>> >> iperf is ok too. The vms path mtu discovery is set by default. I do
>> >> not know why the vm whose mtu is 1500 can not send large file.
>> >
>> >There is a neutron spec currently in discussion for Kilo to finally
>> >fix MTU issues due to tunneling, that also tries to propagate MTU
>> >inside instances: https://review.openstack.org/#/c/105989/
>>
>> The problem is i do not know why the vm with 1500 mtu can not send large file?
>> I found the packet send out all with DF, and is it because the DF set default by linux cause the packet
>> be dropped? And the application do not handle the return back icmp packet with the smaller mtu?
>>
>>  >
>> >/Ihar
>> >-----BEGIN PGP SIGNATURE-----
>> >Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
>> >
>> >iQEcBAEBCgAGBQJUThORAAoJEC5aWaUY1u571u4H/3EqEVPL1Q9KgymrudLpAdRh
>> >fwNarwPWT8Ed+0x7WIXAr7OFXX1P90cKRAZKTlAEEI94vOrdr0s608ZX8awMuLeu
>> >+LB6IA7nMpgJammfDb8zNmYLHuTQGGatXblOinvtm3XXIcNbkNu8840MTV3y/Jdq
>> >Mndtz69TrjTrjn7r9REJ4bnRIlL4DGo+gufXPD49+yax1y/woefqwZPU13kO6j6R
>> >Q0+MAy13ptg2NwX26OI+Sb801W0kpDXby6WZjfekXqxqv62fY1/lPQ3oqqJBd95K
>> >EFe5NuogLV7UGH5vydQJa0eO2jw5lh8qLuHSShGcDEp/N6oQWiDzXYYYoEQdUic=
>> >=jRQ/
>> >-----END PGP SIGNATURE-----
>> >
>> >_______________________________________________
>> >OpenStack-dev mailing list
>> >OpenStack-dev at lists.openstack.org
>> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141028/0bf2ef3b/attachment.html>