ON THIS PAGE
Control Plane Distributed Denial-of-Service (DDoS) Protection Overview
A denial-of-service (DoS) attack is any attempt to deny valid users access to network or server resources by using up all the resources of the network element or server. Distributed denial-of-service (DDoS) attacks involve an attack from multiple sources, enabling a much greater amount of traffic to attack the network. The attacks typically use network protocol control packets to trigger a large number of exceptions to the device’s control plane. This results in an excessive processing load that disrupts normal network operations.
With a single point of DDoS protection management, network administrators can customize profiles for their network control traffic. For routers, protection and monitoring persists across graceful Routing Engine switchover (GRES) and unified in-service-software-upgrade (ISSU) switchovers. Protection is not diminished as the number of subscribers increases.
Host-bound Traffic Policers for DDoS Violations
To protect the control plane against DDoS attacks, devices have policers enabled by default for host-bound traffic. If needed, you can modify many policer default values. Host-bound traffic is traffic destined to the Routing Engine, including protocol control packets for routing protocols, such as OSPF and BGP. Traffic destined to router IP addresses is also considered host-bound traffic.
The policers specify rate limits for all control traffic for a given protocol, or, in some cases, for specific control packet types for a protocol. You can monitor policer actions for packet types and protocol groups at the level of the device, Routing Engine, and line cards. You can also control logging of policer events.
Devices drop control traffic when it exceeds default or configured policer values. When a DDoS violation occurs, the device will not stop processing packets; it only limits their rate. Each violation immediately generates a notification to alert operators about a possible attack. The device counts the violation and notes the time that the violation starts and the time of the last observed violation. When the traffic rate drops below the bandwidth violation threshold, a recovery timer determines when the traffic flow is considered to have returned to normal. If no further violation occurs before the timer expires, the device clears the violation state and generates a notification.
On PTX routers and QFX Series switches, the timer is set to 300 seconds and cannot be modified.
The first line of protection is the policer on the Packet Forwarding Engine (PFE). On devices with multiple line cards, policer states and statistics from each line card are relayed to the Routing Engine and aggregated. The policer states are maintained during a switchover. Although line card statistics and violation counts are preserved during a switchover, Routing Engine policer statistics are not. Control traffic arriving from all ports of the line card converges on the Packet Forwarding Engine, where it is policed, dropping excess packets before they reach the Routing Engine and ensuring the Routing Engine receives only the amount of traffic it can process.
ACX Series routers that support this feature only support aggregate policers, and don’t support policing at the line card level. You can change the default policer values at the Routing Engine level globally or for specific protocol groups, which propagates down to the PFE chipset level. However, you can’t apply additional scaling parameters at the line card level like on other devices. You can disable policing at the Routing Engine level globally or for specific protocol groups. Disabling policing globally effectively disables control plane DDoS protection on the device.
QFX10000 Series switches and PTX Series routers enforce DDoS protection limits at three levels, in the PFE chipset, line card, and the Routing Engine.
In addition to providing notification of violations through event logging, control plane DDoS protection allows you to monitor policers, obtaining information such as policer configuration, number of violations encountered, date and time of violations, packet arrival rates, and number of packets received or dropped.
Control plane DDoS protection policers act on the system’s traffic queues. The QFX5100 and QFX5200 lines of switches manage traffic for more protocols than the number of queues, so the system often must map more than one protocol to the same queue. When traffic for one protocol shares a queue with other protocols and violates DDoS protection policer limits, these devices report a violation on that queue for all mapped protocols because the system doesn’t distinguish which protocol’s traffic specifically caused the violation. You can use what you know about the types of traffic flowing through your network to identify which of the reported protocols actually triggered the violation.
Platform Support
In Junos OS Release 14.2 and later releases, control plane DDoS protection is supported on specific platforms. In general, some models of the following platforms have control plane DDoS protection enabled by default and support configuration options to change default policer parameters:
ACX Series routers.
EX9200 switches.
MX Series routers that have only MPCs installed.
MX Series routers with a built-in MPC.
Note:For simplicity, where the text refers to line cards or line card policers, for these routers that means the built-in MPC.
Because these routers do not have FPC slots, information displayed in
FPCfields byshowcommands actually refers to TFEB.PTX Series routers that have only PE-based FPCs installed (PTX3000, PTX5000, PTX1000, and PTX10000) support control plane DDoS protection starting in Junos OS Release 17.4R1.
PTX10002 routers support control plane DDoS protection starting in Junos OS Release 18.2R1.
PTX10003 routers support control plane DDoS protection starting in Junos OS Evolved Release 19.3R1.
PTX10004 routers support control plane DDoS protection starting in Junos OS Evolved Release 20.3R1.
PTX10008 routers support control plane DDoS protection starting in Junos OS Evolved Release 20.1R1.
QFX Series switches, including the QFX5100 line, QFX5200 line, and the QFX10000 line of switches.
QFX10002-60C switches support control plane DDoS protection starting in Junos OS Release 18.1R1.
T4000 routers that have only Type 5 FPCs installed.
On Junos Evolved platforms you must configure the
inetand/orinet6protocol family on the device's lo0 interface for DDoS protection to work for those protocol families, respectively.Some EX Series switches might have control plane DDoS protection but don’t support CLI options to show or change the default policer parameters.
For router platforms that have other line cards in addition to MPCs (MX Series), Type 5 FPCs (T4000), or PE-based FPCs (PTX3000, PTX5000, PTX1000, and PTX10000), the CLI accepts the configuration but the other line cards are not protected, so the router is not protected.
Control plane DDoS protection support for Enhanced Subscriber Management was added in Junos OS Release 17.3R1 on routing platforms.
To change default-configured control plane DDoS protection parameters for supported protocol groups and packet types, supporting ACX Series routers, PTX Series routers and QFX Series switches have CLI configuration options that differ significantly from the options available for MX Series and T4000 routers. See the following configuration statements for the available configuration options on different devices:
For routing devices except PTX Series routers, see protocols (DDoS).
For ACX Series routers, PTX Series routers and QFX Series switches, see protocols (DDoS) (ACX Series, PTX Series, and QFX Series).
Policer Types and Packet Priorities
Control plane DDoS protection includes two types of policers:
An aggregate policer is applied to the complete set of packet types that belong to a protocol group. For example, you can configure an aggregate policer that applies to all PPPoE control packet types or to all DHCPv4 control packet types. You can specify bandwidth (packets per second [pps]) and burst (packets in a burst) limits, scale the bandwidth and burst limits, and set a traffic priority for aggregate policers. An aggregate policer is supported by all protocol groups.
An individual policer, also referred to as a packet-type policer, is allocated for each control packet type within a protocol group. For example, you can configure a policer for one or more types of PPPoE control packets, RADIUS control packets, or multicast snooping packets. You can specify bandwidth (pps) and burst (packets) limit values, scale the bandwidth and burst limits, and set a traffic priority for packet-type policers. Individual policers are available for some protocol groups.
Protocol group and packet type support varies across platforms and Junos OS releases, as follows:
For routing devices except PTX Series routers, see protocols (DDoS).
For ACX Series routers, PTX Series router, and QFX Series switches, see protocols (DDoS) (ACX Series, PTX Series, and QFX Series).
A control packet is policed first by its individual policer (if supported) and then by its aggregate policer. A packet dropped by the individual policer never reaches the aggregate policer. A packet that passes the individual policer can subsequently be dropped by the aggregate policer.
ACX Series routers only support the aggregate policer for any supported protocol groups.
Packet types within a protocol group have a default, configurable priority: low, medium, or high. Each control packet competes with other packets for the bandwidth within the packet rate limit imposed by its aggregate policer based on the priority configured for each packet type in the protocol group.
The priority mechanism is absolute. High-priority traffic gets bandwidth in preference to medium-priority and low-priority traffic. Medium-priority traffic gets bandwidth in preference to low-priority traffic. Low-priority traffic can use only the bandwidth left by high-priority and medium-priority traffic. If higher priority traffic takes all of the bandwidth, then all the lower priority traffic is dropped.
In releases before Junos OS Release 23.2R1, on MX Series devices, the type of line card in the device drives the distributed denial of service (DDoS) priority of incoming protocols. Starting in Junos OS Release 23.2R1, the device determines the DDoS priority of a protocol based on the DDoS parameters table. This enhancement enables the device to treat all packets of a particular protocol the same by default, regardless of the device's line card. You can modify the DDoS parameters table using CLI. This feature improves consistency in the way devices in the network prioritize protocols to protect against DDoS attacks.
Policer Priority Behavior Example
For example, on a device that supports control plane DDoS protection for the PPPoE protocol group, consider how you might configure packet types within this protocol group. Ignoring other PPPoE packet types for this example, suppose you configure individual policers for PADI and PADT packets, as well as a PPPoE aggregate policer for all those packets. You prioritize PADT packets over PADI packets because PADT packets enable the PPPoE application to release resources to accept new connections. Therefore, you assign high priority to the PADT packets and low priority to the PADI packets.
The aggregate policer imposes a total packet rate limit for the protocol group. PADT packets passed by their individual policer have access to that bandwidth before PADI packets passed by their individual policer, because the PADT packets have a higher priority. If so many PADT packets are passed that they use all the available bandwidth, then all the PADI packets are dropped, because there is no bandwidth remaining at the aggregate policer.
Policer Hierarchy Example
Control plane DDoS policers are organized to match the hierarchical flow of protocol control traffic. Control traffic arriving from all ports of a line card converges on the Packet Forwarding Engine. Control traffic from all line cards on the router converges on the Routing Engine. Similarly, the DDoS policers are placed hierarchically along the control paths so that excess packets are dropped as early as possible on the path. This design preserves system resources by removing excess, malicious traffic so that the Routing Engine receives only the amount of traffic that it can process.
To implement this design on MX Series routers, for example, five DDoS policers are present: One on the Packet Forwarding Engine (the chipset), two at the line card, and two at the Routing Engine. An aggregate policer is also present on the Packet Forwarding Engine for some protocol groups, for a total of six policers; for simplicity, the text follows the general case. For example, Figure 1 shows the policer process for PPPoE traffic. Figure 2 shows the policer process for DHCPv4 traffic. (The same process applies to DHCPv6 traffic as well.)
Recall that PTX Series routers and QFX Series switches have a simpler design with policers in the Packet Forwarding Engine only. PTX10003 and PTX10008 routers enforce control plane DDoS protection limits at three levels, two at the Packet Forwarding Engine chipset and line card levels and one at the Routing Engine level. However, packet type and aggregate policers operate similarly on all of these platforms.
Control packets arrive at the Packet Forwarding Engine for processing and forwarding. The first policer (1) is either an individual policer (Figure 1) or an aggregate policer (Figure 2).
The first policer is an individual policer for protocol groups that support individual policers, with two exceptions. For DHCPv4 and DHCPv6 traffic, the first policer is an aggregate policer.
The first policer is an aggregate policer for protocol groups that support only aggregate policers.
Traffic that passes the first policer is monitored by one or both of the line card policers. If the card has more than one Packet Forwarding Engine, traffic from all Packet Forwarding Engines converges on the line card policers.
When the traffic belongs to a protocol group that supports individual policers, it passes through the line card individual policer (2) and then the line card aggregate policer (3). Traffic that passes the individual policer can be dropped by the aggregate policer. Although DHCPv4 and DHCPv6 traffic was monitored by an aggregate policer at the Packet Forwarding Engine, at the line card it is handled like other protocols that support individual policers.
When the traffic belongs to a protocol group that supports only aggregate policers, only the line card aggregate policer monitors the traffic.
Traffic that passes the line card policers is monitored by one or both of the Routing Engine policers. Traffic from all the line cards converges on the Routing Engine policers.
When the traffic belongs to a protocol group that supports individual policers, it passes through the Routing Engine individual policer (4) and then the Routing Engine aggregate policer (5). Traffic that passes the individual policer can be dropped by the aggregate policer. As it was at the line card level, DHCPv4 and DHCPv6 traffic at the Routing Engine is handled like other protocols that support individual policers.
When the traffic belongs to a protocol group that supports only aggregate policers, only the aggregate policer monitors the traffic.
With this design, three policers evaluate the traffic for protocol groups that support only aggregate policers. Among other groups, this includes ANCP, dynamic VLAN, FTP, and IGMP traffic. Traffic for protocol groups that support both aggregate and individual policers is evaluated by all five policers. Among other groups, this includes DHCPv4, MLP, PPP, PPPoE, and virtual chassis traffic.
Figure 1 shows how control plane DDoS protection polices PPPoE control packets:
PADR packets, for example, are evaluated at the first policer on the Packet Forwarding Engine to determine whether they are within the packet rate limits. PADR packets that exceed the limit are dropped.
All PADR packets that pass the policer on all Packet Forwarding Engines on the line card are next evaluated by the line card individual policer. PADR packets that exceed the limit are dropped.
All PADR packets that pass the line card individual policer proceed to the line card aggregate policer. PADR packets that exceed the limit are dropped.
All PADR packets that are passed by the line card aggregate policers on all line cards on the router proceed to the Routing Engine individual policer. PADR packets that exceed the limit are dropped.
Finally, all PADR packets that are passed by the Routing Engine individual policer proceed to the Routing Engine aggregate policer. PADR packets that exceed the limit are dropped. PADR packets that are not dropped here are passed along as safe, normal traffic.
By default, all three individual policers (Packet Forwarding Engine, line card, and Routing Engine) have the same packet rate limit for a given packet type. With this design, all the control traffic from a Packet Forwarding Engine and line card can reach the Routing Engine as long as there is no competing traffic of the same type from other Packet Forwarding Engines or line cards. When competing traffic is present, excess packets are dropped at the convergence points. That is, they are dropped at the line card for all competing Packet Forwarding Engines and at the Routing Engine for all competing line cards.
Example of Policer Behavior to Limit Packet Rate
For example, suppose you set the policer bandwidth option for PADI packets to 1000 packets per second. This value applies to the individual PADI policers at the Packet Forwarding Engine, the line card, and the Routing Engine. If only the card in slot 5 is receiving PADI packets, then up to 1000 PADI pps can reach the Routing Engine (if the PPPoE aggregate policer is not exceeded). However, suppose the card in slot 9 is also receiving PADI packets at 1000 pps and that its PPPoE aggregate policer is not exceeded. The traffic passes the individual and aggregate policers at both line cards and proceeds to the Routing Engine. At the Routing Engine, the combined packet rate is 2000 pps. Because the PADI policer at the Routing Engine allows only 1000 PADI pps to pass, it drops the excess 1000 packets. It continues to drop the excess packets for as long as the bandwidth (pps) limit is exceeded.
You can apply a scaling factor for both the bandwidth (pps) limit and the burst (packets in a burst) limit at the line card to fine-tune the traffic limits for each slot. For example, suppose the individual policer sets the PADI packet rate to 1000 pps and the burst size to 50,000 packets. You can reduce the traffic limit for PADI packets on any line card by specifying the slot number and scaling factor. A bandwidth scaling factor of 20 for slot 5 reduces the traffic in this example to 20 percent of 1000 pps, or 200 pps for the line card in that slot. Similarly, a burst scaling factor of 50 for that slot reduces the burst size by 50 percent to 25,000 packets. By default, scaling factors are set to 100 so traffic can pass through at 100 percent of the rate limit.
Control Plane DDoS Protection Compared to Subscriber Login Packet Overload Protection
In addition to the control plane DDoS protection capability, MX Series routers also have a built-in subscriber login overload protection mechanism. The login overload protection mechanism (also called a load-throttling mechanism) monitors the incoming subscriber login packets and admits only what the system is capable of handling in accordance with the prevailing load on the system. Packets in excess of what the system can handle are discarded. By shedding this excess load, the system is able to maintain optimal performance and prevent any degradation of login-completion rate under overload conditions. This mechanism uses minimal resources and is enabled by default; no user configuration is required.
The protection provided by this mechanism is secondary to what control plane DDoS protection provides as a first level of defense against high rates of incoming packets. Control plane DDoS protection operates on the Packet Forwarding Engine and protects against all packet types of all protocols. In contrast, the login overload protection mechanism is located on the Routing Engine and specifically operates only on incoming connection-initiation packets such as DHCPv4 DHCPDISCOVER, DHCPv6 SOLICIT, and PPPoE PADI packets.