[j-nsp] Modern IPFIX implementation
Saku Ytti
saku at ytti.fi
Thu Sep 4 05:27:29 EDT 2025
PTX/ACX and likely any future IPFIX implementation for high PPS
devices is cacheless.
That is, once PTX sampling triggers, it immediately crafts an export
packet and sends it on its merry way.
This is mostly fine, in common SP networks the cache ~exclusively
contains cache entries that consist of 1 packet hit, cache is created,
but never hit again before idle-timer exports it.
The only real benefit in a typical situation like this is that the MX
implementation can pack multiple flows into an export packet, PTX only
does 1. This means for the same resolution/sampling-rate, PTX flow
export rate is much higher than MX flow export rate.
This export packet flow packing function is just the same with idle 1s
or idle 100s, so the only thing 100s idle does is delay your
statistics for 99s. Active timer and idle timer do nothing (provided
you're not artificially reducing your resolution beyond sampling-rate
by exploiting cache overflow)
Has anyone asked Juniper to fix PTX/ACX sampling, so that you could
turn 1:5000 to 100:500000, that is trigger sampling 100 times less
frequently, but once triggered pick 100 packets, and immediately write
them out to flow record.
This way PTX/ACX could have cache parity in given resolution for
export rate. IPFIX already supports reporting sampling rate like this,
infact the legacy way is deprecated. And Nokia actually exports IPFIX
records which use this sampling rate reporting style.
Arbor, nfcapd, akvorado have been fixed to support this sampling rate style.
Flow export rate matters for some scenarios, mainly due to commercial reasons.
--
++ytti
More information about the juniper-nsp
mailing list