Tip

This is the documentation for the 20.10 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 or virtual 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 or ipv6.

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 10000 (10 seconds).

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.

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. When this value is increased, the max-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:                  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 full or virtual keyword, optionally followed by ipv4 or ipv6 to view the status only for a specific address family.