Dialer - Out of Sequence Error

001454: Jul 17 14:39:19.795 SEA: %FW-6-DROP_PKT:
Dropping tcp session 103.21.81.183:80 192.168.100.33:55506
due to  Out-Of-Order Segment with ip ident 0

ISR2811(config)#ip inspect tcp reassembly queue length 64

ISR2811(config)#ip inspect tcp reassembly alarm on

ISR2811#show ip inspect statistics
Interfaces configured for inspection 4294967292
Session creations since subsystem startup or last reset 0
Current session counts (estab/half-open/terminating) [0:0:0]
Maxever session counts (estab/half-open/terminating) [0:0:0]
Last session created never
Last statistic reset never
Last session creation rate 0
Maxever session creation rate 0
Last half-open session total 0
TCP reassembly statistics
  received 0 packets out-of-order; dropped 0
  peak memory usage 0 KB; current usage: 0 KB
  peak queue length 0


Hmm... seems that out of order is not an issue.

ISR2811#sh ip virtual-reassembly dialer 1
Dialer1:
   Virtual Fragment Reassembly (VFR) is ENABLED...
   Concurrent reassemblies (max-reassemblies): 512
   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:40455
   Total reassembly timeout count:111

ISR2811#show ip virtual-reassembly fa0/0.1
FastEthernet0/0.1:
   Virtual Fragment Reassembly (VFR) is ENABLED...
   Concurrent reassemblies (max-reassemblies): 128
   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:0
   Total reassembly timeout count:0

Current IOS: c2800nm-advipservicesk9-mz.124-24.T6.bin

upgrading IOS to 15.1(1)T  should fix the issue.

 out-of-order packet processing in the ZBF was introduced in IOS 15.0(1)M. 


So now will try c2800nm-entbasek9-mz.151-4.M6

Stable c870-advipservicesk9-mz.150-1.M7.bin
Stable c870-advipservicesk9-mz.124-15.T15.bin


Now trying this which requires, 256RAM, 64Dc2800nm-adventerprisek9-mz.150-1.M7.bin

A bit of info on virtual-reassembly:

VFR is responsible for detecting and preventing the following types of fragment attacks:

•Tiny Fragment Attack—In this type of attack, the attacker makes the fragment size small enough to force Layer 4 (TCP and User Datagram Protocol (UDP)) header fields into the second fragment. Thus, the ACL rules that have been configured for those fields will not match.

VFR drops all tiny fragments, and an alert message such as follows is logged to the syslog server: "VFR-3-TINY_FRAGMENTS."

•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."

•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.)

When the maximum number of datagrams that can be reassembled at any given time is reached, all subsequent fragments are dropped, and an alert message such as the following is logged to the syslog server: "VFR-4_FRAG_TABLE_OVERFLOW."

When the maximum number of fragments per datagram is reached, subsequent fragments will be dropped, and an alert message such as the following is logged to the syslog server: "VFR-4_TOO_MANY_FRAGMENTS."

In addition to configuring the maximum threshold values, each IP datagram is associated with a managed timer. If the IP datagram does not receive all of the fragments within the specified time, the timer will expire and the IP datagram (and all of its fragments) will be dropped.