[j-nsp] Modern IPFIX implementation
Havard Eidnes
he at uninett.no
Mon Sep 15 13:08:10 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.
I think that depends on which variant of IPFIX you choose to use
on the PTXes and MXes.
Juniper has implemented what they refer to as "inline
monitoring", which I guess is somewhat of a cross between sFlow
and IPFIX, as it includes some payload bytes in each sample.
On the PTX10001-36MR, we found that this collects a (small?)
number of samples in a single IPFIX export packet. However, when
we tried applying the same config on our MX routers (at least in
part in an effort to unify our configurations across platforms,
IMHO increasingly a lost cause), we ended up with just 1 record
in each exported IPFIX packet from the MX routers, and when we
tried reporting this as a bug, we got back "nope, this is as
designed". Go figure.
Ref. https://community.juniper.net/blogs/david-roy/2024/03/01/from-sflow-to-imon-sampling-on-mx10k-platforms
Regards,
- HÃ¥vard
More information about the juniper-nsp
mailing list