WO2024030588A1 - Systèmes et procédés pour de meilleures caractéristiques de surveillance pour une topologie de réseau et interfaces utilisateur correspondantes - Google Patents

Systèmes et procédés pour de meilleures caractéristiques de surveillance pour une topologie de réseau et interfaces utilisateur correspondantes Download PDF

Info

Publication number
WO2024030588A1
WO2024030588A1 PCT/US2023/029447 US2023029447W WO2024030588A1 WO 2024030588 A1 WO2024030588 A1 WO 2024030588A1 US 2023029447 W US2023029447 W US 2023029447W WO 2024030588 A1 WO2024030588 A1 WO 2024030588A1
Authority
WO
WIPO (PCT)
Prior art keywords
anomaly
network traffic
network
visualization
data
Prior art date
Application number
PCT/US2023/029447
Other languages
English (en)
Inventor
Brighton Vino JEGARAJAN
Arno Lenin MALYALA
Joshua WU
Shiva SUNDARRAJAN
Henry Luo
Michael Hu
Josh CRIDLEBAUGH
Ken CRIMMINS
Praveen Raju KARIYANAHALLI
Khanh Nguyen
Original Assignee
Aviatrix Systems, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Aviatrix Systems, Inc. filed Critical Aviatrix Systems, Inc.
Publication of WO2024030588A1 publication Critical patent/WO2024030588A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/22—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks comprising specially adapted graphical user interfaces [GUI]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/04—Processing captured monitoring data, e.g. for logfile generation
    • H04L43/045—Processing captured monitoring data, e.g. for logfile generation for graphical visualisation of monitoring data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14—Network analysis or design
    • H04L41/147—Network analysis or design for predicting network behaviour
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/16—Threshold monitoring

Definitions

  • Embodiments of the disclosure relate to the field of cloud networking. More specifically, one embodiment of the disclosure is directed to a system and method for providing operational visibility of an enterprise network.
  • on-premises electronic devices may correspond to an endpoint device (e.g., personal computer, cellular smartphone, netbook, etc.), a locally maintained mainframe, or even a local server for example.
  • endpoint device e.g., personal computer, cellular smartphone, netbook, etc.
  • mainframe e.g., mainframe
  • local server e.g., a local server
  • operational costs may include the costs for deploying, managing, maintaining, upgrading, repairing and replacing these electronic devices.
  • public cloud is a fully virtualized environment with a multi -tenant architecture that provides tenants (i.e., users) with an ability to share computing and storage resources while, at the same time, retaining data isolation within each user’s cloud account.
  • the virtualized environment includes on-demand, cloud computing platforms that are provided by a collection of physical data centers, where each data
  • SUBSTITUTE SHEET (RULE 26) center includes numerous servers hosted by the cloud provider. Examples of different types of public cloud networks may include, but is not limited or restricted to AMAZON WEB SERVICES®, MICROSOFT® AZURE®, GOOGLE CLOUD PLATFORMTM or ORACLE CLOUDTM for example.
  • cloud network providers permit the user with access to only a limited number of constructs, thereby controlling the type and amount of network information accessible by the user. As a result, the type or amount of network information is rarely sufficient to enable an administrator or user to quickly and effectively troubleshoot and correct network connectivity issues.
  • multi-cloud network there are no conventional solutions to visually monitor the exchange of traffic between network devices in different public cloud networks (multi-cloud network) and retain state information associated with network devices with the multi-cloud network to more quickly detect operational abnormalities that may suggest a cyberattack is in process or the health of the multi-cloud network is compromised.
  • a system and methods of implementing the same that generate a graphical user interface that enable an administrator or other user to build a network topology graph in an intuitive manner where the system then automatically deploys constructs and applicable communication lines between such constructs thereby generating a fully operational network topology.
  • a graphical user interface that displays a network topology graph in a visually scalable manner, i.e., the visual display of icons representing constructs, edges, and other aspects of a network topology graph automatically adjusts to reduce visual clutter and provide for ease of viewing.
  • Such systems, methods, and resultant graphical user interfaces should also provide for various monitoring, searching, and filtering capabilities directly from the graphical user interfaces.
  • a distributed cloud computing system includes a controller configured to (i) deploy and manage a first gateway in a first cloud computing network and a second gateway in a second cloud computing network, and (ii) manage a plurality of constructs; and logic, stored on non- transitory, computer-readable medium, that, upon execution by one or more processors, causes performance of operations.
  • the operations include: receiving, from each of the first gateway and the second gateway, network data, generating an expected network traffic based upon the network data, generating a visualization illustrating an anomaly that deviates from the expected network traffic, and causing rendering of the visualization on a display screen of a network device.
  • a non-transitory computer-readable medium having stored thereon logic that, when executed by one or more processors, causes operations including: receiving, from a controller, network data from a first gateway and a second gateway, generating an expected network traffic based upon the network data, generating a visualization illustrating an anomaly that deviates from the expected network traffic, and causing rendering of the visualization on a display screen of a network device.
  • a computerized method includes receiving, from a controller, network data from a first gateway and a second gateway, generating an expected network traffic based upon the network data, generating a visualization illustrating an anomaly that deviates from the expected network traffic, and causing rendering of the visualization on a display screen of a network device.
  • the visualization comprises a graph displaying actual network traffic overlayed on top of the expected network traffic.
  • the expected network traffic is divided into a plurality of thresholds of expected network traffic.
  • the plurality of thresholds includes: a first threshold that illustrates a tolerance range of the expected network traffic; and a second threshold that illustrates values of network traffic that exceed the first threshold.
  • the visualization when the network traffic is within the first threshold, the visualization does not include a visual indication of the anomaly and, when the network traffic exceeds the second threshold, the visualization comprises a visual indication of the anomaly.
  • the visualization comprises a secondary graph displaying parameters describing the network data.
  • the parameters describing network data are one or more of TCP ports and IP addresses.
  • the visualization includes a user input that allows a user to characterize the anomaly as not an anomaly.
  • the data associated with the anomaly is used as part of the network data upon which the expected network traffic is generated.
  • the visualization includes a graph of disk usage and projected disk runway.
  • the visualization includes a user input configured to select an amount of time for which data is to be backed up.
  • the graph of disk usage dynamically changes in response to manipulations of the user input.
  • FIG. 1 is a diagram of an exemplary embodiment of a distributed cloud computing system including a controller managing constructs spanning multiple cloud networks according to some embodiments;
  • FIG. 2A is an exemplary illustration of a logical representation of a controller deployed within a cloud computing platform in accordance with some embodiments
  • FIG. 2B an exemplary illustration of a logical representation of the topology system logic deployed within a cloud computing platform in accordance with some embodiments
  • FIG. 3A-3B illustrate interface screens displaying portions of a dashboard of a visualization platform directed to illustrating information pertaining to anomalies within a cloud-computing environment according to some embodiments;
  • FIGS. 4A-4E are interface screens displaying portions of a dashboard of a visualization platform directed to illustrating information pertaining to network traffic within a cloudcomputing environment according to some embodiments.
  • FIGS. 5A-5C are interface screens displaying portions of a dashboard of a visualization platform directed to illustrating information pertaining to disk usage within a cloud-computing environment according to some embodiments.
  • Embodiments of the disclosure are directed to a system configured to provide operational visibility of a network that spans one or more cloud computing environments.
  • the system may include a software instance that is operating in one or more cloud computing resources and is configured to collect information and render a graphic user interface (GUI) that provides an interactive, visual rendering of the connectively between constructs of a network spanning multiple (two or more) cloud computing environments (hereinafter, a “multi-cloud computing environment or a “multi-cloud network”).
  • GUI graphic user interface
  • the system includes the software instance and a controller configured to manage constructs deployed in one or more cloud computing environments such as within a multi-cloud environment and communicate with the software instance.
  • the software instance may query the controller for information using one or more Application Programming Interface (API) calls to retrieve information stored by the controller detailing status information of each construct managed by the controller.
  • API Application Programming Interface
  • the controller obtains such information from one or more gateways deployed within a multi-cloud network, where the gateway(s) are configured to transmit this information to the controller on a periodic (or aperiodic) basis.
  • multi-cloud networks refers a plurality of cloud networks, where each cloud network may constitute a public cloud network provided by a different cloud computing environment resource provider (hereinafter, “cloud provider”).
  • a controller may be configured to program each gateway to control routing of network traffic such as by providing instructions to gateways as to how network traffic is routed among various gateways.
  • the controller may instruct a gateway as to whether a virtual machine (VM) from one subnet work (hereinafter, “subnet”) may communicate directly with a VM from another subnet, or how network traffic will flow from a source to a destination within the cloud computing environment managed by the controller.
  • VM virtual machine
  • embodiments of the disclosure discuss instructions provided by the software instance to the controller, which are then transmitted to one or more gateways by the controller and include instructions to transmit network data from the gateway to a routable address (e.g., an Internet Protocol “IP” address, etc.) of the software instance.
  • a routable address e.g., an Internet Protocol “IP” address, etc.
  • the software instance may query the controller for data indicating a status and metadata of each construct managed by the controller and also receive network data from one or more gateways.
  • the software instance includes logic that, upon execution by one or more processors (e.g., being part of the cloud computing resources), generates various visualizations that are a combination of the construct status and metadata (collectively “construct metadata”) and the network data.
  • the visualizations may be interactive and provided to users such as network administrators, information technology (IT) professionals, or the like. Additionally, the visualizations may be configured to receive user input, which causes the logic of the software instance (“topology system logic”) to alter the visualizations.
  • the visualizations may include, but are not limited or restricted to, a dashboard view providing overall status and health of the network as well as specific network parameters; a dynamic topology mapping that provides a visual rendering of each construct and links that identify communications between the constructs; and a network flow visualization providing various illustrations detailing how network traffic is flowing (or has flowed) through the cloud computing environment managed by the controller.
  • Each of the visualizations may provide data spanning a multi-cloud network.
  • the topology system logic may generate tags for one or more of the constructs via the topology mapping visualization and store those tags for searching. For example, further user input may be received causing the topology system logic to search the numerous constructs managed by the controller and display the tagged constructs, as well as any links therebetween, via the topology mapping.
  • the topology system logic may generate visualizations illustrating the network flow of the corresponding tagged construct(s).
  • the topology system logic may generate the exemplary visualizations described above, and those shown in the accompanying drawings, that illustrate the flow of network traffic associated with one or more tagged constructs.
  • the illustrated flow of network traffic may correspond to constructs deployed in multiple cloud networks.
  • topology system logic may store the received data pertaining to the network (the network data and the construct metadata) for given points in time, e.g., ti — > t; (where i>l).
  • the topology system logic Upon receiving user input corresponding to a request to display the changes between two points in time, e.g., ti and t2, the topology system logic compares the stored data for ti and t2, and generate a visual that highlights the change(s) between the network at ti and t2.
  • highlight may refer to any visual indicator or combination of visual indicators, such as color-coding constructs having changed parameters, varying the size of constructs having changed parameters, displaying a graphic (e.g., a ring) around constructs having changed parameters, displaying a window or other image that lists the detected changes in state of the network, which may spanning multiple public cloud networks, between time ti and time t2, or other types of visual indicators.
  • visual indicators such as color-coding constructs having changed parameters, varying the size of constructs having changed parameters, displaying a graphic (e.g., a ring) around constructs having changed parameters, displaying a window or other image that lists the detected changes in state of the network, which may spanning multiple public cloud networks, between time ti and time t2, or other types of visual indicators.
  • logic is representative of hardware, firmware, and/or software that is configured to perform one or more functions.
  • the logic may include circuitry having data processing or storage functionality. Examples of such circuitry may include, but are not limited or restricted to a microprocessor, one or more processor cores, a programmable gate array, a microcontroller, an application specific integrated circuit, wireless receiver, transmitter and/or transceiver circuitry, semiconductor memory, or combinatorial logic.
  • the logic may be software in the form of one or more software modules.
  • the software module(s) may include an executable application, an application programming interface (API), a subroutine, a function, a procedure, an applet, a servlet, a routine, source code, a shared library/dynamic load library, or one or more instructions.
  • the software module(s) may be stored in any type of a suitable non-transitory storage medium, or transitory storage medium (e.g., electrical, optical, acoustical or other form of propagated signals such as carrier waves, infrared signals, or digital signals).
  • non-transitory storage medium may include, but are not limited or restricted to a programmable circuit; a semiconductor memory; non-persistent storage such as volatile memory (e.g., any type of random access memory “RAM”); persistent storage such as non-volatile memory (e.g., read-only memory “ROM”, power-backed RAM, flash memory, phase-change memory, etc.), a solid-state drive, hard disk drive, an optical disc drive, or a portable memory device.
  • volatile memory e.g., any type of random access memory “RAM”
  • persistent storage such as non-volatile memory (e.g., read-only memory “ROM”, power-backed RAM, flash memory, phase-change memory, etc.), a solid-state drive, hard disk drive, an optical disc drive, or a portable memory device.
  • the executable code may be stored in persistent storage.
  • construct may be construed as a virtual or physical logic directed to a particular functionality such as a gateway, virtual private cloud network (VPC), sub-network, or the like.
  • the construct may correspond to virtual logic in the form of software (e.g., a virtual machine), which may assign a device-specific address (e.g., a Media Access Control “MAC” address) and/or an IP address within an IP address range supported by to a particular IP subnet.
  • the construct may correspond to physical logic, such as an electronic device that is communicatively coupled to the network and assigned the MAC and/or IP address(es).
  • Examples of electronic devices may include, but are not limited or restricted to a personal computer (e.g., desktop, laptop, tablet or netbook), a mobile phone, a standalone appliance, a sensor, a server, or an information routing device (e.g., a router, bridge router (“brouter”), etc.). It is contemplated that each construct may constitute at least logic residing as part of a public network, although certain constructs may be deployed as part of an “on-premises” (or local) network.
  • gateway may refer to a software instance deployed within a public cloud network or a virtual private cloud network deployed with the public cloud network and controls the flow of data traffic within and from the public cloud network (e.g., to one or more remote sites including computing devices that may process, store and/or continue the routing of data).
  • each gateway may operate as a “transit gateway” or “spoke gateway,” which are gateways having similar architectures but are identified differently based on their location/configurations within a cloud computing environment.
  • a “spoke” gateway is configured to interact with targeted instances while a “hub” gateway is configured to further assist in the propagation of data traffic (e.g., one or more messages) directed to a spoke gateway or a computing device within an on-premises network.
  • data traffic e.g., one or more messages
  • network traffic metrics may refer to measurements of network traffic transmission including amount, frequency and/or latency.
  • network traffic metrics may include identification of a source and/or destination (e.g., IP address, originating/destination gateway, originating/destination VPC, originating/destination geographic region, etc.). Further, in some embodiments, network traffic metrics may also refer to analyses performed on and/or filtering of measurements of network traffic transmission.
  • controller may refer to a software instance deployed within a cloud computing environment (e.g., resources of a public cloud network) that manages operability of certain aspects of one or more cloud computing environments spanning across different public cloud networks (multi-cloud network).
  • a controller may be configured to collect information pertaining to each VPC and/or each gateway instance and configures one or more routing tables associated with one or more VPCs and/or gateway instances spanning a multicloud network to establish communication links (e.g., logical connections) between different sources and destinations.
  • These sources and/or destinations may include, but are not restricted or limited to on-premises computing devices, gateway instances or other types of cloud resources.
  • the term “message” generally refers to information in a prescribed format and transmitted in accordance with a suitable delivery protocol. Hence, each message may be in the form of one or more packets, frames, or any other series of bits having the prescribed format.
  • the term “link” may be generally construed as a physical or logical communication path between two or more constructs. For instance, as a physical communication path, wired and/or wireless interconnects in the form of electrical wiring, optical fiber, cable, bus trace, or a wireless channel using infrared, radio frequency (RF), may be used.
  • a logical communication path includes any communication scheme that enables information to be exchanged between multiple constructs
  • FIG. 1 a diagram of an exemplary embodiment of a distributed cloud management system 100 is shown, where the cloud computing system features a controller 102 for managing constructs residing in multiple cloud networks and a software instance 138 to visualize the managed constructs (hereinafter, “topology system logic”). More specifically, the controller 102 is configured to manage multiple constructs spanning multiple cloud networks, such as cloud (network) A 104 and cloud (network) B 106.
  • cloud A 104 provides computing resources (“resources”) for a transit gateway 114 in communication with gateways II81-II82 associated with virtual networks (VNETs) II61-II62.
  • VNETs virtual networks
  • Cloud B 106 provides resources for a transit gateway 120 in communication with gateways 1241-1242 associated with virtual private clouds (VPCs) 1221-1222. Cloud B 106 further provides resources for a native transit hub 126 in communication with VPCs 128 and 130. According to this embodiment of the disclosure, as shown in FIG. 1, the transit gateways 114, 120 and the native transit hub 126 are in communication with each other. Thus, as should be clearly understood that the controller 102 is managing several constructs, such as the illustrated gateways, that span multiple cloud networks. [0042] Specifically, a first grouping of constructs 108 is deployed within the Cloud A 104, and second and third groupings of constructs 110, 112 are deployed within Cloud B 106.
  • the controller 102 utilizes a set of APIs to provide instructions to and receive data (status information) associated with each of these constructs as well as status information pertaining to each connection between these constructs (link state).
  • the construct metadata returned by a construct may depend on the type of construct (e.g., regions, VPCs, gateway, subnets, instances within the VPCs, etc.), where examples of construct metadata may include, but is not limited or restricted to one or more of the following construct parameters (properties): construct name, construct identifier, encryption enabled, properties of the VPC associated with that construct (e.g. VPC name, identifier and/or region, etc.), cloud properties in which the construct is deployed (e.g., cloud vendor in which the construct resides, cloud type, etc.), or the like.
  • the cloud management system 100 includes topology system logic 138 processing on cloud computing resources 136.
  • the topology system logic 138 may be logic hosted on a user’s Infrastructure as a Service (laaS) cloud or multi-cloud environment.
  • the topology system logic 138 may be launched as an instance within the public cloud networks (e.g., as an EC2® instance in AWS®).
  • the topology system logic 138 may be launched as an virtual machine in AZURE®. When launched, the topology system logic 138 is assigned a routable address such as a static IP address for example.
  • the topology system logic 138 is in communication with the controller 102 via, for example, an API that enables the topology system logic 138 to transmit queries to the controller 102 via one or more API calls.
  • the topology system logic 138 upon execution by the cloud computing resources 136, performs operations including querying the controller 102 via API calls for construct metadata in response to a particular event.
  • the particular event may be in accordance with a periodic interval or an aperiodic interval or a triggering events such as a user request for a visualization via user input.
  • the controller 102 in response to receiving a query via an API call from the topology system logic 138, accesses data stored on or by the controller 102 and returns the requested data via the API to the topology system logic 138.
  • the topology system logic 138 may initiate one or more queries to the controller 102 to obtain topology information associated with the constructs managed by the controller 102 (e.g., a list of all gateways managed by the controller 102, a list of all VPCs or VNETs managed by the controller 102, or other data gathered from database tables) along with status information associated with each construct as described above.
  • the topology system logic 138 Upon receiving the requested construct metadata, the topology system logic 138 performs one or more analyses and determines whether any additional construct metadata needs to be requested. For example, the topology system logic 138 may provide a first query to the controller 102 requesting a list of all gateways managed by the controller 102. In response to receiving the requested construct metadata, the topology system logic 102 determines the interconnections between the gateways listed. Subsequently, the topology system logic 138 may provide a second query to the controller 102 requesting a list of all VPCs managed by the controller. In response to receiving the requested construct metadata, the topology system logic 138 determines the associations between each VPC and a corresponding gateway.
  • the received construct metadata provides detailed information for each gateway enabling the topology system logic 138 to generate a data object, e.g., a database table of the construct metadata, that represents a gateway.
  • the data object representing the multiple gateways are cross-referenced to build out a topology mapping based on the parameters of each gateway, which may include, inter alia: cloud network user account name; cloud provider name; VPC name; gateway name; VPC region; sandbox IP address; gateway subnet identifier; gateway subnet CIDR; gateway zone; name of associated cloud computing account; VPC identifier; VPC state; parent VPC name; VPC CIDR; etc.
  • the construct metadata is also utilized to generate a data object representing each VPC object and each subnet object.
  • a separate API call may be utilized by the topology system logic 138 to query the controller 102 for a listing of all transit gateways.
  • the topology system logic 138 is then able to determine whether a connection between a first gateway and a second gateway is between two transit gateways.
  • the connections between transit gateways and the connections between a spoke gateway and a transit may be represented visually in two distinct methods.
  • the topology system logic 138 may also receive network data from one or more gateways managed by the controller 102.
  • the network data may include for each network packet, but is not limited or restricted to, an ingress interface, a source IP address, a destination IP address, an IP protocol, a source port for UDP or TCP, a destination port for UDP or TCP, a type and code for ICMP, an IP “Type of Service,” etc.
  • the network data may be transmitted to the topology system logic 138 from a gateway using an IP protocol, for example, UDP.
  • the network data is collected and exported via the NetFlow network protocol.
  • the topology system logic 138 may provide instructions to the controller 102, which in turn provides the instructions to each gateway managed by the controller 102.
  • the instructions provide the IP address of the topology system logic 138, which is used as the IP address for addressing the transmission of the network data.
  • the topology system logic 138 may generate a visualization platform comprising one or more interactive display screens. These display screens may include a dashboard, a topology mapping and a network flow visualization. Additionally, the visualization platform may be configured to receive user input that causes filtering of the of the displayed data.
  • the topology system logic 138 may generate a topology mapping visualization of the connections linking the constructs detected by the controller 102, which are illustrated by the constructs within a logical region 132 represented by Cloud A 104 and Cloud B 106. Additionally, the topology system logic 138 may generate various graphical user interfaces (GUIs) that illustrates network traffic flows, traffic flow heat maps, packet capture, network health, link latency, encryption, firewalls, etc., of network traffic flowing between, to and from constructs managed by the controller 102 as illustrated by a second logical region 134.
  • GUIs graphical user interfaces
  • Embodiments of the disclosure offer numerous advantages over current systems that provide a dashboard illustrating parameters of a controller as current systems do not provide the ability to visualize connections between constructs deployed across multiple cloud networks, the state of resources and connections between resources for multiple clouds and the flow of network data through constructs spanning multiple clouds.
  • an enterprise network may utilize resources deployed in a plurality of cloud networks and an administrator of the enterprise network may desire to obtain visualization of the status of all constructs and connections associated with these resources.
  • conventional systems fail to provide such a solution.
  • a visualization or visual display of the constructs, connections therebetween and the status of each is referred to as a topology mapping.
  • Current systems fail to provide a topology mapping across multiple cloud networks and fail to allow an administrator to search across multiple cloud networks or visualize how changes in a state of a construct or connection in a first cloud network affects the state of a resource or connection in a second cloud network.
  • the topology mapping may automatically change as a state of a construct or connection changes or upon receipt of construct metadata updates in response to certain events such as at periodic time intervals (e.g., a “dynamic topology mapping”).
  • a network may be deployed across multiple cloud networks using a plurality of controllers to manage operability of the network.
  • each controller may gather the information from the network and constructs which it manages and a single controller may obtain all such information, thereby enabling the visualization platform to provide visibility across a network (or networks) spanning multiple controllers.
  • the controller 102 may be a software instance deployed within the cloud network to assist in managing operability of constructs within multiple public cloud networks.
  • the controller 102 may be configured with certain logic modules, including, a VPC gateway creation logic 200, a communication interface logic 202 and a data retrieval logic 204.
  • the controller 102 may also include a routing table database 206.
  • the gateway creation logic 200 performs operations to create a gateway within a VPC including creating a virtual machine within a VPC, provide configuration data to the virtual machine, and prompt initialization of the gateway based on the configuration data.
  • the VPC gateway creation logic 200 launches a virtual machine within a VPC, the virtual machine being an AMAZON® EC2 instance.
  • the virtual machine is launched using a pre-configured virtual machine image published by the controller 102.
  • the virtual machine image is an Amazon Machine Image (AMI).
  • AMI Amazon Machine Image
  • the communication interface logic 202 may be configured to communicate with the topology system logic 138 via an API.
  • the controller 102 may receive queries from the topology system logic 138 via one or more API calls and respond with requested data via the API.
  • the data retrieval logic 204 may be configured to access each construct managed by the controller 102 and obtain construct metadata therefrom. Alternatively, or in addition, the data retrieval logic 204 may receive such construct metadata that is transmitted (or “pushed”) from the constructs without the controller 102 initiating one or more queries (e.g., API calls).
  • the routing table database 206 may store VPC routing table data.
  • the controller 102 may configure a VPC routing table associated with each VPC to establish communication links (e.g., logical connections) between a transit gateway and cloud instances associated with a particular instance subnet.
  • a VPC routing table is programmed to support communication links between different sources and destinations, such as an on-premise computing devices, a cloud instance within a particular instance subnet or the like.
  • the controller 102 obtains and stores information that reveals certain properties of resources (e.g., constructs such as gateways, subnets, VPCs, instances within VPCs, etc.) within the purview of the controller 102 as well as status information pertaining to the connections (communication links) between with these resources.
  • the topology system logic 138 may be a software instance deployed using the cloud computing resources 136 and is configured to communicate with the controller 102 and each of the gateways managed by the controller 102.
  • the topology system logic 138 is configured with certain logic modules, including, a tagging logic 208, a tags database 210, an interface generation logic 212, a communication interface logic 214, a topology snapshot logic 216.
  • the topology system logic 138 may include a snapshot database 218, a construct metadata database 220 and a network data database 222.
  • the exemplary user interfaces illustrated in FIGS. 3-5 may be configured by the topology system logic 138 to be rendered and displayed on various display screens and via various applications.
  • each of the user interfaces illustrated in FIGS. 3-5 may be configured to be displayed through a web browser on a computer display screen, a laptop, a mobile device, or any other network device that includes a web browser.
  • each of the user interfaces illustrated in FIGS. 3-5 may be configured to be displayed through a dedicated software application installed and configured to be executed on any of the network devices described above.
  • the topology system logic 138 may be configured to provide the data and user interfaces described herein to a software application (known in the art as an “app”) that may be installed and configured to be executed by one or more processors of a network device.
  • the app upon execution, the app causes the user interfaces described herein to be rendered on the display screen of the network device (or an associated display screen).
  • GUI graphical user interface
  • dashboard 300 displaying portions of a dashboard topology system visualization platform (“visualization platform”) with each portion configured to illustrate information obtained or determined by the topology system is shown according to aspects of the disclosure.
  • the interface screen of FIG. 3 may be referred to as a dashboard 300 that includes several display portions that illustrate various attributes pertaining to a network that is deployed across one or more cloud providers, and notably across multiple cloud providers.
  • Dashboard 300 is configured to display various anomaly reporting graphs 304-308.
  • Dashboard 300 includes a header 302 that provides information regarding a reported anomaly.
  • header 302 may include a definition (i.e., what type of anomaly is being tracked), an identification of the VPC/Vnet associated with the anomaly, a classification of the severity of the anomaly, and user input or toggle that a user may use to classify the event as an anomaly or not.
  • the toggle could be any type of user input (e.g., a radio button, drop down, text field, etc.) by which the user may verify the anomaly.
  • a user may review dashboard 300 and determine that the event is not an anomaly (e.g., the reported increased traffic is expected).
  • classifying the event as not an anomaly allows the system to use the data associated with the event as a learned data point regarding traffic behavior for future reference.
  • Header 302 may further include a search bar that allows a user to search for specific metric types (e.g., per country traffic, per protocol traffic, egress ports, egress countries, egress IPs, egress bytes, egress packets, ingress ports, ingress countries, ingress IPs, ingress bytes, ingress packets, total bytes, and total packets).
  • specific metric types e.g., per country traffic, per protocol traffic, egress ports, egress countries, egress IPs, egress bytes, egress packets, ingress ports, ingress countries, ingress IPs, ingress bytes, ingress packets, total bytes, and total packets.
  • Graphs 304-308 provide anomaly details that provide context (e.g., when, how, and what) regarding the identified anomaly.
  • Graphs 304-308 provide visual information to a user so that the anomaly may be quickly analyzed, and any necessary mitigation steps can be taken.
  • the x-axis tracks time. As illustrated in FIG. 3, the x-axis is configured to show approximately one hour of data prior to the occurrence of the anomaly and approximately one hour of data after the occurrence of the anomaly to provide context regarding how the system was performing around the time of the anomaly. In other aspects, the amount of time prior to and after the anomaly may be varied.
  • the y-axis may be configured as one of various parameters, such as ingress ports (304), ingress bytes (306), ingress IPs (308).
  • the Y-axis unit represents the scale for the values of the metric. For example, if the graph is for ingress IPs and if the values of the IPs are 1, 3, 5, 8 etc. during the timestamps in x-axis, then the scale of the Y-axis could be 0-10. It will be appreciated that the y-axis could be configured to track other parameters.
  • Each graph 304-308 includes a score or rating of the anomaly (e.g., graph 304 indicates a 98.7% score for the anomaly, indicating the magnitude of the increase in ingress ports versus an expected value based on learned data).
  • the score may be an average of historical data.
  • the score is computed using a z-score algorithm. For example, the z-score of the current data point is computed with respect to the datapoints collected during a learning period. Fingerprinted data (learning period data) is taken into account for the same time interval on the same VPC to eliminate deviations in traffic during other time intervals.
  • the z- score of the current timestamp’s datapoint is determined, it is compared with the user set threshold for the z-score (for the user this is termed as detection sensitivity). If the current z-score is 50% more than the user set threshold, then the current data point is an anomaly in the green zone. If it’s 50-75% more then it’s in the yellow zone. If it’s >75%, then it is in the red zone.
  • Line 304(1) includes an anomaly 304(7) that is visually indicated by a dot.
  • anomaly 304(7) may be visually represented as any visual feature to draw attention to the anomaly on graph 304.
  • anomaly 304(7) may be identified by a dot, a box, a triangle, a graphic or icon, text (e.g., that provides information regarding the anomaly), and the like.
  • the learned values are expected values based upon aggregated historical data. For example, learned values may contain historical usage data for the previous 30 days.
  • an expected amount of traffic throughout the day can be estimated (e.g., an average amount of traffic).
  • the expected amount of traffic includes an upper limit and a lower limit, and the expected value varies based on time of day.
  • graph 304 illustrates that usage is generally higher around 11:00AM vs 10:30AM. Anomalies may be detected by comparing measured traffic to expected traffic. When traffic deviates from the expected value, the system may flag the event as an anomaly. In some aspects, events are only flagged as anomalies if they exceed certain thresholds.
  • Graph 304 provides a visual indication of several threshold values, each of which may be presented in a different color or shading to visually separate each threshold region.
  • a first region 304(2) represents a tolerance range based on the learning (i.e., an acceptable or expected amount of deviation).
  • first region 304(2) may represent values that deviate less than 50% from the expected value based upon the learned values. Values with first region 304(2) fall within the range of what is considered expected or normal and are not flagged as anomalies.
  • Regions 304(3)-304(5) represent a first threshold of deviation (e.g., 50-75%), a second threshold of deviation (e.g., 75-90%), and a third threshold of deviation (e.g., >90%), respectively. These deviation percentages are illustrative, and may be changed.
  • an anomaly may be reported when the value exceeds any of the thresholds of regions 304(3)-304(5).
  • some parameters may be set to be flagged as anomalies when the deviation value reaches region 304(3) (i.e., parameters for which even lower amounts of deviation are unacceptable). For other parameters, it may be acceptable for greater amounts of deviation, in which case an anomaly is only flagged when the deviation value reaches region 304(5).
  • Graph 304 includes a secondary graph 304(6) (e.g., a donut chart) that provides additional information that may be helpful in analyzing the reported anomaly.
  • Secondary graph 304(6) identifies the type and number of ports in use at the time of the anomaly.
  • Graphs 306 and 308 include similar features and are numbered accordingly. Graph 306 provides information regarding ingress bytes and graph 308 provides information regarding ingress IPs. In various aspects, additional graphs may be displayed for other parameters. Providing multiple parameters provides more context to the user regarding the system at the time of the anomaly.
  • FIGS. 4A-4E illustrate GUI screens displaying portions of a dashboard topology system visualization platform, with each portion configured to illustrate information obtained or determined by the topology system.
  • the interface screens of FIGS. 4A-4E may be referred to as a dashboard 400 that includes several display portions that illustrate various attributes pertaining to a network that is deployed across one or more cloud providers, and notably across multiple cloud providers.
  • Dashboard 400 is configured to display various parameters that describe a status or health of the underlying topology.
  • dashboard 400 illustrates a menu 402, a header 404, a summary section 406, and graphs 408-414.
  • Menu 402 enables a user to easily navigate to different options provided by the topology system visualization platform.
  • Menu 402 can comprise various buttons, drop downs, and the like to assist with navigation through the topology system visualization platform.
  • Header section 404 allows a user of the topology system visualization platform to make various selections via drop downs and/or search fields. As illustrated in FIG. 4A, header section 404 allows the user to specify a time period (e.g., last 7 days), a start date/time, an end date/time, and a filter 422 to limit/target the monitored data. FIG. 4E illustrates an exemplary filter 422 that may be used to create structured searches. Header section 404 also allows the user to select between different tabs to view different information, such as an overview (i.e., illustrated in FIG. 4A), trends, geo, and records (see FIG. 4B-4D). The trends page shows time series line charts for traffic by top applications, another time series chart for traffic by risk score. FIG.
  • FIG. 4B represents raw netflow records forwards by gateways to the topology system visualization platform.
  • the records contain identifying information about the application that has sent/received the traffic and the protocol it used to forward the traffic. Based on the type of the application, a risk score is computed and the usual vulnerabilities for such application traffic are listed.
  • FIG. 4C represents user-configured applications and their JA3 Hashes.
  • JA3 and JA3S are TLS fingerprinting methods. JA3 fingerprints the way that a client application communicates over TLS and JA3S fingerprints the server response. Combined, they essentially create a fingerprint of the cryptographic negotiation between the client and server.
  • Summary section 406 provides a summary regarding the information displayed in graphs 408-414. For example, the total traffic (e.g., in megabytes), the number of unique applications that are being run, the number of countries from which traffic is flowing to/from, and the like.
  • Summary section 406 may include a dropdown that enables a user to select how traffic is to be viewed (e.g., bytes, traffic forwarded by application, traffic by risk severity, traffic by Layer 7 protocol used by applications, traffic by Layer 7 category), etc.).
  • Graphs 408-414 display information regarding various parameters of the underlying topology.
  • graph 408 displays data regarding traffic tied to various applications in use (e.g., Google, Apple iCloud, Sharepoint, etc.).
  • a user may identify abnormal application usage.
  • Graph 410 displays data regarding traffic associated with various Layer 7 protocols (e.g., HTTP, HTTPS, DNS, BitTorrent, etc.).
  • Layer 7 protocols e.g., HTTP, HTTPS, DNS, BitTorrent, etc.
  • Graph 412 displays data regarding risk. Risk is determined from pre-defined hashing on a packet level (i.e., certain hash values are given certain levels of risk ranging from unknown to severe).
  • the user can assess the overall risk level and take steps to mitigate the risk if necessary.
  • Graph 414 displays data regarding traffic associated with Layer 7 by category (e.g., web, application, database).
  • FIG. 4B illustrates a table 416 of dashboard 400 that displays information associated with a fingerprinting (i.e., JA3) dictionary.
  • the JA3 dictionary allows the user to build custom definitions for applications so that the system will recognize the application in the future.
  • Each entry in the JA3 dictionary includes a number of parameters regarding the application, and may include, for example, a timestamp indication when the application was used, a gateway associated with the application, the JA3 fingerprint or hash associated with the application, the Layer 7 protocol associated with the application, the Layer 7 Fully Qualified Domain Name associated with the application, the Layer 7 Risk associated with the application, and a Layer 7 latency associated with the application.
  • FIG. 4C illustrates a table 418 of dashboard 400 that demonstrates the ability to override a JA3 hash to specify an application other than a previously known application. This ability gives the user greater customization of the data shown in dashboard 400.
  • FIG. 4D illustrates a table 420 of dashboard 400 that demonstrates the ability to assign multiple JA3 hash values to one application. This is useful when different hash values are associated with different instances of what is really the same application.
  • the ability to assign multiple J A3 hash values to one application simplifies and cleans up the data shown in, for example, FIG. 4A as redundant instances of the application do not appear in the results being displayed.
  • FIG. 4E illustrates in more detail the filter 422 of header section 404 of FIG. 4A.
  • Filter feature allows a user to build a Boolean search based on a variety of parameters.
  • the parameters that may be used to filter include byte size, destination address, TCP flag label, flow locality, direction, CSP tags, bytes, host gateway, destination gateway, source gateway, source IP, source country, destination IP, destination country, traffic type (private vs public), direction of the traffic, timestamps, etc.
  • the filter feature is most helpful for troubleshooting an incident.
  • IP filters if an application is not receiving any hits/traffic, the user can filter by destination gateway (behind which the application VM is present) and see if that GW has any flows during the time interval the issue happened; 2) if a gateway is down or not based on the amount of traffic forward by the gateway; 3) if a threat is discovered, identify the source of the threat (IP filters); if anomalous traffic is discovered on a VPC, flowIQ filters like gateway, bytes, IPs can help troubleshoot how much traffic is going through the gateway during the time interval at which anomaly happened; and if a particular port is accidentally open to the world by checking for traffic on the port.
  • IP filters if anomalous traffic is discovered on a VPC, flowIQ filters like gateway, bytes, IPs can help troubleshoot how much traffic is going through the gateway during the time interval at which anomaly happened; and if a particular port is accidentally open to the world by checking for traffic on the port.
  • FIGS. 5A-5C illustrate GUI screens displaying portions of a dashboard topology system visualization platform, with each portion configured to illustrate information obtained or determined by the topology system.
  • the interface screens of FIGS. 5A-5C may be referred to as a dashboard 500 that includes several display portions that illustrate various attributes pertaining to a network that is deployed across one or more cloud providers, and notably across multiple cloud providers.
  • Dashboard 500 is configured to display various parameters that describe disk usage. Referring to FIG. 5A, dashboard 500 illustrates a menu 502 (similar to menu 402), a header section 504, a disk usage and projection section 506, a disk table 508, a Flow IQ section 510, and a performance section 512.
  • Header section 504 provides an estimate of the disk runway (i.e., the amount of time until disk space will run out based upon current disk usage trends). As illustrated in FIG. 5A, the current estimate for disk runway is 58 days. Dashboard 500 allows a user to modify disk usage parameters to manage the disk runway period.
  • Disk usage and projection section 506 includes a dynamically generated graph 506(1) that displays past disk usage 506(2), projected disk usage 506(3), and full disk usage 506(4).
  • Graph 506(1) breaks down disk usage into multiple categories, including Flow IQ, performance, and other. In various aspects, additional categories can be tracked if desired. Each category of disk usage may be color coded to visually highlight each category.
  • Disk table 508 lists the available storage disks and provides information regarding the disks, including address/directory, disk size, used disk space, available disk space, and where the disk is mounted.
  • Flow IQ section 510 provides information regarding disk usage by Flow IQ and allows the user to specify how much Flow IQ data to back up.
  • FIG. 5A illustrates that, using the current configuration, Flow IQ data is using 30.5 GB of disk space via 256 records. The average additional storage per day of Flow IQ data is 5.12 GB.
  • the user may adjust the storage of Flow IQ data by manipulating a slider 510(1). Slider 510(1) allows the user to specify how many days of data to back up. It will be appreciated that slider 510(1) could be any of a variety of user inputs to select the number of days to back up (e.g., drop down, text field, radio buttons, etc.).
  • FIG. 5B discussed below, illustrates a change made to slider 510(1).
  • Performance section 512 is similar to Flow IQ section 510, but instead relates to the storage of performance data.
  • Performance section 512 illustrates that, using the current configuration, performance data is using 9.5 GB of disk space via 20.1 million records. The average additional storage per day of performance data is 80.61 MB.
  • the user may adjust the storage of performance data by manipulating a slider 512(1).
  • slider 512(1) could be any of a variety of user inputs to select the number of days to back up (e.g., drop down, text field, radio buttons, etc.). Slider 512(1) allows the user to specify how many days of data to back up.
  • FIG. 5B discussed below, illustrates a change made to slider 512(1).
  • FIG. 5B illustrates dashboard 500 after changes have been made to sliders 510(1) and 512(1).
  • the estimated disk runway is 58 days.
  • the estimated disk runway shown in 504 of FIG. 5B
  • FIG. 5B also illustrates that graph 506(1) has dynamically changed relative to graph 506(1) of FIG. 5 A.
  • the projected disk usage 506(3) has changed due to the changes made to sliders 510(1) and 512(1), while the past disk usage 506(2) remains the same in FIGS. 5 A and 5B and full disk usage 506(4) is no longer a part of graph 506(1).
  • FIG. 5C illustrates a manage data section 514 associated with dashboard 500.
  • Manage data section 514 allows a user to specifically select data for deletion to further manage disk usage.
  • manage data section 514 allows a user to target records for deletion based upon time period (e.g., delete records between a start date/time and an end date/time) or based upon record number (e.g., delete the earliest 1,000 records, delete the last 500 records, etc.).
  • time period e.g., delete records between a start date/time and an end date/time
  • record number e.g., delete the earliest 1,000 records, delete the last 500 records, etc.
  • acts, events, or functions of any of the algorithms described herein can be performed in a different sequence, can be added, merged, or left out altogether (e.g., not all described acts or events are necessary for the practice of the algorithms).
  • acts or events can be performed concurrently, e.g., through multi -threaded processing, interrupt processing, or multiple processors or processor cores or on other parallel architectures, rather than sequentially.
  • certain computer-implemented tasks are described as being performed by a particular entity, other embodiments are possible in which these tasks are performed by a different entity.
  • Conditional language used herein such as, among others, “can”, “might”, “may”, “e.g.”, and the like, unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments include, while other embodiments do not include, certain features, elements and/or states. Thus, such conditional language is not generally intended to imply that features, elements and/or states are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without author input or prompting, whether these features, elements and/or states are included or are to be performed in any particular embodiment.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Mining & Analysis (AREA)
  • Human Computer Interaction (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

La présente invention concerne un système informatique en nuage distribué qui comprend un dispositif de commande configuré (i) pour déployer et gérer une première passerelle dans un premier réseau informatique en nuage et une seconde passerelle dans un second réseau informatique en nuage, et (ii) pour gérer une pluralité de constructions ; et une logique, stockée sur un support non transitoire lisible par ordinateur, qui, lors de l'exécution par un ou plusieurs processeurs, provoque des performances d'opérations. Les opérations consistent : à recevoir, de chacune de la première passerelle et de la seconde passerelle, des données de réseau, à générer un trafic de réseau attendu sur la base des données de réseau, à générer une visualisation illustrant une anomalie qui s'écarte du trafic de réseau attendu, et à provoquer le rendu de la visualisation sur un écran de visualisation d'un dispositif de réseau.
PCT/US2023/029447 2022-08-03 2023-08-03 Systèmes et procédés pour de meilleures caractéristiques de surveillance pour une topologie de réseau et interfaces utilisateur correspondantes WO2024030588A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202263394903P 2022-08-03 2022-08-03
US63/394,903 2022-08-03

Publications (1)

Publication Number Publication Date
WO2024030588A1 true WO2024030588A1 (fr) 2024-02-08

Family

ID=89849746

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2023/029447 WO2024030588A1 (fr) 2022-08-03 2023-08-03 Systèmes et procédés pour de meilleures caractéristiques de surveillance pour une topologie de réseau et interfaces utilisateur correspondantes

Country Status (1)

Country Link
WO (1) WO2024030588A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9652354B2 (en) * 2014-03-18 2017-05-16 Microsoft Technology Licensing, Llc. Unsupervised anomaly detection for arbitrary time series
US10019517B2 (en) * 2014-05-06 2018-07-10 Tivo Solutions Inc. Managing media content upload groups
US10819629B2 (en) * 2016-11-15 2020-10-27 At&T Intellectual Property I, L.P. Method and apparatus for dynamic network routing in a software defined network
US11277315B2 (en) * 2020-07-02 2022-03-15 Juniper Networks, Inc. Dashboard for display of state information in a graphic representation of network topology

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9652354B2 (en) * 2014-03-18 2017-05-16 Microsoft Technology Licensing, Llc. Unsupervised anomaly detection for arbitrary time series
US10019517B2 (en) * 2014-05-06 2018-07-10 Tivo Solutions Inc. Managing media content upload groups
US10819629B2 (en) * 2016-11-15 2020-10-27 At&T Intellectual Property I, L.P. Method and apparatus for dynamic network routing in a software defined network
US11277315B2 (en) * 2020-07-02 2022-03-15 Juniper Networks, Inc. Dashboard for display of state information in a graphic representation of network topology

Similar Documents

Publication Publication Date Title
US11722387B1 (en) System and method for determination of network operation metrics and generation of network operation metrics visualizations
US11671331B2 (en) Systems and methods for contextual network assurance based on change audits
US10237294B1 (en) Fingerprinting entities based on activity in an information technology environment
US8156378B1 (en) System and method for determination of the root cause of an overall failure of a business application service
US20150256413A1 (en) Network system with live topology mechanism and method of operation thereof
US10616072B1 (en) Epoch data interface
US20220245462A1 (en) Training a digital twin in artificial intelligence-defined networking
US10944641B1 (en) Systems and methods for application traffic simulation using captured flows
US11489745B2 (en) Methods, systems and computer readable media for providing a declarative network monitoring environment
US10897412B2 (en) Bifocal timeline graphs for network analytics
US20160065444A1 (en) Anomaly detection based on combinations of cause value, message type, response time (gtp-c)
US11695661B1 (en) Systems and methods for deploying a cloud management system configured for tagging constructs deployed in a multi-cloud environment
WO2024030588A1 (fr) Systèmes et procédés pour de meilleures caractéristiques de surveillance pour une topologie de réseau et interfaces utilisateur correspondantes
US11038915B1 (en) Dynamic generation of courses of action for incident response in an information technology environment
WO2023154315A1 (fr) Système et procédé de détection d'anomalie dans un environnement en nuage distribué
WO2024026745A1 (fr) Systèmes et procédés de génération d'une topologie de réseau et interfaces utilisateur correspondantes
WO2024030589A1 (fr) Systèmes et procédés de génération d'une topologie de réseau et interfaces utilisateur correspondantes
WO2024030403A1 (fr) Systèmes et procédés de surveillance d'une topologie de réseau par l'intermédiaire d'interfaces utilisateur graphiques
Lombard Operating VMware Cloud on AWS
WO2024097402A1 (fr) Systèmes et procédés de dimensionnement de réseau autonome utilisant l'intelligence artificielle

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23850773

Country of ref document: EP

Kind code of ref document: A1