Route table updating method and apparatus, electronic device, and readable storage medium

Abstract

This invention provides a routing table update method, apparatus, electronic device, and readable storage medium, comprising: obtaining a longest prefix matching routing table and a virtual route forwarding array, wherein the virtual route forwarding array carries Internet Protocol (IP) addresses; setting the content of each entry in the longest prefix matching routing table to a null pointer; determining the target entry in the longest prefix matching routing table corresponding to the virtual route forwarding array using the IP address; and adjusting the null pointer in the target entry to a pointer pointing to the virtual route forwarding array, thereby saving storage space.

Description

Technical Field

[0001] This invention belongs to the field of data processing, and in particular relates to a routing table update method, apparatus, electronic device, and readable storage medium. Background Technology

[0002] Routing lookup algorithms play a crucial role in networks, being one of the main factors determining the performance of Layer 3 forwarding elements. Although various routing lookup algorithms exist, each with its own focus, lookup speed remains the ultimate goal for every algorithm. The LPM (Longest Prefix Match) lookup table in the DPDK FIB (Data Plane Development Kit Forwarding Information Base) library is one such algorithm. It achieves maximum lookup performance through the DIR-24-8 data structure, ensuring that most routing looksup require only one lookup, and a few require at most two. However, this high performance comes at the cost of storage space, making it a typical example of a space-for-time tradeoff algorithm.

[0003] Therefore, although this algorithm performs well in certain scenarios, it has limitations in its application scenarios. For example, in VRF (Virtual Routing and Rorwarding) scenarios, VRF requires the use of multiple independent route lookup tables, which can cause DPDK's LPM lookup table to occupy a large amount of storage space, and may even make it unusable.

[0004] In conclusion, while the LPM lookup table in the DPDK FIB library performs excellently in terms of lookup speed, its huge storage requirements limit its application in certain specific scenarios. Summary of the Invention

[0005] This invention provides a routing table update method, apparatus, electronic device, and readable storage medium to address the limitation of current DPDK FIB library's LPM lookup table in terms of application scenarios due to its space-for-time tradeoff configuration.

[0006] To solve the above-mentioned technical problems, the present invention is implemented as follows:

[0007] In a first aspect, the present invention provides a routing table update method, the method comprising:

[0008] Obtain the longest prefix matching routing table and the virtual route forwarding array, wherein the virtual route forwarding array carries Internet Protocol addresses;

[0009] Set the content of each entry in the longest prefix matching routing table to a null pointer.

[0010] The target entry in the longest prefix matching routing table corresponding to the virtual route forwarding array is determined using the Internet Protocol address.

[0011] Adjust the null pointer in the target entry to a pointer to the virtual route forwarding array.

[0012] Optionally, before obtaining the longest prefix matching routing table and the virtual route forwarding array, the method further includes:

[0013] Obtain several virtual routing forwarding tenants, wherein the virtual routing forwarding tenants carry Internet Protocol addresses;

[0014] Obtain the network segment of the Internet Protocol address;

[0015] The virtual routing forwarding tenants are divided according to the network segment of the Internet Protocol address to obtain several division regions for the virtual routing forwarding tenants;

[0016] A virtual route forwarding array is generated based on several partitioned regions.

[0017] Optionally, generating a virtual route forwarding array based on several partitioned regions includes:

[0018] For any of the aforementioned partitioned regions, obtain the number of virtual routing forwarding tenants contained in the partitioned region, the numerical identifier carried by the virtual routing forwarding tenants, and the next-hop routing information;

[0019] Based on the number of virtual route forwarding tenants contained in the partitioned region, obtain the length of the virtual route forwarding array corresponding to the partitioned region;

[0020] Based on the next-hop routing information carried by the virtual route forwarding tenant, determine the elements in the virtual route forwarding array;

[0021] The position of each element in the virtual route forwarding array is determined based on the numerical identifier carried by the virtual route forwarding tenant.

[0022] Optionally, after obtaining the number of virtual routing forwarding tenants included in any of the partitioned regions, the numerical identifier carried by the virtual routing forwarding tenants, and the next-hop routing information, the method further includes:

[0023] If the number of virtual route forwarding tenants in the partitioned area is greater than a preset threshold, then a hash table containing a preset number of entries is set.

[0024] Obtain the target network segment of the Internet Protocol address carried by the virtual route forwarding tenant in any of the aforementioned partitioned regions;

[0025] Set the target network segment as the identifier of the hash table;

[0026] Based on the digital identifier carried by the virtual route forwarding tenant, determine the entry in the hash table corresponding to the next-hop routing information in the virtual route forwarding tenant.

[0027] Optionally, before determining the target entry in the longest prefix matching routing table corresponding to the virtual route forwarding array using the Internet Protocol address, the method further includes:

[0028] Obtain the first network mask containing a preset number of bits;

[0029] The index of the longest prefix matching routing table entry is determined based on the first network mask of the preset number of bits.

[0030] Optionally, determining the target entry in the longest prefix matching routing table corresponding to the virtual route forwarding array using the Internet Protocol address further includes:

[0031] Obtain the second network mask of the Internet Protocol address and the actual number of bits in the second network mask;

[0032] Compare the actual number of digits with the preset number of digits;

[0033] If the actual number of bits is less than the preset number of bits, then the Internet Protocol address is expanded according to the preset number of bits to obtain the target Internet Protocol address;

[0034] The target entry of the virtual route forwarding array in the longest prefix matching routing table is determined by the target Internet Protocol address.

[0035] Optionally, after adjusting the null pointer in the target entry to a pointer to the virtual route forwarding array, the method further includes:

[0036] Obtain the Internet Protocol address and numeric identifier of the virtual route forwarding tenant to be queried;

[0037] The Internet Protocol address of the tenant is forwarded through the virtual route to be queried, and the entry to be queried is determined in the longest prefix matching routing table;

[0038] The target virtual route forwarding array is determined by the pointer in the query entry;

[0039] The target location is determined in the target virtual route forwarding array by using the digital identifier of the virtual route forwarding tenant to be queried;

[0040] Obtain the next-hop routing information of the virtual route forwarding tenant to be queried from the target location.

[0041] In a second aspect, the present invention provides a routing table update apparatus, the apparatus comprising:

[0042] The first acquisition module is used to acquire the longest prefix matching routing table and the virtual route forwarding array, wherein the virtual route forwarding array carries Internet Protocol addresses;

[0043] The configuration module is used to set the content of each entry in the longest prefix matching routing table to a null pointer.

[0044] The first determining module is used to determine the target entry in the longest prefix matching routing table corresponding to the virtual route forwarding array based on the Internet Protocol address.

[0045] The adjustment module is used to adjust the null pointer in the target entry to a pointer that points to the virtual route forwarding array.

[0046] Thirdly, the present invention provides an electronic device, comprising: a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the above-described routing table update method.

[0047] Fourthly, the present invention provides a readable storage medium that, when the instructions in the storage medium are executed by the processor of an electronic device, enables the electronic device to perform the above-described routing table update method.

[0048] In this embodiment of the invention, the longest prefix matching routing table and the virtual route forwarding array are obtained, with the virtual route forwarding array carrying Internet Protocol (IP) addresses. The content of each entry in the longest prefix matching routing table is set to a null pointer. The target entry corresponding to the virtual route forwarding array in the longest prefix matching routing table is determined using the IP address. The null pointer in the target entry is adjusted to a pointer to the virtual route forwarding array. By updating the content of the longest prefix matching routing table to pointers, multiple virtual route forwarding arrays can share the LPM table, ensuring that the lookup speed remains unchanged while saving storage space. The data structure of the virtual route forwarding array guarantees lookup speed, and the virtual route forwarding array is configured on demand. Furthermore, idle entries do not require requesting configuration of the virtual route forwarding array, further saving storage space. Attached Figure Description

[0049] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0050] Figure 1 This is a schematic diagram of a routing table configuration for a DIR-24-8 data structure provided in an embodiment of the present invention;

[0051] Figure 2 This is a schematic diagram of adding a DPDK LPM lookup table route according to an embodiment of the present invention;

[0052] Figure 3 This is a flowchart illustrating the steps of a routing table update method provided in an embodiment of the present invention.

[0053] Figure 4 yes Figure 3 The diagram shown is a schematic of setting a hash table for virtual route forwarding in a routing table update method provided by an embodiment of the present invention;

[0054] Figure 5 yes Figure 3 The diagram shown is a schematic diagram of null pointer setting in a routing table update method provided by an embodiment of the present invention;

[0055] Figure 6 yes Figure 3 The flowchart shown is a step 103 of a routing table update method provided in an embodiment of the present invention;

[0056] Figure 7 yes Figure 3 The diagram shown is a schematic of setting a virtual route forwarding array in a routing table update method provided by an embodiment of the present invention;

[0057] Figure 8 This is a structural diagram of a routing table update device provided in an embodiment of the present invention;

[0058] Figure 9 This is a structural diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0059] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0060] This invention applies to the routing lookup scenario of the FIB (Forwarding Information Base) in DPDK (Data Plane Development Kit) within VRF (Virtual Routing and Forwarding). DPDK is an open-source library and driver set primarily running on Linux systems, providing functions and drivers for fast packet processing. It significantly improves data processing performance and throughput, enhancing the efficiency of data plane applications. The FIB determines how to forward packets based on the network prefix. VRF technology achieves data or service isolation by creating multiple routing tables on a Layer 3 forwarding device (also known as a Layer 3 forwarding network element), commonly used in applications requiring isolation such as MPLS VPNs and firewalls. The Layer 3 forwarding device can be a router, firewall, or Layer 3 switch, and routing lookup can also be achieved through these network devices.

[0061] Routing lookup scenarios require routing lookup algorithms. Currently, various algorithms exist, each with its own focus, but lookup speed is the ultimate goal for each. Among them, the LPM (Longest Prefix Match) lookup table algorithm in the DPDK FIB library achieves peak lookup performance. Using a DIR-24-8 data structure, it ensures that most route looksup require only one lookup, and a few require at most two. However, the high performance of the DPDK FIB library's LPM lookup table comes at the cost of storage space. It's worth noting that the LPM table, implemented in the DPDK LPM library component, uses a 32-bit key longest prefix match table search method for finding the best route match in IP forwarding applications; it is a special type of routing table. Typically, a routing table stores the mapping between the destination Internet Protocol address and the next-hop address. Routers determine the transmission path of data packets based on the Internet Protocol address and the routing table, ensuring that data can be sent from the source device to the destination device. The LPM table performs route looksup using a DIR-24-8 data structure, and the Internet Protocol address used can be either IPv4 or IPv6. IPv4 is the fourth version of the Internet Protocol (IP). It defines the format of IPv4 addresses and data packets. IPv4 addresses are 32-bit and are typically represented in dotted decimal notation, such as 192.168.1.1. IPv6 is the sixth version of the IP protocol, designed to replace IPv4 as the next-generation IP protocol. It defines the format of IPv4 addresses and the structure of data packets. IPv6 addresses are 128-bit and are typically represented in colon-separated hexadecimal notation, such as 2001:0db8:85a3:0000:0000:8a2e:0370:7334.

[0062] Based on the above, taking IPv4 addresses as an example, this section explains the storage space occupied by the LPM lookup table currently using the DIR-24-8 data structure. Figure 1As shown, the table is divided into two parts: one part corresponds to the first 24 bits of the mask, and the other part corresponds to the last 8 bits of the mask. Each entry in the table can be used to store next-hop routing information. Next-hop routing information refers to the address of the next network node or device to which the data packet should be forwarded after being processed on the current router or switch. The size unit is bytes, and the available values ​​are 1, 2, 4, and 8. Taking 4 bytes as an example, the storage space occupied by the table corresponding to the 24-bit mask is 2^24 * 4B = 64MB. There can be a maximum of 2^24 tables corresponding to the last 8 bits of the mask, and the size of each table is 2^8 * 4B = 1KB. The maximum storage space occupied is 2^24 * 1KB = 16GB. Therefore, the maximum storage space occupied by the entire LPM lookup table is 64MB + 16GB. Here, KB, MB, and GB are computer storage units, called kilobytes, megabytes, and gigabytes, respectively. As can be seen, the entire LPM lookup table occupies a relatively large amount of storage space. Furthermore, in actual use, most routing entries have masks of 24 bits or less, so only a 64MB table is used. For routing entries with masks exceeding 24 bits, the number is limited to ensure that the storage space occupied by the table corresponding to the last 8 bits of the mask is limited.

[0063] Furthermore, the operating principle of DPDK's LPM lookup table will be explained. LPM has two types of tables, and both types are used identically when adding and looking up routes. Taking the table corresponding to a 24-bit mask as an example, if a route entry is added for a project with a network segment of 10.12.132.0 / 22 ​​and a next-hop value of 100, the table content after the addition will be as follows: Figure 2As shown, for network segments with a mask of 24 bits or less, all IP address positions within the mask bits from the destination network segment to the 24-bit mask are filled with the next-hop value—100. That is, network segments with a mask less than 24 bits are expanded to a 24-bit mask. In this example, 10.12.132.0 / 22, the binary representation of 132 is 1000 0100, and the last two bits are the part to be expanded: 1000. 01xx, where xx includes values ​​00, 01, 10, and 11. The corresponding 24-bit mask IPs are: 10.12.132.0 / 24, 10.12.133.0 / 24, 10.12.134.0 / 24, and 10.12.135.0 / 24. In the code, the corresponding data structure is an array. The value of these IPs shifted right by 8 bits is the array index. Therefore, 10.12.132.0 / 24 shifted right by 8 bits is 10.12.132, and the array index is 10*256^2 + 12*256 + 132 = 658564, where 10... Shifting 12.133.0 / 24 right by 8 bits gives 10.12.133, and the array index is 10*256^2 + 12*256 + 133 = 658565. Shifting 10.12.134.0 / 24 right by 8 bits gives 10.12.134, and the array index is 10*256^2 + 12*256 + 134 = 658566. Shifting 10.12.135.0 / 24 right by 8 bits gives 10.12.135, and the array index is 10*256^2 + 12*256 + 135 = 658567. Fill all entries in this array with the next-hop value 100. Note that the first entry in the array corresponds to index 0, which is the IP address 0.0.0.0. With the above settings, when performing a route lookup using IP addresses in the destination network segment 10.12.132.0 / 22, only one lookup is needed to find the next-hop routing information. For example, for 10.12.133.10, using the LPM longest match principle, the first 24 bits of 10.12.133.10 are used to find the array index, and the corresponding value is the next-hop content (if the next-hop indicates that a further lookup in the 8-bit mask table is needed, the last 8 bits of 10.12.133.10 are used to look up the 8-bit mask table in the same way). Since the IP address corresponding to the 24-bit mask of 10.12.133.10 is 10.12.133.0 / 24, the entry in the 24-bit mask table can be directly matched, completing the route lookup.

[0064] As can be seen from the above, the current DPDK LPM lookup table utilizes the fact that most of the actual routing entries are within a 24-bit mask and limits the number of tables corresponding to the last 8 bits of the mask, thus keeping the table's storage space relatively small. However, this method can only satisfy one or a few independent routing tables. In a VRF scenario (where each VRF tenant corresponds to an independent routing table), the storage space becomes a significant issue. For example, using DPDK's LPM lookup table in a router supporting only 100 VRF tenants, even with all routing entries using 24-bit masks, the storage space required reaches 100 * 64 MB = 6.4 GB. For scenarios supporting K or more VRF tenants, the storage space required will be even greater. Therefore, this invention proposes a routing table update method to address these problems.

[0065] Reference Figure 3 , Figure 3 This is one of the flowcharts of a routing table update method provided in an embodiment of the present invention, such as... Figure 3 As shown, the method may include:

[0066] Step 101: Obtain the longest prefix matching routing table and the virtual route forwarding array. The virtual route forwarding array carries Internet Protocol addresses.

[0067] In this embodiment of the invention, the virtual routing forwarding array is generated by multiple virtual routing forwarding tenants. Multiple virtual routing forwarding tenants are obtained from the system. Each tenant can carry one or more Internet Protocol (IP) addresses. The IP addresses carried by each virtual routing forwarding tenant are resolved to obtain their corresponding network segment information. Based on the network segments of the IP addresses, the virtual routing forwarding tenants are divided into different regions. Each region contains tenants with the same network segment. A virtual routing forwarding array is generated based on the division results. The length and content of the array depend on the number of regions and the tenant information within each region. The specific steps include:

[0068] Obtain several virtual routing forwarding tenants, each carrying an Internet Protocol address;

[0069] Obtain the network segment for the Internet Protocol address;

[0070] Based on the network segment of Internet Protocol address, several virtual routing forwarding tenants are divided to obtain several division areas for virtual routing forwarding tenants;

[0071] A virtual route forwarding array is generated based on several partitioned regions.

[0072] For example, suppose there are three virtual router forwarding tenants, each carrying the following Internet Protocol addresses: Tenant A: 192.168.1.10 / 24, 10.0.0.7 / 24; Tenant B: 172.16.0.5 / 16; Tenant C: 10.1.0.4 / 16, 192.168.2.4 / 24. The resolved network segment information for Tenant A is 192.168.1.0 / 24, 10.0.0.7 / 24. Tenant B's network segment information is 172.16.0.0 / 16, and tenant C's network segment information is 10.1.0.0 / 16, 192.168.2.0 / 24. Three partitioned areas are obtained: Area 1 (192.168.0.0 / 16) includes tenant A (192.168.1.0 / 24) and tenant C (192.168.2.0 / 24); Area 2 (...). Area 1 (10.0.0.0 / 8) includes tenant A (10.0.0.0 / 24) and tenant C (10.1.0.0 / 16). Area 3 (172.16.0.0 / 16) includes tenant B (172.16.0.0 / 16). The virtual route forwarding array of Area 1 has a length of 2, and the elements are the next-hop route information used by tenant A (192.168.1.0 / 24) and tenant C (192.168.2.0 / 24). The virtual route forwarding array of Area 2 has a length of 2, and the elements are the next-hop route information used by tenant A (10.0.0.0 / 24) and tenant C (10.1.0.0 / 16). The virtual route forwarding array of Area 3 has a length of 1, and the elements are the next-hop route information used by tenant B (172.16.0.0 / 16).

[0073] It should be noted that, as seen in the above segmentation, different IPs correspond to different network segments. Therefore, the segments can be divided into different regions, with each region corresponding to one network segment's Internet Protocol address. Subsequent occurrences of identical network segments will then be grouped into the same region.

[0074] Furthermore, after dividing the virtual routing forwarding tenants by network segment, it is necessary to determine the length of the virtual routing forwarding array to be generated based on the number of virtual routing forwarding tenants contained in each division area, determine the elements in the virtual routing forwarding array based on the next-hop routing information carried by the virtual routing forwarding tenants, and determine the position of each element in the virtual routing forwarding array based on the numerical identifier carried by the virtual routing forwarding tenants. The specific steps include:

[0075] Based on the partitioning results, obtain several partitioned regions for virtual routing forwarding tenants;

[0076] For any given region, obtain the number of virtual routing forwarding tenants contained in the region, the numerical identifier carried by the virtual routing forwarding tenants, and the next-hop routing information;

[0077] Based on the number of virtual route forwarding tenants contained in the partitioned area, obtain the length of the virtual route forwarding array corresponding to the partitioned area;

[0078] Based on the next-hop routing information carried by the virtual route forwarding tenant, determine the elements in the virtual route forwarding array;

[0079] The position of each element in the virtual route forwarding array is determined based on the numerical identifier carried by the virtual route forwarding tenant.

[0080] For example, suppose the information obtained is as follows: Region 1: Tenant A (192.168.1.0 / 24, next hop: 100, carrying numeric identifier 0), Tenant C (192.168.2.0 / 24, next hop: 200, carrying numeric identifier 1); Region 2: Tenant A (10.0.0.0 / 24, next hop: 270, carrying numeric identifier 3), Tenant C (10.1.0.0 / 16, next hop: 150, carrying numeric identifier 4); Region 3: Tenant B (172.16.0.0 / 16, next hop: 140, carrying numeric identifier 5). Based on the above information, three arrays are generated. Region 1 corresponds to array 1, with length... Given a length of 2, region 2 corresponds to array 2, and region 3 corresponds to array 3, with a length of 1. The elements in array 1 are [100, 200], the elements in array 2 are [270, 150], and the elements in array 3 are

[140] . Since 0 mod 2 = 0 and 1 mod 2 = 1, 100 is at index 0 in array 1, and 200 is at index 1 in array 1. Correspondingly, 3 mod 2 = 1 and 4 mod 2 = 0, so 150 is at index 0 in array 2, 270 is at index 1 in array 2, and 5 mod 1 = 0, so 140 is at index 0 in array 3.

[0081] Through the above steps, a corresponding virtual route forwarding array can be dynamically generated based on the Internet Protocol address segment of the virtual route forwarding tenant, and the position and content of each element can be determined to facilitate subsequent route lookup.

[0082] It should be noted that the numerical identifier carried by the virtual route forwarding tenant is generally an integer value, which can be set starting from 1. The value is incremented by 1 for each new tenant added to the array. The corresponding array index value for each virtual route forwarding tenant in each virtual route forwarding array is determined by the numerical identifier minus 1. If the numerical identifier is a non-integer value, a VRF integer value can be maintained to correspond to it.

[0083] Furthermore, the above describes the steps for storing routing information when there are a small number of virtual routing tenants. For scenarios with K or more virtual routing tenants, because the number of generated virtual routing tenant arrays is too large, it is necessary to further optimize the storage space for virtual routing tenants. In this case, a hash table for virtual routing is set up, such as... Figure 4 As shown, only virtual route forwarding arrays that actually configure routing entries will have hash tables set up for them, and pointers in these hash tables will point to dynamically added virtual route forwarding arrays. These virtual route forwarding arrays contain the next-hop storage units for virtual route forwarding tenants. In entries 4, 5, and 6 of the LPM table, there are pointers 1, 2, and 3, respectively, pointing to dynamically allocated hash tables 1 and 2. Hash table 1 contains entries pointing to dynamically allocated virtual route forwarding arrays 1 and 2. Virtual route forwarding array 1 contains the next-hop routing information 100 for virtual route forwarding tenant 1 and 500 for virtual route forwarding tenant 2; virtual route forwarding array 2 contains the next-hop routing information 200 for virtual route forwarding tenant 3. Hash table 2 contains entries pointing to dynamically allocated virtual route forwarding arrays 3 and 4. Virtual route forwarding array 3 contains the next-hop routing information 100 for virtual route forwarding tenant 4; virtual route forwarding array 4 contains the next-hop routing information 700 for virtual route forwarding tenant 5. When there are many virtual route forwarding tenants and the 24-bit mask is insufficient, an 8-bit mask LPM table will also be set up. Figure 4 Pointer 3 in the table points to an 8-bit masked LPM table. Pointers 4 and 5 are then set within this 8-bit masked LPM table, pointing to hash tables 3 and 4 respectively. Hash table 3 contains entries pointing to the dynamically requested virtual route forwarding array 5, which contains the next-hop routing information 300 for virtual route forwarding tenant 6. Hash table 4 contains entries pointing to the dynamically requested virtual route forwarding arrays 6 and 7. Virtual route forwarding array 6 contains the next-hop routing information 300 for virtual route forwarding tenant 7, and virtual route forwarding array 7 contains the next-hop routing information 900 for virtual route forwarding tenant 8. As can be seen, when the number of virtual routing tenants exceeds the set threshold, the pointer points to a hash table instead of an array when adding a route entry. Therefore, an identifier is added to the hash table using the target network segment to determine the corresponding entry. Then, the numerical identifier carried by the virtual routing tenant is used to determine the corresponding entry in the hash table. A dynamic virtual routing array is set up for virtual routing tenants belonging to the same hash table entry, and the position of their next-hop routing information in the virtual routing array is determined based on the numerical identifier carried by the virtual routing tenant. The specific steps include:

[0084] If the number of virtual route forwarding tenants in the partitioned area exceeds a preset threshold, then a hash table containing a preset number of entries is set up.

[0085] Obtain the target network segment of the Internet Protocol address carried by the virtual route forwarding tenant in any partitioned area;

[0086] Set the target network segment as the identifier of the hash table;

[0087] Based on the numerical identifier carried by the virtual route forwarding tenant, determine the corresponding entry in the hash table for the next-hop routing information in the virtual route forwarding tenant.

[0088] By following the steps above and using a shared hash table, we can not only further reduce the space for routing lookup algorithms, but also achieve the goal of efficiently finding and managing the next-hop routing information of virtual routing forwarding tenants.

[0089] It should be noted that when there are many virtual router forwarding tenants, and the 24-bit and 8-bit mask LPM tables still cannot meet the needs, the entries in the hash table can be set as pointers, and then hash sub-tables can be set to further expand the scope.

[0090] Step 102: Set the content of each entry in the longest prefix matching routing table to a null pointer.

[0091] In this embodiment of the invention, to enable a larger number of virtual routing forwarding tenants to perform route queries with minimal performance loss, some adjustments are made while balancing space and time. For example, such as... Figure 5 As shown, the content of each entry in the longest prefix matching routing table is set to a null pointer.

[0092] Step 103: Determine the target entry in the longest prefix match routing table corresponding to the virtual route forwarding array using the Internet Protocol address.

[0093] In this embodiment of the invention, after configuring the longest prefix matching routing table content as a null pointer, it is necessary to configure routing information for it. During configuration, it is necessary to first determine the index of the entry in the longest prefix matching routing table. The specific steps include:

[0094] Obtain the first network mask containing a preset number of bits;

[0095] Based on the first network mask with a preset number of bits, determine the index of the entry in the longest prefix matching routing table.

[0096] The preset number of bits can be set according to actual needs, and can be various values ​​such as 8, 16, 24, etc. This invention does not make a specific limitation, but the preset number of bits cannot exceed the number of bits of the network mask of the Internet Protocol address.

[0097] Further, in step 103, as... Figure 6 As shown:

[0098] Step 1031: Obtain the second network mask of the Internet Protocol address and the actual number of bits in the second network mask.

[0099] Step 1032: Compare the actual number of digits with the preset number of digits.

[0100] Step 1033: If the actual number of bits is less than the preset number of bits, then expand the Internet Protocol address according to the preset number of bits to obtain the target Internet Protocol address.

[0101] Step 1034: Determine the target entry in the longest prefix match routing table corresponding to the virtual route forwarding array using the target Internet Protocol address.

[0102] For example, assuming the Internet Protocol address is 10.12.132.0, the second network mask is 255.255.252.0, and the actual number of bits is 22, and the preset number of bits is 24, then the actual number of bits is less than the preset number of bits. The target Internet Protocol address after expanding 10.12.132.0 / 22 ​​is 10.12.132.0 / 24, 10.12.133.0 / 24, 10.12.134.0 / 24, and 10.12.135.0 / 24. The array indices corresponding to the longest prefix matching routing table are determined to be 658564, 658565, 658566, and 658567. The target table entry is found based on the array indices.

[0103] Step 104: Adjust the null pointer in the target table entry to a pointer to the virtual route forwarding array.

[0104] In this embodiment of the invention, after determining the target entry in the longest prefix matching routing table corresponding to the virtual route forwarding array, the null pointer in this target entry is adjusted to a pointer pointing to the virtual route forwarding array. In this way, when performing a subsequent search, after determining the target entry, the corresponding virtual route forwarding array can be determined through the pointer in the target entry.

[0105] It should be noted that the above steps illustrate the process of updating the routing table. When performing a route lookup, the information configured during the setup can be used. First, the Internet Protocol address (IPA) and numeric identifier of the virtual routing tenant to be queried need to be obtained. The IPA is used to find the corresponding entry in the routing table, and the numeric identifier is used to locate the specific next-hop routing information in the virtual routing array. Using the IPA of the virtual routing tenant to be queried, the corresponding entry is searched in the Longest Prefix Matching (LPM) table. The LPM table is used to efficiently find routing information matching the target IPA address. A pointer is obtained from the entry to be queried, pointing to the target virtual routing array. The virtual routing array stores the next-hop routing information of all virtual routing tenants associated with this entry. Using the numeric identifier of the virtual routing tenant to be queried, the corresponding position is searched in the target virtual routing array. The numeric identifier is used to uniquely identify each virtual routing tenant and associate it with its position in the array. The next-hop routing information of the virtual routing tenant to be queried is obtained from the target position. The next-hop routing information is used to determine the forwarding path of the data packet. The specific steps include:

[0106] Obtain the Internet Protocol address and numeric identifier of the virtual route forwarding tenant to be queried;

[0107] The queried entry is determined by forwarding the tenant's Internet Protocol address through the virtual route to be queried and then searching the longest prefix matching routing table.

[0108] The target virtual route forwarding array is determined by the pointer in the table entry to be queried;

[0109] The target location is determined in the target virtual route forwarding array by using the digital identifier of the virtual route forwarding tenant to be queried;

[0110] Retrieve the next-hop routing information of the virtual route forwarding tenant to be queried from the target location.

[0111] By following the steps above, the corresponding entry in the longest prefix matching routing table can be found based on the Internet Protocol address and numerical identifier of the virtual route forwarding tenant to be queried. Then, the target virtual route forwarding array is located using a pointer, ultimately obtaining the next-hop routing information for the queried virtual route forwarding tenant. This allows for efficient searching and management of the next-hop routing information for virtual route forwarding tenants.

[0112] For example, such as Figure 7As shown, the longest prefix matching routing table contains a 24-bit mask. The entries at array indices 3, 4, and 5 contain pointers 1, 2, and 3, respectively, pointing to dynamically allocated virtual route forwarding arrays. Pointer 1 at array index 3 points to virtual route forwarding array 1, containing virtual route forwarding tenants 0, 1, and 2, with corresponding next-hop route information of 100, 500, and 200. Pointer 2 at array index 4 points to virtual route forwarding array 2, containing virtual route forwarding tenants 0, 1, and 2, with corresponding next-hop route information of 100, 0, and 700. The pointer at array index 5 points to an 8-bit mask routing table. The entries at array indices 2 and 3 in the 8-bit mask routing table contain... Pointers 4 and 5 are used as pointers. Pointer 4, with index 2 in the 8-bit masked routing table, points to the dynamically allocated virtual route forwarding array 3, which contains virtual route forwarding tenants 0, 1, and 2, with corresponding next-hop routing information of 300, 0, and 0. Pointer 5, with index 3 in the 8-bit masked routing table, points to the dynamically allocated virtual route forwarding array 4, which also contains virtual route forwarding tenants 0, 1, and 2, with corresponding next-hop routing information of 300, 0, and 900. It can be seen that tenant identifiers in different arrays can be the same, but these tenant identifiers may not be related to the numerical identifiers carried by the tenants. They are simply location identifiers regenerated based on the tenant's current location after entering the virtual route forwarding array. Of course, tenant identifiers in the arrays can also be labeled according to the carried numerical identifiers; this invention does not impose specific limitations on this.

[0113] Furthermore, by setting pointers in the longest prefix matching routing table, multiple virtual route forwarding tenants can share the longest prefix matching routing table. This changes the route lookup process from finding the next hop content of the table entry to finding the pointer. The pointer is used to locate the corresponding virtual route forwarding array, and then the array content corresponding to the array index is retrieved using the virtual route forwarding tenant's numerical identifier, which is the next hop. Compared to the original one lookup, it becomes two lookups, but the lookup efficiency still has a significant speed advantage, and it also reduces the space occupied. The space usage at this time is as follows:

[0114] In a 32-bit system, a pointer is 4 bytes in size, and the table size remains unchanged. In a 64-bit system, a pointer is 8 bytes in size, and the table size doubles. For example, a table corresponding to a 24-bit mask becomes 128MB, and a table corresponding to an 8-bit mask becomes 2KB. For tables corresponding to 24-bit masks (since the number of tables corresponding to 8-bit masks is limited, its impact on storage space can be ignored), if the destination network segment mask is longer or closer to 24 bits, the number of virtual routing forwarding arrays required is less, and the storage space occupied is less; conversely, the smaller the mask, the larger the required virtual routing forwarding array. In the most extreme case, only an 8-bit mask... For Class A addresses, a destination network segment corresponds to 2^16 entries, and each entry corresponds to a virtual route forwarding array. If the number of virtual route forwarding tenants in the virtual route forwarding array is n, then the storage space occupied by the virtual route forwarding array is: 2^16 * 4 * n = 256 * n * 1 KB. For Class C addresses with a 24-bit mask, a destination network segment has only 1 entry, so the storage space occupied by the virtual route forwarding array is: 1 * 4 * n = n * 1 KB. If n is 1000, when configuring a route entry, the space occupied by the virtual route forwarding array is in the range of 1-256 MB.

[0115] In this embodiment of the invention, the longest prefix matching routing table and the virtual route forwarding array are obtained, with the virtual route forwarding array carrying Internet Protocol (IP) addresses. The content of each entry in the longest prefix matching routing table is set to a null pointer. The target entry corresponding to the virtual route forwarding array in the longest prefix matching routing table is determined using the IP address. The null pointer in the target entry is adjusted to a pointer to the virtual route forwarding array. By updating the content of the longest prefix matching routing table to pointers, multiple virtual route forwarding arrays can share the LPM table, ensuring that the lookup speed remains unchanged while saving storage space. The data structure of the virtual route forwarding array guarantees lookup speed, and the virtual route forwarding array is configured on demand. Furthermore, idle entries do not require requesting configuration of the virtual route forwarding array, further saving storage space.

[0116] Figure 8 This is a structural diagram of a routing table update device provided in an embodiment of the present invention. The device may include:

[0117] The first acquisition module 201 is used to acquire the longest prefix matching routing table and the virtual route forwarding array, the virtual route forwarding array carrying Internet Protocol addresses.

[0118] Module 202 is configured to set the content of each entry in the longest prefix matching routing table to a null pointer.

[0119] The first determining module 203 is used to determine the target entry in the longest prefix matching routing table corresponding to the virtual route forwarding array using the Internet Protocol address.

[0120] Adjustment module 204 is used to adjust null pointers in target entries to pointers to virtual route forwarding arrays.

[0121] Optionally, the routing table update device also includes:

[0122] The second acquisition module is used to acquire several virtual routing forwarding tenants, each carrying an Internet Protocol address.

[0123] The third acquisition module is used to obtain the network segment of the Internet Protocol address.

[0124] The fourth acquisition module is used to divide several virtual routing forwarding tenants according to the network segment of Internet Protocol address and obtain several division areas of virtual routing forwarding tenants.

[0125] The generation module is used to generate a virtual route forwarding array based on several divided regions.

[0126] Optionally, the generated modules specifically include:

[0127] The first acquisition submodule is used to acquire, for any given partitioned area, the number of virtual routing forwarding tenants contained in the partitioned area, the numerical identifier carried by the virtual routing forwarding tenant, and the next-hop routing information.

[0128] The second acquisition submodule is used to obtain the length of the virtual route forwarding array corresponding to the partitioned area based on the number of virtual route forwarding tenants contained in the partitioned area.

[0129] The first determination submodule is used to determine the elements in the virtual route forwarding array based on the next-hop routing information carried by the virtual route forwarding tenant.

[0130] The second determination submodule is used to determine the position of each element in the virtual route forwarding array based on the digital identifier carried by the virtual route forwarding tenant.

[0131] The hash table setting submodule is used to set up a hash table containing a preset number of entries if the number of virtual route forwarding tenants in the partitioned area exceeds a preset threshold.

[0132] The third acquisition submodule is used to acquire the target network segment of the Internet Protocol address carried by the virtual route forwarding tenant in any partitioned area.

[0133] The identifier setting submodule is used to set the target network segment as the identifier of the hash table.

[0134] The third determination submodule is used to determine the corresponding entry in the hash table for the next-hop routing information of the virtual routing tenant based on the digital identifier carried by the virtual routing tenant.

[0135] Optionally, the routing table update device also includes:

[0136] The fifth acquisition module is used to acquire a first network mask containing a preset number of bits.

[0137] The second determining module is used to determine the index of the longest prefix matching routing table entry based on the first network mask with a preset number of bits.

[0138] Optionally, the first determining module 203 specifically includes:

[0139] The fourth acquisition submodule is used to obtain the second network mask of the Internet Protocol address and the actual number of bits of the second network mask.

[0140] The comparison submodule is used to compare the actual number of digits with the preset number of digits.

[0141] The fifth acquisition submodule is used to expand the Internet Protocol address according to the preset number of bits if the actual number of bits is less than the preset number of bits, and then obtain the target Internet Protocol address.

[0142] The fourth determination submodule is used to determine the target entry in the longest prefix matching routing table corresponding to the virtual route forwarding array based on the target Internet Protocol address.

[0143] Optionally, the routing table update device also includes:

[0144] The sixth acquisition module is used to obtain the Internet Protocol address and digital identifier of the virtual routing forwarding tenant to be queried.

[0145] The third determination module is used to determine the query entry in the longest prefix matching routing table by forwarding the tenant's Internet Protocol address through the virtual route to be queried.

[0146] The fourth determination module is used to determine the target virtual route forwarding array by using the pointer in the query table entry.

[0147] The fifth determination module is used to determine the target location in the target virtual route forwarding array by using the digital identifier of the virtual route forwarding tenant to be queried.

[0148] The seventh acquisition module is used to obtain the next-hop routing information of the virtual route forwarding tenant to be queried from the target location.

[0149] In this embodiment of the invention, the longest prefix matching routing table and the virtual route forwarding array are obtained, with the virtual route forwarding array carrying Internet Protocol (IP) addresses. The content of each entry in the longest prefix matching routing table is set to a null pointer. The target entry corresponding to the virtual route forwarding array in the longest prefix matching routing table is determined using the IP address. The null pointer in the target entry is adjusted to a pointer to the virtual route forwarding array. By updating the content of the longest prefix matching routing table to pointers, multiple virtual route forwarding arrays can share the LPM table, ensuring that the lookup speed remains unchanged while saving storage space. The data structure of the virtual route forwarding array guarantees lookup speed, and the virtual route forwarding array is configured on demand. Furthermore, idle entries do not require requesting configuration of the virtual route forwarding array, further saving storage space.

[0150] The present invention also provides an electronic device, Figure 9 This is a structural block diagram of an electronic device provided in an embodiment of the present invention. See also... Figure 9 The system includes a processor 501, a memory 502, and a computer program 5021 stored in the memory and executable on the processor. When the processor executes the program, it implements the following steps: a routing table update method.

[0151] Obtain the longest prefix matching routing table and the virtual route forwarding array, wherein the virtual route forwarding array carries Internet Protocol addresses;

[0152] Set the content of each entry in the longest prefix matching routing table to a null pointer.

[0153] The target entry in the longest prefix matching routing table corresponding to the virtual route forwarding array is determined using the Internet Protocol address.

[0154] Adjust the null pointer in the target entry to a pointer to the virtual route forwarding array.

[0155] The present invention also provides a readable storage medium, wherein when the instructions in the storage medium are executed by the processor of an electronic device, the electronic device is able to perform the routing table update method of the foregoing embodiments.

[0156] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0157] The algorithms and displays provided herein are not inherently related to any particular computer, virtual system, or other device. The structure required to construct such a system is readily apparent from the above description. Furthermore, this invention is not directed to any particular programming language. It should be understood that the contents of the invention described herein can be implemented using various programming languages, and the above description of specific languages ​​is for the purpose of disclosing the best mode of implementation of the invention.

[0158] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of the invention may be practiced without these specific details. In some instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification.

[0159] Similarly, it should be understood that, in order to simplify the invention and aid in understanding one or more of the various inventive aspects, in the above description of exemplary embodiments of the invention, various features of the invention are sometimes grouped together in a single embodiment, figure, or description thereof. However, this method of disclosure should not be construed as reflecting an intention that the claimed invention requires more features than expressly recited in each claim. Rather, as reflected in the following claims, inventive aspects lie in fewer than all features of a single foregoing disclosed embodiment. Therefore, the claims following the detailed description are hereby expressly incorporated into this detailed description, wherein each claim itself is a separate embodiment of the invention.

[0160] Those skilled in the art will understand that modules in the device of the embodiments can be adaptively changed and placed in one or more devices different from that embodiment. Modules, units, or components in the embodiments can be combined into a single module, unit, or component, and further, they can be divided into multiple sub-modules, sub-units, or sub-components. Except where at least some of such features and / or processes or units are mutually exclusive, any combination can be used to combine all features disclosed in this specification (including the accompanying claims, abstract, and drawings) and all processes or units of any method or device so disclosed. Unless expressly stated otherwise, each feature disclosed in this specification (including the accompanying claims, abstract, and drawings) may be replaced by an alternative feature serving the same, equivalent, or similar purpose.

[0161] The various component embodiments of the present invention can be implemented in hardware, or as software modules running on one or more processors, or a combination thereof. Those skilled in the art will understand that microprocessors or digital signal processors (DSPs) can be used in practice to implement some or all of the functions of some or all of the components in the sorting device according to the present invention. The present invention can also be implemented as a device or apparatus program for performing part or all of the methods described herein. Such a program implementing the present invention can be stored on a computer-readable medium, or can be in the form of one or more signals. Such signals can be downloaded from an Internet website, provided on a carrier signal, or provided in any other form.

[0162] It should be noted that the above embodiments are illustrative of the invention and not restrictive, and that those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The invention can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names.

[0163] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0164] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

[0165] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

[0166] It should be noted that the various data-related processes in the embodiments of this application are carried out in compliance with the relevant data protection laws and policies of the country where the location is located, and with the authorization granted by the owner of the corresponding device.

Claims

1. A routing table update method, characterized in that, The method includes: Obtain several virtual routing forwarding tenants, each carrying an Internet Protocol (IP) address; obtain the network segment of the IP address; divide the several virtual routing forwarding tenants according to the network segment of the IP address to obtain several partitioned regions for each virtual routing forwarding tenant; generate a virtual routing forwarding array according to the several partitioned regions, each virtual routing forwarding array carrying an IP address; Retrieve the longest prefix matching route table; Set the content of each entry in the longest prefix matching routing table to a null pointer. The target entry in the longest prefix matching routing table corresponding to the virtual route forwarding array is determined using the Internet Protocol address. Adjust the null pointer in the target entry to a pointer to the virtual route forwarding array.

2. The method according to claim 1, characterized in that, The step of generating a virtual route forwarding array based on several divided regions includes: For any of the aforementioned partitioned regions, obtain the number of virtual routing forwarding tenants contained in the partitioned region, the numerical identifier carried by the virtual routing forwarding tenants, and the next-hop routing information; Based on the number of virtual route forwarding tenants contained in the partitioned region, obtain the length of the virtual route forwarding array corresponding to the partitioned region; Based on the next-hop routing information carried by the virtual route forwarding tenant, determine the elements in the virtual route forwarding array; The position of each element in the virtual route forwarding array is determined based on the numerical identifier carried by the virtual route forwarding tenant.

3. The method according to claim 2, characterized in that, After obtaining the number of virtual routing forwarding tenants included in any of the partitioned regions, the numerical identifier carried by the virtual routing forwarding tenants, and the next-hop routing information, the method further includes: If the number of virtual route forwarding tenants in the partitioned area is greater than a preset threshold, then a hash table containing a preset number of entries is set. Obtain the target network segment of the Internet Protocol address carried by the virtual route forwarding tenant in any of the aforementioned partitioned regions; Set the target network segment as the identifier of the hash table; Based on the digital identifier carried by the virtual route forwarding tenant, determine the entry in the hash table corresponding to the next-hop routing information in the virtual route forwarding tenant.

4. The method according to claim 1, characterized in that, Before determining the target entry in the longest prefix matching routing table corresponding to the virtual route forwarding array using the Internet Protocol address, the method further includes: Obtain the first network mask containing a preset number of bits; The index of the longest prefix matching routing table entry is determined based on the first network mask of the preset number of bits.

5. The method according to claim 4, characterized in that, The step of determining the target entry in the longest prefix matching routing table corresponding to the virtual route forwarding array using the Internet Protocol address further includes: Obtain the second network mask of the Internet Protocol address and the actual number of bits in the second network mask; Compare the actual number of digits with the preset number of digits; If the actual number of bits is less than the preset number of bits, then the Internet Protocol address is expanded according to the preset number of bits to obtain the target Internet Protocol address; The target entry of the virtual route forwarding array in the longest prefix matching routing table is determined by the target Internet Protocol address.

6. The method according to claim 2, characterized in that, After adjusting the null pointer in the target entry to a pointer to the virtual route forwarding array, the method further includes: Obtain the Internet Protocol address and numeric identifier of the virtual route forwarding tenant to be queried; The Internet Protocol address of the tenant is forwarded through the virtual route to be queried, and the entry to be queried is determined in the longest prefix matching routing table; The target virtual route forwarding array is determined by the pointer in the query entry; The target location is determined in the target virtual route forwarding array by using the digital identifier of the virtual route forwarding tenant to be queried; Obtain the next-hop routing information of the virtual route forwarding tenant to be queried from the target location.

7. A routing table update device, characterized in that, The device includes: The second acquisition module is used to acquire a plurality of virtual routing forwarding tenants, wherein the virtual routing forwarding tenants carry Internet Protocol addresses; the third acquisition module is used to acquire the network segment of the Internet Protocol address; the fourth acquisition module is used to divide the plurality of virtual routing forwarding tenants according to the network segment of the Internet Protocol address, and acquire a plurality of division regions for the virtual routing forwarding tenants; the generation module is used to generate a virtual routing forwarding array according to the plurality of division regions, wherein the virtual routing forwarding array carries Internet Protocol addresses; The first acquisition module is used to obtain the longest prefix matching routing table; The configuration module is used to set the content of each entry in the longest prefix matching routing table to a null pointer. The first determining module is used to determine the target entry in the longest prefix matching routing table corresponding to the virtual route forwarding array based on the Internet Protocol address. The adjustment module is used to adjust the null pointer in the target entry to a pointer that points to the virtual route forwarding array.

8. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; The memory is used to store computer programs; When the processor executes a program stored in the memory, it implements the routing table update method as described in any one of claims 1-6.

9. A computer-readable storage medium having instructions stored thereon that, when executed by one or more processors, cause the processors to perform the routing table update method as described in any one of claims 1-6.

Images