Posted on August 29, 2019 3:30 am
 |  Asked by plundgren
 |  74 views
0
0
Print Friendly, PDF & Email

We would like to use as high sampling frequency as possible, i.e. going below the dangerous sampling rate limit of 16384. If the switch fails to sample a packet the sFlow protocol contains a counter for that, named drops. See struct flow_sample in https://sflow.org/sflow_version_5.txt

Does the sflow agent detect drops?

1
Posted by Prithvish Nembhani
Answered on August 29, 2019 7:04 am

Hi Plundgren,

Considering you are running sflow and not sflow hardware acceleration, if you sample at higher rates i.e. go below the default sampling rate limit 16384, there are chances based on the rate, the traffic is rate limited by Control plane policing. Since we know that for sflow (and not sflow hardware acceleration) the packets are punted to the CPU for further processing. So such cases you might see drops on the “cpu counters queue”.

In 7280E/R & 7500E/R platform switches, under the CPU counters queue we will see drops incrementing under the CoppSystemSflow.

switch#show cpu counters queue | nz
Jericho0.0:
CoPP Class Queue Pkts Octets DropPkts DropOctets
Aggregate
----------------------------------------------------------------------------------------------------------------
...
CoppSystemSflow Port0 14084435 901463600 7083182 453329567

For 7050,7250,7260,7060 and 7300 platforms, under the CPU counters queue will see drop incrementing under the sflow.

switch(config)#show cpu counters queue | nz

--------------------------------------------------------------------------------
Linecard0/0
--------------------------------------------------------------------------------
Queue Counter/pkts* Drops/pkts
--------------- ------------------- -------------------
Sflow 1760341 8917545

In the case of 7160 platforms, you will see drops under Q28 under cpu counters. In 7160, Q28 maps to XP_SFLOW_RC_SAMPLE.

switch#show platform xp mapping reason-code
Reason Code Reason Code Name CPU Queue Qos Class
----------------- ------------------------------------------------ --------------- --------------------
412 XP_SFLOW_RC_SAMPLE Q28 system-mirroring

switch#show cpu counters queue
DevId Queue Fwd pkts Fwd bytes Drop pkts Drop bytes
----- ----- ---------- -------------------- ---------- --------------------
...
0 Q28 153409530 12886449119 0 0

To add further, there is specifically no explicit counter for sflow in 7150 platform but we can figure out if there are drops possibly could be due to sflow if the following counters increment.

switch(config)#show platform fm6000 counters | nz | grep -i drop
Cpu0 transmitted frames dropped for congestion management 1177957699
...
Ethernet2 frames dropped due to tx mem part. usage above hog wm 836555644

Just to be more clear the discard counters under show sflow detail do not state discards due to high sampling rate but state discards if the packets forwarded by the hardware to the sflow agent is malformed.

switch#show sflow detail
...
Statistics
----------
Total Packets: 1453700379
Number of Samples: 975952749
Sample Pool: 975952749
Hardware Trigger: 978534816
Number of Datagrams: 108448972
Number of Samples Discarded: 0

If you are running sflow hardware acceleration it would be best to refer the following document.
https://eos.arista.com/eos-4-20-5f/hardware-accelerated- sflow/

As per the document, under sflow hardware counters, Receive Packet Drop Count states the number of packet samples arrived to the accelerator but could not be processed; this can indicate a too aggressive sampling rate.

Arista#show sflow hardware counters in case of
——————
SflowAccelFpga7:0
——————
Incoming Packet Count : 0
Outgoing Sflow Datagram Count : 0
Outgoing Flow Sample Count : 0
Incoming Processed Packet Count : 0
Receive Packet Drop Count : 0
Packet Truncated Count : 0
Incoming Packet Error Count : 0
Outgoing Processed Datagram Count : 0
Sample Pool : 0

Hope this helps!

Let me know if there are any further queries.

Thanks,
Prithvish

Post your Answer

You must be logged in to post an answer.