Discovery - Best Practice

[gespahl]

Greetings,

I was wondering how most engineers approach Discovery, especially on larger networks.  I'm not interested in the methods so much but more in how you "define" a valid discovery range.  I think on most networks, for each subnet there will be one or two ip addresses for network devices and the rest of the range will be servers, workstations, etc.  Since you can't do an include and an exclude on the filters how do you make it such that your network devices are discovered but servers, firewalls, etc. aren't?  Do you manually "include" every device in the filter?  Use the SysObjectID somehow?  Is there a way to exclude devices that you don't want to repeatedly discover without using the exclude filter?

The ideal outcome would be to discover everything relevant and nothing that wasn't but also retain the ability to discover new devices that might be plugged into the network at a later time.  How do most engineers handle this issue?  Anyone know of a good document that covers this subject?  Thanks in advance!

George          

[Marvin Rhoads]

If you're discovering a Cisco network, this is one of the advantages of Cisco Prime LMS. It will use a combination of CDP and SNMP to sort out the relevant discoverable devices. Discovery will run again periodically. I believe once a week is the default.

I typically use either a seed file if I know the network pretty well already or else just put in a core router or two per site and let discovery jump router boundaries and go out reasonable diameter (2-3 hops typically).

If you're using a third party product like SolarWinds Orion NPM it can be a bit trickier as it will indeed pull in a lot of non-network devices. That's great if you're also looking to manage servers and application using the SAM component but not so much if you're only using NPM.

Once a network is baselined, the best approach going forward is a combination of scheduled discovery jobs and a process that ensures that new changes are added into the management system as part of the change control process during the maintenance window.

[gespahl]

Thanks, Marvin, but your answer didn't have any relevance to the question.

[Vinod Arya]

Discovery apporaches would always differ from network to network, user to user and per NMS software. There is almost no well defined strategy on it, as the best option often depends on which NMS is being used and which discovery feature is most robust in it.

For NetAdmin's if they they have a well defined network, simple idea is to use the IP ranges to tell NMS what to find. If the Network is vast and doesnt have a defined IP Ranges, using automated modules to dicover network by NMS's own capability is very effective. Widely used, as Marvin said, is CDP module, and people often use other modules to maximize the device's search using ARP, Routing Table, BGP tables, OSPF etc.

Excluding a device from discovery isn't a very smart feature in NMS apps, and often needs to be exluded manually for a perticular IP, IP range, SysObjectID, sysLocation and DNS domains etc, depends on what other filters are available, per the NMS app. Filter options are specifically designed to achive the task of excluding devices, and hence there are least other optios to achieve this.

Once discovery is done initially, you probably want to run custom scheduled discovery jobs to discover new devices which are pluuged in network.

Mostly, any document on discovery would often include an indepth explaination of features available for discovery as per NMS app, probably a User Guide, so that end-users can use features as per their necessity and hence I don't see any document mostly available for Best Practices for Discovery, in general.

(Most of my examples span Ciscowork LMS as NMS app which I have used most. Many things may be additional/differ in many other NMS application)

-Thanks

[Vinod Arya]

That Said above, a very nice document explaining Discovery modules in Ciscoworks LMS is following:

https://supportforums.cisco.com/docs/DOC-9005

I hope it will be helpful.

-Thanks

[Michel Hegeraat]

So far this has always been quite a bit of searching, mapping, etc to find what is in place. And this is a manual exercise :-|

Selecting devices to manage is usually best done on systemobjectid. Most management system have such list of vendor OID. If you have many vendors you list will be longer. Sometimes naming conventions indicate router or switch but it is not 100% reliable.

Choosing the management address is a bit harder. I would never use a physical interface however, always a virtual. I first want to establish a device is reachable, after that retrieve the state of the interfaces.

What I tend to do is try and find out about IP ranges reserved for management. Next would be to try and map between the system-name or DNS-name of a device and the desired IP address.

With this info you can then 'discover' the network and based on the lookup of system-name or DNS-name retrieve the IP you need.

In an ideal world you would be able to get a list of IP addresses of all devices in your network combined with the interface names and select an address from there. After all it is not uncommon that a specific VLAN is used as a management VLAN, however even though this info can be gathered simply from mib2,  I'm not aware of any product out there, that can do this.

LMS for instance, can select the lowest lo0 loopback (if it is available) as a management interface.

Sometimes info is already present in IP address reservation systems, sometimes in access control systems, sometimes it is already for a large part in a DNS.

If 'nothing' is in place I would suggest to define a loopback/VLAN interface on every device. Of course this will add to your routing tables. But you can then take the management VLAN to separate QOS class giving it the priority you feel it needs.

I tend to keep a subnet per site and tried to allow for subnet summarization of subnet's on the WAN, but in the MPLS backbones this is often not really a requirement anymore.if your network topology is a star then it may still be worthwhile

Just a little brainstorm,...

Cheers,

Michel