TCP/IP Troubleshooting: A Structured Approach - Part 2: Troubleshooting Routing Tables

In the first article of this series, I outlined a structured approach for troubleshooting TCP/IP networking issues on Windows-based networks. Key to this structured approach was 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).

They are used to determine which host (called the next-hop IP address) each packet should be forwarded to in order to reach the host this packet is ultimately destined for.

They are used to determine which network interface (called the next-hop interface) should be used to forward this packet so it gets to its ultimate destination.

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

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

AND between the destinations address in the packet (172.16.11.80) and the bitmask (Netmask) of the selected route. Here are the results, where each route in the table is identified by its network destination:

2. For each route, the result of this ANDing is then compared with the Network Destination field of the route, and a match means the route can be used to forward the packet to its destination address. If more than one match is found, Windows uses the route with the longest match (the route whose Netmask has the highest number of 1 bits). If this doesn't result in a unique match, Windows uses the match that has the lowest cost (Metric). Finally, if more than one match has the same lowest cost, Windows arbitrarily chooses one of them as the route to use. From the table above, you can see that this ANDing process results in two matches (routes 1 and 3) so Windows chooses the one that has the longest match, which is row 3. The result of all this is that Windows now knows which route to use to get this packet to its destination. Here\u2019s what this route looks like in the server's routing table:

A. If the route's Gateway field matches the address of one of the network interfaces on the server (or if the Gateway is empty) then Windows sends the packet directly to its destination address using the interface specified in the route.

B. If the route's Gateway field does not match the address of any of the network interfaces on the server, then Windows sends the packet to the address in the route's Gateway field.

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.