IP_VFR-4-FRAG_TABLE_OVERFLOW: Vlan1: the fragment table has reached its maximum threshold 16

[balbeer.singh84]

Hi,

I am getting this error message many times in my Router :

IP_VFR-4-FRAG_TABLE_OVERFLOW: Vlan1: the fragment table has reached its maximum threshold 16

What can be the impact of the same in the prformance?

Please suggest.

[Arumugam Muthaiah]

Hi Balbeer,

IP_VFR-4-FRAG_TABLE_OVERFLOW: Vlan1: the fragment table has reached its maximum threshold 16

%IP_VFR-4-FRAG_TABLE_OVERFLOW: [chars]: the fragment table has reached its maximum threshold [dec]

The number of datagrams being reassembled at any one time has reached it maximum limit.

Virtual fragmentation reassembly (VFR) It is typically used for nat and some other layer 4 features as fragmented IP will only have the layer 4 header in the first fragment. So we need to keep the fragments and reassemble them to make sure that nat is performed the same on all fragments or the other fragments are classified the same.

Performance Impact

VFR will cause a performance impact on the basis of functions such as packet copying, fragment validation, and fragment reorder. This performance impact will vary depending on the number of concurrent IP datagram that are being reassembled.

On Router, there is a buffer that holds fragments for reassembly. The FRAG_TABLE refers to that. If too many fragmented datagrams are received, that buffer will get full and you will receive the FRAG_TABLE_OVERFLOW error.

Suggestion:

You can increase the size of the buffer using ip "virtual-reassembly max-reassemblies <number>"command

with number being the maximum number of datagrams that can be reassembled at any one time.

Refer:

http://www.cisco.com/en/US/docs/ios/sec_data_plane/configuration/guide/sec_virt_frag_reassm.html

But more importantly you should look at why so many fragments are coming in, pointing to a possible MTU issue somewhere along your network path. It looks like some device is fragmenting and sending in too many fragments to your router and once its buffer gets full it throws that error.

Please check show ip route to understand the statistics

Regards,

Aru

[ROBERT HOLMES]

What debug command can we type on a router to see what flows or source IP's are causing the fragmentation?  I can't fix it without knowing the source.  thanks.

[ositechintl]

Hi Robert,

Will you got the output to this issue.

I am also facing the same issue.

Thanks,

Ramesh

[ROBERT HOLMES]

I haven't looked into this lately, but I still don't know the command to show me the source of the fragments.

[msenko]

I found the source of the fragments in the syslog output.

I had a device on gi0/1 performing a software update where the update was generated on an application from a PC on a far-end router (across a WAN interface). The routers were connected via a GRE-Tunnel and the Tunnel uses a different MTU than the common default of 1500 bytes.

In my case I found two solutions to the problem:

1. increase the size of the virtual-reassembly parameters (reassembly, fragmentation, timeout). I basically doubled them from default on the interface for the device, in this case gi0/1.

2. I found the MTU of the tunnel interface to be at the interface default of 1500, so I adjusted the configuration downward for an MTU of 1476 (default for GRE-Tunnel configurations) which also cleared up the problem. I had to hand code it: ip mtu 1476.

Also an interesting note, suspecting the tunnel interface was where the issue was, I first adjusted the mtu for 2048. When I did, I received a notice from the router that setting the mtu above the default of 1476 would result in packet fragmentation. (Thank you Cisco!).

So I then set the mtu to 1200 (this interface connects to a Sonet ring where some of the connection MTU capabilities are below 1300) and tested the software upgrade again. With an MTU of 1200, there were no fragment errors.

I reset the tunnel mtu to 1476 and reset the gi0/1 ip virtual-fragmentation to defaults and tested, all was well. 

[azharalibuttar]

I also faced this issue and it wasted around 4 hours of my precious time. I found under given URL which helped me solve this issue.

https://www.windowstechupdates.com/the-fragment-table-has-reached-its-maximum-threshold-16/

[sbhadrav@cisco.com]

Your router uses a feature named "virtual fragment reassembly" to check if fragments can be reassembled to a complete IP datagram. This can be done (by default) for up to 16 datagrams at a given time.

What you should do:

1.Search for the reason that there is fragmentation in your network and solve that problem.
2.If you come to the conclusion that you can't solve that and the reassemblies are not part of an attack, you can increase the amount of allowed reassemblies:
rtr(config)# interface Fast 0/1

rtr(config-if)#ip virtual-reassembly in max-reassemblies ?

 <1-1024> Number of datagrams that can be reassembled at a time

Here are all defaults when enabled:

 Concurrent reassemblies (max-reassemblies): 16
 Fragments per reassembly (max-fragments): 32
 Reassembly timeout (timeout): 3 seconds