[j-nsp] inline-jflow monitoring

Saku Ytti saku at ytti.fi
Wed Jan 2 05:49:26 EST 2019

On Wed, 2 Jan 2019 at 12:32, Dave Bell <me at geordish.org> wrote:

> Netflow/Jflow/IPFIX does not sample packets. It samples flows. A flow is
> (could be?) made up of many packets.

Everyone probably means the same thing here, but the way you are
saying it, is very confusing to me.

Sampling means we do not look at every packet, we use some algorithm
like 'every nTh' to choose which _packet_ gets looked at.

After we've chosen which _packet_ gets looked at, we store state or
flow for that packet, if we already have applicable flow stored, we
add packet/byte count in that stored flow.

Further, ipfix receiver will then multiply packet and byte count of
flows by sampling ratio, to approximate actual amount of packets/bytes
seen in given flow.

There are few reasons to choose non 1:1 sampling algorithm:

- regulatory requirements
- HW can't support 1:1
- desire to see fewer flows

In absence of specific reason to not do 1:1, you should do 1:1. Even
with 1:100 many flows will be just invisible to you, because there are
lot of short flows and statistically you'll never pick any packet out
of that flow, so you'll never record it. Sampling will necessarily
hide information, which is fine for traffic volume trending, ddos etc.

Trio does IPFIX in HW, it can inspect each and every packet with no
different cost. So if your flow table can survive it, do 1:1 and get
more visibility.


More information about the juniper-nsp mailing list