LMS4 Usertracking contains allmost no IP Adresses

[STEFFEN NEUSER]

Hello,

Needs help in LMS4-Usertracking, where I can see all attached endstations by MAC-adresses only, but not with its IP addresses.

The problem there is no Cisco Layer-3 device (DGW is not managed by LMS) so we need pingsweep urgently to get IP addresses for the endstations as well. But allthough we set pingsweep for all subnets, a wireshark trace shows that LMS ignores this setting. LMS just does the SNMP queries to the switches but definitly no ping(sweep) to the endstations.

How we can LMS enforce to make the pingsweep, that we get the IP informartions into usertracking as well.

thx, Steffen

[Joe Clarke]

If there are no Cisco layer 3 devices, then ping sweeps will not help.  The way ping sweeps work is to ping the subnets to populate the router ARP caches.  Without any managed L3 devices, you will not be able to get IP addresses from the network.  You can, however, get IP addresses if you are using UTLite on the Windows end hosts.

[STEFFEN NEUSER]

Hi Joseph,

Thx for your answer. But why we've got 15 IP addresses from nearly 400 endstations? This must be exactly this IP addresses we got after the initial discovering in April.

It seams that it will be working with IP-addresses and no managed L3 devices - how ever - just one time after the initial discovering and after this no more. If this behavior is an coincidence, how could we reproduce this coincidence to can help this customer.

Steffen

[Joe Clarke]

There is no magic at play.  In order for IP addresses to show up in UT, there must be a managed L3 device known to Topology.  This need not be a router.  It can be an L3 switch such as a 3560, 3750, 6500, etc. Therefore, when UT was first deployed there must have been such a device.  Either that, or the device still exists, but it only knows a portion of the subnets.

However, if there are no such devices in the network, then the only way for UT to learn IPs is for you to use UTLite or enable dynamic User Tracking and enable DHCP snooping on the switches.

[STEFFEN NEUSER]

We've got C4510R-E devices only in this network, configured as plain L2, but the default gateway (DGW) of the endstations is not a Cisco device (therefor not managed in this LMS).

The magic play at initial discovering could be the coinsidence, that the new network was built up on the same weekend, when LMS was installed (not from myself) and for testing issues this 15 IP adresses was pinged from the switches and kept long enough in the ARP-cache of the switches, that the LMS was using that ARP-cache for the initial discovering.

For understanding the IP resolution process in UT is this right?

1. LMS does NOT use the local ARP-cache in UT-Major-Aquisation at the LMS-server itself (missed chance)? So a Ping Sweep in device discovering (customer was set up a /22 range for DCR discovering due missunderstanding of the product) cant influence the IP-resolution in the UT-Major-Aquisation.?

2. LMS uses the ARP-cache of known L3 devices. But the ARP-cache at this devices could be filled up only with end stations that are routed (not L2 switched) over this devices?

3. For DHCP-Snooping: Does LMS is using the DHCP binding table directly or does LMS rely on that DHCP-snooping will bring DHCP discovered end stations into the ARP-cache of the switch making DHCP snooping as well?

4. Ping-Sweep in UT-Major-Aquisation is intended to force IP-communcations to all interesting (those are located in atteched IP-networks) end stations with the aim to reach completeness especialy with seldom speakers as well, for instance to wake up them short before the SNMP-queries to the devices will be started?

For plan-B: If the mechanism with DHCP-Snooping will not work in this network, could an EDM-script containing a pingsweep to the 2 L2-network's triggered by a kron job (short before the UT-Major-Aquisation will start) at one of this switches with setting the ARP-cache timeout at the same value as the UT-Major-Aquisation interval be a good workarround?

Steffen

[Joe Clarke · Accepted solution]

The 4500 switches can be used for ARP retrieval provided they're configured with "ip routing".  UT will look at the ipForwarding object via SNMP to see if routing is enabled.  If it is, then the ARP table will be retrieved from the switches.  If not, even if they have ARP entries, UT will not look at them.

No, UT does not use the LMS server's ARP cache at all.  UT will retrieve the DHCP snooping table directly via SNMP.  Yes, the ping sweep is designed to populate ARP caches on L3 devices as well as find those quite talkers that may have dropped out of CAM tables.

EEM will not help here if the switches are not configured for IP routing.  If everything is truly flat and end hosts are on the same subnet as the management IPs of the switches, then you could enable IP routing just so UT can get ARP entries.

[STEFFEN NEUSER]

thx for your very detailed reply, It was very helpful to understand the real behaviour of UT in extreme situations, Steffen