Chapter 6 Reading Cisco 1 Reading Organizer Ansewr
Contents
Introduction
This certificate illustrates the employ of the ping and traceroute commands. With the aid of some debug commands, this document captures a more detailed view of how these commands work.
Note:Enabling whatever debug commands on a production router may cause serious problems. We recommend that you lot advisedly read the Utilize the Debug Command section earlier you issue debug commands.
Prerequisites
Requirements
There are no specific requirements for this document.
Components Used
This document is non restricted to specific software and hardware versions.
The information in this certificate was created from the devices in a specific lab environs. All of the devices used in this document started with a cleared (default) configuration. If your network is live, brand certain that yous understand the potential impact of whatsoever command.
Conventions
For more data on document conventions, refer to the Cisco Technical Tips Conventions.
Groundwork Information
In this document, we use the bones configuration shown beneath as a basis for our examples:
The Ping Command
The ping command is a very common method for troubleshooting the accessibility of devices. Information technology uses a series of Internet Command Message Protocol (ICMP) Echo messages to determine:
-
Whether a remote host is active or inactive.
-
The circular-trip filibuster in communicating with the host.
-
Packet loss.
The ping control first sends an echo asking packet to an address, then waits for a reply. The ping is successful merely if:
-
the repeat request gets to the destination, and
-
the destination is able to become an echo reply back to the source within a predetermined time called a timeout. The default value of this timeout is two seconds on Cisco routers.
For all the options about this command, see "Ping" under Troubleshooting Commands.
The TTL value of a ping packet cannot be inverse.
Here is an output example showing the ping command later on enabling the debug ip packet detail command:
Warning:Using the debug ip packet detail command on a product router can cause loftier CPU utilization. This may result in a severe operation degradation or a network outage. We recommend that you carefully read Utilize the Debug Command before issuing debug commands.
Router1#debug ip packet detail IP packet debugging is on (detailed) Router1#ping 12.0.0.two Type escape sequence to abort. Sending v, 100-byte ICMP Echos to 12.0.0.2, timeout is 2 seconds: !!!!! Success charge per unit is 100 percent (5/5), circular-trip min/avg/max = four/vi/viii ms Router1# Jan twenty xv:54:47.487: IP: s=12.0.0.1 (local), d=12.0.0.two (Serial0), len 100, sending Jan 20 15:54:47.491: ICMP type=8, code=0 !--- This is the ICMP packet 12.0.0.i sent to 12.0.0.two. !--- ICMP type=viii corresponds to the echo message. Jan 20 15:54:47.523: IP: s=12.0.0.2 (Serial0), d=12.0.0.i (Serial0), len 100, rcvd 3 Jan 20 xv:54:47.527: ICMP blazon=0, code=0 !--- This is the answer nosotros get from 12.0.0.2. !--- ICMP type=0 corresponds to the repeat reply bulletin. !--- By default, the repeat count is five times, and then there volition be five !--- echo requests, and v echo replies.
The table beneath lists possible ICMP-type values.
| ICMP Type | Literal |
|---|---|
| 0 | repeat-reply |
| iii | destination unreachable lawmaking 0 = internet unreachable 1 = host unreachable 2 = protocol unreachable three = port unreachable 4 = fragmentation needed and DF set 5 = source route failed |
| 4 | source-quench |
| 5 | redirect code 0 = redirect datagrams for the network ane = redirect datagrams for the host 2 = redirect datagrams for the type of service and network three = redirect datagrams for the type of service and host |
| six | alternate-address |
| 8 | echo |
| 9 | router-advertisement |
| 10 | router-solicitation |
| eleven | time-exceeded lawmaking 0 = time to live exceeded in transit 1 = fragment reassembly time exceeded |
| 12 | parameter-problem |
| 13 | timestamp-request |
| fourteen | timestamp-answer |
| xv | information-request |
| xvi | information-answer |
| 17 | mask-request |
| 18 | mask-respond |
| 31 | conversion-mistake |
| 32 | mobile-redirect |
The tabular array below lists the possible output characters from the ping facility:
| Grapheme | Clarification |
|---|---|
| ! | Each exclamation point indicates receipt of a reply. |
| . | Each menses indicates the network server timed out while waiting for a respond. |
| U | A destination unreachable error PDU was received. |
| Q | Source quench (destination too busy). |
| M | Could not fragment. |
| ? | Unknown packet type. |
| & | Packet lifetime exceeded. |
Why Can't I Ping?
If you are not able to successfully ping to an address, consider these causes:
Routing Upshot
Here are examples of unsuccessful ping attempts, determining the problem, and what to do to resolve the trouble.
This scenario is explained using the network topology diagram below:
Router1# ! ! interface Serial0 ip address 12.0.0.one 255.255.255.0 no fair-queue clockrate 64000 ! ! Router2# ! ! interface Serial0 ip address 23.0.0.2 255.255.255.0 no fair-queue clockrate 64000 ! interface Serial1 ip address 12.0.0.2 255.255.255.0 ! ! Router3# ! ! interface Serial0 ip accost 34.0.0.3 255.255.255.0 no fair-queue ! interface Serial1 ip address 23.0.0.iii 255.255.255.0 ! ! Router4# ! ! interface Serial0 ip address 34.0.0.4 255.255.255.0 no fair-queue clockrate 64000 ! !
Let united states of america attempt to ping Router4 from Router1:
Router1#ping 34.0.0.4 Blazon escape sequence to abort. Sending five, 100-byte ICMP Echos to 34.0.0.4, timeout is two seconds: ..... Success rate is 0 percent (0/5)
Let the states have a closer wait at what has happened:
Router1#debug ip bundle IP packet debugging is on
Alert:Using the debug ip packet command on a production router can crusade high cpu utilization. This may result in a severe performance deposition or a network outage. We recommend that yous carefully read Apply the Debug Command earlier issuing debug commands.
Router1#ping 34.0.0.4 Type escape sequence to arrest. Sending v, 100-byte ICMP Echos to 34.0.0.iv, timeout is 2 seconds: January 20 16:00:25.603: IP: s=12.0.0.1 (local), d=34.0.0.4, len 100, unroutable. January 20 16:00:27.599: IP: s=12.0.0.1 (local), d=34.0.0.iv, len 100, unroutable. Jan 20 16:00:29.599: IP: s=12.0.0.one (local), d=34.0.0.4, len 100, unroutable. Jan 20 xvi:00:31.599: IP: southward=12.0.0.1 (local), d=34.0.0.four, len 100, unroutable. Jan 20 sixteen:00:33.599: IP: southward=12.0.0.ane (local), d=34.0.0.4, len 100, unroutable. Success charge per unit is 0 percent (0/v)
Since no routing protocols are running on Router1, it does not know where to send its parcel and we get an "unroutable" message.
At present let us add a static route to Router1:
Router1#configure last Enter configuration commands, one per line. Finish with CNTL/Z. Router1(config)#ip route 0.0.0.0 0.0.0.0 Serial0
We now accept:
Router1#debug ip parcel detail IP packet debugging is on (detailed) Router1#ping 34.0.0.iv Type escape sequence to arrest. Sending 5, 100-byte ICMP Echos to 34.0.0.four, timeout is 2 seconds: U.U.U Success rate is 0 percent (0/5) Jan 20 16:05:30.659: IP: s=12.0.0.ane (local), d=34.0.0.4 (Serial0), len 100, sending Jan 20 16:05:30.663: ICMP blazon=8, code=0 Jan 20 16:05:30.691: IP: s=12.0.0.ii (Serial0), d=12.0.0.1 (Serial0), len 56, rcvd 3 Jan 20 16:05:thirty.695: ICMP type=three, code=1 January twenty 16:05:xxx.699: IP: s=12.0.0.ane (local), d=34.0.0.four (Serial0), len 100, sending January 20 16:05:30.703: ICMP type=8, lawmaking=0 Jan twenty 16:05:32.699: IP: s=12.0.0.one (local), d=34.0.0.iv (Serial0), len 100, sending January twenty 16:05:32.703: ICMP blazon=8, code=0 Jan 20 xvi:05:32.731: IP: southward=12.0.0.2 (Serial0), d=12.0.0.i (Serial0), len 56, rcvd three Jan 20 16:05:32.735: ICMP blazon=3, code=1 January 20 16:05:32.739: IP: southward=12.0.0.1 (local), d=34.0.0.four (Serial0), len 100, sending Jan 20 16:05:32.743: ICMP type=8, code=0
Now let united states examine what is wrong on Router2:
Router2#debug ip package detail IP packet debugging is on (detailed) Router2# Jan 20 xvi:10:41.907: IP: due south=12.0.0.one (Serial1), d=34.0.0.four, len 100, unroutable Jan twenty 16:10:41.911: ICMP type=8, lawmaking=0 January 20 sixteen:10:41.915: IP: s=12.0.0.2 (local), d=12.0.0.i (Serial1), len 56, sending Jan 20 16:x:41.919: ICMP type=three, code=1 Jan twenty 16:10:41.947: IP: s=12.0.0.1 (Serial1), d=34.0.0.4, len 100, unroutable Jan 20 xvi:ten:41.951: ICMP type=viii, code=0 Jan twenty 16:x:43.943: IP: s=12.0.0.i (Serial1), d=34.0.0.4, len 100, unroutable Jan twenty 16:10:43.947: ICMP type=8, lawmaking=0 Jan 20 16:10:43.951: IP: south=12.0.0.2 (local), d=12.0.0.one (Serial1), len 56, sending January 20 16:10:43.955: ICMP blazon=iii, code=one January 20 xvi:ten:43.983: IP: south=12.0.0.1 (Serial1), d=34.0.0.4, len 100, unroutable January 20 16:10:43.987: ICMP type=8, lawmaking=0 Jan 20 xvi:x:45.979: IP: southward=12.0.0.1 (Serial1), d=34.0.0.four, len 100, unroutable January 20 sixteen:x:45.983: ICMP blazon=eight, code=0 Jan twenty 16:10:45.987: IP: s=12.0.0.2 (local), d=12.0.0.1 (Serial1), len 56, sending Jan 20 16:x:45.991: ICMP type=iii, code=1
Router1 is correctly sending its packets to Router2, but Router2 doesn't know how to access address 34.0.0.iv. Router2 sends back an "unreachable ICMP" message to Router1.
Now permit'due south enable Routing Information Protocol (RIP) on Router2 and Router3:
Router2# router rip network 12.0.0.0 network 23.0.0.0 Router3# router rip network 23.0.0.0 network 34.0.0.0
Now we have:
Router1#debug ip bundle IP parcel debugging is on Router1#ping 34.0.0.4 Blazon escape sequence to abort. Sending 5, 100-byte ICMP Echos to 34.0.0.4, timeout is 2 seconds: Jan 20 16:16:thirteen.367: IP: due south=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100, sending. Jan 20 16:16:15.363: IP: due south=12.0.0.one (local), d=34.0.0.iv (Serial0), len 100, sending. Jan 20 16:16:17.363: IP: s=12.0.0.ane (local), d=34.0.0.4 (Serial0), len 100, sending. January 20 16:sixteen:19.363: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100, sending. Jan 20 sixteen:xvi:21.363: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100, sending. Success rate is 0 percent (0/v)
This is slightly amend. Router1 is sending packets to Router4, simply is not getting whatsoever answer from Router4.
Let us run across what the trouble could be on Router4:
Router4#debug ip packet IP packet debugging is on Router4# Jan twenty xvi:18:45.903: IP: due south=12.0.0.ane (Serial0), d=34.0.0.iv (Serial0), len 100, rcvd 3 Jan 20 sixteen:18:45.911: IP: due south=34.0.0.4 (local), d=12.0.0.1, len 100, unroutable January 20 16:xviii:47.903: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3 Jan 20 16:xviii:47.907: IP: south=34.0.0.four (local), d=12.0.0.1, len 100, unroutable Jan 20 sixteen:18:49.903: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3 Jan twenty 16:18:49.907: IP: due south=34.0.0.iv (local), d=12.0.0.1, len 100, unroutable Jan 20 sixteen:18:51.903: IP: s=12.0.0.i (Serial0), d=34.0.0.four (Serial0), len 100, rcvd iii Jan 20 16:18:51.907: IP: s=34.0.0.four (local), d=12.0.0.1, len 100, unroutable Jan 20 sixteen:18:53.903: IP: s=12.0.0.one (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd iii Jan 20 16:18:53.907: IP: s=34.0.0.4 (local), d=12.0.0.i, len 100, unroutable
Router4 receives the ICMP packets, and tries to answer to 12.0.0.ane, but because it does not have a route to this network, information technology simply fails.
Allow the states add a static road to Router4:
Router4(config)#ip route 0.0.0.0 0.0.0.0 Serial0
Now it works perfectly, and both sides can admission each other:
Router1#ping 34.0.0.4 Type escape sequence to abort. Sending v, 100-byte ICMP Echos to 34.0.0.4, timeout is 2 seconds: !!!!! Success rate is 100 percent (five/5), circular-trip min/avg/max = 32/35/36 ms
Interface Down
This is a situation where the interface stops working. In the instance below, we endeavor to ping Router4 from Router1:
Router1#ping 34.0.0.iv Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 34.0.0.4, timeout is 2 seconds: U.U.U Success charge per unit is 0 per centum (0/5)
Since the routing is fine, we volition do the troubleshooting step-past-step. Showtime, let us try to ping Router2:
Router1#ping 12.0.0.2 Blazon escape sequence to abort. Sending five, 100-byte ICMP Echos to 12.0.0.ii, timeout is ii seconds: !!!!! Success charge per unit is 100 percentage (5/5), round-trip min/avg/max = 4/4/4 ms
From the in a higher place, we meet that the problem lies between Router2 and Router3. One possibility is that the series interface on Router3 has been shut down:
Router3#testify ip interface brief Serial0 34.0.0.3 Yep manual up up Serial1 23.0.0.3 YES manual administratively down down
This is quite simple to fix:
Router3#configure final Enter configuration commands, ane per line. End with CNTL/Z. Router3(config)#interface s1 Router3(config-if)#no shutdown Router3(config-if)# January twenty 16:xx:53.900: %LINK-3-UPDOWN: Interface Serial1, changed state to upwardly Jan 20 16:twenty:53.910: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, inverse land to upwardly
Access-list Command
In this scenario, nosotros want to allow only telnet traffic to enter Router4 through interface Serial0 .
Router4(config)# access-list 100 allow tcp any any eq telnet Router4(config)#interface s0 Router4(config-if)#ip access-group 100 in Router1#configure concluding Enter configuration commands, ane per line. End with CNTL/Z. Router1(config)#access-list 100 allow ip host 12.0.0.one host 34.0.0.4 Router1(config)#access-listing 100 let ip host 34.0.0.4 host 12.0.0.1 Router1(config)#cease Router1#debug ip parcel 100 IP packet debugging is on Router1#debug ip icmp ICMP package debugging is on
Refer to the Employ the Debug Command section for using access lists with debug commands.
When we now effort to ping Router4, we have the following:
Router1#ping 34.0.0.four Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 34.0.0.4, timeout is ii seconds: U.U.U Success rate is 0 percent (0/5) Jan 20 16:34:49.207: IP: s=12.0.0.ane (local), d=34.0.0.four (Serial0), len 100, sending Jan 20 16:34:49.287: IP: s=34.0.0.four (Serial0), d=12.0.0.1 (Serial0), len 56, rcvd 3 Jan xx 16:34:49.291: ICMP: dst (12.0.0.1) administratively prohibited unreachable rcv from 34.0.0.4 Jan xx sixteen:34:49.295: IP: s=12.0.0.one (local), d=34.0.0.iv (Serial0), len 100, sending January xx sixteen:34:51.295: IP: s=12.0.0.i (local), d=34.0.0.four (Serial0), len 100, sending Jan 20 xvi:34:51.367: IP: s=34.0.0.four (Serial0), d=12.0.0.ane (Serial0), len 56, rcvd iii Jan 20 xvi:34:51.371: ICMP: dst (12.0.0.one) administratively prohibited unreachable rcv from 34.0.0.4 Jan 20 16:34:51.379: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100, sending
At the cease of an admission-list command, nosotros ever have an implicit "deny all". This ways that the ICMP packets that are entering the Serial 0 interface on Router4 are denied, and Router 4 sends an ICMP "administratively prohibited unreachable" message to the source of the original packet every bit shown in the debug message. The solution is to add the following line in the access-list command:
Router4(config)#access-listing 100 permit icmp any any
Address Resolution Protocol (ARP) Consequence
Here is a scenario with an Ethernet connectedness:
Router4#ping 100.0.0.5 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 100.0.0.5, timeout is 2 seconds: Jan 20 17:04:05.167: IP: s=100.0.0.4 (local), d=100.0.0.5 (Ethernet0), len 100, sending Jan 20 17:04:05.171: IP: s=100.0.0.4 (local), d=100.0.0.5 (Ethernet0), len 100, encapsulation failed. January 20 17:04:07.167: IP: southward=100.0.0.four (local), d=100.0.0.5 (Ethernet0), len 100, sending Jan 20 17:04:07.171: IP: south=100.0.0.4 (local), d=100.0.0.5 (Ethernet0), len 100, encapsulation failed. Jan 20 17:04:09.175: IP: s=100.0.0.4 (local), d=100.0.0.v (Ethernet0), len 100, sending Jan 20 17:04:09.183: IP: s=100.0.0.4 (local), d=100.0.0.5 (Ethernet0), len 100, encapsulation failed. Jan 20 17:04:eleven.175: IP: s=100.0.0.iv (local), d=100.0.0.5 (Ethernet0), len 100, sending Jan 20 17:04:11.179: IP: s=100.0.0.four (local), d=100.0.0.5 (Ethernet0), len 100, encapsulation failed. Jan 20 17:04:13.175: IP: s=100.0.0.4 (local), d=100.0.0.5 (Ethernet0), len 100, sending January 20 17:04:13.179: IP: s=100.0.0.four (local), d=100.0.0.v (Ethernet0), len 100, encapsulation failed. Success charge per unit is 0 percent (0/5) Router4#
In this example, the ping is non working due to "encapsulation failed". This means that the router knows on which interface it has to send the packet, simply does not know how to do it. In this example, you need to empathize how Address Resolution Protocol (ARP) works. Meet Configuring Accost Resolution Methods for a detailed caption.
Basically, ARP is a protocol used to map the Layer 2 address (MAC address) to a Layer three address (IP address). You can cheque this mapping using the show arp command:
Router4#testify arp Protocol Address Historic period (min) Hardware Addr Type Interface Internet 100.0.0.iv - 0000.0c5d.7a0d ARPA Ethernet0 Internet 100.0.0.one 10 0060.5cf4.a955 ARPA Ethernet0
Return to the "encapsulation failed" problem. We get a better idea of the trouble using this debug command:
Router4#debug arp ARP packet debugging is on Router4#ping 100.0.0.5 Type escape sequence to arrest. Sending five, 100-byte ICMP Echos to 100.0.0.5, timeout is ii seconds: January twenty 17:19:43.843: IP ARP: creating incomplete entry for IP accost: 100.0.0.5 interface Ethernet0 January twenty 17:19:43.847: IP ARP: sent req src 100.0.0.4 0000.0c5d.7a0d, dst 100.0.0.v 0000.0000.0000 Ethernet0. January 20 17:19:45.843: IP ARP: sent req src 100.0.0.4 0000.0c5d.7a0d, dst 100.0.0.5 0000.0000.0000 Ethernet0. Jan 20 17:19:47.843: IP ARP: sent req src 100.0.0.4 0000.0c5d.7a0d, dst 100.0.0.5 0000.0000.0000 Ethernet0. January 20 17:xix:49.843: IP ARP: sent req src 100.0.0.four 0000.0c5d.7a0d, dst 100.0.0.5 0000.0000.0000 Ethernet0. Jan 20 17:19:51.843: IP ARP: sent req src 100.0.0.iv 0000.0c5d.7a0d, dst 100.0.0.5 0000.0000.0000 Ethernet0. Success rate is 0 per centum (0/5)
The in a higher place output shows that Router4 is dissemination packets by sending them to the Ethernet circulate accost FFFF.FFFF.FFFF. Here, the 0000.0000.0000 means that Router4 is looking for the MAC address of the destination 100.0.0.5. Since it does not know the MAC address during the ARP request in this example, information technology uses 0000.0000.000 as a placeholder in the broadcast frames sent out of interface Ethernet 0, request which MAC address corresponds to 100.0.0.5. If we do not get an reply, the corresponding address in the show arp output is marked as incomplete:
Router4#show arp Protocol Address Age (min) Hardware Addr Type Interface Internet 100.0.0.four - 0000.0c5d.7a0d ARPA Ethernet0 Net 100.0.0.5 0 Incomplete ARPA Internet 100.0.0.one 2 0060.5cf4.a955 ARPA Ethernet0
Subsequently a predetermined catamenia, this incomplete entry is purged from the ARP tabular array. As long equally the respective MAC address is not in the ARP table, the ping fails as a issue of "encapsulation failed".
Delay
By default, if y'all do non receive an answer from the remote terminate within ii seconds, the ping fails:
Router1#ping 12.0.0.2 Type escape sequence to abort. Sending v, 100-byte ICMP Echos to 12.0.0.2, timeout is 2 seconds: ..... Success rate is 0 per centum (0/v)
On networks with a irksome link or a long delay, two seconds are non plenty. Yous can change this default using an extended ping:
Router1#ping Protocol [ip]: Target IP address: 12.0.0.two Repeat count [v]: Datagram size [100]: Timeout in seconds [two]: 30 Extended commands [n]: Sweep range of sizes [n]: Type escape sequence to arrest. Sending 5, 100-byte ICMP Echos to 12.0.0.2, timeout is xxx seconds: !!!!! Success rate is 100 per centum (5/5), round-trip min/avg/max = 1458/2390/6066 ms
In the instance to a higher place, increasing the timeout has led to a successful ping.
Note:The boilerplate circular-trip fourth dimension is more than 2 seconds.
Correct Source Address
Here is an example of a typical situation:
We add a LAN interface on Router1:
Router1(config)#interface e0 Router1(config-if)#ip address Router1(config-if)#ip address xx.0.0.1 255.255.255.0
From a station on the LAN, you can ping Router1. From Router1 you lot can ping Router2. Only from a station on the LAN, you cannot ping Router2.
From Router1, you can ping Router2 considering, by default, you lot use the IP address of the outgoing interface every bit the source address in your ICMP packet. Router2 has not information well-nigh this new LAN. If it has to reply to a packet coming from this network, information technology does not know how to handle it.
Router1#debug ip packet IP bundle debugging is on
Alert: Using the debug ip parcel command on a product router can crusade high cpu utilization. This may result in a severe performance degradation or a network outage. We recommend that you carefully read Utilise the Debug Command earlier issuing debug commands.
Router1#ping 12.0.0.two Type escape sequence to arrest. Sending v, 100-byte ICMP Echos to 12.0.0.2, timeout is two seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = iv/7/nine ms Router1# Jan 20 16:35:54.227: IP: s=12.0.0.ane (local), d=12.0.0.2 (Serial0), len 100, sending Jan 20 xvi:35:54.259: IP: s=12.0.0.2 (Serial0), d=12.0.0.1 (Serial0), len 100, rcvd three
The output case above works because the source accost of the packet we are sending is s=12.0.0.1. If nosotros want to simulate a packet coming from the LAN, we have to employ an extended ping:
Router1#ping Protocol [ip]: Target IP accost: 12.0.0.2 Repeat count [5]: Datagram size [100]: Timeout in seconds [ii]: Extended commands [north]: y Source address or interface: twenty.0.0.ane Type of service [0]: Set DF scrap in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Tape, Timestamp, Verbose[none]: Sweep range of sizes [due north]: Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 12.0.0.ii, timeout is 2 seconds: Jan 20 16:40:18.303: IP: s=20.0.0.one (local), d=12.0.0.2 (Serial0), len 100, sending. Jan 20 16:xl:20.303: IP: s=20.0.0.1 (local), d=12.0.0.two (Serial0), len 100, sending. Jan xx sixteen:40:22.303: IP: s=20.0.0.ane (local), d=12.0.0.2 (Serial0), len 100, sending. Jan 20 16:40:24.303: IP: s=xx.0.0.1 (local), d=12.0.0.ii (Serial0), len 100, sending Jan xx 16:40:26.303: IP: south=xx.0.0.1 (local), d=12.0.0.2 (Serial0), len 100, sending. Success charge per unit is 0 pct (0/5)
This time, the source accost is 20.0.0.1, and it is not working! Nosotros are sending our packets, merely we are not receiving anything. To gear up this result, we but have to add together a route to 20.0.0.0 in Router2.
The basic rule is that the pinged device should likewise know how to send the respond to the source of the ping.
Loftier Input Queue Drops
When a package enters the router, the router attempts to forward it at interrupt level. If a lucifer cannot be found in an appropriate cache table, the bundle is queued in the input queue of the incoming interface to be candy. Some packets are always processed, but with the appropriate configuration and in stable networks, the charge per unit of candy packets must never congest the input queue. If the input queue is total, the packet is dropped.
Though the interface is up and you may not ping the device due to loftier input queue drops. You can bank check the the input drops with the bear witness interface command.
Router1#testify interface Serial0/0/0 Serial0/0/0 is upwards, line protocol is up MTU 1500 bytes, BW 1984 Kbit, DLY 20000 usec, reliability 255/255, txload 69/255, rxload 43/255 Encapsulation HDLC, loopback not set Keepalive set (10 sec) Final input 00:00:02, output 00:00:00, output hang never Last clearing of "evidence interface" counters 01:28:49 Input queue: 76/75/5553/0 (size/max/drops/flushes); Total output drops: 1760 Queueing strategy: Course-based queueing Output queue: 29/1000/64/1760 (size/max total/threshold/drops) Conversations 7/129/256 (active/max active/max total) Reserved Conversations 4/4 (allocated/max allocated) Available Bandwidth 1289 kilobits/sec !--- Output supressed As seen from the output, Input Queue Driblet is high. Refer to Troubleshooting Input Queue Drops and Output Queue Drops in social club to troubleshoot Input/Output queue drops.
The Traceroute Command
The traceroute command is used to discover the routes that packets really take when traveling to their destination. The device (for example, a router or a PC) sends out a sequence of User Datagram Protocol (UDP) datagrams to an invalid port address at the remote host.
Three datagrams are sent, each with a Fourth dimension-To-Live (TTL) field value gear up to ane. The TTL value of one causes the datagram to "timeout" as presently as it hits the get-go router in the path; this router then responds with an ICMP Time Exceeded Message (TEM) indicating that the datagram has expired.
Another three UDP messages are now sent, each with the TTL value set to 2, which causes the 2d router to return ICMP TEMs. This process continues until the packets actually reach the other destination. Since these datagrams are trying to access an invalid port at the destination host, ICMP Port Unreachable Messages are returned, indicating an unreachable port; this event signals the Traceroute program that information technology is finished.
The purpose behind this is to record the source of each ICMP Time Exceeded Message to provide a trace of the path the packet took to accomplish the destination. For all the options about this command, see Trace (privileged).
Router1#traceroute 34.0.0.4 Blazon escape sequence to abort. Tracing the route to 34.0.0.4 ane 12.0.0.two 4 msec 4 msec 4 msec 2 23.0.0.three 20 msec 16 msec 16 msec three 34.0.0.4 16 msec * 16 msec Jan xx 16:42:48.611: IP: s=12.0.0.i (local), d=34.0.0.4 (Serial0), len 28, sending Jan 20 16:42:48.615: UDP src=39911, dst=33434 Jan 20 16:42:48.635: IP: s=12.0.0.ii (Serial0), d=12.0.0.1 (Serial0), len 56, rcvd 3 January 20 16:42:48.639: ICMP type=11, code=0 !--- ICMP Time Exceeded Message from Router2. Jan 20 16:42:48.643: IP: due south=12.0.0.ane (local), d=34.0.0.4 (Serial0), len 28, sending Jan 20 16:42:48.647: UDP src=34237, dst=33435 Jan twenty 16:42:48.667: IP: south=12.0.0.2 (Serial0), d=12.0.0.1 (Serial0), len 56, rcvd iii Jan xx sixteen:42:48.671: ICMP type=11, code=0 Jan 20 16:42:48.675: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28, sending Jan 20 16:42:48.679: UDP src=33420, dst=33436 Jan 20 xvi:42:48.699: IP: s=12.0.0.2 (Serial0), d=12.0.0.1 (Serial0), len 56, rcvd 3 January 20 sixteen:42:48.703: ICMP type=xi, code=0 This is the get-go sequence of packets nosotros send with a TTL=1. The first router, in this case Router2 (12.0.0.ii), drops the package, and sends dorsum to the source (12.0.0.1) a blazon=xi ICMP message. This corresponds to the Time Exceeded Message.
Jan xx 16:42:48.707: IP: south=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28, sending Jan 20 16:42:48.711: UDP src=35734, dst=33437 Jan 20 16:42:48.743: IP: s=23.0.0.iii (Serial0), d=12.0.0.1 (Serial0), len 56, rcvd iii Jan xx xvi:42:48.747: ICMP type=xi, code=0 !--- ICMP Time Exceeded Message from Router3. Jan 20 16:42:48.751: IP: southward=12.0.0.one (local), d=34.0.0.four (Serial0), len 28, sending Jan 20 16:42:48.755: UDP src=36753, dst=33438 Jan twenty 16:42:48.787: IP: due south=23.0.0.three (Serial0), d=12.0.0.i (Serial0), len 56, rcvd three Jan 20 xvi:42:48.791: ICMP type=11, code=0 Jan 20 16:42:48.795: IP: due south=12.0.0.i (local), d=34.0.0.iv (Serial0), len 28, sending Jan 20 16:42:48.799: UDP src=36561, dst=33439 Jan 20 16:42:48.827: IP: s=23.0.0.3 (Serial0), d=12.0.0.1 (Serial0), len 56, rcvd 3 January 20 16:42:48.831: ICMP blazon=xi, lawmaking=0 The same process occurs for Router3 (23.0.0.3) with a TTL=2:
Jan 20 16:42:48.839: IP: s=12.0.0.1 (local), d=34.0.0.iv (Serial0), len 28, sending Jan 20 16:42:48.843: UDP src=34327, dst=33440 Jan 20 xvi:42:48.887: IP: s=34.0.0.4 (Serial0), d=12.0.0.ane (Serial0), len 56, rcvd iii Jan 20 sixteen:42:48.891: ICMP blazon=3, code=3 !--- Port Unreachable message from Router4. January 20 16:42:48.895: IP: southward=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28, sending Jan twenty sixteen:42:48.899: UDP src=37534, dst=33441 Jan 20 16:42:51.895: IP: southward=12.0.0.ane (local), d=34.0.0.4 (Serial0), len 28, sending January 20 16:42:51.899: UDP src=37181, dst=33442 January 20 16:42:51.943: IP: southward=34.0.0.4 (Serial0), d=12.0.0.1 (Serial0), len 56, rcvd iii January 20 16:42:51.947: ICMP blazon=three, code=3 With a TTL=three, we finally achieve Router4. This time, since the port is not valid, Router4 sends back to Router1 an ICMP bulletin with type=three, a Destination Unreachable Bulletin, and code=3 significant port unreachable.
The table beneath lists the characters that can appear in the traceroute control output.
IP Traceroute Text Characters
| Character | Description |
|---|---|
| nn msec | For each node, the round-trip time in milliseconds for the specified number of probes |
| * | The probe timed out |
| A | Administratively prohibited (instance, admission-list) |
| Q | Source quench (destination too busy) |
| I | User interrupted test |
| U | Port unreachable |
| H | Host unreachable |
| N | Network unreachable |
| P | Protocol Unreachable |
| T | Timeout |
| ? | Unknown packet type |
Functioning
Using the ping and traceroute commands, we obtain the round-trip time (RTT). This is the time required to send an repeat parcel, and get an answer back. This can be useful to have a rough idea of the delay on the link. However, these figures are not precise enough to exist used for performance evaluation.
When a packet destination is the router itself, this packet has to be process-switched. The processor has to handle the data from this packet, and send an answer back. This is not the master goal of a router. By definition, a router is built to route packets. Answering a ping is offered as a best-attempt service.
To illustrate this, here is an example of a ping from Router1 to Router2:
Router1#ping 12.0.0.2 Type escape sequence to abort. Sending five, 100-byte ICMP Echos to 12.0.0.2, timeout is two seconds: !!!!! Success rate is 100 percent (5/5), circular-trip min/avg/max = iv/four/four ms
The RTT is approximately four milliseconds. After y'all enable some process-intensive features on Router2, try to ping Router2 from Router1.
Router1#ping 12.0.0.2 Blazon escape sequence to arrest. Sending 5, 100-byte ICMP Echos to 12.0.0.2, timeout is 2 seconds: !!!!! Success charge per unit is 100 per centum (5/five), round-trip min/avg/max = 24/25/28 ms
The RTT has dramatically increased here. Router2 is quite decorated, and answering the ping is not its main priority.
A better way to test router performance is with traffic going through the router:
The traffic is and then fast-switched, and is handled by the router with the highest priority. To illustrate this, allow us go back to our basic network:
Let us ping Router3 from Router1:
Router1#ping 23.0.0.three Blazon escape sequence to abort. Sending five, 100-byte ICMP Echos to 23.0.0.3, timeout is 2 seconds: !!!!! Success rate is 100 per centum (5/5), circular-trip min/avg/max = 32/32/32 ms
The traffic is going through Router2, and is now fast-switched.
Now let us enable the process-intensive feature on Router2:
Router1#ping 23.0.0.3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 23.0.0.3, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/v), round-trip min/avg/max = 32/32/36 ms
There is well-nigh no difference. This is because, on Router2, the packets are now handled at interrupt level.
Utilize the Debug Command
Earlier issuing debug commands, please see Important Information on Debug Commands.
The different debug commands we have used so far gives united states of america an insight into what happens when we use a ping or traceroute control. They can also be useful for troubleshooting. However, in a production surround, debugs should be used with caution. If your CPU is not powerful, or if you lot have a lot of procedure-switched packets, they can easily stall your device. In that location are a couple of ways to minimize the impact of the debug command on the router. Ane way is to use access lists to narrow downwards the specific traffic that yous want to monitor. Here is an case:
Router4#debug ip bundle ? <one-199> Access list <1300-2699> Access listing (expanded range) detail Print more debugging particular Router4#configure terminal Router4(config)#access-listing 150 permit ip host 12.0.0.1 host 34.0.0.4 Router4(config)#^Z Router4#debug ip bundle 150 IP packet debugging is on for admission list 150 Router4#prove debug Generic IP: IP packet debugging is on for admission listing 150 Router4#evidence access-list Extended IP admission list 150 allow ip host 12.0.0.ane host 34.0.0.4 (v matches)
With this configuration, Router4 only prints the debug bulletin that matches the access-list 150. A ping coming from Router1 causes the post-obit message to exist displayed:
Router4# Jan 20 16:51:16.911: IP: south=12.0.0.one (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd three Jan xx 16:51:17.003: IP: s=12.0.0.one (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3 Jan twenty sixteen:51:17.095: IP: s=12.0.0.one (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3 January 20 16:51:17.187: IP: south=12.0.0.1 (Serial0), d=34.0.0.iv (Serial0), len 100, rcvd three Jan 20 16:51:17.279: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd iii
We no longer see the answer from Router4 because, these packets do non match the access-listing. To see them, we should add together the following:
Router4(config)#admission-list 150 permit ip host 12.0.0.one host 34.0.0.4 Router4(config)#access-list 150 let ip host 34.0.0.iv host 12.0.0.1
Nosotros and then have:
Jan 20 16:53:sixteen.527: IP: due south=12.0.0.i (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3 Jan 20 16:53:16.531: IP: southward=34.0.0.4 (local), d=12.0.0.1 (Serial0), len 100, sending January twenty 16:53:16.627: IP: s=12.0.0.i (Serial0), d=34.0.0.iv (Serial0), len 100, rcvd three Jan 20 xvi:53:16.635: IP: south=34.0.0.4 (local), d=12.0.0.1 (Serial0), len 100, sending January 20 16:53:16.727: IP: south=12.0.0.i (Serial0), d=34.0.0.iv (Serial0), len 100, rcvd iii Jan 20 16:53:16.731: IP: s=34.0.0.4 (local), d=12.0.0.1 (Serial0), len 100, sending Jan twenty xvi:53:16.823: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd three Jan 20 16:53:sixteen.827: IP: s=34.0.0.4 (local), d=12.0.0.ane (Serial0), len 100, sending Jan 20 16:53:16.919: IP: s=12.0.0.1 (Serial0), d=34.0.0.iv (Serial0), len 100, rcvd three Jan 20 xvi:53:16.923: IP: s=34.0.0.four (local), d=12.0.0.1 (Serial0), len 100, sending
Another way of minimizing the impact of the debug command is to buffer the debug messages and testify them using the show log command one time the debug has been turned off:
Router4#configure terminal Router4(config)#no logging console Router4(config)#logging buffered 5000 Router4(config)#^Z Router4#debug ip packet IP parcel debugging is on Router4#ping 12.0.0.one Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 12.0.0.i, timeout is 2 seconds: !!!!! Success charge per unit is 100 percent (five/5), round-trip min/avg/max = 36/36/37 ms Router4#undebug all All possible debugging has been turned off Router4#show log Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns) Panel logging: disabled Monitor logging: level debugging, 0 messages logged Buffer logging: level debugging, 61 messages logged Trap logging: level informational, 59 message lines logged Log Buffer (5000 bytes): Jan xx xvi:55:46.587: IP: southward=34.0.0.four (local), d=12.0.0.one (Serial0), len 100, sending Jan 20 16:55:46.679: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
As you can see, the ping and traceroute commands are very helpful utilities that you can use to troubleshoot network admission problems. They are also very piece of cake to use. As these two commands are the most widely used commands by network engineers, understanding them is very crucial for troubleshooting network connectivity.
Related Information
- Using the Extended ping and Extended traceroute Commands
- Technical Support - Cisco Systems
Chapter 6 Reading Cisco 1 Reading Organizer Ansewr
Source: https://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/ios-software-releases-121-mainline/12778-ping-traceroute.html