Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Example: Configuring Control Plane DDoS Protection

This example shows how to configure control plane DDoS protection that enables the router to quickly identify an attack and prevent a flood of malicious control packets from exhausting system resources.

Requirements

Control plane DDoS protection requires the following hardware and software:

  • MX Series routers that have only MPCs installed, T4000 Core Routers that have only FPC5s installed, EX9200 switches.

    Note:

    If a router has other cards in addition to MPCs or FPC5s, the CLI accepts the configuration but the other cards are not protected and therefore the router is not protected.

  • Junos OS Release 11.2 or later

No special configuration beyond device initialization is required before you can configure this feature.

Overview

Distributed denial-of-service attacks use multiple sources to flood a network or router with protocol control packets. This malicious traffic triggers a large number of exceptions in the network and attempts exhaust the system resources to deny valid users access to the network or server.

This example describes how to configure rate-limiting policers that identify excess control traffic and drop the packets before the router is adversely affected. Sample tasks include configuring policers for particular control packet types within a protocol group, configuring an aggregate policer for a protocol group and bypassing that policer for a particular control packet type, and specifying trace options for DDoS operations.

This example does not show all possible configuration choices.

Topology

Configuration

Procedure

CLI Quick Configuration

To quickly configure control plane DDoS protection for protocol groups and particular control packet types, copy the following commands, paste them in a text file, remove any line breaks, and then copy and paste the commands into the CLI.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode.

To configure DDoS protection:

  1. Specify a protocol group.

  2. Configure the maximum traffic rate (in packets per second [pps]) for the DHCPv4 aggregate policer; that is, for the combination of all DHCPv4 packets.

    Note:

    You change the traffic rate using the bandwidth option. Although the term bandwidth usually refers to bits per second (bps), this feature’s bandwidth option represents a packets per second (pps) value.

  3. Configure the maximum burst size (number of packets) for the DHCPv4 aggregate policer.

  4. Configure the maximum traffic rate (in pps) for the DHCPv4 policer for discover packets.

  5. Decrease the recover time for violations of the DHCPv4 discover policer.

  6. Configure the maximum burst size (number of packets) for the DHCPv4 discover policer.

  7. Increase the priority for DHCPv4 offer packets.

  8. Prevent offer packets from being included in the aggregate bandwidth (pps); that is, offer packets do not contribute towards the combined DHCPv4 traffic to determine whether the aggregate bandwidth (pps) is exceeded. However, the offer packets are still included in traffic rate statistics.

  9. Reduce the bandwidth (pps) and burst size (packets) allowed before violation is declared for the DHCPv4 offer policer on the MPC or FPC5 in slot 1.

  10. Configure the maximum traffic rate for the PPPoE aggregate policer, that is, for the combination of all PPPoE packets.

  11. Configure tracing for all DDoS protocol processing events.

Results

From configuration mode, confirm your configuration by entering the show ddos-protection command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

If you are done configuring the device, enter commit from configuration mode.

Verification

To confirm that the DDoS protection configuration is working properly, perform these tasks:

Verifying the DHCPv4 DDoS Protection Configuration and Operation

Purpose

Verify that the DHCPv4 aggregate and protocol policer values have changed from the default. With DHCPv4 and PPPoE traffic flowing, verify that the policers are working correctly. You can enter commands to display the individual policers you are interested in, as shown here, or you can enter the show ddos-protection protocols dhcpv4 command to display this information for all DHCPv4 packet types.

Action

From operational mode, enter the show ddos-protection protocols dhcpv4 aggregate command.

From operational mode, enter the show ddos-protection protocols dhcpv4 discover command.

From operational mode, enter the show ddos-protection protocols dhcpv4 offer command.

Meaning

The output of these commands lists the policer configuration and traffic statistics for the DHCPv4 aggregate, discover, and offer policers respectively.

The Aggregate policer configuration section in the first output example and Individual policer configuration sections in the second and third output examples list the configured values for bandwidth, burst, priority, recover time, and bypass-aggregate.

The System-wide information section shows the total of all DHCPv4 traffic statistics and violations for the policer recorded across all line cards and at the Routing Engine. The Routing engine information section shows the traffic statistics and violations for the policer recorded at the Routing Engine. The FPC slot 1 information section shows the traffic statistics and violations for the policer recorded only at the line card in slot 1.

The output for the aggregate policer in this example shows the following information:

  • The System-wide information section shows that 71,064 DHCPv4 packets of all types were received across all line cards and the Routing Engine. The section shows a single violation with a time stamp and that the aggregate policer at a line card dropped 23,115 of these packets.

  • The FPC slot 1 information section shows that this line card received all 71,064 DHCPv4 packets, but its aggregate policer experienced a violation and dropped the 23,115 packets shown in the other section. The line card individual policers dropped an additional 11,819 packets.

  • The Routing Engine information section shows that the remaining 36,130 packets all reached the Routing Engine and that its aggregate policer dropped no additional packets.

    The difference between the number of DHCPv4 packets received and dropped at the line card [71,064 - (23,115 + 11,819)] matches the number received at the Routing Engine. That might not always be the case, because packets can be received and dropped at more than one line card. In this example, only the line card in slot 1received any DHCPv4 packets.

The output for the DHCPv4 discover packet policer in this example shows the following information:

  • The System-wide information section shows that 47,949 DHCPv4 discover packets were received across all line cards and the Routing Engine. The section shows a single violation with a time stamp and that the aggregate policer at a line card dropped 11,819 of these packets.

  • The FPC slot 1 information section shows that this line card received all 47,949 DHCPv4 discover packets, but its individual policer experienced a violation and dropped the 11,819 packets shown in the other section.

  • The Routing Engine information section shows that only 36,130 DHCPv4 discover packets reached the Routing Engine and that it dropped no additional packets.

    The difference between the number of DHCPv4 discover packets received and dropped at the line card (47,949 - 11,819) matches the number received at the Routing Engine. That might not always be the case, because packets can be received and dropped at more than one line card. In this example, only the line card in slot 1received any DHCPv4 discover packets.

The output for the DHCPv4 offer packet policer in this example shows the following information:

  • This individual policer has never been violated at any location.

  • No DHCPv4 offer packets have been received at any location.

Verifying the PPPoE DDoS Configuration

Purpose

Verify that the PPPoE policer values have changed from the default.

Action

From operational mode, enter the show ddos-protection protocols pppoe parameters brief command.

From operational mode, enter the show ddos-protection protocols pppoe padi command, and enter the command for padr as well.

Meaning

The output from the show ddos-protection protocols pppoe parameters brief command lists the current configuration for each of the individual PPPoE packet policers and the PPPoE aggregate policer. A change from a default value is indicated by an asterisk next to the modified value. The only change made to PPPoE policers in the configuration steps was to the aggregate policer bandwidth limit (pps); this change is confirmed in the output. Besides the configuration values, the command output also reports whether a policer has been disabled, whether it bypasses the aggregate policer (meaning that the traffic for that packet type is not included for evaluation by the aggregate policer), and whether the policer has been modified for one or more line cards.

The output of the show ddos-protection protocols pppoe padi command in this example shows the following information:

  • The System-wide information section shows that 704,832,908 PPPoE PADI packets were received across all line cards and the Routing Engine. The section shows a single violation on a line card that is still in progress, and that the aggregate policer at the line card dropped 660,788,548 of the PADI packets.

  • The FPC slot 3 information section shows that this line card received all 704,832,908 PADI packets. Its individual policer dropped 660,788,548 of those packets and its aggregate policer dropped the other 4,094,030 packets. The violation is ongoing and has lasted more than a day.

  • The Routing Engine information section shows that only 39,950,330 PADI packets reached the Routing Engine and that it dropped no additional packets.

    The difference between the number of PADI packets received and dropped at the line card [704,832,908 - (660,788,548 + 4,094030)] matches the number received at the Routing Engine. That might not always be the case, because packets can be received and dropped at more than one line card. In this example, only the line card in slot 3 received any PADI packets.

The output of the show ddos-protection protocols pppoe padr command in this example shows the following information:

  • The System-wide information section shows that 494,663,595 PPPoE PADR packets were received across all line cards and the Routing Engine. The section shows a single violation on a line card that is still in progress, and that the policer at the line card dropped 484,375,900 of the PADR packets.

  • The FPC slot 1 information section shows that this line card received all 494,663,595 PADR packets. Its individual policer dropped 484,375,900 of those packets. The violation is ongoing and has lasted more than five hours.

  • The Routing Engine information section shows that only 10,287,695 PADR packets reached the Routing Engine and that it dropped no additional packets.

    The difference between the number of PADR packets received and dropped at the line card (494,663,595 - 484,375,900) matches the number received at the Routing Engine. That might not always be the case, because packets can be received and dropped at more than one line card. In this example, only the line card in slot 1 received any PADR packets.

Note:

This scenario is unrealistic in showing all PADI packets received on one line card and all PADR packets on a different line card. The intent of the scenario is to illustrate how policer violations are reported for individual line cards.