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 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.
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
enable (IPv4) or
ipv6 reassembly enable (IPv6) commands from within
config-interface mode. The type may also be set to
in a similar manner, see Interface Configuration Options for details.
The fragment reassembly behavior in TNSR can be fine-tuned globally using the
ip reassembly <type> <address-family> <name> <value>.
Sets options for either
virtualreassembly types. See IP Reassembly Types for details on how these modes operate.
Options used when performing full reassembly of packet fragments.
Options used when performing Shallow Virtual Reassembly for retaining fragment information.
- Address Family
Sets whether these parameters refer to
- 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 is
- 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
fullreassembly mode, new fragment reassembly sessions are not created by TNSR when the limit has been reached, which enforces this limit.
virtualmode, 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
- 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
100milliseconds. When this value is increased, the
max-reassembliesvalue 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: 100 ms Expire walk interval: 10000 ms Maximum reassemblies: 1024 full ipv6 reassembly: Timeout: 100 ms Expire walk interval: 10000 ms Maximum reassemblies: 1024 virtual ipv4 reassembly: Timeout: 100 ms Expire walk interval: 10000 ms Maximum reassemblies: 1024 virtual ipv6 reassembly: Timeout: 100 ms Expire walk interval: 10000 ms Maximum reassemblies: 1024
To limit the output by type, add the
virtual keyword, optionally
ipv6 to view the status only for a specific address