cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1119
Views
15
Helpful
16
Replies

CSDiscovery: still not understanding the details 'Use DCR as Seed List'

Martin Ermel
VIP Alumni
VIP Alumni

I still don't understand the consequences of the Discovery Options 'Use DCR as Seed List' and 'Hop Count'

How does they work in detail?

Cisco says in LMS 2.6 and below all devices in DCR where used as a starting point for any Discovery Cycle after the first initial Discovery. Only for the first initial Discovery the Seed Device List (manual added or import from a file) was used to populate devices into DCR. After that any device from DCR was used for discovery of additional devices. Restriction for discovery could be done only by Discovery Filters and the option 'Jump Router boundaries';

But the discovery process changed in LMS3.x ...

Does CSDiscovery now only use Devices in DCR as seed devices if this option is enabled? If yes, which purpose does it have? Will it cause all Devicves in DCR to be populated in to the list of seed devices? Will it speed-up the disco process?

On the other hand, if this option is not enabled which consequences does it have? Will only the devices listed as seed devices in 'Seed Device Settings' (Global or Module settings) be used? - could this slow down discovery?

The same is with HOP count: how will CSDiscovery behave if there is e.g.a HOP count of 3?

If I look at the 'LMS Workflow Demos' from LMS 3.1 it says 'Router Hops'- another person told me it is the diameter - which I understand as a 'device hop' (regardless of device type) and which could be a significant difference.

Together with the option 'use DCR as seed list' it seems to be useless ...or hard to understand (at least for me...)

Think of the following simple situation:

10 devices in a row (dev1 - dev10), CDP is enabled;

CSDiscovery has the following config:

discovery module: CDP

seed device: dev1; hop count:3

use DCR as Seed List: yes

no Filters

Now I have different options how disco could work:

Option 1:

the first disco cycle should find exactly 3 devices (dev1 - dev3)

the second disco cycle should start with dev1, dev2, dev3 as seeds and finds dev4 - dev6 as new devices

the third disco cycle should start with dev1-dev6 and finds dev7-dev9

and so on..

(which means the hop count applies to all devices found and added to DCR but in fact does not really restrict discovery but instead interferes with it)

Option 2:

the first disco cycle should find exactly 3 devices (dev1 - dev3)

the second disco cycle should start with dev1-dev3 and finds dev4 -dev10

(which means the hop count applies only to dev1, but because of 'Use DCR as Seed List' there is no Hop count definied for dev2 and dev3 - which means it is not restricted- so it finds all devices)

Option 3:

the first disco cycle should find exactly 3 devices (dev1 - dev3)

the second disco cycle will not find any new device

no subsequent disco cycle will find a new device

(which means Disco will start with dev1-dev3 find at least dev4-dev6 but drops all because the Hop count of dev1 restrict the addition to DCR - for any device included and behind dev4 )

Option 4:

the first disco cyle finds all devices

(which mean for dev1 it is restricted to 3 hops, but not for dev2 and dev3 and thus it finds all)

(or it is a router hop count and because of dev1-dev10 beeing in the same IP segment it does not have any effect..)

or is it completely different?

depending on how it really works I could think of some (great?) performance degredation caused by the ongoing and perhaps useless calculation of the Hop count...

As well 'Use DCR as Seed List' could have an impact on the number of parallel threads CSDiscovery uses.

ANY CLARIFICATION AND COMMENT ON THIS IS GREATLY APPRECIATED!

1 Accepted Solution

Accepted Solutions

Correct. The DCR seeds do not have a hop count associated with them.

View solution in original post

16 Replies 16

Joe Clarke
Cisco Employee
Cisco Employee

I can't answer this message inline, and there are a lot of questions here. I'm going to tackle the first, then you can ask each additional in a different post so nothing gets lost.

Use DCR as seed works as you expect. All devices known to DCR (and their DCR credentials) are used as seeds for Discovery. This can speed up Discovery as Discovery is multi-threaded, and it can operate on more than one device at the same time. Additionally, since DCR has (presumably) tested credentials, Discovery doesn't have to re-test multiple configured credentials.

The hop count option tells the various Discovery modules (like CDP) to only go so far in the network when discovering. For example, a hop count of 2 will only discover devices that are at most 2 hops from the seed. To emulate pre-LMS 3.0.1 Discovery, the hop count should be omitted.

OK, I will try to go step by step ...

So these assumptions should be correct:

with 'Use DCR as Seed' enabled

1) CSDiscovery pulls the devices with credentials from DCR and starts polling the device 'directly'

2) it starts with the maximum number of threads for every configured module

3) for newly discoverd devices the credentials must be evaluated

4) for devices beeing in DCR but beeing currently 'unreachable' the credentials are evaluated again (this would be great but I don't believe this is truth... ;-) )

with 'Use DCR as Seed' disabled

1) CSDiscovery (for each configured module) takes the devices from the seed list (module and global)

2) for the seeds it also takes the credentials from DCR

3) if a device is not a seed device it must evaluates the credentials

4) it starts with a number of threads equal to the number of seeds per module (or the max if there are enough seeds defined)

5) the CSDiscovery process will generate up to the max number of threads the more devices are found (thus it could speed up)

OR

does disable 'Use DCR as Seed' interfere with multi-threading?

Now the Hop count...

1) it is bound to a seed device

2) a new discovered device must be inside the hop count of a seed device to be added to DCR

Question:

- are new discovered devices tested against every configured module?

- or only inside the module which found the device ?

A DCR seed whose DCR credentials are incorrect will be marked as unreachable. The Discovery SNMP credentials will not be tried.

Not using DCR as seed does not mess up multi-threading. If you don't have enough seeds to satisfy all available threads, then some threads will be idle until Discovery picks up more devices.

The hop count is bound to a seed, yes. A new device must be in that seed's hop radius.

A newly discovered device is discovered by a module, then it's polled with SNMP. If that passes, it's added to DCR. Multiple modules can find the same device.

A new device is first tested against the hop count of *every* seed from the module that founds the device? Only if this passes, then its polled with SNMP ?

if a new device does not pass the hop count of the module the device will not be handed over to any other module?

No. Say I have this:

10.1.1.1 | Hop Count : 2

Thread 1 starts on 10.1.1.1. Thread 1 will take all of the CDP neighbors from 10.1.1.1. For each device in 10.1.1.1's cache, it looks at their CDP neighbors. Then it stops.

Discovery doesn't care if I have another seed device existed which didn't have a discovered device in its hop radius.

now I understand ... (...I think...)

OK, and because the hop count is bound to a device the option 'Use DCR as Seed' will mess up the basic idea behind the hop count option. ...at least starting with the second discovery cycle...

Correct. The DCR seeds do not have a hop count associated with them.

Ha! so the answer of my first question is Option 2) !

and I would say its time to choose any or all of these options:

- update the documentation with this little information

- add another one of these nice pop-ups with this information when enabling 'Use DCR as Seed List'

Yes, both might be a good idea. In TAC, we typically see customers using -1 (or unlimited) for hop count, so this issue hasn't been raised thus far.

I would say customers can't use this option as it is not clearly enough documented ;-)

... but I agree, most customers won't need it as they want to get any device in their management IP ranges discovered automatically.

BTW, I really like this new feature in LMS 3.1 to have a pop-up when someone logs into LMS - I hope the GUI to configure it will come soon with the next update!

I filed CSCsu88678 for this problem.

I'm confused about the logged in users feature. The portlet may be new, but the feature has been around for a while. What kind of additional configuration would you like?

I know about the 'Notify Users' in CS > Server > Admin which sends a message to all actual logged in users.

What is new (to me) is the possibility to have a pop-up message when someone login to LMS; e.g. to inform him about current server maintenance or something like this.

Which portlet can I use for this feature?

Oh, you're referring the urgent message feature? If so, this has been around since LMS 2.2. I don't know of any plans to GUIfy adding urgent messages to the queue, but that would certainly be a cool enhancement.

I am talking about

opt/CSCOpx/lib/classpath/cscommon.properties

which I thought is new and differs from the urgent message feature in the way that the message only gets presented during the initial login process.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: