understanding sFlowFsTable and sFlow instances

[janklaas.kes...@gmail.com]

Hi,

After delving into the standard, I was wondering if my below assumptions are correct. 

From the standard, the sFlowFsTable contains sampling rates (and receivers) per flow sampler, it’s my understanding that a “flow sampler” Is the same as an “sFlow sampler”, which is linked to an sFlow instance. An sFlow instance is linked to one Data Source. In short, this table gives an overview of all sFlow Instances on the sFlow agent. Is this assumption correct?

 

In the MIB, the sFlowFsTable contains the receiver address, packet sampling rate and maximum header size. The standard doesn’t specify any other differentiators between sFlow instances.  So, if somebody wants to sample a packet flow, a vendor would need to support having an sFlow instance per packet flow. However, is this likely going to happen and is it according to the standard? 

 

Because, it’s my understanding this would go against the concept of sFlow being stateless, scalable, etc… 

Does this make any sense?

All the best,

Jan-Klaas 

[Peter Phaal]

On Tuesday, June 19, 2018 at 7:06:41 AM UTC-7, Jan-Klaas Kesteloot wrote:

After delving into the standard, I was wondering if my below assumptions are correct. 

From the standard, the sFlowFsTable contains sampling rates (and receivers) per flow sampler, it’s my understanding that a “flow sampler” Is the same as an “sFlow sampler”, which is linked to an sFlow instance. An sFlow instance is linked to one Data Source. In short, this table gives an overview of all sFlow Instances on the sFlow agent. Is this assumption correct?

You are correct. There are typically between 1 and 3 instances per data source (switch port).

 

In the MIB, the sFlowFsTable contains the receiver address, packet sampling rate and maximum header size. The standard doesn’t specify any other differentiators between sFlow instances.  So, if somebody wants to sample a packet flow, a vendor would need to support having an sFlow instance per packet flow. However, is this likely going to happen and is it according to the standard? 

The packet sampling rate and maximum header size are specified in the sFlowFsTable. The receiver address is specified in the sFlowRcvrTable and referenced in the sFlowFsTable.

sFlow does not allow you to sample specific packet flows. Packet sampling is enabled at the switch port level and all packets received on the port are candidates for sampling. Typically sampling is enabled on all ports to ensure that all packet flows are sampled.

Each packet sample includes metadata identifying ingress/egress ports, data source, sampling rate etc. The sFlow analyzer can select flows of interest. Generally, the sFlow architecture shifts complexity from the network device to the remote sFlow analyzer in order to reduce the hardware and software resources needed to implement an sFlow agent.

 

 

Because, it’s my understanding this would go against the concept of sFlow being stateless, scalable, etc… 

The sFlow architecture scales because the agent is largely stateless. Stateful measurements, like flow analysis, are performed by the collector where resources are relatively plentiful, https://blog.sflow.com/2010/09/superlinear.html

[Jan-Klaas Kesteloot]

Hi, thanks for the reply and for the clarification. Much appreciated. 

JK.