A method and device for updating a BGP update packet

Abstract

The application discloses a BGP Update message updating method and device, and the method comprises the following steps: receiving a first BGP Update message from a neighbor device; analyzing the first BGP Update message to obtain the types of various routes; matching the types of various routes obtained by analysis with the route types supported by the neighbor device configured locally; determining the matched route types in the various route types, and generating a second BGP Update message according to the matched route types; and sending the second BGP Update message to a BMP server after encapsulation. The method utilizes the modular design feature of the BGP message, analyzes and determines the route types needed to be reported, generates new BGP Update messages for the route types needed to be reported, and enables the routes in the new BGP Update messages reported to the BMP server to be analyzed correctly.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of network communication technology, in particular to a BGP Update packet updating method and device. BACKGROUND

[0002] Currently, if a user wants to check the routes of a certain network device, the BGP neighbor state and other related information of the network device, the user can check the information by logging into the network device. The BGP Monitoring Protocol (BMP) is a protocol for monitoring BGP neighbors, which provides a more convenient way of use than screen output, and is simple, easy to use and maintain. The BMP can access the state and route information of a specified BGP neighbor, and can also periodically display statistical information.

[0003] In actual networking, the network device to be monitored is called a client, and the BMP monitoring server is called a monitoring end or BMP server. One client can be connected to multiple monitoring servers. The address of the monitoring server, the listening port number and the like need to be configured in the client, so as to establish a TCP connection with the monitoring server.

[0004] The client collects the route information received by the monitored BGP neighbor, and generates a BGP Update packet. According to the BMP specification, a BMP header is encapsulated in front of the BGP Update packet to obtain a BMP packet. After receiving various BMP packets, the monitoring server analyzes the packet content according to the BMP specification and the BGP specification, and presents the information to the user through a visual interface.

[0005] A current route reporting method is that the client sends a refresh request to the monitoring neighbor, receives the BGP Update packet reported by the monitoring neighbor, and directly reports the BGP Update packet to the monitoring server. This route reporting method is simple and does not require additional memory consumption, but every time a monitoring server is added, a refresh request needs to be triggered to the monitoring neighbor again, which occupies network bandwidth to achieve, and the client reports all the routes carried in the received BGP Update packets to the monitoring server. If the route types of these reported routes are not supported by the monitoring server, the monitoring server may occur an error due to the inability to correctly parse the BGP Update packet. SUMMARY

[0006] In view of this, the application provides a BGP Update message updating method and device, which are used for solving the problems that the BGP Update message is directly reported to the monitoring server by the client, the monitoring server cannot correctly parse the message and errors occur, and the network bandwidth resources are occupied by reapplying and sending the updating message. Specifically, the following technical solutions are disclosed:

[0007] In a first aspect, the application provides a BGP Update message updating method, which can be applied to a network device, such as a BGP client. The method comprises the following steps: receiving a first BGP Update message from a neighbor device; parsing the first BGP Update message to obtain the types of routes carried in the first BGP Update message; matching the types of the routes with the types of routes supported by the neighbor device and configured locally; determining matched route types from the types of the routes, and generating a second BGP Update message according to the matched route types; and sending the second BGP Update message to a BMP server after encapsulation.

[0008] In combination with the first aspect, in a possible implementation manner of the first aspect, the parsing of the first BGP Update message further obtains address family information AFI fields and sub-address family information SAFI fields of each route type, the AFI fields and the SAFI fields being used to indicate address families to which the current routes belong; and the matching of the types of the routes with the types of routes supported by the neighbor device and configured locally comprises: judging whether the address families indicated by the AFI fields and the SAFI fields of each route are all same as address family information supported by the neighbor device and configured to be reported.

[0009] In combination with the first aspect, in another possible implementation manner of the first aspect, the determining of the matched route types from the types of the routes and the generating of the second BGP Update message according to the matched route types can specifically comprise the following two manners:

[0010] In the first manner, the unmatched route types are obtained, the unmatched route types are removed from the first BGP Update message, and the remaining matched route types generate the second BGP Update message.

[0011] In the second manner, the unmatched route types are obtained, the unmatched route types are marked in the first BGP Update message, and the second BGP Update message is generated, wherein the marked route types are not parsed by the BMP server after being reported.

[0012] Optionally, the indication information "1" or "0" can be configured to mark whether the route type needs to be parsed, such as setting the indication information as "0" to represent shielding the route, and "1" to represent not shielding the route.

[0013] With reference to the first aspect, in a further possible implementation manner of the first aspect, before the encapsulating the second BGP Update message, the method further includes: judging whether a keep-all-routes function is configured on a neighbor of the matching route type and locally established with the neighbor device; and if not configured, performing the step of encapsulating the second BGP Update message and sending to the BMP server.

[0014] With reference to the first aspect, in a further possible implementation manner of the first aspect, the method further includes: if configured, generating a self-assembly packet of real-time route change according to the second BGP Update message, and sending the self-assembly packet to the BMP server.

[0015] With reference to the first aspect, in a further possible implementation manner of the first aspect, after the similarity matching of the types of the parsed routes, the method further includes: if all the route types are matched, judging whether a keep-all-routes function is configured on the neighbor; and if not configured, encapsulating the first BGP Update message and sending to the BMP server.

[0016] With reference to the first aspect, in a further possible implementation manner of the first aspect, the method further includes: if configured, generating a self-assembly packet of real-time route change according to the first BGP Update message, and sending the self-assembly packet to the BMP server.

[0017] In the second aspect, the embodiments of the present application further disclose a BGP Update message updating device, which is used for implementing the method in the first aspect or any implementation manner of the first aspect. The device includes:

[0018] a receiving unit configured to receive a first BGP Update message from a neighbor device;

[0019] a parsing unit configured to parse the first BGP Update message to obtain the types of routes carried in the first BGP Update message;

[0020] a matching unit configured to match the types of the parsed routes with route types supported by the neighbor device configured locally, and determine matching route types in the route types;

[0021] The generating unit is configured to generate a second BGP Update message according to the matched route type.

[0022] The sending unit is configured to send the encapsulated second BGP Update message to the BMP server.

[0023] In a third aspect, an embodiment of the present application further discloses a network device, comprising: at least one processor; and a memory connected with the at least one processor in communication; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the updating method of the BGP Update message according to the first aspect or any implementation manner of the first aspect.

[0024] In a fourth aspect, an embodiment of the present application further discloses a computer readable storage medium, which stores a computer program, and the computer program is executed by a processor to implement the updating method of the BGP Update message according to the first aspect or any implementation manner of the first aspect.

[0025] The method and device provided by the embodiment utilize the characteristics of the modular design (TLV) of the BGP message, determine the route type to be reported by quickly analyzing the BGP Update message, and recombine the route type to be reported to generate a new BGP Update message. Since the routes in the new BGP Update message reported to the BMP server can be correctly analyzed, the problem that the routes received by the BMP server cannot be completely analyzed and errors occur is solved. The method realizes accurate reporting of the pre-policy route and correct analysis of the BGP Update message sent by the client by the BMP server. BRIEF DESCRIPTION OF DRAWINGS

[0026] In order to more clearly illustrate the technical solutions of the embodiments of the present application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or the prior art description. Obviously, the drawings in the following description are some embodiments of the present application, and those skilled in the art can obtain other drawings according to these drawings without creative labor.

[0027] Figure 1 A schematic diagram of a BGP network environment provided by an embodiment of the present application;

[0028] Figure 2 A schematic diagram of the format of a BGP Update message provided by an embodiment of the present application;

[0029] Figure 3aA schematic diagram illustrating the format of the MP_REACH_NLRI field provided in an embodiment of the present invention;

[0030] Figure 3b A schematic diagram illustrating the format of the MP_UNREACH_NLRI field provided for an embodiment of the present invention;

[0031] Figure 4 A flowchart illustrating a BGP Update message update method provided in an embodiment of the present invention;

[0032] Figure 5 A flowchart illustrating another method for updating a BGP Update message provided in an embodiment of the present invention;

[0033] Figure 6 This is a structural block diagram of a message update device provided in an embodiment of the present invention;

[0034] Figure 7 This is a schematic diagram of the structure of a network device provided in an embodiment of the present invention. Detailed Implementation

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

[0036] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0037] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the corresponding listed items.

[0038] It should be understood that although the terms first, second, etc., may be used in this application to describe various information, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another.

[0039] Firstly, the technical scenario and related technical terms involved in the present application are described.

[0040] The technical solution of the embodiment of the present application is applied to a Border Gateway Protocol (BGP) network, referring to Figure 1 , which is a schematic diagram of a BGP network environment. The network devices in the BGP network environment use TCP as their transport layer protocol.

[0041] Among them, BMP is an extended function of BGP routing protocol, which has the characteristics of simple working mechanism and clear purpose (collecting specific information). Since all configurations on BMP can be completed on the device as a client, the deployment difficulty is low.

[0042] As shown in Figure 1 , the devices in BMP include the following roles:

[0043] Client, also known as BMP client: a device configured with BMP function, which establishes a TCP connection with the monitoring server by configuring the address and listening port number of the monitoring server on the client. Among them, one client can connect one or more monitoring servers.

[0044] Monitoring end, monitoring server, also known as BMP server, is used to receive the BMP message sent by the client and analyze the BMP message reported by the client.

[0045] Monitored peer, which is used to establish a BGP session with the client. In this embodiment, the monitoring end and the client are each other's neighbors, so the monitoring end is the monitoring neighbor or neighbor device of the client.

[0046] In this example, the client is device B (Device B), the monitored peer is device A (Device A) and device C (Device C), and the monitoring end is the BMP server. Among them, device A, device B and device C establish BGP session between each other, and device B is configured with BMP function to monitor its BGP running state and route change. In this networking, the monitoring server (BMP server) is the monitoring end, device B is the client (BMP client), and device A and device C which establish BGP session with device B are the monitored peer (Monitored peer).

[0047] The following describes the related concepts of BGP route and BGP Update message between devices.

[0048] 1. BGP route and BGP Update message

[0049] BGP routers use Update messages to advertise route information to their peers. BGP advertises one or more routes with the same path attributes in one Update message. BGP routes with different path attributes are advertised using different Update messages. BGP Update messages can be used to withdraw one or more BGP routes in addition to advertising BGP routes to peers.

[0050] Referring to Figure 2 The format of a BGP Update message is as follows: if the Type in the BGP message header is 2, the message is an UPDATE message (1 octet). The contents of the message following the message header are as follows (RFC 4271). The UPDATE message is used to advertise routes. The fields are shown, and the descriptions of the fields are as follows:

[0051] Withdrawn Routes Length: An Update message can contain zero, one, or more BGP routes that are to be withdrawn. This field is an unsigned integer that indicates the length (in bytes) of the Withdrawn Routes field in the Update message. Optionally, the withdrawn routes length is denoted by the symbol "L1".

[0052] Withdrawn Routes: This field is used to store the BGP route prefixes that are to be withdrawn. If there are multiple BGP routes to be withdrawn using this Update message, this field contains a list of BGP route prefixes, each of which contains two elements, the prefix length and the route prefix.

[0053] Total Path Attribute Length: This field indicates the total length of the path attributes in the Update message. For example Figure 2 In the example, the total path attribute length is denoted by the symbol "L2".

[0054] Path Attributes: When a BGP router uses an Update message to advertise BGP routes to a peer, the message contains the path attributes field. BGP defines a rich set of path attribute types.

[0055] Network Layer Reachability Information: This field is used to store the BGP route prefixes that need to be announced. If there are multiple BGP routes that need to be announced using this Update message, this field will contain a list of BGP route prefixes, each of which contains two elements, the prefix length and the route prefix. Of course, one BGP Update message is used to announce route prefixes with the same path attribute.

[0056] Withdrawn Routes (ipv4 withdrawn routes) start position: offset 21 bytes from the BGP message header; if Withdrawn Routes Length is 0, it means there is no such message, otherwise the message ends at 21+Withdrawn Routes Length position. Path Attributes (variable) start position: offset 23 bytes from the BGP message header, length Total Path Attribute Length. Network Layer Reachability Information (ipv4 route) start position: offset 23+L1+L2 bytes from the BGP message header.

[0057] Among them, the path attribute Path Attributes (variable) can be composed of multiple TLV (Tag, Length, Value), the format is as follows: flag (1 octets) type (1 octets) | Length (1 or 2 octets) | Value

[0058] Among them, the flag has a flag bit to indicate the size of the Length field behind, such as occupying 1 byte or 2 bytes.

[0059] For updated routes (Update routes), BGP merges path attributes Path Attributes with the same attributes together and publishes them, with attribute information in front and one / group prefix information with the same attributes following. Only one such route can be published in an Update message.

[0060] With the wide application of BGP in MPLS VPN, multicast and non-IPv4 address family, this fixed structure cannot fully meet the application requirements. In order to solve the support of BGP for multiple network layer protocols, the IETF (Internet Engineering Task Force) extended the address family capability of BGP-4 to form MP-BGP (Multi-Protocol BGP), so that BGP can provide routing information for multiple applications. In RFC 4760 (Multiprotocol Extensions for BGP-4), two new optional non-transitive attributes are defined, and both of the attributes are used in the multiple protocol extensions of BGP:

[0061] Extended Protocol Reachable NLRI (MP_REACH_NLRI, attribute type 14)

[0062] Extended Protocol Unreachable NLRI (MP_UNREACH_NLRI, attribute type 15)

[0063] The two extended attributes are applicable to all BGP protocol extensions, and in order to distinguish different extension types, the AFI (Address Family Information) and SAFI (Sub-Address Family Information) are carried in the two attributes. Among them, AFI 1 is assigned to IPv4, and 2 is assigned to IPv6.

[0064] Specifically, (1) MP_REACH_NLRI (Attribute code: 14)

[0065] As shown in Figure 3a , a complete MP_REACH_NLRI attribute structure includes the following contents:

[0066] First, address family information: including AFI and SAFI. Among them, AFI carries the network layer protocol identifier related to the network address; SAFI carries additional information of the network layer reachable information in the related attribute.

[0067] Second, next hop information: including the length of the next hop network address (Length of Next Hop Network Address) and the network address of the next hop (Network Address of Next Hop). In the BGP IPv4 definition, the next hop is an address attribute passed, and the attribute type is 3. After the address extension of BGP, the next hop address also needs to be extended, and therefore is passed in the MP_REACH_NLRI attribute.

[0068] Third, prefix information: placed in the NLRI field of the attribute, different address family format.

[0069] In addition, Figure 3a In the middle of the definition of a byte of the reserved (1 octet Reserved) unused, must be set to all 0.

[0070] In addition, see Figure 3b , the embodiment also provides (2) MP_UNREACH_NLRI (Attribute code: 15) format, wherein the extended address unreachable attribute announcement unreachable route, an Update message containing MP_UNREACH_NLRI does not need to carry MP_UNREACH_NLRI attribute except any other path attribute. Its format is shown in Figure 3b .

[0071] In the embodiment, MP_REACH_NLRI (other route type update route): from the starting position of Path Attributes (variable) to determine whether the attribute type is 14, if not, then proceed according to the TLV definition content offset, determine the next type, until the attribute type is 14 or the end of Path Attributes (variable) is reached.

[0072] In addition, after finding the MP_REACH_NLRI attribute position, the address family to which the route belongs can be determined by the starting AFI and SAFI fields. Similarly, the query process of MP_UNREACH_NLRI (other route type withdraw route) is similar to that of "MP_REACH_NLRI", which will not be described here.

[0073] As can be seen from the above description, each route information in the BGP Update message can quickly find the starting position and length, and obtain the AFI and SAFI information of the route.

[0074] 2, keep-all-routes command function

[0075] The peer keep-all-routes command is used to save all BGP route update information from the specified peer (group) since the BGP connection is established, including the original attribute and the final attribute. In addition, the undo peer keep-all-routes command is used to restore the default configuration. By default, only the BGP route update information from the peer through the configured import policy, i.e., the final attribute information, is saved.

[0076] For example, the keep-all-routes command format is as follows:

[0077] peer { group-name | ipv4-address | ipv6-address} keep-all-routes;

[0078] undo peer { group-name | ipv4-address | ipv6-address} keep-all-routes;

[0079] After the import policy of BGP is changed, in order to make the new policy take effect immediately, the BGP connection can be reset, but this will cause a short-term interruption of the BGP connection. For the BGP peer that does not support the Route-Refresh capability, the peer keep-all-routes command can be configured to retain all original routes of the peer, and at this time, the BGP connection does not need to be reset to complete the refresh of the route table.

[0080] In the process that the client reports the BGP Update packet to the monitoring server, the reporting of the routes received by the monitoring neighbor (monitoring peer) is further divided into a pre-policy mode and a post-policy mode. The pre-policy mode refers to the monitoring routes and attributes before the policy, and the post-policy mode refers to the monitoring routes and attributes after the policy.

[0081] In one possible reporting mode, the monitoring neighbor (monitoring peer) is configured with the keep-all-routes feature, sends a refresh request to the neighbor (monitoring device A or C) once, saves the pre-policy attributes of the routes, and then self-packs and reports to the monitoring server. This mode needs to save two copies of attributes for each route, and therefore needs to consume additional memory (the larger the route quantity, the more memory resources are consumed), but the monitoring server does not need to trigger a refresh request to the neighbor device again when collecting routes.

[0082] If the first mode is adopted in consideration of memory occupation, the client sends the report mode of the refresh request to the monitoring neighbor, which will cause some unnecessary address family routes to be reported, and at this time these unsupported routes can cause the monitoring server to be unable to be parsed and various problems can occur. If the second mode is adopted for reporting, the keep-all-routes function is configured for the address family with a small amount of routes, which will occupy more device memory.

[0083] Based on this, the technical scheme provided by the embodiments of the present application enables the user to enable the monitoring neighbor (peer) only on the address family supported by the monitoring server, thereby solving the above problems. Thus, the problem of errors caused by the monitoring server being unable to parse unsupported routes can be solved, and the configuration of the keep-all-routes function to occupy more device memory resources is also avoided.

[0084] The method provided by the embodiments will be described in detail below.

[0085] Referring to Figure 4 A method for updating a BGP Update packet is provided for the embodiments, which can be applied to a client in the application scenarios described above, such as device B, and more specifically, the BGP processing module in the client can execute the method, and the method comprises the following steps:

[0086] Step 101: receiving a first BGP Update packet from a neighbor device.

[0087] The first BGP update packet conforms to the TLV protocol framework, that is, it conforms to the TLV encoding rule, and the TLV protocol framework or encoding rule is based on binary encoding, and data is encoded as a byte array in the form of (T-L-V). Moreover, the format of the first BGP Update packet is as shown in Figure 2 .

[0088] In this example, the client (device B) receives one or more BGP Update packets reported from a monitoring neighbor, such as device A or device C.

[0089] Step 102: parsing the first BGP Update packet to obtain the type of each route carried in the first BGP Update packet.

[0090] The content (field) of the first BGP Update packet is all designed by the module (TLV mechanism, such as according to the specification of RFC4271), and after receiving the first BGP Update packet, the client parses the first BGP Update packet according to the designed TLV mechanism to obtain the information of one or more route types carried in the packet.

[0091] In this embodiment, the first BGP Update message is parsed to obtain at least one of the following route type fields, respectively:

[0092] Withdrawn Routes (ipv4 withdrawn routes), Path Attributes field, Network Layer Reachability Information (ipv4 routes). Among them, the Path Attributes field includes at least one of MP_REACH_NLRI field or MP_UNREACH_NLRI field.

[0093] Wherein, the format and content of the extended protocol reachable NLRI field (MP_REACH_NLRI) and the extended protocol unreachable NLRI field (MP_UNREACH_NLRI) are shown in the above Figure 3a and Figure 3b As shown, including address family information AFI field and sub-address family information SAFI field, this embodiment will not be repeated here.

[0094] According to the field content shown in the above Figure 3a and Figure 3b The first BGP Update message is parsed in step 102 to obtain the AFI field and the SAFI field corresponding to each route type, according to which the address family to which the current route belongs can be indicated, such as indicating IPv4 or IPv6.

[0095] Step 103: Determine whether the parsed route types match all supported route types, that is, match the route types parsed by the local configuration of the neighbor device supported by the route types.

[0096] Among them, the local configuration of the neighbor device supported by the route type can be obtained in advance and stored in the client. For example, before the above steps 101 and 102, it also includes:

[0097] Step 100: The local configuration of the neighbor device supported by the route type.

[0098] For example, the device B of the client establishes a neighbor with the device A, and all routes of the neighbor of the device A configured on the device B are set when the device B and the device A establish a monitoring neighbor relationship.

[0099] In step 103, the route types parsed, such as IPv4, IPv6 and other route types, are compared with the routes set locally by the client to determine whether the parsed routes are all contained in the locally set routes.

[0100] Step 104: If not matched, i.e. each route matches the local set route part, and the part is not matched, then determine the matched route type in the each route type, and generate a second BGP Update message according to the matched route type.

[0101] Step 105: After encapsulating the second BGP Update message, send it to the BMP server.

[0102] Specifically, step 105 includes: first encapsulating the second BGP Update message into a first RM (Route Monitoring) message, which also conforms to the TLV design specification. Then, send the first RM message to the BMP server. After receiving the second BGP Update message, the BMP server parses the message to obtain the route information.

[0103] The method provided in the embodiment utilizes the characteristics of the BGP message modular design (TLV), determines the route type to be reported by quickly parsing the BGP Update message, and recombines the route type to be reported to generate a new BGP Update message. Since the route in the new BGP Update message reported to the BMP server can be correctly parsed, the problem that the route received by the BMP server cannot be completely parsed and errors occur is solved. The method realizes accurate reporting of the pre-policy route and correct parsing of the BGP Update message sent by the client by the BMP server.

[0104] Optionally, in a specific implementation of the embodiment, step 103 includes: judging whether the address family indicated by the AFI field and the SAFI field of each route is the same as the address family information supported by the neighbor device for reporting.

[0105] The address family information supported by the neighbor device for reporting can be obtained in step 100. When the client and at least one monitoring peer establish a monitoring neighbor, the address family information supported by the neighbor device for reporting is specified and configured.

[0106] In the embodiment, the AFI field and the SAFI field of each route include: a Withdrawn Routes field, a Path Attributes field, and a Network Layer Reachability Information field. The Path Attributes field includes at least one of an MP_REACH_NLRI field or an MP_UNREACH_NLRI field.

[0107] In step 103, the BMP client (device B) determines whether the address family information of device A matches the address family information of the route obtained from the monitoring neighbor Update message (step 102) according to the address family information of the neighbor (device A) established (step 100) and the address family information of the route obtained from the monitoring neighbor Update message.

[0108] According to the type of the route, the indication of the AFI field and the SAFI field, and the comparison of the address family supported by the monitoring neighbor for reporting, it is determined whether the corresponding route is reported to the BMP monitoring server.

[0109] For example, the address family information obtained by parsing the first BGP Update message includes Withdrawn Routes (ipv4 withdrawn route) (3), and it is determined whether the Withdrawn Routes (ipv4 withdrawn route) is included in the address family (AFI 1-n, SAFI 1-n) supported by the monitoring neighbor for reporting.

[0110] One embodiment is that if it is not included (i.e., not matched), that is, the type of the route (AFI, SAFI) not supported by the monitoring neighbor for reporting is removed in the first BGP update message, the remaining matched route type is recombined (calculated length) to generate a second BGP update message. The second BGP Update message also conforms to the TLV protocol framework / coding rules.

[0111] In the removal of the route information that does not conform, one or more of the following information can be removed.

[0112] (1) MP_REACH_NLRI;

[0113] (2) MP_UNREACH_NLRI;

[0114] (3) Withdrawn Routes (IPv4 Undo Routes);

[0115] (4)Network Layer Reachability Information (ipv4 routing).

[0116] For example, if in step 103 above it is determined that (3) Withdrawn Routes (ipv4 withdrawn route) is a mismatched route, then the Withdrawn Routes field is marked as a target field, the target field corresponding to the mismatched route type is removed from the first BGP Update message, and the remaining matching route types (1), (2) and (4) are reassembled to generate the second BGP Update message.

[0117] It should be understood that the target field can be one or more of (1), (2), (3) and (4) above.

[0118] Another implementation is to mark the mismatched route type in the first BGP Update message after determining the mismatched route type, and generate a second BGP Update message, wherein the marked route type is not resolved by the BMP server after being reported.

[0119] For example, if the route type matching determines that the (3) Withdrawn Routes (ipv4 route withdrawal) field does not match, then an indication information is set in the field (3). For example, setting the indication information to "0" means blocking the route resolution of this field, and "1" means not blocking the route resolution of this field. When the BMP server receives the second BGP Update message, it identifies the indication information of each field. If it identifies "0", then it does not parse the field and automatically blocks or skips it; if it identifies "1", then it parses the field normally and obtains the route information.

[0120] It should be understood that in this embodiment, the BMP server can also be instructed in other ways to parse which route types in the received BGP Update message and which route types should not be parsed. This embodiment does not limit the specific instruction method.

[0121] Optionally, in another embodiment, before encapsulating the second BGP Update message in step 105, the method further includes: determining whether the keep-all-routes function is configured on the neighboring device that has established a neighboring relationship with the local device and the matching route type.

[0122] Specifically, such as Figure 5As shown, the method comprises:

[0123] Step 1031: judging whether keep-all-routes function is configured on the matched neighbor which establishes a neighbor relationship with the local device.

[0124] If no, i.e. the keep-all-routes function is not configured on at least part of the neighbors, steps 104 and 105 are executed.

[0125] In the keep-all-routes function, a keep-all-routes command is set, which is used to save all BGP route update information from the peer group after the BGP connection is established. If the function is not configured, the process of encapsulating and reporting the second BGP Update packet is executed. If the keep-all-routes function is configured, the following two ways can be used for reporting, specifically including:

[0126] Way one: step 106: the client sends a refresh request to the monitoring neighbor (i.e. the neighbor device). That is, a self-assembly packet of real-time route change is generated according to the second BGP Update packet, and the self-assembly packet is sent to the BMP monitoring server. This reporting method saves the policy-free attributes of the route, encapsulates each route into a self-assembly packet based on each route, and then reports the BGP Update packet to the monitoring server.

[0127] Way two: this way is the method process of executing steps 1031, 104 and 105, i.e. after generating the second BGP Update packet, an RM packet is generated by encapsulating the second BGP Update packet, and is reported to the BMP server. The advantage is that the subsequent processing process is simplified, and the situation of splitting into multiple small packets for reporting in subsequent processing is avoided. After adopting "way two", self-assembly packet reporting (way one) is not needed any more, because self-assembly packet reporting is a small packet reporting situation.

[0128] It should be noted that if the switch does not support the Route-refresh capability, the peer keep-all-routes command needs to be configured on both the local and peer. And the first time the peer keep-all-routes command is configured, it will cause the peer session to reconnect. If the switch supports the Route-refresh capability, after the keep-all-routes command is configured, it will not cause the session with the peer to reconnect, but the refresh BGP command executed by the switch to flush the routing table function will not take effect. If the switch supports the Route-refresh capability, the peer keep-all-routes command does not need to be configured. Whether the keep-all-routes command is configured in the embodiment can be set by the client and the peer, and the embodiment does not limit here.

[0129] Optionally, in step 103, after the similarity matching of the types of the parsed routes, it further includes: if the types of the routes are all matched with the types of the routes supported by the device locally, performing step 1031 to determine whether the keep-all-routes function is configured on all the matched neighbors; if not, encapsulating the first BGP Update message, such as generating a second RM, and sending the second RM to the BMP server. The specific process is similar to the foregoing steps 104 and 105, and will not be described in detail here.

[0130] In addition, the foregoing method further includes: in step 1031, if all the matched routes are configured with the keep-all-routes function, the RM message can still be reported to the BMP server in any one of the foregoing manner one or manner two. The difference is that in the embodiment, the manner one is: the client generates a self-assembly packet of real-time route changes according to the first BGP Update message, and sends the self-assembly packet to the BMP server. The manner two is: the client encapsulates the first BGP Update message into a second RM message, and then reports the second RM message to the BMP server.

[0131] The embodiment provides the method, which improves the accuracy of the policy pre-routing reporting when the user does not configure or partially configures the keep-all-routes function.

[0132] Optionally, in the foregoing step 103, for the unmatched route types, one processing manner is to remove the unmatched route types in the first BGP Update message, and the remaining route types are used to generate a second BGP Update message. In the process of regenerating the message, the length of the BGP Update message also needs to be recalculated. For example, the following cases may be included:

[0133] Case 1: The unmatched route is Withdrawn Routes (ipv4 withdrawn routes)

[0134] If it is determined that the unmatched route is Withdrawn Routes (ipv4 withdrawn routes), the length of the second BGP Update message generated is L0-L1; wherein L0 is the total length of the first BGP Update message. The Withdrawn Routes Length (2 octets) field is updated to 0; the content starting from the Total Path Attribute Length (2 octets) is moved forward by L1 length, covering the original Withdrawn Routes (ipv4 withdrawn routes) content, thus generating the second BGP Update message.

[0135] Case 2: The unmatched route is Network Layer Reachability Information (ipv4 route)

[0136] Since the content of the route is at the end of the BGP Update message, only the total length L0 of the first BGP update message needs to be updated to 23+L1+L2, i.e. the second BGP Update message is obtained, and then the BMP RM message is re-encapsulated according to the message length 23+L1+L2 and reported to the BMP server.

[0137] Case 3: The unmatched route is MP_REACH_NLRI

[0138] The length L3 of the MP_REACH_NLRI attribute is obtained; the total length L0 of the first BGP Update message is updated to L0-L3 when the MP_REACH_NLRI field is removed; the total length L2 of the attribute is updated to L2-L3; the content after the end of the MP_REACH_NLRI attribute is moved forward by L3 length, covering the original MP_REACH_NLRI attribute content, to obtain a new reorganized message, i.e. the second BGP Update message, with a length of L0-L3.

[0139] Case 4: The unmatched route is MP_UNREACH_NLRI

[0140] acquire the length L4 of the MP_UNREACH_NLRI attribute; the total length L0 of the first BGP Update message, when the MP_UNREACH_NLRI field is removed, the total length is updated as L0-L4; the total length L2 of the attribute is updated as L2-L4; the content after the end of the MP_UNREACH_NLRI attribute is moved by L4, and the original content of the MP_UNREACH_NLRI attribute is covered, to obtain a new recombined message, i.e., the second BGP Update message, the length of which is L0-L4.

[0141] It should be understood that in the process of recombining the second BGP Update message and calculating the message length, two or more combinations of the above-mentioned cases 1 to 4 can also be included, and specifically, the process of updating the generation of the second BGP Update message and calculating the total length of the second BGP Update message can refer to the description of the above-mentioned cases, which will not be described in detail here.

[0142] The embodiments of the present application also provide a device corresponding to the above-mentioned updating method of the BGP Update message. Referring to Figure 6 The structure block diagram of the updating device of the BGP Update message provided by the embodiments of the present application. The device is applied to a client, and the client has been connected with a monitoring peer and a monitoring server.

[0143] The message updating device 600 includes a receiving unit 610, an analyzing unit 620, a matching unit 630, a generating unit 640 and a sending unit 650, and in addition, the device can also include more or less other units or modules, such as a storage unit, etc., which are not limited in the embodiments.

[0144] The receiving unit 610 is configured to receive the first BGP Update message from a neighbor device.

[0145] The analyzing unit 620 is configured to analyze the first BGP Update message to obtain the types of each route carried in the first BGP Update message.

[0146] The matching unit 630 is configured to match the types of each route obtained by analysis with the types of routes supported by the neighbor device configured locally, and determine the unmatched types of routes and the matched types of routes.

[0147] The generating unit 640 is configured to generate a second BGP Update message according to the matched types of routes determined by the matching unit 630.

[0148] The sending unit 650 is configured to send the encapsulated second BGP Update message to the BMP server.

[0149] Optionally, in a specific implementation of the embodiment, the parsing unit 620 further obtains an AFI field and an SAFI field of each route type when parsing the first BGP Update message, where the AFI field and the SAFI field are used to indicate an address family to which the current route belongs.

[0150] The matching unit 630 is further configured to determine whether the address family indicated by the AFI field and the SAFI field of each route is the same as the address family information supported by the configuration of the neighbor device.

[0151] Optionally, in another specific implementation of the embodiment, the matching unit 630 is further configured to determine, before encapsulating the second BGP Update message, whether the keep-all-routes function is configured on the neighbor that matches the route type and establishes a neighbor relationship with the local device; if not, the generating unit 640 encapsulates the second BGP Update message, and the sending unit 650 sends the encapsulated second BGP Update message to the BMP server.

[0152] Optionally, in yet another specific implementation of the embodiment, the generating unit 640 is further configured to, if the matching unit 630 determines that the keep-all-routes function is configured, generate a self-assembly packet of real-time route changes according to the second BGP Update message, and send the self-assembly packet to the BMP server through the sending unit 650.

[0153] In addition, the matching unit 630 is further configured to, if all the route types are matched, determine whether the keep-all-routes function is configured on the neighbor; if not, the generating unit 640 encapsulates the first BGP Update message, and the sending unit 650 sends the encapsulated first BGP Update message to the BMP server.

[0154] If the keep-all-routes function is configured, the generating unit 640 generates a self-assembly packet of real-time route changes according to the first BGP Update message, and sends the self-assembly packet to the BMP server through the sending unit 650.

[0155] The device provided in this embodiment utilizes the modular design (TLV) feature of BGP messages to quickly parse BGPUpdate messages, determine the routes that need to be reported, eliminate or block routes that do not need to be reported, and reassemble the types of routes that need to be reported to generate new BGP Update messages. Since the new BGP Update messages reported to the BMP server can be correctly parsed, the problem of errors caused by the BMP server not being able to parse all the routes it receives is solved.

[0156] Furthermore, this embodiment improves the accuracy of policy-front route reporting when the user does not configure or only partially configures the keep-all-routes function by determining whether the keep-all-routes function is configured.

[0157] In addition, embodiments of the present invention also provide a network device, such as... Figure 7 As shown, the network device may include a processor 110 and a memory 120, wherein the processor 110 and the memory 120 may be connected via a bus or other means. Figure 7 For example, the connection is via a bus. Furthermore, the electronic device also includes at least one interface 130, which can be a communication interface or other interface; this embodiment does not impose any limitations on this.

[0158] Optionally, the network device can be a network switch.

[0159] The processor 110 can be a central processing unit (CPU). The processor 110 can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or combinations of the above types of chips.

[0160] The memory 120, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs, non-transitory computer-executable programs, and modules, such as the program instructions / modules corresponding to the BGP Update message update method in the embodiments of the present invention. The processor 110 executes various functional applications and data processing of the processor by running the non-transitory software programs, instructions, and modules stored in the memory 120, thereby implementing the BGP Update message update method in the above method embodiments.

[0161] The memory 120 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created by the processor 110, etc. Furthermore, the memory 120 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory 120 may optionally include memory remotely located relative to the processor 110, and these remote memories may be connected to the processor 110 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0162] In addition, at least one interface 130 is used for communication between the network device and external devices, such as BMP servers, monitoring peers, etc. Optionally, at least one interface 130 can also be used to connect peripheral input / output devices, such as keyboards, displays, etc.

[0163] The one or more modules are stored in the memory 120, and when executed by the processor 110, they perform actions such as... Figure 4 or Figure 5 The BGP Update message update method in the illustrated embodiment.

[0164] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), random access memory (RAM), flash memory, hard disk drive (HDD), or solid-state drive (SSD), etc.; the storage medium can also include combinations of the above types of memory.

[0165] The specific implementation process of the functions and roles of each unit in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0166] In addition, this application also provides a BGP Update message update system, which includes a BGP client, a monitoring server (or BGP server), and at least one monitored peer. The structure of any of the network devices can be the same as described above.Figure 7 The structures shown are the same, and the BGP client is used to implement the BGP Update message updating method described in the foregoing embodiments. In addition, the monitoring server is used to receive the second BGP Update message reported by the BGP client, and parse and process the message.

[0167] For the device and system embodiments, since they basically correspond to the method embodiments, the relevant parts are described in the method embodiment. The device and system embodiments described above are only schematic, wherein the units described as separate components can or can not be physically separate, and the components displayed as units can or can not be physical units, i.e., can be located in one place, or can be distributed on multiple network units. Part or all of the modules can be selected according to actual needs to achieve the purpose of the present application. Those skilled in the art can understand and implement without creative labor.

[0168] For the message updating device and machine readable storage medium embodiments, since the method content involved is basically similar to the foregoing method embodiments, the description is relatively simple, and the relevant parts are described in the method embodiment.

[0169] The above description is only the preferred embodiment of the present application, and is not used to limit the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the scope of protection of the present application.

Claims

1. A method for updating a BGP Update message, characterized by, The method comprises: receiving a first Border Gateway Protocol (BGP) Update message from a neighbor device; parsing the first BGP Update message to obtain types of each route carried in the first BGP Update message; the route type comprises at least one of a withdrawn route entry, a path attribute field, and network layer reachability information; matching the types of each route with a locally configured route type supported by the neighbor device; the locally configured route type supported by the neighbor device is obtained in advance; determining a matched route type from the types of each route, and generating a second BGP Update message according to the matched route type; after encapsulating the second BGP Update message, sending the second BGP Update message to a BMP server; wherein the determining the matched route type from the types of each route and the generating the second BGP Update message according to the matched route type comprise: obtaining an unmatched route type, removing the unmatched route type from the first BGP Update message, and generating the second BGP Update message from the remaining matched route type; or, obtaining an unmatched route type, marking the unmatched route type in the first BGP Update message, and generating the second BGP Update message, wherein the marked route type is not parsed by the BMP server after being reported.

2. The method of claim 1, wherein, The parsing the first BGP Update message further obtains an address family information (AFI) field and a sub-address family information (SAFI) field of each route type, and the AFI field and the SAFI field are used to indicate an address family to which a current route belongs; the matching the types of each route with the locally configured route type supported by the neighbor device comprises: judging whether address families indicated by the AFI field and the SAFI field of each route are all same as address family information supported by the neighbor device and configured to be reported.

3. The method according to any of claims 1-2, characterized in that, Before the encapsulating the second BGP Update message, the method further comprises: judging whether a keep-all-routes function is configured on a neighbor of the matched route type and locally established with the neighbor device; the keep-all-routes function is used to save BGP route update information from a peer or a peer group since a BGP connection is established; if not, performing the encapsulating the second BGP Update message and sending the second BGP Update message to the BMP server.

4. The method of claim 3, wherein, The method further comprises: if yes, generating a self-assembly packet of real-time route change according to the second BGP Update message, and sending the self-assembly packet to the BMP server.

5. The method of claim 3, wherein, After the matching the types of each route, the method further comprises: if all the types of each route are matched, judging whether the keep-all-routes function is configured on the neighbor; If not configured, the first BGP Update message is encapsulated and sent to the BMP server.

6. The method of claim 5, wherein, The method further comprises: If configured, a self-assembly packet of real-time route change is generated according to the first BGP Update message, and the self-assembly packet is sent to the BMP server.

7. An updating device of a BGP Update message, characterized by comprising: The device comprises: A receiving unit configured to receive a first Border Gateway Protocol (BGP) Update message from a neighbor device; An analyzing unit configured to analyze the first BGP Update message to obtain types of each route carried in the first BGP Update message, wherein the route types include at least one of the following: a withdrawn route entry, a path attribute field, and network layer reachability information; A matching unit configured to match the types of each route with locally configured route types supported by the neighbor device, and determine matched route types from the types of each route, wherein the locally configured route types supported by the neighbor device are obtained in advance; A generating unit configured to generate a second BGP Update message according to the matched route types; A sending unit configured to encapsulate the second BGP Update message and send it to a BMP server; In the determination of the matched route types from the types of each route and the generation of the second BGP Update message according to the matched route types, the following steps are included: Obtaining unmatched route types, eliminating the unmatched route types from the first BGP Update message, and generating the second BGP Update message from the remaining matched route types; Or, obtaining unmatched route types, marking the unmatched route types in the first BGP Update message, and generating the second BGP Update message, wherein the marked route types are not parsed by the BMP server after being reported.

8. A network device, comprising: The device comprises a processor and a memory coupled to the processor; The memory stores computer readable program instructions which, when executed by the processor, implement the method for updating a BGP Update message according to any one of claims 1 to 6.

9. A computer readable storage medium having stored thereon a computer program, characterized in that, The computer program, when executed by the processor, implements the method for updating a BGP Update message according to any one of claims 1 to 6.

Images