Juniper sFlow and Inline IPFIX Setup for DDoS Detection

To configure sFlow or inline IPFIX on Juniper MX or QFX for DDoS detection, enable sampling on your external-facing interfaces, point the exporter at a collector, and pick a sample rate that gives enough samples without overloading the line card or routing engine. MX routers (Trio MPCs) are usually best served by inline IPFIX (inline-jflow), while QFX switches typically use sFlow.

This guide shows working configurations for both, sensible starting sample rates, platform limits to check, and the commands that prove flows are actually leaving the box. All addresses use documentation ranges.

Which method on which platform

Support differs by Junos release, line card and chip generation. Check the Juniper Feature Explorer for your exact hardware and version before you plan a rollout. If you need a refresher on the protocol trade-offs, see our comparison of sFlow vs NetFlow vs IPFIX for DDoS detection.

Option 1: Inline IPFIX on MX

Inline flow monitoring has three parts: a template, a sampling instance bound to an FPC, and sampling enabled on interfaces.

# 1. IPFIX templates
set services flow-monitoring version-ipfix template IPV4 flow-active-timeout 60
set services flow-monitoring version-ipfix template IPV4 flow-inactive-timeout 15
set services flow-monitoring version-ipfix template IPV4 template-refresh-rate packets 1000
set services flow-monitoring version-ipfix template IPV4 option-refresh-rate packets 1000
set services flow-monitoring version-ipfix template IPV4 ipv4-template

set services flow-monitoring version-ipfix template IPV6 flow-active-timeout 60
set services flow-monitoring version-ipfix template IPV6 flow-inactive-timeout 15
set services flow-monitoring version-ipfix template IPV6 ipv6-template

# 2. Sampling instance, bound to the FPC
set chassis fpc 0 sampling-instance DDOS-SAMPLING
set chassis fpc 0 inline-services flow-table-size ipv4-flow-table-size 4
set chassis fpc 0 inline-services flow-table-size ipv6-flow-table-size 2

set forwarding-options sampling instance DDOS-SAMPLING input rate 1000
set forwarding-options sampling instance DDOS-SAMPLING family inet output flow-server 192.0.2.50 port 2055
set forwarding-options sampling instance DDOS-SAMPLING family inet output flow-server 192.0.2.50 version-ipfix template IPV4
set forwarding-options sampling instance DDOS-SAMPLING family inet output inline-jflow source-address 192.0.2.1
set forwarding-options sampling instance DDOS-SAMPLING family inet6 output flow-server 192.0.2.50 port 2055
set forwarding-options sampling instance DDOS-SAMPLING family inet6 output flow-server 192.0.2.50 version-ipfix template IPV6
set forwarding-options sampling instance DDOS-SAMPLING family inet6 output inline-jflow source-address 192.0.2.1

# 3. Enable on interfaces
set interfaces xe-0/0/1 unit 0 family inet sampling input
set interfaces xe-0/0/1 unit 0 family inet6 sampling input

Key points:

• The flow table size is allocated per FPC in units of 256K entries. Size it for your expected concurrent flows, including during an attack. Randomized-source floods create a huge number of unique flows.
• Repeat the chassis fpc N sampling-instance line for every FPC that carries sampled interfaces.
• The sample rate 1000 means 1 packet in 1000.
• Short active timeouts (60 seconds or less) help the detector see an attack sooner. Very long timeouts delay detection.

Option 2: sFlow on QFX (and MX where supported)

set protocols sflow agent-id 192.0.2.1
set protocols sflow source-ip 192.0.2.1
set protocols sflow polling-interval 20
set protocols sflow sample-rate ingress 2000
set protocols sflow collector 192.0.2.50 udp-port 6343
set protocols sflow interfaces xe-0/0/1.0
set protocols sflow interfaces xe-0/0/2.0

Per-interface sample rates can override the global value, which is useful when a 10G port and a 100G port sit on the same device. Sample ingress on external ports (transit, peering, IX). Sampling both directions on every port counts the same packet more than once and confuses per-IP thresholds.

On QFX, samples are taken by the ASIC but processed through the host path. An aggressive sample rate does not just cost bandwidth; it can hit internal limits and result in dropped samples. That is why QFX rates are usually higher numbers (fewer samples) than on MX inline IPFIX.

Choosing a sample rate

Start from packets per second, not bits per second. Samples per second = pps / sample rate.

Practical guidance (starting points, not vendor guarantees):

• A volumetric attack is easy to see even at conservative rates. The harder cases are small floods against a single IP, where too few samples arrive to cross a threshold reliably.
• Common starting points are 1:1000 on MX inline IPFIX and 1:2000 or higher on QFX sFlow. Raise the number on faster ports and lower it if detection of small attacks is too slow.
• Check that your thresholds are expressed in estimated pps/bps (sample count times rate) and that the collector knows the sampling rate. sFlow carries it in each sample; IPFIX needs it in sampling options data, so confirm your collector reads it.
• Do not change the rate casually. Baselines built at 1:1000 are not comparable with 1:4000. We cover this in NetFlow DDoS detection: thresholds, baselines, sampling.

Limits to check before rollout

• Flow table exhaustion (inline IPFIX): when the table is full, new flows are dropped or exported incompletely. Watch the error counters during tests.
• Export path: flow packets leave through the routing engine or forwarding path depending on configuration. Make sure the route to the collector exists in the right routing instance and is not blocked by an RE protection filter.
• UDP only: both protocols are connectionless. A lossy path to the collector means silently missing data.
• Line card mix: an older MPC or a non-Trio card on the same chassis may not support inline flow export. Confirm per slot.
• LAG: verify whether your platform samples on the aggregate unit or the members, and check that you do not sample twice.
• Tunnels and MPLS: inline IPFIX on family inet sees IP traffic. Labeled transit traffic needs separate handling and may need family mpls templates.

Verification commands

On the Juniper device for sFlow:

show sflow
show sflow collector
show sflow interface

You should see the collector address, the sample rate, and sample/packet counters that increase over time.

For inline IPFIX:

show services accounting status inline-jflow fpc-slot 0
show services accounting flow inline-jflow fpc-slot 0
show services accounting errors inline-jflow fpc-slot 0
show services accounting flow-detail

Look for active flows, exported flow records and packets, and zero (or stable) error counters. Rising "flow creation failures" or similar counters suggest table pressure.

Also check the configuration and interfaces:

show configuration forwarding-options sampling
show interfaces xe-0/0/1 extensive | match "Input rate|Output rate"

On the collector (Linux), confirm that packets arrive before blaming the detection software:

tcpdump -ni eth0 'host 192.0.2.1 and (udp port 2055 or udp port 6343 or udp port 4739)'

If you see nothing, check the source address, routing, firewall rules on the collector, and any RE filter on the router.

Common mistakes

1. Sampling every interface in both directions. This doubles counts and breaks per-IP thresholds. Sample ingress on edge ports.
2. Forgetting sampling input on the interface unit. The sampling instance alone does nothing.
3. Missing FPC binding. Without chassis fpc N sampling-instance, no flows are exported from that slot.
4. Tiny flow tables. Fine in the lab, then broken during a randomized-source attack.
5. Wrong source address. The collector may match exporters by IP. Use a stable loopback for source-address and source-ip.
6. Ignoring sample rate on the collector. Rates reported as 1:1 will produce thresholds that are off by orders of magnitude.
7. Testing only with normal traffic. Generate a controlled burst (for example from a lab host to a test IP in 198.51.100.0/24) and confirm the detector sees the right pps.

Connecting flows to detection and mitigation

Once flows export cleanly, you need something that evaluates per-IP and per-prefix bps/pps thresholds in near real time and acts on them. NixMon accepts NetFlow v5/v9, IPFIX and sFlow, so the Juniper configurations above can point straight at it. When a threshold is crossed, it can announce a BGP blackhole (RTBH) or a BGP FlowSpec rule toward your routers, trigger an on-prem NixGuard firewall, or use NixGuard Edge for cloud scrubbing if you have your own ASN and at least one /24.

You can test the whole path, from Juniper export to alert, with the 15-day free trial. No credit card is required. Run it in parallel with your current tooling first, compare detected pps against interface counters, then enable automated actions.