Showing results for 
Search instead for 
Did you mean: 
Create Post
Level 11


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.

Steve Extrand

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


0 Kudos
6 Replies
Level 15

UDT doesn't require you to monitor the interfaces within NPM to monitor the ports within UDT.  You can also pick and choose which ports you want to monitor within UDT.

0 Kudos

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. 

0 Kudos

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. 

0 Kudos

Have you added any Layer 3 devices to UDT?  That is where we pull the IP information.

0 Kudos
Not applicable

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?

0 Kudos

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.


0 Kudos