Hi Paolo,
On 2014-01-24 15:56, Paolo Lucente wrote:
Interesting behaviour you are describing.
In-line for a comment about the high interface value:
On Thu, Jan 23, 2014 at 09:01:56PM +0100, Ruben Laban wrote:
As for the ports, I meant to say interfaces ;-) So I did a snmpwalk
against the switch and this told that those interface numbers 211
and 48 correspond to respectively trk2 (2nd configured trunk) and
port 48. So far, so good. The number 1073741823 doesn't show up at
all in the snmpwalk though, which is rather odd. Then again the
number is 0x3FFFFFFF which is probably something "special".
Indeed, that is a "special" indicating that there is no input/output
interface (depending which field the 0x3FFFFFFF is found). This is
typically the case if you ping the switch itself, for example.
Which seems like a bug in the switch then (wonder if it turns out to be
one of many...). As you can see, it's the reply traffic for the packets
with the proper interface IDs.
Based on some more testing: it appears that the switch offers very
little CPU cycles to the sFlow engine. With a sample rate of 1000 I
don't get dropped samples. With a sample rate of 100 and lowered traffic
throughput it also copes without dropping. But even with no drops being
reported, the numbers I see in sfacctd are still way too low. I have no
reason to blame sfacctd just yet, based on the other stuff I've seen.
So far these switches (or at least the sFlow part of them) aren't
giving me much of a comforting feeling. Next week I'll try to reach out
to HP regarding these issues.
Regards,
Ruben
_______________________________________________
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists
