Ingress and Egress Rates

[Rene Schipp von Branitz Nielsen]

Hello folks,

Which members of an sFlow PDU does sFlowTrend use to calculate Ingress and Egress Rates shown in Network -> Top N?

How are the computations made?

Please refer to the 'struct flow_sample' member names (from http://www.sflow.org/sflow_version_5.txt) in the reply.

Thanks in advance,
René

[Stuart Johnston]

René,

You can use the frame_length and stripped fields, assuming that the data is from a sampled_header. You of course also would need to scale the data appropriately (eg see Packet Sampling Basics).

regards,

Stuart

--
 
 

[Rene Schipp von Branitz Nielsen]

Thanks for the reply.

However, I was more thinking how flow_sample->source_id, flow_sample->input, and flow_sample->output are used to determine the rate on a given interface.

The thing is that the frame rate reported by sFlowTrend is twice as high as the actual frame rate on the given port of the switch I'm monitoring.

It could be because the switch reports flow_sample->output = 0 (unknown output interface), when it Rx samples a frame. In such frames, flow_sample->input = flow_sample->source_id = ingress_port.
When the switch Tx samples, it also knows the ingress port and therefore sets flow_sample->input = ingress_port and flow_sample->output = flow_sample->source_id = egress_port.

Is this a malbehavior of the switch, and if so, what is the switch supposed to do?

Thanks,
René

[Stuart Johnston]

René,

Sorry for the delay, I was on vacation.

It looks like the problem is caused by the output interface being set to 0 when ingress sampling. Ideally, the switch should not do this, because obviously the traffic cannot be attributed to the correct egress port. In this case, it is made worse by egress sampling also being active, which does have the ingress and egress port available; this causes sFlowTrend to count the frame twice. The easiest fix for this would be to switch off ingress sampling for all interfaces on the switch. If egress sampling is enabled on all interfaces, then you would still see full visibility to all your traffic.

regards,

Stuart

--
You received this message because you are subscribed to the Google Groups "sFlow" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sflow+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Rene Schipp von Branitz Nielsen]

Hi Stuart,

That makes sense. However, I can't find anything in the standard describing that sFlow-enabled devices must support enabling/disabling flow samples per direction (ingress/egress).

Also, suppose you get the switch to only sample egress traffic and you then enable sFlow on a single port that only receives and never transmits. In this case the switch will never transmit any sFlow samples, which will come as a surprise to the end-user, I guess.

What would happen if I got the switch to report unknown ingress interface on egress samples?

Thanks,
René

[Stuart Johnston]

Hi René,

The standard doesn't mandate that you can enable one direction of sampling specifically.

You are right, if sampling is enabled on only one interface, then all traffic would not be seen. However, the intention of sFlow is that it is enabled everywhere possible, certainly on all interfaces on one device.

If you are able to make the switch report unknown for the ingress interface, on egress samples, then the traffic reported per interface will be correct. However, this will be mirrored by the traffic reported for the unknown interface, which means that the traffic for the whole switch will still be double the correct value. Basically, if there is a flow from interface i to j, then we will see this from i to unknown, and separately from unknown to j, and not be able to correlate the two, so they will both be counted.

Stuart