cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post

Please modify NPM to "completely" rediscover a node when it is replaced, instead of forcing us to delete the old node and then add the new node. The rediscovery must include removing ports that are not present on replacement nodes.

Please modify NPM to "completely" rediscover a node when it is replaced, instead of forcing us to delete the old node and then add the new node. The rediscovery must include removing ports that are not present on replacement nodes.

I'm going through a forklift upgrade this year, replacing about 500 Cisco 2960S switches with 3850's. The replacement switches are given the same names and IP addresses as the outgoing 2960's.

The problem lies in NPM's inability to clean up / remove old ports that aren't present on the new switches.  They remain present in the list of resources for the node, grayed out, until the node is deleted.

I'd rather not have to delete a node and then re-add it just to compensate for NPM's inability to delete absent hardware or interfaces that are not present on the replacement gear.  

Since NPM has a "Rediscover" button for every node, and since that action discovers all NEW interfaces and hardware on a node, why shouldn't NPM be able to learn when some previously-discovered ports are no longer present, and either delete them automatically during Rediscovery or during scheduled Inventory Jobs, or call these ports out for attention after Rediscovery so we can evaluate the output and choose to delete them.

That would be a full-featured tool, and a better one for everyone's environment.

Please add this feature, and save us all the trouble of having to delete and re-add/rediscover nodes.

I'll send VPP's (virtual plus points) to everyone who votes this up!

Swift packets to you!

Rick Schroeder

34 Comments
Level 13

I can usually deal with those grayed out ports be deleting those interfaces and re-running list resources.  It is a manual process and would be nice to be more automated.

I found recently that it isn't just old ports that are not cleaned up.

Recently, our teams switched out an HP Procurve switch with a new Cisco switch using the same IP.  Of course, they didn't tell me they did this, I just kind of stumbled onto it when I noticed it was having trouble with the hardware resources.  Even after a rediscovery and poll now, the node details page said this was still an HP Procurve switch, but with Cisco IOS firmware.  Plus it couldn't figure out the hardware resources with a rediscovery.  I had to delete and re-add the switch.

It's nice to hear others are experiencing the same challenges that I am.

"Rediscovery" should really be complete.  Having to delete and re-add a node, even though model and vendor changes, should not be required.  Rediscovery should include checking the OID's and MIB's to ensure they are still appropriate for the node.  If different or newer MIBs and OIDs are more appropriate, they should either be used automatically, or noted for us to select manually upon rediscovery.

Level 13

I realize in a model or vendor change that these are big changes and almost need to be deleted/re-added because they are so different.  But that also means we lose historical information at the site.  Did the hardware upgrade help with CPU/Memory/Interface utilization?  Was there an improvement for the site/users? 

Maybe not all teams even care about this detail, I suspect our teams don't look at this, at least not through SolarWinds, but I always had an interest in this history.

Agreed, 100%!   It's a key factor in my search for a long-term data warehouse solution for Solarwinds.

Level 14

While I agree the "rediscovery" process could be enhanced, I think I'd prefer a process that discovers the new hardware and then alerts me of that change (similar to scheduled discovery jobs); giving me the option to accept that change. If an unauthorized change occurred, I'd have evidence to go head hunting. If it's an authorized change, I'm notified and the "accept" process would conduct a complete inventory and "list resources" that included the now defunct ports providing me a way to check/uncheck all the stuff I need. Still a bit manual, but also tracked and controlled.

In your case with 500 changes, I can completely appreciate an automated process, but then I put my security hat on and get nervous about unauthorized behavior. But I still voted this up!

Level 13

I do use an alert to tell me when the system detects a machine type change, but it sometimes misses changes, like the HP to Cisco switch change I mentioned.  It also misses some Cisco to Cisco model changes, but does better with those.

Level 12

Yeah, same issue can happen when you RMA an item.

I think I might know what you're referencing, but I'd love it if you'd care to expand on the experience you're talking about, regarding when you RMA an item.

Level 10

We recently have been upgrading many of our sites from S0/0/0 to G0/1 on our routers, so finding the ones that need to re-discover the interfaces has been fairly easy, but for 300+ routers, it was an entire day of my life I won't get back. Plus on the switch side, moving from copper to fiber resulted in another day of re-discovery. We recently changed out an entire stack of 3750 for 3850 in one of our corporate buildings - I ran re-inventory on the node object in NCM, I guess I better rediscover it also in NCM. It's a never-ending saga when equipment gets upgraded or replaced.

Level 16

I get the same thing whenever they change out cards/blades to a different type. I set up an admin page which is my home page when I log into Orion and built a view called 'Nodes with Problems' that shows these whenever I log in.

Need to manually fix it, but at least I see them right away. There is also another view that has a report of 'Audit Events' so I can keep track of when changes occur. It helps.