[ovs-dev] [PATCH] ofproto-dpif-ipfix: add support for per-flow drop counters

Fri Jun 30 09:00:10 UTC 2017

Hi Ben,

Let me provide more details.
I configured per-bridge IPFIX sampling with following command:

$ ovs-vsctl -- set Bridge br1 ipfix=@i -- --id=@i create IPFIX 'targets="127.0.0.1:4739"' \
	obs_domain_id=123 obs_point_id=1 cache_active_timeout=10 \
	cache_max_flows=13 other_config:enable-tunnel-sampling=false sampling=1

When I generate traffic and dump flows I get this output:

$ ovs-appctl dpif/dump-flows br1

recirc_id(0),in_port(7),eth(src=00:00:00:00:00:01,dst=ff:ff:ff:ff:ff:ff),eth_type(0x0800),
ipv4(frag=no), packets:3, bytes:102, used:3.128s,
actions:userspace(pid=4292743264,ipfix(output_port=4294967295)),userspace(pid=4292743264,
		      ipfix(output_port=2)),2,userspace(pid=4292743264,ipfix(output_port=5)),5

As you can see, "userspace" action is present, rather than "sample" action.
I also tried configuring per-flow IPFIX sampling and adding clone action:

$ ovs-vsctl -- --id=@br1 get Bridge br1 -- --id=@cs create Flow_Sample_Collector_Set id=1 \
	bridge=@br1 ipfix=@i -- --id=@i create IPFIX 'targets="127.0.0.1:4739"' \
	obs_domain_id=124 obs_point_id=456

$ ovs-ofctl add-flow br1 'table=0,priority=12, \
	actions=sample(probability=65535,collector_set_id=1,obs_domain_id=124, \
			 obs_point_id=456),resubmit(,1)'
$ ovs-ofctl add-flow br1 'table=1,priority=10,actions=clone(output:2,output:3)'

In this case I also couldn't see "sample" or "clone" action, even though traffic was hitting rules added by me.

$ ovs-ofctl dump-flows br1
 cookie=0x0, duration=7.375s, table=0, n_packets=0, n_bytes=0, priority=0 actions=NORMAL
 cookie=0x0, duration=7.113s, table=0, n_packets=3, n_bytes=102, priority=12
	actions=sample(probability=65535,collector_set_id=1,obs_domain_id=124,obs_point_id=456, resubmit(,1)
 cookie=0x0, duration=7.103s, table=1, n_packets=3, n_bytes=102, priority=10 actions=clone(output:2,output:3)

$ ovs-appctl dpif/dump-flows br1
  recirc_id(0),in_port(7),eth_type(0x0800),ipv4(frag=no),packets:2,bytes:68,used:5.976s,
  actions:userspace(pid=4292741676,flow_sample(probability=65535,collector_set_id=1,
  obs_domain_id=124,obs_point_id=456,output_port=4294967295))

Any ideas how to trigger a "sample" or "clone" action during IPFIX upcall?
I suppose I could somehow force OvS to add those actions with ovs-appctl commands.
However, I'm looking for a usual use case where those actions would be present.
Are you absolutely sure that those actions need to be handled?

Thanks,
Przemek

> -----Original Message-----
> From: Szczerbik, PrzemyslawX
> Sent: Thursday, June 22, 2017 9:20 AM
> To: 'Ben Pfaff' <blp at ovn.org>
> Cc: 'dev at openvswitch.org' <dev at openvswitch.org>
> Subject: RE: [ovs-dev] [PATCH] ofproto-dpif-ipfix: add support for per-flow drop
> counters
> 
> Hi Ben,
> 
> I'm having issues with configuring flows to see "sample" or "clone" actions during
> IPFIX upcall.
> Most of the time I only see "userspace" and "output" actions, which surprises me
> quite a bit.
> Even when I configure per-bridge IPFIX sampling there is no "sample" action.
> 
> I'd appreciate any suggestions how to configure flows to see those actions during
> IPFIX upcall.
> 
> Regards,
> Przemek
> 
> > -----Original Message-----
> > From: Szczerbik, PrzemyslawX
> > Sent: Tuesday, June 20, 2017 8:46 AM
> > To: Ben Pfaff <blp at ovn.org>
> > Cc: dev at openvswitch.org
> > Subject: RE: [ovs-dev] [PATCH] ofproto-dpif-ipfix: add support for per-flow
> drop
> > counters
> >
> > Hi Ben,
> >
> > Thanks for your feedback. I can start working on implementing your
> suggestions.
> >
> > Please keep in mind that IPFIX counters are based on probability, which means
> > they won't necessarily reflect precise values.
> > As you can see it's difficult to determine, with 100% accuracy, at sampling stage
> > whether packet is going to be dropped at some point.
> > I suppose there always is a possibility that next action might drop the packet
> and
> > it we won't detect it.
> >
> > I think that this patch (with addition of your requested changes) covers majority
> > of cases which is good enough for IPFIX protocol.
> >
> > Regards,
> > Przemek
> >
> > > -----Original Message-----
> > > From: Ben Pfaff [mailto:blp at ovn.org]
> > > Sent: Wednesday, June 14, 2017 10:23 PM
> > > To: Szczerbik, PrzemyslawX <przemyslawx.szczerbik at intel.com>
> > > Cc: dev at openvswitch.org
> > > Subject: Re: [ovs-dev] [PATCH] ofproto-dpif-ipfix: add support for per-flow
> > drop
> > > counters
> > >
> > > On Tue, Jun 13, 2017 at 02:25:15PM +0100, Przemyslaw Szczerbik wrote:
> > > > Patch based on RFC 5102, section 5.10. It implements per-flow drop
> counters:
> > > > - droppedPacketDeltaCount
> > > > - droppedPacketTotalCount
> > > > - droppedOctetDeltaCount
> > > > - droppedOctetTotalCount
> > > >
> > > > In order to determine if packet is going to be dropped, flow actions
> associated
> > > > with packet are read. If there is no OVS_ACTION_ATTR_OUTPUT action,
> > packet
> > > will
> > > > be dropped.
> > > >
> > > > Signed-off-by: Przemyslaw Szczerbik <przemyslawx.szczerbik at intel.com>
> > >
> > > Thanks for working on making the IPFIX support more complete.
> > >
> > > The code in this patch that detects whether an output action is present
> > > is incomplete, for a couple of reasons.  First, it skips over "clone"
> > > and "sample" actions that might contain output actions.  An output
> > > action inside "clone" is truly an output.  An output action inside
> > > "sample" is truly an output if the sampling probability is 100% (and the
> > > datapath sometimes uses such a probability for technical reasons).
> > > Whether an output action inside "sample" with a lower probability should
> > > be considered an output is more questionable, but I don't think OVS ever
> > > actually does that.
> > >
> > > The "userspace" and "recirc" actions raise bigger questions.  Either of
> > > these can yield absolutely any kind of behavior, since userspace or the
> > > recirculated flow table lookup's actions can do anything.  There's not
> > > an easy way to decide whether a flow that executes one of these actions
> > > truly drops anything.  Without taking a different approach, when one of
> > > these actions is seen (and there isn't another clear output), the most
> > > one can say is that the flow "might" drop the packet.
> > >
> > > I am not sure the best way forward.
> > >
> > > Thanks,
> > >
> > > Ben.
--------------------------------------------------------------
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263

This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.