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.
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.
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.
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 = 155The 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 trafficAs 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 icmpBeing 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.
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.
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.
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]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 flagA 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#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.
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-protectionMost 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 = 155The 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: 0In 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 NoThe 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 NoThe 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-optionsThe 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 OkNot 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: 0The 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 informationAs 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-fpcstatement 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 protocolscommand now displaysPartialin the Enabled field to indicate when some of the instances of the policer are disabled, and displaysdisabledwhen all policers are disabled.The routing engine information section of the
show ddos-protection protocolscommand output now includes fields for bandwidth, burst, and state.The
show ddos-protection protocols parameterscommand and theshow ddos-protection protocols statisticscommand now include aterseoption to display information only for active protocol groups—that is, groups that show traffic in the Received (packets) column. Theshow ddos-protection protocols parameterscommand also displayspartialfor policers that have some disabled instances.
Get Juniper MX Series now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
