G/C3/B3 provides Less sFlow Sampling Data than Expected

[FAQ_User]

Article ID: 12908

Products
G-Series, firmware 6.03.00.0022 and higher
C3-Series, firmware 6.03.00.0022 and higher
B3-Series, firmware 6.03.00.0022 and higher

Changes
Configured the switch to provide sFlow Packet Sampler data, with or without Statistics Poller data.

Here is a sample configuration:

code:

#sflow

code:

set sflow receiver 1 owner myCollector timeout 4294637449

code:

set sflow receiver 1 ip 10.20.153.190

code:

set sflow port ge.1.1-24 sampler 1

code:

set sflow port ge.1.1 sampler rate 1024

code:

set sflow port ge.1.2 sampler rate 1024

code:

set sflow port ge.1.3 sampler rate 1024

code:

. . .

code:

set sflow port ge.1.24 sampler rate 1024

code:

set sflow port ge.1.1-24 poller 1

code:

set sflow port ge.1.1 poller interval 60

code:

set sflow port ge.1.2 poller interval 60

code:

set sflow port ge.1.3 poller interval 60

code:

. . .

code:

set sflow port ge.1.24 poller interval 60

The sFlow feature permits the user to configure up to 32 ports with Packet Samplers (each extracting one packet per average of 1024-65536 ingressed packets) and an unlimited number of ports with Statistics Pollers (each polling every 0-86400 seconds), continually sending the resulting data to a sFlow collector, which collates it to provide a broad cross-section of the volume and type of traffic that is entering the configured port(s).
Note1: The initally required receiver parameters are

code:

ip

,

code:

owner

, and

code:

timeout

. Until these are configured, it is not possible to successfully issue most of the other sflow 'set' commands. A violation of these rules will result in an "

code:

Incorrect input! Invalid Receiver index value.

" error.
Note2: The '

code:

set sflow port

<

port#

>

code:

sampler|poller

<

receiver#

>' commands set the designated ports to each operate a sampler and/or poller instance, reporting to the cited receiver instance. This is made clear in the output of the '

code:

show sflow sampler|poller

' commands.

Symptoms
The switch sends less sampled data to the sFlow collector than expected.
A similar configuration (specifying the same sampler rate) on a different switch model yields more sampled packet data.

Cause
As stated in the Configuration Guide regarding the '

code:

sampler rate

<

rate

>' parameter of the '

code:

set sflow port...

' command:

code:

Specifies the statistical sampling rate for sampling from this data source. The value of

rate

code:

specifies the number of incoming packets from which one packet will be sampled. For example, if the rate is 1024, one packet will be sampled from [an average of] every 1024 ingressing packets on this data source.

code:

The rate can range from 1024 to 65536. A value of 0 disables sampling. The default value is 0.

It might reasonably be expected that the total of the "

code:

In Unicast Pkts

", "

code:

In Multicast Pkts

", and "

code:

In Broadcast Pkts

" appearing in the output of a '

code:

show port counters

<

port#

>' command, divided by the sampler rate, would yield a close approximation of the number of sFlow sampler packets sent to the collector for that port during the switch's uptime.

It is likely, however, that the actual number of sFlow sampler packets sent to the collector will be fewer than estimated.

This is because the sFlow function of the switch's ASIC restarts the sampling process each second. This means that if the packet rate (in frames per second) on a port is less than the sampler rate, no sampling will occur for that second. It also means that a certain number of frames at the end of each one-second window will not be reported, which ultimately means that the sampler rate is likely to be effectively lower (lower rate = higher number) than what is configured.

This behavior is documented in firmware release notes (e.g. C3-Series f/w 6.03.03.0008), in the '

code:

Known issues from previous releases

' section:

code:

sFlow

code:

sFlow does not sample with frame rates

<

code:

1024fps.

Solution/Workaround
Functions as Designed (FAD).
This is a hardware attribute that is not expected to change.

Workaround:
If no packets are being sent to the collector for a given port, try increasing the packet throughput by transferring a large file over that port.

Note also that a similarly described issue - but generally restricted to ports handling high traffic volumes - is fixed as of firmware 6.03.04.0004:

code:

12893

code:

Resolved an issue with sFlow whereby the actual packet sampling rate did not match the user configured value.

With the fix, system behavior is now consistently as described in this document.

For further sFlow background, please refer to the Configuration Guide for your product.
See also: 13973.