IP_VFR-3-OVERLAP_FRAGMENTS on 2911 router

[james.king14]

We have several Cisco 2911 routers.  Each router is using VPN sessions to communicate with HQ.  This one location I get an error at least 15 time a day saying "%IP_VFR-3-OVERLAP_FRAGMENTS: GigabitEthernet0/2: from the host 10.10.6.3 destined to 2.15.1.120. I have completed the debug on the router to show ip virtual-reassembly.  I also did a debug ip virtual-reassembly.  My question is what is causing this issue?  What can I do to fix this issue.

[Mark Malone · Accepted solution]

This is Cisco official line on it

%IP_VFR-3-OVERLAP_FRAGMENTS: [chars]: from the host [IP_address] destined to [IP_address]

The router has encountered overlap fragments. "Overlap fragment" means that the offset of one fragment overlaps the offset of another fragment. For example, if the offset of the first fragment is 0 and its length is 800, the offset of the second fragments offset must be 800. If the offset of the second fragment is less than 800, the second fragment overlaps the first fragment. This condition might indicate a hostile attack.

Recommended Action: Configure a static ACL to prevent further overlap fragments from the sender.

examples of fragment acl required

http://www.cisco.com/c/en/us/td/docs/ios/12_2s/feature/guide/fsaclseq.html#wp1046701

[james.king14]

Mark,

Thanks, I have read the official line and I guess my question is why?  Why is this one router is causing this.  All my routers are configured the same while this one router,  is the only one having this issues.  Could it be from the circuit or this router.  

What would be the proper acl lingo?

access-list 101 deny ip any host 10.10.3.1 fragments
access-list 101 permit tcp any host 10.10.3.1 
access-list 101 deny ip any any

[Mark Malone]

Well like the output states it could indicate some type of attack on that specific router

Overlapping Fragment Attack—In this type of attack, the attacker can overwrite the fragment offset in the noninitial IP fragment packets. When the firewall reassembles the IP fragments, it might create wrong IP packets, causing the memory to overflow or your system to crash.
VFR drops all fragments within a fragment chain if an overlap fragment is detected, and an alert
message such as follows is logged to the syslog server: “VFR-3-OVERLAP_FRAGMENT.”

[james.king14]

I agree with the information and normally I would be concerned.  The address is my wireless controller that is used region wide.  In my VPN sessions back to a centralized router,  this is the only device showing any issues. 

[Mark Malone · Accepted solution]

When did this start in the last couple of days , were there any changes to the router or to the wlc around the times this all started ?

Even though the routers are generally configured the same are they processing same amount of data , in case this one is being overworked a bit compared to the others, no diffs in IOS version or ram etc ....  have you got the same virtual reassembly set on each router 

that French ip address 2.x.x.x. do you know that address as being an ok destination to communicate with ?

Looking through the docs does not seem to be too much info on it other than block it , but in case its a software bug that was just triggered on that router you could try upgrade as well

this doc has some very good points on fragmentation with an without vpn in place

http://blog.ine.com/2008/11/05/dealing-with-fragmented-traffic/

[james.king14]

Mark,

No this has been ongoing for about a month.  I have been researching all venues of information and finally open my own discussion. To include reading that document you have sent. No differences in RAM or IOS only difference is the routing to the ISP.  The Version is 15.2(4) M3. 

LOL yeah that address is only on my inside regional router and directly connected to the centralized 6909.

this is a new error that just came from said router. IP_VFR-4-FRAG_TABLE_OVERFLOW: GigabitEthernet0/2: the fragment table has reached its maximum threshold 16

[Mark Malone]

what about to increase the buffers just to that interface g0/2 to stop the overflow instead of blocking it , that will give the interface more of a chance to process the traffic if you believe it to be legitimate rather than just dropping it

ip virtual-reassembly max-reassemblies 64 max-fragments 32 timeout

.................................

VFR drops all fragments within a fragment chain if an overlap fragment is detected, and an alert message such as follows is logged to the syslog server: "VFR-3-OVERLAP_FRAGMENT."

•Buffer Overflow Attack—In this type of denial-of-service (DoS) attack, the attacker can continuously send a large number of incomplete IP fragments, causing the firewall to lose time and memory while trying to reassemble the fake packets.

To avoid buffer overflow and control memory usage, configure a maximum threshold for the number of IP datagrams that are being reassembled and the number of fragments per datagram. (Both of these parameters can be specified via the ip virtual-reassembly command.)

[james.king14]

Mark,

that just might work>  I will test that in a few minutes.

[james.king14]

Mark,

That command is not valid on the Cisco IOS Software, C2900 Software (C2900-UNIVERSALK9-M), Version 15.2(4)M3, RELEASE SOFTWARE (fc2).  is there another way to change the re-assemblies?.

[james.king14]

Well we tried to increase the buffers to clear the issue..

[james.king14]

Thank you Mark,

After the last command it has stopped...For Now! I think it is these old 2911 routers that can not handle a circuit larger than 50 mbs.  I have made a request to move to the 4551 ISR.  Since we will try to do 100mbs to each location. 

[Mark Malone]

hmm I have a 2951 15.2(4)m2 and it has it in the interfaces as an option would have thought a 2911 would have it too,  what options does it show when your in the interface does it give you ip virtual at all ?

There's no other way im aware of you can do it i have had to do it on lower end 800s before

xxxxxx(config-if)#ip v?
verify  virtual-reassembly  vrf

[james.king14]

yeah...?  when in the interface these are the only options.

XXXX-xxx(config-if)#ip virtual-reassembly ?
  in   Enable VFR on Ingress
  out  Enable VFR on Egress
  <cr>

what i have tried so far is to give the interface more buffers. 

 hold-queue 220000 in
 hold-queue 220000 out

So far i only show two error log statements in the last 24 hrs. 

[Mark Malone]

Hi

you could also try this syntax its just shorter on IOS below should work increase it bit by bit until the alerts stops , start at 64

xxxxx(config-if)#ip virtual-reassembly in max-reassemblies 64
  <1-1024>  Number of datagrams that can be reassembled at a time