CN113364692B

CN113364692B - Route memory optimization method and route memory optimization device in biplane mode

Info

Publication number: CN113364692B
Application number: CN202110612711.4A
Authority: CN
Inventors: 何运波; 杨晨; 王翔; 马跃东; 张羽; 蔡玮
Original assignee: Nanjing Third Generation Communication Technology Co ltd; Fiberhome Telecommunication Technologies Co Ltd
Current assignee: Nanjing Third Generation Communication Technology Co ltd; Fiberhome Telecommunication Technologies Co Ltd
Priority date: 2021-06-02
Filing date: 2021-06-02
Publication date: 2022-04-26
Anticipated expiration: 2041-06-02
Also published as: CN113364692A

Abstract

The invention discloses a routing memory optimization method and a routing memory optimization device in a biplane mode. The method comprises the steps of constructing an RD routing table with a routing discriminator as a key word, wherein the RD routing table comprises a plurality of routing sub-tables, and each routing sub-table is used for storing routing entries of different types; and acquiring a current route, and storing the current route into a corresponding route sub-table after setting a local generation marking bit for the current route if the current route is the route generated by a local VRF instance. After the multi-dimensional sharing mechanism of the BGP routing table entry is realized, the duplication of the routing table entry is reduced, the memory consumption of the routing table can be reduced, the routing processing performance of the node can be improved, and the routing transceiving processing performance of a BGP protocol is higher.

Description

Route memory optimization method and route memory optimization device in biplane mode

Technical Field

The present invention belongs to the field of communications technologies, and in particular, to a routing memory optimization method and a routing memory optimization device in a biplane mode.

Background

With the mature application of the latest SR (Segment Routing) technology and the large-scale application of the IPv6(Internet Protocol Version 6) network thereof, the forwarding plane has evolved gradually from the traditional MPLS (Multi-Protocol Label Switching) technology to the SR technology and its SRV6 technology. BGP (Border Gateway Protocol) is used as the only dynamic routing Protocol used between autonomous systems in modern networks, and uses a simple, flexible, and efficient design concept as a basic principle to construct an ultra-large-scale complex network connection. The BGP protocol of today has an IPv4/IPv6 address family for carrying public Network services, a traditional VPNV4/VPNV6 address family for supporting VPN (Virtual Private Network) services, and an EVPN address family for supporting layer 2 and layer 3VPN services. The types of service types supported by the BGP protocol are more and more, the underlying forwarding planes of different service types may be MPLS, SR and its SRV6, etc., the network construction process of an operator is gradually evolved along with the development of the technology, the conventional MPLS forwarding plane still needs to be in existence for a while, and the new SR and its SRV6 forwarding plane are used to carry new service types.

The Chinese telecom follows the development trend of network technology, and provides a model of a double forwarding plane, namely, the existing MPLS VPN service is supported by the traditional BGP VPN address family in the existing network, MPLS is used for forwarding, and simultaneously SRV6 attributes are carried by the BGP EVPN address family in the new equipment, are used for supporting the new VPN service type, and are forwarded by SRV 6. This requires BGP to send the routing Prefix (Prefix) introduced by the local private network access side to other BGP neighbors on the public network side simultaneously through the VPN address family or EVPN address family at the source end of the route, as shown in fig. 1. From the source end of the route, that is, from the sending end of the BGP route, as shown in fig. 1, the conventional table entry is that, an IPv4 or IPv6 route accessed by the private network side first forms a Virtual Routing Forwarding (VRF, abbreviated as VRF) Routing table using VRF _ ID or VRF _ NAME as a Key, and if the route needs to be sent to the remote end through the VPNV4/VPNV6 address family of the public network neighbor, the route needs to be copied from the VRF Routing table to the VPN Routing table using RD as a Key, and then NLRI is encapsulated in a format using RD + Prefix as a Key and sent to the remote end; if the IPv4 or IPv6 route accessed by the private network side is further sent to the remote end in the form of an EVPN, the route in the VRF routing table needs to be copied to an EVPN routing table using RD as a key, the EVPN is a multi-service bearer address family, which supports both layer 2 MAC and layer 3 routing, and subsequently supports multicast routing, and the entry format of the EVPN address family is completely different from that of VPN, so that the EVPN routing table needs to be independently constructed, so that at the source end of the biplane model, one route will be finally copied into 2 routes, which actually represents 3 routes, and memory consumption is huge.

As shown in fig. 2 and 3, after receiving a routing table of a VPN address family or an EVPN address family from a remote end, a receiving end of a BGP Route may store the routing table in the form of RD + Prefix in a VPN routing table of the VPN address family or an EVPN routing table of the EVPN address family, respectively, then according to a matching relationship between an import RT (Route Target) of a local VRF routing table and an export RT in the VPN routing table (or the EVPN routing table), import a Route in the VPN routing table or the EVPN routing table into a small table of VRF satisfying conditions to form a VRF routing table, and finally write the VRF routing table into a final forwarding table after selecting an optimum Route in a private network routing table, where in fig. 2 and 3, the left side represents a large table Route (import VPN routing table or EVPN routing table) with an RD key, the right side represents a small table Route with a VRF as a key, and the large table Route is determined according to how the import Route RT in the VRF routing table and the small table Route configuration, so according to the present implementation, the large table route and the small table route are two-fold.

Under the scenario of the above-mentioned dual forwarding plane model, 2N large table routes are formed after the source end N private network side routing tables reach the destination end, respectively correspond to the EVPN address family and the VPN address family, which respectively form 2N routes after being imported into the VRF small table, and finally the N source end routes become 4N routes after reaching the destination end, which results in huge memory consumption on the control surface of the router product.

Disclosure of Invention

In view of the above defects or improvement requirements of the prior art, the present invention provides a routing memory optimization method and a routing memory optimization device in a bi-plane mode, which aims to reduce duplication of routing table entries and reduce memory consumption of a routing table, thereby solving the technical problem of excessive memory consumption caused by expansion of the routing table.

In a first aspect, the present invention provides a method for optimizing a routing memory in a biplane mode, where the method for optimizing the routing memory includes:

constructing an RD routing table with a routing distinguisher as a key word, wherein the RD routing table comprises a plurality of routing sub-tables, and each routing sub-table is used for storing routing entries of different types;

acquiring a current route, and storing the current route into a corresponding route sub-table after setting a local generation marking bit for the current route if the current route is the route generated by a local VRF instance;

and if the current route is the route learned from the far end, generating a marking bit or a sharing marking bit for the current route according to the consistency condition of the export RT of the current route and the import RT of the local VRF side and the consistency condition of the RD carried by the current route and the RD of the local VRF side.

Preferably, the generating a flag bit or a shared flag bit for the current route according to the consistency between the derived RT of the current route and the imported RT of the local VRF side and the consistency between the RD carried by the current route and the RD of the local VRF side includes:

judging whether the export RT of the current route is consistent with the import RT of the local VRF side or not;

and if the RD carried by the current route is consistent with the RD of the local VRF side, the current route meets the sharing condition, and after a remote generation marking bit and a sharing marking bit are set for the current route, the current route is stored into a corresponding route sub-table.

Preferably, after determining whether the RD carried by the current route is consistent with the RD on the local VRF side, the method further includes:

and if the RD carried by the current route is not consistent with the RD at the local VRF side, the current route does not meet the sharing condition, the current route is copied, and the current route is stored into a corresponding route sub-table after an import mark bit is set for the current route.

Preferably, the shared flag bit includes a VRF shared flag bit, a VPLS shared flag bit, and a VPWS shared flag bit, and for the L3VPN service, the VRF shared flag bit is set for the current route; for VPLS service, setting a VPLS shared flag bit for the current route; for VPWS traffic, a VPWS shared flag bit is set for the current route.

Preferably, for the L3VPN service, the import flag bit includes an import flag bit of a remote VPN route and an import flag bit of a remote EVPN route; for L2VPN traffic, the import flag bits include VPLS import flag bits and VPWS import flag bits.

Preferably, the remote generation flag bit includes a VPN remote generation flag bit and an EVPN remote generation flag bit, and the VPN remote generation flag bit is set for a route learned through a VPN address family and the EVPN remote generation flag bit is set for a route learned through an EVPN address family.

Preferably, the IPv4/IPv6 routes generated by the local VRF instance are stored in an IPv4/IPv6 routing sub-table in the RD routing table, the routes of TYPE1 to TYPE4 generated by the local EVPN instance are stored in an EVPN L2 routing sub-table in the RD routing table, the routes of TYPE1 to TYPE4 advertised by the remote EVPN address family are stored in an EVPN L2 routing sub-table in the RD routing table, the routes of TYPE5 advertised by the remote EVPN address family are stored in an IPv4/IPv6 routing sub-table in the RD routing table according to the specific format of IPv4/IPv6 of the routing prefix, and the routes of VPN of the remote EVPN address family advertised are stored in an IPv4/IPv6 routing sub-table in the RD routing table according to the specific format of IPv4/IPv6 of the specific prefix.

Preferably, if the current route is the route sent by the VPN address family, the RD and route prefix information in the NLRI are taken out, and the route is stored in the RD route table;

if the current route is the TYPE5 route sent by the EVPN address family, RD and IPv4/IPv6 route prefixes in the current route are taken out, and the route is stored in an RD route table.

Preferably, the routing sub-tables include an IPv4 unicast routing sub-table, an IPv6 unicast routing sub-table, an IPv4 multicast routing sub-table, an IPv6 multicast routing sub-table, and an EVPN L2 routing sub-table.

In a second aspect, the present invention provides a routing memory optimization apparatus, including at least one processor; and a memory communicatively coupled to the at least one processor; wherein the memory stores instructions executable by the at least one processor and programmed to perform the method of routing memory optimization according to the first aspect.

Generally, compared with the prior art, the technical scheme of the invention has the following beneficial effects:

after the multi-dimensional sharing mechanism of the BGP routing table entry is realized, the duplication of the routing table entry is reduced, the memory consumption of the routing table can be reduced, the routing processing performance of the node can be improved, and the routing transceiving processing performance of the BGP protocol is higher.

Drawings

Fig. 1 is a schematic diagram of a route storage manner of a transmitting end under a dual transmitting plane in the prior art;

fig. 2 is a schematic diagram of a route storage manner (VPN address family) of a receiving end under a dual forwarding plane in the prior art;

fig. 3 is a schematic diagram of a route storage manner (EVPN address family) of a receiving end under a dual forwarding plane in the prior art;

fig. 4 is a schematic flowchart of a method for optimizing a routing memory in a biplane mode according to an embodiment of the present invention;

fig. 5 is a schematic structural diagram of an RD routing table according to an embodiment of the present invention;

fig. 6 illustrates a route storage manner of an L3VPN service according to an embodiment of the present invention;

fig. 7 illustrates a route storage manner of an L2VPN service according to an embodiment of the present invention;

fig. 8 is a schematic diagram of a route storage manner of a transmitting end under a dual transmitting plane according to an embodiment of the present invention;

fig. 9 is a schematic diagram of a route storage manner of a receiving end under a dual forwarding plane according to an embodiment of the present invention;

FIG. 10 is a schematic diagram of a networking mode provided by an embodiment of the invention;

fig. 11 is a service flow diagram of a routing process provided by an embodiment of the present invention;

fig. 12 is a schematic structural diagram of a routing memory optimization device according to an embodiment of the present invention.

Detailed Description

In order to make the objects, technical solutions and advantages of the present invention more apparent, the present invention is described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention. In addition, the technical features involved in the embodiments of the present invention described below may be combined with each other as long as they do not conflict with each other.

Example 1:

referring to fig. 4, in order to solve the problem of excessive memory consumption caused by the expansion of the routing table, the present embodiment provides a routing memory optimization method in the bi-plane mode, where the routing memory optimization method includes the following steps:

step 101: and constructing an RD routing table with a routing distinguisher as a key, wherein the RD routing table comprises a plurality of routing sub-tables, and each routing sub-table is used for storing routing entries of different types.

In this embodiment, an RD routing table as shown in fig. 5 is constructed, the RD routing table performs Hash storage with RD value as Key, and each RD routing table has a plurality of routing sub-tables, where the routing sub-tables include an IPv4 unicast routing sub-table, an IPv6 unicast routing sub-table, an IPv4 multicast routing sub-table, an IPv6 multicast routing sub-table, and an EVPN L2 routing sub-table (actually stored are layer 2 routing information of types 1 to 4, and Type5 routing is stored in the IPv4/IPv6 unicast routing sub-table according to a specific format).

Wherein routes are stored into corresponding routing sub-tables according to TYPEs of routing entries, specifically, IPv4/IPv6 routes generated by the local VRF instance are stored in IPv4/IPv6 routing sub-tables in the RD routing table, routes of TYPE1 to TYPE4 generated by the local EVPN instance are stored in EVPN L2 routing sub-tables in the RD routing table, routes of TYPE1 to TYPE4 advertised by the remote EVPN address family are stored in EVPN L2 routing sub-tables in the RD routing table, routes of TYPE5 advertised by the remote EVPN address family are stored in IPv4/IPv6 routing sub-tables in the RD routing table according to specific formats of IPv4/IPv6 of routing prefixes, routes advertised by the remote VPN address family are stored in IPv4/IPv6 routing sub-tables in the RD routing table according to specific formats of IPv4/IPv 6.

Step 102: and acquiring a current route, and storing the current route into a corresponding route sub-table after setting a local generation marking bit for the current route if the current route is the route generated by a local VRF instance.

Step 103: and if the current route is the route learned from the far end, generating a marking bit or a sharing marking bit for the current route according to the consistency condition of the export RT of the current route and the import RT of the local VRF side and the consistency condition of the RD carried by the current route and the RD of the local VRF side. The source end is a sending end of the route, that is, the source end of the route, and the local end is a receiving end of the route.

In this embodiment, if the current route is a route learned by a remote end, it is determined whether an export RT of the current route is consistent with an import RT of a local VRF side; if the export RT of the current route is consistent with the import RT of the local VRF side, further judging whether the RD carried by the current route is consistent with the RD of the local VRF side, if the RD carried by the current route is consistent with the RD of the local VRF side, the current route meets the sharing condition, and storing the current route into a corresponding route sub-table after setting a remote generation marking bit and a sharing marking bit for the current route. And if the RD carried by the current route is not consistent with the RD at the local VRF side, the current route does not meet the sharing condition, the current route is copied, and the current route is stored into a corresponding route sub-table after an import mark bit is set for the current route.

The shared mark bit comprises a VRF shared mark bit, a VPLS shared mark bit and a VPWS shared mark bit, and the VRF shared mark bit is set for the current route for the L3VPN service; the L2VPN Service includes a VPWS (Virtual Private Wire Service, abbreviated as VPWS) Service and a VPLS (Virtual Private LAN Service, abbreviated as VPLS) Service, and sets a VPLS sharing flag bit for the current route for the VPLS Service; for VPWS traffic, a VPWS shared flag bit is set for the current route.

The remote generation mark bit comprises a VPN remote generation mark bit and an EVPN remote generation mark bit, the VPN remote generation mark bit is set for the route learned by the VPN address family, and the EVPN remote generation mark bit is set for the route learned by the EVPN address family.

In an actual application scenario, for the L3VPN service, the import flag bit includes an import flag bit of a remote VPN route and an import flag bit of a remote EVPN route; for L2VPN traffic, the import flag bits include VPLS import flag bits and VPWS import flag bits.

With reference to fig. 6 and 7, fig. 6 shows a setting manner of a flag bit of a route of L3VPN service, where VRF (o) locally generates a flag bit, VPN (r) remotely generates a flag bit, EVPN (r) remotely generates a flag bit, VRF (o) indicates that the route is a local VRF-side access route, VPN (r) indicates that the route is a remote VPN route, EVPN (r) indicates that the route is a remote EVPN route, and VRF(s) is a shared flag bit, indicating that the route is a shared route; VRF (D/V), VRF (D/E) and VRF (D/O) are import flag bits, VRF (D/V) represents an import route of the route as a far-end VPN route, VRF (D/E) represents an import route of the route as a far-end EVPN route, and VRF (D/O) represents an import route of the route as a local VRF side access route.

Fig. 7 shows the setting of the flag bits for the routes of L2VPN traffic, where vpws (o) and vpls (o) generate flag bits locally, EVPN (r) generates flag bits for the far end, vpws (o) and vpls (o) generate source routes locally accessed to EVPN, EVPN (r) indicates that the routes are far end EVPN routes, and vpws(s) and vpls(s) are shared flag bits indicating that the routes are shared routes; VPWS (D) and VPLS (D) are import flags, which indicate that the route is an import route of the EVPN route.

In this embodiment, in fig. 6, the VPN flag indicates that the route originates from the VPN address family of the remote PE, the EVPN flag indicates that the route originates from the EVPN address family of the remote PE, and the VRF sharing flag indicates that the far end RD is the same as the RD of the local VRF, and the export RT of the route is the same as the import RT of the local VRF, indicating that size table route sharing is implemented. In fig. 7, EVPN marks that the route originates from the source EVPN address family and belongs to L2VPN service, and the VPLS/VPWS sharing mark bit indicates that the RD at the far end is the same as the RD of the VPLS at the home end and its VPWS instance, thereby implementing size table route sharing.

In an actual application scenario, for an L3VPN service route, if the current route is a route generated by a local VRF instance, a local generation flag bit VPN (R) is set for the current route, and then the current route is stored into a corresponding route sub-table; for the L2VPN service route, if the current route is the route generated by the local VRF instance, the current route is stored into the corresponding route sub-table after the local generation flag bit VPWS (O) or VPLS (O) is set for the current route according to the service type. The L2VPN does not actually have biplanes, only three layers of routing tables have biplanes, but the memory optimization of the scheme is not only aiming at the biplanes, but under the biplane scene, the memory problem is amplified, and the memory consumption needs to be reduced urgently. A single L2VPN scenario may also halve the routing table entries at both the sender and receiver.

In this embodiment, the BGP routing table entry employs a multidimensional sharing mechanism, including large table route sharing of the EVPN address family and the VPN address family, and large table route sharing and VRF small table route sharing. The method comprises the steps of keeping the scale of a routing table of a destination end consistent with that of a sending end as much as possible through multiple view presentation modes of a single route, realizing through two-stage mapping, wherein the first stage is mapped into the routing table, the mapping relation between VRF names and RD is established according to configuration, the second stage is mapped into a specific routing entry level, and the source route and the import route are established according to the matching results of export RT and import RT.

In the non-biplane mode, before the implementation of the embodiment of the present invention, the source end has N routes, the actual storage is 2N, and after the routes are sent to the destination end, one of the N routes is corresponding to a general IPv4 address family, the other route is corresponding to a VPN or EVPN address family, and the source end and the destination end are symmetric. After the embodiment of the invention is implemented, the source end and the destination end are stored in N pieces.

In the biplane mode, before the implementation of the embodiment of the present invention, the source end N routes, the actual storage is 3N, and after sending to the destination end (2N is sent), the destination end is 4N, where 2N is an address family corresponding to the EPVN and the VPN sent by the source end, and 2N is an address family corresponding to the private network IPv 4. After the implementation of the embodiment of the invention, the source end still has N pieces of storage, and the destination end still has 2N pieces of storage.

In this embodiment, the RD routing table and the local VRF are correlated to establish a mapping relationship between the local VRF and the remote RD routing table, where the RD routing table is generated on one hand from the routes of the VPN learned by the remote and its EVPN address family, and on the other hand, from the local VRF configuring the RD. The public network route is stored in the RD routing table in a special form that RD is 0, and any service can be stored in the RD routing table and the routing sub-table thereof.

The sharing mechanism will be described from the source end of the route and the sink end of the route, respectively. At the source end of the route, firstly, discarding the VRF routing table with VRF _ ID or VRF _ NAME as key word, only reserving the RD routing table with RD as key word, and realizing the sharing of large table route and small table route, wherein, the VRF routing table is the small table route, and the RD routing table is the large table route. In an actual application scenario, the RD configured by the VRF for the IPv4 or IPv6 route accessed by the private network side is stored in a corresponding RD routing table. If no VPN address family or EVPN address family exists on the public network side, the route in the RD routing table is still forwarded to a BGP neighbor on the VRF side, and the meaning of the RD is ignored; if the routing needs to be sent to the VPN or EVPN address family, the VPN and NLRI message in EVPN format are constructed directly according to the RD to which the route belongs and the prefix of the route itself, and sent, as shown in fig. 8. In this embodiment, the address family to which the stored routing table entry belongs and the address family to which the route is sent to the neighbor are independent of each other, and the static characteristics stored in the routing table and the dynamic characteristics of the route sending are combined, so that the memory consumption of the routing table is reduced, and the completeness of the function is maintained. Another understanding is that one copy of data is stored, but multiple copies are sent in different formats, and before the embodiment of the present invention is implemented, the original data is converted into different formats to be stored and then sent. The scheme of the embodiment of the invention actually reduces the consumption of the memory by improving the complexity of the algorithm.

At the route receiving end, the route sent by the VPN address family keeps the existing processing mode unchanged, the RD and the route Prefix (RD + Prefix information) in the NLRI are taken out, and the route is stored in the RD route table. If the route sent by the EVPN address family is the TYPE5 route, ignoring other data formats specific to the EVPN address family, taking out RD + IPv4/IPv6 Prefix in the route, and storing the route in an RD routing table. After the processing, no matter the VPN address family or the EVPN address family, the route is unified and enters the RD routing table after receiving the local address. In this embodiment, since the VRF routing table with the VRF _ ID or VRF _ NAME as the key is discarded, the lead-in routes of the VPN and its EPVN route are led to the VRF routing table in the RD routing table, and are led to other RD routing tables in a certain RD routing table, as shown in fig. 9.

In an actual application scenario, the RT of a route is divided into an import RT and an export RT, when the route accessed by the VRF side is sent to a remote end through a VPN or EVPN address family, the export RT is carried out as an attribute of the route, when the remote end receives the route, the export RT is matched with the import RT of the VRF configured at the remote end, and the matched route can form the import route, that is, the import condition of the RT is satisfied.

The following describes a method for sending a route to a neighbor based on the storage method of the route: (1) the IPv4/IPv6 route generated by the local VRF instance is marked with a locally generated flag bit VRF (o), and as shown in (1) of fig. 6, after being stored in the RD routing table, the route is firstly sent to other BGP neighbors of the local VRF through an IPv4/IPv6 unicast address family, and then sent to the BGP neighbors on the public network side through the VPN/EVPN address family carrying the RD according to the configuration information.

(2) After the VPN route advertised by the Remote VPN address family is stored in the IPv4/IPv6 route sub-table in the RD route table, the Remote generation flag bit VPN (r) is marked to indicate that the route originates from the VPN service of the Remote (Remote), and when the route meets the sharing condition (the sharing condition is that the RD carried by the route sent by the Remote is the same as the RD value in the local private network route table), the sharing flag bit vrf(s) is set for the route, as shown in (2) of fig. 6. After the remote route and the local route are jointly optimized, the optimal route is sent to the remote end through a VPN address family, and due to the existence of a size table sharing mechanism, the remote route, the local route and a lead-in route thereof need to be correctly distinguished according to a mark bit. If the VPN-to-EVPN situation exists, the optimal route is required to be transmitted to the remote end through an EVPN address family.

(3) After the Type5 advertised by the Remote EVPN address family routes the IPv4/IPv6 routing sub-table stored in the RD routing table, a Remote routing flag bit EVPN (r) is marked to indicate that the route originates from EVPN traffic of a Remote (Remote), and when the route meets the sharing condition, a sharing flag bit vrf(s) is set for the route, as shown in (3) of fig. 6. After the remote route and the local route are jointly preferred, the optimal route is sent to the remote end through an EVPN address family, and due to the existence of a large table and small table sharing mechanism, the remote route, the local route and the import route thereof need to be correctly distinguished according to the mark bit. If the situation of EVPN to VPN exists, the optimal route is required to be sent to the far end through a VPN address family.

(4) TYPE1 to TYPE4 routes generated by local EVPN instance, are marked with local generation flag bits VPLS (o)/VPWS (o) (where VPLS and VPWS belong to two traffic TYPEs of EVPN L2VPN address family), and after being stored in RD routing table, as shown in (1) of fig. 7. Because the routing information of the layer 2 does not relate to BGP neighbors at the EVPN instance side, the routing information is directly sent to BGP neighbors at the public network side through the RD carried by the EVPN address family according to the configuration information.

(5) The TYPE1 to TYPE4 routes advertised by the remote EVPN address family are stored in the EVPN L2 routing sub-table in the RD routing table, and the remote routing flag bit EVPN (r) is set, as shown in (2) (3) of fig. 7. And after the remote route and the local route are jointly preferred, the optimal route is sent to the remote end through the EVPN address family.

The following describes the processing method of route import specifically: (1) the route of IPv4/IPv6 generated by the local VRF instance is marked with a locally generated flag bit VRF (O), and after storing in the corresponding routing sub-table in the RD routing table, the local obtains a VRF import relation chain according to the RT information, and then performs the import processing of the route according to the association relation between the VRF and the RD routing table, if the imported RD is the same as the RD of the current RD routing table, the imported RD is directly ignored, and if the imported RD is not the same as the RD of the current source route, the route table entry is copied, and the copied route is marked with an import flag bit VRF (D/O), as shown in (5) of fig. 6.

(2) After entering a routing sub-table corresponding to the RD routing table, the VPN route advertised by the remote VPN address family acquires a VRF import relation chain according to the RT information, and then performs route import processing according to the association relation between the VRF and the RD routing table, if the imported RD is the same as the current source route RD, the routing table entry is not copied, and only the source route is marked with a large table and a small table sharing flag bit VRF(s), as shown in (2) of fig. 6. If the RD of the import is different from the RD of the current source route, the route table entry is copied, and the import flag bit is marked on the copied route, as shown in (4) of fig. 6.

(3) After entering a routing sub-table corresponding to the RD routing table, the Type5 route advertised by the remote EVPN address family acquires the VRF import relation chain according to the RT information, and then performs the import processing of the route according to the association relation between the VRF and the RD routing table, if the imported RD is the same as the current source route RD, the route table entry is not copied, and only the source route is marked with the large and small table sharing flag bits, as shown in (3) of fig. 6. If the RD of the import is different from the RD of the current source route, the route table entry is copied, and the import flag bit is marked on the copied route, as shown in (4) of fig. 6, and the VRF (D/V) flag bit is marked on the copied route.

(4) After entering a routing sub-table corresponding to an RD routing table, a Type1 to Type4 route advertised by a remote EVPN address family acquires a VRF import relationship chain of an EVPN instance according to RT information, and then performs import processing of the route according to an association relationship between the VRF and the RD routing table, and if the imported RD is the same as the current source route RD, the route table entry is not copied, and only the source route is marked with a size table sharing flag bit, as shown in (2) (3) of fig. 7. If the RD of the import is different from the RD of the current source route, the route table entry is copied, and the copied route is marked with an import flag bit, as shown in (4) of fig. 7.

The following describes in detail a processing method for local delivery of a remote router: (1) and marking a locally generated marking bit on the IPv4/IPv6 route generated by the local VRF example, storing the locally generated marking bit into an IPv4/IPv6 route sub-table corresponding to the RD route table, then carrying out preference on the route with the introduced marking bit and the size table combined sharing the marking bit, and selecting the optimal route to send to a local forwarding table.

(2) And if the VPN route announced by the remote VPN address family is imported into the RD, the sharing of the large and small tables is realized, and a sharing mark bit D is marked, and if other RD route tables are imported, the default import flow is followed, the route is copied to other RD route tables, and the import mark bit is marked. Similar to the IPv4/IPv6 route generated by the local VRF instance, the common flag bit and the BGP route accessed by the local VRF remote end are preferred to select the optimal route and send it to the local forwarding table.

(3) And (3) if the Type5 route advertised by the remote EVPN address family is imported into the RD, the sharing of the size table is realized, the sharing mark bit D is marked, if other RD routing tables are imported, the default import flow is followed, the route is copied into other RD routing tables, and the import mark bit is marked, which is similar to the processing of the above (1) and (2), and the description is not repeated here. It should be noted that the import of the VPN and its EVPN TYPE5 route requires a correct distinction between the source of the imported route, EVPN or VPN.

(4) And if the route from Type1 to Type4 announced by the remote EVPN address family is imported into the RD, the sharing of the size table is realized, a sharing mark bit D is marked, and if other RD routing tables are imported, a default import flow is followed, the route is copied to other RD routing tables, and an import mark bit E is marked. Because the L2 table entry of the EVPN does not relate to the route learned by the neighbor of the local EVPN instance, the whole process is relatively simple, and only the fact whether the route is imported or not and the route shared by the size table need to be concerned, wherein the route shared by the size table is a special form of the imported route.

In this embodiment, if the source RD and the local RD of the local VRF are configured the same and satisfy the import relationship of the RT, then size table sharing in the route receiving direction is achieved. If the configuration of the local RD of the source end RD and the local VRF is different and the import relationship of the RT is satisfied, a new table entry still needs to be generated at the time of import because the size table sharing cannot be realized at this time. After the multi-dimensional sharing mechanism of the BGP routing table entry is realized, the duplication of the routing table entry is reduced, the memory consumption of the routing table can be reduced, the routing processing performance of the node can be improved, and the routing transceiving processing performance of the BGP protocol is higher.

Example 2:

with reference to a specific networking scenario, as shown in fig. 10, CE1 has dual access to PE1 and PE2 nodes, the private network side VRF name is VRF1, RD is 1:1, and both import RT and export RT are 1: 1. CE4 has single access to PE2, and belongs to VRF1 with CE 1. CE2 single access PE3, private network side VRF name is VRF2, RD is 2:2, import RT and export RT are both 1: 1. CE3 single-homed accesses PE3 node, the VRF name at the private network side is VRF1, RD is 1:1, and import RT and export RT are both 1: 1. The public network side PE1, PE2 and PE3 establish BGP neighbors pairwise. BGP neighbors were also established for PE1 and CE1, PE2 and CE1, PE2 and CE4, PE3 and CE2, and PE3 and CE3, respectively. The implementation process of the routing memory optimization method is described by taking an L3VPN service as an example.

(1) The route of IPv4/IPv6 generated by the PE1 in the local VRF1 instance is marked with a locally generated flag bit VRF (o), and as shown in (1) of fig. 6, after being stored in the RD (1:1) routing table, the route is first sent to the local VRF1 side neighbor CE1 with an IPv4/IPv6 unicast address family, and then sent to the public network side BGP neighbor PE3 through the VPN/EVPN address family carrying RD according to the configuration information.

(2) PE1 receives a BGP private network route (11.1.1.1/32) from CE1, loads a locally generated flag bit vrf (o), and stores the route in the RD (1:1) routing table as shown in fig. 6 (1), where the route originates from a remote neighbor and needs to be issued a local forwarding table. And sending the configuration information to BGP neighbor PE3 on the public network side through RD carried by the VPN/EVPN address family, wherein in the process, one routing table does not need to be copied, and the routing is directly sent by a single route in different address families.

(3) Since CE1 is dually homed to PE1 and PE2, PE2 may learn a small table route on the private network side of CE1 directly through VRF1 (Prefix is 11.1.1.1/32) or may learn a large table route on the public network side carrying RD through PE1 (the route is from CE1- > PE1- > PE2, RD is 1:1Prefix is 11.1.1.1/32), PE2 represents the route learned from PE1 as Prefix-Path2, and the route needs to set flag bit VPN (r) to indicate that the route is from the far-end PE and belongs to the source of the VPN address family. The RD (1:1) carried by the route has the same configuration as the RD of the local VRF1, and the export RT (1:1) carried by the route has the same configuration as the import RT (1:1) of the local VRF1, so that the condition of size table sharing is satisfied, and therefore, the route also sets a flag bit VRF(s), as shown in (2) of fig. 6. PE2 represents the route learned directly from CE1 as Prefix-Path1, which sets the flag bit vrf (o). The Prefix-Path1 and Prefix-Path2 both originate from remote end, both satisfy the condition of local underground forwarding, need to be preferentially issued according to configuration, and preferentially issue the Prefix-Path1 originated from CE1 in default. The Prefix-Path1 and Prefix-Path2 need to announce to CE1 preferentially at the same time, the optimal route is Prefix-Path1 of CE1 by default, and the route is not announced to CE1 according to the horizontal segmentation principle. Prefix-Path1 and Prefix-Path2 need to announce preferentially to PE3 and, by default, Prefix-Path 1.

(4) The processing logic of PE2 is similar to that described above in (3), except that the VRF side of PE2 has CE4 in addition to CE 1. PE2 represents the learned route from CE1 as Prefix-Path1 and from PE1 as Prefix-Path2, with one of the two routes needing to be advertised to CE4 and Prefix-Path1 advertised by default.

(5) PE3 can learn routes to the same Prefix from PE1 and PE2, respectively, due to the interfacing of two public network-side BGP neighbors PE1 and PE2, denoted as Prefix-Path1 and Prefix-Path2, respectively. The same RT (1:1) carried by the two routes is consistent with the RT configured by the local VRF1, the import condition is satisfied, and the RD (1:1) carried by the two routes is completely consistent with the RD (1:1) of the local VRF1, the sharing condition is satisfied, and both the Prefix-Path1 and the Prefix-Path2 are shown in (2) of fig. 6. After the Prefix-Path1 and the Prefix-Path2 are imported into the small table of the VRF1 in a shared manner, the small table needs to be issued locally, and also needs to be notified to the neighbor CE3 on the VRF1 side, and a specific preferred notification flow is similar to the aforementioned flow. For VRF2, the export RT of the route matches the import RT on VRF2 side, however, RD carried by the route does not match RD on VRF2 side, only the import condition is satisfied, and the route sharing condition is not satisfied, so it is necessary to copy a route (Prefix-Path 1-duplicate, Prefix-Path 2-duplicate) to RD (2:2) table of VRF2 for Prefix-Path1 and Prefix-Path2, respectively, where the route is represented by (4) in fig. 6, and a VRF (D/V) flag bit is marked to indicate that the route belongs to the import route and belongs to VPN service import. Meanwhile, the Prefix-Path1-Duplication and the Prefix-Path2-Duplication need to issue local forwarding and simultaneously need to notify a private network side neighbor CE2 of VRF 2.

(6) Since there are two VRFs on PE3, VRF1 and VRF2, respectively, the local import condition is satisfied according to the routing configuration of VRF1 and VRF 2. A route learned by PE3 from CE3 is denoted as Prefix-Path (Prefix ═ 11.1.1.3/32), and the procedure of advertising the route to public network neighbor PE1 is similar to that of 2) described above. Meanwhile, the Prefix-Path needs to be imported into VRF2 to form an import route, the import route needs to be copied because the source RD is inconsistent with the destination RD, and the import route is represented as Prefix-Path-Duplication. The route flag is set to VRF (D/O), indicating that the route is an imported route and imported for other VRFs locally, as shown in (5) of fig. 6. Meanwhile, the Prefix-Path-duplicate of the route needs to locally issue a forwarding table of VRF2, and needs to advertise to CE 2. Of particular note is that the route can no longer be advertised from VRF2 carrying RD (2:2) to far-end PE1 and its PE 2.

Example 3:

with reference to fig. 10, on the basis of the combination of the size tables of the routing tables, the routing processing performance is comprehensively improved by the adaptive scheduling algorithm, which is mainly embodied in PE1, PE2, and PE3, and CE1, CE2, CE3, and CE4 are respectively used as a source end and a destination end of the route, which is not described much. As shown in fig. 11, which is a service flow diagram of routing processing, for PE1/PE2/PE3 in a networking diagram, a message-in stage, a route local processing stage, and a message-out stage are involved.

For the message entering stage, the stage does not buffer any message, and immediately analyzes the attribute and the route entry in the message after receiving the Update message, and hangs the route in a scheduling queue waiting for processing.

The route local processing stage comprises route preference, local delivery and neighbor advertisement route, wherein the two sub-processes of the route preference and the local delivery are synchronously scheduled, and the route is advertised to the neighbor for preprocessing and asynchronous scheduling. The reason for this is that the local routing has only one destination, and the whole data volume is controllable. The advertising of the route to the neighbor is a plurality of destinations (a plurality of neighbors), the receiving performance of each neighbor may not be consistent, and the preprocessing of the sending route needs to be performed adaptively and dynamically according to the processing performance of the neighbor. For the routing local processing stage, before the size table is unified, the routing local processing stage actually processes the size table and the small table independently, after the size table is unified, the routing local processing stage only processes one routing table, so that the processing time of the stage can be shortened, the routing processing performance is improved, and the PE1 can directly send the routing since the routing of the local small table is not copied into the routing of the large table any more, thereby reducing the processing logic of the sending process. When the PE3 receives the route of the far-end PE1 and PE2, the route is imported into the VRF1 table, the large-table route does not need to be copied into the small-table route due to a size-table-integrated sharing mechanism, the processing time can be shortened, and the route is directly issued to be locally forwarded and sent to the CE3 node.

A message outgoing stage: the message-out stage and the preprocessing subprocess for advertising the route to the neighbor are the relationship between the consumer and the producer, and when the TCP sliding window of the opposite end is increased, the number of routes generated by the preprocessing subprocess for advertising the route can be increased. When the opposite-end TCP sliding window is reduced, the number of routes generated by the preprocessing subprocess of the advertised route is reduced. Thereby associating the ability of the peer to receive routes with the home sending routes.

Example 4:

referring to fig. 12, fig. 12 is a schematic structural diagram of a routing memory optimization device according to an embodiment of the present invention. The routing memory optimization device of the present embodiment includes one or more processors 41 and a memory 42. In fig. 12, one processor 41 is taken as an example.

The processor 41 and the memory 42 may be connected by a bus or other means, and fig. 12 illustrates the connection by a bus as an example.

The memory 42, which is a non-volatile computer-readable storage medium based on a routing memory optimization method, may be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, the methods of the above embodiments, and corresponding program instructions. The processor 41 implements the methods of the foregoing embodiments by executing non-volatile software programs, instructions, and modules stored in the memory 42 to thereby execute various functional applications and data processing.

The memory 42 may include, among other things, high-speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, memory 42 may optionally include memory located remotely from processor 41, which may be connected to processor 41 via a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

It should be noted that, for the information interaction, execution process and other contents between the modules and units in the apparatus and system, the specific contents may refer to the description in the embodiment of the method of the present invention because the same concept is used as the embodiment of the processing method of the present invention, and are not described herein again.

Those of ordinary skill in the art will appreciate that all or part of the steps of the various methods of the embodiments may be implemented by associated hardware as instructed by a program, which may be stored on a computer-readable storage medium, which may include: a Read Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and the like.

It will be understood by those skilled in the art that the foregoing is only a preferred embodiment of the present invention, and is not intended to limit the invention, and that any modification, equivalent replacement, or improvement made within the spirit and principle of the present invention should be included in the scope of the present invention.

Claims

1. A route memory optimization method in a biplane mode is characterized by comprising the following steps:

if the current route is a route learned from a far end, generating a marking bit or a sharing marking bit for the current route according to the consistency situation of the export RT of the current route and the import RT of the local VRF side and the consistency situation of the RD carried by the current route and the RD of the local VRF side, wherein the method comprises the following steps: judging whether the export RT of the current route is consistent with the import RT of the local VRF side or not; and if the RD carried by the current route is consistent with the RD of the local VRF side, the current route meets the sharing condition, and after a remote generation marking bit and a sharing marking bit are set for the current route, the current route is stored into a corresponding route sub-table.

2. The method according to claim 1, wherein after determining whether the RD carried by the current route is consistent with the RD on the local VRF side, the method further comprises:

3. The method according to claim 2, wherein the shared flag bits include a VRF shared flag bit, a VPLS shared flag bit, and a VPWS shared flag bit, and for L3VPN traffic, the VRF shared flag bit is set for a current route; for VPLS service, setting a VPLS shared flag bit for the current route; for VPWS traffic, a VPWS shared flag bit is set for the current route.

4. The method according to claim 2, wherein for L3VPN traffic, the import flag bit includes an import flag bit of a remote VPN route and an import flag bit of a remote EVPN route; for L2VPN traffic, the import flag bits include VPLS import flag bits and VPWS import flag bits.

5. The method according to claim 1, wherein the far-end generation flag bit includes a VPN far-end generation flag bit and an EVPN far-end generation flag bit, and the VPN far-end generation flag bit is set for a route learned by a VPN address family, and the EVPN far-end generation flag bit is set for a route learned by an EVPN address family.

6. The routing memory optimization method according to claim 1, wherein IPv4/IPv6 routes generated by the local VRF instance are stored in an IPv4/IPv6 routing sub-table in the RD routing table, routes from TYPE1 to TYPE4 generated by the local EVPN instance are stored in an EVPN L2 routing sub-table in the RD routing table, routes from TYPE1 to TYPE4 advertised by the remote EVPN address family are stored in an EVPN L2 routing sub-table in the RD routing table, routes from TYPE5 advertised by the remote EVPN address family are stored in an IPv4/IPv6 routing sub-table in the RD routing table according to the specific format of IPv4/IPv6 of the routing prefix, routes from IPv4/IPv6 advertised by the IPv4/IPv6 routing sub-table in the RD routing table according to the specific format of IPv4/IPv6 of the routing prefix.

7. The method according to claim 1, wherein if the current route is a route sent from a VPN address family, the RD and route prefix information in the NLRI are extracted, and the route is stored in an RD route table;

8. The method of claim 1, wherein the routing sub-table comprises an IPv4 unicast routing sub-table, an IPv6 unicast routing sub-table, an IPv4 multicast routing sub-table, an IPv6 multicast routing sub-table, and an EVPN L2 routing sub-table.

9. A routing memory optimization device, comprising at least one processor; and a memory communicatively coupled to the at least one processor; wherein the memory stores instructions executable by the at least one processor and programmed to perform the method of routing memory optimization according to any of claims 1 to 8.