nv-l
[Top] [All Lists]

RE: Service Level & Bandwidth Monitoring

To: nv-l@lists.tivoli.com
Subject: RE: Service Level & Bandwidth Monitoring
From: "Dabbs, Cliff" <cliff.dabbs@mcps-prs-alliance.co.uk>
Date: Tue, 6 Feb 2001 11:47:27 -0000
Thanks to Everyone for the help with my previous queries,

David, Regarding the one below, can you please expand on the:

> We had to wind out the time-out and retry parameters to ensure the outages
> were genuine.
> 
i.e., How you did it?

I am experiencing some Node Up Events without first receiving a Node Down
Event. It always seems to be the same pieces of equipment, and its probably
just due the slow links to the equipment. 

Any help would be appreciated.

Cliff Dabbs
Senior Network Analyst
Client Services - Networks.
Ex: 4708

> ----------
> From:         davids@ibk.com.au[SMTP:davids@ibk.com.au]
> Reply To:     IBM NetView Discussion
> Sent:         06 February 2001 07:16
> To:   IBM NetView Discussion
> Subject:      Re: [NV-L] Service Level & Bandwidth Monitoring
> 
> 
> Danny,
> 
> There has been some good feedback on point 1) and the only thing I would
> add is that on a busy network I have seen packet loss that resulted in
> regular Node and Interface Down messages from Netmon. We had to wind out
> the timeout and retry parameters to ensure the outages were genuine.
> 
> Regarding point 2) I have used the thresholding capability within Data
> Collection to fire a trap to alert me to extended bursts of traffic
> associated with large file transfers. This only allows you to isolate the
> occurrences to a particular link, we then used RMON probes on the major
> LANs to isolate the devices. This sleuth work has to be done at the time
> of
> the occurrence as the averaging effect within RMON can make it difficult
> to
> isolate the culprit after the event.
> 
> None of this was terribly satisfactory, so the architectural answer was to
> implement Protocol Prioritisation in the routers and put FTP, SMTP, HTTP
> traffic etc in a low priority queue so that it didn't effect the
> time-critical business applications. Life was much easier after that.
> 
> David Steed
> Enterprise Management Consultant
> Innovative Business Knowledge Pty Ltd
> Phone 61-2-9584 8771 Mobile 0402 073 569
> Web Page: www.ibk.com.au
> 
> 
> > -----Original Message-----
> > From:         danny@uk.ibm.com [SMTP:danny@uk.ibm.com]
> > Sent:         Monday, 05 February, 2001 09:37
> > To:           nv-l@tkg.com
> > Subject:           [NV-L] Service Level & Bandwidth Monitoring
> >
> >
> >
> > Hi All
> >
> > These are architectural questions rather than a techinical ones.
> >
> > 1. Have any of you have used NetView in anger as a tool to monitor the
> > service levels being provided by a network provider? My initial thoughts
> > are that one could correlate interface down & up traps/events to
> establish
> > the amount of time a line was unavailable and then put this informaton
> in
> > to a file for offline processing.
> >
> > 2. I know that NetView is capable of monitoring the throughput on
> network
> > interfaces, but have any of you used NetView to pinpoint large data
> > transfers and the associated bottlenecks?
> >
> > Any information that you guys (and gals) can provide on these items
> would
> > be greatly appreciated.
> >
> > It may be that there are more appropriate tools for each of these
> > functions
> > - if so, please net me know.
> >
> > Thanks in advance for your assistance.
> >
> > Danny Williams
> > Tivoli & AIX Specialist
> > IBM Global Services - Integrated Technology Services
> > mailto:danny@uk.ibm.com
> > Tel: 665520 (01926-465520) -- MOBX: 275520 (07967-275520)
> >
> >
> 
> 
> 
> _________________________________________________________________________
> NV-L List information and Archives: http://www.tkg.com/nv-l
> 
The information transmitted is intended only for the person or entity to which 
it is 
addressed and may contain confidential and/or privileged material. 
Any use (including retransmission or copying) of this information by persons or
entities other than the intended recipient is prohibited.  If you are not the 
intended 
recipient of this transmission, please contact the sender and delete the 
material
from any computer.  The sender is not responsible for the completeness or 
accuracy
of this communication as it has been transmitted over a public network.
Any replies to this email may be monitored by the MCPS-PRS Alliance for quality 
control 


<Prev in Thread] Current Thread [Next in Thread>

Archive operated by Skills 1st Ltd

See also: The NetView Web