Tip
This is the documentation for the 23.11 version. Looking for the documentation of the latest version? Have a look here.
IP Reassembly¶
IP reassembly deals with packet fragments, which can be problematic for certain routing, access control, and related tasks which require packet header information. When a packet is fragmented, only the first fragment carries full header information such as TCP/UDP port data. This can lead to problems with processing fragmented packets which involve NAT, for example, which requires that port data.
IP Reassembly Types¶
TNSR supports two types of IP reassembly: Full Reassembly and Shallow Virtual Reassembly.
Full Reassembly¶
Full reassembly is more common and the type of reassembly found most often networking platforms. When performing full reassembly, the router waits until all fragments of a packet arrive, and then it acts on that packet to apply ACLs, NAT, and so on, before delivering the packet further.
This means that fragmented packets must be held in a buffer, consuming memory, for a long enough time to allow later fragments to arrive in a reasonable window. This not only consumes memory required for the buffer, but adds latency since all fragments must arrive before the entire packet can be acted upon.
Shallow Virtual Reassembly¶
Shallow Virtual Reassembly (SVR) does not reassemble fragmented packets, but retains the L4 information so that later fragments can have operations applied using the L4 data from the initial fragment. For example, MAP-T and MAP-E BR rely on the destination port of incoming IPv4 packets to determine the destination CE. Tracking the ports from the first fragment and populating that data into the buffer opaque data of later fragments allows MAP to figure out the correct destination address for future fragments without having to reassemble the entire packet.
Note
Some features of TNSR, such as NAT and MAP, require SVR to function and when those features are active, TNSR will implicitly enable SVR.
IP Reassembly Options¶
IP reassembly is be enabled on a per-interface basis using the ip reassembly
enable
(IPv4) or ipv6 reassembly enable
(IPv6) commands from within
config-interface
mode. The type may also be set to full
or virtual
in a similar manner, see Interface Configuration Options for details.
The fragment reassembly behavior in TNSR can be fine-tuned globally using the
commands ip reassembly <type> <address-family> <name> <value>
.
- Type:
Sets options for either
full
orvirtual
reassembly types. See IP Reassembly Types for details on how these modes operate.- full:
Options used when performing full reassembly of packet fragments.
- virtual:
Options used when performing Shallow Virtual Reassembly for retaining fragment information.
- Address Family:
Sets whether these parameters refer to
ipv4
oripv6
.- Name and Value:
- expire-walk-interval <expire-walk-interval-ms>:
The interval, in milliseconds, at which TNSR will check for fragments to expire. Decreasing this will consume more CPU time but will allow TNSR to be more proactive in cleaning up expired fragments. Increasing this will allow expired fragments to be held longer, but may be more likely to overrun the value of
max-reassemblies
. Default value is10000
(10 seconds) for virtual reassembly and50
for full reassembly.- max-reassemblies <max>:
The maximum number of active reassemblies TNSR will maintain at any given time. Increasing this value will consume more resources, but it will also allow TNSR to reassemble a greater number of fragments at a time. Default value is
1024
.Note
In
full
reassembly mode, new fragment reassembly sessions are not created by TNSR when the limit has been reached, which enforces this limit.In
virtual
mode, this limit is enforced by removing older sessions. If a fragment for a new packet arrives on an interface and a new reassembly session cannot be created because this limit has been reached, the last created session will be erased and a new one will be created for the current fragment.- max-reassembly-length <length>:
The maximum number of fragments TNSR will consider for each reassembly. Increasing this value will consume more resources and can potentially slow down processing as TNSR will wait for more fragments to arrive when attempting to reassemble packets. Default value is
3
.- timeout <timeout-ms>:
The timeout value, in milliseconds, after which TNSR will consider a reassembly attempt expired. Increasing this value will cause fragments to be held longer waiting on the remaining pieces, which means they are more likely to be successfully reassembled on slower networks, at the cost of consuming more resources. Default value is
100
milliseconds for virtual reassembly and200
milliseconds for full reassembly. When this value is increased, themax-reassemblies
value may also need increased to accommodate the higher volume of fragments that TNSR will need to hold.
IP Reassembly Status¶
To view the current IP reassembly status, use the show ip reassembly
[(full|virtual) [(ipv4|ipv6)]]
command.
On its own, show ip reassembly
will display the status of all types for
both IPv4 and IPv6.
tnsr# show ip reassembly
full ipv4 reassembly:
Timeout: 200 ms
Expire walk interval: 50 ms
Maximum reassemblies: 1024
Maximum reassembly length: 3
full ipv6 reassembly:
Timeout: 200 ms
Expire walk interval: 50 ms
Maximum reassemblies: 1024
Maximum reassembly length: 3
virtual ipv4 reassembly:
Timeout: 100 ms
Expire walk interval: 10000 ms
Maximum reassemblies: 1024
Maximum reassembly length: 3
virtual ipv6 reassembly:
Timeout: 100 ms
Expire walk interval: 10000 ms
Maximum reassemblies: 1024
Maximum reassembly length: 3
To limit the output by type, add the full
or virtual
keyword, optionally
followed by ipv4
or ipv6
to view the status only for a specific address
family.