Aaron Glenn wrote:
> On 1/9/07, Juraj Sucik <[EMAIL PROTECTED]> wrote:
>> Hello,
>>
>> I am trying to use sfacctd. I am receiving sflow packets from two
>> Force10 routers. However the routers send sflow packets to a host which
>> then forwards them to another host where I run sfacctd.
>
> How is the host forwarding this packets? if you're not already, you
> should be using samplicate (works perfectly).
>
>> I receive a lot of warnings like:
>> WARN: expecting flow '9210526' but received '5813156'
>> collector=(null):2060 agent=192.168.1.1:1
>> WARN: expecting flow '7618226' but received '10013980'
>> collector=(null):2060 agent=192.168.1.1:0
>> WARN: expecting flow '10013981' but received '7618227'
>> collector=(null):2060 agent=192.168.1.1:0
>> WARN: expecting flow '13099151' but received '7581594'
>> collector=(null):2060 agent=192.168.1.1:13
>> WARN: expecting flow '7581594' but received '13099152'
>> collector=(null):2060 agent=192.168.1.1:13
>>
>> The 192.168.1.1 is the address of the forwarding host. It seems that
>> sflacctd takes the source address of udp packet as an agent address,
>> which I think is incorrect. According to sflow specs the agent address
>> is included in sflow protocol itself (see page 32 of
>> http://sflow.org/sflow_version_5.txt ) and sfacctd should use this one
>> instead. I think this is also the reason for the warnings (sfacctd
>> actually thinks they are coming from the same source, but they are not).
>
> sfacctd uses the information provided in the sFlow datagrams, not the
> source address of the udp packet (well...I hope. using samplicate I
> keep the original source address so...maybe I'm wrong.)
I am using samplicate, but I do not keep the original address of the udp
packets since it would not be routed correctly on our network.
The problem is in the way the hash is created from the sflow sample. It
takes the address of UDP packet instead of the agent address written in
sflow sample (look in the function sfv245_check_status() in sfacctd.c).
The following is quick and dirty patch (which works for me very well):
--- sfacctd.c.orig 2007-01-10 17:59:12.000000000 +0100
+++ sfacctd.c 2007-01-10 18:00:09.000000000 +0100
@@ -2202,6 +2202,8 @@
char *sfv245_check_status(SFSample *spp, struct sockaddr *sa)
{
u_int32_t aux1 = spp->agentSubId;
+ struct sockaddr_in * sai = (struct sockaddr_in *) sa;
+ sai->sin_addr = spp->agent_addr.address.ip_v4;
int hash = hash_status_table(aux1, sa, XFLOW_STATUS_TABLE_SZ);
struct xflow_status_entry *entry = NULL;
Paolo, what do you think? Could you fix the sfacctd?
Regards,
Juraj
_______________________________________________
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists
