4

Hi Everyone,

Need to know the clear differences between RE protection and DDOS protection in Juniper MX. Both are used to save routing engine from depletion of resources. As mentioned in Juniper MX series book , policer called from an input filter on the loopback interface is downloaded to the Trio PFE where it is executed before any DDoS policier functionality.

With that being said , we can save the routing engine resources from depletion (which occurs for example due to icmp flood attack , snmp queries flooding , IP-fragments etc) using only protect re filter applied in inbound direction at loopback interface using filters and policiers , so then why in addition to RE filter DDOS protection comes into picture when protecting the routing engine?

Are there any issues that are not handled by RE filter but handled by DDOS protection very well or put in another way

Whats the main reason behind using DDOS protection in addition to protect RE filter

If possible , please share detailed answer.

Many Thanks

2

Whats the main reason behind using DDOS protection in addition to protect RE filter

You already mentioned one of the key points regarding the lo0 filter and DDoS protection, that is that the lo0 filter is checked first. The goal of the lo0 filter is reject control plane traffic that you know isn't ever needed your device, but what about traffic that is expected?

DDoS protection can protect you from attack vectors involving legitimate control traffic, such as ARP floods. It looks for bursts in traffic over a certain threshold and in order for the violation to clear, must drop below that threshold for a set period of time.

Furthermore, DDoS protection is implemented at various levels in the system:

  • First it checks for violations at the PFE level.
  • Second it checks for violations at an FPC level (aggregate of multiple PFEs)
  • Third it checks for violations at the RE level if the violating traffic happens to be so well distributed to not be caught by the PFE or FPC policers.

For subscriber management deployments there is an additional feature called SCFD (Suspicious Control Flow Detection), unlike the DDoS protection mechanisms mentioned above, this is not turned on by default. This works similarly to DDoS protection in that it can work at multiple levels. You can configure things to work at any number of levels:

  • Per Subscriber (flow): Detection takes place on every subscriber interface.
  • Per IFL (logical interface): Detection takes place based on the aggregate traffic of any subscribers terminated on the IFL.
  • Per IFD (physical interface): Detection takes place based on the aggregate traffic of all subscriber terminating IFLs on the physical interface.

As violations occur at any level, you can take 3 actions (you can set this per level as well):

  • Drop all traffic (default)
  • Police traffic (similar to DDoS)
  • Keep all traffic (basically detection only)
3

The Control Plane DDOS Protection feature is a sophisticated set of control-plane classifiers & policers. It's a great feature and you absolutely should be using it in addition to an ordinary control-plane filter for security.

Traffic can be admitted (or not) on a per-IFL basis so malicious traffic from one interface (port/VLAN/subscriber) doesn't have to affect traffic from a different interface -- each one can have its own policer and there are many distinct traffic classes in the default configuration, too.

This feature was implemented by request of broadband ISPs using MX-series as BRAS. They've understandably been worried about not only common Internet attacks like floods toward TCP/UDP-connected service ports, but also, Ethernet BPDU traffic, ARP/ND, and so on. The ddos-protection feature attempts to mitigate many possible attack vectors by enabling the per-interface/subscriber limits on CPU-bound traffic.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.