Method and device for generating VPN topology, equipment and storage medium

Abstract

The embodiment of the invention provides a method and device for generating VPN topology, equipment and a storage medium, and relates to the technical field of communication. In the embodiment of the invention, the routing target of each VPN instance is collected through the BGP message so as to generate the VPN topology. In the process of generating the VPN topology, the configuration file of each network device does not need to be analyzed, so that the problem that the configuration file cannot be analyzed does not exist, and the accuracy of the VPN topology can be improved.

Description

Technical Field

[0001] The present disclosure relates to the field of communication technology, and in particular to a method, device, equipment and storage medium for generating a virtual private network (VPN) topology. Background Art

[0002] VPN topology can well present the connection relationship between VPN nodes and is widely used in the network operation and maintenance process. When constructing VPN topology, the related technology obtains the configuration file by manually logging into the corresponding routing device, and generates the VPN topology based on the relevant information in the configuration file. Since the configuration files of routing devices from different manufacturers have different formats, it is impossible to use a unified standard to automatically parse the configuration files to obtain relevant information. This results in the configuration files of some routing devices being unable to be parsed, which in turn leads to inaccurate VPN topology. Summary of the invention

[0003] The present disclosure provides a method, apparatus, device and storage medium for generating VPN topology, which can improve the accuracy of VPN topology acquisition.

[0004] In a first aspect, a method for generating a VPN topology is provided, the method comprising: receiving a plurality of border gateway protocol (BGP) messages, the plurality of BGP messages corresponding to a plurality of network devices, obtaining export route targets (ERT) and import route targets (IRT) of VPN instances of the plurality of network devices based on the plurality of BGP messages, and generating a VPN topology based on the ERT and IRT of the VPN instances of the plurality of network devices. The VPN topology indicates the mutual access relationship of the VPN instances of the plurality of network devices.

[0005] The above operations of receiving BGP messages, obtaining routing targets, generating VPN topology, etc. can be performed by any device, such as a controller, any network device, or any other computer device other than the controller and the network device. There can be several network devices among the multiple network devices, each of which corresponds to multiple BGP messages, and there can also be several network devices, each of which corresponds to one BGP message.

[0006] This solution collects the routing targets of each VPN instance through BGP messages to generate VPN topology. In the process of generating VPN topology, there is no need to parse the configuration files of each network device, so there will be no problem that the configuration files cannot be parsed, which can improve the accuracy of VPN topology acquisition.

[0007] In a possible implementation, each BGP message carries the ERT and IRT of the VPN instance of the corresponding network device.

[0008] In this way, the ERT and IRT can be directly obtained in the BGP message without additional processing, which can save processing resources.

[0009] In one possible implementation, each BGP message is a BGP UPDATE message.

[0010] The BGP UPDATE message carries routing information such as route distinguisher (RD), next hop, routing prefix, ERT, etc. In addition, in addition to using the UPDATE message, other BGP messages such as HELLO messages can also be used.

[0011] In this way, by taking advantage of the flexibility of BGP UPDATE messages and their real-time transmission, the real-time performance of route target announcements can be improved, thereby facilitating the improvement of the real-time performance of VPN topology.

[0012] In a possible implementation, the ERT and IRT are carried in a path attribute field of a BGP UPDATE message.

[0013] Various types of extension fields can be defined in the path attribute field, and a certain type of extension field can be selected to carry ERT and IRT. ERT and IRT can be carried in different types of extension fields respectively, or in the same type of extension field.

[0014] In this way, the routing target is carried in the path attribute field through a certain type of extended field, which has higher flexibility when sending the routing target.

[0015] In a possible implementation manner, the IRT is carried in the first extended community attribute field of the path attribute field.

[0016] The ERT and IRT may be carried in different extended community attribute fields or in the same extended community attribute field.

[0017] In a possible implementation, the BGP UPDATE message also carries first indication information, and the first indication information is used to indicate that the BGP UPDATE message is only used to announce the ERT and IRT carried by the BGP UPDATE message, and to inform each network device that it is not necessary to process the BGP UPDATE message, and it is not necessary to add the route prefix in the BGP UPDATE message to the routing table. Only devices that need to generate a VPN topology need to process the route target in the UPDATE message.

[0018] In this way, in the process of establishing a VPN topology, redundant processing of each network device can be reduced, and the processing resource occupation of each network device can be reduced.

[0019] In a possible implementation manner, the first indication information is carried in a path attribute field of a BGP UPDATE message.

[0020] Various types of extension fields defined in the path attribute field may be used to carry the first indication information, or a new type of extension field may be newly defined to carry the first indication information.

[0021] In this way, the first indication information is carried in the path attribute field through a certain type of extended field, and when the first indication information is carried in the BGPUPDATE message, high flexibility is achieved.

[0022] In a possible implementation manner, the first indication information is carried in a second extended community attribute field of the path attribute field.

[0023] The first indication information may be carried in a different extended group attribute field from the routing target, or may be carried in the same extended group attribute field as the entire content of the routing target, or may be carried in the same extended group attribute field as part of the content of the routing target and carried in a different extended group attribute field as another part of the content of the routing target.

[0024] The first indication information may be carried in the Type high field and the Type low field, or may also be carried in the Value field.

[0025] In this way, when the first indication information is carried in the message, it has higher flexibility.

[0026] In a possible implementation, each BGP message carries the ERT of the VPN instance of the corresponding network device. In addition, the second indication information can be obtained, and the second indication information can be used to determine that the IRT of any VPN instance in the current network is the same as the ERT of the VPN instance. After obtaining the second indication information, when obtaining the ERT and IRT of the VPN instances of multiple network devices, the following operations can be performed: based on any BGP message, the ERT of the VPN instance of the network device corresponding to any BGP message is extracted, and the IRT of the VPN instance of the network device corresponding to any BGP message is set to the ERT of the VPN instance of the network device corresponding to any BGP message.

[0027] The second indication information may be obtained from the present device or other devices, and may be configured by an administrator.

[0028] In this way, the BGP message does not need to carry the IRT, thus saving transmission resources.

[0029] In a possible implementation, when generating VPN topology, the connection relationship between VPN instances of multiple network devices can be determined based on the ERT and IRT of VPN instances of multiple network devices, and then the VPN topology is generated based on the connection relationship between VPN instances of multiple network devices.

[0030] In this way, the VPN topology can accurately and clearly represent the connection relationship between VPN instances.

[0031] In a possible implementation, the multiple BGP messages include a first BGP message and a second BGP message, wherein the first BGP message corresponds to the first network device, and the second BGP message corresponds to the second network device. When the multiple BGP messages include the first BGP message and the second BGP message, the process of determining the connection relationship between the VPN instances of the multiple network devices may include: determining a first connection relationship between the first VPN instance and the second VPN instance based on the corresponding relationship between the ERT of the first VPN instance of the first network device and the IRT of the second VPN instance of the second network device, wherein the first connection relationship indicates whether the second VPN instance can access the first VPN instance, and / or determining a second connection relationship between the first VPN instance and the second VPN instance based on the corresponding relationship between the IRT of the first VPN instance of the first network device and the ERT of the second VPN instance of the second network device, wherein the second connection relationship indicates whether the first VPN instance can access the second VPN instance.

[0032] The corresponding relationship may be a variety of relationships, for example, an ERT of the first VPN instance is equal to an IRT of the second VPN instance, or a value obtained by performing a specified operation on an ERT of the first VPN instance and an IRT of the second VPN instance is equal to a specified value, and so on.

[0033] In this way, the VPN topology can accurately and clearly represent the connection relationship between VPN instances.

[0034] In a possible implementation, when the ERT of the first VPN instance of the first network device and the IRT of the second VPN instance of the second network device include the same value option, it is determined that the second VPN instance can access the first VPN instance.

[0035] Each piece of routing information includes an ERT list and an IRT list of a VPN instance, the IRT list includes at least one IRT, and the ERT list includes at least one ERT. When comparing the ERT and IRT of two VPN instances, as long as there is an identical value in the ERT list of the first VPN instance and the IRT list of the second VPN instance, the comparison is considered successful, that is, it is determined that the second VPN instance can access the first VPN instance.

[0036] In a possible implementation, when the IRT of the first VPN instance of the first network device and the ERT of the second VPN instance of the second network device include the same value option, it is determined that the first VPN instance can access the second VPN instance.

[0037] Each piece of routing information includes an ERT list and an IRT list of a VPN instance, the IRT list includes at least one IRT, and the ERT list includes at least one ERT. When comparing the ERT and IRT of two VPN instances, as long as there is an identical value in the IRT list of the first VPN instance and the ERT list of the second VPN instance, the comparison is considered successful, that is, it is determined that the first VPN instance can access the second VPN instance.

[0038] In a possible implementation, the network system to which the multiple network devices belong includes a first autonomous system (AS) and a second AS, the multiple BGP messages include a third BGP message from the first AS and a fourth BGP message from the second AS, the third BGP message corresponds to a third VPN instance of the third network device, and the fourth BGP message corresponds to a fourth VPN instance of the fourth network device. Accordingly, the generated VPN topology may also indicate that there is a connection in the first specified communication mode between nodes corresponding to the third VPN instance and the fourth VPN instance.

[0039] The first designated communication mode may be option A or other communication modes between cross-domain VPN instances.

[0040] In this way, the connection relationship between VPN instances of different ASs can be obtained, VPN topologies of multiple ASs can be generated, and the universality of VPN topologies can be improved.

[0041] In a possible implementation, the process before generating the VPN topology may further include: obtaining first configuration information, wherein the first configuration information indicates that there is a connection in a first specified communication mode between the third VPN instance and the fourth VPN instance. After obtaining the first configuration information, the process of generating the VPN topology may include: generating a first VPN sub-topology based on the ERT and IRT of the VPN instance of the network device included in the first AS, generating a second VPN sub-topology based on the ERT and IRT of the VPN instance of the network device included in the second AS, and connecting the third VPN instance in the first VPN sub-topology and the fourth VPN instance in the second VPN sub-topology to obtain the VPN topology, wherein the connection mode between the nodes corresponding to the third VPN instance and the fourth VPN instance is a connection in the first specified communication mode.

[0042] The first configuration information can be obtained from the device or other devices, and can be configured by the administrator. The controller can determine the AS to which the network device corresponding to each UPDATE message belongs, and can obtain the ERT and IRT of the VPN instance in each AS, and generate the VPN sub-topology corresponding to each AS based on the ERT and IRT of the VPN instance in each AS. Then, based on each VPN sub-topology, an edge corresponding to option A is added. The display form of the edge can be arbitrarily set based on actual needs, such as a dotted line, a wavy line, etc.

[0043] In this way, VPN topologies of multiple ASs are generated, thereby improving the universality of the VPN topology.

[0044] In a possible implementation, the network system to which the multiple network devices belong includes a third AS and a fourth AS, the multiple BGP messages include a fifth BGP message from the third AS and a sixth BGP message from the fourth AS, the fifth BGP message corresponds to a fifth VPN instance of the fifth network device, and the sixth BGP message corresponds to a sixth VPN instance of the sixth network device. Accordingly, the generated VPN topology may also indicate a mutual access relationship between the fifth VPN instance and the sixth VPN instance.

[0045] There may be a connection in option B / C mode between the third AS and the fourth AS, or a connection in other similar cross-domain communication modes.

[0046] In this way, the connection relationship between VPN instances of different ASs can be obtained, VPN topologies of multiple ASs can be generated, and the universality of VPN topologies can be improved.

[0047] In a possible implementation, the processing before generating the VPN topology may further include: obtaining second configuration information, wherein the second configuration information indicates that the third AS and the fourth AS communicate across domains through a second specified communication mode. After obtaining the second configuration information, the processing of generating the VPN topology may include: determining the mutual access relationship between the fifth VPN instance and the sixth VPN instance based on the corresponding relationship between the ERT of the fifth VPN instance and the IRT of the sixth VPN instance, and / or the corresponding relationship between the IRT of the fifth VPN instance and the ERT of the sixth VPN instance.

[0048] The second configuration information can be obtained from the device or other devices, and can be configured by an administrator. The controller can obtain the ERT and IRT of the VPN instances in the third AS and the fourth AS, and generate a VPN topology common to the third AS and the fourth AS based on the ERT and IRT of all VPN instances in the third AS and the fourth AS.

[0049] In this way, VPN topologies of multiple ASs are generated, thereby improving the universality of the VPN topology.

[0050] In a possible implementation, multiple BGP messages are sent by multiple network devices.

[0051] The network device can be a provider edge device (PE), a customer edge device (CE), or a non-edge device. The network device sends directly to the BGP message receiver. The network device and the BGP message receiver have a pre-established BGP neighbor relationship. After generating a BGP message, the network device sends the BGP message to all BGP neighbors, including the BGP message receiver. In this way, the BGP messages corresponding to each network device can be sent to the BGP message receiver.

[0052] In a possible implementation manner, the multiple BGP messages are sent by at least one route reflector.

[0053] The network device sends a BGP message to its corresponding route reflector. The route reflector has a BGP neighbor relationship established in advance with the BGP message receiver (for example, the controller). After the route reflector receives the BGP message, it will send the BGP message to all BGP neighbors, including the BGP message receiver. In this way, the BGP messages corresponding to each network device can eventually be sent to the BGP message receiver.

[0054] In this way, in the process of sending routing targets through BGP messages to build a VPN topology, only a small amount of BGP neighbor relationships can be configured, thereby simplifying configuration information in network devices.

[0055] In a second aspect, a method for generating a VPN topology is provided, the method comprising: sending a BGP message, wherein the BGP message carries a routing target of a VPN instance, the routing target is used to generate a VPN topology, and the VPN topology indicates a mutual access relationship between VPN instances in a network.

[0056] There are multiple possible sending methods, for example, sending to the controller via RR, or sending directly.

[0057] In this way, the routing targets of each VPN instance are collected through BGP messages to generate VPN topology. In the process of generating VPN topology, there is no need to parse the configuration files of each network device, so there will be no problem that the configuration files cannot be parsed, which can improve the accuracy of VPN topology acquisition.

[0058] In a possible implementation, the routing target includes an outgoing routing target ERT and an incoming routing target IRT.

[0059] In this way, the ERT and IRT can be directly obtained in the BGP message without additional processing, which can save processing resources.

[0060] In a possible implementation, the BGP message is a BGP UPDATE message.

[0061] In a possible implementation, the route target is carried in a path attribute field of a BGP UPDATE message.

[0062] In a possible implementation manner, the IRT is carried in the first extended community attribute field of the path attribute field.

[0063] The ERT and IRT may be carried in different extended community attribute fields or in the same extended community attribute field.

[0064] In a possible implementation, the BGP UPDATE message also carries first indication information, and the first indication information is used to indicate that the BGP UPDATE message is only used to announce the ERT and IRT carried by the BGP UPDATE message, and to inform each network device that it is not necessary to process the BGP UPDATE message, and there is no need to add the routing prefix in the BGP UPDATE message to the routing table, and only the controller processes the routing target in the UPDATE message.

[0065] In this way, in the process of establishing a VPN topology, redundant processing of each network device can be reduced, and the processing resource occupation of each network device can be reduced.

[0066] In a possible implementation, the trigger condition for sending the BGP message is: determining that the routing target of the first VPN instance has changed. Accordingly, the routing target carried in the BGP message is the changed routing target of the first VPN instance.

[0067] The change of the routing target may be due to the corresponding configuration operation performed by the user or the network administrator.

[0068] In this way, the BGP message receiver can learn the changes of the routing target of the VPN instance in real time to update the VPN topology, which is more helpful to improve the real-time performance of the VPN topology.

[0069] In a possible implementation, the trigger condition before sending the BGP message is: establishing the second VPN instance. Accordingly, the routing target carried in the BGP message is the routing target of the second VPN instance.

[0070] The VPN instance may be established because a user or a network administrator performs corresponding configuration operations.

[0071] In this way, the BGP message receiver can obtain the routing target of the newly established VPN instance in real time to update the VPN topology, which is more helpful to improve the real-time performance of the VPN topology.

[0072] According to a third aspect, a device for generating a VPN topology is provided. The device includes at least one module. The at least one module is used to implement the method provided by the first aspect and possible implementations thereof.

[0073] In a fourth aspect, a device for generating a VPN topology is provided, the device comprising at least one module, and the at least one module is used to implement the method provided by the second aspect and possible implementations thereof.

[0074] In a fifth aspect, a computer device is provided, the computer device comprising a memory and a processor, the memory being used to store computer instructions. The processor executes the computer instructions stored in the memory, so that the computer device executes the method provided in the first aspect and possible implementations thereof.

[0075] In a sixth aspect, a computer device is provided, the computer device comprising a memory and a processor, the memory being used to store computer instructions. The processor executes the computer instructions stored in the memory, so that the computer device executes the method provided in the second aspect and possible implementations thereof.

[0076] In a seventh aspect, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores a computer program code. When the computer program code is executed by a computer device, the computer device executes the method provided by the first aspect and its possible implementation methods.

[0077] In an eighth aspect, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores a computer program code. When the computer program code is executed by a computer device, the computer device executes the method provided by the second aspect and its possible implementation manner.

[0078] In a ninth aspect, a computer program product is provided, the computer program product comprising a computer program code, and when the computer program code is executed by a computer device, the computer device executes the method provided by the first aspect and its possible implementation manner.

[0079] In a tenth aspect, a computer program product is provided, the computer program product comprising a computer program code, and when the computer program code is executed by a computer device, the computer device executes the method provided by the second aspect and its possible implementation manner. BRIEF DESCRIPTION OF THE DRAWINGS

[0080] Figure 1 is a schematic diagram of the structure of a controller provided by an embodiment of the present disclosure;

[0081] Figure 2 is a flow chart of a method for generating a VPN topology provided by an embodiment of the present disclosure;

[0082] Figure 3 is a network architecture diagram of a full-mesh network provided by an embodiment of the present disclosure;

[0083] Figure 4 is a network architecture diagram of a hub-spoke network provided by an embodiment of the present disclosure;

[0084] Figure 5 is a schematic diagram of the format of an UPDATE message provided by an embodiment of the present disclosure;

[0085] Figure 6 is a VPN topology diagram provided by an embodiment of the present disclosure;

[0086] Figure 7 is a VPN topology diagram provided by an embodiment of the present disclosure;

[0087] Figure 8 is a network architecture diagram provided by an embodiment of the present disclosure;

[0088] Fig. 9 is a network architecture diagram provided by an embodiment of the present disclosure;

[0089] Fig.10 is a flow chart of a method for generating a VPN topology provided by an embodiment of the present disclosure;

[0090] Fig.11is a VPN topology diagram provided by an embodiment of the present disclosure;

[0091] Fig.12 is a network architecture diagram provided by an embodiment of the present disclosure;

[0092] Fig.13 is a flow chart of a method for generating a VPN topology provided by an embodiment of the present disclosure;

[0093] Fig.14 is a VPN topology diagram provided by an embodiment of the present disclosure;

[0094] Fig.15 It is a structural schematic diagram of a device for generating a VPN topology provided by an embodiment of the present disclosure;

[0095] Fig.16 It is a structural schematic diagram of a device for generating a VPN topology provided by an embodiment of the present disclosure. DETAILED DESCRIPTION

[0096] The present disclosure provides a method for generating a VPN topology. The following is an explanation of some terms in the process of the method:

[0097] Network equipment

[0098] A network device is a device used for message forwarding in a network. A network device may be a provider edge device (PE), a customer edge device (CE), or a non-edge device. The embodiment of the present disclosure mainly takes the network device being a PE as an example to explain the solution in detail. Other situations are similar and will not be described in detail.

[0099] VPN Instance

[0100] A VPN instance is also called a virtual routing forwarding (VRF), which can be considered as a virtual router used to build a VPN and a transmission node of the VPN. For example, a VPN built in a carrier network is generally built on a PE, and a PE can establish and maintain one or more VPN instances.

[0101] Route target (RT)

[0102] The routing target includes ERT and IRT. Each VPN instance is configured with at least one ERT and at least one IRT. When any IRT of VPN instance A matches any ERT of VPN instance B, there is a connection from VPN instance B to VPN instance A, indicating that VPN instance A can access VPN instance B. When any ERT of VPN instance C matches any IRT of VPN instance D, there is a connection from VPN instance C to VPN instance D, indicating that VPN instance D can access VPN instance C.

[0103] BGP Messages

[0104] Various messages defined by the BGP protocol. In the disclosed embodiment, the BGP message used to transmit the route target may be a BGP update (UPDATE) message or a Hello (HELLO) message, etc. The disclosed embodiment takes the BGP UPDATE message as an example for explanation, and other situations are similar and will not be repeated. The BGP message in the disclosed embodiment may be a multiprotocol extensions for border gateway protocol (MP-BGP) message.

[0105] BGP UPDATE message (abbreviated as UPDATE message)

[0106] UPDATE messages are used by network devices to notify external routing information. UPDATE messages carry routing information such as RD, nexthop, prefix, and ERT. RD is used to identify the VPN instance corresponding to the routing information. Nexthop is the Internet Protocol (IP) address of the outbound interface of the PE to send the UPDATE message. Prefix is ​​the address of the user network to which the VPN instance is connected.

[0107] Generally, one or more VPN instances may be established in a network device, each VPN instance may correspond to one or more prefixes, and an UPDATE message is used to notify at least one piece of routing information (ie, at least one prefix) of a VPN instance.

[0108] VPN Topology

[0109] The VPN topology is used to present the connection relationship of VPN instances, indicating the mutual access relationship of VPN instances of multiple network devices in the network, or indicating the mutual access relationship of the site (which can be simply referred to as VPN site) to which the VPN instance belongs. In the VPN topology, VPN instances are represented by nodes, and the connection relationship between VPN instances is represented by the edges between nodes. Optionally, the edges in the VPN topology can be directed, for example, an arrow from VPN instance A to VPN instance B can indicate that VPN instance B is reachable to VPN instance A, or that VPN instance A is reachable to VPN instance B. Optionally, the edges in the VPN topology can also be non-directional, for example, VPN instance A and VPN instance B are connected using a line segment without an arrow, indicating that VPN instance A and VPN instance B can visit each other.

[0110] Autonomous system (AS)

[0111] AS is a collection of network devices divided by operators, institutions, companies and other entities. Each AS can include multiple network devices. These entities can apply for their own AS numbers to establish AS.

[0112] Route reflectors (RR)

[0113] RR is used to announce the routing information of several network devices (e.g., PE) for which it is responsible. After receiving the UPDATE message sent by PE, RR will forward (also known as reflect) the UPDATE message to all its BGP neighbors. An AS can have one or more RRs.

[0114] Full-mesh networking

[0115] Full-mesh networking is a network architecture in which VPN connections exist between all VPN instances under the same VPN. In full-mesh networking, the ERT and IRT of any VPN instance are the same.

[0116] Hub-spoke networking

[0117] Hub-spoke networking is a network architecture that can include at least one hub network and at least one spoke network. A hub VPN instance can be established on a network device in the hub network, and a spoke VPN instance can be established on a network device in the spoke network. Under the same VPN, there is a VPN connection between each spoke VPN instance and all hubVPN instances, and there is also a VPN connection between all hubVPN instances.

[0118] Autonomous system boundary router (ASBR)

[0119] ASBR is a router in an AS that connects to other ASs.

[0120] The embodiment of the present disclosure provides a method for generating a VPN topology, which can be applied to a network system. The network system may include a controller and a large number of network devices, etc. The network device may be responsible for providing relevant information for generating a VPN topology. The process of generating a VPN topology may be performed by any device, such as a controller, any network device, or any other computer device other than the controller and the network device. The embodiment of the present disclosure takes the controller responsible for generating a VPN topology as an example to provide a detailed description of the solution, and other situations are similar and will not be repeated.

[0121] like Figure 1 As shown, the controller may include a processor 110 , a memory 120 , a communication component 130 , and the like.

[0122] The processor 110 may include any one or more of a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP) or a digital signal processor (DSP). The processor may be used to execute various program instructions. For example, the processor may be used to generate a VPN topology according to a routing target.

[0123] The memory 120 may be various volatile memories or non-volatile memories, such as a solid state disk (SSD), a dynamic random access memory (DRAM), etc. The memory may be used to store pre-stored data, intermediate data, and result data related to the processing process, such as routing targets, etc.

[0124] The communication component 130 may be a wired network connector, a wireless fidelity (WiFi) module, a Bluetooth module, a cellular network communication module, etc. The communication component may be used to transmit data with other devices, for example, to receive BGP messages from network devices, and so on.

[0125] The present disclosure provides a method for generating a VPN topology. The processing flow of the method is as follows: Figure 2 As shown (the schematic diagram of the relevant network architecture and VPN topology can refer to each example in the subsequent content), the following steps may be included:

[0126] 201. PE sends an UPDATE message.

[0127] Among them, the UPDATE message can carry the routing target of the VPN instance in the PE. The purpose of carrying the routing target is to let the controller know the ERT and IRT of each VPN instance. In some networks (which can be called the first type of networking), the ERT and IRT of any VPN instance are the same, such as full-mesh networking, etc. For this type of networking, the routing target carried in the UPDATE message can only include ERT. In other networks (which can be called the second type of networking), the ERT and IRT of any VPN instance are not necessarily the same, such as hub-spoke networking, etc. For this type of networking, the routing target carried by the UPDATE message can include ERT and IRT. In addition, in addition to using UPDATE messages, other BGP messages can also be used, such as HELLO messages.

[0128] There are many possible triggering methods for PE to send UPDATE messages. The following are some of the possible triggering methods:

[0129] Method 1: receiving a trigger notification. The trigger notification can be sent to the PE by an administrator operating a management terminal.

[0130] Method 2: Establishing a VPN instance: When a PE establishes a VPN instance, it sends an UPDATE message carrying the routing target of the VPN instance.

[0131] Mode 3: The route target of an established VPN instance changes. When the route target of a VPN instance in a PE changes, an UPDATE message is sent, carrying the changed route target of the VPN instance. The change in the route target may be due to the corresponding configuration operation performed by the user or network administrator.

[0132] There is also a fourth triggering mode for the HELLO message, which is periodic triggering. Every time a specified period (such as 5 minutes) passes, the PE sends a HELLO message to the outside, carrying the routing target of the VPN instance in the PE. If there are multiple VPN instances in the PE, multiple HELLO messages can be sent separately.

[0133] Optionally, in actual applications, a "first trigger" may be performed first, that is, triggering mode 1 is used to trigger each PE in the network to send an UPDATE message. At this time, each PE sends an UPDATE message almost simultaneously, and subsequently each PE uses triggering mode 2 and triggering mode 3 to trigger the sending of an UPDATE message.

[0134] When sending an UPDATE message after a trigger event is met, there are several possible ways to send it, as follows:

[0135] The first sending method is to send to the controller through RR. PE sends an UPDATE message to its corresponding RR. RR and the controller have established a BGP neighbor relationship in advance. After RR receives the UPDATE message, it will send the UPDATE message to all BGP neighbors, including the controller. In this way, the UPDATE messages corresponding to each PE can be finally sent to the controller.

[0136] The second sending method is that PE sends directly to the controller. PE and the controller have established a BGP neighbor relationship in advance. After generating an UPDATE message, PE sends the UPDATE message to all BGP neighbors, including the controller. In this way, the UPDATE messages corresponding to each PE can be sent to the controller.

[0137] 202. The controller receives multiple UPDATE messages.

[0138] The controller can receive UPDATE messages sent directly by each PE, and can also receive UPDATE messages of each PE reflected by the RR. The controller can read at least one content information in each UPDATE message, and one content information can include RD, nexthop, prefix and route target.

[0139] When performing the "first trigger", the management terminal can simultaneously send a trigger notification to the controller. When the controller receives the trigger notification, it can start timing, and will subsequently receive a large number of UPDATE messages. When the timing duration reaches the preset duration (such as 5 minutes), the controller can perform subsequent processing of step 203 based on the UPDATE message received during the timing process. Alternatively, the processing of step 203 may not be triggered by timing, but may be triggered by manual operation. The administrator operates the management terminal to send a topology generation notification to the controller. After the controller receives the topology generation notification, it performs subsequent processing of step 203 based on the UPDATE message received between the trigger notification and the topology generation notification.

[0140] In the subsequent process, the controller will randomly receive an UPDATE message sent by any PE, and each time an UPDATE message is received, the subsequent step 203 can be processed based on the UPDATE message. In this way, the VPN topology can be updated as soon as the route changes. Compared with the method of parsing the configuration file to generate the VPN topology in the related art (the timing of parsing the configuration file is controlled by humans, and whether the route target changes will not be considered), the real-time performance of the VPN topology can be better guaranteed.

[0141] 203. The controller generates a VPN topology based on the received routing targets corresponding to the VPN instances.

[0142] The controller may obtain the ERT and IRT corresponding to each VPN instance based on each UPDATE message, and then determine the VPN topology based on the ERT and IRT corresponding to each VPN instance. The specific processing may be as follows.

[0143] First, the unique identifier of the VPN instance corresponding to each content information of the UPDATE message (instance identifier for short) is confirmed.

[0144] The methods may be as follows: Method 1, RD and nexthop may be combined as instance identifiers; Method 2, the physical identity document (ID) of the corresponding PE may be queried through nexthop, and the physical ID and RD may be combined as instance identifiers; Method 3, RD may be used as instance identifiers. Among them, Method 3 is applicable to the situation where the RDs of various VPN instances in the network are different, while Method 1 and Method 2 are applicable to various situations. In addition to the above three methods, there are many other methods for confirming instance identifiers, which will not be described here.

[0145] Then, the instance identifier is used to perform deduplication processing on the content information of multiple UPDATE messages. The deduplication processing is mainly aimed at the above-mentioned "first trigger" processing process.

[0146] The method may be as follows: Method 1, for multiple pieces of content information corresponding to the same instance identifier, these multiple pieces of content information only include ERT (this situation occurs in the first type of networking mentioned above). In this case, one piece of content information is randomly retained; Method 2, for multiple pieces of content information corresponding to the same instance identifier, only one piece of content information includes ERT and IRT, and the other content information does not include IRT. In this case, the one piece of content information including ERT and IRT is retained, and the other content information that does not include IRT is removed; Method 3, for multiple pieces of content information corresponding to the same instance identifier, these multiple pieces of content information include ERT and IRT. In this case, one piece of content information is randomly retained.

[0147] Then, for each piece of content information remaining after deduplication processing, the corresponding ERT and IRT are determined to obtain the ERT and IRT corresponding to each VPN instance.

[0148] For the first type of networking, the ERT and IRT of any VPN instance are the same, and the routing target in the UPDATE message content information may only include ERT. In this case, the same IRT can be determined based on the ERT in the routing target, that is, IRT is set to ERT; for the second type of networking, the ERT and IRT of any VPN instance may be different, and the routing target in the UPDATE message content information may include ERT and IRT. In this case, ERT and IRT can be directly obtained from the content information. Furthermore, combined with the instance identifier corresponding to each piece of content information, the corresponding relationship between the instance identifier and ERT and IRT can be determined, that is, the ERT and IRT corresponding to each VPN instance can be determined.

[0149] Finally, based on the ERT and IRT corresponding to each VPN instance, the VPN topology is determined. The VPN topology indicates the mutual access relationship between the VPN instances of multiple network devices corresponding to multiple BGP messages.

[0150] For example, the multiple BGP messages received by the controller include a first BGP message and a second BGP message, the first BGP message corresponds to a first network device, and the second BGP message corresponds to a second network device. The controller can determine a first connection relationship between the first VPN instance and the second VPN instance based on a correspondence between an ERT of a first VPN instance of the first network device and an IRT of a second VPN instance of the second network device, and the controller can determine a second connection relationship between the first VPN instance and the second VPN instance based on a correspondence between an IRT of the first VPN instance of the first network device and an ERT of the second VPN instance of the second network device. The first connection relationship indicates whether the second VPN instance can access the first VPN instance, and the second connection relationship indicates whether the first VPN instance can access the second VPN instance.

[0151] When the ERT of the first VPN instance and the IRT of the second VPN instance include the same value options, the controller can determine that the second VPN instance can access the first VPN instance; when the IRT of the first VPN instance and the ERT of the second VPN instance include the same value options, the controller can determine that the first VPN instance can access the second VPN instance.

[0152] Optionally, the edge of the VPN topology is directed, and can be unidirectional or bidirectional. An ERT of the first VPN instance is equal to an IRT of the second VPN instance, indicating that the second VPN instance can access the first VPN instance, or in other words, the second VPN instance is reachable to the first VPN instance. Then, a directed edge can be set between a node corresponding to the first VPN instance (hereinafter referred to as the first node) and a node corresponding to the second VPN instance (hereinafter referred to as the second node) in the VPN topology, for example, an edge is set from the first node to the second node (the edge can be represented as a unidirectional arrow) to indicate that the second VPN instance can access the first VPN instance, or an edge is set from the second node to the first node (the edge can be represented as a unidirectional arrow) to indicate that the second VPN instance can access the first VPN instance. When an IRT of the first VPN instance is equal to an ERT of the second VPN instance, indicating that the first VPN instance can access the second VPN instance, or in other words, the first VPN instance is reachable to the second VPN instance, a directed edge may be set between the first node and the second node, for example, an edge from the second node to the first node (the edge may be represented as a one-way arrow) may be set to indicate that the first VPN instance can access the second VPN instance, or an edge from the first node to the second node (the edge may be represented as a one-way arrow) may be set to indicate that the first VPN instance can access the second VPN instance. When an ERT of the first VPN instance is equal to an IRT of the second VPN instance, and an IRT of the first VPN instance is equal to an ERT of the second VPN instance, the edge between the first node and the second node may be set to be bidirectional (the edge may be represented as a bidirectional arrow) to indicate that the first VPN instance and the second VPN instance can access each other, or in other words, the second VPN instance is reachable to the first VPN instance and the first VPN instance is reachable to the second VPN instance.

[0153] Optionally, the VPN topology may also include a routing prefix corresponding to each VPN instance to indicate which networks are reachable between VPN instances. For example, if the first VPN instance and the second VPN instance can access each other, and the node edge corresponding to the first VPN instance displays the routing prefix 192.168.1.0 / 24, and the node edge corresponding to the second VPN instance displays the routing prefix 192.168.2.0 / 24, it means that the second VPN instance can access network 192.168.1.0 / 24 through the first VPN instance, and the first VPN instance can access network 192.168.2.0 / 24 through the second VPN instance.

[0154] Based on the ERT and IRT of each VPN instance, determine whether the ERT and IRT of any two VPN instances correspond. A BGP message includes at least one routing information, each routing information includes an ERT list and an IRT list of a VPN instance, the IRT list includes at least one IRT, and the ERT list includes at least one ERT. Therefore, when comparing the ERT and IRT of two VPN instances (for example, VPN instance C and VPN instance D), as long as there is an identical value in the ERT list of VPN instance C and the IRT list of VPN instance D, the comparison is considered successful, that is, VPN instance D can access VPN instance C. For example, the ERT list of VPN instance C is {100:200, 100:300, 100:400}, and the IRT list is {100:500, 100:600, 100:700}; the ERT list of VPN instance D is {100:500, 100:800, 100:900}, and the IRT list is {100:200, 200:100, 200:200}. By comparison, we can find that both the ERT list of VPN instance C and the IRT list of VPN instance D contain 100:200, that is, VPN instance D can access VPN instance C; both the IRT list of VPN instance C and the ERT list of VPN instance D contain 100:500, that is, VPN instance C can access VPN instance D. Therefore, in the VPN topology, the edge between the node corresponding to VPN instance C and the node corresponding to VPN instance D is bidirectional.

[0155] The specific processing of the above step 203 is explained by taking the processing of "first trigger" as an example, and the controller needs to process a large number of UPDATE messages during this processing. After the processing of "first trigger" is completed, the controller can update the VPN topology based on each UPDATE message received. Specifically, the ERT and IRT corresponding to a VPN instance can be determined based on the UPDATE message, and then the ERT and IRT corresponding to the VPN instance are compared with the ERT and IRT corresponding to each other VPN instance to re-determine the connection relationship between the VPN instance and other VPN instances, thereby updating the VPN topology.

[0156] In addition, PE will also send an UPDATE message when deleting a route. When the controller receives an UPDATE message to delete a route (i.e., delete a route prefix), it determines the VPN instance to which the UPDATE message corresponds. If, after deleting the route prefix, the VPN instance has no other route prefixes, the node and corresponding connection of the VPN instance can be deleted from the generated VPN topology. If, after deleting the route prefix, the VPN instance still has other route prefixes, the VPN topology does not need to be adjusted.

[0157] By adopting the above method, the routing targets of each VPN instance are collected through BGP messages to generate VPN topology. In the process of generating VPN topology, there is no need to parse the configuration files of each network device, so there will be no problem that the configuration files cannot be parsed, which can improve the accuracy of VPN topology.

[0158] The following is a detailed description of the related processing for the first type of networking (ERT and IRT of any VPN instance in the network are the same) and the second type of networking (ERT and IRT of any VPN instance in the network are not necessarily the same). The first type of networking takes full-mesh networking as an example (the corresponding network architecture is as follows Figure 3 As shown in the figure, VRF_A, VRF_B, VRF_C, VRF_D, VRF_E, and VRF_F are six VPN instances, and P is any one or more network devices). The second type of networking takes hub-spoke networking as an example (the corresponding network architecture is as follows Figure 4 As shown in the figure, VRF_A, VRF_B, and VRF_C are three VPN instances). The processing of the first type of networking is similar to that of the full-mesh networking, and the processing of the second type of networking is similar to that of the hub-spoke networking. The embodiments of the present disclosure will no longer elaborate on other networking one by one.

[0159] PE and controller can obtain configuration information respectively, and the configuration information can be obtained from this device or from other specified devices. Network indication information can be obtained in the configuration information, and the networking indication information is used to indicate the networking architecture. After PE and controller determine that the networking architecture is full-mesh networking through the networking indication information, they can determine to adopt the processing method of Example 1; after PE and controller determine that the networking architecture is hub-spoke networking through the networking indication information, they can determine to adopt the processing method of Example 2. Alternatively, the processing method of Example 2 can be adopted in all networks.

[0160] Example 1: full-mesh networking

[0161] When PE determines that the ERT and / or IRT of a VPN instance has changed, it can send an UPDATE message, which can only carry ERT (because ERT and IRT are the same). The RT field has been defined in the general UPDATE message to carry ERT, which is described in detail below:

[0162] The format of the UPDATE message is as follows Figure 5As shown, it includes the Unfeasible Routes Length field, the Withdrawn Routes field, the Total Path Attribute Length field, the Path Attributes field, and the Network Layer Reachability Information field. The RT field is an extended-community field defined in the Path Attributes field. The extended-community attribute field includes the attribute type (Attr.Type) field, the attribute length (Attr.Length) field, and the attribute value (Attr.Value) field. The Attr.Type field may further include an attribute flag (Attr.Flags) field and an attribute type code (Attr.Type Code) field. The Attr.Flags field is used to carry some common attribute parameter information, for example, a certain attribute parameter information is used to indicate that the extended-community attribute field is an optional attribute field or a mandatory attribute field, a certain attribute parameter information is used to indicate the length of the Attr.Length field, and so on. The Attr.Value field may further include Type high, Type low, and Value fields.

[0163] The content value of the Attr.Type Code field of the UPDATE message is 16 (16 is used to indicate the extended community attribute field), the Type high field and the Type low field are the first value combination (the first value combination is a defined value combination, used to indicate that the extended community attribute field is the RT field), and the Value field carries the value of RT (the default is ERT).

[0164] The controller receives the UPDATE message from each PE and obtains the content information of each UPDATE message, for example, as follows:

[0165] {RD:100:100,ERT:1:1,nexthop:1.1.1.1,prefix:192.168.0.0 / 24}

[0166] {RD:100:100,ERT:1:1,nexthop:1.1.1.1,prefix:192.168.1.0 / 24}

[0167] {RD:200:100,ERT:1:1,nexthop:2.2.2.2,prefix:192.168.2.0 / 24}

[0168] {RD:300:100,ERT:1:1,nexthop:3.3.3.3,prefix:192.168.3.0 / 24}

[0169] {RD:100:200,ERT:2:2,nexthop:1.1.1.1,prefix:10.0.1.0 / 24}

[0170] {RD:200:200,ERT:2:2,nexthop:2.2.2.2,prefix:10.0.2.0 / 24}

[0171] {RD:300:200,ERT:2:2,nexthop:3.3.3.3,prefix:10.0.3.0 / 24}

[0172] Here, RD is used as the instance identifier (the RDs corresponding to the six VPN instances VRF_A, VRF_B, VRF_C, VRF_D, VRF_E, and VRF_F are 100:100, 200:100, 300:100, 100:200, 200:200, and 300:200, respectively). For multiple pieces of content information corresponding to the same instance identifier, one piece of content information is randomly retained. Moreover, based on the same characteristics of ERT and IRT in full-mesh networking, IRT can be set based on the ERT of each VPN. In this way, the correspondence between the instance identifier and ERT and IRT can be obtained as follows:

[0173] {RD:100:100,ERT:1:1,IRT:1:1}

[0174] {RD:200:100,ERT:1:1,IRT:1:1}

[0175] {RD:300:100,ERT:1:1,IRT:1:1}

[0176] {RD:100:200,ERT:2:2,IRT:2:2}

[0177] {RD:200:200,ERT:2:2,IRT:2:2}

[0178] {RD:300:200,ERT:2:2,IRT:2:2}

[0179] At this point, it can be determined that there are six VPN instances. The ERT and IRT of these six VPN instances are compared with each other, and the results are as follows:

[0180] The ERT of VRF_D matches the IRT of VRF_E and the IRT of VRF_F. It can be determined that VRF_E can access VRF_D, and VRF_F can access VRF_D, and so on (the process of determining the mutual access relationship between other VPN instances is similar and will not be listed here one by one). Based on the mutual access relationship between VPN instances, we can get the following: Figure 6 The VPN topology shown.

[0181] Example 2: hub-spoke networking

[0182] When PE determines that the ERT and / or IRT of a VPN instance has changed, it can send an UPDATE message. There are several cases for the UPDATE message: Case 1, if only the ERT has changed, ERT can be added to the UPDATE message (in this case, IRT can also be added at the same time); Case 2, if only the IRT has changed, ERT and IRT can be added to the UPDATE message (in this case, ERT can also be omitted, and the corresponding UPDATE message is only processed by the controller, and not by the network devices); Case 3, if both ERT and IRT have changed, ERT and IRT can be added to the UPDATE message.

[0183] In the case of adding ERT in the UPDATE message, ERT can be added to a certain extension field of the UPDATE message. The adding method is the same as in Example 1. Please refer to the relevant content in Example 1. In the case of adding IRT in the UPDATE message, IRT can be added to another extension field of the UPDATE message. The following is a detailed description:

[0184] The Path Attributes field of the UPDATE message can be used for message extension. An extended group attribute field (which may be referred to as the first extended group attribute field) may be defined in the Path Attributes field. The structure of the first extended group attribute field is similar to the structure of the extended group attribute field carrying ERT described above, and reference may be made to the above-mentioned related content. For the first extended group attribute field, a value combination of the Type high field and the Type low field may be predefined (which may be referred to as the second value combination), such as the second value combination of 20 (Type high) and 15 (Type low). The second value combination is used to indicate that the first extended group attribute field is used to carry IRT, and the second value combination may be arbitrarily selected from all undefined value combinations.

[0185] When adding IRT in the UPDATE message, the content of the Attr.Type Code field may be set to 16, the Typehigh field and the Type low field may be set to the second value combination, and the IRT may be filled into the Value field.

[0186] In addition, in addition to using the first extended community attribute field, a newly added type of extended field may also be used. Accordingly, the value of the Attr.Type Code field may be predefined as an undefined value, such as 17.

[0187] In the case of adding IRT in UPDATE message, when a VPN instance corresponds to multiple prefixes, an UPDATE message will be sent for each prefix, and a prefix (remembered as prefix1) can be pre-selected (can be randomly selected) and IRT can be added to the UPDATE message corresponding to prefix1. After prefix1 is revoked, a new prefix (remembered as prefix2) can be selected and IRT can be added to the UPDATE message corresponding to prefix2.

[0188] The controller receives the UPDATE message from each PE and obtains the content information of each UPDATE message, for example, as follows:

[0189] {RD:100:1,ERT:1:1,IRT:2:2,nexthop:1.1.1.1,prefix:192.168.0.0 / 24}

[0190] {RD:100:1,ERT:1:1,nexthop:1.1.1.1,prefix:192.168.1.0 / 24}

[0191] {RD:100:2,ERT:2:2,IRT:1:1,nexthop:2.2.2.2,prefix:192.168.2.0 / 24}

[0192] {RD:100:3,ERT:2:2,IRT:1:1,nexthop:3.3.3.3,prefix:192.168.3.0 / 24}

[0193] Here, RD is used as the instance identifier (the RDs corresponding to the three VPN instances VRF_A, VRF_B, and VRF_C are 100:1, 100:2, and 100:3, respectively). For multiple pieces of content information corresponding to the same instance identifier, one piece of content information including ERT and IRT is retained, and all other content information not including IRT is removed. Then ERT and IRT are directly obtained from the remaining content information. In this way, the corresponding relationship between the instance identifier and ERT and IRT can be obtained as follows:

[0194] {RD:100:1,ERT:1:1,IRT:2:2}

[0195] {RD:100:2,ERT:2:2,IRT:1:1}

[0196] {RD:100:3,ERT:2:2,IRT:1:1}

[0197] At this point, it can be determined that there are three VPN instances. The ERT and IRT of these three VPN instances are compared with each other, and the results are as follows:

[0198] The ERT of VRF_A matches the IRT of VRF_B and the IRT of VRF_C. It can be determined that VRF_B can access VRF_A and VRF_C can access VRF_A. The ERT of VRF_B matches the IRT of VRF_A. It can be determined that VRF_A can access VRF_B. The ERT of VRF_C matches the IRT of VRF_A. It can be determined that VRF_A can access VRF_C. Therefore, we can get the following: Figure 7 VPN topology shown.

[0199] In the embodiment of the present disclosure, when sending an UPDATE message, an indication information can be added to the UPDATE message to indicate that the UPDATE message is only used to announce the routing target carried by the UPDATE message, that is, to inform each network device that there is no need to process the UPDATE message, and there is no need to add the routing prefix in the UPDATE message to the routing table, and only the controller processes the routing target in the UPDATE message.

[0200] The indication information can be added to another extended field of the UPDATE message, which is described in detail below:

[0201] An extended group attribute field (which may be referred to as a second extended group attribute field) may be defined in the Path Attributes field of the UPDATE message. The structure of the second extended group attribute field is similar to the structure of the extended group attribute field carrying ERT described above, and reference may be made to the above-mentioned related content. For the second extended group attribute field, a value combination of the Type high field and the Type low field may be predefined (which may be referred to as a third value combination), and the third value combination may be arbitrarily selected from all undefined value combinations, and the third value combination shall be different from the above-mentioned second value combination.

[0202] When adding indication information in an UPDATE message, the content of the Attr.Type Code field can be set to 16, and the Type high field and the Type low field can be set to the third value combination. At this time, the third value combination can be considered to be the above indication information. In addition, IRT can be added to the Value field, that is, for an UPDATE message with the second extended community attribute field added, the first extended community attribute field does not need to be added. Alternatively, another processing method can be adopted, in which the first extended community attribute field is still added to the UPDATE message to carry the IRT, and the Value field in the second extended community attribute field is left blank.

[0203] In addition, in addition to using the second extended community attribute field, a newly added type of extended field may also be used. Accordingly, the value of the Attr.Type Code field may be predefined as an undefined value, such as 17.

[0204] Below Figure 4 Taking the network architecture shown in FIG. 1 as an example, the use of the indication information is described in detail. In this network architecture, each VPN instance corresponds to multiple CEs, and the PE to which the VPN instance belongs has not established a physical connection with one of the CEs. Figure 8 As shown in the figure, the dotted line indicates that the PE and CE have established a connection relationship, and the dotted line with a cross indicates that the PE and CE have not yet established a connection relationship. In the figure, VRF_A, VRF_B, and VRF_C are three VPN instances, and the corresponding RDs are 100:1, 100:2, and 100:3 respectively. The controller receives the UPDATE message from each PE and obtains the content information of each UPDATE message as follows:

[0205] {RD:100:1,ERT:1:1,IRT:2:2,nexthop:1.1.1.1,prefix:1.1.1.1,extended-community:IRT_Advertisement}

[0206] {RD:100:2,ERT:2:2,IRT:1:1,nexthop:2.2.2.2,prefix:2.2.2.2,extended-community:IRT_Advertisement}

[0207] {RD:100:3,ERT:2:2,IRT:1:1,nexthop:3.3.3.3,prefix:3.3.3.3,extended-community:IRT_Advertisement}

[0208] {RD:100:1,ERT:1:1,nexthop:1.1.1.1,prefix:192.168.0.0 / 24}

[0209] {RD:100:1,ERT:1:1,nexthop:1.1.1.1,prefix:192.168.1.0 / 24}

[0210] {RD:100:2,ERT:2:2,nexthop:2.2.2.2,prefix:192.168.2.0 / 24}

[0211] {RD:100:3,ERT:2:2,nexthop:3.3.3.3,prefix:192.168.3.0 / 24}

[0212] Among them, extended-community:IRT_Advertisement indicates that the corresponding UPDATE message carries the above indication information. For the UPDATE message carrying indication information, the prefix can use a default value, such as 1.1.1.1, 2.2.2.2, 3.3.3.3, or the actual CE address can also be used. The first content information corresponds to CE1, the second content information corresponds to CE5, the third content information corresponds to CE6, the fourth content information corresponds to CE2, the fifth content information corresponds to CE3, the sixth content information corresponds to CE4, and the seventh content information corresponds to CE7. It can be seen that for the CE to which PE has been connected, PE sends an UPDATE message without indication information, and for the CE to which PE has not yet been connected, PE sends an UPDATE message carrying indication information.

[0213] Here, RD is used as the instance identifier. Among the multiple content information, remove the content information that does not include IRT_Advertisement. Then directly obtain ERT and IRT from the remaining content information. In this way, the corresponding relationship between the instance identifier and ERT and IRT can be obtained as follows:

[0214] {RD:100:1,ERT:1:1,IRT:2:2}

[0215] {RD:100:2,ERT:2:2,IRT:1:1}

[0216] {RD:100:3,ERT:2:2,IRT:1:1}

[0217] The ERT and IRT of the three VPN instances are compared with each other, and the results are as follows:

[0218] The ERT of VRF_A matches the IRT of VRF_B and the IRT of VRF_C. It can be determined that VRF_B can access VRF_A and VRF_C can access VRF_A. The ERT of VRF_B matches the IRT of VRF_A. It can be determined that VRF_A can access VRF_B. The ERT of VRF_C matches the IRT of VRF_A. It can be determined that VRF_A can access VRF_C. Therefore, we can get the following: Figure 7 The VPN topology shown.

[0219] Optionally, in the VPN topology, in addition to presenting the mutual access relationship between VPN instances, the connection relationship between the VPN instance and the corresponding CE can also be presented. Based on the routing prefix corresponding to each instance identifier, it can be determined how many CEs the corresponding VPN instance corresponds to, and the corresponding number of CEs can be added to the VPN topology, and the corresponding routing prefixes can be marked on the CEs. For the above-mentioned UPDATE message with indication information added, the corresponding CE may not be added to the VPN topology, or the corresponding CE may be added to the VPN topology, and a special mark, such as "×", can be set for the connection between the CE and the VPN instance.

[0220] Generally, when a VPN instance in a PE is just established but the PE has not yet connected to the CE corresponding to the VPN instance, the PE cannot send an UPDATE message corresponding to the VPN instance because the message cannot actually be forwarded to the CE. However, at this time, the VPN instance has been configured with ERT and IRT. In theory, the VPN instance and the corresponding inter-access relationship can be reflected in the VPN topology. In this case, the above method can be used to carry indication information in the UPDATE message. In this way, each network device will not process the UPDATE message, that is, it will not add the corresponding route to the routing table, while the controller will process the UPDATE message, that is, generate the VPN topology based on the route target in the UPDATE message. In this way, the real-time performance of the VPN topology can be improved.

[0221] In addition to the above application scenarios, in other application scenarios, when a PE does not need to announce routes to other PEs but needs to notify the controller of the route target, indication information can be added to the UPDATE message. For example, the administrator manually triggers the notification of the route target, etc. In this way, the redundant processing of each network device can be reduced in the process of establishing the VPN topology, and the processing resource occupation of each network device can be reduced.

[0222] For the case where there are multiple ASs in the network, the embodiment of the present disclosure provides a method for generating a VPN topology. If there is a connection in the first specified communication mode between VPN instances of different ASs, this method can be used to reflect this connection in the VPN topology. The embodiment of the present disclosure takes the case where multiple ASs include AS100 and AS200, and the first specified communication mode is option A as an example to illustrate the solution. Other cases are similar and will not be described in detail. The corresponding network architecture can be as follows: Fig. 9 The processing flow of this method can be as follows Fig.10 As shown, the following steps are included:

[0223] 1001. PE sends an UPDATE message.

[0224] The processing method of this step may refer to step 201.

[0225] 1002. The controller receives multiple UPDATE messages.

[0226] The processing method of this step may refer to step 202. The controller may receive UPDATE messages from PEs in multiple ASs.

[0227] 1003. The controller obtains first configuration information.

[0228] The first configuration information is used to indicate that there is an Option A connection between the two VPN instances VRF_B and VRF_C, and that PE2 to which VRF_B belongs and PE3 to which VRF_C belongs belong to different ASs, namely AS100 and AS200 (in this case, the two PEs are ASBRs of their respective ASs). The first configuration information can be obtained from the controller locally, or from other devices, and can be set by an administrator.

[0229] 1004. The controller generates a first VPN sub-topology based on the routing targets corresponding to the PEs included in AS100, and generates a second VPN sub-topology based on the routing targets corresponding to the PEs included in AS200.

[0230] The controller can determine the AS to which the PE corresponding to each UPDATE message belongs, obtain the routing target of the VPN instance in each AS, and generate the VPN sub-topology corresponding to each AS based on the routing target of the VPN instance in each AS. If the network includes other ASs besides AS100 and AS200, other ASs can also use the same processing method to determine the corresponding VPN sub-topology. For the processing of generating VPN sub-topology for each AS, please refer to Figure 2 The process shown and the related instructions.

[0231] 1005 , the controller connects VRF_B in the first VPN sub-topology and VRF_C in the second VPN sub-topology to obtain a VPN topology.

[0232] The display format of option A can be set based on actual needs, such as dotted lines, wavy lines, etc. The generated VPN topology can be as follows: Fig.11 shown.

[0233] For the case where there are multiple ASs in the network, the embodiment of the present disclosure provides a method for generating a VPN topology. If there is a connection of the second specified communication mode between VPN instances of different ASs, this method can be used to reflect this connection in the VPN topology. The embodiment of the present disclosure takes the case where multiple ASs include AS100 and AS200, and the second specified communication mode is option B / C as an example to illustrate the scheme. Other cases are similar and will not be described in detail. The corresponding network architecture can be as follows: Fig.12 The processing flow of this method can be as follows Fig.13 As shown, the following steps are included:

[0234] 1301. PE sends an UPDATE message.

[0235] The processing method of this step may refer to step 201.

[0236] 1302. The controller receives multiple UPDATE messages.

[0237] The processing method of this step may refer to step 202. The controller may receive UPDATE messages from PEs in multiple ASs.

[0238] 1303. The controller obtains second configuration information.

[0239] The second configuration information is used to instruct AS100 and AS200 to communicate across domains through option B / C. Fig.12 As shown, two VPN instances VRF_A and VRF_B in a VPN tunnel are in AS100 and AS200 respectively. PE1 to which VRF_A belongs and PE4 to which VRF_B belongs are not the ASBRs to which AS100 and AS200 are connected. The ASBRs to which AS100 and AS200 are connected are PE2 (ASBR1) and PE3 (ASBR2). No VPN instance belonging to the VPN tunnel is established in PE2 and PE3. The second configuration information may include the AS numbers of AS100 and AS200. The second configuration information may be obtained from the controller locally, or may be obtained from other devices, and may be set by an administrator.

[0240] 1304, when generating the VPN topology, the controller may regard AS100 and AS200 as the same AS, and generate the corresponding VPN topology based on the routing targets of the VPN instances of all PEs included in AS100 and AS200.

[0241] The controller can determine the AS to which the PE corresponding to each UPDATE message belongs, determine the UPDATE messages corresponding to AS100 and AS200, and then generate a VPN topology based on the routing targets of the VPN instances carried in these UPDATE messages. For the corresponding processing process, see the description of step 203. The generated VPN topology can be as follows: Fig.14 shown.

[0242] Based on the same technical concept, the embodiment of the present disclosure provides a device for generating a VPN topology, which can be applied to the above controller, such as Fig.15 As shown, the device comprises:

[0243] The receiving module 1510 is used to receive multiple BGP messages corresponding to multiple network devices, and can specifically implement the processing function of the above step 202 and other implicit steps.

[0244] The acquisition module 1520 is used to acquire the outbound routing target ERT and inbound routing target IRT of the VPN instances of multiple network devices based on multiple BGP messages, and can specifically implement the function of determining the ERT and IRT corresponding to each VPN instance in the above step 203, as well as other implicit steps.

[0245] The generation module 1530 is used to generate a VPN topology based on the ERT and IRT of the VPN instances of multiple network devices, where the VPN topology indicates the mutual access relationship between the VPN instances of multiple network devices. Specifically, the function of generating the VPN topology in the above step 203 and other implicit steps can be realized.

[0246] In a possible implementation, each BGP message carries the ERT and IRT of the VPN instance of the corresponding network device.

[0247] In one possible implementation, each BGP message is a BGP UPDATE message.

[0248] In a possible implementation, the ERT and IRT are carried in a path attribute field of a BGP UPDATE message.

[0249] In a possible implementation manner, the IRT is carried in the first extended community attribute field of the path attribute field.

[0250] In a possible implementation manner, the BGP UPDATE message further carries first indication information, where the first indication information is used to indicate that the BGP UPDATE message is only used to notify the ERT and IRT carried by the BGP UPDATE message.

[0251] In a possible implementation manner, the first indication information is carried in a path attribute field of a BGP UPDATE message.

[0252] In a possible implementation manner, the first indication information is carried in a second extended community attribute field of the path attribute field.

[0253] In a possible implementation, each BGP message carries the ERT of the VPN instance of the corresponding network device, and the acquisition module 1520 is further used to: acquire second indication information, the second indication information indicating that the IRT and ERT of the VPN instance of the network device corresponding to any BGP message are the same. The acquisition module 1520 is used to: extract the ERT of the VPN instance of the network device corresponding to any BGP message based on any BGP message, and set the IRT of the VPN instance of the network device corresponding to any BGP message to the ERT of the VPN instance of the network device corresponding to any BGP message.

[0254] In a possible implementation, the generation module 1530 is used to determine the connection relationship between the VPN instances of the multiple network devices based on the ERT and IRT of the VPN instances of the multiple network devices, and generate a VPN topology based on the connection relationship between the VPN instances of the multiple network devices.

[0255] In a possible implementation, the multiple BGP messages include a first BGP message and a second BGP message, the first BGP message corresponds to the first network device, and the second BGP message corresponds to the second network device. The generating module 1530 is used to: determine a first connection relationship between the first VPN instance and the second VPN instance based on the corresponding relationship between the ERT of the first VPN instance of the first network device and the IRT of the second VPN instance of the second network device, the first connection relationship indicating whether the second VPN instance can access the first VPN instance, and / or determine a second connection relationship between the first VPN instance and the second VPN instance based on the corresponding relationship between the IRT of the first VPN instance of the first network device and the ERT of the second VPN instance of the second network device, the second connection relationship indicating whether the first VPN instance can access the second VPN instance.

[0256] In a possible implementation, the generating module 1530 is configured to: when the ERT of the first VPN instance and the IRT of the second VPN instance include the same value option, determine that the second VPN instance can access the first VPN instance.

[0257] In a possible implementation, the generating module 1530 is configured to: when the IRT of the first VPN instance and the ERT of the second VPN instance include the same value option, determine that the first VPN instance can access the second VPN instance.

[0258] In a possible implementation, the network system to which the multiple network devices belong includes a first AS and a second AS, the multiple BGP messages include a third BGP message from the first AS and a fourth BGP message from the second AS, the third BGP message corresponds to a third VPN instance of a third network device, the fourth BGP message corresponds to a fourth VPN instance of a fourth network device, and the VPN topology also indicates that there is a connection of the first specified communication mode between the nodes corresponding to the third VPN instance and the fourth VPN instance.

[0259] In a possible implementation, the acquisition module 1520 is further used to: obtain first configuration information, the first configuration information indicating that there is a connection of the first specified communication mode between the third VPN instance and the fourth VPN instance. Specifically, the processing function of the above step 1003 and other implicit steps can be implemented. The generation module 1530 is used to: generate a first VPN sub-topology based on the ERT and IRT of the VPN instance of the network device included in the first AS. Generate a second VPN sub-topology based on the ERT and IRT of the VPN instance of the network device included in the second AS. Connect the third VPN instance in the first VPN sub-topology and the fourth VPN instance in the second VPN sub-topology to obtain a VPN topology, wherein the connection mode between the nodes corresponding to the third VPN instance and the fourth VPN instance is a connection of the first specified communication mode. Specifically, the processing functions of the above steps 1004-1005 and other implicit steps can be implemented.

[0260] In one possible implementation, the network system to which the multiple network devices belong includes a third AS and a fourth AS, the multiple BGP messages include a fifth BGP message from the third AS and a sixth BGP message from the fourth AS, the fifth BGP message corresponds to a fifth VPN instance of the fifth network device, the sixth BGP message corresponds to a sixth VPN instance of the sixth network device, and the VPN topology also indicates a mutual access relationship between the fifth VPN instance and the sixth VPN instance.

[0261] In a possible implementation, the acquisition module 1520 is also used to: obtain second configuration information, the second configuration information indicates that the third AS and the fourth AS communicate across domains through the second specified communication method. Specifically, the processing function of the above step 1303 and other implicit steps can be implemented. The generation module is used to: determine the mutual access relationship between the fifth VPN instance and the sixth VPN instance based on the corresponding relationship between the ERT of the fifth VPN instance and the IRT of the sixth VPN instance, and / or the corresponding relationship between the IRT of the fifth VPN instance and the ERT of the sixth VPN instance. Specifically, the processing function of the above step 1304 and other implicit steps can be implemented.

[0262] In a possible implementation, multiple BGP messages are sent by multiple network devices.

[0263] In a possible implementation manner, the multiple BGP messages are sent by at least one route reflector.

[0264] Based on the same technical concept, the embodiment of the present disclosure provides a device for generating a VPN topology, which can be applied to the above network devices, such as Fig.16As shown, the device includes: a sending module 1610, which is used to send a BGP message, wherein the BGP message carries a routing target of a VPN instance, the routing target is used to generate a VPN topology, and the VPN topology indicates the mutual access relationship of VPN instances in the network. Specifically, the processing function of the above step 201 and other implicit steps can be realized.

[0265] In a possible implementation, the routing target includes an outgoing routing target ERT and an incoming routing target IRT.

[0266] In a possible implementation, the BGP message is a BGP UPDATE message.

[0267] In a possible implementation, the route target is carried in a path attribute field of a BGP UPDATE message.

[0268] In a possible implementation manner, the IRT is carried in the first extended community attribute field of the path attribute field.

[0269] In a possible implementation manner, the BGP UPDATE message further carries first indication information, where the first indication information is used to indicate that the BGP UPDATE message is only used to notify the ERT and IRT carried by the BGP UPDATE message.

[0270] In a possible implementation, the VPN instance includes a first VPN instance, and the sending module 1610 is further configured to: before sending the BGP message, determine that a routing target of the first VPN instance changes.

[0271] In a possible implementation, the VPN instance includes a second VPN instance, and the sending module 1610 is further configured to: establish the second VPN instance before sending the BGP message.

[0272] In the disclosed embodiment, the routing targets of each VPN instance are collected through BGP messages to generate a VPN topology. In the process of generating the VPN topology, there is no need to parse the configuration files of each network device, so there will be no problem that the configuration files cannot be parsed, which can improve the accuracy of the VPN topology.

[0273] The device for generating VPN topology provided in the above embodiment only uses the division of the above functional modules as an example when generating VPN topology. In actual application, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the computer device is divided into different functional modules to complete all or part of the functions described above. In addition, the device for generating VPN topology provided in the above embodiment and the method embodiment for generating VPN topology belong to the same concept. The specific implementation process is detailed in the method embodiment and will not be repeated here.

[0274] The embodiments of the present disclosure also provide a computer-readable storage medium. The computer-readable storage medium may be any available medium that can be stored by a computing device or a data storage device such as a data center that includes one or more available media. The available medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a digital video disk (DVD)), or a semiconductor medium (e.g., a solid-state hard disk). The computer-readable storage medium includes instructions that instruct a computing device to perform a business processing method, or instructs a computing device to perform a business processing method.

[0275] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit it. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for generating a virtual private network VPN topology, characterized in that: The method comprises: Receiving a plurality of Border Gateway Protocol (BGP) messages, wherein the plurality of BGP messages correspond to a plurality of network devices; Acquire outbound routing targets ERT and inbound routing targets IRT of VPN instances of the multiple network devices based on the multiple BGP messages; A VPN topology is generated based on the ERT and IRT of the VPN instances of the multiple network devices, where the VPN topology indicates a mutual access relationship between the VPN instances of the multiple network devices.

2. The method according to claim 1, characterized in that Each BGP message carries the ERT and IRT of the VPN instance of the corresponding network device.

3. The method according to claim 2, characterized in that Each of the BGP messages is a BGP update UPDATE message.

4. The method according to claim 3, characterized in that The ERT and the IRT are carried in the path attribute field of the BGP UPDATE message.

5. The method according to claim 4, characterized in that The IRT is carried in the first extended community attribute field of the path attribute field.

6. The method according to any one of claims 3 to 5, characterized in that: The BGP UPDATE message also carries first indication information, where the first indication information is used to indicate that the BGP UPDATE message is only used to notify the ERT and IRT carried by the BGP UPDATE message.

7. The method according to claim 6, characterized in that The first indication information is carried in a path attribute field of the BGP UPDATE message.

8. The method according to claim 7, characterized in that The first indication information is carried in the second extended community attribute field of the path attribute field.

9. The method according to claim 1, characterized in that: Each BGP message carries the ERT of the VPN instance of the corresponding network device, and the method further includes: Acquire second indication information, where the second indication information indicates that an IRT and an ERT of a VPN instance of a network device corresponding to any BGP message are the same; The acquiring, based on the multiple BGP messages, the outbound routing targets ERT and the inbound routing targets IRT of the VPN instances of the multiple network devices comprises: The ERT of the VPN instance of the network device corresponding to the any BGP message is extracted based on the any BGP message, and the IRT of the VPN instance of the network device corresponding to the any BGP message is set as the ERT of the VPN instance of the network device corresponding to the any BGP message.

10. The method according to any one of claims 1 to 9, characterized in that: The generating of VPN topology based on the ERT and IRT of the VPN instances of the multiple network devices includes: Determine a connection relationship between the VPN instances of the multiple network devices based on the ERTs and IRTs of the VPN instances of the multiple network devices; The VPN topology is generated based on the connection relationship between the VPN instances of the multiple network devices.

11. The method according to claim 10, characterized in that The multiple BGP messages include a first BGP message and a second BGP message, the first BGP message corresponds to a first network device, and the second BGP message corresponds to a second network device, and the determining the connection relationship between the VPN instances of the multiple network devices based on the ERT and IRT of the VPN instances of the multiple network devices includes: Determining a first connection relationship between the first VPN instance and the second VPN instance based on a correspondence between an ERT of the first VPN instance of the first network device and an IRT of the second VPN instance of the second network device, wherein the first connection relationship indicates whether the second VPN instance can access the first VPN instance; and / or A second connection relationship between the first VPN instance and the second VPN instance is determined based on a correspondence between an IRT of the first VPN instance of the first network device and an ERT of the second VPN instance of the second network device, wherein the second connection relationship indicates whether the first VPN instance can access the second VPN instance.

12. The method according to claim 11, characterized in that The determining the first connection relationship between the first VPN instance and the second VPN instance based on the ERT of the first VPN instance of the first network device and the IRT of the second VPN instance of the second network device includes: When the ERT of the first VPN instance and the IRT of the second VPN instance include the same value option, it is determined that the second VPN instance can access the first VPN instance.

13. The method according to claim 11 or 12, characterized in that: The determining the second connection relationship between the first VPN instance and the second VPN instance based on the correspondence between the IRT of the first VPN instance of the first network device and the ERT of the second VPN instance of the second network device includes: When the IRT of the first VPN instance and the ERT of the second VPN instance include the same value option, it is determined that the first VPN instance can access the second VPN instance.

14. The method according to any one of claims 1 to 13, characterized in that: The network system to which the multiple network devices belong includes a first autonomous system AS and a second AS, the multiple BGP messages include a third BGP message from the first AS and a fourth BGP message from the second AS, the third BGP message corresponds to a third VPN instance of a third network device, the fourth BGP message corresponds to a fourth VPN instance of a fourth network device, and the VPN topology also indicates that there is a connection of a first specified communication mode between nodes corresponding to the third VPN instance and the fourth VPN instance.

15. The method according to claim 14, characterized in that The method further comprises: Acquire first configuration information, where the first configuration information indicates that a connection in the first specified communication mode exists between the third VPN instance and the fourth VPN instance; The generating of VPN topology based on the ERT and IRT of the VPN instances of the multiple network devices includes: generating a first VPN sub-topology based on the ERT and IRT of the VPN instance of the network device included in the first AS; generating a second VPN sub-topology based on the ERT and IRT of the VPN instance of the network device included in the second AS; The third VPN instance in the first VPN sub-topology and the fourth VPN instance in the second VPN sub-topology are connected to obtain the VPN topology, wherein a connection mode between nodes corresponding to the third VPN instance and the fourth VPN instance is a connection of the first designated communication mode.

16. The method according to any one of claims 1 to 15, characterized in that: The network system to which the multiple network devices belong includes a third AS and a fourth AS, the multiple BGP messages include a fifth BGP message from the third AS and a sixth BGP message from the fourth AS, the fifth BGP message corresponds to a fifth VPN instance of a fifth network device, the sixth BGP message corresponds to a sixth VPN instance of a sixth network device, and the VPN topology also indicates a mutual access relationship between the fifth VPN instance and the sixth VPN instance.

17. The method according to claim 16, characterized in that The method further comprises: Acquire second configuration information, where the second configuration information indicates that the third AS and the fourth AS communicate across domains through a second specified communication mode; The generating of VPN topology based on the ERT and IRT of the VPN instances of the multiple network devices includes: Based on the corresponding relationship between the ERT of the fifth VPN instance and the IRT of the sixth VPN instance, and / or the corresponding relationship between the IRT of the fifth VPN instance and the ERT of the sixth VPN instance, a mutual access relationship between the fifth VPN instance and the sixth VPN instance is determined.

18. The method according to any one of claims 1 to 17, characterized in that: The multiple BGP messages are sent by the multiple network devices.

19. The method according to any one of claims 1 to 17, characterized in that: The multiple BGP messages are sent by at least one route reflector.

20. A method for generating a virtual private network VPN topology, characterized in that: The method comprises: A Border Gateway Protocol (BGP) message is sent, wherein the BGP message carries a routing target of a VPN instance, the routing target is used to generate a VPN topology, and the VPN topology indicates a mutual access relationship between VPN instances in a network.

21. The method according to claim 20, characterized in that The routing targets include an outgoing routing target ERT and an incoming routing target IRT.

22. The method according to claim 20 or 21, characterized in that The BGP message is a BGP update UPDATE message.

23. The method according to claim 22, characterized in that The routing target is carried in the path attribute field of the BGP UPDATE message.

24. The method according to claim 23, characterized in that The IRT is carried in the first extended community attribute field of the path attribute field.

25. The method according to any one of claims 22 to 24, characterized in that: The BGP UPDATE message also carries first indication information, where the first indication information is used to indicate that the BGP UPDATE message is only used to notify the ERT and IRT carried by the BGP UPDATE message.

26. The method according to any one of claims 20 to 25, characterized in that: The VPN instance includes a first VPN instance. Before sending the BGP message, the method further includes: It is determined that a routing target of the first VPN instance changes.

27. The method according to any one of claims 20 to 25, characterized in that: The VPN instance includes a second VPN instance. Before sending the BGP message, the method further includes: The second VPN instance is established.

28. A device for generating a virtual private network VPN topology, characterized in that: The device comprises: A receiving module, used for receiving a plurality of Border Gateway Protocol (BGP) messages, wherein the plurality of BGP messages correspond to a plurality of network devices; An acquisition module, configured to acquire the outbound routing target ERT and the inbound routing target IRT of the VPN instances of the multiple network devices based on the multiple BGP messages; A generating module is used to generate a VPN topology based on the ERT and IRT of the VPN instances of the multiple network devices, wherein the VPN topology indicates the mutual access relationship of the VPN instances of the multiple network devices.

29. The device according to claim 28, characterized in that Each BGP message carries the ERT and IRT of the VPN instance of the corresponding network device.

30. The device according to claim 29, characterized in that Each of the BGP messages is a BGP update UPDATE message.

31. The device according to claim 30, characterized in that The ERT and the IRT are carried in the path attribute field of the BGPUPDATE message.

32. The device according to claim 31, characterized in that The IRT is carried in the first extended community attribute field of the path attribute field.

33. The device according to any one of claims 30 to 32, characterized in that The BGP UPDATE message also carries first indication information, where the first indication information is used to indicate that the BGP UPDATE message is only used to notify the ERT and IRT carried by the BGP UPDATE message.

34. The device according to claim 28, characterized in that Each BGP message carries the ERT of the VPN instance of the corresponding network device, and the acquisition module is further used to: Acquire second indication information, where the second indication information indicates that an IRT and an ERT of a VPN instance of a network device corresponding to any BGP message are the same; The acquisition module is used to: The ERT of the VPN instance of the network device corresponding to the any BGP message is extracted based on the any BGP message, and the IRT of the VPN instance of the network device corresponding to the any BGP message is set as the ERT of the VPN instance of the network device corresponding to the any BGP message.

35. The device according to any one of claims 28 to 34, characterized in that The generating module is used for: Determine a connection relationship between the VPN instances of the multiple network devices based on the ERTs and IRTs of the VPN instances of the multiple network devices; The VPN topology is generated based on the connection relationship between the VPN instances of the multiple network devices.

36. The device according to claim 35, characterized in that The multiple BGP messages include a first BGP message and a second BGP message, the first BGP message corresponds to a first network device, the second BGP message corresponds to a second network device, and the generating module is used to: Determine a first connection relationship between the first VPN instance and the second VPN instance based on a correspondence between an ERT of the first VPN instance of the first network device and an IRT of the second VPN instance of the second network device, wherein the first connection relationship indicates whether the second VPN instance can access the first VPN instance; and / or A second connection relationship between the first VPN instance and the second VPN instance is determined based on a correspondence between an IRT of the first VPN instance of the first network device and an ERT of the second VPN instance of the second network device, wherein the second connection relationship indicates whether the first VPN instance can access the second VPN instance.

37. The device according to claim 36, characterized in that The generating module is used for: When the ERT of the first VPN instance and the IRT of the second VPN instance include the same value option, it is determined that the second VPN instance can access the first VPN instance.

38. The device according to claim 36 or 37, characterized in that The generating module is used for: When the IRT of the first VPN instance and the ERT of the second VPN instance include the same value option, it is determined that the first VPN instance can access the second VPN instance.

39. The device according to any one of claims 28 to 38, characterized in that The network system to which the multiple network devices belong includes a first autonomous system AS and a second AS, the multiple BGP messages include a third BGP message from the first AS and a fourth BGP message from the second AS, the third BGP message corresponds to a third VPN instance of a third network device, the fourth BGP message corresponds to a fourth VPN instance of a fourth network device, and the VPN topology also indicates that there is a connection of a first specified communication mode between nodes corresponding to the third VPN instance and the fourth VPN instance.

40. The device according to claim 39, characterized in that The acquisition module is further used for: Acquire first configuration information, where the first configuration information indicates that a connection in the first specified communication mode exists between the third VPN instance and the fourth VPN instance; The generating module is used for: generating a first VPN sub-topology based on the ERT and IRT of the VPN instance of the network device included in the first AS; generating a second VPN sub-topology based on the ERT and IRT of the VPN instance of the network device included in the second AS; The third VPN instance in the first VPN sub-topology and the fourth VPN instance in the second VPN sub-topology are connected to obtain the VPN topology, wherein a connection mode between nodes corresponding to the third VPN instance and the fourth VPN instance is a connection of the first designated communication mode.

41. The device according to any one of claims 28 to 40, characterized in that The network system to which the multiple network devices belong includes a third AS and a fourth AS, the multiple BGP messages include a fifth BGP message from the third AS and a sixth BGP message from the fourth AS, the fifth BGP message corresponds to a fifth VPN instance of a fifth network device, the sixth BGP message corresponds to a sixth VPN instance of a sixth network device, and the VPN topology also indicates a mutual access relationship between the fifth VPN instance and the sixth VPN instance.

42. The device according to claim 41, characterized in that The acquisition module is further used for: Acquire second configuration information, where the second configuration information indicates that the third AS and the fourth AS communicate across domains through a second specified communication mode; The generating module is used for: Based on the corresponding relationship between the ERT of the fifth VPN instance and the IRT of the sixth VPN instance, and / or the corresponding relationship between the IRT of the fifth VPN instance and the ERT of the sixth VPN instance, a mutual access relationship between the fifth VPN instance and the sixth VPN instance is determined.

43. A device for generating a virtual private network VPN topology, characterized in that: The device comprises: The sending module is used to send a Border Gateway Protocol BGP message, wherein the BGP message carries a routing target of a VPN instance, the routing target is used to generate a VPN topology, and the VPN topology indicates the mutual access relationship of VPN instances in the network.

44. The device according to claim 43, characterized in that The routing targets include an outgoing routing target ERT and an incoming routing target IRT.

45. The device according to claim 43 or 44, characterized in that The BGP message is a BGP update UPDATE message.

46. ​​The device according to claim 45, characterized in that The routing target is carried in the path attribute field of the BGP UPDATE message.

47. The device according to claim 46, characterized in that The IRT is carried in the first extended community attribute field of the path attribute field.

48. A computer device, characterized in that: The computer device comprises a memory and a processor, wherein the memory is used to store computer instructions; The processor executes the computer instructions stored in the memory to enable the computer device to perform the method according to any one of claims 1 to 27.

49. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program code. When the computer program code is executed by a computer device, the computer device executes the method according to any one of claims 1 to 27.

Images