The discovery takes long time in LMS3.1

albatli1977 · ‎08-02-2009

we have LMS3.1 CS3.2m the discovery takes more than 4 hr, in the old setup LMS2.6 took 1hr only

I used only cdp protocol with DCR as seed devices.

please find below the configuration of discovery as shown in the summary :

Module Settings

Module(s) Selected: CDP

Seed Device Settings

Module Seed Device File Use DCR As Seed Seed Devices [Hop Count / Subnet Mask*]

CDP Yes

*Subnet Mask is applicable only for 'Ping Sweep On IP Range' module

Global Seed Device Settings:

Seed Devices:

Seed Device File:

Use DCR As Seed: Yes

SNMP Settings

Version User Name Auth Algorithm Priv Algorithm Timeout Retry Target

v2c 2 2 10.*.*.*

v2c 2 2 172.*.*.*

v2c 1 2 10.*.*.*

v2c 1 2 172.*.*.*

Note: User Name, Auth Algorithm and Priv Algorithms are not applicable for SNMP versions v1 and v2c

Filter Settings

Filter Type: IP Address

Filters(include) : 10.*.*.*, 172.*.*.*,

Global Settings

Preferred DCR Display Name: FQDN

Preferred Management IP: Use LoopBack Address

Update DCR Display Name: Yes

Use Default Credentials: Yes

ICMP Timeout: 1000

ICMP Retry: 1

InterPacket Timeout: 20

Email:

Add Discovered Devices to a Group: No

Selected Group Name:

Joe Clarke · ‎08-02-2009

These settings look good. I suggest you contact TAC to have them walk you through enabling CSDiscovery debugging and analyze the ngdiscovery.log to see where the time is being spent. Typically we see problems due to high timeouts or retries. That may still be a factor here, but your values are probably low enough to avoid huge delays.

albatli1977 · ‎10-11-2009

please find an attached the CSDiscovery-config.xml, i see some difference between CSDiscovery-config.xml and GUI configuration

Joe Clarke · ‎10-12-2009

As I said, I see no problems in your settings. You should open a TAC service request so additional debugging can be enabled, and Discovery can be analyzed as it runs. My initial thought on why it may be taking a long time is that you're using a sysObjectID filter. This means that Discovery must contact every device it finds with SNMP before it can apply any filtering. If the device is not SNMP reachable with the given community strings, you will encounter delays. If you want to try and rule that problem out, consider applying an IP address filter instead.

Martin Ermel · ‎10-12-2009

have you also checked the settings for your scheduled discovery jobs in

Common Services > Device and Credentials > Device Discovery > Discovery Scheduled

albatli1977 · ‎10-12-2009

Yes, every Saturday

Martin Ermel · ‎10-12-2009

I meant if you have checked the settings for scheduled discovery job and not only for adhoc discovery?

Adhoc discovery settings are

Common Services > Device and Credentials > Device Discovery > Discovery Settings

(these are the settings used for an adhoc discovery job when clicking on "Start Discovery" ond the "Device Discovery" page)

Each scheduled discovery job does have its own settings when you go to

Common Service > Device and Credentials > Device Discovery > Discovery Schedule

mark the job and click "Edit Settings". These settings can be completely different from the before mentioned

If you create a NEW scheduled discovery job, the current settings from the adhoc discovery are used for this job (and can later be changed by going through "Edit Settings" for each job).