Re: [squid3-ipv6] NEW INDEXING SCHEMA for Cache-peer

From: Rafael Martinez Torres <rmartine@dont-contact.us>
Date: Sat, 03 Nov 2007 10:49:50 +0100

>
> Is there any reason why the PeerIndex is below the field type?
>
Sure. You have to keep the lexicographical ordering on OIDS.

RFC1157.txt available under doc/rfc

   [...]This naming strategy admits the fullest exploitation of the semantics
   of the GetNextRequest-PDU (see Section 4), because it assigns names
   for related variables so as to be contiguous in the lexicographical
   ordering of all variable names known in the MIB.

> SNMPv2-SMI::enterprises.3495.1.5.1.1.1.1 = INTEGER: 1
> SNMPv2-SMI::enterprises.3495.1.5.1.1.1.2 = INTEGER: 2
> SNMPv2-SMI::enterprises.3495.1.5.1.1.2.1 = STRING: "www.google.es"
> SNMPv2-SMI::enterprises.3495.1.5.1.1.2.2 = STRING: "www.google.es"
> SNMPv2-SMI::enterprises.3495.1.5.1.1.3.1 = INTEGER: 1
> SNMPv2-SMI::enterprises.3495.1.5.1.1.3.2 = INTEGER: 1
> SNMPv2-SMI::enterprises.3495.1.5.1.1.4.1 = STRING: "64.233.183.104"
> SNMPv2-SMI::enterprises.3495.1.5.1.1.4.2 = STRING: "64.233.183.104"
>
This is right, as every OID item is the lexical sucessor of previous
(i.e. suc(1.1.3.1) = 1.1.3.2

> I kind of expected it to be ordered like this:
>
> SNMPv2-SMI::enterprises.3495.1.5.1.1.1.1 = INTEGER: 1
> SNMPv2-SMI::enterprises.3495.1.5.1.1.2.1 = STRING: "www.google.es"
> SNMPv2-SMI::enterprises.3495.1.5.1.1.3.1 = INTEGER: 1
> SNMPv2-SMI::enterprises.3495.1.5.1.1.4.1 = STRING: "64.233.183.104"
> ...
> SNMPv2-SMI::enterprises.3495.1.5.1.1.1.2 = INTEGER: 2
> SNMPv2-SMI::enterprises.3495.1.5.1.1.2.2 = STRING: "www.google.es"
> SNMPv2-SMI::enterprises.3495.1.5.1.1.3.2 = INTEGER: 1
> SNMPv2-SMI::enterprises.3495.1.5.1.1.4.2 = STRING: "64.233.183.104"
> ...
>

Wrong. This does not keep lexicographical order:
suc (1.1.4.1) != 1.1.1.2
(no matter the "...", the same would happen for, let's say,
 suc(1.1.4.15) != 1.1.1.2

If so, you have apply the "-Cc" flag on receiving snmpwalk to ignore order.
But this is hack, and in fact the SNMP Agent SHOULD return OID's in
increasing order. As you will see in the further commits, the peer table now
is ordered by increasing index, (the order of squid.conf file), not as
previous, where they were unordered. (hence the need to index by IP)

Not a problem if any peer is added or removed in running time. Just it is
forbidden by "mib.txt" at least until you reboot the SNMP Agent (the squid )!
> (but with the last two .detail.peer entries int reversed order
> .peer.detail)
>
> Otherwise it looks good.
>
> Amos
Received on Mon Dec 03 2007 - 01:50:19 MST

This archive was generated by hypermail pre-2.1.9 : Mon Dec 31 2007 - 12:00:03 MST