Direct link cross-VRF communication method, device, equipment and medium

Abstract

The invention relates to a link cross-VRF communication method and device, equipment and a medium, and relates to the technical field of communication. The method comprises the following steps: when a first message of a first virtual private network (VPN) is received, extracting a destination IP address in the first message; wherein the first message comes from a first host under a first virtual routing and forwarding VRF identifier, and the destination IP address does not belong to a host address under the first VRF identifier in the first VPN; determining a second VRF identifier corresponding to the destination IP address based on the destination IP address and a mapping relation table; and determining a forwarding path of the first message based on the destination IP address and the second VRF identifier. By adopting the method, the access of a large number of direct connection equipment can be realized.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computers, and in particular to a direct link cross-VRF communication method, device, equipment and medium. BACKGROUND

[0002] A VPN (Virtual Private Network) constructs a virtual routing space isolated from each other by allocating independent VRF (Virtual Routing and Forwarding) forwarding instances for different tenants or departments, and ensures that network traffic in each region does not interfere with each other. However, in actual scenarios, there is often a need for intercommunication between private networks and public networks, and between different private networks, such as cloud tenants accessing public network resources and different departments of an enterprise sharing data.

[0003] In implementing cross-VRF communication, existing technologies can take corresponding methods for different types of routes. For remote routes (usually represented as a network segment containing multiple addresses), the conventional approach is to copy the routes of the source VPN (such as VPN1) to the target VPN (such as VPN2), so that a route entry pointing to the source VPN is formed in the target VPN, and the next hop still points to the source VPN, thereby achieving communication from the target VPN to the source VPN. For direct routes (i.e. 32-bit full-mask host addresses), the current processing logic is similar to that of remote routes, and cross-VRF communication is achieved by copying them to the target VPN.

[0004] However, the "copying and introducing" method currently used for direct routes occupies a large number of hardware host table item resources of the switch chip, which ultimately leads to a significant reduction in the number of hosts that the switch can access. SUMMARY

[0005] The present application provides a direct link cross-VRF communication method, device, equipment and medium, which can realize the access of a large number of direct connection devices.

[0006] To achieve the above purpose, the present application adopts the following technical solutions: In a first aspect, the present application provides a direct link cross-VRF communication method, comprising: In the case of receiving a first packet of a first virtual private network (VPN), the destination IP address in the first packet is extracted; wherein the first packet is from a first host under a first virtual routing and forwarding (VRF) identifier, and the destination IP address does not belong to the host address under the first VRF identifier in the first VPN; Based on the destination IP address and the mapping relationship table, the second VRF identifier corresponding to the destination IP address is determined; Based on the destination IP address and the second VRF identifier, the forwarding path of the first packet is determined.

[0007] In one embodiment, the mapping relationship table includes a mapping relationship between the direct link segment route and the VRF identifier.

[0008] In one embodiment, based on the destination IP address and the mapping relationship table, the second VRF identifier corresponding to the destination IP address is determined, including: determining whether the destination IP address belongs to the address range of any direct link segment route in the mapping relationship table; if yes, determining the VRF identifier corresponding to the direct link segment route as the second VRF identifier corresponding to the destination IP address.

[0009] In one embodiment, based on the destination IP address and the second VRF identifier, the forwarding path of the first packet is determined, including: updating the VRF field in the first packet to the second VRF identifier; performing route entry matching based on the destination IP address and the second VRF identifier; if the matching is successful, determining the destination host and the forwarding path corresponding to the first packet based on the matching successful route entry.

[0010] In one embodiment, based on the destination IP address and the mapping relationship table, the second VRF identifier corresponding to the destination IP address is determined, including: determining whether the destination IP address belongs to the address range of any direct link segment route in the mapping relationship table; if no, not updating the VRF field in the first packet, and determining the VRF identifier to which the first packet belongs as the second VRF identifier.

[0011] In one embodiment, including: establishing a mapping relationship between the direct link segment route and the corresponding VRF identifier through the border gateway protocol (BGP) to construct the mapping relationship table.

[0012] In one embodiment, based on the destination IP address and the second VRF identifier, the route entry matching is performed, including: if the matching is not successful, discarding the first packet.

[0013] In a second aspect, the present application provides a direct link cross-VRF communication device, including: an extraction module configured to extract a destination IP address in a first packet in a case that the first packet of a first virtual private network (VPN) is received; wherein the first packet is from a first host under a first virtual routing and forwarding (VRF) identifier, and the destination IP address does not belong to the host address under the first VRF identifier in the first VPN; an identifier determination module configured to determine a second VRF identifier corresponding to the destination IP address based on the destination IP address and a mapping relationship table. A path determining module is configured to determine the forwarding path of the first packet based on the destination IP address and the second VRF identifier.

[0014] In a third aspect, the present application provides a computing device, comprising a memory and a processor; The memory stores one or more computer programs, which include instructions; when the instructions are executed by the processor, the computing device performs the method of any one of the first aspect.

[0015] In a fourth aspect, the present application provides a computer readable storage medium for storing a computer program, which is used to perform the method of any one of the first aspect.

[0016] In a fifth aspect, the present application provides a computer program product, which comprises one or more computer instructions; when the computer instructions are executed by a computer, the computer performs the method of any one of the first aspect.

[0017] From the above technical solutions, the present application has at least the following beneficial effects: In the present application, by extracting the destination IP address in the first packet when the first packet of the first virtual private network (VPN) is received, the direction for subsequent determination of the destination VRF is provided; further, the second VRF identifier corresponding to the destination IP address can be determined based on the destination IP address and the mapping relationship table, thereby realizing accurate determination of the destination VRF; finally, the forwarding path of the first packet can be determined based on the destination IP address and the second VRF identifier, thereby realizing accurate communication of the packet across VRFs. The present application provides a way for fast realization of cross-VRF communication by introducing a mapping relationship table comprising the mapping relationship between "IP address" and "VRF", and finally realizes access of a large number of directly connected devices by only maintaining the mapping relationship table.

[0018] It should be understood that the description of technical features, technical solutions, advantages or similar language in this application does not imply that all features and advantages can be achieved in any single embodiment. On the contrary, it can be understood that the description of features or advantages means that the specific technical features, technical solutions or advantages are included in at least one embodiment. Therefore, the description of technical features, technical solutions or advantages in this specification does not necessarily refer to the same embodiment. Further, the technical features, technical solutions and advantages described in this embodiment can also be combined in any appropriate manner. Those skilled in the art will understand that the embodiments can be implemented without one or more specific technical features, technical solutions or advantages of the specific embodiments. In other embodiments, additional technical features and advantages can be identified in specific embodiments that do not embody all embodiments. BRIEF DESCRIPTION OF DRAWINGS

[0019] Figure 1 An application environment diagram of a direct link cross VRF communication method provided in an embodiment of the application; Figure 2 A flowchart of a direct link cross VRF communication method provided in an embodiment of the application; Figure 3 A structural block diagram of a direct link cross VRF communication device provided in an embodiment of the application; Figure 4 An internal structure diagram of a computer device provided in an embodiment of the application. DETAILED DESCRIPTION

[0020] The terms "first", "second", and "third" and the like in the specification and the drawings of this application are used to distinguish different objects, and are not used to limit a specific order.

[0021] In the embodiments of the present application, the words "exemplary" or "for example" are used to mean serving as an example, instance, or illustration, and not necessarily as preferred or advantageous over other embodiments or implementations. In fact, the use of "exemplary" or "for example" is intended to present concepts in a concrete manner.

[0022] For the sake of clear and concise description of the following embodiments, first give a brief introduction of the related art: VPN (Virtual Private Network, virtual private network) can build mutually isolated virtual routing space by allocating independent VRF (Virtual Routing and Forwarding, virtual routing and forwarding) forwarding instances for different tenants, departments or business domains. Each VRF has a dedicated routing table, ARP table and forwarding rule, which can realize logical isolation of network traffic in each region, fundamentally avoid traffic interference between different tenants or departments, and ensure the security and privacy of data transmission. However, in actual network deployment, the needs of "isolation" and "intercommunication" often coexist: tenants of cloud data centers need to access public network resources through private networks, such as downloading system patches and calling third-party APIs (Application Programming, application programming interface), and different departments within an enterprise (such as the R&D department and the test department) need to share core data (such as test reports and project documents) across domains. The need for intercommunication between private networks and public networks, as well as between different private networks, has become the norm, which requires building an efficient and reliable cross-VRF communication mechanism on the basis of VRF isolation.

[0023] In current mainstream cross-VRF communication technologies, differentiated processing schemes have been formed for different types of routes. For example, remote route (network segment level route) processing: remote routes usually exist in the form of a network segment containing multiple host addresses (such as 192.168.1.0 / 24). When implementing cross-VRF communication, the conventional approach is to "copy and introduce" the remote route table entries of the source VPN (such as VPN1) into the routing table of the target VPN (such as VPN2). After introduction, the target VPN generates a route entry pointing to the source VPN, and the next hop of this entry is still anchored to the gateway device of the source VPN. When a host in the target VPN needs to access the network segment of the source VPN, it can locate the forwarding path through this copied route entry, and ultimately achieve one-way or two-way communication from the target VPN to the source VPN. Direct connection route (host level route) processing: direct connection route refers to a 32-bit full mask host route (such as 192.168.1.10 / 32), which usually corresponds to terminal devices directly connected to the switch, such as PCs (Personal Computer, personal computer), IoT (Internet of Things Sensor, Internet of Things Sensor) sensors. Currently, the industry still follows the "copy and introduction" logic similar to remote routes, that is, the direct connection route table entries in the source VPN are copied one by one to the routing table of the target VPN, so that the target VPN can locate the specific terminal in the source VPN through these copied host routes, and then complete cross-VRF communication. However, it's important to note that the "copy-and-paste" method for directly connected routes has significant resource consumption drawbacks: Switch routing relies on high-speed processing via hardware chips, but the chip's built-in hardware host table resources (dedicated space for storing host-level routes) have limited capacity. When the number of directly connected hosts is large (e.g., thousands of IoT devices), the direct routes for each host need to be copied to multiple target VPNs, causing the hardware host table entries to grow exponentially (number of hosts × number of VPNs). For example, if routes for 1000 directly connected hosts need to be copied to 5 target VPNs, it will occupy 5000 hardware table entries, easily exhausting the switch chip's table resources. The ultimate direct consequence is that the switch cannot continue storing direct routes for newly added hosts, significantly reducing the number of directly connected hosts that can be connected, severely limiting the network access capabilities of large-scale terminal devices.

[0024] To make the technical solution of this application clearer and easier to understand, the application scenarios of the technical solution of this application are described below with reference to the accompanying drawings. Figure 1 As shown in the figure, this figure is a schematic diagram of an application scenario provided by an embodiment of this application.

[0025] In this application scenario, the switch 104 acts as a core layer or aggregation layer device, responsible for accessing the terminal device in the first VRF (such as the enterprise "R&D department VRF", the factory "assembly workshop VRF", etc.). When the first host 102 (such as the R&D department, the assembly workshop sensor, the tenant A remote terminal) initiates cross-VRF communication, it will encapsulate the first packet (containing service data and VPN identifier) through the first VPN and send it to the directly connected switch 104, that is, the switch 104 receives the first packet from the first host 102 in the first VRF. Further, the switch 104 parses the IP header (such as IPv4 / IPv6 header parsing) through the network layer protocol, extracts the destination IP address (i.e. the IP address of the target device 106, such as 192.168.5.20) from the IP header of the first packet. In this process, the switch will check the legality of the destination IP address (such as whether it is a private network address, whether it conforms to the subnet mask rule), and if the address is invalid, the packet will be discarded directly to avoid invalid forwarding occupying resources. Wherein, the switch 104 is built-in "destination IP address-second VRF identifier" mapping table (which can be dynamically synchronized by the controller or manually pre-configured), after extracting the destination IP address, it will immediately query the mapping table, and then the switch 104 can quickly determine the second VRF identifier, and determine the target forwarding domain that the first packet needs to enter, that is, the target address extraction and processing of the first packet, and determine that the destination address of the first packet is the target device 106. Finally, the switch 104 can call the second VRF exclusive routing table (not the global routing table) based on "destination IP address (192.168.5.20) + second VRF identifier", and can determine the optimal forwarding path by combining link state, device reachability and load balancing strategy, etc. to complete the forwarding of the packet.

[0026] In order to make the technical solutions of the present application clearer and easier to understand, the following will introduce a direct link cross-VRF communication method provided by the embodiments of the present application in combination with the above application scenario. As shown in Figure 2 The figure is a flowchart of a direct link cross-VRF communication method provided by an embodiment of the present application.

[0027] S201, in the case of receiving the first packet of the first virtual private network (VPN), extracting the destination IP address in the first packet.

[0028] The first virtual private network (VPN) can refer to a logically isolated virtual network space (such as a departmental network of an enterprise, a cloud tenant network, etc.), which can be isolated from other networks through technical means. The first message is from a first host under a first virtual routing and forwarding (VRF) identifier, and the destination IP address does not belong to the host address under the first VRF identifier in the first VPN. The first VRF identifier can be a specific implementation carrier of the first VPN at the technical level, which allocates independent routing table and forwarding space for the first VPN to ensure that its routing information is isolated from other VPNs, and the identifier is used to uniquely distinguish the VRF instance. The first host can be a terminal device (such as a server or a workstation) connected to the network corresponding to the first VRF identifier, and the IP address of the first host belongs to the direct connection address range of the first VRF. The destination IP address can be the IP address of the target device to be accessed by the first message, and the address does not belong to the host address under the first VRF (i.e., belongs to the direct connection host address of other VRFs), so cross-VRF communication is required.

[0029] Optionally, a mapping relationship between the direct connection network segment route and the corresponding VRF identifier is established through the border gateway protocol (BGP) to construct a mapping relationship table.

[0030] It should be noted that the border gateway protocol (BGP) is a dynamic routing protocol used to transfer routing information between different autonomous systems or networks, which is used here to transfer the direct connection network segment route of the source VRF to the target VRF to provide routing basis for cross-VRF communication. The direct connection network segment route is a network segment route (such as 192.168.1.0 / 24) containing multiple direct connection host IP addresses, rather than a 32-bit full mask route of a single host, which can cover all direct connection hosts in the network segment. The mapping relationship table stores the association between the direct connection network segment route and the corresponding VRF identifier (such as the network segment 192.168.1.0 / 24 corresponding to the VRF2 identifier), which is used to quickly locate the target VRF to which the destination IP address belongs.

[0031] For example, the direct connection network segment route (such as 192.168.1.0 / 24 containing the destination host destination IP address) in the source VRF (such as the second VRF) can be introduced into the first VRF (the VRF identifier corresponding to the first VPN is “VRF1”) in advance through the BGP protocol. Further, in the first VRF, the introduced direct connection network segment route is associated with the source VRF identifier (such as the VRF identifier corresponding to the second VRF is “VRF2”) to which the network segment belongs. Then, based on the above association, a mapping relationship table can be constructed in the lookup module (such as TCAM resource) of the switch chip, and the table entry format can be “direct connection network segment route→corresponding VRF identifier”.

[0032] Further, in the case that the switch receives a first packet from a first host under a first VRF identification (the purpose of the packet is to access a host under another VRF, such as a host under a second VRF), a destination IP address (such as 192.168.1.5, a directly connected host under the second VRF) can be parsed and extracted from the first packet.

[0033] It should be noted that the extraction of the destination IP address is the first step of "identifying the final device to which the packet points" in cross-VRF communication. In the case of a large number of directly connected devices, the destination IP address of each device is its unique identifier in the network (even if there is IP overlap, it can be further distinguished by the VRF identifier later), and this extraction action directly provides the most critical index item for the mapping relationship table, lays the foundation for "accurate positioning of the communication object", and provides the core matching basis for the mapping relationship table.

[0034] S202, determining the second VRF identification corresponding to the destination IP address based on the destination IP address and the mapping relationship table.

[0035] The mapping relationship table includes the mapping relationship between the directly connected network segment route and the VRF identification, and can be used to quickly locate the target VRF to which the destination IP address belongs.

[0036] One implementation manner is to determine whether the destination IP address belongs to the address range of any directly connected network segment route in the mapping relationship table; if yes, the VRF identification corresponding to the directly connected network segment route is determined as the second VRF identification corresponding to the destination IP address; if not, the VRF field in the first packet is not updated, and the VRF identification to which the first packet belongs is determined as the second VRF identification.

[0037] The VRF identification can be used to uniquely distinguish different virtual routing forwarding instances (for example, the VRF identification of the first VRF is "VRF1", and the VRF identification of the second VRF is "VRF2"), and ensure that the routing and forwarding spaces of different VRFs are isolated from each other; the second VRF identification is the VRF identification corresponding to the destination IP address finally determined through the mapping relationship table (which can be the identification of another VRF, or the identification of the original VRF of the first packet), and is the key basis for subsequent forwarding path lookup.

[0038] As the above example, the destination IP address (such as 192.168.1.5) can be used as a key to traverse the address range of all direct network segment routes in the mapping relationship table (such as sequentially checking 10.0.2.0 / 24, 192.168.3.0 / 24, 192.168.1.0 / 24, etc.), so as to match the direct network segment route (such as 192.168.1.5 matching 192.168.1.0 / 24) to which the destination IP address belongs in the mapping relationship table; and then, the corresponding VRF identifier (such as the identifier "VRF2" of the second VRF) can be obtained from the mapping relationship table according to the matched direct network segment route, that is, the target VRF to be accessed by the first packet across the domain.

[0039] It should be noted that in the access scene of a large number of direct connection devices (such as thousands of terminals, multi-branch office devices, etc.), the core requirement is to attribute different devices to corresponding VRFs (virtual routing forwarding domains) to realize logical isolation. The essence of determining the second VRF identifier through "destination IP + mapping table" is to bind a unique "VRF identity tag" for the IP address of each device, which lays a foundation for "precise division of VRF attribution of a large number of devices" and solves the logical isolation problem of large-scale access; and when a large number of devices are supported, the traditional cross-VRF communication needs to manually configure the VRF membership (such as interface binding VRF) on each device or access switch, and the more the devices, the more the configuration workload and error probability increase exponentially. However, through "destination IP + mapping table" to determine the second VRF identifier, the association logic of VRF is transferred from "single device configuration" to "core mapping table unified management", which lays a foundation for "simplifying device access configuration" and reduces the operation and maintenance cost of large-scale deployment; furthermore, the core of cross-VRF communication is "first determine VRF, then select path", and the second VRF identifier is a key bridge connecting "device IP" and "forwarding path". After determining the second VRF identifier through the mapping table, it is equivalent to determining the "forwarding domain" that the packet needs to enter - different VRFs correspond to independent routing tables and forwarding strategies. Subsequently, only the routing information in the domain needs to be called based on the second VRF identifier, so as to calculate the accurate forwarding path, which lays a foundation for "dynamic association of forwarding path and VRF" and provides a logical basis for subsequent efficient forwarding; finally, when a large number of devices are accessed, the private IP address resource is limited, and IP overlap often occurs between multiple VRFs (such as VRF-A and VRF-B both using 192.168.0.0 / 24). If only the destination IP is relied on, the device attribution cannot be distinguished, but through "destination IP + mapping table" to determine the second VRF identifier, the unique distinction of "same IP + different VRF" can be realized, which lays a foundation for "conflict avoidance in IP address reuse scene" and improves the IP utilization rate of large-scale network.

[0040] S203, determining the forwarding path of the first packet based on the destination IP address and the second VRF identifier.

[0041] One implementation manner is to update the VRF field in the first packet to a second VRF identifier; to perform route entry matching based on the destination IP address and the second VRF identifier; if the matching is successful, to determine the destination host and the forwarding path corresponding to the first packet based on the matching successful route entry; and if the matching is not successful, to discard the first packet.

[0042] The VRF field is a field in the packet header for identifying the VRF to which the packet belongs, similar to a "pass card", which determines the route space in which the packet is forwarded in a VRF; the route entry is a forwarding rule stored in a specific VRF routing table, containing information such as "destination IP address range", "next hop", "outbound interface", etc., which is used to guide how the packet reaches the target host; the forwarding path is the specific forwarding route from the current switch to the destination host, which is determined by the next hop, outbound interface, etc. in the route entry, and is the "route map" of the actual transmission of the packet.

[0043] As shown in the above example, the VRF field (original first VRF identifier) carried in the first packet can be updated to the target VRF identifier (such as the identifier "VRF2" of the second VRF), so that the first packet has the "privilege" to enter the target VRF; then, the corresponding VRF routing table (such as the exclusive routing table of VRF2) can be located according to the updated target VRF identifier (such as the identifier "VRF2" of the second VRF); then, the target VRF routing table can be accurately searched with "updated target VRF identifier + destination IP address" (i.e. second VRF identifier + 192.168.1.5) as the key, such as traversing the entries according to the routing priority (such as long mask priority) to check whether the "destination IP range" of an entry contains the current destination IP address (such as whether 10.0.2.5 is within the range of "10.0.2.0 / 24").

[0044] Further, if a matching route entry is found, the entry state (such as whether it is activated, whether there is an outbound interface failure, etc.) is further checked to ensure that it can be used for forwarding; key information such as the IP address of the next hop device (such as 10.0.1.2), the outbound interface (such as the GE0 / 0 / 1 port of the switch), the forwarding priority, etc. can be extracted from the matching route entry; then, a complete forwarding path can be generated by combining the above information, such as the first packet being sent from the GE0 / 0 / 1 port of the current switch to the next hop 10.0.1.2, and finally reaching the host (10.0.2.5) corresponding to the destination IP; then, the switch can send the packet from the specified outbound interface to enter the forwarding process of the next hop device to complete the cross-VRF communication on the direct link.

[0045] Further, if no matching valid entry is found after traversing the target routing table (e.g., the destination IP address does not exist in any routing range, or none of the entries are available), it is determined that the forwarding fails; further, in order to avoid invalid messages occupying network resources, the first message is discarded, and information such as the source IP, destination IP, second VRF identifier, etc. of the message can be saved, and a failure log is recorded, facilitating subsequent troubleshooting (e.g., routing configuration errors, offline destination host, etc.).

[0046] It should be noted that the second VRF identifier is associated by the "destination IP + mapping relationship table" in the embodiment, only a centralized mapping table needs to be maintained in the core device (such as a gateway or a route reflector), and there is no need to configure the VRF parameters for each device, for example, when 100 directly connected devices are added, only the entry of "device destination IP-corresponding VRF identifier" needs to be supplemented in the mapping table, and there is no need to modify the local configuration of each device, the operation and maintenance efficiency is greatly improved, and the complexity of large-scale deployment is greatly reduced; moreover, the forwarding path is determined directly based on "destination IP (device positioning) + second VRF identifier (forwarding domain positioning)", the redundant step of "first searching VRF and then searching route" is omitted, the forwarding decision is simplified from "multi-step table searching" to "one-time mapping matching", for example, when thousands of devices concurrently communicate across VRF, the forwarding delay can be reduced from 10-20 ms to 3-5 ms, and the core device does not need to maintain a large number of dispersed VRF routing tables, only needs to quickly locate the forwarding domain through the mapping table, and the forwarding efficiency and stability in a large-scale scenario are significantly improved; moreover, by introducing the mapping relationship table with dynamic updating capability (such as automatically updating the "destination IP-VRF identifier" association through the controller automatic discovery, DHCP binding and other mechanisms), it is only necessary to write the destination IP and the VRF identifier of the newly added directly connected device into the mapping table through the automatic registration mechanism when the directly connected device is added, and only the corresponding entry needs to be removed in the mapping table when the device is deleted, without modifying the configuration of other devices, supporting the smooth expansion of the device scale from hundreds to tens of thousands, and meeting the dynamic growth demand of large-scale network; moreover, through the double positioning of "destination IP + second VRF identifier", even if the device IP overlaps in different VRFs, the forwarding domain can be accurately distinguished through the second VRF identifier, for example, there are devices using "192.168.1.10" in VRF-A and VRF-B, and the mapping table can record "192.168.1.10-VRF-A" and "192.168.1.10-VRF-B" respectively, and the correct forwarding path is directly located through the destination IP matching to the corresponding VRF identifier during forwarding, completely avoiding the communication conflict caused by large-scale device IP overlap, and improving the accuracy of cross-VRF communication; finally, the core device only needs to maintain a "destination IP-VRF identifier" mapping table, without storing a large number of dispersed VRF routing tables, and the memory occupancy can be significantly reduced; at the same time, the forwarding decision does not need complex route calculation, but only relies on mapping table matching, and the CPU utilization rate is significantly reduced, which enables the core device (such as a switch) to support more directly connected devices, and significantly improves the resource utilization efficiency and access capacity of the network.

[0047] The direct link cross VRF communication method provides a direction for subsequent determination of a destination VRF by extracting a destination IP address in the first message in a case where a first message of a first virtual private network (VPN) is received. Furthermore, the second VRF identifier corresponding to the destination IP address can be determined based on the destination IP address and the mapping relationship table, so as to realize accurate determination of the destination VRF. Finally, the forwarding path of the first message can be determined based on the destination IP address and the second VRF identifier, so as to realize accurate communication of the message across the VRFs. The mapping relationship table including the mapping relationship between the "IP address" and the "VRF" is introduced, so as to provide a way for fast implementation of the cross VRF communication. Finally, a large number of direct connection devices are accessed by only maintaining the mapping relationship table.

[0048] The above Figures 1 to 2 The direct link cross VRF communication method provided by the embodiments of the present application is described in detail, and the device and the apparatus provided by the embodiments of the present application will be introduced below with reference to the drawings.

[0049] As Figure 3 shown, the figure is a schematic diagram of a direct link cross VRF communication device provided by the embodiments of the present application. The device 300 includes an extraction module 301, an identifier determination module 302, and a path determination module 303, wherein: The extraction module 301 is configured to extract a destination IP address in a first message in a case where the first message of a first virtual private network (VPN) is received. The first message is from a first host under a first virtual routing and forwarding (VRF) identifier, and the destination IP address does not belong to the host address under the first VRF identifier in the first VPN. The identifier determination module 302 is configured to determine a second VRF identifier corresponding to the destination IP address based on the destination IP address and a mapping relationship table. The path determination module 303 is configured to determine a forwarding path of the first message based on the destination IP address and the second VRF identifier.

[0050] In one embodiment, the mapping relationship table includes a mapping relationship between a direct link network segment route and a VRF identifier.

[0051] In one embodiment, the identifier determination module 302 is specifically configured to: determine whether the destination IP address belongs to an address range of any direct link network segment route in the mapping relationship table; if yes, determine the VRF identifier corresponding to the direct link network segment route as the second VRF identifier corresponding to the destination IP address.

[0052] In one embodiment, the path determination module 303 is specifically configured to: Update the VRF field in the first packet to the second VRF identifier; perform routing table matching based on the destination IP address and the second VRF identifier; if a match is successful, determine the destination host and forwarding path corresponding to the first packet based on the successfully matched routing table entry.

[0053] In one embodiment, the identifier determination module 302 is specifically used for: Determine whether the destination IP address belongs to the address range of any directly connected network segment route in the mapping table; if not, do not update the VRF field in the first packet, and determine the VRF identifier of the first packet as the second VRF identifier.

[0054] In one embodiment, the direct link across VRF communication device 300 further includes: The relationship table construction module is used to establish a mapping relationship between directly connected network segment routes and corresponding VRF identifiers through the Border Gateway Protocol (BGP) and construct a mapping relationship table.

[0055] In one embodiment, the path determination module 303 is specifically used for: If a match is not found, the first message will be discarded.

[0056] The direct link cross-VRF communication device 300 according to the embodiments of this application can correspond to the execution of the method described in the embodiments of this application, and the other operations and / or functions of each module / unit of the direct link cross-VRF communication device 300 are respectively for implementing Figure 2 For the sake of brevity, the corresponding processes of each method in the illustrated embodiments will not be described in detail here.

[0057] This application also provides a computing device. This computing device can be a local computing device or an application server.

[0058] like Figure 4 As shown in the figure, this is a schematic diagram of a computing device provided in an embodiment of this application. The computing device 700 includes a bus 701, a processor 702, a communication interface 703, and a memory 704. The processor 702, the memory 704, and the communication interface 703 communicate with each other via the bus 701.

[0059] The 701 bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, Figure 4 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0060] The processor 702 can be any one or more of a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP), etc.

[0061] The communication interface 703 is configured to communicate with an external device.

[0062] The memory 704 can include a volatile memory, such as a random access memory (RAM), and / or a non-volatile memory, such as a read-only memory (ROM), a floppy disk, a hard disk, or a solid state drive (SSD).

[0063] The memory 704 stores executable code, and the processor 702 executes the executable code to perform the direct link cross VRF communication method.

[0064] Specifically, in the case of implementing the direct link cross VRF communication method as described above, Figure 3 In the case of implementing the direct link cross VRF communication method as described above, Figure 3 In the case of implementing the direct link cross VRF communication method as described above, Figure 3 The software or program code required to implement the functions of the modules / units in the above embodiments can be partially or entirely stored in the memory 704. The processor 702 executes the program code corresponding to each unit stored in the memory 704 to perform the direct link cross VRF communication method.

[0065] The embodiments of the present application also provide a computer readable storage medium. The computer readable storage medium can be any available medium or data storage device that can store data which can be accessed by a computing device, such as a data center or the like containing one or more available media. The available media can be a magnetic medium (e.g., a floppy diskette, a hard disk drive), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid state hard drive) or the like. The computer readable storage medium includes instructions that instruct a computing device to perform the direct link cross VRF communication method.

[0066] The embodiments of the present application further provide a computer program product including one or more computer instructions. When the computer instructions are loaded and executed on a computing device, the computer instructions produce, in whole or in part, the processes or functions described in the embodiments of the present application.

[0067] The computer instructions can be stored in a computer readable storage medium or transmitted from one computer readable storage medium to another computer readable storage medium, for example, the computer instructions can be transmitted from one website site, computer or data center to another website site, computer or data center through wired (for example, coaxial cable, optical fiber, digital subscriber line) or wireless (for example, infrared, wireless, microwave, etc.).

[0068] The computer program product is executed by a computer, and the computer executes any one of the direct link cross VRF communication methods. The computer program product can be a software installation package, and when the direct link cross VRF communication method is needed, the computer program product can be downloaded and executed on the computer.

[0069] The description of the corresponding processes or structures of each of the above figures has its own emphasis, and the parts not described in detail in a certain process or structure can be referred to the related description of other processes or structures.

[0070] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited to this, any change or replacement within the technical scope disclosed in the present application should be covered in the protection scope of the present application.

Claims

1. A direct link cross-VRF communication method, characterized in that, The method includes: Upon receiving a first packet from a first Virtual Private Network (VPN), the destination IP address is extracted from the first packet; wherein the first packet originates from a first host under the first Virtual Router and Forwarder (VRF) identifier, and the destination IP address does not belong to the host address under the first VRF identifier in the first VPN. Based on the destination IP address and the mapping table, determine the second VRF identifier corresponding to the destination IP address; Based on the destination IP address and the second VRF identifier, the forwarding path of the first packet is determined.

2. The method according to claim 1, characterized in that, The mapping table includes the mapping relationship between directly connected network segment routes and VRF identifiers.

3. The method according to claim 1, characterized in that, The step of determining the second VRF identifier corresponding to the destination IP address based on the destination IP address and the mapping table includes: Determine whether the destination IP address belongs to the address range of any directly connected network segment route in the mapping table; If so, the VRF identifier corresponding to the directly connected network segment route is determined as the second VRF identifier corresponding to the destination IP address.

4. The method according to claim 1, characterized in that, Determining the forwarding path of the first packet based on the destination IP address and the second VRF identifier includes: Update the VRF field in the first message to the second VRF identifier; Based on the destination IP address and the second VRF identifier, perform routing table entry matching; If a match is found, the destination host and forwarding path corresponding to the first packet are determined based on the matching routing table entry.

5. The method according to claim 1, characterized in that, The step of determining the second VRF identifier corresponding to the destination IP address based on the destination IP address and the mapping table includes: Determine whether the destination IP address belongs to the address range of any directly connected network segment route in the mapping table; If not, the VRF field in the first message will not be updated, and the VRF identifier to which the first message belongs will be determined as the second VRF identifier.

6. The method according to claim 1, characterized in that, The method further includes: Using the Border Gateway Protocol (BGP), a mapping relationship is established between directly connected network segment routes and their corresponding VRF identifiers, and the mapping relationship table is constructed.

7. The method according to claim 4, characterized in that, The step of matching routing table entries based on the destination IP address and the second VRF identifier includes: If the match fails, the first message is discarded.

8. A direct-link cross-VRF communication device, characterized in that, The device includes: The extraction module is used to extract the destination IP address from the first packet received from the first virtual private network (VPN); wherein the first packet comes from the first host under the first virtual router and forwarding VRF identifier, and the destination IP address does not belong to the host address under the first VRF identifier in the first VPN; The identifier determination module is used to determine the second VRF identifier corresponding to the destination IP address based on the destination IP address and the mapping relationship table; The path determination module is used to determine the forwarding path of the first packet based on the destination IP address and the second VRF identifier.

9. A computing device, characterized in that, Including memory and processor; The memory stores one or more computer programs, the one or more computer programs including instructions; when the instructions are executed by the processor, the computing device performs the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store a computer program for performing the method as described in any one of claims 1 to 7.

Images