I'll show you (and perhaps refresh your memory) some of the more important and powerful command-line utilities you can use to diagnose network problems on your IIS Web servers and IIS Web farms. Some of these tools' roots go back 20 or more years; some have roots in UNIX, and others are strictly Windows utilities.
You can use numerous command-line tools not only to diagnose problems when they occur but to identify potential bottlenecks before they become significant problems. These tools live in \WINNT\system32 and are consequently "pathed" so you can grab a command prompt and run them from anywhere.
Let's start with the basics. You can use the Ping.exe command-line tool to verify whether a local or remote TCP/IP system is available; you use it when your network resources stop talking.
Consider a scenario in which you receive reports that a Web application is suddenly receiving SQL Server errors. First, you can verify that both the IIS box and SQL Server are up and running. If they are, a simple ping test from the IIS box to the SQL Server box is a quick way to test connectivity. You can ping using DNS name, NetBIOS name, or IP address. And you'd probably do it in this order:
- Ping sanio.sys.com
- Ping sanio
- Ping 192.168.1.30
C:\WINNT\system32>ping sanio.sys.com
Pinging sanio.sys.com [192.168.1.30] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Reply from 192.168.1.30: Destination host unreachable.
Ping statistics for 192.168.1.30:
Packets: Sent = 4, Received = 1, Lost = 3 (75% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
C:\WINNT\system32>And let's assume a NetBIOS or IP ping method succeeds in this manner:C:\WINNT\system32>ping 192.168.1.30
Pinging 192.168.1.30 with 32 bytes of data:
Reply from 192.168.1.30: bytes=32 time<10ms TTL=128
Reply from 192.168.1.30: bytes=32 time<10ms TTL=128
Reply from 192.168.1.30: bytes=32 time<10ms TTL=128
Reply from 192.168.1.30: bytes=32 time<10ms TTL=128
Ping statistics for 192.168.1.30:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
C:\WINNT\system32>The problem obviously lies with DNS, and you can fix it accordingly. I turned off my internal Windows 2000 DNS server to illustrate the problem above, and when I turned the DNS service back on, everything worked correctly again.
You can use the ping tool when you test your Internet connectivity to the world outside the firewall or to test Internet connectivity to servers you host from remote locations. We are currently having a devil of a time with our ISP. We host our static site from a computer room in our San Diego office. Ironically, as I write this (in the middle of the night from home), I know that Internet connectivity is down because I just grabbed a browser to take a peek at our site's new look and feel. It failed. I grabbed a command prompt and pinged http://www.interknowlogy.com and it failed miserably. So it's time to call our network guys—they dread hearing from me, and I guarantee they aren't happy with our ISP.
TRACERT.EXE
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 \WINNT\system32 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:
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
PATHPING.EXE
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 \WINNT\system32 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
PATHPING.EXE
In the past two columns (see the URLs at the end of this article), I talked about how command-line utilities can help you diagnose network problems on your IIS Web servers and IIS Web farms. Often, complaints about latency in Web applications are due to network, not software, problems. The more complex your environment, the easier it is to accidentally or inherently introduce network problems.
I started with the absolute basics—PING. Ping.exe is a command-line tool you use to verify whether a local or remote TCP/IP system is available. Then I covered another basic topic—TRACERT. TraceRT (short for "Trace Route") is a route-tracing utility that can effectively measure the number of router hops (or routes) between systems.
In this article, I cover PATHPING. PathPing.exe is a Windows 2000 route-tracing tool that combines Ping and TraceRT features with additional information those tools don't provide. You can use PathPing to identify routers that cause delays and other latency problems on a connection between two IP hosts. By default, PathPing pings each router 100 times, with a single ping every 0.25 seconds. Consequently, a default query requires 25 seconds per router hop.
First, try a little test using PathPing to trace a route to your favorite Internet site. PathPing lives in \WINNT\system32 and is "pathed" so you can grab a Command Prompt and run it from anywhere on your system. (I might be overstating the obvious, but you'll need Internet connectivity to run this test.) When I type: PathPing –n InterKnowlogy.com (the "n" parameter prevents resolving IP addresses to host names), I get the following:
PathPing has several optional parameters:
http://www.win2000mag.com/Articles/Index.cfm?ArticleID=20618
http://www.win2000mag.com/Articles/Index.cfm?ArticleID=20819
I started with the absolute basics—PING. Ping.exe is a command-line tool you use to verify whether a local or remote TCP/IP system is available. Then I covered another basic topic—TRACERT. TraceRT (short for "Trace Route") is a route-tracing utility that can effectively measure the number of router hops (or routes) between systems.
In this article, I cover PATHPING. PathPing.exe is a Windows 2000 route-tracing tool that combines Ping and TraceRT features with additional information those tools don't provide. You can use PathPing to identify routers that cause delays and other latency problems on a connection between two IP hosts. By default, PathPing pings each router 100 times, with a single ping every 0.25 seconds. Consequently, a default query requires 25 seconds per router hop.
First, try a little test using PathPing to trace a route to your favorite Internet site. PathPing lives in \WINNT\system32 and is "pathed" so you can grab a Command Prompt and run it from anywhere on your system. (I might be overstating the obvious, but you'll need Internet connectivity to run this test.) When I type: PathPing –n InterKnowlogy.com (the "n" parameter prevents resolving IP addresses to host names), I get the following:
Tracing route to interknowlogy.com [63.237.180.197] over a maximum of 30 hops: 0 192.168.1.2 1 10.84.10.1 2 24.11.232.193 3 . . . Computing statistics for 375 seconds . . .When I run PathPing, it first lists the route. This is the same route that the TraceRT command-line tool shows. Next, PathPing displays a busy message for approximately 25 seconds multiplied by the number of router hops. During this time, PathPing gathers information from all the previously listed routers and from the links between them. At the end of this period, it displays the test results like this:
Source to Here This Node/Link
Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address
0 192.168.1.2
0/ 100 = 0% |
1 5ms 0/ 100 = 0% 0/ 100 = 0% 10.84.10.1
0/ 100 = 0% |
2 9ms 0/ 100 = 0% 0/ 100 = 0% 24.11.232.193
0/ 100 = 0% |And so forth . . . Trace complete.In the PathPing output above, in the "This Node/Link Lost/Sent = Pct" and "Address" columns, the link drops 20 percent of the packets.
PathPing has several optional parameters:
- n—Host names. Doesn't resolve addresses to host names.
- h
—Maximum hops. Maximum number of hops to search for target. - g
—Router-list. Uses a loose source route along the host-list. - p
—Period. Number of milliseconds to wait between pings. - q
—Number of queries per hop. - R—RSVP test. Checks to see whether each router in the path supports the Resource Reservation Protocol (RSVP), which lets the host computer reserve a certain amount of bandwidth for a data stream. Use the -R switch to test for Quality of Service (QoS) connectivity.
- T—Layer 2 tag. Attaches a layer-2 priority tag (for example, for IEEE 802.1p) to the packets and sends it to each network device in the path. This helps identify the network devices that don't have layer-2 priority properly configured. Use the -T switch to test for QoS connectivity.
- w
—Timeout. Waits this many milliseconds for each reply.
http://www.win2000mag.com/Articles/Index.cfm?ArticleID=20618
http://www.win2000mag.com/Articles/Index.cfm?ArticleID=20819
No comments :
Post a Comment