Patent Description:
The present technology pertains network analytics, and more specifically to the visualization of data flows between logical entities.

Datacenters can include a large number of servers and virtual machines. As such datacenters can have a large number of data flows between each server and virtual machine. Monitoring and managing the network of a datacenter can be cumbersome especially with a datacenter with a large number of servers, virtual machines and data flows. Visualizing the network of a datacenter can help network operators manage and monitor the network of a datacenter. However, because of the large number of data flows, visualizing these data flows can be very cumbersome.

<CIT> describes methods, systems, and apparatus for network monitoring and analytics. The methods, systems, and apparatus for network monitoring and analytics perform highly probable identification of related messages using one or more sparse hash function sets. Highly probable identification of related messages enables a network monitoring and analytics system to trace the trajectory of a message traversing the network and measure the delay for the message between observation points. The sparse hash function value, or identity, enables a network monitoring and analytics system to identify the transit path, transit time, entry point, exit point, and/or other information about individual packets and to identify bottlenecks, broken paths, lost data, and other network analytics by aggregating individual message data.

In order to describe the manner in which the above-recited and other advantages and features of the disclosure can be obtained, a more particular description of the principles briefly described above will be rendered by reference to specific embodiments that are illustrated in the appended drawings. Understanding that these drawings depict only example embodiments of the disclosure and are not therefore to be considered to be limiting of its scope, the principles herein are described and explained with additional specificity and detail through the use of the accompanying drawings in which:.

The invention of the present European application/patent is set out in the appended claims.

The present disclosure provides a mechanism for visualizing data flows within a datacenter in an interactive hierarchical network chord diagram. In some embodiments a dataflow monitoring system analyzes data describing data flows. Based on the analyzed data describing data flows, the dataflow monitoring system groups a portion of the data flows that originate at the same first endpoint and terminate at the same second endpoint. Subsequently, the dataflow monitoring system displays an interactive hierarchical network chord diagram to include a chord with a first endpoint and a second endpoint. The chord represents the grouped portion of data flows that originate at the same first endpoint and terminate at the same second endpoint. Upon receiving a selection of the chord or the first endpoint of the chord, the dataflow monitoring system expands the grouped portion of the data flows into sub-groupings of data flows and the first endpoint into a set of sub-endpoints. After which, the dataflow monitoring system updates the displayed interactive chord diagram to include the expanded chord and an expanded first endpoint.

Various embodiments of the disclosure are discussed in detail below. While specific implementations are discussed, it should be understood that this is done for illustration purposes only. A person skilled in the relevant art will recognize that other components and configurations may be used.

The disclosed technology is directed to the visualization of data flows within a datacenter. Specifically, to the generation and presentation of an interactive hierarchical network chord diagram (or network chord diagram) to represent analyzed data describing data flows within a datacenter. Additionally, the network chord diagram can visualize the data flows of a datacenter at different levels of abstraction. For example, at the lowest level of abstraction, data flows can be visualized according to the dataflow's individual sending and receiving hosts. At a higher level of abstraction, the data flows can be further grouped by clusters of hosts. As such, the network chord diagram can visualize the grouped data flows by their sending and receiving clusters of hosts. At even higher level of abstraction, the data flows can be further grouped together by common subnets of each cluster of hosts. As such, the network chord diagram can visualize the grouped data flows by their sending and receiving subnets. By allowing the user to visualize the data flows of a data center at different levels of abstraction, the user can more easily consume visualization of the data flows.

<FIG> illustrates a diagram of an example network environment <NUM>. Fabric <NUM> can represent the underlay (i.e., physical network) of network environment <NUM>. Fabric <NUM> can include spine routers <NUM>-N (<NUM>A-N) (collectively "<NUM>) and leaf routers <NUM>-N (<NUM>A-N) (collectively "<NUM>"). Leaf routers <NUM> can reside at the edge of fabric <NUM>, and can thus represent the physical network edge. Leaf routers <NUM> can be, for example, top-of-rack ("ToR") switches, aggregation switches, gateways, ingress and/or egress switches, provider edge devices, and/or any other type of routing or switching device.

Leaf routers <NUM> can be responsible for routing and/or bridging tenant or endpoint packets and applying network policies. Spine routers <NUM> can perform switching and routing within fabric <NUM>. Thus, network connectivity in fabric <NUM> can flow from the spine routers <NUM> to leaf routers <NUM>, and vice versa.

Leaf routers <NUM> can provide servers <NUM>-<NUM> (<NUM>A-E) (collectively "<NUM>"), hypervisors <NUM>-<NUM> (<NUM>A-<NUM>D) (collectively "<NUM>"), and virtual machines (VMs) <NUM>-<NUM> (<NUM>A-<NUM>E) (collectively "<NUM>") access to fabric <NUM>. For example, leaf routers <NUM> can encapsulate and decapsulate packets to and from servers <NUM> in order to enable communications throughout environment <NUM>. Leaf routers <NUM> can also connect other devices, such as device <NUM>, with fabric <NUM>. Device <NUM> can be any network-capable device(s) or network(s), such as a firewall, a database, a server, a collector <NUM> (further described below), an engine <NUM> (further described below), etc. Leaf routers <NUM> can also provide any other servers, resources, endpoints, external networks, VMs, services, tenants, or workloads with access to fabric <NUM>.

VMs <NUM> can be virtual machines hosted by hypervisors <NUM> running on servers <NUM>. VMs <NUM> can include workloads running on a guest operating system on a respective server. Hypervisors <NUM> can provide a layer of software, firmware, and/or hardware that creates and runs the VMs <NUM>. Hypervisors <NUM> can allow VMs <NUM> to share hardware resources on servers <NUM>, and the hardware resources on servers <NUM> to appear as multiple, separate hardware platforms. Moreover, hypervisors <NUM> and servers <NUM> can host one or more VMs <NUM>. For example, server <NUM>A and hypervisor <NUM>A can host VMs <NUM>A-B.

In some cases, VMs <NUM> and/or hypervisors <NUM> can be migrated to other servers <NUM>. For example, VM <NUM>A can be migrated to server <NUM>C and hypervisor <NUM>B. Servers <NUM> can similarly be migrated to other locations in network environment <NUM>. For example, a server connected to a specific leaf router can be changed to connect to a different or additional leaf router. In some cases, some or all of the servers <NUM>, hypervisors <NUM>, and/or VMs <NUM> can represent tenant space. Tenant space can include workloads, services, applications, devices, and/or resources that are associated with one or more clients or subscribers. Accordingly, traffic in the network environment <NUM> can be routed based on specific tenant policies, spaces, agreements, configurations, etc. Moreover, addressing can vary between one or more tenants. In some configurations, tenant spaces can be divided into logical segments and/or networks and separated from logical segments and/or networks associated with other tenants.

Any of leaf routers <NUM>, servers <NUM>, hypervisors <NUM>, and VMs <NUM> can include a sensor <NUM> configured to capture network data, and report any portion of the captured data to collector <NUM>. Sensors <NUM> can be processes, agents, modules, drivers, or components deployed on a respective system (e.g., a server, VM, hypervisor, leaf router, etc.), configured to capture network data for the respective system (e.g., data received or transmitted by the respective system), and report some or all of the captured data to collector <NUM>.

For example, a VM sensor can run as a process, kernel module, or kernel driver on the guest operating system installed in a VM and configured to capture data (e.g., network and/or system data) processed (e.g., sent, received, generated, etc.) by the VM. A hypervisor sensor can run as a process, kernel module, or kernel driver on the host operating system installed at the hypervisor layer and configured to capture data (e.g., network and/or system data) processed (e.g., sent, received, generated, etc.) by the hypervisor. A server sensor can run as a process, kernel module, or kernel driver on the host operating system of a server and configured to capture data (e.g., network and/or system data) processed (e.g., sent, received, generated, etc.) by the server. And a network device sensor can run as a process or component in a network device, such as leaf routers <NUM>, and configured to capture data (e.g., network and/or system data) processed (e.g., sent, received, generated, etc.) by the network device.

Sensors <NUM> can be configured to report data and/or metadata about one or more packets, flows, communications, processes, events, and/or activities observed to collector <NUM>. For example, sensors <NUM> can capture network data as well as information about the system or host of the sensors <NUM> (e.g., where the sensors <NUM> are deployed). Such information can also include, for example, data or metadata of active or previously active processes of the system, metadata of files on the system, system alerts, networking information, etc. Reported data from sensors <NUM> can provide details or statistics particular to one or more tenants. For example, reported data from a subset of sensors <NUM> deployed throughout devices or elements in a tenant space can provide information about the performance, use, quality, events, processes, security status, characteristics, statistics, patterns, conditions, configurations, topology, and/or any other information for the particular tenant space.

Additionally, the reports of sensors <NUM> can include timestamps associated with captured network traffic received, transmitted or generated by the host/node (e.g. VM, hypervisor, server, and leaf router). Sensors <NUM> can also associate a timestamp indicating when sensors <NUM> send the reports to collectors <NUM>. Regardless, the timestamps can be based on the clock of the host (e.g., server, switch, VM, hypervisor, etc.) of where the sensor resides. For example, timestamps associated with sensors <NUM> residing on hypervisor <NUM><NUM>B can be based on the clock of hypervisor <NUM><NUM>B. Furthermore, since multiple sensors <NUM> can reside on the same host, the reports of the multiple sensors <NUM> can be based on a same clock associated with the host or multiple clocks associated with the host. Collectors <NUM> can be one or more devices, modules, workloads and/or processes capable of receiving data from sensors <NUM>. Collectors <NUM> can thus collect reports and data from sensors <NUM>. Collectors <NUM> can be deployed anywhere in network environment <NUM> and/or even on remote networks capable of communicating with network environment <NUM>. For example, one or more collectors can be deployed within fabric <NUM> or on one or more of the servers <NUM>. One or more collectors can be deployed outside of fabric <NUM> but connected to one or more leaf routers <NUM>. Collectors <NUM> can be part of servers <NUM> and/or separate servers or devices (e.g., device <NUM>). Collectors <NUM> can also be implemented in a cluster of servers.

Collectors <NUM> can be configured to collect data from sensors <NUM>. In addition, collectors <NUM> can be implemented in one or more servers. As previously noted, collectors <NUM> can include one or more collectors. Moreover, each collector can be configured to receive reported data from all sensors <NUM> or a subset of sensors <NUM>. For example, a collector can be assigned to a subset of sensors <NUM> so the data received by that specific collector is limited to data from the subset of sensors.

Collectors <NUM> can be configured to aggregate data from all sensors <NUM> and/or a subset of sensors <NUM>. Moreover, collectors <NUM> can be configured to analyze some or all of the data reported by sensors <NUM>. For example, collectors <NUM> can include analytics engines (e.g., engines <NUM>) for analyzing collected data. Environment <NUM> can also include separate analytics engines <NUM> configured to analyze the data reported to collectors <NUM>. For example, engines <NUM> can be configured to receive collected data from collectors <NUM> and aggregate the data, analyze the data (individually and/or aggregated), generate reports, identify conditions, compute statistics, visualize reported data, troubleshoot conditions, visualize the network and/or portions of the network (e.g., a tenant space), generate alerts, identify patterns, calculate misconfigurations, identify errors, generate suggestions, generate testing, and/or any other analytics functions.

While collectors <NUM> and engines <NUM> are shown as separate entities, this is for illustration purposes as other configurations are also contemplated herein. For example, any of collectors <NUM> and engines <NUM> can be part of a same or separate entity. Moreover, any of the collector, aggregation, and analytics functions can be implemented by one entity (e.g., collectors <NUM>) or separately implemented by multiple entities (e.g., engine <NUM> and/or collectors <NUM>).

Each of the sensors <NUM> can use a respective address (e.g., internet protocol (IP) address, port number, etc.) of their host to send information to collectors <NUM> and/or any other destination. Moreover, sensors <NUM> can periodically send information about flows they observe to collectors <NUM>. Sensors <NUM> can be configured to report each and every flow they observe. Sensors <NUM> can report a list of flows that were active during a period of time (e.g., between the current time and the time of the last report). The communication channel between a sensor and collector <NUM> can also create a flow in every reporting interval. Thus, the information transmitted or reported by sensors <NUM> can also include information about the flow created by the communication channel.

<FIG> illustrates a schematic diagram of an example sensor deployment <NUM> in a virtualized environment. Server <NUM>A can run and host one or more VMs <NUM>. VMs <NUM> can be configured to run workloads (e.g., applications, services, processes, functions, etc.) based on hardware resources <NUM> on server <NUM>A. VMs <NUM> can run on guest operating systems <NUM> on a virtual operating platform provided by hypervisor <NUM>. Each VM can run a respective guest operating system which can be the same or different as other guest operating systems associated with other VMs on server <NUM>A. Moreover, each VM can have one or more network addresses, such as an internet protocol (IP) address. VMs <NUM> can thus communicate with hypervisor <NUM>, server <NUM>A, and/or any remote devices or networks using the one or more network addresses.

Hypervisor <NUM> can be a layer of software, firmware, and/or hardware that creates and runs VMs <NUM>. The guest operating systems running on VMs <NUM> can share virtualized hardware resources created by hypervisor <NUM>. The virtualized hardware resources can provide the illusion of separate hardware components. Moreover, the virtualized hardware resources can perform as physical hardware components (e.g., memory, storage, processor, network interface, etc.), and can be driven by hardware resources <NUM> on server <NUM>A. Hypervisor <NUM> can have one or more network addresses, such as an internet protocol (IP) address, to communicate with other devices, components, or networks. For example, hypervisor <NUM> can have a dedicated IP address which it can use to communicate with VMs <NUM>, server <NUM>A, and/or any remote devices or networks.

Hardware resources <NUM> of server <NUM>A can provide the underlying physical hardware driving operations and functionalities provided by server <NUM>A, hypervisor <NUM>, and VMs <NUM>. Hardware resources <NUM> can include, for example, one or more memory resources, one or more storage resources, one or more communication interfaces, one or more processors, one or more circuit boards, one or more extension cards, one or more power supplies, one or more antennas, one or more peripheral components, etc. Additional examples of hardware resources are described below with reference to <FIG> and <NUM>.

Server <NUM>A can also include one or more host operating systems. The number of host operating system can vary by configuration. For example, some configurations can include a dual boot configuration that allows server <NUM>A to boot into one of multiple host operating systems. In other configurations, server <NUM>A may run a single host operating system. Host operating systems can run on hardware resources <NUM>. In some cases, hypervisor <NUM> can run on, or utilize, a host operating system on server <NUM>A.

Server <NUM>A can also have one or more network addresses, such as an internet protocol (IP) address, to communicate with other devices, components, or networks. For example, server <NUM>A can have an IP address assigned to a communications interface from hardware resources <NUM>, which it can use to communicate with VMs <NUM>, hypervisor <NUM>, leaf router <NUM>A in <FIG>, collectors <NUM> in <FIG>, and/or any remote devices or networks.

VM sensors <NUM> can be deployed on one or more of the VMs <NUM>. VM sensors <NUM> can be data and packet inspection agents deployed on the VMs <NUM> to capture packets, flows, processes, events, traffic, and/or any data flowing through the VMs <NUM>. VM sensors <NUM> can be configured to export or report any data collected or captured by the sensors <NUM> to a remote entity, such as collectors <NUM>, for example. VM sensors <NUM> can communicate or report such data using a network address of the respective VMs <NUM> (e.g., VM IP address).

VM sensors <NUM> can capture and report any traffic (e.g., packets, flows, etc.) sent, received, generated, and/or processed by VMs <NUM>. For example, sensors <NUM> can report every packet or flow of communication sent and received by VMs <NUM>. Moreover, any communication sent or received by VMs <NUM>, including data reported from sensors <NUM>, can create a network flow. VM sensors <NUM> can report such flows to a remote device, such as collectors <NUM> illustrated in <FIG>. VM sensors <NUM> can report each flow separately or aggregated with other flows. When reporting a flow, VM sensors <NUM> can include a sensor identifier that identifies sensors <NUM> as reporting the associated flow. VM sensors <NUM> can also include a flow identifier, an IP address, a timestamp, metadata, a process ID, and any other information, as further described below.

VM sensors <NUM> can also report multiple flows as a set of flows. When reporting a set of flows, VM sensors <NUM> can include a flow identifier for the set of flows and/or a flow identifier for each flow in the set of flows. VM sensors <NUM> can also include one or more timestamps and other information as previously explained.

VM sensors <NUM> can run as a process, kernel module, or kernel driver on the guest operating systems <NUM> of VMs <NUM>. VM sensors <NUM> can thus monitor any traffic sent and received by VMs <NUM>, any processes running on the guest operating systems <NUM>, any workloads on VMs <NUM>, etc..

Hypervisor sensor <NUM> can be deployed on hypervisor <NUM>. Hypervisor sensor <NUM> can be a data inspection agent deployed on hypervisor <NUM> to capture traffic (e.g., packets, flows, etc.) and/or data flowing through hypervisor <NUM>. Hypervisor sensor <NUM> can be configured to export or report any data collected or captured by hypervisor sensor <NUM> to a remote entity, such as collectors <NUM>, for example. Hypervisor sensor <NUM> can communicate or report such data using a network address of hypervisor <NUM>, such as an IP address of hypervisor <NUM>.

Because hypervisor <NUM> can see traffic and data from VMs <NUM>, hypervisor sensor <NUM> can also capture and report any data (e.g., traffic data) associated with VMs <NUM>. For example, hypervisor sensor <NUM> can report every packet or flow of communication sent or received by VMs <NUM> and/or VM sensors <NUM>. Moreover, any communication sent or received by hypervisor <NUM>, including data reported from hypervisor sensor <NUM>, can create a network flow. Hypervisor sensor <NUM> can report such flows to a remote device, such as collectors <NUM> illustrated in <FIG>. Hypervisor sensor <NUM> can report each flow separately and/or in combination with other flows or data. When reporting a flow, hypervisor sensor <NUM> can include a sensor identifier that identifies hypervisor sensor <NUM> as reporting the flow. Hypervisor sensor <NUM> can also include a flow identifier, an IP address, a timestamp, metadata, a process ID, and any other information, as explained below.

Hypervisor sensor <NUM> can also report multiple flows as a set of flows. When reporting a set of flows, hypervisor sensor <NUM> can include a flow identifier for the set of flows and/or a flow identifier for each flow in the set of flows. Hypervisor sensor <NUM> can also include one or more timestamps and other information as previously explained.

As previously explained, any communication captured or reported by VM sensors <NUM> can flow through hypervisor <NUM>. Thus, hypervisor sensor <NUM> can observe and capture any flows or packets reported by VM sensors <NUM>. Accordingly, hypervisor sensor <NUM> can also report any packets or flows reported by VM sensors <NUM>. For example, VM sensor A on VM A captures flow <NUM> (F1) and reports F1 to collector <NUM> on <FIG>. Hypervisor sensor <NUM> on hypervisor <NUM> can also see and capture F1, as F1 would traverse hypervisor <NUM> when being sent or received by VM A. Accordingly, hypervisor sensor <NUM> on hypervisor <NUM> can also report F1 to collector <NUM>. Thus, collector <NUM> can receive a report of F1 from VM sensor A on VM A and another report of F1 from hypervisor sensor <NUM> on hypervisor <NUM>.

When reporting F1, hypervisor sensor <NUM> can report F1 as a message or a separate from the message or report of F1 transmitted by VM sensor A on VM A. However, hypervisor sensor <NUM> can also, or otherwise, report F1 as a message or report that includes or appends the message or report of F1 transmitted by VM sensor A on VM A. In other words, hypervisor sensor <NUM> can report F1 as a separate message or report from VM sensor A's message or report of F1, and/or a same message or report that includes both a report of F1 by hypervisor sensor <NUM> and the report of F1 by VM sensor A at VM A. In this way, VM sensors <NUM> at VMs <NUM> can report packets or flows received or sent by VMs <NUM>, and hypervisor sensor <NUM> at hypervisor <NUM> can report packets or flows received or sent by hypervisor <NUM>, including any flows or packets received or sent by VMs <NUM> and/or reported by VM sensors <NUM>.

Hypervisor sensor <NUM> can run as a process, kernel module, or kernel driver on the host operating system associated with hypervisor <NUM>. Hypervisor sensor <NUM> can thus monitor any traffic sent and received by hypervisor <NUM>, any processes associated with hypervisor <NUM>, etc..

Server <NUM>A can also have a server sensor <NUM> running on it. Server sensor <NUM> can be a data inspection agent deployed on server <NUM>A to capture data (e.g., packets, flows, traffic data, etc.) on server <NUM>A. Server sensor <NUM> can be configured to export or report any data collected or captured by server sensor <NUM> to a remote entity, such as collector <NUM>, for example. Server sensor <NUM> can communicate or report such data using a network address of server <NUM>A, such as an IP address of server <NUM>A.

Server sensor <NUM> can capture and report any packet or flow of communication associated with server <NUM>A. For example, sensor <NUM> can report every packet or flow of communication sent or received by one or more communication interfaces of server <NUM>A. Moreover, any communication sent or received by server <NUM>A, including data reported from sensors <NUM> and <NUM>, can create a network flow. Server sensor <NUM> can report such flows to a remote device, such as collector <NUM> illustrated in <FIG>. Server sensor <NUM> can report each flow separately or in combination. When reporting a flow, server sensor <NUM> can include a sensor identifier that identifies server sensor <NUM> as reporting the associated flow. Server sensor <NUM> can also include a flow identifier, an IP address, a timestamp, metadata, a process ID, and any other information.

Server sensor <NUM> can also report multiple flows as a set of flows. When reporting a set of flows, server sensor <NUM> can include a flow identifier for the set of flows and/or a flow identifier for each flow in the set of flows. Server sensor <NUM> can also include one or more timestamps and other information as previously explained.

Any communications capture or reported by sensors <NUM> and <NUM> can flow through server <NUM>A. Thus, server sensor <NUM> can observe or capture any flows or packets reported by sensors <NUM> and <NUM>. In other words, network data observed by sensors <NUM> and <NUM> inside VMs <NUM> and hypervisor <NUM> can be a subset of the data observed by server sensor <NUM> on server <NUM>A. Accordingly, server sensor <NUM> can report any packets or flows reported by sensors <NUM> and <NUM>. For example, sensor A on VM A captures flow <NUM> (F1) and reports F1 to collector <NUM> on <FIG>. Sensor <NUM> on hypervisor <NUM> can also see and capture F1, as F1 would traverse hypervisor <NUM> when being sent or received by VM A. In addition, sensor <NUM> on server <NUM>A can also see and capture F1, as F1 would traverse server <NUM>A when being sent or received by VM A and hypervisor <NUM>. Accordingly, sensor <NUM> can also report F1 to collector <NUM>. Thus, collector <NUM> can receive a report of F1 from sensor A on VM A, sensor <NUM> on hypervisor <NUM>, and sensor <NUM> on server <NUM>A.

When reporting F1, server sensor <NUM> can report F1 as a message or report that is separate from any messages or reports of F1 transmitted by sensor A on VM A or sensor <NUM> on hypervisor <NUM>. However, server sensor <NUM> can also, or otherwise, report F1 as a message or report that includes or appends the messages or reports or metadata of F1 transmitted by sensor A on VM A and sensor <NUM> on hypervisor <NUM>. In other words, server sensor <NUM> can report F1 as a separate message or report from the messages or reports of F1 from sensor A and sensor <NUM>, and/or a same message or report that includes a report of F1 by sensor A, sensor <NUM>, and sensor <NUM>. In this way, sensors <NUM> at VMs <NUM> can report packets or flows received or sent by VMs <NUM>, sensor <NUM> at hypervisor <NUM> can report packets or flows received or sent by hypervisor <NUM>, including any flows or packets received or sent by VMs <NUM> and reported by sensors <NUM>, and sensor 214at server <NUM>A can report packets or flows received or sent by server <NUM>A, including any flows or packets received or sent by VMs <NUM> and reported by sensors <NUM>, and any flows or packets received or sent by hypervisor <NUM> and reported by sensor <NUM>.

Server sensor <NUM> can run as a process, kernel module, or kernel driver on the host operating system or a component of server <NUM>A. Server sensor <NUM> can thus monitor any traffic sent and received by server <NUM>A, any processes associated with server <NUM>A, etc..

In addition to network data, sensors <NUM>, <NUM>, and <NUM> can capture additional information about the system or environment in which they reside. For example, sensors <NUM>, <NUM>, and <NUM> can capture data or metadata of active or previously active processes of their respective system or environment, metadata of files on their respective system or environment, timestamps, network addressing information, flow identifiers, sensor identifiers, etc. Moreover, sensors <NUM>, <NUM>, <NUM> are not specific to any operating system environment, hypervisor environment, network environment, or hardware environment. Thus, sensors <NUM>, <NUM>, and <NUM> can operate in any environment.

As previously explained, sensors <NUM>, <NUM>, and <NUM> can send information about the network traffic they observe. This information can be sent to one or more remote devices, such as one or more servers, collectors, engines, etc. Each sensor can be configured to send respective information using a network address, such as an IP address, and any other communication details, such as port number, to one or more destination addresses or locations. Sensors <NUM>, <NUM>, and <NUM> can send metadata about one or more flows, packets, communications, processes, events, etc..

Sensors <NUM>, <NUM>, and <NUM> can periodically report information about each flow or packet they observe. The information reported can contain a list of flows or packets that were active during a period of time (e.g., between the current time and the time at which the last information was reported). The communication channel between the sensor and the destination can create a flow in every interval. For example, the communication channel between sensor <NUM> and collector <NUM> can create a control flow. Thus, the information reported by a sensor can also contain information about this control flow. For example, the information reported by sensor <NUM> to collector <NUM> can include a list of flows or packets that were active at hypervisor <NUM> during a period of time, as well as information about the communication channel between sensor <NUM> and collector <NUM> used to report the information by sensor <NUM>.

The report(s) of sensors <NUM>, <NUM>, and <NUM> can include timestamps associated with captured network traffic received, transmitted or generated by the host/node (e.g. VM <NUM><NUM>, hypervisor <NUM> and server <NUM>A). Sensors <NUM>, <NUM>, and <NUM> can also associate a timestamp indicating when each respective sensor <NUM>, <NUM>, and <NUM> transmits its respective report(s) to the remote device, such as collectors <NUM> illustrated in <FIG>. Regardless, the timestamps associated by sensors <NUM>, <NUM>, and <NUM> can be based on the clock of the host/node (e.g. VM <NUM><NUM>, hypervisor <NUM> and server <NUM>A) where each respective sensor resides.

<FIG> illustrates a schematic diagram of an example sensor deployment <NUM> in an example network device. Network device is described as leaf router <NUM>A. However, this is for explanation purposes. Network device can be any other network device, such as any other switch, router, etc..

In this example, leaf router <NUM>A can include network resources <NUM>, such as memory, storage, communication, processing, input, output, and other types of resources. Leaf router <NUM>A can also include an operating system environment <NUM>. The operating system environment <NUM> can include any operating system, such as a network operating system. The operating system environment <NUM> can include processes, functions, and applications for performing networking, routing, switching, forwarding, policy implementation, messaging, monitoring, and other types of operations.

Leaf router <NUM>A can also include sensor <NUM>. Sensor <NUM> can be an agent configured to capture network data, such as flows or packets, sent and received by leaf router <NUM>A. Sensor <NUM> can also be configured to capture other information, such as processes, statistics, alerts, status information, device information, etc. Moreover, sensor <NUM> can be configured to report captured data to a remote device or network, such as collector <NUM>, for example. Sensor <NUM> can report information using one or more network addresses associated with leaf router <NUM>A. For example, sensor <NUM> can be configured to report information using an IP assigned to an active communications interface on leaf router <NUM>A.

Leaf router <NUM>A can be configured to route traffic to and from other devices or networks, such as server <NUM>A. Accordingly, sensor <NUM> can also report data reported by other sensors on other devices. For example, leaf router <NUM>A can be configured to route traffic sent and received by server <NUM>A to other devices. Thus, data reported from sensors deployed on server <NUM>A, such as VM and hypervisor sensors on server <NUM>A, would also be observed by sensor <NUM> and can thus be reported by sensor <NUM> as data observed at leaf router <NUM>A. Data reported by the VM and hypervisor sensors on server <NUM>A can therefore be a subset of the data reported by sensor <NUM>.

The report(s) of sensors <NUM> can include timestamps associated with captured network traffic received, transmitted or generated by the host/node (e.g. operating system environment <NUM> and network resources <NUM>). Sensors <NUM> can also associate a timestamp indicating when each respective sensor <NUM> transmits its respective report(s) to the remote device, such as collectors <NUM> illustrated in <FIG>. Regardless, the timestamps associated by sensors <NUM> can be based on a clock of the host/node (e.g. operating system environment <NUM> and network resources <NUM>) where each respective sensor resides.

Sensor <NUM> can run as a process or component (e.g., firmware, module, hardware device, etc.) in leaf router <NUM>A. Moreover, sensor <NUM> can be installed on leaf router <NUM>A as a software or firmware agent. In some configurations, leaf router <NUM>A itself can act as sensor <NUM>. Moreover, sensor <NUM> can run within the operating system <NUM> and/or separate from the operating system <NUM>.

<FIG> illustrates a schematic diagram of an example reporting system <NUM> in an example sensor topology. Leaf router <NUM>A can route packets or traffic <NUM> between fabric <NUM> and server <NUM>A, hypervisor <NUM>A, and VM <NUM>A. Packets or traffic <NUM> between VM <NUM>A and leaf router <NUM>A can flow through hypervisor <NUM>A and server <NUM>A. Packets or traffic <NUM> between hypervisor <NUM>A and leaf router <NUM>A can flow through server <NUM>A. Finally, packets or traffic <NUM> between server <NUM>A and leaf router <NUM>A can flow directly to leaf router <NUM>A. However, in some cases, packets or traffic <NUM> between server <NUM>A and leaf router <NUM>A can flow through one or more intervening devices or networks, such as a switch or a firewall.

Moreover, VM sensor <NUM> at VM <NUM>A, hypervisor sensor <NUM> at hypervisor <NUM>A, network device sensor <NUM> at leaf router <NUM>A, and any server sensor at server <NUM>A (e.g., sensor running on host environment of server <NUM>A), can send reports <NUM> to collector <NUM> based on the packets or traffic <NUM> captured at each respective sensor. Reports <NUM> from VM sensor <NUM> to collector <NUM> can flow through VM <NUM>A, hypervisor <NUM>A, server <NUM>A, and leaf router <NUM>A. Reports <NUM> from hypervisor sensor <NUM> to collector <NUM> can flow through hypervisor <NUM>A, server <NUM>A, and leaf router <NUM>A. Reports <NUM> from any other server sensor at server <NUM>A to collector <NUM> can flow through server <NUM>A and leaf router <NUM>A. Finally, reports <NUM> from network device sensor <NUM> to collector <NUM> can flow through leaf router <NUM>A.

Reports <NUM> can include any portion of packets or traffic <NUM> captured at the respective sensors. Reports <NUM> can also include other information, such as timestamps, process information, sensor identifiers, flow identifiers, flow statistics, notifications, logs, user information, system information, etc. Moreover, reports <NUM> can be transmitted to collector <NUM> periodically as new packets or traffic <NUM> are captured by a sensor. Further, each sensor can send a single report or multiple reports to collector <NUM>. For example, each of the sensors <NUM> can be configured to send a report to collector <NUM> for every flow, packet, message, communication, or network data received, transmitted, and/or generated by its respective host (e.g., VM <NUM>A, hypervisor <NUM>A, server <NUM>A, and leaf router <NUM>A). As such, collector <NUM> can receive a report of a same packet from multiple sensors.

The reports <NUM> of sensors <NUM> can include timestamps associated with captured network traffic received, transmitted or generated by the host/node (VM <NUM>A, hypervisor <NUM>A, server <NUM>A, and leaf router <NUM>A). Sensors <NUM> can also associate a timestamp indicating when each of the sensors <NUM> transmits reports <NUM> to the collector <NUM>. Regardless, the timestamps associated by sensors <NUM> can be based on a clock of the host/node (e.g. VM <NUM>A, hypervisor <NUM>A, server <NUM>A, and leaf router <NUM>A) where each of the respective sensors <NUM> resides.

For example, a packet received by VM <NUM>A from fabric <NUM> can be captured and reported by VM sensor <NUM>. Since the packet received by VM <NUM>A will also flow through leaf router <NUM>A and hypervisor <NUM>A, it can also be captured and reported by hypervisor sensor <NUM> and network device sensor <NUM>. Thus, for a packet received by VM <NUM>A from fabric <NUM>, collector <NUM> can receive a report of the packet from VM sensor <NUM>, hypervisor sensor <NUM>, and network device sensor <NUM>.

Similarly, a packet sent by VM <NUM>A to fabric <NUM> can be captured and reported by VM sensor <NUM>. Since the packet sent by VM <NUM>A will also flow through leaf router <NUM>A and hypervisor <NUM>A, it can also be captured and reported by hypervisor sensor <NUM> and network device sensor <NUM>. Thus, for a packet sent by VM <NUM>A to fabric <NUM>, collector <NUM> can receive a report of the packet from VM sensor <NUM>, hypervisor sensor <NUM>, and network device sensor <NUM>.

On the other hand, a packet originating at, or destined to, hypervisor <NUM>A, will can be captured and reported by hypervisor sensor <NUM> and network device sensor <NUM>, but not VM sensor <NUM>, as such packet would not flow through VM <NUM>A. Moreover, a packet originating at, or destined to, leaf router <NUM>A, will be captured and reported by network device sensor <NUM>, but not VM sensor <NUM>, hypervisor sensor <NUM>, or any other sensor on server <NUM>A, as such packet would not flow through VM <NUM>A, hypervisor <NUM>A, or server <NUM>A.

Each of the sensors <NUM> can include a respective unique sensor identifier on each of the reports <NUM> it sends to collector <NUM>, to allow collector <NUM> to determine which sensor sent the report. The reports <NUM> used to analyze network and/or system data and conditions for troubleshooting, security, visualization, configuration, planning, and management. Sensor identifiers in the reports <NUM> can also be used to determine which sensors reported what flows. This information can then be used to determine sensor placement and topology, as further described below. Sensor placement and topology information can be useful for analyzing the data in the reports <NUM>, as well as troubleshooting, security, visualization, configuration, planning, and management.

The visualization of the data collected from sensors <NUM> can be useful in the management and monitoring of a datacenter in which sensors <NUM> reside. However, with the large number of hosts within the datacenter, visualization of the data flows within the datacenter can be difficult to consume. As such, the data collected from sensors <NUM> that describe the data flows within the datacenter can be abstracted and displayed on an interactive hierarchical network chord diagram (or network chord diagram). <FIG> illustrates an example method for generating an interactive hierarchical network chord diagram (or network chord diagram). Example method <NUM> begins at step <NUM>. At step <NUM>, a dataflow monitoring system analyzes the data describing data flows. For example as illustrated in <FIG>, collector <NUM> can be the dataflow monitoring system configured to analyze the data describing the data flows reported by sensors <NUM>. In some embodiments, the collector <NUM> can include analytics engines <NUM>. Analytics engines <NUM> can configured to do the actual analysis of the data reported by sensors <NUM>. In some embodiments, analytics engines <NUM> can be separate from collector <NUM> and can operate in conjunction or independently with collector <NUM>, when analyzing the data reported by sensors <NUM>.

The data describing the data flows can describe the data flows between logical entities or endpoints of a data enter. A logical entity or endpoint can represent a host (e.g. server, switch, VM, hypervisor, router, etc.), cluster of hosts or one or more subnets. Furthermore data describing the data flows can also describe the attributes of each dataflow (e.g. a sending or originating host, a receiving or terminating host, a sending host subnet, a receiving host subnet and the one or more policies that correspond to the dataflow, etc.).

At step <NUM>, the dataflow monitoring system (e.g. analytics engine <NUM>, collector <NUM>, etc.) can group portions of data flows that originate at the same first endpoint and terminate the same second endpoint. The dataflow monitoring system (e.g. analytics engine <NUM>, collector <NUM>, etc.) can identify the originating endpoint and terminating endpoint of each data flow from the identified attributes of each data flow. For example, analytics engine <NUM> can identify the sending and receiving hosts of each dataflow and group of the data flows according to the same sending host and/or the same receiving host. In another example, analytics engine <NUM> can group portions of the data flows by the subnet of the sending host and/or the subnet of the receiving host.

Sub-groups can also be identified within each grouped portion of data flows. The dataflow monitor (e.g. collector <NUM> or analytics engine <NUM>) can identify or determine sub-groups within each grouped portion. For example analytics engine <NUM> groups portions of data flows that all originate at a subnet and all terminate at another different subnet. Analytics engine <NUM> can also identify one or more subgroups within each subnet group. For example, analytics engine <NUM> can identify one or more clusters of hosts within each subnet group. Additionally, analytics engine <NUM> can identify the portions of data flows within the grouped portion of data flows that originate and/or terminate at the same cluster of hosts within each subnet group. The dataflow monitor system can identify as many different levels of abstraction as needed. For instance, continuing from the example above, analytics engine <NUM> can identify or group one or more sub-groups within each sub-group (e.g. on a host basis).

At step <NUM>, the dataflow monitoring system (e.g. analytics engine <NUM>, collector <NUM>, etc.) can then display a network chord diagram of the analyzed data describing the data flows on a user interface of a computing device (smart phone, laptop, desktop, etc.). Each cord displayed in the network chord diagram represents a grouped portion of bi-directional data flows that originate at the same first endpoint and terminate at the same second endpoint. Each chord in the network chord diagram can also represent one or more policies that are similarly enforced over each represented grouped portion of data flows. Each endpoint or any abstraction thereof visualized in the network chord diagram represents an endpoint that a grouped portion of data flows or an individual dataflow originates from or terminates at. In some embodiments each endpoint visualized in the network cord diagram represents one or more subnets. In some embodiments each endpoint visualized in the network cord diagram represents one or more clusters of hosts. In some embodiments each endpoint visualized in the network chord diagram represents an individual host.

An example of a network chord diagram is shown in <FIG> all illustrate example visualizations of the same chord diagram <NUM>. Example chord diagram <NUM> includes multiple chords (e.g. <NUM>, <NUM>, <NUM> and <NUM>) and multiple endpoints (e.g. <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> and <NUM>). As illustrated each chord, <NUM>, <NUM>, <NUM> and <NUM>, all terminate or originate at endpoints <NUM>, <NUM>, <NUM>, <NUM> and <NUM>. Each cord represents a grouped portion of data flows that all originate from one endpoint and terminate at another endpoint. For example, as illustrated in <FIG>, example chord diagram <NUM> includes chord <NUM> that originates/terminates at endpoint <NUM> and terminates/originates at chord <NUM>.

At step <NUM>, the dataflow monitoring system determines whether a chord or either endpoint of a chord has been selected in the network chord diagram. If the dataflow monitoring system determines a chord or an endpoint of the chord have not been selected, then the dataflow monitoring system continues to display the interactive hierarchical network chord diagram. However, if the dataflow monitoring system determines a chord or either endpoint of the chord has been selected, then the method proceeds to step <NUM>.

At step <NUM>, the dataflow monitoring system (e.g. analytics engine <NUM>, collector <NUM>, etc.) expands the grouped portion of data flows and corresponding endpoints. In some embodiments, selection of the chord causes the dataflow monitoring system to expand the grouped portion of data flows and/or either or both endpoints of the grouped portion of data flows. For example, selection of the chord causes analytics engine <NUM> to expand the represented grouped portion of data flows into sub-groupings of data flows. In another example, selection of the chord causes analytics engine <NUM> to expand one or both of the endpoints of the selected chord into sets of sub-endpoints. In another example, selection of the chord causes analytics engine <NUM> to expand the grouped portion of data flows into sub-groupings of data flows and one or both endpoints of the chords into sets of sub-endpoints.

In some embodiments, selection of an endpoint expands the network topology constructed using the dataflow monitoring system (e.g. analytics engine <NUM>, collector <NUM>, etc.) to expand the represented endpoint or the corresponding grouped portion of data flows. The expansion of the represented endpoint is based on the identified attributes of each corresponding grouped portions of data flows. As such, selection of an endpoint can cause analytics engine <NUM> to expand the represented endpoint into a more granular representation of the network topology. Furthermore, in some embodiments, selection of an endpoint also causes analytics engine <NUM> to expand the corresponding grouped portion of data flows (either originating from or terminating at the represented endpoint) into sub-groupings of data flows. For example, the selected endpoint represents a subnet. As such the dataflow monitoring system identifies clusters of hosts within the subnet (from the attributes of the corresponding grouped portion of data flows) and expands the subnet into said clusters of hosts. In another example, the selected endpoint represents a cluster of hosts. As such, the dataflow monitoring system (e.g. analytics engine <NUM>, collector <NUM>, etc.) identifies the individual hosts within the clusters of hosts (from the attributes of the corresponding grouped portion of data flows) and can expand the cluster of hosts into individual hosts.

In some embodiments, using the above described techniques, the selection of an endpoint causes the dataflow monitoring system (e.g. analytics engine <NUM>, collector <NUM>, etc.) to expand the grouped portion of data flows that terminate at or originate from the represented endpoint.

In some embodiments, using the above described techniques, selection of any endpoint of a chord or the chord itself causes the dataflow monitoring system (e.g. analytics engine <NUM>, collector <NUM>, etc.) to expand the represented endpoint, the corresponding grouped portion of data flows and the corresponding chord(s) other endpoint(s).

At step <NUM>, the dataflow monitoring system (analytics engine <NUM>, collector <NUM>, etc.) updates the displayed network chord diagram to include a set of sub-chords and the set of sub-endpoints. The sub-chords represent the sub-groupings of data flows that originate and/or terminate at the set of sub-endpoints. An example of the updated display of the network chord diagram is illustrated in <FIG> illustrates the updated display after the selection of endpoint <NUM>. Expanded endpoint <NUM> results in sub-endpoint <NUM>, <NUM>, <NUM> and <NUM>. Sub-endpoint <NUM>, <NUM>, <NUM> and <NUM> correspond with chords <NUM>, <NUM>, <NUM> and <NUM> respectively. In some embodiments, as illustrated in <FIG>, endpoint <NUM> represents a subnet and sub-endpoints <NUM>, <NUM>, <NUM> and <NUM> represent different clusters of hosts. In other embodiments, as illustrated in <FIG>, endpoint <NUM> represents a subnet and sub-endpoints <NUM>, <NUM>, <NUM> and <NUM> represent different individual hosts. In other embodiments, as illustrated in <FIG>, endpoint <NUM> represents a cluster of hosts and sub-endpoints <NUM>, <NUM>, <NUM> and <NUM> represent different individual hosts.

In some circumstances, the user (e.g. network operator) may want be informed of the previous level of abstraction while the current endpoint is expanded. For example, a representation of the previous level of abstraction can be included in the network chord diagram. <FIG> illustrates this notifying representation. In <FIG>, endpoint <NUM> is displayed outside the sub-endpoints <NUM>, <NUM>, <NUM> and <NUM>. Endpoint <NUM> in <FIG> represents the previous level of abstraction of the lower level of abstraction sub-endpoints <NUM>, <NUM>, <NUM> and <NUM>.

It should be noted that for sake of simplicity, <FIG> only illustrates the expansion of the selected endpoint <NUM>. However, using the above described techniques, the chords and/or the other corresponding endpoints of the chords can additionally be expanded. However, for sake of simplicity, in this example, as illustrated in <FIG>, only the endpoints are expanded.

The network chord diagram can be further drilled down to as many levels of abstraction as needed. For example, using the above described techniques, the sub-endpoints can be further expanded into sub-sub-endpoints. The expansion of the sub-endpoints can be based on the identified attributes of the sub-groupings of data flows. For example, following <FIG>, assume that the sub-endpoints and chords represent grouped portion of data flows that originate from and terminate at identified clusters of hosts (<NUM>, <NUM>, <NUM>, <NUM>) within the subnet endpoint <NUM>. The dataflow monitor (e.g. analysis engine <NUM>, collector <NUM>, etc.) can identify the individual hosts within those clusters of hosts and the sub-groupings of data flows that originate from or terminate at those identified individual hosts. Again the expansion of the sub-endpoints and/or corresponding chords can be triggered by the selection of a sub-endpoints, corresponding chords/sub-chords and/or the other endpoints/sub-endpoints of the corresponding chord/sub-chord.

The interactive hierarchical network chord diagram (e.g. network chord diagram <NUM>) can visualize the expansion of sub-endpoints. Following the previous example, <FIG> illustrates an example updated display of the interactive hierarchical network chord diagram drilled down to an even lower level of abstraction. Network chord diagram <NUM> of <FIG> illustrates the selection of sub-endpoint <NUM> results in the expansion of sub-endpoint <NUM> into sub-sub-endpoint <NUM>, <NUM> and <NUM>. In this example, the expansion of sub-endpoint <NUM> also expands chord <NUM> into a set of sub-chords <NUM>, <NUM> and <NUM>. Sub-chord <NUM>, <NUM> and <NUM> originate or terminate at sub-endpoints <NUM>, <NUM> and <NUM>, respectively.

Again, the user (e.g. network operator) can be informed of the previous level of abstraction while the current level of abstraction is expanded (e.g. the expanded endpoint, sub-endpoint, sub-sub endpoint, sub-sub-sub endpoint, etc.). In fact a notifying representation can be displayed for any displayed level of abstraction. For example, a representation of the previous level of abstraction can be included in the network chord diagram. <FIG> illustrates this notifying representation. In <FIG>, endpoint <NUM> and sub-endpoint <NUM> is displayed outside the sub-sub-endpoints <NUM>, <NUM> and <NUM>. Endpoint <NUM> and sub-endpoint <NUM> in <FIG> represents the previous level of abstraction of the lower level of abstraction sub-sub-endpoints <NUM>, <NUM> and <NUM>.

The user-interface (UI) displaying the network chord diagram can also include navigation tools and other graphical representations that display additional information related to network chord diagram. <FIG> and <FIG> illustrate example user interfaces for a network chord diagram. UI <NUM> includes example network chord diagram <NUM>, display bar <NUM>, navigation tools <NUM> and search bar <NUM>. Example network chord diagram <NUM> corresponds to the expanded network chord diagram <NUM> of <FIG>.

Display bar <NUM> can include multiple graphical representations to display additional information about the network overall or the network chord diagram itself (e.g. network chord diagram <NUM>). For example, display bar <NUM> can display information about the different network zones (e.g. number and names of the different network zones within the network or network chord diagram <NUM>), the policies enforced for each dataflow within the network or network chord diagram <NUM> (e.g. the number of policies, the name of each policy, details about what each policy is enforcing, etc.), the number of applications within the network, the clusters within the network or network chord diagram <NUM> (e.g. the names of each cluster, the number of clusters within the network, the logical entities that are within each cluster, etc.), the number of dataflows or conversations that are occurring between each endpoint within the network or network chord diagram <NUM>, the number of endpoints within the network or network chord diagram <NUM>, etc.).

Navigation bar (458A, 458B, 458C, 458D and 458E or collectively as <NUM>) can include a number of tools to navigate the displayed network chord diagram (e.g. network chord diagram <NUM>). For example, navigation bar <NUM> can include magnification tool 458A to zoom in and out of the network chord diagram. Navigation bar <NUM> can include a manual navigation tool 458B to filter down the chord chart by only showing selected subnets/hosts. Navigation bar <NUM> can include a remove filter tool 458C to undo a selection of a selected subnet/host by toll 458B. , Navigation bar <NUM> can include a remove unselected host tool 458D which filters out all unselected subnets/hosts. Navigation bar <NUM> can also include a search bar button 458E that, if selected, can trigger the display of a search bar. Other tools are also possible, such as centering tools, chord selection tools, remove all filters tool, etc..

Example UI <NUM> can also include a search bar. In some circumstances, the user (e.g. a network operator) may know and specifically want to search for a particular logical entity within the network as represented by the displayed network chord diagram. In some embodiments, as illustrated in <FIG>, entering the name of a logical entity or endpoint (e.g. subnet, clusters of hosts, individual hosts, etc.) in search bar <NUM>, search bar <NUM> can return and display results in table <NUM>. For example, as illustrated in <FIG>, the user has input a subnet endpoint <NUM>. <NUM> into search bar <NUM>. As such, table <NUM> displays the illustrated results. The displayed results in <FIG> is only an illustration of what additional information UI <NUM> can display and such an illustration should not limit the scope of this application. For example, table <NUM> can include the name of the host, the name of the cluster, the silhouette score, and an alternate cluster. Since hosts are clustered based on their behavior, a host might potentially belong to an alternate cluster and maybe even more than one alternate cluster. The host has an affinity for each cluster called a "silhouette score. " Thus the silhouette score shown in table <NUM> of <FIG> represents the hosts affinity for the named alternate cluster. The host will usually have a lower affinity for the alternate cluster. Additionally, table <NUM> can expand or further display other information relating to the searched endpoint. For instance, as illustrated in table <NUM>, table <NUM> includes graphical representations, that if selected can display additional information about server load balancing (SLB) tags, route tags, distinctive connections with the searched endpoint and with other endpoints within the network, and the number of endpoints the search endpoint provides data to and consumes data from.

In some embodiments table <NUM> is dynamically linked to chord chart <NUM>. When an endpoints or clusters found in the search in table <NUM> is clicked on the chord chart <NUM> can dynamically highlight or expand such endpoints or clusters to call out the element being selected. This feature is very helpful to dig up a node or cluster from a chord chart filled with thousands of elements.

In some embodiments, selection of the chord or endpoint can trigger display of additional information, similar to table <NUM>. For example, assume, as <FIG> illustrates, endpoint <NUM> has been selected and expanded. Additionally assume endpoint <NUM> represents subnet <NUM>. As such, the corresponding expansion is displayed in network chord diagram <NUM> and since endpoint <NUM> (representing subnet <NUM>. <NUM>) has been selected; table <NUM> is generated and displayed. In such an embodiment, table <NUM> can also display additional information about the corresponding sub-endpoints <NUM>, <NUM>, <NUM> and <NUM>. For example table <NUM> can additional display information related to the corresponding data flows originating/terminating at sub-endpoints <NUM>, <NUM>, <NUM> and <NUM> (e.g. the policies of each dataflow). In some embodiments, the user can select a specific chord to only view additional data about the selected chord.

In some embodiments, selection of a chord (including sub-chords, sub-sub chords or any level of abstraction of these chords) can also display a table similar to that of table <NUM>. In such an embodiment, the selection of the chord triggers the display of information related to all corresponding endpoints. In some embodiments, the user can select a specific endpoint to only view additional data about the selected endpoint.

In other embodiments selection of an endpoint or chord (including all other iterations of abstracted levels of endpoints and chords) can collapse a previously selected and expanded endpoint and/or cord. Furthermore, selection of an endpoint and/or chord displays additional information for only the currently selected chord and/or endpoint. In other embodiments, the UI can display additional information for all the endpoints and/or chords selected by the user. The displayed additional information for all the endpoints and/or chords are removed only when specifically closed by the user.

<FIG> illustrates an example network device <NUM> according to some embodiments. Network device <NUM> includes a master central processing unit (CPU) <NUM>, interfaces <NUM>, and a bus <NUM> (e.g., a PCI bus). When acting under the control of appropriate software or firmware, the CPU <NUM> is responsible for executing packet management, error detection, and/or routing functions. The CPU <NUM> preferably accomplishes all these functions under the control of software including an operating system and any appropriate applications software. CPU <NUM> may include one or more processors <NUM> such as a processor from the Motorola family of microprocessors or the MIPS family of microprocessors. In an alternative embodiment, processor <NUM> is specially designed hardware for controlling the operations of router <NUM>. In a specific embodiment, a memory <NUM> (such as non-volatile RAM and/or ROM) also forms part of CPU <NUM>. However, there are many different ways in which memory could be coupled to the system.

The interfaces <NUM> are typically provided as interface cards (sometimes referred to as "line cards"). Generally, they control the sending and receiving of data packets over the network and sometimes support other peripherals used with the router <NUM>. Among the interfaces that may be provided are Ethernet interfaces, frame relay interfaces, cable interfaces, DSL interfaces, token ring interfaces, and the like. In addition, various very high-speed interfaces may be provided such as fast token ring interfaces, wireless interfaces, Ethernet interfaces, Gigabit Ethernet interfaces, ATM interfaces, HSSI interfaces, POS interfaces, FDDI interfaces and the like. Generally, these interfaces may include ports appropriate for communication with the appropriate media. In some cases, they may also include an independent processor and, in some instances, volatile RAM. The independent processors may control such communications intensive tasks as packet switching, media control and management. By providing separate processors for the communications intensive tasks, these interfaces allow the master microprocessor <NUM> to efficiently perform routing computations, network diagnostics, security functions, etc..

Although the system shown in <FIG> is one specific network device of the present invention, it is by no means the only network device architecture on which the present invention can be implemented. For example, an architecture having a single processor that handles communications as well as routing computations, etc. is often used. Further, other types of interfaces and media could also be used with the router.

The memory or memories may also be configured to store tables such as mobility binding, registration, and association tables, etc..

<FIG> illustrate example system embodiments. The more appropriate embodiment will be apparent to those of ordinary skill in the art when practicing the present technology. Persons of ordinary skill in the art will also readily appreciate that other system embodiments are possible.

<FIG> illustrates a conventional system bus computing system architecture <NUM> wherein the components of the system are in electrical communication with each other using a bus <NUM>. Exemplary system <NUM> includes a processing unit (CPU or processor) <NUM> and a system bus <NUM> that couples various system components including the system memory <NUM>, such as read only memory (ROM) <NUM> and random access memory (RAM) <NUM>, to the processor <NUM>. The system <NUM> can include a cache of high-speed memory connected directly with, in close proximity to, or integrated as part of the processor <NUM>. The system <NUM> can copy data from the memory <NUM> and/or the storage device <NUM> to the cache <NUM> for quick access by the processor <NUM>. In this way, the cache can provide a performance boost that avoids processor <NUM> delays while waiting for data. These and other modules can control or be configured to control the processor <NUM> to perform various actions. Other system memory <NUM> may be available for use as well. The memory <NUM> can include multiple different types of memory with different performance characteristics. The processor <NUM> can include any general purpose processor and a hardware module or software module, such as module <NUM><NUM>, module <NUM><NUM>, and module <NUM><NUM> stored in storage device <NUM>, configured to control the processor <NUM> as well as a special-purpose processor where software instructions are incorporated into the actual processor design. The processor <NUM> may essentially be a completely self-contained computing system, containing multiple cores or processors, a bus, memory controller, cache, etc. A multi-core processor may be symmetric or asymmetric.

To enable user interaction with the computing device <NUM>, an input device <NUM> can represent any number of input mechanisms, such as a microphone for speech, a touch-sensitive screen for gesture or graphical input, keyboard, mouse, motion input, speech and so forth. An output device <NUM> can also be one or more of a number of output mechanisms known to those of skill in the art. In some instances, multimodal systems can enable a user to provide multiple types of input to communicate with the computing device <NUM>. The communications interface <NUM> can generally govern and manage the user input and system output. There is no restriction on operating on any particular hardware arrangement and therefore the basic features here may easily be substituted for improved hardware or firmware arrangements as they are developed.

The storage device <NUM> can include software modules <NUM>, <NUM>, <NUM> for controlling the processor <NUM>. Other hardware or software modules are contemplated. The storage device <NUM> can be connected to the system bus <NUM>. In one aspect, a hardware module that performs a particular function can include the software component stored in a computer-readable medium in connection with the necessary hardware components, such as the processor <NUM>, bus <NUM>, display <NUM>, and so forth, to carry out the function.

<FIG> illustrates an example computer system <NUM> having a chipset architecture that can be used in executing the described method and generating and displaying a graphical user interface (GUI). Computer system <NUM> is an example of computer hardware, software, and firmware that can be used to implement the disclosed technology. System <NUM> can include a processor <NUM>, representative of any number of physically and/or logically distinct resources capable of executing software, firmware, and hardware configured to perform identified computations. Processor <NUM> can communicate with a chipset <NUM> that can control input to and output from processor <NUM>. In this example, chipset <NUM> outputs information to output <NUM>, such as a display, and can read and write information to storage device <NUM>, which can include magnetic media, and solid state media, for example. Chipset <NUM> can also read data from and write data to RAM <NUM>. A bridge <NUM> for interfacing with a variety of user interface components <NUM> can be provided for interfacing with chipset <NUM>. Such user interface components <NUM> can include a keyboard, a microphone, touch detection and processing circuitry, a pointing device, such as a mouse, and so on. In general, inputs to system <NUM> can come from any of a variety of sources, machine generated and/or human generated.

Chipset <NUM> can also interface with one or more communication interfaces <NUM> that can have different physical interfaces. Such communication interfaces can include interfaces for wired and wireless local area networks, for broadband wireless networks, as well as personal area networks. Some applications of the methods for generating, displaying, and using the GUI disclosed herein can include receiving ordered datasets over the physical interface or be generated by the machine itself by processor <NUM> analyzing data stored in storage <NUM> or <NUM>. Further, the machine can receive inputs from a user via user interface components <NUM> and execute appropriate functions, such as browsing functions by interpreting these inputs using processor <NUM>. It can be appreciated that example systems <NUM> and <NUM> can have more than one processor <NUM> or be part of a group or cluster of computing devices networked together to provide greater processing capability.

Claim 1:
A computer-implemented method comprising:
analyzing (<NUM>) data describing data flows between endpoints, wherein part of the data describes one or more policies that correspond to each data flow;
grouping (<NUM>) a first portion of the data flows that originate at a same first endpoint (<NUM>) and terminate at a same second endpoint (<NUM>) and grouping a second portion of the data flows that originate at the same first endpoint and terminate at a same third endpoint (<NUM>);
displaying (<NUM>) a network chord diagram (<NUM>) including a first chord (<NUM>) representing the first grouped portion of data flows that originate at the same first endpoint and terminate at the same second endpoint and a second chord (<NUM>) representing the second grouped portion of data flows that originate at the same first endpoint and terminate at the same third endpoint,
wherein each chord in the network chord diagram corresponds to one or more policies of each represented grouped portion of data flows; and
displaying information about the policies enforced for each data flow.