cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2672
Views
0
Helpful
7
Replies

IP_VFR-3-OVERLAP_FRAGMENTS: GigabitEthernet0/0: from the host xx.xx.xx.xx destined to %mypublicIP%

gcarson73
Level 1
Level 1

Cisco 2951, Version 15.5(3)M5

*The public IP is NAT'd.

 

Production router in use for years.  I received the below message from my syslog server today.

 

*Aug  3 05:12:11.048: %IP_VFR-3-OVERLAP_FRAGMENTS: GigabitEthernet0/0: from the host xx.xx.xx.xx destined to %my publicIP%

 

Here is my ACL (*thought this would stop fragments)

ip access-list extended inbound
deny tcp any any fragments
deny udp any any fragments
deny icmp any any fragments
deny ip any any fragments
deny icmp any any
deny ip 127.0.0.0 0.255.255.255 any
deny ip 10.0.0.0 0.255.255.255 any
deny ip 172.16.0.0 0.15.255.255 any
deny ip 192.168.0.0 0.0.255.255 any
deny ip host 0.0.0.0 any
permit ip any any

 

Here is Virtual-reassembly for G0/0

GigabitEthernet0/0:
Virtual Fragment Reassembly (VFR) is ENABLED [in]
Concurrent reassemblies (max-reassemblies): 1000
Fragments per reassembly (max-fragments): 32
Reassembly timeout (timeout): 3 seconds
Drop fragments: OFF

Current reassembly count:0
Current fragment count:0
Total reassembly count:54428
Total reassembly timeout count:104873

 

 

Would it be advisable for "Drop Fragments" to be ON (with command below on intG0/0?)

 

ip virtual-reassebly in max-reassemblies 1000 max-fragments 32 timeout 3 drop-fragments

 

What are the causes of this? (as at first I added IP to DENY in ACL, but I have removed that as I found out it the IP belonged to a remote worker.  I did check MTU size and it was 1500) 

 

 

 

 

7 Replies 7

Jameel Ahmed
Level 1
Level 1

i have the exact same issue here.. it looks like buffer overflow attack from what i have read so far. i am still looking for a remedy. 

ip virtual-reassebly in max-reassemblies 1000 max-fragments 32 timeout 3 drop-fragments

I wish someone with experience would provide some insight.

 

The issue has not returned, although not like it was happening often, as it happened 1 time in the last few years.  I have had no issues with adding the command above, and hope its stopped the fragments completely.  

The command you applied would resolve the issue because it completely drops fragments on the configured interface.

But i wanted to know why it is happening now when it never happened before. I am sure it is some kind of DDos attack.

This interface is my public interface, and I don't want fragments anyway.  I thought my ACL handled that.

 

Anyway, like I said, the IP that caused this was from an employee, on VPN.  I am not sure how it happened, I just want to stop fragments.  If this command "fixed" it, I will make sure to implement on all public interfaces.

 

 

Yes but sometimes you need incoming fragmentation on your internet links but in your case it doesn't imply i guess.

Check your user's vpn client station for MTU settings looks like you need to adjust MTU settings in their vpn client software if it's a remote vpn user.

Again, as originally stated, I checked the MTU size.

 

*All employees are remote, and this was the first case of this, and the same Router with same config, for years.  This employee was with company before I started 3 years ago, so again not sure of what "really" caused it, but I am hoping the new command stops fragments, as my ACL did not completely stop them.  

 

Anything other than MTU size that could of caused this error?

It could be any device between your router and that client if it's not happening on client's station itself. Can you ping that client's public ip from your router's interface with df-bit set. Try to find out path MTU starting from 1500 down to any value where it starts replying.
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: