Windows Server 2008 R2 : Troubleshoot IPV4 - Verify Responsiveness

1. Use the Network Connection Repair Tool

When you find a problem with connectivity, it makes sense to begin your troubleshooting in some common areas. The Network Connection Repair Tool will check for some of the most common connectivity problems. If it finds them, it will make the necessary adjustments and reconnect the system.

The Network Connection Repair Tool automates a list of functions including the following:

• Checking that DHCP is enabled and refreshing the IP address lease

• Flushing the ARP cache

• Flushing the DNS cache using IPCONFIG /FLUSHDNS

• Reregistering DNS names using IPCONFIG /REGISTERDNS

• Flushing the NetBIOS name cache

• Reloading the NetBIOS name cache

The really cool thing about the Network Connection Repair Tool is that the whole process is automated, and it can be initiated from the client and requires no administrative intervention. This means you can resolve the most common IPV4 problems with very little administrative effort.

To start the Network Connection Repair Tool, you will need to go to the Network Connections folder. Right-click the connection you want to repair, and choose Repair.

2. Verify IPV4 Connectivity

If the Network Connection Repair Tool does not fix the connectivity problem, you will need to dig a little deeper to identify and resolve your IP connectivity issues. We recommend you begin at the Event Viewer.

The Event Viewer shows events, warnings, and error messages from the local system or any system to which you have subscribed for event updates. This means the local Event Viewer will collect data about the local system and other systems you choose. You can effectively use the Event Viewer as a central resource to monitor key clients and servers throughout your network. The Event Viewer will likely display any related events that are affecting TCP/IP connectivity.

You will want to make sure that the TCP/IP configuration is correct before you do anything else. Does the current configuration match the defined configuration for this network connection? Knowing your network and how the configurations are supposed to be will have tremendous value when you are troubleshooting.

3. Verify Responsiveness

Of course, not every problem is going to be fixed with a simple check of the hardware and address configuration. Responsiveness is also important. Responsiveness takes into account that communication takes at least two endpoints. If either of the endpoints fails to respond, then the communication cannot take place. If you have checked the local configuration and everything is in order, you should check that the machine is actually responding to IP requests.

IPV4 uses something called an Address Resolution Protocol (ARP) cache to store IPV4 addresses that have been resolved recently. If for some reason the ARP cache holds incorrect information, it can impede connectivity. You can flush the ARP cache with no negative effects to TCP/IP using this command:

ARP -D

If you are thinking to yourself, "Hey, that's a lot like the neighbor cache from IPV6," you are right!

The previous step, deleting the ARP cache, acts as a preemptive action to eliminate the possibility that your machine is being incorrectly directed to an IPV4 address that is not going to respond. To truly troubleshoot responsiveness, you will need to start sending packets onto the network and watching for responses. There are a couple of tools that are uniquely suited for this exercise.

PING uses the Internet Control Message Packet (ICMP) to send echo request packets to a host and then measures the response time as the host responds to those echo requests. This tool can be incredibly valuable in verifying responsiveness in IPV4. Traditionally when you use the PING tool, you begin with the process of pinging the local host address and then move on to the local IP address, then an IP address on the same subnet, next the default gateway of the local router, and finally an address on another network segment. You might have learned that you can skip right to pinging a remote host on another segment; if you get a response, you know everything in the cascade is working. As tempting as that is, in the event that you do not receive a response from the remote host, you really don't know anything about where your problem is located. Start with the local host, and work your way through the list. When you don't receive a response, you have reached the area that is having the problem.

IPV4 has a tool called Trace Route (TRACERT) that allows you to do exactly as its name suggests and trace the route from source to destination in a TCP/IPV4 connection. This tool will help you identify any routing issues that might exist on the route from source to destination computer. Its syntax is as follows:

TRACERT -D xxx.xxx.xxx.xxx

where x is the IP address of the destination computer.

One more very important point concerning PING and TRACERT is that ICMP packets can be considered a security risk, and often network administrators will configure their computers not to accept or respond to ping echo request packets. If you ping a machine and get no response, make certain that the reason you are not getting a response is because there really is no connectivity, not that the system you pinged does not support ICMP packets. This process of removing or limiting response to specific packet types is often termed packet filtering. Packet filtering is a common reason for lack of responsiveness. If you are confident that TCP/IP has been installed and is configured correctly and you are still not getting connectivity, it may well be an issue of filtering. Consider checking the following:

• Windows Firewall rules

• IPsec policies

• Remote access policies

• IPV4 packet filters

• Router policies

Although you are checking for IP filtering issues, you will also want to identify any potential TCP filtering issues. This will save you a troubleshooting step later if you happen to have a problem with TCP connectivity.

4. Check the Routing Table for IPV4

TCP/IP connectivity issues could be caused by incorrect entries on the IPV4 routing table. You can use the ROUTE PRINT command to show the IPV4 routing table. Here again you will need to be familiar with what the correct routes should look like and then check for any erroneous information on the routing table.

You can add new routes with the ROUTE ADD command. If you find erroneous routes and want to update them with correct information, you can modify the entries with the ROUTE CHANGE command. If you find entries that should just not be there, you can delete routes using the ROUTE DELETE command.

Although you are working with the router and routing table, it makes sense to trace a path through routers from source to destination. You can use the PATHPING xxx.xxx.xxx.xxx command to trace the route. Remember, this tool will display packet losses for each router along the path. Some administrators like to use the -d switch with PATHPING in order to speed up the display of results by preventing the reverse DNS lookup at the internal interface of each router on the path. We like the additional detail provided, and we don't mind waiting. You choose what works best for your situation.

5. Validate DNS Name Resolution for IPV4 Addresses

If the IPV4 addressing configuration and response checks out, you will want to move up and check on the resolution of host names to TCP/IP addresses, which means DNS. DNS resolves host names to IP addresses for both IPV4 and IPV6. You can perform some simple tasks to ensure that IPV4 host name to IP address resolution is occurring properly.

First verify that your DNS server has been configured to resolve host names to IPV4 addresses and that it is acting upon name resolution requests it receives. To begin, use the HOSTNAME utility to check the host name of the server and to check the DNS suffix.

Next, open the DNS Manager tool, and verify that all of your configured DNS servers appear on the DNS Manager's list of authoritative servers. You can also use the DNS Manager to check the process of forwarding in the event that a host name cannot be resolved to an IP address on the local DNS server. If you need to make changes to the DNS suffix or to connection-specific DNS suffix information, you can do it using DNS Manager.

6. Flush the DNS Cache

Each IPV4 client maintains a list of recently resolved DNS to IPV4 addresses. This list is called the DNS resolver cache. If for some reason a record in the cache had an incorrect address for a given host name, it would limit connectivity. In cases like this, you can flush the contents of the DNS resolver cache using this:

IPCONFIG /FLUSHDNS

This command will remove all entries from the cache and force the machine to resolve the address with recursive queries sent to the local DNS server hierarchy and get the correct host name to IP address information.

You can quickly check for the function of DNS resolution using the PING tool, as shown in Figure 2. PING can be used in conjunction with IP addresses or host name or an FQDN. For example:

PING Computer 1

or

PING www.microsoft.com

Figure 2. Results of PING www.microsoft.com

7. Test IPV4 TCP Connections

What if everything works from an IP perspective but you still cannot get a TCP connection to occur between systems? In the majority of cases, this is a problem with packet filtering. You learned earlier in the chapter about packet filtering locations for IP packets. You will need to check the same locations for TCP filtering. Since you will be checking your filters when you are validating IP connectivity, it makes sense to check for TCP filters at the same time. If you didn't check for TCP filtering earlier, it is time to do it now.

One of the easiest ways to check TCP connections is with the TELNET tool. TELNET is a command-line tool that establishes TCP connections between systems. It uses a syntax similar to the PING command; simply use the TELNET command followed by the IPV4 address.

If the connection is possible, TELNET will create it. TELNET connects to a service, so once you connect to a machine, you can execute commands against the machine to test, configure, or view the contents of the remote machine. TELNET is sometimes seen as a potential security risk, so please don't be surprised if the local firewalls or security policies do not allow TELNET packets.