This family of protocols can be called PSAMP and it’s well described in this RFC. It works by delivering truncated raw packet headers encoded in Netflow v9 or IPFIX formats to collector. These protocols do not implement any aggregation at all. Hardware just randomly samples packet, wraps it into IPFIX / Netflow packet and sends to collector.
Please ensure that you run at least version 2.0.361 before moving forward with this guide as we did multiple significant changes for protocol support.
Family of these protocols includes:
- IPFIX inline monitoring services, available in Juniper MX and PTX
- IPFIX 315 by Cisco, available in ASR 9000, NCS 5500
- Netflow v9 lite from Cisco, mostly available in switches
Instead of adding separate fields for port numbers, IP addresses, protocol IDs and other information from network packets these network telemetry protocols just add first X bytes (60-100) of packet header and deliver it to collector. In this way they behave like sFlow but they use Netflow and IPFIX protocols as transport to carry this data as they’re way more flexible.
Such approach provides great benefits as we have access to all information available in packet and we’re not limited by number of fields provided by vendor. In addition to that both protocols have no export delay and no flow aggregation. Both protocols offer extremely fast DDoS detection time which can be in range of few seconds. In most of the cases it implemented in hardware and it makes it one of most attractive protocols for network monitoring.
This family of protocol uses standard for Netflow or IPFIX way of sampling encoding which is completely supported by FastNetMon.
To enable support for each protocol you need to enable Netflow / IPFIX plugin first.
To confirm that these parsers work fine we offer following system metrics:
sudo fcli show system_counters|egrep 'lite|inline' netflow_v9_lite_headers 0 netflow_v9_lite_header_parser_error 0 ipfix_inline_headers 0 ipfix_inline_header_parser_error 0
As these protocols do not use aggregation you can set very short average calculation time to detect DDoS attack in a matter of seconds:
sudo fcli set main average_calculation_time 3
For Juniper MX we can offer following configuration example which enables IPFIX inline monitoring services on router:
set services inline-monitoring template FastNetMonInlineTemplate template-refresh-rate 30 set services inline-monitoring template FastNetMonInlineTemplate option-template-refresh-rate 100 set services inline-monitoring template FastNetMonInlineTemplate observation-domain-id 1 set services inline-monitoring instance FastNetMon-instance template-name FastNetMonInlineTemplate set services inline-monitoring instance FastNetMon-instance maximum-clip-length 126 set services inline-monitoring instance FastNetMon-instance collector FastNetMon-collector source-address 10.20.30.40 set services inline-monitoring instance FastNetMon-instance collector FastNetMon-collector destination-address 10.10.10.10 set services inline-monitoring instance FastNetMon-instance collector FastNetMon-collector destination-port 2055 set services inline-monitoring instance FastNetMon-instance collector FastNetMon-collector sampling-rate 1000 set interfaces xe-1/0/7 unit 0 family inet filter input FastNetMon-filter set interfaces xe-1/0/7 unit 0 family inet filter output FastNetMon-filter set firewall family inet filter FastNetMon-filter term 1 then inline-monitoring-instance FastNetMon-instance set firewall family inet filter FastNetMon-filter term 1 then accept
For Cisco ASR 9000 it can be enabled this way and for NCS 5500 you need to follow this guide.
FastNetMon has logic to strip outer GRE headers for this family of protocols and it can be enabled on protocol basis this way:
sudo fcli set main netflow_v9_extract_tunnel_traffic true sudo fcli set main ipfix_extract_tunnel_traffic true sudo fcli commit