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
Store

Getting thousands of alarms from admin up interfaces with nothing connected to them after migration to Solarwinds

We recently migrated to Solarwinds as our only monitoring tool. After the transition, we are getting thousands of alarms from interfaces that have been admin up for several years but nothing is connected to them. These interfaces have been in this status for years because field techs normally don't shut down interfaces, they just unplug and retire equipment attached to these interfaces. i know that the best solution is to shut down these unused interfaces, but this effort would take a long time. do you guys have any ideas on how to fix this problem using Solarwinds?

Find more posts tagged with

Accepted answers

shuth

As HerrDoktor said, turn off all the out-of-the-box alerts. They are meant as examples and you will be flooded with alerts if you leave them on. Start with a small subset of alerts (node down, interface down, hardware warning/critical, etc).

There are two options for the interface monitoring:

1. Delete all the interfaces you don't care about

This is a cleaner method as you are only monitoring and alerting on the interfaces that are important to you. It's a bit more work going through each device and deleting (or enabling) interfaces so that only the important ones are monitored. This could be trunks, port-channels, WAN links, etc. The interface down alert can be used to let you know if any of these important interfaces goes down.

Pros - cleaner and only monitoring key interfaces, lower license/resource requirements

Cons - need to go through and make sure important interfaces are monitored, need to add interfaces each time change made to devices

2. Edit the access port interfaces to be unpluggable (per aLTeReGo's comment)

This requires a larger license count as you will be monitoring a larger number of interfaces. If you set the access port interfaces to unpluggable, they won't trigger the interface down alert as the status will be unplugged instead of down.

Pros - you can see stats on all your interfaces and utilisation of switch ports

Cons - much larger license required, more resources required (polling server, database size, etc), you will need to update each interface to be unpluggable, if access port becomes a trunk you need to update the interface to no longer be unpluggable

If your interfaces have good descriptions you could potentially script the unpluggable flag in the database (e.g. set unpluggable = true if description contains "user port".

All comments

HerrDoktor

Do you have any indicator which interfaces need to be monitored and which don’t need to be monitored?

how did you get the nodes into Orion? Did you do a discovery? what settings did you use for the discovery?

HerrDoktor

For the alerting part...turn off all alerts until you baselined your environment. Trust me, you will never get your staff to look at the emails again if they’re flooded with useless information to begin with.

once you have your metrics and thresholds ready, start with easy alerts like “Node down” use the out of box alerts as starting point to create your own alerts. Don’t blindly turn on the out of box alerts, they are meant as an example.

aLTeReGo

If you're monitoring access ports on your switches you will probably want to edit those interfaces in Orion and enable 'Display interface as unplugged rather than down'. This should eliminate the alerts you are receiving on those interfaces.

HerrDoktor

Thanks for that, haven’t thought about this. With this setting one could still get metrics from access ports if they are plugged in, but no alerts when they go down. They would still require one license count of the SL xxx and still eat up a tiny bit of polling performance, but that is something to consider in the planning phase.

It depends what someone wants to „see“ or what Problem you want to solve with the Orion platform

shuth

There are two options for the interface monitoring:

1. Delete all the interfaces you don't care about

Pros - cleaner and only monitoring key interfaces, lower license/resource requirements

Cons - need to go through and make sure important interfaces are monitored, need to add interfaces each time change made to devices

2. Edit the access port interfaces to be unpluggable (per aLTeReGo's comment)

Pros - you can see stats on all your interfaces and utilisation of switch ports

If your interfaces have good descriptions you could potentially script the unpluggable flag in the database (e.g. set unpluggable = true if description contains "user port".