What Is CPCAR?

Why Do We Need CPCAR?

CPCAR is the core of CPU attack defense, and CPU attack defense is one of the local attack defense functions. Why is attack defense required for the CPU?

In addition to numerous normal service packets, the CPU of a network device may also receive large numbers of attack packets. Malicious attack packets will overwhelm the CPUs, affecting services and even causing a system breakdown. Mass legitimate packets will also lead to high CPU usage, degrading the CPU performance and interrupting services.

To ensure that the CPU can properly process and respond to normal services, the network device provides local attack defense, which has been specifically designed for packets sent to the CPU and is primarily used to protect the device from attacks and ensure consistency of existing services when an attack occurs.

How Does CPCAR Protect the Control Plane?

CPCAR rate-limits only packets sent to the control plane and processed by the CPU. This does not affect the forwarding of traffic that is not processed by the CPU, for example, traffic related to forwarding entries in the forwarding information base (FIB) table. As shown in the following figure, packets 1 and 4 are sent to the CPU and are therefore rate-limited by CPCAR. Packet 4 is discarded because its protocol rate exceeds the configured CPCAR value. Packets 2, 3, 5, and 6 are not processed by the CPU; therefore, they are not affected by CPCAR and are forwarded as expected.

How does CPCAR rate-limit protocol packets?

Core Technology of CPCAR

A network device identifies protocol packets of various services based on access control lists (ACLs) and applies committed access rate (CAR) to rate-limit the protocol packets sent to the CPU, protecting the control plane. CPCAR provides the following types of rate limiting for packets sent to the CPU: protocol-based rate limiting, queue-based scheduling and rate limiting, and unified rate limiting for all packets, as shown in the following figure.

Rate limiting for packets sent to the CPU

• Protocol-based rate limiting: If the traffic volume of a protocol is too large, other protocol packets cannot be processed in a timely manner. CPCAR supports setting of the committed information rate (CIR) and committed burst size (CBS) for each protocol. The device discards the protocol packets exceeding the rate limit. This ensures that services corresponding to each protocol can be normally processed and protocols do not affect each other.
• Queue-based scheduling and rate limiting: After rate limits for protocols are set, the device allocates a queue to each type of protocol. For example, the device allocates a queue to management protocols such as Telnet and SSH and a queue to routing protocols. Queues are scheduled based on weights or priorities, and services with higher priorities are more likely to be scheduled by the CPU. This ensures that higher-priority services are processed preferentially in case of conflicts. Rate limiting can also be implemented to limit the maximum rate of packets in each queue sent to the CPU, with the device discarding the protocol packets that exceed the rate limit in a queue.
• Unified rate limiting for all packets: After the rate limit for all the packets is set, the total number of packets sent to the CPU is limited and more protocol packets can be processed without affecting proper CPU running.

When the preceding three rate limiting modes take effect at the same time, the device limits the rate based on the minimum rate limit.

The default CPCAR values for protocol packets may not meet the dynamic requirements on the rate of protocol packets to be sent to the CPU. To resolve this problem, network devices provide adaptive CPCAR adjustment for protocol packets based on the service volume, packet loss behavior, and CPU usage.