Troubleshoot and correct common problems associated with IP addressing and host configurations

chapter 7:Troubleshoot

    Troubleshoot and correct common problems associated with IP addressing and host configurations

  • Ability to troubleshoot IP addressing is an important skill in CCENT certification learners. We can usually fix an IP network regardless of whether we on site or at home.

    We are going to discuss “Cisco way” of troubleshooting IP addressing. Let’s use the following figure as an example of your basic IP trouble.

    Here are the four troubleshooting steps Cisco recommends:

    1. Open a Command window and ping 127.0.0.1. This is the diagnostic, or loopback, address, and if you get a successful ping, your IP stack is considered initialized. If it fails, then you have an IP stack failure and need to reinstall TCP/IP on the host.

    C:\>ping 127.0.0.1
    Pinging 127.0.0.1 with 32 bytes of data:
    Reply from 127.0.0.1: bytes=32 time<1ms ttl="128
    Reply from 127.0.0.1: bytes=32 time<1ms ttl="128
    Reply from 127.0.0.1: bytes=32 time<1ms ttl="128
    Reply from 127.0.0.1: bytes=32 time<1ms ttl="128
    Ping statistics for 127.0.0.1:
        Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
    Approximate round trip times in milli-seconds:
        Minimum = 0ms, Maximum = 0ms, Average = 0ms

    2. From the Command window, ping the IP address of the local host (we’ll assume correct configuration here, but always check the IP configuration too!). If that’s successful, your network interface card (NIC) is functioning. If it fails, there is a problem with the NIC. Success here doesn’t just mean that a cable is plugged into the NIC, only that the IP protocol stack on the host can communicate to the NIC via the LAN driver.

    C:\>ping 172.16.10.2
    Pinging 172.16.10.2 with 32 bytes of data:
    Reply from 172.16.10.2: bytes=32 time<1ms ttl="128
    Reply from 172.16.10.2: bytes=32 time<1ms ttl="128
    Reply from 172.16.10.2: bytes=32 time<1ms ttl="128
    Reply from 172.16.10.2: bytes=32 time<1ms ttl="128
    Ping statistics for 172.16.10.2:
        Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
    Approximate round trip times in milli-seconds:
        Minimum = 0ms, Maximum = 0ms, Average = 0ms

    3. From the CMD window, ping the default gateway (router). If the ping works, it means that the NIC is plugged into the network and can communicate on the local network. If it fails, you have a local physical network problem that could be anywhere from the NIC to the router.

    C:\>ping 172.16.10.1
    Pinging 172.16.10.1 with 32 bytes of data:
    Reply from 172.16.10.1: bytes=32 time<1ms ttl="128
    Reply from 172.16.10.1: bytes=32 time<1ms ttl="128
    Reply from 172.16.10.1: bytes=32 time<1ms ttl="128
    Reply from 172.16.10.1: bytes=32 time<1ms ttl="128
    Ping statistics for 172.16.10.1:
        Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
    Approximate round trip times in milli-seconds:
        Minimum = 0ms, Maximum = 0ms, Average = 0ms

    4. If steps 1 through 3 were successful, try to ping the remote server. If that works, then you know that you have IP communication between the local host and the remote server. You also know that the remote physical network is working.

    C:\>ping 172.16.20.2
    Pinging 172.16.20.2 with 32 bytes of data:
    Reply from 172.16.20.2: bytes=32 time<1ms ttl="128
    Reply from 172.16.20.2: bytes=32 time<1ms ttl="128
    Reply from 172.16.20.2: bytes=32 time<1ms ttl="128
    Reply from 172.16.20.2: bytes=32 time<1ms ttl="128
    Ping statistics for 172.16.20.2:
        Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
    Approximate round trip times in milli-seconds:
        Minimum = 0ms, Maximum = 0ms, Average = 0ms

    If the user still can’t communicate with the server after steps 1 through 4 have been completed successfully, you probably have some type of name resolution problem and need to check your Domain Name System (DNS) settings. But if the ping to the remote server fails, then you know you have some type of remote physical network problem and need to go to the server and work through steps 1 through 3 until you find the snag.

    Here are some basic commands that you can use to help troubleshoot your network from both a PC and a Cisco router. Keep in mind that though these commands may do the same thing, they’re implemented differently.

    ping Uses ICMP echo requests and replies to test if a node IP stack is initialized and alive on the network.

    traceroute Displays the list of routers on a path to a network destination by using TTL time-outs and ICMP error messages. This command will not work from a command prompt.

    tracert Same function as trace route, but it’s a Microsoft Windows command and will not work on a Cisco router.

    arp -a Displays IP-to-MAC-address mappings on a Windows PC.

    show ip arp Same function as arp -a, but displays the ARP table on a Cisco router. Like the commands trace route and tracert, arp -a and show ip arp are not interchangeable between DOS and Cisco IOS.

    ipconfig /all Used only from a Windows command prompt; shows you the PC network configuration.

    It’s common for a host, router, or other network device to be configured with the wrong IP address, subnet mask, or default gateway. Because this happens way too often, you must know how to find and fix IP address configuration errors.

    A good way to start is to draw out the network and IP addressing scheme.

    Once you have your network accurately drawn out, including the IP addressing scheme, you need to verify each host’s IP address, mask, and default gateway address to establish the problem. Of course, this is assuming that you don’t have a Physical layer problem.

    Look at the example illustrated in the following figure. A user in the sales department calls and tells you that she can’t get to ServerA in the marketing department. You ask her if she can get to ServerB in the marketing department, but she doesn’t know because she doesn’t have rights to log on to that server. 

    First, guide your user through the four troubleshooting steps you learned earlier in this section. Steps 1 through 3 work, but step 4 fails. First, the WAN link between the Lab_A router and the Lab_B router shows the mask as a /27. You should already know that this mask is 255.255.255.224 and determine that all networks are using this mask. The network address is 192.168.1.0. What are our valid subnets and hosts? 256 – 224 = 32, so this makes our subnets 0, 32, 64, 96, 128, etc. So, by looking at the figure, you can see that subnet 32 is being used by the sales department. The WAN link is using subnet 96, and the marketing department is using subnet 64.

    Now you’ve got to establish what the valid host ranges are for each subnet. You should now be able to easily determine the subnet address, broadcast addresses, and valid host ranges. The valid hosts for the Sales LAN are 33 through 62, and the broadcast address is 63 because the next subnet is 64, right? For the Marketing LAN, the valid hosts are 65 through 94 (broadcast 95), and for the WAN link, 97 through 126 (broadcast 127). By closely examining the figure, you can determine that the default gateway on the Lab_B router is incorrect. That address is the broadcast address for subnet 64, so there’s no way it could be a valid host!

© 2015 by Learncertification All Rights Reserved. The certification names are the trademarks of their respective owners. Terms & Privacy Policy