16 Replies Latest reply on Jun 26, 2018 7:26 AM by nickzourdos

    UDT fundamental problem causing issues.  (MAC Move)

    Craig Norborg

      We're evaluating UDT for tracking the movement of IP phones on our network.   I'm playing in my office with a couple switchports and Raspberry Pi's to simulate this.   It seems to be very inconsistent in whether it works or not, and tends to be usually NOT working.

       

      Trying to figure out what’s going on, there seems to be some inconsistencies.     One thing that’s bugging me is something I’m seeing in the Port Details in UDT.    I have 2 ports in my office that I’m using, there is no switch/hub hooked into them, so at the most I should be seeing a single MAC address on the port at any given time.   However, UDT is reporting multiple MAC addresses on them.  I have confirmed via the command line that at the time of this polling there was a single MAC address on the port.     Furthermore, one could argue that if a port is “down” that there should be no “current” MAC-addresses on the port.  Now, it might take a little time for the switch to age out the MAC address from its table, but no more than 5 minutes.   But even when Orion is knowing that a port is down for quite a few polls, it’s still showing MAC(s) on the port.    To me, both of these are telling me that UDT is not actually reflecting the current state of the port, which is bad.   

       

      This seems to be causing issues with the “Port History” shown here also.   Of the 3 MACs on Gi4/0/10, only the one ending is 17:7D is current. But yet both switchports, the one that is UP and the one that is DOWN, are showing multiple MAC as being “CURRENT” in the “Port History”, not good.

       

      esw-03-1498-253-1#sh mac address-table int g4/0/10

                Mac Address Table

      -------------------------------------------

       

      Vlan    Mac Address       Type        Ports

      ----    -----------       --------    -----

      231    b827.eb79.177d    STATIC Gi4/0/10

      Total Mac Addresses for this criterion: 1

      esw-03-1498-253-1#sh mac address-table int g2/0/5

                Mac Address Table

      -------------------------------------------

       

      Vlan    Mac Address       Type        Ports

      ----    -----------       --------    -----

      esw-03-1498-253-1#

       

      But as you can see, its showing this MAC as active on two different ports on the same switch. This should never happen, a mac address-table on a switch associates a given mac to a single port.   But even though gi2/0/5 is down and Orion knows it is, it’s still registering the same mac on two different ports of the same switch. Not good.   The port that is down should show no current MAC addresses.

       

       

      I think this is what is causing issues with the MAC MOVE alert.   I was going to write a custom report to show the MAC’s that had moved in the previous day, and while working in SWQL studio I saw the following. When I looked for the MAC I’m playing with, it shows as being “IsCurrent” on two different ports at the same time on the same switch.   Once again, bad.   You can also see from here that the operational status on one of the ports is “2” which is “DOWN”.   A “DOWN” port shouldn’t have any active MAC’s for any extended period of time.

       

      To me it looks as if the port goes from an UP to a DOWN state, that all MAC’s on that port should stay in the history, but not be current.   If the port goes active again with the same MAC it had before it went down, you could remark it as active without adding another entry into the history. That I’d be ok with.  But leaving so many active I think is confusing the mechanics of things like the MAC move report.

       

       

      This seems to be a fundamental issue with UDT not reflecting the current status on a port, whether it be UP or DOWN.

       

      Anyone else experiencing these issues?    In our environment we have NPM 12.2 and UDT 3.3.0.