Hi Oliver,
as you know, sFlow relies on packet sampling. I'd say:
* this is why it's correct reasoning in terms of packets rather than bytes.
  On http://www.sflow.org/ you can find some useful documents.
* whether 6 packets out of a certain total is correct amount, it depends on
  the sampling rate you have configured on your switch.
* the fact that a little stream has been totally "ignored" while a big one
  has got some packets sampled makes a lot of sense to me.
* if you want to renormalize counters, you need to write down a config file
  and set 'sfacctd_renormalize' to true.

Cheers,
Paolo

On Thu, Oct 26, 2006 at 05:18:12PM +1000, Oliver Hookins wrote:
> Hi there,
> 
> I'm just starting my initial testing of an sFlow setup with some HP 3400cl
> switches and I've already run into some strange behaviour. The setup of
> sFlow on the switch in question is very simple - it is capturing data from
> all ports and sending the sFlow packets to my collector machine that is
> running sfacctd from pmacct-0.11.1.
> 
> The problems is that sfacctd is reporting very little data bytes/packets
> compared to what is actually crossing the network. For example the following
> output of "sfacctd -c src_host,dst_host,src_port,dst_port,proto -P print":
> 
> ID     CLASS             SRC_MAC            DST_MAC            VLAN   SRC_AS
> DST_AS  SRC_IP           DST_IP           SRC_PORT  DST_PORT  PROTOCOL
> TOS    PACKETS     FLOWS       BYTES
> 0      unknown           00:00:00:00:00:00  00:00:00:00:00:00  0      0
> 0       2.2.2.2    1.1.1.1    22        32899     tcp         0
> 1           0           1438
> 0      unknown           00:00:00:00:00:00  00:00:00:00:00:00  0      0
> 0       2.2.2.2    1.1.1.1    22        32899     tcp         0
> 1           0           1438
> 0      unknown           00:00:00:00:00:00  00:00:00:00:00:00  0      0
> 0       2.2.2.2    1.1.1.1    22        32899     tcp         0
> 1           0           1438
> 0      unknown           00:00:00:00:00:00  00:00:00:00:00:00  0      0
> 0       2.2.2.2    1.1.1.1    22        32899     tcp         0
> 3           0           4314
> 
> I know for a fact that during this period at least 33127 bytes were sent
> from 1.1.1.1 to 2.2.2.2, and 955427 bytes from 2.2.2.2 to 1.1.1.1. No
> backchannel traffic shows up from sfacctd at all, and the bulk of the
> traffic from 2.2.2.2 to 1.1.1.1 has been missed, as in the above printout
> you can see a total of less than 10000 bytes has been captured.



_______________________________________________
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists

Reply via email to