US20020069367A1 - Network operating system data directory - Google Patents

Abstract

A method and apparatus for generating a configuration record for a network device is described. One implementation involves receiving general configuration information and vendor-specific configuration information about a network device. This general and vendor-specific configuration information can be used to generate a configuration record unique to the network device.

Description

FIELD OF THE INVENTION
• The present invention relates generally to network systems. More particularly, but not by way of limitation, the present invention relates to systems and methods for configuration, management and monitoring of network resources such as routers, optical devices and the like.[0001]
BACKGROUND OF THE INVENTION
• With the ever-increasing reliance upon electronic data, businesses are becoming more and more reliant upon those networks responsible for distributing that data. Unfortunately, the rapid growth in the amount of data consumed by businesses has outpaced the development and growth of certain necessary network infrastructure components. One reason that the development and growth of the network infrastructure has lagged behind centers on the present difficulty in expanding, configuring, and reconfiguring existing networks. Even the most routine network expansions and reconfigurations, for example, require significant, highly technical, manual intervention by trained network administrators. Unfortunately, these highly trained network administrators are in extremely short supply. Thus, many needed network expansions and reconfigurations are delayed or even completely avoided because of the inability to find the needed administrators to perform the required laborious, technical tasks.[0002]
• The present difficulty in configuring and reconfiguring networks is best illustrated by an example directed toward installing a single new router on an existing network. To install a new router (such as[0003]router100 or105 in FIG. 1), anadministrator110 first would need to choose a particular router with the best attributes for the network. The basic configuration of the new router generally will be defined by its manufacturer and its model. Although it would seem that the router should be chosen based upon its attributes,administrators110 often choose a router based upon the identity of its manufacturer and the administrators' ability to configure devices from that manufacturer.Administrators110, for example, may only know how to configure and operate devices manufactured by Cisco Systems, Inc. and may overlook equal or even superior devices from other manufacturers merely because they cannot configure them.
• After the[0004]administrator110 has chosen the desired router (router105, for example), theadministrator110 generally will order therouter105 from the manufacturer and have it shipped, not necessarily to the installation site, but rather to the administrator's site where a basic configuration can be installed. Theadministrator110 then ships therouter105 to the installation site where it can be physically installed. After therouter105 has been physically installed, theadministrator110 typically is manually notified, e.g., by telephone, that therouter105 is connected to the network. The administrator must then create the device-specific commands required to fully configure therouter105 and transfer those commands to the router'smemory115. After theadministrator110 verifies that the device-specific commands were installed correctly, therouter105 can be brought online.
• Obviously, the steps required for an administrator to configure a single router are quite cumbersome and require significant technical skill. The problem, however, is even more severe when the administrator desires to simultaneously configure or reconfigure several network devices. First, the administrator, for example, would need to manually identify the network devices that need to be configured or reconfigured. For example, if the administrator desired to turn up service between two points, the administrator would need to identify the routers along the path between the two points. The administrator would then need to verify that the policies and rules established for the network permit the contemplated reconfiguration for those devices. Assuming that the reconfiguration is within the network's policies and rules, the administrator would need to create the device-specific code required to reconfigure each of the identified devices. In many instances, the same device-specific code cannot be used on all of the devices. For example, the device-specific commands required to reconfigure a Cisco™ router differ significantly from the device-specific commands required to reconfigure a Juniper™ router. Thus, if the identified network devices include both Cisco™ and Juniper™ routers, the administrator would be required to create different versions of the device-specific commands, thereby significantly increasing the chance for error in the reconfiguration process.[0005]
• Once the device-specific commands have been created for each of the identified network devices, the commands must be manually transmitted to each device. That is, a connection, e.g., a telnet connection, must be established to each device and the particular commands transferred thereto. After each device has received its commands, the network administrator must manually reconnect to each device and verify that the device received the proper commands and that it is operating properly.[0006]
• Although some tools have been developed to help administrators perform certain ones of the laborious tasks of network management, these tools are extremely limited in their application. For example, CiscoWorks™ is a group of unrelated tools that can aid administrators in some enterprise level tasks. CiscoWorks™ and similar tools provide singularly focused, unrelated tools to perform activities such as quality of service (QOS) provisioning and network policy management. These tools do not provide a way to interrelate the various happenings in a network. In essence, these present network tools lack a holistic approach to network administration.[0007]
• Moreover, tools like CiscoWorks™ are generally dedicated to the management of one type of network device, e.g., router or optical device, and one brand of network device. For example, CiscoWorks™ does not help an administrator configure a Juniper™ router, and it does not help an administrator configure optical devices. Thus, if the network has both Cisco™ and Juniper™ devices, multiple, unrelated tools must be utilized to perform basic network management tasks. Unfortunately, because these multiple, unrelated tools are so difficult to manage, network administrators are prone to select routers based upon manufacturer identity rather than upon device features.[0008]
• In addition to several other drawbacks, these singularly focused network tools result in substandard fault detection and recovery. For example, in present systems, once a configuration is changed, there is no easy way to “back out” of that configuration if a problem arises. Presently, if a new configuration for a target device fails, the network administrator would be forced to recreate the device-specific commands of the target device's previous configuration, manually connect to the device and then transmit the recreated device-specific commands to the device. As can be appreciated, this process can be extremely time consuming and error prone.[0009]
• The lack of a comprehensive, holistic tool to manage network resources has led to slowed expansion and the under utilization of existing networks. As skilled administrators become more scarce and as networks grow larger and more complicated, the problems surrounding network management could reach crisis proportions. Accordingly, an integrated network administration tool is needed. In particular, a system and method are needed to efficiently configure, monitor and manage network devices without regard for device type and/or manufacturer.[0010]
SUMMARY OF THE INVENTION
• To remedy the above described and other deficiencies of the current technology, a system and method for the configuration and monitoring of network devices has been developed. In one embodiment, the present invention provides a system and method to configure, monitor and/or manage network devices without regard to device type and/or manufacturer identity. One implementation of this embodiment includes a network manager unit disposed between the network administrator and the network devices. The network manager unit allows the administrator to holistically view, configure and manage an entire network. That is, the administrator can view, configure and manage, for example, both optical devices and/or routers without regard to manufacturer identity or specific model. The administrator can implement this holistic approach with the use of a central repository for all configuration information and/or a central posting location for all network events.[0011]
• In one embodiment, for example, an administrator can configure a new device or reconfigure an existing device by logging into the network manager unit and selecting a particular network device to configure. The network manager unit can then retrieve a configuration record unique to the selected network device from the common repository and provide that record to the administrator. After receiving the record, the administrator can change fields therein without regard for manufacturer identity of the network device. Next, the network manager unit can automatically verify that the requested changes to the configuration record comply with the policies and rules established for the network, and assuming that the changes do not violate any of the policies or rules, the network manager unit can update and store the modified configuration record in the central repository. A copy of the old configuration record can be kept in the central repository for fault recovery, modeling and other purposes.[0012]
• Once the configuration record has been changed, network manager unit can use the fields of the modified configuration record to generate the actual device-specific commands needed to configure the selected network device. For example, the fields in the configuration record can be used to populate variable fields in a device-specific code template. In such an embodiment, the administrator is not required to know or create the actual device-specific commands that are required to configure the selected network device. Instead, the administrator only needs to know the general objective such as “enable router.” The network manager unit will transform this general objective into the actual device-specific commands.[0013]
• After the network manager unit has created the device-specific commands to match the altered configuration record, these commands are automatically pushed to the selected network device and stored in memory therein. A copy of those commands is also stored in association with the configuration record. Finally, after the new device-specific commands have been pushed to the selected network device, the network manager unit can verify the proper installation and operation of the new configuration information.[0014]
• In essence, one embodiment of the present invention allows a configuration record to be created and/or modified for each network device regardless of the device's type, manufacturer or model. Each of the configuration records can be stored in a central repository for simplified access, retrieval and editing. Thus, to change the configuration for any network device, the network manager unit need only retrieve the altered configuration record from the central repository, generate the device-specific commands based upon that configuration record and push those generated device-specific commands to the target network device.[0015]
• In another innovative aspect, the present invention enables automatically responses to network events. For example, network devices can be configured to post messages to a central posting location at the network manager unit. The network manager unit can read these posted network events from the central posting location and determine a proper response based upon predefined rules and policies. The network manager unit can then automatically implement the response. For example, if a particular router becomes congested, that router can post a message to the central posting location. The network manager unit can then read that message and determine the appropriate response for the congested router. The policy could indicate, for example, that the router configuration should be changed to enable congestion handling features. The network manager unit, in this scenario, could automatically reconfigure the router to enable those congestion-handling features.[0016]
• As can be appreciated by those skilled in the art, the present invention addresses the significant shortfalls in present network technology. In particular, the present invention, provides a holistically way to configure, manage and view an entire network system. These and other advantages of the present invention are described more fully herein.[0017]
BRIEF DESCRIPTION OF THE DRAWINGS
• Various objects and advantages and a more complete understanding of the present invention are apparent and more readily appreciated by reference to the following Detailed Description and to the appended claims when taken in conjunction with the accompanying Drawings wherein:[0018]
• FIG. 1 illustrates a present system for configuring network routers;[0019]
• FIG. 2 illustrates a system for configuring network devices in accordance with the principles of the present invention;[0020]
• FIG. 3 illustrates in more detail the network manager unit shown in FIG. 2;[0021]
• FIG. 4 illustrates in more detail the directory element shown in FIG. 3;[0022]
• FIG. 5 illustrates a configuration record for a typical network device in accordance with the present invention;[0023]
• FIG. 6 illustrates in more detail the event bus shown in FIG. 3; and[0024]
• FIG. 7 is a flow chart of a method for configuring a network device in accordance with the present invention.[0025]
DETAILED DESCRIPTION
• Although the present invention is open to various modifications and alternative constructions, a preferred exemplary embodiment that is shown in the drawings is described herein in detail. It is to be understood, however, that there is no intention to limit the invention to the particular forms disclosed. One skilled in the art can recognize that there are numerous modifications, equivalents and alternative constructions that fall within the spirit and scope of the invention as expressed in the claims.[0026]
• Referring now to FIG. 2, there is illustrated a[0027]system120 for configuringnetwork devices100,105,125,130 (collectively135) in accordance with the principles of the present invention. This embodiment includes anetwork manager unit140 disposed between theadministrator110 and thenetwork devices135, which can include routers, optical devices, etc. Thenetwork manager unit140 also is connected to remote storage145 (connected by network150) and anetwork manager support155.
• To alter the configuration of a[0028]network device135 or to add a network device to an existing network, theadministrator110 can access thenetwork manager unit140, search for and retrieve the configuration record corresponding to a target network device, and through a series of interactive, wizard-like screens, change the configuration record for the target network device. This altered configuration record is stored in a central repository in thenetwork manager unit140 and can be checked against network policies accessible by thenetwork manager unit140. Next, thenetwork manager unit140 can generate device-specific commands from the new configuration record and push those device-specific commands to the target network device or have the target network device pull the commands. Finally, thenetwork manager unit140 can verify that the new configuration was installed correctly at the target network device.
• To generate the necessary device-specific commands, the[0029]network manager unit140 may access theremote storage device145 that can contain the various templates needed to generate device-specific commands for different types, brands and/or models of network devices. Each of these templates can contain variable fields corresponding to either information stored in the configuration records or information input directly by the administrator. Thenetwork manager unit140 generates the device-specific commands by retrieving the appropriate template and filling in the variable fields with the data from the configuration records and/or data input directly by theadministrator110. Once generated, these device-specific commands can be stored in the configuration record and/or they can be stored in theremote storage device145 with an appropriate pointer stored in the configuration record.
• As can be appreciated by those skilled in the art, the[0030]network manager unit140 can be implemented on virtually any hardware system. Good results, however, have been achieved using components running the Red Hat™ LINUX Operating System and the Sun Solaeis™ UNIX Operating System. In embodiments running either of these operating systems, thenetwork manager unit140 is configured to utilize the common services provided by that particular operating system.
• Referring now to FIG. 3, there is illustrated in more detail the[0031]network manager unit140 shown in FIG. 2. This embodiment of thenetwork manager unit140 includes six basic modules: aninterface160, adirectory165, apolicy manager170, anevent bus175, ahealth manager180 and anaction manager185. The illustrated connections between the various components are exemplary only. The components can be connected in a variety of ways without changing the basic operation of the system. Although the division of thenetwork manager unit140 into the six components is the presently preferred embodiment, the functions of these components could be subdivided, grouped together, deleted and/or supplemented so that more or less components can be utilized in any particular implementation. Thus, thenetwork manager unit140 can be embodied in several forms other than the one illustrated in FIG. 3.
• Referring first to the[0032]interface module160, it is designed to exchange data with the administrator110 (shown in FIG. 2) and, in some embodiments, with the network devices135 (also shown in FIG. 2). Although theinterface160 could implement virtually any type of interface, good results have been achieved using a graphical, web interface. Other interfaces can be based upon wireless protocols such as WAP (wireless application protocol).
• The second component of the[0033]network manager unit140 is theevent bus175. Theevent bus175 includes a central posting location for receiving messages relating to network events. For example, when a configuration for anetwork device135 is to be changed, an appropriate message can be published (or otherwise made available) to theevent bus175. Similarly, if a network condition such as an error occurs, an appropriate message can be published to theevent bus175. Notably, any message published to theevent bus175 can also be sent to theadministrator110 by way of theinterface160. Theadministrator110, however, does not necessarily need to respond to a received message for the event to be addressed by thenetwork manager unit140.
• To determine the proper response for a message posted to the[0034]event bus175, the received message can be compared against the policies stored in thepolicy manager170, which is a repository for the business and network policies and rules used to manage the network. By using these rules and policies, an administrator110 (shown in FIG. 2) can define a response for any event published to theevent bus175. The defined response can be virtually anything including reconfiguring a network device, shutting down a network device and notifying an administrator.
• In operation, the[0035]policy manager170 can read a message posted to theevent bus175. Alternatively, theevent bus175 can automatically push the message to thepolicy manager170. Either way, however, thepolicy manager170 uses the message to access the policy records that can be stored, for example, in a look-up table and to correlate the message to the appropriate response. Once thepolicy manager170 has determined the appropriate response, that response is published to theevent bus175 as a work order that can be read by theaction manager185 and subsequently executed. That is, theaction manager185 can read the work order from theevent bus175 and perform the necessary tasks to complete that work order. In other embodiments, the work order can be sent directly to theaction manager185. For example, assume that theaction manager185 reads a work order from theevent bus175 that indicates two routers—one a Cisco™ router and one a Juniper™ router—need to be enabled. Theaction manager185 can locate each of these routers and determine the device-specific code needed to enable them. The code required to enable the Cisco™ router, for example, might be “enable_router” and the code required to enable the Juniper™ router might be “router_enable.” Because theaction manager185 determines the appropriate device-specific code, however, the administrator110 (shown in FIG. 2) only needs to generically indicate that both devices are to be enabled. Theadministrator110 does not need to know the actual device-specific code required by each router.
• In other embodiments, the[0036]action manager185 can verify that the administrator110 (shown in FIG. 2) has authority to make changes to network devices without authorization from additional parties. If additional authorization is required, theaction manager185 can post an appropriate message to theevent bus175.
• Still referring to FIG. 3, the[0037]directory165 of thenetwork manager unit140 includes a central repository for storing the configuration records of each of the network devices connected to thenetwork manager unit140. For example, thedirectory165 could store a separate configuration record for each ofnetwork devices100,105,125 and130 shown in FIG. 2. In certain embodiments, several interconnected directories may be utilized, and in such systems, each directory can store a certain subset of the configuration records or a complete copy of all of the configuration records. Generally, such embodiments would employ multiple linkednetwork manager units140, and in the embodiment where complete copies of the configuration records are stored in different directories, synchronization techniques can be used to guarantee data integrity.
• The configuration records stored in the[0038]directory165 are searchable by way of theinterface160. That is, theadministrator110 or a component within the network manager140 (shown in FIG. 2) can initiate a search through theinterface160 and the results of that search can be made available to theadministrator110 through theinterface160. Moreover, the configuration records can be searched in any of a variety of ways. For example, the configuration records can be searched according to equipment type (e.g., routers, optical devices, etc.), device type (edge router, core router, etc.), device location, device manufacturer, device model, device name, operational status, etc.
• Referring now to the[0039]health manager180, it can be configured to monitor the overall health of the network and/or the health of individual network devices135 (shown in FIG. 2) within the network. Thehealth manager180 can operate in an active mode and/or a passive mode. In the active mode, the health manager actively polls at least some of thenetwork devices135 about their status, utilization, congestion, etc. In the passive mode, thevarious network devices135 automatically report to thehealth manager180. In either embodiment, however, thehealth manager180 can collect individual device information and model overall network health. Additionally, thehealth manager180 can publish messages regarding network device problems, projected network device problems, network problems, and/or projected network problems. Thepolicy manager170 can then determine the appropriate course of action to take for the particular message and theaction manager185 can implement that response.
• In further embodiments, the health manager can monitor the health of the network manager components. For example, the health manager can monitor the operation of the event bus, the action manager and/or the directory. Moreover, the health manager can monitor the flow of data between the various components of the network manager.[0040]
• Referring now to FIG. 4, there is illustrated in more detail the[0041]directory165 shown in FIG. 3. This embodiment of thedirectory165 consists of four interconnected modules: configuration storage187, configuration comparator190,configuration reader195 andinterface200. Thedirectory165, however, does not need all of the modules to function in accordance with the principles of the present invention.
• The[0042]configuration reader module195 of thedirectory165 is designed to initiate communication with (or directly communicate with) a target network device and retrieve that device's actual configuration. For example, the configuration reader can retrieve the actual configuration from thememory115 of router105 (shown in FIG. 2). This retrieved actual configuration can then be passed to the configuration comparator190. Theconfiguration reader195 can also retrieve the intended configuration of the target device from the configuration storage187 and pass that intended configuration to the configuration comparator190. The configuration comparator190 can then compare the actual configuration and the intended configuration and present the differences to the administrator110 (shown in FIG. 2). In one embodiment, the differences in the configurations are not only presented literally, but also in a natural language summary form. Once the differences have been identified, they can be used to identify a failed configuration installation and/or to aid the administrator in creating the proper configuration for a device.
• As previously discussed, the configuration storage[0043]187 is designed to store configuration records corresponding to network devices such asnetwork devices135 shown in FIG. 2. In one embodiment the configuration storage187 is designed not only to store the present configuration record for a network device, but also to store previous configuration records for that device. By storing these previous configurations, fault recovery and correction are vastly improved over present systems because prior, successful configurations can be quickly retrieved and used to replace new, faulty configurations. For example, a prior configuration of a previously known good state can be retrieved and installed on the associated network device. This prior configuration could be days old or even weeks old. Prior configuration records can be distinguished by version numbers and/or a time stamp. Additionally, each configuration record can include a searchable summary that includes notes on the configuration and why that configuration was modified.
• Referring now to FIG. 5, there is illustrated a[0044]configuration record205 for a typical network device. Thisconfiguration record205 is divided into four portions: a common information model (“CIM”) data portion210, avendor data portion215,proprietary data portion220 and adata pointer225. The CIM data portion210 contains data relating to the physical attributes of a particular network device such as name, device type, number of interfaces, capacity, etc. The CIM data items are defined in the CIM Specification v2.2 and the CIM Schema v2.4, both of which are well known in the art and incorporated herein by reference.
• The[0045]vendor data portion215 of the configuration record contains standard vendor-specific data regarding the particular network device. For example, thevendor data portion215 could indicate which version of an operating system that the network device is running or which features of the device are enabled. Generally, the data in thevendor data portion215 is specific to each manufacturer and even to each model of network device.
• The[0046]proprietary data portion220 of the configuration record can contain data used by the network manager unit in configuring and managing the network devices. In one embodiment, for example, theproprietary data portion220 includes a pointer to an address at which a core dump for a network device is stored. That is, if a router initiates a core dump, the location of that core dump could be recorded in theproprietary data portion220 of the configuration record for that router. In other embodiments, theproprietary data portion220 can store version numbers, time stamps, health records for a particular configuration, configuration summary data, configuration notes, etc.
• The[0047]pointer portion225 of theconfiguration record205 can be used to point to a storage location where the actual device-specific commands for the associated network device are stored. Similarly, thepointer225 could be configured to point to a storage location for a device-specific template for configuring a newly installed network device. In other embodiments, thepointer portion225 of the configuration record can be supplemented or replaced with a storage location for actual device-specific code.
• Referring now to FIG. 6, there is illustrated in more detail the[0048]event bus175 shown in FIG. 3. As previously described, theevent bus175 is a posting location for messages relating to network events. Network devices as well as the other components of the network manager unit140 (shown in FIG. 2) can address and post events to theevent bus175.
• The particular embodiment of the[0049]event bus175 shown in FIG. 6 is comprised of four basic modules: an interface230, a status storage235, anevent queue240, and anevent queue manager245. In operation, a message indicating the occurrence of a network event is posted to theevent queue240 by way of the interface230. The messages stored at theevent queue240 are then made available to the policy manager170 (shown in FIG. 3), so that a proper response can be determined. If the posted message is a work order from thepolicy manager170, the work order is made available to the action manager185 (shown in FIG. 3) for subsequent implementation.
• In one embodiment of the[0050]event bus175, an event message is stored in status storage235 along with a status field and an age field. Thus, for any message posted to theevent bus175, its status and age can be continuously monitored. (The event bus can also get messages from client devices.) For example, status storage235 could indicate that the status for a particular event is pending in the action manager185 (shown in FIG. 3), awaiting proper authorization, completed, stalled, etc. As the status changes from one status to another, appropriate messages can be generated and posted at theevent queue240. For example, if the status of an event changes from pending to stalled, an appropriate message can be posted to theevent queue240 so that thepolicy manager170 can determine how to respond. Similarly, if the age field in the status storage235 indicates that a particular network event has not been addressed within a predetermined amount of time, that event can be requeued, deleted from theevent queue240, or a new event notification indicating the delay can be generated and placed on theevent queue240.
• Referring now to FIG. 7, there is a flow chart of one method for configuring or reconfiguring a network device in accordance with the principles of the present invention. In this embodiment, the administrator[0051]110 (shown in FIG. 2) initially logs in to the network manager unit140 (Step250). Through a series of a graphical interfaces, theadministrator110 can select a network device that needs to be configured or reconfigured. The configuration record associated with the selected device can then be retrieved from the directory165 (shown in FIG. 3) and presented to the administrator (Step255). If no configuration record is available for a selected device, theadministrator110 will be guided through a series of steps to build the configuration for that device. Otherwise, theadministrator110 can change parameters within the configuration record of the selected device and save those altered configuration records within the directory165 (Step260). Notably, even though the configuration record for the selected network device has been changed, the actual configuration of the device has not been changed. Before the configuration of the device can be changed, an event message indicating that a configuration record has been altered should be published to the event bus175 (shown in FIG. 3) (Step265). The policy manager170 (shown in FIG. 3) then receives the event message, either by reading it from theevent bus175 or by receiving it from theevent bus175, and determines if the configuration change is authorized (Step270). If the configuration change is within the network rules and the administrator110 (shown in FIG. 2) is authorized to make the change, a work order is published to the event bus (Step280). The action manager185 (shown in FIG. 3) can then read the work order from theevent bus175 and carry out the necessary steps to implement the work order (Step280).
• In one embodiment, the action manager[0052]185 (shown in FIG. 3) carries out the work order by locating the target network device, retrieving the appropriate configuration record from the directory165 (shown in FIG. 3), generating the device-specific code corresponding to the altered configuration (Step290), and pushing the device-specific code to the target network device (Step295). Theaction manger185 can also store the device-specific code in a remote storage device, such asremote storage device145 shown in FIG. 2, and a pointer to the remote storage device can be recorded in the configuration record. Finally, theaction manager185 can verify that the device-specific code was properly transferred to the selected network device and that the network device is behaving accordingly (Step300). Assuming that the device-specific codes were installed correctly and that the network device is operating properly, a completion message is published to the event bus175 (shown in FIG. 3) (Step305).
• In conclusion, the present system provides, among other things, a method and apparatus to configure, monitor and manage network devices without regard for device type and/or manufacturer. Those skilled in the art, however, can readily recognize that numerous variations and substitutions may be made in the invention, its use and its configuration to achieve substantially the same results as achieved by the embodiments described herein. Accordingly, there is no intention to limit the invention to the disclosed exemplary forms. Many variations, modifications and alternative constructions fall within the scope and spirit of the disclosed invention as expressed in the claims.[0053]

Claims (20)

What is claimed is:

1. A method for generating a configuration record for a network device, the method comprising the steps of:

receiving general configuration information relating to a network device, the general configuration information including a device type indicator, a device manufacturer indicator, and a device name;

receiving vendor-specific configuration information, wherein the vendor-specific configuration information corresponds to the device manufacturer indicator; and

generating a configuration record for the network device, the configuration record including the received general configuration information and the received vendor-specific configuration information.

2. The method ofclaim 1, wherein the step of receiving general configuration information comprises the step of:

receiving common information model (CIM) data.

3. The method ofclaim 1, further comprising the step of:

generating device-specific configuration commands for the network device associated with the configuration record.

4. The method ofclaim 3, wherein the step of generating a configuration record further comprises the step of:

including at least an indication of the generated device-specific configuration commands with the generated configuration record.

5. The method ofclaim 4, wherein the at least an indication of the device-specific configuration commands comprises a pointer to a storage address where the device-specific configuration records are stored.

6. The method ofclaim 1, further comprising the step of:

receiving at least an indication of a data dump, the data dump being generated by the network device; and

storing the at least an indication of the data dump in the configuration record associated with the network device.

7. The method ofclaim 1, further comprising the step of:

retrieving the vendor-specific configuration information from a remote storage system that is associated with a vendor.

8. The method ofclaim 1, further comprising the step of:

storing the generated configuration record in a central repository configured to store a plurality of configuration records.

9. A data configuration record corresponding to a network device, the data configuration record comprising:

a general configuration data module for storing general information;

a vendor-specific data module for storing vendor-specific information; and

a configuration command data module for storing data associated with device-specific configuration commands for the network device.

10. The data configuration record ofclaim 9, wherein the general configuration data module is configured to store CIM (common information model) data.

11. The data configuration record ofclaim 9, wherein the configuration command data module is configured to store a pointer to a storage location containing the device-specific configuration commands corresponding to the network device.

12. The data configuration record ofclaim 9, wherein the configuration command data module is configured to store device-specific configuration commands.

13. The data configuration record ofclaim 9, stored in a central repository for storing a plurality of data configuration records.

14. A system for generating a configuration record for a network device, the system comprising:

at least a first processor:

at least a first memory device electronically connected with the at least a first processor; and

a plurality of instructions stored on the at least a first memory device, the plurality of instructions configured to cause the at least a first processor to:

receive general configuration information relating to a network device, the general configuration information including a device type indicator, a device manufacturer indicator, and a device name;

receive vendor-specific configuration information, wherein the vendor-specific configuration information corresponds to the device manufacturer indicator; and

generate a configuration record for the network device, the configuration record including the received general configuration information and the received vendor-specific configuration information.

15. The system ofclaim 1, wherein the general configuration information comprises common information model (CIM) data.

16. The system ofclaim 1, wherein the plurality of instructions are further configured to cause the at least a first processor to:

generate device-specific configuration commands for the network device associated with the configuration record.

17. The system ofclaim 16, wherein the plurality of instructions are configured to cause the at least a first processor to generate the configuration record by:

including at least an indication of the device-specific configuration commands with the generated configuration record.

18. The system ofclaim 17, wherein the at least an indication of the device-specific configuration commands comprises a pointer to a storage address where the configuration records are stored.

19. The system ofclaim 18, wherein the plurality of instructions are further configured to cause the at least a first processor to:

receive at least an indication of a data dump, the data dump being generated by the network device; and

store the at least an indication of the data dump in the configuration record associated with the network device.

20. The system ofclaim 14, further comprising:

a central repository electronically coupled with the at least a first processor, the central repository configured to store the generated configuration record.

Images