2 Replies Latest reply on Apr 29, 2014 3:04 AM by Ismo

    UDT Bugs x 2: Unmanaging a node, and MAC change/move TRAP notifications


      Has anyone else found problems with either of the following two scenarios:


      Scenario 1

      1. A node is currently managed in NPM and has all expected data in UDT,

      2. The node is then either unmanaged, or UDT polling is unchecked (in Node - Edit Properties - UDT Node Properties)

      3. All UDT data is deleted

      4. The node is re-managed, or the UDT polling setting is re-checked,

      5. UDT never polls the device again, and UDT data is never re-added.


      Scenario 2

      After enabling MAC TRAP notifications on a switch, and switch port, and seeing the TRAP notifications being received by SW, and ensuring that SW is set to process MAC notifications (in Settings - UDT Settings - Device Tracker Advanced settings - Mac-Notification Processing Interval), UDT never updates the MAC data for the switch.


      My purpose of posting the question here is twofold:

      1. To find out whether others have noticed these issues,

      2. Try and get a more concrete answer than "Our development team has identified it as bug and will be addressed in the future release.

      Unfortunately, the development team does not have an estimated date for the future release."


      The first bug was acknowledged four months ago, and is still not fixed.


      If others can add their support and comments that would be excellent.




      Damian Halloran

        • Re: UDT Bugs x 2: Unmanaging a node, and MAC change/move TRAP notifications

          My 3.0.2 issues:


          a) cannot cope with replies larger than a few KB

          [it uses getbulk, and there is nothing to say that the next blobs of data returned are not larger than this. The alternative is to switch to SNMPv1, or turn the number of repeaters in the SNMP request. Neither of which is a real solution. A fixed SNMP library is available for this]


          b) cannot cope properly with more than one poller

          the database design does not cope with contention between pollers, e.g. if a MAC address is seen on switches on different pollers and the update process deletes from one table, and inserts into another. This locks out one poller or the other. There is a fixed SQL stored procedure which helps, but really the design should be closer to a type-2 dimension (see Ralph Kimball's excellent work on data warehouse design). Updating an existing row to show that it is no-longer current is more efficient than moving data between tables IMNSHO. I suspect that there is still a timeout or deadlock that causes (c) below.


          c) the UDT business layer has a bug where if a database connection on a thread gets broken it never reconnects; the only fix for this is to restart the module engine. When you do that it will then be able to poll the devices. At this point it'll correct the job engine database (should probably fix scenario 1) [current open case since February 5th on this issue]


          d) the UDT business layer does not maintain the job engine database correctly -- what you're seeing in scenario 1. If you stop the job engine, copy the blank SDF file over the existing SDF file, and then restart the job engine then it'll start working again. restarting the ModuleEngine may also fix it...


          I dislike public gripe posts, since it is like a bratty child standing in a store screaming because they are not getting their way, but I've been fighting getting 3.x completely working for about four months as well, and frankly it's getting ridiculous.

          1 of 1 people found this helpful