Cisco Technology, Inc.

Kannan Ponnuswamy

Navneet Yadav

Arvind Chari

Paul John Lesiak

Sachin Waman Danait

Kollivakkam Raghavan

Chien-Ju Lo

Bill YuFan Chen

Chengguo Zhu

Tarique Shakil

Sanchay Harneja

Paul Andrew Raytick

Advait Dixit

Manali Holankar

Alok Lalit Wadhwa

Robert Bukofser

Manvesh Vyas

Furong Ma Gisiger

A monitoring device for troubleshooting events in a datacenter network identifies a first network event for a time period, and provides an initial display page, one or more additional display pages, selectable display objects, and a representation of the first network event. The device generates a dynamic troubleshooting path for the first network event to track a user navigation between display pages, a manipulation of the one or more selectable display objects, and a last-current display page, and also provides an indication of a second network event associated with higher resolution priority relative to the first network event. Retrieving the dynamic troubleshooting path causes the interface to present the last-current display page, apply the manipulation of the one or more selectable display objects, and load the user navigation between the initial dashboard display page and the one or more additional display pages in a cache.

Techniques and interfaces for troubleshooting datacenter networks

Systems, methods, and computer-readable media for providing cross-domain assurance for networks in different network domains. In some embodiments, a method can include collecting first fabric data for a first network in a first network domain and second fabric data for a second network in a second network domain. The second fabric data for the second network can be normalized based on the first network domain to create normalized second fabric data. The first fabric data can then be correlated with the normalized second fabric data to create correlated fabric data. Subsequently, assurance can be provided across the first network in the first network domain and the second network in the second network domain using the correlated fabric data.

Cross-domain network assurance

An example method for discovering and grouping application endpoints in a network environment is provided and includes discovering endpoints communicating in a network environment, calculating affinity between the discovered endpoints, and grouping the endpoints into separate endpoint groups (EPGs) according to the calculated affinity, each EPG comprising a logical grouping of similar endpoints for applying common forwarding and policy logic according to logical application boundaries. In specific embodiments, the affinity includes a weighted average of network affinity, compute affinity and user specified affinity.

Discovering and grouping application endpoints in a network environment

Systems, methods, and computer-readable media for providing network assurance across a network. In some embodiments, network traffic data of a cluster of nodes in a network environment can be gathered based on first network traffic flowing through the nodes using a first group of sensors implemented in the network environment. Network events occurring in the network environment can be identified, e.g. using sensors deployed in an infrastructure of the network environment. Subsequently, the network events can be correlated with the network traffic data to generate correlated network data for the network environment. The correlated network data for the network environment can be used to provide assurance between at least one server in the cluster of nodes and the network infrastructure of the network environment as part of providing assurance across the network environment.

Cross-domain assurance

Systems, methods, and computer-readable media are disclosed for validating endpoint information for nodes in a network. A network assurance appliance is configured to identify an endpoint in a bridge domain is associated with at least one subnet, retrieve at least one IP address associated with the endpoint, determine whether the at least one IP address is within the at least one subnet, and determine there is an inconsistency when the at least one IP address is not within the at least one subnet.

Endpoint bridge domain subnet validation

Disclosed are systems, methods, and computer-readable media for assuring tenant forwarding in a network environment. Network assurance can be determined in layer 1, layer 2 and layer 3 of the networked environment including, internal-internal (e.g., inter-fabric) forwarding and internal-external (e.g., outside the fabric) forwarding in the networked environment. The network assurance can be performed using logical configurations, software configurations and/or hardware configurations.

Validation of layer 1 interface in a network

Systems, methods, and devices are disclosed for generating an interface configured to display status information for network elements on a network. In embodiments, one or more logical models of the network are obtained from at least one of a plurality of controllers on a network. Network statistics are determined based on network traffic. Based on the one or more logical models and the network statistics, a topology of the network and respective status information of one or more network elements during an epoch is identified, the epoch defining a time interval. A user interface is generated that displays the respective status information in a timeline comprising one or more of the epochs.

Epoch data interface

Systems, methods, and computer-readable media for migrating to and maintaining a white-list network security model. Network traffic identified from permit-all access logs can be analyzed to determine whether it should be white-listed, and if so, a specific permit-access, without logging, policy is generated for the identified network traffic. The addition of specific permit-access policies is repeated on permit-all access logs, at which point, permit-all access policy is converted into deny-all access. In some examples, a system or method can obtain hit counts, from both hardware (eg: TCAM) and software tables, for the specific permit-access policy to determine existence of identified network traffic over a period of time. After analyzing hit counts, the specific permit-access policy can either continue to exist or be removed to maintain a white-list network security model.

Growing community of inventors

Murphy, TX, United States of America

Kannan Ponnuswamy