12-05-2011 12:58 PM - edited 03-11-2019 02:59 PM
Hello all,
I have a capture set up of type "asp-drop all", and I am capturing certain packets with no indicated ASP drop reason. See output below (ASA 5510 with 8.0(5)23 code):
asa5510-8.0# show capture
capture ASP type asp-drop all buffer 15000 circular-buffer [Capturing - 14912 bytes]
fw-32103-237233# show capture ASP
3: 14:47:12.731590 10.10.150.226.62279 > 174.120.81.37.443: R 1596734048:1596734048(0) win 0
4: 14:47:17.193166 10.10.150.226.62285 > 174.120.81.37.443: R 1989055853:1989055853(0) win 0
33: 14:47:52.605498 10.10.150.226.62312 > 74.220.200.95.443: R 3525127334:3525127334(0) win 0
47: 14:48:16.301589 10.10.150.231.60987 > 50.28.87.167.443: R 2814263498:2814263498(0) win 0
86: 14:49:34.177343 10.10.150.226.62353 > 173.254.20.75.443: R 562962623:562962623(0) win 0
89: 14:49:36.521121 10.10.150.226.62359 > 173.254.20.75.443: R 2120523434:2120523434(0) win 0
91: 14:49:37.015517 10.10.150.226.62360 > 173.254.20.75.443: R 2545437064:2545437064(0) win 0
122: 14:50:30.861497 173.201.181.41.80 > 10.10.150.226.62386: . ack 2579633127 win 6432 Drop-reason: (tcp-3whs-failed) TCP failed 3 way handshake
152: 14:52:58.610136 10.10.150.226.62423 > 207.32.187.67.443: R 2794556270:2794556270(0) win 0 Drop-reason: (tcp-not-syn) First TCP packet not SYN
170: 14:53:06.523990 10.10.150.226.62425 > 207.32.187.67.443: R 3995294395:3995294395(0) win 0 Drop-reason: (tcp-not-syn) First TCP packet not SYN
180: 14:53:14.175939 10.10.150.226.62428 > 207.32.187.67.443: R 1741959895:1741959895(0) win 0 Drop-reason: (tcp-rstfin-ooo) TCP RST/FIN out of order
Notice in the first 7 packets which were captured, no drop-reason is provided. I know it isn't residual packets being dropped from an already denied flow as the counter for np-socket-closed in the show asp drop table isn't incrementing. Why would I be seeing dropped packets without an assigned reason?
Any help would be greatly appreciated. Thanks in Advanced.
-Ed
Solved! Go to Solution.
12-05-2011 08:20 PM
Hello Eddie,
I have seen this particular behavior a lot of times and this is related to Reset packets, now the ASP capture is going to show us all the packets being dropeed by the ASA Algorithm, so you will think the ASA is dropping the first 7 packets, well yes , It is doing it but just because these are Reset packets comming from one side of the communication ( The client or the server) so the ASA receives the Reset packet and drops it, then it will send its own Reset packet to the other host so the communication can be finished.
So you are going to see this behavior ( No reason) with the reset packets.
This is what I have understood about this particular scenario because I had the same doubt long time ago.
Please rate helpful posts.
Julio
12-05-2011 08:20 PM
Hello Eddie,
I have seen this particular behavior a lot of times and this is related to Reset packets, now the ASP capture is going to show us all the packets being dropeed by the ASA Algorithm, so you will think the ASA is dropping the first 7 packets, well yes , It is doing it but just because these are Reset packets comming from one side of the communication ( The client or the server) so the ASA receives the Reset packet and drops it, then it will send its own Reset packet to the other host so the communication can be finished.
So you are going to see this behavior ( No reason) with the reset packets.
This is what I have understood about this particular scenario because I had the same doubt long time ago.
Please rate helpful posts.
Julio
12-06-2011 07:12 AM
Hello Julia,
Thank you for your input. I had considered that earlier, but was hoping to get a second opinion, which you just provided Thank you kindly for your help.
-Ed
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