Secure mechanism to manage network device configuration and audit with a blockchain

Embodiments presented in this disclosure generally relate to device configuration. More specifically, embodiments disclosed herein relate to use of a distributed ledger to manage and adjust device configuration, and improve audit capabilities.

In order to control the functionality of a network, each device is often given a specific set of configurations to regulate how it operates. In typical networks, the device configuration for any given device is stored on that individual machine. Problematically, if a device fails or needs to be replaced, this configuration information may be lost unless it is stored remotely as well. In order to provide this redundancy, some existing solutions utilize a service that periodically interrogates each device for its current configuration, and stores this information remotely. However, this solution is inadequate in that it does not indicate an ordering or timing of the changes, who or what made the changes, and the like. Further, these services may be unsecure, unavailable, or unreliable.

So that the manner in which the above-recited features of the present disclosure can be understood in detail, a more particular description of the disclosure, briefly summarized above, may be had by reference to embodiments, some of which are illustrated in the appended drawings. It is to be noted, however, that the appended drawings illustrate only typical embodiments of this disclosure and are therefore not to be considered limiting of its scope, for the disclosure may admit to other equally effective embodiments.

FIG. 1 illustrates a system network devices configured to utilize one or more blockchains for device configuration, according to one embodiment disclosed herein.

FIG. 2 is a block diagram of a system of network devices configured to utilize one or more blockchains for device configuration, according to one embodiment disclosed herein.

FIG. 3 illustrates several blocks in a configuration blockchain, according to one embodiment disclosed herein.

FIG. 4 illustrates a configuration block in a configuration blockchain, according to one embodiment disclosed herein.

FIG. 5 illustrates a workflow for maintaining a configuration blockchain, according to one embodiment disclosed herein.

FIG. 6 is a flow diagram illustrating a method of utilizing a configuration blockchain, according to one embodiment disclosed herein.

FIG. 7 is a flow diagram illustrating a method of utilizing a configuration blockchain, according to one embodiment disclosed herein.

FIG. 8 is a flow diagram illustrating a method of utilizing a configuration blockchain, according to one embodiment disclosed herein.

To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the figures. It is contemplated that elements disclosed in one embodiment may be beneficially utilized on other embodiments without specific recitation.

Overview

According to one embodiment presented in this disclosure, a method is provided. The method includes receiving, by a first network device of a plurality of network devices, a configuration blockchain. The method also includes analyzing, by the first network device, the configuration blockchain to identify a plurality of configuration records associated with a second network device of the plurality of network devices. Additionally, for at least one respective configuration record of the plurality of configuration records, the method includes determining, by the first network device, a respective configuration change reflected in the at least one respective configuration record, and implementing, by the first network device, the respective configuration change on the first network device.

According to a second embodiment presented in this disclosure, a computer program product is provided. The computer program product includes a computer-readable storage medium having computer-readable program code embodied therewith, the computer-readable program code executable by one or more computer processors to perform an operation. The operation includes receiving, by a first network device of a plurality of network devices, a first configuration change, and implementing, by the first network device, the first configuration change. The operation additionally includes generating a first configuration record based on the first configuration change. Finally, the operation includes broadcasting, by the first network device, the first configuration record to at least a second network device of the plurality of network devices, wherein the first configuration record is included in a configuration blockchain by the second network device.

According to a third embodiment presented in this disclosure, a system is provided. The system includes one or more computer processors and a memory containing a program which when executed by the one or more computer processors performs an operation. The operation includes receiving, by a first network device of a plurality of network devices, a configuration blockchain. The operation further includes analyzing, by the first network device, the configuration blockchain to identify a plurality of configuration records associated with a second network device of the plurality of network devices. Additionally, for at least one respective configuration record of the plurality of configuration records, the operation includes determining, by the first network device, a respective configuration change reflected in the at least one respective configuration record, and implementing, by the first network device, the respective configuration change on the first network device. The operation also includes receiving, by the first network device, a first configuration change, implementing, by the first network device, the first configuration change, and broadcasting, by the first network device, a first configuration record to at least a third network device of the plurality of network devices, wherein the first configuration record is included in the configuration blockchain by the third network device.

Example Embodiments

Embodiments of the present disclosure provide mechanisms for devices to store their configuration changes in a secure and distributed blockchain. As described herein, a configuration blockchain is a blockchain that stores configuration information associated with computing devices. Additionally, in embodiments, the configuration blockchain can be reviewed and analyzed to identify the timing and ordering of all configuration changes, as well as the entity who ordered the change. Further, in some embodiments, the configuration blockchain can be dynamically replayed in order to enable a device to automatically configure itself based on prior configuration changes. Although network devices are utilized herein as examples, embodiments of the present disclosure can be used for any technical field that involves configuration of devices.

In an embodiment, a controller or configuration device transmits configuration updates to a device. In one embodiment, the devices to be configured are network devices, such as switches, routers, and the like. In one embodiment, the controller and network devices operate as part of a software defined network. In embodiments, when a network device receives a configuration change, the device implements the new configuration, records the change in a ledger, and broadcasts a record of the change to one or more other network devices. Each device in the configuration blockchain network can then maintain a ledger of all changes that have occurred on any device in the network.

FIG. 1 illustrates a system 100 including Network Devices 115 configured to utilize one or more blockchains for device configuration, according to one embodiment disclosed herein. The illustrated embodiment includes two Networks 110 A and 1108 , each of which are controlled by a Controller 105 . Although a single Controller 105 is illustrated for simplicity, in embodiments, each Network 110 may be associated with a distinct Controller 105 . Further, in embodiments, there may be multiple Controllers 105 associated with a single Network 110 , depending on the particular implementation. In an embodiment, each Network 110 may be communicatively coupled with one or more other networks. For example, in one embodiment, each Network 110 operates as a subnetwork of one or more broader networks, such as the Internet. In some embodiments, the Network(s) 110 may be operate as a secure or private network, with limited or restricted access to the Internet. In some embodiments, the Network(s) 110 are entirely isolated from the Internet.

As illustrated, the Network 110 A includes Network Devices 115 A, 115 B, 115 C, and 115 D. In the illustrated embodiment, each Network Device 115 A-D in the Network 110 A is communicatively coupled with each other Network Device 115 A-D. In embodiments, the communications connections between each Network Device 115 A-D is defined by a user or administrator, or by the topography of the network, and the Network Devices 115 A-D and any two Network Devices 115 may or may not be connected. That is, although the illustrated Network 110 A includes connections between and among all Network Devices 115 A-D, in embodiments, some Network Devices 115 A-D may be only partially connected, in that it can directly communicate with only a subset of the devices in the Network 110 A.

Further, although the illustrated embodiment includes four Network Devices 115 A-D in the Network 110 A, there may be any number and arrangement of Network Devices 115 in various embodiments. In the illustrated embodiment, the Network 110 A and Network 1106 form logical groupings of Network Devices 115 . In an embodiment, these groupings are defined by a user or administrator, such as via the Controller 105 . In one embodiment, each Network 110 A and 1106 correspond to a particular geographic location, site, enterprise, and the like. In some embodiments, each Network Device 115 in a logical grouping shares a single configuration blockchain. For example, in the illustrated embodiment, the Network Devices 115 A-D utilize a first configuration blockchain, while the Network Devices 115 E-G utilize a second, separate configuration blockchain.

In the illustrated embodiment, the Controller 105 transmits configuration changes to each of the Network Devices 115 . Upon receiving a configuration, the Network Device 115 updates its configuration, records the change, and broadcasts a record of the change to one or more other devices in its Network 110 A or 1106 . For example, suppose the Controller 105 transmits an updated configuration to Network Device 115 F. In an embodiment, once Network Device 115 F has implemented the configuration change, it broadcasts a record of the change (sometimes referred to as a transaction) to the Network Devices 115 E and 115 G to be included in the configuration blockchain associated with the logical grouping of devices (e.g., the Network 110 B). Upon receiving the indication, in an embodiment, each of the Network Devices 115 E and 115 G record it in their own ledger. In some embodiments, one or more Controllers 105 also receive the change record and maintain a copy of the configuration blockchain.

In embodiments, the configuration record can include an indication as to the device which was configured, the entity that ordered the configuration change (which may include an indication of the Controller 105 , the user or administrator who provided it, and the like), the timing of the change, the contents of the change, and the like. In an embodiment, each of the Network Devices 115 E-G includes a configuration blockchain client that maintains its ledger, as well as attempts to satisfy predefined criteria (such as finding a solution to a predefined algorithm). When the algorithm is completed successfully by one of the Network Devices 115 E-G, the successful Network Device 115 closes the current block it has stored in its ledger, finalizing all transactions or records contained therein. The Network Device 115 further broadcasts this finalized block to the other devices in the Network 1108 , which validate the block (e.g., by confirming that the algorithm was completed). Upon validating the block, each Network Device 115 E-G incorporates it into their copy of the configuration blockchain, and begins processing a new block.

In one embodiment, the algorithm is defined by a user or administrator. In one embodiment, solving the algorithm comprises using a hash algorithm to generate a hash value below a predefined value. In an embodiment, each blockchain client computes a hash of their current block, as well as a nonce value, to determine whether the hash value is below the predefined value. If not, the blockchain client changes the nonce and re-computes the hash. In an embodiment, the computational difficulty of solving the algorithm can be adjusted by a user or administrator based on changing the predefined value. For example, to reduce the complexity of the algorithm (and therefore reduce the time and compute resources needed to close a block), an administrator may increase the predefined value. Similarly, to increase the complexity, the user can lower the predefined value. Of course, in embodiments, any algorithm may be used. Further, in some embodiments, other predefined criteria may be specified to cause the close of a configuration block. For example, in one embodiment, the block may be closed once a predefined time has passed, or some other predefined event occurs.

In an embodiment, the algorithm or predefined criteria are selected to minimize the computational resources needed to complete a configuration block. For example, in one embodiment, an algorithm or value is defined by a user or administrator to ensure that it can be solved or completed using defined compute resources (e.g., a number of clock cycles, an amount of memory, and the like). Similarly, in some embodiments, the blockchain client on each Network Device 115 has limited or reduced access to the compute resources available on the device for other operations. In this way, a network administrator can ensure that solving the algorithm does not interfere with the normal operations of the device.

In embodiments, the configuration blockchain for any particular Network 110 can be retrieved and analyzed at any time. Because of its distributed and secure nature, the configuration blockchain aids the audit or investigation process if a problem is identified, a Network Device 115 stops functioning, and the like. For example, via the Controller 105 or another device, a user or administrator can retrieve a copy of the blockchain for any given logical grouping of devices. This blockchain can then be parsed to determine which configuration changes were entered, by whom, and at what time.

Additionally, in embodiments, the configuration blockchain eases the process of resource management and allocation (RMA). For example, in an embodiment, if a particular Network Device 115 is being replaced, the newly inserted device can receive the configuration blockchain, identify records associated with the device it is replacing, and automatically implement each of these configuration changes in their original order. This allows for a seamless transition. In one embodiment, when a new device is activated, it announces its presence to the logical group. Upon determining that the device is to replace an existing or prior device, in one embodiment, one or more neighboring devices can transmit the blockchain to the new device. For example, in one embodiment, a user can record a record in the configuration blockchain indicating that the new device (identified by a unique identifier) is to replace another specified device. In such an embodiment, when the existing devices receive the indication that the new device is active, they can respond accordingly.

In another embodiment, the newly activated device may receive an indication (such as a configuration policy) instructing it to retrieve the blockchain from one or more neighboring devices, and implement one or more configuration changes that were applied to one or more other specified devices. In such an embodiment, the new device can request the blockchain from one or more other device in the logical group, parse the blockchain to identify the records it is to implement, and complete the configuration.

FIG. 2 is a block diagram of a system 200 of Network Devices 115 A-N configured to utilize one or more blockchains for device configuration, according to one embodiment disclosed herein. In the illustrated embodiment, the system 200 includes a Controller 105 and three Network Devices 115 A-N. Although three Network Devices 115 A-N are illustrated, in embodiments, any number of devices may be included in the network. Similarly, although a single Controller 105 is depicted, any number of Controllers 105 may be utilized in various embodiments.

As illustrated, the Controller 105 includes a Processor 210 , a Memory 215 , Storage 220 , and a Network Interface 225 . In the illustrated embodiment, Processor 210 retrieves and executes programming instructions stored in Memory 215 as well as stores and retrieves application data residing in Storage 220 . Processor 210 is representative of a single CPU, multiple CPUs, a single CPU having multiple processing cores, and the like. Memory 215 is generally included to be representative of a random access memory. Storage 220 may be a disk drive or flash-based storage device, and may include fixed and/or removable storage devices, such as fixed disk drives, removable memory cards, or optical storage, network attached storage (NAS), or storage area-network (SAN). Through the Network Interface 225 , the Controller 105 may be communicatively coupled with other devices, such as the Network Devices 115 A-N.

In the illustrated embodiment, the Memory 215 of the Controller 105 includes a Controller Application 230 . The Controller Application 230 is used to transmit configurations and other controls to the Network Devices 115 A-N. In one embodiment, the Controller 105 operates in a software defined network (SDN) and controls the configurations regarding forwarding rules, security, and the like for each Network Device 115 A-N. In some embodiments, a user or administrator accesses the Controller 105 to implement these configuration changes. In some embodiments, the Controller 105 also maintains a copy of the configuration blockchain used by the Network Devices 115 A-N it controls.

As illustrated, each Network Device 115 A-N includes a respective Processor 250 A-N, Memory 255 A-N, Storage 260 A-N, and Network Interface 265 A-N. In the illustrated embodiment, each Processor 250 A-N retrieves and executes programming instructions stored in the respective Memory 255 A-N as well as stores and retrieves application data residing in the respective Storage 260 A-N. Each Processor 250 A-N is representative of a single CPU, multiple CPUs, a single CPU having multiple processing cores, and the like. Similarly, each Memory 255 A-N is generally included to be representative of a random access memory. Additionally, each Storage 260 A-N may be a disk drive or flash-based storage device, and may include fixed and/or removable storage devices, such as fixed disk drives, removable memory cards, or optical storage, network attached storage (NAS), or storage area-network (SAN). Through their respective Network Interfaces 265 A-N, each Network Device 115 A-N is communicatively coupled with other devices, including one or more other Network Devices 115 A-N, one or more Controllers 105 , and the like.

In the illustrated embodiment, the Memory 255 A-N of each Network Device 115 A-N includes a respective Configuration Blockchain Client 270 A-N. In an embodiment, each Configuration Blockchain Client 270 A-N maintains a copy of the Configuration Blockchain used by the logical grouping of Network Devices 115 A-N. For example, in an embodiment, when a Network Device 115 A-N receives and implements a new configuration from the Controller 105 , the Configuration Blockchain Client 270 A-N of the Network Device 115 A-N generates a record of the change, updates its ledger to reflect the change, and broadcasts the change to the other Network Devices 115 A-N.

Further, in an embodiment, each respective Configuration Blockchain Client 270 A-N attempts to solve the defined algorithm, or otherwise verify a predefined criterion, that triggers the end of the current block. Upon determining that the criteria is satisfied, the respective Configuration Blockchain Client 270 A-N transmits an indication to the other Network Devices 270 A-N, who verify the solution and accept the new block. In this way, each time a configuration change is made to any Network Device 115 A-N, it is recorded by each Network Device 115 A-N.

FIG. 3 illustrates several Blocks 300 A-N in a Configuration Blockchain 275 , according to one embodiment disclosed herein. Although four blocks are illustrated, as indicated by the ellipses 330 and 335 , the Configuration Blockchain 275 may include any number of blocks preceding and following the illustrated Configuration Blocks 300 A-N. As illustrated, in an embodiment, each Configuration Block 300 A-N in the Configuration Blockchain 275 includes a respective Current Block Hash 305 A-N, a respective Previous Block Hash 310 A-N, and a respective Merkle Hash 315 A-N. Further, as illustrated, each respective Configuration Block 300 A-N includes a respective set of Configuration Records 320 A-N.

In an embodiment, the Current Block Hash 305 A includes a hash value representing the Configuration Block 300 A. In embodiments, the Current Block Hash 305 A may be based in part on the Previous Block Hash 310 A and the Merkle Hash 315 A. In some embodiments, the Current Block Hash 300 A is also based in part on a nonce value, as discussed above, or other data. Further, in the illustrated embodiment, the Previous Block Hash 310 A refers to the hash of the previous block in the chain. For example, the Previous Block Hash 310 B in Configuration Block 300 B has the same value as the Current Block Hash 305 A in Configuration Block 300 A. Similarly, the Previous Block Hash 310 N in Configuration Block 300 N has the same value as the Current Block Hash 305 B in Configuration Block 300 B.

In the illustrated embodiment, the Merkle Hash 315 A-N of a Configuration Block 300 A-N is based on each of the Configuration Records 320 A-N included in the respective Configuration Block 300 A-N. For example, in one embodiment, each of the Configuration Records 320 A-N included in the ledger of the Configuration Block 300 A-N is hashed, and the resulting values are iteratively combined and hashed until a final value (e.g., a Merkle Hash 315 A-N) representing all of the Configuration Records 320 A-N in the Configuration Block 300 A-N is created. In this way, none of the individual Configuration Records 320 A-N can be modified or removed, as this would change the Merkle Hash 315 A. Further, in embodiments, a change in the Merkle Hash 315 A would cause the Current Block Hash 305 A to change as well. This, in turn, would cause the hash of each subsequent block (e.g., Current Block Hash 305 B) to change. In this way, the Configuration Blockchain 275 is secure and consistent.

In the illustrated embodiment, two blocks (Configuration Blocks 300 B and 300 C) were created to follow Configuration Block 300 A. For example, this may occur if two Network Devices 115 solve the algorithm and broadcast valid solutions simultaneously (or within the communications delay of the network). In embodiments, this is referred to as a fork in the Configuration Blockchain 275 . In some embodiments, the fork is remedied manually by a user or administrator (e.g., by indicating which Configuration Block 300 B or 300 C to use). In other embodiments, the “correct” block is determined based on the subsequent Configuration block 300 N.

For example, if a fork occurs, some of the Network Devices 115 may be working based on the a version of the Configuration Blockchain 275 that includes Configuration Block 300 B, while other Network Devices 115 are operating based on the a version of the Configuration Blockchain 275 that includes Configuration Block 300 C. Subsequently, when one of the Network Devices 115 completes the next block and broadcasts its solution, in an embodiment, all Network Devices 115 accept this new Configuration Block 300 N, as well as any prior blocks, because it is the longest version of the Blockchain 275 that is available. In this way, the Network Devices 115 may correct forks automatically.

FIG. 4 illustrates a Configuration Block 300 B in a Configuration Blockchain 275 , according to one embodiment disclosed herein. Although three Configuration Blocks 300 A-N are depicted, as illustrated by the ellipses 415 and 420 , the Configuration Blockchain 275 may include any number of blocks. Further, although only the Configuration Block 300 B is illustrated in detail, as indicated by the ellipses in the Configuration Blocks 300 A and 300 N, similar information resides in each of the blocks. In the illustrated embodiment, as discussed above, the Configuration Block 300 B includes a Current Block Hash 305 B, a Previous Block Hash 310 B, and a Merkle Hash 315 B. Further, as illustrated, each of the Configuration Records 320 B are stored in a ledger.

In the illustrated embodiment, the ledger includes an indication as to the target device (e.g., the Network Device 115 that was the target of the configuration change), the user (e.g., the user who initiated the change), the time at which the change was received and/or implemented, the type of the record, and the contents of the record. In an embodiment, each Configuration Record 320 B specifies a particular type. In one embodiment, one such type is “configuration,” indicating that the record corresponds to a configuration change or update. Similarly, in one embodiment, a “replacement” type indicates that one or more identified Network Devices 115 are being replaced with one or more other Network Devices 115 . Additional types of Configuration Record 320 B may also be utilized, in various embodiments.

In the illustrated embodiment, the contents of the Configuration Record 320 B indicate what changes or updates were included in the underlying configuration change. In some embodiment, each Configuration Record 320 includes one or more digital signatures to validate its authenticity. For example, in one embodiment, the Configuration Record 320 B are signed using a certificate (such as a secure unique device identification or SUDI) certificate of the Network Device 115 that implemented the change, the Controller 105 , or both.

In one embodiment, the “target” for a “replacement” record refers to the device that is being replaced. In such an embodiment, the target device may take various actions, such as transmitting the blockchain to the replacement device, shutting itself down, and the like. In some embodiments, the “target” of a replacement record indicates the device that is being activated. In such an embodiment, upon being activated, one or more network devices can identify, based on the blockchain record, that the new device is to replace the old device, and transmit the blockchain to the new device. Similarly, in an embodiment, the new device may itself request the blockchain, analyze the records to determine that it is to replace the specified device(s), and retrieve configuration records for each of those identified devices.

FIG. 5 illustrates a workflow 500 for maintaining a configuration blockchain, according to one embodiment disclosed herein. The illustrated workflow 500 includes operations performed by a Controller 105 and three Network Devices 115 A-C. At block 505 , the Controller 105 transmits a configuration change to the Network Device 115 A. Of course, in embodiments, the Controller 105 can transmit configuration changes to any of the Network Devices 115 A-C. In embodiments, this change may include adding a new rule, removing or modifying an existing rule, and the like. At block 510 , the Network Device 115 A receives the configuration change. At block 515 , the Network Device 115 A validates the change. In one embodiment, validating the configuration change comprises confirming that it was transmitted or signed by a trusted Controller 105 . Additionally, in some embodiments, validating the configuration change includes confirming that an authorized user or administrator initiated the change.

Further, in some embodiments, validating the change includes determining whether the Network Device 115 A can implement the change (e.g., whether it is a valid configuration for the Network Device 115 A). In an embodiment, if the change cannot be validated, the Network Device 115 A discards it and the workflow 500 ends. In some embodiments, the Network Device 115 A may notify the Controller 105 and/or other devices of the failed configuration change. In one embodiment, the Network Device 115 A may generate a record of this failure, and transmit it to each other Network Device 1158 and 115 C to be included in the configuration blockchain.

In the illustrated embodiment, however, the Network Device 115 A successfully validates the configuration change. Upon validating the change, the Network Device 115 A implements the change(s) at block 520 . That is, at block 520 , the Network Device 115 A updates any configurations it has stored based on the change, and performs any other actions identified in the configuration change (such as rebooting).

Once the configuration has been implemented, at block 525 , the Network Device 115 A creates a configuration record based on the change, and records it in its own ledger. Similarly, at block 530 , the Network Device 115 A broadcasts the configuration record to one or more other devices that share the Configuration Blockchain 275 . In the illustrated embodiment, this includes Network Devices 115 B and 115 C. In some embodiments, the Network Device 115 A may update its ledger and/or broadcast the configuration record as soon as the change is validated, rather than waiting until after it has been fully implemented.

In one embodiment, a Configuration Blockchain 275 is distributed across the Network Devices 115 at a particular site, enterprise, geographic location, and the like. In this way, the Network Devices 115 can track their configurations (and automatically recover prior configurations) even in the absence of a connection to a remote server (e.g., via the Internet). For example, if the Network Devices 115 operate in a private network or are otherwise disconnected from a larger network, such as the Internet, they may be unable to store their configuration changes using existing solutions. Similarly, if the remote server is unreachable, a device needing to be replaced or reconfigured based on prior configurations must be manually reconfigured in existing solutions. Embodiments of the present disclosure provide a consistent, secure, and reliable Configuration Blockchain 275 that resides on the local Network Devices 115 themselves.

In some embodiments, the Network Device 115 A may sign or otherwise validate the configuration record prior to broadcasting it to the other Network Devices 115 B and 115 C. For example, in one embodiment, the Network Device 115 A utilizes a SUDI certificate securely stored at manufacturing time. In one embodiment, the Configuration Blockchain Client 270 executes via a device configuration management system, such as a Plug and Play (PNP) agent, developed by Cisco Systems of San Jose, Calif. By signing the configuration record with a secure and unique identifier, each other Network Device 115 B and 115 C can confirm the accuracy and validity of the record.

In the illustrated embodiment, at blocks 535 A and 535 B, the Network Devices 115 B and 115 C, respectively, receive the configuration record from the Network Device 115 A. At blocks 540 A and 540 B, the Network Devices 115 B and 115 C validate the record. For example, in one embodiment, validating the record comprises reviewing the signature or identifier associated with the record to confirm that it originated from a Network Device 115 within the logical group associated with the Blockchain 275 . Further, in an embodiment, validating the record includes confirming that the device listed as the “target” in the record is the same as the device that created or transmitted the record. Once the record has been validated, in the illustrated workflow 500 , each of the Network Devices 115 B and 115 C record the configuration record in their respective ledgers.

In some embodiments, once a Network Device 115 receives a record from another device, the Network Device 115 may first determine whether they have already recorded it in their respective ledger. If not, the Network Device 115 records the change. Further, in some embodiments, each Network Device 115 re-broadcasts the configuration record upon receipt. In this way, the record can propagate throughout a network, to ensure that each connected device receives a copy of the record, even if the device is not directly connected to the originally updated device. In one embodiment, each Network Device 115 broadcasts the record only once, regardless of how many times it receives the record from other devices.

FIG. 6 is a flow diagram illustrating a method 600 of utilizing a configuration blockchain, according to one embodiment disclosed herein. The illustrated method 600 can be used to “replay” old configurations, in order to recreate them in accordance with their original timing and sequence. In the illustrated embodiment, the method 600 begins at block 605 , where a Network Device 115 determines that configuration is required. In one embodiment, the Network Device 115 determines that its configuration is outdated. In another embodiment, upon initial activation, the Network Device 115 determines that it must be configured. In yet another embodiment, the Network Device 115 can receive some indication that configuration is required.

At block 610 , the Network Device 115 retrieves the configuration blockchain associated with the logical grouping to which the Network Device 115 belongs. For example, if a new router is enabled in an enterprise or location, the router may announce its presence and request a copy of the blockchain from any neighboring devices. In another embodiment, when the new device announces its activation, one or more other devices in the grouping transmit the blockchain to the newly activated device. In one embodiment, prior to transmitting the configuration blockchain to the new device, the existing device(s) parse their own blockchain to determine whether the newly activated device is authorized. For example, the device(s) may analyze the configuration blockchain to identify replacement records that list the new device as an authorized device to be added to the network.

Once the Network Device 115 receives the configuration blockchain, the method 600 continues to block 615 , where the Network Device 115 identifies relevant configuration records in the configuration blockchain. In embodiments, identifying relevant records can be based on any defined criteria, depending on the particular implementation.

In one embodiment, identifying relevant records comprises identifying records that were authored or created by one or more specified Network Device 115 , or that refer to a configuration change implemented by one or more particular devices. For example, in one embodiment, a Network Device 115 A may parse the configuration blockchain to identify records corresponding to configuration updates that were implemented by Network Device 115 A (e.g., itself). This may be useful because, for example, the Network Device 115 A crashed, failed, or otherwise had its configurations corrupted. Once the Network Device 115 A is reset, it can automatically identify its previous configurations based on the blockchain. In some embodiments, particular records can be flagged by a user or administrator, and the Network Devices 115 ignore these flagged records. For example, if a recent configuration change caused the failure, the Network Device 115 A can be instructed to ignore this particular change.

In one embodiment, the Network Device 115 A may determine that it is replacing another device in the network, and that it should therefore implement the configurations of that device. For example, in one embodiment, the Network Device 115 A may receive a notification or indication as to the device it is replacing. In another embodiment, this notification may be stored as a record in the blockchain. In such an embodiment, the Network Device 115 A may parse the blockchain to identify any records that list itself as a target, and implement these records. Further, if one or more of these records indicate that the Network Device 115 A is to configure itself based on the configurations of another specified device, the Network Device 115 A can retrieve the records associated with the identified device(s) that the Network Device 115 A is to replicate.

In some embodiments, rather than replacing an existing device, the Network Device 115 may be intended to supplement one or more defined devices, such as by replicating the configurations of the identified device(s). In such an embodiment, the Network Device 115 may analyze each record in the configuration blockchain to identify the relevant records (such as by determining whether the specified target includes one of the identified device(s)), and implement these configuration changes in temporal order. This enables the device to automatically configure itself to exactly replicate the configuration of any other device(s).

In another embodiment, the configuration blockchain may include records with broad applicability, or that identify a set of target devices. In such an embodiment, the Network Device 115 A can additionally identify such records that should be applied, even if the record does not specify any particular device. For example, a record may indicate that it applies to all switches. Regardless of the particular implementation, in block 615 , the Network Device 115 identifies relevant records that it should implement. The method 600 then proceeds to block 620 .

At block 620 , the Network Device 115 selects one of the identified relevant configuration records. In one embodiment, the Network Device 115 selects the records in chronological order, beginning with the oldest record. In some embodiments, the Network Device 115 validates the selected configuration record, prior to implementing it. For example, in one embodiment, the Network Device 115 determines whether the configuration change was authorized. In some embodiments, however, the Network Device 115 may assume that all configuration changes reflected in the configuration blockchain were already validated, and thus forgo this additional validation step.

In some embodiments, prior to implementing the change reflected in the selected record, the Network Device 115 determines whether the change was successfully implemented originally. For example, as discussed above, in some embodiments, configuration records can include failed configuration changes. If the change was not successfully implemented, the Network Device 115 may discard the record. Additionally, in one embodiment, the Network Device 115 validates the change by confirming that it is able to implement the configuration listed in the record. In one embodiment, if this validation step fails, the Network Device 115 discards the record and selects the next one. In another embodiment, the Network Device 115 pauses the method 600 , and alerts one or more other devices (e.g., a Controller 105 ) or users of this failure. This may allow the user or administrator to intervene and determine how to proceed. Subsequently, once the problem is corrected (such as by manually adding one or more configurations), the Network Device 115 may resume execution of the method 600 , to complete its auto-configuration.

In the illustrated embodiment, at block 625 , the Network Device 115 implements the configuration change reflected in the record. That is, in the illustrated embodiment, the configuration is validated (if the particular implementation requires validation) and successfully implemented on the Network Device 115 . As discussed above, in embodiments, if the configuration fails for some reason (either failing validation, or failing implementation), the Network Device 115 may either discard the record and continue, or pause the method 600 and await further instruction.

The method 600 then proceeds to block 630 , where the Network Device 115 records the configuration change in its own ledger. That is, at block 630 , the Network Device 115 generates and stores a record indicating that it has implemented the configuration change. In one embodiment, this record includes the same content as the selected record. In one embodiment, the newly generated record includes a pointer to the selected record in the Configuration Blockchain 275 , so that users can subsequently determine when the configuration was initially created, who initiated it, what device(s) was targeted, and the like.

The method 600 then proceeds to block 635 , where the Network Device 115 broadcasts the record to the other devices. Upon receiving the record, each other device can update its own ledger to reflect the change. In this way, should the Network Device 115 fail or stutter during the method 600 , a user or administrator (or the Network Device 115 itself) can parse the configuration blockchain to determine when it failed, and which step or configuration change was implemented or being implemented at the time.

The method 600 continues to block 640 , where the Network Device 115 determines whether there are additional relevant configuration records to be processed. If so, the method 600 returns to block 620 to select the next configuration record. In an embodiment, the Network Device 115 selects the oldest identified record that has not already been implemented. If there are no remaining records, the method 600 terminates at block 645 .

In the illustrated embodiment, the Network Device 115 iteratively identifies changes and implements them in order. In some embodiments, the Network Device 115 parses each identified relevant record to extract the corresponding configuration change, and assembles a list of configuration changes (e.g., a sequence of commands or policies) to be implemented. The Network Device 115 can then proceed in order through the list or sequence. In one embodiment, prior to implementing each change on the list, the Network Device 115 can parse the changes to determine whether any of the configuration changes were subsequently reversed or undone by a later configuration change. If so, in one embodiment, the Network Device 115 ignores the earlier configuration change. In some embodiments, the Network Device 115 similarly ignores some or all of the subsequent reversal (e.g., because you cannot reverse or remove a configuration change that was never implemented).

In an embodiment, when retrieving and implementing historical configuration changes, the Network Device 115 proceeds chronologically through the relevant records. In this way, the configuration of the Network Device 115 is dynamically re-configured based on prior configurations. In some embodiments, a user or administrator may instruct the Network Device 115 to only implement a subset of the changes. For example, in one embodiment, the Network Device 115 only implements changes that are more recent than a defined time. Similarly, in one embodiment, the Network Device 115 only implements changes older than a defined time.

In embodiments, these configuration records implemented by the Network Device 115 may have been associated with the Network Device 115 itself, or with one or more other devices. Advantageously, the method 600 enables rapid replacement of failed network devices, without requiring manual configuration. Further, because the Network Device 115 can replay the entire sequence of configurations (in their original sequence), the Network Device 115 can exactly replicate the prior configuration. Additionally, because the configuration changes are recorded and broadcast upon receipt, even the most recent changes are available in the blockchain.

FIG. 7 is a flow diagram illustrating a method 700 of utilizing a configuration blockchain, according to one embodiment disclosed herein. In the illustrated embodiment, the method 700 begins at block 705 , where a Configuration Blockchain Client 270 of a first Network Device 115 of a plurality of network devices receives a configuration blockchain. At block 710 , the Blockchain Client 270 of the first Network Device 115 analyzes the configuration blockchain to identify a plurality of configuration records associated with a second Network Device 115 of the plurality of network devices. The method 700 continues to block 715 , where, for at least one respective configuration record of the plurality of configuration records, the Blockchain Client 270 determines a respective configuration change reflected in the at least one respective configuration record, and implements the respective configuration change on the first Network Device 115 .

FIG. 8 is a flow diagram illustrating a method 800 of utilizing a configuration blockchain, according to one embodiment disclosed herein. In the illustrated embodiment, the method 800 begins at block 805 , where a Configuration Blockchain Client 270 of a first Network Device 115 of a plurality of network devices receives a first configuration change. At block 810 , the first Network Device 115 implements the first configuration change. The method 800 then proceeds to block 815 , where the Blockchain Client 270 generates a first configuration record based on the first configuration change. Finally, at block 820 , the Blockchain Client 270 broadcasts the first configuration record to at least a second Network Device 115 of the plurality of network devices, wherein the first configuration record is included in a configuration blockchain by the second Network Device 115 .

In the preceding, reference is made to embodiments presented in this disclosure. However, the scope of the present disclosure is not limited to specific described embodiments. Instead, any combination of the described features and elements, whether related to different embodiments or not, is contemplated to implement and practice contemplated embodiments. Furthermore, although embodiments disclosed herein may achieve advantages over other possible solutions or over the prior art, whether or not a particular advantage is achieved by a given embodiment is not limiting of the scope of the present disclosure. Thus, the preceding aspects, features, embodiments and advantages are merely illustrative and are not considered elements or limitations of the appended claims except where explicitly recited in a claim(s).

As will be appreciated by one skilled in the art, the embodiments disclosed herein may be embodied as a system, method or computer program product. Accordingly, aspects may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.

Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

Computer program code for carrying out operations for aspects of the present disclosure may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

Aspects of the present disclosure are described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments presented in this disclosure. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.

The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

Embodiments of the invention may be provided to end users through a cloud computing infrastructure. Cloud computing generally refers to the provision of scalable computing resources as a service over a network. More formally, cloud computing may be defined as a computing capability that provides an abstraction between the computing resource and its underlying technical architecture (e.g., servers, storage, networks), enabling convenient, on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort or service provider interaction. Thus, cloud computing allows a user to access virtual computing resources (e.g., storage, data, applications, and even complete virtualized computing systems) in “the cloud,” without regard for the underlying physical systems (or locations of those systems) used to provide the computing resources.

Typically, cloud computing resources are provided to a user on a pay-per-use basis, where users are charged only for the computing resources actually used (e.g. an amount of storage space consumed by a user or a number of virtualized systems instantiated by the user). A user can access any of the resources that reside in the cloud at any time, and from anywhere across the Internet. In context of the present invention, a user may access applications (e.g., the Controller Application 230 or the Configuration Blockchain 275 ) or related data available in the cloud. For example, a Configuration Blockchain Client 270 could execute on a computing system in the cloud and track the configuration updates to a network. In such a case, the Configuration Blockchain Client 270 could generate and validate configuration records, and store the Configuration Blockchain 275 at a storage location in the cloud. Doing so allows a user to access this information from any computing system attached to a network connected to the cloud (e.g., the Internet).

The flowchart and block diagrams in the Figures illustrate the architecture, functionality and operation of possible implementations of systems, methods and computer program products according to various embodiments. In this regard, each block in the flowchart or block diagrams may represent a module, segment or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

In view of the foregoing, the scope of the present disclosure is determined by the claims that follow.