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

[jared mauch]

Collection of data like interface errors including drops, etc...  
Should be standard practice and help you isolate what or when there is  
a problem. Tracking this data may mean more complex polling than using  
mrtg/cfgmaker in the default settings but will prove its value over  
time.

Jared Mauch

On May 13, 2008, at 11:15 AM, "Rick Martin" <rick.martin at arkansas.gov>  
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/