debug ip icmp

Paul#4Paul#4 Inactive Imported Users Posts: 57 ■■□□□□□□□□
in CCNP
Hey Folks,

I'm debugging my pings and I only get ICMP echoes going one way even though the pings are successful. Why is that? According to cisco documentation I should get output of echoes going both ways.
Is there a way to configure the debug ip icmp command to give me the output I want?

Thanks in advance :)
Gimme gimme gimme
· Share on FacebookShare on Twitter

Comments

  • Paul BozPaul Boz Member Posts: 2,620 ■■■■■■■■□□
    I just tested it and found that I'm also only getting ICMP traps in one direction, so I turned on ICMP debugging on both devices (originator and target) and saw the complete sequence of send/receives.
    R4#ping 192.168.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 72/108/156 ms
R4#
02:19:18: ICMP: echo reply rcvd, src 192.168.1.2, dst 192.168.3.2
02:19:18: ICMP: echo reply rcvd, src 192.168.1.2, dst 192.168.3.2
02:19:18: ICMP: echo reply rcvd, src 192.168.1.2, dst 192.168.3.2
02:19:18: ICMP: echo reply rcvd, src 192.168.1.2, dst 192.168.3.2
02:19:18: ICMP: echo reply rcvd, src 192.168.1.2, dst 192.168.3.2
R4#

    R1#
02:21:58: ICMP: echo reply sent, src 192.168.1.2, dst 192.168.3.2
02:21:58: ICMP: echo reply sent, src 192.168.1.2, dst 192.168.3.2
02:21:58: ICMP: echo reply sent, src 192.168.1.2, dst 192.168.3.2
02:21:58: ICMP: echo reply sent, src 192.168.1.2, dst 192.168.3.2
02:21:58: ICMP: echo reply sent, src 192.168.1.2, dst 192.168.3.2
R1#

    Basically you ARE seeing both sides. the !!!!! confirms that the packets were sent, and the debug confirms the reply.
    CCNP | CCIP | CCDP | CCNA, CCDA
    CCNA Security | GSEC |GCFW | GCIH | GCIA
    pbosworth@gmail.com
    http://twitter.com/paul_bosworth
    Blog: http://www.infosiege.net/
    · Share on FacebookShare on Twitter
  • Paul#4Paul#4 Inactive Imported Users Posts: 57 ■■□□□□□□□□
    Good idea Paul.

    So this means the ICMP Echo Requests are not being captured by the debug ip ICMP command.

    The Echo Replies are working....

    I guess we know they are being sent because of the ping command, but I thought we would be able to monitor them with debug ip icmp. Thanks for the help.


    This kind of sucks but I guess thats the way it works.

    :)
    Gimme gimme gimme
    · Share on FacebookShare on Twitter
  • Paul BozPaul Boz Member Posts: 2,620 ■■■■■■■■□□
    I think the reasoning is that well, you know where you want your packets to go, and you more than likely know the interface they're leaving (I hope so at least) so just by telling you that the ICMP pings are completing (!!!!!) it's giving you all you really need to know.
    CCNP | CCIP | CCDP | CCNA, CCDA
    CCNA Security | GSEC |GCFW | GCIH | GCIA
    pbosworth@gmail.com
    http://twitter.com/paul_bosworth
    Blog: http://www.infosiege.net/
    · Share on FacebookShare on Twitter
  • tech-airmantech-airman Member Posts: 953
    Paul#4 wrote:
    Hey Folks,

    I'm debugging my pings and I only get ICMP echoes going one way even though the pings are successful. Why is that? According to cisco documentation I should get output of echoes going both ways.
    Is there a way to configure the debug ip icmp command to give me the output I want?

    Thanks in advance :)

    Paul#4,

    Questions:
    1. Which model of router are you pinging from?
    2. Which IOS version do you have running on the router?
    3. What "cisco documentation" are you referring to?

    Here's what my Cisco 2621 router running IOS version 12.2(5d) said. 172.16.185.254 is the IP address for the router's fa0/1 interface. 192.168.0.1 is the IP address for my DSL modem.
    >en
Password:
#debug ?
  aaa                 AAA Authentication, Authorization and Accounting
  access-expression   Boolean access expression
  adjacency           adjacency
  all                 Enable all debugging
  arp                 IP ARP and HP Probe transactions
  async               Async interface information
  backup              Backup events
  bri-interface       bri network interface events
  callback            Callback activity
  cca                 CCA activity
  cdapi               CDAPI information
  cdp                 CDP information
  chat                Chat scripts activity
  compress            COMPRESS traffic
  condition           Condition
  confmodem           Modem configuration database
  conn                Connection Manager information
  cops                COPS
  cpp                 Cpp information
  custom-queue        Custom output queueing
  dhcp                DHCP client activity
  dialer              Dial on Demand
  dnsix               Dnsix information
  domain              Domain Name System
  dxi                 atm-dxi information
  eigrp               EIGRP Protocol information
  entry               Incoming queue entries
  ethernet-interface  Ethernet network interface events
  fastethernet        Fast Ethernet interface information
  frame-relay         Frame Relay
  interface           interface
  ip                  IP information
  isdn                ISDN information
  lapb                LAPB protocol transactions
  lex                 LAN Extender protocol
  list                Set interface or/and access list for the next debug
                      command
  llc2                LLC2 type II Information
  modem               Modem control/process activation
  nhrp                NHRP protocol
  ntp                 NTP information
  nvram               Debug NVRAM behavior
  packet              Log unknown packets
  pad                 X25 PAD protocol
  ppp                 PPP (Point to Point Protocol) information
  printer             LPD printer protocol
  priority            Priority output queueing
  probe               HP Probe Proxy Requests
  qdm                 QoS Device Manager
  radius              RADIUS protocol
  rif                 RIF cache transactions
  rtr                 RTR Monitor Information
  serial              Serial interface information
  smf                 Software MAC filter
  snapshot            Snapshot activity
  snmp                SNMP information
  spanning-tree       Spanning tree debugging
  standby             Hot standby protocol
  tacacs              TACACS authentication and authorization
  tbridge             Transparent Bridging
  telnet              Incoming telnet connections
  template            Template activity
  tftp                TFTP debugging
  tgrm                Trunk Group Resource Manager info
  token               Token Ring information
  tunnel              Generic Tunnel Interface
  udptn               UDPtn async data transport
  v120                V120 information
  vprofile            Virtual Profile information
  vtemplate           Virtual Template information
  x25                 X.25, CMNS and XOT information
  x28                 X28 mode

#debug ip ?
  bgp                     BGP information
  cache                   IP cache operations
  cef                     IP CEF operations
  cgmp                    CGMP protocol activity
  dhcp                    Dynamic Host Configuration Protocol
  drp                     Director response protocol
  dvmrp                   DVMRP protocol activity
  egp                     EGP information
  eigrp                   IP-EIGRP information
  error                   IP error debugging
  flow                    IP Flow switching operations
  ftp                     FTP dialogue
  html                    HTML connections
  http                    HTTP connections
  icmp                    ICMP transactions
  igmp                    IGMP protocol activity
  igrp                    IGRP information
  interface               IP interface configuration changes
  mbgp                    MBGP information
  mcache                  IP multicast cache operations
  mhbeat                  IP multicast heartbeat monitoring
  mpacket                 IP multicast packet debugging
  mrm                     IP Multicast Routing Monitor
  mrouting                IP multicast routing table activity
  msdp                    Multicast Source Discovery Protocol (MSDP)
  mtag                    IP multicast tagswitching activity
  nat                     NAT events
  nbar                    StILE - traffic classification Engine
  ospf                    OSPF information
  packet                  General IP debugging and IPSO security transactions
  peer                    IP peer address activity
  pim                     PIM protocol activity
  policy                  Policy routing
  rgmp                    RGMP protocol activity
  rip                     RIP protocol transactions
  routing                 Routing table events
  rsvp                    RSVP protocol activity
  rtp                     RTP information
  sd                      Session Directory (SD)
  security                IP security options
  socket                  Socket event
  tcp                     TCP information
  tempacl                 IP temporary ACL
  trigger-authentication  Trigger authentication
  udp                     UDP based transactions
  urd                     URL RenDezvous (URD)
  wccp                    WCCP information

#debug ip icmp ?
  <cr>

#debug ip icmp

    Looks like for me, "#debug ip icmp" is as "deep" as I can get for the command. Here's some router output when I ping: 1) the ip address for one of the router's interfaces and 2) the ip address for another router.
    #debug ip icmp
ICMP packet debugging is on
#ping 172.16.185.254

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.185.254, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
#
1y27w: ICMP: echo reply sent, src 172.16.185.254, dst 172.16.185.254
1y27w: ICMP: echo reply rcvd, src 172.16.185.254, dst 172.16.185.254
1y27w: ICMP: echo reply sent, src 172.16.185.254, dst 172.16.185.254
1y27w: ICMP: echo reply rcvd, src 172.16.185.254, dst 172.16.185.254
1y27w: ICMP: echo reply sent, src 172.16.185.254, dst 172.16.185.254
1y27w: ICMP: echo reply rcvd, src 172.16.185.254, dst 172.16.185.254
1y27w: ICMP: echo reply sent, src 172.16.185.254, dst 172.16.185.254
1y27w: ICMP: echo reply rcvd, src 172.16.185.254, dst 172.16.185.254
1y27w: ICMP: echo reply sent, src 172.16.185.254, dst 172.16.185.254
1y27w: ICMP: echo reply rcvd, src 172.16.185.254, dst 172.16.185.254
#ping 192.168.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
#
1y27w: ICMP: echo reply rcvd, src 192.168.0.1, dst 192.168.1.2
1y27w: ICMP: echo reply rcvd, src 192.168.0.1, dst 192.168.1.2
1y27w: ICMP: echo reply rcvd, src 192.168.0.1, dst 192.168.1.2
1y27w: ICMP: echo reply rcvd, src 192.168.0.1, dst 192.168.1.2
1y27w: ICMP: echo reply rcvd, src 192.168.0.1, dst 192.168.1.2

    The key words that you see are "echo reply." That means "#debug ip icmp" only tracks the "echo reply" packets from the destination back to the source.

    In order for your to "see what you want" is for you to turn on "#debug ip packet detail" and look out for the lines with "ICMP type=8" like the following.... 
    #ping 172.16.185.254

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.185.254, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/8 ms
#
1y27w: IP: s=172.16.185.254 (local), d=172.16.185.254 (FastEthernet0/1), len 100
, sending
1y27w:     ICMP type=8, code=0
1y27w: IP: s=172.16.185.254 (FastEthernet0/1), d=172.16.185.254 (FastEthernet0/1
), len 100, rcvd 3
1y27w:     ICMP type=8, code=0
1y27w: IP: s=172.16.185.254 (local), d=172.16.185.254 (FastEthernet0/1), len 100
, sending
1y27w:     ICMP type=0, code=0
1y27w: IP: s=172.16.185.254 (FastEthernet0/1), d=172.16.185.254 (FastEthernet0/1
), len 100, rcvd 3
1y27w:     ICMP type=0, code=0
1y27w: IP: s=172.16.185.254 (local), d=172.16.185.254 (FastEthernet0/1), len 100
, sending
1y27w:     ICMP type=8, code=0
1y27w: IP: s=172.16.185.254 (FastEthernet0/1), d=172.16.185.254 (FastEthernet0/1
), len 100, rcvd 3
1y27w:     ICMP type=8, code=0
1y27w: IP: s=172.16.185.254 (local), d=172.16.185.254 (FastEthernet0/1), len 100
, sending
1y27w:     ICMP type=0, code=0
1y27w: IP: s=172.16.185.254 (FastEthernet0/1), d=172.16.185.254 (FastEthernet0/1
), len 100, rcvd 3
1y27w:     ICMP type=0, code=0
1y27w: IP: s=172.16.185.254 (local), d=172.16.185.254 (FastEthernet0/1), len 100
, sending
1y27w:     ICMP type=8, code=0
1y27w: IP: s=172.16.185.254 (FastEthernet0/1), d=172.16.185.254 (FastEthernet0/1
), len 100, rcvd 3
1y27w:     ICMP type=8, code=0
1y27w: IP: s=172.16.185.254 (local), d=172.16.185.254 (FastEthernet0/1), len 100
, sending
1y27w:     ICMP type=0, code=0
1y27w: IP: s=172.16.185.254 (FastEthernet0/1), d=172.16.185.254 (FastEthernet0/1
), len 100, rcvd 3
1y27w:     ICMP type=0, code=0
1y27w: IP: s=172.16.185.254 (local), d=172.16.185.254 (FastEthernet0/1), len 100
, sending
1y27w:     ICMP type=8, code=0
1y27w: IP: s=172.16.185.254 (FastEthernet0/1), d=172.16.185.254 (FastEthernet0/1
), len 100, rcvd 3
1y27w:     ICMP type=8, code=0
1y27w: IP: s=172.16.185.254 (local), d=172.16.185.254 (FastEthernet0/1), len 100
, sending
1y27w:     ICMP type=0, code=0
1y27w: IP: s=172.16.185.254 (FastEthernet0/1), d=172.16.185.254 (FastEthernet0/1
), len 100, rcvd 3
1y27w:     ICMP type=0, code=0
1y27w: IP: s=172.16.185.254 (local), d=172.16.185.254 (FastEthernet0/1), len 100
, sending
1y27w:     ICMP type=8, code=0
1y27w: IP: s=172.16.185.254 (FastEthernet0/1), d=172.16.185.254 (FastEthernet0/1
), len 100, rcvd 3
1y27w:     ICMP type=8, code=0
1y27w: IP: s=172.16.185.254 (local), d=172.16.185.254 (FastEthernet0/1), len 100
, sending
1y27w:     ICMP type=0, code=0
1y27w: IP: s=172.16.185.254 (FastEthernet0/1), d=172.16.185.254 (FastEthernet0/1
), len 100, rcvd 3
1y27w:     ICMP type=0, code=0

    However, pinging an IP address of another router even with "#debug ip packet detail", I couldn't see any sending or receiving of neither ICMP packets of type 8 nor ICMP packets of type 0.

    So based on "#debug ip icmp" and "#debug ip packet detail", I do not know how to obtain "...output of echos going both ways."

    So I have to ask again what "cisco document" are you referring to when you said "According to cisco documentation I should get output of echoes going both ways."?

    Source:
    1. Understanding the Ping and Traceroute Commands - Cisco Systems - http://www.cisco.com/en/US/products/sw/iosswrel/ps1831/products_tech_note09186a00800a6057.shtml
    · Share on FacebookShare on Twitter
  • dtlokeedtlokee Member Posts: 2,378 ■■■■□□□□□□
    Depending on where the router is located in the path it could be a fast switching issue where the router is fast switching the packets so they are not shown in the debug output. Try using the "no ip route-cache" command to see if it changes.
    The only easy day was yesterday!
    · Share on FacebookShare on Twitter
Sign In or Register to comment.