<div style="line-height:1.7;color:#000000;font-size:14px;font-family:Arial"><div>One more question.</div><div>Vxlan use udp, how can vxlan promise reliability.</div><div><br></div>ÔÚ 2014-10-28 15:51:02£¬"Ian Wells" <ijw.ubuntu@cack.org.uk> дµÀ£º<br> <blockquote id="isReplyContent" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 28 October 2014 00:30, Li Tianqing <span dir="ltr"><<a href="mailto:jazeltq@163.com" target="_blank">jazeltq@163.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="line-height:1.7;color:#000000;font-size:14px;font-family:Arial"><div>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</div><div>tcpdump can catch some small packets. </div><div><br></div><div>Another question about the mtu, what if we clear the DF in the ip packets? Then l2 can split packets into smaller mtu size?</div></div></blockquote><div><br></div><div>Routers can split packets. L2 networks don't understand IP headers and therefore can't fragment packets. DF doesn't change that. <br><br></div><div>(DF is there to make PMTU discovery work, incidentially; it's what prompts routers to return PMTU exceeded messages.)<br>-- <br></div><div>Ian.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="line-height:1.7;color:#000000;font-size:14px;font-family:Arial"><div><div class="h5">At 2014-10-28 15:15:51, "Li Tianqing" <<a href="mailto:jazeltq@163.com" target="_blank">jazeltq@163.com</a>> wrote:<br> <blockquote style="PADDING-LEFT:1ex;MARGIN:0px 0px 0px 0.8ex;BORDER-LEFT:#ccc 1px solid"><div style="line-height:1.7;color:#000000;font-size:14px;font-family:Arial"><div>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. </div><div>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.</div><div>If it is the pmtud, then at the very begining, the packet can not transmit from the begining.</div><div><br></div>At 2014-10-28 14:10:09, "Ian Wells" <<a href="mailto:ijw.ubuntu@cack.org.uk" target="_blank">ijw.ubuntu@cack.org.uk</a>> wrote:<br> <blockquote style="PADDING-LEFT:1ex;MARGIN:0px 0px 0px 0.8ex;BORDER-LEFT:#ccc 1px solid"><div dir="ltr"><div><div>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.</div><div><br>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).<br><br>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.<br><br></div>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.<br>-- <br></div>Ian.<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 27 October 2014 20:14, Li Tianqing <span dir="ltr"><<a href="mailto:jazeltq@163.com" target="_blank">jazeltq@163.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="line-height:1.7;color:#000000;font-size:14px;font-family:Arial"><br><br><br><br><br><div>--<br><div>Best</div><div> Li Tianqing</div></div><div></div><br><pre><span><br>At 2014-10-27 17:42:41, "Ihar Hrachyshka" <<a href="mailto:ihrachys@redhat.com" target="_blank">ihrachys@redhat.com</a>> 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
<div>>inside instances: <a href="https://review.openstack.org/#/c/105989/" target="_blank">https://review.openstack.org/#/c/105989/</a></div><div><br></div></span><div>The problem is i do not know why the vm with 1500 mtu can not send large file? </div><div>I found the packet send out all with DF, and is it because the DF set default by linux cause the packet</div><div>be dropped? And the application do not handle the return back icmp packet with the smaller mtu?</div><span><div><br></div><div> </div>>
>/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
><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</span></pre></div><br><br><span title="neteasefooter"><span></span></span><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br><br><span title="neteasefooter"><span></span></span></blockquote></div></div></div><br><br><span title="neteasefooter"><span></span></span><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>
</blockquote></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>