Cisco Technology, Inc.

Jason David Notari

Lukas Krattiger

Shyam N Kapadia

Patnala Debashis Rao

Uffaz Nathaniel

Aakruthi Ramkumar Gopisetty

Liqin Dong

Manish Chandra Agrawal

Debashis Patnala Rao

Sachin Vijay Vishwarupe

Viral Rajeshbhai Barot

Kora Bongen

Hanuma Kumar Chilakamarthi

Techniques and architecture are described for initializing, reviewing/approving, and deploying changes within a network. Each change is associated with a particular change ticket. When a change needs to be rolled back, the original change ticket may be analyzed to determine what actions need to be performed to roll back the change. A plan of the needed actions may then be presented to a reviewer in a rollback ticket. The original change ticket may be cancelled and a new ticket, e.g., the rollback ticket, may be prepared that includes the plan for the rollback, e.g., the one or more actions needed to roll back the initial change. In configurations, a change ticket may include multiple changes and thus, for rollback, either all the changes associated with the change ticket may be rolled back or only the last change or action that was initially made may be rolled back.

Methods for network change tracking and rollback of changes based on change tickets

The present technology provides a framework for user-guided end-to-end automation of network deployment and management, that enables a user to guide the automation process for any kind of network deployment from the ground up, as well as offering network management, visibility, and compliance verification. The disclosed technology accomplishes this by creating a stateful and interactive virtual representation of a fabric using a customizable underlay fabric template instantiated with user-provided parameter values and network topology data computed from one or more connected network devices. A set of expected configurations corresponding to the user-specified underlay and overly fabric policies is then generated for deployment onto the connected network devices. Network deviations from the intended fabric policies are addressed by the provision of one or more configuration lines to be deployed onto or removed from the connected network devices to bring the network state in agreement with the set of expected configuration.

Multi-fabric deployment and management platform

Techniques for determining that a configuration change in configurations for a network device has occurred to result in changed configurations for the network device. The techniques include creating a policy for the network device by a network controller that manages one or more network devices. The network controller may obtain data from the network device, and update the network device policy based on the obtained data. In some examples, the network controller may compare the network device configurations state with the network controller intent to determine if an Out-of-Band (OOB) configuration change has occurred in the configuration of the network device. Finally, the controller may synchronize the network device to the controller based on the updated policy.

Monitoring interface configurations for network devices in fabrics

The present technology provides a system, method and computer-readable medium for configuration pattern recognition and inference, directed to a device with an existing configuration, through an extensible policy framework. The policy framework uses a mixture of python template logic and CLI micro-templates as a mask to infer the intent behind an existing device configuration in a bottom-up learning inference process. Unique values for device/network identifiers and addresses as well as other resources are extracted and accounted for. The consistency of devices within the fabric is checked based on the specific policies built into the extensible framework definition. Any inconsistencies found are flagged for user correction or automatically remedied by a network controller. This dynamic configuration pattern recognition ability allows a fabric to grow without being destroyed and re-created, thus new devices with existing configurations may be added and automatically configured to grow a Brownfield fabric.

Learning by inference from previous deployments

Techniques for a configuration change service to transition a network controller into a frozen state, causing network users submitting configuration changes associated with the network to refrain from deploying the configuration changes for a period of time are disclosed. A first user configured as a stager role may submit data representing a proposed change to the configuration change service, where the proposed change may be stored in association with a list of proposed changes. A second user configured as an approver role may submit data representing an approval or disapproval of the proposed changes to the configuration change service, where a modified list of proposed changes may be generated. A third user configured as an administrator role may submit data configured to transition the controller to an unfrozen state and/or deploy the changes included in the list of proposed changes to the network controller, subsequent to the period of time.

Staging configuration changes with deployment freeze options

Learning by inference from brownfield deployments

In one example embodiment, a computer-implemented method is provided in which data is received that represents connectivity state between a plurality of nodes interconnected in a hierarchical manner in a network and including a first tier of nodes and a second tier of nodes, wherein the nodes in the second tier have at least one link to each node in the first tier. Display data is generated based on the connectivity state among the plurality of nodes, the display data describing a graphical user representation of the inter-tier link status of individual nodes or groupings of nodes. The display data is presented to a display device.

Growing community of inventors

Pleasanton, CA, United States of America

Jason David Notari