Chapter 23 - IPv4 Troubleshooting Tools

Ping and extended ping from a router is fine and dandy, but it can't quite mimic a ping command created on the host itself because the routers cannot send packets with the host's IP address. As a result, neither the standard nor extended (ping) command can test for some kinds of problem. What four primary issues would this entail?

1. ACLs that discard packets based on host A's IP address, while that same ACL permits packets matched on the router's IP address. 2. LAN switch port security issues that filter A's packets (based on A's MAC address). 3. IP routes on routers that happen to match host A's 172.16.1.51 address, with different routes that match R1's 172.16.1.1 address. 4. Problems with host A's default gateway setting.

A successful (ping) to the IP address on the other end of a serial link between two routers confirms what five facts?

1. Both router's serial interfaces are in an up/up state. 2. The Layer-1 and Layer-2 features of the link work. 3. The routers believe that the neighboring router's IP address is in the same subnet. 4. Inbound ACL's on both routers do not filter the incoming packets, respectively. 5. The remote router is configured with the expected IP address.

Ping doesn't just verify IP connectivity. It can also verify hostname resolution via DNS. Describe or summarize a basic example on how ping and DNS would work together, both before having a mapping, and after having a mapping.

1. Host A will issue (ping) to Host B. 2. Host A checks to see if Host B's hostname (www.cisco.com for example) already exists in its DNS cache. 3. If the DNS hostname has already resolved in its cache, great. 4. If not, Host A first asks DNS to supply (resolve) the name into its matching IP address. 5. Only then will Host A send a packet to Host B's IP address.

The failure of ping, even with two devices on the same subnet, can point to a variety of problems. What four common issues would this entail?

1. IP addressing problem - The host could be statically configured with the wrong IP address. 2. DHCP problems - If you are using DHCP, many problems could exist. The host could be using a different IP address, the DHCP configuration could be wrong, the routers may be missing the DHCP relay configuration and so the host would never received its IPv4 address lease, and so on. 3. VLAN trunking problems - The router could be configured for an 802.1q trunk, when the switch is not (or vice-versa). 4. LAN problems - Port security, VLAN misconfiguration or omission, Layer-1 issue, etc.

If the ping works, it confirms what four things, and rules out what potential issues?

1. The host with address X.X.X.X replied. 2. The LAN can pass unicast frames from the router to the host and vice-versa. 3. You can reasonably assume that the switches learned the MAC addresses of the router and the host, adding those to the MAC address tables. 4. The host and router completed the ARP process (Layer-3 to Layer-2 mapping), and list each other in their respective ARP tables.

In particular, what four things need to be working outside of the standard configurations such as having the IP address configured, the default gateway set, a static or dynamic route being learned, etc.?

1. The switch interfaces on the LAN has to be in a connected (up/up) state. 2. Port security does not filter frames sent by the router, or host. 3. STP has placed the right ports into a forwarding state. 4. Confirming there are no IP ACL's filtering ICMP messages.

Which icon after issuing the ping command represents a failure, and a success?

A ..... (period) represents a failure for an ICMP echo request/reply. A !!!!! (exclamation point) represents a success for an ICMP echo request/reply.

Ping and Traceroute both test what plane?

Data plane

A standard ping often does not test the reverse route. For example, let's say you're verifying communication from PCA to PCB, both of which that live on different subnets. A standard ping (on the router) will have the ICMP echo request sourced from the routers outgoing interface's IP address, and the ICMP echo reply will come back from the destination host. What other type of ping command would allow you to test the reverse route to PCA's subnet?

Extended ping You can use an extended ping to test the route back to PCA's subnet. To do so, you would use PCA's default gateway as the source IP address for the ICMP echo request. In layman's terms, you're using the router's LAN IP address from within PCA's subnet.

If you issue the ping command from R1 (your router), where is the ICMP echo request sourced, and ICMP echo reply sourced from?

ICMP echo request - This is generated from the outgoing interface of your router leading towards the destination host. ICMP echo reply - This message is generated from the destination host.

ICMP is comprised primarily of what two functions?

ICMP echo requests and ICMP replies

ICMP is encapsulated within what header?

ICMP headers are encapsulated inside of IP headers, and IP headers are encapsulated within a Ethernet header and trailer.

Let's say you have the following topology: PCA - R1 - R2 - R3 - PCB Why would Telnet or SSH fail from PCA to R2 or R3, but succeed from R1 to R2, and R2 to R3?

If Telnet or SSH from PCA to R2 or R3 fails, but succeed per-hop starting with R1 to R2, and R2 to R3, that could be indicative of a routing issue. For example, let's there is a routing misconfiguration R2. This may (or will) stop R1, R2 and R3 from sharing their routes, and installing them in the routing table. Hence why Telnet or SSH would fail from PCA to R2 or R3. However, if you Telnet or SSH into R1 via its default gateway, and then do likewise per-hop (to R2 and then from R2 to R3), this works because R1 uses the outgoing interface IP address used to send packets to its next-hop. Because of each of these (telnet) or (ssh) commands connect to an IP address in a directly connected subnet, the routing protocol could be completely misconfigured, and you could still Telnet or SSH to each successive device to troubleshoot and resolve the issue.

A standard (ping) does not test a host's default gateway settings. However, an extended ping can. Therefore, both tests are useful for problem isolation. Why is that, and how can they be used in conjunction?

If a standard ping to a local host works... But an extended ping of that same host fails... Then the problem likely relates back to the host's default gateway settings. The reason why, even if the host doesn't have its default gateway properly configured, ICMP echo replies would still work. Instead, if you use an extended ping, set the source IP address to the outgoing WAN link's interface. This will force the host's ICMP echo reply to flow to an address in another subnet. This makes that host use its default gateway settings. Again, the key difference is that communicating with a device in your local subnet will use Layer-2 switching logic, whereas if you have to communicate to an address outside of your subnet, it needs to be routed to your default gateway and then processes at the router.

A issue with issuing the ping command from a host computer is that perhaps a CSR or yourself do not have access to their device, or they aren't available. Therefore, what would be the next best step towards troubleshooting that computer's TCP/IP settings?

If you can't gain access to the end-users computer to issue ping from CMD, the next best bet would be to connect to their default gateway's (the closest routers) IP address, and issue a ping to both that host and to the destination device to confirm if there is a routing issue from Point A to Point B.

Why is the (traceroute) command useful?

Let's say (ping) fails from Point A to Point B. Rather than using the (ping) command from numerous interfaces, wasting time. Instead, you can use the (traceroute) command to systematically pinpoint routing problems by showing how far a packet goes through an IP network before being discard.

PCA - SW1 - R1 - R2 - SW2 - PCB Why might a extended ping be useful when verifying connectivity between PCA and PCB (specifically from the routers)?

Let's say you're on R1 testing connectivity between PCA and PCB. If you issue the standard ping command, it'll set the ICMP echo request to its outgoing interface's IP address, with the destination being PCB. The problem is, this only verifies connectivity between R1 and PCB, and vice-versa. Simply put, you're verifying that R1 has a static or dynamically learned route to PCB's subnet. However, it doesn't prove that PCB can communicate back (reverse route) to PCA's subnet. Therefore, with an extended ping, you can change the source IP address (ICMP echo request) to PCA's default gateway, aka R1's LAN interface IP address. This is the best way of confirming connectivity back to PCA's subnet, without having direct access to PCA to use its command line.

How do routers mitigate routing loops?

Routers mitigate routing loops in part by discarding looping IP packets. To do so, the IPv4 header holds a field called Time To Live (TTL). The original host that creates the packet sets an initial TTL value. Then, each router that forwards the packet decrements the TTL value by 1. When a router decrements the TTL to 0, the router perceives the packet is looping, and the router discards the packet. The router also notifies the host that sent the discarded packet by sending an ICMP TTL Exceeded message.

What two other tools could you use to troubleshoot your network outside of ping or traceroute?

Telnet and SSH

What is traceroute?

The (traceroute) command gathers information by generating packets that trigger error messages from routers. These messages identify the routers, letting the (traceroute) command list the routers's IP addresses in the output of the command. That error message is the ICMP Time-to-Live Exceeded (TTL Exceeded) message, originally meant to notify hosts when a packet had been looping around a network.

What's the difference between a host's (tracert) and a router's (traceroute) command? Not just the name...

The host's (tracert) command usually creates ICMP echo requests. The router's (traceroute) command instead creates IP packets with a UDP header. This may seem trivial, but in reality, an ACL may actually filter the traffic from a host's (tracert) messages (ICMP) but not the router's (traceroute) command (UDP), or vice-versa.

Why might a router or firewall be an issue for (traceroute)?

The traceroute command may not finish even though the network has no problems. Routers and firewalls may filter the messages sent by the (traceroute) command, or the TTL Exceeded messages, which would prevent the display of portions of a path, or all of the path.

True or False? You don't have to use the (exit) or (quit) command to re-log back in to a switch or router.

True. Instead of using the (exit) or (quit) commands to end your Telnet or SSH session, and re-login back into a switch or router. IOS supports a mechanism to use hotkeys to move between multiple Telnet or SSH sessions from the CLI. This allows you to move between sessions smoothly, and quickly.

True or False? ACL's do not filter packets created on that same router?

True. They will only filter packets that are either received on an incoming interface, or forwarded out an outgoing interface.

A problem with routing is often a symptom, but not a root cause. Root causes tend to be what type of issues?

a. Interface failures b. Routing protocol issues c. Misconfiguration of various features