[j-nsp] Inline IPFIX sampling rate

Scott Granados scott at granados-llc.net
Tue Jul 25 15:41:10 EDT 2017


I can confirm the rate=1 regardless of behavior up through 13.2 up through the PFE programming blocked by flow PR when that bug was addressed.


> On Jul 25, 2017, at 1:39 PM, Euan Galloway <euan+j-nsp at galloway.cc> wrote:
> 
> Let's try that again, but to the list this time...
> 
> *sigh*
> 
> Euan
> 
> On 25 July 2017 at 10:30, Pavel Lunin <plunin at gmail.com> wrote:
> 
>> 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?
>> 
> 
> Although often said/documented/quoted, I've never actually seen this
> behavior (rate = 1 regardless of configuration).
> I'm *fairly* (but not 100%) sure that this didn't happen in late 11.x (even
> though referenced in MX book v1)
> It *certainly* doesn't happen in 12.3+
> 
> 
>> As of the 2nd edition of the MX book, "input rate" must follow the formula
>> “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> is
>> not the index of power of two (aka n in the formula above), it is the
>> actual sampling rate (result of the formula), right?
>> 
> 
> Right below the formula is a table of valid rates (described as
> "input-rate" throughout, rather than "rate")
> Shown as valid are 1 / 3 / 255 / 1023,
> 
>> 
>> Question 3. Given that I correctly understand the previous point, what if I
>> configured something that does not conform to this rule e. g. "rate 100"? I
>> suspect that it should lead to "rate 1" being programmed in the PFE but
>> 
> 
> It works (tested on 15.1F), no obvious difference in the % error for
> setting rate to 2 / 3 / 4 / 5 / 7 / 10.
> (Even though 3 and 7 are somehow "valid" and the rest not).
> 
> I suspect in some prior version it rounded up to the next valid number
> (since that's what commonly happens for other similar "you asked me to do
> something I can't, so I'll try my best to get close"). Also, I'm sure I've
> seen that behavior described by other users.
> 
> 
>> 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.
>> 
> Since it IS actually using the configured value, it's possible this IS the
> value programmed into the hardware.
> (but no, I don't know another command).
> I'll see what it shows on other versions, perhaps it used to round (I
> really doubt it ever just ignored you and did "1" if you missed the magic
> number).
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp



More information about the juniper-nsp mailing list