I've had UDT for a year. It looked quite promising, but it's turned out otherwise and I've had to shut it off due to it not providing timely and accurate information, and due to it causing so many snmp-GETs that it results in a DOS on 6509 Distribution switches.
- Most of my access switches were Cisco 2960S models. Their local memory and CPU resources proved drastically underpowered to accommodate our deployment of Cisco ISE and SW UDT. The switches were so overwhelmed with all the SNMP queries and ISE activity that I had to keep pushing my UDT polling schedule further and further away from the default--which was already a longer time than tracking wireless users and their devices needs. After setting the polling cycles so far apart it became obvious UDT wasn't useful for tracking laptops or wireless devices. I've spent the last year doing forklift upgrades of the 2960S models, replacing them with 8350's and 9348's. I'm hoping to start up UDT again on those units, along with polling my 2960X's and 2960XR's and 4510's, but I'm not confident the experience will be a positive one.
- UDT isn't compatible with SNMP-v3. All of my systems were happily running on snmp-v3 and none of them were providing UDT information because UDT can't work with encrypted v3 data. I had to reconfigure all my access switches, distribution switches, wireless controllers, layer 3 switches, and routers to use snmp-v2. Company security policy mandated that ACL's be applied to all of those nodes that restricted snmp-v2 access to my pollers and my team's workstations. That was loads of work I didn't need, and wouldn't have had to go through if UDT worked with snmp-v3 community strings.
- Router or L3 node changes. I regularly replace aging distribution switches and routers with newer ones, and that's proven an Achilles heal for UDT. I've not yet found a place in its documentation that defines how it interacts with routers & layer three distribution switches, and I've hoped that simply monitoring those nodes with NPM would suffice to provide UDT with the ARP information it requires to track devices on the access switches below the L3 equipment. But when I replaced a VSS pair of Cisco 6509's with a VSS pair of 6807's, ensuring that both the old AND the new equipment was monitored in NPM, I found UDT data about switches below those devices quickly became stale. It seems that UDT lost where to look for the ARP information when the routing interfaces moved from the 6509's to the 6807's. I'm not sure why since both sets of nodes were monitored in NPM. Should I have also added the 6807's to UDT's monitoring? I don't think that's necessary since no access devices are using any ports on the 6807's. Those VSS chasses only serve as the L3 routing hardware for many L2 access switches below them. Wouldn't UDT automatically know that the 6807's contained the data for the thousands of computers attached to the access switches that uplink to the 6807's?
- User tracking. I've had political challenges getting UDT access into the AD world, resulting in an inability to track users by login name. Yes, it's a local problem, not SolarWinds' issue, but it seems like it would be an intuitive step to let UDT automatically access everything it needs in the Active Directory servers without requiring large amounts of input and actions by the AD administrators.
Since my initial deployment of UDT over a year ago I've replaced my SolarWinds server and database infrastructure by moving all to 2016 versions. I've also upgraded to the latest Solarwinds Orion Platform 2018.4 and NAM 2018.4 and i look forward to turning UDT back on with better results due to the upgrades. But I'm not certain this will be the case.
So let's get back to my original question about routers, which also pertains to L3 switches that do routing or function as distribution switches to the VLANs on the switches below them.
- Does UDT require a router be defined for every VLAN?
- If so, where does one tell UDT about the routers serving each switch?
- If UDT doesn't require a specifically defined router or L3 switch for the VLAN's on access switches, how does UDT know which nodes hold the ARP info for every VLAN on every switch?
- Where does UDT go to understand which L3 node should be queried for any PC or workstation being routed by that L3 node?
- SNMP-v2 or v3 for routers and L3 Distribution switches:
- Does UDT require snmp-v2 access to every router?
- Can UDT get its device and user tracking jobs done via snmp-v3 community strings for routers & L3 switches?
- What can be done to reduce the strain UDT puts on switches or routers with CPU and/or memory resources that should be sufficient to UDT's needs--but that aren't?
- I discovered my 6509 Distribution Switches acting like they were experiencing an snmp-get DOS attack from all the queries they received from UDT and other network node discovery tools (e.g.: like Printuition, which polls all IP addresses on the network to discover printers. We have ~8,000 network printers, and keeping up with their paper and toner and service needs requires an automated tool like Printuition). When I replaced the 6509's with 6807's I saw the newer L3 distribution switches could handle the snmp query onslaught better than the 6509's.
- How does one ensure that any L3 switch or router isn't overwhelmed with snmp-get requests from UDT while simultaneously ensuring a current and valid UDT database remains available for my staff to query and watch and manage?
- What are the results of enabling UDT to manage ports on a switch for which UDT is not specifically set to monitor the upstream router or L3 switch?
- Will UDT simply understand the next upstream router from an access switch will hold the ARP info for PC's & printers, and query that upstream router via the snmp-v3 strings used by NPM to monitor that router?
- More and more of my remote sites rely on non-traditional routers for WAN connectivity. In some cases they use Cisco 5506's for BGP WAN routing, and those same ASA's provide local routing for computers at the side. In other cases 8350 or 9348 switches have L3 services enabled and are functioning as the routers for nodes below them.
- Will UDT accurately discover nodes beneath an ASA 5506 that's working as a router?
- Will UDT accurately discover nodes below a 3850 or 9348 switch with L3 services enabled to make it a router for the switches and computers below it?
- A number of sites rely on L3 routing & distribution to come from Cisco Nexus 5548 switches. I've had challenges with Nexus playing well with Solarwinds. Will UDT be able to properly function if routing has to come via Nexus 5548's?
I need to get my investment back from purchasing UDT, but my team is moving to other best of breed solutions that don't stress our network switches or routers, and that do what we expected UDT to do--at a lower price point.
All honest and helpful attempts to assist will be appreciated. I'm betting that if marcoswithanoh can't help me, he knows who can, and he'll draw their attention to this query.