|
Many of the problems associated with intranet-to-Internet access are difficult to diagnose, since a problem can be manifested on either side of a firewall or even in the firewall itself. This month, we examine two such Internet-access problems as experienced by our customers. Here's our first problem as described by our client: "Many of our 5,000 corporate Internet subscribers are complaining about slow response time. Our corporate internetwork (intranet) has a firewall between it and the Internet
, connected via a full 1.544-Mbps T1 link. We need to pinpoint where the problem is before we start upgrading equipment or paying for more lin speed in hopes that response time will improve."
Scott:
Since users frequently ask questions like "Where's the 'any' key?"--as if it were a network problem--the first thing we needed to do was monitor a user's browser during a period of slow access.
Bill:
In this case, the user appeared to have a legitimate complaint, since a number of browser requests took several seconds before the response appeared.
Scott:
Of course, we could have attributed this delay to uncontrolled f
actors in the Internet and called it a day, but we don't give up that easily. We needed to capture some of the user's browser traffic and analyze it in detail.
Bill:
Having done so, our analysis showed a delay of up to 10 seconds from the time a packet entered the firewall to the time it was sent on the T1 link to the Internet.
Scott:
Based on this information alone, one might have concluded that the T1 was the bottleneck.
Bill:
Not so in this case. Further analysis on the T1 side revealed that despite a backlog of packets, the firewall couldn't keep the T1 link saturated.
Scott:
A more robust, or faster, firewall was needed.
Bill:
And, based on the backlog, our client also had to add more firewalls and install a link to the Internet that was faster than the T1 in order to service the multiple firewalls. Problem solved.
Scott:
Now for our next problem.
"My Windows95 workstation suddenly loses all its IP connections while accessing the Internet. Although the workstation doesn't freeze, the only way to regain Internet access is to reboot. Needless to say, the Windows95 rebooting process is very slow and obviously isn't the solution to this problem."
Bill:
Sounds like a problem for Bill Gates.
Scott:
Especially since the workstation in question was using th
e standard stock TCP/IP stack that comes with every copy of Win95.
Bill:
Having limited access to Mr. Gates, we opted for the analysis approach instead.
Scott:
So we went out and captured a failed Internet session, and noted that whenever a packet was lost or delayed in cyberspace, Win95 IP sent up to three packet retransmissions before trying the next gateway (router) from the user's list of default gateways.
Bill:
The user's workstation attempted to find the new gateway using the Address Re
solution Protocol (ARP). An ARP packet contains the IP address of the desired device (the target gateway) and is broadcast on the user's local segment to find the Data Link Control address associated with that IP address.
Scott:
If the subsequent default gateway is not on the same network segment as the user, it will never respond (unless a router on that segment is set up for proxy ARP). After moving onto a subsequent default gateway, Win95 IP will not recycle to
the top of the user's default gateway list where it would find its initially successful default gateway.
Bill:
Not only does the current application fail, but all IP applications in the workstation can no longer function!
Scott:
So why didn't the user experience this problem in the corporate intranet?
Bill:
When accessing the Internet, the retransmission rate was much higher because of delays and lost packets, increasing the likelihood of retransmitting a packet more than once in succession.
Scott:
Originally, the user simply got a list of all the default gateways and added them to the configuration.
Bill:
Of course, the user didn't realize that you're supposed to use only gateways that exist on your local segment, so the solution in this case was to get rid of the "remote" default gateways.
Scott:
We could have turned on proxy ARP or adjusted the retransmission timers or number of retries at the user's workstation. However, sinc
e everyone needed to know their default gateway for their local segment, the correct default gateway was a more straightforward solution and was easier to manage across the intranet.
Bill:
Win95 IP would also try legitimate gateways on retries, and if there was only one gateway, it would cycle the retries only on that gateway.
Scott:
As an exercise to our readers: Analyze your IP intranet-to-Internet traffic and see how your TCP/IP stack responds to problems like these. Feel free to drop us an e-mail with your experiences.
Bill:
Don't forget to e-mail your favorite network horror stories to us. We'll be printing our favorites in our October 15 column--just in time for Halloween.
Bill and Scott can be reached at otw@ pmg.com. Portions of trace files from selected columns are available via Pine Mountain Group's Home Page (www.pmg.com).
|
REPORTS
ANALYTICS
Follow 
