Thanks I will give it a go. I was hoping to collect all traffic which has a corresponding rule in the ofctl table but your comment on "not all packets appearing in the datapath" has cast doubts over that.
CISCO Netflow samples the traffic, which is not good enough for me but I'll try the OVS netflow to see whether all traffic can be captured or not. Cheers On 5 December 2013 22:29, Ben Pfaff <b...@nicira.com> wrote: > Have you considered using NetFlow? > > There's no description of what goes into the kernel flow table because > that is an implementation detail subject to change. It's not an API of > any kind, certainly not a stable one. > > On Thu, Dec 05, 2013 at 10:17:43AM +0500, Asadullah Hussain wrote: > > Thanks, can you guide me to a resource that elaborates on which packets > > appear as flows in datapath and which don't. I am interested in only > those > > flows (TCP & UDP only) which have a corresponding rule in the ovs flow > > table (otherwise I can simply sniff br0 using tcpdump/wireshark etc). > > > > I don't want to catch all flows like ARP requests, broadcast messages > etc. > > > > > > > > On 5 December 2013 09:56, Ben Pfaff <b...@nicira.com> wrote: > > > > > Why not just check for changes more often, even if it takes a while to > > > process them? > > > > > > It's futile trying to catch all traffic this way anyhow, since not all > > > packets that get processed appear in flows in the datapath. > > > > > > I don't think it's worth making a change for this purpose. > > > > > > On Thu, Dec 05, 2013 at 09:35:49AM +0500, Asadullah Hussain wrote: > > > > Because it's a periodic process and if I am not able to process > previous > > > > flows within five seconds, the current flows are lost. > > > > > > > > > > > > On 4 December 2013 20:51, Ben Pfaff <b...@nicira.com> wrote: > > > > > > > > > Why does it matter whether the flows have disappeared while you are > > > > > processing them? > > > > > > > > > > On Wed, Dec 04, 2013 at 03:07:35PM +0500, Asadullah Hussain wrote: > > > > > > Thanks for the reply. I want to further process the flows > returned > > > from > > > > > the > > > > > > "ovs-dpctl dump-flows" command (performing string operations, > make > > > > > lookups > > > > > > in geolocation databases etc) and this processing time takes > longer > > > than > > > > > 5 > > > > > > seconds, due to which flow loss is occurring. > > > > > > > > > > > > > > > > > > On 3 December 2013 21:19, Ben Pfaff <b...@nicira.com> wrote: > > > > > > > > > > > > > On Tue, Dec 03, 2013 at 04:33:24PM +0500, Asadullah Hussain > wrote: > > > > > > > > Is there a way to change the timeout of kernel flow table > > > (ovs-dpctl > > > > > > > > dump-flows)? > > > > > > > > > > > > > > No. > > > > > > > > > > > > > > > The default timeout is 5 seconds which means that all flows > in > > > the > > > > > kernel > > > > > > > > flow table are flushed out after 5 seconds. > > > > > > > > > > > > > > > > I want to increase this time to 1 minute. > > > > > > > > > > > > > > Why? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Asadullah Hussain > > > > > > > > > > > > > > > > > > > > > -- > > > > Asadullah Hussain > > > > > > > > > > > -- > > Asadullah Hussain > -- Asadullah Hussain
_______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
