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

UDT POC

We are doing a POC on UDT. More specifically right now we are playing around with alerting if a new MAC address is detected. So that I don't run out of MAC addresses to test with, where in the db should I delete a MAC address that was already detected so I can use the same one for testing?

Find more posts tagged with

Accepted answers

All comments

rschroeder

Although I don't have the information you request, I would very much like to learn about your experience with UDT. I'm considering it for my organization, too.

designerfx

I ran a UDT POC. It's a fairly useful tool.

There are a few things to note.

1: It interacts with IPAM, some functionality is lost without that.

2: It easily retains HISTORICAL data of where users went, once you integrate it properly with AD.

3: It's not really a good security function, but you can easily shut/no shut a port as long as you have RW SNMP to bounce it.

So you can see " rschroeder was on port A from 8am-5pm monday but was on port B from 8am-5pm tuesday". Also that data gets stored and includes up to a year of history, which is invaluable.

We did an extended POC, having them give us more than 30 days to test.

shalinz

We just installed it last week, so still playing around with it. If all works well, then we are going to deploy in our PCI environment so that we get alerted anytime a new MAC address comes on network. Trying to get the alerting piece figured out. So far it detects the new MAC with no issues, but I am running out of laptops to plug in so that I have a different MAC to test with. If I can delete all references to the existing MAC, then I can get much further in our testing.

Radioteacher

I wish I could help you on that database location.

We have used UDT for location and security work for about two years.

UDT is now embedded in our processes.

We are not getting rid of UDT but since activating an 802.1X product I see the day that the process changes to do lookups there instead of UDT.

We can look by user, device and or port and have the visibility we need to solve issues. (or place blame)

rschroeder

We've been rolling out 802.1x through ISE bigtime this past six months, along with ACI in the data centers. But chasing & securing MACs & flows & port security isn't my primary goal here.

I'm interested in UDT primarily to keep our CMDB up to date, and to help me find every port connected to a specific type of device. For example, we use bar code label printers in many locations (they're called Zebra printers), and they don't get along with Cisco voice VLAN settings on switch ports--which are standard deployment everywhere due to users expecting to be able to use their VOIP phones on the network.

Manually chasing down hundreds or thousands of Zebra printers' ports is tedious; I'm thinking UDT would show me switch and blade and port info for every Zebra's MAC address. Maybe not?

rschroeder

I'd expect you to have ISE or at least sticky-MAC security in a PCI environment, and all non-active ports unpatched and administratively disabled.

Under what circumstances would you see new MAC addresses showing up in a PCI world, if they weren't authorized and allowed? Shouldn't strangers' devices automatically shut down the network ports when they're seen?

802.1x in PCI, or any flavor of NAC, would seem better than being alerted a strange MAC has shown up in PCI--by the time you can do anything, the perpetrator might have done their damage and been long gone. Or am I reading too much into this?

rschroeder

I like the idea--it sounds like it might do what I need/expect.

Can its information be exported into a third-party tool, like a CMDB from LANDesk?

Does it show the switch & port to which every MAC / IP address / device is attached?

I wouldn't need RW access via snmp to leverage its benefits, but I think that's kind of interesting if it can correct situations by automatically shutting a port. Still, I don't like/trust snmp RW on my network, preferring instead to force an admin to manually take action. I see too much potential for some catastrophic activity taking place if RW is enabled--and it might not have the right TACACS info or logging to detect who did what.

Call me paranoid, but at least when I'm surprised, it's usually pleasantly so.

designerfx

So yes , it'll see every item on a switchport: it will use LLDP and CDP, so that means switchport to phone to laptop will show up as phone and laptop on the same switchport. I'll pm you some screenshots.

Export no idea, never got to testing. There are some canned reports.

RW switch (port shutdown) is tied to manage node if I recall so it's not hard to lock down.. It won't even show up as an option for others.