[j-nsp] Inline IPFIX sampling rate
pyxislx at gmail.com
Tue Jul 25 11:24:13 EDT 2017
Hi, Scott & Pavel.
The sampling rate of inline-sampling is always 1 since inline-sampling
process does NOT send samplingInterval(type 34, RFC5102) or
samplingPacketInterval(type 305, RFC7012) in information templates.
AFAIR there are some ambiguities on sampling rate in RFC5102, so
instead of referring to RFC3954(a.k.a. v9) which sends sampling rate
as type-34, MX sends nothing about sampling-rate.*
We ended up using NetFlow v9 on ASR/CRS/7750.
Here's the relevant thread on pmacct list. Again, I'm not sure this ER
got implemented or not.
*Note: At least at 14.2 or 15.1.
I'm not sure this got fixed or not in 17.2, but JTAC told us NOT to
use sampling on IPFIX(!)
We chose not to use MX for this then :)
Hope this helps.
On 7/25/17, Scott Granados <scott at granados-llc.net> wrote:
> I would be interested in this as well. My understanding was that the
> sampling rate in hardware was always set to 1:1 and the sample rate value
> was sent as the scaling factor for the sampling / reporting tool. Changing
> the rate had no practical effect to the actual data. If this has changed
> I’d be curious to know as well.
>> On Jul 25, 2017, at 5:30 AM, Pavel Lunin <plunin at gmail.com> wrote:
>> Hi list,
>> It's been long time I didn't write here :)
>> Does anyone know in details how sampling-rate works (if it does) for
>> IPFIX on MX/Trio?
>> AFAIR sampling rate config hadn't had any meaning for inline IPFIX until
>> some version of JUNOS. It used to be always 1, no matter what you have in
>> the config.
>> Question 1: If correct, which version it was when it's changed?
>> As of the 2nd edition of the MX book, "input rate" must follow the
>> “input_rate=2^n-1”. But it's somewhat poorly explained what it means.
>> Question 2: Do I correctly understand that the value, configured with
>> ”sampling instance <blah> rate <x>”, must conform to this rule. Here <x>
>> not the index of power of two (aka n in the formula above), it is the
>> actual sampling rate (result of the formula), right?
>> Question 3. Given that I correctly understand the previous point, what if
>> configured something that does not conform to this rule e. g. "rate 100"?
>> suspect that it should lead to "rate 1" being programmed in the PFE but
>> can't find a way to check this out. Anyone knows a uKernel command to
>> verify what is actually applied at the PFE level? It seems that "show
>> sample instance summary" just replicates the config values.
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
> juniper-nsp mailing list juniper-nsp at puck.nether.net
More information about the juniper-nsp