Jon, Thanks for bringing this up. In addition to Matus’ answer.
There is a distinction to be made between forwarding and terminating traffic. And there is a nice grey middle ground between the two. Some features does forwarding on the transport header, like NAT, MAP-E, MAP-T and so on, those do not require reassembling the fragment chain, and do forward fragments in flights, aka virtual reassembly. Tunnels with outer fragmentation require full reassembly (the packets are addresses to the node itself), before forwarding. But you could also argue that there are features like ACL, firewalls, legal intercept whatnot that would benefit from doing a full reassembly while forwarding. a) Virtual reassembly b) Full reassembly for terminating traffic (for-us / host) c) Full reassembly for forwarding traffic for specific features requiring that From a quick glance it seems like the current reassembly feature is doing c. And doing it without any level of granularity. Meaning that if you need outer reassembly for an IP in IP tunnel, you’d suddenly also reassemble all IP traffic. Which is unwanted and costly. That should be easy to fix. Klement? So you are right if you combine the current reassembly (c) with NAT, NAT does not deal with the fragments. But at a much higher cost than virtual reassembly of course. I propose we move default reassembly to b instead of c, and that it’s only done in the c case for features that require it. Cheers, Ole > On 14 Aug 2018, at 23:52, Jon Loeliger <j...@netgate.com> wrote: > > VPPeople, > > A few months ago, the vppctl command 'set interface reassembly' was > added along with its API call, ip_reassembly_enable_disable (commit > 4c53313cd7e9b866412ad3e04b2d91ac098c1398). > > What is the relationship of this fragment reassembly and this > enable/disable flag WRT to the NAT's fragment reassembly? > > Specifically, should a NAT fragment reassembly be controlled by this flag? > Empirically, the answer is 'yes'. > > So it appears that one should interpret this enable/disable flag more like: > > When you use `set interface reassembly <IF> off`, the fragments are > forwarded > without any sort of reassembly. The fragments flow through unmolested. > The NAT > fragmentation limits are not respected as they aren't even involved. > > When you use `set interface reassembly <IF> on`, the fragments are > reassembled > before being forwarded. So the interface will process, and possibly > limit, fragment > reassembly, even for NAT rewritten packets. > > Does that sound right? > > And should the reassembly be enabled/disabled on the ingress interface? > Or are there different scenarios where one would want them reassembled on > the egress interface? > > Thanks, > jdl > > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > > View/Reply Online (#10152): https://lists.fd.io/g/vpp-dev/message/10152 > Mute This Topic: https://lists.fd.io/mt/24529319/675193 > Group Owner: vpp-dev+ow...@lists.fd.io > Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [otr...@employees.org] > -=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#10156): https://lists.fd.io/g/vpp-dev/message/10156 Mute This Topic: https://lists.fd.io/mt/24529319/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
