debug ip icmp

Paul#4Paul#4 ■■□□□□□□□□ Posts: 57Inactive Imported Users ■■□□□□□□□□
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

Comments

  • Paul BozPaul Boz ■■■■■■■■□□ Posts: 2,621Member ■■■■■■■■□□
    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
    [email protected]
    http://twitter.com/paul_bosworth
    Blog: http://www.infosiege.net/
  • Paul#4Paul#4 ■■□□□□□□□□ Posts: 57Inactive Imported Users ■■□□□□□□□□
    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
  • Paul BozPaul Boz ■■■■■■■■□□ Posts: 2,621Member ■■■■■■■■□□
    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
    [email protected]
    http://twitter.com/paul_bosworth
    Blog: http://www.infosiege.net/
  • tech-airmantech-airman Posts: 953Member
    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
  • dtlokeedtlokee Posts: 2,381Member
    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!
Sign In or Register to comment.