WO2023102036A1 - Système et procédé de filtrage et de modification basé sur un nuage de messages avec des adresses de chevauchement - Google Patents

Système et procédé de filtrage et de modification basé sur un nuage de messages avec des adresses de chevauchement Download PDF

Info

Publication number
WO2023102036A1
WO2023102036A1 PCT/US2022/051387 US2022051387W WO2023102036A1 WO 2023102036 A1 WO2023102036 A1 WO 2023102036A1 US 2022051387 W US2022051387 W US 2022051387W WO 2023102036 A1 WO2023102036 A1 WO 2023102036A1
Authority
WO
WIPO (PCT)
Prior art keywords
network
cloud
address
virtual
tenant
Prior art date
Application number
PCT/US2022/051387
Other languages
English (en)
Inventor
Nicholas DELECROIX
Saad MIRZA
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 WO2023102036A1 publication Critical patent/WO2023102036A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/2514—Translation of Internet protocol [IP] addresses between local and global IP addresses
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/64—Routing or path finding of packets in data switching networks using an overlay routing layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H04L45/745—Address table lookup; Address filtering
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/74—Admission control; Resource allocation measures in reaction to resource unavailability
    • H04L47/746—Reaction triggered by a failure
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/78—Architectures of resource allocation
    • H04L47/781—Centralised allocation of resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/2521—Translation architectures other than single NAT servers
    • H04L61/2535—Multiple local networks, e.g. resolving potential IP address conflicts
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/2592—Translation of Internet protocol [IP] addresses using tunnelling or encapsulation

Definitions

  • Embodiments of the disclosure relate to the field of networking. More specifically, one embodiment of the disclosure relates to a cloud-based, automated message filtering and modification system operating with one or more edge (spoke) gateways to handle network traffic with overlapping network addresses.
  • spoke edge
  • cloud computing has provided Infrastructure as a Service (laaS), where resources have been developed to leverage and control the native constructs for all types of public cloud networks, such as AMAZON® WEB SERVICES (AWS), MICROSOFT® AZURE® Cloud Services, GOOGLE® Cloud Services, or the like.
  • AWS AMAZON® WEB SERVICES
  • Azure MICROSOFT® AZURE® Cloud Services
  • GOOGLE® Cloud Services or the like.
  • These resources operate as a network infrastructure, which overlays portions of a public cloud network or multiple public cloud networks and provides enhanced functionality (e.g., enhanced security, scalability, visibility, etc.) and is provided access by tenants as a service.
  • this overlaying network infrastructure is generally referred to as a “cloud platform.”
  • the cloud platform may be configured to support hundreds of tenants concurrently by implementing virtual networking infrastructures, where the construct of these networking infrastructures may vary depending on the public cloud provider.
  • the virtual networking infrastructures may include virtual private clouds for AMAZON® WEB SERVICES (AWS), virtual networks for MICROSOFT® AZURE® Cloud Services, or the like.
  • AWS AMAZON® WEB SERVICES
  • VPC virtual private cloud network
  • VPC virtual private cloud network
  • spoke VPCs
  • control plane refers to all functions and/or processes that determine which routing path to use when sending a message.
  • the “data plane” refers to all functions and/or processes that forward messages from one interface to another based on controls set by logic associated with the control plane. These VPCs may be configured to support the routing of messages with the same region of a public cloud network, different regions of the same public cloud network, or different public cloud networks.
  • each of the spoke VPCs may include logic that is manually programmed to perform a network address translation on an incoming control plane message.
  • the management of these VPCs can be highly complex.
  • Current VPC management tools fail to provide adequate safeguards for identifying and modifying messages with overlapping network addresses, which is becoming increasingly problematic given the dynamic scaling and modifications experienced with VPC deployments. Firstly, desired connectivity may not be achieved as the proper routing of data traffic cannot be guaranteed. Secondly, manual configurations of NAT and the associated control plane policies bring a security risk to cloud platforms.
  • a significant security risk is present as data returned from shared services requested by a first tenant may be directed to a second tenant, when the first and second tenants having overlapping network addresses caused by tenant subnetworks having identical prefixes such as the same network identifiers.
  • FIG. 1 is an exemplary embodiment of a cloud platform configured as a software- defined cloud overlay network and deploying a network traffic filtering system over a multi-cloud infrastructure.
  • FIG. 2A is an exemplary embodiment of a logical architecture of the network traffic filtering system of FIG. 1 handling ingress network traffic as advertisements from tenant resources.
  • FIG. 2B is an exemplary embodiment of a logical architecture of the network traffic filtering system of FIG. 1 handling egress network traffic as advertisements from cloud components.
  • FIG. 3 is an exemplary embodiment of the operability of the network traffic filtering system within the spoke gateways of FIG. 1.
  • FIG. 4 is a first exemplary embodiment of the operability of network traffic filtering system deployed within cloud components of the cloud platform to restrict continued propagation of network traffic associated with an overlapping network address.
  • FIGS. 5A-5D are directed to a second exemplary embodiment of the operability of the network traffic filtering system deployed within cloud components of the cloud platform to alter the network address of incoming control plane messages with overlapping network addresses prior to their continued propagation over the cloud platform.
  • FIG. 6 is an exemplary embodiment of the method of operations associated with the transmission of a Border Gateway Protocol (BGP) advertisement from the first tenant resource of FIG. 1.
  • BGP Border Gateway Protocol
  • FIG. 7 is an exemplary embodiment of the method of operations associated with a response to the BGP advertisement of FIG. 6.
  • FIG. 8 is an exemplary embodiment of a cloud platform constituting a software- defined cloud overlay network with routing programmability over the cloud platform based on controller messaging via a control plane of the cloud platform.
  • Embodiments of a network traffic filtering system operating with one or more cloud components of a software-defined network constructed to overlay a public cloud network, is configured to provide enhanced controls and management of communications over the public cloud network (hereinafter, “cloud platform”).
  • the network traffic filtering system is configured to monitor for overlapping network addresses pertaining to (i) cloud components within the cloud platform and resources associated with a tenant using the cloud platform and/or (ii) resources associated with different tenants using the cloud platform.
  • An example of “tenant resources” may include, but is not limited or restrict to one or more components deployed within a tenant environment.
  • the “tenant environment” may correspond to an on-premises network of the tenant and is communicatively coupled to the cloud platform such as one or more computing devices.
  • the “tenant resources” may include one or more cloud components operating within the tenant environment corresponding to a virtual networking infrastructure (VPC) of the tenant (hereinafter, “tenant VPC”) and communicatively coupled to other components within the cloud platform.
  • VPC virtual networking infrastructure
  • the cloud service providers responsible for managing the cloud platform may have control in the addressing for their own subnetworks (hereinafter, “subnets”), these cloud service providers have no control over the subnet addressing selected by tenants that utilize the services provided by the cloud platform.
  • the advertised subnet address associated with the tenant resource may overlap (i) a network address range assigned to a cloud component within the cloud platform and/or (ii) a network address range utilized by another tenant.
  • BGP Border Gateway Protocol
  • IP addresses such as Internet Protocol (IP) addresses for example, may be divided into sections.
  • a first section of the IP address may identify the network (hereinafter, “network ID”) while a second segment may identify a specific machine or host within the network (hereinafter, “host ID”).
  • IPv4 IP address masks and prefixes
  • IPv4 can be used to establish the range of useable IP addresses supported by a subnet (i.e., group of IP addresses associated with the same network ID).
  • a subnet address (e.g., Classless-InterDomain Routing “CIDR” representation of a subnet IP address range) can be used to identify all computing devices associated with a particular company or a collection of users segmented by any number of parameters such as geographic location, user characteristics (e.g., job title, department, etc.), or the like.
  • CIDR Classless-InterDomain Routing
  • a tenant may utilize tens or hundreds of subnets with the cloud platform supporting thousands of tenants.
  • Dividing a tenant’ s network into subnets allows the tenant to be connected to the cloud platform with a single shared network address. Subnet masks and prefixes are relied upon when a tenant is attempting to communicate with another system.
  • a message may be sent to a gateway, and thereafter, routed to a targeted IP address.
  • This routing is referred to as Classless-InterDomain Routing (CIDR).
  • CIDR Classless-InterDomain Routing
  • the subnet mask 255.255.255.0 is 32-bits, namely four 8- bit octets.
  • This representation identifies a 24-bit subnet prefix and the subnet supporting more than 250 useable IP addresses ranging from xx.xx.xx.l - xx.xx.xx.254.
  • IPv4 addresses are used in determining network address overlapping conditions, albeit the invention may be utilized by other protocols directed to addressing and routing network traffic.
  • a cloud instance deployed within the controller (or a cloud platform administrator) is provided access to the actual subnetwork addresses (referred to as “real subnet addresses”) associated with the tenant resources, namely the components deployed within the tenant environment such as a tenant VPC or on-prem network for example, for initially determining whether any of these real subnet addresses overlap a known subnet address range already assigned to cloud components installed within the cloud platform or another tenant.
  • the cloud instance or cloud platform administrator conducts an initial determination whether the communicative coupling of the tenant resources to the cloud platform would create a network address overlapping condition, and if so, a mapped network address translation (NAT) is configured to handle this network address overlapping condition.
  • NAT mapped network address translation
  • the mapped NAT corresponds to a collection of network address translations for a routing protocol established between the cloud platform and a tenant environment over a network connection (e.g., BGP tenant connection) to avoid network address overlapping conditions.
  • the collection of network address translations includes translations between “real” subnet addresses (sometimes referred to as “real VPC CIDR”) and “virtual” subnet addresses (sometimes referred to as “virtual VPC CIDR”).
  • a “virtual” subnet address constitutes a non-overlapping, substitute address for a particular real subnet address.
  • the mapped NAT may be stored within a data store being a portion of non-transitory storage medium.
  • additional network address translations are generated for storage within the mapped NAT.
  • the additional network address translations may be manually programmed or generated through IP Address Management (IP AM) integration to fetch the next available virtual subnet address.
  • IP AM IP Address Management
  • an edge cloud component e.g., spoke gateway
  • logic implemented within one or more selected cloud components of the cloud platform e.g., NAT processing logic within the controller
  • the network address overlapping condition may be detected when a real subnet address included within an incoming control plane message (e.g., subnet prefix within the BGP advertisement) is found in the mapped NAT. If so, the NAT processing logic assists in components of the cloud platform that are responsible the routing of messages over one or more public cloud networks to/from the tenant resource (e.g., onpremises computing device).
  • this translation may involve configuring routing tables for each of the cloud components with the cloud platform, which may overlay the infrastructure of a single public cloud network or multiple (two or more) public cloud networks, to include the real subnet address or the virtual subnet address to effectuate routing with the on-premises computing device.
  • the controller is configured to signal the cloud components, such as various gateways implemented within the cloud platform, via direct messages to update their routing tables to include the virtual VPC CIDR in lieu of the real VPC CIDR to avoid an overlapping address condition to promote greater security and reliable operability.
  • the NAT processing logic may be further configured to determine, using the “real” subnet address for the attached VPC, whether a network address overlapping condition would exist for resources communicatively coupled to the cloud platform over BGP tenant connections.
  • the network address overlapping condition may be detected when the real subnet address, such as the real VPC CIDR being a CIDR- representation of a subnet IP address range associated with the attached (cloud-based) VPC and included in a VPC attachment message for example, is found in a mapped NAT associated with a BGP tenant connection.
  • the real subnet address such as the real VPC CIDR being a CIDR- representation of a subnet IP address range associated with the attached (cloud-based) VPC and included in a VPC attachment message for example, is found in a mapped NAT associated with a BGP tenant connection.
  • the NAT processing logic assists in performing the translation by at least signaling each spoke gateway operating as a terminating end of a BGP tenant connection with a detected network address overlapping condition to modify its routing table to include a virtual VPC CIDR (virtual subnet address) in lieu of its corresponding real VPC CIDR (real subnet address).
  • the NAT processing logic signals each spoke gateway operating as a terminating end of those BGP tenant connections to simply maintain the real VPC CIDR for routing to/from those spoke gateways not subject to network address overlapping conditions.
  • NAT processing logic of the network traffic filtering system is assigned to perform an address translation for control plane messages received by the cloud platform and control plane messages output from the cloud platform.
  • the NAT processing logic may access a listing of network address translations (mapped NAT) for real subnet addresses reserved for components forming the cloud platform (e.g., real subnet address to virtual subnet address translations).
  • the address translation is conducted before a data message (sourced by a component associated with a real subnet address included in the mapped NAT) is propagated through the cloud platform.
  • the controller populates mapped NATs for each spoke VPC of the cloud platform and referenced by one or more spoke gateways deployed within the spoke VPC.
  • the spoke VPC is configured to allow content associated with an incoming control plane message to propagate through the cloud platform if (i) the real subnet (IP) address identified in the control plane message does not overlap any real subnet (IP) address range associated with a cloud component of the cloud platform, and (ii) the real subnet (IP) address overlaps an IP address range associated with a cloud component, but the real subnet (IP) address is modified with a virtual IP address that does not overlap any IP address ranges utilized by the cloud components.
  • IP real subnet
  • the spoke gateway may be configured to prevent subsequent data messages from being errantly propagated over the cloud platform if there is an entry within the mapped NAT that denotes the incoming control plane message features a network address overlapping condition (e.g., subnet address associated of an incoming control plane message falls within a subnet address utilized by one of the components of the cloud platform).
  • a network address overlapping condition e.g., subnet address associated of an incoming control plane message falls within a subnet address utilized by one of the components of the cloud platform.
  • the spoke gateway may be configured to conduct a translation of an address of the incoming control plane message to avoid any network address overlapping conditions, such as a real subnet address of the incoming control plane message (e.g., real VPC CIDR) is noted as an entry in the mapped NAT, and thus, is substituted with a corresponding virtual subnet address (e.g., virtual VPC CIDR) with that entry before propagation through the cloud platform.
  • a real subnet address of the incoming control plane message e.g., real VPC CIDR
  • a virtual subnet address e.g., virtual VPC CIDR
  • the NAT processing logic may access mapped NATs for all the BGP tenant connections for real subnet (IP) addresses that are correlated to (e.g., identical or falling within the subnet address range of) the real VPC CIDR. This correlation denotes a potential network address overlapping condition.
  • IP real subnet
  • the NAT processing logic may be configured to conduct a translation of real VPC CIDR to a virtual network address of the attached VPC (e.g., virtual VPC CIDR) by providing the corresponding virtual VPC CIDR to the spoke gateway or spoke gateways associated with the BGP tenant connection(s) to transit a BGP advertisement with the virtual VPC CIDR to avoid security issues and errand data caused by a network address overlapping condition.
  • a virtual network address of the attached VPC e.g., virtual VPC CIDR
  • the spoke gateway or spoke gateways associated with the BGP tenant connection(s) to transit a BGP advertisement with the virtual VPC CIDR to avoid security issues and errand data caused by a network address overlapping condition.
  • each of the terms “logic” and “component” is representative of hardware, software, or a combination thereof, which is configured to perform one or more functions.
  • the logic may include circuitry having data processing and/or storage functionality. Examples of such circuitry may include, but are not limited or restricted to a processor (e.g., microprocessor, one or more processor cores, a programmable gate array, a microcontroller, an application specific integrated circuit, etc.); non-transitory storage medium; combinatorial logic that collectively perform a specific function or functions, or the like.
  • the logic may be software in the form of one or more software modules.
  • the software module(s) may be configured to operate as one or more software instances with selected functionality (e.g., virtual processor, data analytics, etc.) or as a virtual network device including one or more virtual hardware components.
  • the software module(s) may include, but are not limited or restricted to 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.
  • API application programming interface
  • 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).
  • suitable 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”); or 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.
  • a “controller” is a component that manages operability of a single region or multiple regions of a single-cloud platform or multi-cloud platform by leveraging centralized intelligence acquired based on access and knowledge of content associated with network traffic through each gateway.
  • the controller includes logic, referred to as NAT processing logic, that enforces policies directed to filtering and/or routing modification, which may be unique to each gateway and/or each VPC.
  • the filter and/or modification rules may correspond to conducting checks and updating of a mapped NAT, namely a data store directed to reassignment of a network address to avoid collisions that may significantly affect operations of the cloud platform.
  • Tenant Each “tenant” uniquely corresponds to a particular customer provided access to the cloud platform, such as a company, individual, partnership, or any group of entities (e.g., individual(s) and/or business(es)).
  • Computing device may be construed as virtual or physical logic with data processing and/or data storage functionality.
  • a computing device may include a virtual device that is configured to perform functions based on information received from cloud components.
  • the computing device may correspond to a virtual server configured to execute software instances retrieved from cloud shared services.
  • Gateway may be construed as virtual or physical logic with data monitoring or data routing functionality.
  • a first type of gateway may correspond to virtual logic, such as a data routing software component that is assigned an Internet Protocol (IP) address within an IP address range associated with a virtual networking infrastructure (VPC) including the gateway, to handle the routing of messages within and from the VPC.
  • IP Internet Protocol
  • VPC virtual networking infrastructure
  • the first type of gateway may be identified differently based on its location/operability within a public cloud network, albeit the logical architecture is similar.
  • a “spoke” gateway is a gateway that supports routing of network traffic between a component requesting a cloud-based service and a shared services VPC that maintains the cloud-based service offered by the cloud platform and made available to multiple (two or more) tenants.
  • a “transit” gateway is a gateway configured to further assist in the propagation of network traffic (e.g., one or more messages) between different VPCs such as different spoke gateways within different spoke VPCs.
  • the gateway may correspond to physical logic, such as a type of computing device that supports and is addressable (e.g., assigned a network address such as an IP address).
  • IPSec tunnels Secure peer-to-peer communication links established between gateways of neighboring virtual network components such as neighboring VPCs.
  • the peer- to-peer communication links are secured through a secure network protocol suite referred to as “Internet Protocol Security” (IPSec).
  • IPSec Internet Protocol Security
  • Overlapping network address This term identifies a network address that may fall within subnet IP address ranges associated with different subnets.
  • a network address overlapping condition may be determined when a subnet address, represented by a Class Inter-Domain Routing (CIDR) representation designating a subset that is advertising a service or network presence, is identical to or is a subset of a subnet address range utilized by (i) a cloud component (e.g., VPC, etc.) of the cloud platform and/or (ii) resources (onpremises or cloud-based) associated with another tenant.
  • CIDR Class Inter-Domain Routing
  • Computerized This term generally represents that any corresponding operations are conducted by hardware in combination with software.
  • each message may be in the form of one or more packets (e.g., data plane packets, control plane packets, etc.), frames, or any other series of bits having the prescribed format.
  • packets e.g., data plane packets, control plane packets, etc.
  • frames e.g., frames, or any other series of bits having the prescribed format.
  • the cloud platform 100 may correspond to a software-defined cloud or multi-cloud overlay network featuring components in communication through messages using private network addresses such as Internet Protocol (IP) addresses.
  • IP Internet Protocol
  • the cloud platform 100 is configured to provide resources 110 located within one or more on-premises networks 120 with connectivity to enhanced cloud services. These resources 110 may involve multi-tenant resources, such as first tenant resources 130, second tenant resources 132, and/or third tenant resources as shown. These multi-tenant resources 110 may feature computing devices, routers for connectivity to certain cloud components, or the like.
  • the first tenant resources 130, the second tenant resources 132 and the third tenant resources 134 may constitute resources deployed within the on-premises network(s) 120, namely the same on-premises network or different on-premises networks.
  • the first tenant (Tl) resources 130 and the third tenant (T3) resources 134 may feature computing devices 131 and 135, respectively.
  • the T1 resources 130 and T3 resources 134 may be attributable to different departments within the same company (Company A).
  • the T1 resources 130 and the T2 resources 132 may feature computing devices 131 and 133 respectively, which are attributable to different companies (Company A & Company B).
  • the tenant resources 130/132/134 may constitute virtual private cloud networks (VPCs) that are associated with different tenants and deployed within the same or different regions of a public cloud network or different public cloud networks.
  • VPCs virtual private cloud networks
  • the cloud platform 100 includes one or more virtual private cloud networks (hereinafter, “spoke VPCs”) 140, which are configured for communications with the tenant resources 130/132/134.
  • spoke VPCs e.g., a first spoke (Spokel) VPC 142
  • network traffic filtering system 150 operating within a network controller 190, where the network traffic filtering system 150 is configured to detect network address overlapping conditions.
  • a first type of network address overlapping condition occurs when a network address (e.g., real subnet IP address) within a control plane message 160 received from a tenant resource supported by that spoke VPC (e.g., T1 resources 130 and/or T3 resources 134) overlaps a specific network address or specific network (IP) address range utilized by any of the cloud components 105 of the cloud platform 100 or a specific network address range utilized by another tenant resource.
  • a network address e.g., real subnet IP address
  • IP IP
  • the network traffic filtering system 150 may be configured to access the Class InterDomain Routing (CIDR) representation of a real subnet IP address 162 of the T1 resources 130 (referred to as “real VPC CIDR 162”) from the BGP advertisement 160 to determine whether the real VPC CIDR 162 overlaps a CIDR-representation of a subnet IP address assigned to a cloud component 105 implemented as part of the cloud platform 100 and/or a CIDR-representation of a subnet IP address assigned to other tenant resources (e.g., T2 resources 132).
  • CIDR Class InterDomain Routing
  • This determination may include a review of content within a first mapped NAT 152, which provides CIDR-representations of “real” subnet IP addresses for the cloud components 105 and known tenant resources accessible via the Spokel VPC 142 having overlapping network addresses.
  • the cloud components 105 may include one or more gateways and/or one or more cloud shared services.
  • the spoke VPCs 140 are coupled to other VPCs 170 within the cloud platform 100.
  • Each of these other VPCs (hereinafter, “transit VPCs” 170) is responsible for propagating data plane messages received by the spoke VPCs 140 to other VPCs such as the cloud shared service VPC 180.
  • the Spokel VPC 142 is configured to communicate with one or more tenant resources (e.g., T1 resources 130 via router 136 and/or T3 resources 134 via router 137), where the T1/T3 resources 130/134 may be deployed within the same on-premises network, different on-premises networks, or alternatively, the T1/T3 resources 130/134 may be deployed as a cloud component.
  • a second spoke VPC 143 (hereinafter, “Spoke2 VPC”) is configured to communicate with the T2 resources 132 via a router 138, where the T2 resources 132 may be deployed within the same on-premises network as T1 resources 130 and/or T3 resources 134 or within a different on-premises network.
  • the Spoke2 VPC 143 may be part of the cloud platform 100 overlaying infrastructure associated with a first public cloud network and/or infrastructure of multiple public cloud networks such as five different public cloud networks for example.
  • the T1 resources 130 and the T3 resources 134 are configured to exchange data traffic with a selected gateway of a set (e.g., one or more) of gateways 144I-144M (M>1) maintained in the Spokel VPC 142.
  • these gateways 144I-144M are referred to as “spoke gateways” 144I-144M.
  • spoke gateways 144I-144M is communicatively coupled with the controller 190, including the network traffic filtering system 150, over a control plane 155.
  • the network traffic filtering system 150 is configured to detect a first type of network address overlapping condition by at least conducting analytics on one or more control plane messages input into the cloud platform 100 (e.g., incoming control plane message 160).
  • These analytics may include conducting a review of the content of the first mapped NAT 152 to determine whether a “real” subnet (IP) address of a tenant resource hosting the incoming control plane message 160 (e.g., T1 resource 130) overlaps (i) a real subnet (IP) address utilized by any of the cloud components 105 within the cloud platform 100 (included in the first mapped NAT 152) and/or (ii) a “real” subnet (IP) address utilized by a tenant resource other than the hosted tenant resource (e.g., T2/T3 resource 132/134).
  • IP real subnet
  • the network traffic filtering system 150 Responsive to detecting the first type of network address overlapping condition, is configured to (i) perform a network address translation upon detecting a network address overlapping condition (see FIG. 5A) and/or (ii) block propagation of the control plane message 160 in response to detecting the network address overlapping condition (see FIG. 4). While deployed within the controller 190, the network traffic filtering system 150 may be integrated, wholly or partially, into each spoke gateway 144i... and 144M or may be implemented as a separate cloud component interacting with the spoke gateways 144I-144M.
  • the T2 resources 132 are configured to exchange data traffic with a selected spoke gateway of a set of spoke gateways 1451- 145M maintained in the Spoke2 VPC 143.
  • Each of the spoke gateways 145I-145M may be associated with a network traffic filtering system 150, which is also configured to conduct analytics to detect network address overlapping conditions.
  • the analytics may include a review of content within a second mapped NAT 153, which identifies network address overlapping conditions pertaining to subnet IP addresses for the cloud components 105 and known tenant resources in conflict with the subnet IP address range for the T2 resources 132.
  • the network traffic filtering system 150 is configured to (i) perform a network address translation (see FIG. 5A) and/or (ii) block propagation of content associated with the incoming control plane message (see FIG. 4). While deployed within the controller 190, as an alternative, the network traffic filtering system 150 may be integrated, wholly or partially, into each spoke gateway 145i... and 145M or may be implemented as a separate cloud component interacting with the spoke gateways 145I-145M.
  • the network traffic filtering system 150 may be configured to detect a second type of network address overlapping condition by at least conducting analytics on contents of a VPC attachment message generated based on a cloud service (e.g., shared services VPC 180), recently communicatively coupled to the cloud platform 100.
  • the analytics may include accessing contents of each mapped NAT 152/153 to determine whether the real subnet address is included as an entry within the first mapped NAT 152. If so, the network traffic filtering system 150 is configured to perform a network address translation (see FIG. 5D) and/or block propagation.
  • the controller 190 for the cloud platform 100 is configured to manage gateway data stores 146I-146M, 176I-176M, 186I-186M that control the propagation paths involving spoke gateways 144I-144M, transit gateways 175I-175M, and gateways 185I-185M associated with shared services 180, respectively. Additionally, the controller 190 is configured to manage the first mapped NAT 152 associated with a first BGP tenant connection and utilized by these spoke gateways 144I-144M. Each gateway data store 146i...
  • each gateway data store 146i... or 146M may be generated and uniquely assigned for each spoke gateways 144I-144M, respectively.
  • the first mapped NAT 152 may be generated and shared among a plurality of spoke gateways 144I-144M within the same spoke VPC 142.
  • spoke gateways 145I-145M gateway data stores 147I-147M, and the second mapped NAT 153 that is associated with the BGP connection between the tenant resources 132 and the spoke gateways 145I-145M, which could reside in the same geographic region or different geographic region as spoke gateways 144I-144M, or could reside in a different public cloud network.
  • Each of the mapped NATs 152/153 may be configured with address translations that identify subnet IP addresses utilized by a tenant resource (i.e., “real” subnet IP address) that overlaps a “real” subnet IP address associated with a cloud component within the cloud platform and/or other tenant resources utilizing the services provided through the cloud platform 100.
  • the address translations include a substitute subnet address corresponding to the real subnet IP address (i.e., “virtual” subnet IP address) for use in the transmission of messages over the cloud platform 100.
  • Each of the gateway data stores 144I-144M and 145I-145M as well as the mapped NATs 152 and 153 are populated by the controller 190.
  • the cloud platform 100 includes a peering of the set of spoke gateways 1441-144M deployed within the Spokel VPC 142 to a set of gateways 175I-175N deployed within the transit VPC 170, which may be referred to as “transit gateways” 175I-175N (N>2).
  • the set of spoke gateways 145I-145M deployed within the Spoke2 VPC 143 is also communicatively coupled to the transit gateways 175I-175N.
  • the sets of spoke gateways 144I-144M and 145I-145M are represented as the first spoke gateway 144i and a second spoke gateway 1442 along with third spoke gateway 1451 and a fourth spoke gateway 1452, although three or more spoke gateways may be deployed within the Spokel VPC 142 and/or the Spoke2 VPC 143.
  • the set of transit gateways 175I-175N is represented by a first transit gateway 175i and a second transit gateway 1752, although three or more transit gateways may be deployed within the transit VPC 170.
  • M x N IPSec tunnels 177H-177MN are created between the Spokel VPC 142 and the transit VPC 170.
  • the IPSec tunnels 177H-177MN may be established and maintained through gateway routing tables 146I-146M dedicated to each of the spoke gateways 144i- 144M, respectively.
  • the first spoke gateway 144i is communicatively coupled to both the first transit gateway 1751 via a peer- to-peer communication link 177n and the second transit gateway 1752 via a peer-to-peer communication link 17712.
  • the second spoke gateway 1442 is communicatively coupled to both the first transit gateway 175i via peer-to-peer communication link 17721 and the second transit gateway 1752 via peer-to-peer communication link 17722-
  • the peer- to-peer communication links 177n-17722 may constitute cryptographically secure tunnels, such as tunnels operating in accordance with a secure network protocol.
  • IPSec Internet Protocol Security
  • the VPC-to-VPC tunnels may be referred to as “IPSec tunnels.”
  • a first gateway routing table 146i determines which IPSec tunnel 177n- 17712 for use in forwarding a message from the T1 resources 130 (sometimes referred to as a tenant environment) to the shared services VPC 180 and which IPSec tunnel 177n-177i2 to propagate information back to the T1 resources 130.
  • the network traffic filtering system 150 operating in concert with the mapped NATs 152/153, determines whether the incoming control plane messages into the spoke VPCs 140 feature any known overlapping IP addresses prior to transmission therefrom.
  • FIG. 2A an exemplary embodiment of a logical architecture of the network traffic filtering system 150 implemented within one or more cloud components, such as controller 190 deployed within the cloud platform 100 of FIG. 1 for example, is shown.
  • the controller 190 features one or more input/output (I/O) interfaces 200, one or more processors 220 and a non-transitory storage medium 230.
  • the non-transitory storage medium 230 features the network traffic filtering system 150, which includes the first mapped NAT 152 (utilized by Spokel VPC 142 of FIG. 1), the second mapped NAT (utilized by Spoke2 VPC 143 of FIG. 1), and NAT processing logic 240.
  • the first mapped NAT 152 is configured by the controller 190 with address translations that (i) identify a real subnet IP address that overlaps a subnet IP address associated with a cloud component within the cloud platform and (ii) provide a corresponding “virtual” subnet IP address for use, in lieu of the real subnet IP address, in the transmission of messages over the cloud platform 100.
  • the first mapped NAT 152 may include a first collection of address translations each associated with an overlapping subnet IP address pertaining to a source outside of the cloud platform (referred to as “remote subnet IP address”) and a second collection of address translations each associated with a subnet IP address pertaining to a component of the cloud platform (referred to as a “local subnet IP address”).
  • the first mapped NAT 152 is repeatedly updated by the controller 190, notably when new cloud components are added to the cloud platform 100 of FIG. 1 and/or existing cloud components 105 of the cloud platform 100 are removed or modified.
  • the NAT processing logic 240 is configured to detect the receipt of an incoming control plane message 250 via the first I/O interface 200 from tenant resources 130/134 of FIG. 1 and a VPC attachment message 270 from a VPC that has been newly communicatively coupled to the cloud platform 100 (e.g., shared services VPC 180) as shown in FIGS. 1&2B.
  • the incoming control plane message 250 may constitute, but is not limited or restricted to a BGP advertisement, which is described below for illustrative purposes.
  • a network address included within this control plane message such as a CIDR-representation of a “real” subnet IP address 260 associated with the source of the BGP advertisement 250 for example, is compared to remote subnet IP addresses within the first mapped NAT 152.
  • the NAT processing logic 240 accesses the real subnet IP address 260 from the BGP advertisement 250.
  • the NAT processing logic 240 determines whether the accessed subnet IP address (real subnet IP address) 260 overlaps a remote subnet IP address 262 being part of an address translation within the first mapped NAT 152 to denote a network address overlapping condition.
  • the NAT processing logic 240 accesses a translated IP address 265 corresponding to the remote subnet IP address 262 (referred to as the “virtual” subnet IP address 265) from the first mapped NAT 152 and transmits a message directed to the gateway(s) included in Spokel VPC 142 from which the real subnet IP address 260 was accessed to update gateway data stores 1461-1462 with at least the virtual subnet IP address 265 (and perhaps AS-Path and/or BGP attributes). If no remote subnet IP addresses within the first mapped NAT 152 overlap the real subnet IP address 260, the real subnet IP address 260 remains relied upon for forwarding subsequent data message from a tenant resource via the transit VPC 170 of FIG. 1 to the shared services VPC 180 for example.
  • the NAT processing logic 240 accesses a subnet IP address 275 (e.g., CIDR representative of a real subnet IP address referred to as the “real VPC CIDR”) from the message 270. Thereafter, the NAT processing logic 240 determines whether the real VPC CIDR 275 overlaps a local subnet IP address 280 being part of an address translation within the first mapped NAT 152 to denote a network address overlapping condition.
  • a subnet IP address 275 e.g., CIDR representative of a real subnet IP address referred to as the “real VPC CIDR”
  • the NAT processing logic 240 accesses a translated network address (e.g., virtual subnet IP address 285 such as a “virtual VPC CIDR”) correspond to the correlated local subnet IP address 280, generates a message to substitute the virtual VPC CIDR 285 for the real VPC CIDR 275 to fulfil a routing change within gateway data stores (e.g. data stores 1461-1462, 1761-1762, 1861-1862), generates a message to prompt recipient gateway(s) to generate a BGP advertisement 290 that advertises availability of functionality offered by the shared services VPC 180 accessible via the virtual VPC CIDR 275 to those tenant resources communicatively coupled to the cloud platform via BGP tenant connections (see FIG. 1).
  • a translated network address e.g., virtual subnet IP address 285 such as a “virtual VPC CIDR”
  • gateway data stores e.g. data stores 1461-1462, 1761-1762, 1861-1862
  • BGP advertisement 290 that advertises availability
  • the real VPC CIDR 275 of the message 270 would be included as part of the BGP advertisement 290 and no routing changes are made to the gateway data stores 1461-1462, 1761-1762 and 186i-l 862-
  • the mapped NAT is populated with subnet (IP) addresses utilized by cloud components within the cloud platform and/or subnet addresses utilized by tenant resources that overlap, which are referred to as “real subnet (IP) addresses” (operation 300).
  • IP subnet
  • IP virtual subnet
  • IP virtual subnet
  • a “real” subnet (IP) address included in the BGP advertisement e.g., CIDR-representation for a subnet IP address of the source initiating the BGP advertisement
  • IP real subnet
  • This comparison may be performed by the network traffic filtering system 150 deployed within the controller 190 of FIG. 1.
  • the network traffic filtering system 150 may be deployed as a software instance of a cloud platform that is executed by a processor.
  • the comparison may be conducted by the network traffic filtering system 150 based on the mapped NAT populated by automated through trained, machine learning logic or other artificial intelligence-based logic that compares CIDR-representations of “real” subnet (IP) addresses gathered from analysis of cloud components and tenant resources registered to use the cloud platform.
  • IP subnet
  • IP real subnet
  • the mapped NAT includes a real subnet (IP) address that overlaps the accessed real subnet (IP) address (e.g., IP address range associated with the accessed real subnet (IP) address is identical to or at least partially contained within an IP address range associated with a real subnet (IP) address within the mapped NAT), a virtual subnet (IP) address corresponding to the real subnet address is made available (operations 360 and 370).
  • IP real subnet
  • IP real subnet
  • IP virtual subnet
  • FIG. 4 a first exemplary embodiment of the operability of network traffic filtering system 150 deployed within the controller 190 and operating in concert with cloud components of the cloud platform 100, such as the spoke gateways 144i for example, is shown.
  • the network traffic filtering system 150 is configured to restrict continued propagation of network traffic associated with overlapping network address.
  • a first computing device 400 may be allocated a real network (IP) address 402 (10.30.0.19) within a first subnet 404 (CIDR-representation 10.30.0.0/24) reserved for the T1 resources 130.
  • a second computing device 410 also may be allocated a real network (IP) address 412 (10.30.0.5) within a second subnet 414 (CIDR-representation 10.30.0.0/24), which features a subnet address range identical to the first subset 404.
  • a third computing device 420 may be allocated a real network (IP) address 422 (10.40.0.19) within a third subnet 424 (CIDR-representation 10.40.0.0/24), which is outside the private address range used by the first subnet 404 and the second subnet 414.
  • IP real network
  • resources associated with the Spokel VPC 142 may be allocated IP addresses within a fourth subnet 430 (CIDR-representation 10.7.0.0/24) while resources associated with the Spoke2 VPC 143 may be allocated IP addresses within a fifth subnet 440 (CIDR-representation 10.7.1.0/24), both of which do not overlap with each other or any of the subnet address ranges utilized to the T1 resources 130, the T2 resources 132, or the T3 resources 134.
  • resources associated with the transit VPC 170 may be allocated with IP addresses within a sixth subnet 450 (CIDR- representation 10.0.0.0/24), which does not overlap any of the subnet address ranges utilized by T1 resources 130, T2 resources 132, T3 resources 134, the Spokel VPC 142, and the Spoke2 VPC 143.
  • the resources within the shared services VPC 180 are allocated IP addresses within a seventh subnet 460 (CIDR- representation 10.30.0.0/24), where the first subnet 404, the second subnet 414, and the seventh subnet 460 addresses constitute overlapping network addresses.
  • the NAT processing logic 240 may be configured to detect the incoming BGP advertisement 160 and access a real subnet IP address 406 correspond to the first subnet 404 (CIDR- representation 10.30.0.0/24) from the IP address field 162 of the BGP advertisement 160.
  • the first subnet address 406 may include the CIDR- representation, namely the IPv4 address “10.30.0.0” along with a corresponding subnet mask (or subnet prefix length).
  • the subnet mask (or subnet prefix length) is 24-bits (e.g., three octets or /24)
  • the most significant 24-bits of the private (IP) address associated with the first computing device 400 generally represent the first IP subnet address 406.
  • the NAT processing logic 240 determines whether an overlapping network (IP) address condition exists.
  • IP overlapping network
  • the first mapped NAT 152 associated with the first BGP tenant connection includes a “local” subnet address 460 (i.e., local to the cloud platform 100 with CIDR-representation 10.30.0.0/24) constituting the subnet IP address range utilized by the shared services VPC 180, which includes a software instance 462 allocated a real subnet IP address 464 (CIDR- representation 10.30.0.17), the BGP advertisement 160 is dropped and thereby the content of data messages from the T1 resources 130 are prohibited from propagating through the cloud platform 100.
  • the NAT processing logic 240 associated with a spoke gateway 1442, in communication with the router 137 of the T3 resources 134, accesses an address 426 of the third subnet 424 (CIDR-representation 10.40.0.0/24) from an IP address field 472 of the BGP advertisement 470. After accessing the third subnet IP address 426, the NAT processing logic 240 determines whether an overlapping network (IP) address condition exists.
  • IP overlapping network
  • a “remote” subnet address 10.40.0.0/24 i.e., remote from cloud platform 100
  • data messages from the T3 resources 134 are permitted to be forwarded by the spoke gateway 144i to the transit VPC 170 and propagated through the cloud platform 100.
  • FIGS. 5A-5D a second exemplary embodiment of the operability of the network traffic filtering system 150 deployed within cloud components of the cloud platform 100 is shown.
  • the NAT processing logic 240 of the network traffic filtering system 150 is configured to alter gateway data stores in response to receiving an incoming (control plane) message with overlapping network addresses prior to subsequent propagation of data messages over the cloud platform 100.
  • the first computing device 400 may be allocated the real network (IP) address 402 (10.30.0.19) within the first subnet 404 (CIDR- representation 10.30.0.0/24) reserved for the T1 resources 130.
  • the second computing device 410 also may be allocated the real network (IP) address 412 (10.30.0.5) within the second subnet 414 (CIDR-representation 10.30.0.0/24).
  • the third computing device 420 may be allocated the real network (IP) address 422 (e.g., CIDR-representation 10.40.0.19) within the third subnet 424 (CIDR-representation 10.40.0.0/24).
  • resources associated with the Spoke 1 VPC 142 may be allocated IP addresses within the fourth subnet 430 (CIDR-representation 10.7.0.0/24) while resources associated with the Spoke2 VPC 143 may be allocated IP addresses within the fifth subnet 440 (CIDR-representation 10.7.1.0/24).
  • resources associated with the transit VPC 170 may be allocated with IP addresses within the sixth subnet 450 (CIDR-representation 10.0.0.0/24) and the resources within the shared services VPC 180 are allocated IP addresses within the seventh subnet 460 (CIDR- representation 10.30.0.0/24).
  • the third, fourth, fifth and sixth subnets 424, 430, 440 and 450 feature non-overlapping IP address ranges.
  • the first subnet 404 associated with the T1 resources 130, the second subnet 414 associated with the T2 resources 132, and the seventh subnet 460 associated with the shared services VPC 180 (CIDR-representation 10.30.0.0/24) feature overlapping IP addresses associated with cloud components forming the cloud platform 100.
  • the NAT processing logic 240 may be configured to determine whether an overlapping network (IP) address condition exists. For example, this determination may be accomplished from conducting analytics on the first subnet IP address 406 (CIDR-representation 10.30.0.0/24) included in the IP address field 162 of the BGP advertisement 160. According to one embodiment of the disclosure, the NAT processing logic 240 may receive the first subnet IP address 406 or as part of the contents of the BGP advertisement 160 made available to the controller 190.
  • IP overlapping network
  • the NAT processing logic 240 is configured to conduct analytics by determining whether the first subnet IP address 406 coincides with a CIDR-representation of the first subnet IP address (CIDR-representation 10.30.0.0/24) within the first mapped NAT 152.
  • the first mapped NAT 152 features the network address translations for the first BGP tenant connection with the T1 resources 130.
  • the presence of a coinciding network address translation identifies to the NAT processing logic 240 that a network address translation of the first subnet IP address 406 is required.
  • a presence of a network address overlapping condition may be determined by identifying whether the first subnet address 406 is included in the first mapped NAT 152.
  • This network address translation 520 is conducted to program all gateways with a route 10.130.0.0/24 to point towards the set of spoke gateways 144 so resources in the cloud network can access T1 resources 130 by using its virtual subnet.
  • one or more data messages may be routed by the spoke gateway 144i to include the virtual (remote) network address 520 as the identifier for the T1 resource 130 in lieu of the real (remote) network address 500 along with AS path data 530 and/or other content (e.g., next hop addressing/information, etc.) 540.
  • the subnet address 550 (CIDR- representation 10.7.0.0/24), which is not part of the first mapped NAT 152, may be included as part of a routing path maintained by messaging between the Spoke 1 VPC 142 and the transit VPC 170.
  • the first mapped NAT 152 may also include “local” network address translations associated with cloud components with subnet IP addresses that overlap subnet IP addresses associated with one or more tenant resources.
  • This network address translation 560 may be also directed to BGP advertisements initiated from the first spoke gateway 144i of the cloud platform 100 to T1 resources 130 based on messaging from the controller 190 prompted by a cloud component (e.g., shared services VPC 180).
  • a second mapped NAT 153 associated with a BGP tenant connection between spoke gateway 1452 and T2 resources 132 may include one or more “real” network address translations associated with control plane messages (e.g., BGP advertisement).
  • the network address translations may be conducted on content received from the tenant resources 132 prior to continuing propagation through the cloud platform 100 of FIG. 5A.
  • the second mapped NAT 153 includes a network address translation from real subnet IP address (CIDR-representation 10.30.0.0/24) 580 to virtual subnet IP address (CIDR-representation 10.131.0.0/24) 582.
  • the second mapped NAT 153 may include one or more network address translations between a real VPC CIDR 10.30.0.0/24 584 for the shared services VPC 180 and a virtual subnet IP address 586 (e.g., CIDR-representation 10.230.0.0/24), given that a network address overlapping condition exists between the subset address range used by the shared services VPC 180 and the subnet address range used by the T2 resources 132.
  • the second mapped NAT 153 may be updated with this translation during an attachment phase of the shared services VPC 180 for example.
  • IP subnet
  • one or more data messages subsequent to the BGP advertisement 570 may be routed by the spoke gateway 1442 to o the transit VPC 170 and propagated through the cloud platform 100.
  • the data message(s) may include the real (third) subnet IP address 426 as the identifier for the T3 resource 134 along with the subnet address 550 (CIDR-representation 10.7.0.0/24 included as part of a routing path) and/or other content (e.g., next hop addressing/information, etc.) 570.
  • the NAT processing logic 240 in response to communicatively coupling (i.e., attaching) a VPC to the cloud platform 100 (e.g., attaching the shared services VPC 180 to transit gateway 1752 of the transit VPC 170), the NAT processing logic 240 is configured to determine, using the “real” subnet address 460 for the shared services VPC 180, whether a network address overlapping condition exists. According to one embodiment of the disclosure, the NAT processing logic 240 detects a network address overlapping condition when a subnet IP address with the IP address range associated with the real subnet address 460 is found in a mapped NAT associated with any of the existing BGP tenant connections 592-594.
  • the first mapped NAT 152 is associated with network address translations handled over the first BGP tenant connection 592.
  • the second mapped NAT 153 is associated with a third BGP tenant connection 594.
  • No (or an empty) mapped NAT is associated with the second BGP tenant connection 593.
  • the real subnet address 460 is provided by a VPC attachment message 590 (represented as signaling 270 in FIG. 2A), such as a CIDR-representation 10.30.0.0/24 for example.
  • the NAT processing logic 240 upon receiving the VPC attachment message 590, is configured to determine whether a network address overlapping condition exists for communications with the T1-T3 resources 130/132/134 over BGP tenant connections 592/593/594. For the T1 resources 130 over the first BGP tenant connection 592 between spoke gateway 144i and T1 resources 130, the NAT processing logic 240 would access the first mapped NAT 152 and detect a network address overlapping condition based on the real-virtual network address translation 560 as shown in FIG. 5B.
  • the NAT processing logic 240 would access the second mapped NAT 153 and detect a network address overlapping condition based on a real- virtual network address translation 588 as shown in FIG. 5C.
  • the NAT processing logic 240 assists in performing the translation by at least signaling the corresponding spoke gateways 144i and 1452, operating as terminating ends of the BGP tenant connections 592 and 594, to transmit a BGP advertisement to the T1 and T2 resources 130/132 for the newly attached shared services VPC 180 using the virtual subnet IP address 586 (CIDR-representation 10.230.0.0/24) in lieu of the real subnet address 584 (CIDR-representation 10.30.0.0/24).
  • the NAT processing logic 240 signals the spoke gateway 1442, operating as a terminating end of the second BGP tenant connection 593, to transmit a BGP advertisement to the T3 resources 134 using the real subnet address 584 (CIDR-representation 10.30.0.0/24) of the shared services VPC 180.
  • the BGP advertisement may include a “real” subnet (IP) address associated with and advertising tenant resources.
  • IP real subnet
  • the BGP advertisement is received by a spoke gateway assigned for providing the tenant resources with access to the cloud platform, including services within the shared services VPC (operation 600).
  • the NAT processing logic may be configured to access the real subnet (IP) address being advertised (CIDR) and conduct analytics to determine whether an overlapping IP address condition exists involving the subnet (IP) address (operations 610, 620).
  • the NAT processing logic conducts analytics to determine whether an overlapping IP address condition exists between the subnet (IP) address of the source and subnet addresses associated with cloud components within the cloud platform (operation 630). Such analytics may be conducted by accessing a pre-populated mapped NAT to determine if the subnet (IP) address identified in the BGP advertisement is included as part of a network address translation within the mapped NAT. If so, the NAT processing logic conducts the network address translation by substituting the “real” subnet (IP) address (e.g., real VPC CIDR) corresponding to routing addresses within gateway data stores associated with gateways within the cloud platform with the “virtual” subnet (IP) address (virtual VPC CIDR) as set forth in operation 640.
  • IP real subnet
  • IP virtual VPC CIDR
  • the NAT processing logic conducts analytics to determine whether an overlapping IP address condition exists between the “real” subnet (IP) address associated with the BGP advertisement and subnet addresses associated with any tenant resources utilizing the cloud platform (operation 650). If so, the NAT processing logic conducts the network address translation by substituting the “real” subnet (IP) address with the “virtual” subnet (IP) address (operation 640).
  • the determination as to which gateway data stores may be universal to all of the gateway data stores associated with gateways within the cloud platform or only specific gateway data stores within a routing associated with the source of the real subnet (IP) address. As a result, the content of incoming data messages subsequent to the BGP advertisement will utilize the virtual subnet address in lieu of the “real” subnet address when propagated through cloud components within the cloud platform (operation 660).
  • the message would include at least the real VPC CIDR, namely the “real” subnet IP address assigned to the shared services VPC (operation 700).
  • the NAT processing logic within the controller conducts analytics to determine whether an overlapping IP address condition exist for the real VPC CIDR (operation 710).
  • the analytics conducted on the message are directed to determining whether the real VPC CIDR is present within any of the mapped NATs.
  • the NAT processing logic conducts the network address translation by substituting the “real VPC CIDR (CIDR-representation 10.30.0.0/24) for the “virtual” subnet IP address (e.g., virtual VPC CIDR 10.230.0.0/24) as set forth in operation 720. Thereafter, a BGP advertisement to the tenant resources is generated to include the contents of the messaging, including the virtual VPC CIDR (operation 730) Otherwise, if no network address overlapping condition, a BGP advertisement to the tenant is generated to include the contents of the messaging, including the real VPC CIDR (operation 740).
  • the cloud platform 100 constituting a software-defined cloud overlay network with routing programmability based on messaging by the controller 190 over a control plane 800 is shown.
  • the cloud platform 100 may overlay infrastructure associated with multiple, different public cloud networks such as infrastructure associated with a first public cloud network 810, a second public cloud network 820, and a third public cloud network 830.
  • Each of these public cloud networks 810, 820, 830 are supported by different cloud providers such as Amazon (AWS), Microsoft (Azure) and Google (Google Cloud) for example.
  • AWS Amazon
  • Azure Microsoft
  • Google Cloud Google Cloud
  • the cloud platform 100 may be configured to provide resources located within one or more on-premises networks with connectivity to enhanced cloud services. These resources may include multi-tenant resources, such as the first tenant (Tl) resources 130, the second tenant (T2) resources 132, and/or the third tenant (T3) resources 134 as shown. These multi-tenant resources may feature computing devices, routers for connectivity to certain cloud components, or the like.
  • the cloud platform 100 includes one or more spoke VPCs 840, which are configured for communications with the tenant resources 130/132/134.
  • each of the spoke VPCs 840 may operate in a manner similar to Spokel VPC 142 and/or Spoke2 VPC 143 of FIG.
  • Network 1 may be configured to communicate with the network traffic filtering system 150 operating within the network controller 190 to detect network address overlapping conditions, such as when a network address (e.g., real subnet IP address) within a control plane message 850, received from the T1 tenant resource 130 supported by spoke VPC 840 overlaying a portion of the infrastructure associated with the first public cloud network 810, overlaps a specific network address or specific network (IP) address range utilized by any of the cloud components 840, 842, 844 of the cloud platform 100 or a specific network address range utilized by another tenant resource.
  • a network address e.g., real subnet IP address
  • IP IP
  • the network traffic filtering system 150 may be configured to access the Class Inter-Domain Routing (CIDR) representation of a real subnet IP address 855 of the T1 resources 130 (referred to as “real VPC CIDR 855”) from the BGP advertisement 850 to determine whether the real VPC CIDR 855 overlaps a CIDR-representation of a subnet IP address range assigned to the Spokel VPC 142 implemented as part of the cloud platform 100 and/or a CIDR-representation of a subnet IP address ranges assigned to other cloud components such as transit VPC(s) 842 and shared services VPC 844 that include or are accessible to data stores to
  • BGP Border Gateway Protocol
  • the network traffic filtering system 150 is configured to attempt to detect a network address overlapping condition by at least conducting analytics on one or more control plane messages (e.g., control plane message 850) input into the cloud platform 100.
  • These analytics may include conducting a review of the content of the first mapped NAT 860, being the mapped NAT associated with the Spokel VPC 142 within the cloud platform 110 overlaying infrastructure associated with the first public cloud network 810 to determine whether the real VPC CIDR 855 overlaps (i) a real subnet IP address utilized by any of the cloud components 105 within the cloud platform 100 (included in the first mapped NAT 860) and/or (ii) a real subnet IP address utilized by a tenant resource other than the hosted tenant resource (e.g., T2/T3 resource 132/134).
  • the network traffic filtering system 150 is configured to perform a network address translation by programming routing data stores associated with a routing path utilizes by the first tenant resources 130 (e.g., gateway routing data stores 845 of the Spokel VPC 142, gateway routing data stores for transit VPC 842 and shared services 844 with the portion of the cloud platform 100 overlaying infrastructure of the first public cloud network 810) to substitute the real VPC CIDR 855 for the T1 resources 130 to a virtual VPC CIDR 875.
  • the first tenant resources 130 e.g., gateway routing data stores 845 of the Spokel VPC 142, gateway routing data stores for transit VPC 842 and shared services 844 with the portion of the cloud platform 100 overlaying infrastructure of the first public cloud network 810
  • controller 190 may be desirous for the controller 190 to program other gateway routing data stores associated with spoke VPC(s) 840, transit VPC(s) 842, and/or shared services VPC(s) 844 within a portion of the cloud platform 100 overlaying infrastructure of the second public cloud network 820 to substitute the real VPC CIDR 855 associated with the T1 resources 130 to the virtual VPC CIDR 875.
  • controller 190 may be desirous for the controller 190 to program other gateway routing data stores associated with spoke VPC(s) 840 and/or shared services VPC(s) 844 within a portion of the cloud platform 100 overlaying infrastructure of the third public cloud network 830 to substitute the real VPC CIDR 855 associated with the T1 resources 130 to the virtual VPC CIDR 875.

Abstract

Un système de filtre de trafic de réseau fonctionne pour détecter des conditions de chevauchement d'adresses de réseau et, en réponse, empêcher une propagation continue sur une plateforme en nuage. Mis en œuvre à l'aide d'un dispositif de commande, le système de filtre de trafic de réseau est configuré pour déterminer si un message entrant est associé à une condition de chevauchement d'adresse de réseau. Cette condition est détectée lorsque le message entrant reçu d'une première ressource locataire comprend une adresse de sous-réseau qui chevauche une adresse de sous-réseau sur laquelle repose (a) un composant de la plateforme en nuage ou (b) un composant associé à une seconde ressource locataire différente de la première ressource locataire. Lors de la détection de l'état de chevauchement d'adresse de réseau, le système de filtre de trafic de réseau signale à une passerelle, étant un composant en nuage en communication avec la première ressource locataire, soit pour empêcher des messages associés à l'adresse de sous-réseau d'être acheminés sur la plateforme en nuage soit pour remplacer l'adresse de sous-réseau par une adresse de sous-réseau virtuel de non chevauchement.
PCT/US2022/051387 2021-12-01 2022-11-30 Système et procédé de filtrage et de modification basé sur un nuage de messages avec des adresses de chevauchement WO2023102036A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202117539540A 2021-12-01 2021-12-01
US17/539,540 2021-12-01

Publications (1)

Publication Number Publication Date
WO2023102036A1 true WO2023102036A1 (fr) 2023-06-08

Family

ID=86613036

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2022/051387 WO2023102036A1 (fr) 2021-12-01 2022-11-30 Système et procédé de filtrage et de modification basé sur un nuage de messages avec des adresses de chevauchement

Country Status (1)

Country Link
WO (1) WO2023102036A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030145104A1 (en) * 2002-01-23 2003-07-31 International Business Machines Corporation Virtual private network and tunnel gateway with multiple overlapping, remote subnets
US8259571B1 (en) * 2010-03-26 2012-09-04 Zscaler, Inc. Handling overlapping IP addresses in multi-tenant architecture
US20150381493A1 (en) * 2014-06-30 2015-12-31 Juniper Networks, Inc. Service chaining across multiple networks
US10826723B1 (en) * 2018-02-23 2020-11-03 Amazon Technologies, Inc. Virtual network address space auto-migration
US10897417B2 (en) * 2018-09-19 2021-01-19 Amazon Technologies, Inc. Automated route propagation among networks attached to scalable virtual traffic hubs

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030145104A1 (en) * 2002-01-23 2003-07-31 International Business Machines Corporation Virtual private network and tunnel gateway with multiple overlapping, remote subnets
US8259571B1 (en) * 2010-03-26 2012-09-04 Zscaler, Inc. Handling overlapping IP addresses in multi-tenant architecture
US20150381493A1 (en) * 2014-06-30 2015-12-31 Juniper Networks, Inc. Service chaining across multiple networks
US10826723B1 (en) * 2018-02-23 2020-11-03 Amazon Technologies, Inc. Virtual network address space auto-migration
US10897417B2 (en) * 2018-09-19 2021-01-19 Amazon Technologies, Inc. Automated route propagation among networks attached to scalable virtual traffic hubs

Similar Documents

Publication Publication Date Title
US10469442B2 (en) Adaptive resolution of domain name requests in virtual private cloud network environments
US11563681B2 (en) Managing communications using alternative packet addressing
US11658936B2 (en) Resizing virtual private networks in provider network environments
CN109155799B (zh) 经由层三通信的子网扩展
US10491466B1 (en) Intelligent use of peering in public cloud
CN112640369B (zh) 在公共云中智能地使用对等的方法、设备和机器可读介质
US20190319914A1 (en) Source-dependent address resolution
US20190190885A1 (en) Data network address sharing
CN111698338B (zh) 一种数据传输的方法和计算机系统
US10862796B1 (en) Flow policies for virtual networks in provider network environments
EP2913985A1 (fr) Sélection de services réseaux basée sur le nom de l'hôte
US10326710B1 (en) Propagating access rules on virtual networks in provider network environments
US11943223B1 (en) System and method for restricting communications between virtual private cloud networks through security domains
US10862709B1 (en) Conditional flow policy rules for packet flows in provider network environments
WO2023102036A1 (fr) Système et procédé de filtrage et de modification basé sur un nuage de messages avec des adresses de chevauchement
WO2023102058A1 (fr) Filtrage de trafic et modification d'adresse basés sur un contrôleur
US11916883B1 (en) System and method for segmenting transit capabilities within a multi-cloud architecture
US11757826B1 (en) Securely publishing applications from private networks
WO2023069393A1 (fr) Réseau de recouvrement global à nuages multiples ayant une préférence régionale
CN114301913B (zh) 一种请求处理方法及系统
US11831511B1 (en) Enforcing network policies in heterogeneous systems
WO2022147152A1 (fr) Réseau de gestion et procédé de fonctionnement
WO2023069392A1 (fr) Gestion privée de réseau superposé multi-nuage
EP4331200A2 (fr) Système, classificateur et procédé de gestion de trafic reposant sur une politique de réseau de flux de données
WO2024049905A1 (fr) Dispositif de commande pour coordonner la séparation de flux de communications intra-vpc ou inter-vpc

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: 22902123

Country of ref document: EP

Kind code of ref document: A1