([CHECK_SFLOW_SAMPLING_PACKET],
dnl sleep long enough to get more than one counter sample
dnl from each datasource so we can check sequence numbers
- ovs-appctl time/warp 3000 100
+ ovs-appctl time/warp 2000 100
OVS_VSWITCHD_STOP
OVS_APP_EXIT_AND_WAIT([test-sflow])
--
Neil McKee
InMon Corp
This one perturbs the output ordering just enough to fail two of the
sflow unit tests. Sorry I didn't notice that before. I'll post
another patch for that.
Neil
--
Neil McKee
InMon Corp.
http://www.inmon.com
On Fri, Sep 2, 2016 at 11:47 AM, Ben Pfaff wrote:
> On Mon, Aug 2
0%. For a thorough analysis
of this problem, see Rick Jones' paper:
"High Frequency sFlow v5 Counter Sampling"
ftp://ftp.netperf.org/papers/high_freq_sflow/hf_sflow_counters.pdf
So this patch makes it possible to obtain usable results even
when high-frequency polling is configured.
This patch avoids a segfault that was found and documented here:
http://openvswitch.org/pipermail/discuss/2016-August/022513.html
I raised a pull-request on github.
Signed-off-by: Neil McKee
---
ofproto/ofproto-dpif-sflow.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
Robert,
Two comments:
(1) To add an sFlow extension like this you tag it with an
IANA-assigned enterprise number from:
https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers
The enterprise number goes in the high 20 bits, as described on page
25 of http://sflow.org/sflow_versio
/host-sflow/blob/master/src/Linux/hsflowd.c#L373
--
Neil McKee
InMon Corp.
http://www.inmon.com
On Thu, Jun 16, 2016 at 4:16 AM, Lal, PrzemyslawX wrote:
> Hi Mark,
>
> RFC 2863 standard describes in "Interface Numbering" chapter (
> https://tools.ietf.org/html/rf
ulated traffic.
So this way you get the full picture. It's just that your sFlow collector
sometimes has to decode deeper into the packet to pull out the inner
addresses etc.
I hope this is clear.
Neil
--
Neil McKee
InMon Corp.
http://www.inmon.com
On Fri, Nov 6, 2015 at 5:40 A
Wow. That's great. Thanks. I will look at what else we should add to the
sFlow export. (e.g. QinQ, NAT, ...). Should be straighforward now that we
have the actions for each sample.
Neil
On Tuesday, July 21, 2015, Ben Pfaff wrote:
> On Fri, Jul 17, 2015 at 09:37:02PM -0700, Ne
in future patches that make only incremental
changes.
Signed-off-by: Neil McKee
---
lib/dpif-netlink.c| 2 +
lib/dpif.h| 1 +
lib/odp-util.c| 25 +-
lib/odp-util.h| 1 +
ofproto/ofproto-dpif-sflo
Sure, I'll try to get to that tonight.
Neil
--
Neil McKee
InMon Corp.
http://www.inmon.com
On Fri, Jul 17, 2015 at 4:31 PM, Ben Pfaff wrote:
> On Thu, Jun 11, 2015 at 09:43:59AM -0700, Neil McKee wrote:
> > Packets are still sampled at ingress only, so the egress
> >
pproach is accepted then I can follow up with further enhancements
to report on QinQ, NAT, 64-bit tunnel keys, and to improve the
monitoring of Geneve and STT. That should all be pretty straightforward
now. No further changes to datapath required.
Neil
--
Neil McKee
InMon
: Neil McKee
---
datapath/actions.c| 23 +++
datapath/datapath.c | 18 --
datapath/datapath.h | 2 ++
datapath/linux/compat/include/linux/openvswitch.h | 5 -
4 files
in future patches that make only incremental
changes.
Signed-off-by: Neil McKee
---
lib/dpif-netlink.c| 2 +
lib/dpif.h| 1 +
lib/odp-util.c| 25 +-
lib/odp-util.h| 1 +
ofproto/ofproto-dpif-sflo
Yes. I'll do that. They have changed slightly now that the option to
request the actions is an attribute of the "userspace" action.
Neil
--
Neil McKee
InMon Corp.
http://www.inmon.com
On Tue, May 26, 2015 at 7:17 PM, Ben Pfaff wrote:
> On Fri, May 15, 2015 at 05:53
everywhere so a missing field
can typically be seen at ingress to the next switch in the path.
This patch also adds unit tests to check the sFlow encoding of set(tunnel()),
tnl_push() and push_mpls() actions.
Signed-off-by: Neil McKee
---
lib/dpif-netlink.c| 2 +
datapath actions that may be added in the future.
Adding path information enhances visibility into complex virtual networks.
Signed-off-by: Neil McKee
---
datapath/actions.c | 14 +-
datapath/datapath.c | 18 ++
datapath/datapath.h | 2 ++
3 files changed, 29 insertions
not dependent on the kernel part.
Neil
On Fri, May 15, 2015 at 5:53 PM, Jesse Gross wrote:
> On Fri, May 15, 2015 at 3:04 PM, Neil McKee wrote:
>> I understand that the (optional) kernel datapath changes will need to
>> be submitted as a kernel
>> patch on netdev. I c
everywhere so a missing field
can typically be seen at ingress to the next switch in the path.
This patch also adds unit tests to check the sFlow encoding of set(tunnel()),
tnl_push() and push_mpls() actions.
Signed-off-by: Neil McKee
---
datapath/actions.c| 14 +-
datapath/
ing of set(tunnel()),
tnl_push() and push_mpls() actions.
Signed-off-by: Neil McKee
---
datapath/actions.c| 14 +-
datapath/datapath.c | 18 ++
datapath/datapath.h | 2 +
lib/dpif-netlink.c| 2 +
lib/dpif.h| 1 +
ofproto/of
Real-time visibility into mpls and tunneling will be very helpful for
monitoring and dynamic control,
so please review this patch. Specific questions are tagged with "XXX" comments.
I also submitted a git-hub pull-request:
https://github.com/openvswitch/ovs/pull/45
I understand that the (optional
actions at his fingertips for any packet that might be
sampled.
Thoughts?
Neil
--
Neil McKee
InMon Corp.
http://www.inmon.com
On Mon, Apr 6, 2015 at 3:23 PM, Jesse Gross wrote:
> On Sat, Apr 4, 2015 at 8:45 AM, Neil McKee wrote:
> >
> > On Fri, Apr 3, 2015 at 3:
On Fri, Apr 3, 2015 at 4:21 PM, Joe Stringer wrote:
> Missed this the first time around for some reason. Minor comments inline.
>
> On 1 April 2015 at 22:14, Neil McKee wrote:
> > 1) We can use the concurrent hash-map of flows that the revalidator
> > threads are sharing.
On Fri, Apr 3, 2015 at 3:14 PM, Jesse Gross wrote:
> On Wed, Apr 1, 2015 at 10:14 PM, Neil McKee wrote:
> > I've been looking at filling in the sFlow structures to report on tunnel
> > encap and other transformations. sFlow sampling is best done on ingress
> > only,
option (1), but it really does seem to have all
the problems that Jesse and Ben anticipated in 2011.
Neil
--
Neil McKee
InMon Corp.
http://www.inmon.com
On Wed, Apr 1, 2015 at 10:14 PM, Neil McKee wrote:
> I've been looking at filling in the sFlow structures to report
rom the
kernel? Is that worth pursuing?
5) something else?
Neil
--
Neil McKee
InMon Corp.
http://www.inmon.com
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
to see if there was a way to set a bit in
the skbuff that would survive and come back in a sample, but I'm not sure
how to go about doing that.
Or maybe there is another way?
Neil
--
Neil McKee
InMon Corp.
http://www.inmon.com
___
dev m
efficient and scalable alternative to polling via ovs-dpctl(1).
It's safe to assume that the patch below was mangled by my email setup, so
I posted a github pull-request here:
https://github.com/openvswitch/ovs/pull/31
Signed-off-by: Neil McKee
---
lib/sflow.h | 34 ++-
7;m hoping this can go in. These LACP and port-name extensions are useful
as they stand. No need to wait for the tunnel stuff to settle. Let me
know if you need me to do anything else.
Regards,
Neil
--
Neil McKee
InMon Corp.
http://www.inmon.com
On Tue, Jul 15, 2014 at 4:31 PM, Neil M
t;bundle" and it's pointer to
"lacp" are not going to be moving around underfoot.
Regards,
Neil
--
Neil McKee
InMon Corp.
http://www.inmon.com
On Wed, Jul 9, 2014 at 3:08 PM, Neil McKee wrote:
>
> OK, I'll reply again when I have extended this forked-repo
OK, I'll reply again when I have extended this forked-repo to export the
standard sFlow-LAG structure.
Neil
--
Neil McKee
InMon Corp.
http://www.inmon.com
On Mon, Jul 7, 2014 at 8:55 AM, Ben Pfaff wrote:
> I took a look at the patch. It's not necessary to submit a
&
Yes, I was thinking the same thing. I'm looking forward to trying it out.
Especially if I can submit patches via https://github.com/sflow/ovs. That
will make life easier. I have one outstanding that lays some groundwork
for the sFlow tunnel extensions. If that process goes smoothly then I'll
ards,
Neil
--
Neil McKee
InMon Corp.
http://www.inmon.com
On Mon, Jun 23, 2014 at 1:20 PM, Ben Pfaff wrote:
> On Fri, Jun 13, 2014 at 12:01:50PM -0700, Neil McKee wrote:
> > Standard LACP counters are added to the LACP module, and
> > the sFlow library and test modules ar
t the export of those LACP counters as well as
tunnel and OpenFlow related structures. None of these
structures are actually exported yet, so this patch should
have no discernible effect. Hence no changes to the unit
tests.
Signed-off-by: Neil McKee
---
lib/lacp.c
Finally getting back to this. Can we do it one piece at a time? For
example, attached is a patch that just adds counters to the LACP
module and a call to retrieve them.
Neil
--
Neil McKee
InMon Corp.
http://www.inmon.com
On Mon, Jan 13, 2014 at 8:29 AM, Neil McKee wrote:
> Thanks
Sorry for the delay. Looks good. And thanks for pointing this out.
Neil
--
Neil McKee
InMon Corp.
http://www.inmon.com
On Tue, Jan 7, 2014 at 1:28 AM, Francesco Fusco wrote:
> Neil,
> did you have a chance to have a look at the patch?
>
> Best,
> Francesco
>
>
>
Thanks for the detailed explanation. You should teach a class :)I'll
rework the patch.
Neil
--
Neil McKee
InMon Corp.
http://www.inmon.com
On Thu, Jan 9, 2014 at 11:43 AM, Ben Pfaff wrote:
> On Fri, Jan 03, 2014 at 09:39:00PM -0800, Neil McKee wrote:
> > On Mon, Dec
On Mon, Dec 30, 2013 at 4:08 PM, Ben Pfaff wrote:
> On Fri, Dec 20, 2013 at 03:45:37PM -0800, Neil McKee wrote:
> > Sorry. Grappling with a new email client. Here it as an attachment, if
> > that's OK. Let me know if I need to rebase again.
>
> This patch provokes
Lenglet"
>>>>>>> To: "Jesse Gross"
>>>>>>> Cc: dev@openvswitch.org
>>>>>>> Sent: Friday, October 18, 2013 6:46:05 PM
>>>>>>> Subject: Re: [ovs-dev] [PATCH] sFlow export: include standard tunnel
>>>>>>&g
the
feed they wanted too. All without exploding the complexity of sFlow config
in OVS.
So I guess I just don't see the upside in adding options to OVS. It only
seems to be inviting a complexity explosion. Perhaps I missed something?
Neil
> On Mon, Oct 7, 2013 at 10:45 AM, Neil Mckee
ve to worry that the
outer traffic matrix was
being polluted with tenant address-space, and manage the resulting
state-explosion on both the
configuration and the analysis side. Better to have no option.
Neil
On Oct 7, 2013, at 9:47 AM, Jesse Gross wrote:
> On Sun, Oct 6, 2013 at 10:11
Please comment on this proposed patch. It adds the standard
sFlow-TUNNEL structures to the sFlow export, which will be helpful
for tracing tunneled traffic through a network fabric in real-time.
As part of doing that, it switches over from using odp_port to ofp_port
as the port reference used
Just a comment: one of the architectural differences between IPFIX and sFlow
is the location of the flow-cache: with sFlow the cache is implemented in
external software on a central server, which can then easily export IPFIX if
required (while also providing real-time network-wide visibility
) in bridge.c:iface_refresh_status()
I should check for that? How?
(don't expect answer for at least a week)
Neil
On Jul 2, 2013, at 4:59 PM, Ben Pfaff wrote:
> Thanks Neil. I'm on vacation this week but I'll look at this when I get back
> next week.
>
> On J
OK, here's how it looks now (against latest master). I wasn't sure where to
add the NEWS item so I just guessed.
Signed-off-by: Neil McKee
---
NEWS | 2 ++
vswitchd/bridge.c | 11 +++
vswitchd/vswitch.ovsschema | 7 +--
vswitchd/v
,ifindex list Interface
{"data":[["br2",65534,10],["eth0",1,2],["br1",65534,9],["vm",2,11],["gre0",1,0]],"headings":["name","ofport","ifindex"]}
Signed-off-by: Neil McKee
---
vswitchd/bridge.
o I can
nose around?
Neil
On May 28, 2013, at 5:01 PM, Ben Pfaff wrote:
> On Tue, May 28, 2013 at 12:17:39PM -0700, Neil Mckee wrote:
>> It would be helpful if ovs-vsctl(1) had a way to write out the
>> netdev ifIndex numbers, where applicable, of the bridge ports. This
>>
On May 28, 2013, at 5:01 PM, Ben Pfaff wrote:
> On Tue, May 28, 2013 at 12:17:39PM -0700, Neil Mckee wrote:
>> It would be helpful if ovs-vsctl(1) had a way to write out the
>> netdev ifIndex numbers, where applicable, of the bridge ports. This
>> would help to harmonize
UXK6REbrkYI
Regards,
Neil
Neil McKee
InMon Corp.
http://www.inmon.com
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
> On Tue, Apr 30, 2013 at 10:38:53PM -0700, Neil Mckee wrote:
>> I learned how to squash patches...
>>
>> Change sFlow model to reflect per-bridge sampling. Before we were
>> presenting a separate
>> sFlow data-source (sampler) for each ifIndex-interface, and
el. Note that interface-counter-polling is still handled the same
way as before,
with sFlow counter-polling data only being exported for ifIndex-interfaces.
Signed-off-by: Neil McKee
---
lib/sflow.h | 7
ofproto/ofproto-dpif-sf
Update comments to reflect per-bridge sFlow sampling.
---
ofproto/ofproto-dpif.c | 6 +-
ofproto/tunnel.c | 1 -
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c
index 3ae3532..4306d40 100644
--- a/ofproto/ofproto-dpif.c
+++
git seemed to want to make this a series of 2 patches, and I don't know how to
argue with git. Hope that's OK.
Neil
Change sFlow packet sampling to better reflect the
per-bridge sampling that is really happening, rather than modeling it as
per-interface sampling. This fixes an aliasing pro
tions might not populate
every sFlow field.
Revised patch to follow.
Neil
On Apr 29, 2013, at 3:35 PM, Jesse Gross wrote:
> On Mon, Apr 29, 2013 at 2:53 PM, Neil Mckee wrote:
>> but I'm not sure I understand the one in tunnel.c. I assume you mean this
>> comment:
>>
hat right?
Neil
On Apr 29, 2013, at 11:39 AM, Jesse Gross wrote:
> OK, that sounds reasonable to me. Can you update the comments to
> reflect that sFlow should be OK now - assuming that you think it is. I
> see two: ofproto/ofproto-dpif.c:port_construct() and the one in
> ofproto
any information. Is there any
> disadvantage?
>
> On Wed, Apr 24, 2013 at 2:04 PM, Neil Mckee wrote:
>> Actually it wasn't just tunnel ports. Anything that didn't have an ifIndex
>> was mapping to the same sFlow datasource. Even if it was on another bridge.
&
el traffic sampled on different
>> bridges was all being reported against the same sFlow datasource.
>>
>> The sFlow counter samples remain unchanged, reporting only on interfaces
>> that have valid ifIndex numbers.
>>
>> See definition of SFlowDataSource i
sFlow counter samples remain unchanged, reporting only on interfaces
that have valid ifIndex numbers.
See definition of SFlowDataSource in http://sflow.org/sflow_version_5.txt.
Signed-off-by: Neil McKee
---
lib/sflow.h | 7
ofproto/ofproto-dpif-sflow.c | 76
Yes, that makes sense. Thanks.
Neil
On Apr 3, 2013, at 6:47 PM, Ben Pfaff wrote:
> On Wed, Apr 03, 2013 at 05:01:40PM -0700, Neil Mckee wrote:
>> "parse-listening-port" seems to return the port that the server was
>> told to listen on(?)
>
> Yes, it retu
a note to the commit message to mention that it fixes that
> problem too.
>
> On Wed, Apr 03, 2013 at 01:56:03PM -0700, Neil Mckee wrote:
>> You probably noticed this, but choose-port.pl is sometimes being used
>> to return a free TCP port which is promptly used for UD
You probably noticed this, but choose-port.pl is sometimes being used to
return a free TCP port which is promptly used for UDP. Perhaps
choose-port.pl should take an argument?
Neil
On Apr 3, 2013, at 12:02 PM, Ben Pfaff wrote:
> An occasionally occurring problem with "make check", espec
ecific language governing permissions and
* limitations under the License.
*/
You don't need me sign off again, right? You can submit the revised patch
yourself?
Neil
On Mar 31, 2013, at 9:48 PM, Neil McKee wrote:
> That answers all my questions. I was indeed in the 1.10 branch.
>
&g
ere's an early response.
>
> On Fri, Mar 29, 2013 at 08:39:42PM -0700, Neil Mckee wrote:
>>
>> On Mar 29, 2013, at 4:16 PM, Ben Pfaff wrote:
>>
>>> On Wed, Mar 27, 2013 at 11:02:21PM -0700, Neil Mckee wrote:
>>>> This patch adds an sFlow test to
On Mar 29, 2013, at 4:16 PM, Ben Pfaff wrote:
> On Wed, Mar 27, 2013 at 11:02:21PM -0700, Neil Mckee wrote:
>> This patch adds an sFlow test to the test suite (in branch 1.10). To make
>> that work properly I added netdev_dummy_get_ifindex() so that a dummy netdev
>&g
guess this behavior
could be off by default and turned on just for this test.
I have only tested this on a Fedora 17 OS.
Signed-off-by: Neil McKee
---
lib/netdev-dummy.c| 15 +-
tests/automake.mk | 4 +
tests/ofproto-dpif.at | 54 +
tests/test-sflow.c| 539
per second.
Regards,
Neil
Neil McKee
InMon Corp.
http://www.inmon.com
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
The sFlow standard will soon include an option to report LACP state along with
the periodic counter-push. It would be great for the Open vSwitch to include
this. It is important when aggregating sFlow data to estimate totals, so
it's fundamental information to know accurately right up to th
not.
Neil
--
Signed-off-by: Neil McKee
---
COPYING |6 --
lib/sflow.h |8 ++--
lib/sflow_agent.c|8 ++--
lib/sflow_api.h |8 ++--
lib/sflow_poller.c |8 ++--
lib/sflow_receiver.c |8 ++--
lib/sflow_sampler.c
On Dec 6, 2011, at 2:18 PM, Luca Giraudo wrote:
> Hi Neil,
> replies in-line.
>
> On Tue, Dec 6, 2011 at 1:43 PM, Neil Mckee wrote:
> Hi Luca,
>
> Just checking does this mean that the sFlow-agent-address might change
> just because the first collector in the l
Hi Luca,
Just checking does this mean that the sFlow-agent-address might change
just because the first collector in the list changed? Or because there was a
routing change and the packet path to the collector went out a different
interface?
The primary purpose of the sflow-agent-address
On Sep 22, 2011, at 4:07 PM, Pravin Shelar wrote:
> On Thu, Sep 22, 2011 at 1:56 PM, Ben Pfaff wrote:
>> On Wed, Sep 21, 2011 at 03:21:46PM -0700, Pravin Shelar wrote:
>>> v3: Fixed according to comments from Ben
>>> - Probability calculation
>>> - Coding style fixes
>>> - Now SAM
On Aug 18, 2011, at 6:55 PM, Jesse Gross wrote:
> * Atomic operations are quite slow, which means that enabling sFlow results
> in a major performance hit.
I was alarmed to read this. What is the hit? (I trust your test had the
sampling-probability set so that it only take a handful of sampl
On Aug 18, 2011, at 6:55 PM, Jesse Gross wrote:
> On Aug 19, 2011 6:41 AM, "Neil McKee" wrote:
> >
> >
> > On Aug 18, 2011, at 4:15 AM, Jesse Gross wrote:
> >
> >> On Aug 18, 2011 12:21 AM, "Ben Pfaff" wrote:
> >> >
> &g
On Aug 18, 2011, at 4:21 AM, Jesse Gross wrote:
> On Aug 18, 2011 2:51 AM, "Pravin Shelar" wrote:
> >
> > On Tue, Aug 16, 2011 at 11:17 PM, Jesse Gross wrote:
> > > On Mon, Aug 15, 2011 at 8:34 PM, pravin shelar wrote:
> > >> This patch makes sampling support more generic/simple by adding
>
On Aug 18, 2011, at 4:15 AM, Jesse Gross wrote:
> On Aug 18, 2011 12:21 AM, "Ben Pfaff" wrote:
> >
> > [bringing Neil McKee into the conversation since he knows more about
> > this than me]
> >
> > On Wed, Aug 17, 2011 at 02:17:03PM +0800, Jesse Gr
On Aug 17, 2011, at 2:30 PM, Ben Pfaff wrote:
> On Wed, Aug 17, 2011 at 02:18:52PM -0700, Neil McKee wrote:
>>
>> On Aug 17, 2011, at 12:25 PM, Ben Pfaff wrote:
>>
>>> On Wed, Aug 17, 2011 at 11:51:05AM -0700, Pravin Shelar wrote:
>>>> On Tue, Au
On Aug 17, 2011, at 12:25 PM, Ben Pfaff wrote:
> On Wed, Aug 17, 2011 at 11:51:05AM -0700, Pravin Shelar wrote:
>> On Tue, Aug 16, 2011 at 11:17 PM, Jesse Gross wrote:
>>> The use of the checksum for actions surprised me a little bit, as it
>>> is semantically equivalent to what we have today bu
pace, in which packets
> can still arrive and be processed according to the flow's previous set
> of actions. The same construct as #3 above is one possible solution.
>
> On Thu, Aug 11, 2011 at 11:09:36AM -0700, Neil McKee wrote:
>> I think the current behavior where the w
I think the current behavior where the whole actions-list is serialized and
passed up with the sample is actually really elegant and future-proof. New
actions are being added all the time, and having access to a sampled-stream of
"exactly-what-is-happening-in-there" is always going to be good
78 matches
Mail list logo
