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

Convert ICMP nodes to SNMP with Network Discovery and (re)Import

We have a bunch of nodes that are currently ICMP nodes. Most of them have been reconfigured to allow SNMP and we want to convert them to SNMP, via Network Discovery. So our discovery would find all the new interfaces and good stuff we need to monitor. It seems this can only work if the polling engine is kept the same. We have multiple polling engines so this would be challenging.

Am I correct with the assumption that it will work if the polling engine is kept the same? And is there any way around this? I can discover and auto import via API (this is how we add most new nodes).

Thanks in advance!!

Find more posts tagged with

Accepted answers

All comments

rschroeder

I suspect you will find that multiple polling engines will not be an issue if they all report to the same primary instance of NPM.

I move nodes between polling engines as needed to ensure no one polling engine is overloaded. The inconvenience comes if you are tidy and OCD like me, and have configured your nodes to report syslog and/or traps to the poller originally managing them. Worse, if you have ACL's defining which sources are allowed to talk to nodes via snmp using a specific community string, you may not be able to manage those nodes properly after they are moved to new pollers. But that's just housekeeping, and easy to manage if you plan it out thoroughly and move to different pollers carefully.

Regarding changing polling from ICMP to snmp, after you've got your nodes properly configured for snmp (and syslog reporting and trap sends, etc.), suppose you went to Manage Nodes, then displayed them by Polling Engine (or perhaps by polling method?), and finally selected all that are being polled by ICMP and changed them in bulk to be managed by snmp?

I have NOT tried this, but I HAVE moved nodes in bulk between pollers, and I know NPM automatically tests each node for snmp string compatibility. Once it verifies the snmp test is successful, it simply adds those nodes in bulk to the poller defined. I don't think it's a stretch to be able to change polling nodes in bulk from ICMP to SNMP--as long as you have the right strings & ACL's installed on them.

Then it's an easy matter of doing a bulk change via NCM to get them to remove old ACL's and old syslog/trap configurations, and get the nodes pointing at new pollers.

When you're done, it'll likely be easier than you imagine, and any OCD needs you may have will rest easy, smiling to see the nodes are working properly with the new poller(s), and managed via SNMP.

Your original thought was to do this via Network Sonar so your nodes' internal interfaces and volumes (and all their beautiful SNMP-compatible OIDs) would be discovered by NPM and correctly monitored. That sounds like a great way to do it. I do not use Network Sonar simply to keep the Security Gods appeased (lots of alarms go off when we do port scans or snmp discoveries on multiple internal Class B's), and I don't need the grief that comes flooding back. It means managing a few thousand nodes, 40000+ elements, and several hundred volumes manually. It would be an onerous task to take on all of it at once, but I've grown this network manually over the last fifteen years, and while there's a risk of something undiscovered sneaking through the cracks (particularly as the result of a merger or some rogue vendor), doing this manually has it strengths.

Test it on one node and see how it goes. You've nothing to lose, and a lot of ease to gain.

clarv02

Thanks rschroeder for all the info and your approach. After reading your reply, it gave me an idea (that should have previously been obvious to me). It's true that running a discovery against existing ICMP nodes will not transform them to SNMP if the polling engine is not the same (polling engine defined in discovery must be the same as existing). During the import stage, they will just be skipped if different polling engine.

So all I needed to do is make sure all those ICMP nodes are assigned to a single polling engine, then use that same engine for the discovery. As rschroeder mentioned, and I'm sure many of us have run into, changing polling engines for SNMP nodes can introduce a problem if those nodes don't allow SNMP from the new polling engine. But as ICMP nodes, that should generally never be an issue (just pings).

I tested this on a couple of them, then proceeded with the entire list. Ended up transforming 69 nodes from ICMP to SNMP in bulk. We use extensive filters for selecting interfaces, so that was done here as well. Then after the "re-import" was completed, I just needed to bulk assign custom pollers and the task was complete.

rschroeder

Good work! That's what comes from thinking out of the box a little, and bouncing ideas off of peers.

I'm happy this is working out easy for you!