Re: [ovs-discuss] Can we configure Sflow only for certain traffic?
The sFlow mechanism is OVS is inherently ingress-only sampling, so
per-port config would rarely make sense as it would result in only
half the picture for a given VM or link. The sFlow philosophy is to
keep the agent as simple as possible and generate a standard feed that
can be used by more than one application. So if a particular
application requires a special filter to be applied, then that should
be done at the collector.
(It's not hard to receive an sFlow feed and forward a subset of it on.
Deploying a "first-receiver" sFlow collector to provide this
filtering-and-forwarding step has been done before. The filter may be
on ports, CIDRs, MAC addresses, protocols... It wouldn't make sense
to push all those features into the switch.)
--
Neil McKee
InMon Corp.
http://www.inmon.com
--
Neil McKee
InMon Corp.
http://www.inmon.com
On Mon, Mar 25, 2019 at 1:39 AM 王志克 wrote:
>
> Hi,
>
>
>
> Per below OVS document, we can configure per bridge sflow.
>
> http://docs.openvswitch.org/en/latest/howto/sflow/
>
>
>
> $ ovs-vsctl -- --id=@sflow create sflow agent=${AGENT_IP} \
>
> target="\"${COLLECTOR_IP}:${COLLECTOR_PORT}\"" header=${HEADER_BYTES} \
>
> sampling=${SAMPLING_N} polling=${POLLING_SECS} \
>
> -- set bridge br0 sflow=@sflow
>
>
>
> My question is:
>
> Whether we can configure sflow per in_port or egress port? Basically we may
> only have interest for certain traffic.
>
>
>
> Br,
>
>
>
> Zhike
>
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] sFlow agent error: sfl_agent_error: receiver: flow sample too big for datagram
To include the whole packet in every sampled header you could try changing SFL_MAX_DATAGRAM_SIZE in lib/sflow.h to something like 2000 and then recompile (or maybe 1 if you want to sample whole jumbo frames too), but with the settings you show you will get random 1-in-500 packet-samples. Setting the sampling rate to 1:1 will not perform well at all. It's not what sFlow is designed for. If you really want *all traffic* then you might be better off using a replication openflow rule. Maybe something along these lines: https://blog.sflow.com/2013/11/udp-packet-replication-using-open.html -- Neil McKee InMon Corp. -- Neil McKee InMon Corp. On Mon, Dec 9, 2019 at 10:35 AM Oliver Dzombic wrote: > > Hi Folks, > > when we have high rates of packets per second sflow will not export this > traffic to the collector. > > Inside of ovs-vswitchd.log we can see tons of entries like: > > 2019-12-09T18:15:04.739Z|30436|sflow(handler17)|WARN|sFlow agent error: > sfl_agent_error: receiver: flow sample too big for datagram > > > Our configuration: > > > ovs-vsctl -- --id=@sflow create sflow agent=127.0.0.1 > target="\"127.0.0.1:6343\"" header=1518 sampling=500 polling=1 -- set > bridge ovsbridge sflow=@sflow > > > How can we improve this ? We would like to receive all traffic at the > collector, no matter how many packets or what packetsize will come in. > > Any help / hint / idea is greatly appriciated. > > Thank you ! > > > -- > Mit freundlichen Gruessen / Best regards > > Oliver Dzombic > Layer7 Networks > > mailto:i...@layer7.net > > Anschrift: > > Layer7 Networks GmbH > Zum Sonnenberg 1-3 > 63571 Gelnhausen > > HRB 96293 beim Amtsgericht Hanau > Geschäftsführung: Oliver Dzombic > UST ID: DE259845632 > ___ > discuss mailing list > disc...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] sFlow agent error: sfl_agent_error: receiver: flow sample too big for datagram
Or ERSPAN, which is also supported by OVS. -- Neil McKee InMon Corp. On Mon, Dec 9, 2019 at 10:47 AM Neil McKee wrote: > > To include the whole packet in every sampled header you could try > changing SFL_MAX_DATAGRAM_SIZE in lib/sflow.h to something like 2000 > and then recompile (or maybe 1 if you want to sample whole jumbo > frames too), but with the settings you show you will get random > 1-in-500 packet-samples. Setting the sampling rate to 1:1 will not > perform well at all. It's not what sFlow is designed for. If you > really want *all traffic* then you might be better off using a > replication openflow rule. Maybe something along these lines: > https://blog.sflow.com/2013/11/udp-packet-replication-using-open.html > > -- > Neil McKee > InMon Corp. > > -- > Neil McKee > InMon Corp. > > > > On Mon, Dec 9, 2019 at 10:35 AM Oliver Dzombic wrote: > > > > Hi Folks, > > > > when we have high rates of packets per second sflow will not export this > > traffic to the collector. > > > > Inside of ovs-vswitchd.log we can see tons of entries like: > > > > 2019-12-09T18:15:04.739Z|30436|sflow(handler17)|WARN|sFlow agent error: > > sfl_agent_error: receiver: flow sample too big for datagram > > > > > > Our configuration: > > > > > > ovs-vsctl -- --id=@sflow create sflow agent=127.0.0.1 > > target="\"127.0.0.1:6343\"" header=1518 sampling=500 polling=1 -- set > > bridge ovsbridge sflow=@sflow > > > > > > How can we improve this ? We would like to receive all traffic at the > > collector, no matter how many packets or what packetsize will come in. > > > > Any help / hint / idea is greatly appriciated. > > > > Thank you ! > > > > > > -- > > Mit freundlichen Gruessen / Best regards > > > > Oliver Dzombic > > Layer7 Networks > > > > mailto:i...@layer7.net > > > > Anschrift: > > > > Layer7 Networks GmbH > > Zum Sonnenberg 1-3 > > 63571 Gelnhausen > > > > HRB 96293 beim Amtsgericht Hanau > > Geschäftsführung: Oliver Dzombic > > UST ID: DE259845632 > > ___ > > discuss mailing list > > disc...@openvswitch.org > > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Sflow maths and accuracy
Hello Oliver,
Here is the math:
https://sflow.org/packetSamplingBasics/
But what this means in practice is that you should select a packet-sampling
rate that does not stress the pipeline or impact performance at all.
Something like 1-in-1000 is quite common.
I haven't looked at the pmacct source code so I don't know what it does,
but just multiplying the bytes by the sampling-rate will only give you a
crude approximation. The sFlow protocol allows you to be much more accurate
that this because it always includes the latest value of the "sample pool",
a monotonic counter indicating the total number of packets that could have
been sampled. When you look at the number of samples you
successfully received (some may have been lost in transit) you can compute
the *effective* sampling rate, ESR:
ESR = delta(sample_pool) / count(samples)
which should be close to the 1:N setting you configured, but might not be
exactly the same. Now if you scale up using ESR you should have a number
that converges to the right answer. And as the paper above shows, the more
samples you have, the more accurate you will be.
Another tool you might use to verify your setup is the "sflow-test" app
that runs on the sFlow-RT platform, which is freely available for
non-production experiments like this. It has the nice property that you
can see the measured traffic level update every second, and compare it
directly with the interface counters that sFlow also streams:
https://blog.sflow.com/2015/11/sflow-test.html
--
Neil McKee
InMon Corp.
On Tue, Feb 4, 2020 at 12:18 PM Oliver Dzombic wrote:
> Hi,
>
> the goal is to math sflow into real traffic consumption.
>
> I am testing using pmacct with the sfacctd as collector software.
>
> I am using iperf3 to generate traffic between two hosts.
>
> From my understanding if i do a sflow export configuration like:
>
> agent : "127.0.0.1"
> external_ids: {}
> header : 1518
> polling : 1
> sampling: 1
> targets : ["127.0.0.1:6343"]
>
>
> Then every second, every package will be exported to the collector.
>
> When i send for 5 seconds a total amount of 2.36 GBytes, i would expect
> that the sum of the "bytes" would match with the 2.36 GB.
>
> The numbers that were collected were:
>
> {"event_type": "purge", "vlan": 0, "ip_src": "192.168.178.1", "ip_dst":
> "192.168.178.2", "packets": 192, "bytes": 13519}
>
> {"event_type": "purge", "vlan": 0, "ip_src": "192.168.178.1", "ip_dst":
> "192.168.178.2", "packets": 435, "bytes": 30474}
>
> {"event_type": "purge", "vlan": 0, "ip_src": "192.168.178.1", "ip_dst":
> "192.168.178.2", "packets": 388, "bytes": 27180}
>
> {"event_type": "purge", "vlan": 0, "ip_src": "192.168.178.1", "ip_dst":
> "192.168.178.2", "packets": 318, "bytes": 22260}
>
> {"event_type": "purge", "vlan": 0, "ip_src": "192.168.178.1", "ip_dst":
> "192.168.178.2", "packets": 436, "bytes": 30544}
>
> {"event_type": "purge", "vlan": 0, "ip_src": "192.168.178.1", "ip_dst":
> "192.168.178.2", "packets": 340, "bytes": 23990}
>
>
> And the math is not really matching.
>
> I repeated the test, changing the sample rate ( and multiply the sum of
> bytes with the sample rate ).
>
> But that did not really help. The numbers are changing, but not to
> amount of traffic that had been transfered.
>
>
> Since i assume that old established software like pmacct aswell as
> openvswitch will deliver correct numbers.
>
> So as it seems to me, my math is (still) as good as my teachers told me
> in the college.
>
> Could someone please point me into the right direction how to math that ?
>
> Thank you very much !
>
> --
> Mit freundlichen Gruessen / Best regards
>
> Oliver Dzombic
> Layer7 Networks
>
> mailto:i...@layer7.net
>
> Anschrift:
>
> Layer7 Networks GmbH
> Zum Sonnenberg 1-3
> 63571 Gelnhausen
>
> HRB 96293 beim Amtsgericht Hanau
> Geschäftsführung: Oliver Dzombic
> UST ID: DE259845632
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Should report an error when something are wrong in SFlow
This behavior comes from the sFlow version 5 spec at https://sflow.org/sflow_version_5.txt : The following values should be used for fields that are unknown (unless otherwise indicated in the structure definitions). - Unknown integer value. Use a value of 0 to indicate that a value is unknown. - Unknown counter. Use the maximum counter value to indicate that the counter is not available. Within any given sFlow session a particular counter must be always available, or always unavailable. An available counter may temporarily have the max value just before it rolls to zero. This is permitted. - Unknown string. Use the zero length empty string. */ So a constant value of 0x appearing in these counter fields means "counter not available".Does this answer your question? I suppose it's a separate question to ask if maybe those discard counters could be filled in now. Definitely worth a look. The sFlow spec now allows for the agent to send the headers of dropped packets too (rate limited, not sampled) so we may find that the OVS sFlow agent can be improved to do rather more than just export the counter: https://blog.sflow.com/2020/07/using-sflow-to-monitor-dropped-packets.html Neil On Sun, Mar 31, 2024 at 8:32 PM 李兴鑫 via discuss wrote: >Hi. Nearly, I found the values both of IfOutDiscards and IfInDiscards > are 2^31-1 in our environment. The SFlow returned a record is filled its > all bits with 1. I checked the relevant code, the implementation of SFlow > in OVS ignored the error from netdev_get_stats (see > https://github.com/openvswitch/ovs/blob/c6538b443984e10c266d7e75e797ef2f1b722d61/ofproto/ofproto-dpif-sflow.c#L351), > caused some bad values are reported. But in RFC2233, A SFlow implement > 'MUST NOT' instantiates an object with an incorrect value(see > https://www.rfc-editor.org/rfc/rfc2233.txt#:~:text=specific%20MIB.%0A%0A3.1.18.-,All%20Values%20Must%20be%20Known,-There%20are%20a > ). > > So, I think we had better return an error here, but not ignore it. > ___ > discuss mailing list > disc...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
