Hi, Ole Is there a general rule to set the MTU in overlay networks to avoid fragmentation?
Currently I saw the interface's MTU is 9000 in VPP by default. So can we assume the intermedia router/switch to the tunnel end point can handle the jumbo frame correctly? Thus even the mtu of tunnel end point is smaller, as long as the VPP IP reassembly work correctly. Now my tests showed the IP fragmentation works for VxLAN, while not for IPSec. Thx, Xuekun -----Original Message----- From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Ole Troan Sent: Wednesday, November 14, 2018 8:16 PM To: Prashant Upadhyaya <praupadhy...@gmail.com> Cc: vpp-dev@lists.fd.io Subject: Re: [vpp-dev] Regarding IP Fragmentation Prashant, > Imagine a usecase where I am getting IP packets on my graph node. > I encapsulate them into an outer IP and send them out. > So let's say in my example, I get IP1 and IP2. IP1 is max mtu size and > IP2 is a shorter one. Perhaps they themselves are part of a fragmented > flow. > I now encapsulate IP1 with an outer IP for tunneling. This topples the > mtu size and I send it out ip4-lookup, and in my for loop I operate on > IP2 also and encapsulate it in outer IP and send it again to > ip4-lookup. This triggers my usecase that I described earlier. You can > imagine that effectively I have managed to reorder the original IP > flow (now the inner IP packet) towards the final receiver which is > never good for eg. end to end TCP flows. Indeed. Which is why MTU in overlay networks should be well managed, to avoid fragmentation. And TCP MSS set “correctly”. Could we do something in VPP to avoid reordering fragment? Very likely. Is it worth it given that this should largely be a misconfiguration. Dunno. That said, any patch is welcome. ;-) Cheers, Ole
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#11247): https://lists.fd.io/g/vpp-dev/message/11247 Mute This Topic: https://lists.fd.io/mt/28133898/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
