Re: [bug] in snmp agent

Hi,

Well, i have to say that to use the feature, i dont see how to avoid
browsing the index on a regular basis to catch the news client's ip
addresses and so add/discover new accounting sources.

Another point we have in mind is the following: like you say, browsing the
table is a long taks, CPU intensive and this occure on a regular basis. At
the end, we would like to account base on non-hit - bytes from a subnet.
So, there are 2 possibilities: aggregate the information on the
application side or on the agent side. I believe it would be usefull to
have this in the agent, to avoid unnecessary management traffic (that will
be quite big on large installation bases). So, what about adding a field
to the table: a netmask and be able to configure networks/mask and have X
new entries with those network/masks ?

For this bug resolution, adding a table (only the indexes) is defintively
a solution and would bring the possibility to add those networks/mask. The
values would be computed only when retrieved, this with a maximum of once
a minute or so.

I'll wait news from you,

Thanks,

Regards,

JeF

On Fri, 14 Dec 2001, Henrik Nordstrom wrote:

> As the client table is not normally kept sorted (it is a hash table), I
> think there is not much of a choice other than building a temporary
> table, or to create some other abstract index to the client table that
> is sorted such as the hash bucket number, index.
>
> I don't think the SNMP interface to the client table is really intended
> to be walked, rather queried for the exact IP one is interested in.
> Walking such a large table using SNMP is not a very nice task as the
> client table can contain several thousands of entries or more..
>
> Opinions from someone more SNMP customized than me wanted.
>
> Regards
> Henrik
>
> Jean-Francois Dive wrote:
> >
> > Hi all,
> >
> > This is to report a bug in the snmp agent of squid. A search in bugzilla
> > did not pointed me to any bug ID.
> >
> > When quirying the clientCacheTable, which is indexed on the IP address,
> > the agent does not order the reply of getNextRequest by sorted ip
> > addresses, but by appearance order. So, for example:
> >
> > getnext on cacheClientAddr.10.10.10.10 may return
> > cacheClientAddr.20.20.20.20 . This is not RFC compliant and give problems
> > with most snmpwalk which check that the previous answer is < than the new
> > one.
> >
> > As a workaround, use -Cc option in snmpwalk. My problem is that this makes
> > the table parsing in application not an easy task as standard tools
> > complains.
> >
> > After digging in the code, the problem seems to comes from
> > src/snmp_core.c::client_Inst() which takes the first entry in the
> > client_table trought a call to client_entry(NULL). I dont see anyway to
> > fix the problem but sort the client_table on the ip address, or use a
> > temporary table which is probably not very memory friendly.
> >
> > I'd be interested in any input on this.
> >
> > JeF
>
Received on Fri Dec 14 2001 - 19:38:15 MST