Buy or Renew
Buy or Renew
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
6598
Views
0
Helpful
9
Replies

ASA ICMP Packets

Go to solution
Oscar Cardiel
Level 1
Level 1

‎05-14-2012 02:24 AM - edited ‎03-11-2019 04:06 PM

Hi Guys,

Actually we have two ASA 5520 in active/passive. We are losing random icmp packets between hosts located at different ASA’s interfaces or zones so; random icmp packets are losed when cross the firewalls.

asa# sh interface | i errors

        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

        0 output errors, 0 collisions, 2 interface resets

        94 input errors, 0 CRC, 0 frame, 94 overrun, 0 ignored, 0 abort

        0 output errors, 0 collisions, 2 interface resets

        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

        0 output errors, 0 collisions, 2 interface resets

        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

        0 output errors, 0 collisions, 2 interface resets

        2 input errors, 0 CRC, 0 frame, 2 overrun, 0 ignored, 0 abort

        0 output errors, 0 collisions, 0 interface resets

asa# show conn count

7924 in use, 7934 most used

asa# show resource usage

Resource              Current         Peak      Limit        Denied Context

SSH                         2            2          5             0 System

ASDM                        1            3          5             0 System

Syslogs [rate]            444         1295        N/A             0 System

Conns                    7284         8000     280000             0 System

Xlates                   2728         3063        N/A             0 System

Hosts                    3155         3403        N/A             0 System

Conns [rate]              195          946        N/A             0 System

Inspects [rate]            20          280        N/A             0 System

asa# sh processes cpu-usage non-zero

PC         Thread       5Sec     1Min     5Min   Process

081a86c4   c91afa08    56.9%    45.1%    37.5%   Dispatch Unit

08c15df6   c91a93a8     1.3%     1.3%     1.2%   Logger

08190627   c91a4ec0     0.0%     0.1%     0.0%   tmatch compile thread

084b6fa1   c91a40f8     0.3%     0.6%     0.6%   IKE Daemon

083ccbfc   c91a17a0     0.1%     0.1%     0.1%   fover_health_monitoring_thread

08405637   c91a13b0     0.0%     0.1%     0.1%   ha_trans_data_tx

085345ae   c91a09d8     0.5%     0.3%     0.3%   ARP Thread

088c038d   c918f248     2.3%     2.2%     2.3%   Unicorn Admin Handler

08bde96c   c9189ba8     0.2%     0.4%     0.2%   ssh

Labels:
0 Helpful
2 Accepted Solutions

Accepted Solutions

Go to solution
Julio Carvajal
VIP Alumni
VIP Alumni
In response to Oscar Cardiel

‎05-15-2012 09:42 AM

Hello Oscar,

Thanks for the information.

I think our best suggestion here would be to create captures on both interfaces on the ASA involded on this communication and then check all the packets captured on both interfaces.

Also do a ASP capture that will show us all the packets being dropped by the ASA algorithm ( Acelerated Security Path).. We will need to see the ICMP packets in this list in order to make sure the ASA is the device causing the problem.

Regards,

Do rate all the helpful posts.

Julio

Julio Carvajal
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC

View solution in original post

0 Helpful

Go to solution
lcambron
Level 3
Level 3
In response to Julio Carvajal

‎05-15-2012 11:29 AM

Oscar,

As Julio said, we can confirm this with regular and arp captures.

cap asp type asp-drop all buffer 9999999

show cap asp | inc IP_address

The buffered for this capture gets full very fast, cuz it captures all drops on the ASA, so monitor the same with command 'show capture'

to clean it;  'clear capture asp'

Set simultaneous captures on ingress and egress interfaces to see how many packets are getting to the ASA and how many are leaving.

capture capin interface inside match icmp host source_IP host destination_IP

capture capout interface outside match icmp host NAT'ed_IP host destination_IP

Adding icmp inspection wouldn't hurt.

Felipe.

View solution in original post

0 Helpful
9 Replies 9

Go to solution
Julio Carvajal
VIP Alumni
VIP Alumni

‎05-14-2012 10:26 AM

Hello Oscar,

We will need to determine if the ASA is the device causing the issue.

Can you provide us a show service-policy?

How often does this happens?

Is there a way that you could do captures to check if the ASA is dropping the packets?

Regards,

Julio

Julio Carvajal
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC
0 Helpful

Go to solution
Oscar Cardiel
Level 1
Level 1
In response to Julio Carvajal

‎05-15-2012 12:58 AM

Hi Julio,

It happens random but quite enough to be detected for our customer systems manage based in icmp. Actually, we have installed Cat6509 VSS as network core and I am confusing if ASA55020 are the bottleneck. I have tested some scenarios and icmp packets are losing when its go though the firewall to different zones. Firewalls are connected to core ports and core ports don’t show me any issue, drops packets, speed, blablabla… but I can see firewall have its CPU around 55%, there are interfaces with overrun and input errors, but not too much in my opinion.

I don't have ICMP and ICMP errors inspect active:

asa# sh service-policy

Global policy:
  Service-policy: global_policy
    Class-map: inspection_default
      Inspect: rsh, packet 0, drop 0, reset-drop 0
      Inspect: sunrpc, packet 0, drop 0, reset-drop 0
               tcp-proxy: bytes in buffer 0, bytes dropped 0
      Inspect: tftp, packet 28, drop 0, reset-drop 0
      Inspect: xdmcp, packet 0, drop 0, reset-drop 0
      Inspect: ils, packet 283886, drop 0, reset-drop 0
      Inspect: dns Dns_Inspect, packet 3137293, drop 1359, reset-drop 0
      Inspect: h323 h225 _default_h323_map, packet 0, drop 0, reset-drop 0
               tcp-proxy: bytes in buffer 0, bytes dropped 0
      Inspect: h323 ras _default_h323_map, packet 0, drop 0, reset-drop 0
      Inspect: rtsp, packet 0, drop 0, reset-drop 0
               tcp-proxy: bytes in buffer 0, bytes dropped 0
      Inspect: skinny , packet 9, drop 0, reset-drop 0
               tcp-proxy: bytes in buffer 0, bytes dropped 50
      Inspect: sqlnet, packet 0, drop 0, reset-drop 0
      Inspect: sip , packet 0, drop 0, reset-drop 0
               tcp-proxy: bytes in buffer 0, bytes dropped 0
      Inspect: ftp, packet 13333518, drop 0, reset-drop 0

Interface internet:
  Service-policy: internet-policy
    Class-map: internet-class
      IPS: card status Up, mode inline fail-open
        packet input 198996653, packet output 198996847, drop 0, reset-drop 0

Interface interpista:
  Service-policy: interpista-policy
    Class-map: interpista-class
      IPS: card status Up, mode inline fail-open
        packet input 3832129, packet output 3832131, drop 0, reset-drop 0

Interface inside:
  Service-policy: inside-policy
    Class-map: inside-class
      IPS: card status Up, mode inline fail-open
        packet input 509328060, packet output 509328115, drop 0, reset-drop 0

asa# sh int | i errors

        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

        0 output errors, 0 collisions, 2 interface resets

        131 input errors, 0 CRC, 0 frame, 131 overrun, 0 ignored, 0 abort

        0 output errors, 0 collisions, 2 interface resets

        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

        0 output errors, 0 collisions, 2 interface resets

        59 input errors, 0 CRC, 0 frame, 59 overrun, 0 ignored, 0 abort

        0 output errors, 0 collisions, 2 interface resets

        2 input errors, 0 CRC, 0 frame, 2 overrun, 0 ignored, 0 abort

        0 output errors, 0 collisions, 0 interface resets

asa# sh cpu

CPU utilization for 5 seconds = 66%; 1 minute: 60%; 5 minutes: 49%

asa# sh conn count

6709 in use, 8161 most used

asa# sh resource usage

Resource              Current         Peak      Limit        Denied Context

SSH                         1            2          5             0 System

ASDM                        3            5          5            22 System

Syslogs [rate]            501         1376        N/A             0 System

Conns                    6971         8161     280000             0 System

Xlates                   2405         3264        N/A             0 System

Hosts                    3248         3403        N/A             0 System

Conns [rate]              260          946        N/A             0 System

Inspects [rate]            61          280        N/A             0 SystemasaMRW# sh resource usage
Resource              Current         Peak      Limit        Denied Context
SSH                         1            2          5             0 System
ASDM                        3            5          5            22 System
Syslogs [rate]            501         1376        N/A             0 System
Conns                    6971         8161     280000             0 System
Xlates                   2405         3264        N/A             0 System
Hosts                    3248         3403        N/A             0 System
Conns [rate]              260          946        N/A             0 System
Inspects [rate]            61          280        N/A             0 System

thank you very much for your help in advance

0 Helpful

Go to solution
Julio Carvajal
VIP Alumni
VIP Alumni
In response to Oscar Cardiel

‎05-15-2012 09:42 AM

Hello Oscar,

Thanks for the information.

I think our best suggestion here would be to create captures on both interfaces on the ASA involded on this communication and then check all the packets captured on both interfaces.

Also do a ASP capture that will show us all the packets being dropped by the ASA algorithm ( Acelerated Security Path).. We will need to see the ICMP packets in this list in order to make sure the ASA is the device causing the problem.

Regards,

Do rate all the helpful posts.

Julio

Julio Carvajal
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC
0 Helpful

Go to solution
lcambron
Level 3
Level 3
In response to Julio Carvajal

‎05-15-2012 11:29 AM

Oscar,

As Julio said, we can confirm this with regular and arp captures.

cap asp type asp-drop all buffer 9999999

show cap asp | inc IP_address

The buffered for this capture gets full very fast, cuz it captures all drops on the ASA, so monitor the same with command 'show capture'

to clean it;  'clear capture asp'

Set simultaneous captures on ingress and egress interfaces to see how many packets are getting to the ASA and how many are leaving.

capture capin interface inside match icmp host source_IP host destination_IP

capture capout interface outside match icmp host NAT'ed_IP host destination_IP

Adding icmp inspection wouldn't hurt.

Felipe.

0 Helpful

Go to solution
Oscar Cardiel
Level 1
Level 1
In response to lcambron

‎05-16-2012 03:45 AM

Actually I followed your recommendation about capture icmp traffic on ingress and egress interfaces to see how many packets are getting to the ASA and how many are leaving... Dammit!, I saw the same input and output traffic. I can’t see on the ASP capture any icmp packet being dropped by the ASA…

Thxs a lot guys for your help, I really appreciated that.

asa(config)# sh capture

capture capin type raw-data interface franqui [Capturing - 204480 bytes]

  match icmp host 192.168.3.130 host 172.31.5.28

capture capout type raw-data interface inside [Capturing - 204480 bytes]

  match icmp host 192.168.3.130 host 172.31.5.28

capture asp type asp-drop all buffer 9999999 [Capturing - 9880419 bytes]

asa(config)#

asa(config)# sho cap asp | i 192.168.3.130

1094: 11:15:02.770056 192.168.3.130.80 > 10.150.4.139.52083: . ack 1800180435 win 64240

8427: 11:16:39.131340 192.168.3.130.137 > 192.168.3.255.137:  udp 50

8534: 11:16:39.877548 192.168.3.130.137 > 192.168.3.255.137:  udp 50

8606: 11:16:40.624982 192.168.3.130.137 > 192.168.3.255.137:  udp 50

13257: 11:17:46.657253 802.1Q vlan#1200 P0 10.104.104.36.137 > 192.168.3.130.137:  udp 50

15450: 11:18:18.148170 192.168.3.130.137 > 192.168.3.255.137:  udp 50

23235: 11:20:01.004226 802.1Q vlan#1200 P0 10.104.104.36.137 > 192.168.3.130.137:  udp 50

24334: 11:20:15.551271 192.168.3.130.138 > 192.168.3.255.138:  udp 201

28941: 11:21:21.650265 802.1Q vlan#1200 P0 10.104.104.36.137 > 192.168.3.130.137:  udp 50

30622: 11:21:47.743842 802.1Q vlan#1200 P0 10.104.104.36.137 > 192.168.3.130.137:  udp 50

38870: 11:23:44.843721 192.168.3.130.137 > 192.168.3.255.137:  udp 50

51315: 11:26:39.053433 192.168.3.130.137 > 192.168.3.255.137:  udp 50

51382: 11:26:39.790349 192.168.3.130.137 > 192.168.3.255.137:  udp 50

51438: 11:26:40.540285 192.168.3.130.137 > 192.168.3.255.137:  udp 50

66736: 11:30:18.165610 192.168.3.130.137 > 192.168.3.255.137:  udp 50

75694: 11:32:17.742301 192.168.3.130.138 > 192.168.3.255.138:  udp 201

asa(config)#  sho cap asp | i 172.31.5.28

458: 11:14:54.353894 172.31.5.28.138 > 172.31.255.255.138:  udp 201

9219: 11:16:49.088404 172.31.5.28.63954 > 172.31.5.254.443: F 1216116677:1216116677(0) ack 3105814648 win 65535

9220: 11:16:49.129647 172.31.5.28.63955 > 172.31.5.254.443: F 3311562654:3311562654(0) ack 1788680111 win 65535

9907: 11:16:58.316817 172.31.5.28.63957 > 172.31.5.254.443: F 2372132966:2372132966(0) ack 3446739520 win 65535

9924: 11:16:58.465155 172.31.5.28.63958 > 172.31.5.254.443: F 3052199358:3052199358(0) ack 4060397993 win 65535

9926: 11:16:58.478353 172.31.5.28.63959 > 172.31.5.254.443: F 2416626469:2416626469(0) ack 600987510 win 65535

10207: 11:17:01.425911 172.31.5.28.63960 > 172.31.5.254.443: F 4284764250:4284764250(0) ack 2764360472 win 65535

10209: 11:17:01.462653 172.31.5.28.63962 > 172.31.5.254.443: F 2897853406:2897853406(0) ack 36732653 win 65535

10562: 11:17:06.392862 172.31.5.28.63963 > 172.31.5.254.443: F 3418331111:3418331111(0) ack 4106159305 win 65535

10566: 11:17:06.437782 172.31.5.28.63965 > 172.31.5.254.443: F 351951743:351951743(0) ack 3852846382 win 65535

10570: 11:17:06.491109 172.31.5.28.63964 > 172.31.5.254.443: R 3743180378:3743180378(0) ack 2036124283 win 0

10571: 11:17:06.491322 172.31.5.28.63964 > 172.31.5.254.443: R 3743180378:3743180378(0) win 0

10605: 11:17:06.990885 172.31.5.28.63967 > 172.31.5.254.443: R 1622463220:1622463220(0) ack 1444481707 win 0

10606: 11:17:06.991113 172.31.5.28.63966 > 172.31.5.254.443: F 4291895411:4291895411(0) ack 1869758408 win 65535

10607: 11:17:06.991205 172.31.5.28.63967 > 172.31.5.254.443: R 1622463220:1622463220(0) win 0

10716: 11:17:09.033506 172.31.5.28.63968 > 172.31.5.254.443: F 1213337051:1213337051(0) ack 2793080200 win 65535

28699: 11:21:18.048444 172.31.5.28.63978 > 172.31.5.254.443: F 3516588597:3516588597(0) ack 4082523455 win 65535

28702: 11:21:18.082530 172.31.5.28.63979 > 172.31.5.254.443: F 2624860618:2624860618(0) ack 1229240024 win 65535

29157: 11:21:25.289917 172.31.5.28.63980 > 172.31.5.254.443: F 1840304766:1840304766(0) ack 3822990521 win 65535

29159: 11:21:25.369808 172.31.5.28.63983 > 172.31.5.254.443: F 879930713:879930713(0) ack 1786169064 win 65535

29160: 11:21:25.381587 172.31.5.28.63984 > 172.31.5.254.443: F 427260469:427260469(0) ack 341330867 win 65535

29321: 11:21:28.067242 172.31.5.28.63985 > 172.31.5.254.443: F 2238218183:2238218183(0) ack 2288210469 win 65535

29325: 11:21:28.098902 172.31.5.28.63986 > 172.31.5.254.443: F 118474273:118474273(0) ack 4277263123 win 65535

29665: 11:21:33.143074 172.31.5.28.63987 > 172.31.5.254.443: F 1353084768:1353084768(0) ack 2091147977 win 65535

29667: 11:21:33.174566 172.31.5.28.63989 > 172.31.5.254.443: F 3477322977:3477322977(0) ack 2198309559 win 65535

29701: 11:21:33.621763 172.31.5.28.63988 > 172.31.5.254.443: R 1603447742:1603447742(0) ack 2966254164 win 0

29702: 11:21:33.622007 172.31.5.28.63991 > 172.31.5.254.443: R 272764148:272764148(0) ack 2362014837 win 0

29703: 11:21:33.622282 172.31.5.28.63988 > 172.31.5.254.443: R 1603447742:1603447742(0) win 0

29704: 11:21:33.622328 172.31.5.28.63991 > 172.31.5.254.443: R 272764148:272764148(0) win 0

29767: 11:21:34.860764 172.31.5.28.63992 > 172.31.5.254.443: F 4226212155:4226212155(0) ack 2230361367 win 65535

52256: 11:26:52.323835 172.31.5.28.138 > 172.31.255.255.138:  udp 201

asa(config)# sho cap asp | i 192.168.3.130
1094: 11:15:02.770056 192.168.3.130.80 > 10.150.4.139.52083: . ack 1800180435 win 64240
8427: 11:16:39.131340 192.168.3.130.137 > 192.168.3.255.137:  udp 50
8534: 11:16:39.877548 192.168.3.130.137 > 192.168.3.255.137:  udp 50
8606: 11:16:40.624982 192.168.3.130.137 > 192.168.3.255.137:  udp 50
13257: 11:17:46.657253 802.1Q vlan#1200 P0 10.104.104.36.137 > 192.168.3.130.137:  udp 50
15450: 11:18:18.148170 192.168.3.130.137 > 192.168.3.255.137:  udp 50
23235: 11:20:01.004226 802.1Q vlan#1200 P0 10.104.104.36.137 > 192.168.3.130.137:  udp 50
24334: 11:20:15.551271 192.168.3.130.138 > 192.168.3.255.138:  udp 201
28941: 11:21:21.650265 802.1Q vlan#1200 P0 10.104.104.36.137 > 192.168.3.130.137:  udp 50
30622: 11:21:47.743842 802.1Q vlan#1200 P0 10.104.104.36.137 > 192.168.3.130.137:  udp 50
38870: 11:23:44.843721 192.168.3.130.137 > 192.168.3.255.137:  udp 50
51315: 11:26:39.053433 192.168.3.130.137 > 192.168.3.255.137:  udp 50
51382: 11:26:39.790349 192.168.3.130.137 > 192.168.3.255.137:  udp 50
51438: 11:26:40.540285 192.168.3.130.137 > 192.168.3.255.137:  udp 50
66736: 11:30:18.165610 192.168.3.130.137 > 192.168.3.255.137:  udp 50
75694: 11:32:17.742301 192.168.3.130.138 > 192.168.3.255.138:  udp 201

asa(config)#  sho cap asp | i 172.31.5.28
458: 11:14:54.353894 172.31.5.28.138 > 172.31.255.255.138:  udp 201
9219: 11:16:49.088404 172.31.5.28.63954 > 172.31.5.254.443: F 1216116677:1216116677(0) ack 3105814648 win 65535
9220: 11:16:49.129647 172.31.5.28.63955 > 172.31.5.254.443: F 3311562654:3311562654(0) ack 1788680111 win 65535
9907: 11:16:58.316817 172.31.5.28.63957 > 172.31.5.254.443: F 2372132966:2372132966(0) ack 3446739520 win 65535
9924: 11:16:58.465155 172.31.5.28.63958 > 172.31.5.254.443: F 3052199358:3052199358(0) ack 4060397993 win 65535
9926: 11:16:58.478353 172.31.5.28.63959 > 172.31.5.254.443: F 2416626469:2416626469(0) ack 600987510 win 65535
10207: 11:17:01.425911 172.31.5.28.63960 > 172.31.5.254.443: F 4284764250:4284764250(0) ack 2764360472 win 65535
10209: 11:17:01.462653 172.31.5.28.63962 > 172.31.5.254.443: F 2897853406:2897853406(0) ack 36732653 win 65535
10562: 11:17:06.392862 172.31.5.28.63963 > 172.31.5.254.443: F 3418331111:3418331111(0) ack 4106159305 win 65535
10566: 11:17:06.437782 172.31.5.28.63965 > 172.31.5.254.443: F 351951743:351951743(0) ack 3852846382 win 65535
10570: 11:17:06.491109 172.31.5.28.63964 > 172.31.5.254.443: R 3743180378:3743180378(0) ack 2036124283 win 0
10571: 11:17:06.491322 172.31.5.28.63964 > 172.31.5.254.443: R 3743180378:3743180378(0) win 0
10605: 11:17:06.990885 172.31.5.28.63967 > 172.31.5.254.443: R 1622463220:1622463220(0) ack 1444481707 win 0
10606: 11:17:06.991113 172.31.5.28.63966 > 172.31.5.254.443: F 4291895411:4291895411(0) ack 1869758408 win 65535
10607: 11:17:06.991205 172.31.5.28.63967 > 172.31.5.254.443: R 1622463220:1622463220(0) win 0
10716: 11:17:09.033506 172.31.5.28.63968 > 172.31.5.254.443: F 1213337051:1213337051(0) ack 2793080200 win 65535
28699: 11:21:18.048444 172.31.5.28.63978 > 172.31.5.254.443: F 3516588597:3516588597(0) ack 4082523455 win 65535
28702: 11:21:18.082530 172.31.5.28.63979 > 172.31.5.254.443: F 2624860618:2624860618(0) ack 1229240024 win 65535
29157: 11:21:25.289917 172.31.5.28.63980 > 172.31.5.254.443: F 1840304766:1840304766(0) ack 3822990521 win 65535
29159: 11:21:25.369808 172.31.5.28.63983 > 172.31.5.254.443: F 879930713:879930713(0) ack 1786169064 win 65535
29160: 11:21:25.381587 172.31.5.28.63984 > 172.31.5.254.443: F 427260469:427260469(0) ack 341330867 win 65535
29321: 11:21:28.067242 172.31.5.28.63985 > 172.31.5.254.443: F 2238218183:2238218183(0) ack 2288210469 win 65535
29325: 11:21:28.098902 172.31.5.28.63986 > 172.31.5.254.443: F 118474273:118474273(0) ack 4277263123 win 65535
29665: 11:21:33.143074 172.31.5.28.63987 > 172.31.5.254.443: F 1353084768:1353084768(0) ack 2091147977 win 65535
29667: 11:21:33.174566 172.31.5.28.63989 > 172.31.5.254.443: F 3477322977:3477322977(0) ack 2198309559 win 65535
29701: 11:21:33.621763 172.31.5.28.63988 > 172.31.5.254.443: R 1603447742:1603447742(0) ack 2966254164 win 0
29702: 11:21:33.622007 172.31.5.28.63991 > 172.31.5.254.443: R 272764148:272764148(0) ack 2362014837 win 0
29703: 11:21:33.622282 172.31.5.28.63988 > 172.31.5.254.443: R 1603447742:1603447742(0) win 0
29704: 11:21:33.622328 172.31.5.28.63991 > 172.31.5.254.443: R 272764148:272764148(0) win 0
29767: 11:21:34.860764 172.31.5.28.63992 > 172.31.5.254.443: F 4226212155:4226212155(0) ack 2230361367 win 65535
52256: 11:26:52.323835 172.31.5.28.138 > 172.31.255.255.138:  udp 201

0 Helpful

Go to solution
Oscar Cardiel
Level 1
Level 1
In response to Oscar Cardiel

‎05-16-2012 07:20 AM

I have collected the debug for the ICMP echo request and replies on the ASA and every echo request has its own echo reply. I saw when an ICMP fail, “seq” jumps too:

ICMP echo request from inside:172.31.5.28 to franqui:192.168.3.130 ID=15 seq=23082 len=32

ICMP echo reply from franqui:192.168.3.130 to inside:172.31.5.28 ID=15 seq=23082 len=32

ICMP echo request from inside:172.31.5.28 to franqui:192.168.3.130 ID=15 seq=23084 len=32

ICMP echo reply from franqui:192.168.3.130 to inside:172.31.5.28 ID=15 seq=23084 len=32

ICMP echo request from inside:172.31.5.28 to franqui:192.168.3.130 ID=15 seq=23085 len=32

ICMP echo reply from franqui:192.168.3.130 to inside:172.31.5.28 ID=15 seq=23085 len=32

and sometimes, I saw when an ICMP fail, debug shows us an ICMP to ASA inside interface, too…

ICMP echo request from inside:172.31.5.28 to franqui:192.168.3.130 ID=15 seq=23086 len=32

ICMP echo reply from franqui:192.168.3.130 to inside:172.31.5.28 ID=15 seq=23086 len=32

ICMP echo request from 172.31.5.28 to 172.31.5.254 ID=15 seq=23087 len=32

ICMP echo reply from 172.31.5.254 to 172.31.5.28 ID=15 seq=23087 len=32

ICMP echo reply from franqui:192.168.3.130 to inside:172.31.5.28 ID=15 seq=23088 len=32

ICMP echo request from inside:172.31.5.28 to franqui:192.168.3.130 ID=15 seq=23089 len=32

ICMP echo reply from franqui:192.168.3.130 to inside:172.31.5.28 ID=15 seq=23089 len=32

ICMP echo request from inside:172.31.5.28 to franqui:192.168.3.130 ID=15 seq=23090 len=32

ICMP echo reply from franqui:192.168.3.130 to inside:172.31.5.28 ID=15 seq=23090 len=32

Regards,

0 Helpful

Go to solution
Julio Carvajal
VIP Alumni
VIP Alumni
In response to Oscar Cardiel

‎05-16-2012 11:28 AM

Hello Oscar,

If you see the same amount of ICMP packets on both interfaces that will let us know the problem is not on the firewall ( you are also not seeing the packets on the ASP capture so that will let us know the same thing)

What else is in between, you will need to check that...

Regards,

Julio

Julio Carvajal
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC
0 Helpful

Go to solution
Oscar Cardiel
Level 1
Level 1
In response to Julio Carvajal

‎05-17-2012 03:24 AM

Thxs Julio,

From a host in inside I have captured:

72           31.156111            172.31.5.28          192.168.3.130     ICMP      74           Echo (ping) request  id=0x000f, seq=37555/45970, ttl=128

73           31.157085            192.168.3.130     172.31.5.28          ICMP      74           Echo (ping) reply    id=0x000f, seq=37555/45970, ttl=128

74           32.156145           172.31.5.28         192.168.3.130    ICMP      74           Echo (ping) request  id=0x000f, seq=37556/46226, ttl=128

75           36.999875           172.31.5.28         192.168.3.130    ICMP      74           Echo (ping) request  id=0x000f, seq=37557/46482, ttl=128

76           37.000943            192.168.3.130     172.31.5.28          ICMP      74           Echo (ping) reply    id=0x000f, seq=37557/46482, ttl=128

ASA don't show us the seq=37556.

ICMP echo request from inside:172.31.5.28 to mrwfranqui:192.168.3.130 ID=15 seq=37555 len=32

ICMP echo reply from mrwfranqui:192.168.3.130 to inside:172.31.5.28 ID=15 seq=37555 len=32

ICMP echo request from inside:172.31.5.28 to mrwfranqui:192.168.3.130 ID=15 seq=37557 len=32

ICMP echo reply from mrwfranqui:192.168.3.130 to inside:172.31.5.28 ID=15 seq=37557 len=32

Host and ASA are in the same Vlan, connected both to the switch core 6509VSS. Switch core has more vlans and ICMP packets works fine between them.

0 Helpful

Go to solution
Oscar Cardiel
Level 1
Level 1

‎05-18-2012 02:01 AM

Hi guys,

I got to solve the issue unconfiguring “auto qos” in core Cat6509VSS...¿?

Thanks both for you helps!

0 Helpful
Customers Also Viewed These Support Documents
Review Cisco Networking for a $25 gift card