Generate a communication graph using an application dependency mapping (ADM) pipeline

Abstract

This disclosure generally relates to a method and system for generating a communication graph of a network using an application dependency mapping (ADM) pipeline. In one aspect of the disclosure, the method comprises receiving network data (e.g., flow data and process information at each node) from a plurality of sensors associated with a plurality of nodes of the network, determining a plurality of vectors and an initial graph of the plurality of nodes based upon the network data, determining similarities between the plurality of vectors, clustering the plurality of vectors into a plurality of clustered vectors based upon the similarities between the plurality of vectors, and generating a communication graph of the network system based upon the plurality of clustered vectors.

Description

TECHNICAL FIELD

The disclosure relates generally to computer networks. More specifically, the present technology relates to a method and system for generating communication graph in a network.

BACKGROUND

A modern computer network comprises a large amount of highly distributed nodes and data. The highly distributed data can be very difficult to be collected and analyzed. Network information is typically collected and analyzed based upon historic data. Building policies in a network based upon network information is often labor intensive and can become prohibitive when there are frequent changes in the network or frequent demands in building new policies.

It remains a challenge to build near real-time communication graph such that a user or network administrator can respond to potential threats, improve business operations, have a better network experience, or maximize network stability and performance at a lowest possible cost.

BRIEF DESCRIPTION OF THE DRAWINGS

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 examples thereof which are illustrated in the appended drawings. Understanding that these drawings depict only examples 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:

FIG. 1A and FIG. 1B illustrate schematic block diagrams of an application dependency mapping (ADM) system, according to some examples;

FIG. 2 illustrates an example of an ADM system adopting a leaf-spine architecture, according to some examples;

FIG. 3 is a flow diagram illustrating an example of a process to generate a communication graph using an ADM pipeline, according to some examples; and

FIGS. 4A and 4B illustrate a computing platform of a computing device, according to some examples.

DESCRIPTION OF EXAMPLES

Various examples of the present technology 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 without departing from the spirit and scope of the present technology.

Overview

Aspects of the present technology relate to techniques that enable generating a communication graph of a network using an application dependency mapping (ADM) pipeline. By collecting flow data and process information at each node of the network, the present technology can generate a near real-time communication graph using the ADM pipeline. In this disclose, the term “node” is used interchangeably with endpoint, machine, or virtual machine (VM).

In accordance with one aspect of the present disclosure, a computer-implemented method is provided to generate a communication graph of a network using an ADM pipeline. The method comprises receiving network data (e.g., flow data and process information at each node) from a plurality of sensors associated with a plurality of nodes of the network, determining a plurality of vectors and an initial graph of the plurality of nodes based upon the network data, determining similarities between the plurality of vectors, clustering the plurality of vectors into a plurality of clustered vectors based upon the similarities between the plurality of vectors, and generating a communication graph of the network system based upon the plurality of clustered vectors. The communication graph can provide visibility into the network and make it possible to efficiently build application profiles in the network.

In some examples, a method of generating a communication graph of a network system further comprises defining a policy of the network based upon generated communication graph, presenting the policy to a user of the network system, collecting feedback (e.g., granularity of clustering the plurality of vectors in the network) from the user, and re-generating the communication graph and policies of the network system based upon the user feedback. Some aspects of the present technology further enable the policy to be enforced in the network system. For example, a network communication between two nodes can be prohibited if the network communication is not specifically included in the policies.

In some examples, flow data and process information at each node of a plurality of nodes of a network are collected and summarized into flow summaries on a regular basis (e.g., daily). Data, such as the flow summaries, side information, server load balancing (SLB), route tags, and a plurality of clustered vectors generated in a previous run of ADM pipeline, can be used as an input data to a new ADM pipeline run. Using the flow summaries rather than raw flow data and processing information at each node may substantially reduce processing capacity and time needed to generate a new ADM pipeline run. Some examples of the present technology may further reduce processing capacity and time needed to generate an ADM pipeline run by partitioning nodes of the plurality of nodes into external and internal subnets, processing node vectors (i.e., feature reduction, term frequency-inverse document frequency (tfidf), and normalization), and preserving certain information for a next run or recycling data from a previous ADM pipeline run.

In some examples, a plurality of nodes of a network can be clustered into a plurality of clustered vectors based at least upon a communication pattern and processes running on each node of the plurality of nodes. Some aspects of the present technology can determine similarity scores between any two nodes of the plurality of nodes. The plurality of clustered vectors can be determined based at least upon the similarity scores between nodes of the plurality of nodes.

Some examples of the present technology provide a user interface (UI) for a user of a network to view generated clustered vectors, edit a specific cluster vector (i.e., add or remove a node), modify input parameters to cluster a plurality of nodes in the network, and start a new ADM pipeline run. The UI may provide an option for the user to generate or name a new workspace, select nodes/sensors in an ADM pipeline run, choose input parameters for the ADM pipeline run, and finalize and export a defined policy. The input parameters may include, but are not limited to, time granularity (e.g., a range of time that flow data and process information is to be analyzed), nodes to be included in the ADM pipeline run, side information (e.g., routs/subnets, load balancer information), and clustering granularity. After the new ADM pipeline run is completed, some examples may further provide statistics (e.g., a number of nodes in generated communication graph), a summary of each cluster vector's node members and server/client ports, a summary of changes between two ADM pipeline runs, options to edit each of the plurality of cluster vectors (e.g., add or remove a node to or from a specific cluster vector), add or edit name description for each of the plurality of cluster vectors, or approve the plurality of cluster vectors), application profiles of the plurality of nodes, and an option to start a new ADM pipeline run.

According to some examples, the present technology further enables a system comprising: one or more processors, and memory including instructions that, upon being executed by the one or more processors, cause the system to receive network data from a plurality of sensors associated with a plurality of nodes of a network, determine a plurality of vectors and an initial graph of the plurality of nodes based upon the network data, determine similarities between the plurality of vectors, clustering the plurality of vectors into a plurality of clustered vectors based upon the similarities between the plurality of vectors, and generate a communication graph of the network system based upon the plurality of clustered vectors.

In accordance with another aspect of the present disclosure, a non-transitory computer-readable storage medium storing instructions is provided, the instructions which, when executed by a processor, cause the processor to perform operations comprising, receiving network data (e.g., flow data and process information at each node) from a plurality of sensors associated with a plurality of nodes of a network, determining a plurality of vectors and an initial graph of the plurality of nodes based upon the network data, determining similarities between the plurality of vectors, clustering the plurality of vectors into a plurality of clustered vectors based upon the similarities between the plurality of vectors, and generating a communication graph of the network system based upon the plurality of clustered vectors.

Although many of the examples herein are described with reference to the application dependency mapping and discovery, it should be understood that these are only examples and the present technology is not limited in this regard. Rather, any other network information applications may be realized. Additionally, even though the present disclosure uses a sensor as a data-collecting device, the present technology is applicable to other controller or device that is capable of review, record and report network communication data between various end groups.

Additional features and advantages of the disclosure will be set forth in the description which follows, and, in part, will be obvious from the description, or can be learned by practice of the herein disclosed principles. The features and advantages of the disclosure can be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. These and other features of the disclosure will become more fully apparent from the following description and appended claims, or can be learned by the practice of the principles set forth herein.

DETAILED DESCRIPTION

FIG. 1A illustrates a schematic block diagram of an application dependency mapping system (ADM) 100A, according to some examples. The ADM system 100A can include, for example, a configuration/image imaginer 102, sensors 104, collectors 122, analytics module 124, ADM policy engine 126, user input module 127 and presentation module 128. It should be appreciated that the system topology in FIG. 1A is an example system, and any numbers of computing devices such as sensors, collectors, and network components may be included in the system of FIG. 1A.

The configuration/image manager 102 can configure and manage sensors 104. For example, when a new virtual machine is instantiated or when an existing virtual machine is migrated, the configuration/image manager 102 can provision and configure a new sensor on the virtual machine. According to some examples, the configuration/image manager 102 can monitor the physical status or heathy of the sensors 104. For example, the configuration/image manager 102 may request status updates or initiate tests. According to some examples, the configuration/image manager 102 can also manage and provisions virtual machines.

According to some examples, the configuration/image manager 102 can verify and validate the sensors 104. For example, the sensors 104 can be associated with a unique ID. The unique ID can be generated using a one-way hash function of its basic input/output system (BIOS) universally unique identifier (UUID) and a secret key stored on the configuration and image manager 102. The unique ID can be a large number that is difficult for an imposter sensor to guess. According to some examples, the configuration/image manager 102 can keep the sensors 104 up to date by monitoring versions of software installed on the sensors 104, applying patches, and installing new versions if necessary. In some examples, the configuration/image manager 102 can get the update of the software installed on the sensors 104 from a local source or automatically from a remote source via Internet.

The sensors 104 can be associated with each node or component of a data center (e.g., virtual machine, hypervisor, slice, blade, switch, router, gateway, etc.). Sensors 104 can monitor communications to and from the nodes of the data center, report environmental data related to the nodes (e.g., node IDs, statuses, etc.), and perform suitable actions related to the nodes (e.g., shut down a process, block ports, redirect traffic, etc.). The sensors 104 can send their records over a high-bandwidth connection to the collectors 122 for storage.

In this example, the sensors 104 can be software codes (e.g., running on virtual machine 106, container 112, or hypervisor 108), an application-specific integrated circuit (e.g., ASIC 110, a component of a switch, gateway, router, or standalone packet monitor), or an independent unit (e.g., a device connected to a switch's monitoring port or a device connected in series along a main trunk of a datacenter). For clarity and simplicity in this description, the term “component” is used to denote a component of the network (i.e., a process, module, slice, blade, hypervisor, machine, switch, router, gateway, etc.). It should be understood that various software and hardware configurations can be used as the sensors 104. The sensors 104 can be lightweight, minimally impeding normal traffic and compute resources in a datacenter. The software sensors 104 can “sniff” packets being sent over its host network interface card (NIC) or individual processes can be configured to report traffic to the sensors 104.

According to some examples, the sensors 104 reside on every virtual machine, hypervisor, switch, etc. This layered sensor structure allows for granular packet statistics and data collection at each hop of data transmission. In some examples, the sensors 104 are not installed in certain places. For example, in a shared hosting environment, customers may have exclusive control of VMs, thus preventing network administrators from installing a sensor on those client-specific VMs.

As the sensors 104 capture communication data, they can continuously send network flow data to collectors 122. The network flow data can relate to a packet, collection of packets, flow, group of flows, open ports, port knocks, etc. The network flow data can also include other details such as the VM bios ID, sensor ID, associated process ID, associated process name, process user name, sensor private key, geo-location of sensor, environmental details, etc. The network flow data can comprise data describing communications on all layers of the OSI model. For example, the network flow data can include Ethernet signal strength, source/destination MAC address, source/destination IP address, protocol, port number, encryption data, requesting process, a sample packet, etc.

In some examples, the sensors 104 can preprocess network flow data before sending. For example, the sensors 104 can remove extraneous or duplicative data or create a summary of the data (e.g., latency, packets and bytes sent per traffic flow, flagging abnormal activity, etc.). According to some examples, the sensors 104 are configured to selectively capture certain types of connection information while disregarding the rest. Further, to avoid capturing every packet and overwhelming the system, the sensors 104 can be configured to capture only a representative sample of packets (e.g., every 1,000th packet). According to some examples, the sensors 104 can generate aggregate or summarized network flow data that has been subjected to processing, rendering the network flow data light-weighted for subsequent transmitting and processing.

According to some examples, the sensors 104 can perform various actions with regard to the associated network component. For example, a sensor installed on a VM can close, quarantine, restart, or throttle a process executing on the VM. The sensors 104 can create and enforce policies (e.g., block access to ports, protocols, or addresses). According to some examples, the sensors 104 can perform such actions autonomously or perform the actions based upon external instructions.

The sensors 104 can send network flow data to one or more collectors 122. The one or more collectors 122 can comprise a primary collector and a secondary collector, or substantially identical collectors. In some examples, each of the sensors 104 is not assigned any specific collector. A sensor can determine an optimal collector through a discovery process. The sensor may change an optimal collector to report to when network environment changes, for example, when a determined optimal collector fails or when the sensor is migrated to a new location that is close to a different collector. According to some examples, a sensor may send different network flow data to different collectors. For example, the sensor can send a first report related to one type of process to a first collector, and send a second report related to a different type of process to a second collector.

The collectors 122 can be any type of storage medium that serves as a repository for the data recorded by the sensors 104. According to some examples, the collectors 122 are directly connected to the top of rack (TOR) switch; alternatively, the collectors 122 can be located near the end of row or elsewhere on or off premises. The placement of the collectors 122 can be optimized according to various priorities such as network capacity, cost, and system responsiveness. According to some examples, data storage of the collectors 122 is located in an in-memory database such as dash DB by IBM™. This approach can benefit from rapid random access speeds that typically are required for analytics software. Alternatively, the collectors 122 can utilize solid state drives, disk drives, magnetic tape drives, or a combination of the foregoing in consideration of cost, responsiveness, and size requirements. The collectors 122 can utilize various database structures such as a normalized relational database or NoSQL database.

According to some examples, the collectors 122 serve as network storage for application dependency mapping system 100A. Additionally, the collectors 122 can organize, summarize, and preprocess the collected data. For example, the collectors 122 can tabulate or summarize how often packets with certain sizes or types are transmitted from different virtual machines. The collectors 122 can also characterize traffic flows going to and from various network components or nodes. According to some examples, the collectors 122 can match packets based on sequence numbers, thus identifying traffic flows as well as connection links.

According to some examples, the collectors 122 can flag anomalous data. To avoid keeping all network data indefinitely, the collectors 122 can regularly replace detailed network flow data with consolidated summaries. Hence, the collectors 122 can retain a complete dataset describing network flow and process information over a certain period of time (e.g., the past minute), a smaller dataset describing network flow and process information over a previous period of time (e.g., the previous minute), and progressively consolidated network flow and process data over a broader period of time (e.g., hour, day, week, month, or year). By organizing, summarizing, and preprocessing the data, the collectors 122 can help the ADM system 100A scale efficiently. Although the collectors 122 are generally herein referred to as a plural noun, a single machine or cluster of machines are contemplated to be sufficient, especially for smaller datacenters. In some examples, the collectors 122 can serve as sensors 104 as well.

According to some examples, in addition to data from the sensors 104, the collectors 122 can receive other types of data. For example, the collectors 122 can receive out-of-band data 114 that includes, for example, geolocation data 116, IP watch lists 118, and WhoIs data 120. Additional out-of-band data can include power status, temperature data, etc.

The configuration/image manager 102 can configure and manage the sensors 104. When a new virtual machine is instantiated or when an existing one is migrated, the configuration and image manager 102 can provision and configure a new sensor on the machine. In some examples configuration and image manager 102 can monitor health of the sensors 104. For example, the configuration and image manager 102 may request status updates or initiate tests. In some examples, the configuration and image manager 102 may also manage and provision virtual machines.

The analytics module 124 can accomplish various tasks in its analysis, some of which are herein disclosed. By processing data stored in various collectors 122, the analytics module 124 can automatically generate an application dependency map (e.g., a communication graph), which depicts physical and logical dependencies of the application components, as well as the dependencies between components of the underlying infrastructure resources. The application dependency map can be used to determine, for example, communication paths between nodes and TCP ports used for communication, as well as the processes executing on the nodes. This map can be instructive when the analytics module 124 attempts to determine a root cause of a failure (because a failure of one component can cascade and cause failure of its dependent components) or when the analytics module 124 attempts to predict what will happen if a component is taken offline. Additionally, the analytics module 124 can associate expected latency and bandwidth with corresponding edges of an application dependency map.

For example, if a component A routinely sends data to a component B, but the component B never sends data to the component A, then the analytics module 124 can determine that the component B is dependent on the component A. On the other hand, the component A is likely not dependent on component B. If, however, the component B also sends data to the component A, then they are likely interdependent. These components can be processes, virtual machines, hypervisors, VLANs, etc. Once the analytics module 124 has determined component dependencies, it can then form an application dependency map that represents an application network topology.

Similarly, based upon data provided from the sensors 104, the analytics module 124 can determine relationships between interdependent applications, the analytics module 124 can determine what type of devices exist on the network (brand and model of switches, gateways, machines, etc.), where they are physically located (e.g., latitude and longitude, building, datacenter, room, row, rack, machine, etc.), how they are interconnected (10 Gb Ethernet, fiber-optic, etc.), and what the strength of each connection is (bandwidth, latency, etc.). Automatically determined network topology can be used to integrate the ADM system 100A within an established datacenter. Furthermore, the analytics module 124 can detect changes of a network topology.

In some examples, the analytics module 124 can establish patterns and norms for component behavior. Based upon the patterns and norms, the analytics module 124 can determine that certain processes (when functioning normally) only send a certain amount of traffic to a certain VM using a certain set of ports. The analytics module 124 can establish these norms by analyzing individual components or by analyzing data coming from similar components (e.g., VMs with similar configurations). Similarly, the analytics module 124 can determine expectations for network operations. For example, it can determine the expected latency between two components, the expected throughput of a component, response time of a component, typical packet sizes, traffic flow signatures, etc. In some examples, the analytics module 124 can combine its dependency map with pattern analysis to create reaction expectations. For example, if traffic increases with one component, other components may predictably increase traffic in response (or latency, compute time, etc.).

According to some examples, the analytics module 124 uses machine learning techniques to identify which patterns are policy-compliant or unwanted or harmful. For example, a network administrator can indicate network states corresponding to an attack and network states corresponding to normal operation. The analytics module 124 can then analyze the data to determine which patterns most correlate with the network being in a complaint or non-compliant state. According to some examples, the network can operate within a trusted environment for a time so that the analytics module 124 can establish baseline normalcy. According to some examples, the analytics module 124 contains a database of norms and expectations for various components. This database can incorporate data from sources external to the network. The analytics module 124 can then create network security policies for how components can interact. According to some examples, when policies are determined external to the system 100A, the analytics module 124 can detect the policies and incorporate them into this framework. The network security policies can be automatically modified by a server system or manually tweaked by a network administrator. For example, network security policies can be dynamically changed and be conditional on events. These policies can be enforced on the components. The ADM policy engine 126 can maintain these network security policies and receive user input to change the policies.

The ADM policy engine 126 can configure the analytics module 124 to establish what network security policies exist or should be maintained. For example, the ADM policy engine 126 may specify that certain machines should not intercommunicate or that certain ports are restricted. A network policy controller can set the parameters of the ADM policy engine 126. According to some examples, the ADM policy engine 126 is accessible via the presentation module 128.

In some example, the analytics module 124 and the ADM policy engine 126 can be combined or integrated into an ADM analytics and policy engine 100B, as illustrated in FIG. 1B. The ADM analytics and policy engine 100B is configured to provide functions and services of the analytics module 124 and the ADM policy engine 126, discussed herein.

According to some examples, the analytics module 124 can determine similarity scores for the nodes, which indicate similarity levels among the plurality of nodes. The presentation module 128 can display the similarity scores on a user interface. Further, the system can generate node clusters based on the similarity levels of the node, e.g. nodes sharing a high similarity score (e.g., higher than a selected threshold) are associated with one node cluster.

In some examples, the presentation module 128 can comprise a serving layer 129 and a user interface (UI) 130 that is operable to display, for example, information related to the application dependency map. The aggregate network flow data, analyzed by the analytics module 124, may not be in a human-readable form or may be too large for an administrator to navigate. The presentation module 128 can take the network flow data generated by the analytics module 124 and further summarize, filter, and organize the network flow data as well as create intuitive presentations of the network flow data.

The serving layer 129 can be an interface between the presentation module 128 and the analytics module 124. As the analytics module 124 generates node attributes, the serving layer 129 can summarize, filter, and organize the attributes that comes from the analytics module 124. According to some examples, the serving layer 129 can request raw data from a sensor, collector, or the analytics module 124.

The UI 130, connected with the serving layer 129, can present the data in a format (e.g., pages, bar charts, core charts, tree maps, acyclic dependency maps, line graphs, or tables) for human presentation. The UI 130 can be configured to allow a user to “drill down” on information sets to get a filtered data representation specific to the item the user wishes to “drill down” to. For example, the filtered data representation can be individual traffic flows, components, etc. The UI 130 can also be configured to allow a user to search using a filter. This search filter can use natural language processing to analyze a network administrator's input. Options can be provided on the UI 130 to view data relative to the current second, minute, hour, day, etc. The UI 130 can allow a network administrator to view traffic flows, application dependency maps, network topology, etc.

According to some examples, the UI 130 can receive inputs from a network administrator to adjust configurations in the ADM system 100A or components of the datacenter. These instructions can be passed through the serving layer 129, and then sent to the configuration/image manager 102, or sent to the analytics module 124.

After receiving an adjustment to an input parameter, the analytics module 124 can generated an updated application dependency map using adjusted parameters. For example, a user can remove or add a node from a selected node cluster and rerun the node clustering, or an ADM pipeline. The user can define a period of time for generating the updated application dependency map, for example, Jan. 1, 2015-Jan. 15, 2015. The user can also create/name a new workspace, select nodes for generating the updated map, and upload side information, such as routs/subnets and load balancer information, for generating the application dependency map. Additionally, the user can, while adjusting part of the cluster parameters, approve or preserve certain cluster such that they are not subjected to modifications or re-runs.

Further, the user can adjust the clustering granularity, for example, via a knob or a selectable element on the UI 130. The clustering granularity can generated a preferred number of node clusters. For example, a coarse-grained system with a low granularity comprises fewer clusters of nodes, whereas a fine-grained system with a higher granularity comprises more clusters of nodes in an application dependency map.

With the updated application dependency mapping completed, the user can view network information on the UI 130. The network information can include, for example, number/name of node clusters, port information related to nodes, and comparison summary between most recent two ADM runs.

Additionally, various elements of the ADM system 100A can exist in various configurations. For example, the collectors 122 can be a component of the sensors 104. In some examples, additional elements can share certain portion of computation to reduce loading of the analytics module 124.

FIG. 2 illustrates an example of an ADM system 200 adopting a leaf-spine architecture, according to some examples. In this example, the ADM system 200 comprises a network fabric 201 that includes spine switches 202_a, 202_b, . . . , 202_n (collectively, “202”) connected to leaf switches 204_a, 204_b, 204_c, . . . , 204_n (collectively “204”). The leaf switches 204 can include access ports (or non-fabric ports) and fabric ports. Fabric ports can provide uplinks to the spine switches 202, while access ports can provide connectivity for devices, hosts, end points, VMs, or external networks to the network fabric 201. Although a leaf-spine architecture is illustrated in the network fabric 201, one of ordinary skill in the art will readily recognize that the subject technology can be implemented in any suitable network fabric, including a data center or cloud network fabric. Other suitable architectures, designs, infrastructures, and variations are contemplated herein.

The spine switches 202 can provide various network capacities, such as 40 or 10 Gbps Ethernet speeds. The spine switches 202 can include one or more 40 Gigabit Ethernet ports, each of which can also be split to support other speeds. For example, a 40 Gigabit Ethernet port can be split into four 10 Gigabit Ethernet ports.

The leaf switches 204 can reside at an edge of the network fabric 201, thus representing the physical network edge. According to some examples, the leaf switches 204 can be top-of-rack switches configured according to a top-of-rack architecture. According to some examples, the leaf switches 204 can be aggregation switches in any particular topology, such as end-of-row or middle-of-row topologies. The leaf switches 204 can also represent aggregation switches.

In some examples, the leaf switches 204 are responsible for routing and/or bridging the tenant packets and applying network policies. According to some examples, a leaf switch can perform one or more additional functions, such as implementing a mapping cache, sending packets to a proxy function when there is a miss in the cache, encapsulate packets, enforce ingress or egress policies, etc.

Network packets of the network fabric 201 can flow through the leaf switches 204. For example, the leaf switches 204 can provide servers, resources, endpoints, external networks, or VMs network access to the network fabric 201. According to some examples, the leaf switches 204 can connect the network fabric 201 to one or more end point groups, or any external networks. Each end point group can connect to the network fabric 201 via one of leaf switches 204.

In this example, endpoints 218_a-218_d (collectively “218”) can connect to the network fabric 201 via the leaf switches 204. For example, the endpoints 218_a and 218_b can connect directly to the leaf switch 204A. On the other hand, the endpoints 218_c and 218_d can connect to the leaf switch 204_b via a L1 network 208. Similarly, a wide area network (WAN) 220 can connect to the leaf switches 204_n via L2 network 210.

The endpoints 218 can include any communication device or component, such as a node, computer, server, blade, hypervisor, virtual machine, container, process (e.g., running on a virtual machine), switch, router, gateway, etc. According to some examples, the endpoints 218 can include a server, hypervisor, process, or switch configured with a VTEP functionality which connects an overlay network with the network fabric 201. The overlay network can host physical devices, such as servers, applications, EPGs, virtual segments, virtual workloads, etc. In addition, the endpoints 218 can host virtual workload(s), clusters, and applications or services, which are connected to the network fabric 201 or any other device or network, including an external network. For example, one or more endpoints 218 can host, or connect to, a cluster of load balancers or an end point group of various applications.

In some examples, sensors 206_a-206_b (collectively “206) are associated with each node and component of a data center (e.g., virtual machine, hypervisor, slice, blade, switch, router, gateway, etc.). As illustrated in FIG. 2, the sensors 206 can be respectively associated with the leaf switches 204 and the endpoints 218. The sensors 206 can monitor communications to and from the component, report on environmental data related to the component (e.g., component IDs, statuses, etc.), and perform actions related to the component (e.g., shut down a process, block ports, redirect traffic, etc.). The sensors 206 can send these data to the collectors 212 for storage.

The sensors 206 can preprocess network flow data before sending out. For example, sensors 206 can remove extraneous or duplicative data or create a summary of the data (e.g., indicating latency and packets and bytes sent per traffic flow, or flagging abnormal activity). According to some examples, the sensors 206 are configured to selectively capture certain types of connection information while disregarding the rest. Further, to avoid overwhelming a system, sensors can capture only a representative sample of packets (for example, every 1,000th packet).

According to some examples, the sensors 206 can perform various actions with regard to associated network components. For example, a sensor installed on a VM can close, quarantine, restart, or throttle a process executing on the VM. The sensors 206 can create and enforce security policies (e.g., block access to ports, protocols, or addresses). According to some examples, the sensors 206 perform such actions autonomously or perform the actions based upon an external instruction.

The sensors 206 can send network flow data to one or more collectors 212. The one or more collectors 212 can comprise a primary collector and a secondary collector, or substantially identical collectors. In some examples, each of the sensors 206 is not assigned any specific collector. A sensor can determine an optimal collector through a discovery process. The sensor may change an optimal collector to report to when network environment changes, for example, when a determined optimal collector fails or when the sensor is migrated to a new location that is close to a different collector. According to some examples, a sensor may send different network flow data to different collectors 212. For example, the sensor can send a first report related to one type of process to a first collector, and send a second report related to a different type of process to a second collector.

The collectors 212 can be any type of storage medium that can serve as a repository for the data recorded by the sensors. The collectors 212 can be connected to the network fabric 201 via one or more network interfaces. The collectors 212 can be located near the end of row or elsewhere on or off premises. The placement of the collectors 212 can be optimized according to various priorities such as network capacity, cost, and system responsiveness. Although collectors 122 are generally herein referred to as a plural noun, a single machine or cluster of machines are contemplated to be sufficient, especially for smaller datacenters. In some examples, the collectors 122 can function as the sensors 202 as well.

According to some examples, the collectors 212 serve as network storage for network flow data. Additionally, the collectors 212 can organize, summarize, and preprocess the collected data. For example, the collectors 212 can tabulate how often packets of certain sizes or types are transmitted from different virtual machines. The collectors 212 can also characterize the traffic flows going to and from various network components. According to some examples, the collectors 212 can match packets based on sequence numbers, thus identifying traffic flows as well as connection links.

An analytics module 214 can automatically generate an application dependency map (e.g., a communication graph), which shows physical and logical dependencies of the application components, as well as dependencies between components of the underlying infrastructure resources. The application dependency map can be used to determine, for example, communication paths between nodes and TCP ports used for communication, as well as the processes executing on the nodes. The application dependency map can be instructive when analytics module 214 attempts to determine a root cause of a failure (because failure of one component can cascade and cause failure of its dependent components) or when the analytics module 214 attempts to predict what will happen if a component is taken offline. Additionally, the analytics module 214 can associate edges of an application dependency map with expected latency and bandwidth for that individual edge.

Similarly, based upon data provided from the sensors 206, the analytics module 214 can determine relationships between interdependent applications, the analytics module 214 can determine what type of devices exist on the network (brand and model of switches, gateways, machines, etc.), where they are physically located (e.g., latitude and longitude, building, datacenter, room, row, rack, machine, etc.), how they are interconnected (10 Gb Ethernet, fiber-optic, etc.), and what the strength of each connection is (bandwidth, latency, etc.). Automatically determined network topology can be used to integrate the ADM system 200 within an established datacenter. Furthermore, the analytics module 214 can detect changes of a network topology.

According to some examples, the analytics module 214 can determine similarity scores for the nodes, which indicate similarity levels among the plurality of nodes. A presentation module 222 can display the similarity scores on a user interface. Further, the system 200 can generate node clusters based on the similarity levels between the nodes, e.g. nodes sharing a high similarity score (e.g., higher than a selected threshold) are associated with one node cluster.

According to some examples, the ADM system 200 can enable re-runs of application dependent mapping to implement various adjustments to the system 200. For example, a system administrator can make one or more adjustments, e.g. editing the size of the clusters, changing data-capturing time, to optimize performance of the system 200. The analytics module 214 can compare the re-run data with the original data to summarize or highlight changes, e.g. determining the changes using a matching algorithm. Additionally, the presentation module 222 can display a summary of the changes on a user interface. This feature can help the administrator or user to track implemented changes and make necessary adjustments to improve performance of the system 200.

FIG. 3 is a flow diagram illustrating an example of a process 300 to generate a communication graph using an ADM pipeline, according to some examples. It should be understood that there can be additional, fewer, or alternative steps performed in similar or alternative orders, or in parallel, within the scope of the various examples unless otherwise stated.

At step 302, an ADM system can collect network data and process information of a plurality of nodes in a network using a plurality of sensors. The plurality of sensors includes at least a sensor of a physical switch of the network, a sensor of a hypervisor associated with the physical switch, or a sensor of a virtual machine associated with the hypervisor. For example, as illustrated in FIGS. 1A and 2, the plurality of sensors can be associated with various nodes and components of a data center (e.g., virtual machine, hypervisor, slice, blade, switch, router, gateway, etc.). The plurality of sensors can be respectively associated with leaf switches, hypervisors, and virtual machines and be configured to monitor communications to and from associated components or nodes, report environmental data related to the nodes (e.g., node IDs, statuses, etc.), and perform suitable actions related to the nodes (e.g., shut down a process, block ports, redirect traffic, etc.).

At step 304, the ADM system can determine a plurality of vectors based upon the network data and process information collected at each node of the plurality of nodes. In some examples, the network data and process information collected at each node are summarized into flow summaries on a regular basis (e.g., daily). Data, such as the flow summaries, side information, SLB, and route tags, can be used in determining the plurality of vectors and an initial communication graph. Using the flow summaries rather than raw flow data and processing information at each node may substantially reduce processing capacity and time needed for the system to generate the plurality of vectors and the initial communication graph. The system may further reduce processing capacity and time needed to generate an ADM pipeline run by partitioning nodes of the plurality of nodes into external and internal subnets, processing node vectors (i.e., feature reduction, tfidf, and normalization), and preserving certain information for a next run or recycling data from a previous ADM pipeline run.

At step 306, the ADM system can determine similarities between nodes of the plurality of nodes. The similarities can be measured by similarity scores that are determined based upon the network data and process information collected at the two nodes. At step 308, the ADM system can cluster the plurality of nodes of the network into a plurality of clustered vectors based upon similarities between nodes of the plurality of nodes. The plurality of clustered vectors represents a communication graph of the network. The ADM system may cluster nodes that share a high similarity score (e.g., higher than a selected threshold) into one node cluster. For examples, if a node A and a node B both communicate with a node C via a port 40, the node A and the node B may be deemed similar and clustered into the same cluster.

At step 310, the ADM system can define a policy of the network based upon the plurality of clustered vectors or the communication graph. For example, the policy may prohibit a network communication between two nodes if the network communication is not specifically included in the policy.

At step 312, the ADM system can present the policy to a user and collect the user's feedback. In some examples, the ADM system can provide a user interface (UI) for a user of a network to view generated clustered vectors, edit a specific cluster vector (i.e., add or remove a node), modify input parameters to cluster a plurality of nodes in the network, and start a new ADM pipeline run. The UI may provide an option for the user to generate or name a new workspace, select nodes/sensors in generating the plurality of clustered vectors or the communication graph, choose input parameters for the communication graph, and finalize and export a defined policy. The input parameters may include, but are not limited to, time granularity (e.g., a range of time that flow data and process information is to be analyzed), nodes to be included in an ADM pipeline run to generate a communication graph, side information (e.g., routs/subnets, load balancer information), and clustering granularity.

Based upon a user's feedback, the ADM system can re-cluster the plurality of clustered vector and regenerate the communication graph. A user can view on a user interface information such as statistics of the network, number/name of the node clusters, port information related to nodes, comparison summary between the last ADM to the recent ADM. Cluster statistics can include 1) the number of clusters that is added, 2) the number of clusters that is removed, 3) the number of existing clusters that are modified, and 4) the number of clusters remain unchanged, etc.

At step 314, the ADM system can enforce the policy in the network. For example, the ADM system may prohibit communications between the plurality of nodes of the network if the communications are not provided in the policy.

In some examples, the ADM system can automatically generate a communication graph by analyzing aggregate network flow data. The communication graph can be used to identify, for example, communication paths between the nodes, the TCP ports used for communication, as well as the processes executing on the nodes. This communication graph can be instructive when the ADM system attempts to determine the root cause of a failure (because a failure of one component in the ADM system can cascade and cause failure of dependent components) or when the ADM system attempts to predict what happens if a component is taken offline. Additionally, the ADM system can associate anticipated latency and bandwidth with nodes of the network based upon the communication graph.

FIGS. 4A and 4B illustrate example possible systems in accordance with various aspects of the present technology. The more appropriate example 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 examples are possible.

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

To enable user interaction with the computing device 400, an input device 445 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 435 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 400. The communications interface 440 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 can easily be substituted for improved hardware or firmware arrangements as they are developed. Any features or steps in any example of this patent application may be mixed with any other features or steps in any other examples.

Storage device 430 is a non-volatile memory and can be a hard disk or other types of computer readable media which can store data that are accessible by a computer, such as magnetic cassettes, flash memory cards, solid state memory devices, digital versatile disks, cartridges, random access memories (RAMs) 425, read only memory (ROM) 420, and hybrids thereof.

The storage device 430 can include software modules 432, 434, 436 for controlling the processor 410. Other hardware or software modules are contemplated. The storage device 430 can be connected to the system bus 405. 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 410, bus 405, output device 435 (e.g., a display), and so forth, to carry out the function.

FIG. 4B illustrates a computer system 500 having a chipset architecture that can be used in executing the described method and generating and displaying a graphical user interface (GUI). Computer system 500 is an example of computer hardware, software, and firmware that can be used to implement the disclosed technology. System 500 can include a processor 555, representative of any number of physically and/or logically distinct resources capable of executing software, firmware, and hardware configured to perform identified computations. Processor 555 can communicate with a chipset 560 that can control input to and output from processor 555. In this example, chipset 560 outputs information to output device 565, such as a display, and can read and write information to storage device 570, which can include magnetic media, and solid state media, for example. Chipset 560 can also read data from and write data to RAM 575. A bridge 580 for interfacing with a variety of user interface components 585 can be provided for interfacing with chipset 560. Such user interface components 585 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 500 can come from any of a variety of sources, machine generated and/or human generated.

Chipset 560 can also interface with one or more communication interfaces 590 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 555 analyzing data stored in storage 570 or RAM 575. Further, the machine can receive inputs from a user via user interface components 585 and execute appropriate functions, such as browsing functions by interpreting these inputs using processor 555.

It can be appreciated that example systems 400 and 500 can have more than one processor 410 or be part of a group or cluster of computing devices networked together to provide greater processing capability.

For clarity of explanation, in some instances the present technology can be presented as including individual functional blocks including functional blocks comprising devices, device components, steps or routines in a method embodied in software, or combinations of hardware and software.

In some examples, the computer-readable storage devices, mediums, and memories can include a cable or wireless signal containing a bit stream and the like. However, when mentioned, non-transitory computer-readable storage media expressly exclude media such as energy, carrier signals, electromagnetic waves, and signals per se.

Methods according to the above-described examples can be implemented using computer-executable instructions that are stored or otherwise available from computer readable media. Such instructions can comprise, for example, instructions and data which cause or otherwise configure a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. Portions of computer resources used can be accessible over a network. The computer executable instructions can be, for example, binaries, intermediate format instructions such as assembly language, firmware, or source code. Examples of computer-readable media that can be used to store instructions, information used, and/or information created during methods according to described examples include magnetic or optical disks, flash memory, USB devices provided with non-volatile memory, networked storage devices, and so on.

Devices implementing methods according to these disclosures can comprise hardware, firmware and/or software, and can take any of a variety of form factors. Typical examples of such form factors include laptops, smart phones, small form factor personal computers, personal digital assistants, and so on. Functionality described herein also can be embodied in peripherals or add-in cards. Such functionality can also be implemented on a circuit board among different chips or different processes executing in a single device, by way of further example.

The instructions, media for conveying such instructions, computing resources for executing them, and other structures for supporting such computing resources are means for providing the functions described in these disclosures.

Various aspects of the present technology provide systems and methods for generating a communication graph in a network using a ADM pipeline. While specific examples have been cited above showing how the optional operation can be employed in different instructions, other examples can incorporate the optional operation into different instructions. For clarity of explanation, in some instances the present technology can be presented as including individual functional blocks including functional blocks comprising devices, device components, steps or routines in a method embodied in software, or combinations of hardware and software.

The various examples can be further implemented in a wide variety of operating environments, which in some cases can include one or more server computers, user computers or computing devices which can be used to operate any of a number of applications. User or client devices can include any of a number of general purpose personal computers, such as desktop or laptop computers running a standard operating system, as well as cellular, wireless and handheld devices running mobile software and capable of supporting a number of networking and messaging protocols. Such a system can also include a number of workstations running any of a variety of commercially-available operating systems and other known applications for purposes such as development and database management. These devices can also include other electronic devices, such as dummy terminals, thin-clients, gaming systems and other devices capable of communicating via a network.

To the extent examples, or portions thereof, are implemented in hardware, the present patent application can be implemented with any or a combination of the following technologies: a discrete logic circuit(s) having logic gates for implementing logic functions upon data signals, an application specific integrated circuit (ASIC) having appropriate combinational logic gates, programmable hardware such as a programmable gate array(s) (PGA), a field programmable gate array (FPGA), etc.

Most examples utilize at least one network that would be familiar to those skilled in the art for supporting communications using any of a variety of commercially-available protocols, such as TCP/IP, OSI, FTP, UPnP, NFS, CIFS, AppleTalk etc. The network can be, for example, a local area network, a wide-area network, a virtual private network, the Internet, an intranet, an extranet, a public switched telephone network, an infrared network, a wireless network and any combination thereof.

Methods according to the above-described examples can be implemented using computer-executable instructions that are stored or otherwise available from computer readable media. Such instructions can comprise, for example, instructions and data which cause or otherwise configure a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. Portions of computer resources used can be accessible over a network. The computer executable instructions can be, for example, binaries, intermediate format instructions such as assembly language, firmware, or source code. Examples of computer-readable media that can be used to store instructions, information used, and/or information created during methods according to described examples include magnetic or optical disks, flash memory, USB devices provided with non-volatile memory, networked storage devices, and so on.

Devices implementing methods according to these technology can comprise hardware, firmware and/or software, and can take any of a variety of form factors. Typical examples of such form factors include server computers, laptops, smart phones, small form factor personal computers, personal digital assistants, and so on. Functionality described herein also can be embodied in peripherals or add-in cards. Such functionality can also be implemented on a circuit board among different chips or different processes executing in a single device, by way of further example.

In examples utilizing a Web server, the Web server can run any of a variety of server or mid-tier applications, including HTTP servers, FTP servers, CGI servers, data servers, Java servers and business application servers. The server(s) can also be capable of executing programs or scripts in response requests from user devices, such as by executing one or more Web applications that can be implemented as one or more scripts or programs written in any programming language, such as Java®, C, C# or C++ or any scripting language, such as Perl, Python or TCL, as well as combinations thereof. The server(s) can also include database servers, including without limitation those commercially available from open market.

The server farm can include a variety of data stores and other memory and storage media as discussed above. These can reside in a variety of locations, such as on a storage medium local to (and/or resident in) one or more of the computers or remote from any or all of the computers across the network. In a particular set of examples, the information can reside in a storage-area network (SAN) familiar to those skilled in the art. Similarly, any necessary files for performing the functions attributed to the computers, servers or other network devices can be stored locally and/or remotely, as appropriate. Where a system includes computerized devices, each such device can include hardware elements that can be electrically coupled via a bus, the elements including, for example, at least one central processing unit (CPU), at least one input device (e.g., a mouse, keyboard, controller, touch-sensitive display element or keypad) and at least one output device (e.g., a display device, printer or speaker). Such a system can also include one or more storage devices, such as disk drives, optical storage devices and solid-state storage devices such as random access memory (RAM) or read-only memory (ROM), as well as removable media devices, memory cards, flash cards, etc.

Such devices can also include a computer-readable storage media reader, a communications device (e.g., a modem, a network card (wireless or wired), an infrared computing device) and working memory as described above. The computer-readable storage media reader can be connected with, or configured to receive, a computer-readable storage medium representing remote, local, fixed and/or removable storage devices as well as storage media for temporarily and/or more permanently containing, storing, transmitting and retrieving computer-readable information. The system and various devices also typically will include a number of software applications, modules, services or other elements located within at least one working memory device, including an operating system and application programs such as a client application or Web browser. It should be appreciated that alternate examples can have numerous variations from that described above. For example, customized hardware might also be used and/or particular elements might be implemented in hardware, software (including portable software, such as applets) or both. Further, connection to other computing devices such as network input/output devices can be employed.

Storage media and computer readable media for containing code, or portions of code, can include any appropriate media known or used in the art, including storage media and computing media, such as but not limited to volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage and/or transmission of information such as computer readable instructions, data structures, program modules or other data, including RAM, ROM, EPROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices or any other medium which can be used to store the desired information and which can be accessed by a system device. Based on the technology and teachings provided herein, a person of ordinary skill in the art will appreciate other ways and/or methods to implement the various aspects of the present technology.

The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. It will, however, be evident that various modifications and changes can be made thereunto without departing from the broader spirit and scope of the patent application as set forth in the claims.

Claims

1. A computer-implemented method comprising: collecting network data using a plurality of sensors associated with a plurality of nodes of a network;generating, based upon the network data, a plurality of vectors associated with the plurality of nodes;determining similarities between the plurality of vectors;clustering, based at least upon the similarities, the plurality of vectors into a plurality of clustered vectors;defining a policy based at least upon the plurality of clustered vectors, the policy prohibiting communications between at least two nodes of the plurality of nodes in the network;presenting the policy to a user, via a user interface (UI) including the plurality of clustered vectors, to enable collection of user feedback via input parameters, the input parameters including at least time granularity or clustering granularity in generating the plurality of clustered vectors; andreclustering the plurality of clustered vectors based on the user feedback.

2. The computer-implemented method of claim 1, further comprising: summarizing, at each of the plurality of sensors, collected network data within a predefined time period into network flow and process summaries,wherein the plurality of vectors are generated based at least upon the network flow and process summaries at each of the plurality of sensors.

3. The computer-implemented method of claim 2, wherein the plurality of vectors are generated based at least upon side information, server load balancing (SLB), route tags, or previously generated clustered vectors in the network.

4. The computer-implemented method of claim 1, further comprising: partitioning the plurality of nodes into an external subnet of nodes and an internal subnet of nodes;processing the network data associated with the external subnet of nodes and the internal subnet of nodes; andselecting a subset of the network data in generating the plurality of vectors.

5. The computer-implemented method of claim 4, wherein the processing of the network data includes at least one of steps for feature reduction, term frequency-inverse document frequency, or normalization.

6. The computer-implemented method of claim 1, wherein the presenting of the policy via the UI includes presenting the plurality of clustered vectors, and enabling editing of a specific cluster vector of the plurality of clustered vectors, and modifying or choosing the input parameters to cause the reclustering of the plurality of clustered vectors.

7. The computer-implemented method of claim 1, wherein the input parameters includes the time granularity, the clustering granularity in generating the plurality of clustered vectors, and nodes to be included in an application dependency mapping (ADM) pipeline.

8. The computer-implemented method of claim 6, further comprising: presenting, via the UI, statistics of the plurality of nodes, a summary of one or more nodes in each of the plurality of clustered vectors, and a server port or a client port for each of the plurality of clustered vectors.

9. The computer-implemented method of claim 6, further comprising: presenting, via the UI, a summary of changes to the plurality of clustered vectors in response to one or more modifications to the input parameters; andpresenting a user option to approve the plurality of clustered vectors.

10. The computer-implemented method of claim 1, further comprising: generating a new workspace;selecting nodes/sensors in clustering the plurality of vectors; andenabling the policy.

11. A system comprising: a processor;a user interface (UI); anda computer-readable medium storing instructions that, when executed by the processor, cause the system to perform operations comprising: collecting network data using a plurality of sensors associated with a plurality of nodes of a network;generating, based upon the network data, a plurality of vectors associated with the plurality of nodes;determining similarities between the plurality of vectors;clustering, based at least upon the similarities, the plurality of vectors into a plurality of clustered vectors;defining a policy based at least upon the plurality of clustered vectors, the policy prohibiting communications between at least two nodes of the plurality of nodes in the network;presenting the policy to a user, via the UI including the plurality of clustered vectors, to enable collection of user feedback via input parameters, the input parameters including at least time granularity or clustering granularity in generating the plurality of clustered vectors; andreclustering the plurality of clustered vectors based on the user feedback.

12. The system of claim 11, wherein the instructions, when executed by the processor, cause the system to perform further operations comprising: summarizing, at each of the plurality of sensors, collected network data within a predefined time period into network flow and process summaries,wherein the plurality of vectors are generated based at least upon the network flow and process summaries at each of the plurality of sensors.

13. The system of claim 11, wherein the instructions, when executed by the processor, cause the system to perform further operations comprising: partitioning the plurality of nodes into an external subnet of nodes and an internal subnet of nodes;processing the network data associated with the external subnet of nodes and the internal subnet of nodes; andselecting a subset of the network data in generating the plurality of vectors.

14. The system of claim 13, wherein the processing of the network data includes at least one of steps for feature reduction, term frequency-inverse document frequency, or normalization.

15. The system of claim 11, wherein the presenting of the policy via the UI includes enabling editing of a specific cluster vector of the plurality of clustered vectors, and modifying or choosing input parameters to cause the reclustering of the plurality of clustered vectors.

16. The system of claim 15, wherein the instructions, when executed by the processor, cause the system to perform further operations comprising: presenting, via the UI, statistics of the plurality of nodes, a summary of one or more nodes in each of the plurality of clustered vectors, and a server port or a client port for each of the plurality of clustered vectors.

17. The system of claim 15, wherein the instructions, when executed by the processor, cause the system to perform further operations comprising: presenting, via the UI a summary of changes to the plurality of clustered vectors in response to one or more modifications to the input parameters; andpresenting a user option to approve the plurality of clustered vectors.

18. A non-transitory computer-readable storage medium having stored therein instructions that, upon being executed by a processor, cause the processor to: collect network data using a plurality of sensors associated with a plurality of nodes of a network;generate, based upon the network data, a plurality of vectors associated with the plurality of nodes;determine similarities between the plurality of vectors;cluster, based at least upon the similarities, the plurality of vectors into a plurality of clustered vectors;define a policy based at least upon the plurality of clustered vectors, the policy prohibiting communications between at least two nodes of the plurality of nodes in the network;present the policy to a user, via a user interface (UI) including the plurality of clustered vectors, to enable collection of user feedback via input parameters, the input parameters including at least time granularity or clustering granularity in generating the plurality of clustered vectors; andrecluster the plurality of clustered vectors based on the user feedback.

19. The non-transitory computer-readable storage medium of claim 18, wherein the instructions upon being executed further cause the processor to: summarize, at each of the plurality of sensors, collected network data within a predefined time period into network flow and process summaries;wherein the plurality of vectors are generated based at least upon the network flow and process summaries at each of the plurality of sensors.

20. The non-transitory computer-readable storage medium of claim 18, wherein the instructions upon being executed further cause the processor to: partition the plurality of nodes into an external subnet of nodes and an internal subnet of nodes;process the network data associated with the external subnet of nodes and the internal subnet of nodes; andselect a subset of the network data in generating the plurality of vectors.