11-09-2012 06:48 AM - edited 03-11-2019 05:21 PM
Hello all. It was just last weekend that I put in my first zone firewalled router into a live environment.
Now, with ip inspect log drop_pktset, I see many many entries of dropped packets. Often these are not due to explicit rules I've set but instead, due to I imagine just integrated firewall drop criteria. For example:
177497: *Nov 9 2012 08:56:16.916 PCTime: %FW-6-DROP_PKT: Dropping tcp session <my public IP>:49399 <someone else's public IP>:443 due to RST inside current window with ip ident 0
I get about 4 or 5 different types of conditions. Always with "ip ident 0" whatever that is. There's this RST one, then there's dropping packets due to Out of Order Segment (this is from an email filtering service that then sends the clean emails to our mail server). Also there is often dropping tcp session due to Stray Seegment, usually this one comes from internal systems going outbound. Again, these are not drops due to rules I've set, these are apparently just built-in drop actions esigned into the firewall itself.
Though I would much appreciate any direct explanation from fellow forum members about any specific condition above, I would be happy also with any kind of reference document that explains all of the ones found in an IOS zone firewall so I could referenc them.
I googled some of these and get some partial answers but generally it's a lot of opinion and less facts. Perhaps what is fact is Out of Order: you can set up a parameter map to create an out of order buffer so your firewall will allow more OOO packets before inspcting them, thus you won't have the out of Order rops occuring. I don't know what would be considdred tolerable OOO windowing since TCP by design allows for this to occur but maybe the FW is less tolerant?
Thanks for any insight.
Solved! Go to Solution.
11-12-2012 07:30 PM
Normally 256 is consider a decent value. (I guess thats the larger you can go for thou).
So far there is no reasonable explanation for that Log, as you suggested, it is very generic and that is why there is an enhacement request on it.
http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCth50639
http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsx78412
Unfortunately, if there no present and consisten issue, there no reasonable way to determine what it is causing it.
Mike
11-12-2012 07:30 PM
Normally 256 is consider a decent value. (I guess thats the larger you can go for thou).
So far there is no reasonable explanation for that Log, as you suggested, it is very generic and that is why there is an enhacement request on it.
http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCth50639
http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsx78412
Unfortunately, if there no present and consisten issue, there no reasonable way to determine what it is causing it.
Mike
11-13-2012 07:19 AM
For me, both of those links resulted in a "bug not found" kind of message. But either way, as long as there is visibility into a need to enhance the reporting of those log entries that's great. I'm sure a nice look at some RFC about TCP sessions might give the answers but I don't really have time these days Anyway, thanks for the answer and I"ll try out that OOO value of 256, once I learn how to make a parameter map for this
11-13-2012 07:31 AM
Ok so it appears this OOO parameter map thing is very specific and ha sonly one way to be modified.
#conf t
#parameter-map type ooo global (global is the only option, cannot make an OOO customized parameter map)
(config-profile#tcp reassembly queue length <0-1024>
I set it to 128 just for fun for now. The default is 16. I will try 256 as suggested, it's just that I'm curious if varying values will have varying effects on this OOO problem.
Results of sh parameter-map type OOO global:
parameter-map type ooo global
tcp reassembly timeout 5
tcp reassembly queue length 128
tcp reassembly memory limit 1024
tcp reassembly alarm off
Just FYI to anybody reading this post in the future. I'll post whether the OOO's stopped completely, and what queue length value was the one that worked in this particular scenarioi.
Thanks again.
11-13-2012 10:25 AM
Hello Colin,
Funny, if you copy the whole link it works, if you click on it, it wouldnt.
Let us know if the OOO queue works.
Mike
11-14-2012 11:14 AM
So far I think it's working. Porobme is sometimes I get weired issues with the firewall logging - I mean, as I write this, after running sh logging | i FW, there are no entrires of any kind. Odd, since I haven't cleared the buffer in days.
Anyway, if I start seeing FW entries but don't see the OOO ones, I'll report back here. Meanwhile I wanted to share what I found about the firewall messages desciprtions, located in the following command reference (in Table 1 of the ip inspect log drop_pkt command)
They aren't extremely descriptive but do give more than I've found elsewhere.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide