Batch configuration mode for configuring network devices

In general, techniques are described for a batch configuration mode for configuring network devices. A network device comprising a committed data source and a control unit may implement the techniques. The control unit may receive a plurality of separate commit commands instructing the network device to commit configuration changes to the committed data source. Each of the plurality of commit commands instructs the network device to commit an associated portion of the configuration changes to the committed data source. The control unit then groups two or more of the plurality of separate commit commands to form a batch of commit commands and executes the batch of commit commands to commit the portions of the configuration changes associated with the grouped commit commands to the committed data source as if the grouped portions of the configuration changes were associated with a single commit command.

TECHNICAL FIELD

The invention relates to computer networks, and more particularly, to configuring devices within computer networks.

BACKGROUND

A computer network is a collection of interconnected computing devices that exchange data and share resources. In a packet-based network, such as the Internet, the computing devices communicate data by dividing the data into small blocks called packets. The packets are individually routed across the network from a source device to a destination device. The destination device extracts the data from the packets and assembles the data into its original form. Dividing the data into packets enables the source device to resend only those individual packets that may be lost during transmission.

Certain devices within the network, referred to as routers, maintain tables of routing information that describe available routes through the network. Each route defines a path between two locations on the network. Upon receiving an incoming data packet, the router examines header information within the packet to identify the destination for the packet. Based on the header information, the router accesses the routing table, selects an appropriate route for the packet and forwards the packet accordingly.

Conventional routers typically include a mechanism, referred to herein as a management interface, for directly or remotely configuring the router. By interacting with the management interface, various clients, such as human users and automated scripts, can perform numerous configuration tasks. For example, the clients may configure interface cards of the router, adjust parameters for the supported network protocols, specify the physical components within the routing device, modify the routing information maintained by the router, access software modules and other resources residing on the router, and the like.

In some routers, the management interface allows a client to configure the present configuration of the router using a commit-based model. In a commit-based model, a client issues one or more configuration commands, and then directs the management interface to apply the commands by issuing a “commit” command (alternatively, a “commit”). Typically, the client may direct the management interface to disregard the commands by issuing a “rollback” command.

For example, a client typically places the router in a configuration mode, often by issuing an edit command to the management interface. In this mode, the management interface may essentially “lock” the router, and reject any configuration commands from other clients. Next, the client typically issues a number of commands directing the management interface to modify the present configuration, followed by a commit command that directs the router to apply the configuration changes specified by the commands. Upon receiving the commit command, the management interface applies the changes to the present configuration, thereby adjusting the operation of the router. The management interface may then exit the configuration mode, effectively “unlocking” the router and allowing configuration by another client.”

As the complexity of computing networks has increased, there has been an increasing need for routers and other network devices to support concurrent configuration by multiple clients. Consequently, some devices allow multiple clients to concurrently issue configuration commands. In other words, the management interface of such a device does not “lock” the configuration of the device to a single client, but receives configuration commands from multiple clients while operating in the configuration mode. When the management interface receives a commit command from any of the clients providing commands, the management interface applies all of the pending changes from all of the concurrent clients to the present configuration. These techniques can be problematic in that partial changes made by a client may be committed in response to a commit command from another client. Furthermore, uncommitted changes made by a client may be lost when another client issues a “rollback” command.

As a result, routers have been adapted to provide for a private configuration mode in which a client may operate on a copy of the configuration data of the router separate from the current configuration data. When a commit is issued by the client in this private configuration mode, the router updates the current configuration data to reflect any changes made by the client to the copy of the configuration data without committing any other configuration changes to the configuration data by other clients. While in this private configuration mode, the router does not lock the actual configuration considering that the client is operating on a copy of the current configuration data. As a result, the router may enable multiple clients to operate concurrently in the private configuration mode, each of which may be operating on a separate copy of the configuration data.

While the private configuration mode may facilitate concurrent configuration of the router, the concurrent configuration mode may result in the router receiving multiple commit commands from multiple clients within a short period of time (if not, nearly concurrently). The router may store these commit commands to what may be referred to as a “commit queue” and process these commit commands sequentially in the order these commit commands were stored to the commit queue. Consequently, the router may not execute the commit command stored last in the commit queue for multiple seconds (or even minutes), resulting in significant delay that may detract from the user experience.

SUMMARY

In general, techniques are described for enabling a network device to perform batch configuration operations. More specifically, the techniques may enable a network device, such as a router, to operate in a batch configuration mode in which configuration changes associated with multiple commits are grouped together to form a batch job. The batch job may effectively enable the network device to commit configuration changes associated with multiple commit commands together in a single configuration operation, rather than committing the configuration changes sequentially. For example, the techniques may aggregate configuration changes, for which respective commit commands have been received, made to respective copies of the configuration data and commit the aggregated configuration changes to the current configuration data of the network device as if the aggregated configuration changes were a single configuration change responsive to a single commit. By aggregating the configuration changes across multiple copies and committing these changes in the aggregate, the techniques may increase the number of commits that a router may perform during a given period of time (which may, in other words, increase throughput of device configuration changes). The improved commit command throughput may reduce delays in performing commit commands and, thereby, result in an improved user experience in comparison to conventional routers that execute commit commands in a sequential and separate manner.

In one aspect, a method comprises receiving, with a network device, a plurality of separate commit commands instructing the network device to commit configuration changes to a committed data source that stores current configuration data for the network device, wherein each of the plurality of commit commands instructs the network device to commit an associated portion of the configuration changes to the committed data source, grouping, with the network device, the portions of the configuration changes associated with two or more of the plurality of separate commit commands to form a batch job and executing the batch job to commit the grouped portions of the configuration changes associated with the two or more of the plurality of separate commit commands to the committed data source as if the grouped portions of the configuration changes were associated with a single commit command.

In another aspect, a network device comprises a committed data source that stores current configuration data for the network device and a control unit that receives a plurality of separate commit commands instructing the network device to commit configuration changes to the committed data source, wherein each of the plurality of commit commands instructs the network device to commit an associated portion of the configuration changes to the committed data source. The control unit groups two or more of the plurality of separate commit commands to form a batch of commit commands, wherein the batch of commit commands instructs the network device to commit the portions of the configuration changes associated with the grouped two or more of the plurality of separate commit commands to the committed data source and executes the batch of commit commands to commit the portions of the configuration changes associated with the grouped two or more of the plurality of separate commit commands to the committed data source as if the grouped portions of the configuration changes were associated with a single commit command.

In another aspect, a non-transitory computer-readable medium comprising instructions that, when executed, cause one or more processor of a network device to receive a plurality of separate commit commands instructing the network device to commit configuration changes to a committed data source that stores current configuration data for the network device, wherein each of the plurality of commit commands instructs the network device to commit an associated portion of the configuration changes to the committed data source, group two or more of the plurality of separate commit commands to form a batch of commit commands, wherein the batch of commit commands instructs the network device to commit the portions of the configuration changes associated with the grouped two or more of the plurality of separate commit commands to the committed data source and execute the batch of commit commands to commit the portions of the configuration changes associated with the grouped two or more of the plurality of separate commit commands to the committed data source as if the grouped portions of the configuration changes were associated with a single commit command.

The details of one or more embodiments of the techniques are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the techniques will be apparent from the description and drawings, and from the claims.

DETAILED DESCRIPTION

FIG. 1is a block diagram illustrating an example network system10that implements the batch execution of configuration commands in accordance with the techniques described in this disclosure. Network system10comprises a network12that may be accessed by users14A to14C (collectively users14) via one of links16A to16C (collectively links16). Each of users14represents an entity, such as an individual or an organization, that accesses network12to communicate with other users connected to network12. Links16may be Ethernet or other network connections.

Network12includes a network device18, which represents any type of device capable of operating within network system10, such as a network hub, network switch, network router, or the like. Network device18may include an interface that allows various clients20, such as human users, automated scripts executed by a computing device or network management system (NMS), to configure network device18by specifying protocols to follow, physical arrangements of hardware, or the like. For example, network device18may be a network router, and clients20may specify configuration information to configure interface cards of the router, adjust parameters for the supported network protocols, specify the physical components within the routing device, modify the routing information maintained by the router, and/or access software modules and other resources residing on the router to name a few examples.

Network device18may supports a command syntax in which a configure command may optionally specify a particular configuration mode. More specifically, the configure command may include an additional parameter that specifies an exclusive mode or a private mode. Upon receiving a configure exclusive command from one of clients20, network device18locks the primary configuration, and only allows the requesting client to make changes to the present configuration.

In response to a configure private command from one of clients20, network device18enters a private configuration mode in which multiple clients20can issue configuration commands to device18. In particular, for each of clients20that issues a configure private command, network device18creates a respective private data source from a committed data source that stores the present or current configuration of the device. Network device18applies subsequent configuration commands from clients20to their respective private data sources. Upon receiving a commit command from any given one of clients20, network device18merges the edited data of the private data source into configuration data of the committed data source. In particular, network device18generates a “patch” representing the changes to the private data source, and applies the patch into the committed data source.

When applying the patch, network device18resolves any conflicts that may exist between the private data source being committed and any changes to the committed data source made by other clients20while the private data source was being edited. If one of clients20issues a rollback command when in private configuration mode, only the respective private data source created for the client is discarded and refreshed. Consequently, clients20may edit the private data source without risk of premature commitment of the changes, or loss of the changes, due to another one of clients20.

While the private configuration mode may facilitate concurrent configuration of network device18, this concurrent configuration mode may result in network device18receiving multiple commit commands from multiple clients within a short period of time (and possibly, nearly concurrently). Network device18may then store these commit commands to what may be referred to as a “commit command queue” and process these commit commands sequentially in the order these commit commands were stored to the commit command queue. Consequently, network device18may not execute the commit command stored last to the commit queue for multiple seconds (or even minutes), resulting in significant delay that may detract from the user experience.

To illustrate, assume multiple clients20each concurrently establish a session with network device18to configure network device18. Network device18may therefore maintain a plurality of configuration sessions with multiple ones of clients20. Via these sessions, each of these ones of clients20may enter a private configuration mode, where network device18generates a private data source from the committed data source. Clients20may further, via their respective sessions, edit the private data source, effectively making configuration changes to the private data source. Two or more of clients20may finish making configuration changes within a short period of time from one another and specify a commit command. Network device18receives these commit commands and stores them to the commit command queue, executing these commit commands sequentially in the order in which the respective commit commands were received with respect to one another. Each commit command may require multiple seconds to execute, as committing the changes to the committed data source may involve a process to ensure the changes to be committed will not result in a failed or nonoperational state once committed. Thus, if many commit commands are issued within a short period of time from one another, network device18may not even begin to process the last commit command enqueued to the commit command queue for potentially tens of seconds or possibly a minute or longer from the time at which network device18received the last commit command.

In accordance with the techniques described in this disclosure, network device18may perform batch configuration operations to potentially improve data configuration throughput. More specifically, the techniques may enable network device18to execute in a batch configuration mode in which network device18may aggregate or group configuration changes associated with two or more commit commands to form a batch job. Network device18may then execute the batch job to effectively commit configuration changes that are associated with multiple separate commit commands as a single operation, rather than committing the configuration changes sequentially. In other words, the techniques may aggregate configuration changes to configuration data for which a commit command has been received and commit all of the configuration changes across these copies of the configuration data (i.e., the private data sources in the above example) to the committed data source. By aggregating the configuration changes across multiple copies of the configuration data and committing these changes in the aggregate, the techniques may increase the number of commits that network device18may perform during a given period of time (which may, in other words, increase throughput of device configuration changes). The improved commit command throughput may reduce delays in performing commit commands and thereby result in an improved user experience in comparison to conventional routers that execute commit commands in a sequential and separate or individual manner.

In operation, network device18receives a plurality of separate commit commands instructing network device18to commit configuration changes to the committed data source that stores current configuration data for network device18. As noted above, each of the plurality of commit commands instructs the network device to commit an associated portion of the configuration changes (i.e., those made with respect to associated ones of the private data sources in the example above) to the committed data source. Network device18then groups configuration changes associated with two or more of the plurality of separate commit commands, thereby forming a batch job. Network device18then executes the batch job to commit the portions of the configuration changes associated with the two or more of the plurality of separate commit commands to the committed data source.

In the context of private data sources, rather than repeatedly determining any changes between the private data source for which a commit command has been received and the committed data source, validating the determined changes to ensure the changes will not result in the failure of network device18, and entering the changes to the committed data source, the techniques may effectively merge multiple private data sources for which a commit command has been received, validate the merged private data sources to ensure the changes will not result in the failure of network device18, and enter the merged private data sources to the committed data source. By aggregating the process in the manner described above, the techniques may increase the number of commits that network device18may perform during a given period of time, thereby potentially improving the user experience.

FIG. 2is a block diagram illustrating an example network router24that supports the batch execution of configuration commands in accordance with the techniques described in this disclosure. Router24includes a set of one or more interface cards (IFCs)26that receive and send packets via network links28and30, respectively. IFCs26are typically coupled to network links28,30via one or more interface ports.

Router24further comprises a control unit32that maintains routing information34. Routing information34describes the topology of network12and, in particular, routes through network12. Routing information34may include, for example, route data that describes various routes within network12, and corresponding next hop data indicating appropriate neighboring devices within network12for each of the routes. Routing information34is periodically updated to accurately reflect the topology of network12. In general, router24receives a packet via inbound network link28and control unit32determines the destination address of the packet and outputs the packet on an outbound network link30based on the destination.

Control unit32may receive configuration input from one or more of clients20via an input/output (I/O) interface38. I/O interface38may be a command line interface (CLI) or other suitable interface, for processing user or script-driven commands. Control unit32may store the configuration input received from one or more of clients20as configuration data40, which may take the form of a text file, such as an ASCII file. Alternatively, control unit32may process the configuration input and generate configuration data40in any one of a number of forms, such as one or more databases, tables, data structures, or the like.

In response to receiving a configure command, a management module of router24may parse the command, and place router24in a configuration mode for receiving configuration data40from one of clients20. Configuration data40may take the form of one or more commands for adding new settings to the current configuration of the router, commands for deleting or modifying existing settings of the current configuration, or combinations thereof. Router24may further parse configuration data40, input from one or more of clients20, and resolve the references to appropriately configure router24. Upon receiving a commit command, the management module applies configuration data40to router24.

In this manner, a syntax for the configuration command may be expressed as follows:

where configuration mode may specify private or exclusive, and is optional (as denoted above by the use of square brackets ‘[’ and ‘]’).

The following pseudocode illustrates an exemplary use of a configure command having a “private” configuration mode:

user@host> configure private

In the above pseudocode client20issues a configure private command directing router24to enter a configuration mode and, more particularly, to enter a private configuration mode. While in the private configuration mode, client20then issues a command to modify the current host name of router24, i.e., set system host-name. Finally, client20issues a commit command directing router24to verify and accept the changes.

As described above, one or more of clients20may interface with router24via input/output interface38to concurrently configure router24. In instances where multiple ones of clients20are concurrently entering configuration data40, each of these multiple ones of clients20may enter the private configuration mode and input configuration data40. Often, these multiple ones of clients20may specify configuration data40and then attempt to commit the input configuration data40within short periods of time of one another (and may, in some instances, attempt to commit the configuration data40nearly concurrently).

The commit process, however, as noted above may involve a number of sub-processes that check the integrity of entered configuration data40before committing entered configuration data40to the operational or current configuration data. In other words, control unit32of router24may, upon receiving a commit command, verify that configuration data40input by the one of clients20that entered the commit command, will not result in router24becoming inoperative. Given the complexity of routers24, especially those of routers24that serve in the core of service provider networks that provide data throughput on the order of hundreds of gigabytes per second, control unit32may implement an involved integrity checking process with respect to any entered configuration data40that is to be committed. This process may take multiple seconds, if not more time, to complete. Consequently, control unit32may store commit commands to a commit queue, which, while not shown inFIG. 2, is described in more detail with respect toFIG. 3below. This commit queue may buffer commit commands that are received by control unit32in a short amount of time until control unit32may implement the verification process with respect to each of the commit commands.

Rather than perform this process sequentially with respect to each commit command in the commit queue, control unit32may implement the techniques described in this disclosure to batch commit commands (or, in other words, form a batch job), thereby grouping configuration data40associated with multiple different commits from, often, multiple different ones of clients20into a single group of configuration data40. Control unit32may then perform the verification process with respect to grouped configuration data40, which may significantly reduce the time required to commit the associated configuration data40in comparison to sequentially processing configuration data40associated with each of the commit commands stored to the commit queue. More detail with respect to how control unit32may group configuration data40is described below with respect to the example ofFIG. 3.

FIG. 3is a block diagram illustrating an example control unit32that supports batch commit commands in accordance with the techniques described in this disclosure. Control unit32comprises a management module42that communicates with one or more of clients20via a command line interface (CLI)44. CLI44serves as a daemon process that listens for requests from clients20. Upon receiving a request from one of clients20, CLI44may relay the request to management module42. However, CLI44may give way to direct communication between client20and management module42.

Control unit32may further include one or more software modules46A to46N, collectively referred to as “software modules46.” Software modules46represent processes (which may also be referred to as “threads of execution”), and typically execute within an operating environment provided by an operating system. Software modules46may, for example, include a routing protocol module to administer protocols supported by router24, a chassis module to account for the physical components of router24, a device configuration module to control the physical configuration of router24or the like.

Control unit32may include a committed data source (referred to as committed database (COMMIT DB)48) that stores a present configuration of router24. In other words, router24operates in accordance with configuration information stored in committed database48. Control unit32may further include a shared data source (referred to as shared database (SHARED DB)50) that contains a copy of the configuration data of committed database48, and is typically used for editing the configuration without impacting operation of router24. For example, clients20may access shared database50simultaneously and each of clients20may make changes to the configuration data stored in shared database50.

Management module42may receive a command from one of clients20to configure router24. Management module may parse the command from client20, and place router24in the configure mode requested by client20. Router24may be configured using one of several different configuration modes, such as a default configuration mode (referred to as configure mode), an exclusive configuration mode, a private configuration mode, or the like.

By issuing a configuration command without specifying a configuration mode, management module42operates in the default configuration mode and allows clients20to concurrently edit configuration data in shared database50. If one of clients20issues a commit command, all of the changes, complete or incomplete, made by clients20may be committed to committed database48.

In exclusive configuration mode, management module42allows one of clients20to edit configuration data of shared database50. However, when configuring in exclusive configuration mode, shared database50may be locked, allowing for only one client20at a time to edit configuration data of shared database50. The lock may further prevent client20from creating any interference from other clients20when issuing a commit or rollback command. When receiving a commit command from the client20for which an exclusive lock has been granted, management module42copies shared database50to the committed database48.

In private configuration mode, management module42allows clients20to edit configuration data in respective private data sources, referred to as private databases (PRIVATE DB)52. For each of clients20that issue a configure private command, management module42creates a respective private database52, each of which represent a copy of committed database48created at the time the management module42receives the corresponding configure command. In addition, management module42may generate a copy of a configuration text file54, such as an ASCII configuration file, which may contain configuration data that is used by control unit32during restart. Upon receiving a commit command from any given one of clients20, management module42generates a patch by comparing changes made to private database52with the configuration data of text file54. Management module applies the patch into committed database48, and resolves any conflicts that may exist between private database52being committed and any changes to the committed database48made by other clients20while the private database was being edited.

More information regarding the private configure mode, patch generation and application of a patch can be found in U.S. Pat. No. 7,233,975, entitled “PRIVATE CONFIGURATION OF NETWORK DEVICES,” filed Aug. 19, 2002; U.S. Pat. No. 7,558,835, entitled “APPLICATION OF A CONFIGURATION PATCH TO A NETWORK DEVICE,” filed Mar. 17, 2003; U.S. Pat. No. 7,483,965, entitled “GENERATION OF A CONFIGURATION PATCH FOR NETWORK DEVICES,” filed Jan. 9, 2003; and U.S. Pat. No. 7,865,578, entitled “GENERATION OF A CONFIGURATION PATCH FOR NETWORK DEVICES,” filed Nov. 20, 2006, each of which is hereby incorporated by reference as if set forth herein in their entirety.

Independent of the configuration mode entered by client20, upon issuing a commit command, management module42validates the updated configuration. In one example, management module42determines whether the configuration data conforms to a schema55of the committed database. More specifically, schema55describes a proper syntax to which the configuration information must conform in order to be compatible with all of software modules46. In addition, management module42may direct software modules46to validate specific parameters or settings within the updated configuration data.

Based on the validation, management module42may either reject the pending configuration data, or accept the pending configuration data. For example, management module42may accept the pending configuration data, and update the configuration data of committed database48to reflect the changes made by client20. Management module42may then proceed to notify software modules46that committed database48contains updated configuration information. Software modules46may retrieve the new configuration data from committed database48, and router24may begin to operate in accordance with the new configuration data.

This process of determining the difference and then validating the entered configuration data may take several seconds or more time. Typical delays are often 30 seconds or more, where delays of this order result in a poor user experience. To illustrate, assume five of clients20are concurrently interfacing with CLI44to enter configuration data via 5 different TTY sessions, which are assumed to be virtual TTY session and may be denoted as “Vty1,” “Vty2,” “Vty3,” “Vty4” and “Vty5.” Moreover, assume a standard delay to process configuration data after receiving a commit command to be 30 seconds and that each of the five different ones of clients20each, after entering configuration data, nearly concurrently enter a commit command. The following Table 1 illustrates how conventional routers that do not implement the batch commit process in accordance with the techniques of this disclosure may process the commit commands.

In comparison, the following Table 2 illustrates the batch commit process as implemented by management module42of control unit32in accordance with the techniques described in this disclosure. Maintaining the assumptions made above with respect to Table 1 when considering Table 2, Table 2 demonstrates how router24may significantly reduce the amount of time required to process multiple commit commands through performing the batch commit techniques described in this disclosure.

TABLE 2timevty1vty2vty3vty4vty50set aset bset cset dset e0commitcommitcommitcommitcommit30 sdone. . .. . .. . .. . .1 mdonedonedonedone
In Table 2, management module42receives five commit commands nearly concurrently via Vty1-Vty5. Management module42may process the first commit command from Vty1 in the manner described above and, while processing the first commit command, implement the techniques described in this disclosure to “batch” the second through fifth commit commands, forming a single “job” that groups all configuration data associated with each of the second through fifth commit commands. Management module42may then execute this single job, validating the configuration data associated with each of these second through fifth commits commands as if this configuration data was entered via a single session and committed at once instead of sequentially entered and committed through four different sessions. Management module42may therefore take only 30 seconds to process the first commit command and then another 30 seconds to process the “job,” for a total time of one minute. In comparison to the two minutes and 30 seconds it may take a conventional router to sequentially process all five commit commands, management module42may enter the same amount of configuration data in approximately one minute, which may significantly improve throughput in processing commit commands.

In operation, one or more of clients20may enter a “batch” configuration mode that may be similar to the private configuration mode. That is, in response to the “configure batch” command, management module42may allocate, create or otherwise provide a private DB52for private editing of configuration data in the manner described above. The following pseudocode illustrates an exemplary use of a configure command having a “batch” configuration mode:

When the one of clients20that entered the batch configuration mode, enters the “commit” command, control unit32generates a file (which may be similar to the patch file described above) containing the changes made during the batch configuration session. Control unit32may execute what may be referred to as a “commit server” that monitors a directory or other memory location to which these patch files are stored (i.e., commit queue56in the example ofFIG. 3). The commit server is shown as a commit server58in the example ofFIG. 3.

In response to detecting one or more patches stored to commit queue56, commit server58enters an edit exclusive mode, generates a single batch patch file from the one or more patch files stored to commit queue56(by performing a so-called “load patch” process) and commits the single batch patch file to commit database48(after performing the verification of the single batch patch file in the manner described above). After committing the single batch patch file, commit server58may continue to monitor commit queue56, generating batch patch files and committing the generated batch patch files to commit database48.

In some instances, commit server58may process patch files stored to commit queue56back-to-back with some fixed pause between commits The pause may provide time for modules46to consume the committed configuration changes. In consuming these configuration changes, execution of modules46may significantly increase the amount of processing resources required resulting in what may be referred to as a “high system load.” Commit server58may pause so as not to further increase the system load. In other instances, commit server58may perform commits separately and sequentially until system load exceeds a certain threshold or load level. Once the system load (as monitored by commit server58or provided by another one of modules46) reaches the threshold, commit server58may begin batching patch files to generate batch patch files. In this sense, commit server58may dynamically perform batch commit of configuration data in response to a determination that a metric (such as system load or any other metric, including processor utilization, memory consumption, etc.) exceeds a threshold.

Additionally, in the batch configuration mode, management module42may provide for two types or modes of batch configuration, referred to as an “asynchronous” mode and a “synchronous” mode. In the asynchronous batch configuration mode, management module42adds patch files to commit queue56in response to receiving a commit command. In this instance, commit server58may detect the patch files, generate the batch patch file and commit the batch patch file to commit DB48. Management module42may then exit the edit batch session without waiting for commit server58to finish (and receiving notification of the failure and/or success of the commit from commit server58asynchronously via a system log, hence the name “asynchronous batch configuration mode”). The entries in the system log may include a batch identifier associated with the asynchronous batch configuration mode and any comment added by the one of clients20(or a network management system with which the one of clients20is interacting to configure router24), such as a queue identifier and commit batch comments. Management module42may return the prompt to the user via CLI44, allowing the one of clients20that invoked the asynchronous batch configuration mode to enter additional configuration commands prior to completion of the commit command for the previous asynchronous batch configuration mode.

An example of the asynchronous mode follows below:

router# configure batchrouter# set system host-name foorouter# show | compare[edit system]− host-name bar+ host-name foorouter# commitAdded to commit queue request-id: 1343026router#
In the asynchronous example, the prompt “router#” is returned nearly immediately after entering the “commit” command (and after displaying that the commit has been added to the commit queue with a request identifier (id) of “1343026”).

Alternatively, in the synchronous batch configuration mode, management module42adds the patch to commit queue56in response to receiving a commit command (where commit server58may detect the patch files, generate the batch patch file and commit the batch patch file to commit DB48). Management module42does not return the prompt to the one of clients20that invoked the synchronous batch configuration mode, but waits for commit server58to finish committing the configuration changes to commit database48. Commit server58typically notifies management module42of the success and/or failure of the commit. Management module42may present this success and/or failure via CLI44to the one of clients20that invoked the configuration mode. On successful commit, management module42may present a success message via CLI44and return the prompt to the one of clients20, maintaining the synchronous batch configuration session. On failure of the commit, management module42may present a failure message via CLI44and return the prompt to the one of clients20, maintaining the synchronous batch configuration session. Management module42may also update the system log to include the success/failure messages in the manner described above.

An example of the synchronous mode follows below:

To configure commit server58, one or more of clients20may enter configuration information to control the maximum number of patch files that may be aggregated to form a batch patch file (or “job”), a maximum number of patch files that may be queued, whether the batch configuration mode is asynchronous or synchronous, a commit interval that indicates a time in seconds to wait between starting the next job and other configuration information regarding the system log, such as a number of days to keep error logs. As one example, the commit server configuration information may be specified in the following exemplary way:

system {commit {+queue {+maximum-aggregate-pool 10;+maximum-entries 500;+asynchronous-commit;+commit-interval 0;+days-to-keep-error-logs 30;+}}}
The above configuration information indicates that the maximum aggregate pool of patch files (“maximum-aggregate-pool”) that may be aggregated or grouped to form a batch patch file is 10, the maximum number of patch files or entries (“maximum-entries”) that can be stored to commit queue56is 500, asynchronous commit mode has been enabled (“asynchronous-commit”), the commit interval (“commit-interval”) is zero and that the number of days to keep error logs (“days-to-keep-error-logs”) is 30.

In some respects, the various configuration options to configure commit server58may provide for a variety of benefits. For example, specifying a smaller maximum aggregate pool may reduce the amount of configuration data that is not committed when an error occurs. To illustrate, consider aggregation of 10 separate patch files with one of the patch files having a commit error. Batching these 10 separate patch files to form a batch patch file and attempting to commit the batch patch file would therefore result in an error such that none of the 9 other error-free patch files are entered despite that these patch files would have otherwise been entered had they been separately committed. Consequently, specifying a smaller maximum aggregate pool number may reduce the likelihood of patch files being error free but not committed due to errors in other aggregated patch files.

Also, the asynchronous mode, while providing a more responsive user experience in terms of returning the prompt to the one of clients20prior to completion of the commit, may also enable clients20to enter more configuration data more quickly. As a result, the asynchronous mode may result in overruns of the maximum entries specified for commit queue56. If this maximum entries threshold is exceeded, commit sever58may return an error command, preventing this configuration data from being entered. The commit interval configuration setting may insert delay such that more time is given between execution of the batching process to aggregate patch files stored to commit queue56. A large commit interval may result in a higher percentage of batch patch files having been formed from the maximum aggregate pool number rather than a lower number of patch files. A smaller commit interval may result in a lower percentage of batch patch files having been formed from the maximum aggregate pool number, especially in systems for which configuration information is infrequently entered in comparison to other systems.

When committing a batch patch file, commit server58may encounter, as noted above, one or more errors. Typically, in response to these errors, commit server58generates a commit failure message, either logging this message to a system log (not shown in the example ofFIG. 3for ease of illustration purposes) or presenting the message to the corresponding one of clients20via CLI44. In some instances, commit server58may request the one of clients20to manually resolve the error by, for example, re-entering the configuration information. In other instances, commit server58may attempt to break the batch patch file back into its respective patch files and commit each of the patch files separately, so that those of the patch files that do not have any errors may be committed. In this instance, commit server58may determine which of the patch files specifically caused the error and return more specific failure information identifying the one of patch files that caused the error. In operation, commit server58may return the patch files of the error batch patch file to commit queue56, associating each of these patch files with a flag referred to as an “atomic” flag that indicates that these patch files are to be committed separately and individually or “atomically.” Upon de-queuing these patch files associated with the atomic flag, commit server58commits each of these patch files separately.

In some instances, management module42and/or commit server58may associate each of the patch files with a priority flag. The priority flag may indicate a priority associated with the patch file and dictate when commit server58commits the associated patch file with respect to other patch files stored to commit queue56. Management module42may associate patch files with different priorities, as one example, to resolve conflicts in configuring the same configuration variable. That is, if two or more of clients20are attempting to nearly concurrently configure the same aspect of router24, management module42may specify a priority with respect to each of the resulting configuration patches such that the changes to the same aspect of router24is carried out in the same order the commits were received. Commit server58may, as noted above, re-commit the separate patches in response to detecting a commit error when committing a batch patch file. Commit server58may, in these instances, associate the individual patch files forming the batch patch file with a priority flag or otherwise update, edit or change the priority flag to which each of these individual patch files are associated.

Management module42may also expose via CLI44a number of commands by which clients20may view information associated with and interact with commit server58. To provide a few examples, management module42may provide for the following commands:

show system commit server queue [id <id>] [patch | log]show system commit server statusrequest system commit queue kill (id <id> | all)request system commit server queue cleanup (id <id> | all)request system commit server pauserequest system commit server start
The show system commit server queue command (followed optionally by an identifier (id) and/or a patch or log option) may display one or all queue entries. If the patch option is specified, management module42may display patches inside the queue entry. If the log option is specified, management module42may display the log entry associated with the patch, where the log entries may specify the error and status messages associated with the patch.

The show system commit server status command, when entered, causes management module42to display the status of commit server58(e.g., running, paused, stopped, etc.). The request system commit queue kill (followed optionally by an identifier (id) or the all option), when entered, causes management module42to delete one queue entry (specified by the identifier) or all of the queue entries. The request system commit server queue cleanup (followed optionally by the id or all), when entered, causes management module42to remove any temporary files from the queue directory (meaning the directory to which commit queue56is stored). The request system commit server pause and start commands, when entered, cause management module42to pause or start commit server58, respectively.

FIG. 4is a flowchart illustrating management module42entering a configuration mode in response to a configure command from one of clients20. Initially, management module42receives a command from one of clients20to configure router24(60). In response to receiving a configure command from one of clients20, management module42may parse the command to determine which configuration mode to operate in (62,64). When the configure command includes no additional parameters that specify a particular configuration mode, management module42operates in a default configure mode (66). In this mode, management module42allows clients20to concurrently edit shared database50. If one of clients20issues a commit command, all of the changes, complete or incomplete, made by clients20may be committed to committed database48.

When the configure command includes the additional parameter exclusive, management module42operates in an exclusive configure mode (68). In exclusive configuration mode, management module42allows only one of clients20to edit configuration data of shared database50at a time. Allowing only one client20at a time to edit shared database50may prevent interference between client20in the exclusive configure mode and other clients20in different configuration modes. When receiving a commit command from the client20in the exclusive configure mode, management module42copies shared database50to committed database48.

When the configure command includes the additional parameter private, management module42operates in a private configure mode (70). In private configure mode multiple clients20may concurrently issue configuration commands to management module42. In particular, for each of clients20that issues a configure private command, management module42creates a respective private database52from committed database48that stores the present configuration of the device. Management module42applies configuration commands from clients20to their respective private databases52. Upon receiving a commit command from any given one of clients20, management module42merges the edited data of the respective one of private database52into configuration data of committed database48. In particular, management module42generates a “patch” representing the changes to one of private databases52, and applies the patch into committed database48.

When the configure command includes the additional parameter batch, management module42operates in a batch configure mode (71). In batch configure mode multiple clients20may concurrently issue configuration commands to management module42. In particular, for each of clients20that issues a configure batch command, management module42creates a respective private database52from committed database48that stores the present configuration of the device. Management module42applies configuration commands from clients20to their respective private databases52. Upon receiving a commit command from any given one of clients20, management module42determines the patch file of the differences between the configuration data stored to the corresponding one of private database52and the configuration data of committed database48. Management module42then stores the patch file to commit queue56, where commit server58either detects and processes the patch file in the manner described above to generate a batch patch file. Alternatively, management module42invokes commit server58to process the patch file in the manner described above to generate a batch patch file. In any event, commit server58commits the batch patch file to committed database48.

FIG. 5is a flowchart illustrating management module42operating in a batch configure mode in response to receiving a configure batch command. In response, management module42creates a private database52for the requesting client20that issued the configure batch command (72). As described, private database52may be a replicate of committed database48at the time the request is received. Alternatively, private database52may be a copy of configuration data in shared database50. In addition, management module may make a corresponding copy of configuration text file54, which may comprise an ASCII file, at the time of the request.

Next, client20may edit the configuration data of private database52by issuing one or more configuration commands to management module42(74). Private database52allows client20to edit data without interference from other clients20who may also be editing the configuration of router24. For example, if client20issues a rollback command, the configuration data of the respective private database52may be updated with a current copy of configuration data from committed database48. Meanwhile, the edited configuration data of a private database52associated with another one of clients20remains unchanged.

Management module42may parse the configuration commands input from client20, and resolve the references to appropriately configure router24(76,78). Management module42waits to receive a commit command that indicates the completion of editing of private database52(80). When a commit command has not been received from client20, management module42continues to receive configuration commands (74-80). However, upon receiving a commit command, management module42generates a patch representing the changes to private database52and stores the patch to commit queue48in the manner described above (82,84). Commit server58may then aggregate one or more of the patches stored to commit queue56, generating a batch patch based on the one or more of the patches stored to commit queue56in the manner described above, and apply the batch patch to a candidate DB (86). The candidate DB may refer to one of private DBs52, commit DB48or any other DB that may store the configuration data as modified by the batch patch prior to the validation of the configuration data stored to the DB.

Commit server58may next validate or otherwise determine whether application of the batch patch failed (88). If the batch patch was successfully applied, meaning that the batch patch did not fail (“NO”88), commit server58may report this success to management module42and publish this candidate DB as commit DB48so that the configuration data of DB48may be consumed by modules46. Router24may continue to implement the techniques in the manner described above (72-88). However, if the batch patch was not successfully applied, meaning that the batch patch failed (“YES”88), commit server58may determine the number of patches that were batched (90). If this number of patches that were batched is more than one (“YES”92), commit server58marks all of these patches as “atomic” in the manner described above and stores each of the patches to the commit queue, where each of these patches are re-executed individually (94,86-92). If the number of patches that were batched is not more than one (“NO”92), commit server58returns an error and router24continues to operate in the manner described above (96,72-96).

In one or more examples, the functions described may be implemented in a control unit, which may comprise hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on as one or more instructions or code on a computer-readable medium. Computer-readable media may include computer data storage media or communication media including any medium that facilitates transfer of a computer program from one place to another. Data storage media may be any available media that can be accessed by one or more computers or one or more processors to retrieve instructions, code and/or data structures for implementation of the techniques described in this disclosure.

Various embodiments of the techniques have been described. These and other embodiments are within the scope of the following claims.