O'Reilly logo

Juniper MX Series by Harry Reynolds, Douglas Richard Hanks Jr.

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

DDoS Protection Case Study

The MX Trio platforms began offering built-in DDoS protection starting with release v11.2. This feature makes use of the extensive host-bound traffic classification capabilities of the Trio chipset along with corresponding policers, implemented at various hierarchies within the system, to ensure the RE remains responsive in the event of excessive control plane exception traffic, such as can occur as the result of misconfigurations, excess scaling, or intentional DDoS types of attacks targeting a router’s control plane.

The new low-level DDoS protection provides great benefit right out of the box, so to speak, but does not in itself mitigate the need for a RE protection filter to deny traffic that is not allowed or needed. When the new DDoS protection is combined with a strong RE filter, you can eliminate the need for policing functions in the filter, or for added protection you can continue to use RE filter-based policing as an added measure of safeguard, but in these cases you should ensure the RE filter-based policers have higher bandwidth values then the corresponding PFE and RE DDoS policers, or the policers in the RE will never have a chance to activate as the DDoS policers will see all the discard action. This is because a policer called from an input filter on the loopback interface is downloaded to the Trio PFE where it is executed before any DDoS policer functionality.

The Issue of Control Plane Depletion

As routers scale to provide service to more and more users with ever increasing numbers of services, it’s not uncommon to find them operating near their capacity, especially in periods of heavy load such as route flap caused by network failures. With each new service comes additional load, but also the potential for unexpected resource usage either due to intent or in many cases because of buggy software or configuration errors that lead to unexpected operation.

Resource exhaustion can occur in a number of different places, each having their own set of operational issues. Run short on RIB/FIB and you may blackhole destinations or start using default routes with possibly undesirable paths. Low memory can lead to crashes, or slow reconvergence, as processes start swapping to disk. Run low on CPU, or on the internal communications paths needed to send and receive sessions to keep alive messages, and here comes even more trouble as BFD, BGP, and OSPF sessions begin flapping, which in turn only add more churn to an already too busy system.

In this section, the focus is on protecting the processing path, and therefore the control plane resources. Those control plane resources are needed to process remote access, routing protocols, and network management traffic as they make their way from a network interface through the PFE and onto the RE during periods of unexpected control plane traffic. The goal is to allow supported services, at reasonable levels, without allowing any one service or protocol to overrun all resources, a condition that can easily lead to denial of service for other protocols and users. Such a service outage can easily extend into the remote access needed to access a router in order to troubleshoot and correct the issue. There is little else in life as frustrating as knowing how to fix a problem, only to realize that because of the problem, you’re unable to access the device to take corrective actions.

DDoS Operational Overview

The Juniper DDoS protection feature is based on two main components: the classification of host-bound control plane traffic and a hierarchical set of individual- and aggregate-level policers that cap the volume of control plane traffic that each protocol type is able to send to the RE for processing.

These policers are organized to match the hierarchical flow of protocol control traffic. Control traffic arriving from all ports of a line card converges at the card’s Packet Forwarding Engine. Traffic from all PFEs converges into the line card/FPC. And lastly, 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 actually process. In total, there can be as many as five levels of policing between ingress at the Trio PFE and processing at RE, and that’s not counting any additional lo0-based filtering (with related policing) that can also be in effect.

In operation, control traffic is dropped when it violates a policer’s rate limit. Each violation generates a notification in the syslog to alert the operator about a possible attack. Each violation is counted and its start time is noted, and the system also maintains a pointer to the last observed violation start and end times. 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 violation state is cleared and a notification is again generated to report clearing of the DDoS event.

Once notified, it’s the operator’s responsibility to analyze the nature of the event to make a determination if the traffic type and volume that triggered the DDoS event was expected or abnormal. There is no easy answer here, as each network is scaled to different values with a differing mix of protocols and rate of churn. If the analysis concludes the volume of traffic was normal, then the related policers should be increased to avoid false alarms and potential service disruptions in the future. In contrast, protocols that are not used, or which are known to generate low message volume, can have their policers decreased.

Note

The default policer settings are intentionally set high to ensure there are no unwanted side effects to preexisting installations as they are upgraded to newer code with DDoS protection support, which is enabled by default. In most cases, operators will want to characterize their network’s expected control plane load and then decrease the default policer values to ensure they gain robust DDoS protection from the feature.

Policer states and statistics from each line card are relayed to the routing engine and aggregated. The policer states are maintained during a switchover. Note that during a GRES/NSR event, line card statistics and violation counts are preserved but RE policer statistics are not.

Warning

At this time, DDoS protection is a Trio-only feature. You can configure and commit it on a system that has older, DPC-style line cards but there will be no DDoS protection on those line cards. A chain is only as strong as the worst link; a system with a single line card that does not support DDoS is still vulnerable to an attack.

Host-Bound Traffic Classification

A modern multiservice router has to support a myriad of protocols, and multiprotocol support inherently assumes a method of recognizing each protocol so it can be directed to the correct processing daemon. The DDoS protection feature latches on to the Trio chipset’s rich protocol classification capability to correctly recognize and bin a large number of subscriber access, routing, network management, and remote access protocols. The current list is already large and expected to grow:

{master}[edit system ddos-protection global]
jnpr@R1-RE0# run show ddos-protection version
DDOS protection, Version 1.0
  Total protocol groups       = 84
  Total tracked packet types  = 155

The display shows that in v1.0, there are 84 protocol groups with a total of 155 unique packets types that can be individually policed. The CLI’s ? feature is used to display the current list:

{master}[edit system ddos-protection]
jnpr@R1-RE0# set protocols ?
Possible completions:
> ancp                 Configure ANCP traffic
> ancpv6               Configure ANCPv6 traffic
+ apply-groups         Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
> arp                  Configure ARP traffic
> atm                  Configure ATM traffic
> bfd                  Configure BFD traffic
> bfdv6                Configure BFDv6 traffic
> bgp                  Configure BGP traffic
> bgpv6                Configure BGPv6 traffic
> demux-autosense      Configure demux autosense traffic
> dhcpv4               Configure DHCPv4 traffic
> dhcpv6               Configure DHCPv6 traffic
> diameter             Configure Diameter/Gx+ traffic
> dns                  Configure DNS traffic
> dtcp                 Configure dtcp traffic
> dynamic-vlan         Configure dynamic vlan exceptions
> egpv6                Configure EGPv6 traffic
> eoam                 Configure EOAM traffic
> esmc                 Configure ESMC traffic
> firewall-host        Configure packets via firewall 'send-to-host' action
> ftp                  Configure FTP traffic
> ftpv6                Configure FTPv6 traffic
> gre                  Configure GRE traffic
> icmp                 Configure ICMP traffic
> igmp                 Configure IGMP traffic
> igmp-snoop           Configure snooped igmp traffic
> igmpv4v6             Configure IGMPv4-v6 traffic
> igmpv6               Configure IGMPv6 traffic
> ip-fragments         Configure IP-Fragments
> ip-options           Configure ip options traffic
> ipv4-unclassified    Configure unclassified host-bound IPv4 traffic
> ipv6-unclassified    Configure unclassified host-bound IPv6 traffic
> isis                 Configure ISIS traffic
> jfm                  Configure JFM traffic
> l2tp                 Configure l2tp traffic
> lacp                 Configure LACP traffic
> ldp                  Configure LDP traffic
> ldpv6                Configure LDPv6 traffic
> lldp                 Configure LLDP traffic
> lmp                  Configure LMP traffic
> lmpv6                Configure LMPv6 traffic
> mac-host             Configure L2-MAC configured 'send-to-host'
> mlp                  Configure MLP traffic
> msdp                 Configure MSDP traffic
> msdpv6               Configure MSDPv6 traffic
> multicast-copy       Configure host copy due to multicast routing
> mvrp                 Configure MVRP traffic
> ntp                  Configure NTP traffic
> oam-lfm              Configure OAM-LFM traffic
> ospf                 Configure OSPF traffic
> ospfv3v6             Configure OSPFv3v6 traffic
> pfe-alive            Configure pfe alive traffic
> pim                  Configure PIM traffic
> pimv6                Configure PIMv6 traffic
> pmvrp                Configure PMVRP traffic
> pos                  Configure POS traffic
> ppp                  Configure PPP control traffic
> pppoe                Configure PPPoE control traffic
> ptp                  Configure PTP traffic
> pvstp                Configure PVSTP traffic
> radius               Configure Radius traffic
> redirect             Configure packets to trigger ICMP redirect
> reject               Configure packets via 'reject' action
> rip                  Configure RIP traffic
> ripv6                Configure RIPv6 traffic
> rsvp                 Configure RSVP traffic
> rsvpv6               Configure RSVPv6 traffic
> services             Configure services
> snmp                 Configure SNMP traffic
> snmpv6               Configure SNMPv6 traffic
> ssh                  Configure SSH traffic
> sshv6                Configure SSHv6 traffic
> stp                  Configure STP traffic
> tacacs               Configure TACACS traffic
> tcp-flags            Configure packets with tcp flags
> telnet               Configure telnet traffic
> telnetv6             Configure telnet-v6 traffic
> ttl                  Configure ttl traffic
> tunnel-fragment      Configure tunnel fragment
> virtual-chassis      Configure virtual chassis traffic
> vrrp                 Configure VRRP traffic
> vrrpv6               Configure VRRPv6 traffic

As extensive as the current protocol list is, it’s just the outer surface of the MX router’s protocol recognition capabilities; all of the protocol groups listed support aggregate-level policing and many also offer per-packet type policers that are based on the individual message types within that protocol. For example, the PPP over Ethernet (PPPoE) protocol group contains an aggregate policer in addition to numerous individual packet type policers:

{master}[edit system ddos-protection]
jnpr@R1-RE0# set protocols pppoe ?

Possible completions:
> aggregate            Configure aggregate for all PPPoE control traffic
+ apply-groups         Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
> padi                 Configure PPPoE PADI
> padm                 Configure PPPoE PADM
> padn                 Configure PPPoE PADN
> pado                 Configure PPPoE PADO
> padr                 Configure PPPoE PADR
> pads                 Configure PPPoE PADS
> padt                 Configure PPPoE PADT
{master}[edit system ddos-protection]

In contrast, ICMP is currently supported at the aggregate level only:

{master}[edit system ddos-protection protocols]
jnpr@R1-RE0# set icmp ?
Possible completions:
> aggregate            Configure aggregate for all ICMP traffic
+ apply-groups         Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
{master}[edit system ddos-protection protocols]
jnpr@R1-RE0# set icmp

Being able to recognize this rich variety of traffic at ingress means it can be directed to an equally rich set of policing functions to ensure the control plane load remains within acceptable limits. Given that many protocol groups support both individual packet type policers as well as aggregate-level policing at multiple locations in the host-bound processing path, the DDoS protection feature provides both effective and fine-grained control over host processing path resource protection.

A Gauntlet of Policers

Hierarchical policing is the DDoS prevention muscle behind the host-bound classification brains. This style of hierarchical policing is more akin to cascaded policers and should not be confused with the hierarchical policer discussed previously. The goal is to take action to limit excessive traffic as close to the source as possible, with each lower policer component feeding into a higher level policer, until a final policed aggregate for that protocol type is delivered to the RE for processing.

Figure 4-2 details the various DDoS policing hierarchies in the context of the PPPoE protocol group.

DDoS policing Points for the PPPoE Family.

Figure 4-2. DDoS policing Points for the PPPoE Family.

The first level of policing is performed at ingress to the Trio chipset, shown in step 1, where each protocol group is subjected to a single policing stage that is either aggregate or individual packet type based.

Note

Currently, DHCP uses only an aggregate-level policer at the PFE stage, as is also the case at all stages for protocols that don’t support individual packet type policing. At the PFE and RE hierarchies, DHCP for IPv4 and IPv6 is handled by two-stage policing based on individual message types, in addition to an aggregate rate for the group.

The next level of policing occurs in the line card (FPC) level, as the aggregate stream from all PFEs housed on the FPC contend for their place in the host processing queue. In most cases, including DHCP, the second line of policing consists of two stages: the first for individual message types and the second for the protocols group aggregate, which is shown at steps 2 and 3. Only those messages accepted at the first step are seen at stage 2, and any packet accepted at steps 1 and 2 is still very much subject to discard by the aggregate-level policer at step 3 when there’s too much activity in its group.

Strict queuing is performed within individual message policers for a given protocol group to manage contention for the group’s aggregate policer, based on a configured priority of high, medium, or low. The strict priority handling is shown at the top of the figure, where PADT traffic consumes all 1,000 PPS of the group’s aggregate allowance even though other PPPoE message types are waiting. Here, PPPoE Active Discovery Termination (PADT) is considered more important than PPPoE Active Discovery Initiation (PADI), as it allows the release of PPPoE resources, which in turn facilitates the acceptance of new connections. Given the strict priority, all PADI will be dropped if PADT packets use up all the tokens of the PPPoE aggregate policer.

Note

Because high-priority traffic can starve lower priority traffic within its group, you should thoroughly consider modifying the priority for a given message type as the defaults have been carefully designed for optimal performance in a widest range of use cases.

The final level of policing hierarchy occurs within the RE itself, with another round of protocol group-based two-stage policing, shown in steps 4 and 5 within Figure 4-2. The output of this final stage consists of all the packets types for that group that were accepted by all policing stages in the path, which is then handed off to the associated daemon for message processing, assuming there are no lo0 filters or policers also in the host processing path.

The net result is a minimum of three policing stages for protocols that don’t have individual packet type policers and five for those that do. Aggregate-only groups currently include ANCP, dynamic VLAN, FTP, and IGMP traffic. Groups that support both stages of policing currently include DHCPv4, MLP, PPP, PPPoE, and virtual chassis traffic. As the feature matures, groups that are currently aggregate level-only can be enhanced to support individual message type policing as the need arises.

By default, all three stages of policing (Trio chipset, line card, and routing engine) have the same bandwidth and burst limits for a given packet type. This design enables all the control traffic from a chipset and line card to reach the RE, as long as there is no competing traffic of the same type from other chipsets or line cards. When competing traffic is present, excess packets are dropped at the convergence points, which are the line card for all competing chipsets and the RE for all competing line cards. You can use a scaling factor to reduce the first two stages below the default values (100% of that used in the RE) to fine tune performance.

Note that there is no priority mechanism at the aggregate policer merge points, as shown in Figure 4-2. While there is no explicit prioritization, the bandwidth is allocated in a statistically fair manner, which is to say, higher rate traffic streams get proportionally more bandwidth than lower rate streams, and by the same token, during congestion higher rate streams will also see more discards.

Note

At the time of this chapter’s writing, the CLI incorrectly offered priority as an option for aggregate policers. PR 722873 was raised to correct the issue.

The default policer values are intentionally set high to ensure valid services are not disrupted, given the DDoS feature is enabled by default, and each network varies with regard to what is considered a normal control plane load. Also, there is no one default size for all protocol groups because some message types are processed locally in the line card, and so can have a higher value, and the processing load can vary significantly for those that are sent to the RE. To gain maximum DDoS prevention, rather than after-the-fact notification, it’s expected that each network operator will reduce policer values from their generous defaults after analyzing actual load in their network.

Warning

Any time you lower a policer from its default, pay special attention to any alerts that may indicate it’s too low for your network. Such a condition can lead to an unintentional local DDoS attack when the more aggressive policer begins discarding valid protocol traffic.

Configuration and Operational Verification

The DDoS prevention feature is configured at the [edit system ddos-protection] hierarchy. While there, you can alter the default policer and priority values for a long list of protocols, configure tracing, or modify global operating characteristics such as disabling RE or FPC level DDOS policers and event logging.

{master}[edit system ddos-protection]
jnpr@R1-RE0# set ?
Possible completions:
+ apply-groups         Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
> global               DDOS global configurations
> protocols            DDOS protocol parameters
> traceoptions         DDOS trace options
{master}[edit system ddos-protection]

Disabling and Tracing

You can disable policing at the FPC level (but not at the Trio PFE level) by including the disable-fpc statement. Likewise, you can use the disable-routing-engine statement to do the same for the RE’s policers.

{master}[edit system ddos-protection global]
jnpr@R1-RE0# show
disable-routing-engine;
disable-fpc;

The two combined disable the last two levels of policing hierarchy, the FPC and RE levels; currently, the ingress Trio PFE-level policers cannot be disabled. Note that even when disabled the related daemon continues to run, and control plane policing remains in effect at the Trio PFE level. That last part no doubt sounds confusing, and so bears some clarification. Currently, you cannot disable the PFE level of policing, but the default values assigned to the policers are generally higher than that supported by the FPC-RE path, and so even though they remained enabled they are effectively transparent for traffic that needs to makes its way to the host.

Note

In the Junos v11.4 release, the CLI always shows the RE and FPC levels of policing as enabled, even when they have been globally disabled. PR 722873 was raised to track this issue.

If desired, you can completely disable the DDoS daemon, called jddosd, which collects policer statistics and generates logging of events, with a system processes ddos-protection disable configuration statement. If unexpected behavior is observed, and nothing else seems to help, consider restarting the process with a restart ddos-protection operational mode command.

Note

In the initial release, the default DDoS policer values are equal to the same “higher than host path can support” rates as are used when the feature is disabled. This means the only real effect to disabling the feature when defaults are in place is whether or not you receive alerts when a policer is violated. This also means that if you do not model your network’s control plane loads and reduce the default policer values accordingly, you are not gaining nearly as much protection from the DDoS feature as you could.

The decision to use default values that are higher than the host-bound path can actually support is based on the feature being enabled by default and the desire to be extra cautious about changing behavior when a customer upgrades to a newer version with DDoS support.

You can enable tracing to get additional information about DDoS operation and events by including trace flags—tracing is disabled by default. If desired, you can specify a log name and archive settings, rather than settle for the default /var/log/ddosd syslog, which by default is allowed to be 128 Kbytes before it’s saved as one of three rolling archive files named ddosd.0 through ddosd.2. The currently supported trace flags are displayed:

{master}[edit system ddos-protection]
jnpr@R1-RE0# set traceoptions flag ?
Possible completions:
  all                  Trace all areas of code
  config               Trace configuration code
  events               Trace event code
  gres                 Trace GRES code
  init                 Trace initialization code
  memory               Trace memory management code
  protocol             Trace DDOS protocol processing code
  rtsock               Trace routing socket code
  signal               Trace signal handling code
  state                Trace state handling code
  timer                Trace timer code
  ui                   Trace user interface code
{master}[edit system ddos-protection]
jnpr@R1-RE0# set traceoptions flag

A typical trace configuration is shown, in this case creating a syslog called ddos_trace with a file size of 10 Mbytes, tracking events and protocol-level operations. DDoS logging occurs at the notice severity level, so if you specify something less severe (like info) you will not see any trace logs:

{master}[edit system ddos-protection]
jnpr@R1-RE0# show traceoptions
file ddos_trace size 10m;
level notice;
flag protocol;
flag events;

Granted, there is not much to see on a system that’s not currently under some type of attack:

{master}[edit system ddos-protection]
jnpr@R1-RE0# run show log ddos_trace

{master}[edit system ddos-protection]
jnpr@R1-RE0#

Configure Protocol Group Properties

You can configure aggregate (and individual packet type) policing parameters when supported by the protocol group at the [edit system ddos-protection protocols] hierarchy. In most cases, a given group’s aggregate policer has a larger bandwidth and burst setting, which is calculated on a per packet basis, than any individual packet type policer in the group; however, the sum of individual policers can exceed the group’s aggregate rate. By default, the FPC- and Trio- PFE-level policers inherit bandwidth and burst size percentages values that are based on 100% of the aggregate or individual packet policer rate used at the RE level. From here, you can reduce or scale down the FPC percentages to limit them to a value below the RE policer rates, when desired. Again, the default setting of matching FPC to RE rate ensures that when no excess traffic is present, all messages accepted by the Trio policers are also accepted by the FPC-level policers, which in turn are also accepted by the RE-level policers.

In addition to policer parameters, you can also configure whether an individual policer type should bypass that group’s aggregate policer (while still having its individual packet type statistics tracked), whether exceptions should be logged, the scheduling priority for individual packet type policers, and the recovery time. You can also disable RE or FPC level policing on a per protocol group/message type basis.

This example shows aggregate and individual packet type policer settings for the ip-options group:

protocols {
    ip-options {
        aggregate {
            bandwidth 10000;
            burst 500;
        }

        unclassified {
            priority medium;
        }

        router-alert {
            bandwidth 5000;
            recover-time 150;
            priority high;
        }
    }
}

The bandwidth and burst settings are measured in units of packets per second. The example shown explicitly sets the bandwidth and burst values for the ICMP aggregate policer and router alert individual message policers, and modifies the unclassified ICMP packet type to medium priority from its default of low. The router alert packet type has high priority by default; this example explicitly sets the default value. When burst size is not explicitly configured for an individual packet type, it inherits a value based on the aggregate’s default using a proprietary mechanism that varies the burst size according to the assigned priority, where high-priority gets a higher burst size.

In this case, the aggregate rate has been reduced from 20K PPS to 10K PPS with a 500 packet burst size. The router alert individual message type has its bandwidth set to one-half that of the aggregate at 5K PPS; has been assigned a 150-second recovery time, which determines how long the traffic has to be below the threshold before the DDoS event is cleared; and has been assigned a high priority (which was the default for this message type). The only change made to the unclassified packet type is to assign it a medium priority. This change does not really buy anything for this specific protocol group example, because the ip-option group only has two members contending for the aggregate. After all, a medium priority setting only matters when there is another member using low, given the strict priority that’s in effect when an individual packet type policer contends with other individual packet policers for access to the aggregate policer’s bandwidth. The high priority router alert messages can starve the unclassified group just as easily, regardless of whether it uses a medium or low priority. Note that in this example starvation is not possible because the group’s aggregate packet rate exceeds the individual rate allowed for IP optioned packets. Starvation will become an issue if the group’s aggregate had been set to only 5K, so pay attention to priority settings in relation to the aggregate rate for a given protocol type.

Verify DDoS Operation

You now confirm the configured settings and expected operation using various forms of the show ddos-protection operational mode command:

{master}[edit]
jnpr@R1-RE0# run show ddos-protection ?
Possible completions:
  protocols            Show protocol information
  statistics           Show overall statistics
  version              Show version
{master}[edit]
jnpr@R1-RE0# run show ddos-protection

Most of the meat is obtained with the protocols switch, as demonstrated in the following. The version option displays info on DDoS version along with the numbers of classified protocols:

{master}[edit]
jnpr@R1-RE0# run show ddos-protection version
DDOS protection, Version 1.0
  Total protocol groups       = 84
  Total tracked packet types  = 155

The statistics option provides a quick summary of current DDoS state:

{master}[edit]
jnpr@R1-RE0# run show ddos-protection statistics
DDOS protection global statistics:
  Currently violated packet types:    0
  Packet types have seen violations:  0
  Total violation counts:             0

In this example, let’s focus on the ip-options group and begin with the default parameters for this group:

{master}[edit]
jnpr@R1-RE0# run show ddos-protection protocols ip-options parameters brief
Number of policers modified: 0
Protocol    Packet      Bandwidth Burst  Priority Recover   Policer Bypass FPC
group       type        (pps)     (pkts)          time(sec) enabled aggr.  mod
ip-opt      aggregate   20000     20000  high     300       Yes     --     No
ip-opt      unclass..   10000     10000  low      300       Yes     No     No
ip-opt      rt-alert    20000     20000  high     300       Yes     No     No

The output confirms the group consists of an aggregate and two individual message types. The default values for bandwidth and burst are assigned, as are the individual priorities. You also see that neither individual message is allowed to bypass the aggregate and that the policers are enabled. The configuration is modified as per the previous example, and the changes are confirmed:

{master}[edit]
jnpr@R1-RE0# show | compare
[edit system]
+   ddos-protection {
+       traceoptions {
+           file ddos_trace size 10m;
+           level info;
+           flag protocol;
+           flag events;
+       }
+       protocols {
+           ip-options {
+               aggregate {
+                   bandwidth 10000;
+                   burst 500;
+               }
+               unclassified {
+                   priority medium;
+               }
+               router-alert {
+                   bandwidth 5000;
+                   recover-time 150;
+                   priority high;
+               }
+           }
+       }
+   }

{master}[edit]
jnpr@R1-RE0# run show ddos-protection protocols ip-options parameters brief
Number of policers modified: 3
Protocol    Packet      Bandwidth Burst  Priority Recover   Policer Bypass FPC
group       type        (pps)     (pkts)          time(sec) enabled aggr.  mod
ip-opt      aggregate   10000*    500*   high     300       Yes     --     No
ip-opt      unclass..   10000     10000  medium*  300       Yes     No     No
ip-opt      rt-alert    5000*     20000  high     150*      Yes     No     No

The output confirms the changes have taken effect; any nondefault value is called out with an “*.” Note the default burst values have been calculated in relation to the relative priority factored against the burst aggregate’s burst size, as was described previously. Use the show ddos-protection protocols command to display current violation state, traffic statistics, and details on the aggregate and individual packet type policer information for all or a selected protocol group:

{master}[edit system ddos-protection]
jnpr@R1-RE0# run show ddos-protection protocols ip-options ?
Possible completions:
  <[Enter]>            Execute this command
  |                    Pipe through a command
  parameters           Show IP-Options protocol parameters
  statistics           Show IP-Options statistics and states
  violations           Show IP-Options traffic violations
  aggregate            Show aggregate for all ip options traffic information
  unclassified         Show unclassified ip options traffic information
  router-alert         Show Router alert options traffic information
{master}[edit system ddos-protection]
jnpr@R1-RE0# run show ddos-protection protocols ip-options

The system baseline is now examined to confirm no current violations and that there has been very little ICMP activity since this system was booted:

{master}[edit]
jnpr@R1-RE0# run show ddos-protection protocols ip-options violations
Number of packet types that are being violated: 0

{master}[edit]
jnpr@R1-RE0# run show ddos-protection protocols ip-options statistics brief
Protocol    Packet      Received        Dropped        Rate     Violation State
group       type        (packets)       (packets)      (pps)    counts
ip-opt      aggregate   1               0              0        0         Ok
ip-opt      unclass..   0               0              0        0         Ok
ip-opt      rt-alert    1               0              0        0         Ok

Not only are the current traffic rate counters at 0, but the cumulative counter is also very low, with a single router alert IP optioned packet having been detected thus far. To see details, omit the brief switch:

{master}[edit]
jnpr@R1-RE0# run show ddos-protection protocols ip-options router-alert
Protocol Group: IP-Options

  Packet type: router-alert (Router alert options traffic)
    Individual policer configuration:
      Bandwidth:        5000 pps
      Burst:            20000 packets
      Priority:         high
      Recover time:     150 seconds
      Enabled:          Yes
      Bypass aggregate: No
    System-wide information:
      Bandwidth is never violated
      Received:  1                   Arrival rate:     0 pps
      Dropped:   0                   Max arrival rate: 0 pps
    Routing Engine information:
      Policer is never violated
      Received:  1                   Arrival rate:     0 pps
      Dropped:   0                   Max arrival rate: 0 pps
        Dropped by aggregate policer: 0
    FPC slot 1 information:
      Bandwidth: 100% (5000 pps), Burst: 100% (20000 packets), enabled
      Policer is never violated
      Received:  0                   Arrival rate:     0 pps
      Dropped:   0                   Max arrival rate: 0 pps
        Dropped by aggregate policer: 0
    FPC slot 2 information:
      Bandwidth: 100% (5000 pps), Burst: 100% (20000 packets), enabled
      Policer is never violated
      Received:  1                   Arrival rate:     0 pps
      Dropped:   0                   Max arrival rate: 0 pps
        Dropped by aggregate policer: 0

The output for the router alert individual packet policer confirms systemwide settings, as well as traffic and policer statistics for both the RE and FPC hierarchies. Note that the first-stage Trio PFE-level stats are not displayed in the CLI, but violations are reported via the FPC housing that Trio PFE. With the information provided, you can quickly discern if there is currently excess router alert traffic, whether excess traffic has been detected in the past, and if so, the last violation start and end time. The per FPC displays include any alerts or violation that have been detected at either the Trio chipset or the FPC policing levels, information that allows you to quickly determine the ingress points for anomalous control plane traffic.

You cannot clear violation history except with a system reboot. You can clear a specific group’s statistics or clear a current violation state using the clear ddos-protection protocols command:

{master}[edit]
jnpr@R1-RE0# run clear ddos-protection protocols ip-options ?
Possible completions:
  statistics           Clear IP-Options statistics
  states               Reset IP-Options states
  aggregate            Clear aggregate for all ip options traffic information
  unclassified         Clear unclassified ip options traffic information
  router-alert         Clear Router alert options traffic information

Late Breaking DDoS Updates

As noted previously, the DDoS feature is new. Like most new things, it continues to evolve based on customer and field engineer feedback. The DDoS coverage in this section was based on the v11.4R1.9 Junos release. As it happens, the v11.4R2 release contained updates that enhance the feature, and this seemed a good place to capture them. As always, you should consult the latest Junos feature documentation for your release to ensure you stay abreast of feature evolution. User visible changes to DDoS in 11.4R2 include:

  • It’s now possible to include the disable-fpc statement at the [edit system ddos-protection protocols protocol-group (aggregate | packet-type)] hierarchy level to disable policers on all line cards for a particular packet type or aggregate within a protocol group. The ability to configure this statement globally or for a particular line card remains unchanged.

  • The show ddos-protection protocols command now displays Partial in the Enabled field to indicate when some of the instances of the policer are disabled, and displays disabled when all policers are disabled.

  • The routing engine information section of the show ddos-protection protocols command output now includes fields for bandwidth, burst, and state.

  • The show ddos-protection protocols parameters command and the show ddos-protection protocols statistics command now include a terse option to display information only for active protocol groups—that is, groups that show traffic in the Received (packets) column. The show ddos-protection protocols parameters command also displays partial for policers that have some disabled instances.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required