The fragment table has reached its maximum threshold 16

[Manoel Goncalves]

Hello,

You know the reason Cisco router is generating this event?

044006: Apr 26 17:26:42.176 GMT-3: %IP_VFR-4-FRAG_TABLE_OVERFLOW: FastEthernet0/1: the fragment table has reached its maximum threshold 16
044007: Apr 26 17:27:12.200 GMT-3: %IP_VFR-4-FRAG_TABLE_OVERFLOW: FastEthernet0/1: the fragment table has reached its maximum threshold 16
044008: Apr 26 17:27:42.229 GMT-3: %IP_VFR-4-FRAG_TABLE_OVERFLOW: FastEthernet0/1: the fragment table has reached its maximum threshold 16
044009: Apr 26 17:28:12.362 GMT-3: %IP_VFR-4-FRAG_TABLE_OVERFLOW: FastEthernet0/1: the fragment table has reached its maximum threshold

Thank you

[Karsten Iwen]

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

[Manoel Goncalves]

Thank you Karsten Iwen!

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages wha2tsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Just want to add, more than 16 fragments, per packet, is a bit odd in itself.

[Karsten Iwen]

That is a different counter which is even bigger: 32 fragments per reassembly by default (on ISRs that I checked) if virtual reassembly is enabled.

Here are all defaults when enabled:

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

[David_Che]

I take part in this feature development in 2012.

This feature called 'IP reassemble enhancement'  was requested by NTT. when traffic passing through GRE tunnel, fragment was needed as the tunneled packet was bigger than outgoing interface MTU, unfortunately, when congestion happened on outgoing interface, some fragmented packets with LOW priority TOS were discarded by QoS queue, so the other GRE peer will wait them to arrive until timeout( default 3 seconds). the 16 reassembly queue were soon filled by those fragmented packets. fragmented packets with HIGH priority were also discarded as there were no reassembly queue left.

The solution is to configure as many reassembly queue as 1024. OR

decrease timeout to as little as 100 ms

This solution is pretty good so the feature was applied to virtual fragment and reassembly (VFR).

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages wha2tsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Ah, thanks Karsten!  I did think it was limiting number of fragments per packet.  That said, the default of 32 fragments per packet, should, like my comment about 16, be more than enough.  On the other hand, I could see where a burst of packets, from clients using much larger TCP transmission windows, could overflow 16 packet buffers, but generally only under certain conditions (like fragment/packet sequence reordering, or fragment/packet drops - which David's post appears to confirm).