Network Discovery: What Is It Missing?

I have, for a long while now, needed a simple way to add newly added (previously shutdown) interfaces to become monitored, configuring various settings (polling times, custom properties, etc.) based on a profile. This can be done by utilizing various Orion SDK API scripts, however, having a native process to accomplish this would be terrific.

I bit that bullet long ago and bought into NAM to enable me to monitor every port.

When Security said they all need to be shut down until an authorized device was patched into them, I showed them the cost of employee-hours to unpatch & patch ports in a hundred hospitals and clinics and business offices in three states, across 60,000 physical ports.

Security found it was cheaper to buy Cisco's NAC ISE to do the port shut/no-shut instead of sending bodies to patch/unpatch.

IT was going good until Cisco added new license costs for the things we wanted--and expected/assumed were part of the package.  Now, looking at the $1M upcharge for the features we want, we're still not manually patching/unpatching.  ISE does a basic job of discovering what's plugged into any switchport, and automatically prevents traffic from flowing to/from that device.

It gets a little confusing when compared to the old days; ISE leaves the port enabled "just enough" for the device to share it's MAC address, make a DHCP request, get an IP address, and respond to ICMP.  But not other traffic is allowed.  In the old days we could either ping it or not, and dispatch people accordingly to troubleshoot Layer 1.  Now, Layer 1, 2, and 3 are all working enough for DHCP and ICMP to do their jobs--but not so much that a rogue or malicious device could infect our network.

Troubleshooting this case of a switchport having link UP, showing a connected MAC address, and having the attached device using a DHCP address and responding to pings means more work for my guys if the device isn't working.  And ISE gets a bad name among the techs in the field.

Now we have to review RADIUS LiveLogs (included in Cisco ISE) to see if a device is allowed to use the network, to see how its authorized/authenticated, to see how it's been categorized.  We have to tweak ISE for that individual client device differently, depending on how it needs to work.  Some devices never need to get to the Internet, and we have a group for that.  Others need Internet access, so we may have to manually move a device into that group.  There are hundreds of devices . . .

You can see it might have been less expensive to devote a hundred techs to running around patching/unpatching 7x24 for years . . .

If API's work with SolarWinds modules and things like Cisco access swtiches, Cisco ISE, Cisco firewalls, Active Directory, Infoblox, etc, maybe we'll have a combination of API's that will replace Cisco's ISE.

Go GET 'EM, SolarWinds!

I will like if you don’t use API something like that frameworks for running tasks ..

For example:

run an disco on that group of elements  with CP “my access” I like only interfaces that start with “ge” and I will have that CP to those new interfaces..

But I sure like to  talk about  map discovery engine to work in a real world multi vendor network..

That the biggest problem I have with sw maps the discovery...

The new "map" is still need to use the   topology engine ...and that one could be better...

Topology related OIDs polled by the Orion Platform - SolarWinds Worldwide, LLC. Help and Support

I believe this thread was started because of some posts on yesterday's webcast, revolving around discovery problems. My issues have been resolved by a suggestion from the support team, which was to restart the 'SolarWinds Orion Module Engine' Windows service. Prior to that, I was having trouble getting discovery to work at all, and the same for the 'List Resources' feature on a node.

I sure agree to wluther​'s request, to allow us to set profiles (with more options like REGEX matching to interface types) of the interfaces we want to be automatically added upon RE-discovery. This alone is a big leap from what we currently have.

I'm glad to hear your issue has been resolved.

I'd love to tag all the nodes imported in a batch with some variable so that I can sort out further details on them or keep a longer track of how stuff has entered the DB than what the event log retention allows.

adam.beedell​ Ah, yes, that is a wonderful idea. I, too, would like better records when it comes to elements being added/removed/changed. I would really like to know who added the node, when it was added, and any time(s) it has changed since, also with user account stamps. I have experienced countless times where we needed something that SHOULD have been there, but was not... but actually WAS, only someone removed it. Perhaps that would tie into a more granular audit trail logging/tracking system. (another area of Orion which needs an overhaul) Different log retention levels, allowing more important, device/user specific, logs to last longer than the less important, "garbage" events.

Some of the stuff I would like to see included:

- A tab for VNQM  (configuring AXL credentials on CUCM's and automatically adding SIP trunks).

- The ability to select what stats are collected for interfaces to be imported (errors, availability and stats)

- A summary that would include also what was not discovered (if using a list of IPs for example). On multiple occasions I had to export the discovery results and correlate them in Excel with the IP list (sometimes 100+ IPs) to see what was not discovered.