This article from WindowsNetworking.com explains how routing tables work and how to troubleshoot routing problems in Windows-based networks.
In the first article of this series ( TCP/IP troubleshooting: A structured approach -- Introduction), I outlined a structured approach for troubleshooting TCP/IP networking issues on Windows-based networks. Key to this structured approach were three things:
I displayed these items as a bullet list instead of a numbered list because network troubleshooting generally isn't as easy as 1-2-3. In other words, it's often more of an art (i.e. based on intuition) than a science (based on a methodology).
At the foundation of TCP/IP networking is the routing table, a data construct on each host on a TCP/IP network. Routing tables serve the following three purposes:
Understanding routing tables is therefore essential if you want to be able to effectively troubleshoot routing issues on a TCP/IP network. Let's look at how routing tables work, what they look like in different scenarios, and what troubleshooting steps and tools might be indicated in different situations. We'll begin by examining the routing table on a single-homed server (a server with a single network interface) that has a single IP address assigned to it. I've chosen this example because it's the easiest one to understand, and in next month's follow up article we'll look at more complicated scenarios including servers with multiple IP addresses (such as web servers) and servers with multiple network interfaces (such as servers that are connected to both the LAN and to a separate network used for running backup jobs).
Routing table for single-homed server with a single IP address
The following routing table is for a server that has IP address 172.16.11.30 on the 172.16.11.0/24 network:
To display this routing table, you open a command prompt window and type route print at the command line. Let's take this table apart so we can understand h
To continue reading for free, register below or login
To read more you must become a member of SearchNetworking.com
ow it works.
Each routing entry (or route) in the routing table is composed of five fields:
Example 1: Destination host on local subnet
For our first example, let's say this particular server (172.16.11.30) has to send a packet to another host with IP address 172.16.11.80, which is on the same subnet. This packet will thus have source address 172.16.11.30 and destination address 172.16.11.80. Here is how Windows uses its routing table to decide which route to use:
Clearly, condition A is the case here since the route's Gateway field (172.16.11.30) is the address assigned to the server's single network card. Windows therefore determines that the destination address is on the local subnet and that means Windows can send the packet directly to that address without needing to forward it to any routers. So in this case, Windows simply sends the packet to 172.16.11.80 using the server's 172.16.11.30 network interface, and the receiving host gets it.
Example 2: Destination host on remote subnet
Now let's go through the same process, but this time let's say the server is trying to send the packet to a host on a different subnet, say a host with the address 172.16.10.200. In other words, the packet has a source address of 172.16.11.30 and a destination address of 172.16.10.200. Here's how Windows uses its routing table to decide which route to use this time:
Troubleshooting tips
What can fail in the above process? First, it's possible that Windows might be unable to select a route whose Network Destination field matches the bitwise AND of the Netmask field of the route and the packet's destination address. If this happens, you've got a routing error, and this will probably be indicated to you by some network application running on your server. What happens usually is that Windows uses TCP to notify the upper layer of the network stack that the packet can't be sent, and an error message of some kind usually results.
In this situation, you probably have either a corrupt routing table or an invalid persistent route in your routing table. Persistent routes are routes you add manually to the table using the route -p add command and which persist across reboots since their values are stored in the registry. If you add routes that are invalid, they can produce strange results, though most often they simply result in traffic being dropped mysteriously.
On the other hand, if the destination host is on a remote subnet and Windows forwards the packet to a router (the default gateway address) and this router can't select a route, then what usually happens in this case is that the route returns an ICMP message of "Destination Unreachable -- Host Unreachable" to the host that sent the packet. In this case, TCP will notify upper layers and some sort of error message will be displayed.
In either situation, a useful way to proceed is to examine the routing tables on the sending host and any intermediate routers along the way to the destination host, and see if these routing tables are consistent or look corrupted. A corrupted routing table can be restored (at least on Windows machines) by resetting the TCP/IP stack using the netsh int ip reset command (see KB299357 for details). Note that this reset operation does not remove persistent routes you've added to your routing table.
Conclusion
Now that you know a bit about how routing tables work and how to troubleshoot them, in the next article we'll look at more complex examples such as servers with multiple addresses and several network cards.
About the author:
About the author:
Mitch Tulloch is a writer, trainer and consultant specializing in Windows server operating systems, IIS administration, network troubleshooting, and security. He is the author of 15 books including the Microsoft Encyclopedia of Networking (Microsoft Press), the Microsoft Encyclopedia of Security (Microsoft Press), Windows Server Hacks (O'Reilly), Windows Server 2003 in a Nutshell (O'Reilly), Windows 2000 Administration in a Nutshell (O'Reilly), and IIS 6 Administration (Osborne/McGraw-Hill). Mitch is based in Winnipeg, Canada, and you can find more information about his books at his Web site: www.mtit.com.
[TABLE]WindowsNetworking.com contains a wealth of networking information for administrators: Featuring information on how to setup and troubleshoot various networks of any size. Also includes a comprehensive archive of hundreds of reviewed networking software and hardware solutions. Frequently updated with articles and tips by a team of leading authors, it remains a favorite within the networking community.
