From saku at ytti.fi Thu Sep 4 05:27:29 2025 From: saku at ytti.fi (Saku Ytti) Date: Thu, 4 Sep 2025 12:27:29 +0300 Subject: [j-nsp] Modern IPFIX implementation Message-ID: 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