CM 4.x: Ping sweep and UT host acquisition

[yjdabear]

Does anyone know the "acquisition" in the quote below is referring to Major Acquisition, Minor Acquisition, or both?

"When Ping Sweep is enabled, the UTPing program in $NMSROOT/campus/bin will be invoked during acquisition to send out a sweep of pings for each subnet."

It appears hosts that have short-lived or no IP ARP entries on the routers/layer-3 switches do not get picked up by UT.

[Joe Clarke]

Ping sweeps will be performed on major acquisitions and subnet acquisitions. The new dynamic UT feature in Campus Manager 5.0 will help with being able to obtain these short-lived hosts.

[yjdabear]

Could you explain how dynamic UT in CM 5.0 works?

Does CM 5.0 still impose the following restriction on ping sweeps?

"User Tracking does not perform Ping Sweep on large subnets. For example, subnets containing Class A and B addresses. Hence, ARP cache might not have some IP addresses and the User Tracking may not display the IP addresses."

Does it mean UT (in either CM 4.x or 5.0) will not ping sweep subnets such as 10.10.10.0/24 regardless of the subnet mask?

[Joe Clarke]

The class C or smaller limit still exists in CM 5.0. It will still ping sweep a subnet like 10.10.10.0/24 (if configured), however. Dynamic UT works by getting a MAC address notification from the switch, then trying to fetch IP information using DHCP snooping and user information using UTLite. The idea being that user additions and subtractions are reflected in the UT database in near-realtime.

[yjdabear]

What's the underlying mechanism for the switch-to-UT MAC addr notification? Can Dynamic UT retain its magic without either DHCP snooping or UTLite deployed?

[Joe Clarke · Accepted solution]

Dynamic UT relies on the MAC address notification traps from the CISCO-MAC-ADDRESS-NOTIFICATION-MIB. That is really the key. You can still get MAC updates (provided you're sending traps to the CiscoWorks server) even without UTLite or DHCP snooping.

[mnlatif]

We are running CiscoWorks on two Servers configured as Master\Slave from the Ciscoworks perspective.

Campus Manager is installed on the Master Server and DFM on the Slave Server. We are sending SNMP Traps only to the Slave Server (DFM).

I am assuming that for UT to work, we need to send SNMP traps also to the Master Server (CM installed on this) ?

If DHCP snooping is not configured on the switches, Can Campus manager get the IP info from the ARP tables on Routers ? If yes, then what is the advantage of using DHCP snooping ?

Thanks,

Naman

[Joe Clarke]

You do not need to send traps to the master if you configure DFM to forward traps to the master. Setting up Campus Manager for Dynamic UT is covered in the online help. It lists all of the supported configurations.

If you do not use UTLite or DHCP with DHCP snooping, then you will have to wait for the next UT acquisition cycle to run before the IP information will be updated for the dynamically found MAC addresses.

[yjdabear]

Is DFM a must-have for trap reception by CM UT? In other words, can CM UT receive traps without DFM installed?

Is there a corresponding "snmp-server enable traps blah" config that only enables CISCO-MAC-ADDRESS-NOTIFICATION-MIB traps?

Is the "next UT acquisition cycle" referring to a major or minior acquisition?

[mnlatif]

"snmp-server host X.X.X.X traps test mac-notification"

will only send MAC Notification traps.

As far as I know, DFM is Not a requirement for this functionality.

\\ Naman

[Joe Clarke]

No, it's not. But if you're sending traps to DFM, DFM can then forward those traps to a different server (e.g. the Campus Manager server). CM 5.0 listens for traps on port 1431 by default. So you can either forward traps from another NMS, or configure the devices to send traps directly to CM on port 1431. CM 5.0 also has a configuration wizard that will help you to configure MAC address notification traps on your switches.

[Joe Clarke]

The next acquisition refers to the next major acquisition cycle.