Anyone running with less than 30s ipfix active and inactive flow timeouts
willing to share positive or negative experiences? Our target platform is
mx10003.
We've been running active 60 inactive 30 for quite some time and are looking to
move closer to the known configuration floor of 10 for quicker flow based
anomaly detection. I've recently moved to a 30/30 stance. I plot
jnxOperatingCPU at 60s and couldn't see a change in the FPC graphs, which is
where I think I'd expect to see a change if any?
Has anyone tried 10s or 15s and regretted it? I'm not worried about the
collector impacts; those are easy to mitigate by adding more resources. I'm
already pushing into TSDB output of commands like "show services accounting
flow inline-jflow fpc-slot X" and "show services accounting errors inline-jflow
fpc-slot X" to observe general effects of my changes such as flow table size,
failed exports etc.
-Michael
=============/==============
example config:
services {
flow-monitoring {
version-ipfix {
template ipv4-ipfix {
flow-active-timeout 30;
flow-inactive-timeout 30;
template-refresh-rate {
packets 120000;
seconds 60;
}
option-refresh-rate {
packets 120000;
seconds 60;
}
ipv4-template;
}
template ipv6-ipfix {
flow-active-timeout 30;
flow-inactive-timeout 30;
template-refresh-rate {
packets 120000;
seconds 60;
}
option-refresh-rate {
packets 120000;
seconds 60;
}
ipv6-template;
}
}
}
}
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
