Hi Jon,
NAT plugin does virtual fragment reassembly – it enables to translate
non-initial fragments without L4 header otherwise NAT is unable to gather port
information from the non-initial fragment, packet is still broken into several
fragments after NAT translation.
Matus
From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Jon Loeliger
Sent: Tuesday, August 14, 2018 11:53 PM
To: vpp-dev <vpp-dev@lists.fd.io>
Subject: [vpp-dev] NAT Fragment Reassembly
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 (#10154): https://lists.fd.io/g/vpp-dev/message/10154
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]
-=-=-=-=-=-=-=-=-=-=-=-
