Isolating IP Routing Problems Related to Hosts
Steps for testing the host’s connectivity to the first router:
Step 1: Check the host’s ability to send packets inside its own subnet. Either ping the host’s default gateway IP address from the host, or ping the host’s IP address from the default gateway. If the ping fails, do the following:
a. Ensure that the router’s interface used at the default gateway is in an “up and up” state.
b. Check the source host’s IP address and mask setting as compared to the router’s interface used as the default gateway. Ensure that both agree as to the subnet number ans mask, and therefore agree to the range of valid addresses in the subnet.
c. If the router uses VLAN trunking, solve any trunk configuration issues, ensuring that the router is configured to support the same VLAN in which the host resides.
d. If the other steps do not lead to a solution, investigate Layer 1/2 problems with the LAN.
Step 2: Verify the default gateway setting on the host by pinging one of the default router’s other interface IP addresses. Or, from the default router, use an extended ping of the host’s IP address with a source address from another of the router’s interfaces.
Isolating IP Routing Problems Related to Routers
Step 3: Test connectivity to the destination host by using the extended traceroute command on the host’s default gateway, using the router’s interface attached to the source host for the source IP address of the packets. If the command successfully completes:
a. No routing problems exist in the forward route or reverse route directions.
b. If the end-user traffic still does not work (even though the traceroute worked), troubleshoot any ACLs on each interface on each router in the route, in both directions.
Step 4: If the traceroute command in Step 3 does not complete, test the forward route as follows:
a. telnet to the last traced router (the last router listed in the traceroute command).
b. Find that router’s route that matches the destination IP address that was used in the original traceroute command (show ip route, show ip route ip-address).
c. If no matching route is found, investigate why the expected route is missing. Typically it’s either a routing protocol issue or a static route misconfiguration. It could also be related to a missing connected route.
d. If a matching route is found, and the route is a default route, confirm that it will be used based on the setting for the ip classless/no ip classless commands.
e. If a matching route is found, ping the next-hop IP address listed in the route. Or, if the route is a connected route, ping the true destination IP address.
* If the ping fails, investigate Layer 2 problems between this router and the IP address that was pinged, and investigate possible ACL problems.
* If the ping works, investigate ACL issues.
f. If a matching route is found, and no other problems are found, confirm that the route is not errantly pointing in the wrong direction.
Step 5: If Step 4 does not identify a problem in the forward route, test the reverse route:
a. If the forward route on the last traced router refers to another router as the next-hop router, repeat the substeps of Step 3 from the next-hop router. Analyze the reverse route – the route to reach the source IP address used by the failed traceroute command.
b. If the forward route on the last traced router refers to a connected subnet, check the destination host’s IP settings. In particular, confirm the settings for the IP address, mask, and default gateway.
Troubleshooting Tools and Tips
Host Routing Tools and Perspectives
Host Troubleshooting Tips
Symptom: Some hosts in a subnet can communicate with hosts in other subnets, but others cannot. Common Root Cause: This may be caused by the default gateway using a different mask than the hosts. This may result in the router’s connected route not including some of the hosts on the LAN.
For the exams, most host communication problems are caused by just a handful of issues:
Step 1: Check all hosts and routers that should be in the same subnet to ensure that they all use the same mask and that their addresses are indeed all in the same subnet.
Step 2: Compare each host’s default gateway setting with the router’s configuration to ensure that it is the right IP address.
Step 3: If the first two items are correct, next look at Layer 1/2 issues.
LAN Switch IP Support
Switches act like hosts when it comes to IP configuration. As compared to a PC, a Cisco switch does not use a NIC. Instead, it uses an internal virtual interface associated with VLAN 1 that essentially gives the switch itself an interface in VLAN 1.
IP Address configuration for a switch:
Step 1: Enter VLAN 1 configuration mode using the interface vlan 1 global configuration command (from any config mode).
Step 2: Assign an IP address and mask using the ip address ip-address mask interface subcommand.
Step 3: Enable the VLAN 1 interface using the no shutdown interface subcommand.
Step 4: Add the ip default-gateway ip-address global command to configure the default gateway.
Cisco generally suggests you avoid putting end-user devices into VLAN 1, but the switch IP address may well be configured in VLAN 1. To support the ability for the switch to send and receive packets to hosts in different subnets, the router’s trunking configuration must include configuration for VLAN 1 as well as the end-user VLANs (If you use VLAN 1).
For router LAN interfaces connected to a LAN switch, the main items to check on routers are that the router and switch match each other’s duplex and speed settings, and that if trunking is configured, both the router and switch have been manually configured for trunking, because routers do not dynamically negotiate LAN trunking.
Recognizing When VLSM IS Used
An internetwork uses VLSM when multiple subnet masks are used for different subnets of a single classful network. Only classless routing protocols can support VLSM. Classful routing protocols cannot. (RIP-1, and IGRP). Routing does not require any special configuration to support VLSM, it is a feature of the routing protocol.
Configuring Overlapping VLSM Subnets
IP subnetting rules require that the address ranges in the subnets used in an internetwork should not overlap. IOS can recognize when a new ip address command creates an overlapping subnet, but only in some cases. General statements about when overlaps can/cannot be configured:
* Preventing the overlap: IOS detects the overlap when the ip address command implies an overlap with another ip address command on the same router. If the interface being configured is up/up, IOS rejects the ip address command. If not, IOS accepts the ip address command, but IOS will never bring up the interface.
* Allowing the overlap: IOS cannot detect an overlap when an ip address command overlaps with an ip address command on another router.
For the exams, keep in mind that overlapped subnets can be configured if the subnets do not connect to the same router. So, if a question asks you to pick a new subnet number and configure an interface to be in that subnet, the router’s acceptance of your ip address command does not necessarily tell you that you did the math correctly.
VLSM Troubleshooting Summary
The following list summarizes the key troubleshooting points to consider when you’re troubleshooting potential VLSM problems on the exams:
* Pay close attention to whether the design really uses VLSM. If it does, note whether a classless routing protocol is used.
* Be aware that overlapping subnets can indeed be configured.
* The outward problem symptoms may be that some hosts in a subnet work well, but others cannot send packets outside the local subnet.
* Use the traceroute command to look for routes that direct packets to the wrong part of the network. This could be a result of the overlapped subnets.
* On the exams, you might see a question you think is related to VLSM and IP addresses. In that case, the best plan of attack may well be to analyze the math for each subnet and ensure that no overlaps exist, rather than troubleshooting using ping and traceroute.
Discontiguous Networks and Autosummary
For the exam, keep the concept of discontiguous networks in mind for normal working cases and for cases in which redundant links fail. A discontiguous network would be one in which 10.0.0.0/8 is advertised on both sides of one router, meaning it doesn’t know which way to route the data. The solution is to use a classless routing protocol with autosummary disabled.
Access List Troubleshooting Tips
One of the major difficulties in troubleshooting ACLs is that the traditional troubleshooting tools such as ping and traceroute do not send packets that look like the packets matched by the variety of fields in extended ACLs.
Summarization of tips for attacking ACL-related problems:
Step 1: Determine on which interfaces ACLs are enabled, and in which direction (show running-config, show ip interfaces).
Step 2: Determine which ACL statements are matched by test packets (show access-lists, show ip access-lists).
Step 3: Analyze the ACLs to predict which packets should match the ACL, focusing on the following points:
a. Remember that the ACL uses first-match logic.
b. Consider using the (possibly) faster math, which converts ACL address/wildcard mask pairs into address/subnet mask pairs that allow the use of the same math as subnetting.
c. Note the direction of the packet in relation to the server (going to the server, coming from the server). Make sure that the packets have particular values as either the source IP address and port, or as the destination IP address and port, when processed by the ACL enabled for a particular direction (in or out)
d. Remember that the tcp and udp keywords must be used if the command needs to check the port numbers.
e. Note that ICMP packets do not use UDP or TCP. ICMP is considered to be another protocol matchable with the icmp keyword (instead of ip, tcp, and udp).
f. Instead of using the implicit deny any at the end of each ACL, use an explicit configuration command to deny all traffic at the end of the ACL so that the show command counters increment when that action is taken.
If a problem in forwarding IP packets is occurring, and existing ACLs may be impacting the problem, the first problem isolation step is to find the location and direction of the ACLs. The fastest way to do this is to look at the output of the show running-config command and to look for ip access-group commands under each interface. However, in some cases, enable mode access may not be allowed, and show commands are required. The only way to find the interfaces and direction for any IP ACLs is the show ip interfaces command. The command output lists whether an ACL is enabled, in both directions, and which ACL it is.