Hujie,
> Thanks. We try to change the MTU value to send the big packets which are more
> than 1500 or 1460 Bytes but it is only a temporary way limited in the Lab.
> And we hope to find a tools or some codes which can be put into the VPP or
> DPDK to fragment the big packets to less than 1460 bytes automatically.
As I replied above, VPP will fragment automatically, given the restrictions
above.
E.g. it might be that VXLAN tunnel head end sets DF=1 or doesn’t set the
locally originated flag on the packet.
A packet trace should give you a better hint. Or just set a breakpoint in
ip{4,6}_path_mtu_check()
Cheers,
Ole
> From: Yang, Zhiyong
> Date: 2018-09-27 15:37
> To: Ole Troan
> CC: vpp-dev@lists.fd.io; Kinsella, Ray; hujie....@chinatelecom.cn; Liu, Frank
> M
> Subject: RE: [vpp-dev] one question about IP fragment
> Ole, thanks so much for your warm help.
>
> > The next steps for tunnels, to help avoid fragmentation is to add some sort
> > of
> > tunnel path MTU discovery.
>
> It looks very interesting and helpful. And I'm looking forward to seeing it.
>
> However, we fail to send big packet greater than MTU now, for example,
> We have MTU = 1500, when 1500bytes packets are encapped by vxlan protocol,
> of course, the size of packets is bigger than MTU at the time ,
> it looks that sending packets fails now.
>
> BTW
> Is DPDK IP fragment/reassembly supported in VPP now?
>
> Thanks
> Zhiyong
>
> > -----Original Message-----
> > From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Ole
> > Troan
> > Sent: Wednesday, September 26, 2018 7:06 PM
> > To: Yang, Zhiyong <zhiyong.y...@intel.com>
> > Cc: vpp-dev@lists.fd.io; Kinsella, Ray <ray.kinse...@intel.com>
> > Subject: Re: [vpp-dev] one question about IP fragment
> >
> > Zhiyong,
> >
> > > When I use vxlan in both VM and physical machine , packet
> > > drop issue
> > is come across, after setting VPP MTU = 1600, this issue will disappear.
> > As we
> > all know, some of routes on the network doesn’t support more than 1518 bytes
> > packet.
> > > Should I try to use IP fragment in this case? Or any other better
> > > solution?
> > Does VPP IP fragment work now? If yes, Could you show me how to configure?
> > Thank you very much.
> >
> > Fragmentation now works. Currently both for IPv4 and IPv6 packets are
> > fragmented in ip{4,6}_rewrite. Note that only locally originated IPv6
> > packets can
> > be fragmented, and only IPv4 packets with DF = 0.
> > Assuming the above two restrictions are adhered to, if the VXLAN node sent
> > packets larger than the outgoing interface MTU they should be fragmented
> > now.
> > There is no configuration for fragmentation. (Although I am thinking of
> > adding a
> > knob, with default disabled).
> >
> > For reassembly, VPP has a short-coming, It can only reassemble as an input
> > feature, meaning all fragments, even though not destined for the VPP
> > instance
> > itself are reassembled.
> > I think Juraj is working on a fix for that.
> >
> > The next steps for tunnels, to help avoid fragmentation is to add some sort
> > of
> > tunnel path MTU discovery.
> >
> > But in short, you are much better off with a well managed MTU, than you are
> > with fragmentation.
> > See our draft in intarea for a list:
> > https://tools.ietf.org/html/draft-ietf-intarea-
> > frag-fragile-00
> >
> > Cheers,
> > Ole
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#10684): https://lists.fd.io/g/vpp-dev/message/10684
Mute This Topic: https://lists.fd.io/mt/26229382/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
