%IP_VFR-4-TOO_MANY_FRAGMENTS: FastEthernet0/1.2: Too many fragments

Norberto Salgado · ‎11-03-2009

Hi we have two SSG (Service Selection Gateways 7200), both with IOS 12.4(18). And we are getting the following alarm: %IP_VFR-4-TOO_MANY_FRAGMENTS: FastEthernet0/1.2: Too many fragments per datagram (more than 32) - sent by xxx.xxx.xxx.xxx, destined to xxx.xxx.xxx.xxx . We reconfigured the port, but we are still receiving the alarm.

interface FastEthernet0/1.2

encapsulation dot1Q 2

ip address xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx

no ip redirects

no ip unreachables

no ip proxy-arp

ip virtual-reassembly max-reassemblies 1024

ssg direction downlink

no cdp enable

Any ideas on this?

Thank you.

Peter Paluch · ‎11-03-2009

Hello Norberto,

Obviously, there are some packets hitting your 7200 that appear as many fragments of a single IP packet. You would probably need to do sniffing in order to find out whether these fragments are correct fragments indeed, however, this is what the IOS thinks about them.

Essentially, two packets are considered to be fragments of a single packet if their ID is identical and at least one of them (the one with the smaller Fragment Offset value) has the More Fragments flag set. The question is why are such packets hitting your router - if they are fragments indeed and why are they created at all.

There can be some ill implementations of IP stack on some devices that fail to properly increment the ID of an IP packet which may confuse the Virtual Fragmentation and Reassembly in the IOS.

Is the sender of these fragments always the same IP address? If yes I would personally try to follow the path back to this source, check the MTU on links leading to that source and possibly also checking what packets are generated on that machine - if they are fragmented indeed or whether they are fragmented somewhere along the way.

If you do not requite the functionality of the Virtual Fragmentation and Reassembly, you can also deactivate it.

Best regards,

Peter

Norberto Salgado · ‎11-04-2009

Hi Peter,

thank you for your explanation. The fragments in cause have allways the same IP source and IP destination. So, you advise that the next step should try to know what packets are being generated by this machine?

The reason that we are having this alarm it's that the packets received by the 7200 are not correctly fragmented?

Thank you.

Best regards,

Norberto

Peter Paluch · ‎11-04-2009

Hello Norberto,

Sorry for answering a bit lately.

Yes, my personal course of action would be first to have a close look on the source and destination of those packets that are being logged as excessive fragments, and possibly also on the path and devices that are between the source and your 7200 router.

The Virtual Fragmentation Reassembly feature is basically designed to solve a problem with ACLs, CBAC and IDS that arises if a packet carrying a TCP or UDP segment was fragmented in such a way that the TCP or UDP header is only in the first fragment. In such case, all the security features that match values in the Layer4 header, do not apply to subsequent fragments because the headers simply are not there.

The Virtual Fragmentation Reassembly provides a solution to this by virtually defragmenting packets in router's memory, thereby helping the security features to match all fragments of a larger packet. You may want to read about the feature in greater detail here:

https://www.cisco.com/en/US/docs/ios/12_3t/12_3t8/feature/guide/gt_vfrag.html

The reason why you are having this alarm is that there appear to be more than 1024 fragments of a single packet arriving at your router. Such situation, while theoretically possible, is practically out of question. No reasonable IP packet will be fragmented into 1024 fragments. It more looks like either a bad IP stack implementation at the sender, or an artificial attack.

Best regards,

Peter