Route issuing method and device, electronic equipment and storage medium

By establishing MP-IBGP peers with private network addresses between the controller and the border router, and implementing protocol conversion routing strategies, the problems of increased controller routing protocol complexity and the number of peers are solved, enabling efficient transmission and scheduling of various routes.

CN122073569APending Publication Date: 2026-05-22TENCENT TECHNOLOGY (SHENZHEN) CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
TENCENT TECHNOLOGY (SHENZHEN) CO LTD
Filing Date
2024-11-20
Publication Date
2026-05-22

Smart Images

  • Figure CN122073569A_ABST
    Figure CN122073569A_ABST
Patent Text Reader

Abstract

The invention relates to the technical field of communication, in particular to a route issuing method and device, electronic equipment and a storage medium, which are used for reducing the number of peers of a controller and the complexity of a route protocol. The method is applied to a controller in networking, and the networking further comprises at least one POP. At least one border router is deployed in each POP, each border router is respectively accessed to at least one ISP, and the method comprises the following steps: respectively establishing an MP-IBGP peer with each border router by using a private network address; a private network VRF and at least one public network VRF are respectively configured on each border router; the private network address is bound with a private network VRF; and issuing first routing information to the border router through an MP-IBGP protocol, so that the border router converts the address family attribute of the first routing information from the VPN type to the IP type when determining that the first routing information is matched with a preset protocol conversion routing strategy during routing cross injection.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a routing method, apparatus, electronic device, and storage medium. Background Technology

[0002] In a standard internal network topology, the network is divided into two Virtual Routing Forwarding (VRF) instances: VRF1 and VRF2. VRF1 carries traffic for objects accessing the Internet, using public IP addresses and connecting the data center and point of presence (POP) via a Virtual Private Network (VPN) tunnel. This VPN is based on the underlying network architecture or infrastructure. VRF2 is used for communication between internal devices, using private IP addresses and transmitting internal network routes via the Interior Gateway Protocol (IGP). It also carries VPN tunnel traffic for internal device management and Internet services.

[0003] In this internal network, the controller, acting as the internal routing scheduling device, needs to simultaneously handle route scheduling from the internal data center to the POP and route scheduling for specific ISP exits on the Edge Router (ER) devices. To this end, the controller requires multiple IP addresses: one public IP bound to VRF1 to ensure interoperability with the entire network's VRF1 network and the establishment of Internal Border Gateway Protocol (IBGP) peers for injecting local IPv4 / 6 routes; and one private IP bound to VRF2 to ensure interoperability with internal devices and the establishment of Multi-Protocol Internal Border Gateway Protocol (MP-IBGP) peers for injecting VPNv4 / 6 tunnel routes. This increases the number of peers for the controller and the complexity of the routing protocols.

[0004] In summary, reducing the number of peers in the controller and the complexity of routing protocols are urgent issues that need to be addressed. Summary of the Invention

[0005] This application provides a routing method, apparatus, electronic device, and storage medium to reduce the number of peers in the controller and the complexity of the routing protocol.

[0006] This application provides a routing method applied to a controller in a network, the network further comprising: at least one Point of Presence (POP); each POP deploying at least one border router, each of the border routers connecting to at least one ISP, the method comprising:

[0007] Using a private network address, an MP-IBGP peer is established with each of the border routers; each border router is configured with a private network VRF and at least one public network VRF; the private network address and the private network VRF are bound together.

[0008] The first routing information is sent to the border router via the MP-IBGP protocol, so that when the border router performs route cross-injection, it analyzes whether the first routing information matches the preset protocol conversion routing policy. If it matches, the address family attribute of the first routing information is changed from VPN type to IP type. The route cross-injection refers to injecting the first routing information from a private network VRF into a public network VRF in the border router.

[0009] Another routing method provided in this application embodiment is applied to border routers in a network, the network including: at least one POP and a controller; each POP deploys at least one border router, and each border router is connected to at least one ISP; the controller establishes an MP-IBGP peer with each border router using a private network address; each border router is configured with a private network VRF and at least one public network VRF, and the private network address and the private network VRF are bound; the method includes:

[0010] Receive the first routing information sent by the controller via the MP-IBGP protocol;

[0011] When performing route cross-injection, analyze whether the first route information matches the preset protocol conversion route strategy;

[0012] If a match is found, the address family attribute of the first routing information is changed from VPN type to IP type, and the next-hop VRF of the first routing information is changed from the private network VRF to the public network VRF in the border router, so as to inject the first routing information from the local private network VRF into the public network VRF.

[0013] This application provides a routing distribution device applied to a controller in a network, the network further comprising: at least one Point of Presence (POP); each POP deploying at least one border router, each of the border routers connecting to at least one ISP, the device comprising:

[0014] A configuration unit is used to establish an MP-IBGP peer with each of the border routers using a private network address; each of the border routers is configured with a private network VRF and at least one public network VRF; the private network address and the private network VRF are bound together.

[0015] The scheduling unit is used to send first routing information to the border router via the MP-IBGP protocol, so that when the border router performs route cross-injection, it analyzes whether the first routing information matches a preset protocol conversion routing policy. If it matches, the address family attribute of the first routing information is changed from VPN type to IP type. The route cross-injection refers to injecting the first routing information from a private network VRF into a public network VRF in the border router.

[0016] Optionally, the first routing information carries a target route identifier, so that when the border router performs route cross-injection, it analyzes whether the first routing information matches the protocol conversion routing policy based on the target route identifier; wherein:

[0017] If the target route identifier is a route identifier of a specified type, then it is determined that the first route information matches the protocol conversion route policy;

[0018] If the target route identifier is not a route identifier of the specified type, then it is determined that the first route information does not match the protocol conversion route policy.

[0019] Optionally, each border router in the network connects to at least two ISPs;

[0020] In a scenario where an object requests access to a specific network segment, and the traffic exit specified for that specific network segment is the target ISP among the at least two ISPs, the scheduling unit is specifically used for:

[0021] The first routing information is sent to the target border router among the border routers via the MP-IBGP protocol;

[0022] Wherein, the routing prefix in the first routing information is the specific network segment, the next hop points to the target ISP, and the target border router is the border router among the border routers that connects to the target ISP, so that when the first routing information matches the protocol conversion routing policy, the target border router will forward the traffic request for the specific network segment to the target ISP through the local public network VRF.

[0023] Optionally, the network further includes a data center, in which at least one data center router is deployed; the scheduling unit is further configured to:

[0024] Using the private network address, an MP-IBGP peer is established with each of the data center routers; each of the data center routers is configured with the private network VRF and at least one public network VRF.

[0025] Send the second routing information to the data center router via the MP-IBGP protocol;

[0026] In this second routing information, the routing prefix is ​​the specific network segment, the next hop points to the target border router, and the Multi-Protocol Label Switching (MPLS) label is the label corresponding to the target ISP, so that the data center router will forward traffic requests for the specific network segment to the public network VRF in the target border router through the MPLS tunnel. The MPLS tunnel is established based on the MPLS label.

[0027] Optionally, the first routing information has the highest priority within a specified routing information range, and the specified routing information range includes: each routing information from the target border router to the specific network segment;

[0028] The second routing information has a higher priority than a specified priority, which refers to the priority of the routing information learned by the target ISP and transmitted to the data center router through the routing reflector.

[0029] Another routing device provided in this application embodiment is applied to a border router in a network, the network including: at least one POP and a controller; each POP deploys at least one border router, and each border router is connected to at least one ISP; the controller establishes an MP-IBGP peer with each border router using a private network address; each border router is configured with a private network VRF and at least one public network VRF, and the private network address and the private network VRF are bound; the device includes:

[0030] The receiving unit is used to receive the first routing information sent by the controller through the MP-IBGP protocol;

[0031] The routing cross-connection unit is used to analyze whether the first routing information matches the preset protocol conversion routing strategy when performing routing cross-connection injection.

[0032] If a match is found, the address family attribute of the first routing information is changed from VPN type to IP type, and the next-hop VRF of the first routing information is changed from the private network VRF to the public network VRF in the border router, so as to inject the first routing information from the local private network VRF into the public network VRF.

[0033] Optionally, the first routing information carries a target route identifier, and the routing cross-connect unit is specifically used for:

[0034] Based on the target route identifier, analyze whether the first route information matches the protocol conversion route policy, wherein:

[0035] If the target route identifier is a route identifier of a specified type, then it is determined that the first route information matches the protocol conversion route policy;

[0036] If the target route identifier is not a route identifier of the specified type, then it is determined that the first route information does not match the protocol conversion route policy.

[0037] Optionally, each border router in the network is connected to at least two ISPs; in the scenario where the object requests access to a specific network segment and the traffic exit specified by the specific network segment is the target ISP among the at least two ISPs, the routing prefix in the first routing information is the specific network segment, and the next hop points to the target ISP;

[0038] The device also includes:

[0039] A forwarding unit is used to receive traffic requests for the specific network segment via a local public network VRF;

[0040] Based on the first routing information, the traffic request is forwarded to the target ISP.

[0041] Optionally, the routing cross-connect unit is specifically used for:

[0042] If the first routing information is a VPNv4 route, then the address family attribute of the first routing information is changed from VPNv4 to IPv4;

[0043] If the first routing information is a VPNv6 route, then the address family attribute of the first routing information is changed from VPNv6 to IPv6.

[0044] Optionally, the specified type of route identifier includes at least one of the following: a specified community attribute, a specified extended community attribute.

[0045] Optionally, the routing cross-connect unit is further configured to:

[0046] If no match is found, the first routing information is injected from the local private network VRF into the public network VRF based on the MP-IBGP protocol during route cross-injection.

[0047] An electronic device provided in this application includes a processor and a memory, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor performs the steps of any of the above-described routing methods.

[0048] This application provides a computer-readable storage medium including a computer program. When the computer program is run on an electronic device, the computer program is used to cause the electronic device to perform the steps of any of the above-described routing methods.

[0049] This application provides a computer program product, which includes a computer program stored in a computer-readable storage medium. When the processor of an electronic device reads the computer program from the computer-readable storage medium, the processor executes the computer program, causing the electronic device to perform the steps of any of the above-described routing methods.

[0050] The beneficial effects of this application are as follows:

[0051] This application provides a route distribution method, apparatus, electronic device, and storage medium. This application only requires creating one MP-IBGP peer between the controller and the corresponding router. Specifically, the controller only needs to use its private network address to establish an MP-IBGP peer with the border routers in the POP, instead of using a public network address to establish an IBGP peer with these routers. Since the private network address is bound to the private network VRF, which is used for communication between internal devices, communication between the controller and internal devices can be ensured. Furthermore, by establishing an MP-IBGP peer, VPNv4 / 6 route transmission is supported.

[0052] Based on the above, in order to realize the routing scheduling capability of multiple protocols, this application adds a protocol conversion routing policy based on the MP-IBGP peer on the VPN address family corresponding to the router. Specifically, the controller can send VPN routes (such as the first routing information) to the router through the MP-IBGP protocol. If the route received by the router matches the protocol conversion routing policy, the router performs route cross-injection. When imported into the corresponding VRF, the address family attribute of the route can be converted from the VPN address family to the IP address family. In this way, it is not necessary to establish an IBGP peer between the controller and the corresponding router to realize the transmission of IPv4 / v6 routes.

[0053] In summary, by creating only one MP-IBGP peer between the controller and the corresponding router, multiple routes such as VPNv4 / 6 and IPv4 / v6 can be transmitted simultaneously, enabling rapid routing scheduling in various scenarios and greatly simplifying internal network topology and controller routing scheduling logic.

[0054] Other features and advantages of this application will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings. Attached Figure Description

[0055] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0056] Figure 1 This is an optional schematic diagram of an application scenario in an embodiment of this application;

[0057] Figure 2 A schematic diagram of an internal network providing Internet access as a standard feature in related technologies;

[0058] Figure 3 This is a schematic diagram of a standard internal network in this application;

[0059] Figure 4 This is a schematic diagram of yet another internal network configuration in an embodiment of this application;

[0060] Figure 5 This is a schematic diagram of another internal network configuration in an embodiment of this application;

[0061] Figure 6 A flowchart illustrating the implementation of a routing distribution method provided in this application embodiment;

[0062] Figure 7 This is a schematic diagram illustrating the distribution of routing information by a controller in an embodiment of this application;

[0063] Figure 8 A flowchart illustrating the implementation of another routing method provided in this application embodiment;

[0064] Figure 9 This is a schematic diagram of the forwarding path of traffic requests in an internal network according to an embodiment of this application;

[0065] Figure 10 This is a schematic diagram of the forwarding path of traffic requests in another internal network configuration according to an embodiment of this application.

[0066] Figure 11 This is a schematic diagram of the forwarding path of traffic requests in another internal network configuration according to an embodiment of this application.

[0067] Figure 12This is a timing diagram illustrating the interaction between a controller and a border router and a data center router in one embodiment of this application.

[0068] Figure 13 This is a schematic diagram of the composition structure of a routing distribution device according to an embodiment of this application;

[0069] Figure 14 This is a schematic diagram of the composition structure of another routing distribution device in an embodiment of this application;

[0070] Figure 15 This is a schematic diagram of the hardware structure of an electronic device using an embodiment of this application. Detailed Implementation

[0071] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings of the embodiments of this application. Obviously, the described embodiments are only some embodiments of the technical solutions of this application, and not all embodiments. Based on the embodiments recorded in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the technical solutions of this application.

[0072] The following describes some of the concepts involved in the embodiments of this application.

[0073] 1. Networking and Internal Networking: Networking refers to connecting multiple computers or other devices or network nodes through communication links within a certain physical area (such as an office, school, or home) to form a network system capable of communicating with each other. It can be used to achieve resource sharing, information exchange, etc. Networking can include enterprise internal networks, the Internet, cloud service networks, etc., supporting various applications and services.

[0074] Internal networking is a type of networking that is usually not open to the outside world and only allows authorized users to access it, emphasizing security and centralized management of resources.

[0075] 2. Public VRF and Private VRF:

[0076] Public VRFs are used to handle internet-related traffic. This traffic is typically globally reachable and requires routing via public IP addresses. Private VRFs are used to handle traffic within internal networks or for specific clients. This traffic is typically private and requires routing via private IP addresses. The term "private network" refers to a private network, also known as an internal network or simply an intranet. The term "public network" refers to a public network, also known as an external network or simply an extranet.

[0077] In the embodiments of this application, both the border router and the data center router are configured with public network VRF and private network VRF. The purpose is to achieve isolation and independent routing between different networks, so as to ensure that different types of traffic (such as public network traffic and private network traffic) can be managed and forwarded independently.

[0078] 3. Route injection and cross-route injection:

[0079] Route injection, also known as route import, refers to the process of adding specific routing information (also called routing entries, or simply routes) to the routing table in a network through a certain mechanism. This routing information can be configured manually or automatically learned and propagated through dynamic routing protocols such as Border Gateway Protocol (BGP), Open Shortest Path First (OSPF), and Routing Information Protocol (RIP). The main purpose of route injection is to control and optimize network traffic paths, ensuring that data packets are transmitted along predetermined paths, thereby improving network performance and reliability. This article primarily focuses on the automatic learning and propagation of routes using the MP-IBGP protocol.

[0080] Route cross-injection, also known as route cross-import, refers to injecting routing information from one VRF into another VRF, or injecting it from the global routing table into a VRF. In some cases, different VRFs need to communicate with each other. Route cross-injection allows routing information from one VRF to be introduced into another VRF, enabling these two VRFs to communicate with each other.

[0081] In this embodiment of the application, route cross-injection is a route injection method for border routers. Specifically, it refers to injecting routing information originally intended for the private network VRF in a border router into the public network VRF.

[0082] 4. Protocol Conversion Routing Strategy: This is a network technology used to convert and distribute routing information between different routing protocols. Specifically, in a network, to achieve interoperability between different network protocols, a specific routing mechanism or device (such as a protocol converter, gateway, or router) is used to convert data from one protocol to data from another. This strategy is typically used in multi-protocol network environments to achieve interoperability between different protocols and the sharing of routing information. Protocol conversion routing strategies can ensure that different network devices and protocols can work together, improving the overall performance and reliability of the network.

[0083] For example, in this embodiment of the application, when performing route cross-injection on routing information, the protocol conversion routing policy can be matched. If a match is found, the address family of the routing information is converted to a different protocol.

[0084] 5. MPLS: A technology for efficiently forwarding data packets over high-speed networks. MPLS-based Layer 3 Virtual Private Networks (MPLS L3VPNs) provide VPN services over public networks, allowing multiple tenants or services to communicate isolated from each other on shared public network infrastructure (such as the Internet or a service provider's backbone). Each L3VPN is a logically independent network with its own routing policies and Quality of Service (QoS) settings, providing customers with a service experience similar to a private network. Traffic from different customers is isolated within the MPLS network, ensuring data security and privacy.

[0085] MPLS labels are tags carried by data packets during transmission in an MPLS network. They function similarly to IP addresses in an MPLS network, serving for fast forwarding and traffic isolation. By carrying specific tags, data packets can be ensured to be forwarded along a predetermined path without relying on hop-by-hop IP route lookups.

[0086] 6. MP-IBGP is an extension of BGP used to exchange routing information for multiple network layer protocols within the same Autonomous System (AS). MP-IBGP is particularly suitable for MPLS L3VPN environments because it allows Provider Edge (PE) routers (such as ER and DR in this application) to exchange different types of routing information, including IPv4, IPv6, and MPLS labels. Through MP-IBGP, PE routers can maintain the consistency and synchronization of routing information, ensuring the efficient and reliable operation of MPLS L3VPN.

[0087] 7. Route Reflector (RR) is a mechanism in BGP used to solve the route propagation problem in full-mesh IBGP networks. By centrally managing routing information, it reduces the number of IBGP sessions, simplifies network configuration, and improves network scalability and management efficiency.

[0088] In large networks, each IBGP router needs to establish a full mesh peering relationship with all other IBGP routers, resulting in a large number of BGP sessions and configuration complexity. A route reflector, acting as the central node of the IBGP routers, can receive routing information from clients and reflect it to other clients. In this way, each IBGP router only needs to establish a session with the route reflector, instead of with all other IBGP routers.

[0089] 8. Peer: A peer is a node in a network that can communicate with each other. In this article, a peer can be an ER and a controller, a DR and a controller, or even a DR and an RR, or an ER and an RR. When peers are established between two or more parties, it is not necessary to distinguish between the service requester and the service provider. Devices that have established a peer can achieve equal and reciprocal communication.

[0090] 9. Border Router: This refers to a router located at the network edge, used to connect internal networks (such as corporate LANs) with external networks (such as ISP networks). It is typically deployed at the network's entry and exit points, i.e., Points of Presence (POPs), and is primarily responsible for routing, packet filtering, security control, traffic management, and QoS guarantees. The preferred embodiments of this application are described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustrative and explanatory purposes only and are not intended to limit the application. Furthermore, the embodiments and features described herein can be combined with each other without conflict.

[0091] like Figure 1 The diagram shown is an application scenario illustration of an embodiment of this application. The application scenario diagram includes a terminal device 110 and a server 120.

[0092] In this embodiment, the terminal device 110 includes, but is not limited to, mobile phones, tablets, laptops, desktop computers, e-book readers, smart voice interaction devices, smart home appliances, and in-vehicle terminals. The terminal device may have a client installed for internet access. This client can be software (such as a browser, instant messaging software, etc.), or a webpage, mini-program, etc. The server 120 is the backend server corresponding to the software, webpage, mini-program, etc., or a server specifically used for internet access; this application does not impose specific limitations. The server 120 can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms.

[0093] The routing method in the various embodiments of this application can be applied to a network comprising: at least one Point of Presence (POP), a controller, and a data center; each POP is equipped with at least one border router (ER), and the data center is equipped with at least one data center router (DR). Each border router is connected to at least one ISP, and the border router can then connect to the Internet through various means provided by the ISP (such as broadband, DSL, fiber optic, mobile data, etc.).

[0094] Through the above deployment, interconnection between data center networks and ISP networks (ISP networks are part of the Internet) can be achieved, thereby providing Internet services to a massive number of objects.

[0095] In practical applications, terminal device 110 can initiate traffic requests through the data center in this network, while server 120 provides the necessary services. The server typically relies on routing information provided by routers to access other devices on external or internal networks. For example, the server might send data to a border router in the POP via the data center router, and the border router would then connect to the internet via an ISP. Data packets returning from the internet would also travel the same path back to the terminal device.

[0096] Optionally, the network in this application can be an internal network, such as an internal network used to provide internet access. Specifically, an internal network used to provide internet services refers to a network system built within an enterprise or organization to access the internet. This type of network not only needs to achieve interconnection between internal devices but also must establish a secure and stable connection with the external internet. In short, it is a network architecture that allows an organization to efficiently use internet resources while ensuring security.

[0097] Of course, there can be many other types of networking, such as enterprise networking, which refers to a network architecture that provides network connectivity and internet access for an enterprise's internal network and branch offices. An enterprise may deploy multiple Points of Presence (POPs) in different locations to enable multi-location office operations and disaster recovery; a data center is used for centralized storage and processing of enterprise data, providing core services; and a controller is used for centralized management and routing to optimize network resources. In this embodiment, the internal network used to provide internet services is part of the enterprise networking, focusing on achieving secure and stable connections between internal devices and the internet, while the enterprise networking further encompasses comprehensive network connectivity and optimization between the enterprise's internal network and branch offices.

[0098] For example, cloud service provider networking refers to the network architecture that provides cloud services (such as Infrastructure as a Service, Platform as a Service, and Software as a Service) to users. Cloud service providers may deploy multiple Points of Presence (POPs) globally to provide low-latency and high-availability services; data centers are used to store and process user data and provide various cloud services; and controllers are used to centrally manage and schedule routes, optimize network resources, and support large-scale user demands.

[0099] The networking methods listed above are only simplified examples. Other networking types are also applicable to this application. Each networking type has its specific application scenarios and functional requirements. Through reasonable network design and management, efficient, reliable and secure network services can be achieved. These will not be elaborated on here.

[0100] The following text mainly uses internal networking as an example for specific explanation. Of course, other types of networking use the same routing method, which will not be elaborated on in this article.

[0101] The following is a description of each part of this internal network:

[0102] An ISP is an internet service provider that offers internet services to users. These services can include, but are not limited to, internet access, information services, and value-added services. The "users" here can refer to traffic requesters who request internet services from an ISP. An ISP network is a network provided by an ISP and is part of the internet, used to provide internet services to users, such as internet access, email, and online gaming. Different ISP networks are provided by different ISPs.

[0103] A Point of Presence (POP) is an access point in a network, typically located at the edge of a cloud network. It acts as an access point for the ISP network, helping data center networks connect to the ISP network and access internet services. Different POPs can be located in the same or different regions, each providing service to a specific region. It's important to note that the region where a POP is located can be the same as or different from the region it serves.

[0104] In this embodiment of the application, at least one border router is deployed in each POP. Each border router is connected to the Internet by accessing at least one ISP. It can also be understood as a border router of the ISP network. They are used to connect internal networks (such as corporate LANs) and external networks (such as ISP networks) to ensure that the processes of the internal network can enter and exit the external network securely and efficiently.

[0105] Optionally, each border router in this internal network can connect to at least two ISPs. By connecting to different ISP networks, high-speed Internet access and routing services can be provided, while achieving redundancy and load balancing.

[0106] It should be noted that the number of POPs in this internal network can be one or more. When there is only one POP in the internal network, the POP needs to be connected to at least two ISPs. When there are multiple POPs in the internal network, each POP only needs to be connected to at least one ISP.

[0107] A data center is a centralized location for storing and processing data, typically containing a large number of servers, storage devices, network equipment, and more. Data centers provide high-performance computing and storage resources to support various business applications and services. The data center network is the internal network infrastructure of the data center, ensuring that devices within the data center can communicate and collaborate efficiently and reliably.

[0108] Specifically, a data center network, also known as an intranet network, refers to a network built by a specific enterprise or organization that can provide network services such as storage, computing, or resources, and is only open to personnel and equipment within that specific enterprise or organization.

[0109] In this embodiment of the application, a data center router (DR) is deployed in the data center. It plays a key role in the network architecture of the data center. It is a high-performance router specifically designed for internal network connections and external network communication in the data center. It has high availability, routing functions, security functions and QoS policies to ensure the efficient, secure and reliable operation of the data center network.

[0110] In the internal network of this application, the data center router communicates with the border router and controller to process traffic requests from terminal devices and forward the traffic to the Internet or the internal network.

[0111] Optionally, the controller, as a routing and scheduling device within the internal network, is typically implemented through a software server. For example, a controller based on a software server can be deployed on a suitable server (such as a physical server or a virtual machine provided by a cloud service provider).

[0112] In the internal network of this application, the controller is responsible for managing and scheduling routing information in the network to ensure that traffic is scheduled as needed.

[0113] The above briefly introduces the POP and its ER, the data center and its DR, and the controller in this internal network. The following mainly describes the relationship between the ER, DR, and controller during route scheduling:

[0114] In this embodiment, each ER and DR is configured with a private network VRF and at least one public network VRF. The private network address is bound to the private network VRF. In the controller of this application, only one physical or logical interface needs to be bound to the private network VRF.

[0115] In this internal network, terminal devices initiate traffic requests through the data center. The data center router processes these requests based on the configured private network VRF and public network VRF, and forwards the traffic to the border router. The border router achieves redundancy and load balancing of Internet connections by connecting to multiple ISPs.

[0116] To ensure that the controller can simultaneously perform route scheduling from the DataCenter to the POP and route scheduling for specific ISP exits on the ER device, while reducing the number of peers and the complexity of routing protocols, the controller in this application only needs to use private network addresses (specifically private network IP addresses) to establish MP-IBGP peers with each border router and each data center router. Furthermore, on the VPNv4 and VPNv6 address families corresponding to the MP-IBGP peers, a protocol conversion routing policy based on the MP-IBGP peers is configured. This policy is used to convert the address family attributes of the routing information matching the protocol conversion routing policy to IPv4 or IPv6 during route cross-injection, thereby achieving the ability to implement multiple route injections through a single MP-IBGP protocol.

[0117] Optionally, the routing method in each embodiment of this application can be executed by an electronic device, which can be a terminal device 110 or a server 120. That is, the method can be executed by the terminal device 110 or the server 120 alone, or by the terminal device 110 and the server 120 together.

[0118] The structure of the internal network in the embodiments of this application will be briefly described below with reference to the accompanying drawings:

[0119] See Figure 2 As shown, it is a schematic diagram of a standard internal network in the related technology of this application. Figure 2 The internal network shown provides internet access. This network topology includes two Point-of-Place (POP) sites (POP1 and POP2), one data center, one controller, and one Router Receiver (RR). Each POP contains one Router Receiver (ER), and the data center contains one Router Receiver (DR) and user equipment (User). In this internal network, the controller manages and configures the entire network, and the RR is used to reflect routing information, simplifying the IBGP network.

[0120] In this setup, POP1 deploys one border router ER1, and POP2 deploys one border router ER2. Each edge router has two VRF (Virtual Routing and Forwarding) instances: VRF1 (public network VRF) and VRF2 (private network VRF). The data center routers in the data center also have VRF1 and VRF2 instances.

[0121] In other words, Figure 2 The entire network shown is divided into two VRFs. VRF1 carries all traffic from users accessing the Internet. The IP addresses of this VRF are all public IP addresses. When forwarding traffic between the data center and the POP, a VPN tunnel based on the Underlay network is used. VRF2 is the VRF that forwards all traffic of the entire network (i.e., the whole network). It is used for network communication between internal devices and between controllers. It also carries VPN tunnel traffic for internal device management and Internet services. The IP addresses of this VRF are generally private IP addresses.

[0122] Regarding routing protocol configuration, Figure 2 The ER device's VRF1 establishes an External Border Gateway Protocol (EBGP) peer with the ISP to exchange routes between the internal network and the carrier's network. Internally, the ER establishes MP-IBGP peers with the DR and RR to exchange label routes learned by VRF1 between peers, ensuring the establishment of MPLS Layer 3 VPN tunnels between relevant peers. VRF2, as the network for internal network interconnection, typically uses the IGP protocol to transmit internal network routes, ensuring normal network communication between internal components (including ER, DR, RR, and the controller).

[0123] The controller, as an internal routing scheduling device, needs to implement routing scheduling capabilities from the data center to the POP. For example, when a user accesses the Internet, it needs to use POP2 exit to access the Internet, which requires the injection of VPNv4 / 6 tunnel routes using MP-IBGP. At the same time, it also needs to have the ability to force the routing scheduling of specific ISP exits on the ER device. For example, when a user accesses a specific network segment, it needs to forward the route from ISP3 exit, which requires the injection of local IPv4 / 6 routes using IBGP.

[0124] To achieve this, the controller needs multiple IP addresses: a public IP address (referred to as the public address) bound to VRF1 to ensure communication with VRF1 across the entire network and the establishment of IBGP peers; and a private IP address (i.e., the private address) bound to VRF2 to ensure communication with internal devices and the establishment of MP-IBGP peers. This ensures that the controller can use either MP-IBGP peers or IBGP peers for route injection based on the scheduling task, enabling on-demand scheduling of service traffic. However, this increases the number of peers and the complexity of routing protocols for the controller.

[0125] In this application, the internal network does not require full network support for VRF1 service VRF interoperability; it only needs to ensure VRF2 internal network interoperability. This does not intrude on the existing network and allows for rapid controller deployment. Furthermore, regarding routing protocols, the controller only needs to support the MP-IBGP protocol. It can establish MP-IBGP peers with all scheduling routers (such as ERs and DRs) to perform route transmission, reception, and scheduling.

[0126] like Figure 3 As shown, it is a schematic diagram of a standard internal network according to this application. Figure 3 In this system, the ER and DR scheduling routers still maintain two VRFs. VRF1 continues to carry public network service traffic, while VRF2 carries the tunnel underlay traffic between the internal private network and the public network, ensuring routing isolation between the public and private networks.

[0127] In this network architecture, all ERs and DRs still use private network addresses to establish MP-IBGP peers with RRs, enabling the transmission of public network routes across the entire network. Simultaneously, the controller also uses private network addresses to establish separate MP-IBGP peers with all ERs and DRs, used to learn peer routes and distribute scheduling routes to routers.

[0128] and Figure 2 The difference is, Figure 3 The controller itself only needs one interface to connect to the existing VRF2 internal network, ensuring interoperability with all internal routers. In this way, the controller only needs to establish an MP-IBGP peer with each router in the internal network. All scheduling routers, in addition to their existing configurations, need to add protocol translation routing policies based on the peer for the corresponding VPNv4 and VPNv6 address families for the MP-IBGP peers interconnected with the controller. For routes advertised by the controller peers, in addition to the existing protocol-defined rules, additional protocol translation routing policies are required.

[0129] It should be noted that the above Figure 2 or Figure 3This example illustrates a standard internal network topology. This network contains two Points of Presence (POPs), each POP contains one Execution Provider (ER), and each ER contains one public VRF (VRF1) and one private VRF (VRF2). Each public VRF connects to two ISPs. It should be noted that in practical applications... Figure 2 or Figure 3 The number of POPs, ERs, DRs, and ISPs in the listed internal network can be flexibly adjusted.

[0130] For example, when there is only one POP in the internal network, an ER can be set up in that POP, and the ER needs to be connected to at least two ISPs.

[0131] like Figure 4 As shown, this is a schematic diagram of another internal network configuration in an embodiment of this application. Figure 4 The listed internal network topology has only one Point of Presence (POP), which contains one ER (ER1). ER1 is configured with two public network VRFs, such as VRF1 and VRF3, and one private network VRF, such as VRF2. Additionally, the data center within this internal network contains one Data Center (DR), which is configured with one public network VRF, such as VRF1, and one private network VRF, such as VRF2.

[0132] In this internal network, ER1, ER2 and DR all establish MP-IBGP peers with RR through private network addresses (bound to VRF2), and ER1, ER2 and DR all establish MP-IBGP peers with the controller through private network addresses (bound to VRF2).

[0133] When there are more than two POPs in the internal network, each POP can be configured with one ER. These ERs can connect to at least two ISPs in total. Therefore, some ERs can connect to one ISP, while others can connect to multiple ISPs.

[0134] like Figure 5 As shown, it is a schematic diagram of another internal network in an embodiment of this application. Figure 5 The listed internal network topology has three Points of Presence (POPs), denoted as POP1, POP2, and POP3. Each POP contains one Executor (ER), denoted as ER1, ER2, and ER3. Each ER is configured with one public VRF and one private VRF. The public VRFs are distributed as follows: VRF1 on ER1, VRF3 on ER2, and VRF4 on ER3. The private VRFs are all VRF2. Additionally, the data center in this internal network contains one Data Center (DR), which is configured with one public VRF (e.g., VRF5) and one private VRF (e.g., VRF2).

[0135] In this internal network, ER1, ER2, ER3 and DR all establish MP-IBGP peers with RR through private network addresses (bound to VRF2), and ER1, ER2, ER3 and DR all establish MP-IBGP peers with the controller through private network addresses (bound to VRF2).

[0136] Of course, the above Figure 3 , Figure 4 or Figure 5 The internal network topologies listed herein are all based on the example of setting up one ER in each POP. Of course, more ERs can be set up in a POP, and different ERs can also access the same ISP. Similarly, more DRs can be set up in a data center. In other words, the internal network topologies listed in this article are just simple examples. Other internal network topologies are also applicable to the embodiments of this application, and will not be described in detail here.

[0137] In one alternative implementation, the terminal device 110 and the server 120 can communicate via a communication network.

[0138] In one alternative implementation, the communication network is a wired network or a wireless network.

[0139] It should be noted that, Figure 1 The examples shown are merely illustrative; in reality, the number of terminal devices and servers is unlimited and is not specifically limited in the embodiments of this application.

[0140] In this embodiment of the application, when there are multiple servers, the multiple servers can form a blockchain, and the servers are nodes on the blockchain; as disclosed in the routing method of this embodiment, the routing-related data involved can be stored on the blockchain, such as routing information, traffic requests, etc.

[0141] Furthermore, the embodiments of this application can be applied to various scenarios, including but not limited to cloud technology, artificial intelligence, smart transportation, and assisted driving, specifically to business scenarios related to internet access within these contexts. Below are a few common internet access scenarios:

[0142] (a) Online education.

[0143] Online education platforms provide stable internet access through data centers and multiple Points of Presence (POPs), such as computer rooms in schools and educational institutions. Students and teachers securely access internal teaching resources, such as video courses and assignment submission systems, through a private network VRF, while internet access traffic is routed through a public network VRF, with the border router selecting the optimal ISP exit point to ensure smooth video playback and a low-latency interactive experience.

[0144] (ii) Online games.

[0145] Online gaming platforms deploy high-performance servers in data centers, ensuring low-latency access for players worldwide through multiple POPs and ISP connections. Game servers communicate with internal data center equipment via a private VRF network, ensuring the security and stability of game data. Players' internet access traffic is routed through a public VRF network, where border routers select the optimal ISP exit point for fast response and a smooth gaming experience.

[0146] (III) Telemedicine.

[0147] Telemedicine services provide efficient internet access through data centers and multiple Points of Presence (POPs), such as hospital and clinic server rooms. Doctors and patients securely access internal medical systems, such as remote diagnostic platforms, via a private VRF, while internet access traffic is routed through a public VRF, with the border router selecting the optimal ISP exit point to ensure low latency and high reliability for high-definition video conferencing and real-time data transmission.

[0148] (iv) Remote work.

[0149] In remote work scenarios, enterprises provide stable internet access through data centers and multiple Points of Presence (POPs) (such as branch offices or home offices). Employees securely access internal company resources, such as file servers, email systems, and collaboration tools, via private network VRFs, while internet access traffic is routed through public network VRFs, with border routers selecting the optimal ISP exit point to ensure efficient, low-latency network connectivity and data transmission.

[0150] It should be noted that the scenarios listed above are just simple examples. Other scenarios are also applicable to the embodiments of this application, and will not be described in detail here.

[0151] It should be emphasized that the specific embodiments of this application involve object-related data, such as traffic requests listed above. When the above embodiments of this application are applied to specific products or technologies, permission or consent from the object is required, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions.

[0152] The routing method provided by the exemplary embodiments of this application will be described below with reference to the accompanying drawings and the application scenarios described above. It should be noted that the application scenarios described above are only shown to facilitate understanding of the spirit and principles of this application, and the embodiments of this application are not limited in any way.

[0153] The following explanation primarily uses internal networking as an example. Of course, other types of networking follow the same routing method, which will not be elaborated upon here.

[0154] See Figure 6The diagram shown is a flowchart of a routing method provided in this application embodiment, applied to a controller in a network (such as an internal network). The specific implementation process of this method is as follows: S61-S62:

[0155] S61: Using private network addresses, establish MP-IBGP peers with each border router; each border router is configured with a private network VRF and at least one public network VRF; the private network address is bound to the private network VRF.

[0156] Specifically, a VRF created on a network device (such as a border router or a data center router in this article) is also known as a VPN instance. Each VRF has an independent interface, routing table, and routing protocol process. It allows a single physical router to simulate multiple logical routers, enabling multiple independent virtual networks to be supported on the same physical device. This achieves network isolation between different tenants or services and ensures that traffic in each VRF does not interfere with each other.

[0157] In this embodiment, the public network VRF is used to carry traffic for objects accessing the Internet. It uses public IP addresses and connects the data center and the Point of Presence (POP) via a VPN tunnel, which is based on an underlay network. Due to different ISPs and network environments, one or more public network VRFs can be configured on each border router. Different public network VRFs can be configured on different border routers within the internal network of this application to adapt to different public network environments. This helps to achieve multi-ISP load balancing, path optimization, and efficient utilization of network resources.

[0158] The private network VRF in this embodiment is used for communication between internal devices. It uses private network addresses and transmits internal network routes via the IGP protocol, while also carrying VPN tunnel traffic for internal device management and Internet services. To simplify management, share resources, and improve security, only one private network typically exists in the internal network. Therefore, each border router is generally equipped with a private network VRF, and the same private network VRF is generally configured on different border routers in the internal network of this application to ensure the consistency and reliability of the entire network and achieve unified management and maintenance.

[0159] Of course, in some other cases, multiple private network VRFs can also be configured on the border routers and data center routers in this internal network. This article does not specifically limit this. Different private network VRFs correspond to different private network addresses. In this way, when the border routers and data center routers establish MP-IBGP peers with the controller, they can be distinguished by their private network addresses. The specific implementation method is the same as above, and will not be repeated here.

[0160] In this embodiment of the application, VRF can be used to decompose a complex network structure into multiple logically independent networks, simplifying management and maintenance. Each VRF can be configured and managed independently, reducing the complexity of global configuration. The isolation mechanism between private network VRF and public network VRF can effectively prevent traffic interference and potential security threats between different users.

[0161] Furthermore, in this internal network topology, the controller needs to use a private network address to establish an MP-IBGP peer with each border router. Since the private network VRF is bound to this private network address, when the controller establishes an MP-IBGP peer with a border router using its private network address, it is essentially establishing a peer with the private network VRF within that border router. In this way, through MP-IBGP peers, the controller can efficiently propagate routing information to the border routers, ensuring network stability and reliability.

[0162] S62: Send the first routing information to the border router via the MP-IBGP protocol so that the border router can analyze whether the first routing information matches the preset protocol conversion routing policy when performing route cross-injection. If it matches, the address family attribute of the first routing information is changed from VPN type to IP type. Here, route cross-injection refers to injecting the first routing information from the private network VRF into the public network VRF in the border router.

[0163] Among them, route cross-injection refers to the process of importing routing information from one VRF to another within a border router.

[0164] This application considers that the first routing information sent by the controller to the border router via the MP-IBGP protocol has a VPN address family attribute, generally VPNv4 or VPNv6. Therefore, when performing route cross-injection, it is also necessary to analyze whether the first routing information matches the preset protocol conversion matching strategy. If it matches, the address family attribute of the first routing information needs to be converted from VPN type to IP type. If it does not match, when performing route cross-injection, there is no need to convert the address family attribute. The first routing information can be directly injected from the local private network VRF into the public network VRF based on the MP-IBGP protocol.

[0165] Optionally, when the controller sends the first routing information to the border router, it may attach a routing identifier to the first routing information to indicate whether the route needs to undergo protocol conversion. Specifically, the specific types of the attachable routing identifiers are described in the relevant section on the border router side below, and will not be repeated here.

[0166] Based on the above ideas, one optional implementation is that the first routing information carries a target route identifier, so that when the border router performs route cross-injection, it analyzes whether the first routing information matches the protocol conversion routing policy based on the target route identifier; wherein:

[0167] If the target route identifier is a route identifier of the specified type, then the first routing information is determined to match the protocol conversion routing policy; if the target route identifier is not a route identifier of the specified type, then the first routing information is determined not to match the protocol conversion routing policy.

[0168] In simple terms, when the border router receives the first routing information from the controller, it first extracts the target route identifier carried in the first routing information, and then analyzes whether the target route identifier belongs to the specified type in its newly configured protocol conversion routing policy. Based on whether the target routing information is a route identifier of the specified type, it can determine whether the first routing information matches the protocol conversion routing policy. Of course, other methods for analyzing whether the first routing information matches the protocol conversion routing policy in this application are also applicable. For the specific judgment logic, please refer to the relevant description on the border router side below, which will not be repeated here.

[0169] In the above implementation, when the controller sends routing information to the border router, it can indicate that the routing information needs to be converted to a certain protocol type by attaching a specific routing identifier (i.e., a routing identifier of a specified type). These simple additional routing identifiers can be used to implement complex routing policies and ensure that routing information is correctly transmitted between different protocols.

[0170] The following is a detailed explanation of the process by which the controller sends out routing information:

[0171] Routing information refers to information used to determine the transmission path of a message, and it is generated based on a routing algorithm. A routing message can contain three elements: destination address, subnet mask, and next hop.

[0172] The destination address refers to the IP address of the network to which the data packet will ultimately be delivered, such as the address of an ISP network. The subnet mask is a 32-bit binary number used to distinguish between the network and host portions of an IP address. Consecutive 1s in the subnet mask represent the network portion, and 0s represent the host portion. The next hop is the address of the next router to which the data packet should be forwarded, controlling the forwarding path of the data packet and ensuring that it is transmitted along the expected path. When a data packet does not reach its destination address, the next hop can be used to propagate the data packet until it reaches its destination.

[0173] In practical applications, the network portion defined by the destination address and subnet mask is the routing prefix, which refers to the network prefix that specifies the route, such as 1.0.0.0 / 24. Here, / 24 indicates that the first 24 bits of the subnet mask are 1, i.e., 255.255.255.0.

[0174] The routing method in this application is mainly used for traffic scheduling from the internal data center to different exits of the POP point. Therefore, in this embodiment, the controller, as an internal routing scheduling device, needs to simultaneously implement routing scheduling from the internal data center to the POP and routing scheduling of specific ISP exits on the ER device. This complex but important task can improve network performance, ensure QoS, and meet specific security requirements.

[0175] In this paper, the first routing information is sent by the controller to the ER in the POP, and is mainly used to implement the scheduling of specific ISP exit routes on the ER device.

[0176] In modern network architectures, businesses or organizations typically connect to the Internet through multiple ISPs to achieve redundancy and load balancing.

[0177] Optionally, each border router in the internal network of this application is connected to at least two ISPs. This configuration is usually used to achieve load balancing, redundancy backup and path optimization of multiple ISPs. By connecting to multiple ISPs, even if one ISP fails, the network can still continue to operate normally through other ISPs, improving the reliability and availability of the network. It also makes it easier to dynamically select the optimal ISP exit according to network conditions and business needs, thereby improving the speed and quality of data transmission.

[0178] To meet specific business needs, it is sometimes necessary to force traffic from certain network segments to pass through a specific ISP's exit point. Of course, for various reasons, such as performance optimization, cost savings, security requirements, or the target ISP in the internal network providing better service quality to a specific destination network, it is also necessary to force traffic from certain network segments to pass through a specific ISP's exit point in certain scenarios.

[0179] Below are some practical application scenarios that require specifying an ISP exit point:

[0180] (1) Geolocation services: Some applications or services may rely on geolocation information, such as online map services. To obtain more accurate location data, it may be necessary to connect to a geolocation-related service provider through a specific ISP exit.

[0181] For example, when accessing services from a local data center, selecting the local ISP exit point can reduce transmission distance and lower latency by directing traffic from a specific network segment to the geographically nearest ISP exit point.

[0182] (2) Access to copyrighted content: Streaming services may have regional restrictions. To legally access these services, you can go through a specific ISP exit to comply with the content provider’s geographic restriction policy.

[0183] For example, an online video platform may have different content libraries in different regions. To ensure that users can legally access specific content in their region, the platform configures specific ISP exits. For instance, when a user located in region A accesses the video platform, traffic is routed through the designated ISP exit for that region, ensuring compliance with the content provider's geographic restriction policies and avoiding copyright violations.

[0184] (3) Corporate compliance: Some large enterprises may have strict network access policies that require certain types of data traffic to pass through specific ISP exits in order to comply with data residency or privacy protection regulations.

[0185] For example, a branch of a multinational corporation in country B needs to access the headquarters' data center. According to country B's data residency regulations, all traffic involving sensitive data must pass through a local ISP. Therefore, the company configures a specific ISP exit point to ensure that all sensitive data traffic is transmitted through the local ISP, complying with local data protection and privacy regulations.

[0186] In this embodiment, when a user requests access to a specific network segment, and the designated traffic exit for that network segment is a target ISP among at least two ISPs, the user's traffic request needs to be forwarded through the target ISP's exit. To achieve specific ISP exit route scheduling on the ER device, this application configures corresponding policies on the controller to ensure that routing selection throughout the network meets this requirement.

[0187] An optional implementation method is as follows:

[0188] In scenarios where an object requests access to a specific network segment, and the traffic exit specified for that specific network segment is the target ISP among at least two ISPs, the controller needs to send the first routing information to the target border router among each border router via the MP-IBGP protocol.

[0189] Among them, the target border router is the border router that connects to the target ISP among all border routers; and the routing prefix in the first routing information is a specific network segment, and the next hop points to the target ISP. Specifically, the next hop is the peer address of the target ISP.

[0190] In this way, after receiving the first routing information, the target border router will first analyze the target route identifier contained in the first routing information to see if it is a route identifier of a specified type. If it is, it means that the first routing information matches the protocol conversion routing policy. After converting the address family attribute of the first routing information, it will import it into its local public network VRF, specifically, add it to the routing table of the VRF.

[0191] Subsequently, after receiving a traffic request for a specific network segment, the target border router can forward the traffic request to the target ISP based on the first routing information in the previous public network VRF.

[0192] As mentioned above Figure 3 Taking the internal network shown as an example, suppose there is an internal network with a specific network segment 1.0.0.0 / 24 that needs to access the Internet through the exit of ISP3. That is, the target ISP is ISP3 and the target border router is ER2. Therefore, when configuring the first routing information, the controller directs the traffic of the specific network segment 1.0.0.0 / 24 to the exit of ISP3 in POP2 and sets the next hop to ISP3. When performing route scheduling, the controller needs to send the first routing information (such as VPNv4 or VPNv6 routes) to ER2 in POP2 through the MP-IBGP protocol. The routing prefix in the first routing information is 1.0.0.0 / 24, and the next hop points to ISP3. Specifically, the next hop is the peer address of ISP3.

[0193] For example Figure 4 The internal network shown assumes an internal network with a specific network segment 192.168.1.0 / 24 that needs to access the Internet through the exit of ISP2. That is, the target ISP is ISP2, and the target border router is ER1. Therefore, when configuring the first routing information, the controller directs the traffic of the specific network segment 192.168.1.0 / 24 to the ISP2 exit of POP1 and sets the next hop to ISP2. During route scheduling, the controller needs to send the first routing information (such as a VPNv4 or VPNv6 route) to ER1 in POP1 via the MP-IBGP protocol. The route prefix in this first routing information is 192.168.1.0 / 24, and the next hop points to ISP2. Specifically, the next hop is the peer address of ISP2.

[0194] For example Figure 5The internal network shown assumes an internal network with a specific network segment 10.0.0.0 / 24 that needs to access the Internet through the exit of ISP5. That is, the target ISP is ISP5, and the target border router is ER3. Therefore, when configuring the first routing information, the controller directs the traffic of the specific network segment 10.0.0.0 / 24 to the ISP5 exit of PO3 and sets the next hop to ISP5. During route scheduling, the controller needs to send the first routing information (such as a VPNv4 or VPNv6 route) to ER3 in POP3 via the MP-IBGP protocol. The route prefix in this first routing information is 10.0.0.0 / 24, and the next hop points to ISP5. Specifically, the next hop is the peer address of ISP5.

[0195] In the above implementation, routing information for a specific network segment is sent to the target border router via the MP-IBGP protocol. The controller can precisely control the routing of traffic from that specific network segment to the designated ISP. This ensures that traffic is not incorrectly routed to other ISPs, improving the accuracy and controllability of routing. Furthermore, based on this idea, different routing policies can be configured for different objects (users or applications) and specific network segments, achieving fine-grained traffic management and optimization. Through these technologies and methods, routing scheduling and ISP egress selection in internal networks can be effectively implemented, meeting the needs of various complex scenarios. This is particularly useful in complex enterprise networks, ensuring the efficient and secure operation of critical services.

[0196] It should be noted that the first routing information sent by the controller to the border router in the POP, as listed above, is mainly for the scheduling of specific ISP exit routes on the ER device.

[0197] To further ensure optimal routing, a priority can be set for the first routing information, and this priority can be added to the first routing information. One possible implementation is as follows:

[0198] The first routing information has the highest priority within the specified routing information range, which includes: all routing information from the destination border router to a specific network segment.

[0199] In BGP, routing priority is an attribute used internally. It can be represented by a numerical value indicating the order in which routing information is prioritized, thus influencing route selection. Generally, a higher value indicates higher priority. Specifically, when multiple routing entries point to the same destination network (such as a specific network segment), priority determines which routing entry will be selected to ensure that data packets are transmitted through the optimal path, improving network performance and reliability.

[0200] In this embodiment, the local preference or weight attribute in BGP can be set in the first routing information to indicate its priority. The larger the value of the local preference or weight, the higher the priority, and the more likely the first routing information is to be selected first. Of course, other attributes can also be used to indicate the priority of routing information, which will not be elaborated here.

[0201] Specifically, among the routing information of the target network that the target border router points to a specific network segment, the first routing information has the highest priority. This ensures that traffic requests for a specific network segment are forwarded based on the first routing information and are preferentially forwarded through the target ISP exit indicated in the first routing information.

[0202] For example, if the highest priority is 10, then the priority can be set to 10 in the first routing information. This ensures that the routing information takes precedence over any other routing information in the target border router's public VRF routing table. This means that when multiple routing information matches the same destination, this route will be selected first. In other words, all traffic from the internal network to a specific network segment will preferentially pass through the target border router and then access the Internet through the target ISP's exit, avoiding the uncertainty and potential problems caused by routing conflicts. For critical services or high-priority applications, ensuring that their traffic always passes through the designated ISP exit can improve the reliability and performance of these services.

[0203] In the above implementation, the priority of the first routing information is set to the highest. This ensures that traffic in a specific network segment will preferentially pass through the target ISP exit, achieving precise control over traffic in that specific network segment, optimizing network performance, ensuring the efficient and secure operation of critical services, and meeting the requirements for data residency and privacy protection. Especially when sensitive data is involved, by specifying the ISP exit, traffic of sensitive data or critical services can be isolated from other traffic, reducing the risk of being attacked.

[0204] Of course, besides the cases mentioned above where the target needs to access a specific network segment and therefore specifies an ISP exit, there are other scenarios where specifying an ISP exit also exists. Here are a few examples:

[0205] (1) Cost optimization: Different ISPs may have different pricing strategies. In order to reduce costs, enterprises may choose to pass certain types of traffic (such as mass downloads) through the ISP with lower costs; (2) Bandwidth management: During peak hours, in order to ensure the bandwidth requirements of critical businesses, non-critical traffic may be redirected to other ISPs to avoid affecting the performance of important businesses; (3) Security isolation: In order to enhance security, traffic of certain sensitive data or applications may be passed through dedicated, more secure ISPs to reduce the risk of being attacked; (4) Specific application requirements: Some applications may have special requirements for the network environment. For example, financial trading systems may require low-latency network connections, and in this case, they will choose ISPs with the best network characteristics; etc.

[0206] It should be noted that the method by which the controller issues the first routing information is not limited to the case where the object requests access to a specific network segment. In addition, cost optimization, bandwidth management, security isolation, specific application requirements, etc., as listed above, or some other situations not listed in this article, are also applicable to the embodiments of this application. That is to say, the target ISP in this application is not limited to one or more traffic exits specified in a specific network segment, but can also be one or more traffic exits specified based on some other factors, such as low-cost ISP exits, secure ISP exits, etc., which will not be elaborated here.

[0207] The above describes the process by which the controller sends routing information to the border routers in the POP. This process is mainly for implementing specific ISP outbound route scheduling on the ER device. However, in this internal network, the controller also needs to implement route scheduling from the internal data center to the POP to ensure that traffic requests initiated by objects through the data center can be successfully forwarded to the ER device. An optional implementation method is as follows:

[0208] The controller also uses private network addresses to establish MP-IBGP peers with each data center router. In this way, through MP-IBGP peers, the controller can efficiently propagate routing information to the border routers to ensure network stability and reliability.

[0209] Each data center router is configured with a private network VRF and at least one public network VRF. The private network VRF is bound to the private network address. Therefore, when the controller uses the private network address to establish an MP-IBGP peer with the data center router, it is essentially establishing a peer with the private network VRF in the data center router.

[0210] It should be noted that the process of the controller establishing an MP-IBGP peer with the DR is essentially the same as the process of the controller establishing an MP-IBGP peer with the ER, and will not be repeated here.

[0211] Based on the above, when the controller performs route scheduling, it can send the second route information to the data center router through the MP-IBGP protocol.

[0212] The second routing information in this article is sent by the controller to the DR in the data center, and is mainly used to implement route scheduling from the data center to the POP.

[0213] In this second routing information, the routing prefix is ​​a specific network segment, and the next hop points to the target border router. Specifically, the next hop is the peer address of the target border router.

[0214] Unlike the first routing information, the second routing information includes an MPLS label in addition to the routing prefix and next hop. This MPLS label is the label corresponding to the target ISP, which enables the data center router to forward traffic requests for a specific network segment to the public network VRF in the target border router through an MPLS tunnel. The MPLS tunnel is established based on this MPLS label.

[0215] In this embodiment, the MPLS label is specifically a label assigned to the target ISP egress of the target border router. The label of the ISP egress can be learned through global planning or through MP-IBGP route learning between the controller and the target border router, and is used for fast forwarding in the MPLS network.

[0216] The learning process of this MPLS tag will be briefly explained below:

[0217] Method 1: Global planning, which is a static allocation method.

[0218] Specifically, this refers to pre-determining the label assignment for each ISP exit during the network design phase. This method is simple, straightforward, and has fixed configurations, making it suitable for small networks. Under this approach, network administrators can pre-assign a unique MPLS label to each ISP exit within the internal network.

[0219] As mentioned above Figure 3 Taking the internal network shown as an example, let's assume it's... Figure 3 The label assigned to ISP1 is L1, to ISP2 is L2, to ISP3 is L3, and to ISP4 is L4. If the destination ISP is ISP3, then the MPLS label carried in the second routing information will be L3. Similarly, if the destination ISP is ISP2, then the MPLS label carried in the second routing information will be L2, and so on.

[0220] Suppose there is an internal network with a specific network segment 1.0.0.0 / 24 that needs to access the Internet through the ISP3 egress point. Therefore, when configuring the second routing information, the controller directs traffic from the 1.0.0.0 / 24 network segment to the ISP3 egress point of POP2 and sets the next hop to ER2. Static MPLS label binding is configured on the controller to bind the traffic from this network segment to label L3. During route scheduling, the controller needs to send the second routing information (such as VPNv4 or VPNv6 routes) to the DR in the data center via the MP-IBGP protocol. This second routing information contains an MPLS label of L3, a route prefix of 1.0.0.0 / 24, and the next hop is set to ER2, specifically the peer address of ER2.

[0221] For example, the controller sends VPNv4 routes with L3 labels to the DR via MP-IBGP. After receiving the route, the DR will forward the traffic to ER2 according to the L3 label.

[0222] For example, still using the above... Figure 4 Taking the internal network shown as an example, let's assume it's... Figure 4 The label assigned to ISP1 is L5, the label assigned to ISP2 is L6, and the label assigned to ISP3 is L7.

[0223] Suppose there is an internal network with a specific network segment, 192.168.1.0 / 24, that needs to access the internet through the egress of ISP2. Therefore, when configuring the second routing information, the controller directs traffic from the 192.168.1.0 / 24 network segment to the ISP2 egress of POP1 and sets the next hop to ER1. Static MPLS label binding is configured on the controller to bind the traffic from this network segment to label L6. During route scheduling, the second routing information (such as VPNv4 or VPNv6 routes) needs to be sent to the DR in the data center via the MP-IBGP protocol. This second routing information uses the MPLS label L6, the route prefix is ​​192.168.1.0 / 24, and the next hop points to ER1; specifically, the next hop is the peer address of ER1.

[0224] For example, the controller sends VPNv6 routes with L6 labels to the DR via MP-IBGP. After receiving the route, the DR will forward the traffic to ER1 according to the L6 label.

[0225] Similarly, the above applies. Figure 5 Taking the internal network shown as an example, let's assume it's... Figure 5 The label assigned to ISP1 is L8, the label assigned to ISP2 is L9, the label assigned to ISP3 is L10, the label assigned to ISP4 is L11, and the label assigned to ISP5 is L12.

[0226] Suppose there is an internal network with a specific network segment 10.0.0.0 / 24 that needs to access the Internet through the ISP5 egress. Therefore, when configuring the second routing information, the controller directs traffic from the 10.0.0.0 / 24 network segment to the ISP5 egress of POP3 and sets the next hop to ER3. Static MPLS label binding is configured on the controller to bind the traffic from this network segment to label L12. During route scheduling, the second routing information (such as VPNv4 or VPNv6 routes) needs to be sent to the DR in the data center via the MP-IBGP protocol. This second routing information has an MPLS label of L12, a route prefix of 10.0.0.0 / 24, and the next hop is set to ER3, specifically the peer address of ER3.

[0227] For example, the controller sends VPNv6 routes with label L12 to the DR via MP-IBGP. After receiving the route, the DR will forward the traffic to ER3 according to the label L12.

[0228] Similarly, the above static allocation method can also be used in other internal networks, with the specific implementation methods being the same as above, and will not be described in detail here.

[0229] Method 2: Learning routes through MP-IBGP between the controller and the target border router is a dynamic learning method.

[0230] Specifically, this refers to the automatic learning and allocation of labels through dynamic routing protocols (such as MP-IBGP) during network operation. This method has a high degree of automation, can adapt to changes in network topology, and is suitable for large dynamic networks.

[0231] As mentioned above Figure 3 For example, assuming the target ISP is ISP3 and the target border router is ER2. In this mode, ER2 can learn the egress labels (i.e., MPLS labels) from ISP3 through the MP-IBGP protocol and pass these labels to the DR. The labels carried by the routes received by the DR must match the labels assigned to ER2's ISP3 egress. This ensures that traffic is correctly forwarded to ER2 through the MPLS tunnel, which is established based on MPLS labels.

[0232] For example, the controller establishes an MP-IBGP session with ER2, learns the L2 label assigned by ER2 to the ISP3 egress point via MP-IBGP, and then directs traffic from a specific network segment (e.g., 1.0.0.0 / 24) to the ISP3 egress point of POP2, setting the next hop to ER2. The controller then sends secondary routing information (such as VPNv4 or VPNv6 routes) with L2 labels to the DR via MP-IBGP. Upon receiving the route, the DR forwards the traffic to ER2 based on the L2 label.

[0233] Similarly, in Figure 4 or Figure 5 The above-mentioned dynamic learning method can also be used in the listed internal networks or other internal networks. The specific implementation methods are the same as above, and will not be described in detail here.

[0234] In this embodiment, MPLS labels are carried in the second routing information. Label matching ensures that traffic is forwarded along a predetermined path, avoiding unnecessary intermediate nodes and improving forwarding efficiency. Furthermore, this method enables precise scheduling of traffic within specific network segments, ensuring that this traffic passes through the target ISP's exit point, thus achieving on-demand scheduling of user traffic.

[0235] It should be noted that, regardless of whether global planning or MP-IBGP learning is used, it is necessary to ensure that each ISP egress has a unique MPLS label. Furthermore, the two MPLS label learning processes listed above are merely simplified examples. In practical applications, appropriate methods can be flexibly selected based on network topology and other factors to determine the MPLS label, which will not be elaborated upon here.

[0236] Furthermore, it should be noted that the second routing information sent by the controller to the data center router, as listed above, is primarily for route scheduling from the data center to the POP. Compared to the second routing information, the first routing information does not need to carry an MPLS label because forwarding between the data center and the POP is done through an MPLS network, and the POP is the endpoint of the MPLS network. The ER within the POP is not part of the MPLS network, so an MPLS label is no longer needed to guide traffic forwarding.

[0237] To further ensure optimal routing, a priority can be set in this second routing information. One possible implementation is as follows:

[0238] The priority of the second routing information is higher than the specified priority. The specified priority refers to the priority of the routing information learned by the target ISP and passed to the data center router through RR.

[0239] In the internal network architecture of this application, all ERs and DRs can also establish MP-IBGP peers with RRs using private network addresses, thereby reducing the need for full mesh connectivity and simplifying BGP configuration. Simultaneously, public network routes learned by ER1 from external networks (such as ISP networks) can be passed to RRs via MP-IBGP. RRs will then reflect the routes learned from ERs to other ERs or DRs. Other ERs or DRs receive the routes reflected by RRs and add them to their own routing tables, thus achieving full network transmission of public network routes.

[0240] In this embodiment of the application, the Local Preference or Weight attribute in BGP can also be set in the second routing information to indicate its priority. The larger the value of Local Preference or Weight, the higher the priority, and the easier it is for the second routing information to be selected first.

[0241] For example, if the highest priority is 10, then the priority can be set to 10 in the first routing information. The priority (i.e., the specified priority) of the routing information learned by the target ISP and passed to the data center router through RR is 6. Then the priority of the second routing information can be between 6 and 10, such as any value of 7, 8 or 9. This setting ensures that critical business or high-priority application traffic is always transmitted through the optimal path, improving network reliability and performance, while reserving other paths as backups, enhancing network redundancy and stability.

[0242] It should be noted that, in this embodiment, the order in which the controller sends the second routing information to the data center router and the first routing information to the border router in the POP is not specifically limited. In practical applications, it is necessary to ensure that the DR first forwards the traffic request for a specific network segment to the target ER based on the previously injected second routing information, and then the target ER forwards the traffic request out through the target ISP's exit based on the previously injected first routing information.

[0243] In summary, the controller, acting as the central management device, communicates with all scheduling routers across the network (such as the border routers and data center routers in this paper) through the internal network, establishing MP-IBGP peers. Then, based on policies, it converts specific VPNv4 / 6 routes published by some MP-IBGP peers into IPv4 / 6 routes for this VRF. This enables routing and scheduling capabilities for multiple protocols without altering the original network topology, ensuring on-demand traffic scheduling. This network structure ensures high network performance, reliability, and flexibility.

[0244] The following example illustrates the implementation logic of the controller sending routing information, using a scenario where all traffic from a user requesting access to a specific network segment 1.0.0.0 / 24 must go through the POP2 ISP3 exit:

[0245] like Figure 7 As shown, this is a schematic diagram of a controller issuing routing information in an embodiment of this application. The specific implementation logic is as follows:

[0246] First, the controller needs to send a second route information to the DR via the MP-IBGP protocol. This second route information is a VPNv4 route with a route prefix of 1.0.0.0 / 24, a next hop pointing to ER2, and carries an MPLS label corresponding to the ISP3 egress (this label is obtained through global planning or dynamic learning, see the above embodiment for details). The priority of this route is set higher than the priority of routes learned by ISP3 on ER2 that are passed to the DR via RR, ensuring optimal route scheduling. This guarantees that traffic from the DR to the 1.0.0.0 / 24 network segment will be forwarded to ER2 via an MPLS tunnel, which is established based on the MPLS label.

[0247] Secondly, since the ISP3 exit point also needs to be specified, the controller needs to send the first route information to ER2 via the MP-IBGP protocol. This first route information is also a VPNv4 route with a route prefix of 1.0.0.0 / 24, a next hop pointing to ISP3, and carries a destination route identifier, such as a 1:1 community attribute and the highest priority. When ER2 receives this VPNv4 route and performs route cross-injection into VRF1, because it carries a 1:1 community attribute, it matches the protocol conversion filtering policy. Therefore, the protocol conversion logic is performed, modifying the next hop VRF to VRF1 itself. This makes the route an effective IPv4 intra-VRF route pointing to ISP3, and due to its high priority, it will be preferred and ultimately guide traffic forwarding.

[0248] In summary, this ensures that when a user accesses 1.0.0.0 / 24 and its traffic enters VRF1 of ER2, the IPv4 routing table is queried, and the traffic is matched with the scheduled route issued by the controller, thus forwarding the traffic out from ISP3. This achieves the ability to schedule user traffic on demand.

[0249] Of course, the above example uses VPNv4 as the first routing information. If it is IPv6 routing, the overall logic is the same. By configuring the protocol conversion policy on the VPNv6 address family, the matching policy is converted to IPv6 route, thereby realizing the scheduling and routing of both VPNv6 and IPv6 routes.

[0250] In the above implementation, by centrally managing routing information through the controller, network traffic can be managed more easily, network visibility and manageability can be improved, all relevant devices can be ensured to follow the same routing policy, and network consistency and predictability can be maintained.

[0251] In this embodiment of the application, the above configuration can be used to implement a routing policy that allows user traffic to access a specific network segment to pass through a specific ISP exit.

[0252] It should be noted that the above mainly describes the route distribution method from the controller side. The following describes the route distribution method in this application embodiment from the perspective of the border router (specifically, the target border router):

[0253] In the internal network of this application, each border router establishes an MP-IBGP peer with the controller, and adds a protocol conversion routing policy based on the peer on the corresponding VPNv4 and VPNv6 address families.

[0254] See Figure 8 The diagram shown is an implementation flowchart of another route distribution method provided in this application embodiment, applied to a border router in an internal network. The specific implementation process of this method is as follows: S81-S82:

[0255] S81: Receives the first routing information sent by the controller via the MP-IBGP protocol.

[0256] S82: When performing route cross-injection, analyze whether the first route information matches the preset protocol conversion route policy.

[0257] In the standard MP-IBGP protocol, when a border router receives a VPNv4 / v6 route from the controller, the next hop is set to the next hop of the VRF where the peer resides by default. In this application, the controller establishes an MP-IBGP peer with the border router using a private network address, and this private network address is bound to a private network VRF. Therefore, the default next hop VRF in the MP-IBGP protocol is the private network VRF. However, when accessing the Internet, routing needs to be performed through a public network VRF to forward traffic requests to the ISP. Therefore, route cross-injection is required within the border router to inject the first routing information from the private network VRF in the border router into the public network VRF, enabling routing information sharing between different VRFs and ensuring correct traffic forwarding.

[0258] However, the controller sends the first routing information to the border router via the MP-IBGP protocol. This first routing information is a VPNv4 / 6 route. Therefore, a protocol translation routing policy based on this peer is newly configured on the corresponding VPNv4 and VPNv6 address families on the border router side. Thus, if a route received from a peer under the VPNv4 / v6 address family matches this protocol translation routing policy, the route's address family attribute will be converted to the IPv4 / v6 address family when performing route cross-injection into the corresponding VRF. If the protocol translation routing policy does not match, the MP-IBGP protocol is still used for route cross-injection. That is, during route cross-injection, no address family attribute conversion is needed; the first routing information can be directly injected from the local private network VRF into the public network VRF based on the MP-IBGP protocol.

[0259] The following section elaborates on the matching process of protocol conversion routing policies:

[0260] Optionally, if the first routing information carries a destination route identifier, then the first routing information can be analyzed based on the destination route identifier to determine whether it matches a preset protocol conversion routing strategy. Specifically, this includes the following two cases:

[0261] (1) If the target route identifier is a route identifier of a specified type, then the first route information is determined to match the protocol conversion route policy.

[0262] (2) If the target route identifier is not a route identifier of the specified type, it is determined that the first route information does not match the protocol conversion route policy.

[0263] In this embodiment, the first routing information includes a routing prefix and next hop, and may also include a priority. Furthermore, it may include a destination route identifier. The protocol conversion routing strategy in this application is a preset strategy that defines a series of rules for determining whether to perform protocol conversion on the first routing information, such as analyzing whether the destination route identifier is a route identifier of a specified type.

[0264] Specifically, when the controller sends the first routing information to the border router, it can attach a routing identifier to the first routing information, which is called the target routing identifier. The target routing identifier is used to indicate whether the route needs to be converted to a different protocol.

[0265] When a border router receives the first routing information from the controller, it first extracts the target route identifier carried in the first routing information. Then, it analyzes whether the target route identifier belongs to a specified type in its newly configured protocol conversion routing policy. Based on whether the target routing information is a route identifier of a specified type, it can determine whether the first routing information matches the protocol conversion routing policy. This analysis process ensures that the processing of the first routing information conforms to the preset protocol conversion routing policy, thereby achieving more refined network management and optimization.

[0266] In one optional implementation, the route identifier of the specified type in this application can specifically be represented as a route attribute of a certain specified type among multiple route attributes, such as route type, route source, etc. Thus, if the target route identifier is of the specified type defined in the preset policy, it is determined that the first route information matches the protocol conversion route policy; conversely, if the target route identifier is not of the specified type defined in the preset policy, it is determined that the first route information does not match the protocol conversion route policy.

[0267] In another optional implementation, the route identifier of the type specified in this application can also be represented as: the route attribute with a specified value in one or more route attributes, such as community attribute 1:1, extended community attribute 1:1, etc. Thus, if the target route identifier is of the specified type or specified value defined in the preset policy, it is determined that the first route information matches the protocol conversion route policy; conversely, if the target route identifier is not the specified value defined in the preset policy, it is determined that the first route information does not match the protocol conversion route policy.

[0268] This flexibility allows for more granular and diverse configuration of routing policies.

[0269] The above examples illustrate how to analyze whether a route conforms to a preset protocol conversion routing strategy by appending a target route identifier to the first routing information. Of course, this application also supports other methods for analyzing whether the first routing information conforms to a preset protocol conversion routing strategy. Several methods are briefly listed below:

[0270] For example, the target route identifier can also be empty, meaning that when the controller sends the first routing information, it does not actually carry a route identifier. In this case, it can be determined whether the first routing information matches the protocol conversion routing policy. That is, the first routing information is analyzed to determine whether it conforms to the preset protocol conversion routing policy based on whether a target route identifier (such as community attribute 1:1) is added. Specifically, after the border router receives the first routing information, it determines whether the first routing information contains a target route identifier (here, the target route identifier is the same as the specified type of route identifier listed above). If a target route identifier is present, it is determined that it matches the protocol conversion routing policy of this application; if no target route identifier is present, it is determined that it does not match the protocol conversion routing policy.

[0271] For example, by examining the combination of the routing prefix and next hop in the first routing information, it can be determined whether it conforms to the preset protocol conversion routing policy. Specifically, after receiving the first routing information, the border router extracts the routing prefix and next hop from the first routing information, compares the extracted combination with the combinations in the preset policy, and if the combination is defined in the preset policy (e.g., a specific network segment + target ISP), it is determined that it matches the protocol conversion routing policy of this application; otherwise, it is determined that it does not match the protocol conversion routing policy.

[0272] The methods listed above provide a variety of flexible ways to analyze whether the first routing information conforms to the preset protocol conversion routing strategy, and the appropriate method can be selected according to actual needs. Furthermore, the methods listed above are merely simple examples; other methods are also applicable to the embodiments of this application, and will not be elaborated upon here.

[0273] The following example uses a route attribute with a specified value for a specified route identifier type to provide a brief explanation of the specified route identifier type:

[0274] Optionally, the route identifier of the specified type includes at least one of the following: specifying a community attribute, specifying an extended community attribute.

[0275] In BGP, community attributes are optional transitive attributes used to mark routing information and influence route selection and propagation behavior. In practice, a community attribute is typically a 32-bit unsigned integer, usually represented in the form AS:Value, where AS is the Autonomous System Number and Value is a 16-bit value. Specifying a community attribute means that this 32-bit unsigned integer is a predefined value, such as 1:1, where the first 1 is the Autonomous System Number (16 bits) and the second 1 is a user-defined value (16 bits). Of course, 1:1 is just a simple example; a specified community attribute can be any other user-defined community attribute, such as 1:2, 1:3, 10:4, etc.

[0276] In this application embodiment, the community attribute can be used as a routing identifier, attached to the routing information sent by the controller to the border router, to identify certain characteristics or uses of the route. For example, in this application, a specified community attribute is used to identify that the route requires protocol conversion. If a certain routing information contains the specified community attribute (e.g., community attribute 1:1), then the routing information matches the protocol conversion routing strategy in this application.

[0277] Similarly, an extended community property is an 8-byte (64-bit) value, typically represented in the form of Type:Value, where Type represents the property type and Value represents the specific value. Specifying an extended community property means that the 8-byte value is a predefined numerical value, such as 10:4, where the first 10 is the property type, occupying 16 bits, and the second 4 is the specific value, occupying 48 bits. Likewise, the extended community property 10:4 is just a simple example; besides this, a specified extended community property can also be any other custom extended community property, such as 1:1, 1:3, 5:7, etc.

[0278] In this application embodiment, the extended community attribute can also serve as a routing identifier, appended to the routing information sent by the controller to the border router, to identify certain characteristics or uses of the route. For example, in this application, the extended community attribute is specified to indicate that the route requires protocol conversion. If a routing information contains the specified extended community attribute (e.g., extended community attribute 10:4), then the routing information matches the protocol conversion routing strategy in this application.

[0279] Of course, routing information can also include both community attributes and extended community attributes. That is, in this embodiment, the combination of community attributes and extended community attributes is used as a routing identifier and appended to the routing information sent by the controller to the border router to identify certain characteristics or uses of the route. For example, in this application, specifying a community attribute and specifying an extended community attribute indicates that the route needs to undergo protocol conversion. If a routing information contains both a specified community attribute and a specified extended community attribute (e.g., community attribute 1:1, extended community attribute 10:4), then the routing information matches the protocol conversion routing strategy in this application.

[0280] It should be noted that the examples listed above, using at least one of community attributes and extended community attributes as route identifiers, are just simple examples. Other information can also be used as route identifiers to indicate whether route information matches a protocol route translation policy: For example, AS_PATH represents the list of Autonomous Systems (AS) traversed by the route. If AS_PATH contains a specific AS number (e.g., 1), it indicates that the route requires protocol translation. Another example is Local Pref, which represents the local priority and is used to select the best path among multiple available paths. If the Local Pref value is a specific value (e.g., highest), it indicates that the route requires protocol translation. Yet another example is MED, which is used to influence the selection of external neighbors when there are multiple ingress points within the same Autonomous System. If the MED value is a specific value (e.g., 100), it indicates that the route requires protocol translation. Next Hop represents the IP address of the next-hop router, used to determine the next-hop address for packet forwarding. If the Next Hop value is a specific address (e.g., the peer address of the target ISP), it indicates that the route requires protocol translation.

[0281] The attributes listed above can be used to identify specific routes and perform corresponding protocol conversion operations when these attributes are matched. Of course, these attributes can also be combined as route identifiers in the embodiments of this application. In addition, it should be emphasized that other route identifiers not listed above are also applicable to the embodiments of this application, and will not be described in detail here.

[0282] In the above implementation, by using specific community attributes or extended community attributes, or some other attributes, it is possible to indicate that routing information needs to undergo a certain protocol type conversion. These attributes can be used to implement complex routing strategies to ensure that routing information is correctly transmitted between different protocols.

[0283] S83: If a match is found, the address family attribute of the first routing information is changed from VPN type to IP type, and the next-hop VRF of the first routing information is changed from private network VRF to public network VRF in the border router, so as to inject the first routing information from the local private network VRF into the public network VRF.

[0284] Referring to the above, in the internal network proposed in this application, each border router can be configured with one or more public network VRFs, such as... Figure 3 or Figure 5 In this context, each ER is configured with a public VRF, for example... Figure 4 In this scenario, an ER (Executor) is configured with two public VRFs. Therefore, during route cross-injection, the first route information can be injected from the ER's local private VRF into the public VRF in the following way:

[0285] If there is only one public VRF inside the border router, then the route cross-injection is specifically imported from the private VRF in the border router into the public VRF.

[0286] like Figure 3 In this context, ER2 uses a private network address (bound to VRF2) to establish an MP-IBGP peer with the controller. In other words, the first routing information received by this border router has VRF2 as the default next hop. Therefore, it needs to be imported from VRF2 in ER2 to VRF1.

[0287] If multiple public VRFs exist within the border router, the following two scenarios can be considered:

[0288] Scenario 1: Router cross-injection can be caused by importing private network VRFs from the border router into various public network VRFs within the border router.

[0289] like Figure 4 As shown, there are two public network VRFs in ER1, such as VRF1 and VRF2. Therefore, the first routing information can be imported from VRF2 in ER1 into VRF1 and VRF3 respectively.

[0290] Scenario 2: Route cross-injection can also import only a portion of the VRFs from the border router. Which specific VRFs to import can be further divided into the following sub-scenarios:

[0291] Sub-case 1: Import at least the public VRF corresponding to the target ISP from the border router.

[0292] Still with Figure 4 As shown in the example, there are two public network VRFs in ER1, such as VRF1 and VRF2. Assuming that the target ISP is ISP3 and the public network VRF corresponding to ISP3 is VRF3, then the first routing information can be imported from VRF2 in ER1 to VRF3.

[0293] Sub-case 2: Randomly import one or more public network VRFs from the border router.

[0294] Still with Figure 4 For example, the first routing information can be randomly imported from VRF2 in ER1 to VRF3, or randomly imported from VRF1, and so on.

[0295] It should be noted that the injection methods listed above are just simple examples. Other injection methods are also applicable to the embodiments of this application, and will not be described in detail here.

[0296] In S83, before injecting the first routing information into the route cross-connection, the address family attribute of the first routing information needs to be converted. The specific process is as follows:

[0297] In this embodiment, the POP is the endpoint of the MPLS network. The connection between the ER and the ISP in the POP is a non-MPLS network. While the MPLS network uses VPNv4 / 6 routing, the non-MPLS network uses ordinary IPv4 / 6 routing. Therefore, the address family attribute of the first routing information needs to be converted from VPN type to IP type. An optional implementation is as follows:

[0298] If the first routing information is a VPNv4 route, then the address family attribute of the first routing information is changed from VPNv4 to IPv4; if the first routing information is a VPNv6 route, then the address family attribute of the first routing information is changed from VPNv6 to IPv6.

[0299] In practical applications, VPNv4 / 6 routing refers to the routing information used in MPLS L3VPN. This routing information includes the destination network prefix, next-hop address, and MPLS label information. It is primarily used for route propagation between different VRF instances, ensuring that traffic from different tenants or services is transmitted in isolation within the public network.

[0300] In non-MPLS networks, IPv4 / 6 routing is the most common form of routing, specifically referring to the use of standard IPv4 or IPv6 routing information. This routing information does not contain MPLS labels, but only the destination network prefix and next-hop address, primarily used to guide packet forwarding in non-MPLS networks.

[0301] In this application, the controller establishes peering relationships with ER and DR devices via MP-IBGP, injecting VPNv4 / 6 routing information with MPLS labels. The routing information injected into the DR is used to establish an MPLS L3VPN tunnel between the data center and the POP point, ensuring efficient and secure transmission of user traffic within the MPLS network. The routing information injected into the ER is primarily used to guide packet forwarding in non-MPLS networks and does not involve cross-VRF traffic isolation. Therefore, it needs to be converted from VPNv4 / 6 to IPv4 / 6. The converted IPv4 / 6 routing information is used by the ER device to guide packet forwarding in non-MPLS networks, ensuring that specific traffic is sent to the Internet through the designated ISP exit.

[0302] In this way, the controller does not need to establish a peering relationship with the ER device through iBGP and inject local IPv4 / 6 routing information. Instead, when the protocol conversion routing policy is satisfied, the VPNv4 / 6 routing information is converted to IPv4 / 6 routing information, thereby reducing the number of peers and the complexity of routing protocols for the controller.

[0303] In the above implementation, by converting the first routing information from VPN type to the corresponding IP type, precise control of specific traffic can be achieved, network resource utilization can be optimized, security and isolation can be enhanced, and network performance and flexibility can be improved.

[0304] However, in some cases, the routing information may not match the preset protocol conversion routing policy, and therefore no protocol conversion will be performed.

[0305] Optionally, if the first routing information does not match the protocol conversion routing policy, then during route cross-injection, the first routing information is injected from the local private network VRF into the public network VRF based on the MP-IBGP protocol.

[0306] Specifically, after receiving the first routing information from the controller (which is a VPNv4 / v6 route), the border router checks whether the route matches the preset protocol translation routing policy. The specific checking method is as described above and will not be repeated here. If the route does not match the protocol translation routing policy, the border router will perform route cross-import according to the default MP-IBGP protocol processing procedure, that is, keep the address family attribute of the route unchanged.

[0307] Based on the above implementation method, the consistency of routing information between the private network VRF and the public network VRF can be ensured. Furthermore, processing via the MP-IBGP protocol leverages existing BGP route management and distribution mechanisms, simplifying network management, avoiding unnecessary address family attribute translations, reducing processing overhead, and improving routing efficiency. Moreover, based on this logic, it can be ensured that only routes meeting specific conditions undergo address family attribute translation, improving network security and reliability.

[0308] It should be noted that the above describes in detail the logic of route distribution in the embodiments of this application. The following describes in detail the application of this routing information in conjunction with the scenario:

[0309] In modern network architectures, businesses or organizations typically connect to the Internet through multiple ISPs to achieve redundancy and load balancing.

[0310] Optionally, each border router in the internal network of this application connects to at least two ISPs. In scenarios where an object requests access to a specific network segment, and the traffic exit specified for that specific network segment is the target ISP among the at least two ISPs, the routing prefix in the first routing information is the specific network segment, and the next hop points to the target ISP. For specific implementation details, please refer to the relevant description on the controller side. By issuing this first routing information, it can be ensured that the border router forwards traffic requests for the specific network segment to the target ISP. The specific implementation is as follows:

[0311] Receive traffic requests for a specific network segment via the local public network VRF; forward the traffic requests to the target ISP based on the first routing information.

[0312] Specifically, after a user accesses a specific network segment and enters the public VRF of the target border router through an MPLS tunnel, when querying the IPv4 / 6 routing table, it matches the scheduling route (i.e., the first routing information) previously issued by the controller and forwards this traffic from the target ISP, thus realizing the ability to schedule user traffic on demand. The MPLS tunnel is established based on the MPLS label.

[0313] In the above implementation, by setting the routing prefix in the first routing information to a specific network segment and pointing the next hop to the target ISP, traffic requests from the specific network segment can be forwarded through the designated ISP exit, ensuring that this traffic follows the optimal path and improving access speed and reliability. Furthermore, by precisely controlling the traffic exit point, all traffic can be prevented from passing through the default exit point, thereby balancing network load and improving overall network performance.

[0314] The following section explains the traffic forwarding process within this internal network under the scenarios listed above:

[0315] In practical applications, an object can use a terminal device to initiate a traffic request for a specific network segment to the data center in the internal network. After receiving the traffic request, the DR in the data center will query the local routing table and establish an MPLS tunnel between the data center and the POP where the target border router is located, based on the previously injected second routing information (VPN type). The traffic request will be forwarded to the target border router through the MPLS tunnel. During this process, the traffic request will be forwarded to the public network VRF in the target border router.

[0316] Specifically, in this process, the DR will add MPLS labels to the data packets related to the traffic request based on the MPLS labels in the second routing information (each MPLS label is uniquely bound to an ISP exit, specifically the MPLS label corresponding to the target ISP). Then, the data packets with MPLS labels will be encapsulated in the MPLS tunnel and forwarded to the target border router through the MPLS network.

[0317] The target border router receives the data packet related to the traffic request in the public VRF associated with the target ISP, removes the MPLS label, restores the original IP data packet, and then queries the local routing table in the public VRF. Based on the first routing information (IP type) previously injected by cross-linking, it forwards the traffic request to the target ISP.

[0318] The following examples illustrate the different types of internal networking described above:

[0319] like Figure 9 The diagram shown illustrates a traffic request forwarding path in an internal network configuration according to an embodiment of this application. Figure 9 The internal network structure shown is the same as the one described above. Figure 3 The internal network topology shown is the same, so it will not be repeated here. The difference lies in... Figure 9 China has added a new forwarding path for traffic requests, such as... Figure 9 The bold curve with an arrow in the middle is shown.

[0320] The specific forwarding logic based on this forwarding path is as follows:

[0321] An object can use a terminal device to initiate a traffic request for a specific network segment 1.0.0.0 / 24 to the data center in this internal network. After receiving the traffic request, the DR in the data center will query the local routing table and establish an MPLS tunnel between the data center and POP2 based on the previously injected second routing information (VPNv4 route: route prefix is ​​1.0.0.0 / 24, next hop points to ER2, MPLS label is L3). Specifically, it refers to an MPLS L3VPN tunnel and forwards the traffic request to VRF1 of ER2 in POP2 through the MPLS tunnel.

[0322] Then, query the local routing table in VRF1 of ER2, and based on the first route information injected earlier (IPv4 route: route prefix is ​​1.0.0.0 / 24, next hop points to ISP3), forward the traffic request to ISP3.

[0323] For example Figure 10 As shown, this is a schematic diagram of the forwarding path of traffic requests in another type of internal network configuration according to an embodiment of this application. Figure 10 The internal network structure shown is the same as the one described above. Figure 5 The internal network topologies shown are the same, and will not be repeated here. The difference lies in: Figure 10 China has added a new forwarding path for traffic requests, such as... Figure 10 The bold curve with an arrow in the middle is shown.

[0324] The specific forwarding logic based on this forwarding path is as follows:

[0325] An object can use a terminal device to initiate a traffic request for a specific network segment 10.0.0.0 / 24 to the data center in this internal network. After receiving the traffic request, the DR in the data center will query the local routing table and establish an MPLS tunnel between the data center and POP3 based on the previously injected second routing information (VPNv6 route: route prefix is ​​192.168.1.0 / 24, next hop points to ER1, MPLS label is L12). The traffic request will then be forwarded to VRF4 of ER3 in POP3 through the MPLS tunnel.

[0326] Then, query the local routing table in VRF4 of ER3, and based on the first route information injected earlier (IPv6 route: route prefix is ​​10.0.0.0 / 24, next hop points to ISP5), forward the traffic request to ISP5.

[0327] For example Figure 11 As shown, this is a schematic diagram of the forwarding path of traffic requests in another internal network configuration according to an embodiment of this application. Figure 11 The internal network structure shown is the same as the one described above. Figure 4 The internal network topologies shown are the same, and will not be repeated here. The difference lies in: Figure 11 China has added a new forwarding path for traffic requests, such as... Figure 11 The bold curve with an arrow in the middle is shown.

[0328] The specific forwarding logic based on this forwarding path is as follows: The target can use a terminal device to initiate a traffic request for a specific network segment 192.168.1.0 / 24 to the data center in this internal network. After receiving the traffic request, the DR in the data center will query the local routing table and establish an MPLS tunnel between the data center and POP1 based on the previously injected second routing information (VPNv6 route: route prefix is ​​192.168.1.0 / 24, next hop points to ER1, MPLS label is L6). The traffic request will then be forwarded to VRF1 of ER1 in POP1 through the MPLS tunnel.

[0329] Then, the local routing table in VRF1 of ER1 is queried, and based on the first route information injected earlier (IPv6 route: route prefix is ​​192.168.1.0 / 24, next hop points to ISP2), the traffic request is forwarded to ISP2.

[0330] It should be noted that in the forwarding paths listed above, the public VRF on the DR and ER can be the same or different. For example... Figure 9 In the process, traffic requests are forwarded from VRF1 on DR to VRF1 on ER2, which is the same; for example, in Figure 11In the middle, the traffic request is forwarded from VRF1 on DR to VRF1 on ER1, which is the same; while Figure 10 In this case, the traffic request is forwarded from VRF5 on DR to VRF4 on ER3, which is different.

[0331] In addition, it should be noted that the above Figure 9 , Figure 10 and Figure 11 The traffic forwarding processes listed are just simple examples. The routing method proposed in this application is also applicable to other internal networks, and will not be elaborated on here.

[0332] See Figure 12 The diagram shown illustrates the interaction timing between the controller and the border router and data center router according to this application. The specific implementation process of this method is as follows:

[0333] S1201: The controller sends a second VPNv4 route to the data center router via the MP-IBGP protocol. The route prefix in the second VPNv4 route is a specific network segment, the next hop points to the target border router, and the MPLS label is the label corresponding to the target ISP, with a priority higher than the specified priority.

[0334] S1202: Data center router stores a second VPNv4 route;

[0335] S1203: The controller sends the first VPNv4 route to the target border router via the MP-IBGP protocol. The route prefix is ​​a specific network segment, the next hop points to the target ISP, and the priority is the highest.

[0336] In S1203, the highest priority specifically means the highest within the specified routing information range, as detailed in the above embodiment, and will not be repeated here.

[0337] S1204: When performing route cross-injection, the target border router determines the first VPNv4 route to match the protocol conversion routing policy, converts the address family attribute of the first VPNv4 route to IPv4 type, and modifies the next-hop VRF of the first VPNv4 route from the private network VRF to the public network VRF in the border router, so as to inject the first VPNv4 route into the local public network VRF.

[0338] S1205: The data center router will handle traffic requests for this specific network segment;

[0339] S1206: The data center router establishes an MPLS tunnel based on the second VPNv4 route and forwards the traffic request to the target border router through the MPLS tunnel;

[0340] In S1206, the data center router specifically establishes an MPLS tunnel based on the MPLS label in the second VPNv4 route, as detailed in the above embodiment, and will not be repeated here.

[0341] S1207: The target border router forwards the traffic request to the target ISP via its local public VRF.

[0342] The execution order of S1201 and S1203 is not specifically limited in this article. They can be executed simultaneously, or S1201 can be executed first and S1403 can be executed later, or S1203 can be executed first and S1401 can be executed later, etc. This article does not make specific limitations.

[0343] In summary, this application enables all internal network devices to establish an MP-IBGP peering network using a single IPv4 address, requiring only internal network interconnection. VPNv4 / 6 routes with filtered route identifiers are injected through the controller. The routing processing capability is then extended on the scheduling router to perform policy matching on locally cross-linked imported routes and convert route types matching the filtered route identifiers to IPv4 / 6 routes. This achieves the ability to inject multiple routes using a single MP-IBGP protocol. This solution has low requirements for service network topology; end-to-end flexible service scheduling can be achieved by adding controller nodes without changing the existing network topology, and the protocol processing complexity of the controller is also reduced.

[0344] Based on the same inventive concept, embodiments of this application also provide a routing distribution device. For example... Figure 13 The diagram shows the structure of the routing device 1300, which is used as a controller in a network. The network also includes: at least one Point of Presence (POP); each POP deploys at least one border router, and each border router connects to at least one ISP, which may include:

[0345] Configuration unit 1301 is used to establish an MP-IBGP peer with each of the border routers using a private network address; each of the border routers is configured with a private network VRF and at least one public network VRF; the private network address and the private network VRF are bound together.

[0346] The scheduling unit 1302 is used to send first routing information to the border router via the MP-IBGP protocol, so that when the border router performs route cross-injection, it analyzes whether the first routing information matches a preset protocol conversion routing policy. If it matches, the address family attribute of the first routing information is changed from VPN type to IP type. The route cross-injection refers to injecting the first routing information from a private network VRF into a public network VRF in the border router.

[0347] Optionally, the first routing information carries a target route identifier, so that when the border router performs route cross-injection, it analyzes whether the first routing information matches the protocol conversion routing policy based on the target route identifier; wherein:

[0348] If the target route identifier is a route identifier of a specified type, then it is determined that the first route information matches the protocol conversion route policy;

[0349] If the target route identifier is not a route identifier of the specified type, then it is determined that the first route information does not match the protocol conversion route policy.

[0350] Optionally, each border router in the network connects to at least two ISPs;

[0351] In a scenario where an object requests access to a specific network segment, and the traffic exit specified for that specific network segment is the target ISP among the at least two ISPs, the scheduling unit 1302 is specifically used for:

[0352] The first routing information is sent to the target border router among the border routers via the MP-IBGP protocol;

[0353] Wherein, the routing prefix in the first routing information is the specific network segment, the next hop points to the target ISP, and the target border router is the border router among the border routers that connects to the target ISP, so that when the first routing information matches the protocol conversion routing policy, the target border router will forward the traffic request for the specific network segment to the target ISP through the local public network VRF.

[0354] Optionally, the network further includes a data center, in which at least one data center router is deployed; the scheduling unit 1302 is further configured to:

[0355] Using the private network address, an MP-IBGP peer is established with each of the data center routers; each of the data center routers is configured with the private network VRF and at least one public network VRF.

[0356] Send the second routing information to the data center router via the MP-IBGP protocol;

[0357] In this context, the routing prefix in the second routing information is the specific network segment, the next hop points to the target border router, and the Multiprotocol Label Switching (MPLS) label is the label corresponding to the target ISP. This enables the data center router to forward traffic requests for the specific network segment to the public network VRF in the target border router via an MPLS tunnel. The MPLS tunnel is established based on the MPLS label.

[0358] Optionally, the first routing information has the highest priority within a specified routing information range, and the specified routing information range includes: each routing information from the target border router to the specific network segment;

[0359] The second routing information has a higher priority than a specified priority, which refers to the priority of the routing information learned by the target ISP and transmitted to the data center router through the routing reflector.

[0360] Based on the same inventive concept, embodiments of this application also provide a routing distribution device. For example... Figure 14 The diagram shows the structure of a route distribution device 1400, applied to border routers in a network. The network includes: at least one POP and a controller; each POP deploys at least one border router, and each border router connects to at least one ISP; the controller establishes an MP-IBGP peer with each border router using a private network address; each border router is configured with a private network VRF and at least one public network VRF, and the private network address and the private network VRF are bound together; it may include:

[0361] The receiving unit 1401 is used to receive the first routing information sent by the controller through the MP-IBGP protocol;

[0362] The routing cross-connect unit 1402 is used to analyze whether the first routing information matches a preset protocol conversion routing strategy when performing routing cross-connect injection.

[0363] If a match is found, the address family attribute of the first routing information is changed from VPN type to IP type, and the next-hop VRF of the first routing information is changed from the private network VRF to the public network VRF in the border router, so as to inject the first routing information from the local private network VRF into the public network VRF.

[0364] Optionally, the first routing information carries a target route identifier, and the routing cross-connect unit 1402 is specifically used for:

[0365] Based on the target route identifier, analyze whether the first route information matches the protocol conversion route policy, wherein:

[0366] If the target route identifier is a route identifier of a specified type, then it is determined that the first route information matches the protocol conversion route policy;

[0367] If the target route identifier is not a route identifier of the specified type, then it is determined that the first route information does not match the protocol conversion route policy.

[0368] Optionally, each border router in the network is connected to at least two ISPs; in the scenario where the object requests access to a specific network segment and the traffic exit specified by the specific network segment is the target ISP among the at least two ISPs, the routing prefix in the first routing information is the specific network segment, and the next hop points to the target ISP;

[0369] The device also includes:

[0370] Forwarding unit 1403 is used to receive traffic requests for the specific network segment via the local public network VRF;

[0371] Based on the first routing information, the traffic request is forwarded to the target ISP.

[0372] Optionally, the routing cross-connect unit 1402 is specifically used for:

[0373] If the first routing information is a VPNv4 route, then the address family attribute of the first routing information is changed from VPNv4 to IPv4;

[0374] If the first routing information is a VPNv6 route, then the address family attribute of the first routing information is changed from VPNv6 to IPv6.

[0375] Optionally, the specified type of route identifier includes at least one of the following: a specified community attribute, a specified extended community attribute.

[0376] Optionally, the routing cross-connect unit 1402 is further configured to:

[0377] If no match is found, the first routing information is injected from the local private network VRF into the public network VRF based on the MP-IBGP protocol during route cross-injection.

[0378] This application only requires creating one MP-IBGP peer between the controller and the corresponding router. Specifically, the controller only needs to use its private IP address to establish an MP-IBGP peer with the border router in the POP, and no longer needs to use its public IP address to establish an IBGP peer with these routers. Since the private IP address is bound to the private VRF, and the private VRF is used for communication between internal devices, communication between the controller and internal devices can be ensured. Furthermore, by establishing an MP-IBGP peer, the transmission of VPNv4 / 6 routes is supported.

[0379] Based on the above, in order to realize the routing scheduling capability of multiple protocols, this application adds a protocol conversion routing policy based on the MP-IBGP peer on the VPN address family corresponding to the router. Specifically, the controller can send VPN routes (such as the first routing information) to the router through the MP-IBGP protocol. If the route received by the router matches the protocol conversion routing policy, the router performs route cross-injection. When imported into the corresponding VRF, the address family attribute of the route can be converted from the VPN address family to the IP address family. In this way, it is not necessary to establish an IBGP peer between the controller and the corresponding router to realize the transmission of IPv4 / v6 routes.

[0380] In summary, by creating only one MP-IBGP peer between the controller and the corresponding router, multiple routes such as VPNv4 / 6 and IPv4 / v6 can be transmitted simultaneously, enabling rapid routing scheduling in various scenarios and greatly simplifying internal network topology and controller routing scheduling logic.

[0381] For ease of description, the above sections are divided into modules (or units) according to their functions and described separately. Of course, in implementing this application, the functions of each module (or unit) can be implemented in one or more software or hardware components.

[0382] In this application embodiment, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0383] Having described the routing method and apparatus according to exemplary embodiments of this application, we will now describe an electronic device according to another exemplary embodiment of this application.

[0384] Those skilled in the art will understand that various aspects of this application can be implemented as a system, method, or program product. Therefore, various aspects of this application can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or a combination of hardware and software implementations, collectively referred to herein as a "circuit," "module," or "system."

[0385] Based on the same inventive concept as the above method embodiments, this application also provides an electronic device, the structure of which can be as follows: Figure 15As shown, it includes a memory 1501, a communication module 1503, and one or more processors 1502.

[0386] The memory 1501 is used to store computer programs executed by the processor 1502. The memory 1501 may mainly include a program storage area and a data storage area. The program storage area may store the operating system and programs required to run instant messaging functions, etc.; the data storage area may store various instant messaging information and operation instruction sets, etc.

[0387] Memory 1501 may be volatile memory, such as random-access memory (RAM); memory 1501 may also be non-volatile memory, such as read-only memory, flash memory, hard disk drive (HDD), or solid-state drive (SSD); or memory 1501 may be any other medium capable of carrying or storing a desired computer program having the form of instructions or data structures and accessible by a computer, but is not limited thereto. Memory 1501 may be a combination of the above-described memories.

[0388] Processor 1502 may include one or more central processing units (CPUs) or digital processing units, etc. Processor 1502 is used to implement the above-described routing method when calling computer programs stored in memory 1501.

[0389] The communication module 1503 is used to communicate with terminal devices and other servers.

[0390] This application embodiment does not limit the specific connection medium between the memory 1501, communication module 1503, and processor 1502. This application embodiment... Figure 15 The memory 1501 and the processor 1502 are connected via a bus 1504, and the bus 1504 is in Figure 15 The diagram uses thick lines to describe the connections between other components; these are for illustrative purposes only and should not be considered limiting. The 1504 bus can be divided into address bus, data bus, control bus, etc. For ease of description, Figure 15 It is described using only a thick line, but does not indicate that there is only one bus or one type of bus.

[0391] The memory 1501 stores a computer storage medium, which stores computer-executable instructions for implementing the routing method of this application embodiment. The processor 1502 is used to execute the above-described routing method, such as... Figure 6 or Figure 8 As shown.

[0392] In some possible implementations, various aspects of the routing method provided in this application can also be implemented as a program product, including a computer program. When the program product is run on an electronic device, the computer program causes the electronic device to perform the steps of the routing method according to the various exemplary embodiments of this application described above. For example, the electronic device can perform actions such as... Figure 6 or Figure 8 The steps are shown in the figure.

[0393] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of readable storage media include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0394] The program product of the embodiments of this application may employ a portable compact disc read-only memory (CD-ROM) and include a computer program, and may run on an electronic device. However, the program product of this application is not limited thereto. In this document, the readable storage medium may be any tangible medium that contains or stores a program that may be used by or in conjunction with a command execution system, apparatus, or device.

[0395] A readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying a readable computer program. This propagated data signal may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting a program for use by or in conjunction with a command execution system, apparatus, or device.

[0396] Computer programs contained on readable media may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0397] Computer programs for performing the operations of this application can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The computer program can execute entirely on the user's electronic device, partially on the user's electronic device, as a standalone software package, partially on the user's electronic device and partially on a remote electronic device, or entirely on a remote electronic device or server. In cases involving remote electronic devices, the remote electronic device can be connected to the user's electronic device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external electronic device (e.g., via the Internet using an Internet service provider).

[0398] It should be noted that although several units or sub-units of the device have been mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to embodiments of this application, the features and functions of two or more units described above can be embodied in one unit. Conversely, the features and functions of one unit described above can be further divided and embodied by multiple units.

[0399] Furthermore, although the operations of the method of this application are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0400] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing a computer-usable computer program.

[0401] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, produce a machine for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0402] These computer program commands may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the commands stored in the computer-readable storage medium produce an article of manufacture including command means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0403] These computer program commands can also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing the commands executed on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0404] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0405] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A method for route distribution, characterized in that, A controller applied in a network, the network further comprising: at least one Point of Presence (POP); each POP deploying at least one border router, each of the border routers being connected to at least one Internet Service Provider (ISP), the method comprising: Using a private network address, a Multiprotocol Internal Border Gateway Protocol (MP-IBGP) peer is established with each of the border routers; each of the border routers is configured with a private network Virtual Router Forwarding (VRF) and at least one public network VRF; the private network address and the private network VRF are bound together. The first routing information is sent to the border router via the MP-IBGP protocol, so that when the border router performs route cross-injection, it analyzes whether the first routing information matches the preset protocol conversion routing policy. If it matches, the address family attribute of the first routing information is changed from Virtual Private Network (VPN) type to Internet Protocol (IP) type. The route cross-injection refers to injecting the first routing information from the private network VRF into the public network VRF in the border router.

2. The method as described in claim 1, characterized in that, The first routing information carries a target route identifier, so that when the border router performs route cross-injection, it can analyze whether the first routing information matches the protocol conversion routing policy based on the target route identifier; wherein: If the target route identifier is a route identifier of a specified type, then it is determined that the first route information matches the protocol conversion route policy; If the target route identifier is not a route identifier of the specified type, then it is determined that the first route information does not match the protocol conversion route policy.

3. The method as described in claim 1, characterized in that, Each border router in the network is connected to at least two ISPs; In a scenario where an object requests access to a specific network segment, and the traffic exit specified for that specific network segment is the target ISP among the at least two ISPs, the step of sending the first routing information to the border router via the MP-IBGP protocol includes: The first routing information is sent to the target border router among the border routers via the MP-IBGP protocol; Wherein, the routing prefix in the first routing information is the specific network segment, the next hop points to the target ISP, and the target border router is the border router among the border routers that connects to the target ISP, so that when the first routing information matches the protocol conversion routing policy, the target border router will forward the traffic request for the specific network segment to the target ISP through the local public network VRF.

4. The method as described in claim 3, characterized in that, The network also includes a data center, in which at least one data center router is deployed; the method further includes: Using the private network address, an MP-IBGP peer is established with each of the data center routers; each of the data center routers is configured with the private network VRF and at least one public network VRF. Send the second routing information to the data center router via the MP-IBGP protocol; In this context, the routing prefix in the second routing information is the specific network segment, the next hop points to the target border router, and the Multiprotocol Label Switching (MPLS) label is the label corresponding to the target ISP. This enables the data center router to forward traffic requests for the specific network segment to the public network VRF in the target border router via an MPLS tunnel. The MPLS tunnel is established based on the MPLS label.

5. The method as described in claim 4, characterized in that, The first routing information has the highest priority within the specified routing information range, which includes: each routing information from the target border router to the specific network segment; The second routing information has a higher priority than a specified priority, which refers to the priority of the routing information learned by the target ISP and transmitted to the data center router through the routing reflector.

6. A method for route distribution, characterized in that, A border router is applied in a network, the network comprising: at least one POP and a controller; each POP deploys at least one border router, and each border router is connected to at least one ISP; the controller establishes an MP-IBGP peer with each border router using a private network address; each border router is configured with a private network VRF and at least one public network VRF, and the private network address and the private network VRF are bound; the method includes: Receive the first routing information sent by the controller via the MP-IBGP protocol; When performing route cross-injection, analyze whether the first route information matches the preset protocol conversion route strategy; If a match is found, the address family attribute of the first routing information is changed from VPN type to IP type, and the next-hop VRF of the first routing information is changed from the private network VRF to the public network VRF in the border router, so as to inject the first routing information from the local private network VRF into the public network VRF.

7. The method as described in claim 6, characterized in that, The first routing information carries a target route identifier. The step of analyzing whether the first routing information matches a preset protocol conversion routing policy includes: Based on the target route identifier, analyze whether the first route information matches the protocol conversion route policy, wherein: If the target route identifier is a route identifier of a specified type, then it is determined that the first route information matches the protocol conversion route policy; If the target route identifier is not a route identifier of the specified type, then it is determined that the first route information does not match the protocol conversion route policy.

8. The method as described in claim 6, characterized in that, Each border router in the network is connected to at least two ISPs; in the scenario where the target network segment is required to access a specific network segment and the traffic exit specified by the specific network segment is the target ISP among the at least two ISPs, the routing prefix in the first routing information is the specific network segment and the next hop points to the target ISP; Furthermore, the method further includes: Receive traffic requests for the specific network segment via the local public network VRF; Based on the first routing information, the traffic request is forwarded to the target ISP.

9. The method as described in claim 6, characterized in that, The step of converting the address family attribute of the first routing information from VPN type to IP type includes: If the first routing information is a VPNv4 route, then the address family attribute of the first routing information is changed from VPNv4 to IPv4; If the first routing information is a VPNv6 route, then the address family attribute of the first routing information is changed from VPNv6 to IPv6.

10. The method as described in claim 7, characterized in that, The specified type of route identifier includes at least one of the following: specified community attribute, specified extended community attribute.

11. The method according to any one of claims 6 to 10, characterized in that, The method further includes: If no match is found, the first routing information is injected from the local private network VRF into the public network VRF based on the MP-IBGP protocol during route cross-injection.

12. A routing distribution device, characterized in that, A controller applied in a network, the network further comprising: at least one Point of Presence (POP); each POP deploying at least one border router, each of the border routers connecting to at least one ISP, the device comprising: A configuration unit is used to establish an MP-IBGP peer with each of the border routers using a private network address; each of the border routers is configured with a private network VRF and at least one public network VRF; the private network address and the private network VRF are bound together. The scheduling unit is used to send first routing information to the border router via the MP-IBGP protocol, so that when the border router performs route cross-injection, it analyzes whether the first routing information matches a preset protocol conversion routing policy. If it matches, the address family attribute of the first routing information is changed from VPN type to IP type. The route cross-injection refers to injecting the first routing information from a private network VRF into a public network VRF in the border router.

13. A routing distribution device, characterized in that, A border router is used in a network, the network comprising: at least one POP and a controller; each POP deploys at least one border router, and each border router is connected to at least one ISP; the controller establishes an MP-IBGP peer with each border router using a private network address; each border router is configured with a private network VRF and at least one public network VRF, and the private network address and the private network VRF are bound together; the device includes: The receiving unit is used to receive the first routing information sent by the controller through the MP-IBGP protocol; The routing cross-connection unit is used to analyze whether the first routing information matches the preset protocol conversion routing strategy when performing routing cross-connection injection. If a match is found, the address family attribute of the first routing information is changed from VPN type to IP type, and the next-hop VRF of the first routing information is changed from the private network VRF to the public network VRF in the border router, so as to inject the first routing information from the local private network VRF into the public network VRF.

14. An electronic device, characterized in that, It includes a processor and a memory, wherein the memory stores a computer program that, when executed by the processor, causes the processor to perform the steps of any of the methods described in claims 1 to 11.

15. A computer-readable storage medium, characterized in that, It includes a computer program that, when run on an electronic device, causes the electronic device to perform the steps of any of the methods described in claims 1 to 11.

16. A computer program product, characterized in that, The method includes a computer program stored in a computer-readable storage medium; when a processor of an electronic device reads the computer program from the computer-readable storage medium, the processor executes the computer program, causing the electronic device to perform the steps of any one of claims 1 to 11.