Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Step-by-Step Configuration and Troubleshooting Best Practices for the NGFW, NGIPS and AMP Technologies A Visual Guide to the Cisco Firepower Threat Defense (FTD)
Community Member

FW-4-TCP_OoO_SEG: TCP reassembly queue overflow - session

After upgrading a Cisco 892 to IOS c890-universalk9-mz.151-4.M3.bin from c890-universalk9-mz.124-22.YB.bin(reason was tracebacks) we have noticed the following message's in the logging:

%FW-4-TCP_OoO_SEG: Dropping TCP Segment: seq:1628726886 1492 bytes is out-of-order; expected seq:1628698086. Reason: TCP reassembly queue overflow - session x:42024 to x:80 on zone-pair ccp-zp-in-out class ccp-protocol-http

%FW-4-TCP_OoO_SEG: Deleting session as expected TCP segment with seq:972828144 has not arrived even after 25 seconds - session x:57229 to x:80 on zone-pair ccp-zp-in-out class ccp-protocol-http

After some research we tuned the timers of the tcp reassembly

ip inspect max-incomplete high 8000

ip inspect max-incomplete low 7900

ip inspect one-minute high 8000

ip inspect one-minute low 7900

ip inspect udp idle-time 360

ip inspect dns-timeout 10

ip inspect tcp idle-time 7200

ip inspect tcp finwait-time 10

ip inspect tcp max-incomplete host 1000 block-time 0

ip inspect tcp reassembly queue length 1024

ip inspect tcp reassembly timeout 60

ip inspect tcp reassembly memory limit 256000

However the message's still appear and i cant explain why the sh ip inspect statistics is empty

#sh ip inspect statistics

Interfaces configured for inspection 0

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

The message's did not occur while running c890-universalk9-mz.124-22.YB

1 ACCEPTED SOLUTION

Accepted Solutions
Cisco Employee

Re: FW-4-TCP_OoO_SEG: TCP reassembly queue overflow - session

Hi Marc,

The 'ip inspect' commands and statistics are used for CBAC rather than zone-based firewall. For ZBF, you can tune the reassembly settings with a parameter-map:

parameter-map type ooo global

     tcp reassembly queue length

You can view the queue statistics with the 'show policy-firewall stats all' or 'show policy-map type inspect zone-pair' commands.

Ultimately though, you should investigate why the router is receiving so many out-of-order packets and resolve that issue upstream.

-Mike

2 REPLIES
Cisco Employee

Re: FW-4-TCP_OoO_SEG: TCP reassembly queue overflow - session

Hi Marc,

The 'ip inspect' commands and statistics are used for CBAC rather than zone-based firewall. For ZBF, you can tune the reassembly settings with a parameter-map:

parameter-map type ooo global

     tcp reassembly queue length

You can view the queue statistics with the 'show policy-firewall stats all' or 'show policy-map type inspect zone-pair' commands.

Ultimately though, you should investigate why the router is receiving so many out-of-order packets and resolve that issue upstream.

-Mike

Community Member

Re: FW-4-TCP_OoO_SEG: TCP reassembly queue overflow - session

Thank you for youre reply.

I have also tried the paramet-map ooo settings but these also didnt resolve the issue.

Im not getting any complaints from the clients at the site.

I will go onsite next week and will do some testing/sniffing.

UPDATE:

After tweaking the buffers and time outs the TCP reassembly queu overflow message does not occur anymore.

Now only the following message occurs:

%FW-4-TCP_OoO_SEG: Deleting session as expected TCP segment with seq:4121294117 has not arrived even after 900 seconds - session xxxxx to xxxxxxxxx on zone-pair ccp-zp-in-out class ccp-protocol-http.

During an onsite test the test client also generated this message however the client did not notice this and his download and the speed where OK.

Thread can be closed

9855
Views
0
Helpful
2
Replies
CreatePlease to create content