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

  • 0
  • 1
  • Article
  • Updated 4 years ago
  • (Edited)
Article ID: 12908 

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

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

Here is a sample configuration:

set sflow receiver 1 owner myCollector timeout 4294637449
set sflow receiver 1 ip
set sflow port ge.1.1-24 sampler 1
set sflow port ge.1.1 sampler rate 1024
set sflow port ge.1.2 sampler rate 1024
set sflow port ge.1.3 sampler rate 1024
  . . .
set sflow port ge.1.24 sampler rate 1024
set sflow port ge.1.1-24 poller 1
set sflow port ge.1.1 poller interval 60
set sflow port ge.1.2 poller interval 60
set sflow port ge.1.3 poller interval 60
 . . .
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 ip, owner, and 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 "Incorrect input! Invalid Receiver index value." error.
Note2: The 'set sflow port  <port#>  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 'show sflow sampler|poller' commands.

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.

As stated in the Configuration Guide regarding the 'sampler rate  <rate>' parameter of the 'set sflow port...' command:
Specifies the statistical sampling rate for sampling from this data source. The value of  rate  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.
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 "In Unicast Pkts", "In Multicast Pkts", and "In Broadcast Pkts" appearing in the output of a '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, in the 'Known issues from previous releases' section:
sFlow does not sample with frame rates  <  1024fps.

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

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
12893   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.
Photo of FAQ User

FAQ User, Official Rep

  • 13,620 Points 10k badge 2x thumb

Posted 4 years ago

  • 0
  • 1

There are no replies.

This conversation is no longer open for comments or replies.