IIS Command-Line Tips and Tricks for Network Problem Diagnosis, Part 2

In the last issue of IIS Administrator UPDATE (see the URL at the end of this column), I talked about how powerful command-line utilities can help you diagnose network problems on your IIS Web servers and IIS Web farms. I started with the absolute basic—PING. Ping.exe is a command-line tool you use to verify whether a local or remote TCP/IP system is available. This time, we look at another basic command-line utility you'll want in your arsenal—TraceRT.

Tracert.exe (short for Trace Route) is a route-tracing utility that can effectively measure the number of router hops (or routes) between remote systems, but it's even more effective for measuring hops between your internal systems when you have latency problems. In other words, TraceRT can help identify routing problems between application servers. You can use TraceRT with domain names, IP addresses, or even NetBIOS names.

First try a little test by using TraceRT to trace a route to your favorite Internet site. TraceRT lives in WINNTsystem32 and is consequently "pathed" so you can grab a Command Prompt and run it from anywhere on your system. (I could be overstating the obvious, but you need Internet connectivity to run this test.) When I type tracert interknowlogy.com from my home in Carlsbad, California, I get the following:

 1    20 ms    20 ms    20 ms  10.84.10.1 2   <10 ms    10 ms    10 ms  bb1-fe2-0.carlsbad1.ca.home.net [24.11.232.193] 3    10 ms    20 ms    20 ms  c1-se6-0.sndgca1.home.net [24.7.73.113] 4    10 ms    20 ms    20 ms  c1-pos1-0.anhmca1.home.net [24.7.64.69] 5    10 ms    30 ms    10 ms  c1-pos1-0.lsanca1.home.net [24.7.65.169] 6    10 ms    30 ms    10 ms  c1-pos2-0.snbbca1.home.net [24.7.65.174] 7    20 ms    20 ms    20 ms  c2-pos3-0.snjsca1.home.net [24.7.64.49] 8    20 ms    30 ms    30 ms  24.7.70.134 9    20 ms    20 ms    30 ms  svl-core-03.inet.qwest.net [205.171.14.109]10    20 ms    40 ms    30 ms  bur-core-02.inet.qwest.net [205.171.5.217]11    30 ms    30 ms    30 ms  bur-core-01.inet.qwest.net [205.171.13.1]12    30 ms    20 ms    30 ms  lax-core-01.inet.qwest.net [205.171.8.41]13    30 ms    30 ms    60 ms  lax-edge-09.inet.qwest.net [205.171.19.150] 

My company's Web site is hosted in our San Diego office—just 2.5 miles from my home. Look carefully at the route. The first seven router hops are on the @home network starting in Carlsbad, moving 30 miles south to San Diego, then turning 100 miles north to Anaheim, another 100 miles north to Los Angeles, 30 miles to Santa Barbara, and 350 miles to San Jose, where I get out to the Qwest network and start "hopping" my way south again all the way back to southern California. And remember, I live 2.5 miles away from my company's Web site location! And we wonder why our connections seem slow!

Let's move to a more practical example that you'll probably use when your users (or developers) complain that a site is slow: using TraceRT to measure router hops between your application servers. Just the other day, a content manager at one of my clients complained that the deployment application was really slow. I knew the LAN wasn't experiencing latency of any significance because I'd been using it. One of the network guys told me that they had updated the router software in the production DMZs over the weekend. From the staging server that hosts the content deployment application, I ran a TraceRT to the production Web server farm that deployed the content and found seven router hops! I printed the TraceRT results, took the printout to the networking folks who did the work, and said, "I think we have a problem." This case was particularly interesting because two router hops were to the same router. It hopped in and out and then back in to the DMZ. The networking folks fixed the problem, and the content manager was back in business.

TraceRT can also help you trace routes between Web servers and database, directory, and Lightweight Directory Access Protocol (LDAP) servers. Do yourself a favor and run some TraceRTs between those servers on your Web farm. Eliminating even one router hop between a Web server and a SQL Server machine could mean a spectacular increase in your site's performance.

http://www.win2000mag.com/Articles/Index.cfm?ArticleID=20618