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

Address Scans Seem Inaccurate

Hi guys and gals!

Do I need to have the DHCP servers in SolarWinds to get accurate info?

Some addresses show used on the server and available in IPAM.

Also when using public on some devices SNMP shows nothing even though public is listed for IPAM to use. No firewalls should be blocking this.

Find more posts tagged with

Accepted answers

All comments

jmbourn

I don't have access to our DHCP servers to compare to your issue, but IPAM also seems inaccurate to me. I'll have a user plug into an Ethernet cable and then a few minutes later I scan it with IPAM. The computer doesn't show up in IPAM, so I usually have them get me the IP another way so I can remote in. Sometimes I'll look for a machine that's been on that network subnet for longer periods of time with the same results, so it's not just recently connected devices.

We have a few known DNS issues that come up from time to time, but I thought IPAM acted independently. The crazy thing is, DNS and IPAM are both usually reporting incorrectly on the same machines, but sometimes they'll each have different wrong information. It's the weirdest thing.

mesverrum

IPAM correlates info from a variety of sources so it can be a bit of a hunt to figure out where you would find discrepencies. For one, it ping sweeps the subnets, but only if you haven't disabled it for that subnet (cannot tell you how many clients i have worked with where someone disabled scanning a subnet and nobody else knew until everything was wildly innacurate). If a node doesn't respond to pings it will be invisible to that method (default windows firewall rules often block icmp). You can also scan the dhcp servers for info, in which case IPAM will only ever be as accurate as your DHCP server, did you add them all into IPAM and are they all still working? It can also do what they call a neighbor scan where you point it at a router and it looks are the arp table there to try and fill in the blanks since even devices that don't ping will show up on the router tables, but that isn't usually turned on as it can be taxing on the routers to be coughing that much info up all the time. Then separately there is the SNMP scans, and there are countless threads on people who have problems with reaching their devices with SNMP. Any time I really want to get into why SNMP doesn't work I usually end up doing a packet capture on my polling engine looking for the node in question to see what's going on. Then another thing is that IPAM scans are typically only run every 4 hours, but could potentially be even longer, so displayed data can be stale.

Separately there is UDT, which many people buy together with IPAM but has a whole other collection of features where it'll try to correlate a user to an IP, i only bring that up since @jmbourn's post mentions trying to find users and ethernet ports, which is pretty solidly in the UDT side of things and uses an entirely different set of data which they try to display some of in IPAM, but UDT has it's own challenges with getting data.

When I was consulting I would say that 3/4 IPAM or UDT installs I ran into were missing big chunks of data but it was almost always environmental issues that we just had to work through with their team to ensure that everything was getting what it needed. If you learn how it gets the data and then confirm that all the appropriate channels are available in your environment the tool works fine. Most people barely know how it works so they end up with significant gaps.

jmbourn

@mesverrum That's great information. I will look further into this based on your reply, however I can tell you that my environment has some of the same issues I face with IPAM, but I honestly thought it worked independently. Looking at it through the lens of information you have provided, I can almost guarantee now that my incorrect information is brought on by the environment instead of the utility.