10-02-2008 03:43 AM
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!
Solved! Go to Solution.
10-02-2008 09:10 AM
Correct. The DCR seeds do not have a hop count associated with them.
10-02-2008 06:19 AM
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.
10-02-2008 08:00 AM
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 ?
10-02-2008 08:13 AM
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.
10-02-2008 08:24 AM
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?
10-02-2008 08:29 AM
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.
10-02-2008 09:05 AM
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...
10-02-2008 09:10 AM
Correct. The DCR seeds do not have a hop count associated with them.
10-02-2008 09:24 AM
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'
10-02-2008 09:48 AM
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.
10-02-2008 10:06 AM
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!
10-02-2008 10:25 AM
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?
10-02-2008 10:40 AM
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?
10-02-2008 10:48 AM
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.
10-02-2008 10:51 AM
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.
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: