CN118282863A - Query mechanism for network management system - Google Patents

Abstract

Embodiments of the present disclosure relate to a query mechanism for a network management system. A system comprising one or more processors configured to: a query is received indicating one or more of filtering information, ordering information, or joining information, and an intent graph of the network is retrieved from a first data store, wherein the intent graph includes nodes representing components of the network and edges representing connections between the components. The one or more processors are further configured to select a subset of the plurality of network devices of the network based on querying the intent figures retrieved from the first data store, and retrieve data received from the plurality of network devices of the network from the second data store. The one or more processors are further configured to determine a response to the query based on the selected subset of the plurality of network devices and the data retrieved from the second data store, and output the response to the query.

Description

Query mechanism for network management system

The present application claims the benefit of U.S. patent application Ser. No. 18/185,326, filed on 3/16/2023, which claims the benefit of U.S. provisional patent application Ser. No. 63/477,712, filed on 29/12/2022, the entire contents of which are incorporated herein by reference.

Technical Field

The present disclosure relates to computer networks, and more particularly, to management of network devices.

Background

A computer network is a collection of interconnected computing devices capable of exchanging data and sharing resources. Various devices operate to facilitate communications between computing devices. For example, a computer network may include routers, switches, gateways, firewalls, and various other devices to provide and facilitate network communications.

These network devices typically include mechanisms for configuring the device, such as a management interface, locally or remotely. By interacting with the management interface, the client may perform configuration tasks and execute operational commands to collect and view operational data of the managed device. For example, a client may configure an interface card of a device, adjust parameters for supported network protocols, specify physical components within the device, modify routing information maintained by a router, access software modules and other resources residing on the device, and perform other configuration tasks. In addition, the client may allow the user to view current operating parameters, system logs, information related to network connectivity, network activity, or other status information from the device, as well as view and react to event information received from the device.

The network configuration service may be performed by a number of different devices, such as routers with service cards and/or dedicated service devices. Such services include connectivity services such as layer three virtual private network (L3 VPN), virtual private local area network services (VPLS), and peer-to-peer (P2P) services. Other services include network configuration services such as Dot1q VLAN services. Network Management Systems (NMS) and NMS devices, also referred to as controllers or controller devices, may support these services so that an administrator (e.g., a network administrator) may easily create and manage these high-level network configuration services.

Disclosure of Invention

In general, this disclosure describes techniques for allowing a network administrator to query metrics (e.g., temperature, interface traffic, transceiver load, transceiver power, etc.) of network devices from multiple databases that may be geographically separated, and filter results based on device attributes (e.g., hardware model number, operating system version, transceiver type) and context (e.g., location of the device in a data center topology or role of the device in routing). In some systems, these metrics are stored in a telemetry database separate from the database(s) of device attributes and context. In an intent-based Network Management System (NMS) such as Juniper Apstra ^TM, the context may be stored in an intent graph database. Thus, as a response to a query, there may be sub-queries to many different databases.

Retrieving and compiling information from many different databases may complicate the response to a query. At the client, such compilation may involve very important processing, such as table joining, ordering, and filtering. A network administrator may need to write additional custom code to perform the custom process. This approach may also require large amounts of data to be transferred from multiple databases, which may result in sub-optimal use of computing power, memory, and network bandwidth. For example, a network administrator may manually "stitch" together data from different databases to monitor the network. For example, a network administrator at a client device (e.g., a laptop or computer) may generate 5 to 10 API calls to request data from different databases to monitor the network. That is, a network administrator may manually retrieve and identify relevant data for monitoring the network. Alternatively, the network administrator may write custom code for each query to perform filtering, ordering, and data coupling operations.

In accordance with the techniques of this disclosure, a system may be configured to provide a query mechanism at a cluster (e.g., a container that implements a network monitoring service for clients) and/or at a cloud-based service. The NMS may be configured to provide a query mechanism to provide a "turn-key" solution that automatically stitches together data from different databases and/or generates a user interface that visualizes stitched data from different databases. In this way, the system may provide query results faster than systems that rely on a network administrator to write additional custom code to perform the customization process, which may reduce the time to diagnose and/or solve network problems in the network. In some examples, automatically stitching together data from different databases may reduce the amount of data to be transferred from multiple databases, which may result in a better use of computing power, memory, and/or network bandwidth, as compared to systems that rely on a network administrator to write additional custom code to perform the customization process. In some examples, the query mechanism may additionally or alternatively discover new patterns for improving causal graphs and/or root cause analysis. In some examples, the query mechanism may additionally or alternatively discover new ways of performing intent-based analysis.

In one example, a system includes one or more processors configured to receive a query indicating one or more of filtering information, ordering information, or joining information, retrieve an intent graph of a network from a first data store, wherein the intent graph includes nodes representing components of the network and edges representing connections between the components, select a subset of a plurality of network devices of the network based on the query and the intent graph retrieved from the first data store, retrieve data received from the plurality of network devices of the network from a second data store, determine a response to the query based on the selected subset of the plurality of network devices and the data retrieved from the second data store, and output the response to the query.

In another example, a method includes receiving a query indicating one or more of filtering information, ordering information, or joining information, retrieving an intent graph of a network from a first data store, wherein the intent graph includes nodes representing components of the network and edges representing connections between the components, selecting a subset of a plurality of network devices of the network based on the query and the intent graph retrieved from the first data store, retrieving data received from the plurality of network devices of the network from a second data store, determining a response to the query based on the selected subset of the plurality of network devices and the data retrieved from the second data store, and outputting the response to the query.

In another example, a computer-readable storage medium is encoded with instructions for causing one or more programmable processors to receive a query indicating one or more of filtering information, ordering information, or joining information, retrieve an intent graph of a network from a first data store, wherein the intent graph includes nodes representing components of the network and edges representing connections between the components, select a subset of a plurality of network devices of the network based on the query and the intent graph retrieved from the first data store, retrieve data received from the plurality of network devices of the network from a second data store, determine a response to the query based on the selected subset of the plurality of network devices and the data retrieved from the second data store, and output the response to the query.

The details of one or more examples are set forth in the accompanying drawings and the description below. Other features, objects, and advantages will be apparent from the description and drawings, and from the claims.

Drawings

Fig. 1 is a block diagram illustrating an example of elements comprising an enterprise network managed using a management device.

FIG. 2 is a block diagram illustrating an example set of components for the management device of FIG. 1.

Fig. 3 is a conceptual diagram illustrating an example database in accordance with the techniques of this disclosure.

Fig. 4 is an example code illustrating a first example use case of generating a histogram in accordance with the techniques of this disclosure.

Fig. 5 is an example code illustrating a second example use case of generating a histogram in accordance with the techniques of this disclosure.

Fig. 6 is an example code illustrating a third example use case of generating a histogram in accordance with the techniques of this disclosure.

Fig. 7 is example code illustrating an example use case for generating pie charts in accordance with the techniques of this disclosure.

Fig. 8 is a block diagram illustrating an example code, e.g., a quarter-bit-distance (interquartile range, IQR) operation, with computations embedded in a query mechanism, in accordance with the techniques of this disclosure.

FIG. 9 is example code illustrating an example query mechanism for linear regression in accordance with the techniques of this disclosure.

FIG. 10 is a flow chart illustrating an example process of a query mechanism accessing multiple databases in accordance with the techniques of this disclosure.

Detailed Description

Fig. 1 is a block diagram illustrating an example of elements comprising an enterprise network 2 managed using a controller device 10. Managed elements 14A-14G (collectively, "elements 14") of enterprise network 2 comprise network devices interconnected via communication links to form a communication topology for exchanging resources and information. Element 14 (also commonly referred to as a network device or remote network device) may include, for example, a router, switch, gateway, bridge, hub, server, firewall or other Intrusion Detection System (IDS) or intrusion prevention system (IDP), computing device, computing terminal, printer, other network device, or a combination of such devices. Although described in this disclosure as sending, delivering, or otherwise supporting packets, enterprise network 2 may send data according to any other discrete data unit defined by any other protocol, such as cells defined by an Asynchronous Transfer Mode (ATM) protocol or datagrams defined by a User Datagram Protocol (UDP). The communication link of the interconnecting element 14 may be a physical link (e.g., an optical link, a copper link, etc.), a wireless link, or any combination thereof.

Enterprise network 2 is shown coupled to a public network 18 (e.g., the internet) via a communication link. Public network 18 may include, for example, one or more client computing devices. Public network 18 may provide access to network servers, application servers, public databases, media servers, end user devices, and other types of network resource devices and content.

Controller device 10 is communicatively coupled to element 14 via enterprise network 2. The controller device 10 may comprise, for example, a cluster of virtual machines. In some examples, the controller device 10 forms part of a device management system, although only one device of the device management system is shown in fig. 1 for purposes of example. The controller device 10 may be directly or indirectly coupled to the various elements 14. Once element 14 is deployed and activated, administrator 12 uses controller device 10 to manage network devices using a device management protocol via client device 11 (e.g., mobile device, laptop, computer, server, etc.). One example device protocol is the Simple Network Management Protocol (SNMP), which allows the controller device 10 to traverse and modify a Management Information Base (MIB) that stores configuration data within each of the managed elements 14. More details of the SNMP protocol can be found below: harrington et al ,RFC 3411,"An Architecture for Describing Simple Network Management Protocol(SNMP)Management Frameworks"(, incorporated herein by reference in its entirety, is used to describe the architecture of a Simple Network Management Protocol (SNMP) management framework), network workgroups, internet engineering task force draft, month 12 in 2002, available at http:// tools.

The controller device 10, also referred to herein as a Network Management System (NMS) or NMS device, and the elements 14 are maintained by an IT group set of the enterprise. Administrator 12 interacts with controller device 10 to remotely monitor and configure elements 14. For example, administrator 12 may receive alarms from controller device 10 regarding any of elements 14, view configuration data of elements 14, modify configuration data of elements 14, add new network devices to enterprise network 2, remove existing network devices from enterprise network 2, or otherwise manipulate enterprise network 2 and network devices therein. Although described with respect to enterprise networks, the techniques of this disclosure are applicable to other network types, both public and private, including LAN, VLAN, VPN, etc.

In some examples, administrator 12 uses controller device 10 or a local workstation to interact directly with element 14, such as through a telnet, secure Shell (SSH), or other such communication session. That is, element 14 generally provides an interface for direct interaction, such as a Command Line Interface (CLI), a web-based interface, a Graphical User Interface (GUI), etc., through which a user can interact with the device to directly issue text-based commands. For example, these interfaces typically allow a user to interact directly with the device, such as through telnet, secure Shell (SSH), hypertext transfer protocol (HTTP), or other network session, to enter text according to a defined syntax to submit commands to managed elements. In some examples, a user initiates an SSH session 15 with one of the elements 14 (e.g., element 14F) using the controller device 10 to directly configure element 14F. In this way, the user can provide commands in a format for execution directly to the element 14.

Furthermore, administrator 12 may also create scripts that may be submitted by controller device 10 to any or all of elements 14 using client device 11. For example, in addition to the CLI interface, element 14 provides an interface for receiving a script that specifies commands according to a scripting language. In a sense, scripts may be output to controller device 10 to automatically invoke corresponding Remote Procedure Calls (RPCs) on managed element 14. The script may conform to, for example, extensible markup language (XML) or another data description language.

Administrator 12 uses controller device 10 and client device 11 to configure element 14 to specify certain operating characteristics that advance the goals of administrator 12. For example, administrator 12 may specify particular operational policies for element 14 regarding security, device accessibility, traffic engineering, quality of service (QoS), network Address Translation (NAT), packet filtering, packet forwarding, rate limiting, or other policies. The controller device 10 uses one or more network management protocols designed for management of configuration data within the managed network element 14, such as the SNMP protocol or the network configuration protocol (netcon f) protocol or a derivative thereof, such as a Juniper device management interface, to perform configuration. In general, netcon provides a mechanism for configuring network devices and uses extensible markup language (XML) based data encoding for configuration data, which may include policy data. Netcon f is described below: enns, "NETCONF Configuration Protocol" (NETCONF configuration protocol), working group for networks, RFC4741, month 12 2006, available at tools. The controller device 10 may establish a netcon f session with one or more of the elements 14.

The user configuration of the device may be referred to as "intent". The intent based network system allows the administrator 12 to describe the network/computing/storage state of intent. User intent may be categorized into business policies and stateless intent. The traffic policy or stateful intent may be parsed based on the current state of the network. Stateless intent may be a fully declarative way of describing the intended network/computing/storage state, regardless of the current network state.

The intent may be represented as an intent data model, which may be modeled using a unified graph. The intent data model may be represented as a connection graph such that business policies may be implemented across the intent data model. For example, the data model may be represented using a connection graph with vertices connected using has-edges and reference (ref) edges. The controller device may model the intent data model as a unified graph such that the intent model may be represented as connected. In this way, business policies can be implemented across the intent data model. When modeling intent using a unified graph model, expanding new intent support requires expanding the graph model and assembly logic.

The controller device 10 may be configured to accept high-level configuration data or intent from an administrator 12 (which may be represented as structured input parameters, e.g., according to YANG, which is described below as Bjorklund, "YANG-A Data Modeling Language for the Network Configuration Protocol (NETCONF)" (YANG-data modeling language for network configuration protocol (NETCONF)), internet engineering task force, RFC6020, month 10 2010, available at tools.ietf.org/html/RFC 6020.

To configure a device to execute intent, a user (such as an administrator) may write a translation program that translates high-level configuration instructions (e.g., instructions according to an intent data model, which may be represented as a unified graph model) into low-level configuration instructions (e.g., instructions according to a device configuration model). As part of configuration service support, administrator 12 may provide an intent data model and a mapping between the intent data model to a device configuration model.

The controller device 10 may also be configured to output corresponding low-level device configuration data sets, such as device configuration additions, modifications, and removals. Additional details regarding example processes for translating high-level configuration information into low-level device configuration information may be found below: for example, jiang et al, "TRANSLATING HIGH-LEVEL CONFIGURATION INSTRUCTIONS TO LOW-LEVEL DEVICE CONFIGURATION" (translating high-level CONFIGURATION instructions to low-level device CONFIGURATION), U.S. patent application Ser. No. 15/198,657, filed on even 30/6 in 2016, the entire contents of which are incorporated herein by reference. The present disclosure refers to low-level device configurations (e.g., generated by compiling or translating intents) generated from intent as "device-level intent configuration information" or "intent configuration" to distinguish the device-level configuration from out of band (OOB) device-level configurations. In some examples, the controller device 10 may use yac modeling for the intent data model and the low level device configuration model. This data may contain relationships between YANG entities, such as list items and containers. In some examples, the controller device 10 may convert the YANG data model to a database model and convert the YANG verification to a data verification. Techniques for managing network devices using a graph model of high-level configuration data are described below: "CONFIGURING AND MANAGING NETWORK DEVICES USING PROGRAM OVERLAY ON YANG-BASED GRAPH DATABASE" (using program overlays on a YANG-based graph database to configure and manage network devices), U.S. patent application Ser. No. 15/462,465, filed on 17.3.2017, the entire contents of which are incorporated herein by reference.

Controller device 10 may receive data representing the creation, updating, and/or deletion actions with respect to any or all of the intent data models from one of administrators 12. The controller device 10 may be configured to use the same assembly logic as applied to each of creation, update, and deletion of the graph model.

In general, controllers like the controller device 10 may use hierarchical data models for intent, low-level data models, and resources. The hierarchical data model may be based on yacng or YAML. The hierarchical data model may be represented as a graph, as described above. The intended use may simplify the management of the network and is intended to be descriptive. To achieve this, the controller device 10 may attempt to select the best resource from the element 14 and/or from other devices.

In general, the controller device 10 may be configured to convert a high-level configuration (e.g., intent received from an administrator for a plurality of managed network devices) to a low-level configuration, which may also be referred to herein as a "device-level configuration" (to be applied to the managed network devices themselves). In some cases, controller device 10 may receive an indication of the topology and roles of element 14A and generate device level configuration information for element 14A. For example, administrator 12 may select the topology and roles of elements 14A and provide intent. In some examples, controller device 10 may generate a device-level configuration of element 14A based on the role (e.g., trunk or leaf), topology, and intent of element 14A in the topology (e.g., trunk and She Tapu).

In accordance with the techniques of this disclosure, controller device 10 may be configured to receive a query indicating one or more of filtering information, ordering information, or joining information. For example, the controller device 10 may receive an API request from the client device 11. The filtering information may include, for example, one or more of a vendor, model, interface, system, or timeframe. The linking information may include, for example, grouping by model, grouping by system, grouping by vendor, grouping by interface. The ordering information may include, for example, ordering by vendor or ordering by count.

The controller device 10 may retrieve an intent graph for the network from the first data store 13. The intent graph may include nodes representing components of the network and edges representing connections between the components. The controller device 10 may select a subset of the network devices 14 based on the query and the intent figures retrieved from the first data store 13. For example, the controller device 10 may select the network device 14A, 14B in response to determining that the intent map indicates that the network device 14A, 14B supports the network service indicated by the query. Examples of the first data store 13 may include an intent graph database or a graph index database.

The controller device 10 may retrieve data received from a plurality of network devices of the network from the second data store 15. The controller device 10 may determine a response to the query based on the selected subset of the plurality of network devices and the data retrieved from the second data store 15. Examples of the second data store 15 may include one or more of a Root Cause Identification (RCI) database, a computational telemetry database, an original telemetry database, an intent-based analysis detection level output database, an intent-based detection anomaly database, or a device-level anomaly database. In some examples, the second data store 15 may additionally or alternatively include one or more of a cluster health telemetry database, an audit event log database, a blueprint API, or a mutation API database. For example, the controller device 10 may access one or more databases to retrieve the calculated telemetry and/or raw telemetry of the network devices 14A, 14B.

The controller device 10 may output a response to the query. For example, the controller device 10 may output a histogram to the client device 11 indicating the calculated telemetry and/or the original telemetry of the network devices 14A, 14B. The controller device 10 may be implemented by a system (e.g., a network management system) that provides a query mechanism at a cluster (e.g., a container that implements a network monitoring service for clients) and/or at a cloud-based service. In this manner, the controller device 10 and/or the network management system may be configured to provide a "key-in" solution that automatically stitches together data from different databases and/or generates a user interface that visualizes stitched data from different databases. In some examples, the controller device 10 and/or the network management system may be configured to discover new patterns for improving causal graphs and/or root cause analysis. The controller device 10 and/or the network management system may be configured to discover new ways of performing intent-based analysis.

Fig. 2 is a block diagram illustrating an example set of components of the controller device 10 of fig. 1. In this example, the controller device 10 includes a control unit 22, a network interface 34, and a user interface 36. Network interface 34 represents an example interface that may communicatively couple controller device 10 to an external device (e.g., one of elements 14 of fig. 1). The network interface 34 may represent a wireless and/or wired interface, such as an ethernet interface or a wireless radio configured to communicate in accordance with a wireless standard, such as one or more of the IEEE 802.11 wireless network protocols (such as 802.11a/b/g/n or other such wireless protocols). In various examples, the controller device 10 may include multiple network interfaces, although only one is shown for purposes of example.

The control unit 22 represents any combination of hardware, software, and/or firmware for implementing the functions attributed to the control unit 22 and its constituent modules and elements. When the control unit 22 comprises software or firmware, the control unit 22 also comprises any necessary hardware, such as one or more processors or processing units, for storing and executing the software or firmware. In general, a processing unit may include one or more microprocessors, digital Signal Processors (DSPs), application Specific Integrated Circuits (ASICs), field programmable gate arrays (FGAs), or any other equivalent integrated or discrete logic circuits, as well as any combination of such components. Furthermore, the processing units are typically implemented using fixed and/or programmable logic circuits.

User interface 36 represents one or more interfaces through which a user, such as administrator 12 (fig. 1), interacts with controller device 10, for example, to provide input and receive output. For example, the user interface 36 may represent one or more of a monitor, keyboard, mouse, touch screen, touch pad, track pad, speaker, camera, microphone, and the like. Furthermore, although in this example controller device 10 includes a user interface, it should be understood that administrator 12 need not interact directly with controller device 10, but rather may access controller device 10 remotely, for example, via network interface 34.

In this example, the control unit 22 includes a user interface module 38, a network interface module 32, and a management module 24. The control unit 22 executes the user interface module 38 to receive input from the user interface 36 and/or to provide output to the user interface 36. The control unit 22 also executes a network interface module 32 to send and receive data (e.g., packets) via a network interface 34. Also, the user interface module 38, the network interface module 32, and the management module 24 may be implemented as respective hardware units, or as software or firmware, or as a combination thereof.

The control unit 22 executes a management module 24 to manage various network devices, such as the elements 14 of fig. 1. Management includes, for example, configuring a network device according to instructions received from a user (e.g., administrator 12 of fig. 1), and providing the user with the ability to submit instructions to configure the network device. In this example, the management module 24 also includes a configuration module 26 and a translation module 28.

Management module 24 is configured to receive intents (e.g., high-level configuration instructions) for a set of managed network devices from a user, such as administrator 12. In some examples, management module 24 may be referred to herein as a "fabric manager". Over time, the user may update the configuration instructions, for example, to add new services, remove existing services, or modify existing services performed by the managed device. The intent may be constructed from, for example, YANG. In some examples, the management module 24 also provides the user with the ability to submit translation functions that the translation module 28 executes to translate intent into low-level configuration instructions that are specific to the device, as described below.

The controller device 10 further comprises a configuration database 40. Configuration database 40 may include data structures describing managed network devices (e.g., network elements 14). Configuration database 40 may be used as an intent data store, which may be used to persist and manage a collection of intent data models. For example, the configuration database 40 may include information indicating a device identifier (such as a MAC and/or IP address), a device type, a device vendor, or a device class (e.g., router, switch, bridge, hub, etc.). Configuration database 40 may store current configuration information (e.g., an intent data model, or in some cases, both an intent data model and low-level configuration information) for managed devices (e.g., network elements 14). Configuration database 40 may include a database containing a unified intent data model.

Management module 24 may maintain one or more data structures of device configurations derived from stateful intents. For example, management module 24 may maintain a data structure in configuration database 40. The data structure may include a plurality of vertices and a plurality of edges, each vertex of the plurality of vertices representing a respective network device of the plurality of network devices (e.g., network element 14) or a respective intent of the plurality of stateless intents, and the plurality of edges defining a relationship between the plurality of vertices. The management module 24 may receive an indication of a stateful intent. For example, management module 24 may receive intent unified graph modeling configuration data for a set of managed network devices from a user, such as administrator 12.

The translation module 28, which may also be referred to herein as a "device manager," may use the configuration database 40 to determine which devices are managed. The translation module 28 determines which translation functions 30 to perform on the high level configuration instructions, e.g., which devices will receive the low level configuration instructions, based on the information of the configuration database 40. The translation module 28 then performs each of the determined translation functions of the translation function 30, providing high level configuration instructions as input to the translation function, and receiving low level configuration instructions. Translation module 28 may then provide low level configuration instructions to configuration module 26.

Upon receiving low-level configuration instructions (e.g., device-level configuration instructions) from translation module 28, configuration module 26 may send the low-level configuration instructions to the respective managed network devices for which the configuration is to be updated via network interface module 32. The network interface module 32 communicates low-level configuration instructions to the network interface 34. The network interface 34 forwards the low level configuration instructions to the corresponding network device.

Although user interface 36 is described for purposes of example as allowing administrator 12 (FIG. 1) to interact with controller device 10, other interfaces may be used in other examples. For example, controller device 10 may include a representational state transfer (REST) client (not shown) that may serve as an interface to another device through which administrator 12 may configure controller device 10. Likewise, administrator 12 may configure element 14 by interacting with controller device 10 via a REST client.

In accordance with the techniques of this disclosure, query module 37 may be configured to receive a query indicating one or more of filtering information, ranking information, or joining information. For example, the network interface 34 may receive an API request from the client device 11. The query module 37 may retrieve an intent map of the network from the first data store 13. The intent graph may include nodes representing components of the network and edges representing connections between the components.

The query module 37 may select a subset of the network devices 14 based on the query and the intent figures retrieved from the first data store 13. For example, query module 37 may select the subset network devices in response to determining that the intent map indicates that the subset network devices support the network service indicated by the query.

The query module 37 may retrieve data received from a plurality of network devices of the network from the second data store 15. The query module 37 may determine a response to the query based on the selected subset of the plurality of network devices and the data retrieved from the second data store 15. For example, the query module 37 may access one or more databases to retrieve the calculations and/or raw telemetry of the network devices 14A, 14B. The controller device 10 may output an indication of the response to the query. For example, a query module 37 with a network interface 34 may output a histogram to the client device 11 indicating the computation and/or original telemetry of the network devices 14A, 14B. Although shown as a single device, the controller device 10 may be implemented by a system (e.g., a network management system) that provides a query mechanism at a cluster (e.g., a container that implements a network monitoring service for clients) and/or at a cloud-based service. In this manner, the controller device 10 and/or the network management system may be configured to provide a "key-in" solution that automatically stitches together data from different databases and/or generates a user interface that visualizes stitched data from different databases. In some examples, the controller device 10 and/or the network management system may be configured to discover new patterns for improving causal graphs and/or root cause analysis. The controller device 10 and/or the network management system may be configured to discover new ways of performing intent-based analysis.

Fig. 3 is a conceptual diagram illustrating an example database in accordance with the techniques of this disclosure. For example, the controller device 10 or network management system may be configured to access the various databases and logs shown in fig. 3.

In the example of fig. 3, the controller device 10 may access a database related to a graph model of the network. For example, the controller device 10 may access the intent graph database 204, the intent graph database 204 configured to store the current state of the intent graph model and one or more previous versions of the intent graph model. The controller device 10 may access a graph index database 202, the graph index database 202 including index data mapped to corresponding intent graphs stored in the intent graph database. In some examples, the controller device 10 may be configured to access a Root Cause Identification (RCI) database 206, which database 206 may store Root Cause Failures (RCFs) for identifying network failures, causal graphs for determining the causes of network failures, and/or impact maps identifying affected network devices and/or services of network failures. Controller device 10 may access a computational telemetry database 208 (e.g., for optical transceiver baseline values) and/or a raw telemetry database 214. In some examples, the controller device 10 may access an intent-based analysis detection level output database 210 (e.g., that identifies hot interfaces on a network), an intent-based detection anomaly 212, and/or a device-level anomaly database 216.

In addition, the controller device 10 may access a database storing logs. For example, the controller device 10 may access Apstra cluster health telemetry database 220 that stores health information related to the host container in which the controller device 10 is implemented. For example, apstra cluster health telemetry database 220 may store CPU utilization, memory utilization, file system utilization, when a process is restarted, and/or when a container is restarted. The controller device 10 may access an audit event log database 224, the database 224 storing, for example, when a user logs in or out, when a user deletes or creates an intent graph model (e.g., blueprint), deployments changes to device configuration, and/or failed logins. The controller device 10 may access a blueprint API mutation task database 226 that stores information for requests to change the intent graph model, and/or a mutation API log database 222 that stores information regarding changes to resource pools and/or changes to clusters, operations to add and/or remove design catalog elements, and/or update cryptographic operations.

The data stored by the various databases of fig. 3 may not be well-formatted. Consider, for example, a query for an optical transceiver operating temperature threshold for a ridge device in a data center. In this example, the controller device 10 may first determine a device serial number assigned to a spine ("spin") device from the intent pattern model of the intent pattern database 204. Assume that there are 3 ridge devices with serial numbers sn1, sn2, and sn3, respectively. The controller device 10 may then use the serial number as an index to calculate the telemetry database 208 to obtain an optical transceiver temperature threshold that may be stored on a per device basis. However, the computational telemetry database 208 may not have sn3 data. In this example, the intent pattern model of intent pattern database 204 may report that a ridge device with a sequence number of sn3 is present in the network for the queried time period, but computing telemetry database 208 may report that there is no optical transceiver temperature threshold data for sn3 for that same time period. Thus, the controller device 10 may automatically "stitch" the data from the intent pattern database 204 and the compute telemetry database 208 to determine that sn1 and sn2 are present in the network and that optical transceiver telemetry is properly collected and computed, while telemetry data for sn3 is not yet available in the compute telemetry database 208, possibly due to telemetry collection failure, the lack of an optical transceiver on the device, communication problems with the device, and so forth.

Fig. 4 is example code 240 illustrating a first example use case of generating a histogram in accordance with the techniques of this disclosure. In this example, network administrator 12 may use code 240 to identify a table that displays a respective temperature for each system and interface name ("ifc") combination. Administrator 12 uses code 240 to identify the IBA probe "probe. Ibannit. Optical" and the stage "stage-2min-avg" that outputs a two minute temperature average. Administrator 12 may filter the results to vendor "juniper" and interface with transceiver model "QSFP-abc".

In this example, the controller device 10 or NMS (e.g., cluster or cloud-based service) may access the intent diagram database 204 to identify a serial number of a network device having a vendor "juniper" and a model "QSFP-abc" interface with the transceiver. In this way, the controller device 10 or NMS may select a subset of network devices and a subset of interfaces for each device in the network (e.g., network devices with vendor "juniper" and transceiver model "QSFP-abc") based on the filtering information. In this example, the controller device 10 or NMS may access the IBA detection-level output database 210 to determine the temperature of the interface identified in the network device having the identified serial number. For example, the controller device 10 or NMS may determine the response 242 to the query based on a selected subset of network devices (e.g., identified by a serial number) and a selected subset of interfaces of each device (e.g., identified by a transceiver model number) and data stored in the IBA detection level output database 210. In the example of fig. 4, the controller device 10 or NMS may apply one or more functions (e.g., an averaging function or, more specifically, a2 minute averaging function) to the data retrieved from the second data store to generate a response to the query.

The query mechanism example of fig. 4 may reduce the number of steps performed by the client device 11 (e.g., a laptop computer or computer used by a network administrator) from 4 to 1 (e.g., a single application programming interface request). For example, without a query mechanism, administrator 12 would make 1 API call to intent graph database 204 to identify the serial number of the device of provider "juniper" and the interface of each such network device with transceiver model "QSFP-abc," make 1 API call to IBA probe level output database 210 to determine the temperature of these interfaces, manually filter interfaces that do not have transceiver model "QSFP-abc," and finally concatenate all of the above data into a single table.

Fig. 5 is an example code 250 illustrating a second example use case of generating a histogram in accordance with the techniques of this disclosure. In this example, administrator 12 may provide code 250 to cause controller device 10 or the NMS to create table 252, which table 252 displays for each transceiver model number on each system (device serial number) the 2 minute average temperature of the interface with that transceiver model number. Administrator 12 may provide code 250 to cause controller device 10 or NMS to identify IBA probe "probe. Ibannit. Optical" and output a level of two minute temperature average "stage-2min-avg" for the interface transceiver. Administrator 12 may provide code 250 to cause controller device 10 or NMS to filter the results to suppliers "juniper" and temperatures below 64 degrees and above 68 degrees ("temp <64 or temp > 68"). Administrator 12 provides code 250 to cause controller device 10 or the NMS to group rows by transceiver model and order the groups in ascending order of transceiver model.

In this example, the controller device 10 or NMS may access the intent diagram database 204 to identify a serial number of a device having a provider "juniper". In this example, the controller device 10 or NMS may access the IBA detection-level output database 210 to determine the temperature of the interface of the identified serial number and filter out temperatures between 64 degrees and 68 degrees. In this example, the controller device 10 or NMS may generate the table 252 to group by model.

Fig. 6 is an example code illustrating a third example use case of generating a histogram in accordance with the techniques of this disclosure. In this example, the controller device 10 or NMS may identify a table 262, which table 262 displays the corresponding temperature for each system, interface name ("ifc") and model number combination. The administrator 12 may use code 260 to cause the controller device 10 or NMS to identify IBA probe "metric b.bp_id.optical" and to output a level of two minute temperature average "stage-2min-avg" for the interface transceiver. Administrator 12 may use code 260 to cause controller device 10 or the NMS to filter the results to a time range ("between 2022-08-20t05:00:00d to 2022-08-27t 05:00:00"). Administrator 12 may also use code 260 to cause controller device 10 or the NMS to filter the results to suppliers "juniper" and model number ("QSFP-abc"). Administrator 12 may use code 260 to cause controller device 10 or the NMS to identify the group according to the model function "system by system, ifc grouping".

In this example, the controller device 10 or NMS may access the intent diagram database 204 to identify a serial number of a device having a vendor "juniper" and an interface with the transceiver model "QSFP-abc". In this example, the controller device 10 or NMS may access the IBA detection level output database 210 to determine an average of two minutes of average temperatures for the identified interfaces of the time ranges 2022-08-20T05:00:00-2022-08-27T 05:00:00. In this example, the controller device 10 or NMS may generate a table 262 to group by system and ifc.

Fig. 7 is example code illustrating an example use case for generating pie charts in accordance with the techniques of this disclosure. Although the examples of fig. 4-6 are directed to histograms, the techniques for the query mechanism may be directed to other data formats, such as pie charts or scatter charts as shown in fig. 7. In this example, administrator 12 may provide code 270 indicating a supplier, model, count, low temperature alarm, and high temperature alarm, and controller device 10 or NMS may generate table 272.

FIG. 8 is an example code showing an example of a computation with embedded in a query mechanism, such as an quarter-bit-distance (IQR) operation, in accordance with the techniques of this disclosure. In this example, administrator 12 may provide code 280 to cause controller device 10 or NMS to identify a table 282, which table 282 displays for each transceiver vendor and model combination a corresponding 25 percentile temperature, 50 percentile temperature (e.g., median temperature), 75 percentile temperature, lowest temperature, and highest temperature. Administrator 12 may provide code 280 to identify a quartile range IBA probe "probe.

In this example, the controller device 10 or NMS may access the intent diagram database 204 to identify interfaces and network devices hosting them. In this example, the controller device 10 or NMS may access the IBA detection level output database 210 to determine the temperature. In this example, the controller device 10 or NMS may calculate the IQR output (e.g., percentile value) to generate the table 282. In this example, by referring to the results of the query, administrator 12 may set the temperature range of 60 degrees to 67 degrees (e.g., 25 percentile to 75 percentile) to an acceptable operating range for interfacing with suppliers "juniper" and model "QSFP-111". In the example of fig. 8, the controller device 10 or NMS may apply one or more functions (e.g., a quarter-bit distance function) to the data retrieved from the second data store to generate a response to the query.

FIG. 9 is example code 290 illustrating an example query mechanism for linear regression in accordance with the techniques of this disclosure. When code 290 is executed by controller device 10 or the NMS, code 290 may perform multi-step calculations on the temperature of the transceiver generated by "Juniper" or "Arista".

The example query of fig. 9 may estimate the temperature trend, e.g., how average temperature changes over time, of transceivers produced by different suppliers (Juniper and Arista). The estimate of fig. 9 is a linear straight line defined by the gradient and y-intercept. The y-value is the average temperature and the x-value is the time stamp. To derive the estimate, the controller device 10 or NMS may perform a number of steps using the query.

First, the controller device 10 or NMS may access the original device telemetry database 214 to determine a two minute average temperature for each interface of the time ranges 2022-08-20T05:00:00 and 2022-08-27T 05:00:00. This will result in K time sequences, where K is the number of interfaces. Each time series may include N samples. Assume that IBA probing is configured to calculate a new average value for the transceiver per minute. In this example, the query time period is 2 days (i.e., 2880 minutes). Thus, n=2880.

Second, the controller device 10 or NMS may traverse each element over multiple time sequences grouped by vendor. It is assumed that of the K time sequences, J time sequences are used for interfaces whose transceivers are produced by Juniper. The controller device 10 or NMS may take the 1 st sample from all J time sequences and calculate IQR among those J samples. The 50 percentile value of IQR is sample 1 of the output sequence. The controller device 10 or NMS may take the 2 nd sample from each of the J time sequences, calculate the IQR, and take the 50 percentile value as the 2 nd sample in the output sequence, and so on until all 2880 samples have been processed. The result is an output sequence of 2880 samples of the Juniper ^TM transceiver. The controller device 10 or NMS may repeat the same process for the K-J time sequences remaining in step 1, which are used for interfacing with the Arista ^TM transceiver. In this way, the controller device 10 or NMS may generate the 2 nd output time series with 2880 samples.

Third, the controller device 10 or NMS may acquire 2 time sequences from the previous step. For each time series, the controller device 10 or NMS may perform linear regression on 2880 samples. The output of the linear regression is the gradient, intercept and confidence interval. Thus, the controller device 10 or NMS may generate the table 292 to include 2 rows, each time series of 1 row (e.g., corresponding to transceiver suppliers Juniper and Arista, respectively).

In this way, the controller device 10 may provide functionality that enables a network administrator to run automatically performed multi-step queries to stitch together data from different databases using a cluster or cloud-based service. For example, a network administrator may perform the query operations shown in fig. 4 through 9 using simple functions. Further, controller device 10 may present a user interface to the administrator that displays relevant metrics derived from the stitching data and/or the original stitching data itself. In this way, controller device 10 may enable an administrator to view metrics from different databases, which may help reduce the amount of time a network administrator views metrics in response to network events.

FIG. 10 is a flow chart illustrating an example process of a query mechanism accessing multiple databases in accordance with the techniques of this disclosure. The network management system or another system may include a first data store 13 (e.g., an intent graph database 204) that stores an indication of the intent graph of the network. The intent graph may include nodes representing components of the network and edges representing connections between the components. The first data store 13 may include an intent graph database or a graph index database.

The network management system or another system may include a second data store 15 (e.g., one or more of databases 206-226) that stores data received from a set of network devices of the network (304). The second data store 15 may include one or more of a Root Cause Identification (RCI) database, a computational telemetry database, a raw telemetry database, an intent-based analysis probe-level output database, an intent-based probe anomaly database, or a device-level anomaly database. In some examples, the second data store 15 may additionally or alternatively include one or more of a cluster health telemetry database, an audit event log database, a blueprint Application Programming Interface (API), or a mutation API database.

The controller device 10 (or network management system) may receive a query indicating one or more of filtering information, ordering information, or joining information (302). The filtering information may include one or more of vendor, model, interface, system, or time frame information. For example, client device 11 may be configured to output a query based on user input (e.g., of administrator 12). The controller device 10 may receive a query from the client device 11 as a single Application Programming Interface (API) request.

The controller device 10 may retrieve an intent map of the network from the first data store 13 (304). For example, the controller device 10 may output a request for an intent graph from the first data store 13 prior to or in response to receiving a query.

The controller device 10 (or network management system) may select a subset of the plurality of network devices of the network based on the query and intent map retrieved from the first data store 13 (306). For example, the controller device 10 may select the network device 14A, 14B in response to determining that the intent map indicates that the network device 14A, 14B supports the network service indicated by the query.

The controller device 10 may retrieve data received from a plurality of network devices of the network from the second data store 15 (308). For example, the controller device 10 may access or request data from one or more of the databases 206-226 and/or other databases.

The controller device 10 (or network management system) may determine a response to the query based on the selected subset of the plurality of network devices and the data retrieved from the second data store 15 (310). For example, the controller device 10 may convert data retrieved from the second data store 15 from the format of the second data store 15 to the format specified in the query. For example, when the format specified in the query includes a histogram format, the controller device 10 may convert the data retrieved from the second data store 15 from the format of the second data store 15 to a histogram format. In some examples, the controller device 10 may convert the data retrieved from the second data store 15 from a first temperature unit (e.g., in degrees celsius or in degrees fahrenheit) to a second temperature unit (e.g., in degrees fahrenheit or in degrees celsius). In some examples, the controller device 10 may apply one or more functions to the data retrieved from the second data store 15 to generate a response to the query. The one or more functions may include one or more of an averaging function, a quartile range function, or a linear regression function.

The controller device 10 may determine a response to the query based on data retrieved from a second data store that includes one or more databases or databases (e.g., one or more (or two or more) of the databases 206-226). For example, the controller device 10 may output a first request for data to a first database of the second data store 215 and a second request for data to a second database of the second data store 215. For example, the first database may be located in a different rack, data center, office, and/or geographic area than the second database. In some cases, the first database may be configured with a different protocol, standard, or programming language than the second database. In this manner, controller device 10 may perform operations to receive data stored by different databases than administrator 12 and/or client device 11, which may reduce the amount of time administrator 12 spends configuring queries and/or may reduce the amount of data sent/received by client device 11.

The controller device 10 (or network management system) may output a response to the query (312). For example, the controller device 10 or the client device 11 may generate data representing a user interface presenting a response to a query, and output the data representing the user interface. In some examples, controller device 10 may receive a query from client device 11, and controller device 10 may be configured to output a response to the query to client device 11.

For example, the controller device 10 may determine a set of device serial numbers assigned to a subset of the plurality of network devices using the intent figures retrieved from the first data store 13 (e.g., the graph index database 202 and/or the intent figures database 204). In this example, the controller device 10 may determine a response to the query based on the set of device serial numbers. For example, the controller device 10 may use the device serial number set as an index to the second data store 15 to access data stored by the second data store 15. In some examples, the controller device 10 may determine that the second data store 15 does not include data for device serial numbers assigned to network devices in a subset of the plurality of network devices. In response to determining that the second data store 15 does not include data for the device serial number assigned to the network device, the controller device 10 may determine that the second data store 15 lacks data for the network device. In this example, the controller device 10 may instruct the second data store 15 to lack data for the network device.

The techniques described in this disclosure may be implemented, at least in part, in hardware, software, firmware, or any combination thereof. For example, aspects of the described techniques may be implemented within one or more processors, including one or more microprocessors, digital Signal Processors (DSPs), application Specific Integrated Circuits (ASICs), field programmable gate arrays (FGAs), or any other equivalent integrated or discrete logic circuitry, as well as any combinations of these components. The term "processor" or "processing circuit" may generally refer to any of the foregoing logic circuits, alone or in combination with other logic circuits, or any other equivalent circuit. A control unit comprising hardware may also perform one or more techniques of this disclosure.

Such hardware, software, and firmware may be implemented within the same device or within separate devices to support the various operations and functions described in this disclosure. Furthermore, any of the described units, modules, or components may be implemented together or separately as discrete but interoperable logic devices. Depiction of different features as modules or units is intended to highlight different functional aspects and does not necessarily imply that such modules or units must be realized by separate hardware or software components. Rather, functionality associated with one or more modules or units may be performed by separate hardware or software components or integrated within common or separate hardware or software components.

The techniques described in this disclosure may also be embodied or encoded in a computer-readable medium (such as a computer-readable storage medium) containing instructions. Instructions embedded or encoded in a computer-readable medium may cause a programmable processor or other processor to perform the method, for example, when the instructions are executed. Computer readable media may include non-transitory computer readable storage media and transitory communication media. The tangible and non-transitory computer-readable storage medium may include Random Access Memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, a hard disk, a CD-ROM, a floppy disk, a cartridge, magnetic media, optical media, or other computer-readable storage media. The term "computer-readable storage medium" refers to physical storage media, rather than signals, carrier waves, or other transitory media.

Various examples have been described. These and other examples are within the scope of the following claims.

Claims (20)

1. A system comprising one or more processors configured to:

receiving a query indicating one or more of filtering information, ranking information, or joining information;

Retrieving an intent graph for a network from a first data store, wherein the intent graph includes nodes representing components of the network and edges representing connections between the components;

Selecting a subset of a plurality of network devices of the network based on the query and the intent graph retrieved from the first data store;

retrieving data received from the plurality of network devices of the network from a second data store;

determining a response to the query based on the selected subset of the plurality of network devices and the data retrieved from the second data store; and

Outputting the response to the query.

2. The system of claim 1, wherein the filtering information comprises one or more of: a vendor, model, interface, system, or timeframe.

3. The system of claim 1, further comprising a client device configured to output the query based on user input.

4. The system according to claim 1,

Wherein to receive the query, the one or more processors are configured to receive the query from a client device; and

Wherein to output the indication of the response to the query, the one or more processors are configured to output the indication of the response to the query to the client device.

5. The system of claim 1, wherein to receive the query, the one or more processors are configured to receive the query from a client device as a single application programming interface, API, request.

6. The system of claim 1, wherein to determine the response to the query, the one or more processors are configured to convert the data retrieved from the second data store from a format of the second data store to a format specified in the query.

7. The system according to claim 6,

Wherein the format specified in the query comprises a histogram format; and

Wherein to determine a response to the query, the one or more processors are configured to convert the data retrieved from the second data store from the format of the second data store to the histogram format.

8. The system of any of claims 1 to 7, wherein to determine the response to the query, the one or more processors are configured to apply one or more functions to the data retrieved from the second data store to generate the response to the query.

9. The system of claim 8, wherein the one or more functions comprise one or more of an average function, a quartile range function, or a linear regression function.

10. The system according to claim 1,

Wherein to select the subset of the plurality of network devices, the one or more processors are configured to determine a set of device sequence numbers assigned to the subset of the plurality of network devices using the intent graph retrieved from the first data store;

wherein the one or more processors are configured to determine the response to the query based on the set of device serial numbers.

11. The system of claim 10, wherein to determine the response to the query based on the set of device sequence numbers, the one or more processors are configured to use the set of device sequence numbers as an index to the second data store to retrieve the data from the second data store.

12. The system of claim 10, wherein the one or more processors are configured to:

Determining that the second data store does not include data for device serial numbers assigned to network devices of the subset of the plurality of network devices;

In response to determining that the second data store does not include data for the device serial number assigned to the network device, determining that the second data store lacks data for the network device; and

Wherein to output the indication of the response to the query, the one or more processors are configured to indicate that the second data store lacks data for the network device.

13. The system of claim 1, wherein the first data store comprises one or more of an intent graph database or a graph index database.

14. The system of claim 1, wherein the second data store comprises one or more of: the root cause identifies an RCI database, a computational telemetry database, a raw telemetry database, an intent-based analysis probe-level output database, an intent-based probe anomaly database, or a device-level anomaly database.

15. The system of claim 1, wherein the second data store comprises one or more of: cluster health telemetry database, audit event log database, blueprint application programming interface API or mutation API database.

16. A method, comprising:

Receiving, by one or more processors, a query indicating one or more of filtering information, ranking information, or joining information;

Retrieving, by the one or more processors, an intent graph for a network from a first data store, wherein the intent graph includes nodes representing components of the network and edges representing connections between the components;

Selecting, by the one or more processors, a subset of a plurality of network devices of the network based on the query and the intent graph retrieved from the first data store;

retrieving, by the one or more processors, data received from the plurality of network devices of the network from a second data store;

determining, by the one or more processors, a response to the query based on the selected subset of the plurality of network devices and the data retrieved from the second data store; and

Outputting, by the one or more processors, the response to the query.

17. The method of claim 16, wherein the filtering information comprises one or more of: a vendor, model, interface, system, or timeframe.

18. The method of claim 16, wherein the client device is configured to output the query based on user input.

19. The method according to any one of claim 16 to 18,

Wherein receiving the query comprises: receiving the query from a client device; and

Wherein outputting the indication of the response to the query comprises: the indication of the response to the query is output to the client device.

20. A computer readable storage medium encoded with instructions for causing one or more programmable processors to perform the method performed by the system of any of claims 1-15.