On 28 October 2014 00:30, Li Tianqing <[email protected]> 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" <[email protected]> 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" <[email protected]> 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 <[email protected]> wrote: > >> >> >> >> >> >> -- >> Best >> Li Tianqing >> >> >> At 2014-10-27 17:42:41, "Ihar Hrachyshka" <[email protected]> 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 >> >[email protected] >> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
