Network discovery (or auto-discovery) is the process that automatically populates the physical and logical inventory information of a given network. Without auto-discovery, all the inventory items would be entered to the NIMS (Network Inventory Management System) manually, or at most, be imported from a previously generated flat file. Manual entries bring so many burdens especially if your network is dynamic and each day you add/remove new devices, new cards and provision new circuits.
A note in here: Auto-discovery processes may not only be implemented by the Inventory Management Systems, but also other OSS systems such as Fault Managers, Performance Managers or SQMs which need to employ the network topology information. In an ideal world, all the inventory information should be kept in one place, in the NIMS. However, to be able to sell the individual types of OSS products separately, vendors needed to include an inventory module within their applications. This introduces some scenarios in which multiple OSS products try to discover the network at the same time which may lead to inefficiencies in the network performance.
Auto-discovery of a network includes 3 phases:
• Device Discovery
• Topology Creation
Detection phase identifies all the “living” devices on the network. This is achieved via several mechanisms.
The most popular one is the ICMP Sweeping (or pinging). In this method, you provide an IP pool (typically a subnet) to the tool that will do the discovery. You may also have some options to exclude some IP addresses within this pool. This is because, for some types of devices/interfaces (such as ISDN dial-backup interfaces) unnecessary traffic (even ping) may result in connection charges. Another reason may be limiting the management traffic on a highly utilized interface.
For big networks the discovery process can take days. So, you should split the network into multiple small ones to increase the discovery efficiency and reduce discovery time.
After the IP address set is constructed, the tool starts to ping those IP addresses. If it receives a response, it notes this down.
You may also have the option to import the IP information from a DNS server. If you are using DNS server effectively, this method will provide you all the “authorized” IPs in your network. One other way could be reading the ARP cache of a device, but for me ARP is not very reliable. (The cache is cleared when the device restarts and some items in the cache are subject to time-out after a certain period of time)
The second step in auto-discovery is the Device Discovery. In this step, the discovery engine will try to connect to a found device via specified management protocols (SNMP, TL1 etc.) to receive additional inventory information. Ideally, this information will include all the inventory information for that NE (Network Element). How this is done differs from protocol to protocol. I will try to explain the SNMP device discovery which seems to be the most adapted one.
All devices that implement SNMP management protocol, should implement the MIB-2 RFC. This MIB (Management Information Base) was designed to include generic information that fits to all vendor equipments such as Name, Description, and Interfaces etc. However, most vendors prefer to use their own propriety MIB trees. (Which are located under the enterprise branch of the OID hierarchy). The motivation differs. Some vendors want to “hide” their devices to force the external OSS systems, to interface with the vendor EMS’s NBIs. Some other vendors may just want to distribute the MIBs to registered users for marketing purposes.
Vendors (whether they provide their own MIBs or not) must fill in some MIB-2 values for their NEs. The most important ones for the discovery purposes are the sysObjID, sysName and sysLocation. SysName and sysLocation will be very beneficial values to have, if they are correctly implemented.
SysObjID is the one which helps the discovery engine to understand the device type (host, switch etc.), vendor name, and model name. All the SNMP enabled vendors should register their devices to IANA organization, in order to get a SysObjID. SysObjID is unique in the world, just like a MAC address. This uniqueness enables the management system to map a SysObjID to a specific device type, vendor name and model.
After the device type is received from the SysObjID, further actions can be run. For example, if it is a router, discovery engine could check its MIB repository to find if there is a specific MIB for this vendor-model. (If not, it will use generic MIB-2). After the MIB is located, it will send series of SNMP-get requests to have the routing table, neighbors table, interfaces, sub-interfaces etc. If it is a switch, the discovery process will again send SNMP-get requests (to BRIDGE-MIB for example) to receive the forwarding table information.
The router example could be considered as L3 discovery, whereas the switch example is an example of a L2 Ethernet discovery. Other types of L2 discoveries can be for ATM, Frame Relay and MPLS type of networks.
At the final phase, topology creation, the discovered NE information is correlated by the inventory process to find and visualize the physical and logical connections between the NEs. Topology information can also be fetched directly from devices. For example OSPF protocol mandates the devices to maintain the topology information. Propriety protocols such as Cisco CDP can also be utilized by the discovery processes to draw the network topology.