[ovs-discuss] sFlow

[Neil Mckee]

The sFlow SNMP MIB,  while very useful,  is optional.  It can be  
ignored for now.

The only counter-block you really need is the "generic" one,  which  
exports the basic MIB-II ifTable counters as a single snapshot.  I can  
see that this might be awkward because these counters must be updated  
with every packet,  in the fast-path.   Still,  you'll probably be  
expected to provide them eventually one way or another.

The simplest sampling implementation is usually to have just one  
packet-sampler for the whole switch,  and the critical path there is  
just to decrement the countdown to the next sample,  so that part is  
not going to slow you down at all.  I guess it's just a question of  
figuring out the best way to queue the samples for processing in user- 
space.

There are patents involved,  yes,  but the main sFlow license should  
not be an obstacle (http://www.sflow.org/developers/licensing.php).    
The license you were looking at was specific to the virtual probe  
implementation.    I'll check what we need to do to,  but it looks  
like it's probably enough for me to say in writing that you are  
welcome to use that code as long as you conform to the main sFlow  
license.  You'll probably rewrite the code anyway :).  Our main goal  
in putting it out there was just to say "wow, look how easy this is".

regards,
Neil


On Aug 28, 2009, at 6:23 PM, Justin Pettit wrote:

> Hi, Neil.  Thanks for the information!  We'd like to add native  
> support, but there are a few things that would need to be done:
>
> 	- sFlow uses SNMP to communicate between the collector and agents,  
> and we do not yet have support for SNMP.
>
> 	- For packet sampling, we'd need to make some modifications to the  
> protocol used to communicate with the datapath (in addition to  
> changes in the kernel and userspace).
>
> 	- For counter sampling, we'd need to keep track of a lot more  
> information than we currently do.
>
> Luckily, none of these technical issues are hard.  Our biggest  
> concern has been related to licensing and patents, since this is an  
> open source project.  Does InMon claim any patents or licensing  
> restrictions over projects that implement RFC 3176?
>
> The Virtual Switch Probe looks like a neat program and should work  
> with the current version of Open vSwitch.  However, clause 1(b) in  
> the license agreement that prevents using it for any commercial  
> purposes seems a bit worrying.
>
> --Justin
>
>
> On Aug 28, 2009, at 5:17 PM, Neil McKee wrote:
>
>> Hello all,
>>
>> I saw you had sFlow on your list of features that are "under  
>> development",  so I thought I would offer to help if I can.   If  
>> you're just getting started, the source code linked from this page  
>> might help:
>>
>> http://inmon.com/products/virtual-probe/index.php
>>
>> (It the C source code to an sFlow agent designed to connect to a  
>> virtual SPAN port using libpcap).
>>
>> If you already have something running,  then I'd be happy to help  
>> with the testing.
>>
>> Neil McKee
>> InMon Corp.
>>
>>
>> _______________________________________________
>> discuss mailing list
>> discuss at openvswitch.org
>> http://openvswitch.org/mailman/listinfo/discuss_openvswitch.org