Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials

Identifying Bandwidth Issue

what screens and parameters should i look at to proactively determine if we are having bandwidth issues? NPM response time doesn't seem to help. is there something in NetFlow that can tell me if we are running out of bandwidth or should i be looking at something in NPM?

Find more posts tagged with

bandwidth_issue

Accepted answers

All comments

Jesquitin

Your best bet is to look at the "Interface Details" page in NPM. There are two charts that will shine some light on bandwidth utilization:

Min/Max/Average bps In/Out

Percent Utilization

You can also setup an alert based on bandwidth or percent utilization to send out an email when the threshold is met.

smarion

as a rule of thumb, what percent utilization is considered good, boardline and a problem?

Also, what is the rule of thumb for Min/Max/Average bps In/Out?

danielleh

Hi smarion--

Also, the Real-Time Bandwidth Monitor is a free tool used especially for troubleshooting and network changes. Please see this blog.

darragh.delaney

Hi There,

It just depends how much detail you need to identify the bandwidth issue. NPM which has being mentioned already is good at using SNMP to read values from your network devices. One of the most commonly used values is bps of an interface. You can use this to create alerts when bandwidth goes over certain levels. Other may correct me on this but I find that SNMP data does not have enough information (sometimes) for troubleshooting.

Your next option could be to use NetFlow or one of the other flow standards (jflow, ipfix, sflow). Typically NetFlow is available on a L3 device like a router or switch which has a layer 3 feature set. Once enabled you end up information like what is making connections on your network and how much bandwidth these conversations use up. The NTA product can also graph this data so you can see what utilisation is like amongst other things.

If want to look at what is happening on your LAN and you don’t have NetFlow features available on your network switches then you could look at using a SPAN port. This allows you to take a direct copy of the traffic as it moves through the switch. You could use something like nProbe to convert this raw traffic to flow which can then be processed by NTA. More info at this link

Finally, we’ve integrated our LANGuardian traffic analysis product with NPM so when monitoring and troubleshooting you get a very comprehensive picture and all the detail you need via one dashboard. An online demo of it is available here

Darragh

steve_warren

We normally use 75% as the benchmark for high utilization. I normally use the Min/MAX/Avg RX+TX chart to look at my utilization pattern. Netflow digs deeper by telling you who is using the bandwidth and how much so that you can for instance do some capacity planning or redefine your network access rules.

mdriskell

smarion,

The standard rule of thumb I have always gone by is that you don't want to consistently exceed your WAN links by 70% and your LAN links by 30%.

That being said when you are looking at the charts and graphs in Orion these are based off of a 24 hour clock by default. So if you are looking at the monthly utilization of a circuit for a location that is 8-5 M-F your results will likely be skewed and you may want to adjust for their actual working times.

There are a couple of examples on how to do that but here is one for creating a report based on business hours.

FormerMember

BW utilization can be a useless measure if you use Quality of Service policies on your links. We have to go be user experience. Our links can be maxed out and we never hear from the users.