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

Abstract

The embodiments of the present disclosure relate to the technical field of communications. Provided are a method and apparatus for generating VPN topology, and a device and a storage medium. In the embodiments of the present disclosure, a routing target of each VPN instance is collected by means of a BGP message, so as to generate VPN topology. In the process of generating VPN topology, it is not necessary to analyze configuration files of network devices, so that there is no problem of it not being possible to analyze the configuration files, and the accuracy of the VPN topology can be improved.

Description

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

[0001] This disclosure claims priority to Chinese patent application number 202311160626.4, filed on September 7, 2023, entitled “Method, Apparatus, Device and Storage Medium for Generating VPN Topology,” the entire contents of which are incorporated herein by reference. Technical Field

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

[0003] VPN topology effectively represents the connection relationships between VPN nodes and is widely used in network operations and maintenance. Related technologies for constructing VPN topologies involve manually logging into the corresponding routing device to obtain configuration files and then generating the VPN topology based on the relevant information in the configuration files. However, due to the varying formats of configuration files across different vendors, it's impossible to automatically parse the configuration files and obtain relevant information using a unified standard. This results in some routing device configuration files being unable to be parsed, leading to inaccurate VPN topologies.

[0004] Summary of the Invention

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

[0006] In a first aspect, a method for generating a VPN topology is provided. The method includes receiving multiple Border Gateway Protocol (BGP) messages, the multiple BGP messages corresponding to multiple network devices, obtaining export route targets (ERTs) and import route targets (IRTs) of VPN instances of the multiple network devices based on the multiple BGP messages, and generating a VPN topology based on the ERTs and IRTs of the VPN instances of the multiple network devices. The VPN topology indicates inter-access relationships between the VPN instances of the multiple network devices.

[0007] The operations of receiving BGP messages, obtaining routing targets, and generating VPN topologies can be performed by any device, such as a controller, any network device, or any other computer device other than a controller or network device. The plurality of network devices may include several network devices, each of which corresponds to multiple BGP messages, or several network devices, each of which corresponds to one BGP message.

[0008] This solution uses BGP messages to collect the routing targets of each VPN instance to generate the VPN topology. This process eliminates the need to parse the configuration files of each network device, eliminating the issue of configuration files being unable to be parsed. This improves the accuracy of VPN topology acquisition.

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

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

[0011] In one possible implementation, each BGP message is a BGP update (UPDATE) message.

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

[0013] In this way, by leveraging the flexibility of BGP UPDATE messages, which can be sent in real time, the real-time nature of route target announcements can be improved, thereby facilitating the improvement of the real-time nature of VPN topology.

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

[0015] 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 or in the same type of extension field.

[0016] 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.

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

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

[0019] In one 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, informing each network device that there is no need 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. Only devices that need to generate a VPN topology need to process the routing target in the UPDATE message.

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

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

[0022] 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.

[0023] In this way, carrying the first indication information in the path attribute field through a certain type of extended field and carrying the first indication information in the BGP UPDATE message has higher flexibility.

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

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

[0026] 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.

[0027] In this way, when the first indication information is carried in the message, higher flexibility is achieved.

[0028] In one possible implementation, each BGP message carries the ERT of the VPN instance of the corresponding network device. Furthermore, second indication information can be obtained, and through the second indication information, it can be determined 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 VPN instances of multiple network devices, the following operation can be performed: based on any BGP message, the ERT of the VPN instance of the network device corresponding to the BGP message is extracted, and the IRT of the VPN instance of the network device corresponding to the BGP message is set to the ERT of the VPN instance of the network device corresponding to the BGP message.

[0029] The second indication information may be obtained from the current device or another device, and may be configured by an administrator.

[0030] In this way, BGP messages do not need to carry IRT, which can save transmission resources.

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

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

[0033] In one 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, 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 a corresponding relationship 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, 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 a 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.

[0034] The corresponding relationship can 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, etc.

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

[0036] 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.

[0037] Each piece of routing information includes an ERT list and an IRT list for 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 lists of two VPN instances, if the ERT list of the first VPN instance matches the IRT list of the second VPN instance, the comparison is considered successful, confirming that the second VPN instance can access the first VPN instance.

[0038] 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.

[0039] Each piece of routing information includes the ERT list and 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 values ​​of two VPN instances, if the IRT list of the first VPN instance matches the ERT list of the second VPN instance, the comparison is considered successful, confirming that the first VPN instance can access the second VPN instance.

[0040] In one 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 a third network device, and the fourth BGP message corresponds to a fourth VPN instance of a fourth network device. Accordingly, the generated VPN topology may further indicate that a connection using a first specified communication method exists between nodes corresponding to the third and fourth VPN instances.

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

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

[0043] In one possible implementation, the process before generating the VPN topology may further include: obtaining first configuration information, wherein the first configuration information indicates that a connection using a first specified communication mode exists 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 instances of the network devices included in the first AS, generating a second VPN sub-topology based on the ERT and IRT of the VPN instances of the network devices included in the second AS, and connecting the third VPN instance in the first VPN sub-topology with 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 using the first specified communication mode.

[0044] The first configuration information can be obtained from the device itself or from another device and can be configured by the administrator. The controller determines the AS to which the network device corresponding to each UPDATE message belongs, obtains the ERT and IRT of the VPN instance in each AS, and generates a VPN subtopology corresponding to each AS based on the ERT and IRT of the VPN instance in each AS. Based on each VPN subtopology, an edge corresponding to Option A is added. The edge display format can be set based on actual needs, such as a dashed line or a wavy line.

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

[0046] 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 a fifth network device, and the sixth BGP message corresponds to a sixth VPN instance of a sixth network device. Accordingly, the generated VPN topology may further indicate a mutual access relationship between the fifth VPN instance and the sixth VPN instance.

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

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

[0049] In one possible implementation, the process before generating the VPN topology may further include: obtaining second configuration information, where the second configuration information instructs the third AS and the fourth AS to communicate across domains using a second specified communication mode. After obtaining the second configuration information, the process of generating the VPN topology may include: determining a mutual access relationship between the fifth VPN instance and the sixth VPN instance based on a corresponding relationship between the ERT of the fifth VPN instance and the IRT of the sixth VPN instance, and / or a corresponding relationship between the IRT of the fifth VPN instance and the ERT of the sixth VPN instance.

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

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

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

[0053] A network device can be a provider edge (PE), a customer edge (CE), or a non-edge device. The network device sends BGP messages directly to the recipient. The network device and the recipient have a pre-established BGP neighbor relationship. After generating a BGP message, the network device sends the message to all BGP neighbors, including the recipient. This ensures that all BGP messages from each network device are sent to the recipient.

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

[0055] A network device sends a BGP message to its corresponding route reflector. The route reflector has a pre-established BGP neighbor relationship with the BGP message receiver (for example, a controller). After receiving the BGP message, the route reflector sends the BGP message to all its BGP neighbors, including the BGP message receiver. In this way, the BGP messages corresponding to each network device can ultimately be sent to the BGP message receiver.

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

[0057] 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 the mutual access relationship of VPN instances in a network.

[0058] There are several possible ways of sending, for example, sending to the controller via RR, or sending directly.

[0059] In this way, the routing targets of each VPN instance are collected through BGP messages to generate the 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 is no problem of configuration files being unable to be parsed, which can improve the accuracy of VPN topology acquisition.

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

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

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

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

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

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

[0066] In one 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, informing each network device that it does not need to process the BGP UPDATE message, and does not need to add the routing prefix in the BGP UPDATE message to the routing table. Only the controller processes the routing target in the UPDATE message.

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

[0068] In one possible implementation, the triggering 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.

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

[0070] 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 helpful to improve the real-time performance of the VPN topology.

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

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

[0073] 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 conducive to improving the real-time performance of the VPN topology.

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

[0075] In a fourth aspect, a device for generating a VPN topology is provided. The device includes 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.

[0076] In a fifth aspect, a computer device is provided, comprising a memory and a processor, wherein the memory is configured to store computer instructions and the processor executes the computer instructions stored in the memory to cause the computer device to perform the method provided in the first aspect and possible implementations thereof.

[0077] In a sixth aspect, a computer device is provided, comprising a memory and a processor, wherein the memory is configured to store computer instructions. The processor executes the computer instructions stored in the memory to cause the computer device to perform the method provided in the second aspect and possible implementations thereof.

[0078] In a seventh aspect, a computer-readable storage medium is provided, which stores 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.

[0079] In an eighth aspect, a computer-readable storage medium is provided, which stores 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.

[0080] In a ninth aspect, a computer program product is provided, which includes 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.

[0081] In a tenth aspect, a computer program product is provided, which includes 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. BRIEF DESCRIPTION OF THE DRAWINGS

[0082] FIG1 is a schematic structural diagram of a controller provided by an embodiment of the present disclosure;

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

[0084] FIG3 is a network architecture diagram of a full-mesh network provided in an embodiment of the present disclosure;

[0085] FIG4 is a network architecture diagram of a hub-spoke network provided in an embodiment of the present disclosure;

[0086] FIG5 is a schematic diagram of the format of an UPDATE message provided in an embodiment of the present disclosure;

[0087] FIG6 is a VPN topology diagram provided by an embodiment of the present disclosure;

[0088] FIG7 is a VPN topology diagram provided by an embodiment of the present disclosure;

[0089] FIG8 is a diagram of a network architecture provided by an embodiment of the present disclosure;

[0090] FIG9 is a diagram of a network architecture provided by an embodiment of the present disclosure;

[0091] FIG10 is a flow chart of a method for generating a VPN topology according to an embodiment of the present disclosure;

[0092] FIG11 is a VPN topology diagram provided in an embodiment of the present disclosure;

[0093] FIG12 is a diagram of a network architecture provided by an embodiment of the present disclosure;

[0094] FIG13 is a flow chart of a method for generating a VPN topology according to an embodiment of the present disclosure;

[0095] FIG14 is a VPN topology diagram provided in an embodiment of the present disclosure;

[0096] FIG15 is a schematic structural diagram of an apparatus for generating a VPN topology according to an embodiment of the present disclosure;

[0097] FIG16 is a schematic structural diagram of an apparatus for generating a VPN topology according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0098] The present disclosure provides a method for generating a VPN topology. The following explains some of the terms used in this method:

[0099] Network equipment

[0100] A network device is a device used for message forwarding in a network. It can be a provider edge device (PE), a customer edge device (CE), or a non-edge device. This disclosure primarily uses a PE as an example to describe the solution. Other scenarios are similar and are not described in detail here.

[0101] VPN instance

[0102] A VPN instance, also known as a virtual routing forwarding (VRF), can be considered a virtual router used to build a VPN and a transit node within the VPN. For example, VPN instances in carrier networks are typically established on PEs. A PE can establish and maintain one or more VPN instances.

[0103] Route target (RT)

[0104] Route targets include ERTs and IRTs. 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, a connection exists between VPN instance B and 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, a connection exists between VPN instance C and VPN instance D, indicating that VPN instance D can access VPN instance C.

[0105] BGP messages

[0106] Various messages defined by the BGP protocol. In the disclosed embodiments, the BGP messages used to transmit routing targets may be BGP UPDATE messages or HELLO messages. The disclosed embodiments use the BGP UPDATE message as an example for illustration; other scenarios are similar and will not be described in detail. The BGP messages in the disclosed embodiments may be multiprotocol extensions for border gateway protocol (MP-BGP) messages.

[0107] BGP UPDATE message (referred to as UPDATE message)

[0108] UPDATE messages are used by network devices to announce routing information. They carry routing information such as the RD, nexthop, prefix, and ERT. The RD identifies the VPN instance to which the routing information corresponds. The nexthop is the Internet Protocol (IP) address of the outbound interface on the PE that sends the UPDATE message. The prefix is ​​the address of the user network to which the VPN instance is connected.

[0109] 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.

[0110] VPN topology

[0111] A VPN topology is used to present the connection relationships between VPN instances, indicating the mutual access relationships between VPN instances of multiple network devices in a network, or indicating the mutual access relationships between sites (which can be simply referred to as VPN sites) to which VPN instances belong. In a VPN topology, VPN instances are represented by nodes, and the connection relationships between VPN instances are represented by edges between nodes. Optionally, edges in a 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 from VPN instance A, or vice versa. Optionally, edges in a VPN topology can also be undirected. For example, VPN instance A and VPN instance B are connected by a line segment without an arrowhead, indicating that VPN instance A and VPN instance B can access each other.

[0112] Autonomous system (AS)

[0113] An AS is a collection of network devices organized by entities such as carriers, organizations, and companies. Each AS can contain multiple network devices. These entities can each apply for their own AS number to establish an AS.

[0114] Route reflectors (RRs)

[0115] RRs advertise routing information for several network devices (e.g., PEs) for which they are responsible. Upon receiving an UPDATE message from a PE, an RR forwards (also known as reflects) the UPDATE message to all of its BGP neighbors. An AS can have one or more RRs.

[0116] Full-mesh networking

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

[0118] Hub-spoke networking

[0119] 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 hub VPN instances, and there are VPN connections between all hub VPN instances.

[0120] Autonomous system boundary router (ASBR)

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

[0122] 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. The network devices may be responsible for providing relevant information for generating the VPN topology. The VPN topology generation process can be performed by any device, such as the controller, any network device, or any other computer device other than the controller or network devices. The present disclosure uses the controller as an example to describe the detailed solution. Other scenarios are similar and will not be elaborated upon.

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

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

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

[0126] 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, etc.

[0127] The present disclosure provides a method for generating a VPN topology. The method process is shown in FIG2 (for schematic diagrams of related network architectures and VPN topologies, see the examples in the following content). The method may include the following steps:

[0128] 201. PE sends an UPDATE message.

[0129] 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 network), the ERT and IRT of any VPN instance are the same, such as the full-mesh network. For this type of network, the routing target carried in the UPDATE message can only include the ERT. In other networks (which can be called the second type of network), the ERT and IRT of any VPN instance are not necessarily the same, such as the hub-spoke network. For this type of network, the routing target carried in 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.

[0130] There are many possible ways to trigger the PE to send an UPDATE message. The following are some of the possible triggering methods:

[0131] Method 1: Receiving a trigger notification. The trigger notification can be sent by an administrator using a management terminal to the PE.

[0132] 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.

[0133] Method 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 route target may be due to configuration operations performed by the user or network administrator.

[0134] The HELLO message can also be triggered in mode 4, periodic triggering. Every specified period (e.g., 5 minutes), the PE sends a HELLO message carrying the routing target of the VPN instance in the PE. If the PE has multiple VPN instances, multiple HELLO messages can be sent separately.

[0135] Optionally, in actual applications, a "first trigger" can be performed first, that is, trigger method 1 is used to trigger each PE in the network to send an UPDATE message. At this time, each PE sends the UPDATE message almost at the same time, and subsequently each PE uses trigger method 2 and trigger method 3 to trigger the sending of the UPDATE message.

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

[0137] Method 1: Sending to the controller through the RR. A PE sends an UPDATE message to its corresponding RR. The RR and the controller have a pre-established BGP neighbor relationship. After receiving the UPDATE message, the RR sends the UPDATE message to all BGP neighbors, including the controller. In this way, the UPDATE message corresponding to each PE can ultimately be sent to the controller.

[0138] In the second transmission method, the PE sends the update message directly to the controller. The PE and the controller have a pre-established BGP neighbor relationship. After generating an UPDATE message, the PE sends the UPDATE message to all BGP neighbors, including the controller. In this way, the UPDATE message corresponding to each PE can be sent to the controller.

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

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

[0141] 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 a preset duration (such as 5 minutes), the controller can proceed to the subsequent step 203 based on the UPDATE message received during the timing process. Alternatively, the processing of step 203 may not adopt the timing triggering method, but may adopt the manual operation triggering method, with the administrator operating the management terminal to send a topology generation notification to the controller. After the controller receives the topology generation notification, it proceeds to the subsequent step 203 based on the UPDATE message received between the trigger notification and the topology generation notification.

[0142] In the subsequent process, the controller will randomly receive UPDATE messages sent by any PE. Each time an UPDATE message is received, the controller can perform the subsequent processing in step 203 based on the UPDATE message. In this way, the VPN topology can be updated immediately when 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 does not consider whether the route target has changed), it can better ensure the real-time performance of the VPN topology.

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

[0144] 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.

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

[0146] The following methods are available: Method 1: Combining the RD and nexthop as the instance identifier; Method 2: Using the nexthop to query the physical identity document (ID) of the corresponding PE and combining the physical ID with the RD as the instance identifier; Method 3: Using the RD as the instance identifier. Method 3 is applicable when the RDs of all VPN instances in the network are different, while Methods 1 and 2 are applicable to all situations. In addition to the three methods mentioned above, there are many other methods for confirming instance identifiers, which are not detailed here.

[0147] 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.

[0148] The method can 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, randomly retain one piece of content information; 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, retain the piece of content information including ERT and IRT, and remove the other content information that does not include IRT; Method 3, for multiple pieces of content information corresponding to the same instance identifier, multiple pieces of content information include ERT and IRT. In this case, randomly retain one piece of content information.

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

[0150] For the first type of networking described above, the ERT and IRT of any VPN instance are identical. The routing target in the UPDATE message content can include only the ERT. In this case, the same IRT can be determined based on the ERT in the routing target, that is, the IRT can be set to the ERT. For the second type of networking described above, the ERT and IRT of any VPN instance can be different. The routing target in the UPDATE message content can include both the ERT and IRT. In this case, the ERT and IRT can be directly retrieved from the content information. Furthermore, by combining the instance identifier corresponding to each piece of content information, the correspondence between the instance identifier and the ERT and IRT can be determined, that is, the ERT and IRT corresponding to each VPN instance can be determined.

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

[0152] 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 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 controller can 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 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.

[0153] When the ERT of the first VPN instance and the IRT of the second VPN instance include the same value option, 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 option, the controller can determine that the first VPN instance can access the second VPN instance.

[0154] Optionally, the edges of the VPN topology are directed, either unidirectional or bidirectional. An ERT for a first VPN instance is equal to an IRT for a second VPN instance, indicating that the second VPN instance can access the first VPN instance, or in other words, that the second VPN instance is reachable from the first VPN instance. 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 can be 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 can be 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. If the IRT of a first VPN instance is equal to the ERT of a second VPN instance, indicating that the first VPN instance can access the second VPN instance, or that the first VPN instance is reachable from the second VPN instance, a directed edge can be set between the first and second nodes. For example, an edge (which can be represented as a one-way arrow) can be set from the second node to the first node to indicate that the first VPN instance can access the second VPN instance, or an edge (which can be represented as a one-way arrow) can be set from the first node to the second node to indicate that the first VPN instance can access the second VPN instance. If the ERT of the first VPN instance is equal to the IRT of the second VPN instance, and the IRT of the first VPN instance is equal to the ERT of the second VPN instance, the edge between the first and second nodes can be set as bidirectional (which can be represented as a bidirectional arrow) to indicate that the first and second VPN instances can access each other, or that the second VPN instance is reachable from the first VPN instance and the first VPN instance is reachable from the second VPN instance.

[0155] Optionally, the VPN topology can also include routing prefixes corresponding to each VPN instance to indicate which networks are reachable between the VPN instances. For example, if a first VPN instance and a 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, then 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.

[0156] 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 item, and each routing information item includes an ERT list and an IRT list for 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), if the ERT list of VPN instance C matches the IRT list of VPN instance D, the comparison is considered successful, meaning that VPN instance D can access VPN instance C. For example, VPN instance C's ERT list is {100:200, 100:300, 100:400}, and its IRT list is {100:500, 100:600, 100:700}. VPN instance D's ERT list is {100:500, 100:800, 100:900}, and its IRT list is {100:200, 200:100, 200:200}. Comparison shows that both the ERT list of VPN instance C and the IRT list of VPN instance D contain the value 100:200, indicating that 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 the value 100:500, indicating that 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.

[0157] The specific processing in step 203 is described using the "first trigger" process as an example. During this process, the controller must process a large number of UPDATE messages. After the "first trigger" process, the controller updates the VPN topology based on each UPDATE message it receives. Specifically, the controller first determines the ERT and IRT corresponding to a VPN instance based on the UPDATE message. It then compares the ERT and IRT corresponding to that VPN instance with those corresponding to each other VPN instance to re-determine the connection relationship between that VPN instance and the other VPN instances, thereby updating the VPN topology.

[0158] In addition, PE will also send an UPDATE message when deleting a route. When the controller receives the UPDATE message for deleting a route (i.e., deleting a route prefix), it determines the VPN instance corresponding to the UPDATE message. If, after deleting the route prefix, the VPN instance does not have 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.

[0159] The above method collects the routing targets of each VPN instance through BGP messages to generate the VPN topology. During the VPN topology generation process, there is no need to parse the configuration files of each network device, so there is no problem of configuration files being unable to be parsed, which can improve the accuracy of the VPN topology.

[0160] The following is a specific description of the related processing for the above-mentioned first type of networking (the ERT and IRT of any VPN instance in the network are the same) and the second type of networking (the ERT and IRT of any VPN instance in the network are not necessarily the same). The first type of networking takes the full-mesh networking as an example (the corresponding network architecture is shown in Figure 3, in which 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), and the second type of networking takes the hub-spoke networking as an example (the corresponding network architecture is shown in Figure 4, in which 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 this disclosure will no longer elaborate on other networking one by one.

[0161] The PE and controller can each obtain configuration information, which can be obtained from the device itself or from other designated devices. Networking indication information can be obtained from the configuration information, and the networking indication information is used to indicate the network architecture. After the PE and controller determine that the network architecture is a full-mesh network based on the networking indication information, they can decide to use the processing method in Example 1. After the PE and controller determine that the network architecture is a hub-spoke network based on the networking indication information, they can decide to use the processing method in Example 2. Alternatively, the processing method in Example 2 can be used in all networks.

[0162] Example 1: Full-mesh Networking

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

[0164] The format of the UPDATE message is shown in Figure 5 and 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 attribute 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 the Attribute Flag (Attr.Flags) field and the Attribute Type Code (Attr.Type Code) field. The Attr.Flags field is used to carry some common attribute parameter information, such as an attribute parameter indicating whether the extended community attribute field is optional or mandatory, or an attribute parameter indicating the length of the Attr.Length field. The Attr.Value field may further include the Type high, Type low, and Value fields.

[0165] 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).

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

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

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

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

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

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

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

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

[0174] 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 corresponding relationship between instance identifier, ERT, and IRT can be obtained as follows:

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

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

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

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

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

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

[0181] At this point, we can confirm that there are six VPN instances. We compare the ERT and IRT of these six VPN instances, and the results are as follows:

[0182] VRF_D's ERT matches VRF_E's IRT and VRF_F's IRT. This confirms that VRF_E can access VRF_D, VRF_F can access VRF_D, and so on. (The process for determining inter-access relationships between other VPN instances is similar and is not listed here.) Based on the inter-access relationships between VPN instances, the VPN topology shown in Figure 6 is obtained.

[0183] Example 2: Hub-spoke Networking

[0184] When a PE determines that the ERT and / or IRT of a VPN instance has changed, it can send an UPDATE message. UPDATE messages can be sent in the following scenarios: Scenario 1: If only the ERT has changed, the ERT can be included in the UPDATE message (in this case, the IRT can also be included); Scenario 2: If only the IRT has changed, both the ERT and IRT can be included in the UPDATE message (in this case, the ERT can also be omitted; in this case, only the controller processes the UPDATE message, not the network devices); Scenario 3: If both the ERT and IRT have changed, both can be included in the UPDATE message.

[0185] When adding ERT to an UPDATE message, ERT can be added to an extended field of the UPDATE message. The addition method is the same as in Example 1. Please refer to the relevant content in Example 1. When adding IRT to an UPDATE message, IRT can be added to another extended field of the UPDATE message. The following describes it in detail:

[0186] The Path Attributes field of the UPDATE message can be used for message extension. An extended community attribute field (referred to as the first extended community attribute field) can be defined in the Path Attributes field. The structure of the first extended community attribute field is similar to the structure of the extended community attribute field carrying ERT described above, and reference can be made to the above-mentioned related content. For the first extended community attribute field, a value combination of the Type high field and the Type low field can be predefined (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 community attribute field is used to carry IRT. The second value combination can be arbitrarily selected from all undefined value combinations.

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

[0188] 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.

[0189] When adding an IRT to an UPDATE message, if a VPN instance corresponds to multiple prefixes, an UPDATE message is sent for each prefix. A prefix (referred to as prefix1) is pre-selected (perhaps randomly selected) and the IRT is added to the UPDATE message corresponding to prefix1. After prefix1 is revoked, a new prefix (referred to as prefix2) is selected and the IRT is subsequently added to the UPDATE message corresponding to prefix2.

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

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

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

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

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

[0195] 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, the one piece of content information that includes the ERT and IRT is retained, and all other pieces of content information that do not include the IRT are removed. The ERT and IRT are then directly obtained from the remaining pieces of content information. This yields the corresponding relationship between the instance identifier, ERT, and IRT, as follows:

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

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

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

[0199] At this point, we can confirm that there are three VPN instances. We compare the ERT and IRT of these three VPN instances, and the results are as follows:

[0200] VRF_A's ERT matches both VRF_B's IRT and VRF_C's IRT. This confirms that VRF_B can access VRF_A and that VRF_C can access VRF_A. VRF_B's ERT matches VRF_A's IRT, confirming that VRF_A can access VRF_B. VRF_C's ERT matches VRF_A's IRT, confirming that VRF_A can access VRF_C. Thus, the VPN topology shown in Figure 7 is obtained.

[0201] In an 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.

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

[0203] An extended community attribute field (referred to as a second extended community attribute field) can be defined in the Path Attributes field of the UPDATE message. The structure of the second extended community attribute field is similar to that of the extended community attribute field carrying ERT, and reference can be made to the relevant content above. For the second extended community attribute field, a value combination of the Type high field and the Type low field can be predefined (referred to as a third value combination). The third value combination can be arbitrarily selected from all undefined value combinations, and the third value combination should be different from the second value combination.

[0204] When adding indication information to an UPDATE message, the Attr.Type Code field can be set to 16, and the Type high and Type low fields can be set to a third value combination. In this case, the third value combination can be considered the indication information. In addition, the IRT can be added to the Value field. That is, for an UPDATE message that includes the second extended community attribute field, the first extended community attribute field can be omitted. Alternatively, another processing method can be adopted: the first extended community attribute field can still be added to the UPDATE message to carry the IRT, while the Value field of the second extended community attribute field is left blank.

[0205] 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.

[0206] The following uses the network architecture shown in Figure 4 as an example to explain the use of indication information in detail. In this network architecture, each VPN instance corresponds to multiple CEs, and the PE to which the VPN instance belongs has not yet established a physical connection with one of the CEs. As shown in Figure 8, a dotted line indicates that a connection has been established between the PE and CE, while a dotted line with a cross indicates that a connection has not yet been established between the PE and CE. In the figure, VRF_A, VRF_B, and VRF_C are three VPN instances, and their corresponding RDs are 100:1, 100:2, and 100:3, respectively. The controller receives UPDATE messages from each PE and obtains the following information about the content of each UPDATE message:

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

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

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

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

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

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

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

[0214] Among them, extended-community:IRT_Advertisement indicates that the corresponding UPDATE message carries the above-mentioned 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 the PE has already connected, the PE sends an UPDATE message without indication information, and for the CE to which the PE has not yet connected, the PE sends an UPDATE message carrying indication information.

[0215] 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 the ERT and IRT from the remaining content information. In this way, the corresponding relationship between the instance identifier, ERT, and IRT can be obtained as follows:

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

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

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

[0219] Comparing the ERT and IRT of the three VPN instances reveals the following results:

[0220] VRF_A's ERT matches both VRF_B's IRT and VRF_C's IRT. This confirms that VRF_B can access VRF_A and that VRF_C can access VRF_A. VRF_B's ERT matches VRF_A's IRT, confirming that VRF_A can access VRF_B. VRF_C's ERT matches VRF_A's IRT, confirming that VRF_A can access VRF_C. Thus, the VPN topology shown in Figure 7 is obtained.

[0221] Optionally, in addition to presenting the mutual access relationship between VPN instances, the VPN topology may also present the connection relationship between the VPN instance and the corresponding CE. Based on the routing prefix corresponding to each instance identifier, the number of CEs corresponding to the corresponding VPN instance may be determined, and the corresponding number of CEs may be added to the VPN topology, and the corresponding routing prefixes may be annotated on the CEs. For the UPDATE message with the aforementioned indication information, the corresponding CE may not be added to the VPN topology. Alternatively, the corresponding CE may be added to the VPN topology and a special mark, such as "×," may be set for the connection between the CE and the VPN instance.

[0222] Typically, when a VPN instance is newly established on a PE but the PE has not yet connected to the corresponding CE, the PE cannot send an UPDATE message for that VPN instance because the message cannot be forwarded to the CE. However, at this point, the VPN instance has already been configured with ERT and IRT. Theoretically, the VPN instance and the corresponding inter-access relationships are already reflected in the VPN topology. In this case, the aforementioned method can be used to include indication information in the UPDATE message. This way, network devices do not process the UPDATE message and, therefore, do not add the corresponding route to their routing tables. Instead, the controller processes the UPDATE message and generates the VPN topology based on the route target in the UPDATE message. This improves the real-time performance of the VPN topology.

[0223] In addition to the aforementioned application scenarios, in other scenarios where a PE does not need to advertise routes to other PEs but does need to notify the controller of the route's destination, instructions can be added to the UPDATE message. For example, an administrator manually triggers notification of the route's destination. This reduces redundant processing on each network device during VPN topology establishment, reducing the processing resources consumed by each device.

[0224] For situations where there are multiple ASs in a network, an embodiment of the present disclosure provides a method for generating a VPN topology. If a connection using a first specified communication method exists between VPN instances in different ASs, this method can be used to reflect this connection in the VPN topology. This embodiment of the present disclosure uses the example of multiple ASs including AS100 and AS200, and the first specified communication method being option A, to illustrate the solution. Other similar situations will not be described in detail. The corresponding network architecture can be shown in Figure 9. The processing flow of this method can be shown in Figure 10, including the following steps:

[0225] 1001. PE sends an UPDATE message.

[0226] The processing method of this step can refer to step 201.

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

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

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

[0230] The first configuration information indicates that an Option A connection exists between VPN instances VRF_B and VRF_C. PE2 to VRF_B and PE3 to VRF_C belong to different ASes, namely, AS100 and AS200 (in this case, these two PEs are the ASBRs of their respective ASes). The first configuration information can be obtained locally from the controller or from another device and can be configured by the administrator.

[0231] 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 .

[0232] The controller can determine the AS to which the PE corresponding to each UPDATE message belongs, obtain the route target of the VPN instance in each AS, and generate the VPN sub-topology corresponding to each AS based on the route target of the VPN instance in each AS. If the network includes other ASs besides AS100 and AS200, the corresponding VPN sub-topologies can be determined in the same manner for these other ASes. For the process of generating VPN sub-topologies for each AS, please refer to the flow and related descriptions shown in Figure 2.

[0233] 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.

[0234] The display format of Option A's connection can be set arbitrarily based on actual needs, such as a dotted line, a wavy line, etc. The generated VPN topology can be shown in Figure 11.

[0235] For situations where there are multiple ASs in a network, the present disclosure provides a method for generating a VPN topology. If a connection using a second specified communication method exists between VPN instances in different ASs, this method can be used to reflect this connection in the VPN topology. This disclosure uses the example of multiple ASs including AS100 and AS200, where the second specified communication method is option B / C, to illustrate the solution. Other similar situations will not be described in detail. The corresponding network architecture can be shown in Figure 12. The processing flow of this method can be shown in Figure 13, including the following steps:

[0236] 1301. PE sends an UPDATE message.

[0237] The processing method of this step can refer to step 201.

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

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

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

[0241] The second configuration information is used to instruct AS100 and AS200 to communicate across domains using Option B / C. As shown in Figure 12, two VPN instances, VRF_A and VRF_B, in a VPN tunnel reside in AS100 and AS200, respectively. PE1, to which VRF_A belongs, and PE4, to which VRF_B belongs, are not the ASBRs connecting AS100 and AS200. The ASBRs connecting AS100 and AS200 are PE2 (ASBR1) and PE3 (ASBR2). PE2 and PE3 do not have VPN instances established for this VPN tunnel. The second configuration information may include the AS numbers of AS100 and AS200. The second configuration information can be obtained locally from a controller or from another device and can be configured by an administrator.

[0242] 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.

[0243] 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. The corresponding processing process can be seen in the description of step 203. The generated VPN topology can be shown in Figure 14.

[0244] Based on the same technical concept, an embodiment of the present disclosure provides a device for generating a VPN topology, which can be applied to the above-mentioned controller. As shown in FIG15 , the device includes:

[0245] The receiving module 1510 is configured 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.

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

[0247] 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. The VPN topology indicates the inter-access relationship between the VPN instances of multiple network devices. Specifically, it can implement the function of generating the VPN topology in the above step 203 and other implicit steps.

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

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

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

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

[0252] In a possible implementation, 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 in the BGP UPDATE message.

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

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

[0255] In one possible implementation, each BGP message carries the ERT of the VPN instance of the corresponding network device. Acquisition module 1520 is further configured to obtain 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. Acquisition module 1520 is configured 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 as the ERT of the VPN instance of the network device corresponding to any BGP message.

[0256] In one possible implementation, the generating module 1530 is configured to determine a connection relationship between VPN instances of multiple network devices based on the ERTs and IRTs 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.

[0257] In one possible implementation, the multiple BGP messages include a first BGP message and a second BGP message, the first BGP message corresponding to the first network device, and the second BGP message corresponding to the second network device. Generating module 1530 is configured to: determine a first connection relationship between the first VPN instance and the second VPN instance based on a corresponding relationship 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, 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 a 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.

[0258] 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.

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

[0260] In one 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 the third network device, the fourth BGP message corresponds to a fourth VPN instance of the fourth network device, and the VPN topology further indicates that a connection using the first specified communication method exists between nodes corresponding to the third VPN instance and the fourth VPN instance.

[0261] In one possible implementation, the acquisition module 1520 is further used to: obtain first configuration information, where the first configuration information indicates that a connection of the first specified communication mode exists between the third VPN instance and the fourth VPN instance. Specifically, the processing function of the above-mentioned 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-mentioned steps 1004-1005 and other implicit steps can be implemented.

[0262] 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 a fifth network device, the sixth BGP message corresponds to a sixth VPN instance of a sixth network device, and the VPN topology further indicates a mutual access relationship between the fifth VPN instance and the sixth VPN instance.

[0263] In one possible implementation, acquisition module 1520 is further configured to obtain second configuration information, the second configuration information instructing the third AS and the fourth AS to communicate across domains using a second designated communication method. Specifically, this can implement the processing functions of step 1303 above, as well as other implicit steps. A generation module is configured to determine the mutual access relationship between the fifth and sixth VPN instances 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, this can implement the processing functions of step 1304 above, as well as other implicit steps.

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

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

[0266] Based on the same technical concept, embodiments of the present disclosure provide an apparatus for generating a VPN topology. This apparatus can be applied to the aforementioned network device. As shown in FIG16 , the apparatus includes a sending module 1610 for sending a BGP message. The BGP message carries a route target of a VPN instance. The route target is used to generate a VPN topology, which indicates the inter-access relationships between VPN instances in the network. Specifically, the apparatus implements the processing functions of step 201 described above, as well as other implicit steps.

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

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

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

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

[0271] In a possible implementation, 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 in the BGP UPDATE message.

[0272] 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 whether a routing target of the first VPN instance changes.

[0273] 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.

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

[0275] The above embodiments provide an apparatus for generating a VPN topology, using the division of the functional modules described above as an example. In actual applications, the above functions can be assigned to different functional modules as needed, i.e., the internal structure of a computer device can be divided into different functional modules to perform all or part of the functions described above. Furthermore, the apparatus for generating a VPN topology provided in the above embodiments and the method for generating a VPN topology are conceptually identical. The detailed implementation process is described in the method embodiments and will not be further elaborated here.

[0276] The embodiments of the present disclosure also provide a computer-readable storage medium. The computer-readable storage medium can be any available medium that can be stored by a computing device or a data storage device such as a data center that contains one or more available media. The available medium can 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 drive). 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.

[0277] 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 them. 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 deviate the essence of the corresponding technical solutions 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 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 A second connection relationship between the first VPN instance and the second VPN instance is determined, where 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 BGP UPDATE 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