System, method, and computer program product for platform-independent port discovery

FIELD OF THE INVENTION

0001The present invention relates to networking, and more particularly to network device discovery.

BACKGROUND

0002Wide area computer networks are often maintained by a system administrator. One of the system administrator's functions is to set policy for and to maintain software on the computers comprising the network. Typically, the system administrator decides, among other things, which software products are to be installed on the client computers and how that software is to be configured.

0003In most wide area networks, the system administrator can communicate with each computer on the network in a secure manner because the computers are connected together with a private communication link. Messages, files, and data can be sent over the private communication link from one or more central servers to each computer on the network, and the computers on the network can use the private communication link to send messages, files, and data to one or more central servers.

0004Most wide area networks are also set up so that the system administrator can use a central server to configure software on the other computers in the network. The system administrator can issue and control policy for the wide area network and can update and configure software on any or all computers within the network. One typical and routine practice of a computer network system administrator is to periodically update virus scanning software, intrusion detection tools, etc. on the computers in the administrator's network. Various tools are available for facilitating such network management. One particular example of such a tool is the EPOLICY ORCHESTRATOR device manufactured by MCAFEE, INC.

0005However, before the administrator can manage a network in the foregoing manner, each of the pertinent network devices must first be discovered. In the past, this discovery process has been highly manual in nature. For example, some systems have relied heavily on manual entry or importation of data identifying such network devices. Unfortunately, such systems are more susceptible to error, inefficient, etc.

0006There is thus a need for overcoming these and/or other problems associated with the prior art.

SUMMARY

0007A system, method, and computer program product are provided. Initially, platform-independent information relating to a network device is collected. Thereafter, a port on which the network device resides is determined based on the platform-independent information.

BRIEF DESCRIPTION OF THE DRAWINGS

0008<figref idref="DRAWINGS">FIG. 1</figref> illustrates a network architecture, in accordance with one embodiment.

0009<figref idref="DRAWINGS">FIG. 2</figref> shows a method for bootstrap switch discovery, in accordance with one embodiment.

0010<figref idref="DRAWINGS">FIG. 3</figref> shows a method for switch enumeration, in accordance with one embodiment.

0011<figref idref="DRAWINGS">FIG. 4</figref> shows a method for performing underlying switch enumeration operations, in accordance with one embodiment.

0012<figref idref="DRAWINGS">FIG. 5</figref> shows a method for switch discovery, in accordance with one embodiment.

0013<figref idref="DRAWINGS">FIG. 6</figref> shows a method for router discovery, in accordance with one embodiment.

0014<figref idref="DRAWINGS">FIG. 7</figref> shows a method for generating a topology map, in accordance with one embodiment.

DETAILED DESCRIPTION

0015<figref idref="DRAWINGS">FIG. 1</figref> illustrates a network architecture <b>100</b>, in accordance with one embodiment. As shown, a plurality of networks <b>102</b> is provided. In the context of the present network architecture <b>100</b>, the networks <b>102</b> may each take any form including, but not limited to a local area network (LAN), a wireless network, a wide area network (WAN) such as the Internet, etc. Of course, any type of networks <b>102</b> may be involved.

0016Coupled to the networks <b>102</b> are data server computers <b>104</b> which are capable of communicating over the networks <b>102</b>. Also coupled to the networks <b>102</b> and the data server computers <b>104</b> is a plurality of end user computers <b>106</b>. Such client computers <b>106</b> may each include a desktop computer, lap-top computer, mobile phone, hand-held computer, any component of a computer, and/or any other type of logic.

0017In order to facilitate communication among the networks <b>102</b>, a plurality of switches and routers <b>108</b> is coupled therebetween. Such switches may include, but are not limited to simple network management protocol (SNMP)-enabled switches, L2-capable switches, and/or any other type of switching device. Similarly, the routers may refer to any type of routing device.

0018In the context of the present description, the term “network device” may refer to any of the foregoing network components (e.g. computers, routers, switches, networks themselves, etc.) and/or any other component of a network or group of networks. It should be noted that any of the foregoing network devices may be equipped with various device discovery-related features. In one optional embodiment, such features may be provided by situating agents at each of the network devices.

0019By this design, different network device discovery techniques may be performed, in various embodiments. Specifically, in one embodiment, a discovery technique is provided for discovering various network devices including, for example, switches. Initially, a manufacturer associated with a network device is identified. Of course, such manufacturer may be any entity that, at least in part, contributes to the manufacture of the network device. Thereafter, information associated with the network device may be collected based on the identified manufacturer. In the context of the present description, such information may include any information capable of being used for network device (e.g. switch, etc.) discovery. A network device discovery operation may then be carried out utilizing the information, for the purpose of identifying previously unknown or obscure network devices. More information regarding one exemplary network device discovery technique will be set forth in greater detail during reference to <figref idref="DRAWINGS">FIG. 5</figref> et al.

0020In another embodiment, an additional discovery technique is provided for discovering various network devices including, for example, routers. In use, information is received relating to a plurality of network devices on a network. Again, in the context of the present description, such information may include any information capable of being used for network device (e.g. router, etc.) discovery. Such information is then correlated, such that additional network devices on the network utilizing the information. In use, the discovery is enhanced as a result of the correlation. More information regarding one exemplary network device discovery technique will be set forth in greater detail during reference to <figref idref="DRAWINGS">FIG. 6</figref>.

0021Still yet, in yet another embodiment, platform-independent information relating to a network device is collected. In the context of the present description, such platform-independent information may include any information that allows the determination of a port on which the network device resides, irrespective of the fact that a corresponding network includes network devices manufactured by different parties. To this end, a port on which the network device resides may be determined based on the platform-independent information. More information regarding one exemplary platform-independent network device discovery technique will be set forth in greater detail during reference to <figref idref="DRAWINGS">FIG. 7</figref> et al.

0022With the network devices discovered by way of the foregoing techniques, various subsequent processing may be facilitated. For example, an administrator may use such information for managing and configuring the discovered network devices. Of course, however, it should be noted that the network device discovery techniques disclosed herein may be employed for absolutely any desired purpose.

0023More illustrative information will now be set forth regarding various optional architectures and features with which the foregoing techniques may or may not be implemented, per the desires of the user. It should be strongly noted that the following information is set forth for illustrative purposes and should not be construed as limiting in any manner. Any of the following features may be optionally incorporated with or without the exclusion of other features described.

0024<figref idref="DRAWINGS">FIG. 2</figref> shows a method <b>200</b> for bootstrap switch discovery, in accordance with one embodiment. As an option, the present method <b>200</b> may be implemented in the context of the architecture and environment of <figref idref="DRAWINGS">FIG. 1</figref>. Of course, however, the method <b>200</b> may be carried out in any desired environment.

0025In operation <b>202</b>, network communications (e.g. packets, etc.) are monitored for Cisco discovery protocol (CDP) or spanning tree protocol (STP) packets for a predetermined time. In one exemplary embodiment, the predetermined time may include 60 seconds. Of course, any time period may be utilized. While CDP and STP protocols are utilized herein, it should be noted that any desired protocols may be utilized that allows the present method <b>200</b> to, at least in part, initiate a later network device enumeration process.

0026Next, in decision <b>203</b>, it is determined whether a CDP or STP packet is received. If it is determined that neither a CDP or STP packet is received, an error is generated in operation <b>206</b>. If, on the other hand, it is determined that either a CDP or STP packet is received, such CDP or STP packet is used for identifying a first network device (e.g. switch, etc.) on which further network device discovery may be based.

0027Specifically, it is determined in decision <b>208</b> whether a CDP packet is received. If so, a CDP management IP address is parsed. Note operation <b>212</b>. It should be noted that, in the case of a CDP packet, only the IP address is available. Thereafter, a network device enumeration operation may be performed in operation <b>216</b>, since IP address is known. More information regarding such network device enumeration operation <b>216</b> will be set forth hereinafter in greater detail.

0028On the other hand, if it is determined in decision <b>208</b> that a CDP packet has not been received, it is then determined whether a STP packet is received. Note decision <b>210</b>. If the STP is determined to be received, the Bridge ID (MAC address) is parsed, as indicated in operation <b>212</b>. Still yet, since an IP address is not readily available using the STP packet, a default gateway or router list is queried in operation <b>218</b>. Typically, such router list is readably available on a default machine in a management information base (MIB) address resolution protocol (ARP) cache, and conventionally includes a MAC-to-IP address mapping.

0029Thereafter, it is determined whether a MAC-to-IP address mapping is found. See decision <b>220</b>. If not, the error is generated in operation <b>206</b> (similar to when it is determined that neither a CDP or STP packet is received per decisions <b>208</b>-<b>210</b>). On the other hand, if such mapping is found per decision <b>220</b>, the aforementioned network device enumeration operation may be performed in operation <b>216</b>, since the IP address associated with the MAC address will be known.

0030More exemplary information regarding the foregoing network device enumeration will be set forth hereinafter in greater detail during reference to <figref idref="DRAWINGS">FIG. 3</figref>. Specifically, given the aforementioned MAC address and IP address of a first network device identified using the method <b>200</b> of <figref idref="DRAWINGS">FIG. 2</figref>, the network device enumeration of <figref idref="DRAWINGS">FIG. 2</figref> et al. may be used to identify further network devices.

0031<figref idref="DRAWINGS">FIG. 3</figref> shows a method <b>300</b> for network device (e.g. switch) enumeration, in accordance with one embodiment. As an option, the present method <b>300</b> may be implemented in the context of the architecture and environment of <figref idref="DRAWINGS">FIGS. 1-2</figref> and, in particular, operation <b>216</b> of <figref idref="DRAWINGS">FIG. 2</figref>. Of course, however, the method <b>300</b> may be carried out in any desired environment.

0032In use, a connection is made to the IP address identified during the method <b>200</b> of <figref idref="DRAWINGS">FIG. 2</figref>, utilizing SNMP. As shown, such connection allows a status of a first STP port (out of 24, for example) to be obtained in operation <b>302</b>. Thereafter, it is determined from such status whether port STP forwarding is enabled. See decision <b>304</b>. Such STP forwarding mode enables any STP packet to be forwarded to any network device connected to the port.

0033If this is enabled, it may be inferred that there is likely a network device connected to the port. Thus, the destination STP MAC address associated with any such forwarding mode is added to a bridge port MAC address list in operation <b>306</b>. More information on the use of such list will be set forth hereinafter in greater detail.

0034Thereafter, or if it is determined that port STP forwarding is not enabled per decision <b>304</b> (and, thus, there is likely no network device coupled to the port), a next STP port status is obtained in operation <b>308</b>. These operations then continue until an end of STP port statuses is reached (such that all 24 ports are reviewed), per decision <b>310</b>.

0035Once such end is reached, CDP neighbors (i.e. other CDP-enabled devices, etc.) are obtained in operation <b>312</b>. This may be accomplished by querying network device memory, which typically identifies the presence of CDP neighbors. Further, for each CDP neighbor, an associated IP address (which has a known corresponding MAC address) is stored in a bridge port CDP list, in operation <b>314</b>. Again, details on the use of such information will be set forth hereinafter. To this end, the instant processing is finished with respect to the present network device.

0036More exemplary information regarding the manner in which the aforementioned device enumeration is carried out will be set forth hereinafter in greater detail during reference to <figref idref="DRAWINGS">FIG. 4</figref>. Specifically, the following information relates to underlying operations associated with the SNMP connection, that allows the information gathering of the method <b>300</b> of <figref idref="DRAWINGS">FIG. 3</figref>.

0037<figref idref="DRAWINGS">FIG. 4</figref> shows a method <b>400</b> for performing underlying switch enumeration operations, in accordance with one embodiment. As an option, the present method <b>400</b> may be implemented in the context of the architecture and environment of <figref idref="DRAWINGS">FIGS. 1-3</figref> and, in particular, as an underlying parallel operation with respect to the method <b>300</b> of <figref idref="DRAWINGS">FIG. 3</figref>. Of course, however, the method <b>400</b> may be carried out in any desired environment.

0038Initially, in operation <b>402</b>, a services descriptor value is obtained via the aforementioned SNMP connection. In one embodiment, such services descriptor value may include a sysServices value and/or any other value that describes services rendered by a particular network device. With this information, in decision <b>404</b>, it may be determined whether the current network device is a switch or a router in decisions <b>403</b> and <b>404</b>, respectively. If the network device is neither, an error condition is provided to indicate that the device is not an SNMP network device.

0039However, if it is determined that the current network device is a switch or a router in decisions <b>403</b> and <b>404</b>, a manufacturer object identifier [e.g. Enterprise object identifier (OID) octet, SysObject OID, etc.] is obtained. See operation <b>410</b>. A manufacturer object identifier identifies a manufacturer (e.g. vendor, etc.) associated with the switch or router. To this end, a look up operation <b>412</b> may performed utilizing the manufacturer object identifier, in order to identify the related vendor as well as additional information. Table 1 illustrates an exemplary data structure that may be used in conjunction with the look up operation of operation <b>412</b>.

0040<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="49pt" align="left" /><colspec colname="1" colwidth="168pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" rowsep="1">TABLE 1</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Enterprise OID octet: 9</entry></row><row><entry /><entry>VendorName: Cisco</entry></row><row><entry /><entry>VLAN: enterprises.9.9.68.1.2.2.1.2.0</entry></row><row><entry /><entry>ArpCache: MIB-2.4.22.1.2</entry></row><row><entry /><entry>OperStatus: MIB-2.2.2.1.8</entry></row><row><entry /><entry>STPRootCost: MIB-2.17.2.6</entry></row><row><entry /><entry>BridgeAddress: MIB-2.17.1.1.0</entry></row><row><entry /><entry>STPPortForwardState: 5</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0041It should be noted that the foregoing data structure is set forth for illustrative purposes only and should not be construed as limiting in any way.

0042By way of background, the SNMP framework defines several generic MIBs to use when communicating with any SNMP-enabled network device. However, many vendors expand upon these MIBs or only provide certain information within an enterprise OID space. Because of these limitations, the aforementioned table may be useful to store the OID needed for each SNMP communication with a network device. In addition, such table allows the discovery process to work with any vendor-specific network device as long as the required OIDs are added to the vendor table. Whenever an OID is required, the proper OID may be searched for, within the vendor table, before communicating with the network device. If the OID is not available, a default or generic network device may be designated.

0043A bridge address (e.g. MAC address, etc.) is then obtained in operation <b>414</b>, after which the STP root path cost (which indicates the spanning tree's path cost to the root bridge; similar to hop count) is obtained in operation <b>415</b>. As an option, such information may be obtained via a data structure such as that of Table 1, for example.

0044To this end, a first bridge port may be obtained in operation <b>418</b>, so that an operation status may be obtained. Note operation <b>420</b>. Since physical ports may be combined, aggregated, etc., bridge ports are utilized in the context of the present embodiment. Next, virtual local area network (VLAN) information is obtained in operation <b>422</b>. A next bridge port is then obtained in operation <b>424</b>, and it is determined whether all of the bridge ports are enumerated in decision <b>425</b>. If not, operations <b>420</b>-<b>424</b> are repeated until all of the bridge ports are indeed enumerated.

0045On the other hand, if it is determined that all of the bridge ports are enumerated in decision <b>425</b>, a first forwarding database entry is obtained in operation <b>428</b>. Such entry is the first of many stored in a conventional forwarding database associated with the network device. It is subsequently determined whether a MAC address associated with such entry was dynamically learned, as set forth in decision <b>430</b>. In other words, it is determined whether the MAC address associated with such entry was learned via the methods of <figref idref="DRAWINGS">FIGS. 2-3</figref>.

0046If it was dynamically learned, the MAC address is added to the bridge port MAC address list which was previously described with respect to operation <b>306</b> of <figref idref="DRAWINGS">FIG. 3</figref>. Note operation <b>432</b>. Specifically, each MAC address may be stored in association with a bridge port. Note Table 2, for example.

0047<tables id="TABLE-US-00002" num="00002"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="84pt" align="left" /><colspec colname="2" colwidth="91pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="2" rowsep="1">TABLE 2</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Bridge_port_1</entry><entry>MAC_address_1</entry></row><row><entry /><entry /><entry>MAC_address_2</entry></row><row><entry /><entry /><entry>MAC_address_3</entry></row><row><entry /><entry>Bridge_port_2</entry><entry>MAC_address_4</entry></row><row><entry /><entry>Bridge_port_3</entry><entry>MAC_address_5</entry></row><row><entry /><entry /><entry>MAC_address_6</entry></row><row><entry /><entry /><entry>MAC_address_7</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0048If, however, it is determined that the MAC address was not dynamically learned (or after the MAC address is added to the bridge port MAC address list in operation <b>432</b>), the next forwarding database entry is obtained in operation <b>434</b>. It is then determined whether the present method <b>400</b> is at the end of the forwarding database entries. If so, the method <b>400</b> is terminated. On the other hand, if it is determined that the present method <b>400</b> is not at the end of the forwarding database entries, operations <b>430</b>-<b>434</b> are repeated accordingly for the remaining entries.

0049More exemplary information will now be set forth regarding the manner in which network device discovery is carried out utilizing the information (e.g. bridge port MAC address list, bridge port CDP list, VLAN information, etc.) collected via the methods <b>200</b>-<b>400</b> of <figref idref="DRAWINGS">FIGS. 2-4</figref>. Specifically, in one embodiment, each additional network device in a catenet may be discovered utilizing the various collected information.

0050<figref idref="DRAWINGS">FIG. 5</figref> shows a method <b>500</b> for network device (e.g. switch) discovery, in accordance with one embodiment. As an option, the present method <b>500</b> may be implemented in the context of the architecture and environment of <figref idref="DRAWINGS">FIGS. 1-4</figref>. Of course, however, the method <b>500</b> may be carried out in any desired environment.

0051As shown, information identifying an enumerated network device is received in operation <b>502</b>, after which it is determined whether such network device is a switch in decision <b>504</b>. If the network device is not a switch per decision <b>504</b>, the method <b>500</b> is terminated in operation <b>509</b> as other network devices are not of interest at this stage.

0052If, on the other hand, the network device is indeed a switch, a first bridge port is obtained in operation <b>506</b>. Thereafter, it is determined whether the port has multiple MAC addresses associated therewith (since such would indicate that a switch is coupled thereto). See decision <b>508</b>. This may be accomplished utilizing the information gathered previously (e.g. the bridge port MAC address list, Table 2, etc.).

0053If multiple MAC addresses do indeed exist, a first MAC address is obtained in operation <b>510</b> after which a router list is queried for a MAC-to-IP address mapping in operation <b>512</b>. It is then determined whether such mapping is found (see decision <b>514</b>). If it is found, switch enumeration proceeds in operation <b>516</b> (note the methods <b>300</b> and <b>400</b> of <figref idref="DRAWINGS">FIGS. 3 and 4</figref>, respectively). To this end, switches are constantly enumerated when available. As is now further apparent, the various methods disclosed herein may be executed in parallel.

0054On the other hand, if it is determined that the mapping is not found (see decision <b>514</b>), a next MAC address is obtained in operation <b>518</b>, after which it is determined whether an end of the MAC address list has been reached in decision <b>522</b>. If not, the router list is queried again for the MAC-to-IP address mapping in operation <b>512</b>, and the method <b>500</b> proceeds thereafter with operations <b>514</b>, <b>516</b>, <b>518</b>, etc.

0055If, however, it is determined that the end of the MAC address list has indeed been reached in decision <b>522</b>, it is then determined whether any switches have been discovered. Note operation <b>524</b>. If so, the discovery process is terminated per operation <b>509</b>. Otherwise, the device is marked as a hub or an unmanageable switch in operation <b>520</b>.

0056Referring back to decision <b>508</b>, if it is determined that the port does not have multiple MAC addresses associated therewith, the method <b>500</b> continues by determining whether the port has a CDP neighbor (or STP MAC address) in decision <b>540</b> (which would, again, indicate the presence of a switch coupled to the port). Again, this may be accomplished utilizing the information (e.g. bridge port CDP list, etc.) gathered previously during the methods of the previous figures.

0057If not, a next bridge port is obtained in operation <b>536</b>, and the method <b>500</b> continues with respect to decision <b>542</b>. Specifically, it is determined whether an end of bridge ports has been reached. If so, the method <b>500</b> is terminated in operation <b>509</b>. If not, though, the method <b>500</b> continues with decision <b>508</b>.

0058If, however, it determined that the port has a CDP neighbor (or STP MAC address) in decision <b>540</b>, a mapping is obtained. See operation <b>538</b>. By way of background, CDP only provides an IP address, thus an IP-to-MAC address mapping is required to obtain the appropriate MAC address. On the other hand, STP only provides a MAC address, thus a MAC-to-IP address mapping is required to obtain the appropriate IP address.

0059If the appropriate mapping is found, switch enumeration proceeds in operation <b>526</b> (note the methods <b>300</b> and <b>400</b> of <figref idref="DRAWINGS">FIGS. 3 and 4</figref>, respectively). On the other hand, if it is determined that the appropriate mapping is not found in the case of a CDP neighbor (see decision <b>534</b>), it is then determined whether the port has an STP destination MAC address. See decision <b>530</b>.

0060If so, the STP destination MAC address is used as the MAC address for the CDP neighbor, as set forth in operation <b>528</b>, and switch enumeration proceeds in operation <b>526</b> (note the methods <b>300</b> and <b>400</b> of <figref idref="DRAWINGS">FIGS. 3 and 4</figref>, respectively). Again referencing decision <b>530</b>, if it is determined, on the other hand, that the port does not have an STP destination MAC address, an error is logged indicating that the method <b>500</b> was unable to find the MAC-to-IP address mapping for the CDP neighbor. See operation <b>532</b>. Thereafter, the discovery process is terminated per operation <b>509</b>.

0061Thus, once a network device (e.g. switch, etc.) has had all related bridge ports enumerated and stored, each stored port may be looped through so as to attempt to communicate with any IP address or MAC address found on the port. If a MAC address(es) is found on a port, the default gateway and any discovered routers may be used to find the IP address corresponding to the MAC address.

0062To this end, a platform-independent technique is provided for network device discovery. This is accomplished by collecting information on a network device based on an identified manufacturer associated with the network device. For example, if the network device is a Cisco® device, all CDP neighbors stored on the network device may be enumerated using a Cisco® CDP-MIB and by associating the IP address with the bridge port on which the CDP neighbor packet was received.

0063As mentioned previously, the method <b>500</b> is focused on the discovery of switches. Running in parallel (or serially, if desired) with such switch discovery process is a router discovery process. More information on such router discovery process will now be set forth during reference to <figref idref="DRAWINGS">FIG. 6</figref>.

0064<figref idref="DRAWINGS">FIG. 6</figref> shows a method <b>600</b> for router discovery, in accordance with one embodiment. As an option, the present method <b>600</b> may be implemented in the context of the architecture and environment of <figref idref="DRAWINGS">FIGS. 1-5</figref> and, in particular, in parallel with the switch discovery of <figref idref="DRAWINGS">FIG. 5</figref> et al. Of course, however, the method <b>600</b> may be carried out in any desired environment.

0065As shown, in operation <b>606</b>, a first interface is obtained. As an option, this and various following communications may be accomplished via SNMP using a community string (e.g. a user id or password that allows access to router statistics, etc.). Further, the method <b>600</b> may begin processing with a default gateway of a device performing the router discovery. Unlike the switch discovery of previous figures, the current router discovery may differ in that routers typically have fewer interfaces (e.g. one or two, etc.).

0066Thereafter, it is determined in decision <b>607</b> whether the interface is an Ethernet interface, since it may not necessarily be desirable to communicate over a WAN link. If the interface is not an Ethernet interface, a next interface is obtained in operation <b>608</b>. Then, if there are no more interfaces per decision <b>610</b>, the method <b>600</b> terminates. However, if there are indeed more interfaces per decision <b>610</b>, the method <b>600</b> continues at decision <b>607</b>, as shown. Thus, all Ethernet interfaces may be enumerated.

0067If it is determined in decision <b>607</b> that the interface is an Ethernet interface, a first static route (i.e. a predetermined route to a network device, etc.) is obtained in operation <b>612</b>. Then, in decision <b>616</b>, it is determined whether it is routed out of the present interface. In other words, it is determined whether the route is utilized for network communications (since it is those that are of particular interest). If so, the discovery process is initiated in operation <b>616</b> (by starting the method <b>600</b> again).

0068To this end, all static routes may be enumerated. In one embodiment, this may be accomplished using a RFC1213 MIB, where the enumerated interface is used as the ipRouteIfIndex. For each ipRouteDest returned from the enumerated routes, the discovery process may again be initiated using the ipRouteNextHop Address as the router address.

0069However, if in decision <b>616</b>, it is determined that it is not routed out of the present interface, a next route is obtained in operation <b>620</b>. Thereafter, in decision <b>618</b>, it is determined whether such route is an end of the static routes. If not, the method <b>600</b> proceeds at decision <b>616</b>, as shown.

0070On the other hand, if in decision <b>618</b>, it is determined that such route is indeed an end of the static routes, a first IP address is obtained from an ARP cache. See operation <b>628</b>. Again, the ARP cache includes a MAC-to-IP address mapping, similar to that used hereinabove with respect to switch discovery. It is then determined whether such IP address was learned on the present interface in decision <b>622</b>. This may be accomplished using the IP address and even the subnet mask of the present enumerated network device to search for any other network devices in the ARP cache of the router using the bridge MIB. If this is the case, the discovery process is initiated in operation <b>616</b> (by starting the method <b>600</b> again using the IP address for the router address), so that additional network devices may be found, etc.

0071However, if it is determined that the IP address was not learned on the present interface in decision <b>622</b>, a next IP address is obtained in operation <b>625</b> after which it is determined whether an end of the ARP cache has been reached. If not, the method <b>600</b> continues at decision <b>622</b>. If so, however, the method <b>600</b> continues by obtaining the next interface in operation <b>608</b>, as shown.

0072By correlating information (e.g. IP addresses and the instant interface, etc.) in this manner, the present method <b>600</b> is capable of more efficiently discovering routers. For example, a detailed analysis of at least a portion of the IP addresses in the ARP cache may optionally be avoided.

0073<figref idref="DRAWINGS">FIG. 7</figref> shows a method <b>700</b> for generating a topology map, in accordance with one embodiment. As an option, the present method <b>700</b> may be implemented in the context of the architecture and environment of <figref idref="DRAWINGS">FIGS. 1-6</figref> and, in particular, after the various procedures of <figref idref="DRAWINGS">FIGS. 1-6</figref>. Of course, however, the method <b>700</b> may be carried out in any desired environment.

0074In operation <b>702</b>, a host is initially detected by identifying a broadcast packet or a dynamic host configuration protocol (DHCP) request. Thereafter, the method <b>700</b> waits for topology discovery to finish initializing, as set forth in operation <b>706</b> (e.g. see, for example, the discovery operations in previous <figref idref="DRAWINGS">FIG. 5</figref> et al.). The method <b>700</b> then starts with the bootstrap switch (e.g. see, for example, method <b>200</b> of <figref idref="DRAWINGS">FIG. 2</figref>), as discovered via CDP, or provided by a user, as indicated in operation <b>707</b>. The method <b>700</b> then waits for topology discovery to finish processing the initial switch (e.g. see, for example, the discovery operations in previous <figref idref="DRAWINGS">FIG. 5</figref> et al.). See operation <b>708</b>.

0075It is then determined whether a match has been found in decision <b>710</b>. Specifically, it is determined whether a MAC address associated with the host detected in operation <b>702</b> matches a MAC address in a bridge MIB forwarding database table associated with the network device. If not, empty information is returned to the server, since the host may not be quarantined through the switch. Note operation <b>712</b>.

0076If, however, it is determined that a match has been found in decision <b>710</b>, it is then determined whether there is a switch on the same port (i.e. they are directly connected, etc.). See decision <b>717</b>. If so, the next IP address of the switch that is on the same port (as the host) is obtained in operation <b>716</b>, and the method <b>700</b> proceeds with operation <b>708</b>, etc.

0077Referring back to decision <b>717</b>, if it is determined that there is not a switch on the same port, the VLAN information and bridge port MAC address are obtained along with the interface of the port. Note operation <b>718</b>. Next, the switch information is reported to a server for potential quarantining of the port so that any desired switch management (e.g. configuration, updating, etc.) may be carried out. Note operation <b>720</b>. Of course, as mentioned previously, the present network device discovery technique may be carried out for absolutely any desired purpose.

0078To this end, platform-independent information relating to a network device may be collected. Thereafter, a port on which the network device resides may be determined based on the platform-independent information.

0079Thus, the present technique may be used to periodically detect and find every switch on a target network. The detection of switches may be accomplished by accessing each switch via SNMP and storing within a database the MAC address learned on each port, as well as possibly the port type (e.g. uplink or not, etc.). In any exemplary embodiment where the switch type is an uplink port, it may further be determined to which switch the port connects. Once this information is collected, intelligent assumptions can be made about the location of the MAC address sought.

0080This may, in one embodiment, be accomplished via a database search for the switch that last contained the MAC address of interest. An agent (e.g. sensor, etc.) that detected the switch may then be contacted to inform it of the host MAC address to search for, along with a list of possible switches to which the host may be connected. This list may be known as “mapping hints.” The list of possible switches may include the switch on which the host was last seen, as well as a list of STP roots through which the host may now be connected.

0081Next, the process may iterate through the list of mapping hint switches, and establish a connection to determine if the MAC is found on the port stored within an associated database. For each uplink port on the switch, a connection may be made to the network device so that a search may be performed for the MAC address. This essentially creates a search across the “level” that the previous switch is located, and below.

0082Once the target MAC address is found connected to a network device on the network, the algorithm may continue to step through the network map until the target MAC is found in a leaf node configuration. A leaf node configuration may be defined as a configuration where either the target MAC address is the only MAC address listed for a given port on a network device, or that the next L2 network device does not respond to SNMP queries, and represents an end to the segmented network. After discovery, the devices may be quarantined until they can be reviewed, etc. for policy management.

0083While various embodiments have been described above, it should be understood that they have been presented by way of example only, and not limitation. For example, any of the network elements may employ any of the desired functionality set forth hereinabove. Thus, the breadth and scope of a preferred embodiment should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.