sflow discarded sample with queue depth\size

[Eran Dahan]

Hi, 

I am trying to understand if there is a way to send an sflow discarded sample packet which includes 2 additional tags:
1. queue ID (tag id 1036) - this seems to be working ok. (parsing using sflowtool)

2. queue depth\size (tag id 1040) - this seems to work only on sample flow and not on discarded sample packet. (also parsing using sflowtool)

The reason I am asking about this is because knowing the queue size when a packet is discarded due to buffer drop reason, is an important information. 

Is there a way to send this data with the discarded sample today? 

Is it planned to be supported in future implementations?

thanks,

Eran

[Peter Phaal]

Hi Eran,

The sFlow specifications allows the queue depth record (and any other relevant extended_ flow records) to be used to annotate a discarded_packet record. However, the data that is available at the point that a discard record is dependent on the hardware/software generating the notification and so the queue depth may not be available to the sFlow agent.

This is really a question for your network equipment vendor to answer. Customer feedback can be effective in driving enhancements to the sFlow agent functionality and it sounds like you have a good use case for this request.

Regards,

Peter

[Neil McKee]

After checking the sflowtool source code, it looks like it is currently only looking for a subset of the annotations that may appear (including queue id but not queue depth).  I’ll reply again when sflowtool has been updated.  Probably in two days.

------
Neil McKee
InMon Corp.

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/sflow/256656c0-da90-4514-b29e-fdb352385c12n%40googlegroups.com.

[Peter Phaal]

In the mean time, you could use the sFlow-RT browse-drops application, included in the Docker sflow/prometheus image. Just add queuedepth as a key (or max:queuedepth) as a value when defining a flow, see Defining Flows.

[Eran Dahan]

Hi Guys,

Thanks for the quick reply. Really appreciated. 

I will try to do the suggested configuration on sFlow-RT and wait for the update in the sflowtool.

Thanks a lot,

Eran

[Eran Dahan]

Hi, 

I have one more question. 

Is there any difference using option 1019 which includes both queue ID and queue length in the same header vs using 2 separate headers (1036 + 1040) which seems like providing the same info? 

Preferably I would use option 1019 (if valid) which add less bytes to the discarded sample packet. 

Thanks,

Eran 

[Peter Phaal]

You should use the combination of officially published 1036 and 1040 structures to ensure support from collectors. Separating the two elements allows the omission of 1040 to indicate that queue depth isn't known.

Structure 1019 was allocated, but never adopted. Expressing queue length in segments isn't well defined (1040 defines the length in bytes). Also 1019 doesn't specify how to indicate that the queue depth isn't known. These issues would likely have been addressed had the proposal gained traction at the time.

[Neil McKee]

sflowtool updated to v6.04,  now allows any flow-sample element to appear in a discard-sample (as per the standard).

https://github.com/sflow/sflowtool/releases/tag/v6.04

To build from sources:

git clone https://github.com/sflow/sflowtool

./boot.sh

./configure

make

sudo make install

Please let me know if there is any problem with this.

------
Neil McKee
InMon Corp.

To view this discussion on the web visit https://groups.google.com/d/msgid/sflow/f31354f0-e525-43ee-a89f-0e5fd057a3ccn%40googlegroups.com.

[Eran Dahan]

Hi,

Thank you Peter for the detailed answer regarding type 1019 and thank you Neil for the update of the sflowtool.

Your responsiveness and willingness to help is really amazing and highly appreciated. 

Thanks,

Eran