Message sending method, apparatus, and system

Abstract

The present application relates to the technical field of networks, and provides a message sending method, apparatus, and system. In the solution provided in the present application, after processing a route on the basis of a routing policy, a network device can send routing information of the processed route to a BMP server by means of a BMP message. Moreover, when the BMP message is sent, the processed route has not yet taken effect on the network device. On this basis, the routing information received by the BMP server can be used for detecting whether the routing policy in the network device is correctly configured. If the routing policy is incorrectly configured, and because the routing information processed by means of the routing policy has not yet actually taken effect in the network device, the routing policy can still be modified in time to prevent a network failure. Hence, the solution provided in the present application not only effectively improves flexibility of BMP message transmission, but also ensures reliability of routing policy configuration.

Description

Message sending methods, devices and systems

[0001] This application claims priority to Chinese Patent Application No. 202411219767.3, filed on August 30, 2024, entitled “Message Sending Method, Apparatus and System”, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of network technology, and in particular to a message sending method, apparatus and system. Background Technology

[0003] Border Gateway Protocol (BGP) is a dynamic routing protocol used between autonomous systems (AS). Each AS can include multiple network devices. After two network devices belonging to the same AS, or two network devices belonging to different AS, establish a BGP connection (i.e., establish a peer relationship), they can advertise BGP routes to each other through BGP update messages. Peers are also called neighbors.

[0004] Network devices can send their BGP operational status to a BMP server via BGP monitoring protocol (BMP) messages, allowing the BMP server to obtain the network device's BGP operational status in a timely manner. This BGP operational status can include the establishment and termination of peer relationships, as well as the updating of routing information. However, the flexibility of network devices sending BMP messages is relatively low. Summary of the Invention

[0005] This application provides a message sending method, apparatus, and system that can solve the technical problem of low flexibility in sending BMP messages by network devices.

[0006] Firstly, a message sending method is provided, applied to a network device. The method includes: processing routes in the network device based on a routing policy to obtain routing information of the processed routes; then, sending a first BMP message, which includes the routing information, to a BMP server. Notably, when sending the first BMP message to the BMP server, the processed routes are not yet active on the network device.

[0007] Since the routing policy processed by the network device has not yet taken effect when the network device sends the first BMP message, the routing information received by the BMP server can be used to check whether the routing policy is configured correctly. If the routing policy is misconfigured, it can be modified in a timely manner to avoid network failure. Therefore, the solution provided in this application not only effectively improves the flexibility of BMP message sending but also ensures the reliability of routing policy configuration.

[0008] Optionally, the first BMP message may also include an indication flag, which indicates that the processed route has not yet taken effect on the network device. By including the indication flag in the first BMP message, the BMP server can accurately determine whether the route information is ineffective, thereby facilitating timely detection of whether the routing policy is configured correctly based on the route information.

[0009] Optionally, the first BMP message may include a peer header that carries the indication identifier. For example, the indication identifier may be carried in a reserved field in the peer header to avoid affecting the original message format of the BMP message.

[0010] Optionally, each peer message header includes a peer tag field, which may carry an indicator. It is understood that the peer tag field includes several reserved bits, which may carry the indicator. Thus, the carrying and sending of the indicator can be achieved without affecting the BMP message format.

[0011] Optionally, the first BMP message includes a common header, the message type field of which carries an indication identifier.

[0012] In the solution provided in this application, the value of the message type field in the common header can be extended to define a new type of BMP message. This new type of BMP message is specifically used to carry routing information for routes that have not yet taken effect. Accordingly, the extended value can serve as an indicator to indicate that the routing information carried in the BMP message is information about routes that have not yet taken effect.

[0013] Optionally, the first BMP message may include at least one of a route monitoring message, a route mirroring message, and a statistical report message. The scheme provided in this application can report routing information (pre-verification results of routing policies) through different types of BMP messages, effectively improving the flexibility of message reporting.

[0014] Optionally, the routing information may include an address prefix; or, the routing information may include an address prefix and at least one routing attribute. The address prefix may be an Internet Protocol (IP) prefix. The at least one routing attribute may include a source attribute, an AS path attribute, and a next-hop attribute, etc.

[0015] Specifically, if the routing information is updated, it may include an address prefix and at least one routing attribute. If the routing information is withdrawn, it may include an address prefix but not routing attributes.

[0016] Optionally, the routing policy can be a BGP routing policy, and correspondingly, the routes processed using this BGP routing policy are BGP routes.

[0017] Optionally, the routing policy can also be a routing policy of other routing protocols. These other routing protocols can be protocols other than BGP that affect BGP routes. For example, these other routing protocols can include at least one of the following: Interior Gateway Protocol (IGP) or Open Shortest Path First (OSPF).

[0018] Optionally, the routing policy may include: ingress policy, egress policy, route import policy, route aggregation policy, route selection policy, or virtual private network (VPN) instance policy, etc.

[0019] The ingress policy handles routes received by the network device, the egress policy handles routes advertised by the network device, the route import policy handles routes imported by the network device, the aggregation route policy handles aggregated routes in the network device, and the routing policy and VPN instance policy both handle routes in the local routing table of the network device. Because the solution provided in this application can pre-validate different types of routing policies, it effectively improves the reliability of routing policy configuration, thereby ensuring the stability of network operation. Optionally, each of the above types of routing policies may include at least one of a prefix filter and a route attribute filter.

[0020] Optionally, the method may further include: receiving a feedback message in response to the first BMP message, the feedback message indicating whether the routing policy is configured correctly. The feedback message may be sent by the BMP server or by a controller (such as a network management system) connected to the BMP server.

[0021] Optionally, the method may further include: rolling back the processed route based on the feedback message, or applying the processed route. It is understood that if the feedback message indicates a routing policy configuration error, the network device can roll back the processed route and clear the erroneous policy configuration to avoid network failures caused by incorrectly configured routing information. If the feedback message indicates an accurate routing policy configuration, the network device can directly apply the processed route. Since the routing policy has been verified, it can be ensured that the network can continue to operate stably and reliably after the processed route takes effect.

[0022] Optionally, the method may further include: sending a second BMP message to a BMP server. The second BMP message carries at least one of the following information: the number of routes rejected by the network device due to route-limit or prefix-limit; the number of routes rejected by the network device due to insufficient memory; the number of routes that cannot be sent to the forward information base (FIB) by the network device due to insufficient forwarding resources; the number of routes that cannot be sent to the FIB by the network device due to FIB rejection; the number of routes that cannot be sent to the FIB by the network device due to insufficient label resources or segment identifier (SID) resources; the number of routes that cannot be advertised by the network device due to insufficient label resources or SID resources; and the number of routes that are inactive by the network device due to unreachable next-hop IP or tunnel.

[0023] The solution provided in this application can also report the aforementioned critical events or alarms through BMP messages. This not only effectively enriches the types of information that BMP messages can carry, but also facilitates the rapid discovery of problems in network devices, ensuring the reliable operation of network devices.

[0024] Optionally, the second BMP message can be a statistical report message. In the solution provided in this application, the value of the stat type field in the statistical report message can be expanded to enable the statistical report message to carry at least one of the aforementioned information.

[0025] Secondly, a message sending method is provided, applied to a network device. The method includes: sending a BMP message to a BMP server. The BMP message carries at least one of the following information: the number of routes rejected by the network device due to routing restrictions or prefix restrictions; the number of routes rejected by the network device due to insufficient memory; the number of routes that cannot be distributed to the FIB by the network device due to insufficient forwarding resources; the number of routes that cannot be distributed to the FIB by the network device due to FIB rejection; the number of routes that cannot be distributed to the FIB by the network device due to insufficient label resources or SID resources; the number of routes that cannot be advertised by the network device due to insufficient label resources or SID resources; and the number of routes that are inactive by the network device due to unreachable next-hop IP or tunnel.

[0026] In the solution provided in this application, network devices can report at least one of the aforementioned critical events via BMP messages. This not only effectively enriches the types of information that BMP messages can carry, but also facilitates the rapid detection of problems in network devices, ensuring their reliable operation.

[0027] Thirdly, a message sending method is provided, applied to a BMP server. The method includes: receiving a first BMP message sent by a network device, the first BMP message including routing information. The routing information is obtained by processing routes in the network device based on routing policies, and at the time the first BMP message is sent, the processed routes have not yet taken effect on the network device; this routing information is used to detect whether the routing policies are configured correctly.

[0028] Optionally, the first BMP message may also include an indication flag indicating that the processed route has not taken effect on the network device.

[0029] Optionally, the method may further include: detecting whether the routing policy in the network device is configured correctly based on the routing information, and sending a feedback message to the network device, the feedback message being used to indicate whether the routing policy is configured correctly.

[0030] The BMP server can be configured with a detection algorithm, which can be used to detect routing information and determine whether the routing policies in the network devices are configured correctly.

[0031] Optionally, the method may further include: receiving a second BMP message sent by a network device, the second BMP message carrying at least one of the following information: the number of routes rejected by the network device due to routing restrictions or prefix restrictions; the number of routes rejected by the network device due to insufficient memory; the number of routes that cannot be distributed to the FIB by the network device due to insufficient forwarding resources; the number of routes that cannot be distributed to the FIB by the network device due to rejection by the FIB; the number of routes that cannot be distributed to the FIB by the network device due to insufficient label resources or SID resources; the number of routes that cannot be advertised by the network device due to insufficient label resources or SID resources; and the number of routes that are inactive by the network device due to unreachable next-hop IP or tunnel.

[0032] Optionally, the method may further include: displaying a BMP message sent by the network device, the BMP message including at least one of a first BMP message and a second BMP message.

[0033] By displaying the first BMP message sent by network devices, the BMP server helps maintenance personnel check the accuracy of routing policies. Similarly, by displaying the second BMP message sent by network devices, the BMP server helps maintenance personnel check for faults in the network devices.

[0034] Fourthly, a message sending method is provided, applied to a BMP server. The method includes: receiving a BMP message sent by a network device, the BMP message carrying at least one of the following information: the number of routes rejected by the network device due to routing restrictions or prefix restrictions; the number of routes rejected by the network device due to insufficient memory; the number of routes that cannot be distributed to the FIB by the network device due to insufficient forwarding resources; the number of routes that cannot be distributed to the FIB by the network device due to rejection by the FIB; the number of routes that cannot be distributed to the FIB by the network device due to insufficient label resources or SID resources; the number of routes that cannot be advertised by the network device due to insufficient label resources or SID resources; and the number of routes that are inactive by the network device due to unreachable next-hop IP or tunnel.

[0035] Fifthly, a message sending method is provided, applied to a message sending system including a network device and a BMP server. The method includes: the network device processing routes within the network device based on a routing policy to obtain routing information for the processed routes; the network device sending a first BMP message to the BMP server, the first BMP message including the routing information, wherein the processed routes are not yet effective on the network device at the time the network device sends the first BMP message to the BMP server; and the BMP server receiving the routing information.

[0036] Optionally, the first BMP message may also include an indication flag indicating that the processed route has not taken effect on the network device.

[0037] Optionally, the method may further include: the BMP server detecting whether the routing policy in the network device is configured correctly based on the routing information, and sending a feedback message to the network device, the feedback message indicating whether the routing policy is configured correctly. The network device then rolls back the processed route based on the feedback message, or applies the processed route.

[0038] Optionally, the method may further include: the network device sending a second BMP message to the BMP server, the second BMP message carrying at least one of the following information: the number of routes rejected by the network device due to routing restrictions or prefix restrictions; the number of routes rejected by the network device due to insufficient memory; the number of routes that cannot be sent to the FIB due to insufficient forwarding resources; the number of routes that cannot be sent to the FIB due to rejection by the FIB; the number of routes that cannot be sent to the FIB due to insufficient label resources or SID resources; the number of routes that cannot be advertised due to insufficient label resources or SID resources; and the number of routes that are inactive due to unreachable next-hop IP or tunnel.

[0039] Optionally, the method may further include: the BMP server displaying information carried in the second BMP message.

[0040] Sixthly, a message sending method is provided, applied to a message sending system, the message sending system including: a network device and a BMP server. The method includes: the network device sending a BMP message to the BMP server; the BMP server receiving information carried in the BMP message, the BMP message carrying at least one of the following: the number of routes rejected by the network device due to routing restrictions or prefix restrictions; the number of routes rejected by the network device due to insufficient memory; the number of routes that cannot be distributed to the FIB by the network device due to insufficient forwarding resources; the number of routes that cannot be distributed to the FIB by the network device due to rejection by the FIB; the number of routes that cannot be distributed to the FIB by the network device due to insufficient label resources or SID resources; the number of routes that cannot be published by the network device due to insufficient label resources or SID resources; the number of routes that are inactive by the network device due to unreachable next-hop IP or tunnel.

[0041] In a seventh aspect, a network device is provided, the network device including at least one module that can be used to implement the message sending method provided in the first or second aspect above.

[0042] Eighthly, a BMP server is provided, the BMP server including at least one module that can be used to implement the message sending method provided in the third or fourth aspect above.

[0043] A ninth aspect provides a message sending device, the message sending device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the message sending method provided by any one of the first to fourth aspects described above.

[0044] In a tenth aspect, a network device is provided, which may include a main control board and an interface board, the main control board and the interface board being used to implement the message sending method provided in the first or second aspect above.

[0045] Eleventhly, a computer-readable storage medium is provided, which stores instructions that are executed by a processor to implement the message sending method provided in any one of the first to fourth aspects described above.

[0046] In a twelfth aspect, a computer program product containing instructions is provided, which, when executed on a processor, cause the processor to perform a message sending method as provided in any one of the first to fourth aspects described above.

[0047] In a thirteenth aspect, a message sending system is provided, comprising a network device and a BMP server. The network device is used to implement the message sending method provided in the first or second aspect above. The BMP server is used to implement the message sending method provided in the third or fourth aspect above.

[0048] In summary, this application provides a message sending method, apparatus, and system. In the solution provided by this application, after a network device processes a route based on a routing policy, it can send the processed route information to a BMP server via a BMP message. Furthermore, when sending the BMP message, the processed route on the network device has not yet taken effect. Based on this, the routing information received by the BMP server can be used to detect whether the routing policy in the network device is configured correctly. If the routing policy is configured incorrectly, since the processed route has not yet truly taken effect in the network device, the routing policy can be modified in a timely manner to avoid network failures. Therefore, the solution provided by this application not only effectively improves the flexibility of BMP message sending but also ensures the reliability of routing policy configuration. Attached Figure Description

[0049] Figure 1 is a structural schematic diagram of an application scenario of a message sending method provided in an embodiment of this application;

[0050] Figure 2 is a structural diagram of an application scenario of another message sending method provided in an embodiment of this application;

[0051] Figure 3 is a schematic diagram of a BMP message data format provided in an embodiment of this application;

[0052] Figure 4 is a schematic diagram of a common message header data format provided in an embodiment of this application;

[0053] Figure 5 is a schematic diagram of the data format of a peer message header provided in an embodiment of this application;

[0054] Figure 6 is a schematic diagram of the structure of a peer tag field provided in an embodiment of this application;

[0055] Figure 7 is a schematic diagram of another peer tag field structure provided in an embodiment of this application;

[0056] Figure 8 is a flowchart illustrating a message sending method provided in an embodiment of this application;

[0057] Figure 9 is a flowchart illustrating another message sending method provided in an embodiment of this application;

[0058] Figure 10 is a schematic diagram of the structure of another peer tag field provided in an embodiment of this application;

[0059] Figure 11 is a schematic diagram of the structure of another peer tag field provided in an embodiment of this application;

[0060] Figure 12 is a structural schematic diagram of an application scenario of another message sending method provided in an embodiment of this application;

[0061] Figure 13 is a schematic diagram of the structure of another peer tag field provided in an embodiment of this application;

[0062] Figure 14 is a schematic diagram of the structure of another peer tag field provided in an embodiment of this application;

[0063] Figure 15 is a structural schematic diagram of an application scenario of another message sending method provided in an embodiment of this application;

[0064] Figure 16 is a schematic diagram of the structure of another peer tag field provided in an embodiment of this application;

[0065] Figure 17 is a schematic diagram of the structure of another peer tag field provided in an embodiment of this application;

[0066] Figure 18 is a flowchart of another message sending method provided in an embodiment of this application;

[0067] Figure 19 is a schematic diagram of the structure of a counter field in an SR message provided in an embodiment of this application;

[0068] Figure 20 is a schematic diagram of the structure of a network device provided in an embodiment of this application;

[0069] Figure 21 is a schematic diagram of another network device provided in an embodiment of this application;

[0070] Figure 22 is a schematic diagram of the structure of a BMP server provided in an embodiment of this application;

[0071] Figure 23 is a schematic diagram of the structure of a message sending device provided in an embodiment of this application;

[0072] Figure 24 is a schematic diagram of another network device provided in an embodiment of this application. Detailed Implementation

[0073] The message sending method, apparatus, and system provided in the embodiments of this application are described in detail below with reference to the accompanying drawings. First, the terminology used in the embodiments of this application will be introduced.

[0074] The Adjacency-routing Information Base-input (Adj-RIB-in) table stores routes received from neighbors by network devices. This Adj-RIB-in can include both the pre-policy RIB and the post-policy RIB.

[0075] Local-routing information base (Loc-RIB): Used to store routes used locally by network devices. Furthermore, the routes in the Loc-RIB are routes that have been modified according to relevant policies.

[0076] The adjacency-routing information base-output (Adj-RIB-out) table stores routes selected from the Loc-RIB that will be sent out; these are the routes that need to be communicated to other peers (i.e., neighbors). Furthermore, Adj-RIB-out can include both the RIB before and after the policy is applied.

[0077] Figure 1 is a structural schematic diagram of an application scenario of a message sending method provided in an embodiment of this application. As shown in Figure 1, the application scenario may include at least one network device 01 and a BMP server 02. For example, a network device 01 is schematically shown in Figure 1. The network device 01 runs BGP and BMP. The network device 01 can establish BGP peer relationships (also known as BGP neighbors) with other network devices through BGP and can communicate with the BMP server 02 through BMP. The network device 01 can be a router or switch, such as an access router (AR), a data center switch, or a white-box switch. The BMP server 02, also known as a monitoring station, can be a single server, a server cluster consisting of several servers, or a cloud computing service center. Alternatively, the BMP server 02 can also be BMP server software.

[0078] Figure 2 is a structural diagram of an application scenario for another message sending method provided in this application embodiment. As shown in Figure 2, this application scenario may include multiple network devices 01, which may include provider edge (PE) devices, provider (P) devices, and customer edge (CE) devices. PE devices can establish connections with each other through P devices (also called core layer devices), and each PE device can connect to one or more CE devices. Furthermore, BGP and BMP can be run on the PE devices, P devices, and CE devices, and they can communicate with the BMP server 02 through BMP.

[0079] Before implementing BMP, the BGP running status on network device 01 was typically obtained through manual queries, which was inefficient. After implementing BMP, network device 01 can send its BGP running status to BMP server 02 via a connection, significantly improving network monitoring efficiency. Furthermore, BMP server 02, by understanding the BGP running status through BMP, can promptly identify network problems and take mitigation measures, ensuring network stability.

[0080] Understandably, after establishing a Transmission Control Protocol (TCP) session with BMP server 02, network device 01 running BGP can send BMP messages to BMP server 02. As shown in Figure 3, this BMP message can include a common header and a per-peer header.

[0081] As shown in Figure 4, the general message header can include the following fields: version, message length, and message type (Msg.Type). The message length includes the length of the general message header. A value of 0 indicates a route monitoring (RM) message; a value of 1 indicates a stats report (SR) message; a value of 2 indicates a peer down notification message; a value of 3 indicates a peer up notification message; a value of 4 indicates an initiation message (IM); a value of 5 indicates a termination message (TM); and a value of 6 indicates a route mirroring message. The meanings and uses of each type of BMP message can be found in Table 1.

[0082] Table 1

[0083] As shown in Figure 3, the general header in this BMP message is followed by the peer header. Typically, this peer header is encapsulated in all types of BMP messages except for start and stop messages. As shown in Figure 5, the peer header includes the following fields: peer type, peer flags, peer distinguisher, peer address, peer AS number, peer BGP identification (ID), and timestamp. Peers are also called neighbors. The peer address is 16 bytes long. The peer BGP ID field carries the BGP ID from the open message received from the peer.

[0084] In this context, a value of 0 for the peer type field indicates that the peer type (i.e., the neighbor type) is a public network instance peer; a value of 1 indicates that the peer type is a peer carrying a route distinguisher (RD), such as a private network peer of an L3VPN instance; a value of 2 indicates that the peer type is a local instance peer; and a value of 3 indicates that the peer type is a Loc-RIB instance peer. L3VPN refers to a Layer 3 virtual private network.

[0085] The peer tag field is 1 byte long. When the peer type field takes the value 0, 1, or 2, as shown in Figure 6, the peer tag field includes the following flags:

[0086] V: A value of 1 indicates that the peer address is an Internet protocol version 6 (IPv6) address, and a value of 0 indicates that the peer address is an IP version 4 (IPv4) address;

[0087] L: A value of 1 indicates that the route monitoring data sent is after the policy, and a value of 0 indicates that the route monitoring data sent is before the policy;

[0088] A: A value of 1 indicates that the AS_Path attribute is encapsulated in two bytes, and a value of 0 indicates that the AS_Path attribute is encapsulated in four bytes.

[0089] O: A value of 1 indicates Adj-RIB-out, and a value of 0 indicates Adj-RIB-in;

[0090] Reserved (R) bit.

[0091] When the peer type field is 3, i.e., the peer type is a Loc-RIB instance Peer, the format of the peer label field can be seen in Figure 7. As shown in Figure 7, the peer label field includes a 1-bit F flag and 7 reserved bits. The F flag being 1 indicates that the routes in the Loc-RIB have been processed by policies, meaning the route monitoring data sent to the BMP server is policy-processed.

[0092] Network device 01 is typically configured with routing policies (such as ingress and egress policies). These policies are used to process routes on network device 01, i.e., filtering routes or modifying their prefixes or attributes. For example, ingress policies can be used to filter or modify BGP routes received by network device 01 from other peers. Egress policies can be used to filter or modify BGP routes advertised by network device 01 to other peers. Furthermore, network device 01 can report routing information to BMP server 02 for routes before and / or after the application of a routing policy. Routes before the application of a policy refer to routes before processing by the policy, while routes after the application of a policy refer to routes after processing by the policy.

[0093] It is understood that a routing policy typically includes at least one routing feature and at least one behavioral feature (also called an action feature). The at least one routing feature is used for route matching, and the at least one behavioral feature characterizes the action performed on the matched route. The at least one routing feature may include an address prefix, or it may also include AS path attributes and community attributes, etc. The action characterized by the at least one behavioral feature may include: filtering routes, and / or modifying route attributes, etc.

[0094] It can also be understood that the routing information may include: an address prefix; or, the routing information may include an address prefix and at least one routing attribute. The address prefix may be an IP prefix, and the at least one routing attribute may include: an ORIGIN attribute, an AS path attribute, and a next-hop attribute. The routing attribute may also include: a local priority attribute, a community attribute, an extended community attribute, and a multi-exit discriminator (MED) attribute, etc. If the routing information is updated, it may include an address prefix and at least one routing attribute. If the routing information is withdrawn, it may include an address prefix but not routing attributes.

[0095] When it's necessary to modify the routing policy on network device 01, maintenance personnel can manually modify the configuration information of the routing policy on network device 01. After the modified routing policy is applied to the routes on network device 01 and the processed routes take effect, network device 01 can report the routing information of the policy-adjusted routes (i.e., the routes after they take effect) to BMP server 02. If the routing policy is configured incorrectly, it may cause serious network failures because the policy-adjusted routes have already taken effect. Therefore, there is an urgent need for a method to pre-verify routing policies.

[0096] Figure 8 is a flowchart of a message sending method provided in an embodiment of this application. This method can be applied to the scenario shown in Figure 1 or Figure 2. As shown in Figure 8, the method includes:

[0097] Step 101: The network device processes the routes in the network device based on the configured routing policy to obtain the routing information of the processed routes.

[0098] In this embodiment, for newly configured or modified routing policies in a network device, a pre-validation can be performed to ensure the accuracy of the routing policy configuration. During pre-validation, the network device can first process the routes in the network device using the routing policy to obtain the routing information of the processed routes. The modification of the routing policy can be caused by directly modifying the routing policy itself, or by modifying other configurations (such as system configurations or interface configurations). For changes in the routing policy caused by modifications to other configurations, performing pre-validation on the modified routing policy based on the scheme provided in this embodiment is equivalent to implementing pre-validation for the aforementioned modifications to other configurations.

[0099] As described above, the routing policy may include at least one routing feature and at least one behavioral feature. The network device may first use the at least one routing feature to match routes in the network device. Then, for routes that match the at least one routing feature, the network device may process the route using at least one behavioral feature from the routing policy. For example, it may filter the route (i.e., delete the route) and / or modify the route's routing attributes.

[0100] After a network device processes a route using a routing policy, the resulting routing information may include: an address prefix (such as an IP prefix). Alternatively, in addition to the address prefix, it may include at least one routing attribute. This at least one routing attribute may include: an ORIGIN attribute, an AS path attribute, and a next-hop attribute; or, in addition to the above attributes, it may include at least one of the following attributes: a local priority attribute, a community attribute, an extended community attribute, and a MED attribute, etc.

[0101] Step 102: The network device sends a first BMP message to the BMP server, which includes routing information of the processed route.

[0102] After processing the routing information, the network device can send a first BMP message carrying that routing information to the BMP server. However, when the network device sends this first BMP message, the route processed by the routing policy has not yet taken effect on the network device. Accordingly, the routing information in the first BMP message received by the BMP server can be used to check whether the routing policy in the network device is configured correctly; that is, this routing information can be used for pre-validation of the routing policy.

[0103] For example, the BMP server can display this routing information, which can then be used by operations and maintenance personnel to check whether the routing policies in the network devices are configured correctly. Alternatively, the BMP server can be configured with a detection algorithm that can be directly used to check the routing information and thus determine whether the routing policies in the network devices are configured correctly.

[0104] In this embodiment of the application, since the processed route does not actually take effect on the network device when the network device sends the first BMP message, if the routing policy is configured incorrectly, the routing policy can be modified in time to avoid network failure.

[0105] It's understandable that "processed routes not taking effect" can mean that the processed routes do not affect the forwarding and forwarding behavior of network devices. Forwarding behavior refers to the way network devices forward data streams, and forwarding behavior refers to the way network devices advertise routes to their neighbors. For example, ineffective routes will not participate in local route modification and routing, will not be distributed to the FIB, and will not be advertised to other neighbors. In other words, ineffective routes will not affect the network device's Loc-RIB and Adj-RIB-out. Alternatively, it can be understood that when sending the first BMP message, the network device still processes the previous routes based on the routing policy to guide its forwarding and forwarding behavior.

[0106] It is also understandable that the processed route not taking effect on the network device when the first BMP message is sent can mean that the processed route is not effective on the network device within a certain time range before and after the sending of the first BMP message. This certain time range can be the time error allowed by the message sending system. Furthermore, after sending the first BMP message, the processed route can remain ineffective until the network device takes effect based on the configuration by the operations and maintenance personnel or based on received feedback messages (such as feedback messages issued by the BMP server).

[0107] It's also understandable that the configuration and activation process of routing policies on network devices typically includes two stages: a configuration editing stage and a configuration activation stage. The configuration editing stage is used to edit the routing policy, such as modifying it. The configuration activation stage is used to process the routes using the routing policy, and the processed routes take effect directly on the network device.

[0108] In this embodiment, the configuration and activation process of routing policies on a network device can include three stages: a configuration editing stage, a pre-activation stage, and an ineffective / actually effective stage. The configuration editing stage is used to edit the routing policy. The pre-activation stage is used to process routes using the routing policy, but the processed routes are not actually effective on the network device. Furthermore, in this pre-activation stage, the network device can send a first BMP message carrying routing information of the processed routes to the BMP server. Then, in the ineffective / actually effective stage, if it is determined based on the routing information that the routing policy configuration is incorrect, the network device can cancel (or clear) the incorrect policy configuration, and the processed routes will not be effective; that is, the processed routes will be rolled back to their state before processing. If it is determined based on the routing information that the routing policy configuration is accurate, the network device can activate the processed routes. This achieves pre-verification of the routing policy, avoiding network accidents caused by incorrect routing policy configuration.

[0109] In summary, this application provides a message sending method. In this method, after a network device processes a route based on a routing policy, it can send the processed route information to a BMP server via a BMP message. Furthermore, when sending the BMP message, the processed route on the network device has not yet taken effect. Therefore, the routing information received by the BMP server can be used to detect whether the routing policy in the network device is configured correctly. If the routing policy is misconfigured, since the processed route has not yet truly taken effect in the network device, the routing policy can be modified in a timely manner to avoid network failures. Thus, the solution provided by this application not only effectively improves the flexibility of BMP message sending but also ensures the reliability of routing policy configuration.

[0110] Figure 9 is a flowchart of another message sending method provided in an embodiment of this application. This method can be applied to the scenario shown in Figure 1 or Figure 2. As shown in Figure 9, the method includes:

[0111] Step 201: The network device processes the routes in the network device based on the configured routing policy to obtain the routing information of the processed routes.

[0112] In this embodiment, the routing policy in the network device can be a BGP routing policy, and the routes processed using this BGP routing policy can be BGP routes. Of course, the routing policy can also be a routing policy of other routing protocols. These other routing protocols can be protocols other than BGP that affect BGP routes. For example, these other protocols can include at least one of protocols such as IGP and OSPF.

[0113] Optionally, the routing policy may include ingress policies, egress policies, route import policies, aggregated route policies, routing policies (such as BGP routing policies), or VPN instance policies. Ingress policies handle routes received by network devices, egress policies handle routes advertised by network devices, route import policies handle routes imported by network devices, aggregated route policies handle aggregated routes within network devices, and routing policies and VPN instance policies handle routes within the Loc-RIB of network devices. The solution provided in this application can pre-validate different types of routing policies, effectively improving the reliability of routing policy configuration and thus ensuring the stability of network operation.

[0114] Optionally, each of the above-mentioned routing policies may include at least one of a prefix filter and a routing attribute filter. The above-mentioned processing of routes in network devices based on configuration-based routing policies can refer to processing routes in network devices based on at least one of the prefix filter and the routing attribute filter.

[0115] Step 202: The network device sends a first BMP message to the BMP server, which includes routing information of the processed route.

[0116] The implementation process of steps 201 and 202 can be referred to the relevant descriptions in steps 101 and 102 above, and will not be repeated here.

[0117] Optionally, the first BMP message may also include an indication identifier, which can be used to indicate that the routing information carried in the first BMP message is routing information that has not taken effect on the network device. Based on this, the BMP server can confirm that the first BMP message is a BMP message used for pre-validation of routing policies.

[0118] As a possible example, referring to Figure 3, the first BMP message may include a peer header, which may carry an indication identifier. For example, referring to Figure 5, the peer header includes a peer tag field, which may carry an indication identifier. This indication identifier may also be called a simulation (S) identifier.

[0119] For example, when the peer type field in each peer header has a value of 0, 1, or 2, as shown in Figures 6 and 10, the 4 reserved bits (R) in the peer label field can carry the indicator S. When the peer type field in each peer header has a value of 3, as shown in Figures 7 and 11, the 7 reserved bits (R) in the peer label field can carry the indicator S. Optionally, referring to Figures 10 and 11, it can be seen that the indicator S can occupy 1 bit of the reserved bits, and this 1 bit can be any bit in the reserved bits.

[0120] In this example, the first BMP message reported by the network device may include at least one of a Route Monitoring (RM) message, a Route Mirroring message, and a Statistics Report (SR) message. For example, the first BMP message reported by the network device may include both an RM message and an SR message. Referring to Table 1, if the first BMP message includes an RM message, the routing information carried in the first BMP message may include routing information of routes in Adj-RIB-in, Loc-RIB, and / or Adj-RIB-out after processing with routing policies. If the first BMP message includes a Route Mirroring message, the routing information carried in the Route Mirroring message may include a copy of a message received by the network device, such as a copy of an update message received by the network device. If the first BMP message includes an SR message, the routing information carried in the SR message may include statistical information of the processed routes. This statistical information may include at least one of the following: the number of routes published after processing with routing policies, the number of routes received, the number of routes rejected for publication, the number of routes rejected for reception, the number of preferred routes in Loc-RIB, and the total number of routing tables in the network device, etc. In this context, routes that are refused to be advertised or refused to be received can both refer to routes that have been filtered out by routing policies.

[0121] As another possible example, referring to Figure 3, the first BMP message may include a common header, and the message type field of this common header may carry the indication identifier. That is, the solution provided in this application embodiment can extend the value of the message type field to define a new type of BMP message. This new type of BMP message can be specifically used to carry routing information of routes that have not yet taken effect, that is, routing information used for pre-validation of routing policies. Accordingly, the extended value can serve as an indication identifier to indicate that the routing information carried in the BMP message is information about routes that have not yet taken effect.

[0122] For example, as shown in Table 2, when the message type field is 7, it indicates that the first BMP message is a simulated RM message, and the routing information type carried in the simulated RM message can be the same as the routing information type carried in a traditional RM message. When the message type field is 8, it indicates that the first BMP message is a simulated route mirror message, and the routing information type carried in the simulated route mirror message can be the same as the routing information type carried in a traditional route mirror message. When the message type field is 9, it indicates that the first BMP message is a simulated SR message, and the routing information type carried in the simulated SR message can be the same as the routing information type carried in a traditional SR message.

[0123] Table 2

[0124] Based on the above analysis, it can be seen that the type of information carried in the new type of BMP message (i.e., the simulated BMP message) provided in this application embodiment can be the same as the type of information carried in the traditional BMP message. The difference is that the information carried in the new type of BMP message is all information about routes that have not yet taken effect.

[0125] Step 203: The BMP server displays the routing information.

[0126] In this embodiment, after receiving the first BMP message, the BMP server can display the routing information carried in the first BMP message. This displayed routing information can be used by maintenance personnel to check whether the routing policies in network devices are configured correctly.

[0127] Understandably, if the first BMP message includes an indication identifier, the BMP server can determine, based on this identifier, that the routing information carried in the first BMP message is the routing information of an inactive route. Furthermore, the BMP server can display this routing information based on the indication identifier for maintenance personnel to inspect.

[0128] Step 204: The BMP server checks whether the routing policies in the network devices are configured correctly based on the routing information.

[0129] In this embodiment of the application, the BMP server may also be configured with a detection algorithm. The BMP server may use the detection algorithm to process the routing information in the first BMP message in order to detect whether the routing policy in the network device is configured accurately.

[0130] For example, a BMP server can be a server with BMP server-side software installed, and management software (such as a network management client) can also be installed on this server. The BMP server-side software can receive the first BMP message and display the routing information carried in the first BMP message through a visual interface. Furthermore, the BMP server-side software can also send the routing information from the first BMP message to the management software. The management software can use a detection algorithm to process the routing information to detect whether the routing policies in the network devices are configured accurately. This detection algorithm can be an artificial intelligence (AI) algorithm.

[0131] Step 205: The BMP server sends a feedback message to the network device, which indicates whether the routing policy is configured correctly.

[0132] After completing the testing of the routing policy, the BMP server can send a feedback message to the network device. This feedback message indicates whether the routing policy in the network device is configured correctly. For example, the management software in the BMP server can send feedback messages to the network device.

[0133] It is understandable that the aforementioned BMP server software and management software can be installed on different devices; for example, the management software can be installed on a network management system or controller. Correspondingly, the BMP server can send the routing information from the first BMP message it receives to the device where the management software resides. The device where the management software resides then checks whether the routing policies in the network devices are configured correctly based on the routing information and sends a feedback message to the network devices.

[0134] Step 206: The network device rolls back the processed route based on the feedback message, or applies the processed route.

[0135] After receiving a feedback message from the BMP server, if the feedback message indicates that the routing policy configuration in the network device is accurate, the network device can directly apply the processed route, meaning the processed route can participate in routing, distribution, and advertising. If the feedback message indicates that the routing policy configuration in the network device is incorrect, the network device can roll back (i.e., revert) the processed route, reverting it to its state before processing. Furthermore, the network device can cancel (or clear) erroneous policy configurations. In other words, the BMP server can intervene in the network device's forwarding behavior by instructing the network device to apply or roll back processed routes through feedback messages.

[0136] The following describes the message sending method provided in this application embodiment, taking the routing policy in a network device as the egress policy as an example. As shown in Figure 12, network device A and network device B establish a BGP neighbor relationship, i.e., they are BGP peers. Network device A establishes a BMP connection with the BMP server, also known as a BMP session. The BMP server is the BMP server-side, and network device A is the BMP client. Assuming that the egress policy of neighboring network device B is modified on network device A, after network device A processes the route using the modified egress policy, it will not publish the modified route to network device B. Instead, it will directly send the routing information of the modified route (i.e., the modified egress policy result) to the BMP server through the first BMP message.

[0137] For example, assuming that the neighbor addresses established by network device A and network device B are both IPv4 addresses, the value of the peer label field in the peer header of the first BMP message sent by network device A can be seen in Figure 13. Comparing Figure 10 and Figure 13, it can be seen that the V flag of this peer label field is 0, indicating that the peer address is an IPv4 address; the L flag is 1, indicating that the routing information sent is policy-adjusted; and the O flag is 1, indicating Adj-RIB-out. Furthermore, the last bit of this peer label field is the indicator S (also called the S flag), which is 1, indicating routing information for routes that have not yet taken effect.

[0138] Assuming that the neighbor addresses established by network device A and network device B are both IPv6 addresses, the values ​​of the peer label field in the peer header of the first BMP message can be seen in Figure 14. Comparing Figure 10 and Figure 14, it can be seen that the V flag bit of this peer label field is set to 1, indicating that the peer address is an IPv6 address. The values ​​of other flag bits in the peer label field shown in Figure 14 are the same as those in Figure 13, and will not be repeated here.

[0139] The following describes the message sending method provided in this application embodiment, taking the routing policy in a network device as the ingress policy as an example. As shown in Figure 15, network device B establishes a BGP neighbor relationship with network device A, and network device B establishes a BMP connection with a BMP server. Here, the BMP server is the BMP server-side, and network device B is the BMP client. Assuming that the ingress policy for neighboring network device A is modified on network device B, after network device B processes the route using the modified ingress policy, the processed route will not participate in the modification, routing, or distribution of local routes in network device B. Furthermore, network device B can send the routing information of the processed route (i.e., the result of the modified ingress policy) to the BMP server via a first BMP message.

[0140] For example, assuming that the neighbor addresses established by network device B and network device A are both IPv4 addresses, the values ​​of the peer label field in the peer header of the first BMP message sent by network device B can be seen in Figure 16. Comparing Figure 10 and Figure 16, it can be seen that the V flag of this peer label field is 0, indicating that the peer address is an IPv4 address; the L flag is 1, indicating that the routing information sent is policy-adjusted; and the O flag is 0, indicating Adj-RIB-in. Furthermore, the last bit of this peer label field is the indicator S, which is 1, indicating routing information for routes that have not yet taken effect.

[0141] Assuming that the neighbor addresses established by network device B and network device A are both IPv6 addresses, the values ​​of the peer label field in the peer header of the first BMP message can be seen in Figure 17. Comparing Figure 10 and Figure 17, it can be seen that the V flag bit of this peer label field is set to 1, indicating that the peer address is an IPv6 address. The values ​​of other flag bits in the peer label field shown in Figure 17 are the same as those in Figure 16, and will not be repeated here.

[0142] It is understood that the order of steps in the message sending method provided in this application embodiment can be appropriately adjusted, and steps can be added or removed as needed. For example, step 203 can be deleted as needed. Alternatively, steps 204 and 205 can be deleted as needed. Correspondingly, maintenance personnel can check whether the routing policy is configured accurately based on the routing information displayed by the BMP server. Afterwards, based on the test results, maintenance personnel can manually configure and revoke or activate the processed routes on the network device.

[0143] In summary, this application provides a message sending method. In this method, after a network device processes a route based on a routing policy, it can send the processed route information to a BMP server via a BMP message. Furthermore, when sending the BMP message, the processed route on the network device has not yet taken effect. Therefore, the routing information received by the BMP server can be used to detect whether the routing policy in the network device is configured correctly. If the routing policy is misconfigured, since the processed route has not yet truly taken effect in the network device, the routing policy can be modified in a timely manner to avoid network failures. Thus, the solution provided by this application not only effectively improves the flexibility of BMP message sending but also ensures the reliability of routing policy configuration.

[0144] Figure 18 is a flowchart of another message sending method provided in an embodiment of this application. This method can be applied to the scenario shown in Figure 1 or Figure 2. As shown in Figure 18, the method includes:

[0145] Step 301: The network device sends a second BMP message to the BMP server.

[0146] In this embodiment of the application, the network device may also send a second BMP message to the BMP server during operation. The second BMP message may carry at least one of the following information:

[0147] The number of routes rejected by network devices due to routing restrictions or prefix restrictions;

[0148] The number of routes rejected by a network device due to insufficient memory;

[0149] The number of routes that cannot be sent to the FIB in network devices due to insufficient forwarding resources; where insufficient forwarding resources may include at least insufficient FIB space;

[0150] The number of routes in a network device that could not be sent to the FIB due to FIB rejection;

[0151] The number of routes in network devices that cannot be sent to the FIB due to insufficient tag resources or SID resources;

[0152] The number of routes that cannot be advertised in a network device due to insufficient tag or SID resources;

[0153] The number of routes in a network device that are inactive due to the next-hop IP or tunnel being unreachable.

[0154] Optionally, the second BMP message can be an SR message, which may include at least one counter field. Each counter field is encoded according to type-length-value (TLV). As shown in Figure 19, each counter field may include a stat type field, a stat length field, and a stat data field. The stat data field carries statistical data, the stat type field indicates the type of statistical data carried in the stat data field, and the stat length field indicates the length of the stat data field.

[0155] In this embodiment, the values ​​of the stat type field in the SR message can be expanded to enable the SR message to carry at least one of the aforementioned information. For example, the values ​​of the newly added stat type field and the corresponding types of statistical data in this embodiment are shown in Table 3.

[0156] Table 3

[0157] Step 302: The BMP server displays the information carried in the second BMP message.

[0158] After receiving the second BMP message from the network device, the BMP server can display the information carried in the second BMP message, enabling maintenance personnel to quickly identify problems in the network device. Based on steps 301 and 302 above, it is clear that the solution provided in this application embodiment can send key events at the neighbor level, address family level, or protocol level via BMP messages. For example, it can notify network devices of insufficient memory, forwarding, or tag resources. Therefore, on the one hand, it effectively enriches the types of information that BMP messages can carry, and on the other hand, it facilitates the rapid identification of problems in network devices, ensuring the reliable operation of the network devices.

[0159] It is understood that the message sending method shown in Figure 18 can also be combined with the message sending method shown in Figure 9. For example, steps 301 and 302 can be executed before step 201 or after step 201.

[0160] In summary, this application provides a message sending method. In this method, network devices can report at least one of the following information via BMP messages: the number of routes rejected due to routing limitations, prefix limitations, or insufficient memory; the number of routes that cannot be distributed due to insufficient forwarding resources, insufficient label resources, insufficient SID resources, or FIB rejection; the number of routes that cannot be published due to insufficient label resources or SID resources; and the number of routes that are inactive due to unreachable next-hop IPs or tunnels. This effectively enriches the types of information that BMP messages can carry, and based on this information, it is easy to quickly identify problems in network devices, ensuring the reliable operation of network devices.

[0161] Figure 20 is a schematic diagram of a network device provided in an embodiment of this application. This network device can be applied to systems such as those shown in Figure 1 or Figure 2, and can implement the steps performed by the network device in the above method embodiments. As shown in Figure 20, the network device includes:

[0162] Processing module 401 is used to process routes in network devices based on routing policies to obtain routing information for the processed routes. The functionality of processing module 401 can be found in the descriptions of steps 101 and 201 in the above method embodiments.

[0163] The sending module 402 is used to send a first BMP message to the BMP server, the first BMP message including routing information. When sending the first BMP message to the BMP server, the processed route is not yet effective on the network device. The functionality of the sending module 402 can be found in the descriptions of steps 102 and 202 in the above method embodiments.

[0164] Optionally, the first BMP message may also include an indication identifier, which indicates that the routing information carried in the first BMP message is information about routes that are not effective on the network device.

[0165] Optionally, the first BMP message includes a peer header, which carries an indication identifier.

[0166] Optionally, each peer header includes a peer label field that carries an indication identifier.

[0167] Optionally, the first BMP message includes a common header, and the message type field of the common header carries an indication identifier.

[0168] Optionally, the first BMP message includes at least one of a route monitoring message, a route mirroring message, and a statistics report message.

[0169] Optionally, the routing information may include an address prefix; or, the routing information may include an address prefix and at least one routing attribute.

[0170] Optionally, the routing strategy in this application embodiment can be a BGP routing strategy, and the route is a BGP route.

[0171] Optionally, the routing policy may include: ingress policy, egress policy, route import policy, route aggregation policy, route selection policy, or VPN instance policy, etc.

[0172] Optionally, continuing to refer to Figure 20, the network device may also include:

[0173] The receiving module 403 is used to receive a feedback message for the first BMP message, which indicates whether the routing policy is configured correctly. The functionality of the receiving module 403 can be found in the description of step 205 in the above method embodiment.

[0174] Optionally, the processing module 401 can also be used to roll back the processed route or to apply the processed route based on the feedback message. The functionality of the processing module 401 can also be found in the description of step 206 in the above method embodiments.

[0175] Optionally, the sending module 402 can also be used to send a second BMP message to the BMP server. The second BMP message carries at least one of the following information:

[0176] The number of routes rejected by network devices due to routing restrictions or prefix restrictions;

[0177] The number of routes rejected by a network device due to insufficient memory;

[0178] The number of routes in network devices that cannot be sent to the FIB due to insufficient forwarding resources;

[0179] The number of routes in a network device that could not be sent to the FIB due to FIB rejection;

[0180] The number of routes in network devices that cannot be sent to the FIB due to insufficient tag resources or SID resources;

[0181] The number of routes that cannot be advertised in a network device due to insufficient tag or SID resources;

[0182] The number of routes in a network device that are inactive due to the next-hop IP or tunnel being unreachable.

[0183] The functionality of the sending module 402 can also be described in the relevant description of step 301 in the above method embodiment.

[0184] Optionally, the second BMP message can be a statistical report message.

[0185] In summary, this application provides a network device that, after processing routes based on routing policies, can send the processed route information to a BMP server via BMP messages. Furthermore, the processed routes on the network device are not yet effective when the BMP message is sent. Therefore, the routing information received by the BMP server can be used to detect whether the routing policies in the network device are configured correctly. If the routing policy is misconfigured, since the processed routes have not yet taken effect in the network device, the routing policy can be modified promptly to avoid network failures. Thus, the network device provided by this application not only effectively improves the flexibility of BMP message sending but also ensures the reliability of routing policy configuration.

[0186] Figure 21 is a schematic diagram of another network device provided in an embodiment of this application. This network device can be applied to a system such as that shown in Figure 1 or Figure 2, and can implement the steps performed by the network device in the above method embodiments. As shown in Figure 21, the network device includes:

[0187] Sending module 501 is used to send BMP messages to the BMP server. The BMP messages carry at least one of the following information:

[0188] The number of routes rejected by network devices due to routing restrictions or prefix restrictions;

[0189] The number of routes rejected by a network device due to insufficient memory;

[0190] The number of routes in network devices that cannot be sent to the FIB due to insufficient forwarding resources;

[0191] The number of routes in a network device that could not be sent to the FIB due to FIB rejection;

[0192] The number of routes in network devices that cannot be sent to the FIB due to insufficient tag resources or SID resources;

[0193] The number of routes that cannot be advertised in a network device due to insufficient tag or SID resources;

[0194] The number of routes in a network device that are inactive due to the next-hop IP or tunnel being unreachable.

[0195] The functionality of the sending module 501 can be referred to the relevant description of step 301 in the above method embodiment.

[0196] Alternatively, the BMP message can be a statistical report message.

[0197] In summary, this application provides a network device that can report at least one new type of information via BMP messages. This effectively enriches the types of information that BMP messages can carry, and based on this information, problems in the network device can be quickly identified, ensuring the reliable operation of the network device.

[0198] Figure 22 is a schematic diagram of a BMP server provided in an embodiment of this application. This BMP server can be applied to systems such as those shown in Figure 1 or Figure 2, and can implement the steps performed by the BMP server in the above method embodiments. As shown in Figure 22, the BMP server includes:

[0199] The receiving module 601 is configured to receive a first BMP message sent by a network device, the first BMP message including routing information. This routing information is obtained by processing routes in the network device based on routing policies, and the processed routes have not yet taken effect on the network device when the first BMP message is sent. This routing information is used to detect whether the routing policy is configured accurately. The functional implementation of the receiving module 601 can be referred to the relevant description of step 202 in the above method embodiment.

[0200] Optionally, the first BMP message may also include an indication flag indicating that the processed route has not taken effect on the network device.

[0201] Alternatively, continuing to refer to Figure 22, the BMP server may also include:

[0202] The detection module 602 is used to detect whether the routing policy in the network device is configured accurately based on the routing information. The functionality of the detection module 602 can be found in the description of step 204 in the above method embodiment.

[0203] The sending module 603 is used to send a feedback message to the network device. The feedback message indicates whether the routing policy is configured correctly. The function of the sending module 603 can be referred to the relevant description of step 205 in the above method embodiment.

[0204] Optionally, the receiving module 601 can also be used to receive a second BMP message sent by the network device. The second BMP message carries at least one of the following information:

[0205] The number of routes rejected by network devices due to routing restrictions or prefix restrictions;

[0206] The number of routes rejected by a network device due to insufficient memory;

[0207] The number of routes in network devices that cannot be sent to the FIB due to insufficient forwarding resources;

[0208] The number of routes in a network device that could not be sent to the FIB due to FIB rejection;

[0209] The number of routes in network devices that cannot be sent to the FIB due to insufficient tag resources or SID resources;

[0210] The number of routes that cannot be advertised in a network device due to insufficient tag or SID resources;

[0211] The number of routes in a network device that are inactive due to the next-hop IP or tunnel being unreachable.

[0212] The functionality of the receiving module 601 can also be described in the relevant description of step 301 in the above method embodiment.

[0213] Alternatively, continuing to refer to Figure 22, the BMP server may also include:

[0214] Display module 604 is used to display BMP messages sent by the network device. The functionality of display module 604 can be found in the descriptions of steps 203 and 302 in the above method embodiments.

[0215] In summary, this application provides a BMP server that receives BMP messages reported by network devices, including routing information. This routing information is the routing information of the processed routes after routing policies have been implemented, but the processed routes have not yet taken effect on the network devices. Therefore, the routing information received by the BMP server can be used to detect whether the routing policies in the network devices are configured correctly. If the routing policy is misconfigured, since the processed routes have not yet taken effect in the network devices, the routing policy can be modified in a timely manner to avoid network failures. Thus, the solution provided by this application not only effectively improves the flexibility of BMP message sending but also ensures the reliability of routing policy configuration.

[0216] This application provides another BMP server, which can be applied to systems such as those shown in Figure 1 or Figure 2, and can implement the steps performed by the BMP server in the above method embodiments. As shown in Figure 22, the BMP server includes:

[0217] The receiving module 601 is configured to receive a BMP message sent by a network device, the BMP message carrying at least one of the following information:

[0218] The number of routes rejected by network devices due to routing restrictions or prefix restrictions;

[0219] The number of routes rejected by a network device due to insufficient memory;

[0220] The number of routes in network devices that cannot be sent to the FIB due to insufficient forwarding resources;

[0221] The number of routes in a network device that could not be sent to the FIB due to FIB rejection;

[0222] The number of routes in network devices that cannot be sent to the FIB due to insufficient tag resources or SID resources;

[0223] The number of routes that cannot be advertised in a network device due to insufficient tag or SID resources;

[0224] The number of routes in a network device that are inactive due to the next-hop IP or tunnel being unreachable.

[0225] The functionality of the receiving module 601 can be described in the relevant description of step 301 in the above method embodiment.

[0226] In summary, this application provides a BMP server that can include at least one new type of information in the BMP messages sent by network devices. This effectively enriches the types of information that BMP messages can carry, and based on this information, it is easier to quickly identify problems in network devices, ensuring their reliable operation.

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

[0228] It should be understood that the network device and BMP server provided in the embodiments of this application can be implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD can be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof. Furthermore, the message sending method provided in the above method embodiments can also be implemented in software. When the message sending method provided in the above method embodiments is implemented in software, the network device and BMP server may include software modules for implementing the above method.

[0229] Figure 23 is a schematic diagram of a message sending device according to an embodiment of this application. This message sending device can be applied to systems such as those shown in Figure 1 or Figure 2, and can be a network device or a BMP server within that system. Referring to Figure 23, the message sending device includes: a processor 701, a memory 702, a network interface 703, and a bus 704.

[0230] The memory 702 stores a computer program 7021, which is used to implement various application functions. The processor 701 executes the computer program 7021 to implement the message sending method provided in the above-described method embodiments. For example, the processor 701 executes the computer program 7021 to implement the functions of each module in the device shown in any of the figures 20 to 22.

[0231] The processor 701 can be a central processing unit (CPU), but it can also be other general-purpose processors, digital signal processors (DSPs), ASICs, FPGAs, graphics processing units (GPUs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0232] The memory 702 can be volatile memory or non-volatile memory, or it can include both. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM).

[0233] There can be multiple network interfaces 703, and each network interface 703 is used to establish communication connections with other devices (which can be wired or wireless). In this embodiment, the network interface 703 is used to send and receive messages. These other devices can be terminals, servers, virtual machines, or other network devices.

[0234] Bus 704 is used to connect processor 701, memory 702, and network interface 703. Furthermore, in addition to the data bus, bus 704 may also include a power bus, control bus, and status signal bus, etc. However, for clarity, all buses are labeled as bus 704 in the figure.

[0235] If the message sending device is a network device, the detailed processing procedure of the processor 701 can be found in the steps performed by the network device in the above method embodiment; if the message sending device is a BMP server, the detailed processing procedure of the processor 701 can be found in the steps performed by the BMP server in the above method embodiment; these will not be repeated here.

[0236] Figure 24 is a schematic diagram of another network device provided in an embodiment of this application. This network device can be applied to systems such as those shown in Figure 1 or Figure 2. As shown in Figure 24, the network device may include: a main control board 801 and at least one interface board (interface board is also called a line card or service board), such as interface board 802 and interface board 803 shown in Figure 24. In the case of multiple interface boards, the network device may further include a switching board 804, which is used to complete data exchange between the interface boards.

[0237] The main control board 801, also known as the main processing unit (MPU) or route processor card, is used for system management, equipment maintenance, and protocol processing. The main control board 801 primarily consists of three types of functional units: a system management control unit, a system clock unit, and a system maintenance unit. The main control board 801 includes a central processing unit 8011 and a memory 8012.

[0238] Interface boards 802 and 803, also known as line processing units (LPUs), line cards, or service boards, provide various service interfaces and enable message forwarding. These service interfaces may include: packet over SONET / SDH (POS) interfaces, gigabit Ethernet (GE) interfaces, and asynchronous transfer mode (ATM) interfaces. SONET refers to synchronous optical network, and SDH refers to synchronous digital hierarchy. The main control board 801, interface boards 802 and 803 are interconnected with the system backplane via a system bus. As shown in Figure 24, interface board 802 includes one or more central processing units (CPUs) 8021. The CPUs 8021 control and manage interface boards 802 and communicate with the CPU 8011 on the main control board 801. The memory 8024 on the interface board 802 is used to store forwarding table entries. The network processor 8022 can forward packets by looking up the forwarding table entries stored in the memory 8024. The memory 8024 can also be used to store program code.

[0239] The interface board 802 also includes one or more physical interface cards 8023, which are used to receive messages sent by the previous hop node and send processed messages to the next hop node according to the instructions of the central processing unit 8021.

[0240] Furthermore, it is understood that the central processing unit 8021 and / or network processor 8022 in the interface board 802 of Figure 24 can be dedicated hardware or chips, such as ASICs, to implement the above functions. This implementation method is commonly referred to as using dedicated hardware or chips for the forwarding plane. In another embodiment, the central processing unit 8021 and / or network processor 8022 can also use general-purpose processors, such as general-purpose CPUs, to implement the functions described above.

[0241] Furthermore, it should be understood that there may be one or more main control boards 801, and when there are multiple boards, they can include a primary main control board and a backup main control board. There may also be one or more interface boards; the stronger the data processing capability of the network device, the more interface boards it provides. As shown in Figure 24, the network device includes interface boards 802 and 803. When a distributed forwarding mechanism is used, the structure of interface board 803 is basically the same as that of interface board 802, and the operation on interface board 803 is basically similar to that on interface board 802. For simplicity, it will not be described in detail. When the network device has multiple interface boards, these multiple interface boards can communicate with each other through one or more switching network boards 804, and load sharing and redundancy backup can be achieved to provide high-capacity data exchange and processing capabilities.

[0242] In a centralized forwarding architecture, this network device does not require an 804 switching board; the interface board handles the processing of all system service data. Therefore, the data access and processing capabilities of a distributed network device are greater than those of a centralized network device. The specific architecture adopted depends on the specific network deployment scenario, and no restrictions are imposed here.

[0243] In this embodiment, memory 8012 and memory 8024 can be ROM or other types of static storage devices capable of storing static information and instructions, or RAM or other types of dynamic storage devices capable of storing information and instructions. They can also be EEPROM, compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disks or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but are not limited thereto. Memory 8024 in interface board 802 can exist independently and be connected to central processing unit 8021 via a communication bus; alternatively, memory 8024 can be integrated with central processing unit 8021. Memory 8012 in main control board 801 can exist independently and be connected to central processing unit 8011 via a communication bus; alternatively, memory 8012 can be integrated with central processing unit 8011.

[0244] The program code stored in memory 8024 is executed under the control of central processing unit 8021, and the program code stored in memory 8012 is executed under the control of central processing unit 8011. Central processing unit 8021 and / or central processing unit 8011 can implement the message sending method provided in the above-described method embodiments by executing the program code. The program code stored in memory 8024 and / or memory 8012 may include one or more software units, which may be the functional modules shown in FIG. 20 or FIG. 21.

[0245] In this embodiment of the application, the physical interface card 8023 can be any transceiver-like device used to communicate with other devices or communication networks, such as Ethernet, radio access network (RAN), wireless local area network (WLAN), etc.

[0246] Alternatively, the network devices shown in Figures 20, 21, or 23 can also be implemented using the structure shown in Figure 24.

[0247] This application also provides a computer-readable storage medium storing instructions that, when executed by a processor, cause the processor to perform the steps performed by a network device or a BMP server as described in the above method embodiments.

[0248] This application also provides a computer program product containing instructions that, when executed on a processor, cause the processor to perform the steps performed by a network device or BMP server as described in the above method embodiments.

[0249] This application also provides a message sending system. As shown in FIG1, the system includes a network device 01 and a BMP server 02. The network device 01 can be used to implement the methods shown in steps 101 and 102 of the above method embodiments, or it can be used to implement the methods shown in steps 201, 202, and 206. Alternatively, it can be used to implement the method shown in step 301. The structure of the network device 01 can be seen in FIGS. 20, 21, 23, and 24.

[0250] The BMP server 02 can be used to receive a first BMP message and / or a second BMP message sent by the network device 01. Alternatively, it can also be used to implement the methods shown in steps 203 to 205 in the above method embodiments. Furthermore, the structure of the BMP server 02 can be seen in Figures 22, 23, and 24.

[0251] In the embodiments of this application, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance. In the embodiments of this application, the term "at least one" refers to one or more, and "multiple" refers to two or more. In the embodiments of this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship.

[0252] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the embodiments of this application, and are not intended to limit them; although the embodiments of this application have been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of this application.

Claims

1. A message sending method, characterized in that, Applied to network devices, the method includes: Based on the routing policy, the routes in the network device are processed to obtain the routing information of the processed routes; A first BMP message is sent to the Border Gateway Protocol (BGP) Monitoring Protocol (BMP) server, the first BMP message including the routing information; wherein, when the first BMP message is sent to the BMP server, the processed route is not effective on the network device.

2. The method according to claim 1, characterized in that, The first BMP message also includes an indication identifier, which indicates that the processed route is not effective on the network device.

3. The method according to claim 2, characterized in that, The first BMP message includes a peer header, wherein the peer header carries the indication identifier.

4. The method according to claim 3, characterized in that, Each peer message header includes a peer tag field, which carries the indication identifier.

5. The method according to claim 2, characterized in that, The first BMP message includes a common header, and the message type field of the common header carries the indication identifier.

6. The method according to any one of claims 1 to 5, characterized in that, The first BMP message includes at least one of route monitoring message, route mirroring message, and statistics report message.

7. The method according to any one of claims 1 to 6, characterized in that, The routing information includes: address prefix; Alternatively, the routing information may include: an address prefix and at least one routing attribute.

8. The method according to any one of claims 1 to 7, characterized in that, The routing policy is a BGP routing policy, and the route is a BGP route.

9. The method according to any one of claims 1 to 7, characterized in that, The routing policy is a routing policy of other routing protocols, which are protocols other than BGP that affect BGP routes, and the other routing protocols include at least one of Interior Gateway Protocol (IGP) and Open Shortest Path First (OSPF) protocol.

10. The method according to any one of claims 1 to 9, characterized in that, The routing policies include: ingress policies, egress policies, route import policies, route aggregation policies, route selection policies, or VPN instance policies.

11. The method according to any one of claims 1 to 10, characterized in that, The method further includes: Receive a feedback message for the first BMP message, the feedback message being used to indicate whether the routing policy is configured correctly.

12. The method according to claim 11, characterized in that, The method further includes: Based on the feedback message, either roll back the processed route or make the processed route effective.

13. The method according to any one of claims 1 to 12, characterized in that, The method further includes: A second BMP message is sent to the BMP server, the second BMP message carrying at least one of the following information: The number of routes that the network device rejects due to routing restrictions or prefix restrictions; The number of routes rejected by the network device due to insufficient memory; The number of routes in the network device that cannot be sent to the forwarding information table (FIB) due to insufficient forwarding resources; The number of routes in the network device that could not be sent to the FIB due to FIB rejection; The number of routes in the network device that cannot be sent to the FIB due to insufficient tag resources or segment identifier (SID) resources; The number of routes that cannot be published in the network device due to insufficient tag resources or SID resources; The number of routes in the network device that are inactive due to the next-hop Internet Protocol IP or tunnel being unreachable.

14. The method according to claim 13, characterized in that, The second BMP message is a statistical report message.

15. A message sending method, characterized in that, Applied to network devices, the method includes: Send a BMP message to the BMP server, the BMP message carrying at least one of the following information: The number of routes that the network device rejects due to routing restrictions or prefix restrictions; The number of routes rejected by the network device due to insufficient memory; The number of routes that cannot be sent to the FIB in the network device due to insufficient forwarding resources; The number of routes in the network device that could not be sent to the FIB due to FIB rejection; The number of routes in the network device that cannot be sent to the FIB due to insufficient tag resources or SID resources; The number of routes that cannot be published in the network device due to insufficient tag resources or SID resources; The number of routes in the network device that are inactive due to the next-hop IP or tunnel being unreachable.

16. A message sending method, characterized in that, Applied to BMP servers, the method includes: Receive a first BMP message sent by a network device, the first BMP message including routing information; The routing information is obtained by processing routes in the network device based on the routing policy, and the processed routes are not effective on the network device when the first BMP message is sent. The routing information is used to detect whether the routing policy is configured accurately.

17. The method according to claim 16, characterized in that, The first BMP message also includes an indication identifier, which indicates that the processed route is not effective on the network device.

18. The method according to claim 16 or 17, characterized in that, The method further includes: Based on the routing information, detect whether the routing policy in the network device is configured accurately; A feedback message is sent to the network device, the feedback message indicating whether the routing policy is configured correctly.

19. The method according to any one of claims 16 to 18, characterized in that, The method further includes: Receive a second BMP message sent by the network device, the second BMP message carrying at least one of the following information: The number of routes that the network device rejects due to routing restrictions or prefix restrictions; The number of routes rejected by the network device due to insufficient memory; The number of routes that cannot be sent to the FIB in the network device due to insufficient forwarding resources; The number of routes in the network device that could not be sent to the FIB due to FIB rejection; The number of routes in the network device that cannot be sent to the FIB due to insufficient tag resources or SID resources; The number of routes that cannot be published in the network device due to insufficient tag resources or SID resources; The number of routes in the network device that are inactive due to the next-hop IP or tunnel being unreachable.

20. The method according to any one of claims 16 to 19, characterized in that, The method further includes: Displays the BMP messages sent by the network device.

21. A message sending method, characterized in that, Applied to BMP servers, the method includes: Receive a BMP message sent by a network device, the BMP message carrying at least one of the following information: The number of routes that the network device rejects due to routing restrictions or prefix restrictions; The number of routes rejected by the network device due to insufficient memory; The number of routes that cannot be sent to the FIB in the network device due to insufficient forwarding resources; The number of routes in the network device that could not be sent to the FIB due to FIB rejection; The number of routes in the network device that cannot be sent to the FIB due to insufficient tag resources or SID resources; The number of routes that cannot be published in the network device due to insufficient tag resources or SID resources; The number of routes in the network device that are inactive due to the next-hop IP or tunnel being unreachable.

22. A message sending method, characterized in that, The method is applied to a message sending system, which includes a network device and a BMP server, and includes: The network device processes the routes in the network device based on the routing policy to obtain the routing information of the processed routes; The network device sends a first BMP message to the BMP server. The first BMP message includes the routing information. When the network device sends the first BMP message to the BMP server, the processed routing is not effective on the network device. The BMP server receives the routing information.

23. The method according to claim 22, characterized in that, The first BMP message also includes an indication identifier, which indicates that the processed route is not effective on the network device.

24. The method according to claim 22 or 23, characterized in that, The method further includes: The BMP server detects whether the routing policy in the network device is configured correctly based on the routing information. The BMP server sends a feedback message to the network device, the feedback message being used to indicate whether the routing policy is configured correctly. The network device may either roll back the processed route based on the feedback message, or activate the processed route.

25. The method according to any one of claims 22 to 24, characterized in that, The method further includes: The network device sends a second BMP message to the BMP server, the second BMP message carrying at least one of the following information: The number of routes that the network device rejects due to routing restrictions or prefix restrictions; The number of routes rejected by the network device due to insufficient memory; The number of routes that cannot be sent to the FIB in the network device due to insufficient forwarding resources; The number of routes in the network device that could not be sent to the FIB due to FIB rejection; The number of routes in the network device that cannot be sent to the FIB due to insufficient tag resources or SID resources; The number of routes that cannot be published in the network device due to insufficient tag resources or SID resources; The number of routes in the network device that are inactive due to the next-hop IP or tunnel being unreachable.

26. The method according to claim 25, characterized in that, The method further includes: The BMP server displays the information carried in the second BMP message.

27. A message sending method, characterized in that, The method is applied to a message sending system, which includes a network device and a BMP server, and includes: The network device sends BMP messages to the BMP server; The BMP server receives information carried in the BMP message, wherein the BMP message carries at least one of the following: The number of routes that the network device rejects due to routing restrictions or prefix restrictions; The number of routes rejected by the network device due to insufficient memory; The number of routes that cannot be sent to the FIB in the network device due to insufficient forwarding resources; The number of routes in the network device that could not be sent to the FIB due to FIB rejection; The number of routes in the network device that cannot be sent to the FIB due to insufficient tag resources or SID resources; The number of routes that cannot be published in the network device due to insufficient tag resources or SID resources; The number of routes in the network device that are inactive due to the next-hop IP or tunnel being unreachable.

28. A network device, characterized in that, The network device includes: a memory, a processor, and a computer program stored in the memory and capable of running on the processor, wherein the processor executes the computer program to implement the method as described in any one of claims 1 to 15.

29. A BMP server, characterized in that, The BMP server includes: a memory, a processor, and a computer program stored in the memory and capable of running on the processor, wherein the processor executes the computer program to implement the method as described in any one of claims 16 to 21.

30. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed on a processor, cause the processor to perform the method as described in any one of claims 1 to 21.

31. A computer program product containing instructions, characterized in that, The instructions are executed by the processor to implement the method as described in any one of claims 1 to 21.

32. A message sending system, characterized in that, The message sending system includes: network equipment and a BMP server; The network device is used to implement the method as described in any one of claims 1 to 15, and the BMP server is used to implement the method as described in any one of claims 16 to 21.

Images