How do you resolve missing mac addresses?

Question

We have some specific IoT devices that are pretty well locked down. To the point where we get pretty much no information from them in IPAM, other than the fact that the IP address is in use. We would really like to get mac addresses from these devices, and switchport details would be nice as well. 
 We do have UDT as well as IPAM, and naturally UDT has the opposite problem; we scan the switch to which these devices connect and we of course can see the switchport and mac addresses, but we get no IP addresses in UDT. It is a layer 3 switch, and we get mac and IP address information fine from other types of devices without any issue. I have done some SNMP queries, and have confirmed that the arp table is quite accessible via the OIDs these products use for scanning. It would just be really nice if the two products were able to correlate this data. 
 I have turned on neighbor scanning for the affected subnet (fortunately, it's mostly all within a single subnet), but that brings its own issues. IPAM does indeed retrieve the mac addresses through neighbor scanning, but the next subnet scan overwrites them so they aren't readily available (other than via history). We have both automatic scanning and neighbor scanning enabled; should these be mutually exclusive? The documentation is, of course, quite sparse on these kinds of details. 
 
 The department responsible for these devices would really like to get the mac addresses to aid with identifying and tracking these devices. So, I guess I have a couple of questions for the community: 
 1. Is there any way to correlate mac addresses and IP addresses between UDT and IPAM? The information is all there; we just need a way to bring them together, preferably in both products? If not, does this seem like a reasonable feature request? 
 2. Neighbor scanning seems like a potential solution here, but should automatic subnet scanning be disabled for it to be useful? If so, this really needs to be documented. In this case, it may be reasonable to ONLY use neighbor scanning, but I could see this being problematic for subnets with a wider range of devices. 
 Thoughts? Just trying desperately to come up with some solutions for this quandry, and hopefully gain some further understanding of how these products should work. 
 Thanks.

donrobert5 · Answer

The difference between IPAM and UDT is that the most basic information in IPAM is the IP Address while in UDT it would be the MAC address. 
 It seems you already sorted this out, but in order for UDT and IPAM work together, It needs to be able to gather and relate those information. 
 In IPAM, it needs to be able to see the MAC address on it's own. In UDT, it also needs to be able to resolve to the Proper IP Address. 
 Once those information are populated on both Modules, that's when they can relate those information.

mesverrum · Answer

The simple answer is you need to frame your mind that UDT and IPAM can't actually source data from each other. There is only the most minimal amount of crossover. Makes more sense when you consider that they were both developed entirely separately so the devs couldn't assume that someone had both modules until someone in marketing decided to start pitching them as a bundle and then ultimately rolled them into the new licenses. The way they are marketed and sold does not reflect the way they were built. I think it's a good feature request for them to integrate the two much better, and with the way they are licensed now it really doesnt make sense for them to remain separate anymore, but thats also kind of a big project in terms of how both of them work at this time. At the last company I had where we had both products I did some pretty heavy editing of the UDT endpoint views and got them where they would more clearly cross reference against all my other modules, but I don't have a copy of that handy to share anymore. It was just a bunch of Custom Query widgets combined with me spending a lot of time crawling through the db tables piecing together whatever I could find that looked useful. 
 
 So getting to your number 2, yes neighbor scanning should help assuming all the pieces come together. Neighbor scanning and automatic scanning arent really related. Automatic scanning controls if/when the poller does a ping swing through the defined IP's and tracks if it gets responses or not. Some people dont want all those ping sweeps all across their network, or they are documenting subnets that the poller wouldn't be able to reach so they disable it. 
 Without neighbor scanning IPAM is hoping it has SNMP access to your device. Frustratingly related to that lack of integration I mentioned this scan has to happen within IPAM, which has its own collection of SNMP creds that it can't just inherit from all the other places where you would have already defined them. IPAM wants to do l2 and l3 discovery against every IP, even though NPM and UDT are also doing those exact same SNMP requests as well and writing the data to different tables. Neighbor scanning kicks in when you can't SNMP poll the device for some reason, but you have to specify the IP of a device that would have the mac address in the arp table. Given that UDT works for these macs you know you can get this data, its just going to be a matter of making sure your config is all correct inside IPAM for it to put it all together. 
 https://support.solarwinds.com/SuccessCenter/s/article/How-IPAM-gets-a-MAC-Address-via-SNMP?language=en_US 
 https://documentation.solarwinds.com/en/success_center/ipam/content/ipam-neighbor-scanning.htm 
 
 Getting into the land of just hacking things up, in my past environment when I had discrepancies like this I once disabled all those kinds of topology polling in UDT and IPAM that all try the same OIDs and I used SQL queries to vacuum all the data I wanted out of the NPM topology tables and inserted it into the relevant tables in other modules. Worked well for that environment and cut back on extra loads in my pollers and the target devices.

How do you resolve missing mac addresses?

Top Replies