Asymmetric hub and spoke overlay network

By using BGP large community string encoding and transmitting network routing information in hub and spoke overlay networks, directly sending data packets to remote spoke nodes, solving the problem of additional hops in data transmission, improving transmission efficiency and resource utilization .

CN119183651APending Publication Date: 2024-12-24CISCO TECHNOLOGY INC
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202380039886.8
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Priority Date
2022-07-08
Filing Date
2023-07-07
Publication Date
2024-12-24

AI Technical Summary

Technical Problem

In hub and spoke overlay networks, data transmission needs to be optimized to reduce the number of hops, and prior art is difficult to effectively encode and route network routing information to eliminate additional hops.

Method used

By using Border Gateway Protocol (BGP) large community strings to encode and transmit network routing information, the hub node decodes, stores and forwards this information to directly send data packets to remote spoke nodes, eliminating unnecessary network hops.

Benefits of technology

It realizes more efficient data transmission in a multi-site computing resource network, reduces network hop count, improves data transmission efficiency, and maintains computing and network resources.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119183651A_ABST
    Figure CN119183651A_ABST
Patent Text Reader

Abstract

Techniques for a hub node configured in a site of a hub and spoke overlay network to receive, store and / or forward network routing information associated with spokes, and to send packets directly to the spoke (s) remote from the hub node. A first hub node may receive a network advertisement from a local first spoke of the first hub node that includes a border gateway protocol (BGP) large community string. The first hub node may send the BGP large community string to a second hub node remote from the first hub node. The second hub node may decode the network routing information from the BGP large community string and store the network routing information locally. The second hub node may send the packet directly from a local second spoke of the second hub node to the first spoke without routing the data packet via the first hub node.
Need to check novelty before this filing date? Find Prior Art

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. Patent Application No. 17 / 860,926, filed on July 8, 2022, the entire contents of which are incorporated herein by reference. Technical Field

[0003] The present disclosure generally relates to embedding addresses into metadata associated with spoke routing of a hub and spoke overlay network. Background Art

[0004] Service providers provide computing-based services or solutions to provide users with access to computing resources to meet the users' needs for computing resources without having to invent and maintain the computing infrastructure required to implement these services. These service providers typically maintain a network of data centers that house servers, routers, and other devices that provide computing resources (e.g., computing resources, networking resources, storage resources, database resources, application resources, security resources, etc.) to users. The solutions provided by service providers can include a wide range of services that can be fine-tuned to meet the needs of users. In addition, in a cloud-native environment (e.g., in a hub and spoke network), for example, transmitting data from one endpoint to another may require several hops to traverse such a mesh network without losing destination and / or source address information. Although there may be mechanisms to successfully transmit data between two endpoints, these data transmissions need to be optimized. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] The detailed description is set forth below with reference to the accompanying drawings. In the drawings, the leftmost digit(s) of a reference number identifies the drawing in which the reference number first appears. The use of the same reference number in different drawings indicates similar or identical items. The systems depicted in the drawings are not drawn to scale, and the components in the drawings may not be drawn to scale with respect to each other.

[0006] Figure 1A A system architecture diagram of an example flow of a multi-site computing resource network (e.g., a hub and spoke overlay network) is shown, which includes a first hub node in a first site that receives Border Gateway Protocol (BGP) announcement packets from a local spoke and forwards the BGP announcement packets to a second hub node in a second site remote from the first site.

[0007] Figure 1BA system architecture diagram showing an example flow of a multi-site computing resource network including a first hub node in a first site having local spokes connected thereto, the first hub node sending data packets from a source node of the local spoke directly to a destination node of a remote spoke connected to a second hub node in a second site.

[0008] Figure 2 An example Border Gateway Protocol (BGP) large community is shown that includes three 4-byte segments indicating a tenant virtual network instance (VNI), an encoded VNI type of a spoke, and / or an address of a tunnel endpoint associated with an originating spoke.

[0009] Figure 3 A flow chart illustrating an example method for a first hub node of a hub and spoke overlay network to receive a Border Gateway Protocol (BGP) advertisement packet from a local spoke and forward the BGP advertisement packet to a second hub node remote from the first hub node in the hub and spoke overlay network.

[0010] Figure 4 A flow chart illustrating an example method for a first hub node of a hub and spoke overlay network to send a data packet from a source node of a first spoke local to the first hub node directly to a destination node of a second spoke connected to a second hub node and remote from the first hub node.

[0011] Figure 5 A computing system diagram is shown that illustrates the configuration of a data center that can be used to implement aspects of the technology disclosed herein.

[0012] Figure 6 is a computer architecture diagram showing an illustrative computer hardware architecture for implementing a server device that can be used to implement aspects of the various techniques presented herein. DETAILED DESCRIPTION

[0013] Overview

[0014] Various aspects of the invention are set out in the independent claims and preferred features are set out in the dependent claims. Features of one aspect may be applicable to each aspect alone or in combination with the other aspects.

[0015] The present disclosure describes a method (or methods) for advertising network routing configurations, embedding spoke addresses as metadata associated with spoke routing, and routing network data in a hub and spoke overlay network using virtual network instance (VNI) labels (e.g., multi-protocol label switching (MPLS) labels, virtual extensible local area network (VXLAN) labels, generic network virtualization encapsulation (GENEVE) labels, etc.). The method includes: receiving a network advertisement from a first spoke of a hub and spoke network at a first hub node of the hub and spoke network, the network advertisement including a first Border Gateway Protocol (BGP) large community associated with a first tenant node of the first spoke, wherein the first spoke is associated with the first hub node. Additionally or alternatively, the method includes: decoding a first indication of a first virtual network instance (VNI) type associated with the first spoke from a first portion of the first BGP large community. Additionally or alternatively, the method includes: decoding a first address of a first tunnel endpoint associated with the first spoke from a second portion of the first BGP large community. Additionally or alternatively, the method includes: storing a mapping between the first VNI type and the first address of the first tunnel endpoint in a database associated with the first hub node. Additionally or alternatively, the method includes: sending a first BGP announcement packet from the first hub node to one or more second hub nodes of the hub and spoke network, wherein the one or more second hub nodes are associated with one or more corresponding spokes of the hub and spoke network.

[0016] Additionally or alternatively, the method includes: receiving, at a first hub node of a hub and spoke network, a network advertisement from a second hub node associated with the hub and spoke network, the network advertisement including a first Border Gateway Protocol (BGP) large community associated with a first tenant node of a first spoke of the hub and spoke network, wherein the first hub node is remote from the second hub node and the first spoke is associated with the second hub node. Additionally or alternatively, the method includes: decoding, from a first portion of the first BGP large community, a first indication of a first virtual network instance (VNI) type associated with the first spoke. Additionally or alternatively, the method includes: decoding, from a second portion of the first BGP large community, a first address of a first tunnel endpoint associated with the first spoke. Additionally or alternatively, the method includes: storing, in a database associated with the first hub node, a first mapping between the first VNI type and the first address of the first tunnel endpoint. Additionally or alternatively, the method includes: receiving, at the first hub node, a data packet to be transmitted to the first tenant node from a second spoke of the hub-and-spoke network, wherein the second spoke is associated with the first hub. Additionally or alternatively, the method includes: sending the data packet from the first hub node to the first spoke based at least in part on the first mapping.

[0017] Additionally, the techniques described herein may be performed by a system and / or device having a non-transitory computer-readable medium storing computer-executable instructions that, when executed by one or more processors, perform the methods described above.

[0018] Example Embodiments

[0019] Overlay networks can utilize various techniques to encapsulate data packets and allow for multi-tenant configurations of overlay networks, such as hub and spoke overlay networks. Hub nodes of a hub and spoke overlay network can be configured to communicate network traffic directly with other hub nodes, while spokes may be unaware of the network topology and can be configured to communicate with specific local hub nodes of specific spokes (e.g., hub nodes in the same network site as the spokes) to facilitate the transmission of network traffic. Thus, for any spoke-to-spoke communication in a hub and spoke network, data packets can be transmitted from a first spoke (e.g., a source spoke) deployed in a first network site to at least a first hub node in the first network site. In some instances where a source spoke and a destination spoke associated with a spoke-to-spoke communication are deployed in the same site (e.g., the first network site), the first hub node can transmit the data packet directly to a second spoke (e.g., the destination spoke). However, in examples where the source spoke and destination spoke associated with spoke-to-spoke communication are deployed in separate sites (e.g., a first spoke in a first site and a second spoke in a second site), data transmission may require additional hops to traverse the network. For example, a first hub node may be configured to transmit data packets to a second hub node deployed in a second site, where the second hub node may transmit the data packets to a second spoke in the second site. Return traffic may be transmitted from the second spoke to the second hub, from the second hub to the first hub, and from the first hub to the first spoke through the hub and spoke network in a similar manner.

[0020] The present disclosure describes techniques for a hub node configured in a network site of a multi-site computing resource network (e.g., a hub and spoke overlay network) to receive, store and / or forward network routing information associated with a spoke and to send network communications directly to (one or more) spokes remote from a given hub node. In some examples, a first hub node of a hub and spoke network configured to transmit network traffic associated with a first spoke configured in the first network site can receive a network announcement from the first spoke. The first hub node can be configured to decode the network routing information from a Border Gateway Protocol (BGP) large community string associated with the network announcement, and can store the network routing information in a database associated with the first hub node. In some examples, the first hub node can be configured to further announce the network routing information to additional hub nodes in the hub and spoke network. For example, a first hub node may send network routing information and / or BGP large community strings to a second hub node configured in a second site of a hub and spoke network, wherein the second hub node may store the network routing information in a database associated with the second hub node. Additionally or alternatively, the second hub node may receive a packet from a source tenant node configured in a second spoke associated with the second network site, the packet to be transmitted to a destination tenant node configured in the first spoke. In some examples, the packet may include an inner header and / or an outer header, the inner header including next hop information of a destination tenant node configured in the spoke network, the outer header including next hop information of a given spoke node of the hub and spoke overlay network. The second hub node may receive a data packet from the second spoke and identify network routing information associated with the first spoke that was previously stored in the database. The second hub node can be configured to utilize network routing information associated with the first spoke and send data packets directly to the first spoke without intervention by the first hub node (e.g., without routing the data packets via a hop from the second hub node to the first hub node).

[0021] The network routing information may be received as a network advertisement. In some examples, the network advertisement may be configured as a data packet, a network advertisement packet (e.g., a Border Gateway Protocol (BGP) advertisement packet), and / or an application programming interface (API) call (e.g., a Representative State Transfer (REST) ​​API call that includes details of configuring a given spoke network with a computing resource network). Additionally or alternatively, the network advertisement may include a BGP large community string encoded with various network routing information. The BGP large community string may include various portions encoded with information, such as a first 4-byte portion encoded with a tenant virtual network instance (VNI) associated with a tenant node configured in the spoke network, a second 4-byte portion encoded with an indication of a VNI type associated with the spoke network, and / or a third 4-byte portion encoded with an address associated with the spoke network (e.g., an Internet Protocol (IP) address associated with the spoke network and / or a tunnel endpoint associated with the spoke network).

[0022] In some examples, when a spoke and / or a tenant node configured in a spoke is connected to a site of a hub and spoke network (e.g., goes online), the spoke may transmit network routing information associated with the spoke and / or tenant node to a hub node configured in the same site of the hub and spoke network (e.g., a local hub node of the spoke). For example, one or more routing devices associated with a given spoke network may receive a tenant VNI for a given tenant node in the spoke network, and may encode a first 4-byte portion of a BGP large community string with the tenant VNI. In some examples, the tenant VNI may be received from a hub node locally configured in a given spoke and / or from a database storing the tenant VNI. The tenant VNI may be configured as a VNI label for tenant traffic, e.g., MPLS, VXLAN, GENEVE, and / or any other network overlay protocol. Additionally or alternatively, one or more routing devices may encode the second 4-byte portion of the BGP large community string with an indication of the VNI type of a given spoke (e.g., MPLS, VXLAN, GENEVE, and / or any other network overlay protocol). Additionally or alternatively, one or more routing devices may encode the third 4-byte portion of the BGP large community string with an identifier of an IP version 4 (IPv4) address and / or an IP version 6 (IPv6) address of a network tunnel endpoint associated with a given spoke (or one or more routing devices configured in a given spoke network). In an example where the network tunnel endpoint is an IPv6 address, the IPv6 address may be mapped to a 4-byte identifier. In such an example, a given hub node may be configured to perform a lookup using the 4-byte identifier to determine the IPv6 address of the tunnel endpoint based on the VNI type included in the second portion of the BGP large community string, the second portion indicating that the VNI type of the given spoke is a VNI configured for IPv6 routing.

[0023] The hub node can be configured to decode network routing information from various parts of the BGP large community string. In some examples, when decoding the network routing information, the hub node can be configured to, unless otherwise specified, assume that the IP address included in the third part of the BGP large community string is an IPv4 address. The hub node can be configured to determine such an indication by decoding the second part of the BGP large community and determining that the tunnel endpoint associated with a given spoke is an IPv6 address based at least in part on the VNI type. In such an example, the hub node can then perform a lookup based on the 4-byte identifier encoded in the third part of the BGP large community string (instead of the IPv4 address) to determine the IPv6 address associated with the tunnel endpoint of the given spoke network.

[0024] Additionally or alternatively, the hub node may be configured to store network routing information associated with a given spoke and / or a given tenant of a given spoke as a mapping between a tenant VNI, an indication of a VNI type for a given spoke, and / or an address associated with a spoke network. In some examples, the mapping may include only an indication of a VNI type for a given spoke and an address associated with a spoke network. By storing network routing information in this manner, the hub node may be configured to send a data packet from a source node configured in a local first spoke of the hub node (e.g., configured in the same network site) directly to a second spoke that is remote from the hub node and hosts a destination node associated with the packet. For example, the hub node may identify the tenant VNI associated with the destination node, the VNI type associated with the second spoke, and the address associated with the spoke network based on the mapping, and use the network routing information to send the data packet directly to the second spoke, thereby eliminating an additional network hop by sending the data packet to a remote hub node associated with the second spoke as previously described.

[0025] As previously described, a hub node associated with a hub and spoke network can be configured to advertise network routing information received from a given spoke to each additional hub node in the hub and spoke network. By configuring each hub node to forward the advertisements to each hub node in the hub and spoke network, each hub in the network can be configured to read and / or decode the BGP large community string for each route and learn the VNI type and / or IP address of a given spoke for the route prefix.

[0026] As described herein, computing-based, cloud-based solutions, hub nodes, and / or spoke networks may generally include any type of resource implemented by virtualization technology, such as containers, virtual machines, virtual storage, and the like. In addition, although these techniques are described as being implemented in a data center and / or cloud computing network, these techniques are generally applicable to any network of devices managed by any entity that provides virtual resources. In some instances, these techniques may be performed by a scheduler or commander, and in other examples, various components may be used in a system to perform the techniques described herein. The devices and components that perform the techniques herein depend on the implementation, and the techniques described are not limited to any particular architecture or implementation.

[0027] The techniques described herein provide various improvements and efficiencies regarding the use of BGP large community strings in a multi-site network with a multi-tenant overlay to more efficiently encode network routing information and route network data. For example, the techniques described herein may allow a hub node in a hub-and-spoke overlay network to share network routing information associated with spokes and / or tenants that are locally configured in a given hub node (e.g., configured in the same site of the hub-and-spoke overlay network) with other hub nodes that are remote from the spokes and / or tenants. By encoding network routing information specific to a given spoke and / or tenant node into a BGP large community string associated with a packet, a local hub node can decode the network routing information, locally store the network routing information, and forward the network routing information to a remote hub node in a hub and spoke network, thereby allowing the remote hub node to read the BGP large community string for each route and learn the network-specific information required to route the packet directly to a given remote spoke (e.g., the VNI associated with the remote spoke, and / or the address of the remote spoke and / or the tunnel endpoint associated with the remote spoke). In addition, by announcing the network routing information associated with the local spoke to the remote hub node, a hub node disposed in a network site away from a given spoke of a hub and spoke coverage network can be configured to send packets directly to the given spoke without intervention by a remote hub node associated with the given spoke (e.g., without sending the packet to the remote hub node). In this way, by sending data packets from a hub node in a first site directly to a spoke in a second site remote from the hub node, additional hops in routing the packets may be eliminated and computing and / or network resources may be preserved.

[0028] Certain implementations and embodiments of the present disclosure will now be described more fully below with reference to the accompanying drawings, in which various aspects are shown. However, various aspects can be implemented in many different forms and should not be construed as being limited to the implementations set forth herein. As described herein, the present disclosure encompasses variations of the embodiments. Similar reference numerals refer to similar elements throughout.

[0029] Figure 1A and Figure 1BA system architecture diagram 100 is shown for an example flow for a multi-site computing resource network 102 that includes one or more network sites 104, wherein the one or more network sites 104 include corresponding hub nodes 106, corresponding spokes 108 and / or corresponding data stores 110, wherein the hub node 106 can be configured to announce to other hub nodes 106 in the network 102 (one or more) BGP announcement packets including network routing information received from the corresponding local spoke 108 of the given hub node 106, wherein the network routing information can be stored in the corresponding data store 110 and used to send packets from the given hub node 106 directly to the spoke 108 that is remote from the given hub node 106.

[0030] Figure 1A An example flow and example system architecture diagram 100 is shown of a computing resource network 102 (e.g., a hub and spoke overlay network) that includes at least a first hub node 106(A) configured in a first site 104(A), the first hub node 106(A) receiving a Border Gateway Protocol (BGP) advertisement packet from a local spoke 108(3) and forwarding the BGP advertisement packet to a second hub node 106(B) configured in a second site 104(B) remote from the first site 104(A).

[0031] The computing resource network 102 may include one or more data centers, one or more data centers including various networking components, such as network controllers and / or network switches (also referred to as nodes) operating on physical servers. In some examples, (one or more) physical servers may host one or more virtual machines. Each virtual machine may be configured to perform one of various operations and act as one or more virtual components of the computing resource network 102, such as computing-based resources. In some examples, (one or more) physical servers may host any number of virtual machines. In some examples, (one or more) physical servers in the computing resource network 102 may host various network components of the computing resource network 102, such as hub nodes 106, spokes 108 (1) to (N), spoke networks 112 (1) to (N), and / or one or more tenant nodes 114 (1) to (N), where N may be any integer greater than 1.

[0032] Each spoke 108 can provide the hub node 106 at a given site 104 with access to a spoke network 112 hosting one or more tenant nodes 114. For example, a first hub node 106(A) configured in a first site 104(A) of a computing resource network 102 can be configured to route network traffic associated with a first spoke 108(1) and / or a second spoke 108(2) configured in the first site 104(A), e.g., network traffic originating from and / or destined for one or more tenant nodes 114(1), 114(2) hosted in one or more spoke networks 112(1), 112(2). Additionally or alternatively, a second hub node 106(B) disposed in a second site 104(B) of the computing resource network 102 may be configured to route network traffic associated with a third spoke 108(3) and / or a fourth spoke 108(4) disposed in the second site 104(B), for example, network traffic originating from and / or destined for one or more tenant nodes 114(3), 114(4) hosted in one or more spoke networks 112(3), 112(4). Additionally or alternatively, the first hub node 106(A), the second hub node 106(B), and / or one or more third hub nodes 106(N) may be communicatively coupled such that they are configured to send network traffic to a given hub node 106, which is configured to route the network traffic to a destination spoke 110 disposed in the same network site as the given hub node 106.

[0033] Additionally or alternatively, each site 104 may provide one or more services 116 implemented by a hub node 106 configured in a given site 104. In some examples, the one or more services 116 may include a deep packet inspection (DPI) service, a cloud delivery firewall (CDFW) service, a network address translation (NAT) service, a secure web gateway (SWG) service, a domain name service (DNS) layer security service, and / or a cloud access security broker (CASB) service.

[0034] Take, for example, a computing resource network 102 configured as a hub and spoke overlay multi-protocol label switching (MPLS) network. As previously described, hub node A 106(A) may be configured to route network traffic associated with one or more spokes 108(1), 108(2) disposed in network site A 104(A), and / or hub node B 106(B) may be configured to route network traffic associated with one or more spokes 108(3), 108(4) disposed in network site B 104(B). That is, network traffic is received at hub node A 106(A) and routed to a spoke 108 connected to a spoke network 112 hosting a destination tenant node 114, the network traffic going to one or more tenant nodes 114(1), 114(2) hosted in corresponding spoke networks 112(1), 112(2) connected to hub node A 106(A) via spokes 108(1), 108(2) configured in site A 104(A), and from one or more tenant nodes 114(3) to 114(N) hosted in corresponding spoke networks 112(3) to 112(N) and connected to corresponding hub nodes 106(B), 106(N) via spokes 108(3) to 108(N). In other words, network traffic originating from site B 104 (B) and destined for site A 104 (A) is routed through the hub and spoke coverage network based on a first hop from the originating spokes 108(3), 108(4) to hub node B 106(B), a second hop from hub node B 106(B) to hub node A 106(A), and a third hop from hub node A 106(A) to destination spokes 108(1), 108(2). However, by configuring the networking devices associated with the spokes 108 to encode a Border Gateway Protocol (BGP) large community string with network routing information associated with the spokes 108 and / or tenant nodes 114, the hub node 106 can utilize the network routing information to send packets directly to a remote spoke (e.g., from hub node A 106 (A) to spoke 108 (3)), thereby eliminating the need to route network traffic across network sites in the hub and spoke overlay network using three network hops.

[0035] For example, a hub node A 106(A) disposed in a network site A 104(A) and configured to transmit network traffic associated with a first spoke 108(1) may receive a network advertisement from the first spoke 108(1). In some examples, the network advertisement may be configured as a data packet, a BGP advertisement packet, and / or an application programming interface (API) call, for example, a representational state transfer (REST) ​​API call including details of configuring a given spoke network 112 with a computing resource network 102. Additionally or alternatively, the network advertisement may include a BGP large community string. Additionally or alternatively, the packet may be configured as a data packet including the BGP large community string. The hub node A 106(A) may be configured to decode network routing information from the BGP large community string associated with the packet, and may store the network routing information in a site A database 110(A) disposed in site A 104(A). In some examples, the hub node A 106(A) may be configured to further advertise network routing information to additional hub nodes in the hub and spoke network, such as hub node B 106(B) and / or one or more hub nodes N 106(N). For example, the hub node A 106(A) may send the network routing information and / or BGP large community strings to the hub node B 106(B) disposed in the site B 104(B) of the hub and spoke network, where the hub node B 106(B) may decode the network routing information and / or store the network routing information in a site B database 110(B) disposed in the site B 104(B). Additionally or alternatively, hub node B 106(B) may receive a packet from a source tenant node 114(3) hosted in a spoke network 112(3) connected to a second spoke 108(3) configured in site B 104(B) for transmission to a destination tenant node 114(1) hosted in a spoke network 112(1) connected to the first spoke 108(1). In some examples, the packet may include an inner header including next hop information for the destination tenant node 114(1) configured in the spoke network 112(1) and / or an outer header including next hop information for a given spoke node 108(1) of the hub and spoke overlay network 102. The hub node B 106(B) may receive the data packet from the second spoke 108(3) and identify the network routing information associated with the first spoke 108(1) previously stored in the site B database 110(B).Hub node B 106(B) can be configured to utilize network routing information associated with the first spoke 108(1) and send data packets directly to the first spoke 108(1) without intervention by hub node A 106(A) (e.g., without routing the data packets via an additional hop from hub node B 106(B) to hub node A 106(A)).

[0036] The network routing information may be received as a data packet and / or a network advertisement packet, such as a Border Gateway Protocol (BGP) advertisement packet, that includes a BGP large community string encoded with various network routing information. The BGP large community string may include various portions encoded with the information, such as a first 4-byte portion encoded with a tenant VNI associated with a tenant node 114 configured in a spoke network 112, a second 4-byte portion encoded with an indication of a virtual network instance (VNI) type associated with a spoke 108 and / or spoke network 112, and / or a third 4-byte portion encoded with an address associated with a spoke 108 and / or spoke network 112 (e.g., an Internet Protocol (IP) address associated with the spoke network and / or a tunnel endpoint associated with the spoke network).

[0037] In some examples, when a spoke 108 and / or tenant node 114 configured in a spoke network 112 is connected to a site 104 of a hub and spoke network (e.g., comes online), the spoke 108 can transmit network routing information associated with the spoke 108 and / or tenant node 114 to a hub node 106 configured in the same site 104 of the hub and spoke network (e.g., hub node A 104(A) and spoke 108(1)). For example, one or more routing devices associated with a given spoke network 112 can receive the tenant VNI of a given tenant node 114 in the spoke network and can encode the first 4-byte portion of the BGP large community string with the tenant VNI. In some examples, the tenant VNI can be received from a hub node 106 locally configured in a given spoke 108 and / or from a database storing the tenant VNI. The tenant VNI may be configured as a VNI label for tenant traffic, e.g., MPLS, VXLAN, GENEVE, and / or any other network overlay protocol. Additionally or alternatively, one or more routing devices may encode a second 4-byte portion of the BGP large community string with an indication of the VNI type of a given spoke 108 (e.g., MPLS, VXLAN, GENEVE, and / or any other network overlay protocol). Additionally or alternatively, one or more routing devices may encode a third 4-byte portion of the BGP large community string with an identifier of an IP version 4 (IPv4) address and / or an IP version 6 (IPv6) address of a network tunnel endpoint associated with a given spoke 108 (or one or more routing devices configured in a given spoke network 112). In an example where the network tunnel endpoint is an IPv6 address, the IPv6 address may be mapped to a 4-byte identifier. In such an example, a given hub node 106 can be configured to perform a lookup using a 4-byte identifier to determine the IPv6 address of the tunnel endpoint based on the VNI type included in the second portion of the BGP large community string, which second portion indicates that the VNI type of the given spoke 108 is a VNI configured for IPv6 routing.

[0038] The hub node 106 may be configured to decode network routing information from various portions of the BGP large community string. In some examples, when decoding the network routing information, the hub node 106 may be configured to, unless otherwise specified, assume that the IP address included in the third portion of the BGP large community string is an IPv4 address. The hub node 106 may be configured to determine such an indication by decoding the second portion of the BGP large community and determining that the tunnel endpoint associated with a given spoke 108 is an IPv6 address based at least in part on the VNI type. In such an example, the hub node 106 may then perform a lookup based on the 4-byte identifier (instead of the IPv4 address) encoded in the third portion of the BGP large community string to determine the IPv6 address associated with the tunnel endpoint of the given spoke network 112.

[0039] Additionally or alternatively, the hub node 106 may be configured to store network routing information associated with a given spoke 108 and / or a given tenant 114 of a given spoke 108 as a mapping between the tenant VNI, an indication of the VNI type of the given spoke 108, and / or an address associated with the spoke 108. Additionally or alternatively, the mapping may include only the indication of the VNI type of the given spoke 108 and the address associated with the spoke 108. By storing network routing information in this manner, the hub node 106(A) may be configured to send a data packet from a source node 114(1) configured in a first spoke 108(1) directly to a second spoke 108(3) that is remote from the hub node 106(A) and that hosts a destination node 114(3) associated with the packet. For example, the hub node 106(A) can identify the tenant VNI associated with the destination node 114(3), the VNI type associated with the second spoke 108(3), and the address associated with the second spoke 108(3) based on the mapping, and use the network routing information to send the data packet directly to the second spoke 108(3), thereby eliminating an additional network hop by sending the data packet to the hub node 106(B) associated with the second spoke 108(3) as previously described.

[0040] At "1", hub node A 106(A) disposed in network site A 104(A) and configured to transmit network traffic associated with first spoke 108(1) may receive a network advertisement from first spoke 108(1). In some examples, the network advertisement may be configured as a data packet, a BGP advertisement packet, and / or an application programming interface (API) call, for example, a representational state transfer (REST) ​​API call including details of configuring a given spoke network 112 with computing resource network 102. Additionally or alternatively, the network advertisement may include a BGP large community string. The BGP large community string may include various portions encoded with this information, such as a first 4-byte portion encoded with a tenant VNI associated with a tenant node 114(1) configured in the first spoke network 112(1), a second 4-byte portion encoded with an indication of a virtual network instance (VNI) type associated with the first spoke 108(1) and / or the first spoke network 112(1), and / or a third 4-byte portion encoded with an address associated with the first spoke 108(1) and / or the first spoke network 112(1) (e.g., an Internet Protocol (IP) address associated with the first spoke network 112(1) and / or a tunnel endpoint associated with the first spoke network 112(1)).

[0041] At "2", the hub node A 106(A) may decode network routing information from the various portions of the BGP large community string. In some examples, when decoding the network routing information, the hub node A 106(A) may be configured to assume that the IP address included in the third portion of the BGP large community string is an IPv4 address unless otherwise indicated. The hub node A 106(A) may be configured to determine such an indication by decoding the second portion of the BGP large community and determining, based at least in part on the VNI type, that the tunnel endpoint associated with the first spoke 108(1) is an IPv6 address. In such an example, the hub node A 106(A) may then perform a lookup based on the 4-byte identifier encoded in the third portion of the BGP large community string (instead of the IPv4 address) to determine the IPv6 address associated with the tunnel endpoint of the first spoke network 112(1).

[0042] At "3", hub node A 106(A) may be configured to store network routing information associated with the first spoke 108(1) and / or a tenant node 114(1) configured in the first spoke 108(1) as a mapping between a tenant VNI, an indication of a VNI type of the first spoke 108(1), and / or an address associated with the first spoke 108(1). Additionally or alternatively, the mapping may include only an indication of a VNI type of the first spoke 108(1) and an address associated with the first spoke 108(1).

[0043] At "4", hub node A 106(A) may be configured to further advertise network routing information to additional hub nodes in the hub and spoke network (e.g., hub node B 106(B) and / or one or more hub nodes N 106(N)). For example, hub node A 106(A) may send network routing information and / or BGP large community strings to hub node B 106(B) configured in site B 104(B) of the hub and spoke network.

[0044] In some examples, the example stream can be obtained from Figure 1A Continue to step "4" Figure 1B Additionally or alternatively, Figure 1A An example stream can be written with Figure 1B The example streams are executed concurrently.

[0045] Figure 1B An example flow and example system architecture diagram 100 is shown of a computing resource network 102 (e.g., a hub and spoke overlay network) that includes at least a first hub node 106(A) configured in a first site 104(A) and a second hub node 106(B) configured in a second site 104(B) having local spokes 108(3), 108(4) connected to the second hub node 106(B), the second hub node 106(B) sending data packets from a source node 114(3), 114(4) of one of the local spokes 108(3), 108(4) directly to a destination node 114(1), 114(2) of a remote spoke 108(1), 108(2) connected to the first hub node 106(A) in the first site 104(A).

[0046] The computing resource network 102 may include one or more data centers, one or more data centers including various networking components, such as network controllers and / or network switches (also referred to as nodes) operating on physical servers. In some examples, (one or more) physical servers may host one or more virtual machines. Each virtual machine may be configured to perform one of various operations and act as one or more virtual components of the computing resource network 102, such as computing-based resources. In some examples, (one or more) physical servers may host any number of virtual machines. In some examples, (one or more) physical servers in the computing resource network 102 may host various network components of the computing resource network 102, such as hub nodes 106, spokes 108 (1) to (N), spoke networks 112 (1) to (N), and / or one or more tenant nodes 114 (1) to (N), where N may be any integer greater than 1.

[0047] Each spoke 108 can provide the hub node 106 at a given site 104 with access to a spoke network 112 hosting one or more tenant nodes 114. For example, a first hub node 106(A) configured in a first site 104(A) of a computing resource network 102 can be configured to route network traffic associated with a first spoke 108(1) and / or a second spoke 108(2) configured in the first site 104(A), e.g., network traffic originating from and / or destined for one or more tenant nodes 114(1), 114(2) hosted in one or more spoke networks 112(1), 112(2). Additionally or alternatively, a second hub node 106(B) disposed in a second site 104(B) of the computing resource network 102 may be configured to route network traffic associated with a third spoke 108(3) and / or a fourth spoke 108(4) disposed in the second site 104(B), for example, network traffic originating from and / or destined for one or more tenant nodes 114(3), 114(4) hosted in one or more spoke networks 112(3), 112(4). Additionally or alternatively, the first hub node 106(A), the second hub node 106(B), and / or one or more third hub nodes 106(N) may be communicatively coupled such that they are configured to send network traffic to a given hub node 106, which is configured to route the network traffic to a destination spoke 110 disposed in the same network site as the given hub node 106.

[0048] Additionally or alternatively, each site 104 may provide one or more services 116 implemented by a hub node 106 configured in a given site 104. In some examples, the one or more services 116 may include a deep packet inspection (DPI) service, a cloud delivery firewall (CDFW) service, a network address translation (NAT) service, a secure web gateway (SWG) service, a domain name service (DNS) layer security service, and / or a cloud access security broker (CASB) service.

[0049] Take, for example, a computing resource network 102 configured as a hub and spoke overlay multi-protocol label switching (MPLS) network. As previously described, hub node A 106(A) may be configured to route network traffic associated with one or more spokes 108(1), 108(2) disposed in network site A 104(A), and / or hub node B 106(B) may be configured to route network traffic associated with one or more spokes 108(3), 108(4) disposed in network site B 104(B). That is, network traffic is received at hub node A 106(A) and routed to a spoke 108 connected to a spoke network 112 hosting a destination tenant node 114, the network traffic going to one or more tenant nodes 114(1), 114(2) hosted in corresponding spoke networks 112(1), 112(2) connected to hub node A 106(A) via spokes 108(1), 108(2) configured in site A 104(A), and from one or more tenant nodes 114(3) to 114(N) hosted in corresponding spoke networks 112(3) to 112(N) and connected to corresponding hub nodes 106(B), 106(N) via spokes 108(3) to 108(N). In other words, network traffic originating from site B 104 (B) and destined for site A 104 (A) is routed through the hub and spoke coverage network based on a first hop from the originating spokes 108(3), 108(4) to hub node B 106(B), a second hop from hub node B 106(B) to hub node A 106(A), and a third hop from hub node A 106(A) to destination spokes 108(1), 108(2). However, by configuring the networking devices associated with the spokes 108 to encode a Border Gateway Protocol (BGP) large community string with network routing information associated with the spokes 108 and / or tenant nodes 114, the hub node 106 can utilize the network routing information to send packets directly to a remote spoke (e.g., from hub node A 106 (A) to spoke 108 (3)), thereby eliminating the need to route network traffic across network sites in the hub and spoke overlay network using three network hops.

[0050] At "5", hub node B 106(B) may receive a network advertisement from hub node A 106(A). In some examples, the network advertisement may be configured as a data packet, a BGP advertisement packet, and / or an application programming interface (API) call, for example, a representational state transfer (REST) ​​API call including details of configuring a given spoke network 112 with the computing resource network 102. Additionally or alternatively, the network advertisement may include a BGP large community string. The BGP large community string may include various portions encoded with this information, such as a first 4-byte portion encoded with a tenant VNI associated with a tenant node 114(1) configured in the first spoke network 112(1), a second 4-byte portion encoded with an indication of a virtual network instance (VNI) type associated with the first spoke 108(1) and / or the first spoke network 112(1), and / or a third 4-byte portion encoded with an address associated with the first spoke 108(1) and / or the first spoke network 112(1) (e.g., an Internet Protocol (IP) address associated with the first spoke network 112(1) and / or a tunnel endpoint associated with the first spoke network 112(1)).

[0051] At "6", the hub node B 106(B) may decode network routing information from the various portions of the BGP large community string. In some examples, when decoding the network routing information, the hub node B 106(B) may be configured to assume that the IP address included in the third portion of the BGP large community string is an IPv4 address unless otherwise indicated. The hub node B 106(B) may be configured to determine such an indication by decoding the second portion of the BGP large community and determining, based at least in part on the VNI type, that the tunnel endpoint associated with the first spoke 108(1) is an IPv6 address. In such an example, the hub node B 106(B) may then perform a lookup based on the 4-byte identifier encoded in the third portion of the BGP large community string (instead of the IPv4 address) to determine the IPv6 address associated with the tunnel endpoint of the first spoke network 112(1).

[0052] At "7", the hub node B 106(B) can be configured to store network routing information associated with the first spoke 108(1) and / or the tenant node 114(1) configured in the first spoke 108(1) as a mapping between the tenant VNI, an indication of the VNI type of the first spoke 108(1), and / or an address associated with the first spoke 108(1). Additionally or alternatively, the mapping can include only the indication of the VNI type of the first spoke 108(1) and the address associated with the first spoke 108(1).

[0053] At "8", the hub node B 106(B) may receive a packet from a source tenant node 114(4) hosted in a spoke network 112(4) connected to a second spoke 108(4) disposed in site B 104(B) for transmission to a destination tenant node 114(1) hosted in a spoke network 112(1) connected to a first spoke 108(1). The packet may include an inner header including next hop information for the destination tenant node 114(1) disposed in the spoke network 112(1) and / or an outer header including next hop information for a given spoke 108(1) of the hub and spoke overlay network 102. The hub node B 106(B) may receive the data packet from the second spoke 108(4) and identify network routing information associated with the first spoke 108(1) previously stored in the site B database 110(B).

[0054] At "9", hub node B 106(B) can be configured to utilize network routing information associated with the first spoke 108(1) and send the data packet directly to the first spoke 108(1) without intervention by hub node A 106(A) (e.g., without routing the data packet via an additional hop from hub node B 106(B) to hub node A 106(A)). For example, hub node B 106(B) can identify the tenant VNI associated with destination node 114(1), the VNI type associated with the first spoke 108(1), and / or the address associated with the first spoke 108(1) based on a mapping stored in site B data store 110(B), and utilize the network routing information to send the data packet directly to the first spoke 108(1), thereby eliminating the additional network hop by sending the data packet to hub node A 106(A) associated with the first spoke 108(1) as previously described.

[0055] Figure 2 An example Border Gateway Protocol (BGP) large community string 200 is shown that includes a first 4-byte portion 202, a second 4-byte portion 204, and / or a third 4-byte portion 206. In some examples, portions 202, 204, and / or 206 of the BGP large community string 200 can indicate an encoded tenant VNI 208 associated with a tenant node provisioned in a spoke network, an encoded VNI type and / or VNI associated with a spoke 210, and / or an encoded Internet Protocol (IP) address 212 associated with the spoke.

[0056] As reference Figure 1A and Figure 1BAs described, one or more routing devices associated with a given spoke network may receive a tenant VNI of a given tenant node in the spoke network, and may encode the first 4-byte portion of the BGP large community string with the tenant VNI. The tenant VNI may be configured as a VNI label for tenant traffic, such as MPLS, VXLAN, GENEVE, and / or any other network overlay protocol. Additionally or alternatively, the first 4-byte portion may be configured as a reserved 4-byte portion of the BGP large community string. Additionally or alternatively, one or more routing devices may encode the second 4-byte portion of the BGP large community string with an indication of the VNI type of a given spoke (e.g., MPLS, VXLAN, GENEVE, and / or any other network overlay protocol). Additionally or alternatively, one or more routing devices may encode the third 4-byte portion of the BGP large community string with an identifier of an IP version 4 (IPv4) address and / or an IP version 6 (IPv6) address of a network tunnel endpoint associated with a given spoke (or one or more routing devices configured in a given spoke network). In the example where the network tunnel endpoint is an IPv6 address, the IPv6 address can be mapped to a 4-byte identifier. By encoding the network routing information into the BGP large community string in this manner, a given hub node can be configured to perform a lookup using the 4-byte identifier to determine the IPv6 address of the tunnel endpoint based on the VNI type included in the second portion of the BGP large community string, which second portion indicates that the VNI type of the given spoke is a VNI configured for IPv6 routing.

[0057] Figure 3 and Figure 4 Flowcharts of example methods 300 and 400 are shown, and examples of methods that are at least partially Figure 1A and Figure 1B Various aspects of the functions performed by the computing resource network 102, the hub node(s) 106, the spoke(s) 108, the site database(s) 110, and / or the spoke network(s) 112 described in. Figure 3 and Figure 4 The described logical operations may be implemented as (1) a sequence of computer-implemented actions or program modules running on a computing system and / or (2) interconnected machine logic circuits or circuit modules within a computing system. In some examples, method(s) 300 and / or 400 may be performed by a system including one or more processors and one or more non-transitory computer-readable media storing computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform method(s) 300 and / or 400.

[0058] The implementation of the various components described herein is selected based on the performance and other requirements of the computing system. Accordingly, the logical operations described herein are variously referred to as operations, structural devices, actions, or modules. These operations, structural devices, actions, and modules can be implemented in software, firmware, dedicated digital logic, and any combination thereof. It should also be understood that more than one operation can be performed. Figure 3 and Figure 4 , and more or less operations as shown in and described in this article. These operations may also be performed in parallel, or in an order different from that described herein. Some or all of these operations may also be performed by components other than those specifically identified. Although the techniques described in this disclosure refer to specific components, in other examples, these techniques may be implemented by fewer components, more components, different components, or any configuration of components.

[0059] Figure 3 A flowchart of an example method 300 is shown for a first hub node configured in a first site of a computing resource network (e.g., a hub and spoke overlay network) to receive a Border Gateway Protocol (BGP) advertisement packet from a local spoke and forward the BGP advertisement packet to a second hub node configured in a second site remote from the first site. In some examples, the computing resource network, the first site, the second site, the first hub node, the second hub node, and / or the local spoke may be configured as reference nodes, respectively. Figure 1A Depicted computing resource network 102, site A 104 (A), site B 104 (B), hub node A 106 (A), hub node B 106 (B), and / or first spoke 108 (1).

[0060] At 302, method 300 includes receiving, at a first hub node of the hub and spoke network, a first network advertisement from a first spoke of the hub and spoke network, the first network advertisement including a first Border Gateway Protocol (BGP) large community associated with a first tenant node of the first spoke. In some examples, the first spoke can be associated with the first hub node such that the first hub node is configured to route network traffic to and / or from the first spoke. Additionally or alternatively, the BGP large community can be configured to reference Figure 2 Describes the BGP large community string 200.

[0061] At 304, method 300 includes: decoding a first indication of a first virtual network instance (VNI) type associated with a first spoke from a first portion of a first BGP large community. In some examples, the first hub node can be configured to decode a first indication of a first VNI type associated with the first spoke from the first BGP large community. Additionally or alternatively, the first indication and / or the first portion of the first VNI type can correspond to a reference Figure 2 The encoded VNI and / or second portion 204 of the spoke 210 are depicted.

[0062] At 306, method 300 includes: decoding a first address of a first tunnel endpoint associated with the first spoke from the second portion of the first BGP large community. In some examples, the first hub node can be configured to decode the first address of the first tunnel endpoint associated with the first spoke from the first BGP large community. Additionally or alternatively, the first address and / or the second portion of the first tunnel endpoint can correspond to a reference Figure 2 The encoded IP address and / or third portion 206 of the spoke 212 is described.

[0063] At 308, method 300 includes storing a mapping between the first VNI type and / or the first address of the first tunnel endpoint. In some examples, the mapping may be stored in a database associated with the first hub node.

[0064] At 310, method 300 includes sending a first network advertisement from a first hub node of a hub and spoke network to one or more second hub nodes. In some examples, the one or more second hub nodes may be associated with one or more respective spokes of the hub and spoke network.

[0065] In some examples, the first address of the first tunnel endpoint can be an Internet Protocol version 4 (IPv4) address.

[0066] In some examples, the first address of the first tunnel endpoint can include an indication of an Internet Protocol version 6 (IPv6) address. In some examples, the IPv6 address can be mapped to a 4-byte identifier (e.g., an indication). Additionally or alternatively, the first hub node can be configured to perform a lookup using the 4-byte identifier to determine the IPv6 address of the first tunnel endpoint based on a VNI type included in a second portion of the BGP large community, wherein the second portion indicates that the VNI type of the first spoke is a VNI configured for IPv6 routing.

[0067] In an example where the network tunnel endpoint is an IPv6 address, in such an example, a given hub node 106 can be configured to perform a lookup using a 4-byte identifier to determine the IPv6 address of the tunnel endpoint based on the VNI type included in a second portion of the BGP large community string, where the second portion indicates that the VNI type of the given spoke 108 is a VNI configured for IPv6 routing.

[0068] Additionally or alternatively, method 300 includes: receiving a second BGP announcement packet at a first hub node from a second hub node of one or more second hub nodes, the second BGP announcement packet including a second BGP large community associated with a second tenant node of a second spoke of the hub and spoke network. In some examples, the second spoke can be associated with a second hub node so that the second hub node can be configured to route network traffic to the second spoke and / or route network traffic from the second spoke. Additionally or alternatively, method 300 includes: decoding a second indication of a second VNI type associated with the second spoke from a first portion of the second BGP large community. Additionally or alternatively, method 300 includes: decoding a second address of a second tunnel endpoint associated with the second spoke from a second portion of the second BGP large community. Additionally or alternatively, method 300 includes: storing a second mapping between the second VNI type and the second address of the second tunnel endpoint in a database associated with the first hub node. Additionally or alternatively, the method 300 includes receiving, at the first hub node, from the first spoke a data packet to be transmitted to the second tenant node. Additionally or alternatively, the method 300 includes sending the data packet from the first hub node to the second spoke based at least in part on the second mapping.

[0069] Additionally or alternatively, the method 300 includes receiving, at the second spoke, a second data packet from the first hub node.

[0070] In some examples, the second hub node can be configured to transmit network traffic associated with the second spoke and / or data packets can be sent directly from the first hub node to the second spoke.

[0071] Figure 4A flowchart of an example method 400 of a first hub node configured in a first site of a computing resource network (e.g., a hub and spoke overlay network) is shown, wherein the first hub node has a local spoke connected thereto, the first hub node receives a Border Gateway Protocol (BGP) advertisement packet from a second hub node configured in a second site of the network, and sends a data packet from a source node of one of (one or more) local spokes directly to a destination node of a remote spoke connected to the second hub node in the second site. In some examples, the first hub node and / or the first site may be configured as a reference, respectively. Figure 1B Additionally or alternatively, a second hub node and / or a second site may be configured as a reference node. Figure 1B The hub node A 106 (A) and / or site B 104 (B) are depicted. Additionally or alternatively, the computing resource network and / or local spokes may be configured as reference nodes, respectively. Figure 1B A computing resource network 102 and / or spokes 108(3), 108(4) are depicted.

[0072] At 402, method 400 includes receiving, at a first hub node of a hub and spoke network, a first Border Gateway Protocol (BGP) advertisement packet from a second hub node associated with the hub and spoke network. In some examples, the first BGP advertisement packet may include a first BGP large community associated with a first tenant node of a first spoke of the hub and spoke network. Additionally or alternatively, the first hub node may be remote from the second hub node and / or the first spoke may be associated with the second hub node. Additionally or alternatively, the BGP large community may be configured to reference Figure 2 Describes the BGP large community string 200.

[0073] At 404, method 400 includes: decoding a first indication of a first VNI type associated with a first spoke from a first portion of a first BGP large community. In some examples, the first hub node can be configured to decode a first indication of a first VNI type associated with the first spoke from the first BGP large community. Additionally or alternatively, the first indication and / or the first portion of the first VNI type can correspond to a reference Figure 2 The encoded VNI and / or second portion 204 of the spoke 210 are depicted.

[0074] At 406, method 400 includes: decoding a first address of a first tunnel endpoint associated with the first spoke from the second portion of the first BGP large community. In some examples, the first hub node can be configured to decode the first address of the first tunnel endpoint associated with the first spoke from the first BGP large community. Additionally or alternatively, the first address and / or the second portion of the first tunnel endpoint can correspond to a reference Figure 2 The encoded IP address and / or third portion 206 of the spoke 212 is described.

[0075] At 408, method 400 includes storing a first mapping between the first VNI type and / or the first address of the first tunnel endpoint. In some examples, the mapping may be stored in a database associated with the first hub node.

[0076] At 410, method 400 includes receiving, at a first hub node, a data packet to be transmitted to a first tenant node from a second spoke of a hub and spoke network. In some examples, the second spoke can be associated with the first hub such that the first hub can be configured to route network traffic to and / or from the second spoke. In some examples, the packet can include an inner header including next hop information of a destination tenant node configured in the spoke network and / or an outer header including next hop information of a given spoke node of the hub and spoke overlay network.

[0077] At 412, method 400 includes sending the data packet from the first hub node to the first spoke. In some examples, sending the data packet from the first hub node to the first spoke can be based at least in part on the first mapping.

[0078] In some examples, the first address of the first tunnel endpoint can be an Internet Protocol version 4 (IPv4) address.

[0079] In some examples, the first address of the first tunnel endpoint can include an indication of an Internet Protocol version 6 (IPv6) address. In some examples, the IPv6 address can be mapped to a 4-byte identifier (e.g., an indication). Additionally or alternatively, the first hub node can be configured to perform a lookup using the 4-byte identifier to determine the IPv6 address of the first tunnel endpoint based on a VNI type included in the second portion of the BGP large community, the VNI type indicating that the VNI type of the first spoke is a VNI configured for IPv6 routing.

[0080] In some examples, the second hub node can be configured to transmit network traffic associated with the first spoke and / or data packets can be sent directly from the first hub node to the first spoke.

[0081] In some examples, the first hub node can be configured to transmit network traffic associated with the second spoke. Additionally or alternatively, method 400 includes: receiving a second BGP announcement packet from the second spoke at the first hub node, the second BGP announcement packet including a second BGP large community associated with the second tenant node. Additionally or alternatively, method 400 includes: decoding a second indication of a second VNI type associated with the second spoke from a first portion of the second BGP large community. Additionally or alternatively, method 400 includes: decoding a second address of a second tunnel endpoint associated with the second spoke from a second portion of the second BGP large community. Additionally or alternatively, method 400 includes: storing a second mapping between the second VNI type and the second address of the second tunnel endpoint in a database associated with the first hub node. Additionally or alternatively, method 400 includes: sending a second BGP announcement packet from the first hub node to the second hub node.

[0082] In some examples, the data packet may be a first data packet. Additionally or alternatively, method 400 may include receiving, at a second spoke, a second data packet from a second hub node.

[0083] Additionally or alternatively, method 400 may include sending a second BGP advertisement packet from the first hub node to one or more third hub nodes associated with the hub and spoke network.

[0084] In some examples, the hub and spoke network can be an overlay network.

[0085] Figure 5 is a computing system diagram illustrating a configuration of a data center 500 that can be used to implement aspects of the technology disclosed herein. Figure 5 The illustrated example data center 500 includes several server computers 502A-502E (which may be referred to herein as "a server computer 502" in the singular or "server computers 502" in the plural) for providing computing resources. In some examples, the server computers 502 may include or correspond to servers associated with the data center 104 described herein with reference to FIG. 1.

[0086] The server computer 502 can be a standard tower, rack or blade server computer that is appropriately configured to provide the computing resources described herein. As described above, the computing resources provided by the computing resource network 102 can be data processing resources, such as VM instances or hardware computing systems, database clusters, computing clusters, storage clusters, data storage resources, database resources, networking resources. Some servers 502 can also be configured to execute resource managers that can instantiate and / or manage computing resources. For example, in the case of VM instances, the resource manager can be a hypervisor or another type of program that is configured to execute multiple VM instances on a single server computer 502. The server computers 502 in the data center 500 can also be configured to provide network services and other types of services.

[0087] exist Figure 5 In the example data center 500 shown, an appropriate LAN 508 is also utilized to interconnect the server computers 502A to 502E. It should be understood that the configuration and network topology described herein have been greatly simplified, and that more computing systems, software components, networks, and networking devices may be utilized to interconnect the various computing systems disclosed herein and provide the above-described functionality. Appropriate load balancing devices or other types of network infrastructure components may also be utilized to balance the load between the data centers 500, between each server computer 502A to 502E in each data center 500, and potentially between the computing resources in each server computer 502. It should be understood that reference to Figure 5 The described configuration of data center 500 is illustrative only, and other implementations may be used.

[0088] In some examples, server computers 502 may each execute a hub node 106 , one or more spokes 108 , one or more data stores 110 , and / or one or more services 116 .

[0089] In some instances, computing resource network 102 may provide computing resources, such as application containers, VM instances, and storage, on a permanent or on-demand basis. Among other types of functionality, the computing resources provided by computing resource network 102 may be used to implement the various services described above. The computing resources provided by computing resource network 102 may include various types of computing resources, such as data processing resources (e.g., application containers and VM instances), data storage resources, networking resources, data communication resources, network services, and the like.

[0090] Each type of computing resource provided by computing resource network 102 may be general purpose or may be available in a number of specific configurations. For example, data processing resources may be used as physical computers or VM instances in a variety of different configurations. VM instances may be configured to execute applications including web servers, application servers, media servers, database servers, some or all of the above network services, and / or other types of programs. Data storage resources may include file storage devices, block storage devices, etc. Computing resource network 102 may also be configured to provide other types of computing resources not specifically mentioned herein.

[0091] In one embodiment, the computing resources provided by the computing resource network 102 may be enabled by one or more data centers 500 (which may be referred to herein as "a data center 500" in the singular or "data centers 500" in the plural). A data center 500 is a facility for housing and operating computer systems and related components. A data center 500 typically includes redundant and backup power, communications, cooling, and security systems. Data centers 500 may also be located in geographically different locations. Figure 6 One illustrative embodiment of a data center 500 that can be used to implement the techniques disclosed herein is described.

[0092] Figure 6 An example computer architecture is shown for a computing device (or network routing device) 502 capable of executing program components for implementing the functionality described above. Figure 6 The computer architecture shown illustrates a conventional server computer, workstation, desktop computer, laptop computer, tablet computer, web appliance, e-reader, smart phone, and / or other computing device, and can be used to execute any software components presented herein. In some examples, computing device 502 can correspond to the computer described herein with reference to Figure 1A and / or Figure 1B Describes the physical servers in a data center.

[0093] The computing device 502 includes a baseboard 602, or "motherboard," which is a printed circuit board to which many components or devices may be connected by way of a system bus or other electrical communication paths. In one illustrative configuration, one or more central processing units ("CPUs") 604 operate in conjunction with a chipset 606. The CPU 604 may be a standard programmable processor that performs the arithmetic and logic operations necessary for the operation of the computing device 502.

[0094] The CPU 604 performs operations by transitioning from one discrete physical state to the next, where the state transitions are achieved by manipulating switching elements that distinguish and change these states. Switching elements generally include electronic circuits that maintain one of two binary states, such as flip-flops, and electronic circuits that provide output states based on logical combinations of the states of one or more other switching elements, such as logic gates. These basic switching elements can be combined to create more complex logic circuits, including registers, adders and subtractors, arithmetic logic units, floating point units, etc.

[0095] Chipset 606 provides an interface between CPU 604 and the remaining components and devices on baseboard 602. Chipset 606 may provide an interface with RAM 608, which is used as main memory in computing device 502. Chipset 606 may further provide an interface with a computer-readable storage medium, such as read-only memory (ROM) 610 or non-volatile RAM (NVRAM), for storing basic routines that help boot computing device 502 and transfer information between various components and devices. ROM 610 or NVRAM may also store other software components necessary for the operation of computing device 502 according to the configuration described herein.

[0096] The computing device 502 can operate in a networked environment, using logical connections to remote computing devices and computer systems through a network, such as network 626. Chipset 606 can include functionality for providing network connectivity through NIC 612, such as a Gigabit Ethernet adapter. NIC 612 can connect the computing device 502 to other computing devices through network 626. It should be understood that multiple NICs 612 can be present in the computing device 502, connecting the computer to other types of networks and remote computer systems.

[0097] The computing device 502 can be connected to a storage device 618 that provides non-volatile storage for the computing device 502. The storage device 618 can store an operating system 620, a program 622, and data, which have been described in more detail herein. The storage device 618 can be connected to the computing device 502 via a storage controller 614 connected to the chipset 606. The storage device 618 can be composed of one or more physical storage units. The storage controller 614 can be connected to the physical storage unit via a serial attached SCSI (serial attached SCSI, "SAS") interface, a serial advanced technology attachment (serial advanced technology attachment, "SATA") interface, a fiber channel (fiber channel, "FC") interface, or other types of interfaces for physically connecting and transmitting data between a computer and a physical storage unit.

[0098] The computing device 502 may store data on the storage device 618 by transforming the physical state of the physical storage unit to reflect the information being stored. In different embodiments of the present specification, the specific transformation of the physical state may depend on various factors. Examples of such factors may include, but are not limited to, the technology used to implement the physical storage unit, whether the storage device 618 is characterized as primary storage or secondary storage, etc.

[0099] For example, the computing device 502 can store information to the storage device 618 by issuing instructions through the storage controller 614 to change the magnetic properties of a specific location in the disk drive unit, the reflective or refractive properties of a specific location in the optical storage unit, or the electrical properties of a specific capacitor, transistor, or other discrete component in the solid-state storage unit. Other transformations of the physical medium are possible without departing from the scope and spirit of the present specification, and the foregoing examples are provided only for the convenience of the present specification. The computing device 502 can further read information from the storage device 618 by detecting the physical state or properties of one or more specific locations in the physical storage unit.

[0100] In addition to the mass storage device 618 described above, the computing device 502 may also access other computer-readable storage media to store and retrieve information, such as program modules, data structures, or other data. It should be understood by those skilled in the art that a computer-readable storage medium is any available medium that provides non-transitory storage of data and can be accessed by the computing device 502. In some examples, the operations performed by the computing resource network 102 and / or any components included therein may be supported by one or more devices similar to the computing device 502. In other words, some or all of the operations performed by the computing resource network 102 and / or any components included therein may be performed by one or more computing devices 502 operating in a cloud-based arrangement.

[0101] By way of example, and not limitation, computer-readable storage media may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology. Computer-readable storage media include, but are not limited to, RAM, ROM, erasable programmable ROM ("EPROM"), electrically-erasable programmable ROM ("EEPROM"), flash memory or other solid-state memory technology, compact disc ROM ("CD-ROM"), digital versatile disk ("DVD"), high definition DVD ("HD-DVD"), BLU-RAY or other optical storage, cassettes, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information in a non-transitory manner.

[0102] As briefly mentioned above, the storage device 618 may store an operating system 620 that is utilized to control the operation of the computing device 502. According to one embodiment, the operating system comprises a LINUX operating system. According to another embodiment, the operating system comprises an LINUX operating system from MICROSOFT Corporation of Redmond, Washington. SERVER operating system. According to another embodiment, the operating system may include a UNIX operating system or one of its variants. It should be understood that other operating systems may also be used. Storage device 618 may store other systems or applications and data utilized by computing device 502.

[0103] In one embodiment, the storage device 618 or other computer-readable storage medium is encoded with computer-executable instructions that, when loaded into the computing device 502, transform the computer from a general-purpose computing system into a special-purpose computer capable of implementing the embodiments described herein. As described above, these computer-executable instructions transform the computing device 502 by specifying how the CPU 604 transitions between states. According to one embodiment, the computing device 502 can access a computer-readable storage medium storing computer-executable instructions that, when executed by the computing device 502, perform the above-described Figure 1A , Figure 1B , Figure 3 and / or Figure 4 The computing device 502 may also include a computer-readable storage medium having stored thereon instructions for performing any other computer-implemented operations described herein.

[0104] The computing device 502 may also include one or more input / output controllers 616 for receiving and processing input from a number of input devices, such as a keyboard, a mouse, a touch pad, a touch screen, an electronic stylus, or other types of input devices. Similarly, the input / output controller 616 may provide output to a display, such as a computer monitor, a flat panel display, a digital projector, a printer, or other types of output devices. It will be appreciated that the computing device 502 may not include Figure 6 All components shown in the Figure 6 Other components not explicitly shown may be used in conjunction with Figure 6 A completely different architecture is shown in .

[0105] The server computer 502 may support a virtualization layer 624, for example, one or more components associated with the computing resource network 102 (e.g., the hub node 106, the service(s) 116, the spoke(s) 108, and / or the data store 110. At "1", the first hub node 106 may receive a BGP large community advertisement packet and / or a packet including a BGP large community string from a local first spoke of the first hub node. The first hub node 106 may decode network routing information from various portions of the BGP large community string and / or store the network routing information. At "2", the first hub node may forward the packet including the BGP large community string to a second spoke remote from the first hub node 106. The second hub node 106 may be a hub node 106 (e.g., configured in a network site separate from the first hub node 106). The second hub node 106 may decode network routing information from portions of the BGP large community string and / or store the network routing information in a data store 110 associated with the second hub node 106. At "3", the second hub node 106 may receive a data packet from a local second spoke 108 of the second hub node 106, and the second hub node 106 may send the data packet from the second hub node 106 directly to the first spoke 108 remote from the second hub node 106 based on the network routing information associated with the first spoke stored in the data store 110 associated with the second hub node 106.

[0106] In summary, techniques are described for a hub node configured in a site of a hub and spoke overlay network to receive, store and / or forward network routing information associated with a spoke, and to send packets directly to (one or more) spokes remote from the hub node. A first hub node may receive a network announcement including a Border Gateway Protocol (BGP) large community string from a local first spoke of the first hub node. The first hub node may send the BGP large community string to a second hub node remote from the first hub node. The second hub node may decode the network routing information from the BGP large community string and store the network routing information locally. The second hub node may send packets from a local second spoke of the second hub node directly to the first spoke without the data packets being routed via the first hub node.

[0107] Although the present invention is described with respect to specific embodiments, it should be understood that the scope of the present invention is not limited to these specific embodiments. Because other modifications and changes that change to adapt to specific operating requirements and environments are obvious to those skilled in the art, the present invention is not considered to be limited to the examples selected for the purpose of disclosure, but includes all changes and modifications that do not constitute a deviation from the true spirit and scope of the present invention.

[0108] Although the present application describes embodiments with specific structural features and / or method actions, it should be understood that the claims are not necessarily limited to the specific features or actions described. Instead, the specific features and actions are merely illustrative of some embodiments falling within the scope of the claims of the present application.

[0109] Sample Clauses

[0110] A: A method comprising: receiving a first network advertisement at a first hub node of a hub and spoke network from a first spoke of the hub and spoke network, the first network advertisement comprising a first Border Gateway Protocol (BGP) large community associated with a first tenant node of the first spoke, wherein the first spoke is associated with the first hub node; decoding a first indication of a first virtual network instance (VNI) type associated with the first spoke from a first portion of the first BGP large community; decoding a first address of a first tunnel endpoint associated with the first spoke from a second portion of the first BGP large community; storing a mapping between the first VNI type and the first address of the first tunnel endpoint in a database associated with the first hub node; and sending the first network advertisement from the first hub node to one or more second hub nodes of the hub and spoke network, wherein the one or more second hub nodes are associated with one or more corresponding spokes of the hub and spoke network.

[0111] B: A method according to paragraph A, wherein the first address of the first tunnel endpoint is an Internet Protocol version D (IPv4) address.

[0112] C: A method according to paragraph A or B, wherein the first address of the first tunnel endpoint includes an indication of an Internet Protocol version F (IPv6) address.

[0113] D: The method according to any of paragraphs A to C also includes: receiving a second network announcement from a second hub node among the one or more second hub nodes at the first hub node, the second network announcement including a second BGP large community associated with a second tenant node of a second spoke of the hub and spoke network, wherein the second spoke is associated with the second hub node; decoding a second indication of a second VNI type associated with the second spoke from a first portion of the second BGP large community; decoding a second address of a second tunnel endpoint associated with the second spoke from a second portion of the second BGP large community; storing a second mapping between the second VNI type and the second address of the second tunnel endpoint in the database associated with the first hub node; receiving a data packet to be transmitted to the second tenant node from the first spoke at the first hub node; and sending the data packet from the first hub node to the second spoke based at least in part on the second mapping.

[0114] E: The method according to paragraph D also includes: receiving the second data packet from the first hub node at the second spoke.

[0115] F: The method of paragraph D or E, wherein the second hub node is configured to transmit network traffic associated with the second spoke, and the data packet is sent directly from the first hub node to the second spoke.

[0116] G: A system comprising: one or more processors; and one or more computer-readable media storing computer-executable instructions, wherein the computer-executable instructions, when executed by the one or more processors, cause the one or more processors to perform operations, the operations comprising: receiving, at a first hub node of a hub-and-spoke network, a first network advertisement from a second hub node associated with the hub-and-spoke network, the first network advertisement comprising a first Border Gateway Protocol (BGP) large community associated with a first tenant node of a first spoke of the hub-and-spoke network, wherein the first hub node is remote from the second hub node and the first spoke is associated with the second hub node; receiving, from the first BG Decoding a first indication of a first virtual network instance (VNI) type associated with the first spoke from a first portion of the BGP large community; decoding a first address of a first tunnel endpoint associated with the first spoke from a second portion of the first BGP large community; storing a first mapping between the first VNI type and the first address of the first tunnel endpoint in a database associated with the first hub node; receiving, at the first hub node, a data packet to be transmitted to the first tenant node from a second spoke of the hub-and-spoke network, wherein the second spoke is associated with the first hub; and sending the data packet from the first hub node to the first spoke based at least in part on the first mapping.

[0117] H: A system according to paragraph G, wherein the first address of the first tunnel endpoint is an Internet Protocol version D (IPv4) address.

[0118] I: A system as described in paragraphs G or H, wherein the first address of the first tunnel endpoint includes an indication of an Internet Protocol version F (IPv6) address.

[0119] J: A system as described in any of paragraphs G to I, wherein the second hub node is configured to transmit network traffic associated with the first spoke, and the data packet is sent directly from the first hub node to the first spoke.

[0120] K: A system according to any of paragraphs G to J, wherein the first hub node is configured to transmit network traffic associated with the second spoke, and the operation also includes: receiving a second network announcement from the second spoke at the first hub node, the second network announcement including a second BGP large community associated with the second tenant node; decoding a second indication of a second VNI type associated with the second spoke from a first part of the second BGP large community; decoding a second address of a second tunnel endpoint associated with the second spoke from a second part of the second BGP large community; storing a second mapping between the second VNI type and the second address of the second tunnel endpoint in the database associated with the first hub node; and sending the second network announcement from the first hub node to the second hub node.

[0121] L: The system of paragraph K, wherein the data packet is a first data packet and the operations further comprise: receiving, at the second spoke, a second data packet from the second hub node.

[0122] M: The system of paragraphs K or L, wherein the operations further include sending the second network advertisement from the first hub node to one or more third hub nodes associated with the hub and spoke network.

[0123] N: A system as described in any of paragraphs G to M, wherein the spoke network is an overlay network.

[0124] O: A method comprising: receiving, at a first hub node of a hub and spoke network, a first network advertisement from a second hub node associated with the hub and spoke network, the first network advertisement comprising a first Border Gateway Protocol (BGP) large community associated with a first tenant node of a first spoke of the hub and spoke network, wherein the first hub node is remote from the second hub node and the first spoke is associated with the second hub node; decoding, from a first portion of the first BGP large community, a first indication of a first virtual network instance (VNI) type associated with the first spoke; decoding, from a second portion of the first BGP large community, a first address of a first tunnel endpoint associated with the first spoke; storing in a database associated with the first hub node a first mapping between the first VNI type and the first address of the first tunnel endpoint; receiving, at the first hub node, a data packet to be transmitted to the first tenant node from a second spoke of the hub and spoke network, wherein the second spoke is associated with the first hub; and sending the data packet from the first hub node to the first spoke based at least in part on the first mapping.

[0125] P: A method according to paragraph O, wherein the first address of the first tunnel endpoint is an Internet Protocol version D (IPv4) address.

[0126] Q: A method according to paragraph O or P, wherein the first address of the first tunnel endpoint includes an indication of an Internet Protocol version F (IPv6) address.

[0127] R: A method as described in any of paragraphs O to Q, wherein the second hub node is configured to transmit network traffic associated with the first spoke, and the data packet is sent directly from the first hub node to the first spoke.

[0128] S: A method according to any of paragraphs O to R, wherein the first hub node is configured to transmit network traffic associated with the second spoke, and the method further includes: receiving a second network announcement from the second spoke at the first hub node, the second network announcement including a second BGP large community associated with the second tenant node; decoding a second indication of a second VNI type associated with the second spoke from a first part of the second BGP large community; decoding a second address of a second tunnel endpoint associated with the second spoke from a second part of the second BGP large community; storing a second mapping between the second VNI type and the second address of the second tunnel endpoint in the database associated with the first hub node; and sending the second network announcement from the first hub node to the second hub node.

[0129] T: The method of paragraph S, wherein the data packet is a first data packet, and the method further comprises: receiving a second data packet from the second hub node at the second spoke.

[0130] U: A device comprising: a device for receiving a first network announcement from a first spoke of a hub and spoke network at a first hub node of the hub and spoke network, the first network announcement comprising a first Border Gateway Protocol (BGP) large community associated with a first tenant node of the first spoke, wherein the first spoke is associated with the first hub node; a device for decoding a first indication of a first virtual network instance (VNI) type associated with the first spoke from a first portion of the first BGP large community; a device for decoding a first address of a first tunnel endpoint associated with the first spoke from a second portion of the first BGP large community; a device for storing a mapping between the first VNI type and the first address of the first tunnel endpoint in a database associated with the first hub node; and a device for sending the first network announcement from the first hub node to one or more second hub nodes of the hub and spoke network, wherein the one or more second hub nodes are associated with one or more corresponding spokes of the hub and spoke network.

[0131] V: The device according to paragraph U also includes a device for implementing the method described in any of paragraphs B to F.

[0132] W: A device comprising: a device for receiving, at a first hub node of a hub and spoke network, a first network advertisement from a second hub node associated with the hub and spoke network, the first network advertisement comprising a first Border Gateway Protocol (BGP) large community associated with a first tenant node of a first spoke of the hub and spoke network, wherein the first hub node is remote from the second hub node and the first spoke is associated with the second hub node; a device for decoding, from a first portion of the first BGP large community, a first indication of a first virtual network instance (VNI) type associated with the first spoke; and a device for receiving, from a first portion of the first BGP large community, a first indication of a first virtual network instance (VNI) type associated with the first spoke. means for decoding a first address of a first tunnel endpoint associated with the first spoke from a second portion of the first BGP large community; means for storing a first mapping between the first VNI type and the first address of the first tunnel endpoint in a database associated with the first hub node; means for receiving, at the first hub node, a data packet to be transmitted to the first tenant node from a second spoke of the hub-and-spoke network, wherein the second spoke is associated with the first hub; and means for sending the data packet from the first hub node to the first spoke based at least in part on the first mapping.

[0133] X: The device according to paragraph W also includes a device for implementing the method according to any one of paragraphs P to T.

[0134] Y: A computer program, a computer program product or a computer-readable medium comprising instructions which, when executed by a computer, cause the computer to perform the steps of the method described in any of paragraphs A to F or the steps of the method described in any of paragraphs O to T.

[0135] Although the example clauses described above are described with respect to a specific implementation, it should be understood that in the context of this article, the content of the example clauses can also be implemented via a method, an apparatus, a system, a computer-readable medium, and / or another implementation. In addition, any of Examples A to Y can be implemented alone or in combination with any other one or more of Examples A to Y.

Claims

1. A method comprising: receiving, at a first hub node of a hub-and-spoke network from a first spoke of the hub-and-spoke network, a first network advertisement including a first Border Gateway Protocol (BGP) large community associated with a first tenant node of the first spoke, wherein the first spoke is associated with the first hub node; decoding, from a first portion of the first BGP large community, a first indication of a first virtual network instance (VNI) type associated with the first spoke; decoding a first address of a first tunnel endpoint associated with the first spoke from a second portion of the first BGP large community; storing a mapping between the first VNI type and the first address of the first tunnel endpoint in a database associated with the first hub node; and The first network advertisement is sent from the first hub node to one or more second hub nodes of the hub and spoke network, wherein the one or more second hub nodes are associated with one or more respective spokes of the hub and spoke network.

2. The method according to claim 1, wherein: The first address of the first tunnel endpoint is an Internet Protocol version 4 (IPv4) address.

3. The method according to claim 1 or 2, wherein: The first address of the first tunnel endpoint includes an indication of an Internet Protocol version 6 (IPv6) address.

4. The method according to any one of claims 1 to 3, further comprising: receiving, at the first hub node, from a second hub node of the one or more second hub nodes, a second network advertisement including a second BGP large community associated with a second tenant node of a second spoke of the hub-and-spoke network, wherein the second spoke is associated with the second hub node; decoding, from the first portion of the second BGP larger community, a second indication of a second VNI type associated with the second spoke; decoding a second address of a second tunnel endpoint associated with the second spoke from a second portion of the second BGP larger community; storing a second mapping between the second VNI type and a second address of the second tunnel endpoint in the database associated with the first hub node; receiving, at the first hub node, from the first spoke, a data packet to be transmitted to the second tenant node; and The data packet is sent from the first hub node to the second spoke based at least in part on the second mapping.

5. The method according to claim 4, further comprising: The second data packet is received at the second spoke from the first hub node.

6. The method according to claim 4 or 5, wherein: The second hub node is configured to transmit network traffic associated with the second spoke, and the data packet is sent directly from the first hub node to the second spoke.

7. A system comprising: one or more processors; as well as One or more computer-readable media storing computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform operations comprising: receiving, at a first hub node of a hub and spoke network from a second hub node associated with the hub and spoke network, a first network advertisement including a first Border Gateway Protocol (BGP) large community associated with a first tenant node of a first spoke of the hub and spoke network, wherein the first hub node is remote from the second hub node and the first spoke is associated with the second hub node; decoding, from a first portion of the first BGP large community, a first indication of a first virtual network instance (VNI) type associated with the first spoke; decoding a first address of a first tunnel endpoint associated with the first spoke from a second portion of the first BGP large community; storing a first mapping between the first VNI type and a first address of the first tunnel endpoint in a database associated with the first hub node; receiving, at the first hub node, a data packet to be transmitted to the first tenant node from a second spoke of the hub-and-spoke network, wherein the second spoke is associated with the first hub; and The data packet is sent from the first hub node to the first spoke based at least in part on the first mapping.

8. The system according to claim 7, wherein: The first address of the first tunnel endpoint is an Internet Protocol version 4 (IPv4) address.

9. The system according to claim 7 or 8, wherein: The first address of the first tunnel endpoint includes an indication of an Internet Protocol version 6 (IPv6) address.

10. The system according to any one of claims 7 to 9, wherein: The second hub node is configured to transmit network traffic associated with the first spoke, and the data packet is sent directly from the first hub node to the first spoke.

11. A system according to any one of claims 7 to 10, wherein: The first hub node is configured to transmit network traffic associated with the second spoke, and the operations further include: receiving, at the first hub node, from the second spoke, a second network advertisement including a second BGP large community associated with the second tenant node; decoding, from the first portion of the second BGP larger community, a second indication of a second VNI type associated with the second spoke; decoding a second address of a second tunnel endpoint associated with the second spoke from a second portion of the second BGP larger community; storing a second mapping between the second VNI type and a second address of the second tunnel endpoint in the database associated with the first hub node; and The second network advertisement is sent from the first hub node to the second hub node.

12. The system according to claim 11, wherein: The data packet is a first data packet, and the operations further include receiving, at the second spoke, a second data packet from the second hub node.

13. The system according to claim 11 or 12, wherein: The operations also include sending the second network advertisement from the first hub node to one or more third hub nodes associated with the hub and spoke network.

14. A system according to any one of claims 7 to 13, wherein: The hub and spoke network is an overlay network.

15. A method comprising: receiving, at a first hub node of a hub and spoke network from a second hub node associated with the hub and spoke network, a first network advertisement including a first Border Gateway Protocol (BGP) large community associated with a first tenant node of a first spoke of the hub and spoke network, wherein the first hub node is remote from the second hub node and the first spoke is associated with the second hub node; decoding, from a first portion of the first BGP large community, a first indication of a first virtual network instance (VNI) type associated with the first spoke; decoding a first address of a first tunnel endpoint associated with the first spoke from a second portion of the first BGP large community; storing a first mapping between the first VNI type and a first address of the first tunnel endpoint in a database associated with the first hub node; receiving, at the first hub node, a data packet to be transmitted to the first tenant node from a second spoke of the hub-and-spoke network, wherein the second spoke is associated with the first hub; and The data packet is sent from the first hub node to the first spoke based at least in part on the first mapping.

16. The method according to claim 15, wherein: The first address of the first tunnel endpoint is an Internet Protocol version 4 (IPv4) address.

17. The method according to claim 15 or 16, wherein: The first address of the first tunnel endpoint includes an indication of an Internet Protocol version 6 (IPv6) address.

18. The method according to any one of claims 15 to 17, wherein: The second hub node is configured to transmit network traffic associated with the first spoke, and the data packet is sent directly from the first hub node to the first spoke.

19. The method according to any one of claims 15 to 18, wherein: The first hub node is configured to transmit network traffic associated with the second spoke, and the method further comprises: receiving, at the first hub node, from the second spoke, a second network advertisement including a second BGP large community associated with the second tenant node; decoding, from the first portion of the second BGP larger community, a second indication of a second VNI type associated with the second spoke; decoding a second address of a second tunnel endpoint associated with the second spoke from a second portion of the second BGP larger community; storing a second mapping between the second VNI type and a second address of the second tunnel endpoint in the database associated with the first hub node; and The second network advertisement is sent from the first hub node to the second hub node.

20. The method according to claim 19, wherein: The data packet is a first data packet, and the method further includes receiving, at the second spoke, a second data packet from the second hub node.

21. An apparatus comprising: means for receiving, at a first hub node of a hub and spoke network, from a first spoke of the hub and spoke network, a first network advertisement comprising a first Border Gateway Protocol (BGP) large community associated with a first tenant node of the first spoke, wherein the first spoke is associated with the first hub node; means for decoding, from a first portion of the first BGP large community, a first indication of a first virtual network instance (VNI) type associated with the first spoke; means for decoding a first address of a first tunnel endpoint associated with the first spoke from a second portion of the first BGP large community; means for storing a mapping between the first VNI type and the first address of the first tunnel endpoint in a database associated with the first hub node; and Means for sending the first network advertisement from the first hub node to one or more second hub nodes of the hub and spoke network, wherein the one or more second hub nodes are associated with one or more respective spokes of the hub and spoke network.

22. The apparatus of claim 21, further comprising means for implementing the method of any one of claims 2 to 6.

23. An apparatus comprising: means for receiving, at a first hub node of a hub and spoke network from a second hub node associated with the hub and spoke network, a first network advertisement comprising a first Border Gateway Protocol (BGP) large community associated with a first tenant node of a first spoke of the hub and spoke network, wherein the first hub node is remote from the second hub node and the first spoke is associated with the second hub node; means for decoding, from a first portion of the first BGP large community, a first indication of a first virtual network instance (VNI) type associated with the first spoke; means for decoding a first address of a first tunnel endpoint associated with the first spoke from a second portion of the first BGP large community; means for storing a first mapping between the first VNI type and a first address of the first tunnel endpoint in a database associated with the first hub node; and means for receiving, at the first hub node, from a second spoke of the hub-and-spoke network, a data packet to be transmitted to the first tenant node, wherein the second spoke is associated with the first hub; and means for sending the data packet from the first hub node to the first spoke based at least in part on the first mapping.

24. The apparatus of claim 23, further comprising means for implementing the method of any one of claims 16 to 20.

25. A computer program, a computer program product or a computer readable medium comprising instructions which, when executed by a computer, cause the computer to perform the steps of the method according to any one of claims 1 to 6 or the steps of the method according to any one of claims 15 to 20.