Routing for static border gateway protocol

Abstract

This application relates to routing for static Border Gateway Protocol. A system can determine, for a user with an IP address from a static BGP range, through which paths / tunnels an Internet destination can be best reached. The system looks up the destination address in an egress map. The map can specify a tunnel that should be used to encapsulate the static BGP, or (when a tunnel does not exist) cause the system to emit unencapsulated traffic, where the traffic follows normal BGP routing over the border network.

Description

Technical Field

[0001] This application relates to the field of information and communication, and more specifically to routing for static border gateway protocols. Background Technology

[0002] Telecommunications companies, such as some major telephone companies, charge very high IP relay fees for traffic originating from computer networks, especially for Border Gateway Protocol (BGP) services. However, some telecommunications companies offer two cheaper options for IP connectivity: static routing and a hybrid routing option known as "static BGP." While static routing is significantly cheaper than traditional (or dynamic) BGP relay, its drawback is that services (such as cloud services or data centers) must use IP addresses assigned by each telecommunications company to initiate traffic destined for that company. For example, to send traffic to the first telecommunications company, the service must obtain traffic from its prefix (e.g., 10.100.200.0 / 24), and the service cannot use that prefix to initiate traffic to another telecommunications company. This significantly increases the complexity of the service and is unsuitable if the service's customers or users want to use a single IP address to reach all internet destinations, independent of intermediate telecommunications companies. Summary of the Invention

[0003] According to this application, a computer-executable method for providing static Border Gateway Protocol (BGP) routes is provided, the method comprising: receiving a source IP address; storing the source IP address in a static BGP pool; receiving network reachability data for one or more network destination addresses, wherein the network reachability data includes dynamic BGP data paths for reaching the one or more network destination addresses; receiving tunnel information for one or more tunnels; analyzing the network reachability data and the tunnel information to create a route mapping for using static BGP, wherein the route mapping for using static BGP includes a destination address and a next-hop address; receiving a data packet including the source IP address and a packet destination IP address; when determining that the source IP address is in the static BGP pool, searching in the route mapping for a next-hop address for the packet destination IP address, wherein the next-hop address belongs to a static BGP route; and encapsulating the data packet for transmission through a tunnel in one or more tunnels to the next-hop address.

[0004] According to this application, a computer-readable medium is provided, the computer-readable medium including computer-executable instructions, which, when executed, cause a computing system to perform a method comprising: receiving network reachability data for one or more network destination addresses; and analyzing the network reachability data to create a route mapping for static Border Gateway Protocol (BGP) routing.

[0005] According to this application, a system for providing static Border Gateway Protocol (BGP) routes is provided. The system includes one or more processors configured to: receive a data packet including a source IP address and a destination IP address; look up the source IP address in a list of IP addresses; if the source IP address is determined to be in the list of IP addresses, look up a next-hop address for the destination IP address in a route mapping, wherein the next-hop address belongs to a static BGP route; and encapsulate the data packet for tunneling to the next-hop address. Attached Figure Description

[0006] Figure 1 This is an example system diagram used to provide static BGP routes.

[0007] Figure 2 An example of a data structure for storing route mappings is shown.

[0008] Figure 3 A high-level system diagram depicting the mapping calculator is shown.

[0009] Figure 4 An example flowchart is shown for methods used to create and maintain route mappings.

[0010] Figure 5 A sample flowchart is shown for performing source-plus-destination-based routing in the outbound direction.

[0011] Figure 6 An example flowchart is shown for maintaining tunnel information used to route static BGP traffic data.

[0012] Figure 7 A general example of a suitable computing environment in which the described innovations can be implemented is depicted. Detailed Implementation

[0013] Static routing provides IP address allocation to route prefixes assigned to that IP address on statically configured routes. Static BGP service allows service providers, such as cloud service providers, to allocate their own prefixes, which telecommunications companies can advertise to the service provider over the internet. The telecommunications company statically routes traffic destined for those prefixes to the service provider via the static BGP interface. This allows the service provider's customers or users using the static BGP service to reach any destination from a single IP address while retaining the cost savings associated with static routing. While static BGP service has a lower cost per Mbit compared to traditional BGP (which can also be called standard or dynamic BGP) service, it has a high cost associated with each prefix "advertised" to the telecommunications company. Therefore, in the example, customers or users with low bandwidth utilization per IP address (of the service provider) can continue to use traditional BGP service, where the service provider can advertise a large number of prefixes at low cost per prefix. Static BGP can then be offered to select users with high bandwidth utilization. Users can be "whitelisted" to these new static prefixes and receive IP addresses from them. When a user with an IP address from the static BGP range makes an outbound request, the system can determine which path / tunnel can be used to reach that internet destination. For example, the path could be the most efficient path, including the shortest path, the lowest latency path, the lowest cost, etc. This can be done, for example, by looking up the destination address in an egress mapping. This mapping can specify the tunnel that should be used for encapsulation, or (when a tunnel does not exist) allow the system to issue unencapsulated traffic. The traffic can then follow normal BGP routes on the border network. In some implementations, as described further in detail herein, the system can select the egress communication company and interface (e.g., at the border network) for outbound traffic because there is no dynamic signaling on the static BGP interface. The system can then direct the traffic to the selected interface.

[0014] In some implementations, the system can select outbound traffic paths by parsing BGP data and dynamically place the correct next hop in the routing table.

[0015] In some implementations, where a telecommunications company provides internet relay services to a service provider, the company can accept (outbound) traffic and route it to any destination via a static BGP circuit. In this case, the service provider can assign prefixes to the tunnel endpoints corresponding to that telecommunications company. In the case of multiple telecommunications companies, for example, the prefixes can be assigned in a round-robin fashion. When a telecommunications company withdraws a route from BGP, traffic may continue to be routed to that company. In this case, the telecommunications company can route traffic based on its default route or the route received from its peer.

[0016] Typically, the system can intelligently route user traffic along the best available path, respond to network failures and traffic transfers, and enable traffic engineering. The system can use mapping tools (or calculators) to process BGP data into destination / next-hop entries. These entries can be stored in, for example, mapping tables or routing tables (or egress mappings). Mapping tools can also provide the system with the ability to automatically respond to failures or transfer tunnels.

[0017] In some implementations, the system can provide IP address ranges to telecommunications companies. The telecommunications companies can then publish these prefixes as if the ranges originated from them. This can be published to the Internet via traditional (or dynamic) BGP. In some cases, traffic over these static BGP links is advantageously much less expensive than traffic over traditional (or dynamic) BGP-based links.

[0018] At higher levels, the system may include source-based routing methods. For example, the system may perform source-based routing on egress paths (e.g., from a data center to the public internet). In some implementations, source-based routing may require: (1) source IP addresses registered to a pool of "static BGP IPs", and (2) a list of destination IP prefixes and their next-hop / tunnel IDs. A static BGP IP pool (or static BGP pool) may include a range of IP addresses, such as the / 20 prefix. In the example, the system may store the static BGP pool via a configuration file. Other implementations are also envisioned.

[0019] The size of the destination IP prefix list and its next-hop / tunnel ID information can be much larger than that of the source IP address prefixes, and they change more frequently. For example, there could be hundreds of thousands of IPv4 prefixes, of which tens of thousands could be published by telecommunications companies. Many of these prefixes may change daily (e.g., added or removed). In this example, the system could store the data (prefix, next-hop / tunnel ID) in a database, for example, by streaming the data to a storage area. This information could then be polled periodically.

[0020] In some implementations, the system can encapsulate static BGP traffic destined for IP addresses that match a prefix list, such as encapsulating static BGP traffic destined for IP addresses at the border network. The system can use IP-based encapsulation protocols such as Generic Routing Encapsulation (GRE), IP-in-IP, Layer 2 Tunneling (L2TP), etc. Encapsulation allows intermediate routers in the border network to use static BGP paths. These paths also allow traffic to be routed to static BGP communication routes.

[0021] It should be noted that the system can also support IP addresses that do not belong to the static BGP pool, for example, when no match is found in the prefix list when looking up a destination address. In this case, the system can send data from its forwarded, unencapsulated traffic towards the border network.

[0022] In some implementations, when a link failure occurs, the system can back up the static BGP link with another static BGP link. For example, the system can use an anycast address for the static BGP tunnel endpoint to achieve this. In the example, all circuits assigned to the service provider at the telecommunications company can use the same anycast tunnel endpoint address. When a single circuit fails, the tunnel can be automatically removed from the service, and traffic can be failover to other circuits. In this case, routing table updates at the system level may not be necessary. It should be noted that there can be more than one tunnel per hop.

[0023] When all links to a single telecommunications company (e.g., within a geographical area) become unavailable, traffic can be automatically failover (rerouted) to a backup tunnel endpoint, such as a backup tunnel endpoint on a static BGP link of another telecommunications company. This can be achieved by advertising the other telecommunications company's anycast tunnel endpoint with a higher metric. This way, the backup tunnel endpoint is selected only when no primary tunnel endpoint is available for that anycast address. When there is no backup tunnel to a static BGP link of another telecommunications company, traffic packets can be decapsulated onto a traditional (or dynamic) BGP path.

[0024] In some cases, outbound traffic forwarding may be necessary. Outbound traffic forwarding can be accomplished by disabling the outbound tunnel endpoint on the system (e.g., on the router). Traffic can be automatically forwarded to the next available static BGP endpoint. Traffic forwarding can use the same communication provider, or, when all links with the same provider are down, traffic forwarding can use only an alternative provider as a backup.

[0025] In some implementations, when the system detects service degradation on a single static BGP link of a telecommunications company, but other links to that company remain healthy (e.g., within a geographic area), the system can divert traffic from that link. This may require disabling the outbound tunnel of that link and administratively disabling the link itself. In some cases, it may be necessary to shut down the link to stop attracting inbound traffic. In these situations, the telecommunications company can participate in troubleshooting.

[0026] In some implementations, the system can detect service degradation on all static BGP links of a single communications company (e.g., within a geographical region). For example, the system may include user-configurable thresholds for observed availability on the links. The system can observe sudden increases in round-trip time (RTT), client retransmissions, etc. When the threshold is reached, the system can reroute all static BGP links of that communications company within the affected geographical region. Traffic can then be fault-shifted to another communications company. At this point, troubleshooting can be performed to restore the links to service.

[0027] In some implementations, the system may not be able to control the upstream communication company's advertising of static BGP prefixes, and it may not be able to immediately control the construction of inbound traffic for static BGP. Since the system may not be able to use legacy BGP sessions to back up static BGP sessions, it may shut down the static BGP link. This causes traffic to be diverted to another static BGP link.

[0028] In some implementations, the system can allocate BGP tunnels from an allocation pool based on each site efficiently defined by the router regions stored in the peering service. This allocation can occur sequentially by region / pool and is not specifically chosen by the service provider.

[0029] As described above, the system can perform source-plus-destination routing on the outbound direction (e.g., from a data center or cloud server to the public internet). When traffic data is received, the system can look up the source IP in a static BGP pool to determine if there is a match. In some implementations, the static BGP pool data structure may reside in a statically allocated array. Next, the system can check the destination IP. For example, the system can check the destination IP in a routing table or route map created based on network reachability analysis. In some implementations, the system can use longest prefix match (LPM) to check the destination IP. If the destination IP matches the prefix list, the system can then encapsulate the data (packet) for example, as a GRE.

[0030] In some implementations, a mapping calculator can be used to construct mappings or routing tables. The mapping calculator can receive, as input, network layer reachability data, tunnel encapsulation information (including encapsulation bits), the operational status of each tunnel, traffic transfer status of tunnel endpoints (e.g., endpoint routers), operational device status (such as whether a device or link is entering or leaving service), and a dataset containing reachability information for the network behind each tunnel. The mapping calculator can also receive other data as input, such as performance data, capacity data, latency data, packet loss data, business logic data such as dollar cost data, service level agreement data, and requirements and / or protocol data with third parties or transit centers (e.g., 80% of traffic can use static BGP routes), etc.

[0031] When there are routing changes in the network, the information can be updated and the mapping recalculated within a short period of time (e.g., within 5 minutes). When there are reachability changes in the network, the information can be updated and the mapping recalculated again within another short period of time (e.g., within 1 minute). Reachability changes can include device / link failures, as well as changes based on health probe results.

[0032] In some implementations, when multiple tunnels exist for the same destination, the system can use non-equivalent, non-uniform capacity multipath. For example, the system can aggregate two links located in two separate buildings, or the system can arbitrarily split traffic based on external input (e.g., 70 / 30). In some implementations, the system can use equal-cost multipath (ECMP) routing. ECMP routing is a routing policy in which packets can be forwarded to a single destination via multiple optimal paths with equal routing priorities.

[0033] Figure 1 An example system 100 for providing static BGP is shown. For example, system 100 can route user traffic on the best available path, respond to network failures and traffic transfers, and enable traffic building. System 100 can use a mapping tool (or calculator) 124 to process BGP data into destination / next-hop entries. For example, destination / next-hop entries can be stored in a mapping table or routing table (or egress mapping) 122. Mapping tool 124 can also provide the system with the ability to automatically respond to failures or transfer tunnels. Although... Figure 1 Data center 120 is shown in the document, but the features described herein for system 100 may also be located in other suitable network locations.

[0034] In some implementations, system 100 may first determine the network reachability of IP destination 150. For example, using a traditional (or dynamic) BGP network 160, the system may learn and store data about the optimal path from a BGP source to IP destination 150. The optimal path can be used to route static BGP traffic. As described in more detail below, this data, along with other data, can be fed into a mapping tool or calculator 124. Calculator 124 can use the optimal path information to assign one or more tunnels 132 to the BGP source in mapping table 122. For example, when data center 120 receives traffic data from user source IP address 110, the system can use the IP destination address in the packet to look up tunnel 132 in mapping table 122 and route the traffic data to Internet edge device 134 through the tunnel at the service provider's boundary network. Internet edge device 134 can then route the traffic data to relay 140 via a static BGP link. Relay 140 may be located at a telecommunications company, Internet service provider (ISP), or entity providing relay connectivity.

[0035] In some examples, the system may include scripts that crawl through each of the destinations in destination 150 to determine which static BGP transit 140 are the best transit points for placing the destinations.

[0036] Figure 2 An exemplary data structure 200 for storing route mappings is shown, similar to... Figure 1 The mapping table 122 in the document. Each entry 220 may include the destination IP prefix 202 and its next-hop / tunnel ID information 204. A tunnel can direct traffic to the desired transit center 140. An "unencapsulated" entry can indicate that no tunnel is associated with the destination IP prefix. Data traffic destined for that destination IP prefix is ​​not encapsulated against static BGP.

[0037] Figure 3 A high-level system diagram 300 depicting the mapping calculator 320 is shown, similar to... Figure 1The calculator 124 in the example. For example, the mapping calculator 320 can receive multiple input sources to calculate and create / update route mappings 340. In the example, the input to the calculator may include reachability data 310, tunnel encapsulation information and management status 312, tunnel endpoint transfer status 314, device / interface operation status 316, health information 318, business logic data 319, etc. As described herein, reachability data 310 may include traditional (or dynamic) BGP reachability data for identifying the destination address. In some implementations, the reachability data 310 may be developed or learned using the BGP monitoring protocol (BMP) when outputting BGP data from the router. For example, the data may come from the border network layer, where optimal path calculations can be performed. In some examples, optimal path calculations may include a combination of multiple calculations from multiple network layers. Based on this data, the system can learn the actual path. For example, the data may indicate the network taken by BGP traffic from the source to the destination. Based on this data, the system can also determine the optimal path and the transit or communication company for the next hop, and translate it into a tunnel endpoint.

[0038] Encapsulation information and management status 312 may include, for example, GRE endpoints to send data traffic from the data center edge to the Internet edge (similar to...). Figure 1 The data center edge 120 and the internet edge 134 are included. The transfer status 314 of the tunnel endpoint can include the status of the router to which traffic can be routed (e.g., entering or leaving service). The operational status 316 of the device / interface can include the status associated with the relay center / communication company (e.g., up / down status). Health information 318 can include fault information at the relay center / communication company, such as packet loss information, congestion information, etc. Business logic data 319 can include dollar cost data, availability data, service level agreement data, and requirements and / or agreement data with third parties or relay centers, etc.

[0039] In some implementations, the mapping calculator 320 can analyze the input to construct a mapping table or route map 340. For example, the mapping calculator 320 may include a script that crawls through each destination in 310 to determine which static BGP transit points are the best transit points for placing the destinations. The route map 340 may be stored in a database or in a data structure 200 in storage area 330.

[0040] Figure 4Example flowchart 400 for creating and maintaining route mappings is shown. In method block 410, the system for creating and maintaining route mappings can receive multiple inputs, including, for example, network layer reachability data, tunnel encapsulation information, operational status of each tunnel, traffic transfer status of tunnel endpoints, operational device status, and a dataset containing reachability information of the network behind each tunnel. These inputs and other inputs in Figure 3 The following is described in method block 416. In method block 412, the system can use / analyze the input to create entries in a route mapping similar to route mapping 340. In some examples, the system can receive state updates regarding, for example, routing or reachability data about a destination address. In method block 414, the system can determine if the routing or reachability data has changed. If it is determined that the routing or reachability data has changed, the system can return to method block 412 and update the mapping entry for the destination address. For example, the update may include a new next-hop address for the destination address. If method block 414 determines that the routing or reachability data has not changed, then in method block 416, the system can maintain the current route mapping or mapping scheme.

[0041] Figure 5 This illustrates the use of [methods] in the outbound direction (e.g., from data center 120 or cloud server via internet edge 134 to the public internet, such as... Figure 1 Example flowchart 500 demonstrates source-plus-destination routing. In method block 510, the system may receive a source IP address and store it in a static BGP pool. The static BGP pool may include source addresses that are allowed to use static BGP routes. In some implementations, the static BGP pool data structure may be in a statically allocated array. Other allocations may also be considered. In method block 512, the system may receive network reachability data and tunnel information data. In method 514, a mapping tool or calculator may create a route mapping based at least on the network reachability data and tunnel information data. In method block 516, when traffic data is received, the system may look up the source IP address (method block 518) in the packets in the static BGP pool to determine if there is a match. A match may mean that the data comes from a source that can use static BGP routes (e.g., a customer or user). Once a match is found, in method block 520, the system may look up the destination IP address in the route mapping created in method block 514. In some implementations, the system may use longest prefix match (LPM) to look up the destination IP address. LPM can help find the longest prefix and / or the most specific route to the destination IP address. In method block 522, if the destination IP matches the prefix list, the system can then encapsulate the data (packet), for example, as GRE, and send the data through a tunnel at the next-hop address associated with the destination IP address in the routing map.

[0042] Figure 6 A sample flowchart 600 is shown for maintaining tunnel information used to route static BGP traffic data. In method block 610, the system can determine which tunnels are available to each communication company. For example, the system can use... Figure 3 The tunnel encapsulation information and management status 312 are shown. In method block 612, the system can check the router IP dataset to determine whether the underlying devices are carrying traffic. For example, the system can check the transfer status 314 data of the tunnel endpoint. In method block 614, the system can determine whether the device or link has been transferred. If the device or link has been transferred, then in method block 616, the system can filter out the tunnel. For example, the system can update the next-hop / tunnel ID field in the routing map. If the determination in method block 614 is that the device or link has not been transferred, then in method block 618, the system can determine whether the device associated with the tunnel is healthy (e.g., working and operating normally). If the device is not healthy, then in method block 616, the system can filter out the tunnel. If the device is healthy, then in method block 620, the system can know that the tunnel's prefix is ​​currently reachable through each transit center / communication company. Then, in method block 622, for each active / healthy tunnel, the system can output all the necessary tunnel encapsulation information and the prefixes reachable through that tunnel.

[0043] The data center referred to in this document can be a physical building or enclosure that houses power and provides power and cooling to servers within a cloud provider's network. Customers or users can connect to availability zones of the cloud provider's network via transit centers (TCs) through publicly accessible networks (e.g., the internet, cellular networks). A TC is the primary backbone location linking customers to the cloud provider's network and can be configured with other network provider facilities (e.g., internet service providers, telecommunications providers) and securely connected (e.g., via VPN or direct connection) to availability zones. Each zone can operate two or more TCs for redundancy. The zones are connected to a global network comprising private networking infrastructure (e.g., fiber optic connections controlled by the cloud provider) connecting each zone to at least one other zone. The cloud provider's network can deliver content from points of presence outside but networked with these zones via edge locations and regional edge caching servers. This partitioning and geographical distribution of computing hardware enables the cloud provider's network to provide customers with low-latency resource access globally with high fault tolerance and stability.

[0044] Figure 7A general example of a suitable computing environment 700 in which the described innovations can be implemented is depicted. The computing environment 700 is not intended to imply any limitation on its scope of use or functionality, as these innovations can be implemented in various general-purpose or specialized computing systems. For example, the computing environment 700 can be any of a variety of computing devices (e.g., desktop computers, laptop computers, server computers, tablet computers, etc.).

[0045] refer to Figure 7 The computing environment 700 includes one or more processing units 710, 715 and memories 720, 725. Figure 7 In the diagram, the basic configuration 730 is included within the dashed lines. Processing units 710 and 715 execute computer-executable instructions. The processing units can be general-purpose central processing units (CPUs), processors in application-specific integrated circuits (ASICs), or any other type of processor. In a multiprocessor system, multiple processing units execute computer-executable instructions to increase processing power. For example, Figure 7 A central processing unit 710 and a graphics processing unit or coprocessor 715 are shown. Physical memories 720, 725 may be volatile memories (e.g., registers, caches, RAM), non-volatile memories (e.g., ROM, EEPROM, flash memory, etc.), or some combination thereof, accessible by the processing unit. Memories 720, 725 store software 780 implementing one or more innovations described herein in the form of computer-executable instructions suitable for execution by the processing unit.

[0046] The computing system may have additional features. For example, computing environment 700 includes storage device 740, one or more input devices 750, one or more output devices 760, and one or more communication connections 770. Interconnection mechanisms (not shown), such as buses, controllers, or networks, interconnect components of computing environment 700. Typically, operating system software (not shown) provides an operating environment for other software executing in computing environment 700 and coordinates the activities of components of computing environment 700.

[0047] The physical storage device 740 may be removable or non-removable and includes a magnetic disk, magnetic tape or cassette tape, CD-ROM, DVD, or any other medium that can be used to store information in a non-transitory manner and can be accessed within the computing environment 700. The storage device 740 stores instructions for implementing one or more innovative software 780 described herein.

[0048] Input device 750 may be a touch input device such as a keyboard, mouse, pen, or trackball, a voice input device, a scanning device, or another device that provides input to computing environment 700. Output device 760 may be a monitor, printer, speaker, CD burner, or another device that provides output from computing environment 700.

[0049] Communication connection 770 enables communication with another computing entity via a communication medium. The communication medium transmits information, such as computer-executable instructions, audio or video input or output, or other data in a modulated data signal. A modulated data signal is a signal having one or more characteristics that are set or altered in a manner that encodes information in the signal. By way of example and not limitation, the communication medium may be electrical, optical, RF, or other carriers.

[0050] Although the operations of some of the disclosed methods are described in a specific sequential order for ease of presentation, it should be understood that this descriptive method includes rearrangement unless the specific language described below requires a particular order. For example, operations described sequentially may be rearranged or performed simultaneously in certain situations. Furthermore, for simplicity, the accompanying figures may not show the various ways in which the disclosed methods can be used in conjunction with other methods.

[0051] Any method disclosed herein can be implemented as computer-executable instructions stored on one or more computer-readable storage media (e.g., one or more optical media discs, volatile memory components (such as DRAM or SRAM), or non-volatile memory components (such as flash memory or hard disk drives)) and executed on a computer (e.g., any commercially available computer, including smartphones or other mobile devices that include computing hardware). The term computer-readable storage media excludes communication connections such as signals and carrier waves. Any computer-executable instructions used to implement the disclosed technology, as well as any data created and used during the implementation of the disclosed embodiments, can be stored on one or more computer-readable storage media. The computer-executable instructions can be, for example, a dedicated software application or part of a software application accessed or downloaded via a web browser or other software application (such as a remote computing application). Such software can be executed, for example, on a single local computer (e.g., any suitable commercially available computer) using one or more networked computers, or in a networked environment (e.g., via the Internet, a wide area network, a local area network, a client-server network (such as a cloud computing network), or other such networks).

[0052] For clarity, only certain selected aspects of the software-based implementation have been described. Other details well-known in the art have been omitted. For example, it should be understood that the disclosed techniques are not limited to any particular computer language or program. For instance, aspects of the disclosed techniques can be implemented by software written in C++, Java, Perl, or any other suitable programming language. Similarly, the disclosed techniques are not limited to any particular computer or hardware type. Certain details of suitable computers and hardware are well-known and do not need to be elaborated in this disclosure.

[0053] It should also be well understood that any functionality described herein may be performed, at least in part, by one or more hardware logic components rather than software. Examples, but not limited to, exemplary types of hardware logic components that may be used include Field Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Program-Specific Standard Products (ASSPs), Systems-on-Chip (SoCs), Complex Programmable Logic Devices (CPLDs), and the like.

[0054] Furthermore, any software-based implementation (e.g., including computer-executable instructions for causing a computer to perform any of the methods disclosed) can be uploaded, downloaded, or remotely accessed via suitable communication means. Such suitable communication means include, for example, the Internet, the World Wide Web, an intranet, software applications, cables (including fiber optic cables), magnetic communication, electromagnetic communication (including RF, microwave, and infrared communication), electronic communication, or other such communication means.

[0055] The disclosed methods, apparatuses, and systems should not be construed as limiting in any way. Rather, this disclosure relates to all novel and non-obvious features and aspects of each of the disclosed embodiments, individually and in various combinations and sub-combinations with each other. The disclosed methods, apparatuses, and systems are not limited to any particular aspect or feature or combination thereof, nor are the disclosed embodiments required to have any one or more particular advantages or problems solved.

[0056] Given the many possible implementations to which the principles of the disclosed invention can be applied, it should be recognized that the illustrated embodiments are merely examples of the invention and should not be considered as limiting the scope of the invention. Therefore, we consider all that falls within the scope of these claims as our invention.

Claims

1. A computer-executable method for providing static Border Gateway Protocol (BGP) routes, the method comprising: Receive source IP address; The source IP address is stored in a static BGP pool, wherein the static BGP pool contains a range of IP addresses provided to the user by the cloud service provider, and the IP addresses in the static BGP pool are static prefixes, which are specified to use static BGP. Receive network reachability data for one or more network destination addresses, wherein the network reachability data includes dynamic BGP data paths for reaching the one or more network destination addresses; Receive tunnel information for one or more tunnels; The network reachability data and the tunnel information are analyzed to create a route mapping for using static BGP, wherein the route mapping for using static BGP includes a destination address and a next-hop address; Receive a data packet, the data packet including the source IP address and the destination IP address of the packet; When the source IP address is determined to be in the static BGP pool, the next-hop address for the destination IP address of the packet is looked up in the route mapping, wherein the next-hop address belongs to the static BGP route; and The data packet is encapsulated for transmission through one or more tunnels to the next-hop address.

2. The method according to claim 1, further comprising: Receive the operational status of each of the one or more tunnels, the traffic transfer status of the endpoints of the one or more tunnels, the operational status of one or more devices associated with the one or more tunnels, and a dataset containing reachability information of the network behind the one or more tunnels.

3. The method according to claim 2, wherein, Creating the route mapping for using static BGP further includes analyzing the operational status of each of the one or more tunnels, the traffic transfer status of the endpoints of the one or more tunnels, the operational status of the one or more devices associated with the one or more tunnels, and the dataset containing reachability information of the network behind the one or more tunnels.

4. The method according to claim 1, wherein, The packet destination IP address is one of the one or more network destination addresses.

5. The method according to claim 2, further comprising: Receive reachability data or changes in the operational status of the one or more devices; as well as Update the route mapping.

6. The method according to claim 5, wherein, Updating the route mapping includes updating the next-hop address.

7. The method according to claim 1, wherein, The next-hop address enables the data packet to be sent to the relay center using static BGP.

8. A computer-readable medium comprising computer-executable instructions, which, when executed, cause a computing system to perform a method comprising: Receive network reachability data for one or more network destination addresses; The network reachability data is analyzed to create a route mapping for static Border Gateway Protocol (BGP) routes; The cloud service provider allocates a range of IP addresses to the user for use as static BGP addresses; The range of the IP addresses is stored in the routing map of the cloud service provider; Receive outbound requests for IP addresses within the range of the stated IP addresses; as well as The IP address is determined to be in the route mapping used for static BGP routing, and the route mapping is used to determine a tunnel that can reach the IP address.

9. The computer-readable medium according to claim 8, wherein, The network reachability data includes dynamic BGP data paths for reaching the one or more network destination addresses.

10. The computer-readable medium of claim 8, further comprising: Receive tunnel information for one or more tunnels and the operational status of each of the one or more tunnels, wherein the tunnel information includes a next-hop address.

11. The computer-readable medium of claim 8, further comprising: Analyze business logic data to create route mappings for static BGP routes.

12. The computer-readable medium of claim 10, further comprising: The tunnel information of the one or more tunnels and the operational status of each of the one or more tunnels are analyzed to create the route mapping for static BGP routing.

13. The computer-readable medium according to claim 8, wherein, The route mapping used for static BGP routes includes the destination address and the next-hop address.

14. A system for providing static Border Gateway Protocol (BGP) routes, the system comprising one or more processors configured to: The cloud service provider allocates a range of IP addresses to the user for use as static BGP addresses; The range of the IP addresses is stored in the routing map of the cloud service provider; Receive a data packet, the data packet including a source IP address and a destination IP address; Look up the source IP address in the list of IP addresses that contain the range of IP addresses in the route mapping; When the source IP address is determined to be in the IP address list, the next-hop address for the destination IP address is looked up in the route mapping, wherein the next-hop address belongs to a static BGP route; as well as The data packet is encapsulated for transmission through a tunnel to the next-hop address.

15. The system according to claim 14, wherein, The next-hop address is the tunnel identifier.

16. The system according to claim 14, wherein, The route mapping is created using at least network reachability data, tunnel information, and router status.

17. The system of claim 16, wherein the one or more processors are further configured to: Receive the reachability data or the change in the router state; and Update the route mapping.

18. The system according to claim 17, wherein, Updating the route mapping includes updating the next-hop address.

19. The system according to claim 14, wherein, The next-hop address is the interface address at the relay center.

20. The system according to claim 14, wherein, The next-hop address enables the data packet to be sent to the relay center using static BGP.

Images