[c-nsp] Prove it's not the network!

[Eric Gauthier]

Rick,

This type of problem is one of the most difficult to diagnose.
If you've exhausted all of your other avenues, then you might
want to consider capturing the network traffic for this
person's session during a time when its "slow".  This is a very
labor intensive process, but it may be the only way to focus
in on the "real" problem.  You will need to grab traffic from
the end-user's network port so thta you can go through the
entire session - DNS lookup, TCP setup, the Outlook/Exchange 
login, the request for information, the response time of the 
server, and the download rates, etc. - and build a timeline 
for the transaction.  

This won't, in itself, tell you what's wrong but it will tell 
you how long each sub-component is taking.  From there, you
should be able to figure out which one is causing the worst
delay and then research it - be it the network or application.

Eric Gauthier
.....................................
. Boston University
. Network Systems Engineering Group
. 111 Cummington St. Boston, MA 02215
. 617-353-8218 ~^~ elg at bu.edu
. http://www.bu.edu/nsg/
.....................................



On Tue, May 13, 2008 at 10:15:32AM -0500, Rick Martin wrote:
> 
>  I know this is not really a Cisco specific question but it is
> definitely in support of Cisco hardware. 
> 
>  How do most of you folks prove that "the problem" is not the network?
> We utilize CA Spectrum and eHealth for availability and statistical
> analysis but in some instances that does not cut it. We don't typically
> have much trouble proving that a T1 is serving up 1.5 meg of bandwidth.
> Customers complain that their access is slow, we show that they are
> using all available bandwidth and eventually sell them more bandwidth
> and the problem is resolved.
> 
>  The more difficult effort is when there is plenty of available
> bandwidth and a particular application is slow (Outlook in the case I am
> involved in now). This is a very high level political official and we
> must come to a resolution. All tools we have available to us today
> indicate that there is not a problem with the network. Typical
> utilization on the T1 is about 500 to 600K peak during the day. Certain
> management continues to point the finger at the network. We have used
> Internet based speed tests that at times show less than 1.5Meg download
> speeds, I explain the variables in the Internet and the particular tool
> in use as well as local contention for the bandwidth etc to no avail,
> once they see less than 1.5 meg speed the finger points to the network.
> I still must somehow "prove" that the network is not the issue. 
> 
>  I am interested in an Internet speed test like tool to install at the
> core of our network that would provide a sustained upload or download
> test that would run for longer periods of time than a regular speed
> test. I would like to fill the pipe while graphing in Ehealth or as part
> of the selected tool to prove that the contracted bandwidth is available
> in both directions.
> 
>  Any recommendations for products would be appreciated. We are currently
> looking at SolarWinds WAN Killer and a traffic generator from Omnicore
> LanTraffic V2. I am also open to different "types" of solutions to point
> to where the problem is actually located. 
> 
> Thanks in advance for any suggestions
> 
> Rick Martin
> Network Engineer
> State of Arkansas, Department of Information Systems
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/