CM 5.1.3: Who controls User Tracking Minor Acquisition?

[Martin Ermel]

Minor Acquisition handled by process UTMajorAcquisition?

I want to know which process handles the minor acquisition in UserTracking and if the run status can be acquired from cli.

I observe the following in LMS 3.1 - CM 5.1.3 on windows 2003. It is the same machine as mentioned in this thread:

Major Acquisition is scheduled to run daily at 08:30 am. (It needs approx. 1h 15min to complete, max is 2h 15min)

Minor Acquistion is scheduled to run every 100 min. Thus it will start at 10:10 am.

in the GUI going to Campus Manager > User Tracking > Acquisition shows the "Acquistion Information" Table. When the Major Acq. has finished the table shows all the information and has "Major" as a value in the "Acquisition type" field . At 10:11 am the Start time gets updated with this timestamp and the Type field changes to "Minor". When this process finishes all fields gets updated accordingly. (also the "Last acquisition time" on the CM Home page).

While both these processes are running, "pdshow UTMajorAcquisition" shows the status as running as well.

Because the Minor Acq. is scheduled to run every 100 min. So I expect to see the "Acquisistion Information" being updated every 100 min. But I cannot see these updates, nor can I see the UTMajorAcquisition process running again before the next day at 08:30 am.

So I am wondering how this UTMajorAcquisition of type "Minor" can be interpreted?

1) Is the Minor Acquisition in fact a sub-process of UTMajorAcquisition ?

2) Why does only the first Minor Acq. report its Start/Stop time

3) How can I control that the Minor Acq. is running correctly (beside the fact that the "LastSeen" field gets updated)

4) How is the period of the Minor Acq. be handled - is it added to the start time of the Major Acq or to its end time?

5) What happens if the Major Acq. is still running when the Minor Acq. should start? Will this instance be delayed to run later or will it be ignored?

I did not see this in LMS 3.0.1 (don't know the exact patch level of CM by heart right now)

[Joe Clarke]

All UT acquisitions are started by ANIServer, and run within the scope of UTMajorAcquisition. It's important to note that minor acquisitions only operate on devices which have been seen to have changed in the last Data Collection or polling cycle. So it's entirely possible that minor acquisition dies before it even starts if no changed devices are found. In that case, the following message would be seen in the ani.log:

No devices to run UTMinor. returning...

Assuming vmpsadmin debugging is enabled for Data Collection.

Minor acquisitions are subservient to major acquisitions. If a major is running, minor will abort before starting. If NO major acquisitions have run, minor will abort before it starts. The timer for minor acquisition runs continuously within ANIServer. A new minor will start 100 minutes after the last provided none of the above restrictions are met.

[Martin Ermel]

this is very interesting information!

Which changes take into account to mark a device as changed? Data Collection does the full evaluation of a device - so this process can clearly detect any change. I think Major acquisition collects information about vlan, subnets, ports, MAC addresses and arp caches - so a change of UT relevant information will be detected. But what does polling? I assume it is the device polling in Campus which is set to be 2h per default - I thought it just checks the "still alive" status of a device by asking the SNMP agent something like the sysObjectID or sysName? Which UT relevant SNMP queries does it perform to put a device on the list for a minor discovery?

Is it correct that when I see only 1 minor acquisition in the "Acquisition Information" table over the whole day that only 1 minor acquisition was really running? Or does not every minor acquisition report its state in the same way?

Is it correct, that only the minor acquisition that starts right after a major acquisition reports to the GUI (or changes the Start/Stop field in the pdshow output of UTMajorAcquisition)

[Joe Clarke]

Any change which is detected by Data Collector or devices and links polling will add that device to the queue for minor acquisitions. For eample, if there is a link change on a switch, that switch will be added to the queue. There are no UT-specific queries performed. The standard set of Data Collection and reachability polling is performed.

Every minor acquisition will update ANI with its state IF the minor acquisition. A minor acquisition will NOT update time information if one of the following conditions are true:

* A major acquisition is already active

* ANIServer is not in a ready state

* The first major acquisition has not been done

* There are no devices on which to perform a minor acquisition

* There is an error writing the list of devices to acquire to the params file

I'm betting what you're seeing falls into the category of no devices available for acquisition.

[Martin Ermel]

Oh, - I won't bet about this point! ;-)

I also have got the feeling that there is no device change detected and the minor acquisition is not performed.

But why? Is there really no change or are the settings 'sub-optimal' so a change cannot be detected? There are 300 devices in the network and at least 3000 end-users.

- Major Acquisition is scheduled to run only once per day at 8:30 am. This process does detect a change and consequently a minor acquisition is started right behind. While the Major Acquisition is running no adhoc queriey can be done in UT (no response in the GUI) and starting a utcli command at this time fires up User Tracking. So there is no will to let it run more then once a day.

- I will ask for the Data Collection schedules tomorrow. I guess there is also only one scheduled job for this....

- Polling is set at 2h. But I assume it does only poll for changes on uplink ports (those ports which are on one end of a link in the topology map). If this interpretation of the "polling" is correct, then there are nearly no changes over the day. And thus, there is only one minor acquisition performed.

Does a minor acquisition reported its state to ANI before CM 5.1.3 as well? - I haven't had an eye on this before...

[Joe Clarke]

Yes, device and link polling only polls the link ports seen on the topology map. Minor acquisition has worked the way I described since Campus 5.0. Personally, I would disable minor acquisitions altogether. They don't really buy you much. Instead, I would use major acquisitions with dynamic UT to keep UT up-to-date.

[Martin Ermel]

Ok, thanks for this details!

Do you know of any issues with utcli while a major acquisition is running or that the UT > Reports runs forever while a major acquisition is running?

Perhaps this is related to the problems I found with dynamic updates on this server. I still did not resolve or further investigated this issue - I just unregisterd MAUHIC to workaround the problems.

This is the same installation as mentioned in this thread:

http://forum.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Network%20Infrastructure&topic=Network%20Management&topicID=.ee71a02&fromOutline=&CommCmd=MB%3Fcmd%3Ddisplay_location%26location%3D.2cd3493f

[Joe Clarke · Accepted solution]

No, I haven't seen this. And I certainly can't reproduce. I did a ut -cli job with -query all while a full major acquisition was running, and it returned results immediately.

[Martin Ermel]

thanks for your tests!

I also wanted to retry it again today but had no time to do it. It would be interesting to see if they are running fine now. After unregistering MACUHIC I haven' t tried it again.

You were absolutely right with the minor acquisition! Data Collection was scheduled to run once a day at 8:00 am and there are no changes on the uplink ports which could be detected by polling. So the device list for minor acquisition was empty. Creating a new Data Collection job at 12:00 updated the timestamp for UT on CM > Home as well as for "pdshow UTMajorAcquisition". So clearly shows that a minor acquisition was started!