There are some common pitfalls to avoid even in the low-level
sampling, so feel free to ping me if you have any doubts.
(For example, if you are queueing the samples for processing later
then make sure you use a low priority queue: separate from the queue
you use for critical events like spanning tree updates. Include a
snapshot of the relevant "samplePool" counter with each sample if you
can, and bear in mind that you need to know what happened to that
sampled packet in order to fill in all the fields (e.g. output port/
vlan, or dropped by ACL). That may affect where you choose to sample.
The only configuration options that make sense are ingress-sampling on
all ports, egress-sampling on all ports, or bidirectional-sampling on
some or all ports.)
Neil Mckee
www.inmon.com
On Sep 4, 2009, at 6:28 PM, Justin Pettit <jpet...@nicira.com> wrote:
Terrific! Thank you very much. This will make it much easier to
add sFlow to the project. When we have an implementation working,
we'll definitely take you up on your offer to help us test it.
By the way, I've already updated the bullet point on our project
page to say "sFlow(R)" to keep up our end of the license. ;-)
Thanks again!
--Justin
On Sep 4, 2009, at 4:02 PM, Neil McKee wrote:
Justin,
Please accept this email as written confirmation that you may use
and adapt the source code for the InMon Virtual Probe (http://inmon.com/products/virtual-probe/index.php
) for the implementation of an sFlow agent in the "Open vSwitch"
project (http://openvswitch.org/) under the terms of the sFlow
License (http://www.sflow.org/developers/licensing.php).
Neil McKee
Director
InMon Corp.
On Aug 28, 2009, at 10:38 PM, Neil Mckee wrote:
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@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss_openvswitch.org
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss_openvswitch.org
