Re: Problems migrating from netflow to sFlow: results are low

Christian,

Here are a few suggestions:

1. Most Foundry switches only sample inbound traffic on an
interface, so if you only enabled sflow on the uplink then you are
probably only seeing the traffic in one direction. To monitor both
directions you can just enable sFlow on all ports. Did you enable
netflow on all ports of the router above?

2. sflowtool does not aggregate samples together, even if they are
from the same flow. I don't know what program you are using to
populate the database, but you might want to check that if two flows
with the same key are entered then they end up being added together
(rather than the second one replacing the first).

3. It's helpful to check the frames counter as well as the bytes
counter. The frames estimates will converge faster for a given
sampling rate, and it is not subject to any differences in the way
that bytes are counted. For netflow export, sflowtool uses the ip-
len from the ip header to say how many layer3 bytes there were. If
your netflow source was reporting the bytes including layer2 headers
then there would be a sizable discrepancy. (There are also
different ways to interpret udp packets if they are larger than 1518
bytes and being fragmented at the IP layer.)

You might cross-check using another product (http://www.sflow.org/products/collectors.php).
Some of them are free downloads (e.g. sFlowTrend, ntop, pmccact).

regards,
neil

On Aug 10, 2005, at 7:41 AM, Christian Hammers wrote:

> Hello
>
> I hope this is an appropriate mailing list to get some hints why my
> attempts to migrate from netflow to sflow are currently failing
> because
> the sflow data is just too "less" (I expected about 0-10% differenc).
>
> +------------+-------------+---------------+----------
> +------------+------+
> | day | sflow_flows | netflow_flows | sflow_mb |
> netflow_mb | s/n |
> +------------+-------------+---------------+----------
> +------------+------+
> Sa | 2005-08-06 | 2927 | 6128 | 513.223 |
> 961.606 | 0.53 |
> So | 2005-08-07 | 3060 | 6652 | 557.467 |
> 1659.690 | 0.34 |
> Mo | 2005-08-08 | 3240 | 6597 | 588.296 |
> 795.497 | 0.74 |
> Di | 2005-08-09 | 3212 | 6663 | 563.515 |
> 1525.798 | 0.37 |
> +------------+-------------+---------------+----------
> +------------+------+
>
> The test data below compares the volumina of some ADSL customers who
> could easily be identified by their network adresses (netflow) and
> are all behind one switchport which is exported via sflow. Their
> incoming data is exported via netflow *not* by this switch but by the
> router before it.
>
> The sFlow packets are collected and converted to netflow via:
> "sflowtool -c localhost -d 2042"
> The netflow packets are then collected and written to a MySQL
> database by
> the same program that collects our normal netflow data.
>
> I already verified that the number of packets going in and out of
> the Ethernet
> interface is the ca. "samplerate * sample_collected" and also ca.
> the number
> of netflow entries in my database. So there's no significant packet
> loss due
> to a too high number of samples arriving the collector etc.
> The number of exported UDP packets in a given timestamp is also
> about 20/min as
> configured.
>
> The switch has the following configuration:
> telnet@foundry-switch# show sflow
> sFlow services are enabled.
> sFlow agent IP address: 192.168.230.191
> Collector IP 192.168.230.7, UDP 6343
> Polling interval is 20 seconds.
> Configured default sampling rate: 1 per 512 packets.
> Actual default sampling rate: 1 per 512 packets.
> 49240976 UDP packets exported
> 305332506 sFlow samples collected.
> sFlow ports: ethe 3
> Port Sampling Rates
> -------------------
> Port=3, configured rate=512, actual rate=512
>
> Any ideas? Is sflowtool recommended for production usage?
>
> bye,
>
> -christian-
>
> --
> Christian Hammers WESTEND GmbH | Internet-Business-
> Provider
> Technik CISCO Systems Partner - Authorized
> Reseller
> L|tticher Stra_e 10 Tel
> 0241/701333-11
> ch@westend.com D-52064 Aachen Fax
> 0241/911879
Received on Wed Aug 10 10:12:20 2005