About "debug ip icmp" command.

speculor_cisco · ‎10-30-2010

I am doing some scenarios with GNS simulator.

I have noted that the command debug ip icmp shows me only the echo reply sent from the router.

For example, if I ping from a pc the gateway on the router, I see only the echo reply sent from the router

to the pc and not the echo request sent from the pc to the router.

It seems that the command shows only outcoming icmp traffic and not incoming icmp traffic.

Thanks.

Peter Paluch · ‎10-30-2010

Hello,

I believe that the debug ip icmp actually shows you the working of the ICMP subsystem inside the IOS, perhaps not in a packet-by-packet fashion but rather in a more transactional manner - what is actually done. The ping command itself is a userspace command that obviously generates the ICMP echo-request messages on its own, not using the ICMP subsystem inside the IOS IP driver. Therefore, the debug ip icmp command does not show you the messages originated by the ping command because they are not originated by the ICMP subsystem.

I've made a quick test: Two routers, R1 and R2, interconnected by a direct link, both having the debug icmp packet configured. Now, on R1, I get the following:

R1#ping 10.0.12.2 repeat 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 10.0.12.2, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 8/8/8 ms
R1#
*Mar 2 11:55:50.507: ICMP: echo reply rcvd, src 10.0.12.2, dst 10.0.12.1

and on R2, this is displayed:

R2#
*Mar 2 11:55:50.311: ICMP: echo reply sent, src 10.0.12.2, dst 10.0.12.1

So, R1 reports incoming ICMP messages, the R2 reports outgoing messages, both visibly procesed by the ICMP subsystem in the IOS IP driver.

This may sound quite strangely, I understand that. The fact, however, is that the Unix/Linux ping command works precisely in the same way - it opens a raw IP socket and constructs the entire ICMP message itself, without asking the ICMP "driver" to do that.

Best regards,

Peter

Mahesh Gohil · ‎10-30-2010

Hi,

icmp will not show request packet if you are seeing this output on destination router. But it will show you when you see output on source router. In second case also it will not show you echo request but shows something like

*Oct 28 00:20:43.327: ICMP: echo reply sent, src 10.0.1.50, dst 10.0.1.50
*Oct 28 00:20:43.327: ICMP: echo reply rcvd, src 10.0.1.50, dst 10.0.1.50.

To see if request packets is hitting to your router or not you need debug ip packets detail command and search for type code (8)..something like below

*Oct 28 00:21:47.495: IP: s=10.0.1.49 (POS10/1/0), d=10.0.1.50 (POS10/1/0), len 100, rcvd 3
*Oct 28 00:21:47.495: ICMP type=8, code=0

where 8 indicate it is request packet and if it is type =0 then it indicate reply packet

Hope this is useful

Regards

Mahesh

speculor_cisco · ‎10-30-2010

Thanks for the two answers.

scnetterv · ‎07-30-2014

This is an old question but, in the interest of providing what I believe is a more complete answer. . .

Setup an acl to filter only icmp traffic and then use that to decide which traffic to show in the debug ip packet detail command. Below is an example where the ping from an endpoint fails because the destination network is not in the routing table.

Example:

switch>conf t

switch(config)#access-list 101 permit icmp any any

switch(config)#end

switch>debug ip packet detail 101

Mar 5 00:44:42.386: IP: s=173.227.240.202 (Vlan20), d=10.234.62.23, len 84, input feature
*Mar 5 00:44:42.386:     ICMP type=8, code=0, MCI Check(73), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Mar 5 00:44:42.386: FIBipv4-packet-proc: route packet from Vlan20 src 173.227.240.202 dst 10.234.62.23
*Mar 5 00:44:42.386: FIBfwd-proc: Default:0.0.0.0/0 process level forwarding
*Mar 5 00:44:42.386: FIBfwd-proc: depth 0 first_idx 0 paths 1 long 0(0)
*Mar 5 00:44:42.386: FIBfwd-proc: try path 0 (of 1) v4-sp first short ext 0(-1)
*Mar 5 00:44:42.386: FIBfwd-proc: v4-sp valid
*Mar 5 00:44:42.386: FIBfwd-proc: no nh type 8 - deag
*Mar 5 00:44:42.386: FIBfwd-proc: ip_pak_table 0 ip_nh_table 65535 if none nh none deag 1 chg_if 0 via fib 0 path type special prefix
*Mar 5 00:44:42.386: FIBfwd-proc: Default:0.0.0.0/0 not enough info to forward via fib (none none)
*Mar 5 00:44:42.386: FIBipv4-packet-proc: packet routing failed
*Mar 5 00:44:42.386: IP: s=173.227.240.202 (Vlan20), d=10.234.62.23, len 84, unroutable
*Mar 5 00:44:42.386:     ICMP type=8, code=0
*Mar 5 00:44:42.386: ICMP: dst (10.234.62.23) host unreachable sent to 173.227.240.202
*Mar 5 00:44:42.386: IP: s=173.227.240.201 (local), d=173.227.240.202, len 56, local feature
*Mar 5 00:44:42.386:     ICMP type=3, code=1, RCLI(7), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Mar 5 00:44:42.386: IP: s=173.227.240.201 (local), d=173.227.240.202, len 56, local feature
*Mar 5 00:44:42.386:     ICMP type=3, code=1, Local Clustering(8), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Mar 5 00:44:42.386: IP: s=173.227.240.201 (local), d=173.227.240.202, len 56, local feature
*Mar 5 00:44:42.394:     ICMP type=3, code=1, Wireless Controller(10), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Mar 5 00:44:42.394: FIBipv4-packet-proc: route packet from (local) src 173.227.240.201 dst 173.227.240.202
*Mar 5 00:44:42.394: FIBfwd-proc: packet routed by adj to Vlan20 173.227.240.202
*Mar 5 00:44:42.394: FIBipv4-packet-proc: packet routing succeeded