As soon as I finished the install and was taken to Network Sonar- I knew this wasn't going to be what I was looking for. As with NCM, the problem here is that when you discover the network, UDT looks like it chews up elements like there is no tomorrow. I can't be positive, because I only run a 100 element license of NPM on my dev box, and despite assurances to the contrary, after running a small discovery with UDT I find that it wants to import 2000 more interfaces than my 100 element NPM license allows. So- so much for running this as a module within Orion. My problem with NCM, and what appears to be a problem with UDT is that while I don't want to collect data and manage every port in my network, I do need user tracking data for the entire network. Since it appears that I must monitor every single port, I would need 8-10 additional pollers over the 4 I already run to keep Orion happy with 7K elements per poller. Not going to happen.
I may back out this install and try a completely standalone installation to evaluate, but this is not what I was hoping to see after being quite vocal about the issue with NCM. I may feel differently once I run this as a standalone, but right now this is not only not a home run, but it never got off the bus into the dugout.
Sr Network Analyst
(1) Orion v10 SLX polling engine & Additional Web Server 35500 elements
(3) Orion v10 SLX polling engine
(3) NTA v3.7 775 interfaces
(3) IPSLA SLAX
After running the required Sonar discovery- the only ports that UDT is monitoring are the 412 ports that are on the 11 devices that were already in my NPM database. None of the 2000 ports discovered during the UDT scan are being monitored by UDT, because my NPM license will not allow them to be imported. This would not be an issue in my production enviroment, as I have SLX licensing there, but I am very concerned about chewing up elements in NPM. If I truly do not have to monitor the interfaces in NPM to gather UDT information about them, that would definitely change my opinion.
Took a while to figure out how to get around the license difference, but I was able to add devices to UDT and run scans. Definitely my error and not a limitation of the license.
Issue I am now having is while I do discover MAC addresses, I have been unable to see a mapping to the device IP address. Not sure what is going on there, unless UDT is having an issue in my multi-VLAN environment.
Have you added any Layer 3 devices to UDT? That is where we pull the IP information.
Jeff, does this mean all L3 devices (each switch's upstream gateway) also need to be added in UDT?
Yes, we need layer 3 information to correctly map MAC to IP. Without an IP address, we won't be able to create the hostname linkage either.
Regarding extrands posts, I just want to make sure it is clear to anyone who reads this understands. UDT is licensed by number of UDT ports. This has no impact on your NPM element count. For example, if you are monitoring 2 interfaces on a switch in NPM, then you monitor all of the ports in UDT, your NPM element count will still be 3 (two interfaces and a node). This is the reason we use the language of ports versus interfaces. In general, these are the same physical (or virtual) thing. A port is a UDT licensed element and we collect connection information from it. A interface counts against your NPM license and is used to collect utilization, traffic and error data.
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 150,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process.