Method, device and equipment for realizing CoPP based on protocol feature hardware identification, storage medium and program product

Abstract

The invention discloses a method, a device, equipment, a storage medium and a program product for realizing CoPP based on protocol feature hardware identification, and relates to the technical field of data processing, the method for realizing CoPP based on protocol feature hardware identification comprises the following steps: when a message is uploaded to a CPU, allocating an identification code for the message based on the protocol type of the message; abnormal index mapping is added to the identification code, and a label is added to the abnormal index mapping; searching a Copp control table according to the abnormal index mapping to obtain a speed limiting strategy pointer; and dynamically controlling message uploading based on a speed limiting strategy pointer. Due to the fact that the protocol message type is directly executed through chip hardware logic, ACL does not need to be configured, ACL resources are saved, user-defined protocol messages and chip built-in universal protocol messages can be processed at the same time, and expansibility is high.

Description

Technical Field

[0001] This application relates to the technical field of data processing, and particularly to a method, apparatus, device, storage medium, and program product for implementing CoPP based on protocol feature hardware recognition. Background Art

[0002] In a communication network, the control plane, as the core for network device management and control, is responsible for key tasks such as routing calculation and protocol processing. With the expansion of the network scale and the diversification of service types, the control plane faces increasingly severe traffic impacts, such as denial-of-service (DoS) attacks, abnormal traffic, etc. These traffic may seriously affect the stability and reliability of the control plane. Through Control Plane Policing (CoPP), the traffic entering the control plane can be rate-limited and filtered to ensure that key services are not affected.

[0003] Currently, there are the following problems in control plane protection: (1) Dependence on ACL leads to waste of hardware resources; (2) It is impossible to perform refined control according to protocol types and has insufficient dynamic adjustment capabilities; (3) It is difficult to cope with sudden traffic impacts. Summary of the Invention

[0004] The main purpose of this application is to provide a method, apparatus, device, storage medium, and program product for implementing CoPP based on protocol feature hardware recognition, aiming to solve the technical problem that the existing control plane protection technology depends on ACL, resulting in waste of hardware resources.

[0005] To achieve the above purpose, this application proposes a method for implementing CoPP based on protocol feature hardware recognition. The method for implementing CoPP based on protocol feature hardware recognition includes:

[0006] When a message is sent to the CPU, assign an identification code to the message based on the protocol type of the message;

[0007] Add an exception index mapping to the identification code and add a label to the exception index mapping;

[0008] Search the Copp control table according to the exception index mapping to obtain a rate-limiting policy pointer;

[0009] Dynamically control the message forwarding based on the rate-limiting policy pointer.

[0010] In an embodiment, the step of searching the Copp control table according to the exception index mapping to obtain a rate-limiting policy pointer includes:

[0011] Locate a target item in the CoPP control table based on the exception index mapping;

[0012] Extract the speed limit mode, token bucket capacity, and token refresh rate from the target item;

[0013] Generate a speed limit policy pointer according to the speed limit mode, the token bucket capacity, and the token refresh rate.

[0014] In one embodiment, the step of dynamically controlling the message upload based on the speed limit policy pointer includes:

[0015] Determine the CoPP speed limit mode based on the speed limit policy pointer;

[0016] In the CoPP speed limit mode, dynamically control the message upload based on the single token bucket algorithm.

[0017] In one embodiment, the step of dynamically controlling the message upload based on the single token bucket algorithm includes:

[0018] Obtain the token refresh rate and token bucket capacity in the CoPP speed limit mode;

[0019] Fill the token bucket according to the token refresh rate and the token bucket capacity;

[0020] When the tokens in the token bucket are not exhausted, deduct the tokens and upload the message to the CPU;

[0021] When the tokens in the token bucket are exhausted, process the message as normal traffic.

[0022] In one embodiment, the step of filling the token bucket according to the token refresh rate and the token bucket capacity includes:

[0023] Determine the reserved capacity of the token reservation pool and the shared capacity of the token sharing pool based on the token bucket capacity;

[0024] Fill the token reservation pool and the token sharing pool according to the token refresh rate.

[0025] In one embodiment, the method further includes:

[0026] When an attack is detected, temporarily reduce the shared capacity of the token sharing pool;

[0027] When the protocol priority of the burst message is the first priority, borrow tokens from the token sharing pool and upload the burst message to the CPU.

[0028] In addition, to achieve the above object, the present application also proposes a device for implementing CoPP based on protocol feature hardware recognition. The device for implementing CoPP based on protocol feature hardware recognition includes:

[0029] An identification code assignment module that assigns an identification code to a message based on the protocol type of the message when the message is sent to the CPU;

[0030] An exception index mapping module that adds an exception index mapping to the identification code and adds a label to the exception index mapping;

[0031] A speed limit pointer acquisition module that looks up the CoPP control table according to the exception index mapping to obtain a speed limit policy pointer;

[0032] A CoPP speed limit module that dynamically controls the message sending based on the speed limit policy pointer.

[0033] In addition, to achieve the above object, the present application also proposes a device for implementing CoPP based on protocol feature hardware identification. The device includes: a memory, a processor, and a computer program stored on the memory and executable on the processor. The computer program is configured to implement the steps of the method for implementing CoPP based on protocol feature hardware identification as described above.

[0034] In addition, to achieve the above object, the present application also proposes a storage medium. The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the method for implementing CoPP based on protocol feature hardware identification as described above are implemented.

[0035] In addition, to achieve the above object, the present application also provides a computer program product. The computer program product includes a computer program. When the computer program is executed by a processor, the steps of the method for implementing CoPP based on protocol feature hardware identification as described above are implemented.

[0036] One or more technical solutions proposed by the present application have at least the following technical effects:

[0037] In the embodiment of the present application, when a message is sent to the CPU, an identification code is assigned to the message based on the protocol type of the message; an exception index mapping is added to the identification code, and a label is added to the exception index mapping; the CoPP control table is looked up according to the exception index mapping to obtain a speed limit policy pointer; and the message sending is dynamically controlled based on the speed limit policy pointer. Since the protocol message type is directly identified by the chip hardware logic without configuring ACL, ACL resources are saved, and user-defined protocol messages and chip-built-in general protocol messages can be processed simultaneously, with high scalability. Description of the Drawings

[0038] The drawings here are incorporated into the specification and form a part of the specification, showing embodiments consistent with the present application, and are used together with the specification to explain the principles of the present application.

[0039] To more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the accompanying drawings required for the description of the embodiments or the prior art. Obviously, for those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0040] Figure 1 It is a schematic flowchart provided for the first embodiment of the method for implementing CoPP based on protocol feature hardware recognition in the present application;

[0041] Figure 2 It is a schematic flowchart provided for the second embodiment of the method for implementing CoPP based on protocol feature hardware recognition in the present application;

[0042] Figure 3 It is a schematic flowchart provided for the third embodiment of the method for implementing CoPP based on protocol feature hardware recognition in the present application;

[0043] Figure 4 It is a schematic module structure diagram of the device for implementing CoPP based on protocol feature hardware recognition in the embodiments of the present application;

[0044] Figure 5 It is a schematic device structure diagram of the hardware operating environment involved in the method for implementing CoPP based on protocol feature hardware recognition in the embodiments of the present application.

[0045] The implementation, functional features and advantages of the object of the present application will be further described with reference to the embodiments and the accompanying drawings. Detailed Embodiments

[0046] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application and are not used to limit the present application.

[0047] To better understand the technical solutions of the present application, the following will be described in detail with reference to the accompanying drawings of the specification and the specific embodiments.

[0048] The main solution of the embodiments of the present application is: when a message is sent to the CPU, an identification code is assigned to the message based on the protocol type of the message; an exception index mapping is added to the identification code, and a label is added to the exception index mapping; the Copp control table is searched according to the exception index mapping to obtain a rate limiting policy pointer; and the message sending is dynamically controlled based on the rate limiting policy pointer.

[0049] In some embodiments of the embodiments of the present application, the Control Plane Protection (CoPP) technology can implement rate limiting in the following two ways:

[0050] (1) Based on ACL matching: By configuring the access control list (ACL) to match the packet characteristics, the traffic is rate-limited. However, the ACL resources in the switching chip are very limited, resulting in resource waste, and additional ACL configuration is still required for the protocol packets already recognized by the chip, with low efficiency.

[0051] (2) Based on CPU queue shaping: Mixing different protocol packets in a limited queue cannot perform precise rate-limiting for each protocol type, resulting in possible mislimiting of critical service traffic.

[0052] However, the above solutions have the following defects: (1) Dependence on ACL leads to waste of hardware resources; (2) It is impossible to perform refined control according to protocol types; (3) The dynamic adjustment ability is insufficient and it is difficult to cope with sudden traffic shocks.

[0053] In some implementation manners of the embodiments of the present application, in view of the above defects, the present application proposes a CoPP technical solution based on hardware logic without relying on ACL, which reduces the occupation of ACL resources and improves the resource utilization rate of the switching chip; at the same time, it realizes precise rate-limiting according to protocol types (such as OSPF, Telnet, etc.), enhances the dynamic traffic control ability, and prevents the CPU from being overloaded due to DoS attacks.

[0054] It should be noted that the execution subject of this embodiment can be a computing service device with data processing, network communication, and program running functions, such as a switching chip, a computer or a server connected to the switching chip, etc., or an electronic device or a virtual device capable of implementing the above functions. Hereinafter, a device that implements CoPP based on hardware recognition of protocol characteristics (hereinafter referred to as a protection device) is used as an example to illustrate this embodiment and the following embodiments.

[0055] Based on this, the embodiments of the present application provide a method for implementing CoPP based on hardware recognition of protocol characteristics, referring to Figure 1 , Figure 1 which is a schematic flowchart provided for Embodiment 1 of the method for implementing CoPP based on hardware recognition of protocol characteristics in the present application.

[0056] In this embodiment, the method for implementing CoPP based on hardware recognition of protocol characteristics includes steps S10 to S40:

[0057] Step S10, when the packet is sent to the CPU, assign an identification code to the packet based on the protocol type of the packet.

[0058] It can be understood that a packet is a data unit transmitted in a network and can include control information and user data. The protocol type of a packet can include L2 / L3 protocols, ACL matching results, etc. When a network device receives a packet that requires control plane processing (such as a routing protocol packet, a management packet, etc.), a unique identification code (CPU Reason ID) can be assigned to the packet according to the protocol type of the packet. This identification code can be used by the upper layer protocol stack to distinguish the packet type.

[0059] In the embodiments of the present application, the protocol characteristics (including the protocol type) of a packet can be automatically identified through chip hardware logic (such as L2PDU and L3PUD modules), and an identification code can be assigned to it based on the protocol type of the packet.

[0060] Specifically, in the embodiments of the present application, a hardware logic identification unit can be provided, which can specifically include an L2 / L3 protocol identification engine and an ACL matching result injection module.

[0061] In some embodiments of the present application, the L2 / L3 protocol identification engine of the present application can layer-by-layer parse the packet header through a chip built-in hardware module (such as an L2PDU / L3PDU parser) to identify the protocol type (such as STP, OSPF, Telnet).

[0062] In some embodiments of the present application, the present application can layer-by-layer parse the packet header through the built-in L2 / L3 protocol identification engine of the chip, combine the hardware representation and state machine technology, and realize efficient protocol identification and forwarding decision-making by identifying specific fields or transport layer port numbers in the packet header, improving the performance and scalability of the network device.

[0063] In some embodiments of the present application, for the L2 protocol, it can be determined according to the MAC address, EtherType (such as 0x0800 for IPv4), and LLDP target MAC (01:80:C2:00:00:0E). For the L3 protocol, it can be determined according to the IP header Protocol field (such as 6 = TCP, 89 = OSPF) and port number (such as Telnet = 23).

[0064] It can be understood that the protected device of the present application can layer-by-layer parse the packet header through the built-in L2 / L3 protocol identification engine of the chip and identify the protocol type according to the key fields therein.

[0065] In some embodiments of the present application, the first 14 bytes of the Ethernet frame header can be recognized, including the destination MAC address (6 bytes), the source MAC address (6 bytes), and EtherType (2 bytes, located at bytes 13-14 of the frame header). That is, the Ethernet frame header is obtained by layer-by-layer parsing of the packet header, and the destination MAC address, the source MAC address, and EtherType are obtained by recognizing the target key fields in the Ethernet frame header. The protocol type is determined by recognizing the contents of the destination MAC address, the source MAC address, and EtherType. The specific determination method of the protocol type can be determined based on the specific implementation, and the embodiments of the present application do not limit this.

[0066] Exemplarily, if the destination MAC address is a multicast address (such as 01:80:C2:00:00:00 of STP), it can be determined as the STP protocol; if the destination MAC address is a unicast address, it can be further combined with EtherType for judgment.

[0067] In some embodiments of the present application, after the user-defined ACL rule is hit, the hardware logic can encode the ACL ID (such as 0x1F) into the identification code (CPU Reason ID) to distinguish the user-defined protocol traffic.

[0068] In some embodiments of the present application, for the allocation mechanism of the identification code, the mapping between the predefined protocol type and the identification code can be predefined (such as OSPF = 0x01, Telnet = 0x02), and then the protocol type of the packet can be reflected by the identification code carried in the packet.

[0069] In some embodiments of the present application, an ID segment (such as 0x80-0xFF) can be reserved for user-defined protocols and dynamically registered through the management interface.

[0070] In the specific implementation, the protection device of the embodiments of the present application can, when the packet passes through the above-mentioned COU, layer-by-layer parse the packet header through the L2 / L3 protocol recognition engine built in the chip, and then determine the protocol type of the packet. And based on the predefined mapping between the protocol type and the identification code, an identification code is allocated for the packet and attached to the packet metadata.

[0071] Step S20, add an exception index mapping to the identification code and add a label to the exception index mapping.

[0072] It should be noted that the protection device in the embodiment of the present application may further include an exception index mapping module. This module can be used to handle exceptions and map the identification code (CPU Reason ID) to a unique exception index mapping ExceptionIndex. Exemplarily, the CPU Reason ID can be mapped to ExceptionIndex through the exception index mapping module, and ExceptionEn = 1 is marked.

[0073] It should be explained that the above tag can be a flag bit, which can be used to indicate the further processing method of the message. For example, when adding the tag ExceptionEn = 1 to the exception index mapping, it can indicate that the message needs to be copied and sent to the CPU; when adding the tag ExceptionEn = 0 to the exception index mapping, it can indicate that the message does not need to be copied and sent to the CPU.

[0074] In some embodiments of the embodiment of the present application, a hardware mapping table can be established, and the correspondence between the protocol type and the exception index mapping is supported to be dynamically updated.

[0075] Specifically, the structure of the above hardware mapping table can be a static entry and / or a dynamic entry. When the hardware mapping table is a static entry, it can be mapped through the built-in fixed mapping of the chip (such as CPU Reason ID = 0x01 is mapped to ExceptionIndex = 1). When the hardware mapping table is a dynamic entry, it can be dynamically configured through the SDK interface, supporting user-defined protocols (such as CPU Reason ID = 0x80 is mapped to ExceptionIndex = 32).

[0076] In some embodiments of the embodiment of the present application, a hardware mapping table with a dynamic entry structure is implemented, enabling users to dynamically configure the mapping relationship between the protocol type and the exception index mapping ExceptionIndex through the SDK and coexist with the static entry. Specifically, the embodiment of the present application can store the static entry through chip solidification storage (such as ROM). Generally, the static entry cannot be dynamically modified, such as StaticEntry = {ReasonID: 0x01, ExceptionIndex: 1, Type: STATIC}. For the dynamic entry, it can be stored in programmable memory (such as SRAM / TCAM) and supports read and write operations. For example, DynamicEntry = {ReasonID: 0x80, ExceptionIndex: 32, Type: DYNAMIC}.

[0077] In some embodiments of the present application, for the dynamic table capacity of the hardware mapping table with a dynamic table entry structure, a fixed number of slots (such as 32 dynamic table entries) can be pre-allocated according to chip resources. When a conflict occurs between the dynamic table entries and the static table entries of the hardware mapping table, the dynamic table entries can overwrite the static table entries (for example, when the user configures ReasonID = 0x01, the dynamic table is preferentially matched).

[0078] In some embodiments of the present application, for the SDK interface design of dynamic table entries, functions such as adding a dynamic table entry add_dynamic_entry(uint16_t reason_id, uint8_t exception_index), deleting a dynamic table entry delete_dynamic_entry(uint16_t reason_id), and querying the current mapping table get_mapping_table() can be implemented based on API functions. For parameter verification, an ExceptionIndex range check can be set (such as 1 to 255, and 0 is reserved as an invalid value). When the number of slots for dynamic table entries is insufficient, an error code can be returned.

[0079] In some embodiments of the present application, for the hardware lookup logic of the hardware mapping table, it can be priority matching, that is, first query the dynamic table entries, and then query the static table entries when a miss occurs. For the hit logic during lookup, when the match is successful, the tag ExceptionEn = 1 can be set, and the exception index mapping ExceptionIndex can be filled. When a miss occurs, the tag ExceptionEn = 0 can be set for packet bypass forwarding.

[0080] In some embodiments of the present application, in the packet forwarding pipeline, the hardware can automatically set the tag corresponding to the exception index mapping to 1 and trigger replication and upload to the CPU. If no exception index mapping is matched, the tag can be set to 0, and the packet is only bypassed and forwarded as ordinary traffic.

[0081] In some embodiments of the present application, the implementation goal of the packet bypass mechanism can be to forward the packet as ordinary traffic when no exception index mapping is matched. Specifically, it can be controlled by tags. The default tag ExceptionEn = 0 is set to 1 only when the hardware mapping table is hit. At the same time, pipeline optimization can also be performed by inserting a bypass channel in the forwarding pipeline, and packets with ExceptionEn = 0 directly enter the conventional L2 / L3 forwarding logic.

[0082] In some embodiments of the present application, when the hardware design ensures a miss, the path is switched immediately without waiting for the lookup result, thereby achieving zero-latency bypass. In addition, when an invalid CPU Reason ID (such as 0xFFFF) appears, the packet can be directly bypassed. When a dynamic table entry conflict occurs, a log can be recorded and an SDK alarm can be triggered.

[0083] Step S30: Search the CoPP control table according to the abnormal index mapping to obtain a rate-limiting policy pointer.

[0084] Step S40: Dynamically control the packet forwarding based on the rate-limiting policy pointer.

[0085] It should be noted that the protection device of the present application may further include a rate-limiting pointer acquisition module, which can index the CoPP control table (CoPPCTL) according to the abnormal index mapping, and then obtain the corresponding rate-limiting policy pointer (Ptr). Among them, the CoPP control table can be a table entry for efficiently performing traffic rate-limiting and policy control in a network device, which can be used to implement traffic classification and rate-limiting pointer mapping, and achieve hardware-accelerated rate-limiting execution. Through the hardware lookup mechanism of the CoPP control table, the rate-limiting policy can be quickly matched, reducing processing latency.

[0086] It can be understood that the rate-limiting policy pointer can be a data structure for pointing to or referencing a specific rate-limiting policy, which can be used in a network device to quickly search for and apply the rate-limiting policy without having to recalculate every time traffic arrives. Through the rate-limiting policy pointer of the present application, the packet forwarding to the CPU can be dynamically controlled, thereby improving the dynamic adjustment ability.

[0087] In the embodiment of the present application, when a packet is forwarded to the CPU, an identification code is assigned to the packet based on the protocol type of the packet; an abnormal index mapping is added to the identification code, and a label is added to the abnormal index mapping; the CoPP control table is searched according to the abnormal index mapping to obtain a rate-limiting policy pointer; the packet forwarding is dynamically controlled based on the rate-limiting policy pointer. Since the protocol packet type is directly determined by the chip hardware logic without configuring an ACL, ACL resources are saved, and user-defined protocol packets and chip-built-in general protocol packets can be processed simultaneously, with high scalability.

[0088] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar content as in the above-mentioned embodiment 1 can be referred to the above introduction and will not be repeated hereinafter. On this basis, please refer to Figure 2 , Figure 2 This is the flowchart provided by the second embodiment of the method for implementing CoPP based on protocol feature hardware recognition in the present application.

[0089] In the embodiment of the present application, such as Figure 2As shown, the step of looking up the CoPP control table according to the abnormal index mapping to obtain a rate limiting policy pointer includes:

[0090] Step S31: Locate the target entry in the CoPP control table based on the abnormal index mapping.

[0091] Step S32: Extract the rate limiting mode, token bucket capacity, and token refresh rate from the target entry.

[0092] Step S33: Generate a rate limiting policy pointer according to the rate limiting mode, the token bucket capacity, and the token refresh rate.

[0093] It should be noted that for the CoPP control table in the embodiments of the present application, the table entry structure may include: a. ExceptionIndex; b. CoPP rate limiting mode (PPS / BPS); c. Token bucket capacity; d. Token refresh rate; e. Action (permit / discard), etc. The pre-configured policies for the CoPP control table may include default policies (such as ExceptionIndex = 1 corresponding to OSPF rate limiting of 1000 PPS). The content in the above table entry structure can be configured by the user, and the embodiments of the present application do not limit this.

[0094] It should be explained that for the above token bucket capacity, token bucket refresh rate, and CoPP rate limiting mode, they can be set based on the abnormal index mapping corresponding to different protocol types, so that different protocol types can correspond to independent rate limiting parameters, avoiding mutual interference between services. By flexibly configuring the table entry structure, rapid access and rate limiting deployment of new protocol types can be achieved.

[0095] It can be understood that based on the above table entry structure, the target entry can be located in the CoPP control table according to the abnormal index mapping corresponding to the packet, and the rate limiting mode, token bucket capacity, token refresh rate, etc. can be extracted from the target entry. Based on this content, a rate limiting policy pointer (Ptr) can be generated and passed to the token bucket module.

[0096] In some implementation manners of the embodiments of the present application, the abnormal index mapping of the packet can be compared with the abnormal index mapping (i.e., a. ExceptionIndex) in the CoPP control table. When the comparison result is consistent, it can be determined that the table entry corresponding to the abnormal index mapping in the CoPP control table is the target entry, and the corresponding rate limiting mode, token bucket capacity, token refresh rate, and other parameters can be obtained, and then the corresponding rate limiting policy pointer can be generated, so as to implement different rate limiting policies based on the protocol type, and achieve independent rate limiting according to the protocol type. For example, different rate threshold values are set for traffic such as OSPF, Telnet, and ICMP.

[0097] In the embodiment of the present application, the target item is located in the CoPP control table based on the abnormal index mapping; the rate limiting mode, the token bucket capacity, and the token refresh rate are extracted from the target item; and the rate limiting policy pointer is generated according to the rate limiting mode, the token bucket capacity, and the token refresh rate. Since the rate limiting policy pointer is generated based on the abnormal index mapping, independent rate limiting is realized based on different message protocol types.

[0098] Based on the first embodiment and / or the second embodiment of the present application, in the third embodiment of the present application, the same or similar content as in the above-mentioned first embodiment and / or the second embodiment can be referred to the above introduction and will not be repeated hereinafter. On this basis, please refer to Figure 3 , Figure 3 FIG. is a schematic flow chart provided by the third embodiment of the method for implementing CoPP based on protocol feature hardware recognition in the present application.

[0099] In the example of the present application, as Figure 3 shown, the step of dynamically controlling the message forwarding based on the rate limiting policy pointer includes:

[0100] Step S41, determining the CoPP rate limiting mode based on the rate limiting policy pointer;

[0101] Step S42, under the CoPP rate limiting mode, dynamically controlling the message forwarding based on the single token bucket algorithm.

[0102] It can be understood that in the entry of the CoPP control table, the CoPP rate limiting mode can also be included. Based on the CoPP rate limiting mode included in the rate limiting policy pointer, the dynamic control of the message forwarding can be realized based on the single token bucket algorithm.

[0103] It should be noted that the protection device in the embodiment of the present application can also include the CoPP rate limiting mode, and the CoPP rate limiting mode can perform dynamic control on the message forwarding rate based on the token bucket mechanism ((PPS, Packet per Second)).

[0104] It should be noted that in the CoPP rate limiting module based on the token bucket mechanism (token bucket mode), token refreshing can fill the token bucket regularly according to the token refreshing rate configured by the user in the rate limiting policy pointer (for example, 128 Kbps corresponds to filling a certain number of tokens per second). For packet processing in the token bucket mode, when tokens are sufficient, tokens can be deducted and the packet is allowed to be sent to the CPU; when the tokens are exhausted, the label can be set to 0 and the packet is bypassed as ordinary traffic to avoid CPU overload. That is, the steps of dynamically controlling the packet sending based on the single token bucket algorithm include: obtaining the token refreshing rate and the token bucket capacity in the CoPP rate limiting mode; filling the token bucket according to the token refreshing rate and the token bucket capacity; when the tokens in the token bucket are not exhausted, deducting tokens and sending the packet to the CPU; when the tokens in the token bucket are exhausted, processing the packet as ordinary traffic.

[0105] In some embodiments of the embodiments of the present application, tokens can be periodically injected through a hardware timer based on the token refreshing rate configured by the user (such as 1000 PPS) (for example, injecting 1 token every 1 ms). At the same time, the upper limit of the token bucket capacity can be configured by the user (for example, 100 tokens are allowed to accumulate for burst traffic).

[0106] In some embodiments of the embodiments of the present application, when a packet arrives, the protection device can check the remaining tokens in the token bucket. When the current remaining tokens ≥ 1, 1 token can be deducted and the packet is allowed to be sent to the above CPU. When the tokens in the token bucket are exhausted, that is, the current remaining tokens = 0, a hardware interrupt is triggered and the ExceptionEn flag is set to 0, so that the packet can be bypassed and forwarded as ordinary traffic.

[0107] In some embodiments of the present application, by protecting the management interface of the device, the user can dynamically modify the token refresh rate (for example, temporarily reducing the ICMP rate limit from 1000 PPS to 200 PPS during a DDoS attack). At the same time, the embodiments of the present application can also set a priority preemption mechanism based on the protocol type of the packet. A token reservation pool and a token sharing pool can be configured. For high-priority protocols (i.e., the first-priority protocols, such as OSPF), packets can be sent up through the tokens in the token reservation pool and the token sharing pool. For low-priority protocols (i.e., the second-priority protocols), packets are sent up through the tokens in the token sharing pool. Specifically, in the embodiments of the present application, a token reservation pool can be set up to reserve tokens for high-priority protocols and avoid resource exhaustion due to the traffic of low-priority protocols. The reserved capacity of the token reservation pool and the shared capacity of the token sharing pool are divided based on the token bucket capacity. For the token reservation pool, it includes fixed tokens allocated for high-priority protocols (for example, 100 tokens are reserved for OSPF); for the token sharing pool, it includes the remaining tokens competed by all protocols. The code example can be as follows:

[0108] typedef struct{

[0109] uint32_t total_tokens; / / Total number of tokens

[0110] uint32_t reserved_pool; / / Size of the reservation pool (only available for high-priority)

[0111] uint32_t shared_pool; / / Size of the shared pool (total_tokens - reserved_pool)

[0112] }TokenBucket;

[0113] That is, the step of filling the token bucket according to the token refresh rate and the token bucket capacity includes: determining the reserved capacity of the token reservation pool and the shared capacity of the token sharing pool based on the token bucket capacity; filling the token reservation pool and the token sharing pool according to the token refresh rate.

[0114] In some embodiments of the present application, for the token deduction logic, a Priority field (such as 0 - low, 1 - high) can be added to the entries in the CoPP control table, thereby realizing the priority assignment for different protocol types.

[0115] In some embodiments of the embodiments of the present application, the method for implementing CoPP based on protocol feature hardware recognition in the embodiments of the present application can achieve an adaptive scenario. Exemplarily, for DDoS defense: when an attack is detected, the token sharing pool quota for non-critical protocols (such as ICMP) can be temporarily reduced. That is, the method further includes: when an attack is detected, obtaining a protocol list of non-critical protocols; temporarily reducing the sharing capacity of the non-critical protocols in the protocol list in the token sharing pool.

[0116] It should be noted that the reduction duration of the above sharing capacity can be consistent with the duration of the attack, or it can be other durations, and the embodiments of the present application do not limit this.

[0117] In some embodiments of the embodiments of the present application, in order to achieve protocol guarantee for high-priority protocols, when high-priority protocols burst, if there is no token margin in both the token sharing pool and the token reservation pool, the current overdraft value and the maximum overdraft value of the token sharing pool can be obtained, and the maximum overdraft value can be configured by the user himself. When the current overdraft value reaches the maximum overdraft value, tokens can be automatically borrowed from the token sharing pool to achieve timely uplink of high-priority protocol packets. When the current overdraft value reaches the maximum overdraft value, the packet can be sent through the bypass or sent after waiting for token replenishment.

[0118] The embodiments of the present application determine the CoPP rate limiting mode based on the rate limiting policy pointer; in the CoPP rate limiting mode, the uplink of packets is dynamically controlled based on the single token bucket algorithm. Since the dynamic control of packet uplink is achieved by determining the CoPP rate limiting mode based on the rate limiting policy pointer and based on the token bucket mechanism, the packet uplink function can be automatically closed when the tokens are exhausted, realizing hardware-level traffic control and improving the CPU protection efficiency. At the same time, it supports configuring independent rate limiting parameters for different protocol types (such as OSPF, Telnet), avoiding interference between services. By flexibly configuring the table entries, it is possible to support the rapid access of new protocol types and the deployment of rate limiting policies.

[0119] The present application also provides a device for implementing CoPP based on protocol feature hardware recognition. Please refer to Figure 4 , Figure 4 which is a schematic diagram of the module structure of the device for implementing CoPP based on protocol feature hardware recognition in the embodiments of the present application. The device for implementing CoPP based on protocol feature hardware recognition includes:

[0120] An identification code assignment module 10, which assigns an identification code to the packet based on the protocol type of the packet when the packet is uplinked to the CPU;

[0121] An abnormal index mapping module 20, which adds an abnormal index mapping to the identification code and adds a label to the abnormal index mapping;

[0122] The speed limit pointer acquisition module 30 looks up the Copp control table according to the abnormal index mapping to obtain the speed limit policy pointer;

[0123] The CoPP speed limit module 40 dynamically controls the message forwarding based on the speed limit policy pointer.

[0124] The device for implementing CoPP based on protocol feature hardware recognition provided by this application adopts the method for implementing CoPP based on protocol feature hardware recognition in the above embodiment, which can solve the technical problem that the existing control plane protection technology wastes hardware resources due to reliance on ACL. Compared with the prior art, the beneficial effects of the device for implementing CoPP based on protocol feature hardware recognition provided by this application are the same as those of the method for implementing CoPP based on protocol feature hardware recognition provided by the above embodiment, and other technical features in the device for implementing CoPP based on protocol feature hardware recognition are the same as the features disclosed in the method of the above embodiment, which will not be elaborated here.

[0125] This application provides a device for implementing CoPP based on protocol feature hardware recognition. The device for implementing CoPP based on protocol feature hardware recognition includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein, the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the method for implementing CoPP based on protocol feature hardware recognition in the first embodiment above.

[0126] Next, refer to Figure 5 , which shows a schematic structural diagram of a device for implementing CoPP based on protocol feature hardware recognition suitable for use in the embodiments of this application. The device for implementing CoPP based on protocol feature hardware recognition in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 5 The device for implementing CoPP based on protocol feature hardware recognition shown is merely an example and should not impose any limitations on the functions and usage scope of the embodiments of this application.

[0127] As Figure 5As shown, the device for implementing CoPP based on protocol feature hardware recognition may include a processing device 1001 (such as a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM: Read Only Memory) 1002 or the program loaded from the storage device 1003 into the random access memory (RAM: Random Access Memory) 1004. In the RAM 1004, various programs and data required for the operation of the device for implementing CoPP based on protocol feature hardware recognition are also stored. The processing device 1001, the ROM 1002, and the RAM 1004 are connected to each other through a bus 1005. The input / output (I / O) interface 1006 is also connected to the bus. Generally, the following systems may be connected to the I / O interface 1006: an input device 1007 including, for example, a touch screen, a touchpad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD: Liquid Crystal Display), a speaker, a vibrator, etc.; a storage device 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 can allow the device for implementing CoPP based on protocol feature hardware recognition to communicate with other devices wirelessly or wiredly to exchange data. Although the figure shows a device for implementing CoPP based on protocol feature hardware recognition having various systems, it should be understood that it is not required to implement or have all the shown systems. Instead, more or fewer systems may be implemented or had.

[0128] Particularly, according to the embodiments disclosed in the present application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program contains program codes for executing the methods shown in the flowcharts. In such an embodiment, the computer program can be downloaded and installed from the network through the communication device, or installed from the storage device 1003, or installed from the ROM 1002. When the computer program is executed by the processing device 1001, the above functions defined in the methods of the embodiments disclosed in the present application are executed.

[0129] The device for implementing CoPP based on protocol feature hardware recognition provided by this application adopts the method for implementing CoPP based on protocol feature hardware recognition in the above-mentioned embodiments, and can solve the technical problem that the existing control plane protection technology wastes hardware resources due to relying on ACL. Compared with the prior art, the beneficial effects of the device for implementing CoPP based on protocol feature hardware recognition provided by this application are the same as those of the method for implementing CoPP based on protocol feature hardware recognition provided by the above-mentioned embodiments, and other technical features in the device for implementing CoPP based on protocol feature hardware recognition are the same as the features disclosed in the method of the previous embodiment, which will not be elaborated here.

[0130] It should be understood that each part disclosed in this application can be implemented by hardware, software, firmware or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in a suitable manner in any one or more embodiments or examples.

[0131] The above is only the specific implementation manner of this application, but the protection scope of this application is not limited thereto. Any person skilled in the art can easily think of changes or substitutions within the technical scope disclosed in this application, and all should be covered by the protection scope of this application. Therefore, the protection scope of this application should be subject to the protection scope of the claims.

[0132] This application provides a computer-readable storage medium with computer-readable program instructions (i.e., computer programs) stored thereon, and the computer-readable program instructions are used to execute the method for implementing CoPP based on protocol feature hardware recognition in the above-mentioned embodiments.

[0133] The computer-readable storage medium provided by this application can be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or components, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections with one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM) or flash memory, optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the above. In this embodiment, the computer-readable storage medium can be any tangible medium that contains or stores a program, and this program can be used by or in combination with an instruction execution system, device, or component. The program code contained on the computer-readable storage medium can be transmitted by any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination of the above.

[0134] The above computer-readable storage medium can be included in a device that implements CoPP based on protocol feature hardware recognition; it can also exist independently and not be assembled into a device that implements CoPP based on protocol feature hardware recognition.

[0135] The above computer-readable storage medium carries one or more programs. When the above one or more programs are executed by a device that implements CoPP based on protocol feature hardware recognition, the device that implements CoPP based on protocol feature hardware recognition is caused to:

[0136] When a message is sent to the CPU, assign an identification code to the message based on the protocol type of the message;

[0137] Add an exception index mapping to the identification code and add a label to the exception index mapping;

[0138] Look up the Copp control table according to the exception index mapping to obtain a rate-limiting policy pointer;

[0139] Dynamically control the sending of the message based on the rate-limiting policy pointer.

[0140] Computer program code for performing the operations of this application can be written in one or more programming languages or combinations thereof. The above-mentioned programming languages include object-oriented programming languages such as Java, Smalltalk, C++, and also include conventional procedural programming languages such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, executed as an independent software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (for example, by connecting through the Internet using an Internet service provider).

[0141] The flowcharts and block diagrams in the accompanying drawings illustrate the possible architectures, functions, and operations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in the flowchart or block diagram can represent a module, a program segment, or a part of the code that contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than that marked in the accompanying drawings. For example, two consecutive blocks shown may actually be executed substantially in parallel, and they may sometimes be executed in the reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, and the combination of blocks in the block diagram and / or flowchart, can be implemented by a dedicated hardware-based system for performing the specified functions or operations, or can be implemented by a combination of dedicated hardware and computer instructions.

[0142] The modules described in the embodiments of this application can be implemented in software or in hardware. Among them, the name of the module does not constitute a limitation on the unit itself in some cases.

[0143] The readable storage medium provided in this application is a computer-readable storage medium. The computer-readable storage medium stores computer-readable program instructions (i.e., computer programs) for performing the above-mentioned method for implementing CoPP based on protocol feature hardware recognition, and can solve the technical problem that the existing control plane protection technology wastes hardware resources due to relying on ACL. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the method for implementing CoPP based on protocol feature hardware recognition provided in the above embodiments, and will not be elaborated here.

[0144] The present application also provides a computer program product, including a computer program which, when executed by a processor, implements the steps of the method for implementing CoPP based on protocol feature hardware recognition as described above.

[0145] The computer program product provided by the present application can solve the technical problem that the existing control plane protection technology wastes hardware resources due to dependence on ACL. Compared with the prior art, the beneficial effects of the computer program product provided by the present application are the same as those of the method for implementing CoPP based on protocol feature hardware recognition provided in the above embodiments, and will not be elaborated herein.

[0146] The above are only partial embodiments of the present application, and thus do not limit the patent scope of the present application. Any equivalent structural transformation made under the technical concept of the present application by using the content of the specification and drawings of the present application, or any direct / indirect application in other related technical fields, is included in the patent protection scope of the present application.

Claims

1. A method for implementing CoPP based on protocol feature hardware recognition, characterized in that, The method includes: When a message is sent to the CPU, an identification code is assigned to the message based on the protocol type of the message; An exception index mapping is added to the identification code, and a label is added to the exception index mapping; The Copp control table is searched according to the exception index mapping to obtain a rate limiting policy pointer; Based on the rate limiting policy pointer, the message sending is dynamically controlled.

2. The method for implementing CoPP based on protocol feature hardware recognition according to claim 1, wherein The step of searching the Copp control table according to the exception index mapping to obtain a rate limiting policy pointer includes: Based on the exception index mapping, a target item is located in the CoPP control table; The rate limiting mode, token bucket capacity, and token refresh rate are extracted from the target item; A rate limiting policy pointer is generated according to the rate limiting mode, the token bucket capacity, and the token refresh rate.

3. The method for implementing CoPP based on protocol feature hardware recognition according to claim 1, characterized in that The step of dynamically controlling the message sending based on the rate limiting policy pointer includes: Determining the CoPP rate limiting mode based on the rate limiting policy pointer; In the CoPP rate limiting mode, the message sending is dynamically controlled based on the single token bucket algorithm.

4. The method for implementing CoPP based on protocol feature hardware identification according to claim 3, wherein The step of dynamically controlling the message sending based on the single token bucket algorithm includes: Obtaining the token refresh rate and token bucket capacity in the CoPP rate limiting mode; Filling the token bucket according to the token refresh rate and the token bucket capacity; When the tokens in the token bucket are not exhausted, the tokens are deducted and the message is sent to the CPU; When the tokens in the token bucket are exhausted, the message is processed as ordinary traffic.

5. The method for implementing CoPP based on protocol feature hardware recognition as described in claim 4, wherein The step of filling the token bucket according to the token refresh rate and the token bucket capacity includes: Determining the reserved capacity of the token reservation pool and the shared capacity of the token sharing pool based on the token bucket capacity; Filling the token reservation pool and the token sharing pool according to the token refresh rate.

6. The method for implementing CoPP based on protocol feature hardware recognition according to claim 5, characterized in that The method further includes: When an attack is detected, temporarily reducing the shared capacity of the token sharing pool; When the protocol priority of a burst message is the first priority, borrowing tokens from the token sharing pool and sending the burst message to the CPU.

7. A device for implementing CoPP based on protocol feature hardware recognition, characterized in that, The apparatus for implementing CoPP based on protocol feature hardware identification includes: An identification code assignment module, which assigns an identification code to a message based on the protocol type of the message when the message is sent to the CPU; An exception index mapping module, which adds an exception index mapping to the identification code and adds a label to the exception index mapping; A rate limiting pointer acquisition module, which searches the Copp control table according to the exception index mapping to obtain a rate limiting policy pointer; A CoPP rate limiting module, which dynamically controls the message sending based on the rate limiting policy pointer.

8. A device for implementing CoPP based on protocol feature hardware recognition, characterized in that, The device includes: a memory, a processor, and a program for implementing CoPP based on protocol feature hardware identification stored on the memory and executable on the processor. The program for implementing CoPP based on protocol feature hardware identification is configured to implement the steps of the method for implementing CoPP based on protocol feature hardware identification according to any one of claims 1 to 6.

9. A storage medium, characterized in that, A program for implementing CoPP based on protocol feature hardware recognition is stored on the storage medium, and when the program for implementing CoPP based on protocol feature hardware recognition is executed by a processor, the steps of the method for implementing CoPP based on protocol feature hardware recognition according to any one of claims 1 to 6 are implemented.

10. A computer program product, characterized in that, The computer program product includes a computer program, and when the computer program is executed by a processor, the steps of the method for implementing CoPP based on protocol feature hardware recognition according to any one of claims 1 to 6 are implemented.

Images